최소 프록시 계약 (EIP-1167)은 무엇입니까?

최소 프록시 계약 이해

최소 프록시 계약은 최소한의 오버 헤드를 유지하면서 모든 통화를 다른 계약으로 전달하도록 설계된 가벼운 스마트 계약입니다. 특히 공유 논리와 계약의 여러 인스턴스를 배포 할 때 이더 리움 기반 시스템에서 중요한 역할을합니다. 이 개념은 EIP-1167 을 통해 공식화되었으며, 이는 최소한의 바이트 코드를 사용하여 기존 계약의 클론을 생성하기위한 표준을 간략하게 설명했습니다.

이 메커니즘의 핵심 아이디어는 코드 재사용 입니다. 개발자는 매번 동일한 논리로 새 계약을 배치하는 대신 모든 기능 호출을 기존 구현 계약으로 위임하는 프록시를 배포 할 수 있습니다. 이는 배포 비용을 크게 줄이고 업그레이드를 단순화합니다.

핵심 개념 : 최소 프록시 계약에는 실행을 대상 계약으로 리디렉션하는 데 필요한 코드 만 포함됩니다.

EIP-1167은 어떻게 작동합니까?

EIP-1167은 기능을 달성하기 위해 DelegateCall Opcode를 고안으로 활용합니다. DelegateCall을 사용하면 한 계약을 통해 전화 계약의 컨텍스트 (예 : MSG.Sender 및 Storage)를 보존하면서 한 계약이 다른 계약에서 코드를 실행할 수 있습니다. 최소한의 프록시의 경우, 이는 대리인이 발신자의 컨텍스트를 변경하지 않고 모든 들어오는 통화를 구현 계약으로 전달하는 것을 의미합니다.

작동 방식은 다음과 같습니다.

• 프록시 계약에는 구현 계약의 주소를 보유하는 단일 스토리지 슬롯이 포함되어 있습니다.
• 사용자가 프록시와 상호 작용하면 폴백 함수가 트리거됩니다.
• 이 폴백 기능은 DelegateCall을 사용하여 호출을 저장된 구현 주소로 전달합니다.

단순성으로 인해 프록시 계약은 50,000 가스 미만의 배치에 가스가 거의 필요하지 않습니다. 이 효율성은 많은 유사한 계약을 빠르고 저렴하게 배포 해야하는 시나리오에 이상적입니다.

최소 프록시 계약의 구조

최소 프록시 계약은 일반적으로 EIP-1167에 의해 정의 된 엄격한 구조를 따릅니다. 다음은 다음과 같습니다.

• 구현 계약을 가리키는 일정한 주소 변수.
• 해당 구현 주소에 대한 델리게 콜을 수행하는 폴백 기능.
• 구현 주소 이외의 생성자 또는 상태 변수가 없습니다.

이 디자인은 프록시가 논리 자체를 저장하지 않고 단순히 구현 계약의 도관 역할을합니다. 아래는 Solidity로 작성된 이러한 계약의 단순화 된 버전입니다.

 pragma solidity ^0.8.0; 계약 최소 프록시 {

address private immutable 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) } } }
 }

중요 참고 : 폴백 기능에서 인라인 어셈블리를 사용하는 것은 프록시를 최소화하고 효율적으로 유지하는 데 필수적입니다.

최소 프록시 계약에 대한 사용 사례

최소 프록시 계약은 효율성과 유연성으로 인해 다양한 분산 응용 프로그램 및 프로토콜에 널리 사용됩니다. 가장 일반적인 사용 사례 중 일부는 다음과 같습니다.

• 토큰 공장 : 단일 구현 계약에서 여러 ERC-20 또는 ERC-721 토큰 생성.
• 업그레이드 가능한 계약 : 투명한 프록시 또는 UUP와 같은 업그레이드 패턴을위한 기본 계층 역할.
• 가스 효율적인 배포 : 수백 또는 수천 개의 계약을 인스턴스화 할 때 배치 비용 절감.
• 계약 템플릿 : 여러 배포에서 예측 가능한 동작을위한 표준화 된 템플릿을 제공합니다.

