1. Введение

1.1. Будущее направление Optimistic Rollup

В сентябре 2024 года Виталик подчеркнул необходимость улучшения стандарта Rollup и заявил:

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

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

Система "фаз" Rollup - это фреймворк для грубой оценки уровня безопасности от фазы 0 до фазы 2. В настоящее время только Arbitrum и Optimism достигли фазы 1 в основных Rollup, в то время как большинство оптимистических Rollup все еще находятся на фазе 0.

В этой ситуации возникли некоторые проблемы:

• С момента запуска Optimistic Rollup прошло уже три года, почему до сих пор нет проектов, достигших высочайшей стадии 2?
• Когда можно ожидать, что Optimistic Rollup достигнет второй фазы?

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

1.2. Сравнение оптимистичного Rollup и ZK Rollup

Как известно, Ethereum медленный и имеет высокую комиссию за транзакцию. Исследователи и разработчики Ethereum сообщества продолжают работать над решением этой проблемы. После исследования различных решений, таких как Шардинг (sharding) и Plasma, сообщество наконец пришло к выводу, что Rollup - это главный путь к масштабированию. Поэтому появилось много Rollup-решений, таких как Arbitrum, Optimism и zkSync. Согласно данным L2Beat, на данный момент около 40 Rollup-решений работают, а еще некоторые решения, такие как Validium и Optimium, используют альтернативные решения для реализации более высокой масштабируемости, общее количество достигает 41. Кроме того, ожидается запуск около 80 новых Rollup-цепочек.

（текущая ситуация L2 | источник:L2Beat)

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

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

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

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

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

1. **ZK Rollup **ZK Rollup требует от валидаторов не только предоставить корневое состояние, но и предоставить доказательство ZK для проверки правильности вычисления корневого состояния. Если валидаторы предоставят неверное корневое состояние, доказательство ZK не пройдет проверку L1-контракта, что предотвратит представление злонамеренного корневого состояния.
2. **Оптимистичный роллап **Optimistic Rollup позволяет определенным валидаторам представлять корень состояния без дополнительных гарантий на основе предположения о честности представления. Однако, если представленный корень состояния неверен, любой может поднять возражение и предотвратить его использование в процессе вывода. Опровергающая сторона должна представить доказательства в Эфире о неверности корня состояния, что называется доказательство мошенничества (Fraud Proof).

Чтобы обеспечить безопасное решение атак, таких как атака на период проверки L1, время вывода средств Optimistic Rollup обычно задерживается на неделю.

1.3. Зачем нужны доказательства мошенничества?

В отличие от ZK Rollup, валидаторы Optimistic Rollup могут представлять неверные корневые состояния и пытаться манипулировать транзакциями вывода. Доказательство мошенничества эффективно предотвращает это, обеспечивая безопасность средств в контракте моста.

Если у Optimistic Rollup нет надежного механизма доказательства мошенничества, то он не сможет полностью унаследовать безопасность Ethereum. Например, в текущей системе валидаторов Arbitrum, если все валидаторы сговорятся, они могут похитить все средства из контракта моста. Точно так же, на Rollup, основанных на стеке OP, таких как Base, из-за того, что на основной сети еще не реализован механизм безразрешительного доказательства отказа, отдельные злоумышленные валидаторы также могут похитить средства.

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

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

1.4. Переход к этапу 2: "снятие вспомогательных колес"

система доказательства мошенничества сыграла ключевую роль в процессе помощи Optimistic Rollup в реализации "фазы 2". Фреймворк фаз, предложенный Виталиком, в настоящее время управляется L2Beat и используется для оценки уровня безопасности Rollup.

В экосистеме ETH Workshop этот этапный фреймворк часто сравнивают с обучением езде на велосипеде. Этап 0 Rollup, который больше всего полагается на предположение о доверии, сравнивается с трехколесным велосипедом с тренировочными колесами, в то время как Phase 2 Rollup, который полностью наследует безопасность ETH Square, сравнивается с двухколесным транспортным средством со снятыми тренировочными колесами.

Ниже приведены подробные стандарты для каждой из фаз с 0 по 2.

Как уже упоминалось выше, для достижения Фазы 1 или Фазы 2 в Optimistic Rollup крайне важно реализовать соответствующее доказательство мошенничества и механизм оспаривания. Учитывая эти критерии, система доказательства мошенничества, соответствующая требованиям Фазы 2, должна обладать следующими характеристиками:

• Система работает нормально, нет известных дефектов и обладает функцией "1-of-N".
• Это система, не требующая разрешений, и любой желающий может отправить отзыв.
• Если в системе найдены уязвимости, они должны быть подтверждены в блокчейне.

Во второй половине этой статьи мы рассмотрим, как различные протоколы пытаются реализовать эти функции.

2. доказательство мошенничества - Понятие и неправильное понимание

2.1. Как осуществляется доказательство мошенничества?

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

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

доказательство мошенничества和质疑Протокол通常包括以下步骤：

1. Валидаторы (提出者) регулярно представляют ETH блоку вывод, содержащий L2 корень состояния (или заявление).
2. Если валидаторы (запросившие) не согласны с выходными данными, они могут оспорить их.
3. Заявитель и оппонент через процесс, называемый двоичным методом или методом анатомического разделения, выявляют разногласия и детализируют их до уровня инструкции или уровня Блок (ZK Rollup).
4. Те, кто сомневается, представляют доказательства мошенничества в блокчейне, доказывая недостоверные аспекты. Обычно протоколы, подобные Arbitrum и Optimism, выполняют подозрительные инструкции в блокчейне для верификации.
5. Если доказательство мошенничества пройдет проверку, неправильный вывод будет удален или заменен. В соответствии с Протоколом обжалования, инициатор может быть наказан, а обжалующая сторона получит вознаграждение.

2.2. 常见误解：доказательство мошенничества与质疑不会Откат链

需要注意的是，即使发生доказательство мошенничества和质疑，链也不会被Откат。доказательство мошенничества确保的是“мост合约中的资金不会被恶意提取”，而不涉及不正确状态转换的Откат。

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

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

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

2.3. Реальный пример: сомнения Kroma в апреле 2024 года

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

Kroma - это OP Stack based Rollup, обладающий собственной системой ZK-доказательства отказа и безлицензионной системой валидаторов. 1 апреля 2024 года у сортировщика L1 Kroma возникли проблемы, что привело к генерации неправильного Блока. Кроме того, валидаторы, заметившие эту ситуацию, представили неверный корень вывода. Немного позже после представления корня вывода 12 опротестовавших лиц подвергли этот вывод сомнению.

Один из критиков успешно вызвал функцию proveFault и удалил некорректный вывод.

Сомневающийся успешно выполнен proveFault функция | Источник:etherscan

Это первый успешный случай оспаривания в истории сети Rollup Ethereum Основная сеть. Это также первый случай успешной проверки и оспаривания доказательства сбоя в Основной сети спустя примерно три года после запуска первого оптимистичного Rollup (Arbitrum) в мае 2021 года. Подробное описание этого оспаривания можно найти в статье, написанной Kroma. В этом случае сеть Kroma не откатывалась, а только удалила неправильный корневой вывод.

Отказ от ответственности: доказательство мошенничества или доказательство сбоя?

доказательство мошенничества также известно как доказательство отказа. Особенно в цепочках Optimism и OP Stack используется термин “доказательство отказа”, в то время как в проектах Arbitrum, Cartesi, L2Beat и т.д. используется термин “доказательство мошенничества”.

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

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

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

3. Атака Хакера! - Использование механизма доказательства мошенничества

3.1. Дизайн экономического спорного Протокол

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

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

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

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

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

