Cardano schlägt die Abschaffung der Plutus Gültigkeitsbereichsprüfung vor

Der Cardano Vorschlag CIP-0205 würde einen der Schritte zur Vorbereitung von Plutus Skripten auf die Ausführung abschaffen. Der Autor Jacco Krijnen schlägt vor, Fehler durch ungebundene Variablen während der Ausführung zu behandeln, statt das gesamte Programm vorab zu prüfen. Der am 25. September eingereichte Vorschlag befindet sich weiterhin in der Prüfung.

Die Kosten der Vorbereitung von Plutus Skripten

Bevor ein Skript ausgeführt wird, prüft ein Knoten, ob seine Variablen im Programm korrekt definiert sind. Diese als Gültigkeitsbereichsprüfung bekannte Kontrolle findet in der zweiten Phase der Transaktionsvalidierung statt.

Frühere, im Vorschlag zitierte Benchmarks ergaben, dass die Prüfung etwa 20% der Zeit zur Skriptvorbereitung ausmacht, einschließlich Decodierung und Versionsprüfung. In Benchmarks zur vollständigen Validierung entsprach sie ungefähr 3% der gesamten Validierungszeit. Diese Zahlen messen den Anteil der Prüfung an der Verarbeitungszeit in diesen Testlasten.

Ihre Abschaffung würde den Verarbeitungsaufwand für geeignete Skripte verringern. Eine daraus resultierende Senkung der Transaktionsgebühren hinge laut dem Vorschlag von anschließenden Anpassungen der Gebührenparameter ab.

Wie Plutus Variablenfehler behandeln würde

Plutus Core ist die Sprache zur Ausführung von Smart Contract Skripten auf Cardano. Seine Ausführungsmaschine, die CEK Maschine, verarbeitet bereits Versuche, Variablen ohne gebundenen Wert zu verwenden.

In der Begutachtungsdiskussion zum Vorschlag merkte der Entwickler Seungheon Oh an, dass CEK nicht von der vorläufigen Gültigkeitsbereichsprüfung abhängt. Der Versuch, eine ungebundene Variable auszuwerten, führt zu einem gewöhnlichen Ausführungsfehler.

Nach den vorgeschlagenen Regeln könnte ein Programm erfolgreich sein, wenn eine ungebundene Variable nur in Code erscheint, der niemals ausgeführt wird. Programme mit korrekt definierten Gültigkeitsbereichen würden die gleichen Ausführungsergebnisse behalten.

Entwicklungssprachen wie Aiken, Plinth und Plutarch erzwingen den Gültigkeitsbereich von Variablen bereits durch ihre Typprüfer, bevor Skripte die Blockchain erreichen, heißt es in dem Vorschlag.

Eine neue Sprachversion und ein Hard Fork

Der Entwurf verknüpft die Änderung mit der Plutus Core Sprachversion 1.2.0, was einen Hard Fork erfordern würde. Die Implementierung würde Aktualisierungen der Spezifikation, des Ausführungscodes, des formalen Modells und der Konformitätstests umfassen.

Der Vorschlag erhielt am 29. September die Nummer CIP-0205. CIP Editor Robert Phair bat vor dem Fortgang der Begutachtung um eine breitere Verteilung unter Arbeitsgruppen und verwies auf die Tragweite der Änderung.

Nach dem aktuellen Entwurf würden bestehende Skripte mit den Sprachversionen 1.0.0 und 1.1.0 ihr Verhalten beibehalten. Nach der Aktivierung könnten neue Skripte mit der deklarierten Version 1.2.0 ohne die separate vorläufige Gültigkeitsbereichsprüfung ausgeführt werden.