チェーン上で異なるコンセンサスの実行を可能にする拡張方法「Extension Block」

最近、LitecoinがMimblewimbleを導入するLIP（Litecoin版BIP）が提案された↓

• https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki
• https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki

Litecoinは元々Bitcoinのアルトコインであるため、根本的にブロックチェーンの構造が異なるMimblewimbleを導入するのはBitcoin同様難しい。そこでLitecoinがMimblewimbleを導入するために採った方法がExtension Blockという拡張方法だ。

Auxiliary Block

Extension Blockのアイディアはもともと、2013年にJohnson Lauがハードフォークを必要とせずブロックサイズを増やす方法として提案したものだ↓

https://bitcointalk.org/index.php?topic=283746.0

提案された1MBのブロックサイズを増やすAuxiliary Blockの仕組みは、

1. 各ブロック毎にメインのブロックとは別にAuxiliary Blockが作成される。Auxiliary Blockヘッダーを持たないブロック。
2. OP_NOP1をOP_AUXとして再定義する。
3. 誰かがBitcoinを<serialized script> OP_AUXというscriptPubkey宛に送金するまでAuxiliary Blockは空のまま。この形式のscriptPubkeyが現れると、Auxiliary Blockにコインベースのようなトランザクションが作成され、ロックされたBitcoinが送られる。Auxiliary Blockのマークルルートはメインブロックのコインベースに含まれる。アップグレードされたノードはBitcoinがメインチェーンから補助チェーンに正しく転送されているかどうか確認する。（なお、OP_AUXのトランザクションを含まないブロックではAuxiliary Blockは作られない。つまりAuxiliary Blockのチェーンは形成されない）
4. 補助チェーンでもメインチェーンと同様Bitcoinの送金ができ、マイナーもメインチェーンと同じ仕組みを使って手数料を徴収することもできる。唯一の違いは、補助チェーンにはコイン生成の報酬が無いということ。メインチェーン側で<serialized script> OP_AUXにコインを送金した場合のみ、補助チェーン上でコインが生成される。
5. 補助チェーンからメインチェーンにコインを戻す場合は、補助チェーンのコインを<serialized script y> OP_AUX OP_RETURN形式のscriptPubkeyに送金する。マイナーはこの送金を検知し、メインチェーン上でOP_AUXのUTXOをランダムに選択し、同じコインの量だけメインチェーン内の<deserialized script>宛に送金する。

というもの。この仕組みでは以下の後方互換性が担保される：

• 旧ノードには補助ブロックのデータが表示されないので、補助ブロックのサイズは自由に決められる。
• OP_AUXのアウトプットは旧ノードにとって誰もが使用可能なanyone can spendなUTXOとしてみられるので、旧ノードはそのまま動作可能。
• 上記のルールに従わずOP_AUX UTXOのコインを盗もうとしても大多数のマイナーにより上記がアクティベートされていれば、その行為は拒否される。
• 旧ノードは作成するブロックにOP_AUXトランザクションを含めたり引き換えたりしない限り、引き続き有効なブロックをマイニングできる。

この仕組みを利用すると、ブロックサイズに限らず本来ハードフォークを必要とする変更も、ソフトフォークで実現することができる。

そしてExtension Blockとして2017年1月に実際にBitcoinへのソフトフォークとして提案されたのが↓

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html

LitecoinのExtension Block

Litecoinでは、LIP-0002としてMimblewimbleをLitecoinに導入するためにExtension Blockを導入する提案が出ている。この提案は、OP_AUXのようなopcodeを追加するのではなく、2017年にBitcoinで提案された内容の用に、新しいwitness versionを使った導入になる。

Peg-in

標準チェーンのコインをExtention Blockのチェーンに移動する場合、ユーザーはPeg-inトランザクションを作成する。Peg-inトランザクションは、EB側のブロックチェーンに送金したいコインを新しいwitness program宛に送金するトランザクション。

新しいwitness programにコインを送金するPeg-inトランザクションが作られると、そのPeg-inトランザクションが含まれるブロックに対応するEB側のブロックにおいて、同量のコインを持つコインベーストランザクションが作られる。witness programの値はEB側のコインベーストランザクションの送金先へのコミットメントになる（Mimblewimbleの場合、witness programはEB側のコインベーストランザクションにセットされるカーネルコミットメントを指定するっぽい）。なお、対応するEBのブロックに対応すコインベーストランザクションが存在しない場合、標準チェーン上のPeg-inトランザクションは無効とみなされる。

Peg-inトランザクションにより標準チェーンからEB側のチェーンにコインが移動するので、標準チェーンでは当然移動したコインはEB側から戻ってくるまでロックされなければならない。そのため、Peg-inトランザクションで作成されたUTXOは、マイナーにより収集され、同一ブロック内に作成されるインフレーショントランザクション（後述）で使用される。

