블록 체인의 프록시 계약이란 무엇입니까?

블록 체인 기술의 프록시 계약은 스마트 계약의 업그레이드 가능성을 허용하는 중요한 구성 요소입니다. 분산 된 응용 프로그램 (DAPP) 및 블록 체인 플랫폼의 세계에서는 기본 시스템을 방해하지 않고 스마트 계약을 업데이트하고 수정하는 기능이 필수적입니다. 프록시 계약은 종종 '구현'또는 '논리'계약이라고하는 다른 계약에 대한 전화를 대표하는 중개자 역할을합니다. 이러한 문제를 분리하면 개발자는 주소를 변경하지 않고 계약의 논리를 업데이트 할 수 있으므로 연속성을 유지하고 응용 프로그램과의 사용자 상호 작용을 유지할 수 있습니다.

프록시 계약의 작동 방식

프록시 계약의 핵심 기능은 구현 계약에 대한 통화를 전달하는 능력을 중심으로 진행됩니다. 사용자가 DAPP와 상호 작용하면 거래가 프록시 계약으로 전송되어 이러한 통화를 구현 계약으로 위임합니다. 이 과정은 중개 단계를 알지 못하는 사용자에게 투명합니다. 프록시 계약은 현재 구현 계약의 주소를 저장하고 필요한 경우 새로운 구현을 가리 키도록 업데이트 될 수 있습니다.

프록시 계약의 유형

프록시 계약에는 여러 가지 유형의 프록시 계약이 있으며, 각각 블록 체인 생태계 내에서 특정 요구에 부응하도록 설계되었습니다. 가장 일반적인 유형은 다음과 같습니다.

• 투명한 프록시 :이 프록시는 통화를 전달하는 것 이상으로 최소한의 논리로 가능한 한 간단하게 설계되었습니다. 일반적으로 초점이 단순성과 이해의 용이성에 초점을 맞출 때 사용됩니다.

• UUPS (UPS) 프록시 : UUPS 프록시는 구현 계약 자체를 업그레이드 할 수 있도록 더 많은 유연성을 제공합니다. 이 유형의 프록시는 자주 업데이트가 필요한 복잡한 응용 프로그램에 특히 유용합니다.

• Beacon Proxies : Beacon Proxies는 구현 주소를 관리하기 위해 별도의 '비콘'계약을 사용합니다. 이 접근법은 여러 대리 계약이 동일한 구현을 공유 해야하는 시나리오에 유리합니다.

프록시 계약 사용의 이점

프록시 계약을 사용하면 블록 체인 공간 내의 개발자와 사용자에게 몇 가지 중요한 이점이 있습니다. 첫째 , 프록시 계약을 통해 사용자 경험을 방해하지 않고 스마트 계약을 원활하게 업그레이드 할 수 있습니다. 이는 버그 수정, 새로운 기능 추가 또는 기존 기능 최적화에 중요합니다. 둘째 , 프록시 계약은 개발자가 통제 된 환경에서 새로운 구현을 라이브로 만들기 전에 새로운 구현을 배포하고 테스트 할 수있게함으로써 보안을 향상시킵니다. 마지막으로 프록시 계약은 계약의 주소가 업데이트 후에도 일정하게 유지되므로 기존 시스템과의 호환성을 유지하는 데 도움이 될 수 있습니다.

프록시 계약의 구현

프록시 계약을 구현하기 위해 개발자는 일련의 단계를 따라 프록시 및 구현 계약이 완벽하게 함께 작동하도록합니다. 다음은 기본 프록시 계약을 설정하는 방법에 대한 자세한 안내서입니다.

• 구현 계약 작성 : 응용 프로그램의 논리가 포함 된 스마트 계약을 작성하여 시작하십시오. 이 계약은 시간이 지남에 따라 업그레이드되는 계약입니다.

• 구현 계약 배포 : 구현 계약을 블록 체인 네트워크에 배포하십시오. 프록시 계약에 사용될이 계약의 주소에 유의하십시오.

• 프록시 계약서 작성 : 프록시 계약은 구현 계약의 주소를 저장하고 전화를 전달하도록 설계되어야합니다. 아래는 견고성에서 프록시 계약의 단순화 된 예입니다.

 // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; 계약 프록시 {

address public implementation; constructor(address _implementation) { implementation = _implementation; } function upgradeTo(address newImplementation) public { implementation = newImplementation; } 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) } } }
 }

• 프록시 계약 배포 : 프록시 계약을 블록 체인에 배치하여 구현 계약의 주소를 생성자 인수로 전달합니다.

