Vitaliks neuer Artikel: Die mögliche Zukunft von Ethereum, The Splurge

Originaltitel: Mögliche Zukunftsszenarien des Ethereum-Protokolls, Teil 6: Die Verschwendung

Originalartikel von @VitalikButerin

Originalübersetzung: zhouzhou, BlockBeats

Nachfolgend der Originalinhalt (zur leichteren Lesbarkeit und Verständlichkeit wurde der Originalinhalt neu organisiert):

Manche Dinge lassen sich nur schwer in eine einzige Kategorie einordnen, und im Ethereum-Protokolldesign gibt es viele Details, die für den Erfolg von Ethereum sehr wichtig sind. Tatsächlich betrifft etwa die Hälfte des Inhalts verschiedene Arten von EVM-Verbesserungen, und der Rest besteht aus verschiedenen Nischenthemen. Das ist es, was „Flair“ bedeutet.

Roadmap 2023: Wohlstand

Wohlstand: Ein zentrales Ziel

Das EVM in einen performanten und stabilen Endzustand bringen

Einführung der Kontoabstraktion in das Protokoll, damit alle Benutzer sicherere und bequemere Konten nutzen können

Optimierung der Transaktionsgebührenökonomie, Steigerung der Skalierbarkeit bei gleichzeitiger Risikoreduzierung

Fortgeschrittene erkunden KryptoGrafik, um Ethereum langfristig deutlich zu verbessern

In diesem Kapitel

EVM-Verbesserungen

Kontoabstraktion

EIP-1559 Verbesserungen

VDF (Verifizierbare Verzögerungsfunktion)

Verschleierung und Einmalsignaturen: die Zukunft der Kryptographie

EVM-Verbesserungen

Welches Problem wurde gelöst?

Das aktuelle EVM ist schwer statisch zu analysieren, was die Erstellung effizienter Implementierungen, die formale Überprüfung von Code und weitere Erweiterungen erschwert. Darüber hinaus ist das EVM ineffizient und es ist schwierig, viele Formen fortgeschrittener Kryptografie zu implementieren, sofern dies nicht ausdrücklich durch Vorkompilierung unterstützt wird.

Was ist das und wie funktioniert es?

Der erste Schritt im aktuellen EVM-Verbesserungsplan ist das EVM Object Format (EOF), das im nächsten Hard Fork enthalten sein soll. EOF ist eine Reihe von EIPs, die eine neue EVM-Codeversion mit einer Reihe einzigartiger Funktionen spezifizieren. insbesondere:

• Trennung zwischen Code (der ausgeführt, aber nicht aus dem EVM gelesen werden kann) und Daten (die gelesen, aber nicht ausgeführt werden können)

• Dynamische Sprünge sind verboten, nur statische Sprünge sind erlaubt

• Der EVM-Code kann keine kraftstoffbezogenen Informationen mehr beobachten

• Ein neuer expliziter Unterprogrammmechanismus wurde hinzugefügt

Struktur des EOF-Codes

Boom: EVM-Verbesserungen (Fortsetzung)

Verträge im alten Stil werden weiterhin existieren und können erstellt werden, obwohl sie wahrscheinlich irgendwann auslaufen werden (vielleicht sogar gezwungen sein werden, in EOF-Code umzuwandeln). Verträge im neuen Stil werden von den Effizienzgewinnen profitieren, die EOF mit sich bringt – zunächst in Form von etwas kleinerem Bytecode über die Subroutinenfunktion und später in Form neuer EOF-spezifischer Funktionen oder reduzierter Gaskosten.

Nach der Einführung von EOF wurden weitere Upgrades einfacher, und das derzeit am weitesten entwickelte ist die EVM Modular Arithmetic Extension (EVM-MAX) . EVM-MAX erstellt einen neuen Satz von Operationen speziell für modulare Operationen und platziert sie in einem neuen Speicherbereich, auf den andere Opcodes nicht zugreifen können. Dadurch können Optimierungen wie Montgomery-Multiplikation .

Eine neuere Idee ist die Kombination von EVM-MAX mit der SIMD-Funktion (Single Instruction Multiple Data). SIMD gibt es schon seit langem als Ethereum-Konzept, das erstmals von Greg Colvins EIP-616 . SIMD kann verwendet werden, um viele Formen der Kryptografie zu beschleunigen, darunter Hash-Funktionen, 32-Bit-STARKs und gitterbasierte Kryptografie. Die Kombination von EVM-MAX und SIMD macht diese beiden leistungsorientierten Erweiterungen zu einer natürlichen Paarung.

Ein grober Entwurf für ein kombiniertes EIP würde mit EIP-6690 beginnen, dann:

• Erlaubt (i) jede ungerade Zahl oder (ii) jede Potenz von 2 bis 2768 als Modul

• Fügen Sie für jeden EVM-MAX-Opcode (Addition, Subtraktion, Multiplikation) eine Version hinzu, die 7 Immediates statt 3 x, y, z verwendet: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Im Python-Code funktionieren diese Opcodes folgendermaßen:

• für i im Bereich (Anzahl):
  mem[z_start + z_skip * Anzahl] = op(
  mem[x_start + x_skip * Anzahl],
  mem[y_start + y_skip * Anzahl]
  )

Bei der tatsächlichen Umsetzung erfolgt dies parallel.

• Möglicherweise Hinzufügen von XOR, AND, OR, NOT und SHIFT (sowohl mit als auch ohne Schleife), zumindest für Modulos von Zweierpotenzen. Außerdem Hinzufügen von ISZERO (Pushen der Ausgabe an den EVM-Hauptstapel), was leistungsstark genug sein wird, um elliptische Kurvenkryptografie, Kryptografie kleiner Domänen (wie Poseidon, Circle STARKs), traditionelle Hash-Funktionen (wie SHA 256, KECCAK, BLAKE) und gitterbasierte Kryptografie zu implementieren. Andere EVM-Upgrades sind ebenfalls möglich, haben aber bisher weniger Aufmerksamkeit erhalten.

Links zu bestehender Forschung

Ende der Forschung: https://evmobjectformat.org/

EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690

SIMD: https://eips.ethereum.org/EIPS/eip-616

Verbleibende Arbeit und Kompromisse

