Web3 스마트 계약 보안을 위한 테스트 및 정식 검증

Web3 스마트 계약 보안을 위한 테스트 및 정식 검증

타임 스탬프 : 16 년 2023 월 4 일 오전 10:XNUMX
Web3 스마트 계약 보안 PlatoBlockchain 데이터 인텔리전스에 대한 테스트 및 공식 검증. 수직 검색. 일체 포함.

읽기 시간: 9 분

스카이다이빙을 한다고 상상해보세요. 비행기에서 뛰어내리기 전에 낙하산이 있는지 백 번은 확인하겠죠? 확인 및 테스트는 보안의 필수적인 부분입니다. 보안과 관련된 모든 것을 생각해 보십시오. 그 이후에는 CCTV를 설치하거나 학교에서 필기시험을 하기 전에 펜의 잉크를 확인하는 등의 테스트 메커니즘이 있을 것입니다. 우리 모두는 안전 조치를 따릅니다. 관련된 위험이 높을수록 더 많은 것을 테스트합니다. 스마트 계약에 대해 이야기할 때 위험은 엄청납니다. 스마트 계약 보안에 관해서는 부주의할 수 없습니다.

1. 보안은 항상 필요합니다.

문을 두 번 잠글 수도 있고 세 번 잠글 수도 있습니다. 당신이 없는 동안 집에 도둑이 들지 않는다고 확신할 수 있습니까? 강도가 집에 침입하기 위해 무엇을 할지 모르기 때문에 할 수 없습니다. 우리가 취하는 모든 안전 조치에 대해서도 마찬가지입니다. 안전을 보장하는 완전히 안전한 방법은 없습니다. 그럼에도 불구하고 우리가 취하는 조치는 안전할 가능성을 빠르게 증가시킵니다. 이것이 바로 게임입니다. 우리는 다양한 조치를 취함으로써 안전할 확률을 높이고자 합니다.

Web3의 세계도 다르지 않습니다. 자신을 구할 수 있는 안전한 방법은 없지만 QuillAudits의 경험이 풍부한 감사자를 보유하면 프로토콜 보안 가능성을 크게 높이고 최신 보안을 보장할 수 있습니다. web3에는 프로토콜에 대한 몇 가지 테스트를 수행하여 얼마나 안전한지 이해하는 데 도움이 되는 두 가지 중요한 메커니즘이 있습니다.

  1. 스마트 계약 테스트
  2. 스마트 계약의 공식 검증

그것들을 자세히 이해하고 그것들이 우리 계약의 약점이나 취약점을 아는 데 어떻게 도움이 되는지 알아봅시다.

2. 스마트 계약 테스트

숙련된 개발자는 코드로 기계에 작업을 설명할 수 있습니다. 그럼에도 불구하고 때로는 코드의 결함이나 논리적 오류로 인해 개발자가 염두에 둔 정확한 메커니즘을 기계가 묘사하지 못하는 경우가 있습니다. 테스팅은 우리의 코드가 어디에서 실패하고 우리가 수행해야 하는 행동에 상응하도록 하기 위해 무엇을 할 수 있는지 식별하는 데 도움이 되는 프로세스입니다.

스마트 계약 테스트 계약에 대한 자세한 분석을 수행하고 코드가 어디에서 왜 실패하는지 알아내려고 노력하는 개발 주기의 한 단계입니다. 거의 모든 스마트 계약이 이 단계를 거칩니다. 스마트 계약 테스트에는 두 가지 방법이 있습니다. 그들을 탐구하자.

2.1 자동화

이름에서 알 수 있듯이 이 스마트 계약 테스트 방법은 스크립트 테스트를 수행하는 데 사용됩니다. 여기에는 스마트 계약의 취약성과 결함을 찾기 위해 반복 테스트를 실행하는 자동화된 소프트웨어가 포함됩니다. 이러한 자동화된 테스트 도구는 테스트 데이터 및 예상 결과로 구성할 수 있습니다. 그런 다음 실제 결과를 예상 결과와 비교하여 계약이 제대로 작동하는지 확인합니다. 자동 테스트는 세 가지 범주로 더 분류할 수 있습니다.

