Elaborarea foii de parcurs pentru abstracția contului Ethereum I: EIP-3074, EIP-5806 și EIP-7702

După ce am observat schimbările semnificative care au fost introduse în Ethereum prin upgrade-ul Deneb, am început să ne uităm la ceea ce va introduce următorul hardfork, Pectra. Pentru a ajuta la modelarea discuțiilor care vor urma, căutăm să descriem peisajul actual al abstracției conturilor din jurul Ethereum și ecosistemul său de acumulare, pentru a putea mapa o cale clară înainte.

Acest raport oferă o privire de ansamblu asupra modelului de cont curent al Ethereum, în special asupra efectelor acestora asupra validității tranzacțiilor, a ceea ce presupune exact abstracția contului și un cadru de raționament în legătură cu acesta. Ne vom concentra apoi pe abordarea programabilității EOA prin evaluarea EIP-urilor 5086, 3074 și 7702 și vom concluziona cu modul în care toate acestea afectează probabil viitorul tranzacțiilor pe Ethereum.

Deși există multă confuzie cu privire la ceea ce este sau nu abstracția contului, încadrarea noastră de-a lungul acestei serii este că orice mecanism care permite unui cont să redefinească orice parte a regulilor sale de valabilitate este un mecanism pentru abstracția contului. În plus, oferim o clasificare a acestor mecanisme, deoarece majoritatea dintre ele sunt vag similare și se interpun.

O prezentare generală a abstracției contului în Ethereum

Abstracția contului urmărește să îmbunătățească experiențele utilizatorilor și dezvoltatorilor în întregul ecosistem Ethereum. Pe lângă faptul că experiențele în lanț sunt mai accesibile și mai plăcute pentru utilizatori, le permite dezvoltatorilor să poată face lucruri mai puternice pe Ethereum și să servească utilizatorii în moduri și mai semnificative.

Clasificarea noastră a abordărilor privind abstractizarea conturilor este următoarea:

1. Îmbunătățirea/programabilitatea EOA : Aceasta include modificări la nivel de protocol care permit EOA (Conturi deținute din exterior) să redefiniască porțiunea logică de execuție a regulilor lor de valabilitate. După cum sunt binecunoscute în comunitatea de dezvoltare, EOA-urile sunt conturi asociate de obicei cu utilizatorii finali. Prin urmare, soluțiile care se încadrează în această abordare vor oferi conturilor utilizatorilor finali mai mult control asupra tipului de acțiuni pe care le pot autoriza, în comparație cu modul în care acestea pot fi gestionate astăzi.

2. Conversia/migrarea EOA : Această abordare include propuneri care urmăresc conversia completă a EOA în CA (conturi contractuale). Ideea integrală a acestei abordări este că conturile contractuale oferă deja cele mai multe dintre beneficiile oferite de conturile inteligente, așa că nu ar trebui să mai fie nevoie să complicăm lucrurile; toată lumea ar trebui să folosească pur și simplu un cont de contract ca cont principal (prin portofele de contracte inteligente).

Această abordare prezintă mecanisme care permit unei EOA să treacă la o CA, fără a fi nevoie să-și mute activele, cum ar fi EIP 7377 și EIP 5003 (când sunt luate în considerare împreună cu EIP 3074).

3. Conturi inteligente : acest grup de propuneri include modele care permit atât EOA, cât și CA-urilor să se comporte ca „conturi inteligente”, permițându-le să-și redefinească complet regulile de valabilitate.

Au fost făcute anterior diferite propuneri pentru crearea de conturi inteligente și consacrarea abstracției conturilor la nivel de protocol; EIP-86 și EIP-2938 sunt unele dintre cele mai citate. Cu toate acestea, au existat multe respingeri din cauza complexității percepute introduse de acest design și a părerii oarecum majoritare că Ethereum nu este pregătit pentru o asemenea complexitate.

După renașterea subiectului de către Vitalik după Merge, ERC-4337 a fost propus ca o versiune opt-in a standardului de cont inteligent, similar infrastructurii PBS (Proposer-Builder Separation) pentru MEV (Maximal Extractable Value). Astfel, utilizatorii care doresc să acceseze beneficiile conturilor inteligente ar putea pur și simplu să folosească conducta ERC-4337 pentru a redefini logica contului lor și regulile de valabilitate a tranzacțiilor în structuri denumite UserOperation (sau UserOps pe scurt).

ERC 4337 aduce beneficiile conturilor inteligente în Ethereum actual, fără a consacra nicio complexitate, funcționând ca o alternativă în afara protocolului la conturile inteligente consacrate. Cu toate acestea, acest lucru nu înseamnă că infrastructura este optimă în starea ei actuală, deoarece propria sa complexitate este încă un punct de eșec considerabil.

Pentru a aborda această complexitate, RIP 7560 a fost elaborat ca o versiune consacrată a infrastructurii ERC 4337 în Ethereum și L2-urile sale, astfel încât să moștenească schemele de rezistență la sibil ale rețelei, în loc să fie nevoit să definească o nouă suită de reguli (cum face ERC 4337 cu ERC 7562 ).

În acest raport, ne vom concentra pe explorarea programabilității EOA, evaluarea diferitelor EIP-uri care descriu soluții pe această linie și discută meritele și dezavantajele acestora. În părțile 2 și 3 ale acestei serii, vom acoperi celelalte două clase de abordare a abstracției conturilor care sunt explorate în Ethereum.

Un primer despre conturile și tranzacțiile Ethereum

Pentru a găsi ceea ce poate fi abstractizat, avem nevoie de o imagine (oarecum) completă a designului contului curent. Această secțiune va servi în principal ca o revizuire a conturilor de pe Ethereum și a modului în care tranzacțiile lor sunt validate și executate.

Conturile Ethereum sunt entități cu un sold ether (ETH) și capacitatea de a trimite tranzacții pe blockchain-ul Ethereum. Ele sunt reprezentate ca o „adresă” hexazecimală de 42 de caractere, care servește ca un indicator unic către deținerile și tranzacțiile contului.

O adresă acționează ca o cheie în încercarea de stare a blockchain-ului. Nodurile frunză ale acestui trie sunt structuri de date de cont care pot fi descompuse în patru câmpuri:

1. nonce : un contor liniar folosit pentru a indica numărul de tranzacții de ieșire inițiate de un cont. De asemenea, este crucial în prevenirea atacurilor de reluare.
2. balance : cantitatea de eter (ETH) denominată în wei deținută de un cont.
3. codeHash : un hash al codului executabil EVM conținut într-un cont. EVM (Ethereum Virtual Machine) este mediul de execuție personalizat al Ethereum responsabil pentru gestionarea tranzițiilor complexe de stare dincolo de simplele tranzacții de „trimitere”. Conținutul de cod al unui cont este programat imuabil pentru a efectua forme specifice de tranziție de stat pe blockchain-ul Ethereum, prin EVM.
4. storageHash : un hash al rădăcinii de stocare a unui cont, folosit pentru a reprezenta conținutul de stocare al unui cont ca un hash de 256 de biți al nodului rădăcină al unui merkle patricia trie. Pur și simplu, este un hash al datelor variabile de stat legate de conținutul codului unui cont.

