Předmluva

Tento článek je rozdělen do dvou hlavních modulů:

V první polovině, počínaje prvním návrhem AA v roce 2015, budeme systematicky třídit hlavní obsah dosavadních návrhů EIP. Doufáme, že prozkoumáme historii historických návrhů AA a komplexně zhodnotíme výhody a nevýhody každého plánu.

Ve druhé polovině se soustředíme na porovnání zpětné vazby na pokles trhu, které jsme čelili po navržení EIP 4337, a poté provedeme hloubkovou analýzu EIP 7702, která bude zahrnuta do další verze upgradu Etherea, jakmile bude tento návrh uveden sloučeno, zcela změní formulář žádosti v řetězci.

EIP-7702 má epochální změny, poslouchejte prosím podrobné vysvětlení pana Shishi

1. Abstraktní pozadí účtu

1.1 Abstraktní význam účtu

Umístění Vitalik, zakladatel Etherea, znovu aktualizoval plán rozvoje ETH na konci roku 2023, ale nastavení abstrakce účtu se nezměnilo. Dnešní mainstreamový model se také přesunul z EIP-4337 do další fáze dobrovolné konverze EOA (dobrovolná konverze účtů EOA).

https://x.com/VitalikButerin/status/1741190491578810445

Více než rok od spuštění EIP 4337 (na WalletCon v Denveru dne 1. března 2023 bylo oficiálně oznámeno, že základní kontrakt ERC-4337 navržený a implementovaný vývojáři Ethereum Foundation prošel auditem OpenZeppelin a je považován za oficiálně spuštěn historický uzel).

Vždy byl široce uznáván uživateli, ale není široce používán V tak rozporuplném tržním prostředí byl vývoj EIP-7702 velmi pokročilý a dokonce bylo potvrzeno, že bude začleněn do příští aktualizace.

1.2 Aktuální tržní stav abstrakce účtu

Bez dalších řečí se podívejme na data.

