Frage: Sollte Ethereum damit einverstanden sein, mehr Dinge im Protokoll zu verankern?

Ursprünglicher Autor: Vitalik Buterin

Odaily Planet Daily Translator |. Nian Yin Si Tang

Besonderer Dank geht an Justin Drake, Tina Zhen und Yoav Weiss für ihr Feedback und ihre Rezension.

Seit Beginn des Ethereum-Projekts bestand die starke Philosophie darin, den Kern von Ethereum so einfach wie möglich zu gestalten und dies so weit wie möglich durch den Aufbau darauf aufbauender Protokolle zu erreichen. Im Blockchain-Bereich geht es bei der Debatte „auf L1 aufbauen“ vs. „Fokus auf L2“ oft vor allem um die Skalierung, aber tatsächlich gibt es ähnliche Probleme bei der Erfüllung der Bedürfnisse mehrerer Ethereum-Benutzer: Austausch digitaler Vermögenswerte, Datenschutz , Benutzernamen, erweiterte Verschlüsselung, Kontosicherheit, Zensurresistenz, Front-Running-Schutz und mehr. Allerdings gab es in letzter Zeit einige vorsichtige Versuche, mehr dieser Funktionen in das Kernprotokoll von Ethereum zu integrieren.

Dieser Artikel befasst sich mit einigen philosophischen Überlegungen hinter der ursprünglichen Philosophie der minimalen Kapselung sowie mit einigen neueren Denkweisen zu diesen Ideen. Das Ziel besteht darin, mit dem Aufbau eines Frameworks zu beginnen, um mögliche Ziele besser zu identifizieren, bei denen die Kapselung bestimmter Funktionen eine Überlegung wert sein könnte.

Eine frühe Philosophie zum Protokollminimalismus

In der frühen Geschichte dessen, was damals als „Ethereum 2.0“ bekannt war, bestand der starke Wunsch, ein sauberes, einfaches und schönes Protokoll zu schaffen, das möglichst wenig auf sich selbst aufbaute und fast die gesamte Arbeit den Benutzern überließ. Im Idealfall ist das Protokoll nur eine virtuelle Maschine und die Validierung eines Blocks ist nur ein Aufruf einer virtuellen Maschine.

Dies ist eine ungefähre Rekonstruktion des Whiteboard-Diagramms, das Gavin Wood und ich Anfang 2015 gezeichnet haben, als ich darüber sprach, wie Ethereum 2.0 aussehen würde.

Die „Zustandsübergangsfunktion“ (die Funktion, die den Block verarbeitet) ist nur ein einzelner VM-Aufruf, und die gesamte andere Logik erfolgt über Verträge: einige Verträge auf Systemebene, aber hauptsächlich vom Benutzer bereitgestellte Verträge. Ein sehr schönes Merkmal dieses Modells ist, dass sogar ein ganzer Hard Fork als einzelne Transaktion zum Blockprozessorvertrag beschrieben werden kann, die von der Off-Chain- oder On-Chain-Governance genehmigt und dann mit der Ausführungsberechtigung aktualisiert wird.

Diese Diskussionen im Jahr 2015 beziehen sich speziell auf zwei Bereiche, die wir berücksichtigen: Kontoabstraktion und Skalierung. Bei der Skalierung geht es darum, eine maximal abstrakte Form der Skalierung zu schaffen, die sich wie eine natürliche Erweiterung des obigen Diagramms anfühlt. Verträge können Daten abrufen, die von den meisten Ethereum-Knoten nicht gespeichert werden, und das Protokoll erkennt dies und löst den Aufruf über einige sehr allgemeine erweiterte Rechenfunktionen auf. Aus Sicht der virtuellen Maschine wird der Anruf in ein separates Subsystem geleitet und gibt dann einige Zeit später auf magische Weise die richtige Antwort zurück.

Wir haben diese Idee kurz untersucht, sie aber schnell wieder verworfen, weil wir uns zu sehr darauf konzentrierten, zu beweisen, dass jede Art von Blockchain-Skalierung möglich ist. Allerdings bedeutet die Kombination aus Datenverfügbarkeitsstichproben und ZK-EVM, wie wir später sehen werden, dass eine mögliche Zukunft der Ethereum-Skalierung dieser Vision tatsächlich sehr nahe kommt! Bei der Kontoabstraktion hingegen wussten wir von Anfang an, dass eine Art Implementierung möglich war, also begannen wir sofort mit der Forschung und versuchten, dem reinen Ausgangspunkt „Eine Transaktion ist nur ein Anruf“ so nahe wie möglich zu kommen.

Zwischen der Verarbeitung der Transaktion und dem eigentlichen zugrunde liegenden EVM-Aufruf von der Absenderadresse gibt es eine Menge Boilerplate-Code und danach noch mehr Boilerplate-Code. Wie reduzieren wir diesen Code so nahe wie möglich an Null?

