*Переслать оригинальное название：Исследование моста Canonical Ethereum Bridge и системы доказательств Eclipse

Обзор нашего моста Canonical

Eclipse состоит из трех слоев:

1. Исполнение: Форк клиента Solana Labs(v1.17) для выполнения транзакций SVM
2. Расчеты: Наш канонический мост, определяющий правило выбора вилки в Eclipse, существует на Ethereum, где также будут представлены доказательства мошенничества
3. Доступность данных: Eclipse публикует данные, необходимые для создания доказательств мошенничества, в виде блоков данных на Celestia

На схеме ниже показано, как взаимодействуют эти модули:

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

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

Внесение средств через родной мост Eclipse для Ethereum

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

1. Пользователь вызывает контракт Eclipse's Deposit Bridge на Ethereum
2. Находясь внутри SVM-исполнителя Eclipse [1], ретранслятор [2] наблюдает за вкладом пользователя и адресом назначения.
3. Далее ретранслятор вызывает программу моста SVM, которая отвечает за передачу депозита пользователя на соответствующий адрес назначения
4. Релевер проверяет транзакцию депозита с помощью клиента zk-light (будет реализовано)
5. Наконец, блок, содержащий последующую транзакцию перевода средств после депонирования, завершается и публикуется с помощью плагинаSolana Geyser Plugin

На схеме ниже показано взаимодействие между Ethereum, Celestia и исполнителем SVM во время потока вкладов, описанного выше:

Публикация слотов Eclipse в Celestia в виде блоков данных

Ниже приводится схема публикации партий слотов Eclipse в Celestia в виде блоков данных:

1. Исполнитель SVM публикует каждый слот Eclipse в очередь сообщений через Geyser
2. Исполнитель SVM отправляет партии слотов Eclipse в Celestia в виде блоков данных
3. Набор валидаторов Celestia создает обязательства для представленных блоков данных, которые могут быть использованы для подтверждения включения транзакции в цепочку Eclipse против корня данных.
4. Корни данных, содержащиеся в заголовке каждого блока Celestia, передаются мостовому контракту Eclipse на Ethereum через Blobstream.

Приведенная ниже диаграмма от Celestia объясняет, как обязательства по данным в данном блоке Celestia хранятся в заголовке блока:

Вывод средств и предоставление доказательств мошенничества в Eclipse's Ethereum Bridge

Подобно другим L2, использующим доказательства мошенничества (Arbitrum, Fuel и многие другие), вывод средств из Eclipse требует периода испытания, в течение которого верификаторы могут представить доказательства мошенничества в случае недействительного перехода состояния:

1. Регулярно исполнитель SVM публикует в Ethereum обязательство на эпоху (заранее определенное количество партий) слотов Eclipse вместе с обеспечением
2. Мостовой контракт Eclipse проводит несколько базовых проверок, чтобы убедиться, что размещаемые данные правильно сформированы (описано в разделе "Проектирование защиты от мошенничества")
3. Если отправленный пакет проходит эти базовые проверки, существует предопределенное окно, в течение которого верификаторы могут размещать доказательства мошенничества в случае, если пакетное обязательство подразумевает недопустимый переход состояния
4. Если верификатор размещает успешное доказательство мошенничества, он выигрывает залог исполнителя, размещенная партия отклоняется, а каноническое состояние Eclipse L2 откатывается к последнему правильному пакетному обязательству. В данном случае руководство Eclipse будет иметь возможность избрать нового душеприказчика.
5. Если по истечении времени вызова не удалось доказать факт мошенничества, исполнитель возвращает свой залог вместе с вознаграждением
6. Следовательно, теперь мостовой контракт Eclipse завершит все операции по выводу средств, которые были включены в завершенную партию.

Дизайн с защитой от мошенничества

В этом заключительном разделе мы подробно расскажем о дизайне системы доказательства мошенничества в Eclipse, вдохновленной Анатолием Яковенко и Джоном Адлером. Как правило, для любого доказательства мошенничества верификатор должен:

1. Определите транзакцию, содержащую недопустимый переход состояния
2. Предоставьте входы в указанную транзакцию с недопустимым переходом состояния
3. Продемонстрируйте, что повторное выполнение указанной транзакции с заданными входными данными приводит к выходу, который не равен тому, что было зафиксировано на цепи

В случае Eclipse, (1) Celestia мерклизирует блобы партий блоков, которые размещает SVM-исполнитель Eclipse, что позволяет доказать включение транзакций с помощью свидетелей Меркла. Что касается (2), то в отличие от EVM-ориентированных L2, которые размещают корень Меркла в глобальном дереве состояний, по соображениям производительности Eclipse не обновляет глобальное дерево состояний от транзакции к транзакции, но ниже мы более подробно объясним, как мы обеспечиваем корректность вводимых данных. Наконец, в случае (3) верификатор Eclipse генерирует zk-доказательство вывода(ов) для данной транзакции, в отличие от интерактивного игрового подхода к верификации, распространенного в L2 на базе EVM.

Все транзакции Eclipse можно представить как получение списка входных счетов, выполнение транзакции и получение списка выходных счетов:

Критическое наблюдение для нашего проекта доказательства мошенничества заключается в том, что при выполнении транзакции всегда так, что любой S_InputAccount должен был быть S_OutputAccount какой-то предыдущей транзакции. Это позволяет нам ссылаться на последнюю транзакцию в цепочке, которая произвела данный входной счет, вместо того, чтобы предоставлять свидетеля Меркла к глобальному дереву состояний. В результате нашей разработки мы ввели дополнительные типы обвинений в мошенничестве, такие как ссылка на то, что предыдущая транзакция не была действительной или входной счет уже был "потрачен" какой-то более поздней транзакцией. Ниже мы описываем этот процесс более подробно:

Входы транзакций, опубликованные в Celestia

1. Данные транзакции (публикуются секвенсором)
2. Данные транзакции (публикуются исполнителем SVM), которые содержат следующее:
   1. Количество транзакций [3]
   2. Расположение пространства имен Celestia для данных транзакции
   3. Хэш счета [4] для каждого входа, с подсчетом транзакций, полученных в результате каждого
   4. Список используемых системных параметров и значение каждого из них, с указанием количества транзакций, приходящихся на каждый из них (если применимо) [5]
   5. Выходные данные транзакции, если транзакция прошла успешно; в противном случае, индикатор того, что транзакция не удалась (либо потому, что не удалось разобрать, либо потому, что не удалось выполнить)

Пакетные обязательства, опубликованные на мосту Ethereum Bridge

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

1. Местонахождение пространства имен Celestia для данных транзакции последней транзакции, включенной в пакет
2. Пространство имен Celestia, в котором находятся данные о выполнении [6] всех включенных транзакций
3. Список депозитов, снятий и переопределений, каждый из которых сопровождается подсчетом транзакций, связанных с транзакцией Eclipse

Критерии недействительной партии

Как объяснялось выше, существует несколько способов, с помощью которых партия может быть признана неправильной:

1. Одно из связанных мест пространства имен Celestia имеет неправильную форму или не указывает на данные требуемого типа
2. На Celestia есть транзакция без связанных с ней данных о выполнении, что может быть вызвано двумя причинами:
   1. Транзакция, которая должна была быть самой последней в пакете, не имеет связанных с ней данных о выполнении.
      1. В таком случае верификатор проверяет, так ли это, а мостовой контракт Ethereum проверяет, что последняя запись в списке данных о выполнении не соответствует правильным данным о транзакции.
   2. Данные о выполнении другой транзакции отсутствуют
      1. Верификатор публикует в пространстве имен Celestia местоположение данных транзакции нарушающей транзакции, а также предыдущей и последующей транзакций в том порядке, в котором они были успешно выполнены. После этого мостовой контракт проверяет, что эта транзакция была пропущена
3. Существует транзакция, данные о выполнении которой неверны, что может быть вызвано следующим:
   1. Счетчик транзакций, связанный с хэшем учетной записи или sysvar, не дает заявленного результата.
      1. В этом случае верификатор публикует в пространстве имен Celestia местоположение данных о выполнении данной транзакции с соответствующим подсчетом, а мостовой контракт проверяет, не является ли данное значение неверным.
   2. Количество транзакций, связанных с хэшем учетной записи или sysvar, устарело
      1. Верификатор публикует в пространстве имен Celestia местоположение данных выполнения для более новой транзакции, изменяя значение, о котором идет речь, а мостовой контракт проверяет, что это действительно более новая транзакция.
   3. Выходные данные транзакции неверны, или транзакция использует входные данные, которые не указаны в списке:
      1. В этом случае необходимо zk-доказательство правильности выполнения транзакции или zk-доказательство того, что транзакция использует вход, который не указан в списке. Это можно получить двумя способами:
         1. Верификатор публикует доказательство, или
         2. Верификатор публикует индекс транзакции, которая считается мошеннической, и мостовой контракт Eclipse использует его, чтобы запросить zk-доказательство от Bonsai из RISC Zero.
   4. Депозит от Ethereum был внесен более N партий назад, но в списке транзакций (включенном в пакетное обязательство, размещенное в бридж-контракте) нет соответствующего депозита для N прошедших партий. Или же в списке транзакций есть депозит, но нет связанной с ним транзакции по депозиту Ethereum, или транзакция существует, но уже была включена в другую партию Eclipse.
      1. Бриджевый контракт во всех этих случаях может определить, что это произошло, и считать такую партию недействительной
   5. Выполнено пополнение или снятие средств без соответствующей записи в списке транзакций
      1. В этом случае верификатор сообщает местоположение пространства имен Celestia для данных выполнения, и мостовой контракт проверяет этот факт, чтобы признать транзакцию недействительной
   6. В списке транзакций есть депозит или снятие средств, связанная с ними транзакция Eclipse не выполняет ожидаемых действий или количество транзакций не входит в ожидаемый диапазон количества транзакций. В этом случае произойдет одно из следующих событий:
      1. Мост автоматически определит, что это так, и откажет в приеме соответствующей партии.
      2. Верификатор замечает недействительный переход состояния и публикует доказательство ошибочной транзакции, которое затем проверяется мостовым контрактом.

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

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

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

Чтобы принять участие в работе Eclipse Testnet, следуйте нашим инструкциям здесь. Вы можете связаться с нами в Twitter или Discord, чтобы задать конкретные вопросы о нашем Testnet, мосте или технические вопросы.

Сноски

[1]: Узел, который вычисляет результаты транзакций SVM и применяет конечный результат к новому состоянию Eclipse

[2]: Оператор, который передает события в цепи между Ethereum и Eclipse.

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

[4]: Учетные записи SVM могут быть представлены уникальным хэшем. Единственный способ изменения этого хэша - транзакция.

[5]: Чтобы сделать это без чрезмерного хэширования, мы будем отслеживать каждую выполненную программу, чтобы увидеть, какие части каждой используемой sysvar были на самом деле доступны. Это возможно, но потребует изменения BPF-интерпретатора Solana.

[6]: Сюда входят данные о попытках транзакций, которые не удалось выполнить.

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

1. Эта статья перепечатана из [[зеркало]], Все авторские права принадлежат автору оригинала[Eclipse]]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.