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

May-akda: Ebunker

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

Sa buong network, ang V God at ang Ethereum Foundation ang may pinakamaraming taya sa ZK. Ang ZK ay parang bunsong anak ng Ethereum, na pinagbuhusan ng pinakamaraming atensyon, ngunit ang hinaharap ay pinaka-hindi tiyak.

Ilang araw na ang nakalipas, inilabas ng Ethereum Foundation ang 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 implementasyon 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 ng Node ay Nagbe-verify at ang GAS Limit

Nabanggit na natin 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 ay, 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 mode, ibig sabihin lahat ng node ay kailangang i-verify ang bawat block nang buo. 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 ordering, 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 "Isang Beses na Pag-verify ng Lahat"

Kung magiging ZK-based ang buong Ethereum L1, magbabago ang verification mode mula "lahat ay nagbe-verify" tungo sa "isang beses na pag-verify ng lahat". Sa mode na ito, kapag nabuo na ang isang block, unang gagawa ng ZK proof.

Ang katangian ng ZK ay mabagal ang paggawa ng proof, ngunit napakabilis ng pag-verify. Kaya, kailangan lang ng node na i-verify 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 halimbawa: Dati, kapag nag-file ka ng leave sa DingTalk (nagpapadala ng transaksyon), kailangang isa-isang i-check ng bawat boss (node) kung may natitira ka pang leave (lahat ay nagbe-verify), at kapag naaprubahan ng lahat, saka lang matatapos ang proseso.

Pagkatapos ng ZK, unang tinitiyak ng system na may leave ka, tapos sabay-sabay magbibigay ng proof sa lahat ng boss (ZK), at kailangan lang nilang magtiwala at mabilis na mag-apruba (isang beses na pag-verify ng lahat).

Pagkatapos ng ZK, mag-a-apply ka pa rin ng leave (nagpapadala ng transaksyon), makikita ng system na may natitirang leave ka, at agad sasabihin sa lahat ng boss na "may leave ang taong ito", at lubos na nagtitiwala ang mga boss na hindi magkakamali ang system (ZK), kaya mas mabilis ang pag-apruba (isang beses na pag-verify ng lahat).

Ito ang dahilan kung bakit gustong maging ZK-based ang Ethereum.

Mga Hamon sa Cryptography at Mga Halimbawa

Siyempre, ang engineering na kailangan para dito ay napakalaki, at napakataas ng antas ng cryptography, 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 para gumawa ng ZK proof sa kasalukuyang mga kondisyon.

Ayon sa test data, sa kasalukuyang block size ng Ethereum na 45 M 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 natatapos ang proof sa loob ng 10 segundo.

Upang mapanatili ang decentralization, hinihiling ng Ethereum na ang gastos sa ZK proof device ay hindi lalampas sa $100,000.

Bagama't mas mabilis gumawa ng proof ang mas high-end na GPU (tulad ng H 200 o B 200), tataas naman nang malaki ang entry barrier. Sakto lang ang kasalukuyang disenyo ng Brevis sa limitasyong ito.

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

Buod: Ang Lohika ng Landas ng ZK-based na Ethereum

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

Kung gustong ligtas na itaas ang GAS limit, kailangang isulong ang ZK-based na sistema;

At kung gustong maayos na maisakatuparan ang ZK-based na sistema (proof sa loob ng 10 segundo, hardware cost na mas mababa sa $100,000), kailangan ang pagtutulungan ng cryptography community at ng crypto ecosystem.

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

Hindi lang ito tungkol sa performance, kundi ito rin ang ultimate na solusyon ng Ethereum para balansehin ang seguridad at decentralization.