Wie Label 309 funktioniert

Label 309 legt fest, wie ein Existenznachweis-Eintrag in die Cardano-Transaktions-Metadaten geschrieben wird. Im Kern legt ein Eintrag einen oder mehrere Content-Hashes unter dem Metadaten-Label 309 auf Cardano fest. Die Blockzeit dieser Transaktion wird zum öffentlichen Zeugen dafür, dass genau diese Bytes spätestens zu diesem Zeitpunkt existiert haben. Alles andere, was der Eintrag tragen kann – Signaturen, Storage-URIs, verschlüsselte Inhalte, empfängerspezifische Schlüssel-Slots, Merkle-Wurzeln, ein Zeiger auf einen früheren Eintrag –, sind optionale Metadaten zu dieser einen Aussage.

Das Designziel ist leicht gesagt: Ein Nachweis sollte eigenständig verifizierbar sein. Die grundlegende Aussage zu prüfen, sollte kein Vertrauen in CardanoWall, die Website eines Herausgebers, eine private Datenbank oder eine Zertifizierungsstelle voraussetzen – nur die öffentliche Blockchain und, bei Inhaltsaussagen, die ursprünglichen Bytes.

Label 309 ist ein offener Standard. Er wurde beim Cardano-CIP-Prozess eingereicht – als Vorschlag der Kategorie Metadata – und wird von den CIP-Editoren geprüft; das Metadaten-Label selbst ist der dauerhafte On-Chain-Identifikator, und Web-App, CLI und SDKs sind Referenzimplementierungen davon, nicht der Standard selbst. Wenn du zuerst das größere Bild willst, starte mit was ein Existenznachweis eigentlich ist.

Was wird unter Label 309 auf der Blockchain gespeichert?

Ein Label-309-Eintrag lebt in den Cardano-Transaktions-Metadaten unter dem Integer-Label 309. Genau ein Eintrag pro Transaktion; ein Verifizierer ignoriert jedes andere Metadaten-Label.

Der Eintragskörper ist als kanonisches CBOR codiert – ein deterministisches Binärformat, sodass zwei Implementierungen, die denselben logischen Eintrag ausdrücken, byteidentische Bytes ausgeben. Cardano begrenzt jeden einzelnen Metadaten-String auf 64 Byte, und ein serialisierter Eintrag ist meist größer als das. Deshalb wird der Körper als ein CBOR-Array kleiner Byte-String-Chunks transportiert, deren Verkettung in der richtigen Reihenfolge der Eintragskörper ist. Ein Verifizierer fügt die Chunks wieder zusammen, bevor er irgendetwas validiert. Das ist die einzige Chunking-Operation, die das Format durchführt.

Dieses Transportdetail ist für Implementierer wichtig, doch die Idee dahinter ist schlicht:

Die Transaktion trägt das Metadaten-Label 309.
Der Wert unter diesem Label setzt sich zu einem Label-309-Eintrag zusammen.
Der Eintrag legt sich auf Content-Hashes, Merkle-Wurzeln oder beides fest.
Optionale Felder ergänzen Signaturen, Material für verschlüsselte Inhalte, Storage-URIs und einen Ersatz-Zeiger.

Das ist kein freies Notizfeld. Der Eintrag hat eine strikte, geschlossene Form – und genau das erlaubt es verschiedenen Implementierungen, dieselben Bytes zu erzeugen und zu verifizieren.

Warum ist der Content-Hash die primäre Aussage?

Weil ein Existenznachweis eine Aussage über exakte Bytes ist – und ein Hash der Fingerabdruck exakter Bytes.

Der Content-Hash ist die primäre Aussage in Label 309; jedes andere Feld ist Metadaten dazu. Für einen einfachen Datei-Nachweis trägt ein item eine hashes-Map, die einen benannten Hash-Algorithmus – zum Beispiel sha2-256 oder blake2b-256 – mit einem rohen 32-Byte-Digest verknüpft. Um den Nachweis zu prüfen, berechnet ein Verifizierer den Digest aus der Originaldatei neu und vergleicht ihn mit dem Digest im Eintrag.