• 프록시 계약과 상호 작용하십시오 . 사용자 및 기타 계약은 이제 프록시 계약과 상호 작용하여 구현 계약에 대한 전화를 위임 할 수 있습니다.

• 구현 업그레이드 : 업그레이드가 필요한 경우 새 구현 계약을 배포하고 프록시 계약의 upgradeTo 기능을 호출하여 새로운 구현 주소를 지적하십시오.

프록시 계약의 사용 사례

프록시 계약은 다양한 블록 체인 응용 프로그램에서 광범위한 사용을 찾습니다. 공통 사용 사례 중 하나 는 분산 금융 (DEFI) 플랫폼에 있으며, 스마트 계약은 변화하는 시장 상황에 적응하고 취약성을 고정하기 위해 자주 업데이트되어야합니다. 또 다른 사용 사례 에는 새로운 기능과 개선 사항이 정기적으로 사용자 경험을 향상시키기 위해 Gaming Dapps가 포함됩니다. 또한 프록시 계약은 NFT (Unbunbial Token) 플랫폼에서 디지털 자산의 수명주기를 관리하고 기존 토큰을 방해하지 않고 새로운 기능을 도입하기 위해 사용됩니다.

잠재적 위험 및 고려 사항

프록시 계약은 상당한 혜택을 제공하지만 개발자가 알아야 할 특정 위험과 고려 사항도 제공됩니다. 주요 관심사 중 하나 는 프록시 패턴에 의해 도입 된 복잡성으로, 시스템을 감사하고 이해하기가 더 어려워 질 수 있습니다. 또 다른 위험 은 업그레이드 프로세스의 오류 가능성으로 의도하지 않은 행동이나 자금 손실로 이어질 수 있습니다. 또한 프록시 계약에 대한 의존은 프록시 자체가 손상되면 단일 실패 지점을 만들 수 있습니다.

이러한 위험을 완화하기 위해 개발자는 철저한 테스트, 정기 감사 및 업그레이드를위한 강력한 거버넌스 메커니즘 구현과 같은 모범 사례를 따라야합니다. 또한 프록시 계약을 확립 된 표준 및 패턴을 사용하여 취약점을 최소화하기 위해 보안을 염두에두고 설계해야합니다.

자주 묻는 질문

Q : 프록시 계약을 사용하여 이전 버전의 구현 계약으로 되돌릴 수 있습니까?

A : 예, 프록시 계약은 이전 버전의 구현 계약으로 되돌릴 수 있도록 설계 될 수 있습니다. 이는 모든 과거 구현의 주소를 저장하고 이전 버전으로 다시 전환 할 수있는 함수를 제공함으로써 달성 할 수 있습니다. 그러나이 접근법은 철회에 새로운 문제 나 취약점을 도입하지 않도록 신중한 관리 및 거버넌스가 필요합니다.

Q : 프록시 계약을 지원하지 않는 블록 체인 플랫폼이 있습니까?

A : Ethereum 및 Binance Smart Chain과 같은 대부분의 주요 블록 체인 플랫폼은 대리 계약을 지원합니다. 그러나 Bitcoin과 같이 스마트 계약 기능이 더 제한된 일부 플랫폼은 더 간단한 스크립팅 언어와 튜링 캐스트 스마트 계약 기능의 부족으로 인해 프록시 계약을 지원하지 않습니다.

Q : 사용자는 프록시 계약이 통화를 올바르게 전달하는지 어떻게 확인할 수 있습니까?

A : 사용자는 블록 체인 탐색기에서 거래 로그 및 계약 상태를 검사하여 프록시 계약의 올바른 기능을 확인할 수 있습니다. 프록시에 저장된 구현 계약의 주소를 확인하고 예상 주소와 비교할 수 있습니다. 또한 사용자는 프록시의 소스 코드와 사용 가능한 모든 감사를 검토하여 전달 메커니즘이 올바르게 구현되도록 할 수 있습니다.

Q : 프록시 계약 배포 및 업그레이드와 관련된 비용은 얼마입니까?

A : 프록시 계약 배포 및 업그레이드와 관련된 비용에는 프록시 및 구현 계약 배포 및 업그레이드 기능 실행에 대한 가스 수수료가 포함됩니다. 정확한 비용은 배치 및 업그레이드시 계약의 복잡성과 블록 체인 네트워크의 가스 가격에 따라 다릅니다. 개발자는 사용자의 비용을 최소화하기 위해 업그레이드 전략을 계획 할 때 이러한 비용을 고려해야합니다.