Cardano Reference Inputs erklärt: CIP-31, UTxO, Smart Contracts und Risiken

vor 2 Tagen

8 Min. Lesezeit

Cardano Reference Inputs sind eine technische Grundlage für effizientere Smart Contracts. Mit CIP-31 kann eine Transaktion Daten aus einem bestehenden UTxO lesen, ohne diesen Output auszugeben. Das klingt nach einer kleinen Änderung, löst aber ein fundamentales Problem zustandsbasierter Anwendungen: Informationen können gemeinsam genutzt werden, während der Vermögenswert am referenzierten Output unverändert bleibt. Dieser Leitfaden erklärt die Mechanik, ihre Grenzen und die praktischen Risiken für Nutzer, Entwickler und Anleger.

Was sind Reference Inputs auf Cardano?

Cardano verwendet ein Extended-Unspent-Transaction-Output-Modell, kurz EUTxO. Ein UTxO ist ein noch nicht ausgegebener Transaktionsoutput mit einer Adresse, einem Wert und gegebenenfalls weiteren Daten. Gewöhnliche Inputs konsumieren UTxOs. Eine erfolgreiche Transaktion entfernt sie aus der Menge ungenutzter Outputs und erzeugt neue Outputs. Reference Inputs funktionieren anders: Sie zeigen auf einen vorhandenen Output und machen dessen Informationen für die Validierung sichtbar, ohne ihn zu konsumieren.

Die offizielle Cardano Improvement Proposal CIP-31 unterscheidet ausdrücklich zwischen Spending Inputs und Reference Inputs. Ein referenzierter Output muss noch existieren und unspent sein. Sein Wert darf nicht zur Finanzierung der Transaktion herangezogen werden. Die Spending-Bedingungen des referenzierten Outputs werden nicht geprüft; weder die zugehörige Signatur noch ein Spending-Redeemer wird allein durch das Referenzieren verlangt. Genau diese Trennung zwischen Lesen und Ausgeben ist entscheidend.

Ein einfaches Beispiel mit drei Beteiligten

Stell Dir einen Preisfeed vor, dessen UTxO einen aktuellen Referenzkurs enthält. Eine DeFi-Anwendung möchte diesen Kurs bei zwei unabhängigen Vorgängen lesen. Ohne geeigneten Lesemechanismus müsste die Anwendung den Daten-UTxO konsumieren und einen neuen Output mit denselben Informationen erzeugen. Der zweite Vorgang könnte nicht denselben bereits konsumierten Output verwenden. Mit CIP-31 referenzieren beide Transaktionen denselben noch vorhandenen UTxO. Der Preisfeed bleibt dabei bestehen. Das bedeutet nicht, dass der Kurs richtig oder aktuell ist; es beseitigt lediglich den Konsumkonflikt.

Warum war CIP-31 notwendig?

Im UTxO-Modell sind Outputs zunächst Ressourcen: Eine Ausgabe verbraucht sie. Für Geldbeträge ist das sinnvoll, denn derselbe Betrag darf nicht zweimal ausgegeben werden. Informationen verhalten sich aber anders. Mehrere Nutzer können denselben Kurs, dieselbe Konfiguration oder dieselbe Metadatenversion gleichzeitig lesen. Wenn jede Leseoperation die Datenressource verbraucht, entsteht unnötige Konkurrenz. Das CIP-Dokument beschreibt diesen Unterschied zwischen ressourcenartigen Outputs und wiederverwendbaren Informationen als zentrale Motivation.

Vor der Einführung von Reference Inputs mussten Anwendungen häufig umständliche Zustandsübergänge modellieren, obwohl sie nur einen bestehenden Datensatz prüfen wollten. Das erhöhte den Aufwand für Transaktionsaufbau, Koordination und nachfolgende Nutzer. CIP-31 macht Informationen aus Outputs lesbar, ohne ihre Lebensdauer an eine einzelne Leseoperation zu binden. Es ist aber keine globale Datenbank und auch kein Ersatz für die sorgfältige Modellierung von Zustandsänderungen.

Technischer Ablauf einer Transaktion mit Reference Input

1. Einen gültigen UTxO identifizieren

Die Anwendung ermittelt zunächst den Transaktionshash und Output-Index des UTxO, der die benötigte Information trägt. Diese Kombination identifiziert einen bestimmten Output. Ein Wallet oder Indexer kann bei der Suche helfen. Die Anwendung muss kontrollieren, dass der Output zum Zeitpunkt der Transaktionsvalidierung noch zur UTxO-Menge gehört. Ein bereits ausgegebener Output kann nicht mehr als Reference Input verwendet werden.

2. Spending Inputs und Reference Inputs getrennt angeben

Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten.

