Введение

Взглянув в прошлое, rollups вышли вперед как определяющее решение масштабирования для Ethereum и децентрализованной технологии в целом. Через девять месяцев после Dencun-обновления Ethereum, направленного на масштабирование доступности данных rollup, пропускная способность транзакций превысила двести транзакций в секунду—представляющий пятикратный прирост по сравнению с началом года. Два ведущих роллапа, Arbitrum и OP Mainnet, достигли стадии 1 децентрализации—превосходя несколько известных альтернативных сетей уровня 1в метриках децентрализации, с возможным введением дополнительных роллапов для достижения второй стадии децентрализации к 2025 году. Технология нулевого доказательства продвигается вперед, что позволяетпроверка транзакций, эквивалентных Ethereum, по субцентовым расходам, устанавливая путь для эффективной верификации тысяч стандартных пользовательских транзакций на современной блокчейн-платформе Ethereum.

Однако этот прогресс ставит перед нами новые задачи. Несколько команд разрабатывают независимые блокчейны на основе Ethereum с ограниченной совместимостью между ними. Это ограничение в первую очередь связано с нечастой финализацией роллапов, что препятствует значимому межсетевому взаимодействию. Кроме того, оптимистичные роллапы, на которые в настоящее время приходится большая часть активности экосистемы и Total Value Locked (TVL), сталкиваются с неотъемлемыми техническими ограничениями, которые препятствуют прямому взаимодействию за пределами общих мостов, создавая значительный барьер для взаимодействия между крупными сетями, такими как Arbitrum и Base. Сообщество предложило различные решения, начиная от мостов на основе намерений и атомарных свопов и заканчивая комплексной абстракцией цепочки. Несмотря на различия, у этих решений есть одно фундаментальное требование: надежный источник достоверной информации — протокол, обеспечивающий быструю и экономичную безопасную проверку состояния между накопителями.

Среди ведущих решений, которые обычно полагаются на оптимистичных оракулов (Across), специализированные консенсусы операторов (Stargate через LayerZero) или централизованные доверия к последователям (Polymer Hub), Fast Finality Layer (NFFL) от Nuffle Labs представляет собой убедительный баланс между эффективностью, безопасностью и выравниванием Ethereum. В этой статье рассматривается инновационный подход NFFL к обеспечению верификации состояния междуроллап через механизм рестейкинга EigenLayer и NEAR DA, изучается ее архитектурное проектирование и дорожная карта развития, и анализируются потенциальные приложения и их последствия для экосистемы.

Ваш Ethereum Edge

Получите исследования первых рук, предоставленные нашей командой экспертов.

Ваш адрес электронной почты

Фон

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

Rollups 101

Роллап — это блокчейнкоторый использует другую независимую блокчейн-систему для упорядочения транзакций, доступности данных и достижения консенсуса, одновременно выполняя транзакции внешне таким образом, что они могут быть проверены блокчейном-родителем. Хотя многие определения называют родительскую цепь Уровнем 1 (L1), а роллап Уровнем 2 (L2), некоторые структуры не требуют, чтобы L2 использовал L1 для доступности данных. В данной статье рассматриваются именно роллапы, а не более широкая категория L2, для ясности.

Примером этого различия является то, что все rollups - это L2, но не все L2 обязательно являются rollups. Источник: blog.thirdweb.com

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

Упорядочивание транзакций

Rollups включают сущность, называемую последователем, ответственным за управление включением транзакций и упорядочиванием через сеть L1. Последователь функционирует аналогично производителю блоков в традиционных блокчейнах. Конкретно, он последовательно принимает входящие транзакции от пользователей, агрегирует их в пакеты (сравнимые с L1 блоками) и периодически публикует эти пакеты в назначенный смарт-контракт на L1.

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

В некоторой степени секвенсор является «стартовым» для rollup - он помогает rollup фактически принимать новые транзакции в сети, облегчая продвижение состояния вперед. Некоторые rollup реализуют децентрализованную последовательность - вращающийся набор специализированных сущностей, снижающих риск простоя в противном случае централизованного секвенсора, и основанную последовательность, которая не использует ни один секвенсор в качестве источника доверия перед публикацией пакета на L1. Вместо этого основанная последовательность позволяет любому быть секвенсором, но их пакеты используются только узлами при публикации на L1. Это практически не открывает риска простоя последовательности за счет более медленного включения транзакций (в лучшем случае это 12 секунд на блок в L1).

Однако секвенсоры не принимают решение о новом состоянии в роллапе, даже после выполнения своих собственных партий. Таким образом, секвенсоры «запускают», но не обязательно «запускают» роллап, поскольку их действия не могут непосредственно привести к злонамеренному переходу состояния.

Стартер двигателя. Даже если он не запускает двигатель, без него двигатель тоже не будет работать. Представьте rollup как двигатель, а последователь как стартер.

Доступность данных

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

Следовательно, последователи rollup должны публиковать полные данные о транзакциях на L1 таким образом, чтобы умный контракт rollup мог проверитьдоступность данных. После того как данные транзакции для пакета будут включены и завершены на уровне L1, их доступность гарантирована для всех участвующих узлов.

Перед обновлением Dencun Ethereum rollups публиковали данные транзакций во входных данных (calldata) последовательных вызовов на L1. Поэтому все транзакции должны были быть размещены в блокчейне L1 навсегда. Это может показаться разумным, так как мы хотим, чтобы все узлы, включая будущие, могли восстановить состояние rollup. Однако это очень неэффективно, так как Ethereum L1 не может хранить большие объемы данных в своем реестре, тогда как rollups, высокоскоростные полосы Ethereum, являются очень данныхзависимыми. Вместо этого мы можем сделать так, чтобы умный контракт rollup проверял допустимость последовательных транзакций, чтобы узлы мгновенно следовали состоянию контракта, а не восстанавливали его из всех транзакций, начиная с генезиса.

Воззван мост (консенсус)

Для простоты мы просто перевернули определение rollup вверх ногами - обычно все объяснения начинаются с двустороннего моста между rollup и его L1. Довольно распространено использование собственной валюты L1 в качестве своей собственной среди rollup, чтобы упростить оценку газовых сборов на основе расходов секвенсоров и предложителей. Более того, многие rollup хотят получить популярные токены в своей экосистеме с первого дня, для чего перенос их из их L1 является лучшим выбором.

