Costruire Helios: accesso completamente trustless a Ethereum

Uno dei motivi principali per cui utilizziamo le blockchain è la mancanza di fiducia. Questa proprietà promette di consentirci un accesso auto-sovrano alla nostra ricchezza e ai nostri dati. Nella maggior parte dei casi, blockchain come Ethereum hanno mantenuto questa promessa: le nostre risorse sono veramente nostre. 

Tuttavia, abbiamo fatto delle concessioni per motivi di comodità. Una di queste aree è l'utilizzo di server RPC (remote procedure call) centralizzati. Gli utenti in genere accedono a Ethereum tramite provider centralizzati come Alchemy. Queste aziende gestiscono nodi ad alte prestazioni su server cloud in modo che altri possano accedere facilmente ai dati della catena. Quando un portafoglio interroga il saldo dei suoi token o verifica se una transazione in sospeso è stata inclusa in un blocco, lo fa quasi sempre attraverso uno di questi fornitori centralizzati. 

Il problema con il sistema esistente è che gli utenti devono fidarsi dei fornitori e non c’è modo di verificare la correttezza delle loro domande.

entrare Helios, un client leggero Ethereum basato su Rust che abbiamo sviluppato che fornisce un accesso completamente trustless a Ethereum. Helios — che utilizza il protocollo light client di Ethereum, reso possibile da interruttore recente a prova di palo — converte i dati da un provider RPC centralizzato non affidabile in un RPC locale verificabilmente sicuro. Helios collabora con RPC centralizzati per consentire di verificarne l'autenticità senza eseguire un nodo completo. 

Il compromesso tra portabilità e decentralizzazione è un punto dolente comune, ma il nostro client, che abbiamo reso disponibile al pubblico per sviluppare e altro ancora, si sincronizza in circa due secondi, non richiede archiviazione e consente agli utenti di accedere ai dati della catena sicura da qualsiasi dispositivo (inclusi telefoni cellulari ed estensioni del browser). Ma cosa sono le potenziali insidie ​​del fare affidamento su un’infrastruttura centralizzata? Parleremo di come potrebbero svolgersi in questo post, analizzeremo le nostre decisioni di progettazione e delineeremo anche alcune idee affinché altri possano contribuire al progetto. codebase.

Le insidie ​​dell'infrastruttura centralizzata: creature teoriche nella “foresta oscura” di Ethereum

Una creatura (teorica) si nasconde nel foresta oscura. Questo non caccia la sua preda nel mempool di Ethereum, ma invece piazza le sue trappole imitando l'infrastruttura centralizzata su cui siamo arrivati ​​a fare affidamento. Gli utenti che cadono in questa trappola non commettono errori: visitano il loro scambio decentralizzato preferito, impostano una ragionevole tolleranza allo slittamento e acquistano e vendono token come al solito... Fanno tutto bene, ma cadono comunque vittime di un nuovo tipo di attacco sandwich, una trappola meticolosamente piazzata proprio all'ingresso della foresta oscura di Ethereum: i fornitori di RPC.

Prima di approfondire, diamo un'occhiata a come funzionano le operazioni sugli scambi decentralizzati. Quando gli utenti inviano una transazione di swap, forniscono diversi parametri allo smart contract: quali token scambiare, l'importo dello swap e, soprattutto, il numero minimo di token che un utente deve ricevere affinché la transazione venga completata. Quest'ultimo parametro specifica che lo scambio deve soddisfare un "output minimo" o ripristinarsi. Questo è spesso noto come “tolleranza allo slittamento”, poiché stabilisce di fatto la variazione massima di prezzo che può verificarsi tra il momento in cui la transazione viene inviata al mempool e quando viene inclusa in un blocco. Se questo parametro è impostato su un valore troppo basso, l'utente accetta la possibilità di ricevere meno token. Questa situazione può anche portare a un attacco sandwich, in cui un utente malintenzionato inserisce effettivamente l'offerta tra due scambi dannosi. Gli swap fanno aumentare il prezzo spot e costringono l'operazione dell'utente ad essere eseguita a un prezzo meno favorevole. L'attaccante poi vende immediatamente per incassare un piccolo profitto.

Finché questo parametro di output minimo è fissato vicino al valore equo, sei al sicuro dagli attacchi sandwich. Ma cosa succede se il tuo fornitore RPC non fornisce un preventivo accurato dal contratto intelligente dell'exchange decentralizzato? Un utente può quindi essere indotto con l'inganno a firmare una transazione di swap con un parametro di output minimo inferiore e, a peggiorare le cose, invia la transazione direttamente al provider RPC dannoso. Invece di trasmettere questa transazione al mempool pubblico, dove dozzine di bot competono per eseguire l’attacco sandwich, il fornitore può trattenerlo e inviare il pacchetto di transazioni di attacco direttamente a Flashbots, assicurandosi i profitti.

