ビットコインのスケーリング問題を解決するため、セカンドレイヤーとして注目を浴びているライトニングネットワークですが、今回はそのライトニングを構成する階層についての解説です。
ネットワークプロトコル
本題に入る前にまずはネットワークプロトコルについて簡単なお話を。インターネットを構成するネットワークはいくつかのプロトコル階層によって定義されています。代表的なものにOSI参照モデルとTCP/IPモデルがあります。実際、私たちがインターネットで検索したり、メールを送ったりする場合、TCP/IPモデルが使われています。OSI参照モデルとは、国際標準機構（ISO）が作った標準規格ですが、実際はTCP/IPモデルが先行し実装・普及していったためTCP/IPモデルがディファクトスタンダードとなっています。この両者のモデルをよく対応（以下の図）させる場合がありますが、これには賛否両論あります（今回はこれについては述べません）。
ライトニングのプロトコル階層
実は、ライトニングネットワークにもこれに対応するようなプロトコル階層があります。以下はBlockstream社から引用してきた図です。左側がモデル名、右側がプロトコル名です。もともとライトニングが発表された時のUpdate層はLN-Penaltyだけしか存在しませんでしたが、今回Blockstream社がeltooというプロトコルを提案しています（ここにeltooの技術詳細が日本語解説してあります）。また、最近提案されたMult-Hop LockはTransfer層に該当すると思われます（ここにMult-Hop Lockの技術詳細が日本語解説してあります）。
モデル – プロトコル – 仕様書の対応表を作ってみました。BOLTはプロトコル階層を意識して作成されていないので、章が前後したり、横断的に記載されたりしています。またEltooやMulti-Hop LockはまだBOLTには取り込まれていません。
| モデル名 | プロトコル | BOLT参照箇所 |
| Payment | Invoice | BOLT11 |
| Multihop | Sphinx | BOLT4 – Onion routing |
| Transfer | HTLC, Multi-Hop Lock | BOLT2, 3, 5 |
| Update | LN-Penalty, Eltoo, Gossip | BOLT5 – LN-Penalty, BOLT7 – Routing gossip |
| Base | Framiing & Feature negotiation | BOLT1 – Framing, BOLT9 – Feature flags |
| Transport | Noise_XK | BOLT8 |
また、ライトニングプロトコル階層をOSI参照モデルと対応づけしたスライドなども紹介されています（引用元はここ）。
カプセル化のメリット
ここでネットワークプロトコル階層に戻りますが、プロトコルを階層化しているメリットには、各階層をカプセル化（隠蔽しお互いが中身を干渉しない）することで、論理的に独立した機能を抽象化することが挙げられます。これにより各階層は独立して設計・開発することができ、このためインターネットプロトコルは成長してきました。
BOLTにプロトコル階層の明記を！
現在、ライトニングは様々な機能が提案、設計、実装されています。仕様書BOLTにそってすべての階層を各社（Lightning Labs、Blockstream、ACINQなど）がそれぞれ個別に実装してしまっているのが現状です。ライトニングネットワークではカプセル化という概念はまだ存在しません。ここで一度仕様書BOLTへ戻り、プロトコル階層を明記し、どの機能がどの階層に属するかが明確になると開発効率も良くなるのではと思っています。今後は各階層がライブラリ化して、それぞれを組み合わせて一つのライトニングネットワーク用ソフトウェアができると良いのではないでしょうか？
コメントを残す