Veröffentliche deinen ersten Existenznachweis auf Cardano

Der einfachste Label 309-Nachweis ist ein Hash, der auf Cardano verankert ist.

Du nimmst eine Datei, berechnest ihren kryptografischen Hash, veröffentlichst diesen Hash in einem Label-309-Eintrag unter dem Cardano-Metadaten-Label 309 und bewahrst den daraus entstehenden Transaktions-Hash auf. Später kann jeder, der die Originaldatei hat, den Hash neu berechnen und bestätigen, dass das passende Commitment spätestens zur Blockzeit der Transaktion on chain war. Dafür braucht niemand deinen Server, deine Domain oder deine Identität – nur die Transaktionsreferenz und einen öffentlichen Cardano-Explorer.

Das ist die erste Stufe des Existenznachweises. Alles Weitere baut darauf auf. Diese Anleitung führt dich durch das Veröffentlichen eines solchen Nachweises, größtenteils über das Kommandozeilen-Werkzeug cardanowall, und endet damit, wie du bestätigst, dass es tatsächlich funktioniert hat.

Was veröffentlichst du eigentlich?

Wenn du einen einfachen Nachweis erstellst, veröffentlichst du nicht die Datei selbst.

Du veröffentlichst ein Commitment auf die Datei: ihren Digest. Ein Digest ist ein kryptografischer Fingerabdruck fester Größe. Ändert sich die Datei um nur ein einziges Byte, ändert sich der Digest vollständig. Genau diese Eigenschaft macht einen Hash zu einem verlässlichen Stellvertreter für die exakten Bytes.

Ein reiner Hash-Nachweis passt gut zu Dingen wie:

Verträgen und Rechnungen;
Release-Artefakten und Build-Manifesten;
KI-Ausgaben und Datensatz-Snapshots;
Richtliniendokumenten und Beweispaketen;
Prüfsummen, die ein anderes System bereits erzeugt hat.

Der Nachweis gibt den Inhalt der Datei nicht preis. Er offenbart nur den Hash, den von dir gewählten Hash-Algorithmus und welche optionalen Metadaten du sonst noch in den Eintrag aufnimmst. Mehr dazu, welche Felder on chain landen, findest du unter was auf die Blockchain kommt.

Was brauchst du, bevor du veröffentlichst?

Veröffentlichen braucht ein Gateway. Verifizieren nicht.

Die Verifizierung läuft vollständig aus öffentlichen Chain-Daten. Veröffentlichen ist anders: Irgendetwas muss die Cardano-Transaktion bauen und einreichen, die Netzwerkgebühr bezahlen, die Bestätigung abwickeln und – falls du Dateien off-chain speicherst – die Speicherkosten tragen. Ein Label-309-Gateway ist der Dienst, der all das erledigt. Das Open-Source-Gateway und die Werkzeuge drumherum sind gateway-agnostisch, du richtest die Tools also auf das Gateway aus, für das du einen Schlüssel hast.

Für deinen ersten Nachweis brauchst du:

eine Datei oder einen vorberechneten Digest;
eine Basis-URL eines Label-309-Gateways;
einen API-Key oder ein kurzlebiges Account-Token für dieses Gateway;
genügend Guthaben auf deinem Gateway-Account;
optional einen Identity Seed, falls du den Eintrag signieren willst.

Wenn du das gehostete CardanoWall-Gateway nutzt, betreibt CardanoWall den Gateway-Account und das vorausbezahlte Guthaben für dich. Wenn du dein eigenes Gateway betreibst, finanzierst du dessen Cardano- und Storage-Wallets selbst. So oder so kostet das Veröffentlichen Geld, weil in deinem Namen echte Gebühren bezahlt werden – das ist das Thema von warum das Veröffentlichen einen Preis hat.

Warum lautet der Ablauf erst Kostenvoranschlag, dann veröffentlichen?

Ein Gateway sollte niemals klammheimlich veröffentlichen und dich mit einer Rechnung überraschen. Deshalb hat jede Veröffentlichung dieselbe zweistufige Form: erst einen Preis festschreiben, dann einreichen.

