스마트 계약 개발에서 점검 효과 상호 작용 패턴을 설명하십시오

스마트 계약 개발에서 점검 효과 상호 작용 패턴을 이해합니다

Checks-Effects Interactions 패턴은 이더 리움 스마트 계약 개발에서 널리 채택 된 모범 사례입니다. 재창조 공격 및 자금 손실 또는 데이터 손실로 이어질 수있는 기타 중요한 취약점을 방지하기위한 방어 프로그래밍 전략 역할을합니다.

이 설계 패턴은 검사 , 효과 및 상호 작용의 세 가지 단계로 실행됩니다. 이 주문을 준수함으로써 개발자는 외부 통화가 이루어지기 전에 상태 변경이 발생하도록하여 악의적 인 계약 또는 실행 중 예상치 못한 행동과 관련된 위험을 최소화합니다.

Checks-Effects-Interactions 패턴의 구성 요소는 무엇입니까?

패턴의 각 부분은 계약 무결성을 유지하는 데 중요한 역할을합니다.

• 점검 :이 단계에는 논리를 진행하기 전에 모든 입력 및 조건을 검증하는 것이 포함됩니다. 유효하지 않은 상태에 대한 반대로 , 잔액 확인, 소유권 확인 및 액세스 제어 메커니즘을 존중하는 것이 포함됩니다.

• 효과 :이 단계에서 계약은 내부 상태 변수를 수정합니다. 이러한 상태 변경은 외부 상호 작용이 이루어지기 전에 완료해야합니다. 예로는 잔액 업데이트, 소유권 변경 플래그 변경 또는 토큰 수당 감소가 있습니다.

• 상호 작용 : 마지막 단계는 다른 계약에 대한 외부 호출을 하거나 에테르를 보내는 것입니다. 이러한 작업은 콜백을 유발할 수 있으므로 (예 : 폴백 함수를 통해) 착취를 피하기 위해 모든 내부 상태 업데이트 후에 발생해야합니다.

실행 순서가 중요한 이유는 무엇입니까?

스마트 계약은 종종 토큰 계약, 분산 거래소 또는 사용자 지갑과 같은 외부 엔티티와 상호 작용합니다. 계약이 자체 상태를 업데이트하기 전에 에테르를 보내거나 외부 호출을하는 경우 재창조 공격 의 창이 열립니다.

예를 들어, 에테르를 전송 한 후 사용자의 잔액을 공제하는 계약을 고려하십시오. 악성 계약은 이전의 콜백을 사용하여 원래 기능을 다시 입력하고 자금을 반복적으로 배수 할 수 있습니다. Checks-effects-interaction 패턴을 적용함으로써 계약은 먼저 적격성 ( 점검 )을 검증하고 내부 원장 ( 효과 )을 업데이트 한 다음 외부 전송 ( 상호 작용 )을 시작하여 공격 벡터를 닫습니다.

Solidity에서 Checks-Effects-interactions 패턴을 구현하는 방법

이 패턴을 올바르게 구현하려면 다음 단계를 순서대로 따르십시오.

• 수표 :

  • require 또는 revert 사용하여 입력 매개 변수를 유효성으로 유효성을 유지하십시오.
  • 발신자가 함수를 실행할 권한이 있는지 확인하십시오.
  • 필요한 잔액이나 수당이 충분한 지 확인하십시오.

• 효과 :

  • 트랜잭션과 직접 관련된 상태 변수를 업데이트하십시오.
  • 여기에서 계산 또는 외부 통화를 수행하지 마십시오.
  • 모든 상태 변경이 원자적이고 결정적인지 확인하십시오.

• 상호 작용 :

  • call , transfer 또는 send 와 같은 저수준 기능을 사용하여 외부 통화를 수행하십시오.
  • 더 나은 제어를 위해 명시적인 가스 제한으로 call 방법을 사용하는 것이 좋습니다.
  • 실패를 감지하기 위해 반품 값을 적절하게 처리합니다.

