KR20240041944A - 컴퓨터 구현 방법 및 시스템 - Google Patents

Abstract

위임된 인가를 설정하기 위한 컴퓨터 구현 시스템들 및 방법들이 자세히 설명된다. 위임된 인가 토큰들의 검증 및 생성의 방법들은 위임된 인가 토큰들의 체인의 최초 위임된 인가 토큰을 획득하는 것을 포함한다. 위임된 인가 토큰들의 체인의 추가 위임된 인가 토큰들은 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰에 기초하여 생성된다. 위임된 인가 토큰의 유효성을 검증하는 경우, 최초 위임된 인가 토큰의 유효성은 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들 중 하나와 미리 결정된 값의 비교에 기초한다.

Description

컴퓨터 구현 방법 및 시스템

본 개시내용은 하나 이상의 클라이언트들에 대한 분산 원장, 즉 블록체인과 연관된 하나 이상의 서비스들의 플랫폼을 구현하기 위한 방법들 및 시스템들에 관한 것이다. 보다 구체적으로, 본 개시내용은 블록체인과 연관된 서비스들에 대한 위임된 액세스의 제공을 제공한다(그러나 이에 제한되지 않음).

블록체인은 블록체인의 복제본이 분산 P2P(Peer-to-Peer) 네트워크(이하 "블록체인 네트워크"로서 지칭됨) 내 복수의 노드들 각각에서 유지되며 널리 공개되는 분산 데이터 구조의 형태를 지칭한다. 블록체인은 데이터의 블록들의 체인을 포함하며, 각각의 블록은 하나 이상의 트랜잭션들을 포함한다. 소위 "코인베이스 트랜잭션(coinbase transaction)들"이 아닌 각각의 트랜잭션은 시퀀스 내 이전 트랜잭션을 다시 가리키며, 이는 하나 이상의 코인베이스 트랜잭션들까지 하나 이상의 블록들에 걸쳐 있을 수 있다. 코인베이스 트랜잭션은 아래에서 논의된다. 블록체인 네트워크에 제출된 트랜잭션들은 새로운 블록들에 포함된다. 새로운 블록들은 복수의 노드들 각각이 "작업 증명"을 수행하기 위해 경쟁하는 것 즉, 블록체인의 새로운 블록에 포함되기를 기다리는, 순서화되고 유효성 검증된 보류중인 트랜잭션들의 정의된 세트의 표현에 기초하여 암호화 퍼즐을 해결하는 것을 수반하는 "채굴"로서 지칭되는 프로세스에 의해 생성된다. 블록체인은 노드에서 프루닝(prune)될 수 있으며 블록들의 공개는 단순 블록 헤더들의 공개를 통해 달성될 수 있다는 것이 주의되어야 한다.

블록체인의 트랜잭션들은 다음 목적들: 디지털 자산(예컨대, 다수의 디지털 토큰들)을 전달하는 것, 가상화된 원장 또는 레지스트리 내 저널 엔트리들의 세트를 순서화하는 것, 타임스탬프 엔트리들을 수신 및 프로세싱하는 것, 그리고/또는 인덱스 포인터들을 시간-순서화하는 것 중 하나 이상을 수행하는 데 사용된다. 블록체인 위에 부가적인 기능성을 쌓기 위해 블록체인이 또한 활용될 수 있다. 블록체인 프로토콜들은 트랜잭션의 데이터에의 부가적인 사용자 데이터 또는 인덱스들의 저장을 허용할 수 있다. 단일 트랜잭션 내에 저장될 수 있는 최대 데이터 용량에 대해 미리 지정된 제한이 없고 이에 따라 점점 더 복잡한 데이터가 통합될 수 있다. 예컨대, 이는 블록체인에 전자 문서를 저장하거나, 오디오 또는 비디오 데이터를 저장하는 데 사용될 수 있다.

블록체인 네트워크의 노드들(종종 "채굴자들"로서 지칭됨)은 분산 트랜잭션 등록 및 검증 프로세스를 수행하며, 이는 아래에서 상세히 설명될 것이다. 요약하면, 이 프로세스 동안, 노드는 트랜잭션들을 유효성 검증하여 유효한 작업 증명 솔루션을 식별하려고 시도하는 블록 템플릿에 삽입한다. 유효한 솔루션이 발견되면, 새로운 블록이 네트워크의 다른 노드들로 전파되고, 이에 따라 각각의 노드가 블록체인 상에 새로운 블록을 레코딩하는 것을 가능하게 한다. 트랜잭션을 블록체인에 레코딩하기 위해, 사용자(예컨대, 블록체인 클라이언트 애플리케이션)는 트랜잭션을 전파될 네트워크의 노드들 중 하나로 전송한다. 트랜잭션을 수신하는 노드들은 유효성 검증된 트랜잭션을 새로운 블록에 통합하는 작업 증명 솔루션을 찾기 위해 경합할 수 있다. 각각의 노드는 트랜잭션이 유효하기 위한 하나 이상의 조건들을 포함하는 동일한 노드 프로토콜을 시행하도록 구성된다. 유효하지 않은 트랜잭션들은 블록들 내로 통합되거나 전파되지 않을 것이다. 트랜잭션이 유효성 검증되고 그리하여 블록체인 상에 수락된다고 가정하면, 트랜잭션(임의의 사용자 데이터 포함함)은 이에 따라 불변의 공개 레코드로서 블록체인 네트워크 내 노드들 각각에 등록되고 인덱싱된 상태로 유지된다.

최신 블록을 생성하기 위해 작업 증명 퍼즐을 성공적으로 해결한 노드는 통상적으로 디지털 자산의 금액, 즉 다수의 토큰들을 분배하는 "코인베이스 트랜잭션"이라 불리는 새로운 트랜잭션으로 보상을 받는다. 유효하지 않은 트랜잭션들의 검출 및 거절은 네트워크의 에이전트들로서 작용하는 경쟁 노드들의 액션에 의해 시행되며 불법 행위를 보고하고 차단하도록 장려된다. 광범위한 정보 공개는 사용자들이 노드들의 성능을 지속적으로 감사하도록 허용한다. 단순 블록 헤더들의 공개는 참가자들이 블록체인의 지속적인 무결성을 보장하도록 허용한다.

"출력 기반" 모델(때로는 UTXO 기반 모델로서 지칭됨)에서, 주어진 트랜잭션의 데이터 구조는 하나 이상의 입력들 및 하나 이상의 출력들을 포함한다. 임의의 지출 가능한 출력은 진행중인 트랜잭션 시퀀스로부터 도출 가능한 디지털 자산의 금액을 지정하는 요소를 포함한다. 지출 가능한 출력은 때로는 UTXO("미지출 트랜잭션 출력")로서 지칭된다. 출력은 출력의 향후 리딤션(redemption)을 위한 조건을 지정하는 잠금 스크립트를 더 포함할 수 있다. 잠금 스크립트는 디지털 토큰들 또는 자산들을 유효성 검증하고 이전하는 데 필요한 조건들을 정의하는 술어이다. (코인베이스 트랜잭션 이외의) 트랜잭션의 각각의 입력은 선행 트랜잭션의 이러한 출력에 대한 포인터(즉, 참조)를 포함하고, 가리켜진 출력의 잠금 스크립트를 잠금해제하기 위한 잠금해제 스크립트를 더 포함할 수 있다. 따라서 트랜잭션들의 쌍을 고려하고, 이들을 제1 및 제2 트랜잭션(또는 "타겟" 트랜잭션)이라고 한다. 제1 트랜잭션은 출력을 잠금해제하는 하나 이상의 조건들을 정의하는 잠금 스크립트를 포함하고 디지털 자산의 금액을 지정하는 적어도 하나의 출력을 포함한다. 제2의 타겟 트랜잭션은 제1 트랜잭션의 출력에 대한 포인터를 포함하는 적어도 하나의 입력, 및 제1 트랜잭션의 출력을 잠금해제하기 위한 잠금해제 스크립트를 포함한다.

이러한 모델에서, 제2의 타겟 트랜잭션이 블록체인 네트워크에 전송되어 블록체인에서 전파 및 레코딩될 때, 각각의 노드에 적용되는 유효성에 대한 기준들 중 하나는, 잠금해제 스크립트가 제1 트랜잭션의 잠금 스크립트에 정의된 하나 이상의 조건들 전부 충족하는 것일 것이다. 다른 하나는 제1 트랜잭션의 출력이 다른 더 앞선 유효한 트랜잭션에 의해 이미 리딤되지 않았다는 것일 것이다. 이러한 조건들 중 임의의 것에 따라 유효하지 않은 타겟 트랜잭션을 발견한 임의의 노드는 이를 전파하지 않거나(유효한 트랜잭션으로서 전파하지 않으나, 어쩌면, 유효하지 않은 트랜잭션을 등록하기 위해 전파함) 블록체인에 레코딩될 새로운 블록에 이를 포함시키지 않을 것이다.

대안적인 유형의 트랜잭션 모델은 계정 기반 모델이다. 이 경우에 각각의 트랜잭션은 과거 트랜잭션들의 시퀀스에서 선행 트랜잭션의 UTXO를 뒤로 참조하기 보다는, 절대 계정 잔액을 참조함으로써 전달될 금액을 정의한다. 모든 계정들의 현재 상태는 블록체인과 별개로 노드들에 의해 저장되며 지속적으로 업데이트된다.

현재 연구의 한 영역은 "스마트 계약들"의 구현을 위한 블록체인의 사용이다. 이들은 기계-판독 가능 계약 또는 동의(agreement)의 조건들의 실행을 자동화하도록 설계된 컴퓨터 프로그램들이다. 자연어로 기록되는 기존의 계약과 달리, 스마트 계약은 결과들을 생성하기 위해 입력들을 프로세싱할 수 있는 규칙들을 포함하는 기계 실행 가능 프로그램이며, 이는 그 후 그러한 결과들에 의존하여 액션들이 수행되게 할 수 있다. 블록체인-관련 다른 관심 영역은 '토큰들'(또는 '컬러드 코인(coloured coin)들')을 사용하여 블록체인을 통해 실세계 엔티티들을 표현 및 이전하는 것이다. 잠재적으로 민감성 또는 비밀 아이템은 어떠한 구별 가능한 의미 또는 가치도 갖지 않는 토큰으로 표현될 수 있다. 따라서 토큰은 실세계 아이템이 블록체인으로부터 참조될 수 있게 하는 식별자로서 역할을 한다.

