KR20220012346A - 해시 기반 검증을 위한 실행 가능한 코드를 포함하는 블록체인 트랜잭션 - Google Patents

Abstract

블록체인 네트워크의 노드에서: ECDSA 서명의 r-부분의 기준 인스턴스를 지정하는 실행 가능한 코드를 포함하는 제1 트랜잭션을 획득하는 것; 적어도 ECDSA 서명의 s-부분을 포함하는 정보를 포함하는 제2 트랜잭션을 수신하는 것, 및 공개 키를 획득하는 것-ECDSA 서명은 대응하는 제1 개인 키에 기초하여 메시지에 서명함; 및 제1 트랜잭션으로부터 코드를 실행하는 것을 포함하며, 코드는 제1 개인 키로 누구의 개인 키가 사용되었는지에 무관하게: 제2 트랜잭션 내에서 수신된 메시지 및 획득된 제1 공개 키가 주어지면, ECDSA 서명에 적용된, ECDSA 검증 함수가 제2 트랜잭션 내에서 수신된 s-부분이 제1 트랜잭션에 의해 지정된 r-부분의 기준 인스턴스에 대응하는 것을 검증하는 조건에서 참의 결과를 반환하도록 구성되는 방법.

Description

해시 기반 검증을 위한 실행 가능한 코드를 포함하는 블록체인 트랜잭션

본 개시는 블록체인에 기록하기 위한 트랜잭션 집합을 통해 구현될 수 있는, 지식 증명(knowledge proof)의 형태에 관한 것이다.

블록체인은 분산 데이터 구조의 일 형태를 지칭하며, 여기에서 블록체인의 복제본이 피어-투-피어(Peer-to-Peer; P2P) 네트워크의 복수의 노드의 각각에서 유지된다. 블록체인은 데이터 블록의 체인을 포함하며, 각 블록은 하나 이상의 트랜잭션을 포함한다. 각 트랜잭션은 시퀀스 내에서 선행 트랜잭션을 뒤로 가리킬 수 있다. 트랜잭션은 새로운 블록에 포함되도록 네트워크에 제출될 수 있다. 새로운 블록은 "채굴"로 알려진 프로세스에 의해 생성되며, 이는 복수의 채굴 노드 각각이 "작업 증명", 즉 블록에 포함되기를 기다리는 보류 중인 트랜잭션 풀에 기초하여 암호화 퍼즐 해결을 수행하기 위해 경쟁하는 것을 수반한다.

일반적으로 블록체인의 트랜잭션은 디지털 자산, 즉 가치 저장소 역할을 하는 데이터를 전달하는 데 사용된다. 그러나, 블록체인 위에 추가적인 기능을 쌓기 위해 블록체인을 활용할 수도 있다. 예를 들어, 블록체인 프로토콜은 트랜잭션 출력 내에 추가 사용자 데이터의 저장을 허용한다. 최신 블록체인은 단일 트랜잭션에 저장할 수 있는 최대 데이터 용량을 늘리고 있어, 더욱 복잡한 데이터를 통합할 수 있다. 예를 들어 이는 블록체인에 전자 문서를 저장하거나, 오디오 또는 비디오 데이터를 저장하는 데에도 사용할 수 있다.

네트워크의 각 노드는 전달, 채굴 및 저장의 세 가지 역할 중 하나, 둘 또는 모두를 가질 수 있다. 전달 노드는 네트워크 노드 전체에 트랜잭션을 전파한다. 채굴 노드는 트랜잭션을 블록으로 채굴한다. 저장 노드는 각각 블록체인의 채굴된 블록에 대한 자체 사본을 저장한다. 트랜잭션을 블록체인에 기록하기 위해, 당사자는 트랜잭션을 네트워크의 노드 중 하나로 전송하여 전파한다. 트랜잭션을 수신한 채굴 노드는 트랜잭션을 새로운 블록으로 채굴하기 위해 경쟁할 수 있다. 각 노드는 트랜잭션이 유효하기 위한 하나 이상의 조건을 포함하는 동일한 노드 프로토콜을 따르도록 구성된다. 유효하지 않은 트랜잭션은 전파되거나 블록으로 채굴되지 않는다. 트랜잭션이 유효성 검증되어 블록체인에서 수락된다고 가정하면, 트랜잭션(사용자 데이터 포함)는 P2P 네트워크의 각 노드에 변경 불가능한 공개 기록으로 저장되어 유지된다.

최신 블록을 생성하기 위하여 작업 증명 퍼즐을 성공적으로 해결한 채굴자는 일반적으로 디지털 자산의 새로운 금액을 생성하는 "생성 트랜잭션"이라는 새로운 트랜잭션으로 보상을 받는다. 작업 증명은 블록을 채굴하는 데 많은 양의 컴퓨팅 자원이 필요하고 이중 지출 시도가 포함된 블록은 다른 노드에서 수락되지 않을 가능성이 높기 때문에, 블록에 이중 지출 트랜잭션을 포함함으로써 채굴자가 시스템을 속이지 않도록 장려한다.

"출력 기반" 모델(UTXO 기반 모델로도 지칭됨)에서, 주어진 트랜잭션의 데이터 구조는 하나 이상의 입력과 하나 이상의 출력을 포함한다. 모든 지출 가능한 출력은 UTXO("미지출 트랜잭션 출력")로도 지칭되는 디지털 자산의 금액을 지정하는 요소를 포함한다. 출력은 출력을 리딤(redeem)하기 위한 조건을 지정하는 잠금 스크립트를 더 포함할 수 있다. 각 입력은 선행 트랜잭션 내의 그러한 출력에 대한 포인터를 포함하고, 가리켜진 출력의 잠금 스크립트를 잠금 해제하기 위한 잠금 해제 스크립트를 더 포함할 수 있다. 따라서 한 쌍의 트랜잭션을 고려하여, 제1 및 제2 트랜잭션으로 지칭한다. 제1 트랜잭션은 디지털 자산의 금액을 지정하는 적어도 하나의 출력을 포함하고, 출력을 잠금 해제하는 하나 이상의 조건을 정의하는 잠금 스크립트를 포함한다. 제2 트랜잭션은 제1 트랜잭션의 출력에 대한 포인터를 포함하는 적어도 하나의 입력 및 제1 트랜잭션의 출력을 잠금 해제하기 위한 잠금 해제 스크립트를 포함한다.

이러한 모델에서, 블록체인에 전파되고 기록되기 위하여 제2 트랜잭션이 P2P 네트워크로 전송될 때, 각 노드에 적용되는 유효성 조건 중 하나는 잠금 해제 스크립트가 제1 트랜잭션의 잠금 스크립트에 정의된 하나 이상의 조건을 모두 충족하는 것이다. 다른 하나는 제1 트랜잭션의 출력이 다른 이전 유효한 트랜잭션에 의해 이미 리딤되지 않았다는 것이다. 이러한 조건에 따라 제2 트랜잭션이 유효하지 않음을 발견한 노드는 이를 전파하지 않으며 블록체인에 기록할 블록으로 채굴하기 위해 포함하지 않는다.

트랜잭션 모델의 대안적인 유형은 계정 기반 모델이다. 이 경우 각 트랜잭션은 과거 트랜잭션의 시퀀스에서 선행 트랜잭션의 UTXO를 뒤로 참조하는 것이 아니라, 절대 계정 잔액을 참조하여 전달할 금액을 정의한다. 모든 계정의 현재 상태는 블록체인과 별도로 채굴자에 의해 저장되며 지속적으로 갱신된다. 계정 기반 모델의 트랜잭션은 또한 트랜잭션의 유효성 검증과 동시에 각 노드에서 실행되는 스마트 계약을 포함할 수 있다.

두 모델의 트랜잭션은 지식 증명을 포함할 수 있다. "지식 증명" 또는 "지식의 증명"은 당사자가 예를 들어, d로 지칭하는, 데이터의 일부를 알고 있는지의 임의의 테스트를 지칭하는 기술 용어이다. 출력 기반 트랜잭션 모델의 경우 예를 들어, 하나의 트랜잭션 Tx₁의 출력 내의 잠금 스크립트는 해시 퍼즐을 포함할 수 있다. 제2 트랜잭션 Tx₂의 입력이 Tx₁의 출력을 가리키면, Tx₁의 출력을 성공적으로 리딤하기 위하여 Tx₂의 해당 입력 내의 잠금 해제 스크립트는 해시 퍼즐을 풀어야 한다. 해시 퍼즐은 d의 해시인 해시 값 h, 즉 h = H_puz(d)를 포함한다. 퍼즐은 또한 Tx₂의 잠금 해제 스크립트와 함께 노드에서 실행될 때, Tx₂의 잠금 해제 스크립트에서 d라고 주장되는 데이터 값 d'를 가져와서, 이를 해시 함수 H_puz 로 해시하고, 그리고 Tx₁의 잠금 스크립트에 포함된 해시 값 h와 비교하는 스크립트 조각을 포함한다. 즉, h = H_puz(d') 여부를 확인하고 비교 결과가 예(또는 기술 용어로는 "참")인 경우에만 Tx₁의 출력을 잠금 해제한다. 따라서 Tx₂의 수혜자는 d에 대한 지식을 증명하기 위하여 Tx₂의 잠금 해제 스크립트에 d가 포함된 경우에만 Tx₁의 출력을 잠금 해제할 수 있다.

기존 해시 퍼즐을 단독으로 사용하는 경우의 문제는 비양심적인 채굴자 또는 다른 노드가 Tx₂의 잠금 해제 스크립트에서 d를 관찰한 다음, Tx₂의 자신의 버전 Tx₂ ^* 를 생성하고 채굴(또는 게시)하여, Tx₂에서 의도된 수령인(예를 들어, 밥) 대신 Tx₂ ^*의 출력으로 자신에게 지불할 수 있다는 것이다. 이를 방지하기 위한 기존의 방법은 Tx₁의 잠금 스크립트에 "공개 키 해시로 지불"(P2PKH) 요구 사항을 추가로 포함하는 것이다. d에 대한 지식 증명 외에도, 이는 Tx₂의 잠금 해제 스크립트에 포함될 수취인의 암호화 서명을 요구한다.

해시 퍼즐 및 P2PKH는 또한 출력 기반 모델의 잠금 및 잠금 해제 스크립트 대신 계정 기반 모델에서 스마트 계약을 사용하여 구현할 수도 있다.

당업자에게 친숙한 바와 같이, 암호화 서명은 개인 키 V에 기초하여 생성될 수 있고 개인-공개 키 쌍의 대응하는 공개 키 P에 기초하여 검증될 수 있다. 개인 키 V를 메시지 m에 적용하여 생성된 서명이 주어지면, 다른 당사자가 V를 알지 못하더라도 해당 당사자가 P를 사용하여 서명이 V를 사용하여 생성되었음을 검증할 수 있다(따라서 서명 자체를 확인하는 것은 자체적으로 지식 증명의 다른 형태이다).

이를 위한 알고리즘의 한 형태는 타원 곡선 암호화(elliptic curve cryptography; ECC)에 기초하여 작동하는 타원 곡선 디지털 서명 알고리즘(elliptic curve digital signature algorithm; ECDSA)이다. 이 경우 P와 V는 다음에 의해 관련된다.

여기에서 P는 2개의 요소를 가진 벡터(P_x,P_y)이고, V는 스칼라이며, G는 2차원 타원 곡선의 미리 결정된 점("생성기 점")을 나타내는 2개의 요소를 가진 벡터(G_x,G_y)이다. "ㆍ" 연산은 스칼라 타원 곡선 곱셈-타원 곡선의 한 지점에서 다른 지점으로 변환하는 알려진 연산 형식이다.

ECDSA 서명은 각각 r-부분(r) 및 s-부분(s)으로 당업계에 일반적으로 알려진 2개의 요소로 구성된 튜플(tuple)(r,s)이다. 서명(r,s)은 개인 키 V를 메시지 m에 적용하여 생성된다. 블록체인에 기록하기 위한 트랜잭션의 경우, m은 트랜잭션의 일부가 되고 서명은 해당 트랜잭션의 유효성을 검증할 수 있도록, 해당 부분과 함께 책임 없이 트랜잭션에 태그된다. 예를 들어 출력 기반 모델에서, 서명은 Tx₂의 일부에 서명하고 Tx₁의 출력을 잠금 해제하기 위해 Tx₂의 잠금 스크립트에 포함된다. 서명된 부분은 일반적으로 트랜잭션의 출력을 포함하므로 서명과 트랜잭션을 무효화하지 않고는 변경할 수 없다.

어떤 트랜잭션 모델이 사용되는지에 관계없이, 서명(r,s)은 다음과 같이 계산된다.

여기에서 [R]_x는 2개의 요소를 가진 벡터 R = (R_x,R_y)의 x 좌표를 나타낸다. k는 임시 키(ephemeral key)로 알려져 있다. 이는 일반적으로 무작위로 집합 [1,n-1]에서 선택되며, 여기에서 n은 소수 계수이고 [1,n-1]은 1에서 n-1(포함) 범위의 실수 정수 집합이다. H_sig는 해시 퍼즐에 사용되는 해시 함수 H_puz와 동일하거나 상이한 형태의 해시 함수일 수 있는 해시 함수이다.

서명(r,s), 메시지 m 및 공개 키 P에 대한 지식이 주어지면, 개인 키 V를 모르는 임의의 당사자가 서명이 V에 대한 개인 키를 사용하여 메시지 m에 대해 생성되었음을 확인할 수 있다. 이는 다음을 계산하고:

임을 검증하여 수행된다. 서명은 이것이 참인 경우에만 유효하고, 그렇지 않으면 유효하지 않다. 이것은 공개 키 P와 연관된 당사자가 실제로 메시지 서명자임을 검증하는 것으로 간주될 수 있다.

가능한 채굴자 공격을 피하기 위하여 P2PKH와 결합된 지식 증명으로 해시 퍼즐을 사용하는 것과 관련된 하나의 문제는 P2PKH가 처음에 d를 알고 있는 당사자에게만 지불이 이루어지도록 하는 반면, 이는 또한 Tx₁의 출력이 미리 결정된 특정 수신자 또는 수신자 집합에 묶여 있음을 의미한다(대체 수신자를 포함할 수 있는 대체 조건을 지정할 수 있지만, 여전히 사전 식별되어야 한다)는 것이다.

본원에서 인식하는 바에 따르면, 특정 비밀 가치의 지식을 증명할 수 있는 불특정 당사자가 리딤할 수 있는 트랜잭션을 허용하되, 해당 가치를 드러내지 않는 방식으로 허용하는 것이 바람직할 것이다. 예를 들어, 앨리스(Alice)가 자신이 비밀 키를 제공하는 모든 사람이 잠금을 해제할 수 있는 제1 트랜잭션을 설정하고 싶지만, 이러한 당사자가 누구인지는 미리 지정하고자 하지 않는다고 가정한다. 예를 들어 제1 트랜잭션은 앨리스를 대신하여 편지나 소포와 같은 일부 물품의 배달을 수락하도록 누군가에게 지불하거나 및/또는 물품을 배달하기 위해 배달 회사에 지불할 수 있다. 제1 트랜잭션은 비밀에 대한 지식을 증명하는 제2 트랜잭션으로 리딤될 수 있다. 배송을 주문하는 시점에, 앨리스는 제1 트랜잭션을 설정하고 이를 배송 회사에 제공하거나 블록체인에 게시할 수 있다(또는 단순히 예를 들어 배송 회사에서 제1 트랜잭션을 생성하는 데 필요한 세부 정보 제공). 따라서 배송 회사는 배송이 완료되면 지불이 이루어질 것이라고 확신한다. 그러나, 앨리스는 이 단계에서 누가 대신하여 배달을 받을지 결정하고자 하지 않는다. 대신, 그녀는 나중에 하나 이상의 신뢰할 수 있는 당사자(예를 들어 그녀의 플랫메이트 찰리(Charlie) 및/또는 현재 배달 당일에 있을 것이라고 확인한 밥(Bob))에게만 비밀 값을 제공한다. 이는 앨리스의 비밀 가치에 대한 증거를 보여주는 제2 트랜잭션을 제공하여 그들 중 누구라도 그녀를 대신하여 서명할 수 있게 한다.

이것은 단지 하나의 예시적인 예라는 것을 이해할 것이다. 다른 예로, 트랜잭션은 계약 조건에 대한 동의를 나타내는 데 사용될 수 있다. 앨리스는 지금 계약을 설정하기를 원할 수 있지만, 그녀를 대신하여 서명할 수 있도록 하나 이상의 신뢰할 수 있는 당사자의 하위 집합에 대해 서명 권한 또는 위임장을 부여하기로 결정한 사실 이후에만 하고자 할 수 있다. 예를 들어 계약을 설정할 때 앨리스는 자신이 서명하려고 했을 수 있지만, 나중에야 그녀가 정신 능력을 상실하거나 어떤 이유로 서명할 수 없다는 것을 알게 되어, 다른 사람(예를 들어 이 경우 밥과 찰리가 그녀의 가족이나 사업 동료일 수 있음)에게 위임을 부여해야 한다.

더 일반적으로, 기존 해시 퍼즐에 대한 대안을 제공하는 것이 바람직할 수도 있으며, 퍼즐의 대안적 형태는 해당 값을 노드에 공개하거나 블록체인에 게시하지 않고, 또한 특정 신원에 얽매이지 않은, 비밀 값에 대한 지식 증명을 가능하게 할 것이다.

본 개시에 따르면, 본원에서 "r-퍼즐", 또는 동의어로 "r-도전"으로 지칭되는 새로운 유형의 지식 증명이 제공된다. 이는 도전(즉, 퍼즐)의 기초로 ECDSA 서명의 r-부분에 대응하는 기준 값에 기초한다. 기준 값은 제1 트랜잭션을 리딤하기 위하여 제2 트랜잭션이 지정된 r-부분을 포함하는 서명을 (예를 들어 Tx₂의 잠금 해제 스크립트 내에) 포함할 것을 요구하는 도전으로서 제1 트랜잭션 내에(예를 들어 Tx₁의 잠금 스크립트 내에) 포함된다. 제2 트랜잭션에서 r-퍼즐에 대한 해를 제공함으로써, 이는 증명자가 대응하는 임시 키 k를 알고 있었음을 증명하지만, 제2 트랜잭션에서 k를 공개할 필요가 없다. 따라서 k는 임시 개인 키로 사용될 수 있고, r은 대응하는 임시 공개 키와 같이 작동한다.

본원에 개시된 일 양상에 따르면, 타원 곡선 디지털 서명 알고리즘(ECDSA) 검증 함수에 기초하여 지식 증명을 수행하는, 컴퓨터 구현 방법이 제공된다. 방법은, 블록체인 네트워크의 검증 노드에서: 실행 가능한 코드를 포함하는 제1 트랜잭션을 획득하는 것-코드는 제1 ECDSA 서명의 r-부분의 기준 인스턴스를 지정하는 요소를 포함함; 적어도 제1 ECDSA 서명의 s-부분을 포함하는 제2 트랜잭션을 수신하는 것, 및 제1 공개 키를 획득하는 것-제1 ECDSA 서명은 제1 공개 키에 대응하는 제1 개인 키에 기초하여 메시지에 서명하고, 메시지는 제2 트랜잭션의 일 부분임-을 포함한다. 그런 다음 방법은 제1 트랜잭션으로부터 코드를 실행하는 것을 포함한다. 코드는 제1 개인 키로 누구의 개인 키가 사용되었는지(및 따라서 제2 트랜잭션에서 누구의 공개 키가 사용되었는지)에 무관하게: 제2 트랜잭션 내에서 수신된 메시지 및 획득된 제1 공개 키가 주어지면, 제1 ECDSA 서명에 적용된, ECDSA 검증 함수가 제2 트랜잭션 내에서 수신된 s-부분이 제1 트랜잭션에 의해 지정된 r-부분의 기준 인스턴스에 대응하는 것을 검증하는 조건에서 참의 결과를 반환하도록 구성된다.

제1 트랜잭션의 코드에 포함된 요소는 r-부분 자체의 기준 인스턴스일 수 있고, 또는 그 변환, 예를 들어 r-부분을 포함하는 구성 요소의 해시(해시된 구성 요소는 r-부분 자체와 동일하거나 예를 들어 다른 데이터 값 d와 연결될 수 있음)일 수 있다. 따라서 맥락에서 "지정된"이 반드시 명시적 값을 포함한다는 의미는 아님을 유의한다(물론 이는 확실히 가능한 구현 중 하나이다). 더 일반적으로, ECDSA 검증 알고리즘에 따라 s-부분의 제출된 인스턴스가 유효하게 기준 인스턴스에 대응하는지 확인을 가능하게 하는 r-부분의 기준 인스턴스(예를 들어 그 해시)와 동일하거나 이로부터 유도되는 임의의 요소를 지칭할 수 있다.

어떤 식으로 지정되든, 코드는 이에 따라 도전자(예를 들어 밥)가 임시 키 k를 알고 있어야 함을 증명하는 "r-퍼즐"을 설정한다(k에 대한 지식 없이 해가 제공될 수 있다는 것은 실현 가능하지 않음). 퍼즐은 이 지식 증명의 기초로 r-부분을 유리하게 사용하며, 도전자가 임시 키 k를 노드에 제출하거나 제2 트랜잭션(예를 들어 Tx₂)에서 이를 공개할 것을 요구하지 않는다. 이는, 예를 들어, k가 제1 당사자(예를 들어 앨리스)에 의해 일종의 임시 개인 키 또는 비밀로 사용될 수 있음을 의미하며, 이를 사용하여 밥 및/또는 찰리와 같은 하나 이상의 제2 당사자에게 서명 권한을 부여할 수 있다. r-퍼즐은 k를 공개하지 않고 k에 대한 지식을 증명하므로, 악의적인 채굴자 또는 다른 노드는 의도한 수혜자 대신 자신에게 지불할 유효한 제2 트랜잭션 Tx₂ ^*를 형성하기 위해 자신의 서명을 생성할 수 없다. 또한, 서명의 r-부분 자체는 시스템 내의 어떤 신원과도 연결되지 않으므로, 이는 k를 아는 사람은 누구나 증명을 충족할 수 있음을 의미한다. 제2 트랜잭션의 유효성에 대한 조건은 제1 트랜잭션에 의해 특정 신원에 연결될 필요가 없다. 따라서 예를 들어 앨리스는 제1 트랜잭션을 잠글 대상을 미리 결정할 필요가 없다. 예를 들어 그녀는 배달 회사에 제1 트랜잭션을 설정하기 위한 세부 정보를 제공한 다음, 누가 그녀를 대신하여 소포를 수락하도록 서명 권한을 부여할지 나중에 결정할 수 있다.

본 개시의 실시예의 이해를 돕고 그러한 실시예가 실행되는 방법을 보여주기 위하여, 단지 예로서 첨부 도면을 참조한다:
도 1은 블록체인을 구현하는 시스템의 개략적인 블록도이다.
도 2는 블록체인에 기록될 수 있는 트랜잭션의 몇 가지 예를 개략적으로 도시한다.
도 3은 블록체인을 구현하는 다른 시스템의 개략적인 블록도이다.
도 4는 출력 기반 모델의 노드 프로토콜에 따라 트랜잭션을 처리하는 노드 소프트웨어의 개략적인 블록도이다.
도 5는 예시적인 트랜잭션 집합을 개략적으로 도시한다.
도 6a 내지 도 6d는 타원 곡선 디지털 서명 알고리즘(ECDSA) 이면의 몇 가지 원리를 개략적으로 도시한다.
도 7은 본원에서 r-퍼즐(또는 동의어로 r-도전)으로 지칭하는 지식 증명 유형의 가능한 일 구현의 개략도이다.
도 8은 r-퍼즐의 가능한 다른 구현의 개략도이다.
도 9는 r-퍼즐의 가능한 다른 구현의 개략도이다.
도 10은 r-퍼즐의 가능한 또 다른 구현의 개략도이다.
도 11은 계정 기반 모델의 노드 프로토콜에 따라 트랜잭션을 처리하는 노드 소프트웨어의 개략적인 블록도이다.
도 12는 ECDSA 서명의 예시적인 형식을 개략적으로 도시한다.
도 13은 r-퍼즐의 일 형태에 대한 잠금 및 잠금 해제 스크립트의 예시적인 구현에 대한 단계별 스크립트 분석이다.
도 14a 내지 도 14b는 일련의 r-퍼즐 정방향 트랜잭션을 개략적으로 도시한다.

일부 암호 체계에서 검증자는 사람(증명자 또는 도전자라고 함)이 지식 증명이라고 하는 것 내에 일부 정보를 가지고 있다는 확신을 요구할 수 있다. 단순하게는, 이는 검증자에게 직접 정보를 제공함으로써 수행될 수 있다. 대안적으로 증명자가 정보에 따라 계산을 수행해야 할 수도 있다. 바람직하게는 관련된 계산은 검증자 자신이 도전을 설정하기 위해 정보를 알 필요가 없고, 증명자가 정보를 알고 있음을 검증하기 위해 정보를 검증자에게 공개할 필요가 없도록 하는 것이다. 계산 방법의 경우, 입력 데이터에 대해 검증 계산을 수행해야 한다. 비밀 값에 대한 지식을 증명하는 간단한 방법은 그 사전 이미지(preimage) 및 충돌 저항(collision resistance) 기능으로 인해 암호화 해시 함수를 사용하는 것이다. 이 해시 방법은 해시 함수가 개인 키-공개 키 암호 시스템의 기본 부분을 형성하기 때문에 많은 블록체인 애플리케이션에 쉽게 통합될 수 있다. 이러한 유형의 지식 증명은 일반적으로 해시 퍼즐로 지칭되는 블록체인 애플리케이션에서 매우 다양하다.

UTXO 기반 블록체인에서, 해시 퍼즐(해시된 값의 사전 이미지)에 대한 해(solution)를 지출 조건으로 설정할 수 있으므로 트랜잭션 검증의 일부로 채굴자가 검증을 수행한다. 그러나, 이 접근 방식에서 트랜잭션은 또한 특정 개인 키를 사용하는 서명을 요구하여야 하는데, 그렇지 않으면 채굴자가 블록 내에 트랜잭션을 포함하기 전에 해시 퍼즐 해를 수신하기 때문이다. 이는 악의적인 채굴자가 채굴자에 속한 주소를 향한 출력으로 지출 트랜잭션을 생성할 기회를 줄 것이다.

본 개시에서, 채굴자(또는 전달 노드)에 의해 수행되는 유효성 검증을 여전히 허용하면서 이 문제를 우회하는 지식 증명이 제공된다. 이를 위해, 지식 증명은 타원 곡선 디지털 서명 알고리즘(ECDSA) 서명에 대응하는 임시 키와 연결된다. 이 알고리즘에 사용되는 암호화 기본 요소는 많은 블록체인에 본래 갖추어져 있으므로, 현재 기반구조에 쉽게 통합할 수 있다.

예시적인 시스템 개요

도 1은 블록체인(150)을 구현하는 예시적인 시스템(100)을 도시한다. 시스템(100)은 패킷 교환 네트워크(101), 일반적으로 인터넷과 같은 광역 인터네트워크를 포함한다. 패킷 교환 네트워크(101)는 패킷 교환 네트워크(101) 내에서 피어-투-피어(P2P) 오버레이 네트워크(106)를 형성하도록 배열된 복수의 노드(104)를 포함한다. 각 노드(104)는 피어의 컴퓨터 장비를 포함하며, 상이한 노드(104)는 상이한 피어에 속한다. 각 노드(104)는 하나 이상의 프로세서, 예를 들어, 하나 이상의 중앙 처리 장치(CPU), 가속기 프로세서, 애플리케이션 특정 프로세서 및/또는 필드 프로그램 가능 게이트 어레이(FPGA)를 포함한다. 각 노드는 또한 메모리, 즉 비일시적 컴퓨터 판독 가능 매체 형태의 컴퓨터 판독 가능 스토리지를 포함한다. 메모리는 하나 이상의 메모리 매체, 예를 들어, 하드 디스크와 같은 자기 매체; 솔리드 스테이트 드라이브(SSD), 플래시 메모리 또는 EEPROM과 같은 전자 매체; 및/또는 광 디스크 드라이브와 같은 광 매체를 사용하는 하나 이상의 메모리 유닛을 포함할 수 있다.

블록체인(150)은 데이터 블록의 체인(151)을 포함하며, 블록체인(150)의 각자의 사본이 P2P 네트워크(160)의 복수의 노드 각각에서 유지된다. 체인 내의 각 블록(151)은 하나 이상의 트랜잭션(152)을 포함하며, 이 맥락에서 트랜잭션은 일종의 데이터 구조를 지칭한다. 데이터 구조의 특성은 트랜잭션 모델 또는 체계의 일부로 사용되는 트랜잭션 프로토콜 유형에 의존할 것이다. 주어진 블록체인은 일반적으로 전체에 걸쳐 하나의 특정 트랜잭션 프로토콜을 사용한다. 하나의 공통 유형의 트랜잭션 프로토콜에서, 각 트랜잭션(152)의 데이터 구조는 적어도 하나의 입력 및 적어도 하나의 출력을 포함한다. 각 출력은 출력이 암호로 잠긴 사용자(103)에 속한 디지털 자산의 양을 나타내는 금액을 지정한다(잠금을 해제하여 리딤(redeem)하거나 지출하기 위해서는 해당 사용자의 서명이 필요함). 각 입력은 선행 트랜잭션(152)의 출력을 뒤로 가리키므로, 트랜잭션을 연결한다.

노드(104) 중 적어도 일부는 트랜잭션(152)를 전달하고 이에 따라 전파하는 전달 노드(104F)의 역할을 수행한다. 노드(104) 중 적어도 일부는 블록(151)을 채굴하는 채굴자(104M)의 역할을 수행한다. 노드(104) 중 적어도 일부는 각자의 메모리에 동일한 블록체인(150)의 각자의 사본을 저장하는 저장 노드(104S)(때때로 "전체 사본(full-copy)" 노드라고도 함)의 역할을 한다. 각 채굴자 노드(104M)는 또한 블록(151)으로 채굴되기를 기다리는 트랜잭션(152)의 풀(154)을 유지한다. 주어진 노드(104)는 전달 노드(104), 채굴자(104M), 저장 노드(104S) 또는 이들 중 임의의 둘 또는 모두의 조합일 수 있다.

