Ang Ethereum Foundation ay nagtatakda ng deadline na 2029 para sa mga upgrade na resistant sa quantum

Awtor: KarenZ, Foresight News

Hindi pa nabuksan ng quantum computer ang pinto ng blockchain, ngunit ang Ethereum Foundation ay nagsalba na ng petsa sa kanilang kalendaryo: Disyembre 2029.

Ito ay ang teknikal na deadline na itinakda ng team ng Ethereum Foundation: maghanda para sa posibleng maagang paglitaw ng banta ng quantum, at makumpleto ang pagbabago ng Ethereum Layer 1 laban sa quantum bago maging totoo ang panganib.

Ang Hegotá na nasa pagpaplano, bagaman hindi direktang papalitan ang Ethereum bilang isang ganap na quantum-resistant blockchain, ay magdedesisyon kung makakapagpatuloy ang susunod mga plano ayon sa takdang oras.

Ang «Q-day» ay karaniwang ginagamit upang tukuyin ang isang hipotetikal na punto sa panahon: ang pagkakaroon ng isang quantum computer na may kakayahang mag-atake, na nagdudulot ng malaking banta sa mga umiiral na sistema ng public-key cryptography.

Kailan ito darating, walang makakapag-predict nang tumpak. Ang Ethereum Foundation ay kilalang kinikilala na ang karamihan sa mga kredibleng pagtataya ay nagpapakita na ang Q-day ay mas huli kaysa sa 2030, o maaaring mas huli pa, at may posibilidad na ito ay hindi magmumula nang matagal.

Gumagamit ang Ethereum Foundation Protocol Team ng isang konservatibong inhenyeryong aksiyoma: Dapat maging handa ang Ethereum Layer 1 sa pagdating ng Q-day, na maaaring mangyari sa pinakamabilis na 2030.

Para sa layuning ito, ang tim ng protokolo ay nagtakda ng layunin: upang makuha ang buong quantum resistance sa tatlong bahagi ng Ethereum Layer 1—execution, consensus, at data—bago ang Disyembre 2029.

Hindi ito isang patuloy na layunin na hindi magbabago. Planohin ng tim ng protokolo na muling suriin ang pag-unlad ng quantum computing noong Enero 2027, kasama ang mga opinyon ng mga eksperto mula sa labas. Bago pa man, ang deadline ng 2029 ay ituturing na isang layuning hindi dapat madaling ipagkompromiso.

Kailangan ng maraming taon ng paghahanda ang quantum-resistant upgrade dahil hindi nagagamit ng Ethereum ang isang uri lamang ng kriptograpiya, at hindi ito nagtatapos sa pagbabago ng isang algorithm ng pag-sign. Ang paraan kung paano ipinapatotohanan ng mga user ang pagpapahintulot sa transaksyon, kung paano kasali ang mga validator sa consensus, at kung paano pinapatotohanan ang data, ay lahat ay may kinalaman sa iba’t ibang istruktura ng kriptograpiya. Ang anumang pagbabago ay kailangang dumaraan sa disenyo ng pamantayan, implementasyon ng client, pagsusuri sa kaligtasan, pagsubok sa development network, at koordinasyon sa mainnet—hindi ito maaaring hintayin hanggang sa lumabas ang banta.

Batay sa kasalukuyang ipinahayag na baseline roadmap ng Ethereum Foundation Protocol Team, inaasahang ilunsad ang Glamsterdam network upgrade sa mainnet noong Disyembre 2026, habang ang buong quantum-resistant capability ay iskedyul sa ikalimang hard fork pagkatapos ng Glamsterdam, na tinatawag na L*, na may layunin na Disyembre 2029. Mula sa Glamsterdam hanggang sa L*, mayroon lang tatlong taon; kung kailangang tapusin nang sunud-sunod ang Hegotá, I*, J*, K*, at L*, ang average na panahon sa pagitan ng bawat upgrade ay halos 7.2 na buwan.

Isang napakalaking oras na iskedyul. Sa kasalukuyan, wala pang tiyak na petsa ng paglunsad sa pangunahing network para sa Hegotá, I*, J*, at K* na inilabas ng Ethereum Foundation. Matiyak na inaasahan ng mga koponan ng client na magsisimula ang pagpapatupad ng Hegotá noong huling bahagi ng ikaapat na kuartal ng 2026, habang ang pag-aaral, spesipikasyon, at pagsubok ng mga susunod na bersyon ay dapat gawing paralelo.