Po jeden a půl roce vývoje má EIP 4337 ve sbírce účtů hlavního proudu pouze 1 200 W adres. Nejpřekvapivější je, že na mainnetu Ethereum je pouze 6 764 aktivních adres , ale přinejmenším se velmi liší od počtu adres EOA a CA Musíte vědět, že počet nezávislých adres na mainnetu Ethereum dosáhl 270 milionů (zdroj dat: https://etherscan.io/chart/address. ).

Dá se říci, že na hlavní síti EIP 4337 nedochází k žádnému zásadnímu vývoji.

Zdroj dat: https://dune.com/niftytable/account-abstraction)

To však nevymazává podstatnou hodnotu AA, protože od samého počátku návrhu EIP 4337 bylo předurčeno k tomu, že nemohlo fungovat dobře tváří v tvář vážným problémům s dopřednou kompatibilitou v hlavní síti, takže spolu s různými L2 Lay chains Obecně začleněné do nativního AA, počet EIP 4337 adres explodoval na L2 Mezi nimi byli měsíční aktivní uživatelé základního a polygonového řetězce v červenci 100 W a 300 W, což je docela působivé.

Není to tedy tak, že by návrh EIP 4337 měl mnoho výhod Za chvíli to systematicky shrneme řešení.

2. Co je to abstrakce účtu?

Abstrakce účtu zní zmateně, ale ve skutečnosti v podstatě řeší problém oddělení vlastnických práv.

V architektuře EVM existují dva typy účtů (tj. virtuální počítač Ethereum), externí účet (EOA) a smluvní účet (smluvní účet Vlastnická a podpisová práva k externímu účtu jsou ve skutečnosti drženy stejnou osobou). jednotka. Osoba držící soukromý klíč má nejen „vlastnictví“ účtu, ale má také právo „podepsat a převést všechna aktiva“.

To je určeno transakční strukturou účtu Ethereum

Jak je patrné ze struktury na obrázku níže, ve standardních transakcích Etherea ve skutečnosti neexistuje žádná strana From. Pokud tedy provedu převod prostředků, z jaké konkrétní adresy prostředky spotřebuji? Ve skutečnosti je adresa From dekódována prostřednictvím jejího parametru VRS (tj. podpisu uživatele).

Jde o asymetrické šifrování jako je ECDSA, jednosměrná prahová funkce a další koncepty Zkrátka kryptografie slouží k zajištění bezpečnosti .

Hlavním účinkem EIP 4337 je přidání pole Adresa odesílatele do pole transakce, čímž se oddělí soukromý klíč od provozované adresy.

Proč je tedy oddělení vlastnických práv tak důležité?

Protože design externího účtu (EOA) způsobí další problémy:

  • Soukromé klíče se obtížně chrání: uživatelé ztratí své soukromé klíče (ztráta, útok hackerů, kryptografické crackování) znamená ztrátu veškerého majetku.

  • Málo podpisových algoritmů: Nativní protokol může k ověřování transakcí používat pouze algoritmy ECDSA pro ověřování podpisů a podpisů.

  • Vysoká autorita podpisu: Neexistuje žádný nativní vícenásobný podpis (vícenásobný podpis může spolupracovat pouze prostřednictvím inteligentních smluv) a jakoukoli operaci lze provést pomocí jediného podpisu.

  • Transakční poplatky lze platit pouze prostřednictvím ETH a dávkové transakce nejsou podporovány.

  • Únik soukromí transakcí: Jednotné transakce usnadňují analýzu soukromých informací majitele účtu.

Omezení přitažlivosti ztěžují běžným uživatelům používání Etherea:

Za prvé, pro použití jakékoli aplikace na Ethereu musí uživatelé držet ether (a nést riziko kolísání cen etheru).

Za druhé, uživatelé se musí vypořádat se složitou nákladovou logikou Koncepty ceny plynu, limitu plynu a blokování transakcí (objednávka Nonce) jsou pro uživatele příliš složité.

A konečně, ačkoli se mnoho blockchainových peněženek nebo aplikací snaží zlepšit uživatelskou zkušenost pomocí optimalizace produktu, jejich skutečné účinky jsou minimální.

Způsobem, jak situaci prolomit, je proto implementace abstrakce účtu a oddělení vlastnictví (Vlastník) a podpisových práv (Signer), aby bylo možné výše uvedené problémy vyřešit jeden po druhém. Ve skutečnosti existuje mnoho historických plánů a nakonec se sblíží do dvou tras.

3. Projděte si historii návrhů AA

Zdá se, že existuje mnoho návrhů EIP na řešení tohoto problému, ale v konečné analýze existují dvě základní myšlenky, a proto se otázky zvažované v každém EIP, který v minulosti neprošel, také spojily do řešení současného řešení.

3.1 První cestou je změna adresy EOA na adresu CA

Již 15. listopadu 2015 kolem EIP-101 navrhl Vitalik novou strukturu využívající smlouvy jako účty. Změňte adresu tak, aby obsahovala pouze kód a úložný prostor, změňte manipulační poplatek tak, aby podporoval platbu do ERC 20, změňte nativní token na podobný ERC 20 prostřednictvím předkompilovaných smluv pro ukládání zůstatků (může mít funkce, jako je autorizace srážkové daně) a zefektivněte transakční pole na only to, startgas, data a code. Nyní se zdá, že jde jednoduše o změnu ve stylu Great Leap Forward, která výrazně změní základní design tak, aby každá adresa účtu měla svou vlastní logiku „kódu“ (ve skutečnosti přesně toho se nyní EIP-7702 snaží dosáhnout ). Lze odvodit i další funkce, jako např

  • Umožněte transakcím používat více šifrovacích algoritmů a způsob ověření podpisu může být určen interním kódem každé adresy.

  • Je odolný vůči kvantovým útokům, protože kód má vlastnosti upgradu.

  • Nechte Ethereum mít stejné funkční vlastnosti jako kontrakt ERC 20 a základní efekt má srážkovou autorizaci, takže není třeba ztrácet nativní měnu.

  • Vylepšete prostor pro přizpůsobení účtu, kompatibilní s obnovou sociálních sítí, podporou sbt, získáváním klíčů atd.

Důvod nepokračování je také velmi jednoduchý. Je zřejmé, že tempo je příliš velké. Vzhledem k aktuálnímu problému s konfliktem transakčních hashů a bezpečnostním rizikům bylo odloženo z důvodu nedostatečného zvážení se stala hlavní funkcí následujících EIP 4337 a EIP 7702. jedna.

Později existovala řada EIP, které se pokusily tuto logiku zlepšit:

EIP-859: Abstrakce účtu hlavního řetězce--2018-01-30

Snaha vyřešit problém s nasazením kódu Základní funkcí je, že pokud není nasazena smlouva strany transakce, použije se parametr kódu připojený k transakci k provedení nasazení peněženky smlouvy. Za druhé je také navržen nový operační kód PAYGAS. Kromě placení plynu se stává i transakcí Oddělovač mezi ověřovací částí a prováděcí částí parametrů transakce. I když to tehdy skončilo marně, stalo se nyní jednou z hlavních logik EIP 7702 Každá transakce EIP 7702 je kombinována se speciální transakční strukturou a může být doprovázena určitým kódem, takže adresa EOA má smlouvu. schopnosti v této transakci.

EIP-7702: Nastavte kód účtu EOA 2024-05-07

Toto je také hlavní EIP mechanismu popsaného dále v tomto článku EIP-7702 byl publikován společností Vitalik jako alternativa k EIP-3074 (2024-05-07). Proto je EIP-3074 zastaralé a EIP-7702 je rozhodnuto být zahrnuto do nadcházejícího hard forku ETH Prague/Electra (Pectra). Podrobnosti rozvedeme níže.

3.2 Druhým způsobem je nechat adresu EOA řídit adresu CA

EIP-3074: Přidejte operační kódy AUTH a AUTHCALL--2020-10-15

Přidejte dva nové operační kódy AUTH a AUTHCALL do EVM, což společnosti EOA umožní volat jiné smlouvy prostřednictvím těchto dvou smluv o autorizaci operačních kódů namísto identity EOA. V kombinaci s níže uvedeným obrázkem může EOA v souhrnu odeslat podepsanou zprávu (transakci) na smlouvu, které důvěřuje (nazývaná Invoker), může použít operační kódy AUTH a AUTHCALL k nahrazení tohoto EOA a odeslání tohoto obchodu.

EIP-4337: Použijte transakční paměťový fond k implementaci abstrakce účtu--2021-09-29

V tomto ohledu jsem již napsal mnoho článků, které hluboce analyzují jeho mechanismus. Můžete si přečíst více:

  • https://research.web3 caff.com/zh/archives/3212 ,

  • Výklad plánu přezkoumání abstrakce účtu Ethereum ERC 4337 (část 1)

    Abstraktní zpráva o výzkumu účtu Ethereum o 10 000 slovech: odstranění 10 souvisejících návrhů EIP a sedmiletá cesta k prolomení úzkého hrdla desítek milionů denně aktivních uživatelů

  • Věnujte hodinu vysvětlování záležitosti abstrakce účtu.

Stručně řečeno, byl inspirován MEV k návrhu a jeho základní hodnotou je, že se lze zcela vyhnout změnám protokolu vrstvy konsensu.

eip 4337 navrhuje nový transakční objekt UserOperation Uživatelé odesílají tento objekt do paměťového fondu a svazovači balí a doručují smlouvy v dávkách z dimenze těžařů, aby prováděli transakční transakce k provedení.

EIP-5189: Provozní abstraktní účty prostřednictvím indosantů – 29. 6. 2022

To lze považovat za optimalizaci logiky EIP 4337. Tváří v tvář zlomyslnému Bundlerovi zavádí mechanismus schvalování finančních sankcí, aby se zabránilo útokům blokujícím DoS.

3.3 Další návrhy na podporu AA

EIP-2718: Obálka pro nový typ transakce--2020-06-13

Toto je návrh, který byl dokončen. Definuje nový typ transakce jako obálku pro nové typy transakcí v budoucnu. Čistým efektem je, že když je zaveden nový typ transakce, používá se specifické kódování k rozlišení, o jaký typ transakce se jedná, takže musí být pouze zpětně kompatibilní, ale nikoli dopředně kompatibilní. Nejběžnějším příkladem je EIP 1559, který rozlišuje transakční poplatky a používá nové kódy typu transakce bez ovlivnění původního typu transakce.

EIP-3607: Zajistěte, aby adresy EOA nemohly nasadit smlouvy--2021-06-10

Toto je doplňkové řešení na cestě AA, které se používá k zabránění konfliktu mezi adresou nasazení smlouvy a adresou EOA. Ten bude řídit způsob generování smlouvy, aby systém neumožnil nasazení kódu na adresu, která je již adresou EOA. Toto riziko je ve skutečnosti velmi malé Koneckonců, adresa Ethereum je dlouhá 160 bitů I když existuje způsob, jak použít soukromý klíč ke kolizi se soukromým klíčem zadané adresy smlouvy, bude to stále trvat rok. výpočetní výkon bitcoinu.

3.4 Jak porozumět procesu vývoje abstrakce účtu?

Nejprve musíte pochopit hodnotu převodu na CA

V podstatě jde o skutečný efekt EIP-4337, kterého může dosáhnout

Hlavním nedostatkem EIP-4337 je však to, že porušuje princip lidské motivace.

Zdá se, že je to lepší, ale upadlo to do nekonečného cyklu vývoje trhu Mnoho Dapps není kompatibilních, takže uživatelé nejsou ochotni používat adresy CA a dokonce i používání CA má vyšší transakční náklady (běžné scénáře převodu budou také poplatky za transakce. double) a také příliš spoléhá na kompatibilitu samotného Dapp.

Proto zatím nebyl na mainnetu Ethereum popularizován.

Cena je pro uživatele nejdůležitějším kritériem a náklady je třeba snižovat.

Ale ke skutečnému snížení GAS musí samotné Ethereum provést upgrade soft forku, upravit výpočet GAS nebo upravit spotřebu GAS v operačním kódu a dalších modulech. Protože je však vyžadován soft fork, proč nezohlednit přímo EIP-7702?

4. Komplexní analýza EIP-7702

4.1 Co je EIP-7702

Vyznačuje se novými typy transakcí, které umožňují EOA dočasně mít funkci chytré smlouvy v jedné transakci, čímž podporuje dávkové transakce, transakce bez plynu, vlastní správu povolení atd. v podnikání, aniž by bylo nutné zavádět nový operační kód EVM (ovlivňující dopřednou kompatibilitu).

Umožňuje uživatelům získat většinu schopností AA bez nasazení inteligentních kontraktů a může dokonce poskytnout třetí straně možnost iniciovat transakce jménem uživatelů. Nevyžaduje od uživatelů poskytnutí soukromých klíčů, pouze informace o autorizaci podpisu.

4.2 Struktura dat

Definuje nový typ transakce 0x 04. TransactionPayload tohoto typu transakce je výsledkem serializace s kódováním RLP následujícího obsahu

Důležité je, že je přidán objekt autorizačního seznamu pro uložení kódu, který chce podepisující provést ve svém EOA. Když uživatel podepíše transakci, podepíše také kód smlouvy, který má být proveden, existuje jako dvourozměrný seznam. označující, že informace o více operacích lze uložit v dávkách, proveďte dávkové operace.

4.3 Životní cyklus transakce

4.3.1 Fáze ověřování

Na začátku provádění transakce pro každý [chain_id, address, nonce, y_parity, r, s] n-tice seznamu autorizací:

  1. Použijte ecrecover k obnovení adresy podepisujícího z podpisů r a s (všimněte si, že jde o mechanismus samotného Etherea, takže tento EIP nemění algoritmus podpisu). autorita = ecrecover(keccak(MAGIC || rlp([id_chain_id, adresa, nonce])), y_parity, r, s] (Podobně jako u předchozího řešení podpisu pro získání adresy od, zde se získá místní podpis adresa pro tento seznam)

  2. Ověřte ID řetězu (anti-fork chain replay).

  3. Ověřte, zda je kód podepisujícího oprávnění prázdný nebo zda byl delegován (ověřte, zda je transakce platnou transakcí 7702 a mechanismus delegování bude použit k provedení transakce později).

  4. Ověřte neexistenci autoritativního podpisu (abyste zabránili přehrání autoritního podpisu).

  5. Nastavte kód podepsaného autority na 0x ef 0100 || (používá se k obejití antikolizní politiky EIP 3607)

  6. Zvyšte neexistenci osoby podepisující oprávnění (aby se zabránilo přehrání částečného podpisu).

  7. Přidejte účet autoritního podpisu do seznamu navštívených adres (převeďte horké adresy, abyste snížili poplatek za plyn za skladování dotazu)

4.3.2 Fáze operace provedení

Kde mají být provedeny smluvní kód a provozní pokyny?

"Nová" verze pouze mění chování týkající se nasazení kódu.

Místo nastavení kódu účtu na kód_smluvy získá adresu kódu ze seznamu autorizací a nastaví tento kód jako kód účtu.

Když je tedy potřeba provést autorizační kód, kód se načte z adresy zadané v poli adres seznamu autorizací a provede se v kontextu účtu podepisujícího.

To znamená, že kód smlouvy uživatele je ve skutečnosti uložen na konkrétní adrese v řetězci, nikoli přímo součástí transakce.

Operační instrukce a související parametry jsou uloženy v datovém poli užitečného zatížení transakce.

4.4 Jaká je hodnota EIP-7702?

Dojde ke změnám v celém odkazu peněženky Web3 a dramaticky se změní i uživatelská zkušenost, protože běžné transakce iniciované EOA mohou také provádět různé logiky podobné smlouvám, jako je například dávkový převod. Scénář CeFi ovlivní poplatky za identifikaci transakcí a výběr výběrů Vzhledem ke svému vzniku porušil mnoho předchozích stereotypů, jako například:

  1. Prolomí invariant, že zůstatek na účtu lze snížit pouze transakcemi pocházejícími z tohoto účtu.

  2. Prolomí invariant, že se nonce EOA zvýší o 1 po zahájení provádění transakce (může se zvýšit vícekrát současně).

  3. Logika ochrany dvou srovnání tx.origin a msg.sender je narušena a mnoho minulých smluv je ohroženo.

  4. Narušuje status quo, že EOA sama nemůže vydávat události. Možná bude nutné věnovat pozornost identifikaci a sledování některých on-chain událostí.

  5. Narušuje status quo, že adresy EOA musí uspět při přijímání ERC 20, 721, 1155 a dalších aktiv (může selhat kvůli mechanismu zpětného volání)

4.5 Srovnání mezi EIP-7702 a EIP-4337

1. Výhody EIP-7702

  • Plyn je nižší, protože není potřeba procházet vstupním modulem, což snižuje počet operací v řetězci.

  • Náklady na migraci uživatelů jsou nižší a není třeba předem nasazovat on-chain smlouvy jako předmět.

  • Ve srovnání s Eip 4337 dojde také k provádění delegování kódu a budou existovat také dvě metody:

Plná delegace

  • Úplné delegování znamená delegování všech oprávnění pro operaci na konkrétní adresu. Uživatelé mohou například delegovat práva správy všech tokenů ERC-20 na adresu smart contract, takže tento smart kontrakt může provádět všechny související operace jménem uživatele.

Chráněná delegace

  • Chráněné delegování se týká přidání některých omezení a ochranných opatření během procesu delegování, aby byla zajištěna bezpečnost a ovladatelnost operace delegování.

  • Uživatelé mohou například na smart kontrakt delegovat správu pouze některých tokenů ERC-20 nebo nastavit určitá omezení (například utratit maximálně 1 % z celkového zůstatku za den).

2. Nevýhody EIP-7702

Jeho hlavním nedostatkem je, že se jedná o upgrade soft forku, který vyžaduje souhlas všech, aby jej propagoval, a změny jsou obrovské, což bude mít široký dopad na ekologii řetězce Na základě počátečního hodnocení Čtrnáctého krále jsou následující výzvy, ale výzvy jsou také tržní příležitosti:

  1. Míra volnosti je extrémně vysoká a je obtížné ji kontrolovat. Uživatelé budou potřebovat spolehlivější peněženky, aby poskytovali bezpečnostní ochranu.

  2. Původní struktura se příliš změnila, i když se vyznačuje různými typy transakcí, mnoho infrastruktur, zejména neměnných kontraktů v řetězci, nelze přímo přizpůsobit.

  3. Možnosti smlouvy jsou poskytovány pro adresy EOA, ale odpovídající úložný prostor nelze zachovat.

  4. Náklady na samostatnou transakci jsou o něco vyšší, protože se výrazně zvýší část Calldata. Odhadovaná celková cena hovoru bude 16 (plyn) * 15 (bajtů) = 240 (plyn) náklady na data volání plus náklady na EIP-. 3860 2 * 15 = 30 plus přibližné náklady za běh 150. Proto jen příprava účtu, i když nic neuděláte, přidá 500 Plyn.

  5. "Pokud příjemce podepíše kód bez funkce příjmu, může odesílatel čelit DoS při pokusu o odeslání aktiva." Problém je ve skutečnosti v tom, že EOA A podepsal něco, co neměl - soubor, který lze znovu přehrát, s nesprávně nastavenou implementací (žádná metoda příjmu ()).

  6. Logika výběru v řetězci může být nekonzistentní Pokud například při převodu tokenů ERC-20 má účet příjemce kód, smlouva o tokenu zavolá účet příjemce onERC 20 Received. Pokud onERC 20 Received vrátí nebo vrátí nesprávnou hodnotu, převod tokenu se vrátí zpět.

  7. Také, pokud EOA může vydávat události, nastanou nějaké problémy? Některá infrastruktura může vyžadovat pozornost.

To jsou jen některé z nedostatků, které Shijun shrnul na základě aktuálního obsahu návrhu EIP 7702 a příslušných diskusí na oficiálním fóru. Nakonec je třeba jej plně analyzovat na základě konečného implementačního kódu. Odkaz je následující:

https://eips.ethereum.org/EIPS/eip-7702

https://ethereum-magicians.org/t/eip-set-eoa-account-code-for-one-transaction/19923

https://github.com/ethereum/EIPs/pull/8527

5. Shrnutí plného textu

Tento článek se zdá být dlouhý, ale ve skutečnosti má textový obsah pouze více než 6 000 slov. Mnoho předchozích interpretací EIP, které jsou v něm obsaženy, lze rozšířit pomocí odkazů v článku, takže se k tomu nebudu vracet.

V současné době lze abstrakci účtu skutečně umístit pouze do šestého modulu, který má vše opravit, tedy implementovat. Nyní, když se vývoj EIP 7702 výrazně zrychlil, přineslo systému další výzvy Jak lze očekávat, nakonec si to uvědomí, může dojít k rušivým událostem, jako je fúze Etherea a modifikace konsensuálního algoritmu, takže co nové typy transakcí?

Tentokrát však došlo k příliš velkému podvratu, porušení nemožných skrytých pravidel na více řetězcích a porušení aplikační logiky většiny Dapps. To však pevně obsadilo hlavní bod, kterým je, že náklady pro uživatele jsou nižší. V porovnání s EIP 4337 se transakční náklady téměř zdvojnásobily.

Samotný uživatel je stále adresou EOA a řídí a používá logiku CA pouze v případě potřeby, takže náklady na držení jsou nízké. Před prováděním operací není nutné konvertovat identitu CA v řetězci, což znamená, že uživatelé se nemusí registrovat.

Uživatelé mohou snadno použít EOA k dosažení více transakcí paralelně, jako je autorizace zadržování a provádění zadržování v jedné, což snižuje transakční náklady pro uživatele pro Dapps, zejména pro ty, kteří vyžadují řízení na podnikové úrovni v rámci projektu, jako jsou burzy , provedli rušivé optimalizace Jakmile je dávková agregace realizována v původní ekologii, mohou být základní směnné náklady během okamžiku sníženy o více než polovinu, z čehož mohou mít nakonec prospěch uživatelé.

Proto, i když se hodně změnil, rozměr nákladů stojí za prostudování a přizpůsobení všem Dappům, protože tentokrát musí být uživatelé na straně EIP 7702.