TL;DR: Мы рады наконец-то объявить архитектуру Eclipse Mainnet: Самый быстрый L2 в Ethereum, работающий на базе SVM*.*

Eclipse Mainnet - это L2 общего назначения, который сочетает в себе лучшие части модульного стека:

• Расчеты: Ethereum - Eclipse будет осуществлять расчеты в Ethereum (т. е. закрепленный валидационный мост будет находиться на Ethereum) и использовать ETH в качестве своего газового токена.

• Исполнение: Виртуальная машина Solana (SVM) - Eclipse будет использовать высокопроизводительную SVM в качестве среды выполнения.

• Доступность данных: Celestia - Eclipse будет размещать свои данные в Celestia для масштабируемой доступности данных (DA).

• Доказательство: RISC Zero - Eclipse будет использовать RISC Zero для ZK-доказательств мошенничества (без сериализации промежуточных состояний!).

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

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

Исполнение: Скорость и масштабирование Solana

Eclipse Mainnet будет использовать лучшую в своем классе среду исполнения Solana. Это дает огромные преимущества:

Оптимизированное параллельное выполнение

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

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

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

Локальные рынки гонораров

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

Локальные рынки вознаграждений возможны благодаря уникальной распараллеливаемой среде выполнения Solana. Попытка реализовать локальные рынки вознаграждений для горячих точек состояния в EVM с помощью эвристики (т. е. без предварительного объявления доступа к состоянию) приведет к неэффективности и вероятным векторам атак.

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

Управление ростом штата

Еще до того, как EVM столкнется с последовательным выполнением как с узким местом, рост состояния является его гораздо более серьезным узким местом.

Поскольку для состояния не существует дерева Меркла, Solana не несет накладных расходов на обновление дерева Меркла при каждом обновлении состояния. Вместо этого после каждой эпохи (~2,5 дня) происходит мерклинг всего состояния. Это намного дешевле, чем мерклизация в реальном времени (как в EVM).

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

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

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

Совместимость с EVM

Neon EVM - это EVM, работающий как смарт-контракт, который может быть развернут на любой сети SVM. Это обеспечивает полную совместимость EVM с Eclipse Mainnet (включая поддержку байткода EVM и Ethereum JSON-RPC) и большую пропускную способность по сравнению с однопоточными EVM. Поскольку каждый экземпляр Neon EVM имеет свой собственный локальный рынок сборов, приложения могут просто развернуть свой собственный контракт, чтобы получить преимущества сети приложений без фрагментации UX, безопасности или ликвидности.

Кроме того, компилятор Solang позволяет компилировать код смарт-контрактов Solidity в байткод SVM.

MetaMask Snaps

Переход пользователей EVM на не-EVM сети исторически был серьезным препятствием, но недавно представленные привязки Metamask Snaps собираются разрушить этот барьер. Пользователи EVM могут продолжать использовать MetaMask без необходимости менять кошелек. UX сопоставим с взаимодействием с любой сетью EVM, благодаря вкладу Driftв создание отличной реализации MetaMask Snap с открытым исходным кодом. Пользователи Eclipse Mainnet смогут взаимодействовать с приложениями нативно в MetaMask или использовать кошелек на основе Solana, такой как Salmon.

Вот краткий обзор UX от Drift:

Firedancer

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

Безопасность

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

Более легкое тестирование

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

Расчеты: Безопасность и ликвидность Ethereum

Как и в случае с сегодняшними крупными роллапами, расчеты в Eclipse Mainnet будут производиться в Ethereum. Конкретно это означает, что наш валидационный мост на Ethereum будет непосредственно закреплен в Eclipse. Узлы Eclipse будут обращаться к этому мосту для определения «канонической сети». Мост обеспечивает правильное упорядочивание для Eclipse.

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

Из-за этих свойств безопасности валидиумы и оптимумы часто называют «Ethereum L2». L2BEAT определяет L2 как «сеть, которая полностью или частично получает свою безопасность от первого уровня Ethereum, так что пользователям не приходится полагаться на честность валидаторов L2 для обеспечения безопасности своих средств».

