Across V4 представляет новую и улучшенную кроссчейн архитектуру. Система сочетает в себе намерения и нулевые доказательства (ZKP), чтобы быстрее расширяться на большее количество цепочек. Вот технический разбор. 🧵
Ранее Across использовал "канонические мосты" или адаптеры, специфичные для цепочки, чтобы проверять сообщения из HubPool Ethereum. Это хорошо работало для L2, таких как Arbitrum и Optimism, которые открывают финализированное состояние Ethereum. Но этот дизайн был ограничивающим…
Для не-EVM цепочек, таких как BSC, эта модель не работает. Нет канонического способа проверить состояние Ethereum. Это означало либо создание пользовательских адаптеров, либо полное отсутствие поддержки этих цепочек. Ни одно из этих решений не является оптимальным. Поэтому мы нашли лучший способ, используя ZKP.
Вот процесс: Когда релееры заполняют кроссчейн-заказы, транзакции группируются в пакеты погашения релееров, которые затем проверяются Оптимистичным Оракулом @UMAProtocol. Это всегда происходит в основной сети Ethereum.
После проверки пакета, Across HubPool инициирует процесс расчета. Затем он записывает хэши сообщений о погашении в контракт HubPoolStore в определенные слоты хранения. Это событие хранения также происходит в основной сети Ethereum.
Каждый хеш сообщения в контракте HubPoolStore соответствует намерению выплатить релейеру на целевой цепи. Обратите внимание, что сообщения L1 → L2 могут представлять собой несколько выплат (включая медленные заполнения). Это связано с тем, что они являются корневыми пакетами.
Когда контракт HubPoolStore записывает хэш сохраненного сообщения, он генерирует событие StoredCallData. Это событие содержит хэш сообщения и слот хранения. Событие + сохраненные данные формируют якорь для ZK верификации в дальнейшем.
Сервис под названием финализатор отслеживает эти события. Как только он обнаруживает новое событие, он инициирует процесс, чтобы доказать, что хэш сообщения действительно был записан в Ethereum. Каждое сообщение, для которого хэш хранится, имеет цель, которая может быть специфичной для его цепочки.
Это доказательство позволяет безопасно выполнить сообщение в целевой цепочке. Но финализация Ethereum не мгновенна. Как только финализатор отправляет данные в ZK API, API ждет в течение окна финализации Ethereum, прежде чем сгенерировать доказательство.
Чтобы сгенерировать действительное ZK-доказательство, комитет синхронизации Ethereum должен подписать конкретный финализированный блок. Если сообщение было включено в этот блок или до него, необходимые подписи становятся доступными для начала генерации ZK-доказательства.
Финализатор запрашивает ZK API для генерации доказательства того, что конкретный хэш сообщения был записан в известный слот хранения HubPoolStore в финализированном блоке Ethereum. Это позволяет бездоверительную проверку выплат релееров на любой целевой цепочке.
ZK API подготавливает входные данные для доказательства, включая (но не ограничиваясь): - Завершенные заголовки маяка - Подписи синхронизационного комитета - Меркле-доказательства хранения из слоя исполнения Ethereum Эти данные служат основой для генерации доказательства.
Across разворачивает универсальный стек на целевых цепочках: - Контракт Verifier (валидирует ZK доказательство) - SP1Helios от @Succinct (хранит финализированное состояние Ethereum) - Контракт UniversalSpokepool (проверяет подлинность сообщений во время выполнения)
После проверки ZK-доказательства и подтверждения состояния, executeMsg() может безопасно выполнить полезную нагрузку на целевой цепи. Без доверия. Безопасно. Универсально.
Это означает, что Across больше не нужны пользовательские адаптеры для каждой цепочки. Всего один конвейер, который работает везде: storeMsg() на Ethereum → ZK доказательство → executeMsg() на любой целевой цепочке, которая может проверить доказательство SP1Helios.
Без предположений о доверии. Без накладных расходов на интеграцию. Только Намерения + ZK.
Почему это так важно? Это значительно расширяет охват Across, открывая поддержку для длиннохвостых цепочек, которые не могут нативно проверять состояние Ethereum и не имеют канонических мостов. Это делает процесс подключения быстрее, безопаснее и более масштабируемым.
Across не нуждается в каноническом мосте для этих цепей. Ему просто нужна возможность проверять ZK-доказательство состояния Ethereum. Это снижает накладные расходы на интеграцию, избегает рисков централизованного моста и укрепляет роль Ethereum как корня кроссчейн-истины.
Показать оригинал
7,75 тыс.
42
Содержание этой страницы предоставляется третьими сторонами. OKX не является автором цитируемых статей и не имеет на них авторских прав, если не указано иное. Материалы предоставляются исключительно в информационных целях и не отражают мнения OKX. Материалы не являются инвестиционным советом и призывом к покупке или продаже цифровых активов. Раздел использует ИИ для создания обзоров и кратких содержаний предоставленных материалов. Обратите внимание, что информация, сгенерированная ИИ, может быть неточной и непоследовательной. Для получения полной информации изучите соответствующую оригинальную статью. OKX не несет ответственности за материалы, содержащиеся на сторонних сайтах. Цифровые активы, в том числе стейблкоины и NFT, подвержены высокому риску, а их стоимость может сильно колебаться. Перед торговлей и покупкой цифровых активов оцените ваше финансовое состояние и принимайте только взвешенные решения.