Отказ от ответственности

Эта статья была переведена с ее оригинального языка для вашего удобства. Несмотря на стремление к точности, могут быть небольшие ошибки или различия в толковании. Для наиболее точного и достоверного представления, пожалуйста, обратитесь к оригинальной публикации, доступной по ссылке. Мы ценим ваше понимание и рекомендуем обращаться к оригинальному источнику за подробной информацией.

Ключевые моменты:

• Архитектура FuelVM, основанная на регистрах, выполняет смарт-контракты с существенно меньшим количеством инструкций по сравнению со стековой EVM Ethereum, что приводит к более быстрым транзакциям и снижению затрат на газ.

• Регистровые архитектуры лучше соответствуют современным архитектурам процессоров и позволяют напрямую обращаться к переменным, устраняя ошибки “stack too deep”, с которыми сталкиваются разработчики Ethereum.

• Сложные операции, требующие нескольких шагов в стековых системах, могут выполняться за значительно меньшее количество шагов в архитектуре на регистрах.

• Хотя FuelVM обеспечивает более высокую производительность, разработчикам необходимо изучать новый язык (Sway) и инструментарий, поскольку она не совместима с EVM — это осознанный выбор в пользу эффективности, а не обратной совместимости.

• Сочетание регистровой архитектуры и модели транзакций UTXO позволяет реализовать настоящую параллельную обработку, при которой несколько транзакций могут обрабатываться одновременно, а не последовательно, что значительно увеличивает пропускную способность.

Ethereum стал пионером в области смарт-контрактов благодаря своей виртуальной машине Ethereum Virtual Machine (EVM). Хотя EVM заслуживает признания за то, что сделала возможными программируемые блокчейны, её стековая архитектура накладывает определённые ограничения. Сейчас появляются новые виртуальные машины, включая FuelVM, которая предлагает принципиально иной подход благодаря своей регистровой архитектуре.

Решает ли этот архитектурный сдвиг давние проблемы блокчейнов, такие как скорость транзакций, комиссии и пропускная способность? Давайте разберёмся по шагам.

Регистровая архитектура означает, что виртуальная машина работает преимущественно с регистрами — специальными именованными переменными — вместо структуры данных типа стек. FuelVM имеет собственный набор инструкций, оптимизированный под такой регистровый подход, что позволяет выполнять операции более эффективно, чем в стековых решениях. Такая архитектура позволяет Fuel поддерживать широкий спектр децентрализованных приложений с существенно более высокими характеристиками производительности по сравнению с виртуальными машинами предыдущего поколения.

Чтобы понять, почему регистровый подход FuelVM представляет собой такой значительный шаг вперёд, необходимо рассмотреть стековую архитектуру, используемую в EVM и большинстве других блокчейн-виртуальных машин.

Стековая виртуальная машина работает на основе структуры данных «последним пришёл — первым вышел» (LIFO), где операции могут выполняться только с элементами, находящимися на вершине стека. Это можно представить как стопку бумажных листов или карточек на столе, где вы можете только:

• Добавить (push) новую карточку наверх стека

• Удалить (pop) верхнюю карточку из стека

То есть вы работаете со стопкой карточек, где можете видеть и взаимодействовать только с самой верхней. Если вам нужна третья карточка снизу, сначала нужно снять верхние две, затем получить нужную, а потом вернуть обратно те, что сняли.

Такой подход ограничивает прямой доступ только к верхним элементам стека, что означает, что программисты должны тщательно управлять порядком выполнения операций.

При выполнении операций в стековой виртуальной машине (VM) необходимо:

1. Поместить значения в стек (push)

2. Выполнить операцию, которая извлекает значения из стека

3. Поместить результат обратно в стек

Рассмотрим, как происходит сложение двух чисел в EVM:

Для простого сложения требуются три отдельные операции. По мере увеличения сложности программ этот накладной процесс значительно возрастает. Виртуальная машина тратит значительные ресурсы не на вычисления, а на манипуляции со стеком.

У стека в EVM есть жёсткие ограничения. Он ограничен 1024 элементами, и операции могут напрямую обращаться только к верхним 16. Это приводит к печально известным ошибкам “stack too deep”, когда разработчики создают функции с большим числом переменных или сложной логикой. В итоге им приходится писать странный, неестественный код, чтобы обойти эти ограничения.

