Vitalik: Mas positibo ako ngayon tungkol sa native rollup kaysa dati

Ayon sa ulat ng Jinse Finance, nag-post si Vitalik Buterin sa X platform na mas pinapaboran niya ngayon ang native rollup kaysa dati. Isa sa mga pangunahing dahilan kung bakit siya tutol noon ay: kailangang pumili ng “zk mode” o “optimistic mode” ang precompile ng native rollup. Dahil hindi pa sapat ang maturity ng ZK-EVM sa zk mode, kung bibigyan natin ng dalawang pagpipilian ang L2: “gumamit ng proof na lubos na pinagkakatiwalaan ng Ethereum, ngunit kailangang maghintay ng 2–7 araw para sa withdrawal” o “agad na withdrawal, ngunit kailangan mong gawin ang proof mo mismo,” kadalasan pipiliin ng L2 ang una. Hindi ito maganda para sa composability ng Ethereum, at magreresulta ito sa mas maraming multisig bridges at iba pa.Ngunit ngayon, mukhang tumutugma na ang timeline ng Ethereum sa ganap na pagtanggap ng ZK sa L1 at ang aktwal na timeline ng pagdagdag ng native rollup precompile, kaya’t nalutas na ang problemang ito.Bukod dito, nakikita ko na mas dumarami ang mga proyekto na itinuturing ang synchronous composability bilang pangunahing value proposition ng paggawa ng L2. Nagsumite rin ako ng isang paraan: https://ethresear.ch/t/combining-preconfirmations-with-based-rollups-for-synchronous-composability/23863, para pagsamahin ang based rollups at L2 low-latency preconfirmation (preconf) upang makamit ang synchronous composability.Kaya pakiramdam ko ito ang tamang direksyon ng pag-unlad. Sa tingin ko hindi tayo dapat maging tamad, kailangan nating maglaan ng mas maraming pagsisikap upang hanapin ang pinakamahusay na paraan para maisakatuparan ang precompile na ito. Isa sa mga pangunahing katangian na gusto ko ay: kung gumawa ka ng isang “EVM + ilang bagong feature” na rollup, dapat mong magamit ang native rollup precompile para sa EVM, habang ginagamit ang sarili mong prover para sa mga bagong feature na idinagdag mo. Maaaring isaalang-alang ang paggamit ng lookup table upang standardize na pagdugtungin ang dalawa.