EIP-7002: Ett bättre sätt att satsa på Ethereum

Ethereums övergång från Proof of Work (Pow) till Proof of Stake (PoS), aka, The Merge, var ett nyckelögonblick i nätverkets historia. Förutom att ge Ethereum ett välbehövligt varumärke genom att minska dess koldioxidavtryck, var Proof of Stake avgörande för ett viktigt långsiktigt mål: att minska hindret för att delta i Ethereums konsensus. Sammanslagningen ersatte beräkningsresurser (gruvkraft) med finansiellt kapital som grunden för Ethereums ekonomiska säkerhet – vilket öppnade upp möjligheten för vem som helst att lönsamt och enkelt driva en valideringsnod genom att satsa 32 ETH på Beacon Chain.

Även om Proof of Stake har medfört fördelar finns det fortfarande många förbättringsområden. Några av dessa inkluderar:

• Minska centralisering av insatser och kartellisering av validatorer
• Minimera operativa omkostnader för validerare och incitament för solosatsning
• Förbättra insatsekonomi och användarupplevelse (UX)
• Förbättra enkelhet, säkerhet och decentralisering av delegerade och flerpartssatsningar

EIP-7002: Execution Layer Triggerable Withdrawals är ett nytt Ethereum Improvement Proposal (EIP) som fixar några av de tidigare nämnda problemen. EIP introducerar en mekanism för aktörer att ta ut validerare från Beacon Chain med hjälp av uttagsreferenser istället för att förlita sig på en validators signeringsnyckel för att utlösa uttagsåtgärder – vilket effektivt kopplar bort en validators signeringsnyckel från uttagsnyckeln.

Denna "separation av bekymmer" mellan validatorsigneringsnycklar och uttagsnycklar har en avgörande fördel: att minska förtroendeantaganden i delegerad insats genom att möjliggöra uttagsreferenser för att behålla kontrollen över insatt ETH. Jag ska undersöka varför den här funktionen är nödvändig under loppet av den här artikeln och diskutera andra fördelar med EIP-7002, särskilt för solo- och DVT (distributed validator technology). Artikeln kommer också att överväga några potentiella nackdelar med att implementera EIP-7002 på Ethereum.

Låt oss dyka in!

Sätter scenen: En berättelse om nycklar, vita handskar och sorg

Om du vill satsa ETH och validera Beacon Chain idag, har du två primära alternativ: solo-insats och delegerad insats; det finns andra vägar för att satsa ETH, men dessa mer eller mindre uttag på ett spektrum mellan de tidigare nämnda alternativen. Solosatsning är enkel:

• Sätt in 32 ETH i insättningskontraktet för Beacon Chain för att aktivera en ny validator
• Generera nycklar för att utföra valideringsuppgifter (verifiera transaktioner, attestera till block, aggregera attesteringar och föreslå block)
• Konfigurera en valideringsnod och synkronisera en execution layer (EL) och consensus layer (CL) klient
• Håll din validator online och fungerande för att undvika påföljder

Det finns fler steg (staking Launchpads Validator FAQ har en bra översikt för potentiella validerare), men dessa är ungefär de viktigaste aspekterna av att lansera en validator. Viktigt är att solosatsning inte kräver någon mellanhand eller motpart och låter dig behålla 100 % av belöningarna som erhålls från att validera (attestera till block och föreslå block) på Beacon Chain. Men det är inte en gratis lunch: du har ansvaret för att hantera din validerare och kommer att behöva en viss nivå av teknisk expertis för att driva en solosatsning.

Om idén att hantera en validator låter svår kan du gå den delegerade insatsvägen. Du är fortfarande ansvarig för att tillhandahålla 32 ETH för att registrera en ny validator – först nu delegerar du ansvaret för att driva valideraren till en tredje part. Validatornodoperatören tillhandahåller vad vissa skulle beskriva som en "vit handsketjänst" och kräver kompensation för denna tjänst. Till exempel kan du behöva dela en del av din validators belöningar med nodoperatören som en del av det ursprungliga avtalet.

Den "vita handske"-delen innebär att operatören tar på sig ansvaret för att hålla din validator funktionsduglig och säker - vilket innebär att du kan göra saker som att streama Netflix på en fredagskväll (eller vad du än gör på din fritid) utan att oroa dig för påföljder från missade valideringsuppgifter eller oroa dig för säkerheten för dina valideringsnycklar.

Det finns dock en varning: Delegerad insats kräver att du litar på nodoperatören för att undvika att utsätta din 32 ETH i fara genom att begå ett brott som kan skäras (t.ex. att underteckna två motstridiga block) eller direkt stjäla dina pengar. Det är mycket att fråga – och definitivt inte för personer med förtroendeproblem – men arrangemanget fungerar bra för det mesta när nodoperatörer är ärliga.

Men Ethereum byggdes inte på web2:s "trust me bro"-etos, vilket är anledningen till att "trustless" och "trustlessness" dyker upp ofta i konversationer på krypto-Twitter och Reddit. Delegerad insats i sin renaste form strider mot denna etos, men det finns en lösning på hur nyckelpar genereras under processen att aktivera en ny validator.

Varje validator har två nycklar: en uttagsnyckel och en valideringsnyckel. Uttagsnyckeln är ett offentligt-privat nyckelpar som krävs för att helt eller delvis ta ut saldot i en Beacon Chain-validator beroende på om du vill "skumma" (endast ta ut belöningar) eller "avsluta" (ta ut 32 ETH-saldot + belöningar) . Observera att uttagsnyckeln måste uppdateras från standard BLS ( 0x00 ) autentiseringsuppgifter till 0x01 autentiseringsuppgifter som pekar på en Ethereum-adress för att möjliggöra partiell eller fullständig uttag av en validators saldo.

Uttagsnyckeln genereras vid insättningstillfället via ett gränssnitt som Staking Launchpad och hashas för att skapa ett uttags-ID som ingår i insättningsdata från valideraren – vilket ger Beacon Chain information om vem som deponerade 32 ETH. Infografiken nedan från Protecting Withdrawal Keys av Attestant ger en bra översikt över hur uttagsnyckeln är integrerad i validatorns insättningsbegäran:

Validatornyckeln är ett offentligt-privat nyckelpar som krävs för att utföra de uppgifter som förväntas av varje Ethereum-validerare - i första hand rösta för block och föreslå block för andra att rösta på ("röstning" och "attestering" används omväxlande, men hänvisar till samma koncept för att verifiera transaktioner och bekräfta giltigheten av blocken). Validatorns publika nyckel fungerar som dess unika kryptografiska identitet i Ethereums konsensusprotokoll, medan den privata nyckeln förväntas döljas och användas för att signera blockdata (valideringsnycklar beskrivs också som signeringsnycklar av denna anledning).

Nu, för huvudskillnaden mellan valideringsnycklar (signeringsnycklar) och uttagsnycklar:

En validerares signeringsnyckel används ofta – tänk var 6,5:e minut eller längden på en slot under vilken varje validerare kommer att väljas för att intyga eller föreslå en blockering – och bäst förvaras på en online, lättillgänglig plats som en het plånbok. En uttagsnyckel används dock mindre ofta och kan förvaras på en säker, offline plats som en kall plånbok tills en aktör vill ta ut pengar från uttagsadressen som är kopplad till en viss validator.

Denna distinktion är avgörande för att minska förtroendeantaganden i en delegerad insatsinställning: eftersom uttagsnyckeln inte krävs för valideringsuppgifter, kan en staker behålla kontrollen över insatt ETH genom att dela valideringsnyckeln med nodoperatören och hålla tillbaka uttagsnyckeln. På så sätt kan en oseriös operatör inte springa iväg med en aktörs pengar efter att ha tagit ut en validators saldo utan aktörens godkännande.

