Обговорення оптимізації швидкості підтвердження транзакцій Ethereum
У досвіді користувачів блокчейна, час підтвердження транзакцій є ключовим фактором. Ethereum за останні кілька років завдяки EIP-1559 та переходу на PoS скоротив час підтвердження транзакцій до 5-20 секунд, що порівняно з оплатою кредитною карткою. Однак подальше скорочення часу підтвердження все ще має значення, деякі додатки навіть потребують підсекундної затримки. У цій статті буде розглянуто можливі варіанти подальшої оптимізації часу підтвердження транзакцій у Ethereum.
Огляд існуючих технологій
Однослотова остаточність
Наразі Ethereum використовує механізм консенсусу Gasper, кожні 12 секунд відбувається слот, 32 слоти складають один Epoch. Валідатори голосують за голову ланцюга, остаточність досягається через два Epoch. Цей механізм має проблеми з високою складністю, тривалим часом остаточності (12.8 хвилин) та ін.
Остаточність одного слота (SSF) подібна до консенсусу Tendermint, кожен блок може досягти остаточності перед генерацією наступного блоку. Головним викликом є велике навантаження на мережу, що вимагає від кожного валідатора публікації двох повідомлень кожні 12 секунд. Хоча є деякі оптимізаційні рішення, такі як Orbit SSF, користувачам все ще потрібно чекати 5-20 секунд для підтвердження транзакції.
Попереднє підтвердження Rollup
Ethereum використовує модель масштабування, зосереджену на rollup, рішення L2 повинні забезпечити користувачам швидше підтвердження. Теоретично L2 може створити власну мережу "децентралізованих сортувальників", підписуючи блоки кожні кілька сотень мілісекунд. Але це вимагає від L2 виконання практично такої ж роботи, як і створення нового L1, що насправді просувається повільніше.
Базове попереднє підтвердження
Ця схема використовує складність пропонентів блокчейну Ethereum, щоб стимулювати їх надавати послуги попереднього підтвердження. Користувачі можуть сплачувати додаткову плату, щоб отримати негайну гарантію того, що транзакція буде включена в наступний блок. Якщо пропонент порушить обіцянку, він буде покараний. Цей механізм може забезпечити попереднє підтвердження для L1 та L2 на основі Ethereum.
Можливі архітектурні рішення
Припустимо, що реалізовано остаточність одного слоту та використовуються технології, подібні до Orbit, для зменшення кількості валідаторів підпису в кожному слоті, одночасно використовуючи rollup-попереднє підтвердження або базове попереднє підтвердження для надання швидшого підтвердження. Врешті-решт, ми отримуємо архітектуру epoch-slot:
Епоха: 16 секунд, гарантується механізмом остаточної єдності з одним слотом
Слот: приблизно 2 секунди, досягнення приблизної згоди професійним підмножиною вузлів
Ця архітектура може збалансувати потреби в децентралізації, остаточності та швидкому підтвердженні. L2 може застосувати такі стратегії:
Повністю засновано на Ethereum, оптимізація основних властивостей та цінностей
Схоже на "сервери з блокчейн-скелетом", зберігаючи ефективність серверів, отримуючи переваги від ланцюга.
Компромісний варіант: швидка ланцюг з приблизно 100 вузлами, забезпечена додатковою безпекою від Ethereum
Для різних сценаріїв застосування можна вибрати різні механізми слотів:
Архітектура epoch-slot рідного Ефіру
Попереднє підтвердження сервера
Попереднє підтвердження комітетом
Якщо рідна архітектура Ethereum зможе скоротити час слота до 1 секунди, значення третього варіанту зменшиться. Але дані поза ланцюгом L2(, такі як plasmas і validiums), все ще потребують другого варіанту.
На даний момент ми все ще маємо певну відстань до фінального рішення. Ключові питання включають складність пропозицій блоків, потенціал нових дизайнів, таких як Orbit SSF, тощо. Дослідження додаткових варіантів допоможе покращити досвід користувачів L1 та L2, спростити розробку L2.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
17 лайків
Нагородити
17
4
Поділіться
Прокоментувати
0/400
LazyDevMiner
· 08-05 12:26
Відчувається повільно, але це всього лише на одну-дві секунди, кому це важливо?
Переглянути оригіналвідповісти на0
ValidatorVibes
· 08-05 12:18
був не спав всю ніч, думаючи... ssf може бути класним, але що з винагородами для валідаторів?
Переглянути оригіналвідповісти на0
AirdropHunterWang
· 08-05 12:17
Швидше, швидше, повільно в одну купу.
Переглянути оригіналвідповісти на0
OnchainGossiper
· 08-05 12:08
Не просто зміна механізму консенсусу, чому так поспішати?
Оптимізація швидкості підтвердження транзакцій Ethereum: дослідження рішень з затримкою в підсекунди
Обговорення оптимізації швидкості підтвердження транзакцій Ethereum
У досвіді користувачів блокчейна, час підтвердження транзакцій є ключовим фактором. Ethereum за останні кілька років завдяки EIP-1559 та переходу на PoS скоротив час підтвердження транзакцій до 5-20 секунд, що порівняно з оплатою кредитною карткою. Однак подальше скорочення часу підтвердження все ще має значення, деякі додатки навіть потребують підсекундної затримки. У цій статті буде розглянуто можливі варіанти подальшої оптимізації часу підтвердження транзакцій у Ethereum.
Огляд існуючих технологій
Однослотова остаточність
Наразі Ethereum використовує механізм консенсусу Gasper, кожні 12 секунд відбувається слот, 32 слоти складають один Epoch. Валідатори голосують за голову ланцюга, остаточність досягається через два Epoch. Цей механізм має проблеми з високою складністю, тривалим часом остаточності (12.8 хвилин) та ін.
Остаточність одного слота (SSF) подібна до консенсусу Tendermint, кожен блок може досягти остаточності перед генерацією наступного блоку. Головним викликом є велике навантаження на мережу, що вимагає від кожного валідатора публікації двох повідомлень кожні 12 секунд. Хоча є деякі оптимізаційні рішення, такі як Orbit SSF, користувачам все ще потрібно чекати 5-20 секунд для підтвердження транзакції.
Попереднє підтвердження Rollup
Ethereum використовує модель масштабування, зосереджену на rollup, рішення L2 повинні забезпечити користувачам швидше підтвердження. Теоретично L2 може створити власну мережу "децентралізованих сортувальників", підписуючи блоки кожні кілька сотень мілісекунд. Але це вимагає від L2 виконання практично такої ж роботи, як і створення нового L1, що насправді просувається повільніше.
Базове попереднє підтвердження
Ця схема використовує складність пропонентів блокчейну Ethereum, щоб стимулювати їх надавати послуги попереднього підтвердження. Користувачі можуть сплачувати додаткову плату, щоб отримати негайну гарантію того, що транзакція буде включена в наступний блок. Якщо пропонент порушить обіцянку, він буде покараний. Цей механізм може забезпечити попереднє підтвердження для L1 та L2 на основі Ethereum.
Можливі архітектурні рішення
Припустимо, що реалізовано остаточність одного слоту та використовуються технології, подібні до Orbit, для зменшення кількості валідаторів підпису в кожному слоті, одночасно використовуючи rollup-попереднє підтвердження або базове попереднє підтвердження для надання швидшого підтвердження. Врешті-решт, ми отримуємо архітектуру epoch-slot:
Ця архітектура може збалансувати потреби в децентралізації, остаточності та швидкому підтвердженні. L2 може застосувати такі стратегії:
Для різних сценаріїв застосування можна вибрати різні механізми слотів:
Якщо рідна архітектура Ethereum зможе скоротити час слота до 1 секунди, значення третього варіанту зменшиться. Але дані поза ланцюгом L2(, такі як plasmas і validiums), все ще потребують другого варіанту.
На даний момент ми все ще маємо певну відстань до фінального рішення. Ключові питання включають складність пропозицій блоків, потенціал нових дизайнів, таких як Orbit SSF, тощо. Дослідження додаткових варіантів допоможе покращити досвід користувачів L1 та L2, спростити розробку L2.