20 000 слов: Дебаты о безопасности накопительных пакетов

Первоначально написано Джоном Шарбонно Составитель: Фрэнк, Foresight News

Введение

Нравится вам это или нет, но Twitter, вероятно, никогда не перестанет спорить о том, является ли «L2» или Rollup «наследованием безопасности».

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

Устраняет ли масштабируемый L2 необходимость в L1 на рынке? Можно ли превратить L1, такой как Solana, в L2?

Эти дебаты в основном сводятся к вопросам безопасности. К сожалению, определение «безопасности» здесь всегда было очень расплывчатым. Обычно мы используем этот термин небрежно, и большинство людей примерно знают, о чем мы говорим, но не полностью. В этой статье мы подробно разберем безопасность в различных архитектурах.

Определение модного слова

Роллап

Ранее я использовал следующее определение Мустафы: «Роллап — это блокчейн, который публикует свои блоки в другом блокчейне и наследует консенсус и доступность данных (DA) этого блокчейна».

Ниже приведено более общее определение, данное Джеймсом Прествичем: «Свертка — это способ присоединиться к другому механизму консенсуса путем настройки функций перехода состояний и сохранения состояния надмножества».

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

Можно рассмотреть следующие критерии роллапа:

• Роллап — это система с отслеживанием состояния (например, блокчейн), полученная путем запуска пользовательской функции перехода состояния (STF) на входе данных в основной цепочке (уровень DA).
• Все входные данные (т.е. полные данные о транзакциях или различия в состояниях), используемые для получения окончательного состояния подтверждения удаленной цепочки (т.е. Rollup), подтверждаются в основной цепочке.
• Поскольку состояние Rollup является производным от функции перехода состояния (STF), которая выполняется на данных в основной цепочке, валидность Rollup зависит от валидности основной цепочки. Затем узел Rollup должен полностью проверить консенсус и валидность основной цепочки (или сделать честное предположение большинства о основной цепочке);

Узел Rollup определяет состояние Rollup в результате консенсуса основной цепочки (например, основная цепочка подтверждает порядок и доступность блоков данных), применяя свою собственную функцию перехода состояния (STF).

Кроссчейн-мост

Кроссчейн-мост — это система, которая позволяет двум блокчейнам взаимодействовать друг с другом. Цепочка А (целевая цепочка) должна быть уверена, что в цепочке Б (исходная цепочка) что-то произошло, и наоборот. В идеале мы хотим, чтобы это взаимодействие было двунаправленным, с сильно коррелированными атрибутами безопасности (например, высокая уверенность в том, что сообщение является действительным, исходная цепочка не будет отменена и т. д.).

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

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

Мост из основной цепочки → Rollup

Это направление очень простое, так как нода Rollup полностью проверяет основную цепочку.

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

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

• Блоки исполнения Ethereum с доказательством валидности (исследования zkEVM на базовом уровне продолжаются);
• В Ethereum реализован полный DAS, поэтому узлы могут сэмплировать DA;
• Уровень исполнения Ethereum публикует свои данные в виде больших двоичных объектов на уровне данных, как и любой другой роллап на Ethereum (например, данные уровня исполнения Celestia будут опубликованы на уровне DA, поэтому узлы DAS будут проверять доступность данных Rollup и собственного уровня выполнения Celestia);
• Ethereum обеспечивает полное доказательство консенсуса вместо того, чтобы полагаться на комитеты по синхронизации (например, за счет интеграции валидаторов, лучшей агрегации подписей, возможного доказательства консенсуса ZK и т. д.);

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

• Консенсус Ethereum - любой клиент легкой ноды может отслеживать консенсус, подписанный в виде блокчейна, заголовка блока;
• Собственный уровень исполнения Ethereum DA — узлы Rollup выполняют выборку уровня DA Ethereum, проверяя доступность данных Rollup и собственных данных уровня выполнения Ethereum (обратите внимание, что узлы DAS по-прежнему делают некоторые дополнительные предположения о полных узлах, как мы увидим позже);
• Валидность собственного состояния Ethereum — с zkEVM каждый блок Ethereum поставляется с доказательством валидности;

Узлы объединения должны проверять действительность состояния и DA собственного уровня исполнения Ethereum, поскольку это условия валидности для блоков Ethereum. Узел Rollup должен знать, что он не только отслеживает Ethereum, где был подписан консенсус, но и что это действительный заголовок блока. Например, они могут случайно отследить блоки Ethereum, которые подписаны консенсусом, но недействительны (например, они генерируют много ETH).

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

Мост из основной цепочки Rollup →

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

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

Роллапы, сопроцессоры и намерения

Как уже говорилось, роллапы сохраняют часть своего собственного состояния (состояние роллапа) в дополнение к владению состоянием своей основной цепочки (например, Ethereum). Итак, есть ли у CoW Swap собственное состояние, которое не является частью состояния Ethereum? Если да, то это звучит как роллап. Если нет, то это может быть «сопроцессор».

Однако даже этот вопрос не так прост, как кажется:

Вместо этого можно подумать, что отличительным фактором является постоянство состояния:

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

Крис Гоус затронул эту тему в своем выступлении на Modularity Summit, начав с приблизительного определения интентов: «обязательство функции предпочтения для заданного пространства состояний системы».

Обратите внимание на сходство между частичным разрешением (намерением сопоставления) и сортировкой свертки. Оператор получает подписанное вне цепочки сообщение пользователя → публикует полученные данные в основной цепочке.

• Приложения, основанные на намерениях – результирующие изменения состояния разрешаются в блокчейне (например, в примере CoW Swap приложение находится в базовой цепочке, поэтому токены обмениваются там);
• Приложение Rollup – использует данные, отправленные в основную цепочку, для расчета изменений состояния, генерируемых Rollup;

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

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

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

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

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

