Вступ

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

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

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

Ваш Ethereum Edge

Отримуйте першоджерельні дослідження від нашої команди експертів.

Ваша електронна адреса

Фон

Щоб зрозуміти проблеми, які вирішує NFFL, давайте розглянемо фундаментальну архітектуру rollups, їх цілі та вбудовані обмеження.

Основи Rollups

Роллап - це блокчейнякий використовує інший незалежний блокчейн для упорядкування транзакцій, доступності даних та консенсусу, в той час як виконання транзакцій здійснюється зовнішньо таким чином, що підтверджується батьківським блокчейном. Хоча багато визначень посилаються на батьківський ланцюжок як Шар 1 (L1), а ролап як Шар 2 (L2), деякі фреймворки не потребують, щоб L2 використовували L1 для доступності даних. Для ясності, ця стаття зосереджується конкретно на ролапах, а не на ширшій категорії L2.

Приклад цього розрізнення - всі ролапи є L2, але не всі L2 обов’язково є ролапами. Джерело: blog.thirdweb.com

Звичайно, у нашому випадку батьківським L1 є блокчейн Ethereum. Він відповідає за спільний консенсус з ролапсами (ми розглянемо це пізніше). Давайте проаналізуємо, як ролапси використовують Ethereum для своїх основних функцій: впорядкування транзакцій, доступність даних та консенсус.

Порядок транзакцій

Rollups включають такий суб’єкт, як секвенсор, відповідальний за керування включенням транзакцій та їх упорядкуванням через L1 мережу. Секвенсор функціонує аналогічно продюсеру блоків у традиційних блокчейнах. Зокрема, він послідовно приймає вхідні транзакції від користувачів, агрегує їх в пакети (аналогічні L1 блокам) та періодично публікує ці пакети в призначений розумний контракт на L1.

Смарт-контракт на L1 веде авторитетний облік усіх опублікованих транзакцій та їх упорядкування. Вузли зведення повинні відстежувати цей контракт, щоб отримати нові блоки та інформацію про транзакції. Після того, як пакет включений в блок L1 і цей блок досягає остаточності завдяки консенсусу L1, включення і порядок всіх транзакцій в цьому пакеті гарантуються властивостями безпеки L1.

В певній мірі секвенатор є «стартером» роллапу - він допомагає роллапу приймати нові транзакції у мережі, сприяючи переміщенню стану вперед. Деякі роллапи реалізують децентралізовану послідовність - чергуючий набір спеціалізованих сутностей, які знижують ризик простою централізованого секвенатора, а також послідовність на основі, яка не використовує жодного секвенатора як джерело довіри до публікації пакета в L1. Замість цього, послідовність на основі дає можливість будь-кому бути секвенатором, але їх пакети використовуються тільки вузлами при публікації в L1. Це практично не призводить до ризику простою послідовності за рахунок повільного включення транзакцій (найкращий випадок - 12 секунд на блок L1).

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

Стартовий двигун. Навіть якщо він не запускає двигун, без нього двигун також не працював би. Подумайте про rollup як про двигун, а про послідовника як про стартер.

Доступність даних

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

Отже, послідовники rollup повинні публікувати комплексні дані про транзакції на L1 таким чином, щоб розумний контракт rollup міг їх перевіритидоступність даних. Як тільки дані про транзакцію для пакета включені і закінчені на L1, їх доступність гарантується для всіх учасниць вузлів.

Перед оновленням Dencun rollups Ethereum публікували дані транзакцій во вхідних даних (calldata) послідовних викликів на L1. Тому всі транзакції мусили бути опубліковані назавжди в блокчейні L1. Це може звучати розумно, оскільки ми хочемо, щоб всі вузли, включно з майбутніми, могли відновити стан rollup. Однак це дуже неефективно, оскільки Ethereum L1 не може зберігати великі обсяги даних у своєму реєстрі, тоді як rollups, високошвидкісні смуги Ethereum, є дуже даними. Замість цього ми можемо зробити розумний контракт rollup перевірити валідність послідовних транзакцій, щоб вузли миттєво слідували за станом в контракті, а не відновлювали його з усіх транзакцій, починаючи з генезису.

Закріплений міст (Консенсус)

Для спрощення, ми просто перевернули визначення rollup - зазвичай всі пояснення починаються з двостороннього мосту між rollup та його L1. Такий підхід є досить поширеним серед rollups, оскільки він спрощує оцінку комісійних витрат на основі витрат на послідовників та пропонентів L1. Крім того, багато rollups хочуть мати популярні токени у своєму екосистемі з першого дня, для чого найкращим вибором є їх містування з їх L1.

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

Однак відсутність довіри до виведення вимагає, щоб містковий контракт перевіряв всі транзакції rollup та визначав їх законні результати. Це дозволяє мосту обробляти дійсні запити на виведення, відпускаючи кошти авторизованим ініціаторам на L1. Цей механізм перевірки робить міст дефінітивним джерелом канонічного стану rollup - вузли вирівнюються з переходом стану моста незалежно від альтернативних розгалужень ланцюжка. На відміну від традиційних блокчейнів, rollups не реалізують незалежних правил консенсусу для вибору ланцюжка. Мостовий контракт на L1 визначає канонічний ланцюжок.

Blobs

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

Джерело: L2BEAT

Крім покращення місткості, блоби усунули потребу у сплаті витрат на газ EVM для зберігання даних транзакцій, встановивши окремий канал зі спеціалізованим тимчасовим сховищем і незалежним фіксуванням цін. Ця архітектурна зміна суттєво знизила вартість транзакцій у роллапах, знижуючи комісії з 10-40 центів за транзакцію до рівня підцентів у мережах, таких як Base.

Джерело: growthepie.xyz

Розрахунок Rollup