Conținutul acestor patru câmpuri este folosit pentru a defini tipul unui cont și, în cele din urmă, continuă să definească amploarea funcționalităților acestuia. Astfel, cele două tipuri de conturi Ethereum sunt:

1. Conturi deținute extern (EOA) — care sunt inițializate ca o pereche de chei criptografice:

• O cheie privată care este un caracter criptabil și probabil aleatoriu de 64 de hex și omologul său complementar;
• O cheie publică care este derivată din cheia privată folosind ECDSA (Algoritmul de semnătură digitală cu curbă eliptică).

EOA au câmpuri codeHash și storageHash goale și pot fi controlate numai de oricine deține cheile private. Adresele lor pot fi obținute de la cheia publică corespunzătoare prefixând „0x” la ultimele douăzeci de caractere ale hash-ului keccak-256 al cheii publice a contului.

2. Conturi contractuale (CA) care pot fi create numai printr-un EOA preexistent. Acestea sunt inițializate datorită unui EOA care implementează conținut de cod executabil pe EVM. Acest conținut de cod (stocat ca codeHash) este consacrat în EVM și este responsabil pentru controlul contului prin definirea logicii și interacțiunilor acestuia.

Tranzacțiile din contul de contract sunt în întregime bazate pe pull bazate pe logica codului lor implementat. Deoarece aceste conturi pot fi controlate numai de conținutul codului lor, nu au nevoie de o cheie privată și au doar o cheie publică. Astfel, orice agent care are capacitatea de a actualiza/modifica conținutul codului unui cont contractual ar putea accesa soldul acestuia. Adresa unui cont de contract este derivată din adresa creatorului său și nu a acestuia până la momentul implementării contractului.

Tranzacții

Am descris recent conturile ca fiind entități care au capacitatea de a trimite tranzacții pe Ethereum. Prin urmare, putem înțelege că un scop principal al unui cont este acela de a trimite și primi tranzacții, în timp ce blockchain-ul acționează ca un registru înregistrând istoricul tranzacțiilor, precum și descriind modul în care tranzacțiile modifică câmpurile contului pe baza regulilor descrise în specificația protocolului blockchain.

Deci, care sunt aceste „tranzacții”?

Tranzacțiile sunt operațiuni trimise dintr-un cont, care provoacă o schimbare în „starea” rețelei. Sunt instrucțiuni semnate criptografic din conturi, care au ca rezultat o actualizare a stării la nivel de rețea atunci când sunt executate.

Lipsa permisiunii vine cu costul stimulentelor perverse, pentru a face față acestora, trebuie definite linii directoare stricte (sau reguli de valabilitate) pentru interacțiunile în astfel de medii. În acest context, tranzacțiile trebuie să respecte anumite reguli de valabilitate pentru a fi considerate valide și executate. Majoritatea acestor reguli de valabilitate sunt implementate prin constrângeri impuse contului care trimite tranzacția și variază în funcție de tipul de cont.

Conturile și valabilitatea tranzacțiilor

Pe Ethereum, EOA-urile sunt optimizate pentru utilizare, deoarece sunt orientate spre utilizatorul final. Au capacitatea de a trimite tranzacții într-un mod specific și funcționează perfect autonom. Ele pot fi create și local, metoda mai comună fiind utilizarea furnizorilor de portofel precum MetaMask, Rainbow, Rabby etc.

Pe de altă parte, conturile contractuale pot trimite doar tranzacții permise de logica lor, ca răspuns la „ chemarea ”. De asemenea, acestea pot fi create doar de un EOA care are un sold suficient pentru a plăti stocarea de stat.

O descriere la nivel mai înalt ar fi aceea că EOA poate păstra doar un sold, în timp ce CA pot deține atât un sold, cât și o logică care dictează modul în care acest sold poate fi cheltuit. Aceste proprietăți se datorează următorilor parametri logici care definesc regulile pe care trebuie să le respecte tranzacțiile unui cont:

1. Logica de autentificare - Folosită pentru a defini modul în care un cont își dovedește identitatea în rețea în timp ce își schimbă soldul și/sau logica.
2. Logica de autorizare - Folosită pentru a defini politica de acces a unui cont, adică cine este capabil să acceseze și să facă modificări la soldul și/sau logica contului.
3. Logica Nonce - care definește ordinea în care vor fi executate tranzacțiile dintr-un cont.
4. Logica de plată a gazelor - Folosită pentru a defini partea responsabilă pentru decontarea taxei de gaz a unei tranzacții.
5. Logica de execuție - Folosită pentru a defini ce forme de tranzacții poate trimite un cont sau cum urmează să fie executată o tranzacție.

Acești parametri sunt proiectați pentru a fi rigizi pentru EOA, astfel:

• Autentificarea și autorizarea sunt asigurate de o cheie privată bazată pe ECDSA, adică un utilizator care dorește să trimită o tranzacție din EOA trebuie să-și folosească cheia privată pentru a accesa contul și astfel să demonstreze că are dreptul de a efectua orice modificare a soldului acestuia. .
• Logica nonce implementează o schemă de contor secvenţial, care permite doar o singură tranzacţie per nonce unic să fie executată secvenţial per cont.
• Logica de plată a gazelor specifică că taxa de gaz pentru tranzacții trebuie decontată de către expeditor/contul de origine.
• Logica de execuție specifică faptul că EOA pot trimite numai următoarele formulare de tranzacție:

1. Transferuri regulate între două EOA.
2. Implementarea contractului.
3. apeluri contractuale care vizează logica unui cont de contract implementat.

În general, logica de execuție a EOA le constrânge la o singură tranzacție per semnătură validă.

Pe de altă parte, CA au mai multă flexibilitate în ceea ce privește acești parametri:

• Autentificarea nu este necesară, deoarece tranzacțiile lor sunt de natură consecință/pull-based.
• Autorizarea pentru CA poate lua două forme:

1. Abilitatea de a „ apela ” codul de conținut al CA (sau de a-și executa contractul inteligent), care depinde de logica contractului inteligent al contului și de invarianții acestuia.
2. Capacitatea de a face modificări codului de conținut al CA, care depinde în mare parte de dacă codul de conținut poate fi actualizat sau nu.

În majoritatea cazurilor practice, logica utilizată în acest caz este o schemă cu mai multe semnături care stipulează că un M din N semnături valide (unde M < N) este necesar din conturi specifice (de obicei EOA) pentru o schimbare a logicii CA. a fi valabil.