주어진 현재 트랜잭션(152j)에서, 그(또는 각각의) 입력은 트랜잭션 시퀀스에서 선행 트랜잭션(152i)의 출력을 참조하는 포인터를 포함하며, 이 출력이 현재 트랜잭션(152j)에서 리딤되거나 "지출됨"을 지정한다. 일반적으로, 선행 트랜잭션은 풀(154) 또는 임의의 블록(151) 내의 임의의 트랜잭션일 수 있다. 선행 트랜잭션(152i)은 현재 트랜잭션(152j)가 생성되거나 네트워크(106)로 전송될 때 반드시 존재할 필요는 없지만, 선행 트랜잭션(152i)은 현재 트랜잭션이 유효하려면 존재하고 유효성 검증되어야 한다. 따라서 본원에서 "선행(preceding)"은 포인터에 의해 연결된 논리적 시퀀스의 선행자를 지칭하며, 반드시 시간적 시퀀스로 생성 또는 전송하는 시간이 아니고, 따라서 트랜잭션(152i, 152j)이 순서와 다르게(out-of-order)(고아 트랜잭션에 대한 아래 논의 참조) 생성되거나 전송되는 것을 반드시 배제하지 않는다. 선행 트랜잭션(152i)은 앞선(antecedent) 트랜잭션 또는 선행자(predecessor) 트랜잭션으로 동등하게 지칭될 수 있다.

현재 트랜잭션(152j)의 입력은 또한 선행 트랜잭션(152i)의 출력이 잠겨 있는 사용자(103a)의 서명을 포함한다. 차례로, 현재 트랜잭션(152j)의 출력은 새로운 사용자(103b)에 대해 암호학적으로 잠길 수 있다. 따라서 현재 트랜잭션(152j)은 선행 트랜잭션(152i)의 입력에 정의된 금액을 현재 트랜잭션(152j)의 출력에 정의된 바와 같이 새로운 사용자(103b)에게 전달할 수 있다. 일부 경우에 트랜잭션(152)은 다수의 사용자(그 중 하나는 잔돈을 주기 위해 원래 사용자(103a)일 수 있음) 사이에 입력 금액을 분할하기 위해 다수의 출력을 가질 수 있다. 일부 경우에 트랜잭션은 또한 하나 이상의 선행 트랜잭션의 다수의 출력에서 금액을 수집하고 현재 트랜잭션의 하나 이상의 출력에 재분배하기 위해 다수의 입력을 가질 수도 있다.

위의 것은 "출력 기반" 트랜잭션 프로토콜로 지칭될 수 있으며, 때때로 또한 지출되지 않은 트랜잭션 출력(UTXO) 유형 프로토콜(출력을 UTXO로 지칭함)로 지칭된다. 사용자의 총 잔고는 블록체인에 저장된 어떤 하나의 숫자로 정의되지 않으며, 대신 사용자는 블록체인(151) 내의 많은 상이한 트랜잭션(152)에 흩어져 있는 해당 사용자의 모든 UTXO 값을 대조하기 위해 특별한 "지갑" 애플리케이션(105)이 필요하다.

트랜잭션 프로토콜의 대안적인 유형은 계정 기반 트랜잭션 모델의 일부로 "계정 기반" 프로토콜로 지칭될 수 있다. 계정 기반의 경우, 각 트랜잭션은 과거 트랜잭션의 시퀀스에서 선행 트랜잭션의 UTXO를 뒤로 참조하여 전달할 금액을 정의하지 않고, 절대 계정 잔액을 참조한다. 모든 계정의 현재 상태는 블록체인과 별도로 채굴자에 의해 저장되며 지속적으로 갱신된다. 이러한 시스템에서, 트랜잭션은 계정의 실행 중인 트랜잭션 집계("포지션"이라고도 함)를 사용하여 정렬된다. 이 값은 암호화 서명의 일부로 발신인이 서명하고 트랜잭션 참조 계산의 일부로 해시된다. 또한, 선택적 데이터 필드가 또한 트랜잭션 내에 서명할 수도 있다. 이 데이터 필드는 예를 들어 선행 트랜잭션 ID가 데이터 필드에 포함된 경우 선행 트랜잭션을 뒤로 가리킬 수 있다.

트랜잭션 프로토콜의 어느 유형이든, 사용자(103)가 새로운 트랜잭션(152j)을 시행하기를 원할 때, 그/그녀는 자신의 컴퓨터 단말(102)에서 P2P 네트워크(106)의 노드(104) 중 하나(최근에는 일반적으로 서버 또는 데이터 센터, 그러나 원칙적으로 다른 사용자 단말이 될 수 있음)로 새로운 트랜잭션을 보낸다. 이 노드(104)는 각 노드(104)에 적용되는 노드 프로토콜에 따라 트랜잭션이 유효한지 확인한다. 노드 프로토콜의 세부사항은 해당 블록체인(150)에서 사용되는 트랜잭션 프로토콜의 유형에 대응하며, 함께 전체 트랜잭션 모델을 형성한다. 노드 프로토콜은 일반적으로 노드(104)가 새로운 트랜잭션(152j)의 암호화 서명이 예상되는 서명과 일치하는지 확인하도록 요구하며, 이는 트랜잭션(152)의 정렬된 시퀀스에서 이전 트랜잭션(152i)에 의존한다. 출력 기반의 경우에, 이는 새로운 트랜잭션(152j)의 입력에 포함된 사용자의 암호화 서명이 새로운 트랜잭션이 지출하는 선행 트랜잭션(152i)의 출력에 정의된 조건과 일치하는지 확인하는 것을 포함하며, 여기에서 이 조건은 일반적으로 적어도 새로운 트랜잭션(152j)의 입력 내의 암호화 서명이 새로운 트랜잭션의 입력이 가리키는 이전 트랜잭션(152i)의 출력을 잠금 해제하는지 확인하는 것을 포함한다. 일부 트랜잭션 프로토콜에서 조건은 입력 및/또는 출력에 포함된 사용자 정의 스크립트에 의해 적어도 부분적으로 정의될 수 있다. 대안적으로 단순히 노드 프로토콜만으로 고정되거나, 이들의 조합으로 인한 것일 수 있다. 어느 쪽이든, 새로운 트랜잭션(152j)이 유효하면, 현재 노드는 이를 P2P 네트워크(106)의 하나 이상의 다른 노드(104)로 전달한다. 이러한 노드(104) 중 적어도 일부는 또한 전달 노드(104F)의 역할을 하여, 동일한 노드 프로토콜에 따른 동일한 테스트를 적용하고, 새로운 트랜잭션(152j)을 하나 이상의 추가 노드(104)로 전달하며, 이와 같이 계속된다. 이러한 방식으로 새로운 트랜잭션은 노드(104)의 네트워크 전체에 전파된다.

출력 기반 모델에서, 주어진 출력(예를 들어, UTXO)의 지출 여부에 대한 정의는 노드 프로토콜에 따라 다른 앞의 트랜잭션(152j)의 입력에 의해 유효하게 리딤되었는지의 여부이다. 트랜잭션이 유효하기 위한 다른 조건은 지출 또는 리딤을 시도하는 선행 트랜잭션(152i)의 출력이 다른 유효한 트랜잭션에 의해 이미 지출/리딤되지 않은 것이다. 유효하지 않은 경우에는, 트랜잭션(152j)은 블록체인에 전파되거나 기록되지 않는다. 이는 지출자가 동일한 트랜잭션의 출력을 두 번 이상 사용하고자 시도하는 이중 지출을 방지한다. 반면 계정 기반 모델은 계정 잔액을 유지하여 이중 지출을 방지한다. 트랜잭션의 정의된 순서가 있기 때문에, 계정 잔액은 임의의 일 시간에 단일의 정의된 상태를 갖는다.

유효성 검증에 추가하여, 노드(104M) 중 적어도 일부는 "작업 증명"에 의해 뒷받침되는 채굴로 알려진 프로세스에서 트랜잭션 블록을 최초로 생성하기 위해 경쟁한다. 채굴 노드(104M)에서, 아직 블록에 나타나지 않은 유효한 트랜잭션의 풀에 새로운 트랜잭션이 추가된다. 그런 다음 채굴자는 암호화 퍼즐을 풀고자 시도함으로써 트랜잭션의 풀(154)로부터 트랜잭션(152)의 새로운 유효한 블록(151)을 조립하기 위해 경쟁한다. 일반적으로 이것은 논스가 트랜잭션(154)의 풀과 연결되고 해시될 때 해시의 출력이 미리 결정된 조건을 충족하도록 "논스" 값을 검색하는 것을 포함한다. 예를 들어 사전 결정된 조건은 해시의 출력이 사전 정의된 특정 수의 선행 0을 갖는 것일 수 있다. 해시 함수의 속성은 그 입력에 대해 예측할 수 없는 출력을 갖는다는 것이다. 따라서 이 검색은 무차별 대입에 의해서만 수행될 수 있으므로, 퍼즐을 풀고자 하는 각 노드(104M)에서 상당한 양의 처리 자원을 소비한다.

퍼즐을 풀고자 하는 제1 채굴자 노드(104M)는 이를 네트워크(106)에 발표하고, 그 해를 증명으로 제공하며, 이는 네트워크의 다른 노드(104)가 쉽게 확인할 수 있다(해시에 대한 해가 주어지면 해시의 출력이 조건을 충족하도록 하는지 확인하는 것은 간단하다). 승자가 퍼즐을 해결한 트랜잭션의 풀(154)은 각 노드에서 승자의 발표된 해를 확인한 것에 기초하여, 저장 노드(104S)의 역할을 하는 적어도 일부의 노드(104) 에 의해 블록체인(150)에 새로운 블록(151)으로 기록된다. 블록 포인터(155)가 또한 체인에서 이전에 생성된 블록(151n-1)을 뒤로 가리키는 새로운 블록(151n)에 할당된다. 새로운 블록(151)을 생성하는 데 많은 노력이 필요하고 이중 지출을 포함하는 블록은 다른 노드(104)에 의해 거부될 가능성이 높기 때문에, 채굴 노드(104M)는 이중 지출이 블록에 포함되는 것을 허용하지 않도록 장려되어 작업 증명은 이중 지출의 위험을 줄이는 데 도움이 된다. 일단 생성되면, 블록(151)은 동일한 프로토콜에 따라 P2P 네트워크(106)의 저장 노드(104S) 각각에서 인식되고 유지되기 때문에 수정될 수 없다. 블록 포인터(155)는 또한 블록(151)에 순차적인 순서를 부과한다. 트랜잭션(152)은 P2P 네트워크(106)의 각 저장 노드(104S)에서 순서화된 블록에 기록되기 때문에, 이는 따라서 트랜잭션의 불변 공개 원장을 제공한다.

해의 검색을 시작한 시기에 따라, 주어진 시간에 퍼즐을 풀기 위해 경쟁하는 다른 채굴자(104M)가, 주어진 시간에 채굴되지 않은 트랜잭션 풀(154)의 다른 스냅샷에 기초하여 그렇게 할 수 있다는 점에 유의한다. 각자의 퍼즐을 먼저 푸는 사람이 다음의 새로운 블록(151n)에 포함되는 트랜잭션(152)를 정의하고, 채굴되지 않은 트랜잭션의 현재 풀(154)이 갱신된다. 그런 다음 채굴자(104M)는 새로 정의된 미해결 풀(154)로부터 블록을 생성하기 위해 계속 경쟁하며, 이와 같이 계속된다. 두 채굴자(104M)가 매우 짧은 시간 내에 퍼즐을 해결하여 블록체인에 대한 상충되는 뷰(view)가 전파되는 것인 "포크(fork)"가 발생하는 것을 해결하기 위한 프로토콜 또한 존재한다. 요컨대, 포크의 갈래가 가장 길게 자라는 것이 최종 블록체인(150)이 된다.

대부분의 블록체인에서, 승리한 채굴자(104M)는 새로운 양의 디지털 자산을 어디에선지 모르게 생성하는(한 사용자로부터 다른 사용자에게 디지털 자산의 금액을 전달하는 일반 트랜잭션과 반대) 특별한 종류의 새로운 트랜잭션으로 자동 보상을 받는다. 따라서 승리한 노드는 디지털 자산의 양을 "채굴"했다고 한다. 이 특별한 유형의 트랜잭션은 때때로 "생성(generation)" 트랜잭션으로 지칭된다. 이는 새로운 블록(151n)의 일부를 자동으로 형성한다. 이 보상은 채굴자(104M)가 작업 증명 경쟁에 참여하는 인센티브를 제공한다. 종종 일반(비생성) 트랜잭션(152) 또한 해당 트랜잭션이 포함된 블록(151n)을 생성한 우승 채굴자(104M)에게 추가로 보상하기 위해, 그 출력 중 하나에 추가 트랜잭션 수수료를 지정할 것이다.

채굴과 관련된 계산 자원으로 인해, 일반적으로 적어도 각 채굴자 노드(104M)는 하나 이상의 물리적 서버 유닛, 또는 심지어 전체 데이터 센터를 포함하는 서버의 형태를 취한다. 각 전달 노드(104M) 및/또는 저장 노드(104S) 또한 서버 또는 데이터 센터의 형태를 취할 수 있다. 그러나 원칙적으로 임의의 주어진 노드(104)는 함께 네트워크로 연결된 사용자 단말 또는 그룹의 형태를 취할 수 있다.

각 노드(104)의 메모리는 노드 프로토콜에 따라 각자의 역할을 수행하고 트랜잭션(152)을 처리하기 위해 노드(104)의 처리 장치에서 실행되도록 구성된 소프트웨어(400)를 저장한다. 본원에서 노드(104)에 기인한 임의의 동작은 각자의 컴퓨터 장비의 처리 장치에서 실행되는 소프트웨어(400)에 의해 수행될 수 있다는 것이 이해될 것이다. 노드 소프트웨어(400)는 애플리케이션 계층, 또는 운영 체제 계층 또는 프로토콜 계층과 같은 하위 계층, 또는 이들의 임의의 조합에서 하나 이상의 애플리케이션에서 구현될 수 있다. 또한, 본원에서 사용하는 "블록체인"이라는 용어는 일반적으로 기술의 종류를 지칭하는 총칭으로, 특정 독점 블록체인, 프로토콜 또는 서비스에 제한되지 않는다.

또한 네트워크(101)에는 소비 사용자의 역할을 하는 복수의 당사자(103) 각각의 컴퓨터 장비(102)가 연결되어 있다. 이들은 트랜잭션에서 지급인 및 수취인 역할을 하지만 다른 당사자를 대신하여 트랜잭션을 채굴하거나 전파하는 데 반드시 참여하는 것은 아니다. 그들은 반드시 채굴 프로토콜을 실행할 필요는 없다. 제1 당사자(103a) 및 그 컴퓨터 장비(102a) 및 제2 당사자(103b) 및 그 컴퓨터 장비(102b)인 두 당사자(103) 및 그들 각자의 장비(102)가 예시 목적으로 도시되어 있다. 더 많은 이러한 당사자(103) 및 그들 각자의 컴퓨터 장비(102)가 존재하고 시스템에 참여할 수 있지만, 편의상 그것들은 도시되지 않았다는 것이 이해될 것이다. 각 당사자(103)는 개인 또는 조직일 수 있다. 순전히 예시로서 제1 당사자(103a)는 본원에서 앨리스(Alice)로 지칭되고 제2 당사자(103b)는 밥(Bob)으로 지칭되지만, 이것이 제한적이지 않고 앨리스 또는 밥에 대한 본원에서의 임의의 언급은 각각 "제1 당사자" 및 "제2 당사자"로 대체될 수 있음을 이해할 것이다.

각 당사자(103)의 컴퓨터 장비(102)는 하나 이상의 프로세서, 예를 들어, 하나 이상의 CPU, GPU, 기타 가속기 프로세서, 애플리케이션 특정 프로세서 및/또는 FPGA를 포함하는 각자의 처리 장치를 포함한다. 각 당사자(103)의 컴퓨터 장비(102)는 메모리, 즉 비일시적 컴퓨터 판독 가능 매체 형태의 컴퓨터 판독 가능 스토리지를 더 포함한다. 이 메모리는 하나 이상의 메모리 매체, 예를 들어, 하드 디스크와 같은 자기 매체; SSD, 플래시 메모리 또는 EEPROM과 같은 전자 매체; 및/또는 광 디스크 드라이브와 같은 광 매체를 사용하는 하나 이상의 메모리 유닛을 포함할 수 있다. 각 당사자(103)의 컴퓨터 장비(102) 상의 메모리는 처리 장치 상에서 실행되도록 배열된 적어도 하나의 클라이언트 애플리케이션(105)의 각자의 인스턴스를 포함하는 소프트웨어를 저장한다. 본원에서 주어진 당사자(103)에 기인한 임의의 동작은 각자의 컴퓨터 장비(102)의 처리 장치에서 실행되는 소프트웨어를 사용하여 수행될 수 있다는 것을 이해할 것이다. 각 당사자(103)의 컴퓨터 장비(102)는 적어도 하나 사용자 단말, 예를 들어 데스크탑 또는 랩탑 컴퓨터, 태블릿, 스마트폰, 또는 스마트워치와 같은 웨어러블 장치를 포함한다. 주어진 당사자(103)의 컴퓨터 장비(102)는 또한 사용자 단말을 통해 접근되는 클라우드 컴퓨팅 자원과 같은 하나 이상의 다른 네트워크 자원을 포함할 수 있다.

클라이언트 애플리케이션(105)은 임의의 주어진 당사자(103)의 컴퓨터 장비(102)에 적절한 컴퓨터 판독 가능 저장 매체 상에, 예를 들어 서버로부터 다운로드하거나, 또는 이동식 SSD, 플래시 메모리 키, 이동식 EEPROM, 이동식 자기 디스크 드라이브, 자기 플로피 디스크 또는 테이프, CD 또는 DVD ROM과 같은 광 디스크 또는 이동식 광 드라이브 등과 같은 이동식 저장 장치에 제공되어 초기에 제공될 수 있다.

클라이언트 애플리케이션(105)은 적어도 "지갑" 기능을 포함한다. 여기에는 두 가지 주요 기능이 있다. 이들 중 하나는 각 사용자 당사자(103)가 노드(104)의 네트워크 전체에 전파되어 블록체인(150)에 포함될 트랜잭션(152)를 생성, 서명 및 전송할 수 있게 하는 것이다. 다른 하나는 각 당사자에게 현재 소유하고 있는 디지털 자산의 금액을 다시 보고하는 것이다. 출력 기반 시스템에서, 이 제2 기능은 블록체인(150) 전체에 흩어져 있는 해당 당사자에 속하는 다양한 트랜잭션(152)의 출력에 정의된 금액을 대조하는 것을 포함한다.

참고: 다양한 클라이언트 기능이 주어진 클라이언트 애플리케이션(105)에 통합되는 것으로 설명될 수 있지만, 이는 반드시 제한적인 것은 아니며 대신 본원에 설명된 임의의 클라이언트 기능이 예를 들어, 2개 이상의 별개의 애플리케이션을 수행하기 위하여, 예를 들어 API를 통해 인터페이스하여 또는 다른 하나에 대한 플러그인으로 구현될 수 있다. 더 일반적으로 클라이언트 기능은 애플리케이션 계층이나 운영 체제와 같은 하위 계층, 또는 이들의 조합에서 구현될 수 있다. 다음은 클라이언트 애플리케이션(105)과 관련하여 설명될 것이지만 이것이 제한적이지 않다는 것이 이해될 것이다.

각 컴퓨터 장비(102) 상의 클라이언트 애플리케이션 또는 소프트웨어(105)의 인스턴스는 P2P 네트워크(106)의 전달 노드(104F) 중 적어도 하나에 작동 가능하게 연결된다. 이는 클라이언트(105)의 지갑 기능이 트랜잭션(152)을 네트워크(106)로 전송할 수 있게 한다. 클라이언트(105)는 또한 각 당사자(103)가 수령인인 임의의 트랜잭션에 대해 블록체인(150)에 질의하기 위해(또는 실제로 블록체인(150)에서 다른 당사자의 트랜잭션을 검사하기 위해, 실시예에서 블록체인(150)은 그 공개 가시성을 통해 부분적으로 트랜잭션에 대한 신뢰를 제공하는 공공 시설이므로) 저장 노드(104) 중 하나, 일부 또는 전부에 접촉할 수 있다. 각 컴퓨터 장비(102) 상의 지갑 기능은 트랜잭션 프로토콜에 따라 트랜잭션(152)를 공식화(formulate) 하고 전송하도록 구성된다. 각 노드(104)는 노드 프로토콜에 따라 트랜잭션(152)를 유효성 검증하도록 구성된 소프트웨어(400)를 실행하고, 전달 노드(104F)의 경우 네트워크(106) 전체에 전파하기 위해 트랜잭션(152)를 전달한다. 트랜잭션 프로토콜과 노드 프로토콜은 서로 대응하며, 주어진 트랜잭션 프로토콜은 주어진 트랜잭션 모델을 함께 구현하는 주어진 노드 프로토콜을 따른다. 블록체인(150)의 모든 트랜잭션(152)에 대해 동일한 트랜잭션 프로토콜이 사용된다(그러나 트랜잭션 프로토콜은 내부에서 상이한 하위 유형의 트랜잭션을 허용할 수 있음). 동일한 노드 프로토콜이 네트워크(106)의 모든 노드(104)에 의해 사용된다(그러나 이는 해당 하위 유형에 대해 정의된 규칙에 따라 상이한 하위 유형의 트랜잭션을 상이하게 처리할 수 있으며, 또한 상이한 노드가 상이한 역할을 수행하여 프로토콜의 상이한 대응하는 양상을 구현할 수 있음).

언급된 바와 같이, 블록체인(150)은 블록의 체인(151)을 포함하고, 여기에서 각 블록(151)은 이전에 논의된 바와 같이 작업 증명 프로세스에 의해 생성된 하나 이상의 트랜잭션(152) 집합을 포함한다. 각 블록(151)은 또한 블록(151)에 대한 순차적인 순서를 정의하기 위해 체인에서 이전에 생성된 블록(151)을 뒤로 가리키는 블록 포인터(155)를 포함한다. 블록체인(150)은 또한 작업 증명 프로세스에 의해 새로운 블록에 포함되기를 기다리는 유효한 트랜잭션의 풀(154)을 포함한다. 각 트랜잭션(152)는 트랜잭션 시퀀스에 대한 순서를 정의하기 위해 이전 트랜잭션에 대한 포인터를 다시 포함한다(트랜잭션(152)의 시퀀스는 분기가 허용됨을 유의한다). 블록의 체인(151)은 체인의 첫 번째 블록인 제네시스(genesis) 블록(Gb)(153)까지 거슬러 올라간다. 체인(150) 초반의 하나 이상의 원래 트랜잭션(152)는 선행 트랜잭션이 아닌 제네시스 블록(153)을 가리킨다.

주어진 당사자(103), 예를 들어 앨리스가 블록체인(150)에 포함될 새로운 트랜잭션(152j)을 전송하기를 원할 때, 그녀는 (자신의 클라이언트 애플리케이션(105)에서 지갑 기능을 사용하여) 관련 트랜잭션 프로토콜에 따라 새로운 트랜잭션을 공식화한다. 그런 다음 그녀는 클라이언트 애플리케이션(105)으로부터 자신이 연결된 하나 이상의 전달 노드(104F) 중 하나로 트랜잭션(152)을 전송한다. 예를 들어 이는 앨리스의 컴퓨터(102)에 가장 가깝거나 가장 잘 연결된 전달 노드(104F)일 수 있다. 임의의 주어진 노드(104)가 새로운 트랜잭션(152j)을 수신할 때, 노드 프로토콜 및 각자의 역할에 따라 이를 처리한다. 이는 새로 수신된 트랜잭션(152j)이 "유효하기" 위한 특정 조건을 충족하는지 여부를 먼저 확인하는 것을 포함하며, 그 예는 곧 더 자세히 논의될 것이다. 일부 트랜잭션 프로토콜에서, 유효성 검증을 위한 조건은 트랜잭션(152)에 포함된 스크립트에 의해 트랜잭션별로 구성할 수 있다. 대안적으로 조건은 단순히 노드 프로토콜의 내장 기능이거나, 스크립트 및 노드 프로토콜의 조합으로 정의될 수 있다.

새로 수신된 트랜잭션(152j)이 유효한 것으로 간주되는 테스트를 통과한 경우(즉, "검증된" 조건에서), 트랜잭션(152j)을 수신하는 임의의 저장 노드(104S)는 새로운 검증된 트랜잭션(152)을 해당 노드(104S)에서 유지되는 블록체인(150)의 사본 내의 풀(154)에 추가할 것이다. 또한, 트랜잭션(152j)을 수신하는 임의의 전달 노드(104F)는 검증된 트랜잭션(152)을 P2P 네트워크(106)의 하나 이상의 다른 노드(104)로 전파할 것이다. 각 전달 노드(104F)가 동일한 프로토콜을 적용하기 때문에, 트랜잭션(152j)이 유효하다고 가정하면, 이는 곧 전체 P2P 네트워크(106)에 전파될 것임을 의미한다.

하나 이상의 저장 노드(104)에서 유지되는 블록체인(150)의 사본에서 풀(154)에 일단 승인되면, 채굴자 노드(104M)는 새로운 트랜잭션(152)을 포함하는 풀(154)의 최신 버전에서 작업 증명 퍼즐을 풀기 위해 경쟁하기 시작할 것이다(다른 채굴자(104M)가 풀(154)의 이전 뷰에 기초하여 퍼즐을 풀고자 여전히 시도할 수 있지만, 누구든 먼저 도달한 사람이 다음 새로운 블록(151)이 끝나고 새로운 풀(154)이 시작되는 위치를 정의할 것이며, 결국 누군가가 앨리스의 트랜잭션(152j)을 포함하는 풀(154)의 일부에 대한 퍼즐을 풀게 될 것이다). 새로운 트랜잭션(152j)을 포함하는 풀(154)에 대한 작업 증명이 완료되면, 이는 변경 불가능하게 블록체인(150) 내의 블록(151) 중 하나의 일부가 된다. 각 트랜잭션(152)은 이전 트랜잭션에 대한 뒤로의 포인터를 포함하므로, 트랜잭션의 순서가 또한 변경 불가능하게 기록된다.

상이한 노드(104)는 주어진 트랜잭션의 상이한 인스턴스를 먼저 수신할 수 있고, 따라서 하나의 인스턴스가 블록(150)으로 채굴되기 전에 어느 인스턴스가 '유효'한지에 대한 충돌하는 뷰를 가질 수 있으며, 이 시점에서 모든 노드(104)는 채굴된 인스턴스가 유일한 유효한 인스턴스라는 데에 동의한다. 노드(104)가 하나의 인스턴스를 유효한 것으로 수락한 다음 제2 인스턴스가 블록체인(150)에 기록되었음을 발견하면 해당 노드(104)는 이를 수락해야 하고 최초로 수락한 채굴되지 않은 인스턴스를 폐기(즉, 무효로 처리)한다.

UTXO-기반 모델

도 2는 예시적인 트랜잭션 프로토콜을 도시한다. 이는 UTXO 기반 프로토콜의 예이다. 트랜잭션(152)(약칭 "Tx")은 블록체인(150)의 기본 데이터 구조이다(각 블록(151)은 하나 이상의 트랜잭션(152)을 포함함). 다음은 출력 기반 또는 "UTXO" 기반 프로토콜을 참조하여 설명될 것이다. 그러나 이것은 모든 가능한 실시예로 제한되지 않는다.

UTXO 기반 모델에서, 각 트랜잭션("Tx")(152)은 하나 이상의 입력(202) 및 하나 이상의 출력(203)을 포함하는 데이터 구조를 포함한다. 각 출력(203)은 다른 새로운 트랜잭션의 입력(202)에 대한 출처로서 사용될 수 있는(UTXO가 아직 리딤되지 않은 경우), 미지출 트랜잭션 출력(UTXO)을 포함할 수 있다. UTXO는 디지털 자산(가치 저장소)의 금액을 지정한다. 이는 또한 다른 정보와 함께, 트랜잭션이 발생한 트랜잭션 ID를 포함할 수 있다. 트랜잭션 데이터 구조는 또한 입력 필드(들)(202) 및 출력 필드(들)(203)의 크기의 표시자를 포함할 수 있는 헤더(201)를 포함할 수 있다. 헤더(201)는 또한 트랜잭션의 ID를 포함할 수 있다. 실시예에서 트랜잭션 ID는 트랜잭션 데이터의 해시이고(트랜잭션 ID 자체는 제외) 채굴자(104M)에게 제출된 원시 트랜잭션(152)의 헤더(201)에 저장된다.

앨리스(103a)가 문제의 디지털 자산의 금액을 밥(103b)에게 전달하는 트랜잭션(152j)을 생성하기를 원한다고 하자. 도 2에서 앨리스의 새로운 트랜잭션(152j)은 "Tx₁"로 표시된다. 이는 시퀀스 내의 선행 트랜잭션(152i)의 출력(203)에서 앨리스에게 잠긴 디지털 자산의 금액을 취하고, 이 중 적어도 일부를 밥에게 전달한다. 선행 트랜잭션(152i)은 도 2에서 "Tx₀"으로 라벨이 붙여진다. Tx₀ 및 Tx₁은 임의의 라벨일 뿐이다. Tx₀이 블록체인(151)의 첫 번째 트랜잭션이거나, Tx₁이 풀(154)의 바로 다음 트랜잭션이라는 것을 반드시 의미하지는 않는다. Tx₁은 앨리스에게 잠긴 미지출 출력(203)을 여전히 갖고 있는 임의의 선행(즉, 앞선) 트랜잭션을 뒤로 가리킬 수 있다.

