アップグレードできるコントラクトは安全か｜変更権限・待機時間・事故の教訓

2024年10月16日、レンディングのRadiant Capitalが約5,000万USD相当を失いました。コントラクトの権限は、3-of-11のマルチシグ（11人のうち3人の署名で実行できる仕組み）で守っていました。それでも防げなかったのです。

同社の公式の事後報告によると、攻撃者はまず開発者の端末をマルウェアに感染させました。署名に使うSafe{Wallet}の画面には、正しい取引が表示されていました。その裏で、署名者は悪意ある取引に署名させられていたのです。署名者に見えたのは、署名のやり直しを促すエラー表示だけでした。3つの署名がそろうと、LendingPoolAddressesProvider の transferOwnership が実行され、権限が攻撃者に移りました（Radiant Capital: Post-Mortem）。

アップグレードできるコントラクトを設計するとき、議論はプロキシ方式の比較から始まりがちです。しかしRadiantで破られたのは、プロキシの仕組みではありません。署名者の端末と、署名の画面でした。そうした事故まで含めて見ると、安全性を左右するのは次の3つです。

• 誰が変えられるか（権限）
• 決まってから実行まで、どれだけ待つか（待機時間）
• 何が変わるかを、事前に読めるか（可視性）

そのうえで、データの並び（ストレージ）が新旧で合っているかと、初期化を確かめます。EVMでプロダクトを運用している、あるいはこれから公開するチームの技術責任者なら、公開前にこの3つを決めておく必要があります。以下では、ERC規格、OpenZeppelinの仕様、L2の運用基準、実際の事故を手がかりに、それぞれの決め方を見ていきます。

この記事でわかること

• 権限・待機時間・可視性の3つを、どう決めるか
• Radiant、Tornado Cash、Beanstalkの事故で、どれが破られたか
• 公開前に決めておく12項目のチェックリスト

安全性を決める3つ：誰が、どれだけ待って、何を変えるか

冒頭のRadiantのように、事故は方式の外でも起きます。そのため利用者や取引先から見た危なさは、プロキシ方式よりも次の3つで決まります。これに、方式ごとの制約、初期化、ストレージの互換性の確認を加えます。

それぞれがコードのどこにあたるかは、後半の「実装する人向けの詳細」にまとめました。

この3つは、互いの代わりになりません。マルチシグの署名者を増やしても、待機時間は生まれません。待機時間を延ばしても、何が変わるか読めなければ、利用者は判断できません。

逆に、3つがそろっていれば、アップグレードできること自体は欠陥とは限りません。「変更できる」ことと「気づかれずに変更される」ことは、別の問題です。

OWASPのSmart Contract Top 10の2026年版は、SC01にAccess Control Vulnerabilities（アクセス制御の脆弱性）を挙げました。SC10には、Proxy & Upgradeability Vulnerabilities（プロキシとアップグレードの脆弱性）が新たに入っています（OWASP Smart Contract Top 10: 2026）。コードの不具合だけでなく、権限と変更手続きの設計がリスクとして明示されたわけです。3つの軸を先に決める理由はここにあります。

プロキシ方式で決まること、決まらないこと

方式の選択に意味がないわけではありません。方式で決まるのは、差し替えの権限をプロキシ側・実装側・ビーコンのどこに持たせるかと、1回の差し替えがプロキシ1つに届くのか、多くのプロキシにまとめて届くのかです（下の表）。変更までどれだけ待つか、何が変わるかを読めるかは、どの方式にも含まれていません。そのため、待機時間と可視性は方式の外で作る必要があります。

どの方式にも共通の土台がERC-1967です。プロキシが参照する実装・ビーコン・管理者のアドレスを、決まった保存場所（ストレージスロット）に置くと定めた規格で、ステータスはFinalです。

なぜ決まった場所に置くのか。規格は、プロキシが実装の関数とぶつかりうる関数を利用者に見せるべきではない、と説明しています（ERC-1967: Proxy Storage Slots）。スロットの具体的な値は、末尾の「よくある質問」に載せました。

