Helios bouwen: volledig betrouwbare toegang tot Ethereum

Een van de belangrijkste redenen waarom we blockchains gebruiken, is vertrouwenloosheid. Deze eigenschap belooft ons zelf-soevereine toegang te geven tot onze rijkdom en gegevens. Voor het grootste deel hebben blockchains zoals Ethereum deze belofte waargemaakt - onze activa zijn echt van ons. 

Wel zijn er voor het gemak concessies gedaan. Eén zo'n gebied is ons gebruik van gecentraliseerde RPC-servers (remote procedure call). Gebruikers hebben doorgaans toegang tot Ethereum via gecentraliseerde providers zoals Alchemy. Deze bedrijven draaien high-performance nodes op cloudservers, zodat anderen eenvoudig toegang hebben tot ketengegevens. Wanneer een portemonnee zijn tokensaldi opvraagt ​​of controleert of een lopende transactie in een blok is opgenomen, doet hij dit bijna altijd via een van deze gecentraliseerde providers. 

Het probleem met het bestaande systeem is dat gebruikers de providers moeten vertrouwen en dat er geen manier is om de juistheid van hun vragen te verifiëren.

Enter Helios, een op Rust gebaseerde Ethereum-lichtclient die we hebben ontwikkeld en die volledig betrouwbare toegang tot Ethereum biedt. Helios — dat gebruikmaakt van het light client-protocol van Ethereum, mogelijk gemaakt door de recente overstap naar Bewijs van het belang — zet gegevens van een niet-vertrouwde gecentraliseerde RPC-provider om in een aantoonbaar veilige, lokale RPC. Helios werkt samen met gecentraliseerde RPC's om het mogelijk te maken om hun authenticiteit te verifiëren zonder een volledig knooppunt te draaien. 

De afweging tussen draagbaarheid en decentralisatie is een veelvoorkomend pijnpunt, maar onze klant – die we beschikbaar hebben gemaakt voor het publiek om op voort te bouwen en meer – synchroniseert in ongeveer twee seconden, vereist geen opslag en geeft gebruikers toegang tot beveiligde ketengegevens van elk apparaat (inclusief mobiele telefoons en browserextensies). Maar wat zijn? de mogelijke valkuilen van het vertrouwen op gecentraliseerde infrastructuur? We bespreken in dit bericht hoe ze kunnen uitpakken, lopen door onze ontwerpbeslissingen en schetsen ook een paar ideeën voor anderen om bij te dragen aan de codebasis.

De valkuilen van gecentraliseerde infrastructuur: theoretische wezens in het "donkere bos" van Ethereum

Een (theoretisch) wezen schuilt in de donker bos. Deze jaagt niet op zijn prooi in de Ethereum-mempool, maar zet in plaats daarvan zijn valstrikken door gecentraliseerde infrastructuur na te bootsen waarop we zijn gaan vertrouwen. De gebruikers die in deze val lopen, maken geen fouten: ze bezoeken hun favoriete gedecentraliseerde beurs, stellen een redelijke tolerantie voor slippage in en kopen en verkopen tokens zoals gewoonlijk ... Ze doen alles goed, maar worden nog steeds het slachtoffer van een nieuw soort sandwich-aanval, een val die zorgvuldig is ingesteld bij de ingang van het donkere bos van Ethereum: RPC-providers.

Voordat we verder ingaan, laten we eens kijken naar hoe transacties werken op gedecentraliseerde beurzen. Wanneer gebruikers een swaptransactie verzenden, geven ze verschillende parameters aan het slimme contract: welke tokens moeten worden geruild, het swapbedrag en vooral het minimum aantal tokens dat een gebruiker moet ontvangen om de transactie te doorlopen. Deze laatste parameter specificeert dat de swap moet voldoen aan een 'minimum output' of moet terugkeren. Dit staat vaak bekend als "slippage-tolerantie", omdat het in feite de maximale prijswijziging bepaalt die kan optreden tussen het moment dat de transactie naar de mempool wordt verzonden en het moment waarop deze in een blok wordt opgenomen. Als deze parameter te laag is ingesteld, accepteert de gebruiker de mogelijkheid om minder tokens te ontvangen. Deze situatie kan ook leiden tot een sandwich-aanval, waarbij een aanvaller het bod effectief tussen twee kwaadaardige swaps plaatst. De swaps drijven de spotprijs op en dwingen de handel van de gebruiker om tegen een minder gunstige prijs uit te voeren. De aanvaller verkoopt dan onmiddellijk om een ​​kleine winst te verzamelen.

