건조 제품: 다이아몬드 에이전시 계약을 위한 최상의 보안 관행

CertiK

特邀专栏作者

2023-06-22 08:30

이 기사는 약 3319자로, 전체를 읽는 데 약 5분이 소요됩니다

다이아몬드 프록시 모델의 계약 설계는 이더리움 네트워크의 최대 계약 크기 제한 문제를 해결할 수 있습니다. 이 문서에서는 널리 사용되는 투명 프록시 모드 및 UUPS 프록시 모드와의 비교와

프록시 계약은 스마트 계약 개발자에게 중요한 도구입니다. 오늘날 계약 시스템에는 많은 프록시 모드와 해당 사용 규칙이 있습니다. 우리는 이전에 업그레이드 가능한 프록시 계약 보안 모범 사례를 간략하게 설명했습니다.

이 기사에서는 개발자 커뮤니티에서 인기 있는 또 다른 프록시 모델인 다이아몬드 프록시 모델을 소개합니다.

"다이아몬드"라고도 하는 다이아몬드 프록시 계약은 EIP(Ethereum Improvement Proposal) 2535에서 도입한 이더리움 스마트 계약의 설계 패턴입니다.

다이아몬드 모드를 사용하면 기능을 더 작은 계약("측면"이라고도 함)으로 분할하여 계약이 무제한 기능을 가질 수 있습니다. Diamond는 함수 호출을 적절한 측면으로 라우팅하는 프록시 역할을 합니다.

다이아몬드 모델의 설계는 이더리움 네트워크의 최대 계약 크기 제한 문제를 해결할 수 있습니다. 큰 계약을 더 작은 측면으로 분해함으로써 다이아몬드 패턴을 통해 개발자는 크기 제약의 영향을 받지 않고 더 복잡하고 기능이 풍부한 스마트 계약을 구축할 수 있습니다.

Diamond Brokerage는 기존의 업그레이드 가능한 계약에 비해 엄청난 유연성을 제공합니다. 다른 부분을 건드리지 않고 기능의 선택된 부분을 추가, 교체 또는 제거하여 계약 부분을 업그레이드할 수 있습니다.

이 문서에서는 널리 사용되는 투명 프록시 모드 및 UUPS 프록시 모드와의 비교와 개발자 커뮤니티를 위한 보안 고려 사항을 포함하여 EIP-2535에 대한 개요를 제공합니다.

EIP-2535의 맥락에서,"다이아몬드""측면"이라고 하는 다른 논리 계약에 의해 기능이 구현되는 프록시 계약입니다.

실제 다이아몬드에는 패싯이라고 하는 다른 면이 있고 해당하는 이더리움 다이아몬드 계약에도 다른 면이 있다고 상상해 보십시오. 다이아몬드 차용 기능의 각 계약은 다른 측면 또는 패싯입니다.

다이아몬드 표준은 비유를 사용하여 "다이아몬드 컷"의 기능을 확장하여 패싯 및 기능을 추가, 교체 또는 삭제합니다.

또한 Diamond Standard는 다이아몬드의 패싯과 존재 여부에 대한 정보를 반환하는 "Diamond Loupe"라는 기능을 제공합니다.

전통적인 대리 모델과 비교할 때 "다이아몬드"는 대리 계약과 동일하며 다른 "측면"은 계약 실현에 해당합니다. 다이아몬드 에이전트의 다양한 측면은 내부 기능, 라이브러리 및 상태 변수를 공유할 수 있습니다. 다이아몬드의 주요 구성 요소는 다음과 같습니다.

프록시 역할을 하는 중앙 컨트랙트, 함수 호출을 적절한 측면으로 라우팅합니다. 여기에는 "aspect" 주소에 대한 기능 선택기의 매핑이 포함됩니다.

특정 기능을 구현하는 단일 계약입니다. 각 패싯에는 다이아몬드가 호출할 수 있는 함수 집합이 포함되어 있습니다.

EIP-2535에 정의된 표준 기능 집합으로 다이아몬드에 사용되는 패싯 및 기능 선택기에 대한 정보를 제공합니다. Diamond Loupe를 통해 개발자와 사용자는 다이아몬드의 구조를 검사하고 이해할 수 있습니다.

다이아몬드 및 해당 기능 선택기에서 패싯을 추가, 교체 또는 제거하는 기능. 승인된 주소(예: 다이아몬드 소유자 또는 다중 서명 계약)만 다이아몬드 절단을 수행할 수 있습니다.

