Building Helios: Fullständigt förtroendelös tillgång till Ethereum

En av de främsta anledningarna till att vi använder blockkedjor är tillitslöshet. Den här egenskapen lovar att ge oss självsuverän tillgång till vår rikedom och data. För det mesta har blockkedjor som Ethereum levererat detta löfte - våra tillgångar är verkligen våra. 

Det finns dock eftergifter som vi har gjort för bekvämlighetens skull. Ett sådant område är vår användning av centraliserade RPC-servrar (remote procedure call). Användare kommer vanligtvis åt Ethereum genom centraliserade leverantörer som Alchemy. Dessa företag kör högpresterande noder på molnservrar så att andra enkelt kan komma åt kedjedata. När en plånbok frågar efter sina tokensaldon eller kontrollerar om en pågående transaktion har inkluderats i ett block, gör den det nästan alltid genom någon av dessa centraliserade leverantörer. 

Problemet med det befintliga systemet är att användarna måste lita på leverantörerna, och det finns inget sätt att verifiera att deras frågor är korrekta.

ange Helios, en Rust-baserad Ethereum light-klient som vi utvecklat som ger helt tillitslös tillgång till Ethereum. Helios — som använder Ethereums lätta klientprotokoll, möjliggjort av senaste bytet till bevis på spel — konverterar data från en opålitlig centraliserad RPC-leverantör till en verifierbart säker, lokal RPC. Helios arbetar tillsammans med centraliserade RPC:er för att göra det möjligt att verifiera deras äkthet utan att köra en full nod. 

Avvägningen mellan portabilitet och decentralisering är en vanlig smärtpunkt, men vår klient – ​​som vi har gjort tillgänglig för allmänheten att bygga på och mer – synkroniseras på cirka två sekunder, kräver ingen lagring och tillåter användare att komma åt säker kedjedata från alla enheter (inklusive mobiltelefoner och webbläsartillägg). Men vad är det de potentiella fallgroparna med att förlita sig på centraliserad infrastruktur? Vi tar upp hur de kan spela ut i det här inlägget, går igenom våra designbeslut och skisserar också några idéer för andra att bidra till kodbas.

Fallgroparna i centraliserad infrastruktur: teoretiska varelser i Ethereums "mörka skog"

En (teoretisk) varelse lurar i mörk skog. Den här jagar inte efter sitt byte i Ethereum-mempoolen, utan sätter istället sina fällor genom att efterlikna centraliserad infrastruktur som vi har kommit att lita på. Användarna som fastnar i den här fällan gör inga misstag: de besöker sin favoritbörs, sätter en rimlig glidtolerans och köper och säljer tokens som vanligt... De gör allt rätt, men faller fortfarande offer för en ny typ av smörgåsattack, en fälla som noggrant satts vid ingången till Ethereums mörka skog: RPC-leverantörer.

Innan vi utvecklar, låt oss titta på hur affärer fungerar på decentraliserade börser. När användare skickar en swaptransaktion, tillhandahåller de flera parametrar till det smarta kontraktet - vilka tokens som ska bytas, swapbeloppet och viktigast av allt, det minsta antalet tokens som en användare måste få för att transaktionen ska gå igenom. Den sista parametern anger att växlingen måste uppfylla en "minimumutgång" eller återgå. Detta är ofta känt som "glidningstolerans", eftersom det effektivt sätter den maximala prisändringen som kan inträffa mellan när transaktionen skickas till mempoolen och när den ingår i ett block. Om denna parameter är inställd för lågt accepterar användaren möjligheten att ta emot färre tokens. Denna situation kan också leda till en sandwichattack, där en angripare effektivt lägger budet mellan två skadliga byten. Swapparna driver upp spotpriset och tvingar användarens handel att genomföras till ett mindre förmånligt pris. Angriparen säljer sedan omedelbart för att samla in en liten vinst.

Så länge denna minimiutgångsparameter är inställd nära det verkliga värdet är du säker från sandwichattacker. Men vad händer om din RPC-leverantör inte ger en korrekt prisuppgift från det decentraliserade utbytessmarta kontraktet? En användare kan sedan luras att signera en swaptransaktion med en lägre minimiutgångsparameter och, för att göra saken värre, skickar transaktionen direkt till den skadliga RPC-leverantören. Istället för att sända denna transaktion till den offentliga mempoolen, där dussintals bots tävlar om att utföra sandwichattacken, kan leverantören hålla tillbaka den och skicka attacktransaktionspaketet direkt till Flashbots, och säkra vinsten för sig själva.