У той час як секвенсери керують упорядкуванням і публікацією транзакцій, вони представляють лише один компонент архітектури зведення. Зведення також включають сутності, які називаються «пропонентами», відповідальними за переконання моста L1 у виходах конкретних станів, отриманих у результаті нових послідовних пакетів. По суті, в той час як секвенсери встановлюють виникнення та порядок транзакцій, ініціатори демонструють результати цих транзакцій відповідно до логіки обробки зведення, наприклад, його віртуальної машини.

Роль пропонента значно змінюється в залежності від підходу до підтвердження стану rollup. Існує дві фундаментально різні методології, які визначають дві категорії rollups: Оптимістичні та Знання-нуль (ZK).

Оптимістичні Rollups

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

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

Якщо претендент успішно доводить, що ініціатор подав недійсний перехід стану, вихід стану скасовується, а претендент отримує винагороду (часто за рахунок облігації, яку ініціатори повинні розмістити). Це створює економічну гру, в якій ініціаторів стимулюють подавати лише дійсні державні переходи.

Zero-Knowledge Rollups

У ZK rollups пропозиції генерують математичні докази (звані “докази дійсності” або, технічно більш правильно, “ZK-докази”), які демонструють правильність кожного переходу стану. Ці докази показують, що всі транзакції в партії виконувалися відповідно до правил rollup, не розкриваючи конкретних деталей їх виконання.

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

Розрахунок, остаточність та взаємодія

Час розрахунків через канонічні мости значно відрізняється залежно від типу роллапа - від 7 днів для оптимістичних роллапів через їх період виклику, до кількох годин для ZK роллапів через накладні витрати на генерацію доказів та публікацію пакетів. Хоча ця модель добре працює для захисту високоцінних транзакцій, які можуть терпіти затримки, вона створює значну тертю для більш широкої екосистеми DeFi.

Подумайте, як це впливає на використання в реальному світі: користувач, який хоче використовувати своє забезпечення на основі Arbitrum для отримання кредиту на Base, спочатку повинен містити свої активи та чекати до 7 днів, перш ніж їх можна буде використовувати. Трейдер, який помітив арбітражну можливість між басейнами Uniswap на різних rollups, побачив би, що можливість зникне задовго до того, як він зможе використати її. Геймерський додаток, який хоче дозволити гравцям торгувати предметами в різних розгортаннях rollup, зіткнеться з неприйнятним UX з такими довгими затримками.

Важливим усвідомленням тут є те, що вузли rollup фактично можуть спостерігати за змінами стану набагато швидше - зазвичай протягом кількох секунд після підтвердження блоку L1. Хоча цей стан ще не пройшов повної врегулювання в канонічному місті, він ґрунтується на даних транзакцій, які вже були впорядковані та остаточно визначені на Ethereum. Багато централізованих бірж вже використовують цю властивість, кредитуючи внески користувачів з rollups після кількох підтверджень блоків шляхом запуску власних вузлів та перевірки остаточності транзакцій на L1.

Це створює цікаву дихотомію в екосистемі rollup. Незважаючи на те, що ролапи успішно масштабували пропускну здатність транзакцій Ethereum, вони запровадили серйозну фрагментацію стану та ліквідності. Кожен ролап фактично працює як незалежний блокчейн, який не може ефективно перевіряти стан інших зведень, не чекаючи розрахунку за мостом, незважаючи на те, що всі вони отримують свою безпеку від одного базового ланцюга – Ethereum.

Існуючі рішення

Екосистема розробила різні підходи для подолання цих обмежень, від централізованих мостів до спеціалізованих позаланцюжкових мереж. Ці рішення, як правило, вносять різні компроміси між трьома основними властивостями:

• Безпека - наскільки міцні гарантії того, що перевірка стану є правильною
• Швидкість - Як швидко можна перевірити стан на різних ланцюгах
• Вартість - Якою дорогою є підтримка та використання рішення

Більшість існуючих рішень оптимізують швидкість та вартість за рахунок безпеки, часто покладаючись на довірених операторів, мультіпідписи або оптимістичні механізми з мінімальною економічною підтримкою. Це призвело до кількох високопрофільних взломів містів, особливо до експлуатації міста Ронін на суму в $625 млн, що підкреслює ризики жертвування безпеці на користь зручності.

Основним викликом є створення безпечного “джерела правди” щодо станів роллапу, яке може:

• Перевіряйте зміни стану за кілька секунд або хвилин, а не годин або днів
• Забезпечити міцні гарантії криптекономічної безпеки
• Ефективно працюйте для постачальників інфраструктури та користувачів
• Безшовна інтеграція з існуючими архітектурами rollup

Ця можливість забезпечити швидку перевірку стану між роллапами спровокувала значні інновації. Різні команди підходять до проблеми з різних ракурсів, намагаючись створити інфраструктуру, яка зможе працювати наступне покоління крос-ланцюгових додатків, не жертвуючи безпекою.

У наступних розділах ми дослідимо, як NFFL підходить до цього виклику за допомогою новаторського поєднання відновлення EigenLayer та NEAR DA, створюючи швидкий шар остаточності, який забезпечує розумний баланс між безпекою, швидкістю і ефективністю витрат.

Глибока занурення NFFL

Основна теза

Швидкий шар фінальності Nuffle (NFFL) представляє новий підхід до забезпечення безпечних взаємодій між ланцюжками, забезпечуючи швидку перевірку стану між rollups. Замість того, щоб змушувати розробників вибирати між безпекою та швидкістю, NFFL використовує restaked ETH EigenLayer для створення криптографічно захищеного швидкого шару фінальності, який може підтверджувати стани rollup протягом кількох секунд.