Архитектуры на основе регистров (как в FuelVM) позволяют выполнять операции напрямую с именованными ячейками хранения, называемыми регистрами. Каждый регистр можно использовать напрямую по имени, без необходимости предварительно перемещать другие данные.

Представьте себе подписанные коробки — R1, R2, R3 и так далее. Вы можете поместить значения в любую коробку и использовать их, просто ссылаясь на её метку. Если вам нужно значение из коробки R3 — вы просто смотрите в R3, не нужно перед этим убирать другие. Большинство современных процессоров построены по архитектуре на регистрах, потому что это эффективно и гибко.

В системе на основе регистров выполнение программы включает:

1. Загрузку значений в определённые регистры

2. Выполнение операций, явно ссылающихся на эти регистры

3. Сохранение результатов в заданных регистрах

Например, сложение двух чисел в FuelVM выглядит следующим образом:

ADD R3, R1, R2    // Add values from R1 and R2, store result in R3

Этот подход исключает необходимость постоянного добавления и удаления данных из стека, существенно сокращая количество инструкций. Виртуальные машины на регистрах обладают рядом преимуществ в плане эффективности:

• Снижение Количества Инструкций: Меньше операций требуется для достижения того же результата.

• Прямой Доступ: Нет необходимости перемещать значения — виртуальная машина может напрямую обратиться к любому регистру по имени.

• Более Понятный Код: Инструкции явно указывают, с какими значениями они работают.

• Меньше Накладных Расходов: Не нужно постоянно управлять стеком, что уменьшает количество вспомогательных операций.

• Лучшая Оптимизация: Компиляторам проще оптимизировать работу с регистрами.

Регистры в FuelVM имеют разрядность 64 бита, что хорошо согласуется с архитектурой современных процессоров. Это значит, что при выполнении кода FuelVM узел выполняет множество операций на «нативной» скорости (в то время как в EVM, например, 256-битная арифметика разбивается на несколько 64-битных операций за кулисами).

Кроме того, FuelVM использует UTXO-модель (как у Биткойна), а не модель аккаунтов, как в Ethereum. Это означает, что каждая транзакция явно указывает, какие монеты/входы она использует. Это может показаться не связанным, но на самом деле важно: благодаря UTXO и регистраторам FuelVM может обрабатывать несколько транзакций параллельно, без конфликтов. Представьте это как несколько параллельных производственных линий, где каждая транзакция заранее знает, с какими «деталями» (UTXO) ей предстоит работать. В Ethereum с его общей моделью состояния — это одна производственная линия, на которой все выполняется по очереди.

Регистровые виртуальные машины стабильно превосходят стековые на практике. Разница в эффективности между регистровой и стековой архитектурами становится очевидной, когда мы сравниваем эквивалентные операции:

EVM (на основе стека):

PUSH value1    // Push first value
PUSH value2    // Push second value
SWAP1          // Swap the top two stack items

Хотя обе версии требуют 3 операции, регистровая версия выглядит более понятной и не нуждается в избыточном управлении стеком.

Разница между виртуальными машинами становится ещё более заметной при выполнении сложных операций.

EVM (на основе стека):

PUSH a
PUSH b
ADD      // Compute a + b
PUSH c
PUSH d
SUB      // Compute c - d
MUL      // Multiply the results

Для выполнения такой операции требуется до 7 шагов. Это связано с тем, что стековая архитектура работает как конвейер с одной линией, где можно взаимодействовать только с верхним элементом.

FuelVM (на базе регистров):

ADD R5, R1, R2    // R5 = a + b
SUB R6, R3, R4    // R6 = c - d
MUL R7, R5, R6    // R7 = (a + b) * (c - d)

Метод с регистрами позволяет сохранять промежуточные результаты в именованных ячейках и использовать их точно тогда, когда это необходимо, поэтому для выполнения той же операции требуется всего 3 шага!