Den Eintrag bauen oder abschätzen.
Das Gateway um einen Kostenvoranschlag bitten.
Eine Kostenvoranschlag-ID und eine Preisaufschlüsselung erhalten (Netzwerkgebühr, Speicher, Service-Marge).
Den fertigen Eintrag mit diesem Kostenvoranschlag einreichen.
Sofort eine Gateway-Eintrags-ID erhalten, während die Transaktion noch eingereicht wird.
Den Status verfolgen, bis die Transaktion on chain bestätigt ist.
Das Ergebnis unabhängig verifizieren.

Ein Kostenvoranschlag schreibt den Preis für ein begrenztes Zeitfenster fest – derzeit 15 Minuten. Läuft er ab, bevor du veröffentlichst, forderst du einen neuen an; der Preis kann sich verschieben, falls sich die Wechselkurse verschoben haben, aber sonst ändert sich nichts.

Dieses zweistufige Muster macht Automatisierung sicher. Dein Skript kann den Kostenvoranschlag protokollieren, seine eigene Ausgabenrichtlinie durchsetzen und erst dann veröffentlichen – damit eine Preisspitze oder ein vertippter Batch niemals mit deinem Guthaben durchgehen kann.

Eine Datei mit der CLI veröffentlichen

Für eine lokale Datei ist der Kommandozeilen-Ablauf bewusst knapp gehalten:

cardanowall submit \
  --file ./contract.pdf \
  --base-url https://your-gateway.example \
  --api-key "$CARDANOWALL_API_KEY"

Die CLI hasht die Datei, baut den Label-309-Eintrag, lässt das Gateway einen Kostenvoranschlag erstellen und den Eintrag veröffentlichen und gibt das Ergebnis aus. --base-url und --api-key lesen auch aus den Umgebungsvariablen CARDANOWALL_BASE_URL und CARDANOWALL_API_KEY, sodass sie im CI aus dem Befehl herausfallen.

Für den wiederholten Einsatz speicherst du das Gateway als benanntes Profil, statt den Endpunkt jedes Mal zu übergeben:

cardanowall gateway add prod --base-url https://your-gateway.example
cardanowall gateway use prod
cardanowall submit --file ./contract.pdf

Das cardanowall-Binary ist ein einzelnes, eigenständiges natives Werkzeug ohne zu installierende Laufzeitumgebung. Installiere es von crates.io mit cargo install cardanowall-cli (der Crate heißt cardanowall-cli; der installierte Befehl ist cardanowall) oder baue es aus dem Open-Source-Repository unter github.com/cardanowall.

Wie veröffentlichst du einen Hash, den du schon hast?

Manchmal existiert der Digest bereits – aus einer Build-Pipeline, einer Container-Registry, einem Release-Prozess oder einem Datenarchiv. In dem Fall veröffentlichst du den Digest direkt, ganz ohne Datei:

cardanowall submit --hash <64-hex-digest>

Der Standard-Hash-Modus ist sha2-256. Übergib --alg blake2b-256, wenn du stattdessen diesen Algorithmus brauchst. Der Eintrag hält fest, welchen Algorithmus du verwendet hast, damit ein Verifizierer später weiß, wie er den Digest neu berechnen muss.

Einen vorberechneten Hash zu veröffentlichen ist auch dann die richtige Wahl, wenn die Quelldatei zu groß, zu sensibel oder zu streng kontrolliert ist, um sie durch ein Allzweck-Werkzeug zu schleusen. Wichtig ist allein, dass die exakten Bytes und der exakte Hashing-Prozess reproduzierbar bleiben – sonst kann niemand einen passenden Digest neu berechnen.

Solltest du den Eintrag signieren?

Signiere den Eintrag, wenn du nachweisen willst, dass eine bestimmte Label-309-Identität für ihn einsteht.

Ein reiner Hash-Nachweis sagt: diese Bytes existierten zu diesem Zeitpunkt. Ein signierter Nachweis ergänzt: und dieser Signaturschlüssel steht hinter genau diesem Eintrag. Diese zusätzliche Aussage ist wichtig für Release-Einträge von Unternehmen, offizielle Archive, CI/CD-Pipelines, Workflows mit Beweismitteln, KI-Provenienz-Logs und jede langlebige öffentliche Veröffentlicher-Identität.

