Pinakabagong pananaliksik ni Vitalik: Anong mga pagbabago ang kailangan sa LSDFi protocol at liquidity upang mapataas ang desentralisasyon at mabawasan ang consensus overload?

Ang artikulong ito ay pangunahing tumutuon sa kasalukuyang mga panganib ng sentralisasyon ng node operator at hindi kinakailangang consensus burden sa mga LSDFi protocol at liquidity pool.

May-akda:Vitalik Buterin

Pagsasalin: bayemon.eth, ChainCatcher

Ang kasalukuyang estado ng pag-unlad ng Ethereum ay maaaring sabihing naglalaman ng maraming two-tiered staking, kung saan ang tinutukoy na two-tiered staking ay isang modelo ng staking na may dalawang uri ng kalahok.

• Node Operator: Nagpapatakbo ng node, at gumagamit ng sariling reputasyon at tiyak na halaga ng sariling kapital bilang collateral
• Delegator: Ang mga delegator ay nagsta-stake ng tiyak na dami ng Ethereum, walang minimum na halaga, at walang karagdagang limitasyon sa iba pang paraan ng partisipasyon maliban sa collateral

Ang bagong anyo ng two-tiered staking na ito ay nabuo sa pamamagitan ng malawakang partisipasyon sa mga staking pool na nagbibigay ng liquid staking token (LST). (Rocket Pool at Lido ay parehong gumagamit ng ganitong modelo).

Gayunpaman, ang kasalukuyang two-tiered staking ay may dalawang depekto:

• Panganib ng sentralisasyon ng node operator: Sa kasalukuyan, ang mekanismo ng pagpili ng node operator sa lahat ng staking pool ay labis pa ring sentralisado
• Hindi kinakailangang consensus burden: Ang Ethereum L1 ay kailangang mag-verify ng humigit-kumulang 800,000 na lagda bawat Epoch, na isang napakalaking load para sa bawat slot. Bukod dito, dahil nangangailangan ng mas malaking pondo ang mga liquid staking pool, ngunit hindi naman sapat na nakikinabang ang network mula sa load na ito. Kaya, kung makakamit ng Ethereum network ang makatwirang decentralization at seguridad nang hindi kinakailangang mag-sign ng bawat staker sa bawat slot, maaaring gamitin ng komunidad ang ganitong solusyon upang epektibong mabawasan ang bilang ng mga lagda bawat slot.

Ipinapaliwanag ng artikulong ito ang mga solusyon sa dalawang nabanggit na problema, sa pag-aakalang karamihan ng kapital ay hawak ng mga taong ayaw personal na magpatakbo ng staking node sa kasalukuyang anyo, mag-sign sa bawat slot, mag-lock ng deposito at muling ipamahagi sa mga na-slash na pondo, sa ganitong kalagayan, anong papel pa ang maaari nilang gampanan upang makapag-ambag pa rin ng makabuluhan sa decentralization at seguridad ng network?

Paano gumagana ang kasalukuyang two-tiered staking?

Sa kasalukuyan, ang dalawang pinakasikat na staking pool ay Lido at RocketPool. Para sa Lido, ang dalawang kalahok ay:

• Node Operator: Pinipili ng Lido DAO sa pamamagitan ng pagboto, ibig sabihin, pinipili ng mga LDO holder. Kapag may nagdeposito ng ETH sa Lido smart contract system, nagkakaroon ng stETH, at maaaring i-stake ito ng node operator (ngunit dahil ang withdrawal credential ay naka-bind sa smart contract address, hindi basta-basta makakapag-withdraw ang operator)
• Delegator: Kapag may nagdeposito ng ETH sa Lido smart contract system, nagkakaroon ng stETH, at maaaring i-stake ito ng node operator (ngunit dahil ang withdrawal credential ay naka-bind sa smart contract address, hindi basta-basta makakapag-withdraw ang operator)

Para naman sa Rocket Pool:

• Node Operator: Kahit sino ay maaaring maging node operator, kailangan lang magdeposito ng 8 ETH at tiyak na dami ng RPL token.
• Delegator: Kapag may nagdeposito ng ETH sa Rocket Pool smart contract system, nagkakaroon ng rETH, at maaaring i-stake ito ng node operator (ganun din, dahil ang withdrawal credential ay naka-bind sa smart contract address, hindi basta-basta makakapag-withdraw ang operator).

Papel ng Delegator

Sa mga sistemang ito (o sa mga bagong sistema na maaaring paganahin ng mga potensyal na pagbabago sa protocol sa hinaharap), isang mahalagang tanong ang kailangang sagutin: Mula sa pananaw ng protocol, ano ang saysay ng pagkakaroon ng delegator?

