Sicherung von On-Chain-Beweisen

Eine Blockchain bewahrt ihre Historie, doch fast alles, was Ermittler zum Lesen dieser Historie verwenden, kann sich ändern. Explorer gestalten Seiten um und ändern Adresskennzeichnungen, Analysewerkzeuge aktualisieren ihre Zuordnungen, Websites und Forenbeiträge verschwinden, und die jüngsten Blöcke können noch ersetzt werden. On-Chain-Beweise zu sichern bedeutet, jede dieser Ansichten zu einem bekannten Zeitpunkt festzuhalten, damit eine überprüfende Person Jahre später genau nachvollziehen kann, was Sie gesehen haben, und es anhand der Blockchain selbst bestätigen kann.

Was tatsächlich gesichert werden muss

Das unverarbeitete Transaktionsregister ist der eine Teil eines Falls, der nur selten gerettet werden muss: Sobald ein Block final ist, liefert jeder ehrliche Knoten dieselben Daten. Gesichert werden muss der Kontext darum herum. Die Tabelle führt die üblichen Elemente auf.

Behandeln Sie die Rohdaten als Beweismittel und alles andere als eine datierte Ansicht davon. Wenn ein Explorer-Screenshot und der Knoten voneinander abweichen, ist der Knoten maßgeblich, und die Abweichung gehört in Ihre Notizen.

Jede Tatsache an einen Block binden

Eine txid identifiziert eine Transaktion, legt aber für sich genommen nicht fest, wo sich diese Transaktion in der von Ihnen untersuchten Blockchain befindet. Halten Sie für jede Transaktion, auf die Sie sich stützen, Folgendes fest:

• Blockchain und Netzwerk (Bitcoin-Mainnet, Ethereum mit Chain-ID 1, eine namentlich benannte L2 und deren Chain-ID);
• txid und bei Blockchains mit Kontenmodell den Log-Index jedes Ereignisses, auf das Sie sich stützen;
• Blockhöhe und Block-Hash;
• Bestätigungen oder Finalitätsstatus zum Zeitpunkt der Erfassung;
• die Quelle: Ihr eigener Knoten und dessen Client-Version oder eine namentlich benannte öffentliche API;
• Abrufzeit in UTC sowie die Datei, in der die Rohdaten gespeichert wurden, mit ihrem SHA-256-Hash.

{
  "fact_id": "F-012",
  "chain": "bitcoin-mainnet",
  "txid": "4f3a…c21e",
  "block_height": 966204,
  "block_hash": "0000…3b9e",
  "confirmations_at_capture": 4828,
  "source": "own node, client v30.x",
  "cross_check": "public explorer API, retrieved 2026-10-14T10:05Z, fields match",
  "retrieved_utc": "2026-10-14T09:42:10Z",
  "raw_file": "raw/4f3a_c21e.json",
  "raw_file_sha256": "0072…33a9"
}

Dieser Datensatz verknüpft eine im Bericht verwendete Tatsache (F-012) mit der genauen Transaktion, dem Block und der Quelle sowie mit einer gespeicherten Rohdatendatei, deren Hash überprüft werden kann. Die Hashwerte sind für die Druckdarstellung gekürzt; der tatsächliche Datensatz enthält alle 64 Hex-Zeichen. Die Zeile zur Gegenprüfung hält fest, dass eine zweite, unabhängige Quelle dieselben Werte geliefert hat. Die Lektion Datenqualität, Normalisierung und Provenienz zeigt einen ähnlichen Datensatz für vollständige Datenbestände; die forensische Ergänzung besteht darin, dass jede in einem Bericht angeführte Tatsache auf einen dieser Datensätze zurückgeführt werden kann.

Reorganisationen und Finalität

Daten, die nahe der Blockchain-Spitze erfasst werden, können durch eine Reorganisation rückgängig gemacht werden. Dabei wechseln Knoten zu einem konkurrierenden Zweig, und jüngste Blöcke werden verworfen. Die Lektion Blöcke, Header und Knoten-APIs erklärt die Mechanismen. Für Beweismittel gelten einfache Regeln:

1. Sichern Sie nicht als final, was noch nicht final ist. Bei Bitcoin sind sechs Bestätigungen die übliche Konvention, und Beweise für einen Bericht sollten deutlich mehr Bestätigungen aufweisen. Verwenden Sie bei Ethereum Blöcke am oder unterhalb des finalized-Checkpoints, der normalerweise etwa 13 Minuten hinter der aktuellen Spitze liegt.
2. Halten Sie den Status bei der Erfassung fest. Wenn Sie frühzeitig erfassen mussten, etwa um einen gerade stattfindenden Diebstahl zu dokumentieren, kennzeichnen Sie den Datensatz als vorläufig.
3. Überprüfen Sie vorläufige Datensätze erneut, sobald sie final sind: Rufen Sie die Transaktion erneut ab, bestätigen Sie, dass sie sich in einem Block mit demselben Hash befindet, und dokumentieren Sie die Prüfung. Falls sich der Block-Hash geändert hat, wurde die Transaktion möglicherweise verschoben oder ist verschwunden, und alles, was darauf aufbaut, muss überprüft werden.
4. Layer-2-Systeme erfordern einen zweiten Blick. Die eigenen Blöcke eines Rollups können innerhalb von Sekunden final erscheinen, doch die stärkere Garantie besteht erst, wenn der Batch, der sie enthält, auf der Basis-Blockchain final ist. Bei Auszahlungen aus optimistischen Rollups kommt eine Anfechtungsfrist hinzu. Halten Sie fest, auf welche Finalitätsebene Sie sich gestützt haben.

Eine zeitnahe Dokumentation bleibt wertvoll: Eine frühe Erfassung zeigt, was wann sichtbar war. Sie muss lediglich als das gekennzeichnet werden, was sie ist.

Überprüfung anhand einer zweiten Quelle

Eine einzelne Quelle kann falsch liegen: Ein Explorer kann einen Token falsch dekodieren, einen veralteten Kontostand anzeigen oder eine falsche Kennzeichnung zuordnen. Bevor ein Datenauszug als Beweismittel verwendet wird, vergleichen Sie ihn mit einer unabhängigen Quelle, idealerweise Ihren eigenen Knoten mit einem öffentlichen Knoten oder zwei voneinander unabhängige Anbieter. Die folgende Abfrage setzt voraus, dass der Prüfer die im Bericht angeführten Tatsachen in evidence_facts und einen aktuellen Datenauszug aus einer zweiten Quelle in node_check geladen hat.

-- Tatsachen, deren txid in der zweiten Quelle fehlt oder sich in einem anderen Block befindet
SELECT f.fact_id, f.txid, f.block_hash AS cited_block, n.block_hash AS check_block
FROM evidence_facts f
LEFT JOIN node_check n ON n.txid = f.txid
WHERE n.txid IS NULL
   OR n.block_hash <> f.block_hash
   OR n.value_sats <> f.value_sats;   -- bei EVM-Blockchains Wert in wei und log_index vergleichen

Jede zurückgegebene Zeile ist ein Problem, das vor der Herausgabe des Berichts geklärt werden muss. Eine txid, die in der zweiten Quelle fehlt, deutet meist auf einen Tippfehler hin; dieselbe txid in einem anderen Block bedeutet, dass der Datensatz auf einem Zweig erfasst wurde, der später durch eine Reorganisation ersetzt wurde; ein abweichender Wert deutet meist auf einen Fehler bei der Einheit oder der Anzahl der Dezimalstellen hin. Ein leeres Ergebnis ist zusammen mit der dokumentierten Abfrage und beiden Quellen selbst ein nützlicher Überprüfungsnachweis.

Momentaufnahmen von Kennzeichnungen und Werkzeugausgaben

Kennzeichnungen veralten. Eine Adresse, die dieses Jahr als Zahlungsabwickler gekennzeichnet ist, kann nächstes Jahr als Börse gekennzeichnet oder in einem größeren Cluster zusammengeführt werden. Wenn Ihr Bericht besagt, dass eine Einzahlung an „Börse X“ ging, muss eine überprüfende Person die Kennzeichnung in dem Zustand sehen können, in dem sie war, als Sie sich darauf stützten. Exportieren Sie für jede verwendete Kennzeichnung: den Namen der Entität, die zugehörige Adresse oder das zugehörige Cluster, die Quelle (Eigenveröffentlichung, Anbieterdatensatz, Community-Liste, Analysewerkzeug), die Version oder das Datum der Quelle und ihre Einstufung von A bis D. Die Lektion Von der Adresse über die Entität zur Person: Zuordnung und Kennzeichnung behandelt die Einstufung von Kennzeichnungen; hier geht es darum, ihren Stand festzuhalten.

Werkzeugausgaben müssen ebenso behandelt werden. Speichern Sie die native Projektdatei, sofern das Werkzeug eine solche verwendet, einen lesbaren Export (CSV oder JSON der Knoten und Kanten) und ein gerendertes Bild. Halten Sie außerdem die Werkzeugversion, die Nachverfolgungsmethode, Hop-Grenzen und weitere Einstellungen fest. Die erneute Bearbeitung desselben Falls in einer späteren Version kann einen anderen Graphen ergeben, und Sie müssen den Unterschied erklären können. Die Lektion Werkzeuge, Reproduzierbarkeit und Validierung behandelt den Umgang mit voneinander abweichenden Werkzeugergebnissen.