Наиболее очевидное преимущество, которое видно из приведённых выше примеров — это скорость. Выполняя ту же работу с меньшим количеством инструкций, FuelVM может исполнять код смарт-контрактов быстрее и эффективнее. Всё это означает более быструю работу для пользователей и потенциально гораздо более высокую масштабируемость по сравнению со многими другими цепочками на базе EVM. И это не просто красивые слова. Тесты показывают, что FuelVM может обрабатывать около 400 тысяч TPS на M4, при этом не создавая накладных расходов на контракты и минимизируя рост состояния.

https://x.com/IAmNickDodson/status/1883394906435244343

Снижение количества инструкций для выполнения определённой задачи также означает, что газ, необходимый для сложных операций, будет меньше. FuelVM была спроектирована с учётом того, что каждая операция (opcode) влияет на стоимость, поэтому уменьшение количества необходимых операций делает транзакции в целом дешевле (разумеется, реальные комиссии также зависят от нагрузки на сеть, но эффективность помогает в любом случае).

Фундаментальное различие между регистровой и стековой архитектурой влияет не только на производительность — оно меняет сам подход разработчиков к написанию и восприятию кода.

При работе со стековыми виртуальными машинами, такими как EVM, разработчикам приходится постоянно отслеживать позиции в стеке и мысленно прослеживать операции добавления и удаления значений. Это создает когнитивную нагрузку и приводит к неестественным шаблонам кода, используемым лишь для обхода ограничений стека. Печально известные ошибки “stack too deep” в Solidity — это прямое следствие ограничения EVM на доступ только к 16 верхним элементам стека, что вынуждает разработчиков перестраивать логичный код.

FuelVM на основе регистров устраняет эти ограничения. Разработчики могут:

• Обращаться к любой переменной напрямую по имени, без необходимости управлять позициями в стеке

• Писать код, который соответствует естественным логическим рассуждениям, а не манипуляциям со стеком

• Создавать более сложные функции, не сталкиваясь с произвольными ограничениями глубины стека

• Сосредоточиться на бизнес-логике, а не на борьбе с особенностями виртуальной машины

Sway — язык программирования от Fuel, вдохновлённый Rust, — идеально дополняет регистровую модель. Вместо того чтобы думать: «Сначала нужно поместить значение A, затем значение B, затем сложить их», разработчик просто пишет let result = a + b — гораздо ближе к тому, как мы естественно рассуждаем о вычислениях. Если вы знакомы с Rust, Sway покажется вам знакомым. У него современный синтаксис и инструменты, которые помогают предотвратить ошибки, а не заставляют искать их позже. В отличие от Solidity, где разработчики постоянно борются с ограничениями стека и странностями EVM.

Стековые EVM заставляют разработчиков мыслить в обратном порядке, постоянно перекладывая данные в стеке. С регистрами FuelVM они просто размещают данные там, где нужно, и используют их по мере необходимости — гораздо ближе к нашему естественному подходу к программированию. К тому же экономия газа за счёт меньшего количества операций означает, что пользователи не переплачивают за базовую функциональность.

Этот архитектурный сдвиг делает программирование на блокчейне более доступным и снижает порог специализированных знаний, необходимых для написания эффективных смарт-контрактов.

Регистровая FuelVM против стековой EVM сводится к простому компромиссу: вы хотите молниеносную производительность или лёгкую совместимость?

FuelVM не совместима с EVM, что означает, что вы не можете просто скопировать и вставить свой Solidity-код и ожидать, что он будет работать. Вместо этого вам придётся изучить Sway и по-новому взглянуть на то, как выполняется ваш код. Это действительно серьёзное препятствие, учитывая, что у EVM уже есть масса разработчиков, инструментов и документации.

Но мы сделали этот выбор сознательно. Стековые EVM были разработаны ради простоты, а не производительности. Регистровые системы могут потребовать больше усилий на изучение, но они гораздо эффективнее. Существенные улучшения в скорости выполнения, стоимости газа и удобстве разработки в конечном итоге перевесят издержки на переход.

С регистрами ваш код может напрямую обращаться к переменным по имени, без необходимости «жонглировать» стеком. Это ближе к тому, как на самом деле работают современные языки программирования.

Ставка FuelVM довольно проста: мы считаем, что разработчики со временем перейдут, несмотря на порог входа, потому что прирост производительности слишком хорош, чтобы его игнорировать.