선행 트랜잭션 Tx₀은 앨리스가 새로운 트랜잭션 Tx₁을 생성할 때, 또는 적어도 그녀가 그것을 네트워크(106)에 전송할 때 이미 유효성 검증되어 블록체인(150)에 포함되어 있을 수 있다. 이는 그 시간에 이미 블록(151) 중 하나에 포함되었거나, 풀(154)에서 여전히 대기 중일 수 있으며, 이 경우 곧 새로운 블록(151)에 포함될 것이다. 대안적으로 Tx₀ 및 Tx₁이 생성되어 네트워크(102)에 함께 전송되거나, 또는 노드 프로토콜이 "고아" 트랜잭션 버퍼링을 허용하는 경우 Tx₀이 Tx₁ 이후에 전송될 수 있다. 트랜잭션의 시퀀스의 맥락에서 본원에서 사용되는 "선행" 및 "후속"이라는 용어는 (트랜잭션이 다른 트랜잭션을 뒤로 가리키고, 이와 같이 계속되는) 트랜잭션 내에 지정된 트랜잭션 포인터에 의해 정의된 시퀀스 내의 트랜잭션 순서를 지칭한다. 이는 "선행자(predecessor)"와 "후행자(successor)", 또는 "앞선(antecedent)"과 "후위의(descendant)", "부모"와 "자식" 등으로 동등하게 대체될 수 있다. 이는 그것들이 생성되고, 네트워크(106)로 전송되거나, 임의의 주어진 노드(104)에 도달하는 순서를 반드시 의미하지는 않는다. 그럼에도 불구하고, 선행 트랜잭션(앞선 트랜잭션 또는 "부모")을 가리키는 후속 트랜잭션(후위의 트랜잭션 또는 "자식")은 부모 트랜잭션이 유효성 검증될 때까지 그리고 유효성 검증되지 않는 한 유효성 검증되지 않는다. 부모보다 먼저 노드(104)에 도착하는 자식은 고아로 간주된다. 이는 노드 프로토콜 및/또는 채굴자 행위에 따라 삭제되거나 부모를 기다리기 위해 특정 시간 동안 버퍼링될 수 있다.

선행 트랜잭션 Tx₀의 하나 이상의 출력(203) 중 하나는, 본원에서 UTXO₀으로 라벨이 붙여지는 특정 UTXO를 포함한다. 각 UTXO는 UTXO가 나타내는 디지털 자산의 금액을 지정하는 값과 후속 트랜잭션이 유효성 검증되고 따라서 UTXO가 성공적으로 리딤되기 위하여 후속 트랜잭션의 입력(202)에서 잠금 해제 스크립트가 만족해야 하는 조건을 정의하는 잠금 스크립트로 구성된다. 일반적으로 잠금 스크립트는 특정 당사자(그것이 포함된 트랜잭션의 수혜자)에게 금액을 잠근다. 즉, 잠금 스크립트는, 일반적으로 후속 트랜잭션의 입력 내의 잠금 해제 스크립트가 선행 트랜잭션이 잠겨 있는 당사자의 암호화 서명을 포함하는 조건을 포함하는 잠금 해제 조건을 정의한다.

잠금 스크립트(일명 scriptPubKey)는 노드 프로토콜에서 인식하는 도메인 특정 언어로 작성된 코드이다. 이러한 언어의 특정 예를 "스크립트(Script)"(대문자 S)라고 한다. 잠금 스크립트는 트랜잭션 출력(203)을 사용하는 데 필요한 정보, 예를 들어 앨리스의 서명 요구 사항을 지정한다. 잠금 해제 스크립트는 트랜잭션 출력에 나타난다. 잠금 해제 스크립트(일명 scriptSig)는 잠금 스크립트 기준을 충족하는 데 필요한 정보를 제공하는 도메인 특정 언어로 작성된 코드이다. 예를 들어, 이는 밥의 서명을 포함할 수 있다. 잠금 해제 스크립트는 트랜잭션의 입력(202)에 나타난다.

따라서 도시된 예에서, Tx₀의 출력(203)에 있는 UTXO₀은 UTXO₀을 리딤하기 위해(엄밀히 말하자면, UTXO₀을 리딤하고자 시도하는 후속 트랜잭션이 유효하기 위해) 앨리스의 서명 Sig P_A를 요구하는 잠금 스크립트 [Checksig P_A]를 포함한다. [Checksig P_A]는 앨리스의 공개-개인 키 쌍의 공개 키 P_A를 포함한다. Tx₁의 입력(202)은 Tx₁을 뒤로 가리키는 포인터를 포함한다(예를 들어, 실시예에서 전체 트랜잭션 Tx₀의 해시인 트랜잭션 ID TxID₀에 의해). Tx₁의 입력(202)은 Tx₀의 다른 가능한 출력들 사이에서 이를 식별하기 위해 Tx₀ 내에서 UTXO₀을 식별하는 색인을 포함한다. Tx₁의 입력(202)은 앨리스의 암호화 서명을 포함하는 잠금 해제 스크립트 <Sig P_A>를 더 포함하며, 이는 앨리스가 키 쌍으로부터 자신의 개인 키를 데이터의 미리 정의된 부분(때때로 암호화에서 "메시지"라고 함)에 적용하여 생성된다. 유효한 서명을 제공하기 위해 앨리스가 서명해야 하는 데이터(또는 "메시지")는 잠금 스크립트, 노드 프로토콜 또는 이들의 조합에 의해 정의될 수 있다.

새로운 트랜잭션 Tx₁이 노드(104)에 도달하면, 노드는 노드 프로토콜을 적용한다. 이는 잠금 스크립트와 잠금 해제 스크립트를 함께 실행하여 잠금 해제 스크립트가 잠금 스크립트에 정의된 조건(이 조건은 하나 이상의 기준을 포함할 수 있음)을 만족하는지 여부를 확인하는 것을 포함한다. 실시예에서 이것은 두 개의 스크립트를 연결하는 것을 포함한다:

<Sig P _A > <P _A > || [Checksig P _A ]

여기에서 "||"는 연결을 나타내고 "<...>"는 데이터를 스택에 배치하는 것을 의미하고, "[…]"는 잠금 해제 스크립트(이 예에서는 스택 기반 언어)로 구성된 함수이다. 스크립트를 연결하는 대신, 동등하게 스크립트는 공통 스택을 사용하여 차례로 실행될 수 있다. 어느 쪽이든, 함께 실행될 때, 스크립트는 Tx₀의 출력에 있는 잠금 스크립트에 포함된 앨리스의 공개 키 P_A를 사용하여 Tx₁의 입력에 있는 잠금 스크립트에 예상되는 데이터 부분에 서명하는 앨리스의 서명이 포함되어 있는지 인증한다. 이 인증을 수행하기 위하여 예상되는 데이터 부분 자체("메시지") 또한 Tx₀에 포함되어야 한다. 실시예에서 서명된 데이터는 Tx₀의 전체를 포함한다(따라서 데이터의 서명된 부분을 지정하는 별도의 요소는 책임 없이 포함되어야 하는데, 이미 본질적으로 존재하기 때문이다).

공개-개인 암호화에 의한 인증의 세부 사항은 당업자에게 친숙할 것이다. 기본적으로, 앨리스가 자신의 개인 키로 메시지를 암호화하여 메시지에 서명한 경우, 앨리스의 공개 키와 일반 메시지(암호화되지 않은 메시지)가 주어지면, 노드(104)와 같은 다른 엔티티는 암호화된 버전의 메시지가 앨리스가 서명한 것이라고 인증할 수 있다. 서명은 일반적으로 메시지를 해시하고, 해시에 서명하고, 이를 메시지의 일반 버전에 서명으로 태그를 지정하여, 공개 키 소유자가 서명을 인증할 수 있도록 하는 것을 포함한다. 따라서 특정 데이터 조각 또는 트랜잭션의 일부 등에 서명하는 것에 대한 본원에서의 모든 참조는 실시예에서 해당 데이터 조각 또는 트랜잭션의 일부의 해시에 서명하는 것을 의미할 수 있음에 유의한다.

Tx₁의 잠금 해제 스크립트가 Tx₀의 잠금 스크립트에 지정된 하나 이상의 조건을 충족하는 경우(따라서 표시된 예에서 앨리스의 서명이 Tx₁에 제공되고 인증된 경우), 노드(104)는 Tx₁이 유효한 것으로 간주한다. 그것이 저장 노드(104S)라면, 이는 작업 증명을 기다리는 트랜잭션의 풀(154)에 추가할 것임을 의미한다. 그것이 전달 노드(104F)라면, 트랜잭션 Tx₁을 네트워크(106)의 하나 이상의 다른 노드(104)로 전달하여, 네트워크를 통해 전파될 것이다. Tx₁이 유효성 검증되고 블록체인(150)에 포함되면, Tx₀의 UTXO₀이 지출된 것으로 정의된다. Tx₁은 미지출 트랜잭션 출력(203)을 지출하는 경우에만 유효할 수 있음을 유의한다. 다른 트랜잭션(152)에서 이미 지출한 출력을 지출하려고 시도하는 경우, 다른 모든 조건이 충족되더라도 Tx₁은 유효하지 않다. 따라서 노드(104)는 또한 선행 트랜잭션 Tx₀에서 참조된 UTXO가 이미 지출되었는지(다른 유효한 트랜잭션에 대한 유효한 입력을 이미 형성했는지) 확인할 필요가 있다. 이것이 블록체인(150)이 트랜잭션(152)에 정의된 순서를 부과하는 것이 중요한 이유 중 하나이다. 실제로 주어진 노드(104)는 트랜잭션(152)이 지출된 UTXO(203)를 표시하는 별도의 데이터베이스를 유지할 수 있지만, 궁극적으로 UTXO가 지출되었는지 여부를 결정하는 것은 블록체인(150) 내의 다른 유효한 트랜잭션에 대한 유효한 입력을 이미 형성했는지의 여부이다.

주어진 트랜잭션(152)의 모든 출력(203)에 지정된 총 금액이 모든 입력(202)이 가리키는 총 금액보다 큰 경우, 이는 대부분의 트랜잭션 모델에서 무효에 대한 다른 근거가 된다. 따라서 이러한 트랜잭션은 전파되거나 블록(151)으로 채굴되지 않는다.

UTXO 기반 트랜잭션 모델에서, 주어진 UTXO는 전체로서 지출되어야 한다는 점을 유의한다. UTXO에 정의된 금액의 일부가 지출되는 한편 다른 일부가 지출되도록 "뒤에 남겨둘" 수 없다. 그러나 UTXO의 금액은 다음 트랜잭션의 다수의 출력 사이에 분할될 수 있다. 예를 들어 Tx₀의 UTXO₀에 정의된 금액은 Tx₁의 다수의 UTXO 사이에 분할될 수 있다. 따라서 앨리스가 UTXO₀에 정의된 모든 금액을 밥에게 주기를 원하지 않으면, 나머지를 사용하여 Tx₁의 제2 출력에서 자신에게 잔돈을 주거나, 다른 당사자에게 지불할 수 있다.

실제로 앨리스는 또한 일반적으로 승리한 채굴자에 대한 수수료를 포함해야 하는데, 왜냐하면 최근에는 생성 트랜잭션의 보상만으로는 일반적으로 채굴 동기를 부여하기에 충분하지 않기 때문이다. 앨리스가 채굴자에 대한 수수료를 포함하지 않으면, Tx₀은 채굴자 노드(104M)에 의해 거부될 가능성이 있으므로, 기술적으로 유효하지만, 여전히 전파되지 않고 블록체인(150)에 포함되지 않는다(채굴자 프로토콜은 채굴자(104M)가 원하지 않는 경우 트랜잭션(152)을 수락하도록 강요하지 않는다). 일부 프로토콜에서, 채굴 수수료는 그 자체의 별도 출력(203)을 필요로 하지 않는다(즉, 별도의 UTXO가 필요하지 않음). 대신 주어진 트랜잭션(152)의 입력(들)(202)이 가리키는 총 금액과 출력(들)(203)에 지정된 총 금액 사이의 임의의 차이가 자동으로 승리한 채굴자(104)에게 제공된다. 예를 들어, UTXO₀에 대한 포인터가 Tx₁에 대한 유일한 입력이고 Tx₁에는 하나의 출력 UTXO₁만 있다고 가정한다. UTXO₀에 지정된 디지털 자산의 금액이 UTXO₁에 지정된 금액보다 크면, 차액은 자동으로 승리한 채굴자(104M)에게 넘어간다. 그러나 대안적으로 또는 추가적으로, 채굴자 수수료가 트랜잭션(152)의 UTXO(203) 중 그 자체의 UTXO 중 하나에 명시적으로 지정될 수 있다는 것이 반드시 배제되는 것은 아니다.

앨리스와 밥의 디지털 자산은 블록체인(150)의 임의의 위치의 임의의 트랜잭션(152)에 잠겨 있는 미지출 UTXO로 구성된다. 따라서 일반적으로, 주어진 당사자(103)의 자산은 블록체인(150) 전체에 걸쳐 다양한 트랜잭션(152)의 UTXO에 걸쳐 흩어져 있다. 주어진 당사자(103)의 총 잔고를 정의하는 블록체인(150)의 어떤 곳에 저장된 하나의 숫자는 없다. 클라이언트 애플리케이션(105)에서 지갑 기능의 역할은 각 당사자에게 잠겨 있으며 다른 전방 트랜잭션에서 아직 지출되지 않은 모든 다양한 UTXO의 값을 함께 대조하는 것이다. 이는 저장 노드(104S) 중 임의의 것, 예를 들어, 각 당사자의 컴퓨터 장비(102)에 가장 가깝거나 가장 잘 연결된 저장 노드(104S) 에 저장된 블록체인(150)의 사본을 질의함으로써 이를 수행할 수 있다.

스크립트 코드는 종종 도식적으로 표현됨(즉, 정확한 언어가 아님)을 유의한다. 예를 들어, [Checksig PA]를 작성하여 [Checksig PA] = OP_DUP OP_HASH160 <H(PA)> OP_EQUALVERIFY OP_CHECKSIG를 의미할 수 있다. "OP_..."는 스크립트 언어의 특정 작업코드(opcode)를 나타낸다. OP_CHECKSIG("Checksig"라고도 함)는 두 개의 입력(서명 및 공개 키)을 사용하고 타원 곡선 디지털 서명 알고리즘(ECDSA)을 사용하여 서명의 유효성을 검증하는 스크립트 작업코드이다. 런타임에서, 모든 서명('sig')의 발생은 스크립트에서 제거되지만 해시 퍼즐과 같은 추가 요구 사항은 'sig' 입력으로 검증된 트랜잭션에 남아 있다. 다른 예로서, OP_RETURN은 트랜잭션 내에 메타데이터를 저장할 수 있는 트랜잭션의 지출 불가능한 출력을 생성하기 위한 스크립트 언어의 작업코드이며, 이에 따라 메타데이터를 블록체인(150)에 불변으로 기록할 수 있다. 예를 들어, 메타데이터는 블록체인에 저장하려는 문서를 포함할 수 있다.

서명 P_A는 디지털 서명이다. 실시예에서 이것은 타원 곡선 secp256k1을 사용하는 ECDSA에 기초한다. 디지털 서명은 특정 데이터 조각에 서명한다. 실시예에서, 주어진 트랜잭션에 대해 서명은 트랜잭션 입력의 일부와 트랜잭션 출력의 전부 또는 일부에 서명할 것이다. 서명하는 출력의 특정 부분은 SIGHASH 플래그에 따라 다르다. SIGHASH 플래그는 서명된 출력을 선택하기 위해 서명 끝에 포함된 4바이트 코드이다(따라서 서명 시에 고정된다).

잠금 스크립트는 해당 트랜잭션이 잠겨 있는 당사자의 공개 키를 포함한다는 사실을 지칭하여 "scriptPubKey"라고도 한다. 잠금 해제 스크립트는 대응하는 서명을 제공한다는 사실을 지칭하여 "scriptSig"라고도 한다. 그러나, 더 일반적으로 UTXO가 리딤되기 위한 조건이 서명 인증을 포함하는 것이 블록체인(150)의 모든 애플리케이션에서 필수적인 것은 아니다. 더 일반적으로 스크립팅 언어는 하나 이상의 조건을 정의하는 데 사용할 수 있다. 따라서 보다 일반적인 용어 "잠금 스크립트" 및 "잠금 해제 스크립트"가 선호될 수 있다.

선택적 사이드 채널

도 3은 블록체인(150)을 구현하는 다른 시스템(100)을 도시한다. 시스템(100)은 추가적인 통신 기능이 포함된다는 점을 제외하고는 도 1과 관련하여 설명된 것과 실질적으로 동일하다. 앨리스와 밥의 컴퓨터 장비(102a, 120b) 각각의 클라이언트 애플리케이션은 각각 추가 통신 기능을 포함한다. 즉, (일방 당사자 또는 제3자의 유인으로) 앨리스(103a)가 밥(103b)과 별도의 사이드 채널(301)을 설정할 수 있다. 사이드 채널(301)은 P2P 네트워크와 별도로 데이터 교환을 가능하게 한다. 이러한 통신을 때때로 "오프체인(off-chain)"으로 지칭한다. 예를 들어, 이는 트랜잭션 당사자 중 하나가 네트워크(106)로 브로드캐스팅하기로 선택할 때까지, (아직) 트랜잭션이 네트워크 P2P(106)에 게시되거나 체인(150)으로 진행되지 않고 앨리스와 밥 사이의 트랜잭션(152)을 교환하는 데 사용될 수 있다. 대안적으로 또는 추가적으로, 사이드 채널(301)은 키, 협상된 금액 또는 조건, 데이터 콘텐츠 등과 같은 임의의 다른 트랜잭션 관련 데이터를 교환하는 데 사용될 수 있다.

사이드 채널(301)은 P2P 오버레이 네트워크(106)와 동일한 패킷 교환 네트워크(101)를 통해 설정될 수 있다. 대안적으로 또는 추가적으로, 사이드 채널(301)은 모바일 셀룰러 네트워크, 또는 로컬 무선 네트워크와 같은 로컬 영역 네트워크, 또는 앨리스와 밥의 디바이스(1021, 102b) 사이의 직접 유선 또는 무선 링크와 같은 다른 네트워크를 통해 설정될 수 있다. 일반적으로, 본원의 임의의 곳에서 언급되는 사이드 채널(301)은 "오프체인", 즉 P2P 오버레이 네트워크(106)와 별도로 데이터를 교환하기 위한 하나 이상의 네트워킹 기술 또는 통신 매체를 통한 하나 이상의 링크를 포함할 수 있다. 하나보다 많은 링크가 사용되는 경우, 오프체인 링크의 번들 또는 컬렉션 전체를 사이드 채널(301)로 지칭할 수 있다. 따라서 앨리스와 밥이 사이드 채널(301)로 특정 조각의 정보 또는 데이터를 교환하는 경우, 이는 이러한 모든 데이터 조각이 정확히 동일한 링크 또는 심지어 동일한 유형의 네트워크를 통해 전송되어야 함을 반드시 의미하지는 않는다.

노드 소프트웨어

도 4는 UTXO 또는 출력 기반 모델의 예에서 P2P 네트워크(106)의 각 노드(104)에서 실행되는 노드 소프트웨어(400)의 예를 도시한다. 노드 소프트웨어(400)는 프로토콜 엔진(401), 스크립트 엔진(402), 스택(403), 애플리케이션 레벨 의사결정 엔진(404), 및 하나 이상의 블록체인 관련 기능 모듈(405) 세트를 포함한다. 임의의 주어진 노드(104)에서, 이들은 채굴 모듈(405M), 전달 모듈(405F) 및 저장 모듈(405S) 중 임의의 하나, 둘 또는 세 개 모두(노드의 역할에 따라 다름)를 포함할 수 있다. 프로토콜 엔진(401)은 트랜잭션(152)의 상이한 필드를 인식하고 노드 프로토콜에 따라 처리하도록 구성된다. 트랜잭션(152m)(Tx_m)이 다른 선행 트랜잭션(152m-1)(Tx_m-1)의 출력(예를 들어, UTXO)을 가리키는 입력을 가지고 수신되면, 프로토콜 엔진(401)은 Tx_m의 잠금 해제 스크립트를 식별하고 이를 스크립트 엔진(402)에 전달한다. 프로토콜 엔진(401)은 또한 Tx_m의 입력 내의 포인터에 기초하여 Tx_m-1를 식별하고 검색한다. Tx_m-1가 아직 블록체인(150)에 없으면 보류 중인 트랜잭션의 각자의 노드 자체 풀(154)로부터, 또는 Tx_m-1이 이미 블록체인(150)에 있는 경우 각자의 노드 또는 다른 노드(104)에 저장된 블록체인(150) 내의 블록(151)의 복사본으로부터 Tx_m-1를 검색할 수 있다. 어느 쪽이든, 스크립트 엔진(401)은 Tx_m-1의 가리켜진 출력 내에서 잠금 스크립트를 식별하고 이를 스크립트 엔진(402)으로 전달한다.

따라서, 스크립트 엔진(402)은 Tx_m-1의 잠금 스크립트 및 Tx_m의 대응하는 입력으로부터의 잠금 해제 스크립트를 갖는다. 예를 들어 Tx₁ 및 Tx₂가 도 4에 예시되어 있지만, Tx₀ 및 Tx₁ 등과 같은 임의의 트랜잭션 쌍에 동일하게 적용될 수 있다. 스크립트 엔진(402)은 이전에 논의된 바와 같이 두 개의 스크립트를 실행하며, 이는 사용되는 스택 기반 스크립팅 언어(예를 들어, Script)에 따라 스택(403)에 데이터를 배치하고 이로부터 데이터를 검색하는 것을 포함할 것이다.

스크립트를 함께 실행함으로써, 스크립트 엔진(402)은 잠금 해제 스크립트가 잠금 스크립트에 정의된 하나 이상의 기준을 충족하는지 여부를 결정한다 - 즉, 잠금 스크립트가 포함된 출력을 "잠금 해제"하는가 스크립트 엔진(402)은 이 결정의 결과를 프로토콜 엔진(401)에 반환한다. 잠금 해제 스크립트가 대응하는 잠금 스크립트에 지정된 하나 이상의 기준을 충족한다고 스크립트 엔진(402)이 결정하면, 결과 "참"을 반환한다. 그렇지 않으면 결과 "거짓"을 반환한다.

출력 기반 모델에서 스크립트 엔진(402)의 결과 "참"은 트랜잭션의 유효성을 위한 조건 중 하나이다. 일반적으로 또한 충족되어야 하는 프로토콜 엔진(401)에 의해 평가되는 하나 이상의 추가 프로토콜 수준 조건이 있다. 예컨대 Tx_m의 출력(들)에 지정된 디지털 자산의 총 금액이 그 입력들이 가리키는 총 금액을 초과하지 않고, Tx_m-1의 가리켜진 출력이 다른 유효한 트랜잭션에 의해 이미 지출되지 않아야 한다. 프로토콜 엔진(401)은 하나 이상의 프로토콜 레벨 조건과 함께 스크립트 엔진(402)의 결과를 평가하고, 모두 참인 경우에만 트랜잭션 Tx_m을 유효성 검증한다. 프로토콜 엔진(401)은 트랜잭션이 유효한지 여부에 대한 표시를 애플리케이션 레벨 의사결정 엔진(404)에 출력한다. Tx_m이 실제로 유효성 검증된다는 조건에서만, 의사결정 엔진(404)은 채굴 모듈(405M) 및 전달 모듈(405F) 중 하나 또는 둘 모두가 Tx_m에 대해 각자의 블록체인 관련 기능을 수행하도록 제어하게끔 선택할 수 있다. 이는 채굴 모듈(405M)이 블록(151)으로의 채굴을 위해 노드의 각자의 풀(154)에 Tx_m을 추가하는 것 및/또는 전달 모듈(405F)이 P2P 네트워크(106)의 다른 노드(104)에 Tx_m을 전달하는 것을 포함할 수 있다. 그러나 실시예에서, 의사결정 엔진(404)이 무효 트랜잭션을 전달하거나 채굴하도록 선택하지 않을 것이지만, 반대로 이것이 단순히 유효하기 때문에 유효한 트랜잭션의 채굴 또는 전달을 촉발(trigger)해야 한다는 것을 반드시 의미하지는 않는다는 점을 유의한다. 선택적으로, 실시예에서 의사결정 엔진(404)은 이러한 기능 중 하나 또는 둘 다를 촉발하기 전에 하나 이상의 추가 조건을 적용할 수 있다. 예를 들어 노드가 채굴 노드(104M)인 경우, 의사결정 엔진은 트랜잭션이 유효하고 채굴 수수료가 충분히 남아 있다는 두 가지 모두의 조건에서만 트랜잭션을 채굴하도록 선택할 수 있다.

또한 본원에서 "참" 및 "거짓"이라는 용어는 단일 이진 숫자(비트)의 형태로 표현되는 결과를 반환하는 것으로 반드시 제한되지는 않지만, 이는 확실히 하나의 가능한 구현이다. 더 일반적으로, "참"은 성공 또는 긍정적인 결과를 나타내는 모든 상태를 지칭할 수 있고 "거짓"은 실패 또는 비긍정적인 결과를 나타내는 임의의 상태를 지칭할 수 있다. 예를 들어, 계정 기반 모델(도 4에 도시되지 않음)에서, "참"의 결과는 노드(104)에 의한 서명의 묵시적, 프로토콜 수준의 유효성 검증과 추가적인 스마트 계약의 긍정적인 결과의 조합에 의해 나타날 수 있다(두 개별 결과가 모두 참인 경우 전체 결과가 참 신호인 것으로 간주된다).

예시적인 트랜잭션 집합

도 5는 본원에 개시된 실시예에 따른 사용을 위한 트랜잭션(152) 집합을 도시한다. 집합은 제0 트랜잭션(Tx₀), 제1 트랜잭션(Tx₁), 및 제2 트랜잭션(Tx₂)을 포함한다. "제0", "제1" 및 "제2"는 단지 편리한 라벨이다. 이들은 이러한 트랜잭션이 블록(151) 또는 블록체인(150)에서 바로 이어지는 차례로 배치될 것임을 반드시 의미하지 않으며, 제0 트랜잭션이 블록(151) 또는 블록체인(150) 내의 초기 트랜잭션이라는 것을 의미하지도 않는다. 또한 이러한 라벨이 그 트랜잭션이 네트워크(106)로 전송되는 순서에 관해 어느 것도 의미하지 않는다. 이들은 하나의 트랜잭션의 출력이 다음 트랜잭션의 입력에 의해 가리켜진다는 점에서 논리적인 연속만을 지칭한다. 일부 시스템에서는 자식 이후에 부모를 네트워크(106)로 전송하는 것이 가능하다는 것을 기억한다(이 경우 "고아" 자식은 부모가 도착하기를 기다리는 동안 하나 이상의 노드(104)에서 일정 기간 동안 버퍼링된다).

제0 트랜잭션(Tx₀)은 앨리스(103a)에게 잠긴 디지털 자산의 금액의 출처 역할을 한다는 점에서, 현재의 목적을 위한 출처 트랜잭션(source transaction)으로 지칭될 수도 있다. 제1 트랜잭션(Tx₁)은 또한 본 목적을 위해 도전 트랜잭션(challenge transaction) 또는 퍼즐 트랜잭션(puzzle transaction)으로 지칭될 수 있다. 이는 r-퍼즐에 대한 해를 제공하는 제2 트랜잭션(Tx₂)에 따라 출처 트랜잭션(Tx₀)으로부터 디지털 자산의 금액을 조건부로 전달하는 중개자 역할을 한다. 제2 트랜잭션(Tx₂)은 제1 트랜잭션(Tx₁)에 설정된 r-퍼즐에 대한 해를 제공하고 결과 지불을 증명자(또는 잠재적으로 증명자가 대리하는 수혜자)에게 잠그는 트랜잭션이므로, 증명 트랜잭션(proving transaction) 또는 지출 트랜잭션(spending transaction)으로 또한 지칭될 수 있다. 실시예는 증명자(제2 당사자)가 우연히 밥인 경우를 예로 설명될 수 있지만, 나중에 논의를 기반으로 이해하게 될 바와 같이, r-퍼즐은 실제로 r-퍼즐을 해결하는 유효한 서명을 제공하는 한 신원에 관계없이 임의의 제2 당사자가 증명자가 되도록 허용한다.

도 5에 도시된 바와 같이, 출처 트랜잭션(Tx₀)은 디지털 자산의 금액을 지정하고 앨리스(103a)에 대해 이 출력을 잠그는 잠금 스크립트를 더 포함하는 적어도 하나의 출력(203₀)(예를 들어, Tx₀의 출력 0)을 포함한다. 이것은 출처 트랜잭션(Tx₀)의 잠금 스크립트가 충족되어야 하는 최소한 하나의 조건을 요구한다는 것을 의미하며, 이는 출력을 잠금 해제(및 따라서 디지털 자산의 금액을 리딤)하고자 시도하는 임의의 트랜잭션의 입력은 그 잠금 해제 스크립트에서 앨리스의 암호화 서명(즉, 앨리스의 공개 키 사용)을 반드시 포함하여야 한다는 것이다. 이런 의미에서 Tx₀의 출력에 정의된 금액은 앨리스가 소유하고 있다고 말할 수 있다. 출력은 UTXO로 지칭될 수 있다. (Tx₀의 총 출력(들)을 커버하기에 충분한 한) Tx₀의 입력이 뒤로 가리키는 선행 트랜잭션의 출력은 현재의 목적을 위해 특별히 중요하지 않다.

본 사례에서 출처 트랜잭션(Tx₀)의 출력을 잠금 해제하는 트랜잭션은 제1 트랜잭션(Tx₁)(도전 트랜잭션)이다. 따라서 Tx₁은 Tx₀의 관련 출력(예시된 예에서 Tx₀의 출력 0)에 대한 포인터를 포함하고, 최소한 앨리스의 서명을 요구하는, 해당 출력의 잠금 스크립트에 정의된 조건에 따른 Tx₀의 가리켜진 출력을 잠금 해제하도록 구성된 잠금 해제 스크립트를 더 포함하는 적어도 하나의 입력(202₁)(예를 들어, Tx₁의 입력 0)을 가진다. Tx₁의 일부에 서명하려면 Tx₀의 잠금 스크립트에 의해 앨리스에게 필요한 서명이 필요하다. 일부 프로토콜에서 서명해야 하는 Tx₁ 부분은 Tx₁의 잠금 해제 스크립트에 정의된 설정일 수 있다. 예를 들어 이것은 서명에 추가되는 1바이트인 SIGHASH 플래그에 의해 설정될 수 있으므로, 데이터 측면에서 잠금 해제 스크립트는 <Sig P_A><sighashflag> <P_A>로 나타난다. 대안적으로 서명해야 하는 부분은 Tx₁의 고정 또는 기본 부분일 수 있다. 어느 쪽이든, 서명할 부분은 일반적으로 잠금 해제 스크립트 자체를 제외하고, Tx₁의 입력 중 일부 또는 전체를 제외할 수 있다. 그러나 Tx₁의 서명된 부분에는 적어도 r-퍼즐을 포함하는 출력 203₁이 포함된다(아래 참조, 이 예에서 Tx₁의 출력 0).