Archivierung von Web-Beweisen

Off-Chain-Seiten liefern oft die Zuordnung: eine Betrugswebsite, die Einzahlungsadressen auflistet, ein Forenbeitrag, der gestohlene Gelder anbietet, oder die Nutzungsbedingungen eines Dienstes. Das Berkeley Protocol on Digital Open Source Investigations, veröffentlicht 2020 vom UN Human Rights Office und dem Human Rights Center an der UC Berkeley, beschreibt, wie solches Material professionell erfasst und gesichert wird. Erfassungsmethoden werden in der Lektion OSINT und die Verknüpfung von On-Chain- und Off-Chain-Identifikatoren behandelt. Der Sicherungsdatensatz sollte Folgendes enthalten:

• eine Archivdatei im WARC-Format (ISO 28500:2017), die den Seiteninhalt und die Antworten des Servers bewahrt;
• einen Screenshot der gesamten Seite zum Lesen durch Menschen;
• die URL, den Erfassungszeitpunkt in UTC, das verwendete Werkzeug und die Angabe, ob die Erfassung zuordenbar war oder nicht;
• den bei der Erfassung berechneten SHA-256-Hash jeder Datei;
• sofern sinnvoll, eine Kopie in einem öffentlichen Webarchiv als unabhängige Bestätigung, niemals als einzige Kopie.

Um nachzuweisen, dass eine Erfassung spätestens zu einem bestimmten Zeitpunkt existierte, können Sie einen vertrauenswürdigen Zeitstempel für ihren Hash einholen (RFC 3161 definiert ein entsprechendes Protokoll) oder den Hash in einer öffentlichen Blockchain-Transaktion verankern. OpenTimestamps ist ein Open-Source-Beispiel für den zweiten Ansatz.

Das erneut überprüfbare Beweispaket

All dies wird in einem Beweispaket zusammengeführt: einem Ordner, der es einer überprüfenden Person ermöglicht, jede Tatsache zu prüfen, ohne Ihnen vertrauen zu müssen.

CF-2026-041_onchain_v1/
  README.txt              Anleitung zur erneuten Überprüfung, Quellen, Softwareversionen
  manifest.sha256         eine SHA-256-Zeile pro unten aufgeführter Datei
  facts.json              Tatsachendatensätze (F-001 ... F-088)
  raw/                    Rohdaten von Transaktionen und Blöcken vom Knoten
  labels/labels_2026-10-12.json
  tool/trace_graph_export.json
  web/forum_post_capture.warc
  web/forum_post_capture.png

Das Manifest führt den Hash jeder Datei auf; der Hash des Manifests selbst (für diese Version 4b91…199f) wird im Fallprotokoll und im Beweismittelprotokoll festgehalten, sodass ein einziger Wert das gesamte Paket schützt. Die README beschreibt, wie jede Transaktion von einem beliebigen Knoten abgerufen, mit raw/ verglichen und die Hashwerte neu berechnet werden können. Bearbeiten Sie ein Paket niemals, nachdem es versiegelt wurde: Erstellen Sie Version 2 mit einem neuen Manifest und dokumentieren Sie den Grund. Die Lektion Hashing, Protokollierung, Beweismittelkette und Qualitätsmanagement behandelt, wie das Paket anschließend entlang der Beweismittelkette weitergegeben wird.

Prüfungsschwerpunkt: Warum finale Blockchain-Rohdaten nur selten gerettet werden müssen, Explorer-Seiten, Kennzeichnungen, Werkzeugausgaben, Webseiten und Preise hingegen schon; die Felder, die eine Tatsache verankern (Blockchain, txid, Log-Index, Höhe und Block-Hash, Finalität bei der Erfassung, Quelle und Client-Version, UTC-Zeit, Hash der Rohdatendatei); nicht finale Daten nicht als final behandeln, vorläufige Erfassungen kennzeichnen und erneut überprüfen; Rollup-Finalität im Vergleich zur Finalität der Basis-Blockchain; Gegenprüfung anhand einer unabhängigen Quelle; Export von Momentaufnahmen der Kennzeichnungen und Werkzeugeinstellungen; WARC, Screenshots, Hashwerte und vertrauenswürdige Zeitstempel für Web-Beweise gemäß dem Berkeley Protocol; das Beweispaket, sein Manifest und Versionierung statt nachträglicher Bearbeitung.