Vom Verständnis der abstrakten ETH-Kontenrennstrecke von 4337 bis 7702 in der Vergangenheit und Zukunft

Vorwort

Der Artikel besteht aus zwei Hauptabschnitten:

Im ersten Teil wird ausgehend von dem ersten AA-Vorschlag aus dem Jahr 2015 eine Zusammenfassung der bisherigen Eip-Vorschläge erstellt. Dabei sollen die historischen AA-Vorschläge untersucht und die Vor- und Nachteile der verschiedenen Ansätze ganzheitlich bewertet werden.

Im zweiten Abschnitt wird insbesondere das schwache Marktfeedback nach der Einführung von EIP4337 im Vergleich betrachtet, und es wird eine detaillierte Analyse von EIP7702 durchgeführt, das in der nächsten Version des Ethereum-Upgrades integriert werden soll. Sobald dieser Vorschlag umgesetzt ist, wird er die Form von On-Chain-Anwendungen auf umfassende Weise verändern.

EIP-7702 hat eine bahnbrechende Veränderung, lassen Sie uns 14 Herrn genau zuhören.

1. Hintergrund der abstrakten Konten

1.1 Positionierung der abstrakten Bedeutung von Konten

Der Gründer von Ethereum, Vitalik, hat Ende 2023 erneut den Entwicklungsplan für ETH aktualisiert, aber die Einstellungen für die Kontenabstraktion wurden nicht geändert. Das aktuelle Hauptmodell geht von EIP-4337 in die nächste Phase der freiwilligen EOA-Konvertierung (freiwillige Konvertierung von EOA-Konten) über.

Seit der Einführung von EIP4337 (am 1. März 2023 auf der WalletCon in Denver angekündigt, wurde der Kernvertrag ERC-4337, der von Entwicklern der ETH Foundation entworfen und implementiert wurde, nach einer Prüfung durch OpenZeppelin als offiziell eingeführt angesehen Node in der Geschichte).

Obwohl es allgemein anerkannt wird, wird es nicht weit verbreitet verwendet, und in einer so widersprüchlichen Marktsituation wurde der Fortschritt von EIP-7702 deutlich vorverlegt und es wurde bereits bestätigt, dass es in das nächste Upgrade integriert wird.

1.2 Marktsituation der abstrakten Konten

Keine Worte nötig, schauen Sie sich einfach die Daten an.

Nach anderthalb Jahren Entwicklung gibt es unter den Hauptkettenkonten von EIP4337 nur 12 Millionen Adressen, was besonders überraschend ist, dass es auf dem ETH-Hauptnetz nur 6.764 aktive Adressen gibt. Möglicherweise gibt es statistische Probleme, aber zumindest ist die Anzahl der aktiven Adressen im Vergleich zu EOA und CA sehr gering. Schließlich gibt es bereits 270 Millionen unabhängige Adressen im ETH-Hauptnetz (Quelle: ).

Es kann gesagt werden, dass EIP4337 auf dem Mainnet keine substantielle Entwicklung darstellt.

(Grafikdatenquelle:)

Allerdings löscht dies nicht den Kernwert von AA aus, da dies bereits von Anfang an durch das Design von EIP4337 bestimmt wurde und er nicht in der Lage ist, ernsthafte Probleme mit der Abwärtskompatibilität des Mainnets zu bewältigen. Daher explodiert die Anzahl der Adressen von EIP4337 auf L2, die in verschiedenen L2-Ketten eingebettet sind, zusammen mit einer Vielzahl von L2-Ketten. Die monatlich aktiven Benutzer von base- und Polygon-Chain im Juli erreichen jeweils 1 Million und 3 Millionen, was durchaus bemerkenswert ist.

Also, EIP4337 is not designed wrong, it has many advantages, we will summarize them systematically later. The current situation is due to the differences between Mainnet and L2, and they need to use their respective suitable solutions.

2. Was ist ein Kontenabstrakt?

Kontoabstraktion, klingt verwirrend, aber im Wesentlichen löst es das Problem der Eigentumsaufteilung.

