Цртеж на патоказот за апстракција на сметката Ethereum I: EIP-3074, EIP-5806 и EIP-7702

Откако ги набљудувавме значајните промени што беа воведени во Ethereum преку надградбата на Deneb, почнавме да гледаме напред кон она што ќе го претстави следниот хардфорк, Pectra. За да помогнеме во обликувањето на претстојните дискусии, настојуваме да го опишеме тековниот пејзаж на апстракција на сметките што го опкружува Ethereum и неговиот екосистем за собирање за потенцијално да мапира јасен пат напред.

Овој извештај дава преглед на моделот на тековната сметка на Ethereum, особено нивните ефекти врз валидноста на трансакцијата, што точно подразбира апстракцијата на сметката и рамка за расудување за тоа. Потоа ќе се фокусираме на пристапот за програмабилност на EOA со евалуација на EIPs 5086, 3074 и 7702 и ќе заклучиме со тоа како сето ова веројатно ќе влијае на иднината на трансакциите на Ethereum.

Иако има многу конфузија околу тоа што е или не е апстракцијата на сметката, нашата рамка низ оваа серија е дека секој механизам што дозволува сметката да редефинира кој било дел од нејзините правила за валидност е механизам за апстракција на сметката. Понатаму, даваме класификација на овие механизми, бидејќи повеќето од нив се нејасно слични и се преклопуваат.

Преглед на апстракција на сметката во Ethereum

Апстракција на сметката се обидува да ги подобри искуствата на корисниците и развивачите низ целиот екосистем на Ethereum. Заедно со правењето искуства во синџирот подостапни и попријатни за корисниците, исто така ги овластува програмерите да можат да прават помоќни работи на Ethereum и да им служат на корисниците на уште позначајни начини.

Нашата класификација на пристапите за апстракција на сметката е како што следува:

1. Подобрување/програмабилност на EOA : Ова вклучува промени на ниво на протокол кои им овозможуваат на EOA (надворешни сметки во сопственост) да го редефинираат логичкиот дел за извршување на нивните правила за валидност. Како што се добро познати во развојната заедница, EOA се сметки обично поврзани со крајните корисници. Затоа, решенијата што спаѓаат во овој пристап ќе им овозможат на сметките на крајните корисници со поголема контрола врз тоа какви дејства можат да авторизираат, во споредба со тоа како може да се управува денес.

2. Конверзија/миграција на EOA : Овој пристап вклучува предлози кои бараат целосна конверзија на EOA во CA (сметки со договор). Интегралната идеја на овој пристап е дека договорните сметки веќе ги нудат повеќето од придобивките што ги нудат паметните сметки, така што повеќе не треба да има потреба да се комплицираат работите; секој треба едноставно да користи договорна сметка како своја примарна сметка (преку паметни паричници со договори).

Овој пристап се одликува со механизми кои овозможуваат EOA да премине кон CA, без да мора да ги преместува своите средства, како што се EIP 7377 и EIP 5003 (кога се разгледуваат заедно со EIP 3074).

3. Паметни сметки : оваа група на предлози вклучува дизајни што им овозможуваат и на EOA и на CA да се однесуваат како „паметни сметки“ дозволувајќи им целосно да ги редефинираат своите правила за валидност.

Претходно беа дадени различни предлози за создавање паметни сметки и опфат на апстракција на сметки на ниво на протокол; EIP-86 и EIP-2938 се некои од поцитираните. Сепак, имаше многу притискање поради воочената сложеност воведена со овој дизајн и малку мнозинското мислење дека Ethereum не е подготвен за таква сложеност.

По оживувањето на темата од страна на Виталик по Спојувањето, ERC-4337 беше предложен како опција за вклучување на стандардот за паметни сметки, слична на инфраструктурата PBS (Одделување на предлагач-градител) за MEV (Maximal Extractable Value). Така, корисниците кои сакаат да пристапат до придобивките од паметните сметки може едноставно да го користат нафтоводот ERC-4337 за да ја редефинираат логиката на нивната сметка и правилата за валидност на трансакциите во структурите наречени UserOperation (или накратко UserOps ).

ERC 4337 ги носи придобивките од паметните сметки на денешниот Ethereum без да внесува ништо од сложеноста, со тоа што функционира како алтернатива надвор од протоколот на вградените паметни сметки. Сепак, ова не значи дека инфраструктурата е оптимална во нејзината сегашна состојба бидејќи нејзината сопствена сложеност е сè уште значителна точка на неуспех.

За да се одговори на оваа сложеност, RIP 7560 беше изготвен како вградена верзија на ERC 4337 инфраструктурата низ Ethereum и неговите L2, така што тој ги наследува шемите на мрежата за отпорност на sybil наместо да мора да дефинира нов пакет правила (како што прави ERC 4337 со ERC 7562 ).

Во овој извештај, ќе бидеме фокусирани на истражување на програмибилноста на EOA, оценувајќи ги различните EIP-и кои ги опишуваат решенијата по оваа линија и дискутираат за нивните предности и недостатоци. Во Дел 2 и 3 од оваа серија, ќе ги покриеме преостанатите две класи на пристап кон апстракција на сметката што се истражуваат во рамките на Ethereum.

Прајмер за сметките и трансакциите на Ethereum

За да бараме што може да се апстрахира, потребна ни е (донекаде) целосна слика за дизајнот на тековната сметка. Овој дел најмногу ќе служи како вид на ревизија за тоа какви се сметките на Ethereum всушност и како нивните трансакции се потврдени и извршени.

Сметките на Ethereum се ентитети со салдо на етер (ETH) и можност за испраќање трансакции на блокчејнот на Ethereum. Тие се претставени како хексадецимална „адреса“ од 42 знаци, која служи како уникатен покажувач за чувањето и трансакциите на сметката.

Адресата делува како клуч во состојбата на блокчејнот. Листовите јазли на овој обид се структури на податоци на сметката кои можат да се разложат на четири полиња:

