Building Helios: Fuldstændig tillidsfri adgang til Ethereum

En af hovedårsagerne til, at vi bruger blockchains, er tillidsløshed. Denne ejendom lover at give os selv-suveræn adgang til vores rigdom og data. For det meste har blockchains som Ethereum indfriet dette løfte - vores aktiver er virkelig vores. 

Der er dog indrømmelser, vi har givet for nemheds skyld. Et sådant område er vores brug af centraliserede RPC-servere (remote procedure call). Brugere får typisk adgang til Ethereum gennem centraliserede udbydere som Alchemy. Disse virksomheder kører højtydende noder på cloud-servere, så andre nemt kan få adgang til kædedata. Når en tegnebog forespørger på dens token-saldi eller tjekker, om en afventende transaktion er inkluderet i en blok, gør den det næsten altid gennem en af ​​disse centraliserede udbydere. 

Problemet med det eksisterende system er, at brugerne skal have tillid til udbyderne, og der er ingen måde at verificere rigtigheden af ​​deres forespørgsler.

Indtast Helios, en rustbaseret Ethereum light-klient, vi har udviklet, og som giver fuldstændig tillidsfri adgang til Ethereum. Helios — som bruger Ethereums lette klientprotokol, muliggjort af seneste skifte til bevis for indsatsen — konverterer data fra en upålidelig centraliseret RPC-udbyder til en verificerbart sikker, lokal RPC. Helios arbejder sammen med centraliserede RPC'er for at gøre det muligt at verificere deres ægthed uden at køre en fuld node. 

Afvejningen mellem portabilitet og decentralisering er et almindeligt problem, men vores klient – ​​som vi har gjort tilgængelig for offentligheden til at bygge videre på og mere – synkroniseres på omkring to sekunder, kræver ingen lagring og giver brugerne adgang til sikre kædedata fra enhver enhed (inklusive mobiltelefoner og browserudvidelser). Men hvad er de potentielle faldgruber ved at stole på centraliseret infrastruktur? Vi dækker, hvordan de kan udspille sig i dette indlæg, gennemgår vores designbeslutninger og skitserer også et par ideer, som andre kan bidrage til kodebase.

Faldgruberne ved centraliseret infrastruktur: teoretiske væsner i Ethereums "mørke skov"

Et (teoretisk) væsen lurer i mørk skov. Denne jagter ikke efter sit bytte i Ethereum-mempoolen, men sætter i stedet sine fælder ved at efterligne centraliseret infrastruktur, som vi er kommet til at stole på. De brugere, der bliver fanget i denne fælde, laver ingen fejl: De besøger deres foretrukne decentraliserede børs, indstiller en rimelig glidetolerance og køber og sælger tokens som sædvanligt... De gør alt rigtigt, men bliver stadig ofre for en ny form for sandwich-angreb, en fælde omhyggeligt sat ved selve indgangen til Ethereums mørke skov: RPC-udbydere.

Før vi uddyber, lad os se på, hvordan handler fungerer på decentraliserede børser. Når brugere sender en swap-transaktion, angiver de flere parametre til den smarte kontrakt - hvilke tokens der skal byttes, swap-beløbet og vigtigst af alt, det mindste antal tokens, en bruger skal modtage, for at transaktionen kan gå igennem. Denne sidste parameter specificerer, at swap'en skal opfylde et "minimum output" eller vende tilbage. Dette er ofte kendt som "slipage tolerance", da det effektivt sætter den maksimale prisændring, der kan forekomme mellem, hvornår transaktionen sendes til mempoolen, og når den er inkluderet i en blok. Hvis denne parameter er sat for lavt, accepterer brugeren muligheden for at modtage færre tokens. Denne situation kan også føre til et sandwich-angreb, hvor en angriber effektivt klemmer buddet mellem to ondsindede bytteforhold. Swapsene driver spotprisen op og tvinger brugerens handel til at udføres til en mindre gunstig pris. Angriberen sælger derefter med det samme for at indsamle en lille fortjeneste.

Så længe denne minimale outputparameter er indstillet i nærheden af ​​dagsværdien, er du sikker mod sandwich-angreb. Men hvad hvis din RPC-udbyder ikke giver et præcist pristilbud fra den decentraliserede udvekslings-smart-kontrakt? En bruger kan så blive narret til at underskrive en swap-transaktion med en lavere minimumsoutputparameter, og for at gøre tingene værre sender transaktionen direkte til den ondsindede RPC-udbyder. I stedet for at udsende denne transaktion til den offentlige mempool, hvor snesevis af bots konkurrerer om at udføre sandwich-angrebet, kan udbyderen tilbageholde det og sende angrebstransaktionspakken direkte til Flashbots, hvorved de sikrer sig profitten.