Relai Bitcoin kaufen – Code AUSWANDERNSCHWEIZ, Werbung

Bitcoin mit Relai kaufen – Code AUSWANDERNSCHWEIZ nutzen

Die Transaktion benötigt weiterhin normale Inputs, beispielsweise um Gebühren zu finanzieren und einen tatsächlichen Zustandsübergang auszuführen. Daneben enthält ihr Body die Menge der Reference Inputs. CIP-31 ergänzt dafür ein eigenes Feld mit dem CDDL-Schlüssel 16. Diese getrennte Struktur ist nicht nur Kosmetik: Ein Spending Input ändert die UTxO-Menge, während ein Reference Input den referenzierten Output bestehen lässt.

3. Daten im Script Context auswerten

Bei der Validierung können kompatible Plutus-Skripte die referenzierten Outputs im Script Context untersuchen. Die Anwendung muss selbst festlegen, welche Referenzen zulässig sind. Beispielsweise kann sie prüfen, ob der referenzierte Output an einer erwarteten Script-Adresse liegt, eine bestimmte NFT-Kennung trägt und ein Datum in einem erlaubten Format enthält. Ein Reference Input ist keine automatische Vertrauensgarantie. Ohne solche Prüfungen könnte eine Anwendung beliebige oder manipulierte Daten akzeptieren.

4. Validieren, Gebühren bezahlen und Outputs erzeugen

Die Transaktion wird anhand der normalen Ledger- und Script-Regeln validiert. Bei Erfolg werden die gewöhnlichen Spending Inputs verbraucht und die neuen Outputs angelegt. Die Reference Inputs bleiben unverändert. Für den Vorgang können Netzwerkgebühren und gegebenenfalls Kosten der Script-Ausführung anfallen. CIP-31 verspricht keine gebührenfreien Transaktionen und keinen bestimmten prozentualen Preisvorteil.

CIP-31, CIP-32 und CIP-33: drei unterschiedliche Funktionen

Die drei häufig gemeinsam genannten Verbesserungen erfüllen unterschiedliche Aufgaben. CIP-31 definiert das Lesen eines Outputs ohne Konsum. CIP-32 erlaubt es, ein Datum direkt in einem Output abzulegen, statt dort nur dessen Hash zu speichern. CIP-33 ermöglicht die Ablage eines Referenzskripts in einem Output, sodass andere Transaktionen es über eine Referenz verwenden können. Sie ergänzen sich, sind aber keine austauschbaren Bezeichnungen.

Ein typischer Ablauf kombiniert die Konzepte: Ein Konfigurations-UTxO enthält ein Inline Datum nach CIP-32. Eine neue Transaktion verwendet ihn als Reference Input nach CIP-31. Ein Validator prüft die Konfiguration und kann zusätzlich ein in einem anderen UTxO hinterlegtes Reference Script nach CIP-33 nutzen. Ob sich diese Kombination lohnt, hängt von Anwendung, Datenformat, Script-Grösse und Gebührenparametern ab.

Praxisfall: Preis-Orakel in einer DeFi-Anwendung

Ein Lending-Protokoll benötigt für die Bewertung hinterlegter Sicherheiten einen Preis. Es kann einen Oracle-UTxO mit einer veröffentlichten Preisangabe referenzieren. Mehrere Nutzertransaktionen können dieselbe Version lesen, ohne sie bei jeder Abfrage neu anzulegen. Allerdings muss das Protokoll kontrollieren, wer die Daten veröffentlicht hat, für welchen Markt sie gelten und wie alt sie sein dürfen. Ein Referenzmechanismus löst weder Oracle-Manipulation noch Liquidationsrisiken.

Angenommen, ein Oracle-Datum meldet einen Kurs von 2 CHF pro Token und ein Nutzer hinterlegt 500 Token. Der rechnerische Sicherheitenwert beträgt 1'000 CHF. Bei einer beispielhaften maximalen Beleihungsquote von 60 Prozent wäre ein Kredit von höchstens 600 CHF denkbar. Diese Werte sind frei gewählte Rechenannahmen, keine aktuellen Cardano-Kurse und keine realen Protokollparameter. Wenn der echte Marktpreis später auf 1 CHF sinkt, halbiert sich der Sicherheitenwert auf 500 CHF. Die technische Fähigkeit, das Oracle-Datum zu lesen, verhindert keine Unterdeckung.

Konkurrenz, Aktualisierung und Datenverfügbarkeit