この仕様は、可視性の土台にもなります。保存場所が標準で決まっているので、第三者でも外から読み取れます。そのアドレスがアップグレードできるのか、管理者は誰か、です。実装が差し替わるたびに Upgraded(address indexed implementation) というイベントが出ることも、規格で定められています。

方式ごとの違いは、次のとおりです。

設計で気をつける点も、方式ごとに違います。

• Transparent Proxy：管理者と利用者で呼び出しの扱いを分ける。関数セレクタ（関数を見分ける短い識別子）がぶつかることを前提にした設計。
• UUPS：アップグレード機能を持たない実装に差し替えると、以後はアップグレードできなくなる。
• Beacon Proxy：1つの権限で多くのインスタンスが同時に変わる。権限の重みが最も大きい。
• Diamond：変更の単位が細かいぶん、差分の説明と検証が難しくなりやすい。

OpenZeppelinはTransparent Proxyについて、こう書いています。「このパターンは引き続き提供するが、推奨は軽量で汎用性の高いUUPSへ移りつつある」（OpenZeppelin Contracts 5.x: Proxy）。同じページには注意書きもあります。アップグレードできるプロキシを正しく安全に使うのは難しく、プロキシパターン、Solidity、EVMへの深い理解が要る、という内容です。

Diamondが選ばれるのは、24KBのコントラクトサイズ上限を超える規模のときです。機能ごとに追加・置換・削除したいときにも使われます。facetは、機能ごとに分けた実装コントラクトです。facets() などのloupe関数（今の構成を照会する関数）で、どの関数がどのfacetにあるかを調べられます。DiamondCutイベントは変更の履歴になります。

ただし規格自身が、「diamondの所有権・認証の設計と実装は、この規格の対象ではありません」と書いています（ERC-2535: Diamonds, Multi-Facet Proxy）。どの方式を選んでも、権限の設計は自分で決めることになります。

アップグレード権限を誰に持たせるか

権限の持たせ方には段階があります。1つのEOA、マルチシグ、タイムロックを挟んだマルチシグ、オンチェーンガバナンスとタイムロックの組み合わせ。この順に、1人の意思ですぐ実行できる度合いが下がります。1つのEOAでは、その鍵1本をなくすか盗まれるだけで、すぐに実装を差し替えられてしまいます。そのため、本番運用に入る前にこの状態をやめる。これはほぼすべての事例に共通する基本です。

署名者を11人に増やしても、実行までの待機時間は1秒も増えません。マルチシグは権限を分ける仕組みで、時間を稼ぐのはタイムロックの役目だからです。役割が違うので、片方でもう片方の代わりはできません。

閾値の数字だけでも足りません。冒頭のRadiantは、閾値3-of-11でも防げませんでした。事故の後、同社は閾値を4-of-7に変え、アップグレードに72時間のタイムロックを入れました。取引の中身をEtherscanのデコーダーで手で確かめる手順も加えています。

この事故から分かるのは、閾値が実際に効くかどうかの条件です。署名者が何に署名しているかを、それぞれ独立に確かめられるか。同じ端末構成、同じ署名画面、同じ手順で動く署名者は、独立した承認者として数えにくくなります。署名者の人数、鍵の保管方法、確認手順の独立性は、閾値と同じ重みで検討します。鍵の保管と日々の運用は、マルチシグ・タイムロックによる本番権限管理で詳しく扱っています。

待機時間は、利用者が抜け出せる時間から逆算する

「タイムロックは何日にすべきか」に、一律の正解はありません。逆算で決めます。利用者が変更に気づくまでの時間と、資金やデータを引き上げ終えるまでの時間を足します。待機時間は、それを下回らないようにします。

この考え方には、実在の運用基準があります。L2BEATのStagesは、Stage 1の条件をこう定めています。Security Council以外が起こすアップグレードは、少なくとも7日のexit window（利用者が抜け出せる猶予）がある場合に限って認める。Stage 2では、DAOが起こすものも含め、望まないアップグレードに対して利用者に少なくとも30日の退出時間を与えるべき、としています（L2BEAT: Stages）。

