*Переслати оригінальний заголовок 'Epochs and slots all the way down: ways to give Ethereum users faster transaction confirmation times'

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

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

Одноразове завершення слоту

Сьогодні, Ethereum'sGasperконсенсус використовує архітектуру слоту і епохи. Кожні 12-секундний слот підмножина перевіряючих публікує голос за голову ланцюга, і протягом 32 слотів (6,4 хв) всі перевіряючі мають можливість проголосувати один раз. Ці голоси потім переінтерпретуються як повідомлення в приблизно Схожий на PBFTалгоритм консенсусу, який після двох епох (12,8 хв) надає дуже важливе економічне забезпечення, яке називається фінальністю.

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

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

Діаграма провідної запропонованої дизайн з однослотовою завершеністю_

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

Підтвердження передварних розгортань

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

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

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

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

На основі попереднього підтвердження

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

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

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

На що ми тут фактично дивимося?

Припустимо, що ми впроваджуємо одноразову остаточність. Ми використовуємо Орбіт-подібні техніки для зменшення кількості валідаторів, які підписують кожен слот, але не занадто багато, щоб ми також могли зробити прогрес у досягненні ключової мети зменшення мінімального стейкінгу 32 ETH. В результаті, можливо, час слоту зростає до 16 сек. Потім ми використовуємо або передпідтвердження rollup, або передпідтвердження на основі, щоб надати користувачам швидші підтвердження. Що ми маємо зараз? Архітектура епохи та слоту.

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

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

Одна проста причина - це кількість вузлів. Тоді як стара лінійна @VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">децентралізація / час остаточності / недооцінка часу виконання починає ставати менш настійливою зараз через гіпероптимізовану BLS-агрегацію та в найближчому майбутньому ZK-STARKs, проте фундаментально правдиво, що:

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

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

Тому, мені здається, що (i) архітектури слоту і епохи очевидно правильні, але також (ii) не всі архітектури слоту і епохи створені рівними, і є цінність у більш повному дослідженні простору проектування. Зокрема, варто досліджувати варіанти, які не є тісно переплетеними, як Gasper, і де замість цього є більш сильна роздільність обов'язків між двома механізмами.

Що робити L2?

На мій погляд, на даний момент є три розумні стратегії для L2s.

1. Бути «заснованим», як технологічно, так і духовно. Тобто, вони оптимізуються для того, щоб бути каналами для передачі технічних властивостей базового шару Ethereum та його цінностей (висока децентралізація, стійкість до цензури і т.д.). В їх найпростішій формі, ви можете подумати про ці rollups як про «брендовані шари», але вони також можуть бути значно більш амбіційними, і експериментувати досить активно з новими дизайнами віртуальних машин та іншими технічними вдосконаленнями.
2. З гордістю бути «сервером з блокчейн-каркасом» і зробити все можливе. Якщо ви почнете з сервера, а потім додасте (i) докази коректності STARK, щоб забезпечити дотримання правил сервером, (ii) гарантовані права користувача на виход або примусові транзакції, а також (iii) свободу колективного вибору, або через координований масовий вихід, або через можливість голосувати за зміну послідовності, то ви вже отримали багато з переваг бути onchain, зберігаючи при цьому більшість ефективності сервера.
3. Компромісний підхід: швидкий ланцюжок з ста вузлами, з Ethereum, який забезпечує додаткову сумісність та безпеку. Це фактична поточна дорожня карта багатьох проектів L2.

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

1. Архітектура слоту та епохи, вбудована в Ethereum
2. Попередні підтвердження серверу
3. Комітет передпідтверджень

Ключовим питанням є, наскільки добре ми можемо зробити щось у категорії (1)? Зокрема, якщо це стає дуже добре, то здається, що категорія (3) втрачає свій сенс. Категорія (2) завжди буде існувати, принаймні тому, що будь-що, що "базується", не працює для L2-систем, які працюють з позаномірними даними, такими як плазми та валідиуми. Але якщо нативна архітектура слотів та епохи Ethereum зможе досягти часу "слоту" (тобто попереднього підтвердження) в 1 секунду, то простір для категорії (3) стає значно меншим.

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

Відмова від відповідальності:

1. Ця стаття передрукована з [віталік]. Пересилайте оригінальний заголовок «Епохи та слоти повністю: способи забезпечення користувачам Ethereum швидших часів підтвердження транзакцій». Усі права на авторські права належать оригінальному автору [ Віталік*]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з Вивчайте воротакоманда, і вони оперативно розберуться з цим.
2. Відповідальність за використання: Погляди та думки, висловлені в цій статті, є виключно тими, що належать авторові і не становлять жодних інвестиційних порад.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонені.