MonapartyAutomation_Overview
以前もいろいろと頭でっかちに考えたのだが。 昨今の DeFi 狂想曲での使われ方を観察分析すると、
「こういうのでいいんだよこういうので」
って気がしてきている。
「ほー いいじゃないか」かどうかは読者の判断に委ねる。
チューリング完全は Ether とか EOS とか IOST が頑張っているし興味ない。
長期的に見るとハードリアルタイムシステムであるブロックチェーンのトランザクションにおいて、言語レベルでチューリング完全を提供しようと思うのは頭が悪いのでは、とさえ思う。
このコンセプト、他では無いかも。メッセージパッシングの連鎖により、十分な時間をかければチューリング完全になる。 クロック数がやたらと低いだけ。モナコインの採掘間隔がクロック数相当。0.01Hz …。
でもまあこのレベルで十分だろう。ブロックチェーンでパックマン作ろうとか思っているわけではないよね?
登録でも実行でも、もろもろ XMP を消費する。スパム対策として、コントラクトのバイナリサイズ大きいと重課金になるような設計にする(かもしれない)。 え? 「XMP は増えていかないから減ると困る?」…いやいや、だいじょうぶ「XMP は発行され過ぎだ」と草コイン評論家の田中セソセイが憂いていたくらいなので。派手に消費しよう。
新しいメッセージとして contract を追加する。 コントラクト・オブジェクトの生成・クローン・内部状態変化は、contract メッセージを通じて行われる。
各コントラクト・オブジェクトは、外部から変更可能な内部状態 locked および enabled を持つ。
また契約の検証を行うスクリプト言語のコード、検証成功後に送出するメッセージを含む。 これらのデータについては、外部から変更の変更は不可能である。
また、スクリプト言語による検証に先立ち、初期状態として与えるデータをコントラクト・オブジェクトは保持する。 初期状態はコントラクト・オブジェクトの生成時、または生成されたコントラクト・オブジェクトのクローン時に設定でき、その後は外部からの変更は不可能である。
コントラクト・オブジェクトのライフサイクルは、次に示す状態遷移で表される。 内部状態により処理内容が変化するが、いかなる内部状態の組み合わせであっても、ループとなる遷移はない。 いわゆるワンショット・イベントドリブンである。
ライフサイクルの発端となるイベントトリガは次の2種類である。ともに Monaparty Message "contract" が契機となる。
- 秘密鍵の持ち主が、上記フォーマットで作ったトランザクションをモナコインチェーンに send する。
- 既に存在するコントラクト・オブジェクトが、contract メッセージを send する。
Counterparty-server は contract メッセージを受け取った際に、下記の制約条件を満たすかどうかチェックする。
- 登録手数料よりも多くの XMP 残高があるか。
- 対応しているバージョンであるか。
- script 長が制限を超えていないか。
- ペイロードに乗っている Monaparty メッセージは発火に対応しているか。
これら制約条件を満たさない場合、Counterparty-server は、DB に invalid のフラグを立て、実行予定のコントラクトを格納するテーブルには含めない。
Counterparty-server は、valid であるコントラクトに enabled のフラグを立て、コントラクトの実行に備える。 DB には、実行予定の script や message の他に、このトランザクションを含む Monacoin チェーンのブロック番号(origin number)が記録される。 同時に登録手数料となる XMP を回収する。
状態変化メッセージを含むトランザクションの送信にによって、コントラクトの状態を更新できる。 状態変化メッセージは、Monaparty アドレスの保有者、または保有者がデプロイした contract から発行できる。
対象となるコントラクトの Tx Index は、minor version に続く 64 ビットの正整数で与える。
デプロイを試みた際に invalid フラグの立ったコントラクトは、対応するコントラクト・オブジェクトが生成されない。 よって、状態変化メッセージは常に失敗する。
中断(破棄)時には、XMP 手数料は徴収しない。 再開時には、新規デプロイ時ほどではないにしても、XMP 手数料を徴収する。
恒久的にコントラクトを破棄したければ、enabled フラグを false にし、続けて lock フラグを true すればよい。
上記の方法によりコントラクトは破棄できるが、コントラクトを削除する手段は提供されない。 後日の検証可能性を確保するためである。
破棄されたコントラクトもクローンによりサルベージすることができる。 ただしクローンの元と先とで BlockNumber や TxIndex は変わることに留意が必要である。
Major version が 0 となる contract メッセージを、状態変化メッセージと呼ぶ。
minor version が 1 のとき、対象となるコントラクトの enabled フラグは true、0 のときは false となる。 ただし対象となるコントラクトの locked フラグが true のとき、状態変化メッセージは invalid として扱われる。
minor version が 2 のとき、対象となるコントラクトの locked フラグが true になる。 locked フラグはデフォルトでは false である。true にした locked フラグを false にする手段は提供されない。
既にデプロイされたコントラクトの、クローン(複製)を作成できる。 クローン作成は、サブタイプ "clone" を持つ "contract" Monaparty メッセージが契機になる。 クローン指示メッセージは、Monaparty アドレスの保有者、または保有者がデプロイした contract から発行できる。
クローン元とクローン先のコントラクトで、含まれるオペコードは同じである。 しかし、クローン時には、コントラクトが発火した際の Monacoin Script 言語におけるスタックの初期状態を、新たに指定できる。
スタックの初期状態が異なるため、クローンされたコントラクトとクローン元のコントラクトとは異なる挙動を起こし得る。
クローン元のコントラクトの状態がロックされている場合、クローン先のコントラクトもロックされる。 クローン元のコントラクトでは enabled の状態に関わらず、クローン先のコントラクトはデフォルトで enabled となる。 クローン元の状態を disabled にしておくことで、クラス - インスタンスの関係をエミュレートできる。
自己が秘密鍵を所有していないアドレスのコントラクトも、クローンできる。 その場合、クローン先のコントラクトの実行時権限は、クローンを実行したアドレスが有する。
クローン作成の contract メッセージには、Major version として 255 が設定される。
contract のワークフローは「発火→検証→予約→執行」というライフサイクルを経る。 contract のワークフローにもループの発生は可能性は無い。
発火と検証では、成功/失敗があり、失敗した場合には次の段階に進まない。 予約はメッセージのキューイングのみであり、実行環境の物理制約によるものを除き、失敗のしようがない。 執行における成功/失敗の判定は、送信したメッセージの受け手であるハンドラが行う。
一連のライフサイクルにおいて、contract に非決定性の情報が与えられる機会はない。 事実上 finalize されたと見なせるブロックチェーンを reparse した場合には、必ず一意の結果が得られる。
ワークフローの実施に先立ち、「送信元アドレス」が設定される。 ワークフローが予約まで進んだ場合には、メッセージの送信元として送信元アドレス設定される。
発火の原因により、送信元アドレスは下記の 3 通りの設定が有り得る。
- モナコインのトランザクションに含まれるメッセージだったとき、送信元アドレスは、そのトランザクションの送信アドレス。
- クローンではない contract オブジェクトからメッセージだったとき、contract オブジェクトをデプロイしたアドレス。
- クローンの contract オブジェクトからのメッセージだったとき、contract オブジェクトをクローンしたアドレス。
送信元アドレスは、すべてモナコインのアドレスとして有効な文字列となる。
発火は、contruct の評価を行う契機である。
全ての発火において、該当するコントラクトは、下記の事前条件を満たす必要がある。
- enabled であること。
- 送信元アドレスに、コントラクトの実行手数料を払えるだけの XMP 残高があること。
加えて下記する条件が満たされるとき、発火が起きる。 発火に際して、手数料となる XMP が回収される。この XMP は主にスパム避けの目的であり、発行手数料よりは少額となる。
contruct は、Couterparty-server が処理している Monacoin チェーンのブロック番号の下一桁と origin number の下一桁が一致したときに発火する。 つまり平均 900 秒 (== 90 * 10) ごとの発火となる。
発火すべき contract が複数あるとき、発火は、その contract の origin number が小さいものから順に行われる。
send など Monaparty メッセージに対して発火する。 発火は、発火の契機となるメッセージの処理後に行われる。
発火ごとに contract 内にある script の検証が行われる。
script の実行後のスタック・トップが OP_1 (true) になったとき、検証結果は正しく、契約は成立したと見做される。要するにビットコインと同じルール。
script の言語仕様には条件分岐は存在するが、ジャンプやループは含まれていない。 必ず有限時間以内に検証が終了することが、言語仕様のレベルで保証される。
契約が成立したとき、メッセージの執行が予約される。 このメッセージは、デフォルトでは contract メッセージに予め埋め込んだものが使われるが、検証時に動的に作成したものでの上書きもできる。
予約という段階を踏むのは、無限ループの可能性を排除するためである。 (具体例: trigger type が send のとき、執行された送り先に送り元へ send する contract があると、互いに送り合って処理が終わらない。)
送信元アドレスからは処理できないメッセージが予約される可能性もあるが、この時点ではメッセージの有効性は確認しない。 有効性確認は、執行時にメッセージを受け取るハンドラが責任を負う。
予約されたメッセージは、次の Monacoin chain のブロックで執行される。 全ての予約は、Monacoin ブロックから取り出された Monaparty メッセージの処理前に執行される。 執行されるべき予約が複数ある場合は、先に予約されたものから執行される。
執行されるメッセージが valid になるか否かは、各メッセージのルールに従う。 追加の XMP 手数料徴収も、各メッセージのルール次第となる。
検証結果は正しく契約は成立し予約も行われたが、執行に失敗する、というケースは有り得る。 契約の不履行だが、ワークフローの範囲内では、不履行に対する罰則はない。 (メッセージ送信先のハンドラが、不履行に対する罰則を用意していた場合は、ハンドラの処理に委ねる) 予約はあくまでも予約であって完了ではないと見なす必要がある。
(TBD)
254 以下の 1 バイトの自然数、または 0, 255。0 はコントラクトの状態変更を意味する(後述) 現行は 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 を採用しているので、無関係でもない。
作れたとして 2021 年の春とかかなぁ…でもその頃、無職業者 Bot も、その中の人も、忙しくなりそうなのよね…。