EIP-3074

Bessere und sicherere Nutzung

EIP-3074 ermöglicht es EOA (Externally Owned Accounts), die Kontrolle auf einen bestimmten Vertrag zu übertragen und dadurch die gleichen umfangreichen Ausführungsfunktionen wie der Vertrag zu erhalten. Vor EIP-3074 konnte eine EOA nur einen Vorgang pro Transaktion durchführen, z. B. ERC20 genehmigen oder auf Uniswap tauschen. Nach EIP-3074 kann ein EOA mehrere Operationen gleichzeitig ausführen oder sogar bisher unvorstellbare Aufgaben erledigen. Einfach ausgedrückt, EIP-3074 verbessert die Benutzererfahrung erheblich, und die vertraute Tokenautorisierungsmethode wird umgestaltet, wodurch die Sicherheit erhöht wird, ohne die Benutzererfahrung zu verändern.

Darüber hinaus muss EOA durch EIP-3074 keine Transaktionen länger selbst an die Kette senden, wodurch die Mühe entfällt, ETH für die Zahlung von Transaktionsgebühren erheben zu müssen.

Invoker-Vertrag

Der Vertrag, der die Steuerung von EOA erhalten kann, wird als Invoker-Vertrag bezeichnet. Natürlich kann nicht jeder Vertrag die Kontrolle über die EOA erlangen: Die EOA muss mit einem privaten Schlüssel signieren, und der Inhalt der Signatur gibt eindeutig an, um welchen Invoker-Vertrag es sich handelt und welche Vorgänge der Invoker ausführen darf.

Der Inhalt der EOA-Signatur gibt eindeutig an, welcher Invoker-Vertrag (Invoker-Adresse) und autorisiert die Vorgänge dieses Invoker-Vertrags (Commit)

Der eigentliche Ausführungsprozess wird wahrscheinlich wie folgt aussehen:

1. Alice signiert mit ihrem privaten EOA-Schlüssel und gibt dann den Signaturinhalt und die Signatur an den Relayer
2. Relayer bringt die Kette zur Ausführung des Invoker-Vertrags
3. Der Invoker überprüft die Signatur. Nach bestandener Verifizierung kann es Operationen als EOA durchführen, z. B. USDC genehmigen, dann zu Uniswap gehen, um Börsen zu tauschen, und schließlich einige USDC als Bearbeitungsgebühr an den Relayer übertragen.

Hinweis 1: Ein erneutes Layern ist nicht erforderlich. Alice kann auch ihren eigenen Signaturinhalt und ihr eigenes Siegel in die Kette einbringen.

Nachdem der Aufrufer die Signatur überprüft und mit der Ausführung des Vorgangs begonnen hat, wird er als Alice EOA ausgeführt, was dem Erlangen der (eingeschränkten) Kontrolle über die EOA entspricht.

Es sollte jedoch beachtet werden, dass der Nonce-Wert der EOA nach der Ausführung nicht erhöht wird, sodass dieselbe Signatur wiederverwendet werden kann (so long, wie die EOA Nonce unverändert bleibt), so dass der Invoker seinen eigenen Nonce-Mechanismus implementieren muss, um eine Wiederholung zu vermeiden.

Wenn der Invoker-Vertrag nicht replay-sicher ist, kann die gleiche Autorisierung jederzeit ausgeführt werden.

Eine Einführung in den tatsächlichen Funktionsmechanismus von EIP-3074 finden Sie unter: Einführung in EIP3074

Application

Batchcall

Ermöglichen Sie es Benutzern, die Ausführung mehrerer Transaktionen zu einer zusammenzuführen, wodurch der Prozess mehrerer autorisierter Signaturen und einige Gaskosten eingespart werden.

Hinweis: Dazu muss die dApp auch die Batchcall-Funktion Unterstützung, z. B. EIP-5792, die derzeit von der Community gepusht wird. Andernfalls fordert die dApp den Benutzer nur einmal zum Signieren für jeden Vorgang auf, wenn der Benutzer als normaler EOA behandelt wird.

