Develop with pleasure!

福岡でCloudとかBlockchainとか。

Asset Definition Protocolの仕様(訳)

Open Assets Protocolの仕様(訳) - Develop with pleasure!
Open Assets Address Formatの仕様(訳) - Develop with pleasure!

と続いて最後にAsset Definition Protocolをざっと訳す。
Asset Definition Protocolというのは、Open Assets Protocol上に構築されるプロトコルで、Open Assets Protocolを用いて発行されたアセットにメタデータを関連付けるためのプロセス。

動機

Open Assets Protocol を介して発行されたアセットは、既存のブロックチェーンの枠組みとは別に値を持つことができる。発行者はエンドユーザにアセットとそのアセットに付加される条件について周知できる必要がある。ユーザがアセットの発行者を信頼するかどうか決めるように、発行者は自身の身元を証明することも大切になってくる。

これらは全てクライアントのソフトウェによって透過的に処理される。このドキュメントではそこでどのような処理がされるのか説明する。

仕様

メタデータを関連付けるプロセスは↓の3つのステージからなる。

  • Blockchain association
    発行者によってアセットが定義されたURLがブロックチェーンに埋め込まれる。
  • Asset definition file
    Asset definition fileが生成され、指定されたURLで利用可能になる。
  • Proof of Authenticity(オプション)
    発行者の身元を証明するためSSLが使用される。
ブロックチェーンとの関連付け

アセットを発行すると発行者は、asset definition pointerと呼ばれる文字列を使って、アセットとメタデータファイルを関連付けることができる。
asset definition pointerは↓のフォーマットで記載される。

u=<asset definition URL>

もしくは、

u=<asset definition URL>&sha256=<sha256 hash>

もしくは、

 h<binary hash160> (21 bytes)

↑のasset definition URLと書かれてる箇所にはasset definitionの絶対URLが定義され、sha256 hashはオプションでasset definitionの16進表記のSHA-256ハッシュが定義される。両方とも必ずURLエンコードしておく必要があり、asset definitionはUTF-8エンコードしとく必要がある。

2015.09.19 追記
hで始まるコンパクトフォームは、Marker Outputの40バイト制限への考慮と、アセットを交換する当事者のプライバシー保護が目的となっている。コンパクトフォームは、RIPEMD-160(SHA-256(asset definition))として定義されているBitcoinのHash160関数を使用する。asset definitionの指定にコンパクトフォームが使われている場合、クライアントは1つもしくは事前に定義されたロケーションからデータをフェッチする必要がある。それらのロケーションにあるのは一般的によく知られた資産追跡サーバもしくは、特定のアプリケーションや特定のasset IDためのサーバの可能性がある。

asset definition URLは、有効なURLスキーマ(http,https,ftp,magnet,safe)を利用することができ、クライアントはどのサブセットを使うか自由に決められる。

アセットにasset definition pointerを関連付けるには↓の2つの方法がある。

  1. アセットを発行する際に、marker outputのmetadataフィールドに保存する方法。
  2. Pay to Script Hash(P2SH)を使ってアセットを発行する。このredeem scriptは↓のような構成になっている。
PUSHDATA(<asset definition pointer>) OP_DROP [remainder of the script]

1の方法では、asset definition pointerはアセットの再発行時に変更することが可能になる。2の方法では、asset definition pointerが発行用のスクリプトの一部となっているため、asset IDを変更しない限りasset definition pointerを変更することはできない。

アセットに関連付けられるasset definition pointerを決定する

指定されたアセットの現在のasset definition fileは以下のプロセスでクライアントにより決められる。

アセットが発行された際に入力スクリプトがredeemに使われるように、アセットを発行した出力スクリプトが決まる。(この出力スクリプトのハッシュはasset IDとイコール)

↓の条件を満たす場合

  1. 出力スクリプトがPay to Script Hashのスクリプトである
  2. 該当するredeem scriptはPUSHDATAから始まりOP_DROPが続く。
  3. PUSHDATAのペイロードが有効なasset definition pointer(↑のBlockchain associationで定義した)である

PUSHDATAのペイロードはasset definition pointerと判断され、ここで関連付けが決まる。