Delegerade insatsarrangemang, där spelaren innehar uttagsnyckeln, beskrivs vanligtvis som "icke-förvarsbara" för att återspegla att den enhet som driver valideringsnoden för stakarens räkning i slutändan inte har någon kontroll över insatt ETH. Detta står i kontrast till förvaringslösningar där insatstjänsten kontrollerar både signerings- och uttagsnycklar; "white glove service on steroids" är en bra mental modell för frihetsberövande staking: en staker tillhandahåller helt enkelt 32 ETH för att finansiera valideraren och delegerar allt annat – inklusive initiering av validatorinsättningsbegäranden och lagring av uttagsnycklar – till insatstjänsten).

Att separera validatorsigneringsnycklar från uttagsnycklar löser teoretiskt problemet med förtroende för delegerade insatsavtal. I praktiken har förhållandet mellan nodoperatör och staker i en icke-frihetsbelagd insatsuppsättning fortfarande ett element av förtroende på grund av den nuvarande mekanismen för att dra tillbaka en validator och utlösa ett helt eller partiellt uttag av validatorns saldo till uttagsadressen.

För att dra tillbaka en validator från Beacon Chain måste ett "Voluntary Exit Message" (VEM) signerat med valideringsnyckeln skickas in för bearbetning på konsensusskiktet. När det väl inkluderats i ett block (varje block kan innehålla maximalt 16 uttagsbegäranden), läggs uttagsmeddelandet till i kön för uttagsbegäran — med fördröjningen på det slutliga uttaget påverkad av faktorer, såsom antalet uttag i kö eller validator churn rate.

Jag betonade kravet att underteckna en begäran om frivilligt tillbakadragande med validerarens signeringsnyckel för att belysa ett problem med befintliga "icke-frihetsberövande" insättningslösningar: en staker måste lita på nodoperatören – som kontrollerar valideringsnyckeln som krävs för att signera en VEM – för att behandla begäranden om uttag. Detta återinför effektivt förtroendet i förhållandet mellan nodoperatörer och insatstjänster; värre, det utsätter intressenter för att bli "sörgade" av skadliga nodoperatörer.

I en sorgsattack är angriparens mål att orsaka förluster för den andra parten – inte nödvändigtvis att dra direkt nytta. För att sätta detta i sitt sammanhang, överväg scenariot där Alice delegerar Bob att driva en validerare för hennes räkning men bestämmer sig för att dra tillbaka hennes 32 ETH senare. Bob kunde respektera Alices begäran och utlösa en uttagsbegäran genom att underteckna ett Voluntary Exit Message (VEM)...eller vägra att underteckna meddelandet om uttagsbegäran och stoppa Alices uttagsoperation. Bob kommer inte direkt gynnas av att tacka nej till Alices begäran – allt han kan göra är att hålla Alices ETH "gisslan" genom att vägra hjälpa Alice att dra tillbaka sin validator.

Okej, det är inte 100% korrekt; Bob kan göra många dåliga saker för att orsaka Alice ännu mer "sorg":

1. Minska Alices validatorbalans genom att avsiktligt begå ett slashbart brott eller ådra sig straff. Det individuella straffet för misslyckade valideringsuppgifter (t.ex. saknade intyg) eller begå ett brott som kan skäras (t.ex. underteckna två motstridiga block på samma plats) är vanligtvis lågt men ökar i proportion till antalet validerare som begår liknande överträdelser under samma period . Om till exempel ett eller två intyg saknas kommer en validators balans att minska med en liten bråkdel, men den minskningen ökar exponentiellt om en inaktivitetsläcka — där flera validatorer är offline — inträffar.

   
   

Enligt den nuvarande mekanismen kan en illvillig Bob minska Alices valideringssaldo på 32 ETH upp till 50 procent genom att ådra sig straff och skärningar tills valideraren med kraft dras tillbaka från Beacon Chain-konsensus (efter att dess effektiva saldo sjunkit till 16 ETH). Om vi använder 1 ETH = 2 000 $, kommer Bobs sorgsattack att kosta Alice minst 32 000 $ (16 ETH) i ett normalt fall (inga korrelerade straffavgifter) och 64 000 $ (32 ETH) i det värsta scenariot (dvs. där hela saldot kan skäras ned på grund av korrelationspåföljder).

Den som kan förstöra en sak, kontrollerar en sak. — Paul Atreides (Dune)

1. Kräv en lösensumma från Alice i utbyte mot att hon inte begår ett brott. Detta stämmer inte exakt överens med den tidigare definitionen av sorg, men tänk på att Bobs enda utväg är att bränna ETH om Alice bestämmer sig för att spela hardball. Situationen skiljer sig alltså från mer vanliga typer av attacker där målet (alltid) är att tjäna med minimal förlust.

Obs: Bob (nodoperatören) kan faktiskt vara ärlig i det här scenariot, men en motståndare kan äventyra valideringsnyckeln och hålla Alices ETH som gisslan. Detta förklarar "motpartsrisken" som användare av en SaaS-plattform (satsing-as-a-service) måste bära och är en annan anledning till att solosatsning - med dess "lita på ingen annan än dig själv"-etos - anses vara guldstandarden för Ethereum-aktörer .

Betyder detta att varje icke-frihetsberövande insatstjänst faktiskt inte är icke-frihetsberövande? Inte precis. En enkel lösning är att insatstjänsten undertecknar ett meddelande om frivillig uttagsbegäran i förväg - helst när valideraren har aktiverats på Beacon Chain - som spelaren kan skicka in oberoende till en Ethereum-konsensusnod när den vill dra tillbaka.

Genom att i förväg underteckna frivilliga uttagsförfrågningar för en staker, återgår arrangemanget mellan en staker och en nodoperatör till den ursprungliga icke-frihetsberövande statusen. Men meddelanden om förhandssignerade uttagsbegäranden är inte hållbara av många anledningar:

Problem med förhandssignerade uttagsförfrågningar för insats utan frihetsberövande

Komplexitet

Arbetsflöden för förhandssignerade uttagsbegäranden kräver mer kommunikation mellan en insatstjänstoperatör och insatsdelegatorn: du måste skicka in en begäran om ett meddelande om uttagsbegäran och vänta på att insatstjänsten skickar de undertecknade uttagsbegärandena. Det finns också problemet med säkerheten när du använder och utbyter försignerade uttagsbegäranden:

• En insatstjänst måste vidta extra försiktighetsåtgärder – som att kryptera meddelandet om uttagsbegäran och dela det via en säker (off-chain) kommunikationskanal – för att förhindra att meddelanden om uttagsbegäran hamnar i fel händer.
• En spelare måste vidta extra försiktighetsåtgärder för att lagra meddelandet om uttagsbegäran på en säker plats, eftersom att förlora meddelandet om uttagsbegäran motsvarar att potentiellt förlora förmågan att självständigt ta ut validatorns saldo.

Dessutom är förhandssignerade uttagsförfrågningar för närvarande giltiga för två Ethereum-gafflar eller ~12 månader - om du förväntar dig att forks ska ske ungefär var sjätte månad. Detta innebär att en aktör måste skicka in en begäran om en begäran om frivilligt tillbakadragande till operatören av satsningstjänsten flera gånger under ett kalenderår. Detta kommer inte längre att vara fallet när EIP-7044 implementeras och undertecknade begäranden om uttag av validator blir giltiga på obestämd tid.

EIP-7044 åtgärdar problemet med utgångsmeddelanden som löper ut, men det introducerar en ny uppsättning problem – särskilt för stora insatspooler. Som bakgrund är det nuvarande tillvägagångssättet i decentraliserade insatspooler att kräva att nya valideringsnodoperatörer skickar förhandssignerade uttagsbegäranden innan de får finansiering från poolen. Här ger undertecknade uttagsförfrågningar kryptoekonomisk säkerhet eftersom det minskar makten en (otillförlitlig) operatör har över validatormedel; en insatspool kan utlösa begäran om uttag från en icke-samarbetande validatornodoperatör genom att skicka in den försignerade begäran om uttag i kedjan.

