Ethereum konta abstrakcijas ceļveža I diagrammu veidošana: EIP-3074, EIP-5806 un EIP-7702

Novērojot būtiskās izmaiņas, kas tika ieviestas Ethereum, izmantojot Deneb jauninājumu, mēs esam sākuši skatīties uz priekšu, ko ieviesīs nākamais hardfork Pectra. Lai palīdzētu veidot turpmākās diskusijas, mēs cenšamies aprakstīt pašreizējo kontu abstrakcijas ainavu, kas ieskauj Ethereum un tās apkopojuma ekosistēmu, lai, iespējams, iezīmētu skaidru virzību uz priekšu.

Šajā pārskatā ir sniegts pārskats par Ethereum tekošā konta modeli, jo īpaši to ietekmi uz darījumu derīgumu, to, ko tieši ietver konta abstrakcija, un pamatojumu par to. Pēc tam mēs koncentrēsimies uz EOA programmējamības pieeju, novērtējot EIP 5086, 3074 un 7702, un secināsim, kā tas viss, iespējams, ietekmēs Ethereum darījumu nākotni.

Lai gan pastāv daudz neskaidrību par to, kas ir vai nav konta abstrakcija, mūsu ietvars šajā sērijā ir tāds, ka jebkurš mehānisms, kas ļauj kontam no jauna definēt kādu tā derīguma noteikumu daļu, ir konta abstrakcija. Turklāt mēs sniedzam šo mehānismu klasifikāciju, jo lielākā daļa no tiem ir neskaidri līdzīgi un savstarpēji pārklājas.

Pārskats par konta abstrakciju Ethereum

Konta abstrakcijas mērķis ir uzlabot lietotāju un izstrādātāju pieredzi visā Ethereum ekosistēmā. Līdztekus ķēdes pieredzes padarīšanai lietotājiem pieejamāku un patīkamāku, tas arī dod iespēju izstrādātājiem veikt efektīvākas darbības Ethereum un apkalpot lietotājus vēl jēgpilnākā veidā.

Mūsu kontu abstrakcijas pieeju klasifikācija ir šāda:

1. EOA uzlabojumi/programmējamība : tas ietver protokola līmeņa izmaiņas, kas ļauj EOA (ārēji piederošajiem kontiem) no jauna definēt savu derīguma noteikumu izpildes loģikas daļu. Kā labi zināms izstrādes kopienā, EOA ir konti, kas parasti ir saistīti ar galalietotājiem. Tāpēc risinājumi, kas atbilst šai pieejai, ļaus galalietotāju kontiem vairāk kontrolēt, kādas darbības tie var atļaut, salīdzinājumā ar to, kā to var pārvaldīt šodien.

2. EOA konvertēšana/migrācija . Šī pieeja ietver priekšlikumus, kuru mērķis ir pilnībā pārveidot EOA par CA (līguma kontiem). Šīs pieejas neatņemama ideja ir tāda, ka līgumu konti jau piedāvā lielāko daļu viedo kontu piedāvāto priekšrocību, tāpēc vairs nevajadzētu sarežģīt lietas; ikvienam vienkārši jāizmanto līguma konts kā primārais konts (izmantojot viedos līgumu makus).

Šī pieeja ietver mehānismus, kas ļauj EOA pāriet uz SI, nepārvietojot savus aktīvus, piemēram, EIP 7377 un EIP 5003 (ja to aplūko kopā ar EIP 3074).

3. Viedie konti : šajā priekšlikumu grupā ir iekļauti dizaini, kas ļauj gan EOA, gan CA darboties kā “viedajiem kontiem”, ļaujot tām pilnībā no jauna definēt to derīguma noteikumus.

Iepriekš ir izteikti dažādi priekšlikumi viedo kontu izveidei un kontu abstrakcijas glabāšanai protokola līmenī; EIP-86 un EIP-2938 ir daži no biežāk citētajiem. Tomēr šī dizaina radītā sarežģītība un lielākā daļa uzskatīja, ka Ethereum nav gatavs šādai sarežģītībai, bija daudz atgrūšanās.

Pēc Vitalik tēmas atdzīvināšanas pēc sapludināšanas, ERC-4337 tika piedāvāts kā viedkontu standarta izvēles versija, kas ir līdzīga PBS (Proposer-Builder Separation) infrastruktūrai MEV (maksimālā ekstrahējamā vērtība). Tādējādi lietotāji, kuri vēlas piekļūt viedo kontu priekšrocībām, var vienkārši izmantot ERC-4337 konveijeru, lai atkārtoti definētu sava konta loģiku un transakciju derīguma noteikumus struktūrās, kas tiek dēvētas par UserOperation (vai saīsināti UserOps ).

ERC 4337 nodrošina viedo kontu priekšrocības mūsdienu Ethereum, nepalielinot nekādu sarežģītību, darbojoties kā ārpusprotokola alternatīva ietvertajiem viedkontiem. Tomēr tas nenozīmē, ka infrastruktūra ir optimāla tās pašreizējā stāvoklī, jo tās sarežģītība joprojām ir ievērojama atteices vieta.

Lai risinātu šo sarežģītību, RIP 7560 tika izstrādāta kā nostiprināta ERC 4337 infrastruktūras versija visā Ethereum un tā L2, lai tā mantotu tīkla sibilizturības shēmas, nevis būtu jādefinē jauna noteikumu kopa (kā to dara ERC 4337 ar ERC 7562 ).

Šajā ziņojumā mēs koncentrēsimies uz EOA programmējamības izpēti, dažādu EIP, kas apraksta risinājumus šajā virzienā, un apspriedīsim to priekšrocības un trūkumus. Šīs sērijas 2. un 3. daļā mēs apskatīsim atlikušās divas pieejas klases kontu abstrakcijai, kas tiek pētītas Ethereum.

Primer par Ethereum kontiem un darījumiem

Lai noskaidrotu, ko var abstrahēt, mums ir nepieciešams (nedaudz) pilnīgs priekšstats par tekošā konta dizainu. Šī sadaļa galvenokārt kalpos kā pārskatīšana par to, kādi konti patiesībā ir Ethereum un kā tiek apstiprināti un izpildīti to darījumi.

Ethereum konti ir vienības ar ētera (ETH) bilanci un iespēju nosūtīt darījumus Ethereum blokķēdē. Tie tiek attēloti kā 42 rakstzīmju heksadecimālā “adrese”, kas kalpo kā unikāla norāde uz konta turējumiem un darījumiem.

Adrese darbojas kā atslēga blokķēdes stāvokļa pārbaudei. Šī mēģinājuma lapu mezgli ir konta datu struktūras, kuras var sadalīt četros laukos:

1. nonce : lineārs skaitītājs, ko izmanto, lai norādītu konta iniciēto izejošo darījumu skaitu. Tas ir arī ļoti svarīgi, lai novērstu atkārtotus uzbrukumus.
2. balance : Wei denominētais ētera (ETH) daudzums, kas pieder kontam.
3. codeHash : kontā ietvertā EVM izpildāmā koda jaukšana. EVM (Ethereum virtuālā mašīna) ir Ethereum pasūtījuma izpildes vide, kas ir atbildīga par sarežģītu stāvokļu pāreju apstrādi, ne tikai vienkāršām “sūtīšanas” transakcijām. Konta koda saturs ir nemainīgi ieprogrammēts, lai Ethereum blokķēdē veiktu noteiktas stāvokļa pārejas formas, izmantojot EVM.
4. storageHash : konta krātuves saknes jaucējvārds, ko izmanto, lai attēlotu konta krātuves saturu kā 256 bitu jauktu no Merkle Patricia Trie saknes mezgla. Vienkārši, tas ir stāvokļa mainīgā datu jaukšana, kas saistīta ar konta koda saturu.

