Bagong artikulo ni Vitalik: Ang posibleng hinaharap ng Ethereum protocol The Verge

Sa katunayan, aabutin tayo ng ilang taon bago makuha ang validity proof ng Ethereum consensus.

Orihinal na Pamagat: 《Possible futures of the Ethereum protocol, part 4: The Verge》

May-akda: Vitalik Buterin

Pagsasalin: Mensh, ChainCatcher

 

Espesyal na pasasalamat kina Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams at Uma Roy para sa kanilang feedback at pagsusuri.

Isa sa pinakamakapangyarihang kakayahan ng blockchain ay ang sinuman ay maaaring magpatakbo ng node sa kanilang sariling computer at i-verify ang tamang estado ng blockchain. Kahit na ang 9596 na nodes na nagpapatakbo ng chain consensus (PoW, PoS) ay biglang magkasundo na baguhin ang mga patakaran at magsimulang gumawa ng mga block ayon sa bagong patakaran, ang bawat taong nagpapatakbo ng fully validating node ay tatanggihan ang chain. Ang mga minter na hindi kabilang sa ganitong uri ng sabwatan ay awtomatikong magtitipon sa isang chain na patuloy na sumusunod sa lumang mga patakaran at magpapatuloy sa pagbuo ng chain na iyon, at ang mga user na ganap na nagva-validate ay susunod sa chain na iyon.

Ito ang pangunahing pagkakaiba ng blockchain sa centralized na mga sistema. Gayunpaman, upang maging totoo ang katangiang ito, ang pagpapatakbo ng isang fully validating node ay kailangang maging praktikal para sa sapat na dami ng tao. Nalalapat ito sa mga proposer (dahil kung hindi nila vina-validate ang chain, hindi sila nakakatulong sa pagpapatupad ng protocol rules), at pati na rin sa mga ordinaryong user. Sa kasalukuyan, posible na magpatakbo ng node sa consumer laptop (kabilang ang laptop na ginamit sa pagsulat ng artikulong ito), ngunit mahirap itong gawin. Ang The Verge ay naglalayong baguhin ito, gawing mura ang computational cost ng fully validating chain, at gawing default ang validation kahit sa bawat mobile wallet, browser wallet, o kahit smartwatch.

The Verge 2023 Roadmap

Sa simula, ang "Verge" ay tumutukoy sa paglilipat ng Ethereum state storage sa Verkle tree—isang tree structure na nagpapahintulot ng mas compact na proofs, na nagbibigay-daan sa stateless validation ng Ethereum blocks. Ang isang node ay maaaring mag-validate ng Ethereum block nang hindi kailangang mag-imbak ng anumang Ethereum state (account balances, contract code, storage...) sa hard drive nito, kapalit ng ilang daang KB ng proof data at ilang daang millisecond ng dagdag na oras para mag-validate ng proof. Ngayon, ang Verge ay kumakatawan sa mas malawak na vision, na nakatuon sa pag-abot ng maximum resource efficiency validation ng Ethereum chain, na hindi lamang kinabibilangan ng stateless validation technology, kundi pati na rin ng paggamit ng SNARK para i-validate ang lahat ng Ethereum execution.

Maliban sa pangmatagalang focus sa SNARK validation ng buong chain, isa pang bagong usapin ay kung ang Verkle tree ba ang pinakamahusay na teknolohiya. Ang Verkle tree ay madaling maapektuhan ng quantum computers, kaya kung papalitan natin ang kasalukuyang KECCAK Merkle Patricia tree ng Verkle tree, baka kailanganin pa rin natin itong palitan sa hinaharap. Ang self-replacement method ng Merkle tree ay direktang laktawan ang paggamit ng Merkle branches ng STARK, at ilagay ito sa binary tree. Historically, dahil sa overhead at technical complexity, ang approach na ito ay itinuturing na hindi praktikal. Ngunit kamakailan, nakita natin na ang Starkware ay kayang mag-prove ng 1.7 million Poseidon hashes per second sa isang laptop gamit ang ckcle STARKs, at dahil sa mga teknolohiya tulad ng GKB, ang proof time para sa mas "traditional" hashes ay mabilis ding bumibilis. Kaya, sa nakaraang taon, naging mas open-ended ang "Verge", at may ilang posibleng direksyon ito.

The Verge: Mga Pangunahing Layunin

• Stateless client: Ang storage space na kailangan ng fully validating client at marker node ay hindi dapat lumampas sa ilang GB.
• (Pangmatagalan) Ganap na validation ng chain (consensus at execution) sa smartwatch. Mag-download ng ilang data, mag-validate ng SNARK, tapos na.

Sa kabanatang ito

• Stateless client: Verkle o STARKs
• Validity proof ng EVM execution
• Validity proof ng consensus

Stateless Validation: Verkle o STARKs

Anong problema ang sinusubukan nating lutasin?