Session Key

Benutzer können unter bestimmten Bedingungen auch einem Dritten erlauben, in ihrem Namen zu handeln. Der Stellvertretungsschlüssel im folgenden Diagramm ist der autorisierte Dritte. Die Zugriffsrichtlinie ist die Ausführungsbeschränkung, z. B. die Begrenzung auf den Betrieb von Uniswap, die Übertragung von maximal 1 ETH pro Tag, die Gültigkeitsdauer der Autorisierung usw. Diese Bedingungen werden innerhalb des Invoker-Vertrags entworfen und überprüft. So Long, wie die Prüfung bestanden ist, kann der Drittanbieter Vorgänge als EOA eines Benutzers ausführen.

Telegram Bot kann bestimmte Berechtigungen erhalten, um Vorgänge im Namen der EOA des Benutzers auszuführen

Native ETH Permit

Wenn Long die Bedingungen erfüllt sind (d. h., die Signatur der Genehmigung ist rechtsgültig), kann die ETH Übertragung als EOA des Genehmigers durchgeführt werden, wodurch die Wirkung der nativen ETH Permit erzielt wird.

Limit Order

Der Benutzer füllt das Limit Order Bedingungen aus, und wenn die Bedingungen erfüllt sind, kann es als EOA des Benutzers ausgeführt werden, einschließlich der Genehmigung von Token für DEX, der DEX zur Einlösung usw. Im Vergleich zu den Limit Order, die von DEX selbst bereitgestellt werden, müssen Benutzer keine Transaktionen im Voraus zur Genehmigung an DEX senden.

Wenn Alice eine Order abschließt, führt sie gleichzeitig eine Genehmigung aus, sodass keine vorherige Genehmigung erforderlich ist.

Wenn die Bedingung allgemeiner gestaltet ist, wird sie wie ein Intent-Vertrag: So long wie die vom Benutzer angegebenen Bedingungen erfüllt sind, kann jeder die Absicht im Namen seiner EOA ausführen.

Long wie die Intent-Bedingung erfüllt ist, kann jeder die Ausführung im Namen der EOA des Benutzers initiieren

Social Recovery

Wenn der Benutzer den privaten EOA-Schlüssel verliert, kann er (Alice) die von ihm unterzeichnete EIP-3074-Autorisierung zusammen mit den Unterschriften seiner autorisierten Person (Ehemann und Trust Agent) verwenden, um alle Vermögenswerte der EOA zu übertragen. In Wirklichkeit werden die (übertragbaren) Vermögenswerte eingezogen, nicht die Kontrolle über das Konto. Nachdem der private EOA-Schlüssel verloren gegangen ist, kann der EOA nicht länger verwendet werden.

Wenn der Benutzer den privaten EOA-Schlüssel verliert, können andere autorisierte Personen die Übertragung von EOA-Assets signieren und autorisieren.

Auswirkungen von EIP-3074 Verbesserung der

Token-Autorisierungsmethoden und möglicher Ersatz von approve/permit?

Derzeit werden dApps unter der Annahme entwickelt, dass der Benutzer ein EOA ist: Der Benutzer muss den dApp-Vertrag "vorab genehmigen" und "einen ausreichenden Geldbetrag genehmigen". Das bedeutet, dass Benutzer nicht die ganze Zeit online bleiben, auf die Ausführung der dApp warten oder ständig neu genehmigen müssen, was die Benutzererfahrung erheblich verbessert. Bei bedingungsgesteuerten Anwendungen wie Limit-Orders oder DCA sind Benutzer möglicherweise nicht online, wenn die Bedingungen erfüllt sind, sodass sie einen ausreichend großen Geldbetrag für die Ausführung des dApp-Vertrags vorab genehmigen müssen, und es kann sich um einen sich wiederholenden Prozess handeln.

