EIP-7002: По-добър начин за залагане на Ethereum

Преходът на Ethereum от Proof of Work (Pow) към Proof of Stake (PoS), известен още като The Merge, беше ключов момент в историята на мрежата. Освен че даде на Ethereum така необходимото ребрандиране чрез намаляване на въглеродния му отпечатък, Proof of Stake беше от решаващо значение за ключова дългосрочна цел: намаляване на бариерата пред участие в консенсуса на Ethereum. Сливането замени изчислителните ресурси (мощност за копаене) с финансов капитал като основа на икономическата сигурност на Ethereum – отваряйки възможността за всеки да управлява печелившо и лесно възел за валидиране, като заложи 32 ETH на Beacon Chain.

Въпреки че Proof of Stake донесе ползи, все още има много области за подобрение. Някои от тях включват:

• Намаляване на централизацията на дялове и картелирането на валидатора
• Минимизиране на оперативните разходи за валидаторите и стимулиране на самостоятелно залагане
• Подобряване на икономиката на залагането и потребителското изживяване (UX)
• Подобряване на простотата, сигурността и децентрализацията на делегирани и многостранни операции за залагане

EIP-7002: Задействащи се тегления на ниво изпълнение е ново предложение за подобряване на Ethereum (EIP), което коригира някои от гореспоменатите проблеми. EIP въвежда механизъм за залагащите да теглят валидатори от Beacon Chain, използвайки идентификационни данни за теглене, вместо да разчитат на ключа за подписване на валидатора, за да задействат операции за теглене – ефективно отделяйки ключа за подписване на валидатора от ключа за теглене.

Това „разделяне на притесненията“ между ключовете за подписване на валидатора и ключовете за теглене има критична полза: намаляване на предположенията за доверие при делегирано залагане чрез позволяване на идентификационните данни за теглене да запазят контрола върху заложения ETH. Ще проуча защо тази функция е необходима в хода на тази статия и ще обсъдя други предимства на EIP-7002, особено за соло залагане и DVT (технология за разпределен валидатор) залагане. Статията също така ще разгледа някои потенциални недостатъци на внедряването на EIP-7002 на Ethereum.

Нека се потопим!

Подготовка на сцената: Приказка за ключове, бели ръкавици и скръб(инг)

Ако искате да заложите ETH и да потвърдите Beacon Chain днес, имате две основни опции: соло залагане и делегирано залагане; има и други пътища за залагане на ETH, но тези повече или по-малко тегления са в спектър между гореспоменатите опции. Соло залагането е лесно:

• Депозирайте 32 ETH в договора за депозит Beacon Chain, за да активирате нов валидатор
• Генериране на ключове за изпълнение на задължения на валидатор (проверка на транзакции, удостоверяване на блокове, обобщаване на удостоверения и предлагане на блокове)
• Настройте възел на валидатор и синхронизирайте клиент на слой за изпълнение (EL) и слой на консенсус (CL)
• Поддържайте вашия валидатор онлайн и правилно функциониращ, за да избегнете санкции

Има още стъпки ( често задаваните въпроси за валидатора на Staking Launchpad има страхотен преглед за бъдещи валидатори), но това са приблизително най-важните аспекти на стартирането на валидатор. Важно е, че соло залагането не изисква посредник или контрагент и ви позволява да запазите 100% от наградите, получени от валидиране (удостоверяване на блокове и предлагане на блокове) във веригата Beacon. Но това не е безплатен обяд: вие носите отговорността да управлявате вашия валидатор и ще ви трябва известно ниво на технически опит, за да изпълните самостоятелна операция по залагане.

Ако идеята за управление на валидатор звучи трудно, можете да отидете на делегирания път на залагане. Вие все още носите отговорност за предоставянето на 32 ETH за регистриране на нов валидатор – само че сега делегирате отговорността за управлението на валидатора на трета страна. Операторът на възел за валидиране предоставя това, което някои биха описали като „услуга с бели ръкавици“ и изисква компенсация за тази услуга. Например, може да се наложи да споделите част от наградите на вашия валидатор с оператора на възела като част от първоначалното споразумение.

Частта „бяла ръкавица“ означава, че операторът поема отговорност за поддържане на вашия валидатор работещ и защитен – което означава, че можете да правите неща като стриймване на Netflix в петък вечер (или каквото и да правите в свободното си време), без да се притеснявате за санкции от пропускане на валидаторски задължения или се притеснявате за безопасността на вашите валидаторски ключове.

Все пак има едно предупреждение: делегираното залагане изисква да се доверите на оператора на възела, за да избегнете излагането на вашите 32 ETH на риск чрез извършване на нарушение, което може да бъде намалено (напр. подписване на два конфликтни блока) или директна кражба на вашите средства. Много е да се иска – и определено не за хора с проблеми с доверието – но споразумението работи добре през повечето време, когато операторите на възли са честни.

Но Ethereum не е изграден върху етоса на web2 „довери ми се, брато“, поради което виждате „без доверие“ и „без доверие“ да се появяват често в разговори в крипто-Twitter и Reddit. Делегираното залагане в най-чистата му форма противоречи на този етос, но има заобиколно решение от начина, по който двойките ключове се генерират по време на процеса на активиране на нов валидатор.

Всеки валидатор има два ключа: ключ за теглене и ключ за валидатор. Ключът за теглене е двойка публичен-частен ключ, необходима за частично или пълно изтегляне на баланса на валидатор Beacon Chain в зависимост от това дали искате да „изтеглите“ (изтеглете само награди) или „излезте“ (изтеглете баланса от 32 ETH + награди) . Имайте предвид, че ключът за теглене трябва да бъде актуализиран от идентификационните данни по подразбиране BLS ( 0x00 ) до идентификационни данни 0x01 , които сочат към адрес на Ethereum, за да се даде възможност за частично или пълно изтегляне на баланса на валидатор.

Ключът за теглене се генерира в момента на депозиране чрез интерфейс като Staking Launchpad и се хешира, за да се създаде ID за теглене, който е включен в данните за депозита на валидатора—което предоставя на Beacon Chain информация за това кой е депозирал 32 ETH. Инфографиката по-долу от Protecting Withdrawal Keys от Attestant предоставя чудесен преглед на това как ключът за теглене е интегриран в процеса на искане за депозит на валидатора:

Ключът на валидатора е двойка публично-частни ключове, необходима за изпълнение на задълженията, очаквани от всеки валидатор на Ethereum – основно гласуване за блокове и предлагане на блокове за гласуване от други („гласуване“ и „атестиране“ се използват взаимозаменяемо, но се отнасят до една и съща концепция за проверка на транзакции и потвърждаване на валидността на блокове). Публичният ключ на валидатора служи като негова уникална криптографска идентичност в консенсусния протокол на Ethereum, докато частният ключ се очаква да бъде скрит и използван за подписване на блокови данни (ключовете на валидатора също се описват като ключове за подписване поради тази причина).

Сега, за основната разлика между ключовете за валидиране (подписване) и ключовете за теглене:

Ключът за подписване на валидатор се използва често – помислете на всеки 6,5 минути или за продължителността на слот, по време на който всеки валидатор ще бъде избран да удостовери или предложи блок – и най-добре го съхранявайте в онлайн, лесно за достъп място като горещ портфейл. Ключът за теглене обаче се използва по-рядко и може да се съхранява на сигурно, офлайн място като студен портфейл, докато залагащият не пожелае да изтегли средства от адреса за теглене, свързан с определен валидатор.

