Sursa articol: Foresight Research
TL;DR:
Upgrade-ul Cancun va fi lansat pe 13 martie 2024, iar EIP4844 va fi online în curând. Danksharding este nucleul foii de parcurs Ethereum, iar această actualizare este primul pas către realizarea Danksharding.
După ce Ethereum L2 este adaptat la EIP4844, taxele de tranzacție au scăzut semnificativ, iar TPS-ul lui L2 s-a dublat. Utilizatorii vor simți că tranzacțiile sunt mai rapide, mai ieftine, o experiență mai fluidă și mai receptive. Vor exista aplicații Dapp mai complexe și mai mari pe aceste L2.
Rollup-urile optimiste sunt mai ușor de adaptat la EIP4844, în timp ce pachetele ZK sunt mai complexe de adaptat. Ethereum nu are un contract precompilat pentru a suporta curbele eliptice BLS12-381, ceea ce face dificilă verificarea unor ZKP-uri și împiedică progresul rollup-urilor ZK care se adaptează la EIP4844.
Problema curbelor eliptice poate fi rezolvată în două moduri, 1. Așteptați ca Ethereum să precompileze curbele eliptice BLS12-381 2. Folosiți o altă metodă de demonstrare pentru a atinge același scop, folosind BN254 suportat de pre-compilarea Ethereum;
În prezent, Arbitrum, Optimistic, Starknet, zkSync, Scroll, Polygon zkEVM și noul L2 Morph se adaptează toate la EIP4844. Printre acestea, Arbitrum, Optimistic și Starknet au declarat că vor implementa adaptarea EIP4844 după upgrade-ul Cancun. Morph a preluat conducerea în lansarea soluției inovatoare de adaptare zkSNARK zkEVM, care va fi primul zkSNARK zkEVM care se va adapta la EIP4844.
1. Fundal
În 2020, Ethereum a lansat „Foaia de parcurs Ethereum centrată pe Rollup” și imaginea finală a lui Ethereum descrisă în „Endgame” publicată de Vitalik anul următor, care a determinat direcția generală a Ethereum: optimizarea construcției stratului de bază Ethereum pentru a servi Rollup.
Ethereum a proiectat tehnologia de fragmentare a lui Danksharding pentru a îmbunătăți capacitatea de utilizare a lui Ethereum ca strat de disponibilitate a datelor. Va reduce semnificativ taxele de tranzacție ale L2, va crește TPS-ul Rollup și va realiza o extindere substanțială a Ethereum.
Până în acest an, upgrade-ul Ethereum Cancun-Dencun a fost lansat în sfârșit pe 13 martie 2024, iar EIP4844 este pe cale să intre online. Se poate spune că acest hard fork este primul pas în implementarea Danksharding de către Ethereum și este ruta Ethereum. Miezul din miezul graficului.
În ceea ce privește ce este stratul DA, principiile tehnice ale Danksharding și conținutul EIP4844, vă rugăm să consultați un articol tehnic pe care l-am scris anul trecut: DA (Disponibilitatea datelor) Vine vara? https://foresightnews.pro/article/detail/33575
2. Cum va beneficia upgrade-ul Cancun L2?
EIP4844 introduce un nou tip de tranzacție numit tranzacții care transportă blob. Fiecare tranzacție care poartă blob poate „purta” o listă de blob. Un blob este un pachet de date, aproximativ 125 KB. Bloburile sunt stocate pentru o perioadă scurtă de timp, doar 4096 de epoci, ceea ce înseamnă puțin mai mult de 18 zile.
Taxele de tranzacție L2 au scăzut semnificativ. Deoarece blob-urile nu necesită stocare permanentă, blob-urile sunt mai mari și mai ieftine decât spațiul bloc. Blob-urile pot stoca de 10 ori mai multe date decât Calldata la același consum de gaz. Rollup-ul adaptat la EIP4844 poate stoca date de tranzacție în Blobs, reducând taxele de tranzacție cu un ordin de mărime.
TPS-ul L2 este dublat. Ținta actuală este de 3 blob-uri pe bloc, cu maximum 6 blob permise. Blocurile au doar 90 KB și fiecare blob are aproximativ 125 KB. Introducerea Blob este echivalentă cu extinderea spațiului de mai multe ori al blocului pentru a stoca datele Rollup, astfel încât TPS-ul Rollup poate fi, de asemenea, dublat. Și „On Increasing the Block Gas Limit” scris de Toni și Vitalic a declarat că prin creșterea limitei de bloc de gaz și prețul octeților Calldata non-zero, se va obține o dimensiune mai mică a blocului cu mai puține variabile, astfel încât să se poată adăuga mai multe în viitorul. Cu cât mai multe blob-uri, cu atât este mai mare spațiul de stocare.
Pentru utilizatorii finali, după ce Ethereum L2 este adaptat la EIP4844, tranzacțiile vor fi mai rapide, cu costuri mai mici, mai fluide și mai receptive. Vor exista aplicații Dapp mai complexe și mai mari pe aceste L2.
3. Cum se adaptează L2 la EIP4844?
Cum se adaptează L2 la EIP4844? Trebuie să discutăm separat despre Optimistic Rollup și ZK Rollup.
Rollup-uri optimiste adaptate la EIP4844
Optimistic Rollup folosește dovada fraudei pentru a asigura corectitudinea execuției rollup-ului. Adică, nodul alege mai întâi să creadă că tranziția de stat este corectă, cu excepția cazului în care cineva inițiază un certificat de fraudă într-o anumită perioadă de timp pentru a dovedi că tranziția de stat prezentată anterior este ilegală, tranziția de stat va fi revocată.
Acumularea optimistă este mai ușor de adaptat la EIP4844 decât pachetul ZK. Trimiteți toate tranzacțiile L2 către L1 prin tranzacții care transportă blob pentru a finaliza adaptarea. În plus, dovada fraudei trebuie ajustată pentru a se adapta la EIP4844. Această parte poate fi făcută încet. La urma urmei, multe pachete optimiste nu au lansat încă dovezi de fraudă. Am pus online un certificat de fraudă, dar am constatat că de mai bine de doi ani nu a fost depus niciun certificat de fraudă.
Trimiterea tranzacției L2: atunci când se trimite Rollup, tranzacțiile care transportă blob sunt folosite pentru a stoca datele Rollup în Blob. Sarcina utilă a tranzacției care transportă blob este rlp([tx_payload_body, blobs, engagements, proofs]), unde
tx_payload_body - este TransactionPayloadBody al tranzacției blob standard EIP-2718.
blobs - o listă de blobs. O tranzacție poate conține până la două blob-uri.
angajamente - lista blob a angajamentelor KZG.
dovezi - Blob și listă de dovezi corespunzătoare angajamentului KZG. Această dovadă va fi verificată de nodul ETH.
Ajustați dovada fraudei:
În primul rând, probatorul și contestatorul au nevoie de mai multe runde de interacțiune pentru a găsi punctul de dispută.
Apoi trimiteți punctul de litigiu la L1 pentru judecată. Pentru a se adapta la EIP4844, poate fi necesar să se demonstreze că datele în cauză sunt stocate pe un anumit Blob.
Deoarece datele blob vor fi șterse după aproximativ 18 zile, perioada de provocare trebuie să fie înainte ca acestea să fie șterse, ceea ce este satisfăcut de actualele acumulari optimiste. În general, perioada de provocare nu depășește 7 zile.
ZK Rollups se adaptează la EIP4844
ZK rollup folosește ZKP pentru a demonstra că tranziția stării L2 este corectă. Adaptarea agregatului ZK la EIP4844 este mai complicată decât agregarea optimistă.
Trimiterea tranzacției L2: acest pas al Optimistic Rollup este similar.
Trimiterea dovezilor ZK: în comparație cu ZK Rollup înainte de adaptare, pe lângă proba ZKP de tranziție a stării, este necesar încă un proces de dovezi. Adică, se demonstrează că angajamentul blob și lotul de tranzacție sunt corespunzătoare, asigurându-se astfel că introducerea dovezii de tranziție a stării este corectă.
De exemplu: circuitul ZK de tranziție de stare poate genera o dovadă a procesului de calcul a + a = b. ZKP-ul generat atunci când (a=1,b=2) și (a=2,b=4) este legal. Prin urmare, trebuie să ofer și o dovadă că intrarea pe care am furnizat-o la acel moment a fost (a=1,b=2) în loc de (a=2,b=4).
Acest lucru nu trebuie făcut înainte de adaptarea la EIP4844, deoarece datele sunt stocate direct în Calldata și pot fi citite direct, asigurându-se că intrarea nu va fi ajustată. După utilizarea EIP4844, datele Blob nu pot fi citite direct, iar acest lucru poate fi dovedit doar printr-un circuit nou.
Este mai ușor să implementați acest mecanism de verificare folosind pachetul ZK de la STARK (cum ar fi Starknet). Aceasta este o provocare pentru ZK rollup folosind SNARK. Motivul este: curba eliptică utilizată de angajamentul blob al EIP4844 este BLS12-381, iar contractul precompilat ETH acceptă doar BN254 Verificați certificatul de finalizare a angajamentului blob din contract.
Utilizarea zkEVM/zkVM de la SNARK trebuie să rezolve problema menționată la punctul 2 conform căreia dovada ZK nu poate fi generată din cauza nepotrivirii curbei.
Se așteaptă ca Ethereum să accepte contractele precompilate pentru BLS12-381. Acest lucru va fi lung.
Luați un alt mod de a dovedi. Pentru a proiecta circuite noi, trebuie să utilizați curba eliptică BN254 susținută de contractul precompilat. În prezent, vedem Morph luând această abordare. Acest lucru face, de asemenea, Morph primul zkEVM care finalizează adaptarea EIP4844.
Soluția de integrare EIP-4844 zkEVM de la Morph, consultați: https://medium.com/@morphlayer2/morphs-solution-to-eip-4844-zkevm-integration-7f469910478f
4. Ce L2 sunt adaptate la EIP4844?
În pachetul Optimistic, Optimism și Arbitrum și-au exprimat angajamentul de a adopta EIP-4844 și lucrează îndeaproape cu comunitățile lor pentru a testa și implementa actualizările necesare. Arbitrum este un rollup de Etapa 1 și are o securitate relativ bună. Implica necesitatea de a adapta dovada fraudei la EIP4844. Acumularea optimistă este un pachet de etapă 0. În prezent, nu există dovadă de fraudă. Este mai ușor de adaptat, dar securitatea nu este suficient de mare.
În rollup ZK, dificultatea adaptării rollup-ului folosind STRAK și SNARK este diferită. Este mai ușor să adaptezi EIP4844 cu rollup-ul STARK, iar Starknet este unul dintre reprezentanți. Starknet a publicat un articol în care afirmă că Cancun va implementa adaptarea EIP4844 după actualizare (link articol). Cu pachetul SNARK, zkSync explorează, de asemenea, cum să folosească tranzacțiile care transportă blob pentru a reduce și mai mult costurile și a îmbunătăți performanța. Scroll a publicat un articol anul trecut în care a introdus ideea adaptării EIP4844 (link articol)
Cel mai impresionant este Morph, care este un Optimistic ZK Rollup. A fost primul care a lansat o soluție pentru adaptarea zkEVM la EIP4844. Se poate spune că este primul Rollup zkEVM care a completat EIP4844.
Optimistic ZK Rollup combină avantajele ambelor tipuri de Rollup. Crede cu optimism în rezultatele execuției transmise de Sequencer și permite celor care au îndoieli cu privire la rezultate să inițieze provocări. Doar atunci când este emisă o provocare, probatorul va genera ZKP pentru a demonstra corectitudinea rezultatelor execuției. Are eficiența rollup-ului Optimistic și fiabilitatea dovedită de ZK a rollup-ului ZK.