Ayon sa kasalukuyang ruta, ang mga pangunahing pagkakataon sa bawat yugto ay sumusunod:

• Hegotá: Nasa simula ng ruta na ito. Malinaw ang pagsasaklaw nito ng opisyal: Ang Hegotá ay hindi mismo ang quantum-resistant upgrade, ngunit ito ang magdedesisyon kung makakapagpatuloy ba ang susunod na quantum-resistant upgrade ayon sa takdang oras.
• I*: I-deploy ang quantum-resistant public key registry upang magtatag ng protokol para sa pag-rehistro ng account at paggamit ng quantum-resistant public key; samantala, ang pag-decouple ng consensus ay ang pinakamalikhaing pangunahing direksyon sa bersyon na ito, at ang malaking disenyo at paglipat ng estado ay inaasahang magsisimula mula sa I*.
• J*: Itatayo ang "Minimum Viable Post-Quantum" na layer, o MV-PQ. Ang mga pangunahing sangkap nito ay ang post-quantum heartbeat mechanism sa consensus layer, ang post-quantum leanDA sampling sa data layer, at ang post-quantum leanSPHINCS transaction sa execution layer.
• K*: Ayon sa kasalukuyang batayan, ipinapakilala ang proof-of-enforcement. Sa panahong iyon, ang direksyon ng mga validator ay ang pag-verify ng mga kompakto na proof-of-execution, hindi ang pag-reexecute ng bawat buong block ng bawat validator.
• L*: Ayon sa kasalukuyang baseline, idagdag ang mga mensahe ng post-quantum attestations upang makamit ang buong quantum-resistant consensus, at abotin ang buong quantum-resistant target sa execution layer, consensus layer, at data layer noong Disyembre 2029.

Gayunpaman, ang pagkakasunod-sunod ng mga gawain para sa K* at L* ay hindi pa pinagpasyahan. Ang koponan ng protokolo ay nag-e-evaluate ng isang pagbabago: ang pagpapalikod ng mensahe ng quantum-resistant proof mula sa L* patungo sa K*, upang mas mabilis na maisakatuparan ang buong quantum-resistant capability; samantala, ang pagpapalipat ng enforcement proof mula sa K* patungo sa L*. Kung gagamitin ang solusyong ito, magkakaroon ng pagbabago ang mga tiyak na tungkulin at ritmo ng upgrade para sa K* at L*. Kaya, ang pinakatumpak na pahayag sa kasalukuyan ay: ang Disyembre 2026 ay ang kasalukuyang target na mainnet para sa Glamsterdam, at ang Disyembre 2029 ay ang target sa baseline roadmap para sa L* at buong quantum-resistant capability; ang panloob na pagkakasunod-sunod ng K at L* ay maaaring paayusin.

Ang mga siyentipiko, developer ng kliyente, mga tagapagsuri ng kaligtasan, at ang koponan ng pagsubok ay kailangang tapusin ang Hegotá at maghanda nang maaga ng mga spesipikasyon at prototipo para sa I*, J*, K*, at L*. Kung masyadong maraming interaktibong tampok ang isasama sa Hegotá, hindi lamang ito makakapagdulot ng pagkakalat sa sariling paglunsad nito kundi magkakaroon din ito ng epekto sa koponan na kailangan para sa susunod na quantum-resistant na mga gawain.

Kaya ang tim ng protokolo ng Ethereum Foundation ay nagkategorya sa 62 na kandidatong propuesta bilang S (2), A (15), B (8), C (7), DFI (28), at TBD (2). Ang S ay nangangahulugan na kailangang ipagawa; ang A ay mataas na prioridad at inaasahang ipagawa; ang B ay kailangan pang matugunan ang mga kondisyon tulad ng spesipikasyon, prototipo, o pagkakatotoo ng tagapagmaneho; ang C ay pansamantalang nasa ibaba ng pagsali; ang DFI ay nangangahulugan na hindi inirerekomenda para sa pag-upgrade na ito; at ang TBD ay nangangahulugan na nasa paghihintay.

Sa pagkakasuri ng Hegotá na inilabas ng protocol team, ang dalawang EIP lamang ang nakapasok sa antas S: ang EIP-7805 FOCIL sa consensus layer at ang EIP-8141 Frame transaction sa execution layer.

