翻
@BabylonLabs_io のTBV文書を読んでいるとき、最初に詰まったのは収益ロジックではなく、もっと基礎的な技術的疑問でした。ビットコインのスクリプトにはCovenant(契約)がそもそもないのに、Babylonはなぜメインネットで条件プログラマブルな、無信任の金庫を作れるのか?最初は、ある程度ビットコイン本体に手を入れるのだと思っていました。たとえばソフトフォークでも起こしてから、改めてアーキテクチャを説明するのかなと。しかし読んでみて、私の考えが複雑すぎたと分かりました。
本当に椅子に深く座らせたのは、制約を回避する(というより、うまく回す)発想でした。BitcoinスクリプトにCovenantがないということは、「このUTXOは将来どう使えるのか」という原生のオンチェーン制約を張れないことを意味します。Babylonは合意レイヤーのアップグレードを待たずに、制約を前倒しします。つまり、事前署名トランザクション(pre-signed transactions)によって資金がロックされた瞬間に、将来許可される支払い経路を先に列挙して署名してしまう。条件を満たさない経路は、そもそも有効な署名が取れない。要するに「契約」をスクリプト層から、署名の段階へ移したわけです。
$BABY この流れをさらに追うと、もう一方が状態証明です。事前署名だけでは支払い経路の問題を解決するに留まり、外部アプリケーションが、金庫が今どの状態にあるのか、どの経路を辿るべきかを確認できません。Babylonは状態証明によってVaultの状態変化を検証可能なものにし、条件付き支払いの判断に根拠を与えます。この組み合わせは、文書を何度も行ったり来たりしながらようやく整いました。事前署名が「将来どう使えるか」を管理し、状態証明が「いまどんな状態か」を管理する。両方が揃って初めて、プログラマブルな条件付き支払いが成立します。
#baby この巧妙さを前提に、いくつかのポイントはしっかり押さえておく必要があります。事前署名では、許可される経路が設定時点ですでに列挙されてロックされるため、後から新しいシーンを追加したいなら、再署名や再調整が必要になり、柔軟性は厳密さとの交換になります。さらに、多者による事前署名の調整コストや鍵管理の複雑さといった要素は、ホワイトペーパーには明記されにくいものです。実際に大規模にスケールしたときに、そうした暗黙のコストが本当の試験になります。
結局のところ、Babylonがいちばん賢いのは、「ビットコインを改造する」という遅くて危険な道に手を出さない点です。メインネットを変えず、ソフトフォークも求めずに、既存の署名メカニズムと証明メカニズムを再編成して、プログラマブルな金庫を組み上げた。これは典型的なエンジニアリング上の節制です。能力は下層を改造して得るのではなく、既存の原語(プリミティブ)を組み替えて引き出すのだと示しています。この道が実際の資金と大規模な同時実行に耐えられるかは、メインネットのデータが語るのを待つ必要があります。
#BitVM