Men en validatornodoperatör kommer inte att känna sig bekväm om försignerade uttagsbegäranden lagras på en slumpmässig server på grund av risken för att någon av misstag/avsiktligt utlöser en falsk uttagsbegäran genom att få tag i det undertecknade exitmeddelandet. I ett värsta scenario skulle tvingade exit sannolikt resultera i en förlust för en validatornodoperatör (t.ex. om du tog ett lån mot framtida Beacon Chain-belöningar). Detta innebär att insatspooler måste vidta ännu fler säkerhetsåtgärder och lagra meddelanden om uttagsbegäran säkert, särskilt i en värld efter EIP 7044 där undertecknade uttagsbegäranden har oändliga utgångsdatum.

En möjlig lösning är att kryptera signerade uttagsbegäranden med en delad offentlig nyckel genererad via ett DKG-protokoll (Distributed Key Generation) och kräva ett kvorum av nyckeldelningar för att rekonstruera den privata nyckeln innan uttagsbegäran kan dekrypteras. Detta minskar förtroendeantagandet som följer med att en part lagrar uttagsförfrågningar, förutsatt att ingen kontrollerar tillräckligt många nyckeldelningar för att ensidigt dekryptera de försignerade uttagsförfrågningarna utan input från andra deltagare. Men ett kantfall dyker upp om en eller flera privata nyckelandelar försvinner, förloras eller blir stulna – vilket gör det svårt, eller direkt omöjligt, att dekryptera den signerade uttagsbegäran om det blir nödvändigt att utlösa en validators uttag.

Regelefterlevnad

Staking-tjänster har fått mycket granskning från en alfabetsoppa av tillsynsmyndigheter, framför allt SEC (Securities and Exchanges Commission) ledd av kryptons offentliga fiende nr 1: Gary Gensler. Till exempel stängde Kraken ned sin förvaringsverksamhet tidigare i år och betalade 30 miljoner dollar i böter för att "erbjuda oregistrerade värdepapper genom sin kryptoinsatsplattform."

I teorin är det osannolikt att en insatstjänst som inte är frihetsberövad kommer att fastna i SEC:s hårkors på grund av den icke frihetsberövande karaktären hos dess arrangemang med insatsägaren:

1. Insättningen på 32 ETH (eller multiplar av 32 ETH) för att aktivera en validator kommer från en uttagsadress som kontrolleras av spelaren – och protokollet identifierar uttagsadressen som ägaren till insättningen på 32 ETH. Detta innebär att en insatstjänst utan förvaring inte kan ta ut validerarens saldo och "blanda kundernas pengar med sina egna" som Kraken anklagades för att göra av SEC.

I en börs som Kraken är en användares plånbokssaldo "virtuell" eftersom alla kundmedel hålls i en eller flera plånböcker som kontrolleras av börsen. Så om du satsar 32 ETH via en förvaringstjänst som drivs av en börs, vad du egentligen har är en IOU från börsen som lovar att betala tillbaka 32 ETH (plus en procentandel av valideringsbelöningar) när du vill ta ut pengar.

1. Stakers kan självständigt ta ut pengar genom att skicka in försignerade exits utan att riskera att en oseriös insatstjänst förhindrar uttag. Däremot har en förvaringstjänst – särskilt en börs som Kraken – kontroll över en aktörs tillgångar och kan blockera uttag av godtyckliga skäl.

Dessa två fakta undanröjer behovet av "investerarskydd"; Jag är ingen policyexpert, så ursäkta eventuella fel i detta resonemang. Men det kan fortfarande finnas en liten rynka eller två om du driver en institutionell, icke-frihetsberövad insatstjänst idag:

• Under den korta (eller troligtvis långa) perioden mellan aktivering av en validator och sändning av en i förväg undertecknad frivillig utgång till stakern, kontrollerar stakingtjänsten 32 ETH – vilket gör den "vårdande" i en regulators ögon. Ytterligare förvärrar problemet är de korta utgångsdatumen för försignerade utgångar (pre-EIP 7044): mellan det att ett nytt utträdesmeddelande signeras och skickas till spelaren har validatornodoperatören viss kontroll över den insatta ETH:n.
• Medan vanliga utgångsmeddelanden sänds i kedjan och är offentligt verifierbara, måste en försignerad utgång krypteras och delas utanför kedjan privat mellan nodoperatören och spelaren. Detta gör det svårare för en tredje part som en tillsynsmyndighet att verifiera att insatstjänsten verkligen undertecknade en avsikt att avsluta som en del av det initiala valideringsavtalet – eller om utbytet återkom när det ursprungliga exitmeddelandet löpte ut (dvs. -EIP 7004).

Sammanfattningsvis: försignerade exits lindrar vissa problem med delegerad insats, men räcker inte för att göra insatsen på Ethereum tillförlitlig, säker och decentraliserad. För att sätta tillbaka de "icke-frihetsberövade" i icke-frihetsberövande insatser behöver vi en bättre lösning – som vi nu har tack vare EIP-7002. Efterföljande avsnitt kommer att täcka EIP-7002 i detalj och beröra de olika fördelarna med EIP samt potentiella problem i samband med genomförandet.

En översikt över EIP-7002: Utlösningsbara uttag i exekveringsskikt

EIP-7002 löser problemet med principal-agent i delegerad insats – där aktörer måste lita på att validatornodoperatörer förundertecknar uttagsförfrågningar, eller respekterar framtida uttagsförfrågningar – genom att introducera en ny frivillig uttagsoperation som kan utlösas med en validators uttagsreferens. Detta ger aktörerna befogenhet att dra tillbaka insatt ETH utan att förlita sig på den enhet som innehar validerarens signeringsnyckel (dvs. insatstjänsten i en delegerad insatsuppsättning) för att behandla uttag.

EIP-7002:s nyckelfunktion är introduktionen av ett kontrakt för tillståndsbegäran för validatoruttag som upprätthåller en kö av validatoruttagsbegäranden som kommer från exekveringsskiktet. Med intervaller tas ett antal uttagsbegäranden bort från kön och läggs till exekveringsbegäran för ett Beacon Chain-block. Detta tillåter att uttagsbegäranden från exekveringsskiktet "injiceras" i konsensusskiktet och bearbetas som en del av Beacon Chain-operationer - liknande hur insättningar som härrör från insättningskontraktet överförs från exekveringsskiktet till konsensusskiktet för bearbetning.

Uttagsbegäranden är vanliga Ethereum-transaktioner med valideringskontraktets adress som mål och indikerar avsikt att ta tillbaka en validator (identifierad av dess publika nyckel). Ett meddelande om uttag av validator är giltigt om (a) det är signerat av Ethereum-adressen som hänvisas till i validerarens exekveringslager ( 0x01 ) uttagsreferens (b) validatorn som ska dras tillbaka är aktiv på Beacon Chain. Dessa kontroller utförs av konsensusskiktet efter att uttagsbegäran har tagit sig till Beacon Chain; validatorns kontrakt för uttagsbegäran bekräftar endast om en transaktion med begäran om uttag betalar tillräckligt med gas vid den tidpunkt då kontraktet för uttagsbegäran anropas av en aktör.

Alla uttagsförfrågningar i exekveringsskiktet behandlas på samma sätt som en vanlig frivillig begäran om uttagsbegäran som utlöses från konsensusskiktet, vilket bevarar invarianter kring de maximalt tillåtna uttagsbegäranden från de aktiva validatoruttag. EIP-7002:s in-protokollmekanism för att överföra uttagsbegäranden mellan exekverings- och konsensuslager tar också bort behovet av anslutningar till en konsensusnod för att trigga uttagsbegäranden (vilket krävs för att dra tillbaka validerare med förhandssignerade uttagsbegäranden). Validatorer kan nu finansieras och dras tillbaka från samma exekveringslageradress, vilket förklarar namnet på EIP som "Execution-Layer Triggerable Withdrawals".