Модульный блокчейн и монолитный блокчейн

Монолитные блокчейны (также известные как интегрированные блокчейны) часто определяются как цепочки, которые вертикально интегрируют все основные функции, т. е. консенсус, DA и исполнение. Они берут на себя полную ответственность за собственную безопасность, и Solana и Cosmos Hub являются яркими примерами.

Уровни DA (такие как Ethereum и Celestia) часто называют «модульными» блокчейнами, потому что они передают выполнение на аутсорсинг Rollup, но это не совсем точно. Они также несут независимую ответственность за свой собственный консенсус, DA и правоприменение.

Даже исполнение Celestia будет ограничено (например, переводы, стейкинг, кроссчейн). Точно так же, если кто-то запустит Rollup поверх Solana, он не станет волшебным образом «модульным» блокчейном.

Поэтому, когда вы слышите, как люди называют такие цепочки, как Ethereum или Celestia, «модульными» блокчейнами, поймите, что это скорее практическое различие, чем чисто техническое. И те, и другие часто оптимизируют свои собственные архитектуры для поддержки Rollup. Ожидается, что эти роллапы будут обрабатывать большую часть исполнения сделок в рамках своей области.

Даже Rollup не обязательно является полностью «модульным» — секвенсор Rollup может договориться о последовательности транзакций, предоставить DA и выполнить транзакции до того, как основная цепочка что-то сделает. Таким образом пользователи получают предварительное подтверждение. Затем основная цепочка предоставляет еще одно «окончательное» обязательство, снова объявляя DA и консенсус по порядку транзакций Rollup.

Роллапы и интегрированные цепочки

Для наших целей более важным различием является «Rollup» или «Non-Rollup». Является ли окончательное состояние цепочки источником данных, опубликованных в отдельной основной цепочке (т.е. на уровне DA)?

Несмотря на то, что сегодня мы ассоциируем DAS и валидность/подтверждение отказа с традиционными накопителями, следует отметить, что это логически разные понятия. Теоретически любая «интеграционная цепочка» (например, типичная цепочка приложений Cosmos) может быть обновлена для добавления DAS и доказательств действительности без необходимости публиковать свои данные в других внешних мейнчейнах, таких как Ethereum. Узел будет делать выборку и проверять цепочку отдельно.

Виталик говорит об этой разнице в своем «Эндшпиле»:

Вы можете заметить, что «традиционный большой блокчейн» (интеграционная цепочка) с DAS + валидность/доказательство отказа может в конечном итоге выглядеть как «закрепленный роллап»! Точно так же «масштабируемый и доминирующий роллап» может стать настолько успешным, что он просто сливается со своей основной цепочкой, чтобы приспособиться к этому роллапу.

Границы различия размываются на пределе.

Поэтому, если вы считаете, что эффективность/доказательство отказа DAS+ является конечным результатом, то «Роллап» в каком-то смысле неизбежен. Существует существенная разница между двумя методами, показанными на предыдущей схеме:

• "Роллапы" aka "модульность" - строят логически независимые цепочки, публикуют данные в свою основную цепочку (уровень DA) и повторно используют консенсус основной цепочки;
• «Интегрированный блокчейн» он же «монолитный блокчейн» — интегрируйте все в один протокол со своим консенсусом, без публикации данных в отдельную основную цепочку (даже если уровень DA и уровень исполнения являются в некотором смысле логически разделенными частями общего протокола);

Когда мы говорим о "Rollup" в этом отчете, мы имеем в виду первый (т.е. не цепочку интеграции с DAS + валидность/доказательство отказа, которая может называться встроенным Rollup).

В то время как «традиционный» Rollup не имеет монополии на DAS или доказательства (т.е. интегрированные крупные блокчейны могут добавлять их), обратите внимание, что мы упускаем из виду множество технических деталей, и вы не можете просто выбрать Solana и решить: «О, я думаю, мы добавим DAS сегодня».

Это требует фундаментального рефакторинга протокола, чтобы начать приближаться к тому, что мы наблюдаем в Ethereum и Celestia:

Изменение способа кодирования данных для поддержки DAS будет приравниваться к замедлению кодирования и распространения блоков, начиная приближаться к традиционному уровню DA:

По этой причине мы видим, что команда строит следующее:

• Специализированные слои DA (например, Danksharding от Ethereum, Celestia и т.д.) - медленные блоки + DAS;
• Общие секвенсоры (например, Espresso, Astria или даже Solana) - на самом деле просто быстрые слои DA, DAS не требуется;

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

• Быстрый путь - продолжайте выполнять транзакции и распространять данные как можно быстрее (как это происходит сегодня);
• Медленный путь - кодирование данных постфактум таким образом, чтобы можно было выполнить асинхронную выборку, гарантируя, что узлы DAS немного отстают от консенсуса;

Анатолий обсуждает в подкасте, как Eclipse объединяет Ethereum, Celestia и Solana, и с другого конца спектра вы можете представить, как уровень DA добавляет более быстрый путь, прежде чем сделать данные доступными для выборки:

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

Подтвердите правило

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

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

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

Для данной цепочки может быть любое количество правил подтверждения:

• Сколько блоков нужно подождать, прежде чем подтвердить транзакцию Bitcoin? 1 ？ 6 ？ 10 ？
• Используете ли вы LMD GHOST для подтверждения блоков на основе полезного реестра Ethereum или ждете подтверждения от финального гаджета (Casper FFG)?
• Запускаете ли вы полные узлы, которые непосредственно проверяют каждый блок, или только легкие узлы, которые проверяют подписание консенсуса?
• Вы только что спросили Infura?

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

Это тонкое, но важное различие:

Безопасность = Безопасность + Активность

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

