Epoch#229 | Marloweチュートリアル3章

2020年11月14日 17:51

カルダノの今後を知るために、Marloweとはどういったものか以前調べたのですが、今度はMarlowe Tutorialをみてみました。その中でも6章はGUIベースで視覚的に面白そうだったのですが、まず初めに最初の例のところをみてみました。

3. 最初の例

アリスがボブから猫を買いたいと思ったとしますが、どちらも相手を信用していません。幸いなことに、二人には共通の友人であるキャロルがいて、二人とも中立であることを信頼しています（しかし、彼女にお金を渡して仲介役を務めるほどではありません）。そこで、二人は以下のような契約に合意します。この種の契約はエスクローの簡単な例です。

3.1.簡単なエスクロー契約

When aliceChoice
    (When bobChoice
          (If (aliceChosen `ValueEQ` bobChosen)
              agreement
              arbitrate))

契約はHaskellデータ型のコンストラクタを使って記述します。一番外側のコンストラクタであるWhenは2つの引数を持ちます: 1つ目は観測（observation）で、2つ目は別のコントラクト（契約）です。これの意図する意味は、アクションが発生したときに、2番目のコントラクトが有効になるということです。

二つ目のコントラクトは、それ自体がもう一つのWhen（ボブに決定を求める）ですが、その中には選択肢があります。アリスとボブが何をすべきかについて同意すれば、それが実行され、そうでなければ、キャロルは仲裁して決定するように求められます。

