MonapartyAutomation_Overview
以前もいろいろと頭でっかちに考えたのだが。 昨今の DeFi 狂想曲での使われ方を観察分析すると、
「こういうのでいいんだよこういうので」
って気がしてきている。
「ほー いいじゃないか」かどうかは読者の判断に委ねる。
チューリング完全は Ether とか EOS とか IOST が頑張っているし興味ない。
長期的に見るとハードリアルタイムシステムであるブロックチェーンのトランザクションにおいて、言語レベルでチューリング完全を提供しようと思うのは頭が悪いのでは、とさえ思う。
このコンセプト、他では無いかも。 メッセージパッシングの連鎖により、十分な時間をかければチューリング完全になる。 クロック数がやたらと低いだけ。モナコインの採掘間隔がクロック数相当。0.01Hz …。
でもまあこのレベルで十分だろう。ブロックチェーンでパックマン作ろうとか思っているわけではないよね?
登録でも実行でも、もろもろ XMP を消費する。スパム対策として、メッセージのバイナリサイズ大きいと重課金になるような設計にする(かもしれない)。 え? 「XMP は増えていかないから減ると困る?」 …いやいや、だいじょうぶ「XMP は発行され過ぎだ」と草コイン評論家の田中セソセイが憂いていたくらいなので。派手に消費しよう。
Monaparty message などを契機として副次的に行われる処理、またはその処理単位を、 automation と呼ぶ。 automation には後述するライフサイクルがあり、一連の処理結果として自動的な契約の検査及び執行(いわゆるスマートコントラクトに相当)を行うこともできる。 しかしながら、実際の契約履行は、Monaparty の組み込みコントラクトが行うため、automation という別の用語を当てている。
本仕様は、新しい Monaparty message として automation を追加する。
valid な automation message により、Monaparty runtime は automation object を生成する。
アプリケーション開発者またはアプリケーション自身が automation object の内部状態を変更する際に、別途仕様化される trigger message を利用できる。
automation object は、名が表すとおり、オートメーションの処理に必要な情報が含まれているオブジェクトである。
各 automation object は、その作成契機となった Monaparty message を含む Monacoin transaction の tx_hash により識別される。
automation object に含まれるパラメータは下表のとおりになる。
| parameter | immutable? | default value |
|---|---|---|
| owner | yes | the sender of "automation" or "trigger (clone)" massage |
| public_clonable | yes | false |
| enabled | no | false |
| locked | no | false |
| prestack | no | (empty) |
| contract | no | (empty) |
| message | no | (empty) |
| tx_index | yes | set by the runtime |
| tx_hash | yes | set by the runtime |
| block_index | yes | set by the runtime |
| message_index | yes | set by the runtime |
| start_block | yes | 0 or specified by the message |
| end_block | yes | 0 or specified by the message |
| period | yes | 0 or specified by the message |
この automation object の所有者アドレス。 trigger message のバリデーション時、また contract 評価後に送出されるメッセージの送信元アドレスとして使用される。
owner 以外のアドレスからの clone を許可する場合 true を設定する。
true の場合、発火要求以外のすべての trigger message を invalid とする。
結果として、一度 locked == true になった automation object は locked == false に戻せない。
contract 評価前のスタックの状態を保持する。
contract で評価される Monaparty Script を保持する。
contract が valid だったとき、デフォルトで実行キューに push される Monaparty message。
この automation object が生成された時点でのチェーンの状態。contract から参照可能。
automation object 生成の契機となったメッセージを含むトランザクションの tx_hash。 automaiton message または trigger message に紐づく。 automation object を一意に識別するものであり trigger message の target_hash として用いられる。
オートメーション・オブジェクトのライフサイクルは、次に示す状態遷移で表される。 内部状態により処理内容が変化するが、いかなる内部状態の組み合わせであっても、ループとなる遷移はない。 いわゆるワンショット・イベントドリブンである。
ライフサイクルの発端は Monaparty message "automation" である。
Monaparty runtime は automation メッセージを受け取った際に、下記の制約条件を満たすかどうかチェックする。
- 登録手数料よりも多くの XMP 残高があるか。
- パラメータに不備がないか
これら制約条件を満たさない場合、Counterparty-server は、トランザクションの DB に invalid のフラグを立て、automation object を生成しない。
automation object の生成時には登録手数料となる XMP を回収する。 create 時の automation object の内部状態は下記のようになる。
valid な trigger メッセージによって automation object の状態を更新できる。
trigger メッセージのうち、下記に該当するものは例外なく invalid となる。
- trigger メッセージに含まれる target_hash で識別される automation object が存在しない。
- 指定した automation object の owner address と trigger message の sender address が一致しない。
注: デプロイ時に invalid フラグの立った automation メッセージには、対応する automation object が生成されない。 よって、そのメッセージが持つ tx_hash を target_hash として指定した trigger message は常に失敗する。
trigger メッセージにより automation object パラメータを更新できる。
下記列挙する条件を満たす場合、は、上掲の表における immutable? == no であるものに限定される。
ただし、locked == true が設定された automation object に対する update 要求は、Monaparty runtime が invalid とする。
update 時には手数料として XMP を徴収する。
Monaparty runtime は、enabled == false である automation object を、コントラクトの発火対象から除外する。
automation object を enable/disable にするための trigger message に対し、XMP 手数料は徴収されない。
恒久的にオートメーションを破棄したければ、enabled フラグを false にし、続けて lock フラグを true すればよい。
上記の方法により automation object は破棄できるが、automation object を削除する手段は提供されない。 後日の検証可能性を確保するためである。
破棄された automation object もクローンによりサルベージすることができる。 ただしクローンの元と先とで tx_hash は変わることに、留意が必要である。
既にデプロイされたオートメーション・オブジェクトの clone を作成できる。 clone は、元となる automation object を識別する tx_hash を target_hash とする、trigger message が契機になる。
public_clonable == true である automation object への trigger message は、任意の送信者アドレスに対し valid となる。
public_clonable == false である automation object への trigger message は、automation object の owner とメッセージの送信者が一致しない場合 invalid となる。
clone 時には、automation object の prestack を、trigger message に含まれるものでアトミックに上書きできる。 初期データにより生成されるスタックの初期状態が異なるため、clone で生成された automation object は、元となる automation object と異なる挙動を起こし得る。 clone 先の automation object が保持する public_clonable, enabled および locked の値を trigger message を介してアトミックに変更できる。
clone の契機となる trigger メッセージの送信者は、生成された automation object の owner となる。
clone により生成された automation object は、clone の契機となった trigger message の tx_hash により識別される。
(T.B.D) Major version が 0 となる automation メッセージを、状態変化メッセージと呼ぶ。
minor version が 1 のとき、対象となるオートメーション・オブジェクトの enabled フラグは true、0 のときは false となる。 ただし対象となるオートメーション・オブジェクトの locked フラグが true のとき、状態変化メッセージは invalid として扱われる。
minor version が 2 のとき、対象となるオートメーション・オブジェクトの locked フラグが true になる。 locked フラグはデフォルトでは false である。true にした locked フラグを false にする手段は提供されない。
生成された automation object の owner は immutable である。つまりオートメーション・オブジェクトは他のアドレスに譲渡できない。自らは秘密鍵を持たないアドレスへ譲渡できたとすると、不正送金など悪意ある利用が可能となるリスクがある。
類似のリスクがある "clone" については、下記の理由で機能として提供される。
- pull 型の行為であり事前の十分なチェックの上で使用するという防御ができる。
- 初学者向け雛形の提供、factory パターンを用いたアプリケーション、など、利便性のあるユースケースが見えている。
automation は「発火→検証→予約→執行」というライフサイクルを経る。 オートメーションのライフサイクルにもループの発生は可能性は無い。
発火と検証では、成功/失敗があり、失敗した場合には次の段階に進まない。 予約はメッセージのキューイングのみであり、実行環境の物理制約によるものを除き、失敗のしようがない。 執行における成功/失敗の判定は、送信したメッセージの受け手であるハンドラが行う。
一連のライフサイクルにおいて、オートメーションのワークフローに非決定性の情報が与えられる機会はない。 事実上 finalize されたと見なせるブロックチェーンを reparse した場合には、必ず一意の結果が得られる。
ワークフローの実施に先立ち、「sender address」が設定される。 ワークフローが予約まで進んだ場合、Monaparty runtime は、 sender address とメッセージを queue に積む。
発火の原因により、送信元アドレスは下記の 2 通りの設定が有り得る。
- モナコインのトランザクションに含まれる trigger message だったとき、送信元アドレスは、そのトランザクションの sender address。
- automation object からの trigger message だったとき、automation object の owner アドレス。
送信元アドレスは、すべてモナコインのアドレスとして有効な文字列となる。
詳しい読者への補足: Monaparty automation では、EOA とコントラクトアドレスの区別はありません。
発火は、contruct の評価を行う契機である。
全ての発火において、該当するオートメーションは、下記の事前条件を満たす必要がある。
- enabled であること。
- 送信元アドレスに、オートメーションの実行手数料を払えるだけの XMP 残高があること。
発火には「タイマー発火」「メッセージ発火」の2種類がある。 発火に際して、手数料となる XMP が回収される。この XMP は主にスパム避けの目的であり、発行手数料よりは少額となる。
Monacoin のブロック高が下記条件を満たしたとき、発火が起こる。
contruct を含む automation の生成時に設定された、start_block, cycle, end_block に対し
ブロック高 block が start_block + cycle * n でありかつ start_block <= block < end_block を満たす。
発火すべき automation が複数あるとき、発火は、その automation の message_index が小さいものから順に行われる。
send など Monaparty メッセージに対して発火する。 発火は、発火の契機となるメッセージの処理後に行われる。
発火が失敗しなかった場合、オートメーション・オブジェクト内にある script を用いた検証が行われる。
script の実行後のスタック・トップが OP_1 (true) になったとき、検証結果は正しいと見做される。 要するにビットコインと同じルールである。 ただし、ビットコインとは異なり、この時点で契約は成立しない。
script の言語仕様には条件分岐は存在するが、ジャンプやループは含まれていない。 必ず有限時間以内に検証が終了することが、言語仕様のレベルで保証される。
検証結果が正しいとき、メッセージの執行が予約される。 このメッセージは、デフォルトでは automation メッセージに予め埋め込んだものが使われるが、検証時に動的に作成したものでの上書きもできる。
予約という段階を踏むのは、無限ループの可能性を排除するためである。 (具体例: trigger type が send のとき、執行された送り先に送り元へ send する automation があると、互いに送り合って処理が終わらない。)
送信元アドレスからは処理できないメッセージが予約される可能性もあるが、この時点ではメッセージの有効性は確認しない。 有効性確認は、執行時にメッセージを受け取るハンドラが責任を負う。
予約されたメッセージは、次の Monacoin chain のブロックで執行される。 全ての予約は、Monacoin ブロックから取り出された Monaparty メッセージの処理前に執行される。 執行されるべき予約が複数ある場合は、先に予約されたものから執行される。
執行されるメッセージが valid になるか否かは、各メッセージのルールに従う。 追加の XMP 手数料徴収も、各メッセージのルール次第となる。
検証結果は正しく予約も行われたが、執行に失敗する、というケースは有り得る。 契約の不履行だが、ワークフローの範囲内では、不履行に対する罰則はない。 (メッセージ送信先のハンドラが、不履行に対する罰則を用意していた場合は、ハンドラの処理に委ねる) 予約はあくまでも予約であって完了ではないと見なす必要がある。
(TBD)
254 以下の 1 バイトの自然数、または 0, 255。 現行は 1 のみ。(Monacoin Script ver.1.x) 将来、スクリプトのバージョンが上がった際にはインクリメントされる。
1 バイトの正整数。インクリメントされるが、major version がインクリメントされた際には任意の数値に成り得る。(大抵は 0 にリセットされる)
1 バイトの正整数。 このオートメーションが発火する契機を指示する。現在想定にあるのは、下記の条件となる。
- timer (Monacoin チェーンのブロック数間隔で発火)
- message (オートメーションの所有者のアドレスが絡む Monaparty メッセージの発生直後に発火)
Monacoin Script。これは BitcoinCash Script に若干の独自拡張を加えたもの。 最大長は 128 バイト。とりあえず。
OP_RETURN から始まる例のアレ、の、OP_RETURN を省いたヤツ。script が正常終了したときに実行される。 オートメーション・ランタイムのバージョンにより扱えるメッセージが異なる。
このプランは Monascript と直接の関係は無い。けれども、BitcoinCash Script を採用しているので、無関係でもない。
オートメーションが発行したメッセージの TxID をどうするかはちょっと悩みどころ。保留。