著者：ArcBlock創業者兼CEO Robert Mao

本稿は誰でも自由に転載・転送してよい。この業界自救の呼びかけを、より多くの人に見てもらいたい。

Cryptoはもう、このままではいけない。大規模な窃取が繰り返されるたびに、奪われるのは資産だけではない。参加者がこの業界全体に抱く信頼も奪われていく。私たちは自救しなければならない。

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のfounderとして、またCryptoとBlockchainの従事者として、私はそんな結末を受け入れたくない。この業界には守る価値のあるものがあると信じているし、自分たちのセキュリティ基盤には自分たちで責任を持つべきだと考えている。次の事故を消極的に待ち続ければ、繰り返される失血が、私たちが共に築いてきたものすべてを最終的に破壊しかねない。

だからこそ、この提言を出したい。取引所、ウォレット、ブロックチェーンの建設者は、資産のコントロールとセキュリティ検証の基盤を共に再構築し、一度の侵入による破壊の範囲を制約できるようにすべきだ。以下のタイムラインは、なぜ変えなければならないのかを示している。その後の技術的方策は、私が「ここから始められる」と考える作業だ。

この事故のタイムラインは、すでに長すぎる

2008年、サトシ・ナカモトはピアツーピアの電子現金システムを提唱し、支払いが信頼できる仲介者に依存する度合いを減らそうとした。[[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) しかしその後の重大事故は、資金、承認、ソフトウェア依存が再び集中してしまう問題を、繰り返し露呈させてきた。

以下では、中央集権型取引所（CEX）、分散型取引所（DEX）、ブリッジ、ウォレットなどの分野における代表的な事案を時系列で挙げる。これは完全な事故データベースでも、年ごとの損失統計でもない。金額が示されている場合は、事故時点の概算のグロス影響額を指す。盗難、凍結、その後の回収はそれぞれ別に説明しており、合算して恒久的な損失とみなすことはできない。

2008 · Bitcoin白書

起点
Bitcoinの白書は、金融機関を介在させないピアツーピア決済を提案した。
出典

2011–2014 · Mt. Goxの長期的な窃取

CEX
Mt. Goxでは長期間にわたり窃取が続き、最終的に営業を停止した。米司法省のその後の起訴は、2011〜2014年の間に約64.7万BTCが盗まれたと主張している。これは2014年のある一日に起きた単発の攻撃ではない。
出典

2012 · BitcoinicaとBitfloor

CEX／カストディ基盤
BitcoinicaのLinodeホスティング環境が破られた。同年、Bitfloorでは暗号化されていないウォレットバックアップが攻撃の入口となった。プラットフォームの裏側にあるサーバーとバックアップも、資産安全の境界である。
出典

2015 · Bitstampのホットウォレット

CEX
Bitstampのホットウォレットが侵害され、その後、実行環境が再構築された。公式は事故の範囲とオフライン準備金を区別しており、隔離がエクスポージャーを限定できることを示している。
出典

2016 · Bitfinex

CEX
Bitfinexで約12万BTCが盗まれた。マルチシグの取り決めであっても、エンドツーエンドの独立した承認と検証は依然として必要である。
出典1 · 出典2

2016 · The DAO

オンチェーンプロトコル
The DAOのコントラクトがリエントランシー攻撃を受け、約360万ETHが子DAOへ移され、その後Ethereumの分岐を引き起こした。正当な実行経路が、破滅的な業務結果を生み得る。
出典1 · 出典2

2017 · Parityの共有ウォレットライブラリ

コントラクトウォレット
Parityの共有ウォレットライブラリが破壊され、約51.3万ETHが凍結された。持ち去られなくても、共通コードへの依存によって利用できなくなることがある。
出典

2018 · Coincheck

CEX
CoincheckのNEMホットウォレットが盗まれた。オフライン準備金、ホットウォレットの権限、業務要件のあいだの境界が、再び問題となった。
出典

2019 · Binance

CEX
Binanceの公告によれば、7,000BTCが1件の取引で引き出された。大規模な資産流出は、署名の前段で制約される必要がある。
出典

2020 · KuCoin

CEX
KuCoinのホットウォレット事故。その後、多方面の協力により大量の資産が回収された。盗難総額と最終損失は同じ数字ではない。
出典

2021 · Poly Network

クロスチェーンプロトコル
Poly Networkで約6億1,200万ドル相当の資産が送金され、その後、順次返還された。クロスチェーンの承認と資産コントロールは、正常な業務経路だけで成立してはならない。
出典

2022 · Roninブリッジ

ブリッジ
Roninのバリデータ権限が破られ、173,600ETHと2,550万USDCが送金された。複数のバリデータの鍵も、同じ攻撃チェーンに落ち得る。
出典

2022 · Slopeウォレット

ウォレット
SolanaエコシステムのSlopeウォレット事件。Solana公式は、秘密鍵の情報が誤ってアプリ監視サービスへ送信されたと指摘している。Solanaのコンセンサスが破られたわけではない。
出典

2023 · Euler

レンディングプロトコル
Eulerで約1億9,700万ドル相当の資産がプロトコルの脆弱性により送金され、その後回収された。単一取引の複雑な組み合わせが、業務ロジックの欠陥を増幅し得る。
出典

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／ウォレットフロントエンド
Bybitの約15億ドル規模の事故。攻撃はSafeの開発者環境とフロントエンドに関わり、署名者はウォレットの制御ロジックを変える取引を承認してしまった。
出典1 · 出典2

2025 · Cetus DEX

DEX
Sui上のCetusで約2億2,300万ドルの事故。研究者は数学ライブラリの欠陥を指摘している。非EVM環境でも、コードと資産エクスポージャーの範囲を検証しなければならない。
出典

2026-07 · COLDCARDの乱数欠陥

ハードウェアウォレット / シード生成
ファームウェアの欠陥がシード生成を弱め、攻撃者はデバイスがオフラインのままでも関連する秘密鍵を再構築できた。アップグレードではすでに生成された弱いシードは修復できず、告知に従った移行が必要である。
出典

2026-10 · Ledgerのハードウェア植え込み

ハードウェアウォレット / 流通攻撃
Ledgerは、正規品が改造され、東南アジアの販売チャネルを通じて流通したことを確認した。植え込まれた部品は初期化時にリカバリーフレーズを窃取する。同社は、チップ、オペレーティングシステム、サーバーは破られていないとしている。
出典

2026 · Binanceのマルチチェーン事故

CEX／マルチチェーン
Binanceは約63億ドル相当の資産が影響を受けたと初期推定し、他の侵入可能性の調査は続いている。単一の運営体制は、複数のネットワーク上の資産を同時に露出させ得る。
出典1 · 出典2 · 出典3

ここにはCEXもあれば、分散型取引所、レンディングプロトコル、ブリッジもある。資産が盗まれた事例もあれば、凍結された事例もある。攻撃は異なる層で起きており、修復の方法も異なる。私はこれらすべてを「ユーザーが秘密鍵をちゃんと管理していなかった」の一言に帰着させることに反対する。ユーザーは、どうやって知ればよいのか。あるツールの開発環境、ある共有ライブラリ、あるいは理解できない1件の承認が、自分の全資産の入口になるなどと。

分散型ネットワークはすでに多くのことを成し遂げてきたが、資産コントロールの故障隔離はまったく足りていない。オンチェーンの実行がある取引を忠実に完了したとしても、「なぜその取引に、これほど多くのものを動かす権限があるのか」という問いに答えてはくれない。

異なる技術路線が、共にセキュリティ基盤を築くために

Ethereumの貢献は大きい。より多くの人がオンチェーンアプリを書けるようにし、豊富なツールと開発経験を生み出した。だが今日、多くの新しいチェーンやL2（レイヤー2拡張ネットワーク）が、EVM互換を最優先の目標にしている。EVM、すなわちEthereumのスマートコントラクトを実行する仮想マシンは、広く複製される技術的前提になりつつある。互換性はアプリの移行を確かに容易にする。Unichainなどのプロジェクトのドキュメントは、Ethereumのツールを再利用できることを、等価な実行環境としての価値だと明確に位置づけている。[[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)

EVM互換を業界のデフォルトの答えとみなすことが、構造的なリスク集中を生んでいると私は考える。 ネットワークの名前はいくつあってもよく、バリデータも異なってよい。しかし開発者は同じコントラクトを繰り返しデプロイし、同じ承認の習慣を使い、同じソフトウェアライブラリに依存し得る。共通依存に潜む誤りは、別のチェーンにデプロイしたからといって消えはしない。これは技術路線についての判断であり、すべてのEVM実装が必然的に同じ脆弱性を持つという話ではない。

私がEthereumを批判するのも、まさにここである。汎用的なコントラクト実行能力は移転可能な資産に直接つながり、アプリケーションコードとウォレットのやり取りに極めて大きな責任を負わせる。コントラクトはコントラクトを呼び出せ、承認は長期にわたって残り、一見普通の確認が、その後のアカウントの制御方法を変え得る。セキュリティはますます、各開発チームがこうした組み合わせを正しく理解すること、そして各ユーザーが自分が何に署名したのかを正しく理解することに依存している。

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にも私は不満を持っている。これは参加者が取引の取り込み、除外、順序付けを利用して追加の価値を得る余地を指す。私にとって、順序付けの権限を使ってユーザーの取引をサンドイッチし、その約定結果を悪化させる行為は、修正すべきbugとして扱われるべきであり、誰かがそこから金を稼げるという理由で、残す価値のあるfeatureとして装い直すべきものではない。Ethereum自身のドキュメントも、サンドイッチ攻撃がユーザーに与える害と、MEVがネットワークの安定性にもたらすリスクを明確に認めている。[[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEVはEthereum固有のものではなく、アービトラージや清算など異なる活動も含み、業界には緩和策の研究もある。私の批判は、ネットワークを維持するインセンティブを、ユーザーの取引条件を犠牲にする理由にしてはならない、ということだ。より良い取引体系は、最低限の決済結果と許容される手数料を承認に書き込み、順序付け者が未約定の情報を利用してユーザーを害する余地を制限すべきである。

私はずっと、EthereumがCryptoに与えた影響は、PHPがインターネットに与えた影響に少し似ていると感じている。多くの人が何かを作れるようにし、長期にわたって返済すべきエンジニアリング負債も残した。PHPは2026年10月になっても、深刻なリモートコード実行の脆弱性を修正する必要があった。成熟と普及は、継続的な強化の代わりにはならない。[[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) インターネットの貴重な点は、言語、フレームワーク、クラウドサービスがそれぞれ別々に進化できることだ。私たちも、異なる資産モデルと実行方式が発展し続けることを許すべきであり、「同じ仮想マシンとの互換性」をエコシステムに参加する入場券にしてはならない。

したがって私は、Bitcoin、Solana、Ripple／XRP Ledgerのエコシステム、そしてArcBlockを含む建設者たちに、共通のセキュリティ基盤の構築へ真剣に参加するよう呼びかける。標準と相互運用に参加するために、まず自分をEthereumに作り変える必要はない。多様性は資産のコントロールと検証の方法にまで及ぶべきであり、公開の検証を受け入れるべきだ。SlopeとCetusの事故は、非EVMにも安全の免除はないことをすでに示している。

私が形にしたいのは、異なる実行環境のいずれもが採用できるセキュリティ規範だ。同じ資産制限と検証要件を、EVMと他の路線がそれぞれ実装し、それぞれの保証とコストを公開の場で検証し合う。

すぐに始められる7つの強化策

一、基盤層のリスク管理で資産処分権を制約する

大口ウォレットは、受取先のホワイトリスト、累計支出の上限、新規受取先への待機期間を設定できるべきだ。重要なのは、これらのルールが同じ日常取引用の鍵で即座に解除できないことだ。ルールの変更には独立した承認が必要で、監視と取り消しのための時間も残さなければならない。

既存のスマートアカウントには実装の基礎がある。たとえばSafe Guardsは、マルチシグに加えて取引制限を追加できる。[[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) 私たちはこれを、より採用しやすく、すべての資産コントロール経路をカバーできる基盤能力にする必要がある。直接送金だけを制限し、無制限承認やモジュール、アップグレード経由の迂回を許すなら、保護は空振りに終わる。ホワイトリストのコントラクトがアップグレード可能かどうか、受取側の権限が変化していないかも、検証の範囲に入れなければならない。

AppleのActivation Lockは、日常生活の中の示唆を与えてくれる。盗難されたデバイスの再アクティベーションを制限し、一部の盗難部品の校正も制限する。目的は、盗んだ後に利用できる価値を下げることだ。[[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) ウォレットもこの方向で設計する価値がある。攻撃者が鍵を一本手に入れても、換金できる資産の範囲は限られている。それなら攻撃の期待収益は下がり得る。サービス破壊などのリスクは、別途対処する必要がある。

これが私の言う資産安全の「憲法」だ。操作権限は侵害され得ても、境界を変更する権限は独立を保つべきである。復旧のプロセスも制約を受けなければならない。一度の設定ミスで資産が永久にロックされることを防ぐために。

二、ウォレットにセキュリティ責任を負わせる。ニーモニックを渡すだけにしない

今日のウォレット体系には、私に強い不満がある。ある製品が普通の人に単語の羅列を書き写させ、決して漏らすな、失うな、騙されるなと要求し、その後の失敗をすべてユーザーの責任に帰するなら、私はそれを無責任な設計だと思う。セルフカストディは人にコントロールを与えるべきであり、使える保護と復旧の能力も与えるべきだ。すべての利用者に、まずセキュリティの専門家になれと要求すべきではない。これも、Cryptoがより多くの普通のユーザーへ広がるために越えなければならないハードルである。

最近の事故は、この問題をきわめて直接的に突きつけた。Ledgerは2026年10月、攻撃者が正規のデバイスを改造し、東南アジアの販売チャネルを通じて市場に戻したこと、植え込まれた部品が初期化時にリカバリーフレーズを窃取したことを確認した。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) しかし私たちは、こうした能力を、検証済みで使いやすい保護として提供する必要がある。ユーザー自身に複雑な仕組みを組み立てさせるのではなく。

ニーモニックの単純な難読化では足りない。より信頼できる方向は、審査を受けた暗号化バックアップ、しきい値復旧、独立したデバイス承認であり、大口資産を預け入れる前にユーザーに復旧演習を完了させることだ。バックアップの断片化とマルチシグは異なる層である。前者は復旧時に同じ秘密を再構成し得るが、後者は複数の独立した署名者による取引承認を要求する。復旧サービスが知らぬ間に新たなマスターキーになってはならないし、追加のパスワードが「失えば復旧不能」という別の罠になってはならない。

個人向けウォレットと取引所のウォレットシステムは、取引の説明、署名要求、資産制限、復旧プロセスに関するセキュリティ規範を共有しつつ、異なる限度額と承認ポリシーを採ることができる。BitcoinのPSBTはすでに、ツールをまたいで未署名取引を受け渡すフォーマットを提供している。この共通インターフェースはさらに育てる価値がある。[[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) 共通なのは検査可能なセキュリティ要件であり、各チェーンは自らの適応ルールを明確にする必要がある。ウォレットは、今回の署名で何が移転され、誰にどれだけの将来の権限が与えられるのかを明確に示し、独立したポリシーが範囲外の操作を拒否すべきだ。きれいな確認画面だけでは足りない。

三、最小限の開示で検証可能にする

ある条件が成立することを証明するのに、常にユーザーへ基礎データのすべてを公開させる必要はない。選択的開示、ゼロ知識証明、必要に応じて付与する監査アクセスは、インフラの通常の選択肢になるべきだ。これは資産安全にも関わる。公開された身元と資産の関係は、標的型の欺瞞に手がかりを与えかねない。業務に必要のないデータは、できるだけ露出を減らすべきである。

W3Cの検証可能クレデンシャル体系には、すでに選択的開示の技術的経路がある。ただし、証明の入力が真実であること、クレデンシャルがなお有効であること、そして状態がどう失効するのかは、明確にする必要がある。[[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) ゼロ知識証明（ZK）を採用しても、取引金額と関係が自動的に隠れるわけではなく、スケーリングの証明とプライバシー保護は異なる目標だ。

たとえば、ある業務が参加資格の確認だけを必要とする場合、ユーザーは信頼できる機関が発行した有効な資格結論を示せばよく、財務資料の全体を公開する必要はない。隠された数値が条件を満たすことを証明する必要がある場合に、適切な証明機構を使えばよい。クレデンシャルの信頼できる出所と失効状態は、なお検証しなければならない。

私の提言は、「誰が何を検証する必要があるのか」を先に明確にし、そのうえで必ず公開すべきデータを設計することだ。資格を検証する人は資格の結論だけを必要とするかもしれない。特定の監査職責を負う人は、制限付きの証拠を得られる。公開検証可能な制約のもとで、すべての人への個人情報の恒久的な露出をできるだけ減らす。

四、取引サービスをできる限り集中カストディから切り離す

取引のマッチング、経路の探索、資産の決済は、分けて設計すべきだ。取引の入口を提供するサービスは、現在の決済に必要な権限だけを取得し、それ以外の時間はユーザーの資産が各自の管理下に残るようにするのが望ましい。既存の取引インテントに基づくプロトコルは、すでに一部の道筋を探っている。業界はこれを完成させていける。[[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)

ユーザーが同意するのは、明確な決済条件であるべきだ。何を支払い、最低何を受け取り、いつ失効し、どの手数料が許容されるのか。取引サービスが侵害された後、攻撃者はサービス拒否はできても、これらの条件を勝手に変えることはできない。依然として集中カストディが必要な業務でも、準備金と運営権限を分離し、ホットウォレットの露出と自動補充の限度額を制限すべきだ。

IBITはiSharesのビットコイン取引所上場商品であり、市場で取引されるのはその受益証券（シェア）だ。その仕組みは、部分的な隔離の例を提供している。シェアと原資産のBitcoinは別々に記録され、Vault Balance（カストディ残高）に関わる秘密鍵はコールドストレージに置かれる。シェアの取引記録が変わっても、原資産のBitcoinが1件ごとに追随して動く必要はない。[[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) 参考にすべきは、取引権と準備金の処分権の分離だ。そのTrading Balance（取引サービス残高）には異なる取り決めがあり、カストディ自体にもリスクがある。コールドストレージは、独立した指示と署名の検証と組み合わせなければならない。

私が取引の入口をルーター（router）に例えるのは、それが差し替え可能であり、全ユーザーの資産を束ねるマスタースイッチを持たないことを望むからだ。決済はパケット転送より複雑であり、資産の受け渡しと承認はなお独立に検証される必要がある。サービスをノンカストディアルにしたうえで無制限の出金権限を与えれば、集中リスクをただ呼び戻すことになる。

五、階層アーキテクチャで故障を隔離し、差し替え能力を保つ

独立して進化できる身元と承認のインターフェース、資産ポリシー、決済検証の方式が必要だ。異なるチェーンは自らの実行モデルを保ち、明確なインターフェースで接続できる。インターフェースが示すべきはセキュリティ保証とその条件であり、「呼び出しに成功した」だけでは不十分だ。

インターネットの経験は、この考え方を支持する。Mark NottinghamはRFC 9518「Centralization, Decentralization, and Internet Standards」で、集中化が役立つ場合を論じ、それがもたらす権力とリスクも分析している。[[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) これはまさに参考にすべき態度だ。どの職責が集中してよく、どこまで集中してよく、その権力の拡大をどう防ぐのかを、アーキテクチャに答えさせる。あるサービスに異常の識別を集中させつつ、資産に触れる権限を制限することはできる。ユーザーはサービスを乗り換えても、自分の資産ポリシーと検証記録を失わないようにすべきだ。

最も重要な受け入れの問いはこれだ。業務サービスが侵害された後、どの独立した層がなおそれを拒否できるのか。すべての層が同じ管理鍵を共有しているなら、いわゆる階層は配備図の上の階層にすぎない。

この目標は、五つの層の職責として捉えられる。取引サービスが要求を提出し、ウォレットがユーザーの意図を表現し、独立したポリシーが資産処分権を限定し、検証コンポーネントが操作と証拠を検査し、決済層が制約を執行して検証可能な記録を提供する。これらは異なるチームが実装でき、依存関係と侵害条件もそれぞれ明示する必要がある。

本稿が提言する目標アーキテクチャ。決済層は資産ポリシーを強制執行しなければならない。ウォレット内の表示は、この制約の代わりにはならない。日常の署名、ルール変更、復旧の権限は分離し、迂回テストを受け入れる必要がある。

六、ユーザーが自分の資産を軽量に検証できるようにする

普通の人が自分の残高と入金を検証するために、チェーン全体の歴史を保存して実行しなければならないべきではないし、ウォレットの裏にある一台のサーバーを信じるしかないべきでもない。サトシ・ナカモトは白書の第8節ですでにSPV、すなわち簡易支払い検証を提案している。BitcoinのBIP-157は、クライアントがフィルタをダウンロードし、自分に関係するブロックを探す方向をさらに探っている。Ethereumにもライトクライアントの設計がある。[[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) つまり問題は、誰も考えてこなかったことではなく、明確なセキュリティ条件を備えた検証能力を、ユーザーが毎日使うウォレットに組み込む必要があるということだ。

アカウント状態の証明をサポートするチェーンを例にしよう。残高を照会するとき、サーバーは残高と証明を同時に返すべきだ。ウォレットはまずそのチェーンのルールに従って短いブロック摘要、すなわちブロックヘッダを検証し、次にこの残高が摘要の約束するデータと一致するかを確認する。サーバーが答えを提供し、ウォレットが答えを検証できる。BitcoinのSPVが検証するのは、関連する取引が取り込まれた証拠であり、この残高証明をそのまま流用することはできない。ウォレットはまた、どこまで同期したのか、どの情報が検証済みなのかを明確に示すべきだ。証明が欠けている場合、データが古い場合、出所が矛盾する場合は、警告するか、そうした情報に依存する高リスク操作を停止すべきであり、黙って盲目的な信頼に戻ってはならない。

軽量検証にも条件がある。ある取引がブロックに取り込まれたことを証明しても、そのブロック内の全取引が合法であることを自分で検査したことにはならない。方式によっては、多数のハッシュパワーが正直であること、あるいは信頼できる初期記録、すなわちチェックポイントに依存し得る。サーバーがデータを隠すことや、ユーザーを古いチェーン記録に隔離することへの防御も必要だ。照会そのものが、ユーザーの関心のあるアドレスを露出しないかも対処が必要である。フルノードとブロック生成者は同じ役割ではなく、今日のEthereumのブロック生成はマイナーではなくバリデータを使う。

さらに重要なのは、「オンチェーンでこの送金が確かに起きた」という証明は、「これがまさにユーザーの望んだ送金だ」という証明にはならないことだ。ライトクライアントは、前述の資産制限と署名検査の代わりにはならない。それはユーザーが、検証できない一つの回答への依存を減らす。資産ポリシーは、有効な署名であっても資産を無制限に処分できないようにする。二つの層を一緒に築くことが、検証能力を参加者の手に分散させることになる。

七、異常検知とセキュリティ検証を公共基盤にする

取引の前に、その操作が資産ポリシーに適合するか、履歴上の行動を突然変えていないかを、誰かが検査すべきだ。明らかな異常は、一時停止や追加審査を引き起こせる。権限の拡大には、別の独立した経路を必要とする。AIが判断に関与することはできるが、ハードルールを越える通行証を得るべきではない。

同時に、攻撃事例、権限テスト、繰り返し実行できる検証ツールを共に維持する必要がある。規範を共有し、実装と検証を独立に保つことが、共通の故障を減らす。財団や取引所にはすでにセキュリティへの投資がある。たとえばEthereum FoundationのTrillion Dollar Security Initiativeだ。[[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) 次に問うべきは、その投資が、他のチームも採用し検査できる公共基盤に変わり得るかどうかである。

これら七つの作業は、絶対的な安全を保証するものではない。それらが届けるべきは、検査可能な境界だ。どの権限が侵害された条件下で、資産は最大どれだけ露出し、異常はどれだけ早く発見でき、復旧はなお誰に依存するのか。

AIが可能にするソフトウェアエンジニアリング：私たちのA New Hope

ここまで読んで、こう言う人がいるかもしれない。方向性はどれも正しく聞こえるが、業界はもう何年も歩いてきた。作り直すにはどれだけの人と時間がかかるのか。これではやはり理想論ではないか、と。

過去のソフトウェア生産方式で見積もるなら、この疑問はきわめて現実的だ。だが2026年になった今、coding agentsとAIが可能にするソフトウェアエンジニアリングは、私たちが動員できる建設能力をすでに変えたと私は考える。ここで言うcoding agentsとは、開発環境でコードを読み書きし、ツールを呼び出し、テストを実行し、フィードバックに基づいて作業を続けられるAIプログラミングアシスタントだ。建設者は目標を掲げ、安全境界を定め、こうしたツールを使ってシステムを実装・検査し、結果に責任を負う。

かつては大きなチームが繰り返し実装し、適応させ、維持する必要があった作業を、今は小さなチームがこの新しいエンジニアリング手法で試せる。一つのチームが一つの層を守り、明確なインターフェースをめぐってコンポーネントを届け、それを他のチームが検査し組み合わせる。人のアーキテクチャ判断、coding agentsの実装能力、独立したセキュリティ検証を組織することこそ、真剣に再評価する価値のある建設経路だと私は考える。

AnthropicとPNNLの研究は、具体的な例を示している。限定された重要インフラの模擬環境で、研究者は、攻撃の再構築が数週間かかり得たところから約3時間に短縮されたと報告した。[[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) これは、小さなチームがすでに業界全体を安全に書き換えられることを証明するものではない。だが、かつて高コストだった検証と攻防の作業に、新しいコスト条件が生まれ得ることを示している。

今すぐ始められる組織の作り方がある。Build in PublicのAI Factoryを共に建設することだ。業界の専門家、学者、実務者が公開の場で要件と受け入れ規範（spec）を書き、何を守り、どの操作を許し、どの権限が侵害された後もどの境界を守り続けるのかを述べ、その要求を「受け入れテスト」として書く。coding agentsの群れが、主要なコーディング、テスト、デバッグを担う。異なるチームが設計と結果を検査し、人が判断と受け入れの責任を負う。

参加者は、アイデア、マシン、計算資源、そしてモデル呼び出しの枠、すなわちAI tokensを提供できる。AIやクラウドの企業も、モデル枠、計算資源、ツールの提供で、この公共の建設を支えられる。Spec、プロトタイプコード、agentのワークフロー、テスト環境、検証結果は、共同で維持される基盤になり得て、次のチームがそのまま続きをできるようにする。目標は、開発能力を繰り返し使える公共施設として築き、特定の誰かの時間や特定のチームへの依存を減らすことだ。

攻撃者もAIを使っている。防御を過去の生産方式に留めておく理由は、もうない。[[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) しかしコードが速く生成されることは、出発点にすぎない。制約を明確に書き、テストを繰り返し実行でき、コンポーネントを検査し差し替えられるようにして初めて、AIの能力はインフラの改善に変わる。

独立した建設者が、coding agentsとAIツールを借りて共に働く。宇宙工房は公共建設のメタファーだ。

私は特に、この呼びかけを、それでもなお作ることを愛する人たちに贈りたい。ここで言うhackerとは、システムがどう動くかを理解しようとし、発見を共有し、自分の作品を他人に検証してもらうことを厭わない人のことだ。そうした精神がかつてインターネットを進め、今日はCryptoも進められる。

私はこの業界に聡明な人が足りないとは思わないし、CryptoとAIの業界がこの仕事を支えるリソースを見つけられないとも思わない。より難しいのは、人材、資金、持続する責任を組織としてまとめることだ。財団や能力のある企業は、直接収益を生まないがすべての人が恩恵を受ける基盤的な仕事に対して、長期的なコストを負担する意思を持つべきである。

私は、みんなで世界で共有される暗号インフラの一式を共に作り上げたいと願っている。異なるネットワークとチームが共通のセキュリティ制約のもとで協働し、それぞれが実装し、互いに検証し、ユーザーは選択し移行できる。それは一つのコンポーネントから始められるが、方向は十分に大きく、業界全体が共に建設できるものであるべきだ。ArcBlockを含め、参加者は検証可能な貢献を示すべきである。

私たちは共に、ある場所がすでに侵害されていても資産には境界があり、他のシステムはなお誤りを拒否でき、ユーザーには復旧と離脱の経路が残る、そんなインフラを築くべきだ。『スター・ウォーズ』の名を借りれば、これが私たちのA New Hopeだ。[[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) 希望は、行動しようとする普通の建設者から来る。また、coding agentsと新しいエンジニアリング手法によって、彼らがより多くの建設作業を担えるようになったこの瞬間からも来る。

今すぐ行動しよう

私は、Ethereum、Solana、Bitcoin、XRP Ledgerなどのプロジェクトの建設者に、Binance、Coinbase、Krakenなどの取引所に、そしてウォレット、プロトコル、セキュリティ研究、AI、クラウドのチームに呼びかける。範囲の明確なパイロットから始め、他のチームも採用し検証できる改善を共に生み出そう。

列挙は例示にすぎず、順序に意味はない。規模の大小、どの技術路線を採るかを問わず、参加を歓迎する。この招待には、本文で批判した技術路線の建設者も含まれる。資産安全を共に改善することは、それぞれのエコシステムの境界を越える価値がある。

私自身も参加し、私たちが持つ基盤アーキテクチャ、ソフトウェアエンジニアリング、AI協働の実践を提供する意思がある。 私たちは業界の小さなチームにすぎず、できることは限られている。一つのプロトタイプと、繰り返し実行できるテストの組から始めたい。

実際の運営経験のある人は、匿名化した攻撃シナリオを提供できる。ウォレットとプロトコルのチームが保護を実装し、独立した研究者がそれを迂回しようとする。各チームが能力の及ぶ部分を担い、共に方策を検証し、次の一歩を決める。

私は、本文の資産制限と復旧要件を最初の公開specにまとめることに参加し、関連する技術とエンジニアリングの実践も提供し、他の参加者と共にこのパイロットに向けた公共のAI Factoryを立ち上げる意思がある。まず、非常に具体的な問題を一つ選ぶ。日常取引用の鍵がすでに侵害されたとき、どうすれば攻撃者は依然としてウォレットを一度に空にできないのか。許容される損失の範囲、ルール変更の権限、復旧条件を「受け入れテスト」として書き、開発agentsにプロトタイプを実装させ、別のagentsの組と独立した研究者が迂回経路を探す。データサーバーが誤った残高を返す場合や、デバイスを失った後の復旧も、段階的にテストに加えられる。プロトタイプが何を達成し、どこで失敗し、どのような依存が残るのかは、すべて公開の場で説明し、そのうえで証拠に基づいて次の一歩を決める。

参加を希望する人は、Xでこの提言を公開で転送または引用し、@mave99a にメンションして、解決したい問題、匿名化した攻撃事例、提供できるリソースを語ってほしい。議論は公開で行い、より多くの建設者が見て、続いて参加できるようにしたい。

Cryptoはもう、このままではいけない。一緒にやる気のある人は、今すぐ行動を起こし、作ることができ、検証に耐える一つの改善から始めよう。

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)、順序付けの仕組み、異なる種類、負の影響；「bugとして修正すべき」は、ユーザーを害する行為に対する著者のエンジニアリング上の主張である。 [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
PHP公式2026年ニュースアーカイブ；CISA 2026-10-26の既知の悪用脆弱性更新、CVE-2026-109618、CVE-2026-109619。 [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe、Guardsと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: Partially Signed Bitcoin Transaction Format、未署名取引の交換フォーマットであり、チェーンをまたぐ汎用の資産ポリシー規範ではない。 [↩](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年報、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、独立投稿の説明用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)

Cryptoはもう、このままではいけない：ブロックチェーン従事者による業界自救の提言