1. nonce : Линеарен бројач што се користи за означување на бројот на излезни трансакции иницирани од сметката. Тоа е исто така клучно за спречување на напади со повторување.
2. balance : веи-деноминирана количина на етер (ETH) во сопственост на сметка.
3. codeHash : хаш од извршниот код од EVM содржан во сметката. EVM (Виртуелна машина Ethereum) е нарачана околина за извршување на Ethereum одговорна за справување со сложени транзиции на состојби надвор од едноставни трансакции „испрати“. Содржината на кодот на сметката е непроменливо програмирана да врши специфични форми на транзиција на состојбата на блокчејнот Ethereum, преку EVM.
4. storageHash : хаш од коренот за складирање на сметката, кој се користи за претставување на содржината за складирање на сметката како 256-битен хаш на коренскиот јазол на merkle patricia trie. Едноставно, тоа е хаш од податоците за променливата состојба поврзани со содржината на кодот на сметката.

Содржината на овие четири полиња се користи за дефинирање на типот на сметката и на крајот продолжува да го дефинира обемот на нејзините функционалности. Така, двата вида на сметки на Ethereum се:

1. Надворешни сметки (EOA) - кои се иницијализирани како криптографски пар клучеви:

• Приватен клуч кој е шифриран и докажлив случаен знак од 64 хексадецимален карактер и негов комплементарен пандан;
• Јавен клуч кој е изведен од приватниот клуч со помош на ECDSA (Elliptic Curve Digital Signature Algorithm).

EOA имаат празни полиња за codeHash и storageHash и може да ги контролира само секој што ги поседува приватните клучеви. Нивните адреси може да се добијат од соодветниот јавен клуч со префиксирање „0x“ на последните дваесет знаци од хашот keccak-256 на јавниот клуч на сметката.

2. Договорни сметки (CAs) кои може да се креираат само од претходно постоечки EOA. Тие се иницијализирани поради EOA што распоредува содржина на извршна шифра на EVM. Оваа содржина на кодот (зачувана како codeHash) е вградена во EVM и е одговорна за контрола на сметката преку дефинирање на нејзината логика и интеракции.

Трансакциите од сметката на договорот се целосно засновани на влечење засновани на логиката на нивниот распореден код. Бидејќи овие сметки може да се контролираат само со нивната содржина на код, тие немаат потреба од приватен клуч и имаат само јавен клуч. Така, секој агент кој има можност да ја ажурира/променува содржината на кодот на сметката на договорот ќе може да пристапи до нејзиното салдо. Адресата на сметката на договорот е изведена од адресата на нејзиниот креатор и нејзината непотребност до моментот на распоредување на договорот.

Трансакции

Неодамна ги опишавме сметките како ентитети кои поседуваат можност да испраќаат трансакции преку Ethereum. Затоа, можеме да разбереме дека основната цел на сметката е да испраќа и прима трансакции, додека блокчејнот делува како книга за снимање историја на трансакции, како и опишување како трансакциите ги менуваат полињата на сметката врз основа на правила опишани во спецификацијата на протоколот за блокчејн.

Па што се овие „трансакции“?

Трансакциите се операции испратени од сметка, кои предизвикуваат промена во „состојбата“ на мрежата. Тие се криптографски потпишани инструкции од сметки, кои резултираат со ажурирање на состојбата на целата мрежа кога се извршуваат.

Недозволата доаѓа со цената на перверзните стимулации, за да се справиме со нив, треба да се дефинираат строги упатства (или правила за валидност) за интеракции во такви средини. Во овој контекст, трансакциите треба да следат одредени правила за валидност за да се сметаат за валидни и извршени. Повеќето од овие правила за валидност се имплементирани преку ограничувања поставени на сметката што ја испраќа трансакцијата и варираат во зависност од тоа каков тип на сметка се работи.

Сметки и валидност на трансакцијата

На Ethereum, EOA се оптимизирани за употребливост бидејќи се соочуваат со крајниот корисник. Тие имаат можност да испраќаат трансакции на специфичен начин и совршено да работат автономно. Тие исто така може да се креираат локално, а најчестиот метод е употребата на даватели на паричник како што се MetaMask, Rainbow, Rabby итн.

Од друга страна, договорните сметки можат да испраќаат само трансакции дозволени според нивната логика, како одговор на „ повикувањето “. Исто така, тие можат да бидат креирани само од страна на EOA која има доволно салдо за да плати за неговото државно складирање.

Опис на повисоко ниво би бил дека EOA може да одржуваат само рамнотежа, додека CA може да држат и рамнотежа и логика што диктира како може да се троши овој биланс. Овие својства се должат на следните логички параметри кои ги дефинираат правилата до кои треба да се придржуваат трансакциите на сметката:

1. Логика за автентикација - Се користи за да се дефинира како сметката го докажува својот идентитет на мрежата додека го менува салдото и/или логиката.
2. Логика за овластување - Се користи за дефинирање на политиката за пристап на сметката, т.е., кој може да пристапи и да направи промени на состојбата и/или логиката на сметката.
3. Nonce логика - која го дефинира редоследот по кој треба да се извршат трансакциите од сметката.
4. Логика за плаќање гас - Се користи за дефинирање на страната одговорна за подмирување на надоместокот за гас на трансакцијата.
5. Логика на извршување - Се користи за да се дефинира какви форми на трансакции може да испрати сметката или како да се изврши трансакцијата.

Овие параметри се дизајнирани да бидат ригидни за EOA на тој начин:

• Автентикацијата и овластувањето се обезбедуваат со приватен клуч базиран на ECDSA, т.е., корисникот кој сака да испрати трансакција од својот EOA мора да го користи својот приватен клуч за пристап до сметката и на тој начин да докаже дека има право да изврши какви било промени на нејзиното салдо. .
• Логиката nonce имплементира шема на секвенцијален бројач, која дозволува само една трансакција по единствена нонс да се изврши последователно по сметка.
• Логиката за плаќање на гас одредува дека надоместокот за гас за трансакциите мора да биде подмирен од сметката на испраќачот/изворот.
• Логиката на извршување специфицира дека EOA може да ги испраќаат само следните формулари за трансакција:

1. Редовни трансфери помеѓу две EOA.
2. Распоредување на договор.
3. повици за договор кои се насочени кон логиката на сметката на распоредениот договор.

Поопшто, логиката на извршување на EOA ги ограничува на една трансакција по валиден потпис.

Од друга страна, CA имаат поголема флексибилност околу овие параметри:

• Автентикацијата не е потребна, бидејќи нивните трансакции се последователни/базирани по природа.
• Овластувањето за CA може да има две форми:

1. Способност да се „ повика “ кодот на содржината на CA (или да се изврши неговиот паметен договор), што зависи од логиката на паметниот договор на сметката и неговите непроменливи.
2. Можност за правење промени во кодот за содржина на CA, што најмногу зависи од тоа дали кодот за содржина може да се надградува или не.

