EIP-7002: una millor manera de participar a Ethereum

La transició d'Ethereum de Proof of Work (Pow) a Proof of Stake (PoS), també conegut com The Merge, va ser un moment clau en la història de la xarxa. A més de donar a Ethereum un canvi de marca molt necessari reduint la seva petjada de carboni, Proof of Stake va ser crucial per a un objectiu clau a llarg termini: reduir la barrera per participar en el consens d'Ethereum. La fusió va substituir els recursos computacionals (potència minera) amb capital financer com a base de la seguretat econòmica d'Ethereum, obrint l'oportunitat perquè qualsevol pugui executar de manera rendible i senzilla un node validador amb 32 ETH a la cadena Beacon.

Tot i que Proof of Stake ha aportat beneficis, encara hi ha moltes àrees de millora. Alguns d'aquests inclouen:

• Reducció de la centralització de l'aposta i la cartelització del validador
• Minimitzar la sobrecàrrega operativa dels validadors i incentivar l'aposta individual
• Millorar l'economia d'aposta i l'experiència d'usuari (UX)
• Millorar la senzillesa, la seguretat i la descentralització de les operacions de participacions delegades i multipartit

EIP-7002: Execution Layer Triggerable Retirements és una nova proposta de millora d'Ethereum (EIP) que soluciona alguns dels problemes esmentats anteriorment. L'EIP introdueix un mecanisme perquè els participants puguin retirar validadors de la cadena de balises que utilitzen credencials de retirada en lloc de confiar en la clau de signatura d'un validador per activar operacions de retirada, desacoblant de manera efectiva la clau de signatura d'un validador de la clau de retirada.

Aquesta "separació de preocupacions" entre les claus de signatura del validador i les claus de retirada té un avantatge crític: reduir els supòsits de confiança en la participació delegada permetent que les credencials de retirada mantinguin el control de l'ETH apostat. Exploraré per què aquesta característica és necessària al llarg d'aquest article i parlaré d'altres avantatges de l'EIP-7002, especialment per a l'apostament en solitari i la DVT (tecnologia de validació distribuïda). L'article també considerarà alguns inconvenients potencials d'implementar EIP-7002 a Ethereum.

Submergem-nos!

Preparant l'escenari: una història de claus, guants blancs i dolor (ing)

Si voleu apostar l'ETH i validar la cadena Beacon avui, teniu dues opcions principals: aposta individual i delegada; hi ha altres vies per apostar ETH, però aquestes retirades més o menys en un espectre entre les opcions esmentades. L'aposta en solitari és senzilla:

• Dipositeu 32 ETH al contracte de dipòsit de Beacon Chain per activar un nou validador
• Generar claus per dur a terme tasques de validador (verificació de transaccions, certificació de blocs, agregació d'attestacions i proposta de blocs)
• Configureu un node validador i sincronitzeu un client de capa d'execució (EL) i de capa de consens (CL)
• Mantingueu el vostre validador en línia i funcioni correctament per evitar sancions

Hi ha més passos (les PMF del validador de Staking Launchpad tenen una visió general fantàstica per als validadors potencials), però aquests són aproximadament els aspectes més importants de llançar un validador. És important destacar que l'aposta en solitari no requereix cap intermediari ni contrapart i us permet mantenir el 100% de les recompenses rebudes per validar (acreditar els blocs i proposar blocs) a la cadena Beacon. Però no és un dinar gratuït: teniu la responsabilitat de gestionar el vostre validador i necessitareu un cert nivell d'experiència tècnica per executar una operació d'aposta en solitari.

Si la idea de gestionar un validador sembla difícil, podeu seguir la ruta de staking delegat. Encara sou responsable de proporcionar 32 ETH per registrar un validador nou; només ara, delegueu la responsabilitat d'utilitzar el validador a un tercer. L'operador del node validador està proporcionant el que alguns descriurien com un "servei de guants blancs" i requereix una compensació per aquest servei. Per exemple, és possible que se us demani que compartiu una part de les recompenses del vostre validador amb l'operador del node com a part de l'acord inicial.

La part "guant blanc" significa que l'operador assumeix la responsabilitat de mantenir el validador operatiu i segur, el que significa que podeu fer coses com ara reproduir Netflix un divendres a la nit (o el que feu durant el vostre temps lliure) sense preocupar-vos de les penalitzacions per faltar a les tasques de validador. o preocupar-se per la seguretat de les claus del validador.

Tanmateix, hi ha una advertència: la participació delegada requereix confiar en l'operador del node per evitar posar en risc els vostres 32 ETH cometent una ofensa que es pugui reduir (p. ex., signar dos blocs en conflicte) o robar els vostres fons. És molt demanar, i definitivament no per a persones amb problemes de confiança, però la disposició funciona bé la majoria de vegades quan els operadors de nodes són honestos.

Però Ethereum no es va basar en l'ethos "confia en mi germà" de web2, i és per això que veus que "sense confiança" i "desconfiança" apareixen amb freqüència a les converses a cripto-Twitter i Reddit. L'aposta delegada en la seva forma més pura entra en conflicte amb aquest ethos, però hi ha una solució alternativa a la manera com es generen els parells de claus durant el procés d'activació d'un validador nou.

Cada validador té dues claus: una clau de retirada i una clau de validació. La clau de retirada és una parella de claus pública-privada necessària per retirar parcialment o completament el saldo d'un validador de Beacon Chain depenent de si voleu "descremar" (retirar només recompenses) o "sortir" (retirar el saldo de 32 ETH + recompenses) . Tingueu en compte que la clau de retirada s'ha d'actualitzar des de les credencials BLS ( 0x00 ) predeterminades a les credencials 0x01 que apunten a una adreça d'Ethereum per permetre la retirada parcial o total del saldo d'un validador.

La clau de retirada es genera en el moment del dipòsit a través d'una interfície com el Staking Launchpad i es calcula per crear un identificador de retirada que s'inclou a les dades de dipòsit del validador, que proporciona a la cadena Beacon informació sobre qui va dipositar el 32 ETH. La infografia següent de Protecció de claus de retirada per Attestant ofereix una gran visió general de com s'integra la clau de retirada al procés de sol·licitud de dipòsit del validador:

La clau del validador és un parell de claus públic-privat necessari per executar les funcions que s'espera de cada validador d'Ethereum, principalment votar blocs i proposar blocs perquè els altres votin ("votar" i "acreditar" s'utilitzen indistintament, però fan referència al mateix concepte). de verificar les transaccions i confirmar la validesa dels blocs). La clau pública del validador serveix com a identitat criptogràfica única al protocol de consens d'Ethereum, mentre que s'espera que la clau privada s'amagui i s'utilitzi per signar dades de bloc (les claus del validador també es descriuen com a claus de signatura per aquest motiu).

Ara, per veure la diferència principal entre les claus de validació (signatura) i les claus de retirada:

La clau de signatura d'un validador s'utilitza amb freqüència (penseu cada 6,5 minuts o la durada d'una ranura durant la qual cada validador serà seleccionat per certificar o proposar un bloqueig) i és millor mantenir-lo en un lloc en línia i de fàcil accés com una cartera calenta. No obstant això, una clau de retirada s'utilitza amb menys freqüència i es pot mantenir en un lloc segur i fora de línia com una cartera freda fins que un participant vulgui retirar fons de l'adreça de retirada associada a un validador concret.

Aquesta distinció és crucial per reduir els supòsits de confiança en una configuració de staking delegat: com que la clau de retirada no és necessària per a les tasques de validació, un staker pot mantenir el control de l'ETH apostat compartint la clau de validació amb l'operador del node i mantenint la clau de retirada. D'aquesta manera, un operador canalla no pot fugir amb els fons d'un staker després de retirar el saldo d'un validador sense l'aprovació del staker.

Els acords de participació delegada, on l'apostador té la clau de retirada, es descriuen normalment com a "no custòdia" per reflectir que l'entitat que opera el node validador en nom de l'apostador, finalment, no té control sobre l'ETH apostat. Això contrasta amb les solucions de custòdia en què el servei de staking controla tant les claus de signatura com de retirada; "Servei de guants blancs amb esteroides" és un bon model mental per a l'apostament de custòdia: un staker simplement proporciona 32 ETH per finançar el validador i delega tota la resta, inclosa la iniciació de sol·licituds de dipòsit del validador i l'emmagatzematge de claus de retirada, al servei de staking).

La separació de les claus de signatura del validador de les claus de retirada soluciona teòricament el problema de la confiança en els acords de participació delegada. A la pràctica, la relació entre l'operador del node i el staker en una configuració de staking no custòdia encara té un element de confiança a causa del mecanisme actual per retirar un validador i desencadenar una retirada total o parcial del saldo del validador a l'adreça de retirada.

Per retirar un validador de la cadena de balises, s'ha d'enviar un "Missatge de sortida voluntari" (VEM) signat amb la clau del validador per al seu processament a la capa de consens. Un cop inclòs en un bloc (cada bloc pot incloure un màxim de 16 operacions de sol·licitud de retirada), el missatge de retirada s'afegeix a la cua de sol·licituds de retirada , amb el retard de la retirada final influenciada per factors, com ara y el nombre de retirades a la cua o taxa de rotació del validador.

Vaig posar èmfasi en el requisit de signar una sol·licitud de retirada voluntària amb la clau de signatura del validador per destacar un problema amb les solucions de staking "no de custòdia" existents: un staker ha de confiar en l'operador del node, que controla la clau del validador necessària per signar un VEM, per processar les sol·licituds de retirada. Això torna a introduir de manera efectiva la confiança en la relació entre els operadors de nodes i els serveis de staking; pitjor, posa els stakers en risc de ser "afligits" per operadors de nodes maliciosos.

En un atac de dol , l'objectiu de l'atacant és causar pèrdues a l'altra part, no necessàriament beneficiar-se directament. Per posar-ho en context, considereu l'escenari en què l'Alice delega a Bob per operar un validador en nom seu, però decideix retirar els seus 32 ETH més tard. Bob podria acceptar la sol·licitud de l'Alice i activar una sol·licitud de retirada signant un missatge de sortida voluntària (VEM)... o negar-se a signar el missatge de sol·licitud de retirada i aturar l'operació de retirada de l'Alice. En Bob no es beneficiarà directament de rebutjar la sol·licitud de l'Alice; tot el que pot fer és mantenir l'"ostatge" de l'ETH d'Alice negant-se a ajudar l'Alice a retirar el seu validador.

D'acord, això no és 100% precís; Bob pot fer moltes coses dolentes per causar a Alice encara més "dol":

1. Reduïu el saldo del validador de l'Alice cometent deliberadament una infracció tallable o incorrent en sancions. La sanció individual per incomplir els deures del validador (per exemple, faltar certificats) o per cometre una infracció tallable (per exemple, signar dos blocs conflictius a la mateixa franja) sol ser baixa, però augmenta en proporció al nombre de validadors que cometen infraccions similars en el mateix període. . Per exemple, la falta d'una o dues certificacions reduirà el saldo d'un validador en una petita fracció, però aquesta reducció augmenta de manera exponencial si es produeix una filtració d'inactivitat , on diversos validadors estan fora de línia.

   
   

Sota el mecanisme actual, un Bob maliciós pot reduir el saldo del validador d'Alice de 32 ETH fins a un 50 per cent incorrent en sancions i retallades fins que el validador es retiri per força del consens de Beacon Chain (després que el seu saldo efectiu baixi a 16 ETH). Si utilitzem 1 ETH = 2.000 $, l'atac de dol de Bob li costarà a Alice almenys 32.000 $ (16 ETH) en un cas normal (sense penalitzacions correlacionades) i 64.000 $ (32 ETH) en el pitjor dels casos (és a dir, on el saldo complet pot ser). es reduirà a causa de les penalitzacions de correlació).

Qui pot destruir una cosa, controla una cosa. - Paul Atreides (Dune)

1. Exigir un rescat a l'Alice a canvi de no cometre un delicte retallable. Això no s'alinea exactament amb la definició anterior de dol, però considereu que l'únic recurs de Bob és cremar ETH si l'Alice decideix jugar a la pilota. Per tant, la situació és diferent dels tipus d'atac més habituals on l'objectiu és (sempre) obtenir beneficis amb pèrdues mínimes.

Nota: Bob (l'operador del node) pot ser realment honest en aquest escenari, però un adversari podria comprometre la clau del validador i mantenir l'ETH d'Alice com a ostatge. Això explica el "risc de contrapartida" que han de suportar els usuaris d'una plataforma de staking-as-a-service (SaaS) i és una altra raó per la qual l'apostament en solitari, amb el seu ethos de "no confiar en ningú més que en tu mateix", es considera l'estàndard d'or per als stakers d'Ethereum. .

Vol dir això que tots els serveis d'aposta sense custòdia no són en realitat sense custodia? No exactament. Una solució senzilla és que el servei de staking signi un missatge de sol·licitud de retirada voluntària per avançat, preferiblement una vegada que el validador estigui activat a la cadena Beacon, que l'apostador pot enviar de manera independent a un node de consens d'Ethereum sempre que vulgui retirar-se.

En signar prèviament les sol·licituds de retirada voluntària d'un staker, l'acord entre un staker i un operador de node torna a l'estat original de no custòdia. Tanmateix, els missatges de sol·licitud de retirada signats prèviament no són sostenibles per molts motius:

Problemes amb les sol·licituds de retirada signades prèviament per a la participació no custòdia

Complexitat

Els fluxos de treball de sol·licituds de retirada prèviament signades requereixen més comunicació entre un operador de serveis de staking i el delegador de participacions: heu d'enviar una sol·licitud per a un missatge de sol·licitud de retirada i esperar que el servei de staking enviï les sol·licituds de retirada signades. També hi ha el problema de la seguretat a l'hora d'utilitzar i intercanviar sol·licituds de retirada signades prèviament:

• Un servei de staking ha de prendre precaucions addicionals, com ara xifrar el missatge de sol·licitud de retirada i compartir-lo a través d'un canal de comunicació segur (fora de la cadena), per evitar que els missatges de sol·licitud de retirada caiguin en mans equivocades.
• Un participant ha de prendre precaucions addicionals per emmagatzemar el missatge de sol·licitud de retirada en un lloc segur, ja que perdre el missatge de sol·licitud de retirada equival a perdre potencialment la capacitat de retirar de manera independent el saldo del validador.

A més, les sol·licituds de retirada signades prèviament són vàlides actualment per a dues bifurcacions d'Ethereum o ~ 12 mesos, si espereu que les bifurcacions es produeixin aproximadament cada sis mesos. Això significa que un staker ha de tornar a enviar una sol·licitud de retirada voluntària a l'operador del servei de staking diverses vegades durant un any natural. Això deixarà de ser el cas quan s'implementi l'EIP-7044 i les sol·licituds de retirada del validador signades tinguin validesa indefinida, però.

L'EIP-7044 soluciona el problema dels missatges de sortida caducats, però introdueix un nou conjunt de problemes, especialment per a grans grups de participació. Com a antecedents, l'enfocament actual dels grups d'aposta descentralitzats és exigir als nous operadors de nodes validadors que enviïn sol·licituds de retirada signades prèviament abans de ser finançats pel grup. Aquí, les sol·licituds de retirada signades proporcionen seguretat criptoeconòmica, ja que redueixen el poder que té un operador (no fiable) sobre els fons del validador; un grup de participació pot activar la sol·licitud de retirada d'un operador de node validador que no col·labora enviant la sol·licitud de retirada prèviament signada a la cadena.

Però un operador del node validador no es sentirà exactament còmode si les sol·licituds de retirada signades prèviament s'emmagatzemen en un servidor aleatori a causa del risc que algú desencadeni accidentalment/deliberadament unes sol·licituds de retirada falses en aconseguir el missatge de sortida signat. En el pitjor dels casos, les sortides forçades probablement provocaran una pèrdua per a un operador de node validador (p. ex., si vau contractar un préstec contra futures recompenses de Beacon Chain). Això vol dir que els grups de participació han de prendre encara més precaucions de seguretat i emmagatzemar els missatges de sol·licitud de retirada de manera segura, especialment en un món posterior a l'EIP 7044 on les sol·licituds de retirada signades tenen dates de caducitat infinites.

Una solució potencial és xifrar les sol·licituds de retirada signades amb una clau pública compartida generada mitjançant un protocol DKG (generació de claus distribuïdes) i requerir un quòrum de claus compartides per reconstruir la clau privada abans que es pugui desxifrar la sol·licitud de retirada. Això redueix la hipòtesi de confiança que comporta una part que emmagatzema les sol·licituds de retirada, sempre que ningú controli suficients claus compartides per desxifrar unilateralment les sol·licituds de retirada signades prèviament sense l'entrada d'altres participants. Però apareix un cas extrem si es perden, es perden o es roben una o més claus compartides, cosa que fa que sigui difícil, o totalment impossible, desxifrar la sol·licitud de retirada signada si és necessari activar la retirada d'un validador.

Compliment normatiu

Els serveis de staking han rebut un gran escrutini d'una sopa d'alfabets de reguladors, sobretot la SEC (Securities and Exchanges Commission) dirigida per l'enemic públic número 1 de la cripto: Gary Gensler. Per exemple, Kraken va tancar la seva operació de custòdia de staking com a servei a principis d'aquest any i va pagar 30 milions de dòlars en multes per "oferir valors no registrats a través de la seva plataforma de cripto staking".

En teoria, és poc probable que un servei de participació sense custòdia quedi atrapat en el punt de mira de la SEC a causa de la naturalesa no custòdia del seu acord amb el propietari de la participació:

1. El dipòsit de 32 ETH (o múltiples de 32 ETH) per activar un validador prové d'una adreça de retirada controlada pel staker, i el protocol identifica l'adreça de retirada com a propietari del dipòsit de 32 ETH. Això vol dir que un servei de staking sense custòdia no pot retirar el saldo del validador i "combinar els diners dels clients amb els seus" tal com va acusar Kraken de fer per la SEC.

En un intercanvi com Kraken, el saldo de la cartera d'un usuari és "virtual", ja que tots els fons dels clients es mantenen en una o més carteres controlades per l'intercanvi. Per tant, si aposteu 32 ETH mitjançant un servei de custòdia gestionat per un intercanvi, el que realment teniu és un IOU de l'intercanvi que promet retornar 32 ETH (més un percentatge de recompenses del validador) sempre que vulgueu retirar-vos.

1. Els stakers poden retirar fons de manera independent enviant sortides presignades sense córrer el risc que un servei de staking fraudulent impedeixi les retirades. En canvi, un servei de custòdia, especialment un intercanvi com Kraken, té el control dels actius d'un staker i pot bloquejar les retirades per raons arbitràries.

Aquests dos fets obvien la necessitat de "protecció dels inversors"; No sóc un expert en polítiques, així que disculpeu qualsevol error en aquesta línia de raonament. Però encara pot haver-hi una petita arruga o dues si avui estàs executant un servei de staking institucional i sense custòdia:

• Durant el període curt (o probablement llarg) entre l'activació d'un validador i l'enviament d'una sortida voluntària prèviament signada al staker, el servei de staking controla el 32 ETH, cosa que el fa "custodial" als ulls d'un regulador. El problema encara agreuja més les dates de caducitat curtes de les sortides presignades (pre-EIP 7044): entre el moment en què es signa un nou missatge de sortida i s'envia al staker, l'operador del node validador té cert control sobre l'ETH apostat.
• Tot i que els missatges de sortida habituals s'emeten en cadena i es poden verificar públicament, una sortida prèviament signada s'ha de xifrar i compartir fora de la cadena de manera privada entre l'operador del node i el staker. Això fa que sigui més difícil que un tercer com un regulador verifiqui que el servei de staking realment va signar una intenció de sortida com a part de l'acord de dipòsit inicial del validador, o si l'intercanvi es va repetir un cop va expirar el missatge de sortida original (és a dir, abans -EIP 7004).

En resum: les sortides presignades alleugen alguns problemes amb l'aposta delegada, però no són suficients per fer que l'aposta a Ethereum sigui fiable, segura i descentralitzada. Per tornar a posar el "no custòdia" a l'aposta no custòdia, necessitem una solució millor, que ara tenim, gràcies a EIP-7002. Les seccions posteriors tractaran detalladament l'EIP-7002 i tractaran els diferents avantatges de l'EIP, així com els problemes potencials associats a la seva implementació.

Una visió general de l'EIP-7002: retirades activables de la capa d'execució

L'EIP-7002 soluciona el problema de l'agent principal en l'apostament delegat, on els participants han de confiar en els operadors del node validador per signar prèviament les sol·licituds de retirada o per atendre futures sol·licituds de retirada, introduint una nova operació de retirada voluntària que es pot activar amb la credencial de retirada d'un validador. Això permet als stakers retirar l'ETH apostat sense dependre de l'entitat que té la clau de signatura del validador (és a dir, el servei de staking en una configuració de staking delegada) per processar les retirades.

La característica clau de l'EIP-7002 és la introducció d'un contracte de sol·licitud de retirada del validador amb estat que manté una cua de sol·licituds de retirada del validador originàries de la capa d'execució. A intervals, una sèrie de sol·licituds de retirada s'eliminen de la cua i s'afegeixen a la sol·licitud d'execució d'un bloc Beacon Chain. Això permet que les sol·licituds de retirada de la capa d'execució s'"injectin" a la capa de consens i es processin com a part de les operacions Beacon Chain, de manera similar a com els dipòsits originats del contracte de dipòsit es passen de la capa d'execució a la capa de consens per al seu processament.

Les sol·licituds de retirada són transaccions regulars d'Ethereum amb l'adreça del contracte del validador com a objectiu i indiquen la intenció de retirar un validador (identificat per la seva clau pública). Un missatge de retirada del validador és vàlid si (a) està signat per l'adreça d'Ethereum a la qual es fa referència a la credencial de retirada de la capa d'execució del validador ( 0x01 ) (b) el validador que s'ha de retirar està actiu a la cadena de balises. Aquestes comprovacions les executa la capa de consens després que la sol·licitud de retirada es dirigeixi a Beacon Chain; el contracte de sol·licitud de retirada del validador només confirma si una transacció de sol·licitud de retirada paga prou gas en el moment en què un jugador convoca el contracte de sol·licitud de retirada.

Totes les sol·licituds de retirada de la capa d'execució es processen de la mateixa manera que una operació regular de sol·licitud de retirada voluntària activada des de la capa de consens, que conserva els invariants al voltant de les sol·licituds de retirada màximes permeses de les retirades del validador actiu. El mecanisme dins del protocol d'EIP-7002 per transferir sol·licituds de retirada entre les capes d'execució i de consens també elimina la necessitat de connexions a un node de consens per activar sol·licituds de retirada (que és necessària per retirar validadors amb sol·licituds de retirada presignades). Els validadors ara es poden finançar i retirar des de la mateixa adreça de la capa d'execució, la qual cosa explica la denominació de l'EIP com a "Retirada activable de la capa d'execució".

Després d'haver vist com funciona l'EIP-7002 a un alt nivell, ara podem aprofundir en els detalls més detallats de l'EIP. La següent secció tractarà l' especificació actual de l'EIP-7002 i tractarà aspectes clau del mecanisme de sol·licitud de retirada del validador. Si preferiu ometre la discussió tècnica i explorar els avantatges d'implementar EIP-7002, podeu passar a la secció següent, que destaca algunes de les millores de l'experiència d'usuari (UX) que permet l'EIP-7002.

Operacions de sol·licitud de retirada del validador

Segons EIP-7002, una sol·licitud de retirada del validador (definida en pseudocodi com add_withdrawal_request() ) és una CALL a l'adreça del contracte de sol·licitud de retirada del validador. El camp de transacció per a les trucades al contracte de sol·licitud de retirada del validador té dos valors:

• source_address : un valor de 20 bytes que representa l'adreça de retirada que va iniciar la transacció
• validator_pubkey : un valor de 48 bytes que representa la clau pública del validador que s'ha de sortir

Després que un participant cridi al contracte de sol·licitud de retirada amb validator_pubkey com a entrada, el contracte de sol·licitud de retirada del validador executa les operacions següents (més endavant repassaré les parts clau d'aquesta operació):

• Confirma que la transacció paga prou gas per cobrir EXIT_FEE
• Augmenta el comptador de sortida ( EXIT_COUNT ) en un per al bloc actual
• Insereix el missatge de sortida a la cua
• Augmenta en un l'excés de retirades del bloc actual ( EXCESS_EXITS ).
• Reembossa a la persona que truca, si ha pagat en excés per la gasolina, enviant un estipendi de 2300 gasolina ( EXCESS_RETURN_GAS_STIPEND )

Un detall important: el contracte de sol·licitud de retirada del validador no comprova si source_address és una adreça de retirada vàlida per al validador identificat per validator_pubkey , ni comprova si validator_pubkey . Això exposa un problema de seguretat subtil que pot sorgir si un atacant omple la cua amb missatges que estan condemnats al fracàs; es tracta principalment d'un atac de dol amb l'objectiu d'impedir el processament de sol·licituds de retirada legítimes. L'EIP-7002 soluciona aquest problema cobrant una tarifa d'ajust dinàmic a les transaccions de sol·licitud de retirada (el mecanisme de la tarifa de retirada es tractarà més endavant).

Retirada màxima i objectiu per bloc

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK és el nombre de sol·licituds de retirada de la capa d'execució que es poden incloure en un bloc Beacon Chain. Aquest valor està establert actualment en 16 per reflectir operacions similars a la cadena de balises, com ara VoluntaryExit (operacions de sortida activades directament des de la capa de consens amb la clau de validació d'un staker).

L'especificació també assenyala que establir MAX_WITHDRAWAL_REQUESTS_PER_BLOCK a 16 limita la mida de les càrregues útils d'execució i, per extensió, la mida dels blocs Beacon Chain, i redueix la sobrecàrrega de les operacions de sortida de processament a la capa de consens. Això és útil ja que podem esperar que alguns participants continuïn sortint dels validadors utilitzant el mecanisme actual d'activació de sortides de la capa de consens (és a dir, mitjançant sortides presignades o missatges de sortida voluntària en temps real).

TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK

EIP-7002 teòricament permet incloure fins a 16 operacions de sortida de la capa d'execució en un bloc, però té com a objectiu una estimació més conservadora de dues sortides per bloc. Segons l'especificació , TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK s'ha establert en 2 per limitar la taxa de rotació dels validadors i preservar l'invariant de les retirades màximes permeses per època definides per la funció get_validator_churn_limit() de Beacon Chain, fins i tot en situacions en què tots els ETH estan en circulació.

Cua de sol·licituds de retirada del validador

WITHDRAWAL_REQUEST_COUNT

WITHDRAWAL_REQUEST_COUNT és el nombre de sol·licituds de retirada incloses al bloc actual. Després de cada trucada satisfactòria al contracte de sol·licitud de retirada del validador, el valor de la variable WITHDRAWAL_REQUEST_COUNT emmagatzemada a l'emmagatzematge del contracte del validador s'incrementa en un (definit en pseudocodi com increment_count() ).

En qualsevol moment, el valor de WITHDRAWAL_REQUEST_COUNT estarà entre TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK (2) i MAX_WITHDRAWAL_REQUESTS_PER_BLOCK (16), depenent de quantes operacions de sol·licitud de retirada s'afegeixin a la càrrega útil d'execució del bloc. WITHDRAWAL_REQUEST_COUNT també és una entrada a la funció que calcula l'import que cal pagar per una nova operació de sol·licitud de retirada ( MIN_WITHDRAWAL_REQUEST_FEE ).

EXCÈS DE SOL·LICITUDES DE RETIRADA

EXCESS_WITHDRAWAL_REQUESTS és la diferència entre MAX_WITHDRAWAL_REQUESTS_PER_BLOCK i TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK : el nombre de sol·licituds de retirada sense utilitzar el bloc actual. Com s'ha esmentat, cada bloc pot incloure un màxim de 16 sol·licituds de retirada, però apunta a dues sol·licituds de retirada en situacions normals, de manera que EXCESS_WITHDRAWAL_REQUESTS equival a "la diferència entre quantes sol·licituds de retirada pot consumir un bloc teòricament i quantes sol·licituds de retirada utilitza realment".

El comptador d'excés del contracte de sol·licitud de retirada s'actualitza en funció de l'ús de l'últim bloc i és un factor (entre d'altres) que determina la tarifa pagada per una transacció que anomena el contracte de sol·licitud de retirada del validador. Això garanteix que les tarifes de retirada tinguin un preu segons l'ús actual, que és similar a l'EIP-1559, el càlcul de la base_fee per a un bloc nou es calcula en funció de la diferència entre el límit de gas objectiu i el gas utilitzat pel bloc anterior.

WITHDRAWAL_REQUEST_QUEUE

WITHDRAWAL_REQUEST_QUEUE és una llista de totes les sol·licituds de retirada pendents (ordenades per ordre d'arribada) actualment emmagatzemades al WITHDRAWAL_REQUEST_QUEUE_STORAGE_SLOT del contracte del validador (com WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT i WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT ). El nombre de sol·licituds de retirada a la cua pot ser il·limitat, però la taxa variable MAX_WITHDRAWAL_REQUESTS_PER_BLOCK limita quantes sol·licituds de retirada pendents es poden retirar de la cua a cada bloc.

La cua de sol·licituds de retirada manté un índex "cap" i "cua", ambdós simplement referits al conjunt de sol·licituds prop de l'inici i al final de la cua, que s'actualitza després de cada bloc per tenir en compte el processament d'una o sol·licituds de retirada. Es tracta d'una cua de primer en entrar, primer en sortir (FIFO), de manera que les sol·licituds s'executen segons quan s'afegeixen a la cua, la qual cosa té implicacions de seguretat, especialment pel que fa al dol dels validadors honestos.

Comissions del contracte de retirada del validador

MIN_WITHDRAWAL_REQUEST_FEE és l'import que una adreça que truca al contracte de sol·licitud de retirada del validador per retirar un validador ha de pagar en gasolina. Abans d'inserir una sol·licitud de retirada a la cua, el contracte de sol·licitud de retirada del validador comprova que la tarifa de gas adjunta a la transacció és igual o superior al valor actual de MIN_WITHDRAWAL_REQUEST_FEE -si la transacció té gas sobrant després d'executar-se correctament, l'adreça d'enviament s'acredita exactament amb 2300 gas.

Segons l'especificació, aquest disseny segueix la característica ara obsoleta de Solidity, on invocar la funció fallback() en un contracte de destinació o enviar ETH mitjançant transfer() o send() reenvia un estipendi de 2300 gasos al destinatari. Els canvis en els costos del gas (començant per la bifurcació de Berlín/Istanbul) han reduït la utilitat d'aquesta característica (llegiu la transferència de Stop Using Solidity() Ara per a un cert context), però la idea original d'un sistema de comptabilitat de gas senzill encara és útil. En el context de l'EIP-7002, l'enviament d'un reemborsament fix de 2300 gasos simplifica el mecanisme de tarifa per al contracte de sol·licitud de retirada del validador.

L'alternativa és dissenyar un mecanisme especial que permeti que el contracte de sol·licitud de retirada retorni la quantitat màxima de gas sobrant d'una transacció. Això tindria sentit, especialment en els casos en què l'adreça de retirada és una EOA, els contractes intel·ligents poden calcular valors precisos per a MIN_WITHDRAWAL_REQUEST_FEE comprovant l'estat del contracte, però és probable que els EOA enviaran més gas per cada trucada al contracte de sol·licitud de retirada. Aquesta ruta afegeix més complexitat al disseny de l'EIP-7002 en comparació amb l'ús d'una simple CALL per reenviar una quantitat fixa de gas com a reemborsament; tot i que, els autors de l'EIP-7002 suggereixen que aquesta característica es pot incloure a l'especificació final depenent dels comentaris de les parts interessades.

El càlcul de MIN_WITHDRAWAL_REQUEST_FEE és on les coses es posen interessants. La tarifa de sol·licitud de retirada és dinàmica i està dissenyada per respondre a les condicions de la xarxa, similar a la tarifa base introduïda per EIP-1559, i és una funció de tres variables:

• Comissió de retirada mínima (base): MIN_WITHDRAWAL_REQUEST_FEE
• Nombre d'excés de retirades al bloc actual: EXCESS_WITHDRAWAL_REQUESTS
• La fórmula d'actualització de la tarifa de sol·licitud de retirada: WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION

Igual que base_fee d'EIP-1559, la tarifa de sortida del contracte de retirada del validador és un mecanisme de limitació de tarifes: en el cas mitjà (dues sol·licituds per bloc), qualsevol persona que truqui al contracte de sol·licitud de retirada del validador pot esperar pagar la tarifa mínima de retirada, però el cost de una operació de retirada augmenta progressivament més sol·licituds de retirada s'inclouen en un bloc. Això es pot deduir de l'especificació formal de l'EIP-7002 per actualitzar la tarifa de sol·licitud de retirada : withdrawal_request_fee = MIN_WITHDRAWAL_REQUEST_FEE * e**(excess_withdrawal_requests / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) .

Una explicació del mecanisme de la tarifa de sol·licitud de retirada de l'especificació:

"El comportament bloc per bloc és aproximadament el següent: si el bloc N processa X sol·licituds de retirada, aleshores al final del bloc N excess_withdrawal_requests augmenta en X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK i, per tant, la tarifa_de_retirada_de_retirada al bloc N + 1 augmenta en un factor de e**((X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK) / (WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) Per tant, té un efecte similar a l'EIP-1559 existent, però és més "estable" en el sentit que respon de la mateixa manera a les mateixes sol·licituds de retirada totals independentment de com es distribueixin en el temps. .”

En augmentar progressivament la tarifa de sol·licitud de retirada segons l'ús del contracte de sol·licitud de retirada del validador, EIP-7002 redueix el risc que un atacant ompli deliberadament la cua de sol·licitud de retirada per evitar que altres validadors es retirin. Els missatges de recuperació de la cua de sol·licituds de retirada es retiren de la cua i en l'estil de primer en entrar, primer en sortir (FiFo) en lloc de, per exemple, l'últim en entrar, primer en sortir (LiFo) o l'ordre de la transacció que paga més alt. Tot i que podem suposar que els preus del gas evitaran trucades innecessàries al contracte de sol·licitud de retirada, un atacant maliciós pot estar disposat a pagar més gas per "omplir" la cua de sol·licituds de retirada i portar la sol·licitud de retirada d'un altre validador fins al final de la cua.

El problema s'agreuja encara més per la centralització de la construcció de blocs a Ethereum posterior a la fusió. Si un atacant s'integra amb un o més constructors dominants (per al context: el 80-90% dels blocs fins ara a Ethereum han estat produïts per 4-5 constructors ) i està disposat a pagar per la inclusió de la part superior del bloc, pot dirigir de manera efectiva les sol·licituds de retirada d'un o més participants i evitar retirades oportunes dels validadors de la cadena Beacon.

I per què algú passaria per tot aquest estrès? Una possible motivació podria ser que l'atacant vulgui afligir els participants que vulguin retirar validadors mitjançant credencials de retirada. Per utilitzar l'anterior de Bob l'operador del node (maliciós) i l'Alice l'apostador: Alice pot retirar ràpidament el seu validador per aturar l'atac de dolor de Bob trucant al contracte de sol·licitud de retirada del validador amb la credencial de retirada, però Bob encara pot donar-se més per filtrar l'Alice. saldo del validador enviant correu brossa el contracte de sol·licitud de retirada del validador i retardant la sol·licitud de retirada de l'Alice.

Estructura i validesa del bloc

L'EIP-7002 canvia lleugerament l'estructura i la validació dels blocs Beacon exigint que les sol·licituds de retirada es col·loquin al cos real del bloc (i la càrrega útil d'execució a la capa de consens). Les sol·licituds s'han d'incrustar a la càrrega útil d'execució de manera que sempre que la capa de consens no sigui possible, la capa de consens encara tingui les dades necessàries per executar completament la part de consens de la funció de transició d'estat.

EIP-7002 també afegeix noves condicions de validesa per als blocs. En primer lloc, la llista de sol·licituds de retirada ( withdrawal_requests_list ) no pot superar MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . En segon lloc, la llista de sol·licituds de retirada ha de correspondre al nombre de sol·licituds de retirada retirades de la cua de WITHDRAWAL_REQUEST_QUEUE quan aquestes sol·licituds es disposen en ordre de primer en entrar, primer en sortir (FiFO).

EIP-7002 té una funció ( expected_exit ) per confirmar que un bloc no inclou més sol·licituds de retirada que el resultat de calcular NUM_WITHDRAWAL_REQUESTS_IN_QUEUE - MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . A més, un node de consens que torni a executar el bloc calcularà de manera independent la codificació de les sol·licituds de retirada iterant request_type i request_data en comparació amb el compromís de la llista hash de sol·licituds de retirada.

Per què EIP-7002? El cas de les retirades activables de la capa d'execució

Hipòtesis de confiança reduïdes en la participació delegada

A la introducció, vaig observar com la confiança en la clau de signatura d'un validador per iniciar les sortides del validador va introduir el problema de la confiança; No vaig incloure una definició de confiança, però aquesta definició de l'article de Models de confiança de Vitalik ho resumeix molt bé: "La confiança és qualsevol suposició que feu sobre el comportament d'altres persones". En registrar-se a un servei de staking, sabent que un operador de nodes maliciós pot congelar les retirades, un staker confia essencialment en l'operador de nodes per actuar fidelment.

L'EIP-7002 no elimina totalment l'element de confiança en la participació delegada (encara heu de confiar en un operador de nodes per no executar un atac de dol), però permetre que els participants es retirin amb credencials de retirada redueix la càrrega de confiança fins a cert punt. Per exemple, un usuari no necessita "confiar" que un operador de nodes signarà un missatge de sortida voluntària un cop ho sol·liciti.

Un punt subtil sobre la "desconfiança" és que no es tracta necessàriament d'evitar la necessitat de confiar, sinó de no necessitar confiar perquè (a) hi ha forts incentius perquè totes les parts actuïn amb honestedat (b) les parts honestes tenen una certa quantitat de protecció de les accions de les parts deshonestas. La possibilitat de retirar un validador amb credencials de retirada és un exemple d'això últim: en Bob pot tractar d'afligir l'Alice, però ara l'Alice té l'agència per retirar el seu validador, amb sort abans que en Bob faci més mal.

Millor gestió del risc per als pools de staking

Actualment, les agrupacions d'aposta no tenen manera d'obligar a un operador de nodes validador a retirar-se, cosa que posa els col·laboradors de la agrupació en la posició incòmoda de confiar en els operadors de nodes per actuar amb honestedat. Alguns grups de participació descentralitzats requereixen que els operadors de nodes proporcionin un vincle, però tenint en compte la possibilitat que un operador maliciós es redueixi a 0 ETH, la seguretat d'un vincle podria ser inadequada als ulls d'un staker negatiu al risc.

Amb l'EIP-7002, les agrupacions de staking poden reduir en gran mesura els supòsits de confiança complementant la seguretat davant l'amenaça de retallar la garantia d'un operador de nodes amb procediments per retirar de manera forçada un operador que es comporta malament mitjançant una retirada de la capa d'execució. La possibilitat que les credencials de retirada apuntin a una adreça de contracte intel·ligent (en lloc d'una EOA) també obre nous dissenys de resposta a incidents per a grups de participació; per exemple, un contracte intel·ligent podria enviar automàticament una sol·licitud de retirada si un operador incorre en penalitzacions superiors a la mitjana dins una finestra de temps. Tanmateix, això requereix confiar en un oracle per fer un seguiment del rendiment del validador i en una xarxa de gestors per activar el contracte intel·ligent.

L'altre benefici hipotètic per a un grup de participacions de la implementació d'EIP-7002 és obviar la necessitat de sol·licitar i emmagatzemar missatges de retirada prefirmats, que comporta riscos, tal com he explicat anteriorment (p. ex., l'accés no autoritzat als missatges de retirada podria donar lloc a un validador inesperat). retirades). Això també contribueix a l'objectiu de dissenyar grups de participació sense confiança: a diferència de confiar en les sol·licituds de retirada signades prèviament emmagatzemades per unes quantes persones (de confiança), un contracte intel·ligent designat com a adreça de retirada es podria controlar mitjançant la governança, que permeti a la comunitat decidir. per retirar un operador de node de manera pública i transparent.

Millor gestió del risc per a les configuracions de TVP

La tecnologia de validació distribuïda (DVT) es considera una peça crítica de la infraestructura de staking d'Ethereum per moltes raons:

• DVT redueix les barreres a l'apostament en solitari: diversos participants en solitari poden agrupar fons per activar conjuntament un validador sense haver de confiar en les altres parts. Els esquemes de càlcul multipartit (MPC) poden tolerar fins a ⅓ nodes defectuosos, de manera que si un validador distribuït hipotètic requereix 3 de 5 claus compartides per reconstruir la clau de signatura del validador, la signatura es pot produir si dos nodes DVT estan fora de línia.
• DVT millora la tolerància a errors i la resiliència per a les configuracions de staking institucional/en solitari: com s'ha esmentat anteriorment, la clau de signatura d'un validador es pot dividir en diferents claus compartides i reconstruir-se només quan es requereixen dades de bloc de signatura. Això redueix el risc que un pirata informàtic comprometi la clau de signatura del validador o que un participant perdi l'accés als fons perquè el dispositiu que emmagatzema la clau de signatura ha patit danys.

No obstant això, les configuracions de DVT encara comporten algun risc per als stakers a causa de la forma en què les retirades i les sortides funcionen actualment a la cadena Beacon. Si alguns nodes DVT perden les claus compartides o es neguen a participar en l'esquema de signatura de llindars, sortir d'un validador esdevé impossible, sobretot quan:

• Les claus compartides per a cada participant a la configuració de DVT es generen en el moment d'activar un validador i no es poden "actualitzar" després de la cerimònia inicial de DKG (tingueu en compte que un "participant" podria ser simplement un altre EOA propietat del mateix staker); alguns protocols DVT permeten generar noves claus compartides, tot i que això pot requerir que les claus compartides restants compleixin el quòrum de signatures necessari per a la signatura habitual.
• El llindar de quòrum (el nombre de claus compartides necessàries per generar conjuntament una signatura vàlida per al validador distribuït) no es pot canviar un cop el validador (distribuït) estigui actiu.

Sense que l'EIP-7002 proporcionés l'opció de retirar un validador mitjançant la clau de retirada, l'avantatge d'executar una configuració de DVT, de manera independent o conjuntament amb altres validadors, es reduiria molt (per exemple, un saldo de validador es podria bloquejar per sempre). EIP-7002 ofereix una opció de seguretat alternativa per als validadors distribuïts: si la reconstrucció de la clau de signatura és inviable, el validador es pot retirar de la cadena Beacon enviant una sol·licitud de retirada signada amb la clau de retirada reconstruïda a partir de claus compartides.

Millor compliment de la normativa: posar el "no custòdia" a l'aposta no custòdia

És poc probable que els autors de l'EIP-7002 s'estableixin explícitament amb l'objectiu de facilitar la gestió d'una empresa de participació institucional regulada com a servei. Tot i així, l'EIP ajuda amb el problema de convèncer els reguladors de la no custòdia d'una institució d'ETH participada. Un operador de staking en aquest escenari podria simplement presentar un hash de la transacció de dipòsit signada per la clau de retirada del staker, que ara pot signar i presentar sortides voluntàries, com a prova que els fons dipositats en un validador mai estan sota la seva custòdia en cap moment.

Vaig posar èmfasi en "qualsevol moment" ja que, abans de l'EIP 7044, un operador de nodes assumeix temporalment el control del saldo del validador després que caduqui la sortida prèviament signada. I fins i tot amb les sortides signades perpètuament vàlides d'EIP-7044, els operadors de nodes encara tenen la custòdia dels 32 ETH dipositats per a un validador durant el curt període entre l'activació del validador i l'apostador que rep un missatge de sortida signat de l'operador del servei de staking. L'EIP-7002 elimina aquestes àrees incòmodes i garanteix que els participants tinguin la custòdia (demostrable) dels fons al llarg del cicle de vida del validador, des de l'entrada a la cadena de balises fins a la retirada i l'enviament de fons a l'adreça de retirada del participant.

Millor experiència d'usuari (UX) per a tots

Un bon model mental per a l'EIP-7002 és pensar-ho com a " abstracció de comptes per a la infraestructura de staking". Per al context, una clau de validació (o clau de signatura) és sempre una EOA i inclou el mateix conjunt de restriccions sobre la seguretat i l'ús de la clau privada que afecta els EOA habituals d'Ethereum actuals:

• Les claus de validació (signatura) tenen un risc més elevat de posar-se en perill. A diferència de les claus de retirada emmagatzemades a l'emmagatzematge en fred (fora de línia), les claus de validació s'emmagatzemen en carteres calentes connectades a Internet, cosa que les fa susceptibles a atacs de pesca. Si la clau de signatura d'un validador es veu compromesa, els stakers i els proveïdors de staking delegats són susceptibles als vectors de dol descrits a la introducció sense cap pla de reserva, més enllà de "esperar fins que el saldo baixi a 16 ETH i el validador es retiri amb força pel protocol".
• Les claus de validació tenen opcions limitades per als esquemes de recuperació (perdre-la una vegada = perdre-la per sempre). Dividir una clau de validació en múltiples claus compartides mitjançant la tecnologia de validació distribuïda (DVT) pot mitigar aquest risc, però executar una configuració de staking DVT en solitari no és trivial; a més, com he explicat anteriorment, la DVT no és una bala de plata, ja que les claus compartides es poden perdre i complicar l'actualització de les claus compartides.
• Les claus de validació no admeten dissenys de replanteig més flexibles. Els diferents serveis de staking han evolucionat fluxos de treball automatitzats/flexibles per als validadors de finançament a causa del benefici d'apuntar les credencials de retirada als contractes intel·ligents. La retirada d'un validador és, però, un procés manual que requereix la signatura d'un missatge de sol·licitud de retirada voluntària: el procés es podria automatitzar mitjançant un contracte intel·ligent que emmagatzema les sol·licituds de retirada anteriors a Signex, però que inclou certs supòsits de confiança i consideracions de seguretat explicades anteriorment.

Podem resoldre la majoria, o almenys alguns, d'aquests problemes una vegada que les claus de retirada siguin capaços de sortir dels validadors. Perquè això funcioni, un staker (o staking pool) haurà de completar un canvi únic de les credencials de retirada 0x0 a les credencials de retirada 0x01 , mentre que les credencials 0x0 són una clau BLS (EOA) per defecte, les credencials 0x01 poden apuntar a qualsevol Ethereum. adreça, inclosos els contractes intel·ligents i les EOA. Establir un contracte intel·ligent com a adreça de retirada per a un validador és ideal per millorar l'experiència de l'usuari (UX) de la staking:

1. Les claus de retirada poden tenir mecanismes de recuperació flexibles, com ara la recuperació social. Un staker tindria un o més "guardians" que poden autoritzar una nova clau per controlar el contracte intel·ligent de sol·licitud de retirada si es roba o es perd la clau original: els tutors poden ser amics, familiars, companys de joc o un servei especialitzat de tercers. La flexibilitat en els mecanismes de recuperació pot beneficiar especialment els jugadors solistes; podeu tenir un interruptor d'home mort que activa una sortida EL i envia fons a una adreça designada si el vostre validador deixa de certificar durant un període predeterminat (p. ex., perquè heu "passat al Gran Més enllà").

2. Poden sorgir dissenys de replantejament flexibles. Per exemple, un staker negatiu al risc pot preferir un contracte de retirada multisig de 2 de 2, amb l'operador del staker i el node que tingui una de les dues claus necessàries per aprovar les sol·licituds de retirada, en lloc d'emmagatzemar tota la clau de retirada. Encara no és de custòdia (un operador de node no pot sortir del validador sense aprovació), tot i que requereix confiar en l'operador del node per no bloquejar la sortida d'un validador en negar-se a signar les transaccions de sol·licitud de retirada proposades pel staker.

Per als grups d'aposta, la flexibilitat en els dissenys d'aposta podria significar la implementació de contractes de retirada amb lògica arbitrària per actualitzar o transferir la propietat dels validadors. En absència de l'EIP-7002, l'única manera real que un grup de participació pot gestionar la propietat dels validadors és traslladar les sol·licituds de retirada signades prèviament, la qual cosa comporta diversos riscos i casos extrems.

3. Les retirades del validador es poden automatitzar de manera segura. A diferència d'emmagatzemar les sol·licituds de retirada signades prèviament en un contracte intel·ligent, els contractes de sol·licitud de retirada poden tenir regles complexes que regulen les sol·licituds de retirada del validador; una idea de "ciència boja" és un "grup d'aposta basat en el temps" on els operadors de nodes es giren sense confiança. O considereu si un grup de participacions gran com Lido vol descentralitzar-se: la governança pot optar per retirar alguns validadors controlats per un gran operador de nodes i redistribuir fons a operadors més petits (o apostes individuals) per reduir els punts d'asfixia d'un operador de nodes que controla un nombre considerable de validadors.

Aquestes són només algunes de les primeres possibilitats que permet l'EIP-7002, però estic molt segur que apareixeran més aplicacions, igual que com continuen apareixent noves funcions i casos d'ús per a carteres intel·ligents a Ethereum. Si esteu llegint això i teniu idees més concretes per aplicar l'EIP-7002 als dissenys de replanteig, no dubteu a fer-ho als comentaris!

Hi ha algun inconvenient per implementar EIP-7002?

Potencials canvis de ruptura als dissenys de replanteig existents

A l'esborrany de l'EIP, els autors de l'EIP-7002 reconeixen les possibles preocupacions sobre l'habilitació de les credencials de retirada per activar retirades del validador, però continuen dient: "No coneixem cap disseny d'apostament que depengui d'aquesta característica [és a dir, la incapacitat de retirar-se". amb credencials de retirada]”. Això sembla raonable, fins i tot vaig tenir algunes dificultats per raonar sobre qualsevol acord de participació delegada que requeriria aquesta funció. Però només perquè no sembli obvi, no vol dir que no hi sigui.

"Escolta aquests dubtes tranquils i persistents. Si no saps, no saps el que no saps, no saps quant no saps i no saps quant necessites saber”. - Eliezer Yudkowsky

Per proporcionar una mica de context, inclouré captures de pantalla d'una conversa al voltant d'una proposta inicial per implementar sortides aprovades per la retirada de credencials mitjançant un bus de missatges generalitzats (GMB) . El GMB és un contracte intel·ligent a nivell de sistema els esdeveniments del qual són llegits i processats pels clients, com el contracte de dipòsit actual, i és capaç de transmetre missatges des de la capa d'execució a la capa de consens. Tot i que l'autor(s) va insinuar tipus de missatges EL-a-CL més genèrics, el principal cas d'ús proposat del bus de missatges EL-a-CL proporcionava una manera d'activar sortides de la capa d'execució mitjançant credencials de retirada 0x01.

A partir d'aquest intercanvi, ja tenim un exemple d'una relació d'operador de staker-node basat en el supòsit que el staker no pot sortir i retirar un validador mitjançant la clau de retirada. Un altre exemple d'un cas potencial potencial d'implementació d'EIP-7002 prové d'una conversa sobre els plans de descentralització de Lido al podcast Lido Community Staking, que podeu veure a YouTube . (EIP-7002 només s'esmenta breument (de 28:55 a 30:00) al vídeo).

Com a antecedents, Lido s'ha descrit com una "amenaça sistemàtica per a Ethereum" perquè controla ~ 33,3% dels validadors de Beacon Chain i podria posar en risc el consens d'Ethereum; per exemple, si el Lido DAO va obligar els operadors de nodes a censurar transaccions o a revertir blocs prèviament finalitzats ( la magnitud i la direcció dels vectors d'atac de Lido de Mike Neuder descriuen l'amenaça amb més detall).

Tanmateix, un dels parlants de l'episodi enllaçat anteriorment fa l'argument convincent que aquest vector d'atac —el DAO que coopta amb força els operadors de nodes en un atac al protocol Ethereum— encara no existeix, ja que els operadors de nodes tenen alguna agència. El DAO pot retenir l'aposta d'un validador després de sortir, però no pot confiar en l'amenaça d'una sortida forçada per coaccionar un validador a atacar el consens d'Ethereum.

Amb l'EIP-7002, la dinàmica de potència canvia significativament: els contractes de retirada governats pel DAO poden retirar un operador en contra dels seus desitjos, donant a la DAO una influència sobre els operadors de nodes. Aquest tipus de palanquejament és útil per protegir un protocol de staking contra un conjunt d'operadors maliciosos, tal com he explicat anteriorment. Però també es pot fer un mal ús en els escenaris següents:

• El protocol de staking pateix un atac de govern i el DAO aprova una proposta maliciosa per desencadenar la retirada d'un validador del contracte de retirada.
• Un atacant assumeix el control d'un o més validadors segrestant la propietat del contracte de sol·licitud de retirada i executa una estratègia de xantatge amb èxit

Aquest és un altre exemple de com l'EIP-7002 podria canviar els supòsits existents en els dissenys de replantejament, aquesta vegada, per als operadors de nodes que validen en nom d'un grup de staking com Lido. No obstant això, aquest vector d'atac es pot mitigar fàcilment mitjançant diferents mètodes, com ara l'ús de contractes de sol·licitud de retirada segurs, rigorosament auditats i possiblement no actualitzables o seguir les millors pràctiques per a un govern de DAO segur .

Per tenir en compte el cas extrem en què un operador de nodes pateix pèrdues per una retirada forçada després de negar-se a les demandes d'un atacant per infringir les regles del protocol, els grups de participació poden inspirar-se en empreses immobiliàries per protegir els operadors de nodes:

• Abans de signar un contracte d'arrendament, els llogaters han de proporcionar un "dipòsit de seguretat". El dipòsit es manté en un compte bancari aliè al control de l'empresa immobiliària.
• Si el llogater es muda de l'apartament, però deixa enrere un dany important, l'empresa immobiliària té dret a utilitzar la fiança per cobrir el cost de les reparacions.
• Si l'apartament es troba en bon estat en el moment de la sortida d'un llogater, la fiança es retorna íntegrament a l'arrendatari.

Un protocol de staking pot adoptar un enfocament similar per protegir els operadors de nodes contractant una pòlissa de "fons d'assegurança de l'operador de nodes" a través de Nexus Mutual , Tidal Finance o qualsevol altra plataforma d'assegurances cripto-nativa. Si es retira legítimament el validador d'un operador, el fons d'assegurança es retorna al DAO; si el contrari és cert (p. ex., la retirada d'un validador és provocada per una proposta maliciosa o un error del contracte de retirada), la pòlissa d'assegurança paga els danys a l'operador del node. Tingueu en compte que aquest enfocament es pot generalitzar a qualsevol relació existent que depengui de les especificacions actuals per sortir d'un validador.

Manca de suport per a missatges EL-a-CL més complexos

El contracte de sol·licitud de retirada del validador d'EIP-7002 ofereix una única funcionalitat: enviar una sol·licitud de retirada des de la capa d'execució d'Ethereum a la capa de consens per retirar un validador. Tanmateix, alguns han suggerit la implementació d'un marc de missatgeria general (per exemple, una precompilació SendMessageToConsensusLayer o el contracte a nivell de sistema del Bus de missatges generalitzats (GMB) esmentat anteriorment) per passar tipus genèrics de missatges entre la capa d'execució i la capa de consens. Això podria tenir avantatges com desbloquejar noves maneres d'activar validadors a la cadena Beacon, especialment si es permet adjuntar ETH als missatges EL-a-CL.

Tanmateix, tal com explica Danny Ryan (un dels autors de l'EIP-7002) en un comentari , dedicar un temps d'enginyeria valuós a un marc genèric de missatgeria EL → CL és una "gran empresa amb una proposta de valor poc clara". Per il·lustrar-ho, els autors de la proposta GMB (General Message Bus) només van identificar un altre cas d'ús per a un bus de missatges entre EL i CL: rotació de credencials de retirada per a un validador de credencials de 0x0 a 0x01 .

Això vol dir que és més probable que vegem que el validador retiri el contracte de sol·licitud abans que els desenvolupadors principals parlin d'implementar un bus de missatges EL-a-CL general, si això passa mai. No és que mantenir les coses senzilles mai faci mal.

La senzillesa és un requisit previ per a la fiabilitat. — Edsger W. Dijkstra

Vectors de risc més nous per als stakers existents

He explicat els avantatges d'habilitar les credencials de retirada per activar una retirada en la seva majoria, però hi ha alguns casos extrems associats amb aquesta funció. La idea és així (h/t a aquest comentari a GitHub ):

• Si la clau de signatura d'un validador està compromesa, un pirata informàtic pot exigir un rescat o intentar reduir el saldo del validador, però no pot retirar fons sota cap escenari. Es produirà un joc d'espera: l'atacant destruirà tot el saldo, o l'apostador podrà retirar una part de l'aposta una vegada que el validador es retiri amb força?
• No obstant això, un cop implementat l'EIP-7002, el pirata informàtic de l'escenari anterior pot procedir a sortir del validador i retirar el saldo (un cop implementat l'EIP-7002) en lloc de conformar-se amb un atac de dol/xantatge.

En resum, els stakers individuals i els serveis de staking necessitaran més protecció per a les credencials de retirada després de l'EIP 7002. És per això que l'adopció de la recuperació social, l'autenticació multifactorial (MFA) i la rotació de claus es consideren fonamentals per millorar la seguretat de les operacions de staking individuals/delegades.

Elecció del mecanisme de limitació de velocitat

La funcionalitat add_withdrawal_request() del contracte de sol·licitud de retirada del validador no realitza cap comprovació addicional, a més de comprovar la tarifa de sol·licitud de retirada adjunta, que pot permetre que un atacant obstrueixi la cua de missatges amb sol·licituds de retirada no vàlides (per exemple, missatges de sortida per a un validador inexistent). o un validador inactiu serà invalidat durant les comprovacions de validesa de la capa de consens). L'EIP-7002 utilitza una tarifa de retirada amb un preu dinàmic per limitar les sol·licituds de retirada i fer que aquests atacs siguin costosos, de manera similar a com l'EIP-1559 desanima els atacs de correu brossa i bloqueja el farcit ajustant els preus del gas en funció de l'activitat de la xarxa.

Un disseny alternatiu és restringir les trucades al contracte de sol·licitud de retirada del validador als validadors reals, per exemple, comprovant que validator_pubkey correspon a la clau pública d'un validador Beacon Chain actiu. Això podria simplificar el disseny de l'EIP-7002 eliminant la necessitat d'un mecanisme de preus complex a l'estil EIP-1559 i, potencialment, reduir la tarifa de sol·licitud de retirada, ja que enviar correu brossa a la cua amb sol·licituds falses pot ser menys problema.

Tanmateix, això requereix que la capa d'execució pugui accedir sense confiança a la informació sobre la capa de consens, per comprovar validator_pubkey amb el registre del validador de Beacon Chain, una característica que depèn de la implementació de l'EIP-4788. Això afegeix més complexitat a l'EIP-7002 i introdueix una nova dependència entre els dos EIP, que pot tenir implicacions per a futures millores de disseny, tal com s'indica en aquesta secció de la justificació de l'EIP-7002 .

Fins i tot si EIP-4788 s'hagués integrat amb EIP-7002, encara necessitaríem mecanismes addicionals per evitar altres formes de correu brossa que involucren validadors legítims; un exemple és enviar diverses sol·licituds de retirada per al mateix validador en un període molt curt. Això al seu torn requereix afegir (i fer complir) una nova regla com "només podeu enviar una sol·licitud de retirada per validador cada 3-4 mesos", que pot requerir encara més canvis al contracte de sol·licitud de retirada del validador.

En canvi, el mecanisme actual de limitació de la taxa és senzill de raonar i garanteix una protecció suficient contra la majoria dels problemes de seguretat associats a les retirades de la capa d'execució. Per exemple, la tarifa de sol·licitud de retirada es pot ajustar automàticament a l'alça per dissuadir el dol (intent d'evitar que els validadors honestos es retirin) i els atacs de correu brossa i DOS (intentar sobrecarregar la cadena de balises forçant els nodes de consens a malgastar recursos en filtrar operacions de retirada no vàlides).

Conclusió: EIP-7002 i el futur de la participació a Ethereum

La participació delegada ha rebut crítiques significatives en els darrers mesos, però és segur assumir que la indústria de l'apostament com a servei ha arribat per quedar-se. Si és així, és important reduir el risc per a les persones que deleguin participacions, ja sigui a un pool de participacions líquides o a un servei de participacions institucionals no custodials. L'EIP-7002 aconsegueix aquest objectiu fent que les credencials de retirada 0x01 puguin sortir dels validadors i retirar l'aposta i reduint la necessitat que els stakers confiïn en l'honestedat de l'operador del node.

EIP-7002 també té altres efectes positius. En particular, millorar la resiliència i la seguretat de les operacions d'aposta en solitari i dels validadors distribuïts, permetent una millor recuperació de la pèrdua d'una clau de validació o de claus compartides DVT, hauria de reduir la barrera per a l'aposta individual i reduir la centralització de l'aposta a Ethereum.

Com és habitual, acabaré demanant-vos que considereu la possibilitat de compartir aquest article amb algú que pugui trobar-lo informatiu i, el que és més important, subscriviu-vos a Ethereum 2077 per obtenir informació més detallada sobre totes les coses de R+D d'Ethereum. També podeu connectar-vos amb mi a Twitter per compartir comentaris o comentaris sobre aquest article.