Helios bauen: Völlig vertrauenswürdiger Zugang zu Ethereum

Einer der Hauptgründe, warum wir Blockchains verwenden, ist Vertrauenslosigkeit. Dieses Eigentum verspricht uns einen selbstsouveränen Zugriff auf unser Vermögen und unsere Daten. Zum größten Teil haben Blockchains wie Ethereum dieses Versprechen eingelöst – unsere Vermögenswerte gehören wirklich uns. 

Es gibt jedoch Zugeständnisse, die wir aus Gründen der Bequemlichkeit gemacht haben. Ein solcher Bereich ist unsere Verwendung von zentralisierten RPC-Servern (Remote Procedure Call). Benutzer greifen in der Regel über zentralisierte Anbieter wie Alchemy auf Ethereum zu. Diese Unternehmen betreiben Hochleistungsknoten auf Cloud-Servern, damit andere problemlos auf Kettendaten zugreifen können. Wenn ein Wallet seine Token-Salden abfragt oder prüft, ob eine ausstehende Transaktion in einen Block aufgenommen wurde, geschieht dies fast immer über einen dieser zentralisierten Anbieter. 

Das Problem mit dem bestehenden System besteht darin, dass Benutzer den Anbietern vertrauen müssen und es keine Möglichkeit gibt, die Korrektheit ihrer Anfragen zu überprüfen.

Enter Helios, ein von uns entwickelter Rust-basierter Ethereum-Light-Client, der einen vollständig vertrauenswürdigen Zugriff auf Ethereum bietet. Helios – das das Light-Client-Protokoll von Ethereum verwendet, das durch die ermöglicht wird letzten Schalter zu Nachweis der Beteiligung — Konvertiert Daten von einem nicht vertrauenswürdigen zentralisierten RPC-Anbieter in einen nachweislich sicheren, lokalen RPC. Helios arbeitet mit zentralisierten RPCs zusammen, um es zu ermöglichen, ihre Authentizität zu überprüfen, ohne einen vollständigen Knoten auszuführen. 

Der Kompromiss zwischen Portabilität und Dezentralisierung ist ein häufiger Schmerzpunkt, aber unser Client – ​​den wir der Öffentlichkeit zur Verfügung gestellt haben, um darauf aufzubauen und mehr – synchronisiert in etwa zwei Sekunden, benötigt keinen Speicherplatz und ermöglicht Benutzern den Zugriff auf sichere Kettendaten jedes Gerät (einschließlich Mobiltelefone und Browsererweiterungen). Aber was sind die potenziellen Fallstricke, wenn man sich auf eine zentralisierte Infrastruktur verlässt? Wir behandeln in diesem Beitrag, wie sie sich auswirken könnten, gehen unsere Designentscheidungen durch und skizzieren auch einige Ideen, die andere dazu beitragen können Codebasis.

Die Fallstricke der zentralisierten Infrastruktur: theoretische Kreaturen im „dunklen Wald“ von Ethereum

Eine (theoretische) Kreatur lauert in der dunkler Wald. Dieser jagt nicht im Mempool von Ethereum nach seiner Beute, sondern stellt seine Fallen auf, indem er die zentralisierte Infrastruktur nachahmt, auf die wir uns verlassen. Die Nutzer, die in diese Falle geraten, machen keinen Fehler: Sie besuchen ihre bevorzugte dezentrale Börse, stellen eine vernünftige Slippage-Toleranz ein und kaufen und verkaufen Token wie gewohnt… Sie machen alles richtig, fallen aber trotzdem einer neuen Art von Token zum Opfer Sandwich-Angriff, eine Falle, die akribisch am Eingang zum dunklen Wald von Ethereum aufgestellt wurde: RPC-Anbieter.

Bevor wir näher darauf eingehen, schauen wir uns an, wie Trades an dezentralisierten Börsen funktionieren. Wenn Benutzer eine Swap-Transaktion senden, geben sie dem Smart Contract mehrere Parameter an – welche Token getauscht werden sollen, den Swap-Betrag und vor allem die Mindestanzahl an Token, die ein Benutzer erhalten muss, damit die Transaktion durchgeführt werden kann. Dieser letzte Parameter gibt an, dass der Swap eine „Mindestausgabe“ erfüllen oder zurückkehren muss. Dies wird oft als „Slippage-Toleranz“ bezeichnet, da es effektiv die maximale Preisänderung festlegt, die zwischen dem Senden der Transaktion an den Mempool und der Aufnahme in einen Block auftreten kann. Wenn dieser Parameter zu niedrig eingestellt ist, nimmt der Benutzer die Möglichkeit in Kauf, weniger Token zu erhalten. Diese Situation kann auch zu einem Sandwich-Angriff führen, bei dem ein Angreifer das Gebot effektiv zwischen zwei böswilligen Swaps einbettet. Die Swaps treiben den Kassapreis in die Höhe und zwingen den Trade des Benutzers, zu einem weniger günstigen Preis ausgeführt zu werden. Der Angreifer verkauft dann sofort, um einen kleinen Gewinn zu erzielen.