Einer der wichtigsten Codeteile ist hier „validate_transaction(state, tx)“, der dafür verantwortlich ist, zu prüfen, ob Nonce und Signatur der Transaktion korrekt sind. Das eigentliche Ziel der Kontoabstraktion bestand von Anfang an darin, Benutzern zu ermöglichen, die grundlegende nicht-inkrementelle Verifizierung und ECDSA-Verifizierung durch ihre eigene Verifizierungslogik zu ersetzen, damit Benutzer Funktionen wie Social Recovery und Multi-Signatur-Wallets einfacher nutzen können. Die Suche nach einer Möglichkeit, apply_transaction in einen einfachen EVM-Aufruf umzustrukturieren, ist also nicht nur eine Aufgabe „Code sauber machen, um Code sauber zu machen“, sondern es geht darum, die Logik in den Kontocode des Benutzers zu verschieben und Benutzern die Flexibilität zu geben, die sie benötigen.

Das Beharren darauf, dass apply_transaction so wenig feste Logik wie möglich enthält, führte jedoch letztendlich zu vielen Herausforderungen. Wir können uns einen der frühesten Vorschläge zur Kontoabstraktion ansehen, EIP-86.

Wenn EIP-86 unverändert enthalten wäre, würde dies die Komplexität der EVM reduzieren, auf Kosten einer massiven Erhöhung der Komplexität anderer Teile des Ethereum-Stacks, was das Schreiben im Wesentlichen des gleichen Codes an anderer Stelle und die Einführung einer völlig neuen Klasse erfordern würde Seltsamerweise kann beispielsweise dieselbe Transaktion mit demselben Hash-Wert mehrmals in der Kette auftreten, ganz zu schweigen von dem Problem der mehrfachen Invalidierung.

Mehrere Ungültigkeitsprobleme bei der Kontoabstraktion. Eine in der Kette enthaltene Transaktion könnte Tausende anderer Transaktionen im Mempool ungültig machen, was es für den Mempool leicht macht, billig gefüllt zu werden.

Seitdem hat sich die Kontoabstraktion schrittweise weiterentwickelt. Aus EIP-86 wurde später EIP-208, und schließlich entstand das praktische EIP-2938.

Allerdings ist EIP-2938 alles andere als minimalistisch. Zu seinen Inhalten gehören:

  • Neuer Transaktionstyp

  • Drei neue globale Variablen für den Transaktionsbereich

  • Zwei neue Opcodes, darunter der sehr umständliche PAYgas-Opcode zur Durchführung von Gaspreis- und Gaslimitprüfungen, als EVM-Ausführungshaltepunkte und zur vorübergehenden Speicherung von ETH zur Bezahlung einmaliger Gebühren

  • Eine komplexe Reihe von Mining- und Rebroadcasting-Strategien, einschließlich einer Liste verbotener Opcodes während der Transaktionsüberprüfungsphase

Um eine Kontoabstraktion zu erreichen, ohne Ethereum-Kernentwickler einzubeziehen (die sich auf die Optimierung von Ethereum-Clients und die Implementierung von Zusammenführungen konzentrieren), wurde EIP-2938 schließlich in ERC-4337 umgestaltet, was völlig außerhalb des Protokolls liegt.

ERC-4337. Es basiert ausschließlich auf EVM-Aufrufen!

Da es sich um einen ERC handelt, ist kein Hard Fork erforderlich und existiert technisch gesehen „außerhalb des Ethereum-Protokolls“. Also...Problem gelöst? Es stellt sich heraus, dass dies nicht der Fall ist. Die aktuelle mittelfristige Roadmap von ERC-4337 sieht tatsächlich vor, große Teile von ERC-4337 letztendlich in eine Reihe von Protokollfunktionen umzuwandeln, was ein nützliches Leitbeispiel dafür ist, warum dieser Weg in Betracht gezogen werden sollte.

Paket ERC-4337

Es werden mehrere Hauptgründe für die eventuelle Wiederaufnahme von ERC-4337 in das Protokoll diskutiert:

  • Gaseffizienz: Jeder innerhalb der EVM ausgeführte Vorgang verursacht einen gewissen Overhead der virtuellen Maschine, einschließlich Ineffizienzen bei der Verwendung gasintensiver Funktionen wie Speichersteckplätze. Derzeit summieren sich diese zusätzlichen Ineffizienzen auf mindestens 20.000 Gas, wenn nicht sogar mehr. Die Integration dieser Komponenten in das Protokoll ist der einfachste Weg, diese Probleme zu beseitigen.

  • Risiko von Codefehlern: Wenn der „Einstiegspunktvertrag“ ERC-4337 einen ziemlich schlimmen Fehler aufweist, könnte es sein, dass bei allen ERC-4337-kompatiblen Wallets alle Gelder versiegen. Durch das Ersetzen von Verträgen durch protokollinterne Funktionalität entsteht eine implizite Verpflichtung, Codefehler durch Hard Forks zu beheben, wodurch das Risiko beseitigt wird, dass Benutzern die Mittel ausgehen.

  • Unterstützt EVM-Opcodes wie txt.origin. ERC-4337 selbst veranlasst txt.origin, die Adresse eines „Bundlers“ zurückzugeben, der eine Reihe von Benutzeraktionen in eine Transaktion packt. Die native Kontoabstraktion löst dieses Problem, indem sie dafür sorgt, dass txt.origin auf das tatsächliche Konto verweist, das die Transaktion sendet, wodurch es sich genauso verhält wie EOA.

  • Zensurresistenz: Eine der Herausforderungen bei der Trennung von Antragsteller und Bauunternehmer besteht darin, dass es einfacher wird, einzelne Transaktionen zu überprüfen. In einer Welt, in der das Ethereum-Protokoll einzelne Transaktionen identifizieren kann, kann dieses Problem durch Einschlusslisten erheblich gemildert werden, die es Antragstellern ermöglichen, eine Liste von Transaktionen anzugeben, die in fast allen Fällen in die nächsten beiden Slots aufgenommen werden müssen. Allerdings kapselt ERC-4337 außerhalb des Protokolls „Benutzeroperationen“ in einer einzigen Transaktion, wodurch Benutzeroperationen für das Ethereum-Protokoll undurchsichtig werden. Daher kann die vom Ethereum-Protokoll bereitgestellte Einschlussliste keine Zensurresistenz für ERC-4337-Benutzer bieten Operationen. Durch die Kapselung von ERC-4337 und die Umwandlung der Benutzeroperation in einen „richtigen“ Transaktionstyp wird dieses Problem gelöst.