Во повеќето практични случаи, логиката што се користи во овој случај е шема со повеќе потписи која пропишува дека M од N валидни потписи (каде што M <N) се бара од одредени сметки (најчесто EOAs) со цел да се промени логиката на CA да важи.

• Нивното нарачување трансакции не се заснова на лабаво. Самиот CA може да испрати што повеќе трансакции до што е можно повеќе различни повикувачи , но секој повикувач е ограничен врз основа на нивните сопствени способности.
• Плаќањето за гас најчесто се врши од страна на повикувачот на логиката на CA.
• Логиката на извршување на CA е поразновидна за да овозможи UX подобрувања како што се трансакции со повеќе повици и атомски трансакции.

Оценувајќи ги овие карактеристики, забележуваме дека секој тип на сметка е дизајниран да има компромис помеѓу автономијата и програмабилноста.

EOA имаат целосна автономија, но ограничена програмабилност; тие можат да овластат и испраќаат трансакции кога сакаат, но овие трансакции мора да следат ригиден формат за да се сметаат за валидни. Договорните сметки имаат целосна програмабилност (ограничена само со дизајнот на EVM), но ограничена автономија: нивните трансакции не мора да следат некој ригиден формат, туку може да се испратат само поради нивната логика што е прво повикана.

Во следниот потсекција, сега ќе ги проучуваме импликациите на овие дизајни избори, со цел целосно да го разбереме предлогот на секој дискутиран EIP низ оваа серија.

Дилема на сметката на Ethereum

Сега, кога имаме малку прецизно познавање за функционалностите на различните сметки, лесно можеме да ги идентификуваме нивните продажни точки, како и проблемите што тие ги претставуваат и на искуството на корисниците и на развивачите на Ethereum. Како што претходно споменавме, EOA се дизајнирани како првокласни сметки насочени кон крајните корисници. Апликациите се дизајнирани за лесно да комуницираат со нив, речиси и да нема сложеност за нив и, се разбира, нема трошоци за создавање. Сепак, неговата едноставност доаѓа со значително губење на новина бидејќи тие се дизајнирани да бидат строго детерминистички.

Некои од грижите околу нив се:

1. Подложност на квантни напади - Шемата за потпис ECDSA што ја користи нивниот пар клучеви не е квантно отпорна и со оптимистичка временска рамка од 5 до 10 години за индустриски квантни системи што се постигнуваат, ова претставува значајна закана за Ethereum и неговите апликации на кои многу се потпираат на ECDSA шемата за криптографски докази и безбедност.
2. Недостаток на изразување - Цврстиот формат на правилата за валидност на EOA ја елиминира способноста на корисниците да ги изразат своите трансакции попрецизно преку карактеристики како што се атомичноста на трансакцијата и групирање, и делегирање на трансакциите.
3. Самоодржливост - Секој имаше свој соодветен дел од моментите „снемав бензин“ среде трансакција. Ова се должи на барањето EOA да го решаваат гасот за нивните трансакции сами, што не би било многу важно дали етерот (ETH) не е единствената прифатлива валута за гас. Иако ова е општ проблем со државните машини засновани на сметка (па дури и оние базирани на UTXO), Ethereum секогаш имал намера да биде различен.

Не секој сака (или би можел) секогаш да држи ETH (мислам погледнете ја таа цена), така што остварливите решенија би биле или да се дозволат повеќе валути на гас (премногу тешко, прекинува премногу непроменливи како што е опишано во „Валута ” дел овде ), или да дозволите плаќањата за гас да се подмируваат со друга сметка што не е потеклото на трансакцијата.

На другиот крај од спектарот на сметките, CA таргетираат програмери и потехничка корисничка база. Тие служат како средства за паметни договори (т.е. сметаме дека паметните договори се нивната содржана логика или содржина на код) и затоа можат да имплементираат нови формати на трансакции како што е овозможено од EVM.

Сепак, за сите овие карактеристики тие се глорифицирани сметки од втора класа бидејќи немаат автономија. Некои од нивните недостатоци се како што следува:

1. Тотален недостаток на автономија - CA не можат да започнат трансакција, тие можат само да испраќаат трансакции како одговор на нивното повикување на многу специфичен начин.
2. Подложност на човечка грешка во нивната логика – Недостатокот на ригидност често доведува до неточна дефиниција на непроменливи и други такви логики, што доведе до загуби од милијарди долари поради искористувања на паметни договори и хакери. Сепак, ова е речиси сосема друга тема која е надвор од нашиот опсег овде.

Откако ги разгледавме дизајнерските избори што доведоа до прашањата дефинирани во оваа потсекција, сега можеме да продолжиме да ги оценуваме предложените решенија.

Временска рамка за апстракција на сметката

За да бараме што може да се апстрахира, потребна ни е (донекаде) целосна слика за дизајнот на тековната сметка. Овој дел најмногу ќе служи како вид на ревизија за тоа какви се сметките на Ethereum всушност и како нивните трансакции се потврдени и извршени.

Концептот на апстракција на сметки (барем преку паметни сметки) отсекогаш бил составен дел од патоказот на Ethereum. Најавата е дека сложеноста околу неговата имплементација се закануваше дополнително да го одложи лансирањето на Ethereum, и затоа беше отфрлен поради тековниот дизајн со различни сметки кои нудат различни функционалности. Повторно беше одложен поради фокусот на Ethereum на The Merge и сега повторно се појавува како главен дел од следната голема надградба на мрежата - Pectra. Сепак, неговата сложеност сè уште се смета за значителен недостаток што го спречува неговото зацврстување, особено затоа што Ethereum се сврте кон патоказот насочен кон собирање.

Барањата сега се двојни:

1. Стандардите за сметки треба да бидат поизразени, но без губење на автономијата. Нов стандард кој ја запечатува поделбата помеѓу стандардите на EOA и CA.
2. Новиот стандард треба да го премости јазот помеѓу EOA и CA, додека останува целосно компатибилен низ Ethereum и неговите L2 екосистеми.

Интуитивно овој концепт игра поголема улога во контекст на апстракција на синџирот и интероперабилност. Сепак, нашиот опсег низ овој извештај е ограничен на техничките иницијативи преземени за да се постигне самата апстракција на сметката.

