EIP-7002: Lepší způsob, jak vsadit na Ethereum

Přechod Etherea z Proof of Work (Pow) na Proof of Stake (PoS), neboli The Merge, byl klíčovým momentem v historii sítě. Kromě toho, že Ethereum získalo velmi potřebnou rebrandu snížením jeho uhlíkové stopy, byl Proof of Stake zásadní pro klíčový dlouhodobý cíl: snížení překážky účasti na konsensu Etherea. Sloučení nahradilo výpočetní zdroje (těžební sílu) finančním kapitálem jako základem ekonomického zabezpečení Etherea – otevřelo možnost komukoli ziskově a snadno provozovat validátorový uzel vložením 32 ETH do Beacon Chain.

I když Proof of Stake přinesl výhody, stále existuje mnoho oblastí ke zlepšení. Některé z nich zahrnují:

• Snížení centralizace sázek a kartelizace ověřovatelů
• Minimalizace provozní režie pro validátory a pobídky pro sólo vytyčování
• Zlepšení ekonomiky stakingu a uživatelské zkušenosti (UX)
• Zlepšení jednoduchosti, bezpečnosti a decentralizace delegovaných a vícestranných stakingových operací

EIP-7002: Execution Layer Triggerable Withdrawals je nový návrh na vylepšení Etherea (EIP), který řeší některé z výše uvedených problémů. EIP zavádí mechanismus pro stakery k validátorům stažení z Beacon Chain pomocí přihlašovacích údajů pro stažení namísto spoléhání se na podpisový klíč validátora ke spuštění operací stažení – účinně odděluje podpisový klíč validátora od klíče pro výběr.

Toto „oddělení obav“ mezi podpisovými klíči validátoru a klíči pro výběr má zásadní přínos: snižuje předpoklady důvěry v delegované sázky tím, že umožňuje výběr pověření, aby si udržela kontrolu nad vsazeným ETH. V průběhu tohoto článku prozkoumám, proč je tato funkce nezbytná, a prodiskutuji další výhody EIP-7002, zejména pro sólové vytyčování a vytyčování DVT (technologie distribuovaného validátoru). Článek také zváží některé potenciální nevýhody implementace EIP-7002 na Ethereum.

Pojďme se ponořit!

Příprava jeviště: Příběh klíčů, bílých rukavic a smutku (smutku)

Pokud chcete vsadit ETH a ověřit Beacon Chain dnes, máte dvě základní možnosti: sólo sázky a delegované sázky; existují i jiné způsoby, jak sázet ETH, ale tyto víceméně výběry na spektru mezi výše uvedenými možnostmi. Sólové vytyčování je jednoduché:

• Vložte 32 ETH do smlouvy o vkladu Beacon Chain a aktivujte nový validátor
• Generování klíčů pro provádění povinností validátoru (ověření transakcí, atestace bloků, agregace atestací a navrhování bloků)
• Nastavte uzel validátoru a synchronizujte klienta prováděcí vrstvy (EL) a konsensuální vrstvy (CL).
• Udržujte svůj validátor online a správně fungující, abyste se vyhnuli sankcím

Kroků je více ( Validator FAQ na Staking Launchpadu má skvělý přehled pro potenciální validátory), ale toto jsou zhruba nejdůležitější aspekty spuštění validátoru. Důležité je, že sólo staking nevyžaduje žádného prostředníka ani protistranu a umožňuje vám ponechat si 100 % odměn získaných z validace (potvrzení bloků a navrhování bloků) na Beacon Chain. Ale není to oběd zdarma: máte odpovědnost za správu svého validátoru a budete potřebovat určitou úroveň technických znalostí, abyste mohli provozovat sólo vytyčovací operaci.

Pokud se vám myšlenka na správu validátoru zdá složitá, můžete jít cestou delegovaného vytyčování. Stále jste odpovědní za poskytnutí 32 ETH k registraci nového validátoru – teprve nyní delegujete odpovědnost za provoz validátoru na třetí stranu. Operátor validačního uzlu poskytuje to, co by někteří popsali jako „službu bílých rukavic“ a požaduje za tuto službu kompenzaci. Můžete být například požádáni o sdílení části odměn vašeho validátoru s operátorem uzlu jako součást počáteční smlouvy.

Část „bílá rukavice“ znamená, že operátor přebírá odpovědnost za udržení vašeho validátoru v provozu a zabezpečení – což znamená, že můžete dělat věci, jako je streamování Netflixu v pátek večer (nebo cokoli jiného, co děláte ve svém volném čase), aniž byste se museli obávat penalizací za chybějící povinnosti validátoru. nebo se obáváte o bezpečnost vašich validačních klíčů.

Je tu však varování: Delegované sázky vyžadují důvěřovat operátorovi uzlu, aby se vyhnul riziku ohrožení vašich 32 ETH spácháním přestupku, který lze krájet (např. podepsáním dvou konfliktních bloků) nebo přímo krádeží vašich prostředků. Je toho hodně, co je potřeba žádat – a rozhodně ne pro lidi s problémy s důvěrou – ale uspořádání většinou funguje dobře, když jsou operátoři uzlů poctiví.

Ethereum ale nebylo postaveno na étosu „důvěřuj mi brácho“ web2, a proto se v konverzacích na krypto-Twitteru a Redditu často objevují „důvěryhodnost“ a „důvěryhodnost“. Delegované vytyčování ve své nejčistší podobě je v rozporu s tímto étosem, ale existuje řešení ze způsobu, jakým jsou páry klíčů generovány během procesu aktivace nového validátoru.

Každý validátor má dva klíče: klíč pro výběr a klíč validátoru. Klíč pro výběr je pár veřejného a soukromého klíče potřebný k částečnému nebo úplnému výběru zůstatku validátoru Beacon Chain v závislosti na tom, zda chcete „vybrat“ (vybrat pouze odměny) nebo „ukončit“ (vybrat zůstatek 32 ETH + odměny) . Upozorňujeme, že klíč pro výběr musí být aktualizován z výchozích pověření BLS ( 0x00 ) na pověření 0x01 , které ukazují na adresu Ethereum, aby bylo možné částečné nebo úplné stažení zůstatku validátoru.

Výběrový klíč je generován v době vkladu prostřednictvím rozhraní, jako je Staking Launchpad, a hashován, aby se vytvořilo ID výběru, které je zahrnuto v datech vkladu validátoru – což poskytuje Beacon Chain informace o tom, kdo vložil 32 ETH. Níže uvedená infografika z Protecting Selection Keys by Attestant poskytuje skvělý přehled o tom, jak je klíč pro výběr integrován do procesu žádosti o vklad validátoru:

Validátorový klíč je veřejno-soukromý klíčový pár vyžadovaný pro vykonávání povinností očekávaných od každého Etherea validátoru – především hlasování pro bloky a navrhování bloků, o kterých mohou hlasovat ostatní („hlasování“ a „atestování“ se používají zaměnitelně, ale vztahují se ke stejnému konceptu ověřování transakcí a potvrzování platnosti bloků). Veřejný klíč validátoru slouží jako jeho jedinečná kryptografická identita v konsensuálním protokolu Etherea, zatímco se očekává, že soukromý klíč bude skryt a použit pro podepisování blokových dat (klíče validátoru jsou z tohoto důvodu také popisovány jako podpisové klíče).

Nyní k hlavnímu rozdílu mezi validačními (podepisovacími) klíči a výběrovými klíči:

Podpisový klíč validátoru se používá často – představte si každých 6,5 minuty nebo délku bloku, během kterého bude každý validátor vybrán, aby potvrdil nebo navrhl blokování – a nejlépe je uchovávat na online, snadno dostupném místě, jako je horká peněženka. Výběrový klíč se však používá méně často a může být uchováván na bezpečném offline místě, jako je peněženka, dokud si sázkař nepřeje vybrat prostředky z adresy pro výběr spojené s konkrétním validátorem.

Toto rozlišení je zásadní pro snížení předpokladů důvěry v nastavení delegovaného sázky: protože klíč pro výběr není vyžadován pro povinnosti ověřování, může si sázející ponechat kontrolu nad vsazeným ETH sdílením validačního klíče s operátorem uzlu a držením klíče pro výběr. Tímto způsobem nemůže nepoctivý operátor utéct s peněžními prostředky sázkaře po výběru zůstatku validátora bez souhlasu sázkaře.