Solange dieser minimale Ausgabeparameter in der Nähe des fairen Werts eingestellt ist, sind Sie vor Sandwich-Angriffen sicher. Aber was ist, wenn Ihr RPC-Anbieter kein genaues Preisangebot aus dem Smart Contract für die dezentrale Börse bereitstellt? Ein Benutzer kann dann dazu verleitet werden, eine Swap-Transaktion mit einem niedrigeren minimalen Ausgabeparameter zu signieren, und sendet die Transaktion zu allem Übel direkt an den böswilligen RPC-Anbieter. Anstatt diese Transaktion an den öffentlichen Mempool zu senden, wo Dutzende von Bots um die Ausführung des Sandwich-Angriffs konkurrieren, kann der Anbieter sie zurückhalten und das Angriffstransaktionspaket direkt an Flashbots senden, um die Gewinne für sich selbst zu sichern.

Die Hauptursache dieses Angriffs besteht darin, jemand anderem zu vertrauen, den Zustand der Blockchain abzurufen. Erfahrene Benutzer haben dieses Problem traditionell gelöst, indem sie ihre eigenen Ethereum-Knoten betrieben haben – ein zeit- und ressourcenintensives Unterfangen, das zumindest eine ständig online stehende Maschine, Hunderte von Gigabyte Speicherplatz und etwa einen Tag für die Synchronisierung von Grund auf erfordert. Dieser Prozess ist sicherlich einfacher als früher; Gruppen wie Ethereum auf ARM haben unermüdlich daran gearbeitet, Knoten auf kostengünstiger Hardware (z. B. einem Raspberry Pi mit einer daran befestigten externen Festplatte) auszuführen. Aber selbst mit diesen relativ minimalen Anforderungen ist das Betreiben eines Knotens für die meisten Benutzer immer noch schwierig, insbesondere für diejenigen, die mobile Geräte verwenden.

Es ist wichtig zu beachten, dass zentralisierte RPC-Provider-Angriffe, obwohl durchaus plausibel, im Allgemeinen sind einfache Phishing-Angriffe – und das, was wir beschreiben, muss noch passieren. Auch wenn die Erfolgsbilanz größerer Anbieter wie Alchemy uns wenig Grund gibt, daran zu zweifeln, lohnt es sich, weiter zu recherchieren, bevor Sie unbekannte RPC-Anbieter in Ihr Portemonnaie aufnehmen.

Wir stellen Helios vor: völlig vertrauenswürdiger Zugang zu Ethereum

Durch die Einführung seines Light-Client-Protokolls (ermöglicht durch die kürzlich erfolgte Umstellung auf Proof of Stake) eröffnete Ethereum aufregende neue Möglichkeiten für die schnelle Interaktion mit der Blockchain und die Überprüfung von RPC-Endpunkten mit minimalen Hardwareanforderungen. Im Monat seit Die Fusion, haben wir gesehen, wie eine neue Generation von Light-Clients unabhängig voneinander auftaucht (Leitstern, Nimbus, und die JavaScript-basierte Kevlar), die unterschiedliche Ansätze im Dienste desselben Ziels verfolgt haben: effizienter und vertrauenswürdiger Zugriff ohne Verwendung eines vollständigen Knotens.

Unsere Lösung, Helios, ist ein Ethereum-Light-Client, der in etwa zwei Sekunden synchronisiert wird, keinen Speicherplatz benötigt und einen vollständig vertrauenswürdigen Zugriff auf Ethereum bietet. Wie alle Ethereum-Clients besteht Helios aus einer Ausführungsschicht und einer Konsensschicht. Im Gegensatz zu den meisten anderen Clients verbindet Helios beide Ebenen eng miteinander, sodass Benutzer nur eine einzige Software installieren und ausführen müssen. (Erigon bewegt sich ebenfalls in diese Richtung, indem ein Consensus-Layer-Light-Client hinzugefügt wird, der direkt in ihren Archivknoten integriert ist). 