Signaturen sind immer optional. Ein unsignierter Nachweis ist nach wie vor ein vollständiger, voll verifizierbarer Existenznachweis – Label 309 ist von Grund auf herausgeberunabhängig, und ein Verifizierer muss dem Veröffentlichenden nie vertrauen. Das Signieren beantwortet nur eine andere Frage: wer für den Eintrag einsteht, nicht ob die Bytes existiert haben.

Der Identity Seed darf niemals an das Gateway gesendet werden. CLI und SDK sind so gebaut, dass das Signieren lokal passiert und nur die fertige Signatur den Rechner verlässt. Liefere den Seed über --seed-stdin oder --seed-file, statt über ein blankes --seed-Argument, denn Kommandozeilen-Argumente sickern durch Shell-Verlauf, Prozesslisten und CI-Logs durch:

cardanowall submit --file ./release-manifest.json --seed-stdin

Solltest du die Datei anhängen oder nur den Hash?

Du hast drei Möglichkeiten, in aufsteigender Reihenfolge dessen, was du on chain festschreibst.

Nur Hash. Der kleinste und privateste Nachweis. Er reicht, wenn du ohnehin schon weißt, dass die Datei an einem Ort aufbewahrt wird, den du selbst kontrollierst. Der Eintrag trägt den Digest und nichts über den Abruf.

Hash plus inhaltsadressierter Link. Häng eine ar:// (Arweave)- oder ipfs:// (IPFS)-URI an, damit Verifizierer die Bytes später abrufen können. Der Hash entscheidet weiterhin, ob die abgerufenen Bytes passen – eine inhaltsadressierte URI bindet die Bytes an den Link selbst, sodass ein Verifizierer weder dem Gateway noch DNS noch TLS vertrauen muss, um zu wissen, dass er die richtige Datei abgerufen hat.

Versiegelt. Verschlüssele die Datei, speichere den Chiffretext off-chain und leg den versiegelten Umschlag in den Eintrag. Das ist der Weg für vertrauliche Einträge, für die Zustellung an einen benannten Empfänger und für das spätere Wiederherstellen des Inhalts, falls deine lokale Kopie verloren geht.

Für einen ersten Nachweis fang mit „nur Hash“ an. Signieren, Off-chain-Speicher, Merkle-Bündelung oder versiegelte Zustellung fügst du hinzu, wenn ein echter Anwendungsfall danach verlangt.

Woher weißt du, dass es tatsächlich funktioniert hat?

Hör nicht bei „das Gateway hat ihn angenommen“ auf. Der Nachweis ist erst dann vollständig, wenn die Transaktion on chain ist und verifiziert.

Wenn du veröffentlichst, gibt dir das Gateway sofort eine Eintrags-ID zurück, und der Transaktions-Hash füllt sich asynchron, sobald die Transaktion gebaut und eingereicht ist. Bewahre nach dem Veröffentlichen also auf:

den Cardano-Transaktions-Hash;
die Gateway-Eintrags-ID, falls du ein Gateway genutzt hast;
die Originaldatei oder den Digest;
die öffentliche Identität des Signaturschlüssels, falls du signiert hast;
jede Merkle-Blattliste oder jeden Inklusionsnachweis, falls du gebündelt hast;
jegliches Wiederherstellungsmaterial, falls der Nachweis versiegelt ist.

Dann verifizierst du die Transaktion genauso, wie es jeder Dritte täte – aus der öffentlichen Chain, ganz ohne Gateway:

cardanowall verify <tx-hash> --json

Ein valid-Urteil ist die Ziellinie. Die anderen Urteile sagen dir, was als Nächstes zu tun ist:

pending – die Transaktion ist noch nicht tief genug abgeschlossen. Warte auf weitere Bestätigungen und versuch es erneut.
unverifiable – kein Fehler im Eintrag, aber eine erforderliche Prüfung konnte nicht laufen. Prüfe deine Datenquellen, die Verfügbarkeit deines Off-chain-Speichers und deine Netzwerkrichtlinie.
failed – ein echtes, dem Eintrag zurechenbares Problem. Untersuche den Eintrag selbst.

Die Trennung zwischen failed und unverifiable ist Absicht: failed bedeutet, dass der Eintrag falsch ist, während unverifiable bedeutet, dass der Verifizierer eine Prüfung nicht abschließen konnte. Den vollständigen Verifizierungsablauf findest du unter einen Label-309-Eintrag verifizieren.

