私は見出しの数からバビロンの3-of-5評議会を見た。すなわち、10の署名連合を示している。次に重要な鍵を1つ外すと、6つのルートが消えた。

明らかなポイントは、定足数（クオーラム）がまだ機能することだ。4つの組み合わせが残る。それが本質的な問題ではない。

隠れた挙動は、BABYのオペレーターが、1人の署名者がオフラインになったときに、その4つのルート間で切り替えられるかどうかだ。同じ人々、ツール、アラート、アクセス・ポリシー、承認プロセスがすべての連合の背後にあり続けるなら、10の数学的な経路は、実務上は1つの経路のように振る舞うかもしれない。

さらに、2つ目のオフライン鍵がこの問題をより明確にする。残った4つの連合は1つに収束する。バビロンは技術的にはまだ稼働しているが、ルートの多様性はもう残っていない。もう1回の障害が不可逆になる。

ある程度の集中は正常だ。小さな評議会のほうが調整しやすく、緊急時の署名が無限に複雑にならないようにもできる。

本当の試験は、数学的な耐障害性と、運用上の耐障害性の違いだ。

代替の連合は事前に承認され、テストされ、プレッシャー下でも到達可能なのか？ BABYは、インシデントがガバナンスの凍結になる前に、署名者をローテーションできるのか？ それともオペレーターは、すでに必要になってから初めてバックアップ経路を見つけることになるのか？

私は1つの障害を「システム障害」とは読まない。とはいえ、バビロンの10のルートが意味を持つのは、緊急が始まる前から本当に独立している場合だけだ。

@BabylonLabs_io #baby $BABY