ERC-4337 vs. EIP-3074: Falsche Dichotomie

Was ist Kontoabstraktion?

Jedes Ethereum-Konto implementiert fünf Funktionalitäten:

• Authentifizierung
• Genehmigung
• Wiedergabeschutz
• Gaszahlung
• Ausführung

Eine EOA implementiert sie auf fest codierte Weise:

• Authentifizierung und Autorisierung sind gebündelt: Ein unveränderlicher ECDSA-Schlüssel weist die Identität nach und gewährt volle Autorität.
• Der Wiederholungsschutz ist eine einfache Nonce – ein monoton steigender Zähler.
• Die Gaszahlung erfolgt direkt aus dem ETH-Guthaben der EOA.
• Ausführung – ein einzelner Aufruf an ein einzelnes Ziel.

Kontoabstraktion bedeutet, programmatische Logik zu diesen fünf Funktionalitäten hinzuzufügen:

• Authentifizierung – jede Form des Identitätsnachweises.
• Autorisierung – jede Zugriffsrichtlinie.
• Wiederholungsschutz – Transaktionsreihenfolge entkoppelt vom Wiederholungsschutz.
• Gaszahlung – vom Konto selbst entkoppelte Gaszahlung.
• Ausführung – beliebige Ausführungslogik.

Beispiele für Anwendungsfälle der Kontoabstraktion

• Verschiedene Signaturschemata
  • secp256r1 (sichere Enklave, Passkeys)
  • Schnorr
  • BLS
  • Postquantum
  • ZK-Beweise (z. B zkemail)
• Schlüsseldrehung
  • Ersetzen Sie kompromittierte Schlüssel
  • Deadman-Schalter zur Vererbung (Schlüssel wird aktiv, wenn das Konto ein Jahr lang inaktiv ist)
• Unterschiedliche Zugriffsrichtlinien
  • Multisig
  • Rollenbasierter Zugriff
  • Dapp-spezifische Sitzungsschlüssel
  • Sozialer Aufschwung
• Verschiedene Wiedergabeschutzschemata
  • Parallele Transaktionen von verschiedenen Einheiten
  • Vorab unterzeichnete zukünftige Transaktionen, die von Dritten gesendet werden sollen
  • Verwaltungskanal
• Gasentnahme
  • Gassponsoring durch Dritte
  • Zahlung mit anderen Vermögenswerten als der ETH
  • Datenschutz: Anonyme Airdrop-Ansprüche oder Rückzug aus ZK-Rollups oder Mixern
• Ausführungsabstraktion
  • Mehrere Anrufe an mehrere Ziele bündeln (z. B genehmigen+übertragenvon)
  • Atomarität
  • Dapp-spezifische UX-Verbesserungen

ERC-4337 vs. EIP-3074: Falsche Dichotomie

EIP-3074 zielt darauf ab, die Ausführung zu abstrahieren, indem der EOA durch Aufrufer mit willkürlicher Ausführungslogik aufgeladen wird. Es verfügt über eine einzigartige Eigenschaft: Es erweitert die Funktionen eines EOA, ohne dass Vermögenswerte auf ein neues Konto migriert werden müssen. Probleme wie der dezentrale Zugriff müssen nicht behandelt werden, da die Ausführung keinen Einfluss darauf hat. Die anderen vier Funktionalitäten sind zwar vorhanden, liegen jedoch außerhalb des Geltungsbereichs von EIP-3074.

ERC-4337 zielt darauf ab, das gesamte Konto zu abstrahieren – alle fünf Funktionalitäten. Es ist schwieriger zu lösen, wenn Dezentralisierung und Zensurresistenz erhalten bleiben sollen. Der Schwerpunkt von ERC-4337 liegt auf der Eindämmung von DoS- und Griefing-Angriffsvektoren, die durch die Abstraktion der ersten vier Funktionalitäten ermöglicht werden, ohne auf eine zentralisierte Infrastruktur zurückzugreifen. Als ERC kann es die Funktionen eines EOA nicht erweitern und erfordert die Migration auf ein Smart-Konto.

Die Überschneidung zwischen den beiden Methoden ist minimal: nur Ausführungsabstraktion.