У своєму ядрі NFFL працює як активно валідована служба (AVS), що працює на EigenLayer. Децентралізована мережа операторів, кожен з яких працює на повних вузлах для участі в ролапах, перевіряє та засвідчує оновлення стану. Ці засвідчення підтримуються відновленими ETH операторів, створюючи сильні економічні стимули до чесної поведінки. Комбінування цього з Data Availability layer NEAR для ефективного зберігання блокових даних дозволяє NFFL захищено перевіряти стан міжланцюжкової взаємодії за 2-3 секунди - в кілька разів швидше, ніж канонічне врегулювання мостом.

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

Що робить NFFL особливо привабливим, так це його прагматичний підхід до дизайну. Замість того, щоб намагатися замінити або конкурувати з моделлю безпеки Ethereum, він забезпечує додатковий рівень, оптимізований для сценаріїв використання, які вимагають швидшого завершення. Заявки можуть вибрати, чи покладатися на криптоекономічну безпеку NFFL, чи чекати повного розрахунку L1 залежно від своїх конкретних потреб. Ця гнучкість дозволяє NFFL покращувати взаємодію з користувачем для багатьох крос-чейн взаємодій, зберігаючи при цьому надійні гарантії безпеки.

Система впроваджує три ключові інновації:

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

Така конструкція дозволяє NFFL знайти ретельний баланс між безпекою, швидкістю та економічною ефективністю - трьома властивостями, які традиційно суперечать у крос-чейн інфраструктурі. Забезпечуючи швидку, але безпечну перевірку стану, NFFL відкриває нові можливості для крос-чейн додатків, починаючи від протоколів кредитування і закінчуючи агрегаторами ліквідності.

У наступних розділах ми докладно розглянемо архітектуру NFFL, вивчивши, як його різні компоненти співпрацюють між собою, щоб забезпечити цю нову примітивну для взаємодії між ланцюгами. Ми також проаналізуємо його модель безпеки, обговоримо потенційні застосування та розглянемо дорожню карту протоколу для майбутнього розвитку.

Основні компоненти

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

У центрі NFFL знаходиться його операторська мережа - децентралізована система, яка розширює безпеку Ethereum для забезпечення швидкої верифікації між різними rollup. Замість створення ще однієї ізольованої мережі, яка потребує свої припущення щодо безпеки, NFFL побудовано як Активно Валідована Служба (AVS) на EigenLayer, що дозволяє йому безпосередньо використовувати існуючу екосистему валідаторів Ethereum.

Цей архітектурний вибір є фундаментальним для розуміння моделі безпеки NFFL. Ті самі валідатори, які забезпечують консенсус Ethereum, можуть повторно перевірити свої ETH через EigenLayer, щоб стати операторами NFFL. Цим вони ризикують своїми ставками ETH, щоб підтримати свої показники щодо станів rollup. Це створює потужний міст безпеки між консенсусом Ethereum та швидким шаром остаточності NFFL.

Коли ролап публікує нові дані блоків на L1, ретранслятори пересилають їх до NEAR DA. Оператори отримують дані блоків через обидва джерела та переконуються, що вони еквівалентні. Ми пояснимо подальше, чому публікація даних ролапу на NEAR DA є необхідною для зручності використання додатків, які використовують NFFL, для користувачів та розробників.

Після отримання нових пакетів rollup оператори виконують їх у своїх вузлах rollup. Оскільки всі вони працюють з одним програмним забезпеченням вузла, вони завжди з’являються з однаковим, і правильним, результатом стану. Цей результат стану потім підписується всіма операторами. Коли більшість операторів узгоджується з певним станом, він приймається системою і може бути переданий у контракти реєстру по всіх rollup.

Економічна безпека такої системи має дуже цікаву властивість, що випливає з механіки зниження в EigenLayer:

В EigenLayer Активно Перевірені Сервіси можуть реалізувати механізм верифікації, який здатний виявляти недійсні атестації від операторів, а потім скорочувати (ліквідувати) їх депозит. Оскільки NFFL певною мірою «попередньо розраховує» стан rollup поза мережею, перш ніж він буде розрахований на мосту, можна об’єктивно виявити шахрайство, дочекавшись затримки розрахунку та повідомивши контракт AVS про невідповідність вихідних даних в атестації та мосту. Це економічно дестимулює шахрайські атестації, оскільки вони можуть бути виявлені та скорочені будь-якою організацією, яка стежить за станом L1 та NFFL, навіть без того, щоб вони запускали вузли зведення. Іншими словами, NFFL «страхує» претензії мережі — оператори піддають ризику значний капітал, щоб підтвердити свої претензії щодо станів згортання.

Особливо потужним є те, як він вирівнює стимули у системі. Оператори заробляють комісії за чесну участь, ризикуючи значними втратами за недобросовісність. Чим більше ETH перевіряється у NFFL, тим сильнішими стають ці стимули. І через те, що ця безпека походить від Ethereum через EigenLayer, вона частково користується тим самим міцним економічним забезпеченням, яке забезпечує сотні мільярдів вартості саме на Ethereum.

Повідомлення потік

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

Повідомлення - основна одиниця зв’язку в NFFL. Коли оператори підтверджують новий стан, вони створюють та підписують Повідомлення, які підтверджують цей стан. Ці Повідомлення існують переважно поза ланцюжком, циркулюючи між операторами та агрегатором без зазначених витрат на газ на ланцюжку. Є два відмінні типи Повідомлень, які протікають через систему:

• Повідомлення про оновлення кореня стану містять свідчення оператора про стан rollup на певній висоті блоку. Кожне Повідомлення містить не лише сам корінь стану, але й посилання на транзакцію NEAR DA, що містить дані блоку, створюючи перевірне зв’язок між засвідченим станом та його базовими даними.
• Оновлення набору операторів Повідомлення відстежують зміни в наборі операторів NFFL. Ці повідомлення є важливими для безпеки системи, оскільки вони дозволяють контрактам реєстру rollup підтримувати актуальний запис про дійсних операторів, забезпечуючи, що підтвердження приймаються лише від авторизованих учасників зі ставкою під загрозою.

