EIP-7623: Propunerea care va reevalua prețul Calldata pentru tranzacțiile Ethereum

Tranzacțiile blockchain consumă CPU, memorie, stocare și alte resurse atunci când sunt propagate, executate între noduri și stocate. Prin urmare, stabilirea corectă a prețurilor tranzacțiilor este esențială pentru a preveni abuzul în rețea și pentru a obține o utilizare eficientă a resurselor.

Cu toate acestea, determinarea prețului adecvat pentru tranzacții a fost o provocare de lungă durată în proiectarea protocolului blockchain. Vitalik Buterin, fondatorul Ethereum, abordează această problemă într-un document vechi de cercetare :

Una dintre cele mai provocatoare probleme în proiectarea protocolului blockchain este modul în care se limitează și se stabilește prețul transmiterii tranzacțiilor care sunt incluse în lanț.” — Vitalik Buterin

EIP-7623 este o propunere de îmbunătățire a Ethereum (EIP) care își propune să modifice prețul datelor de apel pentru a limita dimensiunea maximă a blocului. Spre deosebire de propunerile anterioare care doar au crescut costul datelor de apel, EIP-7623 se concentrează pe minimizarea impactului său asupra tranzacțiilor zilnice ale utilizatorilor, obținând în același timp o utilizare eficientă a resurselor.

În acest articol, explicăm rațiunea pentru reprecierea datelor de apel utilizate de tranzacțiile pe Ethereum Layer 1 (L1) și impactul asupra dimensiunilor blocurilor și a performanței rețelei. De asemenea, stabilim contextul pentru modificările propuse la mecanismul taxei de tranzacție Ethereum, bazându-ne pe ani de cercetare în problema stabilirii prețurilor eficiente a resurselor blockchain.

Să ne scufundăm!

Stabilirea scenei: de ce este atât de dificil să stabiliți un preț corect al tranzacțiilor?

Stabilirea prețurilor tranzacțiilor blockchain este dificilă, deoarece estimarea cantității exacte a fiecărei resurse pe care o consumă fiecare tranzacție este în mod inerent complexă. În prezent, în Ethereum, toate resursele sunt reprezentate ca unități unificate numite „gaz” și „gaz blob” (introdus cu EIP-4844 ).

Există reguli predefinite care convertesc consumul de resurse de tranzacție în gaz, iar aceste reguli sunt actualizate periodic. Exemple de aceste reguli includ:

• O tranzacție care implică o taxă generală fixă de cel puțin 21.000 de gaze, în principal pentru verificarea semnăturii

• Consum de gaz predefinit pentru fiecare opcode EVM

  
  

În plus, consumul de gaz pentru calldata este o parte integrantă a acestor reguli, care este mai puțin cunoscut, dar foarte semnificativ. Tarifarea Calldata este crucială, deoarece influențează direct dimensiunea maximă a blocului. În plus, afectează toate tranzacțiile care utilizează contracte inteligente, afectând în special costul tranzacțiilor cumulate care depind de spațiul de date apel – mai degrabă decât de blobs – pentru disponibilitatea datelor .

De ce contează dimensiunea blocului?

Ethereum funcționează în intervale de 12 secunde, timp în care toate nodurile validatoare trebuie să propage blocuri și blob-uri, să execute și să valideze tranzacțiile și să ateste noul bloc. Mai exact, implementarea clientului Ethereum necesită noduri sincere pentru a primi și valida blocurile în primele 4 secunde ale slotului. Ei atestă la 4 secunde în slot, ceea ce înseamnă că blocurile care sosesc după 4 secunde nu vor primi atestări și sunt susceptibile de a fi reorganizate de următorul proponent .

Pentru a minimiza vizualizările împărțite între nodurile Ethereum, timpul de execuție a blocului și timpul de propagare trebuie să fie limitate. Ethereum limitează timpul de execuție a blocului prin stabilirea unui consum maxim de gaz, plafonat în prezent la 30 de milioane cu o țintă de 15 milioane . Aceasta înseamnă că blocurile Ethereum vor folosi în medie ~ 15 milioane de gaz, cu capacitatea de a se extinde și de a consuma 30 de milioane de gaz în perioadele de activitate ridicată.