Наследование и, возможно, более очевидно, Rollup всегда «арендует», а не «наследует» что-либо в своей основной цепочке, оплачивает текущие затраты за потребленные ресурсы (DA), и любая из сторон может решить прекратить отношения. Но самое интересное не в этом.

Безопасность, с этого момента мы сосредоточимся на безопасности. Безопасность алгоритма состоит из Безопасности и Живучести:

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

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

Рассмотрим пример гипотетической цепочки интеграции с DAS + валидность/доказательство отказа. Его данные не публикуются ни в какой другой внешней основной цепочке. Для простоты мы предполагаем мгновенное завершение (например, Tendermint), поэтому нет никакой разницы между доступным реестром и завершенным реестром (например, Gasper от Ethereum).

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

• Легкий узел валидатора консенсуса - проверяет доказательство консенсуса (т.е. доверяет честному консенсусу большинства).
• Полный валидатор легкого узла - проверка консенсуса + проверка DA (с помощью DAS) + проверка валидности состояния (с использованием валидности / доказательства отказа);
• Полная нода - проверка, консенсус + прямая проверка DA (загрузка всех данных) и валидности (исполнение всех транзакций и расчет статуса);

Подтвердите, что правило имеет атрибуты безопасности, а цепочка — нет

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

Давайте рассмотрим несколько примеров.

Теорема CAP

В качестве предыстории, теорема CAP говорит нам, что ни один реестр не может удовлетворять обоим этим условиям одновременно:

Адаптивность (она же динамическая доступность) - сохранение активности с динамическим участием (т.е. если большинство узлов находятся в автономном режиме); Finality (она же согласованность) – обеспечение безопасности под сетевыми разделами;

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

• Протоколы с самой длинной цепочкой - эти протоколы (например, консенсус Сатоши Биткойна) гарантируют активность даже тогда, когда количество активных участвующих узлов варьируется (т.е. они адаптивны), однако они не являются безопасными (т.е. не окончательными) при разделении сети; Протоколы типа BFT - Классические протоколы консенсуса (например, PBFT) достигают окончательности, но не достигают адаптивности;

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

Консенсус биткоина не обеспечивает какой-либо жесткой экономической завершенности.

Узлы наблюдают самую длинную цепочку в своем локальном представлении, и каждый пользователь волен применять любое правило подтверждения, которое ему нравится (например, принимать блоки с >k подтверждений). Стандартно нужно дождаться подтверждения 6 блоков, но это на ваше усмотрение.

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

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

Консенсус PoS Ethereum (Gasper) на первый взгляд кажется обходящим теорему CAP. Однако он реализует эти два свойства, поскольку содержит два вложенных реестра:

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

Gasper принадлежит к семейству протоколов «приливов и отливов» (также известного как двойной реестр или правило двойного подтверждения). Конструкция с двумя реестрами выходит за рамки теоремы CAP (т.е. она предполагает одно правило подтверждения). Когда сеть разбита на разделы, завершенный реестр отстает от адаптивного реестра, но он наверстывает упущенное при восстановлении сети.

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

Гаспер явно предоставляет два разных правила подтверждения, сопоставленных с двумя упомянутыми выше реестрами:

• Динамически доступные правила - гарантированная адаптивность. Учитывайте заголовок блока самой длинной цепочки. LMD GHOST — это правило выбора ветвления, используемое для определения самого тяжелого поддерева;
• Правила финализации - Гарантирует окончательную определенность. Блоки уважения, подтверждённые финальными гаджетами. Casper FFG — это финальные гаджеты, которые применяются поверх правил выбора вилки;

Как обсуждается в статье:

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

Это позволяет всем (честным) узлам в системе:

• Следовать общему механизму предложения блока;
• Однако разные узлы могут выбирать разные правила подтверждения;

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

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

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

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

Это именно то, что предлагается в Правилах подтверждения протокола консенсуса Ethereum, которые предлагают правила подтверждения со следующими свойствами:

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

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

Давайте рассмотрим несколько примеров, например, если вы продаете яхту за 2,5 миллиона долларов в ETH, вот несколько возможных правил подтверждения:

• Полная нода + ожидание окончательного результата – даже злонамеренное большинство валидаторов не сможет обмануть вас, заставив принять недействительные блоки (например, произвести поддельные ETH). Если они заплатят вам $2,5 млн в ETH, а затем попытаются реструктурировать окончательный блок, они понесут огромные расходы (по крайней мере, треть капитала будет урезана);
• Полная нода + ожидание блока — большинство злонамеренных валидаторов по-прежнему не могут обмануть вас, заставив принять недействительный блок, однако они могут отправить вам 2,5 миллиона долларов в ETH в валидном блоке, уехать на яхте, а затем блок немедленно реорганизуется, что возможно при достаточном весе стейка или плохих условиях сети, они не будут урезаны карательно;
• Клиент легкого узла — вредоносные синхроплатные доски могут лгать вам без штрафа, а покупатели могут уйти на яхте (обратите внимание, что этот комитет синхронизации является эксклюзивным для Ethereum в качестве подмножества консенсуса, другие цепочки PoS с более эффективной поддержкой клиентов легких узлов могут проверять все голоса консенсуса с небольшим количеством валидаторов);
• MetaMask — Вы просто доверяете Infura, человек, который купил у вас яхту, пообещал сотруднику Infura, что они могут забрать яхту на выходных, поэтому они солгали вам, вы думали, что получили 2,5 миллиона долларов в ETH, а затем передали ключи;

Роллап подтверждает правила

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

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

• Пользователь отправляет транзакцию в секвенсор;
• Секвенсор сортирует транзакции и выдает предварительное подтверждение;
• Детерминированный STF должен применяться к упорядоченным транзакциям для вычисления нового состояния Rollup;
• Обновленное обязательство статуса роллапа и связанные с ним данные о транзакциях наконец-то передаются в основную цепочку;

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