Upang maunawaan ang lalim ng tanong na ito, isipin muna natin, para sa nabanggit na pagbabago sa protocol sa post, na lilimitahan ang slash penalty sa 2ETH, bababaan din ng Rocket Pool ang staking amount ng node operator sa 2ETH, at tataas ang market share ng Rocket Pool sa 100%/ (para sa mga staker at ETH holder, habang nagiging risk-free ang rETH, halos lahat ng ETH holder ay magiging rETH holder o node operator).

Ipalagay na ang return rate ng rETH holder ay 3% (kasama ang protocol rewards at priority fees + MEV), at ang return rate ng node operator ay 4%. Ipalagay din natin na ang total supply ng ETH ay 100 millions.

Narito ang resulta ng kalkulasyon. Para maiwasan ang compounding, gagamitin natin ang araw bilang unit ng kita:

Ngayon, ipagpalagay na walang Rocket Pool, bawat staker ay may minimum deposit na 2 ETH, ang kabuuang liquidity cap ay 6.25 million ETH, at ang return rate ng node operator ay bumaba sa 1%. Kalkulahin ulit natin:

Mula sa pananaw ng attack cost, pag-isipan natin ang dalawang sitwasyon. Sa unang sitwasyon, hindi magrerehistro ang attacker bilang delegator, dahil wala namang withdrawal rights ang delegator, kaya walang saysay. Kaya, gagamitin nila lahat ng ETH nila para mag-stake at maging node operator. Para maabot ang 1/3 ng kabuuang staked amount, kailangan nilang mag-invest ng 2.08 million ETH (sa totoo lang, malaki pa rin ang numerong ito). Sa pangalawang sitwasyon, kailangan lang mag-invest ng attacker, at para maabot ang 1/3 ng kabuuang staked pool, kailangan pa rin nilang mag-invest ng 2.08 million ETH.

Mula sa staking economics at attack cost, magkapareho ang resulta ng dalawang sitwasyon. Ang share ng node operator sa total ETH supply ay tumataas ng 0.00256% kada araw, habang ang share ng non-node operator ay bumababa ng 0.00017% kada araw. Ang attack cost ay 2.08 million ETH. Kaya, sa modelong ito, ang delegator ay tila isang walang saysay na Rube Goldberg machine, at ang rasyonal na komunidad ay mas pipiliing alisin ang middleman, bawasan nang malaki ang staking reward, at limitahan ang total staked ETH sa 6.25 million.

Siyempre, hindi sinasabi ng artikulong ito na dapat bawasan ng 4 na beses ang staking reward at limitahan ang total staking cap sa 6.25 million. Sa halip, ang punto ng artikulo ay ang isang maayos na staking system ay dapat may mahalagang katangian: ang delegator ay dapat may mahalagang responsibilidad sa buong sistema. Bukod dito, kung ang delegator ay gumagawa ng tamang aksyon dahil sa pressure ng komunidad at altruismo, ayos lang iyon; sa katunayan, ito ang pangunahing puwersa na nagtutulak sa mga tao ngayon na itaguyod ang decentralized at high-security staking solution.

Mga Responsibilidad ng Delegator

Kung ang delegator ay maaaring gumanap ng makabuluhang papel sa staking system, ano kaya ang papel na iyon?

Sa tingin ko, may dalawang uri ng sagot:

• Pagpili ng delegator: Maaaring pumili ang delegator kung kaninong node operator nila ipagkakatiwala ang kanilang stake. Ang "weight" ng node operator sa consensus mechanism ay proporsyonal sa kabuuang stake na na-delegate sa kanila. Sa kasalukuyan, limitado pa rin ang mekanismo ng pagpili ng delegator, ibig sabihin, maaaring i-withdraw ng rETH o stETH holder ang kanilang ETH at lumipat sa ibang pool, ngunit maaaring lubos pang mapabuti ang aktwal na kakayahan ng pagpili ng delegator.
• Partisipasyon sa consensus mechanism: Maaaring pumili ang delegator na gumanap ng tiyak na papel sa consensus mechanism, mas magaan ang responsibilidad kaysa sa full subscription, walang mahabang exit period at slash risk, ngunit nakakatulong pa rin bilang balanse sa node operator.

Pinalakas na Karapatan ng Pagpili ng Delegator

May tatlong paraan upang palakasin ang karapatan ng pagpili ng delegator:

• Pahusayin ang voting tools sa loob ng pool
• Dagdagan ang kompetisyon sa pagitan ng mga pool
• Gawing fixed ang delegation right

Sa kasalukuyan, hindi praktikal ang pagboto sa loob ng pool: Sa Rocket Pool, kahit sino ay maaaring maging node operator, sa Lido, ang pagboto ay desisyon ng LDO holder, hindi ng ETH holder. Nagmungkahi ang Lido ng proposal para sa LDO + stETH dual governance, kung saan maaari nilang i-activate ang isang protection mechanism upang pigilan ang bagong boto, kaya hindi basta-basta madadagdag o matatanggal ang node operator, na nagbibigay ng boses sa stETH holder. Gayunpaman, limitado pa rin ang kapangyarihang ito at maaari pang palakasin.