Ethereum settlement признает важность, которую активы на основе Ethereum, вероятно, будут играть в DeFi и NFT экономиках Eclipse Mainnet. ETH - это лучшие децентрализованные деньги, которые явно предпочитает большинство пользователей, поэтому мы также будем использовать ETH в качестве нашего газового токена. В долгосрочной перспективе абстракция платы позволит пользователям платить в любом токене по их выбору (например, USDC). На данный момент у Eclipse Mainnet нет планов по выпуску собственного токена.

Доступность данных: Пропускная способность и проверяемость Celestia

Eclipse Mainnet будет использовать Celestia для обеспечения доступности данных (также известной как публикация данных или публикация данных). Celestia является давним партнером Eclipse по экосистеме.

Целевая пропускная способность и плата за услуги Eclipse Mainnet, к сожалению, не поддерживаются текущей пропускной способностью Ethereum. Это останется неизменным даже после реализации EIP-4844 (он же «Прото-данкшардинг»), который обеспечивает в среднем ~0,375 МБ blobspace на блок (с ограничением ~0,75 МБ на блок).

• Для переводов ERC-20 с базовым сжатием (~154 байта на транзакцию) это означает ~213 TPS для всех ролловеров вместе взятых.

• Для свопов со сжатием (~400 байт на транзакцию) это составляет ~82 TPS для всех ролловеров вместе взятых.

Для сравнения, Celestia будет запущена с блоками размером 2 МБ в конце этого года. Ожидается, что вскоре после запуска объем Blobspace увеличится до 8 МБ, как только появится достаточное количество легких узлов выборки доступности данных (DAS) и сеть станет стабильной. Узлы DAS выполняют две важнейшие функции:

• Позволяют пользователям самостоятельно убедиться в том, что данные блока Eclipse стали доступны

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

Ожидается, что Celestia станет первым уровнем DA, который будет запущен с DAS в производстве. Это контрастирует с традиционными комитетами доступности данных (DAC), которые вновь вводят предположения о честности комитета без проверки пользователем (подобно существующим монолитным блокчейнам).

Для пользователей, которые переводят свои средства из Ethereum Mainnet в любую сеть, использующую внесетевые DA, существует неотъемлемое предположение о безопасности. В частности, технически возможно, чтобы валидаторы Celestia скрывали данные о транзакциях, но утверждали мосту Ethereum, что эти данные доступны. На практике консенсус Celestia, основанный на доказательстве доли, означает, что утаивание данных на самой Celestia является режущим, что делает этот риск нереальным, на наш взгляд.

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

Обратите внимание, что некоторые рассматривают onchain Ethereum DA как требование, чтобы быть настоящим «L2» здесь по причинам, описанным выше. Мы придерживаемся более распространенной терминологии L2, приведенной ранее, и хотим четко обозначить соображения безопасности.

Мы также намерены следить за прогрессом Ethereum в масштабировании DA после EIP-4844. Продолжают появляться новые интересные исследования, которые потенциально могут предложить высокую пропускную способность DA раньше, чем предыдущие идеи (которые используют более продвинутые распределенные хэш-таблицы). Если Ethereum предложит большее масштабирование для Eclipse в интересах наших пользователей, мы оценим возможность перехода на Ethereum DA.

Доказательства: RISC Zero ZK Доказательства мошенничества (без промежуточной сериализации состояний!)

Наше доказательство будет похоже на SIMD-доказательство мошенничества SVM Анатолия, которое само по себе похоже на идею Джона Адлера о том, что сериализация состояний - это дорого, и ее можно избежать.

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

На высоком уровне доказательство ошибок требует:

1. Обязательства по входу для транзакции,

2. сама транзакция, и

3. Доказательство того, что повторное выполнение транзакции приводит к выходу, отличному от того, который был указан в сети.

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

Существует два возможных типа основных неисправностей:

1. Неправильные выходные данные - в этом случае верификатор предоставляет ZK-доказательство правильных выходных данных на сети. Мы используем RISC Zero для создания ZK-доказательств выполнения SVM, продолжая нашу предыдущую работу по доказательству выполнения байткода BPF. Это позволяет нашему расчетному контракту гарантировать корректность без необходимости запускать сами транзакции на сети.

