вчера вечером я прошёл(прошла) раздел про кроссчейн-архитектуру в whitepaper Newton, и это та часть, которая разрешает вопрос, который я носил(носила) с момента, как впервые прочитал(прочитала) обзор протокола.
если операторская сеть Newton работает в Ethereum и авторизует транзакции, что происходит, когда транзакция выполняется в Arbitrum, или Polygon, или Base? нужно ли каждой целевой сети иметь собственную инфраструктуру комплаенса?
должны ли операторы регистрироваться отдельно в каждой сети, которую они хотят обслуживать? ответ — нет на оба вопроса, и механизм, который делает это возможным, стоит внимательно понять.
Newton использует модель с исходной цепочкой и целевой цепочкой, соответствующую спецификации EigenLayer ELIP-008 Multi-Chain Verification. операторы регистрируются один раз в исходной цепочке — Ethereum mainnet или Sepolia для тестнета. эта единственная регистрация включает их BLS-публичные ключи и суммы стейка. вопрос в том, как эта регистрация.....
достигает целевых цепочек без необходимости дублировать настройку каждым оператором на каждой из них и без введения централизованного моста для передачи информации.
механика синхронизации — самая интересная часть. когда членство операторов меняется в регистрации на исходной цепочке, происходят deregistration, обновления стейка, события slashing — операторы Newton совместно формируют BLS-подписанный Merkle root текущей таблицы операторов. эта подписанная
корень доставляется в целевые цепочки с помощью permissionless relayers. ончейн-верификатор в целевой цепочке проверяет агрегированную BLS-подпись по известному
набор операторов и обновления локальной таблицы операторов. никакого централизованного моста. никакого доверенного посредника. та же экономическая безопасность, которая поддерживает аттестации задач, также поддерживает синхронизацию набора операторов.
практическое следствие в том, что приложения на любой поддерживаемой целевой цепочке получают идентичные гарантии безопасности. один и тот же набор операторов, один и тот же экономический стейк, одни и те же условия slashing — без необходимости отдельной регистрации операторов в каждой цепочке. политика, заданная один раз, применяется везде, где работает Newton.
И архитектурное свойство, которое это открывает, — кроссчейн-независимость по замыслу. приложения не выбирают между цепочками ради того, чтобы воспользоваться авторизационным уровнем Newton. они один раз задают политику, и она последовательно применяется по всей их многоцепочечной развертке. для институциональных участников
управление, позиции сразу на нескольких цепочках одновременно, и устранение фрагментации комплаенса по каждой цепочке — это не удобная функция; это обязательное условие для работы в масштабе.
я считаю, что дизайн permissionless relayer продуман особенно хорошо. ретранслятор переносит подписанный Merkle root от исходной цепочки к целевой, но не может им манипулировать. проверка подписи в целевой цепочке гарантирует, что корень отражает фактический набор операторов, подтверждённый кворумом размещённых операторов. ретранслятор — это посыльный, а не привратник... #Newt
останется ли синхронизация таблицы операторов достаточно быстрой на целевых цепочках по мере роста набора операторов и того, что изменения членства будут происходить всё чаще — это операционный вопрос, который я хочу увидеть, подвергнув стресс-тестированию в реальных условиях????