Der Benutzer muss im Voraus einen ausreichend großen Betrag für die dApp genehmigen, damit die dApp mit ihrem Geld arbeiten kann.

Es ist aber auch notwendig, der dApp zu vertrauen oder die Genehmigung der gefälschten dApp zu vermeiden, und die Genehmigung sofort entfernen zu können

Die später erschienenen Genehmigungsmodi, wie das tokennative EIP-2612 oder das nicht-native Permit2, dienen alle dazu, die Nutzungserfahrung und Sicherheit des Genehmigungsmodus zu verbessern: Benutzer müssen nicht länger große Geldbeträge für jeden dApp-Vertrag genehmigen (und jedes Token muss einmal genehmigt werden). Stattdessen muss der Benutzer nur "einen Namen unterschreiben", um den dApp-Vertrag zu autorisieren, "den angegebenen Betrag abzuheben" innerhalb der "angegebenen Zeit". Dies reduziert nicht nur die Angriffsfläche erheblich, sondern verbessert auch die Benutzererfahrung erheblich.

Benutzer müssen nur off-chain signieren und können den Betrag und die Gültigkeitsdauer angeben, was eine bessere Benutzererfahrung und Sicherheit als eine Genehmigung bietet.

Tatsächlich wurde der Genehmigungsmodus jedoch nicht nur genehmigt, sondern häufig als Betrugsangriffsmethode verwendet (1,2,3): Die Opfer unterschrieben fälschlicherweise, was sie für eine Genehmigung für eine dApp hielten, die dem Angreifer aber tatsächlich erteilt wurde.

Wenn Benutzer eine Genehmigung unterzeichnen, können sie nur sehen, wen sie autorisieren müssen, aber sie wissen nicht, welche Vorgänge damit verbunden sind, um sie auszuführen.

Hinweis: Das aktuelle Genehmigungsdesign ist nicht mit sich wiederholenden dApps wie DCA oder anderen regulären Zahlungsanwendungen kompatibel. Dies liegt daran, dass die Genehmigung über einen Replay-Schutzmechanismus verfügt, so dass dieselbe Genehmigung nach Abschluss einer Übertragung nicht erneut verwendet werden kann, was bedeutet, dass die Benutzer für jeden zukünftigen sich wiederholenden Vorgang im Voraus eine Genehmigung unterzeichnen müssen.

EIP-3074 bietet jedoch eine Chance für Veränderungen: Wenn dApp-Entwickler wissen, dass EOA verschiedene komplexe Vorgänge über Invoker ausführen kann, muss das Design der dApp-Interaktion nicht länger die Sicherheit opfern, Order die Benutzererfahrung zu verbessern, z. B. "Benutzer genehmigen einen großen Geldbetrag im Voraus" und "Benutzer unterschreiben eine Genehmigungsnachricht, um den Rückzug zu autorisieren". Stattdessen verknüpfen Benutzer dApp-Vorgänge, um die atomare Ausführung über Invoker zu genehmigen und auszuführen: Entweder werden Genehmigungs- und dApp-Vorgänge zusammen erfolgreich ausgeführt, oder sie schlagen zusammen fehl. Es gibt keine Erfolgsmöglichkeit für die Genehmigung allein, sodass Benutzer sicher sein können, dass diese Genehmigung für diesen Vorgang gilt. Und Benutzer verwenden die Off-Chain-Signaturautorisierung, so dass die Benutzererfahrung die gleiche ist wie die Erlaubnis! Das bedeutet, dass dApp den Genehmigungsmodus nicht länger benötigt! In Zukunft können Wallets Signaturanfragen direkt verbieten oder strengere Überprüfungen durchführen, ohne sich Gedanken darüber machen zu müssen, ob dies dazu führt, dass Benutzer einige dApps nicht verwenden (sondern wiederum für Betrug verwendet werden).

Benutzer autorisieren nicht länger einfach eine bestimmte Adresse, sondern autorisieren eine bestimmte Adresse und was zu tun ist, und sehen sogar das simulierte Ausführungsergebnis.

