Обговорення практичних рішень для покращення часу підтвердження транзакцій Ethereum
У останні роки Ethereum досяг значного прогресу в швидкості підтвердження транзакцій. Завдяки EIP-1559 та стабільному часу блокування після переходу на механізм PoS, транзакції, надіслані користувачами на L1, зазвичай можуть бути підтверджені протягом 5-20 секунд, що в основному еквівалентно досвіду оплати кредитною карткою. Однак подальше покращення користувацького досвіду все ще має значення, деякі додатки навіть вимагають підсумковий час відгуку на рівні часток секунди. У цій статті будуть розглянуті кілька можливих рішень для покращення швидкості підтвердження транзакцій в Ethereum.
Огляд існуючих технологій
Односекундна остаточність
Наразі консенсус Gasper в Ethereum використовує архітектуру слотів і циклів. Кожні 12 секунд відбувається слот, де частина валідаторів голосує за голову ланцюга, а всі валідатори мають можливість проголосувати один раз протягом 32 слотів (6,4 хвилини). Ці голоси інтерпретуються як повідомлення в алгоритмі консенсусу типу PBFT, а через два цикли (12,8 хвилини) забезпечується фінальність з сильними економічними гарантіями.
Цей метод має дві основні проблеми: по-перше, висока складність, існує багато проблем взаємодії між механізмом голосування від слота до слота та механізмом остаточності від циклу до циклу; по-друге, час остаточного підтвердження у 12,8 хвилини занадто довгий і не відповідає очікуванням користувачів.
Однослотова фінальність (SSF) замінила цю архітектуру механізмом, подібним до Tendermint, що дозволяє досягти остаточного підтвердження блоку N до того, як буде згенеровано блок N+1. SSF зберігає механізм "неактивного витоку", що дозволяє ланцюгу продовжувати працювати і відновлюватися, навіть якщо більше 1/3 валідаторів офлайн.
Основні виклики SSF полягають у тому, що кожному стейкеру необхідно кожні 12 секунд публікувати два повідомлення, що є величезним навантаженням для ланцюга. Хоча існують деякі рішення, такі як нещодавня пропозиція Orbit SSF, користувачам все ж доводиться чекати 5-20 секунд для підтвердження транзакції.
Попереднє підтвердження Rollup
Ethereum в останні роки дотримується дорожньої карти, зосередженої на rollup, проектуючи L1 як базовий рівень для підтримки доступності даних та інших функцій, які використовуються протоколами L2 ( такими як rollups, validiums та plasmas) для надання користувачам послуг з рівнем безпеки, подібним до Ethereum, на більшому масштабі.
Це призвело до розділення акцентів у екосистемі Ethereum: L1 зосереджений на антицензурі, надійності та стабільності, а також на підтримці та вдосконаленні основних функцій; L2 ж більш безпосередньо обслуговує користувачів через різні культури та технології. Проте L2 прагне забезпечити користувачам час підтвердження швидше, ніж 5-20 секунд.
Теоретично, створення децентралізованої мережі сортувальників є відповідальністю L2. Невелика група валідаторів може підписувати блоки кожні кілька сотень мілісекунд і ставити активи як гарантію. Ці заголовки L2 блоків врешті-решт буде опубліковано на L1.
Однак вимога, щоб усі L2 реалізували децентралізоване сортування, здається, не зовсім справедливою, адже це еквівалентно вимозі, щоб rollup виконав практично таку ж роботу, як і створення нової L1. Тому було запропоновано, щоб усі L2 (та L1) спільно використовували механізм попереднього підтвердження в межах Ethereum: базове попереднє підтвердження.
базове попереднє підтвердження
Базовий метод попереднього підтвердження припускає, що пропоненти Ethereum є складними учасниками, пов'язаними з MEV. Він використовує цю складність, заохочуючи цих пропонентів приймати відповідальність за надання послуг попереднього підтвердження.
Цей метод створює стандартизований протокол, за яким користувачі можуть сплачувати додаткову плату для отримання миттєвих гарантій того, що транзакція буде включена в наступний блок, а також зобов'язання щодо виконання результатів цієї транзакції. Якщо пропонент порушить зобов'язання, він буде підданий покаранню.
Цей механізм підходить не лише для L1-транзакцій, для "базованих" на Ethereum rollups всі L2 блоки фактично є L1 транзакціями, тому той самий механізм може надати попереднє підтвердження для будь-якого L2.
Майбутня можлива архітектура
Припустимо, ми реалізували однослотову остаточність, і використовуємо технології, подібні до Orbit, для зменшення кількості валідаторів, які підписують кожен слот, зберігаючи при цьому достатню децентралізацію для зниження бар'єру для стейкінгу. Тривалість слоту може збільшитися до 16 секунд, після чого ми використовуємо попереднє підтвердження rollup або базове попереднє підтвердження, щоб надати користувачам швидше підтвердження. В результаті ми отримуємо архітектуру циклу-слоту.
Ця архітектура важко уникнути, оскільки час, необхідний для досягнення загального консенсусу з певного питання, значно менший, ніж час, необхідний для досягнення максимальної "економічної остаточності". Причини включають:
"Приблизна згода" вимагає лише невелику кількість вузлів, тоді як економічна остаточність потребує участі більшості вузлів.
Коли кількість вузлів перевищує певний масштаб, час, необхідний для збору підписів, значно збільшується.
У поточному Ethereum 12-секундний слот поділяється на три підслоти: публікація та розподіл блоків, доказ, агрегація доказів. Якщо значно зменшити кількість доказувачів, ми можемо зменшити до двох підслотів, реалізуючи 8-секундний слот. Якщо ми зможемо покладатися на спеціалізовану підмножину вузлів для досягнення наближеного консенсусу (при цьому все ще використовуючи повний набір валідаторів для визначення остаточності), ми навіть можемо скоротити час до приблизно 2 секунд.
Отже, архітектура циклів-слотів здається неминучою, але між різними реалізаціями існують відмінності. Варто дослідити напрямок встановлення більшої роздільності уваги між двома механізмами, а не тісно пов'язувати їх, як у Gasper.
Вибір стратегії L2
L2 наразі має три обґрунтовані стратегії:
В технічному та ідеологічному плані "базується" на Ethereum. Ці rollup можна розглядати як "брендовані шардінги", а також вони можуть проводити численні експерименти з новим дизайном віртуальної машини та іншими технологічними вдосконаленнями.
Стати "сервером з каркасом блокчейну". Отримати більшість переваг від блокчейну, додаючи STARK доказ ефективності, забезпечуючи права виходу користувачів, підтримуючи колективний вибір тощо, при цьому зберігаючи ефективні переваги сервера.
Компромісний метод: створити швидкий ланцюг з сотнею вузлів, одночасно використовуючи Ethereum для надання додаткової взаємодії та безпеки. Це фактична дорожня карта багатьох L2 проектів на сьогодні.
Для деяких застосувань (таких як ENS, зберігання ключів, часткові платіжні протоколи) 12 секунд часу блоку вже достатньо. Для інших застосувань єдиним рішенням є архітектура циклів-слотів. У цій архітектурі "цикл" є SSF Ethereum, а "слот" у різних випадках різний:
Циклічна-слотова архітектура, притаманна Ethereum
Попереднє підтвердження сервера
Попереднє підтвердження комітету
Ключове питання в тому, наскільки добре може працювати перший варіант. Якщо він покаже відмінні результати, значення третього варіанту зменшиться. Другий варіант завжди існуватиме, оскільки всі "базовані" на Ethereum рішення не підходять для таких L2, як plasmas та validiums, що використовують позасистемні дані. Якщо рідна архітектура Ethereum зі схемою циклів-слотів зможе зменшити час слоту до 1 секунди, простір третього варіанту значно звузиться.
На даний момент ми ще далеко від остаточних відповідей на ці питання. Однією з ключових невизначеностей є те, наскільки складними стануть блок-пропоненти. Нові дизайнерські рішення, такі як Orbit SSF, надають нам більше простору для досліджень, наприклад, використання Orbit SSF як періоду в архітектурі період-слот. Чим більше у нас є варіантів, тим краще ми можемо обслуговувати користувачів L1 і L2, одночасно спрощуючи роботу розробників L2.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
16 лайків
Нагородити
16
5
Поділіться
Прокоментувати
0/400
¯\_(ツ)_/¯
· 8год тому
Ця швидкість навіть гірша за pow?
Переглянути оригіналвідповісти на0
LightningAllInHero
· 08-02 19:40
Знову граються зі швидкістю підтвердження… Нічого не дає.
Переглянути оригіналвідповісти на0
rekt_but_resilient
· 08-02 19:33
L2 це для того, щоб бути швидшим.
Переглянути оригіналвідповісти на0
ValidatorViking
· 08-02 19:30
ці кінцеві терміни все ще роблять раґнарьок швидким... інфраструктура вузлів потребує серйозного тестування в бою перед будь-якими розумними змінами консенсусу, чесно кажучи
Переглянути оригіналвідповісти на0
RugPullSurvivor
· 08-02 19:17
Хто подивиться на стільки написаного на білому аркуші?
План прискорення підтвердження транзакцій Ethereum: всебічне обговорення від SSF до попереднього підтвердження L2
Обговорення практичних рішень для покращення часу підтвердження транзакцій Ethereum
У останні роки Ethereum досяг значного прогресу в швидкості підтвердження транзакцій. Завдяки EIP-1559 та стабільному часу блокування після переходу на механізм PoS, транзакції, надіслані користувачами на L1, зазвичай можуть бути підтверджені протягом 5-20 секунд, що в основному еквівалентно досвіду оплати кредитною карткою. Однак подальше покращення користувацького досвіду все ще має значення, деякі додатки навіть вимагають підсумковий час відгуку на рівні часток секунди. У цій статті будуть розглянуті кілька можливих рішень для покращення швидкості підтвердження транзакцій в Ethereum.
Огляд існуючих технологій
Односекундна остаточність
Наразі консенсус Gasper в Ethereum використовує архітектуру слотів і циклів. Кожні 12 секунд відбувається слот, де частина валідаторів голосує за голову ланцюга, а всі валідатори мають можливість проголосувати один раз протягом 32 слотів (6,4 хвилини). Ці голоси інтерпретуються як повідомлення в алгоритмі консенсусу типу PBFT, а через два цикли (12,8 хвилини) забезпечується фінальність з сильними економічними гарантіями.
Цей метод має дві основні проблеми: по-перше, висока складність, існує багато проблем взаємодії між механізмом голосування від слота до слота та механізмом остаточності від циклу до циклу; по-друге, час остаточного підтвердження у 12,8 хвилини занадто довгий і не відповідає очікуванням користувачів.
Однослотова фінальність (SSF) замінила цю архітектуру механізмом, подібним до Tendermint, що дозволяє досягти остаточного підтвердження блоку N до того, як буде згенеровано блок N+1. SSF зберігає механізм "неактивного витоку", що дозволяє ланцюгу продовжувати працювати і відновлюватися, навіть якщо більше 1/3 валідаторів офлайн.
Основні виклики SSF полягають у тому, що кожному стейкеру необхідно кожні 12 секунд публікувати два повідомлення, що є величезним навантаженням для ланцюга. Хоча існують деякі рішення, такі як нещодавня пропозиція Orbit SSF, користувачам все ж доводиться чекати 5-20 секунд для підтвердження транзакції.
Попереднє підтвердження Rollup
Ethereum в останні роки дотримується дорожньої карти, зосередженої на rollup, проектуючи L1 як базовий рівень для підтримки доступності даних та інших функцій, які використовуються протоколами L2 ( такими як rollups, validiums та plasmas) для надання користувачам послуг з рівнем безпеки, подібним до Ethereum, на більшому масштабі.
Це призвело до розділення акцентів у екосистемі Ethereum: L1 зосереджений на антицензурі, надійності та стабільності, а також на підтримці та вдосконаленні основних функцій; L2 ж більш безпосередньо обслуговує користувачів через різні культури та технології. Проте L2 прагне забезпечити користувачам час підтвердження швидше, ніж 5-20 секунд.
Теоретично, створення децентралізованої мережі сортувальників є відповідальністю L2. Невелика група валідаторів може підписувати блоки кожні кілька сотень мілісекунд і ставити активи як гарантію. Ці заголовки L2 блоків врешті-решт буде опубліковано на L1.
Однак вимога, щоб усі L2 реалізували децентралізоване сортування, здається, не зовсім справедливою, адже це еквівалентно вимозі, щоб rollup виконав практично таку ж роботу, як і створення нової L1. Тому було запропоновано, щоб усі L2 (та L1) спільно використовували механізм попереднього підтвердження в межах Ethereum: базове попереднє підтвердження.
базове попереднє підтвердження
Базовий метод попереднього підтвердження припускає, що пропоненти Ethereum є складними учасниками, пов'язаними з MEV. Він використовує цю складність, заохочуючи цих пропонентів приймати відповідальність за надання послуг попереднього підтвердження.
Цей метод створює стандартизований протокол, за яким користувачі можуть сплачувати додаткову плату для отримання миттєвих гарантій того, що транзакція буде включена в наступний блок, а також зобов'язання щодо виконання результатів цієї транзакції. Якщо пропонент порушить зобов'язання, він буде підданий покаранню.
Цей механізм підходить не лише для L1-транзакцій, для "базованих" на Ethereum rollups всі L2 блоки фактично є L1 транзакціями, тому той самий механізм може надати попереднє підтвердження для будь-якого L2.
Майбутня можлива архітектура
Припустимо, ми реалізували однослотову остаточність, і використовуємо технології, подібні до Orbit, для зменшення кількості валідаторів, які підписують кожен слот, зберігаючи при цьому достатню децентралізацію для зниження бар'єру для стейкінгу. Тривалість слоту може збільшитися до 16 секунд, після чого ми використовуємо попереднє підтвердження rollup або базове попереднє підтвердження, щоб надати користувачам швидше підтвердження. В результаті ми отримуємо архітектуру циклу-слоту.
Ця архітектура важко уникнути, оскільки час, необхідний для досягнення загального консенсусу з певного питання, значно менший, ніж час, необхідний для досягнення максимальної "економічної остаточності". Причини включають:
У поточному Ethereum 12-секундний слот поділяється на три підслоти: публікація та розподіл блоків, доказ, агрегація доказів. Якщо значно зменшити кількість доказувачів, ми можемо зменшити до двох підслотів, реалізуючи 8-секундний слот. Якщо ми зможемо покладатися на спеціалізовану підмножину вузлів для досягнення наближеного консенсусу (при цьому все ще використовуючи повний набір валідаторів для визначення остаточності), ми навіть можемо скоротити час до приблизно 2 секунд.
Отже, архітектура циклів-слотів здається неминучою, але між різними реалізаціями існують відмінності. Варто дослідити напрямок встановлення більшої роздільності уваги між двома механізмами, а не тісно пов'язувати їх, як у Gasper.
Вибір стратегії L2
L2 наразі має три обґрунтовані стратегії:
В технічному та ідеологічному плані "базується" на Ethereum. Ці rollup можна розглядати як "брендовані шардінги", а також вони можуть проводити численні експерименти з новим дизайном віртуальної машини та іншими технологічними вдосконаленнями.
Стати "сервером з каркасом блокчейну". Отримати більшість переваг від блокчейну, додаючи STARK доказ ефективності, забезпечуючи права виходу користувачів, підтримуючи колективний вибір тощо, при цьому зберігаючи ефективні переваги сервера.
Компромісний метод: створити швидкий ланцюг з сотнею вузлів, одночасно використовуючи Ethereum для надання додаткової взаємодії та безпеки. Це фактична дорожня карта багатьох L2 проектів на сьогодні.
Для деяких застосувань (таких як ENS, зберігання ключів, часткові платіжні протоколи) 12 секунд часу блоку вже достатньо. Для інших застосувань єдиним рішенням є архітектура циклів-слотів. У цій архітектурі "цикл" є SSF Ethereum, а "слот" у різних випадках різний:
Ключове питання в тому, наскільки добре може працювати перший варіант. Якщо він покаже відмінні результати, значення третього варіанту зменшиться. Другий варіант завжди існуватиме, оскільки всі "базовані" на Ethereum рішення не підходять для таких L2, як plasmas та validiums, що використовують позасистемні дані. Якщо рідна архітектура Ethereum зі схемою циклів-слотів зможе зменшити час слоту до 1 секунди, простір третього варіанту значно звузиться.
На даний момент ми ще далеко від остаточних відповідей на ці питання. Однією з ключових невизначеностей є те, наскільки складними стануть блок-пропоненти. Нові дизайнерські рішення, такі як Orbit SSF, надають нам більше простору для досліджень, наприклад, використання Orbit SSF як періоду в архітектурі період-слот. Чим більше у нас є варіантів, тим краще ми можемо обслуговувати користувачів L1 і L2, одночасно спрощуючи роботу розробників L2.