제1 트랜잭션(Tx₁)은 적어도 하나의 출력(203₁)(예를 들어, Tx₁의 출력 0이며, 다시 출력은 UTXO로 지칭될 수 있음)을 갖는다. 제1 트랜잭션(Tx₁)의 출력은 어느 당사자에게도 잠겨있지 않다. 이는 Tx₀과 마찬가지로 앞으로 전달할 디지털 자산의 금액을 지정하는 하나 이상의 출력(예를 들어, Tx₁의 출력 0)을 가지며, 해당 출력을 잠금 해제하여 이 금액을 리딤하는 데 필요한 것을 정의하는 잠금 스크립트를 추가로 포함한다. 그러나, 이 잠금 스크립트는 r-퍼즐에 대한 해를 제공하는 임의의 당사자가 출력을 잠금 해제하도록 허용한다.

제2 트랜잭션(지출 트랜잭션)(Tx₂)은 Tx₁의 위에서 언급한 출력(도시된 예에서 Tx₁의 출력 0)에 대한 포인터를 포함하고, 또한 Tx₁의 잠금 스크립트에 정의된 잠금 해제 조건의 하나 이상의 요구 사항을 충족하는 것에 기초하여 Tx₁의 상기 출력을 잠금 해제하도록 구성된 잠금 해제 스크립트를 포함하는 적어도 하나의 입력(202₂)(예를 들어, Tx₂의 입력 0)을 갖는다. 본원에 개시된 실시예에 따르면, 잠금 해제 조건은 대응하는 잠금 해제 스크립트가 r-퍼즐에 대한 해를 포함한다는 요구사항을 적어도 포함한다. r-퍼즐은 타원 곡선 암호화(ECC) 서명의 r-부분에 기초한 Tx₁의 잠금 스크립트에 정의된 도전을 포함하며, 이는 Tx₂의 잠금 해제 스크립트에서 서명(또는 적어도 그것의 s-부분)을 포함하는 임의의 당사자(이 경우 밥)에 의해 충족될 수 있다. Tx₀의 잠금 스크립트와 달리, r-도전(즉, r-퍼즐)을 충족하는 유효한 서명인 한, Tx₁의 잠금 조건을 잠금 해제하기 위하여 임의의 당사자의 서명이 사용될 수 있음을 유의한다. 이에 대한 예는 곧 더 자세히 논의될 것이다. 밥이 여기에서 증명자 또는 제2 당사자의 예로 간단히 선택되지만, 실제로 r-퍼즐은 임의의 제2 당사자, 예를 들어, 찰리, 도라, 에제키엘 등이 증명자가 될 수 있도록 허용한다. 일부 실시예에서, Tx₁의 잠금 해제 조건은 또한 하나 이상의 추가 조건에 대해 조건부로 만들어질 수 있으며, 예를 들어 앨리스의 서명이 Tx₂의 잠금 해제 스크립트에도 포함되도록 요구할 수 있다.

제2 트랜잭션(Tx₂)은 밥에게 전달할 디지털 자산의 금액을 지정하는 적어도 하나의 출력(202₂)(예를 들어, Tx₂의 출력 0)과 이를 밥에게 잠그는 잠금 스크립트(즉, 지출하기 위해서는 잠금 해제 스크립트에서 밥의 서명을 포함하는 추가 트랜잭션이 필요함)를 가지고 있다. 이러한 의미에서 대상 트랜잭션(Tx₂)의 출력은 밥이 소유하고 있다고 말할 수 있다. 이 출력은 다시 UTXO로 지칭될 수 있다.

증명자의 서명(예를 들어, 밥인 경우 Sig P_B)으로 서명된 Tx₂ 부분은 최소한 이 출력 203₂, 즉 증명자에게 지불을 잠그는 출력(이 예에서는 Tx₂의 출력 0)을 포함할 것이다.

실시예에서, Tx₁의 출력(203₁)에 있는 잠금 스크립트가 출력을 잠금 해제하기 위한 여러 대안적인 조건, 예를 들어 여러 대안적인 r-퍼즐을 정의할 수 있다. 이 경우 Tx₂의 입력(202₂)에 있는 잠금 해제 스크립트는 대안적인 잠금 해제 조건 중 임의의 하나를 충족하는 경우 Tx₁의 출력을 잠금 해제한다.

제0(즉, 출처) 트랜잭션(Tx₀)은 앨리스, 증명자(예를 들어, 밥) 또는 제3자가 생성할 수 있다. 일반적으로 앨리스가 Tx₀의 입력에 정의된 금액을 획득한 선행 당사자의 서명을 필요로 한다. 이는 앨리스, 밥, 선행 당사자 또는 다른 제3자에 의해 네트워크(106)로 전송될 수 있다.

제1 트랜잭션(즉, 도전 트랜잭션)(Tx₁) 또한 앨리스, 증명자(예를 들어, 밥) 또는 제3자에 의해 생성될 수 있다. 실시예에서 앨리스의 서명이 필요하기 때문에, 앨리스에 의해 생성될 수 있다. 대안적으로 밥 또는 제3자가 템플릿으로 생성한 다음 서명을 위해 앨리스에게 전송, 예를 들어 사이드 채널(301)을 통해 전송할 수 있다. 그런 다음 앨리스는 서명된 트랜잭션을 스스로 네트워크(106)로 전송하거나, 밥 또는 제3자가 네트워크(106)로 전달할 수 있도록 이를 밥 또는 제3자에게 전송하거나, 또는 단순히 자신의 서명을 밥 또는 제3자에게 전송하여 서명한 Tx₁로 조합하고 네트워크(106)에 전달하도록 할 수 있다. Tx₁을 네트워크(106)로 전송하기 전에 임의의 오프체인 교환이 사이드 채널(301)을 통해 수행될 수 있다.

제2 트랜잭션(즉, 증명 또는 지출 트랜잭션)(Tx₂)은 앨리스, 증명자(예를 들어, 밥) 또는 제3자에 의해 생성될 수 있다. 제1 버전은 증명자의 서명 및/또는 데이터가 필요하므로, 밥이 생성할 수 있다. 대안적으로 앨리스 또는 제3자가 템플릿으로 생성한 다음 밥에게 서명하도록 전송, 예를 들어, 사이드 채널(301)을 통해 밥에게 전송할 수 있다. 그런 다음 밥은 서명된 트랜잭션을 네트워크(106)에 직접 전송하거나, 앨리스 또는 제3자가 네트워크(106)로 전달하도록 이를 전송하거나, 또는 자신의 서명을 단순히 앨리스 또는 제3자에게 전송하여 서명한 Tx₂로 조합하고 네트워크에 전달하도록 할 수 있다.

트랜잭션의 상이한 요소가 생성되고 조합될 수 있는 다양한 위치와 이것이 P2P 네트워크(106)의 최종 목적지로 직접 또는 대리로 전송되는 다양한 방법이 있음을 이해할 것이다. 개시된 기술은 이러한 측면에서 제한되지 않는다.

또한 본원에서 "앨리스에 의해", "밥에 의해" 및 "제3자에 의해"와 같은 문구는 각각 "앨리스(103a)의 컴퓨터 장비(102a)에 의해", "밥(103b)의 컴퓨터 장비(102b)에 의해" 및 "제3자의 컴퓨터 장비에 의해"의 약어로 사용될 수 있음을 이해할 것이다. 또한, 주어진 당사자의 장비는 해당 당사자가 사용하는 하나 이상의 사용자 디바이스 또는 해당 당사자가 채용하는 클라우드 자원과 같은 서버 자원 또는 이들의 임의의 조합으로 구성될 수 있다는 점에 다시 유의한다. 이는 작업이 단일 사용자 디바이스에서 수행되는 것으로 반드시 제한하지는 않는다.

타원 곡선 디지털 서명 알고리즘 (ECDSA)

공개 키 암호화는 다수의 상이한 블록체인 아키텍처에서 트랜잭션을 보호하기 위한 기초로 사용된다. 공개 키 암호화의 사용은 공개 키 암호화 및 디지털 서명 체계를 포함한다. 공개 키 암호화는 특정 함수는 계산하기 쉽지만 특별한 지식 없이는 반전하기 어렵다는 원칙에 기반을 두고 있다. 이러한 함수를 트랩도어(trapdoor) 함수라고 하며 이를 반전하는 데 필요한 특수 지식을 해당 함수의 트랩도어라고 한다. 계산하기 쉽다는 것은 주어진 입력(또는 입력 세트)에 대해 합리적인 시간 프레임 내에 트랩도어 함수를 계산하는 것이 계산적으로 가능하다는 것을 의미하고, 반전하기 어렵다는 것은 트랩도어에 대한 지식 없이 결과에서 해당 입력(또는 해당 입력들)을 추론하는 것이 계산적으로 불가능하다는 것을 의미한다.

공개 키 암호화의 맥락에서, 키 쌍은 공개 키(누구나 자유롭게 사용할 수 있음)와 대응하는 개인 키(특정 엔티티 또는 그룹에게만 알려져 있다는 의미에서 비밀로 가정됨)를 의미한다. 공개 키는 트랩도어 함수를 정의하고 대응하는 개인 키는 해당 함수를 반전하는 데 필요한 트랩도어이다.

공개 키 암호화 맥락에서, 암호화는 트랩도어 함수(즉, 암호화는 "정방향(forward direction)"으로 수행됨)에 기초하면, 해독은 트랩도어 함수의 반전(즉, 해독은 "역방향(reverse direction)"으로 수행됨)에 기초하며, 이는 트랩도어가 알려진 경우에만 가능하다.

디지털 서명 맥락에서, 서명 검증은 공개 키를 사용하여, 정방향으로 수행되고, 서명 생성은 역방향으로 수행되며 개인 키를 통해서만 실현 가능하게 수행될 수 있다.

블록체인 맥락에서, 공개 키 암호화에 기초한 디지털 서명은 암호화 방식으로 트랜잭션에 서명하고 트랜잭션 서명을 검증하는 기초로 사용된다.

ECC는 타원 곡선의 수학적 속성을 활용하는 공개 키 암호화의 일 형태이며, DSA(디지털 보안 알고리즘)와 같은 다른 암호화 체계에 비해 다양한 이점이 있다.

"타원 곡선 디지털 서명 알고리즘"(ECDSA)은 디지털 서명 생성 및 검증을 위한 기초로 ECC를 사용하는 디지털 서명 체계의 클래스를 지칭한다. ECDSA의 특정 원칙은 아래에 설명되어 있다.

수학 용어에서, ECC는 소수 차수(prime order)의 유한체(finite field)에 대한 타원 곡선의 대수적 구조를 이용한다. 유한체는 유한 요소 집합 및 집합의 요소에 적용될 때 일반적인 산술 규칙(결합성, 교환성 등)을 충족하는 곱셈, 덧셈, 뺄셈 및 나눗셈의 연관된 연산 집합을 의미한다. 즉, "일반적인" 의미에서 덧셈, 곱셈 등일 필요가 없지만, 본질적으로 동일한 방식으로 동작하는 연산이다.

타원 곡선 연산

ECC의 맥락에서, 덧셈, 뺄셈 및 곱셈 연산은, 각각, 본원에서 "+"로 표시된 타원 곡선 점 덧셈, 본원에서 "-"로 표시된 타원 곡선 점 뺄셈 및 본원에서 "ㆍ"로 표시된 타원 곡선 스칼라 곱셈이다. 덧셈 및 뺄셈 연산은 각각 타원 곡선의 두 점에 적용되고 타원 곡선의 제3 점을 반환한다. 그러나 곱셈 연산은 스칼라와 타원 곡선의 단일 점에 적용되고, 타원 곡선의 제2 점을 반환한다. 대조적으로, 나눗셈은 스칼라로 정의된다.

설명을 위해 도 6a는

의 타원 곡선

를 나타내며,

는 모든 실수 값 2차원 좌표의 집합이고 (x,y)∈

는

의 요소를 나타낸다. 타원 곡선

는 다음 식을 만족하는 점의 집합이다.

덧셈:

의 수학적 속성은, 타원 곡선

의 두 점 A,B가 주어지면, A와 B를 교차하는 선이

와 다시 교차하고 C로 표시된 하나의 추가 점만 교차한다는 것이다. A와 B의 타원 곡선 덧셈, 즉 A+B는 C의 "반사(reflection)"로 정의된다. C와 교차하는 수평선을 취하면 C의 반사는 해당 선과 교차하는 타원 곡선의 다른 점이다. 이 정의는 A=B의 경우에 유지되며, C는 이제 A에서

에 대한 접선이

와 다시 교차하는 지점으로 수정된다. 이 정의는 ∞로 표시된 무한대의 점을 타원 곡선의 한 점으로 정의하고 임의의 수직선이 타원 곡선과 교차하는 점으로 정의하여 두 점을 교차하는 선이 수직인 경우에 유지되도록 만들어졌다(예를 들어 D 및 E로 표시된 점은 수직으로 수평으로 정렬되므로 D+E=∞).

뺄셈/덧셈 역원: 반사의 위 정의는 모든 점에 적용되며 타원 곡선 점 뺄셈의 정의를 제공한다. A-B는 A와 B의 반사의 합이다. B의 반사는 더 공식적으로 B의 "덧셈 역원(additive inverse)"으로 지칭되며, 이는 다시 -B로 표시된다. 이 표기법을 사용하여, 타원 곡선 뺄셈은 수학 표기법으로 다음과 같이 정의할 수 있다.

따라서, 도 6b에서, C=-(A+B) 및 (A+B)=-C이다. 또한, 이 정의에서, D=-E는 대수 구조의 일반적인 규칙을 반영한다. 즉, 타원 곡선의 임의의 점과 그 덧셈 역원의 타원 점 덧셈은 무한대의 점이다. 즉

무한대 ∞에 있는 점은 공식적으로 "항등 요소"로 지칭된다(일반 산술과의 유사 및 차이 모두에 유의한다: 일반 산술에서 임의의 숫자 a와 덧셈 역원 -a의 합은 0이고, 0은 일반 산술의 항등 요소이다). 일반 산술을 반영하는 ∞의 항등 요소의 다른 속성은 ∞ 자체를 포함하여

의 임의의 점 A에 대해 A+∞=A라는 것이다(임의의 실수 a에 대한 명제 a+0=0과 유사).

곱셈: 타원 곡선 점 덧셈의 정의로부터, 타원 곡선 스칼라 곱셈의 정의는 다음과 같다. 타원 곡선 점 A와 정수 v의 곱셈은 다음과 같이 정의된다.

즉, A 자신의 v번의 타원 곡선 점 덧셈이다.

참고: 타원 곡선 스칼라 곱셈은 또한 당업계에서 타원 곡선 점 곱셈으로 지칭된다. 이 두 용어는 본 개시에서 동일한 의미를 갖는다.

나눗셈/곱셈 역원: 나눗셈의 연산은 스칼라에 대해 정의된다. 스칼라 v가 주어지면, 그 "곱셈 역원(multiplicative inverse) "은 스칼라 v^-1에서 다음과 같이 정의된다.

도 6a는

가 모든 실수

을 포함하는 무한체에 대해 정의되는 위의 연산을 직관적으로 시각화한 것이다.

도 6b는 식에 의해 정의된 타원 곡선

_n을 나타내므로, 위의 연산이 ECC의 맥락에서 실제로 적용되는 방법을 더 자세히 나타낸다.

여기에서 p는 소수(소수 계수)이고 mod는 모듈로 연산을 나타낸다. 위의 식을 만족하는 점들의 집합은 유한하고, 그 점들 중 하나를 제외하고는 모두 도 6b에서 흰색 원으로 표시된다. 나머지 점은 항등 요소 ∞이다.

소수 p는 타원 곡선 정의의 일부를 형성하며, 자유롭게 선택할 수 있다. 타원 곡선이 우수한 암호화 속성을 가지려면, p가 충분히 커야 한다. 예를 들어, 특정 블록체인 모델에서 256비트 p가 지정된다.

대조적으로, 아래 첨자 "n"은 위에서 정의된 점 덧셈에서 타원 곡선 점에 의해 형성된 그룹의 차수로 본원에서 지칭된다(줄여서, 이를 타원 곡선

_n의 차수라고 부를 수 있다)-아래 참조.

달리 말하자면, n은 그룹의 차수이고 p는 필드의 차수이다. 총 n개의 타원 곡선 점이 있다. 타원 곡선의 각 점은 두 개의 숫자/좌표(x,y)로 표시되며, 여기에서 x와 y는 모두 -(p-1),…0,…,(p-1) 범위에 있다.

도 6b의

_n은 소수 파일에 대한 타원 곡선의 일반적인 속성인 도 6a의

와 유사한 수평 대칭을 나타내므로,

_n 상의 점의 덧셈 역원의 정의가 여전히 유효하다. 일부 점은 수평으로 정렬된 대응 점(counterpoint)이 없으며(예를 들어 (0,0)) 이러한 점은 자체의 덧셈 역원이다.

_n상에서 두 점 A와 B를 교차하는 "선" l_A,B는 유사한 기하학적 요구 사항을 충족하는, 더 작은 검은색 원으로 표시되는, 유한한 점 집합이 되며, 타원 곡선 스칼라 곱셈의 정의가 여전히 유효하다. 도 6a와 유사하게, 도 6b는 선 l_A,B가

_n과 재교차하는 점 C=-(A+B)의 덧셈 역원인 점 A+B=-C를 보여준다.

_n상의 두 점의 타원 곡선 덧셈 A+B=-C는 다음 식에 의해 대수적으로 정의할 수 있다:

여기에서

및

위의 목적을 위해, 정수 v의 곱셈 역원 v^-1의 정의는 다음과 같이 수정된다:

즉, 정수 v의 곱셈 역원은 v mod p의 모듈러 역수이다.

B=-A의 경우는 특별하며, 언급한 바와 같이 항등 요소 ∞의 도입으로 해결되고, 이 경우 A+B=A+(-A)=∞이다. B=∞의 경우 또한 위에서 언급한 것처럼 A+∞=A로 해결되는 특별한 경우이다.

타원 곡선 스칼라 곱셈의 정의는 이 타원 곡선 덧셈의 정의를 채택하고 그렇지 않으면 동일하게 유지된다.

다른 맥락에서, 스칼라 v에 대한 곱셈 역원 v^-1의 정의는 다음과 같다:

곱셈 역원이 mod n 또는 mod p 중 어느 것에 대해 정의되는지는 맥락에서 명확할 것이다.

실제로, 숫자를 mod n 또는 mod p중 어느 것으로 처리해야 하는지 식별하기 위하여, 다음 검사가 적용될 수 있다.

1. EC 점의 좌표를 나타내는 숫자인가?

a. 그렇다면 mod p

2. EC 점을 곱하는 데 사용되는 숫자인가?

a. 그렇다면 mod n

두 검사 모두 긍정적인 답변을 제공하는 경우가 있으며, 이 경우 숫자는 mod p 및 mod n이어야 함을 유의한다.

타원 곡선 암호화 (ECC)

타원 곡선 산술은 비밀 값을 가릴 수 있는 고유한 기능을 제공하며 많은 현대 암호화 시스템의 기초를 형성한다. 특히, 유한체에 대한 타원 곡선 점의 역 스칼라 곱셈은 다루기 힘든 문제이다(계산적으로 수행할 수 없음).

개인 키 V는 정수 형태를 취하고, 대응하는 공개 키 P는 또한 타원 곡선

_n 상의 점인 "생성기 점" G로부터 유도된, 타원 곡선

_n 상의 점 P이다:

여기에서 'ㆍ'는 a, b 및 n(타원 곡선 매개변수)으로 정의된 타원 곡선

_n에 대한 타원 곡선 스칼라 곱을 나타낸다.

충분히 큰 V의 경우, 실제로 P를 유도하기 위해 V 타원 곡선 덧셈을 수행하는 것은 어렵다. 즉, 계산적으로 실행 불가능하다. 그러나, V를 알면, 타원 곡선 연산의 대수적 속성을 활용하여 P를 훨씬 더 효율적으로 계산할 수 있다. P를 계산하는 데 사용할 수 있는 효율적인 알고리즘의 예는 "두배점 덧셈(double and add)" 알고리즘이다. 결정적으로 이것은 V가 알려진 경우에만 구현할 수 있다.

반대로, V가 알려져 있지 않으면, G와 P가 모두 알려져 있더라도 V를 유도하는 계산적으로 실현 가능한 방법(즉, 스칼라 곱셈의 역)이 없다(소위 "이산 로그 문제"). 공격자는 G에서 시작하여 P에 도달할 때까지 타원 곡선 점 덧셈을 반복적으로 수행하여 P를 "무차별 대입"하려고 시도할 수 있다. 그 시점에서 그는 V를 그가 수행해야 하는 타원 곡선 점 덧셈의 수로 알고 있을 것이다. 그러나 그것은 계산적으로 실행 불가능한 것으로 판명된다. 따라서, V는 위와 같은 의미에서 트랩도어의 요건을 만족한다.

ECC에서 공개 키 P, 생성기 키 G 및 타원 곡선

_n은 공개되고 알려진 것으로 가정되지만, 개인 키 V는 비밀이다.

타원 곡선 디지털 서명 검증 알고리즘(ECDSA)

블록체인 시스템에서, 사용자 또는 다른 엔티티는 일반적으로 신원을 증명하는 데 사용되는 개인 키 V를 보유하고 대응하는 공개 키 P는 다음과 같이 계산된다:

개인 키 V는 ECDSA를 사용하여 데이터 m("메시지") 조각에 서명하는 데 사용할 수 있다.

ECDSA에 대한 추가 세부사항은 예를 들어 그 전체로서 본원에 참조로 포함된 "RFC 6979 - 디지털 서명 알고리즘(DSA) 및 타원 곡선 디지털 서명 알고리즘(ECDSA)의 결정론적 사용", Tools.ietf.org, 2019에서 찾을 수 있다.

도 6c는 공개 키-개인 키 쌍(V,P)에 대한 ECDSA 서명(r,s)을 생성하는 서명 생성 함수(서명 생성기)(600)의 개략적인 기능 블록도를 도시한다. EDSA 서명은 본원에서 각각 r-부분(r) 및 s-부분(s)으로 지칭되는 값의 쌍이다.

서명 생성은 공개 키 P를 유도하는 데 사용된 동일한 타원 곡선

_n및 생성기 점 G에 기초하므로, 타원 곡선 매개변수 a,b 및 n과 생성기 점 G가 서명 생성기(600)에 대한 입력으로 표시된다.

서명 생성기(600)의 임시 키 생성기(602)는 "임시(ephemeral)" 키 k∈[1,n-1], 즉 1에서 n-1까지의 범위를 생성한다.

r-부분 생성기(604)는 다음과 같이 k로부터 대응하는 공개 임시 키를 계산하며:

그런 다음 계산된 점의 x 좌표([ ]_x는 타원 곡선 점의 x 좌표를 취하는 과정을 나타냄)를 취하고,

이는 서명의 r 부분이다.

s-부분 생성기(606)는 k mod n의 모듈러 역 k^-1(즉, k^-1k≡1(mod n) - 위 참조) 및 H(m)으로 표시된 메시지 m의 해시(필요한 경우 잘림)를 사용하여 서명(s)의 s-부분을 다음과 같이 계산한다:

본 예에서, 메시지 m은 트랜잭션(608)(본 예에서 하나 이상의 트랜잭션 출력)에 포함될 데이터를 포함한다. 이를 메시지 m에 서명하는 과정으로 지칭할 수 있으며, 메시지 m은 트랜잭션의 서명된 부분이라고 지칭할 수 있다.

메시지 m 및 서명(r,s)은, 다시, 트랜잭션(608)의 일부를 형성한다. 본 예에서, 서명(r,s)은 잠금 해제 스크립트의 일부로서 트랜잭션(608)의 입력에 포함된다.

도 6d는 트랜잭션(608)을 검증하기 위한 서명 검증 함수(서명 검증기)(620)의 개략적인 기능 블록도를 도시한다. 서명 검증기(620)에 의해 수행되는 계산은, 언급된 바와 같이, 공개된 동일한 타원 곡선

_n 및 생성기 점 G에 기초한다.

서명은 입력으로서 개인 키 V를 요구한다. 즉 유효한 서명을 생성하기 위해서는 이를 알아야 한다. 그러나, 서명(r,s)을 유효성 검증하기 위해서는 서명 쌍(r,s), 메시지 m 및 공개 키 P만이 요구된다. 서명을 검증하기 위하여, 서명 검증기(620)는 트랜잭션 m의 서명된 부분을 해시한다(서명(r,s)을 생성하기 위해 사용된 것과 동일한 해시 함수 H를 적용함). 그런 다음 검증 프로세스는 다음 계산을 사용하여 수행된다:

서명은 [R']_x=r인 경우 및 그 경우에만(if and only if) 유효하고(즉, 서명 검증이 성공함), 그렇지 않으면 유효하지 않다(즉, 서명 검증이 실패함). 본 예에서, r은 트랜잭션(608)에 포함된 서명의 r-부분을 나타낸다.

서명 검증 프로세스에 사용된 공개 키 P는 예를 들어 선행 트랜잭션의 잠금 스크립트에 지정될 수 있다. 이 경우, 서명 검증은 선행 트랜잭션의 잠금 스크립트에 지정된 공개 키와 (나중) 트랜잭션(608)의 서명된 부분 m 및 서명(r,s)을 사용하여 수행되며, 서명(r,s)이 선행 트랜잭션에서 지정된 공개 키 P에 대응하는 개인 키 V와 나중 트랜잭션(608)의 서명된 부분 m에 기초하여 생성된 것이 아니면 실패한다. 따라서, 개인 키 V를 보유한 사람만이 선행 트랜잭션의 출력을 청구할 수 있으며(일반적으로 나중 트랜잭션(608)의 출력에 자신의 공개 키를 포함함으로써), 나중 트랜잭션(608)의 서명된 부분 m은 서명(r,s)을 무효화하지 않고는 변경될 수 없다.

R-퍼즐

다음은 ECDSA에 기초한 새로운 형태의 지식 증명에 대해 설명한다. 예를 들어, 도전자는 Tx₁을 생성하고 P2P 블록체인 네트워크(106)에 직접 게시하거나 필요한 세부사항을 제3자에게 제공하여 Tx₁을 조합하여 게시할 수 있게 함으로써 제1 트랜잭션 Tx₁에서 r-퍼즐을 설정하는 당사자 앨리스이다. 검증자(실제로 증명을 실행하는 당사자)는 네트워크의 노드(104)의 운영자, 예를 들어 채굴자이다. r-퍼즐에 대한 해는 Tx₂ 를 네트워크(106)에 게시함으로써 제공된다. r-퍼즐은 본질적으로 신원에 연결되지 않기 때문에 증명자는 임의의 제2 당사자가 될 수 있지만, 예를 들어 아래에서는 증명자가 밥이 되는 시나리오의 관점에서 설명할 수 있다. 증명자는 Tx₂를 직접 생성하여 게시하거나, 제3자가 Tx₂로 조합하여 게시할 수 있도록 필요한 세부 정보를 제3자에게 제공할 수 있다.

암호화 해시 함수는 입력의 작은 변경이 출력의 예측할 수 없는 변경으로 이어지도록 입력을 결정론적으로 모호하게 하는 수단을 제공한다. 기존 해시 함수는 MD5, RIPEMD-160, SHA-1 및 SHA-256[5]를 포함하며, 이들 각각은 충돌 저항(동일한 출력을 생성하는 두 입력을 찾을 확률이 매우 낮음)과 사전 이미지 저항(주어진 해시 값 h = H(d) 입력 d를 찾는 것이 매우 어려움)을 제공한다.

기존의 해시 퍼즐은 다음과 같이 설정할 수 있다. 아이디어는 제2 트랜잭션 Tx₂가 그 입력에 특정 데이터 조각을 포함하는 조건으로 제2 트랜잭션 Tx₂에 의해 그 출력이 리딤될 수 있도록 하는 제1 트랜잭션 Tx₁을 설정하는 것이다.

블록체인 트랜잭션에서, 제1 당사자(앨리스)는 다음과 같이 잠금 스크립트 내의 해시 값 h를 사용하여 비표준 트랜잭션 Tx₁을 단순하게 생성할 수 있다.

OP_HASH160 <h> OP_EQUALVERIFY

여기에서 h= H_puz(d)이고 H_puz 는 퍼즐에 사용된 해시 함수이다(위의 예에서, 잠금 스크립트에 따르면 이 해시 함수는 HASH160이어야 하지만, 다른 구현에서는 다른 형태의 해시 함수가 사용될 수 있음). 이 잠금 스크립트가 포함된 UTXO를 리딤하려면 후속 트랜잭션의 잠금 해제 스크립트에 해시 퍼즐 해가 필요하다. 따라서, 주소가 Addr_Bob인 제2 당사자에 대한 지출 트랜잭션 Tx₂는 d만 포함하면 되는 잠금 해제 스크립트로 구성된다.

TxID 2
입력	출력
0. TxID1 잠금 해제 스크립트: <d>	0. 주소: 금액: {VALUE}

여기에서 TxID_i는 Tx_i의 트랜잭션 ID이다. 잠금 스크립트는: Tx₂의 입력에서 잠금 해제 스크립트의 데이터 값 d를 가져와 해시하고, 이것이 Tx₁의 출력에서 잠금 스크립트에 포함된 해시 값 h와 같은지 확인하도록 한다. 따라서 출력은 Tx₂의 잠금 해제 스크립트에서 d를 제공하여 잠금 해제된다.이 단순한 예에서, Tx₂에서 해시 퍼즐 해를 사용한 사용자의 트랜잭션을 본 후, 이 트랜잭션을 처음 수신한 채굴자는 악의적으로 트랜잭션을 거부하고 해시 퍼즐에 대한 동일한 해를 갖지만, 출력을 자신의 주소 Addr_Miner로 변경한 새로운 조작된(malleated) 버전 Tx₂ ^*를 생성할 수 있다. 그런 다음 악의적인 채굴자는 스스로 Tx₂ ^*를 블록(151)으로 채굴하고자 시도할 수 있으며, Tx₂가 채굴되기 전에 그것을 채굴하는 데 성공하면 밥 대신에 악의적인 채굴자가 지불을 받게 된다.

TxID 2 *
입력	출력
0. TxID1 잠금 해제 스크립트: <d>	0. 주소: 금액: {VALUE}

디지털 서명은 일반적으로 블록체인 트랜잭션에서 소유권을 증명하고 미지출 트랜잭션 출력(UTXO)을 리딤하기 위해 사용된다. 이는 Tx₁와 같은 트랜잭션의 출력을 특정 당사자에게 잠글 수 있게 한다. 가장 일반적인 예는 공개 키 해시에 지불(P2PKH) 트랜잭션으로서, 트랜잭션의 출력이 공개 키(해당 당사자의 주소 역할도 함)의 특정 해시에 잠겨 있다. 공개 키 P에 대한 잠금 스크립트는 다음과 같다:

OP_DUP OP_HASH160

OP_EQUALVERIFY OP_CHECKSIG

여기에서 h_P = H_sig(P)이며 H_sig 는 서명에 사용되는 해시 함수이다(위의 예에서, 잠금 스크립트에 따르면 이 해시 함수는 HASH160이어야 하지만, 다른 구현에서는 다른 형태의 해시 함수가 사용될 수 있음). 이 UTXO를 다른 트랜잭션에 대한 입력으로 사용할 수 있으려면, P를 사용하여 유효한 ECDSA 서명이 있는 잠금 해제 스크립트를 제공하여야 한다:

전체 문자열(잠금 해제 + 잠금 스크립트)은 채굴자가 평가하며, 올바른 공개 키가 제공되고 서명이 유효하며 P에 대응하는지 확인한다. 잠금 스크립트는 기본적으로: Tx₂의 입력 내의 잠금 해제 스크립트에서 공개 키 P를 가져와, 해시하고, 그것이 Tx₁의 출력 내의 잠금 스크립트에 포함된 해시 값 h_P와 같은지 확인하고; 또한 Tx₂의 서명된 부분에 대한 지식이 주어지면, ECDSA 검증 기능에 기초하여 Tx₂의 잠금 해제 스크립트에서 공개 키 P를 사용하여 서명

를 확인하도록 한다. ECDSA 검증 기능은 OP_CHECKSIG 작업코드에 의해 호출된다.

따라서 출력은 Tx₂의 잠금 해제 스크립트에서, P에 대응하는 개인 키 V에 기초하여 서명된 유효한 서명

을 제공함에 의해서만 잠금 해제될 수 있다.

이것을 해시 퍼즐과 함께 사용하면, 해시 퍼즐 해와 함께, 의도된 수령인의 전자 서명을 요구함으로써 위에서 언급한 취약점을 수정할 수 있다. 잠금 스크립트는 다음과 같이 구성될 것이다:

OP_HASH160

OP_EQUALVERIFY OP_DUP OP_HASH160

OP_EQUALVERIFY OP_CHECKSIG

그리고 대응하는 잠금 해제 스크립트는 다음과 같아야 할 것이다:

.

그러나, 이것은 이를 리딤할 수 있는 사람을 공개 키 P의 소유자로 제한한다. 예를 들어 앨리스가 퍼즐을 설정한 후에만 서명 기관을 지정할 수 있는 기능을 유지하려고 하는 것과 같은 일부 애플리케이션에서는 이것이 바람직하지 않을 수 있음을 본원에서 인식한다.

임시 랜덤 값일 수 있는, ECDSA 서명의 r-부분을 이용함으로써 해시 퍼즐 기능을 에뮬레이션할 수 있다는 것이 본원에서 인식된다. ECDSA 서명은 r과 s의 두 가지 주요 부분으로 구성된다. 위에서 본 바와 같이, r=[k·G]_x이다. 기존의 해시 퍼즐 h=H(d) 대신, 역 타원 곡선 덧셈의 난해성은 본원에서 r-퍼즐이라고 하는 유사한 퍼즐을 형성할 수 있다. 퍼즐을 풀기 위해서는, 해의 값 k를 얻어야 하며, 여기에서 k는 r에 대응하는 임시 키이다.

기존 해시 퍼즐의 경우, 퍼즐을 풀 때 블록체인에 d가 노출될 위험이 있다. 그러나, r-퍼즐에서는 k가 절대 드러나지 않는다. 대신 r이 공개되고 서명과 함께 r로부터, k에 대한 지식이 증명될 수 있다.

해시 퍼즐 기능을 에뮬레이션하기 위하여, r-퍼즐의 작성자는 먼저 다른 사전 이미지 데이터를 해시하여 값 k를 얻을 수 있다. 왜냐하면 k는 고정 크기여야 하지만 해시 퍼즐의 사전 이미지 데이터는 임의의 길이가 될 수 있기 때문이다(그리고 해시 함수의 한 가지 속성은 입력 데이터의 길이에 관계없이 고정된 길이의 값을 출력한다는 것이다). 예를 들어, 256비트 길이의 개인/임시 키를 사용하는 경우, r-퍼즐에 대한 사전 이미지 데이터는 k를 얻기 위해 해시되어야 한다. 그러나 대안적으로 k의 일부 적절한 길이 값은 자체 권한으로 비밀 값으로 직접 선택되어 사용될 수 있다(즉, 다른 선행 사전 이미지에서 이를 유도할 필요가 없음).

이 방법은 지출을 위해 ECDSA 서명을 사용하는 모든 블록체인 시스템에서 사용할 수 있다. 예시로서, 다음은 UTXO 기반 모델에서의 예시적인 구현을 설명할 것이다. 스크립팅 언어에서, OP_CHECKSIG 작업코드는 스택에 서명과 공개 키가 필요하다(공개 키가 스택 맨 위에 있고 서명이 바로 아래에 있음). r-퍼즐의 경우, 스크립트는 제공된 서명의 r 값이 r-퍼즐 도전에 사용된 것과 동일한 것인지 확인하도록 구성된다. 달리 말하자면, 스크립트는 (OP_CHECKSIG를 통해) 공개 키에서 서명이 유효한지 확인할 뿐만 아니라, 블록체인에 먼저 게시될 r-퍼즐의 r 값을 사용하여 서명이 생성되었는지도 확인할 것이다.

r-퍼즐의 일부 예시적인 구현이 이제 도 7 내지 10을 참조하여 논의된다. 각 경우에, 증명자, 예를 들어 밥은 Tx₂의 일부에 서명하여 서명(r,s)을 생성하였다. 이 양식의 서명은 때때로 또한 "

"로 지칭된다. 암호화 서명의 맥락에서, 서명된 부분은 "메시지" m라고도 한다. 서명된 부분(메시지) m은 적어도 밥에게 결과 지불을 잠그는 Tx₂의 출력 203₂를 포함한다. 하나보다 많은 출력이 있는 경우, m은 출력의 일부 또는 전부를 포함할 수 있다. m은 사용되는 경우 잠금 시간과 같은 다른 부분도 포함할 수 있다. 그러나 일반적으로 잠금 해제 스크립트 자체를 제외한다(물론 최소한 서명 자체는 제외해야 함). Tx₂에서 메시지 m으로 서명되는 부분은 Sighash에 의해 설정되거나, 또는 기본값이거나, 또는 프로토콜의 고정 기능일 수 있다.

아마도 r-퍼즐의 가장 간단한 구현이 도 7에 나타나 있다. Tx₁의 잠금 스크립트는 기준 인스턴스 또는 r-부분을 포함하며, 여기에서 r'로 라벨이 붙어 있다. 이 방법에서, Tx₂의 잠금 해제 스크립트는 최소한 밥의 서명의 s-부분(s)만 포함하면 된다. 또한 밥이 m에 서명하는 데 사용한 개인 키 V에 대응하는 공개 키 P를 포함할 수 있다. Tx₁의 잠금 스크립트는 노드(104)에서 스크립트 엔진(402)에 의해 실행될 때, Tx₂의 잠금 해제 스크립트에서 s와 P를 취하고 다음 작업을 수행하도록 구성된다:

I)

및

II) 확인

여기에서 r'은 Tx₁의 잠금 스크립트에서 가져오고, s와 m은 Tx₂의 잠금 해제 스크립트에서 가져온다. 밥의 공개 키 P는 잠금 해제 스크립트 Tx₂에서 가져오거나 다른 수단으로 알 수 있다. H_sig는 제1 ECDSA 서명을 생성할 때 m을 해시하는 데 사용된 해시 함수이다. 이는 임의의 형태의 해시 함수일 수 있다. 어떤 형태를 취하든, 이 해시 함수의 형태(유형)는 미리 결정되고 양단에서 알려진 것으로 가정할 수 있다. G는 고정되고 공개적으로 알려진 벡터 값이다.

잠금 스크립트는 상기 확인이 참인 조건에서 "참"의 결과를 반환하고, 그렇지 않으면 "거짓"의 결과를 반환하도록 구성된다. UTXO의 경우, 잠금 해제 스크립트와 함께 잠금 실행의 참의(즉, 성공적인) 결과는 트랜잭션의 유효성에 대한 요구 사항이다. 따라서 Tx₂의 유효성은 r-퍼즐의 결과에 대한 프록시로 사용될 수 있다. 또는 달리 말하자면, Tx₂의 유효성은 r-퍼즐에 대한 해를 제공한다는 조건부이다. 즉, 밥이 r-퍼즐을 통과하지 못하면, 그의 트랜잭션 Tx₂는 네트워크(106)를 통해 전파되지 않고 블록체인(150)에 기록되지 않는다(그리고 Tx₁의 출력에 정의된 지불은 리딤되지 않는다).

도 7의 예는 수학적 의미에서 가장 단순할 수 있지만, 이것이 반드시 임의의 주어진 노드 프로토콜 또는 스크립팅 언어와 통합하기에 가장 간단하다는 것을 의미하지는 않는다. 지출자가 잠금 해제 스크립트에서 <r,s> 및 <P>가 아닌 <s> 및 <P>만을 제공하면, 스크립트는 이를 설명하여야 한다. 작업 I)-II)는 표준 Checksig 유형 작업코드의 작업이 아니다. OP_CHECKSIG 작업코드는 서명이 DER 형식일 것으로 예상하므로 잠금 해제 스크립트에 <s> 값만 제공되면 DER 형식의 유효한 서명을 생성하기 위해 잠금 스크립트(연결할 OP_CAT 등) 내에 몇 가지 추가 작업코드가 필요하다. 간단히 설명된 도 8은 수학적으로 추가 단계를 포함하지만, 실제로는 모두 Tx₂의 입력에서 가져온 r 및 s에 기초한 ECDSA 서명 검증을 호출하기 위한 전용 작업코드를 갖는 스크립트(Script)와 같은 스크립팅 언어와 더 간단하게 통합되는 대안적인 예를 도시한다.

또한 가능한 모든 실시예에서 Tx₂에 P를 포함해야 하는 것은 아님을 유의한다. 실제로, 메시지 m 및 (r,s), 또는 이 경우 (r',s)에 대한 지식으로부터, 공개 키의 두 가지 가능한 값 P 및 -P를 계산하는 것이 가능하다(그러나 어느 것이 어느 것인지는 알 수 없음). 그런 다음 두 가지 검증을 사용하여 어느 것이 올바른 것인지 식별하거나, 대안적으로 두 가지 가능한 해 중 어느 것을 사용할 것인지 신호하기 위하여 1비트 플래그가 Tx₂에 포함될 수 있다. 이 후자의 접근 방식은 현재 일부 계정 기반 프로토콜에서 사용된다. 그러나, 스크립팅 언어(예를 들어 Script)가 (r,s) 및 m에서 P 및 -P를 계산하는 연산에 대한 작업코드가 없는 현재 UTXO 기반 프로토콜에서는 사용되지 않는 경향이 있다. 그럼에도 불구하고, 하나가 도입될 수 있거나 작업이 단순히 잠금 스크립트에 명시적으로 코딩될 수 있다는 가능성을 배제해서는 안 된다. 다른 가능성은 앨리스가 이미 P를 알고 있거나 접근할 수 있거나 사이드 채널(301)을 통해 수신하는 것이다. 그러나 P를 Tx₂에 매핑하려면 별도의 조회가 필요하다.

다른 구현 예는 도 8에 나타나 있다. 여기에서 r-퍼즐은 Tx₂의 잠금 해제 스크립트가 r-부분의 제출된 인스턴스 r을 명시적으로 포함하도록 요구한다. Tx₁의 잠금 스크립트는 r-부분에 대한 테스트를 포함하며, 테스트는 제출된 인스턴스 r과 비교할 r-부분의 기준 인스턴스 r'를 포함한다. 이 방법에서, Tx₂의 잠금 해제 스크립트는 밥의 서명의 r-부분(r)과 s-부분(s)을 포함해야 한다. 또한 이는 밥이 m에 서명하는 데 사용한 개인 키 V에 대응하는 공개 키 P를 포함할 수 있다. Tx₁의 잠금 스크립트는, 노드(104)에서 스크립트 엔진(402)에 의해 실행될 때, Tx₂의 잠금 해제 스크립트에서 r, s 및 P를 가져와 다음 작업을 수행하도록 구성된다:

I) 확인

및

II) 계산

및

III) 확인

여기에서 r'은 Tx₁의 잠금 스크립트에서 가져오고, s, r 및 m은 Tx₂의 잠금 해제 스크립트에서 가져온다. 밥의 공개 키 P는 잠금 해제 스크립트 Tx₂에서 가져오거나, 이전에 논의된 바와 같이 (r,s) 및 m 또는 (r,s) 및 m에서 유도되는 것과 같은, 다른 수단으로 알 수 있다.

잠금 스크립트는 I) 및 III) 단계의 확인이 모두 참인 조건에서 "참"의 결과를 반환하고, 그렇지 않으면 "거짓"의 결과를 반환하도록 구성된다. 다시 UTXO 기반의 경우, 이것은 r-퍼즐 지식 증명의 결과에 따라 트랜잭션의 유효성이 결정될 수 있게 한다. 숫자 I-III가 반드시 순서를 의미하는 것은 아님을 유의한다. 확인 I)는 II)-III) 전이나 후에 수행할 수 있지만, III)는 II) 후에 수행하여야 한다.

도 8의 방법에서, 단계 II) 및 III) 단독은 ECDSA 검증 기능에 의해 수행되는 통상적인 동작이다. 따라서 대부분의 프로토콜에서 스크립트의 기존 Checksig 작업코드(OP_CHECKSIG)와 같은 전용 작업코드에 의해 호출될 수 있다. 단계 I)는 범용 작업코드를 사용하여 잠금 스크립트에 별도로 코딩할 수 있다(예가 곧 제공됨). 또한 II) 및 III) 단계가 원칙적으로 Checksig와 같은 전용 작업코드를 사용하는 대신 범용 작업코드를 사용하여 명시적으로 인코딩될 수 있다는 점도 배제되지 않는다.

트랜잭션 프로토콜의 한 예에서, 트랜잭션 ECDSA 서명은 도 12와 같이 ASN.1(Abstract Syntax Notation One) DER(Distinguished Encoding Rules) 인코딩 형식을 사용한다. 제1바이트 필드는 ASN.1 시퀀스 번호를 나타내는 플래그 0x30을 포함한다. 다음 바이트 필드는 16진수 시퀀스의 길이를 포함한다. 제3 바이트 필드는 ASN.1 정수를 나타내는 플래그 0x02를 포함한다. 그 후, ECDSA 서명의 r 값이 다음 32 또는 33바이트에 포함된다. 필드는 32바이트여야 하지만 r의 제1 바이트가 0x7f보다 크면(제1 비트는 1임) r 값 앞에 0의 추가 바이트가 추가되어 길이가 33바이트가 된다. 이는 정수의 제1 비트를 부호로 해석하는 DER 형식 인코딩의 결과로 수행된다. 음수 값으로 해석되지 않도록 0의 추가 바이트가 값의 시작 부분에 추가된다. ECDSA 서명의 s 값에 대해서도 동일한 작업이 수행된다. 마지막으로, 1바이트 필드인 해시 유형(ht)이 트랜잭션의 비트코인 서명 유형(SIGHASH_ALL, SIGHASH_NONE 등)에 대응하는 DER 인코딩에 추가된다.

앨리스(A)가 퍼즐에 대한 해를 획득한 사람은 누구나 지출할 수 있는 r-퍼즐 트랜잭션을 생성하려는 경우를 고려한다. 이를 달성하기 위하여, 그녀는 아래에 나타난 것과 같은 새로운 트랜잭션 Tx₁를 생성할 것이다. 입력 섹션은 지출된 이전 트랜잭션 Tx₀의 잠금 해제 스크립트를 포함한다. 단순화를 위해, 이것이 앨리스의 서명과 공개 키를 사용하여 지출되는 표준 P2PKH라고 가정한다. 출력 섹션은 잠금 스크립트(스크립트 공개 키), 또는 달리 말하자면 r-퍼즐 도전을 포함한다. 도 12에 도시된 바와 같이, 서명은 일부 프로토콜에서 DER 인코딩 형식을 사용할 수 있으므로, 스크립트는 인코딩된 서명에서 r 값을 추출한 다음 <r>와 같은지 확인해야 한다. 그런 다음, 스크립트는 서명이 공개 키에 대해 유효한지 확인해야 한다. 스크립트 작동 방식에 대한 더 자세한 설명은 도 5에 나타나 있다. 굵게 표시된 작업코드는 본질적으로 서명에서 r을 추출하는 방법일 뿐이다.

TxID1
입력	출력
임의의 지출 입력	OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT SP_SWAP OP_SPLIT OP_DROP <r> OP_EQUALVERIFY OP_SWAP OP_CHECKSIG

대응하는 잠금 해제 스크립트가 아래에 나와 있으며, 여기에서 서명 sig_r은 r을 사용하고 지출자(spender)인 밥(B)은 개인/공개 키 쌍을 사용하여 서명을 계산할 수 있다. sig_r이 (r,s)임을 유의한다.

도 13은 단계별 스크립트 분석을 나타낸다.

임시 키 k는 앨리스가 생성하고 밥(및 선택적으로 하나 이상의 다른 잠재적 증명자)에게 제공할 수 있다. 대안적으로 k는 밥에 의해 생성되고 밥(또는 밥이 k를 공유하기로 선택한 사람)만이 풀 수 있는 r-퍼즐을 설정하기 위해 앨리스에게 주어질 수 있다. 두 경우 모두, 증명자 밥은 발신자 앨리스가 r-퍼즐에 대한 해(k)를 알고 있기 때문에 트랜잭션을 자신이 지출하지 않는다고 신뢰해야 한다. 이를 방지하기 위하여, 증명자 밥은 퍼즐을 만든 다음 앨리스가 R-퍼즐 트랜잭션을 생성할 때 사용할 r 값을 앨리스에게 보낼 수 있다. 그 후, 밥은 r-퍼즐에 대한 해이며 키 형태로 볼 수 있는 값 k를 유지하는 한, 임의의 개인/공개 키 쌍을 사용하여 나중에 출력을 리딤할 수 있다. 반면, 일부 경우에는 앨리스가 k를 알고 있다는 사실이 유리한 특징이 될 수 있다. 예를 들어 개인 키 퍼즐을 만드는 데 사용할 수 있으며 이를 통해 일반화된 원자 교환이 가능하다.

도 9는 공개 키 해시에 지불(P2PKH)과 유사하게 본원에서 "r-퍼즐 해시에 지불(pay to r-puzzle hash)"(P2RPH)로 부를 수 있는 r-퍼즐의 다른 예를 도시한다. 추가 보안 및 개인 정보 보호를 위해, r 값은 Tx₁(네트워크(106)의 노드(104)를 통해 전파되고 블록체인(150)에 배치됨)에 배치되기 전에 해시될 수 있다. 공개 키 자체가 아닌 공개 키의 해시만 블록체인에 있는 P2PKH와 유사하게, R-퍼즐에서도 동일한 작업을 수행할 수 있다.

여기에서 r-퍼즐은 다시 Tx₂의 잠금 해제 스크립트에 r-부분의 제출된 인스턴스 r이 포함될 것을 요구한다. Tx₁의 잠금 스크립트는 다시 r-부분에 대한 테스트를 포함하지만, 이번에는 r'의 해시 형태로 r-부분의 압축된 인스턴스 형태로, 즉 h = H(r')이다. 이것은 제출된 인스턴스 r과 비교될 것이다. 이 방법에서, Tx₂의 잠금 해제 스크립트는 다시 밥의 서명의 r-부분(r)과 s-부분(s)을 포함해야 한다. 또한 밥이 m에 서명하는 데 사용한 개인 키 V에 대응하는 공개 키 P를 포함할 수 있다. Tx₁의 잠금 스크립트는, 노드(104)에서 스크립트 엔진(402)에 의해 실행될 때, Tx₂의 잠금 해제 스크립트에서 r, s 및 P를 가져와 다음 작업을 수행하도록 구성된다:

I) 확인

및

II) 계산

및

III) 확인

여기에서 h는 Tx₁의 잠금 스크립트에서 가져오고 s, r 및 m은 Tx₂의 잠금 해제 스크립트에서 가져온다. 해시 값 h= H_puz(r)이며 여기에서 H_puz는 r 퍼즐의 해시(hash-of-r puzzle)에서 사용되는 해시 함수이다. 이는 임의의 형태의 해시 함수일 수 있다. 이는 H_sig와 동일한 또는 상이한 형태의 해시 함수일 수 있다. 어떤 형태를 취하든, H_puz의 형태는 미리 결정되어 양단에서 알려진 것으로 가정할 수 있다. 밥의 공개 키 P는 또한 잠금 해제 스크립트 Tx₂에서 가져오거나, 또는 이전에 논의된 바와 같이 (r,s) 및 m 또는 (r,s) 및 m에서 유도되는 것과 같은 다른 수단으로 알 수 있다.

잠금 스크립트는 I) 및 III) 단계의 확인이 모두 참인 조건에서 "참"의 결과를 반환하고, 그렇지 않은 경우 "거짓"의 결과를 반환하도록 구성된다. 확인 I)는 II)-III) 전이나 후에 수행할 수 있지만, III)는 II) 후에 수행해야 한다.

또한, 다시 도 8의 경우와 마찬가지로, 단계 II) 및 III) 단독은 ECDSA 검증 기능에 의해 수행되는 통상적인 동작이다. 따라서 대부분의 프로토콜에서 스크립트의 기존 Checksig 작업코드(OP_CHECKSIG)와 같은 전용 작업코드에 의해 호출될 수 있다. 단계 I)는 범용 작업코드를 사용하여 잠금 스크립트에 별도로 코딩할 수 있다.

트랜잭션 도전 Tx₁의 잠금 스크립트의 예는 다음과 같다:

TxID1
입력	출력
임의의 지출 입력	OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT SP_SWAP OP_SPLIT OP_DROP OP_HASH160 <h> OP_EQUALVERIFY OP_SWAP OP_CHECKSIG

양 당사자, 송신인과 수신인 사이에서 일관된 임의의 유형의 해시 함수가 사용될 수 있다. 그러나, P2PKH 표준과 일관성을 유지하기 위하여, SHA-256과 RIPEMD-160의 이중 해시인 OP_HASH160을 사용한다.

대응하는 잠금 해제 스크립트는 아래에 나타나 있으며(이전 섹션과 동일), 여기에서 서명 sig_r은 r을 사용하고 지출자 밥(B)은 개인/공개 키 쌍을 사용하여 서명을 계산할 수 있다:

따라서 도 9의 예는 r의 변환되지 않은 인스턴스 대신 r-도전의 기초로 r-부분의 해시를 사용한다는 점을 제외하고는 도 8과 같다.

이러한 경우, Tx₁의 잠금 해제 스크립트가 "참" 결과에 대한 추가 기준을 부과할 수 있음을 배제하지 않음을 유의한다. 예를 들어 잠금 시간 또는 추가 서명에 대한 요구 사항이 예가 될 수 있다.

위의 기술 중 하나의 사용 사례는 일반적인 지식 도전이다. 해 k가 있거나, 또는 k로 해시될 수 있는 해가 있는 임의의 도전을 고려한다. 그러면 앨리스는 퍼즐에 연결된 R-퍼즐을 생성할 수 있다. 즉, 그녀는 r=[k·G]_x를 정의할 수 있다.

예를 들어, 앨리스는 수학 교수이다. 그녀는 r-퍼즐 트랜잭션 Tx₁을 구성할 수 있으며, 여기에서 기본 k 값은 학생들이 풀도록 장려되는 수학 문제에 대한 해이다. 해를 구하는 사람은 이를 사용하여 서명(r,s)을 생성할 수 있으며, 여기에서 r은 잠금 스크립트의 값과 일치하므로 보상을 청구한다. 서명은 진정성을 제공할 뿐만 아니라 다른 사람에게 해를 공개하지 않고 해에 대한 지식 증명 역할을 한다. 따라서 R-퍼즐은 노출 위험 없이 일반적으로 일부 해 또는 정보에 대한 지식을 증명하는 안전한 메커니즘을 제공한다. 이는 스크립트를 잠금 해제하는 데 필요한 서명을 세련되게 재사용하고 임의의 공개 키 P를 사용할 수 있으므로 해를 찾는 사람이 개인 정보를 보호받으면서 보상을 청구할 수 있다.

이 체계는 또한 토큰 또는 디지털 티켓의 형태로 사용할 수 있다. 예를 들어, 이벤트 주최자는 참석자에게 상이한 k 값을 디지털 티켓으로 발행할 수 있다. 참석자가 이벤트에 참석을 원할 때, r-퍼즐을 사용하여 비밀 토큰에 대한 지식을 증명할 수 있다.

다른 사용 사례로서, r-퍼즐을 서명 인증 체계로 사용할 수 있으며, 여기에서 한 당사자는 다른 당사자에게 서명 권한을 위임할 수 있다. 잠금 스크립트와 일치하는 r 값을 가진 서명이 제공되는 경우에만 잠금 해제될 수 있는 r-퍼즐 트랜잭션 Tx₁을 고려한다. 이는 [k·G]_x=r인 값 k를 아는 사람만이 그러한 서명을 생성할 수 있음을 의미한다. 그러나, 그 사람이 k에 대한 지식을 다른 사람에게 전달하는 경우, 이는 다른 사람이 자신을 대신하여 서명할 수 있는 권한을 효과적으로 부여하는 것이다.

예를 들어, 앨리스가 배달을 받기를 원한다고 가정한다. 그녀는 배달을 수락하기 위해 거기에 있지 않을 수도 있음을 걱정한다. 그녀는 밥과 찰리에게 k 사본을 제공하여 그들이 대신하여 배달을 수락할 수 있도록 한다. 데이브가 소포를 배달하는 경우, 밥에게 소포를 양도하려면 예상되는 r 값이 포함된 서명을 받아야 한다.

이와 같은 시나리오에서, k는 임시 개인 키로 작동하고, r은 임시 공개 키로 간주할 수 있다. k 및 r이 특정 신원에 연결되지 않는다는 점을 제외하고 각각 V 및 P와 유사하다.

조인트 값(joint value) R-퍼즐

도 9의 해시된 R-퍼즐(P2RPH)의 확장으로서, 해시 전에 r과 연결된 추가 값 d를 포함할 수 있다(h = H_puz(r||d)를 얻기 위하여). 이 경우 증명자(예를 들어 밥)는 r-퍼즐을 풀 뿐만 아니라, d도 알아야 한다. 이의 예가 도 10에 나타나 있다.

Tx₁의 잠금 스크립트는, 노드(104)에서 스크립트 엔진(402)에 의해 실행될 때, Tx₂의 잠금 해제 스크립트에서 r, s, P 및 d를 가져와서 다음 작업을 수행하도록 구성된다:

I) 확인

=

및

II) 계산

및

III) 확인

여기에서 r||d는 r과 d의 연결을 임의의 순서(r 먼저 또는 d 먼저)로 나타낸다. 도전 트랜잭션 Tx₁의 잠금 스크립트의 예는 다음과 같다:

TxID
입력	출력
임의의 지출 입력	OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_2 OP_ROLL OP_CAT OP_HASH160 <hjoint> OP_EQUALVERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG

대응하는 잠금 해제 스크립트는 아래에 나와 있다(d가 포함된 것을 제외하고 이전 섹션과 동일). 서명 sig_rP_B는 r을 사용하고 증명자 밥(B)은 임의의 개인/공개 키 쌍을 사용하여 서명을 계산할 수 있다.

추가 서명 sig'은 보안을 위해 추가된 기능이다(이후의 선택적 보안 기능에 대한 섹션 참조). 그러나 이것은 모든 가능한 실시예에서 요구될 필요는 없다.

예시적인 사용 사례는 CLTV 연결된 R-퍼즐이다. 이 경우, 데이터 값 d는 CLTV(Check Lock Time Verify) 트랜잭션 출력과 연결된 시간 값 t일 수 있다. 이에 대한 동기는 P2RPH 해시 내에서 이전에 출력을 지출할 수 없는 시간 t를 숨기고 이를 R-퍼즐에 연결하는 것이다. 이 경우, 증명자(예를 들어 밥)는 r-퍼즐을 풀 뿐만 아니라, t를 알고 지출하기 위하여 특정 시간까지 기다려야 한다. 트랜잭션의 잠금 스크립트의 예는 다음과 같다:

TxID1
입력	출력
임의의 지출 입력	OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT SP_SWAP OP_SPLIT OP_DROP OP_2 OP_ROLL OP_CHECKLOCKTIMEVERIFY OP_CAT OP_HASH160 <hjoint> OP_EQUALVERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG

대응하는 잠금 해제 스크립트는 아래에 나타나 있으며, 서명 sig_rP_B는 r을 사용하고 지출자 밥(B)은 임의의 개인/공개 키 쌍을 사용하여 서명을 계산할 수 있다.

추가 서명 sig'은 보안을 위해 추가된 기능이다(이후의 선택적 보안 기능에 대한 섹션 참조). 그러나 이것은 모든 가능한 실시예에서 요구될 필요는 없다.

이상은 연결의 관점에서 설명되었다. 그러나 이것을 일부 함수 f(r,d)로 일반화하는 것도 가능하다. 예를 들어 f는 r과 d의 덧셈일 수 있으며, 예를 들어 <r> <d> OP_ADD로 구현된다.

다중 R-값 명령문

