Vitalik Buterin ammette il suo più grande errore di design dal 2017 – quindi il tuo Ethereum è a rischio?

Vitalik Buterin ha dichiarato di non essere più d'accordo con il suo tweet del 2017 che minimizzava la necessità per gli utenti di verificare personalmente Ethereum end-to-end.

Questa settimana, ha sostenuto che la rete dovrebbe trattare la verifica self-hosted come una via di fuga non negoziabile mentre la sua architettura diventa più leggera e modulare.

La posizione originale di Buterin è emersa da un dibattito progettuale su se una blockchain dovesse impegnarsi sullo stato on-chain o trattare lo stato come "implicito", ricostruibile solo riproducendo le transazioni ordinate.

L'approccio di Ethereum, che inserisce una radice di stato in ogni intestazione di blocco e supporta dimostrazioni in stile Merkle, consente a un utente di dimostrare un saldo specifico, codice del contratto o valore di archiviazione senza rieseguire tutta la cronologia, purché l'utente accetti la validità del consenso della catena secondo un'ipotesi di maggioranza onesta.

Nel suo nuovo post, Buterin ha riconsiderato quel compromesso come incompleto nella pratica perché può ancora mettere gli utenti di fronte alla scelta tra riprodurre l'intera catena o fidarsi di un intermediario come un operatore RPC, un host di dati d'archivio o un servizio di prova.

L'inversione di rotta di Vitalik sulla verifica personale della cronologia blockchain

Ha ancorato il cambiamento a due fattori: fattibilità e fragilità.

Sulla fattibilità, Buterin ha scritto che le dimostrazione a conoscenza zero ora offrono un percorso per verificare la correttezza senza "letteralmente rieseguire ogni transazione".

Nel 2017, ha sostenuto che ciò avrebbe spinto Ethereum verso una capacità inferiore per mantenere la verifica a portata di mano.

Il cambiamento è importante perché la roadmap pubblica di Ethereum tratta sempre più ZK come primitiva di verificabilità, con ethereum.org che inquadra le dimostrazione a conoscenza zero come un modo per preservare le proprietà di sicurezza riducendo ciò che un verificatore deve calcolare.

Il lavoro sulle direzioni "ZK-light-client" indica anche un modello in cui un dispositivo può sincronizzarsi utilizzando dimostrazioni compatte anziché fidarsi di un gateway sempre online.

Sulla fragilità, Buterin ha elencato modalità di fallimento che si collocano al di fuori dei modelli di minaccia chiari: rete p2p degradata, servizi di lunga durata che si chiudono, concentrazione dei validatori che cambia il significato pratico di "maggioranza onesta" e pressione di governance informale che trasforma "chiama gli sviluppatori" nel backstop.

Ha citato la pressione di censura intorno a Tornado Cash come esempio di come gli intermediari possano limitare l'accesso, sostenendo che l'opzione di ultima istanza di un utente dovrebbe essere quella di "utilizzare direttamente la catena".

Questa impostazione si allinea con una discussione più ampia sul rafforzamento del livello di base di Ethereum e sulla limitazione del turnover, in un contesto di spinta verso l'"ossificazione" del protocollo.

Nel racconto di Buterin, la "capanna di montagna" non è uno stile di vita predefinito.

È un ripiego credibile che cambia gli incentivi, perché la consapevolezza che gli utenti possano uscire riduce la leva di qualsiasi singolo livello di servizio.

Questo argomento si presenta mentre Ethereum riduce ciò che i nodi ordinari devono archiviare, mentre la storia di verifica della rete deve tenere il passo.

Utilizzo e cronologia dei client Ethereum

I client di esecuzione si stanno muovendo verso la scadenza parziale della cronologia, e l'Ethereum Foundation ha affermato che gli utenti possono ridurre l'utilizzo del disco di circa 300-500 GB rimuovendo i dati dei blocchi pre-Merge, mettendo un nodo a portata di mano su un disco da 2 TB.

Allo stesso tempo, i client leggeri riflettono già un modello di fiducia formalizzato ottimizzato per dispositivi a basse risorse, basandosi su un comitato di sincronizzazione di 512 validatori selezionati circa ogni 1,1 giorni.

Questi parametri rendono la verifica del client leggero praticabile su larga scala.

Tuttavia, concentrano anche l'esperienza utente sulla disponibilità di dati corretti e relay ben comportati quando le condizioni si deteriorano.

Il lavoro a lungo termine di Ethereum sulla "statelessness" mira a ridurre la necessità per i nodi di mantenere uno stato di grandi dimensioni mantenendo intatta la convalida dei blocchi.

Ethereum.org avverte che "statelessness" è un termine improprio, distinguendo forme più deboli da progetti più forti che rimangono in fase di ricerca, inclusa la scadenza dello stato.

Gli alberi di Verkle si inseriscono in quel piano perché riducono le dimensioni delle dimostrazioni e sono posizionati come un passo chiave per convalidare senza archiviare localmente uno stato di grandi dimensioni.

Man mano che più del carico di archiviazione si sposta verso l'esterno, verso host di cronologia specializzati o altre reti di dati, la storia di sicurezza diventa meno una questione di chi può archiviare tutto e più di chi può verificare indipendentemente la correttezza e recuperare ciò di cui ha bisogno quando un percorso predefinito fallisce.

Cosa significa questo andando avanti

Nei prossimi 12-36 mesi, la questione pratica è se la verifica si diffonde verso l'esterno mentre Ethereum esternalizza più carichi di archiviazione, o se la fiducia si raggruppa attorno a nuovi punti di strozzatura del servizio.

Un percorso è che wallet e infrastrutture passino da "fidati dell'RPC" a "verifica la prova", mentre la produzione di prove si consolida in un piccolo insieme di stack ottimizzati difficili da replicare, spostando la dipendenza da una classe di provider a un'altra.

Un altro percorso è che la verifica basata su prove diventi ordinaria, con implementazioni di prova ridondanti e strumenti che consentono agli utenti di cambiare provider o verificare localmente quando un endpoint censura, si degrada o scompare, allineandosi con gli sforzi volti a flussi di verifica leggeri.

Un terzo percorso è che la potatura e la modularità progrediscano più velocemente della UX di verifica, lasciando gli utenti con meno opzioni praticabili durante interruzioni o eventi di censura.

Ciò renderebbe la "capanna di montagna" operativamente reale solo per una piccola fetta della rete.

Buterin ha inquadrato la capanna come BATNA di Ethereum, usata raramente ma sempre disponibile, perché l'esistenza di un'opzione autosufficiente vincola i termini imposti dagli intermediari.

Ha concluso sostenendo che mantenere quel ripiego fa parte del mantenere Ethereum stesso.

Il post Vitalik Buterin ammette il suo più grande errore di progettazione dal 2017 – quindi il tuo Ethereum è a rischio? è apparso per primo su CryptoSlate.