Stimmen die Bytes überein, besteht der Nachweis. Ändere ein einziges Byte, und der Digest ändert sich, sodass der Nachweis fehlschlägt.

Deshalb bleibt die Aussage klein, selbst wenn der Inhalt groß oder vertraulich ist. Der Eintrag braucht nie die Datei. Er braucht den Fingerabdruck.

Was sind items, uris und enc?

items sind die inhaltsbezogenen Festlegungen in einem Eintrag. Jedes item ist eine Inhaltsaussage. Der einzige Pflichtteil ist eine nichtleere hashes-Map; der Rest ist optional.

Ein item kann tragen:

hashes – die erforderliche Map von Hash-Algorithmus zu rohem Digest;
uris – optionale inhaltsadressierte Speicherorte wie ar://… (Arweave) oder ipfs://… (IPFS);
enc – ein optionaler Verschlüsselungs-Umschlag für einen versiegelten (verschlüsselten) Eintrag.

Der entscheidende Gedanke ist, dass uris nicht der Nachweis sind. Der Hash ist der Nachweis. Eine URI ist ein Abrufhinweis oder eine Speicher-Festlegung, die einem Verifizierer hilft, prüfbare Bytes zu finden. Ein reiner Hash-Eintrag ohne URI ist ein vollständiger, gültiger Nachweis. Ein Eintrag mit URI kann beim Abruf öffentlicher Inhalte oder von Chiffretext helfen. Ein versiegelter Eintrag hält den Klartext off-chain verschlüsselt und beweist zugleich, wann er existiert hat.

Warum nur `ar://` und `ipfs://`?

Label 309 v1 beschränkt Storage-URIs auf inhaltsadressierte Schemata – Arweave und IPFS – und lehnt alles andere ab, auch https://. Diese Beschränkung ist bewusst gewählt, nicht vorübergehend.

Eine normale https://-URL hängt von DNS, TLS, Serververhalten, Weiterleitungen und davon ab, was später unter dieser Adresse gehostet wird. Eine inhaltsadressierte URI ist anders: Die Adresse selbst wird aus dem Inhalt abgeleitet (eine IPFS-CID ist ein Multihash der Bytes; eine Arweave-Transaktions-ID legt sich unter dem Arweave-Konsens auf die Daten fest). So kann ein Verifizierer bestätigen, dass „die Bytes, die ich abgerufen habe, die Bytes sind, auf die sich der Produzent festgelegt hat“ – ohne dem Storage-Gateway, DNS oder einer Zertifizierungsstelle zu vertrauen. Die abgerufenen Bytes müssen weiterhin mit der On-Chain-Festlegung übereinstimmen; die Storage-Schicht ist für sich genommen nie eine Quelle der Wahrheit.

Was beweisen Signaturen – und was nicht?

Ein Label-309-Eintrag kann ein optionales sigs-Array auf oberster Ebene tragen. Jeder Eintrag darin ist eine abgetrennte COSE_Sign1-Signatur über den Eintragskörper, wobei das Feld sigs entfernt wurde. Schlicht gesagt: Ein Signierender bürgt für den gesamten Eintrag auf einmal – jedes item, jeden Hash, jede URI, jeden versiegelten Umschlag, jede Merkle-Wurzel, den Ablösungszeiger und alle Erweiterungsfelder.

Signieren ist additiv. Ein Eintrag ohne Signatur beweist trotzdem die Existenz. Ein Eintrag mit gültiger Signatur zeigt zusätzlich, dass ein bestimmter Schlüssel hinter dem Eintrag stand:

reiner Hash: Diese Bytes existierten bis zu dieser öffentlichen Zeit;
signiert: Diese Bytes existierten bis zu dieser öffentlichen Zeit, und dieser Schlüssel hat für den Eintrag gebürgt.