Derzeit ist geplant, dass EOF im nächsten Hard Fork enthalten sein wird. Es ist zwar immer möglich, es in letzter Minute zu entfernen – Funktionen wurden in früheren Hard Forks vorübergehend entfernt, was sehr schwierig wäre. Das Entfernen von EOF bedeutet, dass alle zukünftigen Upgrades des EVM ohne EOF durchgeführt werden müssen, was zwar möglich ist, aber schwieriger sein kann.

Der wichtigste Kompromiss des EVM ist die L1-Komplexität gegenüber der Infrastrukturkomplexität. EOF ist eine große Menge an Code, die der EVM-Implementierung hinzugefügt werden muss, und die statische Codeprüfung ist relativ komplex. Im Gegenzug können wir jedoch die höhere Programmiersprache vereinfachen, die EVM-Implementierung vereinfachen und andere Vorteile nutzen. Man kann sagen, dass die Roadmap, die die kontinuierliche Verbesserung von Ethereum L1 priorisiert, EOF beinhalten und darauf aufbauen sollte.

Eine wichtige Arbeit, die erledigt werden muss, ist die Implementierung von etwas wie EVM-MAX plus SIMD-Funktionalität und das Benchmarking des Gasverbrauchs verschiedener Kryptooperationen.

Wie interagiert es mit dem Rest der Roadmap?

L1 passt sein EVM an, damit L2 sich entsprechend leichter anpassen kann. Wenn die beiden nicht synchron angepasst werden, kann dies zu Inkompatibilität und nachteiligen Auswirkungen führen. Darüber hinaus können EVM-MAX und SIMD die Gaskosten vieler Proof-Systeme senken und L2 effizienter machen. Außerdem wird es dadurch einfacher, mehr Vorkompilierungen durch EVM-Code zu ersetzen, der dieselben Aufgaben ausführen kann, möglicherweise ohne die Effizienz stark zu beeinträchtigen.

Kontoabstraktion

Welches Problem wurde gelöst?

Derzeit können Transaktionen nur auf eine Weise verifiziert werden: ECDSA-Signaturen. Zunächst zielt die Kontoabstraktion darauf ab, darüber hinauszugehen und die Verifizierungslogik eines Kontos durch beliebigen EVM-Code zu ermöglichen. Dies kann eine Reihe von Anwendungen ermöglichen:

• Umstellung auf quantenresistente Kryptografie

• Alte Schlüssel rotieren (weitgehend gilt als empfohlene Sicherheitspraxis )

• Multi-Signatur-Wallets und Geldbörsen für die soziale Erholung

• Verwenden Sie einen Schlüssel für Operationen mit geringem Wert und einen anderen Schlüssel (oder einen Satz von Schlüsseln) für Operationen mit hohem Wert

Ermöglicht das Arbeiten von Datenschutzprotokollen ohne Relays, wodurch deren Komplexität erheblich reduziert und ein wichtiger zentraler Abhängigkeitspunkt beseitigt wird

Seit der Einführung der Kontoabstraktion im Jahr 2015 wurden auch die damit verfolgten Ziele um eine große Anzahl von Komfortzielen erweitert, wie z. B. die Möglichkeit für ein Konto, das kein ETH, aber etwas ERC 20 besitzt, Gas mit ERC 20 zu bezahlen. Hier ist eine Übersicht dieser Ziele:

MPC (Multi-Party Computation) ist ein 40 Jahre alte Technologie zum Aufteilen eines Schlüssels in mehrere Teile und zum Speichern dieser auf mehreren Geräten. Dabei werden kryptografische Techniken zum Generieren von Signaturen verwendet, ohne diese Schlüsselteile direkt zu kombinieren.

EIP-7702 ist ein Vorschlag, der im nächsten Hard Fork eingeführt werden soll. EIP-7702 ist das Ergebnis eines wachsenden Bewusstseins für die Notwendigkeit, eine bequeme Kontoabstraktion bereitzustellen, die allen Benutzern (einschließlich EOA-Benutzern) zugute kommt. Ziel ist es, die Erfahrung aller Benutzer kurzfristig zu verbessern und eine Aufspaltung in zwei Ökosysteme zu vermeiden.

Die Arbeit begann mit EIP-3074 und bildete schließlich EIP-7702. EIP-7702 bietet allen Benutzern, einschließlich der heutigen EOAs (external owned accounts, d. h. Konten, die durch ECDSA-Signaturen kontrolliert werden), die praktischen Funktionen der Kontoabstraktion.

Wie Sie der Grafik entnehmen können, können einige Herausforderungen (insbesondere die Komfortherausforderung) durch fortschrittliche Techniken wie Multi-Party-Computing oder EIP-7702 gelöst werden. Das Hauptsicherheitsziel des ursprünglichen Vorschlags zur Kontoabstraktion kann jedoch nur erreicht werden, indem man zurückgeht und das ursprüngliche Problem löst: Smart-Contract-Code die Kontrolle über die Transaktionsüberprüfung zu ermöglichen. Der Grund dafür, dass dies bisher nicht erreicht wurde, ist, dass eine sichere Implementierung schwierig ist.

Was ist das und wie funktioniert es?

Der Kern der Kontoabstraktion ist einfach: Erlauben Sie Smart Contracts, Transaktionen zu initiieren, nicht nur EOAs. Die gesamte Komplexität ergibt sich aus der Implementierung auf eine Weise, die die Aufrechterhaltung eines dezentralen Netzwerks erleichtert und vor Denial-of-Service-Angriffen schützt.

Eine typische Schlüsselherausforderung ist das Problem mehrfacher Fehler:

Wenn es 1.000 Konten gibt, deren Validierungsfunktionen alle auf einem einzigen Wert S basieren, und der aktuelle Wert von S alle Transaktionen im Speicherpool gültig macht, dann kann eine einzige Transaktion, die den Wert von S umdreht, alle anderen Transaktionen im Speicherpool ungültig machen. Dies ermöglicht es Angreifern, Junk-Transaktionen zu sehr geringen Kosten an den Speicherpool zu senden und so die Ressourcen der Netzwerkknoten zu verstopfen.

Nach Jahren harter Arbeit mit dem Ziel, die Funktionalität zu erweitern und gleichzeitig das Denial-of-Service-Risiko (DoS) zu begrenzen, wurde endlich eine Lösung zur Erzielung einer idealen Kontoabstraktion gefunden: ERC-4337.

