---
title: "未初期化のアップグレード可能プロキシ: イニシャライザー乗っ取りのリスク"
description: "アップグレード可能なプロキシは、実装コントラクターではなく初期化呼び出しで自身のストレージを初期化します。この記事では、フロントランニング、実装のロック、デプロイ検証を説明します。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 未初期化のアップグレード可能プロキシ: イニシャライザー乗っ取りのリスク
> 教育目的の参考情報であり、投資助言ではありません。投資により損失が生じる可能性があります。
## 直接の答え
アップグレード可能なプロキシは、実装コントラクトのコンストラクターではなく初期化呼び出しで自身のストレージを初期化します。この記事では、先行呼び出し、実装のロック、デプロイ検証を説明します。
新しいプロキシ アドレスがデプロイされても、最初のトランザクションがまだ確認されていない場合、誰でもパブリック イニシャライザを先制して呼び出して所有者になろうとする可能性があります。
エージェントがデプロイされるとき、コンストラクターはエージェント ストレージ内のコントラクトの初期化ロジックを実行しません。そのため、アップグレード可能なシステムでは、所有者、トークン パラメーター、およびモジュールを設定するために 1 回だけ呼び出すことができるイニシャライザーがよく使用されます。関数が適切に保護されていない場合、または展開と初期化が 2 つのトランザクションに分割されている場合、攻撃者が最初にその関数を呼び出す可能性があります。
## 仕組み
セキュリティ プロセスは、デプロイメントと初期化の呼び出しデータを同じアトミック トランザクションに配置し、コントラクト構築の実装時に初期化を無効にして、実装自体が引き継がれないようにします。再初期化子は、新しいステータスを新しいバージョンに追加するために使用され、バージョンと呼び出し権限も制限する必要があります。実装の初期化ステータスを確認せずにエージェント所有者を確認するだけでも、依然としてリスクが漏洩する可能性があります。
チェーン上の操作は 4 つの層に分かれています。ウォレットは表示と署名を担当し、RPC は読み取りとブロードキャストを担当し、コントラクト コードはステータスの変更を決定し、ブロック コンセンサスはトランザクションが最終的に確認されるかどうかを決定します。どのレベルでも「成功」を表示しても、他のレベルでの検証を置き換えることはできません。
## 例
プロジェクトは最初にエージェントをデプロイし、次に initialize(team) を呼び出すことを計画しています。攻撃者はメモリ プールを監視し、最初により高い料金で initialize(攻撃者) を呼び出し、管理者になり、次に悪意のある実装にアップグレードして資金を送金します。チーム自身の初期化トランザクションはロールバックされますが、この時点で制御が失われます。
ケース内のガス、滑り、ブロック時間を使用して計算方法を示します。実際の操作の前に、現在のチェーンと現在のブロックの価格、流動性、権限、契約ステータスを読み取る必要があります。金額には、トークンの数、ドルの値、およびチェーン上の生の整数が同時に記録されます。
## リスク
戻り値は、実際の終了値に基づいて計算する必要があります。
純売却価値 = 資産市場価値 - 価格ショック - 契約手数料 - 譲渡税 - ガソリン - リスク割引待ち
ネットワークの輻輳、オラクルの異常、管理者のアップグレードという 3 つのストレス シナリオが確立されています。 Gas が 5 倍に拡大し、プールの深さが 50% 減少し、ステーブルコインが 5% 割引され、1 日終了できないと仮定します。 1か月の収入で圧力摩擦をカバーできない場合、高収入では十分な補償ができません。
単一プロトコル、単一チェーン、単一ブリッジ、単一ステーブルコインにはそれぞれ上限が設定されます。管理者、オラクル、ブリッジ、フロントエンド、および単一の RPC が正常であると同時に終了する必要があるポジションはさらに絞り込む必要があり、複数の関連する依存関係が分散していると誤解してはなりません。
## よくある誤解
- 誤解 1: フロントエンドのバランスはチェーン上の事実です。フロントエンドはキャッシュされているか、インデックス付けが遅れているか、間違ったネットワークに接続されている可能性があるため、コントラクトの読み取りと相互検証する必要があります。
- 誤解 2: ガスや滑りを増やすと、どんな故障も解決できる。ガスは仕分けにのみ影響し、スリッページは価格を緩和するだけです。許可、Nonce、および契約条件のエラーは自動的に修復されません。
- 誤解 3: 少量のテストが成功すれば、永続的なセキュリティが得られることを意味します。管理者のアップグレード、動的なパラメータ、流動性の変更により結果が変化するため、ポジションを拡大する前に確認する必要があります。
## 関連トピック
- [ERC-4626 初回預金インフレ攻撃: Vault 株が四捨五入される理由](/ja/crypto/erc4626-inflation-attack/)
- [代理店契約](/ja/crypto/proxy-contract/)
- [スマートコントラクト](/ja/crypto/smart-contract/)
- [アップグレード可能な契約](/ja/crypto/upgradeable-contract/)
- [有効性証明](/ja/crypto/validity-proof/)
## 出典
- [Proxy と Initializable API](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (参照日: 2026-08-20)
- [アップグレード可能なコントラクトの記述](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (参照日: 2026-08-20)
- [スマートコントラクトのアップグレード](https://ethereum.org/developers/docs/smart-contracts/upgrading/) - Ethereum.org (参照日: 2026-08-20)
Source: https://wiki.fcontext.com/ja/crypto/initializer-takeover/index.mdx