﻿---
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.

# 초기화되지 않은 업그레이드 가능 프록시: 초기화 프로그램 탈취 위험

> 교육 참고용이며 투자 조언이 아닙니다. 투자로 인해 손실이 발생할 수 있습니다.

<a id="answer"></a>

## 직접 답변

업그레이드 가능 프록시는 구현 계약의 생성자가 아니라 초기화 호출로 자체 저장소를 초기화합니다. 이 문서는 선제 호출, 구현 잠금 및 배포 검사를 설명합니다.

새 프록시 주소가 배포되었지만 초기 트랜잭션이 아직 확인되지 않은 경우 누구나 선제적으로 공개 초기화를 호출하여 소유자가 되려고 시도할 수 있습니다.

에이전트가 배포되면 생성자는 에이전트 저장소에서 계약의 초기화 논리를 실행하지 않으므로 업그레이드 가능한 시스템은 종종 소유자, 토큰 매개변수 및 모듈을 설정하기 위해 한 번만 호출할 수 있는 초기화 프로그램을 사용합니다. 함수가 제대로 보호되지 않거나 배포와 초기화가 두 개의 트랜잭션으로 분할되는 경우 공격자가 먼저 호출할 수 있습니다.

<a id="mechanism"></a>

## 작동 방식

보안 프로세스는 배포 및 초기화 호출 데이터를 동일한 원자 트랜잭션에 배치하고 계약 생성을 구현할 때 초기화를 비활성화하여 구현 자체가 인계되는 것을 방지합니다. 재초기화 프로그램은 새 버전에 새 상태를 추가하는 데 사용되며 버전 및 호출 권한도 제한해야 합니다. 구현 초기화 상태를 확인하지 않고 에이전트 소유자만 확인하는 것만으로는 여전히 위험이 유출될 수 있습니다.

체인의 작업은 4개 계층으로 나뉩니다. 지갑은 표시 및 서명을 담당하고, RPC는 읽기 및 브로드캐스팅을 담당하며, 계약 코드는 상태 변경을 결정하고, 블록 합의는 거래가 최종 확인되는지 여부를 결정합니다. 어떤 수준에서든 "성공"을 표시하는 것은 다른 수준의 확인을 대체할 수 없습니다.

<a id="example"></a>

## 예시

프로젝트는 먼저 에이전트를 배포하고 다음에 초기화(팀)를 호출할 계획입니다. 공격자는 메모리 풀을 모니터링하고 높은 수수료를 받고 먼저 초기화(공격자)를 호출한 후 관리자가 된 후 악의적인 구현으로 업그레이드하여 자금을 이체합니다. 팀 자체의 초기화 트랜잭션이 롤백되지만 이 시점에서는 제어가 손실됩니다.

계산 방법을 설명하기 위해 케이스의 가스, 미끄러짐 및 차단 시간이 사용됩니다. 실제 작동 전에 현재 체인과 현재 블록의 가격, 유동성, 권한, 계약 상태를 읽어야 합니다. 금액은 토큰 수, 달러 가치 및 체인의 원시 정수를 동시에 기록합니다.

<a id="risks"></a>

## 위험

반품은 실제 종료 가치를 기준으로 계산되어야 합니다.

순 출구 가치 = 자산 시장 가치 - 가격 충격 - 계약 수수료 - 양도세 - 가스 - 위험 할인 대기

네트워크 정체, 오라클 이상, 관리자 업그레이드 등 세 가지 스트레스 시나리오가 설정되었습니다. 가스가 5배 확장되고, 풀 깊이가 50% 감소하고, 스테이블 코인이 5% 할인되고, 하루 동안 나갈 수 없다고 가정합니다. 한 달 수입으로 압박 마찰을 감당할 수 없다면 높은 수입으로도 충분한 보상을 받을 수 없습니다.

단일 프로토콜, 단일 체인, 단일 브리지 및 단일 스테이블코인은 각각 상한을 설정합니다. 관리자, 오라클, 브리지, 프런트엔드 및 단일 RPC가 동시에 정상이어야 하는 위치는 더욱 좁혀야 하며 여러 관련 종속성을 분산으로 착각해서는 안 됩니다.

<a id="misconceptions"></a>

## 흔한 오해

- 오해 1: 프런트 엔드 잔액은 체인의 사실입니다. 프런트 엔드는 캐시되거나 늦게 인덱싱되거나 잘못된 네트워크에 연결될 수 있으며 계약 읽기를 통해 교차 검증되어야 합니다.

- 오해 2: 가스나 미끄러짐이 증가하면 모든 고장이 해결될 수 있습니다. 가스는 분류에만 영향을 미치며 하락은 가격을 완화할 뿐입니다. 허가, Nonce, 계약 조건 오류는 자동으로 복구되지 않습니다.

- 오해 3: 성공적인 소량 테스트는 영구적인 보안을 의미합니다. 관리자 업그레이드, 동적 매개변수 및 유동성 변경으로 인해 결과가 변경되므로 각 포지션 확장 전에 검토해야 합니다.

<a id="related"></a>

## 관련 주제

- [ERC-4626 첫 입금 인플레이션 공격: 금고 지분이 반올림될 수 있는 이유](/ko/crypto/erc4626-inflation-attack/)
- [대리점 계약](/ko/crypto/proxy-contract/)
- [스마트 계약](/ko/crypto/smart-contract/)
- [업그레이드 가능한 계약](/ko/crypto/upgradeable-contract/)
- [유효성 증명](/ko/crypto/validity-proof/)

<a id="sources"></a>

## 출처

- [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/ko/crypto/initializer-takeover/index.mdx
