読者です 読者をやめる 読者になる 読者になる

Develop with pleasure!

福岡でCloudとかBlockchainとか。

Standards Track BIPのレイヤーの分類を定義したBIP-123

Standards Track BIPのヘッダの項目の1つにLayerがあるが、このLayerについて定義したのがBIP-123↓

bips/bip-0123.mediawiki at master · bitcoin/bips · GitHub

動機

Bitcoinはさまざまな標準を含むシステムで、そのいくつかは相互運用性を担保するのに必須の要件だが、それ以外のものはオプションとみなすことができサポートするかどうかは実装者に委ねられる。この相互運用の要件をより厳密に反映するBIPプロセスを実現するためには、要件に応じたBIPの分類が必要になる。低レイヤーのプロポーザルは標準として受け入れられデプロイするまでに多くの課題があるだろう。

仕様

Standards BIPsは以下の4つのレイヤーに分類する。(上から低レベル層 >> 高レベル層)

  • Consensus
  • Peer Services
  • API/RPC
  • Applications

Standards Track BIP以外のBIPはこれらのレイヤー分類をしてもいいし、しなくてもいい。

Consensusレイヤー

Consensusレイヤーでは、暗号コミットメント構造を定義する。このレイヤーの機能の目的は、誰もがローカル環境で特定の状態や履歴が有効か、セトルメントが保証されているか評価できるようにすることである。

Consensusレイヤーはメッセージがネットワーク上でどのように伝搬するかについては関与しない。

Consensusレイヤーに関する意見の不一致は、異なるノードが互換性のない異なる履歴を受け入れることになりネットワークの分断やフォークを招く可能性がある。

さらにConsensusレイヤーの変更をSoftforkとHardforkに細分化する↓

Softfork

Softforkでは、古いルールで有効だったいくつかの構造は新しいルールの下では有効でなくなる。古いルールで無効だった構造は新しい構造でも引き続き無効である。

Hardfork

Hardforkでは古いルールの下で無効だった構造が、新しいルールの下では有効になる。

Peer Servicesレイヤー

Peer Servicesレイヤーでは、ノードがどうやってメッセージを伝播するか定義する。

基本的なノードの相互運用性には、指定された全てのピアサービスのサブセットのみがあればよく、ノードは将来のオプション拡張をサポートする。

既存サービスとの互換性を損なうことなく新しいサービスを追加したり、古いサービスを段階的に廃止することは可能で、サービス中断の重大なリスクなくネットワーク全体をアップグレードすることができる。

API/RPCレイヤー

API/RPCレイヤーは、アプリケーションからアクセス可能な高レベルの呼び出しを定義する。このレイヤーのBIPのサポートは基本的なネットワークの相互運用には必要ないものだが、特定のアプリケーションによっては求められる場合もある。

このレイヤーでは、基本的なネットワークの相互運用性を損なうことなく、競合する標準を設ける余地がある。

Applicationsレイヤー

Applicationsレイヤーは、異なるアプリケーションが同様の機能のサポートやデータの共有をするための高レベルの構造、抽象化及びルールを定義する。

既存のBIPの分類

BIPのREADMEの表のLayer欄でまとめられてる↓

bips/README.mediawiki at master · bitcoin/bips · GitHub