時系列の更新履歴を伴うデータをモナパーティのデータベースに記録する。 各データはモナパーティのメッセージに基づき構築されるため、改ざん耐性は、モナコイン・ブロックチェーンの改ざん耐性と同じくなる。
モナパーティを用いた dApps において、時間およびブロックチェーン外の数量を引数とする関数、いわゆるオラクルが必要となる場合が想定される。
PartyAutomation の条件分岐コントラクトである PartyScript は、永続データをそれ自身では保持できない。 引数/返り値となるデータについて、外部のトランザクションを利用する需要がある。
下記データベースの、各レコードで表せるオブジェクト historical_data を、追加する。
CREATE DATABASE IF NOT EXISTS historical_datas (
tx_index INTEGER UNIQUE,
tx_hash TEXT UNIQUE,
block_index INTEGER,
source TEXT,
origin_tx_hash TEXT,
data BLOB,
fee INTERGER,
status TEXT,
FOREIGN KEY (tx_index, tx_hash, block_index) REFERENCES transactions(tx_index, tx_hash, block_index),
PRIMARY KEY (tx_index, tx_hash))
histrical_data を valid にする際には anti-spam fee として XMP が徴収される。
fee := size(data) / 100000
fee は valid を記録する直前に行われ、source であるモナコインアドレスが fee 以下の場合には invalid となる。 invalid となったメッセージからは fee は徴収されない。
historical_data は、target_hash = 0x0 へ、任意長の data を引数とする trigger メッセージが valid となったとき生成される。 historical_data の trigger_id は 0xTBD である。 メッセージは validate を経て、以下のデータを含むレコードとして保存される。
- メッセージを含むトランザクションの tx_hash, tx_index, block_index
- source: メッセージ送信者のモナコインアドレス
- origin_tx_hash: メッセージを含むトランザクションの tx_hash
- data: メッセージに含まれていた任意長のデータ
- fee: valid とするために支払った fee (XMP)
- status:
validまたはinvalid:{失敗理由}
このオブジェクト(レコード)を origin と呼ぶ。
メッセージが invalid になるのは、下記のとおりである。
- fee が足りない。
origin に対し送出した trigger メッセージが valid となったとき、新たなオブジェクトが追加される。 つまりメッセージにしているのは、下記の情報である。
- target_tx_hash: origin したい tx_hash
- data: 任意長のバイナリ
メッセージの結果として、下記の情報が追加される。
- メッセージを含むトランザクションの tx_hash, tx_index, block_index
- source : メッセージ送信者のモナコインアドレス
- origin_tx_hash: target_tx_hash として指定した tx_hash
- data: メッセージに含まれていた任意長のデータ
- status:
validまたはinvalid:{失敗理由}
メッセージが invalid になるのは、下記のとおりである。
- target_hash に相当する origin_txt_hash が存在しない
- message の source が origin の source と一致しない。
- fee が足りない。
ともに get_{table} スタイルの API が提供される。
しかし、data に相当する引数は data_hex に置換され、16進数文字列形式になる。
origin と append とで source が一致しなければいけないのは、悪意ある上書きを避ける目的である。 だが、アクセスコントロールリスト (ACL) を将来的に求める声が出るのは有り得る。 当仕様では、シンプルを第一に考え、ACL は別仕様で検討すべきと決断した。
ここで、append は update ではない点に注意が必要である。historical_data は、値の変更履歴を記録していく。 いわゆる時系列データベースと同じ挙動と見做せる。
historical_data を mutable な値(変数) として用いたい場合は、 origin_tx_hash を同じくし valid なレコード群の中で、transacion_index が最大のものを採れば良い。
API で常に data_hex に変換するのは、データ構造が BLOB なので UTF-8 への変換は考慮不要だからである。
None as it is a new message.
1ブロック内に複数の append trigger が含まれたとき、それらメッセージが解釈される順序は予測がつかない。 これが問題になる場合には、data 内に整列を支援するデータを含める必要がある。
This XMPIP is released under CC0-1.0 and therefore Public Domain.