Роллапы, zkEVM, совместимость с EVM I Руководство для начинающих

1. Вступление
2. ZK-Роллпы
3. Роллапы для конкретных приложений
4. Разбираемся с EVM
5. Совместимость с Ethereum
6. ZK-EVM
7. Вариант 1. Доказательство трассировки выполнения в EVM
8. Вариант 2: Пользовательская виртуальная машина + поддержка опкодов
9. Вариант 3: Пользовательская виртуальная машина + конвертер
10. Варианты zkEVM от Виталика
11. Что сейчас происходит в области роллапов для смарт-контрактов
12. Дополнительные факторы
13. Заключение
    

ZK-роллапы уже давно воспринимаются как конечное решение проблемы масштабирования Ethereum.

Но, несмотря на их важность для Ethereum, для многих до сих пор не до конца ясны некоторые ключевые моменты:

• Что конкретно представляет собой zk-роллап?
• В чем разница между роллапами для конкретных приложений и роллапами общего назначения?
• Что такое zk-EVM-роллап? Что вообще означают такие термины, как EVM-эквивалент и EVM-совместимость, и как они соотносятся с роллапами?
• Что сейчас происходит в экосистеме zk-роллапов, и как это отражается на моем проекте?

Если вы разработчик, которому необходимо понять следующий этап масштабирования Ethereum, эта статья (надеюсь) поможет вам.

ZK-роллапы возможны благодаря простому утверждению: такие системы доказательств, как STARK или SNARK, позволяют проверять линейное количество утверждений с помощью сублинейной обработки (например, 1000 утверждений → 10 проверок верификатора, 10 000 утверждений → 11 проверок верификатора).

Это свойство используется для создания широко масштабируемой обработки транзакций в блокчейне следующим образом:

1. Пользователь блокирует средства в смарт-контракте zk-rollup на L1
2. Пользователь отправляет транзакции с этими активами в секвенсор L2, который группирует их и генерирует доказательство валидности (например, STARK/SNARK) вместе с обновлением состояния для каждой партии
3. Эти обновления состояния и доказательства поступают в наш смарт-контракт zk-rollup на L1, где проверяются и используются для обновления состояния L1
4. Пользователь может получить свои активы, используя обновленное состояние L1 (с учетом различных механизмов доступности данных), что обеспечивает полноценное самостоятельное хранение и "безопасность сети Ethereum".

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

Чтобы детальнее рассмотреть этот процесс, я бы рекомендовал "Неполное руководство по роллапам" от Виталика:

или недавно выпущенное "Полное руководство по роллапам" от Delphi:

Пока что все выпускаемые zk-роллапы, с которыми мы сталкивались, были так называемыми "роллапами для конкретного приложения".

Роллап, специально разработанный для конкретного приложения, поддерживает определенное количество "изменений состояния" (например, торговлю), определяемое оператором роллапа.

Это чрезвычайно полезно для высокой оптимизации типичных случаев использования, например:

• Loopring — платежи и свопы
• Immutable — майнинг и торговля NFT, игры
• dydx — торговля бессрочными контрактами

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

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

Например, в Immutable мы можем вообще устранить плату за газ, субсидируя бесплатные NFT-минты и переводы за счет комиссий за NFT сделки - компромисс, который возможен только благодаря предсказуемой природе изменений состояний роллапа.

Тем не менее многим проектам нужна возможность создавать свою собственную логику и смарт-контракты независимо от оператора роллапа, а это невозможно в роллапе, ориентированном на конкретное приложение.

Кроме того, многим DeFi-проектам требуется "комбинируемость", или способность атомарно взаимодействовать с другими проектами (например, многие DeFi проекты используют Uniswap в качестве ценового оракула).

Комбинируемость становится возможной только в том случае, если ваш роллап поддерживает не только пользовательский код, но и собственные смарт-контракты, которые может развернуть любой пользователь.

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

Но важнее здесь то, что еще не было ни одной реализации zk-роллапов общего назначения, и уж тем более ни одной, способной к массовому использованию.

