Ein Eintrag für tausende Dateien: Merkle-Bündelung

Ein einziger Label-309-Eintrag kann beweisen, dass tausende oder Millionen Dateien zu einem bestimmten Zeitpunkt existiert haben.

Statt eine Blockchain-Transaktion pro Datei zu veröffentlichen, hasht du jede Datei, faltest diese Hashes zu einem Merkle-Baum und veröffentlichst eine einzige 32 Byte große Merkle-Wurzel. Später kannst du mit einem kleinen Inklusionsnachweis belegen, dass eine bestimmte Datei zu diesem Bündel gehörte – ohne den Rest preiszugeben und ohne jedes Element on chain zu bringen.

So skaliert ein Existenznachweis von einem einzelnen Dokument auf eine beliebig große Menge.

Welches Problem löst die Merkle-Bündelung?

Blockchains sind schlechte Orte, um lange Listen zu speichern. Jedes Byte kostet eine Gebühr, und eine Cardano-Transaktion hat eine harte Größenobergrenze.

Wenn ein System einen stetigen Strom an Artefakten erzeugt – Logs, Modellausgaben, Release-Builds, Rechnungen, Berichte, Beweiseinträge –, dann wird es schnell teuer und unübersichtlich, jeden Hash als eigenen on-chain Eintrag zu veröffentlichen.

Die Merkle-Bündelung komprimiert eine geordnete Liste von Hashes zu einem einzigen Wurzel-Commitment. Die Wurzel hat eine feste Größe (32 Byte), das Bündel kann unbegrenzt groß sein, und der Nachweis für ein einzelnes Element bleibt klein – er wächst nur mit dem Logarithmus der Bündelgröße. Damit werden regelmäßige Commitments für Workflows mit hohem Volumen praktikabel.

Was ist eine Merkle-Wurzel?

Eine Merkle-Wurzel ist ein einzelner Hash, der sich auf eine ganze geordnete Liste festlegt.

Beginne mit einer Liste von Blättern. In einem Workflow für Existenznachweise ist jedes Blatt typischerweise der Hash einer Datei, eines Ereignisses oder eines Manifesteintrags. Die Blätter werden paarweise in einem Binärbaum kombiniert, und der Hash an der Spitze ist die Merkle-Wurzel.

Das Commitment ist in dreierlei Hinsicht exakt:

• Ändert sich ein Blatt, ändert sich die Wurzel.
• Ändert sich die Reihenfolge der Blätter, ändert sich die Wurzel.
• Das Commitment hält außerdem fest, wie viele Blätter es gibt, sodass eine Liste anderer Größe nicht als dasselbe Bündel durchgehen kann.

Die Wurzel zu veröffentlichen ist, als würdest du einen Fingerabdruck für die gesamte geordnete Liste veröffentlichen.

Was kommt tatsächlich auf die Blockchain?

Nur die Wurzel. Die vollständige Liste der Blätter bleibt off-chain.

Ein Label-309-Eintrag trägt das Commitment in einem eigenen merkle-Feld, getrennt von gewöhnlichen Hashes pro Datei. Jedes Commitment ist eine kleine, feste Struktur:

