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

Откако ги набљудувавме значајните промени што беа воведени во Ethereum преку надградбата на Deneb, почнавме да гледаме напред кон она што ќе го претстави следниот хардфорк, Pectra. За да помогнеме во обликувањето на претстојните дискусии, настојуваме да го опишеме тековниот пејзаж на апстракција на сметките што го опкружува Ethereum и неговиот екосистем за собирање за потенцијално да мапира јасен пат напред. Овој извештај дава преглед на моделот на тековната сметка на Ethereum, особено нивните ефекти врз валидноста на трансакцијата, што точно подразбира апстракцијата на сметката и рамка за расудување за тоа. Потоа ќе се фокусираме на пристапот за програмабилност на EOA со евалуација на EIPs 5086, 3074 и 7702 и ќе заклучиме со тоа како сето ова веројатно ќе влијае на иднината на трансакциите на Ethereum. Иако има многу конфузија околу тоа што е или не е апстракцијата на сметката, нашата рамка низ оваа серија е дека секој механизам што дозволува сметката да редефинира дел од нејзините правила за валидност е механизам за апстракција на сметката. Понатаму, даваме класификација на овие механизми, бидејќи повеќето од нив се нејасно слични и се преклопуваат. кој било Преглед на апстракција на сметката во Ethereum Апстракција на сметката се обидува да ги подобри искуствата на корисниците и развивачите низ целиот екосистем на Ethereum. Заедно со правењето искуства во синџирот подостапни и попријатни за корисниците, исто така ги овластува програмерите да можат да прават помоќни работи на Ethereum и да им служат на корисниците на уште позначајни начини. Нашата класификација на пристапите за апстракција на сметката е како што следува: : Ова вклучува промени на ниво на протокол кои им овозможуваат на EOA (надворешни сметки во сопственост) да го редефинираат логичкиот дел за извршување на нивните правила за валидност. Како што се добро познати во развојната заедница, EOA се сметки обично поврзани со крајните корисници. Затоа, решенијата што спаѓаат во овој пристап ќе им овозможат на сметките на крајните корисници со поголема контрола врз тоа какви дејства можат да авторизираат, во споредба со тоа како може да се управува денес. 1. Подобрување/програмабилност на EOA : Овој пристап вклучува предлози кои бараат целосна конверзија на EOA во CA (сметки со договор). Интегралната идеја на овој пристап е дека договорните сметки веќе ги нудат повеќето од придобивките што ги нудат паметните сметки, така што повеќе не треба да има потреба да се комплицираат работите; секој треба едноставно да користи договорна сметка како своја примарна сметка (преку паметни паричници со договори). 2. Конверзија/миграција на EOA Овој пристап се одликува со механизми кои овозможуваат EOA да премине кон CA, без да мора да ги преместува своите средства, како што се и (кога се разгледуваат заедно со EIP 3074). EIP 7377 EIP 5003 : оваа група на предлози вклучува дизајни што им овозможуваат и на EOA и на CA да се однесуваат како „паметни сметки“ дозволувајќи им целосно да ги редефинираат своите правила за валидност. 3. Паметни сметки Претходно беа дадени различни предлози за создавање паметни сметки и опфат на апстракција на сметки на ниво на протокол; и се некои од поцитираните. Сепак, имаше многу притискање поради воочената сложеност воведена со овој дизајн и малку мнозинското мислење дека Ethereum не е подготвен за таква сложеност. EIP-86 EIP-2938 По оживувањето на темата од страна на Виталик по Спојувањето, беше предложен како опција за вклучување на стандардот за паметни сметки, слична на инфраструктурата PBS (Одделување на предлагач-градител) за MEV (Maximal Extractable Value). Така, корисниците кои сакаат да пристапат до придобивките од паметните сметки може едноставно да го користат нафтоводот ERC-4337 за да ја редефинираат логиката на нивната сметка и правилата за валидност на трансакциите во структурите наречени (или накратко ). ERC-4337 UserOperation UserOps ERC 4337 ги носи придобивките од паметните сметки на денешниот Ethereum без да внесува ништо од сложеноста, со тоа што функционира како алтернатива надвор од протоколот на вградените паметни сметки. Сепак, ова не значи дека инфраструктурата е оптимална во нејзината сегашна состојба бидејќи нејзината сопствена сложеност е сè уште значителна точка на неуспех. За да се одговори на оваа сложеност, беше изготвен како вградена верзија на ERC 4337 инфраструктурата низ Ethereum и неговите L2, така што тој ги наследува шемите на мрежата за отпорност на sybil наместо да мора да дефинира нов пакет правила (како што прави ERC 4337 со ). RIP 7560 ERC 7562 Во овој извештај, ќе бидеме фокусирани на истражување на програмибилноста на EOA, оценувајќи ги различните EIP-и кои ги опишуваат решенијата по оваа линија и дискутираат за нивните предности и недостатоци. Во Дел 2 и 3 од оваа серија, ќе ги покриеме преостанатите две класи на пристап кон апстракција на сметката што се истражуваат во рамките на Ethereum. Прајмер за сметките и трансакциите на Ethereum За да бараме што може да се апстрахира, потребна ни е (донекаде) целосна слика за дизајнот на тековната сметка. Овој дел најмногу ќе служи како вид на ревизија за тоа какви се сметките на Ethereum всушност и како нивните трансакции се потврдени и извршени. Сметките на Ethereum се ентитети со салдо на етер (ETH) и можност за испраќање трансакции на блокчејнот на Ethereum. Тие се претставени како хексадецимална „адреса“ од 42 знаци, која служи како уникатен покажувач за чувањето и трансакциите на сметката. Адресата делува како клуч во состојбата на блокчејнот. Листовите јазли на овој обид се структури на податоци на сметката кои можат да се разложат на четири полиња: : Линеарен бројач што се користи за означување на бројот на излезни трансакции иницирани од сметката. Тоа е исто така клучно за спречување на напади со повторување. nonce : веи-деноминирана количина на етер (ETH) во сопственост на сметка. balance : хаш од извршниот код од EVM содржан во сметката. EVM (Виртуелна машина Ethereum) е нарачана околина за извршување на Ethereum одговорна за справување со сложени транзиции на состојби надвор од едноставни трансакции „испрати“. Содржината на кодот на сметката е непроменливо програмирана да врши специфични форми на транзиција на состојбата на блокчејнот Ethereum, преку EVM. codeHash : хаш од коренот за складирање на сметката, кој се користи за претставување на содржината за складирање на сметката како 256-битен хаш на коренскиот јазол на merkle patricia trie. Едноставно, тоа е хаш од податоците за променливата состојба поврзани со содржината на кодот на сметката. storageHash Содржината на овие четири полиња се користи за дефинирање на типот на сметката и на крајот продолжува да го дефинира обемот на нејзините функционалности. Така, двата вида на сметки на Ethereum се: - кои се иницијализирани како криптографски пар клучеви: Надворешни сметки (EOA) кој е шифриран и докажлив случаен знак од 64 хексадецимален карактер и негов комплементарен пандан; Приватен клуч кој е изведен од приватниот клуч со помош на ECDSA (Elliptic Curve Digital Signature Algorithm). Јавен клуч EOA имаат празни полиња за codeHash и storageHash и може да ги контролира само секој што ги поседува приватните клучеви. Нивните адреси може да се добијат од соодветниот јавен клуч со префиксирање „0x“ на последните дваесет знаци од хашот keccak-256 на јавниот клуч на сметката. (CAs) кои може да се креираат само од претходно постоечки EOA. Тие се иницијализирани поради EOA што распоредува содржина на извршна шифра на EVM. Оваа содржина на кодот (зачувана како codeHash) е вградена во EVM и е одговорна за контрола на сметката преку дефинирање на нејзината логика и интеракции. 2. Договорни сметки Трансакциите од сметката на договорот се целосно засновани на влечење засновани на логиката на нивниот распореден код. Бидејќи овие сметки може да се контролираат само со нивната содржина на код, тие немаат потреба од приватен клуч и имаат само јавен клуч. Така, секој агент кој има можност да ја ажурира/променува содржината на кодот на сметката на договорот ќе може да пристапи до нејзиното салдо. Адресата на сметката на договорот е изведена од адресата на нејзиниот креатор и нејзината непотребност до моментот на распоредување на договорот. Трансакции Неодамна ги опишавме сметките како ентитети кои поседуваат можност да испраќаат трансакции преку Ethereum. Затоа, можеме да разбереме дека основната цел на сметката е да испраќа и прима трансакции, додека блокчејнот делува како книга за снимање историја на трансакции, како и опишување како трансакциите ги менуваат полињата на сметката врз основа на правила опишани во спецификацијата на протоколот за блокчејн. Па што се овие „трансакции“? Трансакциите се операции испратени од сметка, кои предизвикуваат промена во „состојбата“ на мрежата. Тие се криптографски потпишани инструкции од сметки, кои резултираат со ажурирање на состојбата на целата мрежа кога се извршуваат. Недозволата доаѓа со цената на перверзните стимулации, за да се справиме со нив, треба да се дефинираат строги упатства (или правила за валидност) за интеракции во такви средини. Во овој контекст, трансакциите треба да следат одредени правила за валидност за да се сметаат за валидни и извршени. Повеќето од овие правила за валидност се имплементирани преку ограничувања поставени на сметката што ја испраќа трансакцијата и варираат во зависност од тоа каков тип на сметка се работи. Сметки и валидност на трансакцијата На Ethereum, EOA се оптимизирани за употребливост бидејќи се соочуваат со крајниот корисник. Тие имаат можност да испраќаат трансакции и совршено да работат автономно. Тие исто така може да се креираат локално, а најчестиот метод е употребата на даватели на паричник како што се MetaMask, Rainbow, Rabby итн. на специфичен начин Од друга страна, договорните сметки можат да испраќаат само трансакции дозволени според нивната логика, „ “. Исто така, тие можат да бидат креирани само од страна на EOA која има доволно салдо за да плати за неговото државно складирање. како одговор на повикувањето Опис на повисоко ниво би бил дека EOA може да одржуваат само рамнотежа, додека CA може да држат и рамнотежа и логика што диктира како може да се троши овој биланс. Овие својства се должат на следните логички параметри кои ги дефинираат правилата до кои треба да се придржуваат трансакциите на сметката: - Се користи за да се дефинира како сметката го докажува својот идентитет на мрежата додека го менува салдото и/или логиката. Логика за автентикација - Се користи за дефинирање на политиката за пристап на сметката, т.е., кој може да пристапи и да направи промени на состојбата и/или логиката на сметката. Логика за овластување - која го дефинира редоследот по кој треба да се извршат трансакциите од сметката. Nonce логика - Се користи за дефинирање на страната одговорна за подмирување на надоместокот за гас на трансакцијата. Логика за плаќање гас - Се користи за да се дефинира какви форми на трансакции може да испрати сметката или како да се изврши трансакцијата. Логика на извршување Овие параметри се дизајнирани да бидат ригидни за EOA на тој начин: Автентикацијата и овластувањето се обезбедуваат со приватен клуч базиран на ECDSA, т.е., корисникот кој сака да испрати трансакција од својот EOA мора да го користи својот приватен клуч за пристап до сметката и на тој начин да докаже дека има право да изврши какви било промени на нејзиното салдо. . Логиката nonce имплементира шема на секвенцијален бројач, која дозволува само една трансакција по единствена нонс да се изврши последователно по сметка. Логиката за плаќање на гас одредува дека надоместокот за гас за трансакциите мора да биде подмирен од сметката на испраќачот/изворот. Логиката на извршување специфицира дека EOA може да ги испраќаат само следните формулари за трансакција: Редовни трансфери помеѓу две EOA. Распоредување на договор. за договор кои се насочени кон логиката на сметката на распоредениот договор. повици Поопшто, логиката на извршување на EOA ги ограничува на една трансакција по валиден потпис. Од друга страна, CA имаат поголема флексибилност околу овие параметри: Автентикацијата не е потребна, бидејќи нивните трансакции се последователни/базирани по природа. Овластувањето за CA може да има две форми: Способност да се „ “ кодот на содржината на CA (или да се изврши неговиот паметен договор), што зависи од логиката на паметниот договор на сметката и неговите непроменливи. повика Можност за правење промени во кодот за содржина на CA, што најмногу зависи од тоа дали кодот за содржина може да се надградува или не. Во повеќето практични случаи, логиката што се користи во овој случај е шема со повеќе потписи која пропишува дека M од N валидни потписи (каде што M <N) се бара од одредени сметки (најчесто EOAs) со цел да се промени логиката на CA да важи. Нивното нарачување трансакции не се заснова на лабаво. Самиот CA може да испрати што повеќе трансакции до што е можно повеќе различни , но секој повикувач е ограничен врз основа на нивните сопствени способности. повикувачи Плаќањето за гас најчесто се врши од страна на на логиката на CA. повикувачот Логиката на извршување на CA е поразновидна за да овозможи UX подобрувања како што се трансакции со повеќе повици и атомски трансакции. Оценувајќи ги овие карактеристики, забележуваме дека секој тип на сметка е дизајниран да има компромис помеѓу автономијата и програмабилноста. EOA имаат целосна автономија, но ограничена програмабилност; тие можат да овластат и испраќаат трансакции кога сакаат, но овие трансакции мора да следат ригиден формат за да се сметаат за валидни. Договорните сметки имаат целосна програмабилност (ограничена само со дизајнот на EVM), но ограничена автономија: нивните трансакции не мора да следат некој ригиден формат, туку може да се испратат само поради нивната логика што е прво повикана. Во следниот потсекција, сега ќе ги проучуваме импликациите на овие дизајни избори, со цел целосно да го разбереме предлогот на секој дискутиран EIP низ оваа серија. Дилема на сметката на Ethereum Сега, кога имаме малку прецизно познавање за функционалностите на различните сметки, лесно можеме да ги идентификуваме нивните продажни точки, како и проблемите што тие ги претставуваат и на искуството на корисниците и на развивачите на Ethereum. Како што претходно споменавме, EOA се дизајнирани како првокласни сметки насочени кон крајните корисници. Апликациите се дизајнирани за лесно да комуницираат со нив, речиси и да нема сложеност за нив и, се разбира, нема трошоци за создавање. Сепак, неговата едноставност доаѓа со значително губење на новина бидејќи тие се дизајнирани да бидат строго детерминистички. Некои од грижите околу нив се: - Шемата за потпис ECDSA што ја користи нивниот пар клучеви не е квантно отпорна и со оптимистичка временска рамка од 5 до 10 години за индустриски квантни системи што се постигнуваат, ова претставува значајна закана за Ethereum и неговите апликации на кои многу се потпираат на ECDSA шемата за криптографски докази и безбедност. Подложност на квантни напади - Цврстиот формат на правилата за валидност на EOA ја елиминира способноста на корисниците да ги изразат своите трансакции попрецизно преку карактеристики како што се атомичноста на трансакцијата и групирање, и делегирање на трансакциите. Недостаток на изразување - Секој имаше свој соодветен дел од моментите „снемав бензин“ среде трансакција. Ова се должи на барањето EOA да го решаваат гасот за нивните трансакции сами, што не би било многу важно дали етерот (ETH) не е единствената прифатлива валута за гас. Иако ова е општ проблем со државните машини засновани на сметка (па дури и оние базирани на UTXO), Ethereum секогаш имал намера да биде различен. Самоодржливост Не секој сака (или би можел) секогаш да држи ETH (мислам погледнете ја таа цена), така што остварливите решенија би биле или да се дозволат повеќе валути на гас (премногу тешко, прекинува премногу непроменливи како што е опишано во „Валута ” дел ), или да дозволите плаќањата за гас да се подмируваат со друга сметка што не е потеклото на трансакцијата. овде На другиот крај од спектарот на сметките, CA таргетираат програмери и потехничка корисничка база. Тие служат како средства за паметни договори (т.е. сметаме дека паметните договори се нивната содржана логика или содржина на код) и затоа можат да имплементираат нови формати на трансакции како што е овозможено од EVM. Сепак, за сите овие карактеристики тие се глорифицирани сметки од втора класа бидејќи немаат автономија. Некои од нивните недостатоци се како што следува: - CA не можат да започнат трансакција, тие можат само да испраќаат трансакции како одговор на нивното повикување на многу специфичен начин. Тотален недостаток на автономија – Недостатокот на ригидност често доведува до неточна дефиниција на непроменливи и други такви логики, што доведе до загуби од милијарди долари поради искористувања на паметни договори и хакери. Сепак, ова е речиси сосема друга тема која е надвор од нашиот опсег овде. Подложност на човечка грешка во нивната логика Откако ги разгледавме дизајнерските избори што доведоа до прашањата дефинирани во оваа потсекција, сега можеме да продолжиме да ги оценуваме предложените решенија. Временска рамка за апстракција на сметката За да бараме што може да се апстрахира, потребна ни е (донекаде) целосна слика за дизајнот на тековната сметка. Овој дел најмногу ќе служи како вид на ревизија за тоа какви се сметките на Ethereum всушност и како нивните трансакции се потврдени и извршени. Концептот на апстракција на сметки (барем преку паметни сметки) отсекогаш бил составен дел од патоказот на Ethereum. Најавата е дека сложеноста околу неговата имплементација се закануваше дополнително да го одложи лансирањето на Ethereum, и затоа беше отфрлен поради тековниот дизајн со различни сметки кои нудат различни функционалности. Повторно беше одложен поради фокусот на Ethereum на The Merge и сега повторно се појавува како главен дел од следната голема надградба на мрежата - Pectra. Сепак, неговата сложеност сè уште се смета за значителен недостаток што го спречува неговото зацврстување, особено затоа што Ethereum се сврте кон патоказот насочен кон собирање. Барањата сега се двојни: Стандардите за сметки треба да бидат поизразени, но без губење на автономијата. Нов стандард кој ја запечатува поделбата помеѓу стандардите на EOA и CA. Новиот стандард треба да го премости јазот помеѓу 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 е како што следува: : Идентификаторот на тековниот синџир што е во согласност со EIP-115 е пополнет на 32 бајти. Оваа вредност обезбедува заштита од напади со повторување, така што трансакциите на оригиналниот синџир не се тривијално реплицирани на алтернативни EVM синџири со слична историја и помала економска безбедност. ChainID : Уникатен идентификатор за секоја трансакција кој исто така обезбедува заштита од напади од повторување. nonce : Вредностите на надоместокот за гас што треба да го плати трансакцијата EIP-5806 за нарачка и вклучување соодветно. max_priority_fee_per_gas и max_fee_per_gas : Максималната количина на гас што може да ја потроши една трансакција од типот 5806. gas_limit : примачот на трансакцијата дестинација : содржината на извршниот код податоци : Агенти кои се условно овластени да извршуваат трансакции со EIP-5806. access_list : три вредности кои заедно претставуваат потпис secp256k1 над пораката — signature_y_parity, signature_r и signature_s 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 ги користи делегатните повици за да спречи непроменливо кршење. Овие ограничувања се насочени кон следните оптички кодови: : Овој оптички код дозволува сметката да зачува вредност во складиштето. Тоа е ограничено во трансакциите на EIP-5806 за да се спречи EOA да поставува/пристапува до складиштето користејќи делегатски повици, со што ќе се спречат потенцијалните проблеми што може да се појават во иднина поради миграција на сметката. SSTORE/0x55 , и : овие оптички кодови опширно му дозволуваат на повикувачот да креира нова сметка. Пристапот до нив е ограничен за да се спречи промена на нецелата на EOA во различна рамка за извршување (создавање/уништување на договор во овој случај) додека врши трансакција EIP-5806, со цел да се спречи неважење на очекувањата дека трансакциите носат последователни неуспеси. CREATE/0xF0 CREATE2/0xF5 SELFDESTRUCT/0xFF Потенцијални апликации на 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: што поставува [овластена] сметка со контекстуална променлива да дејствува во име на втора сметка [авторитет], врз основа на потписот на ECDSA на вториот. [AUTH] кој испраќа/имплементира повици за сметката [авторитет] од/како [овластена] сметка. [AUTHCALL] Овие два оптички кодови му овозможуваат на EOA да ја делегира контролата на претходно воспоставена CA, и на тој начин, да дејствува како едно преку него, без да мора да распореди договор и да ги сноси трошоците и надворешните ефекти поврзани со тоа. EIP-3074 спецификации EIP-3074 дозволува трансакциите да користат формат за потпишување за да се спречат судири со други формати за потпишување трансакции. Активната сметка на која се пренесуваат инструкциите е дефинирана како поле за контекст-променлива именувано [authorized], кое опстојува само преку една трансакција и мора да се редефинира за секоја нова . [MAGIC] [AUTHCALL] [AUTHCALL] Пред да се разгледаат сложеноста на секој оптички код, ова се ентитетите вклучени во трансакцијата EIP-3074: : Примарната сметка за потпишување (ЕОА) која делегира пристап/контрола на втора сметка, која обично е сметка на договор. [авторитет] : Сметката на која треба да се пренесат инструкциите за извршување. Со други зборови, тоа е сметката во која се извршува логиката на , во име на [авторитетот], со користење на ограничувања дефинирани од [инвокатор]. [authorized] [AUTHCALL] [AUTHCALL] : Договор за помошник наменет за управување со интеракциите помеѓу [овластена] сметка и логиката на , особено во случаи кога примарната логика на кодот на договорот на вториот е спонзорство за гас. [повикувач] [AUTHCALL] Договорите за повикувачи добиваат пораки со вредност [COMMIT] од [овластување]; оваа вредност ги дефинира ограничувањата што сметката сака да ги постави на [овластено] извршување на инструкциите за . Така, повикувачите се одговорни да осигураат дека [ ] дефиниран во [овластен] сметка не е злонамерен и има способност да ги задоволи непроменливите ставени од примарната сметка за потпишување во вредност [COMMIT]. [AUTH] [AUTHCALL] contract_code Оптичкиот код има три влезни елементи на стек; или поедноставно - се дефинира со три влеза кои пресметуваат еден излез. Овие влезови се: [AUTH] : која е адресата на EOA која го генерира потписот орган офсет должина Последните два влеза се користат за опишување опсег на модифицирана меморија од 0 до 97, каде што: [memory(offset : offset+1)] – [yParity] [memory(offset+1 : offset+33] – [r] [memory(offset+33 : offset+65)] – [s] [memory(offset+65 : offset+97)] – [COMMIT] Променливите [yParity], [r] и [s] колективно се толкуваат како потпис ECDSA, [magic], на кривата secp256k1 над пораката: [keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)] каде: е потпис на ECDSA што произлегува од комбинацијата на променливите: [MAGIC] што е идентификатор во согласност со EIP 115 на тековниот синџир што се користи за да обезбеди заштита од напади од повторување на алтернативни EVM синџири со слична историја и помала економска безбедност. [chainID] што е тековната нонс на адресата на потписникот на трансакцијата, лево поместена на 32 бајти. [nonce] што е адресата на договорот што ја содржи логиката за извршување на . [invokerAddress] [AUTH] е вредност од 32 бајти што се користи за одредување дополнителни услови за валидност на трансакцијата во логиката на претходна обработка на повикувачот. [COMMIT] Ако пресметаниот потпис е валиден и адресата на потписникот е еднаква на [овластување], полето [овластено] се ажурира до вредноста дадена од [овластување]. Ако некое од овие барања не е задоволено, полето [овластено] останува непроменето во претходната состојба или како непоставена вредност. Цената на гасот за овој оптички код се пресметува како збир од: Фиксна такса за прекомпајлот [ecrecover] и дополнителна за хаш keccak256 и некоја дополнителна логика, вредна 3100 единици Надоместок за проширување на меморијата што се пресметува слично на [RETURN] оптичкиот код и се применува кога меморијата се прошири надвор од наведениот опсег на тековната распределба (97 единици) Фиксна цена од 100 единици направени за топол [авторитет] и 2600 единици за ладен за да се спречат напади поради погрешни цени на оптичките кодови за пристап до државата. ( се имплементира за да не се менува меморијата и ја зема вредноста на [authority] како аргумент, така што е тривијално да се потврди неговата вредност од дадениот потпис.) AUTH Оптичкиот код има седум влезови на елементи на магацинот кои се користат за пресметување на излез на еден елемент од оџакот. [AUTHCALL] Ја има истата логика како и оптичкиот код, т.е. се користи за испраќање пораки-повици во сметка и активирање на специфична логика во нејзините договори. Единственото отстапување во нивната логика е тоа што е дизајниран да ја постави вредноста на [CALLER] пред да продолжи со извршувањето. [CALL] [AUTHCALL] Така, се користи од [авторитетот] за да предизвика однесување специфично за контекст во [овластено] со логички проверки кои се одвиваат на следниов начин: [AUTHCALL] Проверете ја вредноста на [овластено]. Ако не е поставено, извршувањето се смета за неважечко и рамката веднаш се излегува. Ова помага да се спречат неправедни трошоци поради невидени неуспеси. Ги проверува трошоците за гас за планираното однесување на [овластениот]. Проверува дали е усогласена вредност EIP-150 на [гас] операндот. Ја проверува достапноста на вкупниот трошок за гас –[вредност]– во билансот на [властот]. Извршувањето се случува по одземање на [вредност] од состојбата на сметката на [органот]. Ако [вредноста] е поголема од нивното салдо, извршувањето е поништено. Цената на гасот за се пресметува како збир од: [AUTHCALL] Фиксна цена за повикување [warm_storage_read] Цена за проширување на меморијата , која се пресметува слично на цената на гасот за оптичкиот код [memory_expansion_fee] [CALL] Динамична цена [dynamic_gas] Трошокот за извршување на потповикот [subcall_gas] До податоците вратени од се пристапува преку: [AUTHCALL] – што ја турка големината на повратниот бафер на податоци на излезниот оџак [RETURNDATASIZE] – што ги копира податоците од баферот за враќање на податоци во меморијата. [RETURNDATACOPY] Да се спои сето тоа со многу помалку од технолошкиот говор; Трансакциите со Ethereum обично специфицираат две вредности: – кој обезбедува овластување за трансакцијата. tx.origin – во кој всушност се случува трансакцијата. msg.sender Во EOA, како што беше претходно споменато, овластувањето е тесно поврзано со извршувањето, т.е. ( == ). Оваа едноставна непроменлива ги предизвикува повеќето прашања што ги објаснивме во потсекцијата „Валидност на сметки и трансакции“ од овој извештај. tx.origin msg.sender пораки од [authority] му дозволуваат да ја помести функцијата tx.origin на [authorized], додека останува msg.sender. Исто така, му овозможува да дефинира ограничувања на оваа привилегија користејќи вредност [COMMIT]. потоа дозволува [овластен] да пристапи до логиката на договорот, користејќи [инвокатор] како посредник за да се осигура дека договорот до кој сака да пристапи е безопасен. Односно, за секој , [овластен] е да се наведе одреден [повикувач] за нивниот [COMMIT]. [AUTH] [AUTHCALL] [AUTHCALL] Потенцијални апликации на EIP-3074 EIP 3074 е првенствено одговорен за дозволување на EOA да ја делегираат својата логика за авторизација на друга сметка, но неговиот отворен дизајн овозможува многу повеќе во различни контексти. Целата логика на валидација на EOA може да се апстрахира со примена на различни констрикции/иновации на повикувачот по потреба, некои од можните дизајни врз основа на нивната целна логика вклучуваат: : EIP-3074 дозволува EOA nonce да остане недопрена по испраќањето на порака, додека, во меѓувреме, неговата непостојаност за секој зависи од тоа со кој повикувач е во интеракција. На овој начин, тој овозможува нецелосен паралелизам за EOA, така што тие можат да испратат повеќе непреклопувачки како што сакаат. Nonce логика [AUTH] [AUTHCALL] [AUTHCALL] : во EIP, повикувачите може да бидат дизајнирани да дозволуваат спонзорство за гас. Како такви, надоместоците за гас за [COMMIT] на корисникот може да се одземат од потеклото на трансакцијата или од која било сметка за поддршка, без разлика дали е лична или реле заснована на услуги (услуги за спонзорство на гас). Исто така, логиката на извршување е интуитивно апстрахирана; на крајот на краиштата, повикувачот (кој е CA) сега е одговорен за извршување на барањата за трансакции во име на EOA. Логика за плаќање гас Како што е наведено Критики на EIP-3074 Централизација на повикувачот еден од неговите автори: „ “. Можеби најголемиот проблем што го наметнува иницијативата 3074 е тоа што иновацијата на врвот на неа многу лесно ќе се стреми кон дозволени и сопственички текови на зделки; исто како и тековните повторувања на пазарите MEV (максимална извлечена вредност) и PBS (одвојување предлагач-градител) на Ethereum. Цитирајќи Не би очекувал паричниците да ја изложат функционалноста за потпишување на произволни повикувачи… Стандардно, договорите за повикувачи треба да бидат во голема мера ревидирани за да се спречат уште полоши напади отколку што се моментално можни. Ова неизбежно ќе се стреми кон екосистем каде што само неколку договори за повикувачи развиени од влијателни личности ќе бидат прифатени како стандардни за развивачите на паричници. Така, се сведува на компромис помеѓу: Преземање на тешкиот децентрализиран пат на постојана ревизија и поддршка на договорите за повикувачи на ризик од безбедноста на корисниците Усвојување договори за повикувачи од воспоставени и реномирани извори со подобри гаранции за безбедноста на корисниците и помал надзор врз безбедноста на договорот. Друг аспект на оваа точка е функцијата на трошоците поврзана со дизајнирање, ревизија и маркетинг на функционален и безбеден повикувач. Помалите тимови речиси секогаш ќе бидат надминати од поголемите организации - особено на маркетинг фронтот - кои веќе имаат одредена репутација, дури и ако нивниот производ е подобар. Препрати проблеми со компатибилноста EIP-3074 ја вградува шемата за потпис на ECDSA, бидејќи таа сè уште се смета за повалидна од шемата за овластување воведена преку повикувачот. Иако постојат аргументи дека квантниот отпор во моментов не е дефинитивен проблем (и дека е многу полошо во прашање во иднина каде што ECDSA е корумпирана), донекаде неизвестената цел на Ethereum е секогаш да биде пред ваквите проблеми. Потенцијалното жртвување на квантната и цензураната отпорност за маргинални подобрувања во UX можеби нема да биде најдобриот избор во блиска иднина. Друга точка на аргументот за напредна компатибилност е дека додека придобивките од 3074 сè уште се проценуваат, ERC-4337 (кој не бара никакви промени во протоколот) сега има одличен пазар, така што и вие мора да бидете компатибилни со него за да избегнете разделување на екосистемите. Дури и со патоказот за апстракција на домашна сметка, оптичките кодови и на крајот ќе станат застарени во EVM, воведувајќи голем технички долг кон Ethereum со цел да се обезбеди маргинална количина на подобрување на UX. [AUTH] [AUTHCALL] Неотповикливост на ECDSA шемата По испраќањето на пораката и делегирањето на контролата, се очекува EOA да ја избегне вообичаената шема за овластување приватен клуч, бидејќи испраќањето „нормална“ трансакција предизвикува овластувањето што го делегирало на секој повикувач да биде отповикано. Така, шемата ECDSA останува строго супериорна во однос на која било друга шема за овластување што може да ја овозможат поврзаните договори, што значи дека губењето на приватните клучеви би резултирало со целосна загуба на средствата на сметката. [AUTH] Програмабилност преку EIP-7702 Овој предлог првично беше поставен како малку минималистичка варијација на EIP 3074, па да биде ажурирање на истиот. Тој е создаден за да одговори на наводните неефикасности на EIP 3074, особено загриженоста околу неговата некомпатибилност со веќе процутот 4337 екосистем и предлогот за апстракција на природна сметка – RIP 7560. дури требаше Нејзиниот пристап е додавање на нов тип на трансакција усогласен со EIP 2718 - - што му овозможува на EOA да се однесува како паметна сметка за одредени трансакции. Овој дизајн ги овозможува истите карактеристики како EIP 5806 и некои повеќе, додека останува компатибилен со патоказот за апстракција на домашна сметка и постојните иницијативи. [SET_CODE_TX_TYPE] Спецификации на EIP-7702 EIP-7702 му дозволува на EOA да ја „увезе“ содржината на кодот на договорот преку трансакција во согласност со 2718 во формат: [SET_CODE_TX_TYPE] 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 За секоја торка, логичкиот тек на трансакцијата од типот 7702 е како што следува: [chain_id, address, nonce, y_parity, r, s] Потврда на потписот на [авторитетот] од обезбедениот хаш со користење на: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s] Спречување на напади за повторување со вкрстени синџири и со верификација на ID на синџирот. други вектори на напад Проверка дали [овластувањето] веќе има содржина на код. Nonce-проверка за да се осигура дека nonce на [властината] е еднаква на nonce вклучена во торката. Ако трансакцијата е прва трансакција на [властот], се наплатува надомест од . Во случај кога неговото салдо е помало од вредноста на овој надоместок, операцијата се прекинува. SET_CODE_TX_TYPE PER_EMPTY_ACCOUNT_COST Се појавува ознака за делегирање, при што кодот на [овластување] е поставен на покажувачот на [адресата]. Нонцето на потписникот –[власт]– се зголемува за еден. [authority] се додава на адреси до кои се пристапува списокот, кој (прекумерно поедноставен) е збир на адреси што се направени така што враќањето на опсегот на трансакцијата од нив предизвикува тие (адресата) да се вратат во нивната претходна состојба , пред да се внесе вратениот опсег. Ова е како што е дефинирано во за да се овозможи кеширање на вредностите за повеќекратна употреба и да се спречат непотребните трошоци. EIP-2929 Пуф! Да се врзе сето тоа назад; овој EIP им овозможува на EOA да испраќаат трансакции кои поставуваат покажувач на кодот на договорот, овозможувајќи им да ја имплементираат оваа логика како своја во следните трансакции. На овој начин, тој е строго посилен од EIP 5806, бидејќи им овозможува на EOA да имаат содржина на код онолку долго колку што сакаат (наспроти EIP 5806 кој едноставно им дозволува на EOA да испраќаат делегатски повици). Потенцијални апликации на EIP-7702 Извршна апстракција Иако може да се тврди дека тоа повеќе не е апстракција бидејќи EOA активно ја прифаќа логиката што сака да ја изврши, таа сè уште не е „примарниот сопственик“ на споменатата логика. Исто така, не содржи логика, туку едноставно одредува покажувач на логиката (со цел да се намали комплексноста на пресметките). Значи, ние одиме со апстракција на извршување! директно Спонзорство за гас Додека непроменливата е скршена за да се дозволи самоспонзорирање, EIP сè уште дозволува интеграции на спонзорирани трансакции. Сепак, предупредувањето е дека на таквите релеери им треба систем заснован на репутација или удел за да се спречат напади на тага. require(msg.sender == tx.origin) Политики за условен пристап EOAs може да укажуваат само на одреден дел од кодот на сметката, така што само логиката на тој дел може да се изврши во нивниот контекст. Ова, исто така, овозможува постоење на под кои продолжуваат да овозможуваат „деескалација на привилегиите“, така што специфичните уреди имаат пристап до салдото на сметката само под одредени услови. На пример, можете да замислите дозвола за трошење токени ERC-20, но не и ETH, или за трошење до 1% од вкупниот биланс дневно или за интеракција само со одредени апликации. -клучеви Распоредување на паметни договори со вкрстен синџир Поради својата нерестриктивна природа, трансакцијата EIP-7702 може да му дозволи на корисникот да пристапи до CREATE2 оптичкиот код и да го користи за распоредување бајтекод на адреса без други рестриктивни параметри како што е пазарната логика на надоместоци (на пр. EIP-1559 и EIP-4844 ). Ова овозможува адресата да се обнови и да се користи низ повеќе државни машини, со ист бајтекод, каде што нејзината сметка на секој синџир потоа е одговорна за дефинирање на другите параметри на контекстната променлива. Критики на EIP-7702 Недостаток на компатибилност наназад Додека EIP-7702 е сè уште многу неодамнешен, веќе има многу прототипови и тестирања за неговите зависности и потенцијални недостатоци, но неговиот минималистички модел му гарантира голема флексибилност, а со тоа и корисност, во различни контексти. Сепак, тој прекршува премногу непроменливи и не е веднаш компатибилен наназад. Некои од логиките на EIP-7702 вклучуваат: Носечна промена на EOA при средна трансакција: EIP-7702 не ограничува никакви оптички кодови во обид да обезбеди конзистентност. Ова значи дека EOA може да имплементира оптички кодови како што се , и додека извршува трансакција EIP-7702, овозможувајќи нејзината нестабилност да се зголеми во различен контекст. CREATE CREATE2 SSTORE Дозволување сметки со не-нулта вредност да бидат иницирачи на трансакции: EIP-3607 беше имплементиран за да се намали потенцијалниот исход од „судир на адреса“ помеѓу EOA и CA. Адресен судир се случува кога 160-битната вредност на адресата на EOA е целосно еквивалентна на онаа на адресата на CA. codeHash Повеќето корисници не се запознаени со вистинската содржина на сметката (или дури и со разликата помеѓу сметката и адресата!), така што дозволувањето судири на адреси значи дека 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 за да видиме колку добро се вклопуваат во патоказот за апстракција на сметката, останете присутни! Забелешка на авторот: Верзијата на овој напис првпат беше објавена . овде