La causa principale di questo attacco è la fiducia che qualcun altro possa recuperare lo stato della blockchain. Gli utenti esperti hanno tradizionalmente risolto questo problema eseguendo i propri nodi Ethereum: un'attività dispendiosa in termini di tempo e risorse che, come minimo, richiede una macchina costantemente online, centinaia di gigabyte di spazio di archiviazione e circa un giorno per sincronizzarsi da zero. Questo processo è certamente più semplice di prima; gruppi come Ethereum su ARM hanno lavorato instancabilmente per rendere possibile l'esecuzione dei nodi su hardware a basso costo (come un Raspberry Pi con un disco rigido esterno collegato ad esso). Ma anche con questi requisiti relativamente minimi, gestire un nodo è ancora difficile per la maggior parte degli utenti, in particolare per quelli che utilizzano dispositivi mobili.

È importante notare che gli attacchi ai provider RPC centralizzati, sebbene del tutto plausibili, sono generalmente semplici attacchi di phishing – e quello che descriviamo deve ancora accadere. Anche se i precedenti di fornitori più grandi come Alchemy ci danno pochi motivi per dubitare di loro, vale la pena fare ulteriori ricerche prima di aggiungere fornitori RPC sconosciuti al tuo portafoglio.

Presentazione di Helios: accesso completamente trustless a Ethereum

Introducendo il suo protocollo light client (reso possibile dal recente passaggio alla Proof of Stake), Ethereum ha aperto nuove entusiasmanti possibilità per interagire rapidamente con la blockchain e verificare gli endpoint RPC con requisiti hardware minimi. Nel mese successivo la fusione, abbiamo visto un nuovo gruppo di clienti luce emergere indipendentemente l'uno dall'altro (stella polare, nimboe quello basato su JavaScript Kevlar) che hanno adottato approcci diversi al servizio dello stesso obiettivo: accesso efficiente e senza fiducia, senza utilizzare un nodo completo.

La nostra soluzione, Helios, è un light client Ethereum che si sincronizza in circa due secondi, non richiede spazio di archiviazione e fornisce un accesso completamente trustless a Ethereum. Come tutti i client Ethereum, Helios è costituito da un livello di esecuzione e da un livello di consenso. A differenza della maggior parte degli altri client, Helios associa strettamente entrambi i livelli in modo che gli utenti debbano installare ed eseguire solo un singolo software. (Erigo si sta muovendo anche in questa direzione, aggiungendo un light client a livello di consenso integrato direttamente nel loro nodo di archivio). 

Quindi, come funziona? Il livello di consenso di Helios utilizza un blockhash della catena di beacon precedentemente noto e una connessione a un RPC non attendibile per sincronizzarsi in modo verificabile con il blocco corrente. Il livello di esecuzione di Helios utilizza questi blocchi di catene di beacon autenticati in tandem con un livello di esecuzione non attendibile RPC per dimostrare informazioni arbitrarie sullo stato della catena come saldi dei conti, archiviazione dei contratti, ricevute di transazioni e risultati delle chiamate di contratti intelligenti. Questi componenti lavorano insieme per fornire agli utenti un RPC completamente trustless, senza la necessità di eseguire un nodo completo.

…A livello di consenso

Il light client del livello di consenso è conforme al light client della catena di beacon specificazionee fa uso dei comitati di sincronizzazione della catena di beacon (introdotti prima dell'unione nell'hard fork di Altair). Il comitato di sincronizzazione è un sottoinsieme selezionato casualmente di 512 validatori che prestano servizio per periodi di circa 27 ore. 

Quando un validatore fa parte di un comitato di sincronizzazione, firma ogni intestazione di blocco della catena di beacon che vede. Se più di due terzi del comitato firma un dato header di blocco, è molto probabile che quel blocco sia nella canonical beacon chain. Se Helios conosce la composizione dell'attuale comitato di sincronizzazione, può monitorare con sicurezza il capo della catena chiedendo a un RPC non attendibile la firma più recente del comitato di sincronizzazione. 

Grazie alla BLS firma aggregazione, è necessario un solo controllo per convalidare la nuova intestazione. Se la firma è valida ed è stata firmata da più di due terzi del comitato, è lecito ritenere che il blocco sia stato incluso nella catena (ovviamente può essere riorganizzato fuori dalla catena, ma il tracciamento della finalità del blocco può fornire garanzie più severe).

