Was ist ein Existenznachweis?

Ein Existenznachweis ist eine Methode, um zu zeigen, dass genau diese Daten spätestens zu einem bestimmten Zeitpunkt existierten – mithilfe eines öffentlichen Zeitstempels, den jeder prüfen kann.

Das Verfahren ist einfach. Hash die Daten, veröffentliche diesen Hash in einem öffentlichen Eintrag mit Zeitstempel, und lass später jeden, der die Originaldaten hat, den Hash neu berechnen und mit dem Eintrag vergleichen. Stimmen die beiden Hashes überein, weiß der Verifizierer, dass dieselben Bytes spätestens zum Zeitpunkt dieses Eintrags existierten. Er muss weder dir noch deinem Server noch deinem Account vertrauen – nur dem öffentlichen Eintrag und der Mathematik.

Die Datei selbst muss nie öffentlich werden. Der Nachweis kann öffentlich sein, während der Inhalt privat bleibt.

Was beweist ein Existenznachweis?

Er beweist eine eng umrissene, nützliche Aussage:

Genau diese Bytes existierten spätestens zu diesem öffentlichen Zeitpunkt.

Mehr behauptet der grundlegende Nachweis nicht – und seine Stärke liegt gerade in dieser Genauigkeit.

Fast alles lässt sich auf einen kryptografischen Hash reduzieren: ein Dokument, ein Bild, ein Video, ein Datensatz, ein Quellcode-Archiv, ein Build-Artefakt, ein Vertrag, eine Logdatei, eine Modellausgabe oder ein Manifest. Der Hash ist ein kurzer Fingerabdruck genau einer Bytefolge. Ändere ein einziges Byte, und der Fingerabdruck ändert sich vollständig.

Sobald dieser Hash in einem öffentlichen Eintrag verankert ist, wird der Eintrag zum Zeitzeugen. Zeigst du jemandem später die Originaldatei, hasht er sie erneut. Stimmt der neue Hash mit dem festgehaltenen überein, kann er bestätigen, dass die Datei vor ihm genau die Daten enthält, die zuvor festgeschrieben wurden – zum Zeitstempel des Eintrags oder davor.

Das macht einen Existenznachweis überall dort wertvoll, wo der Zeitpunkt zählt:

• zu zeigen, dass eine Datei vor einem Streit existierte;
• zu zeigen, dass ein Bericht vor einer Prüffrist existierte;
• zu zeigen, dass ein Software-Artefakt zum Release-Zeitpunkt existierte;
• zu zeigen, dass ein Datensatz-Snapshot existierte, bevor er verändert wurde;
• zu zeigen, dass eine KI-Ausgabe, ein Prompt-Set oder eine Mediendatei existierte, bevor sie angefochten wurde.

Der Nachweis beschreibt die Datei nicht. Er ist ein kryptografisches Commitment auf ihre exakten Bytes.

Warum muss die Datei nicht öffentlich sein?

Weil die öffentliche Aussage der Hash ist, nicht die Datei.

Eine gute Hashfunktion wirkt wie ein Einweg-Fingerabdruck. Jeder kann den Hash aus der Datei berechnen, aber wer nur den Hash sieht, kann daraus die Datei nicht rekonstruieren. Genau deshalb kann ein privates Dokument einen öffentlichen Nachweis tragen: Der Eintrag sagt „jemand hat sich zu diesem Zeitpunkt auf genau diese Bytes festgelegt“, ohne die Bytes preiszugeben.

Ein Unternehmen kann zum Beispiel das Manifest eines vertraulichen Datensatzes hashen und nur den Hash veröffentlichen. Der Datensatz bleibt privat. Muss das Unternehmen später nachweisen, was der Snapshot enthielt, kann es das vollständige Manifest, eine Teilmenge davon oder einen Inklusionsnachweis für ein einzelnes Element offenlegen – je nachdem, was die Situation verlangt.

Genau deshalb passt ein Existenznachweis zu Teams aus Recht, Compliance und Security: Er schafft einen externen Zeitstempel, ohne vertrauliche Beweismittel in eine öffentliche Datenbank zu legen. Einen genaueren Blick auf dieses Muster findest du unter vertrauliche Offenlegung ohne öffentliche Dateien.

Welche Rolle spielt die Blockchain?

Die Blockchain ist der öffentliche Zeitzeuge – der Teil, den niemand still umschreiben kann, auch der Veröffentlichende nicht.

