Cardano Reference Scripts erklärt: CIP-33, Gebühren, UTxO und Sicherheitsrisiken
Cardano Reference Scripts ermöglichen es einer Transaktion, einen bereits auf der Blockchain gespeicherten Smart-Contract-Code zu verwenden, ohne ihn bei jeder Ausführung vollständig mitzusenden. Hinter dieser Idee steht CIP-33. Das klingt zunächst nach einer technischen Kleinigkeit, beeinflusst aber die Grösse, Kostenstruktur und praktische Gestaltung von Cardano-Anwendungen. Entscheidend ist die Unterscheidung zwischen dem gespeicherten Skript, dem referenzierten UTxO und den Daten, die der Vertrag auswertet. In diesem Leitfaden erfährst Du, wie das Zusammenspiel funktioniert, welche Kosten tatsächlich entstehen und welche Risiken Entwickler und Nutzer beachten sollten.
Was ist ein Reference Script auf Cardano?
Ein Reference Script ist ein Skript, das in einem Transaktionsausgang, also einem UTxO, abgelegt werden kann. Eine spätere Transaktion kann auf diesen Ausgang verweisen und den dort hinterlegten Skriptcode für die Validierung heranziehen. Das Skript muss dann nicht erneut als vollständiger Witness in der Transaktion stehen. Der Referenz-UTxO bleibt beim blossen Lesen erhalten. Das ist besonders nützlich, wenn viele Nutzer denselben Smart Contract wiederholt aufrufen. Die Idee wurde mit CIP-33 formal beschrieben und gehört zu den Verbesserungen, die mit dem Vasil-Protokollupgrade eingeführt wurden.
Das Verfahren ist nicht mit dem Ausführen eines Programms auf einem zentralen Server zu verwechseln. Die Validierung folgt weiterhin den Konsensregeln des Cardano-Ledgers. Ein Reference Script ist auch keine zusätzliche Kryptowährung und kein eigener Token. Es ist eine Art, vorhandenen Code für die Transaktionsprüfung bereitzustellen. Ob eine konkrete Anwendung davon profitiert, hängt von ihrem Skript, ihrer Transaktionsstruktur und den aktuellen Netzwerkparametern ab. Eine kleinere Transaktion ist deshalb nicht automatisch eine günstige oder sichere Transaktion.
Warum wurde CIP-33 entwickelt?
Vor der Einführung mussten Transaktionen, die ein Plutus-Skript benötigten, den entsprechenden Code typischerweise als Skript-Witness mitführen. Bei umfangreichen Validatoren konnte dieser Bestandteil einen erheblichen Anteil der gesamten Transaktionsbytes ausmachen. Wiederholten viele Nutzer denselben Aufruf, wurde derselbe Code wieder und wieder übermittelt. Das belastete die verfügbare Transaktionsgrösse und beeinflusste Gebühren, die teilweise von der Bytezahl abhängen.
CIP-33 löst dieses Wiederholungsproblem, indem das Skript einmal in einem UTxO bereitgestellt und später referenziert werden kann. Damit verschwindet der Code nicht aus der Blockchain: Er wird an einer anderen Stelle gehalten und ist weiterhin Teil des gespeicherten Zustands. Das System verschiebt Kosten und Verantwortlichkeiten. Die erstmalige Bereitstellung kostet Ressourcen, und die spätere Nutzung ist nicht gratis. Gerade bei vielen wiederkehrenden Interaktionen kann die Verschiebung dennoch sinnvoll sein. Bei selten verwendeten oder sehr kleinen Skripten ist der Vorteil dagegen weniger eindeutig.
UTxO und eUTxO: Die technische Grundlage
Cardano verwendet ein erweitertes Unspent-Transaction-Output-Modell, kurz eUTxO. Eine Transaktion konsumiert bestimmte Eingänge und erzeugt neue Ausgänge. Jeder noch nicht ausgegebene Ausgang ist ein UTxO. Im erweiterten Modell können Ausgänge zusätzliche Informationen enthalten, die für Smart Contracts relevant sind. Die Prüfung eines Skripts hängt von den konkret bereitgestellten Transaktionsdaten ab, nicht von einem beliebig veränderlichen globalen Kontostand.
Ein normaler Spending Input wird beim erfolgreichen Ausgeben konsumiert. Ein Reference Input wird dagegen nur gelesen. Die in diesem UTxO liegenden Werte werden nicht zur Finanzierung der Transaktion verwendet, und seine Ausgabebedingungen müssen für das blosse Referenzieren nicht erfüllt werden. Das erklärt, warum viele Transaktionen dieselbe Information lesen können, ohne den Ausgang bei jedem Zugriff neu erstellen zu müssen. Der referenzierte Ausgang muss allerdings zum relevanten Validierungszeitpunkt verfügbar sein. Seine Existenz ist eine technische Voraussetzung und keine Garantie für die inhaltliche Richtigkeit seiner Daten.
CIP-31, CIP-32 und CIP-33 sauber unterscheiden
Diese drei Cardano Improvement Proposals werden häufig gemeinsam genannt, erfüllen aber unterschiedliche Aufgaben. CIP-31 führt Reference Inputs ein: eine Transaktion darf einen vorhandenen Ausgang betrachten, ohne ihn auszugeben. CIP-32 erlaubt Inline Datums: Daten können direkt in einem Ausgang stehen, statt dort lediglich durch ihren Hash repräsentiert zu werden. CIP-33 ergänzt Reference Scripts: Der Skriptcode kann in einem Ausgang gespeichert und von späteren Transaktionen referenziert werden.
Die Unterschiede sind wichtig, weil ein Datum nicht dasselbe ist wie ein Validator. Ein Datum beschreibt häufig den Zustand oder Parameter einer Anwendung. Ein Redeemer liefert Informationen für einen bestimmten Ausführungsversuch. Ein Validator legt die Regeln fest, nach denen eine Ausgabe erlaubt oder abgelehnt wird. Wenn Du in einem Blockexplorer ein Inline Datum siehst, hast Du deshalb noch keinen Beweis, dass ein Reference Script verwendet wurde. Umgekehrt kann ein Reference Script eingesetzt werden, ohne dass jeder Beteiligte die fachliche Bedeutung der übrigen Daten kennt.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Code: AUSWANDERNSCHWEIZ.
Wie läuft eine Transaktion mit Reference Script ab?
Zunächst muss ein geeigneter Ausgang mit dem vorgesehenen Skript erstellt werden. Der Ausgang enthält neben seiner üblichen Struktur das Referenzskript. Anschliessend erstellt die Anwendung eine neue Transaktion mit den tatsächlich auszugebenden Eingängen, den neuen Ausgängen und den für die Skriptprüfung nötigen Daten. Statt den gesamten Validatorcode erneut einzubetten, nennt sie den UTxO, der das passende Skript enthält. Die Ledger-Regeln prüfen dann die benötigte Skriptidentität und führen die Validierung entsprechend aus.
Bei der Prüfung sind Skript-Hash, Plutus-Version, Datum, Redeemer und Ausführungskontext auseinanderzuhalten. Der blosse Verweis auf irgendeinen Ausgang mit irgendeinem Skript reicht nicht. Ein falsch gewählter Referenzausgang oder eine unpassende Version kann zur Ablehnung führen. Auch das Vorhandensein des richtigen Codes garantiert keinen erfolgreichen Vertragsschritt: Die Geschäftsregeln des Validators müssen erfüllt sein. Ein Kauf, Tausch oder Kreditvorgang kann weiterhin scheitern, obwohl der Skript-Witness korrekt referenziert wird.
Beispiel: Ein DeFi-Vertrag mit wiederholten Aufrufen
Stell Dir eine dezentrale Anwendung vor, deren Validator bei vielen Transaktionen identisch ist. Ohne Reference Script würde jeder Nutzer beim Aufruf den Validatorcode mit der Transaktion übermitteln. Mit CIP-33 kann die Anwendung den Code in einem geeigneten UTxO bereitstellen und die späteren Transaktionen darauf verweisen lassen. Die Nutzenden senden weiterhin ihre individuellen Inputs, Outputs und gegebenenfalls Redeemer. Sie sparen lediglich die erneute Übermittlung des wiederverwendbaren Skripts.
Der Effekt ist besonders verständlich, wenn Du Code und Nutzerdaten getrennt betrachtest. Die Regel, nach der ein Tausch erlaubt ist, bleibt gleich; der konkrete Betrag, der Zustand des Pools und die Signaturen ändern sich von Transaktion zu Transaktion. Ein Reference Script beseitigt weder Preisabweichungen noch Slippage, Oracle-Risiken oder fehlerhafte Vertragslogik. Es verändert die technische Bereitstellung des Validators. Ob der Betreiber eines Protokolls die dadurch möglichen Einsparungen an Nutzer weitergibt, lässt sich aus dem Standard allein nicht ableiten.
Gebühren: Was wird günstiger und was bleibt kostenpflichtig?
Cardano-Gebühren bestehen nicht aus einem einzigen unveränderlichen Festpreis. Transaktionsgrösse, Ausführung und weitere Protokollparameter können eine Rolle spielen. Reference Scripts reduzieren häufig den Platzbedarf im eigentlichen Transaktions-Witness, aber die referenzierten Skriptbytes können selbst Gebühren verursachen. Die aktuelle Entwicklerdokumentation weist ausdrücklich darauf hin, dass referenzierte Bytes nicht kostenlos sind und die Gebühren für sehr grosse Skripte ansteigen können. Es wäre deshalb falsch, CIP-33 als kostenlose Smart-Contract-Ausführung zu bewerben.
Ein vereinfachtes Rechenbeispiel illustriert nur die Grössenordnung der übertragenen Daten: Wenn ein Validator hypothetisch 12 Kilobyte umfasst und 100 Transaktionen ihn jeweils vollständig mitsenden, wären das rechnerisch 1'200 Kilobyte wiederholt übertragener Skriptcode. Mit einem Reference Script muss dieser Code nicht in jedem der 100 Transaktions-Witnesses erneut stehen. Daraus folgt aber weder eine Einsparung von genau 1'200 Kilobyte im gesamten Ledger noch eine bestimmte ADA-Gebühr. Der gespeicherte Ausgang, Referenzen, Ausführungsressourcen und die geltenden Parameter müssen separat berücksichtigt werden.
Kostenvergleich richtig durchführen
Für einen belastbaren Vergleich solltest Du zwei funktional gleichwertige Transaktionen konstruieren: eine mit eingebettetem Skript und eine mit Reference Script. Miss die serialisierte Transaktionsgrösse, die berechnete Gebühr, die benötigten Ausführungseinheiten und gegebenenfalls die Kosten für das Anlegen des Referenzausgangs. Verwende dafür dieselben Netzwerkparameter und vergleichbare Inputs. Ein reiner Blick auf die Bytezahl ist unvollständig, wenn unterschiedliche Skriptversionen oder Vertragslogik verwendet werden.
Auch die Zahl der erwarteten Aufrufe spielt eine Rolle. Ein einmalig genutztes Skript muss die Bereitstellungskosten erst rechtfertigen; ein häufig aufgerufener Validator kann diese Kosten über viele Transaktionen verteilen. Rechne deshalb nicht mit einer pauschalen Prozentersparnis. Protokollparameter können sich ändern, und die tatsächlich erhobene Gebühr kann von der Transaktionskonstruktion abhängen. Für einen konkreten Dienst solltest Du Gebühren unmittelbar vor dem Signieren anzeigen lassen und mit den veröffentlichten Regeln abgleichen.
Sicherheit: Ein Reference Script ist kein Gütesiegel
Ein Referenzskript ist lediglich ein technisch verfügbarer Codebestandteil. Die Blockchain garantiert nicht, dass der Validator wirtschaftlich sinnvoll, frei von Programmierfehlern oder für Dich geeignet ist. Fehler in Berechtigungsprüfungen, Preislogik oder Zustandsübergängen können weiterhin zu Verlusten führen. Ein öffentlich abrufbarer Skript-Hash hilft beim Identifizieren des Codes, ersetzt aber weder ein Audit noch die Prüfung, ob die Benutzeroberfläche tatsächlich den erwarteten Vertrag anspricht.
Besonders kritisch ist die Verwechslung von Skriptidentität und Anwendungsidentität. Eine Webseite kann einen seriösen Namen tragen und trotzdem eine Transaktion mit unerwarteten Ausgängen vorbereiten. Vergleiche bei wichtigen Vorgängen den Zielvertrag, die abfliessenden Assets, Gebühren und Signaturanforderungen. Nutze nach Möglichkeit Wallets, die Transaktionsdetails verständlich anzeigen. Eine Hardware-Wallet kann Schlüssel schützen, aber nicht jede betrügerische oder wirtschaftlich nachteilige Transaktion automatisch erkennen.
Verfügbarkeit, Aktualisierung und Governance
Eine Anwendung, die sich auf einen bestimmten Reference-Script-UTxO stützt, muss dessen Verfügbarkeit berücksichtigen. Wird ein Referenzausgang ausgegeben oder ersetzt, müssen Transaktionsbuilder den neuen Zustand kennen. Die Tatsache, dass mehrere Transaktionen denselben Ausgang lesen können, bedeutet nicht, dass er für alle Zukunft unveränderlich oder erreichbar bleibt. Ein robustes Protokoll dokumentiert deshalb, wie Referenzen veröffentlicht, aktualisiert und im Fehlerfall ersetzt werden.
Governance-Fragen entstehen, wenn ein Team entscheidet, welche Version des Validators künftig benutzt wird. Ein unveränderlicher Skript-Hash identifiziert eine konkrete Version; ein Upgrade kann einen neuen Skriptcode und neue Referenzen erfordern. Wer die Umstellung kontrolliert, ist eine separate Vertrauensfrage. Dezentralisierung lässt sich nicht allein daran erkennen, dass ein Skript auf der Blockchain gespeichert ist. Prüfe, ob Administratoren Parameter ändern, Verträge pausieren oder Nutzer auf neue Adressen lenken können.
Reference Scripts und Smart-Contract-Versionen
Cardano hat verschiedene Plutus-Versionen und Ledger-Weiterentwicklungen. Ein Smart Contract muss zur jeweils verwendeten Skriptsprache und zum Transaktionskontext passen. Die ursprüngliche CIP-33-Spezifikation thematisiert ausdrücklich die Darstellung von Referenzskripten im Skriptkontext und die Kompatibilität mit älteren Sprachversionen. Daraus folgt: Entwickler sollten nicht annehmen, dass ein beliebiger historischer Validator ohne Anpassung mit jeder neuen Transaktionsform kombinierbar ist.
Für produktive Anwendungen sind Tests auf einem geeigneten Testnetz und eine nachvollziehbare Versionsverwaltung entscheidend. Dazu gehören positive und negative Testfälle, die Kontrolle des tatsächlich referenzierten Skript-Hashes und die Prüfung von Fehlerpfaden. Wenn ein Wallet oder eine Bibliothek Reference Inputs falsch zusammensetzt, kann die Transaktion trotz korrekter fachlicher Absicht scheitern. Für Endnutzer ist besonders wichtig, dass Wallet und Anwendung den konkreten Vertragstyp unterstützen; ein allgemeines Versprechen der Cardano-Kompatibilität genügt nicht.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Code: AUSWANDERNSCHWEIZ.
Risiken für Nutzer von Cardano-DApps
Bei einer DeFi-Anwendung kommen mehrere Risikoklassen zusammen. Der ADA-Kurs kann stark schwanken und ein Totalverlust ist möglich. Ein Smart Contract kann eine Schwachstelle enthalten, ein Oracle fehlerhafte Preise liefern oder eine Bridge durch einen Angriff Vermögenswerte verlieren. Auch Liquidationsregeln, Verwaltungsrechte und Abhängigkeiten von externen Diensten verdienen Aufmerksamkeit. CIP-33 beseitigt keines dieser Risiken. Es ist eine Effizienzfunktion, keine Versicherung.
Wer Token auf einer Börse hält, trägt zusätzlich Gegenparteirisiken. Wer sie selbst verwahrt, trägt die Verantwortung für Schlüssel und Backups. Eine falsche Adresse, ein manipulierter Link oder eine unbedachte Signatur kann erhebliche Schäden verursachen. Nutze für grössere Beträge zuerst eine kleine Testtransaktion, prüfe die Zieladresse unabhängig und dokumentiere Deine Transaktionen. Für die Schweiz können Vermögensdeklaration und die steuerliche Einordnung von Erträgen relevant sein; die individuelle Behandlung hängt vom Sachverhalt ab.
Woran erkennst Du eine seriöse Implementierung?
Ein seriöses Projekt beschreibt, welche Validatoren es verwendet, wie ihre Skript-Hashes überprüft werden können und welche Versionen aktiv sind. Es erläutert Gebühren, Administratorrechte, Sicherheitsannahmen und bekannte Einschränkungen. Idealerweise sind Quellcode und unabhängige Prüfberichte zugänglich. Ein Audit kann das Risiko senken, ist aber keine Garantie. Prüfe ausserdem, ob kritische Abhängigkeiten und mögliche Upgrade-Pfade transparent dokumentiert sind.
Misstrauisch solltest Du bei Renditeversprechen, unklaren Vertragsadressen, fehlender Dokumentation und der Behauptung werden, Reference Scripts machten eine Anwendung automatisch sicher oder gebührenfrei. Ein technischer Standard kann die Infrastruktur verbessern, aber keine wirtschaftliche Qualität garantieren. Unterscheide stets zwischen nachprüfbaren Ledger-Funktionen, Aussagen des Projektteams und eigenen Erwartungen an den Coin-Preis.
FAQ: Häufige Fragen zu Cardano Reference Scripts
Sind Reference Scripts dasselbe wie Reference Inputs? Nein. Reference Inputs nach CIP-31 ermöglichen das nicht konsumierende Lesen eines UTxO. Reference Scripts nach CIP-33 sind Skripte, die in solchen Ausgängen hinterlegt und von Transaktionen referenziert werden können. Die Konzepte ergänzen sich, sind aber nicht identisch.
Kann ich damit ADA kostenlos verschicken? Nein. Die Funktion richtet sich vor allem an Smart-Contract-Transaktionen. Netzwerkgebühren und gegebenenfalls Skriptausführungskosten bleiben bestehen. Wie hoch die Gebühr ausfällt, muss anhand der konkreten Transaktion berechnet werden.
Kann jeder Nutzer ein Reference Script prüfen? Der gespeicherte Skriptcode und seine Kennung lassen sich grundsätzlich anhand der Blockchain-Daten untersuchen. Ob der Code fachlich korrekt ist, erfordert jedoch technisches Verständnis und gegebenenfalls zusätzliche Werkzeuge.
Erhöhen Reference Scripts automatisch die Zahl der Transaktionen pro Sekunde? Nicht automatisch. Kleinere Transaktionen können die Ressourcennutzung verbessern. Der tatsächliche Durchsatz hängt aber von vielen weiteren Protokollgrenzen, der Transaktionsmischung und dem Netzwerkzustand ab.
Was passiert, wenn die Referenz nicht mehr existiert? Dann muss die Anwendung eine gültige Referenz finden oder die Transaktion anders konstruieren. Entwickler sollten solche Fälle ausdrücklich behandeln.
Sind Reference Scripts nur für DeFi relevant? Nein. Wiederverwendbare Validatoren können auch in anderen Smart-Contract-Anwendungen vorkommen. Ob sich die Technik lohnt, hängt von der Architektur und Nutzungshäufigkeit ab.
Fazit: Effizienzgewinn mit klaren Grenzen
CIP-33 ist ein wichtiger Baustein der Cardano-Smart-Contract-Infrastruktur. Die Möglichkeit, Validatorcode in einem UTxO abzulegen und später zu referenzieren, reduziert unnötige Wiederholungen in Transaktionen. Zusammen mit CIP-31 und CIP-32 erleichtert dies bestimmte Architekturen für datenintensive und wiederkehrende Anwendungen. Dennoch entstehen weiterhin Gebühren, und ein technisch effizienter Vertrag ist nicht automatisch sicher oder wirtschaftlich sinnvoll.
Wenn Du Cardano-DApps bewertest, lohnt sich der Blick über Marketingbegriffe hinaus: Welche Skriptversion wird genutzt, wer kontrolliert Upgrades, wie werden Referenzen verwaltet und welche Risiken bestehen ausserhalb des Validators? Dieser Artikel dient der allgemeinen Information und stellt keine persönliche Anlage-, Rechts- oder Steuerberatung dar.
Kommentare