C'è però un evidente pezzo mancante in questa strategia: come trovare l'attuale comitato di sincronizzazione. Questo inizia con l'acquisizione di una radice di fiducia chiamata punto di controllo debole della soggettività. Non lasciarti intimidire dal nome: significa semplicemente un vecchio blockhash che possiamo garantire sia stato incluso nella catena in qualche momento del passato. C'è qualche matematica interessante dietro esattamente quanti anni può avere il checkpoint; l’analisi del caso peggiore suggerisce circa due settimane, mentre stime più pratiche suggeriscono molti mesi. 

Se il checkpoint è troppo vecchio, ci sono attacchi teorici che può indurre i nodi a seguire la catena sbagliata. L'acquisizione di un checkpoint di soggettività debole è fuori banda per il protocollo. Il nostro approccio con Helios fornisce un checkpoint iniziale codificato nel codice base (che può essere facilmente sovrascritto); quindi salva localmente il blockhash finalizzato più recente da utilizzare come checkpoint in futuro, ogni volta che il nodo viene sincronizzato. 

Convenientemente, i blocchi della catena di beacon possono essere sottoposti ad hashing per produrre un blockhash di beacon unico. Ciò significa che è facile chiedere a un nodo un blocco beacon completo e quindi dimostrare che i contenuti del blocco sono validi eseguendo l'hashing e confrontandolo con un blockhash noto. Helios utilizza questa proprietà per recuperare e provare alcuni campi all'interno del blocco del punto di controllo della soggettività debole, inclusi due campi molto importanti: il comitato di sincronizzazione corrente e il comitato di sincronizzazione successivo. Fondamentalmente, questo meccanismo consente ai light client di avanzare rapidamente attraverso la storia della blockchain.

Ora che abbiamo un punto di controllo della soggettività debole, possiamo recuperare e verificare i comitati di sincronizzazione attuali e successivi. Se l'attuale capo della catena si trova nello stesso periodo del comitato di sincronizzazione del checkpoint, inizieremo immediatamente a verificare i nuovi blocchi con le intestazioni del comitato di sincronizzazione firmate. Se il nostro checkpoint è indietro di diversi comitati di sincronizzazione, possiamo:

1. Utilizza il comitato di sincronizzazione successivo al nostro checkpoint per recuperare e verificare un blocco che origina un comitato di sincronizzazione in futuro.
2. Usa questo nuovo blocco per recuperare il nuovo comitato di sincronizzazione successivo.
3. Se sei ancora indietro, torna al passaggio 1.

Ogni iterazione di questo processo ci consente di avanzare rapidamente attraverso 27 ore della storia della catena, iniziare con qualsiasi blockhash del passato e sincronizzarci con il blockhash corrente.

…A livello di esecuzione

L'obiettivo del client light del livello di esecuzione è prendere le intestazioni dei blocchi beacon verificati dal livello di consenso e utilizzarle insieme a un RPC del livello di esecuzione non attendibile per fornire dati verificati del livello di esecuzione. È quindi possibile accedere a questi dati tramite un server RPC ospitato localmente da Helios.