出金そのものに遅れがある場合は、その分を差し引きます。L2BEATの用語集は、強制トランザクションの遅延などがあれば、その分だけ退出の猶予が減るとしています（L2BEAT: Glossary）。

Arbitrum DAOの憲章は、もっと具体的な時間の割り振りを公開しています。Security Councilは、緊急対応と定期的な更新を担う12名の委員会です（6名ずつ2つのグループ）。9-of-12の承認があれば、待たずに緊急対応を実行できます。

一方、憲章にかかわるAIP（Constitutional AIP）は、温度感の確認から実行まで少なくとも42日かかります。内訳は次のとおりです（The Amended Constitution of the Arbitrum DAO）。

• L2での8日の待機
• L2からL1へのメッセージに伴う、ロールアップのチャレンジ期間1回分以上
• L1での3日の待機

これらの数字を、そのまま自社に持ち込む必要はありません。ちょうどよい長さは対象によって変わります。DEXの流動性提供者なら、数時間で抜けられる場合があります。企業間のデータ連携で相手側の承認手続きが挟まるなら、営業日単位になります。L2の出金なら、チャレンジ期間そのものが退出にかかる時間に加わります。決めるべきは日数そのものではなく、その日数を導いた前提です。

緊急時にすぐ止める権限をどう持つか

脆弱性が見つかっても、7日のタイムロックがあれば、修正を入れるまでに7日かかります。その7日間は、攻撃できる時間になりえます。待機時間は、攻撃者にも猶予を与えるのです。

そこで実務では、権限を2つに分けるのが基本です。資産の移動や実装の差し替えはできない、小さな「止める権限」はすぐ使えるようにします。「変える権限」は、待機時間付きで別に持たせます。

Arbitrumの9-of-12による即時実行は、この割り切りをはっきり示した例です。同時に、閾値を満たす人たちが結託すれば、すぐに何でも変えられる。その前提を利用者に開示していることにもなります。

緊急経路は、待たずに実行できる権限です。24時間の対応体制、監視と通知、事後報告の手順がそろっていなければ、「いつも開いている抜け道」に近づきます。止める範囲、権限の分け方、解除の条件はスマートコントラクトの緊急停止設計で扱っています。投票からタイムロックまでの実行の設計はDAOガバナンスの実行設計をご覧ください。

承認した内容と、実行される内容を一致させる

権限と待機時間を整えても、承認の対象があいまいだと働きません。実際の事故は、承認したものと実行されたものの一致が崩れたところで起きています。

Tornado Cashのガバナンスは、2023年5月に乗っ取られました。手口はこうです。攻撃者はまず、CREATE2（配置先のアドレスを前もって決められる命令）で置いたコントラクトから、CREATEで提案コントラクトを置きました。CREATEのアドレスは、配置元とnonceだけで決まります。この2段構えで、中身のバイトコードが何であっても同じアドレスを再現できる状態を作ったのです。

提案には、自分を破棄する関数が仕込まれていました。攻撃者は投票が通った後にこれを実行し、コードとnonceを消しました。そして同じアドレスに、別のバイトコードを置き直しました。それが可決済みのアドレスとして実行され、攻撃者は1,200,000票を得てガバナンスを握りました（Composable Security: Understanding the Tornado Cash Governance Attack）。

投票で承認されたのは、アドレスだけでした。実行するときに、そこにあるコードが承認したときと同じかは確かめていなかった。これが原因です。

この手口には、その後の仕様の変更がかかわります。EIP-6780で、SELFDESTRUCTの動きが変わりました。アカウント・コード・ストレージを消すのは、そのコントラクトが作られたのと同じトランザクションの中で実行された場合に限られます。ステータスはFinalで、Dencun（Cancun-Deneb）の一部として2024年3月13日にEthereumメインネットで有効になりました（EIP-6780、Ethereum History）。

そのため、Cancun相当を適用済みのチェーンでは、同じアドレスに別のコードを置き直すこの手口は、そのままでは成り立ちません。ただし、Cancun相当を適用していないEVMチェーンでは事情が違います。また、承認したものと実行されるものがずれる問題そのものは、別の形で残ります。外部設定を後から差し込む、delegatecall（別のコントラクトのコードを自分の状態で実行する呼び出し）の先を差し替える、などです。

