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

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 によって更新される。

D2（引き出しリスト）

引き出しとは、L2 から（すなわち BIP-300 のロックされた UTXO から）コインを取り除き、L1 に戻すトランザクションである。各 BIP-300 の引き出しは最大 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 数」＞「残りブロック数」）、それは直ちに取り除かれる。

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 が以下のとおりであるとする……

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

……このとき 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 条項ライセンスの下に提供される。