Grundorsaken till denna attack är att lita på att någon annan hämtar blockkedjans tillstånd. Erfarna användare har traditionellt löst detta problem genom att köra sina egna Ethereum-noder – en tids- och resurskrävande strävan som åtminstone kräver en ständigt online-maskin, hundratals gigabyte lagringsutrymme och cirka en dag för att synkronisera från grunden. Denna process är verkligen enklare än den brukade vara; grupper som Ethereum på ARM har arbetat outtröttligt för att göra det möjligt att köra noder på lågkostnadshårdvara (som en Raspberry Pi med en extern hårddisk fastspänd på den). Men även med dessa relativt minimala krav är det fortfarande svårt att köra en nod för de flesta användare, särskilt för de som använder mobila enheter.

Det är viktigt att notera att attacker från centraliserade RPC-leverantörer, även om de är helt rimliga, i allmänhet är enkla nätfiskeattacker — och den vi beskriver har ännu inte inträffat. Även om meriter från större leverantörer som Alchemy ger oss ingen anledning att tvivla på dem, är det värt att göra lite mer forskning innan du lägger till okända RPC-leverantörer i din plånbok.

Vi introducerar Helios: helt tillitslös tillgång till Ethereum

Genom att introducera sitt lätta klientprotokoll (möjligt genom den senaste övergången till Proof of Stake) öppnade Ethereum spännande nya möjligheter för att snabbt interagera med blockkedjan och verifiera RPC-slutpunkter med minimala hårdvarukrav. I månaden sedan Sammanfogningen, vi har sett en ny skörd av ljusklienter dyka upp oberoende av varandra (Lodestar, nimbus, och den JavaScript-baserade Kevlar) som har tagit olika tillvägagångssätt för samma mål: effektiv och tillförlitlig åtkomst, utan att använda en fullständig nod.

Vår lösning, Helios, är en Ethereum light-klient som synkroniseras på cirka två sekunder, kräver ingen lagring och ger helt tillförlitlig åtkomst till Ethereum. Som alla Ethereum-klienter består Helios av ett exekveringslager och ett konsensuslager. Till skillnad från de flesta andra klienter, kopplar Helios tätt ihop båda lagren så att användarna bara behöver installera och köra en enda mjukvara. (Erigon rör sig i denna riktning också genom att lägga till en konsensuslager ljusklient inbyggd direkt i deras arkivnod). 

Så hur fungerar det? Helios konsensuslagret använder en tidigare känd beacon chain blockhash och en anslutning till en opålitlig RPC för att verifierbart synkronisera med det aktuella blocket. Helios-exekveringsskiktet använder dessa autentiserade beacon-kedjeblock tillsammans med en opålitlig exekveringslager-RPC för att bevisa godtycklig information om kedjetillståndet, såsom kontosaldon, kontraktslagring, transaktionskvitton och smarta kontraktsanropsresultat. Dessa komponenter arbetar tillsammans för att ge användarna en helt tillförlitlig RPC, utan att behöva köra en fullständig nod.

…På konsensusskiktet

Konsensuslagerljusklienten överensstämmer med beacon chain light-klienten specifikation, och använder sig av beaconkedjans synkroniseringskommittéer (introducerades före Merge in the Altair hard fork). Synkroniseringskommittén är en slumpmässigt utvald undergrupp av 512 validerare som fungerar under ~27-timmarsperioder. 

När en validerare är med i en synkroniseringskommitté, signerar de varje fyrkedjeblockshuvud som de ser. Om mer än två tredjedelar av kommittén undertecknar en given blockrubrik är det högst troligt att det blocket finns i den kanoniska beaconkedjan. Om Helios känner till sammansättningen av den nuvarande synkroniseringskommittén kan den med säkerhet spåra chefen för kedjan genom att be en opålitlig RPC om den senaste synkroniseringskommitténs signatur. 

Tack vare BLS namnteckning aggregering krävs endast en enda kontroll för att validera den nya rubriken. Om signaturen är giltig och har undertecknats av mer än två tredjedelar av kommittén, är det säkert att anta att blocket ingick i kedjan (naturligtvis kan det omorganiseras utanför kedjan, men spårningsblockets slutgiltighet kan ge strängare garantier).

