Дорожная карта Ethereum Rollup

Как бы выглядела Rollup-ориентированная дорожная карта Ethereum?

На прошлой неделе команда Optimism объявила о запуске первого этапа их testnet’а, и представила дорожную карту выхода на mainnet.

И они не единственный такой проект: Fuel также движется к созданию своего testnet’а, а Arbitrum уже располагает собственным.

В мире ZK rollup, проекты Loopring, Zksync и Deversifi, базирующиеся на технологии Starkware, работают в mainnet.

И у них уже есть пользователи. С mainnet бета-версией сети OMG, plasma также движется вперед.

Тем временем,

Стоимость транзакций (газа) в сети первого уровня (eth1) поднимается к новым значениям, вплоть до уровня при котором некоторые нефинансовые децентрализованные приложения (dapps) вынуждены закрываться, а другие работать только в testnet.

Дорожная карта сетей второго уровня (eth2) предлагает масштабируемость, и ранние фазы eth2 уже почти готовы,

Однако масштабируемость базового уровня (base-layer) для приложений появится только на последней крупной фазе eth2, которая наступит через несколько лет.

По иронии судьбы, возможность использования eth2 в качестве data-availability  уровня для rollup появится на первой фазе, задолго до того, как eth2 станет доступен к использованию в "традиционных" приложениях первого уровня (L1).

Все эти факты в совокупности приводят к следующему выводу:

Экосистема Ethereum, скорее всего, в ближайшем и среднесрочном будущем полностью сосредоточится на решении Rollup (а так же на Plasma и State Channels*) в качестве стратегии масштабирования.

*Plasma и State Channels - решения для масштабирования сети Ethereum

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

В некоторых аспектах полученные нами выводы противоречат текущему пути развития.

Давайте разберем эти выводы.

Краткосрочная перспектива: Развитие Eth1 для Rollups

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

А не на эффективность on-chain вычислений или операций ввода-вывода.

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

И любое увеличение скорости выше текущих ~60 кБ/сек будет способствовать дальнейшему увеличению масштабируемости Rollup’ов.

Есть некоторые факторы, которые будут по-прежнему важны на базовом уровне:

• EIP 2929, для обеспечения безопасности блокчейна от DoS-атак при текущем уровне газа
• EIP 1559, как для сжигания ETH, так и для облегчения отправки транзакций, которые почти наверняка попадут в следующий блок (rollup которых, все еще зависит от подтверждений)
• Новые прекомпиляции эллиптических кривых для полной поддержки всех вариантов использования ZK-Rollups
• Переход от шестнадцатеричного к двоичному древу и другие изменения для улучшения поддержки stateless-клиентов (поскольку stateless-клиенты ценны независимо от того, как используется блокчейн)

Account Abstraction (AA) в каком-то смысле менее важно, поскольку может быть реализовано на L2 независимо от того, поддерживает ли его L1. Другие "умные функции базового уровня" также становятся менее важными.

Клиенты Eth1 могут быть перепрофилированы в Optimistic rollup-клиентов.

Optimistic rollups по-прежнему должны иметь полные ноды, и если у rollup внутренние правила перехода состояний похожи на Ethereum с небольшими модификациями (например, это цель проекта Optimism), то существующий код может быть перепрофилирован для запуска этих полных нод.

Работа по отделению механизма консенсуса от механизма перехода состояния уже ведется в контексте слияния сетей eth1+eth2 , что также может помочь в достижении этой цели.

Обратите внимание, что такие проекты, как TurboGeth, по-прежнему очень важны, только наибольшую пользу от них получат не клиенты базового уровня eth1, а высокопроизводительные rollup-клиенты.

Краткосрочная перспектива: Адаптация инфраструктуры для Rollups

В настоящее время доминируют сети первого уровня: пользователи держат учетные записи на L1, имена ENS на L1, приложения полностью функционируют на L1 и т.д.

Все это должно измениться.

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

Из этого следует несколько вещей:

1. ENS должна поддерживать регистрацию и перенос имен на L2; одно из предложений, как это сделать, можно найти здесь

2. L2-Протоколы должны быть встроены в кошелек, а не в браузер, как у dapps. В настоящее время интеграция L2 в dapps/quasidapps (например, интеграция zksync в Gitcoin) требует от пользователя полного доверия к dapp, что значительно снижает безопасность по сравнению со статус-кво.

В идеале мы хотим сделать L2 частью самого кошелька (Metamask, stats и т.д.), чтобы мы могли сохранить текущую модель доверия.

Эта поддержка должна быть стандартизирована, чтобы приложение, поддерживающее zksync-платежи, также сразу поддерживало zksync-inside-Metamask, zksync-inside-Status и т.д.

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