Отказ от ответственности

Эта статья была переведена с ее оригинального языка для вашего удобства. Несмотря на стремление к точности, могут быть небольшие ошибки или различия в толковании. Для наиболее точного и достоверного представления, пожалуйста, обратитесь к оригинальной публикации, доступной по ссылке. Мы ценим ваше понимание и рекомендуем обращаться к оригинальному источнику за подробной информацией.

Ключевые моменты:

• Архитектура FuelVM, основанная на регистрах, выполняет смарт-контракты с существенно меньшим количеством инструкций по сравнению со стековой EVM Ethereum, что приводит к более быстрым транзакциям и снижению затрат на газ.

• Регистровые архитектуры лучше соответствуют современным архитектурам процессоров и позволяют напрямую обращаться к переменным, устраняя ошибки “stack too deep”, с которыми сталкиваются разработчики Ethereum.

• Сложные операции, требующие нескольких шагов в стековых системах, могут выполняться за значительно меньшее количество шагов в архитектуре на регистрах.

• Хотя FuelVM обеспечивает более высокую производительность, разработчикам необходимо изучать новый язык (Sway) и инструментарий, поскольку она не совместима с EVM — это осознанный выбор в пользу эффективности, а не обратной совместимости.

• Сочетание регистровой архитектуры и модели транзакций UTXO позволяет реализовать настоящую параллельную обработку, при которой несколько транзакций могут обрабатываться одновременно, а не последовательно, что значительно увеличивает пропускную способность.

Ethereum стал пионером в области смарт-контрактов благодаря своей виртуальной машине Ethereum Virtual Machine (EVM). Хотя EVM заслуживает признания за то, что сделала возможными программируемые блокчейны, её стековая архитектура накладывает определённые ограничения. Сейчас появляются новые виртуальные машины, включая FuelVM, которая предлагает принципиально иной подход благодаря своей регистровой архитектуре.

Решает ли этот архитектурный сдвиг давние проблемы блокчейнов, такие как скорость транзакций, комиссии и пропускная способность? Давайте разберёмся по шагам.

Регистровая архитектура означает, что виртуальная машина работает преимущественно с регистрами — специальными именованными переменными — вместо структуры данных типа стек. FuelVM имеет собственный набор инструкций, оптимизированный под такой регистровый подход, что позволяет выполнять операции более эффективно, чем в стековых решениях. Такая архитектура позволяет Fuel поддерживать широкий спектр децентрализованных приложений с существенно более высокими характеристиками производительности по сравнению с виртуальными машинами предыдущего поколения.

Чтобы понять, почему регистровый подход FuelVM представляет собой такой значительный шаг вперёд, необходимо рассмотреть стековую архитектуру, используемую в EVM и большинстве других блокчейн-виртуальных машин.

Стековая виртуальная машина работает на основе структуры данных «последним пришёл — первым вышел» (LIFO), где операции могут выполняться только с элементами, находящимися на вершине стека. Это можно представить как стопку бумажных листов или карточек на столе, где вы можете только:

• Добавить (push) новую карточку наверх стека

• Удалить (pop) верхнюю карточку из стека

То есть вы работаете со стопкой карточек, где можете видеть и взаимодействовать только с самой верхней. Если вам нужна третья карточка снизу, сначала нужно снять верхние две, затем получить нужную, а потом вернуть обратно те, что сняли.

Такой подход ограничивает прямой доступ только к верхним элементам стека, что означает, что программисты должны тщательно управлять порядком выполнения операций.

При выполнении операций в стековой виртуальной машине (VM) необходимо:

1. Поместить значения в стек (push)

2. Выполнить операцию, которая извлекает значения из стека

3. Поместить результат обратно в стек

Рассмотрим, как происходит сложение двух чисел в EVM:

Для простого сложения требуются три отдельные операции. По мере увеличения сложности программ этот накладной процесс значительно возрастает. Виртуальная машина тратит значительные ресурсы не на вычисления, а на манипуляции со стеком.

У стека в EVM есть жёсткие ограничения. Он ограничен 1024 элементами, и операции могут напрямую обращаться только к верхним 16. Это приводит к печально известным ошибкам “stack too deep”, когда разработчики создают функции с большим числом переменных или сложной логикой. В итоге им приходится писать странный, неестественный код, чтобы обойти эти ограничения.