Darüber hinaus zielt jede Methode darauf ab, Probleme zu lösen, die die andere nicht löst: EIP-3074 zielt darauf ab, bestehende EOAs zu bedienen und die Dinge so einfach wie möglich zu halten. ERC-4337 zielt darauf ab, eine vollständige Kontoabstraktion bereitzustellen, ohne die Kerneigenschaften von Ethereum, wie z. B. die Dezentralisierung, zu opfern.

Wenn man darauf besteht, ERC-4337 mit einem früheren Vorschlag zu vergleichen, ist EIP-2938 der nächstgelegene, nicht EIP-3074. EIP-2938 war ein Durchbruch in der Kontoabstraktion, der erste Vorschlag, der die Schwierigkeit der DoS-Abwehr in einem AA-Mempool erkannte. ERC-4337 löst bestimmte Probleme, die EIP-2938 nicht löste, ein vollständiger Vergleich würde jedoch den Rahmen dieses Dokuments sprengen.

Was können sowohl ERC-4337 als auch EIP-3074 lösen?

Beide lösen die Ausführungsabstraktion und ermöglichen daher die letzte Kategorie der oben genannten Anwendungsfälle:

• Mehrere Anrufe an mehrere Ziele bündeln
• Atomarität
• Dapp-spezifische UX-Verbesserungen

Was kann EIP-3074, was ERC-4337 nicht kann?

• Fügen Sie komplexe Ausführungsfunktionen zu bestehenden EOAs hinzu.
  • ERC-4337 kann EOAs keine Funktionalität hinzufügen, da es sich um einen ERC handelt.
• Einfachheit und bessere Gaseffizienz, wenn nur Ausführungsabstraktion erforderlich ist.
  • Die vollständige Kontoabstraktion erhöht die Komplexität, die für die Ausführungsabstraktion nicht erforderlich ist.

Was kann ERC-4337, was EIP-3074 nicht kann?

• Unterstützen Sie jede EVM-Kette am ersten Tag. Keine Konsensänderungen.
  • EIP-3074 müsste von jeder Kette durch eine Konsensänderung übernommen werden.
• Erlaubnislose Innovation
  • Wallets erlauben nur EIP-3074-Aufrufer auf der Whitelist. ERC-4337-Konten können von jedem erstellt und genutzt werden.
• Vollständige Kontoabstraktion – alle oben genannten Anwendungsfälle, ohne auf Dezentralisierung zu verzichten:
  • Verschiedene Signaturschemata.
    • EIP-3074 verwendet ECDSA. Die EIP erwähnt zwar einen zukünftigen Weg für den Wechsel zu einem anderen Schema, aber solange die EOA selbst den ECDSA-Schlüssel berücksichtigt, kann ein Aufrufer nicht verhindern, dass er direkt verwendet wird.
  • Schlüsseldrehung.
    • Mit EIP-3074 verfügt die EOA weiterhin über einen unwiderruflichen Schlüssel.
  • Unterschiedliche Zugriffsrichtlinien
    • Der ECDSA-Schlüssel kann den Aufrufer umgehen und jeden Vorgang im Konto ausführen. Keine granulare Zugriffskontrolle.
  • Verschiedene Wiedergabeschutzschemata
    • Das Konto ist immer noch ein EOA und verwendet eine eindimensionale Nonce.
  • Gasentnahme
    • Das Konto bezahlt sein eigenes Gas mit der ETH.
    • Auf EIP-3074 könnte ein Gasabzugssystem aufgebaut werden, das ein Relay verwendet, um Metatransaktionen im Namen des Kontos zu senden. Der Schutz solcher Relays vor DoS und Griefing stellt jedoch eine Herausforderung dar, weshalb sie wahrscheinlich zugelassen werden. Der größte Teil der ERC-4337-Komplexität ist darauf zurückzuführen, dass diese Relayer (Bündeler) ohne Erlaubnis bleiben.

Kann EIP-3074 + EIP-5003 das tun, was ERC-4337 tut?