• Rollup Full Node - напрямую проверяет, что предлагаемое состояние цепочки правильное;
• Роллап легких узлов (в том числе мосты верификации) - не могут быть проверены напрямую;
• Разные наблюдатели одного и того же Роллапа используют разные правила подтверждения, поэтому окончательно формулируют свою точку зрения в разное время: • Предполагать разглашение полных данных о транзакциях (а не только различий в состояниях);
• Как упоминалось ранее, узлы Rollup также должны запускать полные узлы основной цепочки или легкие узлы с полным валидатором (или использовать легкие узлы валидатора консенсуса, чтобы сделать честные предположения большинства). Легкие узлы роллапа могут работать как дополнительное программное обеспечение или неявно внутри узла основной цепочки (т.е. роллап проверки контракта между мостами в основной цепочке);

Пользователи также могут быстрее подтверждать транзакции, доверяя секвенсору подтверждение заранее, еще до того, как основной канал получит данные. Если секвенсор ведет себя неправильно, система безопасности может выйти из строя. Затем, как только данные окажутся в основной цепочке (и вы проверите валидность DA+), только сбой основной цепочки (например, реорганизация Ethereum) повлияет на вашу безопасность.

Таким образом, даже централизованные ordering-службы на самом деле не снижают безопасность "Rollup". Вы всегда получаете безопасность, которая соответствует нужным вам правилам подтверждения. Независимо от того, имеет ли Rollup дизайн на основе секвенсора или другой дизайн, вы можете использовать одни и те же правила подтверждения (например, дождаться завершения основной цепочки и проверить валидность Rollup). При условии правильной реализации (например, принудительного включения транзакций через основную цепочку) вы можете получить те же атрибуты безопасности в течение того же периода времени, сохраняя при этом те же условия.

Точно так же вы можете себе представить, что производители блоков Ethereum L1 обеспечивают предварительное подтверждение из-за медленного времени блока, что не делает «Ethereum» менее безопасным. Вам просто нужно решить, использовать ли другое правило подтверждения (менее безопасное) до тех пор, пока валидатор Ethereum не завершит более высокий уровень безопасности.

Идея предварительного подтверждения хорошо вписывается в логику Гаспера, описанную Виталиком:

Общий принцип заключается в том, что вы хотите обеспечить пользователю «как можно больше консенсуса»: если есть > 2/3, то мы достигаем консенсуса на регулярной основе, но если есть < 2/3, то нет причин медлить, ничего не предоставив, потому что очевидно, что цепочка будет продолжать расти, несмотря на временно более низкий уровень безопасности нового блока. Если одно приложение не удовлетворяет более низким уровнем безопасности, не стесняйтесь игнорировать эти фрагменты до тех пор, пока они не будут завершены.

Сложив все это вместе, когда все правила подтверждения согласуются на одно и то же состояние реестра в одно и то же время, мы получаем «область согласованности»:

Подтвердите правило - безопасность и доступность

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

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

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

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

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

Вкратце:

• Пользователи взаимодействуют с любой цепочкой через правила подтверждения;
• Цепочка может иметь любое количество правил подтверждения;
• Безопасность — атрибут правила подтверждения, а не самой цепочки;
• Мы заботимся о безопасности и доступности правил подтверждения для данной цепочки;

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

Роллапы с безопасностью цепочки интеграции

1 , цепочка интеграции с подтверждением валидности DAS+

Теперь мы видим, что безопасность в отношении DA и валидности состояния может быть проверена непосредственно криптографией (DAS + валидность / доказательство отказа) без строгих предположений об операторах цепочки. Любой протокол может технически реализовать их. Полные узлы также могут проверять DA и валидность состояния без внешних предположений.

Теперь остановимся на других свойствах – активности и устойчивости к рекомбинации. Как мы видели ранее, они могут завершиться ошибкой независимо от того, какое правило подтверждения вы используете. Давайте посмотрим на еще одну цепочку интеграции, которая доказывает окончательность эффективности DAS+ односокетного +PoS:

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

• Недоступные данные фактически доступны;
• или допустимы недопустимые переходы между состояниями;

Независимо от того, есть ли у Ethereum 1 валидатор или бесчисленное количество валидаторов, все узлы более или менее верят в DA или валидность блока, которую они гарантируют проверкой. Легкие узлы с полным валидатором можно проверить более простым способом (но обратите внимание, что DAS делает и другие предположения, о которых мы поговорим позже).

Тем не менее, злонамеренное большинство валидаторов может помешать росту реестра, подвергнуть вас цензуре или реорганизовать цепочку (какие именно сбои произойдут, зависит от правил подтверждения). DAS+ZK вас не спасет. Сопротивление реорганизации и деятельности всегда в некоторой степени зависит от различных основополагающих атрибутов данной цепи (например, надежных операторов, экономических стимулов, социального консенсуса и т. д.).

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

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

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

2, Доказательство свертки с использованием DAS + валидность

Теперь давайте немного модифицируем этот пример:

• Предыдущий пример - интеграционная цепочка с доказательством валидности DAS+, представьте себе, что берете сегодняшнюю Solana, но добавляете доказательство DAS+;
• Новый пример - Rollup развертывается на внешней основной цепочке (например, Ethereum) с доказательством действительности + DAS (обратите внимание, что Ethereum DAS еще не запущен), Rollup имеет набор децентрализованных секвенсоров, который может достичь консенсуса с быстрым предварительным подтверждением;

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

Fast Path - До консенсуса основной цепи

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