Erwähnenswert ist, dass ERC-4337 in seiner aktuellen Form deutlich teurer ist als „einfache“ Ethereum-Transaktionen: Eine Transaktion kostet 21.000 Gas, während ERC-4337 rund 42.000 Gas kostet.

Theoretisch sollte es möglich sein, das EVM-Gaskostensystem anzupassen, bis die protokollinternen Kosten und die Kosten für den Zugriff auf Speicher außerhalb des Protokolls übereinstimmen. Es besteht kein Grund, 9000 Gas für die Übertragung von ETH auszugeben, wenn andere Speicherarten bearbeitet werden Operationen sind günstiger. Tatsächlich versuchen zwei EIPs im Zusammenhang mit der bevorstehenden Verkle-Baumtransformation genau das zu erreichen. Aber selbst wenn wir dies tun, gibt es einen offensichtlichen Grund dafür, dass gekapselte Protokollfunktionen, egal wie effizient die EVM wird, unweigerlich viel billiger sind als EVM-Code: Für gekapselten Code müssen keine Benzinkosten für das Vorladen bezahlt werden.

Eine voll funktionsfähige ERC-4337-Wallet ist groß, wobei diese Implementierung kompiliert und in die Kette gestellt wird und etwa 12.800 Bytes beansprucht. Natürlich könnten Sie diesen Code einmal bereitstellen und DELEGATECALL verwenden, um es jeder einzelnen Wallet zu ermöglichen, ihn aufzurufen, aber Sie müssten trotzdem in jedem Block, in dem er verwendet wird, auf den Code zugreifen. Unter dem Gaskosten-EIP des Verkle-Baums bilden 12.800 Bytes 413 Blöcke, und für den Zugriff auf diese Blöcke muss das Zweifache der Witness-Branch_cost (insgesamt 3.800 Gas) und das 413-fache der Witness-Chunk_cost (insgesamt 82.600 Gas) gezahlt werden. Ganz zu schweigen vom ERC-4337-Einstiegspunkt selbst, der in Version 0.6.0 23.689 Bytes in der Kette hat (ungefähr 158.700 Gas zum Laden gemäß den Verkle-Tree-EIP-Regeln).

Dies führt zu einem Problem: Die Gaskosten für den tatsächlichen Zugriff auf diese Codes müssen auf irgendeine Weise über die Transaktionen hinweg amortisiert werden. Der derzeit von ERC-4337 verwendete Ansatz ist nicht sehr gut: Die erste Transaktion im Paket verbraucht einmalige Speicher-/Code-Lesekosten und ist damit viel teurer als andere Transaktionen. Durch die protokollinterne Kapselung können diese öffentlichen gemeinsam genutzten Bibliotheken Teil des Protokolls werden und für jedermann frei zugänglich sein.

Was können wir aus diesem Beispiel lernen und wann sollte Kapselung allgemeiner praktiziert werden?

In diesem Beispiel sehen wir einige unterschiedliche Gründe für die Kapselung von Kontoabstraktionen in Protokollen.

  • Marktbasierte Ansätze, die „die Komplexität an den Rand drängen“, scheitern am ehesten, wenn die Fixkosten hoch sind. Tatsächlich scheint die langfristige Kontoabstraktions-Roadmap viele Fixkosten pro Block zu verursachen. 244.100 Gas für das Laden standardisierter Wallet-Codes sind eine Sache; durch die Aggregation können jedoch Hunderttausende Gas für die ZK-SNARK-Verifizierung sowie die On-Chain-Kosten für die Beweisüberprüfung hinzukommen. Es gibt keine Möglichkeit, den Nutzern diese Kosten in Rechnung zu stellen, ohne zu massiven Marktineffizienzen zu führen, und die Umwandlung einiger dieser Funktionen in Protokollfunktionen, die für jedermann frei zugänglich sind, würde dieses Problem sehr gut lösen.

  • Communityweite Reaktion auf Codefehler. Wenn ein Teil des Codes von allen Benutzern oder einem sehr breiten Benutzerkreis verwendet wird, ist es oft sinnvoller, dass die Blockchain-Community die Verantwortung eines Hard Forks übernimmt, um auftretende Fehler zu beheben. ERC-4337 führt eine große Menge global geteilten Codes ein. Auf lange Sicht ist es zweifellos sinnvoller, Fehler im Code durch Hard Forks zu beheben, als den Benutzern einen großen Verlust an ETH zu verursachen.

  • Manchmal kann eine stärkere Form des Protokolls implementiert werden, indem seine Funktionalität direkt genutzt wird. Das wichtigste Beispiel hierfür sind zensurresistente Funktionen innerhalb des Protokolls, wie z. B. Include-Listen: Protokollinterne Include-Listen können Zensurresistenz besser gewährleisten als Methoden außerhalb des Protokolls, damit Vorgänge auf Benutzerebene wirklich von protokollinternen Vorteilen profitieren Include-Listen, einzelne Benutzer Level-Operationen erfordern eine „Lesbarkeit“ des Protokolls. Ein weiteres weniger bekanntes Beispiel ist, dass das Proof-of-Stake-Design von Ethereum aus dem Jahr 2017 eine Kontoabstraktion von Stake-Schlüsseln vorsah, die zugunsten von gekapseltem BLS aufgegeben wurde, weil BLS einen „Aggregations“-Mechanismus unterstützte, der im Protokoll implementiert werden musste Auf Netzwerkebene kann dadurch die Verarbeitung einer großen Anzahl von Signaturen effizienter gestaltet werden.