Архитектуры на основе регистров (как в FuelVM) позволяют выполнять операции напрямую с именованными ячейками хранения, называемыми регистрами. Каждый регистр можно использовать напрямую по имени, без необходимости предварительно перемещать другие данные.

Представьте себе подписанные коробки — R1, R2, R3 и так далее. Вы можете поместить значения в любую коробку и использовать их, просто ссылаясь на её метку. Если вам нужно значение из коробки R3 — вы просто смотрите в R3, не нужно перед этим убирать другие. Большинство современных процессоров построены по архитектуре на регистрах, потому что это эффективно и гибко.

В системе на основе регистров выполнение программы включает:

1. Загрузку значений в определённые регистры

2. Выполнение операций, явно ссылающихся на эти регистры

3. Сохранение результатов в заданных регистрах

Например, сложение двух чисел в FuelVM выглядит следующим образом:

ADD R3, R1, R2    // Add values from R1 and R2, store result in R3

Этот подход исключает необходимость постоянного добавления и удаления данных из стека, существенно сокращая количество инструкций. Виртуальные машины на регистрах обладают рядом преимуществ в плане эффективности:

• Снижение Количества Инструкций: Меньше операций требуется для достижения того же результата.

• Прямой Доступ: Нет необходимости перемещать значения — виртуальная машина может напрямую обратиться к любому регистру по имени.

• Более Понятный Код: Инструкции явно указывают, с какими значениями они работают.

• Меньше Накладных Расходов: Не нужно постоянно управлять стеком, что уменьшает количество вспомогательных операций.

• Лучшая Оптимизация: Компиляторам проще оптимизировать работу с регистрами.

Регистры в FuelVM имеют разрядность 64 бита, что хорошо согласуется с архитектурой современных процессоров. Это значит, что при выполнении кода FuelVM узел выполняет множество операций на «нативной» скорости (в то время как в EVM, например, 256-битная арифметика разбивается на несколько 64-битных операций за кулисами).

Кроме того, FuelVM использует UTXO-модель (как у Биткойна), а не модель аккаунтов, как в Ethereum. Это означает, что каждая транзакция явно указывает, какие монеты/входы она использует. Это может показаться не связанным, но на самом деле важно: благодаря UTXO и регистраторам FuelVM может обрабатывать несколько транзакций параллельно, без конфликтов. Представьте это как несколько параллельных производственных линий, где каждая транзакция заранее знает, с какими «деталями» (UTXO) ей предстоит работать. В Ethereum с его общей моделью состояния — это одна производственная линия, на которой все выполняется по очереди.

Регистровые виртуальные машины стабильно превосходят стековые на практике. Разница в эффективности между регистровой и стековой архитектурами становится очевидной, когда мы сравниваем эквивалентные операции:

EVM (на основе стека):

PUSH value1    // Push first value
PUSH value2    // Push second value
SWAP1          // Swap the top two stack items

Хотя обе версии требуют 3 операции, регистровая версия выглядит более понятной и не нуждается в избыточном управлении стеком.

Разница между виртуальными машинами становится ещё более заметной при выполнении сложных операций.

EVM (на основе стека):

PUSH a
PUSH b
ADD      // Compute a + b
PUSH c
PUSH d
SUB      // Compute c - d
MUL      // Multiply the results

Для выполнения такой операции требуется до 7 шагов. Это связано с тем, что стековая архитектура работает как конвейер с одной линией, где можно взаимодействовать только с верхним элементом.

FuelVM (на базе регистров):

ADD R5, R1, R2    // R5 = a + b
SUB R6, R3, R4    // R6 = c - d
MUL R7, R5, R6    // R7 = (a + b) * (c - d)

Метод с регистрами позволяет сохранять промежуточные результаты в именованных ячейках и использовать их точно тогда, когда это необходимо, поэтому для выполнения той же операции требуется всего 3 шага!