Zolang deze minimale outputparameter in de buurt van de reële waarde wordt ingesteld, bent u veilig voor sandwichaanvallen. Maar wat als uw RPC-provider geen nauwkeurige prijsopgave geeft van het slimme contract voor gedecentraliseerde uitwisseling? Een gebruiker kan dan worden misleid om een ​​swaptransactie te ondertekenen met een lagere minimale outputparameter en, om het nog erger te maken, de transactie rechtstreeks naar de kwaadwillende RPC-provider sturen. In plaats van deze transactie uit te zenden naar de openbare geheugenpool, waar tientallen bots strijden om de sandwichaanval uit te voeren, kan de provider deze achterhouden en de aanvalstransactiebundel rechtstreeks naar Flashbots sturen, waardoor de winst voor zichzelf wordt veiliggesteld.

De hoofdoorzaak van deze aanval is erop te vertrouwen dat iemand anders de status van de blockchain ophaalt. Ervaren gebruikers hebben dit probleem traditioneel opgelost door hun eigen Ethereum-nodes te gebruiken - een tijd- en resource-intensieve onderneming die op zijn minst een constant online machine, honderden gigabytes aan opslagruimte en ongeveer een dag vereist om helemaal opnieuw te synchroniseren. Dit proces is zeker eenvoudiger dan vroeger; groepen houden van Ethereum op ARM hebben onvermoeibaar gewerkt om het mogelijk te maken om nodes te draaien op goedkope hardware (zoals een Raspberry Pi met een externe harde schijf eraan vastgemaakt). Maar zelfs met deze relatief minimale vereisten is het runnen van een node nog steeds moeilijk voor de meeste gebruikers, vooral voor degenen die mobiele apparaten gebruiken.

Het is belangrijk op te merken dat aanvallen van gecentraliseerde RPC-providers, hoewel volledig plausibel, over het algemeen zijn: eenvoudige phishing-aanvallen - en degene die we beschrijven moet nog gebeuren. Hoewel de trackrecords van grotere providers zoals Alchemy ons weinig reden geven om eraan te twijfelen, is het de moeite waard om wat verder onderzoek te doen voordat je onbekende RPC-providers aan je portemonnee toevoegt.

Introductie van Helios: volledig betrouwbare toegang tot Ethereum

Door zijn light client-protocol te introduceren (mogelijk gemaakt door de recente overstap naar Proof of Stake), opende Ethereum spannende nieuwe mogelijkheden voor snelle interactie met de blockchain en het verifiëren van RPC-eindpunten met minimale hardwarevereisten. In de maand sinds de fusie, hebben we een nieuwe lichting lichtklanten onafhankelijk van elkaar zien ontstaan ​​(poolster, nimbus, en de op JavaScript gebaseerde Kevlar) die verschillende benaderingen hebben gevolgd ten dienste van hetzelfde doel: efficiënte en betrouwbare toegang, zonder een volledig knooppunt te gebruiken.

Onze oplossing, Helios, is een Ethereum light-client die in ongeveer twee seconden synchroniseert, geen opslag vereist en volledig betrouwbare toegang tot Ethereum biedt. Zoals alle Ethereum-klanten bestaat Helios uit een uitvoeringslaag en een consensuslaag. In tegenstelling tot de meeste andere clients koppelt Helios beide lagen nauw aan elkaar, zodat gebruikers slechts één stuk software hoeven te installeren en uit te voeren. (Erigon beweegt zich ook in deze richting door een consensuslaag-light-client toe te voegen die rechtstreeks in hun archiefknooppunt is ingebouwd). 