Es ist jedoch wichtig, sich daran zu erinnern, dass selbst die Kapselung von Kontoabstraktionen in Protokollen im Vergleich zum Status quo immer noch eine große „Entkapselung“ darstellt. Heutzutage können Ethereum-Transaktionen der obersten Ebene nur von externen Konten (External Owned Accounts, EOA) initiiert werden, die mithilfe einer einzigen elliptischen Kurvensignatur von secp 256 k 1 verifiziert werden. Die Kontoabstraktion beseitigt dies und überlässt die Definition der Validierungsbedingungen dem Benutzer. Daher sehen wir in dieser Geschichte über die Kontoabstraktion auch den größten Grund gegen die Kapselung: die Flexibilität, den Bedürfnissen verschiedener Benutzer gerecht zu werden.

Lassen Sie uns die Geschichte weiter konkretisieren, indem wir uns einige andere Beispiele für Funktionen ansehen, die kürzlich für eine Kapselung in Betracht gezogen wurden. Besonderes Augenmerk legen wir auf: ZK-EVM, Trennung von Antragsteller und Erbauer, private Speicherpools, Liquiditätszusagen und neue Vorkompilierung.

Paket ZK-EVM

Wenden wir unsere Aufmerksamkeit einem weiteren potenziellen Kapselungsziel für das Ethereum-Protokoll zu: ZK-EVM. Derzeit haben wir eine große Anzahl von ZK-Rollups, die alle ziemlich ähnlichen Code schreiben müssen, um die Ausführung ähnlicher Ethereum-Blöcke in ZK-SNARKs zu überprüfen. Es gibt ein ziemlich vielfältiges Ökosystem unabhängiger Implementierungen: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth und viele mehr.

Eine aktuelle Kontroverse im Bereich EVM ZK-Rollup betrifft den Umgang mit Fehlern, die im ZK-Code auftreten können. Derzeit verfügen alle diese laufenden Systeme über eine Art „Sicherheitsrat“-Mechanismus, der das Attestierungssystem im Falle eines Fehlers kontrolliert. Letztes Jahr habe ich versucht, einen standardisierten Rahmen zu schaffen, der Projekte dazu ermutigen würde, zu klären, wie sehr sie dem Zertifizierungssystem und wie sehr sie dem Sicherheitsrat vertrauen, und ihre Autorität über diese Organisation im Laufe der Zeit schrittweise zu reduzieren.

Mittelfristig könnte sich das Rollup auf mehrere Zertifizierungssysteme stützen, und der Sicherheitsrat wird nur in extremen Fällen Macht haben, wenn zwei verschiedene Zertifizierungssysteme voneinander abweichen.

Es besteht jedoch das Gefühl, dass einige dieser Arbeiten überflüssig erscheinen. Wir haben bereits eine Ethereum-Basisschicht, sie verfügt über eine EVM und wir haben bereits einen funktionierenden Mechanismus für den Umgang mit Fehlern in der Implementierung: Wenn ein Fehler auftritt, wird der Client aktualisiert, um ihn zu beheben, und die Kette wird weiterhin funktionieren . Aus Sicht des fehlerhaften Clients scheint es, dass abgeschlossene Blöcke nicht mehr bestätigt werden, aber wir werden zumindest keine Geldverluste der Benutzer erleben. Wenn Rollups einfach nur mit EVM gleichwertig bleiben wollen, müssen sie ihre eigene Governance implementieren, um ihre internen ZK-EVM-Regeln ständig zu ändern, um Upgrades auf die Ethereum-Basisschicht anzupassen, was sich falsch anfühlt, weil sie letztendlich auf der Basisschicht aufgebaut sind Die Ethereum-Basisschicht selbst weiß, wann und nach welchen neuen Regeln ein Upgrade durchgeführt werden muss.

Da diese L2-ZK-EVMs im Grunde genau das gleiche EVM wie Ethereum verwenden, können wir irgendwie „EVM-Ausführung in ZK überprüfen“ in die Protokollfunktionalität integrieren und Ausnahmen behandeln, indem wir den sozialen Konsens von Ethereum anwenden, wie etwa Fehler und Upgrades, wie wir es bereits für tun Basisschicht-EVM-Ausführung selbst?