Реализация мостового смарт-контракта с L1 на rollup довольно проста - узлы rollup уже слушают все, что происходит в его контракте, поэтому мы можем реализовать функцию депозита L1, которую все узлы будут интерпретировать как команду для выпуска соответствующего «обернутого» токена на самом rollup.

Однако для бездоверительных выводов необходимо, чтобы контракт моста проверял все транзакции роллапа и определял их законные результаты. Это позволяет мосту обрабатывать допустимые запросы на вывод, освобождая средства авторизованным инициаторам на L1. Этот механизм проверки делает мост источником канонического состояния роллапа - ноды синхронизируются с состоянием моста независимо от альтернативных разветвлений цепи. В отличие от традиционных блокчейнов, роллапы не реализуют независимые правила консенсуса для выбора цепи. Контракт моста на L1 определяет каноническую цепь.

Blobs

Обновление Dencun Ethereum в марте прошлого года представило «блобы» - временные ячейки данных, которые хранятся вне блокчейна и обрезаются (удаляются валидаторами сети) после ~18 дней. Поскольку мосты rollup позволяют восстанавливать состояние без повторного выполнения транзакций, эта функция стала очень полезной для rollups, которые перешли от calldata к blobs вскоре после обновления. Говоря о цифрах, до Dencun общая TPS rollups была около 50. Сегодня это более 200, с теоретическими ограничениями на 400-800 TPS в зависимости от роллапа.

Источник: L2BEAT

Помимо улучшений производительности, блобы устраняют необходимость оплаты затрат на хранение данных транзакции в EVM, устанавливая отдельный канал с специализированным временным хранилищем и независимой ценой на комиссию. Это архитектурное изменение существенно снизило затраты на транзакции в роллапах, снизив комиссии с 10-40 центов за транзакцию до уровня субцента в сетях, например, в Base.

Источник: growthepie.xyz

Урегулирование роллапа

В то время как последователи управляют порядком выполнения транзакций и их публикацией, они представляют лишь один компонент архитектуры rollup. Rollup-решения также включают сущности, называемые ‘предлагателями’, ответственными за убеждение моста L1 в определенных выходах состояния, возникающих из вновь упорядоченных пакетов. По сути, в то время как последователи устанавливают возникновение и порядок транзакций, предлагатели демонстрируют результаты этих транзакций в соответствии с логикой обработки rollup, такой как его виртуальная машина.

Роль заявителя значительно меняется в зависимости от подхода к проверке состояния rollup. Существуют два фундаментально различных методологии, определяющих две категории rollups: Оптимистичные и Нулевые Знания (ZK).

Оптимистичные Rollups

В оптимистичных rollup’ах предлагающие регулярно отправляют обновления состояния на мост L1, обычно вместе с или вскоре после публикации пакетов секвенсора. Эти обновления состояния включают новый корень состояния (криптографическая привязка ко всему новому состоянию rollup’а) после выполнения всех транзакций в последних пакетах.

Для предотвращения недопустимых обновлений состояния мост реализует период вызова (обычно 7 дней), в течение которого специализированные участники, называемые “вызывающими”, могут оспаривать предложение, представляя доказательство мошенничества. Это доказательство показывает, что транзакции были выполнены неправильно, путем повторного выполнения оспариваемой транзакции на L1 и сравнения результатов.

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

Нулевые доказательства роллапов

В ZK rollups предлагатели генерируют математические доказательства (называемые «доказательствами правильности» или более технически правильно - «ZK-доказательствами»), которые демонстрируют правильность каждого перехода состояния. Эти доказательства показывают, что все транзакции в пакете были выполнены в соответствии с правилами rollup, не раскрывая конкретных деталей их выполнения.

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

Расчеты, окончательность и совместимость

Время расчетов через канонические мосты существенно различается в зависимости от типов rollup — от 7 дней для оптимистичных rollup из-за их периода вызова до нескольких часов для ZK rollup из-за накладных расходов на генерацию доказательств и затрат на пакетную публикацию. Хотя эту модель хорошо работает для обеспечения безопасности транзакций высокой ценности, которые могут терпеть задержки, она создает значительное трение для более широкой экосистемы DeFi.

Подумайте, как это влияет на использование в реальном мире: пользователь, который хочет использовать свои заложенные в Arbitrum активы для получения кредита на Base, должен сначала мостить свои активы и ждать до 7 дней, прежде чем их можно будет использовать. Трейдер, заметивший возможность арбитража между пулами Uniswap на разных rollups, увидел бы, что возможность исчезает задолго до того, как он смог бы на нее реагировать. Игровое приложение, желающее позволить игрокам торговать предметами между различными развертываниями rollup, столкнулось бы с неприемлемой пользовательской средой с такими длительными задержками.

Важное понимание здесь заключается в том, что узлы Rollup могут фактически наблюдать за изменениями состояния намного быстрее - обычно в течение нескольких секунд после подтверждения блока L1. Хотя это состояние еще не прошло полной урегулировки в каноническом мосту, оно основано на данных транзакций, которые уже были упорядочены и завершены на Ethereum. Многие централизованные биржи уже используют эту функцию, начисляя пользовательские депозиты от Rollup после только нескольких подтверждений блока, запуская свои собственные узлы и проверяя окончательность транзакции на L1.

Это создает интересную дихотомию в экосистеме rollup. В то время как rollups успешно масштабируют пропускную способность транзакций Ethereum, они внесли серьезную фрагментацию состояния и ликвидности. Каждый rollup фактически работает как независимая блокчейн, который не может эффективно проверить состояние других rollups без ожидания решения моста, несмотря на то, что все они получают свою безопасность от той же основной цепи — Ethereum.

Существующие решения

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

• Безопасность - насколько надежны гарантии правильности проверки состояния
• Скорость - насколько быстро можно проверить состояние на разных цепочках
• Стоимость - насколько дорогим является поддержка и использование решения

Большинство существующих решений оптимизируют скорость и стоимость за счет безопасности - часто полагаясь на доверенных операторов, мультиподписи или оптимистичные механизмы с минимальной экономической поддержкой. Это привело к нескольким знаменитым взломам мостов, наиболее известным из которых был эксплойт моста Ronin на сумму $625 млн, подчеркивающий риски, связанные с жертвой безопасности ради удобства.