2.1.1. 기능 테스트

두 개의 숫자 a와 b를 취한 다음 두 숫자를 더한 값을 반환하는 프로그램을 작성한다고 가정합니다. 따라서 해당 프로그램을 확인하려면 2와 8을 제공하고 예상 결과를 10으로 입력합니다. 이제 프로그램이 실행될 때 10도 반환해야 합니다. 그렇다면 제대로 작동하고 코드가 정확하지만 그렇지 않으면 우리 코드에 약간의 오류가 있습니다. 

기능 테스트를 위해서는 특정 조건에서 계약이 어떻게 작동해야 하는지 이해해야 합니다. 선택한 값으로 계산을 실행하고 반환된 출력을 비교하여 테스트할 수 있습니다. 기능 테스트에는 세 가지 클래스가 있습니다.

  1. 단위 테스트:- 이것은 정확성을 위해 스마트 계약의 개별 구성 요소를 테스트하는 것을 다룹니다. 독단적이거나 변수에 대한 진술이 필요합니다.
  1. 통합 테스트응: – 이들은 여러 개별 구성 요소를 함께 테스트합니다. 통합 테스트는 단위 테스트보다 계층 구조에서 더 높은 수준입니다. 이는 다른 스마트 계약의 일부일 수 있는 다양한 기능의 상호 작용으로 인해 발생하는 오류를 판단하는 데 도움이 됩니다.
  1. 교과서응: – 이것은 계층 구조에서 가장 높습니다. 여기에서 우리는 전체 계약을 하나의 완전히 통합된 시스템으로 테스트하여 필요에 따라 수행되는지 확인합니다. 사용자의 관점에서 이루어지며 이를 수행하는 가장 좋은 방법은 테스트넷에 배포하는 것입니다.

2.1.2. 정적 분석

정적 분석은 프로그램을 실행하지 않고도 수행할 수 있습니다. 실행 전에 스마트 계약의 소스 코드 또는 바이트 코드 분석이 포함됩니다. 따라서 정적 분석이라는 이름을 부여하면 몇 가지 일반적인 취약점을 탐지할 수 있습니다.

2.1.3. 동적 분석

정적 분석과 달리 동적 분석은 코드의 문제를 식별하기 위해 스마트 계약이 실행되는 동안 수행됩니다. 동적 코드 분석기는 계약의 실행 상태를 관찰하고 취약성 및 속성 위반에 대한 자세한 보고서를 생성합니다. 퍼징은 DYnamic 분석에 속합니다. 퍼징은 의도하지 않은 코드 실행을 유발하기 위해 부정확하거나 악의적인 입력을 제공하는 것입니다.

2.2 매뉴얼

이름에서 알 수 있듯이 이 스마트 계약 테스트 방법에는 인간 개발자와의 정기적인 상호 작용이 포함됩니다. 개발자가 코드 라인을 검토하는 코드 감사는 스마트 계약 테스트의 수동 모드에 속합니다.

수동 모드에는 상당한 시간, 기술, 비용 및 노력이 필요합니다. 그럼에도 불구하고 자동 테스트에서 발견되지 않을 수 있는 취약점을 식별하기 때문에 결과는 가치가 있는 경우가 많습니다. 수동 테스트에는 두 가지 필수 유형이 있습니다.

2.2.1 코드 감사:- 

안전 조치가 제대로 작동하는지 테스트하는 가장 좋은 방법은 안전 조치를 깨는 것입니다. 예를 들어 자동차 자물쇠가 제대로 작동하는지 확인하고 싶다면 부수어 보세요. 이제 당신은 숙련된 자동차 도둑이 내 차에 쉽게 침입할 수 있다고 요청할 수 있습니다. 그렇지 않을 수도 있으므로 해결책은 침입에 능숙한 사람을 고용하여 그가 당신을 안내할 수 있도록 하는 것입니다!

 예, QuillAudits에 대해 이야기하고 있습니다. 우리는 귀하를 안내할 수 있는 숙련된 감사팀입니다. 코드 감사에는 소스 코드에서 가능한 모든 취약점을 찾는 공격자 사고 방식이 필요합니다. 코드 감사는 잠재적인 취약성과 결함을 발견하기 위한 스마트 계약의 코드에 대한 자세한 평가입니다.

