バビロンの信頼不要型ビットコイン・ボルト（TBV）を調査する中で、ある点がずっと気になっていました。ツールキットはRust 1.94.1に固定し、再現可能なビルドを要求し、すべての開発者にバイトレベルで完全に一致したバイナリの生成を求めています。バビロンは、誰もがまったく同じ結果に到達するかどうかを重視しているようです。つまり、真のプロダクトは一貫性です。
もし異なる開発者が同じソースから別々のバイナリをコンパイルできてしまうなら、その微妙な差異は、システムが扱うべき別の変数になります。バビロンは、展開（デプロイ）の前に、その変数を取り除きます。1つのソースは常に1つのバイナリを生み、同じ予測可能な挙動を示すべきです。
それが、ボルトのロジックが毎回の環境ごとに作り直されるのではなく、WebAssemblyとしてコンパイルされる理由も説明しています。Rustは安全な実装のまま維持しつつ、WASMによって同じロジックをJavaScriptやTypeScriptのアプリケーションにも活用できます。統合のたびにコアロジックを作り直すのではなく、バビロンは1つの実装を保持し、エコシステムをまたいで再利用します。
エンジニアリング上の判断は、経済戦略のように見えてきました。
バビロンは意図的に「最初に高コスト、後から低コスト」の方針を選んでいます。1つの強固な実装を作り込み、ツールチェーンを固定し、同一の出力を強制することで、最初のビルドのコストは高くなります。しかし、将来のあらゆる統合は、その土台を作り直すのではなく継承できるため、保守負担、実装ごとのバグ、そして長期的なセキュリティリスクを減らせます。
もちろん、この戦略にはトレードオフもあります。
前払いのコストが回収されるのは、十分な数のビルダーが実際にその土台を再利用する場合に限られます。もしエコシステムの採用が限定的なままだと、そのエンジニアリングの規律の多くが、利点ではなく不必要なオーバーヘッドのように終わってしまう可能性があります。
だからこそ、私はTBVのパブリック・テストネットが、「最初に高コスト、後から低コスト」のアプローチが、今後何十もの統合のために同じロジックを作り直すことを最終的に上回るかどうかを証明できるとは思っていません。皮肉なことに、最も強い証拠が現れるのはテストネットの数年後にしかならないかもしれません。ビルダーが同じ土台を継続して再利用するのか、それとも見捨てるのかが明確になる頃です。$RE $BABY #baby @BabylonLabs_io