Efter att ha sett hur EIP-7002 fungerar på hög nivå kan vi nu fördjupa oss i de finare detaljerna i EIP. Nästa avsnitt kommer att täcka den nuvarande specifikationen av EIP-7002 och diskutera nyckelaspekter av validatorns uttagsbegäran. Om du hellre vill hoppa över den tekniska diskussionen och utforska fördelarna med att implementera EIP-7002, kan du hoppa till nästa avsnitt – som belyser några av de förbättringar av användarupplevelsen (UX) som EIP-7002 möjliggör.

Validatorns uttagsbegäran

Enligt EIP-7002 är en validatoruttagsbegäran (definierad i pseudokod som add_withdrawal_request() ) ett CALL till validatorns uttagsbegäran kontraktsadress. Transaktionsfältet för samtal till validatorns uttagsbegärankontrakt har två värden:

• source_address : Ett 20-byte värde som representerar uttagsadressen som initierade transaktionen
• validator_pubkey : Ett 48-byte värde som representerar den offentliga nyckeln för validatorn som ska avslutas

Efter att en staker anropat kontraktet för uttagsbegäran med validator_pubkey som indata, kör kontraktet för uttagsbegäran för validatorn följande operationer (jag kommer att gå igenom viktiga delar av denna operation senare):

• Bekräftar att transaktionen betalar tillräckligt med gas för att täcka EXIT_FEE
• Ökar utgångsräknaren ( EXIT_COUNT ) med en för det aktuella blocket
• Infogar utgångsmeddelandet i kön
• Ökar överskottsuttag för det aktuella blocket ( EXCESS_EXITS ) med ett
• Återbetalar den som ringer – om de betalat för mycket för gas – genom att vidarebefordra ett stipendium på 2300 gas ( EXCESS_RETURN_GAS_STIPEND )

En viktig detalj: validatorns uttagsbegärans kontrakt kontrollerar inte om source_address är en giltig uttagsadress för validatorn som identifieras av validator_pubkey , och det kontrollerar inte heller om validator_pubkey . Detta avslöjar ett subtilt säkerhetsproblem som kan uppstå om en angripare fyller upp kön med meddelanden som är dömda att misslyckas; detta är i första hand en sorgsattack med syftet att förhindra behandling av legitima begäranden om uttag. EIP-7002 löser detta problem genom att ta ut en dynamiskt justerande avgift på transaktioner med begäran om uttag (mekanismen för uttagsavgift diskuteras senare).

Maximalt antal och riktade uttag per block

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK är antalet uttagsbegäranden från exekveringslager som kan inkluderas i ett Beacon Chain-block. Detta värde är för närvarande inställt på 16 för att spegla liknande operationer på Beacon Chain, såsom VoluntaryExit (exit-operationer som utlöses direkt från konsensuslagret med en stakers valideringsnyckel).

Specifikationen noterar också att inställning av MAX_WITHDRAWAL_REQUESTS_PER_BLOCK till 16 begränsar storleken på exekveringsnyttolaster - och i förlängningen storleken på Beacon Chain-block - och minskar omkostnaderna för bearbetning av exitoperationer på konsensusskiktet. Detta är användbart eftersom vi kan förvänta oss att vissa aktörer fortsätter att lämna validerare med den nuvarande mekanismen för att trigga utgångar från konsensuslagret (dvs via försignerade utgångar eller frivilliga utträdesmeddelanden i realtid).

TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK

EIP-7002 tillåter teoretiskt att upp till 16 exitoperationer i exekveringsskiktet inkluderas i ett block, men riktar sig mot en mer konservativ uppskattning av två exit per block. Enligt specifikationen har TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK satts till 2 för att begränsa churn-hastigheten för validatorer och bevara invarianten på maximalt tillåtna uttag per epok definierad av Beacon Chain's get_validator_churn_limit() funktion, även i situationer där all ETH är insatt.

Validatorns kö för uttagsbegäran

WITHDRAWAL_REQUEST_COUNT

WITHDRAWAL_REQUEST_COUNT är antalet uttagsbegäranden som ingår i det aktuella blocket. Efter varje lyckat anrop till kontraktet för validatoruttagsbegäran ökas värdet på variabeln WITHDRAWAL_REQUEST_COUNT som lagras i valideringskontraktets lagring med en (definierad i pseudokoden som increment_count() ).

När som helst kommer värdet på WITHDRAWAL_REQUEST_COUNT att ligga mellan TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK (2) och MAX_WITHDRAWAL_REQUESTS_PER_BLOCK (16) beroende på hur många uttagsbegäranden som läggs till blockets exekveringsnyttolast. WITHDRAWAL_REQUEST_COUNT är också en indata till funktionen som beräknar det belopp som ska betalas av en ny uttagsbegäran ( MIN_WITHDRAWAL_REQUEST_FEE ).

FÖRFLYTTANDE ÅTERTAGNINGSBEGÄRAN

EXCESS_WITHDRAWAL_REQUESTS är skillnaden mellan MAX_WITHDRAWAL_REQUESTS_PER_BLOCK och TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK -antalet uttagsbegäranden som inte används av det aktuella blocket. Som nämnts kan varje block innehålla maximalt 16 uttagsbegäranden men rikta in två uttagsbegäranden i normala situationer, så EXCESS_WITHDRAWAL_REQUESTS motsvarar "skillnaden mellan hur många uttagsbegäranden ett block teoretiskt sett kan konsumera och hur många uttagsbegäranden som faktiskt används".

Kontraktets överskottsräknare för uttagsbegäran uppdateras baserat på det sista blockets användning och är en faktor (bland andra) som bestämmer avgiften som betalas av en transaktion som anropar validatorns kontrakt för uttagsbegäran. Detta säkerställer att uttagsavgifterna prissätts enligt nuvarande användning, vilket liknar EIP-1559 som beräknar base_fee för ett nytt block beräknas baserat på skillnaden mellan målgasgränsen och gasen som användes av det föregående blocket.

WITHDRAWAL_REQUEST_QUEUE

WITHDRAWAL_REQUEST_QUEUE är en lista över alla pågående uttagsförfrågningar (ordnade i ankomstordning) som för närvarande är lagrade i valideringskontraktets WITHDRAWAL_REQUEST_QUEUE_STORAGE_SLOT (som WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT och WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT ). Antalet uttagsförfrågningar i kön kan vara obegränsat, men MAX_WITHDRAWAL_REQUESTS_PER_BLOCK variabel hastighet begränsar hur många pågående uttagsbegäranden som kan avköas i varje block.

Kön för uttagsbegäran upprätthåller ett "huvud" och ett "svans"-index - båda hänvisar helt enkelt till uppsättningen av förfrågningar nära början och slutet av kön - som uppdateras efter varje blockering för att ta hänsyn till behandlingen av en begäran eller uttagsbegäran. Detta är en först-in-först-ut-kö (FIFO), så förfrågningar exekveras i enlighet med när de läggs till i kön, vilket har säkerhetsimplikationer, särskilt kring sorgen från ärliga validerare.

Avgifter för uttagskontrakt för validator

MIN_WITHDRAWAL_REQUEST_FEE är det belopp som en adress som ringer validatorns uttagsbegäran kontrakt för uttag som en validator måste betala i gas. Innan en uttagsbegäran infogas i kön, kontrollerar validatorns uttagsbegärankontrakt att gasavgiften som är kopplad till transaktionen är lika med eller överstiger det aktuella värdet på MIN_WITHDRAWAL_REQUEST_FEE - om transaktionen har överbliven gas efter att den har utförts, krediteras sändningsadressen med exakt 2300 gas.

