EIP-3074 se přes noc stalo nejžhavějším tématem, protože bylo schváleno pro zařazení na další hard fork Ethereum (Pectra/Petra). O čem je však ten humbuk a jak to ovlivní Ethereum a ekosystém EVM? V tomto článku prozkoumáme tento návrh, odpovíme na často kladené otázky a rozptýlíme některé mýty a nedorozumění. Pojďme se ponořit, ano?
Abstrakce účtu Přehled EIP/ERC
Abyste lépe porozuměli abstrakci účtu, musíte vědět, že 99 % případů, kdy někdo řekne „Abstrakce účtu“, myslí „chytré (smluvní) účty“, což je případ, kdy je účet založen na kódu smlouvy, nikoli na jediný soukromý klíč. Stále může být ověřena jedním soukromým klíčem, jak je tomu většinou (to je důležité později), ale může to být také peněženka s více podpisy, jako je tomu u Safe.
Původní význam „abstrakce účtu“ byl „umožnit chytrým kontraktům iniciovat transakce“, ale to se od té doby změnilo na „všechny funkce, které umožňují chytré kontrakty“.
Inteligentní smluvní účty umožňují tyto a další funkce
Abstrakce plynu: dApps sponzorující plyn, uživatel platící plyn různými tokeny ERC20 nebo dokonce předplacení plynu, což je skvělé pro cross-chain onboarding.
To je vynikající pro ochranu soukromí a OpSec, protože to eliminuje doxxování sebe sama tím, že žádáte přátele, aby financovali váš účet pomocí ETH MATIC, bez ohledu na nativní měnu řetězce / souhrnu, nebo v horším případě výběr z burz.
Dávkování transakcí: Nebo sdružování více akcí do jedné transakce. To je fantastické jak pro bezpečnost, tak pro účinnost plynu.
Zabezpečení: Řešení schválení ERC-20. Jako vedlejší efekt dávkování můžeme provést přesné schválení množství spolu s každou akcí, která to vyžaduje, takže problém se schválením zmizí. Proč? Protože nepotřebujeme nekonečná/zbylá schválení a nepotřebujeme ani druhý podpis pro schválení.
Vlastní kryptografie: Povolení nových kryptografických křivek, WebAuthn, zabezpečená enkláva iOS, kvantová bezpečnost a další.
Rotace klíčů a obnovení účtu: Změna soukromých klíčů pro stávající účet nebo obnovení účtu prostřednictvím schémat, jako je sociální obnova společnosti Argent
Všimli jste si něčeho? To vše nějakým způsobem pomáhá bezpečnosti.
Zpět k ERC.
Obecně platí, že všechny ERC související s abstrakcí účtů prohlašují tyto vlastnosti za svou motivaci, ale nemusí je nutně poskytovat; jen pomáhají připravit cestu k tomu, aby se tyto funkce staly mainstreamem.
Pojďme to rozebrat. Velké ERC řeší různé problémy:
Zahájení transakce: Schopnost smluv zahájit transakce.
Nativní: speciální typ transakce v protokolu, který může pocházet z inteligentní smlouvy. Zahrnuje ERC-2938, později nahrazený RIP-7560
Emulovaný: ERC-4337 je „emulovaný“ v tom smyslu, že transakce jsou ve skutečnosti stále iniciovány EOA. To neznamená, že uživatel musí být informován o tomto EOA. Tento EOA je řízen a provozován dodavatelem.
Převádění stávajících uživatelů: zde přichází na řadu EIP-3074 (a jeho menší pomocník ERC-5003)
EIP-3074 umožňuje delegovat řízení STÁVAJÍCÍHO EOA na inteligentní smlouvu. Inteligentní smlouva může ovládat tuto EOA a volat z její adresy, ale nemůže iniciovat transakce. To je důležité, protože stále musíme vyřešit problém se zahájením transakce.
ERC-5003 umožňuje „plnou“ konverzi EOA na účet inteligentní smlouvy díky zrušení původního soukromého klíče, který funguje jako hlavní klíč k tomuto EOA.
Podpisy: Smlouvy obvykle nemohou podepisovat podpisy. Ale dokážou - mohou definovat logiku, která definuje, co je platný podpis pro tuto smlouvu. Například peněženka inteligentní smlouvy, která je multisig mezi Bobem a Alicí, bude definovat platný podpis jako isValidSignature = isValid(bobsSignature) AND isValid(alicesSignature). To je třeba definovat v kódu smlouvy.
ERC-1271 definuje rozhraní, aby se to stalo.
ERC-6492 jej rozšiřuje o podporu dosud nenasazených účtů s inteligentními smlouvami: to umožňuje bezproblémovou stejnou adresu ve všech řetězcích a zároveň umožňuje uživateli podepisovat zprávy.
Obojí musí být implementováno dApps, aby fungovalo.
Chcete-li skutečně vytvořit AA zážitek, musíte vyřešit všechny výše uvedené současně. To je důvod, proč EIP-3074 nekonkuruje ERC-4337, RIP-7560 ani žádnému jinému ERC abstrakce účtu.
Pokud to vše chcete vidět vizuálně, doporučujeme tento snímek z přednášky o demystifikaci AA ERC.
Společný EIP-3074 FUD, který boří mýty
Začněme se slonem v místnosti. Existují tři části FUD související s EIP-3074:
Umožňuje škodlivým dApps vyčerpat existující peněženky v jedné transakci: Je pravda, že takový podpis lze vytvořit, ale neexistuje žádný důvod nebo případ použití pro poskytovatele peněženky, aby někdy umožnil dApps, aby vás přiměly podepsat takové požadavky. Zabezpečení ze strany peněženky je mnohem jednodušší než zabezpečení samotného soukromého klíče a únik soukromého klíče má stejný účinek.
Účet si uchovává jeden hlavní klíč (původní klíč EOA) Existuje další ERC, které to řeší, EIP-5003, jinak známý jako AUTHUSURP, který umožňuje odvolat původní soukromý klíč
EIP-3074 je náplast, která nepřináší výhody nativního AA: EIP-3074 nikdy neměl konkurovat skutečným návrhům AA, jako je RIP-7560. Není to náplast pro AA; je to migrační cesta. Stále potřebujeme nativní AA, protože, jak si pamatujeme dříve, neřeší problém se zahájením transakce.
Výhody a nevýhody EIP-3074
Pro: Vytváří velmi snadnou migrační cestu pro stávající uživatele MetaMask, Trezor, Ledger atd., aby si vyzkoušeli funkce abstrakce účtů na svých stávajících účtech.
Proti: Obětuje rotaci klíčů. I když lze povolit všechny výše uvedené funkce AA, střídání klíčů se stává lehce nepolapitelným, protože původní soukromý klíč si zachovává kontrolu nad účtem ve všech sítích, které nebyly nikdy použity, dokonce i s EIP-5003.
Mentální cvičení
Zde je mentální cvičení, které vám pomůže porozumět pohyblivým částem:
Na hlavní síti Ethereum existuje EOA, аlice.eth (0x696969..69). Tato EOA je z definice cross-chain, takže existuje také na všech kumulativních a EVM řetězcích.
Tento EOA je řízen výhradně soukromým klíčem A, který vlastní Alice.
EIP-3074 bude spuštěn.
Zlomyslný dApp se snaží Alici vykrást a požádá ji, aby podepsala podpis EIP-3074 AUTH, čímž autorizuje škodlivou smlouvu. Peněženka tento požadavek ignoruje a odpojí dApp, protože je dobře implementována a neexistuje žádný případ použití, kdy by to dApp umožňoval.
Alice klikne na tlačítko „povolit abstrakci účtu“ na jejich poskytovateli peněženky (řekněme MetaMask, přes Snap nebo Ambire, nativně). Peněženka podepisuje podpis EIP-3074 AUTH, který autorizuje smlouvu vytvořenou poskytovatelem peněženky, která pomáhá provádět dávkování, sponzorství plynu atd.
Tato smlouva je řízena výhradně soukromým klíčem A.
alice.eth je nyní odděleně řízena dvěma subjekty: soukromým klíčem A (v režimu EOA) a novou smlouvou, která je sama o sobě také řízena výhradně soukromým klíčem A.
Alice nyní může dávkovat, ale aby mohla sponzorovat plyn, musí poskytovatel peněženky Alice implementovat buď ERC-4337 nebo RIP-7560 (pokud to síť podporuje), nebo proprietární relé, aby Alice nemusela používat své ETH ( což je tvrdý požadavek sítě, pokud chcete zahájit transakci).
Alice se rozhodne převést alice.eth na multisig a poskytovatel peněženky instruuje smlouvu, aby zrušila soukromý klíč A a autorizovala 2/2 multi-sig soukromých klíčů BMobilePhone a BLaptop.
To však nefunguje, protože soukromý klíč A stále ovládá Alice.eth: Podle EIP-3074 si původní soukromý klíč zachovává kontrolu, přestože byl delegován na smlouvu.
EIP-5003 je spuštěn na Ethereu a umožňuje alice.eth odeslat speciální pokyn do sítě prostřednictvím svého poskytovatele peněženky, aby zrušil kontrolu nad soukromým klíčem A.
alice.eth je nyní úspěšně převedena na multi-sig, ale pouze na Ethereu. Soukromý klíč A (vlastněný Alice) si stále zachovává kontrolu nad alice.eth ve všech ostatních sítích.
Nakonec jsme se naučili několik věcí:
Dokázali jsme něco úžasného, protože bez EIP-3074 by Alice pravděpodobně nikdy nepřijala abstrakci účtu.
EIP-3074 neřeší vše; stále potřebujeme ERC-4337 a RIP-7560 tolik, kolik jsme potřebovali včera.
EIP-3074 si nehraje pěkně s rotací kláves, i když máme EIP-5003. To je důvod, proč stále potřebujeme skutečné chytré účty, abychom usnadnili případy použití, jako je multi-sig a střídání klíčů.
Jako vedlejší poznámku se domníváme, že střídání klíčů je pro většinu příliš nové a trochu spletité ve světě napříč řetězci, kde nemáte stejný stav mezi všemi souhrny a řetězci. Zdá se, že většina uživatelů se drží paradigmatu jeden klíč = jeden účet, zejména u hardwarových peněženek, které jsou dostatečně bezpečné pro většinu případů použití.
FAQ
Zbytek tohoto článku bude ve formátu typu FAQ, abychom mohli lépe odpovědět na některé z nejčastějších otázek, které lidé mají.
Pomáhá MetaMask dostat se dopředu?
Věříme, že společnosti zabývající se abstrakcí účtů získají mnohem větší hodnotu ze snazšího začlenění uživatelského rozhraní než stávající společnosti z toho, že budou moci nabízet funkce AA svému stávajícímu publiku.
Jinými slovy, „uvolňuje“ sílu AA peněženek nad celým adresným trhem, nejen pro ty, kteří chtějí své prostředky přesunout na novou adresu.
Díky MetaMask Snaps se mnoho AA společností zaměří na budování AA na MetaMasku, což je umístění mozku galaxie, které nikdo kromě nejbystřejších pozorovatelů neviděl přicházet.
Je samotné dávkování nebezpečné?
rozhodně ne. Stále vidíte, co podepisujete. To v kombinaci se simulací transakcí znamená, že podepsání více akcí je stejně bezpečné a ve většině praktických případů bezpečnější než podepsání jedné akce.
Dávkování transakcí je jednou z nejoceňovanějších funkcí abstrakce účtu
Pomáhá to dApps přijmout AA? Řeší problémy s kompatibilitou?
dApps fungují s jakoukoli formou abstrakce účtu s některými výjimkami:
Některé dApps diskriminují chytré (smluvní) účty
Některé dApps nepodporují ERC-1271
EIP-3074 magicky řeší oba problémy: účty se zobrazují jako EOA (nemají žádný kód), takže je nelze diskriminovat. Co se týče podpisů, EOA s povoleným AA (přes 3074) se budou stále podepisovat jako EOA, takže se nekoná žádné drama. Bude to magicky fungovat se všemi dApps na úkor ztráty rotace klíčů.
Pokud však většina lidí zvolí EOA s povoleným AA před čistě inteligentními účty, odrazuje to dApps od podpory ERC-1271 a ERC-6492, ale ERC-4337 již pomohl zvýšit povědomí o návrhech podpisů.
Co takhle zrušit původní klíč?
Klíč můžete odvolat přes EIP-5003 (což zatím není v hard forku plánováno).
Jedna nuance je v tom, že to není dokonalé řešení ve světě napříč řetězci. EOA bude vždy začínat jako EOA na každém novém řetězci, který začnete používat, což znamená, že původní klíč nelze nikdy skutečně odvolat. Ale to platí pro každou formu AA, protože původní oprávnění/privilegia, se kterými jste vytvořili účet, jsou vždy tím, čím účet začíná v jakékoli nové síti.
EIP-3074 funguje lépe, když přináší všechny funkce AA kromě rotace klíčů do stávajících EOA. Jinými slovy, pokud se rozhodnete povolit AA pro EOA, navždy zůstanete s původním soukromým klíčem za tímto EOA.
Zabije to nativní AA (RIP-7560)?
Ne, protože stále potřebujete řešení pro zahájení transakce, alespoň pokud chcete platit plyn jiným tokenem, než je nativní (nebo potřebujete sponzorství plynu).
ERC-4337 je jedno takové řešení, které nevyžaduje upgrady protokolu (není nativní), ale nativní, protokolově zakotvené AA je nesmírně cenné, protože řeší režii plynu a složitost ERC-4337.
Ale pane, co EIP-7377?
EIP-7377 umožňuje převod EOA na chytrý účet. Namísto toho, aby inteligentní kontrakt řídil EOA spolu s původním PK, tento EIP umožňuje kontraktu převzít EOA v jedné transakci.
Lze jej považovat za alternativu k EIP-3074 + EIP-5003, ale nezískal tolik dynamiky.
Závěrečné myšlenky
EIP-3074 není náplast. Je to extrémně optimistické pro budoucnost Etherea a ekosystému EVM, protože žádat od uživatelů, aby náhle opustili své stávající účty a převedli všechny své prostředky, sázkové pozice atd., na nový účet (účet pro chytré smlouvy), výrazně zvyšuje bariéru vstupu.
EIP-3074 poskytne novou střední cestu a postupné onboarding, což je přesně to, co potřebujeme k dramatickému vylepšení UX.
Zajímá vás Ambire? Sledujte nás:
Rozpor | X (Twitter) | Reddit | GitHub | Telegram | Facebook
