Blockchain Smart Contracts with Solidity · レッスン

Transparent Proxyパターンとストレージレイアウト

Transparent Proxyパターン、delegatecallによってロジックとストレージを分離する方法、安全にコントラクトをアップグレードするために従うべきストレージレイアウト規則を学びます。

「Transparent Proxyパターンとストレージレイアウト」はCoddyKit上の無料Blockchain Smart Contracts with Solidityレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはBlockchain Smart Contracts with Solidity学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Blockchain Smart Contracts with Solidityコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Recap: Why Proxies

You have seen UUPS and the Diamond standard. Both rely on a foundational idea: a proxy holds the storage and forwards calls to a separate logic (implementation) contract. Upgrading means pointing the proxy at new logic.

How delegatecall Works

The magic behind proxies is delegatecall. It runs the logic contract's code but in the proxy's storage context, using the proxy's msg.sender and balance.

So storage lives in the proxy; behavior lives in the implementation.

A Minimal Proxy Fallback

A proxy forwards every unknown call to the implementation using assembly delegatecall in its fallback.

fallback() external payable {
    address impl = _implementation();
    assembly {
        calldatacopy(0, 0, calldatasize())
        let ok := delegatecall(gas(), impl, 0, calldatasize(), 0, 0)
        returndatacopy(0, 0, returndatasize())
        switch ok
        case 0 { revert(0, returndatasize()) }
        default { return(0, returndatasize()) }
    }
}

The Function Clash Problem

If the proxy itself has an upgradeTo function and the logic also has a function with the same selector, calls become ambiguous. The Transparent Proxy pattern solves this by routing based on the caller.

Admin vs User Routing

In a Transparent Proxy, the admin address can call admin functions (like upgrade) but cannot reach the implementation. Everyone else is always forwarded to the implementation. This removes clashes.

modifier ifAdmin() {
    if (msg.sender == _admin()) {
        _;
    } else {
        _fallback();
    }
}

Storage Slot Collisions

Both proxy and logic write to the same storage. If they used slot 0 for different variables, they would corrupt each other. Proxies store admin and implementation at fixed pseudo-random slots (EIP-1967) to avoid collisions.

// EIP-1967 implementation slot
bytes32 internal constant _IMPL_SLOT =
    0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

Reading the Implementation Slot

The proxy reads and writes that fixed slot directly with assembly so it never collides with logic variables.

function _implementation() internal view returns (address impl) {
    bytes32 slot = _IMPL_SLOT;
    assembly { impl := sload(slot) }
}

Storage Layout Rules

When upgrading the logic you must preserve the order and types of existing storage variables. New variables go at the end.

Never reorder existing variables
Never change a variable's type
Never insert a new variable before old ones

Storage Gaps

Inheritable base contracts reserve space for future variables with a __gap array so child contracts do not collide after an upgrade adds fields to the base.

contract Base {
    uint256 public value;
    // reserve 50 slots for future use
    uint256[50] private __gap;
}

Initializers Not Constructors

Constructors run only on the logic contract's own deployment, not through the proxy. Upgradeable contracts use an initialize function guarded so it runs exactly once.

bool private _initialized;

function initialize(uint256 v) external {
    require(!_initialized, 'already init');
    _initialized = true;
    value = v;
}

Transparent vs UUPS

Transparent proxies put the upgrade logic in the proxy (more deployment gas, simpler logic). UUPS puts it in the implementation (cheaper proxy, but you must include upgrade code in every version). Choose based on cost and team discipline.

Quick Check

Test your understanding of proxy storage.

Recap

You learned the Transparent Proxy pattern:

delegatecall runs logic in the proxy's storage
Admin-vs-user routing avoids function clashes
EIP-1967 fixed slots and __gap arrays prevent collisions
Use initialize, preserve storage layout, append new variables

Follow these rules and upgrades stay safe.

よくある質問

「Transparent Proxyパターンとストレージレイアウト」レッスンは無料ですか？

はい。「Transparent Proxyパターンとストレージレイアウト」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Blockchain Smart Contracts with Solidityコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Blockchain Smart Contracts with Solidityコースには全4レッスンが含まれています。

「Transparent Proxyパターンとストレージレイアウト」で何を学びますか？

Transparent Proxyパターン、delegatecallによってロジックとストレージを分離する方法、安全にコントラクトをアップグレードするために従うべきストレージレイアウト規則を学びます。ブラウザで直接実行するハンズオンコードでBlockchain Smart Contracts with Solidityを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Blockchain Smart Contracts with Solidityを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのBlockchain Smart Contracts with Solidityは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン4/4です。

「Transparent Proxyパターンとストレージレイアウト」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このBlockchain Smart Contracts with Solidityレッスンでコードを書いて実行できますか？

はい。すべてのBlockchain Smart Contracts with Solidityレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Blockchain Smart Contracts with Solidityに戻る