Sa kasalukuyan, ang Ethereum client ay kailangang mag-imbak ng daan-daang gigabytes ng state data para mag-validate ng blocks, at patuloy itong lumalaki bawat taon. Ang raw state data ay nadadagdagan ng humigit-kumulang 30GB bawat taon, at kailangang mag-imbak ang bawat client ng dagdag na data para ma-update nang epektibo ang trie.

Nagpapababa ito ng bilang ng mga user na kayang magpatakbo ng fully validating Ethereum node: Kahit na maraming hard drive ang kayang mag-imbak ng lahat ng Ethereum state at kahit ilang taon ng history, ang mga computer na karaniwang binibili ng tao ay may ilang daang gigabytes lang na storage. Ang laki ng state ay nagdadala rin ng malaking friction sa proseso ng unang pag-setup ng node: kailangang i-download ng node ang buong state, na maaaring tumagal ng ilang oras o araw. Nagdudulot ito ng iba't ibang chain reactions. Halimbawa, pinapahirap nito nang husto ang pag-upgrade ng node setup ng mga node operator. Technically, maaaring gawin ito nang walang downtime—mag-launch ng bagong client, hintayin itong mag-sync, pagkatapos ay i-off ang lumang client at ilipat ang mga key—pero sa aktwal, napakakomplikado nito sa teknikal.

Paano ito gumagana?

Ang stateless validation ay isang teknolohiya na nagpapahintulot sa nodes na mag-validate ng blocks nang hindi hawak ang buong state. Sa halip, bawat block ay may kasamang witness na naglalaman ng: (i) values, code, balances, storage ng partikular na bahagi ng state na ia-access ng block; (ii) cryptographic proof na tama ang mga value na ito.

Sa aktwal, ang pagpapatupad ng stateless validation ay nangangailangan ng pagbabago sa state tree structure ng Ethereum. Ito ay dahil ang kasalukuyang Merkle Patricia tree ay napakahirap gamitin para sa anumang cryptographic proof scheme, lalo na sa worst case. Maging ito man ay "raw" Merkle branches, o posibilidad na i-wrap ito bilang STARK, pareho lang. Ang pangunahing kahirapan ay nagmumula sa ilang kahinaan ng MPT:

1. Isa itong hexary tree (ibig sabihin, bawat node ay may 16 na anak). Ibig sabihin, sa tree na may sukat na N, ang isang proof ay nangangailangan ng average na 32*(16-1)*log16(N) = 120*log2(N) bytes, o mga 3840 bytes sa tree na may 2^32 items. Sa binary tree, kailangan lang ng 32*(2-1)*log2(N) = 32*log2(N) bytes, o mga 1024 bytes.

2. Hindi naka-Merkle ang code. Ibig sabihin, para mapatunayan ang anumang access sa account code, kailangang ibigay ang buong code, hanggang 24000 bytes.

 

Maaari nating kalkulahin ang worst case tulad ng sumusunod:

30000000 gas / 2400 (cold account read cost) * (5 * 488 + 24000) = 330000000 bytes

Bahagyang mas mababa ang branch cost (gamit ang 5*480 sa halip na 8*480), dahil kapag maraming branches, inuulit ang top part nito. Pero kahit ganoon, hindi talaga praktikal ang dami ng data na kailangang i-download sa isang slot. Kung susubukan nating i-wrap ito bilang STARK, dalawang problema ang lalabas: (i) Hindi STARK-friendly ang KECCAK; (ii) Ang 330MB na data ay nangangahulugang kailangan nating mag-prove ng 5 million na tawag sa KECCAK round function, na maaaring hindi kayanin ng kahit anong hardware maliban sa pinakamalakas na consumer hardware, kahit pa mapabilis natin ang STARK proof ng KECCAK.

Kung direkta nating papalitan ng binary tree ang hex tree at gagawin pang Merkleized ang code, ang worst case ay magiging 30000000/2400*32*(32-14+8) = 10400000 bytes (14 ay minus para sa redundancy bits ng 2^14 branches, at 8 ay para sa proof length ng pagpasok sa code block leaf). Dapat tandaan na kailangan nitong baguhin ang gas cost, at mag-charge para sa bawat access sa code block; ganito ang ginagawa ng EIP-4762. Ang 10.4 MB na capacity ay mas maganda, pero para sa maraming nodes, masyado pa ring malaki ang kailangang i-download sa isang slot. Kaya, kailangan natin ng mas malakas na teknolohiya. Sa aspetong ito, may dalawang nangungunang solusyon: Verkle tree at STARKed binary hash tree.

Verkle Tree

Gumagamit ang Verkle tree ng elliptic curve-based vector commitments para sa mas maiikling proofs. Ang susi ay, kahit gaano kalapad ang tree, bawat parent-child proof part ay 32 bytes lang. Ang tanging limitasyon sa lapad ng proof tree ay kung masyadong malapad ito, babagal ang computation ng proof. Ang proposal para sa Ethereum ay may lapad na 256.

