🎨 주요 Proxy 패턴 종류

Proxy 패턴에도 여러 가지 변형이 있어요. 각각의 특징과 장단점을 알아보면서, 어떤 상황에 어떤 패턴을 사용해야 하는지 살펴볼게요! 🎯

1️⃣ Transparent Proxy Pattern (투명 프록시 패턴)

OpenZeppelin에서 제안한 가장 널리 사용되는 패턴이에요. "투명하다"는 의미는 사용자 입장에서 프록시의 존재를 의식하지 않아도 된다는 뜻이죠.

핵심 특징:
• Admin(관리자)과 일반 사용자를 명확히 구분해요.
• Admin이 호출하면 프록시 자체의 관리 함수가 실행되고, 일반 사용자가 호출하면 구현 컨트랙트로 delegatecall 됩니다.
• 함수 선택자 충돌(Function Selector Collision) 문제를 해결했어요.

// Transparent Proxy 예시 (단순화된 버전)
contract TransparentProxy {
    address private _admin;
    address private _implementation;
    
    modifier ifAdmin() {
        if (msg.sender == _admin) {
            _;
        } else {
            _fallback();
        }
    }
    
    function upgradeTo(address newImplementation) external ifAdmin {
        _implementation = newImplementation;
    }
    
    function _fallback() internal {
        address impl = _implementation;
        assembly {
            calldatacopy(0, 0, calldatasize())
            let result := delegatecall(gas(), impl, 0, calldatasize(), 0, 0)
            returndatacopy(0, 0, returndatasize())
            switch result
            case 0 { revert(0, returndatasize()) }
            default { return(0, returndatasize()) }
        }
    }
    
    fallback() external payable {
        _fallback();
    }
}

2️⃣ UUPS (Universal Upgradeable Proxy Standard)

UUPS는 비교적 최근에 등장한 패턴으로, EIP-1822에서 제안되었어요. Transparent Proxy의 가스 비효율성을 개선한 버전이라고 볼 수 있죠.

핵심 특징:
• 업그레이드 로직이 구현 컨트랙트에 포함되어 있어요.
• 프록시 컨트랙트는 매우 간단하고 가벼워요.
• 일반 사용자의 함수 호출 시 가스 비용이 더 저렴해요.
• 하지만 구현 컨트랙트에 업그레이드 로직을 반드시 포함해야 해요.

// UUPS 구현 컨트랙트 예시
contract MyContractV1 is UUPSUpgradeable {
    uint256 public value;
    
    function initialize(uint256 _value) public initializer {
        value = _value;
    }
    
    function setValue(uint256 _value) public {
        value = _value;
    }
    
    // UUPS에서는 구현 컨트랙트에 업그레이드 로직이 있어요
    function _authorizeUpgrade(address newImplementation) internal override {
        require(msg.sender == owner(), "Only owner can upgrade");
    }
}

3️⃣ Beacon Proxy Pattern (비콘 프록시 패턴)

여러 개의 프록시 컨트랙트를 동시에 관리해야 할 때 유용한 패턴이에요. 예를 들어, 사용자마다 개별 프록시 컨트랙트를 배포하는 경우를 생각해보세요.

핵심 특징:
• Beacon 컨트랙트가 구현 컨트랙트의 주소를 중앙에서 관리해요.
• 여러 프록시가 하나의 Beacon을 참조해요.
• Beacon의 구현 주소만 변경하면 모든 프록시가 동시에 업그레이드돼요.
• 대규모 시스템에서 효율적이에요.

🛠️ Proxy 패턴 구현하기: 실전 가이드

이제 실제로 Proxy 패턴을 구현하는 방법을 단계별로 알아볼게요. OpenZeppelin의 라이브러리를 활용하면 훨씬 쉽고 안전하게 구현할 수 있어요! 💪

🔧 Step 1: 환경 설정

먼저 필요한 도구들을 설치해야 해요. Hardhat이나 Truffle 같은 개발 프레임워크와 OpenZeppelin Contracts를 사용할 거예요.

// package.json 설정
npm install --save-dev hardhat
npm install @openzeppelin/contracts
npm install @openzeppelin/contracts-upgradeable
npm install @openzeppelin/hardhat-upgrades

📝 Step 2: 구현 컨트랙트 작성

업그레이드 가능한 컨트랙트를 작성할 때는 몇 가지 중요한 규칙을 따라야 해요. 일반적인 컨트랙트와는 조금 다른 점들이 있거든요! 🎓

// MyContractV1.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";