• Ordinea lor de tranzacție este vag bazată pe nonce. CA în sine este capabil să trimită cât mai multe tranzacții către cât mai mulți apelanți diverși, totuși fiecare apelant este limitat în funcție de propriile capacități.
• Plata pentru gaz este de obicei gestionată de apelantul logicii CA.
• Logica de execuție a CA-urilor este mai diversă pentru a permite îmbunătățiri UX, cum ar fi tranzacțiile multicall și tranzacțiile atomice.

Evaluând aceste caracteristici, observăm că fiecare tip de cont este conceput pentru a avea un compromis între autonomie și programabilitate.

EOA au autonomie deplină, dar programabilitate limitată; pot autoriza și trimite tranzacții oricând doresc, dar aceste tranzacții trebuie să urmeze un format rigid pentru a fi considerate valide. Conturile contractuale au programabilitate deplină (limitată doar de designul EVM) dar autonomie limitată: tranzacțiile lor nu trebuie să urmeze niciun format rigid, ci pot fi trimise doar datorită logicii lor fiind apelate prima.

În următoarea subsecțiune, vom studia acum implicațiile acestor alegeri de proiectare, pentru a înțelege pe deplin propunerea fiecărui EIP discutat de-a lungul acestei serii.

Dilema contului Ethereum

Acum că avem o cunoaștere oarecum succintă a funcționalităților diferitelor conturi, putem identifica cu ușurință punctele de vânzare ale acestora, precum și problemele pe care le prezintă atât experienței utilizatorilor, cât și dezvoltatorilor pe Ethereum. După cum am menționat anterior, EOA sunt concepute ca conturi de primă clasă care vizează utilizatorii finali. Aplicațiile sunt concepute pentru a interacționa cu ușurință cu ele, nu există aproape nicio complexitate pentru ele și, desigur, nu există niciun cost pentru crearea uneia. Cu toate acestea, simplitatea sa vine cu o pierdere semnificativă de noutate, deoarece sunt concepute pentru a fi strict deterministe.

Unele dintre preocupările din jurul lor sunt:

1. Susceptibilitate la atacuri cuantice - Schema de semnătură ECDSA folosită de perechea lor de chei nu este rezistentă la cuantum și, cu o cronologie optimistă de 5 până la 10 ani pentru sistemele cuantice industriale, aceasta reprezintă o amenințare semnificativă pentru Ethereum și aplicațiile sale, care se bazează foarte mult. privind schema ECDSA pentru dovezi criptografice și securitate.
2. Lipsa de exprimare – Formatul rigid al regulilor de valabilitate ale EOA elimină capacitatea utilizatorilor de a-și exprima tranzacțiile mai succint prin funcții precum atomicitatea tranzacției și loturile și delegarea tranzacțiilor.
3. Autosustenabilitate – Toată lumea a avut parte de momente „am rămas fără benzină” în mijlocul unei tranzacții. Acest lucru se datorează cerinței ca EOA să deconteze singuri gazele pentru tranzacțiile lor, ceea ce nu ar fi o întrebare prea mare dacă eterul (ETH) nu ar fi singura monedă de gaz acceptabilă. Deși aceasta este o problemă generală cu mașinile de stat bazate pe cont (și chiar cu cele bazate pe UTXO), Ethereum a intenționat întotdeauna să fie diferit.

Nu toată lumea vrea (sau ar putea) să dețină întotdeauna ETH (adică uitați-vă la acțiunea prețului), așa că soluțiile viabile ar fi fie să permită mai multe monede ale gazului (prea greu, rupe prea multe invariante așa cum este descris în „Moneda ” aici ), sau pentru a permite plățile de gaz să fie decontate printr-un alt cont care nu este originea tranzacției.

La celălalt capăt al spectrului de conturi, CA vizează dezvoltatorii și o bază de utilizatori mai tehnică. Ele servesc ca vehicule pentru contractele inteligente (adică considerăm contractele inteligente ca fiind logica sau conținutul lor de cod) și, prin urmare, pot implementa formate noi de tranzacții, astfel cum sunt activate de EVM.

Cu toate acestea, pentru toate aceste caracteristici, sunt conturi glorificate de clasa a doua, deoarece nu au autonomie. Unele dintre dezavantajele lor sunt următoarele:

1. Lipsa totală de autonomie – CA nu pot începe o tranzacție, pot trimite tranzacții doar ca răspuns la invocarea într-un mod foarte particular.
2. Susceptibilitate la eroarea umană în logica lor – Lipsa rigidității duce adesea la definirea incorectă a invarianților și a altor astfel de logici, ceea ce a dus la pierderi de miliarde de dolari din cauza exploatărilor și hackurilor de contracte inteligente. Cu toate acestea, acesta este un subiect aproape complet diferit, care depășește domeniul nostru de aplicare aici.

După ce am analizat alegerile de proiectare care au condus la problemele definite în această subsecțiune, putem trece acum la evaluarea soluțiilor propuse.

O cronologie a abstracției contului

Pentru a găsi ceea ce poate fi abstractizat, avem nevoie de o imagine (oarecum) completă a designului contului curent. Această secțiune va servi în principal ca o revizuire a conturilor de pe Ethereum și a modului în care tranzacțiile lor sunt validate și executate.

Conceptul de abstractizare a contului (cel puțin prin conturi inteligente) a fost întotdeauna o parte integrantă a foii de parcurs a Ethereum. Știrea este că complexitatea din jurul implementării sale a amenințat să întârzie și mai mult lansarea Ethereum, așa că a fost abandonat pentru designul actual, cu diferite conturi care oferă diferite funcționalități. A fost amânat din nou de concentrarea Ethereum pe The Merge, iar acum reapare ca parte principală a următoarei upgrade majore a rețelei – Pectra. Cu toate acestea, complexitatea sa este încă considerată un dezavantaj semnificativ care împiedică consacrarea sa, mai ales că Ethereum a trecut la o foaie de parcurs centrată pe rollup.

Cerințele sunt acum duble:

1. Standardele de cont trebuie să fie mai expresive, dar fără pierderea autonomiei. Un nou standard care sigilează diferența dintre standardele EOA și CA.
2. Noul standard trebuie să reducă decalajul dintre EOA și CA, rămânând în același timp compatibil cu Ethereum și ecosistemele sale L2.

În mod intuitiv, acest concept joacă un rol mai important în contextul abstracției în lanț și al interoperabilității. Cu toate acestea, domeniul nostru de aplicare de-a lungul acestui raport este limitat la inițiativele tehnice luate pentru a realiza abstractizarea în sine.