Delegovaná ujednání o sázkách, kde sázkař drží klíč pro výběr, jsou obvykle popsána jako „neuschovatelská“, aby odrážela, že subjekt provozující validační uzel jménem sázkaře nakonec nemá kontrolu nad sázeným ETH. To je v protikladu k řešením úschovy sázek, ve kterých sázková služba kontroluje jak podpisové, tak i vyjímací klíče; „služba v bílých rukavicích na steroidech“ je dobrý mentální model pro úschovu sázek: sázkař jednoduše poskytne 32 ETH na financování validátoru a vše ostatní – včetně iniciování žádostí o vklad validátoru a uložení výběrových klíčů – deleguje na sázkovou službu).

Oddělení podepisovacích klíčů validátoru od klíčů pro výběr teoreticky řeší problém důvěry v dohody o delegovaném stakingu. V praxi má vztah mezi operátorem uzlu a sázkařem v neopatrovaném nastavení sázek stále prvek důvěry kvůli současnému mechanismu pro stažení validátoru a spuštění úplného nebo částečného stažení zůstatku validátoru na adresu pro výběr.

Chcete-li stáhnout validátor z Beacon Chain, musí být odeslána ke zpracování na konsensuální vrstvě „Voluntary Exit Message“ (VEM) podepsaná klíčem validátoru. Po zahrnutí do bloku (každý blok může obsahovat maximálně 16 operací s žádostí o výběr) se zpráva o výběru přidá do fronty žádostí o výběr — se zpožděním konečného výběru ovlivněným faktory, jako je y počet výběrů ve frontě nebo validátor míra odchodu.

Zdůraznil jsem požadavek podepsat dobrovolnou žádost o stažení podpisovým klíčem validátoru, abych upozornil na problém se stávajícími „nevěrnými“ řešeními vytyčování: stakeholder se musí spolehnout na operátora uzlu – který ovládá validátorový klíč potřebný k podpisu VEM – aby zpracovat žádosti o výběr. To účinně znovu zavádí důvěru do vztahu mezi provozovateli uzlů a službami vytyčování; horší je, že vystavuje stakeholdery riziku, že budou „zarmouceni“ zlomyslnými operátory uzlů.

Při truchlícím útoku je cílem útočníka způsobit ztráty druhé straně – ne nutně mít přímý prospěch. Abychom to uvedli do kontextu, zvažte scénář, kdy Alice deleguje Boba, aby jejím jménem provozoval validátor, ale později se rozhodne stáhnout svých 32 ETH. Bob by mohl splnit požadavek Alice a spustit žádost o výběr podepsáním zprávy o dobrovolném odchodu (VEM)… nebo odmítnout podepsat zprávu s žádostí o výběr a zastavit operaci Alice. Bob nebude mít přímý prospěch z odmítnutí Aliciny žádosti – jediné, co může udělat, je držet Alicino ETH „rukojmím“ tím, že odmítne Alici pomoci stáhnout její validátor.

Dobře, to není 100% přesné; Bob může udělat mnoho špatných věcí, aby způsobil Alici ještě větší „smutek“:

1. Snižte Alicinu validátorovou bilanci tím, že se úmyslně dopustíte přestupku, který lze seřezat, nebo uvalením trestů. Individuální trest za nesplnění povinností ověřovatele (např. chybějící atestace) nebo spáchání přestupku, který lze podtrhnout (např. podepsání dvou konfliktních bloků ve stejném slotu) je obvykle nízký, ale zvyšuje se úměrně počtu ověřovatelů, kteří se dopustí podobných přestupků ve stejném období. . Například chybějící jedno nebo dvě atestace sníží zůstatek validátoru o malý zlomek, ale toto snížení exponenciálně vzroste, pokud dojde k úniku nečinnosti – kde je více validátorů offline –.

   
   

Podle současného mechanismu může zlomyslný Bob snížit Alicin zůstatek validátoru ve výši 32 ETH až o 50 procent tím, že bude penalizován a seká, dokud nebude validátor násilně stažen z konsensu Beacon Chain (poté, co jeho efektivní zůstatek klesne na 16 ETH). Pokud použijeme 1 ETH = 2 000 $, Bobův truchlící útok bude stát Alici v normálním případě nejméně 32 000 $ (16 ETH) a v nejhorším případě 64 000 $ (32 ETH) (tj. být sníženy kvůli korelačním sankcím).

Kdo může věc zničit, věc ovládá. — Paul Atreides (Duna)

1. Požadujte od Alice výkupné výměnou za to, že se nedopustíte trestného činu. To se přesně neshoduje s předchozí definicí smutku, ale vezměte v úvahu, že Bobovým jediným východiskem je spálit ETH, pokud se Alice rozhodne hrát tvrdě. Situace se tak liší od běžnějších typů útoků, kde je cílem (vždy) zisk s minimální ztrátou.

Poznámka: Bob (operátor uzlu) může být v tomto scénáři ve skutečnosti upřímný, ale protivník by mohl kompromitovat klíč validátoru a držet Alicino ETH jako rukojmí. To vysvětluje „riziko protistrany“, které musí nést uživatelé platformy sázek jako služba (SaaS), a je to další důvod, proč je sólo sázení – s jeho étosem „nevěřte nikomu kromě sebe“ – považováno za zlatý standard pro sázející Ethereum. .

Znamená to, že každá nevazební sázková služba ve skutečnosti není nevazební? Ne přesně. Jednoduchým řešením je, že sázková služba předem podepíše zprávu s žádostí o dobrovolný výběr – nejlépe po aktivaci validátoru na Beacon Chain – kterou může sázející nezávisle odeslat konsensuálnímu uzlu Ethereum, kdykoli si přeje stáhnout.

Předběžným podepsáním žádostí o dobrovolné stažení pro sázkaře se ujednání mezi sázejícím a operátorem uzlu vrátí do původního stavu, který není opatrovnický. Předem podepsané zprávy s žádostí o stažení však nejsou udržitelné z mnoha důvodů:

Problémy s předem podepsanými žádostmi o výběr pro nevazební sázky

Složitost

Pracovní postupy s předem podepsanými žádostmi o výběr vyžadují více komunikace mezi operátorem sázkové služby a delegátorem sázek: musíte odeslat žádost o zprávu s žádostí o výběr a počkat, až služba vysazení podepsané žádosti o výběr odešle. Existuje také problém zabezpečení při používání a výměně předem podepsaných žádostí o výběr:

• Sázková služba musí přijmout zvláštní opatření – jako je zašifrování zprávy s žádostí o výběr a její sdílení prostřednictvím zabezpečeného (mimo řetězce) komunikačního kanálu – aby se zprávy s žádostí o výběr nedostaly do nesprávných rukou.
• Staker musí přijmout zvláštní opatření, aby uložil zprávu s žádostí o výběr na bezpečné místo, protože ztráta zprávy s žádostí o výběr se rovná potenciální ztrátě schopnosti nezávisle vybrat zůstatek validátoru.

Kromě toho jsou předem podepsané žádosti o výběr aktuálně platné po dobu dvou forků Etherea nebo ~12 měsíců – pokud očekáváte, že k forkům dojde zhruba každých šest měsíců. To znamená, že sázkař musí znovu podat žádost o dobrovolný výběr provozovateli vytyčovací služby několikrát v kalendářním roce. To již nebude případ, kdy je implementován EIP-7044 a podepsané žádosti o stažení validátoru se stanou platnými na dobu neurčitou.

EIP-7044 opravuje problém s vypršením výstupních zpráv, ale přináší novou sadu problémů – zejména u velkých sázkových fondů. Současným přístupem v decentralizovaných stakeholderech je vyžadovat, aby noví operátoři validačních uzlů předkládali předem podepsané žádosti o výběr, než budou financovány fondem. Zde podepsané žádosti o výběr poskytují kryptoekonomickou bezpečnost, protože snižují sílu, kterou má (nedůvěryhodný) operátor nad prostředky validátoru; stakeholder může spustit žádost o výběr nespolupracujícího operátora validačního uzlu odesláním předem podepsané žádosti o výběr v řetězci.