contract MyContractV1 is Initializable, OwnableUpgradeable {
    uint256 public value;
    string public name;
    
    // constructor 대신 initialize 사용
    function initialize(string memory _name) public initializer {
        __Ownable_init();
        name = _name;
        value = 0;
    }
    
    function setValue(uint256 _value) public {
        value = _value;
    }
    
    function getValue() public view returns (uint256) {
        return value;
    }
}

🚀 Step 3: 프록시 배포하기

OpenZeppelin의 Hardhat Upgrades 플러그인을 사용하면 프록시 배포가 정말 간단해져요. 복잡한 프록시 로직을 직접 작성할 필요 없이 몇 줄의 코드만으로 가능하답니다! 😊

// scripts/deploy.js
const { ethers, upgrades } = require("hardhat");

async function main() {
    // 구현 컨트랙트 가져오기
    const MyContract = await ethers.getContractFactory("MyContractV1");
    
    // 프록시와 함께 배포 (Transparent Proxy 사용)
    const proxy = await upgrades.deployProxy(
        MyContract,
        ["My First Contract"], // initialize 함수의 파라미터
        { initializer: 'initialize' }
    );
    
    await proxy.deployed();
    
    console.log("Proxy deployed to:", proxy.address);
    console.log("Implementation deployed to:", await upgrades.erc1967.getImplementationAddress(proxy.address));
}

main();

🔄 Step 4: 컨트랙트 업그레이드하기

이제 가장 중요한 부분이에요! 새로운 기능을 추가한 V2 컨트랙트를 만들고 업그레이드하는 과정을 살펴볼게요. 🎯

// MyContractV2.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "./MyContractV1.sol";

contract MyContractV2 is MyContractV1 {
    // 새로운 상태 변수는 맨 뒤에 추가!
    uint256 public multiplier;
    
    // 새로운 함수 추가
    function setMultiplier(uint256 _multiplier) public {
        multiplier = _multiplier;
    }
    
    // 기존 함수 오버라이드
    function getValue() public view override returns (uint256) {
        return value * multiplier;
    }
    
    // V2에서 추가된 초기화 함수
    function initializeV2(uint256 _multiplier) public reinitializer(2) {
        multiplier = _multiplier;
    }
}

// scripts/upgrade.js
const { ethers, upgrades } = require("hardhat");

async function main() {
    const PROXY_ADDRESS = "0x..."; // 기존 프록시 주소
    
    // 새로운 구현 컨트랙트 가져오기
    const MyContractV2 = await ethers.getContractFactory("MyContractV2");
    
    // 업그레이드 실행
    const upgraded = await upgrades.upgradeProxy(PROXY_ADDRESS, MyContractV2);
    
    console.log("Contract upgraded successfully!");
    console.log("Proxy address:", upgraded.address);
    console.log("New implementation:", await upgrades.erc1967.getImplementationAddress(upgraded.address));
    
    // V2 초기화 함수 호출
    await upgraded.initializeV2(10);
}

main();

⚠️ Storage Layout: 가장 조심해야 할 부분

Proxy 패턴에서 가장 많이 실수하고, 가장 치명적인 결과를 초래할 수 있는 부분이 바로 Storage Layout이에요. 이 부분을 제대로 이해하지 못하면 업그레이드 후 데이터가 꼬이거나 완전히 망가질 수 있어요! 😱

🧩 Storage Slot의 이해

EVM(Ethereum Virtual Machine)에서 컨트랙트의 상태 변수는 storage slot이라는 32바이트 공간에 순차적으로 저장돼요. 첫 번째 변수는 slot 0, 두 번째는 slot 1, 이런 식으로요.

Proxy 패턴에서는 프록시 컨트랙트의 storage를 사용하기 때문에, 구현 컨트랙트를 업그레이드할 때 storage slot의 순서와 타입이 일치해야 해요!

// V1
contract V1 {
    uint256 public a;
    uint256 public b;
}

// V2 - 잘못됨!
contract V2 {
    uint256 public b;  // 순서 바뀜
    uint256 public a;  // 순서 바뀜
}

// V1
contract V1 {
    uint256 public value;
}

// V2 - 잘못됨!
contract V2 {
    address public value;  // 타입 변경
}

// V1
contract V1 {
    uint256 public a;
    uint256 public c;
}

// V2 - 잘못됨!
contract V2 {
    uint256 public a;
    uint256 public b;  // 중간에 삽입
    uint256 public c;
}

// V1
contract V1 {
    uint256 public a;
    uint256 public b;
}

// V2 - 올바름!
contract V2 {
    uint256 public a;
    uint256 public b;
    uint256 public c;  // 끝에 추가
    address public newAddress;  // 끝에 추가
}

🔍 Storage Gap 패턴

미래의 업그레이드를 대비해서 storage gap을 미리 확보해두는 것이 좋은 관행이에요. OpenZeppelin에서도 권장하는 방법이죠! 🎯

