Wie du einen Label-309-Eintrag verifizierst

Du verifizierst einen Label 309-Eintrag direkt aus der öffentlichen Cardano-Chain, ausgehend von einer einzigen Eingabe: einer Transaktionsreferenz. Nichts an der Antwort hängt von CardanoWall ab, vom Veröffentlichenden oder davon, dass irgendein Server noch online ist.

Ein Verifizierer ruft die rohen Transaktions-Bytes aus öffentlicher Cardano-Infrastruktur ab, extrahiert das Metadaten-Label 309, setzt den Eintragskörper wieder zusammen, prüft das kanonische CBOR und das Schema, verifiziert etwaige Urheberschaftssignaturen und – wenn der Inhalt oder eine verschlüsselte Nutzlast verfügbar ist – berechnet die Hashes neu. Die gesamte Prüfung ist eine Folge kryptografischer Vergleiche, keine Anfrage an einen vertrauenswürdigen Dienst.

Das Gateway, das den Eintrag veröffentlicht hat, ist nicht die Autorität. Der Eintrag ist es. Genau darum geht es bei dem Standard: Ein Nachweis, den du einmal prüfst, bleibt für jeden prüfbar, für immer, mit jedem konformen Label-309-Werkzeug.

Was brauchst du zum Verifizieren?

Die Mindesteingabe ist ein Cardano-Transaktions-Hash.

Allein mit diesem Transaktions-Hash kann ein Verifizierer beantworten:

• gibt es in dieser Transaktion einen Label-309-Eintrag?
• ist der Eintrag strukturell gültig?
• ist die Transaktion tief genug bestätigt?
• verifizieren die Signaturen auf Eintragsebene, falls Signaturen vorhanden sind?
• welche Hashes, Speicher-URIs, Merkle-Wurzeln und versiegelten Umschläge behauptet der Eintrag?

Um zu beweisen, dass eine bestimmte Datei die Datei hinter dem Hash ist, braucht der Verifizierer zusätzlich die Datei-Bytes oder ein zurechenbares Speicherobjekt, auf das der Eintrag verweist.

Um einen versiegelten Eintrag zu entschlüsseln, braucht der Verifizierer den privaten Empfängerschlüssel. Dieser Schlüssel wird lokal verwendet und niemals an den Veröffentlichenden oder an CardanoWall zurückgesendet – die gesamte Konstruktion ist so angelegt, dass die Verifizierung nie nach Hause telefoniert.

Was prüft ein Verifizierer tatsächlich?

Ein guter Verifizierer sollte den Eintrag in Schichten prüfen.

Die erste Schicht ist der strukturelle Validator. Das ist eine reine Funktion über die Eintrags-Bytes. Sie führt keine Netzwerkaufrufe, keine Entschlüsselung und keine Signaturverifizierung durch. Sie prüft das kanonische CBOR, die Feldtypen, das geschlossene Schema, die registrierten Algorithmennamen, die URI-Regeln und feldübergreifende Bedingungen wie „es muss mindestens ein item oder ein Merkle-Commitment geben“.

Die zweite Schicht ist der öffentliche Verifizierer. Er löst die Transaktion aus einer vom Verifizierer gewählten Cardano-Datenquelle auf, bindet die abgerufenen Bytes an den Transaktions-Hash, extrahiert das Label 309, prüft die Bestätigungstiefe und verifiziert die Eintragssignaturen. Das ist die Schicht, die ein öffentliches Audit, ein CI-Job oder ein Explorer ausführen kann.

Die dritte Schicht ist der Empfänger-Verifizierer. Er tut alles, was der öffentliche Verifizierer tut, und versucht dann, versiegelte items mit dem lokalen Empfängerschlüssel zu entschlüsseln und die Klartext-Hashes nach der Entschlüsselung neu zu berechnen.

Diese Schichtung ist wichtig, weil nicht jeder Nachweis jede Prüfung braucht. Ein Eintrag mit reinem Hash kann auch dann gültig sein, wenn er keine verschlüsselte Nutzlast hat. Ein öffentlicher Verifizierer kann einen signierten Eintrag validieren, ohne eine versiegelte Datei entschlüsseln zu können.