Det finns dock en uppenbar saknad del i den här strategin: hur man hittar den nuvarande synkroniseringskommittén. Detta börjar med att skaffa en rot av förtroende som kallas svag subjektivitetskontroll. Låt inte namnet skrämma dig – det betyder bara ett gammalt blockhash som vi kan garantera att det fanns med i kedjan någon gång i det förflutna. Det finns en del intressant matematik bakom exakt hur gammal checkpointen kan vara; värsta tänkbara analyser tyder på cirka två veckor, medan mer praktiska uppskattningar tyder på många månader. 

Om checkpointen är för gammal så finns det teoretiska attacker som kan lura noder att följa fel kedja. Att skaffa en svag subjektivitetskontrollpunkt är utanför bandet för protokollet. Vårt tillvägagångssätt med Helios ger en första kontrollpunkt hårdkodad i kodbasen (som enkelt kan åsidosättas); den sparar sedan den senaste slutförda blockhash lokalt för att använda som kontrollpunkt i framtiden, närhelst noden synkroniseras. 

Lämpligen kan beacon chain block hashas för att producera en unik beacon blockhash. Det betyder att det är lätt att be en nod om ett fullständigt beacon-block och sedan bevisa att blockinnehållet är giltigt genom att hasha det och jämföra med ett känt blockhash. Helios använder den här egenskapen för att hämta och bevisa vissa fält i det svaga subjektivitetskontrollpunktsblocket, inklusive två mycket viktiga fält: den nuvarande synkroniseringskommittén och nästa synkroniseringskommitté. Kritiskt sett tillåter denna mekanism lätta klienter att spola framåt genom blockkedjans historia.

Nu när vi har en svag subjektivitetskontrollpunkt kan vi hämta och verifiera nuvarande och nästa synkroniseringskommittéer. Om det nuvarande kedjehuvudet är inom samma synkroniseringskommittéperiod som kontrollpunkten, börjar vi omedelbart verifiera nya block med de undertecknade synkroniseringskommittéernas rubriker. Om vår kontrollpunkt ligger flera synkkommittéer bakom kan vi:

1. Använd nästa synkroniseringskommitté efter vår kontrollpunkt för att hämta och verifiera ett block som kommer från en synkroniseringskommitté i framtiden.
2. Använd detta nya block för att hämta nästa synkroniseringskommitté.
3. Om du fortfarande ligger bakom, gå tillbaka till steg 1.

Varje iteration av denna process tillåter oss att spola framåt genom 27 timmar av kedjans historia, börja med vilken blockhash som helst i det förflutna och synkronisera med den nuvarande blockhashen.

…Vid exekveringsskiktet

Målet med exekveringsskiktets lätta klient är att ta beacon block-rubriker som verifieras av konsensusskiktet och använda dem tillsammans med en opålitlig exekveringslager-RPC för att tillhandahålla verifierad exekveringslagerdata. Dessa data kan sedan nås via en RPC-server som är lokalt värd för Helios.

Här är ett enkelt exempel på att hämta ett kontos saldo, som börjar med en snabb primer om hur staten lagras i Ethereum. Varje konto innehåller ett par fält, som kontraktskoden hash, nonce, storage hash och saldo. Dessa konton lagras i en stor, modifierad Merkle-Patricia träd kallas statsträdet. Om vi ​​känner till roten till statsträdet kan vi validera merkle bevis för att bevisa existensen (eller uteslutningen) av ett konto i trädet. Dessa bevis är faktiskt omöjliga att förfalska.

Helios har en autentiserad tillståndsrot från konsensusskiktet. Använder denna rot och merkle proof-förfrågningar till det opålitliga exekveringsskiktet RPC, Helios kan lokalt verifiera all data som lagras på Ethereum.

Vi använder olika tekniker för att verifiera alla typer av data som används av exekveringsskiktet; används tillsammans, dessa tillåter oss att autentisera all data som hämtas från den opålitliga RPC:n. Även om en opålitlig RPC kan neka åtkomst till data, kan den inte längre ge oss felaktiga resultat.

Använder Helios i det vilda