2.2.2 버그 바운티:-

소스 코드에 몇 가지 보안 결함이 있다고 생각하고(대부분이 그렇습니다) 찾을 수 없는 경우 보상 시스템을 만들어 이 작업을 프리랜서에게 아웃소싱할 수 있습니다. 스마트 계약을 해킹할 수 있는 사람에게 보상을 발표하는 것과 비슷합니다. 이를 통해 스마트 계약에 존재하는 취약성에 대해 학습하여 이를 더 잘 보호하고 사용자를 손실로부터 보호할 수 있습니다.

3. 스마트 계약의 정식 검증

공식 검증은 공식 사양을 기반으로 계약의 정확성을 평가하는 프로세스입니다. 즉, 공식 검증은 코드가 의도한 바를 수행하는지 평가합니다. 공식 검증은 프로그램을 지정, 설계 및 검증하기 위한 공식 방법을 사용합니다.

3.1 공식 사양이란 무엇입니까?

스마트 계약의 맥락에서 공식 사양은 가능한 모든 상황에서 동일하게 유지되어야 하는 속성을 나타냅니다. 이들은 계약 실행에 대한 논리적 어설션을 변경할 수 없고 나타낼 수 없기 때문에 "불변" 속성입니다.

공식 사양은 공식 언어로 작성된 진술 모음입니다. 사양은 다양한 속성을 다루고 계약 속성이 다른 상황에서 어떻게 작동해야 하는지 설명합니다. 계약서에 불변 변수가 없거나 실행 중에 속성이 변경되는 경우 속성 악용으로 이어져 막대한 손실이 발생할 수 있기 때문에 정식 사양이 중요합니다.

스마트 계약이 사양을 충족하는지 또는 예기치 않은 동작이 있는지 판단하는 데 도움이 될 수 있습니다. 형식 검증에는 사양, 모델 및 검증 엔진의 세 가지 구성 요소가 있습니다.

3.1.1 사양

사양은 스마트 계약의 요구 사항에 대한 명확하고 명확하며 완전한 설명입니다. 계약에서 해야 할 일과 하지 말아야 할 일을 설명해야 합니다. 다음은 두 개의 숫자를 추가하는 간단한 스마트 계약의 예시 사양입니다.

// Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
// Implementation details are not relevant to the specification
// …
}

3.1.2 모델

모델은 행동을 추론하는 데 사용할 수 있는 스마트 계약을 공식적으로 나타냅니다. 스마트 계약의 인기 있는 모델 중 하나는 Solidity 프로그래밍 언어입니다. 다음은 위에서 설명한 추가 기능에 대한 예제 모델입니다.

// Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
return a + b;
}

3.1.3 검증 엔진

검증 엔진은 모델을 분석하고 주어진 사양에 대한 정확성을 검증할 수 있는 도구입니다. 다음을 포함하여 스마트 계약에 사용할 수 있는 여러 검증 엔진이 있습니다.

미스릴: Solidity 스마트 계약에서 광범위한 보안 취약성을 감지할 수 있는 오픈 소스 기호 실행 도구입니다.

리믹스 IDE: 스마트 계약의 정확성을 검증할 수 있는 정식 검증 도구를 포함하는 통합 개발 환경.

Certora 증명: 자동화된 수학적 추론을 사용하여 스마트 계약의 정확성을 확인할 수 있는 상용 도구입니다. 다음은 Certora Prover를 사용하여 스마트 계약의 정확성을 확인하기 위해 공식 검증을 사용하는 방법의 예입니다.

pragma solidity 0.7.6; // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint)
function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function test_add(uint a, uint b) public pure returns (bool) {
uint expected = a + b;
uint actual = add(a, b);
return expected == actual;
} // Verification: Verify the correctness of the add function contract TestAdd {
function test_add(uint a, uint b) public view returns (bool) {
return CertoraProver.verify(test_add, a, b);
}
}