Dus hoe werkt het? De Helios-consensuslaag gebruikt een eerder bekende beacon chain blockhash en een verbinding met een niet-vertrouwde RPC om verifieerbaar te synchroniseren met het huidige blok. De Helios-uitvoeringslaag gebruikt deze geverifieerde beacon chain-blokken in combinatie met een niet-vertrouwde uitvoeringslaag-RPC om willekeurige informatie over de ketenstatus te bewijzen, zoals rekeningsaldi, contractopslag, transactie-ontvangsten en slimme contractoproepresultaten. Deze componenten werken samen om gebruikers een volledig betrouwbare RPC te bieden, zonder dat een volledig knooppunt hoeft te worden uitgevoerd.

...Op de consensuslaag

De consensuslaag light client komt overeen met de beacon chain light client specificatie, en maakt gebruik van de synchronisatiecomités van de bakenketen (geïntroduceerd voorafgaand aan de samenvoeging in de Altair-hardvork). De synchronisatiecommissie is een willekeurig geselecteerde subset van 512 validators die gedurende ~27 uur dienen. 

Wanneer een validator in een synchronisatiecommissie zit, ondertekenen ze elke bakenketenblokkop die ze zien. Als meer dan tweederde van de commissie een bepaalde blockheader ondertekent, is het zeer waarschijnlijk dat dat block in de canonieke bakenketen zit. Als Helios de samenstelling van het huidige synchronisatiecomité kent, kan het vol vertrouwen de kop van de keten volgen door een niet-vertrouwde RPC om de meest recente handtekening van het synchronisatiecomité te vragen. 

Met dank aan BLS handtekening aggregatie, is slechts een enkele controle vereist om de nieuwe header te valideren. Als de handtekening geldig is en is ondertekend door meer dan tweederde van de commissie, is het veilig om aan te nemen dat het blok in de keten was opgenomen (natuurlijk kan het uit de keten worden gereorganiseerd, maar de finaliteit van het trackingblok kan zorgen voor strengere garanties).

Er is echter een duidelijk ontbrekend stuk in deze strategie: hoe de huidige synchronisatiecommissie te vinden. Dit begint met het verwerven van een vertrouwenswortel genaamd de zwak controlepunt voor subjectiviteit. Laat je niet afschrikken door de naam - het betekent gewoon een oude blockhash waarvan we kunnen garanderen dat deze op een bepaald moment in het verleden in de keten is opgenomen. Er zit een interessante wiskunde achter hoe oud het controlepunt precies kan zijn; worstcaseanalyse suggereert ongeveer twee weken, terwijl meer praktische schattingen vele maanden suggereren. 

Als het controlepunt te oud is, zijn er theoretische aanvallen die knooppunten kan misleiden om de verkeerde keten te volgen. Het verkrijgen van een zwak controlepunt voor subjectiviteit is buiten de band voor het protocol. Onze aanpak met Helios biedt een eerste controlepunt dat hard gecodeerd is in de codebase (die gemakkelijk kan worden overschreven); het slaat vervolgens de meest recente voltooide blockhash lokaal op om in de toekomst als controlepunt te gebruiken, wanneer het knooppunt wordt gesynchroniseerd. 

Handig is dat beacon chain-blokken kunnen worden gehasht om een ​​unieke beacon-blockhash te produceren. Dit betekent dat het gemakkelijk is om een ​​knooppunt om een ​​volledig bakenblok te vragen en vervolgens te bewijzen dat de blokinhoud geldig is door het te hashen en te vergelijken met een bekende blockhash. Helios gebruikt deze eigenschap om bepaalde velden binnen het zwakke subjectiviteitscontrolepuntblok op te halen en te bewijzen, waaronder twee zeer belangrijke velden: het huidige synchronisatiecomité en het volgende synchronisatiecomité. Van cruciaal belang is dat dit mechanisme lichte clients in staat stelt snel door de geschiedenis van de blockchain te bladeren.