Наиболее очевидное преимущество, которое видно из приведённых выше примеров — это скорость. Выполняя ту же работу с меньшим количеством инструкций, FuelVM может исполнять код смарт-контрактов быстрее и эффективнее. Всё это означает более быструю работу для пользователей и потенциально гораздо более высокую масштабируемость по сравнению со многими другими цепочками на базе EVM. И это не просто красивые слова. Тесты показывают, что FuelVM может обрабатывать около 400 тысяч TPS на M4, при этом не создавая накладных расходов на контракты и минимизируя рост состояния.

https://x.com/IAmNickDodson/status/1883394906435244343

Снижение количества инструкций для выполнения определённой задачи также означает, что газ, необходимый для сложных операций, будет меньше. FuelVM была спроектирована с учётом того, что каждая операция (opcode) влияет на стоимость, поэтому уменьшение количества необходимых операций делает транзакции в целом дешевле (разумеется, реальные комиссии также зависят от нагрузки на сеть, но эффективность помогает в любом случае).

Фундаментальное различие между регистровой и стековой архитектурой влияет не только на производительность — оно меняет сам подход разработчиков к написанию и восприятию кода.

При работе со стековыми виртуальными машинами, такими как EVM, разработчикам приходится постоянно отслеживать позиции в стеке и мысленно прослеживать операции добавления и удаления значений. Это создает когнитивную нагрузку и приводит к неестественным шаблонам кода, используемым лишь для обхода ограничений стека. Печально известные ошибки “stack too deep” в Solidity — это прямое следствие ограничения EVM на доступ только к 16 верхним элементам стека, что вынуждает разработчиков перестраивать логичный код.

FuelVM на основе регистров устраняет эти ограничения. Разработчики могут:

• Обращаться к любой переменной напрямую по имени, без необходимости управлять позициями в стеке

• Писать код, который соответствует естественным логическим рассуждениям, а не манипуляциям со стеком

• Создавать более сложные функции, не сталкиваясь с произвольными ограничениями глубины стека

• Сосредоточиться на бизнес-логике, а не на борьбе с особенностями виртуальной машины

Sway — язык программирования от Fuel, вдохновлённый Rust, — идеально дополняет регистровую модель. Вместо того чтобы думать: «Сначала нужно поместить значение A, затем значение B, затем сложить их», разработчик просто пишет let result = a + b — гораздо ближе к тому, как мы естественно рассуждаем о вычислениях. Если вы знакомы с Rust, Sway покажется вам знакомым. У него современный синтаксис и инструменты, которые помогают предотвратить ошибки, а не заставляют искать их позже. В отличие от Solidity, где разработчики постоянно борются с ограничениями стека и странностями EVM.

Стековые EVM заставляют разработчиков мыслить в обратном порядке, постоянно перекладывая данные в стеке. С регистрами FuelVM они просто размещают данные там, где нужно, и используют их по мере необходимости — гораздо ближе к нашему естественному подходу к программированию. К тому же экономия газа за счёт меньшего количества операций означает, что пользователи не переплачивают за базовую функциональность.

Этот архитектурный сдвиг делает программирование на блокчейне более доступным и снижает порог специализированных знаний, необходимых для написания эффективных смарт-контрактов.

Регистровая FuelVM против стековой EVM сводится к простому компромиссу: вы хотите молниеносную производительность или лёгкую совместимость?

FuelVM не совместима с EVM, что означает, что вы не можете просто скопировать и вставить свой Solidity-код и ожидать, что он будет работать. Вместо этого вам придётся изучить Sway и по-новому взглянуть на то, как выполняется ваш код. Это действительно серьёзное препятствие, учитывая, что у EVM уже есть масса разработчиков, инструментов и документации.

Но мы сделали этот выбор сознательно. Стековые EVM были разработаны ради простоты, а не производительности. Регистровые системы могут потребовать больше усилий на изучение, но они гораздо эффективнее. Существенные улучшения в скорости выполнения, стоимости газа и удобстве разработки в конечном итоге перевесят издержки на переход.

С регистрами ваш код может напрямую обращаться к переменным по имени, без необходимости «жонглировать» стеком. Это ближе к тому, как на самом деле работают современные языки программирования.

Ставка FuelVM довольно проста: мы считаем, что разработчики со временем перейдут, несмотря на порог входа, потому что прирост производительности слишком хорош, чтобы его игнорировать.