興味深い部分は、資金を解放するのに署名者の連合（フェデレーション）を必要としないという約束だと思っていました。ところが実際には、それがシステムに加えるものというより、システムから取り除くもののほうだったのです。
私は、Babylonのステーキング設計を、責任に関する法的な文言やプロトコルのアーキテクチャと照らし合わせ続けました。最初は、それらは無関係な文書のように見えました。それらを一緒に読み進めると、異なる方向から同じ考えを説明していることが分かってきました。
プロトコルがフェデレーションに依存している場合、いずれ誰かが、鍵管理、署名者の利用可能性、アップグレード、緊急時の対応を調整しなければなりません。暗号が健全であっても、機能し続けることができる集団に運用上の依存があるのです。これは、本来インフラであるものの中に組織を作り出してしまいます。
Babylonは、そのような運用上の依存を回避するために、驚くほど多くの設計努力を費やしているように見えます。資金の解放は、委員会が動くのを待つのではなく、プロトコルのルールに従います。これは、参加者が負うリスクの種類を変えます。署名者が協力するかどうかを考えるのではなく、時間の経過とともに、プロトコルのルール、Bitcoinの最終性、バリデータの振る舞いが整合したままでいるかに焦点が移るのです。
Babylon当事者は異なる結果について責任を負わない、という免責条項もまた、アーキテクチャを見た後ではより納得できました。もしフェデレーションが解放を制御しないのであれば、何かが起きたときの裁量的な介入の余地が単純に少なくなります。プロトコルは、自らが踏み込める機会を意図的に減らしているのです。
私は、ドキュメントを読み始めたとき、保管（カストディ）の議論を見つけることを期待していました。読み終えるころには、それらが実際には、失敗する日まで見えにくいままになりがちな調整（コーディネーション）の責任を取り除くことについてのものだと考えるようになりました。
@BabylonLabs_io
#baby $BABY $BANK $LAB