위에서 언급된 예들 또는 시나리오들은 블록체인의 이점들을 이용하여 영구적이고 변조 방지된 이벤트들의 레코드를 제공하면서; 예컨대, BSV(Bitcoin Satoshi's Vision) 블록체인에서 사용되는 ECDSA(Elliptic Curve Digital Signature Algorithm)에 대한 암호화 키들을 관리하는 소프트웨어 및/또는 하드웨어, 또는 프로세서/모듈 이를테면, 디지털 자산들을 관리하기 위한 기능성을 구현하기 위한 디지털 지갑을 포함하거나 구현하도록 클라이언트, 클라이언트 엔티티, 컴퓨팅 디바이스들 또는 클라이언트와 연관된 단말에 요구한다. 게다가, 클라이언트 디바이스가 블록체인 트랜잭션 구조를 구현하고 BSV 라이브러리들에 대한 액세스를 가질 수 있도록 하는 요건이 또한 있다. 따라서 클라이언트들은 이러한 기능성을 구현하기 위한 프로세싱을 포함할 필요가 있을 뿐만 아니라, 그들은 데이터 및/또는 디지털 자산들 ― 이들은 실세계 자산 트랜잭션을 표현하는 스마트 계약 또는 토큰과 관련이 있음 ― 을 전송, 수신 및 보기 위해 블록체인 네트워크를 사용할 수 있기 전에, 이러한 프로세스들에 대해 적절한 보안 조치들이 구현되는 것을 보장할 필요가 있다.

제1 양상에 따르면, 컴퓨터-구현 방법이 제공되며, 이 방법은, 미리 결정된 값을 획득하는 단계, 위임된 인가 토큰들의 체인 중 최초 위임된 인가 토큰을 포함하는 요청을 수신하는 단계, 위임된 인가 토큰들의 체인의 추가 위임된 인가 토큰들을 생성하는 단계 ― 위임된 인가 토큰들의 체인 내 각각의 추가 위임된 인가 토큰의 생성은 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰에 기초함 ― ; 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들 중 하나와 미리 결정된 값의 비교에 기초하여 최초 위임된 인가 토큰의 유효성을 결정하는 단계를 포함한다.

제2 양상에 따르면, 연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법이 제공되며, 이 방법은, 제1 값 및 제2 값을 획득하는 단계 위임된 인가 토큰들의 체인의 최초 위임된 인가 토큰을 생성하는 단계 ― 최초 위임된 인가 토큰은 제1 값 및 제2 값에 기초함 ― , 및 위임된 인가 토큰들의 체인의 적어도 하나의 추가 위임된 인가 토큰을 생성하는 단계를 포함하고, 위임된 인가 토큰들의 체인 내 각각의 추가 위임된 인가 토큰의 생성은 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰 및 제1 값에 기초한다.

제3 양상에 따르면, 제1 양상에 따라 토큰들을 유효성 검증하는 방법이 제공되며, 여기서 최초 위임된 인가 토큰은 제2 양상에 따라 클라이언트에 의해 생성되었다.

제4 양상에 따르면, 제2 양상의 방법에 따라 생성된 위임된 인가 토큰을 수신하는 단계, 위임된 인가 토큰을 포함하는 요청을 생성하는 단계, 및 요청을 서버에 전송하는 단계를 포함하는 방법이 제공된다.

제5 양상에 따르면, 서버, 위임자, 클라이언트를 포함하는 시스템이 제공되며, 클라이언트는, 제2 양상에 따라, 위임된 인가 토큰들의 체인 및 제1 값을 생성하고, 제1 값 및 위임된 인가 토큰들의 체인들의 최종 위임된 인가 토큰을 서버에 송신하고, 그리고 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들 중 하나를 위임자에게 송신하도록 구성된다.

개시된 방법의 일부 특정 구성요소들 및 실시예들은 이제, 유사한 참조 번호들이 유사한 특징들을 지칭하는 첨부 도면들을 참조하여 예시의 방식으로 설명된다.

도 1은 블록체인을 구현하기 위한 예시적인 시스템을 도시한다.
도 2는 예시적인 트랜잭션 프로토콜을 예시한다.
도 3a 및 도 3b는 클라이언트 애플리케이션 및 그의 사용자 인터페이스의 예시적인 구현을 예시한다.
도 4는 네트워크의 각각의 블록체인 노드 상에서 실행되는 노드 소프트웨어의 예를 예시한다.
도 5는 플랫폼 프로세서, 데이터베이스, 블록체인 네트워크, 클라이언트 및 위임들자 간의 상호작용을 예시하는 개략도이다.
도 6은 위임된 인가 토큰들을 생성하기 위한 방법을 예시한다.
도 7은 위임자들이 서비스와 상호작용하는 데 필요한 정보를 분배하기 위한 방법을 예시한다.
도 8은 위임된 인가 토큰들을 유효성 검증하기 위한 방법을 예시한다.
도 9a 내지 도 9d는 위임된 인가 토큰들을 유효성 검증하는 것과 관련된 예들 및 실시예들을 예시한다.
도 10a 내지 도 10e는 이벤트 스트림 서비스와 상호작용하는 예들을 예시한다.
도 11은 일 양상에 따라, 블록체인과 연관된 복수의 서비스들을 위한 플랫폼의 개요를 도시하는 개략도이다.
도 12는 일 양상에 따라, 블록체인과 연관되는 복수의 서비스들의 플랫폼의 구성요소들을 도시하는 개략도이다.
도 13은 본 개시내용의 다양한 양상들 및 실시예들이 구현될 수 있는 컴퓨팅 환경을 예시하는 개략도이다.

따라서, 계산적으로 정교하든 그렇지 않든 간에, 계산적 및 기능적으로 덜 부담되는, 간단하고 빠르고 정확하며 신뢰할 수 있고 안전한 방식으로, 임의의 클라이언트가 블록체인과 연관된 유용한 애플리케이션들에 즉각적으로 액세스하고 상호작용할 수 있도록 허용할, 안전하고, 복잡성이 낮고, 사용자 친화적이고, 효율적이며 견고한 기술들을 구현하고자 하는 바람이 있다. 보다 구체적으로, 클라이언트가 승인한 위임자들이 바람직하게는 안전하고 신뢰할 수 있고 그리고/또는 취소 가능한 방식으로 이러한 시스템으로부터 또한 혜택을 받을 수 있도록 허용하고자 하는 바램이 있다.

이러한 개선된 솔루션이 이제 창안되었다. 본 개시내용은 블록체인과 연관된 기록, 판독 또는 다른 액트들을 위한 위임된 인가(authorisation)를 갖는(및/또는 위임된 인가 토큰을 소유한) 사용자들에 의해 데이터가 간단하게, 안전하게 및/또는 즉각적으로 블록체인에 기록되거나 블록체인으로부터 획득될 수 있게 하는 하나 이상의 기술들을 제안함으로써 위의 기술적 문제들을 해결한다. 블록체인과 연관된 모든 이점들 및 그에 대한 위임된 인가를 여전히 이용 가능할 수 있으면서, 그러한 클라이언트들이 블록체인을 사용하기 위한 임의의 프로세싱 또는 기능이나, 사용자 관리를 위한 임의의 프로세싱 또는 기능을 구현할 필요 없이도, 블록체인과 연관된 하나 이상의 서비스들(및 특히 이러한 서비스들의 위임)에 대한 API(application programming interface)를 제공하는 방법들, 디바이스들 및 시스템들이 제공된다.

제1 양상에 따르면, 컴퓨터-구현 방법이 제공되며, 이 방법은, 미리 결정된 값을 획득하는 단계, 위임된 인가 토큰들의 체인 중 최초 위임된 인가 토큰을 포함하는 요청을 수신하는 단계, 위임된 인가 토큰들의 체인의 추가 위임된 인가 토큰들을 생성하는 단계 ― 위임된 인가 토큰들의 체인 내 각각의 추가 위임된 인가 토큰의 생성은 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰에 기초함 ― ; 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들 중 하나와 미리 결정된 값의 비교에 기초하여 최초 위임된 인가 토큰의 유효성을 결정하는 단계를 포함한다.

제1 양상의 방법을 책임지는 디바이스 또는 디바이스들은 위임된 인가 토큰들을 유효성 검증하므로 검증기로 간주될 수 있다. 유리하게는, 미리 결정된 값만 검증기에게 제공되더라도, 검증기는 임의의 수신된 위임된 인가 토큰들을 여전히 검증할 수 있고 따라서 최소한의 데이터 공유 및 이에 따른 더 작은 공격 표면을 요구하는 보안 인증 시스템을 제공할 수 있다. 더 작은 공격 표면은 전반적으로 더 높은 보안 시스템을 의미한다. 유리하게는, 검증기는 자신이 유효성을 검증하는 임의의 위임된 사용자의 수 또는 아이덴티티를 알 필요가 없고 그리하여 클라이언트 및 위임자들에 대한 더 양호한 프라이버시를 제공한다.

선택적으로, 생성은 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰을 해싱하는 것에 기초한다.

선택적으로, 위임된 인가 토큰들의 체인의 추가 위임된 인가 토큰들을 생성하는 단계는, 각각의 추가 위임된 인가 토큰에 대해, 중간 프리이미지를 결정하는 단계 ― 중간 프리이미지는 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰에 기초함 ― , 및 단방향 함수를 중간 프리이미지에 적용하는 단계를 수행하는 것을 포함하고, 단방향 함수에 대한 출력은 추가 위임된 인가 토큰이다. 바람직하게는 단방향 함수는 해싱 함수이다. 바람직하게는, 중간 프리이미지는 부가적으로 주어진 값에 기초한다.

유리하게는, 단방향 함수를 사용하여 위임된 인가 토큰들을 결정한다는 것은 시스템의 임의의 구성원이 자신의 현재 체인보다 높은 체인에 있는 임의의 위임된 인가 토큰을 계산할 수 없다는 것을 의미한다.

유리하게는, 프리이미지를 주어진 값(아래 초기 값으로 설명됨)에 기초함으로써, 상기 주어진 값 없으면, 시스템의 어느 구성원도 더 높은 체인에 있는 임의의 다른 위임된 인가 토큰을 계산할 수 없다. 상기 주어진 값은 제1 실시예의 방법을 실행하는 디바이스 이외의 다른 디바이스에는 제공되지 않고 그리하여, 악의적인 당사자들에 의한 공격에 대한 변조 방지 및 복원력을 증가시킨다.

선택적으로, 추가 위임된 인가 토큰들의 생성은 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰 및 주어진 값에 기초한다.

선택적으로, 방법은 저장소로부터 주어진 값을 획득하는 단계를 더 포함한다. 선택적으로, 주어진 값은 클라이언트로부터 수신된다.

선택적으로, 생성은 주어진 값 및 선행 위임된 인가 토큰의 컨케터네이션(concatenation)에 기초한다. 바람직하게는, 생성은 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰 및 주어진 값의 컨케터네이션을 해싱하는 것에 기초한다.

유리하게는, 단방향 함수와 주어진 값의 사용의 결합은 유효 토큰들 전부가 전송될 필요 없이, 유효성 검증 서비스가 위임된 인가 토큰들을 유효성 검증하는 것을 여전히 가능하게 하면서, 위임된 인가 토큰을 가진 사용자가 위임된 인가 토큰들의 체인 내 임의의 다른 위임된 인가 토큰을 계산하도록 허용하지 않는다(그리하여 추가 보안을 제공함). 클라이언트 또는 다른 디바이스가 이 제1 양상에 따른 방법을 실행하는 검증기에게 유효 토큰들을 전송할 필요성을 제거함으로써, 제3자들이 임의의 유효 토큰들을 획득할 기회가 재차 감소되고 전체 시스템의 보안이 개선된다.

선택적으로, 요청은 인덱스 번호를 더 포함하고, 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들의 수는 인덱스 번호에 기초한다. 선택적으로, 인덱스는 클라이언트가 생성한 최종 위임된 인가 토큰으로부터의 거리를 표현할 수 있다.

인덱스가 사용되고 위임자가 자신의 요청에 포함하도록 제공되는 경우, 적대적인 제3자들이 2개의 정보 부분: 해시 및 인덱스를 알도록 요구하는 더 높은 보안 시스템이 제공된다. 서비스가 요청을 프로세싱하기 위해 둘 모두가 올바라야 한다.

대안적으로, 어떠한 인덱스도 사용되지 않는다. 인덱스가 사용되지 않거나 위임자에게 제공되지 않는 경우, 유리하게는, 클라이언트들은 자신이 체인 내 어디에 있는지 알지 못하고 이에 따라 얼마나 많은 다른 위임자들이 거기에 있는지를 식별할 수 없고 그리하여 유효성 검증되는 모든 클라이언트들 및 사용자들에 대한 프라이버시를 증가시킨다.

선택적으로, 최초 위임된 인가 토큰의 유효성을 결정하는 단계는 위임된 인가 토큰들의 체인 내 최종 위임된 인가 토큰들과 미리 결정된 값의 비교에 기초한다.

선택적으로, 최초 위임된 인가 토큰의 유효성을 결정하는 단계는, 위임된 인가 토큰들의 체인 내 최종 위임된 인가 토큰 및 미리 결정된 값이 동일한 값을 갖는지를 비교하는 단계를 포함한다.

선택적으로, 요청은 블록체인에 제출하거나 블록체인으로부터 판독하기 위한 것이다.

선택적으로, 요청은 요청에 포함된 데이터의 표현이 블록체인에 레코딩되도록 블록체인 기반 데이터 레코드 서비스에 데이터를 제출하기 위한 것이다. 부가적으로 또는 대안적으로, 요청은 블록체인 기반 데이터 레코드 서비스로부터 데이터의 표현을 판독하기 위한 것이다. 바람직하게는, 데이터를 판독하라는 요청은 판독될 데이터에 대한 참조를 포함한다. 바람직하게는, 블록체인 기반 데이터 레코드 서비스는 본원에서 설명된 바와 같은 플랫폼 서비스의 일부이다.

유리하게는, 블록체인 기반 데이터 레코드 서비스는 블록체인을 상품 데이터 원장으로 간편하게 사용할 수 있는 방식을 제공한다. 또한 위임된 인가 토큰들은 블록체인 기반 데이터 레코드 서비스에 향상된 보안을 제공한다. 따라서 블록체인 기반 데이터 레코드 서비스의 위임된 사용자들은 블록체인과 상호작용할 수 있고 트랜잭션 또는 블록체인 자체와 반드시 직접 상호작용하도록 요구하지 않으면서, 안전한 방식으로 자신들의 데이터 저장 요구들에 대한 블록체인 특성들(이를테면, 불변성, 분산형, 선택적 투명성, 추적성 등)을 이용한다.

선택적으로, 요청의 유효성을 결정하는 것은 추가로, 동일한 최초 위임된 인가 토큰을 포함하는 이전에 수신된 요청들의 수에 기초한다.

유리하게는, 이는 클라이언트가 시스템을 보다 세밀하게 제어하고 불량 행위자가 스팸을 보내는 능력을 제한하는 것을 가능하게 한다. 또는, 비도덕적인 제3자가 유효한 위임된 인가 토큰을 획득한 경우, 행해질 수 있는 피해에 제한이 적용되고 그리하여 전체 시스템의 보안을 증가시킨다.

바람직하게는, 미리 결정된 값은 클라이언트가 생성한 위임된 인가 토큰이다. 바람직하게는, 미리 결정된 값은 클라이언트가 생성한 위임된 인가 토큰들의 체인 내 마지막 위임된 인가 토큰이다. 바람직하게는, 미리 결정된 값은 수신 시 위임된 인가 토큰들의 저장된 체인에 저장된다.

선택적으로, 방법은 최초 위임된 인가 토큰의 유효성에 기초하여 위임된 인가 토큰들의 체인을 저장하는 단계를 더 포함한다. 바람직하게는, 방법은 추가 위임된 인가 토큰을 포함하는 추가 요청을 수신하는 단계, 추가 위임된 인가 토큰이 위임된 인가 토큰들의 저장된 체인에 존재하는지에 기초하여 추가 위임된 인가 토큰의 유효성을 결정하는 단계를 더 포함한다.

중간 해시 결과들이 레코딩되어, 유리하게는, 후속 검증들을 위한 프로세싱 시간을 감소시킨다. 이미 수신된 것보다 낮은 인덱스(즉, 최종 위임된 인가 토큰 또는 H0에 더 가까움)를 갖는 토큰이 수신되는 경우, 해싱이 수행될 필요가 없고 컴퓨터 프로세싱 시간 및 전력이 절약된다.

선택적으로, 미리 결정된 값은 위임된 인가 토큰들의 저장된 체인 중 가장 높은 인덱스를 가진 위임된 인가 토큰이다. 바람직하게는, 추가 위임된 인가 토큰들을 생성하는 단계는 다음까지 수행된다.

선택적으로, 방법은 위임된 인가 토큰의 저장된 체인의 가장 높은 인덱스를 결정하는 단계, 가장 높은 인덱스와 동일한 인덱스를 갖는 위임된 인가 토큰이 생성될 때까지 수신된 위임된 인가 토큰에 기초하여 추가 위임된 인가 토큰들을 생성하는 단계, 최종 생성된 위임된 인가 토큰과 가장 높은 인덱스를 가진 저장된 위임된 인가 토큰의 비교에 기초하여, 수신된 위임된 인가 토큰의 유효성을 결정하는 단계를 포함한다.

선택적으로, 각각의 위임된 인가 토큰이 그와 연관된 인덱스를 갖고 인덱스는 최종 위임된 인가 토큰으로부터의 거리를 표현할 수 있는 경우, 각각의 위임된 인가 토큰은 그의 연관된 인덱스와 함께 저장되고 바람직하게는 인덱스로 검색될 수 있다. 각각의 위임된 인가 토큰을 그의 인덱스별로 저장함으로써, 유리하게는, 인덱스별로 검색하거나 인덱스로 검색하는 것이 데이터 세트를 반복하고 각각의 값을 비교하는 것보다 더 빠르고 덜 컴퓨팅 자원 집약적이기 때문에, 임의의 토큰의 존재에 대한 검색이 보다 시간 및 컴퓨터 자원 효율적이 된다.

선택적으로, 방법은 요청의 유효성의 표시를 제공하고 그리고/또는 위임된 인가 토큰의 유효성에 기초하여 요청을 프로세싱하는 단계를 더 포함한다. 바람직하게는 프로세싱은: 요청 포워딩, 요청 드롭, 요청 허용, 요청 차단, 블록체인 기반 저장 시스템에 대한 액세스 허용, 블록체인 기반 저장 시스템에 대한 판독 액세스 허용, 블록체인 기반 저장 시스템에 대한 기록 액세스 허용, 요청에 기초한 블록체인 기반 저장 시스템으로부터의 데이터의 제공 및/또는 요청에 기초한 블록체인 기반 저장 시스템에 대한 데이터의 기록 중 임의의 하나 이상을 의미한다.

제2 양상에 따르면, 연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법이 제공되며, 이 방법은, 제1 값 및 제2 값을 획득하는 단계 위임된 인가 토큰들의 체인의 최초 위임된 인가 토큰을 생성하는 단계 ― 최초 위임된 인가 토큰은 제1 값 및 제2 값에 기초함 ― , 및 위임된 인가 토큰들의 체인의 적어도 하나의 추가 위임된 인가 토큰을 생성하는 단계를 포함하고, 위임된 인가 토큰들의 체인 내 각각의 추가 위임된 인가 토큰의 생성은 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰 및 제1 값에 기초한다.

제2 양상에 따른 방법을 책임지는 디바이스 또는 디바이스들은 일반적으로 클라이언트가 자신의 액세스를 위임자들 또는 위임된 사용자들에게 위임하는 클라이언트일 것이다.

선택적으로, 위임된 인가 토큰들의 체인의 추가 위임된 인가 토큰들을 생성하는 단계는, 각각의 추가 위임된 인가 토큰에 대해, 중간 프리이미지를 결정하는 단계 ― 중간 프리이미지는 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰 및 제1 값에 기초함 ― , 및 단방향 함수를 중간 프리이미지에 적용하는 단계를 수행하는 것을 포함하고, 단방향 함수에 대한 출력은 추가 위임된 인가 토큰이다. 바람직하게는 단방향 함수는 해싱 함수이다. 바람직하게는, 중간 프리이미지는 부가적으로 주어진 값에 기초한다.

방법은 보안과 관련하여 제1 양상과 관련하여 논의된 것과 동일하거나 유사한 이점들 및 더 많은 이점들을 제공한다.

바람직하게는, 생성은 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰 및 주어진 값의 컨케터네이션을 해싱하는 것에 기초한다.

선택적으로, 방법은 위임된 인가 토큰들의 체인의 위임된 인가 토큰들 중 하나를 위임자 디바이스에 제공하는 단계를 더 포함한다. 바람직하게는, 위임자 디바이스에는 추가로, 위임된 인가 토큰의 인덱스가 제공되고, 인덱스는 제공된 위임된 인가 토큰이 위임된 인가 토큰들의 체인에서 어디에 있는지를 표현한다.

선택적으로, 방법은 위임된 인가 토큰들의 체인의 최종 위임된 인가 토큰 및 제1 값을 검증 디바이스에 제공하는 단계를 더 포함한다. 바람직하게는, 검증 디바이스에는 추가로, 위임자 당 판독들 또는 기록들의 최대 수를 표시하는 수가 제공된다.

선택적으로, 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들의 수는 위임자들의 수에 기초한다. 바람직하게는 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들의 수는 위임자들의 수와 동일하다.

제1 양상에 대해 위에서 제시된 바와 같이, 선택적으로, 위임된 인가 토큰들은 위임자들이 (바람직하게는, 블록체인 기반 데이터 레코드 서비스에 데이터를 기록하거나 그로부터 데이터를 판독하는 방식으로) 상호작용할 수 있도록 위임자들에게 제공된다.

따라서, 위의 위임된 인가 토큰들은 블록체인 기반 데이터 레코드 서비스에 액세스할 때 향상된 보안을 제공하는 동일하거나 유사한 이점이 적용된다. 따라서 블록체인 기반 데이터 레코드 서비스의 위임된 사용자들은 블록체인과 상호작용할 수 있고 트랜잭션 또는 블록체인 자체와 반드시 직접 상호작용하도록 요구하지 않으면서, 안전한 방식으로 자신들의 데이터 저장 요구들에 대한 블록체인 특성들(이를테면, 불변성, 분산형, 선택적 투명성, 추적성 등)을 이용한다.

선택적으로, 제2 값은 최초 위임된 인가 토큰이 생성된 후에 삭제된다.

유리하게는, 제2 값을 삭제함으로써, 누구도 최초 위임된 인가 토큰을 구성할 수 없고 이에 따라, 전체 체인을 구성할 수 없고 그리하여 악의적인 제3자들이 토큰들을 다시 생성하는 임의의 기회를 제거함으로써 개선된 보안을 제공한다.

선택적으로 제1 값 및 제2 값은 랜덤으로 생성된다.

바람직하게는, 제1 양상 또는 제2 양상의 선행 위임된 인가 토큰은 위임된 인가 토큰이 생성되기 직전의 위임된 인가 토큰을 지칭한다. 이는 또한 생성되거나 획득된 최신 위임된 인가 토큰일 수 있다.

제3 양상에 따르면, 제1 양상에 따라 토큰들을 유효성 검증하는 방법이 제공되며, 여기서 최초 위임된 인가 토큰은 제2 양상에 따라 클라이언트에 의해 생성되었다.

제4 양상에 따르면, 제2 양상의 방법에 따라 생성된 위임된 인가 토큰을 수신하는 단계, 위임된 인가 토큰을 포함하는 요청을 생성하는 단계, 및 요청을 서버에 전송하는 단계를 포함하는 방법이 제공된다.

제5 양상에 따르면, 서버, 위임자, 클라이언트를 포함하는 시스템이 제공되며, 클라이언트는, 제2 양상에 따라, 위임된 인가 토큰들의 체인 및 제1 값을 생성하고, 제1 값 및 위임된 인가 토큰들의 체인들의 최종 위임된 인가 토큰을 서버에 송신하고, 그리고 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들 중 하나를 위임자에게 송신하도록 구성된다.

선택적으로, 서버는 제1 양상의 방법에 따라 위임자로부터 요청을 수신하고 프로세싱하도록 구성된다.

선행 양상들 중 임의의 하나 이상에 따르면, 선택적으로, 요청들은 클라이언트 및/또는 위임된 사용자로부터 HTTPS 프로토콜을 통해 또는 이를 사용하여 수신된다. 부가적으로 또는 대안적으로, 요청들의 수신자는 웹 서비스로서 API를 구현한다. 선택적으로, 위임된 인가 토큰들은 이벤트 스트림들 및/또는 데이터 기록기 서비스들에 대한 위임된 액세스를 제공하도록 구성된다. 유리하게는, HTTPS 및/또는 API 및/또는 웹 서비스의 사용은 웹 요청의 수신자가 유연한 블록체인 기반 데이터 서비스들을 여전히 제공하는 것을 가능하게 하면서, 보완적인 보안 특징들을 제공할 수 있다. 블록체인 기반 데이터 기록기 또는 판독기에 대한 위임된 액세스를 제공하는 추가 이점들은 단지 제1 클라이언트를 넘어 더 많은 수의 사용자들이 블록체인 기반 데이터 기록기 또는 판독기 서비스들에 대한 액세스를 갖도록 (안전한 방식으로) 허용하는 것을 포함한다.

예시적인 시스템 개요

도 1은 블록체인(150)을 구현하기 위한 예시적인 시스템(100)을 도시한다. 시스템(100)은 패킷-교환 네트워크(101), 통상적으로 인터넷과 같은 광역 인터네트워크를 포함할 수 있다. 패킷-교환 네트워크(101)는 패킷-교환 네트워크(101) 내에서 P2P(peer-to-peer) 네트워크(106)를 형성하도록 배열될 수 있는 복수의 블록체인 노드들(104)을 포함한다. 예시되지는 않았지만, 블록체인 노드들(104)은 거의 완전한 그래프로서 배열될 수 있다. 따라서, 각각의 블록체인 노드(104)는 다른 블록체인 노드들(104)에 고도로 연결된다.

각각의 블록체인 노드(104)는 피어들의 컴퓨터 장비를 포함하며, 노드들(104) 중 상이한 노드들은 상이한 피어에 속한다. 각각의 블록체인 노드(104)는 하나 이상의 프로세서들, 예컨대, 하나 이상의 CPU(central processing unit)들, 가속기 프로세서들, 애플리케이션 특정 프로세서 및/또는 FPGA(field programmable gate array)들, 및 다른 장비 이를테면, ASIC(application specific integrated circuit)들을 포함하는 프로세싱 장치를 포함한다. 각각의 노드는 또한 메모리, 즉 비-일시적 컴퓨터-판독 가능 매체 또는 매체들의 형태의 컴퓨터-판독 가능 저장소를 포함한다. 메모리는 하나 이상의 메모리 매체들, 예컨대, 하드 디스크와 같은 자기 매체; 솔리드 스테이트 드라이브(SSD), 플래시 메모리 또는 EEPROM과 같은 전자 매체; 및/또는 광학 디스크 드라이브와 같은 광학 매체를 사용하는 하나 이상의 메모리 유닛들을 포함할 수 있다.

블록체인(150)은 데이터의 블록들의 체인(151)을 포함하며, 여기서 블록체인(150)의 개개의 사본은 분산 또는 블록체인 네트워크(160) 내 복수의 블록체인 노드들(104) 각각에서 유지된다. 위에서 언급된 바와 같이, 블록체인(150)의 사본을 유지하는 것은 반드시 블록체인(150)을 전부 저장하는 것을 의미하지는 않는다. 대신, 블록체인(150)은 각각의 블록체인 노드(150)가 각각의 블록(151)의 블록 헤더(아래에서 논의됨)를 저장하는 한, 정리된 상태의 데이터일 수 있다. 체인의 각각의 블록(151)은 하나 이상의 트랜잭션들(152)을 포함하며, 여기서 이 맥락에서 트랜잭션은 일종의 데이터 구조를 지칭한다. 데이터 구조의 성질은 트랜잭션 모델 또는 체계(scheme)의 일부로서 사용되는 트랜잭션 프로토콜의 유형에 의존할 것이다. 주어진 블록체인은 전반에 걸쳐 하나의 특정 트랜잭션 프로토콜을 사용할 것이다. 하나의 공통 유형의 트랜잭션 프로토콜에서, 각각의 트랜잭션(152)의 데이터 구조는 적어도 하나의 입력 및 적어도 하나의 출력을 포함한다. 각각의 출력은 재산으로서 디지털 자산의 양을 표현하는 금액을 지정하며, 그의 예는 출력이 암호학적으로 잠겨 있는 사용자(103)이다(이는 잠금해제되고 그리하여 리딤(redeem) 또는 지출되기 위해 그 사용자의 서명 또는 다른 솔루션을 요구함). 각각의 입력은 선행 트랜잭션(152)의 출력을 뒤로 가리키고, 그리하여 트랜잭션들을 링크한다.

각각의 블록(151)은 또한 블록들(151)에 대한 순차적인 순서를 정의하기 위해 체인에서 이전에 생성된 블록(151)을 뒤로 가리키는 블록 포인터(155)를 포함한다. (코인베이스 트랜잭션 외의) 각각의 트랜잭션(152)은 트랜잭션들의 시퀀스들에 대한 순서를 정의하기 위해 이전 트랜잭션에 대한 역 포인터를 포함한다(트랜잭션들(152)의 시퀀스들은 분기가 허용됨을 주의함). 블록들의 체인(151)은 체인의 최초 블록이었던 제네시스(genesis) 블록(Gb)(153)까지 완전히 거슬러 올라간다. 체인(150) 초반의 하나 이상의 오리지널 트랜잭션들(152)은 선행 트랜잭션이 아닌 제네시스 블록(153)을 가리켰다.

블록체인 노드들(104) 각각은 트랜잭션들(152)을 다른 블록체인 노드들(104)로 포워딩하고 그리하여 트랜잭션들(152)이 네트워크(106) 전체에 전파되게 하도록 구성된다. 각각의 블록체인 노드(104)는 블록들(151)을 생성하고 동일한 블록체인(150)의 개개의 사본을 그들 개개의 메모리에 저장하도록 구성된다. 각각의 블록체인 노드(104)는 또한 블록(151)에 통합되기를 기다리는 트랜잭션들(152)의 순서화된 세트(154)를 유지한다. 순서화된 세트(154)는 종종 "멤풀(mempool)"로서 지칭된다. 본원에서 이 용어는 임의의 특정 블록체인, 프로토콜 또는 모델에 제한되는 것으로 의도되지 않는다. 이는 노드(104)가 유효한 것으로 수락하고 노드(104)가 동일한 출력을 지출하려고 시도하는 임의의 다른 트랜잭션들을 수락하지 않을 의무가 있는 트랜잭션들의 순서화된 세트를 지칭한다.

주어진 현재 트랜잭션(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)은 다수의 사용자들 또는 엔티티들(이들 중 하나는 잔돈(change)을 주기 위해 오리지널 사용자 또는 엔티티들(103a)일 수 있음) 사이에서 입력 금액을 분할하기 위해 다수의 출력들을 가질 수 있다. 일부 경우에서 트랜잭션은 또한 하나 이상의 선행 트랜잭션들의 다수의 출력들로부터 금액들을 수집하고 현재 트랜잭션의 하나 이상의 출력들에 재분배하기 위해 다수의 입력들을 가질 수 있다.

비트코인과 같은 출력-반 트랜잭션 프로토콜에 따르면, 사용자 또는 기계와 같은 엔티티(103)가 새로운 트랜잭션(152j)을 제정하기를 원할 때, 엔티티는 자신의 컴퓨터 단말(102)로부터 수령인에게 새로운 트랜잭션을 전송한다. 엔티티 또는 수령인은 결국, 이 트랜잭션을 네트워크(106)의 블록체인 노드들(104) 중 하나 이상(이는 요즘에는, 통상적으로 서버들 또는 데이터 센터들이지만, 원칙적으로는 다른 사용자 단말들일 수 있음)에 전송할 것이다. 그것은 또한 새로운 트랜잭션(152j)을 제정하는 엔티티(103)가 일부 예들에서는 수령인이 아니라, 블록체인 노드들(104) 중 하나 이상에 트랜잭션을 전송할 수 있는 것이 배제되지 않는다. 트랜잭션을 수신한 블록체인 노드(104)는 블록체인 노드들(104) 각각에 적용되는 블록체인 노드 프로토콜에 따라 트랜잭션이 유효한지를 체크한다. 블록체인 노드 프로토콜은 통상적으로 블록체인 노드(104)가 새로운 트랜잭션(152j)의 암호화 서명이 예상되는 서명과 매칭되는지를 체크하도록 요구하며, 이는 트랜잭션들(152)의 순서화된 시퀀스에서 이전 트랜잭션(152i)에 의존한다. 이러한 출력-기반 블록체인 프로토콜에서, 이는 새로운 트랜잭션(152j)의 입력에 포함된 엔티티(103)의 암호화 서명 또는 다른 인가가 새로운 트랜잭션이 할당하는 선행 트랜잭션(152i)의 출력에 정의된 조건과 매칭되는지를 체크하는 것을 포함하며, 여기에서 이 조건은 통상적으로 적어도 새로운 트랜잭션(152j)의 입력의 암호화 서명 또는 다른 인가가 새로운 트랜잭션의 입력이 링크되는 이전 트랜잭션(152i)의 출력을 잠금해제한다는 것을 체크하는 것을 포함한다. 조건은 선행 트랜잭션(152i)의 출력에 포함된 스크립트에 의해 적어도 부분적으로 정의될 수 있다. 대안적으로 이는 단순히 블록체인 노드 프로토콜만으로 고정되거나, 이들의 조합으로 인한 것일 수 있다. 어느 쪽이든, 새로운 트랜잭션(152j)이 유효한 경우, 블록체인 노드(104)는 이를 블록체인 네트워크(106) 내 하나 이상의 다른 블록체인 노드들(104)에 포워딩한다. 이러한 다른 블록체인 노드들(104)은 동일한 블록체인 노드 프로토콜에 따라 동일한 테스트를 적용하고, 이에 따라 새로운 트랜잭션(152j)을 하나 이상의 추가 노드들(104)로 포워딩하는 식이다. 이러한 방식으로, 새로운 트랜잭션은 블록체인 노드들(104)의 네트워크 전반에 걸쳐 전파된다.

출력-기반 모델에서, 주어진 출력(예컨대, UTXO)이 할당되는지 여부에 대한 정의는 그것이 블록체인 노드 프로토콜에 따라 다른 전방 트랜잭션(152j)의 입력에 의해 유효하게 리딤되었는지의 여부이다. 트랜잭션이 유효하기 위한 다른 조건은 할당 또는 리딤을 시도하는 선행 트랜잭션(152i)의 출력이 다른 트랜잭션에 의해 이미 할당/리딤되지 않은 것이다. 재차, 유효하지 않은 경우, (무효로서 플래깅되고 경고를 위해 전파되지 않는 한) 트랜잭션(152j)은 블록체인(150)에 레코딩되거나 전파되지 않을 것이다. 이는 트랜잭터가 동일한 트랜잭션의 출력을 한번 초과로 할당하고자 시도하는 이중-지출을 경계한다. 반면, 계정-기반 모델은 계정 잔액을 유지함으로써 이중-지출을 경계한다. 재차, 트랜잭션들의 정의된 순서가 존재하기 때문에, 계정 잔액은 임의의 한 시간에 단일의 정의된 상태를 갖는다.

트랜잭션들을 유효성 검증하는 것 외에도, 블록체인 노드들(104)은 또한 일반적으로 "작업 증명"에 의해 지원되는 채굴로서 지칭되는 프로세스에서 트랜잭션들의 블록들을 생성하는 첫 번째가 되기 위해 경쟁한다. 블록체인 노드(104)에서, 새로운 트랜잭션들은 블록체인(150) 상에 레코딩된 블록(151)에 아직 나타나지 않은 유효한 트랜잭션들의 순서화된 세트(154)에 추가된다. 그 후, 블록체인 노드들은 암호화 퍼즐을 해결하도록 시도함으로써 트랜잭션들의 순서화된 세트(154)로부터 트랜잭션들(152)의 새로운 유효한 블록(151)을 조립하기 위해 경쟁한다. 통상적으로 이는 "논스(nonce)"가 트랜잭션들(154)의 순서화된 세트의 표현과 컨케터네이팅되고(concatenated) 해시될 때, 해시의 출력이 미리 결정된 조건을 충족시키도록 논스 값을 검색하는 것을 포함한다. 예컨대, 미리 결정된 조건은 해시의 출력이 미리 정의된 특정 수의 선행 0들을 갖는 것일 수 있다. 이는 작업 증명 퍼즐의 단 하나의 특정 유형일 뿐이며 다른 유형들도 배제되지 않는다는 것에 주의한다. 해시 함수의 속성은 해시 함수가 그의 입력에 대해 예측 불가능한 출력을 갖는다는 것이다. 따라서 이 검색은 무차별 대입(brute force)에 의해서만 수행될 수 있고, 이에 따라 퍼즐을 해결하고자 하는 각각의 블록체인 노드(104)에서 상당한 양의 프로세싱 자원을 소비한다.

퍼즐을 해결하고자 하는 제1 블록체인 노드(104)는 이를 네트워크(106)에 발표하고, 그 솔루션을 증명으로서 제공하며, 이는 그 후 네트워크의 다른 블록체인 노드(104)들에 의해 쉽게 체크될 수 있다(해시에 대한 솔루션이 주어지면, 그 해가 해시의 출력으로 하여금 조건을 충족시키게 한다는 것을 체크하는 것은 간단함). 제1 블록체인 노드(104)는 블록을 수락하고 이에 따라 프로토콜 규칙들을 시행하는 다른 노드들의 임계 합의에 블록을 전파한다. 트랜잭션들의 순서화된 세트(154)는 그 후 블록체인 노드들(104) 각각에 의해 블록체인(150)에 새로운 블록(151)으로서 레코딩된다. 블록 포인터(155)가 또한 체인에서 이전에 생성된 블록(151n-1)을 뒤로 가리키는 새로운 블록(151n)에 할당된다. 예컨대, 작업 증명 솔루션을 생성하는 데 요구되는 해시 형태의 상당량의 노력은 블록체인 프로토콜의 규칙들에 따르려는 제1 노드(104)의 의도를 시그널링한다. 이러한 규칙들은 트랜잭션이 이전에 유효성 검증된 트랜잭션과 동일한 출력을 할당 ― 이는 이중 지출로서 달리 알려짐 ― 하는 경우 트랜잭션을 유효한 것으로 수락하지 않는 것을 포함한다. 일단 생성되면, 블록(151)은 블록체인 네트워크(106) 내 블록체인 노드들(104) 각각에서 인식 및 유지되기 때문에 수정될 수 없다. 블록 포인터(155)는 또한 블록들(151)에 순차적인 순서를 부과한다. 트랜잭션들(152)은 네트워크(106)의 각각의 블록체인 노드(104)에서 순서화된 블록들에 레코딩되기 때문에, 이는 이에 따라, 트랜잭션들의 변경 불가능한 공개 원장을 제공한다.

임의의 주어진 시간에 퍼즐을 해결하기 위해 경쟁하는 상이한 블록체인 노드들(104)은 솔루션을 검색하기 시작한 시기 또는 트랜잭션이 수신된 순서에 의존하여, 임의의 주어진 시간에 아직 공개되지 않은 트랜잭션들 순서화된 세트(154)의 상이한 스냅샷들에 기초하여 퍼즐을 해결할 수 있다는 것에 주의한다. 누구든 각자의 퍼즐을 먼저 해결하는 사람은 어느 트랜잭션들(152)이 어떤 순서로 다음의 새로운 블록(151n)에 포함되는지를 정의하고, 공개되지 않은 트랜잭션들의 현재 세트(154)는 업데이트된다. 그 후 블록체인 노드들(104)은 공개되지 않은 트랜잭션들(154)의 새롭게 정의된 미해결 순서화된 세트로부터 블록을 생성하기 위해 계속 경쟁한다. 발생할 수 있는 임의의 "포크(fork)” ― 이는 2개의 블록체인 노드들(104)이 서로 매우 짧은 시간 내에 그의 퍼즐을 해결하여서, 블록체인에 대한 상충되는 뷰(view)가 노드들 사이에 전파되는 경우임 ― 를 해결하기 위한 프로토콜이 또한 존재한다. 요컨대, 가장 길게 성장하는 포크의 갈래가 확정적인 블록체인(150)이 된다. 동일한 트랜잭션들이 포크들 둘 모두에 나타날 것이므로, 이는 네트워크의 사용자들 또는 에이전트들에게 영향을 미치지 않아야 한다.

비트코인 블록체인(및 대부분의 다른 블록체인들)에 따르면, 새로운 블록(104)을 성공적으로 구성하는 노드에는 (하나의 에이전트 또는 사용자로부터 다른 에이전트 또는 사용자로 디지털 자산의 금액을 이전하는 에이전트-간 또는 사용자-간 트랜잭션과 대조적으로) 디지털 자산의 정의된 양을 분배하는 새로운 특별한 종류의 트랜잭션들에서 디지털 자산의 수락된 금액을 할당하는 능력이 승인된다. 이 특별한 유형의 트랜잭션은 일반적으로 "코인베이스 트랜잭션"으로서 지칭되지만, "초기 트랜잭션"이라고도 칭해질 수 있다. 그것은 통상적으로 새로운 블록(151n)의 제1 트랜잭션을 형성한다. 작업 증명은 나중에 이 특별한 트랜잭션이 리딤되도록 허용하는 프로토콜 규칙들을 따르도록 새로운 블록을 구성하는 노드의 의도를 시그널링한다. 블록체인 프로토콜 규칙은 이 특별한 트랜잭션이 리딤되기 전에 만기 기간 예컨대, 100개의 블록들을 요구할 수 있다. 종종 일반(비-생성) 트랜잭션(152)이 또한 그 트랜잭션이 공개된 블록(151n)을 생성한 블록체인 노드(104M)를 추가로 보상하기 위해, 그의 출력들 중 하나에 부가적인 트랜잭션 수수료를 지정할 것이다. 이 수수료는 일반적으로 "트랜잭션 수수료"로서 지칭되고 아래에서 논의된다.

트랜잭션 유효성 검증 및 공개와 관련된 자원들로 인해, 통상적으로 적어도 블록체인 노드들(104) 각각은 하나 이상의 물리적 서버 유닛들, 또는 심지어 전체 데이터 센터를 포함하는 서버의 형태를 취한다. 그러나 원칙적으로 임의의 주어진 블록체인 노드(104)는 사용자 단말 또는 함께 네트워킹된 사용자 단말들의 그룹의 형태를 취할 수 있다.

각각의 블록체인 노드(104)의 메모리는 블록체인 노드 프로토콜에 따라 각자의 역할 또는 역할들을 수행하고 트랜잭션들(152)을 처리하기 위해 블록체인 노드(104)의 프로세싱 장치 상에서 실행되도록 구성된 소프트웨어를 저장한다. 본원에서 블록체인과 노드(104)에 기인한 임의의 액션은 각자의 컴퓨터 장비의 프로세싱 장치 상에서 실행되는 소프트웨어에 의해 수행될 수 있다는 것이 이해될 것이다. 노드 소프트웨어는 애플리케이션 계층, 또는 운영 체제 계층이나 프로토콜 계층과 같은 하위 계층 또는 이들의 임의의 조합에서 하나 이상의 애플리케이션들로 구현될 수 있다.

또한 네트워크(101)에는 소비 사용자들의 역할을 하는 복수의 당사자들(103) 각각의 컴퓨터 장비(102)가 연결되어 있다. 이러한 사용자들은 블록체인 네트워크와 상호작용할 수 있지만, 트랜잭션들 및 블록들의 유효성 검증, 구성 또는 전파에는 참여하지 않는다. 이러한 사용자들 또는 에이전트들(103) 중 일부는 트랜잭션들에서 전송자들 및 수령인들로서 작용할 수 있다. 다른 사용자들은 반드시 전송자들 또는 수령인들로서 작용할 필요 없이 블록체인(150)과 상호작용할 수 있다. 예컨대, 일부 당사자들은 블록체인(150)의 사본을 저장하는 저장 엔티티들로서 작용할 수 있다(예컨대, 블록체인 노드(104)로부터 블록체인의 사본을 획득함).

당사자들(103) 중 일부 또는 전부는 상이한 네트워크, 예컨대, 블록체인 네트워크(106) 위에 오버레이된 네트워크의 부분으로서 연결될 수 있다. 블록체인 네트워크의 사용자들(종종 "클라이언트"로서 지칭됨)은 블록체인 네트워크를 포함하는 시스템의 일부로서 언급될 수 있지만; 이러한 사용자들은 블록체인 노드들에서 요구되는 역할을 수행하지 않기 때문에 블록체인 노드들(104)이 아니다. 대신에, 각각의 당사자(103)는 블록체인 네트워크(106)와 상호작용할 수 있고 그리하여 블록체인 노드(106)에 연결(즉, 통신)함으로써 블록체인(150)을 활용할 수 있다. 제1 당사자(103a) 및 그/그녀의 개개의 컴퓨터 장비(102a) 및 제2 당사자(103b) 및 그/그녀의 개개의 컴퓨터 장비(102b)인 두 당사자들(103) 및 이들의 개개의 장비(102)가 예시 목적으로 도시된다. 훨씬 더 많은 이러한 당사자들(103) 및 이들의 개개의 컴퓨터 장비(102)가 존재하고 시스템(100)에 참여할 수 있지만, 편의상 그것들은 예시되지 않는다는 것이 이해될 것이다. 각각의 당사자(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)는 또한 사용자 단말을 통해 액세스되는 클라우드 컴퓨팅 자원들과 같은 하나 이상의 다른 네트워킹된 자원들을 포함할 수 있다.

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

클라이언트 애플리케이션(105)은 적어도 "지갑" 기능을 포함한다. 이는 2개의 메인 기능성들을 갖는다. 이들 중 하나는 개개의 당사자(103)가 트랜잭션들(152)을 생성하고 인가(예컨대, 서명)하여 하나 이상의 비트코인 노드들(104)에 전송하여, 이어서 블록체인 노드들(104)의 네트워크 전반에 걸쳐 전파되고 그리하여 블록체인(150)에 포함되는 것을 가능하게 하는 것이다. 남은 하나는 개개의 당사자에게 자신이 현재 소유하고 있는 디지털 자산의 금액을 다시 보고하는 것이다. 출력-기반 시스템에서, 이 제2 기능성은 블록체인(150) 전반에 걸쳐 흩어져 있는 해당 당사자에 속하는 다양한 트랜잭션들(152)의 출력들에서 정의된 금액들을 대조하는 것을 포함한다.

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

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

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

새롭게 수신된 트랜잭션(152j)이 유효한 것으로 간주되기 때문에 테스트를 통과한다는 것을 조건으로(즉, 그것이 "유효성 검증"된다는 조건으로), 트랜잭션(152j)을 수신하는 임의의 블록체인 노드(104)는 새로운 유효성 검증된 트랜잭션(152)을 그 블록체인 노드(104)에서 유지되는 블록체인들(154)의 순서화된 세트(154)에 추가할 것이다. 또한, 트랜잭션(152j)을 수신하는 임의의 블록체인 노드(104)는 유효성 검증된 트랜잭션(152)을 네트워크(106)의 하나 이상의 다른 블록체인 노드들(104)로 전방으로 전파시킬 것이다. 각각의 블록체인 노드(104)가 동일한 프로토콜을 적용하기 때문에, 트랜잭션(152j)이 유효하다고 가정하면, 이는 그것이 곧 전체 네트워크(106)에 걸쳐 전파될 것임을 의미한다.

일단 주어진 블록체인 노드(104)에서 유지되는 트랜잭션(154)의 순서화된 세트에 허용되면, 블록체인 노드(104)는 새로운 트랜잭션(152)을 포함하여 트랜잭션(154)의 각자의 순서화된 세트의 최신 버전 상에서 작업 증명 퍼즐을 해결하기 위해 경쟁하기 시작할 것이다(다른 블록체인 노드들(104)은 트랜잭션들의 상이한 순서화된 세트(154)에 기초하여 퍼즐을 해결하려고 시도할 수 있지만 누구든 먼저 해결하는 사람은 최신 블록(151)에 포함된 트랜잭션들의 순서화된 세트를 정의할 것임을 상기한다). 결국 블록체인 노드(104)는 앨리스의 트랜잭션(152j)을 포함하는 순서화된 세트(154)의 일부에 대한 퍼즐을 해결할 것이다. 새로운 트랜잭션(152j)을 포함하는 순서화된 세트(154)에 대한 작업 증명이 완료되면, 이는 변경 불가능하게 블록체인(150)의 블록들(151) 중 하나의 부분이 된다. 각각의 트랜잭션(152)은 이전 트랜잭션에 대한 역 포인터를 포함하여서, 트랜잭션들의 순서가 또한 변경 불가능하게 레코딩된다.

상이한 블록체인 노드들(104)은 주어진 트랜잭션의 상이한 인스턴스들을 먼저 수신하고 이에 따라 하나의 인스턴스가 새로운 블록(151)에 공개되기 전에 어떤 인스턴스가 '유효'한지에 관한 상충되는 뷰들을 가질 수 있으며, 이 때 모든 블록체인 노드들(104)은 공개된 인스턴스가 유일한 유효 인스턴스라는 것에 동의한다. 블록체인 노드(104)가 하나의 인스턴스를 유효한 것으로 수락하고 그 후 제2 인스턴스가 블록체인(150)에 레코딩되었음을 발견하는 경우, 해당 블록체인 노드(104)는 이를 수락해야 하며 초기에 수락된 인스턴스(즉, 블록(151)에서 공개되지 않은 인스턴스)를 폐기(즉, 유효하지 않은 것으로 취급)할 것이다.

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

UTXO -기반 모델

도 2는 예시적인 트랜잭션 프로토콜을 예시한다. 이는 UTXO-기반 프로토콜의 예이다. 트랜잭션(152)(약칭 "Tx")은 블록체인(150)의 기본 데이터 구조이다(각각의 블록(151)은 하나 이상의 트랜잭션들(152)을 포함함). 다음은 출력-기반 또는 "UTXO" 기반 프로토콜을 참조하여 설명될 것이다. 그러나 이것은 모든 가능한 실시예들로 제한되지 않는다. 예시적인 UTXO-기반 프로토콜이 비트코인을 참조하여 설명되지만, 다른 예시적인 블록체인 네트워크들 상에서 동일하게 구현될 수 있다는 것에 주의한다.

UTXO-기반 모델에서, 각각의 트랜잭션("Tx")(152)은 하나 이상의 입력들(202) 및 하나 이상의 출력들(203)을 포함하는 데이터 구조를 포함한다. 각각의 출력(203)은 (UTXO가 아직 리딤되지 않은 경우) 다른 새로운 트랜잭션의 입력(202)에 대한 소스로서 사용될 수 있는 미지출 트랜잭션 출력(unspent transaction output; UTXO)을 포함할 수 있다. UTXO는 디지털 자산의 금액을 지정하는 값을 포함한다. 이는 분산 원장 상의 세팅된 수의 토큰들을 표현한다. UTXO는 또한 다른 정보 중에서도, 그것이 발생한 트랜잭션의 트랜잭션 ID를 포함할 수 있다. 트랜잭션 데이터 구조는 또한 입력 필드(들)(202) 및 출력 필드(들)(203)의 크기의 표시자를 포함할 수 있는 헤더(201)를 포함할 수 있다. 헤더(201)는 또한 트랜잭션의 ID를 포함할 수 있다. 실시예들에서, 트랜잭션 ID는 (트랜잭션 ID 자체는 제외한) 트랜잭션 데이터의 해시이고 노드들(104)에게 제출된 원시 트랜잭션(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)에 포함되었을 수 있다. 이는 그 시간에 이미 블록들(151) 중 하나에 포함되었거나, 순서화된 세트(154)에서 여전히 대기 중일 수 있으며, 이 경우에 곧 새로운 블록(151)에 포함될 것이다. 대안적으로 Tx₀ 및 Tx₁이 생성되고 네트워크(106)에 함께 전송될 수 있거나 또는 노드 프로토콜이 "고아" 트랜잭션들을 버퍼링하도록 허용하는 경우 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₀의 해시인 그의 트랜잭션 ID인 TxID₀에 의해) Tx₁을 뒤로 가리키는 포인터를 포함한다. Tx₁의 입력(202)은 Tx₀ 내에서 UTXO₀을 식별하는 인덱스를 포함하여, Tx₀의 임의의 다른 가능한 출력들 사이에서 그것을 식별한다. Tx₁의 입력(202)은 앨리스의 암호화 서명을 포함하는 잠금해제 스크립트 <Sig P_A>를 더 포함하며, 이는 앨리스가 키 쌍으로부터 자신의 개인 키를 데이터의 미리 정의된 부분(때로는 암호법에서 "메시지"라 불림)에 적용함으로써 생성된다. 유효한 서명을 제공하기 위해 앨리스에 의해 서명될 필요가 있는 데이터(또는 "메시지")는 잠금 스크립트, 노드 프로토콜 또는 이들의 조합에 의해 정의될 수 있다.