ERC-4337 funktioniert, indem die Verarbeitung von Benutzeraktionen in zwei Phasen unterteilt wird: Überprüfung und Ausführung. Alle Überprüfungen werden zuerst verarbeitet und alle Ausführungen werden danach verarbeitet. Im Speicherpool werden Benutzeraktionen nur akzeptiert, wenn die Überprüfungsphase nur das eigene Konto betrifft und keine Umgebungsvariablen liest. Dies verhindert mehrere Ungültigkeitsangriffe. Darüber hinaus werden im Überprüfungsschritt strenge Gasgrenzwerte durchgesetzt.

ERC-4337 wurde als zusätzlicher Protokollstandard (ERC) entwickelt, da sich die Entwickler von Ethereum-Clients damals auf das Zusammenführen (Merge) konzentrierten und keine zusätzliche Energie für andere Funktionen hatten. Aus diesem Grund verwendet ERC-4337 anstelle von regulären Transaktionen Objekte, die als Benutzeraktionen bezeichnet werden. Vor kurzem haben wir jedoch erkannt, dass wir zumindest einige davon in das Protokoll schreiben müssen.

Dafür gibt es zwei Hauptgründe:

1. Inhärente Ineffizienz von EntryPoint als Vertrag: Es gibt einen festen Overhead von etwa 100.000 Gas pro Bündel und Tausende zusätzliche Gas pro Benutzervorgang.

2. Notwendigkeit der Gewährleistung von Ethereum-Eigenschaften: Die durch Aufnahmelisten geschaffenen Aufnahmegarantien müssen auf die Benutzer der Kontoabstraktion übertragen werden.

Darüber hinaus erweitert ERC-4337 auch zwei Funktionen:

• Paymaster: Eine Funktion, die es einem Konto ermöglicht, Gebühren im Namen eines anderen Kontos zu bezahlen. Dies verstößt gegen die Regel, dass während der Überprüfungsphase nur auf das Konto des Absenders selbst zugegriffen werden kann. Daher wird eine spezielle Verarbeitung eingeführt, um die Sicherheit des Zahlungsmastermechanismus zu gewährleisten.

• Aggregatoren: Funktionen, die Signaturaggregation unterstützen, wie z. B. BLS-Aggregation oder SNARK-basierte Aggregation. Dies ist erforderlich, um beim Rollup die höchste Dateneffizienz zu erreichen.

Links zu bestehender Forschung

Ein Vortrag zur Geschichte der Kontoabstraktion: https://www.youtube.com/watch?v=iLf8qpOmxQc

ERC-4337: https://eips.ethereum.org/EIPS/eip-4337

EIP-7702: https://eips.ethereum.org/EIPS/eip-7702

BLSWallet-Code (mit Aggregationsfunktion): https://github.com/getwax/bls-wallet

EIP-7562 (Kontoabstraktion in das Protokoll geschrieben): https://eips.ethereum.org/EIPS/eip-7562

EIP-7701 (EOF-basierte Schreibprotokoll-Kontoabstraktion): https://eips.ethereum.org/EIPS/eip-7701

Verbleibende Arbeit und Kompromisse

Das Hauptproblem, das gelöst werden muss, ist die vollständige Einführung der Kontoabstraktion in das Protokoll. Das beliebteste EIP zum Schreiben der Protokollkontoabstraktion ist EIP-7701 , das die Kontoabstraktion auf der Grundlage von EOF implementiert. Ein Konto kann einen separaten Codeabschnitt zur Überprüfung haben. Wenn das Konto diesen Codeabschnitt festlegt, wird der Code im Überprüfungsschritt der Transaktionen vom Konto ausgeführt.

Das Schöne an diesem Ansatz ist, dass er zwei gleichwertige Ansichten der lokalen Kontoabstraktion deutlich macht:

1. Machen Sie EIP-4337 zum Teil des Protokolls

2. Ein neuer EOA-Typ, bei dem der Signaturalgorithmus die EVM-Codeausführung ist

Wenn wir mit strengen Beschränkungen der Komplexität des Codes beginnen, der während der Überprüfung ausgeführt werden kann – kein Zugriff auf externe Zustände erlaubt und sogar das anfängliche Gaslimit so niedrig angesetzt, dass es für quantenresistente oder die Privatsphäre wahrende Anwendungen unwirksam ist –, dann ist die Sicherheit dieses Ansatzes klar: Ersetzen Sie einfach die ECDSA-Überprüfung durch eine EVM-Codeausführung, die ähnlich viel Zeit in Anspruch nimmt.

Mit der Zeit werden wir diese Grenzen jedoch lockern müssen, da es sehr wichtig ist, dass datenschutzfreundliche Anwendungen ohne Relais funktionieren und quantenresistent sind. Dazu müssen wir Wege finden, um Denial-of-Service-Risiken (DoS) flexibler anzugehen, ohne dass der Verifizierungsschritt extrem minimalistisch sein muss.

Der wichtigste Kompromiss scheint darin zu bestehen, schnell eine Lösung zu schreiben, die weniger Leute zufriedenstellt, oder länger auf eine möglicherweise idealere Lösung zu warten, wobei der ideale Ansatz wahrscheinlich eine Art Hybridansatz ist. Ein hybrider Ansatz wäre, einige Anwendungsfälle schneller zu schreiben und mehr Zeit zum Erkunden anderer Anwendungsfälle zu lassen. Ein anderer Ansatz wäre, zuerst eine anspruchsvollere Version der Kontoabstraktion auf L2 bereitzustellen. Die Herausforderung besteht hier jedoch darin, dass L2-Teams davon überzeugt sein müssen, dass der Adoptionsvorschlag funktioniert, bevor sie bereit sind, ihn umzusetzen, insbesondere um sicherzustellen, dass L1 und/oder andere L2s in Zukunft kompatible Lösungen übernehmen können.

Eine weitere Anwendung, die wir explizit berücksichtigen müssen, ist Schlüsselspeicherkonten die den kontobezogenen Status auf L1 oder einem dedizierten L2 speichern, aber auf L1 und jedem kompatiblen L2 verwendet werden können. Um dies effizient zu tun, muss L2 möglicherweise Opcodes unterstützen wie L1S-Last oder REMOTESTATICALL , aber dazu ist auch die Kontoabstraktionsimplementierung auf L2 erforderlich, um diese Vorgänge zu unterstützen.

Wie interagiert es mit dem Rest der Roadmap?