Šo četru lauku saturs tiek izmantots, lai definētu konta veidu un galu galā definētu tā funkcionalitātes apjomu. Tādējādi divi Ethereum kontu veidi ir:

1. Ārēji piederoši konti (EOA) , kas tiek inicializēti kā kriptogrāfisko atslēgu pāris:

• Privātā atslēga , kas ir šifrējama un pierādāma nejauša 64 heksadzīmju rakstzīme un tās papildinošais ekvivalents;
• Publiskā atslēga , kas iegūta no privātās atslēgas, izmantojot ECDSA (eliptiskās līknes digitālā paraksta algoritmu).

EOA ir tukši codeHash un storageHash lauki, un tos var kontrolēt tikai ikviens, kam ir privātās atslēgas. To adreses var iegūt no atbilstošās publiskās atslēgas, pirms konta publiskās atslēgas keccak-256 hash pēdējām divdesmit rakstzīmēm pievienojot “0x”.

2. Līguma konti (CA), kurus var izveidot tikai jau esoša EOA. Tie tiek inicializēti, jo EOA izvieto izpildāmā koda saturu EVM. Šis koda saturs (kas tiek saglabāts kā codeHash) ir iekļauts EVM un ir atbildīgs par konta kontroli, definējot tā loģiku un mijiedarbību.

Darījumi no līguma konta ir pilnībā balstīti uz izvilkšanu, pamatojoties uz to izvietotā koda loģiku. Tā kā šos kontus var kontrolēt tikai ar to koda saturu, tiem nav nepieciešama privātā atslēga, un tiem ir tikai publiskā atslēga. Tādējādi jebkurš aģents, kuram ir iespēja atjaunināt/mainīt līguma konta koda saturu, varētu piekļūt konta atlikumam. Līguma konta adrese ir atvasināta no tā izveidotāja adreses un tā nonce līdz līguma izvietošanas brīdim.

Darījumi

Mēs nesen aprakstījām kontus kā vienības, kurām ir iespēja nosūtīt darījumus Ethereum. Tāpēc mēs varam saprast, ka konta galvenais mērķis ir sūtīt un saņemt darījumus, savukārt blokķēde darbojas kā virsgrāmata, kurā tiek reģistrēta darījumu vēsture, kā arī aprakstīts, kā darījumi maina konta laukus, pamatojoties uz noteikumiem, kas aprakstīti blokķēdes protokola specifikācijā.

Tātad, kas ir šie "darījumi"?

Darījumi ir no konta nosūtītas darbības, kas izraisa tīkla “stāvokļa” izmaiņas. Tie ir kriptogrāfiski parakstītas instrukcijas no kontiem, kuru izpildes rezultātā tiek atjaunināts statuss visā tīklā.

Neatļautība ir saistīta ar nepareizu stimulu izmaksām. Lai tos risinātu, ir jādefinē stingras vadlīnijas (vai derīguma noteikumi) mijiedarbībai šādās vidēs. Šajā kontekstā darījumiem ir jāievēro noteikti derīguma noteikumi, lai tos uzskatītu par derīgiem un izpildītiem. Lielākā daļa no šiem derīguma noteikumiem tiek ieviesti, izmantojot ierobežojumus kontam, no kura tiek nosūtīts darījums, un tie atšķiras atkarībā no konta veida.

Konti un darījumu derīgums

Ethereum EOA ir optimizētas lietojamībai, jo tās ir paredzētas galalietotājam. Viņiem ir iespēja nosūtīt darījumus noteiktā veidā un lieliski darboties autonomi. Tos var izveidot arī lokāli, un visizplatītākā metode ir maku pakalpojumu sniedzēju, piemēram, MetaMask, Rainbow, Rabby utt., izmantošana.

No otras puses, līgumu konti var nosūtīt tikai tos darījumus, ko pieļauj to loģika, reaģējot uz “ izsaukšanu ”. Turklāt tos var izveidot tikai EOA, kurai ir pietiekams atlikums, lai samaksātu par valsts uzglabāšanu.

Augstāks apraksts būtu tāds, ka EOA var saglabāt tikai atlikumu, savukārt CA var saglabāt gan atlikumu, gan loģiku, kas nosaka, kā šo atlikumu var izlietot. Šos rekvizītus nosaka šādi loģiskie parametri, kas nosaka noteikumus, kuriem ir jāatbilst konta transakcijām:

1. Autentifikācijas loģika — izmanto, lai noteiktu, kā konts pierāda savu identitāti tīklam, vienlaikus mainot tā bilanci un/vai loģiku.
2. Autorizācijas loģika — izmanto, lai definētu konta piekļuves politiku, ti, kas var piekļūt un veikt izmaiņas konta atlikumā un/vai loģikā.
3. Nonce logic - kas nosaka secību, kādā jāizpilda darījumi no konta.
4. Gāzes maksājumu loģika — izmanto, lai definētu pusi, kas ir atbildīga par darījuma gāzes maksas nokārtošanu.
5. Izpildes loģika — izmanto, lai noteiktu, kādus darījumu veidus konts var nosūtīt vai kā darījums ir jāizpilda.

Šie parametri ir izstrādāti tā, lai tie būtu stingri EOA:

• Autentificēšanu un autorizāciju nodrošina uz ECDSA balstīta privātā atslēga, ti, lietotājam, kurš vēlas nosūtīt darījumu no savas EOA, ir jāizmanto sava privātā atslēga, lai piekļūtu kontam un tādējādi pierādītu, ka viņam ir tiesības veikt jebkādas izmaiņas tā bilancē. .
• Nonce loģika ievieš secīgu skaitītāja shēmu, kas ļauj secīgi izpildīt tikai vienu darījumu uz vienu unikālu nonce.
• Gāzes maksājumu loģika nosaka, ka maksa par gāzi par darījumiem ir jākārto sūtītājam/sākotnējam kontam.
• Izpildes loģika nosaka, ka EOA var nosūtīt tikai šādas darījumu veidlapas:

1. Regulāri pārskaitījumi starp divām EOA.
2. Līguma izvietošana.
3. līguma izsaukumi , kuru mērķis ir izvietotā līguma konta loģika.

Vispārīgāk, EOA izpildes loģika ierobežo tos līdz vienam darījumam uz vienu derīgu parakstu.

No otras puses, SI ir lielāka elastība attiecībā uz šiem parametriem:

• Autentifikācija nav nepieciešama, jo to darījumi pēc būtības ir konsekventi/paņemti.
• CA autorizācijai var būt divi veidi:

1. Iespēja “ izsaukt ” CA satura kodu (vai izpildīt tā viedo līgumu), kas ir atkarīga no konta viedā līguma loģikas un tā invariantiem.
2. Iespēja veikt izmaiņas CA satura kodā, kas galvenokārt ir atkarīgs no tā, vai satura kods ir jaunināms vai nē.

Vairumā praktisko gadījumu šajā gadījumā izmantotā loģika ir vairāku parakstu shēma, kas nosaka, ka M no N derīgu parakstu (kur M < N) ir nepieciešams no konkrētiem kontiem (parasti EOA), lai mainītu SI loģiku. lai būtu derīgs.

