Sicherheit und Skalierung: Welche Angriffsflächen entstehen?

Architektur verändert Angriffsflächen, sie beseitigt sie nicht

Ein Zustandsmodell bestimmt, welche Arten von Fehlern leicht entstehen können und welche bereits strukturell erschwert werden. Daraus darf aber niemals die Behauptung folgen, ein Modell sei „unhackbar“.

Shared Mutable State

Wenn Smart Contracts während einer Ausführung andere Contracts aufrufen und gemeinsamer veränderbarer Zustand über mehrere Aufrufe hinweg relevant bleibt, können komplexe Kontrollflüsse entstehen. Die klassische Reentrancy in EVM-artigen Umgebungen ist ein bekanntes Beispiel: Ein externer Aufruf kann Kontrolle zurückgeben, bevor ein erwarteter Zustandswechsel vollständig abgeschlossen wurde, wenn der Contract falsch programmiert ist.

Warum UTXO-artige Modelle anders sind

Bei UTXO und eUTXO werden konkrete Inputs konsumiert und neue Outputs erzeugt. Der klassische EVM-Mechanismus eines erneut aufgerufenen Contracts, der denselben persistenten Speicher mitten in derselben Aufrufkette verändert, ist dadurch nicht in derselben Form vorhanden. Das ist ein echter struktureller Unterschied.

Andere Fehler bleiben möglich

• falsche Validierungslogik
• fehlerhafte Signatur- oder Berechtigungsprüfungen
• Oracle-Manipulation
• ökonomische Angriffe und Marktmanipulation
• kompromittierte private Schlüssel
• Fehler in Wallets, Indexern, Bridges oder Off-Chain-Komponenten

State Growth und History Growth

Jede langfristige Blockchain muss mit wachsenden Daten umgehen. Dabei sollte man aktiven Zustand und historische Daten unterscheiden. In einem UTXO-System verschwinden verbrauchte Outputs aus der Menge der aktuell unverbrauchten Outputs, aber die Kettenhistorie kann weiterhin wachsen. In einem Account-System können Accounts und Contract Storage wachsen, während zusätzlich historische Blockdaten existieren.

On-Chain und Off-Chain

Skalierung bedeutet häufig, nicht jede Arbeit dauerhaft auf jedem Basisketten-Knoten auszuführen oder zu speichern. Off-Chain-Berechnung, Batching, Channels, Rollup-artige Verfahren oder andere Schichten können die Belastung verlagern. Entscheidend ist dann: Welche Beweise oder Zustandszusammenfassungen braucht Layer 1, und welchen Annahmen muss der Nutzer außerhalb von Layer 1 vertrauen?

Sicherheitsanalyse statt Markenurteil

Frage nicht „Welche Chain ist sicher?“, sondern: Welche Angriffsfläche wird durch das Zustandsmodell reduziert, welche neue Komplexität entsteht, und wo liegen weiterhin vertrauens- oder implementierungsabhängige Komponenten?

Gute Architektur entfernt nicht jedes Risiko. Sie verschiebt Risiken, macht manche Fehler unmöglich, andere sichtbarer und wieder andere zu neuen Engineering-Aufgaben.

Praxisaufgabe: Angriffsflächen-Matrix

1. Erstelle drei Spalten: Account, UTXO, eUTXO.
2. Trage „gemeinsamer veränderbarer Contract-State“, „Double Spend eines Inputs“, „Validator-Logikfehler“, „Oracle“ und „Schlüsselverlust“ ein.
3. Markiere, welche Risiken durch das Modell strukturell verändert werden und welche modellunabhängig bleiben.
4. Unterscheide aktiven Zustand von Blockchain-Historie.
5. Nenne eine Off-Chain-Komponente und beschreibe, welches zusätzliche Vertrauen oder welche zusätzliche Validierung sie benötigt.

Mini-Schritt: Streiche in deiner Fachsprache das Wort „unhackbar“ und ersetze es durch eine konkrete Aussage über eine bestimmte Angriffsfläche.