Umiiral na ngayon ang kompetisyon sa pagitan ng mga pool, ngunit mahina pa. Ang pangunahing hamon ay ang mga mas maliit na staking pool ay may mas mababang liquidity ng staking token, mahirap pagkatiwalaan, at kakaunti ang suporta mula sa mga application.

Maaari nating mapabuti ang unang dalawang problema sa pamamagitan ng paglimita ng slash amount sa mas maliit na halaga, halimbawa 2 o 4 ETH. Pagkatapos, ang natitirang ETH ay maaaring ligtas na ideposito at agad na ma-withdraw, kaya't ang two-way redemption ay posible pa rin para sa mas maliliit na staking pool. Maaari nating mapabuti ang ikatlong problema sa pamamagitan ng paglikha ng isang total issuance contract para sa pamamahala ng LST (katulad ng ERC-4337 at ERC-6900 para sa wallet contract), upang matiyak na anumang staking token na inilabas sa pamamagitan ng contract na ito ay ligtas.

Sa kasalukuyan, wala pang fixed delegation power sa protocol, ngunit posible ito sa hinaharap. Kabilang dito ang logic na katulad ng nabanggit sa itaas, ngunit ipinatutupad sa protocol level. Para sa mga kalamangan at kahinaan ng fixed delegation, tingnan ang artikulong ito.

Ang mga ideyang ito ay mga pagpapabuti sa kasalukuyang kalagayan, ngunit limitado ang mga benepisyong maibibigay nila. May problema ang token voting governance, at sa huli, anumang anyo ng non-incentivized delegation ay isang anyo ng token voting; ito ang pangunahing reklamo ko sa delegated proof of stake. Kaya, mahalaga ring isaalang-alang ang mas malakas na paraan ng consensus participation.

Partisipasyon sa Consensus

Kahit hindi isaalang-alang ang kasalukuyang problema ng liquid staking, may limitasyon din ang kasalukuyang independent staking method. Ipagpalagay na gumagamit ng single-slot finality, sa ideal na estado, bawat slot ay maaaring magproseso ng humigit-kumulang 100,000 hanggang 1,000,000 BLS signatures. Kahit gumamit tayo ng recursive SNARKs para i-aggregate ang signatures, para sa traceability ng signature, kailangang bigyan ng bitfield ng participant ang bawat signature. Kung magiging global scale ang Ethereum, hindi sapat ang fully decentralized storage ng bitfield: bawat slot na may 16 MB ay kayang suportahan ang humigit-kumulang 64 million staker lamang.

Mula sa pananaw na ito, mahalaga ang paghahati ng staking sa mas mataas na complexity na slashable layer at mas mababang complexity na layer. Ang high-complexity layer ay epektibo sa bawat slot, ngunit maaaring may 10,000 kalahok lamang, habang ang low-complexity layer ay tinatawag lang paminsan-minsan para lumahok. Ang low-complexity layer ay maaaring walang slash risk, o maaaring random na bigyan ng pagkakataon ang kalahok na magdeposito at maging slashable sa loob ng ilang slot.

Sa aktwal, maaaring gawin ito sa pamamagitan ng pagtaas ng validator balance cap, at pagkatapos ay pagtaas ng balance threshold (halimbawa, 2048 ETH) para matukoy kung aling validator ang papasok sa high-complexity o low-complexity layer.

Narito ang ilang suhestiyon kung paano gumagana ang mga small-stake role na ito:

• Bawat slot, random na pipili ng 10,000 small staker, na maaaring mag-sign ng tingin nilang tamang nilalaman para sa slot na iyon. Gamitin ang small staker bilang input para patakbuhin ang LMD GHOST fork choice rule. Kung may hindi pagkakaunawaan sa fork choice ng small staker at node operator, hindi tatanggapin ng client ng user ang anumang block bilang finalized at magpapakita ng error. Mapipilitan ang komunidad na makialam para lutasin ang sitwasyon.
• Maaaring magpadala ng transaction ang delegator para ipahayag sa network na online sila at handang maging small staker sa susunod na isang oras. Ang mga mensahe (block o proof) na ipinapadala ng node ay kailangang lagdaan ng node at ng random na napiling delegator para sa confirmation.
• Maaaring magpadala ng transaction ang delegator para ipahayag sa network na online sila at handang maging small staker sa susunod na isang oras. Bawat epoch, pipili ng 10 random delegator bilang inclusion list provider, at pipili ng 10,000 pang delegator bilang voter. Pinipili ito bago ang k-slot, at may k-slot window para mag-post ng on-chain confirmation na online sila. Bawat inclusion list provider na nakumpirma ay maaaring mag-post ng inclusion list, maliban kung para sa bawat inclusion list, alinman sa isama ang transaction sa list, o isama ang boto ng karaniwang 1 na napiling voter na nagpapakita ng unavailable ang inclusion list, kung hindi, ang block ay ituturing na invalid.