이러한 각 사용 사례는 배포 풋 프린트 감소와 여러 프록시에서 일관된 논리를 유지하는 능력의 이점이 있습니다.

최소 프록시 및 기타 프록시 패턴의 차이

Ethereum에는 투명한 프록시, UUPS (UPPERAL 업그레이드 가능 프록시 표준) 및 비콘 프록시를 포함하여 몇 가지 프록시 패턴이 있습니다. 각각은 복잡성, 업그레이드 가능성 및 가스 비용 측면에서 자체 트레이드 오프가 있습니다.

최소 프록시 와 기타 프록시 유형의 주요 차이점은 기능과 확장성에 있습니다.

• 최소 프록시는 추가 인프라와 쌍을 이루지 않는 한 업그레이드를 지원하지 않습니다.
• 투명한 프록시에는 관리자 로직 및 프록시 레지스트리가 포함되며 가스 사용량 및 복잡성 증가가 포함됩니다.
• UUPS 프록시는 구현 계약을 통한 자체 포함 업그레이드를 허용합니다.

최소 프록시는 배포 후 구현이 정적으로 유지되거나 업그레이드가 외부에서 처리되는 시나리오에 가장 적합합니다.

보안 고려 사항 및 모범 사례

최소 프록시 계약은 간단하지만 위험이 없습니다. 개발자는 모범 사례를 따라 안전한 사용을 보장해야합니다.

• 구현 불변성 확인 : 일단 배포되면 구현 주소는 명시 적으로 의도하고 확보하지 않는 한 변경되지 않아야합니다.
• 스토리지 충돌을 피하십시오 : 프록시 및 구현 공유 저장소 컨텍스트이므로 나중에 프록시를 확장하면 신중한 계획이 필요합니다.
• 바이트 코드 확인 : 악성 수정을 방지하기 위해 프록시 및 구현 계약의 바이트 코드를 항상 확인하십시오.
• 철저히 테스트 : Hardhat 또는 Foundry와 같은 도구를 사용하여 Mainnet 배포 전에 상호 작용 및 테스트 엣지 케이스를 시뮬레이션하십시오.

중요한 팁 : 프록시 계약이 구현에서 보안을 상속한다고 가정하지 마십시오. 이는 별도로 감사를 받아야합니다.

자주 묻는 질문

Q : 최소 프록시 계약을 업그레이드 할 수 있습니까? 최소한의 프록시 자체에는 업그레이드 로직이 포함되어 있지 않지만 UUPS와 같은 다른 표준과 결합하거나 외부 컨트롤러를 사용하여 구현 주소를 관리하여 업그레이드 가능한 시스템을 만들 수 있습니다.

Q : 전체 계약에 비해 최소 프록시를 얼마나 저렴하게 배포하고 있습니까? 최소 프록시를 배포하는 데 일반적으로 약 20,000 ~ 50,000 가스가 비용이 발생하지만 전체 계약을 배치하는 것은 복잡성에 따라 2 백만 가스를 초과 할 수 있습니다.

Q : 배포 된 프록시에서 구현 주소를 검색하는 방법이 있습니까? 예, 구현 주소는 일반적으로 특정 스토리지 슬롯 (종종 슬롯 0)에 저장됩니다. eth_getStorageAt 와 같은 도구를 사용하거나 계약 작성 코드를 검사하여 읽을 수 있습니다.

Q : 최소 프록시가 모든 견고성 버전과 호환됩니까? 그들은 견고성 0.5.0 이상과 잘 작동합니다. 그러나 최적의 호환성 및 가스 절약을 위해서는 Soludity 0.8.x 또는 새로운 것을 사용하는 것이 좋습니다.