Vitalik Buterin geeft zijn grootste ontwerpfout sinds 2017 toe – dus loopt jouw Ethereum risico?

Vitalik Buterin zei dat hij het niet meer eens is met zijn tweet uit 2017 waarin hij de noodzaak voor gebruikers om Ethereum end-to-end persoonlijk te verifiëren bagatelliseerde.

Deze week betoogde hij dat het netwerk zelf-gehoste verificatie zou moeten behandelen als een niet-onderhandelbare nooduitgang naarmate de architectuur lichter en modulairder wordt.

Buterins oorspronkelijke standpunt kwam voort uit een ontwerpsdebat over de vraag of een blockchain zich zou moeten committeren aan state on chain of state zou moeten behandelen als "geïmpliceerd", alleen reconstrueerbaar door geordende transacties opnieuw af te spelen.

Ethereums aanpak, het plaatsen van een state root in elke blockheader en het ondersteunen van Merkle-stijl bewijzen, stelt een gebruiker in staat om een specifiek saldo, contractcode of opslagwaarde te bewijzen zonder de volledige geschiedenis opnieuw uit te voeren, zolang de gebruiker de consensusvaliditeit van de chain accepteert onder een eerlijke-meerderheidsaanname.

In zijn nieuwe post herformuleerde Buterin die afweging als incompleet in de praktijk omdat het gebruikers nog steeds kan dwingen te kiezen tussen het opnieuw afspelen van de volledige chain of het vertrouwen op een tussenpersoon zoals een RPC-operator, een archief data-host of een bewijsservice.

Vitaliks ommekeer over persoonlijke verificatie van blockchaingeschiedenis

Hij verankerde de verandering in twee verschuivingen: haalbaarheid en kwetsbaarheid.

Over haalbaarheid schreef Buterin dat zero-knowledge bewijzen nu een pad bieden om correctheid te controleren zonder "letterlijk elke transactie opnieuw uit te voeren."

In 2017 betoogde hij dat dit Ethereum zou hebben gedwongen naar een lagere capaciteit om verificatie binnen bereik te houden.

De verschuiving is belangrijk omdat Ethereums publieke roadmap ZK steeds meer behandelt als een verifieerbaarheidsprimitief, waarbij ethereum.org zero-knowledge bewijzen omschrijft als een manier om beveiligingseigenschappen te behouden terwijl wordt verminderd wat een verificateur moet berekenen.

Werk aan "ZK-light-client" richtingen wijst ook naar een model waarbij een apparaat kan synchroniseren met behulp van compacte bewijzen in plaats van te vertrouwen op een altijd-online gateway.

Over kwetsbaarheid somde Buterin faalmodussen op die buiten duidelijke dreigingsmodellen vallen: verslechterde p2p-netwerken, langlopende diensten die worden afgesloten, validatorconcentratie die de praktische betekenis van "eerlijke meerderheid" verandert, en informele governance-druk die "bel de devs" tot de laatste redmiddel maakt.

Hij noemde censuurdruk rond Tornado Cash als voorbeeld van hoe tussenpersonen de toegang kunnen beperken, en betoogde dat de laatste redmiddeloptie van een gebruiker zou moeten zijn om "de chain direct te gebruiken."

Die framing sluit aan bij een bredere discussie over het verharden van Ethereums basislaag en het beperken van veranderingen, te midden van een drang naar protocol "versteening."

In Buterins verhaal is de "berghut" geen standaard levensstijl.

Het is een geloofwaardige terugvaloptie die prikkels verandert, omdat de wetenschap dat gebruikers kunnen uitstappen de invloed van elke afzonderlijke servicelaag vermindert.

Dat argument komt neer terwijl Ethereum vermindert wat gewone nodes naar verwachting moeten opslaan, terwijl het verificatieverhaal van het netwerk moet bijblijven.

Ethereum client gebruik en geschiedenis

Execution clients gaan over op gedeeltelijk verlopen van geschiedenis, en de Ethereum Foundation zei dat gebruikers het schijfgebruik met ongeveer 300–500 GB kunnen verminderen door pre-Merge blockgegevens te verwijderen, waardoor een node binnen bereik komt op een schijf van 2 TB.

Tegelijkertijd weerspiegelen light clients al een geformaliseerd vertrouwensmodel geoptimaliseerd voor apparaten met weinig middelen, vertrouwend op een synchronisatiecomité van 512 validators dat ongeveer elke 1,1 dag wordt geselecteerd.

Die parameters maken light-client verificatie op schaal werkbaar.

Ze concentreren echter ook de gebruikerservaring rond de beschikbaarheid van correcte gegevens en goed presterende relays wanneer de omstandigheden verslechteren.

Ethereums langetermijn "staatloosheid" werk heeft tot doel de noodzaak voor nodes om grote state vast te houden te verminderen terwijl blockvalidatie intact blijft.

Ethereum.org waarschuwt dat "staatloosheid" een verkeerde benaming is, waarbij zwakkere vormen worden onderscheiden van sterkere ontwerpen die nog onderzoek zijn, inclusief state expiry.

Verkle trees zitten in dat plan omdat ze bewijsgroottes verkleinen en worden gepositioneerd als een belangrijke stap om validatie mogelijk te maken zonder lokaal grote state op te slaan.

Naarmate meer van de opslaglast naar buiten verschuift, naar gespecialiseerde geschiedenishosts of andere datanetwerken, wordt het beveiligingsverhaal minder over wie alles kan opslaan en meer over wie onafhankelijk correctheid kan controleren en kan ophalen wat ze nodig hebben wanneer een standaardpad faalt.

Wat dit betekent voor de toekomst

De komende 12–36 maanden is de praktische vraag of verificatie zich naar buiten verspreidt terwijl Ethereum meer opslaglasten externaliseert, of dat vertrouwen zich concentreert rond nieuwe service knelpunten.

Eén pad is dat wallets en infrastructuur verschuiven van "vertrouw de RPC" naar "verifieer het bewijs," terwijl bewijsproductie consolideert in een kleine set geoptimaliseerde stacks die moeilijk te repliceren zijn, waarbij afhankelijkheid van de ene klasse provider naar de andere verschuift.

Een ander pad is dat op bewijs gebaseerde verificatie gewoon wordt, met redundante bewijsimplementaties en tooling die gebruikers in staat stellen van providers te wisselen of lokaal te verifiëren wanneer een endpoint censureert, degradeert of verdwijnt, in lijn met inspanningen gericht op lichtgewicht verificatieflows.

Een derde pad is dat snoeien en modulariteit sneller vooruitgaan dan verificatie UX, waardoor gebruikers minder werkbare opties hebben tijdens uitval of censuurgebeurtenissen.

Dat zou de "berghut" operationeel reëel maken voor slechts een smalle laag van het netwerk.

Buterin omschreef de hut als Ethereums BATNA, zelden gebruikt maar altijd beschikbaar, omdat het bestaan van een zelfvoorzienende optie de voorwaarden beperkt die door tussenpersonen worden opgelegd.

Hij sloot af met het argument dat het onderhouden van die terugvaloptie onderdeel is van het onderhouden van Ethereum zelf.

Het bericht Vitalik Buterin geeft zijn grootste ontwerpfout sinds 2017 toe – dus loopt jouw Ethereum risico? verscheen eerst op CryptoSlate.