Ang mga small staking node na ito ay may isang bagay na magkatulad: hindi nila kailangang aktibong lumahok sa bawat slot, at kahit light node lang ay sapat na para gawin ang lahat ng trabaho. Kaya, ang node deployment ay kailangang mag-verify lang ng consensus layer, at maaaring gawin ng node operator sa pamamagitan ng application o browser plugin, na kadalasan ay passive, mababa ang computational overhead, hardware requirement, o technical know-how, at hindi na kailangan ng advanced na teknolohiya gaya ng ZK-EVM.

Ang mga "maliit na papel" na ito ay may iisang layunin: pigilan ang 51% majority node operator na mag-censor ng transaction. Ang una at pangalawa ay nakakapigil din sa majority na mag-revert ng finality. Ang pangatlo ay mas direktang nakatuon sa censorship, ngunit mas madaling maapektuhan ng pagpili ng majority node operator.

Ang mga ideyang ito ay isinulat mula sa pananaw ng pagpapatupad ng two-tiered staking solution sa protocol, ngunit maaari rin itong ipatupad bilang function ng staking pool. Narito ang ilang partikular na ideya ng pagpapatupad:

1. Mula sa pananaw ng protocol, bawat validator ay maaaring magtakda ng dalawang staking key: isang persistent staking key P, at isang naka-bind na Ethereum address na maaaring tawagin, at mag-output ng isang mabilis na staking key Q. Ang mga lagda ng node sa fork choice ay sinusubaybayan gamit ang P, at ang mga lagda gamit ang Q. Kung hindi magkatugma ang resulta ng PQ storage, hindi tatanggapin ang anumang block bilang finalized, at ang liquidity pool ang bahalang pumili ng random na representative.
2. Maaaring hindi magbago nang malaki ang protocol, ngunit ang public key ng validator para sa slot na iyon ay itatakda bilang P+Q. Pansinin na para sa slashing, maaaring magkaiba ang Q key ng dalawang slashable message, ngunit pareho ang P key; kailangang tugunan ng slashing design ang ganitong sitwasyon.
3. Ang Q key ay maaari lamang gamitin sa protocol para sa pag-sign at pag-verify ng inclusion list sa block. Sa kasong ito, maaaring maging smart contract ang Q, hindi lang isang key, kaya maaaring gamitin ng staking pool ito para magpatupad ng mas komplikadong voting logic, tumanggap ng inclusion list mula sa random na napiling provider o sapat na boto na nagpapakitang unavailable ang inclusion list.

Konklusyon

Kung maayos na ipinatupad, ang mga fine-tuning sa disenyo ng proof of stake ay maaaring sabay na lutasin ang dalawang problema:

• Magbigay ng pagkakataon sa mga walang sapat na resources o kakayahan para sa independent proof of stake na makilahok sa proof of stake, kaya't mas maraming kapangyarihan ang mapapanatili sa kanilang kamay: kabilang ang (i) kapangyarihang pumili kung aling node ang susuportahan at (ii) aktibong makilahok sa consensus sa mas magaan ngunit makabuluhang paraan kaysa sa full operation ng proof of stake node. Hindi lahat ng kalahok ay pipili ng isa o parehong opsyon, ngunit sinumang pipili ng isa o parehong opsyon ay magkakaroon ng malaking pagbuti kumpara sa kasalukuyan.
• Bawasan ang bilang ng mga lagda na kailangang iproseso ng Ethereum consensus layer sa bawat slot, kahit sa single slot finality, at gawing humigit-kumulang 10,000 na lang ito. Makakatulong din ito sa decentralization, at mas mapapadali para sa lahat na magpatakbo ng validator node.

Para sa mga solusyong ito, maaaring makahanap ng paraan sa iba't ibang antas ng abstraction: mga karapatang ibinibigay sa user sa loob ng proof of stake protocol, pagpili ng user sa pagitan ng proof of stake protocol, at ang pagtatatag sa protocol. Dapat pag-isipang mabuti ang pagpili, at kadalasan ay mas mainam na piliin ang pinakamaliit na posibleng pagtatatag, upang mabawasan ang complexity ng protocol at ang antas ng pagbabago sa protocol economics, habang natatamo pa rin ang inaasahang layunin.

Espesyal na pasasalamat kina Mike Neuder, Justin Drake at iba pa sa feedback at pagsusuri. Tingnan din: Mga artikulo nina Mike Neuder, Dankrad Feist at arixon.eth tungkol sa katulad na paksa.