Това разграничение е от решаващо значение за намаляване на допусканията за доверие при настройка на делегирано залагане: тъй като ключът за теглене не е необходим за задълженията по валидиране, залагащият може да запази контрола върху заложения ETH, като сподели ключа за валидатор с оператора на възела и задържи ключа за теглене. По този начин измамният оператор не може да избяга със средствата на залагащия, след като изтегли баланса на валидатора без одобрението на залагащия.

Делегираните договорености за залагане, при които залагащият държи ключа за теглене, обикновено се описват като „непопечителски“, за да отразят, че субектът, управляващ валидиращия възел от името на залагащия, в крайна сметка няма контрол върху заложените ETH. Това е в контраст с решенията за попечителско залагане, при които услугата за залагане контролира както ключовете за подписване, така и за теглене; „услуга с бели ръкавици на стероиди“ е добър мисловен модел за попечителско залагане: залагащият просто предоставя 32 ETH за финансиране на валидатора и делегира всичко останало – включително иницииране на заявки за депозит на валидатора и съхраняване на ключове за теглене – на услугата за залагане).

Разделянето на ключовете за подписване на валидатора от ключовете за теглене теоретично решава проблема с доверието в споразуменията за делегирано залагане. На практика връзката между оператора на възел и залагащия в настройка за залагане без попечителство все още има елемент на доверие поради текущия механизъм за изтегляне на валидатор и задействане на пълно или частично изтегляне на баланса на валидатора към адреса за изтегляне.

За да изтеглите валидатор от Beacon Chain, „Съобщение за доброволно излизане“ (VEM), подписано с ключа на валидатора, трябва да бъде изпратено за обработка на консенсусния слой. Веднъж включено в блок (всеки блок може да включва максимум 16 операции със заявка за теглене), съобщението за теглене се добавя към опашката за заявка за теглене — като забавянето на окончателното теглене се влияе от фактори, като y броя тегления на опашката или процент на оттегляне на валидатора.

Наблегнах на изискването за подписване на заявка за доброволно теглене с ключа за подписване на валидатора, за да подчертая проблем със съществуващите решения за залагане „без попечителство“: залагащият трябва да разчита на оператора на възела – който контролира ключа на валидатора, необходим за подписване на VEM – да обработка на заявки за теглене. Това ефективно въвежда отново доверие във връзката между операторите на възли и услугите за залагане; което е по-лошо, това излага участниците на риск да бъдат „опечалени“ от злонамерени оператори на възли.

При скръбна атака целта на нападателя е да причини загуби на другата страна - не непременно да се възползва пряко. За да поставим това в контекст, помислете за сценария, при който Алис делегира на Боб да управлява валидатор от нейно име, но решава да изтегли своите 32 ETH по-късно. Боб може да уважи искането на Алис и да задейства заявка за теглене, като подпише Съобщение за доброволно излизане (VEM)… или да откаже да подпише съобщението за заявка за теглене и да спре операцията за теглене на Алис. Боб няма да има директна полза от отказ на молбата на Алис – всичко, което може да направи, е да държи ETH на Алис като „заложник“, като откаже да помогне на Алис да изтегли своя валидатор.

Добре, това не е 100% точно; Боб може да направи много лоши неща, за да причини на Алис още повече „мъка“:

1. Намалете баланса на валидатора на Alice, като умишлено извършите нарушение, което може да бъде намалено, или наложите наказания. Индивидуалното наказание за неизпълнение на задълженията на валидатора (напр. липсващи атестации) или извършване на нарушение, което може да бъде намалено (напр. подписване на два конфликтни блока в един и същи слот) обикновено е ниско, но се увеличава пропорционално на броя на валидаторите, които извършват подобни нарушения за същия период . Например, липсата на една или две атестации ще намали баланса на валидатора с малка част, но това намаление се увеличава експоненциално, ако възникне изтичане на неактивност — когато множество валидатори са офлайн.

   
   

Съгласно настоящия механизъм, злонамерен Боб може да намали баланса на валидатора на Алис от 32 ETH до 50 процента, като наложи санкции и намаления, докато валидаторът не бъде принудително изтеглен от консенсуса на Beacon Chain (след като ефективният му баланс спадне до 16 ETH). Ако използваме 1 ETH = $2000, скърбящата атака на Боб ще струва на Алис най-малко $32 000 (16 ETH) в нормален случай (без корелирани санкции) и $64 000 (32 ETH) в най-лошия сценарий (т.е. когато целият баланс може да бъдат намалени поради санкции за корелация).

Този, който може да унищожи нещо, контролира нещо. — Пол Атридес (Дюна)

1. Поискайте откуп от Алис в замяна на това да не извършите престъпление, което може да бъде намалено. Това не съвпада точно с предишното определение за скръб, но помислете, че единственият изход на Боб е да изгори ETH, ако Алис реши да играе жестоко. По този начин ситуацията е различна от по-често срещаните видове атаки, при които целта е (винаги) печалба с минимална загуба.

Забележка: Боб (операторът на възела) всъщност може да е честен в този сценарий, но противник може да компрометира ключа на валидатора и да държи ETH на Алис като заложник. Това обяснява „риска от насрещната страна“, който потребителите на платформата залагане като услуга (SaaS) трябва да поемат, и е друга причина соло залагането – с неговия дух „не се доверявай на никого освен на себе си“ – се счита за златен стандарт за залагащите на Ethereum .

Това означава ли, че всяка услуга за залагане без попечителство всъщност не е без попечителство? Не точно. Едно просто заобиколно решение е услугата за залагане да подпише предварително съобщение със заявка за доброволно теглене – за предпочитане след като валидаторът е активиран във веригата Beacon Chain – което залагащият може да изпрати независимо до консенсусен възел на Ethereum, когато пожелае да изтегли.

Чрез предварително подписване на заявки за доброволно теглене за стейкер, споразумението между стейкер и оператор на възел се връща към първоначалния статус без попечителство. Предварително подписаните съобщения за искане за теглене обаче не са устойчиви поради много причини:

Проблеми с предварително подписани заявки за теглене за залагане без попечителство

Сложност

Работните потоци за предварително подписани заявки за теглене изискват повече комуникация между оператор на услуга за залагане и делегиращия залог: трябва да подадете заявка за съобщение със заявка за теглене и да изчакате услугата за залагане да изпрати подписаните заявки за теглене. Съществува и проблем със сигурността при използване и обмен на предварително подписани заявки за теглене:

• Услугата за залагане трябва да вземе допълнителни предпазни мерки - като криптиране на съобщението за заявка за теглене и споделянето му по защитен (извън веригата) комуникационен канал - за да предотврати попадането на съобщенията за заявка за теглене в неподходящи ръце.
• Залагащият трябва да вземе допълнителни предпазни мерки, за да съхранява съобщението за заявка за теглене на сигурно място, тъй като загубата на съобщението за заявка за теглене е еквивалентна на потенциална загуба на способността за самостоятелно изтегляне на баланса на валидатора.

Освен това, предварително подписаните заявки за теглене в момента са валидни за два форка на Ethereum или ~12 месеца – ако очаквате форкове да се случват приблизително на всеки шест месеца. Това означава, че залагащият трябва да подаде отново заявка за заявка за доброволно теглене до оператора на услугата за залагане няколко пъти в рамките на една календарна година. Това обаче вече няма да е така, когато се внедри EIP-7044 и подписаните заявки за изтегляне на валидатора станат валидни за неопределено време.

EIP-7044 коригира проблема с изтичащите съобщения за изход, но въвежда нов набор от проблеми - особено за големи пулове за залагане. За предистория, настоящият подход в децентрализираните пулове за залагане е да се изисква от операторите на възли за валидиране да подават предварително подписани заявки за теглене, преди да бъдат финансирани от пула. Тук подписаните заявки за теглене осигуряват криптоикономическа сигурност, тъй като намаляват властта, която (ненадежден) оператор има над средствата на валидатора; пулът за залагане може да задейства заявката за теглене на несътрудничащ оператор на възел на валидатор чрез подаване на предварително подписаната заявка за теглене във веригата.