Основной вызов состоит в установлении безопасного «источника истины» о состояниях rollup, которые могут:

• Проверяйте изменения состояния за секунды или минуты, а не за часы или дни
• Обеспечить надежные криптоэкономические гарантии безопасности
• Работать экономически выгодно как для поставщиков инфраструктуры, так и для пользователей
• Интегрируйтесь без проблем с существующими архитектурами роллапов

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

В следующих разделах мы рассмотрим, как NFFL подходит к этому вызову с помощью своей новаторской комбинации restaking EigenLayer и NEAR DA, создавая быстрый слой окончательности, который находит баланс между безопасностью, скоростью и эффективностью стоимости.

Глубокий погружение NFFL

Основной тезис

Слой быстрой окончательности Nuffle (NFFL) представляет собой новый подход к обеспечению безопасных взаимодействий между блокчейнами путем обеспечения быстрой проверки состояния между роллапами. Вместо того, чтобы заставлять разработчиков выбирать между безопасностью и скоростью, NFFL использует restaked ETH EigenLayer для создания криптоэкономически защищенного слоя быстрой окончательности, который может подтверждать состояния роллапов в течение нескольких секунд.

В своей основе NFFL работает как активно подтвержденная услуга (AVS), работающая на EigenLayer. Децентрализованная сеть операторов, каждый из которых запускает полные узлы для участия в rollups, проверяет и подтверждает обновления состояния. Эти подтверждения подкрепляются заложенным операторами ETH, что создает сильные экономические стимулы к честному поведению. Комбинируя это с уровнем доступности данных NEAR для эффективного хранения блоков данных, NFFL позволяет приложениям безопасно проверять состояние межцепочечного взаимодействия за 2-3 секунды - на порядки быстрее, чем каноническая мостовая система.

Упрощенная архитектура дизайна NFFL

Особенность NFFL заключается в ее прагматичном подходе к дизайну. Вместо того чтобы пытаться заменить или конкурировать с моделью безопасности Ethereum, он предоставляет дополнительный уровень, оптимизированный для случаев использования, требующих более быстрой окончательности. Приложения могут выбирать, полагаться ли на криптэкономическую безопасность NFFL или ждать полного расчета L1 в соответствии с их конкретными потребностями. Эта гибкость позволяет NFFL улучшить пользовательский опыт во многих взаимодействиях между цепями, сохраняя при этом надежные гарантии безопасности.

Система внедряет три ключевых инновации:

1. Децентрализованная сеть операторов, достигающая консенсус по состояниям роллапа путем сравнения локально выполненных переходов состояний с данными блока, размещенными в NEAR DA
2. Система задач на основе контрольных точек, которая обеспечивает эффективное сбор и проверку заверений операторов, сохраняя ответственность через механизмы взыскания EigenLayer.
3. Механизм хранения данных, использующий NEAR DA, позволяющий легко получать данные с подтверждением от всех rollups

Этот дизайн позволяет NFFL найти баланс между безопасностью, скоростью и эффективностью затрат - тремя свойствами, которые традиционно противопоставлялись в инфраструктуре межцепочечного взаимодействия. Предоставляя быструю, но безопасную проверку состояния, NFFL открывает новые возможности для кросс-чейн приложений, начиная от протоколов кредитования и до агрегаторов ликвидности.

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

Основные компоненты

Набор операторов

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

Этот архитектурный выбор является фундаментальным для понимания модели безопасности NFFL. Те же валидаторы, которые обеспечивают безопасность консенсуса Ethereum, могут повторно разместить свои ETH через EigenLayer, чтобы стать операторами NFFL. Делая это, они подвергают свои размещенные ETH риску, чтобы поддержать свои утверждения о состояниях rollup. Это создает мощный безопасный мост между консенсусом Ethereum и быстрым финальным слоем NFFL.

Когда rollup публикует новые данные блока на L1, релеи передают их в NEAR DA. Операторы получают данные блока из обоих источников и убеждаются, что они эквивалентны. Мы дальше объясним, почему публикация данных rollup на NEAR DA необходима, чтобы сделать приложения, использующие NFFL, более удобными для пользователей и разработчиков.

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

Экономическая безопасность такой системы имеет очень интересное свойство, которое вытекает из механики снижения EigenLayer:

В EigenLayer Actively Validated Services могут реализовать механизм проверки, способный обнаруживать недействительные утверждения от операторов и сокращать (ликвидировать) их депозит. Поскольку NFFL в некотором роде «предварительно устанавливает» состояние rollup вне цепи, прежде чем оно будет установлено в мостике, можно объективно обнаружить мошенничество, дождавшись задержки установки и уведомив контракт AVS о несоответствии результатов в утверждении и мостике. Это экономически дезинцентивирует мошеннические утверждения, так как они могут быть обнаружены и сокращены любым наблюдающим за состоянием L1 и NFFL действующим лицом, даже без запуска узлов rollup. Другими словами, NFFL «страхует» утверждения сети - операторы рискуют значительным капиталом для подтверждения своих утверждений о состояниях rollup.

Особую силу этому придает то, как оно выстраивает стимулы в системе. Операторы получают комиссию за честное участие, рискуя значительными потерями за нечестность. Чем больше ETH переставляется в NFFL, тем сильнее становятся эти стимулы. И поскольку эта защита основана на Ethereum через EigenLayer, она частично получает выгоду от той же устойчивой экономической модели безопасности, которая обеспечивает безопасность сотен миллиардов ценности на самом Ethereum.

Поток сообщений

Система мессенджинга NFFL представляет собой инновационный подход к обработке верификации состояния межцепочки в масштабе. Вместо записи каждого подтверждения состояния on-chain, что было бы чрезвычайно дорогостоящим, NFFL вводит двухуровневую систему сообщений и задач, которая позволяет эффективную работу off-chain при сохранении сильных гарантий безопасности on-chain по требованию.

Сообщения - основная единица коммуникации в NFFL. Когда операторы проверяют новое состояние, они создают и подписывают сообщение, удостоверяющее это состояние. Эти сообщения в основном существуют вне цепи, циркулируя между операторами и агрегатором без дополнительных газовых издержек на цепи. В системе существуют два различных типа сообщений, которые проходят через систему:

• Сообщения об обновлении корневого состояния содержат подтверждение оператора о состоянии роллапа на определенной высоте блока. Каждое сообщение содержит не только сам корневое состояние, но и ссылку на транзакцию NEAR DA, содержащую данные блока, создавая проверяемую связь между подтвержденным состоянием и его базовыми данными.
• Обновление набора операторов Сообщения отслеживают изменения в наборе операторов NFFL. Эти Сообщения крайне важны для безопасности системы, поскольку они позволяют контрактам реестра сведений о свертке поддерживать актуальную запись о действительных операторах, обеспечивая принятие подтверждений только от авторизованных участников с определенным риском.

Хотя сообщения обеспечивают эффективную проверку состояния, они одни по себе недостаточны для обеспечения экономической безопасности системы. В этом месте вступают в игру задачи. Задачи являются блоками цепочки работ, которые контролируют состояние системы в регулярных интервалах. Вместо того, чтобы отправлять каждое сообщение в Ethereum, операторы периодически конструируют Sparse Merkle Tree, содержащее все сообщения за определенный период времени. Корень этого дерева затем отправляется в качестве ответа задачи, создавая эффективную цепочку обязательств для всех внелинейных утверждений.

Эта система контрольных точек особенно умна, потому что она позволяет селективную верификацию любого сообщения без необходимости хранения всех сообщений в блокчейне. С помощью доказательств Меркля любой может проверить, что определенное сообщение было включено в контрольную точку, обеспечивая эффективные механизмы вызова при этом сохранении низких базовых затрат. Вы можете представить это как создание «блокчейна утверждений», где контрольные точки служат заголовками блоков, которые фиксируют все сообщения в определенный период времени.

Агрегатор играет решающую роль в этой системе, собирая подписи операторов и делая их доступными через API. Когда операторы подписывают сообщения, они отправляют их агрегатору, который проверяет, что подписи достигли кворума (взвешенные по ставке ETH), прежде чем выставить их для использования приложениями. Это создает чистый интерфейс для разработчиков, сохраняя децентрализованные свойства безопасности системы. Мы подробно рассмотрим сервис агрегатора в следующем разделе.

Сервис агрегатора

Агрегатор действует как координационный уровень NFFL, эффективно управляя потоком сообщений между операторами и приложениями. Концептуально это просто, но его дизайн отражает тщательное обдумывание как практических потребностей разработчиков, так и принципов децентрализации.

В своей основе агрегатор решает проблему «трагедии общих» в агрегации подписей. Без специализированного сервиса каждому приложению, использующему NFFL, пришлось бы независимо собирать и проверять подписи от всех операторов - это неэффективный и дорогостоящий процесс. Вместо этого агрегатор обеспечивает единую точку сбора подписей операторов, проверяет кворум и предоставляет проверенные удостоверения через простой API.

Процесс агрегирования подписей работает следующим образом:

• Операторы независимо подписывают сообщения, подтверждающие обновление состояния
• Эти подписи отправляются в агрегатор для сбора
• Агрегатор проверяет действительность подписи и отслеживает кворум
• Как только достигается достаточный вес ставки, становится доступной собранная подпись
• Приложения могут получать эти удостоверения через API агрегатора

Этот дизайн значительно упрощает интеграцию NFFL для разработчиков. Вместо управления сложными криптографическими операциями или отслеживания ставок операторов, приложения могут просто запрашивать удостоверения для конкретных обновлений состояния через чистый интерфейс API. Агрегатор обрабатывает всю сложность сбора подписей, проверки и агрегации BLS за кадром.

Агрегация подписей

Давайте более подробно изучим агрегацию BLS, используемую NFFL. У подписей BLS есть мощное математическое свойство, которое позволяет объединять несколько подписей в одну подпись. Вместо проверки N отдельных подписей от операторов, что было бы вычислительно затратно и затратно на газ, приложения могут проверять одну объединенную подпись, которая доказывает коллективное согласие.

Здесь выигрыши в эффективности существенны. Когда операторы NFFL подписывают сообщение, они создают стандартные BLS-подписи с использованием своих личных ключей. Затем агрегатор может объединить эти отдельные подписи в одну компактную подпись, которая доказывает согласие кворума. Размер и стоимость проверки этой агрегированной подписи остаются постоянными независимо от того, сколько операторов участвует - это свойство, которое делает систему высокомасштабируемой.

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

Агрегатор и контрольные точки

Важно отметить, что, хотя агрегатор обеспечивает удобство, он не компрометирует модель безопасности NFFL. Собранные им подписи являются общедоступно проверяемыми, и его роль чисто организационная, а не авторитетная. Приложения всегда могут независимо подтвердить, что собранные подписи представляют собой законную квоту от заложенных операторов. Агрегатор не может подделывать подписи или скрывать действительные утверждения—он просто делает их более доступными.

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

Контракты реестра

Контракт реестра, развернутый на каждом участвующем rollup, служит критическим мостом между off-chain утверждениями NFFL и проверкой состояния on-chain. Эти контракты позволяют приложениям доверять проверке состояния других rollup, проверяя крипто-экономически обеспеченные утверждения NFFL.

Что делает Реестр особенно интересным, так это то, как он поддерживает свойства безопасности NFFL на разных цепях. Каждый контракт Реестра хранит локальную копию набора операторов NFFL, отслеживая изменения через аттестации обновления набора операторов. Это означает, что хотя набор операторов управляется через EigenLayer на Ethereum, его состояние надежно отражается на всех участвующих роллапах, что позволяет им независимо проверять аттестации.

Когда приложению требуется проверить состояние другого роллапа - например, протокол кредитования проверяет залог на Arbitrum с Optimism - оно отправляет соответствующее свидетельство в свой локальный контракт Реестра. Это свидетельство включает в себя агрегированную BLS-подпись, о которой мы уже говорили ранее, а также конкретный корневой хеш состояния, на который делается утверждение, и соответствующую ссылку на транзакцию NEAR DA.

Процесс верификации в Реестре чрезвычайно эффективен благодаря агрегации BLS-подписей. Договору достаточно выполнить одну проверку подписи по взвешенным открытым ключам текущего набора операторов. Если подпись действительна и представляет достаточный вес стейка, Реестр принимает аттестованное состояние как проверенное. Это создает доверительный мост между роллапами, который является и безопасным, и экономичным.

