Blockchain Smart Contracts with Solidity · 강의

투명 프록시 패턴과 스토리지 레이아웃

투명 프록시 패턴과 delegatecall이 로직을 스토리지와 분리하는 방식, 컨트랙트를 안전하게 업그레이드하기 위해 따라야 할 스토리지 레이아웃 규칙을 배웁니다.

투명 프록시 패턴과 스토리지 레이아웃은(는) CoddyKit의 무료 Blockchain Smart Contracts with Solidity 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 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.

자주 묻는 질문

“투명 프록시 패턴과 스토리지 레이아웃” 강의는 무료인가요?

네 — “투명 프록시 패턴과 스토리지 레이아웃” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Blockchain Smart Contracts with Solidity 강의 전체를 잠금 해제할 수 있습니다. Blockchain Smart Contracts with Solidity 강의에는 총 4개의 강의가 포함되어 있습니다.

“투명 프록시 패턴과 스토리지 레이아웃”에서 뭘 배우나요?

투명 프록시 패턴과 delegatecall이 로직을 스토리지와 분리하는 방식, 컨트랙트를 안전하게 업그레이드하기 위해 따라야 할 스토리지 레이아웃 규칙을 배웁니다. 브라우저에서 직접 실행하는 실습 코드로 Blockchain Smart Contracts with Solidity을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Blockchain Smart Contracts with Solidity을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Blockchain Smart Contracts with Solidity은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“투명 프록시 패턴과 스토리지 레이아웃” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Blockchain Smart Contracts with Solidity 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Blockchain Smart Contracts with Solidity 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Blockchain Smart Contracts with Solidity(으)로 돌아가기