福岡ブロックチェーンエコノミー勉強会In東京「カラードコインの作り方」

Copyright ©2017 HAW International Inc. all rights reserved.
福岡ブロックチェーンエコノミー勉強会 in 東京
カラードコインの作り方
2017 / 09 / 27
株式会社ハウインターナショナル
安土茂亨

ハウインターナショナル
•Blockchainに関する取り組み
‣2nd Layer技術を中心に研究開発
‣Open Assets Protocolの実装の一つである
openassets-rubyを実装
https://github.com/haw-itn/openassets-ruby
‣BitcoinプロトコルのRuby実装（WIP）
https://github.com/haw-itn/bitcoinrb
•製品・サービス開発
‣Congrechain
‣ブロックチェーンPoC
‣Open Assets Explorer

カラードコインとは？
ブロックチェーン上で任意のアセットを発行し、信頼できる
第三者機関を必要とせず、アセットを転々流通させることが
できる仕組み。Bitcoinとは異なり、発行主体が存在する。
Open Assets Protocol
Elements
Confidential Assets

カラードコインの設計に必要な技術要素
● アセットの識別子
発行された任意のアセットを識別するためのユニークな
識別子の管理とアセットへのリンク
● アセットの量
トランザクションで任意のアセットの取引を行うことができ、
その総量が保証される
● アセットの発行パターン（追加発行の有無）
● アセットに関するメタデータとのリンク（オプション）

カラードコインの実装方法
● オーバーレイ型
既存のトランザクションにOP_RETURNでメタデータを埋め込むことでBitcoin
以外のアセットを表現する実装方法。
通常のBitconのノードから見ると、メタデータが付いているだけのBitcoinの
送金に見え、コンセンサスルールではアセットについて関与しないため、仕様上
無効なトランザクションをブロードキャストできてしまう。
● ネイティブ型
Bitcoinと同様、ネイティブにアセットを取り扱い、コンセンサスルールにも組み
込まれる。コンセンサスルールに組み込まれているため、無効なトランザクショ
ンを作ってもトランザクションの検証に失敗し、ブロードキャストはできない。

Open Assets Protocolの実装パターン

Asset
Asset
トランザクションをオーバーレイ
Transaction
Version
Inputs
...
Outputs
Output 1
Marker Output
Output 2
Output 3
Locktime
オーバーレイ型の実装では、トランザクションを
カラーリングされたトランザクションとして識別できる
ような仕組みを導入するが、Bitcoinのノードからみる
と、その実体はあくまで普通のBitcoinのトランザクショ
ンになる。
アセットの送付先はBitcoinと同様、トランザクションのア
ウトプット単位で制御する。Bitcoinのアウトプットには必
ず少額のBitcoinもセットされており、そのBitcoinの量と
は別にアセットの量をオーバーレイする。
※ Bitcoinの量が0だとUTXOとして認識されないため
カラーリングされたトランザクションがカラーリングされていることは、
そのプロトコルに対応したノード/ウォレットでしか認識できない。

オーバーレイに必要なOP_RETURN
BitcoinのトランザクションのアウトプットにはscriptPubkeyと呼ばれる、
コインのロック条件を記述したスクリプトがセットされている。
一般的なBitcoinを送金するP2PKHのスクリプト
OP_RETURNはスクリプトのOPCODEの１つで、この後ろに任意のデータ
（最大80バイト）をプッシュできる。
※基本的にはトランザクションに付き１つまでで、複数あると非標準トランザクションとみなされ大半
のノードはリレーしない。
scriptPubkeyにOP_RETURNを使うとそのアウトプットは無効なアウトプット
（コインを含まない）として解釈され、ブロックチェーンには記録されるが、
UTXOとしては使用できない。
任意のデータを記録できるOP_RETURNを使って拡張レイヤーを構築する
OP_DUP OP_HASH160 公開鍵ハッシュ OP_EQUALVERIFY OP_CHECKSIG
scriptPubKey
OP_RETURN <任意のデータ>

