もしあるコントラクトがプロキシパターンを使っておらず、アップグレードできないなら、それはより安全だということを意味するのか？
方向性としては正しいが、絶対的なものではない。アップグレードできないコントラクトは、確かに「チームが事後にロジック全体を入れ替える」という攻撃経路を排除する——オンチェーンにデプロイされたコードは永遠にそのままの形を保つ。これはアップグレード可能なコントラクトに対する明確な優位性だ。Uniswap V3を例に取ると、そのコアコントラクト（Factory、Pool、NFT Position Manager）は意図的にアップグレード不可能な設計となっており、3年以上の実戦での検証を経ている。この設計思想自体が一種の安全に対するコミットメントと言える。
しかしアップグレード不可能であることは、管理権限のリスクがゼロであることを意味しない——一部のコントラクトはコアロジック自体を入れ替えることはできなくても、他の形の管理者権限を保持していることがある。例えばコントラクトの動作を一時停止する、手数料パラメータを調整する、特定のアカウントを凍結するといった機能だ。こうした権限も同様に少数の人の手に集中し、悪用される可能性がある。だからこそ確認のポイントは「これはプロキシコントラクトかどうか」だけで止まってはならず、さらに踏み込んで、コントラクト内にonlyOwnerや類似の修飾子で保護された関数が他に残っていないか、それらの関数が実際に何をできるのかまでを確認する必要がある。それこそが完全な全体像なのだ。
マルチシグは単一の秘密鍵よりもはるかに安全に聞こえるが、マルチシグを見かけたら安心してよいのか？
マルチシグが単一のEOAアドレスよりも安全であることは確かで、その方向性自体は間違っていない——複数の独立した鍵が共同で署名して初めて操作が実行されるため、単一の秘密鍵の漏洩だけでは損失を招くには不十分であり、これこそがMultichain事件で欠けていた保護層だ。しかしマルチシグ自体の安全性は、いくつかの見落とされやすい細部にも左右される。第一は閾値の設定だ。「5分の2」のマルチシグは、5つの鍵のうちわずか2つがあれば承認が通ることを意味する。もしこの5つの鍵の実際の管理者が互いに顔見知りで、密接な関係にある場合（例えば全員が同じチームの中核メンバーであるなど）、このマルチシグが「内部での共謀」というリスクに対して発揮する実質的な保護力は、表面上の「5者による相互牽制」という印象よりもはるかに低くなる可能性がある。
第二は、これらの鍵の保有者が本当にそれぞれ独立して鍵を管理し、適切に保管しているかどうかだ——もし複数の鍵の保有者が、実際には秘密鍵を同一人物や同一のシステムに預けて管理させているなら、マルチシグは書面上は高い閾値に見えても、実際の攻撃対象面は単一の秘密鍵とさほど変わらない可能性がある。マルチシグを検証する際は、そのマルチシグウォレットの過去の署名履歴を確認し、毎回異なるアドレスが実際に署名を完了しているかどうかを見ることに価値がある。これは単に「これはマルチシグアドレスだ」と確認するよりも、実際の分散度をはるかによく反映している。
タイムロックによる1〜2日の発効遅延は、悪意あるアップグレードを本当に効果的に阻止できるのか？
タイムロックの保護力は、その遅延期間が実際に「意味のある監視」に使われているかどうかにかかっており、遅延そのものが自動的に保護効果を生むわけではない。もしあるアップグレード提案がタイムロック内で48時間待機している間、誰も、いかなる監視システムも、その期間中に実行待ちで並んでいる提案の内容をチェックしていないなら、この48時間は単なる純粋な待機時間に過ぎず、自動的に防御へと変わることはない——これこそが一部のセキュリティ研究者が、タイムロックは「実際に誰かが見ている」という前提があって初めて本当の保護効果を発揮するのであり、タイムロック自体を万能薬として扱うべきではないと強調する理由だ。
さらに注目すべきは、タイムロックの遅延メカニズムは通常、ブロックチェーンのタイムスタンプ（block.timestamp）に基づいて計算されており、ブロックチェーンのバリデーターにはこのタイムスタンプを小さな範囲（通常は±15秒以内）で操作する余地があるという点だ——この誤差範囲は24時間から48時間という遅延設計に比べればはるかに小さく、攻撃者がタイムロックを実質的に回避するには不十分だが、これはタイムロックが提供するのは「発見される確率を大幅に高めること」であり、暗号学的な、絶対に回避不可能な数学的保証ではないことを思い出させてくれる。本当にすべきことは、この公開された遅延期間を活用し、プロトコルのガバナンスフォーラムやマルチシグウォレットの記録を能動的に確認して、すでに待機中だが実行されていないアップグレード提案がないかを見ることであり、タイムロックが自動的にすでにチェックを完了してくれていると仮定することではない。
資金をあるプロトコルに預ける前、実際にこうしたガバナンス権限に関する詳細をどの順序で確認すべきか？
第一のステップは、まずコントラクトがプロキシかどうかを確認することだ——Etherscanでコントラクトページを開き、「Contract」タブを見て、「This is a proxy contract」というバナーがあるかを確認する。プロキシコントラクトでなければ、さらに他のonlyOwnerで保護された高リスク関数（一時停止、アカウント凍結、パラメータ調整など）がないかを確認できる。プロキシコントラクトであれば、次のステップとしてアップグレード権限が誰の手にあるかを必ず確認する必要がある。
第二のステップは、ownerまたはadminのアドレスを見つけ、そのアドレスをコピーしてEtherscanで検索し、それが一般的なEOAウォレットなのか、それともGnosis Safeのようなマルチシグコントラクトなのかを確認することだ。EOAであれば、アップグレード権限は単一の秘密鍵に集中しており、リスクレベルは最も高い。マルチシグであれば、さらにその署名閾値（何分の何か）と過去の署名履歴を確認し、実際に署名に参加しているアドレスが本当に多様で独立しているかを確かめる。第三のステップとして、タイムロックコントラクトが見つかった場合は、設定されている遅延時間の長さを確認し、プロトコルのガバナンスフォーラムやブロックエクスプローラーを能動的にチェックして、すでに待機中だが実行されていないアップグレード提案がないかを見る。この3つのステップを合わせることで、資金を預ける前に、「このプロトコルのロジックは自分の同意なしに入れ替えられる可能性があるか、入れ替えるには何人の同意が必要か、事前に発見する機会はあるか」といった問いに対して、具体的で検証可能な答えを得ることができる——「このプロトコルは大手っぽいから安全だろう」といった曖昧な印象に頼るのではなく。
2023年7月6日、クロスチェーンブリッジプロトコルMultichain（旧称Anyswap）は、わずか数時間のうちに約1億2,600万ドル相当の資産を流出させ、Fantom、Moonriver、Dogechainなど複数のチェーン上のブリッジ流動性プールがほぼ同時に空にされた。ブロックチェーンセキュリティ企業CertiKは事後、この事件の原因が秘密鍵の侵害であると確認し、「これは秘密鍵の漏洩によるものであり、我々が過去に実施した監査の範囲外である」と直接述べた——そしてCertiKは実際にMultichainを2度監査しており、いずれの回も重大な問題は指摘していなかった。この発言は、ほとんどのDeFiユーザーが見落としがちな事実を浮き彫りにしている。スマートコントラクト監査が検証するのはコードのロジックに脆弱性がないかどうかであり、そのロジックを完全に迂回して資金を直接動かせる鍵を誰が握っているのか、その鍵を何人が保有しどれほど厳重に保護されているのかまでは、通常教えてくれない。
多くの人はスマートコントラクトが一度オンチェーンにデプロイされれば二度と変更できないと考えているが、実務上は、DeFiプロトコルのコントラクトのかなりの割合が「プロキシパターン」を採用している——ユーザーが実際にやり取りするコントラクトアドレス（プロキシコントラクト）自体は非常にシンプルなロジックしか持たず、すべての呼び出しを実際のビジネスロジックを保持する別のアドレス（実装コントラクト）へ転送するだけの役割を担う。プロトコルチームはプロキシが指す実装コントラクトのアドレスを新しいものに変更するだけで、ユーザーがやり取りするアドレスを一切変えることなく、背後で実行されるコード全体を丸ごと入れ替えることができる。この設計はもともと、ユーザーに資産の移行を強いることなくバグを修正したり機能をアップグレードしたりするための善意の意図から生まれたものだが、同時に、アップグレード可能なコントラクトには必ず「このコントラクトのロジックを入れ替える」権限を握る何らかの主体が存在するということでもある。この権限が攻撃者の手に渡れば、元のコードの中に論理的な欠陥を一切見つける必要もなく、プロトコル全体を直接掌握したのと同じ効果を持つ。2026年版OWASPスマートコントラクトトップ10では、「プロキシとアップグレード可能性の脆弱性」の順位が前年の7位から3位へと上昇しており、これはまさに攻撃者がこの攻撃対象面にますます注目していることを反映している。
あるコントラクトがプロキシかどうかを確認する最も直接的な方法は、Etherscanでそのコントラクトのページを開き、「Contract」タブに切り替えることだ——もしそれがプロキシコントラクトであれば、通常「This is a proxy contract」と書かれたバナーが表示される。EtherscanはEIP-1967標準で定められた、実装コントラクトのアドレスを格納する固定ストレージスロット（アドレスは0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bb）を自動的に読み取り、現在指している実装コントラクトのアドレスを表示してくれる。このバナーが表示されているなら、あなたがやり取りしているロジックは、プロトコルチームによっていつでも入れ替えられる可能性があることを意味する——今日あなたが承認した動作パターンが、明日も同じままである保証はない。
プロキシコントラクトであることを確認したら、次のステップは「誰がアップグレードを実行する権限を持っているか」を突き止めることだ。この役割は通常adminまたはownerと呼ばれる。コントラクトページで管理関連の関数（owner()やadmin()など）を見つけ、それを呼び出すとアドレスが返される。このアドレスをコピーしてEtherscanで検索してみよう。それが一般的な外部所有アカウント（EOA、つまり通常のウォレットアドレス）であれば、アップグレード権限は単一の秘密鍵に握られていることになり、その鍵が漏洩したり保有者が悪意を持って行動したりすれば、プロトコル全体のロジックが瞬時に入れ替えられてしまう可能性がある——これはまさにMultichain事件で起きたことだ。見つかったアドレスがそれ自体コントラクトであり、Gnosis Safeのようなマルチシグウォレットであれば、アップグレードには複数の独立した鍵が共同で署名する必要があり、単一の鍵の漏洩だけではアップグレードを引き起こすには不十分だ。さらにその先にタイムロックコントラクト（TimelockController）が接続されていれば、マルチシグが同意した後でも、公開された遅延期間（一般的には24時間から48時間）を経なければ正式には発効しないことを意味し、この期間中に外部の監視者が不審な提案を事前に察知し、警告を発する機会が生まれる。
Multichainはマルチパーティ計算（MPC）技術を用いて秘密鍵を管理しており、理論上は鍵が複数の断片に分割され、異なるノードに分散して保管されることで単一障害点を回避する設計になっていた。しかし事後の追跡報道によると、2023年5月、Multichainの最高経営責任者である「Zhaojun」氏が中国当局に連行され事情聴取を受け、チームはその後、彼との連絡が取れなくなったことを確認した。そして彼こそが、MPCノードサーバーの操作アクセス鍵を管理していた人物だった。言い換えれば、理論上は分散されているはずのこの鍵システムは、実際の運用においては依然として一人の個人に大きく依存していたのだ。7月6日、ブリッジ流動性プールで異常な引き出しが始まり、当初わずか2ドルのテスト送金から、2時間以内に3,100万ドル相当のWBTCが流出する事態へと発展し、その後MoonriverとDogechainのブリッジプールも相次いで空にされた。この過程で一切のコードの脆弱性は悪用されず、いかなるスマートコントラクトのロジックを迂回する必要もなかった——ただ、本来分散して保管されているはずが実際には一人の手に集中していた、その鍵一つだけが必要だったのだ。