Завьялов Илья Николаевич про протоколы AMP.

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

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

Но как в конечном итоге будет выглядеть взаимосвязанная сеть Web3?

Мы верим, что все мосты в конце-концов эволюционируют в межцепочечные протоколы обмена сообщениями или протоколы «Arbitrary Message Passing» (AMP), которые позволят приложениям передавать информацию из одной (исходной) цепи в другую (нужную нам/цепь назначения).

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

Каждый AMP протокол должен обладать двумя важнейшими способностями:

1. Работоспособность: Способность передавать информацию от цепи-источника в цепь назначения.
2. Верификация: Возможность проверки достоверности информации идущей из исходной цепи (источника) в цепь назначения.

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

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

Доверие коду/математике: доказательства которое может проверить любой человек сущесвуют on-chain. Такие решения опираются на ПО (легкие ноды) которое для цепи назначения проверяет наличие консенсуса по транзакции в исходной цепи (подробности будут ниже).

Доверие теории игр: При проведении транзакций пользователям приходится полагаться на добросовестность третьих сторон, например валидаторов и тд. Роль теории игр в данном случае, в том, что для третьей стороны наболее выгодным является наиболее честное поведение. Для обеспечения такого поведения могут применяться экономические стимулы или механизмы оптимистичной безопасности (такие же используются оптимистичными ролл-апами, L2 решениями для Ethereum такими как Optimism и Arbitrum — прим. перев.)

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

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

Способ интеграции/архитектура (то как информация передается — прим. перев.):

Модель из точки в точку (Point-to-Point): Между каждым источником и каждым пунктом назначения должен быть установлен выделенный канал связи.

Хабовая система (Hub and Spoke): Необходимо установить канал связи с центральным хабом, который уже обеспечивает связь со всеми остальными блокчейнами, подключенными к этому же хабу.

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

Как легкие клиенты проверяют консенсус цепочки источника на цепочке назначения?

Легкий клиент/узел — это программное обеспечение, которое подключается к полным узлам для взаимодействия с блокчейном.

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

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

Особенности этого механизма:

1. Безопасность:

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

2. Примеры реализации:

• Если соединяются цепи одного типа (с одним и тем же механизмом консенсуса и фреймворком), то реализация легкого клиента на обеих сторонах будет одинаковой. Пример: IBC для всех цепей на базе Cosmos SDK.
• Если соединяются цепи разных типов (разные фреймворки приложений или типы консенсуса), то реализация легкого клиента будет отличаться. Пример: Composable finance работает над тем, чтобы цепочки Cosmos SDK можно было подключать через IBC к Substrate (фреймворк приложений экосистемы Polkadot). Для этого требуется легкий клиент Tendermint на цепочке Substrate и так называемый beefy light client добавленный в цепь работающую на Cosmos SDK.

3. Сложности:

• Ресурсоемкость: Запускать парные легкие клиенты на всех цепочках дорого, так как добавление записи в блокчейн стоит дорого.
• Масштабируемость: Реализация легкого клиента необходима для обеих комбинаций цепей. Учитывая что реализация зависит так же от архитектуры цепей, сложно масштабировать и соединять разные экосистемы.
• Эксплойты уязвимостей кода: Ошибки в коде могут привести к уязвимостям (простыми словами безопасность экосистемы равна безопасности наименее защищенной цепи в этой экосистеме — прим.перев.)

Как zk-протоколы проверяют достоверность транзакций в исходной цепи?

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

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

ZK протоколы предлагают решение для сокращения газа и времени проверки. На цепи (on-chain) выполняется только проверка доказательства вычислений, а сами вычисления производятся вне цепи (off-chain). Проверка доказательства вычислений может быть выполнена за меньшее время и с меньшим количеством газа, чем выполнение всех исходных вычислений на цепи.

Особенности этих протоколов:

1. Безопасность:

• Доказательство с нулевым разглашением (Zero knowledge proofs или zK proofs) позволяют одному человеку доказывать другому, что утверждение является верным, не раскрывая саму информацию.

Представьте, что вы находитесь в комнате с человеком, которому завязали глаза. На столе перед вами лежат два шарика — белый и черный. Вам необходимо доказать второму человеку (верификатору), что шарики действительно разных цветов, при этом не раскрывая каких именно. Для этого вы должны попросить его спрятать оба шарика под стол. После этого попросите достать только один, чтобы вы могли его увидеть. Далее шарик снова прячется и в следующий раз верификатор снова может показать либо белый, либо черный. Однако вы сможете доказать утверждение, поскольку точно знаете, менял ли он их под столом. Тем не менее полностью верификатор в истинности факта не будет уверен, ведь могли иметь место удача или обман. Эта проблема решается путем повторения эксперимента n количество раз. С каждым раундом шанс случайно оказаться правым будет уменьшаться вдвое: после пяти повторений вероятность обмана составит 1 к 32, после 10 раундов — 1 к 1024, а после 20 раундов — примерно 1 к 1 000 000. Благодаря повторениям можно добиться желаемого уровня надежности доказательства, однако абсолютной уверенности достичь при этом невозможно.