もう1つの型は、承認そのものを一瞬で作り出すものです。Beanstalkの emergencyCommit は、条件を満たす提案をすぐ実行できました。条件は、24時間以上たっていて、ステーキングされた投票力の3分の2以上を持つことです。投票力は、その時点の預け入れ残高からすぐ計算されていました。

攻撃者は2022年4月17日、約10億USD相当のフラッシュローン（同じ取引の中で借りて返す融資）で、一時的に超過多数を作りました。そして同じトランザクションの中で、提案を可決・実行したのです。失われたのは約1億8,100万USDで、そのうち非BEAN資産で約7,700万USDが持ち出されました（Immunefi: Hack Analysis — Beanstalk Governance Attack, April 2022）。

設計での対応は2つです。投票力を、提案した時点の記録（チェックポイント）で固定すること。可決から実行までに、必ず待機時間を置くことです。つまり、1つのトランザクションで投票と実行が終わる道を残さないことです。

3つの事故は、それぞれ別の軸が破られていました。

直接の原因は、表の上から順に次のとおりです。

• Beanstalk：投票力をその場で計算し、同じトランザクションで可決・実行できた
• Tornado Cash：承認の対象がアドレスだけで、実行時のコードを確かめていなかった
• Radiant：署名者の端末が侵害され、画面の表示に頼って承認していた

実務で可視性を作る手段は限られています。そのぶん確実です。

• 実行前に、新しい実装のアドレス、検証済みのソース、旧実装との差分、ストレージの並びの差分を公開する。
• 承認時に記録した extcodehash（そのアドレスにあるコードのハッシュ）を、実行時に照らし合わせる。
• ERC-1967の Upgraded やERC-2535の DiamondCut を監視し、想定外の変更に気づけるようにする。
• 署名者は画面の表示ではなく、デコードした生のcalldataを確かめる。

最後の項目は、Radiantが事故の後に運用へ組み込んだ手順と同じです。変更の検知と影響の分析はDeFiガバナンス変更の監視と影響分析、署名前にcalldataの結果を確かめる仕組みはオンチェーン取引シミュレーションの実装設計で扱っています。

実装で壊れやすいのは、ストレージの並びと初期化

権限と手続きを整えても、差し替えたコードが今の状態を読み違えれば意味がありません。OpenZeppelinが示す、アップグレードできるコントラクトの制約は次のとおりです（OpenZeppelin Upgrades: Writing Upgradeable Contracts）。

• コンストラクタを使えない：初期化は initialize 関数で行い、親コントラクトの初期化関数は手で呼ぶ。
• 宣言時の初期値が反映されない：constant を除き、値は初期化関数の中で設定する。
• 実装コントラクトを初期化済みにしておく：実装のコンストラクタで _disableInitializers を呼び、第三者が初期化できないようにする。
• selfdestruct と delegatecall を使えない：実装が破棄されると、それを参照する全プロキシが動かなくなる。
• 状態変数の宣言順と型を変えられない：変えると既存の値が混ざり、致命的な誤りにつながる。追加の余地は __gap か、ERC-7201で確保する。

ERC-7201は、最後の制約を扱いやすくする規格です。名前ごとに保存場所を分けるので、継承の関係を変えても既存の変数の位置がずれません。ステータスはFinalです（ERC-7201: Namespaced Storage Layout）。保存場所の求め方は後半に載せました。

「プロキシさえ守ればよい」とは言えない例もあります。2021年には、OpenZeppelinのアップグレード用ライブラリで重大な脆弱性が公開されました。初期化されていないUUPSの実装コントラクトを第三者が初期化して所有し、そこから実装を破棄できる状態でした。Transparent Proxy側でも、関数セレクタがぶつかったときに呼び出しが委譲されない問題が見つかっています。どちらもすでに修正済みで、番号と対象バージョンは後半にまとめました。

