Vitalik Buterin flytter Ethereum-skaleringens fokus væk fra Layer 2 (L2) og tilbage til selve protokollens kerne.
Den russisk-canadiske innovatør mener, at Ethereums største langsigtede begrænsninger ikke er rollups eller blob-kapacitet, men dybere arkitektoniske flaskehalse i netværkets state tree og virtuelle maskine.
Vitalik Buterin foreslår markant ethereum-opgradering med fokus på state tree og flaskehalse i den virtuelle maskine
Ifølge Buterin står to elementer – netværkets state tree og virtuelle maskine – for mere end 80 % af bevis-omkostningerne. Det, udtaler han, er et kritisk problem, efterhånden som zero-knowledge (ZK) teknologi bliver central i Ethereums køreplan.
“I dag vil jeg fokusere på to store ting: ændringer i state tree samt VM,” skrev Buterin og tilføjede, at begge er “de store flaskehalse, vi skal tage hånd om, hvis vi vil have effektiv bevisgenerering.”
En gennemgang af et binært træ
Kernen i forslaget er EIP-7864, som skal udskifte Ethereums nuværende hexary Merkle Patricia-træ med et binært træ-design.
Ændringen lyder måske lille, men konsekvenserne er betydelige. Binære træer vil give Merkle-beviser, der er cirka fire gange kortere end den nuværende struktur, hvilket markant mindsker behovet for verifikationsbåndbredde.
Det gør letvægtsklienter og privatlivsfokuserede applikationer billigere og lettere at anvende.
Den nye struktur vil også samle storage slots i “sider” (pages), så applikationer, der indlæser relaterede data, kan gøre det mere effektivt.
Mange decentraliserede applikationer (dApps) tilgår ofte tilstødende storage slots. Det betyder, at opgraderingen kan spare over 10.000 gas pr. transaktion i visse tilfælde.
Buterin foreslog også at kombinere træændringen med mere effektive hash-funktioner, hvilket kan give yderligere stigning i bevisgenereringshastigheden.
Endnu vigtigere vil det nye design gøre Ethereums baselag mere “beviservenligt” (prover-friendly), så ZK-applikationer kan integrere sig direkte med Ethereums state i stedet for at bygge parallelle systemer.
Set i et større perspektiv søger forslaget om binært træ at samle ti års erfaringer om state management i en mere enkel og fremtidssikret struktur.
En fremtid uden for EVM?
Buterins langsigtede vision for Ethereums eksekveringsmotor er endnu mere ambitiøs. Han luftede idéen om på sigt at gå væk fra Ethereum Virtual Machine (EVM) og over mod en arkitektur baseret på RISC-V.
RISC-V er et ofte anvendt åbent instruktionssæt, der kan give større effektivitet og enkelhed.
Buterin mente, at Ethereums stigende brug af særligt designede precompiles afspejler en dybere utilfredshed med selve EVM’en.
Hvis Ethereums vigtigste løfte er alsidig programmerbarhed, foreslog han, bør VM’en understøtte denne vision fuldt ud uden unødvendige krumspring. En RISC-V-baseret VM kan:
- Mindske kompleksiteten
- Øge den rå udførelseseffektivitet, og
- Bedre matche moderne zero-knowledge systemer, hvor mange allerede anvender RISC-V internt.
På kort sigt foreslog Buterin en “vektor-matematik precompile”, beskrevet som en “GPU til EVM’en”. Det kan accelerere kryptografiske operationer markant.
På længere sigt beskrev han en gradvis overgang, hvor RISC-V først anvendes til precompiles, derefter understøtter brugerdeployede kontrakter, og til sidst integreres med EVM’en som kompatibilitetslag.
Debat om kompleksitet
Men ikke alle er overbeviste om, at Ethereum har brug for flere grundlæggende ændringer. Analytikeren DBCrypto kritiserede det, han kaldte stigende abstraktion i Ethereums køreplan, herunder de nye rammeværk, der skal løse rollup-fragmentering.
Hvert ekstra lag, pointerede han, øger kompleksiteten, tilføjer fondsantagelser og skaber flere potentielle angrebsflader.
Spændingen afspejler en bredere debat om, hvorvidt Ethereum skal fortsætte med at lægge lag på sit eksisterende design eller arbejde på en mere fundamental omlægning af grundstrukturen.
Men ifølge Vitalik Buterin skal Ethereums arkitektur udvikle sig og tilpasse sig, i takt med at zero-knowledge proofs bevæger sig fra niche til nødvendighed.
Næste fase af skalering, antyder han, sker måske ikke på Layer 2, men dybt i Ethereums kerne.