Kaya, ang laki ng isang branch sa proof ay nagiging 32 - log256(N) = 4*log2(N) bytes. Kaya, ang theoretical maximum proof size ay mga 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 bytes (dahil hindi pantay-pantay ang distribution ng state blocks, medyo iba ang aktwal na resulta, pero sapat na ito bilang unang approximation).

Dapat ding tandaan na sa lahat ng halimbawa sa itaas, ang "worst case" na ito ay hindi pa talaga worst case: mas masama pa kung sinadyang "i-mine" ng attacker ang dalawang address para magkaroon ng mas mahabang common prefix sa tree, at magbasa ng data mula sa isa sa mga address na iyon, na maaaring magdoble pa ng branch length sa worst case. Pero kahit ganoon, ang worst case proof length ng Verkle tree ay 2.6MB, na halos kapareho ng kasalukuyang worst case na verification data.

Ginagamit din natin ang observation na ito para sa isa pang bagay: ginagawang napakamura ang access sa "adjacent" storage space: maaaring maraming code blocks ng parehong contract, o magkatabing storage slots. Ang EIP-4762 ay nagbibigay ng definition ng adjacency, at nagcha-charge lang ng 200 gas fee para sa adjacent access. Sa ganitong kaso, ang worst case proof size ay nagiging 30000000 / 200*32 - 4800800 bytes, na nasa loob pa rin ng tolerance. Kung gusto nating mas mababa pa ito para sa seguridad, puwede nating bahagyang taasan ang fee para sa adjacent access.

STARKed Binary Hash Tree

Ang prinsipyo ng teknolohiyang ito ay simple: gumawa ka lang ng binary tree, kunin ang maximum na 10.4 MB na proof, i-prove ang values sa block, tapos palitan ang proof ng STARK proof. Sa ganitong paraan, ang proof mismo ay naglalaman lang ng data na pinapatunayan, dagdag ang 100-300kB na fixed overhead mula sa actual STARK.

Ang pangunahing hamon dito ay ang verification time. Maaari tayong gumawa ng halos parehong kalkulasyon tulad ng sa itaas, pero ang bibilangin natin ay hindi bytes kundi hashes. Ang 10.4 MB na block ay nangangahulugan ng 330000 hashes. Kung idagdag pa ang posibilidad na "i-mine" ng attacker ang address tree para magkaroon ng mas mahabang common prefix, ang worst case ay aabot sa 660000 hashes. Kaya, kung kaya nating mag-prove ng 200,000 hashes per second, ayos lang.

Sa consumer laptop gamit ang Poseidon hash function, na dinisenyo para maging STARK-friendly, naabot na ang mga numerong ito. Pero, ang Poseidon system ay medyo bago pa, kaya marami pa ang hindi tiwala sa seguridad nito. Kaya, may dalawang realistic na direksyon:

1. Mabilisang security analysis ng Poseidon, at sapat na familiarity para ma-deploy ito sa L1
2. Gumamit ng mas "conservative" na hash function, tulad ng SHA256 o BLAKE

Kung gusto nating mag-prove ng conservative hash function, ang STARK circuit ng Starkware ay kasalukuyang kayang mag-prove ng 10-30k hashes per second sa consumer laptop. Pero mabilis na umuunlad ang STARK technology. Kahit ngayon, ang GKR-based na technology ay nagpapakita ng posibilidad na itaas ito sa 100-200k range.

Mga Use Case ng Witness Bukod sa Block Validation

Maliban sa block validation, may tatlo pang pangunahing use case na nangangailangan ng mas efficient na stateless validation:

• Mempool: Kapag na-broadcast ang transaction, kailangang i-validate ng nodes sa P2P network ang transaction bago ito i-rebroadcast. Sa kasalukuyan, kasama sa validation ang pag-check ng signature, pati na rin ang pag-check ng balance at tamang nonce. Sa hinaharap (halimbawa, gamit ang native account abstraction tulad ng EIP-7701), maaaring kailanganin pang magpatakbo ng EVM code na mag-a-access ng ilang state. Kung stateless ang node, kailangang may kasamang proof ang transaction para sa state object.
• Inclusion list: Isang proposed feature na nagpapahintulot sa (maaaring maliit at hindi komplikadong) proof-of-stake validators na pilitin ang susunod na block na maglaman ng transaction, kahit ayaw ng (maaaring malaki at komplikadong) block builder. Binabawasan nito ang kakayahan ng mga makapangyarihan na manipulahin ang blockchain sa pamamagitan ng pag-delay ng transactions. Pero, kailangan ng validators ng paraan para i-validate ang validity ng transactions sa inclusion list.
• Light client: Kung gusto nating makapag-access ang users ng chain sa pamamagitan ng wallet (tulad ng Metamask, Rainbow, Rabby, atbp.), kailangan nilang magpatakbo ng light client (tulad ng Helios). Ang core module ng Helios ay nagbibigay ng verified state root sa user. Para sa tunay na trustless na karanasan, kailangan ng user na magbigay ng proof para sa bawat RPC call na ginagawa nila (halimbawa, para sa Ethereum call request, kailangang i-prove ang lahat ng state na na-access sa call).