こうした問題は、目で見るレビューだけでは見落としやすいものです。そこで、ストレージの並びの差分をCIで自動検証するのが基本になります。OpenZeppelin Upgrades PluginsのHardhat / Foundry向けの検証機能は、その1つです。

今の状態を保ったまま構造を変えたい場合はアップグレード可能なコントラクトのデータ移行を、ビルドから本番反映までの変更管理はスマートコントラクトのリリース管理をご覧ください。形式検証で確かめるべき範囲の見極めは、スマートコントラクトの形式検証｜採用すべき範囲と判断基準で扱っています。

権限を持ち続けるか、減らしていくか

アップグレードできないようにすれば、権限を悪用される心配はなくなります。ただ、直す手段もなくなります。脆弱性が見つかったとき、できるのは新しいコントラクトへ移り、利用者に移行をお願いすることだけです。移行のあいだ、古いコントラクトに残る資産は守れません。そのため、「アップグレードできないようにする」ことが、いつも安全とは限りません。

一方で、権限を持ち続けること自体が求められる分野もあります。移転の制御や凍結の機能が、業務や規制の要件になっている場合です。権限を手放すと、要件を満たせなくなります。権限を前提にしたトークン設計の考え方は、ERC-3643の仕組みと実装で整理しています。

権限を少しずつ減らすなら、動かせるのは次の4つです。1つだけ使うことも、組み合わせることもできます。

1. 時間を延ばす：待機時間を延ばし、退出の猶予を広げる。コードを変えずに調整しやすい。
2. 範囲を狭める：パラメータの変更とコードの差し替えを別の権限にし、差し替えられる範囲を絞る。Diamondならfacetごとに絞れる。
3. 持ち主を移す：開発チームのマルチシグから、独立した委員会やオンチェーンガバナンスへ移す。
4. 止める：UUPSなら _authorizeUpgrade が必ず失敗する実装に差し替える。Transparent Proxyなら ProxyAdmin の所有権を放棄する。どちらも元に戻せない。

どこまで進めるかは、条件しだいです。

• 預かる資産の規模と、利用者が一般の人か契約関係のある企業か
• 利用者が実際に抜け出せるか、監査と監視の体制
• 緊急時に対応する人を、いつでも確保できるか

判断の材料は、2つのリスクの比較です。権限を持ち続けた場合に悪用されるリスクと、持たない場合に復旧できなくなるリスク。自社の利用者にとって、どちらが大きいかです。

利用者にとって先を読みやすくするなら、ゴールと条件を先に公表しておく方が有利です。たとえば「監査が終わったらタイムロックを72時間から14日へ延ばす」「稼働から1年で差し替え権限を委員会へ移す」。こうして条件を示しておけば、途中の状態も利用者が評価できます。

公開前に決めておく項目

次の項目は、設計レビューの場でそのまま埋められる細かさにしています。全部を満たすことだけが正解ではありません。ただ、埋まらない項目は、まだ決めていない設計判断が残っている箇所です。

よくある質問

あるコントラクトがアップグレードできるかどうかを、外から確かめられますか

確かめられます。ERC-1967に準拠していれば、実装アドレスは 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc、管理者アドレスは 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 のストレージスロットに入っています。eth_getStorageAt で読み取れます。値が入っていればプロキシで、実装は差し替えられます。

ただし、ERC-1967に準拠しない独自の実装、ビーコンを介する構成、Diamondでは読む場所が違います。値がゼロでも、アップグレードできない証明にはなりません。ソースコードの検証状況とあわせて確かめてください。

アップグレードすると、利用者の残高や設定は消えますか

ふつうは消えません。プロキシ方式では、状態はプロキシ側のストレージに残り、差し替わるのは実装のコードだけです。

ただし、新しい実装で状態変数の宣言順や型が変わっていると、同じスロットを別の意味で読むことになります。残高や権限を、誤った値として解釈するおそれがあります。これは消えるのではなく、読み違える問題です。そのため、アップグレードの安全性はストレージの並びの差分検証にかかっています。

一度アップグレードできるようにしたコントラクトを、後から変えられないようにできますか