Abstracția contului își propune să combine cele mai bune caracteristici ale EOA și CA într-un nou standard de cont – conturi inteligente , care permit separarea totală sau parțială a regulilor de valabilitate ale oricărui cont într-o logică de validare și una de execuție; astfel încât conturile să își poată defini propriile reguli de valabilitate – așa cum sunt permise de EVM – la fel ca conturile contractuale, rămânând în același timp complet autonome la fel ca conturile deținute din exterior.

Există adesea confuzie în ceea ce privește diferențele dintre conturile inteligente și portofelele cu contracte inteligente , așa că haideți să descriem în mod explicit care sunt aceste diferențe mai jos:

• Conturile inteligente sunt conturi Ethereum care sunt conceptualizate pentru a oferi părți egale de programabilitate și autonomie. Ideea este că atât EOA-urile, cât și AC-urile pot deveni conturi inteligente pur și simplu utilizând un mecanism (de exemplu ERC 4337) care le permite să-și înlocuiască regulile de valabilitate impuse de rețea cu reguli de valabilitate personalizate, după cum consideră de cuviință.
• Portofelele inteligente , pe de altă parte, sunt pur și simplu furnizori de portofele care servesc ca interfețe pentru conturile contractuale (da, un portofel nu este un cont).

Comercializarea portofelelor cu contracte inteligente a ușurat adoptarea CA de către o piață mai largă, permițând utilizatorilor mai puțin tehnici să profite de funcțiile pe care le oferă. Cu toate acestea, ei încă se confruntă cu capcanele asociate CA.

Înapoi la conversație; Am discutat anterior despre parametrii care sunt utilizați pentru a defini regulile de valabilitate a tranzacțiilor conturilor:

• Autentificare
• Autorizare
• logica nonce
• Logica de plată a gazelor
• Logica de execuție

Valorile primilor patru parametri pot fi denumite în mod colectiv logica de validare a unui cont, care sunt verificări care au loc înainte de începerea execuției unei tranzacții. Ultimul parametru definește modul în care va decurge execuția tranzacției.

În introducere, am oferit o imagine de ansamblu la nivel înalt a peisajului actual AA sub forma unei clasificări pentru diferitele modele propuse. Acum ne vom concentra pe prima clasă de soluții la dilema contului Ethereum - programabilitatea EOA.

EOA programabile

Cea mai mare atracție a Ethereum este ecosistemul său DeFi tânăr, dar vibrant, care prezintă o varietate de aplicații descentralizate care sunt principalele sale chiuvete de lichiditate. Cele mai multe dintre aceste DApp-uri sunt optimizate pentru a servi EOA, astfel încât sunt greu de interfațat cu conturile contractuale și, eventual, cu conturile inteligente. În timp ce portofelele inteligente cu contracte ajută conturile contractuale în acest caz, ele vin cu propriile lor limitări și cu un UX complet diferit.

O soluție intermediară care este explorată în timp ce atât DApps, cât și furnizorii de portofel se obișnuiesc cu standardul contului inteligent, este de a oferi îmbunătățiri temporare EOA care să le permită să depășească majoritatea restricțiilor impuse, fie că este vorba de validarea sau logica lor de execuție. Mai jos, trecem peste specificațiile a trei EIP-uri majore care oferă rute acționabile către programabilitatea EOA; de la mai puțin cunoscut EIP 5806 , la ambițiosul EIP 3074 și apoi în cele din urmă la victorios EIP 7702 .

Programabilitate prin EIP-5806

Această propunere urmărește să aducă mai multe funcționalități standardului EOA, permițându-i să efectueze apeluri delegate către logica unui cont de contract (contractul său inteligent). Acest lucru face ca contractul inteligent să fie executat în contextul EOA apelantului, adică EOA rămâne în controlul logicii sale de validare, în timp ce logica sa de execuție este gestionată de logica contului de contract corespunzător.

Înainte de a continua, haideți să facem o călătorie pe banda de memorie a evoluției Ethereum până la EIP-7 . EIP-7 a propus crearea codului operațional 0xf4/DELEGATECALL , care este folosit pentru a trimite apeluri de mesaje într-un cont principal cu logica unui cont secundar, menținând în același timp valorile câmpurilor [exmițător] și [valoare] ale contului principal. Cu alte cuvinte, contul primar „moștenește” (sau împrumută dacă preferați) logica contului secundar pentru o anumită durată, așa cum este specificată în apelul de mesaj, astfel încât logica celui din urmă să fie executată în contextul celui dintâi.

Acest opcode a permis dezvoltatorilor dapp să-și împartă logica aplicației în mai multe contracte inteligente, menținând în același timp interdependența, astfel încât să poată ocoli cu ușurință barierele de dimensiunea codului și barierele de gaz. EIP-5806 găsește o nouă utilizare pentru codul operațional DELEGATECALL dincolo de a permite conturilor contractuale să fie interdependente. Mai exact, EIP-5806 folosește EIP-7 ca sursă de inspirație pentru a propune extinderea funcționalității de apel de delegat și la EOA; adică, să permitem EOA să fie, de asemenea, interdependente cu conturile contractuale, pentru că de ce nu.

Specificațiile EIP-5806

EIP 5806 introduce un nou tip de tranzacție compatibil EIP-2718, care este împachetat după cum urmează:

 rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

Aceste tranzacții sunt concepute astfel încât câmpul [către] – care reprezintă adresa destinatarului – să poată accepta adrese doar ca intrări de 20 de octeți, dezactivând expeditorul să folosească opcode-ul CREATE .

Motivația din spatele fiecărei componente a schemei RLP sunt următoarele:

• chainID : identificatorul compatibil cu EIP-115 al lanțului curent este completat la 32 de octeți. Această valoare oferă protecție împotriva atacurilor de reluare, astfel încât tranzacțiile din lanțul inițial să nu fie replicate trivial pe lanțuri EVM alternative cu un istoric similar și o securitate economică mai mică.
• nonce : un identificator unic pentru fiecare tranzacție care oferă, de asemenea, protecție împotriva atacurilor de reluare.
• max_priority_fee_per_gas și max_fee_per_gas : valorile taxei de gaz pe care o tranzacție EIP-5806 trebuie să le plătească pentru comandă și, respectiv, pentru includere.
• gas_limit : cantitatea maximă de gaz pe care o poate consuma o singură tranzacție de tip 5806.
• destinație : destinatarul tranzacției
• date : conținutul codului executabil
• access_list : agenți care sunt autorizați condiționat să execute tranzacții EIP-5806.
• signature_y_parity, signature_r și signature_s : trei valori care împreună reprezintă o semnătură secp256k1 peste mesaj — keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

În timp ce împachetarea tranzacțiilor EIP-5806 în plicurile EIP-2718 le permite să fie foarte compatibile cu retroactiv, EOA-urile nu sunt echivalente cu conturile contractuale. Așadar, anumite restricții trebuie definite în modul în care un EOA utilizează apelurile delegate pentru a preveni ruperea invariabilă.

