規格:Merkle プルーフ データ フォーマット

提案者:スティーブ・シャダーズ (nChain)
TSC スポンサー:ライアン X. チャールズ (Money Button)
著者:(デフォルトの提案者) スティーヴ・シャダーズ
レビュー者:TBA

補足:TSCは、必要に応じてユーザー、実施者、技術専門家および基準専門家をワーキング グループ内で補足的な役割に任命することがあります。

スペシャリスト レビュー者: 法務、IP、コンプライアンス

1. 背景

  1. 問題の説明

    Merkle プルーフとは Merkle ツリーの枝のことであり、そのルートは通常ビットコインのブロック ヘッダーに埋め込まれています。プルーフの実行には、特定のアルゴリズムに従って計算されたデータ要素と共に、供給済みデータ要素の組換えが必要になります。

    Merkle プルーフのフォーマットは、必要なデータを定義するだけでなく、アルゴリズム実行のコンテキスト中においてそのデータを解釈する方法も定義する必要があります。

  2. 目的/正当化

    Merkle プルーフは、オリジナルのビットコイン ホワイトペーパーに述べられている SPV (取引の簡易検証) モデルにとって必須であり、またそれはビットコインのスケーリングを補強します。SPV ウォレットが Merkle プルーフを利用するには、マイナーまたはその他の関係者 (ブロックをすべてダウンロードした人) によって Merkle プルーフがウォレットに提供される必要があります。さまざまな理由により Merkle プルーフを送受信する方法にはさまざまなものがあるので、標準的なフォーマットが採用されればエコシステム全体にわたって実行を簡素化することができます。

    現在の先行技術は FilteredBlock p2p メッセージで具体化されました。これはビット ベクトルとハッシュ リストを使用するものです。 この取り決めはプルーフの逆からの検証を要求するため、不必要なまでに混乱を引き起こします。これは、Merkle ツリーのトランザクションの位置的インデックスを計算するために、簡単なメカニズムが提供されていなために起きているのです。また、この p2p メッセージは、他のメカニズムを活かすために廃れてしまう可能性があります。なぜなら、SPV クライアントにブルーム フィルタを使用することには、内在的なスケーラビリティの問題があるからです。

  3. 範囲

    Merkle プルーフで最も一般的な使用事例は、私たちが SPV (取引の簡易検証) と称するブロックに、トランザクションが含まれていることを証明することです。プルーフそれ自体が、トランザクション、ブロック中のトランザクションのインデックス、そしてプルーフが含まれているブロック ヘッダーのリファレンスといった追加情報を要求することがあります。

    さらに、トランザクションがブロックにまだ含まれていない場合、あるいはトランザクションのための Merkle プルーフがまだ利用可能でない場合、プルーフは、Merkle プルーフの提供対象のトランザクションにおいて、終わっている先祖トランザクションの無傷のチェーンを供給することによって、提供することができます。私たちは、この拡張データ セットのことを「SPV エンベロップ」と仮称しています。これは、Merkle プルーフと追加のデータを含んでいます。そのため、SPV エンベロップは Merkle プルーフ フォーマットそれ自体のスーパーセットになっています。

    私たちは SPV エンベロープを業界のニーズを満たすために不可欠なものと見なしていますが、これは別個に扱わなくてはならないものであり、この基準提案の範囲には含まれていません。従って、そうした基準は Merkle プルーフ要素を、それがどのようにフォーマットされたのかにかかわらず、包含することができます。

  4. 利点

    TSC の使命声明の目標は、「標準化を通じて相互運用性を強化することにより、ビットコイン SV の実用性を向上させること」です。Merkle プルーフは、ビットコインのピア・ツー・ピア的な相互作用の核心にあります。 当然のことながら、そのような相互作用は、別個の、そしてユニークなシステム間の相互運用を要求することになる可能性が高くなります。そのため、Merkle プルーフの標準データ フォーマットを開発する上での主たる利点は、TSC で述べられた目標に沿うものです。そして、それは、基本的に原始的な SPV 運用のエコシステム全体において実装を単純化しなければならなない、というニーズを満たしてくれます。

  5. 成果物

    データ フォーマットについて記述した標準ドキュメント。Merkle プルーフを受け取って実行するための、実行アルゴリズムを含んでいます。

    標準は、バイナリ フォーマットと人間が判読可能なフォーマットの両方で、実装することができる方法を示している必要があります。

2. ワーク グループのプロセスの簡潔な説明

外部:レビュー小委員会で審議する必要のある関心領域についての表明

内部:ドラフト >> レビュー >> 繰り返す (もし必要であれば)。

内部:スペシャリスト レビュー (法務、IP、コンプライアンス) >> ドラフト作成のため繰り返す (もし必要であれば)

外部:パブリック レビュー >> コメントに応答 >> ドラフト作成のため繰り返す (もし必要であれば)

外部:TSC による裁可

3. レビュー者の選出

パブリック レビューのプロセスは、情報提供を希望する人なら誰にでもオープンなものとなっていますが、これはこの基準開発プロセスの後半の部分にある、ということにご注意ください。

  1. 基準

    この TSC ワークグループ レビュー小委員会への参加を希望する人は、以下の基準を満たす必要があります。

    • 以下のうちの少なくとも1つを実証できること。
      1. 標準提案で特定の領域における主題に関して専門知識があること
        • 調査に関連する分野において学士号あるいは同等の経験を持っていること
          • 例:エンジニアリング、コンピュータ科学、数学、その他の関連する科学分野
      2. この基準の結果に関して主たる利害関係者になっている。すなわち、基準の既存のユーザーまたは将来的なユーザー、あるいは基準の実装者。
      3. 国際的に認められた標準機関に関係していて、標準開発において豊富な経験を持っている
    • ワークグループが存続している間、NDA (機密保持契約) を守ること
    • ワークグループが存続している間、レビュー プロセスに取り組めるだけの十分な時間を持っている (ガイドラインとして、ワークグループのライフサイクルは3~4か月の範囲内と予測されていて、通常は数日間のレビュー作業が必要になります。そして、このレビュー作業中、草案の標準を練ることを2~3回繰り返します。)
  2. 申請

    この標準の国際的な開発段階への参加申請は、上記の基準を満たした上でメール ([email protected]) で行ってください。申請は2020年7月3日までに行う必要があります。