• Из-за атак, вызванных уязвимостями в спорных играх;
• задержка攻击，延长用户提现时间超过 7 天；
• Сибилльная атака, потребляющая средства и ресурсы честных участников;
• Атака, вызванная проверкой L1 валидаторов;
• Использование доказательство мошенничестваВиртуальная машина中的漏洞发起的攻击。

注意：以下讨论的Вектор атаки都是公开已知的，并且不会影响任何Основная сеть的安全性。

Следующие главы будут анализировать различные Протоколы и их особенности следующим образом:

3.2. Вектор атаки #1：利用经济争议游戏

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

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

С точки зрения теории игр, Протокол должен обеспечить, чтобы затраты злоумышленника на атаку были больше, чем затраты честного участника на защиту. Однако это очень сложно достичь.

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

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

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

3.2.1. Вектор атаки #1-1: задержка攻击

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

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

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

Однако необходимо учитывать некоторые факторы. Что делать, если злоумышленник не боится, что его средства будут разрезаны, и все же пытается провести атаку задержки?

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

Механизм доказательства мошенничества, применяемый в Arbitrum One и Arbitrum Classic, использует модель форка. Вместо простого разрешения участникам оспаривать неверные утверждения, каждый участник представляет свое собственное утверждение, которое он считает правильным, и прилагает определенную сумму средств, рассматривая их как "форк цепи". Утверждения также могут быть рассмотрены как проверочные точки на состоянии цепи.

Модель ветвления Arbitrum

В Arbitrum Classic участники представляют свои утверждения и ветви цепи, считающиеся правильными, и путем оспаривания последовательно удаляют неправильные ветви цепи, наконец, подтверждают правильные утверждения.

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

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

Поскольку каждый вопрос может занять до 7 дней, злоумышленник может увеличить задержку Протокола до 7 * (N-1) дней.

Отложенная атака для Arbitrum Classic | Источник: [L2Beat Medium] (https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a)

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

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

3.2.2. Вектор атаки #1-2: Атака Сибил (атака на истощение ресурсов)

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

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

1. Постоянное представление неправильных выходных данных. Предположим, что сумма средств злоумышленника Боба превышает сумму средств честных участников (защитников) Алисы, Чарли и Дэвида. В этом случае Боб постоянно представляет неправильные корни. Честные участники Алиса, Чарли и Дэвид будут справляться, выплачивая Газовый сбор и залог, и при определенном пороге средства честных участников будут исчерпаны раньше, чем у Боба. В этот момент Боб представляет другой неправильный вывод. Поскольку в сети больше нет честных участников с оставшимися средствами, этот вывод будет окончательно подтвержден и не будет оспариваться. Таким образом, Боб может украсть средства из оптимистического роллапа.
2. Подозрительные выводы. В отличие от честных участников, злоумышленники могут атаковать, отправляя несколько подозрительных выводов. Атака будет продолжаться до тех пор, пока честные участники не израсходуют все средства, выделенные на Газ и залог, после чего злоумышленники представят неправильные выводы и украдут средства пользователей измоста.

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

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

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

3.3. Решение #1: экономически обоснованная игра споров

1) Arbitrum BoLD

BoLD на основе модели ветвления Arbitrum Classic ввел следующие три элемента для предотвращения уязвимостей задержки:

• Все к механизмам вопросительного знака. В BoLD вопросительный знак больше не является последовательным для каждой пары, а вместо этого используется параллельный механизм, в котором все участники могут заложить свои средства на ветви, с которыми они согласны. Это предотвращает задержки и векторы атак, вызванные предыдущими последовательными вопросительными знаками 1 к 1 и гарантирует, что для одного и того же спора не может быть несколько независимых вопросительных знаков.
• Доказательство, вычисленное в правильном состоянии, предотвращает злонамеренное двоичное разделение (историческое обязательство). Проблема в Arbitrum Classic заключается в том, что злонамеренные участники могут осуществлять двоичное разделение неправильным образом, умышленно вызывая задержку и помечая безразличную часть как спорную. В этой связи BoLD требует предоставления доказательств вместе с корнем состояния, чтобы проверить правильное вычисление корня состояния в процессе двоичного разделения, чтобы убедиться, что злонамеренное двоичное разделение не произошло.

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

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

Однако создание этого подтверждения требует от валидаторов значительного количества вычислительных ресурсов. Внутри это подтверждение требует создания хеша для всех состояний в двоичном разбиении, что обычно оценивается в Arbitrum примерно в 270 хешей (примерно 1.18 x 10²¹). Чтобы решить эту проблему, BoLD разделяет оспаривание на три уровня, уменьшая количество вычисляемых хешей до 226 (примерно 6.71 x 10⁷).

(Этот график предполагает наличие 269 инструкций в общей сложности, фактические данные могут отличаться)

• Ограничение времени застейкать с помощью механизма шахматных часов.

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

Предположим, что два участника представили разные заявления. У каждого участника есть таймер (шахматные часы) на 6.4 дня. Когда очередь участника представлять двоичное или доказательство, таймер начинает отсчет и останавливается после завершения задачи участником.

Поскольку у каждого участника есть 6,4 дня, максимальное время задержки процесса для одного участника составляет 6,4 дня. Таким образом, в BoLD максимальная продолжительность оспаривания составляет 12,8 дня (в некоторых случаях, когда вмешивается Комиссия по безопасности, дополнительно увеличивается на 2 дня).

Через эти механизмы, Arbitrum BoLD эффективно ограничивает задержку, вызванную оспариванием. Максимальная продолжительность оспаривания составляет две недели, а максимальная дополнительная задержка, с которой пользователь может столкнуться, составляет примерно одну неделю.

Однако это может использоваться для задержки атаки. Злоумышленники могут создать сомнение и сговориться с L1 валидаторами, чтобы проверить честность валидаторов Arbitrum, что приведет к задержке вывода средств пользователей Arbitrum на неделю. В этом случае пользователи, запрашивающие вывод средств в этот период времени, могут столкнуться с возможными потерями из-за заблокированных средств. Хотя это и не является прямой атакой на средства, но такие атаки все равно должны быть предотвращены из-за возможных потерь для пользователей. Arbitrum BoLD борется с этой проблемой, устанавливая достаточно высокую залоговую сумму, необходимую для создания сомнения, чтобы отпугнуть такие атаки.

Arbitrum рассчитал эту сумму в экономической документации BoLD. Основной причиной задержки Протокола является проверка L1 валидаторов. В случае атаки задержки сценарий развернется следующим образом:

1. Злоумышленник подает заявление N', которое не соответствует существующему заявлению N, до подтверждения заявления N на Arbitrum.
2. Защитник пытается отправить двухстороннюю сделку, но из-за того, что L1 валидаторы проверяют сомнительную сделку защитника, операция не удалась.
3. Поскольку предполагается, что проверка BoLD не может продолжаться более 7 дней, это может привести к задержке окончательного подтверждения заявления N на неделю.

Прибыль злоумышленника происходит из возможных издержек, которые возникают у пользователей, сомневающихся в выводе запросов на вывод средств. В худшем случае все средства в Arbitrum находятся в одном выводе, и затраты пользователей на возможные издержки рассчитываются следующим образом: предположим, что TVL в Arbitrum One составляет 154 миллиарда долларов, APY составляет 5%:

Стоимость альтернативы = 15,400,000 x (1.051/52 - 1) = $14,722,400

Поскольку неправильное заявление может привести к таким высоким возможным издержкам, участники BoLD должны предоставить депозит в подобном объеме. В настоящее время депозит в BoLD для подачи заявления составляет 3600 ETH, что примерно равно 9,4 миллионам долларов США.

Это делается для предотвращения серьезного ущерба системе со стороны злоумышленников, использующих задержку. Поскольку злоумышленники потеряют свою залоговую сумму при сомнениях, они могут создать возможные потери в размере до 14,7 миллионов долларов США, но потеряют около 9,4 миллионов долларов США. Таким образом, BoLD сдерживает атаки задержкой, требуя залог, равный наихудшим потерям.

