May-akda: Gray Lobster, Deep潮 TechFlow
Mayroong isang di-pagsasabing kaugalian ang mga developer ng Ethereum: kung pwede ay huwag mag-contact sa EVM.
Sa mga nakaraang taon, tuwing kailangan ng chain ng isang bagong kriptograpikong operasyon, ang unang reaksyon ng mga developer ay hindi mag-implement nito sa EVM, kundi humingi ng pagdaragdag ng isang "pre-compiled contract," isang shortcut na naglalabas sa virtual machine at direktang hard-coded sa protokol na antas.
Noong Marso 1, ang Vitalik Buterin ay nag-post ng mahabang post sa X, na direktang inilabas ang katotohanan. Ang kanyang orihinal na pahayag ay nagsasabi na ang buong kahulugan ng Ethereum ay ang kanyang pagiging generiko; kung ang EVM ay hindi sapat, dapat nating harapin ang problema at gumawa ng mas mabuting virtual machine.
Binigay niya ang dalawang espesipikong kutsilyo sa operasyon.
Unang pagkakataon: Palitan ang "data structure"
Ang unang pagbabago ay tungkol sa state tree ng Ethereum. Ito ay maaaring maunawaan bilang ang "sistema ng indeks ng libro" ng Ethereum, kung де saan bawat pagtatanong sa balanse o pagpapatotoo sa transaksyon, kailangang i-traverse ang puno.
Ang problema ay, ngayon ay sobrang "mataba" ang puno. Ginagamit ng Ethereum ang isang istrukturang tinatawag na "hexary Keccak Merkle Patricia tree" (ang pangalan ay parang isang anting-anting). Ang EIP-7864 na inilahad ni Vitalik ay nagsasaklaw na palitan ito ng isang mas simpleng binary tree.
Halimbawa: Noon, kailangan mong pumili ng direksyon ulit-ulit sa isang krusada na may anim na daan, ngayon, tanging kaliwa at kanan lang ang pagpipilian. Ano ang resulta? Ang haba ng Merkle branch ay diretso na binawasan sa kalahati ng orihinal. Para sa mga轻客户端, bumaba nang malaki ang bandwidth na kailangan para i-verify ang data.
Ngunit hindi natutuwa si Vitalik sa pagbabago ng hugis ng puno lamang. Gusto niya ring baguhin ang "uri ng titik sa mga dahon"—ang hash function. Ang dalawang kandidato ay ang Blake3 at Poseidon.
- Ang Blake3 ay nagdadala ng patuloy na pagpapabilis;
- Mas agresibo ang Poseidon, na teoretikal na makapagpapataas ng efficiency ng proof ng ilang dekada, ngunit kailangan pa ng karagdagang audit ang kaligtasan.
Mahalagang banggitin na ang solusyong ito ay nagpalit sa Verkle Trees, na dating pinag-uusapan ng komunidad sa loob ng maraming taon. Noong una, ang Verkle ay ang piniling solusyon para sa hard fork noong 2026, ngunit dahil sa mga banta ng quantum computing sa ilalim na elliptic curve cryptography nito, unti-unting nawalan ng suporta simula sa gitna ng 2024, at ang binary tree approach ang naging tagapagpaliwanag.
Second cut: Palitan ang "virtual machine", gawing isang smart contract ang EVM
Ang pangalawang pagbabago ay mas malakas at mas kontrobersyal: ang pagpalit ng EVM sa matagalang panahon gamit ang RISC-V architecture.
Ang RISC-V ay isang open-source instruction set na dating walang kinalaman sa blockchain, ngunit ngayon ay ginagamit ito sa loob ng lahat ng ZK proof systems. Ang lohika ni Vitalik ay direktang: kung ang prover ay nagsasalita na ng wika na RISC-V, bakit dapat ang virtual machine na magsalita ng ibang wika at magdagdag pa ng isang pagsasalin sa gitna? Alisin ang layer ng pagsasalin, at tataas agad ang efficiency.
Ang isang RISC-V interpreter ay kailangan ng ilang sandaang linya ng code lamang. Sabi ni Vitalik, ganito dapat ang anyo ng blockchain virtual machine.
Isinaplan niya ang tatlong hakbang: Una, gamitin ang bagong virtual machine para i-run ang pre-compiled contracts, at i-rewrite ang 80% ng mga pre-compiled na ito gamit ang bagong VM code; Pangalawa, payagan ang mga developer na direktang i-deploy ang mga contract ng bagong virtual machine, na magkakasabay na magpapatakbo kasama ang EVM; Pangatlo, i-retire ang EVM, ngunit hindi ito mawawala—ito ay i-rewrite bilang isang smart contract na nagpapatakbo sa bagong virtual machine, upang makamit ang ganap na backward compatibility.
Hindi kailangang palitan ng mga dating owner ang kanilang sasakyan. Tanging ang engine ang nagbago nang tahimik, ang steering wheel ay pareho pa rin.
Ilang importante ang dalawang bagay na ito kasama? Binigay ni Vitalik ang isang numero: ang state tree at virtual machine ay kumakapit sa higit sa 80% ng bottleneck ng proof ng Ethereum. Sa ibang salita, kung hindi mo pagbabagoan ang dalawang ito, ang scaling ng Ethereum sa panahon ng ZK ay magiging pagtakbo sa lugar.
Hindi sumasang-ayon ang Arbitrum: Hindi mo maaaring hilingin sa isang courier na gamitin ang forklift dahil sa isang warehouse ay gumagamit nito.
Ngunit hindi ito isang kuwento kung saan lahat ay bumabangong paalam.
Noong Nobyembre ng nakaraan taon, ang pangunahing ekipa ng pag-unlad ng Arbitrum, ang Offchain Labs, ay naglabas ng isang detalyadong teknikal na pagtutol. Ang pangunahing pananaw ng apat na mga mananaliksik ay: ang RISC-V ay talagang angkop para sa ZK proof, ngunit hindi ito angkop bilang "delivery format" para sa mga kontrata.
Nilikha nila ang isang mahalagang pagkakaiba, ang "delivery instruction set" (dISA) at "proof instruction set" (pISA) ay hindi kailangang magkapareho. Ang iyong warehouse ay maaaring magkaroon ng pinakamataas na efisensiya sa paggamit ng forklift, ngunit iyon ay hindi nangangahulugan na kailangan din ng courier na gamitin ang forklift upang magdala ng mga produkto sa harap ng iyong bahay.
Ang Offchain Labs ay nagtataguyod ng WebAssembly (WASM) bilang contract layer dahil sa matibay na mga dahilan: ang WASM ay may mataas na efficiency sa standard hardware, habang ang karamihan sa mga Ethereum node ay hindi nagpapatakbo ng RISC-V chips, at ang pagsisikap na magpalit ay nangangailangan ng emulator; ang WASM ay may matatag na mekanismo para sa type safety verification; at ang toolchain ecosystem ng WASM ay napatunayan na sa milyon-milyon na execution environment.
Mas mahalaga pa, hindi lang sila nagpapahayag. Ang Offchain Labs ay nagsagawa na ng isang prototype sa Arbitrum: gumagamit ng WASM bilang format ng pagpapadala ng contract, at pagkatapos ay ikinokompile sa RISC-V para sa ZK proof. Ang bawat layer ay gumagawa ng sarili nitong gawain, nang walang pagkakaabalisa.
Nilalay nila ang isang mahalagang panganib: ang teknolohiya sa larangan ng ZK proof ay nagbabago nang mabilis, at kamakailan ay napalitan na ng 64-bit ang implementasyon ng RISC-V mula sa 32-bit. Kung i-weld na ngayon ang RISC-V sa Ethereum L1, ano kung may mas mabuting proof architecture na lumalabas sa loob ng dalawang taon? Ang pagtaya sa isang mabilis na umuunlad na target ay hindi ang istilo ng Ethereum.
Isang mas malaking konteksto: Ang mga L2 ay nagsisimulang magwala sa pagbubuntis
Kailangan ng mas malawak na konteksto upang maunawaan ang panukalang ito.
Isa buwan na ang nakalipas, binigyang-pansin ni Vitalik ang kailangan ba pa ng Ethereum ng isang "espesyal na roadmap para sa L2," na nagdulot ng kolektibong tugon mula sa L2 camp. Sinabi ni Ben Fisch, CEO ng Espresso Systems, sa CoinDesk: Ang ibig sabihin ni Vitalik ay ang orihinal na layunin ng L2 ay tulungan ang Ethereum na mas lalo pang ma-expand, at ngayon na hinahabol ng Ethereum ang pagiging mas mabilis, kailangan ring baguhin ang posisyon ng L2.
Kakaibang, ang mga L2 ay hindi nagkakaroon ng panik, kundi nagsisimula na aktibong "maging malaya sa Ethereum". Ang co-founder ng OP Labs, Jing Wang, ay nagkukumpara ng mga L2 sa mga independiyenteng website, habang ang Ethereum ay ang pana-panahong bukas na istandar para sa pagkakasundo. Mas direkta naman ang CEO ng Polygon, Marc Boiron: ang totoong hamon ay hindi ang pagpapalawak, kundi ang pagbuo ng natatanging区块空间 para sa totoong aplikasyon tulad ng pagbabayad.
Sa ibang salita, ang malaking pagbabago ni Vitalik sa execution layer ay isang teknikal na komento sa isang mas malaking trend: ang Ethereum ay bumabalik sa pagkakaroon ng kontrol sa sariling pangunahing kakayahan, habang ang mga L2 ay pinipilit o sa huli ay natagpuan ang kanilang sariling dahilan para umiral.
Makakarating ba ito?
Kinikilala rin ni Vitalik na wala pa ring malawakang pagkakasundo sa komunidad ng mga developer tungkol sa pagpalit sa virtual machine. Mas matatag ang reporma sa state tree, at mayroon nang konkretong draft at team na nagpapalaya sa EIP-7864. Ngunit ang pagpalit sa EVM gamit ang RISC-V? Nananatili pa ito sa "roadmap" stage, at malayo pa sa pagkakasulat sa code.
Gayon naman ay nagbigay si Vitalik ng isang nakakaimpresong pahayag noong nakaraang linggo: ang Ethereum ay nagsagawa na ng isang pagbabago ng jet engine habang nasa hangin (tungkol sa The Merge), at maaari pa itong magkaroon ng apat pang pagbabago—ang state tree, simplified consensus, ZK-EVM verification, at virtual machine replacement.
Inaasahan na maipatupad ang Ethereum Glamsterdam upgrade sa unang kalahati ng 2026, kasunod ng Hegota. Ang mga detalye ng dalawang hard fork ay hindi pa opisyal, ngunit ang pagbabago sa state tree at pagpapabuti sa execution layer ay ang tiyak na pangunahing direksyon.
Ang kuwento ng Ethereum ay hindi kailanman tungkol sa "kakayahan o hindi". Mula sa PoW patungo sa PoS, mula sa L1 all-in hanggang sa Rollup-centered, patunay na ito ay may kakayahang at tapang na alisin ang mga engine sa taas ng 10,000 metro.
Ang pagbabago na ito ay hahawak sa mas malalim na bagay—hindi pagdaragdag ng mga bagong tampok, kundi pagbuwis ng lumang pundasyon at pagpapalit nito. Ito ba ay isang mabuting pinaplano na pagpapabago, o isang walang hanggang liblib na nagiging mas kumplikado habang pinagpapabuti? Ang sagot ay maaaring makikita lamang noong 2027.
Ngunit isa sa mga bagay na tiyak ay: ang Ethereum ay hindi nais maging isang "lumang sistema na may patch" sa panahon ng ZK. Kung paano tanggalin ang mga patch at anong uri ng engine ang dapat palitan, ang pagtalakay mismo, maaaring mas may halaga kaysa sa konklusyon.