Operátor validačního uzlu se však nebude cítit dobře, pokud jsou předem podepsané požadavky na výběr uloženy na náhodném serveru kvůli riziku, že někdo náhodně/úmyslně spustí falešné požadavky na výběr tím, že se zmocní podepsané výstupní zprávy. V nejhorším případě by nucené odchody pravděpodobně vedly ke ztrátě operátora uzlu validátoru (např. pokud jste si vzali půjčku proti budoucím odměnám Beacon Chain). To znamená, že sázkové fondy musí přijmout ještě více bezpečnostních opatření a bezpečně ukládat zprávy s žádostmi o výběr, zejména ve světě po EIP 7044, kde podepsané žádosti o výběr mají nekonečnou dobu platnosti.

Potenciálním řešením je zašifrovat podepsané žádosti o stažení pomocí sdíleného veřejného klíče generovaného prostřednictvím protokolu DKG (Distributed Key Generation) a vyžadovat kvorum sdílených klíčů k rekonstrukci soukromého klíče, než bude možné žádost o stažení dešifrovat. To snižuje předpoklad důvěry, který přichází s tím, že jedna strana ukládá žádosti o výběr, za předpokladu, že nikdo neovládá dostatek sdílených klíčů, aby mohl jednostranně dešifrovat předem podepsané požadavky na výběr bez vstupu ostatních účastníků. Okrajový případ se však objeví, pokud dojde k nesprávnému umístění, ztrátě nebo odcizení jednoho nebo více sdílených soukromých klíčů – což znesnadňuje nebo zcela znemožňuje dešifrování podepsané žádosti o výběr, pokud je nutné spustit výběr validátorem.

Dodržování předpisů

Stakingové služby se dostaly hodně pod kontrolu abecední polévky regulátorů, zejména SEC (Securities and Exchanges Commission) vedené veřejným nepřítelem kryptoměn č. 1: Gary Genslerem. Například společnost Kraken na začátku tohoto roku ukončila svou operaci depozitního staking-as-service a zaplatila 30 milionů dolarů na pokutách za „nabízení neregistrovaných cenných papírů prostřednictvím své platformy pro krypto sázky“.

Teoreticky je nepravděpodobné, že by se neopatrovatelská sázková služba dostala do hledáčku SEC kvůli neopatrovací povaze její dohody s vlastníkem sázky:

1. Vklad 32 ETH (nebo násobky 32 ETH) pro aktivaci validátoru pochází z adresy výběru kontrolované stakerem – a protokol identifikuje adresu pro výběr jako vlastníka vkladu 32 ETH. To znamená, že necustodial staking service nemůže vybrat zůstatek validátoru a „míchat peníze zákazníků se svými vlastními“, jak byl Kraken obviněn SEC.

Na burze, jako je Kraken, je zůstatek v peněžence uživatele „virtuální“, protože všechny prostředky zákazníků jsou drženy v jedné nebo více peněženkách, které burza ovládá. Pokud tedy vsadíte 32 ETH prostřednictvím služby úschovy sázek provozované burzou, to, co skutečně máte, je IOU od burzy, která slibuje, že vrátíte 32 ETH (plus procento odměn validátorů), kdykoli budete chtít vybrat.

1. Stakeři mohou nezávisle vybírat prostředky předložením předem podepsaných výstupů, aniž by riskovali, že nepoctivá sázková služba zabrání výběrům. Naproti tomu depozitní sázková služba – zejména burza jako Kraken – má kontrolu nad aktivy sázkaře a může blokovat výběry z libovolných důvodů.

Tyto dvě skutečnosti odstraňují potřebu „ochrany investorů“; Nejsem odborník na politiku, takže omluvte případné chyby v této úvaze. Ale stále tu může být malá vráska nebo dvě, pokud dnes provozujete institucionální, nevazební službu:

• Během krátkého (nebo pravděpodobně dlouhého) období mezi aktivací validátoru a odesláním předem podepsaného dobrovolného odchodu stakerovi, sázková služba řídí 32 ETH – což z něj činí v očích regulátora „pečovatelský“. Problém dále komplikují krátká data vypršení platnosti předem podepsaných výstupů (před EIP 7044): mezi okamžikem, kdy je podepsána nová výstupní zpráva a odeslána vytyčovači, má operátor validačního uzlu určitou kontrolu nad vsazeným ETH.
• Zatímco běžné výstupní zprávy jsou vysílány v řetězci a veřejně ověřitelné, předem podepsaný odchod musí být zašifrován a sdílen mimo řetězec soukromě mezi operátorem uzlu a stakerem. Tím je pro třetí stranu, jako je regulátor, obtížnější ověřit, že sázková služba skutečně podepsala záměr opustit jako součást původní smlouvy o uložení validátoru – nebo pokud se výměna opakovala poté, co vypršela platnost původní výstupní zprávy (tj. -EIP 7004).

Shrnuto: předem podepsané exity zmírňují některé problémy s delegovaným sázením, ale nestačí k tomu, aby sázky na Ethereum byly důvěryhodné, bezpečné a decentralizované. Abychom „nevazební“ vrátili zpět do nevazebních sázek, potřebujeme lepší řešení – které nyní máme díky EIP-7002. Následující oddíly se budou podrobně zabývat EIP-7002 a dotknou se různých výhod EIP i potenciálních problémů spojených s jeho implementací.

Přehled EIP-7002: Spouštěcí výběry na exekuční vrstvě

EIP-7002 řeší problém principál-agent v delegovaném stakingu – kde stakeři musí důvěřovat operátorům validátorových uzlů, že předem podepíší žádosti o stažení nebo budou respektovat budoucí žádosti o stažení – zavedením nové operace dobrovolného stažení, kterou lze spustit pomocí pověření validátoru pro stažení. To umožňuje sázejícím vybrat vsazené ETH, aniž by se spoléhali na to, že entita držící podpisový klíč validátora (tj. služba sázek v nastavení delegovaných sázek) zpracuje výběry.

Klíčovým rysem EIP-7002 je zavedení smlouvy s žádostí o stažení stavového validátoru, která udržuje frontu žádostí o stažení validátoru pocházejících z prováděcí vrstvy. V určitých intervalech je z fronty odstraněno množství požadavků na výběr a přidáno k požadavku na provedení bloku Beacon Chain. To umožňuje, aby byly požadavky na výběr z prováděcí vrstvy „vloženy“ do konsensuální vrstvy a zpracovány jako součást operací Beacon Chain – podobně jako jsou vklady pocházející z depozitní smlouvy předávány z prováděcí vrstvy do konsenzuální vrstvy ke zpracování.

Žádosti o výběr jsou běžné transakce Ethereum s adresou smlouvy ověřovatele jako cílovou a indikují záměr stáhnout validátor (identifikovaný jeho veřejným klíčem). Zpráva o stažení validátoru je platná, pokud (a) je podepsána adresou Ethereum, na kterou odkazuje pověření pro výběr validátoru na realizační vrstvě ( 0x01 ), (b) validátor, který má být stažen, je aktivní na Beacon Chain. Tyto kontroly jsou prováděny konsensuální vrstvou poté, co se žádost o stažení dostane do Beacon Chain; smlouva s žádostí o výběr validátoru pouze potvrzuje, zda transakce žádosti o výběr zaplatí dostatek plynu v době, kdy stakeholder vyvolá smlouvu s žádostí o výběr.

Všechny žádosti o stažení na prováděcí vrstvě jsou zpracovány stejným způsobem jako běžná operace dobrovolného požadavku na stažení spouštěná z konsensuální vrstvy, která zachovává invarianty kolem maximálních povolených žádostí o stažení z aktivních výběrů validátorů. Mechanismus protokolu EIP-7002 pro přenos žádostí o stažení mezi prováděcí a konsensuální vrstvou také odstraňuje potřebu připojení ke konsenzuálnímu uzlu pro spouštění žádostí o stažení (což je vyžadováno pro stažení validátorů s předem podepsanými žádostmi o stažení). Validátory lze nyní financovat a stahovat ze stejné adresy prováděcí vrstvy, což vysvětluje pojmenování EIP jako „spouštěcí výběry na exekuční vrstvě“.

