Was ist ERC-677: Vereinfachung von Smart Contract-Interaktionen

Smart Contracts treiben fast jede sinnvolle Interaktion auf EVM-basierten Blockchains an – vom Tauschen von Tokens und Staking bis hin zum Überbrücken von Assets und dem Auslösen von Oracle-Updates. Dennoch erfordert der grundlegende ERC-20-Token-Standard oft Benutzeroberflächenmuster mit mehreren Schritten wie "approve" gefolgt von "call", was zu Reibungen führt, mehr Gas kostet und die Wahrscheinlichkeit von Benutzerfehlern erhöht. ERC-677 ist eine pragmatische Erweiterung von ERC‑20, die diese Abläufe optimiert, indem sie eine Token-Übertragung mit einem sofortigen Contract-Aufruf kombiniert.

Dieser Artikel erklärt, was ERC‑677 ist, wie es funktioniert, wo es nützlich ist und worauf Entwickler und Benutzer im Jahr 2025 achten sollten.

Das Problem mit ERC-20 allein

ERC‑20 definiert eine einfache Schnittstelle für fungible Tokens – transfer, approve und transferFrom. Diese Einfachheit hat ERC‑20 zum Rückgrat von DeFi und Stablecoins gemacht, zwingt aber auch gängige Arbeitsabläufe in zwei Transaktionen:

• approve (Genehmigung eines Spenders)
• call (Aufruf des Protokoll-Contracts, der dann transferFrom durchführt)

Dieses zweistufige Muster:

• Erhöht die Anzahl der Transaktionen und den Gasverbrauch.
• Schafft Reibung und Verwirrung in der Benutzererfahrung.
• Kann zu Approval-Race-Conditions und verbleibenden Genehmigungen führen. Siehe die Anleitungen von OpenZeppelin zur Anpassung von Genehmigungen, um Probleme mit der Approve-Semantik zu mindern. OpenZeppelin Empfehlungen für ERC-20-Genehmigungen

Für Hintergrundinformationen zu ERC‑20 selbst siehe die Dokumentation von Ethereum.org. Übersicht über den ERC-20-Standard

Was ERC-677 hinzufügt

ERC‑677 erweitert ERC‑20 um eine wichtige Funktion: transferAndCall. In einer einzigen Transaktion werden Tokens an einen Empfänger-Contract gesendet und rufen dort sofort einen vordefinierten Callback (üblicherweise onTokenTransfer) mit beliebigen Daten auf.

Überblick über den Ablauf:

1. Der Benutzer signiert einen transferAndCall auf dem ERC‑677-Token.
2. Der Token-Contract überträgt die Tokens an den Empfänger.
3. Der Token-Contract ruft recipient.onTokenTransfer(sender, amount, data) auf.
4. Der Empfänger-Contract führt die Logik aus – z. B. Einzahlung, Staking, Tausch oder Auslösung eines Oracles.

Dieses Muster eliminiert die Notwendigkeit eines separaten approve-Schritts und ermöglicht es Contracts, sofort auf den Erhalt von Tokens zu reagieren.

Der LINK-Token von Chainlink ist eine bekannte ERC‑677-Implementierung, die so konzipiert ist, dass Contracts auf LINK-Überweisungen sofort reagieren können, um Oracle-Dienste und damit verbundene Interaktionen zu bezahlen. Chainlink LINK-Token und ERC‑677

Typische Anwendungsfälle

• Staking und Einzahlungen in Vaults: Benutzer tätigen Einzahlungen in einer Transaktion, und der Vault verbucht die Einzahlung im Callback.
• DEX- und Liquiditätsströme: Protokolle können die Tokens empfangen und direkt Swap- oder Add-Liquidity-Logik ausführen.
• Oracles und Dienstleistungszahlungen: Übertragen Sie Tokens an einen Service-Contract und lösen Sie Nutzung oder Abrechnung im selben Aufruf aus. So ermöglicht der LINK ERC‑677 reibungslose Oracle-Zahlungen. Chainlink LINK-Token und ERC‑677
• Bridges und Cross-Chain-Protokolle: Kombinieren Sie die Token-Lieferung mit einem Instruktions-Payload für Bridging oder Messaging.
• Cross-Chain-Interoperabilität: Mit zunehmender Cross-Chain-Nutzung ist die Kombination von Wertübertragung und Ausführung nützlich. Das Design von Chainlink CCIP verdeutlicht die steigende Nachfrage nach programmierbaren Token-Flüssen über Netzwerke hinweg. Was ist CCIP

Wie ERC-677 im Vergleich zu Alternativen abschneidet