Lahat ng use case na ito ay may isang bagay na pareho: nangangailangan sila ng maraming proofs, pero maliit lang ang bawat proof. Kaya, walang practical sense ang STARK proof para dito; ang pinaka-realistic na approach ay direktang gumamit ng Merkle branches. Ang isa pang advantage ng Merkle branches ay ang pagiging updatable: kung may proof ka para sa state object X na may root na block B, at makatanggap ka ng child block B2 at witness nito, maaari mong i-update ang proof para maging root na si block B2. Ang Verkle proofs ay natively updatable din.

Ano ang koneksyon nito sa kasalukuyang research:

• Verkle trees
• John Kuszmaul original paper tungkol sa Verkle tree
• Starkware
• Poseidon2 paper
• Ajtai (lattice-based na alternatibong mabilis na hash function)
• Verkle.info

Ano pa ang puwedeng gawin?

Ang natitirang pangunahing trabaho ay

1. Mas maraming analysis tungkol sa epekto ng EIP-4762 (pagbabago ng stateless gas cost)

2. Mas maraming trabaho sa pagbuo at pag-test ng transition program, na siyang pangunahing bahagi ng complexity ng anumang stateless implementation

3. Mas maraming security analysis para sa Poseidon, Ajtai, at iba pang "STARK-friendly" hash functions

4. Dagdag na development ng ultra-efficient STARK protocol features para sa "conservative" (o "traditional") hashes, tulad ng Binius o GKR-based na approaches.

Dagdag pa rito, malapit na tayong magdesisyon kung alin sa tatlong opsyon ang pipiliin: (i) Verkle tree, (ii) STARK-friendly hash function, at (iii) conservative hash function. Ang kanilang mga katangian ay maaaring buodin sa sumusunod na table:

Maliban sa mga "headline numbers" na ito, may iba pang mahahalagang konsiderasyon:

• Ngayon, ang Verkle tree code ay medyo mature na. Maliban sa Verkle, ang paggamit ng ibang code ay magpapaliban ng deployment, at malamang na magpapaliban ng isang hard fork. Ok lang din ito, lalo na kung kailangan natin ng dagdag na oras para sa hash function analysis o validator implementation, o may iba pa tayong importanteng feature na gustong isama agad sa Ethereum.
• Mas mabilis mag-update ng state root gamit ang hashes kaysa sa Verkle tree. Ibig sabihin, ang hash-based na approach ay maaaring magpababa ng sync time ng full node.
• May interesting witness update property ang Verkle tree—ang Verkle tree witness ay updatable. Mahalaga ito para sa mempool, inclusion list, at iba pang use case, at maaaring makatulong sa efficiency ng implementation: kung na-update ang state object, puwedeng i-update ang witness ng penultimate layer nang hindi binabasa ang last layer.
• Mas mahirap i-SNARK proof ang Verkle tree. Kung gusto nating paliitin pa ang proof size sa ilang libong bytes, may ilang hamon sa Verkle proof. Ito ay dahil ang verification ng Verkle proof ay nag-iintroduce ng maraming 256-bit operations, na nangangailangan ng proof system na may malaking overhead, o may custom internal structure na may 256-bit Verkle proof part. Hindi ito problema para sa stateless mismo, pero nagdadagdag ng komplikasyon.

Kung gusto nating makuha ang Verkle witness updatability sa quantum-safe at reasonably efficient na paraan, isa pang posibleng direksyon ay lattice-based Merkle tree.

Kung hindi sapat ang efficiency ng proof system sa worst case, maaari rin nating gamitin ang multidimensional gas bilang hindi inaasahang tool para punan ang kakulangan: magtakda ng hiwalay na gas limit para sa (i) calldata; (ii) computation; (iii) state access, at iba pang resources. Ang multidimensional gas ay nagpapataas ng complexity, pero kapalit nito, mas mahigpit nitong nililimitahan ang ratio ng average case at worst case. Sa multidimensional gas, ang theoretical maximum number ng branches na kailangang i-prove ay maaaring bumaba mula 12500 sa, halimbawa, 3000. Sa ganitong paraan, kahit ang BLAKE3 ay (bahagya) sapat na ngayon.

Pinapahintulutan ng multidimensional gas na mas malapit ang resource limits ng block sa resource limits ng underlying hardware

Isa pang hindi inaasahang tool ay ang pag-delay ng state root computation sa slot pagkatapos ng block. Sa ganitong paraan, may buong 12 segundo tayong mag-compute ng state root, ibig sabihin kahit sa pinaka-extreme na kaso, sapat na ang 60000 hashes per second na proof time, na muling nagpapakita na ang BLAKE3 ay bahagya lang sapat.

Ang downside ng approach na ito ay nadaragdagan ang light client latency ng isang slot, pero may mas clever na techniques para paliitin ito sa proof generation latency lang. Halimbawa, puwedeng i-broadcast agad ang proof sa network pagkatapos mag-generate ng kahit anong node, hindi na kailangang hintayin ang susunod na block.