Апстракцијата на сметката има за цел да ги комбинира најдобрите карактеристики на EOA и CA во нов стандард на сметка – паметни сметки , кои овозможуваат целосно или делумно раздвојување на правилата за валидност на која било сметка во логика за валидација и извршување; така што сметките можат да ги дефинираат сопствените правила за валидност - како што е дозволено од EVM - исто како и сметките со договор, додека остануваат целосно автономни исто како сметките во надворешна сопственост.

Често постои конфузија околу разликите помеѓу паметните сметки и паричниците со паметни договори , па ајде експлицитно да опишеме кои се овие разлики подолу:

• Паметните сметки се сметки на Ethereum кои се конципирани за да обезбедат еднакви делови на програмибилност и автономија. Идејата е дека и EOA и CA можат да станат паметни сметки едноставно со користење на некој механизам (на пр. ERC 4337) кој им овозможува да ги заменат нивните правила за валидност наметнати од мрежата со нарачани правила за валидност, како што им одговара.
• Паметните договорни паричници од друга страна, се едноставно провајдери на паричници кои служат како интерфејси за договорни сметки (да, паричникот не е сметка).

Комерцијализацијата на паричниците со паметни договори го олесни усвојувањето на CA од страна на поширок пазар, дозволувајќи им на помалку технички корисници да ги искористат предностите на функциите што ги нудат. Сепак, тие сè уште се соочуваат со стапици поврзани со CA.

Назад кон разговорот; претходно разговаравме за параметрите кои се користат за дефинирање на правилата за валидност на трансакциите на сметките:

• Автентикација
• Овластување
• Нема логика
• Логика за плаќање гас
• Логика на извршување

Вредностите на првите четири параметри може колективно да се нарекуваат логика за валидација на сметката, што се проверки што се случуваат пред да започне извршувањето на трансакцијата. Последниот параметар дефинира како ќе продолжи извршувањето на трансакцијата.

Во воведот, дадовме преглед на високо ниво на тековниот пејзаж АА во форма на класификација за различните предложени дизајни. Сега ќе се фокусираме на првата класа решенија за дилемата на сметката на Ethereum- EOA програмабилност.

Програмабилни EOA

Најголемата привлечност на Ethereum е неговиот млад, но енергичен екосистем DeFi, кој располага со различни децентрализирани апликации кои се негови примарни средства за ликвидност. Повеќето од овие DApps се оптимизирани за да им служат на EOA, така што тешко се поврзуваат со договорните сметки и на крајот паметните сметки. Додека паричниците со паметни договори помагаат на договорните сметки во овој случај, тие доаѓаат со свои ограничувања и сосема поинаков UX.

Привремено решение што се истражува додека и DApps и давателите на паричник се навикнуваат на стандардот за паметни сметки, е да се обезбедат привремени подобрувања на EOA кои ќе им овозможат да ги надминат повеќето од нивните наметнати ограничувања, било да е тоа нивната логика за валидација или извршување. Подолу, ги разгледуваме спецификациите на трите главни EIP-и кои обезбедуваат дејствија правци до програмабилноста на EOA; од помалку познатиот EIP 5806 , до амбициозниот EIP 3074 и потоа конечно до победничкиот EIP 7702 .

Програмабилност преку EIP-5806

Овој предлог се обидува да донесе повеќе функционалност на стандардот EOA со тоа што ќе му дозволи да врши делегирање на повици до логиката на договорната сметка (неговиот паметен договор). Ова ефективно предизвикува смарт-договорот да се изврши во контекст на EOA на повикувачот, т.е. EOA останува во контрола на неговата логика за валидација, додека неговата логика на извршување се управува со логиката на соодветната сметка на договорот.

Пред да продолжиме понатаму, дозволете ни да патуваме низ патеката за меморија за еволуција на Ethereum до EIP-7 . EIP-7 предложи создавање на оптички код 0xf4/DELEGATECALL , кој се користи за испраќање повици за пораки во примарна сметка со логика на секундарна сметка, додека се одржуваат вредностите на полињата [испраќач] и [вредност] на примарната сметка. Со други зборови, примарната сметка ја „наследува“ (или ја позајмува ако сакате) логиката на секундарната сметка за одредено времетраење како што е наведено во повикот на пораката, така што логиката на втората се извршува во контекст на првото.

Овој оптички код им овозможи на развивачите на dapp да ја поделат логиката на нивната апликација на повеќе паметни договори додека одржуваат меѓусебна зависност, така што тие лесно би можеле да ги заобиколат бариерите за големината на кодот и бариери за гас. EIP-5806 наоѓа нова употреба за оптичкиот код DELEGATECALL што не дозволува меѓузависните сметки на договори. Поточно, EIP-5806 користи EIP-7 како инспирација за да предложи проширување на функционалноста за повик на делегати и на EOA; т.е., да дозволиме EOA да бидат меѓусебно зависни со договорните сметки, затоа што да не.

Спецификации на EIP-5806

EIP 5806 воведува нов тип трансакција во согласност со EIP-2718, кој е спакуван на следниов начин:

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

Овие трансакции се дизајнирани така што полето [to] – кое ја претставува адресата на примачот – може да прифаќа адреси само како влезови од 20 бајти, оневозможувајќи го испраќачот да го користи CREATE оптичкиот код.

Мотивацијата зад секоја компонента на шемата RLP е како што следува:

• ChainID : Идентификаторот на тековниот синџир што е во согласност со EIP-115 е пополнет на 32 бајти. Оваа вредност обезбедува заштита од напади со повторување, така што трансакциите на оригиналниот синџир не се тривијално реплицирани на алтернативни EVM синџири со слична историја и помала економска безбедност.
• nonce : Уникатен идентификатор за секоја трансакција кој исто така обезбедува заштита од напади од повторување.
• max_priority_fee_per_gas и max_fee_per_gas : Вредностите на надоместокот за гас што треба да го плати трансакцијата EIP-5806 за нарачка и вклучување соодветно.
• gas_limit : Максималната количина на гас што може да ја потроши една трансакција од типот 5806.
• дестинација : примачот на трансакцијата
• податоци : содржината на извршниот код
• access_list : Агенти кои се условно овластени да извршуваат трансакции со EIP-5806.
• signature_y_parity, signature_r и signature_s : три вредности кои заедно претставуваат потпис secp256k1 над пораката — keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

