- Cardano arbeitet an einer effektiven Lösung für den Umgang mit der On-Chain-Zeit, die auf dem Gültigkeitsbereich und dem Slot-Bereich basiert.
- Erfahren Sie, wie Smart-Contract- und Skalierbarkeitslösungen wie Plutus, Marlowe und Hydra dies effektiv handhaben.
Die Cardano-Blockchain hat kürzlich detaillierte Berichte über die Zeitverarbeitung durch das Ouroboros-Konsensprotokoll veröffentlicht. Das Protokoll leitet die geprägten Blöcke rechtzeitig an alle Knoten im System weiter. Infolgedessen erfordert der Zeitaufwand die Erstellung einer global akzeptablen Darstellung für den Konsens.
In einem aktuellen Blog-Post erklärt die Cardano-Muttergesellschaft Input Output Global (IOHK), wie die Plutus-Skripte die Zeit auf effektive Weise verarbeiten. Die Plutus-Skripte erhalten Zugriff auf den Gültigkeitsbereich der Transaktion, wie er von ihrem Ersteller definiert wurde.
Der Ersteller erhält die Flexibilität, den Gültigkeitsbereich so zu definieren, dass jede Transaktion von Slot X bis Slot Y gültig ist. Aber das bringt auch die Einschränkung mit sich, eine Transaktion in einen bestimmten Slot aufzunehmen. In der offiziellen Ankündigung heißt es dazu:
„Das Skript kann davon ausgehen, dass der tatsächliche Zeitpunkt der Validierung in diesem Bereich liegt. Andernfalls wird die Transaktion in Phase eins vor der Skriptausführung fehlschlagen. Dies gewährleistet Determinismus, da das Skript immer dieselbe Information – den Gültigkeitsbereich – sieht, unabhängig davon, wann das Skript validiert wird, so dass das Verhalten gleich ist.“
Die Grenzen des Gültigkeitsintervalls erfolgen in Echtzeit (POSIXTime) und nicht in Slots. Außerdem erfolgt die Umwandlung von Slots in Echtzeit durch einen Konsens. Cardano erklärt, dass die Verwendung von Echtzeit anstelle von Slots wichtig ist, da sich die Slot-Längen bei einer Hardfork ändern können. Daher sind Annahmen, die auf Slots basieren, mehr oder weniger unzuverlässig.
Anwendungsfälle der Zeitverarbeitung in Hydra und Marlowe
Um seine Anfechtungsfrist zu berechnen und durchzusetzen, ist das Hydra-Protokoll auf den Sicherheitsmechanismus angewiesen. Mit Hilfe von UTCTime verfolgt der Hydra-Head-Zustandsautomat den Zeitablauf. Der endgültige Tick kommt jedoch von der Kette, basierend auf der Slot-Nummer, die von den von der Kette produzierten Blöcken beobachtet wird.
Durch die Verwendung von UTCTime geht Hydra die Einschränkungen an, die sich aus der Umwandlung von Zeit-Slots in Zeit ergeben, die durch das Gültigkeitsfenster auferlegt werden. In der Ankündigung heißt es dazu:
„Man kann einen Slot nicht zu weit in die Zukunft konvertieren, was bedeutet, dass es einfacher ist, die UTC-Time außerhalb der Chain zu verwenden und nur dann Konvertierungen vorzunehmen, wenn Transaktionen an die Chain gesendet oder von ihr empfangen werden. Das bedeutet, dass die Granularität des Ticks ungefähr 20 Sekunden beträgt, da dies die erwartete Frequenz ist, mit der Blöcke produziert werden.“
Dadurch kann Hydra auf die protokollrelevante Überschreitung der Anfechtungsfrist reagieren.
„Marlowe“ ist eine domänenspezifische Sprache, die für das Schreiben von Finanz- und Transaktions-Contracts zuständig ist. Sie unterstützt auch nicht-finanzielle Contract-Arten wie Token-Swaps, Auktionen und sogar Spiele. Cardanos bestehender Mechanismus für die Zeitabwicklung ist mit der Semantik von Marlowe gut verzahnt. Es bietet Marlowe-Transaktionen mit Lokalität in Kombination mit dem von Plutus übernommenen Determinismus.
Cardano Anmerkungen: In Marlowe erscheint die Zeit des Contracts typischerweise in den Fristen und Timeouts, die die Ausführung des Contracts einschränken, und das funktioniert perfekt mit den Gültigkeitsintervallen von Cardano. Die Timeout-Logik wird beispielsweise in einem Darlehensvertrag benötigt, um mit der Situation umzugehen, dass eine Darlehenszahlung verpasst wird: Dann muss eine andere Logik ausgeführt werden, um eine Strafe zu verhängen, den Zeitplan für zukünftige Zahlungen anzupassen etc.
Die Lösung
Während der Transaktionsvalidierung möchte Cardano genauere zeitbezogene Daten bereitstellen, die den Zeitstempel des Blockherstellers enthalten, zu dem der Block gemined wurde. Sie kann auch den tatsächlichen Zeitstempel in UTC mit der Genauigkeit von Millisekunden anzeigen.
Dies würde jedoch den schützenden Determinismus der Protokolle aufheben, die diese Funktion nicht mehr enthalten. Eine weitere Option wäre das Hinzufügen verschiedener Arten von „Behauptungen“ zu den Transaktionskörpern über das Gültigkeitsintervall hinaus. Dies wäre zwar möglich, aber schwierig zu implementieren.
Doch Layer-2-Netze wie Hydra können durch einen kürzeren Gültigkeitsbereich und einen kürzeren Slot-Bereich höchste Genauigkeit bieten. Das geht mit der geringeren Latenzzeit bei der Finalität von Transaktionen einher.
