Betreibe dein eigenes Label-309-Gateway

Ja – du kannst dein eigenes Gateway betreiben. Ein Label-309-Gateway ist der Open-Source-Dienst, der Existenznachweis-Einträge bepreist, hochlädt, veröffentlicht, bestätigt und indexiert. Betreibe dein eigenes, und deine Organisation wird zum Betreiber: Du finanzierst die Cardano- und Storage-Wallets, verwaltest Konten und API-Schlüssel und veröffentlichst Standard-Einträge, ohne vom gehosteten Dienst von CardanoWall abhängig zu sein. Die Einträge, die du verankerst, sind identisch mit denen aller anderen, denn das Format bestimmt der Standard, nicht der Betreiber.

Self-Hosting ist nicht der bequeme Weg. Es ist der Weg zur Kontrolle. Dieser Beitrag erklärt, wann sich dieser Tausch lohnt, was das Gateway tatsächlich leistet und welche Verantwortung du übernimmst, wenn du es selbst betreibst.

Wann solltest du dein eigenes Gateway betreiben?

Betreibe dein eigenes Gateway, wenn dir betriebliche Kontrolle wichtiger ist als Bequemlichkeit.

Für die meisten Nutzer ist das gehostete CardanoWall-Gateway die richtige Antwort. Es ist einfacher im Einstieg, leichter zu finanzieren und nimmt dir die Infrastrukturarbeit vollständig ab. Wenn du nur gelegentlich veröffentlichst und keinen Grund hast, die Schlüssel selbst zu halten, hör hier auf – der gehostete Weg ist für dich gebaut.

Manche Teams brauchen jedoch ein anderes Modell:

strenge Vorgaben zu Anbietern und Datenresidenz;
regulierte oder geprüfte Abläufe;
Veröffentlichung in großem Volumen;
interne Compliance-Archive und Systeme für Rechtsnachweise;
Infrastruktur für KI-Provenienz und CI/CD-Nachweis-Pipelines;
Produkte, die auf Label 309 unter eigener Marke aufbauen;
direkte Kontrolle über Schlüssel, Konten, Finanzierung und Preisgestaltung.

Für diese Teams erlaubt Self-Hosting, dass die Organisation die gesamte Pipeline selbst besitzt, statt sie über einen Dritten zu leiten.

Was leistet das Gateway tatsächlich?

Das Gateway besitzt die gesamte Publish-Pipeline und den dahinterliegenden Geld-, Chain- und Storage-Zustand. Es ist ein einzelnes Rust-Binary plus PostgreSQL und übernimmt:

Erstellung von Kostenvoranschlägen und Preisgestaltung;
Upload von Inhalten oder Chiffretext in den Speicher;
Storage-Finanzierung und -Abrechnung;
Aufbau, Übermittlung und Bestätigungsverfolgung von Cardano-Transaktionen;
Reorg-Behandlung und automatische Rückerstattungen, wenn eine Veröffentlichung dauerhaft fehlschlägt;
den öffentlichen On-Chain-Index der Einträge;
Kontoguthaben und das Guthaben-Ledger;
API-Schlüssel, Konto-Tokens und die Betreiber-Steuerebene;
Webhooks und den Audit-Trail.

Das ist die Maschinerie hinter einem zuverlässigen Veröffentlichungsdienst. Der Client besitzt weiterhin die nutzerseitige Absicht und die privaten Schlüssel; das Gateway besitzt die Chain-, Storage-, Preis- und Konto-Infrastruktur. Diese Trennung ist bewusst gewählt – es ist dieselbe Grenze, ganz gleich ob CardanoWall das Gateway betreibt oder du.

Was brauchst du für Self-Hosting?

Mindestens den operativen Besitz von fünf Dingen.

Ein Gateway-Deployment. Das Binary, seine Konfiguration, eine Postgres-Datenbank, Netzwerkzugriff, Logs, Monitoring und einen Upgrade-Pfad. Das Binary wendet seine eigenen Schema-Migrationen beim Start an und führt jede Hintergrundschleife unter einem Supervisor aus, sodass eine fehlschlagende Schleife den Prozess stoppt, statt im Stillen den Dienst zu beeinträchtigen.

