EIP-7002: Bolji način za ulog na Ethereum

Prijelaz Ethereuma s Proof of Work (Pow) na Proof of Stake (PoS), poznat i kao The Merge, bio je ključni trenutak u povijesti mreže. Osim što je Ethereumu omogućio prijeko potrebnu rebrendiranje smanjenjem njegovog ugljičnog otiska, Proof of Stake bio je ključan za ključni dugoročni cilj: smanjenje prepreka sudjelovanju u konsenzusu Ethereuma. Spajanjem su računalni resursi (snaga rudarenja) zamijenjeni financijskim kapitalom kao osnovom ekonomske sigurnosti Ethereuma—otvorajući priliku svakome da profitabilno i jednostavno pokrene čvor validatora ulaganjem 32 ETH na Beacon Chain.

Iako je Proof of Stake donio prednosti, još uvijek postoje mnoga područja poboljšanja. Neki od njih uključuju:

• Smanjenje centralizacije udjela i kartelizacije validatora
• Minimiziranje operativnih troškova za validatore i poticanje solo stakinga
• Poboljšanje ekonomije udjela i korisničkog iskustva (UX)
• Poboljšanje jednostavnosti, sigurnosti i decentralizacije delegiranih i višestranačkih operacija uloga

EIP-7002: Povlačenja koja se aktiviraju na sloju izvršenja novi su prijedlog poboljšanja Ethereuma (EIP) koji rješava neke od gore navedenih problema. EIP uvodi mehanizam za stakere da povlače validatore iz Beacon Chaina koristeći vjerodajnice za povlačenje umjesto da se oslanjaju na ključ za potpisivanje validatora za pokretanje operacija povlačenja—čime se ključ za potpisivanje validatora učinkovito odvaja od ključa za povlačenje.

Ovo "odvajanje pitanja" između ključeva za potpisivanje validatora i ključeva za povlačenje ima ključnu korist: smanjenje pretpostavki o povjerenju u delegiranom ulogu omogućavanjem vjerodajnicama za povlačenje da zadrže kontrolu nad uloženim ETH-om. Istražit ću zašto je ova značajka neophodna tijekom ovog članka i raspraviti o drugim prednostima EIP-7002, posebno za solo staking i DVT (tehnologija distribuiranog validatora) staking. Članak će također razmotriti neke potencijalne nedostatke implementacije EIP-7002 na Ethereum.

Zaronimo!

Postavljanje pozornice: Priča o ključevima, bijelim rukavicama i tugovanju

Ako danas želite uložiti ETH i potvrditi Beacon Chain, imate dvije primarne opcije: solo ulog i delegirani ulog; postoje i drugi načini za ulaganje ETH-a, ali ta su više ili manje povlačenja u spektru između gore navedenih opcija. Solo ulog je jednostavan:

• Uplatite 32 ETH u Beacon Chain ugovor o depozitu kako biste aktivirali novi validator
• Generirajte ključeve za obavljanje dužnosti validatora (provjera transakcija, potvrđivanje blokova, prikupljanje potvrda i predlaganje blokova)
• Postavite čvor validatora i sinkronizirajte klijenta izvršnog sloja (EL) i sloja konsenzusa (CL)
• Neka vaš validator bude online i ispravno radi kako biste izbjegli kazne

Postoji više koraka ( česta pitanja o validatoru Staking Launchpada imaju sjajan pregled za potencijalne validatore), ali ovo su otprilike najvažniji aspekti pokretanja validatora. Važno je da solo staking ne zahtijeva posrednika ili drugu stranu i omogućuje vam da zadržite 100% nagrada primljenih od potvrđivanja (potvrđivanje blokova i predlaganje blokova) na Beacon Chain-u. Ali to nije besplatan ručak: vi ste odgovorni za upravljanje svojim validatorom i trebat će vam određena razina tehničke stručnosti za samostalno vođenje operacije iskolčenja.

Ako ideja o upravljanju validatorom zvuči teško, možete krenuti putem delegiranog stakinga. I dalje ste odgovorni za pružanje 32 ETH za registraciju novog validatora—samo što sada delegirate odgovornost za rad validatora na treću stranu. Operater čvora validatora pruža ono što bi neki opisali kao "uslugu bijelih rukavica" i zahtijeva naknadu za ovu uslugu. Na primjer, možda ćete morati podijeliti dio nagrada vašeg validatora s operaterom čvora kao dio početnog ugovora.

Dio "bijele rukavice" znači da operater preuzima odgovornost za održavanje vašeg validatora operativnim i sigurnim—što znači da možete raditi stvari poput streamanja Netflixa u petak navečer (ili što god radite u slobodno vrijeme) bez brige o kaznama zbog propuštanja dužnosti validatora ili brinete o sigurnosti vaših ključeva validatora.

Međutim, postoji upozorenje: delegirano ulaganje zahtijeva povjerenje u operatera čvora kako bi se izbjeglo dovođenje vaših 32 ETH u opasnost počinjenjem prekršaja koji se može smanjiti (npr. potpisivanje dva sukobljena bloka) ili izravnom krađom vaših sredstava. Puno se traži—i definitivno nije za ljude s problemima povjerenja—ali dogovor dobro funkcionira većinu vremena kada su operateri čvorova pošteni.

Ali Ethereum nije izgrađen na principu web2 "vjeruj mi brate", zbog čega se "bez povjerenja" i "bez povjerenja" često pojavljuju u razgovorima na kripto-Twitteru i Redditu. Delegirani staking u svom najčišćem obliku sukobljava se s ovim etosom, ali postoji zaobilazno rješenje u načinu na koji se parovi ključeva generiraju tijekom procesa aktivacije novog validatora.

Svaki validator ima dva ključa: ključ za povlačenje i ključ validatora. Ključ za povlačenje je par javno-privatnih ključeva koji je potreban za djelomično ili potpuno povlačenje salda Beacon Chain validatora, ovisno o tome želite li "preskočiti" (povući samo nagrade) ili "izaći" (povući 32 ETH salda + nagrade) . Imajte na umu da se ključ za povlačenje mora ažurirati sa zadanih vjerodajnica BLS ( 0x00 ) na vjerodajnice 0x01 koje upućuju na Ethereum adresu kako bi se omogućilo djelomično ili potpuno povlačenje salda validatora.

Ključ za povlačenje generira se u trenutku polaganja preko sučelja kao što je Staking Launchpad i raspršuje se kako bi se stvorio ID povlačenja koji je uključen u podatke o pologu validatora—koji Beacon Chainu daje informacije o tome tko je položio 32 ETH. Donja infografika od Protecting Withdrawal Keys by Attestant pruža sjajan pregled kako je ključ za isplatu integriran u postupak zahtjeva za depozit validatora:

Ključ validatora je javno-privatni par ključeva koji je potreban za izvršavanje dužnosti koje se očekuju od svakog validatora Ethereuma—prvenstveno glasanje za blokove i predlaganje blokova za druge da glasaju ("glasovanje" i "potvrđivanje" koriste se naizmjenično, ali se odnose na isti koncept provjere transakcija i potvrđivanja valjanosti blokova). Javni ključ validatora služi kao njegov jedinstveni kriptografski identitet u protokolu konsenzusa Ethereuma, dok se od privatnog ključa očekuje da bude skriven i da se koristi za potpisivanje blok podataka (ključevi validatora se zbog toga opisuju i kao ključevi za potpisivanje).

Sada, za glavnu razliku između validatorskih (potpisnih) ključeva i ključeva za povlačenje:

Ključ za potpisivanje validatora koristi se često—mislite svakih 6,5 minuta ili duljinu intervala tijekom kojeg će svaki validator biti odabran da potvrdi ili predloži blokadu—i najbolje ga je čuvati na mrežnoj lokaciji kojoj je lako pristupiti poput vrućeg novčanika. Međutim, ključ za povlačenje koristi se rjeđe i može se čuvati na sigurnoj, izvanmrežnoj lokaciji poput hladnog novčanika sve dok staker ne želi povući sredstva s adrese za povlačenje koja je povezana s određenim validatorom.

Ova je razlika presudna za smanjenje pretpostavki o povjerenju u delegiranom postavljanju uloga: budući da ključ povlačenja nije potreban za dužnosti provjere valjanosti, nositelj uloga može zadržati kontrolu nad uloženim ETH-om dijeljenjem ključa validatora s operaterom čvora i držanjem ključa povlačenja. Na taj način, lažni operater ne može pobjeći sa stakerovim sredstvima nakon što povuče saldo validatora bez suglasnosti stakera.