Dies ist ein wichtiges und herausforderndes Thema.

Ein mögliches Diskussionsthema bezüglich der Datenverfügbarkeit in nativem ZK-EVM ist Statefulness. ZK-EVMs wären viel dateneffizienter, wenn sie keine „Zeugen“-Daten transportieren müssten. Das heißt, wenn ein bestimmtes Datenelement in einem vorherigen Block gelesen oder geschrieben wurde, können wir einfach davon ausgehen, dass der Prüfer Zugriff darauf hat und es nicht erneut verfügbar machen muss. Es geht nicht nur darum, Speicher und Code nicht neu zu laden; es stellt sich heraus, dass bei einer korrekten Komprimierung der Daten durch die zustandsbehaftete Komprimierung im Vergleich zur zustandslosen Komprimierung bis zu dreimal so viele Daten eingespart werden können.

Das bedeutet, dass wir für die ZK-EVM-Vorkompilierung zwei Optionen haben:

1. Die Vorkompilierung erfordert, dass alle Daten im selben Block verfügbar sind. Das bedeutet, dass der Prüfer zustandslos sein kann, aber es bedeutet auch, dass die Verwendung dieses vorkompilierten ZK-Rollups viel teurer ist als die Verwendung eines benutzerdefinierten Code-Rollups.

2. Durch die Vorkompilierung können Zeiger auf Daten verweisen, die bei früheren Ausführungen verwendet oder generiert wurden. Dadurch ist das ZK-Rollup nahezu optimal, aber es ist komplexer und führt einen neuen Zustand ein, der vom Prüfer gespeichert werden muss.

Was können wir daraus lernen? Es gibt einen guten Grund, die ZK-EVM-Verifizierung auf irgendeine Weise zu kapseln: Rollup erstellt bereits seine eigene benutzerdefinierte Version, und Ethereum ist bereit, seine zahlreichen Implementierungen und den sozialen Konsens außerhalb der Kette zu gewichten, um EVM auf L1 auszuführen. Das fühlt sich aber falsch an L2, der genau die gleiche Aufgabe erfüllt, müsste ein komplexes Gerät implementieren, an dem der Sicherheitsrat beteiligt ist. Andererseits liegt aber auch ein großes Problem im Detail: Es gibt verschiedene Versionen von ZK-EVM, mit unterschiedlichen Kosten und Nutzen. Die Unterscheidung zwischen zustandsbehaftet und zustandslos kratzt nur an der Oberfläche; Versuche, benutzerdefinierten „Fast-EVM“-Code zu unterstützen, der sich in anderen Systemen bewährt hat, können einen größeren Designraum offenlegen. Daher bringt die Verpackung von ZK-EVM sowohl Hoffnung als auch Herausforderungen mit sich.

Encapsulation Proposer and Builder Separation (ePBS)

Der Aufstieg von MEV macht die Blockproduktion zu einer wirtschaftlichen Aktivität im großen Maßstab, bei der hochentwickelte Akteure in der Lage sind, Blöcke zu produzieren, die mehr Einnahmen generieren als der Standardalgorithmus, der lediglich einen Mempool von Transaktionen beobachtet und diese enthält. Bisher hat die Ethereum-Community versucht, dieses Problem zu lösen, indem sie Off-Protocol-Proposer-Builder-Trennungsschemata wie MEV-Boost verwendet, das es regulären Validatoren („Proposern“) ermöglicht, Blöcke zu pushen. Der Bau wird an spezialisierte Akteure („Builders“) ausgelagert ").

MEV-Boost geht jedoch von Vertrauensannahmen in einer neuen Klasse von Akteuren namens Relays aus. In den letzten zwei Jahren gab es viele Vorschläge zur Schaffung eines „gekapselten PBS“. Welche Vorteile bietet dies? In diesem Fall ist die Antwort sehr einfach: Ein PBS, das unter direkter Verwendung von Protokollfunktionen erstellt wurde, ist leistungsfähiger (im Sinne schwächerer Vertrauensannahmen) als ein PBS, das ohne deren Verwendung erstellt wurde. Dies ähnelt dem Fall der Kapselung von Preisorakeln in einem Protokoll – obwohl es in diesem Fall starke Einwände gibt.

Kapseln Sie den privaten Speicherpool

Wenn ein Benutzer eine Transaktion sendet, ist diese sofort öffentlich und für alle sichtbar, noch bevor sie in die Kette aufgenommen wird. Dies macht Benutzer vieler Anwendungen anfällig für wirtschaftliche Angriffe, wie z. B. Front-Running.

In jüngster Zeit gibt es eine Reihe von Projekten, die sich der Erstellung „privater Mempools“ (oder „Krypto-Mempools“) widmen, die die Transaktionen der Benutzer verschlüsseln, bis sie unwiderruflich in einen Block aufgenommen werden.

Das Problem ist jedoch, dass ein solches Schema eine besondere Art der Verschlüsselung erfordert: Um zu verhindern, dass Benutzer das System überfluten und es zuerst entschlüsseln, muss die Verschlüsselung automatisch entschlüsselt werden, nachdem die Transaktion tatsächlich unwiderruflich akzeptiert wurde.