Hinweis: Dies bedeutet nicht, dass Betrügereien vollständig blockiert werden können! Benutzer können immer noch zu betrügerischen Websites verleitet werden, und betrügerische Websites können immer noch Genehmigungs- oder Übertragungsvorgänge organisieren, damit Benutzer unterschreiben können, aber zu diesem Zeitpunkt können Benutzer zumindest sehen, was diese Signatur tun wird, und Wallets können sogar die Ergebnisse der Anzeigeausführung simulieren und den Benutzern präsentieren, so dass die Benutzer klar wissen können, wer wie viel Geld verliert und wer wie viel Geld gewinnt. Im Vergleich zu Genehmigungen, die nicht wissen, welches Vorgangs- oder sogar Ausführungsergebnis sie haben, haben Benutzer mehr Informationen, um zu entscheiden, ob sie autorisieren möchten. Obwohl es sich nicht um eine perfekte Heilung handelt, wird es dennoch eine wesentliche Verbesserung der aktuellen Situation darstellen.

How the Wallet Handles EOA nonces

Das aktuelle EIP-3074-Design enthält den EOA-nonce-Wert im Signaturinhalt, sodass alle ursprünglichen EIP-3074-Autorisierungen ungültig werden Long, wenn EOA eine Transaktion zur Ausführung an die Kette sendet und den nonce-Wert ändert.

Wenn der Benutzer eine andere Person autorisiert, die EOA zu betreiben, z. B. den Sitzungsschlüssel oder die oben erwähnte Social Recovery-Methode, muss verhindert werden, dass sich die Nonce der EOA ändert. Andernfalls ist es notwendig, alle Berechtigungen erneut zu signieren und dem Treuhänder zu geben, was erhebliche Auswirkungen auf die Benutzererfahrung und die Robustheit des Mechanismus hat.

Wenn der Benutzer berechtigt ist, selbst zu arbeiten, muss die Änderung der EOA Nonce nicht ausdrücklich verhindert werden, da die EIP-3074-Signatur immer noch vor einer bestimmten Frist wie der Transaktion ausgeführt werden soll. Es ist nur so, dass die Wallet mehr EIP-3074-Transaktionen der EOA verwalten muss: Wenn EIP-3074-Signaturen darauf warten, in die Kette hochgeladen zu werden, müssen die Transaktionen der EOA selbst warten.

Hinweis: Der Invoker-Vertrag selbst wird (und sollte) eine Reihe von Nonce-Mechanismen beibehalten, sodass die Signatur nach der Verwendung noch erneut signiert werden muss, unabhängig davon, ob sich die EOA Nonce ändert.

Session Key und Social Recovery müssen höchstwahrscheinlich warten, bis EIP-3074 die Regeln ändert, um die EOA Nonce aus dem Signaturinhalt zu entfernen, bevor sie in großem Umfang übernommen werden können. Daher muss sich die Wallet nur auf den Anwendungsfall "benutzerautorisierte Operationen" konzentrieren und die EIP-3074-Signatur als Transaktion behandeln. Sie müssen sich keine Sorgen machen, EOA-Sendetransaktionen zu vermeiden oder die EOA Nonce zu ändern.

Es sollte jedoch beachtet werden, dass, wenn der Benutzer seinen eigenen EIP-3074-Signaturinhalt in die Kette bringen möchte, es zwei Nachteile gibt:

1. Der Benutzer muss zweimal signieren: einmal für die EIP-3074-Signatur und einmal für die On-Chain-Transaktionssignatur.
2. Da die On-Chain-Transaktion 1 zur EOA Nonce hinzufügt, bevor die Transaktion ausgeführt wird, muss die EOA Nonce in der EIP-3074-Signatur des Benutzers 1 vorab hinzugefügt werden, um der EOA Nonce +1 zu entsprechen, die von der Kette selbst verursacht wird.