そうでない場合は

  1. 最初のインプットからスクリプトや有効なOpen Assetsのmarker outputの全てのトランザクションBitcoinのブロックチェーンから取り出される。
  2. marker outputのmetadataフィールドが空(0 byte)のトランザクションは除外される。
  3. これらのトランザクションはブロックチェーン上の順番で保持される。もしそのようなトランザクションが無い場合、そのアセットにはメタデータは関連付けられていない。
  4. 残ったトランザクションのmarker outputのmetadataフィールドはasset definition pointerになる。そのasset definition pointerの書式が正しくない場合、そのアセットにはメタデータは関連付けられていないことになる。
Asset definition file

asset definition pointeが決まると、指定されたURLに格納されたファイルが検索される。asset definition pointerのハッシュによるファイルは検証され、該当するファイルが見つからない場合、もしくは検証でハッシュと合致しない場合は、そのアセットにメタデータは関連付けられていないものとして扱われる。

JSON形式のAsset definition fileの例↓

    {
      "asset_ids": [
        "<base 58 asset id>"
      ],
      "name_short": "<string>",
      "name": "<string>",
      "contract_url": "<url>",
      "issuer": "<string>",
      "description": "<string>",
      "description_mime": "<mime type>",
      "type": "<string>",
      "divisibility": <integer>,
      "link_to_website": <boolean>,
      "icon_url": "<url>",
      "image_url": "<url>",
      "version": "<string>"
    }

各フィールドの定義は↓

フィールド 説明
asset_ids (必須)このAsset definition fileの使用を承認されたBase58エンコードされたasset IDの配列。クライアントは処理するアセットのasset IDがこの配列内に存在するかチェックする必要がある。asset definition pointerがP2SHを使ってブロックチェーン内に保存されている場合、このリストに含まれるべきasset IDは循環依存問題を回避するため、(最初のPUSHDATAとOP_DROPを除いた)remainder scriptによってのみ計算できる。
name_short (必須) USD, MSFT, BTCのようにこのアセットの量(金額)を呼称するためのticker。このフィールドの値が10文字を超える場合、クライアントはアセットの定義を拒否することができる。
name (必須)このアセットの名前。
contract_url このアセットに関する詳細情報のURL。エンドユーザからアクセスできる必要がある。
issuer 発行者の名前。クライアントは(未検証であるため)この値を表示しないという選択も可能。
description このアセットの説明。クライアントは最低でも4096文字はサポートする必要がある。
description_mime descriptionフィールドを解釈するためのMIME typeでデフォルトは”text/plain”。クライアントはどのMIME typeをサポートするか選択可能。
type このアセットのタイプ。
divisibility このアセットが小数点以下の桁数の量を持つことができるかを示す符号付き整数。これにより量をどのように表示するかが変わる。表示される量は、asset quantityを10^divisibilityで割ったものとある。(divisibilityが2ならasset quantity / 10^2になる)
link_to_website proof of authenticityを使用するかどうかを決めるBoolean値。falseが設定されるとSSL証明書が有効になっていてもproof of authenticityは無効となる。
icon_url アセットのアイコンのURL。アイコンの画像ファイルは48x48ピクセルであるべきだけど、クライアントはその他の形式も多分サポートする。
image_url アセットの画像URL。画像ファイルは少なくとも幅が260ピクセル以上である必要はあるけど、クライアントは必ずしもその規格でなくてもサポートする。
version Asset definition formatのバージョンであり、1.0と定義する必要がある。

フィールドの順序は特に関係なく、もしファイルが有効でない場合はメタデータは現時点でアセットには関連付けられない。

Proof of Authenticity

Proof of Authenticityは発行者の身元を証明しアセットに関連付けるオプショナルな手段で、asset definition URLがhttpsを使用する場合のみ利用可能。

クライアントはメタデータファイルを参照する際、Webサーバから提示されるSSL証明書のsubjectフィールドを抽出する必要がある。このsubjectがアセットの発行者として使われる。

クライアントはアセットのメタデータファイルを取得する際に、HTTPのリダイレクトに従う必要があるが、フルリダイレクトチェーンはproof of authenticityを有効にするためHTTPSを使用する必要がある。加えて、リダイレクトの場合、最後のリソースのSSL証明書がproof of authenticityに使用される。

論理的根拠

asset definition は発行者の裁量で書き換え可能であるため、発行者はasset definition fileのハッシュを提供する必要は無い。
アセットメタデータは発行者によって情報提供のためだけに提供されており、発行者が特に指定しない限り、裁判における契約強制力とみなすべきではない。法的拘束力のある契約の枠組みを提供するのはこの仕様の範囲外である。