Dogovori o delegiranom ulaganju, gdje ulagač drži ključ za isplatu, obično se opisuju kao "neskrbnički" kako bi odražavali da subjekt koji upravlja čvorom validatora u ime ulagača u konačnici nema kontrolu nad uloženim ETH-om. To je u suprotnosti s rješenjima skrbničkog udjela u kojima usluga udjela kontrolira ključeve za potpisivanje i povlačenje; "usluga bijele rukavice na steroidima" dobar je mentalni model za skrbnički ulog: ulagač jednostavno daje 32 ETH za financiranje validatora i delegira sve ostalo—uključujući pokretanje zahtjeva za uplatu validatora i pohranjivanje ključeva za isplatu—uslugu ulog).

Odvajanje ključeva za potpisivanje validatora od ključeva za povlačenje teoretski rješava problem povjerenja u delegiranim ugovorima o ulogu. U praksi, odnos između operatera čvora i stakera u postavci udjela bez skrbništva još uvijek ima element povjerenja zbog trenutnog mehanizma za povlačenje validatora i pokretanja potpunog ili djelomičnog povlačenja salda validatora na adresu za povlačenje.

Za povlačenje validatora iz Beacon Chaina, "Poruka o dobrovoljnom izlazu" (VEM) potpisana ključem validatora mora se predati za obradu na sloju konsenzusa. Nakon što je uključena u blok (svaki blok može uključivati najviše 16 operacija zahtjeva za povlačenje), poruka o povlačenju dodaje se u red čekanja zahtjeva za povlačenje — pri čemu na odgodu konačnog povlačenja utječu čimbenici, kao što su y broj povlačenja u redu ili validator churn rate.

Naglasio sam zahtjev da se potpiše zahtjev za dobrovoljnim povlačenjem ključem za potpisivanje validatora kako bih istaknuo problem s postojećim rješenjima za ulaganje "ne-skrbništva": staker se mora osloniti na operatera čvora—koji kontrolira ključ validatora potreban za potpisivanje VEM-a—da obraditi zahtjeve za isplatu. Ovo učinkovito ponovno uvodi povjerenje u odnos između operatera čvorova i usluga udjela; što je još gore, izlaže stakere riziku da budu "ožalošćeni" od strane zlonamjernih operatera čvorova.

U napadu žalosti , cilj napadača je uzrokovati gubitke za drugu stranu - ne nužno imati izravnu korist. Da ovo stavimo u kontekst, razmotrimo scenarij u kojem Alice delegira Boba da upravlja validatorom u njezino ime, ali kasnije odlučuje povući svojih 32 ETH. Bob bi mogao ispuniti Alicein zahtjev i pokrenuti zahtjev za povlačenje potpisivanjem Poruke o dobrovoljnom izlasku (VEM)…ili odbiti potpisati poruku sa zahtjevom za povlačenje i zaustaviti Aliceinu operaciju povlačenja. Bob neće imati izravnu korist od odbijanja Aliceina zahtjeva—sve što može učiniti je držati Alicein ETH “taocem” odbijanjem pomoći Alice da povuče svoj validator.

U redu, to nije 100% točno; Bob može učiniti mnogo loših stvari da Alice izazove još više "tuge":

1. Smanjite Alicein saldo validatora namjernim činjenjem prekršaja koji se može rezati ili dobivanjem kazni. Pojedinačna kazna za neispunjavanje dužnosti validatora (npr. nedostaju potvrde) ili počinjenje prekršaja koji se može smanjiti (npr. potpisivanje dva sukobljena bloka u istom utoru) obično je niska, ali se povećava proporcionalno broju validatora koji počine slične prekršaje u istom razdoblju. . Na primjer, nedostatak jedne ili dvije potvrde smanjit će stanje validatora za mali dio, ali to smanjenje se eksponencijalno povećava ako dođe do curenja neaktivnosti — gdje je više validatora izvan mreže.

   
   

Prema trenutnom mehanizmu, zlonamjerni Bob može smanjiti Alicein saldo validatora od 32 ETH do 50 posto podvrgavanjem kaznama i rezovima sve dok se validator nasilno ne povuče iz konsenzusa Beacon Chaina (nakon što njegov efektivni saldo padne na 16 ETH). Ako upotrijebimo 1 ETH = 2000 USD, Bobov napad koji tuguje koštat će Alisu najmanje 32 000 USD (16 ETH) u normalnom slučaju (bez koreliranih kazni) i 64 000 USD (32 ETH) u najgorem scenariju (tj., kada cijeli saldo može biti smanjen zbog korelacijskih kazni).

Onaj tko može uništiti stvar, kontrolira stvar. - Paul Atreides (Dina)

1. Zahtijevajte otkupninu od Alice u zamjenu za nepočinjanje kaznenog djela. Ovo se baš ne slaže s prethodnom definicijom tugovanja, ali uzmite u obzir da je Bobov jedini izlaz spaliti ETH ako Alice odluči igrati tvrdoglavo. Situacija se stoga razlikuje od uobičajenih vrsta napada gdje je cilj (uvijek) profit uz minimalni gubitak.

Napomena: Bob (operator čvora) može zapravo biti pošten u ovom scenariju, ali protivnik bi mogao kompromitirati ključ validatora i držati Alicein ETH kao taoca. Ovo objašnjava "rizik druge strane" koji korisnici platforme za ulaganje kao uslugu (SaaS) moraju snositi i još je jedan razlog zbog kojeg se samostalno ulaganje - sa svojim etosom "vjeruj nikome osim sebi" - smatra zlatnim standardom za ulagače u Ethereum .

Znači li to da svaka neskrbnička usluga zapravo nije neskrbnička? Ne baš. Jednostavno zaobilazno rješenje je da usluga stakinga unaprijed potpiše poruku sa zahtjevom za dobrovoljnu isplatu — po mogućnosti nakon što se validator aktivira na Beacon Chain-u — koju staker može neovisno poslati konsenzusnom čvoru Ethereuma kad god želi povući se.

Prethodnim potpisivanjem dobrovoljnih zahtjeva za povlačenje za stakera, dogovor između stakera i operatera čvora vraća se na izvorni status bez skrbništva. Međutim, unaprijed potpisane poruke zahtjeva za povlačenje nisu održive iz mnogo razloga:

Problemi s unaprijed potpisanim zahtjevima za isplatu za uloge bez skrbništva

Složenost

Radni tokovi unaprijed potpisanih zahtjeva za povlačenje zahtijevaju veću komunikaciju između operatera usluge stakinga i delegata uloga: morate podnijeti zahtjev za poruku sa zahtjevom za povlačenjem i pričekati da usluga stakinga pošalje potpisane zahtjeve za povlačenje. Tu je i problem sigurnosti prilikom korištenja i razmjene unaprijed potpisanih zahtjeva za isplatu:

• Usluga stakinga mora poduzeti dodatne mjere opreza—kao što je šifriranje poruke sa zahtjevom za isplatu i njezino dijeljenje preko sigurnog (izvan lanca) komunikacijskog kanala—kako bi spriječila da poruke sa zahtjevom za isplatom padnu u pogrešne ruke.
• Staker mora poduzeti dodatne mjere opreza kako bi pohranio poruku sa zahtjevom za povlačenje na sigurno mjesto jer je gubitak poruke sa zahtjevom za povlačenje jednak potencijalnom gubitku mogućnosti samostalnog povlačenja salda validatora.

Osim toga, unaprijed potpisani zahtjevi za isplatu trenutno vrijede za dva forka Ethereuma ili ~12 mjeseci—ako očekujete da će se forkovi događati otprilike svakih šest mjeseci. To znači da staker mora ponovno podnijeti zahtjev za dobrovoljni zahtjev za povlačenje operateru usluge stakinga više puta u jednoj kalendarskoj godini. Međutim, to više neće biti slučaj kada se implementira EIP-7044 i potpisani zahtjevi za povlačenje validatora postanu valjani na neodređeno vrijeme.

EIP-7044 rješava problem istjecanja izlaznih poruka, ali uvodi novi skup problema—posebno za velike skupove uloga. Za pozadinu, trenutni pristup u decentraliziranim skupovima za ulaganje zahtijeva od novih operatora čvorova validatora da dostave unaprijed potpisane zahtjeve za isplatu prije nego što ih skup financira. Ovdje potpisani zahtjevi za isplatu pružaju kriptoekonomsku sigurnost budući da smanjuju moć (nepouzdanog) operatera nad sredstvima validatora; staking pool može pokrenuti zahtjev za povlačenje od operatera čvora validatora koji ne surađuje podnošenjem unaprijed potpisanog zahtjeva za povlačenje u lancu.