Grundårsagen til dette angreb er at stole på, at en anden kan hente status for blockchain. Erfarne brugere har traditionelt løst dette problem ved at køre deres egne Ethereum-noder - en tids- og ressourcekrævende bestræbelse, der i det mindste kræver en konstant online maskine, hundredvis af gigabyte lagerplads og omkring en dag at synkronisere fra bunden. Denne proces er bestemt nemmere end den plejede at være; grupper som Ethereum på ARM har arbejdet utrætteligt for at gøre det muligt at køre noder på billig hardware (såsom en Raspberry Pi med en ekstern harddisk fastspændt). Men selv med disse relativt minimale krav er det stadig svært for de fleste brugere at køre en node, især for dem, der bruger mobile enheder.

Det er vigtigt at bemærke, at centraliserede RPC-udbyderangreb, selvom de er helt plausible, generelt er simple phishing-angreb - og den, vi beskriver, er endnu ikke sket. Selvom track records fra større udbydere som Alchemy giver os ringe grund til at tvivle på dem, er det værd at gøre noget yderligere research, før du tilføjer ukendte RPC-udbydere til din tegnebog.

Vi introducerer Helios: Fuldstændig tillidsfri adgang til Ethereum

Ved at introducere sin lette klientprotokol (gjort muligt af det nylige skift til Proof of Stake) åbnede Ethereum spændende nye muligheder for hurtigt at interagere med blockchain og verificere RPC-slutpunkter med minimale hardwarekrav. I måneden siden Fusionen, vi har set en ny høst af lysklienter dukke op uafhængigt af hinanden (Lodestar, Nimbus, og den JavaScript-baserede Kevlar), der har taget forskellige tilgange til at tjene det samme mål: effektiv og tillidsfri adgang uden brug af en fuld node.

Vores løsning, Helios, er en Ethereum light-klient, der synkroniserer på omkring to sekunder, kræver ingen lagring og giver fuldstændig tillidsfri adgang til Ethereum. Som alle Ethereum-klienter består Helios af et eksekveringslag og et konsensuslag. I modsætning til de fleste andre klienter forbinder Helios begge lag tæt, så brugerne kun behøver at installere og køre et enkelt stykke software. (Erigon bevæger sig også i denne retning ved at tilføje en konsensuslagslysklient indbygget direkte i deres arkivnode). 

Så hvordan virker det? Helios-konsensuslaget bruger en tidligere kendt beacon chain blockhash og en forbindelse til en upålidelig RPC til verificerbart at synkronisere med den aktuelle blok. Helios-udførelseslaget bruger disse autentificerede beacon-kædeblokke sammen med en upålidelig eksekveringslags RPC til at bevise vilkårlig information om kædetilstanden, såsom kontosaldi, kontraktlagring, transaktionskvitteringer og smarte kontraktopkaldsresultater. Disse komponenter arbejder sammen for at betjene brugerne en fuldstændig tillidsfri RPC, uden at det er nødvendigt at køre en fuld node.

…På konsensuslaget

Konsensus-lag-lysklienten er i overensstemmelse med beacon-kædelysklienten specifikation, og gør brug af beacon-kædens synkroniseringsudvalg (introduceret forud for Merge in the Altair hard fork). Synkroniseringsudvalget er en tilfældigt udvalgt undergruppe af 512 validatorer, der tjener i ~27-timers perioder. 

Når en validator er i en synkroniseringskomité, signerer de hver enkelt beacon-kædeblok-header, som de ser. Hvis mere end to tredjedele af komiteen underskriver en given blokoverskrift, er det højst sandsynligt, at denne blok er i den kanoniske beacon-kæde. Hvis Helios kender sammensætningen af ​​den nuværende synkroniseringskomité, kan den trygt spore lederen af ​​kæden ved at bede en upålidelig RPC om den seneste synkroniseringskomités signatur. 

Tak til BLS signatur aggregering, kræves der kun en enkelt kontrol for at validere den nye header. Hvis signaturen er gyldig og er blevet underskrevet af mere end to-tredjedele af udvalget, er det sikkert at antage, at blokken var inkluderet i kæden (selvfølgelig kan den omorganiseres ud af kæden, men sporingsblok-finaliteten kan give strengere garantier).