Aceste restricții vizează următoarele coduri operaționale:

• SSTORE/0x55 : Acest cod operațional permite unui cont să salveze o valoare în stocare. Este restricționat în tranzacțiile EIP-5806 pentru a împiedica EOA să seteze/acceseze spațiul de stocare folosind apelurile delegate, prevenind astfel potențialele probleme care pot apărea în viitor din cauza migrării contului.
• CREATE/0xF0 , CREATE2/0xF5 și SELFDESTRUCT/0xFF : Aceste coduri operaționale permit în mod extensiv apelantului să creeze un cont nou. Accesul la acestea este restricționat pentru a preveni alterarea nonce-ului unui EOA într-un cadru de execuție diferit (crearea/distrugerea contractului în acest caz) în timp ce acesta efectuează o tranzacție EIP-5806, pentru a preveni invalidarea așteptării că tranzacțiile poartă nonce consecutive.

Aplicații potențiale ale EIP-5806

Aplicabilitatea principală a EIP-5806 este abstractizarea execuției pentru EOA. Permițând EOA să interacționeze fără încredere cu contractele inteligente, dincolo de simple apeluri la logica lor, le oferă caracteristici precum:

• Executarea condiționată a tranzacțiilor
• Loturi de tranzacții
• Tranzacții cu mai multe apeluri (de exemplu, aprobarea și apelarea)

Critici la adresa EIP-5806

Modificările propuse de EIP-5806, deși permit funcțiile necesare, nu sunt deosebit de noi; existența sa se bazează în mare parte pe un EIP-7 deja funcțional. Acest lucru îi permite să ocolească multe obstacole potențiale în calea acceptării.

Una dintre preocupările majore exprimate la începuturile sale a fost riscul potențial de a permite EOA să acceseze spațiul de stocare și să îl schimbe, la fel cum fac în prezent CA-urile. Acest lucru înlătură o mulțime de invarianți consacrate în rețea cu privire la modul în care trebuie să tranzacționeze EOA, și astfel a fost rezolvat prin introducerea restricțiilor menționate în subsecțiunea anterioară.

O a doua critică (care este un pic o sabie cu două tăișuri) este simplitatea EIP-5806; există un sentiment că recompensele datorate acceptării EIP-5806 ar putea să nu merite costul, deoarece permite doar abstractizarea execuției și nu multe altele. Orice altă restricție de valabilitate rămâne definită de rețea pentru EOA care optează pentru EIP-5806, spre deosebire de alte EIP oarecum similare pe care le discutăm în următoarele subsecțiuni.

Programabilitate prin EIP-3074

EIP-3074 propune să permită EOA să delege cea mai mare parte a logicii lor de validare conturilor contractuale specializate, denumite invocatori, prin suprapunerea logicii de autorizare a acestora din urmă peste a lor pentru forme specifice de tranzacții. Acesta realizează acest lucru prin semnarea politicii lor de acces la un contract invocator, care apoi devine responsabil pentru definirea politicii de acces a EOA.

Acest EIP propune adăugarea a două coduri operaționale noi la EVM:

• [AUTH] care setează un cont [autorizat] cu variabile de context să acționeze în numele unui al doilea cont [de autoritate], pe baza semnăturii ECDSA a acestuia din urmă.
• [AUTHCALL] care trimite/implementează apeluri pentru contul [autoritate] din/ca cont [autorizat].

Aceste două coduri operaționale permit unui EOA să delege controlul unui CA prestabilit și, astfel, să acționeze ca unul singur prin intermediul acestuia, fără a fi nevoie să implementeze un contract și să suporte costurile și externalitățile asociate cu acesta.

Specificațiile EIP-3074

EIP-3074 permite tranzacțiilor să utilizeze un format de semnare [MAGIC] pentru a preveni coliziunile cu alte formate de semnare a tranzacțiilor. Contul activ la care sunt transmise instrucțiunile [AUTHCALL] este definit ca un câmp variabil de context numit [autorizat], care persistă doar printr-o singură tranzacție și trebuie redefinit pentru fiecare nou [AUTHCALL] .

Înainte de a aborda complexitățile fiecărui cod operațional, acestea sunt entitățile implicate într-o tranzacție EIP-3074:

• [autoritate] : contul de semnare principal (un EOA) care delegă accesul/controlul unui al doilea cont, care este de obicei un cont contractual.
• [autorizat] : contul către care urmează să fie transmise instrucțiunile [AUTHCALL] pentru execuție. Cu alte cuvinte, este contul în care logica unui [AUTHCALL] este executată, în numele [autorității], folosind constrângerile definite de un [invocator].
• [invocator] : Un contract subsidiar menit să gestioneze interacțiunile dintre contul [autorizat] și logica [AUTHCALL] , mai ales în cazurile în care logica principală a codului de contract al acestuia din urmă este sponsorizarea gazelor.

Contractele invocatoare primesc mesaje [AUTH] cu o valoare [COMMIT] de la [autoritate]; această valoare definește restricțiile pe care contul dorește să le pună asupra execuției de către [autorizat] a instrucțiunilor [AUTHCALL] . Astfel, invocatorii sunt responsabili pentru a se asigura că [ contract_code ] definit într-un cont [autorizat] nu este rău intenționat și are capacitatea de a satisface invarianții plasați de contul de semnare principal într-o valoare [COMMIT].

Codul operațional [AUTH] are trei intrări pentru elemente de stivă; sau mai simplu - este definit de trei intrări care calculează o singură ieșire. Aceste intrări sunt:

1. autoritate : care este adresa EOA care generează semnătura
2. offset
3. lungime

Ultimele două intrări sunt folosite pentru a descrie un interval de memorie modificabilă de la 0 la 97, unde:

1. [memory(offset : offset+1)] – [yParity]
2. [memory(offset+1 : offset+33] – [r]
3. [memory(offset+33 : offset+65)] – [s]
4. [memory(offset+65 : offset+97)] – [COMMIT]

Variabilele [yParity], [r] și [s] sunt interpretate colectiv ca o semnătură ECDSA, [magic], pe curba secp256k1 peste mesaj:

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

unde:

• [MAGIC] este o semnătură ECDSA rezultată din combinarea variabilelor:
• [chainID], care este identificatorul compatibil cu EIP 115 al lanțului actual, utilizat pentru a oferi protecție împotriva atacurilor de reluare pe lanțuri EVM alternative cu un istoric similar și o securitate economică mai mică.
• [nonce] care este adresa semnatarului tranzacției actuale nonce, completată la stânga la 32 de octeți.
• [invokerAddress] care este adresa contractului care conține logica pentru executarea [AUTH] .
• [COMMIT] este o valoare de 32 de octeți utilizată pentru a specifica condiții suplimentare de valabilitate a tranzacției în logica de preprocesare a invocatorului.

Dacă semnătura calculată este validă și adresa semnatarului este egală cu [autoritate], câmpul [autorizat] este actualizat la valoarea furnizată de [autoritate]. Dacă oricare dintre aceste cerințe nu este îndeplinită, câmpul [autorizat] rămâne neschimbat în starea anterioară sau ca valoare nesetată.

Costul gazului pentru acest opcode este calculat ca suma:

1. O taxă fixă pentru precompilarea [ecrecover] și suplimentar pentru un hash keccak256 și ceva logică suplimentară, evaluată la 3100 de unități

2. O taxă de extindere a memoriei care este calculată în mod similar cu codul operațional [RETURN] și aplicată atunci când memoria este extinsă peste intervalul specificat al alocării curente (97 de unități)

3. Un cost fix de 100 de unități suportate pentru o [autoritate] caldă și 2600 de unități pentru una rece pentru a preveni atacurile din cauza prețurilor greșite ale codurilor operaționale care accesează de stat.

   
   

   ( AUTH este implementat pentru a nu modifica memoria și ia valoarea [authority] ca argument, astfel încât este trivial să verifici valoarea acesteia din semnătura furnizată.)

Codul operațional [AUTHCALL] are șapte intrări de elemente de stivă care sunt utilizate pentru a calcula o ieșire a unui singur element de stivă.

Are aceeași logică ca și opcode-ul [CALL] , adică; este folosit pentru a trimite mesaje-apeluri într-un cont și pentru a declanșa o logică specifică în contractele sale. Singura abatere în logica lor este că [AUTHCALL] este conceput pentru a seta valoarea [CALLER] înainte de a continua cu execuția.

Astfel, [AUTHCALL] este utilizat de către [autoritate] pentru a declanșa un comportament specific contextului în [autorizat], verificările logice procedând după cum urmează:

1. Verificați valoarea lui [autorizat]. Dacă nu se setează, execuția este considerată invalidă și cadrul este imediat părăsit. Acest lucru ajută la prevenirea taxelor neloiale din cauza eșecurilor fără precedent.
2. Verifică costul de gaz al comportamentului preconizat al [autorizat].
3. Verifică valoarea conformă EIP-150 a operandului [gaz].
4. Verifică disponibilitatea costului total al gazelor –[valoare]– în soldul [autorității].
5. Executarea are loc după deducerea [valorii] din soldul contului [autorității]. Dacă [valoarea] este mai mare decât soldul lor, execuția este invalidată.

Costul gazului pentru [AUTHCALL] este calculat ca suma:

• Un cost fix pentru apelarea [warm_storage_read]
• Un cost de extindere a memoriei [memory_expansion_fee] , care este calculat în mod similar costului de gaz pentru codul operațional [CALL]
• Un cost dinamic [dynamic_gas]
• Costul de execuție al subapelului [subcall_gas]

Datele returnate de la o [AUTHCALL] sunt accesate prin:

• [RETURNDATASIZE] – care împinge dimensiunea buffer-ului de date returnate în stiva de ieșire
• [RETURNDATACOPY] – care copiază datele din bufferul de date returnate în memorie.

Pentru a aduce totul împreună cu mult mai puțin vorbire tehnologică; Tranzacțiile Ethereum specifică de obicei două valori:

1. tx.origin – care oferă autorizarea tranzacției.
2. msg.sender – în care tranzacția are loc efectiv.

În EOA, așa cum sa menționat anterior, autorizarea este strâns cuplată cu execuția, adică ( tx.origin == msg.sender ). Acest simplu invariant dă naștere la majoritatea problemelor pe care le-am explicat în subsecțiunea „Conturi și Valabilitatea tranzacțiilor” a acestui raport.

Mesajele [AUTH] de la [authority] îi permit să compenseze funcția tx.origin la [authorized], rămânând în același timp msg.sender. De asemenea, îi permite să definească restricții la acest privilegiu folosind o valoare [COMMIT]. [AUTHCALL] permite apoi [autorizat] să acceseze logica unui contract, folosind un [invocator] ca intermediar pentru a se asigura că contractul pe care dorește să îl acceseze este inofensiv. Adică, pentru fiecare [AUTHCALL] , [autorizat] trebuie să specifice un anumit [invocator] pentru [COMMIT].

Aplicații potențiale ale EIP-3074

EIP 3074 este în primul rând responsabil pentru a permite EOA să-și delege logica de autorizare către un cont diferit, cu toate acestea, designul său deschis permite mult mai multe în contexte diferite. Întreaga logică de validare a unui EOA poate fi abstractizată prin aplicarea diferitelor constrângeri/inovații la invocator, după cum este necesar, unele dintre modelele posibile bazate pe logica țintă includ:

• Logica nonce : EIP-3074 permite ca nonce EOA să rămână neatins după trimiterea unui mesaj [AUTH] , în timp ce nonce pentru fiecare [AUTHCALL] depinde de invocatorul cu care interacționează. În acest fel, permite paralelismul nonce pentru EOA, astfel încât acestea să poată trimite mai multe [AUTHCALL] care nu se suprapun după cum doresc.
• Logica de plată a gazelor : așa cum este specificat în EIP, invocatorii pot fi proiectați pentru a permite sponsorizarea gazelor. Ca atare, taxele de gaz pentru [COMMIT]ul unui utilizator ar putea fi deduse din originea tranzacției sau din orice cont de sprijin, fie unul personal sau un releu bazat pe servicii (servicii de sponsorizare a gazelor). De asemenea, logica de execuție este abstractizată intuitiv; la urma urmei, invocatorul (care este un CA) este acum responsabil pentru executarea cererilor de tranzacție în numele EOA.

Critici la adresa EIP-3074

Centralizarea invocatorului

Citând unul dintre autorii săi: „ Nu m-aș aștepta ca portofelele să expună funcționalitatea de a semna invocatori arbitrari... ”. Poate cea mai mare problemă pusă la cale de inițiativa 3074 este că inovația de deasupra va tinde foarte ușor către fluxuri de tranzacții autorizate și proprietare; la fel ca iterațiile actuale ale piețelor Ethereum MEV (valoare maximă extractabilă) și PBS (separarea propunere-constructor).

În mod implicit, contractele invocatoare trebuie să fie auditate în mare măsură pentru a preveni atacuri și mai grave decât sunt posibile în prezent. Acest lucru va tinde inevitabil către un ecosistem în care doar o mână de contracte invocatoare dezvoltate de figuri influente vor fi adoptate ca standard pentru dezvoltatorii de portofel. Astfel, se rezumă la un compromis între:

• Luând calea descentralizată a auditării și susținerii în mod constant a contractelor invocatoare, cu riscul securității utilizatorilor
• Adoptarea de contracte invocatoare din surse stabilite și de renume, cu garanții mai bune pentru securitatea utilizatorilor și mai puțină supraveghere a siguranței contractului.

Un alt aspect al acestui punct este funcția de cost asociată cu proiectarea, auditarea și comercializarea unui invocator funcțional și sigur. Echipele mai mici vor fi aproape întotdeauna depășite de organizațiile mai mari – în special pe frontul de marketing – care au deja o reputație consolidată, chiar dacă produsul lor este mai bun.

Probleme de compatibilitate înainte

EIP-3074 consolidează schema de semnătură ECDSA, deoarece este încă considerată mai valabilă decât schema de autorizare introdusă prin intermediul invocatorului. Deși există argumente că rezistența cuantică nu este în prezent o problemă definitivă (și că este mult mai rău în joc într-un viitor în care ECDSA este coruptibil), scopul oarecum nedeclarat al Ethereum este să fie mereu în fața unor astfel de probleme. Sacrificiul potențial al rezistenței cuantice și la cenzură pentru îmbunătățiri marginale în UX ar putea să nu fie cea mai bună alegere în viitorul apropiat.

Un alt punct al argumentului compatibilității înainte este că, în timp ce beneficiile lui 3074 erau încă evaluate, ERC-4337 (care nu necesită nicio modificare a protocolului) are acum o piață grozavă, așa că trebuie să fii compatibil și cu el pentru a evita compartimentarea ecosistemelor. Chiar și cu foaia de parcurs de abstracție a contului nativ, codurile operaționale [AUTH] și [AUTHCALL] ar deveni în cele din urmă învechite în EVM, introducând o mare cantitate de datorii tehnice către Ethereum pentru a oferi o cantitate marginală de îmbunătățire a UX.

Irevocabilitatea schemei ECDSA

După trimiterea unui mesaj [AUTH] și delegarea controlului, se așteaptă ca EOA să evite schema obișnuită de autorizare a cheii private, deoarece trimiterea unei tranzacții „normale” face ca autorizația pe care a delegat-o fiecărui invocator să fie revocată. Astfel, schema ECDSA rămâne strict superioară oricărei alte scheme de autorizare pe care contractele asociate o pot permite, ceea ce înseamnă că o pierdere a cheilor private ar duce la o pierdere totală a activelor contului.

Programabilitate prin EIP-7702

Această propunere a fost inițial o variantă oarecum minimalistă a EIP 3074 și chiar a fost menită să fie o actualizare a acestuia. A fost născut pentru a aborda presupusele ineficiențe ale EIP 3074, în special preocupările legate de incompatibilitatea acestuia cu ecosistemul deja înfloritor 4337 și propunerea de abstracție a contului nativ – RIP 7560.

Abordarea sa este adăugarea unui nou tip de tranzacție compatibil EIP 2718 – [SET_CODE_TX_TYPE] – care permite unui EOA să se comporte ca un cont inteligent pentru tranzacții specificate. Acest design permite aceleași caracteristici ca EIP 5806 și altele, rămânând în același timp compatibil cu foaia de parcurs de abstractizare a contului nativ și inițiativele existente.

Specificațiile EIP-7702

EIP-7702 permite unui EOA să „importe” conținutul codului unui contract printr-o tranzacție conformă cu [SET_CODE_TX_TYPE] 2718 în formatul:

 rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Această sarcină utilă este complet similară cu cea a EIP 5806, cu excepția faptului că introduce o „listă de autorizare”. Această listă este o secvență ordonată de valori de format:

[[chain_id, address, nonce, y_parity, r, s], ...]

unde fiecare tuplu definește valoarea [adresei].

Înainte de a continua, părțile implicate într-un SET_CODE_TX_TYPE sunt:

• [autoritate] : care este EOA/contul de semnare principal
• [adresă] : care este adresa unui cont care conține cod delegabil.

Când [autoritatea] semnează un SET_CODE_TX_TYPE care specifică [adresă], este creat un desemnator de delegare. Acesta este un „program pointer” care face ca toate cererile de recuperare de cod datorate acțiunilor [autorității] în orice moment să fie canalizate către codul observabil al [adresei].

Pentru fiecare tuplu [chain_id, address, nonce, y_parity, r, s] , fluxul logic al unei tranzacții de tip 7702 este următorul:

1. Verificarea semnăturii [autorității] din hash-ul furnizat folosind: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Prevenirea atacurilor de reluare încrucișată și a altor vectori de atac prin verificarea ID-ului lanțului.
3. Se verifică dacă [autoritatea] are deja conținut de cod.
4. Verificați nonce pentru a vă asigura că nonceul [autorității] este egal cu nonceul inclus în tuplu.
5. Dacă tranzacția este prima tranzacție SET_CODE_TX_TYPE a [autorității], se percepe o taxă PER_EMPTY_ACCOUNT_COST . În cazul în care soldul acestuia este mai mic decât valoarea acestei taxe, operațiunea este abandonată.
6. Are loc desemnarea delegației, în care codul [autorității] este setat la un indicator al [adresei].
7. Nonceul semnatarului –[autoritatea]– se majorează cu unu.
8. [autoritatea] se adaugă la o listă de adrese accesate, care (supra-simplificat) este un set de adrese care sunt realizate astfel încât revenirea unui domeniu al unei tranzacții de la acestea să facă ca acestea (adresa) să fie restabilite la starea lor anterioară , înainte ca domeniul de aplicare invers să fie introdus. Acest lucru este definit în EIP-2929 pentru a permite stocarea în cache a valorilor reutilizabile și pentru a preveni taxele inutile.

Pf! Pentru a lega totul înapoi; acest EIP permite EOA să trimită tranzacții care setează un pointer către codul unui contract, permițându-le să implementeze această logică ca proprie în tranzacțiile ulterioare. În acest fel, este strict mai puternic decât EIP 5806, deoarece permite EOA-urilor să aibă de fapt conținut de cod atâta timp cât doresc (spre deosebire de EIP 5806 care permite pur și simplu EOA-urilor să trimită apeluri de delegat).

Aplicații potențiale ale EIP-7702

Abstracția execuției

Deși s-ar putea argumenta că nu mai este o abstractizare, deoarece EOA preia în mod activ logica pe care dorește să o execute, totuși nu este „proprietarul principal” al logicii menționate. De asemenea, nu conține direct logică, pur și simplu specifică un pointer către logică (pentru a reduce complexitatea de calcul). Deci mergem cu abstractizarea execuției!

Sponsorizarea gazelor

În timp ce invariantul require(msg.sender == tx.origin) este întrerupt pentru a permite auto-sponsorizarea, EIP permite în continuare integrările de relee de tranzacții sponsorizate. Cu toate acestea, avertismentul este că astfel de relee au nevoie de un sistem bazat pe reputație sau miză pentru a preveni atacurile de doliu.

Politici de acces condiționat

EOA pot indica doar o anumită porțiune a codului contului, astfel încât doar logica acelei porțiuni să fie executabilă în contextul lor.

Acest lucru permite, de asemenea, existența unor subchei care continuă să permită „de-escaladarea privilegiilor”, astfel încât anumite dapps să aibă acces la soldul unui cont doar în condiții specifice. De exemplu, vă puteți imagina o permisiune de a cheltui jetoane ERC-20, dar nu ETH, sau de a cheltui până la 1% din soldul total pe zi sau de a interacționa doar cu o anumită aplicație.

Implementarea unui contract inteligent încrucișat

Datorită naturii sale nerestrictive, o tranzacție EIP-7702 ar putea permite unui utilizator să acceseze codul operațional CREATE2 și să-l folosească pentru a implementa codul octet către o adresă fără alți parametri restrictivi, cum ar fi logica pieței de taxe (de exemplu, EIP-1559 și EIP-4844). ). Acest lucru permite ca adresa să fie recuperată și utilizată pe mai multe mașini de stat, cu același bytecode, unde contul său de pe fiecare lanț este apoi responsabil pentru definirea celorlalți parametri variabili de context.