EIP-5003 ergänzt EIP-3074, indem es der EOA erlaubt, ihren ECDSA-Schlüssel zu widerrufen und zu einem Smart Contract zu werden. Als Vertrag kann er die restlichen Kontofunktionen abstrahieren, z ECDSA durch eine andere Signatur ersetzen, Schlüssel rotieren, Zugriffsrichtlinien anwenden usw. In diesem Sinne entspricht es in gewisser Weise Vorschlägen wie EIP-6913 und EIP-7377, ist jedoch EIP-7377 überlegen, da es als Opcode ein Gasabstraktionssystem für die Migration selbst verwenden kann.

Sobald die EOA in einen Smart Contract umgewandelt wurde, können keine Transaktionen mehr direkt durchgeführt werden und der Zugriff muss über eine andere EOA erfolgen. Dies stellt die Herausforderung dar, die ERC-4337 lösen soll. Der Benutzer hat nach der Migration zwei Möglichkeiten, mit dem Konto Transaktionen durchzuführen:

1. Führen Sie eine weitere finanzierte EOA für Transaktionen mit dem Konto durch und unterzeichnen Sie jede Transaktion zweimal. Dies macht den Wert der Kontoabstraktion zunichte und führt zu einer schlechten UX.
2. Verwenden Sie ein Relay, das eine finanzierte EOA aufrechterhält, die Transaktionen in die Kette bringt und vom Konto erstattet wird. Der Schutz eines solchen Relays vor DoS und Griefing ist schwieriger als es scheint, daher betreiben einige Projekte ein autorisiertes Relay. Dies führt zu einem Verlust der Dezentralisierung und Zensurresistenz.

Die Möglichkeit, den Kontozugriff nach der Migration zu dezentralisieren, besteht darin, bestimmte Einschränkungen anzuwenden, bis das Konto den Sprit bezahlt. Dieser Ansatz wurde sowohl von EIP-2938 als auch von ERC-4337 verfolgt. Der<a href="https://notes.ethereum.org/ @yoav /unified-erc-4337-mempool">ERC-4337 mempool bietet eine dezentrale Möglichkeit, mit dem Konto Transaktionen durchzuführen.

TL;DR: Nein, es unterstreicht nur die Notwendigkeit von ERC-4337.

Vorsichtsmaßnahme: EOA-Migration gilt als schädlich

Für bestehende EOA-Benutzer ist es verlockend, direkt auf ein Smart-Konto zu migrieren, anstatt Vermögenswerte zu übertragen. Es birgt jedoch gewisse Schwachstellen, von denen einige nicht gemindert werden können.

Was könnte schiefgehen, wenn der EOA-Schlüssel kompromittiert wird, nachdem er widerrufen wurde?

1. Der Schlüssel bleibt für andere Ketten gültig (einschließlich zukünftiger Ketten, die zum Zeitpunkt der Migration noch nicht einmal vorhanden sind). Es kann verwendet werden, um dasselbe Konto bei anderen Ketten zu beanspruchen und alle auf das Konto dieser Ketten gesendeten Vermögenswerte zu übertragen.
2. Off-Chain-Systeme wie der Login-Prozess von Dapp-Frontends prüfen Signaturen. Viele von ihnen unterstützen EIP-1271 für intelligente Vertragssignaturen, versuchen es aber nur, wenn ecrecover fehlschlägt. Der Schlüssel könnte dazu verwendet werden, das Konto auf diesen Systemen zu kompromittieren.
3. Es kann in der Kette (in derselben Kette, in der es widerrufen wurde) zum Signieren von Genehmigungsautorisierungen verwendet werden. Wenn das Konto ERC-20-Token enthält, die Permit unterstützen, können diese Token mit dem widerrufenen Schlüssel gestohlen werden.
4. Cross-Chain-Bridges überprüfen beim Abheben häufig eine Signatur. Wenn das Konto über eine solche Brücke Gelder an eine andere Kette sendet, kann der widerrufene Schlüssel zum Abheben der Gelder auf der anderen Seite verwendet werden.

Der Benutzer könnte den privaten Schlüssel nach der Migration brennen und hoffen, dass keine Kopien übrig bleiben, aber dann kann der Benutzer auch nicht die gleiche Adresse auf anderen Ketten beanspruchen.