Cardano-Finanzierung. Das Gateway braucht eine finanzierte Wallet, um Transaktionsgebühren zu bezahlen. Du verwaltest die einzelnen Transaktionsausgänge nicht selbst – die Wallet pflegt einen kleinen Pool bereitstehender Ausgänge, damit jede Veröffentlichung eine exakte Gebühr zahlt statt einer Schätzung. Du hältst diese Wallet aufgefüllt; den Rest erledigt das Gateway.

Storage-Finanzierung. Wenn dein Gateway Datei- oder Chiffretext-Uploads annimmt, braucht es ein Speicher-Backend und die Mittel, um Bytes zu speichern. In der Produktion ist das Arweave über einen Turbo-Bundler, bezahlt über vorausbezahlte Storage-Credits, die du aus einer Arweave-Wallet auffüllst. Du kannst auch ein reines Hash-Deployment ganz ohne Speicher betreiben: Die Einträge tragen dann nur den Content-Hash (und etwaige extern gehostete URIs), und die Instanz speichert nichts.

Betreiber-Anmeldedaten. Die Steuerebene ist durch ein Betreiber-Root-Geheimnis geschützt, das genau einmal ausgegeben wird, wenn du die Instanz bereitstellst. Die tägliche Administration läuft über kurzlebige Betreiber-Tokens, die daraus erzeugt werden. Diese Geheimnisse dürfen niemals in einen Browser, ein Client-Bundle, eine mobile App oder ein CI-Log gelangen.

Eine Konto- und Abrechnungsrichtlinie. Selbst wenn du der einzige Nutzer bist, muss das Gateway dennoch entscheiden, wer veröffentlichen darf und wie Guthaben gutgeschrieben wird. Das Guthaben unterliegt der alleinigen Autorität des Gateways; du schreibst es über die Steuerebene aus dem Abrechnungssystem gut, das du betreibst.

Self-Hosting ist echte Infrastruktur. Behandle es so, und es ist verlässlich; behandle es leichtfertig, und es wird zur Belastung.

Verändert Self-Hosting den Standard?

Nein. Ein selbst gehostetes Gateway veröffentlicht dieselben Label-309-Einträge wie jeder andere Betreiber, und die Einträge bleiben Standard.

Ein Verifizierer braucht nur die Cardano-Transaktions-Metadaten, optional die Inhalts-Bytes und einen öffentlichen Cardano-Explorer. Er muss nicht wissen – und kann nicht erkennen –, ob ein Eintrag vom gehosteten CardanoWall-Gateway, vom Gateway deines Unternehmens oder vom Laptop eines Entwicklers stammt. Genau darum geht es bei der Trennung des offenen Standards vom gehosteten Produkt: Das dauerhafte Artefakt ist Label 309, und jedes Gateway ist eine nachgelagerte Implementierung davon.

Beseitigt Self-Hosting alle Kosten?

Nein. Es beseitigt die Marge des gehosteten Betreibers, aber die zugrunde liegenden Kosten bleiben deine.

Du zahlst weiterhin:

Cardano-Transaktionsgebühren und Storage-Kosten für hochgeladene Bytes;
Infrastruktur-, Datenbank- und Backup-Kosten;
Monitoring, Logging und Security-Operations;
Personalzeit, Treasury-Management und Ausfallwiederherstellung;
Upgrades und laufende Wartung.

Wenn dein Volumen gering ist, ist das gehostete Gateway in der Praxis oft günstiger, sobald du die menschlichen Kosten des Infrastrukturbetriebs mitrechnest. (Warum Veröffentlichen überhaupt Geld kostet, erfährst du unter warum Veröffentlichen einen Preis hat.) Wenn dein Volumen hoch ist oder Vorgaben verlangen, dass du die Schlüssel selbst hältst, beginnt Self-Hosting sich zu lohnen.

Wer sollte nicht selbst hosten?

Hoste nicht selbst, nur um nicht über den Preis nachdenken zu müssen.

Wenn du nur gelegentlich veröffentlichst, keine Betriebskapazität hast, keine finanzierten Wallets verwalten willst und keine eigene Richtlinienkontrolle brauchst, ist das gehostete Gateway mit ziemlicher Sicherheit die bessere Wahl. Self-Hosting macht dich verantwortlich für Verfügbarkeit, Sicherheit, Finanzierung, Monitoring und Upgrades – und das ist nur dann ein Vorteil, wenn du diese Verantwortung tatsächlich willst.

Für die meisten Einzelnen und viele kleine Teams ist das gehostete CardanoWall der praktische Weg.

Wer passt gut zu Self-Hosting?

