Vitalik пропонує нові правила з 12-секундною незворотністю транзакцій, низьколатентна мережа забезпечує потужний захист

Співзасновник Ethereum Віталік Бутерін 18 березня опублікував статтю, в якій представив новий механізм швидкого підтвердження транзакцій в Ethereum. Згідно з цим пропозицією, користувачі отримують тверду гарантію, що транзакції в Ethereum не будуть скасовані протягом одного часового слоту (12 секунд). Віталік зазначив, що безпека цього механізму залежить від двох передумов: переважна більшість валідаторів у мережі залишаються чесними та мережеві затримки не перевищують приблизно 3 секунди.

Основний принцип механізму швидкого підтвердження

Поточний механізм фіналізації в Ethereum (економічна фіналізація) вимагає очікування двох епох, тобто приблизно 6,4 хвилини, щоб забезпечити незворотність транзакцій, захищену криптографією та економічними стимулами. Це створює суттєві перешкоди для застосувань, що потребують миттєвого підтвердження — таких як платіжні термінали, виконання ордерів на децентралізованих біржах та онлайнова розрахункова обробка у роздрібній торгівлі.

Віталік пропонує механізм швидкого підтвердження, щоб заповнити «прогалину безпеки» між «запакуванням транзакції у блок» та «отриманням повної фіналізації»:

Час підтвердження: один часовий слот (12 секунд), без необхідності чекати завершення епохи

Перша передумова безпеки: більшість валідаторів у мережі чесно працюють, відсутні зловмисники, які спільно зривають поширення транзакцій

Друга передумова безпеки: мережеві затримки не перевищують приблизно 3 секунди, що забезпечує поширення повідомлень до кінця слоту до його завершення

Рівень безпеки: нижчий за повну «економічну фіналізацію», але при виконанні двох вищезазначених передумов ймовірність скасування транзакції є дуже низькою

Головна ідея Віталіка полягає в тому, що в реальності більшість часу мережа Ethereum відповідає цим двом умовам, тому для практичних застосувань ця «слабка фіналізація» є цілком надійною та значно швидшою за очікування повної підтвердження.

Порівняння з існуючими механізмами підтвердження в Ethereum

Поточний механізм підтвердження в Ethereum має кілька рівнів, розуміння яких допомагає оцінити значущість нової пропозиції:

Транзакція запакована (близько 12 секунд): транзакція потрапляє у найновіший блок, але теоретично ще може бути перероблена (наприклад, під час мережевих атак або у крайніх випадках)

Після підтвердження блоку — певна глибина: з додаванням нових блоків ризик скасування транзакції зменшується, але до досягнення повної фіналізації вона ще не є математично незмінною

Повна фіналізація (~6,4 хвилини): через дві епохи транзакція отримує криптографічний захист фіналізації, і будь-який зловмисник має знищити щонайменше 1/3 ETH у стейкінгу, щоб скасувати її

Новий механізм швидкого підтвердження вводить між першим і другим рівнями «м’який, але довірений» рівень незворотності, скорочуючи час підтвердження з 6,4 хвилин до 12 секунд, за рахунок залежності від чесності мережі, а не лише криптографічних гарантій.

Поширені питання

Чи достатньо надійна передумова «більшість валідаторів чесні»?

У більшості випадків у мережі Ethereum ця умова виконується. Механізм PoS передбачає суворі штрафи (slashing), що карають зловмисників великими втратами ETH, стимулюючи чесну поведінку. Однак у разі цілеспрямованих атак 51% або масштабної згоди валідаторів ця передумова може порушитися — саме тому Віталік називає цей механізм «менш безпечним за повну фіналізацію».

Чи реалістично у глобальному масштабі забезпечити затримки менше 3 секунд?

Ethereum має широку мережу валідаторів по всьому світу, і одним із її цілей є швидке поширення повідомлень у межах слоту. Затримки у 3 секунди цілком досяжні для добре підключених вузлів, але для дуже віддалених або погано з’єднаних — це може бути викликом. Це означає, що цей механізм орієнтований на сценарії з хорошим інтернет-з’єднанням.

Чи потрібно для цього хард-форк у протоколі Ethereum?

На даний момент Віталік пропонує технічну ідею, яка ще не проходила офіційний процес внесення до EIP (Ethereum Improvement Proposal). Реалізація може вимагати оновлення клієнтського програмного забезпечення або ж може бути застосована на рівні додатків у рамках існуючого протоколу без повного хард-форку. Технічний шлях ще обговорюється розробниками.