Ali operater čvora validatora neće se baš osjećati ugodno ako su unaprijed potpisani zahtjevi za povlačenje pohranjeni na nasumičnom poslužitelju zbog rizika da netko slučajno/namjerno pokrene lažne zahtjeve za povlačenjem dolaskom do potpisane izlazne poruke. U najgorem slučaju, prisilni izlazi vjerojatno bi rezultirali gubitkom za operatora čvora validatora (npr. ako ste uzeli zajam uz buduće Beacon Chain nagrade). To znači da skupovi za ulaganje moraju poduzeti još više sigurnosnih mjera i sigurno pohraniti poruke zahtjeva za isplatu, posebno u svijetu nakon EIP 7044 gdje potpisani zahtjevi za isplatu imaju beskonačne datume isteka.

Potencijalno rješenje je šifriranje potpisanih zahtjeva za povlačenje zajedničkim javnim ključem generiranim putem DKG (Distributed Key Generation) protokola i zahtijevanje kvoruma dijeljenih ključeva za rekonstrukciju privatnog ključa prije nego što se zahtjev za povlačenjem može dešifrirati. Ovo smanjuje pretpostavku povjerenja koja dolazi s jednom stranom koja pohranjuje zahtjeve za isplatu, pod uvjetom da nitko ne kontrolira dovoljno dijeljenih ključeva za jednostrano dešifriranje unaprijed potpisanih zahtjeva za isplatu bez unosa drugih sudionika. Ali pojavljuje se rubni slučaj ako se jedan ili više dijeljenih privatnih ključeva izgubi, izgubi ili ukrade—što otežava ili potpuno onemogućuje dešifriranje potpisanog zahtjeva za povlačenje ako aktiviranje povlačenja validatora postane neophodno.

Usklađenost s propisima

Staking usluge dobile su dosta nadzora od abecedne juhe regulatora, ponajviše od SEC-a (Komisija za vrijednosne papire i burze) koju vodi kriptovalutni neprijatelj broj 1: Gary Gensler. Na primjer, Kraken je ranije ove godine zatvorio svoju skrbničku operaciju staking-as-service i platio 30 milijuna dolara kazne za “nuđenje neregistriranih vrijednosnih papira putem svoje platforme za kripto staking”.

U teoriji, usluga udjela bez skrbništva vjerojatno neće biti uhvaćena na nišanu SEC-a zbog prirode sporazuma s vlasnikom udjela bez skrbništva:

1. Polog od 32 ETH (ili višekratnik od 32 ETH) za aktiviranje validatora dolazi s adrese za isplatu koju kontrolira staker—a protokol identificira adresu za povlačenje kao vlasnika pologa od 32 ETH. To znači da usluga udjela bez skrbništva ne može povući saldo validatora i "pomiješati novac korisnika sa svojim vlastitim" kao što je SEC optužio Kraken da radi.

U razmjeni kao što je Kraken, saldo korisnikovog novčanika je "virtualan" jer se sva sredstva korisnika drže u jednom ili više novčanika koje kontrolira burza. Dakle, ako uložite 32 ETH putem skrbničke usluge koju vodi mjenjačnica, ono što stvarno imate je IOU od mjenjačnice kojom se obećava da ćete vratiti 32 ETH (plus postotak nagrada validatora) kad god želite podići.

1. Stakeri mogu samostalno povlačiti sredstva podnošenjem unaprijed potpisanih izlaza bez rizika da će lažna staking usluga spriječiti isplate. Nasuprot tome, skrbnička usluga udjela—posebno burza kao što je Kraken—ima kontrolu nad imovinom ulagača i može blokirati isplate iz proizvoljnih razloga.

Ove dvije činjenice uklanjaju potrebu za “zaštitom investitora”; Nisam stručnjak za politiku, stoga se ispričavam za pogreške u ovom rezoniranju. Ali još uvijek može postojati mala bora ili dvije ako danas vodite institucionalnu uslugu udjela bez skrbništva:

• U kratkom (ili vjerojatno dugom) razdoblju između aktiviranja validatora i slanja unaprijed potpisanog dobrovoljnog izlaza stakeru, staking servis kontrolira 32 ETH—što ga čini "skrbničkim" u očima regulatora. Dodatno otežavaju problem kratki rokovi isteka unaprijed potpisanih izlaza (prije EIP 7044): između vremena kada je nova izlazna poruka potpisana i poslana stakeru, operator čvora validatora ima određenu kontrolu nad uloženim ETH-om.
• Dok se redovite izlazne poruke emitiraju u lancu i mogu se javno provjeriti, unaprijed potpisani izlaz mora biti šifriran i privatno podijeljen izvan lanca između operatera čvora i stakera. Ovo otežava trećoj strani kao što je regulatorno tijelo da potvrdi da je servis za ulaganje doista potpisao namjeru izlaska kao dio početnog sporazuma o depozitu validatora—ili ako se razmjena ponovila nakon što je izvorna poruka o izlasku istekla (tj. prije -EIP 7004).

Ukratko: unaprijed potpisani izlazi ublažavaju neke probleme s delegiranim ulogom, ali nisu dovoljni da bi ulog na Ethereumu bio pouzdan, siguran i decentraliziran. Da bismo "ne-skrbničko" vratili u ne-skrbnički ulog, potrebno nam je bolje rješenje—koje sada imamo, zahvaljujući EIP-7002. Sljedeći odjeljci će detaljno pokriti EIP-7002 i dotaknuti razne prednosti EIP-a kao i potencijalne probleme povezane s njegovom implementacijom.

Pregled EIP-7002: povlačenja koja se aktiviraju na izvršnom sloju

EIP-7002 rješava problem principal-agent u delegiranom ulaganju—gdje ulagači moraju vjerovati operaterima čvora validatora da će unaprijed potpisati zahtjeve za povlačenje ili poštovati buduće zahtjeve za povlačenje—uvođenjem nove operacije dobrovoljnog povlačenja koja se može pokrenuti vjerodajnicom za povlačenje validatora. To omogućuje ulagačima da povuku uloženi ETH bez oslanjanja na entitet koji drži ključ za potpisivanje validatora (tj. uslugu udjela u delegiranoj postavci ulog) za obradu povlačenja.

Ključna značajka EIP-7002 je uvođenje ugovora o zahtjevu za povlačenje validatora koji održava red čekanja zahtjeva za povlačenje validatora koji potječu iz izvršnog sloja. U intervalima se određeni broj zahtjeva za isplatu uklanja iz reda čekanja i dodaje zahtjevu za izvršenje bloka Beacon Chain. To omogućuje da se zahtjevi za isplatu iz izvršnog sloja "ubrizgaju" u konsenzusni sloj i obrade kao dio Beacon Chain operacija—slično kao što se depoziti koji potječu iz depozitnog ugovora prosljeđuju iz izvršnog sloja u konsenzusni sloj na obradu.

Zahtjevi za povlačenje redovite su Ethereum transakcije s ugovornom adresom validatora kao ciljem i ukazuju na namjeru povlačenja validatora (prepoznatog njegovim javnim ključem). Poruka o povlačenju validatora valjana je ako (a) je potpisana Ethereum adresom navedenom u vjerodajnici za povlačenje izvršnog sloja validatora ( 0x01 ) (b) validator koji se povlači aktivan je na Beacon Chain-u. Ove provjere izvršava sloj konsenzusa nakon što zahtjev za povlačenjem stigne do Beacon Chaina; ugovor o zahtjevu za povlačenje validatora samo potvrđuje ako transakcija zahtjeva za povlačenje plaća dovoljno goriva u trenutku kada staker poziva ugovor o zahtjevu za povlačenje.

Svi zahtjevi za povlačenje izvršnog sloja obrađuju se na isti način kao redovita operacija zahtjeva za dobrovoljnim povlačenjem koja se pokreće iz sloja konsenzusa, čime se čuvaju invarijante oko maksimalno dopuštenih zahtjeva za povlačenje iz povlačenja aktivnog validatora. Mehanizam unutar protokola EIP-7002 za prijenos zahtjeva za povlačenje između izvršnog i konsenzusnog sloja također uklanja potrebu za vezama na konsenzusni čvor za pokretanje zahtjeva za povlačenje (što je potrebno za povlačenje validatora s unaprijed potpisanim zahtjevima za povlačenje). Validatori se sada mogu financirati i povlačiti s iste adrese izvršnog sloja, što objašnjava imenovanje EIP-a kao "Povlačenja koja se aktiviraju izvršnim slojem".

