KR20230005353A - 탈중앙화된 데이터베이스에서 허가된 이벤팅 - Google Patents

탈중앙화된 데이터베이스에서 허가된 이벤팅 Download PDF

Info

Publication number
KR20230005353A
KR20230005353A KR1020227042214A KR20227042214A KR20230005353A KR 20230005353 A KR20230005353 A KR 20230005353A KR 1020227042214 A KR1020227042214 A KR 1020227042214A KR 20227042214 A KR20227042214 A KR 20227042214A KR 20230005353 A KR20230005353 A KR 20230005353A
Authority
KR
South Korea
Prior art keywords
event
blockchain
event data
context
identifier
Prior art date
Application number
KR1020227042214A
Other languages
English (en)
Inventor
제이슨 옐릭
알레산드로 소르니오티
엘리 안드룰라키
안젤로 데 카로
Original Assignee
인터내셔널 비지네스 머신즈 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 인터내셔널 비지네스 머신즈 코포레이션 filed Critical 인터내셔널 비지네스 머신즈 코포레이션
Publication of KR20230005353A publication Critical patent/KR20230005353A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

예시적인 동작은 주체(an entity)로부터 이벤트 데이터를 수신하는 단계, 상기 이벤트 데이터가 보증 정책을 만족하는지를 결정하는 단계, 상기 이벤트 데이터의 컨텍스트에 대응하는 식별자를 세트 하는 단계, 상기 이벤트 데이터 및 상기 식별자를 포함하는 이벤트를 생성하는 단계, 및 탈중앙화된 데이터베이스(a decentralized database)에 기록하기 위해 이벤트를 제출하는 단계를 포함하고, 상기 식별자는 상기 이벤트 데이터의 컨텍스트와 대응하는 상태가 올바른지(correct)를 검증하기 위해 사용된다.

Description

