EIP-7002: 'n Beter manier om op Ethereum te speel

Ethereum se oorgang van Proof of Work (Pow) na Proof of Stake (PoS), oftewel The Merge, was 'n sleuteloomblik in die netwerk se geskiedenis. Behalwe om Ethereum 'n broodnodige herhandelsnaam te gee deur sy koolstofvoetspoor te verklein, was Proof of Stake noodsaaklik vir 'n belangrike langtermyndoelwit: die vermindering van die hindernis vir deelname aan Ethereum se konsensus. Die samesmelting het berekeningshulpbronne (mynkrag) vervang met finansiële kapitaal as die basis van Ethereum se ekonomiese sekuriteit - wat die geleentheid oopmaak vir enigiemand om winsgewend en maklik 'n valideerdernodus te bestuur deur 32 ETH op die Beacon Chain te steek.

Alhoewel bewys van spel voordele gebring het, is daar steeds baie areas van verbetering. Sommige hiervan sluit in:

• Verminder belangsentralisasie en valideerderkartelisering
• Minimalisering van operasionele bokoste vir valideerders en aansporing van solo-aansporing
• Verbetering van staking-ekonomie en gebruikerservaring (UX)
• Verbetering van eenvoud, sekuriteit en desentralisasie van gedelegeerde en veelparty-stakingbedrywighede

EIP-7002: Execution Layer Triggerable Onttrekkings is 'n nuwe Ethereum Improvement Proposal (EIP) wat sommige van die voorgenoemde probleme regstel. Die EIP stel 'n meganisme bekend vir belanghebbendes om valideerders van die Beacon Chain te onttrek deur onttrekkingsbewyse te gebruik in plaas daarvan om op 'n valideerder se ondertekeningsleutel staat te maak om onttrekkingsbedrywighede te aktiveer - wat 'n validator se ondertekeningsleutel effektief van die onttrekkingsleutel ontkoppel.

Hierdie "skeiding van bekommernisse" tussen valideerder-ondertekeningsleutels en onttrekkingsleutels het 'n kritieke voordeel: die vermindering van vertroue-aannames in gedelegeerde staking deur onttrekkingsgeloofsbriewe in staat te stel om beheer oor die betrokke ETH te behou. Ek sal in die loop van hierdie artikel ondersoek hoekom hierdie kenmerk nodig is en ander voordele van EIP-7002 bespreek, veral vir solo-staking en DVT (distribued validator technology) staking. Die artikel sal ook 'n paar potensiële nadele van die implementering van EIP-7002 op Ethereum oorweeg.

Kom ons duik in!

Stel die verhoog: 'n Verhaal van sleutels, wit handskoene en hartseer

As jy ETH wil insit en die Beacon Chain vandag wil bekragtig, het jy twee primêre opsies: solo staking en gedelegeerde staking; daar is ander maniere om ETH in te span, maar hierdie min of meer onttrekkings op 'n spektrum tussen die bogenoemde opsies. Solo staking is eenvoudig:

• Deponeer 32 ETH in die Beacon Chain depositokontrak om 'n nuwe valideerder te aktiveer
• Genereer sleutels vir die uitvoering van valideerderpligte (verifiëring van transaksies, attestering van blokke, samevoeging van attests, en stel blokke voor)
• Stel 'n valideerdernodus op en sinkroniseer 'n uitvoeringslaag (EL) en konsensuslaag (CL) kliënt
• Hou jou valideerder aanlyn en funksioneer behoorlik om boetes te vermy

Daar is meer stappe (die Staking Launchpad se Validator FAQ het 'n goeie oorsig vir voornemende valideerders), maar dit is ongeveer die belangrikste aspekte van die bekendstelling van 'n validator. Belangrik, solo-inzet vereis geen middelman of teenparty nie en laat jou toe om 100% van die belonings wat ontvang word van validering (bevestiging van blokke en voorstel van blokke) op die Beacon Chain te hou. Maar dit is nie 'n gratis middagete nie: jy het die verantwoordelikheid om jou valideerder te bestuur en sal 'n mate van tegniese kundigheid nodig hê om 'n solo-staking-operasie uit te voer.

As die idee om 'n valideerder te bestuur moeilik klink, kan jy die gedelegeerde stakingsroete gaan. Jy is steeds verantwoordelik vir die verskaffing van 32 ETH om 'n nuwe valideerder te registreer—net nou delegeer jy die verantwoordelikheid om die valideerder te bedryf aan 'n derde party. Die valideerdernodusoperateur verskaf wat sommige as 'n "withandskoendiens" sal beskryf en vereis vergoeding vir hierdie diens. Daar kan byvoorbeeld van jou verwag word om 'n deel van jou valideerder se belonings met die nodusoperateur te deel as deel van die aanvanklike ooreenkoms.

Die "wit handskoen"-deel beteken dat die operateur verantwoordelikheid aanvaar om jou valideerder operasioneel en veilig te hou - wat beteken dat jy dinge kan doen soos Netflix op 'n Vrydagaand (of wat jy ook al in jou vrye tyd doen) kan doen sonder om bekommerd te wees oor boetes van ontbrekende validator-pligte of om bekommerd te wees oor die veiligheid van jou valideerdersleutels.

Daar is egter 'n waarskuwing: Gedelegeerde staking vereis dat u die nodusoperateur vertrou om te verhoed dat u 32 ETH in gevaar stel deur 'n snybare oortreding te pleeg (bv. twee botsende blokke te onderteken) of om u fondse te steel. Dit is baie om te vra - en beslis nie vir mense met vertroue kwessies - maar die reëling werk goed uit die meeste van die tyd wanneer nodus operateurs eerlik is.

Maar Ethereum is nie gebou op web2 se “trust me bro”-etos nie, en daarom sien jy dat “trustless” en “trustlessness” gereeld voorkom in gesprekke op crypto-Twitter en Reddit. Gedelegeerde staking in sy suiwerste vorm bots met hierdie etos, maar daar is 'n oplossing vir die manier waarop sleutelpare gegenereer word tydens die proses om 'n nuwe valideerder te aktiveer.

Elke valideerder het twee sleutels: 'n onttrekkingsleutel en 'n valideerdersleutel. Die onttrekkingsleutel is 'n publiek-private sleutelpaar wat nodig is om die balans van 'n Beacon Chain-valideerder gedeeltelik of heeltemal te onttrek, afhangende van of jy wil "skim" (onttrek slegs belonings) of "uitgaan" (onttrek die 32 ETH-saldo + belonings) . Let daarop dat die onttrekkingsleutel opgedateer moet word vanaf die verstek BLS ( 0x00 ) geloofsbriewe na 0x01 geloofsbriewe wat na 'n Ethereum adres verwys om gedeeltelike of volle onttrekking van 'n valideerder se balans moontlik te maak.

Die onttrekkingsleutel word gegenereer ten tyde van deponering via 'n koppelvlak soos die Staking Launchpad en gehash om 'n onttrekking-ID te skep wat ingesluit is in die depositodata van die valideerder - wat die Beacon Chain inligting verskaf oor wie die 32 ETH gedeponeer het. Die infografika hieronder van Beskerming van Onttrekkingsleutels deur Attestant bied 'n goeie oorsig van hoe die onttrekkingsleutel geïntegreer is in die valideerder-deposito-versoekproses:

Die valideerdersleutel is 'n publiek-private sleutelpaar wat nodig is vir die uitvoering van die pligte wat van elke Ethereum-bekragtiger verwag word - hoofsaaklik om vir blokke te stem en blokke voor te stel vir ander om oor te stem ("stem" en "attestering" word uitruilbaar gebruik, maar verwys na dieselfde konsep om transaksies te verifieer en die geldigheid van blokke te bevestig). Die valideerder se publieke sleutel dien as sy unieke kriptografiese identiteit in Ethereum se konsensusprotokol, terwyl die private sleutel na verwagting versteek en gebruik word vir die ondertekening van blokdata (validatorsleutels word ook beskryf as ondertekeningsleutels om hierdie rede).

Nou, vir die belangrikste verskil tussen validator (ondertekening) sleutels en onttrekkingsleutels:

'n Valideerder se ondertekeningsleutel word gereeld gebruik - dink elke 6,5 minute of die lengte van 'n gleuf waartydens elke valideerder gekies sal word om 'n blokkering te getuig of voor te stel - en die beste gehou word op 'n aanlyn, maklik-toeganklike plek soos 'n warm beursie. 'n Onttrekkingsleutel word egter minder gereeld gebruik en kan op 'n veilige, vanlyn plek gehou word soos 'n koue beursie totdat 'n belanghebbende fondse wil onttrek van die onttrekkingsadres wat met 'n spesifieke valideerder geassosieer word.

Hierdie onderskeid is van kardinale belang vir die vermindering van vertroue-aannames in 'n gedelegeerde staking-opstelling: aangesien die onttrekkingsleutel nie nodig is vir valideringspligte nie, kan 'n belanghebbende beheer behou oor die betrokke ETH deur die valideerdersleutel met die nodusoperateur te deel en die onttrekkingsleutel te hou. Op dié manier kan 'n skelm operateur nie met 'n belanghebbende se fondse weghardloop nadat hy 'n valideerder se balans onttrek het sonder die aandeelhouer se goedkeuring nie.

Gedelegeerde stakingsreëlings, waar die belanghebbende die onttrekkingsleutel hou, word tipies beskryf as "nie-bewaring" om te weerspieël dat die entiteit wat die valideerdernodus namens die belanghebbende bedryf, uiteindelik geen beheer het oor die betrokke ETH nie. Dit staan in kontras met oplossings vir bewaring waarin die stakingsdiens beide onderteken- en onttrekkingsleutels beheer; "withandskoendiens op steroïede" is 'n goeie verstandelike model vir bewaring: 'n belanghebbende verskaf eenvoudig 32 ETH om die valideerder te finansier en delegeer alles anders - insluitend die aanvang van valideerderdeposito-versoeke en die stoor van onttrekkingsleutels - na die staking-diens).

