Kartering van die Ethereum-rekening Abstraksie Padkaart I: EIP-3074, EIP-5806 en EIP-7702

Nadat ons die beduidende veranderinge waargeneem het wat deur die Deneb-opgradering aan Ethereum ingestel is, het ons begin kyk na wat die volgende hardevurk, Pectra, sal bekendstel. Om die komende besprekings te help vorm, poog ons om die huidige landskap van rekeningabstraksie rondom Ethereum en sy oprol-ekosisteem te beskryf om moontlik 'n duidelike pad vorentoe te karteer.

Hierdie verslag bied 'n oorsig van Ethereum se lopende rekeningmodel, veral hul uitwerking op transaksiegeldigheid, wat presies rekeningabstraksie behels, en 'n raamwerk om daaroor te redeneer. Ons sal dan fokus op die EOA-programmeerbaarheidsbenadering deur EIP's 5086, 3074 en 7702 te evalueer, en afsluit met hoe dit alles waarskynlik die toekoms van transaksies op Ethereum beïnvloed.

Alhoewel daar baie verwarring is oor wat rekeningabstraksie is of nie, is ons raamwerk deur hierdie reeks dat enige meganisme wat 'n rekening toelaat om enige gedeelte van sy geldigheidsreëls te herdefinieer, 'n meganisme vir rekeningabstraksie is. Verder verskaf ons 'n klassifikasie van hierdie meganismes, aangesien die meeste van hulle vaagweg eenders is en oorvleuel.

'N Oorsig van rekeningabstraksie in Ethereum

Rekeningabstraksie poog om gebruikers- en ontwikkelaarervarings oor die hele Ethereum-ekosisteem te verbeter. Saam met die maak van on-chain-ervarings meer toeganklik en aangenaam vir gebruikers, bemagtig dit ook ontwikkelaars om kragtiger dinge op Ethereum te kan doen en gebruikers op selfs meer betekenisvolle maniere te bedien.

Ons klassifikasie van die benaderings tot rekeningabstraksie is soos volg:

1. EOA-verbetering/programmeerbaarheid : Dit sluit protokolvlakveranderings in wat EOA's (Ekstern Besit Rekeninge) in staat stel om die uitvoeringslogika-gedeelte van hul geldigheidsreëls te herdefinieer. Soos bekend binne die ontwikkelingsgemeenskap, is EOA's rekeninge wat tipies met eindgebruikers geassosieer word. Daarom sal oplossings wat binne hierdie benadering val eindgebruikerrekeninge bemagtig met meer beheer oor watter soort aksies hulle kan magtig, in vergelyking met hoe dit vandag bestuur kan word.

2. EOA-omskakeling/migrasie : Hierdie benadering sluit voorstelle in wat die volledige omskakeling van EOA's na GR'e (kontrakrekeninge) beoog. Die integrale idee van hierdie benadering is dat kontrakrekeninge reeds die meeste van die voordele bied wat deur slim rekeninge gebied word, so dit behoort nie meer nodig te wees om dinge te kompliseer nie; almal moet bloot 'n kontrakrekening as hul primêre rekening gebruik (deur slim kontrakbeursies).

Hierdie benadering beskik oor meganismes wat 'n EOA toelaat om na 'n GR oor te skakel, sonder om sy bates te skuif, soos EIP 7377 en EIP 5003 (wanneer dit saam met EIP 3074 oorweeg word).

3. Slim rekeninge : Hierdie groep voorstelle sluit ontwerpe in wat beide EOA's en CA's in staat stel om as "slim rekeninge" op te tree deur hulle in staat te stel om hul geldigheidsreëls heeltemal te herdefinieer.

Verskeie voorstelle is voorheen gemaak vir die skep van slim rekeninge en rekeningabstraksieverskansing op protokolvlak; EIP-86 en EIP-2938 is van die meer aangehaalde. Daar was egter baie terugslag as gevolg van die waargenome kompleksiteit wat deur hierdie ontwerp ingestel is en die ietwat meerderheidsmening dat Ethereum nie gereed is vir sulke kompleksiteit nie.

Na Vitalik se herlewing van die onderwerp na The Merge, is ERC-4337 voorgestel as 'n opt-in weergawe van die slim rekeningstandaard, soortgelyk aan die PBS (Proposer-Builder Separation) infrastruktuur vir MEV (Maximal Extractable Value). Gebruikers wat dus toegang tot die voordele van slim rekeninge wil verkry, kan eenvoudig die ERC-4337-pyplyn gebruik om hul rekening se logika en transaksies se geldigheidsreëls te herdefinieer in strukture waarna verwys word as 'n UserOperation (of UserOps vir kort).

ERC 4337 bring die voordele van slim rekeninge na die hedendaagse Ethereum sonder om enige van die kompleksiteit te verskans, deur te funksioneer as 'n buite-protokol-alternatief vir verskanste slim rekeninge. Dit beteken egter nie dat die infrastruktuur optimaal is in sy huidige toestand nie, aangesien sy eie kompleksiteit steeds 'n aansienlike punt van mislukking is.

Om hierdie kompleksiteit aan te spreek, is RIP 7560 opgestel as 'n verskanste weergawe van die ERC 4337-infrastruktuur oor Ethereum en sy L2's, sodat dit die netwerk se sibil-weerstandskemas erf eerder as om 'n nuwe reeks reëls te definieer (soos ERC 4337 doen met ERC 7562 ).

In hierdie verslag sal ons gefokus wees op die verkenning van EOA-programmeerbaarheid, die evaluering van die verskillende EIP's wat oplossings volgens hierdie lyn beskryf en hul meriete en nadele bespreek. In Deel 2 en 3 van hierdie reeks sal ons die oorblywende twee klasse van benadering tot rekeningabstraksie dek wat binne Ethereum ondersoek word.

'N Beginsel oor Ethereum-rekeninge en -transaksies

Om uit te vind wat geabstraheer kan word, benodig ons 'n (ietwat) volledige prentjie van die lopende rekeningontwerp. Hierdie afdeling sal meestal dien as 'n hersiening van soorte vir wat rekeninge op Ethereum eintlik is, en hoe hul transaksies bekragtig en uitgevoer word.

Ethereum-rekeninge is entiteite met 'n eter (ETH) balans en die vermoë om transaksies op die Ethereum blockchain te stuur. Hulle word voorgestel as 'n 42-karakter heksadesimale "adres", wat dien as 'n unieke wyser na die rekening se besit en transaksies.

'n Adres dien as 'n sleutel in die blokketting se staatsdrie. Die blaarknope van hierdie drie is rekeningdatastrukture wat in vier velde ontbind kan word:

1. nonce : 'n Lineêre teller wat gebruik word om die aantal uitgaande transaksies aan te dui wat deur 'n rekening geïnisieer is. Dit is ook van kardinale belang om herhalingsaanvalle te voorkom.
2. balance : Die wei-gedenomineerde hoeveelheid eter (ETH) wat deur 'n rekening besit word.
3. codeHash : 'n Hash van die EVM-uitvoerbare kode wat in 'n rekening vervat is. Die EVM (Ethereum Virtual Machine) is Ethereum se pasgemaakte uitvoeringsomgewing wat verantwoordelik is vir die hantering van komplekse staatsoorgange verder as eenvoudige "stuur"-transaksies. Die kode-inhoud van 'n rekening is onveranderlik geprogrammeer om spesifieke vorme van staatsoorgang op die Ethereum-blokketting uit te voer deur die EVM.
4. storageHash : 'n Hash van 'n rekening se stoorwortel, wat gebruik word om die stoorinhoud van 'n rekening voor te stel as 'n 256-bis hash van 'n merkle patricia trie se wortelnode. Eenvoudig, dit is 'n hash van die toestand-veranderlike data wat verband hou met 'n rekening se kode-inhoud.