Но ситуация постепенно меняется:

• У StarkNet на данный момент запущена основная сеть (хотя и в ограниченной альфа-версии).
• 3 отдельных проекта (zkSync, Polygon Hermez/zkEVM и Scroll) на ETH CC 2022 объявили, что станут первыми "zkEVM", запустившими основные сети.

Последние объявления заслуживают внимания, потому что эти команды заявили не о простых роллапах общего назначения, а о "zkEVM".

За этим последовало много споров в Твиттере вокруг "совместимости EVM", "эквивалентности EVM", "истинного zkEVM" и того, что из этого лучше.

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

Давайте начнем с самого начала: что такое EVM?

Впервые была определена в "желтой книге" Ethereum, а затем модифицирована серией предложений по совершенствованию Ethereum (EIPs).

Она состоит из:

• Стандартной "машины" для выполнения программ, с переменчивой "памятью" для каждой транзакции, постоянным "хранилищем", куда записываются транзакции, и операционным "стеком";
• ~140 ценовых "опкодов", которые выполняют изменения состояния в этой машине.

Примеры операционных кодов для нашей виртуальной машины:

• Операции со стеком — PUSH1 (добавляет что-то в стек)
• Арифметические операции — ADD (сложение чисел), SUBTRACT
• Операции состояния — SSTORE (сохранение данных), SLOAD (загрузка данных)
• Операции транзакции — CALLDATA, BLOCKNUMBER (возвращают информацию о текущей выполняемой транзакции).

Если программы представлены в виде одного непрерывного кода, то это называется "байткод" (обычно представленный в виде длинной шестнадцатеричной строки).

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

У Ethereum своя виртуальная машина, а не адаптация какой-либо существующей, потому что у сети уникальные потребности:

• У каждой операции должна быть "стоимость" для предотвращения злоупотреблений (поскольку все ноды выполняют все транзакции);
• Каждая операция должна быть детерминированной (поскольку все ноды должны согласиться с состоянием после выполнения транзакции);
• Нам нужны характерные для блокчейна концепции (например, смарт-контракты, транзакции);
• Некоторые сложные операции должны быть примитивами (например, криптография);
• Транзакции должны пройти через "песочницу", без ввода-вывода или доступа к внешнему состоянию.

У нее есть ограничения по дизайну, но ее огромное преимущество первого и дальнейшее широкое внедрение обеспечило колоссальное превосходство для Ethereum — на сегодня это самая закаленная в боях часть инфраструктуры смарт-контрактов во всей индустрии.

Из-за доминирующего положения Ethereum многие более поздние блокчейны начали сразу с этой среды исполнения.

Важно заметить, что EVM — это не что-то неизменное, и она часто проходит через обновления, такие как EIP1559:

Другим блокчейнам требуется время на обновление, или же они в каких-то моментах отличаются от Ethereum, поэтому зачастую используются несколько устаревшие версии EVM, и им сложно поспевать за изменениями.

Сей факт может расстраивать основных разработчиков Ethereum:

Однако, когда люди говорят о "сети EVM", то речь обычно идет не только о зеркальном отображении этой среды выполнения.

В Ethereum зародились несколько основных спецификаций, которые де-факто стали глобальными стандартами:

• Solidity (высокоуровневый язык, который компилируется в байткод EVM);
• Клиент Ethereum JSON-RPC API (спецификация для взаимодействия с нодами Ethereum);
• ERC20/ERC721 (стандарты токенов Ethereum);
• ethers.js (веб-библиотека для взаимодействия с Ethereum);
• Криптография Ethereum (например, keccak256 в качестве хэш-функции, подписи ECDSA на secp256k1).

Технически, ваша сеть может работать с EVM без поддержки некоторых или всех вышеперечисленных стандартов.

Однако соответствие этим стандартам существенно облегчит использование инструментов Ethereum в вашей новой сети.