Die EVM-Architektur (d. h. Virtuelle Ethereum-Maschine) hat zwei Arten von Konten, externe Konten (EOA) und Vertragskonten (Contract Account). Das Eigentum und die Unterschriftsberechtigung des externen Kontos werden tatsächlich von derselben Einheit gehalten. Personen, die den Private Key besitzen, haben nicht nur das “Eigentum” an diesem Konto, sondern auch das Recht, “alle Vermögenswerte zu unterschreiben und zu übertragen”.

Dies wird durch die Handelsstruktur des Ethereum-Kontos bestimmt.

Aus der Struktur des folgenden Diagramms geht hervor, dass Standardtransaktionen in Ethereum keine Absenderadresse haben. Wenn ich also eine Geldüberweisung getätigt habe, auf welcher Adresse wurden die Mittel tatsächlich ausgegeben? Tatsächlich wird die Absenderadresse durch die VRS-Parameter (d.h. die Benutzersignatur) zurückverfolgt.

Hier geht es um Konzepte wie ECDSA und asymmetrische Verschlüsselung, Einweg-Schwellenfunktionen usw. Wir werden nicht ins Detail gehen, aber insgesamt wird die Sicherheit hier durch Kryptographie gewährleistet, was natürlich zu der aktuellen Situation der Zusammenführung von Eigentumsrechten und der EOA-Adresse führt.

Der Kerneffekt von EIP4337 besteht darin, das Sender Address-Feld im Transaktionsfeld hinzuzufügen, um den Private Key von der verwendeten Adresse zu trennen.

Warum ist die Trennung des Eigentums so wichtig?

Weil das externe Konto (EOA) mehr Probleme aufwirft:

1. Private Key难保护：用户失去Private Key（遗失、Hacker攻击、密码学上的被破解）意味着地失去所有资产。
2. Signatur-Algorithmus: Das Native-Protokoll kann zur Überprüfung von Transaktionen nur den ECDSA-Signatur-Algorithmus verwenden.
3. Hohe Signaturberechtigungen: Kein nativer Mehrfachsignatur (Mehrfachsignatur kann nur über Smart Contracts zur Zusammenarbeit realisiert werden), Einzelsignatur kann beliebige Operationen ausführen.
4. Die Transaktionsgebühr kann nur mit ETH bezahlt werden und Batch-Transaktionen werden nicht unterstützt.
5. Handelsprivatsphäre offenbaren: Einzelhandelstransaktionen erleichtern die Analyse der Privatinformationen des Kontoinhabers.

Die Einschränkungen der Berufung machen es für normale Benutzer schwierig, Ethereum zu verwenden:

Zunächst müssen Benutzer, die eine Anwendung auf dem Ethereum-Netzwerk verwenden, ETH halten (und das Risiko der Preisfluktuation von ETH tragen).

Zweitens müssen Benutzer komplexe Gebührenlogik wie Gaspreis, Gaslimit und Transaktionsblockierung (Nonce-Reihenfolge) behandeln, die für Benutzer zu kompliziert sind.

Schließlich haben viele Blockchain-Wallets oder -Anwendungen versucht, die Benutzererfahrung durch Produktverbesserungen zu verbessern, aber ihre tatsächliche Wirkung ist gering.

Der Weg zur Lösung besteht also darin, die Kontoabstraktion zu realisieren und das Eigentumsrecht (Owner) und das Signaturrecht (Signer) zu entkoppeln, um die oben genannten Probleme nacheinander lösen zu können.

Tatsächlich gibt es viele historische Pläne, die letztendlich alle auf zwei Linien zusammenlaufen werden

3. AA-Historische Vorschlagsstruktur

Es scheint viele Vorschläge zur Lösung des Problems in EIP zu geben, aber letztendlich gibt es nur zwei Kernideen. Daher führen alle bisher nicht genehmigten EIPs zu den aktuellen Lösungsansätzen.

3.1 Der erste Ansatz besteht darin, EOAAdresse in CAAdresse umzuwandeln

Bereits am 15. November 2015 schlug Vitalik im Zusammenhang mit EIP-101 vor, Verträge als neue Struktur für Konten zu verwenden. Die Adresse sollte nur aus Code und Speicherplatz bestehen, die Gebührenunterstützung sollte von ERC20 übernommen werden, und durch vorab kompilierte Verträge sollten native Token in tokenähnliche ERC20 umgewandelt werden, um das Guthaben zu speichern (mit Funktionen wie Abzugsermächtigung usw.). Die Transaktionsfelder sollten auf nur to, startgas, data und code vereinfacht werden.