Ecco un semplice esempio di come recuperare il saldo di un conto, iniziando con una rapida introduzione su come viene archiviato lo stato in Ethereum. Ogni account contiene un paio di campi, ad esempio l'hash del codice contratto, il nonce, l'hash di archiviazione e il saldo. Questi account sono archiviati in un formato grande e modificato Albero Merkle-Patricia chiamato albero degli stati. Se conosciamo la radice dell'albero degli stati, possiamo convalidare prove di merkle per dimostrare l'esistenza (o l'esclusione) di qualsiasi account all'interno dell'albero. Queste prove sono effettivamente impossibili da falsificare.

Helios ha una radice di stato autenticata dal livello di consenso. Usando questa radice ed richieste di prova merkle al livello di esecuzione non attendibile RPC, Helios può verificare localmente tutti i dati archiviati su Ethereum.

Applichiamo diverse tecniche per verificare tutti i tipi di dati utilizzati dal livello di esecuzione; utilizzati insieme, questi ci consentono di autenticare tutti i dati recuperati dall'RPC non attendibile. Sebbene una RPC non attendibile possa negare l'accesso ai dati, non può più fornirci risultati errati.

Utilizzo di Helios in natura

Il compromesso tra portabilità e decentralizzazione è un punto dolente comune, ma poiché Helios è così leggero, gli utenti possono accedere ai dati della catena sicura da qualsiasi dispositivo (inclusi telefoni cellulari ed estensioni del browser). La possibilità di eseguire Helios ovunque consente a più persone di accedere ai dati Ethereum senza fiducia, indipendentemente dal loro hardware. Ciò significa che gli utenti possono utilizzare Helios come provider RPC in MetaMask e accedere in modo sicuro a dapps senza altre modifiche. 

Inoltre, il supporto di Rust per WebAssembly rende facilmente possibile agli sviluppatori di app incorporare Helios all'interno di applicazioni Javascript (come portafogli e dapps). Queste integrazioni renderebbero Ethereum più sicuro e ridurrebbero la nostra necessità di fidarci di un’infrastruttura centralizzata.

Non vediamo l'ora di vedere cosa inventerà la community. Ma nel frattempo, ci sono molti modi per contribuire a Helios: se non sei interessato a contribuire al codice base, puoi anche creare software che integri Helios per trarne vantaggio. Queste sono solo alcune delle idee di cui siamo entusiasti:

• Supporta il recupero dei dati light client direttamente dalla rete P2P anziché tramite RPC
• Implementare alcuni dei metodi RPC mancanti
• Crea una versione di Helios compilabile in WebAssembly
• Integra Helios direttamente nel software del portafoglio
• Crea un dashboard Web per visualizzare i saldi dei token che recupera i dati da Helios incorporati nel sito Web con WebAssembly
• Implementa l'API del motore in modo che il livello di consenso di Helios possa essere connesso a un nodo completo del livello di esecuzione esistente

Controlla la base di codice per iniziare: accogliamo con favore le vostre segnalazioni di bug, richieste di funzionalità e codice. E se costruisci qualcosa in più, condividilo con noi su Twitter, Telegramo Farcaster @a16zcrypto.

***
Le opinioni qui espresse sono quelle del personale di AH Capital Management, LLC ("a16z") citato e non sono le opinioni di a16z o delle sue affiliate. Alcune informazioni qui contenute sono state ottenute da fonti di terze parti, incluse società in portafoglio di fondi gestiti da a16z. Sebbene tratti da fonti ritenute affidabili, a16z non ha verificato in modo indipendente tali informazioni e non fornisce dichiarazioni sull'accuratezza attuale o duratura delle informazioni o sulla sua adeguatezza per una determinata situazione. Inoltre, questo contenuto può includere pubblicità di terze parti; a16z non ha esaminato tali annunci pubblicitari e non approva alcun contenuto pubblicitario in essi contenuto.

Questo contenuto viene fornito solo a scopo informativo e non deve essere considerato come consulenza legale, commerciale, di investimento o fiscale. Dovresti consultare i tuoi consulenti in merito a tali questioni. I riferimenti a qualsiasi titolo o risorsa digitale sono solo a scopo illustrativo e non costituiscono una raccomandazione di investimento o un'offerta per fornire servizi di consulenza in materia di investimenti. Inoltre, questo contenuto non è diretto né destinato all'uso da parte di investitori o potenziali investitori e non può in alcun caso essere invocato quando si decide di investire in qualsiasi fondo gestito da a16z. (Un'offerta per investire in un fondo a16z sarà fatta solo dal memorandum di collocamento privato, dal contratto di sottoscrizione e da altra documentazione pertinente di tale fondo e dovrebbe essere letta nella sua interezza.) Eventuali investimenti o società in portafoglio menzionati, citati o descritti non sono rappresentativi di tutti gli investimenti in veicoli gestiti da a16z, e non si può garantire che gli investimenti saranno redditizi o che altri investimenti effettuati in futuro avranno caratteristiche o risultati simili. Un elenco degli investimenti effettuati da fondi gestiti da Andreessen Horowitz (esclusi gli investimenti per i quali l'emittente non ha autorizzato a16z a divulgare pubblicamente e gli investimenti non annunciati in asset digitali quotati in borsa) è disponibile all'indirizzo https://a16z.com/investments /.

Grafici e grafici forniti all'interno sono esclusivamente a scopo informativo e non dovrebbero essere presi in considerazione quando si prende una decisione di investimento. I rendimenti passati non sono indicativi di risultati futuri. Il contenuto parla solo a partire dalla data indicata. Eventuali proiezioni, stime, previsioni, obiettivi, prospettive e/o opinioni espresse in questi materiali sono soggette a modifiche senza preavviso e possono differire o essere contrarie alle opinioni espresse da altri. Si prega di consultare https://a16z.com/disclosures per ulteriori informazioni importanti