Die inhoud van hierdie vier velde word gebruik om 'n rekening se tipe te definieer, en gaan uiteindelik voort om die omvang van sy funksionaliteite te definieer. Dus, die twee tipes Ethereum-rekeninge is:

1. Rekeninge in eksterne besit (EOA's) - wat geïnisialiseer word as 'n kriptografiese sleutelpaar:

• 'n Privaat sleutel wat 'n enkripteerbare en bewysbaar ewekansige 64-hex karakter is, en sy komplementêre eweknie;
• 'n Publieke sleutel wat afgelei is van die private sleutel met behulp van die ECDSA (Elliptic Curve Digital Signature Algorithm).

EOA's het leë codeHash- en storageHash-velde en kan slegs beheer word deur enigiemand wat die private sleutels besit. Hul adresse kan van die ooreenstemmende publieke sleutel verkry word deur "0x" voor te sit by die laaste twintig karakters van die rekening se publieke sleutel se keccak-256 hash.

2. Kontrakrekeninge (CA's) wat slegs deur 'n voorafbestaande EOA geskep kan word. Hulle word geïnisialiseer as gevolg van 'n EOA wat uitvoerbare kode-inhoud op die EVM ontplooi. Hierdie kode-inhoud (geberg as die codeHash) is vasgelê in die EVM, en is verantwoordelik vir die beheer van die rekening deur die logika en interaksies daarvan te definieer.

Transaksies vanaf kontrakrekening is geheel en al trek-gebaseerde gebaseer op hul ontplooide kode se logika. Aangesien hierdie rekeninge slegs deur hul kode-inhoud beheer kan word, het hulle geen behoefte aan 'n private sleutel nie en het slegs 'n publieke sleutel. Dus, enige agent wat die vermoë het om 'n kontrakrekening se kode-inhoud op te dateer/verander, sal toegang tot sy balans hê. Die adres van 'n kontrakrekening is afgelei van die skepper se adres en sy nie-tyd tot die punt van die kontrak se ontplooiing.

Transaksies

Ons het onlangs rekeninge beskryf as entiteite wat die vermoë het om transaksies oor Ethereum te stuur. Ons kan dus verstaan dat 'n primêre doel van 'n rekening is om transaksies te stuur en te ontvang, terwyl die blokketting dien as 'n grootboek-aantekeninggeskiedenis van transaksies sowel as om te beskryf hoe transaksies rekeningvelde verander gebaseer op reëls wat in die blokkettingprotokolspesifikasie beskryf word.

So wat is hierdie "transaksies"?

Transaksies is bedrywighede wat vanaf 'n rekening gestuur word, wat 'n verandering in die "toestand" van die netwerk veroorsaak. Dit is kriptografies ondertekende instruksies van rekeninge, wat lei tot 'n netwerkwye staatsopdatering wanneer dit uitgevoer word.

Toestemmingloosheid kom met die koste van perverse aansporings, om dit te hanteer, moet streng riglyne (of geldigheidsreëls) gedefinieer word vir interaksies in sulke omgewings. In hierdie konteks moet transaksies sekere geldigheidsreëls volg om as geldig beskou en uitgevoer te word. Die meeste van hierdie geldigheidsreëls word geïmplementeer via beperkings wat op die rekening geplaas word wat die transaksie stuur, en wissel na gelang van watter tipe rekening dit is.

Rekeninge en transaksiegeldigheid

Op Ethereum is EOA's geoptimaliseer vir bruikbaarheid aangesien dit eindgebruiker in die gesig staar. Hulle het die vermoë om transaksies op 'n spesifieke manier te stuur en funksioneer perfek outonoom. Hulle kan ook plaaslik geskep word, die meer algemene metode is die gebruik van beursieverskaffers soos MetaMask, Rainbow, Rabby ens.

Aan die ander kant kan kontrakrekeninge slegs transaksies stuur wat deur hul logika toegelaat word, in reaksie op ' oproep '. Hulle kan ook slegs geskep word deur 'n EOA wat 'n voldoende balans het om vir sy staatsberging te betaal.

'n Meer hoëvlak beskrywing sou wees dat EOA's slegs 'n balans kan hou, terwyl GR'e beide 'n balans en logika kan hou wat bepaal hoe hierdie balans bestee kan word. Hierdie eienskappe is te danke aan die volgende logiese parameters wat die reëls definieer waaraan 'n rekening se transaksies moet voldoen:

1. Stawingslogika - Word gebruik om te definieer hoe 'n rekening sy identiteit aan die netwerk bewys terwyl sy balans en/of logika verander word.
2. Magtigingslogika - Word gebruik om 'n rekening se toegangsbeleid te definieer, dit wil sê wie in staat is om toegang te verkry en veranderinge aan die rekening se balans en/of logika aan te bring.
3. Nonce logic - wat die volgorde definieer waarin transaksies vanaf 'n rekening uitgevoer moet word.
4. Gasbetalingslogika - Word gebruik om die party te definieer wat verantwoordelik is vir die vereffening van 'n transaksie se gasfooi.
5. Uitvoeringslogika - Word gebruik om te definieer watter vorme van transaksies 'n rekening kan stuur, of hoe 'n transaksie uitgevoer moet word.

Hierdie parameters is ontwerp om rigied te wees vir EOA's, so:

• Stawing en magtiging word verskaf deur 'n ECDSA-gebaseerde private sleutel, dit wil sê, 'n gebruiker wat 'n transaksie vanaf hul EOA wil stuur, moet hul private sleutel gebruik om toegang tot die rekening te verkry en sodoende bewys dat hulle die reg het om enige veranderinge aan sy balans aan te bring .
• Die nonce-logika implementeer 'n opeenvolgende tellerskema, wat toelaat dat slegs een transaksie per unieke nonce opeenvolgend per rekening uitgevoer kan word.
• Gasbetalingslogika spesifiseer dat die gasfooi vir transaksies deur die sender/oorsprongrekening vereffen moet word.
• Uitvoeringslogika spesifiseer dat EOA's slegs die volgende transaksievorms kan stuur:

1. Gereelde oordragte tussen twee EOA's.
2. Kontrak ontplooiing.
3. kontrakoproepe wat 'n ontplooide kontrakrekening se logika teiken.

Meer algemeen beperk die uitvoeringslogika van EOA's hulle tot een transaksie per geldige handtekening.

Aan die ander kant het CA's meer buigsaamheid rondom hierdie parameters:

• Stawing is nie nodig nie, aangesien hul transaksies gevolglik/trekgebaseer van aard is.
• Magtiging vir GR'e kan twee vorme aanneem:

1. Vermoë om die CAs-inhoudkode te “ roep ” (of sy slimkontrak uit te voer), wat afhang van die logika van die rekening se slimkontrak en sy onveranderlikes.
2. Vermoë om veranderinge aan die CA's inhoudkode aan te bring, wat meestal afhang van of die inhoudkode opgradeerbaar is of nie.

In die meeste praktiese gevalle is die logika wat in hierdie geval gebruik word 'n multi-handtekeningskema wat bepaal dat 'n M van N geldige handtekeninge (waar M < N) van spesifieke rekeninge (gewoonlik EOA's) vereis word ten einde 'n verandering van die GR se logika geldig te wees.

• Hul transaksiebestelling is losweg nie-gebaseer. Die CA self is in staat om soveel transaksies aan soveel diverse oproepers as moontlik uit te stuur, maar elke oproeper is beperk op grond van hul eie vermoëns.
• Gasbetaling word gewoonlik deur die oproeper van die GR se logika hanteer.
• Die uitvoeringslogika van CA's is meer divers om UX-verbeterings soos multi-oproeptransaksies en atoomtransaksies moontlik te maak.

Deur hierdie kenmerke te evalueer, neem ons waar dat elke tipe rekening ontwerp is om 'n afweging te hê tussen outonomie en programmeerbaarheid.

EOA's het volle outonomie maar beperkte programmeerbaarheid; hulle kan transaksies magtig en stuur wanneer hulle wil, maar hierdie transaksies moet 'n rigiede formaat volg om as geldig beskou te word. Kontrakrekeninge het volle programmeerbaarheid (slegs beperk deur die EVM se ontwerp) maar beperkte outonomie: hul transaksies hoef nie enige rigiede formaat te volg nie, maar kan slegs uitgestuur word omdat hul logika eerste opgeroep word.

In die volgende onderafdeling gaan ons nou die implikasies van hierdie ontwerpkeuses bestudeer, ten einde die voorstel van elke bespreekte EIP regdeur hierdie reeks ten volle te verstaan.

Ethereum se rekening dilemma

Noudat ons 'n ietwat bondige kennis van die verskillende rekeninge se funksies het, kan ons maklik hul verkoopspunte identifiseer sowel as die kwessies wat hulle aan beide gebruikers- en ontwikkelaarervaring op Ethereum bied. Soos ons voorheen genoem het, is EOA's ontwerp as eersteklas rekeninge wat eindgebruikers teiken. Toepassings is ontwerp om maklik met hulle te kommunikeer, daar is byna geen kompleksiteit daaraan nie, en natuurlik is daar geen koste om een te skep nie. Die eenvoud daarvan kom egter met 'n aansienlike verlies aan nuutheid, aangesien hulle ontwerp is om streng deterministies te wees.

Sommige van die bekommernisse rondom hulle is:

1. Vatbaarheid vir kwantumaanvalle - Die ECDSA-handtekeningskema wat deur hul sleutelpaar gebruik word, is nie kwantumbestand nie, en met 'n optimistiese tydlyn van 5 tot 10 jaar vir industriële kwantumstelsels wat bereik word, hou dit 'n beduidende bedreiging in vir Ethereum en sy toepassings wat sterk staatmaak op die ECDSA-skema vir kriptografiese bewyse en sekuriteit.
2. Gebrek aan uitdrukking – Die rigiede formaat van EOA's se geldigheidsreëls skakel die vermoë van gebruikers uit om hul transaksies meer bondig uit te druk deur middel van kenmerke soos transaksie-atomiteit en groepering, en transaksiedelegering.
3. Selfvolhoubaarheid – Almal het hul billike deel van "ek het nie meer petrol gehad"-oomblikke in die middel van 'n transaksie gehad. Dit is as gevolg van die vereiste dat EOA's self die gas vir hul transaksies vereffen, wat nie veel van 'n vraag sou wees as eter (ETH) nie die enigste aanvaarbare gasgeldeenheid is nie. Alhoewel dit 'n algemene probleem is met rekeninggebaseerde staatsmasjiene (en selfs UTXO-gebaseerde), het Ethereum altyd bedoel om anders te wees.

Nie almal wil (of sal in staat wees om) altyd ETH te hou nie (ek bedoel kyk na daardie prysaksie), so die lewensvatbare oplossings sal wees om óf verskeie gasgeldeenhede toe te laat (te hard, breek te veel invariante soos beskryf in die "Geldeenheid" ” afdeling hier ), of om toe te laat dat gasbetalings vereffen word deur 'n ander rekening wat nie die transaksie se oorsprong is nie.

Aan die ander kant van die rekeningspektrum teiken CA's ontwikkelaars en 'n meer tegniese gebruikersbasis. Hulle dien as voertuie vir slim kontrakte (dws ons beskou slim kontrakte as hul vervatte logika of kode-inhoud) en kan dus nuwe transaksieformate implementeer soos deur die EVM geaktiveer.

Vir al hierdie kenmerke is dit egter verheerlikte tweedeklasrekeninge aangesien hulle geen outonomie het nie. Sommige van hul nadele is soos volg:

1. Totale gebrek aan outonomie – GR'e kan nie 'n transaksie begin nie, hulle kan slegs transaksies uitstuur in reaksie op 'n beroep op 'n baie spesifieke manier.
2. Vatbaarheid vir menslike foute in hul logika - Die gebrek aan rigiditeit lei dikwels tot verkeerde definisie van onveranderlikes en ander sulke logika, wat gelei het tot miljarde dollars se verliese as gevolg van slim kontrakuitbuiting en hacks. Dit is egter amper 'n heeltemal ander onderwerp wat hier buite ons bestek is.

Nadat ons die ontwerpkeuses hersien het wat gelei het tot die kwessies wat in hierdie onderafdeling gedefinieer is, kan ons nou voortgaan om die voorgestelde oplossings te evalueer.

'n Tydlyn van rekeningabstraksie

Om uit te vind wat geabstraheer kan word, benodig ons 'n (ietwat) volledige prentjie van die lopende rekeningontwerp. Hierdie afdeling sal meestal dien as 'n hersiening van soorte vir wat rekeninge op Ethereum eintlik is, en hoe hul transaksies bekragtig en uitgevoer word.

Die konsep van rekeningabstraksie (ten minste via slim rekeninge) was nog altyd 'n integrale deel van Ethereum se padkaart. Die kennis is dat die kompleksiteit rondom die implementering daarvan gedreig het om Ethereum se bekendstelling verder te vertraag, en daarom is dit geskrap vir die huidige ontwerp met verskillende rekeninge wat verskillende funksies bied. Dit is weer vertraag deur Ethereum se fokus op The Merge, en duik nou weer op as 'n hoofdeel van die netwerk se volgende groot opgradering – Pectra. Die kompleksiteit daarvan word egter steeds as 'n beduidende nadeel beskou wat die verskansing daarvan voorkom, veral aangesien Ethereum na 'n oprolgesentreerde padkaart gedraai het.

Die vereistes is nou tweeledig:

1. Rekeningstandaarde moet meer ekspressief wees, maar sonder verlies aan outonomie. 'n Nuwe standaard wat die skeiding tussen die EOA- en CA-standaarde verseël.
2. Die nuwe standaard moet die gaping tussen EOA's en CA's oorbrug, terwyl dit deeglik versoenbaar bly oor Ethereum en sy L2-ekosisteme.

Intuïtief speel hierdie konsep 'n groter rol in die konteks van kettingabstraksie en interoperabiliteit. Ons omvang in hierdie verslag is egter beperk tot die tegniese inisiatiewe wat geneem is om rekeningabstraksie self te bewerkstellig.

Rekeningabstraksie het ten doel om die beste kenmerke van EOA's en CA's in 'n nuwe rekeningstandaard te kombineer – slim rekeninge , wat volle of gedeeltelike skeiding van enige rekening se geldigheidsreëls in 'n valideringslogika en 'n uitvoering een moontlik maak; sodat rekeninge hul eie geldigheidsreëls kan definieer – soos deur die EVM toegelaat – net soos kontrakrekeninge, terwyl hulle ten volle outonoom bly net soos rekeninge wat ekstern besit word.

Daar is dikwels verwarring oor die verskille tussen slimrekeninge en slimkontrakbeursies, so kom ons beskryf uitdruklik wat hierdie verskille hieronder is:

• Slim rekeninge is Ethereum-rekeninge wat gekonseptualiseer is om gelyke dele van programmeerbaarheid en outonomie te verskaf. Die idee is dat beide EOA's en CA's slim rekeninge kan word bloot deur een of ander meganisme te gebruik (bv. ERC 4337) wat hulle toelaat om hul netwerk-opgelegde geldigheidsreëls te vervang met pasgemaakte geldigheidsreëls, soos hulle goeddink.
• Slimkontrakbeursies aan die ander kant is bloot beursieverskaffers wat dien as koppelvlakke om rekeninge te kontrakteer (ja, 'n beursie is nie 'n rekening nie).

Die kommersialisering van slim kontrak-beursies het die aanvaarding van CA's deur 'n groter mark vergemaklik, wat minder tegniese gebruikers in staat gestel het om voordeel te trek uit die kenmerke wat hulle bied. Hulle staar egter steeds die slaggate in die gesig wat met GR'e verband hou.

Terug na die gesprek; ons het voorheen die parameters bespreek wat gebruik word om die geldigheidsreëls van transaksies van rekeninge te definieer:

• Stawing
• Magtiging
• Nie-logika
• Gas betaling logika
• Uitvoering logika

Die waardes van die eerste vier parameters kan gesamentlik na verwys word as 'n rekening se valideringslogika , wat kontroles is wat plaasvind voordat 'n transaksie se uitvoering begin. Die laaste parameter definieer hoe die uitvoering van die transaksie moet voortgaan.

In die inleiding het ons 'n hoëvlakoorsig van die huidige AA-landskap verskaf in die vorm van 'n klassifikasie van soorte vir die verskillende voorgestelde ontwerpe. Ons sal nou fokus op die eerste klas oplossings vir Ethereum se rekeningdilemma - EOA-programmeerbaarheid.

Programmeerbare EOA's

Ethereum se grootste aantrekkingskrag is sy jong maar lewendige DeFi-ekosisteem wat 'n verskeidenheid gedesentraliseerde toepassings bevat wat sy primêre likiditeitsputte is. Die meeste van hierdie DApps is geoptimaliseer om EOA's te bedien, dus is dit moeilik om met kontrakrekeninge en uiteindelik slim rekeninge te koppel. Terwyl slim kontrak-beursies wel help om rekeninge in hierdie geval te kontrakteer, het hulle hul eie beperkings en 'n heeltemal ander UX.

'n Tussentydse oplossing wat ondersoek word terwyl beide DApps en beursieverskaffers gewoond raak aan die slim rekeningstandaard, is om tydelike verbeterings aan EOA's te verskaf wat hulle in staat stel om die meeste van hul opgelegde beperkings te oorkom, of dit nou hul validerings- of uitvoeringslogika is. Hieronder gaan ons oor die spesifikasies van drie groot EIP's wat uitvoerbare roetes bied na EOA-programmeerbaarheid; van die minder bekende EIP 5806 , na die ambisieuse EIP 3074 en dan uiteindelik na die seëvierende EIP 7702 .

Programmeerbaarheid via EIP-5806

Hierdie voorstel poog om meer funksionaliteit na die EOA-standaard te bring deur dit toe te laat om gedelegeerde oproepe na 'n kontrakrekening se logika (sy slim kontrak) uit te voer. Dit veroorsaak effektief dat die slim kontrak uitgevoer word in die konteks van die oproeper EOA, dit wil sê, die EOA bly in beheer van sy valideringslogika, terwyl sy uitvoeringslogika deur die ooreenstemmende kontrakrekening se logika hanteer word.

Voordat ons verder gaan, laat ons 'n reis onderneem deur die Ethereum-evolusie-geheuebaan na EIP-7 . EIP-7 het die skepping van die 0xf4/DELEGATECALL -opkode voorgestel, wat gebruik word om boodskapoproepe na 'n primêre rekening met 'n sekondêre rekening se logika te stuur, terwyl die waardes van die primêre rekening se [sender] en [waarde] velde gehandhaaf word. Met ander woorde, die primêre rekening “erf” (of leen as jy verkies) die logika van die sekondêre rekening vir 'n sekere tydsduur soos gespesifiseer in die boodskapoproep, sodat laasgenoemde se logika in die konteks van eersgenoemde uitgevoer word.

Hierdie opkode het dapp-ontwikkelaars in staat gestel om hul toepassing se logika in veelvuldige slim kontrakte te verdeel, terwyl interafhanklikheid gehandhaaf word, sodat hulle maklik om kodegrootte-versperrings en gasversperrings kon rondtrek. EIP-5806 vind 'n nuwe gebruik vir die DELEGATECALL-opkode verder as om toe te laat dat kontrakrekeninge interafhanklik is. Spesifiek, EIP-5806 gebruik EIP-7 as 'n inspirasie om die uitbreiding van die afgevaardigde-oproepfunksionaliteit ook na EOA's voor te stel; dit wil sê, laat ons toelaat dat EOA's ook interafhanklik is met kontrakrekeninge, want hoekom nie.

EIP-5806 spesifikasies

EIP 5806 stel 'n nuwe EIP-2718-voldoende transaksietipe bekend wat soos volg verpak is:

 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]).

Hierdie transaksies is so ontwerp dat die [to]-veld – wat die ontvanger se adres verteenwoordig – adresse slegs as 20-grepe-insette kan aanvaar, wat die sender uitskakel om die CREATE opkode te gebruik.

Die motivering agter elke komponent van die RLP-skema is soos volg:

• chainID : Die huidige ketting se EIP-115-voldoende identifiseerder opgevul tot 32 grepe. Hierdie waarde bied herhalingsaanvalbeskerming, sodat transaksies op die oorspronklike ketting nie triviaal gerepliseer word op alternatiewe EVM-kettings met 'n soortgelyke geskiedenis en minder ekonomiese sekuriteit nie.
• nonce : 'n Unieke identifiseerder vir elke transaksie wat ook herhalingsaanvalbeskerming bied.
• max_priority_fee_per_gas en max_fee_per_gas : Die waardes van die gasfooi wat 'n EIP-5806-transaksie moet betaal vir onderskeidelik bestelling en insluiting.
• gas_limit : Die maksimum hoeveelheid gas wat 'n enkele 5806-tipe transaksie kan verbruik.
• bestemming : Die transaksie ontvanger
• data : Die uitvoerbare kode-inhoud
• toegangslys : Agente wat voorwaardelik gemagtig is om EIP-5806-transaksies uit te voer.
• signature_y_parity, signature_r, en signature_s : drie waardes wat saam 'n secp256k1-handtekening oor die boodskap verteenwoordig — keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

Terwyl die verpakking van EIP-5806-transaksies in EIP-2718-koeverte dit moontlik maak om baie agteruitversoenbaar te wees, is EOA's nie gelykstaande aan kontrakrekeninge nie. So sekere beperkings moet gedefinieer word in die manier waarop 'n EOA gedelegeerde oproepe gebruik om onveranderlike breek te voorkom.

Hierdie beperkings is gerig op die volgende opkodes:

• SSTORE/0x55 : Hierdie opkode laat 'n rekening toe om 'n waarde in berging te stoor. Dit is beperk in EIP-5806-transaksies om te verhoed dat EOA's berging instel/toegang kry deur gedelegeerde-oproepe te gebruik, om sodoende potensiële probleme te voorkom wat in die toekoms kan ontstaan as gevolg van rekeningmigrasie.
• CREATE/0xF0 , CREATE2/0xF5 , en SELFDESTRUCT/0xFF : Hierdie opkodes laat die beller omvattend toe om 'n nuwe rekening te skep. Toegang tot hierdie is beperk om verandering van 'n EOA se nonce in 'n ander uitvoeringsraamwerk te voorkom (kontrakskepping/vernietiging in hierdie geval) terwyl dit 'n EIP-5806-transaksie uitvoer, om ongeldig te maak van die verwagting dat transaksies opeenvolgende nonces dra.

Potensiële toepassings van EIP-5806

Die primêre toepaslikheid van EIP-5806 is uitvoering-abstraksie vir EOA's. Deur EOA's toe te laat om vertroueloos met slim kontrakte te kommunikeer, verder as eenvoudige oproepe na hul logika, gee hulle kenmerke soos:

• Voorwaardelike uitvoering van transaksies
• Transaksiegroepering
• Multi-oproep transaksies (bv. goedkeur en bel)

Kritiek van EIP-5806

Die veranderings wat deur EIP-5806 voorgestel word, hoewel dit die nodige kenmerke moontlik maak, is nie besonder nuut nie; sy bestaan is meestal gebaseer op 'n reeds funksionele EIP-7. Dit laat dit toe om baie potensiële struikelblokke vir aanvaarding te omseil.

Een van die groot bekommernisse wat in sy vroeë dae uitgespreek is, was die potensiële risiko om EOA's toe te laat om toegang tot berging te kry en dit te verander, net soos CA's tans doen. Dit breek baie netwerk-verskanste invariante oor hoe EOA's transaksies moet doen, en is dus hanteer deur die beperkings wat in die vorige onderafdeling genoem is, in te stel.

'n Tweede kritiek (wat 'n bietjie van 'n tweesnydende swaard is) is die eenvoud van EIP-5806; daar is 'n mate van sentiment dat die belonings as gevolg van die aanvaarding van EIP-5806 dalk nie die koste werd is nie, aangesien dit slegs uitvoering abstraksie moontlik maak en nie veel anders nie. Elke ander geldigheidsbeperking bly netwerkgedefinieer vir EOA's wat inteken op EIP-5806, in teenstelling met ander ietwat soortgelyke EIP's wat ons in die volgende onderafdelings bespreek.

Programmeerbaarheid via EIP-3074

EIP-3074 stel voor om EOA's toe te laat om die meeste van hul valideringslogika aan gespesialiseerde kontrakrekeninge, waarna verwys word as aanroepers, te delegeer deur laasgenoemde se magtigingslogika oor hulle s'n te plaas vir spesifieke vorme van transaksies. Dit bereik dit deur hul toegangsbeleid by 'n aanroeperkontrak te teken, wat dan verantwoordelik word vir die definisie van die EOA se toegangsbeleid.

Hierdie EIP stel die byvoeging van twee nuwe opkodes tot die EVM voor:

• [AUTH] wat 'n konteksveranderlike [gemagtigde] rekening stel om namens 'n tweede [owerheid] rekening op te tree, gebaseer op laasgenoemde se ECDSA-handtekening.
• [AUTHCALL] wat oproepe stuur/implementeer vir die [owerheid] rekening vanaf/as die [gemagtigde] rekening.

Hierdie twee op-kodes laat 'n EOA toe om beheer aan 'n vooraf-gevestigde GR te delegeer, en dus as een daardeur op te tree, sonder om 'n kontrak te ontplooi en die koste en eksternaliteite wat daarmee gepaard gaan, aan te gaan.

EIP-3074 spesifikasies

EIP-3074 laat transaksies toe om 'n [MAGIC] -tekenformaat te gebruik om botsings met ander transaksie-ondertekeningformate te voorkom. Die aktiewe rekening waarheen [AUTHCALL] -instruksies deurgegee word, word gedefinieer as 'n konteksveranderlike veld met die naam [gemagtig], wat slegs voortduur deur 'n enkele transaksie en herdefinieer moet word vir elke nuwe [AUTHCALL] .

Voordat die kompleksiteite van elke opkode aangespreek word, is dit die entiteite wat by 'n EIP-3074-transaksie betrokke is:

• [owerheid] : Die primêre ondertekeningsrekening ('n EOA) wat toegang/beheer delegeer na 'n tweede rekening, wat tipies 'n kontrakrekening is.
• [gemagtig] : Die rekening waarheen [AUTHCALL] instruksies deurgegee moet word vir uitvoering. Met ander woorde, dit is die rekening waarin die logika van 'n [AUTHCALL] uitgevoer word, namens die [owerheid], deur gebruik te maak van beperkings wat deur 'n [aanroeper] gedefinieer is.
• [aanroeper] : 'n Hulpkontrak wat bedoel is om die interaksies tussen die [gemagtigde] rekening en die logika van die [AUTHCALL] te bestuur, veral in gevalle waar die primêre logika van laasgenoemde se kontrakkode gasborgskap is.

Oproeperkontrakte ontvang [AUTH] -boodskappe met 'n [COMMIT]-waarde van [owerheid]; hierdie waarde definieer die beperkings wat die rekening wil plaas op [gemagtigde] se uitvoering van [AUTHCALL] instruksies. Oproepers is dus verantwoordelik om te verseker dat die [ contract_code ] wat in 'n [gemagtigde] rekening gedefinieer is, nie kwaadwillig is nie en die vermoë het om die onveranderlikes wat deur die primêre ondertekeningsrekening in 'n [COMMIT]-waarde geplaas word, te bevredig.

Die [AUTH] -opkode het drie stapelelement-insette; of meer eenvoudig - dit word gedefinieer deur drie insette wat 'n enkele uitset bereken. Hierdie insette is:

1. gesag : wat die adres is van die EOA wat die handtekening genereer
2. verreken
3. lengte

Die laaste twee insette word gebruik om 'n reeks veranderbare geheue van 0 tot 97 te beskryf, waar:

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]

Die veranderlikes [yParity], [r] en [s] word gesamentlik geïnterpreteer as 'n ECDSA-handtekening, [magic], op die secp256k1-kromme oor die boodskap:

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

waar:

• [MAGIC] is 'n ECDSA handtekening wat voortspruit uit die kombinasie van die veranderlikes:
• [chainID] wat die huidige ketting se EIP 115-voldoende identifiseerder is wat gebruik word om herhalingsaanvalbeskerming te bied op alternatiewe EVM-kettings met 'n soortgelyke geskiedenis en minder ekonomiese sekuriteit.
• [nonce] wat die transaksieondertekenaar se adres se huidige nonce is, links opgevul tot 32 grepe.
• [invokerAddress] wat die adres is van die kontrak wat die logika vir [AUTH] se uitvoering bevat.
• [COMMIT] is 'n 32-grepe waarde wat gebruik word om addisionele transaksiegeldigheidsvoorwaardes in die aanroeper se voorverwerkingslogika te spesifiseer.

As die berekende handtekening geldig is en die ondertekenaar se adres gelyk is aan [owerheid], word die [gemagtigde] veld opgedateer na die waarde wat deur [owerheid] verskaf word. As enige van hierdie vereistes nie bevredig word nie, bly die [gemagtigde] veld onveranderd in sy vorige toestand, of as 'n ongestelde waarde.

Die gaskoste vir hierdie opkode word bereken as die som van:

1. 'n Vaste fooi vir die [ecrecover] voorafsamestelling en ekstra vir 'n keccak256 hash en 'n bietjie addisionele logika, ter waarde van 3100 eenhede

2. 'n Geheue-uitbreidingsfooi wat soortgelyk aan die [RETURN]-opkode bereken word, en toegepas word wanneer geheue uitgebrei word verby die gespesifiseerde reeks van die huidige toekenning (97 eenhede)

3. 'n Vaste koste van 100 eenhede aangegaan vir 'n warm [owerheid] en 2600 eenhede vir 'n koue een om aanvalle te voorkom as gevolg van wanpryse van staattoegangskodes.

   
   

   ( AUTH word geïmplementeer om nie geheue te verander nie, en neem [owerheid] se waarde as 'n argument sodat dit onbenullig is om die waarde daarvan te verifieer vanaf die verskafde handtekening.)

Die [AUTHCALL] -opkode het sewe stapelelement-insette wat gebruik word om 'n enkele stapelelement-uitset te bereken.

Dit het dieselfde logika as die [CALL] op-kode, dws; dit word gebruik om boodskapoproepe na 'n rekening te stuur en spesifieke logika in sy kontrakte te aktiveer. Die enigste afwyking in hul logika is dat [AUTHCALL] ontwerp is om die [CALLER] se waarde te stel voordat u met uitvoering voortgaan.

Dus, [AUTHCALL] word deur die [owerheid] gebruik om konteksspesifieke gedrag in [gemagtigde] te aktiveer met logiese kontrole wat soos volg voortgaan:

1. Kyk vir [gemagtigde] se waarde. As dit nie ingestel is nie, word die uitvoering as ongeldig geag en word die raam onmiddellik verlaat. Dit help om onbillike aanklagte as gevolg van ongekende mislukkings te voorkom.
2. Kontroleer vir die gaskoste van [gemagtigde] se voorgenome gedrag.
3. Kontroleer vir die [gas] operand se EIP-150 voldoen-waarde.
4. Kontroleer vir die beskikbaarheid van die totale gaskoste –[waarde]– in [owerheid] se balans.
5. Uitvoering vind plaas na aftrekking van [waarde] van die saldo van [owerheid] se rekening. As [waarde] groter is as hul saldo, word die uitvoering ongeldig.

Die gaskoste vir [AUTHCALL] word bereken as die som van:

• 'n Vaste koste om [warm_storage_read] te bel
• 'n Geheue-uitbreidingskoste [memory_expansion_fee] , wat soortgelyk aan die gaskoste vir die [CALL] -opkode bereken word
• 'n Dinamiese koste [dynamic_gas]
• Die uitvoeringskoste van die suboproep [subcall_gas]

Die data wat van 'n [AUTHCALL] teruggestuur word, word verkry deur:

• [RETURNDATASIZE] – wat die grootte van die terugkeerdatabuffer op die uitvoerstapel stoot
• [RETURNDATACOPY] – wat die data van die terugkeerdatabuffer na die geheue kopieer.

Om dit alles saam te bring met baie minder van die tegnologie-praat; Ethereum-transaksies spesifiseer tipies twee waardes:

1. tx.origin – wat magtiging vir die transaksie verskaf.
2. msg.sender – waarin die transaksie werklik plaasvind.

In EOA's, soos voorheen genoem, is magtiging nou gekoppel aan uitvoering, dit wil sê ( tx.origin == msg.sender ). Hierdie eenvoudige onveranderlike gee aanleiding tot die meeste van die kwessies wat ons in die "Rekeninge en transaksiegeldigheid" onderafdeling van hierdie verslag verduidelik het.

[AUTH] -boodskappe van [owerheid] laat dit toe om die tx.origin-funksie te verreken na [gemagtig], terwyl dit die boodskap.sender bly. Dit laat dit ook toe om beperkings op hierdie voorreg te definieer deur 'n [COMMIT]-waarde te gebruik. [AUTHCALL] laat dan [gemagtig] toe om toegang tot 'n kontrak se logika te verkry, deur 'n [aanroeper] as 'n tussenganger te gebruik om te verseker dat die kontrak waartoe hy toegang wil verkry, skadeloos is. Dit wil sê, vir elke [AUTHCALL] is [gemagtig] om 'n spesifieke [aanroeper] vir hul [COMMIT] te spesifiseer.

Potensiële toepassings van EIP-3074

EIP 3074 is hoofsaaklik daarvoor verantwoordelik om EOA's toe te laat om hul magtigingslogika na 'n ander rekening te delegeer, maar die oop ontwerp daarvan maak baie meer in verskillende kontekste moontlik. Die hele valideringslogika van 'n EOA kan geabstraheer word deur verskeie beperkings/innovasies op die aanroeper toe te pas soos nodig, sommige van die moontlike ontwerpe gebaseer op hul teikenlogika sluit in:

• Nonce-logika : EIP-3074 laat die EOA's nonce toe om onaangeraak te bly nadat 'n [AUTH] -boodskap gestuur is, intussen hang die nonce daarvan vir elke [AUTHCALL] af van met watter aanroeper dit in interaksie is. Op hierdie manier maak dit nie-parallellisme vir EOA's moontlik, sodat hulle verskeie nie-oorvleuelende [AUTHCALL] s kan uitstuur soos hulle wil.
• Gasbetalingslogika : Soos gespesifiseer in die EIP, kan aanroepers ontwerp word om gasborgskap toe te laat. As sodanig kan die gasfooie vir 'n gebruiker se [COMMIT] afgetrek word van die transaksie se oorsprong, of van enige ondersteunende rekening, hetsy 'n persoonlike een of 'n diensgebaseerde aflos (gasborgskapdienste). Ook die uitvoeringslogika word intuïtief geabstraheer; die aanroeper (wat 'n GR is) is immers nou verantwoordelik vir die uitvoering van transaksieversoeke namens die EOA.

Kritiek van EIP-3074

Aanroepersentralisasie

Deur een van die skrywers daarvan aan te haal : " Ek sou nie verwag dat beursies funksionaliteit blootstel om arbitrêre aanroepers aan te teken nie ... ". Miskien is die grootste probleem wat deur die 3074-inisiatief gestel word, dat innovasie bo-op dit baie maklik sal neig tot toegestane en eie transaksievloei; net soos die huidige iterasies van Ethereum se MEV (maksimum onttrekbare waarde) en PBS (voorstel-bouer skeiding) markte.

By verstek moet oproeperkontrakte grootliks geoudit word om selfs erger aanvalle te voorkom as wat tans moontlik is. Dit sal onvermydelik neig na 'n ekosisteem waar slegs 'n handjievol aanroeperkontrakte wat deur invloedryke figure ontwikkel is, aangeneem sal word as die verstek vir beursie-ontwikkelaars. Dit kom dus neer op 'n kompromis tussen:

• Neem die harde gedesentraliseerde pad van voortdurende ouditering en ondersteuning van aanroeperkontrakte met die risiko van gebruikers se sekuriteit
• Aanvaarding van oproeperkontrakte van gevestigde en betroubare bronne met beter waarborge vir gebruikerssekuriteit en minder toesig oor die kontrak se veiligheid.

Nog 'n aspek van hierdie punt is die kostefunksie wat verband hou met die ontwerp, ouditering en bemarking van 'n funksionele en veilige aanroeper. Kleiner spanne sal byna altyd oortref word deur groter organisasies – veral op die bemarkingsfront – wat reeds 'n gevestigde reputasie het, selfs al is hul produk beter.

Stuur versoenbaarheidskwessies aan

EIP-3074 verskans die ECDSA-handtekeningskema, aangesien dit steeds meer geldig beskou word as die magtigingskema wat deur die aanroeper ingestel is. Alhoewel daar argumente is dat kwantumweerstand tans nie 'n definitiewe probleem is nie (en dat daar veel erger op die spel is in 'n toekoms waar ECDSA korrupbaar is), is Ethereum se ietwat onbepaalde doel om altyd voor sulke probleme te wees. Die moontlike opoffering van kwantum- en sensuurweerstand vir marginale verbeterings in UX is dalk nie die beste keuse in die nabye toekoms nie.

