프록시 계약이란 무엇이며 어떻게 업그레이드 가능성을 가능하게합니까?

스마트 계약 개발에서 프록시 계약 이해

블록 체인 및 스마트 계약 개발의 세계에서 프록시 계약은 중요한 설계 패턴으로 등장했습니다. 배포되면 불변이 불가능한 기존의 스마트 계약과 달리 프록시 계약은 전체 계약을 재배치하지 않고 변경 및 업그레이드를 구현하기위한 구조화 된 메커니즘을 제공합니다. 이 유연성은 특히 배포 된 코드를 직접 변경할 수없는 이더 리움과 같은 환경에서 특히 중요합니다. 프록시 계약은 사용자와 응용 프로그램의 실제 논리 사이의 중개자 역할을하므로 개발자는 시간이 지남에 따라 기능을 업데이트 할 수 있습니다.

프록시 계약의 작동 방식 : 기술 개요

핵심적으로 프록시 계약은 구현 계약으로 알려진 다른 계약을 중심으로 정면 또는 포장지 역할을합니다. 사용자가 프록시와 상호 작용하면 delegatecall Opcode를 사용하여 기능 호출을 구현 계약으로 전달합니다. 이 Opcode는 논리가 다른 곳에 상주하더라도 실행 컨텍스트 (예 : 스토리지 및 발신자 주소)가 프록시 상태와 일치하는 상태를 유지합니다.

• 프록시는 계약의 상태를 유지합니다.
• 구현 계약에는 비즈니스 논리가 포함되어 있습니다.
• 사용자의 기능 호출은 프록시를 통해 현재 구현으로 라우팅됩니다.

이 분리를 통해 구현에 대한 업데이트가 가능하면서 프록시 주소와 관련된 모든 기존 데이터 및 상호 작용을 보존 할 수 있습니다.

업그레이드 가능성을 가능하게하는 DelegateCall의 역할

프록시 계약의 업그레이드 가능성을 가능하게하는 주요 기술 기능은 delegatecall 메커니즘입니다. Solidity에서 delegatecall 한 계약을 통해 발신자의 스토리지, 값 및 컨텍스트를 유지하면서 다른 계약에서 코드를 실행할 수 있습니다. 이는 프록시 계약이 delegatecall 사용하여 구현 계약에서 기능을 호출 할 때 실행 중에 변경된 변경이 구현이 아닌 대리의 스토리지에 영향을 미친다는 것을 의미합니다.

이 동작은 다음과 같이 필수적입니다.

• 업그레이드 후에도 데이터가 지속되도록합니다.
• 스토리지에서 논리를 분리시켜 향후 수정에 필요합니다.

delegatecall 없으면 업그레이드는 계약과 관련 데이터를 모두 재배치해야하므로 잠재적 인 불일치와 정보 손실로 이어집니다.

실제로 사용되는 프록시 패턴의 유형

이더 리움 생태계 내에 몇 가지 프록시 패턴이 존재하며, 각각의 복잡성과 제어를 제공합니다.

• 투명 프록시 패턴 :이 접근법은 발신자가 관리자가 아닌 한 모든 외부 호출을 구현 계약으로 라우팅합니다. 이를 통해 거버넌스 운영이 정기적 인 사용자 상호 작용을 방해하지 않도록합니다.

• UUPS (범용 업그레이드 가능 프록시 표준) :이 모델에서 업그레이드 로직은 구현 계약 자체의 일부입니다. 이는 구현 수준에서 업그레이드를 제어 할 수 있도록하여 중앙 집중화 위험을 줄입니다.

• Beacon Proxy Pattern : 구현 주소를 하드 코딩하는 대신 Beacon Proxy는 별도의 비콘 계약에서 최신 구현 주소를 검색합니다. 이를 통해 여러 프록시에서 대량 업그레이드가 동시에 가능합니다.

이러한 각 모델은 보안, 탈 중앙화 및 유지 보수 용이성 측면에서 트레이드 오프가있어 프로젝트 요구 사항에 따라 다양한 사용 사례에 적합합니다.

기본 프록시 계약 구현 : 단계별 안내서

기본 프록시 계약을 작성하려면 몇 가지 정확한 단계가 필요합니다. 견고성을 사용하여 수동으로 수행하는 방법은 다음과 같습니다.