Однако залог в размере 3600 ETH был установлен не только из-за задержки атаки. Чтобы защититься от атаки Сибилл, Arbitrum BoLD обеспечивает безопасность системы до тех пор, пока средства атакующего не превышают 6,5 раз сумму средств защищающегося, а именно 3600 ETH.

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

Предположим, что честный участник Алиса представила действительное заявление на сумму X ETH. Злонамеренный участник Боб, у которого есть 3600 ETH, может создать несколько злонамеренных заявлений. В этом случае Алисе нужно заблокировать Y ETH на каждое заявление Боба на низком уровне.

В модели разветвления Arbitrum блокировка средств означает согласие на состояние цепи от генезиса до заявления. Эта функция позволяет участникам перемещать заложенные ими средства из заявления A в его дочерние заявления A' и A''. Таким образом, Алиса перемещает свои изначально заложенные X ETH на более низкий уровень и блокирует Y ETH для каждого злонамеренного заявления Боба.

Если у Боба явно больше средств, что произойдет? Боб может создавать бесчисленные злонамеренные заявления, пока у Элис не иссякнут средства и она не сможет продолжать блокировку. В этот момент Элис не сможет продолжать деление, что позволит Бобу подтвердить неверные заявления.

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

Arbitrum называет этот показатель ресурсов отношением. Он показывает степень преимущества честных участников по сравнению с зловредными участниками. Это отношение выражается через отношение оплаты Газа (G) и залоговой суммы (S), которую должен выплатить каждый участник, как показано ниже:

Система сомнений BoLD разделена на три уровня. Путем поддержания определенного соотношения ресурсов на каждом уровне обеспечивается то, что защищающаяся сторона всегда имеет N-кратное преимущество перед атакующей стороной во всей системе. Arbitrum рассчитывает необходимую сумму залога на верхнем уровне и строит график на основе этого соотношения ресурсов.

(Стоимость залога верхнего уровня по отношению к ресурсам Arbitrum BoLD | Источник:Desmos)

Согласно данному графику, при соотношении ресурсов в 100 раз, необходимый депозит для верхнего уровня превышает 1 миллион ETH (более чем 4 трлн долларов США). Хотя более высокое соотношение ресурсов делает систему более безопасной от атак Сибилл, сумма депозита становится настолько высокой, что практически никто не может участвовать в системе, что делает ее неотличимой от централизованной системы, в которой только валидаторы предоставляют заявления.

Поэтому в BoLD коэффициент ресурсов установлен на уровне 6,5, что делает залог верхнего уровня равным 3600 ETH, а залоги первого и второго уровня установлены соответственно в размере 555 ETH и 79 ETH.

В общем, BoLD вычисляет пропорцию ресурсов и устанавливает сумму залога, чтобы обеспечить защитникам 6,5-кратное преимущество перед атакующими и предотвратить атаки Sybil.

2)Картези Дэйв

Dave от Cartesi впервые упомянулся в статье "Турнир несанкционированных аудитов" в декабре 2022 года, раньше, чем первый Вайтпейпер BoLD. Он призван обеспечить преимущество вычислительных ресурсов и капитала честных участников по сравнению с злоумышленниками. Архитектура Dave похожа на BoLD и имеет две ключевые особенности:

Путем правильного вычисления состояния доказательств (исторические обязательства) предотвращается злоумышленное разделение.

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

В структуре турнира используется механизм последовательного опрошения по принципу один на один.

Сомнения Дэйва проводятся не единовременно, а в форме чемпионата, как показано на рисунке ниже.

На рисунке показано, как происходит оспаривание, когда злонамеренный злоумышленник подает семь неправильных заявлений о сети. Из-за природы исторических обязательств честные участники, поддерживающие правильные утверждения (обозначенные зеленым цветом), объединяются вместе, образуя команду. В Dave они организованы в форме турнира и выстроены по схеме, каждый участник проводит оспаривание один на один. Оспаривание в одной и той же фазе происходит параллельно, и после недели, когда оспаривание завершено, победитель переходит на следующую фазу. На рисунке команда честных участников должна пройти три раунда оспаривания, чтобы выиграть турнир.

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

Документация Cartesi доказывает, что защитник всегда имеет экспоненциальное преимущество перед атакующим в любой ситуации. Другими словами, Dave гарантирует, что для защиты от атакующего потребуется логарифмический ресурс по сравнению с количеством атакующих. Это делает выполнение атаки Сибилл в Dave очень сложным, поэтому сумма залога Dave установлена на уровне не менее 1 ETH, что значительно ниже, чем в BoLD.

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

Td = 7 x log2(1 + NA) (дней)

Где NAN_ANA представляет собой количество злонамеренных заявлений. Однако сомнения Дэйва могут состоять из нескольких уровней для эффективного создания исторических обязательств. Здесь злонамеренные участники могут создавать NAN_ANA злонамеренных заявлений на каждом уровне сомнений, что увеличит общее время задержки, как показано ниже:

Td = 7 x [log2(1 + NA)]L (дней)

Где LL означает количество уровней в каждом возражении. Если, как показано на рисунке, есть семь злонамеренных заявлений и L=2, то полное разрешение возражений может занять до 9 недель, пользователи могут столкнуться с дополнительной задержкой вывода средств в течение 2 месяцев. Если количество уровней увеличивается или увеличивается количество злонамеренных заявлений, задержка может продлиться на несколько месяцев.

Cartesi стремится решить эту проблему с помощью ZK-SNARKs, подробное обсуждение которого будет проведено в разделе 4 «Возможные улучшения».

3）Оптимистичное доказательство ошибки (Optimism Fault Proof, OPFP)

OPFP - это неподтвержденный протокол, который в настоящее время используется в приложениях OP на основной сети, и имеет следующие особенности:

• Все механизмы сомнения в одновременных игровых деревьях

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

OPFP Архитектура игрового дерева и двоичного процесса | Источник: Файл оптимизма

Процесс деления происходит параллельно на дереве игры, показанном на рисунке. Листья дерева представляют состояние L2, каждый Узел в дереве соответствует одному состоянию L2, самый правый лист представляет самое новое состояние L2. Например, подача заявления в Узле 1 эквивалентна подаче состояния в Узле 31.

Эта структура позволяет представлять двоичное деление. Например, если валидаторы не согласны с корневым заявлением (Узел 1), они будут подавать заявление в Узел 2, соответствующий Узел 23 в дереве, так как это середина между Узлом 16 и Узлом 31. Затем отправитель Узла 1 проверит состояние L2 Узла 23 и, если согласен, подаст Узел 6 (Узел 27); если не согласен, то подаст Узел 4 (Узел 19) и продолжит этот процесс до нахождения разрыва.

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

Полная архитектура игрового дерева OPFP | Источник: Файл Optimism

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

В отличие от BoLD или Dave, OPFP не обязывает соблюдать правильное разделение на двоичные части через исторические обещания, поскольку стоимость создания и представления таких обещаний вне блокчейна/в блокчейне высока.

• Модульная настраиваемая игра о спорах В настоящее время OP Основная сеть только запустила два типа игр (лицензированные/нелицензированные). Оптимизм планирует в конечном итоге внедрить различные типы игр и уже достиг минимального интерфейса для поддержки этой цели. Следуя определенным именам функций и параметрам, можно создавать настраиваемые игры споров.

• Ограничение времени для оспаривания через шахматные часы

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

Интересно, что каждому участнику предоставляется не 7 дней, а 3,5 дня, что означает, что если никто не поднимет вопросы по выводу, вывод будет окончательно подтвержден в течение 3,5 дня.

Однако это не позволяет немедленно снять наличные. После окончательного определения вывода OPFP есть период охраны в течение 3,5 дней, в течение которого комиссия по безопасности может вмешаться и, при необходимости, аннулировать неправильный вывод.

Пользовательский процесс снятия средств в "Счастливом пути" | Источник: Блог OP Labs

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

Это приводит к вопросу: возможно ли, что вывод пользователей будет задержан на неделю или более, подобно ситуации с BoLD, если на OPFP возникнут сомнения? Ответ - да. В отличие от BoLD или Dave, Optimism предоставляет пользователям возможность реагировать на сомнения, основываясь на уникальных особенностях Протокола.

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

1. Alice подала заявление о правильном корневом состоянии.
2. Боб подал противовоззвание, в то время как Элис предприняла действия для защиты своего первоначального заявления.
3. Боб ждал, пока его часы почти не кончатся (3,5 дня), и затем задал себе вопрос о своем заявлении.

В этот момент Алисе следует ответить и запросить у Боба Маржа, но у нее унаследовано оставшееся время на часах у Боба, что, возможно, недостаточно для опровержения его заявления. Поэтому Боб может избежать потери своей Маржа, представив «заявление о влезании в поезд».

Заявление о попутчике в Optimism Fault Proof | Источник:L2Beat

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

Поэтому, если оставшееся время для предлагающего или оспаривающего составляет менее 3 часов, OPFP решает эту проблему, сбросив счетчик на 3 часа. Это обеспечивает достаточное время для опровержения заявления об попутчиках. Однако, если в течение следующего периода в двоичной системе не будет предпринято никаких действий в течение более 3 часов, оспаривание завершится.

Мы можем представить себе ситуацию, в которой этот механизм используется для проведения задержка атаки. Предположим, что честный участник Алиса представляет правильный вывод, с момента представления которого Алисой, начинает отсчет времени часового сомневающегося лица. Злонамеренный участник Боб ждет, пока часы сомневающегося лица истекут, чтобы представить неправильный вывод за 1 секунду до истечения времени. В этот момент, правила OPFP увеличивают время Боба до 3 часов. Алиса сделает ответ, а Боб будет продолжать использовать дополнительные 3 часа, предоставленные для каждого шага деления.

Это может вызвать задержку в разрешении спора. Боб может задерживаться на длительный период времени до 3.5 дней + 3 часа × максимальное количество бинарных разделений. MAX_GAME_DEPTH для OPFP составляет 73, что означает, что Боб может задерживать процесс на 3.5 дня + 3 часа × 36 = 8 дней. Если Алиса также примет подобные меры для задержки разрешения спора, процесс бинарного разделения может занять 16 дней.

Это означает, что пользователи не могут снять деньги в течение 16 дней? На самом деле это не так, потому что логика снятия средств Optimism делает это невозможным. В отличие от Arbitrum, который требует, чтобы снятие доказало, что оно содержится в определенном блоке L2, OP Stack использует механизм хранения доказательств, и запросы на снятие записываются в контракте L2ToL1MessagePasser L2. Это означает, что даже если время оспаривания определенного блока долгое, пользователи все равно могут дождаться завершения следующего блока и снять деньги на основе корневого хранилища контракта, содержащегося в этом блоке. Таким образом, даже если их запрос на снятие средств оспаривается, пользователи не обязаны ждать долгое время задержки, поскольку они могут использовать следующий блок.

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

1. Запустите вывод на L2 (initiateWithdrawal).
2. Доказать вывод на уровне L1 (proveWithdrawalTransaction), включая вывод вывода.
3. Подождите неделю, чтобы доказательство было готово задержка, затем завершите транзакцию вывода (finalizeWithdrawalTransaction).

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

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

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

Размер маржи OPFP | Источник: [Optimism File] (https://specs.optimism.io/fault-proof/stage-one/bond-incentives.html)

Другими словами, чем дольше задержка вызывает сомнения в OPFP, тем выше становится стоимость Маржа, потому что требуется экспоненциальный рост Маржа, что уменьшает стимул для задержки атаки со временем. Кроме того, поскольку вывод в OPFP можно отправлять в любое время, злоумышленнику трудно оценить ресурсы, необходимые для задержки атаки. Начальная установка Маржа составляет 0,08 ETH, а общая Маржа, которую необходимо представить при полном опрошен, составляет около 700 ETH.

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

В OPFP могут быть следующие векторы атак Sybil, которые могут привести к краже средств пользователей:

1. Атакующий создает несколько сомнений, что приводит к тому, что защитник использует все средства на Маржа и Gas费.
2. Злоумышленник непрерывно отправляет неправильные данные на вывод, вынуждая защитника реагировать, пока не исчерпает их средства на Маржа и комиссии за газ.

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

Однако это не означает, что средства пользователей в Основной сети OP находятся под угрозой. OPFP все еще находится на стадии 1, и Комитет по безопасности имеет право исправить любые неправильные результаты. Таким образом, даже если произойдет такая атака, Комитет по безопасности сможет вмешаться и защитить средства пользователей на мосту Основной сети OP.

Однако, чтобы перейти к фазе 2 OPFP, Optimism должен изменить механизм, чтобы обеспечить большее преимущество защитнику по сравнению с атакующим. Optimism готовит вторую версию игры с спорами (V2), чтобы решить эту проблему, подробности будут представлены в разделе 4 «Возможные улучшения».

4) Доказательство сбоя Kroma ZK (Kroma ZKFP)

Kroma - это L2, основанный на OP Stack, и перед введением OPFP в сентябре 2023 года он представил на своей основной сети нелицензируемую систему ZK Fault Proof. Kroma ZKFP имеет схожие характеристики с OPFP, но его особенность заключается в использовании ZK для генерации блочного доказательства и в использовании разложения, а не двоичного разделения, что существенно сокращает количество взаимодействий, необходимых для процесса вызова. Основные особенности Kroma ZKFP можно подвести к следующему:

• Снижение числа взаимодействий с помощью ZK и декомпозиции

Kroma ZKFP позволяет участникам найти разногласия в течение четырех взаимодействий. Когда возникает возражение, Kroma ZKFP обрабатывает его на 1,800 блоках, от предыдущего вывода до текущего. В отличие от метода бисекции, где диапазон делится на две части, в методе разложения предлагающий и возражающий делят диапазон на N частей. Процесс следующий:

После того, как каждому участнику будет представлены две транзакции, они определат блок, в котором есть разногласия. Оппонент может создать доказательство сбоя с нулевым разглашением (ZK), чтобы показать, что утверждение предлагающего является неверным. В Kroma ZKFP время ожидания двоичного разделения составляет 1 час, а время ожидания генерации доказательства ZK составляет 8 часов.

• Реализация Децентрализация валидаторы через механизм стимулирования01928374656574839201

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

Для этого Kroma изменила стек OP, распределив половину комиссий Gas, созданных в блокчейне, между валидаторами, представляющими выходные данные. Кроме того, Kroma планирует перенести эту систему наград на свой собственный токен KRO после TGE и планирует внедрить систему валидаторов, подобную DPoS, что позволит обычным пользователям вносить свой вклад в безопасность и активность цепочки, даже если они не запускают свой клиент.

Сумма Маржа в Kroma в настоящее время установлена на 0,2 ETH, чтобы обеспечить достаточную стоимость генерации ZK-подтверждений и выполнения бифуркации. Эта Маржа будет преобразована в KRO в системе валидаторов в будущем.

• Система одновременных 1 на 1 боевых вызовов

Для обеспечения равного и справедливого распределения стимулов Kroma устанавливает фиксированный интервал подачи заявок в 1 час и случайным образом выбирает валидаторов из заранее зарегистрированной коллекции валидаторов в качестве предложивших. Это предотвращает чрезмерную конкуренцию, которая может привести к потере Gas-сборов, и избегает монополии строителей Блоков, которые имеют право на сортировку транзакций, на вознаграждение.