Wie funktioniert es? Die Konsensschicht von Helios verwendet einen zuvor bekannten Beacon-Chain-Blockhash und eine Verbindung zu einem nicht vertrauenswürdigen RPC, um nachweislich mit dem aktuellen Block zu synchronisieren. Die Helios-Ausführungsschicht verwendet diese authentifizierten Beacon-Kettenblöcke zusammen mit einem nicht vertrauenswürdigen Ausführungsschicht-RPC, um willkürliche Informationen über den Kettenstatus wie Kontostände, Vertragsspeicherung, Transaktionsbelege und Smart-Contract-Anrufergebnisse nachzuweisen. Diese Komponenten arbeiten zusammen, um Benutzern einen vollständig vertrauenswürdigen RPC zu bieten, ohne dass ein vollständiger Knoten ausgeführt werden muss.

…Auf der Konsensebene

Der Consensus Layer Light Client entspricht dem Beacon Chain Light Client Spezifikation, und nutzt die Sync-Komitees der Beacon Chain (eingeführt vor dem Merge in der Altair Hard Fork). Das Sync-Komitee ist eine zufällig ausgewählte Teilmenge von 512 Prüfern, die für ~27-Stunden-Zeiträume dienen. 

Wenn ein Validierer Mitglied eines Sync-Komitees ist, signiert er jeden Beacon-Chain-Block-Header, den er sieht. Wenn mehr als zwei Drittel des Komitees einen bestimmten Block-Header signieren, ist es sehr wahrscheinlich, dass sich dieser Block in der kanonischen Beacon-Kette befindet. Wenn Helios die Zusammensetzung des aktuellen Sync-Komitees kennt, kann es den Kopf der Kette zuverlässig verfolgen, indem es einen nicht vertrauenswürdigen RPC nach der neuesten Signatur des Sync-Komitees fragt. 

Danke BLS Stempel, Unterschrift Aggregation ist nur eine einzige Prüfung erforderlich, um den neuen Header zu validieren. Wenn die Unterschrift gültig ist und von mehr als zwei Dritteln des Komitees unterzeichnet wurde, kann man davon ausgehen, dass der Block in die Kette aufgenommen wurde (natürlich kann er aus der Kette reorganisiert werden, aber die Endgültigkeit des Tracking-Blocks kann sorgen strengere Garantien).

Es gibt jedoch ein offensichtlich fehlendes Stück in dieser Strategie: wie man das aktuelle Sync-Komitee findet. Dies beginnt mit dem Erwerb einer Vertrauenswurzel, die als „Root of Trust“ bezeichnet wird Schwacher Subjektivitäts-Checkpoint. Lassen Sie sich von dem Namen nicht einschüchtern – er bedeutet nur einen alten Blockhash, von dem wir garantieren können, dass er irgendwann in der Vergangenheit in die Kette aufgenommen wurde. Es gibt eine interessante Mathematik hinter dem genauen Alter des Kontrollpunkts; Die Worst-Case-Analyse geht von etwa zwei Wochen aus, während praktischere Schätzungen von vielen Monaten ausgehen. 

Wenn der Kontrollpunkt zu alt ist, gibt es Theoretische Angriffe das kann Knoten dazu verleiten, der falschen Kette zu folgen. Das Erfassen eines schwachen Subjektivitätsprüfpunkts ist für das Protokoll außerhalb des Bandes. Unser Ansatz mit Helios bietet einen anfänglichen Checkpoint, der fest in die Codebasis einprogrammiert ist (der leicht überschrieben werden kann); Anschließend speichert es den zuletzt fertiggestellten Blockhash lokal, um es in Zukunft als Prüfpunkt zu verwenden, wenn der Knoten synchronisiert wird. 

Praktischerweise können Beacon-Kettenblöcke gehasht werden, um einen einzigartigen Beacon-Blockhash zu erzeugen. Dies bedeutet, dass es einfach ist, einen Knoten nach einem vollständigen Beacon-Block zu fragen und dann zu beweisen, dass der Blockinhalt gültig ist, indem er gehasht und mit einem bekannten Blockhash verglichen wird. Helios verwendet diese Eigenschaft, um bestimmte Felder innerhalb des Prüfpunktblocks für schwache Subjektivität abzurufen und zu prüfen, darunter zwei sehr wichtige Felder: das aktuelle Sync-Komitee und das nächste Sync-Komitee. Entscheidend ist, dass dieser Mechanismus leichten Clients ermöglicht, schnell durch die Geschichte der Blockchain vorzuspulen.