Es scheint jetzt eine Art großer Sprung nach vorne zu sein, der eine umfassende Änderung des Grunddesigns bewirkt und jedem KontoAdresse seine eigene “Code”-Logik verleiht (was im Grunde genommen das ist, was EIP-7702 jetzt erreichen möchte).

Es können auch andere Funktionen abgeleitet werden, wie zum Beispiel

1. Lassen Sie den Handel mehr Verschlüsselungsalgorithmen verwenden, die durch den inneren Code jeder Adresse zur Festlegung der Authentifizierungsmethode bestimmt werden können
2. Hat Eigenschaften zur Abwehr von quantencomputergestützten Angriffen, da der Code upgrade-fähig ist.
3. Lassen Sie Ether die gleichen funktionalen Merkmale wie der ERC20-Kontrakt haben, und der Kerneffekt besteht darin, die Autorisierung zurückzuhalten, so dass der Verlust der nativen Münze nicht erforderlich ist
4. Erweitern Sie den benutzerdefinierten Speicherplatz des Kontos, kompatibel mit der Wiederherstellung von sozialen Beziehungen, sbt-Unterstützung, der Wiederherstellung des Geheimen Schlüssels usw.

Der Grund, warum es nicht weiter vorangetrieben wurde, ist auch sehr einfach. Offensichtlich ist der Schritt zu groß, und das Sicherheitsrisiko des aktuellen Handels-Hash-Konflikts wurde nicht ausreichend berücksichtigt, so dass es immer aufgeschoben wurde, aber das Konzept des Vorteils ist zu einem der Kernfunktionen von EIP4337 und EIP7702 geworden.

Später gab es eine Reihe von EIPs, die versuchten, diese Logik zu verbessern.

EIP-859：Hauptkontoabstraktion–2018-01-30

Versuch, das Bereitstellungsproblem von Code zu lösen, hat die Kernfunktion, dass bei Nichtbereitstellung des Vertrags der Gegenpartei der Vertrag mit dem Code-Parameter des Transfers ausgeführt wird, um die Bereitstellung der Wallet durchzuführen. Darüber hinaus wird ein neuer PAYGAS-Opcode vorgeschlagen, der neben der Bezahlung von Gas auch als Trennzeichen zwischen dem Validierungs- und dem Ausführungsteil eines Transfers dient.

Obwohl es damals ohne Ergebnis endete, wurde dies zu einer der Kernlogiken von EIP7702. Jede Transaktion von EIP7702 kombiniert eine spezielle Transaktionsstruktur und kann bestimmten Code enthalten, um dem EOAAdresse die Fähigkeit eines Smart Contracts in dieser Transaktion zu verleihen.

EIP-7702: EOA Konto-Code 2024-05-07 festlegen

Dies ist auch der Kern des folgenden Diskussionsmechanismus EIP, den Vitalik als Ersatz für EIP-3074 unter der Nummer EIP-7702 veröffentlicht hat (2024-05-07). Daher wurde EIP-3074 verworfen und EIP-7702 wurde für die bevorstehende ETH Prague/Electra（Pectra）Hard Fork übernommen. Die Details werden im folgenden Text erläutert.

3.2 Die zweite Route ist es, EOAAdresse zu fahren, um CAAdresse zu treiben

**EIP-3074: Hinzufügen der ** AUTH und AUTHCALL Opcode–2020-10-15

Fügen Sie in EVM zwei neue OpCodes AUTH und AUTHCALL ein, damit EOA über diese beiden OpCodes autorisierte Verträge anstelle der Identität von EOA aufrufen kann, um andere Verträge aufzurufen.

Unter Verwendung des folgenden Diagramms kann man zusammenfassend sagen, dass ein EOA eine bereits signierte Nachricht (Transaktion) an einen eigenen vertrauenswürdigen Vertrag (Invoker) senden kann. Dieser Invoker-Vertrag kann die AUTH- und AUTHCALL-Operationcodes verwenden, um anstelle dieses EOA die Transaktion zu senden.