Die Präzision ist wichtig, denn eine Signatur beweist weniger, als oft angenommen wird. Eine verifizierte Signatur beweist nicht, dass derselbe Schlüssel die Cardano-Transaktion bezahlt oder eingereicht hat, dass er die Blockzeit gewählt hat oder dass er zu einer namentlich benannten realen Person gehört. Sie beweist, dass der Schlüssel den Eintragskörper signiert hat – nicht mehr. Gib sie als „signiert von diesem Schlüssel“ wieder, niemals als „veröffentlicht von diesem Schlüssel“. Diese enge, ehrliche Bedeutung macht einen signierten Nachweis über verschiedene Apps und Gateways hinweg portabel. Urheberschaft ist immer optional, und eine Signatur, die ein Verifizierer nicht prüfen kann (ein nicht unterstützter Algorithmus, ein nicht auflösbarer Schlüssel), entwertet die Existenzaussage nie – Signaturen schlagen sanft fehl; die Existenz nicht.

Was ist ein versiegelter Eintrag?

Ein versiegelter Eintrag hält den Inhalt vertraulich und beweist trotzdem, wann er existiert hat.

In einem versiegelten Label-309-Eintrag legt sich das item weiterhin auf den Klartext-Hash fest – nie auf den Chiffretext. Der Klartext wird verschlüsselt, und der Chiffretext lebt an einer inhaltsadressierten URI (ar://… oder ipfs://…), nie on-chain. Der On-Chain-Eintrag trägt einen Verschlüsselungs-Umschlag mit dem Material, das ein ausgewählter Schlüsselinhaber braucht, um den Inhalts-Verschlüsselungsschlüssel wiederherzustellen. Die Blockchain enthält den Klartext nicht, und sie veröffentlicht keine Empfängerliste.

Für einen Empfänger kommen bei der Verifizierung ein paar Schritte hinzu:

Den Eintrag von Cardano abrufen.
Den Chiffretext aus dem inhaltsadressierten Speicher abrufen.
Lokal versuchen, einen passenden Schlüssel-Slot zu öffnen.
Den Chiffretext entschlüsseln, falls sich ein Slot öffnet.
Den Klartext-Hash neu berechnen und mit der On-Chain-Festlegung vergleichen.

Weil der On-Chain-Digest den Klartext bindet, bewahrt ein versiegelter Nachweis die exakte Originaldatei und hält sie privat. Ein paar ehrliche Grenzen gehören dazu: Ein versiegelter Eintrag beweist Zeitpunkt und Integrität, nicht Anonymität, und ein Empfänger, der entschlüsselt, kann den Klartext danach immer noch weitergeben.

Wie funktionieren Empfänger ohne ein Empfängerfeld?

Empfänger funktionieren über Empfangsschlüssel und Probeentschlüsselung, nicht über ein lesbares Adressatenfeld.

Wenn ein Absender die Empfangsadresse eines Empfängers kennt (ein öffentlicher X25519-Schlüssel, optional ein hybrider Post-Quanten-Schlüssel), kann der Absender einen versiegelten Eintrag mit einem Schlüssel-Slot bauen, den dieser Empfänger öffnen kann. Der öffentliche Schlüssel des Empfängers erscheint nie als lesbares Feld im Eintrag. Die Software des Empfängers beobachtet den öffentlichen Strom der Label-309-Einträge und versucht lokal, Kandidaten-Slots zu entschlüsseln; öffnet sich ein Slot, gehört der Eintrag in die Inbox dieses Empfängers.

Deshalb ist eine CardanoWall-Inbox kein gewöhnliches serverseitiges Postfach. Das Gateway stellt einen empfängerblinden Feed von Einträgen bereit; der Client findet die, die er entschlüsseln kann. Der Server muss nie wissen, wer der Empfänger ist, und entschlüsselt nie etwas in dessen Auftrag. (Siehe wie man versiegelte Einträge empfängt für die Empfängerseite in der Praxis.)

Es gibt dennoch Metadaten-Grenzen, die man klar benennen sollte. Der Eintrag veröffentlicht nie Klartext oder eine Empfängerspalte, und die Slot-Reihenfolge wird vor der Veröffentlichung gemischt, sodass sie kein Signal trägt. Aber die Anzahl der Slots ist sichtbar, und Zeitpunkte, Zahlungsspuren und Bedienfehler können Informationen preisgeben, die das Eintragsformat selbst nicht verbergen kann.

Wie deckt ein Eintrag Tausende von Dateien ab?

Wenn du beweisen musst, dass tausend Dateien existiert haben, solltest du dafür keine tausend Cardano-Transaktionen brauchen. Label 309 unterstützt Merkle-Bündelung: Hashe die Dateien, baue einen Merkle-Baum über die geordnete Liste der Hashes und veröffentliche eine einzelne 32-Byte-Wurzel im merkle-Array des Eintrags. Neben der Wurzel trägt der Eintrag einen Blatt-Zähler, der die On-Chain-Wurzel an die exakte Größe der Off-Chain-Liste bindet.

Später kannst du beweisen, dass eine bestimmte Datei oder ein bestimmtes Ereignis im Bündel war, indem du Folgendes zeigst:

die Datei (oder ihren Blatt-Hash);
einen Inklusionsnachweis – die Geschwister-Hashes entlang des Pfads zur Wurzel;
die Merkle-Wurzel, die im Label-309-Eintrag verankert ist.

Der Verifizierer faltet den Inklusionsnachweis wieder zu einer Wurzel hoch und akzeptiert ihn nur, wenn die neu berechnete Wurzel der veröffentlichten Wurzel Byte für Byte entspricht. Jedes nicht offengelegte Blatt bleibt privat – die Wurzel verrät nichts über die Blätter, auf die sie sich festlegt.

Das ist die Skalierungsschicht für CI/CD-Artefakte, Compliance-Logs, KI-Ausgaben, Datensatz-Manifeste, Release-Ordner und Beweisbündel. Sie bekommt ihre eigene Behandlung in ein Eintrag für Tausende von Dateien.

Was macht der supersedes-Zeiger?

supersedes ist ein optionaler 32-Byte-Zeiger auf einen früheren Label-309-Eintrag, über dessen Transaktions-Hash. Er lässt einen neueren Eintrag sagen: „Dieser ersetzt oder aktualisiert jenen früheren Eintrag.“

Der frühere Eintrag wird nicht gelöscht und nicht entwertet. Cardano ist nur-anfügend, also bleiben beide Einträge für immer eigenständig verifizierbar. Der Zeiger ist nur eine Verknüpfung; er trägt kein Begründungsfeld. Die menschliche Bedeutung der Ersetzung – eine Korrektur, ein überarbeitetes Manifest, ein aktualisiertes Beweispaket – gehört in den neuen Inhalt oder in die Anwendungsschicht, nicht in die Metadaten. Der Wert des Zeigers liegt darin, dass er ohne Anbieter-Datenbankzeile und ohne proprietäre Eintrags-ID funktioniert.

Wie funktioniert die Verifizierung?

Die Verifizierung ist geschichtet. Label 309 definiert drei Verifizierer-Rollen, jede eine strikte Erweiterung der vorigen:

Struktureller Validator – eine reine Funktion über die Eintrags-Bytes. Sie bestätigt kanonisches CBOR, die Schema-Form, Feldtypen, Pflichtfelder, Algorithmus-Kennungen und URI-Regeln. Sie führt keine Netzwerk-I/O durch, verifiziert keine Signaturen und entschlüsselt nichts.
Öffentlicher Verifizierer – startet von einer Cardano-Transaktionsreferenz. Er ruft die rohe Transaktion von einem Explorer ab, den der Verifizierer selbst wählt, bindet diese Bytes an den angefragten Transaktions-Hash, bestätigt, dass Label 309 vorhanden ist, setzt den Eintrag wieder zusammen, führt die strukturelle Validierung aus, prüft die Bestätigungstiefe und verifiziert die Signaturen, die er unterstützt. Sind Inhalts-Bytes verfügbar, kann er öffentliche Content-Hashes neu berechnen. Er entschlüsselt nicht.
Empfänger-Verifizierer – alles, was der öffentliche Verifizierer tut, plus seinen eigenen privaten Schlüssel, um versiegelte Inhalte zu öffnen und Klartext-Hashes neu zu berechnen.

Eine Feinheit hält die Verifizierung ehrlich: Ein öffentlicher Verifizierer liest das rohe Transaktions-CBOR, nicht die JSON-Ansicht der Metadaten eines Explorers. Eine JSON-Projektion ist verlustbehaftet – sie verwirft die Reihenfolge der Map-Schlüssel und die Unterscheidung zwischen Bytes und Text –, sodass ein erneutes Codieren daraus jede Signatur eines konformen Eintrags zerstören würde. Und weil die Bestätigung auf Cardano probabilistisch ist, wird ein Eintrag, der nur ein oder zwei Blöcke tief liegt, als pending statt valid gemeldet, bis genug Bestätigungen hinter ihm liegen.

Diese Struktur hält das Vertrauensmodell sauber. Ein einfacher Verifizierer braucht kein CardanoWall-Konto; ein öffentlicher Nachweis prüft ohne Herausgeber-Server; ein versiegelter Nachweis entschlüsselt lokal, in den Händen des Schlüsselinhabers. Die Anleitung einen Label-309-Eintrag verifizieren zeigt den Pfad des öffentlichen Verifizierers von Anfang bis Ende.

Wo passt das Gateway hinein?

Das Gateway veröffentlicht Einträge. Es ist nicht die Wurzel des Vertrauens.

Ein Label-309-Gateway übernimmt die Teile, die wirklich schwer selbst zu betreiben sind: Es erstellt den Kostenvoranschlag, lädt Chiffretext in den Speicher hoch, baut die Cardano-Transaktion und reicht sie ein, wartet auf die Bestätigung, indexiert Einträge, verwaltet Guthaben und stellt eine API bereit. CardanoWall nutzt dieses Gateway-Modell, um das Veröffentlichen für normale Nutzer und Entwickler praktikabel zu machen.

Aber einem Nachweis wird nicht deshalb vertraut, weil ein Gateway sagt, er existiere. Ihm wird vertraut, weil der Eintrag on-chain ist, die Bytes validieren, die Signaturen stimmen und die Hashes sich neu berechnen lassen. Das ist die Grenze zwischen einem gehosteten Dienst und einem Nachweis-Standard: Der Dienst hilft dir beim Veröffentlichen; der Standard lässt jeden verifizieren – mit dem Gateway vollständig außerhalb des Vertrauenspfads.

Das minimale Gedankenmodell

Stell dir Label 309 als einen kleinen, geschichteten Eintrag vor:

items beweisen, dass exakte Inhalts-Bytes bis zu einer öffentlichen Zeit existiert haben.
sigs lassen Schlüssel optional für den Eintrag bürgen.
enc lässt verschlüsselten Inhalt privat, aber wiederherstellbar bleiben.
empfängerspezifische Schlüssel-Slots lassen bestimmte Schlüsselinhaber versiegelten Inhalt öffnen.
merkle lässt einen Eintrag für ein sehr großes Bündel einstehen.
Verifizierung läuft auf öffentlichen Daten und lokalen Schlüsseln – nie auf Anbietervertrauen.

Diese Schichtung ist der Grund, warum CardanoWall eine Web-App, eine API, eine CLI, eine Desktop-App oder ein selbst gehostetes Gateway sein kann – während das Nachweisformat gleich bleibt. Das Produkt kann sich ändern; der Nachweis bleibt verifizierbar.

Eine Sache lohnt es sich durchgehend ehrlich zu benennen: Ein Label-309-Nachweis zeigt, dass bestimmte Bytes bis zu einer öffentlichen Zeit existiert haben und dass sie sich seither nicht verändert haben. Er beweist nicht, wer den Inhalt verfasst hat, wem er gehört oder ob irgendetwas darin wahr ist. Wo diese Grenze verläuft, siehe was ein Nachweis nicht beweist.

Weiterführende Lektüre

Was ist ein Existenznachweis?
Einen Label-309-Eintrag verifizieren
Ein Eintrag für Tausende von Dateien
Was ein Nachweis nicht beweist
Der Label-309-Standard: label309.org
Die quelloffenen SDKs und die CLI: github.com/cardanowall
Die Cardano-CIP-Einreichung (in Prüfung): CIPs PR #1205