위의 예에서 우리는 추가 기능의 모델, 기능에 대한 사양 및 기능의 정확성을 확인할 수 있는 검증 엔진(Certora Prover)을 포함하는 Solidity 스마트 계약을 정의합니다. 또한 함수의 정확성을 확인하는 데 사용할 수 있는 테스트 함수(test_add)를 정의합니다.

3.2 테스팅 VS 정식 검증

논의한 바와 같이 테스트는 테스트되지 않은 데이터에 대해 말할 수 없기 때문에 부족한 일부 입력 데이터 봇에 대한 예상 결과를 반환합니다. 가능한 모든 입력에 대해 확인하는 것은 사실상 불가능합니다. 따라서 "기능적 정확성"에 대해 확신할 수 없습니다. 공식 검증이 필요한 곳입니다. 공식 검증 방법은 소프트웨어 또는 스마트 계약을 지정하고 검증하기 위해 엄격한 수학적 기법을 사용합니다.

3.3 공식 검증 기법

형식적 검증은 향상을 위한 광범위한 기술을 가지고 있습니다. 스마트 계약 보안. 블로그의 이 부분에서는 몇 가지를 개별적으로 살펴보겠습니다.

3.3.1 모델 확인

공식 사양이 무엇인지 논의하면서 이 공식 검증 기술에서 사양과 스마트 계약을 확인합니다. 이러한 스마트 계약은 상태 전환 시스템으로 표현되며 속성은 시간 논리를 사용하여 정의됩니다. 

이 기술은 주로 시간 경과에 따른 스마트 계약의 동작을 나타내는 임시 속성을 평가하는 데 사용됩니다. 액세스 제어 속성(관리자 호출 자폭) 형식 논리로 쓸 수 있습니다. 그런 다음 모델 확인 알고리즘은 계약이 이 공식 확인을 충족하는지 확인할 수 있습니다.

모델 검사는 기본적으로 스마트 계약이 있을 수 있는 모든 가능한 상태를 시도한 다음 속성 위반이 발생하는지 확인하는 상태 공간 탐색이라는 기술을 사용합니다. 그러나 이것은 무한히 많은 상태로 이어질 수 있습니다. 따라서 모델 검사기는 스마트 계약의 효율적인 분석을 가능하게 하는 추상화 기술에 의존합니다.

3.3.2 정리 증명

정리 증명은 프로그램의 정확성에 대한 수학적 추론에 관한 것입니다. 계약의 시스템 및 사양에 대한 논리적 인상을 만들고 진술 간의 "논리적 등가성"을 확인하는 작업을 다룹니다. 논리적 동등성은 진술 B가 참인 경우에만 진술 A가 참이라고 말하는 수학적 관계입니다.

모델 확인 기술에서 배운 것처럼 계약을 유한 상태의 전환 시스템으로 모델링합니다. 정리 증명은 무한 상태 시스템의 분석을 처리할 수 있습니다. 그러나 자동화된 정리 증명기는 논리적 문제가 결정 가능한지 여부를 항상 알 수는 없습니다. 따라서 정리 증명자가 정확성 증명을 도출하도록 안내하기 위해 종종 사람의 도움이 필요합니다.

4. 결론

테스트 및 공식 검증은 모두 스마트 계약 개발의 필수 부분입니다. 스마트 계약을 안전하게 만들고 계약을 배포할 수 있도록 돕는 데 사용되는 방법입니다. 그러나 아시다시피 보안은 결코 충분하지 않습니다. 적절한 테스트가 없었기 때문에 많은 스마트 계약이 해킹당했습니다. 이제 그 어느 때보다 web3 커뮤니티에 더 안전한 프로토콜이 필요합니다. 

QuillAudits는 귀하의 프로토콜을 보호하는 임무를 수행하고 있습니다. 숙련되고 경험이 풍부한 팀과 함께 단 하나의 취약점도 발견되지 않도록 합니다. 웹사이트를 방문하여 Web3 프로젝트를 확보하십시오!

28 조회수

타임 스탬프 :

더보기 퀼해시