Mehrere Transaktionen dürfen denselben noch vorhandenen Output referenzieren. Das vermindert die Konkurrenz um gemeinsam gelesene Informationen. Sobald ein berechtigter Akteur den referenzierten Output tatsächlich ausgibt, ist diese konkrete Referenz aber nicht mehr gültig. Eine bereits vorbereitete Transaktion kann dadurch scheitern und muss gegebenenfalls neu aufgebaut werden. Anwendungen sollten deshalb nicht davon ausgehen, dass ein Referenz-UTxO unbegrenzt unverändert verfügbar bleibt.

Für häufig aktualisierte Oracles ist die Versionierung wichtig. Eine neue Veröffentlichung kann den alten Daten-UTxO konsumieren und einen neuen erzeugen. Nutzer müssen dann die richtige neue Referenz ermitteln. Ein stabiler Identifier, eine klar definierte Autorisierung und ein Verfahren für abgelaufene Daten helfen, Fehlentscheidungen zu vermeiden. Gerade bei finanziellen Smart Contracts sollte die Aktualität nicht nur in einer Benutzeroberfläche, sondern soweit erforderlich auch in der on-chain-Validierung überprüft werden.

Welche Vorteile sind realistisch?

Der grösste Vorteil ist die Entkopplung von Lesen und Ausgeben. Mehrere Anwendungen können dieselben Daten verwenden, ohne durch jede Leseoperation eine neue UTxO-Version erzwingen zu müssen. Das erleichtert bestimmte Oracle-, Konfigurations-, Registry- und Metadatenmodelle. Entwickler erhalten mehr Möglichkeiten, unveränderliche oder selten veränderte Informationen auf der Blockchain bereitzustellen. Nutzer können von robusterem Transaktionsaufbau profitieren, sofern die Anwendung den Mechanismus korrekt implementiert.

Die Grenzen sind ebenso wichtig. Reference Inputs beschleunigen nicht automatisch jede Transaktion, garantieren keinen höheren Durchsatz des gesamten Netzwerks und beseitigen keine Script-Ausführungsgrenzen. Es können zusätzliche Bytes, Prüfungen und Abhängigkeiten entstehen. Die Performance muss für eine konkrete Anwendung gemessen werden. Marketingaussagen wie «kostenloses Lesen» oder «unbegrenzte Skalierung» wären daher irreführend.

Sicherheitsrisiken: Was kann schiefgehen?

Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten.

Bitcoin mit Relai kaufen – Code AUSWANDERNSCHWEIZ nutzen

Falsche Datenquelle und manipulierte Referenzen

Eine Transaktion kann grundsätzlich einen existierenden Output referenzieren, ohne dessen Spending-Berechtigung nachzuweisen. Daraus folgt nicht, dass die Daten vertrauenswürdig sind. Ein Smart Contract muss die Herkunft, erwartete Adresse, Asset-Identität und das Datenformat prüfen. Wird nur irgendein plausibel aussehender Preis akzeptiert, kann ein Angreifer einen eigenen Output mit falschem Datum bereitstellen. Die Gefahr entsteht durch unzureichende Validierungslogik, nicht durch einen Fehler im Grundprinzip von CIP-31.

Veraltete Daten und Race Conditions

Ein referenzierter Output kann zum Zeitpunkt des Transaktionsaufbaus gültig sein und vor der Aufnahme in einen Block konsumiert werden. Die Transaktion kann dann nicht mehr auf genau diesen Output zugreifen. Ebenso kann ein noch existierender Output einen wirtschaftlich überholten Kurs enthalten. Eine Anwendung muss zwischen technischer Existenz und fachlicher Aktualität unterscheiden. Fristen, Versionen und verifizierbare Publisher können helfen, ersetzen aber keine Risikoanalyse.

Smart-Contract-Fehler und Gegenparteirisiken

Auch korrekt referenzierte Daten können von einem fehlerhaften Validator falsch interpretiert werden. Bei DeFi kommen Liquidationsmechanismen, unzureichende Sicherheiten, Governance-Eingriffe und mögliche Angriffe auf Oracles hinzu. Verwahrst Du ADA oder Token über eine zentrale Börse, bestehen ausserdem Gegenparteirisiken unabhängig von CIP-31. Brücken zwischen Blockchains schaffen zusätzliche technische und organisatorische Angriffsflächen.

Kosten und wirtschaftliche Einordnung

Für die Nutzung von Reference Inputs existiert kein allgemeiner, zeitloser Pauschalpreis. Die tatsächlichen Transaktionskosten hängen unter anderem von der Transaktionsgrösse, der Ausführung von Plutus-Skripten und den jeweils gültigen Netzwerkparametern ab. Wenn ein Protokoll zuvor bei jedem Lesezugriff einen UTxO konsumieren und neu erstellen musste, kann die neue Architektur unnötige Zustandsänderungen vermeiden. Daraus darf aber kein fixer Gebührenrabatt abgeleitet werden.

