Autor original |Vitalik

Compilare |. Odaily Planet Daily Nan Zhi

Unul dintre atributele importante ale unei bune experiențe de utilizator blockchain este timpul rapid de confirmare a tranzacției. Astăzi, Ethereum este mult îmbunătățit față de ceea ce era acum cinci ani. Datorită EIP-1559 și timpului de blocare stabil după trecerea la PoS (The Merge), tranzacțiile trimise de utilizatori pe L1 pot fi de obicei confirmate în 5-20 de secunde, ceea ce este aproximativ echivalent cu experiența de plată cu un card de credit. Cu toate acestea, este utilă îmbunătățirea în continuare a experienței utilizatorului, iar unele aplicații necesită chiar latențe de sute de milisecunde sau mai puțin. Acest articol va explora câteva opțiuni practice pentru îmbunătățirea timpilor de confirmare a tranzacțiilor în Ethereum.

Prezentare generală a ideilor și tehnicilor existente

finalitatea unui singur slot

În prezent, consensul Gasper de la Ethereum utilizează un singur slot (Slot) și arhitectura Epoch. La fiecare 12 secunde un slot, un subset de validatori votează pe capul lanțului și la fiecare 32 de sloturi (6,4 minute), toți validatorii au șansa de a vota o dată. Aceste voturi sunt apoi reinterpretate ca mesaje într-un algoritm de consens similar cu PBFT, oferind o garanție economică foarte puternică numită finalitate după două Epoci (12,8 minute).

În ultimii ani, am devenit din ce în ce mai nemulțumiți de abordarea noastră actuală. Există două motive principale pentru aceasta. În primul rând, această metodă este complicată și există multe erori de interacțiune între mecanismul de vot de la interval la interval și mecanismul de finalitate Epoch-to-Epoch să aștepte atât de mult.

Single Slot Finality (SSF) înlocuiește această arhitectură cu un mecanism similar cu consensul Tendermint, în care blocul N este finalizat înainte ca blocul N+1 să fie generat. Principala diferență cu Tendermint este că păstrăm mecanismul de „scurgere de inactivitate”, care permite lanțului să continue să ruleze și să se recupereze dacă mai mult de 1/3 dintre validatori sunt offline.

Principala provocare cu finalitatea cu un singur slot este că înseamnă că fiecare staker Ethereum trebuie să publice două mesaje la fiecare 12 secunde, ceea ce reprezintă o sarcină semnificativă pentru lanț. Există câteva idei inteligente pentru a atenua această problemă, inclusiv recenta propunere Orbit SSF. Deși acest lucru accelerează semnificativ „finalitatea” pentru a îmbunătăți experiența utilizatorului, nu schimbă faptul că utilizatorii trebuie să aștepte 5-20 de secunde.

Pre-confirmare acumulată

Ethereum a urmat o foaie de parcurs centrată pe rollup în ultimii ani, proiectând stratul de bază Ethereum (L1) pentru a sprijini disponibilitatea datelor și alte caracteristici, care sunt apoi puse la dispoziție pentru protocoalele L2, cum ar fi rollup-uri, validium și plasme oferi utilizatorilor același nivel de securitate ca Ethereum la o scară mai mare.

Acest lucru creează o separare a preocupărilor în cadrul ecosistemului Ethereum: Ethereum L1 se concentrează pe rezistența la cenzură, fiabilitatea, stabilitatea și menținerea și îmbunătățirea funcționalității de bază a unui anumit nivel de bază, în timp ce L2 se concentrează pe comunicarea mai directă prin diferite culturi și tehnologii către utilizatori. Dar dacă mergi pe această cale, apare o problemă inevitabilă: L2 dorește să ofere utilizatorilor confirmări mai rapide decât 5-20 de secunde.

Până acum, cel puțin în teorie, a fost responsabilitatea lui L2 să-și creeze propria rețea de „secvențiere descentralizate”. Un grup mic de validatori poate semna blocuri la fiecare câteva sute de milisecunde și își poate miza miza în spatele acelor blocuri. În cele din urmă, fișierele antet pentru aceste bucăți L2 sunt publicate în L1.

Dar setul de validare L2 poate comite „fraudă”: ei pot semna mai întâi blocul B1, apoi pot semna un bloc conflictual B2 și îl pot trimite în lanț înainte de B1. Dar dacă o fac, vor fi prinși și își vor pierde bunurile gajate. De fapt, am văzut exemple practice de versiuni centralizate, dar rollup-ul, pe de altă parte, a fost lent în dezvoltarea rețelelor de comandă descentralizate. Ați putea argumenta că este nedrept să cereți ca toate L2-urile să fie descentralizate: îi cerem rollup-ului să facă aproape aceeași treabă ca și crearea unui L1 complet nou. Ca atare, Justin Drake a promovat o modalitate pentru toate L2 (precum și L1) de a utiliza un mecanism de pre-confirmare partajat la nivelul întregului Ethereum: pre-confirmare de bază.

Pre-confirmare de bază

Abordarea preconfirmărilor bazate presupune că cei care propun Ethereum sunt participanți extrem de sofisticați asociați cu MEV. Abordările bazate pe preconfirmare exploatează această complexitate prin stimularea acestor propuneri complexi să accepte responsabilitatea furnizării serviciilor de preconfirmare.

Ideea de bază a acestei abordări este de a crea un protocol standardizat în care utilizatorii pot oferi o garanție imediată că o tranzacție va fi inclusă în următorul bloc pentru o taxă suplimentară, precum și o creanță asupra rezultatelor executării respectivei tranzacții. Dacă un solicitant încalcă orice promisiune făcută oricărui utilizator, acesta poate fi tăiat.