새로운 트랜잭션 Tx₁이 블록체인 노드(104)에 도달할 때, 노드는 노드 프로토콜을 적용한다. 이는 잠금해제 스크립트가 잠금 스크립트에 정의된 조건(이 조건은 하나 이상의 기준들을 포함할 수 있음)을 충족시키는지를 체크하기 위해 잠금 스크립트 및 잠금해제 스크립트를 함께 실행하는 것을 포함한다. 실시예들에서, 이는 2개의 스크립트들을 컨케터네이팅(concatenating)하는 것을 수반한다.

여기에서 "||"는 컨케터네이션을 표현하고 "<...>"는 스택 상에 데이터를 배치하는 것을 의미하고, "[…]"는 잠금 스크립트(이 예에서, 스택-기반 언어)에 의해 구성된 함수이다. 동등하게, 스크립트들을 컨케터네이팅하는 대신, 스크립트들은 공통 스택을 사용하여 번갈아 실행될 수 있다. 어느 쪽이든, 함께 실행될 때, 스크립트들은 Tx₀의 출력의 잠금 스크립트에 포함된 바와 같은 앨리스의 공개 키 P_A를 사용하여, Tx₁의 입력의 잠금해제 스크립트가 데이터의 예상되는 부분에 서명하는 앨리스의 서명을 포함한다는 것을 인증한다. 이 인증을 수행하기 위하여 데이터의 예상되는 부분 자체("메시지")가 또한 포함될 필요가 있다. 실시예들에서, 서명된 데이터는 Tx₁ 전체를 포함한다(이에 따라, 평문으로 데이터의 서명된 부분을 지정하는 별개의 요소가 포함될 필요가 없는데, 그 이유는 그것이 이미 본질적으로 존재하기 때문임).

공개-개인 암호법에 의한 인증의 세부사항들은 당업자에게 친숙할 것이다. 기본적으로, 앨리스가 자신의 개인 키를 사용하여 메시지에 서명한 경우, 앨리스의 공개 키 및 평문의 메시지를 감안하여, 노드(104)와 같은 다른 엔티티는 메시지가 앨리스에 의해 서명된 것임이 틀림없다는 것을 인증할 수 있다. 서명은 통상적으로 메시지를 해시하는 것, 해시에 서명하는 것, 그리고 이를 서명으로서 메시지에 태깅하고, 이에 따라 공개 키의 임의의 보유자(holder)가 서명을 인증하는 것을 가능하게 하는 것을 포함한다. 따라서 여기에서 특정 데이터 조각 또는 트랜잭션의 일부 등에 서명하는 것에 대한 임의의 참조는 실시예들에서 해당 데이터 조각 또는 트랜잭션 일부의 해시에 서명하는 것을 의미할 수 있다는 것에 주의한다.

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

주어진 트랜잭션(152)의 모든 출력들(203)에서 지정된 총 금액이 모든 그의 입력들(202)에 의해 가리켜지는 총 금액보다 큰 경우, 이는 대부분의 트랜잭션 모델들에서 무효에 대한 다른 근거이다. 따라서 이러한 트랜잭션들은 전파되지도 않고 블록(151)에 포함되지 않을 것이다.

UTXO-기반 트랜잭션 모델에서, 주어진 UTXO는 전체로서 지출될 필요가 있다는 것에 주의한다. 다른 프랙션(fraction)이 지출되면서, 지출된 것으로 UTXO에서 정의된 금액의 프랙션을 "남겨둘" 수는 없다. 그러나 UTXO로부터의 금액은 다음 트랜잭션의 다수의 출력들 사이에서 분할될 수 있다. 예컨대, Tx₀의 UTXO₀에 정의된 금액은 Tx₁의 다수의 UTXO들 사이에서 분할될 수 있다. 따라서 앨리스가 UTXO₀에 정의된 모든 금액을 밥에게 주기를 원하지 않는 경우, 앨리스는 Tx₁의 제2 출력에서 자신에게 잔돈을 주거나, 다른 당사자에게 지불하는데 나머지를 사용할 수 있다.

실제로, 앨리스는 또한 일반적으로 그녀의 트랜잭션(104)을 공개한 비트코인 노드에 대한 수수료를 포함할 필요가 있을 것이다. 앨리스가 그러한 수수료를 포함시키지 않는 경우, Tx₀은 블록체인 노드들(104M)에 의해 거부될 수 있고, 이에 따라 기술적으로 유효하더라도, 전파되어 블록체인(150)에 포함되지 않을 수 있다(노드프로토콜은 블록체인 노드들(104)이 원하지 않는 경우 이들에게 트랜잭션들(152)을 수락하도록 강요하지 않음). 일부 프로토콜들에서, 트랜잭션 수수료는 자체의 별개의 출력(203)을 요구하지 않는다(즉, 별개의 UTXO가 필요하지 않음). 대신, 주어진 트랜잭션(152)의 입력(들)(202)에 의해 가리켜지는 총 금액과 출력(들)(203)에 지정된 총 금액 사이의 임의의 차이는 트랜잭션을 공개한 블록체인 노드(104)에게 자동으로 주어진다. 예컨대, UTXO₀에 대한 포인터가 Tx₁에 대한 유일한 입력이고 Tx₁는 단 하나의 출력 UTXO₁만을 갖는다고 하자. UTXO₀에 지정된 디지털 자산의 금액이 UTXO₁에 지정된 금액보다 큰 경우, 차이는 UTXO₁을 포함하는 블록을 공개한 노드(104)에 의해 할당될 수 있다. 그러나 대안적으로 또는 부가적으로, 트랜잭션 수수료가 트랜잭션(152)의 UTXO들(203) 중 자체 UTXO에서 명시적으로 지정될 수 있다는 것이 반드시 배제되는 것은 아니다.

앨리스 및 밥의 디지털 자산들은 블록체인(150)의 임의의 위치의 임의의 트랜잭션들(152)에서 그들에게 잠겨 있는 UTXO로 구성된다. 따라서 통상적으로, 주어진 당사자(103)의 자산들은 블록체인(150) 전반에 걸친 다양한 트랜잭션들(152)의 UTXO들에 걸쳐 흩어져 있다. 블록체인(150)의 어떤 위치에도 주어진 당사자(103)의 총 잔액을 정의하는 숫자는 전혀 없다. 클라이언트 애플리케이션(105)에서 지갑 기능의 역할은, 개개의 당사자에게 잠겨 있으며 다른 전방 트랜잭션에서 아직 지출되지 않은 모든 다양한 UTXO들의 값들을 함께 대조하는 것이다. 비트코인 노드들(104) 중 임의의 것에 저장된 블록체인(150)의 사본을 질의함으로써 이것이 수행될 수 있다.

스크립트 코드는 종종 도식적으로(즉, 정확한 언어를 사용하지 않음) 표현된다는 것에 주의한다. 예컨대, 특정 기능을 표현하기 위해 작업 코드(opcode)들이 사용될 수 있다. "OP_..."는 스크립트 언어의 특정 작업코드(opcode)를 지칭한다. 예로서, OP_RETURN은 잠금 스크립트의 선두에서 OP_FALSE가 앞에 있을 때 트랜잭션 내에 데이터를 저장하고 그리하여 데이터를 블록체인(150)에 변경 불가능하게 레코딩할 수 있는 트랜잭션의 지출 불가능한 출력을 생성하는 스크립트 언어의 작업코드이다. 예컨대, 데이터는 블록체인에 저장하고자 하는 문서를 포함할 수 있다.