Nakon što smo vidjeli kako EIP-7002 radi na visokoj razini, sada možemo zadubiti u sitnije detalje EIP-a. Sljedeći odjeljak će pokriti trenutnu specifikaciju EIP-7002 i raspravljati o ključnim aspektima mehanizma zahtjeva za povlačenje validatora. Ako biste radije preskočili tehničku raspravu i istražili prednosti implementacije EIP-7002, možete prijeći na sljedeći odjeljak—koji ističe neka od poboljšanja korisničkog iskustva (UX) koja EIP-7002 omogućuje.

Validatorske operacije zahtjeva za povlačenje

Prema EIP-7002, zahtjev za povlačenje validatora (definiran u pseudokodu kao add_withdrawal_request() ) je CALL na ugovornu adresu zahtjeva za povlačenje validatora. Transakcijsko polje za pozive na ugovor o zahtjevu za isplatu validatora ima dvije vrijednosti:

• source_address : 20-bajtna vrijednost koja predstavlja adresu za povlačenje koja je pokrenula transakciju
• validator_pubkey : 48-bajtna vrijednost koja predstavlja javni ključ validatora iz kojeg treba izaći

Nakon što staker pozove ugovor o zahtjevu za povlačenjem s validator_pubkey kao ulazom, ugovor o zahtjevu za povlačenjem za validator pokreće sljedeće operacije (kasnije ću proći kroz ključne dijelove ove operacije):

• Potvrđuje da transakcija plaća dovoljno goriva da pokrije EXIT_FEE
• Povećava brojač izlaza ( EXIT_COUNT ) za jedan za trenutni blok
• Umeće izlaznu poruku u red čekanja
• Povećava višak povlačenja za trenutni blok ( EXCESS_EXITS ) za jedan
• Vraća novac pozivatelju — ako je preplatio gorivo — prosljeđujući naknadu od 2300 goriva ( EXCESS_RETURN_GAS_STIPEND )

Važan detalj: ugovor o zahtjevu za povlačenje validatora ne provjerava je li source_address važeća adresa za povlačenje za validator identificiran pomoću validator_pubkey , niti provjerava je li validator_pubkey . Ovo otkriva suptilan sigurnosni problem koji se može pojaviti ako napadač ispuni red čekanja porukama koje su osuđene na neuspjeh; ovo je primarno napadački napad s ciljem sprječavanja obrade legitimnih zahtjeva za isplatu. EIP-7002 rješava ovaj problem naplaćivanjem dinamički prilagođene naknade za transakcije zahtjeva za povlačenje (o mehanizmu naknade za povlačenje raspravlja se kasnije).

Maksimalna i ciljna povlačenja po bloku

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK je broj zahtjeva za povlačenje izvršnog sloja koji se mogu uključiti u blok Beacon Chain. Ova je vrijednost trenutačno postavljena na 16 za zrcaljenje sličnih operacija na Beacon Chain-u, kao što je VoluntaryExit (operacije izlaza koje se pokreću izravno iz sloja konsenzusa ključem validatora stakera).

U specifikaciji se također napominje da postavljanje MAX_WITHDRAWAL_REQUESTS_PER_BLOCK na 16 ograničava veličinu nosivosti izvršenja – i proširenjem, veličinu blokova Beacon Chain – i smanjuje opterećenje obrade izlaznih operacija na sloju konsenzusa. Ovo je korisno jer možemo očekivati da će neki dionici nastaviti izlaziti iz validatora koristeći trenutni mehanizam pokretanja izlaza iz sloja konsenzusa (tj. putem unaprijed potpisanih izlaza ili poruka o dobrovoljnom izlazu u stvarnom vremenu).

TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK

EIP-7002 teoretski dopušta uključivanje do 16 izlaznih operacija izvršnog sloja u blok, ali cilja na konzervativniju procjenu od dva izlaza po bloku. Prema specifikaciji , TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK postavljen je na 2 kako bi se ograničila stopa odljeva validatora i očuvala nepromjenjivost maksimalno dopuštenih povlačenja po epohi definiranoj Beacon Chain-ovom funkcijom get_validator_churn_limit() - čak i u situacijama kada je sav ETH u optjecaju uložen.

Red čekanja zahtjeva za isplatu Validatora

WITHDRAWAL_REQUEST_COUNT

WITHDRAWAL_REQUEST_COUNT je broj zahtjeva za isplatu uključen u trenutni blok. Nakon svakog uspješnog poziva validatorskom ugovoru o zahtjevu za povlačenjem, vrijednost varijable WITHDRAWAL_REQUEST_COUNT pohranjene u pohrani validatorskog ugovora povećava se za jedan (definirano u pseudokodu kao increment_count() ).

U bilo kojem trenutku, vrijednost WITHDRAWAL_REQUEST_COUNT nalazit će se između TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK (2) i MAX_WITHDRAWAL_REQUESTS_PER_BLOCK (16) ovisno o tome koliko je operacija zahtjeva za povlačenje dodano nosivosti izvršenja bloka. WITHDRAWAL_REQUEST_COUNT također je unos u funkciju koja izračunava iznos koji treba platiti novom operacijom zahtjeva za isplatu ( MIN_WITHDRAWAL_REQUEST_FEE ).

PREVIŠENI ZAHTJEVI ZA POVLAČENJE

EXCESS_WITHDRAWAL_REQUESTS je razlika između MAX_WITHDRAWAL_REQUESTS_PER_BLOCK i TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK - broj zahtjeva za isplatu koji su ostali neiskorišteni zbog trenutne blokade. Kao što je spomenuto, svaki blok može uključivati najviše 16 zahtjeva za povlačenjem, ali cilja dva zahtjeva za povlačenjem u normalnim situacijama, tako da je EXCESS_WITHDRAWAL_REQUESTS ekvivalent "razlici između broja zahtjeva za povlačenjem koji blok teoretski može potrošiti i koliko zahtjeva za povlačenjem stvarno koristi".

Brojač viška ugovora o zahtjevu za povlačenje ažurira se na temelju upotrebe zadnjeg bloka i jedan je od faktora (između ostalih) koji određuje naknadu plaćenu transakcijom koja poziva validator ugovora o zahtjevu za povlačenje. Time se osigurava da se cijene naknada za povlačenje određuju prema trenutnoj upotrebi, što je slično EIP-1559 izračunu base_fee za novi blok koji se izračunava na temelju razlike između ciljanog ograničenja plina i plina korištenog u prethodnom bloku.

WITHDRAWAL_REQUEST_QUEUE

WITHDRAWAL_REQUEST_QUEUE je popis svih zahtjeva za isplatu na čekanju (poređanih redoslijedom pristizanja) trenutno pohranjenih u WITHDRAWAL_REQUEST_QUEUE_STORAGE_SLOT ugovora validatora (kao WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT i WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT ). Broj zahtjeva za povlačenje u redu čekanja može biti neograničen, ali promjenjiva stopa MAX_WITHDRAWAL_REQUESTS_PER_BLOCK ograničava koliko se zahtjeva za povlačenje na čekanju može ukloniti iz reda čekanja u svaki blok.

Red zahtjeva za povlačenjem održava indeks "glave" i "repa" - oba se jednostavno odnose na skup zahtjeva blizu početka i kraja reda čekanja - koji se ažurira nakon svakog bloka kako bi se uzela u obzir obrada jednog ili zahtjeva za povlačenje. Ovo je red čekanja prvi ušao, prvi izašao (FIFO), tako da se zahtjevi izvršavaju u skladu s time kada su dodani u red čekanja - što ima sigurnosne implikacije, posebno zbog žalosti poštenih validatora.

Naknade za povlačenje ugovora o validatoru

MIN_WITHDRAWAL_REQUEST_FEE je iznos koji adresa koja zove validator zahtjeva za povlačenje ugovora o povlačenju mora platiti u plinu. Prije umetanja zahtjeva za isplatu u red čekanja, ugovor o zahtjevu za povlačenje validatora provjerava je li naknada za plin priložena transakciji jednaka ili premašuje trenutnu vrijednost od MIN_WITHDRAWAL_REQUEST_FEE - ako transakcija ima ostatak plina nakon uspješnog izvršenja, adresa za slanje se pripisuje točno 2300 plin.