Lebt ein Hash nur in deiner eigenen Datenbank, hängt der Nachweis vollständig von deinem System ab. Wird der Zeitstempel später angezweifelt, kann jemand mit gutem Grund fragen, ob die Datenbank umgeschrieben, aus einem Backup wiederhergestellt, von einem Administrator bearbeitet oder rückdatiert wurde. Eine öffentliche Blockchain räumt diesen Zweifel aus. Sobald eine Transaktion bestätigt ist, ist der Eintrag mit Zeitstempel für jeden sichtbar und steht nicht mehr unter der alleinigen Kontrolle des Veröffentlichenden.

Bei CardanoWall ist der Nachweis-Eintrag in den Cardano-Transaktions-Metadaten unter dem Metadaten-Label 309 verankert. Ein Verifizierer ruft die Transaktion über einen öffentlichen Cardano-Explorer seiner Wahl ab, liest den Eintrag und prüft den Content-Hash gegen die Originalbytes. An dieser Prüfung ist kein CardanoWall-Server beteiligt – der ganze Sinn ist, dass der Nachweis ohne uns Bestand hat.

Die Blockchain versteht dein Dokument nicht, und das muss sie auch nicht. Sie hält die Nachweisdaten fest; die Bedeutung entsteht erst, wenn ein Verifizierer den Hash neu berechnet und bestätigt, dass die Bytes übereinstimmen.

Was ist der einfachste Nachweis?

Der einfachste Nachweis ist reiner Hash.

Du wählst eine Datei. Die Software berechnet einen Hash, etwa SHA-256 oder BLAKE2b-256. Dieser Hash landet in einem Eintrag, der in den Cardano-Metadaten veröffentlicht wird. Später wiederholt ein Verifizierer die Hash-Berechnung an der Originaldatei, und stimmt der Digest überein, besteht der Nachweis.

Die erste Stufe lässt sich also auf drei Tatsachen reduzieren:

1. Der Inhalt existiert.
2. Sein Hash ist on chain verankert.
3. Jeder mit dem Originalinhalt kann die Übereinstimmung verifizieren.

Für viele Zwecke reicht das. Ein Hash mit Zeitstempel ist gerade deshalb so wirkungsvoll, weil er so einfach ist – es gibt kaum etwas, das man falsch konfigurieren kann, und nichts, dem man vertrauen muss.

Wann reicht ein Hash nicht aus?

Ein bloßer Hash beantwortet eine Frage gut, aber nicht jede Frage.

Er sagt nicht, wer die Datei erstellt hat. Er zeigt nur, dass die Bytes existierten. Halten zwei Personen dasselbe öffentliche PDF in der Hand, kann jede von ihnen einen Hash davon veröffentlichen; der Hash allein sagt nichts über die Urheberschaft.

Er bewahrt die Datei nicht auf. Verlierst du die Originalbytes, hast du noch einen öffentlichen Hash, aber womöglich nichts mehr, womit du ihn abgleichen könntest.

Und er liefert die Datei niemandem aus. Braucht eine andere Person die Originaldaten, reicht ein bloßer Hash sie ihr nicht weiter.

Deshalb ist das zugrunde liegende Eintragsformat in Schichten aufgebaut. Ein Eintrag aus reinem Hash ist vollständig gültig, aber der Standard unterstützt darüber hinaus Signaturen, versiegelte (verschlüsselte) Payloads, an Empfänger adressierte Zustellung und Merkle-Bündelung – jede fügt dem Zeitstempel eine Fähigkeit hinzu.

Wie verändert eine Signatur den Nachweis?

Eine Signatur fügt eine schlüsselgestützte Aussage hinzu.

Ein signierter Eintrag sagt mehr als „diese Bytes existierten spätestens zu diesem Zeitpunkt“. Er kann zusätzlich sagen: „dieser Schlüssel hat diesen Eintrag signiert.“ Das zählt für Urheberschaft, Freigaben, interne Kontrollen und Geschäftsabläufe: Eine Organisation kann mit einem Signaturschlüssel zeigen, dass ein bestimmtes System, Team oder eine bestimmte Identität für einen Eintrag einsteht, und ein Urheber kann einen Nachweis signieren, um seine Identität mit einem Werk zu verknüpfen.

Die Formulierung muss allerdings präzise bleiben. Eine Signatur zeigt, dass der Schlüssel den Eintrag signiert hat – nicht, wer in der realen Welt über diesen Schlüssel verfügt. Einen Schlüssel an eine Person zu binden, hängt von einem Kontext ab, der außerhalb des Eintrags hergestellt wird. (CardanoWall hält Signaturen bewusst optional; jeder kann veröffentlichen, und Verifizierer müssen dem Veröffentlichenden nie vertrauen.)