EIP-4337: Implementierung der Kontoabstraktion mit dem Transaktions-Speicherpool–2021-09-29

Insgesamt wurde er durch MEV inspiriert, das Kernziel besteht darin, Änderungen auf der Konsensschicht Protokoll vollständig zu vermeiden.

EIP4337 schlägt ein neues Transaktionsobjekt UserOperation vor. Benutzer senden dieses Objekt an den Mempool, wo es von Bündlern in Chargen von der Miner-Seite aus gepackt und zur Ausführung von Vertrags-Transaktionen übergeben wird. Im Wesentlichen werden die unterliegenden Transaktionen und Kontobewegungen auf Vertragsebene ausgeführt.

EIP-5189: Operation of abstract Konto through endorsers - 2022-06-29

Dies optimiert die Logik von EIP4337 und zielt darauf ab, böswillige Bundler durch die Einführung eines Mechanismus zur Geldstrafen-Endorser-Erstellung zu bekämpfen, um Dos-Blockadeangriffe zu verhindern.

3.3 Andere Vorschläge zur Unterstützung von AA

EIP-2718: Umschlag für neue Transaktionstypen - 2020-06-13

Dies ist ein bereits endgültiger Vorschlag, der einen neuen Transaktionstyp definiert, der als Umschlag für zukünftige Transaktionstypen fungiert.

Das Endziel ist, dass bei der Einführung neuer Transaktionstypen durch spezifische Kodierung unterschieden wird, um welche Art von Transaktion es sich handelt, so dass sie nur rückwärtskompatibel sein müssen, ohne vorwärtskompatibel zu sein. Das häufigste Beispiel ist EIP1559, das die Transaktionsgebühren unterscheidet, eine neue Transaktionstypenkodierung verwendet und die ursprünglichen Legacy-Transaktionstypen nicht beeinflusst.

EIP-3607: Ermöglicht das Nicht-Deployen von Verträgen für EOAs Adresse - 2021-06-10

Dies ist ein Ergänzungsplan auf dem AA-Pfad, um das Problem der Konflikte zwischen dem bereitgestellten Vertrag Adresse und EOA Adresse zu verhindern. Es wird die Methode zur Vertragsgenerierung steuern und verhindern, dass der Code auf eine Adresse bereitgestellt wird, die bereits eine EOA Adresse ist. Dieses Risiko ist eigentlich sehr gering, immerhin hat eine Ethereum Adresse eine Länge von 160 Bit. Obwohl es eine Methode gibt, um aus einem privaten Schlüssel eine bestimmte Vertragsadresse zu kollidieren, würde es auch bei voller Rechenleistung für Bitcoin etwa ein Jahr dauern.

3.4 Wie versteht man die abstrakte Entwicklungsgeschichte des Kontos?

Zunächst muss der Wert nach der Umwandlung in CA verstanden werden.

Im Grunde genommen ist es die praktische Wirkung von EIP-4337, die es ermöglicht.

However, the core drawback of EIP-4337 is that it violates the principle of human motivation.

Er scheint besser zu sein, aber er steckt in einer Art Todesspirale der Marktentwicklung fest, viele Dapps sind immer noch nicht kompatibel, so dass Benutzer nicht bereit sind, CA-Adressen zu verwenden, selbst wenn die Verwendung von CA zu höheren Transaktionskosten führt (in normalen Überweisungsszenarien verdoppeln sich auch die Transaktionsgebühren), und es hängt zu sehr von der Kompatibilität der Dapps selbst ab.

Daher hat es bisher keine Verbreitung im Ethereum-Hauptnetzwerk gegeben.

Kosten sind das wichtigste Maß für die Benutzer und müssen gesenkt werden.

Aber um wirklich Gas zu senken, muss Ethereum selbst ein Soft-Fork-Upgrade durchführen, um Gasberechnungen zu ändern oder Gasverbrauchsmodule von Operationcodes zu ändern usw. Aber wenn wir über einen Soft-Fork nachdenken, warum nicht gleich EIP-7702 in Betracht ziehen?

4. Eine umfassende Analyse von EIP-7702

