Cardanoの時間処理パート2:ユースケース

本稿は、Arnaud Bailly、Michael Peyton Jones、Sebastian Nagel、Polina Vinogradova、Brian Bushによる共同執筆によるものです。

前回の投稿では、OuroborosによるCardanoの時間処理方法と決定性の重要性を説明しました。ここでは、Cardanoの時間に関する具体的なユースケースを紹介します。

Plutusスクリプトによる時間処理

Plutusスクリプトは、作成者が定義するトランザクション有効範囲にアクセスします。有効範囲を定義する際、作成者はトランザクションがスロットXからスロットYまで有効とするか、どちらかを定義せずにしておくことができます。これにより、トランザクションを含むことができるスロットを制約することができます。これは、オンチェーンでさまざまな「コントラクト」を定義する際に非常に便利です。

スクリプトは、実際の検証時間がこの範囲内にあると推定できます。そうでなければ、トランザクションはスクリプトが実行される前に第一段階で失敗します。これは、スクリプトがいつ検証されたかにかかわらず常に同じ情報（有効範囲）を参照するため、動作は同じとなり、決定性が保証されます。

有効期間の制限は、スロットよりも実際の時間（POSIXTime）で表現され、スロットから時間への換算は、前回の投稿で説明したとおり、コンセンサスによって実行されます。スロットではなく実際の時間を使用することは重要です。これは、スロット長がハードフォークで変化する可能性があることから、スロット数に基づく前提は一般に信頼できないためです。スクリプトが有効範囲を参照するという事実によって、スクリプトは「現在の時間が所与の時間の前または後である」というようなアサーションを行うことはできますが、それ以外のタイプのアサーションを行うことはできません（「このトランザクションが検証される秒は偶数」など）。

Alonzoの元の設計では、有効範囲は既知のすべての時間の使用をカバーすると同時に、既存の存続可能時間（TTL）フィールドにもうまく適合します。理論上は、例えば同じ原理を他のタイプのアサーションに適用させることが可能です。すなわち第一段階でチェックされたアサーションにスクリプトを依存させるということですが、これはCardanoネットワークのさまざまな部分に大規模な構造的変化を伴うことになるため、簡単ではありません。さらに、第一段階のチェックはネットワーク中のすべてのノードで有効となる必要があります。これにより、「現在の時刻」などのローカル条件に依存するあらゆる種類のアサーションが排除されます。

時間のユースケース

Cardanoエコシステムには時間に関するさまざまなアプリケーションがあります。

Hydra

Hydraプロトコルは、コンテスト期限を計算し実施する時間に依存しています。これは、プロトコルのセーフティメカニズムにとって重要な部分です。Hydra HeadステートマシンはUTCTimeを使用して時間の経過を追跡しますが、ティックは、チェーンによって生成されたブロックから観測されるスロット番号に基づき、チェーンから取得されます。UTCTimeを使用する理由は、有効時間によって課されるスロットから時間への換算に伴う制限に対応するためです。スロットをかなり先の未来まで換算することはできません。これは、UTCTimeをオフチェーン使う方が簡単であり、チェーンとのトランザクションの送受信の時だけ換算することを意味します。

これは、ティックの粒度が約20秒であることを示しています。これはブロック生成の予想頻度であるためです。この時間尺度を使って、Hydraはプロトコル関連のコンテスト期限の超過に対応することができます。

重要なことは、Hydra Head（およびノード）のローカルタイムがOuroborosが処理するオンチェーンタイムに関連付けられていることです（パート1参照）。Hydraは同型的プロトコルであるため、望ましいのはレイヤー2でも「時限トランザクション」が処理されることです（issue #196参照）。しかし、Hydraはブロックを生成しないため、コンセンサス自体に時間の概念は（まだ）必要ありません。

これには、レイヤー2台帳で時間を離散化する精度とプロセスを理解する必要があります。オンチェーンで時間を処理する複雑性はレイヤー2にも当てはまりますが、レイヤー2はネットワークがかなり小規模で、寿命が短く、グローバルなスケーリングを必要としないため、よりよい解決策を提供できます。

議論に参加し、所有するアプリのタイプとそれが必要とする解決時間を共有することに関心がある場合は、Hydra Discordチャネルにご参加ください。

Marlowe

Marloweは、金融および取引契約を作成するためのドメイン固有言語（DSL）であり、そのほぼすべてに時間がかかわります。Marloweでは、ほとんどのACTUS標準コントラクト（ローン、スワップ、オプション、デリバティブなど）を含む、幅広い標準金融コントラクトを作成できます。さらに、Marloweはオークション、トークンスワップ、ゲームなど、さまざまな非金融コントラクトタイプもサポートしています。時間に関するCardanoの既存のメカニズムは、Marloweのセマンティクスとうまく一致し、MarloweのトランザクションにPlutusから受け継いだローカル性と決定性を提供します。

Marloweでは、コントラクトの時間は通常コントラクトの実行がどのように展開するかを制限する締切とタイムアウトとして表示され、これはCardanoの有効期間と完全に連携します。例えばタイムアウトロジックはローンコントラクトでローンの支払いが実行されないという状況を処理するために必要とされます。その後で、罰則を科す、将来の支払いのスケジュールを調整するなどのために、別のロジックが必要になります。コントラクトは、早期支払いをいつ受け取ったかに基づいて、その後の支払いを調整するためなど、数値計算で有効期間の時間エンドポイントを直接使用することもできます。時間が間隔として表示されるという事実が、Marloweに実際的な影響を与えることはほとんどありません。間隔はほんの数分であり、トランザクションを送信してからCardanoネットワーク上のブロックに表示されるまでの時間と同じくらい短い可能性があるからです。

解決案

Cardanoは、可能性として、トランザクションの検証中に、ブロック生成者からのブロックの発行やスロットからの換算時のタイムスタンプ、またはミリ秒の精度をもつUTCの実際のタイムスタンプなど、より正確な時間関連のデータを提供することができます。しかし、これはこの機能を持たないプロトコルで実行されるため、前方決定性を壊します（パート1参照）。ユーザーは、ブロック生成者がブロック作成時に使用した正確なタイムスタンプに依存することになるため、トランザクションが確実に台帳に適用されるのか否かを知ることができなくなります。

もう1つのオプションは、有効期間をこえるさまざまなアサーションタイプをトランザクションボディに追加することです。これは可能ですが、前述したとおり困難です。これらのアサーションタイプが役立つユースケースが必要です。

最後に、Hydraなどのレイヤー2ネットワークは、「スロット長」を短くし、有効範囲を短くすることで精度を高め、トランザクションのファイナリティでの待ち時間を短縮できます。現在のHydra Headの実装はまだこのレベルの柔軟性を提供していないことに注意してください。

まとめ

これは、特に分散型ブロックチェーンの設定において複雑なトピックです。これらの記事では、Cardanoのオンチェーン時間には特定の制約が付いた明確な概念があり、長期的には利用可能な改善オプションがあることを示しています。

オンチェーン時間は、従来のソフトウェアとはいく分異なる動作をします。この分岐は、エンドユーザーとステークプールオペレーターのセキュリティと使いやすさを確保しながら、システムの制約に対処するために一貫した方法で定義されています。さらに、Cardanoの時間測定は、従来の金融用途と比較しても、複数のユースケースをカバーするのに十分に優れているようです。

Discordコミュニティチャネルで、Cardanoの時間処理とここで触れられなかったユースケースの可能性についての議論に参加してください。