Межсетевые (cross-chain) приложения становятся основой современного Web3, позволяя активам, пользователям и протоколам взаимодействовать через несколько сетей блокчейна. Однако интероперабельность также добавляет новые риски безопасности. Разные цепочки поддерживают отдельные наборы валидаторов, механизмы консенсуса и предположения о доверии, из-за чего сложно проверить, что межсетевое действие действительно авторизовано.
Протокол Newton решает эту задачу с помощью децентрализованной межсетевой (cross-chain) модели авторизации, которая сохраняет безопасность и при этом обеспечивает бесшовную совместимость. Вместо того чтобы полагаться на централизованные мосты или доверенных реляторов, Newton использует криптографически проверяемую модель, построенную вокруг операторов EigenLayer, BLS-подписей и синхронизированных таблиц операторов.
В основе архитектуры Newton лежит модель Source Chain и Destination Chain. Исходная цепочка — например, Ethereum Mainnet или Sepolia — служит «домом» для сети операторов. Здесь операторы регистрируются, вносят залоговые активы, публикуют свои BLS-публичные ключи и остаются подотчетными благодаря механизму слэшинга EigenLayer. Целевые цепочки, включая сети вроде Base, Arbitrum, Optimism и Polygon, — это где приложения фактически выполняют транзакции и применяют решения по политике.
Вместо того чтобы требовать, чтобы каждая целевая цепочка постоянно связывалась с Ethereum, Newton синхронизирует информацию об операторах через децентрализованный протокол синхронизации таблиц операторов (Operator Table Synchronization).
Когда набор операторов меняется из-за новых регистраций, обновлений ставок, снятий с регистрации или событий слэшинга, операторы Newton коллективно формируют BLS-подписанный корень Меркле, представляющий актуальную таблицу операторов. Это криптографический снимок включает идентичности операторов, публичные ключи и веса ставок на определенной высоте блока.
Любой может без разрешений ретранслировать этот подписанный снимок на целевые цепочки. Поскольку каждое обновление несет действительную агрегированную BLS-подпись, целевые цепочки могут независимо проверять подлинность таблицы операторов, не доверяя мессенджеру. Это создает высокодецентрализованный механизм синхронизации, избегая при этом постоянной связи с исходной цепочкой.
Newton также разделяет синхронизацию на два независимых рабочих процесса.
Путь медленных обновлений изменяет таблицу операторов только тогда, когда меняется состав операторов. Поскольку такие события происходят относительно редко, синхронизация остается эффективной.
Быстрый путь сосредоточен на проверке транзакционных сертификатов. Как только последняя таблица операторов становится доступной локально, целевые цепочки должны выполнять легковесную проверку BLS только тогда, когда завершается оценка политики. Это существенно снижает стоимость верификации при сохранении сильных гарантий безопасности.
Чтобы сделать проверку еще более эффективной, каждая целевая цепочка поддерживает калькулятор таблицы операторов (Operator Table Calculator). Вместо того чтобы искать каждого оператора по отдельности, калькулятор непрерывно вычисляет агрегированные публичные ключи для каждого кворума. Когда приходит новая таблица операторов, обрабатываются только изменения, поэтому проверка остается быстрой даже по мере роста сети.
Само межцепочечное подтверждение следует согласованной модели безопасности.
В Ethereum Newton может напрямую ссылаться на BLS-регистр EigenLayer. На целевых цепочках Newton вместо этого проверяет BN254-сертификат, который упаковывает агрегированную BLS-подпись вместе со снимком операторов, использованным при оценке. Поскольку сертификат привязан к конкретной цепочке, номеру блока и снимку таблицы операторов с использованием EIP-712 с типизированными данными, повторные атаки между цепочками фактически предотвращаются.
Безопасность по-прежнему опирается на экономические гарантии EigenLayer.
Операторы, которые одобряют мошеннические таблицы операторов, сталкиваются с теми же штрафами за слэшинг, что и операторы, которые отправляют неверные оценки политики. Чтобы успешно скомпрометировать процесс синхронизации, необходимо нарушить работу кворума поставленных в залог операторов, что делает атаки экономически дорогими и крайне непрактичными.
Архитектура также уделяет приоритет живучести (liveness). Если временные сетевые условия препятствуют достаточному числу операторов подписать новую таблицу операторов, целевые цепочки продолжают работу, используя последний проверенный снимок. Лишь после истечения настраиваемого порога устаревания новые сертификаты будут отклоняться, пока не будет синхронизирована обновленная таблица операторов. Такой баланс позволяет приложениям оставаться работоспособными, предотвращая долгосрочную опору на устаревшую информацию валидаторов.
Заглядывая дальше, архитектура Newton спроектирована так, чтобы поддерживать проверку обновлений таблицы операторов с помощью Знания с нулевым разглашением (ZK). Вместо того чтобы требовать кворума подписей, в будущих реализациях можно будет генерировать краткие криптографические доказательства того, что реестр операторов корректно перешел из одного состояния в другое. Это еще больше снизит предположения о доверии и улучшит масштабируемость в растущей многосетевой экосистеме.
В конечном счете, протокол Newton превращает межцепочечную совместимость из процесса, основанного на доверии, в процесс, который можно криптографически проверять. Объединяя децентрализованную синхронизацию операторов, агрегированные BLS-подписи, эффективную проверку сертификатов и ориентированную на будущее технологию ZK, Newton создает инфраструктуру, где приложения могут уверенно авторизовывать транзакции между несколькими блокчейнами, не жертвуя децентрализацией или безопасностью.