Building Helios: Fullstendig tillitsløs tilgang til Ethereum

En av hovedgrunnene til at vi bruker blokkjeder er tillitsløshet. Denne eiendommen lover å gi oss selvsuveren tilgang til vår rikdom og data. For det meste har blokkjeder som Ethereum innfridd dette løftet - våre eiendeler er virkelig våre. 

Det er imidlertid innrømmelser vi har gjort for enkelhets skyld. Et slikt område er i vår bruk av sentraliserte RPC (remote procedure call) servere. Brukere får vanligvis tilgang til Ethereum gjennom sentraliserte leverandører som Alchemy. Disse selskapene kjører noder med høy ytelse på skyservere slik at andre enkelt kan få tilgang til kjededata. Når en lommebok spør etter tokensaldoene sine eller sjekker om en ventende transaksjon er inkludert i en blokk, gjør den det nesten alltid gjennom en av disse sentraliserte leverandørene. 

Problemet med det eksisterende systemet er at brukerne må stole på leverandørene, og det er ingen måte å verifisere riktigheten av forespørslene deres.

Enter Helios, en rustbasert Ethereum light-klient vi utviklet som gir fullstendig tillitsløs tilgang til Ethereum. Helios — som bruker Ethereums lette klientprotokoll, muliggjort av nylig bytte til bevis på innsatsen — konverterer data fra en upålitelig sentralisert RPC-leverandør til en verifiserbart sikker, lokal RPC. Helios jobber sammen med sentraliserte RPC-er for å gjøre det mulig å verifisere deres autentisitet uten å kjøre en full node. 

Avveiningen mellom portabilitet og desentralisering er et vanlig smertepunkt, men klienten vår – som vi har gjort tilgjengelig for publikum å bygge videre på og mer – synkroniseres på rundt to sekunder, krever ingen lagring og lar brukere få tilgang til sikre kjededata fra alle enheter (inkludert mobiltelefoner og nettleserutvidelser). Men hva er de potensielle fallgruvene ved å stole på sentralisert infrastruktur? Vi dekker hvordan de kan utspille seg i dette innlegget, går gjennom designbeslutningene våre, og skisserer også noen ideer som andre kan bidra til kodebase.

Fallgruvene til sentralisert infrastruktur: teoretiske skapninger i Ethereums "mørke skog"

En (teoretisk) skapning lurer i mørk skog. Denne jakter ikke på byttet sitt i Ethereum-mempoolen, men setter i stedet fellene sine ved å etterligne sentralisert infrastruktur som vi har kommet til å stole på. Brukerne som blir fanget i denne fellen gjør ingen feil: De besøker sin favoritt desentraliserte børs, setter en rimelig glidetoleranse, og kjøper og selger tokens som vanlig... De gjør alt riktig, men blir likevel ofre for en ny type sandwich-angrep, en felle omhyggelig satt ved inngangen til Ethereums mørke skog: RPC-leverandører.

Før vi utdyper, la oss se på hvordan handler fungerer på desentraliserte børser. Når brukere sender en byttetransaksjon, gir de flere parametere til den smarte kontrakten – hvilke tokens som skal byttes, byttebeløpet og viktigst av alt, minimumsantallet tokens en bruker må motta for at transaksjonen skal gå gjennom. Denne siste parameteren spesifiserer at byttet må tilfredsstille en "minimumsutgang" eller gå tilbake. Dette er ofte kjent som "slippage tolerance", da det effektivt setter den maksimale prisendringen som kan oppstå mellom når transaksjonen sendes til mempoolen og når den er inkludert i en blokk. Hvis denne parameteren er satt for lavt, aksepterer brukeren muligheten for å motta færre tokens. Denne situasjonen kan også føre til et sandwich-angrep, der en angriper effektivt legger budet mellom to ondsinnede bytter. Swappene driver opp spotprisen og tvinger brukerens handel til å gjennomføres til en mindre gunstig pris. Angriperen selger deretter umiddelbart for å samle inn en liten fortjeneste.

Så lenge denne minste utgangsparameteren er satt nær virkelig verdi, er du trygg mot sandwich-angrep. Men hva om RPC-leverandøren din ikke gir et nøyaktig pristilbud fra den desentraliserte utvekslingssmartkontrakten? En bruker kan deretter bli lurt til å signere en byttetransaksjon med en lavere minimumsutgangsparameter, og for å gjøre vondt verre sende transaksjonen rett til den ondsinnede RPC-leverandøren. I stedet for å kringkaste denne transaksjonen til den offentlige mempoolen, hvor dusinvis av roboter konkurrerer om å utføre sandwich-angrepet, kan leverandøren holde tilbake det og sende angrepstransaksjonspakken direkte til Flashbots, og sikre profitten for seg selv.