Die skeiding van valideerder-tekensleutels van onttrekkingsleutels los teoreties die probleem van vertroue in gedelegeerde staking-ooreenkomste op. In die praktyk het die verhouding tussen nodusoperateur en belanghebbende in 'n nie-toesighoudende staking-opstelling steeds 'n element van vertroue as gevolg van die huidige meganisme om 'n valideerder te onttrek en 'n volle of gedeeltelike onttrekking van die valideerder se balans na die onttrekkingadres te veroorsaak.

Om 'n valideerder uit die Beacon Chain te onttrek, moet 'n "Voluntary Exit Message" (VEM) onderteken met die valideerdersleutel ingedien word vir verwerking op die konsensuslaag. Sodra dit by 'n blok ingesluit is (elke blok kan 'n maksimum van 16 onttrekkingsversoekbewerkings insluit), word die onttrekkingsboodskap by die onttrekkingversoektou gevoeg—met die vertraging op die finale onttrekking wat deur faktore beïnvloed word, soos y die aantal tou-onttrekkings of validator churn rate.

Ek het die vereiste beklemtoon om 'n vrywillige onttrekkingsversoek met die valideerder se ondertekeningsleutel te onderteken om 'n probleem met bestaande "nie-toesighoudende" staking-oplossings uit te lig: 'n belanghebbende moet staatmaak op die nodusoperateur - wat die valideerdersleutel beheer wat nodig is om 'n VEM te onderteken - om onttrekkingsversoeke verwerk. Dit stel vertroue effektief weer in die verhouding tussen nodusoperateurs en stakingsdienste; erger nog, dit plaas belanghebbendes op die risiko om "bedroef" te word deur kwaadwillige nodus-operateurs.

In 'n bedroefde aanval is die aanvaller se doel om verliese vir die ander party te veroorsaak—nie noodwendig om direk te bevoordeel nie. Om dit in konteks te plaas, oorweeg die scenario waar Alice Bob delegeer om 'n valideerder namens haar te bedryf, maar besluit om haar 32 ETH later te onttrek. Bob kan Alice se versoek eerbiedig en 'n onttrekkingsversoek aktiveer deur 'n Voluntary Exit Message (VEM) te onderteken ... of weier om die onttrekkingsversoekboodskap te onderteken en Alice se onttrekkingsoperasie te stuit. Bob sal nie direk daarby baat om Alice se versoek te weier nie—al wat hy kan doen is om Alice se ETH “gyselaar” te hou deur te weier om Alice te help om haar valideerder te onttrek.

Goed, dit is nie 100% akkuraat nie; Bob kan baie slegte dinge doen om Alice nog meer "hartseer" te veroorsaak:

1. Verminder Alice se valideerderbalans deur doelbewus 'n snybare oortreding te pleeg of strawwe op te doen. Die individuele straf vir die versuim van valideerderpligte (bv. ontbrekende attestasies) of die pleeg van 'n snybare oortreding (bv. die ondertekening van twee botsende blokke in dieselfde gleuf) is tipies laag, maar neem toe in verhouding tot die aantal valideerders wat soortgelyke oortredings in dieselfde tydperk pleeg . Byvoorbeeld, die ontbrekende van een of twee attests sal 'n valideerder se balans met 'n klein fraksie verminder, maar daardie vermindering neem eksponensieel toe as 'n onaktiwiteitlek - waar verskeie valideerders vanlyn is - plaasvind.

   
   

Onder die huidige meganisme kan 'n kwaadwillige Bob Alice se valideerderbalans van 32 ETH tot 50 persent verminder deur boetes en slashings op te doen totdat die valideerder kragtig onttrek word van Beacon Chain konsensus (nadat sy effektiewe balans tot 16 ETH gedaal het). As ons 1 ETH = $2 000 gebruik, sal Bob se treuraanval Alice ten minste $32,000 (16 ETH) kos in 'n normale geval (geen gekorreleerde boetes nie) en $64,000 (32 ETH) in die ergste scenario (dws waar die hele balans kan gesny word as gevolg van korrelasie strawwe).

Hy wat 'n ding kan vernietig, beheer 'n ding. - Paul Atreides (Duin)

1. Eis 'n losprys van Alice in ruil daarvoor dat sy nie 'n snybare oortreding pleeg nie. Dit strook nie presies met die vorige definisie van hartseer nie, maar dink aan dat Bob se enigste uitweg is om ETH te verbrand as Alice besluit om hardebal te speel. Die situasie is dus anders as meer algemene tipes aanvalle waar die doel (altyd) is om wins te maak met minimale verlies.

Let wel: Bob (die knooppuntoperateur) kan eintlik eerlik wees in hierdie scenario, maar 'n teëstander kan die valideerdersleutel kompromitteer en Alice se ETH gyselaar hou. Dit verklaar die "teenparty-risiko" wat gebruikers van 'n staking-as-a-service (SaaS)-platform moet dra en is nog 'n rede waarom solo-staking - met sy "vertrou niemand behalwe jouself nie"-etos - as die goue standaard vir Ethereum-aanhangers beskou word .

Beteken dit dat elke nie-toesighoudende stakingdiens eintlik nie nie-toesighoudend is nie? Nie presies nie. 'n Eenvoudige oplossing is dat die stakingdiens vooraf 'n vrywillige onttrekkingsversoekboodskap onderteken - verkieslik sodra die valideerder op die Beacon Chain geaktiveer is - wat die staker onafhanklik aan 'n Ethereum-konsensusnodus kan indien wanneer hy wil onttrek.

Deur vrywillige onttrekkingsversoeke vir 'n belanghebbende vooraf te onderteken , keer die reëling tussen 'n belanghebbende en 'n nodusoperateur terug na die oorspronklike nie-bewaringsstatus. Vooraf ondertekende onttrekkingsversoekboodskappe is egter om baie redes nie volhoubaar nie:

Probleme met vooraf ondertekende onttrekkingsversoeke vir nie-toesighoudende staking

Kompleksiteit

Vooraf-ondertekende onttrekkingsversoeke-werkvloeie vereis meer kommunikasie tussen 'n stakingdiensoperateur en die spelafvaardiger: jy moet 'n versoek vir 'n onttrekkingsversoekboodskap indien en wag vir die stakingdiens om die ondertekende onttrekkingsversoeke te stuur. Daar is ook die probleem van sekuriteit wanneer vooraf ondertekende onttrekkingsversoeke gebruik en uitgeruil word:

• ’n Inzetdiens moet ekstra voorsorgmaatreëls tref—soos om die onttrekkingsversoekboodskap te enkripteer en dit oor ’n veilige (van die ketting) kommunikasiekanaal te deel—om te verhoed dat die onttrekkingversoekboodskappe in die verkeerde hande val.
• 'n Belanghebbende moet ekstra voorsorg tref om die onttrekkingsversoekboodskap op 'n veilige plek te stoor, aangesien die verlies van die onttrekkingversoekboodskap gelykstaande is aan die moontlike verlies van die vermoë om die valideerder se balans onafhanklik te onttrek.

Daarbenewens is vooraf ondertekende onttrekkingsversoeke tans geldig vir twee Ethereum-vurke of ~ 12 maande - as jy verwag dat vurke ongeveer elke ses maande sal plaasvind. Dit beteken dat 'n belanghebbende 'n versoek vir 'n vrywillige onttrekkingsversoek verskeie kere in 'n kalenderjaar by die stakingsdiensoperateur moet indien. Dit sal egter nie meer die geval wees wanneer EIP-7044 geïmplementeer word nie en ondertekende valideerder-onttrekkingsversoeke word egter onbepaald geldig.

EIP-7044 los die kwessie van uitgangboodskappe wat verval, reg, maar dit stel 'n nuwe stel probleme bekend—veral vir groot stakingpoele. Ter agtergrond, die huidige benadering in gedesentraliseerde stakingpoele is om te vereis dat nuwe valideerdernodusoperateurs vooraf ondertekende onttrekkingsversoeke indien voordat hulle deur die poel befonds word. Hier bied getekende onttrekkingsversoeke kripto-ekonomiese sekuriteit aangesien dit die mag wat 'n (onvertroude) operateur het oor valideerderfondse verminder; 'n stakingpoel kan die onttrekkingsversoek van 'n nie-samewerkende valideerdernodusoperateur aktiveer deur die vooraf-ondertekende onttrekkingsversoek in die ketting in te dien.