Додека пакувањето на трансакциите EIP-5806 во пликовите EIP-2718 им овозможува да бидат во голема мера компатибилни наназад, EOA не се еквивалентни на сметките со договор. Значи, одредени ограничувања мора да се дефинираат на начинот на кој EOA ги користи делегатните повици за да спречи непроменливо кршење.

Овие ограничувања се насочени кон следните оптички кодови:

• SSTORE/0x55 : Овој оптички код дозволува сметката да зачува вредност во складиштето. Тоа е ограничено во трансакциите на EIP-5806 за да се спречи EOA да поставува/пристапува до складиштето користејќи делегатски повици, со што ќе се спречат потенцијалните проблеми што може да се појават во иднина поради миграција на сметката.
• CREATE/0xF0 , CREATE2/0xF5 и SELFDESTRUCT/0xFF : овие оптички кодови опширно му дозволуваат на повикувачот да креира нова сметка. Пристапот до нив е ограничен за да се спречи промена на нецелата на EOA во различна рамка за извршување (создавање/уништување на договор во овој случај) додека врши трансакција EIP-5806, со цел да се спречи неважење на очекувањата дека трансакциите носат последователни неуспеси.

Потенцијални апликации на EIP-5806

Примарната применливост на EIP-5806 е апстракција за извршување за EOA. Дозволувањето на EOA да комуницираат без доверба со паметните договори надвор од едноставните повици до нивната логика, им дава карактеристики како што се:

• Условно извршување на трансакции
• Серии на трансакции
• Трансакции со повеќе повици (на пр. одобрувајте и повикајте)

Критики на EIP-5806

Промените предложени од EIP-5806, иако ги овозможуваат потребните функции, не се особено нови; неговото постоење е претежно засновано на веќе функционален EIP-7. Ова му овозможува да заобиколи многу потенцијални пречки за прифаќање.

Една од главните грижи искажани во првите денови беше потенцијалниот ризик од дозволување на EOA да пристапуваат до складиштето и да го менуваат, исто како што тоа го прават моментално CA. Ова прекршува многу непроменливи мрежни непроменети во врска со тоа како треба да се врши трансакција на EOA, и така беше решено со воведување на ограничувањата споменати во претходната потточка.

Втора критика (што е малку меч со две острици) е едноставноста на EIP-5806; Постои мислење дека наградите поради прифаќањето на EIP-5806 можеби не се вредни за цената, бидејќи овозможува само апстракција на извршувањето, а не многу друго. Секое друго ограничување на валидноста останува мрежно дефинирано за EOA кои се определуваат за EIP-5806, за разлика од другите донекаде слични EIP за кои разговараме во следните потсекции.

Програмабилност преку EIP-3074

EIP-3074 предлага да им се дозволи на EOA да го делегираат најголемиот дел од нивната логика за валидација на специјализирани сметки на договор, наречени повикувачи, со наметнување на логиката за овластување на второто над нивната за специфични форми на трансакции. Тоа го постигнува со потпишување на нивната политика за пристап до договор за повикувач, кој потоа станува одговорен за дефинирање на политиката за пристап на EOA.

Овој EIP предлага додавање на два нови оптички кодови на EVM:

• [AUTH] што поставува [овластена] сметка со контекстуална променлива да дејствува во име на втора сметка [авторитет], врз основа на потписот на ECDSA на вториот.
• [AUTHCALL] кој испраќа/имплементира повици за сметката [авторитет] од/како [овластена] сметка.

Овие два оптички кодови му овозможуваат на EOA да ја делегира контролата на претходно воспоставена CA, и на тој начин, да дејствува како едно преку него, без да мора да распореди договор и да ги сноси трошоците и надворешните ефекти поврзани со тоа.

EIP-3074 спецификации

EIP-3074 дозволува трансакциите да користат формат за потпишување [MAGIC] за да се спречат судири со други формати за потпишување трансакции. Активната сметка на која се пренесуваат инструкциите [AUTHCALL] е дефинирана како поле за контекст-променлива именувано [authorized], кое опстојува само преку една трансакција и мора да се редефинира за секоја нова [AUTHCALL] .

Пред да се разгледаат сложеноста на секој оптички код, ова се ентитетите вклучени во трансакцијата EIP-3074:

• [авторитет] : Примарната сметка за потпишување (ЕОА) која делегира пристап/контрола на втора сметка, која обично е сметка на договор.
• [authorized] : Сметката на која треба да се пренесат инструкциите [AUTHCALL] за извршување. Со други зборови, тоа е сметката во која се извршува логиката на [AUTHCALL] , во име на [авторитетот], со користење на ограничувања дефинирани од [инвокатор].
• [повикувач] : Договор за помошник наменет за управување со интеракциите помеѓу [овластена] сметка и логиката на [AUTHCALL] , особено во случаи кога примарната логика на кодот на договорот на вториот е спонзорство за гас.

Договорите за повикувачи добиваат пораки [AUTH] со вредност [COMMIT] од [овластување]; оваа вредност ги дефинира ограничувањата што сметката сака да ги постави на [овластено] извршување на инструкциите за [AUTHCALL] . Така, повикувачите се одговорни да осигураат дека [ contract_code ] дефиниран во [овластен] сметка не е злонамерен и има способност да ги задоволи непроменливите ставени од примарната сметка за потпишување во вредност [COMMIT].

Оптичкиот код [AUTH] има три влезни елементи на стек; или поедноставно - се дефинира со три влеза кои пресметуваат еден излез. Овие влезови се:

1. орган : која е адресата на EOA која го генерира потписот
2. офсет
3. должина

Последните два влеза се користат за опишување опсег на модифицирана меморија од 0 до 97, каде што:

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]

Променливите [yParity], [r] и [s] колективно се толкуваат како потпис ECDSA, [magic], на кривата secp256k1 над пораката:

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

каде:

• [MAGIC] е потпис на ECDSA што произлегува од комбинацијата на променливите:
• [chainID] што е идентификатор во согласност со EIP 115 на тековниот синџир што се користи за да обезбеди заштита од напади од повторување на алтернативни EVM синџири со слична историја и помала економска безбедност.
• [nonce] што е тековната нонс на адресата на потписникот на трансакцијата, лево поместена на 32 бајти.
• [invokerAddress] што е адресата на договорот што ја содржи логиката за извршување на [AUTH] .
• [COMMIT] е вредност од 32 бајти што се користи за одредување дополнителни услови за валидност на трансакцијата во логиката на претходна обработка на повикувачот.

