#baby $BABY
竹竹最近はBabylon Genesisのアーキテクチャをじっくり見ていて、Epoching、Checkpointing、BTC Staking、Finalityがそれぞれ独立したモジュールになっているのが、竹竹にはずっと「賢い分業」だと感じられています。各モジュールが自分の担当範囲だけに集中できるので、問題が起きてもシステム全体を巻き込んで一緒に道連れにならず、原因特定もかなり速い。

ただ、ここ数日前にふと、以前はあまり考えていなかった観点を思いつきました。モジュールをどんどん細かく分解するほど、モジュール「同士」の関係が、逆に新しい隠れコストになりはしないでしょうか？

これは、分業が細かいチームに少し似ています。各人がそれぞれ担当を受け持つので、効率は確かに高い。でも、誰かが業務のやり方を変えようとすると、他の人たちもある程度は歩調を合わせて調整しないと、つながりがうまくいかなくなる。モノリシック（単体）なアーキテクチャは、全部を一人で抱えるようなものです。しんどいのはしんどいけれど、少なくとも他者との整合が取れているか悩む必要はありません。モジュール化はそのしんどさを肩代わりしてくれる一方で、気づきにくいのにずっと存在する、協調コストのようなものを別の形で生み出しているのだと思います。

竹竹は、このコストは合意（プロトコル）が立ち上がったばかりの段階ではほとんど感じにくいと思っています。モジュール数は少なく、更新頻度も高くないので、みんなで少し調整して終わり、となりがちです。でも、システムが十分長く稼働し、機能がどんどん積み重なっていくと、各モジュールがそれぞれ別のバージョンに進化してしまいます。そうしてもなお、すべてのモジュールが円滑に会話（連携）できる状態を保つこと自体が、いつの間にか一種のテクニカルデット（技術債）になっている可能性があります。コード品質の問題ではなく、モジュール間の協調を維持するための複雑さが、時間とともに少しずつ積み上がっていく、ということです。多くの大規模システムが最終的に問題を起こすのは、どこかのモジュールが壊れたというより、こうした「バージョンが噛み合わなくなる」状況で死ぬ、ということが往々にしてあります。

この見方について竹竹は、現時点では完全には検証できていません。Babylonはまだ比較的若く、モジュールのアップグレードに関する実例も十分に多くないからです。ただ、竹竹としては、これは今のうちから注意しておく価値のあるシグナルだと考えています。新機能が次々出るかどうかを見るのではなく、毎回モジュールを一緒にアップグレードするたびに、どれくらいの時間がかかり、どれだけのチームが関わる必要があるのかを見るべきです。その時間がだんだん長くなっていくなら、技術債がゆっくりと姿を現し始めていることを意味しているかもしれません。
@BabylonLabs_io

竹竹からのちょっとした相互質問：技術債って、今の時点で注目すべきですか？