Maar 'n valideerder node-operateur sal nie juis gemaklik voel as vooraf-ondertekende onttrekkingsversoeke op 'n ewekansige bediener gestoor word nie as gevolg van die risiko dat iemand per ongeluk/doelbewus 'n valse onttrekkingsversoeke aktiveer deur die getekende uitgangboodskap in die hande te kry. In 'n ergste scenario sal gedwonge uitgange waarskynlik 'n verlies vir 'n validator node-operateur tot gevolg hê (bv. as jy 'n lening aangegaan het teen toekomstige Beacon Chain-belonings). Dit beteken dat poele selfs meer veiligheidsmaatreëls moet tref en onttrekkingsversoekboodskappe veilig moet stoor, veral in 'n post-EIP 7044-wêreld waar ondertekende onttrekkingsversoeke oneindige vervaldatums het.

'n Potensiële oplossing is om ondertekende onttrekkingsversoeke te enkripteer met 'n gedeelde publieke sleutel wat deur 'n DKG (Distributed Key Generation) protokol gegenereer word, en 'n kworum van sleutelaandele te vereis om die private sleutel te rekonstrueer voordat die onttrekkingsversoek gedekripteer kan word. Dit verminder die vertroue-aanname wat gepaard gaan met een party wat onttrekkingsversoeke stoor, mits niemand genoeg sleutelaandele beheer om die voorafgetekende onttrekkingsversoeke eensydig te dekripteer sonder insette van ander deelnemers nie. Maar 'n randsaak verskyn as een of meer private sleutelaandele misplaas, verlore of gesteel word - wat dit moeilik maak, of heeltemal onmoontlik, om die getekende onttrekkingsversoek te dekripteer as die onttrekking van 'n valideerder nodig word.

Regulerende nakoming

Staking dienste het baie ondersoek gekry van 'n alfabetsop van reguleerders, veral die SEC (Securities and Exchanges Commission) gelei deur crypto se openbare vyand nr. 1: Gary Gensler. Kraken het byvoorbeeld vroeër vanjaar sy toesighoudende staking-as-diens-operasie gesluit en $30 miljoen in boetes betaal vir “die aanbied van ongeregistreerde sekuriteite deur sy kripto-inzetplatform.”

In teorie is dit onwaarskynlik dat 'n nie-bewaringsdiens in die SEC se visier vasgevang sal word as gevolg van die nie-toesighoudende aard van sy reëling met die belangeienaar:

1. Die deposito van 32 ETH (of veelvoude van 32 ETH) vir die aktivering van 'n valideerder kom van 'n onttrekkingadres wat deur die belanghebbende beheer word - en die protokol identifiseer die onttrekkingsadres as die eienaar van die 32 ETH-deposito. Dit beteken dat 'n nie-bewaringsdiens nie die valideerder se balans kan onttrek en kliënte se geld met sy eie kan meng nie, soos Kraken deur die SEC daarvan beskuldig is.

In 'n beurs soos Kraken, is 'n gebruiker se beursiebalans "virtueel" aangesien alle kliëntefondse in een of meer beursies gehou word wat deur die beurs beheer word. As jy dus 32 ETH insit via 'n bewaardiens wat deur 'n beurs bestuur word, is wat jy regtig het 'n IOU van die beurs wat belowe om 32 ETH terug te betaal (plus 'n persentasie valideerderbelonings) wanneer jy ook al wil onttrek.

1. Stakers kan onafhanklik fondse onttrek deur vooraf ondertekende uitgange in te dien sonder om die risiko te loop dat 'n skelm staking-diens onttrekkings sal voorkom. Daarteenoor het 'n bewaringsdiens - veral 'n beurs soos Kraken - beheer oor 'n belanghebbende se bates en kan onttrekkings om arbitrêre redes blokkeer.

Hierdie twee feite vermy die behoefte aan "beleggerbeskerming"; Ek is nie 'n beleidskenner nie, so verskoon enige foute in hierdie lyn van redenasie. Maar daar is dalk nog 'n klein plooitjie of twee as jy vandag 'n institusionele, nie-toesighoudende stakingsdiens bedryf:

• Vir die kort (of waarskynlik lang) tydperk tussen die aktivering van 'n valideerder en die stuur van 'n vooraf-getekende vrywillige uitgang na die staker, beheer die staking-diens die 32 ETH - wat dit "toesighoudend" maak in die oë van 'n reguleerder. Verdere verergering van die probleem is die kort vervaldatums van vooraf ondertekende uitgange (pre-EIP 7044): tussen die tyd dat 'n nuwe uitgangboodskap onderteken en aan die staker gestuur word, het die valideerdernodusoperateur 'n mate van beheer oor die uitgesette ETH.
• Terwyl gereelde uitgangboodskappe aan die ketting uitgesaai word en publiek verifieerbaar is, moet 'n vooraf ondertekende uitgang geënkripteer en privaat buite die ketting tussen die nodusoperateur en staker gedeel word. Dit maak dit moeiliker vir 'n derde party soos 'n reguleerder om te verifieer dat die stakingdiens werklik 'n voorneme-tot-uittrede onderteken het as deel van die aanvanklike valideerderdeposito-ooreenkoms—of as die uitruiling herhaal het sodra die oorspronklike uittreeboodskap verstryk het (dws voor -EIP 7004).

Samevattend: vooraf ondertekende uitgange verlig 'n paar probleme met gedelegeerde staking, maar is nie genoeg om inzet op Ethereum trustloos, veilig en gedesentraliseerd te maak nie. Om die "nie-bewaring" terug te plaas in nie-bewaring, het ons 'n beter oplossing nodig - wat ons nou het, danksy EIP-7002. Daaropvolgende afdelings sal EIP-7002 in detail dek en die verskeie voordele van die EIP aanraak, sowel as moontlike kwessies wat met die implementering daarvan verband hou.

'n Oorsig van EIP-7002: Uitvoering-laag aktiveerbare onttrekkings