De asemenea, fiecare cod operațional EVM are un cost de gaz predeterminat pe baza consumului de resurse. De exemplu, codul operațional SSTORE este mai costisitor decât operațiunile mai simple (de exemplu, adăugarea aritmetică - ADD) deoarece implică accesarea și modificarea procesului de stare. Această stabilire a prețurilor diferențiate pentru codurile operaționale EVM, împreună cu limita totală a gazului, a urmărit să restrângă timpul total de execuție.

În timp ce limita de gaz a unui bloc poate constrânge oarecum timpul de execuție a blocului, timpul de propagare a blocului rămâne neconstrâns în mod explicit. Dimensiunea blocului este un factor major care afectează timpul de propagare în blockchain-urile publice. De exemplu, blocurile de dimensiuni mai mari cresc încărcarea rețelei și cerințele de lățime de bandă; dacă dimensiunea blocului depășește cu mult lățimea de bandă a majorității nodurilor, este nevoie de mai mult pentru ca nodurile să se propagă complet și să primească blocul - crescând riscul de pierdere sau reorganizare a blocurilor. (De aceea protocolul Bitcoin (pre- Segwit ) avea o limită de dimensiunea blocului de 1 MB pentru a preveni creșterea ratelor de furcă și pentru a asigura securitatea și cerințele scăzute ale nodurilor blockchain.)

În prezent, Ethereum, nu există o limită de dimensiune a blocului stabilită în mod explicit. Cu toate acestea, dimensiunea maximă teoretică a blocului poate fi estimată luând în considerare limita de gaz, costul datelor de apel, rata de compresie etc. Deși dimensiunea actuală a blocului Ethereum este de ~2,78 MB (excluzând blob-urile), prețul curent pentru datele de apel permite încărcături EL de până la 7,15 MB, în timp ce dimensiunea medie este mult mai mică, în jur de 100 KB.

Dacă încărcăturile utile atât de mari ar fi propagate în mod constant pe parcursul a 10 minute, ar putea ajunge la aproximativ 42,9 MB, ceea ce este semnificativ mai mare decât dimensiunile tipice ale blocurilor din alte rețele blockchain.

Acest lucru ar putea supraîncărca rețeaua Ethereum și ar putea face ca nodurile să aibă vederi diferite pentru o perioadă scurtă de timp într-un scenariu de atac DoS în care încărcăturile utile de 7,15 MB continuă pentru o perioadă.

În practică, dimensiunea medie a blocului în Ethereum astăzi este de aproximativ 125 KB, indicând un decalaj semnificativ față de dimensiunea maximă a blocului. Acest lucru ridică o altă îngrijorare cu privire la ineficiența utilizării resurselor. De exemplu, dacă rețeaua poate gestiona suficient blocuri de 1 MB la rând, o discrepanță mare între dimensiunea medie a blocului și 1 MB sugerează că Ethereum are mai multă capacitate pentru funcționalitatea Data Availability (DA), dar nu o folosește eficient.

Limitând dimensiunea maximă a blocului și aliniind dimensiunea medie a blocului mai aproape de acest maxim, Ethereum ar putea reduce riscurile de consens, obținând în același timp o utilizare mai eficientă a resurselor. Acesta este motivul pentru care EIP-7623 se concentrează pe dimensiunea maximă posibilă a blocului, care este foarte afectată de prețul calldata.

Ce este Calldata în Ethereum?

Calldata este un câmp dintr-o tranzacție folosit de obicei pentru a transmite ce funcții să apeleze și ce parametri să treacă. De exemplu, dacă doriți să bateți un NFT, includeți metoda „mint” și trăsăturile specifice ale NFT în câmpul calldata. Următorul exemplu arată prima tranzacție menită a unui CryptoPunk în 2017.

Datele de apel (denumite „date de intrare” în figură) conțin numele funcției getPunk , reprezentat de 0xc81d1d5b, și indexul NFT, reprezentat de 0x00001eb0 (7856 în hexazecimal). Dacă transferați doar ETH și nu interacționați cu niciun contract inteligent, câmpul calldata este nul ( 0x ).