Но операторът на валидиращ възел няма да се чувства комфортно, ако предварително подписаните заявки за теглене се съхраняват на произволен сървър поради риска някой случайно/умишлено да задейства фалшиви заявки за теглене, като се добере до подписаното съобщение за изход. В най-лошия сценарий принудителните излизания вероятно ще доведат до загуба за оператор на възел на валидатор (напр. ако сте взели заем срещу бъдещи награди на Beacon Chain). Това означава, че пуловете за залагане трябва да вземат дори повече предпазни мерки и да съхраняват сигурно съобщенията за заявки за теглене, особено в свят след EIP 7044, където подписаните заявки за теглене имат безкрайни дати на валидност.

Потенциално решение е да се шифроват подписани заявки за теглене със споделен публичен ключ, генериран чрез протокол DKG (генериране на разпределен ключ) , и да се изисква кворум от споделени ключове за възстановяване на частния ключ, преди заявката за теглене да може да бъде декриптирана. Това намалява предположението за доверие, което идва с една страна, съхраняваща заявки за теглене, при условие че никой не контролира достатъчно споделени ключове, за да декриптира едностранно предварително подписаните заявки за теглене без информация от други участници. Но възниква проблемен случай, ако един или повече споделени частни ключове са изгубени, изгубени или откраднати - което прави трудно или напълно невъзможно дешифрирането на подписаната заявка за теглене, ако се наложи задействане на теглене от валидатор.

Съответствие с нормативната уредба

Услугите за залагане получиха много контрол от азбучна супа от регулатори, най-вече от SEC (Комисията по ценни книжа и борси), водена от обществения враг №1 на крипто: Гари Генслер. Например, Kraken затвори своята операция по попечителско залагане като услуга по-рано тази година и плати 30 милиона долара глоби за „предлагане на нерегистрирани ценни книжа чрез своята платформа за крипто залагане“.

На теория е малко вероятно услугата за залагане без попечителство да попадне в полезрението на SEC поради непопечителския характер на нейното споразумение със собственика на залога:

1. Депозитът от 32 ETH (или кратни на 32 ETH) за активиране на валидатор идва от адрес за теглене, контролиран от залагащия – и протоколът идентифицира адреса за теглене като собственик на депозита от 32 ETH. Това означава, че услугата за залагане без попечителство не може да изтегли баланса на валидатора и да „смеси парите на клиентите със своите собствени“, както Kraken беше обвинен, че прави от SEC.

В борса като Kraken балансът в портфейла на потребителя е „виртуален“, тъй като всички клиентски средства се съхраняват в един или повече портфейли, контролирани от борсата. Така че, ако заложите 32 ETH чрез услуга за попечителско залагане, управлявана от борса, това, което наистина имате, е IOU от борсата, обещаваща да върнете 32 ETH (плюс процент от наградите на валидатора), когато пожелаете да изтеглите.

1. Залагащите могат независимо да теглят средства чрез изпращане на предварително подписани изходи, без да рискуват фалшива услуга за залагане да попречи на тегленията. За разлика от това, попечителска услуга за залагане – особено борса като Kraken – има контрол върху активите на залагащия и може да блокира тегления по произволни причини.

Тези два факта премахват необходимостта от „защита на инвеститорите“; Не съм експерт по политиката, така че извинете за грешките в този ред на разсъждения. Но все пак може да има малка бръчка или две, ако днес управлявате институционална услуга за залагане без попечителство:

• За краткия (или вероятно дълъг) период между активирането на валидатор и изпращането на предварително подписано доброволно излизане до залагащия, услугата за залагане контролира 32 ETH, което я прави „попечителска“ в очите на регулатора. Допълнително усложняване на проблема са кратките дати на изтичане на предварително подписаните изходи (преди EIP 7044): между времето, когато ново съобщение за изход е подписано и изпратено до залагащия, операторът на възел на валидатора има известен контрол върху заложените ETH.
• Докато редовните съобщения за изход се излъчват по веригата и могат да бъдат публично проверени, предварително подписано изход трябва да бъде криптирано и споделено извън веригата частно между оператора на възела и залагащия. Това прави по-трудно за трета страна като регулатор да провери дали услугата за залагане наистина е подписала намерение за напускане като част от първоначалното споразумение за депозит на валидатора - или ако обменът се е повторил, след като първоначалното съобщение за изход е изтекло (т.е. -EIP 7004).

В обобщение: предварително подписаните изходи облекчават някои проблеми с делегираното залагане, но не са достатъчни, за да направят залагането на Ethereum надеждно, сигурно и децентрализирано. За да върнем „без попечителство“ обратно в залагане без попечителство, имаме нужда от по-добро решение – което сега имаме благодарение на EIP-7002. Следващите раздели ще покрият подробно EIP-7002 и ще засегнат различните предимства на EIP, както и потенциалните проблеми, свързани с прилагането му.

Общ преглед на EIP-7002: Тегления, задействани от изпълнителния слой

EIP-7002 поправя проблема принципал-агент при делегирано залагане – където залагащите трябва да се доверят на операторите на възел на валидатор за предварително подписване на заявки за теглене или да уважават бъдещи заявки за теглене – чрез въвеждане на нова операция за доброволно теглене, която може да бъде задействана с идентификационни данни за теглене на валидатор. Това дава възможност на залагащите да теглят заложен ETH, без да разчитат на субекта, който държи ключа за подписване на валидатора (т.е. услугата за залагане в делегирана настройка за залагане), за да обработва тегления.

Ключовата характеристика на EIP-7002 е въвеждането на договор за заявка за теглене на валидатор, който поддържа опашка от заявки за теглене на валидатор, произхождащи от слоя за изпълнение. На интервали определен брой заявки за теглене се премахват от опашката и се добавят към заявката за изпълнение на блок Beacon Chain. Това позволява заявките за теглене от изпълнителния слой да бъдат „инжектирани“ в консенсусния слой и обработени като част от операциите на Beacon Chain — подобно на начина, по който депозитите, произхождащи от договора за депозит, се предават от изпълнителния слой към консенсусния слой за обработка.

Заявките за теглене са редовни транзакции на Ethereum с адреса на договора за валидатор като цел и показват намерение за изтегляне на валидатор (идентифициран от неговия публичен ключ). Съобщение за изтегляне на валидатор е валидно, ако (a) е подписано от адреса на Ethereum, посочен в идентификационните данни за изтегляне на слоя за изпълнение ( 0x01 ) на валидатора (b) валидаторът, който ще бъде изтеглен, е активен във веригата Beacon. Тези проверки се изпълняват от консенсусния слой, след като заявката за теглене стигне до Beacon Chain; договорът за заявка за теглене на валидатора потвърждава само дали транзакция със заявка за теглене плаща достатъчно гориво в момента, в който договорът за заявка за теглене е извикан от залагащ.

Всички заявки за теглене на ниво изпълнение се обработват по същия начин като обикновена операция за заявка за доброволно теглене, задействана от консенсусния слой, което запазва инвариантите около максималните допустими заявки за теглене от активните тегления на валидатора. Вграденият в протокола механизъм на EIP-7002 за прехвърляне на заявки за теглене между слоеве за изпълнение и консенсус също премахва необходимостта от връзки към консенсусен възел за задействане на заявки за теглене (което се изисква за теглене на валидатори с предварително подписани заявки за теглене). Валидаторите вече могат да бъдат финансирани и изтеглени от един и същ адрес на изпълнителния слой, което обяснява наименуването на EIP като „Изтегляне, задействано от изпълнителен слой“.