Da die Kette zuerst 1 zur EOA Nonce hinzufügt, schlägt die Überprüfung der EIP-3074-Signatur aufgrund einer nicht übereinstimmenden EOA Nonce fehl.

Wenn Benutzer der EOA Nonce in der EIP-3074-Signatur 1 hinzufügen, bevor sie sie selbst in die Kette bringen, kann die Überprüfung reibungslos ablaufen.

Zusammenfassung und Highlights

• EIP-3074 ermöglicht es EOA, die gleichen umfangreichen Ausführungsfunktionen wie Verträge zu erhalten, was viele neue Anwendungsszenarien eröffnet.
• Dadurch wird nicht nur die Benutzererfahrung erheblich verbessert, sondern auch die aktuelle Tokenautorisierungsmethode geändert, wodurch sie bei gleichbleibender Benutzererfahrung sicherer wird.
• Darüber hinaus ist EIP-3074 eine einfache Signatur, und Benutzer müssen die Signatur nicht unbedingt zur Ausführung in die Kette bringen, so dass Sie sich keine Sorgen machen müssen, ETH zu sammeln, um Transaktionsgebühren zu zahlen.
• Zu den Verwendungszwecken von EIP-3074 gehören Batch-Aufruf, Sitzungsschlüssel, native ETH-Genehmigung, Limit Order und soziale Wiederherstellung. Viele davon waren zuvor für EOAs unmöglich zu erreichen, und einige, wie Limit Order, erforderten die Verwendung unsicherer Vorautorisierungsmethoden.
• EIP-3074 ändert auch die aktuelle Tokenautorisierungsmethode. Die approve-Methode autorisiert direkt eine bestimmte Adresse, um Token auf unbestimmte Zeit abzuheben, und erfordert, dass die EOA des Benutzers eine Transaktion sendet, um die Genehmigung auszuführen, sodass die Benutzererfahrung und die Sicherheit nicht gut sind. Bei der Genehmigungsmethode muss der Benutzer nur unterschreiben, und jede Signatur gibt den Betrag und die Gültigkeitsdauer an, was die Benutzererfahrung und Sicherheit im Vergleich zur Genehmigung erheblich verbessert.
• Die Genehmigung wird jedoch immer noch häufig für Betrügereien verwendet. Beim Signieren können Benutzer nur wissen, wen sie autorisieren müssen, wie viel und wie lange sie gültig sind, aber sie wissen nicht, wozu diese Autorisierung dient. "Wozu es da ist" wird eine andere Signatur (oder Transaktion) sein. Normale dApps lassen Benutzer die Genehmigung und "wofür sie ist" unterschreiben, aber es handelt sich immer noch um zwei verschiedene Signaturen, so dass weder der Benutzer noch die Brieftasche wissen können, wofür diese Genehmigung verwendet wird, wenn sie aufgefordert werden, die Genehmigung zu unterzeichnen.
• Mit EIP-3074 müssen Benutzer (1) keinen großen Geldbetrag für dApp im Voraus genehmigen, sondern müssen nur genehmigen, wenn es eine Operation gibt, die die gleiche Wirkung wie die Genehmigung hat; (2) Es ist nur eine einfache Unterschrift und muss sich nicht um das Sammeln von ETH kümmern, um die Transaktionsgebühr zu bezahlen, die der Genehmigung entspricht; (3) Jede Genehmigung ist an einen bestimmten Vorgang gebunden und wird zusammen unterzeichnet, so dass die Benutzer genau wissen können, wofür diese Genehmigung gilt, was sicherer ist als die Genehmigung!
• Es besteht die Hoffnung, dass EIP-3074 die aktuellen Genehmigungs- und Genehmigungsmodi erfolgreich ersetzen und Benutzern eine sicherere Autorisierungsmethode bieten kann.

Haftungsausschluss:

1. Dieser Artikel ist ein Nachdruck von [imToken Labs]. Alle Urheberrechte liegen beim ursprünglichen Autor [Nothing]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an das Team von Gate Learn, 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.