Moderne Krypto-Wallets sind fast vollständig von zentralisierten RPC-Diensten abhängig. Der OOPSIE-Ansatz (Opt-in Ownership of Partial State of Interest, Exclusively) zeigt, wie Nutzer durch kryptografisch verifizierte Teilzustände – also Merkle-Patricia-Trie-Beweise via Snap-Sync – Datensouveränität und Privatsphäre zurückgewinnen können. Gleichzeitig wirft das Modell ökonomische Fragen zur Bereitstellung von Zustandsdaten auf. Der folgende Artikel erklärt die technische Architektur, die theoretischen Grenzen und die praktischen Konsequenzen für die Ethereum-Ökonomie.

Problemstellung: Zentralisierte RPC-Dienste und fehlende Datensouveränität

Wallets fungieren heute primär als bloße RPC-Proxys ohne lokale Datenspeicherung. Bei Ausfällen zentraler Infrastruktur verlieren sie ihre Handlungsfähigkeit. Die wichtigsten Probleme sind:

• Abhängigkeit von wenigen RPC-Anbietern, die teuer und anfällig für Ausfälle sind.
• Privacy-Leakage: Jede Abfrage sendet die Nutzeradresse an zentrale Server.
• Fragilität: Wenn ein RPC-Provider offline geht, kann der Nutzer weder Balance noch Nonce einsehen.
• Wachsende Zentralisierung durch ZK-EVMs, weil Validatoren keinen vollständigen Zustand mehr benötigen.

OOPSIE-Modell: Architektur und Funktionsweise

OOPSIE verwandelt Wallets in „tiny, proof-aware“ Light-Clients. Kernpunkte:

• Snap-Sync-First-Read: Beim Start wird ein Range Set – eine kleine Liste von Schlüssel-Wert-Paaren (10 – 50 Keys) – über das P2P-Netzwerk abgefragt.
• Multiproof-Verifizierung: Die zurückgelieferten Merkle-Patricia-Trie-Beweise werden gegen den aktuellen Block-Header verifiziert, wodurch die Daten als VERIFIED gelten.
• Offline-First-UX: Balance, Nonce und ausgewählte Token-Slots stehen sofort zur Verfügung; Transaktionen können offline vorbereitet werden.
• Fallback-RPC: Für komplexe Aufrufe (z. B. Gas-Schätzung) bleibt ein RPC optional.

Der Ansatz reduziert den lokalen Speicherbedarf drastisch im Vergleich zum vollständigen Download von Smart-Contract-Zuständen (z. B. USDC).

Kryptografische Schranken lokaler Beweise (Revocable Proof Systems)

Theoretische Arbeiten zur Zustandslosigkeit (Christ & Bonneau 2023) zeigen, dass Clients Beweise entweder kontinuierlich aktualisieren müssen oder der globale Zustand linear anwachsen muss. Das untere Schwellenwert-Limit liegt bei Ω(1) Aktualisierungen pro Widerruf (2023). OOPSIE umgeht das permanente Mitführen aller Zwischenzustände, indem es bedarfsgesteuerte Multiproofs über den P2P-Snap-Sync-Mechanismus nutzt. Die Arbeitslast wird damit vom Endgerät auf das Netzwerk verlagert.

Tatsächlicher Speicheraufwand populärer Smart Contracts

Die Diskussion um selective Storage Slots wird durch konkrete On-Chain-Metriken unterstützt:

• Reiner USDC-Contract-State (nur Slots, ohne Trie-Overhead): > 1 GB (2024, Paradigm Research).
• Erforderlicher Datenumfang für vollständige Contract-Beweispfade inkl. aller MPT-Zwischenknoten: ~10 GB (2025, Schätzung).
• Typische Größe eines Merkle-Multiproofs für ≤ 50 Keys: 10 – 50 KB (2025, Quelle S2).
• Geth Full-Node-Datenvolumen (Default Sync): 1769 GB (2026, Etherscan).

Damit ist das Laden kompletter Token-Zustände auf mobilen Geräten praktisch unmöglich, wohingegen ein Range Set von 10 – 50 Keys nur wenige zehn Kilobyte Speicher beansprucht.

Wachsende Asymmetrie zwischen Ausführungszustand und Validierungskosten

Mit dem Anwachsen des Ethereum-Gesamtzustands und der Trennung von Block-Proposal und Block-Building (PBS) schrumpft die Zahl der Akteure, die Vollzustände vorhalten. Ohne gezielte Anreize für das Bereitstellen von Zeugen (Witnesses) erodiert die Dezentralisierung. Der aktuelle Full-Node-Speicherbedarf von 1,7 TB verdeutlicht die Dringlichkeit alternativer Servicing-Märkte.

