面白い部分はビットコインのブロックハッシュそのものだと思っていました。ところが、バビロンが想定しているサイズはそちらであることが分かりました。
最初はそれ、ただの実装上の詳細に聞こえます。ブロックハッシュには既知の形式があるので、想定サイズを定義するのはほとんど不要に思えます。しかし、検証ロジックをチェックポイント処理やビットコイン統合と一緒にもっと読み進めていくうちに、見方が変わってきました。
バビロンのようなプロトコルは、意味を変えずに別のチェーンから情報が届くことに依存しています。すべてのチェックポイント、すべての証明、そしてすべてのバリデータ判断は、「処理されるデータがビットコインが実際に生成したものと一致している」という前提から始まります。ブロックハッシュの想定サイズのような基本的な項目を曖昧に扱えば、その上のあらゆる層が追加の不確実性を引き継ぐことになります。
さらに面白くなったのは、バビロンがジェネシスデータを検証し、最初から状態を再構築するやり方と比較した後です。ネットワークは、ほぼ正しく見える情報を拒否するのに驚くほど多くの労力を費やします。というのも「ほぼ正しい」だけで、参加者の間で状態が分裂してしまうからです。小さな検証ルールは、本質的に協調のルールです。
また、運用コストについても考え続けました。可能な限り早い段階で不正な形式のデータを拒否するほうが、検証用ストレージを通してコンセンサスまで進めてからミスに気づくより安く済みます。価値はセキュリティだけではありません。すべてのバリデータにおける、予測可能なリソース使用量につながります。
私は暗号に関するところを調べていき、最終的には「規律」について考えるようになりました。信頼性は、ときに「間違いにつながるのはあと1バイトだけ」というデータを処理することを拒むところから始まるのです。
@BabylonLabs_io
#baby $BABY