통상적으로, 트랜잭션의 입력은 공개 키 P_A에 대응하는 디지털 서명을 포함한다. 실시예들에서, 이는 타원 곡선 secp256k1을 사용하는 ECDSA에 기초한다. 디지털 서명은 특정 데이터 조각에 서명한다. 일부 실시예들에서, 주어진 트랜잭션에 대해, 서명은 트랜잭션 입력의 일부, 및 트랜잭션 출력들의 전부 또는 일부에 서명할 것이다. 서명되는 출력들의 특정 부분들은 SIGHASH 플래그에 의존한다. SIGHASH 플래그는 일반적으로 어느 출력들이 서명되는지를 선택하기 위해 서명의 끝에 포함된 4-바이트 코드이다(이에 따라, 서명 시에 고정됨).

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

도 1에 도시된 바와 같이, 앨리스 및 밥의 컴퓨터 장비(102a, 120b) 각각 상의 클라이언트 애플리케이션은 각각 부가적인 통신 기능성을 포함할 수 있다. 즉, 부가적인 기능성은 (어느 한 당사자 또는 제3자의 주도로) 앨리스(103a)가 밥(103b)과 별개의 사이드 채널(301)을 설정하는 것을 가능하게 한다. 사이드 채널(301)은 블록체인 네트워크와 별개로 데이터 교환을 가능하게 한다. 이러한 통신을 때로는 "오프-체인(off-chain)" 통신으로서 지칭된다. 예컨대, 이는 당사자들 중 하나가 네트워크(106)로 브로드캐스팅하기로 선택할 때까지, (아직) 트랜잭션이 블록체인 네트워크(106) 상에 등록되거나 체인(150)으로 진행됨 없이 앨리스와 밥 사이에서 트랜잭션(152)을 교환하는 데 사용될 수 있다. 이러한 방식으로 트랜잭션을 공유하는 것은 때로는 "트랜잭션 템플릿" 공유하는 것으로서 지칭된다. 트랜잭션 템플릿은 완전한 트랜잭션을 형성하기 위해 요구되는 하나 이상의 입력들 및/또는 출력들이 없을 수 있다. 대안적으로 또는 부가적으로, 사이드 채널(301)은 키들, 협상된 금액들 또는 조건들, 데이터 콘텐츠 등과 같은 임의의 다른 트랜잭션 관련 데이터를 교환하는 데 사용될 수 있다.

사이드 채널(301)은 블록체인 네트워크(106)와 동일한 패킷 교환 네트워크(101)를 통해 설정될 수 있다. 대안적으로 또는 부가적으로, 사이드 채널(301)은 상이한 네트워크 이를테면, 모바일 셀룰러 네트워크, 또는 로컬 영역 네트워크 이를테면, 로컬 무선 네트워크, 또는 심지어, 앨리스 및 밥의 디바이스들(102a, 102b) 사이의 직접 유선 또는 무선 링크를 통해 설정될 수 있다. 일반적으로, 본원의 임의의 위치에서 지칭되는 바와 같은 사이드 채널(301)은 "오프-체인", 즉 블록체인 네트워크(106)와 별개로 데이터를 교환하기 위한 하나 이상의 네트워킹 기술들 또는 통신 매체들을 통한 임의의 하나 이상의 링크들을 포함할 수 있다. 하나 초과의 링크가 사용되는 경우, 오프-체인 링크들의 번들(bundle) 또는 모음은 전체적으로 사이드 채널(301)로서 지칭될 수 있다. 따라서 앨리스 및 밥이 사이드 채널(301)을 통해 특정 정보 조각들 또는 데이터 등을 교환한다고 하면, 이는 이러한 모든 데이터 조각들이 정확히 동일한 링크 또는 심지어 동일한 유형의 네트워크를 통해 전송되어야 한다는 것을 반드시 의미하는 것은 아니란 것에 주의한다.

클라이언트 소프트웨어

도 3a는 현재 개시된 방식의 실시예들을 구현하기 위한 클라이언트 애플리케이션(105)의 예시적인 구현을 예시한다. 클라이언트 애플리케이션(105)은 트랜잭션 엔진(351) 및 사용자 인터페이스(UI) 계층(352)을 포함한다. 트랜잭션 엔진(351)은 클라이언트(105)의 기본 트랜잭션 관련 기능성을 구현하고, 이를테면, 트랜잭션(152)을 공식화하고, 사이드 채널(301)을 통해 트랜잭션들 및/또는 다른 데이터를 수신 및/또는 송신하고, 그리고/또는

위에서 논의되고 곧 더 자세히 논의되는 방식들에 따라 블록체인 네트워크(106)를 통해 전파될 하나 이상의 노드들(104)에 트랜잭션을 전송하도록 구성된다. 본원에서 개시된 실시예들에 따르면, 각각의 클라이언트(105)의 트랜잭션 엔진(351)은 기능(353...)을 포함한다.

UI 계층(352)은 장비(102)의 사용자 출력 수단을 통해 개개의 사용자(103)에게 정보를 출력하고, 장비(102)의 사용자 입력 수단을 통해 개개의 사용자(103)로부터 다시 입력들을 수신하는 것을 포함하여, 개개의 사용자의 컴퓨터 장비(102)의 사용자 입력/출력(I/O) 수단을 통해 사용자 인터페이스를 렌더링하도록 구성된다. 예컨대, 사용자 출력 수단은 시각적 출력을 제공하기 위한 하나 이상의 디스플레이 스크린들(터치 또는 비-터치 스크린), 오디오 출력을 제공하기 위한 하나 이상의 스피커들 및/또는 촉각 출력을 제공하기 위한 하나 이상의 햅틱 출력 디바이스들 등을 포함할 수 있다. 사용자 입력 수단은 예컨대, 하나 이상의 터치 스크린들(출력 수단에 사용되는 것과 동일하거나 상이한 것)의 입력 어레이; 마우스, 트랙패드 또는 트랙볼과 같은 하나 이상의 커서 기반 디바이스들; 스피치 또는 음성 입력을 수신하기 위한 하나 이상의 마이크로폰들 및 스피치 또는 음성 인식 알고리즘들; 수동 또는 신체 제스처들의 형태의 입력을 수신하기 위한 하나 이상의 제스처 기반 입력 디바이스들; 또는 하나 이상의 기계식 버튼들, 스위치들 또는 조이스틱들 등을 포함할 수 있다.

참고: 본원에서 다양한 기능성이 동일한 클라이언트 애플리케이션(105)에 통합되는 것으로 설명될 수 있지만, 이는 반드시 제한적인 것은 아니며 대신에 둘 이상의 개별 애플리케이션들의 모음으로 구현될 수 있는데, 예컨대, 하나는 API(application programming interface)를 통한 인터페이싱하거나 남은 하나에 대한 플러그-인이다. 예컨대, 트랜잭션 엔진(351)의 기능성은 UI 계층(352)과는 별개의 애플리케이션에서 구현될 수 있거나, 트랜잭션 엔진(351)과 같은 주어진 모듈의 기능성은 하나 초과의 애플리케이션 사이에서 분할될 수 있다. 설명된 기능성 중 일부 또는 전부가 말하자면, 운영 체제 계층에서 구현될 수 있다는 것도 배제되지 않는다. 본원 어디에서든 단일 또는 주어진 애플리케이션(105) 등에 대한 참조가 이루어진 경우, 이는 단지 예일 뿐이며 보다 일반적으로, 설명된 기능성은 임의의 형태의 소프트웨어로 구현될 수 있다는 것이 인지될 것이다.

도 3b는 앨리스의 장비(102a) 상의 클라이언트 애플리케이션(105a)의 UI 계층(352)에 의해 렌더링될 수 있는 사용자 인터페이스(UI)(360)의 예의 목-업(mock-up)을 제공한다. 유사한 UI가 밥의 장비(102b)의 클라이언트(105b) 또는 임의의 다른 당사자의 것에 의해 렌더링될 수 있다는 것이 인지될 것이다.

예시로서, 도 3b는 앨리스의 관점으로부터의 UI(360)를 도시한다. UI(360)는 사용자 출력 수단을 통해 별개의 UI 요소들로서 렌더링된 하나 이상의 UI 요소들(362, 362, 363)을 포함할 수 있다.

예컨대, UI 요소들은 상이한 온-스크린 버튼들 또는 메뉴 내 상이한 옵션들 등일 수 있는 하나 이상의 사용자 선택 가능 요소들(362)을 포함할 수 있다. 사용자 입력 수단은 사용자(103)(이 경우에 앨리스(103a))가 온-스크린의 UI 요소를 클릭 또는 터치하거나 원하는 옵션의 이름을 말하는 것과 같이 옵션들 중 하나를 선택하거나 다른 방식으로 동작시키는 것을 가능하게 하도록 배열된다(주의: 본원에서 사용된 바와 같은 "수동"이라는 용어는 자동과 대조하기 위한 것일 뿐이며 반드시 손을 사용하는 것으로 제한되지는 않음).

대안적으로 또는 부가적으로, UI 요소들은 하나 이상의 데이터 엔트리 필드들(362)을 포함할 수 있으며, 이를 통해 사용자는 ...를 할 수 있다. 이러한 데이터 엔트리 필드는 같은 사용자 출력 수단 예컨대, 온-스크린을 통해 렌더링되며 데이터는 사용자 입력 수단 예컨대, 키보드 또는 터치스크린을 통해 필드들에 입력될 수 있다. 대안적으로 데이터는 구두로 예컨대, 스피치 인식에 기초하여 수신될 수 있다.

대안적으로 또는 부가적으로, UI 요소들은 사용자에게 정보를 출력하기 위해 출력되는 하나 이상의 정보 요소들(363)을 포함할 수 있다. 예컨대, 이것/이것들은 청각적으로 또는 스크린 상에 렌더링될 수 있다.

다양한 UI 요소들을 렌더링하고, 옵션들을 선택하고, 데이터를 입력하는 특정 수단은 중요하지 않다는 것이 인지될 것이다. 이러한 UI 요소들의 기능성은 곧 자세히 논의될 것이다. 또한, 도 3에 도시된 UI(360)는 도식화된 목-업(mock-up)일 뿐이며 실제로는 간결성을 위해 예시되지 않은 하나 이상의 추가 UI 요소들을 포함할 수 있다는 것이 인지될 것이다.

노드 소프트웨어

도 4는 UTXO-기반 또는 출력-기반 모델의 예에서 네트워크(106)의 각각의 블록체인 노드(104) 상에서 실행되는 노드 소프트웨어(450)의 예를 예시한다. 다른 엔티티는 네트워크(106) 상에서 노드(104)로 분류되지 않고, 즉 노드(104)에 필요한 액션들을 수행하지 않고 노드 소프트웨어(450)를 실행할 수 있다는 것에 주의한다. 노드 소프트웨어(450)는 프로토콜 엔진(451), 스크립트 엔진(452), 스택(453), 애플리케이션-레벨 판단 엔진(454), 및 일 세트의 하나 이상의 블록체인-관련 기능 모듈들(455)을 포함한다(그러나 이에 제한되지 않음). 각각의 노드(104)는 합의 모듈(455C)(예컨대, 작업 증명), 전파 모듈(455P) 및 저장 모듈(455S)(예컨대, 데이터베이스) 3개 모두를 포함하는(그러나 이에 제한되지 않음) 노드 소프트웨어를 실행할 수 있다. 프로토콜 엔진(351)은 통상적으로 트랜잭션(152)의 상이한 필드들을 인식하고 이들을 노드 프로토콜에 따라 프로세싱하도록 구성된다. 다른 선행 트랜잭션(152i)(Tx_{m - 1})의 출력(예컨대, UTXO)을 가리키는 입력을 갖는 트랜잭션(152j)(Tx_j)이 수신될 때, 프로토콜 엔진(451)은 Tx_j의 잠금해제 스크립트를 식별하고 이를 스크립트 엔진(452)에 전달한다. 프로토콜 엔진(451)은 또한 Tx_j의 입력의 포인터에 기초하여 Tx_i를 식별 및 리트리브(retrieve)한다. Tx_i는 블록체인(150) 상에 공개될 수 있으며, 이 경우, 프로토콜 엔진은 노드(104)에 저장된 블록체인(150)의 블록(151)의 사본으로부터 Tx_i를 리트리브할 수 있다. 대안적으로, Tx_i는 아직 블록체인(150) 상에 공개되지 않았을 수 있다. 그 경우에, 프로토콜 엔진(451)은 노드(104)에 의해 유지되는 공개되지 않은 트랜잭션의 순서화된 세트(154)로부터 Tx_i를 리트리브할 수 있다. 어느 쪽이든, 스크립트 엔진(451)은 Tx_i의 참조된 출력에서 잠금 스크립트를 식별하고 이를 스크립트 엔진(452)으로 전달한다.

따라서, 스크립트 엔진(452)은 Tx_i의 잠금 스크립트 및 Tx_j의 대응하는 입력으로부터의 잠금해제 스크립트를 갖는다. 예컨대, Tx₀ 및 Tx₁로 라벨링된 트랜잭션들이 도 2에 예시되지만, 임의의 트랜잭션 쌍들에 동일하게 적용될 수 있다. 스크립트 엔진(452)은 이전에 논의된 바와 같이 2개의 스크립트들을 함께 실행하며, 이는 사용되고 있는 스택-기반 스크립팅 언어(예컨대, Script)에 따라 스택(453) 상에 데이터를 배치하고 스택(403)으로부터 데이터를 리트리브하는 것을 포함할 것이다.

스크립트들을 함께 실행함으로써, 스크립트 엔진(452)은 잠금해제 스크립트가 잠금 스크립트에 정의된 하나 이상의 기준들을 충족시키는지 여부 ― 즉, 잠금 스크립트가 포함되는 출력을 "잠금해제"하는가? 를 결정한다. 스크립트 엔진(452)은 이 결정의 결과를 프로토콜 엔진(451)에 리턴한다. 잠금해제 스크립트가 대응하는 잠금 스크립트에 지정된 하나 이상의 기준들을 충족시키는 것으로 스크립트 엔진(452)이 결정하는 경우, 결과 "참"이 리턴된다. 그렇지 않으면, 결과 "거짓"이 리턴된다.

출력-기반 모델에서, 스크립트 엔진(452)으로부터의 결과 "참"은 트랜잭션의 유효함을 위한 조건들 중 하나이다. 통상적으로 또한 충족되어야 하는, 프로토콜 엔진(451)에 의해 평가되는 하나 이상의 추가의 프로토콜-레벨 조건들; 이를테면, Tx_j의 출력(들)에 지정된 디지털 자산의 총 금액이 그의 입력들에 의해 가리켜지는 총 금액을 초과하지 않는 것, 그리고 Tx_i의 가리켜진 출력이 다른 유효한 트랜잭션에 의해 이미 지출되지 않았을 것이 존재한다. 프로토콜 엔진(451)은 하나 이상의 프로토콜-레벨 조건들과 함께 스크립트 엔진(452)으로부터의 결과를 평가하고, 이들이 모두 참인 경우에만, 트랜잭션 Tx_j를 유효성 검증한다. 프로토콜 엔진(451)은 트랜잭션이 유효한지에 관한 표시를 애플리케이션-레벨 판단 엔진(454)에 출력한다. Tx_j가 실제로 유효성 검증된다는 조건에서만, 판단 엔진(454)은 Tx_j에 대해 각자의 블록체인-관련 기능을 수행하도록 합의 모듈(455C) 및 전파 모듈(455P) 둘 모두를 제어하기로 선택할 수 있다. 이는, 블록(151)에 통합하기 위해 노드의 트랜잭션들(154)의 개개의 순서화된 세트(154)에 Tx_j를 추가하는 합의 모듈(455C) 및 네트워크(106) 내 다른 블록체인 노드(104)에 Tx_j를 포워딩하는 전파 모듈(455P)을 포함한다. 선택적으로, 실시예들에서, 애플리케이션-레벨 판단 엔진(454)은 이들 기능들 중 어느 하나 또는 둘 모두를 트리거하기 전에 하나 이상의 부가적인 조건들을 적용할 수 있다. 예컨대, 판단 엔진은 트랜잭션이 유효하고 트랜잭션 수수료가 충분히 남아 있다는 것을 조건으로만 트랜잭션을 공개하기로 선택할 수 있다.

또한, 본원에서 "참" 및 "거짓"이라는 용어들은 단지 단일 이진 숫자(비트)의 형태로 표현되는 결과를 리턴하는 것으로 반드시 제한되지는 않지만, 이는 확실히 하나의 가능한 구현이라는 것에 주의한다. 보다 일반적으로, "참"은 성공 또는 긍정적인 결과를 표시하는 임의의 상태를 지칭할 수 있고 "거짓"은 실패 또는 비-긍정적인 결과를 표시하는 임의의 상태를 지칭할 수 있다. 예컨대, 계정-기반 모델에서, "참"의 결과는 서명의 암시적인 프로토콜 레벨의 유효성 검증 및 스마트 계약의 부가적인 긍정적인 출력의 조합에 의해 표시될 수 있다(개별 결과들 둘 모두가 참인 경우, 전체 결과가 참을 시그널링하는 것으로 간주됨).

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

예컨대, 위의 일부 실시예들은 비트코인 네트워크(106), 비트코인 블록체인(150) 및 비트코인 노드(104) 관점에서 설명되었다. 그러나 비트코인 블록체인은 블록체인(150)의 하나의 특정 예이며 위의 설명은 모든 블록체인에 일반적으로 적용될 수 있다는 것이 인지될 것이다. 즉, 본 발명은 결코 비트코인 블록체인으로 제한되지 않는다. 보다 일반적으로, 비트코인 네트워크(106), 비트코인 블록체인(150) 및 비트코인 노드(104)에 대한 위의 임의의 참조는 각각 블록체인 네트워크(106), 블록체인(150) 및 블록체인 노드(104)에 대한 참조로 대체될 수 있다. 블록체인, 블록체인 네트워크 및/또는 블록체인 노드는 위에서 설명된 바와 같이 비트코인 블록체인(150), 비트코인 네트워크(106) 및 비트코인 노드(104)의 설명된 성질들 중 일부 또는 전부를 공유할 수 있다.

본 발명의 바람직한 실시예들에서, 블록체인 네트워크(106)는 비트코인 네트워크이고 비트코인 노드들(104)은 블록체인(150)의 블록들(151)을 생성, 공개, 전파 및 저장하는 설명된 기능들 모두를 적어도 수행한다. 이러한 기능들의 전부는 아니지만 하나 또는 일부만을 수행하는 다른 네트워크 엔티티들(또는 네트워크 요소들)이 있을 수 있음을 배제되지 않는다. 즉, 네트워크 엔티티는 블록들을 생성 및 공개하지 않고 블록들을 전파 및/또는 저장하는 기능을 수행할 수 있다(이러한 엔티티들은 바람직한 비트코인 네트워크(106)의 노드들로 간주되지 않음을 상기한다).

본 발명의 비-바람직한 실시예들에서, 블록체인 네트워크(106)는 비트코인 네트워크가 아닐 수 있다. 이러한 실시예들에서, 노드가 블록체인(150)의 블록들(151)을 생성, 발행, 전파 및 저장하는 기능들 전부는 아니지만 적어도 하나 또는 일부를 수행할 수 있다는 것이 배제되지 않는다. 예컨대, 이러한 다른 블록체인 네트워크들에서, "노드"는 블록들(151)을 생성 및 공개하지만 해당 블록들(151)을 저장하고 그리고/또는 다른 노드에 전파하진 않도록 구성된 네트워크 엔티티를 지칭하는 데 사용될 수 있다.

보다 더 일반적으로, 위의 "비트코인 노드"(104)라는 용어에 대한 임의의 참조는 "네트워크 엔티티" 또는 "네트워크 요소"라는 용어로 대체될 수 있으며, 이러한 엔티티/요소는 블록들을 생성, 공개, 전파 및 저장하는 역할들의 일부 또는 전부를 수행하도록 구성된다. 이러한 네트워크 엔티티/요소의 기능들은 블록체인 노드(104)를 참조하여 위에서 설명된 동일 방식으로 하드웨어로 구현될 수 있다.

위임된 인가

도 5는 바람직하게는, 블록체인(101)과 연관된 복수의 서비스들을 제공하는 플랫폼 프로세서(504)의 일부로서 위임된 인가 토큰의 제공 및 사용을 위한 본 개시내용의 제1 양상에 따른 시스템(500)에 관한 것이다. 플랫폼 프로세서(504)는 선택적으로 도 11 및 도 13과 관련하여 아래에서 더 자세히 설명되는 바와 같은 플랫폼이다. 그러나 본원에서 설명된 바와 같은 위임된 인가 방법들 및 시스템들은 블록체인(101)과 연관되지 않은 서비스들을 포함하는 다른 서비스들에서 사용될 수 있다는 것이 당업자에 의해 인지될 것이다. 플랫폼 프로세서(504)는 블록체인(101), 클라이언트(502) 및/또는 위임된 사용자(506)와 통신 및/또는 상호작용하도록 구성된다. 플랫폼 프로세서(504)는 예시를 쉽게 하기 위해 본원에서 모놀리식 서버로서 설명된다. "클라이언트", "사용자" 또는 유사한 용어들이 사용되는 경우, 이는 종종 상기 클라이언트 또는 사용자에 의해 소유되는 디바이스를 지칭하는 것으로 이해될 것이다. 당업자는 이것이 단일 서버, 메인프레임, 서버들의 모음, 마이크로서비스, 마이크로서비스들의 모음, 클라우드 서비스, 선행 및/또는 다른 컴퓨팅 플랫폼 또는 플랫폼들의 임의의 조합으로서 구현될 수 있다는 것을 인지할 것이다. 본원에서 사용된 바와 같은 "서비스" 또는 "서비스들"이라는 용어들은 엄밀히, 하나의 서버 상에서 실행되는 하나의 단일 애플리케이션에 특유한 것이 아니라, 컴퓨팅 기능들 또는 거동들의 모음에 대한 일반적인 용어로 이해되어야 한다. 여기서 예들 및 옵션들의 비-총망라하는 목록이 제시된다. 서비스는 하나의 애플리케이션 또는 다수의 애플리케이션들일 수 있다. 서비스는 하나, 또는 다수의 하드웨어 서버/디바이스 상에서 실행될 수 있다. 예컨대, 아래에는 서비스와 별개로 데이터베이스가 제공되며, 이는 대신 동일한 서비스의 일부로 동등하게 포함될 수 있다.

시스템(500)은 플랫폼(504) 상의 서비스에 대한 인가를 가진 사용자인 클라이언트(502)를 포함한다. 클라이언트의 인가는 클라이언트(502)가 다른 사용자들(506)(본원에서 이후에, 위임된 사용자들 또는 위임자들이라 칭함)에게 위임된 인가를 제공하도록 허용한다. 클라이언트(502)는 서비스의 "소유자"로 간주되고 바람직하게는, 플랫폼(504) 상에서 서비스의 생성을 트리거할 수 있다. 클라이언트(502)는 다른 사용자들이 서비스에 대한 액세르를 갖도록 하는 인가를 위임하기를 원한다. 바람직하게는, 위임된 인가는 위임된 사용자들(506)이 서비스를 실행 중인 플랫폼(504)과 상호작용(512)하는 허가(permission)를 제공한다. 보다 바람직하게는, 상호작용들은 서비스를 판독하거나, 기록하거나, 또는 판독 및 기록 둘 다를 하기 위한 것이다. 훨씬 더 바람직하게는, 설명된 서비스는 도 10a-c, 도 11 및 도 12를 참조하여 아래에서 더 자세히 설명되는 이벤트 스트림이다. 당업자는, 여기에서 서비스의 위임된 인가와 연관된 방법들 및 시스템들이 다른 서비스들과 함께 사용될 수 있다는 것을 이해할 것이다.