• Rollup Consensus Validator Light Node - Доверяйте честному большинству в консенсусе секвенсора Rollup;
• Rollup Full Validator Light Node - запускает DAS+ на ленте секвенсора для проверки доказательства валидности перед публикацией чего-либо в Ethereum;
• Rollup Full Node - Загружайте все данные из ленты секвенсора и выполняйте все транзакции для непосредственной проверки DA и валидности;

Технически секвенсор Rollup может облегчить DAS и обеспечить доказательство валидности перед публикацией в основной цепочке, но на самом деле этого не происходит. Легкие узлы с полным валидатором обычно предназначены для проверки их через основную цепочку, но я предполагаю, что «живые» доказательства DAS+ можно более четко сравнить с теми же, что и в интегрированной цепочке.

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

• Полагаться на секвенсор Rollup для активности и антирекомбинации, а не на набор валидаторов интегрированной цепочки;
• Удален только атрибут final activity, потому что здесь просматривается только временной диапазон до консенсуса основной цепочки (эти "окончательные" атрибуты активности будут принадлежать им позже в будущем);

Удаления отображаются красным зачеркнутым цветом, а добавления — синим:

Медленный путь - Дождитесь консенсуса основной цепочки

Для дополнительной безопасности узлы могут ожидать консенсуса от основной цепочки (например, Ethereum), и именно здесь это проявляется более явно, т.е. узлы Rollup также должны запускать узел основной цепочки:

• Легкий узел валидатора консенсуса основной цепи - доверяйте честному консенсусу большинства основной цепочки;
• Light Node Main chain full validator - проверка валидности основной цепочки + запуск DAS на основной цепочке (включая данные Rollup + данные основной цепочки);
• Полный узел основной цепи - загрузка всех данных мейнчейна (включая проверку данных роллапа) + выполнение всех транзакций мейнчейна для прямой проверки валидности;
• Обратите внимание, что действительность Rollup может быть проверена двумя различными способами:
• Вне основной цепочки (с запуском дополнительного программного обеспечения узла Rollup) - Rollup не требует, чтобы его основная цепочка проверяла свое состояние или STF, не нуждается в развертывании моста верификации, вместо этого может проверить доказательство Rollup другим методом (например, получение доказательства Rollup через p2p), что требует запуска дополнительного программного обеспечения узла Rollup для проверки доказательства (т.е. легких узлов Rollup);
• Внутри основной цепочки (реализуйте узел Rollup внутри основной цепочки) - это норма на сегодняшний день, логика валидатора легкого узла Rollup развернута в самой основной цепочке (т.е. встроенный в Rollup контракт моста), так как этот узел валидатора Rollup работает внутри STF основной цепочки, валидация STF основной цепочки также означает проверку STF роллапа;

Если мы получим proof-proof mainchain с нулевым разглашением (например, Ethereum L1 zkEVM) + все роллапы докажут свое состояние внутри основной цепочки→ мы получим видение Виталика о доказательстве сингулярности. Доказательство валидации Ethereum с нулевым разглашением означает проверку всех остальных цепочек и проверку узлов их внутренних реализаций:

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

Ниже приведены изменения по сравнению с предыдущей таблицей Fast Path Rollup.

Это достигается за счет того, что основная цепочка заставляет транзакции включать или навязывает замену секвенсора/проверщика, что мы называем здесь «окончательным» действием, потому что с точки зрения Rollup это медленный путь, но с точки зрения основной цепочки это можно считать активностью «в реальном времени».

Роллап с интегрированным блокчейном

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

• DA и валидность состояния - Если это реализовано, доказательство валидности DAS+ может обеспечить применимые гарантии безопасности, независимо от того, является ли цепочка интегрированной или традиционной Rollup. На самом деле, в этих технологиях сегодня доминирует Rollup; Liveness Re-org Resistance – Интегрированные блокчейны отвечают за это независимо во всех сценариях. Вместо этого Rollup предлагает выбор правил подтверждения в разные временные рамки. Вы можете использовать менее безопасные правила подтверждения (консенсус секвенсора доверия), чтобы получить быстрые гарантии, или дождаться более безопасных правил подтверждения (дождаться консенсуса основной цепи);

Активность и устойчивость к рекомбинации

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

Если оператор полностью вышел из-под контроля, никакое доказательство полного узла или ZK не защитит вас от сбоев в работе или реорганизации.

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

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

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

Цепочки могут даже выбирать, какие атрибуты делегировать той или иной цепочке, а различные типы архитектур «L2» (такие как валидиумы, оптимизм и сайдчейны) могут поглощать различные подмножества атрибутов безопасности. Например:

• Антиреструктуризация - Rollup может делегировать антиреструктуризацию Ethereum, и его правила выбора форка основаны на том, что консенсус Ethereum подтверждает для выбора «канонической цепочки». Если Ethereum реорганизуется, Rollup также реорганизуется.
• Liveness - Однако, если в Rollup отсутствует механизм принудительного включения и принудительной замены операторов, пользователи Rollup все равно не получают атрибут живости Ethereum;

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

Это подчеркивает важность таких механизмов.

Доступность данных и валидность статуса

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

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

Для того, чтобы сбалансировать безопасность и доступность, часто используются следующие предпочтительные способы:

• Сделать DAS и доказательство эффективности широко доступными;

• Если у вас нет DAS и/или подтверждения действительности, сделайте полные узлы широко доступными (т.е. низкие требования к ресурсам, простоту запуска и т.д.);
• Если у вас нет DAS и/или доказательства валидности, а полный узел в значительной степени недоступен, то, пожалуйста, сделайте легкий узел валидатора консенсуса широко доступным и получите заслуживающий доверия консенсус честного большинства;
• Посещение Инфуры;

Обратите внимание, что 2 (полный узел) на самом деле является наиболее безопасным. Верификация ZK проста, но узлы DAS делают некоторые дополнительные предположения, которых нет у полных узлов. Тем не менее, они обеспечивают почти такую же безопасность, как и полные узлы, и при минимальных требованиях к ресурсам они масштабируемы.

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

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

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