Grunnårsaken til dette angrepet er å stole på at noen andre henter tilstanden til blokkjeden. Erfarne brukere har tradisjonelt løst dette problemet ved å kjøre sine egne Ethereum-noder – en tids- og ressurskrevende innsats som i det minste krever en konstant online maskin, hundrevis av gigabyte lagringsplass og rundt en dag for å synkronisere fra bunnen av. Denne prosessen er absolutt enklere enn den pleide å være; grupper som Ethereum på ARM har jobbet utrettelig for å gjøre det mulig å kjøre noder på lavkostmaskinvare (som en Raspberry Pi med en ekstern harddisk festet til). Men selv med disse relativt minimale kravene, er det fortsatt vanskelig å kjøre en node for de fleste brukere, spesielt for de som bruker mobile enheter.

Det er viktig å merke seg at angrep fra sentraliserte RPC-leverandører, selv om de er helt plausible, generelt er enkle phishing-angrep — og den vi beskriver har ennå ikke skjedd. Selv om sporrekordene til større leverandører som Alchemy gir oss liten grunn til å tvile på dem, er det verdt å gjøre litt mer forskning før du legger til ukjente RPC-leverandører i lommeboken din.

Vi introduserer Helios: fullstendig tillitsløs tilgang til Ethereum

Ved å introdusere sin lette klientprotokoll (gjort mulig av den nylige overgangen til Proof of Stake), åpnet Ethereum spennende nye muligheter for raskt å samhandle med blokkjeden og verifisere RPC-endepunkter med minimale maskinvarekrav. I måneden siden Sammenslåingen, vi har sett en ny mengde lette klienter dukke opp uavhengig av hverandre (Lodestar, Nimbus, og den JavaScript-baserte Kevlar) som har tatt forskjellige tilnærminger i tjeneste for samme mål: effektiv og tillitsløs tilgang, uten å bruke en full node.

Løsningen vår, Helios, er en Ethereum light-klient som synkroniserer på rundt to sekunder, krever ingen lagring og gir fullstendig tillitsløs tilgang til Ethereum. Som alle Ethereum-klienter består Helios av et utførelseslag og et konsensuslag. I motsetning til de fleste andre klienter, kobler Helios tett sammen begge lagene slik at brukerne bare trenger å installere og kjøre ett enkelt stykke programvare. (Erigon beveger seg i denne retningen også ved å legge til en konsensuslagslysklient innebygd direkte i arkivnoden deres). 

Så hvordan fungerer det? Helios-konsensuslaget bruker en tidligere kjent beacon chain blockhash og en tilkobling til en uklarert RPC for å verifiserbart synkronisere med gjeldende blokk. Helios-utførelseslaget bruker disse autentiserte beacon-kjedeblokkene i tandem med en ikke-klarert utførelseslags RPC for å bevise vilkårlig informasjon om kjedetilstanden som kontosaldo, kontraktlagring, transaksjonskvitteringer og smarte kontraktanropsresultater. Disse komponentene fungerer sammen for å betjene brukere en fullstendig pålitelig RPC, uten å måtte kjøre en full node.

…På konsensuslaget

Konsensuslagslysklienten samsvarer med lysklienten for beacon chain spesifikasjon, og benytter seg av beacon-kjedens synkroniseringskomiteer (introdusert i forkant av Merge in the Altair hard fork). Synkroniseringskomiteen er en tilfeldig valgt undergruppe av 512 validatorer som fungerer i ~27-timers perioder. 

Når en validator er i en synkroniseringskomité, signerer de hver beacon-kjedeblokkoverskrift de ser. Hvis mer enn to tredjedeler av komiteen signerer en gitt blokkoverskrift, er det høyst sannsynlig at den blokken er i den kanoniske beacon-kjeden. Hvis Helios kjenner sammensetningen av den nåværende synkroniseringskomiteen, kan den trygt spore lederen av kjeden ved å be en upålitelig RPC om den siste synkroniseringskomiteens signatur. 

Takk til BLS signatur aggregering, er det bare nødvendig med en enkelt sjekk for å validere den nye overskriften. Hvis signaturen er gyldig og har blitt signert av mer enn to tredjedeler av komiteen, er det trygt å anta at blokken ble inkludert i kjeden (selvfølgelig kan den omorganiseres ut av kjeden, men sporingsblokkens endelighet kan gi strengere garantier).

