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