STVA – Ein ERC-Standard für kanonische, unabhängige Transaktionssimulationen

2. November 2026 Kryptowährungen
Eine silberne Hardware-Wallet liegt neben einem RISC-V-Entwicklungsboard und einem versiegelten Metallzylinder auf einem

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_call oder debug_traceCall liefern 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 VerificationPayload und 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.