기존 프록시와 마찬가지로 다이아몬드 프록시에서 함수 호출이 이루어지면 프록시의 대체 기능(fallback function)이 트리거됩니다. 다이아몬드 프록시와의 주요 차이점은 폴백 함수에는 호출된 함수의 구현이 있는 논리적 계약 주소를 저장하고 결정하는 selectorToFacet 매핑이 있다는 것입니다. 그런 다음 기존 프록시와 마찬가지로 delegatecall을 사용하여 함수를 실행합니다.

모든 프록시는 함수 호출을 외부 주소로 위임하는 fallback() 함수를 사용합니다. 아래는 다이아몬드 프록시 구현과 기존 프록시 구현입니다.

어셈블리 코드 블록이 매우 유사하므로 유일한 차이점은 다이아몬드 프록시 대리자 호출의 aspect 주소와 기존 프록시 대리자 호출의 impl 주소입니다.

주요 차이점은 다음과 같습니다. 다이아몬드 프록시에서 애스펙트의 주소는 호출자의 msg.sig(함수 선택기)에서 애스펙트의 주소까지의 해시맵에 의해 결정되는 반면, 기존 프록시에서는 impl 주소가 의존하지 않습니다. 발신자가 입력합니다.

다이아몬드 에이전트 폴백 기능

전통적인 프록시 폴백 기능

SelectorToFacet 매핑은 각 기능 선택기의 구현을 포함하는 계약을 결정합니다. 프로젝트 작업자는 종종 이 기능 선택기-구현 계약 매핑을 추가, 교체 또는 제거해야 합니다. EIP-2535 상태: 이를 달성하려면 diamondCut() 함수가 있어야 합니다. 아래는 예제 인터페이스입니다.

각 FacetCut 구조에는 다이아몬드 프록시 계약에서 업데이트할 패싯 주소와 4바이트 기능 선택기 배열이 포함되어 있습니다. FaceCutAction을 사용하면 기능 선택기를 추가, 교체 및 제거할 수 있습니다. diamondCut() 함수의 구현에는 적절한 액세스 제어, 슬롯 충돌 방지, 실패 시 복구 등이 포함되어야 합니다.

다이아몬드 에이전트가 어떤 기능과 측면을 가지고 있는지 알아보기 위해 "다이아몬드 돋보기"를 사용합니다. "Diamond Loupe"는 EIP-2535에 정의된 다음 인터페이스를 구현하는 특별한 측면입니다.

facets() 함수는 모든 패싯의 주소와 4바이트 함수 선택자를 반환해야 합니다. facetFunctionSelectors() 함수는 특정 측면에서 지원하는 모든 함수 선택기를 반환해야 합니다. facetAddresses() 함수는 다이아몬드가 사용하는 모든 패싯 주소를 반환해야 합니다.

facetAddress() 함수는 주어진 선택자를 지원하는 측면을 반환하거나, 찾지 못한 경우 주소(0)를 반환해야 합니다. 동일한 기능 선택기를 가진 하나 이상의 애스펙트 주소가 있어서는 안 됩니다.

다이아몬드 프록시가 서로 다른 함수 호출을 서로 다른 구현 계약에 위임한다는 점을 감안할 때 충돌을 방지하기 위해 스토리지 슬롯을 적절하게 관리하는 것이 중요합니다. EIP-2535는 여러 스토리지 슬롯 관리 방법을 언급합니다.

이 측면은 구조에서 상태 변수를 선언할 수 있습니다. 이 측면은 각각 다른 저장 위치를 가진 여러 구조를 사용할 수 있습니다. 각 구조에는 계약 저장소의 특정 위치가 있습니다. 관점은 자신의 상태 변수를 선언할 수 있지만 다른 관점에서 선언한 상태 변수의 저장 위치와 충돌할 수 없습니다. 샘플 라이브러리 및 다이아몬드 스토리지 계약은 다음 그림과 같이 EIP-2535에서 제공됩니다.

App Store는 Diamond Store의 보다 전문화된 버전입니다. 이 패턴은 aspect의 상태 변수를 보다 편리하고 쉽게 공유하기 위해 사용된다. 앱 스토어 구조는 애플리케이션에 필요한 상태 변수의 수와 유형을 포함하도록 정의됩니다. 관점은 항상 AppStorage 구조를 스토리지 슬롯의 위치 0에서 첫 번째이자 유일한 상태 변수로 선언합니다. 그러면 다른 측면에서 이 구조의 변수에 액세스할 수 있습니다.

보조 제목

투명 프록시 및 UUPS 프록시와의 비교

현재 Web3 개발자 커뮤니티에서 사용하는 두 가지 주요 프록시 모드는 투명 프록시 모드와 UUPS 프록시 모드입니다. 이 섹션에서는 다이아몬드 프록시 모드를 투명 프록시 및 UUPS 프록시 모드와 간략하게 비교합니다.