Nog 'n punt oor die vooruitversoenbaarheidsargument is dat terwyl die voordele van 3074 nog beoordeel is, ERC-4337 (wat geen protokolveranderinge vereis nie) nou 'n wonderlike mark het, so jy moet ook daarmee versoenbaar wees om te vermy kompartementalisering van ekosisteme. Selfs met die padkaart vir inheemse rekeningabstraksie, sou die [AUTH] en [AUTHCALL] opkodes uiteindelik verouderd raak in die EVM, wat 'n groot hoeveelheid tegniese skuld aan Ethereum bekendstel om 'n marginale hoeveelheid UX-verbetering te lewer.

ECDSA skema onherroeplikheid

Nadat 'n [AUTH] -boodskap gestuur is en beheer gedelegeer is, word daar van die EOA verwag om die gewone privaatsleutel-magtigingskema te vermy, aangesien die uitstuur van 'n "normale" transaksie veroorsaak dat die magtiging wat dit aan elke aanroeper gedelegeer het, herroep word. Die ECDSA-skema bly dus streng beter as enige ander magtigingskema wat die gepaardgaande kontrakte moontlik maak, wat beteken dat 'n verlies van private sleutels 'n totale verlies van die rekening se bates tot gevolg sal hê.

Programmeerbaarheid via EIP-7702