• Viņu darījumu secība ir brīvi balstīta. Pati CA var nosūtīt pēc iespējas vairāk darījumu pēc iespējas dažādiem zvanītājiem , tomēr katrs zvanītājs ir ierobežots atkarībā no savām iespējām.
• Gāzes maksājumus parasti apstrādā CA loģikas zvanītājs .
• CA izpildes loģika ir daudzveidīgāka, lai nodrošinātu UX uzlabojumus, piemēram, vairāku zvanu darījumus un atomu darījumus.

Novērtējot šīs funkcijas, mēs novērojam, ka katrs konta veids ir izveidots tā, lai būtu kompromiss starp autonomiju un programmējamību.

EOA ir pilnīga autonomija, bet ierobežota programmējamība; viņi var autorizēt un nosūtīt darījumus, kad vien vēlas, taču šiem darījumiem ir jāievēro stingrs formāts, lai tos uzskatītu par derīgiem. Līgumu kontiem ir pilnīga programmējamība (to ierobežo tikai EVM dizains), bet ierobežota autonomija: to darījumiem nav jāievēro nekāds stingrs formāts, bet tos var nosūtīt tikai tāpēc, ka vispirms tiek izsaukta to loģika.

Nākamajā apakšsadaļā mēs tagad pētīsim šo dizaina izvēļu ietekmi, lai pilnībā izprastu katras apspriestās EIP piedāvājumu visā šajā sērijā.

Ethereum konta dilemma

Tagad, kad mums ir diezgan īsas zināšanas par dažādo kontu funkcijām, mēs varam viegli noteikt to pārdošanas punktus, kā arī problēmas, kuras tie rada gan lietotāju, gan izstrādātāju pieredzei Ethereum. Kā jau minējām iepriekš, EOA ir veidoti kā pirmšķirīgi konti, kas paredzēti galalietotājiem. Lietojumprogrammas ir izstrādātas tā, lai tās varētu viegli mijiedarboties, tās gandrīz nav sarežģītas, un, protams, par to izveide nav jāmaksā. Tomēr tā vienkāršība ir saistīta ar ievērojamu novitātes zudumu, jo tie ir izstrādāti tā, lai tie būtu stingri deterministiski.

Dažas no tām bažām ir:

1. Jutība pret kvantu uzbrukumiem — ECDSA parakstu shēma, ko izmanto viņu atslēgu pāris, nav kvantu izturīga, un, ņemot vērā optimistisko 5–10 gadu laika grafiku rūpniecisko kvantu sistēmu sasniegšanai, tas rada ievērojamus draudus Ethereum un tā lietojumprogrammām, kas ir ļoti atkarīgas. par ECDSA shēmu kriptogrāfiskajiem pierādījumiem un drošībai.
2. Izteiksmes trūkums — EOA derīguma noteikumu stingrais formāts neļauj lietotājiem precīzāk izteikt savus darījumus, izmantojot tādas funkcijas kā darījumu atomitāte un pakešu grupēšana un darījumu deleģēšana.
3. Pašilgtspēja — Ikvienam ir bijusi sava daļa brīžu, kad darījuma laikā man beidzās benzīna. Tas ir saistīts ar prasību, ka EOA pašām norēķinās par gāzi par saviem darījumiem, kas nebūtu īpaši jautājams, vai ēteris (ETH) nebūtu vienīgā pieņemamā gāzes valūta. Lai gan šī ir vispārēja problēma ar uz kontu balstītām stāvokļa iekārtām (un pat tādām, kas balstītas uz UTXO), Ethereum vienmēr bija iecerēts citādi.

Ne visi vēlas (vai varētu) vienmēr turēt ETH (es domāju, aplūkojiet šo cenu darbību), tāpēc dzīvotspējīgs risinājums būtu vai nu atļaut vairākas gāzes valūtas (pārāk grūti, pārtrauc pārāk daudz invariantu, kā aprakstīts sadaļā “Valūta”. ” sadaļu šeit ), vai lai ļautu norēķināties par gāzes maksājumiem, izmantojot citu kontu, kas nav darījuma izcelsme.

Kontu spektra otrā galā CA ir paredzētas izstrādātājiem un tehniskākai lietotāju bāzei. Tie kalpo kā transportlīdzekļi viedajiem līgumiem (ti, mēs uzskatām, ka viedie līgumi ir tajos ietvertā loģika vai koda saturs), un tādējādi var ieviest jaunus darījumu formātus, ko iespējo EVM.

Tomēr visām šīm funkcijām tie ir slavēti otrās klases konti, jo tiem nav autonomijas. Daži to trūkumi ir šādi:

1. Pilnīgs autonomijas trūkums — CA nevar sākt darījumu, tās var tikai nosūtīt darījumus, reaģējot uz to izsaukšanu ļoti īpašā veidā.
2. Uzņēmība pret cilvēciskām kļūdām to loģikā – stingrības trūkums bieži noved pie nepareizas invariantu definīcijas un citas līdzīgas loģikas, kas ir radījis miljardiem dolāru zaudējumus viedo līgumu izmantošanas un uzlaušanas dēļ. Tomēr šī ir gandrīz pilnīgi cita tēma, kas ir ārpus mūsu darbības jomas.

Pārskatot dizaina izvēles, kas noveda pie šajā apakšnodaļā definētajām problēmām, tagad varam turpināt piedāvāto risinājumu izvērtēšanu.

Konta abstrakcijas laika skala

Lai noskaidrotu, ko var abstrahēt, mums ir nepieciešams (nedaudz) pilnīgs priekšstats par tekošā konta dizainu. Šī sadaļa galvenokārt kalpos kā pārskatīšana par to, kādi konti patiesībā ir Ethereum un kā tiek apstiprināti un izpildīti to darījumi.

Konta abstrakcijas jēdziens (vismaz izmantojot viedos kontus) vienmēr ir bijis Ethereum ceļveža neatņemama sastāvdaļa. Lieta ir tāda, ka sarežģītība, kas saistīta ar tā ieviešanu, draudēja vēl vairāk aizkavēt Ethereum palaišanu, tāpēc tas tika izņemts no pašreizējā dizaina ar dažādiem kontiem, kas piedāvā dažādas funkcijas. To atkal aizkavēja Ethereum koncentrēšanās uz The Merge, un tagad tā tiek atjaunota kā galvenā tīkla nākamā lielā jauninājuma — Pectra daļa. Tomēr tā sarežģītība joprojām tiek uzskatīta par būtisku trūkumu, kas neļauj to nostiprināt, jo īpaši tāpēc, ka Ethereum ir mainījies uz apkopojumu orientētu ceļvedi.

Tagad prasības ir divkāršas:

1. Konta standartiem ir jābūt izteiksmīgākiem, taču nezaudējot autonomiju. Jauns standarts, kas novērš plaisu starp EOA un CA standartiem.
2. Jaunajam standartam ir jāpārvar plaisa starp EOA un CA, vienlaikus saglabājot pilnīgu saderību visā Ethereum un tā L2 ekosistēmās.

Intuitīvi šai koncepcijai ir lielāka loma ķēdes abstrakcijas un sadarbspējas kontekstā. Tomēr mūsu darbības joma šajā ziņojumā aprobežojas ar tehniskām iniciatīvām, kas veiktas, lai panāktu pašu kontu abstrakciju.

