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

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

Однак, навіть якщо його прийняти, в якийсь момент може статися розгалуження мережі, і цей блок може не потрапити в поточний ланцюжок. Тож коли ми можемо з упевненістю стверджувати, що блок вважається незмінним? Відповідь на це питання залежить від мережі, яку ми розглядаємо.

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

В Ethereum для цього існує гаджет finality. Через потенційні розгалуження мережі необхідно визначити конкретну гілку в розгалуженні. Тому після останнього блоку група атестаторів фіналізує блоки Ethereum.

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

Finality на Layer 2

У рішеннях другого рівня ситуація інша. У роллапах, як і в мережах 1-го рівня, також є блоки. Однак фіналізація працює по-різному, залежно від типу згортання. У zk-згортаннях доказ переходу стану мережі L2 надсилається до контракту батьківської мережі.

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

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

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

Докази шахрайства vs зобов'язання

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

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

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

Швидка фінальна стадія з Symbiotic

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

Давайте розглянемо це питання з точки зору мережі Ethereum. Оператори приєднуються до сховищ і мережі через контракти OptInService. У деяких випадках мережа повинна додатково реєструвати операторів у своєму проміжному програмному забезпеченні, яке також надає інформацію про поточні частки операторів.

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

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

Важливість швидкого завершення

Чому питання швидкого завершення настільки важливе? Уявіть, що ви розробляєте міст між двома мережами. Маючи зобов'язання щодо фінальності, ви могли б швидше передавати повідомлення і токени між мережами. Загалом, ви могли б оцінити розмір частки, що підтримує зобов'язання. На основі цієї оцінки ви можете виконувати перекази, швидкість яких обмежена зобов'язаннями системи, і використовувати вбудовану фіналізацію мережі для переказів, які перевищують зобов'язання системи. Загалом, швидке завершення є зручним у міжланцюговому зв'язку та подібних рішеннях. Вона є вигідною у рішеннях спільного секвенування, оскільки значно прискорює їхню роботу.

Модульність має значення

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

Висновок

Виділимо основні моменти:

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

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

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

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

Website | X | App | Documentation | GitHub