Prema specifikaciji, ovaj dizajn slijedi sada zastarjelu značajku u Solidityju, gdje pozivanje funkcije fallback() u odredišnom ugovoru ili slanje ETH putem transfer() ili send() prosljeđuje stipendiju od 2300 gasa primatelju. Promjene u troškovima plina (počevši od račvanja Berlin/Istanbul) smanjile su korisnost ove značajke (pročitajte Stop Using Solidity's transfer() Sada malo konteksta), ali izvorna ideja o jednostavnom sustavu obračuna plina i dalje je korisna. U kontekstu EIP-7002, slanje fiksnog povrata od 2300 gasa pojednostavljuje mehanizam naknade za ugovor o zahtjevu za povlačenje validatora.

Alternativa je osmisliti poseban mehanizam koji omogućuje da se ugovorom o zahtjevu za povlačenje vrati maksimalna količina plina preostalog od transakcije. To bi imalo smisla, posebno u slučajevima kada je adresa za povlačenje EOA - pametni ugovori mogu izračunati precizne vrijednosti za MIN_WITHDRAWAL_REQUEST_FEE provjerom stanja ugovora, ali EOA će vjerojatno poslati više gasa za svaki poziv na ugovor sa zahtjevom za povlačenje. Ova ruta dodaje više složenosti dizajnu EIP-7002 u odnosu na upotrebu jednostavnog CALL za prosljeđivanje fiksne količine plina kao povrat novca; iako autori EIP-7002 sugeriraju da bi ova značajka mogla biti uključena u konačnu specifikaciju ovisno o povratnim informacijama dionika.

Izračun od MIN_WITHDRAWAL_REQUEST_FEE mjesto je gdje stvari postaju zanimljive. Naknada za zahtjev za isplatu je dinamična i dizajnirana da odgovori na mrežne uvjete, slično osnovnoj naknadi koju je uveo EIP-1559, a funkcija je tri varijable:

• Minimalna (osnovna) naknada za povlačenje: MIN_WITHDRAWAL_REQUEST_FEE
• Broj suvišnih povlačenja u trenutnom bloku: EXCESS_WITHDRAWAL_REQUESTS
• Formula ažuriranja naknade za zahtjev za povlačenje: WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION

Poput EIP-1559 base_fee , izlazna naknada za ugovor o povlačenju validatora je mehanizam koji ograničava stopu: u prosječnom slučaju (dva zahtjeva po bloku), svatko tko poziva ugovor o zahtjevu za povlačenje validatora može očekivati plaćanje minimalne naknade za povlačenje, ali trošak operacija povlačenja postupno povećava sve više zahtjeva za povlačenje uključeno je u blok. To se može zaključiti iz službene specifikacije EIP-7002 za ažuriranje naknade za zahtjev za isplatu : withdrawal_request_fee = MIN_WITHDRAWAL_REQUEST_FEE * e**(excess_withdrawal_requests / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) .

Objašnjenje mehanizma naknade za zahtjev za isplatu iz specifikacije:

“Ponašanje blok po blok je otprilike sljedeće: Ako blok N obrađuje X zahtjeva za isplatu, onda se na kraju bloka N excess_withdrawal_requests povećava za X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK , i tako se naknada za zahtjev za povlačenje u bloku N + 1 povećava za faktor e**((X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK) / (WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) , dakle, ima sličan učinak kao postojeći EIP-1559, ali je "stabilniji" u smislu da odgovara na isti način na iste ukupne zahtjeve za povlačenje bez obzira na to kako su raspoređeni tijekom vremena. .”

Postupnim povećanjem naknade za zahtjev za povlačenje u skladu s korištenjem ugovora o zahtjevu za povlačenje validatora, EIP-7002 smanjuje rizik da napadač namjerno popuni red čekanja zahtjeva za povlačenje kako bi spriječio druge validatore u povlačenju. Poruke o opozivu u redu čekanja zahtjeva za isplatu uklanjaju se iz reda čekanja i u stilu prvi-ušao-prvi-izišao (FiFo) za razliku od, recimo, zadnji-ušao-prvi-izišao (LiFo) ili narudžbe s najvećom isplatom transakcije-prve. Iako možemo pretpostaviti da će cijene plina spriječiti nepotrebne pozive na ugovor o zahtjevu za povlačenje, zlonamjerni napadač bi mogao biti voljan platiti više goriva da "napuni" red čekanja zahtjeva za povlačenje i gurne zahtjev za povlačenje drugog validatora na kraj reda.

Problem je dodatno kompliciran centralizacijom izgradnje blokova u Ethereumu nakon spajanja. Ako je napadač integriran s jednim ili više dominantnih graditelja (za kontekst: 80-90% blokova do danas na Ethereumu proizvelo je 4-5 graditelja ) i voljan je platiti za uključivanje na vrhu bloka, oni može učinkovito pokrenuti zahtjeve za povlačenje od jednog ili više sudionika i spriječiti pravovremena povlačenja validatora iz Beacon Chaina.

I zašto bi itko prolazio kroz sav taj stres? Moguća motivacija može biti da napadač želi ožalostiti sudionike koji žele povući validatore koristeći vjerodajnice za povlačenje. Za korištenje prethodnog od Boba (zlonamjernog) operatera čvora i Alice ulagača: Alice može brzo povući svoj validator kako bi zaustavila Bobov bolni napad pozivanjem ugovora o zahtjevu za povlačenje validatora s vjerodajnicom za povlačenje - ali Bob još uvijek može dati više od sebe da procuri Alicein saldo validatora spamom ugovora o zahtjevu za povlačenjem validatora i odgađanjem Alicinog zahtjeva za povlačenjem.

Struktura bloka i valjanost

EIP-7002 malo mijenja strukturu i provjeru valjanosti Beacon blokova zahtijevajući da se zahtjevi za povlačenje stave u stvarno tijelo bloka (i nosivost izvršenja u sloju konsenzusa). Zahtjevi moraju biti ugrađeni u nosivost izvršenja tako da kad god je sloj konsenzusa nedostižan, sloj konsenzusa i dalje ima potrebne podatke za potpuno izvršenje dijela konsenzusa funkcije prijelaza stanja.

EIP-7002 također dodaje nove uvjete valjanosti za blokove. Prvo, popis zahtjeva za isplatu ( withdrawal_requests_list ) ne može premašiti MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . Drugo, popis zahtjeva za povlačenje mora odgovarati broju zahtjeva za povlačenje koji su isključeni iz reda čekanja iz WITHDRAWAL_REQUEST_QUEUE kada su takvi zahtjevi raspoređeni po redoslijedu prvi ušao, prvi izašao (FiFO).

EIP-7002 ima funkciju ( expected_exit ) za potvrdu da blok ne uključuje više zahtjeva za povlačenje od rezultata izračunavanja NUM_WITHDRAWAL_REQUESTS_IN_QUEUE - MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . Također, konsenzusni čvor koji ponovno izvršava blok neovisno će izračunati kodiranje zahtjeva za povlačenje iteracijom request_type i request_data u usporedbi s predanošću hash liste zahtjeva za povlačenje.

Zašto EIP-7002? Slučaj za povlačenja koja se mogu aktivirati na sloju izvršenja

Smanjene pretpostavke povjerenja u delegiranom udjelu

U uvodu sam primijetio kako je oslanjanje na validatorov ključ za potpisivanje za pokretanje izlaza validatora uvelo problem povjerenja; Nisam uključio definiciju povjerenja, ali ova definicija iz Vitalikova članka Modeli povjerenja to lijepo sažima: “Povjerenje je svaka pretpostavka(e) koju imate o ponašanju drugih ljudi”. Prijavom na uslugu stakinga, znajući da zlonamjerni operater čvora može zamrznuti isplate, staker u biti vjeruje operateru čvora da će postupati vjerno.

EIP-7002 ne uklanja u potpunosti element povjerenja u delegiranom ulogu—još uvijek morate vjerovati operateru čvora da neće izvršiti žalosni napad—ali omogućavanje ulagačima da se povuku s vjerodajnicama za povlačenje u određenoj mjeri smanjuje teret povjerenja. Na primjer, korisnik ne treba "vjerovati" da će operater čvora potpisati poruku o dobrovoljnom izlazu nakon što to zatraži.

Suptilna točka u vezi s "nepouzdanjem" je da se ne radi nužno o izbjegavanju potrebe za povjerenjem, već o tome da ne treba vjerovati jer (a) postoje jaki poticaji za sve strane da djeluju pošteno (b) poštene strane imaju određenu količinu zaštita od radnji nepoštenih stranaka. Mogućnost povlačenja validatora s vjerodajnicama za povlačenje primjer je potonjeg: Bob može pokušati ožalostiti Alice, ali sada Alice ima agenciju za povlačenje svog validatora, nadajmo se prije nego što Bob napravi još štete.

Bolje upravljanje rizikom za skupove uloga

Trenutačno skupovi za ulaganje nemaju načina natjerati operatora čvora validatora da se povuče—što doprinositelje skupa stavlja u neugodan položaj da vjeruju operaterima čvorova da će postupati pošteno. Neki decentralizirani skupovi za ulaganje zahtijevaju od operatera čvorova da osiguraju obveznicu, ali s obzirom na mogućnost da zlonamjerni operater bude smanjen na 0 ETH, sigurnost iz obveznice mogla bi biti neadekvatna u očima ulagača nesklonog riziku.

S postavljenim EIP-7002, skupovi udjela mogu uvelike smanjiti pretpostavke o povjerenju nadopunjavanjem sigurnosti od prijetnje smanjenja kolaterala operatora čvora s postupcima za prisilno povlačenje operatora koji se loše ponaša putem povlačenja izvršnog sloja. Mogućnost povlačenja vjerodajnica koje upućuju na adresu pametnog ugovora (umjesto EOA) također otvara nove dizajne odgovora na incidente za skupove uloga—na primjer, pametni ugovor mogao bi automatski podnijeti zahtjev za povlačenje ako operater dobije kazne veće od prosjeka unutar vremenski prozor. Međutim, to zahtijeva povjerenje u proročanstvo za praćenje performansi validatora i mrežu čuvara za pokretanje pametnog ugovora.

Druga hipotetska korist za skup uloga od implementacije EIP-7002 je izbjegavanje potrebe za traženjem i pohranjivanjem unaprijed potpisanih poruka o povlačenju, što dolazi s rizicima kao što sam prethodno objasnio (npr. neovlašteni pristup porukama o povlačenju može rezultirati neočekivanim validatorom povlačenja). To također pridonosi cilju dizajniranja nepovjerljivih skupova uloga: za razliku od oslanjanja na unaprijed potpisane zahtjeve za isplatu pohranjene od strane nekoliko (pouzdanih) pojedinaca, pametnim ugovorom označenim kao adresa za isplatu može se upravljati upravljanjem - omogućujući zajednici da odlučuje javno i transparentno povući operatera čvora.

Bolje upravljanje rizikom za postavke DVT-a

Tehnologija distribuiranog validatora (DVT) smatra se kritičnim dijelom Ethereumove infrastrukture za ulaganje iz mnogo razloga:

• DVT smanjuje prepreke za samostalno ulaganje: Više pojedinačnih ulagača može zajedno udružiti sredstva kako bi zajednički aktivirali validator bez potrebe da vjeruju svakoj drugoj strani. Sheme multiparty computation (MPC) mogu tolerirati do ⅓ neispravnih čvorova—pa ako hipotetski distribuirani validator zahtijeva 3 od 5 zajedničkih ključeva za rekonstrukciju ključa za potpisivanje validatora, potpisivanje se može dogoditi ako su dva DVT čvora izvan mreže.
• DVT poboljšava toleranciju na pogreške i otpornost za institucionalne/samostalne postavke udjela: Kao što je gore spomenuto, ključ za potpisivanje validatora može se podijeliti na različite dijeljene ključeve i rekonstruirati samo kada su potrebni podaci o bloku za potpisivanje. Time se smanjuje rizik da haker ugrozi ključ za potpisivanje validatora ili da dioničar izgubi pristup sredstvima jer je uređaj koji pohranjuje ključ za potpisivanje oštećen.

Međutim, postavke DVT-a još uvijek nose određeni rizik za stakere zbog načina na koji isplate i izlasci trenutno funkcioniraju na Beacon Chainu. Ako neki DVT čvorovi zagube dijeljenje ključeva ili odbiju sudjelovati u shemi potpisivanja praga, izlazak iz validatora postaje nemoguć—posebice kada:

• Dijeljenje ključeva za svakog sudionika u postavljanju DVT-a generira se u trenutku aktivacije validatora i ne može se "osvježiti" nakon početne DKG ceremonije (imajte na umu da "sudionik" može jednostavno biti drugi EOA u vlasništvu istog stakera); neki DVT protokoli dopuštaju generiranje novih zajedničkih ključeva, iako to može zahtijevati da preostali ključevi zadovolje kvorum potpisa potrebnih za redovito potpisivanje.
• Prag kvoruma—broj dijeljenja ključeva potrebnih za zajedničko generiranje važećeg potpisa za distribuirani validator—ne može se promijeniti nakon što je (distribuirani) validator aktivan.

Bez EIP-7002 koji pruža opciju povlačenja validatora pomoću ključa za povlačenje, korist od pokretanja DVT podešavanja - neovisno ili u suradnji s drugim validatorima - bila bi znatno smanjena (npr. stanje validatora moglo bi biti zauvijek zaključano). EIP-7002 pruža zamjensku sigurnosnu opciju za distribuirane validatore: ako je rekonstrukcija ključa za potpisivanje neizvediva, validator se može povući iz Beacon lanca podnošenjem zahtjeva za povlačenje potpisanog ključem za povlačenje rekonstruiranim iz zajedničkih ključeva.

Bolja usklađenost s propisima: Stavljanje "ne-skrbničkog" udjela u ne-skrbnički ulog

Malo je vjerojatno da su autori EIP-7002 izričito postavili cilj da olakšaju vođenje regulirane institucionalne tvrtke za ulaganje kao uslugu. Unatoč tome, EIP pomaže u problemu uvjeravanja regulatora da institucija nema skrbništvo nad uloženim ETH-om. Operater za ulaganje u ovom scenariju mogao bi jednostavno predstaviti hash transakcije depozita potpisan ključem za povlačenje stakera—koji sada može potpisati i podnijeti dobrovoljne izlaske—kao dokaz da sredstva položena u validator nikada nisu u njegovom nadzoru ni u jednom trenutku.

Naglasio sam "u bilo kojoj točki u vremenu" jer, prije EIP 7044, operater čvora privremeno preuzima kontrolu nad saldom validatora nakon što unaprijed potpisani izlaz istekne. Čak i s trajno važećim potpisanim izlazima EIP-7044, operateri čvorova i dalje imaju skrbništvo nad 32 ETH položena za validator u kratkom razdoblju između aktivacije validatora i stakera koji primi potpisanu poruku o izlazu od operatera usluge stakinga. EIP-7002 uklanja ta neugodna područja i osigurava da ulagači imaju (dokazivo) skrbništvo nad sredstvima tijekom životnog ciklusa validatora—od ulaska u lanac Beacon za podizanje i slanja sredstava na adresu ulagača za povlačenje.

Bolje korisničko iskustvo (UX) za sve

Dobar mentalni model za EIP-7002 je da se o njemu razmišlja kao o " apstrakciji računa za infrastrukturu za ulaganje". Za kontekst, ključ validatora (ili ključ za potpisivanje) uvijek je EOA i dolazi s istim skupom ograničenja oko sigurnosti i upotrebe privatnog ključa koji danas utječu na obične Ethereum EOA:

• Ključevi validatora (potpisivanje) izloženi su većem riziku od ugrožavanja. Za razliku od ključeva za povlačenje pohranjenih u hladnom (izvanmrežnom) skladištu, ključevi validatora pohranjeni su u vrućim novčanicima povezanim s internetom—što ih čini osjetljivima na phishing napade. Ako je ključ za potpisivanje validatora ugrožen, stakeri i delegirani davatelji stakinga osjetljivi su na vektore žalosti opisane u uvodu bez ikakvog zamjenskog plana—osim “pričekajte dok saldo ne padne na 16 ETH i validator se nasilno povuče putem protokola”.
• Ključevi validatora imaju ograničene mogućnosti za sheme oporavka (izgubiti jednom = izgubiti zauvijek). Dijeljenje ključa validatora u više dijeljenih ključeva putem tehnologije distribuiranog validatora (DVT) može ublažiti ovaj rizik, ali pokretanje solo DVT postavljanja uloga nije trivijalno; plus, kao što sam već objasnio, DVT nije srebrni metak jer se dijeljeni ključevi mogu izgubiti i komplicirati osvježavanje dijeljenih ključeva.
• Ključevi validatora ne mogu podržati fleksibilnije dizajne iskolčenja. Različite usluge za ulaganje razvile su automatizirane/fleksibilne tijekove rada za validatore financiranja zbog prednosti usmjeravanja vjerodajnica za povlačenje na pametne ugovore. Međutim, povlačenje validatora je ručni postupak koji zahtijeva potpisivanje poruke o zahtjevu za dobrovoljnim povlačenjem - proces se može automatizirati pametnim ugovorom koji pohranjuje zahtjeve za povlačenje prije potpisa, ali to dolazi s određenim pretpostavkama o povjerenju i sigurnosnim razmatranjima koja su prethodno objašnjena.

Možemo riješiti većinu—ili barem neke—od ovih problema kada ključevi za povlačenje budu mogli izaći iz validatora. Da bi ovo funkcioniralo, staker (ili staking pool) morat će izvršiti jednokratnu promjenu s 0x0 vjerodajnica za povlačenje na 0x01 vjerodajnice za povlačenje—dok su 0x0 vjerodajnice BLS (EOA) ključ prema zadanim postavkama, 0x01 vjerodajnice mogu ukazivati na bilo koji Ethereum adresa, uključujući pametne ugovore i EOA. Postavljanje pametnog ugovora kao adrese za isplatu za validatora izvrsno je za poboljšanje korisničkog iskustva (UX) uloga:

1. Ključevi za povlačenje mogu imati fleksibilne mehanizme oporavka, poput socijalnog oporavka. Staker bi imao jednog ili više "skrbnika" koji mogu ovlastiti novi ključ za kontrolu pametnog ugovora zahtjeva za povlačenje ako je izvorni ključ ukraden ili izgubljen - skrbnici mogu biti prijatelji, rođaci, kolege stakeri ili specijalizirana usluga treće strane. Fleksibilnost u mehanizmima povrata može osobito koristiti solo ulagačima; možete imati mrtvi prekidač koji aktivira EL izlaz i šalje sredstva na naznačenu adresu ako vaš validator prestane ovjeravati na unaprijed određeno razdoblje (npr. zato što ste “prešli u Great Beyond”).

2. Mogu se pojaviti fleksibilni dizajni iskolčenja. Na primjer, ulagač koji je sklon riziku može preferirati ugovor o povlačenju s više potpisa 2-od-2—s ulagačem i operaterom čvora koji drže jedan od dva ključa potrebna za odobravanje zahtjeva za povlačenje—umjesto pohranjivanja cijelog ključa za povlačenje. I dalje nije skrbnički (operator čvora ne može izaći iz validatora bez odobrenja), iako zahtijeva povjerenje u operatera čvora da neće blokirati izlaz validatora odbijanjem potpisivanja transakcija zahtjeva za povlačenje koje je predložio staker.

Za skupove uloga, fleksibilnost u dizajnu uloga može značiti implementaciju ugovora o povlačenju s proizvoljnom logikom za ažuriranje ili prijenos vlasništva validatora. U nedostatku EIP-7002, jedini pravi način na koji skup uloga može upravljati vlasništvom nad validatorima je premještanje unaprijed potpisanih zahtjeva za isplatu, što dolazi s raznim rizicima i rubnim slučajevima.

3. Isplate putem validatora mogu se sigurno automatizirati. Za razliku od pohranjivanja unaprijed potpisanih zahtjeva za povlačenje u pametnom ugovoru, ugovori o zahtjevima za povlačenje mogu imati složena pravila koja uređuju zahtjeve za povlačenje validatora; ideja o "ludoj znanosti" je "bazen uloga temeljen na vremenu" gdje se operateri čvorova nepovjerljivo rotiraju. Ili razmislite o tome želi li se veliki skup uloga kao što je Lido decentralizirati: upravljanje može odlučiti povući neke validatore koje kontrolira veliki operator čvora i redistribuirati sredstva manjim operaterima (ili solo stakerima) kako bi se smanjile točke gušenja od operatera čvora koji kontrolira znatan broj validatori.

Ovo su samo neke od ranih mogućnosti koje EIP-7002 omogućuje, ali vrlo sam siguran da će se pojaviti još aplikacija—baš kao što nove značajke i slučajevi upotrebe pametnih novčanika na Ethereumu nastavljaju izlaziti na površinu. Ako ovo čitate i imate još konkretnih ideja za primjenu EIP-7002 na dizajne iskolčenja, slobodno se javite u komentarima!

Ima li kakvih nedostataka u implementaciji EIP-7002?

Moguće prijelomne promjene postojećih dizajna iskolčenja

U nacrtu EIP-a, autori EIP-7002 priznaju potencijalnu zabrinutost oko omogućavanja vjerodajnica za povlačenje da pokreću povlačenja validatora—ali dalje kažu, "ne znamo ni za jedan dizajn uloga koji se oslanja na ovu značajku [tj. nemogućnost povlačenja s vjerodajnicama za povlačenje]”. Ovo se čini razumnim - čak sam i ja imao poteškoća s razmišljanjem o bilo kakvom dogovoru o delegiranom ulogu koji bi zahtijevao ovu značajku. Ali samo zato što se ne čini očiglednim, ne znači da ne postoji.

“Poslušajte te tihe, mučne sumnje. Ako ne znaš, ne znaš što ne znaš, ne znaš koliko ne znaš i ne znaš koliko si trebao znati.” — Eliezer Yudkowsky

Da pružim malo konteksta, uključit ću snimke zaslona razgovora oko ranog prijedloga za implementaciju izlaza odobrenih vjerodajnicama za povlačenje putem sabirnice generaliziranih poruka (GMB) . GMB je pametni ugovor na razini sustava čije događaje čitaju i obrađuju klijenti, poput trenutnog depozitnog ugovora, i sposoban je prenijeti poruke od izvršnog sloja do konsenzusnog sloja. Dok su autor(i) nagovijestili više generičkih tipova poruka EL-to-CL, glavni predloženi slučaj upotrebe sabirnice poruka EL-to-CL pružao je način pokretanja izlaza iz izvršnog sloja putem 0x01 vjerodajnica za povlačenje.

Iz ove razmjene već imamo primjer odnosa staker-node operatera izgrađenog na pretpostavci da staker ne može izaći i povući validator pomoću ključa za povlačenje. Još jedan primjer potencijalnog rubnog slučaja implementacije EIP-7002 dolazi iz razgovora o Lidovim planovima decentralizacije na Lido Community Staking Podcastu, koji možete gledati na YouTubeu . (EIP-7002 samo se kratko spominje (28:55 do 30:00) u videu).

Za pozadinu, Lido je opisan kao "sustavna prijetnja Ethereumu" jer kontrolira ~ 33,3% validatora Beacon Chaina i mogao bi ugroziti konsenzus Ethereuma; na primjer, ako je Lido DAO prisilio operatere čvora da cenzuriraju transakcije ili vrate prethodno finalizirane blokove (Mike Neuder's Magnituda and direction of Lido attack vectors opisuje prijetnju detaljnije).

Međutim, jedan od govornika u prethodno povezanoj epizodi iznosi uvjerljiv argument da ovaj vektor napada — DAO koji nasilno uključuje operatere čvorova u napad na Ethereum protokol — još ne postoji, budući da operateri čvorova imaju određeno djelovanje. DAO može uskratiti ulog validatora nakon što izađe, ali se ne može osloniti na prijetnju prisilnim izlaskom kako bi se validator natjerao da napadne Ethereum-ov konsenzus.

Uz EIP-7002, dinamika snage značajno se mijenja: ugovori o povlačenju kojima upravlja DAO mogu povući operatora protiv njegovih želja—dajući DAO-u utjecaj nad operaterima čvorova. Ova vrsta poluge korisna je za zaštitu protokola udjela od zlonamjernog skupa operatora, kao što sam već objasnio. Ali također se može zloupotrijebiti u sljedećim scenarijima:

• Protokol udjela trpi napad upravljanja i DAO prosljeđuje zlonamjerni prijedlog za pokretanje povlačenja validatora iz ugovora o povlačenju
• Napadač preuzima kontrolu nad jednim ili više validatora otimanjem vlasništva nad ugovorom o zahtjevu za povlačenje i provodi uspješnu strategiju ucjenjivanja

Ovo je još jedan primjer kako bi EIP-7002 mogao promijeniti postojeće pretpostavke u dizajnu iskolčenja—ovaj put, za operatore čvorova koji provjeravaju valjanost u ime skupa iskolčenja kao što je Lido. Unatoč tome, ovaj vektor napada može se lako ublažiti različitim metodama kao što je upotreba sigurnih, rigorozno revidiranih i možda nenadogradivih ugovora o zahtjevima za isplatu ili slijedeći najbolje prakse za sigurno upravljanje DAO-om .

Kako bi se objasnio rubni slučaj kada operater čvora trpi gubitke od prisilnog povlačenja nakon što je odbio zahtjeve napadača da prekrši pravila protokola, skupovi za ulaganje mogu se nadahnuti nekretninskim tvrtkama kako bi zaštitili operatere čvorova:

• Prije potpisivanja ugovora o najmu, iznajmljivači su dužni položiti "sigurnosni polog". Polog se drži na bankovnom računu izvan kontrole tvrtke za nekretnine.
• Ako se najmoprimac iseli iz stana, ali za sobom ostavi znatnu štetu, tvrtka za nekretnine ima pravo iskoristiti sigurnosni polog za pokriće troškova popravka.
• Ako je stan u trenutku izlaska iznajmljivača u dobrom stanju, polog se u cijelosti vraća iznajmljivaču.

Protokol udjela može usvojiti sličan pristup zaštiti operatera čvora sklapanjem police "fonda osiguranja operatora čvora" putem Nexus Mutual , Tidal Finance ili bilo koje druge kripto izvorne platforme osiguranja. Ako je operatorov validator legitimno povučen, fond osiguranja se vraća DAO-u; ako je obrnuto (npr. povlačenje validatora pokrenuto je zlonamjernim prijedlogom ili greškom u ugovoru o povlačenju), polica osiguranja isplaćuje štetu operateru čvora. Imajte na umu da se ovaj pristup može generalizirati na sve postojeće odnose koji se oslanjaju na trenutne specifikacije za izlazak iz validatora.

Nedostatak podrške za složenije EL-to-CL poruke

Ugovor o zahtjevu za povlačenje validatora EIP-7002 pruža jednu funkciju: slanje zahtjeva za povlačenje iz Ethereumovog izvršnog sloja na konsenzusni sloj za povlačenje validatora. Međutim, neki su predložili implementaciju općeg okvira za razmjenu poruka (npr. predkompilacija SendMessageToConsensusLayer ili ranije spomenuti ugovor na razini sustava Generalized Message Bus (GMB)) za prijenos generičkih tipova poruka između izvršnog sloja i konsenzusnog sloja. To bi moglo imati koristi poput otključavanja novih načina za aktiviranje validatora na Beacon Chain-u, posebno ako je dopušteno prilaganje ETH porukama EL-to-CL.

Međutim, kako Danny Ryan (jedan od autora EIP-7002) objašnjava u komentaru , trošenje dragocjenog inženjerskog vremena na generički okvir za razmjenu poruka EL → CL je "veliki pothvat s nejasnom vrijednošću". Ilustracije radi, autori prijedloga GMB-a (sabirnice općih poruka) identificirali su samo još jedan slučaj upotrebe sabirnice poruka između EL i CL: rotiranje vjerodajnica za povlačenje za validator s 0x0 na 0x01 vjerodajnice.

To znači da je vjerojatnije da ćemo prvo vidjeti isporuku ugovora o zahtjevu za povlačenje validatora prije nego što glavni razvojni programeri razgovaraju o implementaciji opće sabirnice poruka EL-to-CL, ako se to ikada dogodi. Nije da jednostavnost nikad ne boli.

Jednostavnost je preduvjet za pouzdanost. — Edsger W. Dijkstra

Noviji vektori rizika za postojeće stakere

Razradio sam prednosti omogućavanja vjerodajnica za povlačenje za pokretanje povlačenja većim dijelom, ali postoje neki rubni slučajevi povezani s tom značajkom. Ideja ide ovako (h/t ovom komentaru na GitHubu ):

• Ako je ključ za potpisivanje validatora ugrožen, haker može zahtijevati otkupninu ili pokušati smanjiti saldo validatora—ali ne može povući sredstva ni u kojem slučaju. Uslijedit će igra čekanja: hoće li napadač uništiti cijeli saldo ili će staker moći povući neki dio uloga nakon što se validator nasilno povuče?
• Međutim, kada se EIP-7002 implementira, haker u prethodnom scenariju može izaći iz validatora i povući stanje (nakon što se EIP-7002 implementira) umjesto da se zadovolji napadom žaljenja/ucjene.

Ukratko, solo stakeri i usluge stakinga trebat će više zaštite za vjerodajnice za povlačenje nakon EIP 7002. Zbog toga se usvajanje društvenog oporavka, multifaktorske (MFA) autentifikacije i rotacije ključeva smatraju ključnima za poboljšanje sigurnosti za solo/delegirane operacije stakinga.

Izbor mehanizma ograničenja brzine

Funkcionalnost ugovora o zahtjevu za povlačenje validatora add_withdrawal_request() ne provodi nikakve dodatne provjere, osim provjere priložene naknade za zahtjev za povlačenje, potencijalno dopuštajući napadaču da začepi red poruka nevažećim zahtjevima za povlačenje (npr. izlazne poruke za nepostojeći validator ili će neaktivni validator biti poništen tijekom provjera valjanosti sloja konsenzusa). EIP-7002 koristi naknadu za isplatu s dinamičkom cijenom kako bi ograničio zahtjeve za isplatu i učinio takve napade skupima, slično kao što EIP-1559 obeshrabruje spam napade i blokira punjenje prilagodbom cijena goriva na temelju mrežne aktivnosti.

Alternativni dizajn je ograničiti pozive na ugovor o zahtjevu za povlačenje validatora na stvarne validatore—na primjer, provjerom da validator_pubkey odgovara javnom ključu aktivnog Beacon Chain validatora. To bi moglo pojednostaviti dizajn EIP-7002 uklanjanjem potrebe za složenim mehanizmom određivanja cijena u stilu EIP-1559 i, potencijalno, smanjenjem naknade za zahtjev za isplatu budući da spamovanje reda lažnim zahtjevima može biti manji problem.

Međutim, ovo zahtijeva da izvršni sloj može nepouzdano pristupiti informacijama o sloju konsenzusa—kako bi provjerio validator_pubkey u odnosu na registar validatora Beacon Chaina—značajka koja ovisi o implementaciji EIP-4788. To dodaje složenost EIP-7002 i uvodi novu ovisnost između dva EIP-a, što može imati implikacije na buduća poboljšanja dizajna kao što je navedeno u ovom odjeljku obrazloženja EIP-7002 .

Čak i da je EIP-4788 integriran s EIP-7002, i dalje bismo trebali dodatne mehanizme za sprječavanje drugih oblika spama koji uključuju legitimne validatore; primjer je podnošenje više zahtjeva za povlačenje za isti validator u vrlo kratkom razdoblju. To zauzvrat zahtijeva dodavanje (i provedbu) novog pravila poput "možete podnijeti samo jedan zahtjev za povlačenje po validatoru svaka 3-4 mjeseca", što može zahtijevati još više izmjena u ugovoru o zahtjevu za povlačenjem za validator.

Nasuprot tome, trenutni mehanizam za ograničavanje stope je jednostavan za zaključivanje i jamči dovoljnu zaštitu od većine sigurnosnih problema povezanih s povlačenjima na izvršnom sloju. Na primjer, naknada za zahtjev za povlačenje može se automatski podesiti prema gore kako bi se spriječilo žaljenje (pokušaj spriječiti poštene validatore da se povuku) i neželjena pošta i DOS napadi (pokušaj preopteretiti Beacon Chain prisiljavanjem čvorova konsenzusa da troše resurse na filtriranje nevažećih operacija povlačenja).

Zaključak: EIP-7002 i budućnost ulaganja u Ethereum

Delegirani staking dobio je značajne kritike posljednjih mjeseci, ali može se pretpostaviti da će industrija staking-a-usluge ostati tu. Ako je tako, važno je smanjiti rizik za pojedince koji delegiraju udjele - bilo na likvidni staking pool ili institucionalnu uslugu udjela bez skrbništva. EIP-7002 postiže ovaj cilj tako što 0x01 vjerodajnice za povlačenje mogu izaći iz validatora i povući ulog te smanjujući potrebu da stakeri vjeruju u poštenje operatera čvora.

EIP-7002 ima i druge pozitivne učinke prelijevanja. Konkretno, poboljšanje otpornosti i sigurnosti solo staking operacija i distribuiranih validatora—omogućavanjem boljeg oporavka od gubitka validatorskog ključa ili dijeljenja ključeva DVT-a—trebalo bi smanjiti prepreku solo stakingu i smanjiti centralizaciju uloga na Ethereumu.

Kao i obično, završit ću zamolivši vas da razmislite o dijeljenju ovog članka s nekim tko bi ga mogao smatrati informativnim i, što je još važnije, pretplatite se na Ethereum 2077 za dublja istraživanja i razvoj Ethereuma. Također se možete povezati sa mnom na Twitteru kako biste podijelili komentare ili povratne informacije o ovom članku.