Když jsme viděli, jak EIP-7002 funguje na vysoké úrovni, můžeme se nyní ponořit do jemnějších detailů EIP. Další část se bude zabývat současnou specifikací EIP-7002 a probere klíčové aspekty mechanismu žádosti o stažení validátoru. Pokud byste raději přeskočili technickou diskuzi a prozkoumali výhody implementace EIP-7002, můžete přeskočit k další části – která zdůrazňuje některá vylepšení vkládání uživatelské zkušenosti (UX), která EIP-7002 umožňuje.

Operace žádosti o stažení validátoru

Podle EIP-7002 je žádost o stažení validátoru (definovaná v pseudokódu jako add_withdrawal_request() ) CALL na adresu smlouvy žádosti validátoru o stažení. Pole transakce pro volání smlouvy s žádostí o stažení validátoru má dvě hodnoty:

• source_address : 20bajtová hodnota představující adresu pro výběr, která iniciovala transakci
• validator_pubkey : 48bajtová hodnota představující veřejný klíč validátoru, který se má opustit

Poté, co staker zavolá smlouvu o žádosti o stažení s validator_pubkey jako vstupem, spustí smlouva o žádosti o stažení validátoru následující operace (klíčové části této operace projdu následně):

• Potvrzuje, že transakce platí dostatek plynu na pokrytí EXIT_FEE
• Zvyšuje výstupní počítadlo ( EXIT_COUNT ) o jednu pro aktuální blok
• Vloží výstupní zprávu do fronty
• Zvyšuje nadměrné výběry pro aktuální blok ( EXCESS_EXITS ) o jednu
• Vrátí volajícímu – pokud přeplatil za plyn – přeposláním stipendia 2300 benzínu ( EXCESS_RETURN_GAS_STIPEND )

Důležitý detail: smlouva o žádosti o stažení validátoru nekontroluje, zda je source_address platnou adresou pro výběr pro validátor identifikovaný validator_pubkey , ani nekontroluje, zda validator_pubkey . To odhaluje jemný bezpečnostní problém, který může nastat, pokud útočník zaplní frontu zprávami, které jsou odsouzeny k selhání; jedná se především o smuteční útok s cílem zabránit zpracování oprávněných žádostí o výběr. EIP-7002 řeší tento problém účtováním dynamicky se upravujícího poplatku za transakce s žádostí o výběr (mechanismus poplatku za výběr je popsán později).

Maximální a cílové výběry na blok

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK je počet požadavků na stažení prováděcí vrstvy, které lze zahrnout do bloku Beacon Chain. Tato hodnota je aktuálně nastavena na 16, aby zrcadlila podobné operace na Beacon Chain, jako je VoluntaryExit (operace ukončení spouštěné přímo z konsensuální vrstvy pomocí validátorového klíče stakera).

Specifikace také poznamenává, že nastavení MAX_WITHDRAWAL_REQUESTS_PER_BLOCK na 16 omezuje velikost užitné zátěže provádění – a tedy i velikost bloků Beacon Chain – a snižuje režii operací ukončení zpracování na vrstvě konsensu. To je užitečné, protože můžeme očekávat, že někteří stakeři budou nadále opouštět validátory pomocí současného mechanismu spouštění odchodů z konsensuální vrstvy (tj. prostřednictvím předem podepsaných odchodů nebo zpráv o dobrovolném odchodu v reálném čase).

TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK

EIP-7002 teoreticky umožňuje zahrnout do bloku až 16 výstupních operací prováděcí vrstvy, ale zaměřuje se na konzervativnější odhad dvou výstupů na blok. Podle specifikace byl TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK nastaven na 2, aby omezil rychlost odchodu validátorů a zachoval invariant na maximálních povolených výběrech za epochu definovanou funkcí get_validator_churn_limit() Beacon Chain – dokonce i v situacích, kdy je veškeré ETH v oběhu stakováno.

Fronta žádostí o stažení validátoru

WITHDRAWAL_REQUEST_COUNT

WITHDRAWAL_REQUEST_COUNT je počet žádostí o výběr zahrnutých v aktuálním bloku. Po každém úspěšném volání smlouvy s žádostí o stažení validátoru se hodnota proměnné WITHDRAWAL_REQUEST_COUNT uložené v úložišti kontraktu validátoru zvýší o jednu (definovaná v pseudokódu jako increment_count() ).

Hodnota WITHDRAWAL_REQUEST_COUNT bude v kterémkoli okamžiku ležet mezi TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK (2) a MAX_WITHDRAWAL_REQUESTS_PER_BLOCK (16) v závislosti na tom, kolik operací s žádostí o výběr bude přidáno k užitečné zátěži provádění bloku. WITHDRAWAL_REQUEST_COUNT je také vstupem do funkce, která vypočítá částku, která má být zaplacena novou operací žádosti o výběr ( MIN_WITHDRAWAL_REQUEST_FEE ).

NADMĚRNÉ ŽÁDOSTI O STAŽENÍ

EXCESS_WITHDRAWAL_REQUESTS je rozdíl mezi MAX_WITHDRAWAL_REQUESTS_PER_BLOCK a TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK – počet žádostí o výběr, které aktuální blok nevyužije. Jak již bylo zmíněno, každý blok může obsahovat maximálně 16 žádostí o výběr, ale v normálních situacích cílí na dvě žádosti o výběr, takže EXCESS_WITHDRAWAL_REQUESTS je ekvivalentní „rozdílu mezi tím, kolik požadavků na výběr může blok teoreticky spotřebovat a kolik žádostí o výběr skutečně využívá“.

Počítadlo překročení smlouvy s žádostí o výběr se aktualizuje na základě použití posledního bloku a je jedním z faktorů (mimo jiné), který určuje poplatek zaplacený transakcí, která nazývá smlouvu žádosti o výběr validátoru. To zajišťuje, že poplatky za výběr jsou stanoveny podle aktuálního využití, což je podobné jako u EIP-1559, kdy se base_fee pro nový blok vypočítává na základě rozdílu mezi cílovým limitem plynu a plynem použitým předchozím blokem.

WITHDRAWAL_REQUEST_QUEUE

WITHDRAWAL_REQUEST_QUEUE je seznam všech nevyřízených žádostí o výběr (uspořádaných v pořadí příchodu) aktuálně uložených v WITHDRAWAL_REQUEST_QUEUE_STORAGE_SLOT smlouvy s validátorem (jako WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT ). Počet žádostí o výběr ve frontě může být neomezený, ale variabilní sazba MAX_WITHDRAWAL_REQUESTS_PER_BLOCK omezuje, kolik nevyřízených žádostí o výběr lze vyřadit z fronty do každého bloku.

Fronta žádostí o výběr udržuje index „head“ a „tail“ – oba jednoduše odkazují na sadu požadavků blízko začátku a konce fronty – který se aktualizuje po každém bloku, aby zohlednil zpracování jednoho nebo požadavků na výběr. Jedná se o frontu „first-in-first-out“ (FIFO), takže požadavky jsou prováděny podle toho, kdy jsou přidány do fronty – což má bezpečnostní důsledky, zejména pokud jde o smutek poctivých validátorů.

Poplatky za odstoupení od smlouvy validátorem

MIN_WITHDRAWAL_REQUEST_FEE je částka, kterou musí validátor zaplatit v plynu na adresu, na které je požadována smlouva s žádostí o výběr validátoru. Před vložením požadavku na výběr do fronty smlouva s žádostí o výběr validátoru zkontroluje, zda se poplatek za plyn spojený s transakcí rovná nebo překračuje aktuální hodnotu MIN_WITHDRAWAL_REQUEST_FEE - pokud po úspěšném provedení transakce zbývá plyn, na odesílací adresu je připsáno přesně 2300 plyn.

Podle specifikace tento návrh navazuje na nyní již zastaralou funkci v Solidity, kde vyvolání funkce fallback() v cílové smlouvě nebo odeslání ETH přes transfer() nebo send() přepošle příjemci stipendium ve výši 2300 plynu. Změny v nákladech na plyn (počínaje vidlicí Berlín/Istanbul) snížily užitečnost této funkce (pro určitý kontext si přečtěte Přestaňte používat převod Solidity() Now ), ale původní myšlenka jednoduchého systému účtování plynu je stále užitečná. V kontextu EIP-7002 zaslání pevné náhrady ve výši 2 300 plynu zjednodušuje mechanismus poplatků za smlouvu s žádostí o stažení validátoru.