Nag-aangkop sila ng dalawang mahahalagang isyu sa buhay ng transaksyon: kung maaaring masama ang isang kwalipikadong transaksyon sa isang bloke, at paano maaaring patunayan at maisagawa ang isang transaksyon ng isang akawnt.

Ang FOCIL (EIP-7805) ay ang pambuod na "Fork-choice enforced Inclusion Lists". Ang layunin nito ay mapabuti ang pagkakaroon ng pagkakataon sa pagkakasunod-sunod ng mga transaksyon sa Ethereum.

Sa kasalukuyan, ang mga propesyonal na block builders ang dominanteng nagpapagawa ng mga block. Ang paghahati-hati ng mga tungkulin na ito ay nakakatulong sa pagpapabuti ng efisiyensiya sa pagbuo ng block, ngunit kung ang produksyon ng block ay matagal nang nakikonsentrado sa ilang mga builder, maaari rin silang makakuha ng malakas na kakayahang piliin ang mga transaksyon. Kaya, idinagdag ng FOCIL isang karagdagang antas ng pagtanggap na limitasyon mula sa mga validator sa panlabas na normal na proseso ng block building.

Ayon sa disenyo ng FOCIL, bawat Slot ay pipili ng isang grupo ng mga validator upang mabuo ang “Committee ng Listahan ng Pagkakasama” (IL committee). Ang mga miyembro ng komite ay gumagawa at nagpapalabas ng kanilang sariling listahan ng pagkakasama batay sa mga transaksyon na nasa paghihintay na kanilang nakikita. Ang builder ng block sa susunod na Slot ay kumukuha ng mga listahang ito at idinadagdag ang mga transaksyon na sumusunod sa mga kondisyon ng pagpapatupad habang binubuo ang block. Ang mga validator na responsable sa pagpapatotoo sa bagong block ay nagtatago rin ng kanilang natanggap na listahan ng pagkakasama nang maayos at sinusuri kung ang block ay sumusunod sa mga kinakailangang ito.

Kung ang isang区块 ay naglalabas ng listahan ng mga transaksyon na itinatag ng validator nang walang wastong dahilan, hindi magbibigay ng boto ang proofers para sa区块 na iyon. Kahit na ang ganitong区块 ay patuloy na epektibo sa antas ng pagpapatupad, hindi ito makakakuha ng sapat na pagsang-ayon upang makapasok sa pormal na chain. Ito ang kahulugan ng FOCIL: hindi ito nagpapahintulot sa mga miyembro ng komite na direktang baguhin ang区块, kundi nagpapahigpit sa mga pagpipilian ng mga builder ng区块 sa pamamagitan ng pagboto o pagkakawala ng pagboto ng mga validator.

Ang kasunod na EIP-8369 ay karagdagang naglalarawan kung anong mga transaksyon ang angkop para sa pagsasakop ng FOCIL. Ang dahilan ng pagkakalimot sa karaniwang transaksyon ay madaling i-verify; ang mga Frames transaction ay nagpapahintulot sa programmable na pag-verify, ngunit mas mataas ang gastos, kaya kailangan ng karagdagang pagtukoy sa sakop ng estado na maaaring basahin at sa budget para sa pag-verify.

Sa madaling salita, hindi pinapawi ng FOCIL ang paggawa ng区块 builder ng mga validator, kundi idinadagdag nito sa mga builder ang isang patakaran sa consensus layer: maaari pa ring ayusin mo ang karamihan sa mga transaksyon sa区块, ngunit hindi mo maaaring patuloy na pansinin ang mga kwalipikadong transaksyon na listahan ng komite nang walang makatotohanang dahilan.

Ang Frame Transactions (EIP-8141) ay tumutukoy sa mga problema sa account layer. Ito ay naglalayong gawing mas programmable ang transaction validation, transaction execution, at gas payment sa protocol layer upang magbigay ng pundasyon para sa native account abstraction. Si Vitalik ay isa sa mga co-author ng EIP-8141.

Sa kasalukuyan, ang karamihan sa karaniwang Ethereum accounts ay nakadepende sa fixed na uri ng private key signature. Gusto ng Frames na gawing mas flexible ang pag-verify ng account, tulad ng paggamit ng bagong signature scheme, pagsasama ng maraming authorization conditions, o pagpapahintulot sa ibang account na magbayad ng transaction fees. Maaari rin nito suportahan ang signature aggregation at payagan ang pagpapakilala ng bagong signature scheme sa hinaharap nang hindi kailangang magkaroon ng hiwalay na hard fork para sa bawat isa.

