Babylon LabsのTBVテストネットがローンチしてから、数日かけてそのバッチ処理の仕組みをひと通り試してみた。最初は、1件のビットコイン取引にHTLC出力を最大10個まで詰め込めるという数字に惹かれた。手数料はほぼ10分の1になり、かなりお得に見えたからだ。しかし、実際にいくつかの取引について、構築から署名、承認まで一通り完了させてみると、コスト削減だけに注目していては、この設計が本当に解決しようとしている問題をほぼ見落としてしまうのだと、少しずつ気づいた。@BabylonLabs_io $BABY
#baby 各出力は依然として、それぞれ独立した保管単位だ。独自のUTXO、事前署名済み取引のグラフ、退出経路を持つ。10個の出力を1つの親取引にまとめるのは、すでに個別に施錠された10個の箱を、一時的に同じコンテナに積んで輸送するようなものだ。輸送費は確かに共有できるが、それぞれの箱の鍵や解錠確認、最終的な帰属は、常に厳密に分けられている。効率化はブロードキャストの段階で共有できる一方、リスクは意図的に切り離されている。この点はテスト中にも特にはっきりと感じられた。同じ取引に複数の出力が含まれていても、それぞれのライフサイクルや緊急退出の仕組みが交差することはまったくなかった。だからといって、オフチェーンでの調整が簡単になるわけではない。サービス提供者が正常に稼働しているときは署名を集めてまとめて送信する。オフラインのときでも、ユーザーはオンチェーンから必要な情報を取得し、自分で入金を完了できる。しかし、償還を拒否された場合は、今も自分でワンタイムキーと証明資料を用意し、単独で対応しなければならない。バッチ処理で本当に圧縮されるのは手数料だけで、安全のための手順は少しも簡略化されない。オフラインの状況も何度か意図的にシミュレーションしてみた。引き継ぎの経路は機能したが、手順はすべて必要で、近道はなかった。だからメインネットに展開された後、私が継続して注目したいのは、手数料がどれだけ節約できたかという表面的な数字ではない。実際のトラフィックにおけるバッチ規模の分布、署名プロセスの完了率、そしてサービス提供者がオフラインになった際、ユーザーが問題を認識してから自力で引き継ぐまでにかかる平均時間だ。この3つのデータこそ、手数料の共有とリスクの分離が、長期運用可能なバランスに達しているかを示してくれる。手数料は共有できても、安全は一人ひとりが自分で守らなければならない。$BTC