Inklusionslisten müssen Kontoabstraktionstransaktionen unterstützen, und in der Praxis sind die Anforderungen für Inklusionslisten tatsächlich denen für dezentrale Speicherpools sehr ähnlich, obwohl Inklusionslisten etwas flexibler sind. Darüber hinaus sollten Kontoabstraktionsimplementierungen so weit wie möglich zwischen L1 und L2 koordiniert werden. Wenn wir in Zukunft erwarten, dass die meisten Benutzer Schlüsselspeicher-Rollups verwenden, sollte das Design der Kontoabstraktion darauf basieren.

EIP-1559 Verbesserungen

Welches Problem löst es?

EIP-1559 wurde 2021 auf Ethereum aktiviert, wodurch die durchschnittliche Blockeinbindungszeit deutlich verbessert wurde.

Wartezeit

Die aktuelle Umsetzung von EIP-1559 ist in mehreren Aspekten nicht perfekt:

1. Die Formel ist leicht fehlerhaft: Sie zielt nicht auf 50% Blöcke ab, sondern auf etwa 50-53% volle Blöcke, abhängig von der Varianz (das hängt mit dem zusammen, was Mathematiker die „arithmetisch-geometrische Mittelungleichheit“ nennen).

2. Sich in Extremsituationen nicht schnell genug anzupassen.

Die spätere Formel für Blobs (EIP-4844) wurde speziell entwickelt, um das erste Problem zu lösen, und ist insgesamt auch sauberer. Weder EIP-1559 selbst noch EIP-4844 versuchen jedoch, das zweite Problem zu lösen. Infolgedessen ist der Status quo ein chaotischer Mittelweg, der zwei verschiedene Mechanismen umfasst, und es gibt das Argument, dass beide im Laufe der Zeit verbessert werden müssen.

Darüber hinaus gibt es weitere Schwächen bei der Preisgestaltung von Ethereum-Ressourcen, die nichts mit EIP-1559 zu tun haben, aber durch Anpassungen an EIP-1559 behoben werden können. Eines der Hauptprobleme ist der Unterschied zwischen dem Durchschnitts- und dem Worst-Case-Szenario: Die Ressourcenpreise in Ethereum müssen so festgelegt werden, dass sie das Worst-Case-Szenario abdecken, bei dem der gesamte Gasverbrauch eines Blocks eine Ressource verbraucht, der tatsächliche Durchschnittsverbrauch jedoch viel niedriger ist, was zu Ineffizienzen führt.

Was ist multidimensionales Gas und wie funktioniert es?

Die Lösung für diese Ineffizienzen ist mehrdimensionales Gas : unterschiedliche Preise und Limits für unterschiedliche Ressourcen. Dieses Konzept ist technisch unabhängig von EIP-1559, aber die Existenz von EIP-1559 erleichtert die Implementierung. Ohne EIP-1559 ist die optimale Verpackung eines Blocks mit mehreren Ressourcenbeschränkungen ein komplexes mehrdimensionales Rucksackproblem . Mit EIP-1559 erreichen die meisten Blöcke bei keiner Ressource die volle Kapazität, daher ist ein einfacher Algorithmus wie das Akzeptieren jeder Transaktion, die genügend Gebühren zahlt, ausreichend.

Derzeit verfügen wir über mehrdimensionales Gas für Ausführung und Datenblöcke. Grundsätzlich können wir dies auf weitere Dimensionen erweitern, beispielsweise Anrufdaten (Transaktionsdaten), Status lesen/schreiben und Statusgrößenerweiterung.

EIP-7706 führt eine neue Gasdimension speziell für Anrufdaten ein. Außerdem vereinfacht es den mehrdimensionalen Gasmechanismus, indem es die drei Gasarten in einem einzigen Rahmen (im Stil von EIP-4844) vereint und so auch die mathematischen Mängel von EIP-1559 behebt. EIP-7623 ist eine präzisere Lösung für das Ressourcenproblem im Durchschnitts- und Worst-Case-Fall mit einer engeren Begrenzung der maximalen Anrufdaten, ohne eine völlig neue Dimension einzuführen.

Eine weitere Forschungsrichtung besteht darin, das Problem der Aktualisierungsrate zu lösen und einen schnelleren Algorithmus zur Berechnung der Grundgebühr zu finden, während die durch den EIP-4844-Mechanismus eingeführten Schlüsselinvarianten erhalten bleiben (d. h.: auf lange Sicht liegt die durchschnittliche Nutzung knapp nahe am Zielwert).

Links zu bestehender Forschung

Häufig gestellte Fragen zu EIP-1559: Häufig gestellte Fragen zu EIP-1559

Empirisch Analyse von EIP-1559

Vorgeschlagen Verbesserungen, um schnelle Anpassungen zu ermöglichen:

EIP-4844 FAQ zum Grundgebührenmechanismus: Häufig gestellte Fragen zu EIP-4844

EIP-7706: EIP-7706

EIP-7623: EIP-7623

Mehrdimensionales Gas: Mehrdimensionales Gas

Welche Aufgaben und Kompromisse bleiben noch übrig?

Bei mehrdimensionalem Gas gibt es zwei wesentliche Kompromisse:

1. Erhöhung der Protokollkomplexität: Die Einführung von mehrdimensionalem Gas macht das Protokoll komplexer.

2. Erhöhte Komplexität des optimalen Algorithmus zum Füllen von Blöcken: Der optimale Algorithmus zum Füllen von Blöcken bis zur Kapazitätsgrenze wird ebenfalls komplexer.

Die Protokollkomplexität ist für Calldata relativ gering, aber für die Gasdimensionen, die intern im EVM liegen (wie Speicherlese- und -schreibvorgänge), steigt die Komplexität. Das Problem besteht darin, dass nicht nur Benutzer Gaslimits festlegen, sondern auch Verträge Limits festlegen, wenn sie andere Verträge aufrufen. Und derzeit können sie Limits nur in einer einzigen Dimension festlegen.

Eine einfache Lösung besteht darin, mehrdimensionales Gas nur innerhalb von EOF verfügbar zu machen, da EOF es Verträgen nicht erlaubt, Gaslimits festzulegen, wenn sie andere Verträge aufrufen. Nicht-EOF-Verträge müssen bei der Durchführung von Speichervorgängen für alle Gasarten zahlen (wenn beispielsweise SLOAD 0,031 TP9T des Gaslimits für den Blockspeicherzugriff beansprucht, werden Nicht-EOF-Benutzern auch 0,031 TP9T der Ausführungsgebühr für das Gaslimit berechnet).