• 구현 계약 작성 : 표준 견고 계약에서 응용 프로그램의 핵심 논리를 정의하십시오. 예를 들어, 균형 추적 및 전송 기능으로 간단한 토큰 계약을 만듭니다.

• 구현 계약 배포 : Hardhat 또는 Truffle과 같은 배포 스크립트 또는 도구를 사용하여 구현 계약을 원하는 네트워크에 배포하십시오. 계약 주소를 기록하십시오.

• 프록시 계약 만들기 : 구현 주소를 저장하고 delegatecall 사용하여 들어오는 거래를 전달하는 프록시 계약을 작성하십시오. 폴백 함수가 알 수없는 기능 호출을 올바르게 처리하는지 확인하십시오.

 pragma solidity ^0.8.0; 계약 프록시 {

address public implementation; constructor(address _implementation) { implementation = _implementation; } fallback() external payable { address impl = implementation; assembly { let ptr := mload(0x40) calldatacopy(ptr, 0, calldatasize()) let result := delegatecall(gas(), impl, ptr, calldatasize(), 0, 0) let size := returndatasize() returndatacopy(ptr, 0, size) switch result case 0 { revert(ptr, size) } default { return(ptr, size) } } }
 }

• 프록시 계약 배포 : 프록시를 배치하고 구현 주소를 생성자에게 전달하십시오.

• 프록시와 상호 작용하십시오 : 모든 사용자 상호 작용은 프록시 계약을 거쳐야하여 지속적인 상태를 유지하면서 올바른 논리가 실행되도록해야합니다.

보안 고려 사항 및 모범 사례

업그레이드 가능성은 새로운 공격 벡터를 도입하고 신중한 취급이 필요합니다. 몇 가지 중요한 고려 사항은 다음과 같습니다.

• 관리자 액세스 제어 : 신뢰할 수있는 엔티티 만 업그레이드를 시작할 수 있어야합니다. 무단 변경 사항을 방지하기 위해 다중 서명 지갑 또는 타임 락을 구현하십시오.

• 스토리지 충돌 : 프록시 및 구현 계약에 스토리지 변수가 겹치는 경우 데이터 손상이 발생할 수 있습니다. 충돌을 피하기 위해 OpenZeppelin의 Initializable 와 같은 라이브러리를 사용하십시오.

• 테스트 및 감사 : 스테이징 환경에서 프록시 기반 시스템을 철저히 테스트합니다. 악용 가능한 취약점이 없는지 확인하기 위해 Mainnet에 배포하기 전에 공식 감사를 수행하십시오.

• 문서 및 투명성 : 업그레이드 절차를 명확하게 문서화하고 잠재적 변경에 대해 사용자와의 투명성을 유지합니다.

모범 사례를 준수함으로써 개발자는 위험을 완화하면서 업그레이드 가능한 스마트 계약의 이점을 활용할 수 있습니다.

자주 묻는 질문

Q1 : 누구든지 프록시 계약을 업그레이드 할 수 있습니까? 아니요, 일반적으로 액세스 제어 메커니즘에 의해 관리되는 관리 권한을 가진 주소 만 업그레이드를 수행 할 수 있습니다. 무단 액세스를 방지하려면 적절한 역할 관리가 필수적입니다.

Q2 : 과거 버전의 구현 계약을 추적 할 수 있습니까? 그렇습니다. 과거 구현 주소를 쇄 또는 오프 체인을 저장함으로써 개발자는 특정 기간 동안 사용 된 이전 버전을 감사하고 확인할 수 있습니다.

Q3 : 통화 중에 구현 계약이 되돌아 오면 어떻게됩니까? 구현 계약이 되돌아 가면 거래가 실패하고 통화 중에 주정부 변경이 롤백됩니다. 프록시 계약은 실패한 논리 변경을 유지하지 않습니다.

Q4 : 프록시 계약은 모든 이더 리움 가상 머신 (EVM)과 호환됩니까? 예, delegatecall 과 같은 기본 EVM 기능에 의존하기 때문에 프록시 계약은 Binance Smart Chain, Polygon 및 Avalanche와 같은 모든 EVM 호환 네트워크에서 작동합니다.