Ngunit ang Frames ay hindi sariling kompletong solusyon sa quantum-resistant signing, at hindi ito magtatanggal agad ng mga umiiral na key pagkatapos ng pag-launch ng Hegotá. Ito ay nag-aalok ng "cryptographic agility": kung sakaling kailangan magpalit ng signing scheme sa hinaharap, ang mga account ay makakamove sa pamamagitan ng programmable verification, at hindi magiging permanenteng nakakulong sa isang uri ng key system.

Kailangan pa ng Frames dalawang A-class proposal bilang pangunahing kasunod. Ang EIP-8250 Keyed Nonces ay nagpapahintulot sa parehong sender na gamitin ang magkakaibang nonce channels, kaya hindi na kailangang maghintay ang iba’t ibang transaksyon dahil sa isang mahigpit na pagkakasunod-sunod; ang EIP-8272 naman ay nagpapahintulot sa transaksyon na gamitin ang kamakailang on-chain state na maaaring i-verify ng validator, upang makakuha rin ng pagkakataon mula sa FOCIL ang mga privadong transaksyon.

Kaya ang FOCIL at Frames ay hindi dalawang hiwalay na tampok. Ang unang ito ay nagbabago kung anong mga kwalipikadong transaksyon ang dapat isama sa bloke, habang ang pangalawa ay nagbabago sa sariling estruktura ng pag-verify ng transaksyon. Ang kakayahan nilang magtrabaho nang ligtas nang magkasama ay isa sa pinakamahalagang pagsubok ni Hegotá.

Ang S-class proposal ay nagtataglay ng pangunahing direksyon ng Hegotá, ngunit ang maraming A-class proposals ay may epekto rin sa pagkakasiguro ng account sa hinaharap ng Ethereum, migrasyon laban sa quantum, proof-of-execution, at pagtantiya ng mga yunit.

Una sa EIP-8365. Ito ay plano para simulan ang proseso ng pag-alis ng bahagi ng BLS withdrawal credentials, dahil sa mga credential na ito ay patuloy na nakasalalay sa mga teknolohiyang kriptograpiko na maaaring mawalan ng kaligtasan sa harap ng sapat na malakas na quantum attack. Naniniwala ang team ng protokolo na maaaring simulan ang paglipat na ito nang maaga, nang hindi naghihintay sa pagkakatuklas ng kompletong quantum-resistant consensus design.

Sa aspeto ng seguridad ng akunty, ang EIP-7906, EIP-8298, at EIP-8151 ay itinuturing na ekstensyon na kombinasyon ng Frames.

Ang EIP-7906 ay naglalayong magdagdag ng mekanismo ng Transaction Assertions, na nagpapahintulot sa mga transaksyon na suriin kung ang mga nakatakdang resulta ay nangyari bago ito isumite. Layunin ng mekanismo na bawasan ang mga pagkawala dulot ng masamang mga kontrato na humuhuli ng mga asset ng wallet at ilang mga gawain ng MEV. Gayunpaman, ang eksaktong saklaw ng pagbabasa ay kasalukuyang pinag-aaralan at pinapaliit, kaya hindi maaaring isulat ang kasalukuyang disenyo bilang nakapirming pinal na spesipikasyon.

Ang EIP-8298 ay nagpapahintulot sa paggamit muli ng existing contract code ng account, na nagpapalawak sa mga in-delegated account tungo sa mga smart contract account na may buong code. Ang EIP-8151 naman ay naglalayong limitahan ang paggamit ng tradisyonal na ecRecover authentication sa mga address na may existing contract code.

Kapag pinagsama ang dalawang propostal na ito, maaaring matigil nang totoo ang paggamit ng lumang secp256k1 key bilang pinakamataas na pagsasakop, at magbuo ng buong landas para sa paglalabas mula sa lumang sistema ng key.

Ang EIP-8025 (Optional Execution Proofs) ay may kaugnayan sa hinaharap na ruta ng zkEVM. Ito ay plano na isama ang mga pagbabago na kailangan para sa optional execution proofs sa unified execution specification, upang mabawasan ang mga problema sa pangmatagalang pagpapanatili ng mga magkakaibang bersyon ng iba’t ibang proyekto ng zkVM.