Paano ito nakikipag-interact sa ibang bahagi ng roadmap?

Ang pagsasaayos ng stateless problem ay nagpapataas nang husto ng kahirapan ng single staking. Kung may teknolohiya para pababain ang minimum balance ng single staking, tulad ng Orbit SSF o application layer policies gaya ng squad staking, magiging mas praktikal ito.

Kung sabay na ipinatupad ang EOF, magiging mas madali ang multidimensional gas analysis. Ito ay dahil ang pangunahing execution complexity ng multidimensional gas ay mula sa pag-handle ng child calls na hindi nagpa-pass ng lahat ng gas mula sa parent call, at sa EOF, puwede lang gawing illegal ang ganitong child calls, kaya nagiging trivial ang problemang ito (at ang native account abstraction ay magbibigay ng protocol-level alternative para sa kasalukuyang pangunahing use case ng partial gas).

May mahalagang synergy din sa pagitan ng stateless validation at history expiry. Sa kasalukuyan, kailangang mag-imbak ng halos 1TB ng historical data ang client; ilang beses itong mas malaki kaysa sa state data. Kahit stateless ang client, maliban na lang kung matanggal natin ang obligasyon ng client na mag-imbak ng historical data, hindi matutupad ang pangarap ng halos walang storage na client. Ang unang hakbang dito ay ang EIP-4444, na nangangahulugang iimbak ang historical data sa torrents o Portal Network.

Validity Proof ng EVM Execution

Anong problema ang sinusubukan nating lutasin?

Ang pangmatagalang layunin ng Ethereum block validation ay malinaw—dapat kayang i-validate ang Ethereum block sa pamamagitan ng: (i) pag-download ng block, o kahit maliit na bahagi lang ng data availability sampling ng block; (ii) pag-validate ng maliit na proof na valid ang block. Isa itong operation na napakababa ng resource requirement, puwedeng gawin sa mobile client, browser wallet, o kahit sa ibang chain (walang data availability part).

Para maabot ito, kailangan ng SNARK o STARK proof para sa (i) consensus layer (ibig sabihin, proof-of-stake) at (ii) execution layer (ibig sabihin, EVM). Ang una ay isang challenge na dapat maresolba habang patuloy na pinapabuti ang consensus layer (halimbawa, para sa single-slot finality). Ang pangalawa ay nangangailangan ng EVM execution proof.

Ano ito, paano ito gumagana?

Sa pormal na anyo, sa Ethereum specification, ang EVM ay tinutukoy bilang state transition function: may pre-state S ka, block B, at kinukwenta mo ang post-state S' = STF(S, B). Kung light client ang user, wala silang buong S at S', o kahit E; sa halip, may pre-state root R, post-state root R', at block hash H sila.

• Public input: pre-state root R, post-state root R', block hash H
• Private input: block body B, objects sa state na ia-access ng block Q, parehong objects pagkatapos ng execution Q', state proof (tulad ng Merkle branches) P
• Claim 1: Valid proof si P na ang Q ay naglalaman ng ilang bahagi ng state na nire-representa ng R
• Claim 2: Kung patakbuhin ang STF sa Q, (i) ang execution process ay mag-a-access lang ng objects sa loob ng Q, (ii) valid ang block, (iii) ang resulta ay Q'
• Claim 3: Kung i-recompute ang bagong state root gamit ang impormasyon mula sa Q' at P, makukuha ang R'

Kung may ganito, puwedeng magkaroon ng fully validating Ethereum EVM execution light client. Napakababa na ng resource requirement ng client. Para sa tunay na fully validating Ethereum client, kailangan ding gawin ito para sa consensus.

May mga implementation na ng validity proof para sa EVM computation, at malawak itong ginagamit sa L2. Pero para maging feasible ang EVM validity proof sa L1, marami pang kailangang gawin.

Ano ang koneksyon nito sa kasalukuyang research?

• EFPSE ZK-EVM (hindi na ginagamit dahil may mas magagandang opsyon)
• Zeth, na nagko-compile ng EVM sa RISC-0 ZK-VM
• ZK-EVM formal verification project

Ano pa ang puwedeng gawin?

Sa kasalukuyan, may dalawang pangunahing kakulangan ang validity proof ng electronic accounting system: security at verification time.

Ang secure na validity proof ay nangangailangan ng garantiya na talagang vina-validate ng SNARK ang computation ng EVM, at walang vulnerabilities. Dalawang pangunahing teknolohiya para mapataas ang security ay multi-verifier at formal verification. Ang multi-verifier ay nangangahulugang may ilang independent na implementation ng validity proof, tulad ng maraming client, at kung ang isang block ay mapatunayan ng sapat na malaking subset ng mga implementation na ito, tatanggapin ng client ang block. Ang formal verification ay gumagamit ng tools na karaniwang ginagamit sa mathematical theorem proving, tulad ng Lean4, para patunayan na tinatanggap lang ng validity proof ang tamang execution ng underlying EVM specification (halimbawa, EVM K semantics o python-based na Ethereum Execution Layer Specification (EELS)).