Эти предположения «N-в-2» (например, честное меньшинство узлов могут обеспечить DAS) очень выгодны по сравнению с типичным приблизительным предположением «N/2» (например, 51% производителей блоков могут привести к реорганизации). У Виталика есть хорошее введение в эту тему в его посте о модели доверия.

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

Ознакомьтесь с примером предыдущей проверки подтверждения свертки:

• Опубликуйте доказательство ZK от Rollup в смарт-контракте Ethereum, где вы запускаете полную ноду Ethereum и неявно проверяете доказательство;
• Отправьте доказательство ZK of Rollup на мой легкий узел Rollup, чтобы проверить доказательство напрямую;

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

Рассмотрим роллап на основе цепочки мошенничества:

• Правила выбора форка Rollup следуют за вершиной цепочки→ Если цепочка будет реорганизована, Rollup также реорганизуется;
• Обязательный механизм включения Rollup и удаление секвенсора обеспечиваются с помощью межсетевых контрактов в мошеннической цепочке→ Если реестр мошеннической цепочки останавливается, то же самое происходит и с реестром роллапа. Если мошенническая цепочка захочет подвергнуть цензуре ваш роллап, то вы будете подвергнуты цензуре;

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

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

Разумный выбор основной цепочки Rollup может оказать конкретное влияние на атрибуты безопасности. Особенно ценно использовать бэкчейн с высокой активностью (рост реестра + CR) и сопротивлением реорганизации.

Различные предположения о безопасности для разных периодов времени

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

Роллап имеет следующие характеристики:

• Время блока 10 секунд;
• Поддерживаются световые узлы DAS
• Могут быть предоставлены правила подтверждения активности и антиреорганизации «Высокая безопасность» (например, децентрализованные доверенные валидаторы и т.д.);

Интегрированный блокчейн имеет следующие характеристики:

• Время вывода блока 1 секунда;
• Легкий узел DAS и доказательство действительности могут быть реализованы, независимо от того, запущен ли он как интегрированный блокчейн или как роллап;
• Если реализован централизованный секвенсор - он обеспечит "низкую безопасность" подтверждения правил об активности и устойчивости к рекомбинации;
• Если он реализует свой собственный децентрализованный консенсус (либо в виде предварительно подтвержденного набора секвенсоров Rollup, либо в виде набора валидаторов интегрированной цепочки), он будет предоставлять правила подтверждения «средней безопасности» для активности и антиреорганизации;

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

«Абсолютная безопасность» Rollup выше, чем «безопасность в реальном времени», потому что основная цепочка не может гарантировать нам быстрее, чем ее собственное время блока. Несмотря на то, что вы можете проверить, являются ли предварительные подтверждения секвенсора допустимыми переходами состояний, вы не можете полностью гарантировать их завершенность до тех пор, пока они, наконец, не достигнут уровня DA.

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

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

• Практичная функциональность и эффективность. Например, централизованные секвенсоры могут обеспечить быструю предварительную проверку и снизить операционные накладные расходы;
• Сильная гарантия. Например, невероятный набор децентрализованных секвенсоров может обеспечить лучшую активность в реальном времени, но за счет более высоких эксплуатационных расходов и задержки (в самом крайнем случае вы просто позволяете уровню DA обрабатывать порядок свертки, предпочитая не предоставлять более быстрый путь);

Интересно, что вы можете возразить, что накопительные пакеты L1-упорядочения менее активны, чем централизованные секвенсоры, в зависимости от вашего временного масштаба. До сих пор мы говорили об активности, включая ее в некую концепцию «конечного времени». Однако это сугубо относительное и субъективное. Относительно чего? Сколько времени это займет?

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

• Если baseline = операция внутри Rollup, последовательный Rollup L1 может обеспечить лучшую активность. Никому другому в цепочке не следует обещать до тех пор, пока не будет подтверждена основная цепочка, поэтому вы все в равных условиях;
• Если базовый уровень = работа вне роллапа - свертка с мягкой предварительной квалификацией может обеспечить лучшую активность. Предварительное подтверждение - это просто бесплатная опция, и вы все равно возвращаетесь к гарантии основной цепи со скоростью основной цепи, но в то же время вы можете получить более слабую гарантию. Если вы им не доверяете, просто дождитесь подтверждения основной цепочки. Мир не замирает между блоками Ethereum, и для многих приложений устаревшие цены между длительными блоками могут быть неприемлемыми;

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

И последнее важное замечание. Предполагая, что пользователи Rollup могут вернуться к тому же уровню активности, что и основная цепочка, предполагая, что вы можете принудительно включить ее полностью со скоростью блока основной цепочки (например, если orderinger Rollup проверяет вас, вы можете принудительно включить транзакции в следующий блок Ethereum основной цепочки).

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

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

Например, если у пользователя есть надежный механизм принудительного выхода или даже принудительного удаления оператора, то централизованный секвенсор Rollup не может произвольно извлекать ренту из пользователя и блокировать ее. Это общая область, обсуждаемая Крисом Гоусом в его докладе о MEV, Conversion Cost, Edge и Slow Gaming.

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

Proof защищает не цепочку, а пользователя

После всего этого мы видим, что для данного правила подтверждения получается, что точнее защитить разных «наблюдателей» (пользователей) Rollup, чем защитить сам «Rollup». Безопасность «Роллапа» не существует как единой конкретной меры.

Обеспечение безопасности наблюдателя – это, конечно, самое главное, ведь все мы являемся наблюдателями цепи! Эта цепочка – все, что говорят ее наблюдатели. Если вы не можете наблюдать его безопасным способом, вы должны довериться кому-то другому (например, проверяющему), чтобы он сказал вам «правду» об этом. Но мы не хотим доверять, мы хотим проверки→ мы хотим доказательств.

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