След като видяхме как EIP-7002 работи на високо ниво, сега можем да се задълбочим в по-фините детайли на EIP. Следващият раздел ще покрие текущата спецификация на EIP-7002 и ще обсъди ключови аспекти на механизма за заявка за изтегляне на валидатора. Ако предпочитате да пропуснете техническата дискусия и да проучите предимствата на внедряването на EIP-7002, можете да преминете към следващия раздел, който подчертава някои от подобренията в потребителското изживяване (UX), които EIP-7002 позволява.

Операции по искане за теглене на Валидатор

Съгласно EIP-7002 заявка за изтегляне на валидатор (дефинирана в псевдокод като add_withdrawal_request() ) е CALL към адреса на договора за заявка за изтегляне на валидатор. Полето за транзакция за повиквания към договора за заявка за теглене на валидатора има две стойности:

• source_address : 20-байтова стойност, представляваща адреса за теглене, който е инициирал транзакцията
• validator_pubkey : 48-байтова стойност, представляваща публичния ключ на валидатора, от който трябва да излезете

След като залагащ извика договора за заявка за теглене с validator_pubkey като вход, договорът за заявка за теглене на валидатора изпълнява следните операции (по-късно ще прегледам ключовите части на тази операция):

• Потвърждава, че транзакцията плаща достатъчно газ, за да покрие EXIT_FEE
• Увеличава брояча за излизане ( EXIT_COUNT ) с единица за текущия блок
• Вмъква съобщението за изход в опашката
• Увеличава излишните тегления за текущия блок ( EXCESS_EXITS ) с едно
• Възстановява сумата на обаждащия се – ако е надплатил за бензин – чрез препращане на стипендия от 2300 бензин ( EXCESS_RETURN_GAS_STIPEND )

Важна подробност: договорът за заявка за теглене на валидатора не проверява дали source_address е валиден адрес за теглене за валидатора, идентифициран от validator_pubkey , нито проверява дали validator_pubkey . Това разкрива фин проблем със сигурността, който може да възникне, ако нападател запълни опашката със съобщения, които са обречени на провал; това е предимно скръбна атака с цел предотвратяване на обработката на законни заявки за теглене. EIP-7002 адресира този проблем, като начислява динамично коригираща се такса върху транзакции със заявка за теглене (механизмът за такса за теглене се обсъжда по-късно).

Максимални и целеви тегления на блок

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK е броят заявки за теглене на ниво изпълнение, които могат да бъдат включени в блок Beacon Chain. Понастоящем тази стойност е зададена на 16, за да отразява подобни операции във веригата Beacon Chain, като например VoluntaryExit (операции за изход, задействани директно от консенсусния слой с ключ за валидиране на залагащия).

Спецификацията също така отбелязва, че настройката на MAX_WITHDRAWAL_REQUESTS_PER_BLOCK на 16 ограничава размера на полезните натоварвания за изпълнение - и като разширение, размера на блоковете Beacon Chain - и намалява режийните разходи за обработка на изходни операции на консенсусния слой. Това е полезно, тъй като можем да очакваме някои залагащи да продължат да излизат от валидаторите, използвайки текущия механизъм за задействане на излизания от консенсусния слой (т.е. чрез предварително подписани излизания или съобщения за доброволно излизане в реално време).

TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK

EIP-7002 теоретично позволява до 16 изходни операции на ниво изпълнение да бъдат включени в блок, но цели по-консервативна оценка от два изхода на блок. Съгласно спецификацията , TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK е зададен на 2, за да ограничи скоростта на оттегляне на валидаторите и да запази инварианта на максималните допустими тегления за епоха, дефинирани от функцията get_validator_churn_limit() на Beacon Chain – дори в ситуации, в които е заложен целият ETH в обращение.

Опашка от заявки за теглене на Валидатор

WITHDRAWAL_REQUEST_COUNT

WITHDRAWAL_REQUEST_COUNT е броят заявки за теглене, включени в текущия блок. След всяко успешно извикване на договора за заявка за теглене на валидатора, стойността на променливата WITHDRAWAL_REQUEST_COUNT , съхранена в хранилището на договора на валидатора, се увеличава с единица (дефинирана в псевдокод като increment_count() ).

Във всеки момент стойността на WITHDRAWAL_REQUEST_COUNT ще бъде между TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK (2) и MAX_WITHDRAWAL_REQUESTS_PER_BLOCK (16) в зависимост от това колко операции на заявка за теглене са добавени към полезния товар за изпълнение на блока. WITHDRAWAL_REQUEST_COUNT също е вход към функцията, която изчислява сумата, която трябва да бъде платена чрез нова операция по заявка за теглене ( MIN_WITHDRAWAL_REQUEST_FEE ).

ИЗВЪРШЕНИ ЗАЯВКИ ЗА ТЕГЛЕНЕ

EXCESS_WITHDRAWAL_REQUESTS е разликата между MAX_WITHDRAWAL_REQUESTS_PER_BLOCK и TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK – броят заявки за теглене, останали неизползвани от текущия блок. Както споменахме, всеки блок може да включва максимум 16 заявки за теглене, но е насочен към две заявки за теглене в нормални ситуации, така че EXCESS_WITHDRAWAL_REQUESTS е еквивалентен на „разликата между колко заявки за теглене теоретично може да поеме един блок и колко заявки за теглене действително използва“.

Излишният брояч на договора за заявка за теглене се актуализира въз основа на използването на последния блок и е един фактор (наред с други), който определя таксата, платена от транзакция, която извиква договора за заявка за теглене на валидатора. Това гарантира, че таксите за теглене се определят според текущото използване, което е подобно на EIP-1559, като изчисляването на base_fee за нов блок се изчислява въз основа на разликата между целевия лимит на газ и газа, използван от предишния блок.

WITHDRAWAL_REQUEST_QUEUE

WITHDRAWAL_REQUEST_QUEUE е списък на всички чакащи заявки за теглене (подредени по ред на пристигане), които в момента се съхраняват в WITHDRAWAL_REQUEST_QUEUE_STORAGE_SLOT на договора за валидиране (като WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT и WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT ). Броят на заявките за теглене в опашката може да бъде неограничен, но променливата скорост MAX_WITHDRAWAL_REQUESTS_PER_BLOCK ограничава колко чакащи заявки за теглене могат да бъдат извадени от опашката във всеки блок.

Опашката от заявки за теглене поддържа индекс „глава“ и „опашка“ – и двата просто се отнасят до набора от заявки близо до началото и края на опашката – който се актуализира след всеки блок, за да отчете обработката на една или заявки за теглене. Това е опашка „първи влязъл, първи излязъл“ (FIFO), така че заявките се изпълняват в зависимост от това кога са добавени към опашката – което има последици за сигурността, особено по отношение на скръбта на честните валидатори.

Такси за договор за оттегляне на Валидатор

MIN_WITHDRAWAL_REQUEST_FEE е сумата, която валидаторът трябва да плати в бензин, който адресът извиква договора за заявка за теглене на валидатора за теглене. Преди да вмъкне заявка за теглене в опашката, договорът за заявка за теглене на валидатора проверява дали таксата за газ, свързана с транзакцията, е равна или надвишава текущата стойност от MIN_WITHDRAWAL_REQUEST_FEE - ако транзакцията има остатъчен газ след успешно изпълнение, адресът за изпращане се кредитира с точно 2300 газ.

