Abstract

時系列の更新履歴を伴うデータをモナパーティのデータベースに記録する。各データはモナパーティのメッセージに基づき構築されるため、改ざん耐性は、モナコイン・ブロックチェーンの改ざん耐性と同じくなる。

Motivation

モナパーティを用いた dApps において、時間およびブロックチェーン外の数量を引数とする関数、いわゆるオラクルが必要となる場合が想定される。

PartyAutomation の条件分岐コントラクトである PartyScript は、永続データをそれ自身では保持できない。引数/返り値となるデータについて、外部のトランザクションを利用する需要がある。

Specification

Object structure

下記データベースの、各レコードで表せるオブジェクト 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))

Anti-spam fee

histrical_data を valid にする際には anti-spam fee として XMP が徴収される。

fee := size(data) / 100000

fee は valid を記録する直前に行われ、source であるモナコインアドレスが fee 以下の場合には invalid となる。 invalid となったメッセージからは fee は徴収されない。

Declare

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 が足りない。

Append

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 が足りない。

API (REST/JSON RPC)

ともに get_{table} スタイルの API が提供される。しかし、data に相当する引数は data_hex に置換され、16進数文字列形式になる。

Rationale

origin と append とで source が一致しなければいけないのは、悪意ある上書きを避ける目的である。だが、アクセスコントロールリスト (ACL) を将来的に求める声が出るのは有り得る。当仕様では、シンプルを第一に考え、ACL は別仕様で検討すべきと決断した。

ここで、append は update ではない点に注意が必要である。historical_data は、値の変更履歴を記録していく。いわゆる時系列データベースと同じ挙動と見做せる。

historical_data を mutable な値(変数) として用いたい場合は、 origin_tx_hash を同じくし valid なレコード群の中で、transacion_index が最大のものを採れば良い。

API で常に data_hex に変換するのは、データ構造が BLOB なので UTF-8 への変換は考慮不要だからである。

Backward compatibility

None as it is a new message.

Additional infomation

1ブロック内に複数の append trigger が含まれたとき、それらメッセージが解釈される順序は予測がつかない。これが問題になる場合には、data 内に整列を支援するデータを含める必要がある。

Acknowledements

Copyright

This XMPIP is released under CC0-1.0 and therefore Public Domain.

cryptcoin-junkey/historical_data.md