• ERC‑1363 (ähnlich transferAndCall für "payable tokens"): Ähnliches Ziel – Contracts ermöglichen, auf den Erhalt von Tokens zu reagieren – mit standardisierten Callbacks für Ausgaben- und Genehmigungsabläufe. Gut für zahlungsähnliche Erlebnisse. ERC‑1363 Spezifikation

• ERC‑777 (tokens mit Hooks): Bietet reichhaltigere Token-Semantik und Empfänger-Hooks. Leistungsfähig, aber historisch mit mehr Komplexität und Reentrancy-Risiko verbunden, wenn Empfänger nicht sorgfältig konzipiert sind. ERC‑777 Spezifikation

• EIP‑2612 (permit) und Permit2: Konzentriert sich auf gaslose Genehmigungen über signierte Nachrichten, wodurch die Notwendigkeit von approve-Transaktionen reduziert wird. Großartig für DEXs und Wallets, lässt aber oft noch einen nachfolgenden Contract-Aufruf übrig. ERC‑677 reduziert die Benutzerschritte, indem es Übertragung und Ausführung bündelt. EIP‑2612 Permit, Uniswap Permit2

• Account Abstraction (EIP‑4337): Ermöglicht es Wallets und Paymastern, mehrere Operationen zu bündeln und Gas zu sponsern, was die Benutzererfahrung verbessert. ERC‑677 ergänzt AA, indem es die Schritte auf Protokollseite weiter reduziert. EIP‑4337 Account Abstraction

Kurz gesagt: Permit und AA reduzieren die Reibung auf Wallet-Seite; ERC‑677 reduziert die Reibung, indem es die Token-Übertragung selbst auslöst, um Smart Contract-Logik zu starten.

Überlegungen für Entwickler und Sicherheit

Bei Callbacks beim Empfang von Tokens ist Vorsicht geboten:

• Reentrancy (Wiedereintritt): Der Token-Contract ruft die Logik des Empfängers auf. Wenn Empfänger dann zurück in den Token-Contract oder andere externe Contracts aufrufen, können Reentrancy-Schwachstellen entstehen. Verwenden Sie gegebenenfalls Checks-Effects-Interactions oder Guard-Muster. SWC‑107 Reentrancy, OpenZeppelin ReentrancyGuard

• Absender und Token validieren: Stellen Sie sicher, dass Empfänger-Contracts msg.sender mit dem vertrauenswürdigen Token-Contract abgleichen und die Token-Adresse validieren, wenn mehrere Tokens unterstützt werden.

• Whitelisting: Erwägen Sie, erlaubte Empfänger-Contracts (oder die Validierung von Schnittstellen) für Tokens auf eine Whitelist zu setzen, bei denen der Callback sensible Operationen durchführen kann.

• Event-Design: Das Ausgeben reichhaltiger Events erleichtert Indizierung und Analyse. Behalten Sie ERC‑20-kompatible Transfer-Events neben ERC‑677-spezifischen Daten bei, wo dies für die Tool-Kompatibilität möglich ist.

• Fallback-Sicherheit: Wenn der Empfänger den erwarteten Callback nicht implementiert, sollte die Übertragung fehlschlagen oder einem sicheren, expliziten Fehlerpfad folgen, um einen "stillen" Funktionsverlust zu vermeiden.

• Gas und Fehlerfälle: Der Callback kann fehlschlagen; behandeln Sie Fehler mit klaren Fehlermeldungen und stellen Sie sicher, dass Benutzer verstehen, ob die Übertragung erfolgreich war oder die gesamte Transaktion fehlgeschlagen ist.

Für allgemeine Smart Contract-Sicherheit sind die Solidity-Dokumente zu Sicherheitsüberlegungen weiterhin essenziell. Solidity Sicherheitsüberlegungen

Wallet UX: Warum das für Benutzer wichtig ist

Durch die Eliminierung der Sequenz "approve dann call" kann ERC‑677 komplexe Interaktionen wie eine einzige, zielgerichtete Aktion wirken lassen. Das reduziert Signatur-Müdigkeit, senkt den kognitiven Aufwand und spart oft Gas. Allerdings ist die einzelne Transaktion reichhaltiger: Sie übertragen nicht nur Tokens, sondern führen auch Contract-Logik aus. Dies erfordert klare Vorschauen, Simulationen und lesbare Aufrufdaten von Wallets.

Wenn Sie ein sicherheitsbewusster Benutzer sind, der mit Protokollen interagiert, die ERC‑677 verwenden, kann die Verwendung einer Hardware-Wallet, die menschenlesbare Funktionsnamen, Parameter und geschätzte Wertänderungen anzeigt, Ihnen helfen, mit Vertrauen zu signieren.