탈중앙화된 데이터베이스에서 허가된 이벤팅
[0001] 중앙 집중식 데이터베이스(centralized database)는 한 위치에 있는 단일 데이터베이스(예: 데이터베이스 서버)에 데이터를 저장하고 유지한다. 이 위치는 종종 중앙 컴퓨터, 예를 들어, 데스크톱 중앙 처리 유닛(CPU), 서버 CPU 또는 메인프레임 컴퓨터이다. 중앙 집중식 데이터베이스에 저장된 정보는 일반적으로 다수의 다양한 지점들에서 액세스할 수 있다. 예를 들어, 클라이언트/서버 구성을 기반으로 다수의 사용자들 또는 클라이언트 워크스테이션들이 중앙 집중식 데이터베이스에서 동시에 작업할 수 있다. 중앙 집중식 데이터베이스는 단일 위치로 인해 특히 보안 목적으로 관리, 유지 및 제어하기 쉽다. 중앙 집중식 데이터베이스 내에서 데이터 중복성(data redundancy)은 모든 데이터의 단일 저장 장소가 주어진 데이터 세트에 하나의 기본 레코드(one primary record)만 있음을 의미하므로 최소화된다.
[0002] 일 예시적 실시 예는 시스템을 제공하고, 상기 시스템은 주체(an entity)로부터 이벤트 데이터를 수신하기 위한 하나 또는 그 이상의 수신기, 스마트 계약의 체인코드(chaincode)를 저장하기 위한 스토리지 영역(a storage area), 및 상기 스마트 계약을 실행하기 위한 프로세서를 포함하고, 상기 프로세서는 상기 이벤트 데이터가 보증 정책을 만족하는지를 결정하는 단계, 상기 이벤트 데이터의 컨텍스트에 대응하는 식별자를 세트 하는 단계, 상기 이벤트 데이터 및 상기 식별자를 포함하는 이벤트를 생성하는 단계, 및 탈중앙화된 데이터베이스(a decentralized database)에 기록하기 위해 이벤트를 제출하는 단계 중 하나 또는 그 이상을 수행하고, 상기 식별자는 상기 이벤트 데이터의 컨텍스트와 대응하는 상태가 올바른지(correct)를 검증한다(validate).
[0003] 다른 예시적 실시 예는 방법을 제공하고, 상기 방법은 주체(an entity)로부터 이벤트 데이터를 수신하는 단계, 상기 이벤트 데이터가 보증 정책을 만족하는지를 결정하는 단계, 상기 이벤트 데이터의 컨텍스트에 대응하는 식별자를 세트 하는 단계, 상기 이벤트 데이터 및 상기 식별자를 포함하는 이벤트를 생성하는 단계, 및 탈중앙화된 데이터베이스(a decentralized database)에 기록하기 위해 이벤트를 제출하는 단계 중 하나 또는 그 이상을 포함하고, 상기 식별자는 상기 이벤트 데이터의 컨텍스트와 대응하는 상태가 올바른지(correct)를 검증하기 위해 사용된다.
[0004] 또 다른 예시적 실시 예는 비-일시적 컴퓨터 판독 매체를 제공하며, 상기 비-일시적 컴퓨터 판독 매체는 명령들을 저장하고, 상기 명령들은 프로세서에 의해 실행되었을 때 상기 프로세서가 주체(an entity)로부터 이벤트 데이터를 수신하는 단계, 상기 이벤트 데이터가 보증 정책을 만족하는지를 결정하는 단계, 상기 이벤트 데이터의 컨텍스트에 대응하는 식별자를 세트 하는 단계, 상기 이벤트 데이터 및 상기 식별자를 포함하는 이벤트를 생성하는 단계, 및 탈중앙화된 데이터베이스(a decentralized database)에 기록하기 위해 이벤트를 제출하는 단계 중 하나 또는 그 이상을 수행하도록 하고, 상기 식별자는 상기 이벤트 데이터의 컨텍스트와 대응하는 상태가 올바른지(correct)를 검증한다.
[0005] 도 1a는 예시적인 실시예들에 따른 데이터베이스를 포함하는 시스템의 네트워크 다이어그램을 도시한다.
[0006] 도 1b는 예시적인 실시예들에 따라 데이터베이스와 함께 작동하는 컴포넌트의 다른 네트워크 다이어그램을 도시한다.
[0007] 도 1c는 예시적인 실시예들에 따라 데이터베이스와 함께 동작하는 컴포넌트의 추가 네트워크 다이어그램을 도시한다.
[0008] 도 2a는 예시적인 실시예들에 따른 예시적인 블록체인 아키텍처 구성을 예시한다.
[0009] 도 2b는 예시적인 실시예들에 따른 블록체인 트랜잭션 흐름을 예시한다.
[0010] 도 3a는 예시적인 실시예들에 따른 허가된 네트워크를 예시한다.
[0011] 도 3b는 예시적인 실시예들에 따른 다른 허가된 네트워크를 예시한다.
[0012] 도 3c는 예시적인 실시예들에 따른 무허가 네트워크를 예시한다.
[0013] 도 4는 예시적인 실시예들에 따른 시스템 메시징 다이어그램을 예시한다.
[0014] 도 5는 예시적인 실시예들에 따른 플로 다이어그램을 예시한다.
[0015] 도 6a는 예시적인 실시예들에 따른, 여기에 설명된 하나 또는 그 이상의 동작들을 수행하도록 구성된 예시적인 시스템을 예시하는 도면이다.
[0016] 도 6b는 예시적인 실시예들에 따른, 여기에 설명된 하나 또는 그 이상의 동작들을 수행하도록 구성된 다른 예시적인 시스템을 예시하는 도면이다.
[0017] 도 6c는 예시적인 실시예들에 따른 스마트 계약을 활용하도록 구성된 또 다른 예시적인 시스템을 예시한다.
[0018] 도 6d는 예시적인 실시예들에 따른 블록체인을 활용하도록 구성된 또 다른 예시적인 시스템을 예시한다.
[0019] 도 7a는 예시적 실시예들에 따른 분산 원장에 새로운 블록이 추가되는 프로세스를 예시한다.
[0020] 도 7b는 예시적 실시예들에 따른 새로운 데이터 블록의 데이터 콘텐츠를 예시한다.
[0021] 도 7c는 예시적 실시예들에 따른 디지털 콘텐츠를 위한 블록체인을 예시한다.
[0022] 도 7d는 예시적 실시예들에 따른 블록체인에서 블록의 구조를 나타낼 수 있는 블록을 예시한다.
[0023] 도 8a는 예시적인 실시예에 따른 머신 러닝(인공 지능) 데이터를 저장하는 예시적인 블록체인을 예시한다.
[0024] 도 8b는 예시적인 실시예에 따른 예시적인 양자 보안 블록체인을 예시한다.
[0025] 도 9는 예시적인 실시예들 중 하나 또는 그 이상을 지원하는 예시적인 시스템을 예시한다.
[0026] 본 명세서의 도면들에 일반적으로 설명되고 예시된 바와 같은, 본 발명의 컴포넌트들은 매우 다양한 구성들로 배열 및 설계될 수 있음을 쉽게 이해할 것이다. 따라서, 첨부된 도면들에 나타낸 바와 같은, 방법, 장치, 비-일시적 컴퓨터 판독 가능 매체 및 시스템 중 적어도 하나의 실시예들에 대한 다음의 상세한 설명은, 청구된 본 애플리케이션의 범위를 제한하려는 것이 아니라 선택된 실시예들의 대표적인 예일뿐이다.
[0027] 본 명세서 전반에 걸쳐 설명된 본 발명의 특징들, 구조들 또는 특징들은 하나 또는 그 이상의 실시 예들에서 임의의 적절한 방식으로 조합되거나 제거될 수 있다. 예를 들어, 본 명세서 전반에 걸쳐 "예시적인 실시 예들", "일부 실시 예들" 또는 기타 유사한 표현들의 사용은 실시예와 관련하여 설명된 특정 특징, 구조 또는 특성이 적어도 하나의 실시예에 포함될 수 있다는 사실을 나타낸다. 따라서, 본 명세서 전반에 걸쳐 사용된 "예시적인 실시 예들", "일부 실시 예들에서", "다른 실시 예들에서", 또는 기타 유사한 표현들은 반드시 모두 동일 그룹의 실시예들을 가리키는 것은 아니며, 설명된 특징들, 구조들, 또는 특성들은 하나 또는 그 이상의 실시예들에서 임의의 적절한 방식으로 결합되거나 제거될 수 있다. 또한, 도면들에서 엘리멘트들 간의 임의의 연결은 도시된 연결이 단-방향 또는 양-방향 화살표인 경우에도 단-방향 및/또는 양-방향 통신을 허용할 수 있다. 또한, 도면들에 도시된 모든 디바이스는 서로 다른 디바이스일 수 있다. 예를 들어, 만일 모바일 디바이스가 정보를 보내는 것으로 도시되면, 유선 디바이스가 정보를 보내기 위해 사용될 수도 있다.
[0028] 또한, 실시예들의 설명에서는 "메시지"라는 용어가 사용되었을 수 있지만, 다른 유형들의 네트워크 데이터, 예를 들어, 패킷, 프레임, 데이터그램, 등이 또한 사용될 수 있다. 또한, 특정 유형들의 메시지들 및 시그널링이 예시적인 실시예들에서 묘사될 수 있지만, 그들이 특정 유형의 메시지 및 시그널링에 제한되는 것은 아니다.
[0029] 일 실시예에서, 이 애플리케이션은, 서로 통신하는 다수 노드들을 포함하는, 분산 스토리지 시스템인 탈중앙 데이터베이스(a decentralized database) (블록체인과 같은)를 이용한다. 탈중앙 데이터베이스는 상호 신뢰할 수 없는 당사자들(mutually untrusted parties) 간에 기록들을 유지할 수 있는 분산 원장(a distributed ledger)과 유사한 추가 전용 불변 데이터 구조(an append-only immutable data structure)를 포함한다. 신뢰할 수 없는 당사자들은 여기서는 피어들(peers) 또는 피어 노드들이라고 칭한다. 각 피어는 데이터베이스 기록들의 복사본을 유지하며 단일 피어는 분산된 피어 간에 합의(consensus)에 도달하지 않고는 데이터베이스 기록들을 수정할 수 없다. 예를 들어, 피어들은 블록체인 스토리지 트랜잭션들을 검증하고(validate), 스토리지 트랜잭션들을 블록들로 그룹화하며(group), 블록들에 대해 해시 체인을 구축하기(build) 위해 합의 프로토콜을 실행할 수 있다. 이 프로세스는 일관성을 위해, 필요에 따라, 스토리지 트랜잭션들을 오더링(order)하여 원장을 형성한다. 다양한 실시 예들에서, 허가형 및/또는 무허가 블록체인(a permissioned and/or a permissionless blockchain)이 사용될 수 있다. 공공 또는 무허가(public or permission-less) 블록체인에서는, 특정 ID(identity) 없이 누구나 참여할 수 있다. 공공 블록체인들은 기본 암호화폐(native cryptocurrency)를 포함할 수 있으며 작업 증명(Proof of Work: PoW)과 같은 다양한 프로토콜들에 기초한 합의(consensus)를 사용할 수 있다. 반면에, 허가된 블록체인 데이터베이스는 자금들, 상품들, 정보들 등을 교환하는 비즈니스들과 같이 공통의 목표를 공유하지만, 서로를 완전히 신뢰하지 않는 주체들 그룹 간에 안전한 상호 작용들을 제공한다.
[0030] 이 애플리케이션은, "스마트 계약들" 또는 "체인코드들"("smart contracts" or "chaincodes")라 일컬어 지는, 그리고 분산 스토리지 체계에 맞춤으로 조정되는(tailored), 임의의 프로그래밍 가능한 논리를 작동하는 블록체인을 활용할 수 있다. 일부 경우들에서, 시스템 체인코드들이라 일컬어지는 관리 기능들 및 파라미터들을 위해 특수 체인코드들(specialized chaincodes)이 존재할 수 있다. 상기 애플리케이션은, 보증 또는 보증 정책(endorsement or endorsement policy) 이라 일컬어지는, 블록체인 데이터베이스의 변조 방지 속성(tamper-proof properties)과 노드들 간의 기본 계약을 활용하는(leverage) 신뢰할 수 있는 분산 애플리케이션들인 스마트 계약들을 추가로 이용할 수 있다. 이 애플리케이션과 연관된 블록체인 트랜잭션들은 블록체인에 커밋되기(committed) 전에 "보증(endorsed)"될 수 있지만, 보증되지 않은, 트랜잭션들은 무시된다. 보증 정책을 통해 체인코드는 보증에 필요한 피어 노드들 집합의 형태로 트랜잭션에 대한 보증인(endorser)을 명시할 수 있다. 클라이언트가 보증 정책에 명시된 피어들에 트랜잭션을 보낼 때, 그 트랜잭션을 검증하기(validate) 위해 그 트랜잭션은 실행된다. 검증 후, 그 트랜잭션들은 블록들로 그룹화된 보증된 트랜잭션들의 순서화 된 시퀀스(an ordered sequence)를 생성하기 위해 합의 프로토콜(a consensus protocol)이 사용되는 오더링 단계(an ordering phase)에 들어간다.
[0031] 이 애플리케이션은 블록체인 시스템의 통신 주체들인 노드들을 이용할 수 있다. "노드"는 다른 유형들의 다수 노드들이 동일 물리적 서버에서 실행될 수 있다는 점에서 논리적 기능을 수행할 수 있다. 노드들은 신뢰 도메인들로 그룹화되며 다양한 방식들로 노드를 제어하는 논리적 주체들과 연관된다. 노드들은, 클라이언트 또는 제출 클라이언트 노드와 같은, 다양한 유형들을 포함할 수 있고, 클라이언트 또는 제출 클라이언트 노드(submitting-client node)는 트랜잭션-호출(transaction-invocation)을 보증인(예: 피어)에게 제출하고 트랜잭션-제안들(transaction-proposals)을 오더링 서비스(예: 오더링 노드)에 브로드캐스트 한다. 다른 유형의 노드는 피어 노드이고, 피어 노드는 클라이언트가 제출한 트랜잭션들을 수신하고, 트랜잭션들을 커밋(commit) 하여, 블록체인 트랜잭션들 원장의 상태와 사본을 유지할 수 있다. 필요조건은 아니지만, 피어들도 보증인의 역할을 가질 수 있다. 오더링-서비스-노드(Ordering-service-node) 또는 오더러(orderer)는 모든 노드들에 대한 통신 서비스를 실행하는 노드이고, 트랜잭션들을 커밋하고 블록체인의 세계 상태(a world state)를 수정할 때 시스템의 각 피어 노드들에 브로드캐스트하는 것과 같은, 전달 보장(a delivery guarantee)을 구현하며, 이는 일반적으로 컨트롤 및 설정 정보를 포함하는 초기 블록체인 트랜잭션에 대한 다른 이름이다.
[0032] 이 애플리케이션은 블록체인의 모든 상태 전환들(all state transitions)의, 순서화 된, 변조-방지 기록인 원장을 활용할 수 있다. 상태 전환들은 참여 당사자들(예: 클라이언트 노드들, 오더링 노드들, 보증인 노드들, 피어 노드들 등)가 제출한 체인코드 호출들(즉, 트랜잭션들)로 인해 발생할 수 있다. 각 참여 당사자(예: 피어 노드)는 원장의 사본을 유지할 수 있다. 트랜잭션은, 생성들, 업데이트들, 삭제들 등과 같은 하나 또는 그 이상의 오퍼랜드들로서, 한 세트의 자산 키-값 쌍들(a set of asset key-value pairs)이 원장에 커밋되게 할 수 있다. 원장은 불변의 순서화 된 기록을 블록들에 저장하는 데 사용되는 블록체인(체인이라고도 함)을 포함한다. 원장은 또한 블록체인의 현재 상태를 유지하는 상태 데이터베이스도 포함한다.
[0033] 이 애플리케이션은 트랜잭션 로그 (a transaction log)인 체인(a chain)을 활용할 수 있으며, 상기 트랜잭션 로그는 해시-링크된 블록들(hash-linked blocks)로 구성되고, 각 블록은 N 트랜잭션들의 시퀀스를 포함하며, 여기서 N이 1 과 같거나 더 크다. 블록 헤더는 블록의 트랜잭션들의 해시뿐만 아니라, 이전 블록의 헤더의 해시도 포함한다. 이러한 방식으로, 원장의 모든 트랜잭션들은 순서가 지정된(sequenced) 암호화 방식으로 함께 링크될 수 있다. 따라서, 상기 해시 링크들을 파괴함이 없이 원장 데이터를 변조(tamper)하는 것은 불가능하다. 가장 최근에 추가된 블록체인 블록의 해시는 이전에 발생한 체인의 모든 트랜잭션을 나타내며, 따라서 모든 피어 노드들이 일관되고 신뢰할 수 있는 상태에 있음을 보장할 수 있다. 체인은 피어 노드 파일 시스템(예: 로컬, 연결된 스토리지, 클라우드 등)에 저장되어 블록체인 워크로드의 추가-전용 특성(the append-only nature)을 효율적으로 지원한다.
[0034] 불변 원장의 현재 상태는 체인 트랜잭션 로그에 포함된 모든 키들의 최신 값들을 나타낸다. 상기 현재 상태는 채널에 알려진 최신 키 값들을 나타내므로, 월드 상태라고도 한다. 체인코드 호출들(Chaincode invocations)은 원장의 현재 상태 데이터에 대해 트랜잭션들을 실행한다. 이들 체인 코드 상호 작용들을 효율적으로 만들기 위해, 키들의 최신 값들을 상태 데이터베이스에 저장할 수 있다. 상태 데이터베이스는 단순히 체인의 트랜잭션 로그에 대해서 인덱스 된 뷰(an indexed view)일 수 있으므로, 언제든지 체인으로부터 다시 생성될 수 있다(regenerated). 상태 데이터베이스는, 피어 노드 시작 시, 트랜잭션들이 승인되기 전에 자동으로 복구(또는 필요한 경우 생성)될 수 있다.
[0035] 이벤트(An event)는 블록체인 네트워크들 및 다른 유형들의 탈중앙화된 데이터베이스들에서 전송되는 메시지 유형 중 하나이다. 특정 조건들이 충족되면 스마트 계약의 체인코드를 사용하여 검증자(a validator)에 의해 하나의 이벤트가 생성될 수 있다. 예를 들어, 새로운 트랜잭션 블록들이 블록체인에 커밋될 때 종종 기본 이벤트(a base event)라고 하는 한 유형의 이벤트가 생성될 수 있다. 다른 유형의 이벤트들은 체인코드의 일부를 구성하거나 상태를 나타낼 수 있다. 예를 들어 커스텀 이벤트(a custom event)는 네트워크 내부 또는 외부의 주체들(entities)(예: 노드들, 사용자들, 클라이언트들, 등)에 배포하기 위해 체인코드가 지정한 특정 메시지들과 관련될 수 있다. 예를 들어, 그들의 검증자들 및/또는 네트워크 정책에 의해 결정된 대로 네트워크 이벤트들이 다양한 수준들(varying levels)의 프라이버시, 액세스 또는 제한을 갖는 것은 드문 일이 아니다. 다양한 상태 수준들을 갖는 이벤트들의 생성, 배포 및/또는 액세스를 관리하기 위해 다양한 체인코드가 사용될 수 있다.
[0036] 예시적인 실시예들은, 블록체인과 같은, 그러나 이에 제한되지 않는, 탈중앙화된 데이터베이스에 이벤트가 저장되기 전에 이벤트를 생성하고 검증하는, 방법들, 시스템들, 컴포넌트들, 비일시적 컴퓨터 판독 가능 매체, 디바이스들 및/또는 네트워크들을 제공한다. 이벤트 생성 및 검증(The event generation and validation)은 블록체인 정보 및 자산들 관리에서 컴퓨터의 기능을 개선시키는 방식으로 수행된다. 일 실시예에서, 상기 개선은 상기 데이터베이스에 의해 관리되는 객체 및/또는 네임스페이스(an object and/or namespace)에 이벤트(및 예를 들어 하나 또는 그 이상의 연관된 트랜잭션)를 결합하는(bind) 이벤트와 연관하여 저장된 새로운 정보의 추가를 통해 실현된다. 상기 새로운 정보는, 예를 들어, 키 이름 또는 키 주소(a key name or a key address)와 같은 키 정보일 수 있지만 이에 제한되지 않는, 키 정보일 수 있다.
[0037] 이벤트를 데이터베이스에 커밋하기 전에 및/또는 상기 이벤트와 관련된 데이터베이스 질의와 관련하여, 새로운 정보에 기초한 동작들(operations)을 수행함으로써, 이벤트의 검증은 상대적으로 더 많은 시간과 처리가 효율적인 방식으로 관련 트랜잭션과 함께 수행될 수 있다. 일 실시예에서, 상기 키 정보는 객체 또는 이벤트와 관련하여 미리 검증된다. 따라서, 블록체인이나 다른 데이터베이스에 기록될 이벤트(및 예를 들어 하나 또는 그 이상의 수반 트랜잭션들(attendant transactions))와 함께 상기 키 정보를 포함하면 이벤트와 관련된 필드에 존재할 때 상기 이벤트(및 트랜잭션(들))를 자동으로 검증하는 역할을 한다. 일 실시예에서, 그러한 필드는 이벤트에 포함되거나 추가될 수 있다. 이 실시예 또는 다른 실시예에서, 이벤트와 연관된 트랜잭션은 이벤트 데이터뿐만 아니라 필드를 포함하는 메시지 포맷을 포함할 수 있다. 따라서, 유효한 키 정보(예: 알려진 키 정보와 매치하는)의 존재 여부를 체크하면 검증을 수행하기 위해 데이터베이스에 있는 다른 노드들의 원장들에 질의할 필요 없이, 이벤트 및 그 것의 수반 트랜잭션(들)의 유효성을 검증할 수 있다.
[0038] 일 실시예에서, 동작들이 상태 네임스페이스(the state namespace)에서 의사 쓰기(a pseudo-write)에 이벤트를 상관시키기 위해 수행된다. 이벤트를 정의할 때 이벤트는 이벤트 생성의 유효성을 설정하는 키 정보를 포함할 수 있다. 이벤트 및 하나 또는 그 이상의 관련 트랜잭션들이 검증되면, 상기 이벤트는 해당 키 정보의 의사 쓰기로 평가될 수 있다. 해당 키에 대해 상태 수정들이 수행되지 않은 경우에도, 상기 검증은 트랜잭션이 해당 키 정보를 수정하였더라도 이벤트 및/또는 관련 트랜잭션이 여전히 유효함을 보장할 수 있다. 이는 이벤트의 소비자들(예: 노드들 및/또는 노드 클라이언트들)이 이제 이벤트가 예상되는 키 정보와 관련되었기만 한다면 이벤트를 유효한 것으로 간주할 수 있다는 이점을 갖는다. 만일 키와 그 것의 액세스가 적절하게 선택된다면, 이벤트의 유효성은 하나 또는 그 이상의 연결된 트랜잭션들의 유효성을 의미한다.
[0039] 전술한 것 외에도, 본 명세서에 기술되고 묘사된 본 발명의 솔루션들의 일부 추가적인 이점들은, 보안 관점에서, 이벤트 및 관련 트랜잭션들 및 기타 콘텐츠가 올바르다(correct)는 데이터베이스 클라이언트들(예를 들어, 청구 관리 애플리케이션에서 소비자들)에 대한 보증들을 포함하며, 다만 이 경우에도 이벤트와 연관된 트랜잭션들/콘텐츠는 적절하게 보증되었고(endorsed) 보증 정책이 적절하게 세트 되었다고(예를 들어, 보증 정책이 올바르지 않은 경우도, 모든 원장 키의 정확성에 관한 클레임은 할 수 없다고) 가정한다. 본 명세서에 기술된 실시예들에 의해 제공되는 키 정보 및 그에 수반되는 동작들을 사용하여서, 만일 데이터베이스 사용자가(예를 들어, 클라이언트 애플리케이션을 통해) 이벤트의 정확성을 확인하고자 한다면, 사용자는, 이벤트의 조건 또는 기타 콘텐츠가 실제로 참인지를 충분한 수의 피어 노드들로부터 확인하기 위해, 이벤트를 수신한 후 질의에 의존해야 할 수 있다.
[0040] 도 1a는 이벤트에 대응하는 데이터가 생성되어 탈중앙화된 데이터베이스에 기록되기 전에 이벤트가 올바른지 검증하기 위한 시스템(100)의 예시적인 실시예의 논리도를 도시한다. 예시를 위해, 탈중앙화된 데이터베이스는 블록체인으로 논의될 것이다. 그러나, 다른 실시예에서는 다른 유형의 데이터베이스가 사용될 수도 있다.
[0041] 도 1a를 참조하면, 시스템(100)은 클라이언트(또는 클라이언트 애플리케이션)(110)에 결합된 노드(N1)(120)와 같은 네트워크 주체를 포함한다. 클라이언트(110)는, 예를 들어, 유선 또는 무선 네트워크 또는 기타 통신 경로를 포함할 수 있는, 통신 링크를 통해 노드(120)로 전송되는 이벤트 데이터(115)를 생성할 수 있다. 상기 이벤트 데이터는 모든 형식의 정보를 포함할 수 있지만, 특히 블록체인의 의도된 애플리케이션과 관련될 수 있다. 아래에서 더 자세히 논의되는 하나의 비제한적인 예에서, 상기 이벤트 데이터는 하나 또는 그 이상의 네트워크 주체들의 고객들에 대한 청구 정보를 포함한다. 이 경우에, 네트워크 주체들은 예를 들어 동일한 회사 또는 다양한 회사들에 속할 수 있다. 일 실시예에서, 클라이언트(110)는 노드(120)에 전달되기 전에 이벤트 데이터 및/또는 하나 또는 그 이상의 연관된 트랜잭션들을 암호화할 수 있다. 대응 암호 해독(예: 키) 정보가 블록체인 네트워크의 하나 또는 그 이상의 다른 노드들 또는, 예를 들어, 블록체인 질의로부터 생성된 이벤트들에 액세스하기 위한 암호 해독을 수행하는 데 사용될 수 있는 관련 클라이언트에 위치할 수 있다. 노드(120)는 탈중앙화된 데이터베이스의 복수의 노드들 중 하나일 수 있다. 일 실시예에서, 노드(120)는 이벤트 및 트랜잭션을 블록체인에 커밋하기 전에 이벤트 및/또는 트랜잭션 검증을 수행하는 피어 노드일 수 있다.
[0042] 도 1a에 도시된 바와 같이, 노드(120)는 프로세서(122) 및 상기 프로세서에 의해 실행될 스마트 계약의 체인코드를 저장하는 스토리지 영역(124)을 포함한다. 작동 중에, 상기 프로세서는 클라이언트(110)로부터 이벤트 데이터를 수신한 다음 상기 이벤트 데이터를 보증 정책(125)과 비교한다. 만일 보증 정책의 조건들 또는 요건들이 충족되면, 프로세서(122)는 스마트 계약의 체인코드를 실행하여 이벤트를 생성한다. 상기 이벤트는 단독으로, 또는 관련된 하나 또는 그 이상의 트랜잭션들과 함께, 블록체인에 대한 합의 및 커밋을 위해 제출될 수 있다. 일 실시예에서, 각각의 이벤트 또는 연관된 트랜잭션들은 블록체인 데이터베이스에서 관리되는 동일 또는 상이한 객체와 관련될 수 있다. 일부 경우들에서, 이벤트들 및 관련 트랜잭션들이 해당 개체의 다양한 상태들을 나타낼 수 있다. 따라서, 블록체인은 연관된 트랜잭션들과 함께 이벤트들을 저장할 수 있으며, 각 이벤트의 콘텐츠는 연관된 개체의 다른 상태(또는 상태의 변경)를 나타낼 수 있다. 네임스페이스 기반으로 키 정보를 생성하기 위해, 노드(120)(및 실제로 블록체인 네트워크의 하나 또는 그 이상의 다른 노드들)는 네임스페이스 논리(126)를 포함할 수 있다.
[0043] 도 1b는 시간 경과에 따라 블록체인에 기록된 일련의 트랜잭션들(1701 내지 170N) 간의 논리적 관계(150)의 예를 도시한다. 이 예에서, 모든 트랜잭션들은 동일한 객체 또는 네임스페이스(190)와 관련되어 있다. 청구 애플리케이션(a billing application)에서, 객체(190)는 노드(120)에 의해 수신된 이벤트 데이터에 대응하는 고객 청구서의 상태(the state of a customer bill)에 대응할 수 있다. 이 경우에, 클라이언트(110)는 상품들 및/또는 서비스들에 대해 청구하는 은행, 신용 카드 회사, 공공서비스 회사(utility company) 또는 다른 주체일 수 있다.
[0044] 도 1b를 참조하면, 트랜잭션들(1701 내지 170N) 중 하나 또는 그 이상은 클라이언트(110)로부터 수신된 이벤트 데이터의 다양한 항목들에 기초하여 노드(120)의 프로세서에 의해 생성된 대응 이벤트들과 연관될 수 있다. 이 예에서, 이벤트(E1)(1801)는 연관된 트랜잭션(T1)(1701)에 대응하고, 이벤트(E2)(1802)는 연관된 트랜잭션(T2)(1702)에 대응하는 식이다. 각 이벤트는 객체(또는 관련 트랜잭션)의 상태를 나타낼 수 있다. 이벤트들은 도 1b의 트랜잭션들로부터 구별되는(distinct) 것으로 도시되어 있지만, 일 실시예에서 이벤트들(또는 이벤트 데이터)는 트랜잭션 또는 이벤트 포맷의 첨부된 또는 추가의 필드에 포함될 수 있다. 예를 들어, 도 1c에 예시된 일 실시예에서, 각각의 트랜잭션 또는 이벤트의 포맷(195)은 이벤트 데이터를 나타내는 정보를 포함하는 제1 필드(196), 본 명세서에 기술된 하나 또는 그 이상의 실시예들에 따라 개선된 검증을 위해 사용될 수 있는 이벤트 키 정보를 포함하는 제2 필드(197), 및 트랜잭션 정보를 포함하는 제3 필드(198)를 포함하는 메시지 구조를 가질 수 있다.
[0045] 트랜잭션들 및 이벤트들 간의 하나의 가능한 관계는 다음 예에 따라 이해될 수 있다. 객체(190)가 고객 X에 대한 청구서를 나타낼 때, 이벤트(E1)(1801)는 고객 X에 대한 청구서가 생성된 상태를 나타낼 수 있다. 연관된 트랜잭션(T1)(1701)은, 예를 들어, 청구 금액을 나타낼 수 있다. 이벤트(E2)(1802)는 청구서의 다른 상태를 나타낼 수 있다. 예를 들어, 이벤트(E2)는 청구서에 대한 첫 번째 기한(the first due date)이 만료되었음을 나타내는 트랜잭션(T2)(1702)에 대해 청구서가 지불되지 않은 상태를 나타낼 수 있다. 하나 또는 그 이상의 후속 트랜잭션들은 다양한 추가의 상태 변경들 및 관련 트랜잭션들을 반영할 수 있다. 예를 들어, 이벤트(EN)(180N)은 고객 X에 대한 청구서가 지불되었음을 나타낼 수 있고 그 것의 관련 트랜잭션(TN)(170N)은 청구서에 연체료(a late fee)가 추가되었음을 나타낼 수 있다. 따라서, 블록체인 원장에 대해 네트워크에 의해서 관리되는 동일한 객체에 대한 이벤트들과 연관된 트랜잭션들을 기록할 수 있다.
[0046] 일 실시예에서, 상기 객체는 블록체인 네트워크의 상태 네임스페이스(a state namespace)와 연관될 수 있다. 상기 네임스페이스는 하이퍼레저 패브릭(Hyperledger Fabric)의 프라이빗 데이터 컬렉션들과 같은, 스마트 계약의 글로벌 네임스페이스와 다른 검증 규칙들을 갖는 상태 공간의 파티션일 수 있다. 상기 네임스페이스는, 하이퍼레저 패브릭(Hyperledger Fabric)의 상태-기반 보증 또는 다른 블록체인 시스템들의 토큰들과 같은, 자체 검증 규칙들을 갖는 단일 키일 수도 있다.
[0047] 도 1a에 도시된 바와 같이, 사기(fraud)를 방지하고 블록체인에 저장된 정보의 유효성을 보장하기 위해, 프로세서(122)에 의해 실행되는 스마트 계약의 체인코드는 검증, 예를 들어, 이벤트가 올바르다는 또는 그렇지 않으면 진본이고(authentic) 유효하다는 확인을 위해 사용되는 추가 필드를 포함하는 이벤트를 생성할 수 있다. 이것은, 예를 들어, 객체에 연결된 정보(예: 식별자)를 생성하기 위해 스마트 계약(124)의 체인코드를 실행하는 상기 프로세서에 의해 수행될 수 있다. 이 식별자는, 예를 들어, 네트워크 기관(a network authority)에 의해 생성되고 객체(또는 네임스페이스)와 함께 사용하기 위해 사전-승인될 수 있다. 따라서, 상기 식별자는 이벤트에 연결되는 것만으로 이벤트를 검증하기 위한 기초로서 역할을 할 수 있으므로, 이에 의해 이벤트의 콘텐츠(및 그 것의 연관된 트랜잭션)가 올바른지를 결정하기 위해 블록체인에서 피어 노드들의 원장들에 질의할 필요성을 완화한다. 도 1의 예시적인 이벤트 또는 트랜잭션 포맷에서, 상기 식별자는, 이벤트 검증 목적을 위해 예약된 새로 생성된 필드인, 제2 필드(197)에 포함될 수 있다.
[0048] 일단 식별자가 세트되 면(예를 들어, 미리 저장된 정보에 액세스하거나 네트워크 기관으로부터 직접 획득되면), 프로세서(122)는 검증을 위해 사용되는 제2 필드에 상기 식별자를 삽입할 수 있다. 적어도 이러한 방식으로, 상기 프로세서는 이벤트가 블록체인에 대한 합의 및 커밋을 위해 생성되기 전에 이벤트의 유효성을 검증하는 데 사용될 수 있는 이벤트(또는 트랜잭션)의 전용 필드에 정보를 미리 저장하는 것과 관련된 의사 쓰기 동작(a pseudo-write operation)을 수행하는 것으로 간주될 수 있다. 이벤트에서 식별자를 생성하고 삽입하면(또는 달리 연관시키면), 적어도 피어 노드들 및 전체 관리 네트워크 주체들의 처리 오버헤드를 줄이는 측면에서, 블록체인을 관리하는 컴퓨터의 효율성을 향상시킬 수 있다.
[0049] 일 실시예에서, 이벤트의 새로운 제2 필드에 저장된 정보는 이벤트가 연관된 객체에 링크될 수 있다. 예를 들어, 일 실시예에서 이벤트/트랜잭션의 제2 필드에 의사-기록되는 생성된 식별자는 이벤트에 대응하는 특정 객체에 대해 미리 생성된 키 정보를 포함할 수 있다. 키 정보가 객체에 대해 이미 검증되었기 때문에(예: 네트워크 기관에 의해), 이벤트(및 그 것의 연관된 트랜잭션)는 키 정보가 이벤트와 연관되어 있음을 확인함으로써 검증될 수 있다. 이렇게 하면 블록체인에 추가될 새로운 블록에 트랜잭션을 커밋하기 전에 이벤트 및 그 것의 연관된 트랜잭션을 검증하기 위해 블록체인 노드의 원장에 질의할 필요가 완화된다. 따라서, 키 정보는 키 정보에 기초하여 검증 또는 권한 부여(authorization)를 수행하도록 프로그램 된 권한 부여 메커니즘 또는 검증 기관에 이벤트를 효과적으로 바인드 하는 역할을 할 수 있다. 일 실시예에서, 키 정보는 객체에 할당된 키 이름(a key name)을 포함할 수 있다. 다른 실시예에서, 키 정보는 객체에 할당된 키 주소를 포함할 수 있다. 또 다른 실시예에서, 프로세서는 클라이언트(110)에 의해 수신된 이벤트 데이터에 기초하여 이벤트의 생성을 인가하기 위해 객체와 연관된 다른 유형의 식별 정보를 생성할 수 있다. 키 정보는 이벤트 또는 트랜잭션 포맷의 추가 필드에 삽입하기 전에 하나 또는 그 이상의 보안 기능들(예: 다양한 형태의 암호화)로 인코드 될 수 있다.
[0050] 일 실시예에서, 프로세서(122)에 의해 구현된 스마트 계약의 체인코드는 네임스페이스 기반으로 이벤트 승인을 위한 키 정보를 생성하도록 프로그램 될 수 있다. 각 네임스페이스는 다른 네임스페이스들에 대응하는 객체들과 다를 수 있는 복수의 대응 객체들을 가질 수 있으며, 이들 객체들 각각은, 예를 들어, 블록체인의 의도된 애플리케이션에 따라, 하나 또는 그 이상의 대응 트랜잭션들 및/또는 이벤트들을 가질 수 있다.
[0051] 네임스페이스 기반으로 키 정보를 생성하기 위해, 노드(120)(및 실제로 블록체인 네트워크의 하나 또는 그 이상의 다른 노드들)는 네임스페이스 로직(126)을 포함할 수 있다. 그러한 로직은, 예를 들어, 하이퍼레저 소투쓰(Hyperledger Sawtooth) 플랫폼과 같은, 그러나 이에 국한되지 않는, 블록체인 플랫폼의 일부일 수 있다. 네임스페이스 로직(126)은 관련되지 않은 트랜잭션들, 예를 들어, 동일한 객체에 관련되지 않은 트랜잭션들 사이에 분리를 제공하기 위해 이벤트의 생성을 승인하도록 노드(120)에 의해 사용될 수 있다. 예를 들어, 노드(120)는 네임스페이스 로직(126)을 포함할 수 있으며, 네임스페이스 로직(126)은 글로벌 상태 저장소(a global state store)를 사용하고 상기 저장소가 다양한 네임스페이스들로 분리되도록 하며, 각각의 네임스페이스는 객체들의 분리된 범주에 대응한다. 하나의 비제한적 예에서, 각 네임스페이스는 다양한 고객들에 대응할 수 있으며 각 네임스페이스에 대응하는 이벤트들은 이들 고객들에게 발행된 청구서들에 대응할 수 있다.
[0052] 노드(120)가 네임스페이스 로직을 포함할 때, 각각의 네임스페이스에서 각각의 객체에 대해 다양한 키 정보가 미리 생성될 수 있다. 일 실시예에서, 동일 네임스페이스에 대응하는 다수의 객체들에 대해 동일 키 정보가 생성될 수 있다. 어느 경우든, 키 정보는 연관된 객체에 대응하는 이벤트들 및/또는 트랜잭션들과 관련하여 사용하기 위해 미리 검증되고 승인될 수 있다. 이러한 방식으로, 승인을 위해 노드(120)에 의해 발생된 이벤트 및 블록체인에서의 후속 기록이 이벤트에 대응하는 객체에 할당된 적절한 대응 키 정보를 갖는지를 확인함으로써 이벤트 승인이 수행될 수 있다. 그 결과, 이벤트 승인을 수행하기 위해 블록체인의 노드들의 원장들에 질의하는 비효율적인 처리가 방지될 수 있으며, 이에 의해, 컴퓨터가 블록체인 트랜잭션들의 이벤트 생성, 승인, 합의 및 커밋 그리고 동일한 노드 또는 다른 노드에 의해서 블록체인에 질의할 때 트랜잭션 및 그 것의 연관된 이벤트를 검증하는 것과 관련된 후속 동작들을 관리하는 것과 관련하여 컴퓨터의 동작을 개선할 수 있다.
[0053] 전술한 특징들에 따라, 노드(120)는 본 명세서에 기술된 하나 또는 그 이상의 실시예들을 구현함에 있어서 다음과 같이 동작할 수 있다. 클라이언트(110)로부터 이벤트 데이터를 수신하면, 프로세서(122)는 객체 및/또는 상기 객체에 대응하는 네임스페이스에 대응하는 키 정보를 포함하는 이벤트(또는 트랜잭션 포맷)에 새로운(이벤트 검증) 필드를 추가로 세트 함으로써 새로운 이벤트를 발생시킨다. 전술한 바와 같이, 방출된 이벤트는 이벤트가 의사-쓰기를 수행하고 있는 트랜잭션에 대응하는 상태를 나타내는 정보를 포함할 수 있다. 플랫폼 검증 코드(예를 들어, 스마트 계약의 체인코드에 포함된)는 하나 또는 그 이상의 대응 트랜잭션을 검증할 때 새로운(이벤트 검증) 필드의 키 정보를 검사한다.
[0054] 일부 경우들에서, 발생된 이벤트와 연관된 트랜잭션은 키 정보를 수정했을 수 있다. 그럼에도 불구하고, 새로운 필드에 키 정보를 저장하면 트랜잭션이 수정되더라도, 예를 들어, 노드(120) 또는 플랫폼 검증 코드에 의해 참조되는 키 정보(이 트랜잭션이 실제로 수행하는 모든 수정에 더하여)는 여전히 유효한 것으로 간주됨이 보장된다.
[0055] 이어서, 클라이언트 애플리케이션(예를 들어, 블록체인 네트워크에서 클라이언트(110), 노드(120)의 다른 클라이언트 또는 다른 노드의 클라이언트에 대응하는)이 블록체인 내의 블록으로부터 트랜잭션 이벤트를 검색하기 위한 질의를 수행할 때, 상기 클라이언트 애플리케이션은 상기 트랜잭션 이벤트의 이벤트 검증 필드에 저장된 키 정보에 기초하여 비교를 수행함으로써 트랜잭션 이벤트의 유효성(또는 정확성)을 검증할 수 있다. 예를 들어, 클라이언트 애플리케이션은 검색된 트랜잭션 이벤트와 연관된 특정 객체(및/또는 네임스페이스)에 대한 키 정보를 획득하거나 또는 기록했기 때문에, 클라이언트 애플리케이션은 검색된 트랜잭션 이벤트의 필드에 저장된 키 정보를 상기 객체(또는 네임스페이스)에 대한 알려진 키 정보와 비교할 수 있다. 만일 매치가 있다면, 클라이언트 애플리케이션은 블록체인 네트워크에 있는 다른 노드들의 원장들에 질의할 필요 없이 트랜잭션 이벤트가 유효하다고 결정한다. 만일 매치가 없다면, 클라이언트 애플리케이션은 블록체인에 기록된 트랜잭션 이벤트가 사기(fraudulent)(예: 악의적인 공격자로부터의)이거나 신뢰할 수 없다고 결정할 수 있다.
[0056] 이들 실시예들의 예시적인 시나리오는 청구 애플리케이션(a billing application)이다. 예를 들어, 만일 노드(120)의 프로세서(122)에 의해 실행되는 스마트 계약이 고객의 특정 청구서(객체)가 전액 지불되었다는 상태를 나타내는 이벤트를 방출한다면, 이벤트는 상기 청구서를 참조하는 키 정보 참조 필드(a field referencing key information)로 보강될 수 있다. 이 경우 "청구서 완납" 이벤트는 연관된 트랜잭션(예: 청구서 지불을 위한 자금 이체)이 고객에 의해서 및/또는 다른 당사자들(예: 신용카드 회사)에 의해 상기 청구서의 이벤트 상태를 수정할 권한(authority)으로 승인된 경우에만 유효한 것으로 간주될 수 있다. 이벤트 상태의 유효성은 이벤트의 추가 필드에 저장된 키 정보(또는 트랜잭션 메시지 포맷)에 기초하여 확인될 수 있다.
[0057] 일부 경우들에서, 전술한 예시 시나리오에서 트랜잭션 자체는 키 정보가 수정되게 할 수 있다. 예를 들어, 청구서의 이벤트 상태를 "미지급"에서 "전액 지불"로 업데이트하면 많은 키들 세트가 수정될 수 있으며, 키들 모두가 청구서 지불 승인을 위해 동등한 보증을 예측하거나 요구하는 것이 쉽지 않다. 그러나 청구서의 지불 상태를 나타내는 키와 같은, 이들 키들의 일부는 유효한 트랜잭션에서 수정되어야 하므로, 따라서 청구서 수정하도록 승인된 주체에 의해 보증되어야 한다. 이벤트를 키 정보에 바인딩함으로써, 전체 지불을 확인하려는 블록체인으로부터 정보를 검색하는 클라이언트 애플리케이션은 이벤트를 생성한 노드(120)에서 스마트 계약의 상태 메커니즘의 서브세트를 결정하기만 하면 된다. 이는 고객 정보의 프라이버시와 보안을 유지하는 동시에 클라이언트 애플리케이션이 청구서 지불의 유효성을 확인하기 위해 요청한 정보를 획득할 수 있도록 하는 유익한 효과를 가질 수 있다.
[0058] 키 정보가 없다면, 클라이언트 애플리케이션은, 블록체인에 커밋하기 전과 클라이언트 애플리케이션에 의한 블록체인 질의 후 검증 동안, 안전하지 않은 방식으로(이벤트 검증을 모두 수행하지 않고) 작동해야 하거나 이벤트를 검증하기 위해 시간 및 처리 비효율적인 작업을 최소한 수행해야 한다. 예를 들어, 클라이언트는 이벤트가 적절하게 생성되었는지 확인하기 위해 원장 상태에 대한 왕복 질의(a round-trip query)를 만들어야 한다. 더욱이, 본 명세서에 기술된 실시예들의 이벤트-키-바인딩 접근법(the event-key-binding approach) 없이, 청구서를 지불하지 않은 공격자는 유효한 트랜잭션을(예를 들어, 아마도 관련되지 않은 더 작은 청구서를 지불하는) 발행할 수 있지만, 다른 더 큰 청구서기 지불되었음을 나타내는 이벤트를 첨부할 수 있다. 이벤트를 수신할 때, 애플리케이션은 (a) 트랜잭션의 상태 수정들을 검사하고 상태 수정들이 이벤트 콘텐츠와 대응하는지 확인하려고 시도하고(이 접근 방식은 깨지기 쉽고 오류가 발생하기 쉽다), (b) 이벤트 콘텐츠가 올바른지 확인하기 위해 청구서의 상태를 물어보려고 원장으로 즉시 왕복 여행을 하며(비용이 많이 들고 오류가 발생하기 쉬움), 또는 (c) 액면가(face value)로 이벤트를 수락하고 공격에 굴복한다. 본 발명의 실시예들의 이벤트-바인딩을 도입함으로써, 클라이언트 애플리케이션은, 예를 들어 새로운 이벤트 필드에서 매치하는 키 정보에 기초하여 추가 검증 체크를 수행하는 접근법(c)을 선택하고 보안을 유지할 수 있다.
[0059] 도 2a는 예시적인 실시예들에 따른, 블록체인 아키텍처 구성(200)을 도시한다. 도 2a에 도시된 바와 같이, 블록체인 아키텍처(200)는 특정 블록체인 엘리멘트들, 예를 들어, 블록체인 노드들(202)의 그룹을 포함할 수 있다. 블록체인 노드들(202)은 하나 또는 그 이상의 노드들(204-210)을 포함할 수 있다(이 4개의 노드들은 예시적으로만 도시됨). 이러한 노드들은, 블록체인 트랜잭션 추가 및 검증 프로세스(합의)와 같은 여러 활동들에 참여한다. 블록체인 노드들(204-210) 중 하나 또는 그 이상은 보증 정책에 기초하여 트랜잭션들을 보증할 수 있고 아키텍처(200)의 모든 블록체인 노드들에 대해 오더링 서비스를 제공할 수 있다. 블록체인 노드는 블록체인 인증(authentication)을 시작하고 블록체인 계층(216)에 저장된 블록체인 불변 원장에 기록하려고 할 수 있으며, 그 사본은 기반 물리적 하부구조(the underpinning physical infrastructure)(214)에도 저장될 수 있다. 블록체인 구성은 맞춤형 애플리케이션에 따라 생성될 수 있는 저장된 프로그램/애플리케이션 코드(220)(예를 들어, 체인코드, 스마트 계약들 등)에 액세스하고 실행하기 위해 애플리케이션 프로그래밍 인터페이스들(APIs)(222)에 연결된 하나 또는 그 이상의 애플리케이션들(224)을 포함하며, 참가자들이 원하는 구성으로 자신의 상태들을 유지하고 자신의 자산을 컨트롤하며 외부 정보를 수신할 수 있다. 이것은 트랜잭션으로 배포되고, 분산 원장에 추가하는 것을 통해, 모든 블록체인 노드들(204-210)에 설치될 수 있다.
[0060] 블록체인 기반 또는 플랫폼(212)은 블록체인 데이터의 다양한 계층들, 서비스들(예: 암호화 신뢰 서비스들, 가상 실행 환경, 등) 및 기반 물리적 컴퓨터 하부구조를 포함하는데, 이는 새로운 트랜잭션들을 수신하고, 저장하며, 그리고 데이터 항목에 액세스하려고 감사자들(auditors)에게 액세스를 제공하는 데 사용될 수 있다. 블록체인 계층(216)은 프로그램 코드를 처리하고 물리적 하부구조(214)를 참여시키는 데 필요한 가상 실행 환경에 대한 액세스를 제공하는 인터페이스를 익스포즈(expose)할 수 있다. 암호화 신뢰 서비스들(218)은 자산 교환 트랜잭션들과 같은 트랜잭션들(예: 자산 교환 트랜잭션들)을 확인하고 정보를 비공개(private)로 유지하는 데 사용될 수 있다.
[0061] 도 2a의 블록체인 아키텍처 구성은, 블록체인 플랫폼(212)에 의해서, 제공된 서비스들 및 익스포즈된 하나 또는 그 이상의 인터페이스를 통해, 프로그램 /애플리케이션 코드 (220)를 처리 및 실행할 수 있다. 코드(220)는 블록체인 자산들을 컨트롤 할 수 있다. 예를 들어, 코드(220)는 데이터를 저장 및 전송할 수 있고, 조건들 또는 실행 대상이 되는 다른 코드 엘리멘트들을 갖는, 스마트 계약 및 연관된 체인코드의 형태인 노드들(204-210)에 의해 실행될 수 있다. 비-제한적인 예로서, 스마트 계약들이, 변경들, 업데이트들, 등의 대상인, 리마인더들(reminders), 업데이트들, 및/또는 기타 통지들을 실행하기 위해서, 생성될 수 있다. 스마트 계약들 그 자체는, 권한 부여(authorization)와 액세스 요건들 및 원장의 사용과 관련된 규칙들을 식별하기 위해, 사용될 수 있다. 예를 들어, 정보(226)는 클라이언트 애플리케이션, 노드 또는 다른 네트워크 주체로부터 수신된 이벤트 데이터를 포함할 수 있다. 상기 이벤트 데이터는 이벤트를 생성하고 검증하기 위해 수신 노드에 의해 기초로 사용될 수 있다. 이벤트 생성 및 검증은 수신 노드에 의해 구현된 스마트 계약의 체인코드를 포함할 수 있는 로직을 사용하여 수행될 수 있다. 상기 체인코드는, 예를 들어, 애플리케이션(224)에 포함될 수 있거나 애플리케이션(224)과 별개일 수 있다. 스마트 계약 및/또는 애플리케이션(224)은 블록체인 층(216)에 포함된 하나 또는 그 이상의 처리 주체들(하나의 경우, 예를 들어 가상, 머신)에 의해 실행될 수 있다.
[0062] 다른 동작들 수행 중에, 스마트 계약의 체인코드는, 예를 들어, 데이터베이스 네트워크의 기존 보증 정책에 기초하여, 이벤트를 생성하고 검증할 수 있다. 일 실시예에서, 상기 스마트 계약은 수신된 이벤트 데이터와 연관된 데이터베이스 객체(예를 들어, 청구서) 및/또는 네임스페이스를 결정할 수 있다. 그런 다음, 노드는 보증 정책의 조건에 따라 이벤트(및 수반되는 트랜잭션(들))를 보증하고 검증할 수 있다. 만일 보증 및 검증 조건들(예를 들어 이벤트 데이터의 콘텐츠 및/또는 데이터베이스의 의도된 애플리케이션에 따라 다를 수 있는) 이 충족된다면, 노드는 이벤트에 디지털 서명을 하고, 예를 들어, 이벤트가 블록체인에 커밋되는 것을 포함하여, 네트워크 전체에 걸쳐 이벤트를 내보내도록 승인할 수 있다.
[0063] 일 실시예에서, 보증은 데이터베이스 네트워크에 의해 관리되는 객체 또는 미리 결정된 네임스페이스와 연관되는 이벤트 데이터에 근거할 수 있다(predicated). 예를 들어, 이벤트 데이터를 수신하는 노드의 스마트 계약은 네트워크에 의해서 관리되는 알려진 개체 및/또는 네임스페이스에 대해서 데이터의 콘텐츠를 체크할 수 있다. 만일 매치가 있다면, 스마트 계약은 상기 객체 또는 네임스페이스와 관련하여 저장된 키 정보를 검색한 다음 키 정보를 저장하기 위해 새로운 필드를 포함하는 대응 이벤트를 생성할 수 있다. 이벤트에 키 정보를 포함하면 이벤트의 콘텐츠(예를 들어, 이벤트와 연관된 모든 상태 변경 또는 트랜잭션을 포함하는)가 올바르고(correct) 유효하다(valid)는 것을 보장할 수 있다.
[0064] 결과(228)는 스마트 계약에 의해 생성된 키 정보를 포함하는 새로운 필드와 함께 현재 보증되고 검증된 이벤트를 포함할 수 있다. 이벤트는 하나 또는 그 이상의 연관된 트랜잭션들과 함께 또는 하나 또는 그 이상의 연관된 트랜잭션들없이 출력될 수 있다. 이 이벤트(및 연관된 트랜잭션(들))는 합의를 위해 블록체인 네트워크에 출력되고 이후 블록체인의 새로운 블록에 커밋될 수 있다. 일 실시예에서, 이벤트는 블록체인 네트워크의 다른 노드들에 알림으로 전송될 수 있다. 일단 블록체인에 커밋되면, 노드들(예: 피어 노드들 204, 206, 208, 210 등)와 통신하는 클라이언트 애플리케이션들이 블록체인에 이벤트에 대해 질의할 수 있다. 따라서, 새로운 필드에 포함된 키 정보는 이벤트의 컨텐츠 및 연관된 모든 트랜잭션들이 올바른지 자동으로 검증하는 기능을 수행할 수 있다. 물리적 하부구조(214)는 본 명세서에 기술된 모든 데이터 또는 정보를 검색하기 위해 이용될 수 있다.
[0065] 여기서 기술된 스마트 계약들은 고급 애플리케이션 및 프로그래밍 언어를 통해 생성된 후, 블록체인의 블록에 기록될 수 있다. 스마트 계약은 블록체인(예: 블록체인 피어들의 분산 네트워크)에 등록, 저장 및/또는 복제되는 실행 가능 코드를 포함할 수 있다. 트랜잭션은 스마트 계약과 관련된 조건들이 충족되는 경우 수행될 수 있는 스마트 계약 코드의 실행이다. 스마트 계약의 실행은 디지털 블록체인 원장의 상태에 대해 신뢰할 수 있는 수정(들)을 발생시킬(trigger) 수 있다. 스마트 계약 실행에 의해서 발생된 블록체인 원장의 수정(들)은 하나 또는 그 이상의 합의 프로토콜들을 통해 블록체인 피어들의 분산 네트워크 전체에 자동으로 복제될 수 있다.
[0066] 스마트 계약은 키-값 쌍들의 형식으로(in the format of key-value pairs) 블록체인에 데이터를 쓸 수 있다(write). 또한, 스마트 계약 코드는 블록체인에 저장된 값들을 읽고 애플리케이션 연산들(application operations)에 사용할 수 있다. 스마트 계약 코드는 다양한 논리 연산들의 출력을 블록체인에 쓸 수 있다. 상기 코드는 가상 머신 또는 기타 컴퓨팅 플랫폼에서 임시 데이터 구조를 생성하는 데 사용될 수 있다. 블록체인에 기록된 데이터는 공개(public)될 수 있고 및/또는 암호화되어 비공개(private)로 유지될 수 있다. 스마트 계약에 의해 사용/생성된 임시 데이터는 제공된 실행 환경에 의해 메모리에 보관되었다가, 블록체인에 필요한 데이터가 식별되면 삭제된다.
[0067] 체인코드는, 추가 기능들과 함께, 스마트 계약의 코드 해석(예: 로직)을 포함할 수 있다. 여기에 설명된 바와 같이, 체인코드는 컴퓨팅 네트워크에 배치된 프로그램 코드일 수 있으며, 여기서 합의 프로세스 동안 체인 검증자들(chain validators)에 의해서 함께 실행 및 검증된다. 체인코드는 해시를 수신하고 이전에 저장된 기능 추출기(feature extractor)의 사용에 의해서 생성된 데이터 템플릿과 연결된 해시를 블록체인으로부터 검색한다. 만일 해시 식별자의 해시들과 저장된 식별자 템플릿 데이터에서 생성된 해시가 일치하면(match), 체인코드는 요청된 서비스에 인증 키(an authorization key)를 보낸다. 체인코드는 암호화 세부 정보들과 관련된 블록체인 데이터에 쓸 수 있다.
[0068] 도 2b는 예시적인 실시예에 따른 블록체인의 노드들 사이의 블록체인 트랜잭션 플로(250)의 예를 도시한다. 도 2b를 참조하면, 트랜잭션 플로는 애플리케이션 클라이언트 노드(260)에 의해 보증 피어 노드(281)로 전송된 트랜잭션 제안(291)을 포함할 수 있다. 보증 피어(281)는 클라이언트 서명을 확인하고(verify) 트랜잭션을 개시하기 위해 체인코드 함수를 실행할 수 있다. 출력은 체인코드 결과들, 체인코드에서 읽혀 진 키/값 버전 세트(읽기 세트), 체인코드에서 쓰여 진 키들/값들 세트(쓰기 세트)를 포함할 수 있다. 제안 응답(292)은, 승인된 경우, 보증 서명과 함께 클라이언트(260)로 다시 전송된다. 클라이언트(260)는 보증들을 트랜잭션 페이로드(a transaction payload)(293)로 취합해서(assemble) 그것을 오더링 서비스 노드(284)에 브로드캐스트 한다. 오더링 서비스 노드(284)는 정렬된 트랜잭션들을 채널의 모든 피어들(281-283)에 블록들로서 전달한다. 블록체인에 커밋하기 전에, 각 피어(281-283)는 트랜잭션을 검증할 수 있다. 예를 들어, 피어들은 명시된 피어들의 올바른 할당(the correct allotment of the specified peers)이 결과들에 서명하고 트랜잭션 페이로드(293)에 대해 서명들을 인증하였음을 보장하기 위해 보증 정책을 체크할 수 있다.
[0069] 다시 도 2b를 참조하면, 클라이언트 노드(260)는 보증인인 피어 노드(281)에 대해 요청을 구축하고 전송함으로써, 트랜잭션(291)을 개시한다. 클라이언트(260)는, 트랜잭션 제안을 생성하기 위해 이용 가능한 API를 활용하는, 지원된 소프트웨어 개발 키트(SDK)를 이용하는 애플리케이션을 포함할 수 있다. 제안은 체인코드 함수를 호출하여 데이터를 원장에서 읽고/원장에 쓰라는(즉, 자산들을 위해 새로운 키 값 쌍을 쓰라는) 요청이다. SDK는 트랜잭션 제안을 적절하게 설계된 형식(예: 원격 절차 호출(RPC)을 통한 프로토콜 버퍼)으로 패키징하고 트랜잭션 제안에 대한 고유한 서명을 생성하기 위해 클라이언트의 암호화 자격 증명들(the client's cryptographic credentials)을 가져오는 심(a shim) 역할을 수행할 수 있다.
[0070] 응답으로, 보증 피어 노드(281)는 (a) 트랜잭션 제안이 잘 형성되었는지, (b) 트랜잭션이 과거에 이미 제출되지는 않았는지(재생-공격 보호), (c) 서명이 유효한지, 그리고 (d) 제출자(예에서 클라이언트(260))는 해당 채널에서 제안된 연산을 수행하도록 적절하게 승인되었는지를 확인할 수 있다. 보증 피어 노드(281)는 트랜잭션 제안 입력을 호출된 체인코드 함수에 대한 아규먼트들(arguments)로서 취할 수 있다. 그런 다음, 체인코드는 현재 상태 데이터베이스에 대해 실행되어 응답 값, 읽기 세트 및 쓰기 세트를 포함하는 트랜잭션 결과를 생성한다. 그러나, 이 시점에서 원장에 대한 업데이트는 수행되지 않는다. 응답 (292)에서, 보증 피어 노드(281)의 서명과 함께, 값들의 세트가, 제안 응답(292)으로서 클라이언트(260)의 SDK에 다시 전달되고, 클라이언트(260)의 SDK는 애플리케이션이 사용하기 위해 페이로드(payload)를 분석한다(parse).
[0071] 응답으로, 클라이언트(260)의 애플리케이션은 보증 피어들의 서명들을 검사/확인(inspects/verifies)하고 제안 응답이 동일지를 결정하기 위해 제안 응답을 비교한다. 만일 체인코드가 원장만 질의하였다면, 애플리케이션은 질의 응답은 검사하고 일반적으로 트랜잭션은 오더링 노드 서비스(284)에 제출하지 않는다. 만일 클라이언트 애플리케이션이 원장을 업데이트하기 위해 트랜잭션을 오더링 노드 서비스(284)에 제출하려 한다면, 애플리케이션은 제출 전에 명시된 보증 정책이 충족되었는지(즉, 트랜잭션에 필요한 모든 피어 노드가 트랜잭션을 보증했는지)를 결정한다. 여기서, 클라이언트는 트랜잭션에 대한 다수의 당사자들 중 하나만을 포함할 수 있다. 이 경우, 각 클라이언트는 자신의 보증 노드를 가질 수 있으며, 각 보증 노드는 트랜잭션을 보증해야 한다. 아키텍처는 애플리케이션이 응답을 검사하지 않도록 선택되거나, 또는 보증되지 않은 트랜잭션을 전달하더라도, 보증 정책이 여전히 피어들에 의해 시행되고 커밋 검증 단계에서 지지되도록 구성된다.
[0072] 성공적인 검사 후, 단계(293)에서 클라이언트(260)는 보증들을 트랜잭션으로 취합하고 트랜잭션 메시지 내의 트랜잭션 제안 및 응답을 오더링 노드(284)에 브로드캐스트 한다. 트랜잭션은 읽기/쓰기 세트들, 피어들의 서명들 및 채널 ID를 포함할 수 있다. 오더링 노드(284)는 자신의 연산을 수행하기 위해 트랜잭션의 전체 콘텐츠를 검사할 필요는 없고, 대신에 오더링 노드(284)는 단지 네트워크의 모든 채널로부터 트랜잭션들을 수신하여, 채널별로 시간순으로 정렬하고, 채널당 트랜잭션들의 블록들을 생성할 수 있다.
[0073] 트랜잭션의 블록들은 오더링 노드(284)에서 채널의 모든 피어 노드들(281-283)로 전달된다. 상기 블록 내의 트랜잭션들(294)은 모든 보증 정책이 충족되었는다는 것을 보증하고 트랜잭션 실행에 의해 읽기 세트가 생성된 이후 읽기 세트 변수들 때문에 원장 상태에 대한 변경들이 없었다는 것을 보증하기 위해 검증된다. 상기 블록 내의 트랜잭션들은 유효하거나 유효하지 않은 것으로 태그가 지정된다. 또한, 단계(295)에서, 각 피어 노드(281-283)는 상기 블록을 채널의 체인에 추가하고, 각 유효한 트랜잭션에 대해 쓰기 세트가 현재 상태 데이터베이스에 커밋된다. 트랜잭션(호출)이 체인에 변경 불가능하게 추가되었음을 클라이언트 애플리케이션에 통지하고, 트랜잭션이 검증되었는지 또는 무효화되었는지(invalidated)를 통지하기 위해, 이벤트가 발생될 수 있다(emitted).
[0074] 도 3a는 분산되고, 탈중앙화 된 P2P(peer-to-peer) 아키텍처를 특징으로 하는, 허가형 블록체인 네트워크(300)의 예를 도시한다. 이 예에서, 블록체인 사용자(302)는 허가된 블록체인(304)에 대해 트랜잭션을 개시할 수 있다. 이 예에서, 트랜잭션은 배치(deploy), 호출(invoke), 또는 질의(query)일 수 있으며, SDK를 이용하는 클라이언트-측 애플리케이션을 통해, API 등을 통해 직접 발급될 수 있다. 네트워크들은, 감사자(auditor)와 같은, 조정자(regulator)(306)에 대해 액세스를 제공할 수 있다. 블록체인 네트워크 운영자(308)는 조정자(306)를 "감사자"로 등록하고, 블록체인 사용자(302)를 "클라이언트"로 등록하는 것과 같은 멤버 권한들(member permissions)을 관리한다. 감사자는 원장 질의로만 제한될 수 있는 반면 클라이언트는 특정 유형의 체인코드를 배포, 호출, 및 질의할 수 있는 권한이 부여될 수 있다.
[0075] 블록체인 개발자(310)는 체인코드 및 클라이언트-측 애플리케이션들을 작성할 수 있다(write). 블록체인 개발자(310)는 인터페이스를 통해 네트워크에 직접 체인코드를 배치할 수 있다. 체인코드 내의 기존 데이터 소스(312)로부터의 자격증명들(credentials)을 포함하기 위해, 개발자(310)는 대역외 연결(an out-of-band connection)을 사용하여 데이터에 액세스 할 수 있다. 이 예에서, 블록체인 사용자(302)는 피어 노드(314)를 통해 허가된 블록체인(304)에 연결한다. 트랜잭션들을 진행하기 전에, 피어 노드(314)는 사용자 역할들 및 권한들을 관리하는 인증 기관(certificate authority)(316)으로부터, 사용자의 등록 및 트랜잭션 인증서들을 검색한다. 일부 경우들에서, 블록체인 사용자들은 허가된 블록체인(304)에서 트랜잭션 하기 위해 이러한 디지털 인증서들을 소유해야 한다. 한편, 체인코드를 이용하려는 사용자는 기존 데이터 소스(312)에서 자신의 자격 증명을 확인해야 할 수 있다. 사용자의 인증을 확인하기 위해, 체인코드는 기존 처리 플랫폼(318)을 통해 이 데이터에 대해 대역외 연결(an out-of-band connection)을 사용할 수 있다.
[0076] 도 3b는, 분산되고, 탈중앙화된P2P 아키텍처를 특징으로 하는, 허가형 블록체인 네트워크(320)의 다른 예를 도시한다. 이 예에서, 블록체인 사용자(322)는 허가된 블록체인(324)에 트랜잭션을 제출할 수 있다. 이 예에서, 트랜잭션은 배치, 호출, 또는 질의일 수 있으며, SDK를 이용하는 클라이언트-측 애플리케이션을 통해, API 등을 통해 직접 발급될 수 있다. 네트워크들은, 감사자와 같은, 조정자(326)에 대한 액세스를 제공할 수 있다. 블록체인 네트워크 운영자(328)는 조정자(326)를 "감사자"로 등록하고 블록체인 사용자(322)를 "클라이언트"로 등록하는 것과 같은 멤버 권한들을 관리한다. 감사자는 원장 질의로만 제한될 수 있는 반면 클라이언트는 특정 유형의 체인코드를 배치, 호출, 및 질의할 수 있는 권한이 부여될 수 있다.
[0077] 블록체인 개발자(330)는 체인코드 및 클라이언트-측 애플리케이션들을 작성한다. 블록체인 개발자(330)는 인터페이스를 통해 네트워크에 직접 체인코드를 배치할 수 있다. 체인코드에 기존의 데이터 소스(332)로부터의 자격증명들을 포함하기 위해, 개발자(330)는 대역외 연결을 사용하여 데이터에 액세스 할 수 있다. 이 예에서, 블록체인 사용자(322)는 피어 노드(334)를 통해 네트워크에 연결한다. 트랜잭션들을 진행하기 전에 피어 노드(334)는 인증 기관(336)으로부터 사용자의 등록 및 트랜잭션 인증서들을 검색한다. 일부 경우들에서, 블록체인 사용자들은 허가된 블록체인 (324)에서 트랜잭션 하기 위해 이러한 디지털 인증서들을 소유해야 한다. 한편, 체인코드를 이용하려는 사용자는 기존 데이터 소스(332)에서 자신의 자격증명을 확인해야 할 수 있다. 사용자의 인증을 확인하기 위해, 체인코드는 기존 처리 플랫폼(338)을 통해 이 데이터에 대해 대역외 연결을 사용할 수 있다.
[0078] 일부 실시예들에서, 여기에서의 블록체인은 무허가 블록체인(permissionless blockchain) 일 수 있다. 참여 권한이 필요한 허가형 블록체인들과 달리, 누구나 무허가 블록체인에 참여할 수 있다. 예를 들어, 무허가 블록체인에 참여하기 위해 사용자는 개인 주소를 생성할 수 있고, 트랜잭션들을 제출하고, 원장에 엔트리들을 추가함으로써, 네트워크와 상호 작용을 시작할 수 있다. 추가적으로, 모든 당사자들은 시스템 상에서 노드를 실행하는 것과 트랜잭션들을 확인하는 데 도움이 되는 마이닝 프로토콜들을 채용하는 것을 선택할 수 있다.
[0079] 도 3c는 복수의 노드들(354)를 포함하는 무허가 블록체인(352)에 의해 처리되는 트랜잭션의 프로세스(350)를 예시한다. 발신자(356)는 결제(payment) 또는 어떤 다른 형태의 가치(예를 들어, 증서, 의료 기록들, 계약, 상품, 서비스 또는 디지털 기록에 캡슐화될 수 있는 기타 자산)를 무허가 블록체인(352)를 통해 수신자(358)에게 보내기를 원한다. 일 실시예에서, 발신자 디바이스(356) 및 수신자 디바이스(358) 각각은 사용자 인터페이스 컨트롤들 및 트랜잭션 파라미터의 디스플레이를 제공하는 디지털 지갑들(블록체인(352)과 연관됨)을 가질 수 있다. 응답으로, 트랜잭션은 블록체인(352)을 통해 노드들(354)로 브로드캐스트된다. 블록체인(352)의 네트워크 파라미터들에 따라서 노드들은 트랜잭션을 확인(verify)(360)하는데, 무허가 블록체인(352) 생성자들에 의해서 설정된 규칙들(미리-정의되거나 동적으로 할당될 수 있음)에 기초하여 한다. 예를 들어, 이 것은 관련 당사자들의 ID 확인(verifying identities) 등을 포함할 수 있다. 트랜잭션은 즉시 확인될 수도 있거나, 또는 다른 트랜잭션들과 함께 대기열에 배치되어, 노드들(354)이 네트워크 규칙들 세트에 기초하여 트랜잭션들이 유효한지를 결정할 수도 있다.
[0080] 구조(362)에서, 유효한 트랜잭션들은 블록으로 형성되고 잠금(해시)으로 봉인된다. 이 과정은 노드들(354) 사이에서 노드들을 마이닝(mining)함으로써 수행될 수 있다. 노드들의 마이닝은 무허가 블록체인(352)을 위해 특별히 블록들의 마이닝 및 생성을 수행하는 추가의 소프트웨어를 이용하여 할 수 있다. 각 블록은 네트워크에 의해서 동의된 알고리즘을 사용하여 생성된 해시(예: 256비트 숫자, 등)에 의해서 식별될 수 있다. 각 블록은, 헤더, 체인 내의 이전 블록 헤더의 해시에 대한 포인터 또는 참조, 그리고 유효한 트랜잭션들 그룹을 포함할 수 있다. 이전 블록의 해시에 대한 참조는 블록들의 안전한 독립 체인의 생성과 연관되어 있다.
[0081] 블록들이 블록체인에 추가되기 전에, 먼저 블록들은 검증되어야 한다. 무허가 블록체인(352)에 대한 검증은 블록의 헤더에서 파생된 퍼즐에 대한 솔루션인 작업-증명(a proof-of-work: PoW)을 포함할 수 있다. 도 3c의 예에서는 도시되지 않았지만, 블록을 검증하기 위한 다른 프로세스는 지분-증명(proof-of-stake)이다. 알고리즘이 수학 문제들을 해결한 채굴자들(miners)에게 보상하는 작업-증명과 달리, 지분 증명을 통해, 새로운 블록의 생성자는, "지분"으로도 정의되는, 자신의 부(富)에 따라, 결정론적 방식으로(in a deterministic way) 선택된다. 그런 다음, 선택된/선택된 노드에 의해 유사한 증명이 수행된다.
[0082] 마이닝(364)을 사용하여, 노드들은 솔루션이 네트워크-전체의 타겟(a network-wide target)을 충족할 때까지 하나의 변수를 점진적으로 변경하여 블록을 해결하려고 한다. 이것은 PoW를 생성하고 이에 의하여 정답들을 보장한다. 달리 말하면, 잠재적인 솔루션은 문제를 해결하는 데 컴퓨팅 자원들이 고갈되었음(drained)을 증명해야 한다. 일부 유형의 무허가 블록체인들에서, 채굴자들은 블록을 올바르게 채굴한 가치(예: 코인들, 등)로 보상될 수 있다.
[0083] 여기서, PoW 프로세스는, 블록들을 체인으로 연결하는 것(chaining)과 함께, 블록체인 수정들을 극도로 어렵게 만드는데, 공격자가 한 블록의 수정들이 허용되게 하기 위해 모든 후속 블록들을 수정해야 하기 때문이다. 또한, 새로운 블록들이 채굴됨에 따라, 블록을 수정하는 것의 어려움도 증가하고, 후속 블록들의 수도 증가한다. 분산(366)를 통해, 성공적으로 검증된 블록은 무허가 블록체인(352)을 통해 분산되고 모든 노드들(354)은 무허가 블록체인(352)의 감사 가능한 원장인 다수 체인(a majority chain)에 상기 블록을 추가한다. 또한, 발신자(356)에 의해 제출된 트랜잭션의 가치는 예치되거나(deposited) 또는 그렇지 않으면 수신자 디바이스 (358)의 디지털 지갑에 전송된다.
[0084] 도 4는 예시적인 실시예들에 따라 이벤트를 생성하고 검증하기 위한 시스템 메시징 다이어그램(400)을 도시한다. 도 4를 참조하면, 시스템 다이어그램(400)은 제1 주체(410), 제2 주체(420) 및 블록체인(430)을 포함한다. 제1 주체(410)는 블록체인 네트워크의 제1 노드일 수 있고, 제2 주체(420)는 블록체인 네트워크의 제2 노드일 수 있다.
[0085] 도 4를 참조하면, 상기 메시징 다이어그램은 새로운 이벤트를 생성할 때 고려할 이벤트 데이터를 포함하는 제1 메시지를 수신하는 단계(411)를 포함한다. 상기 제1 메시지는 제1 주체(410), 블록체인 네트워크의 다른 노드 또는 다른 주체와 통신하는 클라이언트 애플리케이션으로부터 수신될 수 있다. 상기 이벤트 데이터는 블록체인 네트워크의 객체 및/또는 네임스페이스를 식별하거나 식별하기 위한 기초로서 사용될 수 있는 정보를 제공하는 콘텐츠를 포함할 수 있다. 일 실시예에서, 이벤트 데이터의 콘텐츠는 연관된 객체의 상태(또는 상태의 변경)를 나타낼 수 있는데, 예를 들어, 회사의 특정 고객에 대한 청구서의 객체에 대해서, 이벤트 데이터는 청구서가 "미납" 상태에서 "전액 지불" 상태로 변경되었음을 나타낼 수 있다.
[0086] 동작 단계(412)에서, 제1 메시지가 수신되면, 제1 주체(410)의 프로세서는 스마트 계약을 실행하여 제1 메시지의 콘텐츠를 결정한다. 그 다음 상기 콘텐츠는 보증 정책에 제출되는데, 보증 정책은, 네트워크에서 이벤트가 생성되어야 하는지를 결정하기 위해, 이벤트 데이터를 보증하고 검증하는데 수행될 일련의 조건들 또는 동작들을 정의할 수 있다. 상기 조건들 또는 동작들은 메시지 콘텐츠에 의해 표시된 객체가 블록체인 네트워크에 의해 이전에 생성되고 유지되는 키 정보에 대응하는지를 결정하는 단계를 포함할 수 있다. 추가적으로, 또는 대안적으로, 제1 주체의 프로세서는 이벤트 데이터의 콘텐츠에 대응하는 미리결정된 네임스페이스가 있는지를 결정할 수 있다. 만일 두 조건이 모두 존재하지 않는다면, 이벤트 데이터의 유효성은 검증될 수 없고 이벤트 생성이 거부될 수 있다. 반면에, 만일 보증정책의 조건들이 총족 되었다면, 이벤트는 생성될 수 있다.
[0087] 동작 단계(413)에서, 일단 보증 정책의 조건들이 만족되었다는 결정이 내려지면, 제1주체(410)의 스마트 계약을 실행하는 프로세서는 이벤트 데이터에 관련되는 객체 및/또는 네임스페이스에 대응하는 키 정보를 저장하는 새로운 필드로 이벤트를 생성한다. 이 동작 단계는 다양한 방식으로 수행될 수 있다. 예를 들어, 생성된 이벤트는 키 정보를 갖는 새로운 필드를 포함할 수 있다. 추가적으로 또는 대안적으로, 상기 이벤트와 연관된 트랜잭션의 메시지 포맷은 키 정보를 포함하는 새로운 필드를 포함할 수 있다.
[0088] 이벤트가 생성되면 메시지(414)가 블록체인(430)으로 전송된다. 상기 메시지는 이벤트 및 하나 또는 그 이상의 연관된 트랜잭션들(있는 경우)과 함께 전송될 수 있다. 이벤트가 수신되면, 블록체인은 합의를 위해 상기 이벤트를 제출하고 그 다음, 동작 단계(415)에서, 블록체인의 새로운 블록에 상기 이벤트를 커밋한다.
[0089] 그 다음, 메시지(416)는 상기 이벤트가 블록체인에 커밋된 후 임의의 시점에서 제2 주체(420)로부터 블록체인(430)으로 전송될 수 있다. 메시지(416)는 이벤트 및 그 것에 수반되는 트랜잭션(들)에 액세스하기 위한 질의를 포함할 수 있다.
[0090] 동작 단계(417)에서, 상기 이벤트를 포함하는 블록은 블록체인으로부터 검색되어 응답 메시지(418)로서 제2 주체(420)로 다시 전송된다.
[0091] 동작 단계(419)에서, 제2주체(420)는 블록체인에서 검색된 이벤트의 콘텐츠를 검색하여 키 정보를 검색한다. 그런 다음, 이 키 정보는 상기 이벤트의 콘텐츠에 대응하는 객체(및/또는 네임스페이스)의 알려진 키 정보와 비교된다. 만일 매치가 있다면, 제2 주체(420)는, 블록체인(430)에서 검색된 정보에서 식별된 이벤트와 연관된 모든 트랜잭션들과 함께, 상기 이벤트가 유효하다고 결정할 수 있다. 이들 동작 단계들은, 예를 들어, 제2 주체(420)의 프로세서에 의해 실행되는 스마트 계약에 의해 수행될 수 있다.
[0092] 도 5는, 예시적인 실시예들에 따라, 블록체인과 같은 탈중앙화된 데이터베이스에서 정보를 관리하는 예시적인 방법의 플로차트(500)를 도시한다. 도 5를 참조하면, 방법(500)은, 동작 단계(510)에서, 하나의 주체로부터 이벤트 데이터를 수신하는 단계를 포함할 수 있다. 이벤트 데이터의 콘텐츠는 블록체인에 생성되어 기록될 이벤트를 나타내는 다양한 유형의 정보를 포함할 수 있다. 상기 주체는 블록체인 노드의 클라이언트 애플리케이션, 블록체인의 노드, 다른 블록체인 주체, 또는 블록체인 네트워크 외부에 있지만 네트워크의 하나 또는 그 이상의 주체들과 통신하는 주체일 수 있다.
[0093] 동작 단계(520)에서, 이벤트 데이터가 보증 정책을 만족하는지에 대한 결정이 내려진다. 보증 정책은 여기에 설명된 하나 또는 그 이상의 요건들 또는 조건들을 포함할 수 있다. 일 실시예에서, 보증 정책은 블록체인에 의해 관리되는 객체 또는 블록체인의 네임스페이스 중 하나 또는 그 이상에 대응하는 이벤트 데이터의 콘텐츠를 요구할 수 있다. 예를 들어, 청구 애플리케이션에서, 객체는 특정 청구서일 수 있으며 이벤트 데이터는 상기 청구서와 관련된 트랜잭션을 나타낼 수 있다. 예를 들어, 이벤트 데이터는 "미납"에서 "전액 지불"로의 변경과 같이 청구서에 관한 상태 변경이 발생했음을 나타낼 수 있다. 네임스페이스는, 예를 들어, 청구서를 발행한 회사 또는 서비스의 고객 및/또는 청구서와 관련된 서비스 또는 상품을 제공한 고객에 대응할 수 있다.
[0094] 동작 단계(530)에서, 이벤트 데이터의 컨텍스트에 대응하는 식별자가 세트 된다. 이벤트 데이터의 컨텍스트는, 예를 들어, 이전에 표시된 객체 또는 네임스페이스이거나 이를 포함할 수 있다. 일 실시예에서, 상기 식별자는 본 명세서에 기술된 모든 유형의 키 정보를 포함할 수 있다. 예를 들어, 이벤트 데이터의 컨텍스트는 데이터베이스는 대응하는 채널 이름, 네임스페이스, 컬렉션 또는 키 이름 모두 또는 이들 중 둘 이상을 포함하는 튜플(a tuple)을 포함할 수 있다. 예를 들어, 키 정보는 객체 또는 네임스페이스에 대응하도록 미리 세트 될 수 있다. 따라서, 키 정보와 이벤트 및/또는 하나 또는 그 이상의 연관된 트랜잭션들의 연관은 이벤트가 올바른지 자동으로 검증하는 기능을 수행할 수 있다.
[0095] 동작 단계(540)에서, 보증 정책이 만족되고 식별자가 세트 되면, 방법은 블록체인 네트워크에 제출하기 위한 이벤트를 생성하는 단계를 포함할 수 있다. 생성된 이벤트는, 예를 들어, 다수의 필드를 포함할 수 있다. 하나의 필드는 데이터베이스에 의해 관리되는 상태, 객체, 네임스페이스 또는 컨텍스트를 나타내는 이벤트 데이터로부터 획득된 정보를 포함할 수 있다. 다른 필드는 식별자, 예를 들어 객체, 네임스페이스 또는 기타 컨텍스트에 대해 미리 결정된 키 정보를 포함할 수 있다.
[0096] 동작 단계(550)에서, 생성된 이벤트는 블록체인 네트워크에 제출될 수 있다. 여기에는 블록체인에 기록될 새로운 블록의 합의 및 주제 기록(consensus and subject recordation)을 위해 이벤트를 커밋하는 단계가 포함될 수 있다. 일 실시예에서, 이것은, 이벤트가 블록체인에 기록되는지 여부에 관계없이, 이벤트의 블록체인 네트워크에 있는 피어 노드들에 알림을 제공하는 단계를 포함할 수 있다.
[0097] 동작 단계(560)에서, 블록체인은 이벤트를 검색하도록 질의 될 수 있고, 검색된 이벤트의 콘텐츠에 관한 검증은 검색된 이벤트의 키 정보를 사전 승인되고 이벤트 콘텐츠와 연관된 객체 또는 네임스페이스 링크된 알려진 키 정보와 매칭함으로써 확인될 수 있다.
[0098] 도 6a는 예시적인 실시예들에 따라 다양한 연산들을 수행하도록 구성된 물리적 하부구조(610)를 포함하는 예시적인 시스템(600)을 예시한다. 도 6a를 참조하면, 물리적 하부구조(610)는 모듈(612) 및 모듈(614)을 포함한다. 모듈(614)은 블록체인(620) 및 스마트 계약(630)(블록체인(620)에 상주할 수 있음)을 포함하며, 이는 예시적인 실시예들 중 어느 하나에 포함된 연산 단계들(608) 중 어느 하나를 (모듈(612) 내에서) 실행할 수 있다. 단계들/연산들(608)은 설명되거나 도시된 실시예들 중 하나 또는 그 이상을 포함할 수 있고 하나 또는 그 이상의 스마트 계약들(630) 및/또는 블록체인들(620)으로부터 기록되거나 판독되는 출력 또는 기록된 정보를 나타낼 수 있다. 물리적 하부구조(610), 모듈(612), 및 모듈(614)은 하나 또는 그 이상의 컴퓨터들, 서버들, 프로세서들, 메모리들, 및/또는 무선 통신 디바이스들을 포함할 수 있다. 또한, 모듈(612)과 모듈(614)은 동일 모듈일 수 있다.
[0099] 도 6b는 예시적인 실시예들에 따라 다양한 연산들을 수행하도록 구성된 다른 예시적인 시스템(640)을 도시한다. 도 6b를 참조하면, 시스템(640)은 모듈(612) 및 모듈(614)을 포함한다. 모듈(614)은 블록체인(620) 및 스마트 계약(630) (블록체인(620)에 상주할 수 있음)을 포함하며, 이는 예시적인 실시예들 중 어느 하나에 포함된 연산 단계들(608) 중 어느 하나를(모듈(612) 내에서) 실행할 수 있다. 단계들/동작들(608)은 설명되거나 도시된 실시예들 중 하나 또는 그 이상을 포함할 수 있고 하나 또는 그 이상의 스마트 계약들(630) 및/또는 블록체인들(620)로부터 기록되거나 판독되는 출력 또는 기록된 정보를 나타낼 수 있다. 물리적 하부구조(610), 모듈(612), 및 모듈(614)은 하나 또는 그 이상의 컴퓨터들, 서버들, 프로세서들, 메모리들, 및/또는 무선 통신 장치들을 포함할 수 있다. 또한, 모듈(612)과 모듈(614)은 동일 모듈일 수 있다.
[00100] 도 6c는 예시적인 실시예들에 따라 계약 당사자들 사이에 스마트 계약 구성을 이용하도록 구성된 예시적인 시스템과 블록체인에서 스마트 계약 조건들을 시행하도록 구성된 중개 서버를 도시한다. 도 6c를 참조하면, 구성(650)은 하나 또는 그 이상의 사용자 디바이스들(652 및/또는 656)을 명시적으로 식별하는 스마트 계약(630)에 의해 주도된(driven) 통신 세션, 자산 이전 세션 또는 프로세스 또는 절차를 나타낼 수 있다. 스마트 계약 실행의 실행, 연산들 및 결과들은 서버(654)에 의해서 관리될 수 있다. 스마트 계약(630)의 콘텐츠는 스마트 계약 트랜잭션에 대한 당사자인 주체들(652, 656) 중 하나 또는 그 이상에 의한 디지털 서명들을 요구할 수 있다. 스마트 계약 실행 결과들은 블록체인 트랜잭션으로 블록체인(620)에 기록될 수 있다. 스마트 계약(630)은 하나 또는 그 이상의 컴퓨터들, 서버들, 프로세서들, 메모리들 및/또는 무선 통신 장치들에 상주할 수 있는 블록체인(620)에 상주한다.
[00101] 도 6d는 예시적인 실시예들에 따라 블록체인을 포함하는 시스템(660)을 도시한다. 도 6d의 예를 참조하면, 애플리케이션 프로그래밍 인터페이스(API) 게이트웨이(662)는 블록체인 논리(예를 들어, 스마트 계약(630) 또는 다른 체인코드) 및 데이터(예를 들어, 분산 원장 등)에 액세스하기 위한 공통 인터페이스를 제공한다. 이 예에서, API 게이트웨이(662)는 하나 또는 그 이상의 주체들(652 및 656)을 블록체인 피어(즉, 서버(654))에 연결함으로써 블록체인에서 트랜잭션들(호출, 질의들 등)을 수행하기 위한 공통 인터페이스이다. 여기서, 서버(654)는 세계 상태의 사본을 보유하는 블록체인 네트워크 피어 컴포넌트이고, 클라이언트들(652 및 656)이 세계 상태에 대한 데이터를 질의하고 블록체인 네트워크에 트랜잭션들을 제출할 수 있도록 하는 분산 원장이며, 여기서, 계약(630) 및 보증 정책에 따라, 보증 피어들이 스마트 계약들(630)을 실행할 것이다.
[00102] 상기 실시예들은 하드웨어로, 프로세서에 의해 실행되는 컴퓨터 프로그램으로, 펌웨어로, 또는 이들의 조합으로 구현될 수 있다. 컴퓨터 프로그램은 스토리지 매체와 같은, 컴퓨터 판독 가능 매체에 구현될 수 있다. 예를 들어, 컴퓨터 프로그램은 랜덤 액세스 메모리("RAM"), 플래시 메모리, 읽기-전용 메모리("ROM"), 지울 수 있는 프로그래밍 가능한 읽기-전용 메모리("EPROM"), 전기적으로 지울 수 있는 프로그램 가능한 읽기-전용 메모리(“EEPROM”), 레지스터들, 하드 디스크, 이동식 디스크, 컴팩트 디스크 읽기-전용 메모리("CD-ROM"), 또는 당업계에 알려진 임의의 다른 형태의 스토리지 매체가 있다.
[00103] 예시적인 스토리지 매체는 프로세서가 스토리지 매체로부터, 정보를 읽고 정보를 기록할 수 있도록, 프로세서에 연결될 수 있다. 대안적으로, 스토리지 매체는 프로세서에 통합될 수 있다. 프로세서 및 스토리지 매체는 오더링형 집적 회로("ASIC")에 상주할 수 있다. 대안으로, 프로세서와 스토리지 매체는 별개의 컴포넌트들로 존재할 수 있다.
[00104] 도 7a는 예시적인 실시예들에 따라 분산 원장(720)에 새로운 블록이 추가되는 프로세스(700)을 도시하고, 도 7b는 예시적인 실시예들에 따라, 블록체인을 위한 새로운 데이터 블록 구조(730)의 콘텐츠를 도시한다. 도 7a를 참조하면, 클라이언트들(도시하지 않음)은 블록체인 노드들(711, 712, 713)에 트랜잭션들을 제출할 수 있다. 클라이언트들은 블록체인(720)에서 활동(activity)을 실행하기 위해 모든 소스로부터 지시를 받을 수 있다. 예를 들어, 클라이언트들은 블록체인에 대한 트랜잭션들을 제안하는 디바이스, 사람 또는 주체와 같은, 요청자를 대신하여 작동하는, 애플리케이션일 수 있다. 복수의 블록체인 피어들(예: 블록체인 노드들(711, 712, 713)은 블록체인 네트워크의 상태와 분산 원장(720)의 사본을 유지할 수 있다. 클라이언트들이 제안한 트랜잭션들을 시뮬레이션 및 보증하는 보증 피어들과 보증들을 확인하고, 트랜잭션들을 검증하며, 분산 원장(720)에 트랜잭션들을 커밋하는 커밋 피어들을 포함하여 블록체인 네트워크에 다양한 유형의 블록체인 노드들/피어들이 존재할 수 있다. 이 예에서, 블록체인 노드들(711, 712, 713)은 보증인 노드, 커미터 노드 또는 둘 다의 역할을 수행할 수 있다.
[00105] 분산 원장(720)은 블록들 내의 불변하고, 시퀀스된 기록들(immutable, sequenced records in blocks), 및 블록체인(722)의 현재 상태를 유지하는 상태 데이터베이스(724) (현재 세계 상태)를 저장하는 블록체인을 포함한다. 하나의 분산 원장(720)은 채널당 존재할 수 있고 각 피어는 자신이 멤버인 각 채널을 위한 분산 원장(720)의 자신의 사본을 유지한다. 블록체인(722)은 각 블록이 N개의 트랜잭션 시퀀스를 포함하는 해시-링크 블록들로서 구조화된(structured), 트랜잭션들 로그(log)이다. 블록들은 도 7b에 도시된 바와 같은 다양한 컴포넌트들을 포함할 수 있다. 블록들의 링크(도 7a에서 화살표로 표시)는 현재 블록의 블록 헤더 내에 이전 블록 헤더의 해시를 추가함으로써 생성될 수 있다. 이러한 방식으로, 블록체인(722)의 모든 트랜잭션들은 순차화 되고(sequenced) 그리고 암호적으로 서로 링크되는데, 이는 해시-링크들을 파괴하지 않고서 블록체인 데이터를 변조하는 것을 방지하기 위해서이다. 또한, 링크들로 인해, 블록체인(722)의 최신 블록은 그 것 이전에 발생한 모든 트랜잭션을 나타낸다. 블록체인(722)은, 추가 전용 블록체인 워크로드(an append-only blockchain workload)를 지원하는, 피어 파일 시스템(로컬 또는 부착된 스토리지)에 저장될 수 있다.
[00106] 블록체인(722) 및 분산 원장(722)의 현재 상태는 상태 데이터베이스(724)에 저장될 수 있다. 여기서, 현재 상태 데이터는 블록체인(722)의 체인 트랜잭션 로그에 포함된 모든 키들에 대한 최신 값을 나타낸다. 체인코드 호출들은 상태 데이터베이스(724)의 현재 상태에 대해 트랜잭션들을 실행한다. 이러한 체인코드 상호작용을 매우 효율적으로 만들기 위해, 모든 키들의 최신 값이 상태 데이터베이스(724)에 저장된다. 상태 데이터베이스(724)는 블록체인(722)의 트랜잭션 로그에 대한 인덱스 된 뷰를 포함할 수 있고, 따라서 그 것은 언제든지 상기 체인으로부터 재생성 될 수 있다. 상태 데이터베이스(724)는, 트랜잭션들이 수용되기 전에, 피어 시작 시 자동으로 복구(또는 필요한 경우 생성)될 수 있다.
[00107] 보증 노드들은 클라이언트들로부터 트랜잭션들을 수신하고 시뮬레이트 된 결과들에 기초하여 트랜잭션을 보증한다. 보증 노드들은 트랜잭션 제안들을 시뮬레이트 하는 스마트 계약들을 보유한다. 보증 노드가 트랜잭션을 보증할 때, 보증 노드로부터 클라이언트 애플리케이션에 대한 서명된 응답인 트랜잭션 보증(a transaction endorsement)을 보증 노드들은 생성하며, 이는 시뮬레이트 된 트랜잭션의 보증을 표시한다. 트랜잭션을 보증하는 방법은 체인코드 내에서 명시될 수 있는 보증 정책에 따라 다르다. 보증 정책의 예는 "대다수의 보증 피어들은 트랜잭션을 보증해야 한다"이다. 채널들마다 보증 정책들이 다를 수 있다. 보증된 트랜잭션들은 클라이언트 애플리케이션에 의해 오더링 서비스(710)로 전달된다.
[00108] 오더링 서비스(710)는 보증된 트랜잭션들을 수용하고(accept), 그들을 하나의 블록으로 정렬하고(order), 상기 블록들을 커밋팅 피어들에게 전달한다. 예를 들어, 오더링 서비스(710)는 트랜잭션의 임계값이 도달되었 때, 타이머가 타임아웃이 되었을 때, 또는 다른 조건에 도달했을 때 새로운 블록을 개시할 수 있다. 도 7a의 예에서, 블록체인 노드(712)는 블록체인(720)에 저장하기 위해 새로운 데이터 블록(730)을 수신한 커밋팅 피어이다. 상기 블록체인 내의 제1 블록은 제네시스 블록이라고 하고, 이는 상기 블록체인에 관한 정보, 상기 블록체인의 멤버들에 관한 정보, 상기 블록체인에 저장된 데이터, 등에 관한 정보를 포함할 수 있다.
[00109] 오더링 서비스(710)는 오더러들의 클러스터로 구성될 수 있다. 오더링 서비스(710)는 트랜잭션들, 스마트 계약들을 처리하거나, 및 공유 원장을 유지하지 않는다. 오히려, 오더링 서비스(710)는 보증된 트랜잭션들을 수용하고 이러한 트랜잭션들이 분산 원장(720)에 커밋된 순서(order)를 명시할 수 있다. 블록체인 네트워크의 아키텍처는 '오더링'의 특정 구현(예: Solo, Kafka, BFT 등)이 플러그 가능한 컴포넌트가 되도록 설계될 수 있다.
[00110] 트랜잭션들은 일관된 순서로(a consistent order) 분산 원장(720)에 기록된다. 트랜잭션들의 순서는 상태 데이터베이스(724)에 대한 업데이트들이 네트워크에 커밋될 때 그들이 유효함을 보장하기 위해 설정된다. 암호화 퍼즐의 솔빙(solving) 또는 마이닝(mining)을 통해 오더링이 발생하는 암호화폐 블록체인 시스템(예: 비트코인 등)과 달리, 이 예에서 분산 원장(720)의 당사자들은 상기 네트워크에 가장 적합한 오더링 메커니즘을 선택할 수 있다.
[00111] 오더링 서비스(710)가 새로운 데이터 블록(730)을 초기화할 때, 새로운 데이터 블록(730)은 커밋팅 피어들(예를 들어, 블록체인 노드들(711, 712, 및 713))로 브로드캐스트 될 수 있다. 응답으로, 각 커밋팅 피어는 읽기 세트와 쓰기 세트가 상태 데이터베이스(724)의 현재 세계 상태와 여전히 일치(match)함을 보장하기 위해 체크함으로써 새로운 데이터 블록(730) 내의 트랜잭션을 검증한다. 구체적으로, 커밋팅 피어는 보증인들이 트랜잭션을 시뮬레이트 할 때 존재했던 읽기 데이터가 상태 데이터베이스(724) 내의 현재 세계 상태와 동일한지(identical)를 결정할 수 있다. 커밋팅 피어가 트랜잭션을 검증할 때, 트랜잭션은 분산 원장(720)의 블록체인(722)에 기록되고, 상태 데이터베이스(724)는 읽기-쓰기 세트로부터의 쓰기 데이터로 업데이트된다. 만일 트랜잭션이 실패한다면, 즉 만일 커밋팅 피어가 읽기-쓰기 세트가 상태 데이터베이스(724)의 현재 세계 상태와 일치하지 않다는 것을 발견하면 하나의 블록에 정렬된 트랜잭션은 여전히 상기 블록에 포함되지만 유효하지 않은 것으로 표시되고 상태 데이터베이스(724)는 업데이트되지 않는다.
[00112] 도 7b를 참조하면, 분산 원장(720)의 블록체인(722)에 저장된 새로운 데이터 블록(730)(데이터 블록이라고도 함)은 블록 헤더(740), 블록 데이터(750) 및 블록 메타데이터(760)와 같은 다수 데이터 세그먼트들을 포함할 수 있다. 도 7b에 도시된 새로운 데이터 블록(730) 및 그것의 콘텐츠와 같은, 다양한 도시된 블록들 및 그들의 콘텐츠들은, 단지 예들일 뿐이며 예시적인 실시예들의 범위를 제한하려는 것이 아님을 이해해야 한다. 새로운 데이터 블록(730)은 N개의 트랜잭션(들)(예를 들어, 1, 10, 100, 500, 1000, 2000, 3000 등)의 트랜잭션 정보를 블록 데이터(750) 내에 저장할 수 있다. 새로운 데이터 블록(730)은 블록 헤더(740) 내(예를 들어, 도 7a의 블록체인(722) 상의) 이전 블록 대한 링크를 포함할 수 있다. 특히, 블록 헤더(740)는 이전 블록의 해시를 포함할 수 있다. 블록 헤더(740)는 또한 고유 블록 번호, 새로운 데이터 블록(730)의 블록 데이터(750)의 해시, 등을 포함할 수 있다. 새로운 데이터 블록(730)의 블록 번호는 고유할 수 있고 0으로부터 시작하는 증분/순차적 순서(an incremental /sequential order)와 같은 다양한 순서들로 할당될 수 있다.
[00113] 블록 데이터(750)는 새로운 데이터 블록(730) 내에 기록된 각 트랜잭션의 트랜잭션 정보를 저장할 수 있다. 예를 들어, 트랜잭션 데이터는 다음 중 하나 또는 그 이상을 포함할 수 있다: 트랜잭션의 유형, 버전, 타임스탬프, 분산 원장(720)의 채널 ID, 트랜잭션 ID, 에포크, 페이로드 가시성, 체인코드 경로(tx의 배치), 체인코드 이름, 체인코드 버전, 입력(체인코드 및 기능들), 공개 키 및 인증서와 같은 클라이언트(생성자) 식별, 클라이언트의 서명, 보증인의 ID, 보증인 서명들, 제안 해시, 체인코드 이벤트들, 응답 상태, 네임스페이스, 읽기 세트(트랜잭션이 읽은 키 및 버전의 목록, 등), 쓰기 세트(키 및 값의 목록, 등), 시작 키, 종료 키, 키들의 목록, 메르켈 트리 질의 요약, 등등. 트랜잭션 데이터는 N개의 트랜잭션들 각각에 대해 저장될 수 있다.
[00114] 일부 실시예들에서, 블록 데이터(750)는 블록체인(722)에 블록들의 해시-링크된 체인에 추가 정보를 추가하는 새로운 데이터(762)를 저장할 수도 있다. 상기 추가 정보는 여기에 설명되거나 묘사된 단계들, 특징들, 프로세스들 및/또는 작업들(actions) 중 하나 또는 그 이상을 포함한다. 따라서, 새로운 데이터(762)는 분산 원장(720) 상의 블록들의 불변 로그에 저장될 수 있다. 그러한 새로운 데이터(762)를 저장하는 것의 이점들 중 일부는 여기에 개시되고 묘사된 다양한 실시예들에 반영된다. 비록 도 7b에서 새로운 데이터(762)는 블록 데이터(750)에 도시되어 있지만 블록 헤더(740) 또는 블록 메타데이터(760)에도 위치할 수 있다.
[00115] 블록 메타데이터(760)는 메타데이터의 다수 필드들을 저장할 수 있다(예를 들어, 바이트 어레이 등으로서). 메타데이터 필드들은 블록 생성 시 서명, 마지막 구성 블록에 대한 참조, 블록 내에서 유효 및 무효의 트랜잭션들을 식별하는 트랜잭션 필터, 블록을 정렬한 오더링 서비스의 지속된 마지막 오프셋(last offset persisted of an ordering service) 등을 포함할 수 있다. 서명, 마지막 구성 블록 및 오더러 메타데이터(the orderer metadata)는 오더링 서비스(710)에 의해 추가될 수 있다. 한편, 블록의 커미터(블록체인 노드(712)와 같은)는 보증 정책, 읽기/쓰기 세트들의 검증 등에 기초하여 유효성/무효성 정보를 추가할 수 있다. 트랜잭션 필터는 블록 데이터(750)의 트랜잭션들 수와 동일 크기의 바이트 어레이 및 트랜잭션이 유효/무효였는지를 식별하는 검증 코드를 포함할 수 있다.
[00116] 도 7c는 본 명세서에 설명된 실시예들에 따른 디지털 콘텐츠를 위한 블록체인(770)의 일 실시예를 도시한다. 디지털 콘텐츠는 하나 또는 그 이상의 파일들 및 연관된 정보를 포함할 수 있다. 상기 파일들은 미디어, 이미지들, 비디오, 오디오, 텍스트, 링크들, 그래픽들, 애니메이션들, 웹 페이지들, 문서들, 또는 기타 형태들의 디지털 콘텐츠를 포함할 수 있다. 블록체인의 변경 불가능한 추가 전용 특징들은, 디지털 콘텐츠의 무결성, 유효성, 및 진정성을 보호하기 위한 보호장치(safeguard)로서 기능을 수행하고, 이 것은 허용 규칙들(admissibility rules)이 적용되는 법률 절차(in legal proceedings), 또는 증거가 고려되는 기타 설정들 또는 디지털 정보의 표시 및 사용이 다른 방식으로 관심이 있는 경우에 적합하게 사용할 수 있다. 이 경우, 디지털 컨텐츠를 디지털 증거라고 할 수 있다.
[00117] 블록체인은 다양한 방식들로 형성될 수 있다. 일 실시예에서, 디지털 콘텐츠는 블록체인 자체에 포함되고 블록체인 자체로부터 액세스될 수 있다. 예를 들어, 블록체인의 각 블록은 연관된 디지털 콘텐츠를 따라 참조 정보(예: 헤더, 값 등)의 해시 값을 저장할 수 있다. 해시 값 및 연관된 디지털 콘텐츠는 함께 암호화될 수 있다. 따라서, 각 블록의 디지털 컨텐츠는 블록체인의 각 블록을 암호 해독함으로써 접근될 수 있으며, 각 블록의 해시 값은 이전 블록을 참조하기 위한 기초로서 사용될 수 있다.
[00130] 이것은 다음과 같이 예시될 수 있다.
Figure pct00001
[00118] 일 실시예에서, 디지털 콘텐츠는 블록체인에 포함되지 않을 수 있다. 예를 들어, 블록체인은 디지털 콘텐츠 없이 각 블록 콘텐츠의 암호화된 해시들을 저장할 수 있다. 디지털 콘텐츠는 원본 파일의 해시 값과 관련하여 다른 스토리지 영역 또는 메모리 주소에 저장될 수 있다. 다른 스토리지 영역은 블록체인을 저장하는 데 사용되는 동일 스토리지 디바이스이거나 또 다른 스토리지 영역 또는 별도의 관계형 데이터베이스일 수 있다. 각 블록의 디지털 콘텐츠는 관심 블록의 해시 값을 획득하거나 질의한 다음 실제 디지털 콘텐츠에 대응하여 저장된, 스토리지 영역에서 해당 해시 값을 조회함으로써 참조되거나 액세스될 수 있다. 이 연산은, 예를 들어, 데이터베이스 게이트키퍼(a database gatekeeper)에서 수행될 수 있다. 이것은 다음과 같이 예시될 수 있다.
Figure pct00002
[00119] 도 7c의 예시적인 실시예에서, 블록체인(770)은, N ≥ 1인, 정렬된 시퀀스로(in an ordered sequence) 암호화로 링크된 다수의 블록들(7781, 7782, … 778N)을 포함한다. 블록들(7781, 7782, … 778N)을 링크하기 위해 사용된 암호화는 다수의 키가 있거나 키가 없는 해시 함수들 중 하나일 수 있다. 일 실시예에서, 블록들(7781, 7782, … 778N)은 블록들 내의 정보에 기초하는 입력들로부터 n-비트 영숫자 출력들(n은 256 또는 다른 숫자임)을 생성하는 해시 함수의 대상(subject to)이 된다. 그러한 해시 함수의 예들은, SHA-유형(SHA는 Secured Hash Algorithm의 약자) 알고리즘, 머클-댐가드(Merkle-Damgard) 알고리즘, HAIFA 알고리즘, 머클-트리(Merkle-tree) 알고리즘, 난스(nonce)-기반 알고리즘 및 비-충돌-방지 PRF 알고리즘을 포함하지만, 이에 국한하지는 않는다. 다른 실시예에서, 블록들(7781, 7782, … 778N)은 해시 함수와 다른 함수에 의해 암호로 링크될 수 있다. 예시의 목적으로, 다음 설명은 해시 함수, 예를 들어 SHA-2를 참조하여 진행된다.
[00120] 블록체인 내의 각 블록들(7781, 7782, …, 778N)은 헤더, 파일 버전, 및 값을 포함한다. 상기 헤더와 상기 값은 블록체인에서 해싱의 결과로서 블록마다 다르다. 일 실시예에서, 상기 값은 헤더에 포함될 수 있다. 파일의 버전은 원본 파일이거나 원본 파일의 다른 버전일 수 있고, 이에 관해서는 후술한다.
[00121] 블록체인의 제1 블록(7781)은 제네시스 블록(genesis block)이라고 하며 헤더(7721), 원본 파일(7741), 초기값(7761)을 포함한다. 제네시스 블록과, 실제로 모든 후속 블록들에 사용되는 해싱 체계(hashing scheme)는, 변화할 수 있다(vary). 예를 들어, 제1 블록(7781)의 모든 정보가 한 번에 해시되거나, 제1 블록(7781)의 정보 각각 또는 일부가 별도로 해시된 후, 별도로 해시된 부분들이 수행될 수 있다.
[00122] 헤더(7721)는 하나 또는 그 이상의 초기 파라미터들을 포함할 수 있으며, 예를 들어, 버전 번호, 타임스탬프, 난스(nonce), 루트 정보, 난이도, 합의 프로토콜, 기간, 미디어 형식, 소스, 설명 키워드들 및/또는 원본 파일(7741) 및/또는 블록체인과 연관된 기타 정보를 포함할 수 있다. 헤더(7721)는 자동으로(예: 블록체인 네트워크 관리 소프트웨어에 의해) 생성되거나 블록체인 참가자에 의해 수동으로 생성될 수 있다. 블록체인의 다른 블록들(7782 부터 778N) 내의 헤더와 달리 제네시스 블록 내의 헤더(7721)는 단지 이전 블록이 없기 때문에 이전 블록을 참조하지는 않는다.
[00123] 제네시스 블록 내의 원본 파일(7741)은, 예를 들어, 블록체인에 포함되기 전에 처리가 있거나 없는 디바이스에 의해 캡처 된 데이터일 수 있다. 원본 파일(7741)은 디바이스, 미디어 소스, 또는 노드로부터 시스템의 인터페이스를 통해 수신된다. 원본 파일(7741)은, 예를 들어, 수동 또는 자동으로 사용자, 디바이스 및/또는 시스템 프로세서에 의해 생성될 수 있는, 메타데이터와 연관된다. 메타데이터는 원본 파일(7741)과 관련하여 제1 블록(7781)에 포함될 수 있다.
[00124] 제네시스 블록 내의 값(7761)은 원본 파일(7741)의 하나 또는 그 이상의 고유 속성들에 기초하여 생성된 초기 값이다. 일 실시예에서, 하나 또는 그 이상의 고유 속성들은 원본 파일(7741)에 대한 해시 값, 원본 파일(7741)에 대한 메타데이터, 및 상기 파일과 관련된 다른 정보를 포함할 수 있다. 일 구현에서, 초기 값(6761)은 다음 고유 속성들에 기초할 수 있다:
Figure pct00003
[00125] 블록체인 내의 다른 블록들(7782 부터 778N)도 또한 헤더들, 파일들 및 값들을 갖는다. 하지만, 제1 블록(7721)과 달리, 다른 블록들의 헤더들(7722 부터 772N) 각각은 직전 블록의 해시 값을 포함한다. 직전 블록의 해시 값은 직전블록 헤더의 해시일 수도 있고, 이전 블록 전체의 해시 값일 수도 있다. 나머지 블록들 각각에 선행 블록의 해시 값을 포함함으로써, 화살표(780)로 표시된 바와 같이, 블록 단위로(on a block-by-block basis), N번째 블록에서 제네시스 블록(및 관련 원본 파일)으로 추적을 수행하여 감사 가능하고 변경 불가능한 관리-사슬(an auditable and immutable chain-of-custody)을 설정할 수 있다.
[00126] 다른 블록들 내의 헤더(7722 부터 772N) 각각은 또한 다른 정보, 예를 들어, 버전 번호, 타임스탬프, 난스(nonce), 루트 정보, 난이도, 합의 프로토콜 및/또는 해당 파일들 및/또는 일반적으로 블록체인과 관련된 기타 파라미터들 또는 정보를 포함할 수 있다.
[00127] 다른 블록들 내의 파일들(7742 부터 774N)은, 예를 들어, 수행된 처리의 유형에 따라 원본 파일과 동일하거나 또는 제네시스 블록의 원본 파일 내의 수정된 버전일 수 있다. 수행된 처리의 유형은 블록마다 다를 수 있다. 처리는, 예를 들어, 정보를 수정하거나(redacting) 정보의 콘텐츠를 달리 변경하거나, 파일에서 정보를 제거하거나 정보를 파일들에 더하거나, 또는 추가하는 것과 같은, 선행 블록 내의 파일의 모든 수정을 포함할 수 있다.
[00128] 추가적으로, 또는 대안으로, 처리는 단순히 이전 블록에서 파일을 복사하는 것, 파일의 저장 위치를 변경하는 것, 하나 또는 그 이상의 선행 블록들에서 파일을 분석하는 것, 파일을 한 스토리지 또는 메모리 위치에서 다른 위치로 이동하는 것, 또는 블록체인의 파일 및/또는 그 것의 연관된 메타데이터에 관한 조치를 수행하는 것을 포함할 수 있다. 파일을 분석하는 것을 포함하는 처리는, 예를 들어, 파일과 연관된 다양한 분석들, 통계들, 또는 기타 정보를 추가하거나, 포함하거나, 또는 달리 연관시키는 것을 포함할 수 있다.
[00129] 다른 블록들 내의 다른 블록들(7762 부터 776N) 각각에서 값들은 고유한 값들이며 수행된 처리의 결과로서 모두 다르다. 예를 들어, 임의의 한 블록 내의 값은 이전 블록 내의 상기 값의 업데이트된 버전에 대응한다. 업데이트는 상기 값이 할당된 블록의 해시에 반영된다. 따라서 상기 블록들의 값들은 상기 블록들에서 어떤 처리가 수행되었는지에 관한 표시를 제공하고, 또한 블록체인을 통해 원래 파일로 다시 추적하는 것을 허용한다. 이 추적은 전체 블록체인을 통해 파일의 관리 체인(the chain-of-custody of the file)을 확인한다.
[00130] 예를 들어, 파일에 표시된 사람의 신원(ID)을 보호하기 위해 이전 블록 내의 파일 일부분들이 수정(redacted), 차단(blocked out), 또는 픽셀화(pixelated) 되는 경우를 고려해 볼 수 있다. 이 경우에, 수정된 파일을 포함하는 블록은 수정된 파일과 관련된 메타데이터, 예를 들어, 수정이 수행된 방법, 수정을 수행한 사람, 수정(들)이 발생한 타임스탬프들 등을 포함할 것이다. 메타데이터는 상기 값을 형성하기 위해 해시 될 수 있다. 상기 블록에 대한 메타데이터는 이전 블록에서 값을 형성하기 위해 해시 된 정보와 다르기 때문에 상기 값들은 서로 다르고 암호 해독 시 복구될 수 있다.
[00131] 일 실시예에서, 다음 중 어느 하나 또는 그 이상이 발생할 때 현재 블록의 값을 형성하기 위해 이전 블록의 값이 업데이트될 수 있다(예를 들어, 새로운 해시 값이 계산됨). 새로운 해시 값은, 이 예시적인 실시예에서, 아래에 언급된 정보의 전부 또는 일부를 해싱함으로써 계산될 수 있다.
Figure pct00004
[00132] 도 7d는 일 실시예에 따라 블록체인(790)에서 블록들의 구조를 나타낼 수 있는 블록의 실시예를 예시한다. 블록, Blocki은, 헤더(772i), 파일(774i) 및 값(776i)을 포함한다.
[00133] 헤더(772i)는 이전 블록(Blocki-1)의 해시 값 및 추가 참조 정보를 포함하며, 이는, 예를 들어, 여기서 논의된 정보의 유형들(예를 들어, 참조들, 특성들, 파라미터들, 등을 포함하는 헤더 정보) 중 어느 하나의 유형일 수 있다. 물론, 제네시스 블록은 제외하고, 모든 블록들은 이전 블록의 해시를 참조한다. 이전 블록의 해시 값은, 파일 및 메타데이터를 포함하는, 이전 블록 내의 헤더의 해시이거나, 또는 이전 블록 내의 정보 전체 또는 일부의 해시일 수도 있다.
[00134] 파일(774i)은 Data 1, Data 2, …, Data N과 같은 복수의 데이터를 시퀀스로 포함한다. 상기 데이터는 메타데이터 Metadata 1, Metadata 2, …, Metadata N으로 태그가 지정되고, 상기 메타데이터는 상기 데이터와 연관된 콘텐츠 및/또는 특성들을 설명한다. 예를 들어, 각 데이터에 대한 메타데이터는 데이터에 대한 타임스탬프를 표시하고, 데이터를 처리하기 위한 정보, 데이터에 묘사된 사람들 또는 기타 콘텐츠를 표시하는 키워드들, 및/또는 파일 전체의 유효성과 콘텐츠를 설정하는 데 도움이 될 수 있는 기타 특징들, 특히, 예를 들어, 아래에서 논의되는 실시예와 관련하여 설명되는, 디지털 증거로서의 사용을 포함할 수 있다. 메타데이터 외에도, 각 데이터는, 변조, 파일의 갭들 및 파일을 통한 순차적 참조를 방지하기 위해, 참조 REF1, REF2, …, REFN를 사용하여 이전 데이터에 대해 태그를 붙일 수 있다.
[00135] 일단 메타데이터가 데이터에 할당되면(예: 스마트 계약을 통해), 상기 메타데이터는 해시 변경 없이 변경될 수 없으며, 해시의 변경은 무효화를 위해 쉽게 식별될 수 있다. 따라서, 메타데이터는, 블록체인에서 참여자들에 의한 사용을 위해 액세스될 수 있는 정보의 데이터 로그를 생성한다.
[00136] 값(776i)는 해시 값 또는 이전에 논의된 정보의 유형들 중 하나에 기초하여 계산된 다른 값이다. 예를 들어, 임의의 주어진 블록(Blocki)에 대해, 상기 블록에 대한 상기 값은, 상기 블록, 예를 들어, 새로운 해시 값, 새로운 저장 위치, 연관된 파일에 대한 새로운 메타데이터, 컨트롤 또는 액세스, 식별자 또는 기타 조치 또는 추가될 정보의 이전(transfer)에 대해 수행된 처리를 반영하기 위해 업데이트될 수 있다. 각 블록 내의 상기 값이 파일 및 헤더의 데이터를 위해 메타데이터부터 분리된 것으로 도시되었지만, 상기 값은, 다른 실시예에서는 이 메타데이터에, 부분적으로 또는 전체적으로 기초될 수 있다.
[00137] 일단 블록체인(770)이, 어느 시점에서, 형성되면, 상기 파일에 대한 불변의 관리-사슬(the immutable chain-of-custody)은 상기 블록들에 걸친 값들의 트랜잭션 히스토리에 대해 블록체인을 질의함으로써 획득될 수 있다. 이 질의, 또는 추적 절차는, 가장 최근 포함된 블록(예: 마지막(N번째) 블록)의 값을 암호 해독하는 것으로 시작할 수 있고, 그런 다음 제네시스 블록에 도달하고 원본 파일이 복구될 때까지 다른 블록들의 값을 계속 암호 해독함으로써 이루어진다. 상기 암호 해독은 헤더들과 파일들 및 각 블록에서 연관된 메타데이터를 암호 해독하는 것을 포함할 수 있다.
[00138] 암호 해독은 각 블록에서 발생한 암호화 유형에 기초하여 수행된다. 여기에는 개인 키들(private keys), 공개 키들(public keys), 또는 공개 키-개인 키 쌍의 사용이 포함될 수 있다. 예를 들어, 비대칭 암호화가 사용될 때, 네트워크의 블록체인 참여자들 또는 프로세서는 미리 결정된 알고리즘을 사용하여 공개 키와 개인 키 쌍을 생성할 수 있다. 공개 키와 개인 키는 어떤 수학적 관계를 통해 서로 연관된다. 공개 키는, IP 주소 또는 집 주소와 같은, 다른 사용자들로부터 메시지를 수신하는 주소 역할을 하기 위해 공개적으로 배포될 수 있다. 개인 키는 비밀로 유지되며 다른 블록체인 참가자들에게 전송된 메시지들에 디지털 서명하는 데 사용된다. 수신자가 발신자의 공개 키를 사용하여 확인할 수 있도록 서명이 메시지에 포함된다. 이렇게 하면, 수신자는 발신자만 이 메시지를 보낼 수 있었을 것이라고 확신할 수 있게 된다.
[00139] 키 쌍을 생성하는 것은 블록체인에서 계정을 생성하는 것과 유사할 수 있지만, 실제로 어디에 등록할 필요는 없다. 또한, 블록체인에서 실행되는 모든 트랜잭션은 발신자가 개인 키를 사용하여 디지털 서명한다. 이 서명은 계정 소유자만 블록체인의 파일을 추적하고 처리할 수 있음을 보장한다(스마트 계약에 의해 결정된 권한 범위 내에 있다면).
[00140] 도 8a 및 8b는 여기에 통합되고 사용될 수 있는 블록체인에 대한 사용 사례들의 추가 예들을 도시한다. 특히, 도 8a는 머신 러닝(인공 지능) 데이터를 저장하는 블록체인(810)의 예(800)를 도시한다. 머신 러닝은 새로운 데이터에 대한 정확한 예측을 위한 예측 모델들을 구축하기 위해 방대한 양들의 히스토리 데이터(또는 훈련 데이터)에 의존한다. 머신 러닝 소프트웨어(예: 신경망들 등)는 종종 수백만 개의 기록들을 선별하여 직관적이지 않은 패턴들을 찾아낼 수 있다(unearth).
[00141] 도 8a의 예에서, 호스트 플랫폼(820)은 자산(830)의 예측 모니터링을 위한 머신 러닝 모델을 구축하고(build) 및 배치한다(deploy). 여기서, 호스트 플랫폼(820)은 클라우드 플랫폼, 산업용 서버, 웹 서버, 퍼스널 컴퓨터, 사용자 디바이스 등일 수 있다. 자산들(830)은 항공기, 기관차, 터빈, 의료 기계 및 장비, 석유 및 가스 장비, 보트들, 선박들, 차량들 등과 같은 모든 유형의 자산(예: 머신 또는 장비 등)일 수 있다. 다른 예로서, 자산들(830)은 주식들, 통화, 디지털 코인들, 보험 등과 같은 무형 자산일 수 있다.
[00142] 블록체인(810)은 머신 러닝 모델의 훈련 프로세스(802)와 훈련된 머신 러닝 모델에 기초한 예측 프로세스(804) 모두를 상당히 개선하는데 사용될 수 있다. 예를 들어, 단계(802)에서, 데이터 과학자/엔지니어 또는 다른 사용자가 데이터를 수집하도록 요구하기보다, 히스토리 데이터는 자산들(830) 자체에 의해(또는 중개자를 통해, 도시되지 않음) 블록체인(810)에 저장될 수 있다. 이것은 예측 모델 훈련을 수행할 때 호스트 플랫폼(820)에 의해 필요한 수집 시간을 상당히 감소시킬 수 있다. 예를 들어, 스마트 계약들을 사용하면, 데이터를 원래 위치에서 블록체인(810)으로 직접 안정적으로 이전될(transferred) 수 있다. 블록체인(810)을 사용하여 수집된 데이터의 보안 및 소유권을 보장함으로써, 스마트 계약들은 자산들의 데이터를 머신 러닝 모델을 구축하기 위해 데이터를 사용하는 개인에게 직접 보낼 수 있다. 이것은 자산들(830) 사이에서 데이터 공유를 허용한다.
[00143] 수집된 데이터는 합의 메커니즘에 따라 블록체인(810)에 저장될 수 있다. 합의 메커니즘은 기록되는 데이터가 확인되었고 정확하다는 것을 보장하기 위해 (허가된 노드들에) 가져온다. 기록된 데이터는 타임-스탬프가 찍혔고, 암호로 서명되었으며 변경할 수 없다. 따라서 감사 가능하고, 투명하며, 안전하다. 특정 경우들에서(예: 공급망, 의료, 물류 등), 블록체인에 직접 기록하는(write) IoT 디바이스들 추가하면, 기록되는 데이터의 빈도와 정확성이 모두 증가할 수 있다.
[00144] 또한, 수집된 데이터에 관한 머신 러닝 모델의 훈련은 호스트 플랫폼(820)에 의한 개선(refinement) 및 시험의 라운드들(rounds)을 거칠 수 있다. 각 라운드는 추가 데이터 또는 이전에 머신 러닝 모델에 대한 지식을 확장하는데 도움을 주기 위해 고려하지 않았던 데이터에 기초할 수 있다. 단계(802)에서, 상기 서로 다른 훈련 및 시험 단계들(및 이와 연관된 데이터)은 블록체인(810)에 저장될 수 있다. 상기 머신 러닝 모델에 관한 각각의 개선(예: 변수, 가중치 등의 변경)은 블록체인(810)에 저장될 수 있다. 이것은 상기 모델이 어떻게 훈련되었고 어떤 데이터가 모델을 훈련시키는 데 사용되었는지에 대해 확인 가능 증명(verifiable proof)을 제공한다. 또한, 호스트 플랫폼(820)이 최종적으로 훈련된 모델을 달성하였을 때, 최종 모델은 블록체인(810)에 저장될 수 있다.
[00145] 상기 모델은 훈련된 후, 실제(live) 환경에 배치되어 최종 훈련된 머신 러닝 모델의 실행에 기초한 예측들/결정들을 내릴 수 있다. 예를 들어, 단계(804)에서, 머신 러닝 모델은 항공기, 풍력 터빈, 의료 기계 등과 같은 자산에 대한 상태-기반 유지 관리(CBM)를 위해 사용될 수 있다. 이 예에서, 자산들(830)으로부터 피드백 된 데이터는 머신 러닝 모델에 입력되어 실패 이벤트들, 오류 코드들, 등과 같은 이벤트 예측들을 하는 데 사용될 수 있다. 호스트 플랫폼(820)에서 머신 러닝 모델을 실행하여 이루어진 결정들은 블록체인(810)에 저장되어 감사 가능/확인 가능 증명을 제공할 수 있다. 하나의 비-제한적인 예로서, 머신 러닝 모델은 자산들(830)의 일부분에 대한 미래의 폭락/실패(breakdown/failure)를 예측할 수 있고 그 부분을 대체하기 위한 경고 또는 통지를 생성할 수 있다. 이 결정 배후의 데이터는 블록체인(810)의 호스트 플랫폼(820)에 의해 저장될 수 있다. 일 실시예에서, 여기에 설명되고 및/또는 묘사된 특징들 및/또는 조치들은 블록체인(810)에서 또는 블록체인(810)과 관련하여 발생할 수 있다.
[00146] 블록체인을 위한 새로운 트랜잭션들은 새로운 블록에 함께 모여서 기존 해시 값에 추가될 수 있다. 그런 다음 이 것은 새로운 블록을 위한 새로운 해시를 생성하기 위해 암호화된다. 그들이 암호화될 때, 이 것은 트랜잭션들의 다음 목록에 추가되며, 그 다음도 그러하다. 그 결과 각 블록은 이전의 모든 블록들의 해시 값들을 포함하는 블록들의 체인이 형성된다. 이들 블록들을 저장하는 컴퓨터들은 그들의 해시 값들을 정기적으로 비교하여 그들 모두가 합의 상태에(in agreement)있음을 보장한다. 합의하지 않는 모든 컴퓨터는, 문제를 일으키고 있는 기록들을 폐기한다. 이 접근 방식은 블록체인의 변조-방지를 보장하는 데는 좋지만, 완벽하지는 않다.
[00147] 이 시스템을 게임하는 한 가지 방법은 부정직한 사용자가 트랜잭션들의 목록을 자신에게 유리하게 변경하지만, 해시는 변경되지 않은 상태로 남게 해 보는 것이다. 이것은 무차별 대입에 의해서, 달리 말하면, 기록을 변경하고, 그 결과를 암호화하며, 해시 값이 동일한지를 봄으로써, 행해질 수 있다. 만일 해시 값이 동일하지 않다면, 일치(match)하는 해시를 찾을 때까지 계속해서 시도한다. 블록체인들의 보안은 일반 컴퓨터들이 우주의 나이와 같이, 완전히 비현실적인 시간 규모들을 통해서만 이러한 종류의 무차별 대입 공격을 수행할 수 있다는 믿음을 기반으로 한다. 대조적으로, 양자 컴퓨터들은 훨씬 더 빠르며(1000배 더 빠름) 결과적으로 훨씬 더 큰 위협을 준다.
[00148] 도 8b는 양자 컴퓨팅 공격으로부터 보호하기 위해 양자 키 분배(QKD)를 구현하는 양자-보안 블록체인(852)의 예(850)를 도시한다. 이 예에서, 블록체인 사용자들은 QKD를 사용하여 서로의 ID들을 확인할 수 있다. 이것은 도청자가 파괴하지 않고는 복사할 수 없는, 광자들과 같은 양자 입자들을 사용하여 정보를 전송한다. 이와 같이, 블록체인을 통해 발신자와 수신자는 서로의 ID를 확인할 수 있다.
[00149] 도 8b의 예에는, 4명의 사용자들 (854, 856, 858 및 860)이 존재한다. 사용자들 쌍 각각은 그들 사이에 비밀 키(862)(즉, QKD)를 공유할 수 있다. 이 예에서는 4개의 노드들이 있으므로 6개의 노드들 쌍들이 존재하고, 따라서 QKDAB, QKDAC, QKDAD, QKDBC, QKDBD, 및 QKDCD를 포함하는 6개의 다른 비밀 키들(862)이 사용된다. 각 쌍은, 도청자가 파괴하지 않고는 복사할 수 없는 광자들과 같은, 양자 입자들을 사용하여, 정보를 전송함에 의하여 QKD를 생성할 수 있다. 이러한 방식으로, 한 쌍의 사용자들은 서로의 ID를 확인할 수 있다.
[00150] 블록체인(852)의 연산(operation)은 (i) 트랜잭션들의 생성, 및 (ii) 새로운 트랜잭션들을 집계하는(aggregate) 블록들 구축(construction)의 두 가지 절차들에 기초한다. 새로운 트랜잭션들은 기존 블록체인 네트워크와 유사하게 생성될 수 있다. 각 트랜잭션은, 발신자, 수신자, 생성 시간, 이전될 양(또는 가치), 발신자가 연산을 위해 펀드들(funds)을 보유하고 있음을 정당화하는 참조 트랜잭션들 목록, 등에 관한 정보를 포함할 수 있다. 그런 다음 이 트랜잭션 기록은 다른 모든 노드들 전송되고, 이들 노들에서 그 것은 미확인 트랜잭션들 풀에 입력된다. 여기서, 두 당사자들(즉, 사용자들(854-860) 중 한 쌍의 사용자들)은 공유 비밀 키(862)(QKD)를 제공함으로써 상기 트랜잭션을 인증한다. 이 양자 서명(quantum signature)은 모든 트랜잭션에 첨부될 수 있어 변조하기가 매우 어렵다. 각 노드는 각 트랜잭션이 충분한 펀드들을 가지고 있는지 확인하기 위해 블록체인(852)의 로컬 사본에 관하여 그들의 엔트리들을 체크한다. 그러나, 트랜잭션들은 아직 확인된(confirmed) 것이 아니다.
[00151] 블록들에 관해 기존의 마이닝 프로세스를 수행하는 대신, 블록들은 브로드캐스트 프로토콜을 사용하여 탈중앙 방식으로(in decentralized manner) 생성될 수 있다. 미리 결정된 기간(예: 초, 분, 시간 등)에, 네트워크는 브로드캐스트 프로토콜을 모든 미확인 트랜잭션에 적용하여 이에 의하여 트랜잭션의 올바른 버전에 관한 비잔틴 합의(Byzantine agreement) (consensus)를 달성할 수 있다. 예를 들어, 각 노드는 개인 값(a private value)(특정 노드의 트랜잭션 데이터)을 가질 수 있다. 제1 라운드에서, 노드들은 그들의 개인 값들을 서로에게 전송한다. 후속 라운드들에서, 노드들은 그들이 이전 라운드에서 다른 노드들로부터 수신한 정보를 전달한다. 여기서, 정직한 노드들은 새로운 블록 내에서 완전한 트랜잭션들 세트를 생성할 수 있다. 이 새로운 블록은 블록체인(852)에 추가될 수 있다. 일 실시예에서, 여기에서 설명되고 및/또는 묘사된 특징들 및/또는 조치들은 블록체인(852) 상에서 또는 블록체인(852)에 대해 발생할 수 있다.
[00152] 도 9는 여기에 설명되고 및/또는 도시된 예시적인 실시예들 중 하나 또는 그 이상을 지원하는 예시적인 시스템(900)을 도시한다. 시스템(900)은 컴퓨터 시스템/서버(902)를 포함하며, 이는 다수의 다른 범용 또는 특수 목적 컴퓨팅 시스템 환경들 또는 구성들과 함께 운영된다. 컴퓨터 시스템/서버(902)와 함께 사용하기에 적합할 수 있는 잘 알려진 컴퓨팅 시스템들, 환경들 및/또는 구성들의 예들은, 개인용 컴퓨터 시스템들, 서버 컴퓨터 시스템들, 씬(thin) 클라이언트들, 씩(thick) 클라이언트들, 휴대용 또는 랩톱 장치들, 다수 프로세서 시스템들, 마이크로 프로세서-기반 시스템들, 셋톱 박스들, 프로그래밍 가능한 소비자 전자 제품들, 네트워크 PC들, 미니 컴퓨터 시스템들, 메인프레임 컴퓨터 시스템들, 및 상기 시스템들 또는 디바이스들 등을 포함하는 분산 클라우드 컴퓨팅 환경들을 포함한다.
[00153] 컴퓨터 시스템/서버(902)는 컴퓨터 시스템에 의해 실행되는, 프로그램 모듈들과 같은 컴퓨터 시스템 실행-가능 명령들의 일반적인 맥락에서 설명될 수 있다. 일반적으로, 프로그램 모듈들은 특정 작업들을 수행하거나 특정 추상 데이터 유형들을 구현하는 루틴들, 프로그램들, 개체들, 컴포넌트들, 논리, 데이터 구조들, 등을 포함할 수 있다. 컴퓨터 시스템/서버(902)는 통신들 네트워크를 통해 연결된 원격 처리 디바이스들에 의해 작업들(tasks)이 수행되는 분산 클라우드 컴퓨팅 환경들에서 실행될 수 있다. 분산 클라우드 컴퓨팅 환경에서 프로그램 모듈들은 메모리 스토리지 디바이스들을 포함하는 로컬 및 원격 컴퓨터 시스템 저장 매체 모두에 위치할 수 있다.
[00154] 도 9에 도시된 바와 같이, 클라우드 컴퓨팅 노드(900)의 컴퓨터 시스템/서버(902)는 범용 컴퓨팅 장치의 형태로 도시된다. 컴퓨터 시스템/서버(902)의 컴포넌트들은 하나 또는 그 이상의 프로세서 또는 처리 유닛들(904), 시스템 메모리(906), 및 시스템 메모리(906)를 포함하는 다양한 시스템 컴포넌트들을 프로세서(904)에 연결하는 버스를 포함할 수 있지만, 이에 국한되지 않는다.
[00155] 상기 버스는 메모리 버스 또는 메모리 컨트롤러, 주변 장치 버스, 가속 그래픽 포트, 다양한 버스 아키텍처들을 사용하는 프로세서 또는 로컬 버스를 포함하는 여러 유형들의 버스 구조들 중 하나 또는 그 이상을 나타낸다. 예를 들어, 그러한 아키텍처는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스 및 주변 장치 컴포넌트 상호 연결(PCI) 버스를 포함한다.
[00156] 컴퓨터 시스템/서버(902)는 일반적으로 다양한 컴퓨터 시스템 판독가능 매체를 포함한다. 이러한 매체는 컴퓨터 시스템/서버(902)에 의해 액세스 가능한 모든 이용 가능한 매체일 수 있으며, 휘발성 및 비-휘발성 매체, 이동식 및 비-이동식 매체를 모두 포함한다. 일 실시예에서, 시스템 메모리(906)는 다른 도면들의 플로 다이어그램들을 구현한다. 시스템 메모리(906)는 랜덤 액세스 메모리(RAM)(910) 및/또는 캐시 메모리(912)와 같은 휘발성 메모리 형태의 컴퓨터 시스템 판독 가능 매체를 포함할 수 있다. 컴퓨터 시스템/서버(902)는 다른 착탈식/비-이동식, 휘발성/비-휘발성 컴퓨터 시스템 저장 매체를 더 포함할 수 있다. 단지 예로서, 스토리지 시스템(914)은 비-이동식, 비-휘발성 자기 매체(도시되지 않고 일반적으로 "하드 드라이브"라고 함)로부터 읽고 쓰기 위해 제공될 수 있다. 도시되지는 않았지만, 이동식 비-휘발성 자기 디스크(예: "플로피 디스크")에서 읽고 쓰기 위한 자기 디스크 드라이브, 및 이동식 비-휘발성 광학 디스크에서 읽거나 쓰기 위한 광학 디스크 드라이브 CD-ROM, DVD-ROM 또는 기타 광학 매체와 같은 디스크를 제공할 수 있다. 이러한 경우, 각각은 하나 또는 그 이상의 데이터 미디어 인터페이스들을 통해 버스에 연결될 수 있다. 아래에서 추가로 도시되고 설명되는 바와 같이, 메모리(906)는 애플리케이션의 다양한 실시예들의 기능들을 수행하도록 구성된 프로그램 모듈들의 세트(예를 들어, 적어도 하나)를 갖는 적어도 하나의 프로그램 제품을 포함할 수 있다.
[00157] 프로그램 모듈들(918)의 세트(적어도 하나)를 갖는 프로그램/유틸리티 (916)는, 예를 들어 메모리(906)에 저장될 수 있으며, 또한 운영 체제, 하나 또는 그 이상의 애플리케이션들, 기타 프로그램 모듈들 및 프로그램 데이터도 저장될 수 있으나, 이에 국한되지는 않는다. 각각의 운영 체제, 하나 또는 그 이상의 애플리케이션 프로그램들, 다른 프로그램 모듈들, 및 프로그램 데이터 또는 이들의 일부 조합은 네트워킹 환경의 구현을 포함할 수 있다. 프로그램 모듈들(918)은 일반적으로 여기서 기술된 바와 같은 애플리케이션의 다양한 실시예들의 기능들 및/또는 방법들을 수행한다.
[00158] 당업자에 의해 이해되는 바와 같이, 본 출원의 실시 예들은 시스템, 방법, 또는 컴퓨터 프로그램 제품으로서 구현될 수 있다. 따라서, 본 출원의 특징들은 전체 하드웨어 실시예, 전체 소프트웨어 실시예(펌웨어, 상주 소프트웨어, 마이크로 코드 등 포함) 또는 일반적으로 모두 참조될 수 있는 소프트웨어 및 하드웨어 특징을 결합한 실시예의 형태를 취할 수 있고, 여기에서 "회로", "모듈" 또는 "시스템"이라 한다. 또한, 본 출원의 실시 예는 컴퓨터 판독가능 프로그램 코드가 구현된 하나 또는 그 이상의 컴퓨터 판독가능 매체(들)에 구현된 컴퓨터 프로그램 제품의 형태를 취할 수 있다.
[00159] 컴퓨터 시스템/서버(902)는 또한 키보드, 포인팅 장치, 디스플레이(922) 등과 같은 하나 또는 그 이상의 외부 디바이스들(920); 사용자가 컴퓨터 시스템/서버(902)와 상호작용할 수 있게 하는 하나 또는 그 이상의 디바이스들; 및/또는 컴퓨터 시스템/서버(902)가 하나 또는 그 이상의 다른 컴퓨팅 디바이스들과 통신할 수 있게 하는 모든 디바이스(예를 들어, 네트워크 카드, 모뎀 등)와 통신할 수도 있다. 그러한 통신은 I/O 인터페이스(924)를 통해 발생할 수 있다. 또한, 컴퓨터 시스템/서버(902)는 네트워크 어댑터(926)를 통해 근거리 통신망(LAN), 일반 광역 통신망(WAN) 및/또는 공공 네트워크(예: 인터넷)와 같은 하나 또는 그 이상의 네트워크와 통신할 수 있다. 도시된 바와 같이, 네트워크 어댑터(926)는 버스를 통해 컴퓨터 시스템/서버(902)의 다른 컴포넌트들과 통신한다. 도시되지는 않았지만, 다른 하드웨어 및/또는 소프트웨어 컴포넌트들이 컴퓨터 시스템/서버(902)와 함께 사용될 수 있음을 이해해야 한다. 예에는, 마이크로코드, 장치 드라이버들, 중복 처리 디바이스들, 외부 디스크 드라이브 어레이들, RAID 시스템들, 테이프 드라이브들, 및 데이터 보관 스토리지 시스템들 등이 포함되지만 이에 국한되지는 않는다.
[00160] 시스템, 방법, 및 비일시적 컴퓨터 판독 가능 매체 중 적어도 하나의 예시적인 실시예가 첨부 도면들에 예시되어 있고 전술한 상세한 설명에서 설명되었지만, 본 출원은 개시된 실시예들로 제한되지 않고, 다음 청구범위들에 의해 설명되고 정의된 바와 같이 수많은 재배열들, 수정들 및 대체들이 가능하다는 것이 이해될 것이다. 예를 들어, 다양한 도면들의 시스템 기능들은 여기에 설명된 하나 또는 그 이상의 모듈들 또는 컴포넌트들에 의해 수행될 수 있거나 분산 아키텍처에서 전송기, 수신기 또는 둘 다의 쌍을 포함할 수 있다. 예를 들어, 개별 모듈들에 의해 수행되는 기능의 전부 또는 일부는 이러한 모듈들 중 하나 또는 그 이상에 의해 수행될 수 있다. 또한, 여기에 설명된 기능은 다양한 시간들에 다양한 이벤트들과 관련하여 모듈들 또는 컴포넌트들의 내부 또는 외부에서 수행될 수 있다. 또한, 다양한 모듈 간에 전송되는 정보는 데이터 네트워크, 인터넷, 음성 네트워크, 인터넷 프로토콜 네트워크, 무선 디바이스, 유선 디바이스 및/또는 복수의 프로토콜들 중 적어도 하나를 통해 모듈들 간에 전송될 수 있다. 또한, 임의의 모듈들에 의해 전송되거나 수신된 메시지들은 직접 및/또는 다른 모듈들 중 하나 또는 그 이상을 통해 전송 또는 수신될 수 있다.
[00161] 당업자는 "시스템"이 개인용 컴퓨터, 서버, 콘솔, 개인 휴대 정보 단말기(PDA), 휴대 전화, 태블릿 컴퓨팅 장치, 스마트폰 또는 기타 적절한 컴퓨팅 디바이스, 또는 디바이스들의 조합으로 구현될 수 있음을 인식할 것이다. "시스템"에 의해 수행되는 것으로 전술한 기능들을 제시하는 것은 어떤 식으로 본 출원의 범위를 제한하려고 의도되지 않았고 많은 실시예들 중 하나의 예를 제공하도록 의도된다. 실제로, 여기에 개시된 방법들, 시스템들 및 디바이스들은 컴퓨팅 기술과 일치하는 국부적이고 분산된 형태로 구현될 수 있다.
[0162] 전술한 실시예들 중 하나 또는 그 이상에 따라, 탈중앙화된 데이터베이스에서 정보의 저장을 관리하는 단계, 특히 블록체인을 포함하되 이에 국한되지 않는 탈중앙화된 데이터베이스를 위해 트랜잭션들 및 기타 이벤트 데이터를 관리하는 단계에서 개선을 나타내는 시스템, 방법 및 컴퓨터 판독 가능 매체가 제공된다.
[0163] 일 실시예에서, 상기 실시예들 중 하나 또는 그 이상은 비잔틴 클라이언트들(byzantine clients)이 유효하지만, 특정 동작에 대응하는 이벤트들을 내보내는 것처럼 보이나, 상기 동작을 수행하지 않은 시스템에 오해를 일으키도록 형성된 트랜잭션들(misleadingly formed transactions)을 삽입하는 것을 방지함으로써 문제들을 해결한다. 기존 데이터베이스에서는, 모든 검증 노드에 대해 신뢰가 있다고 가정하기 때문에 모든 참여자가 진입할 때(at ingress) 트랜잭션들은 안전하게 필터링 될 수 있다. 이와 대조적으로, 본 발명의 하나 또는 그 이상의 실시예들에 따르면, 다양한 참여자들은 다양한 권한들 및/또는 다양한 상태들을 가질 수 있고 다양한 상태들은 그들을 수정하기 위해 다양한 보증들을 요구하기 때문에, 이들 하나 또는 그 이상의 실시예들은 전통적인 데이터베이스 하에서 동작할 수 없다.
[0164] 더욱이, 본 명세서에 기술된 하나 또는 그 이상의 실시예들은 공격 표면(an attack surface)(달리 유효한 트랜잭션들에 관한 스푸핑된 이벤트들(spoofed events))을 제거함으로써 클라이언트 애플리케이션의 보안을 향상시킨다. 또한, 하나 또는 그 이상의 실시예들은 탈중앙화된 데이터베이스에 새로운 유형의 데이터를 저장하고 관리할 수 있다. 예를 들어, 새로운 데이터는 이벤트를 캡슐화하는 트랜잭션 내부에 저장될 수 있다. 이 추가 데이터는 트랜잭션을 검증하는 데 필요한 것보다 더 많은 검증 체크들을 수행하기 위해 트랜잭션 검증 컴포넌트에 의해 활용될 수 있다. 이 추가 데이터는 이제 안전하게 이벤트를 처리할 수 있는 클라이언트에 의해 소비될 수 있는데, 왜냐하면 트랜잭션이 유효한 것으로 표시되면, 클라이언트는 이들 데이터에 대한 추가 보안 체크들이 수행되었음을 알기 때문이다.
[00165] 본 명세서에 설명된 시스템 기능들 중 일부는 구현 독립성을 보다 구체적으로 강조하기 위해, 모듈들로 제시되었다는 점에 유의해야 한다. 예를 들어, 모듈은 맞춤형 VLSI(Very Large-Scale Integration) 회로들 또는 게이트 어레이들, 논리 칩들, 트랜지스터들 또는 기타 개별 부품들과 같은 기성품 반도체들을 포함하는 하드웨어 회로로 구현될 수 있다. 모듈은 또한 필드 프로그램 가능 게이트 어레이, 프로그램 가능 어레이 로직, 프로그램 가능 논리 디바이스들, 그래픽 처리 유닛들 등과 같은 프로그램 가능 하드웨어 디바이스로 구현될 수 있다.
[00166] 모듈은 또한 다양한 유형의 프로세서들에 의한 실행을 위해 소프트웨어에서 적어도 부분적으로 구현될 수 있다. 실행 가능한 코드의 식별된 단위는, 예를 들어, 개체, 절차 또는 기능으로 구성될 수 있는 컴퓨터 명령들의 하나 또는 그 이상의 물리적 또는 논리적 블록들을 포함할 수 있다. 그럼에도 불구하고, 식별된 모듈의 실행 파일은 물리적으로 함께 위치할 필요는 없지만, 논리적으로 함께 결합될 때 모듈을 구성하고 모듈에 대해 명시된 목적을 달성하는 다른 위치들에 저장된 이종 명령들을 포함할 수 있다. 또한, 모듈들은 컴퓨터 판독 가능 매체에 저장될 수 있으며, 이는, 예를 들어, 하드 디스크 드라이브, 플래시 장치, 랜덤 액세스 메모리(RAM), 테이프 또는 데이터를 저장하는 데 사용되는 임의의 다른 매체일 수 있다.
[00167] 실제로, 실행 가능한 코드의 모듈은 단일 명령, 또는 여러 명령들이 될 수 있으며, 여러 다른 코드 세그먼트들에 걸쳐, 다른 프로그램들 간에, 여러 메모리 디바이스들에 걸쳐 분산될 수도 있다. 유사하게, 연산 데이터는 여기에서 모듈들 내에서 식별 및 설명될 수 있으며 임의의 적절한 형태로 구현되고 임의의 적절한 유형의 데이터 구조 내에서 구성될 수 있다. 연산 데이터는 단일 데이터 세트로 수집되거나 다른 스토리지 디바이스들을 비롯한 여러 위치들에 분산될 수 있으며, 적어도 부분적으로는 시스템 또는 네트워크에서 단지 전자 신호들로 존재할 수 있다.
[00168] 본 명세서의 도면에서 일반적으로 설명되고 예시된 바와 같이, 애플리케이션의 컴포넌트들은 매우 다양한 다른 구성들로, 배열 및 설계될 수 있다는 것을 쉽게 이해할 것이다. 따라서, 실시예의 상세한 설명은 청구된 바와 같은 애플리케이션의 범위를 제한하려는 것이 아니라 단지 애플리케이션의 선택된 실시예들을 대표하는 것이다.
[00169] 당해 기술 분야의 통상의 지식을 가진 자는 상기 실시 예들은 다른 순서의 단계들 및/또는 개시된 것과 다른 구성의 하드웨어 엘리멘트로 실시될 수 있음을 쉽게 이해할 것이다. 따라서, 이러한 바람직한 실시예들에 기초하여 애플리케이션이 설명되었지만, 특정 수정들, 변형들 및 대안적인 구성들이 명백할 것이라는 것은 당업자에게 명백할 것이다.
[00170] 본 출원의 바람직한 실시예들이 설명되었지만, 설명된 실시예들은 단지 예시일 뿐이며 전체 범위의 균등물들 및 수정들(예: 프로토콜들, 하드웨어 디바이스들, 소프트웨어 플랫폼들 등)을 고려하여 본 출원의 범위는 첨부된 청구범위에 의해서만 정의되어야 함을 이해해야 한다.

Claims (20)

  1. 시스템에 있어서, 상기 시스템은:
    주체(an entity)로부터 이벤트 데이터를 수신하기 위한 수신기;
    스마트 계약의 코드를 저장하기 위한 스토리지 영역; 및
    상기 스마트 계약을 실행하기 위한 프로세서를 포함하고, 상기 프로세서는:
    상기 이벤트 데이터가 보증 정책을 만족하는지를 결정하는 단계;
    상기 이벤트 데이터의 컨텍스트에 대응하는 식별자를 세트 하는 단계;
    상기 이벤트 데이터 및 상기 식별자를 포함하는 이벤트를 생성하는 단계; 및
    탈중앙화된 데이터베이스(a decentralized database)에 기록하기 위해 이벤트를 제출하는 단계를 수행하고, 상기 식별자는 상기 이벤트 데이터의 컨텍스트와 대응하는 상태가 올바른지(correct)를 검증하는
    시스템.
  2. 제1항에 있어서, 상기 식별자는 상기 이벤트 데이터의 컨텍스트에 대응하여 이전에 생성된 키 정보를 포함하는
    시스템.
  3. 제1항에 있어서, 상기 이벤트 데이터의 컨텍스트는 상기 데이터베이스에 의해서 관리되는 객체(an object)를 참조하는
    시스템.
  4. 제1항에 있어서, 상기 이벤트 데이터의 컨텍스트는 상기 데이터베이스에 대응하는 채널 이름, 네임스페이스, 컬렉션 또는 키 이름 중 적어도 두 개를 포함하는 튜플(a tuple)을 포함하는
    시스템.
  5. 제1항에 있어서, 상기 이벤트 데이터의 컨텍스트는 상기 데이터베이스에 대응하는 채널 이름, 네임스페이스, 컬렉션 및 키 이름을 포함하는 튜플을 포함하는
    시스템.
  6. 제1항에 있어서, 상기 프로세서는 상기 이벤트에 대응하는 포맷의 소정 필드에 상기 식별자의 삽입을 포함하는 동작들에 따라 이벤트를 생성하는
    시스템.
  7. 제1항에 있어서,
    상기 컨텍스트는 상기 데이터베이스에 의해서 관리되는 객체 또는 네임스페이스이며, 그리고
    상기 식별자는 상기 객체 또는 네임스페이스를 위해 사전-인증된(pre-authenticated)
    시스템.
  8. 방법에 있어서, 상기 방법은:
    주체(an entity)로부터 이벤트 데이터를 수신하는 단계;
    상기 이벤트 데이터가 보증 정책을 만족하는지를 결정하는 단계;
    상기 이벤트 데이터의 컨텍스트에 대응하는 식별자를 세트 하는 단계;
    상기 이벤트 데이터 및 상기 식별자를 포함하는 이벤트를 생성하는 단계; 및
    탈중앙화된 데이터베이스(a decentralized database)에 기록하기 위해 이벤트를 제출하는 단계를 포함하고, 상기 식별자는 상기 이벤트 데이터의 컨텍스트와 대응하는 상태가 올바른지(correct)를 검증하기 위해 사용되는
    방법.
  9. 제8항에 있어서, 상기 식별자는 상기 이벤트 데이터의 컨텍스트에 대응하여 이전에 생성된 키 정보를 포함하는
    방법.
  10. 제8항에 있어서, 상기 이벤트 데이터의 컨텍스트는 상기 데이터베이스에 의해서 관리되는 객체(an object)를 참조하는
    방법.
  11. 제8항에 있어서, 상기 이벤트 데이터의 컨텍스트는 상기 데이터베이스에 대응하는 채널 이름, 네임스페이스, 컬렉션 또는 키 이름 중 적어도 두 개를 포함하는 튜플(a tuple)을 포함하는
    방법.
  12. 제8항에 있어서, 상기 이벤트 데이터의 컨텍스트는 상기 데이터베이스에 대응하는 채널 이름, 네임스페이스, 컬렉션 및 키 이름을 포함하는 튜플을 포함하는
    방법.
  13. 제8항에 있어서, 상기 이벤트를 생성하는 단계는 상기 이벤트에 대응하는 포맷의 소정 필드에 상기 식별자를 삽입하는 단계를 포함하는
    방법.
  14. 제8항에 있어서,
    상기 컨텍스트는 상기 데이터베이스에 의해서 관리되는 객체 또는 네임스페이스이며, 그리고
    상기 식별자는 상기 객체 또는 네임스페이스를 위해 사전-인증된(pre-authenticated)
    방법.
  15. 비-일시적 컴퓨터 판독 매체에 있어서, 상기 비-일시적 컴퓨터 판독 매체는 명령들을 저장하고, 상기 명령들은 하나 또는 그 이 상의 프로세서에 의해 실행되었을 때 상기 하나 또는 그 이상의 프로세서가:
    주체(an entity)로부터 이벤트 데이터를 수신하는 단계;
    상기 이벤트 데이터가 보증 정책을 만족하는지를 결정하는 단계;
    상기 이벤트 데이터의 컨텍스트에 대응하는 식별자를 세트 하는 단계;
    상기 이벤트 데이터 및 상기 식별자를 포함하는 이벤트를 생성하는 단계; 및
    탈중앙화된 데이터베이스(a decentralized database)에 기록하기 위해 이벤트를 제출하는 단계를 수행하도록 하고, 상기 식별자는 상기 이벤트 데이터의 컨텍스트와 대응하는 상태가 올바른지(correct)를 검증하는
    비-일시적 컴퓨터 판독 매체.
  16. 제15항에 있어서, 상기 식별자는 상기 이벤트 데이터의 컨텍스트에 대응하여 이전에 생성된 키 정보를 포함하는
    비-일시적 컴퓨터 판독 매체.
  17. 제15항에 있어서, 상기 이벤트 데이터의 컨텍스트는 상기 데이터베이스에 의해서 관리되는 객체(an object)를 참조하는
    비-일시적 컴퓨터 판독 매체.
  18. 제15항에 있어서, 상기 이벤트 데이터의 컨텍스트는 상기 데이터베이스에 대응하는 채널 이름, 네임스페이스, 컬렉션 또는 키 이름 중 적어도 두 개를 포함하는 튜플(a tuple)을 포함하는
    비-일시적 컴퓨터 판독 매체.
  19. 제15항에 있어서, 상기 이벤트를 생성하는 단계는 상기 이벤트에 대응하는 포맷의 소정 필드에 상기 식별자를 삽입하는 단계를 포함하는
    비-일시적 컴퓨터 판독 매체.
  20. 제15항에 있어서,
    상기 컨텍스트는 상기 데이터베이스에 의해서 관리되는 객체 또는 네임스페이스이며, 그리고
    상기 식별자는 상기 객체 또는 네임스페이스를 위해 사전-인증된(pre-authenticated)
    비-일시적 컴퓨터 판독 매체.
KR1020227042214A 2020-06-30 2021-05-18 탈중앙화된 데이터베이스에서 허가된 이벤팅 KR20230005353A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/917,247 2020-06-30
US16/917,247 US20210406876A1 (en) 2020-06-30 2020-06-30 Permissioned eventing in a decentralized database
PCT/IB2021/054257 WO2022003436A1 (en) 2020-06-30 2021-05-18 Permissioned eventing in a decentralized database

Publications (1)

Publication Number Publication Date
KR20230005353A true KR20230005353A (ko) 2023-01-09

Family

ID=79031106

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227042214A KR20230005353A (ko) 2020-06-30 2021-05-18 탈중앙화된 데이터베이스에서 허가된 이벤팅

Country Status (9)

Country Link
US (1) US20210406876A1 (ko)
JP (1) JP2023530594A (ko)
KR (1) KR20230005353A (ko)
CN (1) CN115668856A (ko)
AU (1) AU2021300620B2 (ko)
CA (1) CA3180249A1 (ko)
GB (1) GB2611687A (ko)
IL (1) IL298416A (ko)
WO (1) WO2022003436A1 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220129445A1 (en) * 2020-10-28 2022-04-28 Salesforce.Com, Inc. Keyspace references
CN115756439B (zh) * 2022-10-20 2024-02-13 乾三(北京)科技有限公司 一种状态机引擎编排方法、装置及计算机设备
WO2024096914A1 (en) * 2022-10-31 2024-05-10 Venkataraman Mohan Blockchain based document and data sharing

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150379510A1 (en) * 2012-07-10 2015-12-31 Stanley Benjamin Smith Method and system to use a block chain infrastructure and Smart Contracts to monetize data transactions involving changes to data included into a data supply chain.
WO2017091530A1 (en) * 2015-11-24 2017-06-01 Gartland & Mellina Group Blockchain solutions for financial services and other transaction-based industries
EP3193299A1 (en) * 2016-01-15 2017-07-19 Accenture Global Services Limited Device, method and system for autonomous selection of a commodity supplier through a blockchain distributed database
US11940978B2 (en) * 2018-09-19 2024-03-26 International Business Machines Corporation Distributed platform for computation and trusted validation
US11032063B2 (en) * 2018-09-19 2021-06-08 International Business Machines Corporation Distributed platform for computation and trusted validation
US11212076B2 (en) * 2018-09-19 2021-12-28 International Business Machines Corporation Distributed platform for computation and trusted validation
US20200142693A1 (en) * 2018-11-07 2020-05-07 International Business Machines Corporation Transparent code processing
CA3061594A1 (en) * 2018-11-14 2020-05-14 Royal Bank Of Canada System and method for cross-border blockchain platform
US20200184548A1 (en) * 2018-12-07 2020-06-11 Honeywell International Inc. Systems and methods for leasing equipment or facilities using blockchain technology
US11244313B2 (en) * 2019-01-31 2022-02-08 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing declarative smart actions for coins and assets transacted onto a blockchain using distributed ledger technology (DLT)
US10726002B1 (en) * 2019-08-19 2020-07-28 DLT Global Inc. Relational data management and organization using DLT
US10585882B1 (en) * 2019-09-23 2020-03-10 Trace, LLC Systems and methods for writing updates to and/or reading previously stored updates of assets implemented as smart contracts on a decentralized database

Also Published As

Publication number Publication date
CN115668856A (zh) 2023-01-31
US20210406876A1 (en) 2021-12-30
AU2021300620B2 (en) 2024-07-11
IL298416A (en) 2023-01-01
JP2023530594A (ja) 2023-07-19
CA3180249A1 (en) 2022-01-06
GB202300463D0 (en) 2023-03-01
WO2022003436A1 (en) 2022-01-06
AU2021300620A1 (en) 2022-11-17
GB2611687A (en) 2023-04-12

Similar Documents

Publication Publication Date Title
US11360963B2 (en) Tracking and verification of physical assets
US11277260B2 (en) Off-chain notification of updates from a private blockchain
US20210091960A1 (en) Tracking and verification of physical assets
US20210226800A1 (en) Preserving privacy of linked cross-network transactions
US20210303713A1 (en) Protecting sensitive data
US11362826B2 (en) Endorsement process for non-deterministic application
US11664973B2 (en) Trust-varied relationship between blockchain networks
WO2021197227A1 (en) Noisy transaction for protection of data
US20210256009A1 (en) Multi-client transaction validation
US11475365B2 (en) Verification of stochastic gradient descent
US20220329436A1 (en) Token-based identity validation via blockchain
US20220276996A1 (en) Assessment node and token assessment container
AU2021300620B2 (en) Permissioned eventing in a decentralized database
US11847234B2 (en) Verifiable training of model in untrusted environment
US20220278845A1 (en) Honest behavior enforcement via blockchain
US20230208638A1 (en) Future asset reclamation via blockchain
US11271742B2 (en) Decentralized secure data sharing
US11356260B2 (en) Decentralized secure data sharing
US20210314155A1 (en) Trusted ledger stamping
US20210150597A1 (en) Automated invoicing
WO2023046409A1 (en) Digital asset platform with hsm verification
US11088833B1 (en) Decentralized secure data sharing
US11314729B2 (en) Multi-candidate data structure for transaction validation
US11526467B2 (en) Document storage and verification
US12019585B2 (en) Document storage and verification

Legal Events

Date Code Title Description
A201 Request for examination