블록체인 기반 프로젝트가 달성하고자 하는 주요 목표 중 하나는 데이터 검증입니다. 실제 예를 들어 디지털 ID와 온라인 문서 저장 및 수표를 볼 수 있습니다. 실제로 이러한 경우에는 개인 또는 법인을 확인하기 위해 조치/거래 개시자 확인이 필요합니다. 예를 들어, 디지털 형태의 신분증을 소지한 사람의 경우 소유권을 확인하는 것이 중요합니다. 따라서 데이터 검증 가능성 문제의 훌륭한 예입니다. 가장 단순한 형태의 솔루션인 디지털 서명을 검토해 보겠습니다. 디지털 서명의 테스트는 스마트 계약 개발 중 중요한 포인트 중 하나입니다.
접근 방식은 간단합니다.
1) 시스템은 모두에게 알려진 규칙에 따라 메시지를 생성합니다.
2) 서명자는 메시지를 받고 특정 기호 세트를 추가합니다. 디지털 서명, 개인 키로 메시지에서 구성된 코드
3) 생성된 서명은 이제 계약으로 보내지며 서명자의 주소를 검색하기 위해 분해됩니다.
Solidity는 서명 생성 및 추가 분해를 위한 ECDSA 알고리즘을 제공합니다. 알고리즘 자체에 대해 자세히 알아볼 필요는 없습니다(필요한 정보는 적절한 소스에서). 우리가 알아야 할 것은 ECDSA가 비대칭 암호화의 한 예라는 것입니다. 여기서 첫 번째 사용자는 개인 키로 서명을 만들고 두 번째 사용자는 표준 알고리즘을 적용하여 서명자의 공개 키를 검색합니다. 따라서 서명의 출처를 확인할 수 있습니다. 대신 서명 사용 및 테스트와 같은 실용적인 부분에 집중하겠습니다.
우선 문제를 인식해야 합니다. 예를 들어, 계약은 호출자의 주소를 저장하는 작업을 수행해야 합니다. 컨트랙트는 발신자가 확인된 경우에만 저장을 수행해야 하지만, 누구도 허락 없이 주소를 사용할 수 없도록 해야 합니다. 실제 호출자를 검색하려면 메시지를 생성하고 서명한 다음 계약 내에서 분해해야 합니다.
당신을 찾을 수 있습니다 Solidity 문서의 표준 솔루션 (예 : 0.8.4에서 — 기사 시점의 최신 안정 버전). 문서는 메시지 생성, 서명 분할 및 서명자를 검색하기 위한 어셈블리 코드와 같은 기본 제공 기능이 필요한 계약을 제공합니다. 이 예는 필요한 모든 방법을 보여주고 매우 간단하지만 두 가지 단점이 있습니다. 보편성이 부족하고 솔루션 테스트의 좋은 예가 없습니다. 이것이 내가 내 버전의 코드와 (실제 목표) - 계약의 테스트 전략을 제공하는 이유입니다.
물론, 당신은 사용할 수 있습니다 표준 OpenZeppelin 라이브러리 ECDSA 작업의 경우 유연성 부족과 테스트 접근 방식이라는 동일한 문제에 다시 직면하게 됩니다. 이제 서명 기반 논리의 예를 살펴보겠습니다. 당신은 완전한 내 GitHub의 작업 예제하지만 온전히 보여주고 싶은 곳이 몇 군데 없다.
먼저 메시지를 준비하겠습니다. 보시다시피 두 개의 압축 및 해시된 지갑 주소로 구성됩니다.
두 번째 중요한 코드는 표준 이더리움 메시지와 함께 메시지를 해시하는 것입니다.
메시지가 이더리움 네트워크 내에서 전송되었음을 보여주며 난수가 아닌 32바이트 길이를 가지고 있습니다. 이전 작업 후에 길이가 32바이트인 해시가 있습니다. 이러한 형태로 추가적인 해싱 기능을 갖는 것은 필수적이며, 그 이유는 잠시 후에 다루도록 하겠습니다.
다른 코드 조각은 꽤 표준적입니다. 서명을 분할하는 기능은 다음과 같습니다.
서명자를 검색하는 함수는 다음과 같습니다.
외부 인터페이스의 경우 서명과 필요한 인수를 수신하고 사용자가 이미 등록되어 있는지 확인하고 메시지를 구성하고 서명을 확인하는 사용자 지정 함수를 사용합니다.
먼저 서명해야 하는 메시지를 모방합니다. 우리는 사용할 것입니다 ethers.js (함께 web3) 가장 많이 사용하고 편리한 라이브러리입니다. 오픈 소스 라이브러리이므로 자유롭게 탐색할 수 있습니다. 코드와 문서. 또한 이 라이브러리는 다음 메시지를 구성하기 위한 완벽한 인터페이스를 제공합니다.
둘의 단점 중 하나는 web3 및 에테르 라이브러리는 두 라이브러리 모두 전체 Ethererum 노드와 함께 작동하는 것을 목표로 하기 때문에 로컬 Ganache 환경에 대한 모든 기능을 가지고 있지 않다는 것입니다. 그럼에도 불구하고, 다음을 사용하여 로컬 테스트를 위한 접근 방식이 있습니다. web3 계정 기능. 가수 기능을 구현하고 현재 web3 공급자에 대한 연결을 제공하는 추가 계정을 만들어야 하지만:
이제 메시지가 생성되고 서명되었습니다. 그러나 그것이 전부는 아닙니다. 몇 가지 이야기할 것이 남아 있습니다. 두 라이브러리(web3 및 ethers)는 서명 생성 전에 메시지에 대한 추가 해싱을 제공합니다. 또한 메시지는 해시될 뿐만 아니라 앞에서 본 표준 Ethereum 메시지와 결합됩니다.
그래서 우리는 계약에 추가 방법을 추가했습니다. 따라서 사용자 지정 메시지를 사용하려면 추가 해싱 등을 건너뛰고 서명 기능의 사용자 지정 버전을 만들어야 합니다. 위에서 이유를 논의했습니다. 두 표준 라이브러리 모두 기능을 재정의해야만 변경할 수 있는 메시지 서명에 대한 일반적인 접근 방식을 구현합니다.
마지막 단계로 테스트를 실행하고 올바르게 작동하는지 확인합니다.
서명 생성, 생성된 메시지, 서명 승인 및 거부를 테스트했습니다. 따라서 검증 기능에 대한 꽤 완전한 테스트 세트입니다.