Pe lângă scopul său principal de a transmite parametri la contractele inteligente, calldata este folosită și pentru înregistrarea de notificări simple sau prin pachete care stochează datele tranzacțiilor. Cu alte cuvinte, calldata nu trebuie întotdeauna să interacționeze cu contractele inteligente sau să urmeze reguli stricte; poate conţine valori arbitrare.

Folosind această flexibilitate, pachete optimiste , cum ar fi Optimism și Arbitrum, unele pachete ZK (validitate), date despre tranzacții cumulate post-comprimate și stări actualizate în câmpul calldata al tranzacțiilor lor de secvențiere. Deși EIP-4844 a permis disponibilitatea datelor prin blob-uri în loc de calldata, calldata este încă preferată de pachetele mici care nu au nevoie de cei 128 KB complet ai unui blob pentru un singur lot.

Calldata este adesea folosită pentru funcționalitatea DA, deoarece este cel mai puțin consumator de gaz pentru a posta date mari pe EVM. Acesta este motivul pentru care dimensiunea maximă a blocului este constrânsă de prețul calldata. Cel mai rău scenariu apare atunci când un bloc este umplut cu tranzacții cu scop DA care utilizează cantități mici de gaz, dar dimensiuni mari de date.

În prezent, costul calldata este de 4 gaz pe zero octeți și 16 gaz pe octet diferit de zero. Datele de apel pot fi comprimate folosind compresia rapidă ( EIP-706 ), iar dimensiunea tranzacției nu poate depăși 125 KB. Calculul precis al dimensiunii maxime a blocului este complex datorită naturii variate a rapoartelor de compresie, dar se știe că blocul poate crește până la ~2,78 MB.

Dacă blocurile de 2,78 MB continuă consecutiv din anumite motive (de exemplu, atacuri de spam), rețeaua ar putea fi supraîncărcată, iar nodurile ar putea avea vederi divizate din cauza vitezei scăzute de propagare. Mai multe noduri ar putea atesta blocuri diferite ca lanțul canonic, crescând riscul de a nu ajunge la un consens. Pentru a preveni acest lucru, o soluție simplă ar putea fi creșterea costului datelor de apel - de exemplu, dublarea costului datelor de apel la 8 gaz pe zero octeți și 32 de gaze pe octet diferit de zero ar putea reduce aproximativ dimensiunea maximă a blocului la jumătate.

Cu toate acestea, această abordare ar putea dăuna tranzacțiilor normale ale utilizatorilor. Creșterea costurilor cu datele de apel doar pentru a preveni cel mai rău scenariu ar putea duce la o pierdere mai mare decât un câștig, având în vedere că dimensiunea medie a blocului este în prezent de doar 125 KB și nu ridică preocupări semnificative.

Care este motivația pentru EIP-7623?

EIP-7623 diferă ușor de alte propuneri care pur și simplu măresc costul datelor de apel. În loc de o ajustare generală a prețului datelor de apel, EIP-7623 se concentrează pe creșterea costului gazului, în special pentru tranzacțiile care par să servească în scopuri de disponibilitate a datelor (DA).

Ce înseamnă acest lucru? Dacă gazul utilizat într-o tranzacție este insuficient în comparație cu dimensiunea totală a datelor încărcate, este considerată o tranzacție cu scop DA și se percepe mult mai mult pentru calldata. În schimb, dacă o tranzacție consumă suficient gaz în raport cu dimensiunea datelor, este considerată o tranzacție non-DA și este taxată la fel ca în prezent.

O analogie utilă poate fi făcută între calldata din Ethereum și pungile de plastic din lumea reală. Când cumpărăm produse sau produse alimentare, primim adesea pungi de plastic pentru a le transporta, de obicei la un cost foarte mic sau chiar gratuit. Cu toate acestea, dacă persoanele fizice pot cumpăra un număr nelimitat de pungi de plastic, ar fi dăunător mediului.

O posibilă soluție este de a restricționa pungile de plastic la clienții care cumpără suficiente produse sau percep un preț mai mare, cum ar fi 1 USD per pungă. Aceasta este analogă cu abordarea EIP-7623, care funcționează ca o formă de impozit Pigouvian. Impune costuri mai mari tranzacțiilor care utilizează o cantitate mare de date de apel, dar gaz insuficient, promovând astfel o utilizare mai eficientă a resurselor. Aplicând costuri mai agresive celor care folosesc în primul rând calldata pentru disponibilitatea datelor, mai degrabă decât un amestec echilibrat de date și execuție, protocolul își propune să asigure o utilizare mai eficientă și mai durabilă a resurselor rețelei.