Nu we een zwak controlepunt voor subjectiviteit hebben, kunnen we de huidige en volgende synchronisatiecommissies ophalen en verifiëren. Als de huidige kettingkop zich binnen dezelfde synchronisatiecommissie-periode bevindt als het controlepunt, dan beginnen we onmiddellijk met het verifiëren van nieuwe blokken met de ondertekende synchronisatiecommissie-headers. Als ons controlepunt meerdere synchronisatiecommissies achterloopt, kunnen we:

1. Gebruik de volgende synchronisatiecommissie na ons controlepunt om een ​​blok op te halen en te verifiëren dat in de toekomst een synchronisatiecommissie veroorzaakt.
2. Gebruik dit nieuwe blok om de nieuwe volgende synchronisatiecommissie op te halen.
3. Als u nog steeds achterloopt, gaat u terug naar stap 1.

Elke iteratie van dit proces stelt ons in staat om 27 uur van de geschiedenis van de keten vooruit te spoelen, te beginnen met een blockhash in het verleden en te synchroniseren met de huidige blockhash.

...Op de uitvoeringslaag

Het doel van de lichte client voor de uitvoeringslaag is om bakenblokheaders te nemen die zijn geverifieerd door de consensuslaag, en deze samen met een niet-vertrouwde RPC van de uitvoeringslaag te gebruiken om geverifieerde uitvoeringslaaggegevens te leveren. Deze gegevens zijn vervolgens toegankelijk via een RPC-server die lokaal wordt gehost door Helios.

Hier is een eenvoudig voorbeeld van het ophalen van het saldo van een account, te beginnen met een snelle inleiding over hoe de status wordt opgeslagen in Ethereum. Elk account bevat een aantal velden, zoals de hash van de contractcode, nonce, opslaghash en saldo. Deze accounts worden opgeslagen in een grote, aangepaste Merkle-Patricia boom de staatsboom genoemd. Als we de wortel van de toestandsboom kennen, kunnen we valideren merkle bewijzen om het bestaan ​​(of de uitsluiting) van een account in de boom te bewijzen. Deze bewijzen zijn in feite onmogelijk te vervalsen.

Helios heeft een geverifieerde staatswortel van de consensuslaag. Deze root gebruiken en merkle proof verzoeken aan de niet-vertrouwde uitvoeringslaag RPC, Helios kan lokaal alle gegevens verifiëren die zijn opgeslagen op Ethereum.

We passen verschillende technieken toe om allerlei gegevens te verifiëren die door de uitvoeringslaag worden gebruikt; samen gebruikt, stellen deze ons in staat om alle gegevens te verifiëren die zijn opgehaald van de niet-vertrouwde RPC. Hoewel een niet-vertrouwde RPC de toegang tot gegevens kan weigeren, kan het ons geen onjuiste resultaten meer opleveren.

Helios in het wild gebruiken

De afweging tussen draagbaarheid en decentralisatie is een veelvoorkomend pijnpunt - maar omdat Helios zo licht van gewicht is, hebben gebruikers toegang tot beveiligde ketengegevens vanaf elk apparaat (inclusief mobiele telefoons en browserextensies). De mogelijkheid om Helios overal te gebruiken, maakt het voor meer mensen mogelijk toegang te krijgen tot betrouwbare Ethereum-gegevens, ongeacht hun hardware. Dit betekent dat gebruikers Helios als hun RPC-provider in MetaMask kunnen gebruiken en zonder enige andere wijzigingen betrouwbare toegang tot dapps kunnen krijgen. 

Verder maakt Rust's ondersteuning voor WebAssembly het voor app-ontwikkelaars gemakkelijk mogelijk om Helios in Javascript-applicaties (zoals portemonnees en dapps) in te sluiten. Deze integraties zouden Ethereum veiliger maken en onze behoefte aan vertrouwen op gecentraliseerde infrastructuur verminderen.

We kunnen niet wachten om te zien waar de community mee komt. Maar in de tussentijd zijn er veel manieren om bij te dragen aan Helios - als je niet geïnteresseerd bent om bij te dragen aan de codebase, kun je ook software bouwen die Helios integreert om te profiteren van de voordelen ervan. Dit zijn slechts enkele van de ideeën waar we enthousiast over zijn:

• Ondersteuning voor het rechtstreeks ophalen van light-clientgegevens van het P2P-netwerk in plaats van via RPC
• Implementeer enkele van de ontbrekende RPC-methoden
• Bouw een versie van Helios die compileert naar WebAssembly
• Integreer Helios rechtstreeks in portefeuillesoftware
• Bouw een webdashboard om uw tokensaldi te bekijken waarmee gegevens worden opgehaald van Helios die in de website is ingesloten met WebAssembly
• Implementeer de engine-API zodat de consensuslaag van Helios kan worden verbonden met een bestaande volledige node van de uitvoeringslaag

Bekijk de codebase om te beginnen — we verwelkomen uw bugrapporten, functieverzoeken en code. En als je iets meer bouwt, deel het dan met ons op Twitter, Telegram, of Farcaster @a16zcrypto.

***
De standpunten die hier naar voren worden gebracht, zijn die van het individuele personeel van AH Capital Management, LLC (“a16z”) dat wordt geciteerd en zijn niet de standpunten van a16z of haar gelieerde ondernemingen. Bepaalde informatie in dit document is verkregen uit externe bronnen, waaronder van portefeuillebedrijven van fondsen die worden beheerd door a16z. Hoewel ontleend aan bronnen die betrouwbaar worden geacht, heeft a16z dergelijke informatie niet onafhankelijk geverifieerd en doet het geen uitspraken over de huidige of blijvende nauwkeurigheid van de informatie of de geschiktheid ervan voor een bepaalde situatie. Bovendien kan deze inhoud advertenties van derden bevatten; a16z heeft dergelijke advertenties niet beoordeeld en keurt de daarin opgenomen advertentie-inhoud niet goed.

Deze inhoud is uitsluitend bedoeld voor informatieve doeleinden en mag niet worden beschouwd als juridisch, zakelijk, investerings- of belastingadvies. U dient hierover uw eigen adviseurs te raadplegen. Verwijzingen naar effecten of digitale activa zijn alleen voor illustratieve doeleinden en vormen geen beleggingsaanbeveling of aanbod om beleggingsadviesdiensten te verlenen. Bovendien is deze inhoud niet gericht op of bedoeld voor gebruik door beleggers of potentiële beleggers, en mag er in geen geval op worden vertrouwd bij het nemen van een beslissing om te beleggen in een fonds dat wordt beheerd door a16z. (Een aanbod om te beleggen in een a16z-fonds wordt alleen gedaan door middel van het onderhandse plaatsingsmemorandum, de inschrijvingsovereenkomst en andere relevante documentatie van een dergelijk fonds en moet in hun geheel worden gelezen.) Alle genoemde beleggingen of portefeuillebedrijven waarnaar wordt verwezen, of beschreven zijn niet representatief voor alle investeringen in voertuigen die door a16z worden beheerd, en er kan geen garantie worden gegeven dat de investeringen winstgevend zullen zijn of dat andere investeringen die in de toekomst worden gedaan vergelijkbare kenmerken of resultaten zullen hebben. Een lijst van investeringen die zijn gedaan door fondsen die worden beheerd door Andreessen Horowitz (met uitzondering van investeringen waarvoor de uitgevende instelling geen toestemming heeft gegeven aan a16z om openbaar te maken, evenals onaangekondigde investeringen in openbaar verhandelde digitale activa) is beschikbaar op https://a16z.com/investments /.

De grafieken en grafieken die hierin worden verstrekt, zijn uitsluitend bedoeld voor informatieve doeleinden en er mag niet op worden vertrouwd bij het nemen van een investeringsbeslissing. In het verleden behaalde resultaten zijn geen indicatie voor toekomstige resultaten. De inhoud spreekt alleen vanaf de aangegeven datum. Alle projecties, schattingen, voorspellingen, doelstellingen, vooruitzichten en/of meningen die in deze materialen worden uitgedrukt, kunnen zonder voorafgaande kennisgeving worden gewijzigd en kunnen verschillen of in strijd zijn met meningen van anderen. Zie https://a16z.com/disclosures voor aanvullende belangrijke informatie