Det er imidlertid en åpenbar manglende brikke i denne strategien: hvordan finne den nåværende synkroniseringskomiteen. Dette starter med å skaffe seg en rot av tillit kalt svakt subjektivitetskontrollpunkt. Ikke la navnet skremme deg - det betyr bare en gammel blockhash som vi kan garantere at var inkludert i kjeden på et tidspunkt i fortiden. Det er noe interessant matematikk bak nøyaktig hvor gammel sjekkpunktet kan være; Worst-case-analyse antyder rundt to uker, mens mer praktiske estimater antyder mange måneder. 

Hvis sjekkpunktet er for gammelt, er det det teoretiske angrep som kan lure noder til å følge feil kjede. Å anskaffe et svakt subjektivitetskontrollpunkt er utenfor båndet for protokollen. Vår tilnærming med Helios gir et innledende sjekkpunkt hardkodet inn i kodebasen (som enkelt kan overstyres); den lagrer deretter den siste ferdigstilte blockhashen lokalt for bruk som sjekkpunkt i fremtiden, når noden synkroniseres. 

Beleilig kan beacon chain blokker hashes for å produsere en unik beacon blockhash. Dette betyr at det er enkelt å be en node om en full beacon-blokk, og deretter bevise at blokkinnholdet er gyldig ved å hashe det og sammenligne med en kjent blockhash. Helios bruker denne egenskapen til å hente og bevise visse felt innenfor den svake subjektivitetssjekkpunktblokken, inkludert to svært viktige felt: den nåværende synkroniseringskomiteen og den neste synkroniseringskomiteen. Kritisk nok lar denne mekanismen lette klienter spole fremover gjennom blokkjedens historie.

Nå som vi har et svakt subjektivitetskontrollpunkt, kan vi hente og verifisere de nåværende og neste synkroniseringskomiteene. Hvis det nåværende kjedehodet er innenfor samme synkroniseringskomitéperiode som sjekkpunktet, begynner vi umiddelbart å bekrefte nye blokker med de signerte synkroniseringskomitéhodene. Hvis sjekkpunktet vårt er flere synkroniseringskomiteer bak, kan vi:

1. Bruk neste synkroniseringskomité etter sjekkpunktet vårt for å hente og bekrefte en blokkering som kommer fra én synkroniseringskomité i fremtiden.
2. Bruk denne nye blokken til å hente den nye neste synkroniseringskomiteen.
3. Hvis du fortsatt er bak, gå tilbake til trinn 1.

Hver iterasjon av denne prosessen lar oss spole fremover gjennom 27 timer av kjedens historie, starte med hvilken som helst blockhash i fortiden og synkronisere med gjeldende blockhash.

…På utførelseslaget

Målet med execution layer light-klienten er å ta beacon block headers som er verifisert av konsensuslaget, og bruke dem sammen med en ikke-klarert execution layer RPC for å gi verifiserte execution layer data. Disse dataene kan deretter nås via en RPC-server som er lokalt hostet av Helios.

Her er et enkelt eksempel på å hente en kontos saldo, og starter med en rask primer om hvordan staten lagres i Ethereum. Hver konto inneholder et par felt, for eksempel kontraktkodehash, nonce, storage-hash og saldo. Disse kontoene er lagret i en stor, modifisert Merkle-Patricia tre kalt statstreet. Hvis vi kjenner roten til statstreet, kan vi validere merkle bevis for å bevise eksistensen (eller ekskluderingen) av en konto i treet. Disse bevisene er faktisk umulige å forfalske.

Helios har en autentisert tilstandsrot fra konsensuslaget. Bruker denne roten og merkle proof forespørsler til det uklarerte utførelseslaget RPC, kan Helios lokalt verifisere alle data som er lagret på Ethereum.

Vi bruker forskjellige teknikker for å verifisere alle slags data som brukes av utførelseslaget; brukt sammen, lar disse oss autentisere alle data hentet fra den uklarerte RPC-en. Selv om en uklarert RPC kan nekte tilgang til data, kan den ikke lenger gi oss feil resultater.

Bruker Helios i naturen