Es gibt verschiedene Techniken mit unterschiedlichen Kompromissen, um diese Form der Verschlüsselung zu implementieren. Jon Charbonneau hat es einmal gut beschrieben:

  • Verschlüsseln Sie zentralisierte Betreiber wie Flashbots Protect.

  • Time-Lock-Verschlüsselung, diese Verschlüsselungsform kann nach bestimmten aufeinanderfolgenden Berechnungsschritten von jedem entschlüsselt werden und ist nicht parallelisierbar;

  • Die Schwellenwertverschlüsselung vertraut einem ehrlichen Mehrheitsgremium bei der Entschlüsselung von Daten. Spezifische Vorschläge finden Sie im Konzept geschlossener Beacon-Ketten.

  • Vertrauenswürdige Hardware wie SGX.

Leider hat jede Verschlüsselungsmethode unterschiedliche Schwächen. Während es für jede Lösung eine Untergruppe von Benutzern gibt, die bereit sind, ihr zu vertrauen, ist keine Lösung vertrauenswürdig genug, um tatsächlich von Schicht 1 akzeptiert zu werden. Zumindest bis zur Perfektionierung der verzögerten Verschlüsselung oder einem anderen technologischen Durchbruch scheint die Kapselung der Anti-Ahead-Trading-Funktionalität in Layer 1 ein schwieriges Unterfangen zu sein, auch wenn es sich um eine so wertvolle Funktion handelt, dass viele Anwendungslösungen entstanden sind.

Gekapselter Liquiditätseinsatz

Ein häufiges Bedürfnis unter Ethereum-DeFi-Benutzern ist die Möglichkeit, ihre ETH gleichzeitig zum Abstecken und als Sicherheit in anderen Anwendungen zu verwenden. Eine weitere häufige Anfrage dient einfach der Bequemlichkeit: Benutzer möchten in der Lage sein, Stakes zu tätigen (und Online-Stake-Schlüssel zu schützen), ohne die Komplexität, einen Knoten zu betreiben und ihn immer online zu halten.

Die bei weitem einfachste Absteck-„Schnittstelle“, die diese beiden Anforderungen erfüllt, ist nur ein ERC 20-Token: Wandeln Sie Ihre ETH in „abgesteckte ETH“ um, halten Sie sie und wandeln Sie sie dann wieder zurück. Tatsächlich tun dies bereits Anbieter von Liquiditätsbeteiligungen wie Lido und Rocket Pool. Es gibt jedoch einige natürliche Zentralisierungsmechanismen, die beim Abstecken von Liquidität eine Rolle spielen: Menschen werden natürlicherweise die größte Version der ETH abstecken, weil diese am vertrautesten und liquidesten ist.

Jede Version der abgesteckten ETH muss über einen Mechanismus verfügen, um zu bestimmen, wer der zugrunde liegende Knotenbetreiber werden kann. Es kann nicht unbegrenzt sein, denn dann beteiligen sich Angreifer und nutzen Benutzergelder, um ihre Angriffe auszuweiten. Derzeit sind die beiden Spitzenreiter Lido und Rocket Pool, wobei erstere Knotenbetreiber auf der DAO-Whitelist haben und letztere es jedem ermöglichen, einen Knoten mit einer Einzahlung von 8 ETH zu betreiben. Diese beiden Methoden bergen unterschiedliche Risiken: Die Rocket-Pool-Methode ermöglicht einem Angreifer einen 51-prozentigen Angriff auf das Netzwerk und zwingt die Benutzer, den Großteil der Kosten zu zahlen, während bei der DAO-Methode ein bestimmter abgesteckter Token dominant wird Ein potenziell kompromittiertes Governance-Gadget kontrolliert einen großen Teil aller Ethereum-Validatoren. Man muss anerkennen, dass Protokolle wie Lido Schutzmaßnahmen implementiert haben, aber eine einzige Verteidigungsebene reicht möglicherweise nicht aus.

Kurzfristig besteht eine Möglichkeit darin, die Teilnehmer des Ökosystems zu ermutigen, verschiedene Liquiditätsanbieter zu nutzen, um die Möglichkeit zu verringern, dass ein dominanter Akteur ein systemisches Risiko darstellt. Auf lange Sicht ist dies jedoch ein instabiles Gleichgewicht, und es ist gefährlich, sich zu sehr auf moralischen Druck zu verlassen, um Probleme zu lösen. Es stellt sich natürlich die Frage: Wäre es sinnvoll, einige Funktionen in das Protokoll zu integrieren, um den Liquiditätseinsatz weniger zentral zu gestalten?

Die entscheidende Frage hier ist: Welche Art von protokollinterner Funktionalität? Ein Problem bei der einfachen Erstellung eines fungiblen „ETH-Stake“-Tokens innerhalb des Protokolls besteht darin, dass es entweder über eine gekapselte Ethereum-weite Governance verfügen müsste, um zu entscheiden, wer die Knoten betreiben darf, oder dass es ein offenes Ende haben müsste, aber das würde dazu führen Werkzeuge des Angreifers.

