Швидке підтвердження交易: новий напрямок для покращення досвіду користувачів Ethereum
Важливим аспектом досвіду користувачів блокчейну є швидкість підтвердження транзакцій. Останніми роками Ethereum досяг значного прогресу в цьому напрямку. Завдяки EIP-1559 і стабільному часу блокування після переходу на PoS, транзакції, надіслані користувачами на L1, зазвичай підтверджуються за 5-20 секунд, що приблизно відповідає досвіду оплати кредитною карткою. Проте подальше скорочення часу підтвердження все ще має значення, деякі додатки навіть вимагають підсекундної затримки. У цій статті буде розглянуто кілька можливих рішень для підвищення швидкості підтвердження транзакцій в Ethereum.
Огляд існуючих технологій
Однослотова остаточність
Зараз консенсус Gasper Ethereum використовує архітектуру слота (Slot) та епохи (Epoch). Кожні 12 секунд відбувається слот, частина валідаторів голосує за голівку ланцюга, 32 слота (6,4 хвилини ) всі валідатори по черзі голосують один раз. Ці голоси інтерпретуються як повідомлення в алгоритмі консенсусу типу PBFT, два епохи (12,8 хвилини ) забезпечують сильні економічні гарантії фіналізації.
Останніми роками цей метод поступово виявляє недоліки: по-перше, висока складність, взаємодія між механізмами рівня слота і епохи легко може бути помилковою; по-друге, час очікування 12,8 хвилин занадто довгий. Однослотова фінальність (Single Slot Finality, SSF) замінила цю архітектуру через механізм, подібний до Tendermint, блок N може бути остаточно підтверджений перед генерацією N+1. SSF зберігає механізм "неактивного витоку", що дозволяє ланцюгу продовжувати працювати та відновлюватися, навіть якщо понад 1/3 валідаторів знаходяться в офлайні.
Основними викликами SSF є те, що кожен стейкер повинен надсилати два повідомлення кожні 12 секунд, що створює величезне навантаження на мережу. Хоча існують деякі рішення, такі як нещодавня пропозиція Orbit SSF, користувачам все ще потрібно чекати 5-20 секунд, щоб підтвердити транзакцію.
Попереднє підтвердження Rollup
Останніми роками Ethereum дотримується дорожньої карти, зосередженої на rollup, проектуючи L1 для підтримки базових функцій, таких як доступність даних, для використання L2 протоколами (, такими як rollups, validiums і plasmas ), забезпечуючи аналогічну безпеку для користувачів на більшому масштабі.
Це призвело до поділу праці в екосистемі Ethereum: L1 зосереджується на антикорупції, надійності та поліпшенні основних функцій, тоді як L2 безпосередньо обслуговує потреби користувачів. Однак L2 прагне надати користувачам підтвердження швидше, ніж за 5-20 секунд.
Теоретично, створення децентралізованої мережі сортувальників є відповідальністю L2. Невелика група валідацій може підписувати блоки кожні кілька сотень мілісекунд та ставити активи як забезпечення. Ці заголовки блоків L2 врешті-решт будуть опубліковані на L1.
Але набір валідаторів L2 може зловживати: спочатку підписати блок B1, а потім підписати конфліктний B2 та подати його заздалегідь. Як тільки це буде виявлено, вони втратять свої стейкінгові активи. Наразі вже є централізовані версії таких випадків, але розробка децентралізованих мереж для ранжування у rollup просувається повільно. Вимагати, щоб всі L2 реалізували децентралізоване ранжування, здається, не зовсім справедливим, це майже рівнозначно створенню абсолютно нового L1. Тому було запропоновано дати всім L2( та L1) спільно використовувати механізм попереднього підтвердження в межах Ethereum: базове попереднє підтвердження.
Базове попереднє підтвердження
Базове припущення про попереднє підтвердження полягає в тому, що пропонувальники Ethereum є високо складеними учасниками, пов'язаними з MEV, які використовують цю складність, заохочуючи їх брати на себе відповідальність за послуги попереднього підтвердження.
Основна ідея полягає в створенні стандартизованого протоколу, де користувачі можуть сплачувати додаткову плату, щоб негайно отримати гарантію включення транзакції до наступного блоку та оголошення результатів транзакції. Якщо пропонент порушить умови, його буде конфісковано.
Цей механізм може бути використаний як для L1-транзакцій, так і для L2-блоків, які "базуються на" роллапах.
Перспективи майбутнього
Припустимо, ми реалізували остаточність в одному слоту, використовуючи технологію класу Orbit для зменшення кількості валідаторів підпису в кожному слоті, одночасно просуваючи мету зниження порогу застави до 32 ETH. Тривалість слоту може збільшитися до 16 секунд, а потім використовувати попереднє підтвердження rollup або базове попереднє підтвердження для надання користувачам швидшого підтвердження. В результаті ми отримуємо нову еру - архітектуру слотів.
Глибокою причиною, чому така архітектура важко уникнути, є те, що час, необхідний для досягнення приблизної згоди з певного питання, набагато менший, ніж час, необхідний для досягнення максимальної "економічної остаточності".
Основні причини включають кількість вузлів та "якість" вузлів. "Приблизний консенсус" вимагає лише невеликої кількості вузлів, тоді як економічна фінальність потребує участі більшості вузлів. Спеціалізований підмнож вузлів може зменшити час протоколу до приблизно 2 секунд.
Отже, архітектура епохи-слота здається правильним напрямком, але між різними реалізаціями існують відмінності. Варто дослідити можливість встановлення більшої відокремленості уваги між двома механізмами, а не так тісно зв'язувати їх, як у Gasper.
Вибір L2
Наразі існує три розумні стратегії для L2:
Технологічно та ідеологічно "базується" на Ethereum, оптимізуючи його базові властивості та цінності. Може розглядатися як "брендове шардінг", також може сміливо інновувати в таких аспектах, як нове проектування VM.
Стати "сервером з блокчейн-скелетом", максимально використовуючи переваги централізації, одночасно забезпечуючи безпеку через докази ефективності, механізми виходу тощо.
Компромісний варіант: швидка ланцюг з приблизно сотнею вузлів, Ethereum забезпечує додаткову взаємодію та безпеку. Це є поточним маршрутом багатьох проектів L2.
Для деяких застосувань (, таких як ENS, зберігання ключів, часткові платіжні протоколи ), 12 секунд часу блокування є достатнім. В інших випадках потрібна архітектура епохи-слоту, де "епоха" є SSF Ethereum, а "слот" змінюється залежно від застосування.
Ключове питання полягає в тому, на яку міру може вплинути рідна епохально-слотова архітектура Ethereum. Якщо час слота зможе зменшитися до 1 секунди, простір третього варіанту значно скоротиться.
Наразі ми ще далеко від остаточних відповідей на ці питання. Еволюція складності пропозицій блоків залишається достатньо невизначеною. Новаторські рішення, такі як Orbit SSF, відкривають великі можливості для досліджень. Чим більше варіантів, тим кращий досвід ми зможемо надати користувачам L1 та L2, а також спростити роботу розробників L2.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
8 лайків
Нагородити
8
8
Поділіться
Прокоментувати
0/400
MEVSandwich
· 07-21 06:44
Заблокувати угоду занадто повільно, помираю від смутку.
Переглянути оригіналвідповісти на0
CryptoMotivator
· 07-18 23:17
Увесь день все повільно, все зростає
Переглянути оригіналвідповісти на0
DegenWhisperer
· 07-18 09:24
газ дорого, коли знизиться?
Переглянути оригіналвідповісти на0
SelfCustodyBro
· 07-18 08:50
Біжить швидше за gwei
Переглянути оригіналвідповісти на0
HashRateHermit
· 07-18 08:42
Чому всі скаржаться на повільність?
Переглянути оригіналвідповісти на0
GasFeeCrybaby
· 07-18 08:41
Чому ще не швидше?
Переглянути оригіналвідповісти на0
RugDocDetective
· 07-18 08:34
Підтвердження триває занадто довго, чекаю на лисого
Прискорення підтвердження транзакцій Ethereum: дослідження механізму остаточності одного слота та попереднього підтвердження
Швидке підтвердження交易: новий напрямок для покращення досвіду користувачів Ethereum
Важливим аспектом досвіду користувачів блокчейну є швидкість підтвердження транзакцій. Останніми роками Ethereum досяг значного прогресу в цьому напрямку. Завдяки EIP-1559 і стабільному часу блокування після переходу на PoS, транзакції, надіслані користувачами на L1, зазвичай підтверджуються за 5-20 секунд, що приблизно відповідає досвіду оплати кредитною карткою. Проте подальше скорочення часу підтвердження все ще має значення, деякі додатки навіть вимагають підсекундної затримки. У цій статті буде розглянуто кілька можливих рішень для підвищення швидкості підтвердження транзакцій в Ethereum.
Огляд існуючих технологій
Однослотова остаточність
Зараз консенсус Gasper Ethereum використовує архітектуру слота (Slot) та епохи (Epoch). Кожні 12 секунд відбувається слот, частина валідаторів голосує за голівку ланцюга, 32 слота (6,4 хвилини ) всі валідатори по черзі голосують один раз. Ці голоси інтерпретуються як повідомлення в алгоритмі консенсусу типу PBFT, два епохи (12,8 хвилини ) забезпечують сильні економічні гарантії фіналізації.
Останніми роками цей метод поступово виявляє недоліки: по-перше, висока складність, взаємодія між механізмами рівня слота і епохи легко може бути помилковою; по-друге, час очікування 12,8 хвилин занадто довгий. Однослотова фінальність (Single Slot Finality, SSF) замінила цю архітектуру через механізм, подібний до Tendermint, блок N може бути остаточно підтверджений перед генерацією N+1. SSF зберігає механізм "неактивного витоку", що дозволяє ланцюгу продовжувати працювати та відновлюватися, навіть якщо понад 1/3 валідаторів знаходяться в офлайні.
Основними викликами SSF є те, що кожен стейкер повинен надсилати два повідомлення кожні 12 секунд, що створює величезне навантаження на мережу. Хоча існують деякі рішення, такі як нещодавня пропозиція Orbit SSF, користувачам все ще потрібно чекати 5-20 секунд, щоб підтвердити транзакцію.
Попереднє підтвердження Rollup
Останніми роками Ethereum дотримується дорожньої карти, зосередженої на rollup, проектуючи L1 для підтримки базових функцій, таких як доступність даних, для використання L2 протоколами (, такими як rollups, validiums і plasmas ), забезпечуючи аналогічну безпеку для користувачів на більшому масштабі.
Це призвело до поділу праці в екосистемі Ethereum: L1 зосереджується на антикорупції, надійності та поліпшенні основних функцій, тоді як L2 безпосередньо обслуговує потреби користувачів. Однак L2 прагне надати користувачам підтвердження швидше, ніж за 5-20 секунд.
Теоретично, створення децентралізованої мережі сортувальників є відповідальністю L2. Невелика група валідацій може підписувати блоки кожні кілька сотень мілісекунд та ставити активи як забезпечення. Ці заголовки блоків L2 врешті-решт будуть опубліковані на L1.
Але набір валідаторів L2 може зловживати: спочатку підписати блок B1, а потім підписати конфліктний B2 та подати його заздалегідь. Як тільки це буде виявлено, вони втратять свої стейкінгові активи. Наразі вже є централізовані версії таких випадків, але розробка децентралізованих мереж для ранжування у rollup просувається повільно. Вимагати, щоб всі L2 реалізували децентралізоване ранжування, здається, не зовсім справедливим, це майже рівнозначно створенню абсолютно нового L1. Тому було запропоновано дати всім L2( та L1) спільно використовувати механізм попереднього підтвердження в межах Ethereum: базове попереднє підтвердження.
Базове попереднє підтвердження
Базове припущення про попереднє підтвердження полягає в тому, що пропонувальники Ethereum є високо складеними учасниками, пов'язаними з MEV, які використовують цю складність, заохочуючи їх брати на себе відповідальність за послуги попереднього підтвердження.
Основна ідея полягає в створенні стандартизованого протоколу, де користувачі можуть сплачувати додаткову плату, щоб негайно отримати гарантію включення транзакції до наступного блоку та оголошення результатів транзакції. Якщо пропонент порушить умови, його буде конфісковано.
Цей механізм може бути використаний як для L1-транзакцій, так і для L2-блоків, які "базуються на" роллапах.
Перспективи майбутнього
Припустимо, ми реалізували остаточність в одному слоту, використовуючи технологію класу Orbit для зменшення кількості валідаторів підпису в кожному слоті, одночасно просуваючи мету зниження порогу застави до 32 ETH. Тривалість слоту може збільшитися до 16 секунд, а потім використовувати попереднє підтвердження rollup або базове попереднє підтвердження для надання користувачам швидшого підтвердження. В результаті ми отримуємо нову еру - архітектуру слотів.
Глибокою причиною, чому така архітектура важко уникнути, є те, що час, необхідний для досягнення приблизної згоди з певного питання, набагато менший, ніж час, необхідний для досягнення максимальної "економічної остаточності".
Основні причини включають кількість вузлів та "якість" вузлів. "Приблизний консенсус" вимагає лише невеликої кількості вузлів, тоді як економічна фінальність потребує участі більшості вузлів. Спеціалізований підмнож вузлів може зменшити час протоколу до приблизно 2 секунд.
Отже, архітектура епохи-слота здається правильним напрямком, але між різними реалізаціями існують відмінності. Варто дослідити можливість встановлення більшої відокремленості уваги між двома механізмами, а не так тісно зв'язувати їх, як у Gasper.
Вибір L2
Наразі існує три розумні стратегії для L2:
Технологічно та ідеологічно "базується" на Ethereum, оптимізуючи його базові властивості та цінності. Може розглядатися як "брендове шардінг", також може сміливо інновувати в таких аспектах, як нове проектування VM.
Стати "сервером з блокчейн-скелетом", максимально використовуючи переваги централізації, одночасно забезпечуючи безпеку через докази ефективності, механізми виходу тощо.
Компромісний варіант: швидка ланцюг з приблизно сотнею вузлів, Ethereum забезпечує додаткову взаємодію та безпеку. Це є поточним маршрутом багатьох проектів L2.
Для деяких застосувань (, таких як ENS, зберігання ключів, часткові платіжні протоколи ), 12 секунд часу блокування є достатнім. В інших випадках потрібна архітектура епохи-слоту, де "епоха" є SSF Ethereum, а "слот" змінюється залежно від застосування.
Ключове питання полягає в тому, на яку міру може вплинути рідна епохально-слотова архітектура Ethereum. Якщо час слота зможе зменшитися до 1 секунди, простір третього варіанту значно скоротиться.
Наразі ми ще далеко від остаточних відповідей на ці питання. Еволюція складності пропозицій блоків залишається достатньо невизначеною. Новаторські рішення, такі як Orbit SSF, відкривають великі можливості для досліджень. Чим більше варіантів, тим кращий досвід ми зможемо надати користувачам L1 та L2, а також спростити роботу розробників L2.