Bakit Kailangan ng Ethereum ang ZK-VM: Ang Pinakamataas na Landas ng Scalability

Sa maraming ideya ng pag-scale ng Ethereum, ang ZK ang pinaka-komplikado at pinakamahalagang direksyon.

Sa buong network, si Vitalik at ang Ethereum Foundation ang may pinakamalaking pagtaya sa ZK. Ang ZK ay parang bunsong anak ng Ethereum, pinagbuhusan ng pinakamaraming atensyon, ngunit ang hinaharap ay pinaka-hindi tiyak.

Ilang araw na ang nakalipas, naglabas ang Ethereum Foundation ng Kohaku roadmap, isang plano para sa mga pangunahing bahagi ng privacy wallet. Muling binigyang-diin ng roadmap na maraming pangunahing function ang patuloy na aasa sa pag-deploy ng ZK-EVM o ZK-VM.

Kaya, bakit napaka-urgent ng pangangailangan ng Ethereum para sa ZK-VM?

Napakasimple ng sagot: Para sa pagpapabuti ng performance, at hindi sa kapinsalaan ng seguridad.

Ang Bottleneck ng Pagpapabuti ng Performance: Lahat ay Nagbe-verify at GAS Limit

Nabanggit na namin dati, ang pinakamabilis na paraan para mapabuti ang performance ng Ethereum ay ang pagtaas ng GAS limit, ibig sabihin ay gawing mas malaki ang block.

Ngunit ang problema, ang pagtaas ng GAS limit ay may kapalit, ang sobrang laki ng block ay mabigat na pasanin para sa mga node.

Sa kasalukuyan, gumagamit ang Ethereum ng isang tinatawag na “lahat ay nagbe-verify” na verification mode, ibig sabihin lahat ng node ay kailangang kumpletong i-verify ang bawat block. Simple at ligtas ang mekanismong ito, ngunit sobrang redundant.

Kung malaki ang itinaas ng GAS limit, sabay-sabay ding tataas ang computational load ng bawat node.

Isinasaalang-alang na ang block interval ng Ethereum ay 12 segundo lamang, at kailangan pang maglaan ng oras para sa block propagation at MEV sorting, ang aktwal na oras na magagamit ng validator para mag-verify ay mga 4–8 segundo lang, halos walang natitirang oras para sa mas malaking load.

Ethereum Pagkatapos ng ZK: Mula “Lahat ay Nagbe-verify” tungo sa “Lahat ay Isang Beses Lang Magbe-verify”

Kung ang Ethereum L1 ay ganap na gawing ZK, ang verification mode ay magbabago mula “lahat ay nagbe-verify” tungo sa “lahat ay isang beses lang magbe-verify”. Sa mode na ito, kapag na-assemble na ang isang block, unang gagawa ng ZK proof.

Ang katangian ng ZK ay mabagal gumawa ng proof, pero sobrang bilis mag-verify. Kaya, kailangang i-verify lang ng node nang isang beses kung tama ang proof, at hindi na kailangang ulitin ang lahat ng transaksyon sa block.

Ibig sabihin nito, maaaring tumaas nang malaki ang GAS limit ng Ethereum nang hindi gaanong nadaragdagan ang pasanin ng mga node.

Isang magandang paghahalintulad: Dati, kapag nag-file ka ng leave request sa DingTalk (nagpapadala ng transaction), kailangang isa-isang i-check ng bawat boss (node) kung may natitira ka pang leave balance (lahat ay nagbe-verify), at kapag lahat ay nag-approve, saka lang matatapos ang proseso.

Pagkatapos ng ZK, unang iche-check ng system kung may natitira kang leave, tapos maglalabas ng proof (ZK) para sa lahat ng boss, at ang mga boss ay kailangang magtiwala at mabilis na mag-approve (lahat ay isang beses lang magbe-verify).

Pagkatapos ng ZK, mag-aapply ka pa rin ng leave (magpapadala ng transaction), makikita ng system na may natitira kang leave, at agad nitong sasabihin sa lahat ng boss na “may leave ang taong ito”, at lubos na nagtitiwala ang mga boss na hindi magkamali ang system (ZK), kaya mas mabilis silang mag-aapprove (lahat ay isang beses lang magbe-verify).

Ito ang dahilan kung bakit gustong gawing ZK ng Ethereum.

Mga Hamon sa Cryptography at Mga Halimbawa

Siyempre, ang engineering work ay napakalaki at ang cryptographic difficulty ay napakataas, kaya kailangang makipagtulungan ang Ethereum sa mga propesyonal na team.

Ang Brevis protocol na binanggit ng Ethereum Foundation researcher na si Justin ay isa sa mga nangungunang halimbawa sa larangang ito.

Nakatuon ang Brevis sa ZK-VM, at ang pinakabagong Pico Prism technology nito ay isa sa pinakamabilis na paraan ng paggawa ng ZK proof sa kasalukuyang mga kondisyon.

Ayon sa test data, sa kasalukuyang block size ng Ethereum na 45M GAS, gamit ang 64 na RTX 5090 GPU, kayang tapusin ng Brevis ang 99.6% ng block proof sa loob ng 12 segundo, kung saan 96.8% ng block ay kayang tapusin ang proof generation sa loob ng 10 segundo.

Para mapanatili ang decentralization, hinihiling ng Ethereum na ang gastos ng ZK proof device ay hindi lalampas sa 100,000 US dollars.

Bagaman mas mabilis gumawa ng proof ang mas high-end na GPU (tulad ng H200 o B200), tataas naman nang malaki ang entry barrier. Ang kasalukuyang disenyo ng Brevis ay sakto sa limitasyong ito.

Bakit mahalaga rin ang “10-second coverage”? Dahil ang MEV blocks ay karaniwang nabubuo sa loob ng 1–3 segundo, at ang 10 segundong proof time ay sakto para mapuno ang 12 segundong block interval.

Buod: Ang Lohika ng Landas ng ZK ng Ethereum

Kung gustong pabilisin ng Ethereum ang pagtaas ng L1 performance, kailangang itaas ang GAS limit;

Kung gustong ligtas na itaas ang GAS limit, kailangang itulak ang ZK;

At kung gustong magawa nang elegante ang ZK (proof generation sa loob ng 10 segundo, hardware cost na mas mababa sa 100,000 US dollars), kailangan ang pagtutulungan ng cryptography community at crypto ecosystem.

Ang ZK ay ang pinaka-komplikado ngunit pinaka-determinadong direksyon sa scaling roadmap ng Ethereum.

Hindi lang ito tungkol sa performance, kundi ito rin ang ultimate solution ng Ethereum sa paghahanap ng balanse sa pagitan ng seguridad at decentralization.