Solidity 스마트 계약에서 상속은 어떻게 작동하나요?

Solidity의 상속: 모듈식 스마트 계약 구축

1. Solidity의 상속을 통해 하나의 계약이 다른 계약의 속성과 기능을 채택할 수 있으므로 코드 재사용과 구조화된 설계가 가능합니다. 파생 계약은 기본 계약에서 상속할 수 있으며 비공개로 표시되지 않은 상태 변수, 함수 및 수정자에 대한 액세스 권한을 얻습니다. 이 메커니즘은 논리의 계층적 구성을 지원하여 여러 계약의 중복성을 줄입니다.

2. 계약이 다른 계약에서 상속되면 상속된 동작을 확장하거나 수정할 수 있습니다. 예를 들어 하위 계약은 기본 함수의 virtual 키워드와 파생된 함수의 override 키워드를 사용하여 상위 계약의 함수를 재정의할 수 있습니다. 이를 통해 동일한 함수 시그니처의 다양한 구현이 계약 계층 전반에 걸쳐 존재할 수 있는 다형성 동작이 가능합니다.

3. Solidity에서는 다중 상속이 지원되므로 계약이 둘 이상의 상위로부터 상속될 수 있습니다. 함수 호출을 해결하기 위해 Solidity에서 사용하는 C3 선형화 알고리즘으로 인해 상속 순서가 중요합니다. 먼저 나열된 계약은 메서드 결정에서 우선 순위를 가지므로 상위에 중복되는 기능이 존재할 때 모호성을 방지하는 데 도움이 됩니다.

4. 상속된 계약의 생성자는 가장 기본 수준 계약부터 파생 계약까지 상속 순서대로 실행됩니다. 인수가 필요한 경우 각 생성자를 명시적으로 호출해야 상속 트리의 모든 수준에서 상태 변수가 적절하게 초기화됩니다.

5. 가시성은 상속에서 중요한 역할을 합니다. 공개 및 내부 기능은 파생 계약을 통해 액세스할 수 있는 반면 비공개 기능은 정의 계약에만 국한됩니다. 내부 함수는 재정의할 수 있어 사용자 정의에 유연성을 제공하는 반면, 외부 함수는 계약 컨텍스트 외부에서만 호출할 수 있으므로 재정의할 수 없습니다.

함수 재정의 및 가상 메서드

1. 파생 계약에서 함수를 재정의하려면 기본 계약에서 해당 함수를 가상 으로 선언해야 합니다. 이는 해당 기능의 구현이 하위 계약에서 대체될 수 있음을 나타냅니다. 이 키워드가 없으면 함수는 하위 클래스에서 고정되고 변경 불가능한 상태로 유지됩니다.

2. 재정의 계약은 가상 기능을 재정의할 때 override 키워드를 사용해야 합니다. 이는 명시적인 의도를 적용하고 우발적인 재정의를 방지합니다. 함수가 재정의를 선언하지 않고 재정의를 시도하면 컴파일러에서 오류가 발생합니다.

3. 재정의할 때 이름, 매개변수, 반환 유형을 포함한 함수 서명이 원본과 정확히 일치해야 합니다. 가시성(공개, 내부)과 같은 수정자도 호환되어야 하지만 더 엄격한 가시성(예: 공개에서 내부로 축소)은 허용되지 않습니다.

4. super 를 사용하여 재정의된 함수의 상위 버전을 호출하는 것이 가능합니다. 이 키워드는 상속 계층 구조를 통해 호출을 라우팅하여 함수의 다음으로 가장 가까운 구현을 호출합니다. 또는 BaseContractName.functionName() 구문을 통해 특정 조상의 메서드를 직접 호출할 수 있습니다.

5. 수정자 재정의는 유사한 규칙을 따릅니다. 수정자는 가상으로 선언된 다음 파생 계약에서 재정의될 수 있습니다. 이를 통해 함수에 적용되는 사전 또는 사후 조건을 변경하고 컨텍스트에 따라 액세스 제어 또는 실행 논리를 조정할 수 있습니다.

추상 계약 및 인터페이스

1. 추상 계약은 구현 없이 하나 이상의 기능을 포함하는 불완전한 계약입니다. 이는 abstract 키워드를 사용하여 선언되며 다른 계약을 구축할 수 있는 템플릿 역할을 합니다. 추상 계약에서 상속되는 모든 계약은 구현되지 않은 모든 기능을 구현하거나 그 자체를 추상으로 표시해야 합니다.

