Особая благодарность Джону Шарбонно и Конору МакМенамину за рецензирование этой статьи.

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

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

Правила подтверждения: последовательность против доступности

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

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

• Согласованность (безопасность): любые два представления узлов являются согласованными при разделении сети.
• Доступность (liveness): транзакции продолжают попадать в бухгалтерскую книгу в течение некоторого времени даже после того, как значительная часть узлов перестает участвовать в протоколе.

Теорема CAP говорит нам о том, что невозможно разработать алгоритм консенсуса, который оставался бы одновременно последовательным при разделениях сети и доступным при динамическом участии: если происходит серьезное разделение сети, узлы могут либо решить продолжать производить блоки и потерять последовательность, либо остановиться и потерять доступность. У узлов нет возможности отличить, что другие просто находятся вне сети (динамическое участие) или активны, но недоступны (разделение сети), и поэтому невозможно действовать по-разному.

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

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

Правила подтверждения в Ethereum

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

При благоприятных сетевых условиях Ethereum также стремится обеспечить гарантии согласованности через конечность, используя протокол Casper FFG. Финальность - это самое сильное правило подтверждения, которое только возможно, при этом узлы имеют жестко закодированное правило никогда не переформировывать финализированные блоки.

Финализированная бухгалтерская книга (зеленая) всегда является префиксом реальной бухгалтерской книги (синяя).

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

Пользователи могут выбрать, использовать ли им Casper FFG в качестве самого безопасного правила подтверждения или быть более живыми, полагаясь на LMD GHOST. Правила подтверждения для LMD GHOST, подобно правилу k-подтверждения в Биткойне, могут быть более сложными, чем просто проверка того, включена ли транзакция в бухгалтерскую книгу, как указано в правиле подтверждения Safe Block.

Правила подтверждения при сворачивании

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

Свертывание данных транзакций

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

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

Свертывание различий состояний

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

Методы агрегирования доказательств предлагают решение этого компромисса между временем подтверждения и амортизацией затрат: даже если в рулонах наблюдается минимальная активность, они все равно могут выиграть от амортизации за счет включения транзакций из более активных рулонов в одно доказательство. Примером такого подхода является SHARP от Starkware, в настоящее время объединяющий доказательства из Starknet, Paradex и StarkEx, такие как dYdX и даже Validiums.

Где все становится сложнее

Спецификация производных рулонов

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

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

В цепочках OP Stack время блока составляет 2 секунды, в результате чего каждый блок Ethereum состоит из 6 блоков. Эта группировка из 6 блоков между блоками Ethereum называется "эпохой". Сообщения L1-to-L2, переданные через L1, включаются в первую часть первого блока соответствующей эпохи для данного блока L1. Хотя эти транзакции можно считать подтвержденными, не дожидаясь окончания окна последовательности, поскольку их порядок в бухгалтерской книге L2 после создания известен, важно отметить, что узлы не начнут вычислять блоки, содержащие эти сообщения, если предшествующая партия отсутствует. Это происходит потому, что состояние не может быть вычислено без полной последовательности, и поэтому корни состояний также не будут опубликованы на L1.

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

Разрешенные функции

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

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

То же самое может относиться и к роллапам, публикующим различия в состоянии: zkSync Era и zkSync Lite имеют трехступенчатый процесс публикации различий в состоянии: сначала они фиксируют данные без каких-либо доказательств, затем предоставляют доказательства, а затем, после 24-часовой задержки, корень становится доступным для выполнения, чтобы обработать снятие средств. В теории, когда предоставляется доказательство, порядок транзакций фиксируется, поэтому не нужно ждать, пока пройдет задержка выполнения. За исключением того, что zkSync может вернуть эти блоки:

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

В то время как в zkSync Era ни один блок не был отменен, в zkSync Lite это произошло 8 раз.

Наблюдаемость конечности

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

Давайте посмотрим на некоторые из ответов:

Это решение работает, если секвенсор готов отвечать Вам и если Вы ему доверяете. А что, если нет? Или, что если он есть, но Вы ему не доверяете? Как Вы проверяете правильность утверждения?

Мой любимый ответ.

Решение, которое действительно работает, было предложено здесь:

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

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

Метрики быстродействия

В качестве первого шага к отслеживанию времени до завершения свернутых транзакций, на L2BEAT мы начали отслеживать метрики "быстродействия", в частности, интервалы между партиями транзакций (если применимо) и корни состояний. Это объясняется тем, что если, например, рулон взаимодействует с L1 всего один раз в месяц, пользователи не могут ожидать, что время до завершения будет исчисляться минутами. Метрику Liveness можно рассматривать как нижний предел времени до завершения: если сворачивание данных транзакций публикует пакеты раз в две минуты, и предполагается, что распределение транзакций L2 равномерно, ожидаемое время до завершения не ниже одной минуты.

Вот некоторые примеры данных, которые мы отслеживаем для zkSync Era (обновления состояния) и OP Mainnet (пакеты tx):

Метрики zkSync Era liveness за сентябрь.

Метрики быстродействия OP Mainnet за сентябрь.

Как и было предсказано, поскольку для создания ZK-доказательств требуется время и есть стимул включать больше транзакций в одно доказательство, zkSync Era имеет худшие показатели быстродействия, чем OP Mainnet. Важно помнить, что, как мы уже обсуждали в предыдущих разделах, метрики liveness не переходят напрямую в показатели финальности: в худшем случае OP Mainnet имеет фактически более высокое время до финальности из-за своего окна последовательности.

Теперь Вы можете изучить метрики liveness для большинства рулонов на L2BEAT:

Ограничения при отслеживании быстроты

Хотя liveness можно рассматривать как нижний предел индикатора окончательности, иногда он может быть очень плохим. Представьте себе роллап с временем блока 4 секунды, что означает, что на каждый блок Ethereum приходится 3 блока роллапа. Если оператор роллапа размещает только два блока L2 на блок L1, даже если с точки зрения Ethereum роллап очень живой, он будет все больше отставать от мягких подтверждений L2, и время до завершения будет все больше ухудшаться. Хотя это и экстремальный сценарий, его необходимо учитывать в роллапах.

Практическим примером является Starknet: хотя мы наблюдаем в среднем 32 секунды между обновлениями состояния, время до завершения работы на самом деле приближается к 6 часам:

Источник: starkscan.co

Это происходит потому, что Starknet публикует обновление корня состояния для каждого блока L2 на L1. Однако для этого они должны сослаться на доказательство SHARP, которое обычно публикуется примерно раз в 30 минут. Кроме того, эти доказательства отстают от вершины цепочки L2 с мягким подтверждением примерно на 6 часов.

Мягкие подтверждения

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

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

Идем дальше

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

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

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