Eine interessante Idee ist der Artikel von Dankrad Feist über die Maximierung des Liquiditätseinsatzes. Lassen Sie uns zunächst in den sauren Apfel beißen. Wenn Ethereum zu 51 % angegriffen wird, werden möglicherweise nur 5 % der angegriffenen ETH gekürzt. Dies ist ein vernünftiger Kompromiss; da derzeit über 26 Millionen ETH eingesetzt werden, sind die Kosten für einen Angriff auf ein Drittel davon (~8 Millionen ETH) zu hoch, insbesondere wenn man bedenkt, wie viele „außerhalb des Modells liegende“ Angriffe gleichzeitig durchgeführt werden können geringere Kosten. Tatsächlich wurden ähnliche Kompromisse im Vorschlag des Superkomitees zur Umsetzung der Single-Slot-Finalität untersucht.

Wenn wir akzeptieren, dass nur 5 % der Angriffs-ETH gekürzt werden, dann werden mehr als 90 % der eingesetzten ETH nicht von der Kürzung betroffen sein, sodass sie als fungible Liquid-Stake-Token innerhalb des Protokolls verwendet und dann von anderen Anwendungen verwendet werden können.

Dieser Weg ist interessant. Aber es bleibt immer noch eine Frage: Was genau ist gekapselt? Rocket Pool funktioniert sehr ähnlich: Jeder Knotenbetreiber stellt einige Mittel bereit, und Liquiditäts-Staker sorgen für den Rest. Wir können einfach einige Konstanten anpassen, um die maximale Slashing-Strafe auf 2 ETH zu begrenzen, und das bestehende rETH von Rocket Pool wird risikofrei.

Mit einfachen Protokollanpassungen können wir auch andere clevere Dinge tun. Nehmen wir zum Beispiel an, wir möchten ein System mit zwei „Stufen“ des Einsatzes: Knotenbetreiber (hohe Anforderungen an Sicherheiten) und Einleger (keine Mindestanforderungen an Sicherheiten, können jederzeit beitreten und gehen), aber wir möchten dennoch eine zufällig ausgewählte Anzahl von Teilnehmern bereitstellen Die Befugnisse des Einlegerausschusses können die Zentralisierung von Knotenbetreibern verhindern, z. B. die Empfehlung einer Liste von Transaktionen, die einbezogen werden müssen (aus Gründen der Zensurresistenz), die Kontrolle der Fork-Auswahl bei Inaktivitätslecks oder die Anforderung von Unterschriften auf Blöcken. Dies könnte auf eine Weise erreicht werden, die im Wesentlichen außerhalb des Protokolls liegt, indem das Protokoll dahingehend angepasst wird, dass jeder Validator (i) einen regulären Einsatzschlüssel bereitstellen muss und (ii) eine ETH-Adresse, die in jedem Slot verwendet werden kann, zur Ausgabe aufgerufen wird sekundärer Pfandschlüssel. Das Protokoll würde beide Schlüssel befähigen, aber der Mechanismus zur Auswahl des zweiten Schlüssels in jedem Slot könnte dem Staking-Pool-Protokoll überlassen werden. Es mag immer noch besser sein, einige Funktionen direkt zu kapseln, aber es ist erwähnenswert, dass dieser Gestaltungsspielraum besteht, bei dem es darum geht, „einige Dinge einzubeziehen und andere Dinge dem Benutzer zu überlassen“.

Kapseln Sie mehr Vorkompilierung

Vorkompilierte Verträge (oder „vorkompilierte Verträge“) sind Ethereum-Verträge, die komplexe kryptografische Operationen implementieren, wobei die Logik nativ im Client-Code und nicht im EVM-Smart-Contract-Code implementiert wird. Die Vorcodierung ist ein Kompromiss, der seit Beginn der Ethereum-Entwicklung übernommen wurde: Da der Overhead einer virtuellen Maschine für sehr komplexen und hochspezialisierten Code zu groß ist, können wir einige wichtige Anwendungen in nativem Code implementieren, um sie schneller zu machen. Heute umfasst dies im Wesentlichen einige spezifische Hash-Funktionen und elliptische Kurvenoperationen.

Derzeit gibt es Bestrebungen, eine Vorkompilierung für secp 256 r 1 hinzuzufügen, eine etwas andere elliptische Kurve als secp 256 k 1, die für grundlegende Ethereum-Konten verwendet wird, da sie von vertrauenswürdigen Hardwaremodulen gut unterstützt wird und daher häufig zur Erhöhung der Wallet-Sicherheit verwendet wird. In den letzten Jahren hat die Community auch darauf gedrängt, eine Vorkompilierung für BLS-12-377, BW 6-761, generalisiertes Pairing und andere Funktionen hinzuzufügen.

Das Gegenargument zu diesen Forderungen nach mehr Precompilern ist, dass viele der zuvor hinzugefügten Precompiler (wie RIPEMD und BLAKE) am Ende weitaus seltener genutzt wurden als erwartet, und wir sollten daraus lernen. Anstatt mehr Vorkompilierung für bestimmte Vorgänge hinzuzufügen, sollten wir uns vielleicht auf einen bescheideneren Ansatz konzentrieren, der auf Ideen wie EVM-MAX und dem Hibernate-But-Always-Resumable-SIMD-Vorschlag basiert, der es ermöglichen würde, EVM-Implementierungen zu geringeren Kosten auszuführen Ausführen einer breiten Palette von Codeklassen. Vielleicht könnte sogar die bestehende, wenig genutzte Vorkompilierung entfernt und durch eine (unweigerlich weniger effiziente) EVM-Code-Implementierung derselben Funktionen ersetzt werden. Dennoch ist es immer noch möglich, dass es bestimmte kryptografische Vorgänge gibt, die wertvoll genug sind, um sie zu beschleunigen. Daher ist es sinnvoll, sie vorkompiliert hinzuzufügen.