Konta abstrakcijas mērķis ir apvienot labākās EOA un CA funkcijas jaunā konta standartā — viedajos kontos , kas ļauj pilnībā vai daļēji nodalīt jebkura konta derīguma noteikumus validācijas loģikā un izpildes loģikā; lai konti varētu definēt savus derīguma noteikumus — kā to atļauj EVM — tāpat kā līgumu konti, vienlaikus saglabājot pilnīgu autonomiju tāpat kā ārējiem kontiem.

Bieži vien ir neskaidrības par atšķirībām starp viedkontiem un viedo līgumu makiem , tāpēc tālāk aprakstīsim šīs atšķirības.

• Viedie konti ir Ethereum konti, kas ir izstrādāti, lai nodrošinātu vienādas programmējamības un autonomijas daļas. Ideja ir tāda, ka gan EOA, gan CA var kļūt par viedkontiem, vienkārši izmantojot kādu mehānismu (piemēram, ERC 4337), kas ļauj tiem aizstāt tīkla noteiktos derīguma noteikumus ar īpašiem derīguma noteikumiem, kā viņi uzskata par vajadzīgu.
• No otras puses, viedie līgumu maki ir vienkārši maku nodrošinātāji, kas kalpo kā saskarnes līgumu kontiem (jā, seifs nav konts).

Viedo līgumu maku komercializācija atviegloja CA pārņemšanu plašākā tirgū, ļaujot mazāk tehniskiem lietotājiem izmantot to piedāvātās funkcijas. Tomēr viņi joprojām saskaras ar nepilnībām, kas saistītas ar CA.

Atpakaļ uz sarunu; mēs iepriekš apspriedām parametrus, kas tiek izmantoti, lai definētu kontu darījumu derīguma noteikumus:

• Autentifikācija
• Autorizācija
• Nonce loģika
• Gāzes maksājumu loģika
• Izpildes loģika

Pirmo četru parametru vērtības kopā var saukt par konta validācijas loģiku , kas ir pārbaudes, kas tiek veiktas pirms darījuma izpildes sākuma. Pēdējais parametrs nosaka, kā jāturpina darījuma izpilde.

Ievadā mēs sniedzām augsta līmeņa pārskatu par pašreizējo AA ainavu dažādu piedāvāto dizainu veidu klasifikācijas veidā. Tagad mēs koncentrēsimies uz Ethereum konta dilemmas pirmās klases risinājumiem — EOA programmējamību.

Programmējamās EOA

Ethereum lielākā pievilcība ir tā jaunā, bet dinamiskā DeFi ekosistēma, kurā ir dažādas decentralizētas lietojumprogrammas, kas ir tās galvenās likviditātes novadītājas. Lielākā daļa šo DApp ir optimizēti, lai apkalpotu EOA, tāpēc tos ir grūti savienot ar līgumu kontiem un galu galā viedkontiem. Lai gan viedie līgumu maki šajā gadījumā palīdz slēgt līgumus, tiem ir savi ierobežojumi un pilnīgi atšķirīga lietotāja pieredze.

Pagaidu risinājums, kas tiek pētīts, kamēr gan DApps, gan maka nodrošinātāji pierod pie viedkontu standarta, ir nodrošināt pagaidu uzlabojumus EOA, kas ļauj tiem pārvarēt lielāko daļu uzlikto ierobežojumu neatkarīgi no tā, vai tā ir validācijas vai izpildes loģika. Tālāk mēs aplūkojam trīs galveno EIP specifikācijas, kas nodrošina praktiskus ceļus uz EOA programmējamību; no mazāk zināmā EIP 5806 līdz vērienīgajam EIP 3074 un tad visbeidzot līdz uzvarošajam EIP 7702 .

Programmējamība, izmantojot EIP-5806

Šī priekšlikuma mērķis ir nodrošināt EOA standarta funkcionalitāti, ļaujot tam veikt deleģētos zvanus uz līguma konta loģiku (tā viedais līgums). Tas efektīvi izraisa viedā līguma izpildi zvanītāja EOA kontekstā, ti, EOA joprojām kontrolē savu validācijas loģiku, savukārt tā izpildes loģiku apstrādā atbilstošā līguma konta loģika.

Pirms turpināt, dosimies ceļojumā pa Ethereum evolūcijas atmiņas joslu uz EIP-7 . EIP-7 ierosināja izveidot operācijas kodu 0xf4/DELEGATECALL , ko izmanto, lai nosūtītu ziņojumu zvanus uz primāro kontu ar sekundārā konta loģiku, vienlaikus saglabājot primārā konta lauku [sūtītājs] un [vērtība] vērtības. Citiem vārdiem sakot, primārais konts “manto” (vai, ja vēlaties, aizņemas) sekundārā konta loģiku uz noteiktu laiku, kā norādīts ziņojuma izsaukumā, lai pēdējā loģika tiktu izpildīta pirmā konta kontekstā.

Šis opkods ļāva dapp izstrādātājiem sadalīt savas lietojumprogrammas loģiku vairākos viedos līgumos, vienlaikus saglabājot savstarpējo atkarību, lai viņi varētu viegli apiet koda lieluma barjeras un gāzes barjeras. EIP-5806 atrod jaunu lietojumu DELEGATECALL operētājkodam, kas pārsniedz līguma kontu savstarpēju atkarību. Konkrēti, EIP-5806 izmanto EIP-7 kā iedvesmu, lai ierosinātu deleģēto zvanu funkcionalitātes paplašināšanu arī EOA; ti, ļausim arī EOA būt savstarpēji atkarīgām no līgumu kontiem, jo kāpēc gan ne.

EIP-5806 specifikācijas

EIP 5806 ievieš jaunu ar EIP-2718 saderīgu transakciju veidu, kas ir iesaiņots šādi:

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

Šīs transakcijas ir izstrādātas tā, lai lauks [kam], kas apzīmē saņēmēja adresi, var pieņemt adreses tikai kā 20 baitu ievadi, tādējādi sūtītājam neļaujot izmantot opkoda CREATE .

Katra RLP shēmas komponenta motivācija ir šāda:

• ķēdes ID : pašreizējās ķēdes EIP-115 saderīgais identifikators, kas polsterēts līdz 32 baitiem. Šī vērtība nodrošina aizsardzību pret atkārtotu uzbrukumu, lai sākotnējās ķēdes darījumi netiktu triviāli replicēti alternatīvās EVM ķēdēs ar līdzīgu vēsturi un mazāku ekonomisko drošību.
• nonce : unikāls identifikators katram darījumam, kas nodrošina arī aizsardzību pret atkārtotu uzbrukumu.
• max_priority_fee_per_gas un max_fee_per_gas : gāzes maksas vērtības, kas EIP-5806 darījumam jāmaksā attiecīgi par pasūtīšanu un iekļaušanu.
• gas_limit : maksimālais gāzes daudzums, ko var patērēt viens 5806 tipa darījums.
• galamērķis : darījuma saņēmējs
• dati : izpildāmā koda saturs
• access_list : aģenti, kuri ir nosacīti pilnvaroti veikt EIP-5806 darījumus.
• signature_y_parity, signature_r un signature_s : trīs vērtības, kas kopā apzīmē secp256k1 parakstu virs ziņojuma — keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

Lai gan EIP-5806 transakciju iesaiņošana EIP-2718 aploksnēs ļauj tiem būt ļoti saderīgiem, EOA nav līdzvērtīgi līguma kontiem. Tāpēc ir jādefinē daži ierobežojumi, kā EOA izmanto delegātu zvanus, lai novērstu nemainīgus bojājumus.

