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欄でまとめられてる↓