Agglayer является одним из основных компонентов Polygon 2.0. Буква «Agg» в его названии означает агрегирование, отражая его роль в качестве слоя агрегации. По сути, его функция аналогична протоколам межсетевой совместимости, таким как Layerzero и Wormhole, направленным на соединение фрагментированного мира блокчейна. Однако методы их строительства отличаются. Проще говоря, традиционные протоколы межсетевой совместимости сродни строительным компаниям, строящим мосты повсюду, проектируя и строя мосты для соединения различных цепочек или протоколов (что может быть сложно для гетерогенных цепочек). В отличие от этого, Agglayer функционирует скорее как «локальная сеть», состоящая из механизмов обмена, где подключенные цепочки могут присоединиться к «локальной сети», просто подключив «кабель» (доказательство ZK) для обмена данными. По сравнению с повсеместным строительством мостов, это быстрее, удобнее в использовании и обеспечивает лучшую совместимость.
Концепция Agglayer во многом обязана дизайну Shared Validity Sequencing от Umbra Research, который стремится достичь атомной межцепной совместимости среди нескольких Оптимистичных Rollups. Путем совместного использования последователя вся система может однородно обрабатывать упорядочивание транзакций и публикацию корней состояний по всем Rollups, обеспечивая атомарность и условное выполнение.
Конкретная логика реализации включает три компонента:
Диаграмма показывает процесс работы контракта MintBurnSystemContract, когда используется один общий последователь.
Поскольку текущие Rollups обычно поддерживают двунаправленную передачу сообщений между Layer 1 и Layer 2, вместе с другими специальными предварительными компиляциями, Umbra добавляет простую межцепочечную систему, состоящую из контракта MintBurnSystemContract (Burn and Mint), чтобы дополнить три компонента, как показано выше.
Согласованность корневого хэша Меркля: Корневые хэши burnTree на Chain A и mintTree на Chain B должны совпадать, обеспечивая согласованность и атомарность межцепочечной операции.
В этом дизайне Rollup A и B используют один общий секвенсор. Этот общий секвенсор отвечает за публикацию пакетов транзакций и корней состояний обоих Rollups в Ethereum. Общий секвенсор может быть централизованным, как большинство существующих секвенсоров Rollup, или децентрализованным, подобным подходу Metis. Ключевым моментом в системе является то, что общий секвенсор должен публиковать пакеты транзакций и корни состояний обоих Rollups в L1 в одной транзакции.
Общий секвенсор получает транзакции и конструирует блоки для A и B. Для каждой транзакции на A секвенсор проверяет, взаимодействует ли она с MintBurnSystemContract. Если транзакция успешно взаимодействует с функцией записи, секвенсор пытается выполнить соответствующую транзакцию минта на B. Если транзакция минта прошла успешно, секвенсор включает транзакцию записи на A и транзакцию mint на B; Если транзакция минта завершается сбоем, секвенсор исключает обе транзакции.
Говоря простыми словами, эта система является прямым расширением существующего алгоритма построения блоков. Секвенсор выполняет транзакции и условно вставляет триггерные транзакции из одного накопителя в другой. Во время проверки на предмет мошенничества в основной цепочке необходимо только убедиться в правильности сжигания в цепочке А и минта в цепочке Б (т.е. согласованность корня Меркла). В этом сценарии несколько накопительных пакетов ведут себя как одна цепочка. По сравнению с монолитным накопительным пакетом эта структура обеспечивает лучшую поддержку сегментирования, независимость приложений и функциональную совместимость. Однако к недостаткам относятся повышенная нагрузка на узлы при проверке и секвенировании, а вероятность внедрения невелика из-за соображений распределения прибыли и автономии свертки.
Agglayer интегрирует вышеупомянутые решения, внедряя более эффективные улучшения и два ключевых компонента: Unified Bridge и Pessimistic Proofs.
Единый мост: Рабочий процесс единого моста включает сбор и агрегацию состояний всех подключенных цепей в слой агрегации, который затем генерирует унифицированное доказательство для Ethereum. Этот процесс включает три этапа состояния: предварительное подтверждение (которое позволяет более быстрое взаимодействие при временных предположениях состояния), подтверждение (которое проверяет правильность представленного доказательства) и завершение. В конечном итоге это доказательство может подтвердить допустимость транзакции всех подключенных цепей.
Оптимистичные доказательства: Подключение Rollups к мультицепочечной среде представляет две основные проблемы: 1. Введение различных валидаторов и механизмов консенсуса усложняет безопасность; 2. Для вывода средств из оптимистичного Rollup требуется период в 7 дней. Чтобы решить эти проблемы, Polygon представляет новый метод нулевого доказательства, известный как Пессимистические доказательства.
Идея за Пессимистическими доказательствами заключается в том, чтобы предположить, что все блокчейны, подключенные к AggLayer, могут потенциально действовать злоумышленно, и сделать наихудшие предположения для всех межцепочных операций. Затем AggLayer использует доказательства с нулевым разглашением для проверки правильности этих операций, обеспечивая, что даже в случае злонамеренного поведения, целостность межцепочных операций остается неприкосновенной.
С помощью этой схемы можно достичь следующих характеристик:
Как упоминалось ранее, цель Agglayer совпадает с целью протоколов взаимодействия цепей. Но какой из них превосходит других? Прежде чем сравнивать, нам нужно понять два вопроса: 1. Почему взаимодействие цепей так сложно? 2. Каковы общие решения для взаимодействия цепей?
Как и знаменитая трилемма блокчейна, кроссчейн-протоколы также сталкиваются с трилеммой совместимости. Из-за фундаментальной предпосылки децентрализации блокчейны, по сути, являются конечными автоматами, которые не могут получать внешнюю информацию. Хотя AMM и оракулы заполнили некоторые пробелы в DeFi, кроссчейн-протоколы сталкиваются с гораздо более сложными проблемами. В некотором смысле, мы никогда не сможем по-настоящему извлечь какие-либо реальные токены из исходной цепочки, что приведет к появлению различных обернутых токенов, таких как xxBTC и xxETH. Однако этот подход является рискованным и централизованным, потому что реальные BTC и ETH должны быть заблокированы в кроссчейн-контрактах моста в исходной цепочке, в то время как вся кроссчейн-структура может столкнуться с такими проблемами, как несоответствие активов, несовместимость протоколов из-за разных виртуальных машин, проблемы доверия, проблемы двойного расходования и проблемы с задержкой. Чтобы быть эффективными и экономичными, большинство кроссчейн-решений по-прежнему полагаются на кошельки с несколькими подписями. Вот почему мы до сих пор часто слышим о сбоях кроссчейн-мостов.
Теперь давайте рассмотрим проблему более подробно на более низком уровне. По словам основателя Connext Арджуна Бхуптани, протоколы межцепочечной связи могут оптимизировать только два из трех следующих ключевых атрибутов:
Ранние классификации кроссчейн-мостов часто основывались на таких фигурах, как Виталик Бутерин, который классифицировал кроссчейн-технологии на три типа: блокировки времени хеширования, проверка свидетелей и ретрансляционная валидация (легкая проверка клиента). Позже Арджун Бхуптани переклассифицировал кроссчейн-решения в нативную валидацию (отсутствие доверия + расширяемость), внешнюю валидацию (расширяемость + обобщенность) и нативную валидацию (отсутствие доверия + обобщенность). Эти методы проверки основаны на различных моделях доверия и технических реализациях для удовлетворения различных потребностей в безопасности и совместимости.
Мосты с подтвержденной поддержкой нативных токенов:
Мосты, проверенные нативно, полагаются на механизмы консенсуса исходной и целевой цепочек для прямой проверки правильности транзакции. Для этого метода не требуется дополнительных слоев проверки или посредников. Например, некоторые мосты могут использовать смарт-контракты для создания логики проверки прямо между двумя блокчейнами, что позволяет им подтверждать транзакции через свои собственные механизмы консенсуса. Этот подход повышает безопасность, так как он прямо зависит от врожденных механизмов безопасности участвующих цепочек. Однако его реализация может быть более технически сложной, и не все блокчейны поддерживают прямую нативную проверку.
Мосты, проверенные внешними источниками:
Внешне проверенные мосты используют сторонних валидаторов или кластеры валидаторов для подтверждения достоверности транзакции. Эти валидаторы могут быть независимыми узлами, членами консорциума или другими типами участников, работающими вне исходной и целевой цепочек. Этот метод обычно включает передачу сообщений между цепочками и проверку логики, выполняемую внешними сущностями, а не непосредственно обрабатываемую участвующими блокчейнами. Внешняя проверка обеспечивает более широкую совместимость и гибкость, так как она не ограничена определенными цепочками, но вводит дополнительный уровень доверия и потенциальные риски безопасности. Несмотря на риски централизации, внешняя проверка является наиболее популярным методом межцепочечной связи, так как он эффективен, гибок и экономичен.
Местно подтвержденные мосты:
Локально проверенные мосты предполагают, что целевая цепочка проверяет состояние исходной цепочки для подтверждения транзакций и выполнения последующих транзакций локально. Обычно это включает в себя запуск легкого клиента виртуальной машины целевой цепочки в исходной цепочке или параллельно. Локальная проверка требует честного меньшинства или синхронного предположения, когда в комитете есть хотя бы один честный ретранслятор (честное меньшинство) или, если комитет не работает, пользователи должны передавать транзакции сами (синхронное предположение). Локальная верификация является наиболее надежным методом межцепочечной связи, но также является дорогостоящей, менее гибкой в разработке и больше подходит для блокчейнов с высокой схожестью конечных автоматов, например, между сетями Ethereum и L2 или блокчейнами, разработанными на основе Cosmos SDK.
Текущие решения межцепочечного взаимодействия [1]
Компромиссы, сделанные в различных областях, привели к различным типам межцепных решений. Кроме методов верификации, текущие межцепные решения могут быть классифицированы несколькими способами, каждое из которых применяет уникальные подходы к обмену активами, передаче и вызову контрактов.
· Обмен токенов: Этот метод позволяет пользователям торговать определенным активом на одной блокчейн и получать эквивалентный актив на другой цепочке. С использованием технологий, таких как атомные свопы и кросс-цепные автоматизированные рыночные делители (AMM), могут быть созданы пулы ликвидности на различных цепочках для облегчения обмена различными активами.
· Мосты активов: Этот метод включает блокировку или сжигание активов на исходной цепочке через смарт-контракты и разблокировку или выпуск новых активов на целевой цепочке через соответствующие смарт-контракты. Эта техника может быть дополнительно разделена на три типа в зависимости от обработки активов:
· Native Payments: Этот метод позволяет приложениям на исходной цепи запускать операции платежей с использованием собственных активов на целевой цепи. Он также может запускать межцепные платежи на основе данных с одной цепи на другой цепи. Этот метод в основном используется для расчетов и может быть основан на данных блокчейна или внешних событиях.
· Взаимодействие умных контрактов: Этот метод позволяет умным контрактам на исходной цепочке вызывать функции умных контрактов на целевой цепочке на основе локальных данных, обеспечивая создание сложных кросс-чейн приложений, включая обмен активами и мостовые операции.
· Программируемые мосты: это продвинутое решение взаимодействия, которое объединяет функции моста активов и передачи сообщений. При передаче активов с исходной цепи на целевую цепь, вызовы контрактов на целевой цепи могут быть немедленно запущены, что позволяет использовать различные функции межцепочечного взаимодействия, такие как стейкинг, обмен активами или хранение активов в смарт-контрактах на целевой цепи.
Давайте сравним Agglayer с текущими протоколами межцепочечного взаимодействия, на примере LayerZero, самого влиятельного протокола межцепочечного взаимодействия. LayerZero использует улучшенную версию внешней верификации, преобразуя источник доверия для верификации в два независимых элемента — оракул и релеер. Этот минималистический подход решает проблемы внешней верификации, делая его программным мостом, способным выполнять различные операции. Логически, кажется, что он элегантно разрешил так называемую трилемму. С общей точки зрения, LayerZero имеет потенциал стать межцепочечным хабом всей Web3, решая проблемы, такие как фрагментированный пользовательский опыт и разрыв ликвидности, вызванный взрывом цепей в модульную эру. Вот почему ведущие венчурные капиталы сделали большие ставки на такие протоколы.
Однако, какова реальность? Отложив в сторону недавние споры относительно операций с раздачей LayerZero, рассмотрим его проблемы развития. Достижение идеального состояния подключения всей Web3 крайне сложно, а его децентрализация под сомнением. В его ранней версии V1 оракул LayerZero представлял риски взлома и потенциально вредоносного поведения (Wormhole, который использует институты отрасли в качестве узлов-хранителей, часто сталкивается с подобными критиками). Эти опасения были смягчены только с появлением децентрализованной сети проверки (DVN) в V2, что требовало значительных ресурсов B-стороны.
Кроме того, разработка протоколов межцепочечного взаимодействия включает в себя работу с протоколами гетерогенных цепей, форматами данных, операционной логикой и вызовом различных смарт-контрактов. Истинная совместимость в Web3 требует не только индивидуальных усилий, но и сотрудничества различных проектов. Ранние пользователи LayerZero могут вспомнить, что он в основном поддерживал межцепочечное взаимодействие для блокчейнов на основе EVM, с ограниченной поддержкой других экосистем. Это также верно для Agglayer, но Agglayer обеспечивает сверхнизкую задержку и асинхронную совместимость, что делает его более подобным интернету, которым мы пользуемся ежедневно.
В целом, подход Agglayer к агрегации для использования в одной цепочке проще, эффективнее и соответствует текущим тенденциям модульного подхода. Однако абсолютного превосходства между ними в настоящее время нет. Кроссчейн-протоколы по-прежнему обладают такими преимуществами, как более широкая ликвидность, более зрелая экосистема и большая проактивность. Сила Agglayer заключается в его способности по-настоящему агрегировать конкурирующие цепочки уровней 1 и 2, нарушая игру с нулевой суммой фрагментированной ликвидности и пользователей в эпоху взрывного роста цепей. Он обеспечивает многоцепочечные взаимодействия с низкой задержкой, абстракцию собственной цепочки и общие пулы ликвидности без необходимости обернутых токенов, что представляет собой значительную возможность для цепочек с длинным хвостом и цепочек для конкретных приложений.
В общем, Agglayer в настоящее время является самым перспективным решением для межцепочечного взаимодействия, в разработке также есть аналогичные проекты, такие как «Join-Accumulate Machine» Polkadot. История Web3 перешла от монолитного к модульному, и следующим шагом будет объединение.
Хотя проект Agglayer все еще находится в начальной стадии, он уже интегрировал несколько ключевых проектов. Вот три значимых примера:
X Layer - это проект Ethereum Layer 2, построенный на Polygon CDK. Он соединяет OKX и сообщество Ethereum, позволяя любому желающему участвовать в действительно глобальной онлайн-экосистеме. Как публичная цепь ведущей биржи, интеграция с Agglayer принесет обширную ликвидность проектам в агрегационном слое. Кроме того, веб-кошелек OKX Web3, служащий доступовым уровнем для обычных пользователей, также может обеспечить лучшую поддержку для Agglayer.
Union - это слой инфраструктуры с нулевым разглашением, построенный на Cosmos и используемый для общих сообщений, передачи активов, NFT и DeFi. Он полагается на проверку согласованности без привлечения доверенных сторон, оракулов, мультиподписей или MPC. Как интегрированная цепочка, Union обеспечивает глубокую связь между экосистемами EVM и Cosmos в рамках слоя агрегации. Используя Union в качестве шлюза IBC, это позволяет подключаться к Union, а затем к IBC, тем самым объединяя две в противном случае фрагментированные модульные экосистемы.
Astar Network это сеть для предприятий, развлекательных и игровых проектов в Японии и по всему миру, посвященная продвижению «Web3». Она использует поддержку межвиртуальной машины от Polygon и Polkadot для предоставления настраиваемых решений блокчейн. Как первая полностью интегрированная цепочка Agglayer, Astar будет напрямую получать доступ к многомиллиардному общему пулу ликвидности и достигать роста реальных пользователей.
Agglayer является одним из основных компонентов Polygon 2.0. Буква «Agg» в его названии означает агрегирование, отражая его роль в качестве слоя агрегации. По сути, его функция аналогична протоколам межсетевой совместимости, таким как Layerzero и Wormhole, направленным на соединение фрагментированного мира блокчейна. Однако методы их строительства отличаются. Проще говоря, традиционные протоколы межсетевой совместимости сродни строительным компаниям, строящим мосты повсюду, проектируя и строя мосты для соединения различных цепочек или протоколов (что может быть сложно для гетерогенных цепочек). В отличие от этого, Agglayer функционирует скорее как «локальная сеть», состоящая из механизмов обмена, где подключенные цепочки могут присоединиться к «локальной сети», просто подключив «кабель» (доказательство ZK) для обмена данными. По сравнению с повсеместным строительством мостов, это быстрее, удобнее в использовании и обеспечивает лучшую совместимость.
Концепция Agglayer во многом обязана дизайну Shared Validity Sequencing от Umbra Research, который стремится достичь атомной межцепной совместимости среди нескольких Оптимистичных Rollups. Путем совместного использования последователя вся система может однородно обрабатывать упорядочивание транзакций и публикацию корней состояний по всем Rollups, обеспечивая атомарность и условное выполнение.
Конкретная логика реализации включает три компонента:
Диаграмма показывает процесс работы контракта MintBurnSystemContract, когда используется один общий последователь.
Поскольку текущие Rollups обычно поддерживают двунаправленную передачу сообщений между Layer 1 и Layer 2, вместе с другими специальными предварительными компиляциями, Umbra добавляет простую межцепочечную систему, состоящую из контракта MintBurnSystemContract (Burn and Mint), чтобы дополнить три компонента, как показано выше.
Согласованность корневого хэша Меркля: Корневые хэши burnTree на Chain A и mintTree на Chain B должны совпадать, обеспечивая согласованность и атомарность межцепочечной операции.
В этом дизайне Rollup A и B используют один общий секвенсор. Этот общий секвенсор отвечает за публикацию пакетов транзакций и корней состояний обоих Rollups в Ethereum. Общий секвенсор может быть централизованным, как большинство существующих секвенсоров Rollup, или децентрализованным, подобным подходу Metis. Ключевым моментом в системе является то, что общий секвенсор должен публиковать пакеты транзакций и корни состояний обоих Rollups в L1 в одной транзакции.
Общий секвенсор получает транзакции и конструирует блоки для A и B. Для каждой транзакции на A секвенсор проверяет, взаимодействует ли она с MintBurnSystemContract. Если транзакция успешно взаимодействует с функцией записи, секвенсор пытается выполнить соответствующую транзакцию минта на B. Если транзакция минта прошла успешно, секвенсор включает транзакцию записи на A и транзакцию mint на B; Если транзакция минта завершается сбоем, секвенсор исключает обе транзакции.
Говоря простыми словами, эта система является прямым расширением существующего алгоритма построения блоков. Секвенсор выполняет транзакции и условно вставляет триггерные транзакции из одного накопителя в другой. Во время проверки на предмет мошенничества в основной цепочке необходимо только убедиться в правильности сжигания в цепочке А и минта в цепочке Б (т.е. согласованность корня Меркла). В этом сценарии несколько накопительных пакетов ведут себя как одна цепочка. По сравнению с монолитным накопительным пакетом эта структура обеспечивает лучшую поддержку сегментирования, независимость приложений и функциональную совместимость. Однако к недостаткам относятся повышенная нагрузка на узлы при проверке и секвенировании, а вероятность внедрения невелика из-за соображений распределения прибыли и автономии свертки.
Agglayer интегрирует вышеупомянутые решения, внедряя более эффективные улучшения и два ключевых компонента: Unified Bridge и Pessimistic Proofs.
Единый мост: Рабочий процесс единого моста включает сбор и агрегацию состояний всех подключенных цепей в слой агрегации, который затем генерирует унифицированное доказательство для Ethereum. Этот процесс включает три этапа состояния: предварительное подтверждение (которое позволяет более быстрое взаимодействие при временных предположениях состояния), подтверждение (которое проверяет правильность представленного доказательства) и завершение. В конечном итоге это доказательство может подтвердить допустимость транзакции всех подключенных цепей.
Оптимистичные доказательства: Подключение Rollups к мультицепочечной среде представляет две основные проблемы: 1. Введение различных валидаторов и механизмов консенсуса усложняет безопасность; 2. Для вывода средств из оптимистичного Rollup требуется период в 7 дней. Чтобы решить эти проблемы, Polygon представляет новый метод нулевого доказательства, известный как Пессимистические доказательства.
Идея за Пессимистическими доказательствами заключается в том, чтобы предположить, что все блокчейны, подключенные к AggLayer, могут потенциально действовать злоумышленно, и сделать наихудшие предположения для всех межцепочных операций. Затем AggLayer использует доказательства с нулевым разглашением для проверки правильности этих операций, обеспечивая, что даже в случае злонамеренного поведения, целостность межцепочных операций остается неприкосновенной.
С помощью этой схемы можно достичь следующих характеристик:
Как упоминалось ранее, цель Agglayer совпадает с целью протоколов взаимодействия цепей. Но какой из них превосходит других? Прежде чем сравнивать, нам нужно понять два вопроса: 1. Почему взаимодействие цепей так сложно? 2. Каковы общие решения для взаимодействия цепей?
Как и знаменитая трилемма блокчейна, кроссчейн-протоколы также сталкиваются с трилеммой совместимости. Из-за фундаментальной предпосылки децентрализации блокчейны, по сути, являются конечными автоматами, которые не могут получать внешнюю информацию. Хотя AMM и оракулы заполнили некоторые пробелы в DeFi, кроссчейн-протоколы сталкиваются с гораздо более сложными проблемами. В некотором смысле, мы никогда не сможем по-настоящему извлечь какие-либо реальные токены из исходной цепочки, что приведет к появлению различных обернутых токенов, таких как xxBTC и xxETH. Однако этот подход является рискованным и централизованным, потому что реальные BTC и ETH должны быть заблокированы в кроссчейн-контрактах моста в исходной цепочке, в то время как вся кроссчейн-структура может столкнуться с такими проблемами, как несоответствие активов, несовместимость протоколов из-за разных виртуальных машин, проблемы доверия, проблемы двойного расходования и проблемы с задержкой. Чтобы быть эффективными и экономичными, большинство кроссчейн-решений по-прежнему полагаются на кошельки с несколькими подписями. Вот почему мы до сих пор часто слышим о сбоях кроссчейн-мостов.
Теперь давайте рассмотрим проблему более подробно на более низком уровне. По словам основателя Connext Арджуна Бхуптани, протоколы межцепочечной связи могут оптимизировать только два из трех следующих ключевых атрибутов:
Ранние классификации кроссчейн-мостов часто основывались на таких фигурах, как Виталик Бутерин, который классифицировал кроссчейн-технологии на три типа: блокировки времени хеширования, проверка свидетелей и ретрансляционная валидация (легкая проверка клиента). Позже Арджун Бхуптани переклассифицировал кроссчейн-решения в нативную валидацию (отсутствие доверия + расширяемость), внешнюю валидацию (расширяемость + обобщенность) и нативную валидацию (отсутствие доверия + обобщенность). Эти методы проверки основаны на различных моделях доверия и технических реализациях для удовлетворения различных потребностей в безопасности и совместимости.
Мосты с подтвержденной поддержкой нативных токенов:
Мосты, проверенные нативно, полагаются на механизмы консенсуса исходной и целевой цепочек для прямой проверки правильности транзакции. Для этого метода не требуется дополнительных слоев проверки или посредников. Например, некоторые мосты могут использовать смарт-контракты для создания логики проверки прямо между двумя блокчейнами, что позволяет им подтверждать транзакции через свои собственные механизмы консенсуса. Этот подход повышает безопасность, так как он прямо зависит от врожденных механизмов безопасности участвующих цепочек. Однако его реализация может быть более технически сложной, и не все блокчейны поддерживают прямую нативную проверку.
Мосты, проверенные внешними источниками:
Внешне проверенные мосты используют сторонних валидаторов или кластеры валидаторов для подтверждения достоверности транзакции. Эти валидаторы могут быть независимыми узлами, членами консорциума или другими типами участников, работающими вне исходной и целевой цепочек. Этот метод обычно включает передачу сообщений между цепочками и проверку логики, выполняемую внешними сущностями, а не непосредственно обрабатываемую участвующими блокчейнами. Внешняя проверка обеспечивает более широкую совместимость и гибкость, так как она не ограничена определенными цепочками, но вводит дополнительный уровень доверия и потенциальные риски безопасности. Несмотря на риски централизации, внешняя проверка является наиболее популярным методом межцепочечной связи, так как он эффективен, гибок и экономичен.
Местно подтвержденные мосты:
Локально проверенные мосты предполагают, что целевая цепочка проверяет состояние исходной цепочки для подтверждения транзакций и выполнения последующих транзакций локально. Обычно это включает в себя запуск легкого клиента виртуальной машины целевой цепочки в исходной цепочке или параллельно. Локальная проверка требует честного меньшинства или синхронного предположения, когда в комитете есть хотя бы один честный ретранслятор (честное меньшинство) или, если комитет не работает, пользователи должны передавать транзакции сами (синхронное предположение). Локальная верификация является наиболее надежным методом межцепочечной связи, но также является дорогостоящей, менее гибкой в разработке и больше подходит для блокчейнов с высокой схожестью конечных автоматов, например, между сетями Ethereum и L2 или блокчейнами, разработанными на основе Cosmos SDK.
Текущие решения межцепочечного взаимодействия [1]
Компромиссы, сделанные в различных областях, привели к различным типам межцепных решений. Кроме методов верификации, текущие межцепные решения могут быть классифицированы несколькими способами, каждое из которых применяет уникальные подходы к обмену активами, передаче и вызову контрактов.
· Обмен токенов: Этот метод позволяет пользователям торговать определенным активом на одной блокчейн и получать эквивалентный актив на другой цепочке. С использованием технологий, таких как атомные свопы и кросс-цепные автоматизированные рыночные делители (AMM), могут быть созданы пулы ликвидности на различных цепочках для облегчения обмена различными активами.
· Мосты активов: Этот метод включает блокировку или сжигание активов на исходной цепочке через смарт-контракты и разблокировку или выпуск новых активов на целевой цепочке через соответствующие смарт-контракты. Эта техника может быть дополнительно разделена на три типа в зависимости от обработки активов:
· Native Payments: Этот метод позволяет приложениям на исходной цепи запускать операции платежей с использованием собственных активов на целевой цепи. Он также может запускать межцепные платежи на основе данных с одной цепи на другой цепи. Этот метод в основном используется для расчетов и может быть основан на данных блокчейна или внешних событиях.
· Взаимодействие умных контрактов: Этот метод позволяет умным контрактам на исходной цепочке вызывать функции умных контрактов на целевой цепочке на основе локальных данных, обеспечивая создание сложных кросс-чейн приложений, включая обмен активами и мостовые операции.
· Программируемые мосты: это продвинутое решение взаимодействия, которое объединяет функции моста активов и передачи сообщений. При передаче активов с исходной цепи на целевую цепь, вызовы контрактов на целевой цепи могут быть немедленно запущены, что позволяет использовать различные функции межцепочечного взаимодействия, такие как стейкинг, обмен активами или хранение активов в смарт-контрактах на целевой цепи.
Давайте сравним Agglayer с текущими протоколами межцепочечного взаимодействия, на примере LayerZero, самого влиятельного протокола межцепочечного взаимодействия. LayerZero использует улучшенную версию внешней верификации, преобразуя источник доверия для верификации в два независимых элемента — оракул и релеер. Этот минималистический подход решает проблемы внешней верификации, делая его программным мостом, способным выполнять различные операции. Логически, кажется, что он элегантно разрешил так называемую трилемму. С общей точки зрения, LayerZero имеет потенциал стать межцепочечным хабом всей Web3, решая проблемы, такие как фрагментированный пользовательский опыт и разрыв ликвидности, вызванный взрывом цепей в модульную эру. Вот почему ведущие венчурные капиталы сделали большие ставки на такие протоколы.
Однако, какова реальность? Отложив в сторону недавние споры относительно операций с раздачей LayerZero, рассмотрим его проблемы развития. Достижение идеального состояния подключения всей Web3 крайне сложно, а его децентрализация под сомнением. В его ранней версии V1 оракул LayerZero представлял риски взлома и потенциально вредоносного поведения (Wormhole, который использует институты отрасли в качестве узлов-хранителей, часто сталкивается с подобными критиками). Эти опасения были смягчены только с появлением децентрализованной сети проверки (DVN) в V2, что требовало значительных ресурсов B-стороны.
Кроме того, разработка протоколов межцепочечного взаимодействия включает в себя работу с протоколами гетерогенных цепей, форматами данных, операционной логикой и вызовом различных смарт-контрактов. Истинная совместимость в Web3 требует не только индивидуальных усилий, но и сотрудничества различных проектов. Ранние пользователи LayerZero могут вспомнить, что он в основном поддерживал межцепочечное взаимодействие для блокчейнов на основе EVM, с ограниченной поддержкой других экосистем. Это также верно для Agglayer, но Agglayer обеспечивает сверхнизкую задержку и асинхронную совместимость, что делает его более подобным интернету, которым мы пользуемся ежедневно.
В целом, подход Agglayer к агрегации для использования в одной цепочке проще, эффективнее и соответствует текущим тенденциям модульного подхода. Однако абсолютного превосходства между ними в настоящее время нет. Кроссчейн-протоколы по-прежнему обладают такими преимуществами, как более широкая ликвидность, более зрелая экосистема и большая проактивность. Сила Agglayer заключается в его способности по-настоящему агрегировать конкурирующие цепочки уровней 1 и 2, нарушая игру с нулевой суммой фрагментированной ликвидности и пользователей в эпоху взрывного роста цепей. Он обеспечивает многоцепочечные взаимодействия с низкой задержкой, абстракцию собственной цепочки и общие пулы ликвидности без необходимости обернутых токенов, что представляет собой значительную возможность для цепочек с длинным хвостом и цепочек для конкретных приложений.
В общем, Agglayer в настоящее время является самым перспективным решением для межцепочечного взаимодействия, в разработке также есть аналогичные проекты, такие как «Join-Accumulate Machine» Polkadot. История Web3 перешла от монолитного к модульному, и следующим шагом будет объединение.
Хотя проект Agglayer все еще находится в начальной стадии, он уже интегрировал несколько ключевых проектов. Вот три значимых примера:
X Layer - это проект Ethereum Layer 2, построенный на Polygon CDK. Он соединяет OKX и сообщество Ethereum, позволяя любому желающему участвовать в действительно глобальной онлайн-экосистеме. Как публичная цепь ведущей биржи, интеграция с Agglayer принесет обширную ликвидность проектам в агрегационном слое. Кроме того, веб-кошелек OKX Web3, служащий доступовым уровнем для обычных пользователей, также может обеспечить лучшую поддержку для Agglayer.
Union - это слой инфраструктуры с нулевым разглашением, построенный на Cosmos и используемый для общих сообщений, передачи активов, NFT и DeFi. Он полагается на проверку согласованности без привлечения доверенных сторон, оракулов, мультиподписей или MPC. Как интегрированная цепочка, Union обеспечивает глубокую связь между экосистемами EVM и Cosmos в рамках слоя агрегации. Используя Union в качестве шлюза IBC, это позволяет подключаться к Union, а затем к IBC, тем самым объединяя две в противном случае фрагментированные модульные экосистемы.
Astar Network это сеть для предприятий, развлекательных и игровых проектов в Японии и по всему миру, посвященная продвижению «Web3». Она использует поддержку межвиртуальной машины от Polygon и Polkadot для предоставления настраиваемых решений блокчейн. Как первая полностью интегрированная цепочка Agglayer, Astar будет напрямую получать доступ к многомиллиардному общему пулу ликвидности и достигать роста реальных пользователей.