Wie verändert das Versiegeln den Nachweis?

Ein versiegelter Nachweis fügt verschlüsselte Aufbewahrung hinzu.

In einem versiegelten Eintrag legt sich der on-chain Nachweis weiterhin auf den Hash des Klartexts fest. Die Datei selbst kann jedoch verschlüsselt und an einem inhaltsadressierten Speicherort abgelegt werden – einer ar://-Adresse (Arweave) oder ipfs://-Adresse –, während im Eintrag nur die Referenz darauf steht. Die Chain sieht den Klartext nie.

Das zählt, wenn der Verlust der Originaldatei den Hash schwer nutzbar machen würde. Mit einem versiegelten Nachweis kann jemand mit dem passenden Schlüssel später den gespeicherten Chiffretext abrufen, ihn entschlüsseln, den Klartext-Hash neu berechnen und bestätigen, dass die entschlüsselte Datei genau der Inhalt ist, der on chain festgeschrieben wurde. Da die Speicheradresse aus den Bytes selbst abgeleitet wird, kann der Empfänger außerdem erkennen, dass ein Storage-Gateway die richtigen Bytes geliefert hat, ohne diesem Gateway vertrauen zu müssen.

Die öffentliche Chain muss den Klartext nie offenlegen. Die verschlüsselte Payload reist mit dem Nachweis, während der Entschlüsselungsschlüssel bei dem bleibt, der ihn halten soll.

Wie verändert die Empfängerzustellung den Nachweis?

Die Empfängerzustellung erlaubt es, einen versiegelten Eintrag für jemand anderen zu verschlüsseln.

Kennst du die Empfangsadresse eines Empfängers (einen öffentlichen Schlüssel, den er geteilt hat), kannst du einen versiegelten Eintrag veröffentlichen, den nur er mit seinem eigenen Schlüssel öffnen kann. Bemerkenswert: Der Eintrag trägt kein Feld, das sagt „dies ist für Alice.“ Es gibt on chain überhaupt keinen Adressaten. Die Software des Empfängers durchsucht öffentliche Einträge und entschlüsselt im Stillen probeweise diejenigen, die an seine Schlüssel adressiert sein könnten – und öffnet nur die, die es tatsächlich sind.

Das macht aus einem Existenznachweis mehr als bloß persönliches Zeitstempeln. Er kann vertrauliche Offenlegung, den Austausch rechtlicher Beweismittel, private Compliance-Pakete und interne Audit-Übergaben tragen – Abläufe, bei denen der Zeitverlauf öffentlich sein soll, der Inhalt aber nicht. Bevor du etwas für jemanden versiegelst, lohnt es sich allerdings zu bestätigen, dass der Schlüssel wirklich ihm gehört; siehe einen Empfänger prüfen, bevor du eine Datei versiegelst.

Eine ehrliche Grenze: Verschlüsselung schützt die Bytes, nicht die Menschen. Das Versiegeln hält den Klartext nur für Schlüsselinhaber lesbar, aber es garantiert keine Anonymität, und ein Empfänger kann den Klartext jederzeit weitergeben, sobald er ihn entschlüsselt hat.

Wie verändert die Merkle-Bündelung den Nachweis?

Die Merkle-Bündelung erlaubt es, dass sich ein Eintrag auf viele items zugleich festlegt.

Statt einer Transaktion pro Datei kann ein System Tausende oder Millionen items hashen, diese Hashes in einen Merkle-Baum falten und eine einzelne 32 Byte große Wurzel veröffentlichen. Später zeigt ein Inklusionsnachweis, dass ein bestimmtes item Teil des festgeschriebenen Bündels war. Der Verifizierer braucht nicht jede Datei on chain: Die Wurzel ist das öffentliche Commitment, und ein kurzer Inklusionsnachweis – einer, der nur mit dem Logarithmus der Bündelgröße wächst – führt ein einzelnes item auf diese Wurzel zurück. Jedes andere item im Bündel bleibt privat.

Das passt zu Abläufen mit hohem Volumen:

• CI/CD-Artefakte und Release-Manifeste;
• tägliche Compliance-Logs;
• KI-generierte Inhalte in großem Maßstab;
• Datensatz-Snapshots;
• Audit-Nachweisordner;
• Medien- und Publikationsarchive.

Der Merkle-Modus hält den on-chain Eintrag winzig und lässt einen einzigen Nachweis dennoch eine riesige Menge an items abdecken. Ein durchgerechnetes Beispiel findest du unter ein Eintrag für Tausende Dateien.

Was beweist ein Existenznachweis nicht?

