Перенесіть оригінальний заголовок «Епохи та слоти всюди: способи забезпечити користувачам Ethereum швидше підтвердження транзакційних часів»

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

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

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

Сьогодні, Ethereum’sГасперконсенсус використовує слот та архітектуру епохи. Кожним слотом тривалістю 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 може фокусуватися на більш прямому звертанні до користувачів - як через різнікультурнийі технічні компроміси. Але якщо ви йдете цим шляхом, виникає невідворотна проблема: L2s хочуть обслуговувати користувачів, які хочуть отримувати підтвердження набагато швидше, ніж за 5-20 секунд.

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

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

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

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

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

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

На що ми насправді дивимося тут?

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

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

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

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

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

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

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

Що повинні робити L2s?

На мою думку, наразі існують три розумні стратегії для L2s.

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

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

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

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

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

Disclaimer：

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