Исходный текст: «Система рисков L2Bridge».

Автор: bartek.eth

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

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

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

Тип моста

Для конечных пользователей соединение активов означает получение депозита определенного актива из исходной цепочки и отправку этого актива пользователю в целевой цепочке.

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

В общих чертах этот процесс происходит двумя способами:

Мосты токенов на основе сообщений. Эти мосты позволяют ликвидности течь по цепочкам в форме сообщений. Как правило, они позволяют создавать актив в целевой цепочке после его блокировки или уничтожения в исходной цепочке. Примеры: Rollup Bridge, собственный мост Polygon, Anyswap (anyCall) и сеть Axelar. Сеть ликвидности. Также существуют мосты, которые будут выкупать часть отчеканенных активов. Они позволяют пользователям передавать активы в другие цепочки, при условии, что эти активы были переданы заранее через «Мост сообщений». Примеры: Connecxt на основе Nomad Bridge, Hop на основе Hop Optimistic Bridge, некоторые другие HTLC (контракт блокировки времени хеширования, контракт блокировки времени хеширования) и условные передачи (например, nova и т. д.).

Безопасность мостов передачи сообщений

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

Легкий клиент проверяет достоверность состояния

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

Пример: здесь приведены все накопительные пакеты. L1 проверит переход состояния L2 через FraudProof (доказательство мошенничества) или ValidityProof (доказательство действительности).

Консенсус легкой проверки клиента

Описание: Мост, который проверяет консенсус исходной цепочки в целевой цепочке. Это зависит от механизма консенсуса, используемого цепочкой источников, и обычно включает проверку подписи кворума текущего комитета валидаторов, если цепочка источников использует протокол консенсуса предложений и голосования в стиле PBFT (например, Tendermint, HotStuff, Casper FFG). протокол). В качестве альтернативы, если исходная цепочка использует протокол PoW или протокол PoS в стиле «самой длинной цепочки» (например, Ouroboros, ETH 2.0 LMD Ghost и т. д.), тогда используйте соответствующие правила разветвления для проверки самой длинной цепочки.

Примеры: мост NEAR Rainbow (игнорирование компонента Optimistic, связанного со сложностью процесса проверки механизма подписи NEAR), мост PoS Polygon (проверка консенсуса цепочки Heimdall) и Cosmos IBC (проверка подписи другой цепочки Cosmos).

внешний набор валидаторов

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

В ролях: Червоточина, Мультичейн, Акселар, ДеБридж, Синапс, Звездные врата.

оптимистичная проверка

Описание: Мост с периодом вызова (период вызова, примечание переводчика: относится к периоду времени, в течение которого другие валидаторы могут оспорить достоверность сообщения моста, если сочтут его недействительным).

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

Продолжительность периода испытания: чем дольше, тем лучше. Размер набора наблюдателей: разрешение не требуется > требуется разрешение.

Примеры: Hop Protocol, Connext Amarok, Across, Nomad Token Bridge.

Гибридный метод аутентификации

Описание: Существует структура, сочетающая вышеуказанные методы проверки.

Безопасность сети ликвидности

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

Возьмем простой пример: Алиса в цепочке А хочет передать активы в цепочку Б. Боб (поставщик ликвидности, LP) уже имеет активы той же стоимости в цепочке B. Он использует свои активы в цепочке B для предоставления услуг по обмену баланса Алисы в цепочке A и собирает комиссию за обслуживание. В конце концов, Алиса получит актив в цепочке B, а Боб получит актив + комиссию за обслуживание в цепочке A.

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

Есть и другие способы обмена активами:

HTLC: Также известный как контракт блокировки времени хеширования, он может использоваться для атомарного обмена активами между двумя сторонами в цепочке. Обычно от пользователя требуется всего два шага: один — заблокировать, другой — разблокировать. Возможный сценарий сбоя заключается в том, что ваши средства заблокированы на фиксированный период «сна». Примеры: Connext NXTP, Liqualit. Условный перевод: позволяет LP использовать ярлыки для обмена сообщениями, что позволяет LP немедленно предоставлять средства конечным пользователям и получать средства из моста для обмена сообщениями при каждом соединении средств. В случае неудачи, если нет LP, обеспечивающих ликвидность, будет активирован медленный путь. Примеры: Hop, Connext Amarok, MakerDAO Teleport. Внешний валидатор: позволяет пользователям переводить средства доверенному поставщику мостов, который обещает передать средства в другую цепочку. Возможный сценарий неудачи здесь заключается в том, что ваши средства будут потеряны. Пример: Бинанс

сопротивление цензуре

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

Типичное решение:

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

Общая активная неисправность

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

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

текучесть

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

Неограниченный (мост может чеканить собственные/авторитетные токены) Разрешенный (ликвидность обеспечивается оператором моста) Без разрешения (любой LP может обеспечить ликвидность)

Дополнительные мысли и показатели Возможность обновления Разрешенные участники Объем переводов за последние 24 часа Уникальные переводы за последние 24 часа Доступная ликвидность Поддерживаемые токены/блокчейны