Ang roadmap ng Interop ay "pinabilis": Pagkatapos ng Fusaka upgrade, maaaring sumapit ang mahalagang hakbang para sa interoperability ng Ethereum

Chainfeeds Panimula:

Kung walang real-time na ZK, mahirap magkaroon ng tunay na magagamit na Interop UX.

Pinagmulan ng Artikulo:

May-akda ng Artikulo:

imToken Labs

Pananaw:

imToken Labs: Noong Disyembre 4, opisyal na na-activate sa mainnet ang Fusaka upgrade ng Ethereum, ngunit hindi ito kasing-ingay ng Dencun upgrade noon, at ang atensyon ng merkado ay mas nakatutok sa Blob scaling at PeerDAS, na pinupuri ang patuloy na pagbaba ng L2 data cost. Ngunit sa likod ng ingay na ito, may isang hindi kapansin-pansing proposal na EIP-7825, na nagtanggal ng pinakamalaking hadlang para sa pagpapatupad ng L1 zkEVM at real-time na proof sa Ethereum, at maaaring tahimik na naglalatag ng daan para sa huling yugto ng Interop. Sa Fusaka upgrade na ito, halos lahat ng atensyon ay nasa scaling: 8x na pagtaas ng Blob capacity, kasabay ng PeerDAS random sampling verification, na tuluyang ginawang kasaysayan ang cost narrative ng DA (data availability) track. Totoo, mas murang L2 ay maganda, ngunit para sa pangmatagalang ZK roadmap ng Ethereum, ang EIP-7825 ang tunay na game changer, dahil nagtakda ito ng Gas limit para sa bawat transaksyon ng Ethereum (mga 16.78 million Gas). Alam ng lahat, tumaas na ngayong taon ang Gas Limit ng Ethereum block sa 60 million, ngunit kahit patuloy na tumataas ang limit, sa teorya, kung may gustong magbayad ng napakataas na Gas Price, maaari pa rin siyang magpadala ng isang napakakomplikadong "Mega-Transaction" na direktang pupuno sa buong 60 million Gas capacity ng block, na magdudulot ng pagsisikip sa buong block. Bakit kailangang limitahan ang laki ng bawat transaksyon? Sa totoo lang, walang epekto ito sa karaniwang user na nagpapadala ng pera, ngunit para sa ZK Prover (proof generator), ito ay usapin ng buhay at kamatayan, at malapit na kaugnay sa paraan ng pagbuo ng proof ng ZK system. Halimbawa, bago ang EIP-7825, kung may "Mega-Transaction" na gumagamit ng 60 million Gas sa isang block, kailangang tapusin ng ZK Prover ang napakakomplikadong transaksyon na ito nang sunud-sunod, hindi maaaring hatiin o iproseso nang sabay-sabay, parang isang single-lane highway na may napakabagal na malaking trak sa unahan, at lahat ng sasakyan sa likod (ibang transaksyon) ay kailangang maghintay hanggang makadaan ito. Ito ay direktang nagtatakda ng "death sentence" para sa "real-time proof" — dahil ang oras ng pagbuo ng proof ay hindi na makokontrol, maaaring umabot ng ilang minuto o mas matagal pa. Ngunit pagkatapos ng EIP-7825, kahit lumaki pa sa hinaharap ang block capacity sa 100 million Gas, dahil bawat transaksyon ay sapilitang nililimitahan sa loob ng 16.78 million Gas, ang bawat block ay nahahati na sa mga predictable, may hangganan, at maaaring iprosesong sabay-sabay na "mga maliit na task unit", na nangangahulugang ang pagbuo ng proof sa Ethereum ay mula sa isang mahirap na "logic problem", naging isang purong "money problem": basta't may sapat na parallel computing power, maaari nating iproseso nang sabay-sabay ang mga hinating maliit na task na ito sa napakaikling panahon, kaya't makakabuo ng ZK proof para sa malalaking block. Gayunpaman, kahit pinadali ng EIP-7825 ang pisikal na daan para sa real-time proof (dahil sa parallelization), ito ay isang bahagi lamang ng kwento, ang isa pa ay kung paano gagamitin ng Ethereum mainnet ang kakayahang ito? Dito pumapasok ang pinaka-core na narrative ng Ethereum roadmap — L1 zkEVM. Sa matagal na panahon, ang zkEVM ay itinuturing na "Holy Grail" ng Ethereum scaling, hindi lang dahil sa kakayahan nitong lutasin ang performance bottleneck, kundi dahil muling binibigyang-kahulugan nito ang trust mechanism ng blockchain. Ang pangunahing ideya ay bigyan ang Ethereum mainnet ng kakayahang bumuo at mag-verify ng ZK proof. Sa madaling salita, sa hinaharap, bawat block execution ng Ethereum ay maaaring maglabas ng isang verifiable mathematical proof, kaya't ang ibang nodes (lalo na ang light nodes at L2) ay hindi na kailangang ulitin ang computation para makumpirma ang tamang resulta — kung maisusulat ang kakayahang bumuo ng ZK proof direkta sa protocol layer ng Ethereum (L1), bawat proposer na magbubuo ng block at ZK proof ay hindi na kailangang ulitin ng mga validator ang buong transaksyon, kailangan na lang nilang i-verify ang napakaliit na mathematical proof na ito.