Weitere Forschungen zu mehrdimensionalem Gas werden zum Verständnis dieser Kompromisse beitragen und dabei helfen, das ideale Gleichgewicht zu finden.

Wie interagiert es mit dem Rest der Roadmap?

Die erfolgreiche Implementierung von mehrdimensionalem Gas kann die Ressourcennutzung im schlimmsten Fall erheblich reduzieren und so den Druck verringern, die Leistung zu optimieren, um Anforderungen wie binäre Bäume auf Basis von STARKed-Hashes zu unterstützen. Das Setzen eines klaren Ziels für das Wachstum der Zustandsgröße erleichtert es Client-Entwicklern, zukünftige Anforderungen zu planen und abzuschätzen.

Wie bereits erwähnt, erleichtert die Existenz von EOF aufgrund seiner unbeobachtbaren Natur die Implementierung extremerer Versionen von mehrdimensionalem Gas.

Überprüfbare Verzögerungsfunktionen (VDFs)

Welches Problem löst es?

Derzeit verwendet Ethereum RANDAO-basierte Zufälligkeit, um Antragsteller auszuwählen. Die Zufälligkeit von RANDAO funktioniert, indem von jedem Antragsteller verlangt wird, ein Geheimnis preiszugeben, zu dessen Offenlegung er sich im Voraus verpflichtet hat, und jedes offenbarte Geheimnis in die Zufälligkeit eingemischt wird.

Jeder Antragsteller hat also 1 Bit Macht: Er kann die Zufälligkeit ändern, indem er nicht auftaucht (gegen einen Preis). Dies ist sinnvoll, um Antragsteller zu finden, da es sehr selten vorkommt, dass Sie eine Gelegenheit aufgeben, zwei neue zu bekommen. Aber es ist nicht ideal für On-Chain-Anwendungen, die Zufälligkeit benötigen. Idealerweise sollten wir eine robustere Quelle für Zufälligkeit finden.

Was ist ein VDF und wie funktioniert es?

Eine verifizierbare Verzögerungsfunktion ist eine Funktion, die nur sequentiell berechnet werden kann und nicht durch Parallelisierung beschleunigt werden kann. Ein einfaches Beispiel ist wiederholtes Hashing: for i in range(10**9): x = hash(x). Die Ausgabe wird mit SNARK als korrekt nachgewiesen und kann als Zufallswert verwendet werden.

Die Idee ist, dass die Eingaben auf der Grundlage der zum Zeitpunkt T verfügbaren Informationen ausgewählt werden, während die Ausgaben zum Zeitpunkt T noch nicht bekannt sind: Die Ausgaben sind erst irgendwann nach T verfügbar, wenn jemand die Berechnung vollständig ausgeführt hat. Da jeder die Berechnung ausführen kann, besteht keine Möglichkeit, die Ergebnisse zu verbergen und sie daher auch nicht zu manipulieren.

Das Hauptrisiko bei überprüfbaren Verzögerungsfunktionen besteht in einer versehentlichen Optimierung: Jemand findet einen Weg, die Funktion schneller als erwartet auszuführen und manipuliert dadurch die Informationen, die sie zum Zeitpunkt T preisgibt.

Eine versehentliche Optimierung kann auf zwei Arten erfolgen:

1. Hardwarebeschleunigung: Jemand erstellt einen ASIC, der Rechenzyklen schneller ausführt als vorhandene Hardware.

2. Versehentliche Parallelisierung: Jemand findet einen Weg, eine Funktion durch Parallelisierung schneller auszuführen, selbst wenn dies 100-mal mehr Ressourcen erfordert.

Die Aufgabe bei der Erstellung eines erfolgreichen VDF besteht darin, diese beiden Probleme zu vermeiden und gleichzeitig die Effizienz praktisch zu erhalten (ein Problem bei hashbasierten Ansätzen ist beispielsweise, dass das SNARKing von Hashes in Echtzeit eine leistungsstarke Hardware erfordert). Die Hardwarebeschleunigung wird normalerweise dadurch erreicht, dass ein Akteur im öffentlichen Interesse einen nahezu optimalen VDF-ASIC selbst erstellt und verteilt.

Links zu bestehender Forschung

VDF-Forschungswebsite: www.vdfresearch.org

Denken zu Angriffen auf VDF in Ethereum, 2018:

Angriffe gegen MinRoot

Welche Aufgaben und Kompromisse bleiben noch übrig?

Derzeit gibt es keine einzige VDF-Konstruktion, die alle Anforderungen der Ethereum-Forscher vollständig erfüllt. Es bedarf weiterer Arbeit, um eine solche Funktion zu finden. Wenn eine solche Funktion gefunden wird, besteht der wichtigste Kompromiss darin, ob sie einbezogen werden soll: ein einfacher Kompromiss zwischen Funktionalität und Protokollkomplexität sowie Sicherheitsrisiken.

Wenn wir glauben, dass ein VDF sicher ist, sich aber als unsicher herausstellt, dann wird die Sicherheit je nach Implementierung auf die RANDAO-Annahme (1 Bit Kontrolle pro Angreifer) oder etwas schlechter herabgestuft. Selbst wenn das VDF also ausfällt, wird es das Protokoll nicht beschädigen, wohl aber Anwendungen oder neue Protokollfunktionen, die stark darauf angewiesen sind.

Wie interagiert es mit dem Rest der Roadmap?

VDFs sind eine relativ in sich geschlossene Komponente des Ethereum-Protokolls, die neben der Erhöhung der Sicherheit bei der Auswahl des Antragstellers auch Anwendung in (i) On-Chain-Anwendungen findet, die auf Zufälligkeit basieren, und (ii) kryptografischen Mempools. Allerdings ist für die Erstellung kryptografischer Mempools auf Basis von VDFs noch immer auf zusätzlichen kryptografischen Entdeckungen aufgebaut, die bisher noch nicht gemacht wurden.

Ein wichtiger Punkt, den man bedenken sollte, ist, dass es aufgrund der Unsicherheit in der Hardware einen gewissen Spielraum zwischen der Erstellung der VDF-Ausgabe und dem Zeitpunkt gibt, an dem sie benötigt wird. Das bedeutet, dass die Informationen mehrere Blöcke früher verfügbar sein werden. Dies kann ein akzeptabler Kostenfaktor sein, sollte aber bei Designs zur Single-Slot-Finalisierung oder zur Auswahl durch Komitees berücksichtigt werden.

