Develop with pleasure!

福岡でCloudとかBlockchainとか。

Colored Coins ProtocolのメタデータのRulesについて

techmedia-think.hatenablog.com
で出てきたColored Coins Protocolのメタデータに定義できるRulesについて。

Rules · Colored-Coins/Colored-Coins-Protocol-Specification Wiki · GitHub

Rules

メタデータに定義されているRulesは、Colored Coins Protocolの特徴的な機能で、カラードコインでスマートコントラクトを実現する可能性を広げる。

Colored Coins Protocolの現在の実装では4つのルールをサポートしている。

  • Fees
    アセットを送付する度に指定されたアドレスに手数料を支払う。
  • Expiration
    アセットの有効期限を設定する。
  • Minters
    アセットの再発行が可能なアドレスを制限する
  • Holders
    アセットを受け取ることができるアドレスを制限する。

↑の4つのルールは、2つのキーとJSONオブジェクトを受け付ける。

Params

関連するパラメータでルール毎に異なる。(以下に各ルール毎に説明)

Inheritance

アセットを送付する際に、どのようにルールが継承されるか指定する。inheritanceフラグには0,1,2を指定することができ、数が大きいほど制限が緩くなりアセットの新しい受信者の自由度が増える。

ざっくりしたイメージが↓

  • 0:Low privilege (Locked)
  • 1:Limited privilege
  • 2:Admin (Open)

Fees

アセットが送付された際に、どのアドレスが手数料を受け取るか決定する。(1つのアセットに複数の手数料のルールがある可能性もある)

デフォルト

デフォルトでFeesルールは空で、ルールはopen(Inheritance=2)。

Params

Feesルールは下記パラメータを指定したJSONオブジェクトを受け取る。

  • amount
    アドレスに支払う必要がある関連するアセットの量。
  • address
    手数料を受け取るアドレス。
  • asset_id
    手数料で支払われるアセットのAsset ID。
    ※ asset_id = 1はネイティブコイン(Bitcoin)のため予約されている。
Inheritance
  • 0:アセットの新しい受信者は手数料を追加することはできない。
  • 1:アセットの新しい受信者は手数料を追加することができるが、Inheritanceレベルは0。
  • 2:アセットの新しい受信者は特に制限なく手数料を追加することができる。
ユースケース

一部のアセットのために分散型の二次マーケットを作成するのはビジネスモデル上の問題がある。アセットを作成しマーケットで販売した場合、発行者は販売したアセットについてマーケット上ではコントール不可能なので、ユーザ間でそのアセットがやりとりされても手数料を取ることができない。このRuleを利用することで企業は、企業が管理する集中型のデータベースの外側で行われる各取引について、不正行為を排除するためにブロックチェーンのセキュリティメカニズムを利用できるようになる。(チケットの転売みたいなことを防ぐことができる?)

Expiration

資産の寿命(有効期限)を決定する。期限に達するとアセットはアセットが有効期限内の最後に保持されていた出力のものとなる。

デフォルト

デフォルトでExpirationルールは空で、ルールはopen(Inheritance=2)。

Params

Expirationルールは2つのパラメータを持つJSONオブジェクトを受け取る。

  • blocks
    ブロック高もしくは範囲を指すエンコードされた整数値
  • range
    以下のいずれかを指すboolean値。
    • range = 0
      blockパラメータにブロックの高さを指定し、それがアセットの有効期限。
    • range = 1
      blockパラメータにアセットが有効期限を迎える範囲Nを指定する。Nはアセットが発行された発行トランザクションからのブロック数。
Inheritance
  • 0:アセットの新しい受信者は有効期限を変更できない。
  • 1:アセットの新しい受信者は有効期限を変更できるが、Inheritanceレベルは0。
  • 2:アセットの新しい受信者は特に制限なく有効期限を変更できる。