Благодаря этому механизму Kroma ZKFP может работать в параллельной системе опровержения 1 к 1. Когда случайно выбранные валидаторы представляют свои результаты, любой может поднять вопрос, и опровержение происходит только между представителем результатов и оппонентом. Возможно несколько одновременных опровержений, и первый оппонент, представивший действительное доказательство ZK, побеждает в опровержении.

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

Однако, если у злоумышленника больше средств, чем у защищающей стороны, Kroma ZKFP все еще будет уязвима для атаки Сибилл, аналогичной OPFP. В сценарии атаки Сибилл в Kroma ZKFP может быть следующее:

• Атакующий постоянно оспаривает действительный вывод, пока средства подающего вывод не исчерпаются, после чего атакующий представляет доказательство ZK, чтобы выиграть оспаривание.

Подобно OPFP, Kroma ZKFP удаляет соответствующий вывод после успешного оспаривания. Поэтому, если произойдет такая атака, этот вывод может быть удален, что приведет к задержке вывода средств до 1 часа. Если атака будет продолжаться, все честные валидаторы могут исчерпать средства, что приведет к подтверждению неверного вывода и позволит злоумышленнику похитить средства пользователей.

Крома ZKFP все еще находится на нулевой стадии, и ее система подтверждения несовершенна по следующим причинам:

1. Начальная точка двоичного поиска основана на последнем представленном выводе, а не на последнем подтвержденном выводе.

В OPFP точкой отсчета обычно является последний подтвержденный вывод примерно неделю назад. Однако в Kroma ZKFP точкой отсчета является последний представленный вывод, который был представлен около 1 часа назад, а процесс деления происходит на 1,800 блоках.

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

2. Не было проверено, основаны ли валидаторы на правильных пакетных данных.

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

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

Однако на практике Совет безопасности может вмешаться, чтобы отозвать результаты, оспариваемые из-за ошибок, или удалить недействительные выходные данные, поэтому эти векторы атаки не повлияют на средства пользователей основной сети Kroma. Однако для достижения этапа 2 ZKFP Kroma необходимо внедрить механизмы защиты от этих уязвимостей. Kroma уже предложила улучшения, направленные на решение этих проблем, которые будут подробно описаны в разделе 4 «Возможные улучшения».

3.4 Вектор атаки #2：L1 аудит

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

Ситуация с Ethereum может повлиять на безопасность Rollup в двух случаях:

1. **ETH坊验证者对 Rollup доказательство мошенничества交易的审查 Если валидаторы или строители ETH фонда сговорятся и подадут злонамеренный выходной хеш в Optimistic Rollup, одновременно проверив все транзакции, связанные с доказательством мошенничества, что произойдет? Сомнения не будут разрешены в указанный срок, выходной хеш будет подтвержден, и средства пользователей могут быть подвергнуты риску. Это называется слабой проверкой. В случае Optimistic Rollup, если эта проверка продолжается дольше установленного времени (обычно 7 дней), средства пользователя могут быть подвержены риску.
2. Эфириум подвергся 51% атаке, что привело к проверке всех транзакций доказательства мошенничества **Эта ситуация включает в себя два возможных пути атаки:

• Во-первых, субъект может получить более 2/3 всего застейканного ETH, что позволит ему произвольно подтверждать блоки. В таком случае злоумышленник может проверять мошеннические транзакции доказательство, а также произвольно генерировать эти транзакции.
• Второй метод связан с «скрытой» атакой, в которой участвует участник с более чем 1/3 общего залога ETH-цепи. Об этом описано в исследовании «Неатрибутивная цензура мошенничества на основе доказательства второго уровня протокола L2» на странице [https://ethresear.ch/t/non-attributable-censorship-attack-on-fraud-proof-based-layer2-protocols/6492]. В этом случае злоумышленник, обладающий 1/3 залога ETH-цепи, может предотвратить подтверждение любого блока, который ему не нравится. Если злоумышленник продолжает голосовать за обычные блоки и молчит по поводу блоков с доказательством мошенничества, он может подтвердить злонамеренный корень вывода и похитить средства из Оптимистического Rollup. Это называется неатрибутивной цензурой мошенничества на основе доказательства второго уровня L2. Эта атака более сложна для обнаружения, чем простое получение более 2/3 залога и контроль над всеми блоками ETH-цепи.

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

3.5 Решение #2: задержка и полуавтоматическое восстановление 51% атаки за 7 дней

Для борьбы с этими Вектор атаки Optimistic Rollup в настоящее время вводит задержку в 7 дней для вывода средств. Эти 7 дней были предложены Виталиком на основе идеи, что 7 дней достаточно для противодействия атакам на проверку.

Давайте проанализируем, достаточно ли 7-дневный период опрошенности в Optimistic Rollup для защиты от цензуры, учитывая два типа цензуры: слабую и сильную цензуру.

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

Здесь нужно учитывать два фактора:

1. Чтобы успешно оспорить в течение 7 дней, необходимо успешно провести несколько сделок.

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

2. Необходимо разумно предположить пропорцию валидаторов, связанную с проверкой. В настоящее время большинство строителей блоков в ETH-сообществе (известных как централизованные) не проходят проверку, и учитывая долю отдельных залоговщиков в ETH, шансы на то, что большинство (99,9%, например) валидаторов сговорятся для проверки, практически равны нулю.

Обзор основных строителей блоков ETH | Источник: твит Justin Drake

Учитывая эти два аспекта, если мы предположим, что 99,5% валидаторов (это все же слишком экстремальное предположение) участвуют в проверке и вычисляем вероятность успешной отправки 30-40 вызовов биржи требуемого протокола (например, BoLD или OPFP) честными участниками, то во всех случаях вероятность успеха приближается к 100%. Кроме того, с появлением будущих решений (например, включение в список или несколько одновременных предложений, таких как BRAID, APS + FOCIL), способность сопротивляться проверке может дополнительно увеличиться, что снизит риск потери пользовательских средств в Optimistic Rollup из-за слабой проверки.

Итак, будет ли 7 дней достаточно в условиях строгой проверки? Упомянутая ранее атака на 51% может быть решена только через социальный форк. Особенно сложно обнаружить атаки, связанные с невозможностью атрибуции, и их нельзя предотвратить с помощью решений, разработанных для слабых проверок (например, включение в список).

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

1. легкий клиент监控内存池，检测某些交易在Блок中未被包含的时间是否过长。
2. Если определенная транзакция находится в пуле памяти в течение одного дня и не включена в блок, то будет запущена кнопка "Вы согласны с проведением социального форка?", что позволит сообществу запустить жесткий форк на основе этого соглашения.

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

В этом случае средства, пострадавшие от атаки 51%, должны оставаться заблокированными до завершения исполнения социального форка. Аналогичная ситуация произошла во время The DAO Hardфорк, где средства хакеров были заблокированы в sub-DAO на 27 дней, пока они не смогли вывести. За это время сообщество ETH Fang успешно провело Хардфорк, не позволив хакерам обналичить средства (подробнее см. [пост Виталика на Reddit] (https://www.reddit.com/r/ethereum/s/zQw1YOnomE)).

Другими словами, даже если произошло нападение на 51%, средства должны оставаться заблокированными до социального форка. В этом случае 7-дневный период вывода средств в Optimistic Rollup действует как буфер. Если в течение этой недели не будет проведен социальный форк, средства пользователей в Optimistic Rollup могут быть украдены, а также выведены на централизованную биржу или перемешаны через Tornado Cash, что приведет к тому, что средства практически невозможно вернуть пользователям после социального форка.

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

С этой точки зрения некоторые критикуют OPFP за сокращение этого срока до 3,5 дней, что делает его более уязвимым для атаки на жесткий контроль. Однако эта критика не имеет оснований. Поскольку оптимизм все еще находится в фазе 1, опекунам предоставляется достаточный период буферизации для проверки правильности корневого состояния, и вывод средств может быть осуществлен только после окончания дополнительного 3,5-дневного периода опеки. Таким образом, даже в случае атаки на жесткий контроль злоумышленнику придется подождать 7 дней, прежде чем осуществить вывод. Кроме того, злоумышленник должен будет тщательно проверить все сомнительные транзакции в течение целой недели, поскольку опекуны также должны быть проверены, чтобы предотвратить их отказ от подтверждения злонамеренных выводов.

Однако ключевым является то, что Ethereum должен гарантировать возможность обработки социального форка в течение 7 дней. Это означает, что инструменты для обнаружения атаки 51% должны быть готовы, и требуется достаточное исследование и моделирование, чтобы определить, возможно ли осуществить социальный форк в течение 7 дней. Только в этом случае задержка вывода средств в технологии Optimistic Rollup может рассматриваться как эффективное обеспечение.

3.6 Вектор атаки #3: Использование уязвимости в системе доказательства мошенничества

Большинство сомнений в Протоколе возникают, когда участники находят определенную точку (инструкцию или Блок), в которой они не согласны, а затем генерируют доказательство, показывающее, что утверждение другого участника неверно. Виртуальная машина, используемая для генерации таких доказательств, называется доказательство мошенничества Виртуальная машина (Fraud Proof VM), а программное обеспечение, используемое на этой Виртуальной машине для генерации доказательств, называется программой (program). Каждый Протокол использует разные доказательства мошенничества Виртуальная машина и программу, как показано ниже:

Каждая система доказательства мошенничества предназначена для доказательства правильности определенного результата выполнения в EVM в блокчейне. Но что произойдет, если в этой системе (будь то Виртуальная машина или программа) есть уязвимости?

Эта проблема может быть исследована с использованием Вектор атаки, обнаруженного Yoav Weiss в OVM. Из-за уязвимости функции Откат в OVM возможно совершение атаки, однако для осуществления атаки необходимо предположение о создании «мошеннической сделки». Мошенническая сделка - это сделка, которая выполняется нормально на Rollup, но дает разные результаты при использовании виртуальной машины и программы, вызывающих сомнения в доказательствах мошенничества. Поскольку система доказательств мошенничества должна генерировать результаты, идентичные EVM, возможность создания мошеннической сделки означает наличие уязвимости в системе доказательств мошенничества.

Yoav обнаружил несколько уязвимостей в системе доказательства мошенничества OVM и может смоделировать эту атаку, генерируя мошеннические транзакции. Простой пример атаки, обнаруженный им, заключается в том, что стоимость Газа для операций Код операции SSTORE и SLOAD (для сохранения и чтения состояния) в StateManager OVM неправильно записывается. Это означает, что любая транзакция, хранящая или считывающая значение в контракте (почти все транзакции, кроме простых переводов ETH), будет отмечена как мошенническая транзакция в процессе проверки, даже если она правильно выполняется в Rollup.

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

Это также одна из причин, по которой недавно OP Mainnet перешел от безлицензионного режима своей системы доказательства отказа к режиму, в котором могут присоединяться только авторизованные участники. После того, как OPFP был применен в основную сеть, аудит безопасности выявил доказательство мошенничества системы (Cannon и op-program) а также несколько уязвимостей в Протоколе вызова оспаривания игры. Чтобы предотвратить злоупотребление системой, Optimism объявил 17 августа переход на систему разрешений.

Конечно, уязвимости Виртуальной машины могут не оказывать существенного влияния на Rollup, находящийся в фазе 0 или фазе 1, так как Совет безопасности может вмешаться в любое время, чтобы исправить спорные результаты. Это было предложено ранее OP Labs. Фактически, OP Labs поделились своей аудиторской рамкой на форуме Optimism, где описаны стандарты для проведения внешнего аудита в определенных ситуациях.

(Система аудита OP Labs | Источник: [Optimism Forum] (https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864))

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

Однако, поскольку уязвимости уже были обнаружены, необходимо решить эти проблемы. Optimism исправили эти проблемы в рамках своего обновления сети Granite, что позволило OP Mainnet восстановиться до фазы 1.

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

3.7 Решение №3: Множественное доказательство

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

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

Например, представьте себе многократную систему доказательств с использованием Cannon, оптимизма и asterisc ZK доказательств, работающую на виртуальной машине (на основе Risc-V). В случае сомнений будут происходить следующие события:

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

Подиграшка Cannon, использующая традиционный метод OPFP. Используйте asterisc для создания подигры ZK для доказательства отказа.

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

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

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

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

4. возможные улучшения

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

4.1 Улучшение пространства для каждого Протокола

1) Arbitrum BoLD

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

• 6,5-кратное соотношение ресурсов слишком мало для преимущества защитника.
• Депозит по подаче основного заявления составляет 3,600 ETH, что является слишком большой суммой.

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

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

Вторая проблема заключается в том, что требуется залог в размере 3 600 ETH, что еще более затрудняет решение этой проблемы. Размер залога BoLD не только направлен на борьбу с атаками Sybil, но и на устрашение задержки атаки. Размер залога является функцией TVL (общей стоимости заблокированных средств), и даже при использовании ZK не удастся существенно снизить Падение. Чтобы решить эту проблему, BoLD внедряет механизм пула залога, позволяющий нескольким участникам совместно нести залог.

2)Картези Дэйв

Dave эффективно справился с атакой Сибил через свою структуру турнира, но, как уже упоминалось ранее, она подвержена задержке. Максимальное время задержки вычисляется как функция количества злонамеренных заявок NA и уровня стейкинга L по формуле: Td = 7 x [log2(1 + NA)]L (дней)

Если NA = 7 и L = 3, протокол может столкнуться с задержкой до четырех месяцев, что причинит пользователю значительные неудобства и убытки, так как вывод будет задержан.

ZK может помочь решить эту проблему. Фиксация уровня L на 1 (как в строке BoLD ++) может сократить максимальное время задержки до: Td = 7 x log2(1 + NA) (дней)

По сообщениям, Cartesi использует технологию ZK на основе RISC Zero для этого улучшения. Однако остаются опасения, достаточно ли такое улучшение для полной защиты от атак задержки. Если NA = 7, то протокол все еще может столкнуться с дополнительной задержкой, продолжительностью до двух недель, и стоимость атакующего будет составлять только залог в 7 ETH, плюс плата за Gas и стоимость обязательств вне цепочки. Для цепочек с высокой стоимостью Закрытая позиция такое наказание может быть недостаточным, чтобы остановить атаку задержки.

(Dave: механизм подозрений с жирным стилем | Источник: L2Beat Medium)

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

Td = 7 x log8 (1 + NA) (дней)

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

Однако недостатком этого метода является ослабление преимущества защищающегося при сопротивлении атаке Sybil. Хотя BoLD предоставляет структуру, в которой у защищающегося есть N-кратное преимущество перед атакующим, Дэйв создал структуру, в которой преимущество защищающегося на несколько порядков превышает преимущество атакующего.

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

3) Оптимизация безошибочности (OPFP)

Недостатком OPFP является его уязвимость перед атаками Сибила, потому что затраты на атаку и защиту равны. OP Labs в контрверсиальной игре V2 предложили решение этой проблемы.

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

(Заявление о ветвлении |. в Controversy Game V2.) Источник: Optimism Specs GitHub)

В предыдущей OPFP были векторы атаки Sybil:

1. Создать множество сомнений, чтобы исчерпать средства Маржа и Газ защитника.
2. Непрерывно представлять ложные выходные данные, заставляя защитника реагировать и истощать его ресурсы.

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

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

