機能ファイルがインターネットを混乱させた時

この投稿では、今週のCloudflareの障害のようなインシデントについての考え方、タイムロック付きの純粋なスマートコントラクトコントロールプレーンが障害モードをどのように変えるか、そしてゼロ知識証明がどこに適合するかについて説明します。

火曜日の障害概要

2025年11月18日 11:20 UTC、Cloudflareのエッジが大量のトラフィックに対して5xxエラーを返し始めました。根本的な原因は攻撃者ではなく、クエリが重複行を返すようにしたClickHouseの権限変更でした。そのクエリは、数分ごとにすべてのエッジボックスに配信されるボット管理の「機能ファイル」を生成していました。

重複によりファイルサイズが倍増し、機能数が200を超えました。ボットモジュールにはハードキャップがあり、オーバーフローでパニックするunwrap()がありました。ノードが5分ごとに「古い良好な」出力と「新しい不良な」出力を交互に切り替えるため、すべてのシャードが更新され不良状態のままになるまで、フリートは振動していました。

Cloudflareは14:24にパブリッシャーを停止し、14:30に最後の既知の良好なファイルを配信し、17:06に完全な復旧を報告しました。彼らが挙げたフォローアップは：内部設定の取り込みの強化、グローバルキルスイッチの追加、およびモジュール全体の障害モードのレビューです。

完全なタイムラインとコードスニペットについては、Cloudflare自身の事後分析を参照してください。

その話には2つの別々の問題があります：

1. コントロールプレーンの障害：ジェネレーターが仕様外のアーティファクト（重複、機能が多すぎる、サイズが大きすぎる）を出力した。
2. データプレーンの脆弱性：コンシューマーが優雅に劣化する代わりにクラッシュした。

（2）はコードレビューで修正できます。しかし（1）はブロックチェーンが輝く場所です：ロールアウトの前に改ざん明示的でプログラム可能なゲートとして。

パブリックブロックチェーン上の「証明付き設定」

アイデアを一文に圧縮すると：スマートコントラクトがそう言わない限り、設定は「現行」にならず、コントラクトはタイムロックとアーティファクトが不変条件に従うという証明の後にのみそのフラグを切り替える。この一文は完全なアーキテクチャを意味しています。

特にイーサリアム、イーサリアム仮想マシンとコンセンサスレイヤーを実行するEVMチェーンに構築されたパブリックブロックチェーンが、その問題に良い解決策を提供することがわかりました。

昇格ゲートとしてのオンチェーン設定レジストリ

• 高速で信頼性のあるEVM（多くの場合L2）上のスマートコントラクトが、各候補アーティファクトと任意の証明へのコミットメントを記録します。
• 書き込みはタイムロックとマルチシグによってゲート制御されます。一時停止/キルスイッチとロールバックポインタはファーストクラスです。
• オンチェーンにはハッシュまたは完全なスクリプトを載せることができます。オフチェーンの場合、ブロブはオブジェクトストアに存在しますが、保証は低くなります。サイズの問題でフルオンチェーンが不可能で、データが一時的な場合はEIP-4844ブロブを使用するのが良いアイデアです。別のストレージですが、真のオンチェーンハッシュと18日間の保持期間を持つブロブをペアにすることができ、これはローリングロールバックウィンドウに最適です。

レイテンシーの適合。 イーサリアムはエポックで確定しますが、L2は数秒で確認します（OP Stackは約2秒を目標とし、zkSyncは約1秒、多くのシステムが高速な証明を公開しています）。5分間のコントロールプレーンのケイデンスには十分です。例えばOPブロック時間の議論やCircleの証明タイミングを参照してください。

必須の証明：ゲートをスマートにする

すべてのアーティファクトに簡潔な証明を添付し、オンチェーンで検証します。これは私たちのChainwallプロトコルで行っていることですが、異なる種類のデータに対してです！

核心的な目標は基本的なプロパティを証明することです：row_count <= 200、キーでソートされユニーク、スキーマが正規表現とタイプルールに一致、ファイルサイズ <= N。ロジック全体をオンチェーンに収めるか、より大きな表現にはPlonk/Groth回路に依存することができます。例えば、zk-VMゲストはCSV/Parquet/JSONを解析してSNARKを出力できます。内容を明らかにする必要はなく、コミットメントだけです。ZKでの正規表現のための研究と本番システムの両方が存在し（例：Reefと関連するzk-regex作業）、これによりスキーマチェックが現実的になります。