Ang EIP-8279 (Byte Layer ng Block Access List) at EIP-8131 (Unified Transaction Content Layer) ay isang set ng mga propuesta para sa seguridad. Ang parehong ito ay nagtataguyod ng mga minimum na pamantayan para sa block access list at transaction content, na layunin ay limitahan ang mga attacker na gumagamit ng mababang presyo na content upang magdulot ng ekstremong presyon sa mga yunit. Sinisikap nilang lubos na harapin ang pinakamasamang kaso ng gastos sa pagproseso ng block, hindi direktang ipahayag ang pagpapalawak ng network capacity. Ang paggamit ng seguridad na natitirang puwang para palawakin ang capacity ay kailangang pagdesisyunan nang hiwalay sa hinaharap.

Ang EIP-3298 ay plano na tanggalin nang buo ang mekanismo ng gas refund upang mabawasan ang mga espesyal na kaso sa pagmamarka, pagpapatupad, at pagsubok; habang ang EIP-5920 (PAY Opcode) ay nagpapahintulot sa mga kontrata na i-transfer ang ETH nang hindi ipinapatakbo ang code ng tagatanggap, upang malinaw na hiwalayin ang “pagpapadala ng halaga” at “pagtawag sa kontrata”.

Sambil naka-attend ang ilang napapansing propuesta, nananatili pa sila sa B-class.

Halimbawa, ang EIP-8198 (Quick Slots) ay naghahangad na maikliin ang oras ng Slot, ngunit hinihingi ng team ng protokol na muna itong matapos ang mga sumusunod: spesipikasyon, kompletong prototype, pagtataya ng mga epekto sa ibaba, at patunay na hindi ito magdudulot ng pagkakaantala sa susunod na disenyo ng pagkakabawas ng consensus. Ang dahilan ay ang oras ng Slot ay hindi lamang nakakaapekto sa bilis ng paggawa ng block, kundi pati na rin sa pagpapadala ng network, paghuhusga ng consensus, at mga aksiyon ng aplikasyon batay sa oras.

Dagdag pa, ang EIP-8368 at EIP-8372 ay nakalista bilang “TBD” (para sa pagtukoy). Ang dalawang proposta ay tumatalakay sa gas limit at pagtantiya ng estado ng yunit, at pinasiyahan ng tim ng protokol na hintayin ang mga data sa mainnet pagkatapos ng paglulunsad ng Glamsterdam noong Disyembre 2026 bago matukoy kung kailangan ng pagpapalit.

Ang bilang ng EIP na kinabibilangan ng Hegotá ay hindi ang tanging pamantayan para masukat kung matagumpay ang pag-upgrade na ito.

Mas mahalaga pa, kaya ba nito ipagbigay ang FOCIL, Frames, at kanilang pangunahing mga kasama nang hindi pinapawi ang kaligtasan at kalidad ng pagsubok, habang pinapaiwan ang sapat na mga yunit para sa pag-aaral ng pampublikong key registration at decoupled consensus para sa I*, minimum viable quantum resistance para sa J*, at execution proofs at full quantum-resistant consensus para sa K* at L*.

Batay sa kasalukuyang layunin, ang Glamsterdam ay magpapasimula ng maikling siklo ng pagpapabuti noong Disyembre 2026, habang ang L* sa baseline roadmap ay magkakaroon ng katapusan noong Disyembre 2029. Ang bawat pagpapabuti sa gitna ay hindi dapat mag-focus lamang sa pagkumpleto ng sariling mga tampok, kundi kailangan ding siguraduhin na ang susunod na yugto ay maaari pa ring magpatuloy.

Hindi makakapagbigay ng tiyak na sagot kung ang banta ng quantum ay magiging totoo bago ang 2030. Ngunit ang kasalukuyang pagpili ng Ethereum ay malinaw: unahin ang pagtakda ng deadline para sa panganib, at hayaang patunayan ng bawat proposta ang kanilang kakayahang maging handa para sa mainnet sa pamamagitan ng mga spesipikasyon, prototipo, at pagsubok.

Mga sanggunian sa artikulo:

https://blog.ethereum.org/2026/09/07/protocol-hegota-eips

https://blog.ethereum.org/2026/09/07/protocol-priorities

https://x.com/VitalikButerin/status/2073459000398463446