Ако пресметаниот потпис е валиден и адресата на потписникот е еднаква на [овластување], полето [овластено] се ажурира до вредноста дадена од [овластување]. Ако некое од овие барања не е задоволено, полето [овластено] останува непроменето во претходната состојба или како непоставена вредност.

Цената на гасот за овој оптички код се пресметува како збир од:

1. Фиксна такса за прекомпајлот [ecrecover] и дополнителна за хаш keccak256 и некоја дополнителна логика, вредна 3100 единици

2. Надоместок за проширување на меморијата што се пресметува слично на [RETURN] оптичкиот код и се применува кога меморијата се прошири надвор од наведениот опсег на тековната распределба (97 единици)

3. Фиксна цена од 100 единици направени за топол [авторитет] и 2600 единици за ладен за да се спречат напади поради погрешни цени на оптичките кодови за пристап до државата.

   
   

   ( AUTH се имплементира за да не се менува меморијата и ја зема вредноста на [authority] како аргумент, така што е тривијално да се потврди неговата вредност од дадениот потпис.)

Оптичкиот код [AUTHCALL] има седум влезови на елементи на магацинот кои се користат за пресметување на излез на еден елемент од оџакот.

Ја има истата логика како и [CALL] оптичкиот код, т.е. се користи за испраќање пораки-повици во сметка и активирање на специфична логика во нејзините договори. Единственото отстапување во нивната логика е тоа што [AUTHCALL] е дизајниран да ја постави вредноста на [CALLER] пред да продолжи со извршувањето.

Така, [AUTHCALL] се користи од [авторитетот] за да предизвика однесување специфично за контекст во [овластено] со логички проверки кои се одвиваат на следниов начин:

1. Проверете ја вредноста на [овластено]. Ако не е поставено, извршувањето се смета за неважечко и рамката веднаш се излегува. Ова помага да се спречат неправедни трошоци поради невидени неуспеси.
2. Ги проверува трошоците за гас за планираното однесување на [овластениот].
3. Проверува дали е усогласена вредност EIP-150 на [гас] операндот.
4. Ја проверува достапноста на вкупниот трошок за гас –[вредност]– во билансот на [властот].
5. Извршувањето се случува по одземање на [вредност] од состојбата на сметката на [органот]. Ако [вредноста] е поголема од нивното салдо, извршувањето е поништено.

Цената на гасот за [AUTHCALL] се пресметува како збир од:

• Фиксна цена за повикување [warm_storage_read]
• Цена за проширување на меморијата [memory_expansion_fee] , која се пресметува слично на цената на гасот за [CALL] оптичкиот код
• Динамична цена [dynamic_gas]
• Трошокот за извршување на потповикот [subcall_gas]

До податоците вратени од [AUTHCALL] се пристапува преку:

• [RETURNDATASIZE] – што ја турка големината на повратниот бафер на податоци на излезниот оџак
• [RETURNDATACOPY] – што ги копира податоците од баферот за враќање на податоци во меморијата.

Да се спои сето тоа со многу помалку од технолошкиот говор; Трансакциите со Ethereum обично специфицираат две вредности:

1. tx.origin – кој обезбедува овластување за трансакцијата.
2. msg.sender – во кој всушност се случува трансакцијата.

Во EOA, како што беше претходно споменато, овластувањето е тесно поврзано со извршувањето, т.е. ( tx.origin == msg.sender ). Оваа едноставна непроменлива ги предизвикува повеќето прашања што ги објаснивме во потсекцијата „Валидност на сметки и трансакции“ од овој извештај.

[AUTH] пораки од [authority] му дозволуваат да ја помести функцијата tx.origin на [authorized], додека останува msg.sender. Исто така, му овозможува да дефинира ограничувања на оваа привилегија користејќи вредност [COMMIT]. [AUTHCALL] потоа дозволува [овластен] да пристапи до логиката на договорот, користејќи [инвокатор] како посредник за да се осигура дека договорот до кој сака да пристапи е безопасен. Односно, за секој [AUTHCALL] , [овластен] е да се наведе одреден [повикувач] за нивниот [COMMIT].

Потенцијални апликации на EIP-3074

EIP 3074 е првенствено одговорен за дозволување на EOA да ја делегираат својата логика за авторизација на друга сметка, но неговиот отворен дизајн овозможува многу повеќе во различни контексти. Целата логика на валидација на EOA може да се апстрахира со примена на различни констрикции/иновации на повикувачот по потреба, некои од можните дизајни врз основа на нивната целна логика вклучуваат:

• Nonce логика : EIP-3074 дозволува EOA nonce да остане недопрена по испраќањето на [AUTH] порака, додека, во меѓувреме, неговата непостојаност за секој [AUTHCALL] зависи од тоа со кој повикувач е во интеракција. На овој начин, тој овозможува нецелосен паралелизам за EOA, така што тие можат да испратат повеќе непреклопувачки [AUTHCALL] како што сакаат.
• Логика за плаќање гас : Како што е наведено во EIP, повикувачите може да бидат дизајнирани да дозволуваат спонзорство за гас. Како такви, надоместоците за гас за [COMMIT] на корисникот може да се одземат од потеклото на трансакцијата или од која било сметка за поддршка, без разлика дали е лична или реле заснована на услуги (услуги за спонзорство на гас). Исто така, логиката на извршување е интуитивно апстрахирана; на крајот на краиштата, повикувачот (кој е CA) сега е одговорен за извршување на барањата за трансакции во име на EOA.

Критики на EIP-3074

Централизација на повикувачот

Цитирајќи еден од неговите автори: „ Не би очекувал паричниците да ја изложат функционалноста за потпишување на произволни повикувачи… “. Можеби најголемиот проблем што го наметнува иницијативата 3074 е тоа што иновацијата на врвот на неа многу лесно ќе се стреми кон дозволени и сопственички текови на зделки; исто како и тековните повторувања на пазарите MEV (максимална извлечена вредност) и PBS (одвојување предлагач-градител) на Ethereum.

Стандардно, договорите за повикувачи треба да бидат во голема мера ревидирани за да се спречат уште полоши напади отколку што се моментално можни. Ова неизбежно ќе се стреми кон екосистем каде што само неколку договори за повикувачи развиени од влијателни личности ќе бидат прифатени како стандардни за развивачите на паричници. Така, се сведува на компромис помеѓу:

• Преземање на тешкиот децентрализиран пат на постојана ревизија и поддршка на договорите за повикувачи на ризик од безбедноста на корисниците
• Усвојување договори за повикувачи од воспоставени и реномирани извори со подобри гаранции за безбедноста на корисниците и помал надзор врз безбедноста на договорот.

Друг аспект на оваа точка е функцијата на трошоците поврзана со дизајнирање, ревизија и маркетинг на функционален и безбеден повикувач. Помалите тимови речиси секогаш ќе бидат надминати од поголемите организации - особено на маркетинг фронтот - кои веќе имаат одредена репутација, дури и ако нивниот производ е подобар.

Препрати проблеми со компатибилноста

EIP-3074 ја вградува шемата за потпис на ECDSA, бидејќи таа сè уште се смета за повалидна од шемата за овластување воведена преку повикувачот. Иако постојат аргументи дека квантниот отпор во моментов не е дефинитивен проблем (и дека е многу полошо во прашање во иднина каде што ECDSA е корумпирана), донекаде неизвестената цел на Ethereum е секогаш да биде пред ваквите проблеми. Потенцијалното жртвување на квантната и цензураната отпорност за маргинални подобрувања во UX можеби нема да биде најдобриот избор во блиска иднина.

Друга точка на аргументот за напредна компатибилност е дека додека придобивките од 3074 сè уште се проценуваат, ERC-4337 (кој не бара никакви промени во протоколот) сега има одличен пазар, така што и вие мора да бидете компатибилни со него за да избегнете разделување на екосистемите. Дури и со патоказот за апстракција на домашна сметка, оптичките кодови [AUTH] и [AUTHCALL] на крајот ќе станат застарени во EVM, воведувајќи голем технички долг кон Ethereum со цел да се обезбеди маргинална количина на подобрување на UX.

Неотповикливост на ECDSA шемата

По испраќањето на пораката [AUTH] и делегирањето на контролата, се очекува EOA да ја избегне вообичаената шема за овластување приватен клуч, бидејќи испраќањето „нормална“ трансакција предизвикува овластувањето што го делегирало на секој повикувач да биде отповикано. Така, шемата ECDSA останува строго супериорна во однос на која било друга шема за овластување што може да ја овозможат поврзаните договори, што значи дека губењето на приватните клучеви би резултирало со целосна загуба на средствата на сметката.

Програмабилност преку EIP-7702

Овој предлог првично беше поставен како малку минималистичка варијација на EIP 3074, па дури требаше да биде ажурирање на истиот. Тој е создаден за да одговори на наводните неефикасности на EIP 3074, особено загриженоста околу неговата некомпатибилност со веќе процутот 4337 екосистем и предлогот за апстракција на природна сметка – RIP 7560.

Нејзиниот пристап е додавање на нов тип на трансакција усогласен со EIP 2718 - [SET_CODE_TX_TYPE] - што му овозможува на EOA да се однесува како паметна сметка за одредени трансакции. Овој дизајн ги овозможува истите карактеристики како EIP 5806 и некои повеќе, додека останува компатибилен со патоказот за апстракција на домашна сметка и постојните иницијативи.

Спецификации на EIP-7702

EIP-7702 му дозволува на EOA да ја „увезе“ содржината на кодот на договорот преку трансакција во согласност со [SET_CODE_TX_TYPE] 2718 во формат:

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

Оваа носивост е целосно слична на онаа на EIP 5806, освен што воведува „листа за овластување“. Оваа листа е подредена низа на вредности на форматот:

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

каде што секоја торка ја дефинира вредноста на [address]'.

Пред да продолжите, страните вклучени во SET_CODE_TX_TYPE се:

• [авторитет] : што е сметката за EOA/примарна потпишување
• [адреса] : што е адреса на сметка која содржи код што може да се делегира.

Кога [овластувањето] потпишува SET_CODE_TX_TYPE со наведување [адреса], се создава ознака за делегација. Ова е „програма за покажувач“ која предизвикува сите барања за пронаоѓање код поради дејствијата на [власта] во секој момент да бидат канализирани до видлив код на [адреса].

За секоја [chain_id, address, nonce, y_parity, r, s] торка, логичкиот тек на трансакцијата од типот 7702 е како што следува:

1. Потврда на потписот на [авторитетот] од обезбедениот хаш со користење на: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Спречување на напади за повторување со вкрстени синџири и други вектори на напад со верификација на ID на синџирот.
3. Проверка дали [овластувањето] веќе има содржина на код.
4. Nonce-проверка за да се осигура дека nonce на [властината] е еднаква на nonce вклучена во торката.
5. Ако трансакцијата е прва трансакција SET_CODE_TX_TYPE на [властот], се наплатува надомест од PER_EMPTY_ACCOUNT_COST . Во случај кога неговото салдо е помало од вредноста на овој надоместок, операцијата се прекинува.
6. Се појавува ознака за делегирање, при што кодот на [овластување] е поставен на покажувачот на [адресата].
7. Нонцето на потписникот –[власт]– се зголемува за еден.
8. [authority] се додава на адреси до кои се пристапува списокот, кој (прекумерно поедноставен) е збир на адреси што се направени така што враќањето на опсегот на трансакцијата од нив предизвикува тие (адресата) да се вратат во нивната претходна состојба , пред да се внесе вратениот опсег. Ова е како што е дефинирано во EIP-2929 за да се овозможи кеширање на вредностите за повеќекратна употреба и да се спречат непотребните трошоци.

Пуф! Да се врзе сето тоа назад; овој EIP им овозможува на EOA да испраќаат трансакции кои поставуваат покажувач на кодот на договорот, овозможувајќи им да ја имплементираат оваа логика како своја во следните трансакции. На овој начин, тој е строго посилен од EIP 5806, бидејќи им овозможува на EOA да имаат содржина на код онолку долго колку што сакаат (наспроти EIP 5806 кој едноставно им дозволува на EOA да испраќаат делегатски повици).

Потенцијални апликации на EIP-7702

Извршна апстракција

Иако може да се тврди дека тоа повеќе не е апстракција бидејќи EOA активно ја прифаќа логиката што сака да ја изврши, таа сè уште не е „примарниот сопственик“ на споменатата логика. Исто така, не содржи директно логика, туку едноставно одредува покажувач на логиката (со цел да се намали комплексноста на пресметките). Значи, ние одиме со апстракција на извршување!

Спонзорство за гас