Реестр создает безопасный и экономичный мост с минимальным доверием между роллапами. Путем проверки объединенных подписей относительно взвешенных открытых ключей набора операторов он может подтвердить, что обновление состояния получило достаточный вес аттестации, чтобы считаться действительным. Это позволяет приложениям надежно проверять состояния между различными роллапами, наследуя экономические гарантии NFFL.

Реестр также играет решающую роль в системе вызовов NFFL. Если впоследствии удостоверение оказывается фальшивым в результате вызова, реестр может его аннулировать, защищая приложения от зависимости от неправильного состояния. Это создает несколько уровней безопасности - мгновенные криптоэкономические гарантии от заложенного ETH в сочетании с долгосрочной защитой от мошенничества через вызовы.

Классификация неисправностей и проектирование безопасности

Модель безопасности NFFL сосредоточена на обнаружении и наказании двух основных типов недобросовестного поведения оператора: сбоев безопасности и сбоев активности.

Ошибка безопасности - это нарушения, влияющие на целостность сети, порождающие неправильные состояния или результаты, несоответствующие правилам системы. Существуют два основных типа ошибок безопасности, которые могут совершать операторы:

• Эквивокация происходит, когда оператор подписывает несколько противоречивых сообщений для одного и того же события. Например, подписывание утверждений для разных корней состояния на одной и той же высоте блока или утверждение нескольких разных временных меток для одного и того же блока. Такое поведение подрывает способность сети достигать согласия относительно канонического состояния.
• Недопустимое утверждение происходит, когда оператор подписывает доказательно неверное заявление. Это может быть подтверждение обновления набора операторов, которое не соответствует дельте состояния on-chain, или подписание корневого состояния, которое не соответствует правильному выполнению транзакций блока. Эти недостатки могут быть объективно проверены через on-chain данные.

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

Процесс оспаривания может отличаться в зависимости от типа ошибки и сообщения, которое оспаривается:

Для задач контрольных точек заявители могут доказать либо ошибки включения сообщений, либо ошибки исключения. Если было пропущено сообщение с действительными удостоверениями за период времени контрольной точки, или было включено недействительное/не входящее в период сообщение, то вызов пройдет успешно. Это проверяется с использованием доказательств Меркла против дерева сообщений контрольной точки.

Отдельные сообщения можно оспаривать после истечения их контрольного периода, доказывая, что содержание сообщения было недействительным. Например:

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

Эта многоуровневая система проверки позволяет протоколу поддерживать быструю работу через внеблоковую передачу сообщений, сохраняя при этом сильные гарантии безопасности с помощью криптоэкономических механизмов. Благодаря возможности доказательства обнаружения недействительного поведения и его экономического наказания с помощью отключения EigenLayer, NFFL создает сильные стимулы для честной работы, одновременно обеспечивая эффективные вызовы при нарушениях, когда они все же происходят.

Примеры потока реального мира

Устанавливая способ быстрого и дешевого чтения состояний между rollup, NFFL открывает широкий спектр приложений, которые были недоступны с текущим технологическим стеком экосистемы. Давайте рассмотрим некоторые идеи, от теоретических и простых до более сложных и конкретных приложений, полезных в наиболее популярных областях современной экосистемы Ethereum.

Протокол приветствия

Давайте начнем с простого примера, описанного в официальной документации Nuffle Labs - протокол, который позволяет пользователям отправлять сообщения «привет» между различными rollups. Хотя это базово, это демонстрирует основные механизмы того, как приложения могут использовать NFFL для межцепочной коммуникации.

Предположим, что пользователь хочет отправить сообщение в сети №1, которое будет прочитано в сети №2. Процесс начинается, когда они отправляют транзакцию в сети №1, записывая своё сообщение “привет!” в состояние сети. На данный момент сообщение существует только в сети №1 и, как правило, требует ожидания канонического моста (возможно, несколько часов или дней), прежде чем оно может быть проверено другими роллапами.

Здесь на помощь приходит NFFL. Когда блок, содержащий это сообщение, создается, он отправляется в NEAR DA ретранслятором сети. Операторы NFFL, работающие с полными узлами для обеих сетей, проверяют, что эти данные блока совпадают с тем, что их узел сети #1 вычислил локально. После проверки они подписывают сообщения, подтверждающие новый корень состояния.

Эти удостоверения передаются через агрегаторный сервис NFFL, который собирает подписи до тех пор, пока достаточный вес доли не заверит состояние. После достижения кворума, собранная подпись становится доступной через API NFFL, обычно в течение нескольких секунд после исходного производства блока.

Теперь наступает интересная часть - потребление сообщения в сети №2. Контракт Hello Protocol на сети №2 может принять транзакцию, содержащую:

• Доказательство хранения, показывающее, что сообщение существует в состоянии сети №1
• NFFL удостоверение, подтверждающее, что это состояние действительно
• Ссылка на транзакцию NEAR DA, содержащую данные блока

Протокол направляет эти данные в контракт реестра Сети #2, который проверяет подпись удостоверения по своим записям операторов NFFL. Если данные являются действительными, это доказывает, что сообщение существует в проверенном состоянии Сети #1, что позволяет протоколу безопасно его обрабатывать.

То, что делает его мощным, - это сочетание скорости и безопасности. Весь процесс от отправки сообщения до кросс-цепной проверки может быть завершен за секунды, а не часы или дни, как с каноническими мостами. Однако безопасность обеспечивается криптоэкономическими гарантиями, поддерживаемыми переобеспеченным ETH через EigenLayer, а не доверенные операторыили оптимистические предположения.

Хотя отправка сообщений ‘привет’ может показаться тривиальной, этот же шаблон позволяет создавать гораздо более сложные приложения для взаимодействия через цепочки. Возможность быстро и надежно проверять состояние на роллапах создает строительные блоки для всего, начиная от кросс-чейн DeFi до абстрагированных от цепочек пользовательских интерфейсов.

Быстрый и дешевый мост для токенов

Основываясь на этих фундаментальных принципах, давайте рассмотрим более практическое применение - токен-мост, использующий NFFL для быстрых перекрестных трансферов между роллапами. Текущая ситуация с мостами заставляет сделать сложные компромиссы между скоростью, стоимостью и безопасностью. Давайте рассмотрим, как NFFL может изменить эти динамики.