Kontext 2025: Adoption und Komponierbarkeit

Im Jahr 2025 setzt sich der Trend fort, Wertübertragung und Intent-Ausführung zu bündeln:

• Mehr Protokolle bevorzugen "One-Click"-Einzahlungen, Swaps oder Dienstleistungszahlungen, die sich nativ anfühlen und die Unübersichtlichkeit durch Genehmigungen reduzieren.
• Cross-Chain-Frameworks legen Wert auf programmierbare Token-Bewegungen und Message-Payloads – ERC‑677-ähnliche Semantiken passen gut zu diesen Architekturen. Sehen Sie, wie CCIP programmierbare Nachrichten neben der Token-Übertragung für Cross-Chain-Anwendungsfälle formalisiert. Was ist CCIP

Erwarten Sie eine stärkere Unterstützung durch Wallets und Middleware für die Simulation von Callback-Flüssen, die Hervorhebung von Risiken und die Bereitstellung verständlicher Aufforderungen, die kombinierte Übertragungs- und Ausführungsoperationen sicherer machen.

Skizze der minimalen Schnittstelle

Konzeptionell sieht ERC‑677 wie folgt aus (Implementierungen können leicht variieren):

interface IERC677 {
    function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool);
    event Transfer([address](https://onekey.so/blog/de/ecosystem/what-is-a-crypto-wallet-address/) indexed from, [address](https://onekey.so/blog/de/ecosystem/what-is-a-crypto-wallet-address/) indexed to, uint256 value, bytes data);
}

interface IERC677Receiver {
    function onTokenTransfer([address](https://onekey.so/blog/de/ecosystem/what-is-a-crypto-wallet-address/) sender, uint256 value, bytes calldata data) external;
}

Der Token-Contract ruft onTokenTransfer beim Empfänger unmittelbar nach der Wertübertragung auf, wodurch der Empfänger in einer einzigen Transaktion reagieren kann.

Praktische Tipps

• Für Protokollentwickler: Dokumentieren Sie erwartete Callback-Schnittstellen und Fehlergründe klar. Veröffentlichen Sie gegebenenfalls Whitelists oder Schnittstellenprüfungen, damit Integratoren das Verhalten überprüfen können.
• Für Integratoren: Simulieren Sie transferAndCall, um Zustandsänderungen nach dem Callback vorherzusehen. Kennzeichnen Sie riskante Empfänger oder unbekannte Callbacks für Benutzer.
• Für Benutzer: Bevorzugen Sie vertrauenswürdige Protokolle und überprüfen Sie Transaktionsvorschauen. Wenn Ihre Wallet eine lesbare Dekodierung unterstützt, nehmen Sie sich einen Moment Zeit, um die an den Callback übergebenen Parameter zu überprüfen.

Sollten Sie ERC-677 verwenden?

Verwenden Sie ERC‑677, wenn:

• Sie das Muster "approve + call" für Kernabläufe von Benutzern eliminieren möchten.
• Das Protokoll von einer sofortigen, atomaren Reaktion auf den Erhalt von Tokens profitiert.
• Sie Empfänger-Callbacks gegen Reentrancy härten und Token-Quellen gründlich validieren können.

Wenn Ihr Anwendungsfall rein genehmigungszentriert ist (z. B. einem DEX zu erlauben, Tokens später auszugeben), reichen EIP‑2612 oder Permit2 möglicherweise aus. Wenn Sie reichhaltigere Hook-Semantiken über viele Empfänger hinweg benötigen, bewerten Sie ERC‑777, aber seien Sie sich seiner Komplexität bewusst.

Eine Notiz für OneKey-Benutzer

ERC‑677-Transaktionen kombinieren eine Token-Übertragung mit einem Contract-Aufruf. Beim Signieren ist es hilfreich zu sehen, welche Funktion genau ausgeführt wird und mit welchen Parametern. Der Open-Source-Ansatz von OneKey und die EVM-Unterstützung zielen darauf ab, transparente Aufrufvorschau-Möglichkeiten und zuverlässiges Signieren für fortgeschrittene Interaktionen wie transferAndCall zu bieten, damit Power-User eine hohe Sicherheit aufrechterhalten und gleichzeitig eine optimierte Benutzererfahrung genießen können.

Indem Sie ERC‑677 verstehen und eine Wallet verwenden, die Transaktionsdetails klar anzeigt, können Sie sicher von einfacheren, Ein-Transaktions-Smart-Contract-Interaktionen profitieren.