Enligt specifikationen följer denna design den nu utfasade funktionen i Solidity, där anropande av fallback() -funktionen i ett destinationskontrakt eller sändning av ETH via transfer() eller send() vidarebefordrar ett stipendium på 2300 gas till mottagaren. Förändringar i gaskostnader (som börjar med Berlin/Istanbul-gaffeln) har minskat användbarheten av den här funktionen (läs Stop Using Soliditys transfer() Nu för något sammanhang), men den ursprungliga idén med ett enkelt gasredovisningssystem är fortfarande användbar. I samband med EIP-7002 förenklar betalningsmekanismen för validatorns uttagsbegäran att skicka en fast återbetalning på 2300 gas.

Alternativet är att utforma en speciell mekanism som gör det möjligt för kontraktet med begäran om uttag att returnera den maximala mängden gas som blir över från en transaktion. Detta skulle vara vettigt, särskilt i fall där uttagsadressen är en EOA-smarta kontrakt kan beräkna exakta värden för MIN_WITHDRAWAL_REQUEST_FEE genom att kontrollera kontraktets tillstånd, men EOA:er kommer sannolikt att skicka mer gas för varje samtal till kontraktet för uttagsbegäran. Denna rutt gör designen av EIP-7002 mer komplex jämfört med att använda ett enkelt CALL för att vidarebefordra en fast mängd gas som en återbetalning; även om EIP-7002:s författare föreslår att denna funktion kan inkluderas i den slutliga specifikationen beroende på feedback från intressenter.

Beräkningen av MIN_WITHDRAWAL_REQUEST_FEE är där saker och ting blir intressanta. Avgiften för begäran om uttag är dynamisk och utformad för att svara på nätverksförhållandena, liknande grundavgiften som introducerades av EIP-1559, och är en funktion av tre variabler:

• Minsta (bas) uttagsavgift: MIN_WITHDRAWAL_REQUEST_FEE
• Antal överskottsuttag vid det aktuella blocket: EXCESS_WITHDRAWAL_REQUESTS
• Uppdateringsformeln för begäran om uttagsavgift: WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION

Liksom EIP-1559s base_fee , är validatorns uttagsavgift en avgiftsbegränsande mekanism: i det genomsnittliga fallet (två förfrågningar per block) kan alla som ringer validatorns uttagsbegäran kontrakt förvänta sig att betala den lägsta uttagsavgiften, men kostnaden för en uttagsoperation gradvis skalar upp fler uttagsbegäranden ingår i ett block. Detta kan härledas från EIP-7002:s formella specifikation för uppdatering av avgiften för uttagsbegäran : withdrawal_request_fee = MIN_WITHDRAWAL_REQUEST_FEE * e**(excess_withdrawal_requests / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION)

En förklaring av avgiftsmekanismen för begäran om uttag från specifikationen:

"Block-för-block-beteendet är ungefär som följer: Om block N behandlar X uttagsbegäranden, ökar excess_withdrawal_requests i slutet av block N med X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK , och så ökar uttagsavgiften i block N + 1 med en e**((X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK) / (WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) . Därför har den en liknande effekt som befintlig EIP-1559, men är mer "stabil" i den meningen att den svarar på samma sätt på samma totala uttagsförfrågningar fördelade över tiden. .”

Genom att successivt höja avgiften för begäran om uttag i enlighet med användningen av validatorkontraktet för uttagsbegäran, minskar EIP-7002 risken för att en angripare medvetet fyller upp kön för uttagsbegäran för att förhindra andra validerare från att göra uttag. Återkallningsmeddelanden i kön för uttagsbegäran läggs ur kö och i först-in-först-ut-stil (FiFo) i motsats till, säg, sist-in-först-ut (LiFo) eller högst betalande transaktion-först ordning. Även om vi kan anta att gaspriserna kommer att förhindra onödiga anrop till kontraktet för uttagsbegäran, kan en illvillig angripare vara villig att betala mer gas för att "stoppa" kön för uttagsbegäran och skjuta en annan validators uttagsbegäran till slutet av kön.

Problemet förvärras ytterligare av centraliseringen av blockbyggnad i post-Merge Ethereum. Om en angripare är integrerad med en eller flera dominerande byggare (för sammanhang: 80-90 % av blocken hittills på Ethereum har producerats av 4-5 byggare ) och är villig att betala för inkludering i toppklass, kan effektivt köra uttagsförfrågningar från en eller flera aktörer och förhindra snabba uttag av validerare från Beacon Chain.

Och varför skulle någon gå igenom all den stressen? En möjlig motivation kan vara att angriparen vill sörja aktörer som vill dra tillbaka validerare med hjälp av uttagsuppgifter. För att använda den föregående av Bob (den skadliga) nodoperatören och Alice the staker: Alice kan snabbt dra tillbaka sin validerare för att stoppa Bobs sorgsattack genom att ringa validatorns uttagsbegäran kontrakt med uttagsuppgifterna - men Bob kan fortfarande ge sig själv mer för att läcka Alices validatorsaldo genom att spamma validatorns uttagsbegäran och fördröja Alices uttagsbegäran.

Blockstruktur och giltighet

EIP-7002 ändrar något strukturen och valideringen av Beacon-block genom att kräva att uttagsbegäranden placeras i själva blocket (och exekveringsnyttolasten i konsensuslagret). Begäranden måste vara inbäddade i exekveringsnyttolasten så att närhelst konsensusskiktet är ouppnåeligt, har konsensusskiktet fortfarande den erforderliga data för att fullständigt exekvera konsensusdelen av tillståndsövergångsfunktionen.

EIP-7002 lägger också till nya giltighetsvillkor för block. För det första kan listan över uttagsbegäranden ( withdrawal_requests_list ) inte överstiga MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . För det andra måste listan över uttagsbegäranden motsvara antalet uttagsbegäranden som ställts i kö från WITHDRAWAL_REQUEST_QUEUE när sådana förfrågningar är ordnade i först-in-först-ut-ordning (FiFO).

EIP-7002 har en funktion ( expected_exit ) för att bekräfta att ett block inte innehåller fler uttagsbegäranden än resultatet av beräkningen av NUM_WITHDRAWAL_REQUESTS_IN_QUEUE - MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . Dessutom kommer en konsensusnod som återexekverar blocket oberoende att beräkna kodningen av uttagsbegäranden genom att iterera request_type och request_data jämfört med åtagandet av hashen för uttagsbegäran.

Varför EIP-7002? Fallet för utlösningsbara uttag på exekveringslager

Minskade förtroendeantaganden vid delegerad insats

I inledningen noterade jag hur beroendet av en validators signeringsnyckel för att initiera valideringsutgångar introducerade problemet med förtroende; Jag inkluderade ingen definition av tillit, men den här definitionen från Vitaliks Trust Models- artikel sammanfattar det fint: "Tilltro är alla antaganden du gör om andra människors beteende". Genom att registrera sig för en insatstjänst, med att veta att en skadlig nodoperatör kan frysa uttag, litar en staker i huvudsak på att nodoperatören agerar troget.

EIP-7002 tar inte helt bort förtroendeelementet i delegerad insats – du måste fortfarande lita på att en nodoperatör inte utför en sorgsattack – men att göra det möjligt för aktörer att dra sig tillbaka med uttagsuppgifter minskar förtroendebördan till viss del. En användare behöver till exempel inte "ha tro" på att en nodoperatör kommer att underteckna ett frivilligt avslutsmeddelande när de begär det.

En subtil poäng med "tillitlöshet" är att det inte nödvändigtvis handlar om att undvika behovet av att lita, utan om att inte behöva lita på eftersom (a) det finns starka incitament för alla parter att agera ärligt (b) ärliga parter har en viss mängd skydd mot oärliga parters handlingar. Möjligheten att dra tillbaka en validerare med autentiseringsuppgifter är ett exempel på det senare: Bob kanske försöker sörja Alice, men nu har Alice byrån att dra tillbaka sin validator, förhoppningsvis innan Bob gör någon mer skada.

Bättre riskhantering för insatspooler