Critici la adresa EIP-7702

Lipsa de compatibilitate inversă

Deși EIP-7702 este încă foarte recent, au existat deja multe prototipuri și teste pentru dependențele și potențialele dezavantaje, dar modelul său minimalist îi garantează multă flexibilitate și, prin urmare, utilitate, în diferite contexte. Cu toate acestea, rupe mult prea multe invariante și nu este imediat compatibil cu înapoi. Unele dintre logica EIP-7702 includ:

1. Modificare EOA la mijlocul tranzacției: EIP-7702 nu limitează niciun cod operațional pentru a asigura coerența. Aceasta înseamnă că un EOA poate implementa coduri operaționale precum CREATE , CREATE2 și SSTORE în timp ce execută o tranzacție EIP-7702, permițând creșterea nonce-ului într-un context diferit.
2. Permiterea conturilor cu o valoare codeHash diferită de zero să fie inițiatoare de tranzacții: EIP-3607 a fost implementat pentru a reduce potențiala consecință a unei „coliziune de adrese” între EOA și CA. O coliziune de adrese are loc atunci când valoarea de 160 de biți a adresei unui EOA este complet echivalentă cu cea a adresei unui CA.

Majoritatea utilizatorilor nu cunosc conținutul propriu-zis al unui cont (sau chiar diferența dintre un cont și o adresă!), așa că permiterea coliziunilor de adrese înseamnă că un EOA s-ar putea masca ca un cont contractual și ar putea atrage fonduri ale utilizatorilor într-un mod lung. puțin pentru a le fura în cele din urmă pe toate. EIP-3607 a abordat acest lucru stipulând că conturile care conțin cod nu ar trebui să își poată cheltui soldul folosind propria logică de autorizare. Cu toate acestea, EIP 7702 întrerupe acest invariant pentru a permite EOA-urilor să rămână autonome chiar și după ce au câștigat o anumită programabilitate.