4. Более четко стандартизировать Yul или что-то подобное в качестве промежуточного языка компиляции. EVM базового уровня Ethereum и OVM, используемый в Optimism Rollup, немного отличаются по цели компиляции, но оба могут быть скомпилированы из Solidity.

Чтобы создать экосистему с разными целями компиляции, но в то же время избежать монокультуры Solidity и допустить к использованию несколько языков,

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

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

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

Преимущества Rollup-ориентированности в контексте экономической устойчивости

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

Часть этой суммы может быть покрыта организациями, которые финансируют проекты, направленные на общественное благо, - например Gitcoin Grants или Ethereum Foundation.

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

Однако проекты второго уровня (L2), запускающие собственный токен, набирают достаточное финансирование - при условии, конечно, что токен подкреплен реальной экономической ценностью (т.е. потенциальные будущие сборы, которые получит L2).

И эти L2-протоколы имеют возможность получать сборы/MEV, которые могут использоваться для финансирования развития, прямо или косвенно (путем поддержки токена, финансирующего развитие).

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

[представьте себе ACD-звонки от людей, пытающихся договориться о том, кто сколько денег заслуживает]

Но L2-проекты, у которых есть свои собственные механизмы финансирования общественных благ (и/или участвующие в Gitcoin Grants), вызывают гораздо меньше споров.

Таким образом,

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

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

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

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

Долгосрочная перспектива

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

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

• Сегодня Ethereum имеет скорость ~15 TPS (транзакций в секунду)
• Если все перейдут на Rollups, то вскоре мы достигнем значения ~3000 TPS.
• Когда наступит фаза 1, и Rollups перейдут на шардированные (shard) цепочки eth2 для хранения данных, мы поднимемся до теоретического максимума в ~100000 TPS.
• В конце концов, наступит фаза 2, которая даст нам sharded-блокчейны eth2 с нативными вычислениями, что даст нам уровень в ~1000-5000 TPS.

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

Это подразумевает подход "фаза 1,5 и готово" к eth2, когда базовый уровень отступает и сосредотачивается на качественном выполнении нескольких вещей - а именно, консенсуса и доступности данных.

На самом деле, это может быть лучшей позицией для eth2, потому что sharding data availability гораздо безопаснее, чем sharding вычислений EVM.

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

Процесс data availability sampling безопасен при асинхронности.

[Если этот процесс осуществляется с помощью ZKPs или полиномиальных обязательств]

Это поможет Ethereum отличиться более сильной моделью безопасности по сравнению с другими шардированными (sharded) L2-цепочками, которые все движутся в направлении шардированного исполнения в той или иной форме.

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

На чем может сосредоточиться eth2 в долгосрочной перспективе?

• Разделение времени формирования блока на разные шарды таким образом, чтобы в любой момент времени на каком-то шарде всегда было запланировано создание блока в течение нескольких сотен миллисекунд. Это позволит Rollup’ам, работающим на нескольких шардах, иметь сверхнизкую задержку без риска того, что сам блокчейн будет иметь сверхнизкую задержку.
• Улучшение и укрепление алгоритма консенсуса
• Адаптация EVM для большей поддержки fraud-proof верификации (например, это может подразумевать некую "рамочную" функцию, которая предотвращает выход кода из sandbox или позволяет переназначить SLOAD/SSTORE на использование чего-то другого, кроме хранилища аккаунтов, в качестве источника данных).
• Повсеместное добавление технологии ZK-SNARK

Компромиссные предложения

Если вы не настроены “идти до конца" в направлении "фаза 1.5 и готово", есть естественный компромиссный путь:

Иметь небольшое количество шардов исполнения (например, 4-8) и гораздо больше шардов данных.

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

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

Например, для перемещения между Rollups, представления fraud proofs, представления ZK proofs в ZK rollups, публикации корневых контрактов на токены ERC20 (конечно, большинство пользователей будут жить в Rollups, но базовый контракт тоже должен где-то жить...) и т.д.

И это все равно будет большой потерей UX, если все это будет стоить по $140 за транзакцию.

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

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

Сегодня проверка блоков eth1 в среднем занимает ~200-500 мс каждые 13 секунд, так что проверка восьми потоков такого исполнения в течение коротких периодов времени вполне осуществима.

Можно представить, что у клиентов будет политика "если сетевая задержка низкая или комитеты заполнены на >80%, полагайтесь на fraud proofs и комитеты, в исключительных случаях проверяйте все шарды напрямую".

Оригинал находится здесь.

Переведено и адаптировано командой Telegram-канала

@Ghost_In_The_Block