727 Financeインシデントは資産だけでなく、信頼も奪う。暗号資産はこのままではいけない。我々自身で救わなければならない。
著者：Robert Mao、ArcBlockの創業者兼CEO
本記事は、業界が自らを救うためのこの呼びかけをより多くの人々に見てもらいたいという願いから、誰でも自由に複製・転載することを許可しています。
暗号資産はこのままではいられません。度重なる大規模な窃盗は、資産だけでなく、参加者の業界全体に対する信頼も奪っています。私たちは自らを救わなければなりません。
2026年10月29日、Binanceで重大なセキュリティインシデントが発生しました。同社の予備発表によると、約63億ドル相当の資産が影響を受け、影響を受けた資産のうち約30億ドルが凍結されたと推定されています。調査は当初、あるDevOpsエンジニアのノートPCを指摘し、その後、他の侵入可能な箇所も発見されました。Binanceはまた、ウォレットの秘密鍵の漏洩を示す証拠は見つかっていないと述べています。影響額は最終的な純損失ではなく、攻撃チェーン全体は依然として調査中です。[[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
この取り組みは、EthereumやSolanaなどのブロックチェーンプロジェクトのビルダーに向けたものであり、またBinance、Coinbase、Kraken、そして参加を希望するすべての取引所、ウォレット、プロトコル、セキュリティビルダーに向けたものです。共に資産を保護するための基盤を再構築しましょう。私は参加する用意があり、より多くの人々が共に行動することを望んでいます。
これだけでも十分に重いものです。しかし私がより懸念しているのは、この事件がCryptoに対する信頼をどれほど破壊し、どれほどの攻撃者にこの業界を依然として攻撃し続ける価値のある標的と見なさせるかということです。たとえ最終的に誰かが損失を負担したとしても、補償はユーザーの信頼を自動的に修復することはできず、同種の破壊が再び起こるのを止めることもできません。
Binanceは、今日私たちが問題に直面せざるを得なくなった入り口にすぎません。目をそらせば、取引所、ブリッジ、オンチェーンプロトコル、ウォレットは長い間、傷跡を長く残してきました。新しいネットワークや製品が次々と現れる一方で、古い失敗の様式が何度も何度も繰り返されています。私たちは発表を出し、しばらく待ち、そして次のインシデントを日常として扱うことはできません。
私たちはまた、詐欺や、構築に対する責任を負わず概念を生み出すだけの慣行が、あまりにも長い間この業界を害してきたことを認めなければなりません。技術とインフラを真剣に構築するチームもまた、失われた信頼の結果を共に負わなければなりません。人々がCrypto全体を詐欺と見なす頃には、本当に守る価値のある技術と探求もまた、それと共に放棄されるかもしれません。
ArcBlockの創業者であり、CryptoとBlockchainの実践者として、私はそのような結末を受け入れることはできません。私はこの業界には守る価値のある価値があると信じており、また私たちは自らのセキュリティ基盤に対して責任を負わなければならないと信じています。もし私たちが引き続き受動的に次のインシデントを待ち続けるなら、繰り返される出血は最終的に私たちが共に築いてきたすべてを破壊するかもしれません。では、このイニシアチブを提起したい。取引所、ウォレット、ブロックチェーンの構築者は、資産管理とセキュリティ検証の基盤を共同で再構築し、単一の侵入による被害範囲を制約すべきである。以下のタイムラインは、なぜ変更が必要かを説明するものであり、続く技術提案は、我々が着手できると考える作業である。
2008年、サトシ・ナカモトはピアツーピア電子現金システムを提案し、支払いを信頼できる仲介者への依存からより独立させようと試みた。[[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) しかし、それ以降の主要なインシデントは、資金、認可、ソフトウェア依存関係が再び集中化する問題を繰り返し露呈させてきた。
以下は、中央集権型取引所（CEX）、分散型取引所（DEX）、ブリッジ、ウォレットなどの分野における代表的なインシデントの時系列リストである。完全なインシデントデータベースでも、年ごとの損失統計でもない。金額が記載されている場合、それはインシデント発生時点の概算総影響額を指す。盗難、凍結、その後の回収は別々に記述され、恒久的な損失として合算することはできない。
2008年 · ビットコイン・ホワイトペーパー
出発点
ビットコイン・ホワイトペーパーは、金融機関を仲介者としないピアツーピア決済を提案した。
出典
2011～2014年 · Mt. Goxの長期的な盗難
CEX
Mt. Goxは長期的な盗難に遭い、最終的に営業を停止した。後の米国司法省の起訴状は、2011年から2014年の間に約647,000 BTCが盗まれたと主張した。これは2014年の単日攻撃ではなかった。
出典
2012年 · BitcoinicaとBitfloor
CEX / カストディアル・インフラ
BitcoinicaのLinodeホスティング環境が侵害され、同年、Bitfloorの暗号化されていないウォレットバックアップが攻撃の入口となった。プラットフォームの背後にあるサーバーとバックアップもまた、資産セキュリティ境界の一部である。
出典
2015年 · Bitstampのホットウォレット
CEX
Bitstampのホットウォレットが侵害され、運用環境はその後再構築された。インシデントの範囲とオフライン準備金の公式な区別は、分離がエクスポージャーの範囲を制限できることを示した。
出典
2016年 · Bitfinex
CEX
約120,000 BTCがBitfinexから盗まれた。マルチシグの取り決めであっても、エンドツーエンドの独立した認可と検証が必要である。
出典1 · 出典2
2016年 · The DAO
オンチェーン・プロトコル
The DAOコントラクトはリエントランシー攻撃を受け、約360万ETHがサブDAOに移され、その後イーサリアムのフォークを引き起こした。正当な実行パスが壊滅的なビジネス結果を生み出す可能性がある。
出典1 · 出典2
2017年 · Parity共有ウォレットライブラリ
コントラクト・ウォレット
Parity共有ウォレットライブラリが破壊され、約513,000 ETHが凍結された。たとえ送金されなくても、共有コード依存関係のために資金が使用不能になる可能性がある。
出典
2018年 · Coincheck
CEXCoincheckのNEMホットウォレットが盗難された。オフライン準備金、ホットウォレットの権限、業務上の必要性の境界が再び問題となった。
出典
2019 · Binance
CEX
Binanceは7,000 BTCが単一のトランザクションで引き出されたと発表した。大規模な資産流出は署名前に制約される必要がある。
出典
2020 · KuCoin
CEX
KuCoinホットウォレット事件。その後、多者間の協力により大量の資産が回収された。盗難総額と最終的な損失額は同じ数字ではない。
出典
2021 · Poly Network
クロスチェーンプロトコル
約6億1,200万ドル相当の資産がPoly Networkから移転され、その後段階的に返還された。クロスチェーンの認可と資産管理は通常の業務経路のみでは維持できない。
出典
2022 · Roninブリッジ
ブリッジ
Roninのバリデータ権限が侵害され、173,600 ETHと2,550万USDCが移転された。複数のバリデータの鍵も同一の攻撃チェーンに陥る可能性がある。
出典
2022 · Slopeウォレット
ウォレット
SolanaエコシステムにおけるSlopeウォレット事件。Solana公式は、秘密鍵情報が誤ってアプリケーション監視サービスに送信されたと述べた。Solanaのコンセンサスが侵害されたわけではない。
出典
2023 · Euler
レンディングプロトコル
プロトコルの脆弱性により約1億9,700万ドル相当の資産がEulerから移転され、その後回収された。単一トランザクション内の複雑な組み合わせは業務ロジックの欠陥を増幅させ得る。
出典
2023 · Ledger Connect Kit
ウォレット接続ツール
Ledger Connect Kitがサプライチェーン攻撃を受け、悪意のあるコードがアプリケーションフロントエンドに侵入した。ハードウェアデバイスのセキュリティはトランザクション内容の検証に代わるものではない。
出典
2024 · DMM Bitcoin
CEX
DMM Bitcoinから約3億800万ドルが盗難された。FBIなどの機関はその後、関係者および署名チェーンを標的としたソーシャルエンジニアリング攻撃を公表した。
出典
2024 · Radiant Capital
レンディングプロトコル / 署名
Radiant Capitalから約5,000万ドルが盗難され、複数の開発者デバイスが侵害された。マルチパーティ署名であっても、汚染されたトランザクション情報に集合的に依存する可能性がある。
出典
2025 · Bybit / Safe
CEX / ウォレットフロントエンド
約15億ドルのBybit事件はSafeの開発者環境とフロントエンドに関与し、署名者はウォレットの制御ロジックを変更するトランザクションを承認した。
出典1 · 出典2
2025 · Cetus DEX
DEXSui上のCetusにおける約2億2,300万ドルの事件で、研究者は数学ライブラリの欠陥を指摘している。非EVM環境でも同様にコードと資産エクスポージャーの範囲を精査する必要がある。
出典
2026-07 · COLDCARD乱数欠陥
ハードウェアウォレット / シード生成ファームウェアの欠陥によりシード生成が弱体化され、デバイスがオフラインの間に攻撃者が関連する秘密鍵を再構築できるようになった。アップグレードでは、すでに生成された弱いシードを修正することはできない。アドバイザリに従った移行が依然として必要である。
出典
2026-10 · Ledgerハードウェア移植
ハードウェアウォレット／流通攻撃
Ledgerは、正規品のデバイスが改造され、東南アジアの流通チャネルを通じて出回り、移植された部品が初期化中にリカバリーフレーズを窃取したことを確認した。ベンダーは、自社のチップ、オペレーティングシステム、サーバーは侵害されていないと述べている。
出典
2026 · Binanceマルチチェーンインシデント
CEX／マルチチェーン
Binanceは当初、約63億ドル相当の資産が影響を受けたと推定し、他の侵入可能な箇所についての調査は依然として進行中である。単一のオペレーティングシステムが、複数のネットワークにまたがる資産を同時に露出させ得る。
出典1 · 出典2 · 出典3
ここにはCEXだけでなく、分散型取引所、レンディングプロトコル、ブリッジも存在する。盗まれた資産もあれば、凍結された資産もある。攻撃は異なるレイヤーで発生し、是正方法も異なる。私はこれらすべてを「ユーザーが秘密鍵を適切に管理できなかった」という一文に還元することに反対する。ユーザーは、あるツールの開発環境、ある共有ライブラリ、あるいは理解不能な認可が、自分のすべての資産への入口になることをどうやって知り得るのだろうか。
分散型ネットワークはすでに多くのことを成し遂げてきたが、資産管理のための障害分離はまだ十分とは程遠い。オンチェーン実行はトランザクションを忠実に完了するが、そのトランザクションがなぜこれほど多くの資産を移動する権利を持つのかを我々に代わって答えることはできない。
Ethereumの貢献は大きい。より多くの人々がオンチェーンアプリケーションを書けるようになり、豊富なツールと開発経験を育んだ。しかし今日、多くの新しいチェーンやL2（レイヤー2スケーリングネットワーク）は、EVM互換性を主要な目標として扱っている。Ethereumスマートコントラクトを実行する仮想マシンであるEVMは、広く複製される技術的前提になりつつある。互換性はアプリケーションの移行を確かに便利にする。Unichainなどのプロジェクトのドキュメントは、Ethereumツールの再利用を同等の実行環境の価値として明示的に挙げている。[[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
私は、EVM互換性を業界の既定の答えとして扱うことが、構造的なリスクの集中を生み出していると考える。ネットワーク名は多くあり得、バリデータは異なり得るが、開発者は同じコントラクトを繰り返しデプロイし、同じ認可の習慣を用い、同じソフトウェアライブラリに依存するかもしれない。共有依存関係のエラーは、別のチェーンにデプロイされたからといって消えるものではない。これは技術的経路についての判断であり、すべてのEVM実装が必然的に同じ脆弱性を持つという主張ではない。ここが私のイーサリアムに対する批判の根拠でもある。汎用的なコントラクト実行能力が移転可能な資産と直接結びついているため、アプリケーションコードとウォレットのインタラクションに極めて大きな責任が課される。コントラクトはコントラクトを呼び出せ、認可は長期間持続し、一見普通の確認がアカウントのその後の制御モードを変え得る。セキュリティは、すべての開発チームがこれらの組み合わせを正しく理解すること、そしてすべてのユーザーが自分が署名した内容を正しく理解することに、ますます依存している。
EIP-7702はこの問題を非常に明確にしている。普通の送金は「今回誰にいくら送るか」であるのに対し、委任認可は「今後、このコード片に私のアカウントを代表して操作を実行させる」というものになり得る。ユーザー体験の向上と権限の細分化という目標はあるが、委任の設定自体が広範な実行能力を付与し、細粒度の権限は依然として委任されたコードによって正しく実装されなければならない。[[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) Minfeng Qiらによるプレプリント「EIP-7702 Phishing Attack」は、このような認可の署名を誘導した後にアカウントを持続的に制御する経路を研究している。[[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) 利便性が増すにつれてセキュリティ責任も増大し、前者を単純にユーザーに押し付けることはできない。
今回のBinanceのインシデントは複数のチェーンにまたがり、調査もまだ完了していないため、影響全体を直接EIP-7702やEVMに帰することはできない。リエントランシー、署名サービスの侵害、フロントエンドの改ざんも同じ脆弱性ではない。しかし、こうした区別はアーキテクチャへの疑問を止める口実になるべきではない。なぜ基盤層は、上位層の誤りに対して、容易に回避できないより多くの制約を保持しないのか。
MEVも私を不満にさせる。これは参加者がトランザクションの包含、排除、順序付けを通じて余剰価値を得る空間を指す。私にとって、順序付けの力を用いてユーザーのトランザクションをサンドイッチし、その実行結果を悪化させることは、修正すべきバグとして扱われるべきであり、誰かがそこから利益を得られるという理由だけで、保存する価値のある機能として包装されるべきではない。イーサリアム自身のドキュメントも、トランザクションのサンドイッチがユーザーに与える害と、MEVがネットワークの安定性にもたらすリスクを明確に認めている。[[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEVはイーサリアム固有のものではなく、アービトラージや清算など異なる活動も含み、業界にはすでに緩和策の研究がある。私の批判は、ネットワークを維持するインセンティブが、ユーザーの取引条件を犠牲にする理由になってはならないということだ。より良い取引システムは、最低受渡結果と許容手数料を認可に書き込み、注文者が未約定情報を利用してユーザーに損害を与える空間を制限すべきである。私は以前から、イーサリアムが暗号資産に与えた影響は、PHPがインターネットに与えた影響といくぶん似ていると感じてきた。多くの人が何かを作れるようにした一方で、返済に長い時間がかかるエンジニアリング負債も残した。PHPは2026年10月になっても、深刻なリモートコード実行の脆弱性を修正する必要があった。成熟と普及は、継続的な堅牢化の代わりにはならない。[[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) インターネットの価値あるところは、言語、フレームワーク、クラウドサービスがそれぞれ別々に進化できることにある。私たちも、異なる資産モデルと実行方式が発展し続けることを許すべきであり、「同じ仮想マシンとの互換性」をエコシステムに参加するための入場券とみなすべきではない。
したがって私は、ビットコイン、Solana、Ripple/XRP Ledgerのエコシステム、そしてArcBlockを含むビルダーたちに、共通のセキュリティ基盤の構築に真剣に参加するよう呼びかける。標準や相互運用性に参加するために、まず自分自身をイーサリアムに作り変える必要はない。多様性は資産の管理と検証の方法において実装され、公衆の監視に開かれていなければならない。SlopeとCetusのインシデントはすでに、非EVMにもセキュリティの免除がないことを私たちに思い起こさせている。
私が形になることを望んでいるのは、異なる実行環境がすべて採用できるセキュリティ仕様である。同じ資産制限と検証要件をEVMと他の経路がそれぞれ実装し、そのうえで各々の保証とコストを公に検証できるようにする。
1. 基盤となるリスク制御に資産の処分権限を制約させる
大規模なウォレットは、受取人のホワイトリスト、累積支出上限、新規受取人に対する待機期間を設定できるべきである。重要なのは、これらのルールが同じ日常的な取引用の鍵によって直ちに取り消せないことである。ルールの変更には独立した承認を必要とし、監視と取り消しのための時間を残さなければならない。既存のスマートアカウントにはすでに実装の基盤がある。例えばSafe Guardsはマルチシグを超えた取引制限を追加できる。[[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) 私たちはこれを、すべての資産管理経路をカバーする、より導入しやすい基盤的能力にする必要がある。直接送金のみを制限し、無制限承認、モジュール、アップグレードによるバイパスを許せば、保護は機能しない。ホワイトリストコントラクトがアップグレード可能かどうか、受取人の権限が変更されていないかも検証範囲に入れる必要がある。Appleのアクティベーションロックは日常生活における示唆を与える。盗難デバイスの再アクティベーションを制限し、特定の盗難部品のキャリブレーションを制限することで、盗難後に悪用できる価値を減らすことを目的としている。[[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) ウォレットもこの方向で設計する価値がある。攻撃者が鍵を入手したとしても、換金できる資産の範囲は限られたままであり、攻撃の期待収益は低下する可能性がある。サービス妨害などのリスクは別途対処する必要がある。
これが私の言う資産セキュリティの「憲法」である。運用権限は侵害される可能性があるが、境界を変更する権限は独立したままでなければならない。復旧プロセスも制約される必要があり、単一の設定ミスによって資産が恒久的にロックされることを防がなければならない。
II. ニーモニックを渡すだけでなく、ウォレットにセキュリティ責任を負わせる
私は今日のウォレットシステムに強い不満を持っている。製品が一般の人に一連の単語を書き写させ、決して漏らさず、失わず、騙し取られないことを要求し、その後のすべての失敗をユーザーの責任に帰するなら、それは無責任な設計だと私は考える。セルフカストディは人にコントロールを与えるべきであり、同時に使える保護と復旧の能力も与えるべきである。すべてのユーザーがまずセキュリティ専門家になることを要求すべきではない。これはCryptoがより多くの一般ユーザーに到達するために越えなければならない敷居でもある。最近の事件により、この問題は明確に議題に上がっている。2026年10月、Ledgerは攻撃者が正規デバイスを改ざんした上で東南アジアの流通チャネルを通じて市場に再投入し、埋め込まれた部品が初期化時にリカバリーワードを窃取したことを確認した。Ledgerはこれを、チップ、オペレーティングシステム、サーバーの侵害ではなく、デバイスが工場を出た後の局所的な流通攻撃と定義した。[[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) COLDCARDの7月の事件は、ファームウェアがシード生成を弱体化させたものであり、攻撃者が関連する秘密鍵を再構築するためにデバイスを遠隔制御する必要はなかった。ファームウェアを更新すれば今後の生成プロセスは修正されるが、すでに生成された弱いシードは依然として移行が必要である。[[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)
この二つの事件は同じ種類の脆弱性ではないが、合わせて示しているのは、ユーザーが注意深く単語を書き留め、デバイスをオフラインに保ったとしても、製造元に代わってランダム性とサプライチェーンの完全性を検証することはできないということである。デバイスにバックアップ単語を表示させることはオフライン復元を目的としているが、同時に完全な復元秘密が保護を必要とする表示およびバックアップの経路を通過する原因にもなる。チップのセキュリティは、デバイス全体と配送プロセスの検証に代わるものではない。
改善の目標は、完全なウォレットのライフサイクル、すなわち鍵がどのように生成され、取引がどのように説明され、権限がどのように分離され、デバイス紛失後に復元がどのように機能するかであるべきだ。アカウント抽象化、つまりアカウントがプログラム可能なルールを通じて認可を検証できるようにすること、およびSLIP-39などのしきい値バックアップは、いずれも標準と実装の基盤がすでに存在するため、業界で誰も取り組んでいないとは言えない。[[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) しかし、これらの機能を、ユーザーが自分で複雑なスキームを組み立てるのではなく、検証済みで使いやすい保護手段にする必要がある。
ニーモニック単語の単純な難読化では不十分である。より信頼できる方向には、レビュー済みの暗号化バックアップ、しきい値復元、独立したデバイス認可、および大量の資産を預け入れる前にユーザーが復元訓練を完了することが含まれる。バックアップシャードとマルチシグは異なる層である。前者は復元時に同一の秘密に再結合される可能性があるが、後者は複数の独立した署名者が取引を承認することを必要とする。復元サービスが密かに新たなマスターキーになってはならず、追加のパスワードが、失えば復元不能な損失となる別の罠になってはならない。個人ウォレットと取引所ウォレットシステムは、取引記述、署名要求、資産制限、復旧プロセスに関するセキュリティ仕様を共有できる一方で、異なる限度額と承認ポリシーを採用することができる。ビットコインのPSBTはすでに未署名取引をツール間で受け渡すためのフォーマットを提供しており、この共通インターフェースは引き続き構築する価値がある。[[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) 共通なのは検証可能なセキュリティ要件であり、各チェーンは依然として独自の適応ルールを明確にする必要がある。ウォレットは、この署名が何を移転し、その後の権限を誰にどれだけ付与するのかを明確に提示すべきであり、独立したポリシーは範囲外の操作を拒否すべきである。より美しい確認ページだけでは十分ではない。
III. 最小限の必要な開示で検証可能性を実現する
ある条件が成立することを証明するために、常にユーザーがすべての基礎データを開示することを要求すべきではない。選択的開示、ゼロ知識証明、オンデマンドで付与される監査アクセスは、インフラストラクチャにおける通常の選択肢となるべきである。これは資産セキュリティにも関係する。公開された身元と資産の関係は、標的型詐欺の手がかりを提供する可能性があり、事業に必要のないデータはできる限り露出させるべきではない。
W3Cの検証可能クレデンシャルシステムには、すでに選択的開示の技術的経路が存在する。しかし、入力が真正であること、クレデンシャルが有効であり続けること、ステータスがどのように失効されるかを証明することは、依然として明確にする必要がある。[[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) ゼロ知識証明（ZK）を採用しても、取引金額と関係が自動的に隠蔽されるわけではない。スケーリング証明とプライバシー保護は異なる目標である。
例えば、事業が参加資格のみを検証する必要がある場合、ユーザーは完全な財務資料を開示することなく、信頼できる機関が発行した有効な資格結論を提示できる。隠された値がある条件を満たすことを証明する必要がある場合には、適切な証明メカニズムを使用できる。クレデンシャルの信頼できる発行元とその失効ステータスは、依然として検証する必要がある。
私の取り組みは、まず「誰が何を検証する必要があるか」を明確にし、その後、公開しなければならないデータを設計することである。資格を検証する者は資格結論のみを必要とする場合があり、特定の監査責任を負う者は制限された証拠を取得できる。公開検証可能な制約は、すべての人に恒久的に露出される個人情報を最小限に抑えるべきである。
IV. 取引サービスを可能な限り中央集権的保管から自由にする取引マッチング、パス探索、資産決済はそれぞれ別々に設計されるべきである。取引エントリーポイントを提供するサービスは、現在の決済を完了するために必要な権限のみを可能な限り取得し、それ以外の時間はユーザー資産がそれぞれの管理下に留まるようにすべきである。既存のインテントベースの取引プロトコルはすでに経路の一部を探求しており、業界はそれを引き続き完成させることができる。[[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
ユーザーが同意するものは明確な決済条件であるべきで、何を支払い、最低限何を受け取り、いつ失効し、許容される手数料は何かを含む。取引サービスが侵害された後、攻撃者はサービスを拒否することはできても、これらの条件を恣意的に変更することはできない。依然として中央集権的なカストディを必要とする事業者も、準備金の権限と運用権限を分離し、ホットウォレットのエクスポージャーと自動補充の上限を制限すべきである。
IBITはiSharesのビットコイン上場投資商品であり、市場で取引されるのはその株式である。その仕組みは部分的な分離の一例を提供している。株式と原資産のビットコインは別々に記録され、Vault Balance（カストディ残高）に関連する秘密鍵はコールドストレージに置かれる。株式取引記録の変更は、取引ごとに原資産のビットコインが移動することを必要としない。[[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) ここから学べることは、取引権限と準備金処分権限の分離である。そのTrading Balance（取引サービス残高）は異なる仕組みであり、カストディ自体にもリスクが伴う。コールドストレージは独立した指示と署名検証と組み合わせる必要がある。
私は取引エントリーポイントをルーターに例える。それは全ユーザー資産に対するマスタースイッチを担うことなく交換可能であることを願ってのことである。決済はパケット転送よりも複雑であり、資産の受け渡しと認可は依然として独立して検証される必要がある。サービスをノンカストディアルにした上で無制限の引き出し権限を与えることは、中央集権的リスクを呼び戻すだけである。
V. 階層アーキテクチャを用いて障害を分離し、交換可能性を維持する我々には、独立して進化できるアイデンティティと認可のインターフェース、資産ポリシー、および決済検証の手法が必要である。異なるチェーンはそれぞれ独自の実行モデルを維持し、明確なインターフェースを通じて接続できる。インターフェースは「呼び出しが成功した」とだけ述べるのではなく、セキュリティ保証とその条件を明示すべきである。インターネットの経験はこのアプローチを支持している。RFC 9518「中央集権化、分散化、およびインターネット標準」において、Mark Nottinghamは中央集権化が有用となり得る状況を具体的に論じ、またそれがもたらす権力とリスクを分析している。[[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) これはまさに学ぶ価値のある姿勢である。どの責任を中央集権化できるのか、どの程度までなら可能か、そしてその権力が拡大するのをどう防ぐかを、アーキテクチャに答えさせよう。サービスには異常を集中的に識別することを許可しつつ、資産に触れる権限は制限できる。ユーザーは自身の資産ポリシーと検証記録を失うことなく、サービスを切り替えられるべきである。
最も重要な受け入れの問いは、ビジネスサービスが侵害された後、どの独立した層が依然としてそれを拒否できるか、である。すべての層が一つの管理鍵を共有しているなら、いわゆる階層化はデプロイ図上の階層化にすぎない。
この目標は五つの責任層として捉えられる。トランザクションサービスはリクエストを提出し、ウォレットはユーザーの意図を表現し、独立したポリシーは資産処分に対する権限を制限し、検証コンポーネントは操作と証拠を検査し、決済層は制約を強制し検証可能な記録を提供する。これらは異なるチームによって実装でき、その依存関係と障害条件も個別に記述されなければならない。
本稿が提唱するターゲットアーキテクチャ。決済層は資産ポリシーを強制しなければならず、ウォレット内のプロンプトはこの制約を代替できない。日常的な署名、ルール変更、および復旧権限は分離され、バイパステストに供される必要がある。
6. ユーザーが自身の資産を軽量に検証できるようにする
一般の人々は、自身の残高と受領を検証するためにチェーン全体の履歴を保存・実行する必要はないし、ウォレットの背後にある単一のサーバーのみを信頼する必要もない。サトシ・ナカモトはすでにホワイトペーパーの第8節でSPV、簡易支払検証を提案している。ビットコインのBIP-157は、クライアントがフィルタをダウンロードし、自身に関連するブロックを見つけられるようにする探求を続けており、イーサリアムにもライトクライアントの設計がある。[[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) したがって問題は、誰も考えたことがないということではなく、明確なセキュリティ条件を備えた検証能力を、ユーザーが日常的に使用するウォレットに依然として組み込む必要があるということである。アカウント状態証明をサポートするチェーンを例に挙げると、残高を照会する際、サーバーは残高と証明の両方を返すべきである。ウォレットはまず、そのチェーンのルールに従って短いブロックダイジェスト、すなわちブロックヘッダーを検証し、次にこの残高がそのダイジェストによってコミットされたデータと一致するかどうかを確認する。サーバーが答えを提供し、ウォレットがその答えを検証できる。ビットコインのSPVは、関連するトランザクションが含まれていた証拠を検証するものであり、そのまま残高証明としてコピーすることはできない。ウォレットはまた、どこまで同期したか、どの情報が検証済みかを明確に表示すべきであり、証明が欠けている場合、データが古い場合、またはソースが矛盾する場合には、警告を発するか、この情報に依存する高リスク操作を停止すべきであり、黙って盲信にフォールバックしてはならない。
ライト検証には依然として条件がある。トランザクションがブロックに含まれたことを証明することは、ブロック内のすべてのトランザクションが有効であることを自分で確認することと同じではない。異なるスキームは、ハッシュパワーの過半数が正直であることに依存するか、信頼された初期記録、すなわちチェックポイントに依存する場合がある。また、サーバーがデータを隠蔽したり、ユーザーを古いチェーン記録に隔離したりすることにも警戒しなければならない。クエリ自体がユーザーにとって重要なアドレスを露出するかどうかも対処する必要がある。フルノードとブロック生成者は同じ役割ではなく、イーサリアムは現在、ブロック生成にマイナーではなくバリデータを使用している。
さらに重要なのは、「この送金が実際にオンチェーンで発生した」ことを証明できても、「これがまさにユーザーが望んだ送金である」ことを証明できるわけではない。ライトクライアントは、以前の資産制限と署名検証を置き換えることはできない。それらはユーザーが検証不能な答えへの依存を減らすことを可能にし、資産ポリシーは、有効な署名であっても資産を無制限に処分できないことを保証する。両方の層を共に構築して初めて、検証能力を参加者間に分散させることができる。
7. 異常識別とセキュリティ検証を公共インフラとして構築する
トランザクションの前に、誰かがその操作が資産ポリシーに準拠しているか、また履歴上の行動を突然変化させていないかを確認すべきである。明らかな異常は一時停止またはエスカレーション審査を引き起こすことができ、権限の拡大には別の独立した経路が必要である。AIは判断に参加できるが、ハードルールを上書きするパスを受け取るべきではない。
同時に、攻撃事例、権限テスト、および繰り返し実行可能な検証ツールを共同で維持する必要がある。仕様を共有し、独立した実装と独立した検証を保持することによってのみ、コモンモード故障を減らすことができる。財団や取引所はすでにセキュリティ投資を行っており、例えばイーサリアム財団のTrillion Dollar Security Initiativeなどである。[[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) 次に問うべきは、その投資を他のチームも採用・検査できる公共インフラに変換できるかどうかである。これら七つの作業項目のいずれも、絶対的な安全性を保証することはできない。それらが果たすべきは検査可能な境界である。すなわち、どのような権限侵害の条件下で、最大どれだけの資産が露出するのか、異常をどれだけ迅速に発見できるのか、そして復旧が依然として誰に依存しているのか、である。
ここで、こう言う人もいるかもしれない。方向性は正しいように聞こえるが、業界はすでに何年も進んできた。再構築にはどれだけの人と時間が必要になるのか。これではやはり理想論ではないか、と。
過去のソフトウェア生産方式に従って見積もるなら、この疑問は非常に現実的である。しかし2026年までには、コーディングエージェントとAIを活用したソフトウェアエンジニアリングが、私たちが動員できる構築能力をすでに変えたと私は考える。ここで言うコーディングエージェントとは、開発環境においてコードを読み書きし、ツールを呼び出し、テストを実行し、フィードバックに基づいて作業を継続できるAIプログラミングアシスタントである。構築者は目標を設定し、セキュリティ境界を定義し、これらのツールを用いてシステムを実装・検査し、結果に責任を負う。
以前なら大規模なチームが反復的に実装、適応、保守する必要があった作業を、今では小規模なチームがこの新しいエンジニアリング手法で試みることができる。一つのチームが一つのレイヤーを担当し、明確なインターフェースを中心にコンポーネントを提供し、その後、他のチームがそれらを検査し組み合わせる。人間のアーキテクチャ判断、コーディングエージェントの実装能力、独立したセキュリティ検証を組織化することこそ、私の見解では、真剣に再評価する価値のある構築経路である。
AnthropicとPNNLの研究は具体的な例を示している。限られた重要インフラのシミュレーション環境において、研究者は攻撃の再構築がおそらく数週間から約3時間に短縮されたと報告した。[[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) これは小規模チームがすでに業界全体を安全に書き換えられることを証明するものではないが、以前は高コストだった検証と攻防作業が新たなコスト条件を持ち得ることを示している。
今すぐ開始できる組織的アプローチの一つは、Build in Public AI Factoryを共同で構築することである。業界の専門家、学者、実務者が要件と受け入れ仕様（spec）を公開で作成し、何を保護すべきか、どの操作が許可されるか、どの権限が侵害された後でもどの境界が維持されなければならないかを説明し、その後これらの要件を受け入れテストに変換する。コーディングエージェントのグループが主要なコーディング、テスト、デバッグ作業を担い、異なるチームが設計と結果を検査し、人間が判断と受け入れの責任を負う。参加者はアイデア、マシン、計算能力、モデル呼び出し枠、すなわちAIトークンを提供できる。AIとクラウドコンピューティング企業も、モデル枠、計算リソース、ツールを通じてこの公共建設を支援できる。仕様、プロトタイプコード、エージェントワークフロー、テスト環境、検証結果はすべて共同で維持されるインフラとなり、次のチームがそこから直接続けられるようにする。目標は、開発能力を再利用可能な公共施設に組み込み、特定の個人の時間や特定のチームへの依存を減らすことである。
攻撃者もAIを使っている。もはや防御を過去の生産方法に委ねる理由はない。[[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) しかし、コード生成が速いことは出発点にすぎない。制約を明確に書き、テストを繰り返し実行可能にし、コンポーネントを検査可能かつ交換可能にして初めて、AIの能力はインフラの改善へと変換できる。
独立したビルダーはコーディングエージェントとAIツールの助けを借りて協働する。宇宙工房は公共建設の比喩である。特に、まだ構築することを愛する人々にこの呼びかけを届けたい。ここでの「ハッカー」とは、システムがどのように動くかを解明しようとし、見つけたことを共有しようとし、他人に自分の仕事をテストさせようとする人を指す。その精神はかつてインターネットを前進させ、今日それはCryptoも前進させることができる。
この業界に賢い人が欠けているとは思わないし、CryptoとAI業界がこの仕事を支えるリソースを見つけられないとも思わない。より難しいのは、人材、資金、持続的な責任を一緒に組織することである。財団や能力のある企業は、直接収益を生まずとも全員に利益をもたらす基盤的仕事の長期的コストを負担することを厭うべきではない。
皆が協力して、グローバルに共有される暗号インフラを構築できることを願う。異なるネットワークとチームは共有されたセキュリティ制約の下で協働し、それぞれが独自のソリューションを実装し、互いのものをテストし、ユーザーは選択し移行できる。単一のコンポーネントから始められるが、方向性は業界全体が共に構築するのに十分な大きさであるべきだ。ArcBlockを含むすべての参加者は、検証可能な仕事を貢献すべきである。
私たちは共に、ある部分が侵害されても資産には境界があり、他のシステムは依然としてエラーを拒否でき、ユーザーには回復と退出の道が残るようなインフラを構築すべきだ。スター・ウォーズから名前を借りれば、これが私たちの「新たなる希望」である。[[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) 希望は行動を厭わない普通のビルダーから生まれ、またコーディングエージェントと新しいエンジニアリング手法が彼らにより多くの構築作業を担わせることを可能にするこの瞬間からも生まれる。Ethereum、Solana、Bitcoin、XRP Ledger などのプロジェクトのビルダー、Binance、Coinbase、Kraken などの取引所、さらにウォレット、プロトコル、セキュリティ研究、AI、クラウドコンピューティングのチームに招待を送りたい：明確にスコープを定めたパイロットから始め、他のチームが採用・テストできる改善を共同で生み出そう。
列挙した名前はあくまで例であり、順序に意味はない。規模や技術的アプローチに関わらず、参加を歓迎する。この招待には、本記事で批判した技術的アプローチのビルダーも含まれる。資産セキュリティの共同改善は、それぞれのエコシステムの境界を越える価値がある。
私自身も参加し、既存のインフラ、ソフトウェアエンジニアリング、AI コラボレーションの実践を提供する用意がある。私たちは業界の小さなチームにすぎず、できることは限られている。プロトタイプと再現可能なテスト群から始めたい。
実務運用の経験を持つ人々は匿名化した攻撃シナリオを提供し、ウォレットとプロトコルのチームは保護を実装し、独立研究者はそれを回避しようと試みることができる。各チームが対応可能な部分を担い、共同でソリューションをテストし、次のステップを決定する。
私は、本記事の資産制限と復旧の要件を最初の公開仕様にまとめる作業に参加する用意があり、また、関連する技術とエンジニアリングの実践を提供し、他の参加者とともにこのパイロットのための公開 AI Factory を構築することにも貢献する用意がある。まず非常に具体的な問題を選ぶ：日常的な取引キーが漏洩した後、攻撃者によるウォレットからの一括流出をどう防ぐか？許容される損失範囲、ルール変更の権限、復旧条件を受け入れテストに書き込み、開発エージェントにプロトタイプを実装させ、別のエージェント群と独立研究者にバイパス経路を探させる。誤った残高を返すデータサーバーや、デバイス紛失後の復旧も、徐々にテストに追加できる。プロトタイプが何を達成し、どこで失敗し、どのような依存関係が残るかをすべて公開で説明し、証拠に基づいて次のステップを決定すべきである。
参加を希望する方は、X で本イニシアチブを公開でリポストまたは引用し、@mave99a にメンションして、解決したい問題、匿名化した攻撃事例、または提供できるリソースについて語っていただきたい。議論が公開で進み、より多くのビルダーが見て参加できることを願っている。
暗号資産はこのままではいけない。共に取り組む意志のある方々よ、今行動を起こそう。構築可能でテストに耐えうる一つの改善から始めよう。Binance、初回発表の公式投稿および追加調査の公式更新、2026-10-30、TRMマルチチェーン分析。本稿は2026-10-30時点で検証済みであり、調査および回収状況は変更される可能性がある。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
Satoshi Nakamoto、Bitcoin: A Peer-to-Peer Electronic Cash System、2008年。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
Uniswap、Unichain EVM Equivalence。共有依存関係のリスク集中は本稿における著者の判断であり、当該文書の結論ではない。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
Vitalik Buterin、Sam Wilson、Ansgar Dietrichs、lightclient、EIP-7702: Set Code for EOAs、2024-05-07作成。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
Minfeng Qi、Qin Wang、Ruiqiang Li、Tianqing Zhu、Shiping Chen、EIP-7702 Phishing Attack、2025-12-13、arXiv v1プレプリント。本Binanceインシデントを特定するものではない。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum、Maximal extractable value (MEV)、順序付けメカニズム、各種類型および負の影響。「バグとして修正されるべき」は、ユーザーに損害を与える行為に対する著者のエンジニアリング上の立場である。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
PHP公式2026年ニュースアーカイブ、CISA 2026-10-26 Known Exploited Vulnerabilities更新、CVE-2026-109618、CVE-2026-109619。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe、Guards and Modules、機能および権限リスクの説明。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
Apple、Apple to expand repair options with support for used genuine parts、2024-04-11、現行のパーツペアリング対応の説明。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger、Ledger's Response to the Hardware Implant Attack、2026-10、流通チェーンにおける攻撃に関するベンダー声明。Joe Grand、ハードウェアインプラントに関するリバースエンジニアリング研究。未検証のネットワーク損失推計を確定した結論として提示してはならない。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite、Current COLDCARD Security Status、2026-10-30アクセス、2026年7月のインシデントおよび是正に関する継続更新記録。アップグレードとシード移行は二つの別個の操作である。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Account Abstraction Using Alt Mempool、Trezor、SLIP39 FAQs、しきい値リカバリ、互換性および追加パスフレーズのリスク。既存のメカニズムは構築の基盤であり、すべてのデプロイが信頼できることを意味するものではない。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174：部分的署名済みビットコイントランザクション形式。未署名トランザクションの交換形式であり、クロスチェーン汎用資産戦略仕様ではない。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C、Verifiable Credentials Overview v1.0、2026-07-30 Group Note、Ethereumプライバシーノート。概要に記載された技術の標準化状況は、それぞれ独立している。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
CoW Protocolドキュメント、トランザクションインテントおよびソルバーメカニズム。本記事は、特定のデプロイメントに対する包括的なセキュリティ保証を提供するものではない。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares、IBIT 2025 Annual Report、PDF 8～10ページのカストディ取決めおよび45ページのリスク開示。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham、RFC 9518: Centralization, Decentralization, and Internet Standards、2023-12、独立提出、informational RFC、標準化トラック仕様ではない。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Bitcoinホワイトペーパー第8節 Simplified Payment Verification、BIP-157: Client Side Block Filtering、Ethereum、Light clients。ライトクライアントごとに検証範囲と信頼条件は異なる。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Ethereum Foundation、Announcing the Trillion Dollar Security Initiative、2025-05-14。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic、AI to defend critical infrastructure、2026-01-08、PNNLとの協力による制限環境下での研究。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic、Mapping AI-enabled cyber threats、実際の悪用サンプルに関する研究。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm、Star Wars: A New Hope (Episode IV)、1977。本記事はそのタイトルと共同自助のイメージを借用している。[↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)