2. Реализация: Cуществует несколько видов zK proofs: SNARK, STARK, VPD, SNARG

• В настоящее время самые распространенные это zk-SNARK и zk-STARK. Первые требуют начальной доверительной установки между проверяющим и верифицирующим.
• zk-STARK был создан как альтернативная версия zk-SNARK и считается более быстрой и дешевой реализацией технологии. К тому же zk-STARK не требует начальной доверительной настройки

3. Сложности:

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

4. Примеры:

• Polymer ZK-IBC от Polymer Labs, Succinct Labs. Компания Polymer работает над созданием IBC с поддержкой multi-hop соединений, чтобы увеличить возможности подключения, сократив при этом количество необходимых парных соединений.

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

1. Экономические стимулы: Множество внешних участников (например, валидаторы) приходят к консенсусу относительно обновленного состояния исходной цепи. Это похоже на мульти-подпись (особый тип цифровых подписей, который позволяет двум или более пользователям подписывать документы вместе как группа — прим. перев.), но для того, чтобы стать валидатором, участники должны поставить на кон определенное количество токенов, которые могут быть уничтожены в случае обнаружения их вредоносной деятельности. В открытых блокчейнах любой может накопить долю и стать валидатором. Существуют также вознаграждения за блок, которые служат экономическим стимулом, при следовании участниками протоколу. Таким образом они получают экономический стимул работать честно. Однако если сумма, которую можно украсть, значительно превышает поставленную на кон долю, участники могут попытаться сговориться, чтобы украсть эти средства. Примеры: Axelar, Celer IM

2. Оптимистичная безопасность: Оптимистичные решения в области безопасности опираются на доверии к меньшинству, которое предполагает что только меньшинство участников блокчейна живые, ведут себя честно и следуют правилам протокола. В этих решениях может быть достаточно если гарантом выступает только один честный участник сети. Здесь тоже присутствуют экономические стимулы, но, на практике, даже честный гарант может пропустить мошенническую операцию. Examples: Nomad, ChainLink CCIP.

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

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

Особенностями этих типов решений:

1. Безопасность:

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

2. Реализация на практике

• Цепь посрединик со своими валидаторами: Группа внешних валидаторов следит за исходной цепью, при каждом запросе достигает консенсуса в отношении действительности транзакции и если консенсус достигнут — подтверждают его на цепи назначения. Валидаторы обычно должны поставить на кон определенное количество токенов, которые могут быть уничтожены в случае раскрытия их вредоносной деятельности. Примеры: Axelar Network, Celer IM
• Внецепочечные агенты: Off-chain агенты могут быть использованы для реализации оптимистичных роллапов, когда в течение предустановленного временного промежутка off-chain агенты могут предоставить доказательства мошенничества и отменить транзакцию. Пример: Nomad полагается на независимых агентов вне цепочки для передачи заголовка и криптографического доказательства. ChainLink CCIP будет использовать существующую сеть оракулов для мониторинга и подтверждения межцепочечных транзакций.

3. Сложности:

• Участники могут злоупотребить доверием вступив в сговор, из-за чего требуются дополнительые меры для обеспечения безопасности такие как квадратичное голосование.
• Завершенность: Решения основанные на оптимистичной безопасности привносят сложности с окончательностью транзакций, так как пользователям приходится ждать завершения “окна вмешательства” для того чтобы их транзакции стали окончательными.

4. Преимущества:

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

1. Предположене о честности большинства: Эти решения основаны на реализации мульти-подписи, когда несколько субъектов проверяют и подписывают транзакции. Как только минимальный порог достигнут, транзакция считается действительной. Предполагается, что большинство субъектов являются честными, и если большинство этих субъектов подписывает определенную транзакцию, то она действительна. Единственное, что здесь поставлено на карту — это репутация участников. Примеры: Multichain (Anycall V6), Wormhole.
2. Независимость: Эти решения разделяют весь процесс передачи сообщений на две части и полагаются на различные независимые субъекты для управления этими двумя процессами. Предполагается, что эти субъекты независимы друг от друга и не вступают в сговор. Пример: LayerZero. Заголовки блоков передаются по запросу децентрализованными оракулами, а доказательства транзакций отправляются через ретрансляторы. Если доказательство совпадает с заголовками, транзакция считается действительной. Приложения, построенные на LayerZero, могут выбирать оракул и ретранслятор (или размещать собственный оракул/ретранслятор), тем самым ограничивая риск сговора между отдельными оракулами и ретрансляторами. Конечные пользователи должны быть уверены, что либо LayerZero, либо третья сторона, либо само приложение запускает оракул и ретранслятор независимо и без злого умысла.

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