프록시 계약이란 무엇입니까?

프록시 계약의 개념 이해

프록시 계약은 이더 리움과 같은 블록 체인 플랫폼의 스마트 계약 개발 에 일반적으로 사용되는 설계 패턴입니다. 주요 목적은 계약의 논리를 스토리지 에서 분리하는 것입니다. 이 분리를 통해 개발자는 계약 주소를 변경하거나 프록시 자체에 저장된 데이터를 잃지 않고 계약의 논리를 업그레이드 하거나 수정할 수 있습니다.

프록시 계약은 종종 구현 계약 이라고하는 다른 계약으로 전화를 전달하는 중개자 역할을합니다. 프록시는 모든 상태 변수를 보유하고 구현 계약에는 기능 및 비즈니스 논리가 포함되어 있습니다. 이 아키텍처 패턴은 분산 된 응용 프로그램 (DAPPS)에서 장기적인 유연성을 유지하는 데 중요합니다.

프록시 계약의 작동 방식

프록시 계약의 메커니즘은 EVM (Ethereum Virtual Machine) 의 DelegateCall 기능에 크게 의존합니다. 사용자가 프록시 계약과 상호 작용할 때 프록시는 DelegateCall을 사용하여 실행을 현재 구현 계약으로 전달합니다. 이를 통해 코드는 프록시의 맥락에서 실행되도록 보장합니다. 이는 저장, 주소 및 잔액이 프록시 계약에 속합니다.

다음은 이것이 어떻게 작동하는지에 대한 고장입니다.

• 프록시 계약에는 현재 구현 주소 에 대한 참조가 포함되어 있습니다.
• 프록시에서 함수가 호출되면 DelegateCall을 사용하여 구현 계약의 맥락에서 해당 함수를 실행합니다.
• 실행 중 모든 변경 사항은 구현 계약이 아닌 프록시의 저장에 영향을 미칩니다.

이 방법을 사용하면 전체 계약 시스템을 재배치하지 않고 업그레이드 가능성이 가능하며, 이는 사용자 신뢰 및 계약 연속성을 유지하는 데 필수적입니다.

다른 유형의 프록시 계약

각각 특정 사용 사례 및 구현 세부 사항이있는 여러 유형의 프록시 계약이 있습니다.

• 투명한 프록시 :이 유형의 경로는 관리자 또는 일반 사용자로부터 온 것인지에 따라 다르게 호출됩니다. 관리자 호출은 프록시 관리자 계약으로 전달되며 정기 통화는 논리 계약으로 이동합니다.
• UUPS (범용 업그레이드 가능 프록시 표준) :이 모델에서는 업그레이드 기능이 로직 계약 자체 내에서 구현됩니다. 이는 동일한 표준을 사용하여 모든 프록시에서 일관된 업그레이드 메커니즘을 시행합니다.
• Beacon Proxy : 구현 주소를 직접 저장하는 대신이 프록시는 현재 구현 주소를 동적으로 제공하는 비콘 계약을 참조합니다. 이를 통해 여러 프록시에서 동시에 대량 업그레이드가 가능합니다.

각 프록시 유형에는 보안 , 업그레이드 가능성 및 복잡성 측면에서 장점과 트레이드 오프가 있습니다.

프록시 계약을 배치하는 단계

프록시 계약을 배포하려면 여러 단계가 필요합니다. 자세한 연습은 다음과 같습니다.

• 구현 계약 배포 : 실제 비즈니스 로직이 포함됩니다. UUPS와 같은 특정 프록시 유형을 사용하는 경우 향후 업그레이드를 방해 할 수 있으므로 생성자가 없어야합니다.
• 프록시 계약 배포 : 배포 중에 구현 계약의 주소를 지정합니다. 일부 프록시 계약에는 관리자 주소를 설정해야합니다.
• 프록시와 상호 작용하십시오 : 모든 사용자 상호 작용은 프록시를 통과해야합니다. 트러플 , 하드 하트 또는 리믹스 와 같은 도구를 사용하여 프록시와 상호 작용하고 올바른 ABI가 사용되도록하십시오.
• 구현 업그레이드 (필요한 경우) : 새로운 버전의 논리가 준비된 경우 새 구현 계약을 배포하고 프록시의 참조를 업데이트하십시오. 이 단계는 사용 된 프록시 유형에 따라 다릅니다.

