Co-fondatorul Ethereum, Vitalik Buterin, a prezentat pe 6 septembrie un model de tranzacție pe termen lung care ar putea permite rețelei să proceseze o parte din munca de validare în paralel.
Propunerea sa separă efectele produse de tranzacții de condițiile care trebuie îndeplinite înainte ca acele efecte să poată avea loc.
Buterin a descris cele două componente ca „acțiuni” și „dependențe” într-o postare detaliată. Acțiunile modifică starea Ethereum, cum ar fi transferul de ETH sau apelarea unui contract. Dependențele acoperă informațiile necesare pentru a stabili că o tranzacție este validă.
O semnătură digitală este un exemplu de dependență. Alte exemple includ dovezi Merkle care arată că există o ieșire nespenduită, dovezi cu cunoștință zero și condiții de stare care trebuie să rămână adevărate atunci când o tranzacție intră într-un bloc.
Buterin a susținut că explicitarea acestei distincții ar putea ajuta Ethereum să se scaleze fără a-și abandona mediul de execuție flexibil. Cu toate acestea, propunerea rămâne parte a cercetării continue a protocolului. Dezvoltatorii Ethereum nu au aprobat designul complet pentru implementare.
Tranzacțiile Ethereum combină în prezent autorizarea, plata taxelor și execuția într-un flux comun de procesare. Nodurile verifică dacă o tranzacție este semnată corect, dacă expeditorul o poate plăti și dacă instrucțiunile sale se execută cu succes.
Unele dintre aceste verificări nu depind de modificările finale de stare ale tranzacției. Buterin a spus că astfel de dependențe ar putea fi procesate separat și, în multe cazuri, simultan.
De exemplu, un validator ar putea avea nevoie să confirme o semnătură înainte de a accepta o tranzacție. Acea verificare nu trebuie neapărat să aștepte semnături necorelate atașate altor tranzacții. Dacă mai multe verificări independente sunt cunoscute în avans, clienții pot distribui munca pe resursele de procesare disponibile.
Verificările dependente de stare necesită o atenție sporită. O condiție legată de un sold de cont sau de un slot de stocare poate deveni invalidă dacă o tranzacție anterioară modifică aceeași stare. Buterin a spus că mempool-urile ar putea raționa mai eficient aceste condiții atunci când tranzacțiile declară ce părți ale stării accesează.
Abordarea ar recompensa tranzacțiile previzibile. Operațiunile care își specifică clar dependențele ar putea primi costuri de gaz mai mici, deoarece clienții le-ar putea verifica mai eficient. Tranzacțiile care necesită apeluri dinamice și acces imprevizibil la stare ar rămâne posibile, dar ar putea costa mai mult.
Buterin a estimat că peste 90% din activitatea Ethereum în volum nu necesită nivelul complet de flexibilitate dinamică al rețelei. Această cifră este evaluarea sa, mai degrabă decât o măsurătoare de rețea publicată în cadrul postării. Argumentul mai larg este că transferurile comune și interacțiunile contractuale de rutină ar putea utiliza formate mai restrictive fără a limita aplicațiile specializate.
Modelul propus ar păstra sistemul flexibil de conturi al Ethereum pentru tranzacțiile care au nevoie de el. Activitatea mai previzibilă ar putea utiliza structuri analizabile static, asemănătoare cu părți din modelul de tranzacție al Bitcoin.
Bitcoin utilizează un model de ieșire a tranzacțiilor nespenduite (UTXO) în care o tranzacție identifică ieșirile pe care intenționează să le cheltuiască. Ethereum utilizează în mod normal conturi cu solduri, nonces și stocare programabilă de contracte. Buterin nu propune ca Ethereum să-și înlocuiască modelul de conturi cu arhitectura Bitcoin. El a descris un spectru care combină idei din ambele sisteme.
EIP-8141 este o propunere de îmbunătățire Ethereum (EIP) în stadiu de proiect pentru un nou tip de tranzacție cunoscut sub numele de Tranzacție Cadru (Frame Transaction). Acesta împarte o tranzacție în cadre de apel de contract care pot valida autoritatea, aproba plata gazului și efectua operațiuni ale utilizatorului.
Propunerea oficială spune că validitatea tranzacției și plata taxelor nu ar mai depinde exclusiv de o semnătură standard atașată tranzacției exterioare. Codul contului ar putea defini în schimb regulile necesare de autorizare și plată.
Tranzacțiile Cadru ar putea suporta taxe sponsorizate, plăți în tokenuri diferite de ETH, rotația cheilor și gruparea tranzacțiilor (batching). Acestea ar putea permite, de asemenea, conturilor deținute extern (EOA) să primească funcționalități de abstracție a contului fără a se baza pe aceeași implementare de contract în fiecare rețea compatibilă.
Conform structurii propuse, cadrele de verificare ar determina dacă expeditorul a autorizat tranzacția. Cadre separate ar putea stabili cine plătește taxele și apoi ar executa operațiunile solicitate.
Această structură se aliniază cu diviziunea lui Buterin între dependențe și acțiuni. Cadrele de verificare gestionează condițiile care trebuie îndeplinite. Cadrele expeditorului gestionează operațiunile care modifică starea.
Formatul ar putea, de asemenea, îmbunătăți interoperabilitatea între rețelele Ethereum Virtual Machine. Diferite lanțuri ar putea suporta aceeași structură minimă de tranzacție, aplicând în același timp propriile instrumente de verificare, precompilări sau funcționalități de cont.
Buterin a descris formatul potențial ca o listă de bază de apeluri cu flag-uri care identifică funcția acestora. Un apel ar putea fi marcat ca o dependență pură, o verificare dependentă de stare sau o acțiune. Tranzacția ar conține, de asemenea, informații standard, cum ar fi originea și nonce-ul său.
EIP-8141 rămâne clasificată ca o propunere Core în stadiu de proiect. Specificația sa actuală include reguli detaliate pentru admiterea în mempool, execuția cadrelor, chitanțe, semnături, contabilitatea gazului și propagarea tranzacțiilor. Aceste detalii se pot modifica în timpul revizuirii.
Dezvoltatorii Ethereum au dezbătut, de asemenea, preocupări tehnice. Acestea includ riscuri de atac de tip denial-of-service (DoS), reguli de înlocuire a tranzacțiilor, modificări ale uneltelor (tooling), limite pentru tranzacțiile în așteptare și restricții impuse cadrelor de verificare.
O discuție a remarcat că mempool-ul public propus ar păstra în mod normal doar o singură Tranzacție Cadru în așteptare pentru fiecare expeditor. Dezvoltatorii au pus la îndoială cum ar afecta această regulă conturile care trimit în mod regulat mai multe tranzacții într-un singur bloc.
Alți participanți au examinat dacă formatul introduce complexitate suplimentară pentru portofele, constructori de blocuri și interfețele de apel de procedură la distanță (RPC) ale Ethereum. Aceste întrebări trebuie rezolvate înainte ca echipele de clienți să poată implementa o specificație stabilă.
Modelul pe termen lung al lui Buterin merge dincolo de EIP-8141. El a sugerat că dependențele care nu necesită acces la stare ar putea fi verificate o singură dată la nivelul mempool-ului, în loc să fie repetate de fiecare validator.
O dependență pură ar putea include o semnătură sau dovadă criptografică a cărei validitate nu se modifică odată cu starea Ethereum. După verificare, rețeaua ar putea înlocui mai multe bucăți de muncă de verificare cu un STARK recursiv care confirmă că toate verificările au fost finalizate corect.
Un STARK este o dovadă criptografică care permite unei părți să demonstreze că un calcul a fost efectuat corect. Dovezile recursive pot verifica alte dovezi, făcând posibilă combinarea multor verificări într-o sarcină de verificare mai mică.
Mempool-ul propus ar putea agrega semnăturile tranzacțiilor, dovezile de validitate și alte dependențe înainte de execuția blocului. Validatorii ar verifica apoi dovada agregată în loc să repete independent fiecare calcul original.
Buterin a sugerat că această abordare ar putea, de asemenea, reduce cantitatea de date de verificare plasate pe lanț. Dacă dovada recursivă stabilește că toate dependențele au fost valide, o parte din datele originale ar putea fi potențial omise.
Acest rezultat nu face parte din specificația actuală EIP-8141. Ar necesita cercetări suplimentare care să acopere generarea dovezilor, coordonarea mempool-ului, disponibilitatea datelor și protecțiile împotriva agregării invalide.
Designul se referă, de asemenea, la pregătirea Ethereum pentru criptografia post-cuantică. Semnăturile rezistente la atacuri cuantice sunt în general mai mari și mai costisitoare de verificat decât semnăturile ECDSA utilizate de conturile Ethereum obișnuite.
EIP-8141 ar putea permite conturilor să definească noi scheme de autorizare fără a aștepta ca Ethereum să înlocuiască un singur standard fix de semnătură. Agregarea recursivă a dovezilor ar putea reduce apoi costul verificării semnăturilor post-cuantice mari.
EIP-8141 ar putea ajuta conturile Ethereum să adopte autorizarea post-cuantică dacă sistemele practice de semnătură devin disponibile. Aceasta rămâne o cale de securitate pe termen lung, mai degrabă decât un răspuns imediat la o amenințare cuantică activă.
Conturile Ethereum utilizează nonces secvențiale pentru a preveni reluarea tranzacțiilor (replay). Dacă un cont trimite tranzacțiile numerotate 10, 11 și 12, rețeaua le procesează în mod normal în acea ordine.
Secvența poate crea un blocaj. Dacă tranzacția 10 se blochează sau devine invalidă, tranzacțiile ulterioare din același cont pot, de asemenea, să aștepte, chiar și atunci când operațiunile lor sunt necorelate.
Nonces cu cheie ar oferi unui cont mai multe secvențe independente de nonce. Tranzacțiile atribuite unor chei diferite ar putea continua fără să aștepte ca o altă secvență să avanseze.
Acest lucru ar putea ajuta conturile inteligente, sistemele de confidențialitate și aplicațiile care trimit simultan mai multe operațiuni independente. Fiecare flux de lucru ar putea primi propriul domeniu de nonce, păstrând în același timp protecția împotriva reluării.
Crypto.news a raportat anterior că nonces cu cheie ar putea preveni blocarea reciprocă a tranzacțiilor private independente. Funcționalitatea face parte dintr-un efort mai amplu de a îmbunătăți tranzacțiile private, conturile flexibile și rezistența la cenzură.
Buterin a conectat, de asemenea, munca legată de tranzacții cu modele de stare alternative, inclusiv designuri UTXO native și structuri de stare bazate pe dovezi. Aceste proiecte explorează dacă anumite active sau operațiuni pot utiliza reguli de stare previzibile, în timp ce contractele complexe își păstrează flexibilitatea existentă a Ethereum.
Abordarea ar putea crea mai multe niveluri de procesare. Operațiunile simple, declarate, ar fi mai ușor de analizat și ar putea primi taxe mai mici. Apelurile dinamice de contract ar continua să funcționeze, dar ar consuma mai multe resurse, deoarece clienții nu le pot pregăti execuția în același mod.
Astfel de prețuri diferențiate ar încerca să alinieze taxele cu constrângerile reale de scalare create de fiecare tranzacție. Nu ar garanta taxe mai mici pentru fiecare utilizator sau aplicație.
EIP-8141 trebuie să treacă prin mai multe etape înainte de a putea afecta utilizatorii Ethereum. Dezvoltatorii Core trebuie mai întâi să fie de acord că Tranzacțiile Cadru oferă o cale mai bună decât designurile concurente de abstracție a contului.
Propunerea ar necesita apoi implementări de client, rețele de dezvoltare, testare de interoperabilitate, suport pentru portofele și revizuire de securitate. Dezvoltatorii ar trebui, de asemenea, să testeze cum interacționează Tranzacțiile Cadru cu constructorii de blocuri, mempool-urile, piețele de taxe și contractele inteligente existente.
Discuțiile anterioare ale dezvoltatorilor au luat în considerare EIP-8141 pentru viitorul upgrade Hegotá al Ethereum. Cu toate acestea, crypto.news a raportat că Tranzacțiile Cadru rămân în considerare, mai degrabă decât să fie programate formal.
FOCIL, o propunere separată menită să îmbunătățească rezistența la cenzură prin liste de includere a tranzacțiilor, a fost, de asemenea, discutată alături de EIP-8141. Cele două propuneri abordează probleme diferite. Tranzacțiile Cadru privesc autorizarea și structura de execuție, în timp ce FOCIL privește includerea tranzacțiilor eligibile în blocuri.
Dezvoltatorii au susținut că utilizarea lor împreună ar putea oferi abstracție nativă a contului cu o rezistență mai puternică la cenzură. Această combinație este încă un pachet propus, nu un angajament aprobat în foaia de parcurs Ethereum.
Comentariile lui Buterin din 6 septembrie descriu, prin urmare, o direcție posibilă pentru designul tranzacțiilor Ethereum. Ele nu anunță un upgrade finalizat, o dată de activare sau o modificare confirmată a taxelor de gaz din mainnet.
Următoarele etape verificabile ar fi suportul formal al dezvoltatorilor, includerea într-un scop de upgrade și implementări funcționale pe rețelele de dezvoltare. Până atunci, EIP-8141 și mempool-urile STARK recursive rămân propuneri active de cercetare și inginerie.
EIP-8141 propune Tranzacții Cadru care împart validarea, aprobarea taxelor și execuția în cadre separate de apel de contract.
Este în prezent o propunere Core în stadiu de proiect. Dezvoltatorii Ethereum pot încă modifica sau respinge specificația sa.
O acțiune modifică starea Ethereum, cum ar fi trimiterea de ETH sau apelarea unui contract. O dependență este o condiție care trebuie să fie validă, cum ar fi o semnătură sau o dovadă de stare.
Separarea lor ar putea permite ca dependențele independente să fie procesate simultan înainte ca operațiunile care modifică starea să fie executate.
Ar putea face tranzacțiile previzibile mai ieftine de procesat dacă dezvoltatorii adoptă un preț al gazului care recompensează operațiunile analizabile static.
Nicio reducere a taxelor nu este confirmată. Costurile ar depinde de specificația finală, implementarea clientului și deciziile viitoare de upgrade.
ETH