EIP-7002 los die hoof-agent-probleem in gedelegeerde staking op - waar belanghebbendes valideerdernodusoperateurs moet vertrou om onttrekkingsversoeke vooraf te onderteken, of toekomstige onttrekkingsversoeke te eerbiedig - deur 'n nuwe vrywillige onttrekkingsoperasie in te stel wat geaktiveer kan word met 'n valideerder se onttrekkingsbewys. Dit bemagtig belanghebbendes om ingesette ETH te onttrek sonder om staat te maak op die entiteit wat die valideerder se ondertekeningsleutel hou (dws die stakingsdiens in 'n gedelegeerde staking-opstelling) om onttrekkings te verwerk.

EIP-7002 se sleutelkenmerk is die bekendstelling van 'n stateful validator-onttrekkingsversoekkontrak wat 'n tou van validator-onttrekkingsversoeke in stand hou wat afkomstig is van die uitvoeringslaag. Met tussenposes word 'n aantal onttrekkingsversoeke uit die tou verwyder en by die uitvoeringsversoek van 'n Beacon Chain-blok gevoeg. Dit laat toe dat onttrekkingsversoeke vanaf die uitvoeringslaag in die konsensuslaag "ingespuit" word en as deel van Beacon Chain-bedrywighede verwerk word - soortgelyk aan hoe deposito's wat uit die depositokontrak ontstaan, van die uitvoeringslaag na die konsensuslaag oorgedra word vir verwerking.

Onttrekkingsversoeke is gereelde Ethereum-transaksies met die valideerderkontrakadres as die teiken en dui voorneme aan om 'n valideerder te onttrek (geïdentifiseer deur sy publieke sleutel). 'n Bekragtiger-onttrekkingsboodskap is geldig as (a) dit onderteken is deur die Ethereum-adres waarna verwys word in die valideerder se uitvoering-laag ( 0x01 ) onttrekkingsgeloofsbewys (b) die valideerder wat onttrek moet word, aktief is op die Beacon Chain. Hierdie tjeks word uitgevoer deur die konsensuslaag nadat die onttrekkingsversoek sy pad na Beacon Chain gemaak het; die valideerder-onttrekkingsversoekkontrak bevestig slegs as 'n onttrekkingsversoektransaksie genoeg gas betaal op die tydstip dat die onttrekkingsversoekkontrak deur 'n belanghebbende geroep word.

Alle uitvoering-laag-onttrekkingsversoeke word op dieselfde manier verwerk as 'n gereelde vrywillige onttrekkingsversoekoperasie wat vanaf die konsensus-laag geaktiveer word, wat onveranderlikes rondom die maksimum toelaatbare onttrekkingsversoeke van die aktiewe valideerder-onttrekkings bewaar. EIP-7002 se in-protokol-meganisme vir die oordrag van onttrekkingsversoeke tussen uitvoering- en konsensuslae verwyder ook die behoefte aan verbindings met 'n konsensusnodus om onttrekkingsversoeke te aktiveer (wat vereis word vir die onttrekking van bekragtigers met vooraf-ondertekende onttrekkingsversoeke). Valideerders kan nou befonds en onttrek word van dieselfde uitvoering-laag-adres, wat die benaming van die EIP verduidelik as "Execution-Layer Triggerable Onttrekkings".

Nadat ons gesien het hoe EIP-7002 op 'n hoë vlak werk, kan ons nou in die fynere besonderhede van die EIP delf. Die volgende afdeling sal die huidige spesifikasie van EIP-7002 dek en sleutelaspekte van die valideerder-onttrekkingsversoekmeganisme bespreek. As jy liewer die tegniese bespreking wil oorslaan en die voordele van die implementering van EIP-7002 wil verken, kan jy na die volgende afdeling spring—wat sommige van die verbeterings aan staking-gebruikerservaring (UX) wat EIP-7002 moontlik maak, uitlig.

Validator onttrekking versoek bedrywighede

Volgens EIP-7002 is 'n valideerder-onttrekkingsversoek (gedefinieer in pseudokode as add_withdrawal_request() ) 'n CALL na die valideerder-onttrekkingsversoek-kontrakadres. Die transaksieveld vir oproepe na die valideerder-onttrekkingsversoekkontrak het twee waardes:

• source_address : 'n 20-grepe waarde wat die onttrekkingsadres verteenwoordig wat die transaksie geïnisieer het
• validator_pubkey : 'n 48-grepe waarde wat die publieke sleutel verteenwoordig van die validator wat verlaat moet word

Nadat 'n belanghebbende die onttrekkingsversoekkontrak met die validator_pubkey as inset geroep het, voer die validator-onttrekkingsversoekkontrak die volgende bewerkings uit (ek sal die belangrikste dele van hierdie bewerking vervolgens deurgaan):

• Bevestig dat die transaksie genoeg gas betaal om EXIT_FEE te dek
• Verhoog die uittreeteller ( EXIT_COUNT ) met een vir die huidige blok
• Voeg die uitgangboodskap in die tou in
• Verhoog oortollige onttrekkings vir die huidige blok ( EXCESS_EXITS ) met een
• Betaal die beller terug—as hulle te veel vir gas betaal het—deur 'n toelae van 2300 gas aan te stuur ( EXCESS_RETURN_GAS_STIPEND )

'n Belangrike detail: die valideerder-onttrekkingsversoekkontrak kyk nie of source_address 'n geldige onttrekkingadres is vir die validator wat deur validator_pubkey geïdentifiseer is nie, en dit kontroleer ook nie of validator_pubkey . Dit ontbloot 'n subtiele sekuriteitskwessie wat kan ontstaan as 'n aanvaller die tou vul met boodskappe wat gedoem is om te misluk; dit is hoofsaaklik 'n treuraanval met die doel om die verwerking van wettige onttrekkingsversoeke te voorkom. EIP-7002 spreek hierdie probleem aan deur 'n dinamiese aanpassingsfooi op onttrekkingsversoektransaksies te hef (die onttrekkingsfooimeganisme word later bespreek).

Maksimum en teiken onttrekkings per blok

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK is die aantal uitvoering-laag-onttrekkingsversoeke wat in 'n Beacon Chain-blok ingesluit kan word. Hierdie waarde is tans op 16 gestel om soortgelyke bewerkings op die Beacon Chain te weerspieël, soos VoluntaryExit (uitgangsbewerkings wat direk vanaf die konsensuslaag geaktiveer word met 'n staker se valideerdersleutel).

Die spesifikasie merk ook op dat die stel van MAX_WITHDRAWAL_REQUESTS_PER_BLOCK op 16 die grootte van uitvoerladings – en by uitbreiding, die grootte van Beacon Chain-blokke – beperk en die bokoste van die verwerking van uittree-operasies op die konsensuslaag verminder. Dit is nuttig aangesien ons kan verwag dat sommige belanghebbendes sal voortgaan om valideerders te verlaat deur die huidige meganisme te gebruik om uitgange uit die konsensuslaag te aktiveer (dws via voorafgetekende uitgange of intydse vrywillige uitgangboodskappe).

TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK

EIP-7002 laat teoreties toe dat tot 16 uitvoering-laag-uitgangsbewerkings in 'n blok ingesluit word, maar teiken 'n meer konserwatiewe skatting van twee uitgange per blok. Volgens die spesifikasie is TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK op 2 gestel om die churn rate van valideerders te beperk en die onveranderlike op maksimum toelaatbare onttrekkings per epog te behou, gedefinieer deur die Beacon Chain se get_validator_churn_limit() funksie-selfs in situasies waar al die ETH in die omloop is.

Valideerder-onttrekkingsversoekwaglys

WITHDRAWAL_REQUEST_COUNT

WITHDRAWAL_REQUEST_COUNT is die aantal onttrekkingsversoeke wat in die huidige blok ingesluit is. Na elke suksesvolle oproep na die valideerder-onttrekkingsversoekkontrak, word die waarde van die WITHDRAWAL_REQUEST_COUNT veranderlike wat in die valideerderkontrak se berging gestoor is, verhoog met een (gedefinieer in pseudokode as increment_count() ).

Op enige tydstip sal die waarde van WITHDRAWAL_REQUEST_COUNT tussen TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK (2) en MAX_WITHDRAWAL_REQUESTS_PER_BLOCK (16) lê, afhangende van hoeveel onttrekkingversoekbewerkings by die blok se uitvoering loonvrag gevoeg word. WITHDRAWAL_REQUEST_COUNT is ook 'n invoer na die funksie wat die bedrag bereken wat betaal moet word deur 'n nuwe onttrekkingsversoekbewerking ( MIN_WITHDRAWAL_REQUEST_FEE ).

OORTUIGLIKE ONTTREKKINGSVERSOEKE

EXCESS_WITHDRAWAL_REQUESTS is die verskil tussen MAX_WITHDRAWAL_REQUESTS_PER_BLOCK en TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK - die aantal onttrekkingsversoeke wat deur die huidige blok ongebruik gelaat word. Soos genoem, kan elke blok 'n maksimum van 16 onttrekkingsversoeke insluit, maar teiken twee onttrekkingsversoeke in normale situasies, so EXCESS_WITHDRAWAL_REQUESTS is gelykstaande aan "die verskil tussen hoeveel onttrekkingsversoeke 'n blok teoreties kan verbruik en hoeveel onttrekkingsversoeke werklik gebruik word".

Die onttrekkingsversoekkontrak se oormaatteller word opgedateer op grond van die laaste blok se gebruik en is een faktor (onder andere) wat die fooi bepaal wat betaal word deur 'n transaksie wat die valideerder-onttrekkingsversoekkontrak oproep. Dit verseker dat onttrekkingsfooie geprys word volgens huidige gebruik, wat soortgelyk is aan EIP-1559 wat die base_fee vir 'n nuwe blok bereken word gebaseer op die verskil tussen die teikengaslimiet en die gas wat deur die vorige blok gebruik is.

WITHDRAWAL_REQUEST_QUEUE

WITHDRAWAL_REQUEST_QUEUE is 'n lys van alle hangende onttrekkingsversoeke (gerangskik in volgorde van aankoms) wat tans in die bekragtigingskontrak se WITHDRAWAL_REQUEST_QUEUE_STORAGE_SLOT (as WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT en WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT ) gestoor word. Die aantal onttrekkingsversoeke in die tou kan onbeperk wees, maar die MAX_WITHDRAWAL_REQUESTS_PER_BLOCK veranderlike koers beperk hoeveel hangende onttrekkingsversoeke in elke blok uit die tou gesit kan word.

Die tou vir onttrekkingversoeke handhaaf 'n "kop" en 'n "stert"-indeks - albei verwys bloot na die stel versoeke naby die begin en einde van die tou - wat na elke blok opgedateer word om rekening te hou met die verwerking van een of onttrekkingsversoeke. Dit is 'n eerste-in-eerste-uit (EIEU) tou, so versoeke word uitgevoer volgens wanneer dit by die tou gevoeg word - wat sekuriteitsimplikasies het, veral rondom die hartseer van eerlike valideerders.

Valideerder-onttrekkingskontrakfooie

MIN_WITHDRAWAL_REQUEST_FEE is die bedrag wat 'n adres wat die valideerder-onttrekkingsversoekkontrak aanroep om te onttrek wat 'n validator in gas moet betaal. Voordat 'n onttrekkingsversoek by die tou ingevoeg word, kontroleer die valideerder-onttrekkingsversoekkontrak dat die gasfooi verbonde aan die transaksie gelyk is aan of meer is as die huidige waarde van MIN_WITHDRAWAL_REQUEST_FEE - indien die transaksie gas oor het nadat dit suksesvol uitgevoer is, word die stuuradres met presies 2300 gekrediteer gas.