간단한 예는 다음과 같습니다.

 function withdraw(uint256 amount) public { // Checks require(balanceOf[msg.sender] >= amount, 'Insufficient balance'); // Effects balanceOf[msg.sender] -= amount; // Interactions (bool success, ) = msg.sender.call{value: amount}(''); require(success, 'Transfer failed');

}

이 코드 스 니펫 에서이 기능은 사용자가 충분한 균형 ( 점검 )을 보장하고 계정 ( 효과 )에서 금액을 공제하고 마지막으로 에테르 ( 상호 작용 )를 보냅니다.

패턴을 따르지 않을 때 일반적인 실수

점검 효과 상호 작용 패턴과의 편차는 심각한 문제로 이어질 수 있습니다.

• Reentrancy 취약성 : 상태를 업데이트하기 전에 에테르를 보내거나 외부 통화를하면 공격자가 동일한 기능을 재귀 적으로 호출 할 수 있습니다.
• 레이스 조건 : 적절한 시퀀싱이없는 외부 결과에 여러 작업이 의존하는 경우 예기치 않은 결과가 발생할 수 있습니다.
• 잘못된 상태 업데이트 : 외부 통화 후 상태 수정은 통화가 실패하면 계약을 일관되지 않은 상태로 남길 수 있습니다.

악명 높은 예는이 패턴에 대한 준수가 부족하여 수백만의 에테르를 배수 한 재귀적인 호출 익스플로잇을 가능하게하는 Dao Hack 입니다.

핵심 패턴 이외의 모범 사례

점검 효과 상호 작용 구조를 따르는 동안 추가 예방 조치가 보안을 향상시킵니다.

• 수정 자 기반 액세스 제어를 사용하여 체크를 중앙 집중화하고 중복성을 줄입니다.
• 에테르 전송에 풀오버 푸시 패턴을 적용하여 사용자에게 인출을 제어 할 수 있도록합니다.
• 복잡한 논리 또는 여러 외부 통화를 처리 할 때 비 반환 잠금 장치를 사용하십시오.
• 추가 보호 계층을 추가하려면 OpenZeppelin의 ReentrancyGuard 라이브러리를 사용하는 것을 고려하십시오.

이러한 관행은 핵심 패턴을 보완하고보다 강력하고 안전한 스마트 계약을 구축하는 데 도움이됩니다.

자주 묻는 질문 (FAQ)

Q : Ethereum 외에 다른 블록 체인 플랫폼에서 Checks-Effects-interaction 패턴을 사용할 수 있습니까? 그렇습니다.이 패턴은 재창조 공격에 대한 감수성으로 인해 이더 리움에서 시작되었지만 스마트 계약이 외부 시스템과 상호 작용하거나 외부 트리거를 기반으로 상태를 수정하는 모든 플랫폼에 광범위하게 적용됩니다.

Q : 상호 작용 단계에서 외부 호출이 실패하면 어떻게됩니까? 외부 통화가 실패하면 명시 적으로 처리되지 않는 한 트랜잭션이 되돌아갑니다. 이러한 통화를 시도 케치 메커니즘으로 랩핑하거나 반환 값을 확인하여 계속 또는 롤백 여부를 결정하는 것이 중요합니다.

Q : 점검 효과 상호 작용 패턴의 위반을 감지하는 도구가 있습니까? 예, Slither , Oyente 및 Securify 와 같은 정적 분석 도구는이 패턴과 위험한 코드 구성에서 잠재적 편차를 식별 할 수 있습니다.

Q : 단일 함수 내에서 여러 가지 효과 나 상호 작용을 가질 수 있습니까? 전적으로. 그러나 모든 효과 (상태 변경)는 상호 작용 (외부 통화) 보다 우선해야합니다. 여러 상호 작용이 필요하더라도 마지막 상태 업데이트 이후에 모두 오려야합니다.