Додека непроменливата require(msg.sender == tx.origin) е скршена за да се дозволи самоспонзорирање, EIP сè уште дозволува интеграции на спонзорирани трансакции. Сепак, предупредувањето е дека на таквите релеери им треба систем заснован на репутација или удел за да се спречат напади на тага.

Политики за условен пристап

EOAs може да укажуваат само на одреден дел од кодот на сметката, така што само логиката на тој дел може да се изврши во нивниот контекст.

Ова, исто така, овозможува постоење на под -клучеви кои продолжуваат да овозможуваат „деескалација на привилегиите“, така што специфичните уреди имаат пристап до салдото на сметката само под одредени услови. На пример, можете да замислите дозвола за трошење токени ERC-20, но не и ETH, или за трошење до 1% од вкупниот биланс дневно или за интеракција само со одредени апликации.

Распоредување на паметни договори со вкрстен синџир

Поради својата нерестриктивна природа, трансакцијата EIP-7702 може да му дозволи на корисникот да пристапи до CREATE2 оптичкиот код и да го користи за распоредување бајтекод на адреса без други рестриктивни параметри како што е пазарната логика на надоместоци (на пр. EIP-1559 и EIP-4844 ). Ова овозможува адресата да се обнови и да се користи низ повеќе државни машини, со ист бајтекод, каде што нејзината сметка на секој синџир потоа е одговорна за дефинирање на другите параметри на контекстната променлива.

Критики на EIP-7702

Недостаток на компатибилност наназад

Додека EIP-7702 е сè уште многу неодамнешен, веќе има многу прототипови и тестирања за неговите зависности и потенцијални недостатоци, но неговиот минималистички модел му гарантира голема флексибилност, а со тоа и корисност, во различни контексти. Сепак, тој прекршува премногу непроменливи и не е веднаш компатибилен наназад. Некои од логиките на EIP-7702 вклучуваат:

1. Носечна промена на EOA при средна трансакција: EIP-7702 не ограничува никакви оптички кодови во обид да обезбеди конзистентност. Ова значи дека EOA може да имплементира оптички кодови како што се CREATE , CREATE2 и SSTORE додека извршува трансакција EIP-7702, овозможувајќи нејзината нестабилност да се зголеми во различен контекст.
2. Дозволување сметки со не-нулта вредност codeHash да бидат иницирачи на трансакции: EIP-3607 беше имплементиран за да се намали потенцијалниот исход од „судир на адреса“ помеѓу EOA и CA. Адресен судир се случува кога 160-битната вредност на адресата на EOA е целосно еквивалентна на онаа на адресата на CA.

Повеќето корисници не се запознаени со вистинската содржина на сметката (или дури и со разликата помеѓу сметката и адресата!), така што дозволувањето судири на адреси значи дека EOA може да се маскира како договорна сметка и да привлече кориснички средства на долг ветер. малку за на крајот да го украде сето тоа. EIP-3607 го реши ова со пропишување дека сметките што содржат код не треба да можат да го трошат своето салдо користејќи ја сопствената логика за авторизација. Сепак, EIP 7702 ја прекинува оваа непроменлива со цел да им овозможи на EOA да останат автономни дури и откако ќе добијат одредена програмабилност.

Сличност со EIP-3074

Потпишувањето на адресата на сметката наместо содржината на кодот е во основа исто како шемата на 3074 со повикувачи. Не обезбедува строги гаранции околу конзистентноста на содржината на кодот со вкрстени синџири, бидејќи адресата може да добие различна содржина на код на различни синџири. Ова значи дека адресата чија содржина на код ја содржи истата логика на еден синџир може да биде предаторска или целосно злонамерна на друг синџир, а тоа може да доведе до губење на корисничките средства.

Заклучок

EOA во нивната сегашна форма денес се многу ограничени бидејќи не им дозволуваат на корисниците да ги искористат предностите на функциите за програмабилност што ги нуди EVM. Иако постојат различни патеки за надградба на сметките, како што наведовме во почетокот на овој извештај, избраното решение треба да ги одржува принципите на безбедно и безбедно самостоење. Понатаму, надградбите на EOA може значително да влијаат и на корисничкото искуство и на развивачите на апликации, така што мора да се земат предвид сите гласови на засегнатите страни.

Дозволувањето на EOA да извршува код на кој било начин неизмерно ја проширува функционалноста на сметките, но оваа нова експресивност доаѓа со значајни ризици и можни слепи страни. Решавањето на овие размени е од клучно значење за да се обезбеди надградба со неоспорни UX придобивки за корисниците на Ethereum.

Културата на отворена дискусија на Ethereum го прави одлично полигон за тестирање за такви иновации, бидејќи речиси секоја импликација на секој дизајн е темелно деконструирана од експерти на тема. Ова сеопфатно разгледување треба да помогне да се ублажат ризиците од злоупотреба од противниците.

EIP-7702 во моментов е постер за механизми што се обидуваат да ја донесат програмабилноста на EVM на EOA, бидејќи е означен како замена за слотот на EIP 3074 во надградбата на Pectra. Го наследува отворениот дизајн на механизмот на 3074 додека во голема мера ја намалува површината/ризиците за напад. Исто така, овозможува многу повеќе со избегнување на ограничувањата на 3074 за одредени класи на оптички кодови.

Иако сè уште се прават некои подобрувања во дизајнот на предлогот, тој веќе собра многу добра волја и поддршка од програмерите, особено затоа што директно го поддржува Vitalik. Во заедницата постојат тврдења дека овој пристап за апстракција на сметки може да биде дури и подобар од паметните сметки. Овој коментар нагласува дека оваа патека бара помалку промени и не е толку сложена, и дека EOA се веќе вградени.

Сепак, мора да се потсетиме на идната безбедносна пресвртница на квантниот отпор на секое ниво на мрежата Ethereum. Оваа квантна безбедност е неостварлива со јадрото на моделот на тековната сметка поради користењето на шемите за потпис базирани на ECDSA за овластување за EOA.

Така, програмабилноста на EOA треба да се гледа како чекор по патот до паметните сметки, а не како дестинација. Ги надополнува EOA и овозможува подобро искуство на корисникот и развивачот, додека останува компатибилен со крајната цел за апстракција на сметката на паметните сметки.

Во нашиот следен извештај, ќе се нурнеме во шемите за миграција на EOA за да видиме колку добро се вклопуваат во патоказот за апстракција на сметката, останете присутни!