Šie ierobežojumi ir vērsti uz šādiem opkodiem:

• SSTORE/0x55 : šis operācijas kods ļauj kontam saglabāt vērtību krātuvē. Tas ir ierobežots EIP-5806 darījumos, lai neļautu EOA iestatīt/piekļūst krātuvei, izmantojot deleģētos zvanus, tādējādi novēršot iespējamās problēmas, kas nākotnē varētu rasties konta migrācijas dēļ.
• CREATE/0xF0 , CREATE2/0xF5 un SELFDESTRUCT/0xFF : šie opkodi plaši ļauj zvanītājam izveidot jaunu kontu. Piekļuve tiem ir ierobežota, lai novērstu EOA darbības traucējumu izmaiņu citā izpildes ietvaros (šajā gadījumā līguma izveide/iznīcināšana), kamēr tā veic EIP-5806 darījumu, lai novērstu cerības, ka darījumi ietver secīgus pārkāpumus, nederīgumu.

Iespējamie EIP-5806 pielietojumi

EIP-5806 primārā pielietojamība ir EOA izpildes abstrakcija. Ļaujot EOA neuzticami mijiedarboties ar viedajiem līgumiem, ne tikai izmantojot vienkāršus izsaukumus uz to loģiku, tiek piešķirtas tādas funkcijas kā:

• Darījumu izpilde ar nosacījumiem
• Darījumu komplektēšana
• Vairāku zvanu darījumi (piemēram, apstiprināšana un zvanīšana)

EIP-5806 kritika

EIP-5806 ierosinātās izmaiņas, lai gan nodrošina nepieciešamās funkcijas, nav īpaši jaunas; tā pastāvēšana galvenokārt ir balstīta uz jau funkcionējošu EIP-7. Tas ļauj tai apiet daudzus potenciālos šķēršļus pieņemšanai.

Viena no galvenajām bažām, kas tika pausta tās pirmajās dienās, bija iespējamais risks, ka EOA varēs piekļūt krātuvei un to mainīt, tāpat kā to pašlaik dara CA. Tas izjauc daudzus tīklā ietvertos invariantus attiecībā uz to, kā EOA ir jādarbojas, un tas tika risināts, ieviešot iepriekšējā apakšiedaļā minētos ierobežojumus.

Otra kritika (kas ir nedaudz abpusēji griezīgs zobens) ir EIP-5806 vienkāršība; Pastāv zināms viedoklis, ka atlīdzība par EIP-5806 pieņemšanu varētu nebūt šo izmaksu vērta, jo tā nodrošina tikai izpildes abstrakciju, nevis daudz ko citu. Visi citi derīguma ierobežojumi paliek tīklā noteikti EOA, kas izvēlas EIP-5806, atšķirībā no citiem nedaudz līdzīgiem EIP, par kuriem mēs runājam turpmākajās apakšsadaļās.

Programmējamība, izmantojot EIP-3074

EIP-3074 ierosina ļaut EOA deleģēt lielāko daļu savas validācijas loģikas specializētiem līgumu kontiem, kas tiek dēvēti par atsauksmēm, uzliekot pēdējo autorizācijas loģiku pār savējiem īpašiem darījumu veidiem. Tas tiek panākts, parakstot savu piekļuves politiku izsaucēja līgumam, kas pēc tam kļūst atbildīgs par EOA piekļuves politikas noteikšanu.

Šajā EIP ir ierosināts EVM pievienot divus jaunus darbības kodus:

• [AUTH] kas iestata konteksta mainīgo [autorizēto] kontu, lai tas darbotos otra [iestādes] konta vārdā, pamatojoties uz tā ECDSA parakstu.
• [AUTHCALL] kas nosūta/īsteno [autoritātes] konta izsaukumus no/kā [autorizētā] konta.

Šie divi operāciju kodi ļauj EOA deleģēt kontroli iepriekš izveidotai CA un tādējādi darboties kā vienai caur to, neizvietojot līgumu un neradot ar to saistītās izmaksas un ārējās izmaksas.

EIP-3074 specifikācijas

EIP-3074 ļauj darījumiem izmantot [MAGIC] parakstīšanas formātu, lai novērstu sadursmes ar citiem darījumu parakstīšanas formātiem. Aktīvais konts, kuram tiek nodotas [AUTHCALL] instrukcijas, ir definēts kā konteksta mainīgā lauks ar nosaukumu [autorizēts], kas saglabājas tikai vienā transakcijā un ir jādefinē no jauna katram jaunam [AUTHCALL] .

Pirms katra operētājkoda sarežģītības risināšanas EIP-3074 darījumā iesaistītās vienības:

• [iestāde] : primārais parakstīšanas konts (EOA), kas deleģē piekļuvi/vadību otram kontam, kas parasti ir līguma konts.
• [autorizēts] : konts, kuram izpildei jānodod [AUTHCALL] norādījumi. Citiem vārdiem sakot, tas ir konts, kurā [AUTHCALL] loģika tiek izpildīta [iestādes] vārdā, izmantojot [izsaucēja] definētus ierobežojumus.
• [invoker] : papildu līgums, kas paredzēts, lai pārvaldītu mijiedarbību starp [autorizēto] kontu un [AUTHCALL] loģiku, jo īpaši gadījumos, kad pēdējā līguma koda primārā loģika ir gāzes sponsorēšana.

Izsaucēja līgumi saņem [AUTH] ziņojumus ar [COMMIT] vērtību no [iestādes]; šī vērtība nosaka ierobežojumus, ko konts vēlas noteikt [autorizēts] [AUTHCALL] instrukciju izpildei. Tādējādi izsaucēji ir atbildīgi par to, lai [autorizētā] kontā definētais [ contract_code ] nebūtu ļaunprātīgs un spētu apmierināt primārā parakstīšanas konta invariantus [COMMIT] vērtībā.

Opkodam [AUTH] ir trīs steka elementu ievades; vai vienkāršāk — to nosaka trīs ieejas, kas aprēķina vienu izvadi. Šīs ievades ir:

1. iestāde : kas ir parakstu ģenerējošās EOA adrese
2. kompensēt
3. garums

Pēdējās divas ievades tiek izmantotas, lai aprakstītu modificējamās atmiņas diapazonu no 0 līdz 97, kur:

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]

Mainīgie [yParity], [r] un [s] tiek kolektīvi interpretēti kā ECDSA paraksts [magic] secp256k1 līknē virs ziņojuma:

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

kur:

• [MAGIC] ir ECDSA paraksts, kas iegūts, kombinējot mainīgos:
• [chainID], kas ir pašreizējās ķēdes EIP 115 saderīgais identifikators, ko izmanto, lai nodrošinātu atkārtotu uzbrukuma aizsardzību alternatīvām EVM ķēdēm ar līdzīgu vēsturi un mazāku ekonomisko drošību.
• [nonce], kas ir darījuma parakstītāja pašreizējā nonce, kas ir papildināta ar 32 baitiem.
• [invokerAddress], kas ir līguma adrese, kas satur [AUTH] izpildes loģiku.
• [COMMIT] ir 32 baitu vērtība, ko izmanto, lai norādītu papildu transakcijas derīguma nosacījumus izsaucēja pirmapstrādes loģikā.