Dies ist der Abschnitt, der den Nachweis ehrlich hält. Ein Commitment mit Zeitstempel ist stark, weil es genau ist – und genau zu sein bedeutet, dass es Aussagen gibt, die es schlicht nicht trifft.

Er beweist nicht, dass ein Dokument wahr ist. Ein falsches Dokument lässt sich genauso leicht mit einem Zeitstempel versehen wie ein wahres.

Er beweist kein Eigentum. Jeder kann eine Datei hashen, die ihm nicht gehört.

Er beweist für sich allein keine Urheberschaft. Urheberschaft braucht Signaturen, Schlüsselverwaltung und realen Kontext obendrauf.

Er beweist nicht, dass ein Software-Build sicher ist. Er kann zeigen, welches Artefakt, welche SBOM, welches Log oder welches Manifest zu einem bestimmten Zeitpunkt existierte, aber Sicherheit hängt vom Build-Prozess und den Kontrollen darum herum ab.

Er beweist nicht, dass ein Datensatz rechtmäßig erhoben oder genutzt wurde. Er kann zeigen, dass ein Commitment auf einen Datensatz existierte – was ein wichtiges Beweismittel sein kann –, aber rechtliche Ansprüche sind eine eigene Frage, die von deiner Rechtsordnung und deinem Rechtsbeistand abhängt.

Kurz gesagt: Ein Existenznachweis gibt dir Zeitpunkt und Integrität, nicht Wahrheit oder Rechte. Jede weitergehende Aussage muss sorgfältig auf diesem Fundament aufgebaut werden. Was ein Nachweis nicht beweist geht genauer darauf ein, wo die Grenze verläuft.

Warum CardanoWall auf Label 309 aufbaut

Ein Nachweis ist nur so nützlich, wie er portabel ist. Einer, der nur innerhalb einer einzigen Website funktioniert, ist kaum ein Nachweis – ein ernsthafter sollte von unabhängigen Werkzeugen lesbar, aus öffentlicher Infrastruktur verifizierbar und von Software verstanden werden, die der ursprüngliche Dienst nie geschrieben hat.

Deshalb baut CardanoWall auf Label 309 auf, einem offenen, anbieterneutralen Standard für Existenznachweise auf Cardano. Label 309 – nicht die CardanoWall-App – ist das dauerhafte Artefakt; die Web-App, das Kommandozeilenwerkzeug und die SDKs sind Referenzimplementierungen, die ihm nachgelagert sind. Der Standard definiert ein Eintragsformat, das vom bloßen Zeitstempel an aufwärts skaliert:

• reine Hash-Nachweise für einfache Existenz;
• signierte Nachweise für schlüsselgestützte Urheberschaftsaussagen;
• versiegelte Nachweise für verschlüsselte Aufbewahrung;
• empfängerversiegelte Nachweise für private Zustellung;
• Merkle-Nachweise für Bündel mit hohem Volumen;
• benannte Algorithmus-Identifikatoren, damit sich die Kryptografie über die Zeit weiterentwickeln kann, ohne ältere Einträge zu brechen.

Das Format durchläuft außerdem eine öffentliche Prüfung: Der Existenznachweis unter dem Metadaten-Label 309 wurde beim Cardano-CIP-Prozess eingereicht und wird von den CIP-Editoren als Vorschlag der Metadaten-Kategorie geprüft. (Das Metadaten-Label 309 ist die on-chain Kennung; die CIP-Nummer wird vom Prozess separat vergeben.) Der vollständige Standard, seine Referenzimplementierungen und der gesamte Open-Source-Code liegen öffentlich unter github.com/cardanowall unter freizügigen Lizenzen.

CardanoWall ist die Oberfläche. Label 309 ist das Eintragsformat. Der Nachweis ist darauf ausgelegt, beide zu überdauern – die Oberfläche und das Unternehmen, das dir beim Veröffentlichen geholfen hat.

Weiterführende Lektüre

• Wie Label 309 funktioniert – der Standard hinter jedem CardanoWall-Nachweis.
• Was auf die Blockchain kommt – genau welche Bytes veröffentlicht werden und welche dein Gerät nie verlassen.
• Einen Label-309-Eintrag verifizieren – einen Nachweis selbst prüfen, allein aus öffentlicher Infrastruktur.
• Wie sich ein Existenznachweis mit anderen Zeitstempel- und Provenienz-Systemen vergleicht: im Vergleich zu OpenTimestamps, im Vergleich zu einer Zeitstempel-Autorität und im Vergleich zu C2PA / Content Credentials.