De ce vizați tranzacțiile DA pe Ethereum?

Nu este nimic inerent greșit în tranzacțiile care utilizează Ethereum pentru disponibilitatea datelor. EIP-7623 nu descurajează Ethereum să funcționeze ca un nivel de disponibilitate a datelor; mai degrabă, descurajează utilizarea calldata în scopul stocării datelor de tranzacție și încurajează indirect utilizarea blob-urilor pentru DA. Această propunere își propune să separe stratul de execuție de nivelul de disponibilitate a datelor, permițând fiecărui strat să gestioneze eficient cererea și să prezică mai bine cazurile extreme.

Procedând astfel, EIP-7623 încearcă să sporească eficiența și predictibilitatea gestionării resurselor Ethereum limitând în același timp suprafața DoS. Această separare asigură că fiecare strat își poate gestiona mai eficient funcțiile specifice, contribuind în cele din urmă la o rețea Ethereum mai robustă și mai scalabilă.

O prezentare generală a specificațiilor EIP-7623

Calculul curent de gaz al unei tranzacții este următorul:

Cele 21,000 din specificația de mai sus reprezintă gazul minim perceput pentru orice tranzacție. De asemenea, STANDARD_TOKEN_COST tokens_in_calldata reprezintă gazul folosit pentru calldata, pe care EIP-7623 încearcă în principal să-l repare. Aici, tokens_in_calldata este o combinație ponderată simplă de octeți zero și non-zero, care este calculată de tokens_in_calldata = zero_bytes_in_calldata + 4 * nonzero_bytes_in_calldata .

STANDARD_TOKEN_COST este setat în prezent la 4, deci costul gazului pentru zero_bytes_in_calldata este 4 și nonzero_bytes_in_calldata este 16.

evm_gas_used este gazul utilizat pentru executarea unei tranzacții, acoperind în primul rând interacțiunile cu contractele inteligente. Tranzacțiile non-DA au de obicei o componentă mare evm_gas_used .

Atunci când o tranzacție creează un nou contract, termenul isContractCreation devine 1, ceea ce înseamnă că atrage gaz suplimentar pentru crearea și stocarea noului contract. Deoarece crearea contractului nu este în centrul atenției aici, vom seta acest termen la zero.

EIP-7623 propune următoarea ajustare a calculului total al gazelor:

În noul calcul, max(blue box, red box) compară gazul calculat prin metoda curentă (caseta albastră), cu TOTAL_COST_FLOOR_PER_TOKEN calldata (caseta roșie). Cutia albastră este exact aceeași cu metoda actuală de calcul a gazelor. Caseta roșie, care este nouă în EIP-7623, reprezintă valoarea care judecă dacă o tranzacție este în scopuri DA. Începând cu 1 ianuarie 2025, TOTAL_COST_FLOOR_PER_TOKEN este propus să fie 10, ceea ce este mult mai mare decât STANDARD_TOKEN_COST de 4.

Cu alte cuvinte, dacă o tranzacție nu cheltuiește suficient evm_gas_used , caseta roșie va fi probabil o valoare mai mare decât valoarea casetei albastre, marcând-o ca tranzacție cu scop DA. În consecință, tranzacția va fi taxată la rata TOTAL_COST_FLOOR_PER_TOKEN , plătind efectiv un pic mai puțin de 3 ori mai mult pentru calldata. În schimb, majoritatea tranzacțiilor cu scop general cheltuiesc suficient evm_gas_used , astfel încât valoarea maximă (cutie albastră, casetă roșie) va fi implicit la valoarea casetei albastre, menținând metoda curentă a costului gazului.

Ce fel de tranzacții sunt afectate de EIP-7623?

Pentru a determina ce tranzacții sunt afectate de EIP-7623, trebuie să identificăm condiția în care caseta roșie (calcul de gaz nou) este mai mare decât caseta albastră (calcul de gaz curent).