Der mangler dog en åbenlys brik i denne strategi: hvordan man finder den nuværende synkroniseringskomité. Dette starter med at erhverve en rod af tillid kaldet svagt subjektivitetskontrolpunkt. Lad ikke navnet skræmme dig – det betyder bare en gammel blokhash, som vi kan garantere, at den var inkluderet i kæden på et tidspunkt tidligere. Der er noget interessant matematik bag præcis, hvor gammel checkpointet kan være; worst case-analyse tyder på omkring to uger, mens mere praktiske skøn tyder på mange måneder. 

Hvis checkpointet er for gammelt, er der teoretiske angreb der kan narre noder til at følge den forkerte kæde. At erhverve et svagt subjektivitetskontrolpunkt er uden for protokollens bånd. Vores tilgang med Helios giver et indledende kontrolpunkt hardkodet ind i kodebasen (som nemt kan tilsidesættes); den gemmer derefter den seneste afsluttede blockhash lokalt til brug som kontrolpunkt i fremtiden, når som helst noden synkroniseres. 

Beacon-kædeblokke kan bekvemt hashes for at producere en unik beacon-blockhash. Det betyder, at det er nemt at bede en node om en fuld beacon-blok og derefter bevise, at blokindholdet er gyldigt ved at hashe det og sammenligne med en kendt blockhash. Helios bruger denne egenskab til at hente og bevise visse felter inde i den svage subjektivitetskontrolpunktblok, inklusive to meget vigtige felter: den nuværende synkroniseringskomité og den næste synkroniseringskomité. Kritisk nok tillader denne mekanisme lette klienter at spole frem gennem blockchains historie.

Nu hvor vi har et svagt subjektivitetskontrolpunkt, kan vi hente og verificere de nuværende og næste synkroniseringsudvalg. Hvis det nuværende kædehoved er inden for samme synkroniseringskomitéperiode som kontrolpunktet, begynder vi straks at verificere nye blokke med de underskrevne synkroniseringskomitéoverskrifter. Hvis vores kontrolpunkt er flere synkroniseringsudvalg bagved, kan vi:

1. Brug den næste synkroniseringskomité efter vores kontrolpunkt til at hente og verificere en blok, der stammer fra én synkroniseringskomité i fremtiden.
2. Brug denne nye blok til at hente den nye næste synkroniseringskomité.
3. Hvis du stadig er bagud, skal du vende tilbage til trin 1.

Hver gentagelse af denne proces giver os mulighed for at spole frem gennem 27 timer af kædens historie, starte med en hvilken som helst blockhash i fortiden og synkronisere med den nuværende blockhash.

…På udførelseslaget

Målet med execution layer light-klienten er at tage beacon block headers, der er verificeret af konsensus laget, og bruge dem sammen med en ikke-pålidelig execution layer RPC til at levere verificerede execution layer data. Disse data kan derefter tilgås via en RPC-server, der er lokalt hostet af Helios.

Her er et simpelt eksempel på at hente en kontos saldo, startende med en hurtig primer om, hvordan staten opbevares i Ethereum. Hver konto indeholder et par felter, såsom kontraktkoden hash, nonce, storage hash og saldo. Disse konti er gemt i en stor, ændret Merkle-Patricia træ kaldet statstræet. Hvis vi kender roden til statstræet, kan vi validere merkle beviser for at bevise eksistensen (eller udelukkelsen) af en konto i træet. Disse beviser er faktisk umulige at forfalske.

Helios har en autentificeret tilstandsrod fra konsensuslaget. Bruger denne rod , merkle proof-anmodninger til det upålidelige eksekveringslag RPC, kan Helios lokalt verificere alle data, der er gemt på Ethereum.

Vi anvender forskellige teknikker til at verificere alle slags data, der bruges af eksekveringslaget; brugt sammen, giver disse os mulighed for at autentificere alle data hentet fra den ikke-pålidelige RPC. Selvom en RPC, der ikke er tillid til, kan nægte adgang til data, kan den ikke længere vise os forkerte resultater.

Brug af Helios i naturen

Afvejningen mellem portabilitet og decentralisering er et almindeligt smertepunkt - men da Helios er så let, kan brugere få adgang til sikre kædedata fra enhver enhed (inklusive mobiltelefoner og browserudvidelser). Evnen til at køre Helios hvor som helst gør det muligt for flere mennesker at få adgang til pålidelige Ethereum-data, uanset deres hardware. Dette betyder, at brugere kan bruge Helios som deres RPC-udbyder i MetaMask og tillidsfrit få adgang til dapps uden andre ændringer. 