För närvarande har insatspooler inget sätt att tvinga en validatornodoperatör att dra sig ur – vilket försätter poolbidragsgivare i den obekväma positionen att lita på att nodoperatörer agerar ärligt. Vissa decentraliserade insatspooler kräver att nodoperatörer tillhandahåller en obligation, men med tanke på möjligheten att en illvillig operatör kan skäras ned till 0 ETH, kan säkerheten från en obligation vara otillräcklig i ögonen på en riskvillig aktör.

Med EIP-7002 på plats kan insatspooler avsevärt minska förtroendeantaganden genom att komplettera säkerheten från hotet om att skära ned en nodoperatörs säkerhet med procedurer för att tvångsmässigt dra tillbaka en operatör som inte beter sig genom ett utförandelager. Möjligheten att uttagsreferenser pekar på en smart kontraktsadress (istället för en EOA) öppnar också nya incidentresponsdesigner för insatspooler – till exempel kan ett smart kontrakt automatiskt skicka en begäran om uttag om en operatör ådrar sig högre än genomsnittet påföljder inom ett tidsfönster. Detta kräver att man litar på ett orakel för att spåra validatorprestanda och ett keepernätverk för att utlösa det smarta kontraktet.

Den andra hypotetiska fördelen för en insatspool med att implementera EIP-7002 är att man undviker behovet av att begära och lagra försignerade uttagsmeddelanden, vilket kommer med risker som jag har förklarat tidigare (t.ex. kan obehörig åtkomst till uttagsmeddelanden resultera i oväntad validering uttag). Detta bidrar också till målet att utforma förtroendelösa insatspooler: i motsats till att förlita sig på förhandssignerade uttagsförfrågningar lagrade av ett fåtal (pålitliga) individer, skulle ett smart kontrakt som utsetts som uttagsadress kunna kontrolleras av styrning som gör det möjligt för gemenskapen att besluta att dra tillbaka en nodoperatör offentligt och öppet.

Bättre riskhantering för DVT-inställningar

Distributed validator technology (DVT) anses vara en viktig del av Ethereums insatsinfrastruktur av många anledningar:

• DVT minskar hindren för solo-insats: Flera solo-insatsare kan slå ihop pengar för att gemensamt aktivera en validator utan att behöva lita på alla andra parter. Multiparty Computation (MPC)-scheman kan tolerera upp till ⅓ felaktiga noder – så om en hypotetisk distribuerad validator kräver 3-av-5 nyckeldelningar för att rekonstruera validatorns signeringsnyckel, kan signering ske om två DVT-noder är offline.
• DVT förbättrar feltoleransen och motståndskraften för institutionella/solo-satsningsinställningar: Som nämnts ovan kan en valideringsnyckel delas upp i olika nyckeldelningar och rekonstrueras endast när signeringsblockdata krävs. Detta minskar risken för att en hackare äventyrar validerarens signeringsnyckel eller att en aktör förlorar tillgången till pengar på grund av att enheten som lagrar signeringsnyckeln lidit skada.

DVT-installationer medför dock fortfarande en viss risk för aktörer på grund av hur uttag och exit för närvarande fungerar på Beacon Chain. Om vissa DVT-noder tar bort nyckeldelning eller vägrar att delta i tröskelsigneringsschemat, blir det omöjligt att lämna en validator – särskilt när:

• Nyckeldelningar för varje deltagare i DVT-installationen genereras vid tidpunkten för aktivering av en validator och kan inte "uppdateras" efter den första DKG-ceremonin (observera att en "deltagare" helt enkelt kan vara en annan EOA som ägs av samma aktör); vissa DVT-protokoll tillåter att nya nyckeldelningar genereras, även om detta kan kräva att de återstående nyckeldelningarna uppfyller det kvorum av signaturer som krävs för vanlig signering.
• Kvorumtröskeln – antalet nyckeldelningar som krävs för att gemensamt generera en giltig signatur för den distribuerade valideraren – kan inte ändras när den (distribuerade) valideraren är aktiv.

Utan EIP-7002 ger möjligheten att dra tillbaka en validator med hjälp av uttagsnyckeln, skulle fördelen med att köra en DVT-installation - oberoende eller i samverkan med andra validatorer - reduceras avsevärt (t.ex. kan ett valideringssaldo låsas för alltid). EIP-7002 tillhandahåller ett reservsäkerhetsalternativ för distribuerade validerare: om det är omöjligt att rekonstruera signeringsnyckeln kan valideraren dras tillbaka från Beacon-kedjan genom att skicka in en begäran om uttag undertecknad med uttagsnyckeln rekonstruerad från nyckeldelning.

Bättre regelefterlevnad: Att sätta "icke-frihetsberövande" i icke-frihetsberövande insatser

Det är osannolikt att författarna till EIP-7002 uttryckligen nämnde med målet att göra det lättare att driva ett reglerat institutionellt staking-as-service-företag. Ändå hjälper EIP med problemet med att övertyga tillsynsmyndigheter om en institutions icke-vårdande av insatt ETH. En insatsoperatör i detta scenario skulle helt enkelt kunna presentera en hash av insättningstransaktionen undertecknad av spelarens uttagsnyckel – som nu kan signera och skicka in frivilliga utträden – som bevis på att medel som satts in i en validator aldrig är i dess förvar vid någon tidpunkt.

Jag betonade "någon tidpunkt som helst" eftersom, före EIP 7044, tar en nodoperatör tillfälligt kontroll över validatorns saldo efter att den försignerade utgången löper ut. Och även med EIP-7044:s evigt giltiga undertecknade utgångar, har nodoperatörer fortfarande vårdnaden om de 32 ETH som deponerats för en validator under den korta perioden mellan validatorns aktivering och stakern tar emot ett undertecknat utgångsmeddelande från stakingtjänstoperatören. EIP-7002 tar bort dessa besvärliga områden och säkerställer att intressenter har (bevisbar) vård av pengar under hela validerarens livscykel – från att gå in i Beacon Chain till att ta ut pengar och skicka pengar till stakers uttagsadress.

Bättre insatsanvändarupplevelse (UX) för alla

En bra mental modell för EIP-7002 är att tänka på det som " kontoabstraktion för stakinginfrastruktur". För sammanhanget är en valideringsnyckel (eller signeringsnyckel) alltid en EOA och kommer med samma uppsättning begränsningar kring säkerhet och användning av privata nyckel som påverkar vanliga Ethereum EOAs idag:

• Validatornycklar (signeringsnycklar) löper en högre risk att äventyras. Till skillnad från uttagsnycklar som lagras i kall (offline) lagring, lagras valideringsnycklar i heta plånböcker anslutna till Internet, vilket gör dem mottagliga för nätfiskeattacker. Om en validators signeringsnyckel äventyras är stakers och delegerade stakingleverantörer mottagliga för sorgvektorerna som beskrivs i inledningen utan någon reservplan – utöver "vänta tills balansen sjunker till 16 ETH och valideraren dras tillbaka med kraft av protokollet".
• Validatornycklar har begränsade alternativ för återställningsscheman (förlora den en gång = förlora den för alltid). Att dela upp en valideringsnyckel i flera nyckeldelningar via distribuerad valideringsteknik (DVT) kan minska denna risk, men att köra en solo-DVT-insatsinställning är inte trivialt; plus, som jag förklarade tidigare, är DVT inte en silverkula eftersom nyckeldelningar kan gå förlorade och komplicera uppdateringen av nyckeldelningar.
• Validatornycklar kan inte stödja mer flexibla insättningsdesigner. Olika insättningstjänster har utvecklat automatiserade/flexibla arbetsflöden för finansieringsvaliderare på grund av fördelen med att peka på uttagsreferenser till smarta kontrakt. Att återkalla en validator är dock en manuell process som kräver att man undertecknar ett meddelande om frivillig uttagsbegäran - processen kan automatiseras genom ett smart kontrakt som lagrar förfrågningar om pre-signex uttag, men det kommer med vissa förtroendeantaganden och säkerhetsöverväganden som förklarats tidigare.