Хоча повідомлення забезпечують ефективну перевірку стану, самі вони не є достатніми для забезпечення економічної безпеки системи. Тут на допомогу приходять Завдання. Завдання - це ланцюжкові одиниці роботи, які періодично перевіряють стан системи. Замість того, щоб надсилати кожне повідомлення в Ethereum, оператори періодично створюють Розріджене Дерево Меркла, що містить всі повідомлення з певного періоду часу. Корінь цього дерева потім надсилається як відповідь на Завдання, створюючи ефективний ланцюжковий зобов’язання до всіх позаланцюжкових підтверджень.

Ця система контрольних точок особливо розумна, оскільки вона дозволяє вибірково перевіряти будь-яке повідомлення, не вимагаючи, щоб усі повідомлення зберігалися в мережі. За допомогою доказів Меркла будь-хто може перевірити, що конкретне повідомлення було включено до контрольної точки, що забезпечує ефективні механізми виклику, зберігаючи при цьому низькі базові витрати. Ви можете думати про це як про створення «блокчейну атестацій», де контрольні точки служать заголовками блоків, які фіксуються до всіх повідомлень протягом певного періоду часу.

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

Сервіс-агрегатор

Агрегатор діє як координаційний рівень NFFL, ефективно керуючи потоком повідомлень між операторами та додатками. Хоча концептуально простий, його дизайн відображає ретельне врахування як практичних потреб розробників, так і принципів децентралізації.

В основі агрегатор вирішує проблему “трагедії загального користування” в агрегації підписів. Без спеціального сервісу кожна програма, що використовує NFFL, повинна незалежно збирати та перевіряти підписи від усіх операторів - неефективний та дорогий процес. Замість цього агрегатор забезпечує одну точку збору підписів операторів, перевірку кворуму та надання перевірених показників за допомогою простого API.

Процес агрегації підпису працює наступним чином:

• Оператори незалежно підписують повідомлення, які засвідчують оновлення стану
• Ці підписи надсилаються агрегатору для збору
• Агрегатор перевіряє валідність підпису та відстежує кворум
• Коли досягається достатній вага стейку, з’являється узагальнене підписання
• Додатки можуть отримувати ці атестації через API агрегатора

Цей дизайн значно зменшує складність для розробників, які інтегрують NFFL. Замість управління складними криптографічними операціями або відстеження ставок оператора, додатки можуть просто запитувати підтвердження для конкретних оновлень стану через чистий API-інтерфейс. Агрегатор обробляє всю складність збору підписів, перевірки та BLS-агрегації за кулісами.

Агрегація підпису

Давайте розглянемо подальшу агрегацію BLS, яку використовує NFFL. Підписи BLS мають потужну математичну властивість, яка дозволяє об’єднувати кілька підписів в один загальний підпис. Замість перевірки окремих N підписів від операторів, що було б обчислювально складним та вимагало багато газу, програми можуть перевірити один агрегований підпис, який підтверджує колективну згоду.

Ефективність тут значно збільшилася. Коли оператори NFFL підписують повідомлення, вони генерують стандартні підписи BLS за допомогою своїх приватних ключів. Агрегатор може потім об’єднати ці індивідуальні підписи в один компактний підпис, який доводить згоду кворуму. Розмір та вартість перевірки цього агрегованого підпису залишається постійним незалежно від того, скільки операторів брали участь - ця властивість робить систему високомасштабовною.

Крім того, агрегований підпис можна перевірити за допомогою комбінованих публічних ключів підписуючих операторів, зважених їхніми сумами стейку, щоб гарантувати належний облік економічної безпеки. Потім контракт реєстрації потребує тільки одну операцію перевірки підпису, щоб підтвердити, що достатня вага стейку засвідчила оновлення стану.

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

Важливо зауважити, що, хоча агрегатор забезпечує зручність, він не компромітує модель безпеки NFFL. Підписи, які він збирає, є публічно перевірними, і його роль є виключно організаційною, а не авторитетною. Додатки завжди можуть незалежно перевірити, що зібрані підписи відображають законне кворум від стейкованих операторів. Агрегатор не може підробляти підписи або приховувати дійсні свідчення - він просто робить їх більш доступними.

Агрегатор також відіграє важливу роль у системі контрольних точок. Збираючи всі повідомлення протягом часу, він може створити розріджені дерева Меркла, що використовуються в контрольних завданнях. Це створює ефективний запис всіх підтверджень, які пройшли через систему, що дозволяє пізніше перевірити їх у разі потреби для вирішення проблем безпеки чи аудиту.

Реєстраційні контракти

Контракт реєстру, розгорнутий на кожній участь у rollup, служить критичним мостом між позачерговими утвердженнями NFFL та перевіркою стану на ланцюжку. Ці контракти дозволяють додаткам безпосередньо перевіряти стан інших rollups шляхом перевірки криптоекономічно забезпечених утверджень NFFL.

Особливо цікавим робить Реєстр те, як він забезпечує безпекові властивості NFFL на різних ланцюгах. Кожний контракт Реєстру зберігає локальну копію набору операторів NFFL, відстежуючи зміни через атестації оновлення набору операторів. Це означає, що в той час як набір операторів управляється через EigenLayer на Ethereum, його стан надійно відображається на всіх участих роллапах, що дозволяє їм незалежно перевіряти атестації.