Ignorând termenul de creare a contractului și înlocuind valori în parametri, obținem următoarea condiție: Tranzacțiile vor suporta un cost mai mare de gaz dacă gazul consumat pentru execuția EVM este mai mic de 6 ori jetonele din calldata.

Pentru a face acest lucru mai intuitiv, să împărțim ambele părți la 4 tokens_in_calldata . Să ne amintim că 6 tokens_in_calldata este gazul plătit pentru calldata într-o tranzacție.

Această ecuație finală indică faptul că, dacă gazul utilizat pentru execuția EVM este mai puțin de două ori gazul utilizat pentru calldata, tranzacția va suporta taxe mai mari pentru calldata.

Cât de mult vor crește costurile Calldata după EIP-7623?

Să presupunem că gazul minim pentru o tranzacție este 21.000, gazul utilizat pentru execuția EVM este k, iar gazul utilizat pentru datele de apel este kx. Costul total al tranzacției poate fi exprimat astfel:

Conform calculului actual (fără EIP-7623), costul ar fi de 21.000+k+kx. Prin urmare, rata de creștere cu EIP-7623 ar fi:

Rata de creștere în funcție de k este reprezentată mai jos:

Pentru a înțelege impactul practic, să examinăm statisticile privind utilizarea gazului pentru metodele de funcționare obișnuite, concentrându-ne pe cele familiare pentru majoritatea utilizatorilor.

Dintre diferitele funcții de swap din schimburile descentralizate, swap(string, address, uint256, bytes) este cea mai utilizată.

În medie, folosește 5.152 pentru date de apel și 175.742 pentru EVM , iar aceasta reprezintă o valoare de 34 de ori mai mare. Funcția transfer(address, uint256) , utilizată pentru transferul de jetoane ERC20, consumă aproximativ 24.501 de gaze pentru execuția EVM, de aproximativ 40 de ori mai mult decât cele 620 de gaze utilizate pentru calldata.

Similar acestor funcții, majoritatea tranzacțiilor zilnice ale utilizatorilor au o diferență semnificativă între gazul utilizat pentru datele de apel și execuția EVM, ceea ce înseamnă că este puțin probabil să fie afectate de EIP-7623.

Analiza oferită de cercetătorul Ethereum Toni Wahrstätter arată că dacă se aplică EIP-7623, 3,02% din tranzacțiile Ethereum recente ar fi afectate. Analiza sa identifică, de asemenea, care metode de funcționare vor fi afectate și estimează creșterea costurilor pentru acele metode. O analiză ulterioară oferită de Wahrstätter arată că pentru tranzacțiile recente pe Ethereum, 3,02% dintre tranzacții sunt afectate dacă se aplică EIP-7623.

Site- ul său arată, de asemenea, ce metode de funcționare vor fi de fapt afectate și cât de mult ar crește prețul pentru acele metode.

Printre funcțiile afectate de EIP-7623, cea mai frecvent utilizată este addSequencerL2BatchFromOrigin() , folosită în mod obișnuit pentru secvențierea tranzacțiilor de acumulare pe Ethereum. O altă metodă afectată este commitBatches() , folosită frecvent în tranzacțiile de acumulare. Aceste două funcții sunt de așteptat să înregistreze cele mai semnificative creșteri ale costurilor, cu o creștere estimată cu 150% a costurilor totale cu gaze atunci când se utilizează aceste metode.

Cu toate acestea, rollup-urile pot utiliza blob-uri pentru postarea datelor și multe rollup-uri, cum ar fi Arbitrum One și Base, fac deja acest lucru . În consecință, agregatele care utilizează blob-uri pentru postarea datelor nu sunt susceptibile să fie puternic afectate de costurile crescute impuse de EIP-7623.

Analizarea impactului EIP-7623 asupra dimensiunilor blocurilor

EIP-7623 crește costul gazului pentru tranzacțiile care utilizează cantități mari de date de apel. Aceasta înseamnă că atacurile de spam, care se bazează în mare măsură pe date de apel, ar necesita un cost de aproximativ trei ori mai mare, reducând efectiv dimensiunea maximă a blocului de la 2,54 MB la aproximativ 0,72 MB. În consecință, rețeaua Ethereum ar fi mai bine echipată pentru a gestiona cele mai defavorabile scenarii în care blocurile mari sunt propagate continuu.