선택적으로 위임된 사용자들이 가질 수 있는 서비스와의 다른 상호작용들이 있다. 허용되는 상호작용들의 유형들은 서비스에 의존할 것이다. 예컨대, 서비스가 금융 트랜잭션들을 제공하는 경우, 위임된 사용자는 트랜잭션들을 생성하거나 서명할 위임된 인가를 가질 수 있다. 바람직하게는 위임된 인가는 더 많은 위임된 사용자들을 추가하거나 위임된 인가 토큰들을 생성하는 허가를 부여하지 않는다.

도 6 및 도 7을 참조하여 아래에 더 자세히 설명되는 바와 같이, 본 양상의 실시예에 따르면, 클라이언트(502)는 위임된 인가 토큰들을 생성하고 이를 위임된 사용자들(506)에게 제공한다(508).

도 8 및 도 9a-c를 참조하여 아래에 더 자세히 설명되는 바와 같이, 본 양상의 실시예에 따르면, 위임된 사용자들(506)은 이러한 토큰들을 포함하는 요청들을 생성하도록 구성되며, 요청들은 플랫폼(504) 상에서 실행 중인 서비스로 전송된다(512). 요청의 수신 시에, 서비스는 요청을 유효성 검증하고 위임된 인가 토큰의 유효성에 의존하여, 요청을 프로세싱할 것이다.

위임된 인가 토큰 생성

도 6은 제1 양상의 실시예에 따른 방법(600)을 도시한다. 방법(600)은 위임된 인가 토큰들(본원에서 DelegedAuth 토큰들로서 또한 설명됨)의 생성을 설명하고 클라이언트(502)가 위임된 서비스와 상호작용하도록 하나 초과의 위임된 사용자를 인가하기를 원할 때 사용된다. 바람직하게는, 이 방법은 시스템(500) 내 임의의 다른 엔티티들과의 상호작용 없이 완전히 클라이언트에 의해 수행된다. 선택적으로, 위임된 인가 토큰들은 위임된 인가 토큰과 함께 제공될 수 있는 연관된 인덱스를 갖는다.

위임된 인가 토큰들은 이들이 관련된 토큰들의 세트를 형성하도록 생성된다. 바람직하게는, 아래 설명된 바와 같이 각각의 위임된 인가 토큰(최초 토큰은 제외함)은 체인 내 선행 토큰에 기초하기 때문에, 세트는 토큰들의 "체인"이다.

먼저, 2개의 랜덤 수들: 초기 값(아래 IV로서 참조됨) 및 시드 값(아래 시드로서 참조됨)이 생성된다(602).

선택적으로, 필요한 위임된 인가 토큰들의 수가 결정된다(604). 이 수는 일반적으로 클라이언트가 위임된 인가를 제공하기를 원하는 사용자들의 수와 동일하다(또는 때로는 더 큼).

그 후, 이들 두 값들에 기초하여 최초 위임된 인가 토큰이 생성된다(606). 바람직하게는, 최초 위임된 인가 토큰은 초기 값 및 시드 값의 컨케터네이션에 기초한다. 더욱 바람직하게는, 최초 위임된 인가 토큰은 입력들로서 초기 값 및 시드 값을 사용하는 단방향 함수에 기초한다. 훨씬 더 바람직하게는, 최초 위임된 인가 토큰은 초기 값 및 시드 값의 컨케터네이션의 해시에 기초한다.

선택적으로 시드 값은 어떤 엔티티도 그것을 재차 사용할 수 없도록 안전하게 삭제된다.

추가 위임된 인가 토큰들이 생성된다(608). 생성된 각각의 위임된 인가 토큰은 적어도 이전에 생성된 위임된 인가 토큰에 기초한다. 바람직하게는, 각각의 추가 위임된 인가 토큰은 초기 값 및 이전에 생성된 위임된 인가 토큰에 기초하여 생성된다. 이전에 생성된 인가 토큰은 바람직하게는, 현재 생성 중인 것 직전에 생성된 위임된 인가 토큰을 지칭하며, 선행 위임된 인가 토큰으로서 또한 설명될 수 있다. 더 바람직하게는, 각각의 추가 위임된 인가 토큰은 초기 값과 이전에 생성된 위임된 인가 토큰의 조합에 기초하여 생성된다. 훨씬 더 바람직하게는, 각각의 추가 위임된 인가 토큰은 입력으로서 초기 값 및 이전에 생성된 위임된 인가 토큰의 조합을 취하는 단방향 함수에 기초하여 생성된다. 여전히 보다 더 바람직하게는, 각각의 추가 위임된 인가 토큰은 초기 값과 이전에 생성된 위임된 인가 토큰의 조합의 해시에 기초하여 생성된다. 더욱 훨씬 더 바람직하게는, 조합은 이전에 생성된 인가 토큰 상의 초기 값의 컨케터네이션이다.

초기 값과 이전에 생성된 위임된 인가 토큰의 조합은 프리이미지로서 설명될 수 있다.

이전에 위임된 인가 토큰에 초기 값을 프리펜딩(pre-pending)하는 것(위의 컨케터네이션)에 대한 대안은 초기 값을 전혀 사용하지 않고 따라서 이전에 위임된 인가 토큰은 생성된 이전에 위임된 인가 토큰에만 기초한다. 이런 방식으로 다음 위임된 인가 토큰을 생성하기 위해, 이전에 위임된 인가 토큰에 대해 단방향 함수가 사용되며 상기 함수의 출력은 다음 위임된 인가 토큰이다. 바람직하게는, 단방향 함수는 해싱 함수이다.

위임된 인가 토큰은 바람직하게는 이진 스트링 및/또는 바이트 스트링의 형태이다. 이진 스트링의 길이는 사용되는 단방향 함수에 의존한다. 사용되는 단방향 함수가 SHA256인 경우, 위임된 인가 토큰들은 길이가 256비트(또는 32바이트)일 것이다. 선택적으로, 이 이진 스트링은 16진수 스트링, base64 스트링 또는 임의의 다른 적절한 인코딩 체계로서 표현 및/또는 인코딩될 수 있다.

이 생성 단계(608)는 토큰을 생성하는 클라이언트(502)가 충분한 토큰들을 가지고 있다고 결정할 때 및/또는 생성된 토큰들의 수가 단계(604)에서 결정된 수 이상일 때 중지된다.

바람직하게는, 위에서 설명된 방법(600)은 위임된 사용자들과 서비스 간의 상호작용의 각각의 유형을 생성하는 데 사용된다. 바람직하게는, 위임된 인가 토큰들의 일 체인은 서비스에 대한 판독 액세스를 위해 생성되고, 위임된 인가 토큰의 다른 체인은 서비스에 대한 기록 액세스를 위해 생성된다. 클라이언트가 판독 인가를 제공하기를 원하는 각각의 사용자는 판독 위임된 인가 토큰들 중 하나를 수신하고, 클라이언트가 기록 인가를 제공하기를 원하는 각각의 사용자는 기록 위임된 인가 토큰들 중 하나를 수신한다. 판독 및 기록 위임된 인가 토큰들의 수가 동일할 필요는 없다.

선택적으로, 위임된 사용자는 하나 초과의 토큰을 수신할 수 있다. 이는 여기에 논의된 기록과 같은 상호작용이 제한된 예의 경우, 위임된 사용자에게 더 많은 기록들을 허용할 것이다.

위임자 토큰들의 체인을 생성하는 것(606, 608)과 관련된 단계들이 또한 아래 표에 도시될 수 있다. 이 표에서 'R'은 '판독' 인가와 관련된 토큰들 및 데이터를 표현하는 데 사용되며, 'W'는 '기록' 인가와 관련된 토큰들 및 데이터를 표현하는 데 사용된다. 'H' 함수는 단방향 함수이며 바람직하게는 해시 함수이고, '||' 기호는 바람직하게는 상기 기호의 각각의 옆의 컨케터네이션을 표현한다. 각각의 4개의 토큰들이 단지 예시로만 생성된다. 각각의 유형의 토큰에 대한 상이한 수들이 사용될 수 있다.

위 표에서 볼 수 있듯이, 위임된 인가 토큰들의 체인 내 최종 위임된 인가 토큰은 H0 해시이다.

바람직하게는, 기록 위임된 인가 토큰의 경우, 토큰당 최대 기록들이 또한 존재한다. 이는 선택적으로 각각의 토큰이 수행할 수 있는 상호작용들의 수를 클라이언트가 제한하기를 원하는 다른 상호작용들로 확장된다.

위에 설명된 방법(600)의 예가 도 10d를 참조하여 설명된다. 클라이언트가 랜덤 초기 값(IV) 및 시드를 취하여, 위임된 인가 토큰들의 체인을 생성하는 예시적인 시스템(1070)이 도시된다. 다음으로 "생성" 이벤트 스트림 메시지가 이벤트 스트림 서비스로 전송되고, 이벤트 스트림 생성 메시지는 최종 위임된 인가 토큰(H0) 및 초기 값을 포함한다. 이벤트 스트림 서비스는 이벤트 스트림을 생성하고, 최종 토큰 및 초기 값을 생성된 스트림과 연관시키고, 생성 메시지에 "이벤트 스트림 식별자"인 "esid"로 응답한다. esid는 클라이언트 및/또는 임의의 위임된 사용자들에 의한 임의의 향후 상호작용들을 위해 사용된다.

생성 요청은 바람직하게는 JSON 오브젝트이고, 다음을 포함한다:

추가 실시예에 따르면, 사용자에게 위임된 인가를 제공하기 위해 요구된 정보를 분배하는 방법(700)이 도 7에 도시된다.

선택적으로 도 6에 기술된 실시예에 의해 위임된 인가 토큰이 생성되는 경우(702), 클라이언트는 각각의 위임된 사용자에게 토큰들을 제공하고(704), 임의의 위임된 토큰들의 유효성을 결정하기 위해 플랫폼 또는 서비스에 대해 요구되는 임의의 데이터를 제공한다(706). 바람직하게는, 토큰들의 유효성을 결정하기 위해 플랫폼 또는 서비스에 대해 요구되는 데이터는 위임된 인가 토큰들의 체인(위의 예에서 볼 수 있는 바와 같은 WH0 및/또는 RH0) 내 마지막 위임된 인가 토큰 및 초기 값들(위의 예들에서 볼 수 있는 바와 같은 WIV 및/또는 RIV)을 포함한다.

위임된 인가 토큰들은 본질적으로 이들에 대한 순서성을 가지며, 이에 따라 인덱싱될 수 있다. 바람직하게는, 각각의 위임된 사용자에게 자신의 토큰을 제공(704)할 때 토큰의 인덱스가 또한 제공된다.

위임된 사용자들 및 플랫폼에 데이터를 제공하는 것과 관련된 단계들(704, 706)은 순차적으로 제시되지만, 임의의 순서로 또는 동시에 수행될 수 있다.

토큰들의 각각의 체인이 상호작용(예컨대, 판독 또는 기록)별로 생성되므로, 방법(700)은 클라이언트가 위임하고자 하는 상호작용의 각각의 유형에 대해 수행된다.

위임자들에게는 서비스가 셋업되기 전에 그의 위임된 인가 토큰들이 제공될 수도 있고, 서비스가 실행되면 요청 시 제공될 수 있다.

클라이언트(502)는 언제든지, 이러한 토큰들 중 임의의 수 또는 전부를 취소할 수 있다. 이는 토큰들을 취소하려고 하는 서비스(아래 제공된 예에서 이는 특정 이벤트 스트림의 식별을 의미함), 토큰이 취소될 상호작용들의 유형(예컨대, 판독 또는 기록), 취소될 토큰들 및/또는 취소될 토큰의 인덱스를 표시하는 데이터를 포함하는 요청을 클라이언트가 생성함으로써 수행된다. 바람직하게는 취소될 토큰들 및 인덱스 둘 모두가 사용되고, 선택적으로 하나만이 사용된다. 바람직하게는, 모든 토큰들은 인에이블/취소되지 않은 상태로 시작하고 클라이언트(502)는 이를 최소해야 한다. 취소의 구체적인 예들이 도 10c 및 도 10e에 제공된다.

개별 토큰들을 취소할 수 있게 된다는 것은 서비스에 대한 클라이언트의 액세스 관리에 있어 클라이언트(502)에게 더 뛰어난 유연성 및 제어를 허용한다. 또한, 위임된 사용자(506)가 다른 토큰들을 모르고 이들을 계산할 수 없기 때문에, 클라이언트가 액세스를 취소하려고 할 때, 여전히 인에이블된/취소되지 않은 임의의 다른 위임된 사용자들을 알리거나 업데이트할 필요가 없고 그리하여 컴퓨팅 자원들 및 시간을 절약한다.

위임된 인가 토큰 사용

도 8을 참조하면, 서비스와 상호작용하기 위한 요청을 수신하고(804), 유효성 검증하고(806), 프로세싱하는(808) 프로세스를 설명하는 추가 실시예에 따른 방법(800)이 도시된다. 본 실시예에서 그리고 설명의 편의를 위해, 이 방법(800)이 플랫폼 상에서 실행되는 서비스에 의해 수행되는 것으로 설명된다. 대안적인 실시예들에서, 플랫폼은 여기서 방법(800)을 수행하도록 구성된 추가 프로세스를 실행하고 있다. 이 프로세스는 "인증 서비스" 또는 "액세스 제어 서비스"로서 설명될 수 있으며 선택적으로 상호작용되고 있는 서비스와 동일한 플랫폼(504) 상에서 실행된다. 추가 대안으로서, 인증 서비스는 서비스가 요청을 수신하기 전에 필터로서 거동한다.

위임된 사용자로부터 요청을 수신하는 단계에 앞서, 서비스는 위임된 인가 토큰들을 생성한 클라이언트로부터 적절한 유효성 검증 데이터를 수신한다(802). 유효성 검증 데이터는 적어도, 위임된 인가 토큰들의 체인의 최종 해시(또는 최종 위임된 인가 토큰)를 포함한다. 또한, 이 최종 토큰은 최종 위임된 인가 토큰이 클라이언트로부터 올 때 최종 위임된 인가 토큰을 클라이언트가 수신한 것으로 설명된다. 이 최종 해시는 본원에서 사용된 바와 같이 H0, R_H0 또는 W_H0로서 표현될 수 있다. 바람직하게는, 유효성 검증 데이터는 또한 도 6을 참조하여 위에서 설명된 바와 같이 위임된 인가 토큰들의 체인을 생성하는 프로세스에서 사용되는 초기 값을 포함한다.

서비스는 위임된 사용자들로부터의 요청들을 유효성 검증하기 전에 임의의 지점에서 이 데이터를 수신할 수 있다(802). 바람직하게는 새로운 이벤트 스트림이 생성될 때 유효성 검증 정보가 서비스에 제공된다.

일정 시간 후, 서비스는 위임된 사용자들로부터 서비스 및/또는 이벤트 스트림을 사용하라는 요청들을 수신할 것이다(804). 이러한 요청들은 위임된 인가 토큰을 포함한다. 요청이 위임된 인가 토큰을 포함하지 않거나 클라이언트에서 온 것이 아닌 경우, 요청은 유효한 것으로 간주되지 않는다. 클라이언트로부터의 요청들은 바람직하게는, 위임된 인가 토큰들을 요구하지 않고 상이한 시스템을 사용하여 유효성 검증되거나 인증될 것이다.

서비스는 위임된 인가 토큰 및 유효성 검증 데이터에 기초하여 요청의 유효성을 결정한다(806). 이 단계는 도 9a 내지 도 9d와 관련하여 더 자세히 설명된다. 유효성 검증은 때로는 수신된 위임된 인가 토큰부터 시작하여 최종 위임된 인가 토큰까지 위임된 인가 토큰들의 체인의 서브세트를 재생성하는 것을 포함한다. 재생성된 최종 위임된 인가 토큰이 클라이언트가 수신한 최종 위임된 인가 토큰과 동일한 경우, 수신된 위임된 인가 토큰은 유효하다.

선택적으로 서비스는 위임된 인가 토큰이 취소되었는지 여부에 기초하여 요청의 유효성을 추가로 결정한다. 이 서비스 및 상호작용에 대한 토큰 및/또는 인덱스가 취소된 경우, 요청은 유효하지 않은 것으로 밝혀질 것이다.

마지막으로, 단계(806)에서 결정된 유효성에 의존하여, 요청이 프로세싱된다. 토큰이 유효하지 않는 경우, 요청이 프로세싱되지 않는다.

방법(800)이 인증 서비스에 의해 실행되는 경우, 프로세싱 단계(806)는 인증 서비스가 유효성 검증의 결과에 대한 표시를 서비스 및/또는 플랫폼에 제공하는 것을 포함한다. 대안적으로, 인증 서비스가 필터로서 작용하는 경우, 프로세싱 단계(806)는 요청을 삭제하는 것을 포함하고, 토큰이 유효하지 않은 경우 요청을 서비스에 포워딩하지 않는다. 토큰이 유효한 경우, 선택적으로, 요청이 유효하다는 것을 표시하는 부가적인 정보와 함께 서비스에 대한 요청이 전달될 것이다.

도 9a-d에 도시된 방법은 서비스가 수신된 위임된 인가 토큰들을 유효성 검증할 수 있는 방법에 대한 상이한 예시적인 상황들을 설명한다. 제1 방법(900)은 제1 요청이 수신되는 경우를 도시한다. 수신된 위임된 인가 토큰부터 시작하여 위임된 인가 토큰들의 체인이 재생성된다. 제2 방법은 추가 요청이 수신되었지만 인덱스가 임의의 이전에 수신된 위임된 인가 토큰들보다 체인에서 더 높고 서비스가 이를 계산하지 않은 경우를 도시한다. 제3 방법은 다른 추가 요청이 수신되고 인덱스가 체인 내 뒷부분에 있고 서비스에서 이를 이미 계산한 경우를 도시한다.

체인을 참조하여 "더 높은" 및 "더 낮은"이 사용된 경우, 이는 공급된 인덱스를 지칭한다. "더 높은"이라 함은 더 높은 인덱스 번호를 가지며 최종 위임된 인가 토큰으로부터 더 멀리 떨어져 있는 것과 관련되고, "더 낮은"이라 함은 그 반대이다. 0의 인덱스는 가장 낮은 인덱스이며 체인 내 최종/마지막 생성된 위임된 인가 토큰을 인덱싱한다. 인덱스 0을 갖는 위임된 인가 토큰은 위에서 논의된 바와 같이 검증 목적으로 클라이언트에 의해 제공되는 토큰이다.

바람직하게는, 유효성 검증 방법은 클라이언트가 위임된 인가 토큰들의 체인을 구성하는 데 사용하는 것과 동일한 방법을 사용한다. 제1, 제2 및 제3 예시적인 상황 방법들(900, 920, 940)은 해시 체인(또는 그 서브세트)이 생성된 것과 실질적으로 동일한 방법을 사용하여 재구성되는 것을 보여준다.

도 9a는 제1 유효성 검증 방법(900)을 도시하며, 여기서 토큰이 처음으로 서비스에 의해 수신된다(902). 제1 요청은 최초 수신된 위임된 인가 토큰을 포함한다. 바람직하게는, 요청은 또한 인덱스를 포함한다.

이는 최초 수신된 위임된 인가 토큰이므로, 서비스는 위임된 인가 토큰들의 체인의 어떠한 다른 부분도 생성하지 않을 것이다.

다음으로, 최초 수신된 위임된 인가 토큰부터 시작하여, 위임된 인가 토큰들의 체인이 재생성된다. 체인은 위에서 설명된 바와 같이 체인이 생성되었던 방법과 동일한 방법을 사용하여 생성된다. 따라서, 체인은 바람직하게는 초기 값을 최초 수신된 위임된 인가 토큰과 컨케터네이팅하고 그 후 이를 해싱하여 체인 내 다음 위임된 인가 토큰을 수신함으로써 생성된다. 이 단계는 여러 번 반복된다. 인덱스가 요청에 존재하는 경우, 생성된 체인 내 위임된 인가 토큰들의 수는 인덱스에 기초한다. 인덱스는 위임된 인가 토큰들의 체인에서 최종 위임된 인가 토큰으로부터의 거리로 볼 수 있다. 최종 위임된 인가 토큰 H0'이 생성될 때까지 추가 위임된 인가 토큰들이 생성된다. 예컨대, 요청 내 인덱스가 3인 경우, 아래에 도시된 바와 같이 3개의 해시들(H2', H1', H0')이 더 생성될 것이다. ' 기호는 이것이 수신된 위임된 인가 토큰에 기초한 체인이며 클라이언트 생성 체인과 동일하지 않을 수 있음을 나타내는 데 사용된다. 여기서 'R' 및 'W'는 판독('R'), 기록('W') 또는 임의의 다른 상호작용에 대해 프로세스가 동일하기 때문에 여기서 사용되지 않았다.

H0'를 구하는 것은 또한 단일 방정식에 의해 수행될 수 있다.

