Обговорення плану оптимізації часу підтвердження транзакцій Ethereum
Важливим аспектом досвіду користувачів блокчейну є швидкий час підтвердження транзакцій. В останні роки Ethereum досяг значного прогресу в цій сфері. Завдяки EIP-1559 та стабільному часу блокування після переходу на PoS, транзакції, відправлені користувачами на L1, зазвичай можуть бути підтверджені протягом 5-20 секунд, що в основному відповідає досвіду оплати кредитною карткою. Однак подальше покращення користувацького досвіду все ще має сенс, деякі додатки навіть потребують затримки в субсекундному діапазоні. У цій статті буде розглянуто кілька реалістичних варіантів покращення часу підтвердження транзакцій в Ethereum.
Огляд існуючих технологій
Однослотова остаточність
Наразі консенсус Gasper в Ethereum використовує архітектуру з одного слота та епохи. Кожні 12 секунд один слот, частина валідаторів голосує за голову ланцюга, всі валідатори мають можливість проголосувати один раз протягом 32 слотів. Ці голоси переінтерпретуються як повідомлення, подібні до алгоритму консенсусу PBFT, і забезпечують сильну економічну гарантію остаточності через два епохи.
Останніми роками люди все більше незадоволені цим методом, і є дві основні причини: по-перше, висока складність, існує багато взаємодій між механізмом голосування «слот до слоту» та механізмом остаточності «епоха до епохи»; по-друге, час остаточності в 12,8 хвилини занадто довгий.
Остаточність в одній ячейці (SSF) замінила цю архітектуру за допомогою механізму, подібного до Tendermint, дозволяючи остаточно підтвердити блок N до його генерації в блоці N+1. Основна відмінність від Tendermint полягає в збереженні механізму "неактивного витоку", що дозволяє ланцюгу продовжувати функціонувати і відновлюватися, коли понад 1/3 валідаторів офлайн.
Основним викликом SSF є те, що кожен стейкер повинен кожні 12 секунд публікувати два повідомлення, що створює величезне навантаження на ланцюг. Хоча існують деякі варіанти пом'якшення, такі як нещодавня пропозиція Orbit SSF, це не змінило факту, що користувачам потрібно чекати 5-20 секунд.
Попереднє підтвердження Rollup
Ethereum в останні роки дотримується дорожньої карти, зосередженої на rollup, проектуючи L1 як базовий рівень для підтримки доступності даних та інших функцій для використання протоколами L2. Це призвело до розмежування уваги в екосистемі: L1 зосереджується на антикорупційності, надійності та вдосконаленні основних функцій, тоді як L2 більш безпосередньо обслуговує потреби користувачів.
Теоретично, створення децентралізованої мережі сортувальників є відповідальністю L2. Невелика група валідаторів може підписувати блоки кожні кілька сотень мілісекунд і публікувати заголовки цих блоків в L1. Проте вимагати, щоб усі L2 виконували децентралізоване сортування, здається, не зовсім справедливим, оскільки це еквівалентно створенню абсолютно нового L1.
Базове попереднє підтвердження
Базове припущення про попереднє підтвердження полягає в тому, що пропоненти Ethereum є високо складними учасниками MEV. Цей підхід використовує їхню складність, стимулюючи цих пропонентів приймати відповідальність за надання послуг попереднього підтвердження.
Його основна ідея полягає в створенні стандартизованого протоколу, за яким користувачі можуть сплачувати додаткові збори, щоб отримати миттєву гарантію включення транзакції в наступний блок, а також заяву про результат виконання. Якщо пропонент порушить обіцянку, він буде оштрафований.
Цей механізм підходить не лише для L1-транзакцій, але й може надати попереднє підтвердження для "на базі" роллапів.
Майбутнє бачення
Припустимо, що реалізовано остаточність у межах одного слоту, і використано технології, подібні до Orbit, для зменшення кількості валідаторів в кожному слоті. Тривалість слоту може збільшитися до 16 секунд, а потім використовувати попереднє підтвердження rollup або базове попереднє підтвердження для надання користувачам швидшого підтвердження. В результаті ми можемо отримати архітектуру epoch-slot.
архітектура epoch-slot, схоже, важко уникнути, оскільки час, необхідний для досягнення загальної згоди з певного питання, менший, ніж для досягнення максимальної "економічної остаточності" угоди. Причини включають кількість вузлів і "якість" вузлів.
У поточному Ethereum 12-секундний слот розділений на три підслоти. Якщо значно зменшити кількість валідаторів, це може зменшитися до двох підслотів з використанням 8-секундного часу слота. Якщо покладатися на спеціалізовані підмножини вузлів для досягнення наближеного консенсусу, це може ще більше скоротитися до приблизно 2 секунд.
Рекомендації щодо стратегії L2
L2 наразі має три розумні стратегії:
Технічно та духовно "базується" на Ethereum, оптимізуючи його базові технологічні властивості та цінності.
Стати "сервером з блокчейн-скелетом", максимально використовуючи ефективність сервера та отримуючи переваги від запису в блокчейн.
Компромісний метод: швидкий ланцюг з приблизно ста вузлами, Ethereum забезпечує додаткову взаємодію та безпеку.
Для деяких застосувань час формування блоку в 12 секунд є достатнім. Для інших застосувань єдиним рішенням є архітектура epoch-slot. Ключове питання полягає в тому, наскільки добре рідна архітектура epoch-slot Ethereum може впоратися з цим, що вплине на значення інших рішень.
Наразі ми ще далекі від остаточних відповідей на ці питання. Складність блок-пропозицій залишається досить невизначеною. Новаторські дизайни, такі як Orbit SSF, варто подальшого вивчення. Чим більше у нас є варіантів, тим краще ми можемо обслуговувати користувачів L1 і L2 та спростити роботу розробників L2.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
22 лайків
Нагородити
22
8
Репост
Поділіться
Прокоментувати
0/400
ShibaMillionairen't
· 07-21 14:39
Торгівля криптовалютою як сновидіння, смішно. Зачекайте, якщо час підтвердження скоротиться, хіба це не ускладнить обдурювання людей, як лохів?
Переглянути оригіналвідповісти на0
DefiPlaybook
· 07-20 15:55
Це справді абсурдно, чи я просто довго працював на будівництві.
Переглянути оригіналвідповісти на0
GasFeeCryer
· 07-20 01:55
Старі часи L1 підтверджувалися так повільно, що це було сумно. Тепер хоча б з натяжкою можна використовувати.
Переглянути оригіналвідповісти на0
CryptoTherapist
· 07-20 01:48
торгівельна тривога реальна сім'я... давайте помедитуємо на тих часах підтвердження і звільнимося від менталітету fomo, якщо чесно
Переглянути оригіналвідповісти на0
MissedTheBoat
· 07-20 01:47
Кредитна картка не має бути такою повільною... Швидше!
Переглянути оригіналвідповісти на0
AllInAlice
· 07-20 01:46
Підтвердження швидко наближається, 5 секунд вже достатньо дивовижні.
Переглянути оригіналвідповісти на0
AirdropHunterZhang
· 07-20 01:28
Рекомендую всім не захоплюватися газом, якщо ціна знизиться, то можна All in.
Обговорення оптимізації часу підтвердження транзакцій Ethereum: порівняння SSF, Rollup та основних попередніх підтверджувальних схем
Обговорення плану оптимізації часу підтвердження транзакцій Ethereum
Важливим аспектом досвіду користувачів блокчейну є швидкий час підтвердження транзакцій. В останні роки Ethereum досяг значного прогресу в цій сфері. Завдяки EIP-1559 та стабільному часу блокування після переходу на PoS, транзакції, відправлені користувачами на L1, зазвичай можуть бути підтверджені протягом 5-20 секунд, що в основному відповідає досвіду оплати кредитною карткою. Однак подальше покращення користувацького досвіду все ще має сенс, деякі додатки навіть потребують затримки в субсекундному діапазоні. У цій статті буде розглянуто кілька реалістичних варіантів покращення часу підтвердження транзакцій в Ethereum.
Огляд існуючих технологій
Однослотова остаточність
Наразі консенсус Gasper в Ethereum використовує архітектуру з одного слота та епохи. Кожні 12 секунд один слот, частина валідаторів голосує за голову ланцюга, всі валідатори мають можливість проголосувати один раз протягом 32 слотів. Ці голоси переінтерпретуються як повідомлення, подібні до алгоритму консенсусу PBFT, і забезпечують сильну економічну гарантію остаточності через два епохи.
Останніми роками люди все більше незадоволені цим методом, і є дві основні причини: по-перше, висока складність, існує багато взаємодій між механізмом голосування «слот до слоту» та механізмом остаточності «епоха до епохи»; по-друге, час остаточності в 12,8 хвилини занадто довгий.
Остаточність в одній ячейці (SSF) замінила цю архітектуру за допомогою механізму, подібного до Tendermint, дозволяючи остаточно підтвердити блок N до його генерації в блоці N+1. Основна відмінність від Tendermint полягає в збереженні механізму "неактивного витоку", що дозволяє ланцюгу продовжувати функціонувати і відновлюватися, коли понад 1/3 валідаторів офлайн.
Основним викликом SSF є те, що кожен стейкер повинен кожні 12 секунд публікувати два повідомлення, що створює величезне навантаження на ланцюг. Хоча існують деякі варіанти пом'якшення, такі як нещодавня пропозиція Orbit SSF, це не змінило факту, що користувачам потрібно чекати 5-20 секунд.
Попереднє підтвердження Rollup
Ethereum в останні роки дотримується дорожньої карти, зосередженої на rollup, проектуючи L1 як базовий рівень для підтримки доступності даних та інших функцій для використання протоколами L2. Це призвело до розмежування уваги в екосистемі: L1 зосереджується на антикорупційності, надійності та вдосконаленні основних функцій, тоді як L2 більш безпосередньо обслуговує потреби користувачів.
Теоретично, створення децентралізованої мережі сортувальників є відповідальністю L2. Невелика група валідаторів може підписувати блоки кожні кілька сотень мілісекунд і публікувати заголовки цих блоків в L1. Проте вимагати, щоб усі L2 виконували децентралізоване сортування, здається, не зовсім справедливим, оскільки це еквівалентно створенню абсолютно нового L1.
Базове попереднє підтвердження
Базове припущення про попереднє підтвердження полягає в тому, що пропоненти Ethereum є високо складними учасниками MEV. Цей підхід використовує їхню складність, стимулюючи цих пропонентів приймати відповідальність за надання послуг попереднього підтвердження.
Його основна ідея полягає в створенні стандартизованого протоколу, за яким користувачі можуть сплачувати додаткові збори, щоб отримати миттєву гарантію включення транзакції в наступний блок, а також заяву про результат виконання. Якщо пропонент порушить обіцянку, він буде оштрафований.
Цей механізм підходить не лише для L1-транзакцій, але й може надати попереднє підтвердження для "на базі" роллапів.
Майбутнє бачення
Припустимо, що реалізовано остаточність у межах одного слоту, і використано технології, подібні до Orbit, для зменшення кількості валідаторів в кожному слоті. Тривалість слоту може збільшитися до 16 секунд, а потім використовувати попереднє підтвердження rollup або базове попереднє підтвердження для надання користувачам швидшого підтвердження. В результаті ми можемо отримати архітектуру epoch-slot.
архітектура epoch-slot, схоже, важко уникнути, оскільки час, необхідний для досягнення загальної згоди з певного питання, менший, ніж для досягнення максимальної "економічної остаточності" угоди. Причини включають кількість вузлів і "якість" вузлів.
У поточному Ethereum 12-секундний слот розділений на три підслоти. Якщо значно зменшити кількість валідаторів, це може зменшитися до двох підслотів з використанням 8-секундного часу слота. Якщо покладатися на спеціалізовані підмножини вузлів для досягнення наближеного консенсусу, це може ще більше скоротитися до приблизно 2 секунд.
Рекомендації щодо стратегії L2
L2 наразі має три розумні стратегії:
Для деяких застосувань час формування блоку в 12 секунд є достатнім. Для інших застосувань єдиним рішенням є архітектура epoch-slot. Ключове питання полягає в тому, наскільки добре рідна архітектура epoch-slot Ethereum може впоратися з цим, що вплине на значення інших рішень.
Наразі ми ще далекі від остаточних відповідей на ці питання. Складність блок-пропозицій залишається досить невизначеною. Новаторські дизайни, такі як Orbit SSF, варто подальшого вивчення. Чим більше у нас є варіантів, тим краще ми можемо обслуговувати користувачів L1 і L2 та спростити роботу розробників L2.