2. 본문이 없는 추상 계약 내의 기능은 자동으로 추상으로 간주되며 추상이 아닌 하위 항목에 의해 구현되어야 합니다. 이러한 함수는 하위 항목이 준수해야 하는 필수 인터페이스를 정의하여 구현 전반에 걸쳐 일관성을 보장합니다.

3. 인터페이스는 함수 선언(본문 없음), 이벤트 및 구조체만 포함하도록 계약을 제한하여 추상화를 더욱 강화합니다. 인터페이스의 모든 함수는 암시적으로 외부 함수이며 상태 변수를 가질 수 없습니다. 계약은 모든 기능에 대한 구체적인 정의를 제공하여 인터페이스를 구현합니다.

4. 단일 계약은 ERC-20, ERC-721 또는 사용자 정의 프로토콜 사양과 같은 다양한 표준화된 동작을 결합하여 여러 인터페이스를 구현할 수 있습니다. 이는 이더리움 생태계에서 널리 받아들여지는 표준에 대한 상호 운용성과 준수를 촉진합니다.

5. 인터페이스는 생성자를 포함하거나 일반 계약에서 상속할 수 없으므로 재사용 가능한 비즈니스 논리를 캡슐화하기보다는 계약 간의 통신 경계를 정의하는 데 가장 적합합니다. 불변성으로 인해 계약 간 상호 작용 보장에 이상적입니다.

일반적인 함정과 모범 사례

1. 다중 상속 중 상위 계약의 순서가 잘못되면 C3 선형화 규칙으로 인해 예상치 못한 동작이 발생할 수 있습니다. 개발자는 올바른 메서드 해결을 보장하고 자동 버그를 방지하기 위해 우선순위가 낮은 순서로 기본 계약을 나열해야 합니다.

2. 깊은 상속 트리를 과도하게 사용하면 가독성이 떨어지고 배포 비용이 증가할 수 있습니다. 집중적이고 단일 목적의 계약을 갖춘 평면형 구조는 종종 복잡한 계층 구조보다 유지 관리가 용이하고 가스 효율성이 더 높은 것으로 입증됩니다.

3. 재정의 가능한 기능을 가상 으로 표시하지 못하면 하위 계약의 확장이 방지되어 유연성이 제한됩니다. 반대로, 필요 없이 너무 많은 기능을 가상으로 표시하면 의도하지 않은 수정 지점이 노출되어 잠재적으로 보안이 손상될 수 있습니다.

4. 상속된 체인의 생성자 인수 불일치로 인해 컴파일 오류가 발생합니다. 상속 경로의 각 생성자는 계약 인스턴스화 중에 명시적으로 전달된 적절한 수와 유형의 인수를 받아야 합니다.

5. 코드 재사용을 위해 상속에만 의존하면 라이브러리나 구성성 패턴과 같은 대안을 간과할 수 있습니다. 지시문이나 대리인 호출 에 using 을 사용하면 특정 시나리오에서 더 안전하고 모듈화된 솔루션을 제공할 수 있습니다.

자주 묻는 질문

두 개의 상위 계약이 동일한 이름의 함수를 정의하면 어떻게 되나요? Solidity에서는 이러한 충돌을 하위 계약에서 명시적으로 해결해야 합니다. 개발자는 일반적으로 상위 또는 직접 한정을 통해 상위 버전 중 하나를 호출하여 함수를 재정의하고 모호성을 처리하는 방법을 결정해야 합니다.

계약이 일반 계약과 인터페이스 모두에서 상속될 수 있나요? 예. 계약은 구체적인 계약, 추상 계약 및 인터페이스의 혼합을 포함하여 여러 소스에서 상속할 수 있습니다. 구현해야 하는 함수 시그니처만 제공하는 인터페이스와 동일한 상속 규칙이 적용됩니다.

계약상속을 막을 수 있나요? Solidity는 상속을 차단하기 위해 'final'과 같은 내장 키워드를 제공하지 않습니다. 그러나 개발자는 개인 생성자를 사용하여 계약을 설계하거나 상속을 비실용적이거나 비효율적으로 만드는 방식으로 기능을 제한할 수 있습니다.

상속은 배포 중 가스 비용에 어떤 영향을 미치나요? 상속된 코드는 결과 계약의 바이트코드 크기를 증가시키며 이는 배포 비용에 직접적인 영향을 미칩니다. 외부 라이브러리를 사용하지 않는 한 기본 계약의 함수는 최종 바이트코드에 복사되므로 대규모 상속 트리를 배포하는 데 더 많은 비용이 듭니다.