The uncomfortable part – who actually serves state?

OOPSIE leans on snap-sync/multiproofs for authenticity. Today, snap-serving nodes (public sync nodes, a few public Geth/Nethermind/Besu nodes) are already saturated. In a ZK-EVM world, validators don’t need full State to prove/verify, so the natural question is: who is incentivized to hold and serve state at all? Not validators. Not most solo builders. That leaves two classes with any reason to carry state: Block builders (latency-sensitive) and RPC providers (already bandwidth-limited). Ohne einen dezentralen Markt für „Witness Serving“ droht ein Teufelskreis: weniger State-Holder → Beweise schwerer zu finden → Wallets fallen zurück auf RPC → RPC-Last steigt → noch weniger State-Holder.

Die praktische Notwendigkeit dieses Paradigmenwechsels wird durch fundamentale Schranken der Kryptografie untermauert. Wie Untersuchungen zu zustandslosen Blockchains zeigen (Christ & Bonneau 2023), existiert eine unvermeidbare theoretische Hürde: Reduziert ein System den globalen Speicherbedarf der Validatoren, müssen Beweise entweder kontinuierlich aktualisiert werden, oder die Beweisdaten wachsen pro Zustandsänderung dynamisch an. OOPSIE versucht diesen Konflikt pragmatisch zu lösen, indem nicht der Nutzer permanente Updates berechnen muss, sondern bei Bedarf frische Multiproofs über den P2P-Layer abgefragt werden. Doch genau hier schließt sich der Kreis zur ökonomischen Realität.

Wenn Full-Node-Betreiber ohnehin unter der Last von über 1,7 Terabyte an Kettendaten ächzen (Etherscan 2026) und ZK-EVMs die Pflicht zur lokalen Zustandsführung für die Konsensfindung entwerten, fehlt der monetäre Treiber für das kostenlose Bereitstellen dieser Beweise. Ein dezentraler Markt für „Witness Serving“ ist daher keine nette Ergänzung zu OOPSIE, sondern dessen mathematische und wirtschaftliche Existenzbedingung. Ohne incentivierte Bereitsteller wird die angestrebte Souveränität des Nutzers schnell an überlasteten DevP2P-Endpunkten scheitern.

Risiken: P2P-Überlastung und Latenz

• P2P-Überlastung: Millionen Wallets könnten bei jedem Start Snap-Sync-Multiproofs direkt über das DevP2P-Netzwerk anfragen, was CPU-intensive Trie-Traversierungen verursacht.
• Latenz bei schwachen Mobilfunkverbindungen: On-Demand-Holen frischer MPT-Beweise erfordert P2P-Roundtrips, die unter instabilen Netzwerkbedingungen langsamer sein können als optimierte CDN-RPCs.

FAQ

Warum laden Wallets im OOPSIE-Modell nicht einfach den gesamten Token-State (z. B. alle USDC-Halter) herunter?
Einzelne weit verbreitete Smart Contracts wie USDC belegen bereits über 1 GB an reinen Slot-Daten und erfordern inklusive aller Merkle-Patricia-Trie-Zwischenknoten rund 10 GB Speicherplatz. Für mobile Wallets ist dieser Datenumfang unrealistisch, weshalb OOPSIE strikt auf minimale Range Sets von 10 – 50 spezifischen Slots setzt.

Können OOPSIE-Wallets Transaktionen vollständig offline generieren?
Ja, grundlegende Parameter wie Konten-Nonce und bekannte Token-Guthaben können offline eingesehen und Transaktions-Payloads vorbereitet werden. Für die finale kryptografische Verifikation und Übertragung gegen den aktuellen State Root ist jedoch vor dem Senden eine Synchronisation mit dem Chain-Head erforderlich.

Fazit

Expiry ist nur real, wenn State tatsächlich bereitgestellt wird. OOPSIE-artige Clients können nur dann funktionieren, wenn sie kontinuierlich aktuelle, authentifizierte Teilzustände erhalten. In einer Zukunft, in der ZK-EVMs die Notwendigkeit von Full-Nodes reduzieren, droht die RPC- und Builder-Zentralisierung. Durch das Anbieten von Multiproofs für benannte Leaves schafft OOPSIE ein Marktpotential für dezentrale Witness-Server. Damit wird State-Expiry von einem theoretischen Konzept zu einer praktikablen, nachgefragten Dienstleistung. Der nächste Schritt besteht darin, Anreize für das P2P-Bereitstellen von Snap-Sync-Beweisen zu schaffen und die Architektur so zu gestalten, dass fehlende Ranges nicht das Finalisieren verhindern – ein entscheidender Baustein für ein nachhaltiges, dezentralisiertes Ethereum-Ökosystem.