Volgens die spesifikasie volg hierdie ontwerp die nou afgekeurde kenmerk in Solidity, waar die fallback() funksie in 'n bestemmingskontrak of die stuur van ETH via transfer() of send() 'n toelae van 2300 gas aan die ontvanger stuur. Veranderinge in gaskoste (begin met die Berlyn/Istanbul vurk) het die nut van hierdie kenmerk verminder (lees Stop Using Solidity se oordrag() Nou vir 'n sekere konteks), maar die oorspronklike idee van 'n eenvoudige gasrekeningstelsel is steeds nuttig. In die konteks van EIP-7002, vereenvoudig die stuur van 'n vaste terugbetaling van 2300 gas die fooimeganisme vir die valideerder-onttrekkingsversoekkontrak.

Die alternatief is om 'n spesiale meganisme te ontwerp wat die onttrekkingsversoekkontrak toelaat om die maksimum hoeveelheid gas wat oorbly van 'n transaksie terug te gee. Dit sal sin maak, veral in gevalle waar die onttrekkingsadres 'n EOA-slimkontrakte is, kan presiese waardes vir MIN_WITHDRAWAL_REQUEST_FEE bereken deur die kontrak se toestand na te gaan, maar EOA's sal waarskynlik meer gas stuur vir elke oproep na die onttrekkingsversoekkontrak. Hierdie roete voeg meer kompleksiteit by die ontwerp van EIP-7002 teenoor die gebruik van 'n eenvoudige CALL om 'n vaste hoeveelheid gas aan te stuur as 'n terugbetaling; alhoewel, EIP-7002 se skrywers stel voor dat hierdie kenmerk by die finale spesifikasie ingesluit kan word, afhangende van terugvoer van belanghebbendes.

Die berekening van MIN_WITHDRAWAL_REQUEST_FEE is waar dinge interessant raak. Die onttrekkingsversoekfooi is dinamies en ontwerp om op die netwerktoestande te reageer, soortgelyk aan die basisfooi wat deur EIP-1559 ingestel is, en is 'n funksie van drie veranderlikes:

• Die minimum (basis) onttrekkingsfooi: MIN_WITHDRAWAL_REQUEST_FEE
• Aantal oortollige onttrekkings by die huidige blok: EXCESS_WITHDRAWAL_REQUESTS
• Die onttrekkingsversoekfooi-opdateringsformule: WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION

Soos EIP-1559 se base_fee , is die valideerder-onttrekkingskontrak se uittreefooi 'n koersbeperkende meganisme: in die gemiddelde geval (twee versoeke per blok), kan enigiemand wat die validator-onttrekkingsversoekkontrak bel, verwag om die minimum onttrekkingsfooi te betaal, maar die koste van 'n onttrekkingsoperasie verhoog geleidelik meer onttrekkingsversoeke word in 'n blok ingesluit. Dit kan afgelei word uit EIP-7002 se formele spesifikasie vir die opdatering van die onttrekkingsversoekfooi : withdrawal_request_fee = MIN_WITHDRAWAL_REQUEST_FEE * e**(excess_withdrawal_requests / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION)

'n Verduideliking van die onttrekkingsversoekfooimeganisme uit die spesifikasie:

“Die blok-vir-blok-gedrag is rofweg soos volg: As blok N X onttrekkingsversoeke verwerk, dan verhoog excess_withdrawal_requests aan die einde van blok N met X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK , en dus verhoog die onttrekking_versoek_fooi in blok N + 1 fooi met 'n e**((X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK) / (WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) Dit het dus 'n soortgelyke effek as bestaande EIP-1559, maar is meer "stabiel" in die sin dat dit op dieselfde manier reageer op dieselfde totale onttrekkingsversoeke, ongeag hoe dit versprei word. .”

Deur die onttrekkingsversoekfooi geleidelik te verhoog volgens die gebruik van die valideerder-onttrekkingsversoekkontrak, verminder EIP-7002 die risiko dat 'n aanvaller doelbewus die onttrekkingsversoektou vul om te verhoed dat ander valideerders onttrek. Herroepboodskappe in die tou vir onttrekkingversoeke word uitgestel en in eerste-in-eerste-uit (FiFo)-styl in teenstelling met, sê, laaste-in-eerste-uit (LiFo) of hoogste-betalende-transaksie-eerste orde. Alhoewel ons kan aanneem dat die gaspryse onnodige oproepe na die onttrekkingsversoekkontrak sal voorkom, is 'n kwaadwillige aanvaller dalk bereid om meer gas te betaal om die onttrekkingversoekry te “stop” en 'n ander bekragtiger se onttrekkingsversoek na die einde van die tou te druk.

Die probleem word verder vererger deur die sentralisering van blokbou in post-Merge Ethereum. As 'n aanvaller geïntegreer is met een of meer dominante bouers (vir konteks: 80-90% van blokke tot op hede op Ethereum is deur 4-5 bouers vervaardig ) en bereid is om te betaal vir bo-aan-die-blok-insluiting, sal hulle kan effektief onttrekkingsversoeke van een of meer belanghebbendes vooruit laat loop en tydige onttrekkings van valideerders uit die Bakenketting voorkom.

En hoekom sal iemand deur al daardie stres gaan? 'n Moontlike motivering kan wees dat die aanvaller belanghebbendes wil bedroef wat valideerders wil onttrek deur onttrekkingsgeloofsbriewe te gebruik. Om die vorige van Bob die (kwaadwillige) node-operateur en Alice die staker te gebruik: Alice kan vinnig haar valideerder onttrek om Bob se hartseer-aanval te stuit deur die validator-onttrekkingsversoekkontrak met die onttrekkingsgeloofsbewys te skakel - maar Bob kan homself steeds meer gee om Alice se lek valideerderbalans deur die validator-onttrekkingsversoekkontrak te spam en Alice se onttrekkingsversoek te vertraag.

Blokstruktuur en geldigheid

EIP-7002 verander die struktuur en die validering van Beacon-blokke effens deur te vereis dat onttrekkingsversoeke in die werklike liggaam van die blok geplaas word (en uitvoeringsloonvrag in die konsensuslaag). Versoeke moet in die uitvoering loonvrag ingebed word sodat wanneer konsensuslaag onbereikbaar is, die konsensuslaag steeds die nodige data het om die konsensusgedeelte van die staatoorgangsfunksie volledig uit te voer.

EIP-7002 voeg ook nuwe geldigheidsvoorwaardes vir blokke by. Eerstens kan die lys van onttrekkingsversoeke ( withdrawal_requests_list ) nie MAX_WITHDRAWAL_REQUESTS_PER_BLOCK oorskry nie. Tweedens moet die lys van onttrekkingsversoeke ooreenstem met die aantal onttrekkingsversoeke wat uit WITHDRAWAL_REQUEST_QUEUE gelaat is wanneer sulke versoeke in eerste-in-eerste-uit (FIFO) volgorde gerangskik word.

EIP-7002 het 'n funksie ( expected_exit ) om te bevestig dat 'n blok nie meer onttrekkingsversoeke insluit as die resultaat van die berekening van NUM_WITHDRAWAL_REQUESTS_IN_QUEUE - MAX_WITHDRAWAL_REQUESTS_PER_BLOCK nie. Ook sal 'n konsensusnodus wat die blok heruitvoer, onafhanklik die enkodering van onttrekkingsversoeke bereken deur request_type en request_data te herhaal in vergelyking met die verbintenis van die hash van onttrekking versoeklys.

Hoekom EIP-7002? Die saak vir uitvoering-laag aktiveerbare onttrekkings

Verminderde vertroue aannames in gedelegeerde staking

In die inleiding het ek opgemerk hoe vertroue op 'n valideerder se ondertekeningsleutel om validator-uitgange te inisieer die probleem van vertroue bekendgestel het; Ek het nie ’n definisie van vertroue ingesluit nie, maar hierdie definisie uit Vitalik se Trust Models- artikel som dit mooi op: “Trust is enige aanname(s) wat jy maak oor die gedrag van ander mense”. Deur aan te meld vir 'n staking diens, met die wete dat 'n kwaadwillige nodus operateur onttrekkings kan vries, vertrou 'n staker in wese die nodus operateur om getrou op te tree.

EIP-7002 verwyder nie die vertroue-element in gedelegeerde staking heeltemal nie - jy moet steeds 'n nodusoperateur vertrou om nie 'n treuraanval uit te voer nie - maar om belanghebbendes in staat te stel om te onttrek met onttrekkingsgeloofsbriewe, verminder die las van vertroue tot 'n mate. Byvoorbeeld, 'n gebruiker hoef nie te "vertrou" dat 'n nodusoperateur 'n vrywillige uitgangboodskap sal onderteken sodra hulle dit versoek nie.

'n Subtiele punt oor "vertroueloosheid" is dat dit nie noodwendig gaan oor die vermyding van die behoefte om te vertrou nie, maar oor die behoefte om nie te vertrou nie, want (a) daar is sterk aansporings vir alle partye om eerlik op te tree (b) eerlike partye het 'n mate van beskerming teen die optrede van oneerlike partye. Die vermoë om 'n valideerder met onttrekkingsbewyse te onttrek is 'n voorbeeld van laasgenoemde: Bob kan probeer om Alice te bedroef, maar nou het Alice die agentskap om haar validator te onttrek, hopelik voordat Bob nog skade aanrig.

Beter risikobestuur vir staking van poele

Tans het stakingpoele geen manier om 'n valideerdernodusoperateur te dwing om te onttrek nie - wat poelbydraers in die ongemaklike posisie plaas om nodusoperateurs te vertrou om eerlik op te tree. Sommige gedesentraliseerde stakingpoele vereis dat nodusoperateurs 'n verband verskaf, maar gegewe die moontlikheid dat 'n kwaadwillige operateur tot 0 ETH gesny word, kan die sekuriteit van 'n verband onvoldoende wees in die oë van 'n risiko-sku belanghebbende.

Met EIP-7002 in plek, kan stakingpoele trustaannames aansienlik verminder deur die sekuriteit van die bedreiging van die vermindering van 'n nodusoperateur se kollaterale aan te vul met prosedures om 'n wangedrag-operateur met geweld te onttrek deur 'n uitvoeringslaagonttrekking. Die moontlikheid van onttrekkingsgeloofsbriewe wat na 'n slimkontrakadres (in plaas van 'n EOA) verwys, maak ook nuwe voorvalreaksie-ontwerpe oop vir stakingpoele—byvoorbeeld, 'n slimkontrak kan outomaties 'n onttrekkingsversoek indien as 'n operateur hoër-as-gemiddelde boetes oploop binne 'n tydvenster. Dit vereis dat 'n orakel vertrou word om valideerderprestasie op te spoor, en 'n bewaardernetwerk om die slim kontrak te aktiveer.

Die ander hipotetiese voordeel vir 'n spelpoel van die implementering van EIP-7002 is om die behoefte om vooraf ondertekende onttrekkingsboodskappe aan te vra en te stoor, wat gepaard gaan met risiko's soos ek voorheen verduidelik het (bv. ongemagtigde toegang tot onttrekkingsboodskappe kan lei tot onverwagte bekragtiging onttrekkings). Dit dra ook by tot die doelwit van die ontwerp van trustlose staking-poele: in teenstelling met die staatmaak op vooraf ondertekende onttrekkingsversoeke wat deur 'n paar (vertroude) individue gestoor word, kan 'n slim kontrak wat as die onttrekkingsadres aangewys word beheer word deur bestuur wat die gemeenskap in staat stel om te besluit om 'n nodusoperateur publiek en deursigtig te onttrek.

Beter risikobestuur vir DVT-opstellings

Distribued validator-tegnologie (DVT) word om baie redes as 'n kritieke deel van Ethereum se staking-infrastruktuur beskou:

• DVT verminder struikelblokke vir solo-insette: Veelvuldige solo-spelers kan fondse saamvoeg om gesamentlik 'n valideerder te aktiveer sonder om elke ander party te vertrou. Veelparty-berekeningskemas (MPC) kan tot ⅓ foutiewe nodusse verdra—so as 'n hipotetiese verspreide valideerder 3-van-5 sleuteldelings vereis om die valideerder se ondertekeningsleutel te rekonstrueer, kan ondertekening plaasvind as twee DVT-nodusse vanlyn is.
• DVT verbeter foutverdraagsaamheid en veerkragtigheid vir institusionele/solo-opstellings: Soos hierbo genoem, kan 'n valideerder se ondertekeningsleutel in verskillende sleuteldelings verdeel word en slegs gerekonstrueer word wanneer ondertekening van blokdata vereis word. Dit verminder die risiko dat 'n kuberkraker die valideerder se ondertekeningsleutel in gevaar stel, of dat 'n belanghebbende toegang tot fondse verloor omdat die toestel wat die ondertekeningsleutel stoor, skade gely het.

DVT-opstellings hou egter steeds 'n mate van risiko vir belanghebbendes in as gevolg van die manier waarop onttrekkings en uitgange tans op die Beacon-ketting werk. As sommige DVT-nodusse sleuteldelings misplaas of weier om aan die drempelondertekeningskema deel te neem, word dit onmoontlik om 'n valideerder te verlaat - veral wanneer:

• Sleutelaandele vir elke deelnemer aan die DVT-opstelling word gegenereer ten tyde van die aktivering van 'n valideerder en kan nie na die aanvanklike DKG-seremonie "verfris" word nie (let daarop dat 'n "deelnemer" bloot 'n ander EOA kan wees wat deur dieselfde belanghebbende besit word); sommige DVT-protokolle laat wel toe dat nuwe sleutelaandele gegenereer word, alhoewel dit dalk vereis dat die oorblywende sleutelaandele aan die kworum van handtekeninge voldoen wat benodig word vir gereelde ondertekening.
• Die kworumdrempel – die aantal sleutelaandele wat nodig is om gesamentlik 'n geldige handtekening vir die verspreide valideerder te genereer – kan nie verander word sodra die (verspreide) valideerder aktief is nie.

Sonder EIP-7002 wat die opsie bied om 'n valideerder te onttrek deur die onttrekkingsleutel te gebruik, sal die voordeel daarvan om 'n DVT-opstelling onafhanklik of in samewerking met ander valideerders te bestuur, aansienlik verminder word (bv. 'n valideerderbalans kan vir ewig gesluit word). EIP-7002 bied 'n terugvalveiligheidsopsie vir verspreide valideerders: as die rekonstruering van die ondertekeningsleutel onuitvoerbaar is, kan die valideerder uit die Beacon-ketting onttrek word deur 'n onttrekkingsversoek in te dien wat onderteken is met die onttrekkingsleutel gerekonstrueer uit sleutelaandele.

Beter regulatoriese nakoming: Plaas die "nie-bewaringspligtige" in nie-bewaring

Dit is onwaarskynlik dat die skrywers van EIP-7002 dit uitdruklik uiteengesit het met die doel om dit makliker te maak om 'n gereguleerde institusionele staking-as-service maatskappy te bestuur. Desondanks help die EIP met die probleem om reguleerders te oortuig van 'n instelling se nie-bewaring van betrokke ETH. 'n Speloperateur in hierdie scenario kan bloot 'n hash van die depositotransaksie wat deur die belanghebbende se onttrekkingsleutel onderteken is, wat nou vrywillige uitgange kan onderteken en indien, aanbied as bewys dat fondse wat in 'n valideerder gedeponeer is, nooit op enige tydstip in sy bewaring is nie.

Ek het “enige tydstip” beklemtoon aangesien, voor EIP 7044, 'n nodusoperateur tydelik beheer oorneem van die valideerder se balans nadat die voorafgetekende uitgang verstryk. En selfs met EIP-7044 se ewigdurend geldige getekende uitgange, het nodusoperateurs steeds die bewaring van die 32 ETH wat vir 'n valideerder gedeponeer is vir die kort tydperk tussen die valideerder se aktivering en die staker wat 'n getekende uitgangboodskap van die staking diensoperateur ontvang het. EIP-7002 verwyder hierdie ongemaklike areas en verseker dat belanghebbendes (bewysbare) bewaring van fondse het regdeur die valideerder se lewensiklus—van die betreding van die Beacon-ketting tot die onttrekking en die stuur van fondse na die staker se onttrekkingadres.

Beter gebruikerservaring (UX) vir almal

'n Goeie verstandelike model vir EIP-7002 is om daaraan te dink as " rekeningabstraksie vir staking-infrastruktuur". Vir konteks is 'n valideerdersleutel (of ondertekeningsleutel) altyd 'n EOA en kom met dieselfde stel beperkings rondom privaatsleutelveiligheid en -gebruik wat gereelde Ethereum EOA's vandag raak:

• Valideerder (ondertekening) sleutels loop 'n groter risiko om gekompromitteer te word. Anders as onttrekkingsleutels wat in koue (vanlyn) berging gestoor word, word valideerdersleutels gestoor in warm beursies wat aan die internet gekoppel is – wat hulle vatbaar maak vir uitvissing-aanvalle. As 'n valideerder se ondertekeningsleutel gekompromitteer word, is stakers en gedelegeerde stakingverskaffers vatbaar vir die treurvektore wat in die inleiding beskryf word sonder enige terugvalplan - verder as "wag totdat die balans tot 16 ETH daal en die valideerder kragtig deur die protokol onttrek word".
• Validatorsleutels het beperkte opsies vir herstelskemas (verloor dit een keer = verloor dit vir altyd). Die verdeling van 'n valideerdersleutel in veelvuldige sleuteldelings via verspreide valideringstegnologie (DVT) kan hierdie risiko verminder, maar die bestuur van 'n solo DVT-inzetopstelling is nie-triviaal; plus, soos ek voorheen verduidelik het, is DVT nie 'n silwer koeël nie, aangesien sleutelaandele verlore kan gaan en die verfrissing van sleutelaandele bemoeilik.
• Valideerdersleutels kan nie meer buigsame steekontwerpe ondersteun nie. Verskillende stakingsdienste het outomatiese/buigsame werkvloeie ontwikkel vir befondsingsvalideerders as gevolg van die voordeel om onttrekkingsbewyse na slim kontrakte te verwys. Die onttrekking van 'n valideerder is egter 'n handmatige proses wat vereis dat 'n vrywillige onttrekkingsversoekboodskap onderteken word - die proses kan geoutomatiseer word deur 'n slim kontrak wat pre-signex-onttrekkingsversoeke stoor, maar dit kom met sekere vertroue-aannames en sekuriteitsoorwegings wat voorheen verduidelik is.

Ons kan die meeste - of ten minste sommige - van hierdie probleme oplos sodra onttrekkingsleutels in staat is om valideerders te verlaat. Vir dit om te werk, sal 'n staker (of staking poel) 'n eenmalige verandering van 0x0 onttrekking geloofsbriewe moet voltooi na 0x01 onttrekking geloofsbriewe - terwyl 0x0 geloofsbriewe by verstek 'n BLS (EOA) sleutel is, kan 0x01 geloofsbriewe na enige Ethereum verwys adres, insluitend slim kontrakte en EOA's. Om 'n slim kontrak as die onttrekkingsadres vir 'n valideerder te stel, is wonderlik om die gebruikerservaring (UX) van staking te verbeter:

1. Onttrekkingsleutels kan buigsame herstelmeganismes hê, soos sosiale herstel. 'n Belanghebbende sal een of meer "voogde" hê wat 'n nuwe sleutel kan magtig om die onttrekkingsversoek-slimkontrak te beheer as die oorspronklike sleutel gesteel of verloor word - voogde kan vriende, familielede, mede-aanhangers of 'n gespesialiseerde derdepartydiens wees. Buigsaamheid in herstelmeganismes kan veral solo-spelers bevoordeel; jy kan 'n dooiemanskakelaar hê wat 'n EL-uitgang aktiveer en fondse na 'n aangewese adres stuur as jou valideerder vir 'n voorafbepaalde tydperk ophou om te getuig (bv. omdat jy "oorgegaan het na die Groot Anderkant").

2. Buigsame steekontwerpe kan na vore kom. Byvoorbeeld, 'n risiko-sku belanghebbende kan 'n 2-van-2 multisig-onttrekkingskontrak verkies—met die staker en nodusoperateur wat een van die twee sleutels hou wat nodig is om onttrekkingsversoeke goed te keur—in plaas daarvan om die hele onttrekkingsleutel te stoor. Dit is steeds nie-toesighoudend ('n nodusoperateur kan nie die valideerder verlaat sonder goedkeuring nie), alhoewel dit vereis dat die knooppuntoperateur vertrou word om nie 'n validator se uitgang te blokkeer deur te weier om onttrekkingsversoektransaksies te onderteken wat deur die belanghebbende voorgestel word nie.

Vir steekpoele kan buigsaamheid in steekontwerpe die implementering van onttrekkingskontrakte met arbitrêre logika beteken vir die opdatering of oordrag van eienaarskap van valideerders. In die afwesigheid van EIP-7002, is die enigste werklike manier waarop 'n stakingpoel eienaarskap van valideerders kan bestuur, om voorafgetekende onttrekkingsversoeke rond te skuif, wat met verskeie risiko's en randgevalle gepaard gaan.

3. Validator-onttrekkings kan veilig geoutomatiseer word. In teenstelling met die stoor van voorafgetekende onttrekkingsversoeke in 'n slim kontrak, kan onttrekkingsversoekkontrakte komplekse reëls hê wat valideerder-onttrekkingsversoeke beheer; 'n "mal wetenskap" idee is 'n "tyd-gebaseerde staking pool" waar nodus operateurs vertroueloos geroteer word. Of oorweeg of 'n groot stakingpoel soos Lido wil desentraliseer: bestuur kan kies om sommige valideerders wat deur 'n groot nodusoperateur beheer word, te onttrek en fondse na kleiner operateurs (of solo-spelers) te herverdeel om verstikkingspunte te verminder van 'n nodusoperateur wat 'n aansienlike aantal valideerders.

Dit is net 'n paar van die vroeë moontlikhede wat EIP-7002 moontlik maak, maar ek is baie seker dat meer toepassings sal verskyn - net soos hoe nuwe kenmerke en gebruiksgevalle vir slim beursies op Ethereum steeds na vore kom. As jy hierdie lees en meer konkrete idees het om EIP-7002 op steekontwerpe toe te pas, kan jy gerus die opmerkings lui!

Is daar enige nadele aan die implementering van EIP-7002?

Potensiële breekveranderings aan bestaande steekontwerpe

In die konsep EIP erken die skrywers van EIP-7002 potensiële kommer oor die moontlikheid van onttrekkingsgeloofsbriewe om validator-onttrekkings te aktiveer - maar gaan voort om te sê, "ons weet nie van enige spelontwerpe wat op hierdie kenmerk staatmaak nie [dws onvermoë om te onttrek nie met onttrekkingsbewyse]”. Dit lyk redelik - selfs ek het 'n bietjie gesukkel om te redeneer oor enige gedelegeerde stakingsreëling wat hierdie kenmerk sou vereis. Maar net omdat dit nie voor die hand liggend lyk nie, beteken dit nie dat dit nie daar is nie.

“Luister na daardie stil, knaende twyfel. As jy nie weet nie, weet jy nie wat jy nie weet nie, jy weet nie hoeveel jy nie weet nie, en jy weet nie hoeveel jy nodig gehad het om te weet nie.” — Eliezer Yudkowsky

Om 'n bietjie konteks te verskaf, sal ek skermkiekies van 'n gesprek insluit rondom 'n vroeë voorstel om onttrekkingsbewysgoedgekeurde uitgange via 'n Algemene Boodskapbus (GMB) te implementeer . Die GMB is 'n stelselvlak slim kontrak waarvan die gebeure deur kliënte gelees en verwerk word, soos die huidige depositokontrak, en in staat is om boodskappe van die uitvoeringslaag na die konsensuslaag oor te dra. Terwyl die skrywer(s) na meer generiese EL-na-CL-boodskaptipes gesinspeel het, was die belangrikste voorgestelde gebruiksgeval van die EL-na-CL-boodskapbus 'n manier om uitgange uit die uitvoeringslaag te aktiveer via 0x01-onttrekkingsgeloofsbriewe.

Uit hierdie uitruiling het ons reeds 'n voorbeeld van 'n staker-node-operateurverhouding gebou op die aanname dat die staker nie kan verlaat en 'n valideerder kan onttrek deur die onttrekkingsleutel te gebruik nie. Nog 'n voorbeeld van 'n potensiële randgeval van die implementering van EIP-7002 kom uit 'n gesprek oor Lido se desentralisasieplanne op die Lido Community Staking Podcast, wat jy op YouTube kan kyk . (EIP-7002 word slegs kortliks (28:55 tot 30:00) in die video genoem).

Ter agtergrond, Lido is beskryf as 'n "sistematiese bedreiging vir Ethereum" omdat dit ~ 33.3% van Beacon Chain valideerders beheer en Ethereum se konsensus in gevaar kan stel; byvoorbeeld, as die Lido DAO knooppuntoperateurs gedwing het om transaksies te sensor, of om voorheen afgehandelde blokke terug te keer (Mike Neuder se Magnitude en rigting van Lido-aanvalvektore beskryf die bedreiging in meer besonderhede).

Een van die sprekers in die voorheen gekoppelde episode voer egter die dwingende argument dat hierdie aanvalvektor - die DAO wat nodusoperateurs kragtig koöpteer in 'n aanval op die Ethereum-protokol - nog nie bestaan nie, aangesien nodusoperateurs 'n agentskap het. Die DAO kan die belang van 'n valideerder weerhou nadat dit verlaat het, maar kan nie staatmaak op die dreigement van 'n gedwonge uitgang om 'n valideerder te dwing om Ethereum se konsensus aan te val nie.

Met EIP-7002 verander die kragdinamiek aansienlik: onttrekkingskontrakte wat deur die DAO beheer word, kan 'n operateur teen sy wense onttrek - wat die DAO hefboomwerking gee oor nodusoperateurs. Hierdie tipe hefboom is nuttig om 'n staking-protokol teen 'n kwaadwillige operateurstel te beskerm, soos ek voorheen verduidelik het. Maar dit kan ook in die volgende scenario's misbruik word:

• Die staking-protokol kry 'n bestuursaanval en die DAO voer 'n kwaadwillige voorstel aan om 'n valideerder se onttrekking uit die onttrekkingskontrak te aktiveer
• 'n Aanvaller neem beheer oor een of meer valideerders deur eienaarskap van die onttrekkingsversoekkontrak te kap en voer 'n suksesvolle afpersingstrategie uit

Dit is nog 'n voorbeeld van hoe EIP-7002 bestaande aannames in steekontwerpe kan verander - hierdie keer vir nodusoperateurs wat namens 'n steekpoel soos Lido bekragtig. Nietemin kan hierdie aanvalvektor maklik versag word deur verskillende metodes soos die gebruik van veilige, streng geouditeerde en moontlik nie-opgradeerbare, onttrekkingsversoekkontrakte of die navolging van beste praktyke vir veilige DAO-bestuur .

Om rekening te hou met die randgeval waar 'n nodusoperateur verliese ly weens 'n gedwonge onttrekking nadat hy 'n aanvaller se eise geweier het om protokolreëls te oortree, kan stakingpoele inspirasie van eiendomsmaatskappye neem om nodusoperateurs te beskerm:

• Voordat 'n huurkontrak onderteken word, moet huurders 'n "sekuriteitsdeposito" verskaf. Die deposito word in 'n bankrekening buite die beheer van die eiendomsmaatskappy gehou.
• Indien die huurder uit die woonstel trek, maar aansienlike skade agterlaat, is die eiendomsmaatskappy daarop geregtig om die sekuriteitsdeposito te gebruik om die koste van herstelwerk te dek.
• Indien die woonstel in 'n goeie toestand is ten tyde van 'n huurder se uitgang, word die sekuriteitsdeposito ten volle aan die huurder terugbetaal.

'n Uitsteekprotokol kan 'n soortgelyke benadering aanneem om nodusoperateurs te beskerm deur 'n "nodusoperateurversekeringsfonds"-polis uit te neem via Nexus Mutual , Tidal Finance , of enige ander kripto-inheemse versekeringsplatform. Indien 'n operateur se valideerder wettiglik onttrek word, word die versekeringsfonds aan die DAO terugbesorg; as die omgekeerde waar is (bv. 'n valideerder se onttrekking word veroorsaak deur 'n kwaadwillige voorstel of onttrekkingskontrakfout), betaal die versekeringspolis skadevergoeding aan die nodusoperateur uit. Let daarop dat hierdie benadering veralgemeen kan word na enige bestaande verhoudings wat staatmaak op die huidige spesifikasies om 'n valideerder te verlaat.

Gebrek aan ondersteuning vir meer komplekse EL-tot-CL-boodskappe

EIP-7002 se valideerder-onttrekkingsversoekkontrak bied 'n enkele funksionaliteit: stuur 'n onttrekkingsversoek vanaf Ethereum se uitvoeringslaag na die konsensuslaag om 'n valideerder te onttrek. Sommige het egter voorgestel dat 'n algemene boodskapraamwerk (bv. 'n SendMessageToConsensusLayer voorsamestelling, of die Generalized Message Bus (GMB) stelselvlakkontrak wat voorheen genoem is) implementeer om generiese tipes boodskappe tussen die uitvoeringslaag en konsensuslaag deur te gee. Dit kan voordele inhou soos om nuwe maniere te ontsluit om valideerders op die Beacon Chain te aktiveer, veral as die heg van ETH aan EL-tot-CL-boodskappe toegelaat word.

Soos Danny Ryan (een van EIP-7002 se skrywers) egter in 'n opmerking verduidelik , is die besteding van waardevolle ingenieurstyd aan 'n generiese boodskap EL → CL-raamwerk 'n "groot onderneming met onduidelike waardeproposisie". Ter illustrasie het die skrywers van die GMB (General Message Bus)-voorstel slegs een ander gebruiksgeval vir 'n boodskapbus tussen die EL en CL geïdentifiseer: roterende onttrekkingsgeloofsbriewe vir 'n valideerder van 0x0 tot 0x01 geloofsbriewe.

Dit beteken dat ons meer geneig is om te sien dat die valideerder die versoekkontrak intrek voordat kernontwikkelaars praat oor die implementering van 'n algemene EL-na-CL-boodskapbus, as dit ooit sal gebeur. Nie dat dit ooit seer is om dinge eenvoudig te hou nie.

Eenvoud is 'n voorvereiste vir betroubaarheid. — Edsger W. Dijkstra

Nuwer risikovektore vir bestaande belanghebbendes

Ek het uitgebrei oor die voordele om onttrekkingsbewyse in staat te stel om 'n onttrekking vir die grootste deel te aktiveer, maar daar is 'n paar randgevalle wat met daardie kenmerk geassosieer word. Die idee gaan soos volg (h/t na hierdie opmerking op GitHub ):

• As 'n valideerder se ondertekeningsleutel gekompromitteer word, kan 'n kuberkraker losprys eis, of probeer om die valideerder se balans te verminder - maar dit kan onder geen scenario fondse onttrek nie. 'n Wagspeletjie sal volg: Sal die aanvaller die hele balans vernietig, of sal die spelers 'n deel van die spel kan onttrek sodra die valideerder met geweld onttrek is?
• Sodra EIP-7002 egter geïmplementeer is, kan die kuberkraker in die vorige scenario voortgaan om die valideerder te verlaat en die balans te onttrek (sodra EIP-7002 geïmplementeer is) in plaas daarvan om met 'n rou-/afpersaanval te skik.

Kortom, solo stakers en staking dienste sal meer beskerming nodig hê vir onttrekking geloofsbriewe post-EIP 7002. Dit is hoekom aanvaarding van sosiale herstel, multifaktor (MFA) verifikasie, en sleutel rotasie as krities beskou word vir die verbetering van sekuriteit vir solo/gedelegeerde staking bedrywighede.

Keuse van koersbeperkingsmeganisme

Die valideerder-onttrekkingsversoekkontrak add_withdrawal_request() funksionaliteit voer geen bykomende kontrole uit nie, behalwe om die aangehegte onttrekkingsversoekfooi na te gaan, wat moontlik 'n aanvaller toelaat om die boodskap-tou te verstop met ongeldige onttrekkingsversoeke (bv. uitgangboodskappe vir 'n nie-bestaande valideerder of 'n onaktiewe valideerder sal ongeldig gemaak word tydens die konsensuslaag se geldigheidskontroles). EIP-7002 gebruik 'n dinamiese geprysde onttrekkingsfooi om onttrekkingsversoeke te beperk en sulke aanvalle duur te maak, soortgelyk aan hoe EIP-1559 strooiposaanvalle ontmoedig en vulsel blokkeer deur gaspryse aan te pas op grond van netwerkaktiwiteit.

'n Alternatiewe ontwerp is om oproepe na valideerder-onttrekkingsversoekkontrak te beperk tot werklike valideerders - byvoorbeeld deur te kontroleer dat validator_pubkey ooreenstem met die publieke sleutel van 'n aktiewe Beacon Chain-valideerder. Dit kan EIP-7002 se ontwerp vereenvoudig deur die behoefte aan 'n komplekse, EIP-1559-styl prysmeganisme te verwyder en, moontlik, die onttrekkingsversoekfooi te verminder, aangesien die strooipos met vals versoeke minder van 'n probleem kan wees.

Dit vereis egter dat die uitvoeringslaag vertroueloos toegang kan verkry tot inligting oor die konsensuslaag - om validator_pubkey te kontroleer teen die Beacon Chain se valideerderregister - 'n kenmerk wat afhang van die implementering van EIP-4788. Dit voeg meer kompleksiteit by EIP-7002 en stel 'n nuwe afhanklikheid tussen die twee EIP's in, wat implikasies kan hê vir toekomstige ontwerpverbeterings soos aangedui in hierdie afdeling van EIP-7002 se rasionaal .

Selfs al is EIP-4788 geïntegreer met EIP-7002, sal ons steeds bykomende meganismes nodig hê om ander vorme van strooipos te voorkom wat wettige valideerders behels; 'n voorbeeld is die indiening van verskeie onttrekkingsversoeke vir dieselfde valideerder in 'n baie kort tydperk. Dit op sy beurt noodsaak die byvoeging (en afdwinging) van 'n nuwe reël soos "jy kan slegs een onttrekkingsversoek per valideerder elke 3-4 maande indien", wat selfs meer veranderinge aan die validator-onttrekkingsversoekkontrak kan vereis.

Daarteenoor is die huidige koersbeperkingsmeganisme maklik om oor te redeneer en waarborg dit genoeg beskerming teen die meeste sekuriteitskwessies wat verband hou met uitvoering-laag-onttrekkings. Byvoorbeeld, die onttrekkingsversoekfooi kan outomaties opwaarts aanpas om hartseer (poging om te verhoed dat eerlike valideerders onttrek) en strooipos en DOS-aanvalle (probeer om die Bakenketting te oorlaai deur konsensusnodusse te dwing om hulpbronne te mors op die filter van ongeldige onttrekkingsbedrywighede) af te weer.

Gevolgtrekking: EIP-7002 en die toekoms van belang op Ethereum

Gedelegeerde staking het die afgelope maande aansienlike kritiek ontvang, maar dit is veilig om te aanvaar dat die staking-as-'n-diensbedryf hier is om te bly. Indien wel, is dit belangrik om die risiko te verminder vir individue wat belang delegeer - hetsy na 'n likiede stakingpoel of 'n institusionele nie-bewaringsdiens. EIP-7002 bereik hierdie doelwit deur 0x01-onttrekkingsbewyse te maak wat valideerders kan verlaat en belang onttrek en die behoefte aan belanghebbendes om 'n nodusoperateur se eerlikheid te vertrou, verminder.

EIP-7002 het ook ander positiewe oorvloei-effekte. In die besonder, die verbetering van die veerkragtigheid en sekuriteit van solo-staking-bedrywighede en verspreide valideerders - deur beter herstel van verlies van 'n validator-sleutel of DVT-sleuteldelings moontlik te maak - behoort die hindernis tot solo-staking te verminder en belangsentralisasie op Ethereum te verminder.

Soos gewoonlik, sal ek afsluit deur jou te vra om te oorweeg om hierdie artikel te deel met iemand wat dit dalk insiggewend vind en, nog belangriker, teken in op Ethereum 2077 vir meer diep duik oor alles wat Ethereum R&D betref. Jy kan ook met my op Twitter kontak maak om opmerkings of terugvoer oor hierdie artikel te deel.