Auch die Speicherung des Daten-UTxO bindet Ressourcen. Ein Output muss die geltenden Mindestanforderungen erfüllen; diese können sich mit Parametern und Eigenschaften des Outputs ändern. Bei der Planung einer Anwendung sollten Entwickler daher Initialkosten, Aktualisierungen, Speicherbedarf, Transaktionsgrösse und Ausführungsbudget zusammen betrachten. Für Nutzer ist der tatsächlich angezeigte Gesamtbetrag wichtiger als eine abstrakte Aussage über die Effizienz eines einzelnen CIP.

Was bedeutet CIP-31 für ADA als Kryptowährung?

Reference Inputs erweitern die technischen Möglichkeiten des Cardano-Netzwerks. Sie erzeugen aber keinen direkten Anspruch auf Einnahmen und garantieren keine steigende Nachfrage nach ADA. Der ADA-Kurs hängt von vielen Faktoren ab, darunter Marktstimmung, Liquidität, regulatorische Entwicklungen, Netzwerkaktivität und allgemeine Risikobereitschaft. Ein technisch sinnvolles Upgrade ist keine Kursprognose. Bei Altcoins sind starke Wertschwankungen und ein Totalverlust möglich.

Wer Cardano nutzt, sollte zwischen der Funktion des nativen Coins ADA, den Eigenschaften von Cardano-Token und den Risiken einzelner Anwendungen unterscheiden. Der Token einer DeFi-Anwendung kann vollständig andere Rechte und Risiken haben als ADA. Auch ein sicher funktionierender Referenzmechanismus schützt nicht vor einem kompromittierten Wallet, einer Phishing-Seite oder einer betrügerischen Anwendung.

Praktische Prüfliste für Nutzer und Entwickler

Als Nutzer solltest Du prüfen, ob eine Anwendung nachvollziehbar dokumentiert, welche Oracles und Smart Contracts sie verwendet, wie sie mit veralteten Daten umgeht und ob unabhängige Sicherheitsprüfungen vorliegen. Prüfe bei Wallet-Freigaben die angezeigte Transaktion und verwahre Deine Seed Phrase niemals in einer fremden Webseite. Als Entwickler solltest Du Referenzen anhand expliziter Identitäts- und Formatregeln validieren, Aktualisierungen testen, fehlende Outputs abfangen und Szenarien mit konkurrierenden Transaktionen simulieren.

Häufige Fragen zu Cardano Reference Inputs

Wird ein referenzierter UTxO ausgegeben?

Nein. Genau das ist die Kernfunktion von CIP-31: Der Output wird gelesen, ohne durch diese Transaktion konsumiert zu werden. Er kann allerdings unabhängig davon durch eine andere zulässige Spending-Transaktion ausgegeben werden.

Kann jeder beliebige Output referenziert werden?

Ein referenzierter Output muss im aktuellen UTxO-Set existieren. Für das blosse Referenzieren werden seine Spending-Bedingungen nicht geprüft. Ob ein Smart Contract den Inhalt als vertrauenswürdig akzeptieren darf, muss dessen eigene Validierungslogik entscheiden.

Sind Reference Inputs dasselbe wie Reference Scripts?

Nein. Reference Inputs nach CIP-31 sind ein Mechanismus zum Lesen eines Outputs. Reference Scripts nach CIP-33 sind in Outputs gespeicherte Skripte, die über einen solchen Verweis verfügbar gemacht werden können.

Macht CIP-31 Transaktionen kostenlos?

Nein. Normale Netzwerkgebühren und gegebenenfalls Kosten für Script-Ausführung bleiben bestehen. Die Architektur kann bestimmte unnötige Zustandsänderungen vermeiden, aber der tatsächliche Vorteil hängt von der Anwendung ab.

Kann ich durch CIP-31 höhere Staking-Erträge erzielen?

CIP-31 ist kein Staking-Produkt und legt keine Rendite fest. Es beschreibt eine Ledger-Funktion für Transaktionen. Staking-Risiken, Gebühren und mögliche Erträge müssen unabhängig davon beurteilt werden.

Fazit: Lesen ohne Ausgeben ist nützlich, aber keine Sicherheitsgarantie

CIP-31 behebt eine wichtige Einschränkung des EUTxO-Modells: Ein Daten-UTxO muss nicht mehr für jede Leseoperation verbraucht werden. Das ist besonders für gemeinsam verwendete Oracle-Daten, Konfigurationen und Referenzskripte relevant. Die entscheidenden Fragen bleiben jedoch, wer Daten bereitstellt, wie sie authentifiziert werden, wann sie veralten und welche Folgen ein Fehler hat. Für Anleger ist CIP-31 ein technisches Merkmal von Cardano, keine eigenständige Kaufempfehlung.