Hierdie voorstel het aanvanklik uiteengesit as 'n ietwat minimalistiese variasie van EIP 3074, en was selfs bedoel om 'n opdatering daarvan te wees. Dit is gebore om die veronderstelde ondoeltreffendheid van EIP 3074 aan te spreek, veral die kommer oor die onversoenbaarheid daarvan met die reeds florerende 4337-ekosisteem en die voorstel vir inheemse rekeningabstraksie – RIP 7560.

Sy benadering is die toevoeging van 'n nuwe EIP 2718-voldoenende transaksietipe – [SET_CODE_TX_TYPE] – wat 'n EOA toelaat om as 'n slim rekening vir gespesifiseerde transaksies op te tree. Hierdie ontwerp maak dieselfde kenmerke as EIP 5806 en sommige meer moontlik, terwyl dit versoenbaar bly met die inheemse rekeningabstraksiepadkaart en bestaande inisiatiewe.

EIP-7702 spesifikasies

EIP-7702 laat 'n EOA toe om die kode-inhoud van 'n kontrak te "invoer" deur 'n [SET_CODE_TX_TYPE] 2718-voldoenende transaksie van die formaat:

 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])

Hierdie loonvrag is heeltemal soortgelyk aan dié van EIP 5806, behalwe dat dit 'n "magtigingslys" bekendstel. Hierdie lys is 'n geordende volgorde van waardes van formaat:

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