Ang sapat na mabilis na verification time ay nangangahulugang dapat kayang i-validate ang anumang Ethereum block sa loob ng mas mababa sa 4 na segundo. Malayo pa tayo dito ngayon, kahit na mas malapit na tayo kaysa sa inakala natin dalawang taon na ang nakalipas. Para maabot ito, kailangan ng progreso sa tatlong direksyon:

• Parallelization—ang pinakamabilis na EVM verifier ngayon ay kayang mag-prove ng Ethereum block sa average na 15 segundo. Ginagawa ito sa pamamagitan ng parallelization sa daan-daang GPU, tapos pinagsasama-sama ang kanilang trabaho sa dulo. Theoretically, alam natin kung paano gumawa ng EVM verifier na kayang mag-prove ng computation sa O(log(N)) time: isang GPU bawat step, tapos gumawa ng "aggregation tree":

May mga hamon sa pagpapatupad nito. Kahit sa worst case, halimbawa, isang napakalaking transaction ang sumakop sa buong block, hindi puwedeng hatiin ang computation per transaction, kundi per opcode (EVM o RISC-V, atbp.). Ang pagtiyak na ang "memory" ng virtual machine ay consistent sa pagitan ng iba't ibang bahagi ng proof ay isang pangunahing hamon. Pero kung magawa natin ang recursive proof na ito, alam natin na kahit walang ibang improvement, naresolba na ang latency problem ng prover.

• Proof system optimization—ang mga bagong proof system tulad ng Orion, Binius, GRK, at iba pa, ay malamang na magdulot ng panibagong malaking pagbilis ng verification time para sa general computation.
• Iba pang pagbabago sa EVM gas cost—maraming bagay sa EVM ang puwedeng i-optimize para maging mas favorable sa prover, lalo na sa worst case. Kung puwedeng gumawa ng attacker ng block na magba-block sa prover ng sampung minuto, hindi sapat na kayang mag-prove ng ordinaryong Ethereum block sa 4 na segundo. Ang mga kinakailangang pagbabago sa EVM ay maaaring hatiin sa mga sumusunod na kategorya:
• Pagbabago ng gas cost—kung matagal mag-proof ng isang operation, kahit mabilis itong i-compute, dapat mataas ang gas cost nito. Ang EIP-7667 ay isang EIP na naglalayong tugunan ang pinakamatinding problemang ito: malaki ang itinaas ng gas cost ng (traditional) hash function, dahil mura ang opcode at precompile ng mga function na ito. Para mabawi ang dagdag na gas cost, puwede nating babaan ang gas cost ng EVM opcodes na mababa ang proof cost, para mapanatili ang average throughput.
• Pagpapalit ng data structure—maliban sa pagpapalit ng state tree sa mas STARK-friendly na paraan, kailangan ding palitan ang transaction list, receipt tree, at iba pang structure na mahal ang proof cost. Ang EIP ni Etan Kissling na naglilipat ng transaction at receipt structure sa SSZ ay isang hakbang sa direksyong ito.

Maliban dito, ang dalawang tools na nabanggit sa nakaraang seksyon (multidimensional gas at delayed state root) ay makakatulong din dito. Pero, dapat tandaan na, hindi tulad ng stateless validation, ang paggamit ng dalawang tools na ito ay nangangahulugang sapat na ang teknolohiya para matapos ang kailangan natin ngayon, at kahit gamitin ang mga ito, kailangan pa rin ng mas maraming trabaho para sa full ZK-EVM verification—mas kaunti lang ang kailangan.

Isang bagay na hindi nabanggit sa itaas ay ang prover hardware: paggamit ng GPU, FPGA, at ASIC para mas mabilis na mag-generate ng proof. Ang Fabric Cryptography, Cysic, at Accseal ay tatlong kumpanyang umuunlad dito. Napakahalaga nito para sa L2, pero malabong maging decisive factor para sa L1, dahil gusto ng lahat na manatiling highly decentralized ang L1, ibig sabihin, dapat kayang mag-generate ng proof ng ordinaryong Ethereum user, at hindi dapat maging bottleneck ang hardware ng isang kumpanya. Puwedeng mas agresibo ang tradeoff ng L2.

Sa mga larangang ito, marami pang kailangang gawin:

• Ang parallelization ng proof ay nangangailangan na puwedeng "mag-share ng memory" ang iba't ibang bahagi ng proof system (tulad ng lookup table). Alam natin ang mga teknolohiya para dito, pero kailangan pa itong i-implement.
• Kailangan pa ng mas maraming analysis para mahanap ang ideal na set ng gas cost changes para mapaliit ang worst case verification time.
• Kailangan pa ng mas maraming trabaho sa proof system

Mga posibleng trade-off:

• Security vs. prover time: Kung pipili ng mas agresibong hash function, mas komplikadong proof system, o mas agresibong security assumption o ibang design, maaaring mapabilis ang prover time.
• Decentralization vs. prover time: Kailangang magkasundo ang community sa "spec" ng prover hardware na target. Ok lang ba na malalaking entity ang prover? Gusto ba nating kayang mag-prove ng high-end consumer laptop ng Ethereum block sa 4 na segundo? O gitna?
• Antas ng paglabag sa backward compatibility: Ang iba pang kakulangan ay maaaring punan ng mas agresibong gas cost changes, pero mas malamang na magdulot ito ng hindi proporsyonal na pagtaas ng cost ng ilang application, na pipilitin ang mga developer na i-rewrite at i-redeploy ang code para manatiling economically viable. Gayundin, may sariling complexity at downsides ang dalawang tools na ito.

Paano ito nakikipag-interact sa ibang bahagi ng roadmap?

Ang core technology na kailangan para sa L1 EVM validity proof ay malaki ang overlap sa dalawang larangan:

• L2 validity proof (ibig sabihin, "ZK rollup")
• Stateless na "STARK binary hash proof" method

Kapag matagumpay na naipatupad ang validity proof sa L1, sa wakas ay magagawa ang madaling single staking: kahit ang pinakamahinang computer (kabilang ang mobile o smartwatch) ay kayang mag-stake. Pinapataas pa nito ang halaga ng pagresolba sa iba pang limitasyon ng single staking (tulad ng 32ETH minimum).

Dagdag pa rito, ang EVM validity proof ng L1 ay maaaring magpataas nang husto ng gas limit ng L1.

Validity Proof ng Consensus

Anong problema ang sinusubukan nating lutasin?

Kung gusto nating SNARK-validate ang isang Ethereum block nang buo, hindi lang EVM execution ang kailangang i-prove. Kailangan din nating i-prove ang consensus, ibig sabihin, ang bahagi ng system na nagha-handle ng deposits, withdrawals, signatures, validator balance updates, at iba pang bahagi ng Ethereum proof-of-stake.

Mas simple ang consensus kaysa sa EVM, pero ang hamon ay wala tayong L2 EVM convolution, kaya halos lahat ng trabaho ay kailangang gawin pa rin. Kaya, ang anumang implementation ng proof ng Ethereum consensus ay kailangang "from scratch", kahit na puwedeng i-build ang proof system sa shared work na ito.

Ano ito, paano ito gumagana?

Ang beacon chain ay tinutukoy bilang state transition function, tulad ng EVM. Ang state transition function ay pangunahing binubuo ng tatlong bahagi:

• ECADD (para sa pag-verify ng BLS signatures)
• Pairing (para sa pag-verify ng BLS signatures)
• SHA256 hash (para sa pagbabasa at pag-update ng state)

Sa bawat block, kailangan nating mag-prove ng 1-16 BLS12-381 ECADD para sa bawat validator (maaaring higit pa, dahil maaaring kasama ang signatures sa ilang sets). Puwedeng mapagaan ito gamit ang subset precomputation technique, kaya puwedeng sabihing isang BLS12-381 ECADD lang ang kailangang i-prove bawat validator. Sa kasalukuyan, may 30000 validator signatures bawat slot. Sa hinaharap, kapag naipatupad ang single-slot finality, maaaring magbago ito sa dalawang direksyon: kung brute force ang approach, maaaring tumaas sa 1 million ang validators bawat slot. Sa kabilang banda, kung Orbit SSF ang gamitin, mananatili sa 32768 ang validators, o bababa pa sa 8192.

Paano gumagana ang BLS aggregation: Ang pag-verify ng total signature ay nangangailangan lang ng isang ECADD bawat participant, hindi isang ECMUL. Pero 30000 ECADD pa rin ang malaking proof workload.

Para sa pairing, sa kasalukuyan, may maximum na 128 proofs bawat slot, ibig sabihin, kailangang mag-verify ng 128 pairings. Sa pamamagitan ng ElP-7549 at karagdagang pagbabago, puwedeng bumaba sa 16 bawat slot. Kaunti lang ang pairings, pero napakamahal ng cost: bawat pairing ay ilang libong beses na mas matagal i-run (o i-prove) kaysa sa ECADD.

Isa sa pangunahing hamon sa pag-prove ng BLS12-381 operations ay walang convenient curve na may order na katumbas ng field size ng BLS12-381, kaya nadadagdagan ang overhead ng anumang proof system. Sa kabilang banda, ang Verkle tree na proposal para sa Ethereum ay nakabase sa Bandersnatch curve, kaya ang BLS12-381 mismo ay nagiging SNARK system na ginagamit para mag-prove ng Verkle branches. Ang simpleng implementation ay kayang mag-prove ng 100 G1 additions per second; para mapabilis pa, malamang na kailangan ng techniques tulad ng GKR.