• Легкие узлы - Легкие узлы роллапа более безопасны, если есть доказательства, им не нужно доверять действительности чьих-либо слов;
• Полная нода - при наличии доказательства, безопасность полной ноды Rollup не увеличится и не уменьшится, вы можете запустить Rollup ("пессимистичный роллап") без встроенного моста или даже какого-либо доказательства, если вы начнете отправлять доказательство валидности, то безопасность полной ноды не увеличится и не уменьшится;

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

Аттестация защищает мост Rollup

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

Как и в случае с любым типичным узлом Light, мост не может напрямую проверять допустимость Rollup. Мы не верим в честное большинство, а защищаем мосты доказательствами. Протокол консенсуса для базы данных A (уровень DA) сортирует большие двоичные объекты данных, а затем проверяет, что мост самостоятельно проверяет допустимость соответствующего обновления базы данных B (Rollup):

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

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

Рассмотрим старый гипотетический сценарий про Терру:

• Terra имеет свой набор валидаторов, ее нативный токен — LUNA, и можно выпускать нативные UST;
• У Osmosis есть собственный набор валидаторов, а его нативным токеном является OSMO.
• У нас есть стандартный мост Terra ←→ Osmosis IBC, где каждая сторона запускает легкий узел валидатора консенсуса другой цепочки (т.е. каждая сторона моста зависит от честного большинства набора валидаторов другой цепочки);
• Вы запускаете свою собственную полную ноду для каждой цепочки в качестве пользователя;
• Мы называем UST на мосту через IBC UST osmoUST;
• Мы называем OSMO на Terra мостом через IBC terraOSMO;
• Вы владеете terraOSMO на Terra;
• Вы делаете LP в пуле osmoUST/OSMO на Osmosis;

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