다른 가능성은 서로 다른 명령문(statement)과 연관되어 잠금을 해제하는 r의 미리 결정된 여러 값, 예를 들어 r₁, r₂ 및 r₃을 갖는 것이다. 각 r_i에 명령문 S_i를 할당하면, 서명에서 대응하는 r_i를 사용하여 특정 명령문을 확인할 수 있다. 예를 들어, 이는 하나 또는 여러 개의 대체 가능한 계약 조건에 동의함을 나타내기 위해 서명하는 데 사용할 수 있다.

잠금 해제 스크립트에서 어떤 r 값이 사용되는지 확인하는 잠금 스크립트를 구성할 수 있으며, r 값에 대한 해석을 할당할 수 있다. 위의 아이디어를 구현하는 잠금 스크립트는 다음과 같을 수 있다:

OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP

OP_DUP OP_HASH160

OP_EQUAL

OP_IF

<명령문 1> OP_DROP OP_OVER OP_CHECKSIGVERIFY

OP_ELSE

OP_DUP OP_HASH160

OP_EQUAL

OP_IF

<명령문 2> OP_DROP OP_OVER OP_CHECKSIGVERIFY

OP_ELSE

OP_HASH160

OP_EQUAL

OP_IF

<명령문 3> OP_DROP OP_OVER OP_CHECKSIGVERIFY

OP_ENDIF

OP_ENDIF

OP_ENDIF

OP_CHECKSIG

모든 <명령문 i>는 대응하는 R-퍼즐을 해결한 후에만 접근할 수 있는 상이한 잠금 조건으로 대체된다. 잠금 해제 스크립트는 아래에 나타나 있으며 r_i는 설정된 명령문에 접근하는 데 필요한 고유한 r 값이다.

추가 서명 sig'은 다시 보안을 위한 선택적 추가 기능이다(이후 참조). 그러나 이것은 모든 가능한 실시예에서 요구될 필요는 없다.

R-퍼즐 정방향 체인

트랜잭션 Tx(i+1)를 지출하기 위한 충분 조건이 트랜잭션 Tx(i)의 지출 조건에 필요한 것과 동일한 지식에 하나의 추가 지식을 더한 것인 일련의 트랜잭션을 고려한다. 예를 들어, P₀,R₀(의 개인 키 부분)의 지식이 Tx0의 출력을 지출하는 데 필요하면, P₀,R₀,R₁(의 개인 키 부분)의 지식이 Tx1의 출력을 지출하기에 충분하다. 어떤 의미에서, 트랜잭션은 정방향 체인에서 함께 연결된다. [R_i]_x=r_i임에 유의한다. 예시적인 사용 사례는 토큰 r_i가 순서가 중요한 어떤 것에 대한 접근 토큰인 것이다. 예를 들어 각 토큰이 예를 들어 미디어 스트림의 서로 다른 각 부분에 대한 접근을 가능하게 하는 것이다.

도 14는 일련의 트랜잭션의 예를 도시한다.

예를 들어 앨리스가 토큰 r₀,r₁,r₂,… 를 소유하고 있으며 토큰 발행자는 해시

의 지식을 갖고 있다고 가정한다. 토큰 r_i는 이를 블록체인에 공개하고 k_i의 지식 증명을 증명함으로써 활성화되는 것으로 합의된다.

앨리스는 위에 주어진 일련의 트랜잭션을 생성하여 자신의 토큰을 활성화할 수 있다. 앨리스가 트랜잭션 Tx0을 브로드캐스팅할 때 그녀는 다음 트랜잭션에서 토큰 r₀을 활성화하기로 확약한다. 그녀가 Tx1을 브로드캐스팅할 때 r₀을 공개하고 k₀에 대한 지식 증명을 제공하여, 토큰을 활성화한다.

이 방법의 장점은 앨리스가 아니면 누구도 k₀에 대한 지식을 증명할 수 없기 때문에 토큰 r₀을 활성화할 수 없다는 것이다. 또한, 앨리스의 공개 키 P₀과 각 토큰의 활성화 사이에는 계층적 인증 링크가 있다. 또한, 보안을 유지하면서 트랜잭션의 크기를 절대적으로 최소화한다. 이는 토큰의 활성화를 디지털 서명에 통합함에 의해 달성된다.

토큰 r_i는 미리 생성된다. r_i의 실제 값 사이에 특별한 관계가 있을 필요는 없다. 또한, 도 14a에 도시된 공개 키 사이의 관계 P_i+1=P_i+R_i가 필수적인 것이 아님에 유의한다. 대안적으로 이는 임의의 또는 자유롭게 선택한 공개 키로 수행될 수 있다. 도 14a에 도시된 관계는 공개 키를 생성하는 편리한 방법일 뿐이다.

선택적 보안 기능 #1

k에 기초한 서명이 게시되면, k의 값을 아는 사람은 누구나 서명을 생성하는 데 사용된 비밀 키 V의 값을 도출할 수 있다. 이는 아래의 서명 식에서 V를 해결하여 수행할 수 있다:

V에 대해 풀면 다음을 얻는다:

많은 경우에 트랜잭션의 수신자가 k를 아는 유일한 사람이기 때문에 이것은 심각한 위험을 제기하지 않는다. 다른 경우에, 지출자는 R-퍼즐에 대한 해에 서명하는 데 사용된 개인 키 V를 재사용하지 않도록 주의해야 한다. 좋은 보안 관행은 사용자가 공개/개인 키 쌍(P,V)을 재사용하지 않는 것이 바람직한 것으로 나타나며, 새로운 돈을 받을 때 항상 새로운 공개/개인 키 쌍을 사용하는 것이 좋다.

원칙적으로 공개-개인 키 쌍(P,V)은 "영구적"이다. 즉, 여러 번 사용할 수 있다. 임의의 임시 키 k의 사용이 이를 보장한다. 그러나, 난수 생성기가 제대로 구현되지 않은 사건이 있었다.

동일한 임시 키 k와 동일한 개인 키를 사용하여 두 개의 다른 메시지에 서명하면, 두 서명에서 개인 키 V를 도출할 수 있다. 즉 (r,s) 및 k가 주어지면, V를 계산할 수 있다. 여기에서 r=[k·G]_x이고 V는 서명에 사용된 공개 키 P에 대한 개인 키이다. 난수 생성기가 서명 과정에서 실패하면, 지난번과 동일한 난수를 생성하여, 개인 키를 공개할 수 있다. 문제를 해결하기 위하여, 사람들은 난수 생성기를 수정하는 대신 공개 키를 재사용하지 않기 시작했다.

본 사례에서, 앨리스는 k를 알고 있지만, 밥의 공개 키에 대한 개인 키인 V를 알지 못한다. 앨리스가 밥에게 k를 넘길 때, 밥은 자신의 개인 키를 사용하여 (r,s)를 제공하여 r-퍼즐을 해결할 수 있다. 앨리스가 서명을 볼 때, k를 알고 있으므로, V를 도출할 수 있다. 이는 밥에게 바람직하지 않을 수 있다. 따라서 밥은 바람직하게는 (P,V)의 재사용을 피해야 한다.

그러나, 이에 대한 문제는 밥의 공개 키 P가 밥을 식별하는 지속적인 수단으로 사용될 수 없다는 것이다.

이를 해결하기 위하여, 본원에 개시된 실시예에 따르면, 밥은 대응하는 공개 키 P₂를 갖는 별도의 개인 키 V₂를 사용하여 Tx₂에 밥의 추가 서명 sig₂를 포함할 수 있다. 그는 또한 추가 서명과 함께 P₂를 포함한다. 따라서 두 가지 유형의 공개-개인 키 쌍이 있다. 제1 유형은 일회성 사용을 위해 즉석에서 생성되는 것이다. 다른 유형은 HD 지갑과 같은 일부 추가 프로토콜에 따라 생성되는 것이다. 밥은 r 퍼즐 서명에 제1유형의 키 쌍을 사용하고, 제2 서명에 제2유형을 사용할 수 있다.

그러면 앨리스는 제2 공개 키를 사용하여 공개 키와 신원 사이의 매핑에 기초하여 밥의 신원, 예를 들어 밥의 고유 이름, 사용자 이름 또는 네트워크 주소를 조회할 수 있다. 매핑은 예를 들어 공개 키를 신원에 매핑하는 공개 데이터베이스에서 사용 가능하게 만들 수 있거나, 또는 매핑이 앨리스와 밥 사이에서 간단히 사전 합의될 수 있다(예를 들어 앨리스의 컴퓨터 장비(102a)에 비공개로 저장됨).

서명 기관 사용 사례를 다시 고려한다. 예를 들어 앨리스는 배달을 받고 싶어 하지만 배달을 직접 수락할 수 없을 수 있다. 그녀는 밥과 찰리에게 k 사본을 제공하여 그들이 대신하여 배달을 수락할 수 있도록 한다. 데이브가 소포를 배달하고 있다. 그는 예상 r 값으로 서명을 받아야 한다. 이제 데이브가 자신의 기록 또는 규정 준수를 위해 수신자의 신원 또한 검증해야 한다고 상상한다.

밥이 배달을 수락하기 위해 거기 있다고 가정한다. 밥이 k에 기초하여 그의 공개 키와 서명을 생성하면, 앨리스와 찰리 모두 밥의 개인 키 V를 계산할 수 있다. 이는 공개 키가 한 번만 사용하도록 설계된 경우 문제가 되지 않는다. 그러나, 밥이 미래에 자신의 신원을 증명하기 위해 이 공개 키가 필요한 경우에는 이상적이지 않다.

이 문제를 해결하기 위하여, 실시예는 밥을 식별하는 데 사용할 수 있는 밥의 r-퍼즐과 무관한 하나 이상의 서명을 Tx₂에 포함할 수 있다. 예를 들어, 추가 서명과 대응하는 공개 키 P₂가 데이브가 수락하는 동일한 트랜잭션의 OP_RETURN 출력(지출 불가능한 출력)에 추가될 수 있다. 대안은 r-퍼즐 트랜잭션의 잠금 스크립트에 추가 OP_CHECKSIG를 포함하는 것이다. 앨리스는 트랜잭션과 추가 서명에 사용된 공개 키를 검색하여, 누가 그녀를 대신하여 서명했는지 알 수 있다.

일부 다른 경우에는, k 값이 사용 전에 누출될 수 있다는 우려가 있을 수 있다. 이 문제를 해결하기 위해, 앨리스는 P2PKH를 r-퍼즐 트랜잭션에 추가하여 더 안전하게 만들 수 있다. 앨리스가 그녀의 서명 권한을 밥에게 위임하려고 한다고 가정한다. 앨리스는 밥으로부터 일회성 공개 키 P₂를 얻고 r 값을 지정할 뿐만 아니라 추가 공개 키 P₂를 지정하는 r-퍼즐 트랜잭션을 생성한다.

앨리스 자신도 서명할 수 있도록, 선택적으로 앨리스는 1/2 MultiSig를 만들 수 있다. 잠금 스크립트의 예는 다음과 같다:

TxID
입력	출력
임의의 지출 입력	OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP <r> OP_EQUALVERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIGVERIFY OP_1 <Alice's PK> <Bob's P2> OP_2 OP_CHECKMULTISIG

r-퍼즐은 앨리스가 r-퍼즐의 해, 즉 서명 권한을 밥에게 전달할 때를 선택할 수 있으므로 더 많은 유연성을 제공함을 유의한다. 그녀는 트랜잭션이 채굴된 후에도 전달 여부를 결정할 수 있다.k가 누출되면, 사람들은 누출된 k로 서명에 서명하는 데 사용된 개인 키를 발견할 수 있다. 그러나 밥을 식별하는 데 사용할 수 있는 공개 키에 연결된 개인 키인 다른 개인 키 V₂가 있다. 출력이 손상되려면, 공격자가 두 개의 독립적인 비밀을 얻어야 하며, 이는 그 중 하나만 손상시키는 것보다 훨씬 가능성이 낮다.

위의 예에서, Tx₂의 잠금 스크립트는 기존의 P2PKH를 통해 밥의 추가 공개 키 P₂에 잠겨 있음(r-퍼즐에 사용된 것이 아니라 추가 서명에 의해 잠금 해제됨)을 유의한다. r-퍼즐 기술은 사용자에게 추가 선택을 허용한다. 일부 애플리케이션에서 증명자가 신원에 관계없이 문제를 해결할 수 있도록 r-퍼즐을 사용하는 것이 바람직할 수 있다. 반면 일부 다른 애플리케이션에서는 해시 퍼즐과 P2PKH의 조합이 여전히 바람직할 수 있으며, r-퍼즐은 선택적으로 이와 함께 사용할 수 있다. 이것은 나중에 더 자세히 논의될 것이다.

그러나 신원 조회 및/또는 보안을 위해 P₂에 대응하는 추가 서명이 필요하지만, Tx₁의 잠금 스크립트가 P2PKH에서와 같이 특정 증명자의 신원에 미리 묶여 있지 않은 경우, 그에 따라 위의 잠금 스크립트를 조정할 수 있다. 즉, 추가 서명에는 단순히 Checksig를 포함할 수 있지만, 대응하는 공개 키 P₂에 OP_EQUALVERIFY는 아니다.

선택적 보안 기능 #2

위 방법의 다른 잠재적인 보안 취약점은 서명 위조 가능성이다. 이는 자금을 청구하려는 채굴자가 악용할 수 있다(해시 퍼즐과 유사). (지출자로부터) 트랜잭션을 수신하는 채굴자는 지출자가 원래 트랜잭션에서 사용한 것과 동일한 서명을 사용하면서 자신에게 자금을 보내도록 트랜잭션을 변경할 수 있다. 이것은 다음과 같이 수행된다:

P=V·G를 다음과 같은 서명(r,s)을 얻기 위해 m으로 표시된 원래 트랜잭션에 서명하는 데 사용되는 공개/개인 키 쌍이라고 가정한다:

및

해당 트랜잭션을 지출하기 위하여, 지출자는 다음 잠금 해제 스크립트를 사용한다:

이 트랜잭션을 수신하는 채굴자는 다음과 같은 새로운 잠금 해제 스크립트를 사용하여 자신에게 자금을 보내는 m'으로 표시된 새로운 것으로 트랜잭션을 변경할 수 있다:

여기에서 P'=V'·G는 다음과 같은 공개/개인 키 쌍이다:

및

채굴자는 V'를 알 필요가 없다(V를 모르기 때문에)는 점을 유의한다. 검증 프로세스는 다음 계산을 사용하여 수행된다:

서명은 (R')_x=r인 경우 및 그 경우에만 유효하고, 그렇지 않으면 유효하지 않다.

새로운 트랜잭션 m'과 새로운 잠금 해제 스크립트를 사용하여, 검증 프로세스는 다음과 같다:

(프라임(') 표시는 여기에서 이전과 다른 의미를 갖는 점을 유의한다. 이 맥락에서 프라임 표시는 기준 인스턴스를 지칭하지 않는다.)

이 잠재적인 취약성을 해결하기 위하여, 실시예는 비밀 키 V를 알지 못하면 채굴자가 제공할 수 없는 다른 메시지 m_sighash 상의 잠금 해제 스크립트 내에 다른 추가 서명 sig'를 포함할 수 있다. 이 경우 잠금 해제 스크립트는 다음과 같다:

sig'는 다른 메시지 m_sighash 의 서명일 수 있으므로 메시지를 변경하기 위해 원래 것과 상이한 sighash 플래그를 사용한다(예를 들어 기본 플래그인 SIGHASH_ALL 대신 SIGHASH_NONE). 또한, sig'는 개인 키를 누출하지 않도록 상이한 r 값을 사용해야 한다(개인 키가 동일한 임시 키를 사용하는 두 서명으로부터 유도될 수 있기 때문이다). 마지막으로, 트랜잭션은 아래와 나타난 같이 끝에 다른 OP_CHECKSIG를 포함하여야 한다.

TxID
입력	출력
임의의 지출 입력	OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP <r> OP_EQUALVERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG

이는 r-퍼즐과 동일한 공개 키 P를 사용해야 하므로, 공개 키 P에 대한 개인 키 V를 아는 사람만이 다른 서명을 생성할 수 있으며, 위의 공격은 불가능하다.공격자는 공개 키를 공격자가 개인 키에 대해 알지 못하는 다른 공개 키로 교체하려고 한다. 이 공격을 방지하기 위해, 도전은 또한 개인 키에 대한 지식을 요청한다. 이 경우, 하나의 서명으로 충분하지 않다. 따라서, 두 개의 서명이 필요하다. 두 서명 모두 동일한 개인 키를 알고 있다는 증거로 간주된다. 이는 도전이 상이한 임시 키를 가질 것이라고 주장하므로 안전하다.

P2PKH + P2PRPH

R-퍼즐이 지식 증명으로 사용되는 것과 같은 방식으로, P2PKH 출력은 또한 P2PKH 출력의 공개 키에 대응하는 개인 키의 지식에 대한 지식 증명이다. 이는 본질적으로 P2PKH 출력에서 공개 키 P_puzzle=V_puzzle·G에 매핑되는 개인 키 V_puzzle로 퍼즐 k를 대체함으로써 수행된다. r-퍼즐의 실시예에서, 지식 증명은 증명자가 선택할 수 있고 신원에 연결하는 데 사용할 수 있는 공개 키를 동반한다. P2PKH에서, 일반적인 지출 서명 및 공개 키(비밀 퍼즐에 대한 지식을 증명함)는 특정 신원에 연결하기 위해 다른 서명 및 공개 키를 동반해야 한다. 간단하게, 증명자는 아래에 나타난 바와 같이 잠금 스크립트에 다른 OP_CHECKSIG에 대응하는 P2PKH 잠금 해제에 다른 서명과 공개 키를 추가할 수 있다.

TxID
입력	출력
임의의 지출 입력	OP_DUP OP_HASH160 <H(Ppuzzle)> OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_CHECKSIG

대응하는 잠금 해제 스크립트는 다음과 같다:

<sigP_ID><P_ID>와 퍼즐 또는 트랜잭션 사이에는 암호화 링크가 없음을 유의한다. 채굴자 및 누구라도 실제로 이를 다른 공개 키의 다른 서명으로 대체할 수 있으며, 이는 채굴자가 공개 해시 퍼즐을 가로챌 수 있는 방식과 약간 유사하다. 채굴자나 가로채는 사람은 자신에게 자금을 보내기 위하여 메시지를 변경할 수 없다(오픈 해시 퍼즐의 경우와 같이). 그러나 <sigP_ID><P_ID>를 자신의 것으로 바꾸어 자신의 정체성과 연결되어 있는 것처럼 보이게 하는 것을 막을 방법은 없다.

한편, 본원에 개시된 기술에 기초하여, 동일한 스크립트에서 P2PKH 및 P2RPH를 함께 사용하여 위의 경우와 같이 가로채거나 대체될 수 없도록 제2 서명에 대한 암호화 링크를 강제 실행하는 것이 가능하다.

TxID
입력	출력
임의의 지출 입력	OP_DUP OP_HASH160 <H(Ppuzzle)> OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <H(Ppuzzle)> OP_EQUALVERIFY OP_SWAP OP_CHECKSIG

잠금 스크립트에서, P_puzzle=V_puzzle·G이고 r=[R]_x=[V_puzzle·G] _x 이므로 이들은 기본적으로 동일하다. 공개 키는 압축되거나 압축 해제될 수 있고, 어느 쪽이든 접두사가 앞에 붙기 때문에 실제로는 동일하지 않다. 아래와 같이 〈H(P_puzzle)〉=〈H(r_puzzle)〉로 만들기 위해 서명에서 r 값을 추출할 때 스크립트에 명시적으로 접두사를 추가하는 것도 가능하다. 그러나, 이것은 실제로 많은 이점을 얻지 못한다.

TxID
입력	출력
임의의 지출 입력	OP_DUP OP_HASH160 <H(Ppuzzle)> OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_PUSHDATA <r-prefix> OP_SWAP OP_CAT OP_HASH160 <H(Ppuzzle)> OP_EQUALVERIFY OP_SWAP OP_CHECKSIG

(잠금 스크립트의 도식 표현에서 H(…)가 삼각형 괄호 <>로 언급된 경우, 이것은 실제로 해시 함수가 아니라 해시 값을 나타내기 위하여 의도한 것임을 유의한다. 삼각 괄호 <>는 이 값을 스택에 배치하는 것을 의미한다.)두 트랜잭션에 대한 대응하는 잠금 해제 스크립트는 다음과 같다:

계정 기반 모델의 대안적 구현

이상은 주로 출력 기반 모델(예를 들어 UTXO 기반 모델)에서의 구현 측면에서 설명되었다. 그러나 이것이 제한적이지 않음을 이해할 것이다. 도 11은 계정 기반 모델을 사용하여 가능한 대안적인 구현을 도시한다.

간단히 말해서, 계정 기반 모델에서, r-퍼즐 기능은 사용자가 호출하는 스마트 계약 기능에 포함될 수 있다. 한 당사자는 스마트 계약에서 r-퍼즐 값(또는 해시된 r-퍼즐 값)을 설정할 수 있으며 다른 당사자는 나중에 스마트 계약에 서명을 제공한다.

UTXO 블록체인 아키텍처에서, 제1 트랜잭션의 잠금 해제 스크립트에 구현된 요구 사항은 제2 트랜잭션이 유효한 것으로 수락되고 블록체인에 기록되기 위해 제2 트랜잭션의 잠금 스크립트에 의해 충족되어야 한다. 본 맥락에서, 이는 트랜잭션 유효성 검증 프로세스의 일부로 채굴자가 이미 수행한 작업을 활용하기 때문에 유용하다. 본 맥락의 구체적인 예로서, 트랜잭션이 블록체인에 추가되었다는 사실은 블록체인 네트워크 전체에 걸쳐 노드에서 트랜잭션이 검증되었음을 의미하며, 이는 차례로 그 잠금 스크립트가 몇 가지 특정 유용한 요구 사항을 충족함을 의미한다. 이해 당사자는 이러한 요구 사항이 충족되었는지 여부를 스스로 확인할 필요가 없다. 트랜잭션이 블록체인에서 성공적으로 기록되었다는 사실 덕분에 이러한 요구 사항이 충족되었다고 가정할 수 있다. 이는 트랜잭션이 유효하기 위해 스크립트가 완료 시 "참"의 결과를 반환해야 하고(트랜잭션이 유효하기 위한 다른 요구 사항이 있을 수 있음), 스크립트가 "거짓"의 결과를 반환하면(본원에서 사용된 용어에 따르면, 예를 들어 OP_VERIFY 작업코드가 스크립트를 종료하기 때문에 스크립트가 실패한 경우를 포함함), 트랜잭션은 유효하지 않다는 사실에 기인한다.

그러나, 다른 블록체인 모델(예를 들어 특정 계정 기반 아키텍처)에서, 트랜잭션 유효성과 트랜잭션 코드 실행 결과 사이의 이러한 상호 의존성이 반드시 반영되는 것은 아니다. 예를 들어, 특정 스마트 계약 블록체인에서, 트랜잭션이 블록체인 프로토콜에 의해 부과된 "기본" 유효성 요구 사항 집합을 충족하는 경우 유효할 수 있으므로 블록체인에 기록을 위해 수락된다. 따라서 제2 트랜잭션은 제1 트랜잭션의 코드에 구현된 일부 요구 사항을 충족하지 않더라도 유효한 것으로 수락되고 블록체인에 기록될 수 있다. 제1 트랜잭션의 코드는 예를 들어 스마트 계약 코드일 수 있다.

제2 트랜잭션이 제1 트랜잭션에 의해 생성된 스마트 계약 계정으로 주소가 지정되었다고 가정하면, 스마트 계약 코드에 따라 해당 트랜잭션에 응답하는 방법이 결정된다. 일부 요구 사항이 충족되지 않는 경우 예를 들어 이를 무시(또는 그렇지 않으면 거짓의 결과를 반환)할 수 있는 한편, 해당 요구 사항이 정확하면, 스마트 계약 계정의 잔액에서 공제되고 신용된 디지털 자산의 양으로 증명자에게 보상(또는 그렇지 않으면 참의 결과를 반환)할 수 있다. 어떤 의미에서, 이는 스마트 계약(에이전트)에 의한, 즉 스마트 계약 코드 내에 명시적으로 부호화된, "에이전트-수준" 처리를, 노드에 의해 "묵시적으로" 수행되는 "프로토콜-수준" 처리, 즉 트랜잭션에서 수행되는 블록체인 네트워크가 작동하는 블록체인 프로토콜에 의해 부과된 유효성 요구 사항을 충족하는 지 결정하는 처리로부터 추출한다. 따라서, 이러한 블록체인 아키텍처에서, 각 트랜잭션의 프로토콜 수준에서 노드에 의한 "유효/무효" 결정은 트랜잭션이 프로토콜 수준에서 유효한 것으로 결정될 수 있지만 그럼에도 불구하고 에이전트 수준에서 거짓의 결과를 반환한다는 점에서 스마트 계약에 의해 에이전트 수준에서 해당 트랜잭션과 관련하여 반환된 "참/거짓" 결과에서 분리될 수 있다.

이것은 트랜잭션이 유효하기 위해 "참"의 결과를 반환하는 스크립트가 필요한, UTXO 아키텍처와 대조된다. 스크립트가 종료되거나 스택에 참이 아닌 다른 항목을 남기고 완료되면(이러한 결과 중 하나가 본원에서 사용된 용어 "거짓"의 결과를 구성함) 트랜잭션은 유효하지 않다.

트랜잭션 유효성에 대한 기본 요구 사항 중 하나는 트랜잭션이 유효한 서명을 포함한다는 것일 수 있다. 따라서, 위의 UTXO 예에서, 서명은 (예를 들어 서명을 검증하고 서명 검증에 대해 참/거짓을 반환하는 OP_CHECKSIG 작업코드 또는 동일한 방식으로 서명을 확인하고 추가로 결과가 참인지 검증하며, 그렇지 않은 경우 스크립트를 종료하는 OP_CHECKSIGVERIFY 작업코드를 사용하여) 도전 트랜잭션 자체의 코드로 검증되는 반면, 대안적인 블록체인 아키텍처에서 서명은 위의 의미에서 처리 노드에 의해 묵시적으로 검증될 수 있으므로, 트랜잭션 코드 자체 내에서 서명 확인을 코딩할 필요가 없다.

본 맥락의 구체적인 예로서, 트랜잭션은 프로토콜 수준에서 유효한 것으로 간주될 수 있다. 왜냐 하면 이는 유효한 서명을 포함하지만, 애플리케이션 수준에서 여전히 거짓의 결과를 반환하기 때문이며 예를 들어 일부 다른 요구 사항이 충족되지 않기 때문이다.

도 11은 계정 기반 모델에 따라 트랜잭션을 처리하는 노드 소프트웨어(400)의 대안을 나타내며, 노드 소프트웨어는 여기에서 400acc로 표시된다. 이 노드 소프트웨어(400acc)의 인스턴스는 네트워크(106)의 계정 기반 버전의 노드(104) 각각에서 구현될 수 있다. 계정 기반 노드 소프트웨어(400acc)는 계정 기반 프로토콜 엔진(401acc), 계약 엔진(402acc)(스크립트 엔진(402)과 다소 유사함), 애플리케이션 레벨 의사결정 엔진(404), 및 하나 이상의 블록체인 관련 기능 모듈(405) 세트를 포함한다. 임의의 주어진 노드(104)에서, 이들은 채굴 모듈(405M), 전달 모듈(405F) 및 저장 모듈(405S)(노드의 역할에 따라 다름) 중 임의의 하나, 둘 또는 세 개 모두를 포함할 수 있다. 프로토콜 엔진(401acc)은 트랜잭션의 상이한 필드를 인식하고 노드 프로토콜에 따라 처리하도록 구성된다. 노드 소프트웨어(400acc)는 또한 각자의 노드(104)의 메모리에 복수의 계정 각각의 계정 상태(406)를 유지한다. 이들은 예를 들어 앨리스, 증명자(예를 들어 밥) 및/또는 앨리스와 증명자 사이에 제정될 계약에 따라 출금 또는 신용을 받을 다른 당사자의 계정을 포함할 수 있다. 계약 엔진(402acc)은 트랜잭션에서 수신된 스마트 계약의 결과에 따라 계정 상태를 수정하도록 배열된다. 스마트 계약은 또한 "에이전트"로도 지칭된다.

도 11은 또한 도 7에서 10과 관련하여 위에서 설명한 것과 동일하거나 유사한 r-퍼즐 기능을 구현할 수 있는 트랜잭션 Tx₁ ^acc 및 Tx₂ ^acc를 나타낸다. 각각은 (출처 주소 필드에서) 출처 계정 주소(1102) 및 (목적지 주소 필드에서) 목적지 계정 주소(1103)를 포함한다. 제1 트랜잭션 Tx₁ ^acc는 출처 계정 주소(1102a)와 목적지 계정 주소(1103a)를 포함한다. 제2 트랜잭션 Tx₂ ^acc는 출처 계정 주소(1102b)와 목적지 계정 주소(1103b)를 포함한다. 제1 트랜잭션 Tx₁ ^acc는 또한 스마트 계약(1101)을 포함한다. 스마트 계약(1101)은 앨리스에 의한 도전(퍼즐)을 포함할 수 있다. 이는 앨리스 가 생성하거나 또는 앨리스가 제공한 세부 정보를 사용하여 앨리스를 대신하여 제3자가 생성할 수 있다. 제2 트랜잭션 Tx₂ ^acc는 사용자 지정 페이로드 데이터를 운반하기 위한 하나 이상의 자유 데이터 필드(1104)를 선택적으로 포함할 수 있다. 이것은 증명자, 예를 들어 밥이 제공한 퍼즐에 대한 해의 적어도 일부를 포함할 수 있다. 트랜잭션 Tx₁ ^acc 및 Tx₂ ^acc는 또한 앨리스와 증명자가 각각 서명한다. 각 트랜잭션은 또한 각 당사자의 서명(1105a, 1105b)을 포함한다.

트랜잭션은 네트워크(106)를 통해 브로드캐스팅된다. 프로토콜 엔진(401acc)이 각 트랜잭션을 수신할 때 서명(1105)의 유효 여부를 묵시적으로 검증한다. 즉 이는 프로토콜 엔진(401acc)의 고유한 특징이며 스마트 계약(1101)에 명시될 필요가 없다. 따라서 프로토콜 엔진(401acc)은 적어도 각자의 서명이 유효한 조건에서 전달 및/또는 채굴을 위해 각 트랜잭션을 유효성 검증한다. 또한 유효성이 충족되려면 하나 이상의 추가 조건이 필요할 수 있다. 유효하다면, 애플리케이션 레벨 의사결정 엔진(404)은 트랜잭션을 각각 채굴 및/또는 전달하기 위해 채굴 모듈(405M) 및/또는 전달 모듈(405F)의 제어 여부를 선택할 수 있다.

이러한 계정 기반 모델에서, 앨리스, 밥 및 스마트 계약 자체에는, 상이한 계정 주소를 갖는, 별도의 계정이 할당된다. 트랜잭션은 출처 주소 필드의 주소"로부터(from)", 목적지 주소 필드의 주소"로(to)" 전송된다고 한다. 스마트 계약에 대한 계정을 생성하기 위하여, 트랜잭션에서 스마트 계약에 대한 바이트코드를 포함하는 트랜잭션이 블록체인으로 업로드된다. 이러한 계정 생성 트랜잭션의 경우, 목적지 필드의 목적지 주소(1103)는 블록체인에서 이전에 사용된 적이 없는 주소여야 하며, 트랜잭션이 일단 수락되면, 해당 주소가 새로 생성된 스마트 계약 계정의 주소가 된다. 그 후, 스마트 계약을 "호출"하기 위해, 즉 스마트 계약의 바이트코드가 추가 트랜잭션에 따라 실행되도록 하기 위해, 추가 트랜잭션을 해당 주소로 보낼 수 있다. "목적지" 주소(1103)는 계약을 제정하기 위한 중개 주소 역할을 한다. 앨리스는 하나 이상의 요구 사항을 지정하는 스마트 계약을 생성하기 위해 Tx₁ ^acc를 해당 주소로 보낸다. 밥은 스마트 계약을 호출하기 위해 해당 동일한 주소로 Tx₂ ^acc를 보내고, 그러면 스마트 계약이 Tx₂ ^acc가 이들 지정된 요구 사항을 충족하는지 여부를 확인하게 된다. "출처" 주소(1102)는 계약 당사자인 사용자의 계정을 지정한다. 스마트 계약이 Tx₂ ^acc가 지정된 요구 사항을 충족한다고 결정하는 경우, 스마트 계약은 자신의 계정 잔액에서 디지털 자산의 금액을 공제하고, Tx₂ ^acc 내의 출처 주소(1102b)를 갖는 계정(즉, 밥의 계정)의 잔액이 해당 금액만큼 적립되게 하도록 구성될 수 있다(직관적으로, Tx₂ ^acc를 보냄으로써, 밥은 그의 계정(출처 주소 필드에서 식별됨)에 적립하도록 스마트 계약(목적지 주소 필드에서 식별됨) 에 사실상 요청한다).

프로토콜 엔진(401acc)이 X₂ ^acc를 수신하면, 그것이 유효한 조건에서, Tx₂ ^acc 의 목적지 주소(1103b)와 일치하는 계정을 찾을 것이다. Tx₁ ^acc가 처리되고 유효하다고 가정하면, 해당 계정은 Tx₁ ^acc 덕분에 존재하고 Tx₁에 제공된 스마트 계약 코드와 연관된다. 이에 대한 응답으로, 프로토콜 엔진(401acc)은 계약 엔진(402acc)을 제어하여 Tx₁ ^acc에서 스마트 계약(1101)을 실행하고, 계약에 정의된 기준에 따라, 스마트 계약의 하나 이상의 필드에서 데이터를 피연산자 데이터로 취한다. 피연산자 데이터는 예를 들어 하나 이상의 자유 데이터 필드(1104)로부터의 데이터 및/또는 서명 필드(1105b)로부터의 서명을 포함할 수 있다. Tx₂ ^acc의 피연산자 데이터가 Tx₁ ^acc의 스마트 계약(1101)에 정의된 하나 이상의 기준을 충족하는 조건에서 계약 엔진(402acc)은 스마트 계약(1101)에 정의된 수정에 따라 하나 이상의 당사자(앨리스, 증명자 및/또는 하나 이상의 제3자)의 계정 상태(406)를 수정한다. 그렇지 않으면 계정 상태(406)에 대한 이러한 수정이 이루어지지 않는다. 그러나 일부 계정 기반 시스템에서, 스마트 계약의 결과는 트랜잭션의 유효성을 위한 조건이 아님을 유의한다. 따라서 Tx₂ ^acc가 Tx₁ ^acc의 스마트 계약(1101)에 설정된 기준을 충족하지 못하면, Tx₂ ^acc는 여전히 전파되고 실패한 트랜잭션의 기록으로 블록으로 채굴된다. 이는 또한 여전히 채굴 수수료에 영향을 미칠 수 있다(따라서 프로토콜 엔진(401)은 당사자 중 하나와 승리한 채굴자의 계정 상태(406)를 여전히 수정할 수 있다).

r-퍼즐을 구현하기 위해, r-퍼즐 기능의 적어도 일부는 Tx₁ ^acc의 스마트 계약(1101)에 코딩될 수 있고, 해는 Tx₂ ^acc의 하나 이상의 데이터 필드(1104)에 제시될 수 있다. 예를 들어 이는 도 7의 변형을 구현하는 데 사용될 수 있다. 선택적으로, 프로토콜 엔진(401acc)의 묵시적 서명 검증 기능 중 일부, 예를 들어 도 8 내지 도 10의 변형 중 하나를 구현하기 위하여 악용될 수 있다. 도 8 내지 도 10의 경우, 단계 II) 및 III)은 Tx₂ ^acc의 서명을 검증할 때 프로토콜 엔진(401acc)의 음함수(implicit function)일 수 있다(서명 검증 그 자체가 프로토콜 엔진(401acc)에 의해 구현되는 노드 프로토콜의 고유한 기능임을 기억할 것). 따라서 Tx₁ ^acc의 스마트 계약(1101)에서 이것 위에 단계 I)를 계층화하는 것만이 필요하다. 스마트 계약은 I)의 결과가 참인지 및 프로토콜 엔진(401ac)이 Tx₂ ^acc가 유효함을 나타내는지 여부를 확인한다. 둘 모두 예인 경우, 검증에 대한 전체 결과가 "참"으로 선언된다. 즉, 밥이 r-퍼즐에서 설정한 도전을 성공적으로 충족하였다. 도 8 내지 도 10의 구현에서, 도 9 및 10의 경우의 데이터 값 d만이 자유 데이터 필드(1104)에 포함될 필요가 있음을 유의한다. 서명 정보는 서명 필드(1105b)에 포함된다.