Хорошим примером выступает Polygon, где, помимо использования всех вышеперечисленных инструментов, запущена форкнутая версия Etherscan (Polygonscan), используются инструменты разработчика Ethereum, такие как Hardhat, и который поддерживается как другая "сеть" Ethereum в таких кошельках, как Metamask.

Популярные инструменты, как Nansen и Dune, первоначально нацелены на Ethereum, так что добавить поддержку новых EVM блокчейнов очень просто.

Новые кошельки, новые торговые площадки NFT — если единственное, что вас отличает от интерфейса Ethereum, это ID сети, то вас, скорее всего, будут добавлять одними из первых.

Конечно, эти инструменты созданы для Ethereum, так что как только вы начнете модифицировать свой блокчейн (например, увеличивать размер блоков, ускорять время блока), то рискуете потерять с ними связь. Идеальной совместимости не бывает.

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

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

На мой взгляд термин "совместимость с EVM" недостаточно описывает сетевой эффект — на самом деле мы говорим о "совместимости с Ethereum", которая распространяется не только на среду исполнения смарт-контрактов, но и на всю экосистему и инструментарий Ethereum.

Блокчейны, не использующие EVM, такие как Solana, вынуждены создавать совершенно параллельные экосистемы, что тормозит их развитие и затрудняет привлечение новых разработчиков.

Впрочем, отсутствие необходимости соблюдать стандарты EVM дает блокчейнам свободу вносить фундаментальные изменения в инструментарий и тем самым сильнее дифференцировать себя от Ethereum.

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

Если вы знаете, как преодолевать трудности создания успешной параллельной цепочки и экосистемы, то Solana вдохновит своими результатами.

Сеть показала, что:

• Вы можете получить потрясающие собственные приложения (например, MagicEden, Phantom);
• Проекты, созданные на основе EVM, будут поддерживать вас, если будет достаточный коммерческий стимул (например, Opensea добавила поддержку Solana).

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

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

А команды разработчиков роллапов (по причинам, изложенным выше) думают о следующем:

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

Но это уже не так просто, как форкнуть Geth для создания нового L1 блокчейна с нуля.

Цель — запустить байткод EVM.

Только вот ZK-доказательства требуют, чтобы все вычислительные утверждения, которые они доказывают, были преобразованы в очень специфический формат — "алгебраическую схему", которую затем можно скомпилировать в STARK или SNARK.

Чтобы понять, что такое "схемы", приведем пример (используя более наглядную булеву схему в качестве частного случая арифметической схемы).

В системе zkSNARK, построенной на этой простой схеме, доказывающий хочет убедить проверяющего, что им известны входные данные (𝑥1 = 1, 𝑥2 = 1, 𝑥3 = 0), которые дают на выходе истину.

Это суперупрощенная схема с ограниченным количеством логических элементов.

Уверен, что вам несложно будет представить, сколько элементов понадобится для кодирования схемы, доказывающей сложное взаимодействие смарт-контрактов, особенно тех, которые включают криптографию!

Для полного понимания процесса компиляции я рекомендую книгу Виталика "Zero to Hero Guide to SNARKs", а также обсуждение различных систем доказательств от Эли Бен-Сассона:

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

В целом, есть немного способов сделать это:

• Доказать непосредственно трассировку выполнения в EVM, преобразовав ее в верифицируемую схему;
• Создать пользовательскую виртуальную машину, преобразовать опкоды EVM в опкоды для этой виртуальной машины, затем доказывать корректность трассировки в этой пользовательской среде;
• Создать пользовательскую виртуальную машину, конвертировать Solidity в байткод вашей пользовательской ВМ (напрямую или с помощью пользовательского языка высокого уровня) и доказывать в вашей пользовательской среде.

Разберем сначала самый интуитивно понятный: доказательство трассировки выполнения в EVM - то, над чем сейчас работает команда Scroll (вместе с Privacy Scaling Group из Ethereum Foundation).

Чтобы это сработало, нам потребуется:

1. Спроектировать схему для некоторого криптографического накопителя (что позволит нам проверить, что мы верно считываем память и загружаем правильный байткод);
2. Спроектировать схему для связи байткода с реальной трассировкой выполнения;
3. Спроектировать схему для каждого опкода (что позволит нам доказать корректность чтения, записи и вычислений для каждого опкода).

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

Диаграмма ниже показывает, что теоретически единственное различие между Scroll и Ethereum заключается в фактической среде выполнения.

Важно заметить, что пока механизм Scroll поддерживает не все опкоды EVM, но они намерены со временем достичь паритета.

Очень круто этот вопрос обсудила команда Optimism, хотя и в контексте оптимистичных роллапов:

Для начала команда Optimism создала собственную виртуальную машину (Optimistic Virtual Machine, OVM) в качестве среды выполнения для своего роллапа.

OVM была "Ethereum-совместимой" и позволяла запускать модифицированный код Solidity, но несколько областей несоответствия на низком уровне приводили к тому, что инструменты Ethereum и сложный код часто приходилось переписывать.

В связи с этим Optimism перешла на "EVM-эквивалентность", где используется точная спецификация EVM напрямую, и сейчас разрабатывает первую EVM-эквивалентную систему доказательства.

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

К сожалению, основная инфраструктура EVM мало подходит для zk-роллапов.

Основная мера производительности роллапа — это количество "ограничений", необходимых для записи определенного вычисления в схему. Во многих случаях прямое отражение EVM приводит к огромным затратам.

Например, в EVM 256-битные целые числа, а zk-доказательства лучше всего работают над простыми полями.

Введение диапазона проверок для борьбы с несоответствующей арифметикой полей добавляет ~100 ограничений на каждый шаг EVM.

Схема хранения Ethereum по большей части опирается на keccak256, которая в 1000 раз больше в виде схемы, чем хэш-функция, подходящая для STARK (например, Poseidon, Pedersen).

Замена keccak создаст огромные проблемы совместимости для существующей инфраструктуры Ethereum.

В дополнение к этому, подписи на стандартной эллиптической кривой Ethereum чрезвычайно дороги для доказательства и проверки в сравнении с эллиптическими кривыми, дружественными SNARK/STARK.

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

Как минимум до тех пор, пока сама EVM не изменится и не станет более дружественной к SNARK (скорее всего, через несколько лет).

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

Polygon Hermez (недавно переименованная в Polygon zkEVM) — одна из команд, сосредоточенных на этом подходе.

Принцип построения zkEVM у Polygon — "эквивалентность на уровне опкода", что в целом похоже на подход Scroll.

Но в отличие от Scroll, альтернативная среда выполнения от Polygon ("zkExecutor") выполняет не опкоды EVM, а специально разработанные "zkASM" опкоды для оптимизации интерпретации EVM (т.е. уменьшения количества ограничений по сравнению с прямым доказательством в EVM).

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

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

В конце концов, нужно четко понять, что ваши программы выполняются не в zkEVM, который отражает EVM в схеме, а в альтернативной среде выполнения "zkExecutor", которая похожа, но отличается от самой EVM.

Смущает то, что команда позиционирует это как "zkEVM" и "EVM-эквивалентность", потому что из-за пользовательского интерпретатора zkASM, этот роллап на самом деле "EVM-совместим" в соответствии с определением от Optimism, приведенным выше.

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

Polygon заявила о совместимости "со 100% существующих инструментов Ethereum" и обязалась обеспечить соответствие JSON-RPC.

На это они ссылаются в своей документации и предлагают реализацию здесь.

На практике это заявление, скорее, выдача желаемого за действительное и сильно зависит от того, станет ли сам Ethereum более дружелюбным к SNARK.

То, что делает Polygon, обеспечивает более производительный роллап, чем у Scroll (конечно, в краткосрочной и среднесрочной перспективе), но при этом:

• Существенно больше пользовательского кода, поскольку потребовалось создать zkASM;
• Возможное требование к разработчикам модифицировать свой L1-код или инструментарий;
• Отход от Ethereum с течением времени потенциально больше.

