On-Chain-Beweise sichern

Eine Blockchain bewahrt ihre Historie, aber fast alles, was Ermittlerinnen und Ermittler zum Lesen dieser Historie verwenden, kann sich ändern. Explorer gestalten Seiten neu und versehen Adressen mit anderen Bezeichnungen, Analysetools aktualisieren ihre Zuordnungen, Websites und Forenbeiträge verschwinden, und die neuesten Blöcke können noch ersetzt werden. On-Chain-Beweise zu sichern bedeutet, jede dieser Ansichten zu einem bekannten Zeitpunkt festzuhalten, damit eine prüfende Person Jahre später genau nachvollziehen kann, was Sie gesehen haben, und es mit der Blockchain selbst abgleichen kann.

Was tatsächlich gesichert werden muss

Das Roh-Ledger ist der eine Teil eines Falls, der selten gerettet werden muss: Sobald ein Block final ist, liefern alle ehrlichen Nodes dieselben Daten. Gesichert werden muss der Kontext drumherum. 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 Node voneinander abweichen, ist der Node maßgeblich, und die Abweichung gehört in Ihre Notizen.

Jede Tatsache an einem Block verankern

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

• Blockchain und Netzwerk (Bitcoin-Mainnet, Ethereum-Chain-ID 1, ein benanntes L2 und dessen Chain-ID);
• txid und bei Chains mit Account-Modell 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 Node und dessen Client-Version oder eine benannte öffentliche API;
• Abrufzeitpunkt 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": "eigener Node, Client v30.x",
  "cross_check": "öffentliche Explorer-API, abgerufen 2026-10-14T10:05Z, Felder stimmen überein",
  "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 exakten Transaktion, dem Block und der Quelle sowie mit einer gespeicherten Rohdatei, deren Hash überprüft werden kann. Die Digests sind für den Druck verkürzt; der echte Datensatz enthält alle 64 Hex-Zeichen. Die Zeile für den Gegencheck hält fest, dass eine zweite, unabhängige Quelle dieselben Werte geliefert hat. Die IDFE-BA-Lektion Datenqualität, Normalisierung und Provenienz enthält einen ähnlichen Datensatz für ganze Datensätze; die forensische Ergänzung besteht darin, dass sich jede im Bericht zitierte Tatsache bis zu einem dieser Datensätze zurückverfolgen lässt.

Reorganisationen und Finalität

Daten nahe der Blockchain-Spitze können durch eine Reorganisation rückgängig gemacht werden. Dabei wechseln Nodes zu einem konkurrierenden Zweig und aktuelle Blöcke werden ungültig. Die IDFE-BA-Lektion Blöcke und Header als Daten erklärt die Mechanik. Für Beweismittel gelten einfache Regeln:

1. Sichern Sie nichts als final, was nicht final ist. Bei Bitcoin sind sechs Bestätigungen die übliche Konvention, und Beweise für einen Bericht sollten deutlich darüber liegen. Verwenden Sie bei Ethereum Blöcke auf oder unterhalb des finalized-Checkpoints, normalerweise etwa 13 Minuten hinter der Spitze.
2. Halten Sie den Status zum Zeitpunkt der Erfassung fest. Wenn Sie früh erfassen mussten, zum Beispiel um einen Diebstahl während des Geschehens 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 halten Sie die Prüfung fest. Wenn sich der Block-Hash geändert hat, wurde die Transaktion möglicherweise verschoben oder ist verschwunden; alles, was darauf aufbaut, muss überprüft werden.
4. Layer 2s erfordern eine zweite Prüfung. Die eigenen Blöcke eines Rollups können innerhalb von Sekunden final erscheinen, aber die stärkere Garantie besteht erst, wenn der Batch, der sie enthält, auf der Basiskette final ist. Bei Auszahlungen aus Optimistic Rollups kommt ein Anfechtungszeitraum hinzu. Halten Sie fest, auf welcher Finalitätsebene Sie sich verlassen haben.

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

Abgleich mit einer zweiten Quelle

Eine einzelne Quelle kann falsch liegen: Ein Explorer kann einen Token falsch dekodieren, einen veralteten Kontostand anzeigen oder eine falsche Bezeichnung zuordnen. Bevor ein Auszug zum Beweismittel wird, gleichen Sie ihn mit einer unabhängigen Quelle ab, idealerweise Ihrem eigenen Node mit einem öffentlichen oder zwei voneinander unabhängigen Anbietern. Die folgende Abfrage setzt voraus, dass die prüfende Person die im Bericht zitierten Tatsachen in evidence_facts und einen aktuellen Auszug aus einer zweiten Quelle in node_check geladen hat.

-- Tatsachen, deren txid in der zweiten Quelle fehlt oder sich dort 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-Chains den Wert in wei und den log_index vergleichen

Jede zurückgegebene Zeile weist auf ein Problem hin, das vor der Veröffentlichung des Berichts geklärt werden muss. Eine in der zweiten Quelle fehlende txid weist meist auf einen Tippfehler hin; dieselbe txid in einem anderen Block bedeutet, dass der Datensatz auf einem Zweig erfasst wurde, der später bei einer Reorganisation ersetzt wurde; ein anderer Wert weist meist auf einen Einheiten- oder Dezimalstellenfehler hin. Ein leeres Ergebnis ist zusammen mit der gespeicherten Abfrage und beiden Quellen selbst ein nützlicher Verifizierungsnachweis.