스마트 계약 계정은 또한 계정과 연관된 (논리적) 데이터 저장 요소인 색인된 "데이터 레지스터"(미도시)를 갖는다. 위에 요약된 UTXO 모델에서, 값은 잠금 스크립트 자체에 포함되며, 스마트 계약 코드(1101)의 특정 부분에서도 마찬가지일 수 있다. 그러나, 스마트 계약의 스마트 계약 바이트코드는 대안적으로 또는 추가적으로 하나 이상의 그 계정 레지스터에 저장된 데이터에 대해 실행될 수 있다. 또한, 일반적으로 스마트 계약 계정이 생성된 후 스마트 계약 계정 레지스터에 값을 저장할 수 있다. 따라서, 예를 들어, 스마트 계약 계정은 스마트 계약 바이트코드를 포함하는 도전 트랜잭션 Tx_1,α ^acc에 의해 생성될 수 있다. 그런 다음 별도의 "중간" 트랜잭션 Tx_1,β ^acc가 (현재 존재하는) 스마트 계약 계정으로 전송될 수 있으며, 이는 스마트 계약 계정의 레지스터 $R에 특정 값 v를 저장하는 효과가 있다. 스마트 계약은 지정된 출처 계정 주소(예를 들어 처음에 스마트 계약을 생성한 동일한 당사자(앨리스))로부터의 그러한 데이터만을 수락하도록 구성될 수 있다. Tx₂ ^acc가 수신되면, 계약 엔진(402acc)에 의해 수행되는 작업(예를 들어 "레지스터 $R에 접근하고 Tx₂ ^acc의 데이터 필드 $D에 있는 값과 값 비교")이 도전 트랜잭션 Tx_1,α ^acc에 제공된 스마트 계약 바이트코드에 의해 정의된다. 그러나 $R에 저장된 값은 중간 트랜잭션 Tx_1,β ^acc에 의해 설정되었다. 본원에서 사용된 용어에 따르면, Tx_1,α ^acc는 여전히 하나 이상의 요구 사항을 설정하는 도전 트랜잭션이라고 하며, 이제 이러한 요구 사항은 하나 이상의 중간 트랜잭션(예를 들어 Tx_1,β ^acc) 내에 제공될 데이터를 참조할 뿐이다.

따라서, 일부 구현에서, 도전 트랜잭션 Tx_1,α ^acc는 r-퍼즐의 작업을 정의할 수 있지만(예를 들어 증명 트랜잭션 Tx₂ ^acc의 서명의 r-부분을 레지스터 $R의 값과 비교하여 일치하는지 확인 등) 증명 트랜잭션 Tx₂ ^acc의 r-부분과 비교되는 $R의 값은 중간 트랜잭션 Tx_1,β ^acc에 의해 설정되었을 수 있다.

참고: 또한 일부 계정 기반 모델은 공개 키 P가 서명(1105)에 포함될 필요가 없다. 대신 1비트 플래그 flg를 포함하기만 하면 된다. 언급한 바와 같이, (r,s)와 메시지에서 두 개의 가능한 키 P 및 -P를 유도하는 것이 가능하다. 플래그 flg는 이러한 두 가지 가능한 해 중 실제로 Tx₂ ^acc의 메시지에 서명하기 위해 증명자가 사용하는 개인 키 V에 대응하는 공개 키를 나타내는 데 사용된다. 프로토콜 엔진(401acc)은 Tx₂ ^acc에서 명시적으로 수신하는 대신 (r,s) 및 flg를 사용하여 증명자의 공개 키 P를 유도한다. 이 기술은 출력 기반 모델에서도 가능하며 계정 기반 모델에만 국한되지 않지만, 현재 많은 출력 기반 모델에서 사용되는 스크립팅 언어에는 r과 s에서 P를 유도하기 위한 전용 작업코드가 없기 때문에, 스택 기반 언어의 기존 범용 작업코드를 사용하여 잠금 해제 스크립트에 이 기능을 명시적으로 코딩하는 것은 복잡하다. 또한, 특정 계정 기반 모델은 해당 트랜잭션에 서명하는 데 사용되는 공개 키에서 트랜잭션의 출처 주소를 유도한다. 따라서, 출처 주소가 반드시 트랜잭션에서 별도로 인코딩되는 것은 아니며, 공개 키가 서명에서 유도되는 경우, 출처 주소도 서명에서 간접적으로 유도될 수 있음을 의미한다.

결론

위의 실시예들은 단지 예로서 설명되었다는 것을 이해할 것이다.

더 일반적으로, 본원에 개시된 기술의 제1 예시에 따르면, 타원 곡선 디지털 서명 알고리즘(ECDSA) 검증 함수에 기초하여 지식 증명을 수행하는, 컴퓨터 구현 방법이 제공된다. 방법은, 블록체인 네트워크의 검증 노드에서: 실행 가능한 코드를 포함하는 제1 트랜잭션을 획득하는 것-코드는 제1 ECDSA 서명에 대한 r-부분의 기준 인스턴스를 지정하는 요소를 포함함-; 적어도 제1 ECDSA 서명의 s-부분을 포함하는 정보를 포함하는 제2 트랜잭션을 수신하는 것, 및 제1 공개 키를 획득하는 것-제1 ECDSA 서명은 제1 공개 키에 대응하는 제1 개인 키에 기초하여 메시지에 서명하고, 메시지는 제2 트랜잭션의 일 부분임-; 및 제1 트랜잭션으로부터 코드를 실행하는 것을 포함한다. 코드는 제1 개인 키로 누구의 개인 키가 사용되었는지에 무관하게: 제2 트랜잭션 내에서 수신된 메시지 및 획득된 제1 공개 키가 주어지면, 제1 ECDSA 서명에 적용된, ECDSA 검증 함수가 제2 트랜잭션 내에서 수신된 s-부분이 제1 트랜잭션에 의해 지정된 r-부분의 기준 인스턴스에 대응하는 것을 검증하는 조건에서 참의 결과를 반환하도록 구성된다.

출력 기반 모델(예를 들어 UTXO 기반 모델)에서, ECDSA 검증 함수는 제1 트랜잭션의 출력(예를 들어 UTXO)의 잠금 스크립트에 있는 작업코드에 의해 호출될 수 있다. 작업코드는 검증 노드에 미리 저장된 ECDSA 검증 함수의 인스턴스를 호출할 수 있다. 대안적으로, 계정 기반 모델에서와 같이, ECDSA 검증 함수는 제1 트랜잭션(계정 기반의 경우 스마트 계약일 수 있음) 내의 코드에 의해 명시적으로 호출되어야 하는 대신, 노드 프로토콜의 일부로 자동으로 실행되는, 노드의 음함수(implicit function)일 수 있다. 다른 대안으로 ECDSA 검증이 코드에 명시적으로 코딩될 수 있다는 점을 배제하지 않는다.

본 개시된 교시의 제2 선택적 예시에 따르면, 상기 요소는 제1 ECDSA 서명의 r-부분의 기준 인스턴스인, 제1 예시에 따른 방법이 제공될 수 있다.

본 개시의 제3 선택적 예시에 따르면,

상기 ECDSA 검증 함수는:

계산, 및

확인을 수행하고,

r'는 제1 ECDSA 서명의 r-부분의 기준 인스턴스이고, s는 제1 ECDSA 서명의 s-부분이고, P는 제1 공개 키이고, m은 제1 ECDSA 서명에 의해 서명된 제2 트랜잭션의 부분이고, H_sig은 제1 ECDSA 서명의 생성에서 m을 해시하기 위하여 사용된 해시 함수이고, G는 타원 생성기 점이고, [R']_x은 R'의 x 좌표를 나타내고, "ㆍ" 는 타원 곡선 스칼라 곱셈을 나타내는, 제2 예시에 따른 방법이 제공될 수 있다. 이 경우 코드는 상기 확인이 참인 조건에서 참의 결과를 반환하고, 그렇지 않으면 거짓의 결과를 반환하도록 구성된다.

제4 선택적 예시에 따르면, 제2 트랜잭션 내에서 수신된 정보는 제1 ECDSA 서명의 r-부분의 제출된 인스턴스를 더 포함하고, 코드는 r-부분의 제출된 인스턴스가 기준 인스턴스와 동일한지 확인하도록 구성되는, 제1 또는 제2 예시에 따른 방법이 제공될 수 있다.

제5 선택적 예시에 따르면, 상기 ECDSA 검증 함수는 제2 트랜잭션 내에서 수신된 s-부분이 r-부분의 제출된 인스턴스에 대응하는지 확인하고, 상기 검증은 두 가지 확인을 함께 사용하여 그것이 기준 인스턴스에 대응한다는 것인, 제4 예시에 따른 방법이 제공될 수 있다.

제6 선택적 예시에 따르면, 코드는:

r' = r의 확인을 수행하도록 구성되고,

ECDSA 검증 함수는:

계산, 및

확인을 수행하고,

r은 제1 ECDSA 서명의 r-부분의 제출된 인스턴스이고, r'는 제1 ECDSA 서명의 r-부분의 기준 인스턴스이고, s는 제1 ECDSA 서명의 s-부분이고, P는 제1 공개 키이고, m은 제1 ECC 서명에 의해 서명된 제2 트랜잭션의 부분이고, H_sig은 제1 ECDSA 서명의 생성에서 m을 해시하기 위하여 사용된 해시 함수이고, G는 타원 생성기 점이고, [R']_x은 R'의 x 좌표를 나타내고, "ㆍ" 는 타원 곡선 스칼라 곱셈을 나타내는, 제2 예시에 따른 제5 예시에 따른 방법이 제공될 수 있다. 이 경우 코드는 두 개 모두의 상기 확인이 참인 조건에서 참의 결과를 반환하고, 그렇지 않으면 거짓의 결과를 반환하도록 구성된다.

제7 선택적 예시에 따르면, 상기 요소는 제1 ECDSA 서명의 r-부분의 기준 인스턴스의 변환인, 제4 또는 제5 예시에 따른 방법이 제공될 수 있다. 이 경우 코드는 제출된 인스턴스에 대해 동일한 변환을 수행함에 의하여 제출된 인스턴스가 기준 인스턴스와 동일한지 상기 확인을 수행하도록 구성된다.

제8 선택적 예시에 따르면, 상기 요소는 제1 ECDSA 서명의 r-부분의 기준 인스턴스를 포함하는 구성요소의 해시인(상기 변환이 해시임), 해시 값인, 제7 예시에 따른 방법이 제공될 수 있다.

제9 선택적인 예시에 따르면, 상기 구성요소는 제1 ECDSA 서명의 r-부분의 기준 인스턴스 r'이고, 코드는:

의 확인을 수행하도록 구성되고,

ECDSA 검증 함수는:

계산, 및

확인을 수행하고,

r은 제1 ECDSA 서명의 r-부분의 제출된 인스턴스이고, s는 제1 ECDSA 서명의 s-부분이고, h는 해시 값이고, H_puz 는 h를 생성하기 위하여 r'를 해시하는 데 사용된 해시 함수이고, P는 제1 공개 키이고, m은 제1 ECC 서명에 의해 서명된 제2 트랜잭션의 부분이고, H_sig은 제1 ECDSA 서명의 생성에서 m을 해시하기 위하여 사용된 해시 함수이고, G는 타원 생성기 점이고, [R']_x은 R'의 x 좌표를 나타내고, "ㆍ" 는 타원 곡선 스칼라 곱셈을 나타내는, 제5 예시에 따른 제8 예시에 따른 방법이 제공될 수 있다. 이 경우 코드는 두 개 모두의 상기 확인이 참인 조건에서 참의 결과를 반환하고, 그렇지 않으면 거짓의 결과를 반환하도록 구성된다.

H_puz는 해시 퍼즐에 사용되는 해시 함수이다. H_sig는 ECC 서명 및 검증에 사용되는 해시 함수이다. H_puz 및 H_sig는 동일한 형태의 해시 함수일 수도 있고 아닐 수도 있다.

제10 선택적 예시에 따르면, 상기 구성요소는 제1 ECDSA 서명의 r-부분의 기준 인스턴스 r'와 데이터 값의 기준 인스턴스 d'의 조합

이고, 제2 트랜잭션 내에서 수신된 정보는 제1 ECDSA 서명의 r-부분의 제출된 인스턴스 r와 데이터 값의 제출된 인스턴스 d를 더 포함하는, 제5 예시에 따른 제8 예시에 따른 방법이 제공될 수 있다. 코드는:

=

의 확인을 수행하도록 구성되고,

상기 ECDSA 검증 함수는:

계산, 및

확인을 수행하고,

s는 제1 ECDSA 서명의 s-부분이고, h_joint는 해시 값이고, H_puz 는 h_joint를 생성하기 위하여

를 해시하는 데 사용된 해시 함수이고, P는 제1 공개 키이고, m은 제1 ECC 서명에 의해 서명된 제2 트랜잭션의 부분이고, H_sig은 제1 ECDSA 서명의 생성에서 m을 해시하기 위하여 사용된 해시 함수이고, G는 타원 생성기 점이고, [R']_x은 R'의 x 좌표를 나타내고, "ㆍ" 는 타원 곡선 스칼라 곱셈을 나타낸다. 이 경우 코드는 두 개 모두의 상기 확인이 참인 조건에서 참의 결과를 반환하고, 그렇지 않으면 거짓의 결과를 반환하도록 구성된다.

다시 H_puz 및 H_sig는 동일한 유형의 해시 함수일 수도 있고 아닐 수도 있다.

제11 선택적 예시에 따르면, 상기 조합 f는 연결이고,

는

이며,

는

인, 제10 예시에 따른 방법이 제공될 수 있다.

제12 선택적 예시에 따르면, 데이터 값은 목표 시점을 지정하는 잠금 시간 값을 포함하고, 코드는 목표 시점에 도달하는 추가 조건에서 참의 결과를 반환하도록 구성되는, 제10 또는 제11 예시에 따른 방법이 제공될 수 있다.

잠금 시간 값은 인간 시간의 관점에서, 예를 들어 밀리초, 초, 분, 시간, 일, 주, 월 또는 년으로 목표 시점을 지정할 수 있다. 대안적으로 잠금 시간 값은 블록 수의 관점에서 목표 시점을 지정할 수 있다. 어느 쪽이든, 지정된 시점은 절대 시간으로 지정되거나, 정의된 지점, 예를 들어 제1 트랜잭션이 블록체인의 블록으로 채굴되는 지점으로부터 경과하는 시간의 양으로 지정될 수 있다.

제13 선택적 예시에 따르면, 제1 공개 키를 상기 획득하는 것은 제2 트랜잭션 내의 정보의 일부로서 제1 공개 키를 수신하는 것을 포함하는, 제1 내지 제12 예시 중 어느 하나에 따른 방법이 제공될 수 있다.

대안적으로, 제2 트랜잭션 내의 정보는 제1 ECDSA 서명의 r-부분의 제출된 인스턴스와 s-부분 모두를 포함하고, 상기 획득하는 것은 제1 ECDSA 서명의 r-부분의 제출된 인스턴스와 s-부분의 조합으로부터 제1공개 키를 유도하는 것을 포함한다.

다른 대안으로서, 획득하는 것이, 예를 들어, 제2 트랜잭션과 연관된 사이드 채널을 통해 제1 공개 키를 수신하는 것; 또는 제2 트랜잭션에서 또는 사이드 채널을 통해, 제1 공개 키의 색인 또는 제1 공개 및 개인 키 소유자의 신원을 수신하고 이를 사용하여 제1 공개 키를 조회하는 것을 제외하지 않는다.

제14 선택적 예시에 따르면, 코드는 제2 ECDSA 서명의 r-부분의 기준 인스턴스를 더 지정하고; 코드는 복수의 대체 조건 중 어느 하나가 충족되면 참의 결과를 반환하도록 구성되는, 제1 내지 제13 예시 중 어느 하나에 따른 방법이 제공될 수 있다. 이 경우 대체 조건은: i) 제1 ECDSA 서명에 의해 서명된 제2 트랜잭션의 부분과 제1 공개 키가 주어지면 제1 ECDSA 서명의 s-부분이 제1 ECDSA 서명의 r-부분의 기준 인스턴스에 대응하는지 검증하는 것, 및 ii) 제2 ECDSA 서명에 의해 서명된 제2 트랜잭션의 부분과 제2 ECDSA 서명을 생성하는 데 사용된 제2 개인 키에 대응하는 제2 공개 키가 주어지면 제2 ECDSA 서명의 s-부분이 제2 ECDSA 서명의 r-부분의 기준 인스턴스에 대응하는지 검증하는 것을 포함할 수 있다.

예를 들어, 상이한 조건은 계약의 상이한 대체 조건과 같은 상이한 대체 명령문에 매핑될 수 있다.

제15 선택적 예시에 따르면, 적어도 제1 ECDSA 서명의 s-부분은 제1 당사자에 의해 제2 당사자에게 주어진 또는 그 반대인 임시 키 및 제2 당사자의 개인 키인 제1 개인 키를 사용하여 제2 당사자에 의해 생성된 것인, 제1 내지 제14 예시 중 어느 하나에 따른 방법이 제공될 수 있다.

제16 선택적 예시에 따르면,

,

,

,

, 및

이며, P는 제1 공개 키이고, V는 제1 개인 키이고, k는 임시 키이고, G는 타원 생성기 점이고, n은 소수 계수(생성기 점의 소수 차수)이고, m은 제1 ECDSA 서명에 의해 서명된 제2 트랜잭션의 부분이고, H_sig은 제1 ECDSA 서명의 생성에서 m을 해시하기 위하여 사용된 해시 함수이고, [R]_x은 R의 x 좌표를 나타내고, "ㆍ" 는 타원 곡선 스칼라 곱셈을 나타내는, 제15 예시에 따른 방법이 제공될 수 있다.

제17 선택적 예시에 따르면, 제1 ECDSA 서명의 r-부분의 제출된 인스턴스 r은 또한 제2 당사자에 의해 생성된 것인, 적어도 제4 예시에 따른, 제15 또는 제16 예시에 따른 방법이 제공될 수 있다.

제18 선택적 예시에 따르면, 데이터 값의 제출된 인스턴스 d은 또한 제2 당사자에 의해 생성된 것인, 적어도 제10, 제11 또는 제12 예시에 따른, 제17 예시에 따른 방법이 제공될 수 있다.

제19 선택적 예시에 따르면, 제2 트랜잭션을 상기 수신하는 것은 제2 당사자로부터 제2 트랜잭션을 수신하는 것을 포함하는, 제15 내지 제18 예시 중 어느 하나에 따른 방법이 제공될 수 있다.

제20 선택적 예시에 따르면, 상기 코드에 의해 반환된 결과가 참인 조건에서 제1 당사자에 대한 서비스를 촉발(trigger)하는 것을 포함하는, 제15 내지 제19 예시 중 어느 하나에 따른 방법이 제공될 수 있다.

예를 들어, 서비스는 제1 당사자에 의해 위임되었을 수 있고, 제1 당사자를 대신하여 수행될 수 있고, 및/또는 제1 당사자를 위해 수행될 수 있다. 서비스는 컴퓨터화된 서비스일 수 있고 상기 촉발은 서비스를 자동으로 촉발하는 것을 포함할 수 있다.

임시 키를 제2 당사자("밥")에게 제공하면, 이는 제1 당사자("앨리스")가 밥이 그녀를 대신하여 서비스에 서명할 수 있도록 하지만, 밥이 노드에 임시 키 k를 공개하거나 이를 블록체인에 게시하지 않아도 된다. 또한 프로세스가 특정 개인 키(또는 그 대응하는 공개 키)에 연결되어 있지 않기 때문에, 이는 앨리스가 임시 키의 복사본을 또한 제3자("찰리")에게 제공할 수 있으며 그런 다음 밥과 찰리 중 하나가 서비스에 성공적으로 서명할 수 있다는 것을 의미한다. 이는 r-부분이 도전의 기초로 사용되며, r-부분이 임의의 특정 신원에 매핑되지 않기 때문에 가능하다.

제21 선택적 예시에 따르면, 제2 트랜잭션 내에서 수신된 정보는 제2 당사자의 추가 개인 키를 사용하여 제2 트랜잭션의 일 부분에 서명하는 제2 당사자의 추가 암호화 서명을 포함하고, 추가 개인 키는 추가 공개 키에 대응하는, 제15 내지 제20 예시 중 어느 하나에 따른 방법이 제공될 수 있다.

추가 서명은 ECC 서명 또는 다른 유형, 예를 들어 RSA 서명일 수 있다.

제22 선택적 예시에 따르면, 제1 당사자 및/또는 제3자가 추가 공개 키에 기초하여 제2 당사자의 신원을 조회할 수 있게 하는 매핑이 사용 가능한, 제21 예시에 따른 방법이 제공될 수 있다.

예를 들어 신원은 제2 당사자의 개인 이름, 회사 이름, 사용자 이름 또는 네트워크 주소일 수 있다. 제3자는 예를 들어 앞서 언급한 서비스의 제공자일 수 있다.

제23 선택적 예시에 따르면, 코드는 추가 공개 키를 사용하여 추가 암호화 서명을 검증하고 추가 암호화 서명이 검증되는 추가 조건에서 참의 결과를 반환하도록 구성되는, 제21 또는 제22 예시에 따른 방법이 제공될 수 있다.

제24 선택적 예시에 따르면, 제2 트랜잭션 내에서 수신된 정보는 제1 당사자의 개인 키를 사용하여 제2 트랜잭션의 일 부분에 서명하는 제1 당사자의 암호화 서명을 포함하는, 제15 내지 제23 예시 중 어느 하나에 따른 방법이 제공될 수 있다.

실시예에서 방법은 제1 당사자의 개인 키에 대응하는 공개 키를 획득하는 것을 포함할 수 있고, 여기에서 코드는 제2 당사자의 암호화 서명을 검증하고 제1 당사자의 암호화 서명이라는 추가 조건에서 참의 결과를 반환하도록 구성된다.

실시예에서, 제2 당사자 및/또는 제3자가 제1 당사자의 공개 키에 기초하여 제1 당사자의 신원을 조회할 수 있게 하는 매핑이 사용 가능할 수 있다. 예를 들어 제1 당사자의 신원은 제1 당사자의 개인 이름, 회사 이름, 사용자 이름 또는 네트워크 주소일 수 있다.

제25 선택적 예시에 따르면, 제2 트랜잭션 내에서 수신된 정보는 상이한 r-부분의 값을 갖지만 제1 ECDSA 서명과 동일한 제1 개인 키를 갖는 추가 ECDSA 서명을 포함하고; 코드는 제1 공개 키를 사용하여 추가 ECDSA 서명을 검증하고 추가 ECDSA 서명이 검증되는 추가 조건에서 참의 결과를 반환하도록 구성되는, 제15 내지 제24 예시 중 어느 하나에 따른 방법이 제공될 수 있다.

추가 ECDSA 서명은 제2 트랜잭션의 제1 ECDSA 서명과 상이한 부분에 서명할 수 있다.

제26 선택적 예시에 따르면, 제2 트랜잭션은 디지털 자산의 금액을 지정하고, 상기 금액은 적어도 코드가 상기 참의 결과를 반환하는 조건에서 잠금 해제되는, 제1 내지 제25 예시 중 어느 하나에 따른 방법이 제공될 수 있다.

제27 선택적 예시에 따르면, 트랜잭션의 각각은 하나 이상의 입력 및 하나 이상의 출력을 포함하는 데이터 구조를 포함하고, 각 출력은 잠금 스크립트를 포함하고, 각 입력은 잠금 해제 스크립트 및 다른 트랜잭션의 출력에 대한 포인터를 포함하며; 상기 코드는 제1 트랜잭션의 잠금 스크립트에 의해 구성되고, 제2 트랜잭션 내에서 수신된 상기 정보는 제2 트랜잭션의 입력 내의 잠금 해제 스크립트에 의해 구성되고, 제2 트랜잭션의 상기 입력 내의 포인터는 제1 트랜잭션의 상기 출력을 가리키는, 제1 내지 제26 예시 중 어느 하나에 따른 방법이 제공될 수 있다. 이 경우, 방법은 적어도 코드가 참의 상기 결과를 반환하는 조건에서 트랜잭션을 유효성 검증하는 것, 및 상기 유효성 검증에 응답하여: 제2 트랜잭션을 상기 검증 노드에 의하여 하나 이상의 블록을 채굴하기 위한 트랜잭션 풀 내에 포함시키는 것, 및/또는 제2 트랜잭션을 블록체인 네트워크의 적어도 하나의 다른 노드로 전달하는 것 중 적어도 하나를 포함한다.