実用的な2つの道があります：

• zkVMルート：チェッカーをzkVM内で実行し、オンチェーンでレシートを検証します。RISC Zeroの検証コントラクトとSuccinctのSP1オンチェーン証明ラッピングを参照してください。
• 回路ルート：上記の不変条件のための小さな固定回路。CSV/JSON + 正規表現の場合、解析ガジェットとzk-regex技術を組み合わせることができます。

新しい信頼を導入しない配布

エッジはレジストリをポーリングし、オンチェーンで承認されたアーティファクトのみを採用します。第三者RPCを信頼することを避けるために、コントロールプレーンでライトクライアント（例：Helios）を実行するか、ポータルネットワークを計画します。そうすることで、エッジは「新しい現行」状態を受け入れる前に、ヘッダーとインクルージョン証明をローカルで検証します。

キルスイッチとロールバックはコントラクト内のビットに過ぎず、エッジによって尊重されます。Cloudflareは明示的に、より強力なグローバルキルスイッチの必要性を指摘しました。そのスイッチを小さな監査済みコントラクトに置くことで、ストレス下での単一の真実源が得られます。

これは本当にCloudFlareの障害を変えたでしょうか？

• 重複で膨らんだファイルは、ベストエフォートではなく証明によって強制されるカウント/サイズ制限を突破します。昇格は失敗します。
• 誰かが手動でブロブをストレージにアップロードしても、オンチェーンの「現行」フラグと証明検証なしでは、エッジはそれを採用することを拒否します。
• プロキシでのパニックは修正する必要がありますが、リスクの最も鋭いエッジを、証明システムとタイムロックが非常に優れているドメインに移動させました。

なぜデジタル資産に純粋なオンチェーンコントロールプレーンを主張するのか

CloudFlareのイベントは攻撃ではありませんでしたが、彼らは最初はそう思い、それは確かにありそうでした！暗号セキュリティで見てきたように：攻撃者は鍵を追いかけるだけでなく、コントロールプレーンを強制します。

• フロントエンドまたは署名者UIの改ざん：Bybitの盗難は、署名者が見るものを操作することで、壊滅的な承認を押し通す方法を示しました。分析はフィッシングとトランザクション承認フローのUI操作を指摘しており、スマートコントラクトの悪用ではありません。NCC Groupの技術ノートとLedger Insightsの報道を読んでください。
• 第三者API権限：SwissBorg/Kilnはsolidityのバグではありませんでした。それは攻撃者がステーキング権限を再編成し、Kilnの共同声明で説明されているように約193k SOLを流出させることを可能にしたオフチェーンのAPIパスでした。
• 開発者のラップトップからクラウド認証情報まですべて：Lazarus/TraderTraitorは、侵害された開発者マシンとトリックされたビルドフローがクラウドの足がかりとチームが見て署名するものを曲げる力を買うことを証明し続けています。例えばCISAのアドバイザリーや、AWSの認証情報が開発ボックスからどのように漏洩するかについてのElasticのシミュレーションを参照してください。

結論

私たちの立場：デジタル資産の制御は、プライベート認証情報、CIトークン、クラウドACL、または管理ダッシュボードではなく、タイムロックとマルチシグによって守られたスマートコントラクトに存在する必要があります。デプロイや「所有者変更」アクションが契約のschedule()とexecute()パスを必ず通過する必要がある場合、開発者のラップトップ上のルートキットでもキューをジャンプすることはできません。時間遅延は頼りになるサーキットブレーカーであり、オンチェーン監査証跡は客観的です。残るのは「私たちが推進しているものが不正な形式だったらどうなるか？」という質問だけであり、これはまさに「証明付き設定」が答えるものです。

また、信頼最小化アプリケーションの市場が相当あると信じています。私たちはOKcontract Labsで最初の明確に定義されたユースケースのための適切な基盤を今構築しているだけです。

「機能ファイルがインターネットを躓かせたとき」は元々Coinmonks on Mediumで公開され、人々はこの記事をハイライトして返信することで会話を続けています。