Таким образом, OPFP может эффективно противостоять атакам Сибилл, введя ветви, предусмотренные в спорной игре V2.

4)Kroma ZK Безотказный (Kroma ZKFP)

Kroma ZKFP сталкивается с двумя проблемами: уязвимостью перед атаками Сибил и недостаточной системой подтверждения. Чтобы перейти к фазе 1, Kroma ZKFP должна решить следующие две проблемы:

1. Начальная точка двоичного метода основана на последнем представленном выводе, а не на окончательно определенном выводе.
2. Валидаторы не проверили, основаны ли сомнения на правильных пакетных данных.

Kroma планирует перейти с Halo2 zkEVM Scroll на Succinct SP1 zkVM, чтобы решить эти две проблемы и продвинуться на 1 этап.

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

Для второго вопроса Kroma будет использовать бездоверительное доказательство на основе ZK. Конкретный порядок работы следующий:

（Использование недоверительного вывода с нулевым доказательством ZK | Источник: Lightscale Notion）

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

Здесь Kroma планирует проверить, были ли данные из L1 правильно извлечены путем ZK-проверки. Если данные были получены только через доверенное RPC-соединение за пределами программы ZK, то нельзя утверждать, что данные партии не были подвергнуты подмене. Можно подтвердить, что программа обратилась к правильному Блоку и извлекла партию данных, используя доказательство связности Блокхеша, сгенерированное ZK. Эти Блоки идут от Блока O (источник L1 для Блока T на L2) до Блока C (Блок L1, созданный во время оспаривания). Если оспаривающая сторона конструирует Блок T L2 на основе неправильных данных партии, то Блокхеш L1, на который ссылается оспаривающая сторона при извлечении данных партии, будет отличаться от фактического Блокхеша L1, содержащего данные партии (включая T1), и не будет связан с Блоком C. Таким образом, если нет хеш-конфликта, подтверждение связности L1 Блока с помощью ZK может доказать, что оспаривающая сторона построила Блок L2 на основе правильных данных партии.

Kroma планирует использовать ZK для проверки точности пакетных данных, что позволяет проверить связность хеш-блоков от L1 Блок O до C. Если оппоненты на основе неправильных пакетных данных создадут L2 Блок T, то хеш L1, на который они ссылаются, будет отличаться от хеш-блока с правильными пакетами, и он не будет подключен к Блоку C. Поскольку нет конфликта хешей, этот метод можно использовать для проверки правильности пакетных данных в процессе оспаривания.

С помощью этих улучшений Kroma ZKFP сможет перейти к этапу 1. Однако для достижения этапа 2 Kroma нуждается в дополнительных решениях для защиты от атак Sybil, в том числе изменения Протокола на Все-против-Всех (All-vs-All) и переработки механизма Маржа.

4.2. Обзор

5. будущее доказательства мошенничества

5.1. Фаза 2 Rollup - ваш капитал в безопасности

Как уже упоминалось, Optimistic Rollups развивается в направлении фазы 2. Arbitrum стремится к реализации фазы 2 на основе BoLD. План внедрения BoLD уже опубликован на форуме управления и получил много поддержки, в настоящее время он развернут на тестовой сети. Если не будут обнаружены серьезные проблемы безопасности, Arbitrum, скорее всего, реализует фазу 2 через BoLD до конца текущего года.

Optimism также работает над реализацией фазы 2. Чтобы перейти к фазе 2 на основной сети OP, необходимо завершить спорную игру V2 и иметь поддержку множественных доказательств с различными механизмами подтверждения. Несмотря на то, что стандарты все еще совершенствуются, спорная игра V2 эффективно решает слабые места существующего OPFP, обеспечивает надежную защиту от атак Сибилл и приближает нас к фазе 2. Кроме того, различные команды, включая OP Labs, Succinct, Kroma и Kakarot, активно разрабатывают множественные доказательства, вкладывая значительные исследовательские ресурсы в создание разнообразных способов доказательства в стеке OP. Таким образом, за исключением серьезных проблем, Optimism планирует перейти к фазе 2 в первом полугодии следующего года.

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

Следовательно, с конца этого года по следующий год, основные Rollup с большой пользовательской базой, такие как Arbitrum, OP Основная сеть и Base, ожидается, что перейдут к этапу 2, унаследовав полную безопасность Ethereum. Это в значительной степени может утихомирить критику вроде "Rollup всего лишь мультиподпись" или "Rollup в любой момент может забрать ваши средства".

5.2. ZK доказательство мошенничества是未来

Большинство обсуждаемых Протоколов могут получить выгоду от внедрения ZK доказательства мошенничества. Например, применение ZK в Arbitrum BoLD может увеличить ресурсное соотношение, сделав его более устойчивым к атакам Сибилл, в то время как Cartesi Dave может сделать его менее уязвимым к задержкам. OPFP также внедряет ZK для поддержки системы множественных доказательств, что может снизить сумму Маржи и повысить безопасность Протокола.

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

Через этот способ, Доказательство мошенничества ZK играет ключевую роль в безопасности и децентрализации Optimistic Rollup.

5.3. Как проявляется ZK Rollup? доказательство мошенничества会变弱吗?

В этот момент некоторые читатели могут спросить: Если доказательство мошенничества и механизм оспаривания настолько сложны, не станет ли ZK роллапы лучшим выбором? До некоторой степени это правильно. В ZK Rollups достижение фазы 2 не требует учета сложных экономических факторов, средства пользователей не подвергаются риску кражи в ходе событий проверки L1, пользователи могут вывести свои средства в течение нескольких часов.

Переход от оптимистичных роллапов к ZK роллапам может быть быстрее, чем ожидалось. Это связано с быстрым улучшением основного недостатка ZK роллапов - высокой стоимости и времени генерации доказательств. Недавно Succinct Labs представила OP Succinct, основанную на OP Stack версию ZK, предоставляющую фреймворк для легкого запуска ZK роллапов.