• Чеканить поддельные UST → кроссчейн в Osmosis для чеканки osmoUST, использовать его для истощения всех торговых пар osmoUST (например, вывести все OSMO из пула osmoUST/OSMO;
• Чеканка поддельных terraOSMO → кроссчейн в osmosis для вывода всего нативного обеспечения OSMO, заблокированного на Osmosis, который поддерживает terraOSMO, все оставшиеся terraOSMO на Terra теперь больше не будут поддерживаться;
• Ну, безопасность здесь не работает:
• Полная нода (я) - моя полная нода распознает блоки Terra как невалидные и отклоняет их, валидаторы Terra не могут украсть мои позиции terraOSMO или osmoUST/OSMO LP;
• Легкий узел (мост) - мост просто проверяет, что консенсус Terra подписан на блоке (не проверяя валидные переходы состояний), чтобы не отклонять их, валидаторы Terra могут украсть залог OSMO, поддерживающий мой terraOSMO, и слить все OSMO из пула osmoUST/OSMO (оставив кучу бесполезных osmoUST);

Мост использует правила подтверждения с более сильными предположениями о доверии.

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

Обратите внимание, что важно, чтобы эти неисправности не «заражали» остальную часть цепочки, т.е. неисправность «заражала» активы Osmosis, подверженные маршруту моста Terra, но в самой цепочке Osmosis нет сбоя безопасности.

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

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

• Роллапы Ethereum в настоящее время требуют, чтобы их узлы запускали полные узлы Ethereum, и эти роллапы разделяют консенсус Ethereum; Namada (отдельная цепочка Tendermint, а не цепочка Rollup) потребует от своих узлов запуска полных узлов Ethereum, однако Namada не согласна с консенсусом Ethereum (т.е. она не публикует данные в Ethereum и не выводит их состояние на основе этого);

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

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

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

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

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

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

Зависимые и независимые цепочки

Давайте снова посмотрим на наши пять атрибутов безопасности, теперь в контексте наблюдения за мостом проверки Rollup на Ethereum:

• Рост реестра — валидаторы Ethereum могут заставить реестр Rollup продолжать расти (например, принудительно включать транзакции);
• Устойчивость к цензуре - валидаторы Ethereum могут заставить операторов Rollup не подвергать цензуре бесконечно долго (например, принудительно включать транзакции или подменять секвенсор);
• Антиреструктуризация - Антиреструктуризация Rollup связана с Ethereum. Если Ethereum реорганизуется, то все роллапы на Ethereum будут перегруппированы;
• Доступность данных - DA Rollup гарантирован, потому что Rollup по определению является производным от данных, подтвержденных консенсусом основной цепочки (где находится контракт Rollup), Rollup и основная цепочка разделяют консенсус слияния, DA является условием действительности самого Ethereum, поэтому, если данные недоступны, то сам блок Ethereum недействителен. Мост может получить доступ к данным в основной цепочке без добавления предположений о доверии;
• Валидность состояния - контракт проверит доказательство валидности перехода состояния Rollup (или дождется прохождения окна вызова), которое доказывает, что заявленное обновление состояния является валидным результатом применения STF Rollup на соответствующих данных, подтвержденных в основной цепочке;

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

Виталик приводит полезный наглядный пример:

«Вы переводите 100 ETH на мост через Solana и получаете 100 Solana-WETH, а Ethereum подвергается атаке на 51%. Злоумышленник вносит кучу своих ETH в Solana-WETH, а затем возобновляет транзакцию на стороне Ethereum, как только сторона Solana подтверждает это. Контракт Solana-WETH больше не поддерживается в полном объеме, и, возможно, ваши 100 Solana-WETH теперь стоят всего 60 ETH. Даже при наличии идеального моста на базе ZK-SNARK, полностью подтверждающего консенсус, он все равно уязвим для атаки 51%, подобной этой.

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

Если Ethereum будет атакован на 51% и восстановится, Arbitrum и Optimism также восстановятся, поэтому даже если Ethereum будет атакован 51%, приложения «cross-rollup», которые сохраняют состояние на Arbitrum и Optimism, гарантированно останутся согласованными. Если бы Ethereum не был атакован 51%, не было бы возможности провести атаку 51% на Arbitrum и Optimism соответственно. Таким образом, по-прежнему полностью безопасно держать активы, выпущенные Optimism на основе Arbitrum.

Вы можете заменить Solana любой цепочкой, которую захотите - даже гипотетической цепочкой, в которой вы превосходите валидатора Ethereum с точки зрения доверия, и, по сути, любые предположения о безопасности являются аддитивными, когда вы говорите о кроссчейн-активах с их реестром записей (например, ETH от Ethereum), и всегда есть вероятность реорганизации связанной цепочки или сбоя деятельности.

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

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

Есть также некоторые недостатки привязки цепочки Rollup к основной цепочке. Давайте сравним два кроссчейн-сценария, в обоих случаях у нас есть две цепочки, которые используют двусторонний кроссчейн-мост с полным валидатором:

• Зависимость - удаленная цепочка (т.е. Rollup) разделяет консенсус основной цепочки (т.е. уровня DA) и выводит свое собственное состояние из данных в основной цепочке, удаленная цепочка должна разветвляться с основной цепочкой и определять свою завершенность на основе основной цепочки;
• Независимые - Эти цепочки имеют свой собственный независимый консенсус, они не выводят свое собственное состояние на основе данных по другим цепочкам. Они не разделяют отношения удаленной цепочки (т.е. Rollup) ←→ основной цепи (т.е. уровня DA). Они не перегруппировываются вместе и не зависят от активности друг друга;
• Интересно, что это и хорошо, и плохо:
• Плохо - Реорганизация вашей цепочки с другими цепочками или сбои в работе могут показаться недостатком на первый взгляд, почему в моей цепочке возникают проблемы, потому что ваша цепочка сломана?
• Хорошо - если эта дивергенция вызывает серьезные проблемы в вашей цепочке, это на самом деле важное преимущество (например, если у вас есть большое количество кроссчейн-активов из исходной цепочки, то она будет реорганизована с точки зрения вашего кроссчейн-бриджа, оставив необеспеченное обеспечение), цепочка и ее кроссчейн-мост должны быть согласованы друг с другом;

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

• Хорошо - Хороший мейнчейн защищает пользователей Rollup от операторов Rollup, выжимающих из них слишком много ценности, обеспечивая привилегии выхода;
• Плохо - Плохие бэкчейны могут произвольно завышать цену и извлекать эту ценность из Rollup и самих его пользователей;
• Доказательство отправки + запуск DAS в обоих направлениях вместо совместного использования общей основной цепочки также имеет некоторые недостатки:
• Вы не хотите, чтобы ваш узел запускал кучу легких узлов DAS других цепочек, и вам приходилось вручную добавлять новые цепочки, запуск DAS на огромном общем уровне DA намного эффективнее;
• Для каждой цепочки неэффективно проверять валидность для множества различных цепочек, однако теоретически возможно агрегировать доказательства между несколькими цепочками, чтобы всему кластеру цепочек нужно было опубликовать только одно доказательство в цепочке;

Здесь есть компромиссы и преимущества, но также имейте в виду, что существует огромная зависимость пути от того, где находятся интересные активы, и если вы хотите использовать кучу нативных активов Ethereum (включая те, которые входят в его Rollup), имеет смысл укоренить свою цепочку в Ethereum и его кроссчейн-мостах.

Заключение

«Безопасность наследования роллапов» — это хорошее сокращение, но помните, что на самом деле мы имеем в виду следующие ключевые моменты:

• Роллап платит арендную плату своей основной цепочке, такой как Ethereum, за ресурсы, которые он потребляет (DA);
• Роллап может предоставлять правила подтверждения со свойствами безопасности вплоть до основной цепочки (т.е. пользователи могут получить те же гарантии безопасности, что и при работе с самой основной цепочкой);
• Пользователи получают эти атрибуты безопасности основной цепи со скоростью консенсуса основной цепочки;
• Если пользователи Rollup хотят быть быстрее, чем подтверждение, предоставляемое основной цепочкой, они могут использовать правила подтверждения, которые делают дополнительные временные предположения о безопасности;
• Наблюдатель (т.е. пользователь) взаимодействует с Rollup через правила подтверждения, и таким (необязательным, но очень ценным) наблюдателем является мост верификации с наименьшим доверием;

Теперь рассмотрим преимущества развертывания Rollup в цепочке интеграции:

Безопасность пользователя - Независимо от того, хотите ли вы реализовать какие-либо кроссчейн-мосты или нет, Rollups может арендовать DA из своей основной цепочки и восстановить свой консенсус, что позволяет Rollup предоставлять своим пользователям правила подтверждения, которые соответствуют основной цепочке, без необходимости достижения собственного консенсуса;

Кроссчейн-безопасность - Rollup может создавать кроссчейн в пределах общего домена безопасности основной цепочки (т.е. самой основной цепочки и ее Rollup), и его свойства безопасности сравнимы с работой в самой основной цепочке;

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

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

Несмотря на то, что сегодня мы ассоциируем DAS и доказательства валидности с Rollup, это логически разные понятия. Любая цепочка может интегрировать эти технологии, и различие между тем, что является роллапом, а что нет, начинает разрушаться в конце игры (т.е. для одного интегрированного роллапа он может иметь логически разделенные уровни DA и выполнения в рамках одного протокола).

Тем не менее, сегодня в этих технологиях верификации и масштабирования явно доминируют уровни «традиционного свертки» и DA.