Решениям выше требуется значительное время на разработку, чтобы "заставить EVM работать с zk-роллапами", а приоритет будет отдаваться совместимости, а не долгосрочной производительности и масштабируемости.

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

Именно такой подход выбрала компания StarkWare, создав StarkNet.

Это наиболее продвинутый на сегодняшний день роллап общего назначения.

В StarkNet используется пользовательская виртуальная машина для смарт-контрактов (Cairo VM) со своим собственным языком низкого уровня (Cairo).

И то и другое было создано специально для роллапов, нацеленных на смарт-контракты.

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

Команда Nethermind (в партнерстве со StarkWare) создала конвертер Warp, который преобразует произвольный код Solidity в байткод Cairo VM.

Цель Warp — позволить переносить популярные контракты Solidity в StarkNet.

Правда, на практике есть некоторые функции Solidity, которые Warp не поддерживает, включая низкоуровневые вызовы (полный список можно найти здесь).

Этот подход к созданию роллапа для смарт-контрактов обеспечивает "совместимость с Solidity": вы не выполняете программы внутри EVM и не поддерживаете совместимость с любыми другими интерфейсами Ethereum, но разработчики Solidity могут писать код, который будет использоваться в вашем роллапе.

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

Но и тут есть несколько недостатков:

• Во-первых, создать собственную виртуальную машину довольно сложно.

У команды Ethereum было больше 5 лет на устранение недостатков в EVM, и мы все равно часто видим обновления и исправления.

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

• Кроме того, поддержка Solidity благодаря конвертору чревата потенциальной потерей совместимости — если разработчики пишут контракты и в CAIRO, и в Solidity, то велика вероятность, что инструментарий для поддержки интерфейса между ними будет хрупким.

До сих пор основная часть проектов StarkNet была написана непосредственно на CAIRO, и их может быть не так-то просто совместить с будущими проектами Solidity.

• Наконец, и это, возможно, самое важное, команда StarkNet сейчас вообще не стремится к совместимости с другими компонентами Ethereum.

Они разрабатывают собственные клиенты API, библиотеки javascript и систему кошельков, что вынудит Ethereum-совместимые инструменты внедрять поддержку StarkNet вручную.

Это все очень сложно, но не невозможно. Выше мы уже говорили про успех Solana и что ее собственные стандарты поддерживаются некоторыми инструментами Ethereum, но все зависит от способности команды StarkWare привлечь разработчиков, которые будут не против переделывать.

Однако, если они добьются успеха, то команда StarkWare сможет повторить преимущество первого, которое есть у EVM, с помощью первой виртуальной машины для смарт-контрактов, оптимизированной под zk-роллапы.

Еще одна команда, работающая по этой стратегии, — zkSync.

Затем был создан специальный компилятор для компиляции Yul (промежуточный язык, который может быть скомпилирован в байткод для различных версий EVM, что-то типа низкоуровневого Solidity) в LLVM-IR для дальнейшей компиляции в инструкции для своей ВМ.

Похоже на то, что делает StarkWare, но в теории обеспечивает большую гибкость в отношении базового языка (правда, пока что поддерживается только Solidity 0.8.x).

В целом, их стратегия заключается в применении большего количества инструментов Ethereum, чем StarkNet.

И я жду, что их клиенты API и т.д. будут более "совместимы с Ethereum".

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

Это отличный пример использования пользовательской ВМ — вам не нужно ждать, пока Ethereum создаст новые функции!

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

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

Более того, как мы разобрали выше, чем сильнее вы стремитесь к совместимости с Ethereum, тем менее эффективной будет ваша программа в "верифицируемом формате".

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

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

С точки зрения опыта разработчиков у роллапа типа 3, в который вносится одно небольшое изменение в прикладной уровень, больше общего с роллапом типа 2, чем с роллапом типа 3, в который внесли крупные изменения в основной уровень, но без создания новой виртуальной машины, что сделало бы его типом 4.

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

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

Я считаю следующие определения наиболее четкими и последовательными:

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

Всем приходится идти на различные компромиссы: проще создавать, поддерживать и обновлять или более производительные, или более простая совместимость с существующими инструментами.