waar elke tupel die [adres]' waarde definieer.

Voordat u voortgaan, is die partye betrokke by 'n SET_CODE_TX_TYPE :

• [owerheid] : wat die EOA/primêre ondertekeningsrekening is
• [adres] : wat die adres is van 'n rekening wat delegeerbare kode bevat.

Wanneer [owerheid] 'n SET_CODE_TX_TYPE onderteken wat [adres] spesifiseer, word 'n delegasie-aanwyser geskep. Hierdie is 'n "wyserprogram" wat veroorsaak dat alle kodeherwinningsversoeke weens die [owerheid] se optrede op enige oomblik na [adres] se waarneembare kode gekanaliseer word.

Vir elke [chain_id, address, nonce, y_parity, r, s] tuple, is die logiese vloei van 'n 7702-tipe transaksie soos volg:

1. Verifikasie van [owerheid] se handtekening vanaf die verskafde hash deur gebruik te maak van: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Voorkoming van kruis-ketting herhaling aanvalle en ander aanval vektore deur verifikasie van die ketting se ID.
3. Kontroleer tans of [owerheid] reeds kode-inhoud het.
4. Nonce-kontrole om te verseker dat [owerheid] se nonce gelyk is aan die nonce wat in die tupel ingesluit is.
5. As die transaksie [owerheid] se eerste SET_CODE_TX_TYPE -transaksie is, word 'n PER_EMPTY_ACCOUNT_COST -fooi gehef. In die geval dat die saldo minder is as die waarde van hierdie fooi, word die operasie laat vaar.
6. Delegasie-aanwysing vind plaas, waarin die kode van [owerheid] ingestel is op 'n wyser van die [adres].
7. Die nonce van die ondertekenaar –[gesag]– word met een verhoog.
8. [owerheid] word by 'n lys-toeganklike adresse gevoeg, wat (oorvereenvoudig) 'n stel adresse is wat so gemaak is dat die terugkeer van 'n omvang van 'n transaksie van hulle veroorsaak dat hulle (die adres) teruggestel word na hul vorige toestand , voordat die teruggekeerde omvang ingevoer is. Dit is soos gedefinieer in EIP-2929 om die kas van herbruikbare waardes moontlik te maak en onnodige heffings te voorkom.