一般的に、Whenはケースのリスト（アクションと、それぞれのアクションが発生したときにトリガーされる対応するコントラクト）を提供します。これを使用することで、下記の様にアリスではなく、ボブが最初の選択をするというオプションを許可することができます。

 When [ Case aliceChoice
             (When [ Case bobChoice
                         (If (aliceChosen `ValueEQ` bobChosen)
                            agreement
                            arbitrate) ],
       Case bobChoice
             (When [ Case aliceChoice
                         (If (aliceChosen `ValueEQ` bobChosen)
                             agreement
                             arbitrate) ]
      ]

このコントラクトでは、アリスとボブのどちらかが最初の選択をすることができます。彼らが同意すれば、それで終わりです。そうでなければ、キャロルが仲裁します。チュートリアルの残りの部分では、アリスが最初に選択するシンプルなバージョンに戻ります。

演習
実際にこのコントラクトを実行することを考えてみましょう。アリスがすでにある程度のお金をコントラクトにコミットしているとします。ボブがそれ以上参加しないことを選んだ場合はどうなるでしょうか？
アリスがすでに支払いを約束していると仮定していますが、それを確実にするためにコントラクトを設計したいと仮定します：何をする必要があるでしょうか？

3.2. Marloweでのエスクロー

Marloweのコントラクトは、適切に進行するように追加の構成要素を組み込んでいます。Whenでは、さらに下記の2つのものを提供する必要があります。

・コントラクトが進行するまでのタイムアウト
・進行する継続コントラクト

3.3. Adding timeouts

まず、Whenの条件が真にならない場合を想定して、今まで書いてきたことをどのように修正するかを検討してみましょう。そこで、コントラクトの中でWhenが発生するたびにタイムアウトと継続の値を追加していきます。

  When [ Case aliceChoice
            (When [ Case bobChoice
                        (If (aliceChosen `ValueEQ` bobChosen)
                           agreement
                           arbitrate) ]
                  60            -- ADDED
                  arbitrate)    -- ADDED
      ]
      40           -- ADDED
      Close        -- ADDED

最も外側の When は、アリスが最初の選択をすることを要求します：もしアリスがスロット 40 までに選択をしなかった場合、コントラクトはクローズされ、コントラクトに含まれていたすべての資金が返金されます。

Closeは通常、Marloweのコントラクトを通る「パス」の最後のステップであり、その効果はコントラクト内の資金を参加者に返金することです。（これについては、後のチュートリアルでMarloweをステップバイステップで見るときに詳しく説明します。）この特定のケースでは、払い戻しはスロット番号40で行われます。

内部構造を見てみると、もしアリスが選択したのであれば、ボブからの選択を待ちます。もしそれが60番スロットまでに来なければ、キャロルが仲裁に入ることになります。

3.4. Adding commitments

次に、コントラクトの第一歩として現金がどのようにコミットされているかを見ていきましょう。

When [Case (Deposit "alice" "alice" ada price)   -- ADDED
(When [ Case aliceChoice
            (When [ Case bobChoice
                        (If (aliceChosen `ValueEQ` bobChosen)
                           agreement
                           arbitrate) ]
                  60
                  arbitrate)
      ]
      40
      Close)
  ]
  10                                      -- ADDED

価格の保証金は「アリス」に要求されます：それが与えられた場合、それはまた、「アリス」と呼ばれる口座に保持されます。このような口座はコントラクト期間中のみ存在し、各口座は1つのコントラクトに属します。

もし入金が行われずにスロット番号10でタイムアウトになった場合、コントラクトは終了し、コントラクトにある全てのお金が返金されます。この場合、コントラクトが終了したことになります。

3.5. Definitions

仲裁、合意、価格など、このコントラクトの記述の一部には、Marlowe DSLのHaskellエンベッディングを使用して、いくつかの省略形の定義を与えていることを、後ほど見ていきます。また、アカウントなどの記述をより簡潔にするために、オーバーロードされた文字列を使用しています。

これらについては、Haskellに組み込まれたMarloweを見るときに詳しく説明します。

演習
タイムアウト値の選択についてコメントし、代替案を検討してください。
例えば、When のタイムアウトが 40 であったのを 60 に置き換えたとしたら、また逆にしたらどうなるでしょうか？それぞれのWhenに同じタイムアウト、例えば100を設定するのは賢明でしょうか？もしそうでなければ、なぜそうしないのでしょうか？

この例では、Marlowe契約言語の多くの構成要素を示しました。次のチュートリアルでは、言語のすべてを紹介します。

3.6. Notes

ここでの例ではアカウント名を手動で提供する必要がありますが、ブロックチェーン上に展開されたMarloweのバージョンでは、ユーザーのウォレットによって生成されることが可能です。

3.7. 詳細を知るための参照先

これらの記事では、関数型プログラミングを使用して金融契約を記述するための原著がカバーされています。

Composing contracts: an adventure in financial engineering
Certified symbolic management of financial multi-party contracts

3章は以上です。

感想としては、プログラミング部分は実際やろうとなると全く別と思いますが、説明があれば何となく文章の様に読めそうな言語だと感じました。

Rewards

Epoch#229になりました！ということで今回(Epoch#227分)の結果です。今回の委任先プールですが、こちらの鯨の項で書いたように、Cardano Foundationが委任を移動したプールへ3エポック前に変更して様子をみています。今回の報酬も新しいプールでの分配になります。

仮定としては委任しているADAに応じて報酬額が決まるので、ほぼ報酬は変わらないはずです。その裏付けを見てみたいと思ったためのプール変更です。（色々な要素はあるので、多少の幅あると思いますが）

自分の委任量ですと、シミュレータによると年間2,056.081174 ADA、ROS: 5.1402%になります。

そして今回のエポックでの結果は下記になります。次の次のエポックで全体結果を改めてみてみたいと思いますが、やはり今までの報酬額の平均くらい？になります。

Epoch: 229
Total Staked: 19.80b (62.10%)
Active Pools: 1,227
Total Stake Addresses: 76,907
Rewards: 32.542 ADA
Total Rewards: 627.691 ADA
ROS: 5.49%
Lifetime ROS: 5.39%

大分ステーク数が増えたと思ったのと、ステークプールオペレータ（SPO）として一番気になるのはActive Poolsです。このまま増えていくのでしょうか？
個人的にはパラメータと分散化の展望へ書いた通り考え方は変わらず、さらに記事が出てきているので勉強しながら、方向性変わらずやっていこうと思います。

プールの飽和量に関して

ステーキングをしている方への重要事項になります。

PoolToolですと下記の様に飽和しそうなプールに目印が付くようになりました。

これは、2020/12/6に飽和量が64Mになるので、それ以上になりそうなプールへの委任は報酬が減るため、委任先を移動することが推奨されています。その点にはお気をつけていただければと思います。

また、ステーク・プール宣伝になりますが、その際には下記SSPへの移動のご検討もお願い致します。

Sugar Staking Pool [SSP]: 私が運営するプールになります。来年の8月まで手数料を0.01%にしていますので、何かのためになったなどあれば、委任のご検討をよろしくお願いいたします。これからも日本語の翻訳など微力ながらも活動を続けていければと思います。

Ticker: SSP
Name: Sugar Staking Pool
Pool id: 5c8751066db31d6745bc8a58ba1534de67a95f9962fc309b4673dd8c

ADA/USDチャート

ようやく雲の上に出てきて、100日移動平均線（上段黄）にチャレンジしているところです。時間をかけて、下は50日移動平均線（上段緑）と200日移動平均線（上段赤）でサポートが固まってきているように見えます。このままいけば緑が黄をうわ抜けそうなチャートをしていて楽しみです。

※ 日足チャートなので長期目線です。あくまで一つの見方なのでトレードは自己責任でお願いします。

最後まで読んでいただき、本当にありがとうございます。
役に立ったと思っていただけたら、スキや、Twitterのフォローをしていただけると幸いです。

よろしければ、過去のブログのまとめページもご確認をお願い致します。（ステークプールの宣伝を含みます）