Yderligere gør Rusts understøttelse af WebAssembly det nemt muligt for app-udviklere at integrere Helios i Javascript-applikationer (som tegnebøger og dapps). Disse integrationer ville gøre Ethereum sikrere og reducere vores behov for at stole på centraliseret infrastruktur.

Vi kan ikke vente med at se, hvad samfundet finder på. Men i mellemtiden er der masser af måder at bidrage til Helios på - hvis du ikke er interesseret i at bidrage til kodebasen, kan du også bygge software, der integrerer Helios for at drage fordel af dens fordele. Dette er blot nogle få af de ideer, vi er begejstrede for:

• Understøtter hentning af lette klientdata direkte fra P2P-netværket i stedet for via RPC
• Implementer nogle af de manglende RPC-metoder
• Byg en version af Helios, der kompilerer til WebAssembly
• Integrer Helios direkte i tegnebogssoftware
• Byg et web-dashboard for at se dine token-saldi, der henter data fra Helios indlejret på webstedet med WebAssembly
• Implementer motor-API'en, så Helios' konsensuslag kan forbindes til en eksisterende fuld knude for eksekveringslag

Tjek kodebasen for at komme i gang – vi glæder os over dine fejlrapporter, funktionsanmodninger og kode. Og hvis du bygger noget mere, så del det med os videre Twitter, Telegram, eller Farcaster @a16zcrypto.

***
De synspunkter, der er udtrykt her, er dem fra det enkelte AH Capital Management, LLC ("a16z") personale, der er citeret, og er ikke synspunkter fra a16z eller dets tilknyttede selskaber. Visse oplysninger indeholdt heri er indhentet fra tredjepartskilder, herunder fra porteføljeselskaber af fonde forvaltet af a16z. Selvom det er taget fra kilder, der menes at være pålidelige, har a16z ikke uafhængigt verificeret sådanne oplysninger og fremsætter ingen repræsentationer om den aktuelle eller vedvarende nøjagtighed af oplysningerne eller dens passende for en given situation. Derudover kan dette indhold omfatte tredjepartsreklamer; a16z har ikke gennemgået sådanne annoncer og støtter ikke noget reklameindhold indeholdt deri.

Dette indhold er kun givet til informationsformål og bør ikke påberåbes som juridisk, forretningsmæssig, investerings- eller skatterådgivning. Du bør rådføre dig med dine egne rådgivere om disse spørgsmål. Henvisninger til værdipapirer eller digitale aktiver er kun til illustrationsformål og udgør ikke en investeringsanbefaling eller tilbud om at levere investeringsrådgivningstjenester. Ydermere er dette indhold ikke rettet mod eller beregnet til brug af nogen investorer eller potentielle investorer og kan under ingen omstændigheder stoles på, når der træffes en beslutning om at investere i en fond, der administreres af a16z. (Et tilbud om at investere i en a16z-fond vil kun blive givet af private placement-memorandummet, tegningsaftalen og anden relevant dokumentation for en sådan fond og bør læses i deres helhed.) Eventuelle investeringer eller porteføljeselskaber nævnt, refereret til eller beskrevne er ikke repræsentative for alle investeringer i køretøjer, der administreres af a16z, og der kan ikke gives sikkerhed for, at investeringerne vil være rentable, eller at andre investeringer foretaget i fremtiden vil have lignende karakteristika eller resultater. En liste over investeringer foretaget af fonde forvaltet af Andreessen Horowitz (undtagen investeringer, hvortil udstederen ikke har givet tilladelse til, at a16z offentliggør såvel som uanmeldte investeringer i offentligt handlede digitale aktiver) er tilgængelig på https://a16z.com/investments /.

Diagrammer og grafer, der er angivet i, er udelukkende til informationsformål og bør ikke stoles på, når der træffes nogen investeringsbeslutning. Tidligere resultater er ikke vejledende for fremtidige resultater. Indholdet taler kun fra den angivne dato. Alle fremskrivninger, estimater, prognoser, mål, udsigter og/eller meninger udtrykt i disse materialer kan ændres uden varsel og kan afvige fra eller være i modstrid med andres meninger. Se venligst https://a16z.com/disclosures for yderligere vigtige oplysninger