După cum sa menționat, tranzacțiile L1 sunt garantate pe baza confirmării prealabile. Dacă rollup-urile sunt „bazate”, atunci toate blocurile L2 sunt tranzacții L1, astfel încât același mecanism poate fi folosit pentru a oferi pre-confirmare pentru orice L2.

La ce ne uităm de fapt?

Să presupunem că atingem finalitatea cu un singur slot. Folosim tehnologie similară cu Orbit pentru a reduce numărul de validatori care semnează pe slot, dar nu prea mult, astfel încât să putem face progrese și în ceea ce privește obiectivul cheie de a reduce minimul de miză de 32 ETH. Intervalul de timp poate fi mărit la 16 secunde, iar apoi folosim pre-confirmarea cumulativă sau pre-confirmarea de bază pentru a oferi utilizatorilor o confirmare mai rapidă. Ce am obținut până la urmă: o arhitectură de epocă-slot.

Există un motiv filozofic profund pentru care arhitectura de epocă și slot pare atât de greu de evitat: este nevoie de mai puțin timp pentru a ajunge la un acord aproximativ asupra unui lucru decât pentru a ajunge la un acord asupra unui lucru cu cel mai mare grad de „finalitate economică” .

Un motiv simplu este numărul de noduri. În timp ce vechiul compromis de descentralizare liniară/timpul de finalitate/supraveghere pare acum ușor datorită agregării BLS ultra-optimizate și viitoarelor ZK-STARK, următoarele motive nu pot fi ignorate:

  • „Consensul aproximativ” necesită doar un număr mic de noduri, în timp ce finalitatea economică necesită o mare majoritate de noduri.

  • Odată ce numărul de noduri depășește o anumită dimensiune, trebuie să petreceți mai mult timp colectând semnături.

În Ethereum de astăzi, slotul de 12 secunde este împărțit în trei sub-sloturi: publicare și distribuire în bloc, atestare și agregare de atestare. Dacă numărul de probe este redus semnificativ, putem reduce la două subsloturi și putem folosi intervalul de timp de 8 secunde. Un alt factor, mai realist și mai mare, este „calitatea” nodului. Un alt factor mai mare este „calitatea” nodului. Dacă ne-am putea baza și pe un subset specializat de noduri pentru a ajunge la un acord aproximativ (și să folosim totuși setul complet de validatori pentru a determina finalitatea), am putea reduce acest lucru la ~2 secunde.

Deci, în opinia mea, arhitectura epoch-and-slot este în mod clar corectă, dar nu toate arhitecturile epoch-and-slot sunt create egale și există valoare în explorarea mai completă a spațiului de proiectare. O direcție demnă de cercetări ulterioare nu este la fel de strâns cuplată ca în Gasper, ci cu o separare mai puternică a preocupărilor între cele două mecanisme.

Ce ar trebui să facă L2?

În opinia mea, L2 are în prezent trei strategii rezonabile:

  • Atât tehnic, cât și spiritual „bazat”. Adică, ele optimizează proprietățile tehnice ale stratului de bază al lui Ethereum și valorile acestuia (descentralizare ridicată, rezistență la cenzură etc.). În forma lor cea mai simplă, puteți considera aceste pachete ca „cioburi de marcă”, dar pot fi, de asemenea, mult mai ambițioase, experimentând intens cu noi design-uri VM și alte îmbunătățiri tehnice.

  • Deveniți un „server cu schele blockchain” și profitați la maximum de el. Dacă începeți cu un server și apoi adăugați dovezi de valabilitate STARK pentru a vă asigura că serverul respectă regulile pentru a asigura dreptul utilizatorilor de a retrage sau de a forța tranzacțiile și libertatea de alegere, fie prin retragere în masă coordonată, fie prin schimbarea ordonatorului; votează, atunci ai. Obține cele mai multe dintre beneficiile uplink-ului, păstrând în același timp cea mai mare parte a eficienței serverului.

  • Calea de mijloc: un lanț rapid cu o sută de noduri, Ethereum oferă un plus de interoperabilitate și securitate. Aceasta este foaia de parcurs actuală de facto pentru multe proiecte L2.

Pentru unele aplicații (de exemplu, ENS, stocarea cheilor, unele protocoale de plată), un timp de blocare de 12 secunde este suficient. Pentru acele aplicații în care acest lucru nu este aplicabil, singura soluție este o arhitectură epoch-and-slot. În trei cazuri, „epoca” este SSF-ul Ethereum, dar slotul este diferit în fiecare dintre cele trei cazuri de mai sus:

  • O arhitectură de epocă și slot nativă Ethereum

  • Pre-confirmare server

  • preconfirmarea comisiei

O întrebare cheie este, cât de buni putem fi în Categoria 1? În special, dacă devine foarte bine, se simte că Categoria 3 nu va însemna atât de mult. Deoarece toate soluțiile „bazate” nu funcționează cu date L2 în afara lanțului, cum ar fi plasme și validium, categoria 2 va exista întotdeauna. Dacă o arhitectură de epocă și slot nativă Ethereum poate fi redusă la 1 secundă, atunci spațiul pentru Categoria 3 va deveni mult mai mic.

Astăzi, suntem departe de răspunsurile finale la aceste întrebări. O întrebare cheie este cât de complexi vor deveni propușitorii de blocuri, care rămâne o zonă de incertitudine considerabilă. Modelele precum Orbit SSF sunt foarte noi, așa că spațiul de proiectare al schemelor, cum ar fi utilizarea Orbit SSF ca o epocă în epoch-and-slot, este încă demn de explorare completă. Cu cât avem mai multe opțiuni, cu atât putem face mai bine pentru utilizatorii L1 și L2 și putem face viața mai ușoară dezvoltatorilor L2.