Teams, die bereits ernsthafte Infrastruktur betreiben und einen konkreten Grund haben, die Pipeline selbst zu halten. Gute Kandidaten sind:

Unternehmen, die Nachweise in großem Volumen veröffentlichen;
Compliance-Teams, die täglich oder stündlich Nachweise verankern, idealerweise unter einem einzigen Eintrag gebündelt;
KI-Teams, die Manifeste von Datensätzen und Ausgaben festschreiben;
DevSecOps-Teams, die Nachweise in Release-Pipelines einbinden;
Rechtsplattformen, die mit sensiblen Beweismitteln umgehen;
Produkte, die Label 309 unter eigener Marke wollen;
Organisationen, die sensible Abläufe nicht über einen gehosteten Drittanbieter-Dienst leiten dürfen.

In diesen Fällen wird der Gateway-Betrieb Teil der bestehenden Sicherheits- und Infrastrukturaufstellung der Organisation, statt etwas Neues, auf das man aufpassen muss.

Wie baut ein Produkt auf einem Gateway auf?

Ein Produkt kann das Gateway als seine Basisschicht behandeln. Das Gateway übernimmt Chain, Storage, Preisgestaltung, Guthaben, Einträge und Publish-Status; dein Produkt übernimmt Nutzer, Sitzungen, die Abrechnungsdarstellung, Benachrichtigungen, Workflow, UI und domänenspezifische Bedeutung.

Zum Beispiel:

ein Compliance-Produkt veröffentlicht tägliche Kontroll-Snapshots;
ein Medienprodukt verankert Content-Credentials-(C2PA-)Manifest-Hashes;
ein Rechtsprodukt versiegelt Beweismittel für bestimmte Empfänger;
ein Entwicklerwerkzeug veröffentlicht Release-Nachweise;
ein KI-Produkt versieht Stapel generierter Ausgaben mit einem Zeitstempel.

Das Produkt baut Cardano-Übermittlung oder Storage-Abrechnung nie neu – es ruft das Gateway auf. Genau so ist CardanoWall gebaut: Die Web-App und der Worker sind ein Wrapper um dieselben öffentlichen Gateway-Ebenen, die auch ein Dritter nutzt, ohne private Hintertür. Wenn du die Integrationsmuster im Detail willst, sieh dir auf einem Label-309-Gateway aufbauen an.

Wie verbinden sich Clients mit einem Gateway?

Über die HTTP-API des Gateways, aufgeteilt in zwei Ebenen.

Eine Web-App, Desktop-App, ein CLI, eine SDK-Integration oder ein Backend-Dienst nutzt Konto-Tokens oder API-Schlüssel, um die Datenebene aufzurufen: bepreisen, hochladen, veröffentlichen, Guthaben lesen, Einträge lesen. Betreiber-Aktionen – Konten anlegen, Guthaben gutschreiben, Margen setzen, Anmeldedaten erzeugen – laufen über die Steuerebene, und immer nur aus einem vertrauenswürdigen Backend.

Die übliche Trennung:

Clients handeln mit eng gefassten, kurzlebigen Konto-Anmeldedaten;
dein Backend hält die Betreiber-Anmeldedaten und gibt sie nie preis;
private Identitätsschlüssel bleiben auf den Geräten der Nutzer oder unter deiner eigenen Schlüsselrichtlinie;
das Gateway entschlüsselt niemals versiegelte Inhalte.

Ein praktisches Muster ist der Token-erzeugende Proxy: Der Client authentifiziert sich gegen dein eigenes Sitzungssystem, dein Backend tauscht diese Sitzung gegen ein kurzlebiges Konto-Token, das genau auf das beschränkt ist, was die Seite braucht, und der Client sieht nur dieses Token. Ein durchgesickertes Token ist dann ein Problem für eine Stunde und kein Vorfall. Die Lesefläche für Einträge ist noch einfacher – sie bedient anonyme Aufrufer, sodass öffentliche Verifizierungs-Seiten und Explorer überhaupt keine Anmeldedaten brauchen.

Was sollten Betreiber schützen?

Mehrere Dinge, ungefähr in dieser Reihenfolge nach Schweregrad.