Bezeichnungen und Tool-Ausgaben als Momentaufnahme sichern

Bezeichnungen verlieren mit der Zeit ihre Gültigkeit. Eine Adresse, die dieses Jahr als Zahlungsdienstleister bezeichnet wird, kann nächstes Jahr als Börse bezeichnet oder einem größeren Cluster zugeordnet werden. Wenn Ihr Bericht besagt, dass eine Einzahlung an „Börse X“ ging, muss eine prüfende Person die Bezeichnung so sehen können, wie sie zum Zeitpunkt Ihrer Verwendung lautete. Exportieren Sie für jede verwendete Bezeichnung den Namen der Entität, die abgedeckte Adresse oder den Cluster, die Quelle (selbst veröffentlicht, Anbieterdatensatz, Community-Liste, Analysetool), die Version oder das Datum der Quelle sowie Ihre Einschätzung der Verlässlichkeit. Die IDFE-BA-Lektion Zuordnung und Bezeichnung behandelt die Bewertung von Bezeichnungen; hier geht es darum, sie einzufrieren.

Tool-Ausgaben müssen genauso behandelt werden. Speichern Sie die native Projektdatei, sofern das Tool eine solche hat, einen lesbaren Export (CSV oder JSON der Knoten und Kanten) und ein gerendertes Bild. Halten Sie außerdem die Tool-Version, die Tracing-Methode, Hop-Limits und weitere Einstellungen fest. Wenn Sie denselben Fall mit einer späteren Version erneut ausführen, kann ein anderer Graph entstehen, und Sie müssen den Unterschied erklären können. Die Lektion Tools, Reproduzierbarkeit und Validierung behandelt den Abgleich voneinander abweichender Tools.

Web-Belege archivieren

Off-Chain-Seiten enthalten oft die Zuordnung: eine Betrugswebsite mit Einzahlungsadressen, ein Forenbeitrag, der gestohlene Gelder anbietet, oder die Nutzungsbedingungen eines Dienstes. Das Berkeley Protocol on Digital Open Source Investigations, 2020 vom UN-Menschenrechtsbüro und dem Human Rights Center an der UC Berkeley veröffentlicht, legt dar, wie solches Material professionell gesammelt und gesichert wird. Erfassungsmethoden werden in der Lektion OSINT-Methodik behandelt. Der Sicherungsdatensatz sollte Folgendes enthalten:

• eine Archivdatei im Format WARC (ISO 28500:2017), das den Seiteninhalt und die Antworten des Servers speichert;
• einen Screenshot der vollständigen Seite zur menschlichen Prüfung;
• die URL, den Erfassungszeitpunkt in UTC, das verwendete Tool und die Angabe, ob die Erfassung zuordenbar war oder nicht;
• den SHA-256-Hash jeder Datei, berechnet zum Erfassungszeitpunkt;
• falls nützlich, eine Kopie in einem öffentlichen Webarchiv als unabhängige Bestätigung, niemals als einzige Kopie.

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

Das erneut überprüfbare Beweispaket

All das fließt in ein Beweispaket ein: einen Ordner, mit dem eine prüfende Person jede Tatsache überprüfen kann, ohne Ihnen vertrauen zu müssen.

CF-2026-041_onchain_v1/
  README.txt              wie erneut überprüft wird, Quellen, Softwareversionen
  manifest.sha256         eine SHA-256-Zeile pro nachfolgender Datei
  facts.json              Datensätze zu Tatsachen (F-001 ... F-088)
  raw/                    Rohtransaktionen und -blöcke vom Node
  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 in das Fallprotokoll und das Beweisprotokoll aufgenommen, sodass ein Wert das gesamte Paket schützt. Die README erklärt, wie jede Transaktion von einem beliebigen Node abgerufen, mit raw/ verglichen und die Hashes neu berechnet werden. Bearbeiten Sie ein versiegeltes Paket niemals: Geben Sie Version 2 mit einem neuen Manifest heraus und halten Sie den Grund dafür fest. Die Lektion Hashing, Protokollierung und Beweismittelkette behandelt, wie das Paket anschließend durch die Verwahrung weitergegeben wird.

Prüfungsschwerpunkt: warum Rohdaten finaler Blöcke auf der Blockchain selten gerettet werden müssen, Explorer-Seiten, Bezeichnungen, Tool-Ausgaben, Webseiten und Preise dagegen schon; die Felder, die eine Tatsache verankern (Blockchain, txid, Log-Index, Höhe und Block-Hash, Finalität zum Erfassungszeitpunkt, Quelle und Client-Version, UTC-Zeit, Hash der Rohdatei); nicht finale Daten nicht als final zu behandeln, vorläufige Erfassungen zu kennzeichnen und erneut zu überprüfen; Finalität von Rollups im Vergleich zur Finalität der Basiskette; Abgleich mit einer unabhängigen Quelle; Export von Momentaufnahmen der Bezeichnungen und Tool-Einstellungen; WARC, Screenshots, Hashes und vertrauenswürdige Zeitstempel für Web-Belege gemäß dem Berkeley Protocol; das Beweispaket, sein Manifest und die Versionierung anstelle von Änderungen am Paket.