Plutus、Marlowe、HydraはどのようにCardanoの時間管理に対応しているのか？この記事ではカルダノ上の時間に関する具体的な使用例について詳しく説明します。

以下はIOGブログに掲載された記事「Time handling on Cardano, part 2: use cases」を翻訳したものです。

カルダノでの時間の使い方【第二部】使用例

by Arnaud Bailly 2022年12月8日

このブログ記事は、Arnaud Bailly、Michael Peyton Jones、Sebastian Nagel、Polina Vinogradova、Brian Bushによって執筆されました。

前回の記事では、Ouroborosがカルダノ上でどのように時間を扱うかについて説明し、決定論の重要性を説明しました。ここでは、カルダノ上の時間に関する具体的な使用例について詳しく説明します。

Plutusスクリプトはどのように時間を処理するのか？

Plutusスクリプトは、作成者によって定義されたトランザクションの有効範囲にアクセスすることができます。有効範囲を定義する際、作成者はトランザクションをスロットXからスロットYまで有効だと決めたり、境界の一方または両方を未定義にしたりすることができます。これはトランザクションがどのスロットに含まれるかという制約を与え、様々な「契約」を定義するためにオンチェーンで非常に有用です。

スクリプトは、バリデーションの実際の時間がこの範囲にあると仮定することができます。そうでない場合、トランザクションはスクリプト実行前にフェー ズ1で失敗します。これは、スクリプトがいつ検証されるかに関係なく、スクリプトが常に同じ情報 (有効範囲)を見るので、動作が同じになり、決定性を保証します。

有効範囲の限界はスロットではなく実時間（POSIXTime）で表現され、スロットから実時間への変換は前回の記事で説明したように合意によって行われます。スロットの長さはハードフォークで変更される可能性があり、スロットのカウントに基づく仮定は一般に信頼できないため、スロットではなく実時間を使用することは重要です。スクリプトが有効範囲を見ることで、スクリプトは「現在の時刻がある時刻の前/後にある」といった主張をすることができるが、それ以外の種類の主張（例えば「このトランザクションが有効である秒数は偶数である」）をすることはできません。

Alonzoのオリジナルデザインでは、有効範囲は既知の時間の使い方をすべてカバーし、既存のTTL（time-to-live）フィールドにもうまく適合しています。理論的には、同じ原則を他の種類のアサーションに適用することも可能です。たとえば、スクリプトをフェーズ 1 でチェックしたアサーションに依存させることができます。しかし、これはカルダノネットワークのさまざまな部分に深い構造的な変更を意味するため、簡単ではないでしょう。また、フェーズ1のチェックはネットワーク上のすべてのノードで有効である必要があるため、「現在時刻」のようなローカルな条件に依存するようなアサーションは除外されます。

時刻の使用例

時刻はカルダノのエコシステムの中でさまざまな用途に使われています。

Hydra

Hydraプロトコルは、プロトコルの安全機構の重要な部分であるコンテストの期限を計算し、強制するために時間に依存しています。Hydra HeadステートマシンはUTCTimeを使って時間の経過を追跡しますが、その刻みはチェーンによって生成されたブロックから観測されたスロット番号に基づき、チェーンからもたらされます。UTCTimeを使用する理由は、有効ウィンドウが課すスロットから時間への変換に固有の制限に対処するためです。あまりに遠い将来のスロットを変換することはできません。つまり、オフチェーンでUTCTimeを使用し、チェーンにトランザクションを送信または受信するときにのみ変換を行う方が単純であるということです。

これはブロックが生成される予想される頻度であるため、tickの粒度がおよそ20秒であることを意味します。この時間の尺度を使えば、Hydraはプロトコルに関連した争奪期限の超過に反応することが可能です。

重要なのは、Hydraヘッド（とノード）のローカル時間はOuroborosが扱うオンチェーン時間と結びついていることです（詳しくはpart 1 参照）。Hydraは同型プロトコルであるため、レイヤ2でも「時間指定取引」を処理することが望ましいでしょう（ issue #196参照）。しかしHydraはブロックを生成しないので、コンセンサス自体に時間の概念は必要ありません（まだ）。

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

もし、あなたが議論に参加し、あなたが持っているアプリケーションの種類と、それらが必要とする解決時間を共有することに興味があるなら、この Hydra Discord channelに参加してください。

Marlowe

Marloweは金融や取引の契約を書くためのドメイン特化型言語（DSL）で、ほとんど全ての契約は時間を伴います。Marloweでは、ACTUSの標準的な契約（ローン、スワップ、オプション、デリバティブなど）のほとんどを含む、さまざまな標準的な金融契約が書かれています。さらにMarloweは、オークションやトークンスワップ、ゲームなど、金融以外のさまざまな契約タイプにも対応しています。カルダノの時間に関する既存のメカニズムは、Marloweのセマンティクスとうまく調和し、Plutusから受け継いだ局所性と決定性をMarloweの取引に提供します。

Marloweでは、コントラクトの時間は通常、コントラクトの実行を制約するデッドラインとタイムアウトに現れますが、これはカルダノの有効期限と完全に連動しています。タイムアウトのロジックは、例えばローン契約において、ローンの支払いが滞った場合に対応するために必要です。その場合、ペナルティを課す、将来の支払いスケジュールを調整するなど、異なるロジックを実行する必要があります。契約はまた、数値計算において有効区間の時間的終点を直接使用することができます。おそらく、早期支払いを受けた時期に基づいて将来の支払額を調整するためです。時間がインターバルとして表示されることは、Marloweではほとんど実用的な影響を及ぼしません。なぜなら、インターバルは、取引を送信してからそれがカルダノネットワーク上のブロックに表示されるまでの時間、つまりわずか数分と同じくらい短いものだからです。

ソリューション

カルダノは、ブロックが鋳造されたブロックプロデューサーからのタイムスタンプ、そのスロットからの変換、あるいはミリ秒精度のUTCでの実際のタイムスタンプなど、トランザクション検証中に、より正確な時間関連データを提供する可能性があります。しかし、この機能を含まないプロトコルと同様に、これは将来の決定論（part 1参照）を破ることになります。つまり、ユーザーはある取引が確実に台帳に適用されるかどうかを判断できなくなるということです。なぜなら、ブロック生成者がブロックを生成する際に使用した正確なタイムスタンプに依存するためです。

もう一つの選択肢は、有効期限を超えた様々な種類のアサーションをトランザクション本体に追加することでしょう。これは可能ですが、先に述べたように難しいです。したがって、これらのアサーションが有用であるためにはユースケースが必要です。

最後に、Hydraのようなレイヤ2ネットワークは、トランザクションの最終処理における遅延の減少とともに、短い「スロット長」と短い有効範囲によって精度の向上を提供することができます。現在のHydra Headの実装は、まだそのようなレベルの柔軟性を提供していないことに注意が必要です。

結論

時間は、特に分散型ブロックチェーンの設定において、複雑なトピックです。これらのブログ記事から、カルダノにはオンチェーンタイムという明確な概念があり、特定の制約と長期的に利用可能な改善オプションがあることがわかります。

オンチェーン時間は、従来のソフトウェアにおける時間とはやや異なる振る舞いをします。この乖離は、エンドユーザーやステークプール運営者のセキュリティとユーザビリティを確保しつつ、システムの制約に対応するために一貫した方法で定義されています。さらに、カルダノの時間の尺度は、伝統的な金融の用途と比較しても、複数のユースケースをカバーするのに十分であると思われます。

Discord community channelsに参加して、カルダノの時間の取り扱いや、これらの投稿で言及されていない潜在的なユースケースについてさらに議論してください。