제1 및 제2 트랜잭션을 포함하는 복수의 트랜잭션 각각에 대하여, 네트워크의 노드 중 적어도 일부는 트랜잭션이 유효한 조건에서 각 트랜잭션을 전파하도록 구성되고, 네트워크의 노드의 적어도 일부 노드는 트랜잭션이 유효한 조건에서 블록체인의 적어도 일부의 복사본에 각 트랜잭션을 기록하도록 구성된다. 제2 트랜잭션의 유효성은 적어도 참의 결과를 반환하는 코드에 대해 조건부이다.

제28 선택적 예시에 따르면, 제2 트랜잭션의 출력 중 하나는 갱신된 제1 ECDSA 서명의 r-부분의 기준 인스턴스를 지정하는 상기 코드의 갱신된 버전을 포함하는, 제27 예시에 따른 방법이 제공될 수 있다. 이 경우 방법은: 적어도 갱신된 제1 ECDSA 서명의 s-부분을 포함하는 정보를 포함하는 트랜잭션의 상기 집합 중 제3을 수신하는 것, 및 갱신된 제1 공개 키를 획득하는 것-갱신된 제1 ECDSA 서명은 갱신된 제1 공개 키에 대응하는 갱신된 제1 개인 키에 기초하여 제3 트랜잭션의 일 부분에 서명함; 및 제3 트랜잭션으로부터 코드의 갱신된 버전을 실행하는 것을 포함하며, 갱신된 코드는, 갱신된 제1 개인 키로 누구의 개인 키가 사용되었는지에 무관하게, 제2 트랜잭션의 서명된 부분 및 획득된 제1 공개 키가 주어지면, 갱신된 제1 ECDSA 서명에 적용된, 갱신된 제1 ECDSA가 갱신된 s-부분이 제2 트랜잭션 내에 지정된 r-부분의 기준 인스턴스에 대응하는 것을 검증하는 조건에서 참의 결과를 반환하도록 구성된다.

실시예에서, 제3 트랜잭션의 출력 중 하나는 추가로 갱신된 제1 ECDSA 서명 등의 r-부분의 기준 인스턴스를 지정하는 상기 코드의 추가로 갱신된 버전을 포함할 수 있으며, 따라서 정방향 체인 또는 r-퍼즐을 생성한다.

제29 선택적 예시에 따르면, 트랜잭션은 계정 기반 모델에 따라 구성되고, 상기 코드는 제1 트랜잭션에 포함된 스마트 계약으로 구성되는, 제1 내지 제26 예시 중 어느 하나에 따른 방법이 제공될 수 있다.

실시예에서, 어느 모델에서든, 검증 노드는 채굴 노드, 전달 노드 및/또는 블록체인의 적어도 일부를 저장하는 저장 노드(예를 들어 블록체인의 전체 사본을 저장하는 전체 사본 저장 노드)일 수 있다. 실시예에서, 제1 트랜잭션을 상기 획득하는 것은 제1 당사자, 예를 들어 앞서 언급한 제1 당사자로부터 제1 트랜잭션의 적어도 일부를 수신하는 것을 포함할 수 있다. 실시예에서, 제1 트랜잭션을 상기 획득하는 것은 제1 당사자로부터 제1 트랜잭션을 수신하는 것을 포함할 수 있다. 대안적으로, 실시예에서, 제1 트랜잭션을 상기 획득하는 것은 검증 노드에서 제1 트랜잭션을 공식화하는 것을 포함할 수 있다. 실시예에서, 제1 트랜잭션을 상기 획득하는 것은 노드 중 상기 하나에서 제1 당사자로부터 적어도 r-부분의 기준 인스턴스를 수신하고 제1 트랜잭션으로 공식화하는 것을 포함할 수 있다. 실시예에서, 제1 트랜잭션을 상기 획득하는 것은 검증 노드에서 r-부분을 생성하는 것을 포함하는 제1 트랜잭션을 공식화하는 것을 포함할 수 있다.

실시예에서, 제2 트랜잭션을 상기 수신하는 것은 제2 당사자, 예를 들어, 앞서 언급한 제2 당사자로부터 제2 트랜잭션을 수신하는 것을 포함할 수 있다. 실시예에서, 제2 트랜잭션은 제2 당사자에 의해 적어도 부분적으로 생성되었다. 실시예에서 제2 트랜잭션은 제2 당사자에 의해 생성되었다. 실시예에서, 제2 트랜잭션을 상기 수신하는 것은, 직접적으로 또는 제1 당사자 또는 제3자를 통해, 제2 당사자로부터 제2 트랜잭션을 수신하는 것을 포함할 수 있다. 실시예에서, 제2 트랜잭션은 제2 당사자가 제3자에게 제공한 제1 ECDSA 서명의 적어도 s-부분(및 실시예에서 제1 ECDSA 서명의 r-부분의 제출된 인스턴스 및/또는 데이터 값)에 기초하여 제3자에 의해 생성되었다.

본원의 교시의 제30 예시에 따르면, 컴퓨터 판독 가능 스토리지 상에 구현되고 네트워크의 노드 상에서 실행될 때 제1 내지 제29 예시 중 어느 하나의 방법을 수행하도록 구성되는 컴퓨터 프로그램이 제공된다.

제31 예시에 따르면, 하나 이상의 메모리 유닛을 포함하는 메모리, 및 하나 이상의 처리 유닛을 포함하는 처리 장치를 포함하고; 메모리는 처리 장치 상에서 실행되도록 배열된 코드를 저장하고, 코드는 처리 장치 상일 때 제1 내지 제29 예시 중 어느 하나의 방법을 수행하도록 구성되는 네트워크의 노드가 제공될 수 있다.

본원의 교시의 제32 예시에 따르면, 타원 곡선 디지털 서명 알고리즘(ECDSA) 검증 함수에 기초하여 지식 증명을 설정하는, 컴퓨터 구현 방법이 제공되며, 방법은, 제1 당사자의 컴퓨터 장비를 사용하여: 제2 당사자에게 임시 키를 전송하는 것, 또는 제2 당사자로부터 임시 키를 수신하는 것; 임시 키에 기초하여, 제1 ECDSA 서명의 r-부분의 기준 인스턴스를 결정하는 것; 실행 가능한 코드를 포함하는 제1 트랜잭션을 형성하는 것-코드는 제1 ECDSA 서명의 r-부분의 기준 인스턴스를 지정하는 요소를 포함함-을 포함하고; 코드는 적어도 제2 트랜잭션으로부터의 제1 ECDSA 서명의 s-부분에 대해, 및 제1 공개 키에 대해 작동하도록 구성되고, 제1 ECDSA 서명은 제1 공개 키에 대응하는 제1 개인 키에 기초하여 메시지에 서명하고, 메시지는 제2 트랜잭션의 일 부분이고; 코드는, 제1 개인 키로 누구의 개인 키가 사용되었는지에 무관하게: 제2 트랜잭션 내에서 수신된 메시지 및 제1 공개 키가 주어지면, 제1 ECDSA 서명에 적용된, ECDSA 검증 함수가 제2 트랜잭션 내에서 수신된 s-부분이 제1 트랜잭션에 의해 지정된 r-부분의 기준 인스턴스에 대응하는 것을 검증하는 조건에서 참의 결과를 반환하도록 구성된다.

실시예에서 방법은 본원에 개시된 임의의 예시 또는 다른 실시예에 따라 제1 당사자의 컴퓨터 장비에서 수행되는 단계를 더 포함할 수 있다.

본원의 교시의 제33 예시에 따르면, 블록체인에 기록하기 위한 트랜잭션 집합이 제공된다. 집합은, 컴퓨터 판독 가능 매체 상에 구현되며: 실행 가능한 코드를 포함하는 제1 트랜잭션-코드는 제1 ECDSA 서명의 r-부분의 기준 인스턴스를 지정하는 요소를 포함함; 및 적어도 제1 ECDSA 서명의 s-부분을 포함하는 정보를 포함하는 제2 트랜잭션을 포함하며, 제1 ECDSA 서명은 제1 공개 키에 대응하는 제1 개인 키에 기초하여 메시지에 서명하고, 메시지는 제2 트랜잭션의 일 부분이다. 코드는 블록체인 네트워크의 노드에서 실행될 때, 제1 개인 키로 누구의 개인 키가 사용되었는지에 무관하게: 제2 트랜잭션 내에서 수신된 메시지 및 획득된 제1 공개 키가 주어지면, 제1 ECDSA 서명에 적용된, ECDSA 검증 함수가 제2 트랜잭션 내에서 수신된 s-부분이 제1 트랜잭션에 의해 지정된 r-부분의 기준 인스턴스에 대응하는 것을 검증하는 조건에서 참의 결과를 반환하도록 구성된다.

실시예에서, 제1 및/또는 제2 트랜잭션은 본원에 개시된 임의의 예시 또는 다른 실시예에 따른 특징을 더 포함할 수 있다.

개시된 기술의 다른 변형 또는 사용 사례는 본원에서 개시가 주어지면 당업자에게 명백해질 수 있다. 개시의 범위는 설명된 실시예에 의해 제한되지 않고 첨부된 청구범위에 의해서만 제한된다.

Claims (33)

1. 타원 곡선 디지털 서명 알고리즘(ECDSA) 검증 함수에 기초하여 지식 증명을 수행하는, 컴퓨터 구현 방법에 있어서, 상기 방법은, 블록체인 네트워크의 검증 노드에서:
   실행 가능한 코드를 포함하는 제1 트랜잭션을 획득하는 것-상기 코드는 제1 ECDSA 서명의 r-부분에 대한 기준 인스턴스를 지정하는 요소를 포함함-;
   적어도 상기 제1 ECDSA 서명의 s-부분을 포함하는 정보를 포함하는 제2 트랜잭션을 수신하는 것, 및 제1 공개 키를 획득하는 것-상기 제1 ECDSA 서명은 상기 제1 공개 키에 대응하는 제1 개인 키에 기초하여 메시지에 서명하고, 상기 메시지는 상기 제2 트랜잭션의 일 부분임-; 및
   상기 제1 트랜잭션으로부터 상기 코드를 실행하는 것을 포함하며, 상기 코드는 상기 제1 개인 키로 누구의 개인 키가 사용되었는지에 무관하게:
   - 상기 제2 트랜잭션 내에서 수신된 상기 메시지 및 상기 획득된 제1 공개 키가 주어지면, 상기 제1 ECDSA 서명에 적용된, 상기 ECDSA 검증 함수가 상기 제2 트랜잭션 내에서 수신된 상기 s-부분이 상기 제1 트랜잭션에 의해 지정된 상기 r-부분의 상기 기준 인스턴스에 대응하는 것을 검증하는 조건에서 참의 결과를 반환하도록 구성되는 방법.
2. 제1항에 있어서, 상기 요소는 상기 제1 ECDSA 서명의 상기 r-부분의 상기 기준 인스턴스인 방법.
3. 제2항에 있어서, 상기 ECDSA 검증 함수는:
   

   

   계산, 및
   

   

   확인을 수행하고,
   r'는 상기 제1 ECDSA 서명의 상기 r-부분의 상기 기준 인스턴스이고, s는 상기 제1 ECDSA 서명의 상기 s-부분이고, P는 상기 제1 공개 키이고, m은 상기 제1 ECDSA 서명에 의해 서명된 상기 제2 트랜잭션의 상기 부분이고, H_sig은 상기 제1 ECDSA 서명의 생성에서 m을 해시하기 위하여 사용된 해시 함수이고, G는 타원 생성기 점이고, [R']_x은 R'의 x 좌표를 나타내고, "ㆍ" 는 타원 곡선 스칼라 곱셈을 나타내며;
   상기 코드는 상기 확인이 참인 조건에서 참의 결과를 반환하고, 그렇지 않으면 거짓의 결과를 반환하도록 구성되는 방법.
4. 제1항 또는 제2항에 있어서, 상기 제2 트랜잭션 내에서 수신된 상기 정보는 상기 제1 ECDSA 서명의 상기 r-부분의 제출된 인스턴스를 더 포함하고, 상기 코드는 상기 r-부분의 상기 제출된 인스턴스가 상기 기준 인스턴스와 동일한지 확인하도록 구성되는 방법.
5. 제4항에 있어서, 상기 ECDSA 검증 함수는 상기 제2 트랜잭션 내에서 수신된 상기 s-부분이 상기 r-부분의 상기 제출된 인스턴스에 대응하는지 확인하고, 상기 검증은 두 가지 확인을 함께 사용하여 그것이 상기 기준 인스턴스에 대응한다는 것인 방법.
6. 제2항 또는 제5항에 있어서, 상기 코드는:
   r' = r의 확인을 수행하도록 구성되고,
   상기 ECDSA 검증 함수는:
   

   

   계산, 및
   

   

   확인을 수행하고,
   r은 상기 제1 ECDSA 서명의 상기 r-부분의 상기 제출된 인스턴스이고, r'는 상기 제1 ECDSA 서명의 상기 r-부분의 상기 기준 인스턴스이고, s는 상기 제1 ECDSA 서명의 상기 s-부분이고, P는 상기 제1 공개 키이고, m은 상기 제1 ECC 서명에 의해 서명된 상기 제2 트랜잭션의 상기 부분이고, H_sig은 상기 제1 ECDSA 서명의 생성에서 m을 해시하기 위하여 사용된 해시 함수이고, G는 타원 생성기 점이고, [R']_x은 R'의 x 좌표를 나타내고, "ㆍ" 는 타원 곡선 스칼라 곱셈을 나타내며;
   상기 코드는 두 개 모두의 상기 확인이 참인 조건에서 참의 결과를 반환하고, 그렇지 않으면 거짓의 결과를 반환하도록 구성되는 방법.
7. 제4항 또는 제5항에 있어서, 상기 요소는 상기 제1 ECDSA 서명의 상기 r-부분의 기준 인스턴스의 변환이고, 상기 코드는 상기 제출된 인스턴스에 대해 동일한 변환을 수행함에 의하여 상기 제출된 인스턴스가 상기 기준 인스턴스와 동일한지 상기 확인을 수행하도록 구성되는 방법.
8. 제7항에 있어서, 상기 요소는, 상기 제1 ECDSA 서명의 상기 r-부분의 상기 기준 인스턴스를 포함하는 구성요소의 해시인, 해시 값인 방법.
9. 제5항 또는 제8항에 있어서, 상기 구성요소는 상기 제1 ECDSA 서명의 상기 r-부분의 상기 기준 인스턴스 r'이고, 상기 코드는:
   

   

   의 확인을 수행하도록 구성되고,
   상기 ECDSA 검증 함수는:
   

   

   계산, 및
   

   

   확인을 수행하고,
   r은 상기 제1 ECDSA 서명의 상기 r-부분의 상기 제출된 인스턴스이고, s는 상기 제1 ECDSA 서명의 상기 s-부분이고, h는 상기 해시 값이고, H_puz 는 h를 생성하기 위하여 r'를 해시하는 데 사용된 해시 함수이고, P는 상기 제1 공개 키이고, m은 상기 제1 ECC 서명에 의해 서명된 상기 제2 트랜잭션의 상기 부분이고, H_sig은 상기 제1 ECDSA 서명의 생성에서 m을 해시하기 위하여 사용된 해시 함수이고, G는 타원 생성기 점이고, [R']_x은 R'의 x 좌표를 나타내고, "ㆍ" 는 타원 곡선 스칼라 곱셈을 나타내며;
   상기 코드는 두 개 모두의 상기 확인이 참인 조건에서 참의 결과를 반환하고, 그렇지 않으면 거짓의 결과를 반환하도록 구성되는 방법.
10. 제5항 또는 제8항에 있어서, 상기 구성요소는 상기 제1 ECDSA 서명의 상기 r-부분의 상기 기준 인스턴스 r'와 데이터 값의 기준 인스턴스 d'의 조합

    

    이고, 상기 제2 트랜잭션 내에서 수신된 상기 정보는 상기 제1 ECDSA 서명의 상기 r-부분의 제출된 인스턴스 r와 상기 데이터 값의 제출된 인스턴스 d를 더 포함하고, 상기 코드는:
    

    

    =

    

    의 확인을 수행하도록 구성되고,
    상기 ECDSA 검증 함수는:
    

    

    계산, 및
    

    

    확인을 수행하고,
    s는 상기 제1 ECDSA 서명의 상기 s-부분이고, h_joint는 상기 해시 값이고, H_puz 는 h_joint를 생성하기 위하여

    

    를 해시하는 데 사용된 해시 함수이고, P는 상기 제1 공개 키이고, m은 상기 제1 ECC 서명에 의해 서명된 상기 제2 트랜잭션의 상기 부분이고, H_sig은 상기 제1 ECDSA 서명의 생성에서 m을 해시하기 위하여 사용된 해시 함수이고, G는 타원 생성기 점이고, [R']_x은 R'의 x 좌표를 나타내고, "ㆍ" 는 타원 곡선 스칼라 곱셈을 나타내며;
    상기 코드는 두 개 모두의 상기 확인이 참인 조건에서 참의 결과를 반환하고, 그렇지 않으면 거짓의 결과를 반환하도록 구성되는 방법.
11. 제10항에 있어서, 상기 조합 f는 연결이고,

    

    는

    

    이며,

    

    

    는

    

    인 방법.
12. 제10항 또는 제11항에 있어서, 상기 데이터 값은 목표 시점을 지정하는 잠금 시간 값을 포함하고, 상기 코드는 상기 목표 시점에 도달하는 추가 조건에서 참의 결과를 반환하도록 구성되는 방법.
13. 전술한 청구항 중 어느 한 항에 있어서, 상기 제1 공개 키를 상기 획득하는 것은 상기 제2 트랜잭션 내의 상기 정보의 부분으로서 상기 제1 공개 키를 수신하는 것을 포함하는 방법.
14. 전술한 청구항 중 어느 한 항에 있어서:
    상기 코드는 제2 ECDSA 서명의 r-부분의 기준 인스턴스를 더 지정하고;
    상기 코드는 복수의 대체 조건 중 어느 하나가 충족되면 참의 결과를 반환하도록 구성되며, 상기 대체 조건은:
    i) 상기 제1 공개 키 및 상기 제1 ECDSA 서명에 의해 서명된 상기 제2 트랜잭션의 상기 부분이 주어지면 상기 제1 ECDSA 서명의 상기 s-부분이 상기 제1 ECDSA 서명의 상기 r-부분의 상기 기준 인스턴스에 대응하는지 검증하는 것, 및
    ii) 상기 제2 ECDSA 서명에 의해 서명된 상기 제2 트랜잭션의 상기 부분과 상기 제2 ECDSA 서명을 생성하는 데 사용된 제2 개인 키에 대응하는 제2 공개 키가 주어지면 상기 제2 ECDSA 서명의 상기 s-부분이 상기 제2 ECDSA 서명의 상기 r-부분의 상기 기준 인스턴스에 대응하는지 검증하는 것을 포함하는 방법.
15. 전술한 청구항 중 어느 한 항에 있어서, 적어도 상기 제1 ECDSA 서명의 상기 s-부분은 제1 당사자에 의해 제2 당사자에게 주어거나 또는 그 반대인 임시 키 및 상기 제2 당사자의 개인 키인 상기 제1 개인 키를 사용하여 상기 제2 당사자에 의해 생성된 것인 방법.
16. 제15항에 있어서:
    

    

    ,
    

    

    ,
    

    

    ,
    

    

    , 및
    

    

    이며,
    P는 상기 제1 공개 키이고, V는 상기 제1 개인 키이고, k는 상기 임시 키이고, n은 소수 계수이고, G는 타원 생성기 점이고, m은 상기 제1 ECDSA 서명에 의해 서명된 상기 제2 트랜잭션의 상기 부분이고, H_sig은 상기 제1 ECDSA 서명의 생성에서 m을 해시하기 위하여 사용된 해시 함수이고, [R]_x은 R의 x 좌표를 나타내고, "ㆍ" 는 타원 곡선 스칼라 곱셈을 나타내는 방법.
17. 적어도 제4항에 따른, 제15항 또는 제16항에 있어서, 상기 제1 ECDSA 서명의 상기 r-부분의 상기 제출된 인스턴스 r은 또한 상기 제2 당사자에 의해 생성된 것인 방법.
18. 적어도 제10항, 제11항 또는 제12항에 따른, 제17항에 있어서, 상기 데이터 값의 상기 제출된 인스턴스 d은 또한 상기 제2 당사자에 의해 생성된 것인 방법.
19. 제15항 내지 제18항 중 어느 한 항에 있어서, 상기 제2 트랜잭션을 상기 수신하는 것은 상기 제2 당사자로부터 상기 제2 트랜잭션을 수신하는 것을 포함하는 방법.
20. 제15항 내지 제19항 중 어느 한 항에 있어서, 상기 코드에 의해 반환된 상기 결과가 참인 조건에서 상기 제1 당사자에 대한 서비스를 촉발(trigger)하는 것을 포함하는 방법.
21. 제15항 내지 제20항 중 어느 한 항에 있어서, 상기 제2 트랜잭션 내에서 수신된 상기 정보는 상기 제2 당사자의 추가 개인 키를 사용하여 상기 제2 트랜잭션의 일 부분에 서명하는 상기 제2 당사자의 추가 암호화 서명을 포함하고, 상기 추가 개인 키는 추가 공개 키에 대응하는 방법.
22. 제21항에 있어서, 상기 제1 당사자 및/또는 제3자가 상기 추가 공개 키에 기초하여 상기 제2 당사자의 신원을 조회할 수 있게 하는 매핑이 사용 가능한 방법.
23. 제21항 또는 제22항에 있어서, 상기 코드는 상기 추가 공개 키를 사용하여 상기 추가 암호화 서명을 검증하고 상기 추가 암호화 서명이 검증되는 추가 조건에서 참의 결과를 반환하도록 구성되는 방법.
24. 제15항 내지 제23항 중 어느 한 항에 있어서, 상기 제2 트랜잭션 내에서 수신된 상기 정보는 상기 제1 당사자의 개인 키를 사용하여 상기 제2 트랜잭션의 일 부분에 서명하는 상기 제1 당사자의 암호화 서명을 포함하는 방법.
25. 제15항 내지 제24항 중 어느 한 항에 있어서:
    상기 제2 트랜잭션 내에서 수신된 상기 정보는 상이한 상기 r-부분의 값을 갖지만 상기 제1 ECDSA 서명과 동일한 상기 제1 개인 키를 사용하는 추가 ECDSA 서명을 포함하고;
    상기 코드는 상기 제1 공개 키를 사용하여 상기 추가 ECDSA 서명을 검증하고, 상기 추가 ECDSA 서명이 검증되는 추가 조건에서 참의 결과를 반환하도록 구성되는 방법.
26. 전술한 청구항 중 어느 한 항에 있어서, 상기 제2 트랜잭션은 디지털 자산의 금액을 지정하고, 상기 금액은 적어도 상기 코드가 상기 참의 결과를 반환하는 조건에서 잠금 해제되는 방법.
27. 전술한 청구항 중 어느 한 항에 있어서, 상기 트랜잭션의 각각은 하나 이상의 입력 및 하나 이상의 출력을 포함하는 데이터 구조를 포함하고, 각 출력은 잠금 스크립트를 포함하고, 각 입력은 잠금 해제 스크립트 및 다른 트랜잭션의 출력에 대한 포인터를 포함하며;
    상기 코드는 상기 제1 트랜잭션의 상기 잠금 스크립트에 의해 구성되고, 상기 제2 트랜잭션 내에서 수신된 상기 정보는 상기 제2 트랜잭션의 입력 내의 상기 잠금 해제 스크립트에 의해 구성되고, 상기 제2 트랜잭션의 상기 입력 내의 상기 포인터는 상기 제1 트랜잭션의 상기 출력을 가리키며;
    상기 방법은 적어도 상기 코드가 상기 참의 결과를 반환하는 조건에서 상기 트랜잭션을 유효성 검증하는 것, 및 상기 유효성 검증에 응답하여:
    - 상기 제2 트랜잭션을 상기 검증 노드에 의하여 하나 이상의 블록으로 채굴하기 위한 트랜잭션 풀 내에 포함시키는 것, 및/또는
    - 상기 제2 트랜잭션을 상기 블록체인 네트워크의 적어도 하나의 다른 노드로 전달하는 것 중 적어도 하나를 포함하는 방법.
28. 제27항에 있어서, 상기 제2 트랜잭션의 상기 출력 중 하나는 갱신된 제1 ECDSA 서명의 상기 r-부분의 기준 인스턴스를 지정하는 상기 코드의 갱신된 버전을 포함하고, 상기 방법은:
    적어도 상기 갱신된 제1 ECDSA 서명의 s-부분을 포함하는 정보를 포함하는 트랜잭션의 상기 집합 중 제3을 수신하는 것, 및 갱신된 제1 공개 키를 획득하는 것-상기 갱신된 제1 ECDSA 서명은 상기 갱신된 제1 공개 키에 대응하는 갱신된 제1 개인 키에 기초하여 상기 제3 트랜잭션의 일 부분에 서명함-; 및
    상기 제3 트랜잭션으로부터 상기 코드의 상기 갱신된 버전을 실행하는 것을 포함하며, 상기 갱신된 코드는, 상기 갱신된 제1 개인 키로 누구의 개인 키가 사용되었는지에 무관하게, 상기 제2 트랜잭션의 상기 서명된 부분 및 상기 획득된 제1 공개 키가 주어지면, 상기 갱신된 제1 ECDSA 서명에 적용된, 상기 갱신된 제1 ECDSA가 상기 갱신된 s-부분이 상기 제2 트랜잭션 내에 지정된 상기 r-부분의 상기 기준 인스턴스에 대응하는 것을 검증하는 조건에서 참의 결과를 반환하도록 구성되는 방법.
29. 제1항 내지 제26항 중 어느 한 항에 있어서, 상기 트랜잭션은 계정 기반 모델에 따라 구성되고, 상기 코드는 상기 제1 트랜잭션에 포함된 스마트 계약으로 구성되는 방법.
30. 컴퓨터 판독 가능 스토리지 상에 구현되고 네트워크의 노드 상에서 실행될 때 전술한 청구항 중 어느 한 항의 방법을 수행하도록 구성되는 컴퓨터 프로그램.
31. 하나 이상의 메모리 유닛을 포함하는 메모리, 및
    하나 이상의 처리 유닛을 포함하는 처리 장치를 포함하고;
    상기 메모리는 상기 처리 장치 상에서 실행되도록 배열된 코드를 저장하고, 상기 코드는 상기 처리 장치 상일 때 제1항 내지 제29항 중 어느 한 항의 방법을 수행하도록 구성되는 네트워크의 노드.
32. 타원 곡선 디지털 서명 알고리즘(ECDSA) 검증 함수에 기초하여 지식 증명을 설정하는, 컴퓨터 구현 방법에 있어서, 상기 방법은, 제1 당사자의 컴퓨터 장비를 사용하여:
    제2 당사자에게 임시 키를 전송하는 것, 또는 상기 제2 당사자로부터 상기 임시 키를 수신하는 것;
    상기 임시 키에 기초하여, 제1 ECDSA 서명의 r-부분의 기준 인스턴스를 결정하는 것;
    실행 가능한 코드를 포함하는 제1 트랜잭션을 형성하는 것-상기 코드는 상기 제1 ECDSA 서명의 상기 r-부분의 상기 기준 인스턴스를 지정하는 요소를 포함함-을 포함하고;
    상기 코드는: 적어도 제2 트랜잭션으로부터의 상기 제1 ECDSA 서명의 s-부분, 및 제1 공개 키에 대해 작동하도록 구성되고, 상기 제1 ECDSA 서명은 상기 제1 공개 키에 대응하는 제1 개인 키에 기초하여 메시지에 서명하고, 상기 메시지는 상기 제2 트랜잭션의 일 부분이고;
    상기 코드는, 상기 제1 개인 키로 누구의 개인 키가 사용되었는지에 무관하게:
    - 상기 제2 트랜잭션 내에서 수신된 상기 메시지 및 상기 제1 공개 키가 주어지면, 상기 제1 ECDSA 서명에 적용된, 상기 ECDSA 검증 함수가 상기 제2 트랜잭션 내에서 수신된 상기 s-부분이 상기 제1 트랜잭션에 의해 지정된 상기 r-부분의 상기 기준 인스턴스에 대응하는 것을 검증하는 조건에서 참의 결과를 반환하도록 구성되는 방법.
33. 블록체인에 기록하기 위한 트랜잭션 집합에 있어서, 컴퓨터 판독 가능 데이터 매체 상에 구현되는, 상기 집합은:
    실행 가능한 코드를 포함하는 제1 트랜잭션-상기 코드는 제1 ECDSA 서명의 r-부분의 기준 인스턴스를 지정하는 요소를 포함함-; 및
    적어도 상기 제1 ECDSA 서명의 s-부분을 포함하는 정보를 포함하는 제2 트랜잭션을 포함하며, 상기 제1 ECDSA 서명은 제1 공개 키에 대응하는 제1 개인 키에 기초하여 메시지에 서명하고, 상기 메시지는 상기 제2 트랜잭션의 일 부분이며;
    상기 코드는 블록체인 네트워크의 노드에서 실행될 때, 상기 제1 개인 키로 누구의 개인 키가 사용되었는지에 무관하게:
    상기 제2 트랜잭션 내에서 수신된 상기 메시지 및 상기 획득된 제1 공개 키가 주어지면, 상기 제1 ECDSA 서명에 적용된, 상기 ECDSA 검증 함수가 상기 제2 트랜잭션 내에서 수신된 상기 s-부분이 상기 제1 트랜잭션에 의해 지정된 상기 r-부분의 상기 기준 인스턴스에 대응하는 것을 검증하는 조건에서 참의 결과를 반환하도록 구성되는 집합.

Images