Was haben wir daraus gelernt?

Der Wunsch, so wenig wie möglich zu kapseln, ist verständlich und gut; er entspringt der philosophischen Tradition von Unix, minimalistische Software zu entwickeln, die sich leicht an die unterschiedlichen Bedürfnisse der Benutzer anpassen lässt und den Fluch der Software-Aufblähung vermeidet. Blockchain ist jedoch kein Personal-Computing-Betriebssystem, sondern ein soziales System. Das bedeutet, dass es sinnvoll ist, bestimmte Funktionalitäten im Protokoll zu kapseln.

In vielen Fällen ähneln diese anderen Beispiele dem, was wir in der Kontoabstraktion gesehen haben. Aber wir haben auch einige neue Lektionen gelernt:

  • Durch die Kapselung der Funktionalität können Zentralisierungsrisiken in anderen Bereichen des Stacks vermieden werden:

Wenn das Basisprotokoll minimal und einfach gehalten wird, wird die Komplexität oft auf ein Ökosystem außerhalb des Protokolls verlagert. Aus Sicht der Unix-Philosophie ist das in Ordnung. Allerdings besteht manchmal die Gefahr, dass das Off-Protocol-Ökosystem zentralisiert wird, meist (aber nicht nur) aufgrund hoher Fixkosten. Die Kapselung kann manchmal die De-facto-Zentralisierung verringern.

  • Eine zu starke Kapselung kann die Vertrauens- und Governance-Belastung des Protokolls überfordern:

Dies ist das Thema des vorherigen Artikels „Don't Overload Ethereum Consensus“: Wenn die Kapselung einer bestimmten Funktion das Vertrauensmodell schwächt und Ethereum als Ganzes „subjektiver“ macht, schwächt dies die glaubwürdige Neutralität von Ethereum. In diesen Fällen ist es besser, die spezifische Funktionalität als Mechanismus auf Ethereum zu haben, anstatt zu versuchen, sie in Ethereum selbst zu integrieren. Das beste Beispiel hierfür sind verschlüsselte Speicherpools, deren Kapselung etwas schwierig sein kann, zumindest bis sich die Latenzverschlüsselung verbessert.

  • Eine zu starke Kapselung kann das Protokoll übermäßig komplex machen:

Die Protokollkomplexität ist ein systemisches Risiko, das durch das Hinzufügen zu vieler Funktionen zu einem Protokoll erhöht wird. Die Vorkompilierung ist das beste Beispiel.

  • Die Kapselung von Funktionalität kann auf lange Sicht kontraproduktiv sein, da Benutzerbedürfnisse unvorhersehbar sind:

Eine Funktion, die viele für wichtig halten und von vielen Benutzern genutzt werden wird, wird in der Praxis wahrscheinlich nicht sehr oft genutzt.

Darüber hinaus zeigen Liquiditätszusagen, ZK-EVM und vorkompilierte Beispiele die Möglichkeit eines Mittelwegs: minimale praktikable Verankerung. Das Protokoll muss nicht die gesamte Funktionalität kapseln, sondern kann spezifische Teile enthalten, die sich mit wichtigen Herausforderungen befassen, sodass die Funktionalität einfach zu implementieren ist, ohne zu paranoid oder zu eng zu wirken. Beispiele hierfür sind:

  • Anstatt ein vollständiges Liquiditäts-Einsatzsystem zu kapseln, ist es besser, die Regeln für die Einsatzstrafe zu ändern, um vertrauenswürdiges Liquiditäts-Einsatz praktikabler zu machen;

  • Anstatt mehr Precompiler zu kapseln, ist es besser, EVM-MAX und/oder SIMD zu kapseln, um die effiziente Implementierung einer größeren Klasse von Operationen zu erleichtern;

  • Es ist möglich, die EVM-Verifizierung einfach zu kapseln, anstatt das gesamte Rollup-Konzept zu kapseln.

Wir können das vorherige Diagramm wie folgt erweitern:

Manchmal ist es sinnvoll, etwas zu kapseln, und das Entfernen selten verwendeter Precompiler ist ein Beispiel dafür. Die Kontoabstraktion als Ganzes ist, wie bereits erwähnt, ebenfalls eine wichtige Form der Entkapselung. Wenn wir die Abwärtskompatibilität für bestehende Benutzer unterstützen möchten, könnte der Mechanismus tatsächlich dem Mechanismus überraschend ähnlich sein, der die Vorkompilierung entpackt hat: Einer der Vorschläge ist EIP-5003, der es EOAs ermöglichen würde, ihre Konten so umzuwandeln, dass sie dasselbe (bzw besser) funktionaler Vertrag.

Welche Funktionen in das Protokoll aufgenommen und welche anderen Schichten des Ökosystems überlassen werden sollten, ist ein komplexer Kompromiss. Es wird erwartet, dass sich dieser Kompromiss im Laufe der Zeit weiter verbessert, da sich unser Verständnis der Benutzerbedürfnisse und der verfügbaren Palette an Ideen und Technologien weiter verbessert.