Asemanare cu EIP-3074

Semnarea adresei unui cont în loc de conținutul codului acestuia este practic la fel ca schema lui 3074 cu invocatori. Nu oferă garanții stricte în ceea ce privește consistența conținutului codului încrucișat, deoarece o adresă poate prelua un conținut de cod diferit pe lanțuri diferite. Aceasta înseamnă că o adresă al cărei conținut de cod conține aceeași logică pe un lanț ar putea fi de pradă sau complet rău intenționată pe un alt lanț, iar acest lucru ar putea duce la pierderea fondurilor utilizatorilor.

Concluzie

EOA în forma lor actuală sunt foarte limitate, deoarece nu permit utilizatorilor să profite de caracteristicile de programabilitate oferite de EVM. Deși există diverse căi de actualizare a conturilor, așa cum am subliniat la începutul acestui raport, soluția aleasă trebuie să mențină principiile auto-custoderii în siguranță. În plus, upgrade-urile EOA pot avea un impact semnificativ atât asupra experienței utilizatorului, cât și asupra dezvoltatorilor de aplicații, astfel încât toate vocile părților interesate trebuie luate în considerare.

Permiterea EOA-urilor să execute cod în orice mod extinde enorm funcționalitatea conturilor, dar această nouă expresibilitate vine cu riscuri semnificative și posibile abateri. Rezolvarea acestor compromisuri este esențială pentru a oferi un upgrade cu beneficii UX de necontestat pentru utilizatorii Ethereum.

Cultura Ethereum a discuțiilor deschise îl face un teren de testare excelent pentru astfel de inovații, deoarece aproape fiecare implicație a fiecărui design este complet deconstruită de experții în domeniu. Această considerație cuprinzătoare ar trebui să contribuie la atenuarea riscurilor de abuz din partea adversarilor.

EIP-7702 este în prezent modelul pentru mecanismele care încearcă să aducă programabilitate EVM la EOA, fiind marcat ca înlocuitor pentru slotul EIP 3074 în upgrade-ul Pectra. Moștenește designul deschis al mecanismului lui 3074 în timp ce scade foarte mult suprafața/riscurile de atac. De asemenea, permite mult mai mult prin evitarea restricțiilor 3074 la anumite clase de coduri operaționale.

Deși există încă unele îmbunătățiri în ceea ce privește designul propunerii, aceasta a strâns deja multă bunăvoință și sprijin din partea dezvoltatorilor, mai ales că îl sprijină direct Vitalik. În cadrul comunității, există pretenții că această abordare a abstracției conturilor ar putea fi chiar mai bună decât conturile inteligente. Acest comentariu subliniază că această cale necesită mai puține modificări și nu este la fel de complexă și că EOA sunt deja consacrate.

Cu toate acestea, trebuie să ne amintim viitorul reper de securitate al rezistenței cuantice la fiecare nivel al rețelei Ethereum. Această siguranță cuantică este imposibilă cu nucleul modelului de cont curent din cauza utilizării schemelor de semnătură bazate pe ECDSA pentru autorizarea EOA.

Astfel, programabilitatea EOA trebuie văzută ca un pas pe calea către conturile inteligente și nu ca destinație. Supraalimentează EOA și permite o experiență mai bună pentru utilizatori și dezvoltatori, rămânând în același timp compatibil cu obiectivul final de abstracție a contului al conturilor inteligente.

În următorul nostru raport, ne vom scufunda în schemele de migrare EOA pentru a vedea cât de bine se încadrează în foaia de parcurs de abstracție a contului, rămâneți pe fază!