바람직하게는, 체인 내 수신된 위임된 인가 토큰(H3') 및 중간 해시들(H2' 및 H1')(이는 또한 위임된 인가 토큰이고 향후 위임자에 의해 사용될 수 있음) 각각은 토큰이 유효한 것으로 밝혀진 경우 향후 사용을 위해 저장된다. 이러한 중간 토큰들의 사용은 아래에 도 9c에 도시된 예시적인 방법(940)과 관련하여 추가로 설명된다. 훨씬 더 바람직하게는, 수신 및 생성된 위임된 인가 토큰들은 이들이 체인 내 그의 포지션에 따라 인덱싱될 수 있도록 데이터 저장 메커니즘(이를테면, 어레이, 데이터베이스, 하드 드라이브 또는 임의의 다른 유사한 시스템 또는 모듈)에 저장된다. 유리하게는, 위임된 인가 토큰들을 그의 인덱스와 연관시키는 것(또한 인덱싱이라 칭함)은 도 9c를 참조하여 설명된 상황에서와 같이 더 쉬운 룩업을 허용한다. 토큰이 유효하지 않은 것으로 밝혀지는 경우, 구성된 전체 체인이 저장 및/또는 삭제되지 않는다.

최초 수신된 토큰의 유효성은 위에서 설명한 유효성 검증 방법(800)의 초기 단계(802)에서 유효성 검증 데이터의 일부로서 클라이언트로부터 수신된 최종 해시와 생성된 최종 해시(H0')의 비교에 기초하여 결정된다. H0 및 H0'이 동일한 경우, 위임된 인가 토큰은 유효하다.

대안적으로, 인덱스가 사용되지 않는 경우, 위임된 인가 토큰들이 지속적으로 생성되고 각각의 생성된 토큰이 H0와 비교하도록 방법이 수정된다. 비교가 성공적으로 이루어지거나 최대 토큰 수에 도달하는 경우 프로세스가 중지된다. 최대 수에 도달했지만 성공적인 비교가 이루어지지 않는 경우, 최초 수신된 위임된 인가 토큰은 유효하지 않은 것으로 밝혀진다.

도 9b를 참조하면, 방법(920)이 도시되며, 여기서 위임된 인가 토큰 및 인덱스를 또한 포함하는 추가 요청이 수신된다(922). 예시 목적을 위해, 이 예시적인 방법에서, 위임된 인가 토큰 및/또는 인덱스는, 사전에 서비스에 의해 확인되지 않았고 위임된 인가 토큰들의 임의의 미리 계산된 체인에 존재하지 않는다.

수신 시에, 서비스는 위임된 인가 토큰이 이전에 생성된 체인에 이미 존재하는지를 결정한다(924). 바람직하게는, 인덱싱된 데이터 저장 메커니즘을 사용하여, 인덱스에 기초하여 룩업이 수행된다. 데이터 저장 메커니즘이 어레이인 경우, 이는 인덱스 엔트리의 데이터에 액세스하는 것을 의미한다. 현재 예에서, 인덱스에 어떠한 위임된 인가 토큰도 없다.

위임된 인가 토큰을 인덱싱하기 위해 인덱스를 사용하는 것에 대한 대안으로, 이 방법은 단순히 저장된 위임된 인가 토큰들 전부에 걸쳐 루핑(loop)하여 존재 여부를 체크할 수 있다.

토큰이 현재 저장된 체인에 아직 존재하지 않으므로, 위임된 인가 토큰들의 체인이 더 많이 생성되어 클라이언트에 의해 생성된 체인에 토큰이 존재하는지를 확인해야 한다. 체인은 이전에 설명된 것과 유사하게/동일하게 구성된다(이는 바람직하게는, 초기 값을 추가로 수신된 위임된 인가 토큰과 컨케터네이팅하여 이를 단방향 함수를 반복적으로 통과시킴). 바람직하게는, 체인(H0) 내 최종 위임된 인가 토큰까지 내내 이러한 단계들을 반복하는 대신, 위임된 인가 토큰들의 체인 내 처음으로 이전에 생성되거나 수신된 위임된 인가 토큰과 만날 때까지 이러한 단계들이 반복된다. 토큰들을 생성하는 방법은 결정론적이어서, 동일한 시작 데이터가 주어지면, 동일한 체인이 생성될 것이다. 이는 최초 위임된 인가 토큰뿐만 아니라 체인 내 임의의 지점에서 시작하는 경우에 해당된다.

단방향 함수가 사용되기 때문에, 체인의 구성 시에, 서비스(또는 다른 위임자들을 포함한 시스템 내 임의의 다른 디바이스)는 초기 값이 그의 토큰에 프리펜딩되더라도, 임의의 주어진 지점으로부터 체인 내 보다 높이 있는 위임된 인증 토큰들을 계산할 수 없다. 이는 출력을 사용하여, 입력을 계산하는 것이 불가능한 단방향 함수의 속성이다. 따라서 체인은 항상, 임의의 수신된 위임된 인가 토큰들로부터 전방으로 구성되어야 한다.

예컨대, 수신된 토큰의 인덱스가 5이고 인덱스 3, 2, 1, 0(H3, H2, H1, H0)의 위임된 인가 토큰이 이미 데이터 저장 메커니즘에 저장되어 있는 경우, 추가로 수신된 위임된 인증 토큰이 유효한지 여부를 결정하기 위해, 다음 계산들만이 수행될 필요가 있다:

H3'가 이미 저장된 H3와 동일한 경우, 체인의 나머지도 동일할 것이고, 추가로 수신된 위임된 인가 토큰이 유효할 것이고, 나머지 컨케터네이션 및 단방향 함수 단계들이 스킵될 수 있다. H3'가 H3와 동일하지 않은 경우, 나머지 체인이 또한 상이할 것이고(그리고 따라서 계산들이 또한 스킵될 수 있음) 위임된 인가 토큰은 유효하지 않다.

따라서, 이 예에서, 수신된 위임된 인가 토큰의 유효성은 현재 생성된 위임된 인가 토큰(바람직하게는 현재 생성된 위임된 인가 토큰들 중 마지막 토큰)의 위임된 인가 토큰들 중 하나와 저장된 및/또는 이전에 생성된 위임된 인가 토큰의 비교에 기초하여 결정된다. 저장된 및/또는 이전에 생성된 위임된 인가 토큰들 중 가장 높은 인덱스를 가진 토큰이 바람직하다.

가장 높은 인덱스를 갖는 저장된 위임된 인가 토큰은 유효한 것으로 밝혀졌던, 이전에 수신된 위임된 인가 토큰일 가능성이 높다. 따라서 이 방법은 또한, 임의의 이전에 수신된 위임된 인가 토큰들 중 가장 높은 인덱스를 결정하고, 이전에 수신되고 유효한 위임된 인가 토큰의 인덱스와 동일한 인덱스를 갖는 위임된 인증 토큰까지, 수신된 위임된 인가 토큰에 기초하여 추가 위임된 인가 토큰들을 생성하고, 최종 생성된 위임된 인가 토큰과 이전에 수신된 위임된 인가 토큰의 비교에 기초하여 수신된 위임된 인증 토큰의 유효성을 결정하는 것으로서 설명될 수 있다. 수신된 토큰이 유효한 경우, 이 토큰은 임의의 이전에 수신된 토큰들 중 가장 높은 인덱스를 가진 토큰이 될 것이다.

도 9c를 참조하면, 예시적인 방법이 도시되며, 여기서 다른 추가 위임된 인가 토큰 및 인덱스를 포함하는 또 다른 추가 요청이 수신된다(942). 이 예에서, 토큰은 이미, 위임된 인가 토큰들의 저장된 체인의 일부이다. 이 토큰은 이전에 사용되었기 때문에 또는 이 토큰을 수신하기 전에 더 높은 인덱스를 가진 유효한 토큰이 수신되었기 때문에 이미 저장되었을 수 있다.

다른 추가 위임된 인가 토큰 및 그의 인덱스가 수신되면(942), 해당 인덱스와 연관되어 사전 생성되고 저장된 위임된 인가 토큰이 있다고 결정된다(944)(이 예의 경우). 바람직하게는 결정은 주어진 인덱스의 위임된 인가 토큰에 대해 데이터 저장 메커니즘에 질의하는 것을 포함한다. 인덱스와 관련하여 저장된 위임된 인가 토큰과 다른 추가로 수신된 위임된 인가 토큰 간의 비교가 이루어진다. 토큰의 유효성은 이 비교에 기초한다. 바람직하게는, 토큰들이 동일한 경우, 수신된 토큰이 유효하다. 토큰들이 동일하지 않은 경우, 수신된 토큰이 유효하지 않다.

바람직하게는, 제1, 제2 및 제3 방법들(900, 920, 940)은 위임된 인가 토큰들을 유효성 검증하기 위해 함께 사용된다. 유리하게도, 이러한 방법들(900, 920, 940)은 위임된 인가 토큰들이 수신될 때마다 위임된 인가 토큰들의 체인이 계산될 필요가 없도록 캐싱을 제공하고 이에 따라 강력한 액세스 제어 보안을 여전히 제공하면서, 컴퓨터 프로세싱 파워 및 시간을 절약한다. 위임자들의 수가 매우 다수인 경우, 해싱 프로세스는 컴퓨팅하는 데 시간이 걸릴 수 있다.

대안적으로, 제1 방법(900)만이 사용된다. 제1 방법(900)만이 사용되는 경우, 모든 각각의 요청의 수신 시에 위임된 인가 토큰들의 전체 체인이 생성되고 체인 중 어느 것도 저장되지 않는다. 이는 사용되지 않을 수도 있는 중간 위임된 인가 토큰을 저장할 필요가 없으며 여전히 강력한 액세스 제어 보안을 유지한다는 이점을 제공한다.

도 9d를 참조하면, 이러한 일이 언제 그리고 어떻게 발생하는지를 예시하기 위해 전체적인 방법(960)이 도시된다. 위임된 인가 토큰 및 인덱스를 포함하는 임의의 요청이 수신될 때(962), 요청이 이전에 계산되어 데이터 저장소에 저장되었는지에 대한 결정(964)이 내려진다.

위임된 인가 토큰이 이전에 생성되지 않은 경우, 인덱스로부터 시작하여, 최종 위임된 인가 토큰이 생성되거나 이전에 계산된/수신된 알려진 유효한 위임된 인가 토큰이 생성될 때까지 추가 위임된 인가 토큰들이 생성된다(966). 생성된 위임된 인가 토큰들 중 임의의 것이 임의의 이전에 수신했거나 생성된 위임된 인가 토큰들에 대한 값 및 인덱스 둘 모두 면에서 동일한 경우, 수신된 토큰은 유효한 것으로 간주된다. 바람직하게는, 이전에 수신된 또는 생성된 위임된 인가 토큰의 인덱스가 충족될 정도로 충분한 위임된 인가 토큰들만이 생성된다. 예컨대, H3가 이전에 수신되었거나 생성되었고, 현재 H5'가 수신된 경우, H5', H4' 및 H3'만이 생성된다. 현재 수신된 토큰의 유효성은 가장 낮은 인덱스를 가진 현재 위임된 인가 토큰을 가장 높은 인덱스를 갖는 이전에 수신된/생성된 위임된 인가 토큰과 비교함으로써 결정된다. 예컨대, 도 9b와 관련하여 위에서 설명된 바와 같이 H3을 H3'와 비교한다.

기록 위임된 인가 토큰들을 유효성 검증할 때, 바람직하게는, 클라이언트는 또한, 위에서 설명된 유효성 검증 방법(800)의 제1 단계(802)에서 유효성 검증 데이터의 일부로서 "최대 기록들" 값을 제공한다. 바람직하게는, 위임된 사용자가 허용받은 것보다 더 많은 데이터를 서비스에 기록하지 않도록 보장하기 위해 다른 유효성 검증 단계가 사용된다. 서비스는 각각의 위임된 인가 토큰과 연관된 "기록들의 수" 값을 저장한다. 이는 0에서 시작하고 위임된 사용자가 서비스에 기록할 때마다 증분된다. 토큰을 유효성 검증한 후, "최대 기록" 유효성 검증이 또한 수행된다. 이 유효성 검증은 "기록들의 수"를 "최대 기록들"과 비교한다. 위임된 인가 토큰에 대한 '기록들의 수'가 '최대 기록들' 값 이상인 경우, 요청이 프로세싱되지 않는다. 만약 그 미만인 경우, "기록들의 수" 값이 증분되고 요청이 프로세싱된다. 선택적으로, "기록들의 수"는 요청이 이벤트 스트림 및/또는 블록체인에 데이터를 성공적으로 기록하는 경우에만 증분된다. 당업자는 이것이 기록 이외의 다른 상호작용들에도 적용될 수 있다는 것을 이해할 것이다. 기록은 단지 예시로만 사용되었다.

일부 실시예들에서, 요청은 HTTP(Hypertext Transfer Protocol) 요청 또는 HTTPS(Hypertext Transfer Protocol Secure) 요청의 형태이다. 선택적으로, 위임된 인가 토큰은 HTTP(S) 요청의 헤더에 저장된다. 선택적으로 헤더의 형식은 다음과 같다:

2개의 값들 DelegedAuthIndex 및 DelegedAuth의 Base64 인코딩은 선택적이다. 대안적으로, 이 두 개의 이진 표현이 사용된다.

유리하게는, 위임된 인가를 헤더로 이동시킴으로써, 인가 프로세스는 RFC 7235에 설명된 바와 같이 기본 HTTP 인증 프레임워크와 더 잘 호환될 수 있다.

단일 위임자

판독 및/또는 기록을 위해 단 하나의 위임자가 필요한 경우, 단방향 함수에 대한 입력으로서 사용되는 초기 값 및 시드 값의 조합에 기초하는, 도 6을 참조하여 설명된 방법(600)을 사용하여 단 하나의 해시만이 생성된다. 서비스는 유효성 검증 목적으로 이 "최종"(그리고 유일한) 위임된 인가 토큰을 수신한다. 재구성할 위임된 인가 토큰들의 체인이 없기 때문에 초기 값들이 결코 사용되지 않을 것이고, 따라서 클라이언트는 자신이 원하는 임의의 데이터를 서비스에 전달할 수도 있고 아무것도 전달하지 않을 수도 있다. 서비스는 언제나 최종 위임된 인가 토큰만을 수신할 것이고, 이에 따라 임의의 수신된 요청들의 유효성 검증은 수신된 요청의 위임된 인가 토큰 및 최종 위임된 인가 토큰을 비교이다. 임의의 다른 토큰은 유효하지 않을 것이다.

플랫폼 시스템

일 양상에 따르면, 클라이언트 위임과 관련된 선행 양상들 중 임의의 하나 이상은 여기서 설명된 플랫폼 프로세서와 함께 사용될 수 있다. 바람직하게는, 클라이언트 위임 양상들은 API(1508)에 의해 제공되는 데이터 서비스(1502), 컴퓨팅 서비스(1504) 및/또는 커머스 서비스(1506) 액세스에 대한 액세스를 위임하는 데 사용된다. 위임된 액세스는 판독, 기록, 판독/기록, 제출 및/또는 특정 서비스와 연관될 수 있는 임의의 다른 액션의 형태로 나타날 수 있다. 본 양상은 유리하게는, BSV 블록체인과 같은 블록체인 네트워크를 사용하여 소프트웨어 제어 기술 시스템들 또는 스마트 계약들의 관리와 같은 유용한 실세계 비즈니스 및 기술 애플리케이션들의 신속한 전달을 가능하게 하는 PaaS(Platform as a Service) 및 SaaS(Software as a Service) 제안물일 수 있다.

도 10a 내지 도 10e를 참조하면, (도 11 내지 도 13을 참조하여 아래에 더 자세히 설명되는 바와 같은) 플랫폼 서비스와의 예시적인 상호작용들이 도시된다. 도시된 예시적인 상호작용들은: 이벤트 스트림에 대한 이벤트들의 추가, 이벤트 스트림에 대한 이벤트들의 질의(또는 판독), 이벤트 스트림과의 상호작용으로부터 위임된 사용자의 취소, 이벤트 스트림 및 위임된 인가 토큰들의 생성 및 시스템의 상이한 실시예들 및 양상들을 포함하는 전체 방법이다. 이들은 위임된 인가 토큰들이 이벤트 스트림들 및 플랫폼 서비스들의 맥락에서 사용되는 방법의 예를 통해 제공된다.

이러한 예시적인 실시예들에서, (이전 예시적인 실시예들에서 설명된 바와 같은) 플랫폼은 이벤트 스트림 서비스(1004), 클라이언트 인증 서비스(1006), 데이터베이스(1008) 및 메시지 버스(1010)를 포함하는 다수의 구성요소들을 포함한다.

이러한 예들에서, 플랫폼 서비스는 다수의 상이한 이벤트 스트림들(EventStreams)을 제공하고 이에 따라 클라이언트 및/또는 위임된 사용자는 이들이 상호작용하고자 하는 특정 이벤트스트림에 대한 식별자를 제공한다. 따라서 요청은 서비스 식별자를 더 포함한다. 선택적으로, 플랫폼이 상호작용할 이러한 서비스를 단 하나만 제공하는 경우, 식별자가 요구되지 않을 것이다.

도 10a부터 시작하여, 위에서 설명된 바와 같이 클라이언트(504) 또는 위임된 사용자(506)일 수 있는 클라이언트 애플리케이션(1002)은 이벤트 스트림 서비스(1004)에 이벤트를 추가하고 있다. 클라이언트 애플리케이션(1002)은 이벤트 스트림 서비스에 "appendEvent" 요청을 전송한다. "appendEvent" 요청은 이벤트와 연관된 데이터, 및 클라이언트 애플리케이션이 위임된 사용자인 경우, 위임된 인가 토큰 및 인덱스를 포함하는 DelegedAuth 정보를 포함한다. 클라이언트 애플리케이션이 클라이언트(502)인 경우, 클라이언트 인증 서비스(1006)(위에서 설명된 또는 특히 도 8을 참조하여 설명된 바와 같은 임의의 인증 서비스와는 별개임)를 사용하여 상이한 클라이언트 인증 프로세스가 수행된다.

이벤트 스트림 서비스(1004)는 데이터를 유효성 검증한 후, 요청과 연관된 위임된 인증 정보가 있는 경우, 해당 정보가 데이터베이스(1008)에 전달된다(1014). 데이터베이스는 도 8 내지 도 9d를 참조하여 설명된 바와 같은 유효성 검증 방법을 수행하고 임의의 이전에 생성된 위임된 인가 토큰들을 저장하도록 구성된다. 데이터베이스는 수신된 위임된 인가 정보에 대해 위임된 인가의 유효성으로 응답한다(미도시). 이는 기록 서비스이므로, 데이터베이스는 또한, 사용된 특정 위임된 인가 토큰과 연관된 기록들의 수가 이전에 정의된 "최대 기록들"을 초과하지 않았음을 유효성 검증할 것이다.

유효한 인가의 표시자의 경우, 이벤트 스트림 서비스(1004)는 추가 정보를 계속 프로세싱한다. 이는 이벤트를 데이터베이스(1008)에 삽입하고(1016), 이벤트의 인덱스를 수신하고(1018), 그 후 메시지 버스(1010)를 통해 블록체인에 이벤트를 게시하고(1020), 임의의 빌링 액션들을 마무리하고(1022), 마지막으로 이벤트가 성공적으로 추가되었다는 표시로 클라이언트 애플리케이션(1002)에 응답하는 것(1024)을 포함한다.

도 10b로 이동하면, 클라이언트 애플리케이션(1002)은 이벤트 스트림 서비스(1004)로부터 데이터 판독을 요청하고 있다. 클라이언트 애플리케이션(1002)은 이벤트 스트림 서비스(1004)에 "queryData" 요청을 전송한다. 이벤트 스트림 서비스(1004)는 파라미터들을 유효성 검증하고 "appendEvent" 예(1000)와 동일하거나 유사한 방법으로 인가(위임된 인가 토큰이 있는 경우) 또는 인증(대안적인 클라이언트 인증 서비스가 사용되는 경우)을 진행한다. 이는 판독 서비스이므로, 바람직하게는, 레코딩할 최대 판독들, 기록들 또는 다른 최대 상호작용들이 없다.

클라이언트 애플리케이션(1002)이 인증되거나 인가되는 경우, 데이터 질의의 일부인 임의의 필터들(이를테면, 시간 범위들, 데이터의 유형들, 데이터를 공급한 사용자 등)이 데이터베이스 질의를 구성하는 데 사용된다. 데이터베이스 질의는 SQL 포맷일 수 있다. 질의가 포멧팅되면, 이는 선택의 형태로 데이터베이스(1008)에 제출된다. 임의의 빌링 정보는 다른 서비스들이 검토 및 관리하도록 메시지 버스(1010)에 제출된다(1034). 마지막으로, 요청된 데이터는 JSON 응답 형태로 클라이언트 애플리케이션에 리턴된다(1036).

도 10c에서, 클라이언트 애플리케이션(1002)은 위임된 인가 토큰을 취소하고자 한다. 바람직하게는, 클라이언트(502)만이 그러한 액션들을 책임질 수 있고 이에 따라, 위임된 인가 토큰이 인가되도록 하는 옵션은 없으며 클라이언트 인증 방법만이 이용 가능하다.

클라이언트는 취소할 PUT 방법을 포함하는 HTTP 요청을 이벤트 스트림 서비스(1004)에 제출한다(1052). 요청은 다음을 포함한다:

·이벤트스트림의 ID인 esid,

·참조할 이벤트스트림과 연관된 체인을 데이터베이스가 알 수 있도록 클라이언트가 수정하려는 상호작용인 액세스유형(accessType) ― 바람직하게는 "판독" 또는 "기록"

·체인 내 위임된 인가 토큰의 인덱스인 인덱스

·위임된 인가 토큰인 토큰.

이러한 파라미터들은 유효성 검증되고 클라이언트가 인증된다.

이벤트 스트림 서비스(1004)는 위임된 사용자 정보를 저장하는 데이터 저장 메커니즘을 업데이트하기 위해 데이터베이스(1008)에 추가 요청을 제출한다(1054). 바람직하게는, 각각의 위임된 인가 토큰 및/또는 각각의 인덱스와 연관된 열, 플래그 또는 다른 데이터 조각이 있다(모든 위임된 인가 토큰들이 모두 알려지진 않을 수 있기 때문에). 이 데이터 조각은 올바른 인덱스 및 위임된 인가 토큰이 제공되더라도, 토큰이 유효한 것으로 간주되지 않을 것이란 점을 반영하도록 업데이트될 것이다. 대안적으로, 서비스와 연관된 "최대 기록들"이 있는 경우, 해당 위임된 인가 토큰에 대한 기록들의 수가 "최대 기록들"과 동일하게 세팅되며, 이는 모든 향후 상호작용들이 유효하지 않게 됨을 보장할 것이다.

데이터베이스(1008)는 위임된 인가 토큰이 이벤트 스트림 서비스(1004)에 대해 사용된 횟수들을 리턴할 것이다(1056). 임의의 빌링 정보는 다른 서비스들이 검토 및 관리하도록 메시지 버스(1010)에 제출된다(1058). 마지막으로, 취소가 성공했는지를 포함하는 응답이 바람직하게는 JSON 응답의 형태로 클라이언트 애플리케이션에 리턴된다(1060). 선택적으로, 응답은 또한 취소된 위임된 인가 토큰을 사용하여 상호작용이 행해진 횟수들을 포함한다.

위에서 설명된 바와 같이, 도 10d는 클라이언트가 제2 양상에 따라 위임된 인가 토큰들의 체인을 생성하고, 그 후 도 6에 따른 방법이 이벤트 스트림 서비스 상에서 이벤트 스트림을 생성하는 시스템(1070)을 도시한다.

도 10e를 참조하면, 본원에서 설명된 바와 같이 다수의 실시예들 및 특징들을 포함하는 전체 시스템이 도시된다. 클라이언트는 도 10d를 참조하여 설명된 바와 같이 위임된 인가 토큰들의 체인을 생성하고 이벤트 스트림을 생성한다. 반드시 바로 직후는 아닐지라도 일정 시간 후에, 클라이언트는 위임자가 이벤트 스트림과 상호작용하는 데 필요한 세부사항들을 제공한다. 세부사항들은 이벤트 스트림 서비스 상의 이벤트 스트림 중 어느 것이 상호작용할지를 식별하기 위한 식별자(도면에서 "esid"), 그의 위임된 인가 토큰(도면에서 "H") 및 인덱스(이 예에서 "3")를 포함한다. 이 정보를 통해, 위임자는 "appendEvent" 요청을 통해 이벤트 스트림 서비스에 데이터를 제출하는 데 충분한 정보를 갖게 된다. 요청은 클라이언트로부터 수신된 모든 동일한 세부사항들 외에도 위임자가 이벤트 스트림에 제출하려는 임의의 데이터를 포함한다.

도 10e는 또한 발생하는 예시적인 취소를 도시한다. 여기서 클라이언트는 위임된 인가 토큰을 취소하라는 요청을 제출한다. 요청은 토큰을 취소할 이벤트 스트림(esid), 토큰의 인덱스에 따른 토큰 자체, 및 취소할 상호작용의 유형(이 예에서는 "기록")을 식별한다. 주어진 이벤트 스트림에 대해 유효한 토큰 및 인덱스 매칭이 있는 경우, 이벤트 스트림 서비스는 토큰을 디스에이블한다.

플랫폼 서비스들의 개요는 시스템의 고레벨 개략도를 보여주는 도 11에서 볼 수 있다. 플랫폼 서비스는 서비스들이 하나 이상의 클라이언트들에 의해 액세스될 수 있게 하는 API(1508)를 제공하는 플랫폼 프로세서(1500)를 갖는다.

도 11에 도시된 바와 같은 플랫폼 서비스들(1500)은 3개의 서비스 패밀리들로 구성되며, 클라이언트 단부에서 어떠한 블록체인 기반 소프트웨어, 지식 또는 라이브러리들도 실제로 구현하지 않고도 사용자들 및 조직들이 블록체인의 고유한 속성들에 의해 제공되는 이점들을 쉽고 안전하게 이용할 수 있게 하는 것을 목표로 한다. 이러한 서비스는 다음과 같다:

- 상품 데이터 원장으로서 체인의 사용을 단순화하는 것을 목표로 하는 데이터 서비스(1502). 데이터 서비스는 바람직하게는 블록체인에의 데이터 기록 및 블록체인으로부터의 판독을 구현하기 위해 본원에서 제공된 데이터 구조들 및 방법들을 사용한다.

- 비트코인 SV와 같은 디지털 자산에 의해 뒷받침되는 일반화된 컴퓨팅 프레임워크를 제공하는 것을 목표로 하는 컴퓨팅 서비스(1504).

- 비트코인 SV와 같은 디지털 자산을 사용하여 트랜잭팅(transacting)하기 위한 엔터프라이즈-클래스 능력들을 제공하는 커머스 서비스들(1506).

API가 웹 서비스로 구현되기 때문에, API에서 클라이언트의 HTTPS 프로토콜을 통해 또는 HTTPS 프로토콜을 사용하여 요청들이 수신될 수 있다. 그 후, 요청된 서비스들은 기본 소프트웨어(1510)를 사용하여 하나 이상의 서비스 모듈들 또는 프로세싱 자원들(1502-1506)에 의해 구현되며, 이러한 기본 소프트웨어(1510)는 블록체인과 연관되는데, 즉 블록체인과 연관된 트랜잭션들을 생성, 프로세싱 및 제출하기 위한 자원들, 라이브러리들 및/또는 키-관리 지갑 구현들을 구현하기 위한 것이다. 일단 프로세싱되면, 트랜잭션들은 (클라이언트가 임의의 그러한 기능성 또는 트랜잭션 라이브러리들을 구현하는 대신에) 블록체인 네트워크(1512)에 제출될 수 있다. 기껏해야, 클라이언트는 암호화폐 또는 일부 다른 디지털 자산과 연관된 디지털 지갑 등을 구현할 수 있지만, 플랫폼 서비스(1500)가 또한 클라이언트를 위해 디지털 자산을 제공 및 관리할 수 있기 때문에 이것이 필수적인 것은 아니다.

도 12는 제공된 서비스들 중 임의의 하나 이상이 액세스될 수 있게 하는 API와 연관된 플랫폼(1600)에 의해 구현될 수 있고 블록체인과 연관된 복수의 서비스들의 보다 세분화된 개략도를 제공한다. 이 도 12에서 보여지는 바와 같이, 데이터 서비스(1602)는 데이터 기록기(1602a) 및 데이터 판독기 서비스(1602b)를 포함할 수 있다. 위에서 설명된 바와 같은 위임된 인가는 바람직하게는 이벤트 스트림들, 데이터 기록기 및/또는 데이터 판독기에 대한 위임된 액세스를 제공하는 데 사용된다. 유사하게, 데이터 판독기(1602b)를 사용하여 데이터 아카이브에 액세스하기를 원하는 위임된 사용자는 바람직하게는 위의 설명에 따라 위임된 인가를 갖는다. 이벤트 스트림들에 대한 추가 세부사항들은 영국 특허 출원 번호 2002285.1(2020년 2월 19일에 nChain Holdings Limited라는 이름으로 출원됨)의 도 4 내지 도 8을 참조하여 논의되고, 이로써 인용에 의해 포함된다. 데이터 기록기 서비스(1602a)는 클라이언트들이 간단하고 안전하며 최적화된 방식으로 데이터를 블록체인에 기록하는 것을 가능하게 한다. 데이터 판독기 서비스(1602b)는 클라이언트들이 블록체인에 저장된 데이터를 리턴하는 질의들을 전송하는 것을 가능하게 한다. 이는 클라이언트가 애드 혹(ad hoc) 또는 주기적 기반으로 즉, 특정 시간프레임 내에 블록체인으로부터 판독하고자 하는 데이터의 유형 또는 블록체인(1610)에서 프로세싱되는 일 세트의 관련되거나 관련되지 않은 이벤트들 또는 문서들과 연관된 것들을 미리 정의할 수 있는 필터링된 스트림들을 사용할 수 있다. 데이터 아카이브 특징은 지정된 이벤트 또는 계약에 대한 선행 트랜잭션의 로그들에 대한 액세스를 허용한다.

플랫폼(1600)의 컴퓨팅 서비스들(1606)은 스마트 계약과 연관된 애플리케이션(1606a) 및 프레임워크(1606b)를 포함하며, 이는 일부 실시예들에서, 블록체인(1610)에서 상태 머신으로서 표현될 수 있다. 컴퓨팅 서비스들(1606)은, 데이터가 입력되고 임의의 그러한 컴퓨테이션에 대한 결과들이 클라이언트에 제공될 필요가 있기 때문에, 데이터 서비스(1602)와 상호작용한다.

커머스 서비스들(1604)은 동급 최상의 보안 관행들 및 기술들에 기초하여 블록체인(1610)을 통한 트랜잭션을 위해 엔터프라이즈 지갑들(1604a)을 통해 엔터프라이즈-클래스 능력들의 제공을 담당한다. 예컨대, 일부 실시예들에서, 엔터프라이즈 지갑들은 하나 초과의 사람, 사용자 또는 계정이 정의된 기준을 충족하는, 즉 특정한 미리 정의된 제한을 초과하는 큰 값의 암호화폐와 연관된 트랜잭션에 서명(sign off)할 필요가 있을 때 블록체인 트랜잭션 프로세싱을 가능하게 하는 기능성을 구현할 수 있다. 엔터프라이즈 지갑은 또한 암호화폐 또는 다른 자원을 표현하는 토큰들과 같은 대량의 디지털 자산들을 이동시키기 위해 임계 수 및/또는 유형의 서명들을 구현하는 기능성을 또한 포함할 수 있다. 그 후 이러한 자산들의 움직임은 이러한 엔터프라이즈 지갑 구현에 의해 적용된 기준들에 기초하여 프로세싱된 후 블록체인 상에 표현될 수 있다.

SPV(simplified payment verification) 서비스들(1608)은 블록체인으로부터의 정보를 요구하지만 채굴자 노드를 실행하지 않기 때문에 이에 대한 직접 링크를 포함하지 않는 애플리케이션들이다. 이러한 SPV 서비스(1608)는 경량 클라이언트가, 전체 블록체인(1610)을 다운로드하지 않고도 트랜잭션이 블록체인에 포함되었음을 검증하도록 허용한다.

예시적인 사용 사례들

본원에서 설명된 시스템들 및 방법들은 스마트 계약들, 블록체인, 및 보다 구체적으로 이벤트 스트림들과 관련된 다수의 상이한 사용 시나리오들을 가능하게 한다. 여기서 제공된 사용 사례들은 예들일 뿐이며 숙련자는 훨씬 더 많은 사례들이 가능하다는 점을 이해할 것이다. 숙련자는, 이벤트 스트림들에 대한 구체적인 참조가 이루어지지만 이러한 사례들이 다른 스마트 계약 기술, 다른 블록체인 기술 또는 유사한 기술을 사용하여 또한 수행될 수 있다는 점을 추가로 이해할 것이다.

사례 1 ― 투표 서비스

일반 대중에게 하나의 주제 또는 다른 주제(예컨대, The Voice, Strictly, 이달의 목표, 좋아하는 아티스트 등)에 대해 투표할 기회를 제공하는 경우들의 수가 점점 늘어나고 있다. 이러한 투표들은 제한된 시간 기간 내에 투표(또는 투표들)를 행사하고자 하는 잠재적으로 매우 다수의 독립적인 사람들을 수반한다. 이러한 공개 투표들은 전형적으로 폰-인(phone-in), 웹 및 전화 앱 프런트 엔드들을 사용한다. 여기에 설명된 실시예들은 이벤트 스트림들 및 위임된 인가를 사용하여 투명성 및 공개 조사(public scrutiny)를 제공하는 저비용 스케일링 가능한 백엔드를 제공할 수 있다.

(위에서 논의된 바와 같이 클라이언트(502)로서 작용하는) 투표 마스터는 투표자들의 그룹(이는 위에서 논의된 것처럼 위임된 사용자(506)로서 작용함) 사이에서 투표를 수행하기를 원한다고 가정하고, 각각의 투표자는 제한된 시간 기간 내에서 투표를 1 내지 N번 행사할 수 있다. 이는 다음과 같이 이벤트 스트림 서비스 및 위임된 인가 토큰들을 사용하여 달성될 수 있다.

1. 투표 마스터는 그의 delegedAuthIndex 값과 함께 delegedAuth 토큰들의 세트 ― 집합적으로 이들을 'VAT(Voter Authorization Token)라 칭한다고 하자 ― 를 생성하고 투표 기간의 개시에 앞서 투표자들의 집단에 배포하는 것을 담당한다. 개별 투표자들은 자신의 투표를 행사하는 시간에 제시를 위해 그의 VAT를 저장한다.

2. 투표 마스터는 특정 시간에 시작하고 종료하는 이벤트 스트림을 생성한다.

3. 투표자들은 투표 기간 내 언제든지 appendEvent 엔드포인트를 호출함으로써 자신의 투표(들)를 행사할 수 있다. 투표들은 유효한 VAT와 함께 제시되어야 한다.

4. 각각의 투표는 VAT를 사용하여 인가될 것이며 sequenceNumber를 사용하지 않고 스트림에 추가될 것이다. 개별 이벤트들의 순서는 전형적으로 중요하지 않다. 스트림은 이벤트 스트림의 생성 동안 선택적으로 제공되는 최대 기록들을 사용하여 VAT당 1 내지 N번의 투표를 수용하도록 구성될 수 있다.

5. 투표 기간의 종료 시에, 투표 마스터는 이벤트 스트림을 마무리하고 queryData 엔드포인트를 사용하여 투표들을 집계할 것이다. 감사자는 또한, 투표들을 통해 반복하도록 위임된 판독 액세스를 사용하고, 이벤트 데이터를 유효성 검증하고, 필요에 따라 온체인 스트림 상태를 검증하도록 queryData를 사용할 수 있다.

이 투표 서비스의 특성은 다음을 포함한다:

·투표는 유효한 VAT를 소지한 투표자들의 집단으로 엄격히 제한된다.

·투표자 당 최대 투표 수는 투표 기간에 앞서 투표 마스터에 의해 엄격히 제한된다.

·투표 기간은 스트림을 생성할 때 고정된 시작 및 종료 시간들을 설정할 수 있는 투표 마스터의 직접 제어하에 있다.

·이벤트 스트림 서비스는 투표자의 아이덴티티를 알지 못하므로, 한 투표를 다른 투표보다 선호할 근거가 없다(투표자들의 IP 주소를 알 수 있다는 단서를 가짐).

·투표들은 대략 도달 시간 순서로 레코딩될 것이다.

·모든 투표들의 레코드는 구체적으로 이벤트 스트림 기술 및 보다 일반적으로 블록체인 기술의 결과로서 변경 불가능하고 감사 가능하다. 이벤트 메시지 자체는 (투표 마스터에 의해 지정된 규칙들에 따라) 난독화될 수도 있고 그렇지 않을 수도 있으며, 이는 공개 감사의 실용성을 결정할 것이다.

이벤트 스트림을 생성할 때 사용되는 예시적인 구성 데이터:

여기에서 이벤트 스트림 및 블록체인 기술의 사용은 유리하게는, 다른 "공개" 투표 상황들에서 일반적으로 발견될 수 없는 투명성의 레벨을 제공할 수 있다. 투표는 임의의 투표자가 데이터 세트에서 자신의 투표를 볼 수 있고 투표의 결과를 스스로 계산할 수 있도록 배열될 수 있다. 이러한 투표의 결과는 투표 데이터가 평문 텍스트로 저장될 때 즉시 이용 가능하게 될 것이지만, 투표 데이터가 난독화될 때 투표 마스터가 투표의 결과를 선언하기를 기다려야 한다.

VAT 분배

공정한 투표를 위해, 투표 기간의 개시에 앞서 투표자들에게 VAT가 분배되어야 한다. VAT는 사용 사례에 실용적인 임의의 방식으로 분배될 수 있다. 이에 대한 예는 각각의 VAT를 전화 앱에 분배하는 것일 수 있다. VAT는 등록된 사용자와 연관될 수도 있고 연관되지 않을 수도 있다.

대안은 계정 데이터에 VAT를 홀딩하고 계정 사용자에게 웹 인터페이스를 제공하는 것일 것이다.

대안은 홀들 및/또는 키패드 입력을 투표 데이터로 치환하고 각각의 하나를 VAT의 캐시와 연관시키는 드라이버에 다이얼 업 전화 서비스(dial-up phone service)를 연결하는 것일 것이다.

각각의 투표자 애플리케이션은 VATN이라 불리는 위임된 인가 토큰 및 인덱스 N을 포함하는 VAT를 수신할 것이다. 토큰 및 인덱스 둘 모두는 투표가 행사될 때마다 제시되어야 한다.

VAT 검증

이벤트 스트림이 생성되었을 때 WIV 및 WH0이 제공되었으면, 이벤트 서비스는 VAT_N 및 N을 포함하지만 일반 클라이언트 인증 데이터는 포함하지 않는 appendEvent에 대한 호출을 예상할 것이다. 검증 프로세스는 도 8 및 도 9a-d를 참조하여 위에서 설명한 것과 동일하거나 유사하다. 이전에 확인된 경우, 서비스는 VAT 당 최대 투표 수의 구성 및 VAT_N을 사용하여 행사된 이전 투표들의 수에 의존하여 투표를 수락하거나 거부할 것이다. 이전에 확인되지 않은 경우, 서비스는 VAT_N을 N번 반복적으로 해시하고 그 후 최종 결과를 WH0과 비교해야 한다. 이들이 동일한 경우, 투표가 인가되고 레코딩될 것이다. 예컨대; N = 3인 경우, WH0가 와 같으면 투표가 수락될 것이다.

투표 평가

바람직하게는, 투표들을 평가하고 결과를 결정하는 것은 투표 마스터의 단독 책임이다.

사례 2 ― 장비 활동 로그

하이-엔드 장비 제조자는 그의 고객 장비의 중요한 활동 로그들에 대한 액세스를 갖기를 원하며, 이는 보증 또는 서비스 계약의 일부일 수 있다. 로그들을 분석함으로써, 제조자는 장비가 피크 효율로 수행하도록 보장하기 위한 사전적 단계들을 취할 수 있을 수 있다. 위임된 인가 토큰들은 장비에 팩토리 피팅(factory fit)되어 장비가 등록부터 시작하여 그의 수명 동안 중요한 이벤트들을 자동으로 로깅하도록 허용할 수 있다.

이 경우, 다음이 권장될 것이다:

·제조자는 각각의 제품 라인에 대해 개별 이벤트 스트림을 구성할 수 있다.

·위임된 인가 토큰들은 제조자의 클라이언트 데이터베이스에 레코딩되는 위임자 인덱스와 함께 장비에 팩토리 피팅될 것이다.

·장비는 등록부터 시작하여 장비의 수명 동안 중요한 이벤트들을 자동으로 로깅할 것이다.

·제조자는 심장 박동, 실행 시간들, 중요 구성요소들의 변경, 적격 재료들의 사용 등을 포함한 임의의 활동을 원격으로 모니터링할 수 있다.

이벤트 스트림을 생성할 때 사용되는 예시적인 구성 데이터:

사례 3 ― 응찰을 통한 입찰 프로세스

정직하고 공개적인 입찰 프로세스를 수행하고자 하는 지방 의회를 고려한다. 의회는 성공적인 입찰을 수여하기 위한 요건들 및 근거를 명확하게 명시하는 입찰 문서들을 발행할 것이다.

20개 업체들이 입찰에 대한 의향을 등록했다고 가정하자. 의회는 적어도 20개 요소들에 대한 위임된 토큰들을 생성하고 입찰들을 레코딩하기 위한 이벤트 스트림을 생성해야 한다. 20개 업체들에는 자신의 입찰 문서를 제출할 때 사용할 토큰이 각각 주어진다. 입찰 기간이 끝나면 각각의 업체가 모든 입찰들의 판독을 허용하도록 동일하거나 다른 토큰이 또한 제공될 수 있다.

스트림 id(선행 예에서 "esid")는 입찰 조건들이 수락 가능하다는 것을 보장하기 위해 스트림의 메타데이터를 미리 체크하는 데 사용될 수 있다.

편견 없이 입찰 프로세스가 수행되도록 보장하기 위해, 이벤트 스트림이 다음과 같이 구성될 수 있다:

구성 파라미터 설명:

파라미터	구성 효과
settleDataOnChain.method	메서드 onEvent는 각각의 입찰 문서가 온체인으로 레코딩될 것임을 표시한다. setDataOnChain의 디폴트 값은 공증이며, 이는 전체 문서가 아닌 입찰 문서의 다이제스트가 레코딩되게 할 것이다.
writeAccessControl.maxWritesPerDelegate	각각의 업체가 입찰을 등록할 수 있는 최대 횟수를 세팅한다.
writeAccessControl.delegatedWriteH0	위임된 기록 인가를 위한 스트림을 구성한다.
writeAccessControl.delegatedWriteIV	위임된 기록 인가를 위한 스트림을 구성한다.
readAccessControl.delegatedWriteH0	위임된 판독 인가를 위한 스트림을 구성한다.
readAccessControl.delegatedWriteIV	위임된 판독 인가를 위한 스트림을 구성한다.
readAccessControl.readAfterFinalise	입찰 기간이 끝나기 전에 임의의 데이터가 판독되는 것을 방지한다.
timeAccessControl.openFrom	입찰 기간의 시작을 2020년 10월 10일 GMT 자정으로 세팅한다.
timeAccessControl.openUntil	입찰 기간 종료를 2020년 10월 20일 GMT 자정으로 세팅한다.

이 구성의 경우, delegedAuth 토큰을 수신한 업체들은 입찰서를 등록하고 최대 3회까지 수정할 수 있을 것이다. 입찰들은 지정된 기간 내에 엄격하게 수락될 것이며, 입찰 기간이 끝날 때까지 누구도 응찰을 볼 수 없을 것이다. 블록체인 상에 이러한 입찰 정보를 레코딩하는 것은 이러한 응찰 프로세스를 공개적으로 감사하는 방식을 제공하고 그리하여, 전체 프로세스가 준수됨을 보장하고 악의적인 행위자가 응찰 프로세스를 방해할 가능성을 감소시키고 전반적으로 이러한 다중 당사자 상호작용의 보안을 증가시킨다.

업체들이 또한 각각의 입찰이 제출된 직후 온체인으로 자신의 응찰의 다이제스트를 모니터링할 수 있을 것이다. 이러한 다이제스트들은 존재의 증명으로서 역할을 하고 그리하여 제출과 감사 사이에 응찰 콘텐츠가 변경되지 않았음을 보장한다. 유리하게는, 응찰이 무엇인지 보여주지 않고 응찰의 존재가 레코딩되도록 허용한다.

사례 4 ― 메시지 난독화

이벤트 데이터(이하 ED)를 난독화할 필요성은 사용 사례에 의존한다. 투명성 및 공개 감사의 용이성을 위해, 평문 텍스트 이벤트 데이터가 바람직하다. 그러나 이벤트 데이터는 매우 민감할 수 있어서, 이벤트 스트림을 제공하는 서비스에도 드러나선 안 된다. 이러한 경우들에서, 클라이언트는 클라이언트가 각각의 이벤트를 판독하도록 허용하지만 다른 것들은 허용하지 않는 방식으로 이벤트들이 난독화되도록 지시할 수 있다. 이를 달성하는 비교적 간단한 방법은 셰어드 비밀(shared secret)을 통하는 것이다:

·delegedAuth 토큰 및 인덱스와 함께, 클라이언트는 또한 각각의 기여자에게 다른 랜덤 번호 IV(이하 fIV)를 또한 제공한다(즉, 비공개로 유지되어야 하는 셰어드 비밀). 이는 기여자의 데이터를 암호화할 때 초기 벡터로서 사용된다.

·각각의 기여자는 클라이언트에 의해 지정된 규칙들에 따라 자신의 이벤트 데이터(ED)를 포맷화한다.

· 그 후 ED는 AES와 같은 일반적인 방법을 사용하여 암호화된다. ED가 기여자 및 클라이언트에 의해서만 판독될 수 있도록 기여자의 개인 iv가 사용된다.

그 후, 이벤트 메시지는 다음과 같이 구성될 수 있다.

클라이언트가 기여자의 데이터를 평가하고자 할 때, 이들은 queryData를 사용하여 이벤트 레코드를 획득할 수 있다. 이 레코드는 기여자의 id, 및 이에 따른 셰어드 비밀 iv을 찾는 데 사용될 수 있는 위임자의 인덱스를 포함한다. 그 후, 이는 난독화된 데이터 요소로부터 평문 텍스트 이벤트 데이터를 복구하는 데 사용될 수 있다.

플랫폼 디바이스들

이제 도 13을 참조하면, 본 개시내용의 적어도 하나의 실시예를 실행하는 데 사용될 수 있는 컴퓨팅 디바이스(2600)의 예시적이고 단순화된 블록도가 제공된다. 다양한 실시예들에서, 컴퓨팅 디바이스(2600)는 위에서 예시되고 설명된 시스템들 또는 방법들 중 임의의 것을 구현하는 데 사용될 수 있다. 예컨대, 컴퓨팅 디바이스(2600)는 도 5의 이전에 설명된 시스템(500)에서 하나 이상의 구성요소들로서 사용되도록 구성될 수 있다. 컴퓨팅 디바이스(2600)는 주어진 사용자와 연관된 클라이언트 엔티티가 되도록 구성될 수 있으며; 플랫폼 프로세서에 데이터베이스 요청 및/또는 제출을 하는 클라이언트 엔티티이다. 컴퓨팅 디바이스(2600)는 위임된 사용자가 되도록 구성될 수 있다. 위임된 사용자는 그의 위임된 인가 토큰의 수신 시에, 플랫폼 프로세서에 데이터 요청 및/또는 제출을 할 수 있다. 따라서 컴퓨팅 디바이스(2600)는 휴대용 컴퓨팅 디바이스, 개인용 컴퓨터 또는 임의의 전자 컴퓨팅 디바이스일 수 있다. 도 13에 도시된 바와 같이, 컴퓨팅 디바이스(2600)는 하나 이상의 레벨들의 캐시 메모리 및 메인 메모리(2608) 및 영구 저장소(2610)를 포함하는 저장 서브시스템(2606)과 통신하도록 구성될 수 있는 메모리 제어기를 갖는 하나 이상의 프로세서들(집합적으로 2602로 라벨링됨)을 포함할 수 있다. 메인 메모리(2608)는 도시된 바와 같이 동적 랜덤 액세스 메모리(DRAM)(2618) 및 판독 전용 메모리(ROM)(2620)를 포함할 수 있다. 저장 서브시스템(2606) 및 캐시 메모리(2602)는 본 개시내용에서 설명된 바와 같이 트랜잭션들 및 블록들과 연관된 세부사항들과 같은 정보의 저장을 위해 사용될 수 있다. 프로세서(들)(2602)는 본 개시내용에서 설명된 바와 같은 임의의 실시예의 기능성 또는 단계들을 제공하기 위해 활용될 수 있다.

프로세서(들)(2602)는 또한 하나 이상의 사용자 인터페이스 입력 디바이스들(2612), 하나 이상의 사용자 인터페이스 출력 디바이스들(2614) 및 네트워크 인터페이스 서브시스템(2616)과 통신할 수 있다.

버스 서브시스템(2604)은 컴퓨팅 디바이스(2600)의 다양한 구성요소들 및 서브시스템들이 의도된 대로 서로 통신하는 것을 가능하게 하기 위한 메커니즘을 제공할 수 있다. 버스 서브시스템(2604)이 단일 버스로서 개략적으로 도시되지만, 버스 서브시스템의 대안적인 실시예들은 다수의 버스들을 활용할 수 있다.

네트워크 인터페이스 서브시스템(2616)은 다른 컴퓨팅 디바이스들 및 네트워크들에 대한 인터페이스를 제공할 수 있다. 네트워크 인터페이스 서브시스템(2616)은 다른 시스템들로부터 컴퓨팅 디바이스(2600)로 데이터를 수신하고 컴퓨팅 디바이스(2600)로부터 다른 시스템들로 데이터를 송신하기 위한 인터페이스 역할을 할 수 있다. 예컨대, 네트워크 인터페이스 서브시스템(2616)은 데이터 기술자(data technician)가 디바이스를 네트워크에 연결하는 것을 가능하게 할 수 있어서, 데이터 기술자는 데이터 센터와 같은 원격 위치에 있으면서 디바이스로 데이터를 송신하고 디바이스로부터 데이터를 수신할 수 있을 수 있다.

사용자 인터페이스 입력 디바이스들(2612)은 하나 이상의 사용자 입력 디바이스들 이를테면, 키보드; 통합 마우스, 트랙볼, 터치패드 또는 그래픽 태블릿과 같은 포인팅 디바이스; 스캐너; 바코드 스캐너; 디스플레이에 통합된 터치스크린; 음성 인식 시스템들, 마이크로폰들과 같은 오디오 입력 디바이스들; 및 다른 유형들의 입력 디바이스들을 포함할 수 있다. 일반적으로, "입력 디바이스"라는 용어의 사용은 컴퓨팅 디바이스(2600)에 정보를 입력하기 위한 모든 가능한 유형들의 디바이스들 및 메커니즘들을 포함하도록 의도된다.

하나 이상의 사용자 인터페이스 출력 디바이스들(2614)은 디스플레이 서브시스템, 프린터, 또는 비-시각적 디스플레이 이를테면, 오디오 출력 디바이스 등을 포함할 수 있다. 디스플레이 서브시스템은 음극선관(CRT), 평면 패널 디바이스 이를테면, 액정 디스플레이(LCD), 발광 다이오드(LED) 디스플레이, 또는 프로젝션 또는 다른 디스플레이 디바이스일 수 있다. 일반적으로, "출력 디바이스"라는 용어의 사용은 컴퓨팅 디바이스(2600)로부터 정보를 출력하기 위한 모든 가능한 유형들의 디바이스들 및 메커니즘들을 포함하도록 의도된다. 하나 이상의 사용자 인터페이스 출력 디바이스들(2614)은, 예컨대, 설명된 프로세스들 및 변형들을 내부에서 수행하는 애플리케이션과의 사용자 상호작용이 적절할 수 있을 때 그러한 상호작용을 용이하게 하기 위한 사용자 인터페이스를 제시하는 데 사용될 수 있다.

저장 서브시스템(2606)은 본 개시내용의 적어도 하나의 실시예의 기능성을 제공할 수 있는 기본 프로그래밍 및 데이터 구조들을 저장하기 위한 컴퓨터-판독 가능 저장 매체를 제공할 수 있다. 하나 이상의 프로세서들에 의해 실행될 때, 애플리케이션들(프로그램들, 코드 모듈들, 명령들)은 본 개시내용의 하나 이상의 실시예들의 기능성을 제공할 수 있고, 저장 서브시스템(2606)에 저장될 수 있다. 이러한 애플리케이션 모듈들 또는 명령들은 하나 이상의 프로세서들(2602)에 의해 실행될 수 있다. 저장 서브시스템(2606)은 본 개시내용에 따라 사용되는 데이터를 저장하기 위한 리포지토리를 부가적으로 제공할 수 있다. 예컨대, 메인 메모리(2608) 및 캐시 메모리(2602)는 프로그램 및 데이터를 위한 휘발성 저장소를 제공할 수 있다. 영구 저장소(2610)는 프로그램 및 데이터를 위한 영구(비-휘발성) 저장소를 제공할 수 있으며, 플래시 메모리, 하나 이상의 솔리드 스테이트 드라이브들, 하나 이상의 자기 하드 디스크 드라이브들, 연관된 이동식 매체들을 갖는 하나 이상의 플로피 디스크 드라이브들, 연관된 이동식 매체들을 갖는 하나 이상의 광학 드라이브들(예컨대, CD-ROM 또는 DVD 또는 블루레이 드라이브) 및 다른 유사한 저장 매체들을 포함할 수 있다. 이러한 프로그램 및 데이터는 본 개시내용에 설명된 바와 같은 트랜잭션들 및 블록들과 연관된 데이터뿐만 아니라 본 개시내용에 설명된 바와 같은 하나 이상의 실시예들의 단계들을 수행하기 위한 프로그램들을 포함할 수 있다.

컴퓨팅 디바이스(2600)는 휴대용 컴퓨터 디바이스, 태블릿 컴퓨터, 워크스테이션, 또는 아래에서 설명되는 임의의 다른 디바이스를 포함하는 다양한 유형들로 이루어질 수 있다. 부가적으로, 컴퓨팅 디바이스(2600)는 하나 이상의 포트들(예컨대, USB, 헤드폰 잭, 라이트닝 커넥터 등)을 통해 컴퓨팅 디바이스(2600)에 연결될 수 있는 다른 디바이스를 포함할 수 있다. 컴퓨팅 디바이스(2600)에 연결될 수 있는 디바이스는 광섬유 커넥터들을 수용하도록 구성된 복수의 포트들을 포함할 수 있다. 따라서, 이 디바이스는 프로세싱을 위해 컴퓨팅 디바이스(2600)에 디바이스를 연결하는 포트를 통해 송신될 수 있는 전기 신호들로 광학 신호들을 변환하도록 구성될 수 있다. 컴퓨터들 및 네트워크들의 끊임없이 변하는 성질로 인해, 도 13에 도시된 컴퓨팅 디바이스(2600)의 설명은 디바이스의 바람직한 실시예를 예시하기 위한 특정 예로서만 의도된다. 도 13에 도시된 시스템보다 더 많거나 더 적은 구성요소들을 갖는 다수의 다른 구성들이 가능하다.

위에서 설명된 다양한 방법들은 컴퓨터 프로그램에 의해 구현될 수 있다. 컴퓨터 프로그램은 위에서 설명된 다양한 방법들 중 하나 이상의 기능들을 수행하도록 컴퓨터에 지시하도록 배열된 컴퓨터 코드를 포함할 수 있다. 이러한 방법들을 수행하기 위한 컴퓨터 프로그램 및/또는 코드는 장치, 이를테면, 컴퓨터에 하나 이상의 컴퓨터 판독 가능 매체 또는 더 일반적으로는 컴퓨터 프로그램 제품으로 제공될 수 있다. 컴퓨터 판독 가능 매체들은 일시적 또는 비-일시적일 수 있다. 하나 이상의 컴퓨터 판독 가능 매체들은 예컨대, 전자, 자기, 광학, 전자기, 적외선 또는 반도체 시스템, 또는 예컨대, 인터넷을 통해 코드를 다운로드하기 위한 데이터 송신용 전파 매체일 수 있다. 대안적으로, 하나 이상의 컴퓨터 판독 가능 매체들 하나 이상의 물리적 컴퓨터 판독 가능 매체들 이를테면, 반도체 또는 솔리드-스테이트 메모리, 자기 테이프, 제거 가능 컴퓨터 디스켓, 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 강성 자기 디스크 및 광학 디스크 이를테면, CD-ROM, CD-R/W 또는 DVD의 형태를 취할 수 있다.

일 구현에서, 본원에서 설명된 모듈들, 구성요소들 및 다른 특징들은 개별 구성요소들로서 구현되거나 ASIC들, FPGA들, DSP들 또는 유사한 디바이스들과 같은 하드웨어 구성요소들의 기능성에 통합될 수 있다.

"하드웨어 구성요소" 또는 "하드웨어 모듈"은 특정 동작들을 수행할 수 있는 실체가 있는(예컨대, 비일시적) 물리적 구성요소(예컨대, 하나 이상의 프로세서들의 세트)이며 특정 물리적 방식으로 구성되거나 배열될 수 있다. 하드웨어 구성요소는 특정 동작들을 수행하도록 영구적으로 구성된 전용 회로 또는 로직을 포함할 수 있다. 하드웨어 구성요소는 FPGA(field programmable gate array) 또는 ASIC과 같은 특수 목적 프로세서이거나 이를 포함할 수 있다. 하드웨어 구성요소는 또한 특정 동작들을 수행하기 위해 소프트웨어에 의해 일시적으로 구성되는 프로그래밍 가능 록직 또는 회로를 포함할 수 있다.

따라서, "하드웨어 구성요소" 또는 "하드웨어 모듈"이라는 문구는, 특정 방식으로 동작하거나 본원에서 설명된 특정 동작들을 수행하도록 물리적으로 구성되거나, 영구적으로 구성(예컨대, 하드와이어링됨)되거나, 또는 일시적으로 구성(예컨대, 프로그래밍됨)될 수 있는 실체가 있는 엔티티를 포괄하는 것으로 이해되어야 한다.

또한, 모듈들 및 구성요소들은 하드웨어 디바이스 내에서 펌웨어 또는 기능 회로로서 구현될 수 있다. 또한, 모듈들 및 구성요소들은 하드웨어 디바이스들 및 소프트웨어 구성요소들의 임의의 조합으로 또는 소프트웨어(예컨대, 기계 판독 가능 매체 또는 송신 매체에 저장되거나 달리 구체화되는 코드)로만 구현될 수 있다.

다음의 논의들로부터 명백한 바와 같이 달리 구체적으로 언급되지 않으면, 설명 전반에 걸쳐, "결정하는", "제공하는", "계산하는", "컴퓨팅하는", "식별하는", "결합하는", "설정하는", "전송하는", "수신하는", "저장하는", "추정하는", "체크하는", "획득하는" 등과 같은 용어들을 활용한 논의들은, 컴퓨터 시스템의 레지스터들 및 메모리들 내의 물리적(전자적) 양들로서 표현되는 데이터를, 컴퓨터 시스템 메모리들 또는 레지스터들 또는 다른 이러한 정보 저장, 송신 또는 디스플레이 디바이스들 내의 물리적 양들로서 유사하게 표현되는 다른 데이터로 조작 및/또는 변형하는 컴퓨터 시스템, 또는 유사한 전자 컴퓨팅 디바이스의 액션(action)들 및 프로세스들을 지칭한다는 것이 인지된다.

본 명세서 및 청구항들에서 사용되는 바와 같은 "포함하는"이라는 용어는 "~로 적어도 부분적으로 구성되는"을 의미한다. "포함하는"이라는 용어를 포함하는 본 명세서 및 청구항들에서의 각각의 진술을 해석할 때, 해당 용어의 단서가 되는 특징 또는 특징들 이외의 특징들이 또한 존재할 수 있다. "포함하다"("comprise" 및 "comprises")와 같은 관련 용어들이 또한 동일한 방식으로 해석되어야 한다.

본원에서 개시된 숫자들의 범위(예컨대, 1 내지 10)에 대한 참조는 또한 해당 범위 내의 모든 유리수들(예컨대, 1, 1.1, 2, 3, 3.9, 4, 5, 6, 6.5, 7, 8, 9 및 10) 및 또한 해당 범위 내의 유리수들의 임의의 범위(예컨대, 2 내지 8, 1.5 내지 5.5 및 3.1 내지 4.7)에 대한 참조를 포함하고, 이에 따라 본원에서 명시적으로 개시된 모든 범위들의 모든 하위 범위들이 이로써 명시적으로 개시되도록 의도된다. 이들은 구체적으로 의도된 것의 예들일 뿐이며 열거된 최저 값과 최고 값 사이의 수치 값의 모든 가능한 조합들이 유사한 방식으로 본 출원에서 명시적으로 언급되는 것으로 간주된다.

본원에서 사용되는 바와 같은 "및/또는"이라는 용어는 "및" 또는 "또는" 또는 둘 모두를 의미한다.

본원에서 사용된 바와 같은 명사의 복수 표현은 해당 명사의 복수 및/또는 단수 형태들을 의미한다.

요소의 단수 참조는 그러한 요소들의 복수 참조를 배제하지 않으며 그 반대의 경우도 마찬가지이다.

위의 설명은 제한이 아니라 예시적인 것으로 의도됨을 이해할 것이다. 위의 설명을 판독 및 이해할 시에, 다수의 다른 구현들이 당업자들에게 명백할 것이다. 본 개시내용이 특정한 예시적인 구현들을 참조하여 설명되었지만, 본 개시내용은 설명된 구현들로 제한되는 것이 아니라, 첨부된 청구범위들의 범위 내에서의 변경 및 수정을 이용하여 실시될 수 있음을 인식할 것이다. 따라서, 명세서 및 도면들은 제한적인 의미가 아니라 예시적인 의미로 간주되어야 한다. 따라서, 본 개시내용의 범위는, 첨부된 청구항들이 권리를 가지는 등가물들의 전체 범위와 함께 그러한 청구범위들을 참조하여 결정되어야 한다.

Claims (35)

1. 컴퓨터 구현 방법으로서,
   미리 결정된 값을 획득하는 단계,
   위임된 인가 토큰들의 체인 중 최초 위임된 인가 토큰을 포함하는 요청을 수신하는 단계,
   상기 위임된 인가 토큰들의 체인의 추가 위임된 인가 토큰들을 생성하는 단계 ― 상기 위임된 인가 토큰들의 체인 내 각각의 추가 위임된 인가 토큰의 생성은 상기 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰에 기초함 ― ;
   상기 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들 중 하나와 상기 미리 결정된 값의 비교에 기초하여 상기 최초 위임된 인가 토큰의 유효성을 결정하는 단계를 포함하는,
   컴퓨터 구현 방법.
2. 제1 항에 있어서,
   상기 생성은 상기 위임된 인가 토큰들의 체인 내 상기 선행 위임된 인가 토큰을 해싱하는 것에 기초하는,
   컴퓨터 구현 방법.
3. 제1 항 또는 제2 항에 있어서,
   상기 위임된 인가 토큰들의 체인의 추가 위임된 인가 토큰들을 생성하는 단계는, 각각의 추가 위임된 인가 토큰에 대해,
   중간 프리이미지를 결정하는 단계 ― 상기 중간 프리이미지는 상기 위임된 인가 토큰들의 체인 내 상기 선행 위임된 인가 토큰에 기초함 ― , 및
   단방향 함수를 상기 중간 프리이미지에 적용하는 단계
   를 수행하는 것을 포함하고, 상기 단방향 함수에 대한 출력은 상기 추가 위임된 인가 토큰인,
   컴퓨터 구현 방법.
4. 제3 항에 있어서,
   상기 단방향 함수는 단방향 함수인,
   컴퓨터 구현 방법.
5. 제3 항 또는 제4 항에 있어서,
   상기 중간 프리이미지는 부가적으로 주어진 값에 기초하는,
   컴퓨터 구현 방법.
6. 제1 항 또는 제2 항에 있어서,
   상기 추가 위임된 인가 토큰들의 생성은 상기 위임된 인가 토큰들의 체인 내 상기 선행 위임된 인가 토큰 및 주어진 값에 기초하는,
   컴퓨터 구현 방법.
7. 제5 항 또는 제6 항에 있어서,
   저장소로부터 상기 주어진 값을 획득하는 단계를 더 포함하는,
   컴퓨터 구현 방법.
8. 제5 항 내지 제7 항 중 어느 한 항에 있어서,
   상기 주어진 값은 클라이언트로부터 수신되는,
   컴퓨터 구현 방법.
9. 제5 항 내지 제8 항 중 어느 한 항에 있어서,
   상기 생성은 상기 주어진 값 및 상기 선행 위임된 인가 토큰의 컨케터네이션(concatenation)에 기초하는,
   컴퓨터 구현 방법.
10. 제9 항에 있어서,
    상기 생성은 상기 위임된 인가 토큰들의 체인 내 상기 선행 위임된 인가 토큰 및 상기 주어진 값의 컨케터네이션을 해싱하는 것에 기초하는,
    컴퓨터 구현 방법.
11. 전술한 청구항 중 어느 한 항에 있어서,
    상기 요청은 인덱스 번호를 더 포함하고, 상기 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들의 수는 상기 인덱스 번호에 기초하는,
    컴퓨터 구현 방법.
12. 전술한 청구항 중 임의의 하나 이상에 있어서,
    상기 최초 위임된 인가 토큰의 유효성을 결정하는 단계는 상기 위임된 인가 토큰들의 체인 내 최종 위임된 인가 토큰들과 상기 미리 결정된 값의 비교에 기초하는,
    컴퓨터 구현 방법.
13. 전술한 청구항 중 임의의 하나 이상에 있어서,
    상기 최초 위임된 인가 토큰의 유효성을 결정하는 단계는,
    상기 위임된 인가 토큰들의 체인 내 상기 최종 위임된 인가 토큰 및 상기 미리 결정된 값이 동일한 값을 갖는지를 비교하는 단계를 포함하는,
    컴퓨터 구현 방법.
14. 전술한 청구항 중 임의의 하나 이상에 있어서,
    상기 요청은 상기 블록체인에 제출하거나 상기 블록체인으로부터 판독하기 위한 것인,
    컴퓨터 구현 방법.
15. 전술한 청구항 중 임의의 하나 이상에 있어서,
    상기 요청의 프로세싱은 추가로, 동일한 최초 위임된 인가 토큰을 포함하는 이전에 수신된 요청들의 수에 기초하는,
    컴퓨터 구현 방법.
16. 전술한 청구항 중 임의의 하나 이상에 있어서,
    상기 위임된 인가 토큰들의 체인을 저장하는 단계를 더 포함하는,
    컴퓨터 구현 방법.
17. 제16 항에 있어서,
    추가 위임된 인가 토큰을 포함하는 추가 요청을 수신하는 단계,
    상기 추가 위임된 인가 토큰이 상기 위임된 인가 토큰들의 저장된 체인에 존재하는지에 기초하여 상기 추가 위임된 인가 토큰의 유효성을 결정하는 단계, 및
    상기 추가 위임된 인가 토큰의 유효성에 기초하여 상기 추가 요청을 프로세싱하는 단계를 더 포함하는,
    컴퓨터 구현 방법.
18. 전술한 청구항 중 임의의 하나 이상에 있어서,
    상기 요청의 유효성의 표시를 제공하고 그리고/또는 상기 위임된 인가 토큰의 유효성에 기초하여 상기 요청을 프로세싱하는 단계를 더 포함하는
    컴퓨터 구현 방법.
19. 연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법으로서,
    제1 값 및 제2 값을 획득하는 단계,
    상기 위임된 인가 토큰들의 체인의 최초 위임된 인가 토큰을 생성하는 단계 ― 상기 최초 위임된 인가 토큰은 상기 제1 값 및 상기 제2 값에 기초함 ― , 및
    상기 위임된 인가 토큰들의 체인의 적어도 하나의 추가 위임된 인가 토큰을 생성하는 단계를 포함하고, 상기 위임된 인가 토큰들의 체인 내 각각의 추가 위임된 인가 토큰의 생성은 상기 위임된 인가 토큰들의 체인 내 선행 위임된 인가 토큰 및 상기 제1 값에 기초하는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
20. 제19 항에 있어서,
    상기 위임된 인가 토큰들의 체인의 추가 위임된 인가 토큰들을 생성하는 단계는, 각각의 추가 위임된 인가 토큰에 대해,
    중간 프리이미지를 결정하는 단계 ― 상기 중간 프리이미지는 상기 위임된 인가 토큰들의 체인 내 상기 선행 위임된 인가 토큰 및 상기 제1 값에 기초함 ― , 및
    단방향 함수를 상기 중간 프리이미지에 적용하는 단계
    를 수행하는 것을 포함하고, 상기 단방향 함수에 대한 출력은 상기 추가 위임된 인가 토큰인,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
21. 제20 항에 있어서,
    상기 생성은 상기 제1 값 및 상기 선행 위임된 인가 토큰의 컨케터네이션에 기초하는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
22. 제21 항에 있어서,
    상기 생성은 상기 위임된 인가 토큰들의 체인 내 상기 선행 위임된 인가 토큰 및 상기 주어진 값의 컨케터네이션을 해싱하는 것에 기초하는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
23. 제19 항 내지 제22 항 중 어느 한 항에 있어서,
    상기 위임된 인가 토큰들의 체인의 위임된 인가 토큰들 중 하나를 위임자 디바이스에 제공하는 단계를 더 포함하는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
24. 제23 항에 있어서,
    상기 위임자 디바이스에는 추가로, 상기 위임된 인가 토큰의 인덱스가 제공되고, 상기 인덱스는 상기 제공된 위임된 인가 토큰이 상기 위임된 인가 토큰들의 체인에서 어디에 있는지를 표현하는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
25. 제19 항 내지 제24 항 중 어느 한 항에 있어서,
    상기 위임된 인가 토큰들의 체인의 최종 위임된 인가 토큰 및 상기 제1 값을 검증 디바이스에 제공하는 단계를 더 포함하는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
26. 제25 항에 있어서,
    상기 검증 디바이스에는 추가로, 위임자 당 판독들 또는 기록들의 최대 수를 표시하는 수가 제공되는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
27. 제19 항 내지 제26 항 중 어느 한 항에 있어서,
    상기 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들의 수는 위임자들의 수에 기초하는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
28. 제27 항에 있어서,
    상기 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들의 수는 상기 위임자들의 수 이상인,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
29. 제19 항 내지 제28 항 중 어느 한 항에 있어서,
    상기 제2 값은 상기 최초 위임된 인가 토큰이 생성된 후에 삭제되는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
30. 제19 항 내지 제29 항 중 어느 한 항에 있어서,
    상기 제1 값 및 상기 제2 값은 랜덤으로 생성되는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
31. 전술한 청구항 중 임의의 하나 이상에 있어서,
    상기 선행 위임된 인가 토큰은 상기 위임된 인가 토큰이 생성되기 직전의 위임된 인가 토큰을 지칭하는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
32. 제1 항 내지 제18 항 중 어느 한 항에 있어서,
    상기 최초 위임된 인가 토큰은 제19 항 내지 제31 항 중 임의의 하나 이상의 방법에 따라 클라이언트에 의해 생성되는,
    연관된 위임된 인가 토큰들의 체인을 생성하기 위한 컴퓨터 구현 방법.
33. 컴퓨터 구현 방법으로서,
    제19 항 내지 제31 항 중 임의의 하나 이상의 방법에 따라 생성된 위임된 인가 토큰을 수신하는 단계,
    상기 위임된 인가 토큰을 포함하는 요청을 생성하는 단계, 및
    상기 요청을 서버에 전송하는 단계를 포함하는,
    컴퓨터 구현 방법.
34. 시스템으로서,
    서버,
    위임자, 및
    클라이언트를 포함하고, 상기 클라이언트는,
    제19 항 내지 제31 항 중 임의의 하나 이상에 따라, 위임된 인가 토큰들의 체인 및 제1 값을 생성하고,
    상기 제1 값 및 상기 위임된 인가 토큰들의 체인들의 최종 위임된 인가 토큰을 상기 서버에 송신하고, 그리고
    상기 위임된 인가 토큰들의 체인 내 위임된 인가 토큰들 중 하나를 상기 위임자에게 송신하도록 구성되는,
    시스템.
35. 제34 항에 있어서,
    상기 서버는,
    제1 항 내지 제18 항 중 임의의 하나 이상의 방법에 따라 상기 위임자로부터 요청을 수신 및 프로세싱하도록 구성되는,
    시스템.