4.1 Was ist EIP-7702?

Es unterscheidet sich durch neue Transaktionstypen, die es EOAs ermöglichen, vorübergehend die Funktionen von Smart Contracts in einer einzelnen Transaktion zu haben, und unterstützt so geschäftliche Stapeltransaktionen, Gas-freie Transaktionen und benutzerdefiniertes Berechtigungsmanagement, ohne neue EVM-OpCodes (die die Abwärtskompatibilität beeinflussen) einzuführen.

Er ermöglicht es Benutzern, die Fähigkeit der meisten AA zu erlangen, ohne Smart Contracts bereitzustellen, und kann sogar die Fähigkeit eines Dritten bereitstellen, Transaktionen im Namen des Benutzers zu initiieren, ohne dass der Benutzer seinen Private Key angeben muss, sondern nur die autorisierten Informationen signieren muss.

4.2 Datenstruktur

Er definierte einen neuen Transaktionstyp 0x04, bei dem der Transaktionspayload RLP-codiertes Serialisierungsergebnis des folgenden Inhalts ist

Es ist wichtig, dass das authorization_list-Objekt hinzugefügt wurde, um den Code zu speichern, den die Unterzeichner in ihrer EOA ausführen möchten. Benutzer unterzeichnen Transaktionen und unterzeichnen gleichzeitig den auszuführenden Vertragscode. Es wird als zweidimensionale Liste vorhanden sein, was bedeutet, dass mehrere Operationen in Stapeln gespeichert werden können, um Stapelverarbeitung durchzuführen.

4.3 Handelslebenszyklus

4.3.1 Verifizierungsphase

In der Anfangsphase der Ausführung von Transaktionen wird für jedes authorization_list-Tupel [chain_id, Adresse, nonce, y_parity, r, s] Folgendes durchgeführt:

1. Wiederherstellung der Adresse des Unterzeichners aus den Signaturen r und s mit ecrecover (Beachten Sie, dass dies ein Mechanismus von Ethereum selbst ist, daher hat dieser EIP den Signatur-Algorithmus nicht geändert). authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s] (Ähnlich wie bei der vorherigen Entschlüsselung zur Ermittlung von fromAdresse, handelt es sich hier um die lokale Signaturadresse für diese Liste)
2. Verify Chain-ID (Schutz vor Fork-Chain-Wiederholung).
3. Überprüfen Sie, ob der Code des authority-Signierenden leer ist oder bereits delegiert wurde (um zu überprüfen, ob die Transaktion eine gültige 7702-Transaktion ist, die später über den Delegationsmechanismus ausgeführt wird).
4. Überprüfen Sie den Nonce des Autoritätssignierers (zum Schutz vor der erneuten Signatur der Autorität).
5. Setzen Sie den Code des authority-Unterzeichners auf 0xef0100 || Adresse (für die Umgehung der EIP3607-Kollisionsvermeidungsstrategie).
6. Erhöhen Sie den nonce des authority-Unterzeichners (um die Wiederholung der lokalen Signatur zu verhindern).
7. Fügen Sie den authority-Signer-Konto zur bereits zugänglichen Adressliste hinzu (Umleitung auf die heiße Adresse, Drop-Anfrage der gespeicherten Gasgebühr)

4.3.2 Ausführungsphase

Wo finde ich den auszuführenden Vertragscode und die Bedienungsanweisungen?

Die “neue” Version ändert nur das Verhalten der Code-Bereitstellung.

Es setzt den Kontocode nicht mehr als contract_code, sondern ruft den Code address aus der authorization_list ab und setzt diesen als Kontocode.

So wenn die Autorisierungscode ausgeführt werden muss, lädt es den code von Adresse im authorization_list und führt ihn im Kontext des Unterzeichners Konto aus.

Das bedeutet, dass der Vertragscode des Benutzers tatsächlich an einer bestimmten Adresse on-chain gespeichert ist und nicht direkt in der Transaktion enthalten ist.

Die Betriebsanweisungen und zugehörigen Parameter werden im Datenfeld der Transaktionslast gespeichert.

4.4 Welchen Wert hat EIP-7702?

