Aktuelle Transaktionssimulationen im Ethereum-Ökosystem beruhen häufig auf Web-Frontends oder RPC-Knoten, die manipuliert werden können. Der vorgeschlagene ERC-Standard STVA (Simulation Result for Transactions) bietet ein einheitliches Format für verifizierbare Simulationsartefakte. Durch kryptografische Zeugen (Witnesses) können hardwarebasierte Signer und Light-Clients die erwarteten Zustandsänderungen autark prüfen, bevor sie eine Signatur freigeben. Damit schließt STVA die Lücke zwischen der Anzeige im Wallet-Interface und der tatsächlichen Ausführungswirkung auf Protokollebene.
Warum ein neuer ERC-Standard nötig ist
Die wichtigsten Schwachstellen, die STVA adressiert, lassen sich in drei Punkten zusammenfassen:
- Manipulierbare Frontends: Ein kompromittiertes UI kann falsche Calldata anzeigen, ohne dass der Nutzer die eigentliche Wirkung erkennt.
- Unverifizierte RPC-Simulationen: Dienste wie
eth_calloderdebug_traceCallliefern JSON-Antworten, die nicht kryptografisch gesichert sind. - Blind Signing: Nutzer signieren häufig, ohne die resultierenden StateDiffs, Balance-Changes oder Logs zu prüfen.
STVA definiert ein deterministisches SimulationResult, das über denselben VerificationPayload und einen Zustandsschnappschuss reproduzierbar ist. Das Ergebnis wird durch einen kanonischen Hash (keccak256 oder EIP-712) gebunden und kann in Signaturen sowie Scoped Capability Tokens integriert werden.
Abgrenzung zum “Clear Signing”-Standard ERC-7730
ERC-7730 (Clear Signing) legt standardisierte JSON-Deskriptoren fest, um Funktionsaufrufe und EIP-712-Payloads lesbar im Wallet-Display darzustellen. Der STVA-Entwurf geht einen Schritt weiter:
- ERC-7730 prüft nur das deklarierte Calldata-Format.
- STVA prüft zusätzlich die tatsächliche Ausführungswirkung – StateDiff, Saldenänderungen und Logs – und bindet diese an einen kryptografisch verankerten State Root.
- Im Mai 2026 übernimmt die Ethereum Foundation im Rahmen der Trillion Dollar Security Initiative die Pflege von ERC-7730 (Stewardship-Übergabe).
Durch die Kombination beider Standards können Nutzer sowohl die mensch-lesbare Darstellung (ERC-7730) als auch die maschinen-prüfbare Ausführung (STVA) erhalten.
Bandbreiten- und Größenanforderungen an Prestate-Witnesses
Für eine staatenlose Verifikation im “Strict”-Modus müssen Kontozustände und Speicherpositionen per Merkle-Proof mitgeliefert werden. Die dabei entstehenden Overheads wurden in aktuellen Studien quantifiziert:
- Typische Witness-Größe pro Standard-ERC-20-Transfer: 1 bis 3 KB (Jahr 2025, Quelle S2).
- Der Overhead entsteht durch Storage-Slots- und Account-Proofs im Merkle-Patricia-Trie (MPT).
Diese Größenbeschränkung limitiert die Übertragung an ressourcen-beschränkte Geräte, stellt aber gleichzeitig einen praktikablen Kompromiss für vernetzte Light-Clients und moderne Signierumgebungen dar. Die Diskussion, ob vollständige StateDiffs oder komprimierte Hashes übertragen werden sollen, lässt sich anhand dieser konkreten Grenzwerte fundiert führen.
Praktische Umsetzung staatenloser EVM-Verifikation
Mehrere Implementierungen zeigen bereits die Machbarkeit stateless-EVM-Validierung:
- Paradigms
stateless-Crate (GitHub, Quelle S3) demonstriert in-memory EVM-Ausführungen ohne persistente Datenbank. - Eingebettete
revm-Instanzen laufen auf nostd- und Embedded-Umgebungen, insbesondere auf RISC-V-Architekturen (Zielarchitektur 2025, Quelle S3). - Die lokale Ausführung erfordert lediglich einen gültigen State-Root-Checkpoint, gegen den die Merkle-Beweise verifiziert werden.
Damit erfüllt der STVA-Standard das “Strict Compliance”-Profil: Der Signierer führt die Transaktion eigenständig aus, prüft die Witnesses und verwirft das Ergebnis bei Abweichungen.
Risiken und Gegenmaßnahmen
Der Standard erkennt zwei zentrale Risiken an:
Overhead und Komplexität für ressourcenarme Signer
Offline-Hardware-Wallets verfügen häufig nicht über ausreichenden Speicher oder Rechenleistung, um umfangreiche EVM-Ausführungen mit Megabyte-großen Contract-Codes und Merkle-Zweigen in Echtzeit zu bewältigen. Als Gegenmaßnahme wird das “Standard”-Profil empfohlen, bei dem ein Konsens mehrerer RPC-Validatoren über den State-Root ausreicht und nur ein Minimal-Witness übertragen wird.
Zustandsabhängigkeit und MEV/Reorg-Sensitivität
Wird eine Transaktion gegen Block N simuliert, kann ein späterer Reorg oder Arbitrage-MEV die tatsächlichen StateDiffs verändern. Der Standard schlägt vor, die Simulation an einen verbindlichen Commitment-Point (finalisierter Block-Header oder Checkpoint) zu binden und bei signierten Transaktionen nur Zustände zu akzeptieren, die mit diesem Commitment übereinstimmen.
FAQ – Häufig gestellte Fragen
Was unterscheidet diesen ERC-Entwurf von bestehenden RPC-Simulationen wie eth_call oder debug_traceCall?Herkömmliche RPC-Simulationen liefern unbeglaubigte JSON-Antworten eines einzelnen Server-Betreibers. STVA definiert einen deterministischen, gehashten Payload, der durch kryptografische State-Proofs verifiziert und direkt in Signaturen oder Smart-Account-Validierungen eingebunden werden kann.Kann ein vollständig offline betriebenes Hardware-Wallet diesen Standard nutzen?Nur bedingt: Das Gerät benötigt mindestens einen vertrauenswürdigen, aktuellen State Root (z. B. via QR-Code oder Light-Client-Sync) sowie den State-Witness der betroffenen Speicherzellen, um die Transaktion lokal isoliert nachzurechnen.
Diskussionspunkte und weiterführende Überlegungen
- Exakte Kodierung von
StateDiff– Vollständige Daten vs. Hash-Only zur Reduktion der Payload-Größe. - Notwendigkeit von Prestate-Proofs gegenüber vertrauenswürdigen RPC-Quellen mit Multi-Node-Konsens.
- Grad der Bindung des Simulation-Hashes an
VerificationPayloadund Capability-Tokens.
Die Diskussion dieser Punkte ist zentral, um das Sicherheitsökosystem von Ethereum weiter zu festigen und die Integration von STVA in bestehende Wallet- und Signatur-Workflows zu ermöglichen.
Statistiken und Kennzahlen
| Metric | Wert | Jahr | Quelle |
|---|---|---|---|
| Witness-Größe pro ERC-20-Transfer | 1 – 3 KB | 2025 | S2 |
| Official Registration of ERC-7730 | 2024 | 2024 | S1 |
| Stewardship-Übergabe ERC-7730 | Mai 2026 | 2026 | – |
| Zielarchitektur für stateless Validation Engines | RISC-V (nostd) | 2025 | S3 |
Fazit
Der ERC-Standard STVA schafft ein verbindliches, kryptografisch geprüftes Fundament für Transaktionssimulationen im Ethereum-Netzwerk. Im Vergleich zu ERC-7730 erweitert er die Sicherheit von der reinen Calldata-Dekodierung hin zur vollständigen Ausführungs- und Zustands-Verifikation. Durch die Nutzung von Merkle-Patricia-Trie-Beweisen und stateless-EVM-Engines wie revm wird eine ressourcenschonende, aber dennoch robuste Prüfung für Hardware-Signer und Light-Clients ermöglicht. Gleichzeitig werden Overhead-Probleme und MEV-Sensitivität klar benannt und mit pragmatischen Profil-Ansätzen adressiert. Damit liefert STVA ein entscheidendes Werkzeug, um die wachsende Lücke zwischen UI-Anzeige und on-chain-Effekten zu schließen und das Vertrauen in dezentralisierte Signatur-Workflows nachhaltig zu stärken.