Коли додаток потребує перевірки стану іншого rollup - наприклад, протокол позики перевіряє заставу на Arbitrum з Optimism - він подає відповідну посвідчення в свій локальний договір реєстрації. Це посвідчення включає агрегований BLS-підпис, про який ми розмовляли раніше, разом з конкретним коренем стану, який підтверджується, та відповідною посиланням на транзакцію NEAR DA.

Процес верифікації в Реєстрі надзвичайно ефективний завдяки агрегації підписів BLS. Для контракту достатньо виконати одну перевірку підпису щодо зважених публічних ключів поточного набору операторів. Якщо підпис є дійсним і представляє достатню вагу стейку, Реєстр приймає затверджений стан як перевірений. Це створює надійний міст між роллапами, який є безпечним та економічним.

Реєстр створює мінімізований до довіри міст між зведеннями, який є одночасно безпечним і економічно ефективним. Перевіряючи агреговані підписи за зваженими відкритими ключами операторського набору, він може підтвердити, що оновлення стану отримало достатню вагу атестації, щоб вважатися дійсним. Це дозволяє програмам надійно перевіряти штати в різних зведеннях, успадковуючи гарантії економічної безпеки NFFL.

Реєстр також відіграє вирішальну роль у системі викликів НФФЛ. Якщо пізніше буде доведено, що атестація є фальшивою через систему оскарження, Реєстр може визнати її недійсною, захищаючи заявки від посилання на неправильний стан. Це створює кілька рівнів безпеки – негайні криптоекономічні гарантії від стейкінгу ETH у поєднанні з довгостроковим захистом від шахрайства через виклики.

Класифікація помилок та дизайн безпеки

Модель безпеки NFFL зосереджена на виявленні та покаранні двох основних типів неправомірної поведінки оператора: несправності безпеки та несправності життєдіяльності.

Помилки безпеки - це порушення, які впливають на цілісність мережі шляхом створення неправильних станів або результатів, які не узгоджуються з правилами системи. Існує два основних типи помилок безпеки, які оператори можуть допустити:

• Еквівокація виникає, коли оператор підписує кілька суперечливих повідомлень для одного й того ж події. Наприклад, підписувати підтвердження для різних коренів стану на одній і тій же висоті блоку або підтверджувати кілька різних міток часу для одного й того ж блоку. Така поведінка підриває здатність мережі до досягнення консенсусу щодо канонічного стану.
• Недійсна підтвердження виникає, коли оператор підписує очевидно неправильне заявлення. Це може бути підтвердженням оновлення набору операторів, яке не відповідає дельте стану на ланцюжку, або підписування кореня стану, який не відповідає правильному виконанню транзакцій блоку. Ці недоліки можна об’єктивно перевірити за допомогою даних на ланцюжку.

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

Процес виклику змінюється в залежності від типу несправності та повідомлення, яке було викликано:

Для завдань контрольної точки оскаржувачі можуть довести або включення, або виключення повідомлень. Якщо було пропущено повідомлення з дійсними свідченнями з періоду часу контрольної точки або було включено недійсне / поза періодом повідомлення, оскарження вважається успішним. Це підтверджується за допомогою доказів Меркла проти дерева повідомлень контрольної точки.

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

• Повідомлення про оновлення, встановлені оператором, можуть бути визнані недійсними, якщо показати, що ідентифікатор заявленого оновлення або дельта оператора не збігається зі станом у мережі
• Повідомлення про оновлення кореня стану можуть бути оскаржені шляхом демонстрації того, що заявлений корінь стану не відповідає правильному виконанню транзакцій

Ця багатошарова система верифікації дозволяє протоколу забезпечувати швидку роботу за допомогою позацепних повідомлень, зберігаючи при цьому потужні гарантії безпеки за допомогою криптоекономічних механізмів. Шляхом зроблення недійсної поведінки доведено виявною та економічно покараною за допомогою EigenLayer’s slashing, NFFL створює потужні стимули для чесної роботи, дозволяючи ефективні виклики у випадку порушень.

Приклади реального потоку

Створивши спосіб швидкого та дешевого читання стану cross-rollup, NFFL відкриває широкий спектр застосувань, які не були можливими з поточним технологічним стеком екосистеми. Давайте розглянемо деякі ідеї, від чогось теоретичного та простого до більш складних та конкретних застосувань, корисних в найпопулярніших областях сьогоднішньої екосистеми Ethereum.

Привіт Протокол

Давайте почнемо з простого прикладу, описаного в офіційній документації Nuffle Labs - протокол, що дозволяє користувачам надсилати повідомлення “привіт” між різними rollups. Хоча це базово, це демонструє основні механізми того, як додатки можуть використовувати NFFL для міжланцюжкової комунікації.

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

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

Ці атестації проходять через агрегаторний сервіс NFFL, який збирає підписи, поки достатньо ваги стейкінгу не підтвердить стан. Після досягнення кворуму агрегований підпис стає доступним через API NFFL, зазвичай протягом декількох секунд від початкового виробництва блоків.

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

• Доказ сховища, що показує, що повідомлення існує в стані мережі #1
• Свідоцтво NFFL, що підтверджує, що цей стан є дійсним
• Посилання на транзакцію NEAR DA, що містить блок даних

Протокол маршрутизує ці дані до контракту реєстрації Network #2, який перевіряє підпис атестації згідно з його записом операторів NFFL. Якщо дані є валідними, це доводить, що повідомлення існує в перевіреному стані Network #1, що дозволяє протоколу безпечно обробити його.

Що робить його потужним, так це поєднання швидкості та безпеки. Весь потік від надсилання повідомлення до кросчейн-перевірки може завершитися за лічені секунди, а не години чи дні за допомогою канонічних мостів. Проте безпека походить від криптоекономічних гарантій, підкріплених відновленими ETH через EigenLayer, а не довірені операториабо оптимістичні уявлення.