Was sollte eine Oberfläche nach dem Veröffentlichen zeigen?

Eine gute Oberfläche zeigt mehr als das Wort „veröffentlicht“. Für einen ersten Nachweis solltest du Folgendes sichtbar machen:

den kurzen Transaktions-Hash, mit einem Kopier-Button;
den vollständigen Transaktions-Hash in der Detailansicht;
den Hash-Algorithmus und den Digest;
den Veröffentlichungsstatus;
die Blockzeit, sobald bestätigt;
das Verifizierungsurteil;
ob der Eintrag signiert wurde;
ob Dateien angehängt oder versiegelt wurden;
ob irgendwelche Prüfungen übersprungen wurden.

Das macht den Nachweis verständlich, ohne dass jemand die Spezifikation lesen muss.

Was kann beim Veröffentlichen schiefgehen?

Die meisten Fehler beim Veröffentlichen sind operativ, nicht mysteriös. Dem Account kann das Guthaben ausgehen. Der Kostenvoranschlag kann abgelaufen sein. Der Eintrag kann zu groß für eine Cardano-Transaktion sein. Eine hochgeladene Datei kann nicht gespeichert werden. Die Cardano-Transaktion kann dauerhaft fehlschlagen – in dem Fall macht ein gut gebautes Gateway die Belastung selbst rückgängig, sodass dir nur das berechnet wird, was on chain landet. Oder die finanzierte Wallet des Gateways braucht schlicht Aufmerksamkeit.

Ein ernsthafter Veröffentlichungs-Workflow behandelt Wiederholungen idempotent. Ein Gateway entdoppelt einen Wiederholungsversuch anhand der exakten Bytes des Eintrags – das erneute Einreichen desselben Eintrags gibt das bestehende Ergebnis zurück, statt zweimal Geld auszugeben – und akzeptiert einen Idempotenz-Schlüssel auf Upload-Batches, sodass ein erneut zugestellter Upload wiederholungssicher ist. Gestalte in einem nutzerseitigen Produkt den Wiederholungspfad, bevor dein erster echter Kunde in ein Netzwerk-Timeout läuft, nicht danach.

Wenn du das in eine Pipeline einbaust, geht die CLI in der Automatisierung nutzen tiefer auf JSON-Ausgabe, Exit-Codes und den sicheren Umgang mit Geheimnissen ein.

Was beweist dein erster Nachweis nicht?

Ein Existenznachweis ist präzise darin, was er behauptet – was bedeutet, dass er auch präzise darin ist, was er nicht behauptet.

Er beweist kein Eigentum.
Er beweist keine Urheberschaft – es sei denn, du signierst ihn und kannst den Signaturschlüssel an die behauptete Identität binden.
Er beweist nicht, dass die Datei wahr, rechtmäßig oder original ist.
Er bewahrt die Datei nicht, es sei denn, du speicherst sie an einem dauerhaften Ort.

Was er beweist, ist exakt und dauerhaft: dass die präzisen Bytes, die zum festgeschriebenen Hash passen, spätestens zur Blockzeit der Transaktion existierten, und dass alle optionalen Signaturen, Speicherprüfungen oder Prüfungen versiegelter Inhalte gemäß der Richtlinie des Verifizierers verifiziert haben.

Das reicht aus, um wirklich nützlich zu sein, und ist präzise genug, um vertrauenswürdig zu sein. Die ausführlichere Grenze dessen, was ein Zeitstempel feststellen kann und was nicht, findest du unter was ein Nachweis nicht beweist.

Weiterführende Lektüre

Einen Label-309-Eintrag verifizieren – die vertrauensfreie, accountlose andere Hälfte des Ablaufs.
Warum das Veröffentlichen einen Preis hat – wofür die Gebühr aufkommt.
Die CLI in der Automatisierung nutzen – JSON-Ausgabe, Exit-Codes und Geheimnisse im CI.
Was auf die Blockchain kommt – die Felder, die ein Eintrag tatsächlich trägt.
Der offene Standard und die Referenzimplementierungen: label309.org und der Quellcode unter github.com/cardanowall.