Vi kan lösa de flesta – eller åtminstone några – av dessa problem när uttagsnycklar kan lämna validerare. För att detta ska fungera måste en staker (eller insatspool) genomföra en engångsändring från 0x0 uttagsuppgifter till 0x01 uttagsuppgifter – medan 0x0 autentiseringsuppgifter är en BLS (EOA) nyckel som standard, 0x01 referenser kan peka på vilket Ethereum som helst adress, inklusive smarta kontrakt och EOA. Att sätta ett smart kontrakt som uttagsadress för en validator är bra för att förbättra användarupplevelsen (UX) av insats:

1. Uttagsnycklar kan ha flexibla återhämtningsmekanismer, som social återhämtning. En staker skulle ha en eller flera "vårdnadshavare" som kan auktorisera en ny nyckel för att kontrollera uttagsbegäran smart kontrakt om den ursprungliga nyckeln blir stulen eller försvunnen – vårdnadshavare kan vara vänner, släktingar, medspelare eller en specialiserad tredjepartstjänst. Flexibilitet i återhämtningsmekanismer kan särskilt gynna solospelare; du kan ha en dödmansbrytare som aktiverar en EL-utgång och skickar pengar till en angiven adress om din validator slutar att intyga under en förutbestämd period (t.ex. för att du har "gått vidare till det stora bortom").

2. Flexibla utsättningsdesigner kan uppstå. Till exempel kan en riskvillig spelare föredrar ett 2-av-2 multisig-uttagskontrakt – där spelaren och nodoperatören håller en av de två nycklarna som krävs för att godkänna uttagsbegäranden – istället för att lagra hela uttagsnyckeln. Det är fortfarande icke-vårdande (en nodoperatör kan inte lämna valideraren utan godkännande), även om det kräver att man litar på att nodoperatören inte blockerar en validators utgång genom att vägra att underteckna transaktioner med begäran om uttag som föreslagits av stakern.

För insatspooler kan flexibilitet i insatsdesigner innebära att man implementerar uttagskontrakt med godtycklig logik för att uppdatera eller överföra äganderätten till validatorer. I avsaknad av EIP-7002 är det enda verkliga sättet som en insatspool kan hantera ägande av validerare att flytta runt förhandssignerade uttagsbegäranden, vilket kommer med olika risker och fördelar.

3. Validatoruttag kan säkert automatiseras. Till skillnad från att lagra försignerade uttagsförfrågningar i ett smart kontrakt, kan kontrakt för uttagsbegäranden ha komplexa regler för uttagsbegäranden från validator; en "galen vetenskap"-idé är en "tidsbaserad insatspool" där nodoperatörer roteras tillitslöst. Eller fundera på om en stor insatspool som Lido vill decentralisera: förvaltningen kan välja att dra tillbaka vissa validatorer som kontrolleras av en stor nodoperatör och omfördela medel till mindre operatörer (eller solointresserade) för att minska chokepoäng från en nodoperatör som kontrollerar ett stort antal validerare.

Det här är bara några av de tidiga möjligheterna EIP-7002 möjliggör, men jag är mycket säker på att fler applikationer kommer att dyka upp – precis som hur nya funktioner och användningsfall för smarta plånböcker på Ethereum fortsätter att dyka upp. Om du läser det här och har mer konkreta idéer för att applicera EIP-7002 på utsättningsdesigner, hör gärna av dig i kommentarerna!

Finns det några nackdelar med att implementera EIP-7002?

Potentiella förändringar av befintliga utsättningsdesigner

I utkastet till EIP erkänner författarna till EIP-7002 potentiella farhågor kring att göra det möjligt för uttagsreferenser att utlösa valideringsuttag – men fortsätter med att säga, "vi känner inte till några insatsdesigner som förlitar sig på denna funktion [dvs. oförmåga att dra tillbaka med uttagsuppgifter]”. Detta verkar rimligt – även jag hade lite svårt att resonera om något delegerat insatsarrangemang som skulle kräva denna funktion. Men bara för att det inte verkar självklart betyder det inte att det inte finns där.

"Lyssna på dessa tysta, tjatande tvivel. Om du inte vet, vet du inte vad du inte vet, du vet inte hur mycket du inte vet, och du vet inte hur mycket du behövde veta.” — Eliezer Yudkowsky

För att ge lite sammanhang kommer jag att inkludera skärmdumpar av en konversation kring ett tidigt förslag om att implementera uttag som godkänts för uttag av autentiseringsuppgifter via en Generalized Message Bus (GMB) . GMB är ett smart kontrakt på systemnivå vars händelser läses och bearbetas av kunder, som det nuvarande insättningskontraktet, och som kan förmedla meddelanden från exekveringsskiktet till konsensusskiktet. Medan författaren(erna) antydde mer generiska EL-till-CL-meddelandetyper, var det huvudsakliga föreslagna användningsfallet för EL-till-CL-meddelandebussen ett sätt att trigga utgångar från exekveringsskiktet via 0x01-återkallelsereferenser.

Från detta utbyte har vi redan ett exempel på en operatörsrelation mellan staker-nod som bygger på antagandet att spelaren inte kan lämna och dra tillbaka en validator med hjälp av uttagsnyckeln. Ett annat exempel på ett potentiellt fördelaktigt fall för implementering av EIP-7002 kommer från en konversation kring Lidos decentraliseringsplaner på Lido Community Staking Podcast, som du kan titta på på YouTube . (EIP-7002 nämns bara kort (28:55 till 30:00) i videon).

Som bakgrund har Lido beskrivits som ett "systematiskt hot mot Ethereum" eftersom det kontrollerar ~33,3% av Beacon Chain-validerare och kan sätta Ethereums konsensus på spel; till exempel om Lido DAO tvingade nodoperatörer att censurera transaktioner eller återställa tidigare slutförda block (Mike Neuders Magnitude and direction of Lido attack vectors beskriver hotet mer i detalj).

En av talarna i det tidigare länkade avsnittet framför dock det övertygande argumentet att denna attackvektor – DAO som med kraft samarbetar nodoperatörer till en attack mot Ethereum-protokollet – inte existerar ännu, eftersom nodoperatörer har någon agentur. DAO kan hålla inne insatsen för en validator efter att den lämnats, men kan inte lita på hotet om en påtvingad utgång för att tvinga en validator att attackera Ethereums konsensus.

Med EIP-7002 förändras kraftdynamiken avsevärt: uttagskontrakt som styrs av DAO kan dra tillbaka en operatör mot dess önskemål – vilket ger DAO hävstångseffekt över nodoperatörer. Den här typen av hävstång är användbar för att skydda ett insättningsprotokoll mot en skadlig operatörsuppsättning, som jag har förklarat tidigare. Men det kan också missbrukas i följande scenarier:

• Insatsprotokollet drabbas av en förvaltningsattack och DAO skickar ett skadligt förslag för att utlösa en validators tillbakadragande från uttagskontraktet
• En angripare tar kontrollen över en eller flera validerare genom att kapa äganderätten till kontraktet för uttagsbegäran och kör en framgångsrik utpressningsstrategi

Detta är ytterligare ett exempel på hur EIP-7002 skulle kunna ändra befintliga antaganden i utsättningsdesigner – den här gången för nodoperatörer som validerar på uppdrag av en insatspool som Lido. Ändå kan denna attackvektor enkelt mildras genom olika metoder som att använda säkra, noggrant granskade och eventuellt icke-uppgraderbara kontrakt för begäran om uttag eller att följa bästa praxis för säker DAO-styrning .

För att ta hänsyn till fallet där en nodoperatör lider förluster på grund av ett påtvingat tillbakadragande efter att ha vägrat en angripares krav på att bryta mot protokollregler, kan insatspooler hämta inspiration från fastighetsbolag för att skydda nodoperatörer:

• Innan ett hyresavtal undertecknas måste hyresgäster lämna en "deposition". Depositionen förvaras på ett bankkonto utanför fastighetsbolagets kontroll.
• Om hyresgästen flyttar från lägenheten, men lämnar efter sig betydande skador, har fastighetsbolaget rätt att använda depositionen för att täcka kostnaden för reparationer.
• Om lägenheten är i gott skick vid tidpunkten för en hyresgästs utträde, återbetalas depositionen i sin helhet till hyresgästen.

Ett insatsprotokoll kan anta ett liknande tillvägagångssätt för att skydda nodoperatörer genom att teckna en "nodoperatörsförsäkringsfond" via Nexus Mutual , Tidal Finance eller någon annan kryptonativ försäkringsplattform. Om en operatörs validator dras in på ett legitimt sätt, återlämnas försäkringsfonden till DAO; om det omvända är sant (t.ex. en validators tillbakadragande utlöses av ett skadligt förslag eller ett uttagskontrakt), betalar försäkringen ut skadestånd till nodoperatören. Observera att detta tillvägagångssätt kan generaliseras till alla befintliga relationer som förlitar sig på de nuvarande specifikationerna för att avsluta en validator.

Brist på stöd för mer komplexa EL-till-CL-meddelanden

EIP-7002:s kontrakt för begäran om uttag av validator ger en enda funktionalitet: att skicka en begäran om uttag från Ethereums exekveringslager till konsensusskiktet för att dra tillbaka en validator. Vissa har dock föreslagit att implementera ett allmänt ramverk för meddelanden (t.ex. en SendMessageToConsensusLayer förkompilering, eller Generalized Message Bus (GMB) systemnivåkontrakt som nämnts tidigare) för att skicka generiska typer av meddelanden mellan exekveringsskiktet och konsensusskiktet. Detta kan ha fördelar som att låsa upp nya sätt att aktivera validerare på Beacon Chain, speciellt om det är tillåtet att koppla ETH till EL-till-CL-meddelanden.

Men som Danny Ryan (en av EIP-7002:s författare) förklarar i en kommentar , är att spendera värdefull ingenjörstid på ett generiskt meddelande EL → CL-ramverk ett "stort företag med oklara värdeförslag". För att illustrera, identifierade författarna till förslaget GMB (General Message Bus) endast ett annat användningsfall för en meddelandebuss mellan EL och CL: roterande uttagsreferenser för en validator från 0x0 till 0x01 referenser.

Detta betyder att vi är mer benägna att se att validatorn drar tillbaka begäran om kontrakt skickas först innan kärnutvecklare pratar om att implementera en allmän EL-till-CL-meddelandebuss, om det någonsin kommer att hända. Inte för att det någonsin gör ont att hålla saker enkla.

Enkelhet är en förutsättning för tillförlitlighet. — Edsger W. Dijkstra

Nyare riskvektorer för befintliga aktörer

Jag har utvecklat fördelarna med att aktivera uttagsreferenser för att utlösa ett uttag för det mesta, men det finns några kantfall förknippade med den funktionen. Idén går så här (h/t till denna kommentar på GitHub ):

• Om en validators signeringsnyckel äventyras kan en hackare kräva lösen eller försöka minska validerarens saldo – men den kan inte ta ut pengar under något scenario. Ett väntande spel kommer att följa: Kommer angriparen att förstöra hela saldot, eller kommer spelaren att kunna dra tillbaka någon del av insatsen när validatorn dras tillbaka med kraft?
• Men när EIP-7002 väl har implementerats kan hackaren i det föregående scenariot fortsätta att lämna valideraren och dra tillbaka saldot (när EIP-7002 väl har implementerats) istället för att nöja sig med en sorg/utpressningsattack.

Kort sagt, ensamspelande och insatstjänster kommer att behöva mer skydd för uttagsreferenser efter EIP 7002. Det är därför antagandet av social återhämtning, multifaktorautentisering (MFA) och nyckelrotation anses vara avgörande för att förbättra säkerheten för solo/delegerad staking.

Val av hastighetsbegränsande mekanism

Validatorns uttagsbegäran kontrakt add_withdrawal_request() funktionen utför inga ytterligare kontroller, förutom att kontrollera den bifogade avgiften för uttagsbegäran, vilket potentiellt tillåter en angripare att täppa till meddelandekön med ogiltiga uttagsbegäranden (t.ex. utgångsmeddelanden för en icke-existerande validator eller så kommer en inaktiv validator att ogiltigförklaras under konsensusskiktets giltighetskontroller). EIP-7002 använder en dynamiskt prissatt uttagsavgift för att begränsa uttagsförfrågningar och göra sådana attacker kostsamma, på samma sätt som EIP-1559 motverkar spamattacker och blockerar fyllning genom att justera gaspriserna baserat på nätverksaktivitet.

En alternativ design är att begränsa samtal till kontrakt för begäran om återkallelse av validator till faktiska validatorer – till exempel genom att kontrollera att validator_pubkey motsvarar den publika nyckeln för en aktiv Beacon Chain-validator. Detta kan förenkla EIP-7002:s design genom att ta bort behovet av en komplex, EIP-1559-liknande prissättningsmekanism och, potentiellt, minska avgiften för begäran om uttag eftersom det kan vara mindre problem att spamma kön med falska förfrågningar.

Detta kräver dock att exekveringsskiktet kan tillförlitligt komma åt information om konsensusskiktet – för att kontrollera validator_pubkey mot Beacon Chains validatorregister – en funktion som är beroende av implementering av EIP-4788. Detta lägger till mer komplexitet till EIP-7002 och introducerar ett nytt beroende mellan de två EIP:erna, vilket kan få konsekvenser för framtida designförbättringar som noteras i detta avsnitt av EIP-7002:s motivering .

Även om EIP-4788 integrerades med EIP-7002, skulle vi fortfarande behöva ytterligare mekanismer för att förhindra andra former av skräppost som involverar legitima validerare; ett exempel är att skicka in flera uttagsbegäranden för samma validator under en mycket kort period. Detta i sin tur kräver att man lägger till (och upprätthåller) en ny regel som "du kan bara skicka in en uttagsbegäran per validerare var 3-4 månad", vilket kan kräva ännu fler ändringar av validatorns uttagsbegäran.

Däremot är den nuvarande hastighetsbegränsningsmekanismen enkel att resonera kring och garanterar tillräckligt skydd mot de flesta säkerhetsproblem som är förknippade med uttag av exekveringsskikt. Till exempel kan avgiften för begäran om uttag automatiskt justeras uppåt för att avskräcka sorg (försök att förhindra ärliga validerare från att dra sig ur) och spam och DOS-attacker (försöker överbelasta Beacon Chain genom att tvinga konsensusnoder att slösa resurser på att filtrera ogiltiga uttagsoperationer).

Slutsats: EIP-7002 och framtiden för satsning på Ethereum

Delegerad insats har fått betydande kritik de senaste månaderna, men det är säkert att anta att staking-as-a-service-branschen är här för att stanna. Om så är fallet är det viktigt att minska risken för individer som delegerar andelar – vare sig de är till en likvid insatspool eller en institutionell insatstjänst utan förvaring. EIP-7002 uppnår detta mål genom att göra 0x01 uttagsreferenser kapabla att lämna validerare och dra tillbaka insatser och minska behovet för aktörer att lita på en nodoperatörs ärlighet.

EIP-7002 har också andra positiva spridningseffekter. I synnerhet bör en förbättring av motståndskraften och säkerheten för soloinsatsoperationer och distribuerade validerare – genom att möjliggöra bättre återhämtning från förlust av en valideringsnyckel eller DVT-nyckeldelning – minska barriären för solosatsning och minska insatscentraliseringen på Ethereum.

Som vanligt avslutar jag med att be dig överväga att dela den här artikeln med någon som kanske tycker att den är informativ och, ännu viktigare, prenumerera på Ethereum 2077 för mer djupdykning i allt som rör Ethereum FoU. Du kan också kontakta mig på Twitter för att dela kommentarer eller feedback om den här artikeln.