Ведущие мосты сегодня ясно иллюстрируют эти компромиссы. Stargate, работающий на LayerZero, достигает относительно низких затрат, но занимает 10-30 минут на завершение переводов из-за того, что его операторная сеть должна достигать и передавать согласование между несколькими цепочками. Across обеспечивает почти мгновенные переводы, но по 10-100 раз дороже, в основном из-за дорогостоящих выходов оракула UMA и медленных (6-часовых) циклов перебалансировки, которые влияют на эффективность ликвидности.

NFFL представляет здесь новый парадигму. Используя AVS-фреймворк EigenLayer вместо поддержки отдельной сети операторов, NFFL может достичь консенсуса по состояниям rollup в течение нескольких секунд. Этот консенсус может быть эффективно передан через реестровые контракты по всем участвующим rollup, обеспечивая конструкции мостов, которые объединяют стоимостную эффективность Stargate с еще более быстрой окончательностью, чем Across.

Представьте себе пользователя, перемещающего ETH с Arbitrum на Base. Когда токены блокируются в мостовом контракте на Arbitrum, операторы NFFL быстро проверяют и подтверждают этот изменение состояния через свои полные узлы. Как только агрегатор соберет достаточное количество подтверждений, мостовой контракт на Base сможет немедленно проверить блокировку токенов через свой контракт реестра и освободить средства пользователю.

Эта скорость и эффективность делают многие существующие оптимизации моста менее актуальными. Например, часто предлагаются системы моста на основе намерений, чтобы обойти медленную окончательность - пользователи отправляют намерения для моста токенов, и эти намерения сопоставляются и выполняются специализированными актерами. Но с NFFL, обеспечивающим согласованность почти так же быстро, как займет сопоставление намерений, мосты могут вместо этого использовать более эффективные конструкции пулов ликвидности, похожие на Stargate, но без его ограничений скорости.

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

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

Протокол кредитования Multi-Chain

Кросс-цепной займ представляет собой, возможно, наиболее убедительное немедленное применение NFFL. Текущие протоколы займа сталкиваются с существенными ограничениями из-за фрагментации цепи. Возьмем Aave — несмотря на то, что он развернут на нескольких роллапах, каждое развертывание работает в изоляции. Пользователи, желающие использовать залог на разных цепях, должны мостить активы и ждать, что приводит к фрагментации ликвидности и снижению эффективности капитала. Более того, некоторые развертывания на более мелких роллапах даже не имеют достаточной ликвидности для какого-либо значимого займа, что подвергает сомнению маркетинговую позицию Aave о простом займе для всех людей любого размера. «Просто используйте Aave». …но только на его крупнейших развертываниях.

NFFL позволяет осуществлять фундаментально отличный подход. Рассмотрим протокол кредитования, который поддерживает пулы по нескольким rollups, но использует NFFL для передачи состояния залога между ними. Пользователь может внести USDC в качестве залога на Base, а затем немедленно занять USDT на Arbitrum против этого же залога - даже если USDT вообще не развернут на Base. Контракт Arbitrum протокола просто проверяет позицию залога Base через удостоверения NFFL, без необходимости моста.

Это создает новые возможности для эффективного использования капитала. Пользователи могут получить доступ к лучшим курсам на любом поддерживаемом Rollup, не перемещая активы. Поставщики ликвидности могут размещать капитал там, где он наиболее нужен, не поддерживая отдельные позиции на каждой цепочке. И поскольку позиции могут быть отслеживаемыми практически в режиме реального времени через NFFL-аттестации, протоколы могут предлагать лучшие курсы, сохраняя при этом безопасность.

Преимущества выходят за рамки основного кредитования. Рассмотрим протокол маржинальной торговли, позволяющий пользователям открывать позиции на нескольких DEX одновременно. Трейдер может внести залог на Arbitrum, а затем использовать его для открытия маржинальных позиций как на DEX Arbitrum, так и на DEX Base одновременно. Протокол может отслеживать все позиции через аттестации NFFL, обеспечивая быстрые ликвидации при необходимости и давая трейдерам доступ к лучшим ценам во всей экосистеме.

Эта модель значительно проще и эффективнее существующих подходов. Вместо сложных механизмов моста или централизованных источников цен, протоколы могут непосредственно проверять позиции через реестровые контракты. Быстрая окончательность от NFFL означает, что они могут работать с более низкими предельными значениями безопасности, сохраняя при этом безопасность. И пользователи могут получить безшовный опыт доступа к ликвидности по всей экосистеме.

Cross-DEX: Развернуть один раз, использовать везде

Текущий подход к масштабированию децентрализованных бирж на роллапах часто приводит к абсурдным неэффективностям. Когда протоколы, такие как Uniswap, разворачиваются на новом роллапе, пользователи изначально сталкиваются с пулами, лишенными ликвидности и отсутствием критически важных торговых пар. Рассмотрим недавнее развертывание Uniswap V3 на ZKsync — несмотря на значительный интерес и приток средств от недавнего ZK-эйрдропа, многие пулы оставались непригодными для использования днями после запуска из-за недостаточной ликвидности. Тем временем развертывания этого же протокола на Arbitrum, Base и других установленных цепях поддерживают глубокую ликвидность, низкие комиссии и эффективное ценообразование для тысяч пар.

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

Вы правильно догадались: NFFL снова предлагает принципиально иной подход. Давайте рассмотрим это с помощью двух все более мощных шаблонов:

Рассмотрим новый DEX, запускающийся исключительно на Arbitrum, выбранный из-за его устоявшейся экосистемы DeFi и выгодных газовых затрат. Вместо запуска отдельных экземпляров по всему блокчейну, он поддерживает объединенные пулы ликвидности на Arbitrum, обеспечивая торговый доступ с любого роллапа. Вот как пользователь на Base может взаимодействовать с ним:

1. Алиса хочет обменять 10 000 USDC на ETH на Base
2. Базовый интерфейс DEX запрашивает состояние пула Arbitrum через подтверждения NFFL
3. Алиса видит, что она может получить более выгодные цены, чем фрагментированные пулы Base.
4. Она одобряет сделку на Base
5. Транзакция выполняется на Арбитруме, а результат подтверждается обратно в Базу