できます。UUPSなら、_authorizeUpgrade が必ず失敗する実装に差し替えれば、以後のアップグレードを止められます。Transparent Proxyなら、管理者である ProxyAdmin の所有権を放棄する方法があります。

どちらも元に戻せません。実行する前に、脆弱性が見つかったときの代わりの手段を用意しておきます。新しいコントラクトへの移行手順と、利用者への知らせ方です。権限を段階的に減らしてから最後の段階として実行する方が、利用者にとって先を読みやすくなります。

実装する人向けの詳細

ここからは、実際にコントラクトとCIを組む担当者向けに、前半で後回しにした規格の細部をまとめます。

3つの軸は、コードのどこにあるか

ERC-1967のスロットの位置

実装スロットと管理者スロットは、どちらも keccak256 の値から1を引いた位置です。具体的な値は「よくある質問」の1問目にあります。

ERC-7201の保存場所の求め方

名前空間ごとに、ストレージの位置を次の式で求めます。

keccak256(abi.encode(uint256(keccak256(bytes(id))) - 1)) & ~bytes32(uint256(0xff))

注釈は @custom:storage-location erc7201:<NAMESPACE_ID> の形で付けます。規格は2023年6月20日に公開されました。

OpenZeppelinで公開された2つの脆弱性

• GHSA-q4h9-46xg-m3x9（2021年9月15日公開）：@openzeppelin/contracts-upgradeable の >=4.1.0 <4.3.2 で、初期化されていないUUPSの実装を第三者が初期化・所有し、実装を破棄できた。深刻度はcriticalで、4.3.2で修正。EIP-6780の適用後は破棄そのものは再現しにくいが、実装の所有権を第三者が取れる状態は解消していない。
• GHSA-mx2q-35m2-x2rh（2023年4月17日公開）：Transparent Proxyで、セレクタが衝突したときに呼び出しが委譲されない問題。4.8.3で修正。

XTELAができること

私たちは、EVM上のプロダクトについて、アップグレード権限の置き場所、タイムロックと緊急停止の分け方、承認内容と実行内容をコードハッシュで照合する運用手順、ストレージレイアウト検証を組み込んだCIを設計・開発します。プロキシ方式やタイムロックの日数は決め打ちせず、貴社の利用者が退出に要する時間と運用体制から逆算してPoCで確かめます。設計中の構成を具体的に確認したい場合は、お問い合わせフォームからご連絡ください。

主要参考資料

• ERC-1967: Proxy Storage Slots
• ERC-2535: Diamonds, Multi-Facet Proxy
• ERC-7201: Namespaced Storage Layout
• EIP-6780: SELFDESTRUCT only in same transaction
• ethereum.org: History and forks of Ethereum
• OpenZeppelin Contracts 5.x: Proxy
• OpenZeppelin Contracts 5.x: Governance（TimelockController）
• OpenZeppelin Upgrades: Writing Upgradeable Contracts
• GHSA-q4h9-46xg-m3x9: UUPSUpgradeable vulnerability
• GHSA-mx2q-35m2-x2rh: TransparentUpgradeableProxy clashing selector
• OWASP Smart Contract Top 10: 2026（2026年9月24日確認）
• L2BEAT: Stages（2025年7月23日最終更新、2026年9月24日確認）
• L2BEAT: Glossary（exit windowの定義。2026年9月24日確認）
• The Amended Constitution of the Arbitrum DAO（2026年9月24日確認）
• Radiant Capital: Post-Mortem
• Immunefi: Hack Analysis — Beanstalk Governance Attack, April 2022
• Composable Security: Understanding the Tornado Cash Governance Attack

資料の確認日と注意

公開資料は2026年8月15日に確認しました。OWASP Smart Contract Top 10、L2BEAT Stages、Arbitrum DAOの憲章は、2026年9月24日に確認し直しています。「よくある質問」のスロットの値も、2026年8月15日時点のものです。規格・ライブラリ・L2の基準・各プロジェクトの設定は更新されるので、採用するときに確かめ直してください。法令・会計・税務にかかわる判断は、専門家に確認してください。