Daher sollte die Migration als letztes Mittel eingesetzt werden, wenn es einen triftigen Grund gibt, die alte Adresse beizubehalten. Standardmäßig werden neue Konten am besten mit CREATE2 bereitgestellt und nicht von einer EOA migriert, sodass sie nicht mit einem EOA-Schlüssel in anderen Ketten verknüpft sind.

Die Community neigt dazu, die Bedeutung der EOA-Migration zu überbewerten, da die meisten aktuellen Benutzer über EOAs verfügen. Die nächste Milliarde Nutzer könnten mit einem Smart-Konto beginnen und müssten nicht von einem EOA migrieren. Wir, die aktuellen EOA-Benutzer, sind nur ein kleiner Teil davon. Die Migration kann für die Migration aktueller Benutzer für eine Weile wichtig sein. Wenn Kontoabstraktion die Norm ist, wird es zu einem selten genutzten Ablauf.

Gibt es Synergien zwischen ERC-4337 und EIP-3074?

Ja, sie könntenauf interessante Weise kombiniert werden. Wenn eine Kette EIP-3074 übernimmt, könnten Projekte, die ERC-4337 verwenden, es zu ihrem Vorteil nutzen.

RIP-7560: Ein vielversprechender Weg für die Zukunft der Kontoabstraktion

Sowohl EIP-3074 als auch ERC-4337 sind Schritte, um einige der Vorteile der vollständigen nativen Kontoabstraktion zu nutzen. Ersteres konzentriert sich darauf, alle Vorteile der Ausführungsabstraktion zu nutzen, und letzteres konzentriert sich darauf, alle Vorteile der Kontoabstraktion auf allen EVM-Ketten zu nutzen, jedoch auf eine nicht native Weise, die weniger effizient ist.

Eine Kette, die möchte, dass ihre Benutzer von der vollständigen nativen Kontoabstraktion profitieren, könnte RIP-7560 einführen. Es verwendet die gleiche Konto- und Mempool-Architektur wie ERC-4337, funktioniert jedoch nativ auf Protokollebene.

RIP-7560 muss nicht vom ersten Tag an übernommen werden, und bestehende Konten können bei Ketten, die sich für die Einführung entscheiden, jederzeit in der Zukunft darauf migrieren:

• ERC-4337-Konten können ohne Änderung ihrer Architektur auf RIP-7560 migrieren, indem ihre Implementierung so geändert wird, dass sie der in RIP-7560 definierten speziellen EntryPoint-Adresse vertraut. Ein Konto kann mit geringem Aufwand sowohl ERC-4337- als auch RIP-7560-kompatibel sein, sodass keine Migration erforderlich ist.
• EOA kann möglicherweise direkt auf RIP-7560 migrieren, ohne ERC-4337 oder EIP-3074 zu durchlaufen. RIP-7560 unterstützt bereits die Gasentnahme für EOAs. Bei einem zukünftigen RIP könnte die EOA ihren Code festlegen, sei es mithilfe eines Opcodes wie SETCODE (EIP-6913) oder AUTHUSURP (EIP-5003) oder durch Hinzufügen eines TransactionType4-Subtyps ähnlich EIP-7377. Dieser Opcode/Subtyp könnte von einem Migrationsvertrag verwendet werden, der in einer Typ-4-Transaktion (RIP-7560) aufgerufen wird. Von der EOA-Migration wird jedoch <a href="https://notes.ethereum.org/@yoav/erc-4337-vs-eip-3074-false-dichotomy#Caveat:-EOA-migration-considered-harmful"> abgeraten .

RIP-7560 benötigt Ihr Feedback

Wir sammeln Feedback zu RIP-7560, bevor wir dessen Verankerung vorschlagen. Wenn Sie an der nativen Kontoabstraktion interessiert sind, lesen Sie bitte die PR oder nehmen Sie an der Diskussion teil.

Haftungsausschluss:

1. Dieser Artikel wurde von [https://notes.ethereum.org/@ yoav/erc-4337-vs-eip-3074-false-dichotomy@yoav ] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [@yoav]. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte an das Gate Learn- Team, das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.