Reducerea dimensiunii maxime posibile a blocului creează o oportunitate de a crește numărul de blob-uri incluse pe bloc. În prezent, numărul maxim de blob-uri este de 6, fiecare având o dimensiune de 128 KiB. Dacă se adoptă EIP-7623 și se menține aceeași dimensiune maximă a blocului, ar putea fi posibilă creșterea numărului maxim de blob-uri la aproximativ 18, ceea ce înseamnă o creștere de 3 ori a TPS-ului maxim (tranzacții pe secundă) de rollup-uri.

Acest calcul implică o oarecare simplificare excesivă, deoarece metodele de propagare pentru blob și blocuri diferă. Cu toate acestea, avantajul principal este separarea crescută între straturile de execuție și disponibilitatea datelor. Deoarece gazul blob și gazul de execuție au piețe separate de taxe, perturbările pe o piață nu o vor afecta direct pe cealaltă.

Această separare simplifică obținerea eficienței capitalului, deoarece devine mai ușor de controlat ținta și resursele maxime pe care le poate gestiona rețeaua Ethereum într-un singur bloc.

Care sunt alte considerente legate de implementarea EIP-7623?

În timp ce EIP-7623 oferă beneficii semnificative, ar putea avea un impact potențial asupra pachetelor mici, necesitând utilizarea blob-urilor în loc de calldata. Pentru pachetele cu cerere redusă, dimensiunea mare a blob-ului de 128 KiB le poate impune să aștepte mai mult până când pot umple întregul blob. Această situație crește nevoia de protocoale de partajare a blob , permițând mai multor pachete să partajeze spațiul mare de blob pentru o mai bună eficiență a costurilor.

Deși taxa de bază pentru blob este în prezent foarte mică (făcând blob-urile un spațiu DA ieftin), o creștere bruscă a cererii ar putea pune o povară semnificativă asupra acestor pachete. Fără o creștere concomitentă a numărului de blob-uri pe bloc, EIP-7623 ar putea face pachetele care trimit tranzacții DA mai competitive, deoarece capacitatea totală pentru DA scade în general. Este necesar să se evalueze dacă numărul de blob-uri ar trebui crescut simultan pentru a se adapta acestei schimbări.

Un alt aspect este stabilirea criteriilor pentru pragul în care tranzacțiile ar trebui să fie afectate de această actualizare. Există compromisuri între dimensiunea blocului și experiența utilizatorului. De exemplu, setarea prea agresivă a pragului ar putea reduce foarte mult dimensiunea maximă a blocului, dar multe tranzacții ar putea fi nevoite să plătească mai mult gaz pentru datele de apel.

Deși modificarea dimensiunii maxime a blocului este explicită și vie, este greu de estimat și de cuantificat cât de mult ar fi afectat Ethereum prin necesitatea unor costuri mai mari de gaz pentru tranzacțiile cu scop DA. Acest prag poate fi stabilit doar social.

În plus, criteriile depind în mare măsură de alți parametri stabiliți de operațiunile EVM sau de limita de gaz. De exemplu, dacă Ethereum ar crește limita de gaz de bloc la 300 de milioane în viitor, pragul EIP-7623 ar trebui, de asemenea, modificat pentru a menține dimensiunea maximă a blocului.

Concluzie

EIP-7623 este o propunere de îmbunătățire a Ethereum care urmărește să reducă dimensiunea maximă a blocului prin ajustarea costului calldata, vizând în mod specific tranzacțiile cu scop DA. Această ajustare ar putea crește costul pentru tranzacțiile DA non-blob cu până la 300%, în timp ce majoritatea tranzacțiilor zilnice ale utilizatorilor rămân neafectate.

Pe parcursul acestei postări, am explorat motivația din spatele propunerii, implicațiile acesteia, tipurile de tranzacții afectate și potențialele preocupări care pot apărea. Sper că această scriere vă va ajuta să înțelegeți mai multe despre această propunere recentă și să vă ofere informații detaliate despre conținutul ei. Dacă sunteți interesat și doriți să aflați mai multe, puteți continua analiza și explicația lui Toni Wahrstätter și puteți participa la discuția deschisă pe forumul Ethereum Magicians.