자금 손실 이나 보안 취약점을 피하기 위해 이러한 각 단계를 신중하게 실행해야합니다.

프록시 계약에 대한 보안 고려 사항

프록시 계약은 개발자가 해결해야 할 새로운 보안 문제를 도입합니다.

• 스토리지 충돌 : 구현 계약 및 프록시가 신중하게 설계되지 않은 경우 스토리지 변수가 겹치면 의도하지 않은 데이터 손상으로 이어질 수 있습니다.
• 초기화 문제 : 구현 계약의 생성자는 초기화 기능 으로 대체되지 않으면 문제를 일으킬 수 있습니다. 배포 후 재개를 방지하기 위해 이러한 기능을 보호해야합니다.
• 액세스 제어 : 계약 업그레이드 기능은 엄격하게 제어되어야합니다. 관리 키의 잘못된 관리는 악의적 인 업그레이드 로 이어질 수 있습니다.
• 복잡성 테스트 : 프록시 계약은 테스트의 복잡성을 증가시켜 개발자가 프록시와 구현 계약을 철저히 테스트해야합니다.

OpenZeppelin 과 같은 프레임 워크에서 잘 알려진 프록시 패턴을 사용하면 이러한 많은 위험을 완화 할 수 있습니다.

프록시 계약의 사용 사례

프록시 계약은 장기 유지 보수가 필수적인 다양한 분산 금융 (Defi) 프로토콜 및 DAPP에서 널리 사용됩니다. 주목할만한 사용 사례에는 다음이 포함됩니다.

• 거버넌스 제어 업그레이드 : AAVE 또는 Compound Proxy Contracts와 같은 프로토콜은 사용자 상호 작용을 방해하지 않고 커뮤니티 중심의 업그레이드를 허용합니다.
• 재배치없이 버그 수정 : 배치 된 계약에서 중요한 버그가 발견되면 개발자는 새로운 구현에서 논리를 수정하고 사용자 잔액이나 계약 주소에 영향을 미치지 않고 프록시를 업그레이드 할 수 있습니다.
• 다중 계약 시스템 : 여러 계약이 함께 작동하는 시스템에서 프록시 계약은 모든 구성 요소를 조정 된 방식으로 업그레이드 할 수 있도록 할 수 있습니다.

이러한 사용 사례는 실제 블록 체인 응용 프로그램에서 프록시 계약의 실제 가치를 보여줍니다.

자주 묻는 질문

Q : 모든 유형의 스마트 계약에 프록시 계약을 사용할 수 있습니까? A : 프록시 계약은 널리 적용 가능하지만 업그레이드 가능성이 필요하지 않은 허가 없거나 불변 계약에 적합하지 않을 수 있습니다. 예를 들어, ERC-20 또는 ERC-721 과 같은 토큰 표준은 종종 프록시 패턴의 혜택을 받지만 일부 프로토콜은 신뢰 최소화 에 불변성을 선호합니다.

Q : 프록시 계약을 효과적으로 테스트하려면 어떻게해야합니까? A : 프록시 계약을 테스트하려면 프록시와 구현 로직을 모두 확인해야합니다. Hardhat 또는 Foundry 와 같은 테스트 프레임 워크를 사용하고 모든 상호 작용이 프록시를 통과하도록하십시오. 프록시 환경을 조롱하고 스토리지 무결성을 확인하는 것이 중요합니다.

Q : 프록시 계약은 모든 EVM 호환 블록 체인과 호환됩니까? A : 그렇습니다. 프록시 계약은 Binance Smart Chain , Polygon 및 Arbitrum을 포함한 모든 EVM 호환 체인 에서 사용할 수있는 Delegatecall 과 같은 EVM 기능 에 의존합니다. 그러나 툴링 또는 계약 검증의 차이는 배포 워크 플로에 영향을 줄 수 있습니다.

Q : 프록시 계약을 사용하는 가스의 영향은 무엇입니까? A : 프록시 계약은 추가 델리 게이 콜 단계로 인해 소량의 오버 헤드를 추가합니다. 그러나이 오버 헤드는 일반적으로 최소이며 사용자 경험에 크게 영향을 미치지 않습니다. 프록시 설계를 최적화하고 중복 통화를 최소화함으로써 가스 절약을 달성 할 수 있습니다.