contract MyContractV1 {
    uint256 public value;
    string public name;
    
    // 미래의 업그레이드를 위한 예약 공간
    // 50개의 slot을 예약 (50 * 32 bytes = 1600 bytes)
    uint256[48] private __gap;
}

contract MyContractV2 {
    uint256 public value;
    string public name;
    
    // 새로운 변수 2개 추가
    uint256 public multiplier;
    address public admin;
    
    // gap을 48개로 줄임 (50 - 2 = 48)
    uint256[46] private __gap;
}

이렇게 하면 나중에 변수를 추가할 때 gap에서 빼서 사용하면 되니까, storage layout이 안전하게 유지돼요! 😊

🔐 보안 고려사항

Proxy 패턴은 강력한 기능이지만, 그만큼 보안에 신경 써야 할 부분도 많아요. 업그레이드 권한을 가진 사람이 악의적으로 행동하면 큰 문제가 발생할 수 있거든요. 🛡️

🎯 1. 업그레이드 권한 관리

// Timelock을 사용한 업그레이드 예시
import "@openzeppelin/contracts/governance/TimelockController.sol";

contract UpgradeableWithTimelock {
    TimelockController public timelock;
    
    constructor(address[] memory proposers, address[] memory executors) {
        // 48시간 지연
        timelock = new TimelockController(
            2 days,
            proposers,
            executors,
            address(0)
        );
    }
    
    function scheduleUpgrade(address newImplementation) public {
        // 업그레이드 예약
        bytes memory data = abi.encodeWithSignature(
            "upgradeTo(address)",
            newImplementation
        );
        
        timelock.schedule(
            address(this),
            0,
            data,
            bytes32(0),
            bytes32(0),
            2 days
        );
    }
}

🔒 2. 초기화 함수 보호

initialize 함수는 한 번만 호출되어야 해요. 만약 여러 번 호출될 수 있다면 공격자가 컨트랙트를 재초기화해서 소유권을 탈취할 수 있어요! 😨

🎭 3. Delegatecall의 위험성

delegatecall은 강력하지만 위험한 기능이에요. 잘못 사용하면 예상치 못한 결과가 발생할 수 있어요.

특히 selfdestruct를 포함한 컨트랙트로 delegatecall하면 프록시 자체가 파괴될 수 있어요! 😱

🌟 실전 활용 사례

이론만 알아서는 부족하죠! 실제로 Proxy 패턴이 어떻게 활용되는지 몇 가지 사례를 살펴볼게요. 🎪

💰 1. DeFi 프로토콜

Aave, Compound, Uniswap 같은 대형 DeFi 프로토콜들은 모두 업그레이드 가능한 컨트랙트를 사용해요.

예를 들어 Aave V2에서 V3로 업그레이드할 때, 사용자들은 아무것도 할 필요 없이 자동으로 새로운 기능을 사용할 수 있었어요. 만약 Proxy 패턴을 사용하지 않았다면 모든 사용자가 자금을 이동해야 했을 거예요! 😅

🎮 2. NFT 마켓플레이스

NFT 마켓플레이스는 빠르게 변화하는 시장 요구사항에 대응해야 해요. 새로운 로열티 시스템, 경매 방식, 결제 옵션 등을 계속 추가해야 하죠.

OpenSea의 Seaport 프로토콜도 업그레이드 가능한 구조로 설계되어 있어요. 이를 통해 새로운 NFT 표준이나 기능을 빠르게 지원할 수 있답니다! 🖼️

🏦 3. 토큰 컨트랙트

일부 토큰 프로젝트는 업그레이드 가능한 토큰 컨트랙트를 사용해요. 하지만 이건 논란의 여지가 있어요.

장점: 버그 수정, 기능 추가, 규제 대응이 가능해요.
단점: 중앙화 우려, 신뢰 문제가 발생할 수 있어요.

그래서 많은 프로젝트들이 초기에는 업그레이드 가능하게 만들고, 충분히 안정화되면 업그레이드 권한을 포기(renounce)하는 전략을 사용해요. 🎯

🌐 4. 재능넷 같은 플랫폼

재능넷과 같은 재능 공유 플랫폼에서 블록체인을 활용한다면, Proxy 패턴은 필수적이에요!

예를 들어:
• 사용자 평판 시스템 개선
• 새로운 결제 방식 추가
• 수수료 구조 변경
• 분쟁 해결 메커니즘 업데이트

이런 변경사항들을 Proxy 패턴을 통해 원활하게 적용할 수 있어요. 사용자들은 기존 계정과 데이터를 그대로 유지하면서 새로운 기능을 바로 사용할 수 있죠! 🚀