Schlüssel und Anmeldedaten. Das Gateway signiert mit einem einzigen verschlüsselten Keyring – Cardano-, Storage- und Webhook-Schlüssel in einer Datei unter einer Passphrase. Erstelle ihn offline, halte ein Offline-Backup sowohl der Datei als auch der Passphrase, und behüte das Betreiber-Root-Geheimnis wie ein Produktions-Datenbankpasswort. Es gibt keinen Schlüssel-Export- oder Sweep-Pfad: Verlierst du den Keyring, strandest du sämtliche Mittel, die auf seinen Adressen liegen.

Mittel und Befugnis. Steuere, wer Konten anlegen, API-Schlüssel ausstellen, Guthaben anpassen und Margen ändern darf. Jede Aktion auf der Steuerebene wird im Audit protokolliert, und Guthaben-Anpassungen sind pro Aufruf gedeckelt – als Begrenzung des Schadensradius –, sodass ein Vertipper oder ein kompromittiertes Token nur so viel auf einmal bewegen kann.

Betrieb. Halte Logs und einen Audit-Trail, einen Backup-und-Restore-Plan sowie Monitoring für niedrigen Wallet-Stand, leerlaufenden Speicher, hängende Uploads, fehlgeschlagene Veröffentlichungen und einen veralteten Chain-Tip bereit. Das Binary protokolliert strukturiertes JSON für einen Log-Aggregator und stellt eine Health-Probe bereit.

Least Privilege. Ein Browser darf niemals Betreiber-Anmeldedaten erhalten. Ein CI-Job darf niemals mehr Macht erhalten, als er braucht. Fasse Konto-Tokens eng und halte sie kurzlebig.

Wie funktioniert die Verifizierung gegen ein selbst gehostetes Gateway?

Genau wie gegen jedes Gateway: Die Verifizierung vertraut dem Gateway überhaupt nicht.

Ein Verifizierer prüft die Cardano-Transaktion, die Label-309-Metadaten, die Hashes, die optionalen Signaturen, etwaige Merkle-Nachweise und versiegelte Nutzlasten nach den Standardregeln – kein Herausgeber-Server in der Schleife. Das Gateway hilft dir beim Veröffentlichen und Indexieren; es kann einen ungültigen Nachweis nicht gültig machen.

Das zählt am meisten für interne Systeme. Ein Unternehmen, das sein eigenes Gateway betreibt, sollte seine eigenen Einträge dennoch unabhängig verifizieren. „Unser Gateway hat gesagt, es habe veröffentlicht“ ist nicht der Nachweis. Der On-Chain-Eintrag und eine unabhängige Prüfung sind der Nachweis. Diese Prüfung kannst du mit dem quelloffenen Kommandozeilenwerkzeug cardanowall ausführen oder einen Eintrag von Hand verifizieren – keines davon braucht dein laufendes Gateway.

Wie hängt das mit CardanoWall zusammen?

CardanoWall ist das gehostete, ausgefeilte Produkt und der Referenzbetreiber für den Standard. Self-Hosting ist der Weg zur Unabhängigkeit. Die beiden stehen nicht im Widerspruch.

Ein Nutzer kann auf CardanoWall starten, später zu einem selbst gehosteten Gateway wechseln oder beide für verschiedene Abläufe nutzen. Ein Entwickler kann ein Produkt auf dem Gateway-Modell bauen. Ein Unternehmen kann das gehostete CardanoWall für einfache Teams behalten und gleichzeitig sein eigenes Gateway für regulierte Automatisierung betreiben. Die gemeinsame Schicht darunter ist Label 309 – offen, anbieterneutral und on-chain dieselbe, ganz gleich wer veröffentlicht.

Die Kurzfassung

Betreibe dein eigenes Gateway, wenn du den Veröffentlichungsdienst selbst betreiben willst. Du gewinnst Kontrolle über Finanzierung, Konten, Margen, API-Schlüssel, Infrastruktur und Richtlinien – und übernimmst die Verantwortung für Verfügbarkeit, Sicherheit, Wallets, Speicher, Monitoring und Upgrades.

Gehostetes CardanoWall ist Bequemlichkeit. Self-Hosting ist Kontrolle. Die Nachweis-Einträge bleiben so oder so Standard.

Weiterführende Lektüre

Der offene Standard: label309.org.
Das Gateway, die SDKs und das CLI, alle Open Source (Apache-2.0): github.com/cardanowall.
Der Metadaten-Standard ist beim Cardano-CIP-Prozess eingereicht und in Prüfung: der Vorschlag als Pull Request.
Was ist ein Label-309-Gateway?
Label 309 ist Open Source