스마트 계약 보안 모범 사례

현명한 계약 취약점 이해

스마트 계약은 코드에 직접 작성된 이용 약관과 자체 실행 계약입니다. 이더 리움과 같은 블록 체인 네트워크에서 작동하기 때문에 코드의 모든 취약점은 돌이킬 수없는 재무 손실로 이어질 수 있습니다. 가장 악명 높은 사례 중 하나는 Dao Hack 입니다. 여기서 재귀 콜 취약성으로 공격자는 수백만 달러 상당의 에테르를 배출 할 수있었습니다. 재창조, 정수 오버플로/언더 플로 및 부적절한 액세스 제어와 같은 일반적인 취약점을 이해하는 것은 안전한 스마트 계약을 작성하는 개발자에게는 중요합니다.

코드 감사 및 공식 확인

현명한 계약 보안을 보장하는 가장 효과적인 방법 중 하나는 엄격한 코드 감사를 통한 것입니다. 여기에는 경험이 풍부한 개발자 또는 타사 보안 회사가 잠재적 인 결함에 대한 계약의 소스 코드를 검토하는 것이 포함됩니다. Slither 및 Oyente 와 같은 도구는 알려진 취약점을 자동으로 감지 할 수 있습니다. 공식적인 검증은 더 복잡하지만 계약이 사양을 준수한다는 것을 수학적으로 증명합니다. 이 방법은 종종 실패가 옵션이 아닌 고분비 환경에서 사용됩니다.

• 정적 분석 도구를 사용하여 취약성을 감지하십시오
• 숙련 된 개발자와 동료 리뷰를 수행합니다
• 미션 크리티컬 계약에 공식적인 검증 기술을 사용하십시오

테스트 및 시뮬레이션 환경

메인 넷에 스마트 계약을 배포하기 전에 시뮬레이션 환경에서 광범위한 테스트가 필수적입니다. Ropsten 또는 Goerli와 같은 테스트 넷을 통해 개발자는 실제 자금을 위험에 빠뜨리지 않고 실제 상호 작용을 시뮬레이션 할 수 있습니다. 개발자는 또한 단위 테스트 및 퍼지 테스트를 사용하여 에지 케이스 및 예기치 않은 입력을 덮어야합니다.

• Mainnet 이전의 TestNets에 계약을 배치합니다
• 단위 테스트를 사용하여 개별 기능을 확인하십시오
• 숨겨진 버그를 발견하려면 퍼즈 테스트를 적용하십시오

업그레이드 및 비상 통제

불변성은 블록 체인의 핵심 특징이지만 보안 결함이 배치 후 발견되면 단점이 될 수 있습니다. 프록시 패턴을 사용한 업그레이드 가능한 스마트 계약을 통해 개발자는 전체 계약을 재배치하지 않고 버그 또는 패치 취약점을 수정할 수 있습니다. 그러나 이것은 제대로 관리되지 않으면 중앙 집중화의 위험을 도입합니다. 비상 정지 메커니즘 (킬 스위치)을 구현하면 활발한 악용의 경우 계약 운영을 중단 할 수 있습니다.

• 업그레이드 가능성을 위해 프록시 계약을 사용하십시오
• 비상 시나리오에 대한 일시 정지 기능을 구현하십시오
• 거버넌스 메커니즘이 업그레이드 가능성의 오용을 방지하십시오

안전한 개발 관행

보안 스마트 계약 작성은 개발 단계에서 모범 사례를 채택하는 것으로 시작됩니다. 개발자는 Consensys 또는 Ethereum Community가 요약 한 것과 같은 안전한 코딩 표준을 따라야합니다. 인라인 어셈블리 및 확인되지 않은 수학 작업과 같은 위험한 패턴을 피하는 것이 필수적입니다. 또한 외부 통화를 제한 하고 올바른 오류 처리를 보장하면 예기치 않은 동작을 방지 할 수 있습니다.

• 신뢰할 수있는 출처의 안전한 코딩 가이드 라인을 따르십시오
• 확인되지 않은 산술 작업을 피하십시오
• 외부 계약에 대한 의존도를 최소화합니다

종속성 관리 및 외부 라이브러리

스마트 계약은 종종 외부 라이브러리 또는 종속성에 의존하여 토큰 표준 또는 수학 작업과 같은 일반적인 기능을 구현합니다. 그러나 구식이거나 신뢰할 수없는 라이브러리를 사용하면 숨겨진 취약점을 소개 할 수 있습니다. 개발자는 항상 오픈 제프 펠린 또는 DAPPSYS 와 같은 잘 알려진 널리 채택 된 라이브러리를 사용해야합니다. 의도하지 않은 업데이트를 방지하기 위해 종속성 버전을 잠그는 것도 중요합니다.

• 잘 알려진 오픈 소스 라이브러리를 사용하십시오
• 패키지 관리자의 종속성 버전을 잠그십시오
• 패치 버전에 의존성을 정기적으로 업데이트합니다

액세스 제어 및 역할 기반 권한

부적절한 액세스 제어는 스마트 계약에서 일반적인 보안 위반의 원천입니다. 개발자는 RBAC (역할 기반 액세스 제어) 시스템을 구현하여 중요한 기능을 승인 된 주소로만 제한해야합니다. 관리 조치를 위해 다중 서명 지갑을 사용하면 민감한 운영을 실행하기 전에 합의를 요구함으로써 보안을 더욱 향상시킬 수 있습니다.

• 역할과 권한을 명확하게 정의하십시오
• 관리 기능에는 멀티 시그 지갑을 사용하십시오
• 하드 코딩 된 특권 주소를 피하십시오

자주 묻는 질문

스마트 계약에서 가장 일반적인 취약점은 무엇입니까? 가장 일반적인 취약점은 Reentrancy 이며, 여기서 악성 계약은 초기 기능이 완료되기 전에 현재 계약으로 다시 전화하여 자금이 소진됩니다.

스마트 계약이 감사되었는지 어떻게 확인할 수 있습니까? Etherscan 과 같은 블록 체인 탐험가에서 계약의 배포 주소를 확인하고 Certik , Trail of Bits 또는 OpenZeppelin 과 같은 평판이 좋은 회사가 게시 한 감사 보고서를 찾을 수 있습니다.

타사 스마트 계약 템플릿을 사용하는 것이 안전합니까? OpenZeppelin 과 같은 신뢰할 수 있고 감사 된 소스의 템플릿을 사용하는 것은 일반적으로 안전하지만 개발자는 여전히 코드를 검토하고 특정 사용 사례 및 보안 요구 사항에 맞게 조정해야합니다.

배치 된 계약에서 취약성을 찾으면 어떻게해야합니까? 취약성을 발견하면 계약자 또는 팀에 즉시 문의하십시오. 계약이 오픈 소스 인 경우 책임있는 공개 또는 풀 요청을 제출하십시오. 활발한 착취의 경우 적절한 채널을 통해 커뮤니티에 경고하는 것을 고려하십시오.