Введение в OP Sucinct | Источник: [Краткий блог] (https://blog.succinct.xyz/op-succinct/)

Однако все еще есть несколько факторов, которые следует учесть. Во-первых, это стоимость. В OP Succinct стоимость создания Блок доказательства составляет примерно $0.005-$0.01, а затраты на запуск проверяющего оцениваются в диапазоне от $6,480 до $12,960 в месяц. Если объем обработки транзакций цепи (TPS) высок, эти издержки могут дополнительно возрасти.

(Стоимость доказательства в различных сетях Бенчмарк | Источник: Блог Succinct )

Например, на базе сети OP Succinct средние затраты на генерацию подтверждения каждого Блока составляют около $0.62. Исходя из этой цифры, ежемесячные затраты составят $803,520. Это дополнительные затраты, отсутствующие у Optimistic Rollups, даже если затраты на ZK Падение, операционные затраты на ZK Rollups всегда будут выше, чем у Optimistic Rollups.

Второе соображение - это влияние на Децентрализация. В ZK Rollups валидаторы должны запускать программы доказательства, что является более сложным и затратным, чем запуск программы доказательства мошенничества в Optimisitic Rollups. Кроме того, из-за медленной генерации доказательств в ZK системе пользователь не может проверить транзакцию в режиме реального времени. Хотя более высокие аппаратные требования могут повысить скорость генерации доказательств, чтобы соответствовать скорости выполнения транзакций, это означает, что для работы с программой доказательства требуется высокая вычислительная среда. В идеале любой человек должен иметь возможность запустить Узел для обеспечения безопасности цепи, но ZK пока не достигли этого уровня.

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

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

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

5.4. доказательство мошенничества применимо только к Rollup?

Мы уже изучили оптимистические роллапы Ethereum и их механизмы доказательства мошенничества. Также, у этого доказательства мошенничества есть какие-то другие сферы применения?

1. Снова застейкать Протокол доказательство мошенничества можно активно использовать в Протоколе заморозки. Возьмем, например, Eigenlayer, это типичная служба заморозки на блокчейне ETH.

Eigenlayer - это сервис, который позволяет безопасно замораживать ETH в залог с помощью застейки. В Eigenlayer операторы могут внести ETH или LST пользователей на основе контрактов застейки внутри Eigenlayer и участвовать в проверке, выбирая несколько служб активной проверки (AVS). С помощью Eigenlayer Протокол может легко создавать AVS и снижать затраты на стартовые затраты валидаторов.

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

**Пример слэшинга AVS | Источник: Eigenlayer GitHub

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

Хотя эта функция разрезания пока не реализована в Eigenlayer, недавно была объявлена модель общей безопасности, планируется включить функцию разрезания в следующей версии. Это позволит использовать доказательство мошенничества для разрезания.

2. Уровень доступности данных ** **доказательство мошенничества также может использоваться на уровне доступности данных (DA). Одним из типичных примеров является предложенное и реализованное Celestia доказательство мошенничества. У Celestia есть технология, позволяющая лайт-нодам проверять правильность хранения данных на основе выборочной доступности данных. Давайте более детально изучим этот концепт.

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

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

В Celestia есть два типа доказательств мошенничества:

• доказательство мошенничества состояния переключения

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

Выборочная доступность данных Celestia | Источник: Документация Celestia

Celestia валидаторы структурируют данные транзакции в матрицу k x k, затем расширяют ее до матрицы 2k x 2k с использованием технологии, называемой 2D Reed-Solomon кодирование. Затем они вычисляют общие 4k Корень Меркла для каждой строки и столбца, и включают результаты хеширования этих Корень Меркла в заголовок блока для дальнейшего распространения.

Только с помощью информации Корень Меркла в Заголовке блока, лайт-нод может проверить, правильные ли данные имеют валидаторы Celestia. Лайт-нод запрашивает данные из случайной точки в матрице 2k x 2k и получает соответствующие строки и столбцы Корень Меркла от валидаторов. Если эти данные могут быть проверены с значениями в Заголовке блока, то можно доверять тому, что у валидаторов есть правильные данные.

Однако появился важный фактор: что, если валидаторы злонамеренно выполняют кодирование Рида-Соломона? Celestia решает эту проблему, внедряя механизм, называемый "доказательством мошенничества с плохим кодированием". Если полный узел Celestia обнаружит неправильное кодирование во время процесса восстановления блока, он сгенерирует доказательство мошенничества, содержащее высоту блока, неправильную часть кодирования и доказательство отказа, и передаст его лайт-ноду. Лайт-нод проверит это доказательство, чтобы подтвердить, что данные действительно содержат ошибку кодирования, и перестанет использовать неправильные данные.

Кроме того, Celestia также предложила механизм доказательства мошенничества для перехода состояния.

Архитектура блока Celestia | Источник: [Блог DAO] (https://mirror.xyz/contributiondaoblog.eth/_VknA2qiU0AF2aHcfCRxNjNQ2zLgOOWDnDXjs7fQR1o)

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

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

3. Машинное обучение Искусственный интеллект и блокчейн стали популярной темой в 2024 году, и в этой области было проведено множество исследований. Одним из наиболее заметных аспектов является сочетание блокчейна и машинного обучения.

Основные причины применения машинного обучения в блокчейне:

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

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

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

• доказательство мошенничества Виртуальная машина（Fraud Proof VM）：эта Виртуальная машина выполняет машинное обучение вывода, ее функциональность аналогична WAVM от Arbitrum или Cannon от Optimism.
• opML Смарт-контракт：этот контракт проверяет доказательство мошенничества, действует аналогично контракту MIPS.sol Optimism.
• Игра проверки валидаторы, которые вызывают сомнения, взаимодействуют с сервером посредством двоичного поиска, чтобы определить отдельные ошибочные шаги в Виртуальной машине, а затем создают доказательство мошенничества для этого шага и отправляют его в контракт opML.

Валидационная игра на ORA opML | Источник: [Документ ORA] (https://docs.ora.io/doc/technology/proving-frameworks-zkml-opml-opp-ai/opml)

Через этот механизм доказательств мошенничества, opML использует безопасность и доверие блокчейна, обеспечивая при этом экономически эффективную среду для обучения и проверки моделей машинного обучения.

6. Заключение

Optimistic Rollup активно работает над улучшением доказательство мошенничества и протокола, чтобы унаследовать большую безопасность Ethereum и создать более доверчивую цепь. Arbitrum планирует достичь фазы 2 через BoLD к концу этого года, а Optimism также работает над фазой 2, полагаясь на контроверсиальную игру V2 и многофакторное доказательство. К следующему году пользователи Optimistic Rollup смогут взаимодействовать с сетью с более высокой степенью безопасности, не беспокоясь о возможности потери своих средств в Rollup. Кроме того, Виталик упомянул в своем блоге, что количество Rollup на фазе 1 и выше также ожидается увеличиться.

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

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

7. Ссылки

(https://l2beat.com/scaling/summary)[L2Beat]

[Мошенничество доказывает войну |.] Лука Донно на L2Beat](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a)

[Файл Arbitrum] (https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction)

[Оптимистичная статья] (https://docs.optimism.io/).

[Спецификации оптимизма] (https://specs.optimism.io/fault-proof/index.html)

Недоступный судьей матч | Cartesi

[Технические характеристики Kroma] (https://specs.kroma.network/experimental/zk-fault-dipute-game/overview.html)

BoLD：быстрое и недорогое разрешение споров

[Экономика BoLD] (https://github.com/OffchainLabs/bold/blob/main/docs/research-specs/Economics.pdf)

Почему срок вызова оптимистичного Rollup составляет 7 дней? | Кельвин Фихтер в OP Labs

доказательство мошенничества уже сломано | Gabriel Coutinho de Paula в Cartesi

Оптимистичное путешествие во времени | Yoav Weiss

Описание первого успешного вызова на основной сети Kroma

Распаковка прогресса в Децентрализация базовой линии | OP Labs

Неатрибутивная цензурная атака на Layer2 Протоколы на основе доказательства мошенничества

[Система аудита OP Labs] (https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864)

[Деривация, не требующая доверия |.] Крома](https://www.notion.so/Complete-Trust-less-Derivation-for-Zero-Knowledge-Dispute-Game-bfaebd36375d48169424064237986dea?pvs=4)

Представление OP Succinct：полное доказательство действительности на стеке OP | Succinct

[Eigenlayer GitHub] (https://github.com/Layr-Labs/eigenlayer-contracts/blob/d3730b5dd1b94d5e676e0c7a00a031574263c2c3/docs/experimental/AVS-Guide.md)

[Файлы Селестии] (https://docs.celestia.org/)

[Вклад Блог DAO] (https://mirror.xyz/contributiondaoblog.eth/_VknA2qiU0AF2aHcfCRxNjNQ2zLgOOWDnDXjs7fQR1o)

[Документ ORA] (https://docs.ora.io/doc/technology/proving-frameworks-zkml-opml-opp-ai/opml)

Заявление:

1. Эта статья взята с [research.2077], все права принадлежат оригинальным авторам [sm-stack и BTC Penguin]. Если у вас есть возражения к этому репосту, пожалуйста, свяжитесь с командой Gate Learn, они оперативно рассмотрят ваш запрос.
2. Отказ от ответственности: высказывания и мнения, выраженные в этой статье, представляют собой только личное мнение автора и не являются инвестиционными рекомендациями.
3. Команда Gate Learn переводит статьи на другие языки. За исключением случаев, когда это указано, запрещено копирование, распространение или плагиат статей.