Съгласно спецификацията, този дизайн следва вече отхвърлената функция в Solidity, където извикването на функцията fallback() в договор за местоназначение или изпращането на ETH чрез transfer() или send() препраща стипендия от 2300 газ към получателя. Промените в разходите за газ (започвайки с разклонението Берлин/Истанбул) намалиха полезността на тази функция (прочетете Спрете да използвате трансфера на Solidity() Сега за малко контекст), но първоначалната идея за проста система за отчитане на газ все още е полезна. В контекста на EIP-7002, изпращането на фиксирано възстановяване от 2300 газ опростява механизма за такса за договора за заявка за изтегляне на валидатор.

Алтернативата е да се създаде специален механизъм, който позволява на договора за заявка за теглене да върне максималното количество газ, останало от транзакция. Това би имало смисъл, особено в случаите, когато адресът за теглене е EOA - интелигентните договори могат да изчислят точни стойности за MIN_WITHDRAWAL_REQUEST_FEE чрез проверка на състоянието на договора, но EOA вероятно ще изпращат повече газ за всяко повикване към договора за заявка за теглене. Този маршрут добавя повече сложност към дизайна на EIP-7002 в сравнение с използването на просто CALL за препращане на фиксирано количество газ като възстановяване; въпреки че авторите на EIP-7002 предполагат, че тази функция може да бъде включена в окончателната спецификация в зависимост от обратната връзка от заинтересованите страни.

Изчисляването на MIN_WITHDRAWAL_REQUEST_FEE е мястото, където нещата стават интересни. Таксата за заявка за теглене е динамична и проектирана да отговаря на условията на мрежата, подобно на основната такса, въведена от EIP-1559, и е функция на три променливи:

• Минимална (базова) такса за теглене: MIN_WITHDRAWAL_REQUEST_FEE
• Брой излишни тегления при текущия блок: EXCESS_WITHDRAWAL_REQUESTS
• Формулата за актуализиране на таксата за теглене: WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION

Подобно на base_fee на EIP-1559, изходната такса на договора за теглене на валидатора е механизъм за ограничаване на скоростта: в средния случай (две заявки на блок), всеки, който се обажда на договора за заявка за теглене на валидатора, може да очаква да плати минималната такса за теглене, но цената на операцията по теглене прогресивно увеличава повече заявки за теглене, включени в блок. Това може да бъде изведено от официалната спецификация на EIP-7002 за актуализиране на таксата за заявка за теглене : withdrawal_request_fee = MIN_WITHDRAWAL_REQUEST_FEE * e**(excess_withdrawal_requests / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) .

Обяснение на механизма за такса за искане за теглене от спецификацията:

„Поведението блок по блок е приблизително следното: Ако блок N обработва X заявки за теглене, тогава в края на блок N excess_withdrawal_requests се увеличава с X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK и така таксата за_заявка за изтегляне в блок N + 1 се увеличава с фактор e**((X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK) / (WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) , следователно има подобен ефект на съществуващия EIP-1559, но е по-„стабилен“ в смисъл, че отговаря по един и същ начин на същите общи заявки за теглене, независимо от това как са разпределени във времето. .”

Чрез постепенно увеличаване на таксата за заявка за теглене в съответствие с използването на договора за заявка за теглене на валидатор, EIP-7002 намалява риска от нападател, който умишлено запълва опашката за заявка за теглене, за да попречи на други валидатори да теглят. Съобщенията за изземване в опашката за заявки за теглене се изваждат от опашката и са в стил „първи влязъл, първи излязъл“ (FiFo), за разлика от, да речем, „последен влязъл – първи излязъл“ (LiFo) или поръчка с най-високо платена транзакция. Въпреки че можем да приемем, че цените на газта ще предотвратят ненужни извиквания към договора за заявка за теглене, злонамерен нападател може да е готов да плати повече газ, за да „напълни“ опашката със заявки за теглене и да избута заявката за теглене на друг валидатор до края на опашката.

Проблемът допълнително се усложнява от централизацията на блоковото изграждане в Ethereum след сливането. Ако атакуващият е интегриран с един или повече доминиращи създатели (за контекст: 80-90% от блоковете до момента в Ethereum са произведени от 4-5 създатели ) и е готов да плати за включване на най-високия блок, те може ефективно да управлява заявки за теглене от един или повече играчи и да предотвратява навременни тегления на валидатори от Beacon Chain.

И защо някой би преживял целия този стрес? Възможна мотивация може да бъде, че нападателят иска да наскърби играчите, които искат да изтеглят валидатори, използвайки идентификационни данни за теглене. За да използвате предишния оператор на Боб (зловреден) възел и Алис, залагащ: Алис може бързо да изтегли своя валидатор, за да спре скърбящата атака на Боб, като извика договора за заявка за изтегляне на валидатора с идентификационните данни за теглене – но Боб все още може да даде повече, за да изтече информацията на Алис баланс на валидатора чрез спам на договора за заявка за теглене на валидатора и забавяне на заявката за теглене на Алис.

Блокова структура и валидност

EIP-7002 леко променя структурата и валидирането на Beacon блоковете, като изисква заявките за теглене да се поставят в действителното тяло на блока (и полезния товар за изпълнение в консенсусния слой). Заявките трябва да бъдат вградени в полезния товар за изпълнение, така че когато консенсусният слой е непостижим, консенсусният слой все още има необходимите данни за пълното изпълнение на консенсусната част от функцията за преход на състоянието.

EIP-7002 също добавя нови условия за валидност за блокове. Първо, списъкът със заявки за теглене ( withdrawal_requests_list ) не може да надвишава MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . Второ, списъкът със заявки за теглене трябва да съответства на броя заявки за теглене, изключени от опашката WITHDRAWAL_REQUEST_QUEUE , когато такива заявки са подредени в реда „първи влязъл, първи излязъл“ (FiFO).

EIP-7002 има функция ( expected_exit ) за потвърждение, че даден блок не включва повече заявки за теглене от резултата от изчисляването на NUM_WITHDRAWAL_REQUESTS_IN_QUEUE - MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . Също така консенсусен възел, изпълняващ повторно блока, ще изчисли независимо кодирането на заявките за теглене чрез повторение на request_type и request_data в сравнение с ангажимента на хеша на списъка със заявки за теглене.

Защо EIP-7002? Случаят за задействащи тегления на ниво изпълнение

Намалени допускания за доверие при делегирано залагане

Във въведението отбелязах как разчитането на ключа за подписване на валидатора за иницииране на излизания от валидатора доведе до проблема с доверието; Не включих определение за доверие, но това определение от статията на Виталик за моделите на доверие го обобщава добре: „Доверието е всяко предположение(я), което правите относно поведението на други хора“. Като се регистрира за услуга за залагане, знаейки, че злонамерен оператор на възел може да замрази тегления, залагащият по същество се доверява на оператора на възел да действа вярно.

EIP-7002 не премахва напълно елемента на доверие в делегираното залагане – все пак трябва да се доверите на оператор на възел, че няма да изпълни скърбяща атака – но позволяването на залагащите да се оттеглят с идентификационни данни за теглене намалява тежестта на доверието до известна степен. Например, потребителят не трябва да „има вяра“, че оператор на възел ще подпише съобщение за доброволен изход, след като го поиска.

Тънък момент относно „недоверието“ е, че не става въпрос непременно за избягване на необходимостта от доверие, а за липса на нужда от доверие, защото (а) има силни стимули за всички страни да действат честно (б) честните страни имат известно количество защита от действията на нечестни страни. Възможността да се изтегли валидатор с идентификационни данни за изтегляне е пример за последното: Боб може да се опита да наскърби Алис, но сега Алис има агенцията да изтегли своя валидатор, надяваме се, преди Боб да причини повече щети.

По-добро управление на риска за пулове за залагане

Понастоящем пуловете за залагане нямат начин да принудят оператора на валидиращ възел да се оттегли – което поставя участниците в пула в неудобната позиция да се доверят на операторите на възел да действат честно. Някои децентрализирани пулове за залагане изискват операторите на възли да осигурят облигация, но като се има предвид възможността злонамерен оператор да бъде намален до 0 ETH, сигурността от облигация може да е недостатъчна в очите на залагащия, който не е склонен към риск.

С EIP-7002 на място, пуловете за залагане могат значително да намалят допусканията за доверие чрез допълване на сигурността от заплахата от намаляване на обезпечението на оператор на възел с процедури за принудително оттегляне на неправилно работещ оператор чрез изтегляне на изпълнителен слой. Възможността за идентификационни данни за теглене, сочещи към адрес на интелигентен договор (вместо EOA) също отваря нови дизайни за реагиране при инциденти за пулове за залагане – например интелигентен договор може автоматично да подаде заявка за теглене, ако оператор понесе по-високи от средните санкции в рамките на времеви прозорец. Това обаче изисква да се доверите на оракул за проследяване на ефективността на валидатора и на поддържаща мрежа за задействане на интелигентния договор.

Другата хипотетична полза за пул за залагане от внедряването на EIP-7002 е премахването на необходимостта да се изискват и съхраняват предварително подписани съобщения за теглене, което идва с рискове, както обясних по-рано (напр. неоторизиран достъп до съобщения за теглене може да доведе до неочакван валидатор тегления). Това също допринася за целта за проектиране на безнадеждни пулове за залагане: за разлика от разчитането на предварително подписани заявки за теглене, съхранявани от няколко (доверени) лица, интелигентен договор, определен като адрес за теглене, може да бъде контролиран от управлението, позволявайки на общността да решава да оттегли оператор на възел публично и прозрачно.

По-добро управление на риска за настройки на ДВТ

Технологията за разпределен валидатор (DVT) се счита за критична част от инфраструктурата за залагане на Ethereum по много причини:

• DVT намалява бариерите пред соло залагането: Множество соло залагащи могат да обединяват средства заедно, за да активират съвместно валидатор, без да се налага да се доверяват на всяка друга страна. Схемите за многостранно изчисление (MPC) могат да толерират до ⅓ дефектни възли – така че ако хипотетичен разпределен валидатор изисква 3 от 5 споделяния на ключове, за да реконструира ключа за подписване на валидатора, подписването може да се случи, ако два DVT възела са офлайн.
• DVT подобрява толерантността към грешки и устойчивостта за институционални/самостоятелни настройки на залагане: Както бе споменато по-горе, подписващият ключ на валидатора може да бъде разделен на различни споделени ключове и реконструиран само когато се изискват подписващи блокови данни. Това намалява риска хакер да компрометира ключа за подписване на валидатора или играч да загуби достъп до средства, тъй като устройството, съхраняващо ключа за подписване, е претърпяло повреда.

Въпреки това, настройките на DVT все още носят известен риск за залагащите поради начина, по който тегленията и излизанията работят в момента във веригата Beacon. Ако някои DVT възли погрешно споделят ключове или отказват да участват в схемата за прагово подписване, излизането от валидатор става невъзможно - особено когато:

• Споделяните ключове за всеки участник в настройката на DVT се генерират по време на активиране на валидатор и не могат да бъдат „опреснявани“ след първоначалната церемония на DKG (имайте предвид, че „участник“ може просто да бъде друг EOA, притежаван от същия залагащ); някои DVT протоколи позволяват генерирането на нови споделени ключове, въпреки че това може да изисква останалите споделени ключове да отговарят на кворума от подписи, необходими за редовно подписване.
• Прагът на кворума — броят споделяния на ключове, необходими за съвместно генериране на валиден подпис за разпределения валидатор — не може да бъде променен, след като (разпределеният) валидатор е активен.

Без EIP-7002 да предоставя опция за изтегляне на валидатор с помощта на ключа за изтегляне, ползата от стартирането на настройка на DVT - независимо или съвместно с други валидатори - би била значително намалена (напр. балансът на валидатор може да бъде заключен завинаги). EIP-7002 предоставя резервна опция за безопасност за разпределени валидатори: ако възстановяването на ключа за подписване е невъзможно, валидаторът може да бъде изтеглен от веригата Beacon чрез подаване на заявка за теглене, подписана с ключа за изтегляне, реконструиран от споделени ключове.

По-добро спазване на регулаторните изисквания: Поставяне на „без лишаване от свобода“ в залагане без лишаване от свобода

Малко вероятно е авторите на EIP-7002 изрично да имат за цел да улеснят управлението на регулирана институционална компания за залагане като услуга. Въпреки това EIP помага при проблема с убеждаването на регулаторите, че дадена институция не попечителства върху заложен ETH. Операторът на залагане в този сценарий може просто да представи хеш на депозитната транзакция, подписана от ключа за теглене на залагащия – който вече може да подписва и изпраща доброволни изходи – като доказателство, че средствата, депозирани във валидатор, никога не са в негово попечителство в нито един момент.

Подчертах „по всяко време“, тъй като преди EIP 7044 операторът на възел временно поема контрола върху баланса на валидатора след изтичане на предварително подписания изход. И дори с вечно валидните подписани изходи на EIP-7044, операторите на възли все още имат попечителство върху 32 ETH, депозирани за валидатор за краткия период между активирането на валидатора и получаването от залагащия на подписано съобщение за изход от оператора на услугата за залагане. EIP-7002 премахва тези неудобни области и гарантира, че залагащите имат (доказуемо) попечителство върху средствата през целия жизнен цикъл на валидатора – от влизане във веригата Beacon за теглене и изпращане на средства до адреса за теглене на залагащия.

По-добро потребителско изживяване (UX) за всички

Един добър ментален модел за EIP-7002 е да се мисли за него като за „ абстракция на сметка за инфраструктура за залагане“. За контекст ключът за валидиране (или ключът за подписване) винаги е EOA и идва със същия набор от ограничения относно безопасността и използването на частния ключ, който засяга обикновените EOA на Ethereum днес:

• Ключовете за валидиране (подписване) са изложени на по-висок риск от компрометиране. За разлика от ключовете за теглене, съхранявани в студено (офлайн) хранилище, ключовете за валидиране се съхраняват в горещи портфейли, свързани с интернет, което ги прави податливи на фишинг атаки. Ако ключът за подписване на валидатор е компрометиран, залагащите и делегираните доставчици на залагания са податливи на векторите на печал, описани във въведението, без никакъв резервен план—отвъд „изчакайте, докато балансът спадне до 16 ETH и валидаторът бъде принудително изтеглен от протокола“.
• Ключовете на валидатора имат ограничени възможности за схеми за възстановяване (загуба веднъж = загуба завинаги). Разделянето на ключ за валидиране на множество споделени ключове чрез технология за разпределен валидатор (DVT) може да смекчи този риск, но изпълнението на настройка за залагане на соло DVT не е тривиално; освен това, както обясних по-рано, DVT не е сребърен куршум, тъй като споделените ключове могат да бъдат загубени и да усложнят опресняването на споделени ключове.
• Ключовете за валидиране не могат да поддържат по-гъвкави дизайни на залагане. Различните услуги за залагане са развили автоматизирани/гъвкави работни потоци за финансиране на валидатори поради предимството на насочването на идентификационни данни за теглене към интелигентни договори. Оттеглянето на валидатор обаче е ръчен процес, който изисква подписване на съобщение за заявка за доброволно теглене - процесът може да бъде автоматизиран чрез интелигентен договор, който съхранява заявки за теглене преди signex, но това идва с определени допускания за доверие и съображения за сигурност, обяснени по-рано.

Можем да разрешим повечето — или поне някои — от тези проблеми, след като ключовете за теглене могат да излизат от валидаторите. За да работи това, залагащият (или групата за залагане) ще трябва да извърши еднократна промяна от идентификационни данни за теглене 0x0 на идентификационни данни за теглене 0x01 – докато идентификационните данни 0x0 са BLS (EOA) ключ по подразбиране, идентификационните данни 0x01 могат да сочат към всеки Ethereum адрес, включително интелигентни договори и EOA. Задаването на интелигентен договор като адрес за теглене за валидатор е чудесно за подобряване на потребителското изживяване (UX) при залагане:

1. Ключовете за теглене могат да имат гъвкави механизми за възстановяване, като социално възстановяване. Залагащият ще има един или повече „настойници“, които могат да упълномощят нов ключ за контролиране на интелигентния договор на заявката за теглене, ако оригиналният ключ бъде откраднат или изгубен – настойниците могат да бъдат приятели, роднини, колеги залагащи или специализирана услуга на трета страна. Гъвкавостта на механизмите за възстановяване може да бъде особено полезна за соло залагащите; можете да имате превключвател , който активира EL изход и изпраща средства до определен адрес, ако вашият валидатор спре да удостоверява за предварително определен период (напр. защото сте „преминали към Great Beyond“).

2. Могат да се появят гъвкави дизайни на залагане. Например, склонен към риск залагащ може да предпочете договор за теглене с множество подписи 2-от-2 – като залагащият и операторът на възел притежават един от двата ключа, необходими за одобряване на заявки за теглене – вместо да съхраняват целия ключ за теглене. Той все още не е попечителски (оператор на възел не може да излезе от валидатора без одобрение), въпреки че изисква доверие на оператора на възел да не блокира изхода на валидатора, като откаже да подпише транзакции с искане за теглене, предложени от залагащия.

За пуловете за залагане, гъвкавостта в дизайна на залагане може да означава прилагане на договори за теглене с произволна логика за актуализиране или прехвърляне на собственост върху валидатори. При липсата на EIP-7002, единственият реален начин, по който пулът за залагане може да управлява собствеността върху валидаторите, е да премества предварително подписани заявки за теглене, което е свързано с различни рискове и крайни случаи.

3. Тегленията чрез Валидатор могат безопасно да се автоматизират. За разлика от съхраняването на предварително подписани заявки за теглене в интелигентен договор, договорите за заявки за теглене могат да имат сложни правила, управляващи заявките за теглене на валидатора; идеята за „луда наука“ е „пул за залагане, базиран на времето“, където операторите на възли се сменят без доверие. Или помислете дали голям пул за залагане като Lido иска да се децентрализира: управлението може да избере да оттегли някои валидатори, контролирани от оператор на голям възел, и да преразпредели средства към по-малки оператори (или соло стейкъри), за да намали точките на задушаване от оператор на възел, контролиращ значителен брой валидатори.

Това са само някои от ранните възможности, които EIP-7002 позволява, но съм много сигурен, че ще се появят още приложения – точно както продължават да се появяват нови функции и случаи на употреба за интелигентни портфейли в Ethereum. Ако четете това и имате по-конкретни идеи за прилагане на EIP-7002 към проекти за залагане, не се колебайте да се включите в коментарите!

Има ли недостатъци при прилагането на EIP-7002?

Потенциални счупващи промени в съществуващите проекти за залагане

В проекта на EIP авторите на EIP-7002 признават потенциални опасения относно разрешаването на идентификационните данни за теглене, за да задействат тегления от валидатора, но продължават да казват, „не знаем за никакви проекти за залагане, които разчитат на тази функция [т.е. невъзможност за теглене с пълномощия за теглене]“. Това изглежда разумно – дори аз имах известни затруднения да разсъждавам относно всяко делегирано споразумение за залагане, което би изисквало тази функция. Но това, че не изглежда очевидно, не означава, че го няма.

„Слушайте тези тихи, натрапчиви съмнения. Ако не знаете, не знаете какво не знаете, не знаете колко много не знаете и не знаете колко трябва да знаете.” — Елиезер Юдковски

За да осигуря някакъв контекст, ще включа екранни снимки на разговор около ранно предложение за прилагане на изходи, одобрени с идентификационни данни за теглене, чрез генерализирана шина за съобщения (GMB) . GMB е интелигентен договор на системно ниво, чиито събития се четат и обработват от клиенти, подобно на текущия договор за депозит, и е в състояние да предава съобщения от слоя за изпълнение до слоя за консенсус. Докато авторът(ите) намекнаха за по-общи типове съобщения EL-към-CL, основният предложен случай на използване на шината за съобщения EL-към-CL беше предоставянето на начин за задействане на изходи от изпълнителния слой чрез идентификационни данни за изтегляне 0x01.

От този обмен вече имаме пример за връзка оператор на залагащ възел, изградена на предположението, че залагащият не може да излезе и да изтегли валидатор, използвайки ключа за изтегляне. Друг пример за потенциален краен случай на внедряване на EIP-7002 идва от разговор относно плановете за децентрализация на Lido в Lido Community Staking Podcast, който можете да гледате в YouTube . (EIP-7002 се споменава само накратко (28:55 до 30:00) във видеото).

За предистория Lido е описан като „систематична заплаха за Ethereum“, тъй като контролира ~ 33,3% от валидаторите на Beacon Chain и може да изложи на риск консенсуса на Ethereum; например, ако Lido DAO принуди операторите на възли да цензурират транзакции или да върнат предварително финализирани блокове ( Величината и посоката на векторите за атака на Lido на Mike Neuder описват заплахата по-подробно).

Въпреки това, един от ораторите в свързания по-рано епизод прави убедителния аргумент, че този вектор на атаката – DAO, принудително кооптиращ операторите на възли в атака срещу протокола Ethereum – все още не съществува, тъй като операторите на възли имат известна агенция. DAO може да задържи залога на валидатор, след като излезе, но не може да разчита на заплахата от принудително излизане, за да принуди валидатор да атакува консенсуса на Ethereum.

С EIP-7002 динамиката на мощността се променя значително: договорите за теглене, управлявани от DAO, могат да оттеглят оператор против неговите желания – давайки на DAO лост над операторите на възли. Този тип ливъридж е полезен за защита на протокол за залагане срещу злонамерен набор от оператори, както обясних по-рано. Но също така може да бъде злоупотребено в следните сценарии:

• Протоколът за залагане претърпява атака за управление и DAO предава злонамерено предложение за задействане на оттегляне на валидатор от договора за оттегляне
• Нападателят поема контрол над един или повече валидатори, като отвлича собствеността върху договора за заявка за теглене и изпълнява успешна стратегия за изнудване

Това е още един пример за това как EIP-7002 може да промени съществуващите предположения в дизайна на залагането – този път за операторите на възли, валидиращи от името на пул за залагане като Lido. Независимо от това, този вектор на атака може лесно да бъде смекчен чрез различни методи като използване на сигурни, строго одитирани и евентуално неподлежащи на надграждане договори за искане за теглене или следвайки най-добрите практики за сигурно управление на DAO .

За да се отчете крайният случай, при който оператор на възел претърпява загуби от принудително оттегляне, след като отхвърли исканията на нападател да наруши правилата на протокола, пуловете за залагане могат да се вдъхновят от компаниите за недвижими имоти, за да защитят операторите на възли:

• Преди да подпишат договор за наем, наемателите са длъжни да предоставят „гаранционен депозит“. Депозитът се съхранява в банкова сметка извън контрола на компанията за недвижими имоти.
• Ако наемателят се изнесе от апартамента, но остави след себе си значителни щети, компанията за недвижими имоти има право да използва гаранционния депозит за покриване на разходите за ремонт.
• Ако апартаментът е в добро състояние към момента на напускане на наемателя, гаранционният депозит се връща изцяло на наемателя.

Протоколът за залагане може да възприеме подобен подход за защита на операторите на възли, като сключи полица за „застрахователен фонд за оператори на възли“ чрез Nexus Mutual , Tidal Finance или всяка друга платформа за криптовалута. Ако валидаторът на оператор бъде оттеглен законно, застрахователният фонд се връща на DAO; ако обратното е вярно (напр. оттеглянето на валидатор е предизвикано от злонамерено предложение или грешка в договора за оттегляне), застрахователната полица изплаща щети на оператора на възела. Имайте предвид, че този подход може да се обобщи за всички съществуващи взаимоотношения, които разчитат на текущите спецификации за излизане от валидатор.

Липса на поддръжка за по-сложни EL-to-CL съобщения

Договорът за заявка за теглене на валидатор на EIP-7002 предоставя една единствена функционалност: изпращане на заявка за теглене от изпълнителния слой на Ethereum до консенсусния слой за изтегляне на валидатор. Някои обаче предложиха прилагане на обща рамка за съобщения (напр. предкомпилация SendMessageToConsensusLayer или договор на системно ниво на Generalized Message Bus (GMB), споменат по-рано) за предаване на общи типове съобщения между слоя за изпълнение и слоя за консенсус. Това може да има предимства като отключване на нови начини за активиране на валидатори във веригата Beacon Chain, особено ако прикачването на ETH към EL-to-CL съобщения е разрешено.

Въпреки това, както Danny Ryan (един от авторите на EIP-7002) обяснява в коментар , изразходването на ценно инженерно време върху обща рамка за съобщения EL → CL е „голямо начинание с неясно предложение за стойност“. За илюстрация, авторите на предложението за GMB (обща шина за съобщения) идентифицираха само един друг случай на употреба за шина за съобщения между EL и CL: ротация на идентификационни данни за теглене за валидатор от 0x0 до 0x01 идентификационни данни.

Това означава, че е по-вероятно първо да видим изпращането на договора за заявка за оттегляне на валидатора, преди основните разработчици да говорят за внедряване на обща шина за съобщения EL-to-CL, ако това някога се случи. Не че поддържането на нещата прости някога боли.

Простотата е предпоставка за надеждност. — Edsger W. Dijkstra

По-нови рискови вектори за съществуващи играчи

Разработих подробно предимствата на активирането на идентификационните данни за теглене, за да задействат теглене в по-голямата си част, но има някои крайни случаи, свързани с тази функция. Идеята е така (h/t към този коментар в GitHub ):

• Ако ключът за подписване на валидатор е компрометиран, хакерът може да поиска откуп или да се опита да намали баланса на валидатора, но не може да изтегли средства при никакъв сценарий. Ще последва игра на изчакване: Ще унищожи ли нападателят целия баланс или залагащият ще може да изтегли част от залога, след като валидаторът бъде изтеглен насила?
• Въпреки това, след като EIP-7002 бъде внедрен, хакерът в предишния сценарий може да продължи да излиза от валидатора и да изтегли баланса (след като EIP-7002 бъде внедрен), вместо да се примири с атака за скръб/изнудване.

Накратко, самостоятелните залагащи и услугите за залагане ще се нуждаят от повече защита за идентификационните данни за теглене след EIP 7002. Ето защо приемането на социално възстановяване, многофакторно (MFA) удостоверяване и ротация на ключове се считат за критични за подобряване на сигурността за соло/делегирани операции за залагане.

Избор на механизъм за ограничаване на скоростта

Функционалността на договора за заявка за теглене на валидатора add_withdrawal_request() не извършва никакви допълнителни проверки, освен проверка на прикачената такса за заявка за теглене, което потенциално позволява на атакуващ да задръсти опашката със съобщения с невалидни заявки за теглене (напр. съобщения за изход за несъществуващ валидатор или неактивен валидатор ще бъде анулиран по време на проверките за валидност на консенсусния слой). EIP-7002 използва такса за теглене с динамична цена, за да ограничи заявките за теглене и да направи подобни атаки скъпи, подобно на начина, по който EIP-1559 обезсърчава спам атаките и блокира пълнежа, като коригира цените на бензина въз основа на мрежовата активност.

Алтернативен дизайн е да се ограничат обажданията към договора за заявка за изтегляне на валидатор до действителни валидатори – например чрез проверка дали validator_pubkey съответства на публичния ключ на активен валидатор Beacon Chain. Това може да опрости дизайна на EIP-7002, като премахне необходимостта от сложен механизъм за ценообразуване в стил EIP-1559 и потенциално намали таксата за заявка за теглене, тъй като спамът на опашката с фалшиви заявки може да е по-малък проблем.

Това обаче изисква изпълнителният слой да може да има бездоверен достъп до информация за консенсусния слой – да проверява validator_pubkey спрямо валидаторния регистър на Beacon Chain – функция, която зависи от внедряването на EIP-4788. Това добавя повече сложност към EIP-7002 и въвежда нова зависимост между двата EIP, което може да има последици за бъдещи подобрения на дизайна, както е отбелязано в този раздел от обосновката на EIP-7002 .

Дори ако EIP-4788 беше интегриран с EIP-7002, пак ще имаме нужда от допълнителни механизми за предотвратяване на други форми на спам, които включват законни валидатори; пример е подаване на множество заявки за теглене за един и същ валидатор за много кратък период. Това от своя страна налага добавянето (и прилагането) на ново правило като „можете да подадете само една заявка за теглене на валидатор на всеки 3-4 месеца“, което може да изисква още повече промени в договора за заявка за теглене на валидатор.

За разлика от това, настоящият механизъм за ограничаване на скоростта е лесен за разсъждение и гарантира достатъчна защита срещу повечето проблеми със сигурността, свързани с тегления на ниво изпълнение. Например, таксата за заявка за теглене може автоматично да се коригира нагоре, за да възпре скръбта (опит за предотвратяване на изтегляне на честни валидатори) и спам и DOS атаки (опит за претоварване на Beacon Chain чрез принуждаване на консенсусните възли да губят ресурси за филтриране на невалидни операции за теглене).

Заключение: EIP-7002 и бъдещето на залагането на Ethereum

Делегираното залагане получи значителни критики през последните месеци, но е безопасно да се предположи, че индустрията за залагане като услуга е тук, за да остане. Ако е така, намаляването на риска за лицата, делегиращи дялове – независимо дали към ликвиден пул за залагане или институционална услуга за залагане без попечителство – е важно. EIP-7002 постига тази цел, като прави идентификационните данни за теглене 0x01 способни да излизат от валидатори и да изтеглят залог и намалява необходимостта залагащите да се доверяват на честността на оператора на възел.

EIP-7002 има и други положителни странични ефекти. По-специално, подобряването на устойчивостта и сигурността на операциите за соло залагане и разпределените валидатори – чрез позволяване на по-добро възстановяване от загуба на валидаторен ключ или DVT споделяне на ключове – трябва да намали бариерата пред соло залагането и да намали централизацията на залога в Ethereum.

Както обикновено, ще завърша, като ви помоля да обмислите споделянето на тази статия с някой, който може да я намери за информативна и, което е по-важно, да се абонирате за Ethereum 2077 за по-задълбочени гмуркания относно всички неща, свързани с R&D на Ethereum. Можете също да се свържете с мен в Twitter, за да споделите коментари или отзиви за тази статия.