Обговорення практичних рішень для покращення часу підтвердження транзакцій Ethereum
Важливим аспектом досвіду користувача блокчейну є час підтвердження транзакцій. У останні роки Ethereum досяг значних успіхів у цій сфері. Наразі транзакції, надіслані користувачами на L1, зазвичай можуть бути підтверджені за 5-20 секунд, що є порівнянним з досвідом оплати кредитною карткою. Однак подальше скорочення часу підтвердження все ще має значення, деяким додаткам навіть потрібна затримка в мілісекундах. У цій статті буде розглянуто деякі можливі варіанти Ethereum у цій сфері.
Огляд існуючих рішень
Однослотова остаточність
Наразі консенсус Gasper в Ethereum використовує архітектуру слотів та епох. Кожні 12 секунд відбувається слот, валідатори голосують за голову ланцюга, за 32 слоти (6.4 хвилини) всі валідатори мають можливість проголосувати один раз. Ці голосування інтерпретуються як повідомлення, подібні до алгоритму консенсусу PBFT, і через два епохи (12.8 хвилини) забезпечують остаточність з сильними економічними гарантіями.
Однак, цей метод має проблеми зі складністю та занадто довгим часом. Остаточність односекційного блоку (SSF) замінила цю архітектуру за допомогою механізму, подібного до Tendermint, що дозволяє остаточно підтвердити блок N до генерації блоку N+1. SSF зберігає механізм "неактивного витоку", що дозволяє ланцюгу продовжувати працювати, коли більше 1/3 валідаторів офлайн.
Основним викликом SSF є те, що кожен стейкер повинен надсилати два повідомлення кожні 12 секунд, що створює значне навантаження на ланцюг. Хоча існують деякі рішення для пом'якшення, такі як пропозиція Orbit SSF, користувачам все ще потрібно чекати 5-20 секунд.
Попереднє підтвердження Rollup
Ethereum використовує дорожню карту, зосереджену на rollup, де L1 забезпечує доступність даних та інші функції, а протокол L2 на цій основі надає користувачам більш масштабні послуги. Це призводить до розділення уваги: L1 зосереджується на антикорупційності, надійності та основних функціях, тоді як L2 безпосередньо відповідає на потреби користувачів.
Теоретично, L2 може створити свою власну мережу "децентралізованих сортувальників", яка підписує блоки кожні кілька сотень мілісекунд. Але це вимагає від L2 виконання майже такої ж роботи, як і при створенні нового L1, що призводить до повільного прогресу. Тому хтось запропонував, щоб всі L2 спільно використовували одну механіку попереднього підтвердження в межах Ethereum: базове попереднє підтвердження.
базова попередня підтвердження
Базове попереднє підтвердження використовує складність пропозиційника Ethereum, щоб мотивувати їх надання послуг попереднього підтвердження. Користувачі можуть сплачувати додаткову плату, щоб отримати негайну гарантію того, що транзакція буде включена в наступний блок. Якщо пропозиціонер порушить зобов'язання, він зазнає покарання. Ця механіка підходить не лише для L1 транзакцій, але й для L2 блоків на основі "rollups".
Можливі напрямки в майбутньому
Припустимо, реалізовано остаточність одного слота, використовуючи технології, подібні до Orbit, щоб зменшити кількість валідаторів, що підписують кожен слот, одночасно знижуючи поріг застави. Тривалість слота може зрости до 16 секунд, поєднуючи попереднє підтвердження rollup або базове попереднє підтвердження для надання користувачам швидшого підтвердження. Це фактично формує архітектуру epoch-slot.
Причина, чому така архітектура важко уникнути, полягає в тому, що досягнення приблизної згоди займає менше часу, ніж досягнення максимальної "економічної остаточності". Впливають фактори, такі як кількість вузлів та "якість" вузлів. Якщо ми можемо покладатися на спеціалізований підмнож вузлів для досягнення приблизного консенсусу, одночасно використовуючи повний набір валідаторів для визначення остаточності, можливо, ми зможемо знизити час підтвердження до близько 2 секунд.
Отже, дослідження простору дизайну архітектури epoch-slot з більшою роздільністю уваги є цінним.
Вибір стратегії L2
L2 наразі має три розумні стратегії:
Технічно та духовно "базується" на Ethereum, оптимізуючи його технічні властивості та цінності.
Стати "сервером з блокчейн-скелетом", поєднуючи ефективність сервера та безпеку блокчейну.
Компромісний метод: швидкий ланцюг у поєднанні з Ethereum забезпечує додаткову міжоперабельність та безпеку.
Для деяких застосувань час блоку в 12 секунд є достатнім. Для інших застосувань єдиним рішенням є архітектура epoch-slot. Ключове питання полягає в тому, наскільки добре рідна архітектура epoch-slot Ethereum може впоратися з цим, що вплине на сенс інших рішень.
На даний момент ми ще далекі від остаточних відповідей на ці питання. Складність пропозицій блоків залишається невизначеною. Нові проекти, такі як Orbit SSF, надають простір для дослідження більшої кількості можливостей. Чим більше варіантів у нас є, тим краще ми можемо обслуговувати користувачів L1 та L2 та спростити роботу розробників L2.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
26 лайків
Нагородити
26
7
Поділіться
Прокоментувати
0/400
FreeRider
· 23год тому
Пробіжимо, потім поговоримо.
Переглянути оригіналвідповісти на0
AirdropHarvester
· 23год тому
Хто навчить мене, як зробити попереднє підтвердження rollup
Переглянути оригіналвідповісти на0
HypotheticalLiquidator
· 07-14 02:10
Грати в оптимізацію базових протоколів - це ризикувати системними ризиками.
Переглянути оригіналвідповісти на0
All-InQueen
· 07-12 17:57
Топ, не розумію, але спочатку кину грошей
Переглянути оригіналвідповісти на0
DegenWhisperer
· 07-12 17:53
Промчався і зник.
Переглянути оригіналвідповісти на0
AirdropHunterZhang
· 07-12 17:52
Попереднє підтвердження? Якщо немає аірдропу, не витрачайте час на ці всі красиві слова.
Ethereum прискорення підтвердження транзакцій Дослідження односекундної остаточності та попередніх підтверджень
Обговорення практичних рішень для покращення часу підтвердження транзакцій Ethereum
Важливим аспектом досвіду користувача блокчейну є час підтвердження транзакцій. У останні роки Ethereum досяг значних успіхів у цій сфері. Наразі транзакції, надіслані користувачами на L1, зазвичай можуть бути підтверджені за 5-20 секунд, що є порівнянним з досвідом оплати кредитною карткою. Однак подальше скорочення часу підтвердження все ще має значення, деяким додаткам навіть потрібна затримка в мілісекундах. У цій статті буде розглянуто деякі можливі варіанти Ethereum у цій сфері.
Огляд існуючих рішень
Однослотова остаточність
Наразі консенсус Gasper в Ethereum використовує архітектуру слотів та епох. Кожні 12 секунд відбувається слот, валідатори голосують за голову ланцюга, за 32 слоти (6.4 хвилини) всі валідатори мають можливість проголосувати один раз. Ці голосування інтерпретуються як повідомлення, подібні до алгоритму консенсусу PBFT, і через два епохи (12.8 хвилини) забезпечують остаточність з сильними економічними гарантіями.
Однак, цей метод має проблеми зі складністю та занадто довгим часом. Остаточність односекційного блоку (SSF) замінила цю архітектуру за допомогою механізму, подібного до Tendermint, що дозволяє остаточно підтвердити блок N до генерації блоку N+1. SSF зберігає механізм "неактивного витоку", що дозволяє ланцюгу продовжувати працювати, коли більше 1/3 валідаторів офлайн.
Основним викликом SSF є те, що кожен стейкер повинен надсилати два повідомлення кожні 12 секунд, що створює значне навантаження на ланцюг. Хоча існують деякі рішення для пом'якшення, такі як пропозиція Orbit SSF, користувачам все ще потрібно чекати 5-20 секунд.
Попереднє підтвердження Rollup
Ethereum використовує дорожню карту, зосереджену на rollup, де L1 забезпечує доступність даних та інші функції, а протокол L2 на цій основі надає користувачам більш масштабні послуги. Це призводить до розділення уваги: L1 зосереджується на антикорупційності, надійності та основних функціях, тоді як L2 безпосередньо відповідає на потреби користувачів.
Теоретично, L2 може створити свою власну мережу "децентралізованих сортувальників", яка підписує блоки кожні кілька сотень мілісекунд. Але це вимагає від L2 виконання майже такої ж роботи, як і при створенні нового L1, що призводить до повільного прогресу. Тому хтось запропонував, щоб всі L2 спільно використовували одну механіку попереднього підтвердження в межах Ethereum: базове попереднє підтвердження.
базова попередня підтвердження
Базове попереднє підтвердження використовує складність пропозиційника Ethereum, щоб мотивувати їх надання послуг попереднього підтвердження. Користувачі можуть сплачувати додаткову плату, щоб отримати негайну гарантію того, що транзакція буде включена в наступний блок. Якщо пропозиціонер порушить зобов'язання, він зазнає покарання. Ця механіка підходить не лише для L1 транзакцій, але й для L2 блоків на основі "rollups".
Можливі напрямки в майбутньому
Припустимо, реалізовано остаточність одного слота, використовуючи технології, подібні до Orbit, щоб зменшити кількість валідаторів, що підписують кожен слот, одночасно знижуючи поріг застави. Тривалість слота може зрости до 16 секунд, поєднуючи попереднє підтвердження rollup або базове попереднє підтвердження для надання користувачам швидшого підтвердження. Це фактично формує архітектуру epoch-slot.
Причина, чому така архітектура важко уникнути, полягає в тому, що досягнення приблизної згоди займає менше часу, ніж досягнення максимальної "економічної остаточності". Впливають фактори, такі як кількість вузлів та "якість" вузлів. Якщо ми можемо покладатися на спеціалізований підмнож вузлів для досягнення приблизного консенсусу, одночасно використовуючи повний набір валідаторів для визначення остаточності, можливо, ми зможемо знизити час підтвердження до близько 2 секунд.
Отже, дослідження простору дизайну архітектури epoch-slot з більшою роздільністю уваги є цінним.
Вибір стратегії L2
L2 наразі має три розумні стратегії:
Для деяких застосувань час блоку в 12 секунд є достатнім. Для інших застосувань єдиним рішенням є архітектура epoch-slot. Ключове питання полягає в тому, наскільки добре рідна архітектура epoch-slot Ethereum може впоратися з цим, що вплине на сенс інших рішень.
На даний момент ми ще далекі від остаточних відповідей на ці питання. Складність пропозицій блоків залишається невизначеною. Нові проекти, такі як Orbit SSF, надають простір для дослідження більшої кількості можливостей. Чим більше варіантів у нас є, тим краще ми можемо обслуговувати користувачів L1 та L2 та спростити роботу розробників L2.