Vitalik Buterin onthult de grote uitdaging voor de toekomst van Ethereum - en hoe deze op te lossen

Mede-oprichter van Ethereum, Vitalik Buterin, deelde zijn mijmering over een "onderbelicht, maar niettemin erg belangrijk" aspect van het Ethereum-ecosysteem in een recente blogpost dit weekend.

De post getiteld "Hoe zal de multi-client filosofie van Ethereum omgaan met ZK-EVM's?" gericht op de technische uitdagingen, compromissen en mogelijke oplossingen voor het creëren van een multi-client ecosysteem voor ZK-EVM's.

Het multi-client probleem met Zk-EVM's

Vitalik gelooft dat ZK-EVM's in de toekomst zullen evolueren om een ​​essentieel onderdeel te worden van Ethereum's layer-1 beveiligings- en verificatieproces. Met Zero Knowledge (ZK)-technologie kunnen ontwikkelaars de authenticiteit van een transactie of bericht bewijzen zonder aanvullende informatie vrij te geven. Zo kan de ene partij de andere ervan overtuigen dat een bericht waar is zonder kennis te onthullen die verder gaat dan de geldigheid van het bericht.

Het privacy-afdwingende karakter van ZK-technologie zou echter het bredere EVM-landschap kunnen verstoren, aangezien Ethereum-clients subtiel verschillen in het implementeren van protocolregels, aldus de mede-oprichter van Ethereum.

Layer 2-protocollen in ZK-rollups hebben met succes ZK-bewijzen gebruikt en hebben geholpen Ethereum te schalen door meerdere transacties in één bewijs te bundelen. Naarmate ZK-EVM's echter evolueren om de uitvoering op Mainnet te verifiëren, "worden ZK-EVM's de facto een derde type Ethereum-client, net zo belangrijk voor de netwerkbeveiliging als uitvoeringsclients en consensusclients vandaag zijn."

Het bekijken van ZK-EVM's als een derde type Ethereum-client roept de volgende vraag op van Vitalik,

"Hoe zouden we eigenlijk een 'multi-client'-ecosysteem kunnen maken voor ZK-bewijzende juistheid van Ethereum-blokken?"

Terwijl het ecosysteem schaalt, wil Vitalik de voordelen van de "multi-client-filosofie" behouden en tegelijkertijd gebruikmaken van de mogelijkheden van ZK-EVM's om de schaalbaarheid, beveiliging en decentralisatie van het Ethereum-netwerk te verbeteren.

De belangrijkste technische uitdagingen van het gebruik van ZK-technologie met meerdere klanten hebben volgens Vitalik betrekking op latentie en data-inefficiëntie. Bovendien gaan individuele Ethereum-clients anders om met zero-knowledge bewijzen vanwege specifieke interpretaties van protocolregels of ZK-EVM-implementaties.

ZK-EVM multi-client oplossingen

Ondanks deze uitdagingen is Vitalik van mening dat het creëren van een open multi-client ZK-EVM-ecosysteem haalbaar en gunstig is voor de veiligheid en decentralisatie van Ethereum.

Hieronder vindt u een visuele weergave van de verschillende clients die worden gebruikt in de consensus- en uitvoeringslagen van het Ethereum-ecosysteem.

Vitalik voerde aan dat het hebben van meerdere klanten de veiligheid en decentralisatie van het netwerk verhoogt door het risico van een enkele catastrofale bug in één implementatie te verminderen, wat zou kunnen leiden tot een uitval van het hele netwerk. Bovendien helpt een multi-client-filosofie om machtsconcentratie binnen één ontwikkelteam of organisatie te voorkomen, wat politieke decentralisatie bevordert.

Vitalik presenteerde drie mogelijke oplossingen voor het probleem, zoals hieronder weergegeven.

1. “Single ZK-EVM: verlaat het multi-client paradigma en kies één ZK-EVM die we gebruiken om blokken te verifiëren.
2. Gesloten multi-ZK-EVM: een specifieke set van meerdere ZK-EVM's overeenkomen en vastleggen in consensus, en een consensuslaagprotocolregel hebben dat een blok bewijzen nodig heeft van meer dan de helft van de ZK-EVM's in die set om als geldig te worden beschouwd .
3. Open multi ZK-EVM: verschillende clients hebben verschillende ZK-EVM-implementaties en elke client wacht op een bewijs dat compatibel is met zijn eigen implementatie voordat hij een blok als geldig accepteert.”

In de context van ZK-EVM's ondersteunt Vitalik het idee van een open multi-client ZK-EVM-ecosysteem. Verschillende clients hebben verschillende ZK-EVM-implementaties en elke client wacht op bewijs dat compatibel is met zijn eigen voordat een blok als geldig wordt geaccepteerd.

"Voor mij lijkt (3) ideaal, tenminste totdat en tenzij onze technologie zodanig verbetert dat we formeel kunnen bewijzen dat alle ZK-EVM-implementaties gelijkwaardig zijn aan elkaar..."

Zodra de technologie echter zodanig is verbeterd dat ZK-EVM-implementaties enigszins gestandaardiseerd zijn, voerde Vitalik aan dat de oplossing zal zijn om de meest efficiënte optie te kiezen. Hij is van mening dat de "uitdagingen [voor optie 3] kleiner lijken dan de uitdagingen van de andere twee opties, althans voorlopig."

Vitalik knikte ook naar de recente snelle vooruitgang op het gebied van AI en stelde dat vooruitgang op het gebied van AI de ontwikkeling van bewezen ZK-EVM-implementaties een boost zou kunnen geven.

“Op de langere termijn kan er natuurlijk van alles gebeuren. Misschien zal AI de formele verificatie zo opvoeren dat het gemakkelijk kan bewijzen dat ZK-EVM-implementaties gelijkwaardig zijn en alle bugs kan identificeren die verschillen veroorzaken.”