Ja aprēķinātais paraksts ir derīgs un parakstītāja adrese ir vienāda ar [autoritāte], lauks [autorizēts] tiek atjaunināts līdz [autoritāte] norādītajai vērtībai. Ja kāda no šīm prasībām nav izpildīta, lauks [autorizēts] paliek nemainīgs iepriekšējā stāvoklī vai kā atiestatīta vērtība.

Gāzes izmaksas šim opkodam tiek aprēķinātas kā summa:

1. Fiksēta maksa par [ecrecover] priekškompilāciju un papildu maksa par keccak256 hash un papildu loģika, 3100 vienību vērtībā

2. Atmiņas paplašināšanas maksa, kas tiek aprēķināta līdzīgi operācijas kodam [RETURN] un tiek piemērota, kad atmiņa tiek paplašināta, pārsniedzot pašreizējā piešķīruma norādīto diapazonu (97 vienības).

3. Fiksētās izmaksas 100 vienību apmērā par siltu [iestādei] un 2600 vienībām par aukstu, lai novērstu uzbrukumus valsts piekļuves operāciju kodu nepareizas cenas noteikšanas dēļ.

   
   

   ( AUTH tiek ieviests, lai nemodificētu atmiņu, un kā argumentu izmanto [autoritātes] vērtību, tāpēc ir triviāli pārbaudīt tās vērtību no nodrošinātā paraksta.)

Operatīvajam kodam [AUTHCALL] ir septiņas steka elementu ievades, ko izmanto, lai aprēķinātu viena steka elementa izvadi.

Tam ir tāda pati loģika kā [CALL] operācijas kodam, ti; to izmanto, lai nosūtītu ziņojumu zvanus uz kontu un iedarbinātu īpašu loģiku savos līgumos. Vienīgā novirze to loģikā ir tāda, ka [AUTHCALL] ir paredzēts, lai iestatītu [CALLER] vērtību pirms izpildes turpināšanas.

Tādējādi [AUTHCALL] lai aktivizētu kontekstam specifisku uzvedību [autorizēts] ar loģiskām pārbaudēm, kas notiek šādi:

1. Pārbaudiet [autorizētā] vērtību. Ja nav iestatīts, izpilde tiek uzskatīta par nederīgu un kadrs tiek nekavējoties iziets. Tas palīdz novērst netaisnīgu maksu nepieredzētu kļūmju dēļ.
2. Pārbauda [pilnvarotā] paredzētās darbības gāzes izmaksas.
3. Pārbauda [gāzes] operanda EIP-150 saderīgo vērtību.
4. Pārbauda kopējo gāzes izmaksu – [vērtība] – pieejamību [iestādes] bilancē.
5. Izpilde notiek pēc [vērtības] atskaitīšanas no [iestādes] konta atlikuma. Ja [vērtība] ir lielāka par to atlikumu, izpilde tiek anulēta.

Gāzes izmaksas par [AUTHCALL] tiek aprēķinātas kā summa:

• Fiksēta maksa par zvanu [warm_storage_read]
• Atmiņas paplašināšanas maksa [memory_expansion_fee] , kas tiek aprēķināta līdzīgi kā gāzes izmaksas operācijas kodam [CALL]
• Dinamiska maksa [dynamic_gas]
• Apakšzvana izpildes izmaksas [subcall_gas]

Datiem, kas atgriezti no [AUTHCALL] var piekļūt, izmantojot:

• [RETURNDATASIZE] — kas nospiež atgriešanas datu bufera lielumu uz izvades steku
• [RETURNDATACOPY] – kas kopē datus no atgriešanas datu bufera uz atmiņu.

Lai to visu apvienotu, izmantojot daudz mazāk tehnoloģiju; Ethereum darījumi parasti norāda divas vērtības:

1. tx.origin – kas nodrošina darījuma autorizāciju.
2. msg.sender – kurā darījums faktiski notiek.

EOA, kā minēts iepriekš, autorizācija ir cieši saistīta ar izpildi, ti ( tx.origin == msg.sender ). Šis vienkāršais invariants rada lielāko daļu problēmu, ko izskaidrojām šī pārskata apakšsadaļā “Konti un darījumu derīgums”.

[AUTH] ziņojumi no [autoritāte] ļauj tai kompensēt funkciju tx.origin uz [authorized], vienlaikus paliekot kā īsziņas sūtītājs. Tas arī ļauj definēt šīs privilēģijas ierobežojumus, izmantojot [COMMIT] vērtību. Pēc tam [AUTHCALL] ļauj [autorizētajam] piekļūt līguma loģikai, izmantojot [izsaucēju] kā starpnieku, lai nodrošinātu, ka līgums, kuram tas vēlas piekļūt, ir nekaitīgs. Tas nozīmē, ka katram [AUTHCALL] , [autorizēts] ir jānorāda konkrēts [izsaucējs] savam [COMMIT].

Iespējamie EIP-3074 pielietojumi

EIP 3074 galvenokārt ir atbildīgs par to, lai EOA varētu deleģēt savu autorizācijas loģiku citam kontam, tomēr tā atvērtais dizains ļauj daudz vairāk dažādos kontekstos. Visu EOA validācijas loģiku var abstrahēt, vajadzības gadījumā izsaucējam piemērojot dažādus ierobežojumus/jauninājumus. Daži no iespējamiem modeļiem, kuru pamatā ir to mērķa loģika, ietver:

• Nonce logic : EIP-3074 ļauj EOAs nonce palikt neskartiem pēc [AUTH] ziņojuma nosūtīšanas, savukārt tā nonce katram [AUTHCALL] ir atkarīgs no tā, ar kuru izsaucēju tas mijiedarbojas. Tādā veidā tas nodrošina EOA nepareizu paralēlismu, lai tie varētu nosūtīt vairākus nepārklājošus [AUTHCALL] kā viņi vēlas.
• Gāzes maksājumu loģika : kā noteikts EIP, izsaucējus var izveidot tā, lai atļautu sponsorēt gāzi. Tādējādi maksa par gāzi par lietotāja [COMMIT] var tikt atņemta no darījuma izcelsmes vai jebkura atbalsta konta, neatkarīgi no tā, vai tas ir personīgais vai uz pakalpojumu balstīts relejs (gāzes sponsorēšanas pakalpojumi). Arī izpildes loģika ir intuitīvi abstrahēta; galu galā izsaucējs (kas ir CA) tagad ir atbildīgs par darījumu pieprasījumu izpildi EOA vārdā.

EIP-3074 kritika

Izsaucēja centralizācija

Citējot vienu no tā autoriem: " Es negaidītu, ka maki varētu atklāt funkcionalitāti, kas parakstītu patvaļīgus izsaucējus … ". Iespējams, ka lielākā problēma, ko rada 3074 iniciatīva, ir tā, ka jauninājumi tās augšpusē ļoti viegli tiecas uz atļautu un patentētu darījumu plūsmu; tāpat kā pašreizējās Ethereum MEV (maksimālās ieguves vērtības) un PBS (ieteicēju un būvētāju atdalīšanas) tirgus iterācijas.

Pēc noklusējuma izsaucēju līgumi ir rūpīgi jāpārbauda, lai novērstu vēl sliktākus uzbrukumus, nekā pašlaik ir iespējams. Tas neizbēgami būs tendence uz ekosistēmu, kurā tikai daži ietekmīgu personu izstrādātie līgumi tiks pieņemti kā noklusējuma maka izstrādātāji. Tādējādi tas ir saistīts ar kompromisu starp:

• Izvēloties decentralizēto ceļu, pastāvīgi pārbaudot un atbalstot izsaucēju līgumus, riskējot ar lietotāju drošību
• Izsaucēju līgumu pieņemšana no atzītiem un cienījamiem avotiem ar labākām garantijām lietotāju drošībai un mazāku līguma drošības pārraudzību.

Vēl viens šī punkta aspekts ir izmaksu funkcija, kas saistīta ar funkcionāla un droša izsaucēja projektēšanu, auditēšanu un mārketingu. Mazākas komandas gandrīz vienmēr pārspēs lielākas organizācijas, īpaši mārketinga jomā, kurām jau ir zināma reputācija, pat ja to produkts ir labāks.

Pārsūtīšanas saderības problēmas

EIP-3074 iestrādā ECDSA parakstu shēmu, jo tā joprojām tiek uzskatīta par derīgāku nekā autorizācijas shēma, kas ieviesta, izmantojot izsaucēju. Lai gan pastāv argumenti, ka kvantu pretestība pašlaik nav galīga problēma (un nākotnē, kad ECDSA ir sabojājama, ir daudz sliktāks jautājums), Ethereum nedaudz nenoteiktais mērķis ir vienmēr būt priekšā šādām problēmām. Potenciāli upurēt kvantu un cenzūras pretestību nelieliem UX uzlabojumiem, iespējams, tuvākajā nākotnē nebūs labākā izvēle.

Vēl viens arguments par saderību nākotnē ir tāds, ka, lai gan 3074 priekšrocības vēl tika novērtētas, ERC-4337 (kas neprasa nekādas protokola izmaiņas) tagad ir liels tirgus, tāpēc jums ir jābūt saderīgam arī ar to, lai izvairītos no ekosistēmu sadalīšana. Pat izmantojot vietējo kontu abstrakcijas ceļvedi, operācijas kodi [AUTH] un [AUTHCALL] EVM galu galā novecos, radot Ethereum lielu tehnisko parādu, lai nodrošinātu nelielu UX uzlabojumu.

ECDSA shēmas neatsaucamība

Paredzams, ka pēc [AUTH] ziņojuma nosūtīšanas un kontroles deleģēšanas EOA izvairīsies no parastās privātās atslēgas autorizācijas shēmas, jo, nosūtot “parastu” darījumu, tiek atsaukta katram izsaucējam deleģētā autorizācija. Tādējādi ECDSA shēma joprojām ir stingri pārāka par jebkuru citu autorizācijas shēmu, ko var nodrošināt saistītie līgumi, kas nozīmē, ka privāto atslēgu zaudēšana izraisītu konta aktīvu pilnīgu zaudēšanu.

Programmējamība, izmantojot EIP-7702

Šis priekšlikums sākotnēji bija izklāstīts kā nedaudz minimālistisks EIP 3074 variants, un tas pat bija paredzēts tā atjauninājumam. Tas tika izveidots, lai novērstu iespējamās EIP 3074 neefektivitātes, jo īpaši bažas par tā nesaderību ar jau plaukstošo 4337 ekosistēmu un vietējā konta abstrakcijas priekšlikumu — RIP 7560.

Tās pieeja ir pievienot jaunu ar EIP 2718 saderīgu darījumu veidu — [SET_CODE_TX_TYPE] , kas ļauj EOA darboties kā viedam kontam noteiktiem darījumiem. Šis dizains nodrošina tādas pašas funkcijas kā EIP 5806 un dažas citas, vienlaikus saglabājot saderību ar vietējā konta abstrakcijas ceļvedi un esošajām iniciatīvām.

EIP-7702 specifikācijas

EIP-7702 ļauj EOA “importēt” līguma koda saturu, izmantojot [SET_CODE_TX_TYPE] 2718 saderīgu darījumu šādā formātā:

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

Šī kravnesība ir pilnībā līdzīga EIP 5806 kravnesībai, izņemot to, ka tajā ir iekļauts “autorizācijas saraksts”. Šis saraksts ir sakārtota formāta vērtību secība:

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

kur katrs kortežs definē [adreses] vērtību.

Pirms turpināt, SET_CODE_TX_TYPE iesaistītās puses ir:

• [iestāde] : kas ir EOA/primārais parakstīšanas konts
• [adrese] : tā konta adrese, kurā ir deleģējams kods.

Kad [iestāde] paraksta SET_CODE_TX_TYPE , norādot [adresi], tiek izveidots deleģēšanas apzīmējums. Šī ir “rādītāju programma”, kuras dēļ visi koda izguves pieprasījumi saistībā ar [iestādes] darbībām jebkurā brīdī tiek novirzīti uz [adreses] novērojamo kodu.

Katrai [chain_id, address, nonce, y_parity, r, s] kortei 7702 tipa transakcijas loģiskā plūsma ir šāda:

1. [Iestādes] paraksta pārbaude no sniegtā jaucējkoda, izmantojot: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Pārrobežu ķēdes atkārtošanas uzbrukumu un citu uzbrukumu vektoru novēršana, pārbaudot ķēdes ID.
3. Pārbauda, vai [iestādei] jau ir koda saturs.
4. Nonce pārbaude, lai pārliecinātos, ka [iestādes] nonce ir vienāda ar nonce, kas iekļauta kortežā.
5. Ja darījums ir [iestādes] pirmais SET_CODE_TX_TYPE darījums, no tā tiek iekasēta maksa PER_EMPTY_ACCOUNT_COST . Gadījumā, ja tās atlikums ir mazāks par šīs maksas vērtību, operācija tiek pārtraukta.
6. Notiek deleģēšanas apzīmējums, kurā [iestādes] kods ir iestatīts uz [adreses] rādītāju.
7. Parakstītāja nonce –[autoritāte] – tiek palielināta par vienu.
8. [iestāde] tiek pievienota sarakstam pieejamām adresēm, kas (pārāk vienkāršota) ir adrešu kopa, kas izveidota tā, ka darījuma apjoma atgriešana no tām izraisa to (adreses) atgriešanos iepriekšējā stāvoklī. , pirms tika ievadīts atgrieztais tvērums. Tas ir definēts EIP-2929, lai nodrošinātu atkārtoti lietojamu vērtību saglabāšanu kešatmiņā un novērstu nevajadzīgas maksas.

Fu! Sasiet to visu atpakaļ; šī EIP ļauj EOA nosūtīt darījumus, kas norāda uz līguma kodu, ļaujot tām īstenot šo loģiku kā savu turpmākajos darījumos. Tādā veidā tas ir stingri spēcīgāks par EIP 5806, jo tas ļauj EOA faktiski izmantot koda saturu tik ilgi, cik viņi vēlas (pretstatā EIP 5806, kas vienkārši ļauj EOA nosūtīt delegātu zvanus).

Iespējamie EIP-7702 pielietojumi

Izpildes abstrakcija

Lai gan varētu apgalvot, ka tā vairs nav abstrakcija, jo EOA aktīvi pārņem loģiku, ko tā vēlas izpildīt, tā joprojām nav minētās loģikas “galvenais īpašnieks”. Turklāt tas tieši nesatur loģiku, tas vienkārši norāda rādītāju uz loģiku (lai samazinātu skaitļošanas sarežģītību). Tātad mēs ejam ar izpildes abstrakciju!

Gāzes sponsorēšana