Open Assets Protocolのトランザクションには必ず
Marker Outputと呼ばれる特殊な出力が１つ含まれ、
Open Assets Payloadが格納されている。
アセットの量の管理
Transaction
Version
Inputs
...
Outputs
Output 1
Marker Output
Output 2
Locktime
OP_RETURN <Open Assets Payload>
フィールドサイズ内容
OAP Marker 2バイト Open Assets Protocolの出力であることを示すマーカーで、0x4f41を指定
Version 2バイト Open Assets Protocolのバージョン番号（0x0100）
Asset Quantityの数 1-9バイト Asset Quantityリスト内のアイテム数
Asset Quantityリスト可変トランザクションで送付されるアセットの量（LEB128でエンコード）
メタデータの長さ 1-9バイトメタデータの長さ
メタデータ可変任意のメタデータ（Asset Definition Pointer等を指定）
※OP_RETURNは任意の80バイトのデータを記録できるスクリプト
Open Assets Payloadで、このトランザクションの各アウトプットに割り当てるアセットの数が決まる。
OP_RETURN 4f41010001e80700
このトランザクションで取引されるアセットの数は1000個で
最初のアウトプットにその量が割当られる
（例）
※ 定義されているのは量のみで、そのAsset IDについてはここでは明示的に定義されていない。

アセットの発行と送付の識別
Transaction
Version
Inputs
...
Outputs
Marker Output
Output 1
Output 2
Locktime
Marker Outputの位置でアセットの発行と送付のアウトプットを制御
Transaction
Version
Inputs
...
Outputs
Output 1
Marker Output
Output 2
Locktime
アセット発行Tx アセット送付Tx
アセット発行用のアウトプット
アセット送付用のアウトプット
あるアセットの新規発行と別のアセットの送付を１トランザクションで行うことも可能

Asset IDの算出方法
Transaction
Version
Inputs
Input 1
Outputs
Marker Output
Output 1
Output 2
Locktime
Transaction
Version
Inputs
Input 1
Input 2
Outputs
Marker Output
Output 1
Output 2
Output 3
Locktime
Transaction
Version
Inputs
Input 1
Input 2
Outputs
Output 1
Marker Output
Output 2
Locktime
Transaction
Version
Inputs
Input 1
...
Outputs
Output 1
Output 2
Locktime
アセット送付Tx
アセット送付Tx
アセット発行Tx
アセットの識別子となるAsset IDは発行Txまで遡り
その入力が参照するアウトプットのscriptPubkeyから計算される
scriptPubkey
scriptPubkeyをHASH160し、エンコードしたものが Asset ID

order based coloring
トランザクションの各インプットが保持しているアセットを、Marker Outputに定義
されている数だけ、順番に各アウトプットに割り当てる方法。
Inputs
Input 0
Asset Quantity : 3
Asset ID : A1
Input 1
Asset Quantity : 2
Asset ID : A1
Input 2
Asset Quantity : N/A
Asset ID : N/A
Input 3
Asset Quantity : 3
Asset ID : A1
Input 4
Asset Quantity : 3
Asset ID : A2
Marker Outputに定義されているAsset Quantity：[10, 4, 4, 1, 2]
Outputs
Output 0
Asset Quantity : 10
Asset ID : A3
Output 1 ( Marker )
Asset Quantity : N/A
Asset ID : N/A
Output 2
Asset Quantity : 4
Asset ID : A1
Output 3
Asset Quantity : 4
Asset ID : A1
Output 4
Asset Quantity : 1
Asset ID : A2
Output 4
Asset Quantity : 2
Asset ID : A2
新規発行アセット

Asset Definition Pointer
OP_RETURN <Open Assets Payload>
トランザクションにはアセットに関するメタデータ（名称、アセットの定義、アイコ
ン、約款など）を十分に定義できるスペースは無いため、アセットのメタデータを
定義したファイルのポインターを、アセットを新規発行するトランザクションの
Open Assets Payloadのメタデータフィールドにセットする。
OP_RETURN 4f410100016417753d68747470733a2f2f676f6f2e676c2f75617043734a
u=https://goo.gl/uapCsJ
各ウォレットやノードは、アセット発行トランザクションの
メタデータをパースして、アセットの情報を表示する。

Open Assets Protocolの実装方法
Open Assets Protocolでは、取引するアセットの量と各アウトプットへ
の割当をMarker Outputで行い、アセットの識別子は発行Txまで遡って
計算することで、アセットの量と識別子を管理している。
【メリット】
● トランザクションに最大80バイトのMarker Outputを挿入するだけなのでとて
もデータ効率が良い。（OP_RETURNなのでUTXOとしても管理されない）
● シンプルなプロトコルで各アウトプットには任意のBitcoin Scriptを使用でき
るため、BitcoinのScriptで実装できるコントラクトは、そのままセットにも適用
できる（Atomic SwapやPayment Channelなど）。
【デメリット】
● 各アウトプットの割り当てられているAsset IDを知るためには、アセットの発
行トランザクションまで辿る必要があるため、SPVでは実装できない。
● Bitcoinのコンセンサスルールとは関係ないため、アセットにとって無効なトラ
ンザクションもブロードキャストでき、その保護は各ノード/ウォレットが負う。