Alternativou je navržení speciálního mechanismu, který umožní, aby smlouva s žádostí o výběr vrátila maximální množství plynu zbylého z transakce. To by dávalo smysl, zejména v případech, kdy je adresa pro výběr EOA-inteligentní smlouvy mohou vypočítat přesné hodnoty pro MIN_WITHDRAWAL_REQUEST_FEE kontrolou stavu smlouvy, ale EOA pravděpodobně pošlou více plynu na každé volání smlouvy o žádosti o výběr. Tato cesta zvyšuje složitost návrhu EIP-7002 oproti použití jednoduchého CALL k předání fixního množství plynu jako náhrady; ačkoli autoři EIP-7002 navrhují, aby tato funkce mohla být zahrnuta do konečné specifikace v závislosti na zpětné vazbě od zúčastněných stran.

Ve výpočtu MIN_WITHDRAWAL_REQUEST_FEE jsou věci zajímavé. Poplatek za žádost o výběr je dynamický a navržený tak, aby odpovídal podmínkám sítě, podobně jako základní poplatek zavedený EIP-1559, a je funkcí tří proměnných:

• Minimální (základní) poplatek za výběr: MIN_WITHDRAWAL_REQUEST_FEE
• Počet přebytečných výběrů v aktuálním bloku: EXCESS_WITHDRAWAL_REQUESTS
• Vzorec pro aktualizaci poplatku za žádost o výběr: WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION

Stejně jako base_fee u EIP-1559 je výstupní poplatek ze smlouvy o odstoupení validátoru mechanismem omezujícím sazbu: v průměrném případě (dvě žádosti na blok) může kdokoli, kdo zavolá smlouvu s žádostí o stažení validátoru, očekávat, že zaplatí minimální poplatek za stažení, ale náklady na operace výběru postupně zvětšuje další požadavky na výběr jsou zahrnuty do bloku. To lze odvodit z formální specifikace EIP-7002 pro aktualizaci poplatku za žádost o výběr : withdrawal_request_fee = MIN_WITHDRAWAL_REQUEST_FEE * e**(excess_withdrawal_requests / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) .

Vysvětlení mechanismu poplatku za žádost o výběr ze specifikace:

„Chování po jednotlivých blocích je zhruba následující: Pokud blok N zpracovává X žádostí o výběr, pak se na konci bloku N excess_withdrawal_requests zvýší o X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK , a tak se poplatek za žádost o výběr v bloku N + 1 zvýší faktorem e**((X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK) / (WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) Má tedy podobný účinek jako stávající EIP-1559, ale je „stabilnější“ v tom smyslu, že reaguje stejným způsobem na stejné celkové požadavky na výběr bez ohledu na to, jak jsou distribuovány v průběhu času.

Postupným zvyšováním poplatku za žádost o výběr podle použití smlouvy s žádostí o stažení validátoru EIP-7002 snižuje riziko, že útočník záměrně zaplní frontu žádostí o výběr, aby zabránil ostatním validátorům ve výběrech. Zprávy o odvolání ve frontě žádostí o stažení jsou vyřazeny z fronty a ve stylu FiFo (první do skladu), na rozdíl od, řekněme, posledního pořadí (LiFo) nebo nejlépe platících transakcí jako první. I když můžeme předpokládat, že ceny plynu zabrání zbytečným voláním do smlouvy s žádostí o výběr, může být zlomyslný útočník ochoten zaplatit více plynu, aby „nacpal“ frontu žádostí o výběr a posunul žádost jiného validátora o výběr na konec fronty.

Problém je dále umocněn centralizací tvorby bloků v post-Merge Ethereum. Pokud je útočník integrován s jedním nebo více dominantními staviteli (pro kontext: 80–90 % bloků k dnešnímu dni na Ethereu vyrobilo 4–5 stavitelů ) a je ochoten zaplatit za zahrnutí v horní části bloku, může účinně předběhnout žádosti o výběr od jednoho nebo více stakerů a zabránit včasným výběrům validátorů z Beacon Chain.

A proč by někdo podstupoval všechen ten stres? Možnou motivací může být to, že útočník chce zarmoutit stakeholdery, které si přejí odvolat validátory pomocí přihlašovacích údajů pro výběr. Chcete-li použít předchozího operátora Boba (škodlivého) uzlu a Alice vysazovatele: Alice může rychle stáhnout svůj validátor, aby zastavila Bobův truchlící útok tím, že zavolá validátorovi žádost o stažení smlouvy s přihlašovacími údaji o stažení – ale Bob se stále může dát víc, aby prozradil Alice. zůstatek validátoru spamováním smlouvy s žádostí o výběr validátoru a odložením žádosti Alice o výběr.

Bloková struktura a platnost

EIP-7002 mírně mění strukturu a ověřování Beacon bloků tím, že vyžaduje, aby požadavky na stažení byly umístěny do skutečného těla bloku (a užitečného zatížení provádění v konsensuální vrstvě). Požadavky musí být vložené do prováděcího užitečného zatížení tak, že kdykoli je konsensuální vrstva nedosažitelná, konsenzuální vrstva má stále potřebná data k úplnému provedení konsenzuální části funkce stavového přechodu.

EIP-7002 také přidává nové podmínky platnosti pro bloky. Za prvé, seznam žádostí o výběr ( withdrawal_requests_list ) nesmí překročit MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . Za druhé, seznam žádostí o výběr musí odpovídat počtu žádostí o výběr vyřazených z fronty WITHDRAWAL_REQUEST_QUEUE , když jsou takové požadavky uspořádány v pořadí první na první-první-out (FiFO).

EIP-7002 má funkci ( expected_exit ) pro potvrzení, že blok nezahrnuje více požadavků na výběr, než je výsledek výpočtu NUM_WITHDRAWAL_REQUESTS_IN_QUEUE - MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . Konsenzuální uzel znovu provádějící blok také nezávisle vypočítá kódování žádostí o stažení pomocí iterace request_type a request_data ve srovnání se závazkem hash seznamu žádostí o stažení.

Proč EIP-7002? Případ pro výběry spustitelné na úrovni provedení

Snížené předpoklady důvěry v delegované sázky

V úvodu jsem si všiml, jak spoléhání se na podpisový klíč validátoru při inicializaci ukončení validátoru přineslo problém důvěry; Nezahrnul jsem definici důvěry, ale tato definice z článku Vitalik's Trust Models to pěkně shrnuje: „Důvěra je jakýkoli předpoklad(y), který uděláte o chování jiných lidí“. Tím, že se přihlásíte ke službě sázky, protože ví, že provozovatel uzlu může zmrazit výběry, sázkař v podstatě důvěřuje provozovateli uzlu, že bude jednat věrně.

EIP-7002 zcela neodstraňuje prvek důvěry v delegovaném skládání – stále musíte důvěřovat operátorovi uzlu, že neprovede žalový útok – ale umožnění stakerů stáhnout se s odvoláním pověření do určité míry snižuje zátěž důvěry. Uživatel například nemusí „mít víru“, že operátor uzlu podepíše dobrovolnou výstupní zprávu, jakmile o to požádá.

Jemným bodem „nedůvěryhodnosti“ je, že nejde nutně o vyhýbání se potřebě důvěřovat, ale o nepotřebě důvěřovat, protože (a) existují silné pobídky pro všechny strany, aby jednaly čestně (b) čestné strany mají určité množství ochranu před jednáním nepoctivých stran. Schopnost stáhnout validátor s přihlašovacími údaji je příkladem toho druhého: Bob se může pokusit zarmoutit Alici, ale Alice má nyní agenturu, aby její validátor stáhla, doufejme, že dříve, než Bob způsobí další škody.

Lepší řízení rizik pro sázkové pooly

V současné době nemají fondy sázek žádný způsob, jak donutit operátora validačního uzlu, aby se stáhl – což staví přispěvatele fondu do nepříjemné pozice důvěřujících operátorů uzlů, aby jednali čestně. Některé decentralizované sázkové fondy vyžadují, aby provozovatelé uzlů poskytli dluhopis, ale vzhledem k možnosti, že se zlomyslný operátor dostane na 0 ETH, může být zabezpečení z dluhopisu nedostatečné v očích sázkaře averzního k riziku.

Se zavedeným EIP-7002 mohou sázkové fondy výrazně snížit předpoklady důvěry tím, že doplní zabezpečení před hrozbou podříznutí kolaterálu operátora uzlu postupy pro násilné stažení neslušného operátora prostřednictvím stažení prováděcí vrstvy. Možnost odstoupení od smlouvy směřující na adresu chytré smlouvy (místo EOA) také otevírá nové návrhy odezvy na incidenty pro sázkové fondy – například inteligentní smlouva by mohla automaticky odeslat žádost o odstoupení, pokud operátor utrpí vyšší než průměrné sankce v rámci časové okno. To však vyžaduje důvěřovat orákulu, aby mohl sledovat výkon validátoru, a síti správců, která spustí inteligentní smlouvu.

Další hypotetickou výhodou pro stakeholder vyplývající z implementace EIP-7002 je eliminace potřeby vyžadovat a ukládat předem podepsané zprávy o odstoupení od smlouvy, což s sebou nese rizika, jak jsem vysvětlil dříve (např. neoprávněný přístup ke zprávám o odstoupení od smlouvy by mohl vést k neočekávanému validátoru výběry). To také přispívá k cíli navrhování důvěryhodných sázkových fondů: na rozdíl od spoléhání se na předem podepsané žádosti o výběr uložené několika (důvěryhodnými) jednotlivci, inteligentní smlouva označená jako adresa pro výběr by mohla být řízena řízením, které by komunitě umožnilo rozhodnout veřejně a transparentně stáhnout provozovatele uzlu.

Lepší řízení rizik pro nastavení DVT

Technologie distribuovaného validátoru (DVT) je považována za kritickou součást infrastruktury sázek Etherea z mnoha důvodů:

• DVT snižuje překážky pro sólo sázky: Více sólo sázkařů může shromáždit finanční prostředky, aby společně aktivovali validátor, aniž by museli věřit každé druhé straně. Schémata vícestranného výpočtu (MPC) mohou tolerovat až ⅓ chybných uzlů – takže pokud hypotetický distribuovaný validátor vyžaduje 3 z 5 sdílených klíčů k rekonstrukci podpisového klíče validátoru, k podepsání může dojít, pokud jsou dva uzly DVT offline.
• DVT zlepšuje odolnost proti chybám a odolnost pro institucionální/sólo nastavení vytyčování: Jak bylo zmíněno výše, podpisový klíč validátoru lze rozdělit do různých sdílených klíčů a rekonstruovat pouze v případě, že je vyžadováno podepisování blokových dat. Sníží se tak riziko, že hacker ohrozí podpisový klíč validátoru nebo že stakeholder ztratí přístup k finančním prostředkům, protože zařízení ukládající podpisový klíč utrpělo poškození.

Nastavení DVT však stále přináší určité riziko pro stakery kvůli tomu, jak výběry a výstupy v současné době fungují na Beacon Chain. Pokud některé uzly DVT zamění sdílené klíče nebo se odmítnou účastnit schématu podepisování prahových hodnot, opuštění validátoru se stane nemožným – zvláště když:

• Sdílené klíče pro každého účastníka nastavení DVT jsou generovány v době aktivace validátoru a nelze je „obnovit“ po úvodní ceremonii DKG (všimněte si, že „účastníkem“ může být jednoduše jiný EOA vlastněný stejným stakerem); některé protokoly DVT umožňují generování nových sdílených klíčů, ačkoli to může vyžadovat, aby zbývající sdílené klíče splňovaly kvorum podpisů vyžadované pro pravidelné podepisování.
• Práh kvora – počet sdílených klíčů potřebných ke společnému vygenerování platného podpisu pro distribuovaný validátor – nelze změnit, jakmile je (distribuovaný) validátor aktivní.

Bez toho, aby EIP-7002 poskytoval možnost vyjmout validátor pomocí vyjímacího klíče, by byla výhoda spuštění nastavení DVT – nezávisle nebo ve shodě s jinými validátory – značně omezena (např. zůstatek validátoru by mohl být navždy uzamčen). EIP-7002 poskytuje záložní bezpečnostní možnost pro distribuované validátory: pokud není rekonstruování podpisového klíče proveditelné, validátor lze stáhnout z řetězce Beacon odesláním žádosti o stažení podepsané pomocí rekonstruovaného klíče pro odebrání ze sdílených klíčů.

Lepší dodržování předpisů: Zařazení „nevazebních“ do nevazebních sázek

Je nepravděpodobné, že si autoři EIP-7002 výslovně stanovili cíl usnadnit provozování regulované institucionální společnosti poskytující sázky jako služby. I tak ale EIP pomáhá s problémem přesvědčování regulátorů o tom, že instituce nespravuje vsazené ETH. Operátor sázky by v tomto scénáři mohl jednoduše předložit hash vkladové transakce podepsaný sázecím klíčem pro výběr – který nyní může podepsat a odeslat dobrovolné odchody – jako důkaz, že prostředky uložené ve validátoru nejsou nikdy v žádném okamžiku v jeho úschově.

Zdůraznil jsem „jakýkoli okamžik“, protože před EIP 7044 operátor uzlu dočasně přebírá kontrolu nad zůstatkem validátoru poté, co vyprší předem podepsaný výstup. A dokonce i s trvale platnými podepsanými výstupy EIP-7044 mají operátoři uzlů stále v úschově 32 ETH uložených pro validátor na krátkou dobu mezi aktivací validátoru a vytyčovačem, který obdrží podepsanou výstupní zprávu od operátora vytyčovací služby. EIP-7002 odstraňuje tyto nepohodlné oblasti a zajišťuje, že stakeři mají (prokazatelnou) úschovu finančních prostředků po celou dobu životního cyklu validátoru – od vstupu do Beacon Chain až po výběr a odeslání finančních prostředků na adresu stakera pro výběr.

Lepší sázková uživatelská zkušenost (UX) pro všechny

Dobrým mentálním modelem pro EIP-7002 je uvažovat o něm jako o „ abstrakce účtů pro infrastrukturu sázek“. Pro kontext, validátorový klíč (nebo podpisový klíč) je vždy EOA a přichází se stejnou sadou omezení týkajících se bezpečnosti a použití soukromého klíče, které dnes ovlivňují běžné Ethereum EOA:

• Ověřovací (podepisovací) klíče jsou vystaveny vyššímu riziku kompromitace. Na rozdíl od výběrových klíčů uložených v chladném (offline) úložišti jsou validační klíče uloženy v hot peněženkách připojených k internetu, díky čemuž jsou náchylné k phishingovým útokům. Pokud dojde ke kompromitaci podpisového klíče validátoru, stakeři a delegovaní poskytovatelé vytyčování jsou náchylní k vektorům smutku popsaným v úvodu bez jakéhokoli záložního plánu – kromě „počkejte, dokud zůstatek neklesne na 16 ETH a validátor bude protokolem násilně stažen“.
• Validátorové klíče mají omezené možnosti pro schémata obnovy (ztratit je jednou = ztratit navždy). Rozdělení validátorového klíče do více sdílených klíčů pomocí distribuované validátorové technologie (DVT) může toto riziko zmírnit, ale spuštění sólo nastavení vytyčování DVT není triviální; plus, jak jsem vysvětlil dříve, DVT není stříbrná kulka, protože klíče se mohou ztratit a zkomplikovat obnovení klíčů.
• Validátorové klíče nemohou podporovat flexibilnější návrhy vytyčování. Různé stakingové služby vyvinuly automatizované/flexibilní pracovní postupy pro validátory financování díky výhodě nasměrování přihlašovacích údajů pro výběr na chytré smlouvy. Stažení validátoru je však manuální proces, který vyžaduje podepsání zprávy s dobrovolným požadavkem na výběr – tento proces by mohl být automatizován inteligentní smlouvou, která uchovává žádosti o stažení před podpisem, ale to přichází s určitými předpoklady důvěry a bezpečnostními aspekty vysvětlenými výše.

Většinu – nebo alespoň některé – z těchto problémů můžeme vyřešit, jakmile budou klíče pro výběr schopny opustit validátory. Aby to fungovalo, bude staker (nebo fond sázek) muset dokončit jednorázovou změnu z pověření pro výběr 0x0 na pověření pro výběr 0x01 – zatímco pověření 0x0 jsou ve výchozím nastavení klíčem BLS (EOA), pověření 0x01 mohou odkazovat na jakékoli Ethereum. adresu, včetně inteligentních smluv a EOA. Nastavení chytré smlouvy jako adresy pro odstoupení od smlouvy pro validátor je skvělé pro zlepšení uživatelské zkušenosti (UX) sázek:

1. Klíče pro výběr mohou mít flexibilní mechanismy obnovy, jako je sociální obnova. Staker by měl jednoho nebo více „strážců“, kteří mohou autorizovat nový klíč ke kontrole smart kontraktu s žádostí o výběr, pokud by byl původní klíč odcizen nebo ztracen – opatrovníky mohou být přátelé, příbuzní, kolegové stakeři nebo specializovaná služba třetí strany. Flexibilita mechanismů vymáhání může prospět zejména sólo sázejícím; můžete mít přepínač mrtvého muže , který aktivuje východ z EL a pošle prostředky na určenou adresu, pokud váš validátor přestane atestovat na předem stanovenou dobu (např. protože jste „přešli do Velkého světa“).

2. Mohou se objevit flexibilní návrhy vytyčování. Například staker, který odmítá riziko, může upřednostňovat smlouvu o výběru 2 ze 2 s více značkami – s jedním ze dvou klíčů potřebných ke schválení žádostí o výběr – s jedním ze dvou klíčů potřebných ke schválení žádostí o výběr – se stakerem a operátorem uzlu – namísto uložení celého klíče pro výběr. Je to stále nevěrné (operátor uzlu nemůže opustit validátor bez schválení), i když vyžaduje důvěřovat operátorovi uzlu, že neblokuje výstup validátoru tím, že odmítne podepsat transakce žádosti o stažení navržené stakeholderem.

V případě sázkových fondů by flexibilita v návrzích sázek mohla znamenat implementaci smluv o odstoupení s libovolnou logikou aktualizace nebo převodu vlastnictví validátorů. Při absenci EIP-7002 je jediným skutečným způsobem, jak může stakeholder spravovat vlastnictví validátorů, přesouvat předem podepsané žádosti o výběr, což s sebou nese různá rizika a okrajové případy.

3. Výběry validátorů lze bezpečně automatizovat. Na rozdíl od ukládání předem podepsaných žádostí o výběr v chytré smlouvě mohou mít smlouvy s žádostí o výběr složitá pravidla upravující žádosti o výběr pomocí validátoru; Myšlenka „šílené vědy“ je „časově založená skupina sázek“, kde se operátoři uzlů nedůvěřivě střídají. Nebo zvažte, zda se velký sázkový fond, jako je Lido, chce decentralizovat: správa se může rozhodnout stáhnout některé validátory ovládané velkým operátorem uzlů a přerozdělit prostředky menším operátorům (nebo samostatným sázkařům), aby se snížily škrtící body od operátora uzlů ovládajícího značný počet validátory.

Toto jsou jen některé z prvních možností, které EIP-7002 umožňuje, ale jsem si velmi jistý, že se objeví další aplikace – stejně jako nové funkce a případy použití pro chytré peněženky na Ethereu. Pokud toto čtete a máte konkrétnější nápady pro aplikaci EIP-7002 na návrhy vytyčování, neváhejte se ozvat v komentářích!

Má implementace EIP-7002 nějaké nevýhody?

Potenciální změny stávajících návrhů vytyčování

V návrhu EIP autoři EIP-7002 uznávají potenciální obavy týkající se umožnění stažení přihlašovacích údajů spouštět výběry validátorů – ale dále říkají: „neznáme žádné návrhy sázek, které by na tuto funkci závisely [tj. nemožnost stažení s přihlašovacími údaji pro výběr]“. To se zdá rozumné – dokonce i já jsem měl určité potíže s uvažováním o jakémkoli delegovaném vytyčovacím uspořádání, které by tuto funkci vyžadovalo. Ale to, že se to nezdá samozřejmé, neznamená, že to tam není.

"Poslouchejte ty tiché, dotěrné pochybnosti." Pokud nevíte, nevíte, co nevíte, nevíte, kolik toho nevíte, a nevíte, kolik toho potřebujete vědět.“ — Eliezer Yudkowsky

Abych uvedl nějaký kontext, zahrnu snímky obrazovky konverzace kolem raného návrhu na implementaci odchodů schválených odebráním pověření prostřednictvím Generalized Message Bus (GMB) . GMB je inteligentní smlouva na systémové úrovni, jejíž události jsou čteny a zpracovávány klienty, jako je aktuální smlouva o vkladu, a je schopna předávat zprávy z prováděcí vrstvy do konsensuální vrstvy. Zatímco autor (autoři) naznačili obecnější typy zpráv EL-to-CL, hlavním navrhovaným případem použití sběrnice zpráv EL-CL bylo poskytnutí způsobu, jak spustit výstupy z prováděcí vrstvy pomocí přihlašovacích údajů 0x01.

Z této výměny již máme příklad vztahu operátor-uzel sázkař postavený na předpokladu, že sázkař nemůže opustit a stáhnout validátor pomocí klíče pro výběr. Další příklad potenciálního okrajového případu implementace EIP-7002 pochází z rozhovoru o plánech decentralizace společnosti Lido v podcastu Lido Community Staking, který můžete sledovat na YouTube . (EIP-7002 je ve videu zmíněn pouze krátce (28:55 až 30:00)).

Pro pozadí, Lido bylo popsáno jako „systematická hrozba pro Ethereum“, protože kontroluje ~ 33,3 % validátorů Beacon Chain a mohlo by ohrozit konsenzus Etherea; pokud například Lido DAO donutilo operátory uzlů cenzurovat transakce nebo vrátit dříve dokončené bloky (vektor Mike Neudera Magnitude a směr vektorů útoku Lido popisuje hrozbu podrobněji).

Jeden z řečníků v dříve propojené epizodě však uvádí přesvědčivý argument, že tento vektor útoku – DAO násilně kooptující operátory uzlů do útoku na protokol Ethereum – zatím neexistuje, protože operátoři uzlů mají nějakou agenturu. DAO může zadržet sázku ověřovatele poté, co odejde, ale nemůže se spoléhat na hrozbu nuceného odchodu, aby donutila ověřovatele k útoku na konsenzus Etherea.

S EIP-7002 se dynamika výkonu výrazně mění: smlouvy o odstoupení řízené DAO mohou stáhnout operátora proti jeho vůli, což dává DAO vliv na operátory uzlů. Tento typ pákového efektu je užitečný pro ochranu vytyčovacího protokolu proti sadě škodlivého operátora, jak jsem vysvětlil dříve. Ale může být také zneužit v následujících scénářích:

• Sázkový protokol utrpí útok na vládnutí a DAO projde zlomyslným návrhem na vyvolání odstoupení validátora od smlouvy o odstoupení
• Útočník převezme kontrolu nad jedním nebo více validátory tím, že unese vlastnictví smlouvy s žádostí o stažení a provede úspěšnou strategii vydírání

Toto je další příklad toho, jak by EIP-7002 mohl změnit stávající předpoklady v návrzích vytyčování – tentokrát pro operátory uzlů ověřující jménem skupiny vytyčování, jako je Lido. Tento vektor útoku však lze snadno zmírnit pomocí různých metod, jako je použití zabezpečených, přísně kontrolovaných a případně neupgradovatelných smluv s žádostí o stažení nebo dodržování osvědčených postupů pro bezpečné řízení DAO .

Abychom zohlednili okrajový případ, kdy operátor uzlu utrpí ztráty z nuceného stažení poté, co odmítl útočníkovy požadavky na porušení pravidel protokolu, mohou se sázkové fondy inspirovat realitními společnostmi, aby ochránily operátory uzlů:

• Před podpisem nájemní smlouvy jsou nájemci povinni složit „kauci“. Vklad je veden na bankovním účtu mimo kontrolu realitní společnosti.
• Pokud se nájemce z bytu odstěhuje, ale zanechá po sobě značné škody, je realitní společnost oprávněna použít kauci na úhradu nákladů na opravy.
• Pokud je byt v době odchodu nájemce v dobrém stavu, kauce se vrací v plné výši nájemci.

Stakingový protokol může přijmout podobný přístup k ochraně operátorů uzlů uzavřením politiky „pojištění provozovatele uzlů“ prostřednictvím Nexus Mutual , Tidal Finance nebo jakékoli jiné krypto-nativní pojistné platformy. Pokud je validátor operátora odebrán oprávněně, je pojistný fond vrácen DAO; je-li opak pravdou (např. odstoupení validátoru je vyvoláno chybou s návrhem nebo odstoupením od smlouvy), pojišťovna vyplácí škodu provozovateli uzlu. Všimněte si, že tento přístup lze zobecnit na jakékoli existující vztahy, které se opírají o aktuální specifikace pro ukončení validátoru.

Nedostatek podpory pro složitější zprávy EL-to-CL

Smlouva o žádosti o stažení validátoru EIP-7002 poskytuje jedinou funkci: odeslání žádosti o stažení z prováděcí vrstvy Etherea do konsensuální vrstvy za účelem stažení validátoru. Někteří však navrhli implementaci obecného rámce pro zasílání zpráv (např. předkompilace SendMessageToConsensusLayer nebo výše zmíněná smlouva na systémové úrovni Generalized Message Bus (GMB)) pro předávání obecných typů zpráv mezi prováděcí vrstvou a vrstvou konsensu. To by mohlo mít výhody, jako je odemknutí nových způsobů aktivace validátorů na Beacon Chain, zvláště pokud je povoleno připojení ETH ke zprávám EL-to-CL.

Nicméně, jak vysvětluje Danny Ryan (jeden z autorů EIP-7002) v komentáři , trávit cenný čas inženýrů na obecném rámci pro zasílání zpráv EL → CL je „velký podnik s nejasnou nabídkou hodnoty“. Pro ilustraci, autoři návrhu GMB (General Message Bus) identifikovali pouze jeden další případ použití pro sběrnici zpráv mezi EL a CL: rotace pověření pro stažení pro validátor z 0x0 na 0x01 pověření.

To znamená, že je pravděpodobnější, že validátor odvolá smlouvu s žádostí jako první, než budou hlavní vývojáři mluvit o implementaci obecné sběrnice zpráv EL-CL, pokud k tomu někdy dojde. Ne, že by bylo jednoduché udržovat věci někdy na škodu.

Jednoduchost je předpokladem spolehlivosti. — Edsger W. Dijkstra

Novější rizikové vektory pro stávající stakery

Vysvětlil jsem výhody povolení výběru přihlašovacích údajů ke spuštění výběru z větší části, ale s touto funkcí jsou spojeny některé okrajové případy. Myšlenka vypadá takto (h/t k tomuto komentáři na GitHubu ):

• Pokud dojde ke kompromitaci podpisového klíče ověřovatele, může hacker požadovat výkupné nebo se pokusit snížit zůstatek ověřovatele – ale v žádném případě nemůže vybrat prostředky. Bude následovat čekací hra: Zničí útočník celý zůstatek, nebo bude staker moci stáhnout část sázky, jakmile bude validátor násilně stažen?
• Jakmile je však implementován EIP-7002, hacker v předchozím scénáři může přistoupit k ukončení validátoru a vybrat zůstatek (po implementaci EIP-7002) místo toho, aby se spokojil s útokem smutku/vydírání.

Stručně řečeno, sólo sázkaři a sázkové služby budou po EIP 7002 potřebovat větší ochranu pro výběr pověření. To je důvod, proč je přijetí sociální obnovy, vícefaktorové (MFA) autentizace a střídání klíčů považováno za zásadní pro zlepšení bezpečnosti pro sólo/delegované sázkové operace.

Volba mechanismu omezení rychlosti

Funkce add_withdrawal_request() s žádostí o stažení smlouvy validátoru neprovádí žádné další kontroly, kromě kontroly připojeného poplatku za žádost o stažení, což útočníkovi potenciálně umožňuje ucpat frontu zpráv neplatnými požadavky na stažení (např. výstupní zprávy pro neexistující validátor nebo neaktivní validátor bude zneplatněn během kontrol platnosti konsensuální vrstvy). EIP-7002 používá dynamicky určovaný poplatek za výběr, aby omezil požadavky na výběr a zdražil takové útoky, podobně jako EIP-1559 odrazuje od spamových útoků a blokového naplňování úpravou cen plynu na základě síťové aktivity.

Alternativním návrhem je omezit volání smlouvy s žádostí o stažení validátoru na skutečné validátory – například kontrolou, že validator_pubkey odpovídá veřejnému klíči aktivního validátoru Beacon Chain. To by mohlo zjednodušit návrh EIP-7002 odstraněním potřeby složitého cenového mechanismu ve stylu EIP-1559 a potenciálně snížit poplatek za žádost o výběr, protože spamování fronty falešnými požadavky může být menší problém.

To však vyžaduje, aby prováděcí vrstva mohla bez důvěry přistupovat k informacím o konsensuální vrstvě – pro kontrolu validator_pubkey proti registru validátorů Beacon Chain – což je funkce, která závisí na implementaci EIP-4788. To zvyšuje složitost EIP-7002 a zavádí novou závislost mezi dvěma EIP, což může mít důsledky pro budoucí vylepšení návrhu, jak je uvedeno v této části zdůvodnění EIP-7002 .

I kdyby byl EIP-4788 integrován s EIP-7002, stále bychom potřebovali další mechanismy, abychom zabránili jiným formám spamu, které zahrnují legitimní validátory; příkladem je odeslání více žádostí o výběr pro stejný validátor ve velmi krátké době. To zase vyžaduje přidání (a vynucení) nového pravidla jako „můžete podat pouze jednu žádost o výběr na validátor každé 3-4 měsíce“, což může vyžadovat ještě více změn ve smlouvě o žádosti o stažení validátoru.

Naproti tomu současný mechanismus omezování rychlosti je jednoduchý na zdůvodnění a zaručuje dostatečnou ochranu proti většině bezpečnostních problémů souvisejících se stahováním z realizační vrstvy. Poplatek za žádost o výběr se například může automaticky upravit směrem nahoru, aby odradil truchlení (pokoušející se zabránit čestným validátorům ve stažení) a spamování a útoky DOS (pokoušející se přetížit Beacon Chain tím, že nutí uzly konsensu plýtvat zdroji na filtrování neplatných operací výběru).

Závěr: EIP-7002 a budoucnost sázek na Ethereum

Delegované vytyčování se v posledních měsících dočkalo značné kritiky, ale lze s jistotou předpokládat, že odvětví vytyčování jako služby zde zůstane. Pokud ano, je důležité snížit riziko pro jednotlivce, kteří delegují sázku – ať už do poolu likvidních sázek nebo institucionální nevěrné sázkové služby. EIP-7002 dosahuje tohoto cíle tím, že umožňuje výběrovým údajům 0x01 opustit validátory a stáhnout sázku a snižuje potřebu stakerů důvěřovat poctivosti operátora uzlu.

EIP-7002 má také další pozitivní vedlejší účinky. Zejména zlepšení odolnosti a bezpečnosti operací sólo vytyčování a distribuovaných validátorů – tím, že umožní lepší zotavení ze ztráty klíče validátoru nebo sdílených klíčů DVT – by mělo snížit překážku pro sólo vytyčování a snížit centralizaci sázek na Ethereum.

Jako obvykle zakončím tím, že vás požádám, abyste zvážili sdílení tohoto článku s někým, kdo jej může považovat za informativní, a co je důležitější, přihlaste se k odběru Etherea 2077, abyste se mohli podrobněji ponořit do všech věcí výzkumu a vývoje Etherea. Můžete se se mnou také spojit na Twitteru a sdílet komentáře nebo zpětnou vazbu k tomuto článku.