Para sa SHA256 hash, ang pinakamasamang kaso ngayon ay epoch transition block, kung saan kailangang i-update ang buong validator short balance tree at maraming validator balances. Ang short balance tree ng bawat validator ay isang byte lang, kaya may 1 MB ng data na kailangang i-rehash. Katumbas ito ng 32768 SHA256 calls. Kung may isang libong validator na may balance na lampas o kulang sa threshold, kailangang i-update ang effective balance sa validator record, kaya maaaring kailanganin ng 10000 hashes. Ang shuffling mechanism ay nangangailangan ng 90 bits bawat validator (kaya 11 MB ng data), pero puwedeng i-compute ito kahit kailan sa epoch. Sa single-slot finality, maaaring magbago ang mga numerong ito depende sa detalye. Hindi na kailangan ang shuffling, kahit na maaaring ibalik ito ng Orbit sa ilang antas.

Isa pang hamon ay kailangan nating kunin ulit ang lahat ng validator state, kabilang ang public key, para ma-verify ang block. Para sa 1 million validators, 48 million bytes lang ang kailangan para basahin ang public keys, dagdag pa ang Merkle branches. Kaya, bawat epoch, kailangan ng milyon-milyong hashes. Kung kailangan nating mag-prove ng validity ng PoS, isang realistic na paraan ay incremental verifiable computation: mag-store ng hiwalay na data structure sa proof system na optimized para sa efficient lookup at proof ng updates.

Sa kabuuan, maraming hamon. Para epektibong matugunan ang mga ito, malamang na kailangan ng malalim na redesign ng beacon chain, na maaaring mangyari kasabay ng paglipat sa single-slot finality. Ang mga katangian ng redesign na ito ay maaaring kabilang ang:

• Pagbabago ng hash function: Sa kasalukuyan, "full" SHA256 hash function ang ginagamit, kaya dahil sa padding, bawat call ay katumbas ng dalawang compression function calls. Kung SHA256 compression function lang ang gamitin, makakakuha tayo ng 2x gain. Kung Poseidon ang gamitin, maaaring 100x gain, na lubos na magre-resolve ng lahat ng problema natin (sa hash side): sa 1.7 million hashes per second (54MB), kahit 1 million validator records ay kayang "basahin" sa proof sa loob ng ilang segundo.
• Kung Orbit, direktang i-store ang shuffled validator records: Kung pipili ng tiyak na bilang ng validators (tulad ng 8192 o 32768) bilang committee ng slot, ilalagay sila nang magkatabi sa state, kaya minimal lang ang hash na kailangan para basahin ang lahat ng public keys ng validators sa proof. Pinapadali rin nito ang lahat ng balance updates.
• Signature aggregation: Anumang high-performance signature aggregation scheme ay mangangailangan ng recursive proof, kung saan ang iba't ibang nodes sa network ay gumagawa ng intermediate proof para sa subset ng signatures. Natural nitong hinahati ang proof workload sa maraming nodes sa network, kaya malaki ang nababawas sa trabaho ng "final prover".
• Iba pang signature scheme: Para sa Lamport+ Merkle signature, kailangan ng 256 + 32 hashes para mag-verify ng signature; i-multiply sa 32768 signers, makakakuha ng 9437184 hashes. Puwedeng mapabuti pa ito ng maliit na constant factor sa pamamagitan ng optimization ng signature scheme. Kung Poseidon ang gamitin, kayang i-prove ito sa isang slot. Pero sa aktwal, mas mabilis pa rin ang recursive aggregation scheme.

Ano ang koneksyon nito sa kasalukuyang research?

• Concise Ethereum consensus proofs (sync committee lang)
• Concise Helios in SP1
• Concise BLS12-381 precompile
• Halo2-based BLS aggregate signature verification

Ano pa ang kailangang gawin, at paano ang trade-off:

Sa aktwal, aabutin tayo ng ilang taon bago makuha ang validity proof ng Ethereum consensus. Katumbas ito ng oras na kailangan para sa single-slot finality, Orbit, pagbabago ng signature algorithm, at security analysis, na kailangan ng sapat na confidence para magamit ang "aggressive" hash function tulad ng Poseidon. Kaya, ang pinaka-makatwirang gawin ay lutasin muna ang ibang problemang ito, at isaalang-alang ang STARK-friendliness habang ginagawa ito.

Ang pangunahing trade-off ay malamang na nasa execution order, sa pagitan ng mas incremental na approach sa pagre-reform ng Ethereum consensus layer at mas aggressive na "one big change" approach. Para sa EVM, reasonable ang incremental approach dahil minimal ang disruption sa backward compatibility. Para sa consensus layer, mas maliit ang epekto sa backward compatibility, at may advantage ang mas "comprehensive" na rethinking ng detalye ng beacon chain construction para ma-optimize ang SNARK-friendliness sa pinakamahusay na paraan.

Paano ito nakikipag-interact sa ibang bahagi ng roadmap?

Sa pangmatagalang redesign ng Ethereum PoS, dapat gawing pangunahing konsiderasyon ang STARK-friendliness, lalo na para sa single-slot finality, Orbit, pagbabago ng signature scheme, at signature aggregation.