Выгоды от этой объединенной ликвидности значительны. Поставщики ликвидности могут сконцентрировать свой капитал в одном месте, что приводит к лучшим ценам и меньшему проскальзыванию. Команде протокола нужно управлять только одним развертыванием, упрощая разработку и снижая операционные издержки. И пользователи получают постоянный доступ к глубокой ликвидности независимо от того, какой rollup они используют.

Такой протокол мог бы использовать ранее исследованный шаблон моста для бесшовного управления потоком свопов. Время ожидания всего лишь несколько секунд, и сам факт моста может быть полностью абстрагирован. Это приближает нас к захватывающему понятию «абстракции цепи», которое недавно стало довольно популярным в криптосообществе: если для dapp не имеет значения, на какой цепи вы находитесь, почему вам волноваться, на какой цепи находитесь вы и все эти приложения? Пользователь может просто перейти на веб-сайт приложения, подключить свой кошелек и выполнить желаемое действие. Готово.

Но NFFL позволяет реализовать еще более мощный шаблон - обертывание существующих протоколов DeFi для межцепочечного доступа. Вместо создания конкурирующих пулов ликвидности, разработчики могут создавать “вспомогательные” протоколы, которые позволяют получить доступ к огромным пулам Uniswap на Arbitrum с любого роллапа.

Развертывание Uniswap с наибольшим TVL. База и Arbitrum лидируют в таблице, с Optimism, у которого TVL в 6 раз меньше, чем у каждого из них, а другие rollups попадают в раздел «Другие». Источник:DefiLlama

Например, предположим, что Бобу нужно обменять долгий токен на пару на Base. В настоящее время его варианты ограничены - либо мостом перейти на другую цепочку и подождать, либо принять значительную проскальзывание из-за низкой ликвидности Base. С помощью обертки, работающей на базе Uniswap Arbitrum с использованием технологии NFFL, Боб смог бы:

1. Запросить доступную ликвидность по всем пулам Arbitrum Uniswap через аттестации NFFL
2. Найти глубокую ликвидность для желаемой пары в установленном пуле Arbitrum
3. Выполните сделку от Base через протокол оболочки
4. Получите его токены на Base, как только NFFL подтвердит завершение обмена

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

Возможности выходят далеко за рамки простых свопов. Благодаря проверке состояния в режиме реального времени от NFFL протоколы могут предлагать сложные функции, такие как кросс-чейн лимитные ордера. Пользователь может разместить лимитный ордер на базовый актив против ликвидности Arbitrum с помощью оберточного протокола, который контролирует движение цен через аттестации NFFL и выполняет операцию, когда выполняются условия.

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

• Расходы на газ для их конкретных операций
• Технологический стек - виртуальная машина, AA, тип последовательности, DA и т.д.
• Регуляторные соображения

Затем с помощью NFFL они могут все еще обслуживать пользователей во всей экосистеме роллапов, сохраняя более простую и эффективную операцию.

Импликации для MEV также интересны. С объединенной ликвидностью, доступной на всех цепочках, искателям MEV потребуется мониторить и взаимодействовать с меньшим количеством развертываний. Это может привести к более эффективному открытию цен и более качественному исполнению для пользователей всех роллапов.

Как вы, возможно, уже заметили, эта модель развертывания одной цепи с многоцепочечным доступом через NFFL может выйти далеко за пределы DEX. Любой протокол, который извлекает выгоду из глубины ликвидности или сетевых эффектов, может принять эту модель - протоколы кредитования, платформы опционов, торговые площадки NFT и многое другое. Ключевая идея заключается в том, что NFFL делает межсетевой доступ почти таким же бесшовным, как и взаимодействие в одной цепочке, позволяя протоколам оптимизировать свою стратегию развертывания без ущерба для доступности. Другими словами, NFFL снова превращает Ethereum в экосистему.

Дорожная карта и перспективы развития

В то время как NFFL уже позволяет создавать мощные новые кросс-чейн приложения, протокол продолжает развиваться. Дорожная карта развития NFFL сосредоточена на трех ключевых областях:

Безопасность протокола

• Реализация всесторонних механизмов вызова и сокращения через EigenLayer
• Активация участия операторов без разрешения с надежным управлением ставками
• Улучшение верификации состояния межцепных с помощью улучшенных криптографических примитивов (BLS→ECDSA)

Масштабируемость сети

• Оптимизация схем сигнатур и распространения состояний
• Улучшение эффективности контрольной точки и затрат на верификацию

Взаимодействие с разработчиками

• Построение SDK и инструментов для легкой интеграции
• Расширение поддержки различных типов rollup и виртуальных машин
• Создание документации и примеров для общих случаев использования

В следующих разделах мы подробно рассмотрим некоторые из самых значительных запланированных улучшений.

BLS в ECDSA

Один из наиболее значимых запланированных изменений - переход от подписей BLS к подписям ECDSA. В настоящее время NFFL использует подписи BLS для обеспечения эффективной агрегации - несколько подписей оператора могут быть объединены в одну подпись, которая доказывает согласованность кворума. Хотя это снижает затраты на проверку, это создает проблемы для управления набором операторов через цепочки.

Проблема заключается в том, как работает проверка подписи BLS. При проверке совокупной подписи BLS проверяющий должен использовать точно такой же набор открытых ключей, что и создатель. Это означает, что при изменении набора операторов на Ethereum все rollups должны обновиться до точно такого же набора операторов, прежде чем они смогут проверить новые утверждения. Даже небольшое несоответствие между наборами операторов на цепочках может препятствовать проверке подписи и требовать синхронизации всех сообщений об изменениях набора операторов.

Подписи ECDSA, хотя и требуют больше места и вычислений для проверки, предлагают больше гибкости. Отдельные операторские подписи могут быть проверены независимо, что позволяет более плавные переходы при изменении набора операторов. Rollups могут проверять утверждения, пока они распознают подписывающих операторов, даже если их вид на полный набор операторов временно отличается от Ethereum. Эта большая гибкость может стоить незначительного увеличения затрат на проверку.

Динамические наборы операторов

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

Система динамических операторов позволила бы новым операторам присоединиться к сети без разрешения, заложив через EigenLayer. Это вводит несколько технических вызовов, которые нужно внимательно рассмотреть:

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

Во-вторых, протоколу нужны механизмы для отслеживания производительности оператора и веса ставки. Поскольку операторы присоединяются и уходят, система должна поддерживать точные записи о ставке каждого оператора и их правах на участие в консенсусе. Это становится более сложным с динамическим набором по сравнению с текущим подходом с белым списком.