Хоча відправка повідомлень «привіт» може здаватися тривіальною, цей же шаблон дозволяє створювати набагато більш складні крос-ланцюжкові додатки. Можливість швидко та недовірчо перевіряти стан на роллапах створює будівельні блоки для всього, від крос-ланцюжкового DeFi до використання ланцюга-абстракції користувачів.

Швидке & Дешеве мостіння токенів

Ґрунтуючись на цих основах, давайте розглянемо більш практичне застосування - міст токенів, що використовує NFFL для швидких перехресних переказів. Нинішній ландшафт мостів змушує йти на складні компроміси між швидкістю, вартістю та безпекою. Давайте розглянемо, як НФФЛ може змінити цю динаміку.

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

NFFL вводить тут нову парадигму. Використовуючи фреймворк AVS EigenLayer замість підтримки окремої мережі операторів, NFFL може досягти згоди щодо станів rollup за секунди. Ця згода може бути ефективно передана через контракти реєстру по всіх участих rollups, дозволяючи створювати мостові конструкції, які поєднують вигоди вартості Stargate з ще більшою швидкістю завершення, ніж Across.

Розглянемо користувача, який переміщує ETH з Arbitrum до Base. Коли токени заблоковані в контракті мосту на Arbitrum, оператори NFFL швидко перевіряють і підтверджують цю зміну стану за допомогою своїх повних вузлів. Після того, як агрегатор збере достатню кількість атестацій, контракт мосту на базі може негайно перевірити блокування токена через свій контракт реєстру та видати кошти користувачеві.

Ця швидкість та ефективність роблять багато існуючих оптимізацій мости незначними. Наприклад, системи мостів на основі намірів часто пропонуються як спосіб обійти повільну остаточність - користувачі подають наміри для мостів токенів, і ці наміри збігаються та виконуються спеціалізованими акторами. Але з NFFL, який забезпечує згоду майже так само швидко, як збіг намірів, мости замість цього можуть використовувати більш ефективні дизайни ліквідності, схожі на Stargate, але без його обмежень швидкості.

Тут величезні вигоди вартістю. Операторам мостів не потрібно підтримувати окрему інфраструктуру згоди або платити за дорогі виходи оракулів. Користувачі отримують токени на цільовому ланцюжку за кілька секунд, платячи головним чином за базові витрати газу на верифікацію. Постачальники ліквідності можуть управляти позиціями більш ефективно зі швидшими циклами перебалансування.

Як додаткову перевагу, система забезпечує високий рівень безпеки за допомогою механізмів зниження вартості EigenLayer. Будь-які шахрайські свідчення призводять до втрати операторами їх застосованих ETH, тоді як мости все ще можуть перевіряти кінцеве узгодження через канонічні мости як додатковий захисний шар.

Протокол позики на багатьох ланцюгах

Крос-чейн кредитування представляє, мабуть, найпереконливіше негайне застосування NFFL. Поточні протоколи кредитування стикаються зі значними обмеженнями через фрагментацію ланцюга. Візьмемо Aave: незважаючи на те, що його розгортають у кількох зведеннях, кожне розгортання працює окремо. Користувачі, які хочуть використовувати заставу в різних мережах, повинні об’єднувати активи та чекати, фрагментуючи ліквідність та знижуючи ефективність капіталу. Крім того, деякі розгортання на невеликих зведеннях не мають достатньої ліквідності навіть для будь-якого значущого кредитування, що ставить під сумнів маркетингову позицію Aave щодо простого кредитування для всіх у будь-якому розмірі. “Просто використовуй Aave”. Але лише на найбільших його розгортаннях.

NFFL забезпечує принципово інший підхід. Розглянемо протокол кредитування, який підтримує пули в кількох ролапах, але використовує NFFL для розподілу стану застави між ними. Користувач може внести USDC як заставу на базу, а потім негайно позичити USDT на Arbitrum під цю ж заставу, навіть якщо USDT взагалі не розгорнутий на базі. Арбітражний контракт протоколу просто перевіряє позицію базового забезпечення за допомогою атестацій NFFL, без необхідності перекриття.

Це створює потужні нові можливості для ефективності капіталу. Користувачі можуть отримати доступ до найкращих курсів на будь-якому підтримуваному ролапі, не переміщуючи активи. Постачальники ліквідності можуть розміщувати капітал там, де це найбільше потрібно, не підтримуючи окремі позиції на кожному ланцюжку. І оскільки позиції можна контролювати практично в режимі реального часу за допомогою атестацій NFFL, протоколи можуть пропонувати кращі курси, зберігаючи при цьому безпеку.

Переваги виходять за межі базового кредитування. Подумайте про протокол з використанням кредитного левередж-торгівлі, який дозволяє користувачам відкривати позиції на кількох DEXs. Торгівець може внести заставу на Arbitrum, а потім використовувати її для відкриття левередж-позицій як на DEXs Arbitrum, так і на DEXs Base одночасно. Протокол може відстежувати всі позиції через NFFL свідчення, дозволяючи швидке ліквідації у разі потреби, надаючи торгівцям доступ до найкращих цін у всьому екосистемі.

Ця модель є драматично простішою та ефективнішою, ніж існуючі підходи. Замість складних механізмів мостів або централізованих джерел цін протоколи можуть безпосередньо перевіряти позиції через реєстраційні контракти. Швидке завершення від NFFL означає, що вони можуть працювати з меншими маржами безпеки, зберігаючи водночас безпеку. І користувачі отримують безшовний досвід доступу до ліквідності по всій екосистемі.

Крос-DEX: Розгорнути один раз, використовуйте скрізь