Avveiningen mellom portabilitet og desentralisering er et vanlig smertepunkt - men siden Helios er så lett, kan brukere få tilgang til sikre kjededata fra alle enheter (inkludert mobiltelefoner og nettleserutvidelser). Muligheten til å kjøre Helios hvor som helst gjør det mulig for flere mennesker å få tilgang til pålitelige Ethereum-data, uavhengig av maskinvaren deres. Dette betyr at brukere kan bruke Helios som RPC-leverandør i MetaMask, og har tillitsløst tilgang til dapps uten andre endringer. 

Videre gjør Rusts støtte for WebAssembly det enkelt mulig for apputviklere å bygge inn Helios i Javascript-applikasjoner (som lommebøker og dapps). Disse integrasjonene vil gjøre Ethereum tryggere, og redusere vårt behov for å stole på sentralisert infrastruktur.

Vi gleder oss til å se hva samfunnet finner på. Men i mellomtiden er det mange måter å bidra til Helios - hvis du ikke er interessert i å bidra til kodebasen, kan du også bygge programvare som integrerer Helios for å dra nytte av fordelene. Dette er bare noen av ideene vi er begeistret for:

• Støtte for å hente lette klientdata direkte fra P2P-nettverket i stedet for via RPC
• Implementer noen av de manglende RPC-metodene
• Bygg en versjon av Helios som kompileres til WebAssembly
• Integrer Helios direkte i lommebokprogramvaren
• Bygg et nettdashbord for å se token-saldoene dine som henter data fra Helios innebygd i nettstedet med WebAssembly
• Implementer motor-API slik at Helios' konsensuslag kan kobles til en eksisterende utførelseslag full node

Sjekk ut kodebasen for å komme i gang – vi ønsker dine feilrapporter, funksjonsforespørsler og kode velkommen. Og hvis du bygger noe mer, del det med oss ​​videre Twitter, Telegram, eller Farcaster @a16zcrypto.

***
Synspunktene som er uttrykt her, er de fra individuelle AH Capital Management, LLC (“a16z”) personell som er sitert og er ikke synspunktene til a16z eller dets tilknyttede selskaper. Visse opplysninger her er innhentet fra tredjepartskilder, inkludert fra porteføljeselskaper av fond forvaltet av a16z. Selv om a16z er hentet fra kilder som antas å være pålitelige, har ikke a16z uavhengig verifisert slik informasjon og gir ingen representasjoner om den nåværende eller varige nøyaktigheten til informasjonen eller dens hensiktsmessighet for en gitt situasjon. I tillegg kan dette innholdet inkludere tredjepartsannonser; aXNUMXz har ikke vurdert slike annonser og støtter ikke noe reklameinnhold som finnes deri.

Dette innholdet er kun gitt for informasjonsformål, og bør ikke stoles på som juridisk, forretningsmessig, investerings- eller skatterådgivning. Du bør rådføre deg med dine egne rådgivere om disse sakene. Referanser til verdipapirer eller digitale eiendeler er kun for illustrasjonsformål, og utgjør ikke en investeringsanbefaling eller tilbud om å tilby investeringsrådgivningstjenester. Videre er dette innholdet ikke rettet mot eller ment for bruk av noen investorer eller potensielle investorer, og kan ikke under noen omstendigheter stoles på når du tar en beslutning om å investere i et fond som forvaltes av a16z. (Et tilbud om å investere i et a16z-fond vil kun gis av det private emisjonsmemorandumet, tegningsavtalen og annen relevant dokumentasjon for et slikt fond og bør leses i sin helhet.) Eventuelle investeringer eller porteføljeselskaper nevnt, referert til, eller beskrevet er ikke representative for alle investeringer i kjøretøy forvaltet av a16z, og det kan ikke gis noen garanti for at investeringene vil være lønnsomme eller at andre investeringer som gjøres i fremtiden vil ha lignende egenskaper eller resultater. En liste over investeringer foretatt av fond forvaltet av Andreessen Horowitz (unntatt investeringer som utstederen ikke har gitt tillatelse til at a16z kan offentliggjøre så vel som uanmeldte investeringer i børsnoterte digitale eiendeler) er tilgjengelig på https://a16z.com/investments /.

Diagrammer og grafer gitt i er kun for informasjonsformål og bør ikke stoles på når du tar investeringsbeslutninger. Tidligere resultater er ikke en indikasjon på fremtidige resultater. Innholdet taler kun fra den angitte datoen. Eventuelle anslag, estimater, prognoser, mål, prospekter og/eller meninger uttrykt i dette materialet kan endres uten varsel og kan avvike eller være i strid med meninger uttrykt av andre. Se https://a16z.com/disclosures for ytterligere viktig informasjon