Lai gan require(msg.sender == tx.origin) invariants ir bojāts, lai atļautu pašsponsorēšanu, EIP joprojām ļauj integrēt sponsorētu darījumu pārraidītājus. Tomēr brīdinājums ir tāds, ka šādiem pārraidītājiem ir nepieciešama uz reputāciju vai likmes balstīta sistēma, lai novērstu bēdu uzbrukumus.

Nosacīta piekļuves politikas

EOA var norādīt tikai uz noteiktu konta koda daļu, tādējādi tikai šīs daļas loģika ir izpildāma to kontekstā.

Tas arī nodrošina apakšatslēgas , kas nodrošina “privilēģiju deeskalāciju”, tādējādi konkrētiem dapps var piekļūt konta atlikumam tikai īpašos apstākļos. Piemēram, varat iedomāties atļauju tērēt ERC-20 marķierus, bet ne ETH, vai tērēt līdz 1% no kopējā atlikuma dienā vai mijiedarboties tikai ar noteiktām lietojumprogrammām.

Pārrobežu ķēdes viedo līgumu izvietošana

Tā neierobežojošā rakstura dēļ EIP-7702 darījums var ļaut lietotājam piekļūt operācijas kodam CREATE2 un izmantot to, lai izvietotu baitkodu uz adresi bez citiem ierobežojošiem parametriem, piemēram, maksas tirgus loģikas (piemēram, EIP-1559 un EIP-4844). ). Tas ļauj adresi atgūt un izmantot vairākās stāvokļa mašīnās ar vienu un to pašu baitu kodu, kur tās konts katrā ķēdē ir atbildīgs par citu konteksta mainīgo parametru definēšanu.

EIP-7702 kritika

Atgriezeniskās saderības trūkums

Lai gan EIP-7702 vēl ir pavisam nesen, jau ir veikts daudz prototipēšanas un testēšanas, lai noteiktu tā atkarības un iespējamos trūkumus, taču tā minimālistiskais modelis garantē tam lielu elastību un līdz ar to arī lietderību dažādos kontekstos. Tomēr tas pārtrauc pārāk daudz invariantu un nav uzreiz saderīgs ar atpakaļejošu spēku. Dažas no EIP-7702 loģikas ietver:

1. Vidēja darījuma EOA bez izmaiņām: EIP-7702 neierobežo nevienu opkodu, lai nodrošinātu konsekvenci. Tas nozīmē, ka EOA, izpildot EIP-7702 transakciju, var ieviest operācijas kodus, piemēram, CREATE , CREATE2 un SSTORE , ļaujot to palielināt citā kontekstā.
2. Atļaujot kontus ar kodu, kas nav nulles codeHash vērtība, būt par darījumu iniciatoriem: EIP-3607 tika ieviests, lai samazinātu iespējamo “adreses sadursmes” ietekmi starp EOA un CA. Adrešu sadursme notiek, ja EOA adreses 160 bitu vērtība ir pilnībā līdzvērtīga CA adreses vērtībai.

Lielākā daļa lietotāju nepārzina faktisko konta saturu (vai pat atšķirību starp kontu un adresi!), tāpēc adrešu sadursmju atļaušana nozīmē, ka EOA var maskēties kā līguma konts un piesaistīt lietotāja līdzekļus ilgstošā situācijā. mazliet, lai galu galā to visu nozagtu. EIP-3607 to risināja, nosakot, ka kontiem, kuros ir kods, nevajadzētu tērēt atlikumu, izmantojot savu autorizācijas loģiku. Tomēr EIP 7702 pārtrauc šo invariantu, lai EOA varētu palikt autonomas pat pēc zināmas programmējamības iegūšanas.

Līdzība ar EIP-3074

Parakstīšanās, izmantojot konta adresi, nevis tā koda saturu, būtībā ir tāda pati kā 3074 shēma ar izsaucējiem. Tas nenodrošina stingras garantijas par starpķēžu koda satura konsekvenci, jo adrese dažādās ķēdēs var iegūt atšķirīgu koda saturu. Tas nozīmē, ka adrese, kuras koda saturs satur tādu pašu loģiku vienā ķēdē, var būt plēsonīga vai atklāti ļaunprātīga citā ķēdē, un tādējādi var tikt zaudēti lietotāja līdzekļi.

Secinājums

EOA to pašreizējā formā mūsdienās ir ļoti ierobežoti, jo tie neļauj lietotājiem izmantot EVM piedāvātās programmējamības funkcijas. Lai gan pastāv dažādi ceļi uz kontu jaunināšanu, kā mēs izklāstījām šī ziņojuma sākumā, izvēlētajam risinājumam ir jāsaglabā drošas un drošas pašpārvaldības principi. Turklāt EOA jauninājumi var būtiski ietekmēt gan lietotāju pieredzi, gan lietojumprogrammu izstrādātājus, tāpēc ir jāņem vērā visu ieinteresēto personu balsis.

Ļaujot EOA izpildīt kodu jebkurā veidā, ievērojami paplašina kontu funkcionalitāti, taču šī jaunā izteiksmība ir saistīta ar nozīmīgiem riskiem un iespējamām blindside. Šo kompromisu atrisināšana ir ļoti svarīga, lai nodrošinātu jaunināšanu ar neapstrīdētām UX priekšrocībām Ethereum lietotājiem.

Ethereum atklāto diskusiju kultūra padara to par lielisku šādu inovāciju izmēģinājumu laukumu, jo gandrīz visas katra dizaina sekas ir rūpīgi dekonstruējušas priekšmetu eksperti. Šim visaptverošajam apsvērumam vajadzētu palīdzēt mazināt pretinieku ļaunprātīgas darbības risku.

EIP-7702 pašlaik ir mehānismiem, kuru mērķis ir nodrošināt EVM programmējamību EOA, plakātu, kas Pectra jauninājumā ir atzīmēts kā EIP 3074 slota aizstājējs. Tas pārmanto 3074 mehānisma atvērto dizainu, vienlaikus ievērojami samazinot uzbrukuma virsmu/riskus. Tas arī nodrošina daudz vairāk, izvairoties no 3074 ierobežojumiem noteiktām opkodu klasēm.

Lai gan priekšlikuma dizainā joprojām tiek veikti daži uzlabojumi, tas jau ir guvis lielu labo gribu un izstrādātāju atbalstu, jo īpaši tāpēc, ka to tieši atbalsta Vitaliks. Sabiedrībā izskan apgalvojumi, ka šī pieeja kontu abstrakcijai varētu būt pat labāka nekā viedie konti. Šis komentārs uzsver, ka šis ceļš prasa mazāk izmaiņu un nav tik sarežģīts, un ka EOA jau ir nostiprinātas.

Tomēr mums ir jāatceras kvantu pretestības nākotnes drošības pavērsiens visos Ethereum tīkla līmeņos. Šī kvantu drošība nav iespējama ar tekošā konta modeļa kodolu, jo EOA autorizācijai tiek izmantotas uz ECDSA balstītas parakstu shēmas.

Tādējādi EOA programmējamība ir jāuzskata par soli ceļā uz viedkontiem, nevis galamērķi. Tas uzlabo EOA un nodrošina labāku lietotāja un izstrādātāja pieredzi, vienlaikus saglabājot saderību ar viedo kontu galveno kontu abstrakcijas mērķi.

Nākamajā pārskatā mēs iedziļināsimies EOA migrācijas shēmās, lai redzētu, cik labi tās iekļaujas kontu abstrakcijas ceļvedī. Sekojiet līdzi jaunumiem!