Поточний підхід до масштабування децентралізованих бірж на ролапах часто призводить до абсурдних неефективностей. Коли протоколи, такі як Uniswap, розгортаються на новому ролапі, користувачі спочатку стикаються з басейнами позбавленими ліквідності та відсутністю критичних торговельних пар. При цьому розгляньте недавнє розгортання Uniswap V3 на ZKsync — незважаючи на значний ажіотаж та потік коштів від недавнього ZK airdrop, багато пулів залишалися непридатними для використання протягом декількох днів після запуску через недостатню ліквідність. Тим часом розгортання того ж протоколу на Arbitrum, Base та інших встановлених ланцюгах забезпечують глибоку ліквідність, низькі комісії та ефективне ціноутворення для тисяч пар.

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

Ви відгадали правильно: NFFL знову дозволяє змінити підхід. Давайте дослідимо це через два все більш потужні шаблони:

Розгляньте новий DEX, який розгортається виключно на Arbitrum, обраному через його встановлену екосистему DeFi та вигідні витрати на газ. Замість запуску окремих екземплярів по ланцюжках, він підтримує об’єднані пули ліквідності на Arbitrum, одночасно надаючи доступ до торгівлі з будь-якого rollup. Ось як користувач на Base може спілкуватися з ним:

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

Переваги цієї об’єднаної ліквідності є значними. Постачальники ліквідності можуть сконцентрувати свій капітал на одному місці, що призводить до кращої ціноутворення та меншого зносу. Команда протоколу повинна керувати лише одним розгортанням, спрощуючи розробку та зменшуючи оперативні витрати. І користувачі мають постійний доступ до глибокої ліквідності незалежно від того, який роллап вони використовують.

Такий протокол може використовувати схему мосту, яку ми досліджували раніше, для безперешкодного управління потоком свопів. За час очікування всього в кілька секунд факт мосту може бути повністю абстрагований. Це захоплююче наближає нас до тези про «ланцюгову абстракцію», яка останнім часом стала досить популярною в криптоспільноті: якщо для децентралізованої програми не має значення, в якому ланцюжку ви знаходитесь, чому вас хвилює, в якому ланцюжку ви і всі ці додатки знаходитесь? Користувач може просто перейти на веб-сайт програми, підключити свій гаманець і виконати потрібну дію. Зроблено.

Але NFFL дозволяє ще потужніше патерни - огортання існуючих протоколів DeFi для крос-ланцюжкового доступу. Замість створення конкуруючих пулів ліквідності, розробники можуть створювати «допоміжні» протоколи, які забезпечують доступ до великих басейнів Uniswap Arbitrum з будь-якого ролапу.

Розгортання Uniswap з найбільшим обсягом заблокованих коштів. Base та Arbitrum лідирують у цьому списку, при цьому у Optimism обсяг заблокованих коштів в 6 разів менший, ніж у будь-якого з них, а інші ролапи потрапляють до категорії “Інші”. Джерело: DefiLlama

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

1. Запит доступної ліквідності по всіх пулах Arbitrum Uniswap через NFFL підтвердження
2. Знайти глибоку ліквідність для бажаної пари в усталеному пулі Arbitrum
3. Виконайте угоду з Бази через протокол обгортки
4. Отримайте його токени на Base, як тільки NFFL підтвердить завершення обміну

Ця модель трансформації є трансформаційною, оскільки вона перетворює існуючі успішні розгортання в універсальну інфраструктуру. Замість очікування місяців або років, щоб ліквідність назбиралася на нових роллапах, протоколи можуть миттєво використовувати встановлені пули. Це дуже ефективно з точки зору капіталу та створює кращий користувацький досвід.

Можливості виходять далеко за межі простих свопів. З реальним підтвердженням стану NFFL протоколи можуть надавати складні функції, такі як лімітні заявки міжланцюжкового порядку. Користувач може розмістити лімітне замовлення на Base проти ліквідності Arbitrum, протокол-обгортка відстежує рухи цін через підтвердження NFFL та виконує їх, коли умови виконані.

Ця модель може перетворити наше уявлення про розгортання протоколу по всіх роллапах. Замість автоматичного розгортання всюди або приєднання до мережевих ефектів конкретного ланцюжка, протоколи можуть стратегічно обирати свій основний ланцюжок на основі таких факторів, як:

• Вартість газу для їх конкретних операцій
• Технологічний стек — віртуальна машина, AA, тип послідовності, DA, тощо.
• Регуляторні аспекти

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

Наслідки для MEV також цікаві. З єдиною ліквідністю, доступною на всіх ланцюгах, пошукачам MEV необхідно буде відслідковувати і взаємодіяти з меншою кількістю виконань. Це може призвести до більш ефективного виявлення цін та кращого виконання для користувачів у всіх ролапах.

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

Дорожня карта та майбутні розробки

Хоча NFFL вже дозволяє потужні нові крос-ланцюжкові застосунки, протокол продовжує розвиватися. Дорожня карта розвитку NFFL акцентує увагу на трьох ключових напрямках:

Протокол безпеки

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

Масштабованість мережі

• Оптимізація схем підписів та передачі стану
• Покращення ефективності контрольних точок та витрат на перевірку

Досвід розробника

• Розробка SDK та інструментів для простої інтеграції
• Розширення підтримки різних типів ролапів та віртуальних машин
• Створення документації та прикладів для типових випадків використання

У наступних розділах ми детально розглянемо деякі з найважливіших запланованих поліпшень.

BLS до ECDSA

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

Проблема полягає в тому, як працює перевірка підпису BLS. Під час перевірки агрегованого підпису BLS перевіряючий повинен використовувати точно такий же набір відкритих ключів, які його створили. Це означає, що коли набір операторів змінюється в Ethereum, всі ролапи повинні оновитися до точно такого ж набору операторів, перш ніж вони зможуть перевірити нові свідчення. Навіть невелике неспівпадання наборів операторів між ланцюжками може запобігти перевірці підпису та потребувати синхронізації всіх повідомлень про зміни набору операторів.

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