Jetzt, da wir einen schwachen Subjektivitäts-Checkpoint haben, können wir das aktuelle und das nächste Sync-Komitee abrufen und überprüfen. Wenn sich der aktuelle Kettenkopf innerhalb der gleichen Sync-Committee-Periode wie der Prüfpunkt befindet, beginnen wir sofort mit der Überprüfung neuer Blöcke mit den signierten Sync-Committee-Headern. Wenn unser Kontrollpunkt mehrere Sync-Komitees hinter sich hat, können wir:

1. Verwenden Sie das nächste Synchronisierungskomitee nach unserem Kontrollpunkt, um einen Block abzurufen und zu verifizieren, der in der Zukunft von einem Synchronisierungskomitee stammt.
2. Verwenden Sie diesen neuen Block, um das neue Komitee für die nächste Synchronisierung abzurufen.
3. Wenn Sie immer noch im Rückstand sind, kehren Sie zu Schritt 1 zurück.

Jede Iteration dieses Prozesses ermöglicht es uns, schnell durch 27 Stunden der Geschichte der Kette vorzuspulen, mit einem beliebigen Blockhash in der Vergangenheit zu beginnen und mit dem aktuellen Blockhash zu synchronisieren.

…Auf der Ausführungsebene

Das Ziel des Ausführungsschicht-Light-Clients besteht darin, Beacon-Block-Header zu nehmen, die von der Konsensschicht verifiziert wurden, und sie zusammen mit einem nicht vertrauenswürdigen Ausführungsschicht-RPC zu verwenden, um verifizierte Ausführungsschichtdaten bereitzustellen. Auf diese Daten kann dann über einen RPC-Server zugegriffen werden, der lokal von Helios gehostet wird.

Hier ist ein einfaches Beispiel für das Abrufen eines Kontostands, beginnend mit einer kurzen Einführung, wie der Status in Ethereum gespeichert wird. Jedes Konto enthält einige Felder, wie z. B. Vertragscode-Hash, Nonce, Speicher-Hash und Saldo. Diese Konten werden in einem großen, modifizierten gespeichert Merkle-Patricia-Baum Zustandsbaum genannt. Wenn wir die Wurzel des Zustandsbaums kennen, können wir validieren Merkle Beweise um die Existenz (oder den Ausschluss) eines Kontos innerhalb des Baums zu beweisen. Diese Beweise sind praktisch unmöglich zu fälschen.

Helios hat einen authentifizierten Zustandsstamm aus der Konsensschicht. Verwenden Sie diese Wurzel und merkle proof Anfragen an die nicht vertrauenswürdige Ausführungsschicht RPC, kann Helios alle auf Ethereum gespeicherten Daten lokal verifizieren.

Wir wenden verschiedene Techniken an, um alle Arten von Daten zu überprüfen, die von der Ausführungsschicht verwendet werden. Wenn sie zusammen verwendet werden, können wir alle Daten authentifizieren, die von dem nicht vertrauenswürdigen RPC abgerufen werden. Während ein nicht vertrauenswürdiger RPC den Zugriff auf Daten verweigern kann, kann er uns keine falschen Ergebnisse mehr liefern.

Mit Helios in freier Wildbahn

Der Kompromiss zwischen Portabilität und Dezentralisierung ist ein häufiger Schmerzpunkt – aber da Helios so leichtgewichtig ist, können Benutzer von jedem Gerät (einschließlich Mobiltelefonen und Browsererweiterungen) auf sichere Kettendaten zugreifen. Die Möglichkeit, Helios überall auszuführen, ermöglicht mehr Menschen den Zugriff auf vertrauenswürdige Ethereum-Daten, unabhängig von ihrer Hardware. Dies bedeutet, dass Benutzer Helios als ihren RPC-Anbieter in MetaMask verwenden und ohne weitere Änderungen vertrauensvoll auf Dapps zugreifen können. 

Darüber hinaus macht es die Unterstützung von Rust für WebAssembly App-Entwicklern leicht möglich, Helios in Javascript-Anwendungen (wie Wallets und Dapps) einzubetten. Diese Integrationen würden Ethereum sicherer machen und unsere Notwendigkeit verringern, einer zentralisierten Infrastruktur zu vertrauen.

Wir können es kaum erwarten zu sehen, was sich die Community einfallen lässt. Aber in der Zwischenzeit gibt es viele Möglichkeiten, zu Helios beizutragen – wenn Sie nicht daran interessiert sind, zur Codebasis beizutragen, können Sie auch Software entwickeln, die Helios integriert, um seine Vorteile zu nutzen. Dies sind nur einige der Ideen, auf die wir uns freuen:

• Unterstützung für das Abrufen von Light-Client-Daten direkt aus dem P2P-Netzwerk statt über RPC
• Implementieren Sie einige der fehlenden RPC-Methoden
• Erstellen Sie eine Version von Helios, die zu WebAssembly kompiliert wird
• Integrieren Sie Helios direkt in die Wallet-Software
• Erstellen Sie ein Web-Dashboard, um Ihre Token-Salden anzuzeigen, die Daten von Helios abrufen, die mit WebAssembly in die Website eingebettet sind
• Implementieren Sie die Engine-API, damit die Consensus-Schicht von Helios mit einem vorhandenen Vollknoten der Ausführungsschicht verbunden werden kann

Sehen Sie sich die Codebasis an Um loszulegen – wir freuen uns über Ihre Fehlerberichte, Feature-Anfragen und Ihren Code. Und wenn Sie etwas mehr bauen, teilen Sie es uns mit Twitter, Telegram, oder Farcaster @a16zcrypto.

***
Die hier geäußerten Ansichten sind die der einzelnen zitierten Mitarbeiter von AH Capital Management, LLC („a16z“) und nicht die Ansichten von a16z oder seinen verbundenen Unternehmen. Bestimmte hierin enthaltene Informationen stammen aus Drittquellen, einschließlich von Portfoliounternehmen von Fonds, die von a16z verwaltet werden. Obwohl sie aus als zuverlässig erachteten Quellen stammen, hat a16z solche Informationen nicht unabhängig überprüft und macht keine Zusicherungen über die aktuelle oder dauerhafte Genauigkeit der Informationen oder ihre Angemessenheit für eine bestimmte Situation. Darüber hinaus kann dieser Inhalt Werbung von Drittanbietern enthalten; a16z hat solche Anzeigen nicht überprüft und unterstützt keine darin enthaltenen Werbeinhalte.

Dieser Inhalt wird nur zu Informationszwecken bereitgestellt und sollte nicht als Rechts-, Geschäfts-, Anlage- oder Steuerberatung angesehen werden. Sie sollten diesbezüglich Ihre eigenen Berater konsultieren. Verweise auf Wertpapiere oder digitale Vermögenswerte dienen nur der Veranschaulichung und stellen keine Anlageempfehlung oder ein Angebot zur Erbringung von Anlageberatungsdiensten dar. Darüber hinaus richtet sich dieser Inhalt nicht an Anleger oder potenzielle Anleger und ist nicht für die Verwendung durch diese bestimmt, und es darf unter keinen Umständen darauf vertraut werden, wenn eine Entscheidung getroffen wird, in einen von a16z verwalteten Fonds zu investieren. (Ein Angebot zur Investition in einen a16z-Fonds wird nur durch das Privatplatzierungsmemorandum, den Zeichnungsvertrag und andere relevante Unterlagen eines solchen Fonds abgegeben und sollte vollständig gelesen werden.) Alle erwähnten, erwähnten oder erwähnten Investitionen oder Portfoliounternehmen oder Portfoliounternehmen Die beschriebenen Investitionen sind nicht repräsentativ für alle Investitionen in von a16z verwaltete Vehikel, und es kann nicht garantiert werden, dass die Investitionen rentabel sind oder dass andere Investitionen in der Zukunft ähnliche Merkmale oder Ergebnisse aufweisen werden. Eine Liste der Investitionen von Fonds, die von Andreessen Horowitz verwaltet werden (mit Ausnahme von Investitionen, für die der Emittent a16z keine Genehmigung zur öffentlichen Offenlegung erteilt hat, sowie unangekündigte Investitionen in öffentlich gehandelte digitale Vermögenswerte) ist unter https://a16z.com/investments verfügbar /.

Die darin bereitgestellten Diagramme und Grafiken dienen ausschließlich zu Informationszwecken und sollten bei Anlageentscheidungen nicht als verlässlich angesehen werden. Die Wertentwicklung in der Vergangenheit ist kein Hinweis auf zukünftige Ergebnisse. Der Inhalt spricht nur zum angegebenen Datum. Alle Prognosen, Schätzungen, Prognosen, Ziele, Aussichten und/oder Meinungen, die in diesen Materialien geäußert werden, können ohne Vorankündigung geändert werden und können von den Meinungen anderer abweichen oder ihnen widersprechen. Weitere wichtige Informationen finden Sie unter https://a16z.com/disclosures