私は、手数料効率を最優先にしたバビロンの「10出力のPre-PegIn」バッチを見ました。10個のバースト出力を1つのトランザクションで運ぶと、よりすっきりしていて、安くつき、スケールもしやすいように見えます。

それが明らかな読み方で、おそらく弱い読み方でしょう。

本当の問題はブロードキャスト後に起きます。各出力はそれぞれ独自のビットコイン支払い経路を持ち続けるかもしれませんが、10個すべてが「時間どおりにクリアされる1回のアクティベーション・イベント」に依存しています。そのペグインが滞ると、BABYは1つの遅延したバーストだけに直面するのではありません。同じライブネス（稼働性）の失敗の背後で、10人のユーザーが待たされる可能性があります。

共有された依存関係は普通です。バッチ処理が存在するのは、10回繰り返すことでエントリのオーバーヘッドが増えてブロック領域を無駄にし、バーストごとのコストも上がるからです。効率性は本物です。

ただし試されるのは遅延下での振る舞いです。バビロンは出力ごとの回復を切り分けられるのか、それともトランザクション単位の問題がバッチ全体をまとめて拘束してしまうのか。締め切りが縮まり始めたとき、誰がどう反応するのでしょうか。1つのトランザクションに紐づく大きい絶対的な手数料があることで、再送はよりつらくなるのでは？

これは、手数料効率と失敗の集中のトレードオフです。

BABYは、バッチ化によってエントリコストを下げつつ、1つの運用ミスを10個のバーストの待ち行列に変えない限り成功です。私はまだ、気になる一点を見ています。別々の支払い経路が、別々のライブネスを保証するわけではない、ということです。

バビロンはここで容量を節約できるかもしれません。より難しい問題は、それが独立性を保つかどうかです。
@BabylonLabs_io #baby $BABY