Verschleierung und Einmalsignaturen: die ferne Zukunft der Kryptographie

Welches Problem löst es?

Einer der berühmtesten Artikel von Nick Szabo ist sein 1997 erschienenes Papier über das „God Protocol“. In diesem Papier stellte er fest, dass viele Mehrparteienanwendungen auf eine „vertrauenswürdige dritte Partei“ angewiesen sind, um Interaktionen zu verwalten. Seiner Ansicht nach besteht die Rolle der Kryptografie darin, eine simulierte vertrauenswürdige dritte Partei zu schaffen, die dieselbe Aufgabe erfüllt, ohne dass tatsächlich Vertrauen in einen bestimmten Teilnehmer erforderlich ist.

Bisher haben wir dieses Ideal nur teilweise erreicht. Wenn wir nur einen transparenten virtuellen Computer wollen, dessen Daten und Berechnungen nicht abgeschaltet, zensiert oder manipuliert werden können, und Privatsphäre kein Ziel ist, dann kann Blockchain dieses Ziel erreichen, wenn auch mit begrenzter Skalierbarkeit.

Wenn Datenschutz das Ziel ist, konnten wir bis vor kurzem nur einige wenige spezifische Protokolle für bestimmte Anwendungen entwickeln: digitale Signaturen für die Basisauthentifizierung, Ringsignaturen und verknüpfbare Ringsignaturen für reine Anonymität, identitätsbasierte Verschlüsselung für bequemere Verschlüsselung unter bestimmten Annahmen über vertrauenswürdige Herausgeber, Blindsignaturen für elektronisches Bargeld im Charm-Stil usw. Dieser Ansatz erfordert für jede neue Anwendung viel Arbeit.

In den 2010er Jahren erhielten wir erstmals einen Einblick in einen anderen und leistungsfähigeren Ansatz, der auf programmierbarer Kryptografie basiert. Anstatt für jede neue Anwendung ein neues Protokoll zu erstellen, können wir leistungsstarke neue Protokolle – insbesondere ZK-SNARKs – verwenden, um beliebigen Programmen kryptografische Garantien hinzuzufügen.

Mit ZK-SNARKs können Benutzer beliebige Aussagen über die von ihnen gespeicherten Daten beweisen. Die Beweise sind (i) leicht überprüfbar und (ii) geben keine anderen Daten preis als die Aussage selbst. Dies ist sowohl in Bezug auf Datenschutz als auch Skalierbarkeit ein großer Fortschritt, und ich vergleiche es mit der Wirkung von Transformatoren in der KI. Tausende von Mannjahren anwendungsspezifischer Arbeit wurden plötzlich durch diese allgemeine Lösung ersetzt, die ein unerwartet breites Spektrum an Problemen bewältigen kann.

ZK-SNARKs sind jedoch nur das erste von drei ähnlichen extrem mächtigen allgemeinen Primitiven. Diese Protokolle sind so mächtig, dass sie mich, wenn ich an sie denke, an einen Satz extrem mächtiger Karten in Yu-Gi-Oh! erinnern – dem Kartenspiel und der Fernsehsendung, die ich als Kind gespielt habe: die Egyptian Gods Cards.

Die ägyptischen Götterkarten sind drei extrem mächtige Karten. Der Legende nach kann der Herstellungsprozess dieser Karten tödlich sein, und ihre Macht macht ihre Verwendung in Duellen verboten. In ähnlicher Weise gibt es in der Kryptographie diesen Satz von drei ägyptischen Götterprotokollen:

Was sind ZK-SNARKs und wie funktionieren sie?

ZK-SNARKs ist eines der drei Protokolle, die wir bereits haben, mit einem hohen Reifegrad. In den letzten fünf Jahren haben die dramatischen Verbesserungen bei der Geschwindigkeit des Prüfers und der Entwicklerfreundlichkeit ZK-SNARKs zu einem Eckpfeiler der Skalierbarkeits- und Datenschutzstrategie von Ethereum gemacht. ZK-SNARKs haben jedoch eine wichtige Einschränkung: Sie müssen die Daten kennen, um sie nachzuweisen. Jeder Status in einer ZK-SNARK-Anwendung muss einen eindeutigen Eigentümer haben, der anwesend sein muss, um das Lesen oder Schreiben dieses Status zu genehmigen.

Das zweite Protokoll, das diese Einschränkung nicht hat, ist die vollständig homomorphe Verschlüsselung (FHE), mit der Sie beliebige Berechnungen an verschlüsselten Daten durchführen können, ohne die Daten jemals anzusehen. Auf diese Weise können Sie Berechnungen an den Benutzerdaten zum Nutzen der Benutzer durchführen und gleichzeitig die Daten und den Algorithmus vertraulich halten.

Außerdem können Sie damit Wahlsysteme wie MACI skalieren, um nahezu perfekte Sicherheits- und Datenschutzgarantien zu erhalten. FHE galt lange als zu ineffizient für den praktischen Einsatz, doch jetzt ist es endlich effizient genug, um in der Praxis eingesetzt zu werden.

Cursive ist eine Anwendung, die Zweiparteienberechnungen und vollständig homomorphe Verschlüsselung (FHE) zur datenschutzkonformen Ermittlung gemeinsamer Interessen nutzt.

Allerdings hat FHE auch seine Grenzen: Jede auf FHE basierende Technologie erfordert immer noch jemanden, der den Entschlüsselungsschlüssel besitzt. Dies kann ein M-von-N-verteiltes Setup sein, und Sie können sogar Trusted Execution Environments (TEEs) verwenden, um eine zweite Schutzebene hinzuzufügen, aber es ist immer noch eine Einschränkung.

Als nächstes kommt das dritte Protokoll, das noch leistungsfähiger ist als die ersten beiden zusammen: Ununterscheidbarkeitsverschleierung. Obwohl diese Technologie noch lange nicht ausgereift ist, verfügen wir seit 2020 über theoretisch gültige Protokolle, die auf Standardsicherheitsannahmen basieren, und wir haben vor kurzem begonnen, sie zu implementieren.

