最近、複数 Agent が協調する自動化プロセス一式を設計していて、作れば作るほど、
@OpenLedger の「何千もの Agent が互いに自動で呼び出し、決済し合う」というビジョンがセクシーに聞こえる一方で、実装すると致命的なエンジニアリング上の危険が隠れていると感じています。それは「障害のカスケード(連鎖)伝播」です。
まずは私の実際のシナリオから。手元には3つのマイクロサービスがあります。A はオンチェーンのデータを取得し、B はそのデータをクリーニングして構造化されたリサーチレポートにし、C はそのリサーチレポートに基づいて意思決定を行います。中央集権型のシステムなら、各段階にタイムアウト、リトライ、サーキットブレーカーを付けられます。A が落ちれば、C はすぐにそれを検知して劣化モードへ切り替え、汚れたデータを掴んだまま暴走することはありません。このフォールトトレランス機構は、ローカルで何度も何度も調整してようやく安定させたものです。
しかし、この仕組みを OpenLedger の分散ネットワークに持ち込むと、難易度が一気に制御不能になります。Agent C が Agent B からレポートを自動購入し、B がさらに A に対してデータ料金を自動で支払う――この一連の呼び出しは完全自動で、人の監視も介在しません。そこで問題です。A 側のノードが突然、停電・回線断・ダウンに見舞われたら、チェーン上の障害はどのように伝播するのでしょう?
最も恐ろしいのは、A が完全に落ちるのではなく、「一見正常に見えるが実際には汚れたデータ」を返してくるケースです。B はそれを疑わず、言われるままに清掃してリサーチレポートとして受け取ります。C は、その汚れたデータに基づくリサーチレポートを手に、ためらいなくオンチェーンで真水の現金(実資金)を伴う取引を実行します。何かがおかしいと気づいた時には、損害はすでに発生しており、しかも完全自動実行なので、誰もタイムリーに停止ボタンを押せません。
$LAB 中央集権型システムなら、私はいつでも監視し、遮断し、ロールバックできます。しかし、完全自動実行でブラックボックス化された分散ネットワークでは、誰も、その疾走するチェーンの「手術」をしてくれません。たとえシステムが後からスマートコントラクトで A のデポジットを没収(Slash)して補填できたとしても、今回のカスケード故障によって私のビジネスはすでに致命的な停止状態に陥ってしまいます。
ですから客観的に言うと、OpenLedger の Agent コンポーザビリティ(組み合わせ可能性)という方向性は正しいと思います。確かに、マシン経済のトレンドを突いています。ただし「データが失われても損害賠償できる」だけでは到底足りません。真面目な商用用途に必要なのは「1秒たりともリンクが間違えない」ことです。自動決済のカッコよさだけを見て終わらせず、故障耐性とカスケード遮断に関する実際の設計を多方面から検討してください。中立に様子見して、DYOR。
#BTC #OpenLedger $OPEN @OpenLedger