Ethereum komanda veiks plašu kriptogrāfijas atjauninājumu pret kvantu riskiem

Ethereum izstrādātāji ir publiskojuši ceļa karti, kas paredz 2026. gadā sākt pakāpenisku pāreju uz kvantu noturīgāku kriptogrāfiju. Mērķis ir mazināt riskus, ko nākotnē varētu radīt kvantu datori.
Kur Ethereum šobrīd ir ievainojams
Ceļa karte izceļ četrus protokola “vājākos posmus” kvantu draudu kontekstā: konsensa līmeņa validatoru parakstus (BLS), datu pieejamības slāni, kas balstās uz KZG, lietotāju kontu (EOA) ECDSA parakstus un daļu ZK pierādījumu sistēmu, kas arī izmanto kvantu ziņā problemātiskus pieņēmumus.
Plāns paredz nevis vienu atjauninājumu, bet pakāpenisku, lai samazinātu pārejas riskus un vienlaikus saglabātu tīkla lietojamību.
Konsenss un datu pieejamība: no BLS/KZG uz hash+STARK
Konsensa pusē esošās BLS parakstu shēmas paredzēts aizstāt ar hash balstītu kriptogrāfiju (piemēram, Winternitz tipa pieeju) un izmantot STARK līmeņa agregāciju, lai tiktu galā ar parakstu izmēru un verifikācijas izmaksām.
Datu pieejamības slānī (kur šobrīd plaši tiek izmantots KZG) apsvērta migrācija uz STARK balstītiem risinājumiem, taču tas nozīmē apjomīgu inženiertehnisku darbu. STARK pierādījumi ir lielāki, un jārisina arī datu paraugošanas (DAS) un dzēšanas kodu verifikācijas praktiskie aspekti.
Lietotāju maki un ZK pierādījumi: EIP-8141 un “agregācija protokola līmenī”
Lietotāju pusē svarīgs virziens ir “native” kontu abstrakcija ar jaunu transakciju tipu, EIP-8141, kas ļautu parakstiem izmantot ne tikai ECDSA, bet jebkuru shēmu, tostarp kvantu noturīgākas alternatīvas. Tas ir būtiski, jo post-quantum paraksti parasti ir apjomīgāki un dārgāki verifikācijā.
ZK pierādījumu sadaļā galvenā problēma ir izmaksas: kvantu noturīgi STARK tipa pierādījumi varētu būt nesamērīgi dārgi, ja tos verifikētu “pa vienam” ķēdē. Tāpēc tiek virzīta ideja par protokola līmeņa rekursīvu agregāciju, daudzus pierādījumus apvienot vienā “vieglākā”, lai samazinātu slodzi un komisijas.
Now, the quantum resistance roadmap.
Today, four things in Ethereum are quantum-vulnerable:
* consensus-layer BLS signatures
* data availability (KZG commitments+proofs)
* EOA signatures (ECDSA)
* Application-layer ZK proofs (KZG or groth16)We can tackle these step by step:…
— vitalik.eth (@VitalikButerin) February 26, 2026