Pff! Om dit alles terug te bind; hierdie EIP laat EOA's toe om transaksies te stuur wat 'n wyser na 'n kontrak se kode stel, wat hulle in staat stel om hierdie logika as hul eie in daaropvolgende transaksies te implementeer. Op hierdie manier is dit streng sterker as EIP 5806, want dit laat EOA's toe om werklik kode-inhoud te hê vir so lank as wat hulle wil (teenoor EIP 5806 wat bloot EOA's toelaat om afgevaardigde-oproepe te stuur).

Potensiële toepassings van EIP-7702

Uitvoering abstraksie

Alhoewel daar aangevoer kan word dat dit nie meer 'n abstraksie is nie aangesien die EOA aktief die logika inneem wat dit wil uitvoer, is dit steeds nie die "primêre eienaar" van genoemde logika nie. Dit bevat ook nie direk logika nie, dit spesifiseer bloot 'n wyser na die logika (ten einde berekeningskompleksiteit te verminder). So ons gaan met uitvoering abstraksie!

Gasborgskap

Terwyl die require(msg.sender == tx.origin) invariant gebreek word om selfborgskap toe te laat, laat die EIP steeds die integrasies van geborgde transaksie-aflosers toe. Die waarskuwing is egter dat sulke aflosers 'n reputasie- of spelgebaseerde stelsel benodig om hartseeraanvalle te voorkom.

Voorwaardelike toegangsbeleide

EOA's kan slegs na 'n spesifieke gedeelte van die rekening se kode wys, sodat slegs die logika van daardie gedeelte in hul konteks uitvoerbaar is.

Dit maak ook die bestaan van subsleutels moontlik wat voortgaan om "privilege de-eskalasie" moontlik te maak, sodat spesifieke dapps slegs toegang tot 'n rekening se saldo onder spesifieke omstandighede het. Byvoorbeeld, jy kan jou 'n toestemming voorstel om ERC-20-tokens te spandeer, maar nie ETH nie, of om tot 1% van die totale balans per dag te spandeer, of om slegs met 'n spesifieke toepassing te kommunikeer.

Kruis-ketting slim kontrak ontplooiing

Weens die nie-beperkende aard daarvan, kan 'n EIP-7702-transaksie 'n gebruiker toelaat om toegang tot die CREATE2-opkode te verkry en dit te gebruik om greepkode na 'n adres te ontplooi sonder enige ander beperkende parameters soos fooimarklogika (bv. EIP-1559 en EIP-4844) ). Dit laat toe dat die adres herwin en gebruik word oor verskeie toestandmasjiene, met dieselfde greepkode, waar sy rekening op elke ketting dan verantwoordelik is vir die definisie van die ander konteksveranderlike parameters.

Kritiek van EIP-7702

Gebrek aan terugwaartse verenigbaarheid

Terwyl EIP-7702 nog baie onlangs is, is daar reeds baie prototipering en toetsing vir sy afhanklikhede en potensiële nadele, maar sy minimalistiese model waarborg dit baie buigsaamheid, en dus bruikbaarheid, in verskillende kontekste. Dit breek egter heeltemal te veel invariante en is nie onmiddellik terugwaarts versoenbaar nie. Sommige van EIP-7702 se logika sluit in:

1. Mid-transaksie EOA nie-verandering: EIP-7702 beperk nie enige opkodes in 'n poging om konsekwentheid te verseker nie. Dit beteken dat 'n EOA op-kodes soos CREATE , CREATE2 en SSTORE kan implementeer terwyl 'n EIP-7702-transaksie uitgevoer word, wat toelaat dat die nonce daarvan in 'n ander konteks verhoog word.
2. Om rekeninge met 'n nie-nul codeHash waarde toe te laat om transaksievervaardigers te wees: EIP-3607 is geïmplementeer om die potensiële uitval van 'n "adresbotsing" tussen EOA's en CA's te verminder. 'n Adresbotsing vind plaas wanneer die 160-bis waarde van 'n EOA se adres heeltemal gelykstaande is aan dié van 'n CA se adres.

Die meeste gebruikers is nie vaardig oor die werklike inhoud van 'n rekening nie (of selfs die verskil tussen 'n rekening en 'n adres!), so om adresbotsings toe te laat, beteken dat 'n EOA hom as 'n kontrakrekening kan voordoen en gebruikersfondse in 'n langtermyn kan lok. bietjie om dit uiteindelik alles te steel. EIP-3607 het dit aangespreek deur te bepaal dat rekeninge wat kode bevat nie in staat moet wees om hul balans deur hul eie magtigingslogika te gebruik nie. EIP 7702 breek egter hierdie onveranderlike om EOA's in staat te stel om outonoom te bly, selfs nadat hulle 'n mate van programmeerbaarheid verkry het.

Ooreenkomstig met EIP-3074

Om 'n rekening se adres in plaas van die kode-inhoud oor te teken, is basies net soos 3074 se skema met aanroepers. Dit bied nie streng waarborge oor konsekwentheid van kruiskettingkode-inhoud nie, aangesien 'n adres 'n ander kode-inhoud op verskillende kettings kan aanneem. Dit beteken dat 'n adres waarvan die kode-inhoud dieselfde logika op een ketting bevat, roofsugtig of heeltemal kwaadwillig op 'n ander ketting kan wees, en dit kan lei tot die verlies van gebruikersfondse.

Gevolgtrekking

EOA's in hul huidige vorm vandag is baie beperk, aangesien dit gebruikers nie toelaat om voordeel te trek uit die programmeerbaarheidskenmerke wat deur die EVM aangebied word nie. Alhoewel daar verskeie maniere is om rekeninge op te gradeer, soos ons aan die begin van hierdie verslag uiteengesit het, moet die gekose oplossing die beginsels van veilige en veilige selfbewaring handhaaf. Verder kan EOA-opgraderings 'n aansienlike impak hê op beide die gebruikerservaring en toepassingsontwikkelaars, so alle belanghebbendestemme moet oorweeg word.

Deur EOA's toe te laat om kode op enige manier uit te voer, brei die funksionaliteit van rekeninge geweldig uit, maar hierdie nuwe uitdrukbaarheid kom met betekenisvolle risiko's en moontlike blindelings. Die oplossing van hierdie afwykings is van kritieke belang om 'n opgradering met onbetwiste UX-voordele vir Ethereum-gebruikers te lewer.

Ethereum se kultuur van oop bespreking maak dit 'n goeie toetsgrond vir sulke innovasies, aangesien byna elke implikasie van elke ontwerp deeglik deur vakkundiges gedekonstrueer word. Hierdie omvattende oorweging behoort te help om die risiko's van oortreding van teenstanders te verminder.

EIP-7702 is tans die plakkaatkind vir meganismes wat poog om EVM-programmeerbaarheid na EOA's te bring, nadat dit gemerk is as 'n plaasvervanger vir EIP 3074 se gleuf in die Pectra-opgradering. Dit erf die oop ontwerp van 3074 se meganisme terwyl dit die aanvaloppervlak / risiko's aansienlik verlaag. Dit maak ook baie meer moontlik deur 3074 se beperkings op sekere klasse opkodes te vermy.

Alhoewel daar nog 'n paar verfynings aan die ontwerp van die voorstel gedoen word, het dit reeds baie welwillendheid en ondersteuning van ontwikkelaars gekry, veral omdat Vitalik dit regstreeks ondersteun. Binne die gemeenskap is daar bewerings dat hierdie benadering tot rekeningabstraksie selfs beter as slim rekeninge kan wees. Hierdie kommentaar beklemtoon dat hierdie pad minder veranderinge verg en nie so kompleks is nie, en dat EOA's reeds vasgelê is.

Ons moet egter die toekomstige sekuriteitsmylpaal van kwantumweerstand op elke vlak van die Ethereum-netwerk onthou. Hierdie kwantumveiligheid is onuitvoerbaar met die lopende rekeningmodelkern as gevolg van die gebruik van ECDSA-gebaseerde handtekeningskemas vir EOA-magtiging.

EOA-programmeerbaarheid moet dus gesien word as 'n stap op die pad na slim rekeninge en nie die bestemming nie. Dit verhoog EOA's en maak 'n beter gebruikers- en ontwikkelaarervaring moontlik, terwyl dit versoenbaar bly met die uiteindelike rekeningabstraksiedoelwit van slim rekeninge.

In ons volgende verslag sal ons in EOA-migrasieskemas duik om te sien hoe goed hulle op die rekeningabstraksiepadkaart pas, bly ingeskakel!