Es wird Veränderungen in der gesamten Kette von Web3-Wallet geben, was zu erheblichen Veränderungen im Benutzererlebnis führt, da normale Transaktionen, die von EOA initiiert werden, auch verschiedene logische Aktionen ähnlich einem Vertrag ausführen können, wie z. B. Massentransfers. Dies wird sich auf die Transaktionsauthentifizierung im CeFi-Szenario auswirken und auch die Gebühren für Ein- und Auszahlungen beeinflussen.

Durch sein Auftreten werden viele frühere Vorurteile gebrochen, wie zum Beispiel:

1. Brach die Invariante, dass der Kontostand nur durch Transaktionen, die aus diesem Konto stammen, verringert werden kann.
2. Es wurde die Invariante gebrochen, dass die EOA Nonce nach Beginn der Transaktionsausführung um 1 erhöht wird (möglicherweise mehrere gleichzeitig).
3. Die Schutzlogik der Vergleichsfunktionen tx.origin und msg.sender wurde durchbrochen, was viele frühere Verträge gefährdet.
4. Gebrochen hat die aktuelle Situation, in der EOA selbst keine Ereignisse auslösen kann, möglicherweise müssen Sie bei der Identifizierung und Überwachung einiger on-chain Ereignisse vorsichtig sein.
5. Brach den EOAAdresse akzeptiert ERC20, 721, 1155 und andere Vermögenswerte zwangsläufig erfolgreich (aufgrund des Pullback-Mechanismus möglicherweise fehlgeschlagen)

4.5 Vergleich von EIP-7702 und EIP-4337

1. Die Vorteile von EIP-7702

Gas ist niedriger, da keine entrypoint-Module benötigt werden und on-chain-Operationen reduziert werden.

Benutzerumzugskosten sind geringer, es ist nicht erforderlich, im Voraus on-chain-Verträge als Hauptkörper bereitzustellen

Im Vergleich zu EIP4337 gibt es auch bei der Code-Delegationsausführung zwei Möglichkeiten:

Vollständige Delegation

Vollständige Delegierung bedeutet, dass die volle Berechtigung für einen Vorgang an eine bestimmte Adresse delegiert wird. Beispielsweise kann ein Benutzer die Verwaltung aller ERC-20-Token an eine Smart-Contract-Adresse delegieren, die alle damit verbundenen Vorgänge im Namen des Benutzers ausführen kann.

Geschützte Delegation

Ein geschützter Auftrag bezieht sich auf die Hinzufügung von Einschränkungen und Schutzmaßnahmen während des Auftrags, um die Sicherheit und Kontrollierbarkeit des Auftragsvorgangs zu gewährleisten.

Zum Beispiel kann ein Benutzer die Verwaltungsbefugnisse für einige ERC-20-Token nur einem Smart Contract übertragen oder bestimmte Einschränkungen festlegen (z. B. maximal 1 % des Gesamtguthabens pro Tag ausgeben).

2. Nachteile von EIP-7702

Sein Hauptnachteil ist, dass er ein Soft Fork-Upgrade ist, das einen großen Konsens erfordert und sich stark auf die On-Chain-Ökologie auswirkt. Nach einer vorläufigen Bewertung von Herrn Shi wurden folgende Herausforderungen identifiziert, aber Herausforderungen sind auch Marktchancen:

1. Sehr hohe Freiheitsgrade, schwer zu auditieren, Benutzer werden eine vertrauenswürdige Wallet benötigen, um Sicherheitsschutz zu gewährleisten.
2. Die ursprüngliche Architektur hat sich stark verändert, obwohl sie durch verschiedene Transaktionstypen unterschieden wird, können viele Infrastrukturkomponenten, insbesondere nicht änderbare Smart Contracts, nicht direkt angepasst werden.
3. Die EOAAdresse bietet Vertragsfähigkeiten, aber der entsprechende Speicherplatz kann nicht erhalten bleiben.
4. Die Kosten für separate Transaktionen steigen leicht an, da der Calldata-Bereich stark vergrößert wird. Die geschätzten Gesamtkosten des Aufrufs betragen 16 (Gas) * 15 (Bytes) = 240 (Gas) Calldata-Kosten, zuzüglich der Kosten von EIP-3860 2 * 15 = 30, und zusätzlich ca. 150 Laufzeitkosten. Daher würde allein die Vorbereitung des Kontos, auch wenn nichts getan wird, zu einer Erhöhung von 500 Gas führen.
5. “Wenn der Empfänger einen Code unterschrieben hat, der keine Empfangsfunktion hat, könnte der Sender beim Versuch, Vermögenswerte zu senden, einem DoS ausgesetzt sein.” Siehe Fall. Das Problem ist eigentlich, dass EOA A etwas unterschrieben hat, was es nicht unterschreiben sollte - eine wiederholbare Datei mit einer fehlerhaften Implementierung (kein receive()).
6. Die On-Chain Ein- und Auszahlungslogik kann inkonsistent sein. Wenn beispielsweise ein ERC-20 Token transferiert wird und das Empfängerkonto einen Code hat, wird der Token-Vertrag die Funktion onERC20Received des Empfängerkontos aufrufen. Wenn onERC20Received den Wert nicht korrekt wiederherstellt oder einen Fehler zurückgibt, wird der Token-Transfer rückgängig gemacht.
7. Wenn EOA Ereignisse auslösen kann, gibt es möglicherweise Probleme zu beachten, insbesondere bei einigen Infrastrukturen.

Dies sind nur einige der in Bezug auf den aktuellen EIP7702-Vorschlag und die entsprechende offizielle Forendiskussion identifizierten Mängel. Letztendlich muss die Analyse noch auf der Grundlage des endgültigen Implementierungscodes erfolgen.

Siehe unten:

5. Zusammenfassung des gesamten Textes

Dieser Artikel scheint umfangreich zu sein, aber der tatsächliche Textinhalt beträgt nur etwas mehr als 6.000 Wörter. Viele frühere Interpretationen von EIP, die im Text erwähnt werden, sind über Links erweiterbar, auf die ich hier nicht weiter eingehen werde.

Aktuell gesehen, Kontoabstraktion kann tatsächlich nur im sechsten Modul, also bei der Reparatur von allem, platziert werden, was auch die letzte Umsetzung bedeutet. Jetzt wird der Fortschritt von EIP7702 deutlich beschleunigt, was hauptsächlich neue Herausforderungen für die Systemsicherheit mit sich bringt. Es ist absehbar, dass er letztendlich realisiert wird, schließlich können sogar revolutionäre Ereignisse wie die ETH Zusammenführung und die Änderung des Konsens-Algorithmus eintreten. Was ist dann schon von neuen Transaktionstypen zu sprechen?

Aber diesmal gibt es zu viele Inhalte, die umgestaltet werden müssen. Es bricht viele ungeschriebene Regeln auf der On-Chain-Seite und zerstört auch die Anwendungslogik der meisten Dapps. Aber es hält fest an dem wichtigsten Punkt, dass die Kosten für Benutzer niedriger sind! Im Vergleich zu den fast verdoppelten Transaktionskosten von EIP4337.

Der Benutzer ist immer noch ein EOAAdresse, aber er treibt und verwendet die CA-Logik nur bei Bedarf, so dass die Haltekosten niedriger sind. Es ist nicht erforderlich, zuerst die Identität des CA auf der Kette umzuwandeln und dann zu handeln, was bedeutet, dass Benutzer sich nicht registrieren müssen.

Benutzer können mit einem EOA leicht mehrere Paralleltransaktionen durchführen, z. B. die Autorisierung und Ausführung von Lastschriften kombinieren, was die Transaktionskosten für den Benutzer selbst senkt. Für Dapps, insbesondere für Projektparteien, die on-chain Unternehmensverwaltung benötigen, wie z. B. Börse, ist dies eine revolutionäre Optimierung. Sobald die Stapelaggregation in der nativen Umgebung implementiert ist, können die Börse-Kosten im Wesentlichen um mehr als die Hälfte reduziert werden, was letztendlich auch den Benutzern zugutekommt.

Daher ist es lohnenswert für alle Dapps, sich mit den Kosten zu befassen, auch wenn sich viel geändert hat, denn dieses Mal stehen die Benutzer definitiv auf der Seite von EIP7702.