2. Некорректные входы - в этом случае верификатор публикует на onchain ссылку на исторические данные, показывающие, что состояние входа не соответствует заявленному. Используя квантовый гравитационный мост Celestia, наш расчетный контракт гарантирует, что эти исторические данные действительно доказывают мошенничество.

Почему Eclipse, почему Ethereum, почему сейчас

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

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

• высокопроизводительные распараллеленные виртуальные машины (например, SVM)

• Масштабирование DA с поддержкой легких узлов DAS (например, Celestia).

• Прогресс в инфраструктуре доказательства, позволяющий реализовать его в любом месте (например, RISC Zero).

• Повышение переносимости кода (например, Neon и Solang) и пользователей (например, MetaMask Snaps) в разных экосистемах.

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

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

Настройки на уровне консенсуса могут быть невероятно ценными для некоторых приложений (например, dYdX v4), и мы с удовольствием помогаем командам запускать роллапы для конкретных приложений.

Однако таких случаев немного. Именно поэтому большинство новых роллапов по-прежнему являются просто ванильными форками EVM. Проблемы разработчиков не решаются фрагментацией UX на большее количество сетей. Основным сценарием использования миллиона сетей сегодня часто оказывается запуск еще миллиона токенов. Спрос на полнофункциональную кастомизацию просто не существует сегодня для подавляющего большинства сценариев использования.

Даже если бы реальный спрос существовал, инфраструктура, необходимая для поддержки множества сетей приложений с конкурентоспособным UX, находится на расстоянии нескольких лет (если она вообще когда-нибудь достигнет этого уровня). Суперчейн Optimism (стек OP), гиперблокчейны zkSync (стек ZK), сети Orbitrum и так далее - все они имеют мультичейн видение с общей инфраструктурой. Это должно обеспечить более плавный UX при работе между сетями в одной экосистеме (например, между двумя сетями в рамках Superchain) по сравнению с полностью изолированными сетями (например, между Ethereum и Solana).

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

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

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

Это заблуждение возникает из-за того, что в сегодняшних роллапах в основном используется ванильный однопоточный EVM без изменений, чтобы воспользоваться ранними сетевыми эффектами. В результате мы часто видим, как «выделенное блочное пространство» приводится в качестве причины для развертывания специфического для приложений роллапа. Эти сумасшедшие NFT-майнеры не должны повышать цены на все остальные приложения в вашей сети, но ответ не в том, чтобы пойти и создать свою собственную сеть. Это все равно что использовать кувалду, чтобы расколоть арахис. Вы идете на болезненные и ненужные компромиссы (сложность, стоимость, худший UX, фрагментированная ликвидность и т. д.). Оптимальное решение невероятно очевидно - просто используйте распараллеленную VM с локальными рынками комиссий для государственных горячих точек. Это именно то, что предлагает SVM.

Ethereum - интеллектуальный, социальный и экономический центр криптовалют. Его ахиллесовой пятой было масштабирование. Масштабирование DA все еще находится в процессе разработки, а существующие среды исполнения L2 не могут конкурировать с новыми инновациями, такими как SVM. Мы опасаемся, что в нынешнем виде экосистема Ethereum будет застигнута врасплох любым резким ростом активности. Однопоточные EVM и ограниченный DA быстро приведут к возобновлению высоких сборов, только на этот раз на ролловеры.

Мы считаем, что Eclipse Mainnet - это очевидное решение: объединение производительности Solana с безопасностью, проверяемостью и сетевыми эффектами дорожной карты, ориентированной на роллапы.

Размышления на прощание

Прелесть Ethereum в том, что он питается инновациями. Дорожная карта, ориентированная на роллапы, является олицетворением этого, делегируя исполнение и инновации свободному рынку. У L2 есть невероятная возможность использовать сетевые эффекты Ethereum и гарантии расчетов, экспериментируя с лучшими новыми средами исполнения. Eclipse Mainnet является естественным воплощением этого видения.

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

Чтобы принять участие в проекте, свяжитесь с нами по адресу team@eclipse.builders для получения инструкций по тестированию сети.