1.EPI-2535:https://eips.ethereum.org/EIPS/eip-2535 #Facets,% 20 State% 20 Variables% 20 and% 20 Diamond% 20 Storage

2.EPI-1967:https://eips.ethereum.org/EIPS/eip-1967

3.Diamond proxy reference implementation: https://github.com/mudgen/Diamond

4.OpenZeppelin implementation: https://github.com/OpenZeppelin/openzeppelin-contracts/tree/v4.7.0/contracts/proxy

프록시 및 확장 가능한 솔루션은 더 복잡한 시스템이며 OpenZeppelin은 UUPS, 투명 및 Beacon 확장 가능한 프록시에 대한 코드 기반과 포괄적인 문서를 제공합니다. 그러나 다이아몬드 프록시 패턴의 경우 OpenZeppelin은 그 이점을 확인했지만 여전히 라이브러리에 EIP-2535 다이아몬드 구현을 포함하지 않기로 결정했습니다.

따라서 기존 타사 라이브러리를 사용하거나 이 솔루션을 직접 구현하는 개발자는 매우 주의하여 구현해야 합니다. 여기에서 개발자 커뮤니티가 고려해야 할 보안 모범 사례의 체크리스트를 작성했습니다.

계약 논리를 더 작고 관리하기 쉬운 모듈로 나누면 개발자는 코드를 더 쉽게 테스트하고 감사할 수 있습니다.

이미지 설명

출처: Aavegotchi Github

이미지 설명

출처: Mugen의 Diamond-3-안전모

스마트 계약의 저장소 구조에 새 상태 변수를 추가할 때 구조 끝에 추가해야 합니다. 구조의 시작 부분이나 중간에 새 상태 변수를 추가하면 새 상태 변수가 기존 상태 변수 데이터를 덮어쓰게 되고 새 상태 변수 뒤의 모든 상태 변수는 잘못된 메모리 위치를 참조할 수 있습니다.

AppStorage 패턴에서는 다이아몬드 프록시에 대해 하나의 구조만 선언하고 이 구조를 모든 측면에서 공유해야 합니다. 여러 구조가 필요한 경우 DiamondStorage 패턴을 사용해야 합니다.

내부 구조체에 더 많은 상태 변수를 추가할 의도가 없다고 확신하지 않는 한 구조체를 다른 구조체 안에 직접 넣지 마십시오. 구조체 뒤에 선언된 변수 저장소 슬롯을 덮어쓰지 않고는 업그레이드에서 내부 구조체에 새 상태 변수를 추가할 수 없습니다.

해결 방법은 "구조체"에 직접 "구조체"를 배치하는 대신 메모리 매핑된 구조에 새 상태 변수를 추가하는 것입니다. 맵의 가변 스토리지 슬롯은 다르게 계산되며 스토리지에서 연속적이지 않습니다.

배열의 크기는 구조의 크기에 영향을 받습니다. 새 상태 변수가 구조에 추가되면 해당 구조의 크기와 레이아웃이 변경됩니다.

구조가 배열의 요소로 사용되는 경우 이로 인해 문제가 발생할 수 있습니다. 구조의 크기와 레이아웃이 변경되면 배열의 크기와 레이아웃도 변경되어 구조의 일관된 크기와 레이아웃에 의존하는 인덱싱 또는 기타 작업에 문제가 발생할 수 있습니다.

다른 프록시 패턴과 마찬가지로 각 변수에는 고유한 스토리지 슬롯이 있어야 합니다. 그렇지 않으면 동일한 위치에 있는 두 개의 서로 다른 구조가 서로 덮어쓰게 됩니다.

initialize() 함수는 일반적으로 권한 있는 역할의 주소와 같은 중요한 변수를 설정하는 데 사용됩니다. 컨트랙트가 배포될 때 초기화되지 않으면 악의적인 행위자가 컨트랙트를 호출하고 제어할 수 있습니다.

초기화/설정 기능에 적절한 접근 제어를 추가하거나 컨트랙트 배포 시 해당 기능이 호출되어 다시 호출되지 않도록 하는 것이 좋습니다.

컨트랙트의 어떤 측면이 selfdestruct() 함수를 호출할 수 있는 경우 전체 컨트랙트를 파기할 가능성이 있어 자금이나 데이터가 손실될 수 있습니다. 이것은 다이아몬드 프록시 모드에서 매우 위험합니다. 여러 측면에서 프록시 계약의 스토리지 및 데이터에 액세스할 수 있기 때문입니다.