Mit der nicht unterscheidbaren Verschleierung können Sie ein kryptografisches Programm erstellen, das beliebige Berechnungen durchführt und dabei alle internen Details des Programms verbirgt. Ein einfaches Beispiel: Sie können Ihren privaten Schlüssel in ein verschleiertes Programm einfügen, das Sie nur zum Signieren von Primzahlen verwenden können, und dieses Programm an andere verteilen. Diese können mit diesem Programm jede beliebige Primzahl signieren, aber sie können den Schlüssel nicht extrahieren. Die Möglichkeiten gehen jedoch weit darüber hinaus: In Kombination mit Hashing können damit beliebige andere kryptografische Grundelemente und mehr implementiert werden.

Das Einzige, was ein unkenntlich verschleiertes Programm nicht kann, ist, sich selbst vor dem Kopieren zu schützen. Doch dafür steht eine leistungsfähigere Technologie in den Startlöchern, die allerdings voraussetzt, dass jeder über einen Quantencomputer verfügt: Quanten-One-Shot-Signaturen.

Durch die Kombination von Verschleierung und Einmalsignaturen können wir eine nahezu perfekte vertrauenslose dritte Partei aufbauen. Das einzige Ziel, das allein durch Kryptographie nicht erreicht werden kann und noch durch die Blockchain garantiert werden muss, ist die Zensurresistenz. Diese Technologien können nicht nur Ethereum selbst sicherer machen, sondern auch leistungsfähigere Anwendungen darauf aufbauen.

Um besser zu verstehen, wie diese Primitiven zusätzliche Fähigkeiten hinzufügen, verwenden wir Abstimmungen als Schlüsselbeispiel. Abstimmungen sind ein interessantes Problem, da sie viele komplexe Sicherheitseigenschaften erfüllen müssen, darunter sehr starke Verifizierbarkeit und Datenschutz. Obwohl es seit Jahrzehnten Abstimmungsprotokolle mit starken Sicherheitseigenschaften gibt, können wir es uns selbst schwerer machen, indem wir Designs verlangen, die beliebige Abstimmungsprotokolle verarbeiten können: quadratische Abstimmungen, paarweise eingeschränkte quadratische Finanzierung, quadratische Finanzierung mit Cluster-Matching und so weiter. Mit anderen Worten: Wir möchten, dass der Schritt des Stimmenzählens ein beliebiges Programm ist.

Nehmen wir zunächst an, dass wir die Wahlergebnisse öffentlich in die Blockchain stellen. Dies gibt uns öffentliche Verifizierbarkeit (jeder kann überprüfen, ob das Endergebnis korrekt ist, einschließlich der Regeln für die Auszählung und Berechtigung) und Zensurresistenz (die Leute können nicht daran gehindert werden, ihre Stimme abzugeben). Aber wir haben keine Privatsphäre.

Dann haben wir ZK-SNARKs hinzugefügt und jetzt haben wir Privatsphäre: Jede Stimme ist anonym, während gleichzeitig sichergestellt wird, dass nur autorisierte Wähler abstimmen können und jeder Wähler nur einmal abstimmen kann.

Als Nächstes haben wir den MACI-Mechanismus eingeführt, bei dem Stimmen mit einem Entschlüsselungsschlüssel eines zentralen Servers verschlüsselt werden. Der zentrale Server ist für den Stimmenzählprozess verantwortlich, einschließlich der Entfernung doppelter Stimmen und der Veröffentlichung eines ZK-SNARK-Nachweises des Ergebnisses. Dadurch bleiben die vorherigen Garantien erhalten (selbst wenn der Server betrügt!), aber wenn der Server ehrlich ist, wird auch eine Garantie der Widerstandsfähigkeit gegen Zwang hinzugefügt: Benutzer können nicht beweisen, wie sie abgestimmt haben, selbst wenn sie es wollten. Dies liegt daran, dass Benutzer zwar ihre Stimme beweisen können, aber nicht beweisen können, dass sie nicht abgestimmt haben, um diese Stimme auszugleichen. Dies verhindert Bestechung und andere Angriffe.

Wir führen die Stimmenauszählung in FHE durch und berechnen dann die N/2-von-N-Schwellenwert-Entschlüsselung. Dadurch wird die Anti-Zwangsgarantie auf N/2-von-N anstelle von 1-von-1 verbessert.

Wir verschleiern das Zählprogramm und gestalten es so, dass es nur Ergebnisse ausgeben kann, wenn es autorisiert ist, was ein Beweis für einen Blockchain-Konsens, eine Art Arbeitsnachweis oder eine Kombination aus beidem sein kann. Dies macht die Anti-Zwangsgarantie nahezu perfekt: Im Falle eines Blockchain-Konsens müssen 51% der Validierer zusammenarbeiten, um ihn zu brechen; im Falle eines Arbeitsnachweises wird es, selbst wenn alle zusammenarbeiten, extrem teuer, die Stimmen mit einer anderen Teilmenge von Wählern neu zu zählen, um zu versuchen, das Verhalten eines einzelnen Wählers zu extrahieren. Wir können das Programm sogar kleine zufällige Anpassungen an der endgültigen Zählung vornehmen lassen, um die Schwierigkeit, das Verhalten eines einzelnen Wählers zu extrahieren, noch weiter zu erhöhen.

Wir haben Einmalsignaturen hinzugefügt, ein Primitiv, das auf Quanteninformatik basiert und es ermöglicht, eine Signatur nur einmal für einen bestimmten Informationstyp zu verwenden. Dies macht die Anti-Zwangsgarantie wirklich perfekt.

Die nicht unterscheidbare Verschleierung unterstützt auch andere leistungsstarke Anwendungen. Zum Beispiel:

1. Dezentrale autonome Organisationen (DAOs), On-Chain-Auktionen und andere Anwendungen mit beliebigen internen geheimen Zuständen.

2. Ein wirklich universelles vertrauenswürdiges Setup: Jemand kann ein verschleiertes Programm erstellen, das einen Schlüssel enthält, und jedes Programm ausführen und die Ausgabe bereitstellen, indem er hash(Schlüssel, Programm) als Eingabe in das Programm eingibt. Bei einem solchen Programm kann jeder Programm 3 in sich selbst einfügen, indem er den Vorschlüssel des Programms und seinen eigenen Schlüssel kombiniert und so das Setup erweitert. Dies kann verwendet werden, um ein vertrauenswürdiges 1-aus-N-Setup für jedes Protokoll zu generieren.