※例えば、有効期限が10ブロックでInheritance Flagが2のアセットが転送された場合、アセットの元々の有効期限である10より大きい15といった有効期限は設定できない。従って有効期限の変更でできるのは有効期限の短縮のみである。

ユースケース

時間ベースのアセットは、融資や、鍵のような限られた時間のみアセットにアクセスするようなケースや、指定時間有効なクーポンなど、アセットがライフタイムを有するようなケースでの利用が考えられる。
Airbnbのようにプラットフォーム時間貸しする際の鍵として利用できそう。

Minters

アセットのタイプ(locked, unlocked)に関らず、アセットを再発行可能なアドレスを定義する。

デフォルト

デフォルトでMintersルールは空で、ロックされている。

Params

Minterルールは1つのパラメータを持つJSONオブジェクトのリストを受け取る。

  • addressBitcoinアドレス。このアドレスの秘密鍵を持つユーザであれば、このアセットの発行が可能になる。(このアドレスがアセットを発行したオリジナルの秘密鍵を持っていなくても良い。)
Inheritance
  • 0:アセットの新しい受信者はmintersを追加できない。
  • 1:アセットの新しい受信者はmintersを追加できるが、Inheritanceレベルは0。
  • 2:アセットの新しい受信者は特に制限なくmintersを追加できる。

※パフォーマンスの最適化のため、minterがアセットを再発行する場合、アセットを最初に発行したトランザクションとブロックについてメタデータ内のAsset_Genesisに記載する必要がある。

ユースケース

"Admin"権限を設定されたアドレスに与えることで、より多くのアセットの発行やメタデータの追加が可能になる。
銀行本社が銀行に裏打ちされたUSDコイン(自己宛小切手みたいな)を発行し、同じ銀行の各支店にもそのUSDコインを発行する権限を与えたい場合などに有効。

Holders

このアドレスを保持することが許されているアドレスを決定する。

デフォルト

デフォルトでHoldersルールは空で、ルールはopen(Inheritance=2)。

Params

Holdersルールは1つのパラメータを持つJSONオブジェクトのリストを受け取る。

  • addressBitcoinアドレス。アセットはここに定義されているアドレス群にのみ送付可能で、限られたグループのみがこのアセットの保持を保持できる。
Inheritance
  • 0:アセットの新しい受信者はholdersを追加できない。
  • 1:アセットの新しい受信者はholdersを追加できるが、Inheritanceレベルは0。
  • 2:アセットの新しい受信者は特に制限なくholdersを追加できる。
ユースケース

金融機関のバックボーンとしてパーミッションレスなブロックチェーンを使用するための最大の議論の一つは、企業がAMLやKYCのような規制を順守しながらアセットを制御する能力である。このルールを使えば、事前に確認を取ったアドレス群にのみ有効なアセットを発行できる。つまりパーミッションレスなブロックチェーンにパーミッションレイヤを効果的に作ることができる。

所感

  • ブロックチェーンでアセットを送付する際にRule Engineを適用するってアプローチは面白い。Bitcoinのブロックチェーン上のプロトコルなので、トリガーとできるのはアセットが送付されるタイミングのみっぽい。
  • 定義可能なルールについては分かったけど、ルールを評価するRule Engineがどうやって動作するのかは明記されていない。Colored Coins Protocolをサポートするウォレットでアセットを送付する際に動作するのか?この辺は実装見てみる必要がある。
  • Open Assets Protocolだと発行者の公開鍵からAsset IDが生成されるので、同じアセットを発行できるのはその公開鍵に対する秘密鍵を持つユーザのみだったけど、Colored Coins Ptorotocolの場合はMintersのルールを利用することで、第三者によるアセットの再発行も可能になる。
  • このルールに矛盾するような細工をしたトランザクションがブロードキャストされた場合、どういう振る舞いになるのか気になる。
    ( Open Assets ProtocolだとMarker Outputの値を改竄するとuncoloredと判定されてアセットは消失する。)