Cardano CIP-0195 kodiert Plutus V4 mit Listen statt Arrays
Victoria Shinder2 Min. LesezeitDas Repository der Cardano Improvement Proposals hat am 13. Oktober 2026 CIP-0195 „Data Encoding of Plutus V4 Ledger Types“ mit dem Status Proposed aufgenommen. Verfasst von Ziyang Liu (IOG), mit dem Plutus-Team von IOG als Implementierer, legt er fest, wie die Ledger-API-Typen der nächsten Plutus-Version – der Skriptkontext und die darin vorkommenden Typen – als Data-Objekte kodiert werden, die Smart Contracts erhalten.
Warum es den CIP braucht. Der Vorschlag nennt drei Gründe. UPLC hat inzwischen einen eingebauten Typ Array mit Zugriff in konstanter Zeit, was die Frage nach einem Wechsel der Kodierung aufwirft. Plutus V1 bis V3 haben bekannte Ineffizienzen: Jeder Produkttyp steckt in einem überflüssigen Constr 0-Tag, und um an eine Grenze eines Interval oder an den Credential in einem Maybe StakingCredential zu kommen, braucht es zwei Constr-Ebenen, wo eine genügen würde. Außerdem war die Kodierung in V1–V3 nie formal spezifiziert – maßgeblich war faktisch Template-Haskell-Code im Repository plutus, den Entwickler alternativer Compiler zurückentwickeln mussten.
Listen statt Arrays – mit überraschender Begründung. Der CIP kommt zu dem Schluss, dass List klar die bessere Wahl für die Kodierung von Datentypen ist, trotz des konstanten Array-Zugriffs. Erstens braucht die Listenkodierung keine Änderung am Typ Data, Arrays dagegen zwei neue Konstruktoren und vier neue Built-ins – ein tiefer Eingriff für Plutus und für alle anderen Sprachen und Werkzeuge. Zweitens sind Listen in der Praxis meist schneller: Dank des neuen Built-ins dropList mit geringem Grund- und Stückpreis im Kostenmodell bleibt der Listenzugriff selbst beim 20. Feld schneller als indexArray – und TxInfo, der größte V4-Konstruktor, hat genau 20 Felder. Arrays gewinnen nur in Randfällen, etwa beim Lesen weniger, weit auseinanderliegender Felder eines großen Konstruktors. Drittens spart das Erzeugen von Data aus Listen eine zusätzliche Umwandlung mit listToArray; die Autoren schätzen, dass die Umwandlung einer Liste mit 1.000 Elementen deutlich unter 1 Prozent des Transaktionslimits kostet, wenn ein Array wirklich gebraucht wird.
Was sich sonst ändert. Produkttypen werden als schlichte List [x1…xn] statt Constr 0 [x1…xn] kodiert, was den Aufwand für das Zerlegen von Paaren spart. Beim Abflachen verschachtelter Typen ist der CIP zurückhaltend: Der naheliegende Kandidat Maybe StakingCredential entfällt ohnehin, weil Address in V4 ein Maybe AccountId trägt, und auch der übermäßig verschachtelte Typ Interval wird in V4 durch einen neuen ersetzt.
Für Vertragsautoren heißt das: V4-Skripte lesen ihren Kontext über eine dokumentierte Kodierung statt über eine aus generiertem Code erschlossene, mit anderem Aufbau als in V1–V3, wo immer Produkttypen oder die neuen Typen für Address und Intervalle betroffen sind.
Quelle: Cardano Foundation, CIPs-Repository, CIP-0195 „Data Encoding of Plutus V4 Ledger Types“ (aufgenommen am 13. Oktober 2026) — https://github.com/cardano-foundation/CIPs/commit/3d15c14da08d1fe22f61f717d50fc08eeb0baea1