Динамічні набори операторів

Ця зміна підпису безпосередньо пов’язана з ще одним важливим поліпшенням протоколу - впровадженням динамічних наборів операторів. Поточна система використовує статичний, дозволений набір операторів. Хоча це спростило початковий розвиток, воно обмежує децентралізацію та масштабованість протоколу.

Динамічна система операторів дозволить новим операторам без дозволу приєднатися до мережі, роблячи ставку через EigenLayer. Це ставить перед нами кілька технічних викликів, які потребують ретельного вирішення:

Спочатку протокол повинен керувати чергами входу та виходу операторів. Коли оператори хочуть приєднатися або покинути мережу, ці зміни потрібно координувати на всіх участьованих ланцюгах. Система черги забезпечує плавні переходи без порушення здатності мережі перевіряти атестації.

По-друге, протоколу потрібні механізми для відстеження продуктивності оператора та ваги стейкінгу. Коли оператори приєднуються та йдуть, система повинна вести точний облік частки кожного оператора та їхніх прав на участь у консенсусі. Це стає складнішим із динамічним набором порівняно з поточним підходом із білого списку.

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

Зняття навчальних коліс

Інша критична область розвитку - активація механізмів відкритих викликів та зниження. Ці механізми є важливими для забезпечення чесної поведінки та надання гарантій економічної безпеки, на які НФФЛ покладається.

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

• По-перше, безпечність, яка безпосередньо впливає на цілісність мережі. До них входить двозначність - коли оператор підписує кілька конфліктуючих повідомлень для одного і того ж випадку, наприклад, посвідчення різних коренів стану для одного й того ж блоку. Також до них входять недійсні посвідчення, коли оператор підписує невідомо неправильні переходи стану або оновлення набору операторів.
• Друге, проблеми живості, які впливають на доступність мережі. Якщо оператори постійно утримуються від підписування повідомлень, це впливає на здатність мережі ефективно перевіряти стани. Механізм виклику повинен збалансувати покарання такої поведінки, враховуючи законну недоступність.

Протокол впроваджуватиме систему викликів на основі застави. Претенденти повинні заблокувати заставу під час подання виклику, яку вони втрачають, якщо виклик виявиться недійсним. Однак, якщо вони успішно доведуть помилку оператора, вони отримають винагороду від урізаної ставки оператора. Це створює економічні стимули для моніторингу поведінки операторів, одночасно запобігаючи несерйозним викликам.

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

Сам механізм слешінгу буде реалізований за допомогою контрактів проміжного програмного забезпечення EigenLayer. Коли челенджі досягають успіху, оператори втрачають частину своїх стейкінгових ETH. Параметри різання розроблені таким чином, що потенційні втрати значно перевищують будь-які вигоди від зловмисної поведінки. Частина цієї урізаної частки присуджується успішним претендентам, а решта може бути розподілена між чесними операторами або використана для розробки протоколу.

Ці механізми створюють комплексну систему безпеки. Оператори стикаються зі значними фінансовими штрафами за неправомірну поведінку, викликачі надихаються на моніторинг мережі, а додатки можуть покладатися на криптекономічні гарантії, підтримувані переставленим ETH. Час виклику набагато коротший, ніж докази шахрайства оптимістичного розрахунку, проте все ж забезпечує міцну безпеку за допомогою механізмів зниження EigenLayer.

Майбутнє швидкого фіналізу

Хоча NFFL надає негайне рішення для перевірки стану міжролапних мереж, варто розглянути, як цей протокол вписується в загальну стратегію масштабування Ethereum. Головне питання, яке задають багато людей, таке: «Чи буде NFFL все ще актуальним, коли технологія ролап розвиватиметься?»

Відповідь стає зрозумілою, коли ми розглядаємо фундаментальні обмеження в різних конструкціях rollup. Оптимістичні rollups, незважаючи на їх популярність і зрілість, фундаментально не можуть розв’язувати швидше, ніж їх вікно доказу шахрайства — зазвичай 7 днів. Хоча рішення, такі як Superchain від Optimism та Arbitrum Orbit, дозволяють швидшу комунікацію між rollups, які ділять міст, вони не допомагають з взаємодією поза своїми конкретними екосистемами, наприклад, між цими двома.

ZK rollups стикаються з різними, але однаково важливими обмеженнями. Навіть якщо технологія ZK proof значно покращиться, є практичні обмеження щодо швидкості розрахунків. Навіть якщо ми досягнемо такої точки, де пруфи можуть бути згенеровані для кожного L1 блоку, Ethereum все ж повинен мати можливість перевіряти кілька ZK пруфів на кожен блок у різних rollups. Коли це стане можливим, розрахунок все ще буде обмежений часом блоку L1 - принаймні 12 секунд за поточних параметрів.

NFFL пропонує інший підхід, використовуючи підписані свідчення послідовника з rollups. Замість очікування публікації пакетів на L1, оператори NFFL можуть перевіряти та свідчити про зміни стану, як тільки вони виробляються послідовником. Це дає змогу перевіряти стан міжланцюгової взаємодії за кілька секунд, забезпечуючи при цьому міцну криптоекономічну безпеку через EigenLayer.

Важливо, що NFFL не слід розглядати як конкурента або загрозу моделі безпеки rollup Ethereum. Натомість він надає додатковий інструмент, який дозволяє нові можливості всередині модульної екосистеми 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/)\]. Усі авторські права належать оригінальному автору [Алекс Гук]. Якщо є зауваження до цього перепринту, будь ласка, зв’яжіться з Ворота Навчитисякоманда, і вони швидко займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, що належать автору, і не становлять жодних інвестиційних порад.
3. Переклади статті на інші мови виконуються командою gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.