Warum aus rohen Transaktions-Bytes verifizieren und nicht aus einer JSON-Ansicht?

Die Label-309-Verifizierung arbeitet mit rohen Chain-Daten, nicht mit einer bequemen JSON-Projektion – und der Unterschied ist nicht bloß kosmetisch.

Der Eintrag ist kanonisches CBOR. Signaturen decken byte-genaues kanonisches CBOR ab. Cardano-Transaktions-Metadaten haben Byte-Strings, Text-Strings, Arrays, Maps und Reihenfolge-Regeln, die JSON nicht verlustfrei bewahren kann.

Ein Verifizierer sollte also das rohe Transaktions-CBOR abrufen, die Transaktions-ID neu berechnen, die Auxiliary Data an den Transaktionskörper binden und dann das Label-309-Chunk-Array wieder zum ursprünglichen Eintragskörper zusammensetzen.

Ein Explorer kann nützliche Infrastruktur sein. Er sollte nicht zu dem werden, dem du vertraust. Der Verifizierer sollte Explorer-Antworten als Daten behandeln, die es zu binden, zu prüfen und gegenzuprüfen gilt.

Was steckt in einem Label-309-Eintrag?

Ein Label-309-Eintrag wird unter dem Cardano-Transaktions-Metadaten-Label 309 transportiert.

Der On-Chain-Wert ist kein loses JSON-Objekt. Der Eintragskörper wird einmal als kanonisches CBOR serialisiert und dann als Array von Byte-String-Chunks transportiert, weil Cardano-Metadaten-Byte-Strings und -Text-Strings auf 64 Byte begrenzt sind.

Nach dem Zusammensetzen ist der Eintragskörper eine einzelne CBOR-Map. Ihre obersten Schlüssel sind:

• v, die Schema-Version (aktuell 1);
• items, ein optionales Array von Commitments pro Inhalt – jedes item trägt eine erforderliche hashes-Map und optional seine eigene uris-Liste für inhaltsadressierten Speicher (ar://, ipfs://) sowie ein enc-Envelope für versiegelten Inhalt;
• merkle, optionale Listen-Commitments, die eine On-Chain-Wurzel an eine Off-Chain-Blattliste binden – die Art und Weise, wie große Bündel verankert werden;
• sigs, optionale Urheberschaftssignaturen auf Eintragsebene;
• supersedes, ein optionaler, nur-anfügender Zeiger auf einen früheren Eintrag;
• crit plus namespacierte Erweiterungsschlüssel, für vorwärtskompatible Ergänzungen.

Ein konformer Eintrag muss sich auf mindestens einen items-Eintrag oder ein merkle-Commitment festlegen. Die Speicher-URIs und der versiegelte Umschlag liegen innerhalb eines items, nicht auf der obersten Ebene – ein Detail, das man richtig hinbekommen sollte, wenn man den Eintrag selbst parst.

Die zentrale Aussage ist immer content-first: Diese Hashes oder diese Merkle-Wurzel wurden in dieser Transaktion spätestens zur Blockzeit verankert.

Welche Urteile sollte Automatisierung erwarten?

Die Verifizierung sollte nicht jedes Problem auf „gültig“ oder „ungültig“ zusammenfallen lassen.

Das Verifizierer-Modell von Label 309 verwendet vier maschinelle Urteile:

• valid: jede erforderliche Prüfung ist bestanden.
• failed: der Eintrag selbst hat eine strukturelle, eine Signatur- oder eine zurechenbare Integritätsprüfung nicht bestanden.
• unverifiable: eine erforderliche Prüfung konnte aus Gründen nicht abgeschlossen werden, die nicht dem Eintrag zuzurechnen sind, etwa nicht verfügbare Infrastruktur oder Inhalt, der nicht abgerufen werden konnte.
• pending: die Transaktion ist on-chain, aber unterhalb der Bestätigungsschwelle des Verifizierers.

Diese Aufteilung ist in echten Systemen wichtig.

Wenn ein Storage-Gateway ausgefallen ist, sollte der Eintrag nicht verurteilt werden. Wenn abgerufene Bytes einer festgelegten URI zurechenbar sind und ihr Hash nicht übereinstimmt, sollte der Eintrag fehlschlagen. Wenn die Transaktion nur eine Bestätigung hat, sollte der Verifizierer sagen, dass sie pending ist, statt so zu tun, als sei die Finalität bereits eingetreten.

Die quelloffene cardanowall CLI bildet diese Zustände direkt auf Exit-Codes ab, sodass das Urteil bis in ein Shell-Skript überlebt, ohne dass irgendein JSON geparst werden muss:

cardanowall verify <tx-hash> --json

Diese Aufteilung ist genau das, was du in der Continuous Integration willst: Das Skript kann „der Nachweis ist schlecht“ (Exit 1, und niemals von einem sich fehlverhaltenden Explorer herbeiführbar) von „versuch es später noch einmal“ (Exit 2) unterscheiden. Derselbe Verifizierer steckt in den TypeScript-, Python- und Rust-SDKs, sodass eine Anwendung den vollständigen strukturierten Bericht lesen kann statt eines Exit-Codes. Zu den Mustern, wie du das in eine Pipeline einbindest, siehe die CLI in der Automatisierung nutzen.

Wie verifizierst du eine Datei?

Für einen einfachen Datei-Nachweis ist der Ablauf:

1. Nimm den Transaktions-Hash.
2. Ruf den Label-309-Eintrag ab und verifiziere ihn.
3. Identifiziere den festgelegten Hash-Algorithmus und Digest.
4. Hash die Datei-Bytes lokal.
5. Vergleiche deinen Digest mit dem Digest im Eintrag.
6. Prüfe Bestätigungstiefe und Blockzeit.
7. Prüfe etwaige Eintragssignaturen, falls vorhanden.

Wenn sich die Datei um ein einziges Byte unterscheidet, unterscheidet sich der Hash.

Das ist die Stärke eines Content-Hash-Nachweises. Er beweist nicht, dass die Datei wahr, legal, original oder wertvoll ist. Er beweist, dass die exakten Bytes, die zum Hash passen, spätestens zur verankerten Blockzeit existierten – nach Maßgabe der Finalitätsrichtlinie des Verifizierers.

Wie verifizierst du einen versiegelten Eintrag?

Ein versiegelter Eintrag fügt verschlüsselten Inhalt hinzu.

Der öffentliche Eintrag legt sich weiterhin auf den Klartext-Hash fest. Der Chiffretext kann off-chain gespeichert werden, zum Beispiel über Arweave oder IPFS. Das On-Chain-Envelope enthält die Information, die ein vorgesehener Empfänger braucht, um den Content-Schlüssel lokal wiederherzustellen.

Der Empfänger-Verifizierer sollte:

1. Zuerst den öffentlichen Verifizierungspfad durchlaufen.
2. Den bereitgestellten privaten Schlüssel gegen die versiegelten Slots ausprobieren.
3. Wenn sich ein Slot öffnet, den Chiffretext entschlüsseln.
4. Den Klartext-Hash neu berechnen.
5. Ihn mit dem On-Chain-Hash-Commitment vergleichen.

Diese abschließende Hash-Prüfung ist die Brücke zwischen „ich habe etwas entschlüsselt“ und „das ist der exakte Inhalt, der mit einem Zeitstempel versehen wurde“. Die Bytes zu entschlüsseln reicht für sich genommen nicht; der neu berechnete Klartext-Hash muss mit dem Commitment übereinstimmen, das der Eintrag gemacht hat, bevor irgendetwas verschlüsselt wurde.

Der Empfängerschlüssel bleibt lokal. Die Verifizierung braucht kein vertrauenswürdiges CardanoWall-Konto, keinen Herausgeber-Server und keinen Rückruf an die Person, die den Eintrag veröffentlicht hat. Ein versiegelter Eintrag hält seinen Klartext gegenüber den Schlüsselinhabern vertraulich – aber beachte seine Grenzen: Er garantiert keine Anonymität, und sobald ein Empfänger den Inhalt entschlüsselt, kann er mit dem Klartext machen, was er will.

Wie verifizierst du ein Merkle-Commitment?

Merkle-Commitments sind für Bündel da.

Statt Tausende von Hashes direkt in einem Eintrag zu veröffentlichen, kann ein Produzent eine einzige Merkle-Wurzel veröffentlichen und die geordnete Blattliste sowie die Inklusionsnachweise off-chain halten.

Um ein item aus dem Bündel zu verifizieren:

1. Hash das item oder beschaffe den festgelegten Blatt-Digest.
2. Verifiziere den Inklusionsnachweis gegen die Merkle-Wurzel.
3. Prüfe, dass die Wurzel und leaf_count im Label-309-Eintrag stehen.
4. Verifiziere die Cardano-Transaktion und die Bestätigungstiefe.

Die Wurzel allein reicht nicht. Der Produzent oder das Archiv muss die Blattliste und die Inklusionsnachweise aufbewahren. Label 309 gibt dem Bündel einen öffentlichen Anker; die operativen Nachweise rund um das Bündel müssen weiterhin aufbewahrt werden. So beweist ein Eintrag Tausende von Dateien zu festen On-Chain-Kosten.

Was sollte nicht vertraut werden?

Vertraue der Website des Veröffentlichenden nicht als Quelle der Wahrheit.

Vertraue einem Screenshot einer Transaktion nicht.

Vertraue einer JSON-Explorer-Ansicht nicht als kryptografischer Eingabe.

Vertraue einem Storage-Gateway nicht allein deshalb, weil es Bytes zurückgegeben hat.

Vertraue keinen „verifiziert“-Plaketten, die nicht sagen, was geprüft wurde.

Der Verifizierer sollte einen Bericht erzeugen können: Transaktions-Hash, verwendete Cardano-Datenquellen, Bestätigungstiefe, Blockzeit, Eintrags-Digest, Signaturergebnisse, Content-Hash-Ergebnisse, Speicher-Abrufergebnisse, Merkle-Prüfungen und etwaige übersprungene Prüfungen.

Dieser Bericht ist es, was den Nachweis in Audits und Automatisierung brauchbar macht.

Was beweist die Verifizierung nicht?

Die Verifizierung ist präzise. Man sollte sie nicht überverkaufen.

Ein gültiger Label-309-Eintrag beweist für sich genommen nicht:

• rechtliches Eigentum am Inhalt oder ausschließliche Rechte daran;
• dass der Inhalt wahr ist;
• dass der Veröffentlichende die Erlaubnis hatte, ihn zu veröffentlichen;
• dass eine reale Person über einen Signaturschlüssel verfügt;
• dass ein Gericht, eine Behörde oder ein Kunde den Nachweis ohne stützende Beweise akzeptiert – die Zulässigkeit als Beweismittel hängt von der Rechtsordnung ab, und ein Nachweis kann einen Fall stützen, ersetzt aber keinen Rechtsbeistand;
• dass Off-Chain-Speicher für immer verfügbar bleibt, sofern die Haltbarkeit des Speichers nicht separat gepflegt wird.

Er beweist die Aussage, die der Eintrag tatsächlich macht: Ein Hash oder eine Merkle-Wurzel wurde auf Cardano verankert, etwaige Signaturen über den Eintrag verifizierten, und etwaige Inhalts- oder Entschlüsselungsprüfungen stimmten mit den Commitments überein. Mit anderen Worten: Er belegt Zeitpunkt und Integrität – nicht Wahrheit, Eigentum oder Rechte.

Genau diese engere Aussage macht ihn nützlich. Zur vollständigen Grenze dessen, was ein Zeitstempel kann und nicht kann, siehe was ein Nachweis nicht beweist.

Weiterführende Lektüre

• Der Label-309-Standard, einschließlich der vollständigen Verifizierungs-Pipeline, der Urteilszustände und des typisierten Fehlerkatalogs: label309.org.
• Der quelloffene Verifizierer – die cardanowall CLI plus die TypeScript-, Python- und Rust-SDKs, die alle dieselben Prüfungen ausführen: github.com/cardanowall.
• Label 309 ist beim Cardano-CIP-Prozess eingereicht und wird von den CIP-Editoren als Vorschlag der Metadaten-Kategorie geprüft: der offene Pull Request.