ソフトフォークによるネイティブ実装

ソフトフォークでカラードコインを実装
Johnson Lau氏によるBitcoinをソフトフォークしてカラードコインに対応する提案
https://github.com/jl2012/bips/blob/color/bip-color.mediawiki
【参照実装】
https://github.com/jl2012/bitcoin/commits/color
※ Tweetにあるように、おそらく導入されることはないと思われる。
これからのスライドはその前提でソフトフォークで実装するとした場合の話。

Color Commitmentとアウトプットの拡張
Transaction
Version = 3
Inputs
...
Outputs
Color commitment
...
Locktime
<header> <color tag> <bit field>
フィールドサイズ内容
header 4バイト OP_RETURN OP_PUSHDATA2 0x85 0xad
color tag 32バイトこのコミットメントの対象となるcolorの識別子
bit field 可変トランザクション内のどのアウトプットが
カラーリングされたアウトプットか示すビット列
アセットを送付するトランザクションには、必ずcolor識別子
ごとのColor Commitmentアウトプットが含まれる。
Output
value
scriptPubkey
Output
value
scriptPubkey
color
トランザクションのアウトプットの
構造に color 識別子を表す
256 bit のcolorフィールドを追加
既存のアウトプット構造
各アウトプットにアセットの識別子がセットされるため、出力のアセットが何なのかアウトプットのみで判断できる。
結果SPVノードでもアセットを識別できるようになる。

アセットの発行と識別子
Input
scriptSig
sequence
OutPoint(txid, index)
sequenceフィールドをビット列として扱い、23番目と24番目
のビットでアセットの発行/送付、発行タイプを識別する。
● 23 番目のみビットがセットされている場合
追加発行が可能なアセットの新規発行を意味する。アセットの識別子は
ダブルSHA256(0x00008000 + 入力が参照するUTXOのscriptPubkey)
識別子がscriptPubkeyで構成されるため、同じscriptPubkeyを使えば、
同じ識別子のアセットが発行できる。
● 24 番目のみビットがセットされている場合
追加発行が不可能な不可能なアセットの新規発行を意味する。アセットの識別子
は、
ダブルSHA256(0x00000001 + 入力が参照するUTXOのOutPoint)
識別子がOutPointで構成されるため、一度発行したら、二度と同じ識別子の
アセットは発行できないことが保証される。
● 23番目と24番目両方のビットがセットされている場合
アセットの送付を意味し、この入力のアセットの識別子は、入力が参照する
アウトプットが持つ識別子になる。
"00000001000000000000000000000000"
0x80000000
"00000000100000000000000000000000"
0x00010000
"00000001100000000000000000000000"
0x80010000

コンセンサスルールの追加
トランザクションのversionが3以上の場合、以下のチェックに引っかかるトランザク
ションは無効なトランザクションとしてブロックチェーンに組み入れられることはない。
● インプットのアセット数よりアウトプットのアセット数多くないか
● color commitmentにアセットが割り当てられていないか
● color commitmentのデータ長やcolor tag、bit fieldの範囲が不正でないか
● １アウトプットに複数のアセットが割り当てられていないか
● インプットにアセットがないのに、アセットを送付するbitがセットされていないか
● インプットにアセットがあるのに、新規発行のbitがセットされていないか
● コインベースのアセット手数料が、ブロック内のアセット手数料を超えていない
か
（アセットも手数料としてマイナーが収集することも可能）

ネイティブの実装方法
ネイティブの実装では、トランザクションの各アウトプットのvalueでアセッ
トの量を、アセットの識別子はアウトプットにcolorフィールドを追加して、
それぞれ管理する。
【メリット】
● 各アウトプットにアセットの識別子がセットされるため、SPVノードでもアセッ
トを扱うことができる。
● コンセンサスルールでアセットの検証も行われるため、無効なトランザクショ
ンがブロックチェーンに格納されることなく、ノードレベルで事前にチェックが
できる。
【デメリット】
● 各アウトプットにcolorフィールド（32バイト）が設けられ、データスペースを消
費する。
● アセットのメタデータを定義する仕様は無い。

福岡ブロックチェーンエコノミー勉強会In東京「カラードコインの作り方」

More Related Content

What's hot

Similar to 福岡ブロックチェーンエコノミー勉強会In東京「カラードコインの作り方」

福岡ブロックチェーンエコノミー勉強会In東京「カラードコインの作り方」