BIP157とBIP158の触り
以前触れた通り、NeutrinoはBIP157とBIP158の参照実装となっている。注意しないと行けないのは、この2つはdraft段階であり、まだ議論中のものであること。
ってか、Olaoluwa Osuntokunってよく名前を聞くroasbeefだったんだ。Lightning LabsのCTO。golang使いみたいだから、そういう意味でも注目しよう。
気になるのはBIPで受理されていない実装を Neutrinoが行っているということは、現状この支払いができるのはNeutrinoのみだということだ。こういう場合ってどうなるんだろう。っていうかそもそも、BIP化する場合とかってに実装しちゃう場合ってどう違うの?
BIP157 Client Side Block Filtering
SPVに利用されるbloom filterの持つ課題である、privacyとdos攻撃のリスクを軽減させるために、クライアントサイドでフィルタリングを実施する提案だ。
だから、フルノード側もアップデートが必要で、しかも下位互換性はない。
現在実装されているのはNeutrinoだけだが、bitcoindではいつ頃になるのだろうか。普通、bitcoindに参照実装がなされるのはいつ頃なんだろう。draft段階でやられるのか?とか考えて、
BIPの承認フロー
Acceptedの段階ではいつFinalに移行するかわからないレベルなので、少なくともこの段階では出来上がっていないとまずい。とするとdraft段階でかなり実装されているのがふつうなのかな?
BIP158 Compact Block Filters
実質的には、BIP157とBIP158が合体して初めて新しい SPVの形が完成する。ここでは、ブロックデータのコンパクトなフィルタの構造について定義している。
BIP-37のBloom Filterの代替として提案されたフィルタ構成は、圧縮にゴロム・ライス符号を使用することでフィルタサイズを最小限に抑える。
なぜ既存のbloom filterではだめなのかというと、 こっちでは、各SPVの識別情報を統一してごちゃまぜにする感じだからだと思う。
だけど問題なのは、full node側へのメリットの少なさ。これはpeer serviceのBIPになるわけだけど、承認条件である1%以上のノードが採用っていうのは結構ハードルが高い気がする。それこそneutrino/lndが頑張るっていうシナリオを想定してしまう。