• der Commitment-Algorithmus (Label 309 v1 registriert rfc9162-sha256: den RFC 9162 Merkle Tree Hash mit SHA-256);
• die 32 Byte große Wurzel;
• der leaf_count, der die Wurzel an die Größe der Off-Chain-Liste bindet;
• optionale inhaltsadressierte uris (ar:// oder ipfs://), die auf die Datei mit der Blattliste verweisen.

Der on-chain Eintrag bleibt winzig – eine einzelne Wurzel legt sich auf eine unbegrenzte Liste zu festen Kosten von 32 Byte fest. Die Details liegen off-chain, in der geordneten Blattliste. (Wo der Rest eines Eintrags lebt, erfährst du unter was auf die Blockchain kommt.)

Wie beweist du später eine einzelne Datei?

Du erstellst einen Inklusionsnachweis.

Ein Inklusionsnachweis ist die kurze Liste der Geschwister-Hashes entlang des Pfads von einem Blatt bis zur Wurzel. Ein Verifizierer faltet das Blatt und diese Geschwister im Baum wieder nach oben und akzeptiert den Nachweis nur dann, wenn die neu berechnete Wurzel exakt der veröffentlichten Wurzel entspricht.

In der Praxis hat die Prüfung vier Eingaben:

1. den Hash der Datei oder des Elements, das du beweisen willst;
2. den Inklusionsnachweis (den Geschwisterpfad);
3. die Merkle-Wurzel im Label-309-Eintrag;
4. die Cardano-Blockzeit der Transaktion, die ihn getragen hat.

Wenn die Faltung die veröffentlichte Wurzel reproduziert, war das Element in der festgeschriebenen Liste enthalten – und die Blockzeit bezeugt, wann diese Liste existiert hat. Der Verifizierer braucht das eine Element und seinen Nachweis; er braucht nie die anderen Dateien des Bündels.

Zwei Details solltest du auseinanderhalten. Die Konstruktion ist reihenfolgeabhängig, also müssen die Blätter in genau der Reihenfolge bleiben, in der sie veröffentlicht wurden. Und ein „Baum“ mit einem einzigen Blatt ist kein brauchbarer Zeitstempel: Die Wurzel eines Ein-Blatt-Baums ist nicht das Blatt selbst, also veröffentlichst du, um eine einzelne Datei zu beweisen, einen schlichten Content-Hash und kein Merkle-Commitment für ein einzelnes Element.

Warum ist es eine Stärke, dass Erstellung und Verifizierung vollständig offline funktionieren?

Weil der einzige Schritt, der einen Server berührt, das Veröffentlichen der Wurzel ist.

Den Baum zu bauen, Inklusionsnachweise abzuleiten und sie zu verifizieren ist reine Berechnung. Wer über die geordnete Blattliste verfügt, kann die Wurzel neu berechnen und jeden Nachweis erneut ableiten – kein Konto, kein Gateway, kein Netzwerk und keine Mitwirkung dessen, der ursprünglich veröffentlicht hat. Der Veröffentlichende ist zum Zeitpunkt der Verifizierung nie beteiligt.

Das ist wichtig für Beweise, die Werkzeuge und Anbieter überdauern müssen. Ein Nachweis, den du offline gegen einen öffentlichen Cardano-Explorer prüfen kannst, funktioniert noch lange, nachdem ein bestimmter Dienst längst verschwunden ist. Du kannst ein Bündel-Commitment genauso verifizieren, wie du jeden Label-309-Eintrag verifizierst, und du kannst die Inklusionsprüfung mit dem quelloffenen cardanowall-Kommandozeilenwerkzeug direkt in CI verdrahten (merkle-build, um einen Ordner zu einer Wurzel zu falten, merkle-verify, um zu bestätigen, dass ein Element dazugehört).

Warum ist das für Workflows mit hohem Volumen nützlich?

Weil viele reale Nachweise bündelförmig sind, nicht einzeldateiförmig. Ein Team muss vielleicht zeigen:

• was eine CI/CD-Pipeline gebaut hat und welche Artefakte in einem Release ausgeliefert wurden;
• welche Software Bill of Materials (SBOM) existierte, bevor eine Schwachstelle offengelegt wurde;
• welche KI-Ausgaben an einem bestimmten Tag erzeugt wurden;
• welcher Datensatz-Snapshot vor einem Trainingslauf existierte;
• welche Compliance-Logs vor einem Audit existierten;
• welche juristischen Beweisdateien vor einer Sicherungsanordnung aufbewahrt wurden;
• welche Reserven eine Bilanz zu einem bestimmten Zeitpunkt festgeschrieben hat.

Keines davon passt gut in ein Modell aus einer Datei pro Transaktion. Die Merkle-Bündelung lässt dich ein einziges Commitment pro Bündel veröffentlichen – ohne jedes private Element offenzulegen und ohne on-chain Metadaten, die linear mit der Bündelgröße wachsen.

Kann die Blattliste privat bleiben?

Ja. Die veröffentlichte Wurzel verrät nichts über die Blätter, auf die sie sich festlegt.

Du kannst die Blattliste in deinem eigenen Beweissystem, Release-Archiv, Datenraum oder Compliance-Speicher behalten und später nur das offenlegen, was du brauchst:

• eine Datei und ihren Inklusionsnachweis;
• eine Datensatzzeile, ein Dokument oder ein Release-Artefakt;
• einen Audit-Log-Eintrag;
• eine Teilmenge der Liste;
• oder die gesamte Blattliste.

Das ist das Muster, wenn du ein öffentliches Commitment mit Zeitstempel willst, ohne die zugrunde liegenden Daten öffentlich zu machen – eng verwandt mit vertraulicher Offenlegung ohne öffentliche Dateien und Proof of Reserves mit Merkle-Wurzeln.

Der Preis dafür ist Verantwortung. Eine Wurzel beweist, dass irgendeine Liste bekannter Größe zu einer bekannten Zeit existiert hat; sie erlaubt es für sich allein niemandem zu beweisen, welche konkreten Elemente darin enthalten waren. Wenn du die Blattliste privat hältst, musst du sie bewahren. Verlierst du sowohl die Blattliste als auch alle gespeicherten Inklusionsnachweise, behältst du den Zeitstempel, verlierst aber die Möglichkeit zu beweisen, dass ein bestimmtes Element festgeschrieben war.

Was sollte ein Blatt sein?

Ein Blatt sollte genau das darstellen, was du später möglicherweise beweisen musst.

Bei Dateien ist das Blatt der Hash der Datei-Bytes. Bei strukturierten Daten ist es üblicherweise der Hash eines kanonischen Manifesteintrags. Bei CI/CD könnte ein Blatt ein Artefakt-Digest, ein SBOM-Digest, ein Build-Log-Digest, eine Commit-Referenz oder ein signierter Release-Manifest-Eintrag sein. Bei KI-Provenienz könnte ein Blatt ein Ausgabedatei-Hash, ein Prompt-/Ausgabe-Manifesteintrag, ein Datensatz-Element-Commitment oder ein Hash eines Content-Provenienz-Manifests sein.

Worauf es ankommt, ist Konsistenz. Werden Blätter über verschiedene Läufe hinweg auf unterschiedliche Arten erzeugt, lässt sich späteren Inklusionsnachweisen nur noch schwer vertrauen. Lege die Blattdefinition und die Kanonisierung einmal fest und wende sie jedes Mal gleich an.

Solltest du die Blattliste veröffentlichen oder privat halten?

Das hängt davon ab, was du beweist und wer es sehen soll.

Die Blattliste zu veröffentlichen macht die Verifizierung durch Dritte trivial: Jeder kann die Liste abrufen, die Wurzel neu berechnen und die festgeschriebene Menge prüfen. Sie privat zu halten gibt dir Vertraulichkeit und selektive Offenlegung – du legst Inklusionsnachweise nur dann offen, wenn es nötig ist. Viele Workflows machen beides: eine öffentliche Blattliste für quelloffene Releases, eine private für interne Compliance-Logs, eine versiegelte für sensible Beweise.

Die Wurzel ist das öffentliche Commitment. Die Richtlinie für die Blattliste ist eine separate Entscheidung, die darauf aufsetzt.

Wie oft solltest du Wurzeln veröffentlichen?

Passe die Taktung an den Workflow an.

Ein CI/CD-System veröffentlicht vielleicht eine Wurzel pro Release, Build oder Deployment-Fenster. Ein Compliance-System veröffentlicht vielleicht eine Wurzel pro Stunde, pro Tag oder pro Kontrollperiode. Eine KI-Plattform veröffentlicht Wurzeln vielleicht pro Bündel generierter Inhalte, pro Trainings-Snapshot oder pro Modellversions-Ereignis. Ein System für juristische Beweise veröffentlicht vielleicht eine Wurzel pro Fallakte, Aufnahmefenster oder Chain-of-Custody-Meilenstein.

Die richtige Taktung balanciert Kosten, betriebliche Einfachheit und die Genauigkeit der Zeitlinie, die du später möglicherweise beweisen musst.

Was beweist eine Merkle-Wurzel nicht?

Eine Merkle-Wurzel beweist das Festschreiben einer Liste zu einem bestimmten Zeitpunkt. Sie beweist nicht die geschäftlichen Behauptungen, die diese Liste umgeben. Wie jeder Existenznachweis zeigt sie, dass bestimmte Bytes bis zu einer öffentlichen Zeit existiert haben – nicht, dass sie wahr, rechtmäßig, von einer bestimmten Person verfasst oder Eigentum von irgendjemandem sind (siehe was ein Nachweis nicht beweist).

Konkret:

• Sie beweist nicht, dass ein Software-Build sicher war. Sie kann beweisen, welche Artefakte oder Manifeste in einem Release enthalten waren.
• Sie beweist nicht, dass ein Datensatz rechtmäßig erhoben wurde. Sie kann beweisen, dass ein Datensatz-Commitment vor einer bestimmten Zeit existiert hat.
• Sie beweist nicht, dass ein Log-Eintrag wahr ist. Sie kann beweisen, dass der Eintrag Teil eines festgeschriebenen Bündels war.
• Sie beweist keine Urheberschaft – es sei denn, der Eintrag oder der umgebende Prozess fügt Signaturen und Identitätskontrollen hinzu.

In Label 309 ist Urheberschaft optional und explizit: Ein Eintrag kann losgelöste Signaturen tragen, aber sie sind nie erforderlich, und ein Merkle-Commitment für sich allein macht keine Aussage darüber, wer die Liste erzeugt hat. Die Wurzel liefert das Commitment mit Zeitstempel; der Prozess darum herum liefert die geschäftliche Bedeutung.

Wie passt Label 309 hier hinein?

Label 309 ist der offene, anbieterneutrale Standard für Existenznachweise auf Cardano; er wurde in den Cardano-CIP-Prozess eingereicht und wird von den CIP-Editoren als Vorschlag der Kategorie Metadata geprüft. Die Merkle-Bündelung ist kein separates Produkt – sie ist die Skalierungsschicht, die in den Standard eingebaut ist.

Ein Bündel-Commitment nutzt denselben Eintrag und denselben Verifizierungspfad wie ein Nachweis für eine einzelne Datei. Ein Eintrag unter dem Metadaten-Label 309 kann eine Merkle-Wurzel tragen, und daneben dieselben optionalen Bestandteile, die jeder Eintrag unterstützt: gewöhnliche Hashes pro Datei, inhaltsadressierte Speicher-uris, einen supersedes-Zeiger auf einen früheren Eintrag und Urheberschafts-Signaturen. So erbt ein Bündel-Nachweis alles, was ein einzelner Nachweis hat:

• einen Cardano-Blockzeit-Zeugen;
• eine standardisierte, geschlossene Eintragsstruktur;
• eigenständige, offline Verifizierung gegen einen öffentlichen Explorer;
• dieselben quelloffenen Werkzeuge, Bibliotheken und das CLI über alle Sprachen hinweg.

Hash jedes Element, baue einen geordneten Merkle-Baum, veröffentliche eine Wurzel in einem Label-309-Eintrag und bewahre die Blattliste sowie alle Nachweise auf, die du brauchen könntest. Beweise später, dass ein einzelnes Element Teil des festgeschriebenen Bündels war – ohne jedes Element on chain zu bringen. Genau das macht Existenznachweise praktikabel für CI/CD, KI-Provenienz, Datensätze, Compliance, juristische Beweise und andere Workflows mit hohem Volumen.

Weiterführende Lektüre

• Wie Label 309 funktioniert – die Eintragsstruktur, in die sich ein Bündel-Commitment einklinkt.
• Trainingsdaten beweisen, ohne sie preiszugeben – selektive Offenlegung aus einer privaten Blattliste, von Anfang bis Ende.
• Wie Label 309 sich mit OpenTimestamps vergleicht – ein weiteres Protokoll, das viele Hashes in einem Anker zusammenfasst.
• Der Standard, die quelloffenen SDKs und das CLI sowie der Text der Spezifikation: label309.org und github.com/cardanowall.
• RFC 9162 – die Merkle-Tree-Hash-Konstruktion, die Label 309 für Bündel-Commitments verwendet.