3. Für die Überprüfung von ZK-SNARKs ist nur eine Signatur erforderlich: Die Implementierung ist ganz einfach: Richten Sie eine vertrauenswürdige Umgebung ein und lassen Sie jemanden einen Obfuscator erstellen, der Nachrichten nur dann mit dem Schlüssel signiert, wenn ein gültiger ZK-SNARK vorhanden ist.

4. Verschlüsselter Speicherpool: Es ist sehr einfach, Transaktionen zu verschlüsseln, sodass sie nur entschlüsselt werden können, wenn in der Zukunft ein Ereignis in der Kette eintritt. Dies kann sogar eine erfolgreich ausgeführte verifizierbare Verzögerungsfunktion (VDF) umfassen.

Mit Einmalsignaturen können wir Blockchains immun gegen 51%-Angriffe mit Finalitätsumkehr machen, obwohl Zensurangriffe weiterhin möglich sind. Primitive wie Einmalsignaturen machen Quantengeld möglich und lösen das Problem der Doppelausgabe ohne Blockchain, obwohl viele komplexere Anwendungen immer noch eine Kette erfordern.

Wenn diese Grundelemente effizient genug gestaltet werden können, können die meisten Anwendungen der Welt dezentralisiert werden. Der größte Engpass wird die Überprüfung der Richtigkeit der Implementierung sein.

Hier sind einige Links zu bestehenden Forschungsarbeiten:

1. Ununterscheidbarkeit Verschleierung (2021):

2. Wie Verschleierung Ethereum helfen kann

3. Erste bekannte Konstruktion von One-Shot-Signaturen

4. Versuchte Implementierung einer Verschleierung (1)

5. Versuchte Implementierung einer Verschleierung (2)

Welche Arbeit bleibt noch zu erledigen und was sind die Kompromisse?

Es bleibt noch viel zu tun, und die nicht unterscheidbare Verschleierung ist noch sehr unausgereift. Die möglichen Konstruktionen laufen so langsam (wenn nicht sogar langsamer) als erwartet und sind daher für Anwendungen unbrauchbar. Die nicht unterscheidbare Verschleierung ist dafür bekannt, dass sie theoretisch polynomiale Laufzeit hat, in der Praxis kann ihre Laufzeit jedoch länger sein als die Lebensdauer des Universums. Neuere Protokolle haben diese Laufzeit etwas verkürzt, aber der Aufwand ist für den Routinegebrauch immer noch zu hoch: Ein Implementierer schätzt die Laufzeit auf ein Jahr.

Quantencomputer gibt es noch nicht einmal: Alle Konstruktionen, die Sie im Internet sehen, sind entweder Prototypen, die nicht mehr als 4-Bit-Operationen ausführen können, oder es handelt sich überhaupt nicht um substantielle Quantencomputer, und obwohl sie möglicherweise Quantenteile enthalten, können sie keine sinnvollen Berechnungen wie Shors- oder Grovers-Algorithmen ausführen. Es gibt neuere Anzeichen dafür, dass echte Quantencomputer nicht mehr weit entfernt sind. Doch selbst wenn echte Quantencomputer bald auftauchen, kann es Jahrzehnte dauern, bis normale Menschen Quantencomputer auf ihren Laptops oder Telefonen verwenden können, bis der Tag kommt, an dem mächtige Institutionen die elliptische Kurvenkryptographie knacken können.

Bei der ununterscheidbaren Verschleierung liegt ein wichtiger Kompromiss in den Sicherheitsannahmen, und es gibt aggressivere Designs, die spezielle Annahmen verwenden. Diese Designs haben oft realistischere Laufzeiten, aber die speziellen Annahmen können manchmal gebrochen werden. Mit der Zeit verstehen wir Gitter vielleicht besser und kommen zu Annahmen, die weniger bruchanfällig sind. Dieser Weg ist jedoch riskanter. Ein konservativerer Ansatz wäre, bei Protokollen zu bleiben, deren Sicherheit nachweislich auf Standardannahmen reduziert wird, aber das kann bedeuten, dass es länger dauert, ein Protokoll zu erhalten, das schnell genug läuft.

Wie interagiert es mit dem Rest der Roadmap?

Extrem starke Kryptographie könnte das Spiel revolutionieren, zum Beispiel:

1. Wenn wir es schaffen, dass die Verifizierung von ZK-SNARKs genauso einfach ist wie die Signierung, brauchen wir möglicherweise kein Aggregationsprotokoll mehr; wir können die Verifizierung direkt in der Kette durchführen.

2. Einmalsignaturen könnten sicherere Proof-of-Stake-Protokolle bedeuten.

3. Viele komplexe Datenschutzprotokolle erfordern möglicherweise nur eine datenschutzerhaltende Ethereum Virtual Machine (EVM), um sie zu ersetzen.

4. Verschlüsselte Speicherpools lassen sich einfacher implementieren.

Zunächst werden die Vorteile auf der Anwendungsebene sichtbar, da Ethereums L1 in seinen Sicherheitsannahmen von Natur aus konservativ sein muss. Die Nutzung allein auf der Anwendungsebene könnte jedoch störend sein, wie es beim Aufkommen von ZK-SNARKs der Fall war.

Ursprünglicher Link

Dieser Artikel stammt aus dem Internet: Vitaliks neuer Artikel: Die mögliche Zukunft von Ethereum, The Splurge

Verwandt: Grayscale wählt sorgfältig 35 Token aus: FDV mindestens 300 Millionen US-Dollar, besser geeignet für Großinvestoren

Original | Odaily Planet Daily ( @OdailyChina ) Autor | Fu Howe ( @vincent 31515173 ) Als eine der Brücken zwischen Web3 und Mainstream-Finanzen haben Grayscales Initiativen in der Kryptoindustrie viel Aufmerksamkeit erregt. Von den anfänglichen Vertrauensprodukten von Bitcoin, Ethereum und vielen bekannten Token bis hin zur Einführung von Bitcoin Spot ETF und Ethereum Spot ETF in diesem Jahr ist Grayscales Beitrag zur Kryptoindustrie für alle offensichtlich. Kürzlich hat Grayscale 35 Krypto-Assets aufgelistet, die es in Zukunft zu seinen Produkten hinzufügen möchte. Zu diesem Zweck hat Odaily Planet Daily die 35 Währungen zunächst nach Track klassifiziert und sie dann nach dem Marktwert jeder Währung sortiert und die Preistrends der letzten zwei Jahre anhand von Diagrammen mit den Lesern geteilt. Es gibt insgesamt…