ビットコイン・インスティテュート
ビットコイン・インスティテュート
English

BIP 300 — ハッシュレートエスクロー​（コンセンサス層）

BIP（ビットコイン改善提案） GitHub · 対象日 · 登録日 · 更新日
人物： ポール・シュトルク ,  CryptAxe
サイドチェーンソフトフォークガバナンス
ポール・シュトルク（Paul Sztorc） 2017年8月14日 
BIP: 300
  Layer: Consensus (soft fork)
  Title: Hashrate Escrows (Consensus layer)
  Authors: Paul Sztorc <truthcoin@gmail.com>
           CryptAxe <cryptaxe@gmail.com>
  Status: Draft
  Type: Specification
  Assigned: 2017-08-14
  License: BSD-2-Clause
  Discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html

概要

BIP-300は、新しい種類のL2を可能にする。そこでは「引き出し」（L2からL1へのトランザクション）が、連合体や固定された公開鍵集合ではなく、プルーフ・オブ・ワークによって統治される。

BIP-300は、正直な利用者にとって正しく行うのが容易で、不正なマイナーにとって悪用が困難な、緩慢で透明性が高く監査可能な引き出しを重視する。BIP-300の主要な設計目標は分割可能性である — 利用者は望むならBIP-300のトランザクションを無視してよく、利用者がそれらすべてを検証しようと、一部だけを検証しようと、まったく検証しまいと、L1にとっては何の違いもない。第二の設計目標は安全性である — L2の利用者は、L2ネットワークが多額の手数料を支払っているならば (https://www.drivechain.info/blog/fees/)、マイナーはそれを維持したいと望むはずであり、したがって引き出しは正確に処理される、と確信できるべきである。

BIP-300がL1とこれらL2との間に「ブリッジ」を確立すれば、利用者はコインを即座に出し入れでき、最終決済にのみBIP-300を用いればよい。この構成により、ビットコインは、ブロックサイズ・ノードソフトウェア・技術スタック・非中央集権化の水準によらず、世界中のあらゆる形・規模のトランザクションを、L1をまったく変更することなく処理できるようになる。

動機

BIP-300により、強力なプライバシー (https://www.truthcoin.info/blog/zside-meltcast/)、惑星規模のスケール (https://www.truthcoin.info/blog/thunder/)、そして年間数千億ドル規模のマイニング収益 (https://www.truthcoin.info/blog/all-world-txns/)を、ライトニングネットワーク (https://www.truthcoin.info/blog/ln-blackpill/)よりもはるかに強力な (https://x.com/Truthcoin/status/1701959339508965405)セキュリティモデル (https://www.drivechain.info/blog/fees/)のもとで達成できる。

本来の動機はリード・ホフマンにまで遡る。彼は2014年にこう書いた (https://blockstream.com/2015/01/13/en-reid-hoffman-on-the-future-of-the-bitcoin-ecosystem/)。「サイドチェーンは、開発者がBitcoin Coreのコードを実際に変更することなく、ビットコインの世界に機能や特性を追加することを可能にする……その結果、単一通貨を持つ共通プラットフォームの相乗効果を失うことなく、より柔軟で分散した形で、イノベーションをより速く起こすことができる。」

詳細はdrivechain.info (http://www.drivechain.info/)を参照。

仕様

概観

BIP-300は、6種の新しいブロックチェーンメッセージから構成される。

  • M1.「新規サイドチェーンの提案」
  • M2.「提案へのACK」
  • M3.「バンドルの提案」
  • M4.「バンドルへのACK」
  • M5. 入金 — メインからサイドへのBTCの移転
  • M6. 引き出し — サイドからメインへのBTCの移転

ノードはこのデータをいくつかのキャッシュ (https://github.com/LayerTwo-Labs/bip300301_enforcer/blob/13a4353c39a26d9d40180ea361b7580fd682e5b5/src/bip300.rs#L79-L96)に整理する。主に以下の2つである。

  • D1.「サイドチェーンリスト」
  • D2.「引き出しリスト」

D1（サイドチェーンリスト）

D1は有効なサイドチェーンの一覧である。D1はM1とM2によって満たされる。フィールド #9と #10はM5とM6によって更新される。

フィールド番号ラベル型説明・目的
1エスクロー番号uint8_tエスクローのID番号。各サイドチェーンを一意に指すために用いる。
2バージョンint32_tバージョン番号。
3サイドチェーン名stringサイドチェーンの人間可読な名前。
4サイドチェーン説明stringサイドチェーンの人間可読な説明。
5Hash1 — tarballハッシュuint256正規のサイドチェーンソフトウェアのtar.gzのsha256ハッシュとして意図される。（これはBIP-300によって強制されるものではなく、人間向けの用途のみである。）
6Hash2 — gitコミットハッシュuint160正規のサイドチェーンノードソフトウェアのgitコミットハッシュとして意図される。（これはBIP-300によって強制されるものではなく、人間向けの用途のみである。）
7Activeboolこのサイドチェーンスロットは有効なサイドチェーンを含むか？
8有効化状態int, int提案の経過（ブロック数）、および「失敗」（サイドチェーンにackしないブロック）の回数。サイドチェーンが有効化された後は破棄される。
9「CTIP」—「TxID」uint256サイドチェーンの資金を保持するUTXO（2つのうち1つ目）。
10「CTIP」—「vout」int32_tサイドチェーンの資金を保持するUTXO（2つのうち2つ目）。

D2（引き出しリスト）

引き出しとは、L2から（すなわちBIP-300のロックされたUTXOから）コインを取り除き、L1に戻すトランザクションである。BIP-300の引き出し1回で、L2での引き出し最大6,000件をまとめて支払うことができ、（L2ごとに）一度に成功できる引き出しは1件のみである。したがって、すべてのL2利用者は同一の大きな引き出しイベントを共有するため、L1側ではこれらの引き出しを「バンドル」と呼ぶ。

D2はM3・M4・M5・M6によって駆動される。これらのメッセージは以下の原則を強制する。

  1. データベースは正規の順序を持つ（早い者勝ち）。
  2. あるブロックから次のブロックへ、すべての「残りブロック数」フィールドは1ずつ減少する。
  3. 「残りブロック数」がゼロに達すると、そのバンドルは取り除かれる。
  4. あるブロックから次のブロックへ、「ACK数」の値は最大1まで増減しうる（M4を参照）。
  5. あるバンドルの「ACK数」が13150以上に達すると、それは「成功」し、対応するM6メッセージをブロックに含めることができる。
  6. あるバンドルのM6が支払われた場合も、それは取り除かれる。
  7. あるバンドルが成功しえない場合（13150 −「ACK数」＞「残りブロック数」）、それは直ちに取り除かれる。
フィールド番号ラベル型説明・目的
1サイドチェーン番号uint8_t引き出し要求を特定のハッシュレートエスクローに紐付ける。
2バンドルハッシュuint256引き出しの試行。具体的には、サイドチェーンから資金を引き出しうるトランザクションの「ブラインドされたトランザクションID」（すなわち、2つのフィールドをゼロにしたトランザクションの二重Sha256。M6を参照）である。
3ワークスコア（ACK数）uint16_tあるバンドルが得たマイナーの支持票の数。0から始まる。増加しうる最速の速度は1ブロックあたり1。
4残りブロック数uint16_tこのバンドルに残された寿命（ブロック数で測定）。26,300から始まりカウントダウンする。

M1 — サイドチェーンの提案

新しいサイドチェーンはM1で提案され、M2でACKされる。

M1は、以下を含むコインベースOP Returnアウトプットである。

1-byte - OP_RETURN (0x6a)
4-byte - Message header (0xD5E0C4AF)
N-byte - The serialization of the sidechain.
  1-byte nSidechain
  4-byte nVersion
  x-byte title
  x-byte description
  32-byte hashID1
  20-byte hashID2

M1は以下の場合に無効である。

  • D1に重複するエントリーを追加することになる。
  • このブロックにすでにM1が存在する。
  • サイドチェーンのシリアライズがパースできない。

そうでなければ:

  • D1に新しいエントリーが追加され、その初期有効化状態は (age=0, fails=0) である。

M2 — サイドチェーン提案へのACK

M2は、以下を含むコインベースOP Returnアウトプットである。

1-byte - OP_RETURN (0x6a)
4-byte - Message header (0xD6E1C5BF)
32-byte - the sha256D hash of sidechain's serialization

M2は、パースできない場合、または存在しないサイドチェーンに対するものである場合は無視される。

M2は以下の場合に無効である。

  • このブロックにすでにM2が存在する。
  • 同一のスロットに対する2つの異なるM1にACKしようとしている。

そうでなければ:

  • サイドチェーンは「ACK」され、このブロックでは「失敗」を得ない（それ以外であれば得ていたはずである）。

サイドチェーンは以下の場合に有効化に失敗する。

  • スロットが未使用の場合: 続く2016ブロックの間に1008回の失敗が蓄積する（すなわち50% のハッシュレート閾値）。
  • スロットが使用中の場合: 続く26,300ブロックの間に13,150回の失敗が蓄積する（すなわち50% のハッシュレート閾値）。

（このため、使用中のサイドチェーンスロットを上書きできる。BIP-300のサイドチェーンは、すでに13150ブロックにつき1回の破局（無効な引き出し）に対して脆弱であるため、このスロット上書きの選択肢は安全性の前提を変えない。）

そうでなければ、サイドチェーンは有効化される（ActiveがTRUEに設定される）。

バンドルによる引き出し

サイドチェーンの引き出しは「バンドル」という形を取る — 多数の個別の引き出し要求を、まれにしか発生しない単一のL1トランザクションへと「まとめ上げる」ことからこう呼ばれる。

L2側では、個別の引き出し要求が定期的に結合され、CoinJoinに似た単一の引き出しバンドルになる。このバンドルは（L2とL1の双方で）特定の方法で (https://github.com/LayerTwo-Labs/bip300301_messages/blob/398b224981c7c236c8354704e655996d33685149/src/lib.rs#L374C1-L419C2)ハッシュ化される — この「ブラインドされたハッシュ」は自身のL1手数料にコミットするが、（注目すべきことに）その最初のトランザクションインプットにはコミットしない（その点でBIP-118 (https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki)に似ている）。

L1のマイナーが3〜6ヶ月かけて緩やかにACKしていくのはこのハッシュであり、M6自体（もちろんいかなるサイドチェーンデータも）ではない。

あるバンドルは、（M6経由で）そのすべての引き出しを支払うか、失敗する（そして誰にも何も支払わない）かのいずれかである。

M3 — バンドルの提案

M3は、以下を含むコインベースOP Returnアウトプットである。

1-byte - OP_RETURN (0x6a)
4-byte - Commitment header (0xD45AA943)
32-byte - The bundle hash, to populate a new D2 entry
1-byte - nSidechain (the slot number)

M3は、パースできない場合、または存在しないサイドチェーンに対するものである場合は無視される。

M3は以下の場合に無効である。

  • このブロックにはすでに当該nSidechain向けのM3が存在する。
  • このハッシュを持つバンドルがすでにD2に存在する。
  • このハッシュを持つバンドルはすでに支払い済みである。
  • このハッシュを持つバンドルは過去に拒否されている。

そうでなければ: M3はD2にエントリーを追加し、初期ACKスコアは1、初期残りブロック数は26,299とする。（D2に追加されること自体が、最初の支持票として数えられる。）

M4 — バンドルへのACK

あるバンドルがD2に入った後、それを有効にするのに十分なACKをどのように与えればよいか？

M4は、以下を含むコインベースOP Returnアウトプットである。

1-byte - OP_RETURN (0x6a)
4-byte - Commitment header (0xD77D1776)
1-byte - Version
n-byte - The "upvote vector" -- describes which bundle-choice is "upvoted", for each sidechain.

M4メッセージは以下の場合に無効となる（そしてそのブロックを無効にする）。

  • 存在しないバンドルに支持票を投じようとしている（たとえば、サイドチェーン #2にバンドルが3個しかないのに、サイドチェーン #2の7番目のバンドルに投票しようとする場合）。
  • いかなるサイドチェーンからのバンドルもまったく存在しない。

M4があるブロックに存在しない場合、それはすべてのサイドチェーンについて「棄権」として扱われる。

M4が存在し有効である場合: ACKされた各引き出しバンドルは、支持票を1票獲得する。

各サイドチェーンは常に2個の「仮想バンドル」を持つ — 「棄権」バンドル（0xFF）と「警報」バンドル（0xFE）である。棄権はACK数を変化させず、警報はすべてのバンドルのACK数をすべて1減らす。

投票を受け取らなかったバンドルは反対票を投じられる（ACKを1失う）。あるサイドチェーンに保留中のバンドルがない場合、M4の作成・パース時にそれは飛ばされる。

実例

サイドチェーン #1の7番目のバンドルに支持票を投じ、サイドチェーン #2の4番目のバンドルに支持票を投じるには、支持ベクトルは { 07, 04 } となる。そしてM4は [0x6A,D77D1776,00,0006,0003] となる。

ブロック900,000のD2が以下のとおりであるとする……

SC番号バンドルハッシュACK数残りブロック数
1h14522,109
1h21222,008
2h31322,999
2h4823,550
2h5222,560

……そしてD2が以下のようになろうとしているとする。

SC番号バンドルハッシュACK数残りブロック数
1h14622,108
1h21122,007
2h31222,998
2h4923,549
2h5122,559

……このときM4は [0x6A,D77D1776,00,0000,0001] であったことになる。

領域の節約

バージョン番号により、多くの場合において支持ベクトルを縮小できる。 バージョン0x00は支持ベクトルを完全に省略し（すなわちM4全体で6バイト）、このブロックのM4を前ブロックのM4と等しく設定する。 バージョン0x01はサイドチェーンあたり1バイトを用い、ACKされたすべての引き出しのインデックスが256未満である間（すなわち99.99% 以上の場合）に使用できる。 バージョン0x02はサイドチェーンあたり2バイトを用いるが、天文学的に起こりにくいケース（複数のサイドチェーンが256個を超えるバンドル候補を持つ場合など）でも常に機能する。 バージョン0x03は支持ベクトルを省略し、代わりに、対抗馬に対して少なくとも50票の差をつけてリードしている引き出しにのみ支持票を投じる。

たとえば、支持ベクトル { 2, N/A, 1 } は [0x6A,D77D1776,01,01,00] として表現される。これは「サイドチェーン #1の2番目のバンドルと、サイドチェーン #3の1番目のバンドルに支持票を投じる」ことを意味する（サイドチェーン #2に提案されたバンドルがない場合に限る）。

支持ベクトル { N/A, N/A, 4 } は [0x6A,D77D1776,01,03] となる。

M5 — BTCの入金（L1からL2へ）

最後に、入金（M5）と引き出し（M6）について述べる。これらはコインベースアウトプットではなく、L1上のトランザクションである。

エスクローアウトプットを使用し、コインの量を増加させるトランザクションを「M5」と呼ぶ。逆に、エスクローアウトプットを使用し、コインの量を減少させるトランザクションを「M6」と呼ぶ。こちら (https://github.com/LayerTwo-Labs/bip300301_enforcer/blob/13a4353c39a26d9d40180ea361b7580fd682e5b5/src/bip300.rs#L462C1-L462C47)を参照。

入金・引き出しが行われるたびに、古いUTXOが使用され、新しいUTXOが1個作成される。（入金・引き出しは決してUTXOの肥大化を引き起こさない。）各サイドチェーンの特定の財務UTXO（「CTIP」）は、常にD1（前述）にキャッシュされる。

すべてのM5は、以下の限りにおいて有効である。

  • OP_DRIVECHAINアウトプットをちょうど1個持つ — これが新しいCTIPとなる。
  • 新しいCTIPは、以前より多くのコインを保持する。

M6 — BTCの引き出し（L2からL1へ）

M6は以下の場合に無効である。

  • M6のブラインドされたハッシュが、承認済みのバンドルハッシュのいずれとも一致しない。（言い換えれば、M6はまず13,150の支持票によって承認されなければならない。）
  • M6の最初のアウトプットがOP_DRIVECHAINでない。（このOP_DRIVECHAINが新しいCTIPとなる。言い換えれば、引き出されなかったすべてのコインはサイドチェーンに払い戻される。）
  • 2番目のアウトプットが、正確に10バイトのゼロ値OP_RETURNスクリプトでなく、その8バイトがシリアライズされたビットコイン額でない。
  • M6のトランザクション手数料が、直前の項目の額と正確に一致しない。
  • 最初の後に追加のOP_DRIVECHAINアウトプットが存在する。

そうでなければ、M6は有効であり、資金は引き出される。

（後半2つの項目の目的は、バンドルハッシュがL1のトランザクション手数料をカバーできるようにすることである。）

OP_DRIVECHAIN

本提案は、使用に厳密な意味論を持つ、単一の新オペコードOP_DRIVECHAINを追加する。OP_NOP5（0xb4）は、スクリプト全体がOP_DRIVECHAINに続けて1バイトのプッシュとOP_TRUE（正確に4バイト）である場合に限り、OP_DRIVECHAINとして再定義される。 この1バイトのプッシュはサイドチェーン番号を含む。 これは「スクリプト番号」ではなく、OP_1..OP_16その他いかなる種類のプッシュにもなりえないことに注意。また符号なしであり、サイドチェーン番号が127を超える場合でもパディングしてはならない。 最後のOP_TRUEは、この変更がソフトフォークであり続けることを保証するためのものである。 これがなければ、サイドチェーン番号0と128は旧来のスクリプトインタープリターを失敗させることになる。

OP_DRIVECHAINインプットが使用される場合、M5またはM6の追加ルール（前述）が強制されなければならない。

後方互換性

本ソフトフォークは、Bitcoin Coreをまったく変更することなく展開できる（すなわちCUSF (https://bip300cusf.com/)経由）。

展開

本BIPは、ハッシュレートの51% 超がエンフォーサークライアント (https://github.com/LayerTwo-Labs/bip300301_enforcer/)を実行したとき（実行すれば）展開される。

理想的には、十分な数の利用者もエンフォーサークライアントを実行することが望ましい — これにより、マイナーがこれを無効化することを強く思いとどまらせることができる。

リファレンス実装

エンフォーサーはこちら (https://github.com/LayerTwo-Labs/bip300301_enforcer/)。

また、いくつかのL2の実例はこちら (https://releases.drivechain.info/)。

著作権

本BIPはBSD 2条項ライセンスの下に提供される。

関連エントリー

原典の外部ソース

https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki

他の外部ソース