Оптимистичные мосты. Новый вид кроссчейн-коммуникаций

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

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

Когда мы писали о трилемме в прошлом году, мы разделили мосты на три типа в зависимости от того, как они проверяются:

В каждом случае механизм проверки приводил к компромиссу как минимум в ОДНОМ из трех очень желательных свойств:

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

Вот как они работают на высоком уровне:

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

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

Внешне проверенные (т. е. multisig, валидатор, PoS, mpc или порог) мосты (и сами сайдчейны/L1!) используют допущение честного большинства — другими словами, m of nучастники системы должны правильно проверять обновления. С точки зрения криптоэкономики это означает:

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

В качестве альтернативы полная экономическая безопасность моста, проверенного извне, может быть достигнута, если система может (а) надежно доказать мошенничество и (б) вернуть пользователям полную сумму всех ценностей, которые могут быть потеряны в результате взлома. Другими словами, пользователи и/или LP могут быть застрахованы только в том случае, если стоимость сокращаемой доли (например, в RUNE на Thorchain) больше или равна TVL всей системы. Обратите внимание, что (а) является сильным предположением — окончательное доказательство мошенничества здесь само по себе требует ненадежного механизма межцепной связи, что делает проблему несколько рекурсивной.

Шаблон «наблюдатель + защита от мошенничества», с другой стороны, использует единственное допущение честного верификатора. Другими словами, оптимистичные мосты требуют, чтобы 1 of n стороны в системе правильно проверяли обновления.

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

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

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

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

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

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

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

В оптимистичных мостах мошенничество всегда детерминистически доказуемо в исходной цепочке (аналогично тому, как мошенничество ORU всегда доказуемо в L1). Для этого наблюдатель просто должен представить доказательство недопустимого обновления контракта цепочки происхождения, что затем приводит к сокращению средства обновления. Затем наблюдатель отправляет подписанное сообщение в цепочку назначения, чтобы «отключить» канал связи в течение 30 минут (до того момента, когда эти мошеннические данные можно считать завершенными).

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

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

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

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

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

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

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

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

Например, взлом Ronin Bridge стоимостью 625 миллионов долларов был бы невозможен, если бы Ронин использовал оптимистичный мост, даже если бы все ключи были скомпрометированы.

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

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

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

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

Тем не менее, ретрансляторы заголовков не лишены своих проблем:

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

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

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

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

По этой причине мы невероятно взволнованы Nomad и думаем, что это огромный шаг вперед для кроссчейн и перекрестной связи.

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

Протокол совместимости Nomad работает в основной сети Ethereum, Moonbeam и Milkomeda, и вскоре планируется развернуть его во всех основных сетях.

Информация: [Website] [Twitter] [Discord] [Docs] [Github] [Blog]

Connext — это сеть взаимодействия L2 Ethereum.

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

Информация: [Website] [Twitter] [Discord] [Docs] [Github] [Blog]