Наконец, протокол должен эффективно обрабатывать обновления набора операторов между цепями. Когда набор операторов меняется на Ethereum, эти обновления должны распространяться на все участвующие роллапы через их реестровые контракты. Запланированный переход на ECDSA поможет здесь, сделав эти обновления более гибкими.

Снятие поддержки

Еще одна важная область развития - активация механизмов безопасности вызова и штрафования без разрешения. Эти механизмы необходимы для обеспечения честного поведения и предоставления гарантий экономической безопасности, на которых основывается NFFL.

Система вызовов центрируется вокруг механизма задачи контрольной точки. Когда операторы представляют контрольные точки, содержащие сведения о временном периоде, каждый может вызвать эти контрольные точки, если считает, что они содержат недопустимые утверждения. Успешный вызов может быть обусловлен несколькими типами ошибок:

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

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

Для обновления корневых состояний процесс вызова особенно интересен. После того, как оператор подтверждает состояние rollup, это может быть оспорено путем доказательства того, что соответствующие данные блока не были правильно размещены в NEAR DA или что подтвержденное состояние не соответствует каноническому состоянию после расчета. Это требует от оспаривателей предоставления доказательств через Rainbow Bridge для проверки NEAR DA, что создает несколько уровней безопасности.

Механизм сокращения будет реализован через промежуточные контракты EigenLayer. Когда вызовы успешны, операторы теряют часть своих ставок в ETH. Параметры сокращения спроектированы таким образом, чтобы потенциальные потери значительно превышали любые выгоды от злонамеренного поведения. Некоторая часть этой сокращенной ставки присуждается успешным вызывателям, в то время как остаток может быть распределен среди честных операторов или использован для развития протокола.

Эти механизмы создают комплексную систему безопасности. Операторы сталкиваются с серьезными финансовыми штрафами за неправильное поведение, вызыватели получают стимулы для мониторинга сети, а приложения могут полагаться на криптоэкономические гарантии, подкрепленные перезаложенным ETH. Периоды вызова намного короче, чем доказательства мошенничества оптимистического свертывания, при этом все еще обеспечивается сильная безопасность благодаря механизмам сокращения EigenLayer.

Будущее быстрой окончательности

Хотя NFFL предоставляет немедленное решение для проверки состояния между роллапами, стоит рассмотреть, как протокол вписывается в более широкий план масштабирования Ethereum. Главный вопрос, который многие задают: «Будет ли NFFL по-прежнему актуален с развитием технологии роллапов?»

Ответ становится ясным, когда мы рассмотрим основные ограничения поселения в различных дизайнах rollup. Оптимистичные rollup, несмотря на их популярность и зрелость, не могут фундаментально решать быстрее, чем окно доказательства мошенничества - обычно 7 дней. Хотя решения типа Superchain от Optimism и Arbitrum Orbit обеспечивают более быструю связь между rollups, которые используют один и тот же мост, но они не помогают с интероперабельностью за пределами своих конкретных экосистем - например, между этими двумя.

ZK-роллапы сталкиваются с различными, но одинаково важными ограничениями. Даже при существенном улучшении технологии ZK-доказательств, существуют практические ограничения на скорость расчета. Даже если мы достигнем точки, когда доказательства могут быть сгенерированы для каждого блока L1, Ethereum должен все равно иметь возможность проверять несколько ZK-доказательств на каждый блок в разных роллапах. Когда это станет возможным, расчеты все равно будут ограничены временем блока L1 - как минимум 12 секунд при текущих параметрах.

NFFL предлагает другой подход, используя подписанные аттестации последовательности от rollups. Вместо ожидания пакетов, которые должны быть опубликованы на L1, операторы NFFL могут проверять и подтверждать изменения состояния сразу после их создания последователем. Это позволяет выполнять проверку состояния межцепочек в считанные секунды, сохраняя при этом надежность криптоэкономической безопасности через EigenLayer.

Важно, чтобы NFFL не рассматривали как конкурентную или угрожающую модель безопасности Ethereum rollup. Вместо этого она предоставляет дополнительный инструмент, который открывает новые возможности в модульной экосистеме Ethereum. Приложения могут использовать NFFL для быстрой проверки состояния, при этом все еще полагаясь на каноническое урегулирование через L1, когда это необходимо. Это создает более широкий набор инструментов для разработчиков, чтобы строить кросс-цепочные приложения с моделями безопасности, соответствующими их конкретным потребностям.

Заключение

NFFL представляет собой новый подход к решению одной из наиболее насущных проблем модульной экосистемы Ethereum - обеспечение безопасной и эффективной верификации состояния междуроллапа. Используя переставленные ETH EigenLayer для экономической безопасности и NEAR DA для эффективного хранения данных, NFFL создает слой быстрой финальности, который может проверять состояния роллапа в считанные секунды, а не часы или дни.

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

Возможно, самое важное, NFFL позволяет новому поколению кросс-чейн приложений, которые ранее были недоступны. От объединенных протоколов кредитования, которые делят залоговые средства между роллапами, до оболочек DEX, которые делают установленную ликвидность универсально доступной, быстрая проверка состояния NFFL создает строительные блоки для истинной абстракции цепочек. Это имеет глубокие последствия для капиталовложений и опыта пользователей во всей экосистеме.

Дорожная карта протокола демонстрирует приверженность непрерывному улучшению. Плановые обновления, такие как переход к подписям ECDSA и внедрение динамических наборов операторов, улучшат децентрализацию и масштабируемость. Активация комплексных механизмов челленджа и снижения повреждений укрепит гарантии безопасности. И интеграция с дополнительными решениями DA помимо NEAR сделает NFFL еще более универсальным.

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

Отказ от ответственности:

1. Эта статья взята из [[](https://research.2077.xyz/nuffle-ethereums-finality-as-a-service-layer#introduction)[2077 исследование](https://research.2077.xyz/)\]. Все права принадлежат оригинальному автору [Алекс Хук]. Если есть возражения против данной публикации, пожалуйста, свяжитесь со Gate Learnкоманда, и они быстро справятся с этим.
2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно мнениями автора и не представляют собой инвестиционных советов.
3. Переводы статей на другие языки выполняются командой gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.