Peg-out

Peg-inとは逆にEBのチェーンから標準チェーンにコインを移動する際にはEBチェーン上でPeg-outトランザクションを作成する。Peg-outトランザクションは標準チェーン上で同量のコインの送金先であるLitecoinアドレスへコミットする。

Peg-outにより標準チェーン上で利用可能になったコインは、標準トランザクションのコインベーストランザクションのコインと同様、使用できるまで一定期間ロックされる。これはチェーンの再編成に対応するため。

インテグレーショントランザクション

標準チェーン上でEBへのPeg-in、EBからのPeg-outを処理するために作られるのがインテグレーショントランザクション。インテグレーショントランザクションはマイナーによってブロック毎に１つ作成されるトランザクションで、ブロック内の最後のトランザクションとして配置される。

インテグレーショントランザクションは、X+1個のインプットとY+1個のアウトプットを持つ。Xはブロック内のPeg-inトランザクションの数で、Yはブロック内のPeg-outトランザクションの数。

• インプット
  • 最初のインプットは前のブロックExtAddr UTXO（後述）。
  • X個のインプットはブロック内のPeg-inトランザクションのUTXOを集めたもの。基本的に対応するEB内に同じ数のコインベーストランザクションが作られる。これらのコインは新しくEB側のチェーンに移動するコインであるため、標準チェーン上では他で使用されないようこのトランザクションでインプットとして使用される。
• アウトプット
  • 最初のアウトプットは、このブロックにおけるEB側のコインの合計量を持つExtAddrアウトプット。インプットには前のブロックのExtAddrとこのブロックでEB側に移動したコインの合計があるので、そこからこのブロックでEB側から標準チェーンに戻ってきたコイン（このアウトプットの後に続くPeg-out分のコイン）を差し引いた量がこのブロック時点でのEB側のコインの総量になり、その総量を全てこのExtAddrにロックすることになる。
  • Y個のアウトプットは、EB側のチェーンから標準チェーンに移動してくるコインのアウトプット。このアウトプットはEB側のPeg-outトランザクションでコミットされたLitecoinアドレス宛のアウトプットになり、対応するEB側のブロック内のPeg-outトランザクションの数と同じだけのアウトプットが作成される。

ExtAddr

ExtAddrは、EB側のチェーンに移動したコインを標準チェーン側でロックしておくためのアドレスで、以下のフォーマットのscriptPubkeyになる。

ExtVer <eb_commitment>

ExtVerの値はおそらくEB毎に異なるものと思われる（例えば今回一緒に提案されているLIP-0003のMimblewimbleのEBでは「ExtVer」の値は0x09とされている）。

witness programの部分は2〜40バイトのeb_commitment。このデータは対応するEBのブロックへのコミットメントになる。LIP-0003だと、EBのブロック内のトランザクションカーネルとそのブロック時点のUTXOセットのデータから作られるコミットメントになる。

基本的に１ブロックあたりそのインテグレーショントランザクション内で１つのExtAddrが作られ、そこにEBに移動したコインの総量がロックされることになる。

EBに対応してしない旧ノードから見ると↑のscriptPubkeyは誰もが使用可能なアウトプットと認識される。

手数料

EB側の手数料は基本的にインテグレーショントランザクションの手数料として標準チェーン側で徴収される。

所感

以上が、Extension Blockを利用した拡張方法。

• Extension Block側のチェーンの仕様は自由に決められるので（EBのブロックサイズも自由に決められるし、トランザクション構造もまったく異なる仕組みが利用できる）、既存のコンセンサスにとらわれない拡張が可能なのは大きい。
• サイドチェーンライクでもあるけど、サイドチェーンと違って
  • Peg-in/outが単一のチェーンのコンセンサスとして担保されており、この点は重要。
  • EB側のブロック生成の手数料報酬も標準チェーンのコインとして入手できる。
• 一方、サイドチェーンと違って単一チェーンのフルノードとしての検証コストは増える。これはフルノードの分散化への影響があるのと、経済的な観点からマイナーによる導入の支持がどうなるか？という別の課題が生まれる。EB側のチェーンの報酬は手数料収入だけなので、標準チェーンとEB側のチェーンで手数料レートが変わる可能性も考えられる。

ちなみに、↑のExtAddrを利用してブロック単位で別のコインを管理する手法は、似たようなアプローチが以前、Confidential TransactionをBitcoinにソフトフォークで導入する際にも使われており↓、設計方法の１つとして他にも利用できそう。

techmedia-think.hatenablog.com