Оригінальний автор |Vitalik

Компіляція | Odaily Південний лимонний шар зіркового дня

Однією з важливих властивостей гарного користувацького досвіду в галузі блокчейн є швидкий час підтвердження угод. На сьогоднішній день Ethereum вже значно покращився порівняно з п'ятьма роками тому. Завдяки EIP-1559 і стабільному часу блоку після переходу до PoS (The Merge), угоди, відправлені користувачами на L1, зазвичай підтверджуються протягом 5-20 секунд, що приблизно відповідає досвіду оплати кредитною карткою. Однак подальше покращення користувацького досвіду є цінним, оскільки деякі додатки навіть вимагають затримки у сотих або навіть коротший час. У цій статті будуть розглянуті деякі практичні варіанти Ethereum (покращення часу підтвердження угод).

Огляд існуючих ідей та технологій

Остаточна одношарова

Наразі у Гаспері, консенсусі Ethereum, використовується архітектура з одним слотом та епохою. Кожні 12 секунд утворюється новий слот, під час якого частина валідаторів голосує за головний блок ланцюжка. Протягом 32 слотів (6.4 хвилини) кожен валідатор має можливість проголосувати один раз. Ці голоси потім перетворюються на повідомлення, схожі на ті, що використовуються в алгоритмі консенсусу PBFT. Після двох епох (12.8 хвилини) надається економічна гарантія, яка отримує назву "окончательность".

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

Single Slot Finaty (SSF) замінює цю архітектуру механізмом, подібним до Tendermint Консенсус, де блок N завершується до генерації блоку N+1. Основна відмінність від Tendermint полягає в тому, що ми зберігаємо механізм «витоку бездіяльності», який дозволяє ланцюжку продовжувати працювати і відновлюватися, коли більше 1/3 валідатори знаходяться в автономному режимі.

Основним викликом для остаточності одного слоту є те, що це означає, що кожен ставкоємець Ethereum повинен надіслати дві повідомлення кожні 12 секунд, що є значним навантаженням на ланцюг. Є кілька хитрих ідей, які можуть полегшити цю проблему, включаючи останню пропозицію Orbit SSF. Хоча це значно прискорює «остаточність» для покращення користувацького досвіду, це не змінює факту, що користувачам доведеться чекати від 5 до 20 секунд.

Попереднє підтвердження Rollup

Протягом останніх кількох років Ethereum завжди дотримувався маршрутної карти, що базується на rollup, розроблена для підтримки доступності даних та інших функцій на рівні Ethereum L1, а потім ці функції можуть використовуватися протоколами L2, такими як rollups, validiums та plasmas, для забезпечення користувачам аналогічного рівня безпеки на більшій масштабі.

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

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

Але зі збірки L2 можуть взяти участь "шахраї": вони можуть спочатку підписати блок B1, а потім підписати конфліктний блок B2 та подати його до ланцюжка перед B1. Але якщо вони це зроблять, їх виявлять та вони втратять заставні активи. Насправді, ми вже бачили практичний приклад централізованої версії, але з іншого боку, розгортання у відкритих мережах уповільнюється в розробці децентралізованих мереж упорядкування. Можна сказати, що вимагати від усіх L2 децентралізованого упорядкування - несправедливо: ми вимагаємо від rollup зробити майже те саме, що і створення нового L1. Тому Джастін Дрейк просуває метод, який дозволяє всім L2 (а також L1) використовувати механізм попередньої підтвердження на базовому рівні, який є спільним для всієї мережі Ethereum.

Підтвердження базових попередніх умов

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

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

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

Що ми насправді дивимося?

Припустимо, що ми досягли однослотової остаточності. Ми використовуємо технологію, схожу на технологію Orbit, щоб зменшити кількість валідаторів, що підписуються на кожен слот, але не занадто багато, щоб ми також могли зробити прогрес у досягненні ключової цілі - зменшенні мінімального порогу ставки 32 ETH. Тривалість слота може збільшитися до 16 секунд, після чого ми використовуємо передпідтвердження роллапу або базове підтвердження, щоб забезпечити користувачам швидше підтвердження. Нарешті, що ми отримали: архітектуру епох-слот.

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