Avvägningen mellan portabilitet och decentralisering är en vanlig smärtpunkt - men eftersom Helios är så lätt kan användare komma åt säker kedjedata från vilken enhet som helst (inklusive mobiltelefoner och webbläsartillägg). Möjligheten att köra Helios var som helst gör det möjligt för fler människor att komma åt tillförlitlig Ethereum-data, oavsett deras hårdvara. Detta innebär att användare kan använda Helios som sin RPC-leverantör i MetaMask och tillförlitligt komma åt dapps utan några andra ändringar. 

Dessutom gör Rusts stöd för WebAssembly det enkelt möjligt för apputvecklare att bädda in Helios i Javascript-applikationer (som plånböcker och dapps). Dessa integrationer skulle göra Ethereum säkrare och minska vårt behov av att lita på centraliserad infrastruktur.

Vi kan inte vänta på att se vad samhället kommer fram till. Men under tiden finns det många sätt att bidra till Helios - om du inte är intresserad av att bidra till kodbasen kan du också bygga mjukvara som integrerar Helios för att dra nytta av dess fördelar. Det här är bara några av de idéer vi är glada över:

• Stöd för att hämta lätt klientdata direkt från P2P-nätverket snarare än via RPC
• Implementera några av de saknade RPC-metoderna
• Bygg en version av Helios som kompileras till WebAssembly
• Integrera Helios direkt i plånboken
• Bygg en webbinstrumentpanel för att se dina tokensaldon som hämtar data från Helios inbäddade på webbplatsen med WebAssembly
• Implementera motorns API så att Helios konsensuslager kan kopplas till en befintlig exekveringslager full nod

Kolla in kodbasen för att komma igång — vi välkomnar dina felrapporter, funktionsförfrågningar och kod. Och om du bygger något mer, dela det med oss ​​vidare Twitter, Telegram, eller Farcaster @a16zcrypto.

***
De åsikter som uttrycks här är de från den individuella AH Capital Management, LLC (“a16z”) personal som citeras och är inte åsikterna från a16z eller dess dotterbolag. Viss information som finns här har erhållits från tredjepartskällor, inklusive från portföljbolag av fonder som förvaltas av a16z. Även om den är hämtad från källor som anses vara tillförlitliga, har a16z inte självständigt verifierat sådan information och gör inga utfästelser om den aktuella eller varaktiga riktigheten av informationen eller dess lämplighet för en given situation. Dessutom kan detta innehåll innehålla tredjepartsannonser; a16z har inte granskat sådana annonser och stöder inte något reklaminnehåll i dem.

Detta innehåll tillhandahålls endast i informationssyfte och bör inte litas på som juridisk rådgivning, affärs-, investerings- eller skatterådgivning. Du bör rådfråga dina egna rådgivare i dessa frågor. Hänvisningar till värdepapper eller digitala tillgångar är endast i illustrativt syfte och utgör inte en investeringsrekommendation eller erbjudande om att tillhandahålla investeringsrådgivningstjänster. Dessutom är detta innehåll inte riktat till eller avsett att användas av några investerare eller potentiella investerare, och får inte under några omständigheter lita på när man fattar ett beslut om att investera i någon fond som förvaltas av a16z. (Ett erbjudande om att investera i en a16z-fond kommer endast att göras av det privata emissionsmemorandumet, teckningsavtalet och annan relevant dokumentation för en sådan fond och bör läsas i sin helhet.) Alla investeringar eller portföljbolag som nämns, hänvisas till, eller beskrivna är inte representativa för alla investeringar i fordon som förvaltas av a16z, och det finns ingen garanti för att investeringarna kommer att vara lönsamma eller att andra investeringar som görs i framtiden kommer att ha liknande egenskaper eller resultat. En lista över investeringar gjorda av fonder som förvaltas av Andreessen Horowitz (exklusive investeringar för vilka emittenten inte har gett tillstånd för a16z att offentliggöra såväl som oanmälda investeringar i börsnoterade digitala tillgångar) finns tillgänglig på https://a16z.com/investments /.

Diagram och grafer som tillhandahålls i är endast i informationssyfte och bör inte litas på när man fattar investeringsbeslut. Tidigare resultat är inte en indikation på framtida resultat. Innehållet talar endast från det angivna datumet. Alla prognoser, uppskattningar, prognoser, mål, framtidsutsikter och/eller åsikter som uttrycks i detta material kan ändras utan föregående meddelande och kan skilja sig åt eller strida mot åsikter som uttrycks av andra. Se https://a16z.com/disclosures för ytterligare viktig information