В конце концов, лидер будет определяться не только техническими возможностями, но и лучшим внедрением и маркетингом.

Тем не менее принятие правильных фундаментальных технических решений, несомненно, несет в себе существенные преимущества.

• Сможет ли команда Scroll, ревностно придерживающаяся спецификации EVM, легко реагировать на любые обновления EVM?
• Поможет ли более прагматичный подход другой команды быстрее выйти на рынок?
• Станет ли подход StarkWare, основанный на использовании виртуальных машин и конвертера, более надежным фундаментом для долгосрочного масштабирования?
• Будет ли другая команда учиться на ошибках, которые, несомненно, совершат первопроходцы в этой области, и опередит их?
  

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

Но перед тем, как предаваться мечтам, надо четко определить текущую готовность к разработке смарт-контрактов.

Любая команда будет позиционировать себя как "вот-вот захватит мир", но смарт-контракты "производственного уровня" на Ethereum появятся не раньше конца 2022 года, а то и в 2023 году.

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

В силу такого незрелого состояния, роллапы, созданные под конкретные приложения, пока остаются рабочими вариантами для разработчиков, которым нужен масштаб без ущерба для безопасности от Ethereum.

Более того, я полагаю, что даже после создания и внедрения роллапов общего назначения производительность, настраиваемость и надежность роллапов, заточенных под конкретные приложения, в обозримом будущем будут лучше для некоторых случаев использования (например, для бирж, майнинга/торговли NFT).

Несмотря на основную тематику этой статьи, речь идет не о совместимости в ущерб производительности экосистемы Ethereum!

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

Вот вам несколько критериев от меня:

• Комиссия

D чем будут оплачиваться комиссии? В нативном токене, или в ETH, или в какой-то сложной комбинации того и другого?

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

• Доказательства и секвенирование

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

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

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

• Самостоятельное хранение:

Главная идея zk-роллапов заключается в возможности масштабирования при сохранении безопасности Ethereum.

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

• Доступность данных

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

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

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

Роллапы для смарт-контрактов — невероятно интересная часть дорожной карты масштабирования Ethereum.

Разнообразные компромиссы, на которые идут эти роллапы в своих отношениях с существующим набором инструментов Ethereum, — это удивительное свидетельство разнообразия экосистемы разработчиков Ethereum.

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

Пока что большая часть проектов продает свое видение. То есть возможности через 3+ лет, а не то, чего можно достичь сегодня (или даже через 12 месяцев). Это может сильно запутать людей.

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

• В чем заключаются точные различия среды выполнения между L1 и L2? Какие опкоды будут изменены на L2? Будут ли какие-то характеристики виртуальной машины (например, структура комиссий) отличаться от L1?
• Где найти формальную спецификацию вашей пользовательской ВМ, и в чем она более/менее производительна по сравнению с другими вариантами?
• Какие изменения будут внесены в другие интерфейсы Ethereum (например, клиенты API, библиотеки) этим роллапом, что приведет к сбоям в работе инструментов Ethereum?
• Когда запуск роллапа в тестнете? В основной сети? Может ли он поддерживать устойчивую пропускную способность в 1000+ пользовательских контрактов в секунду?
• Когда вы видите поддержку полного самостоятельного хранения активов пользователей, и как это выглядит в контексте роллапа общего назначения?
• Как только роллап выйдет в тестнет, то на эти вопросы появятся ответы. А пока, я бы хотел, чтобы разработчики публиковали больше технических деталей о том, на какие компромиссы им пришлось идти в реализации своего решения, и как это повлияет на разработчиков смарт-контрактов и инструментов.

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

Оригинал статьи на ENG

Мы с командой анализируем, рассказываем о крипте и развиваем сообщество с 2017 года. Создали десяток реальных юзкейсов и готовы делиться всем опытом с тобой. Заходи в наши Telegram-каналы и читай полезную аналитику каждый день...

• TT Analytics
• TT Academy
• TT Ventures