Один простий причина - кількість вузлів. Хоча через надто оптимізоване об'єднання BLS і незабаром з'являтимуться ZK-STARKs, старі лінійні децентралізовані / час остаточності / витрати тепер виглядають пом'якшені, нижче наведені причини не можна ігнорувати:

• "Приблизна Консенсус" вимагає лише невеликої кількості вузлів, тоді як економічна остаточність вимагає більшості вузлів.
• Якщо кількість вузлів перевищує певну межу, вам знадобиться більше часу для збору підписів.

У сьогоднішньому Ethereum 12 слотів розподіляються на три підслоти: публікація та розповсюдження блоків, доказ, агрегація доказів. Якщо значно зменшити кількість доказових осіб, ми можемо скоротити до двох підслотів і використовувати 8-секундні інтервали слотів. Іншим, більш практичним фактором є «якість» вузлів. Якщо ми також можемо покладатися на підмножину спеціалізованих вузлів, щоб досягти приблизну згоду (і все ще використовувати повний набір перевіряючих), ми можемо знизити це до приблизно 2 секунд.

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

Як повинна діяти L2?

На мою думку, L2 наразі має три розумні стратегії:

• Технічно і духовно вони обидва "базуються". Це означає, що вони оптимізують технічні властивості та цінності базового рівня Ethereum (високий децентралізований, устійкий до цензури тощо). В найпростішому випадку ви можете розглядати ці rollup як "брендові шарди", але вони також можуть мати більші амбіції і проводити багато експериментів у новому дизайні віртуальних машин та інших технічних вдосконаленнях.
• Станьте «сервером з блокчейн-каркасом» та повністю використовуйте його. Якщо ви починаєте з сервера, а потім додаєте доказ дійсності STARK для забезпечення виконання правил сервером; гарантуєте право користувача на вибір виходу або примусової угоди; вільний вибір колективно, через координацію масштабного вибуття або через зміну голосів вибирачів, то ви вже отримали більшість переваг ланцюга, зберігаючи при цьому більшість ефективності сервера.
• Компромісний підхід: швидкан ланцюжок з 100 вузлами, Ethereum надає додаткову взаємодію та безпеку. Це є поточною стратегією багатьох проектів L2.

Для деяких додатків (наприклад, ENS, зберігання ключів, деякі протоколи оплати) 12-секундний час блоку вже достатньо. Для тих додатків, до яких це не застосовується, єдиним рішенням є архітектура епох-і-слот. У трьох випадках епоха є SSF Ethereum, але слоти в цих трьох випадках різні:

• Оригінальна архітектура епохи та слоту на основі Ethereum
• Попереднє підтвердження сервера
• Комітет попередньо підтверджує

Ключовим питанням є те, наскільки добре ми можемо робити це в першій категорії? Особливо, якщо воно стає дуже добре, то відчуття значення третьої категорії стає не таким великим. Оскільки всі схеми, що базуються на «based», не підходять для даних поза ланцюжком L2, таких як плазми та валідіуми, друга категорія буде існувати завжди. Якщо епоха та слот-архітектура, вбудована в Ethereum, може зменшити час слоту до 1 секунди, то простір третьої категорії стане набагато меншим.

Сьогодні ми ще далеко від остатньої відповіді на ці питання. Одне з ключових питань полягає в тому, наскільки складними стануть пропоненти блоків, це все ще досить нестабільна сфера. Новаторські рішення, такі як Orbit SSF, є дуже новаторськими, тому наприклад, використання Orbit SSF у просторі проектування епох та слотів все ще варте повного дослідження. Чим більше варіантів ми маємо, тим краще ми зможемо обслуговувати користувачів L1 та L2, спрощувати роботу розробників L2.