탈중앙화 금융(DeFi)과 대체 불가능한 토큰(NFT)의 등장으로 디지털 자산 주권의 새로운 시대가 열렸습니다. 그러나 블록체인 기술의 투명한 겉치레 뒤에는 이상적인 분산화와 중앙 집중화된 개발자 제어 사이의 조용한 싸움이 치열하게 벌어지고 있습니다. "숨겨진 소유자" 개념은 오늘날 가장 큰 보안 과제 중 하나를 나타냅니다. 여기서는 프로젝트가 소유권을 포기했다고 주장하는 경우에도 궁극적인 통제권을 유지하기 위해 특권적인 거버넌스 메커니즘이 교묘하게 설치됩니다. 현대 스마트 계약 아키텍처에 대한 심층 분석에 따르면 소유권은 더 이상 단순한 이진 상태가 아니라 관리 역할, 업그레이드 권한 및 미묘하게 위장된 논리적 백도어의 복잡한 스펙트럼입니다.
불변성과 거버넌스 제어 필요성 사이의 모순
이더리움 생태계와 이더리움 가상 머신(EVM) 호환 체인에서 소스 코드의 불변성은 종종 인간 개입에 대한 장벽으로 간주됩니다. 계약이 배포되면 해당 논리 코드가 블록체인 원장에 영구적으로 새겨집니다. 그러나 운영 현실에서는 개발자가 오류를 수정하고, 기능을 업데이트하거나, 공격과 같은 긴급 상황에 개입할 수 있어야 합니다. 이러한 정당한 필요에 따라 통제력을 유지할 수 있는 디자인 모델이 탄생했지만 면밀히 모니터링되지 않으면 자산을 조작하고 전유할 수 있는 공간도 만들어집니다.
Tan Phat Digital의 전문가에 따르면 '숨겨진 소유자'라는 개념은 특정 개인뿐만 아니라 시스템에서 '보편 키'를 보유하고 있는 모든 개체를 의미합니다. 이는 단일 외부 엔터티 계정(EOA)부터 다중 서명 거버넌스 메커니즘(Multisig) 또는 계약의 핵심 논리를 방해할 수 있는 권한을 가진 DAO에 이르기까지 다양합니다.
액세스 제어 시스템 성숙도 수준 분류
'숨겨진 소유자'의 위험을 평가하기 위해 Tan Phat Digital은 공통 블록체인 보안 표준 변수를 기반으로 액세스 제어 성숙도 평가 프레임워크를 컴파일합니다.
레벨 1: 단일 EOA (높은 노출)
디자인 특징: 단일 개인 지갑이 모든
onlyOwner권한을 보유합니다.숨겨진 소유자 위험: 매우 높습니다. 이는 개인 키가 노출되거나 개발자가 사기를 저지르려는 의도가 있는 경우 치명적인 약점입니다.
레벨 2: 중앙 집중식 다중 서명(기본 완화)
설계 특징: 지갑 그룹 간에 전력이 공유됩니다(예: 3/5 서명 모델).
숨겨진 소유자 위험: 중간 하이에. 회원 지갑이 동일한 관심 그룹에 속하는 경우 시스템은 여전히 조작에 취약합니다.
레벨 3: 시간 잠금 및 역할 분리(강화된 제어)
설계 기능: 모든 변경 사항에 시간 지연을 적용하고(Timelock) Minter, Admin, Pauser와 같은 역할을 명확하게 구분합니다.
위험 숨겨진 소유자: 낮음에서 중간까지. 커뮤니티는 변경 사항이 적용되기 전에 반응하고 테스트할 시간을 갖습니다.
레벨 4: 근본적인 불변성(최종 게임)
디자인 기능: 배포 후 모든 관리 권한을 완전히 제거합니다. 소스 코드는 어떤 식으로든 변경할 수 없습니다.
숨겨진 소유자 위험: 없음. 하지만 이 레벨은 나중에 오류를 수정할 수 없기 때문에 출시 전에 소스 코드를 완전히 완료해야 합니다.
레벨 1에서 레벨 4로의 전환은 "숨겨진 소유자"의 위험을 완전히 제거할 수 있는 유일한 방법이지만 배포 후 발생하는 기술적 오류에 대한 유연성과 대응 측면에서도 절충이 필요합니다.
프록시 아키텍처와 소스 코드 불변성의 환상
제어를 유지하는 기술에서 프록시 패턴은 가장 강력하고 널리 사용되는 도구입니다. 이를 통해 개발자는 고정 주소에서 계약의 동작을 완전히 변경할 수 있으며 상태와 처리 논리의 분리를 통해 "가변 가능성의 환상"을 만들 수 있습니다. 프록시 계약은 사용자를 위한 단일 통신 게이트웨이 역할을 하지만 DELEGATECALL 코드를 통해 실행을 논리적 계약(구현)에 위임합니다.
DELEGATECALL 메커니즘 및 컨텍스트 위험
DELEGATECALL 코드를 사용하면 프록시가 구현 코드를 실행할 수 있지만 프록시의 메모리 컨텍스트(저장소)에서 실행됩니다. 이는 상태 변수, Ether 잔액 및 소유권이 모두 프록시에 있고 계산 규칙은 구현에 있음을 의미합니다.
데이터 충돌을 피하기 위한 EIP-1967 스토리지 슬롯 계산 공식은 일반적으로 다음과 같이 정의됩니다.
이러한 무작위 해시 슬롯을 사용하면 프록시의 구현 변수가 구현의 비즈니스 변수를 덮어쓰는 것을 방지할 수 있습니다. 그러나 Tan Phat Digital은 개발자가 의도적으로 "스토리지 충돌"을 생성하는 경우 사용자 자금을 인출하기 위해 악성 코드가 포함된 계약을 가리키도록 논리적 주소를 조작할 수 있다고 지적합니다.
인기 있는 프록시 모델 및 관리 권한에 대한 세부정보
투명 프록시 모델
기능 위치 업그레이드: 프록시에 위치 계약.
제어 메커니즘: 관리자 주소만이 업그레이드 기능을 실행할 수 있는 권한을 갖습니다. 일반 사용자의 호출은 항상 논리적 계약으로 리디렉션됩니다.
보안 평가: 기능 선택기 충돌은 방지되지만 시스템이
msg.sender를 지속적으로 확인해야 하기 때문에 가스 비용이 더 높습니다.
UUPS 모델(EIP-1822)
업그레이드 기능 위치: 구현 계약에 직접 위치합니다.
제어 메커니즘: 업그레이드 논리는 최적화를 위해 구현에 상속됩니다.
보안 평가: 가스 효율적이지만 새 업그레이드에 후속 업그레이드를 수행하는 논리가 부족할 경우 시스템이 영구적으로 "벽돌화"될 위험이 있습니다.
비콘 모델 프록시
- 다이아몬드 모델(EIP-2535)
업그레이드 기능 위치: 조각 구조(Facets).
제어 메커니즘: 각 기능(함수 선택기)에 대한 자세한 업그레이드 관리.
보안 평가: 최대한의 유연성을 제공하지만 이 아키텍처는 매우 복잡하여 역할을 감사하고 관리하기가 어렵습니다. 게임.
자세히 보기: 개인 키를 공개하지 않았는데도 지갑이 여전히 돈을 잃는 이유는 무엇입니까?
권위 매트릭스: AccessControl 및 DEFAULT_ADMIN_ROLE
프록시 메커니즘 외에도 Ownable 또는 AccessControl과 같은 액세스 관리 라이브러리를 남용하는 것은 "숨겨진 소유자"를 설치하는 일반적인 방법입니다. 대부분의 투자자는 단순한 owner 변수만 확인하지만, 숙련된 개발자는 다단계 인증 시스템(RBAC)을 사용합니다.
DEFAULT_ADMIN_ROLE 우위
AccessControl 라이브러리에서 DEFAULT_ADMIN_ROLE 역할(일반적으로 해시 코드 0x00)이 권한을 부여합니다. 절대:
mint(Minter) 또는 일시 중지(Pauser) 권한을 포함하여 시스템의 다른 모든 역할을 부여(부여) 또는 취소(취소)합니다.
유료 주소, Oracle 데이터 소스 또는 위험 매개변수와 같은 민감한 매개변수를 변경합니다.
_setRoleAdmin을 통해 다른 역할의 "관리자 역할"을 변경하는 기능 함수입니다.
Tan Phat Digital은 경고합니다. 개발자가 계약에서 '소유권 포기'를 행사하더라도 해당 계약의 논리에 숨겨진 관리자 역할이 여전히 존재하는 경우 여전히 제어권을 유지할 수 있습니다.
위장된 수정자를 통해 숨겨진 "소유자" 로직을 분석합니다.
제어 의도를 숨기기 위해 개발자는 종종 중립적인 수정자를 사용합니다. names:
onlyManager: 종종 기술적인 작업을 수행하는 것으로 설명되지만 실제로는 철회 권한을 부여받을 수 있습니다.onlyCFO또는onlyVaultAdmin: 재무 관리라는 이름으로 유동성에 개입할 권리를 위장합니다.authorized: 모든 주소를 허용하는 수정자 개발자의 화이트리스트에 등록되어 권한 있는 명령을 실행할 수 있습니다.
논리를 숨기는 백도어 기술 및 프로그래밍 트릭
진정한 "숨겨진 소유자"는 종종 모호한 소스 코드 깊은 곳에 숨겨진 트리거 조건을 설치하거나 오해의 소지가 있는 함수 이름 혼동을 사용합니다.
이름을 속이는 기술(기만적인 이름 지정)
Tan Phat Digital은 다음과의 계약에서 일반적으로 발견되는 함수 이름 지정 패턴을 컴파일했습니다. 백도어:
safeWithdraw() 함수
실제 논리: 계약의 전체 잔액을 소유자의 지갑으로 이체하라는 명령을 실행합니다.
목적: 안전한 출금을 가장하여 모든 자금을 출금(Rug Pull)합니다. 기능.
UpdateLibrary() 함수
실제 논리:
implementation변수가 새 주소를 가리키도록 변경합니다.목적: 자동으로 계약을 악성으로 업그레이드합니다. version.
syncBalance() 함수
실제 논리:
msg.sender의 잔액을 0으로 설정합니다.목적: 사용자 자산을 동결하거나 초기화합니다. system.
emergencyRefund() 함수
실제 논리:
selfdestruct(owner)명령을 호출합니다. Owner"는 프록시 피싱 공격을 통해 원격으로 계약을 조작합니다. 또한 시간 지연 또는 블록 번호에 따른 활성화 조건은 프로젝트가 안정적으로 운영되고 축적된 후에만 백도어가 "깨어나는" 데 도움이 됩니다. 충분한 유동성.세유 유동성 절도: 개발자는 특권 기능을 사용하여 유동성 풀에서 모든 기본 자산(ETH/USDT)을 인출하여 사용자 토큰이 더 이상 사용되지 않도록 합니다. 교환 가능.
거래 동결(허니팟): 블랙리스트 논리(
isBlacklisted)가 선택적으로 활성화된 소스 코드로 인해 사용자는 구매할 수만 있고 판매할 수는 없습니다.무제한 발행: 숨겨진
MINTER_ROLE권한을 사용하면 판매할 엄청난 양의 토큰을 생성하여 완전히 희석할 수 있습니다. 투자자 자산의 가치.검증 상태 확인: 바이트코드만 표시하는 계약과는 절대 상호 작용하지 않습니다. 확인된 소스 코드 없음(녹색 확인 표시) 프록시를 사용하면 뒤에 있는 구현 계약을 주의 깊게 확인해야 합니다.
권한 있는 역할 추적:
Ctrl + F를 사용하여 검색:owner,admin,DEFAULT_ADMIN_ROLE,minter,onlyOwneronlyAdmin.
사기의 경제학: Rug Pull 및 차용 메커니즘
Tan Phat Digital은 "숨겨진 소유자"의 가장 일반적인 세 가지 형태의 차용을 분석합니다.
포렌식 프로세스: Etherscan에서 "숨겨진 소유자"를 탐지하는 방법
자산을 보호하려면 Tan Phat Digital 다음과 같은 "잎을 확인하고 웜을 찾는" 검사 프로세스를 권장합니다.
위험한 기능 확인:
selfdestruct,delegatecall및upgradeTo에 특히 주의하세요.숨겨진 소유자란 실제로 무엇인가요? 개발자가 완전히 분산된 프로젝트를 광고하더라도 숨겨진 관리자 역할이나 논리적 백도어를 통해 스마트 계약(예: 자금 인출, 거래 중지)에 대한 궁극적인 제어를 유지할 수 있는 프로그래밍 기술입니다.
개발자에게 숨겨진 소유자가 필요한 이유는 무엇입니까? 사기 목적(러그 풀) 외에도 때로는 개발자가 긴급 버그 수정이나 기능 업데이트를 위해 설치하지만 Timelock 또는 Multisig가 없으면 이는 엄청난 집중입니다. 위험합니다.
소유권 포기가 정말 안전한가요? 전혀 그렇지 않습니다. 개발자는
소유자지갑 포기 기능을 호출할 수 있지만AccessControl라이브러리의 숨겨진 관리자 역할 또는 프록시 업그레이드 권한을 통해 여전히 권한을 유지합니다.계약이 악성 프록시인지 어떻게 알 수 있습니까? Etherscan을 확인하여 단일 EOA 지갑으로 "구현" 주소를 변경할 수 있는지 확인하세요. 개발자가 예고 없이 어떤 로직으로든 업그레이드할 수 있다면 그것은 위험합니다.
DEFAULT_ADMIN_ROLE은 얼마나 위험한가요? 이것이 AccessControl 표준의 "궁극적인 힘"입니다. 이 역할을 맡은 사람은 다른 권한이 잠겨 있어도 새 지갑에 모든 권한(예: 발행 권한)을 부여할 수 있습니다.
"Ghost State" 오류가 무엇인가요? 이는 계약이 정리된 후에도 저장소에 오래된 데이터가 여전히 남아 있는 현상입니다(예: 2025년 Yearn yETH 사건). 공격자는 이 "유령" 데이터를 활용하여 매우 저렴한 비용으로 막대한 양의 토큰을 만들 수 있습니다.
tx.origin이 백도어의 징후로 간주되는 이유는 무엇입니까? 관리자 권한을 인증하기 위해msg.sender대신tx.origin을 사용하면 개발자가 사용자(또는 관리자)를 속일 수 있습니다.Rug Pull에서 "기만적인 이름 지정"은 어떻게 작동하나요? 개발자는 안전해 보이도록 함수 이름을
safeWithdraw()또는emergencyRefund()와 같이 지정하지만 그 내부에는 모든 자금을 개인 지갑으로 이체하거나 자체 취소하는 코드가 포함되어 있습니다. 계약.초기화되지 않은 프록시를 식별하는 방법은 무엇입니까? Etherscan에서 "계약 읽기" 탭을 확인하세요.
owner또는admin과 같은 변수가0x00...주소에 있는 경우 공격자(또는 개발자 자신)는 언제든지 생성자 함수를 호출하여 장악할 수 있습니다.자기 파괴를 백도어로 사용할 수 있습니까? 예.
selfdestruct가 포함된 기능을 사용하면 개발자는 전체 계약 논리를 파괴하고 내부의 Ether를 미리 결정된 주소로 배출하여 사용자의 자산을 영원히 동결시킬 수 있습니다.Timelock은 투자자를 어떻게 보호합니까? Timelock은 모든 관리 명령에 대해 지연(예: 48시간)을 생성합니다. 이를 통해 커뮤니티는 업그레이드를 테스트하고 비정상적인 징후가 감지되면 즉시 돈을 인출할 수 있습니다.
프로젝트를 허니팟으로 식별하는 신호? 계약에는 구매만 허용하고 판매는 허용하지 않는 로직이 포함되어 있으며 일반적으로 화이트리스트 확인 조건 또는 100% 판매 수수료와 함께
_transfer기능에 숨겨져 있습니다.4 거버넌스 성숙도 수준은 무엇입니까? 포함 사항: 레벨 1(단일 EOA - 극도의 위험), 레벨 2(다중 서명 - 중간 위험), 레벨 3(시간 잠금 및 역할 분해 - 보안), 레벨 4(완전 불변 - 절대적 보안).
숨겨진 소유자를 검색하는 데 가장 적합한 도구는 무엇입니까? Tan Phat Digital은 빠르고 쉬운 검색을 위해 TokenSniffer와 GoPlus Security의 조합을 사용할 것을 권장합니다. 기술적 지식이 있는 경우 더 깊은 정적 분석을 위해 미끄러지듯 이동하세요.
검증된(녹색 체크 표시) 계약이 여전히 난잡한 이유는 무엇입니까? 개발자는 검증되지 않은 외부 라이브러리(예: StableMagnet 사례)에 연결하거나 사용자가 신뢰한 후 자동 프록시 업그레이드를 수행할 수 있기 때문입니다.
관리 이벤트 추적: 소유자가 주장하는 경우 "이벤트" 탭에서 OwnershipTransferred 이벤트를 확인하세요. 권리를 포기했다면 새 주소가 "소각"(0x...죽음) 주소인지 확인하세요.
숨겨진 소유자에 대한 15가지 자주 묻는 질문(FAQ)
다음은 숨겨진 소유자 메커니즘에 대한 일반적인 질문에 대한 Tan Phat Digital의 자세한 답변입니다.
"거짓 분산화"에 주의하세요.
개념 "Hidden Owner"는 이 세상에서 Web3의 세계에서 소스 코드는 인간이 일방적으로 법을 변경할 수 있는 열쇠를 쥐고 있지 않은 경우에만 진정한 법임을 상기시켜 줍니다. 숨겨진 관리자 권한이 있으면 상당한 중앙화 위험이 발생합니다.
Tan Phat Digital은 절대적인 개발자 제어가 투명하고 시간 제한이 있는 거버넌스 메커니즘(Timelock) 및 커뮤니티 합의로 대체될 때만 블록체인 프로젝트가 진정으로 핵심 가치인 위임 없는 신뢰를 달성할 수 있다고 믿습니다. 소셜 네트워크에서의 약속을 절대 믿지 마세요. 코드가 실제로 체인에서 실행되는 것을 신뢰하세요.
공유
