KR20210082194A - 프라이버시 보호 유효성 검사 및 커밋 아키텍처 - Google Patents

프라이버시 보호 유효성 검사 및 커밋 아키텍처 Download PDF

Info

Publication number
KR20210082194A
KR20210082194A KR1020217015034A KR20217015034A KR20210082194A KR 20210082194 A KR20210082194 A KR 20210082194A KR 1020217015034 A KR1020217015034 A KR 1020217015034A KR 20217015034 A KR20217015034 A KR 20217015034A KR 20210082194 A KR20210082194 A KR 20210082194A
Authority
KR
South Korea
Prior art keywords
node
transaction
receiving
domain
nodes
Prior art date
Application number
KR1020217015034A
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 KR20210082194A publication Critical patent/KR20210082194A/ko

Links

Images

Classifications

    • 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
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • 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/602—Providing cryptographic facilities or services
    • 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/606—Protecting data by securing the transmission between two devices or processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

다수 참가자 프로세스를 스케줄링하고 검증하는 방법(400)이 제공되며, 상기 방법은, 다수 참가자 프로세스의 참가자와 연관된 제출 노드(210)에 의해서, 암호로 보호된 메시지(140)를 하나 이상의 수신 노드들(120,122)로 전송함으로써 제안된 트랜잭션을 제출하는 단계(420), 상기 암호로 보호된 메시지(140)는 외부 노드(130)에 의해 판독가능한 비암호화된 서브메시지(142) 및 적어도 외부 노드로(130)부터 프라이버시를 보호하기 위한 암호로 보호된 서브메시지(144)를 적어도 포함하며; 상기 외부 노드에 의해서, 다른 트랜잭션들에 대한 제안된 트랜잭션의 순서를 결정하는 단계(410); 적어도 일부 수신 노드들을 통해, 암호로 보호된 메시지를 검증하는 단계; 적어도 일부 수신 노드들로부터, 암호로 보호된 메시지의 유효성에 대한 확인을 수신하는 단계(440); 확인 조건을 충족하는 하나 이상의 확인들을 적어도 일부 수신 노드들로부터 수신함에 기초하여, 상기 제안된 트랜잭션을 확인된 트랜잭션으로서 파이널라이징하는 단계(450); 및 상기 외부 노드에 의해 결정된 순서에 따라, 상기 확인된 트랜잭션을 분산 원장에 기록하는 단계(460)를 포함한다.

Description

프라이버시 보호 검증 및 커밋 아키텍처
본 개시는 프라이버시 보호 검증 및 커밋 아키텍처를 위한 복수의 노드들을 포함하는 컴퓨터 시스템에 관한 것이다. 본 개시는 또한 분산 원장에 트랜잭션을 커밋하기 위해 다수 참가자 프로세스를 검증하는 방법에 관한 것이다.
분산 컴퓨팅에서 일관성 보장 문제는 상태 머신 복제 문제(state-machine replication problem)로 알려져 있다. 비잔틴 장애 허용 솔루션(Byzantine fault tolerant solutions)은 상호 불신하는 당사자와도 상태(예컨대, 워크플로우) 진화의 유효성을 보장하면서 문제를 해결할 수 있다.
비트코인 및 이더리움과 같은 암호 화폐 시스템은 상태-머신 복제 문제에 대한 최소한 부분적인 해결책을 가질 수 있다(추가적인 "허가없는" 요구 사항 포함). 그러나 이러한 기존 해결책은 많은 어플리케이션에 적용할 수 없다. 이러한 어플리케이션 중 하나는, 통상적으로 영향을 받는 참가자에게만 워크플로우 진화(workflow evolution)가 표시되어야만 하는, 다수 참가자 프로세스에서 프라이버시를 제공하는 것이다. 이러한 문제에 대한 해결책은 분산 원장에 트랜잭션을 검증, 동기화 및 커밋하는 중앙집중식 노드를 활용하는 것이다. 하지만, 이러한 목적으로 중앙집중식 노드를 사용하는 것은 중앙집중식 노드를 신뢰할 수 있어야하고 서로 다른 각각의 노드가 워크플로 진화를 중앙집중식 노드에 공개해야하기 때문에, 일부 어플리케이션에는 적합하지 않을 수 있다. 따라서, 트랜잭션을 동기화 및 검증하기 위한 목적으로 중앙집중식 노드의 사용을 회피할 수 있는 프라이버시 보존 아키텍처에 대한 필요성이 존재한다.
본 명세서에 포함된 문서들, 행위들, 자료들, 디바이스들, 논문들 등에 대한 임의의 논의는, 이러한 사안들의 일부 또는 전부가 선행 기술의 일부를 형성한다던가 또는 첨부된 특허 청구 범위 각각의 우선일 이전에 존재하는 본 개시와 관련된 분야의 통상적인 일반 지식임을 인정하는 것으로 간주되지 않는다.
본 명세서 전반에 걸쳐서 "포함하다(comprise)"라는 단어 또는 "포함하다(comprises)" 또는 "포함하는(comprising)"과 같은 변형들은 언급된 요소, 정수 또는 단계, 또는 요소들의 그룹, 정수들 또는 단계들의 포함을 함축하는 것으로 이해되어야 하며, 다른 요소, 정수 또는 단계 또는 요소들의 그룹, 정수들 또는 단계들을 배제하는 것으로 이해되어서는 안된다.
다수 참가자 프로세스의 스케줄링 및 검증하는 방법이 제공되며, 상기 방법은 다수 참가자 프로세스의 참가자와 연관된 제출 노드에 의해서, 암호로 보호된(cryptographically-protected) 메시지를 하나 이상의 수신 노드들로 전송함으로써 제안된 트랜잭션을 제출하는 단계, 상기 암호로 보호된 메시지는 외부 노드에 의해 판독가능한 비암호화된(unencrypted) 서브메시지 및 적어도 외부 노드로부터 프라이버시를 보호하기 위한 암호로 보호된 서브메시지를 적어도 포함하며; 상기 외부 노드에 의해서, 다른 트랜잭션들에 대한 제안된 트랜잭션의 순서를 결정하는 단계; 적어도 일부 수신 노드들을 통해, 암호로 보호된 메시지를 검증하는 단계; 적어도 일부 수신 노드들로부터, 암호로 보호된 메시지의 유효성에 대한 확인을 수신하는 단계; 확인 조건을 충족하는 하나 이상의 확인들을 적어도 일부 수신 노드들로부터 수신함에 기초하여, 상기 제안된 트랜잭션을 확인된 트랜잭션으로서 파이널라이징하는 단계; 및 상기 외부 노드에 의해 결정된 순서에 따라, 상기 확인된 트랜잭션을 분산 원장에 기록하는 단계를 포함한다.
일부 실시예에서, 상기 하나 이상의 수신 노드들은 적어도 제 1 수신 노드 및 제 2 수신 노드를 포함할 수 있으며, 상기 암호로 보호된 서브메시지는 상기 제 1 수신 노드에 의해 판독가능하지만 상기 제 2 수신 노드에 의해 판독되지 않는다.
일부 실시예에서, 상기 제 1 수신 노드는 상기 암호로 보호된 서브메시지를 복호화하기 위한 복호화 키에 액세스할 수 있지만, 상기 제 2 수신 노드는 그렇지 않다.
일부 실시예에서, 상기 암호로 보호된 메시지는 상기 외부 노드로 전송될 수 있으며, 상기 외부 노드는 상기 암호로 보호된 메시지를 하나 이상의 수신 노드들로 전송한다.
일부 실시예에서, 상기 하나 이상의 수신 노드들은 자신의 신원을 다른 수신 노드들로부터 숨기기 위해 가명 주소를 사용할 수 있다.
일부 실시예에서, 상기 방법은 제출 노드와 가명 주소, 그리고 수신 노드와 가명 주소 사이의 연관성들을 유지하는 신원 관리자를 추가로 사용한다.
일부 실시예에서, 암호로 보호된 메시지의 유효성을 결정하는 단계는 비암호화된(unencrypted) 서브메시지에 기초할 수 있다.
일부 실시예에서, 비암호화된 서브메시지에 기초하여 상기 암호로 보호된 메시지의 유효성을 결정하는 단계는, 상기 제안된 트랜잭션의 트랜잭션 시간이 상기 외부 노드에 의해 제공된 타임스탬프의 윈도우 내에 있는지를 결정하는 단계를 포함할 수 있다.
일부 실시예에서, 상기 제안된 트랜잭션의 트랜잭션 시간은 타임스탬프들의 범위(range)일 수 있다.
일부 실시예에서, 상기 암호로 보호된 메시지의 유효성을 결정하는 단계는 암호로 보호된 서브메시지에 기초할 수 있다.
일부 실시예에서, 암호로 보호된 서브메시지에 기초하여 상기 암호로 보호된 메시지의 유효성을 결정하는 단계는, 제안된 트랜잭션이 이전 트랜잭션과 충돌하는지 여부를 식별하는 단계를 포함할 수 있다.
일부 실시예에서, 암호화된 서브메시지에 기초하여 상기 암호로 보호된 메시지의 유효성을 결정하는 단계는 제안된 트랜잭션이 양호하게 적격(well-formed)인지의 여부를 결정하는 단계를 포함할 수 있다.
일부 실시예에서, 암호로 보호된 서브메시지에 기초하여 상기 암호로 보호된 메시지의 유효성을 결정하는 단계는, 제안된 트랜잭션이 일련의 적합성 규칙들(conformance rules)을 따르는지를 결정하는 단계를 포함할 수 있다.
일부 실시예에서, 제안된 트랜잭션이 이전 트랜잭션과 충돌하는지 여부를 식별하는 단계는, 제안된 트랜잭션이 분산 원장에 과거에 기록되었는지를 체크하는 단계를 포함할 수 있다.
일부 실시예에서, 상기 암호로 보호된 메시지의 유효성을 결정하는 단계는 비암호화된 서브메시지 및 암호로 보호된 서브메시지에 기초할 수 있다.
일부 실시예에서, 상기 유효성을 결정하는 단계는, 상기 비암호된 서브메시지가 상기 암호로 보호된 서브메시지와 일치하는지를 결정하는 단계를 포함할 수 있다.
일부 실시예에서, 상기 확인 조건은, 다수 참가자 프로세스의 참가자에 대응하는 각각의 수신 노드로부터 확인을 수신하는 것; 할당된 기간 내에 특정 분량의 확인들을 수신하는 것; 수신 노드들의 특정된 서브세트로부터 확인들을 수신하는 것; 또는 암호화 증명자(cryptographic prover) 또는 신뢰할 수 있는 하드웨어와 같은 검증가능한 증명 메커니즘으로부터 확인을 수신하는 것 중 하나 이상일 수 있다.
일부 실시예에서, 상기 방법은 심판 노드(referee node)를 추가로 사용할 수 있으며, 심판 노드는 상기 하나 이상의 수신 노드들이 수신 노드에 대해 예상되는 액션에 따라 행동하지 않는지를 결정한다.
일부 실시예에서, 상기 심판 노드는, 제안된 트랜잭션의 형식이 적격인지의(well-formed) 여부; 하나 이상의 수신 노드들에 의해 제공된 확인이 하나 이상의 다른 확인들과 충돌하는지 여부; 및 제안된 트랜잭션이 용량 약속 소진(capacity promise exhaustion)을 잘못 표시하는지 여부 중 하나 이상을 결정할 수 있다.
일부 실시예에서, 상기 방법은 분쟁 해결 프로세스를 수행하기 위해 심판 노드를 추가로 사용할 수 있다.
일부 실시예에서, 상기 제안된 트랜잭션이 적격인지를 결정하는 단계는, 제안된 트랜잭션이 적합성 규칙들(conformance rules)을 준수하는지; 제안된 트랜잭션이 하나 이상의 수신 노드들의 필수 서브 세트에 의해 승인되는지; 및 제안된 트랜잭션이 리소스 요건들에 대한 올바른 선언을 갖고있는지 중 하나 이상을 체크하는 단계를 포함할 수 있다.
일부 실시예에서, 상기 하나 이상의 수신 노드들 중 제 1 노드는 제안된 트랜잭션을 심판 노드에 전달하여 분쟁 해결 프로세스를 개시할 수 있다.
일부 실시예에서, 상기 분쟁 해결 프로세스는 상기 제출 노드 또는 상기 하나 이상의 수신 노드들로부터 결정된 부정행위 노드(misbehaving node)에 처벌을 부과하는 심판 노드에 의해서 해결될 수 있다.
일부 실시예에서, 상기 처벌은, 부정행위 노드의 트랜잭션을 제출하는 기능을 제거하는 것; 부정행위 노드와 관련된 제안된 트랜잭션을 동결된 것으로 플래그하는 것; 심판 노드에 의해 결정된 부정행위 노드에 대한 맞춤 처벌; 도메인 규칙에 정의된 부정행위 노드에 대한 처벌 중 하나 이상이다.
일부 실시예에서, 심판 노드는 분쟁 해결 프로세스의 결과를 제출 노드 또는 하나 이상의 수신 노드들과 통신할 수 있다.
일부 실시예에서, 분쟁 해결 프로세스는 도메인 규칙들에 정의될 수 있다.
일부 실시예에서, 제 1 수신 노드 이외의 다른 수신 노드들이, 분쟁 해결 프로세스에 대한 증거로서 하나 이상의 메시지를 상기 심판 노드에 제공할 수 있다.
일부 실시예에서, 프로세스를 구성하는 다수의 트랜잭션들에 대응하는 복수의 메시지들의 순서를 결정하는 단계는 비암호된 서브메시지에 기초할 수 있다.
일부 실시예에서, 비암호화된 서브메시지는 상기 암호로 보호된 메시지가 상기 외부 노드에 의해 수신된 시간에 대응하는 물리적 타임스탬프를 포함할 수 있다.
일부 실시예에서, 다른 트랜잭션들에 대한 제안된 트랜잭션의 순서는 물리적 타임스탬프에 기초할 수 있다.
일부 실시예에서, 제안된 트랜잭션의 순서는, 상기 제안된 트랜잭션에 할당된 논리적 타임스탬프에 기초할 수 있다.
일부 실시예에서, 상기 논리적 타임스탬프는 상기 물리적 타임스탬프의 정의된 시간 윈도우 내의 시간에 대응할 수 있다.
일부 실시예에서, 상기 암호로 보호된 서브메시지는 암호화된 서브메시지일 수 있다.
일부 실시예에서, 다수 참가자 프로세스를 스케줄링하고 검증하는 방법이 제공되며, 상기 방법은 다수 참가자 프로세스에서 참가자와 연관된 제출 노드에 의해서, 암호로 보호된(cryptographically-protected) 메시지를 하나 이상의 수신 노드들로 전송함으로써 제안된 트랜잭션을 제출하는 단계, 상기 암호로 보호된 메시지는 외부 노드에 의해 판독가능한 비암호화된(unencrypted) 서브메시지 및 적어도 외부 노드로부터 프라이버시를 보호하기 위한 암호로 보호된 서브메시지를 적어도 포함하며; 상기 외부 노드에 의해, 다른 트랜잭션들에 대한 제안된 트랜잭션의 순서를 결정하는 단계; 상기 외부 노드에 의해, 비암호화된 서브메시지에 기초하여 다수 참가자 프로세스에서 참가자와 연관된 하나 이상의 수신 노드들을 결정하는 단계; 상기 외부 노드에 의해, 적어도 암호로 보호된 서브메시지를 상기 하나 이상의 수신 노드로 전송하는 단계; 상기 하나 이상의 수신 노드들에 의해, 암호로 보호된 서브메시지의 유효성을 결정하는 단계; 상기 외부 노드에 의해, 암호로 보호된 서브메시지의 유효성에 대한 확인을 상기 하나 이상의 수신 노드들로부터 수신하는 단계; 상기 외부 노드에 의해, 확인을 수신해야만 하는 하나 이상의 노드들을 결정하는 단계; 상기 외부 노드에 의해, 하나 이상의 노드에 확인을 전송하는 단계; 상기 제출 노드에 의해, 상기 하나 이상의 수신 노드들에 의해 제공된 확인들이 확인 조건을 충족하는지 여부에 기초하여 제안된 트랜잭션을 확인된 트랜잭션으로서 파이널라이징하는 단계; 및 상기 제출 노드에 의해, 상기 외부 노드에 의해 결정된 순서에 따라 상기 확인된 트랜잭션을 분산 원장에 기록하는 단계를 포함할 수 있다.
일부 실시예에서, 상기 방법은 중재자 노드에 의해, 상기 하나 이상의 수신 노드들에 의해 제공된 확인들을 수신하고 집계하는 단계를 더 포함할 수 있다.
일부 실시예에서, 상기 방법은 하나 이상의 확인들의 집계를 저장하는 단계; 하나 이상의 확인들의 집계를 다른 노드로 전송하는 단계; 및 확인들의 집계를 기반으로 제안된 트랜잭션을 확인하는 단계 중 하나 이상을 더 포함할 수 있다.
프로그램 명령들을 포함하는 비일시적, 유형의, 컴퓨터 판독가능 매체로서, 상기 프로그램 명령들은 실행될 때, 노드 또는 일련의 관련 노드들로 하여금 전술한 방법을 수행하게 한다.
다수 참가자 프로세스에서 트랜잭션 또는 일련의 트랜잭션들을 스케줄링하고 검증하는 방법이 제공되며, 상기 방법은, 부분적으로 암호화된 메시지를 다수 참가자 프로세스의 참가자와 관련된 하나 이상의 수신 노드들에게 적어도 전송함으로써 제안된 트랜잭션을 제출하는 단계, 상기 부분적으로 암호화된 메시지는 외부 노드에 의해 판독가능한 비암호화된(unencrypted) 서브메시지 및 적어도 외부 노드로부터 프라이버시를 보호하기 위한 암호화된 서브메시지를 적어도 포함하며; 부분적으로 암호화된 메시지의 유효성에 대한 확인을 수신 노드로부터 수신하는 단계; 확인 조건을 만족하는 하나 이상의 확인들을 적어도 일부 수신 노드들로부터 수신함에 기초하여, 제안된 트랜잭션을 확인된 트랜잭션으로서 파이널라이징하는 단계; 다른 트랜잭션들에 대한 확인된 트랜잭션의 순서를 외부 노드로부터 수신하는 단계; 및 외부 노드에 의해 결정된 순서에 따라 확인된 트랜잭션을 원장에 기록하는 단계를 포함한다.
일부 실시예에서, 상기 하나 이상의 수신 노드들은 제 1 수신 노드와 제 2 수신 노드를 적어도 포함하고, 상기 방법은 암호화된 서브메시지를 상기 제 1 수신 노드에 전송하는 단계를 더 포함하고, 상기 암호화된 서브메시지는 상기 제 1 수신 노드에 의해 제어되지만 상기 제 2 수신 노드에 의해 제어되지 않는 복호화 키에 의해서 복호화될 수 있다.
일부 실시예에서, 상기 암호화된 서브메시지는 상기 제 2 수신 노드로 전송되지 않을 수 있다.
일부 실시예에서, 상기 방법은 각각의 수신 노드의 가명 주소를 결정하는 단계를 더 포함할 수 있으며, 각각의 가명 주소는 다른 수신 노드들로부터 각각의 수신 노드의 신원을 숨기기 위해 사용된다.
프로그램 명령들을 포함하는 비일시적, 유형의, 컴퓨터 판독가능 매체로서, 상기 프로그램 명령들은 실행될 때, 제출 노드로 하여금 상기 방법을 수행하게 한다.
다수 참가자 프로세스에서 복수의 트랜잭션을 스케줄링하고 검증하는 방법이 제공되며, 상기 방법은,
노드 또는 일련의 관련 노드들을 통해:
A. 다수 참가자 프로세스를 구성하는 복수의 트랜잭션들에 대응하는 복수의 메시지들의 순서를 결정하는 단계;
B. 다수 참가자 프로세스의 참가자와 연관된 제출 노드로부터 부분적으로 암호화된 메시지를 포함하는 제안된 트랜잭션을 수신하는 단계, 상기 부분적으로 암호화된 메시지는 노드 또는 일련의 관련 노드들에 의해 판독가능한 적어도 하나의 비암호화된 서브메시지를 포함하고;
C. 상기 비암호화된 서브메시지에 기초하여 다수 참가자 프로세스의 참가자와 연관된 수신 노드를 결정하는 단계;
D. 상기 부분적으로 암호화된 메시지를 수신 노드로 전송하는 단계;
E. 상기 부분적으로 암호화된 메시지의 유효성에 대한 확인을 수신 노드로부터 수신하는 단계; 및
F. 제출 노드로 상기 확인을 전송하는 단계를 포함한다.
일부 실시예에서, 상기 방법은 상기 수신 노드의 가명 주소를 결정하는 단계를 더 포함하고, 상기 가명 주소는 다른 노드들로부터 상기 수신 노드의 신원을 숨기기 위해 사용된다.
일부 실시예에서, 분산 원장은 제출 노드, 외부 노드 및/또는 수신 노드들 사이의 메시지들을 기록하고, 분산 원장에 기록된 확인된 트랜잭션(들)은 기록된 메시지들을 포함하며, 이에 의해서 상기 외부 노드에 의해 결정된 순서가 상기 기록된 메시지들로부터 입증되거나 또는 도출될 수 있다.
일부 실시예에서, 분산 원장은 복수의 개별 원장들을 포함하고, 각각의 개별 원장은 원장의 각각의 부분 사본(partial copy)을 유지하고, 상기 분산 원장은 복수의 개별 원장들의 부분 기록들로부터 구성된다.
일부 실시예에서, 상기 방법은 외부 노드와 관련된 제 1 도메인으로부터 타겟 외부 노드와 관련된 타겟 도메인으로의 상기 다수 참가자 프로세스의 변경을 더 포함한다. 상기 방법은, 상기 제 1 도메인의 외부 노드에 의해서, 개시자 노드로부터 전송 요청을 수신하는 단계, 상기 전송 요청은 타겟 도메인 및 타겟 외부 노드를 지정하고; 상기 제 1 도메인의 외부 노드에 의해서, 제안된 트랜잭션을 호스팅할 타겟 도메인 및 타겟 외부 노드의 유효성을 결정하는 단계를 더 포함하고, 여기서, 타겟 도메인이 제안된 트랜잭션을 유효하게 호스팅할 수 있다고 결정함에 기초하여, 제안된 트랜잭션을 타겟 노드에서 스케줄링하고 검증하기 위한 승인을 개시자 노드에 전송하며, 제안된 트랜잭션의 순서를 결정하는 단계는 타겟 외부 노드에 의해 수행된다.
일부 실시예에서, 상기 방법은 제출 노드 및/또는 수신 노드에서 전송 요청을 수신하는 단계; 및 제출 노드 및/또는 수신 노드에서 제안된 트랜잭션을 호스팅할 타겟 도메인 및 타겟 외부 노드의 유효성을 결정하는 단계를 더 포함하고, 여기서, 타겟 도메인이 제안된 트랜잭션을 유효하게 호스팅할 수 있다고 결정함에 기초하여, 제안된 트랜잭션을 타겟 노드에서 스케줄링하고 검증하기 위한 승인을 개시자 노드에 전송한다.
일부 실시예에서, 개시자 노드에 대한 승인은 지정된 타임 아웃 조건과 연관되고, 상기 승인은 지정된 타임 아웃 조건에 기초하여 유효하거나 및/또는 독점적(exclusive)이다.
다수 참가자 프로세스를 스케줄링하고 검증하는 방법이 제공되며, 상기 방법은 제 1 외부 노드, 제 1 수신 노드, 및 다수 참가자 프로세스의 참가자와 연관된 제출 노드와 연관된 제 1 도메인; 제 2 외부 노드, 제 2 수신 노드, 및 제출 노드 또는 별도의 릴레이 노드와 연관된 제 2 도메인 -상기 제출 노드 또는 릴레이 노드는 제 1 외부 노드 및 제 2 노드 모두와 통신하며-; 와 관련되고, 상기 방법은, - 제출 노드에 의해, 제 1 도메인에 대한 제 1 제안된 트랜잭션 및 제 2 도메인에 대한 제 2 제안된 트랜잭션을 결정하는 단계, 상기 제 1 및 제 2 제안된 트랜잭션들은 조합되어, 상기 제 1 및 제 2 수신 노드와 관련된 제안된 다수 참가자 트랜잭션을 형성하고, 제 1 및 제 2 제안된 트랜잭션 각각은 각각의 수신 노드들에 대해 암호로 보호된 메시지를 포함하고, 상기 암호로 보호된 메시지는 적어도 각 도메인의 외부 노드에 의해 판독가능한 비암호화된 서브메시지 및 적어도 외부 노드로부터 프라이버시를 보호할 암호로 보호된 서브메시지를 포함하며; - 제출 노드 및/또는 릴레이 노드에 의해, 제 1 제안된 트랜잭션을 제 1 수신 노드에 제출하고 제 2 제안된 트랜잭션을 제 2 수신 노드에 제출하는 단계; - 제 1 외부 노드에 의해, 제 1 제안된 트랜잭션에 대한 제 1 순서를 결정하는 단계; -제 2 외부 노드에 의해, 제 2 제안된 트랜잭션에 대한 제 2 순서를 결정하는 단계; - 제 1 및 제 2 수신 노드들을 통해, 암호로 보호된 각각의 메시지를 검증하는 단계; - 제 1 및 제 2 수신 노드들로부터 암호로 보호된 메시지들의 유효성에 대한 확인을 수신하는 단계; - 확인 조건을 만족하는 확인들을 제 1 및 제 2 수신 노드들로부터 수신함에 기초하여, 확인된 제 1 트랜잭션와 확인된 제 2 트랜잭션의 조합으로서 상기 제안된 다수 참가자 트랜잭션을 파이널라이징하는 단계; 및 - 제 1 순서에 따라 제 1 확인된 트랜잭션을 제 1 도메인과 관련된 분산 원장에 기록하고, 제 2 순서에 따라 제 2 확인된 트랜잭션을 제 2 도메인과 관련된 분산 원장에 기록하는 단계를 포함한다.
일부 실시예에서, 상기 제출 노드는 상기 제 1 도메인과 상기 제 2 도메인 사이에서 메시지를 수신 및 송신하기 위한 중계자이고, 상기 방법은 또한, 제출 노드 및/또는 릴레이 노드에 의해, 암호로 보호된 메시지의 유효성에 대한 확인을 제 1 수신 노드로부터 제 2 도메인의 제 2 외부 노드 및/또는 제 2 수신 노드로 전송하는 단계; 및 제출 노드 및/또는 릴레이 노드에 의해, 암호로 보호된 메시지의 유효성에 대한 확인을 제 2 수신 노드로부터 제 1 도메인의 제 1 외부 노드 및/또는 제 1 수신 노드로 전송하는 단계를 더 포함한다.
일부 실시예에서, 제안된 다수 참가자 트랜잭션을 파이널라이징하기 위한 승인은, 지정된 타이밍 조건과 관련되고, 상기 승인은 지정된 타이밍 조건에 기초하여 유효하거나 및/또는 독점적이다.
일부 실시예에서, 제안된 트랜잭션은 다수의 도메인들에 걸쳐 제안된 다수 참가자 트랜잭션의 일부이고, 상기 방법은, 제안된 다수 참가자 트랜잭션으로부터, 하나 이상의 수신 노드들 및 외부 노드를 포함하는 제 1 도메인에 대한 제 1 제안된 트랜잭션 및 하나 이상의 다른 수신 노드들 및 다른 외부 노드를 포함하는 다른 도메인에 대한 적어도 하나의 다른 제안된 트랜잭션을 결정하는 단계; 상기 다른 도메인의 다수 참가자 프로세스의 참가자와 연관된 하나 이상의 다른 수신 노드들로 부분적으로 암호화된 다른 메시지를 적어도 전송함으로써 상기 다른 제안된 트랜잭션을 제출하는 단계, 상기 부분적으로 암호화된 다른 메시지는 상기 다른 외부 노드에 의해 판독가능한 비암호화된 서브메시지 및 적어도 상기 다른 외부 노드로부터 프라이버시를 보호하기 위한 암호화된 서브메시지를 적어도 포함하며; 상기 하나 이상의 다른 수신 노드들로부터 상기 부분적으로 암호화된 다른 서브메시지의 유효성에 대한 다른 확인을 수신하는 단계; 상기 제안된 트랜잭션을 파이널라이징하는 단계는, 확인 조건을 만족하는 다른 수신 노드들 중 적어도 일부로부터 하나 이상의 확인들을 수신하는 것에 기초하여, 다른 확인된 트랜잭션으로서, 상기 다른 제안된 트랜잭션을 파이널라이징하는 단계를 더 포함하고; 다른 외부 노드로부터, 다른 도메인의 다른 트랜잭션들에 대한 상기 다른 확인된 트랜잭션의 순서를 수신하는 단계; 및 상기 다른 외부 노드에 의해 결정된 순서에 따라, 상기 다른 확인된 트랜잭션을 원장 또는 다른 원장에 기록하는 단계를 더 포함한다.
일부 실시예에서, 상기 방법은, 암호로 보호된 메시지의 유효성에 대한 확인을 제 1 도메인의 수신 노드로부터 다른 도메인의 다른 수신 노드로 전송하는 단계; 및 암호화로 보호된 메시지의 유효성에 대한 다른 확인을 상기 다른 도메인의 다른 수신 노드로부터 제 1 도메인의 수신 노드로 전송하는 단계를 더 포함한다.
일부 실시예에서, 제안된 트랜잭션 및 다른 제안된 트랜잭션을 파이널라이징하기 위한 승인은 지정된 타이밍 조건과 관련되고, 상기 승인은 지정된 타이밍 조건에 기초하여 유효하거나 및/또는 독점적이다.
일부 실시예에서, 상기 암호화된 서브메시지는 제안된 트랜잭션에서 모든 예상된 확인들을 암호화적으로 검증하기 위한 예상 확인 데이터를 포함하고, 상기 방법은, 수신된 하나 이상의 확인들 각각을 예상 확인 데이터로 암호화적으로 검증하기 위해 암호화 기능을 실행하는 단계를 더 포함한다.
일부 실시예에서, 상기 예상 확인 데이터는 공개 키(들)의 형태이고, 상기 예상 확인 데이터는은 공개 키(들)에 대응하는 개인 키를 갖는 전자 서명을 포함한다.
일부 실시예에서, 제안된 트랜잭션은 복수의 서브 트랜잭션들을 포함하고, 복수의 서브 트랜잭션들 각각은 적어도 하나의 수신 노드와 관련되며, 각각의 서브 트랜잭션은 관련된 수신 노드에 의해 서브 트랜잭션에 대해 판독될 수 있지만 서브 트랜잭션에 관련되지 않는 수신 노드(들)에 의해서는 판독될 수 없는 개인 정보를 구비한 대응하는 암호로 보호되는 서브메시지와 연관되며, 그리고 상기 암호로 보호된 서브메시지는 제안된 트랜잭션 내의 적어도 하나의 다른 서브 트랜잭션의 개인 정보를 적어도 부분적으로 나타내는 확인들을 검증하기 위한 개인 정보 검증 데이터를 포함하고, 상기 방법은, 적어도 하나의 다른 서브 트랜잭션의 확인이 상기 개인 정보 검증 데이터와 대응하는지를 검증하는 단계를 더 포함한다.
일부 실시예에서, 상기 서브 트랜잭션의 확인은 상기 서브 트랜잭션의 개인 정보의 암호화 해시를 적어도 부분적으로 포함한다.
일부 실시예에서, 상기 제안된 트랜잭션은 복수의 서브트리를 갖는 트리 구조를 가지며, 서브트리는 상기 복수의 서브 트랜잭션들 중 하나 이상을 포함한다.
일부 실시예에서, 상기 암호화로 보호된 서브메시지는 제안된 트랜잭션의 복수의 서브트랜잭션들의 확인들 중 어느 하나를 암호화적으로 검증하기 위한 개인 정보 검증 데이터를 포함한다.
프로그램 명령들을 포함하는 비일시적, 유형의, 컴퓨터 판독가능 매체가 제공되며, 상기 프로그램 명령들은 실행될 때, 노드 또는 일련의 관련 노드들로 하여금 전술한 방법을 수행하게 한다.
일부 실시예에서, 원장은 공유 원장일 수 있다.
이하의 도면을 참조하여 본 발명의 실시예를 설명한다.
도 1은 다수 트랜잭션들을 포함하는 다수 참가자 프로세스를 스케줄링하고 검증하기 위한 예시적인 시스템이다.
도 2a는 다수 트랜잭션들을 포함하는 다수 참가자 프로세스를 스케줄링하고 검증하기 위한 보다 복잡한 예시적인 시스템이다.
도 2b는 중재자 노드가 있는 도 2a의 일례이다.
도 2c는 모든 노드들에 서브메시지를 배포하는 일례이다.
도 2d는 일부 노드에 서브메시지를 배포하는 일례이다.
도 3은 제안된 트랜잭션의 일례를 도시한다.
도 4는 다수 참가자 프로세스를 스케줄링하고 검증하는 예시적인 방법이다.
도 5는 예시적인 노드이다.
도 6은 원본(origin) 도메인에서 타겟 도메인으로의 도메인 변경의 예를 나타내는 개략도이다.
도 7은 원본 도메인에서 타겟 도메인으로 도메인 변경의 또 다른 예이다.
도 8은 2 개의 도메인에 걸친 다중 도메인 트랜잭션의 일례의 개략도이다.
도 9는 도 8의 다중 도메인 트랜잭션에서 다양한 데드 라인을 나타낸 도면이다.
도 10은 단일 도메인에서 구현될 수 있는 다수 참가자들을 포함하는 트랜잭션의 또 다른 일례를 예시한다.
도 11a은 도 10의 예시적인 트랜잭션에서 다양한 엔티티들의 뷰를 보여준다.
도 1lb는 도 11a의 뷰의 블라인드 뷰를 개념적으로 예시한다.
도 12는 도 10 내지 도 11b의 트랜잭션 및 방법의 개략도이다.
도 13은 도 10 내지 도 12의 트랜잭션 및 방법의 상태 천이도이다.
도 14a는 참가자 A, 참가자 B 및 은행을 포함하는 트랜잭션의 뷰들을 예시한다.
도 14b는 도 14a의 트랜잭션에서 은행이 볼 수 있는 뷰를 예시한다.
도 15a는 가상 원장에 기록될 트랜잭션에 대한 메시지의 표현으로, 하나의 참가자 P의 세부 사항이 누락되었다.
도 15b는 참가자 A의 세부 사항이 누락된 가상 원장에 기록될 트랜잭션에 대한 메시지의 표현이다.
도 16a는 다수 참가자 프로세스의 완전한 트랜잭션 뷰를 예시한다.
도 16b는 도 16b의 제 1 뷰의 코어를 예시한다.
도 17은 다수 참가자 프로세스 및 트랜잭션을 나타내는 완전한 데이터 구조를 예시한다.
도 18은 서브-트랜잭션 프라이버시를 예시하는 도 17의 트랜잭션의 서브 뷰의 표현을 예시한다.
도 19는 도 17의 트랜잭션에 대한 전체 이해관계자(stakeholder) 트리의 표현을 예시한다.
도 20은 이해관계자 은행에 대해 블라인드되지 않은 이해관계자 트리의 표현을 예시한다.
본 개시는 분산 시스템에서 동기화와 유효성을 분리할 수 있는 시스템에 관한 것이다. 동기화는 분산 시스템의 표준 문제이며, 일반적으로 전체-주문(total-order) 브로드캐스트 또는 멀티캐스트와 같은 합의 프리미티브를 주문하는 일부 형태를 통해 해결된다. 예시적인 시스템이 개시되는바, 이는 유효성 검사가 수신자 자신에게 이동될 수 있는 수신 노드의 개념에 기초하여 유효성을 보장한다. 무수히 많은 다른 이점 중에서, 이는 모든 데이터를 보고 처리할 수 있는 중앙집중식 커미터 노드의 필요성을 제거하거나, 또는 모든 데이터를 보고 처리할 수 있는 능력을 공동으로 갖는 다수-당사자 커미터 노드의 필요성을 제거할 수 있으므로, 시스템의 수신 노드들에 대한 프라이버시를 강화할 수 있다.
시스템에서, 참가자들은 트랜잭션에 대한 그들의 부분적인 관점(view: 이하, "관점" 또는 "뷰"라 함)에 기초하여 로컬 유효성 검사를 수행할 수 있으며, 그리고 확인들(confirmations)(예컨대, 피어 투 피어 확인들 또는 시스템의 컴포넌트(들) 또는 노드(들)을 통해 라우팅된 확인들)을 통해 로컬 검사들의 결과들을 교환할 수 있다. 일례에서, 당사자들은 그들의 부분적인 관점에 기초하여 로컬 유효성 검사를 수행하는 작업을 참가자 사용자들(participant users) 또는 다른 행위자들에게 위임할 수 있다. 일례에서, 참가자들은 분산 원장의 워크플로 규칙들에 대한 그들의 제한된 관점에 기초하여 트랜잭션 레벨 유효성 검사를 수행하는 작업을 당사자 사용자들(party users) 또는 다른 행위자들에게 위임할 수 있다.
도 1은 다수 트랜잭션들을 포함하는 다수 참가자 프로세스를 스케줄링하고 검증하기 위한 예시적인 시스템(100)을 도시한다. 본 일례에서, 프로세스(102), 노드들 사이에서 통신하기 위한 네트워크(104), 제출 노드(110), 수신 노드(120), 외부 노드(130) 및 원장(160)이 있다. 선택적으로, 제 2 수신 노드(122)(도 1의 파선으로 표시됨) 및 신원 관리자(170)가 있을 수 있다.
본 일례에서, 프로세스(102)는 모든 노드들에 걸쳐 공유될 수 있다. 프로세스에는 다수의 참가자들이 있을 수 있으며, 이들 참가자들 각각은 네트워크의 하나 이상의 노드와 관련될 수 있다. 가장 간단한 일례에서, 제출 노드(110), 수신 노드(120) 및 외부 노드(130)가 있을 수 있다. 외부 노드(130)는, 다수의 참가자들을 포함하는 프로세스(102)를 구성하는 하나 이상의 트랜잭션들에 대응하는 복수의 메시지들의 순서를 결정할 수 있다. 외부 노드(130)는 외부 노드의 논리적 순서 기능을 구현하는 복수의 물리적 시스템들을 포함할 수 있다.
제출 노드(110)는 제안된 트랜잭션(140)을 제출할 수 있다. 제안된 트랜잭션(140)을 제출하는 것은 네트워크(104)를 통해 프로세스의 참가자와 연관된 하나 이상의 수신 노드(120, 122)에 암호로 보호된 메시지를 전송하는 것을 포함할 수 있으며, 여기서 암호로 보호된 메시지는 외부 노드(130)에 의해 판독가능한 비암호화된 서브메시지(142) 및 적어도 외부 노드(130)로부터의 프라이버시를 보호하기 위한 암호로 보호된 서브메시지(144)를 포함할 수 있다. 본 일례에서, 암호로 보호된(cryptographically-protected) 메시지는, 비암호화된(unencrypted) 서브메시지(142) 및 암호화된(encrypted) 서브메시지(144)를 포함할 수 있는 부분적으로 암호화된 메시지일 수 있다. 본 명세서의 나머지 부분에서, 단지 편의를 위해, 암호로 보호된 메시지와 서브메시지를 각각 부분적으로 암호화된 메시지 및 암호화된 서브메시지로 참조하며, 다음이 이해되야하는바, 인가되지 않은 노드로부터 암호로 보호된 메시지 또는 서브메시지를 인코딩하거나 난독화(obfuscation)하기 위해 암호화 이외의 다른 암호화 보호 메커니즘이 활용될 수 있다(예컨대, 데이터 마스킹,의미론적 난독화, 기타 등등). 본 일례에서, 암호화된 서브메시지(144)는 부분적으로 암호화된 메시지의 제출된 페이로드로 간주될 수 있다. 일례에서, 대칭 암호화(예컨대, 고급 암호화 표준(AES: Advanced Encryption Standard)), 비대칭 암호화(예컨대, RSA, 타원 곡선(elliptic curve) 등) 또는 통합 암호화(예컨대, ECIES)는 부분적으로 암호화된 메시지를 암호화하고 그리고 제안된 트랜잭션(140)을 제출하는데 이용될 수 있으며, 이해되는 바와 같이, 본 명세서에 개시된 모든 트랜잭션에서 사용될 수 있다.
제출 노드(110)가 제안된 트랜잭션(140)을 제출하면, 수신 노드(120)는 제안된 트랜잭션(140)을 수신하고 부분적으로 암호화된 메시지의 유효성을 결정할 수 있으며, 확장에 의해 제안된 트랜잭션(140)을 결정할 수 있다. 일례에서 이러한 검증은, 수신 노드(120)가 부분적으로 암호화된 메시지의 암호화된 서브메시지(144)를 검증하는 것을 포괄할 수 있다. 예를 들어, 소정 실시예에서, 암호화된 서브메시지(144)는 데이터(예를 들어, 프로그램 명령, 정보 등)를 포함할 수 있는데, 이러한 데이터는 수신 노드(120) 및 제출 노드(110)에 대해 비공개이고(private), 그리고 외부 노드(130)에 의해 판독되지 않는다(예컨대, 수신 및 제출 노드들(110, 120)은 복호화(또는 '해독" 이라함) 키를 갖지만 외부 노드(130)는 복호화 키를 갖지 않기 때문에).
제안된 트랜잭션(140)의 유효성이 결정되면, 수신 노드(120)는 확인(confirmation)(150)이라 지칭되는 메시지를 전송할 수 있으며, 이는 수신 노드(120)로부터의 부분적으로 암호화된 메시지의 유효성에 대한 확인일 수 있다. 일례에서, 이러한 확인은, 수신 노드(120)가 제안된 트랜잭션(140)의 맥락에서 암호화된 서브메시지(144)를 검증했고 그리고 제안된 트랜잭션(140)이 정확하고 유효한 것으로 간주하는지를 확인할 수 있다. 일부 예들에서, 제안된 트랜잭션(140)이 검증되기 전에 시퀀싱하는 단계(즉, 제안된 트랜잭션(140)을 다른 제안된 트랜잭션에 대해 순서화하는 단계)가 유리할 수 있다. 모든 참가자가 트랜잭션들의 동일한 시퀀스(또는 해당 시퀀스의 스니펫)를 수신 및 검증할 수 있으므로, 이러한 참가자들은 제안된 트랜잭션들의 동일한 순서 또는 시퀀스를 암시적으로 검증할 수 있으며, 이는 부정행위 노드(misbehaving node)를 쉽게 식별할 수 있게 한다.
본 일례에서, 제출 노드(110)는 수신 노드(120)로부터 확인을 수신함에 기초하여, 제안된 트랜잭션(140)을 확인된 트랜잭션으로 수락할 수 있고, 제안된 트랜잭션(140)이 확인 조건을 만족하는 것으로 결정할 수 있다. 본 일례에서 확인 조건은 프로세스(102)의 참가자들에 대응하는 모든 노드들에 의해서 확인(150)이 수신되는 것일 수 있다. 본 일례에서 수신자(120)가 오직 한 명인 경우, 제안된 트랜잭션(140)을 확인하기 위해 하나(1)의 확인만이 제출 노드(110)에 의해 수신될 필요가 있을 것이다. 더 복잡한 사례들은 아래에서 논의된다.
본 일례에서, 제출 노드(110) 및/또는 수신 노드(120)는 외부 노드(130)에 의해 결정된 순서에 따라, 확인된 트랜잭션을 원장(160)에 기록할 수 있다. 일 예에서 원장은 모든 노드들 사이에서 공유될 수 있는 데이터 저장소일 수 있다. 다른 예에서, 원장(160)은 각 노드가 원장의 부분적 사본 또는 전체 사본을 유지하는 분산 원장일 수 있으며, 제출 노드(110) 및/또는 수신 노드(120)는 그에 따라 원장의 사본을 업데이트할 수 있다. 다른 일례에서도, 원장(160)은 개념적으로만 존재하고 현실적으로는 존재하지 않는 분산 원장일 수 있다. 구체적으로, 원장(160)은 네트워크를 통해 제출되고 "가상" 원장에 입력된 트랜잭션들에 관한 네트워크의 노드들 사이에서 교환되는 복수의 메시지들로 구성된 분산된 "가상" 원장일 수 있다. 복수의 메시지들에 포함된 데이터로부터, 네트워크의 노드들과 관련된 참가자들은 언제든지 "가상" 원장의 상태를 계산할 수 있으므로 해당 시점에 네트워크의 다른 참가자들에 대한 의무와 책임을 계산할 수 있지만, 스테이트풀(stateful) 분산 원장(예컨대, 비트 코인 또는 이더리움과 유사함)은 실제로 존재하지 않을 수 있다. 다르게 말하면, 복수의 메시지들만이 네트워크의 다양한 노드들에 의해 저장될 수 있으며 그리고 이들 메시지들의 내용을 기반으로 계산된 "가상" 원장의 상태.
도 2a 및 도 2b는 보다 복잡한 예시적인 시스템(200)을 도시한다. 도 1의 일례에서와 매우 유사하게, 프로세스(102)는 모든 노드에 걸쳐 공유될 수 있다. 프로세스에는 여러 참가자들이 있을 수 있으며 각 참가자는 네트워크의 하나 이상의 노드와 관련될 수 있다. 그러나, 도 1의 일례와 달리, 본 일례에서는 시스템의 참가자와 관련된 3 개의 노드들이 존재한다(제출 노드(210) 및 2 개의 수신 노드들(262, 264)). 도 1의 일례에서와 같이, 외부 노드(230)는 다수의 참가자들을 포함하는 프로세스(102)를 구성하는 다수의 트랜잭션들에 대응하는 다수의 메시지들의 순서를 결정할 수 있다. 일반적으로, 프로세스(102)는 본 개시의 다른 예에서 설명된 바와 같이 다수의 트랜잭션들로 구성된다. 하지만, 프로세스는 단일 트랜잭션을 포함할 수 있음을 이해해야한다. 명확성을 위해 네트워크가 예시로부터 제거되었지만, 도 1에서와 같이 네트워크가 존재할 수도 있다.
도 1과 유사하게, 제출 노드(210)는 제안된 트랜잭션(240)을 제출할 수 있다. 제안된 트랜잭션(240)을 제출하는 것은 부분적으로 암호화된 메시지를 네트워크(도시되지 않음)를 통해 프로세스(202)의 참가자와 관련된 2 개의 수신 노드들(220, 222)로 전송하는 것을 포함할 수 있으며, 여기서 부분적으로 암호화된 메시지는 외부 노드(230)에 의해 판독가능한 비암호화된 서브메시지(242) 및 적어도 외부 노드(230)로부터 프라이버시를 보호하기 위해 암호화된 서브메시지(244)를 적어도 포함할 수 있다. 도 2a의 예에서, 부분적으로 암호화된 메시지는 외부 노드(230)로 전송될 수 있고, 외부 노드는 확인을 위해 제안된 트랜잭션(240)을 수신할 하나 이상의 수신 노드를 결정할 수 있다. 그 후 외부 노드(230)는 부분적으로 암호화된 메시지를 적절한 수신 노드(들)(220, 222)로 전송할 수 있다. 일부 경우에서, 암호화된 서브메시지(244)가 각각의 수신 노드(220, 222)와 관련되어 있다면, 외부 노드(230)는 제안된 트랜잭션(240) 전체 대신에 암호화된 서브메시지(244)를 수신 노드에 전송할 수 있다. 다른 일례에서, 제안된 트랜잭션(240)은 다수의 부분적으로 암호화된 메시지들(각 수신자에 대해 대응하는 비암호화된 서브메시지 242 및 암호화된 서브메시지 244와 함께)의 세트를 포함할 수 있으며, 이에 의해 서브메시지들(예를 들어, 암호화된 서브메시지 244)은 각각의 수신 노드들(220, 222)로 분할되고 분배될 수 있다. 이것은 다음을 의미하는바, 제안된 트랜잭션(240)의 일부는 승인된 수신 노드에게는 보일 수 있지만, 승인되지 않은 다른 수신 노드에게는 보이지 않을 수 있음을 의미하며, 이에 따라 이들 각각의 부분들에 대해, 승인되지 않은 수신 노드들에게는 보여져서는 안되는 트랜잭션의 부분들의 프라이버시를 보호할 수 있다.
위의 일례가 도 2c에 도시되어 있으며, 도 2c는 추가 수신 노드(224)가 존재하며, 부분적으로 암호화된 메시지들이 서브메시지들(242 내지 248)로 분할되고 그리고 암호화된 각각의 서브메시지들(244, 246, 248)이 각각의 수신 노드들(220, 222, 224)로 분배되는 시나리오를 도시한다. 도 2c의 일례에서, 암호화된 서브 메시지(244)는 제 1 수신 노드(220)에 의해 판독될 수 있지만, 제 2 수신 노드(222) 또는 제 3 수신 노드(224)에 의해서는 판독될 수 없다. 즉, 각 수신 노드(220, 222, 224)가 각각의 암호화된 서브메시지(244, 246, 248)를 수신한하더라도, 암호화된 서브메시지(244)의 내용은 제 1 수신 노드(220)에 의해 판독되고 그리고 잠재적으로 검증될 수 있지만, 제 2 수신 노드(222) 또는 제 3 수신 노드(224)에 의해서는 그렇지 않다. 이는 일부 메시지들의 내용이 하나의 수신 노드에 대해 프라이빗하며, 따라서 다른 수신 노드와는 공유되어서는 안되는 많은 일례들에서 발생할 수 있다. 제 1, 제 2 및 제 3 수신 노드(220, 222, 224)보다 더 많은 노드들이 네트워크의 일부를 형성할 수 있으며, 특정 암호화된 서브메시지(244)는 암호화된 서브메시지(244)를 볼 자격이 있는 수신 노드들의 임의의 서브세트에 전송되고 판독될 수 있지만, 암호화된 서브메시지(244)를 볼 자격이 없는 수신 노드들의 서브세트에는 전송되지 않으며 판독될 수 없다.
도 2c에 예시된 것과 유사한 일례가 도 2d의 예시에 묘사된다. 도 2d의 일례에서, 암호화된 서브메시지(244)는 제 1 수신 노드(220)에 의해서만 수신될 수 있지만, 제 2 수신 노드(222) 또는 제 3 수신 노드(224)에 의해서는 수신되지 않는다. 즉, 본 일례에서, 암호화된 서브메시지(244)가 제 2 수신 노드(222) 또는 제 3 수신 노드(224)와 관련이 없다고 결정하면, 외부 노드(230)는 암호화된 서브메시지(244)를 제 2 수신 노드(222) 또는 제 3 수신 노드(224)로 포워딩하지 않을 수 있다. 이것은 다음을 의미하는바, 제 2 수신 노드(222)가 복호화 키에 대한 비인가 액세스를 획득한 경우에도, 제 2 수신 노드(222)는 외부 노드(230)로부터 암호화된 서브메시지(244)를 전혀 수신하지 않았을 것이기에, 제 2 수신 노드(222)가 암호화된 서브메시지(244)를 복호화(또는 해독이라 함)할 수 없음을 의미한다. 이와 유사하게, 제 3 수신 노드(224)가 외부 노드(230)로부터 암호화된 서브메시지(244)를 전혀 수신하지 않았을 것이기에, 제 3 수신 노드(224)도 암호화된 서브메시지(244)를 복호화할 수 없다. 마찬가지로, 외부 노드(230)가 암호화된 서브메시지(244)를 제 2 수신 노드(222) 또는 제 3 수신 노드(224)로 실수로 전송한 경우에도, 상기 제 2 수신 노드(222) 또는 제 3 수신 노드(224)는 사악한 행동(nefarious behaviour)이 없으면, 암호화된 서브메시지(244)를 복호화하기 위한 복호화 키를 통상적으로 갖지 않을 것이다. 따라서, 본 발명의 시스템은 노드들 간의 프라이버시를 보존할 수 있어, 키 또는 암호화 알고리즘(cryptographic algorithm)이 손상(compromise)된 경우에도, 제안된 트랜잭션의 일부를 볼 자격이 있는 노드들만이 그렇게 행동하는 것을 보장할 수 있다.
일 예에서, 제 1 수신 노드(220)는 암호화된 서브메시지를 판독하기 위해 제 1 수신 노드(220)에 제공된 암호화된 서브메시지(244)를 복호화하기 위한 복호화 키에 액세스할 수 있다. 본 일례에서, 제 2 수신 노드(222)는 도 2c에 도시된 바와 같이 암호화된 서브메시지(244)를 수신할 수 있지만, 제 1 수신 노드(220)로 어드레싱된 암호화된 서브메시지(244)를 복호화하기 위한 복호화 키에 대한 액세스 권한은 없으며, 이는 그 특정 암호화된 서브메시지(244)의 프라이버시를 보호하기 위한 것이다. 물론, 암호화된 서브메시지(244)를 복호화하기 위한 복호화 키에 대한 액세스는, 특정 암호화된 서브메시지(244)를 읽을 자격이 있는 네트워크 내의 임의의 개수 또는 임의의 서브세트의 수신 노드들로 확장될 수 있다.
완전성을 위해 도 2d의 예에서 암호화된 서브메시지(246)는 제 1 및 제 2 수신 노드(220, 222)에 분배되고, 암호화된 서브메시지(248)는 제 1 및 제 3 수신 노드(220, 224)에 분배된다는 점에 주목할 필요가 있다. 마찬가지로, 제 1 수신 노드(220) 및 제 2 수신 노드(222)는 암호화된 서브메시지(246)를 복호화하기 위한 복호화 키에 대한 액세스 권한을 가질 필요가 있을 것이며 그리고 제 1 수신 노드(220), 제 2 수신 노드(224) 및 제 3 수신 노드(226)는 암호화된 서브메시지(246)를 복호화하기 위한 복호화 키에 대한 액세스 권한을 가질 필요가 있을 것이다.
제안된 트랜잭션(240)의 유효성이 각 수신 노드(220, 222)에 의해 결정되면, 각 수신 노드(220, 222)는 확인(confirmation)(250, 252)이라 지칭되는 메시지를 보낼 수 있으며, 이는 수신 노드(220, 222)로부터의 부분적으로 암호화된 메시지의 유효성에 대한 확인일 수 있다. 본 일례에서, 도 1의 일례와 달리, 각 수신 노드(220, 222)로부터의 확인은 외부 노드(230)로 전송될 수 있다. 외부 노드(230)는 복수의 노드들 중 하나 일 수 있는 제출 노드(210)를 결정할 수 있고, 그리고 적절한 제출 노드(210)로 확인들을 전송할 수 있다. 예시되지 않은 일부 변형예에서, 하나의 수신 노드로부터 다른 노드로 확인들이 직접 전송될 수 있다. 즉, 확인들은 외부 노드 또는 중재자를 통하지 않고 피어-투-피어로 전송될 수 있다. 피어-투-피어 확인은 거래를 검증하기 위한 적절한 규칙들과 함께 외부 노드 또는 중재자와 조합되어 사용될 수 있다.
일 예에서, 제출 노드(210)는 복수의 확인들(수신 노드 220으로부터의 제 1 확인 및 수신 노드 222로부터의 제 2 확인)을 수신함에 기초하여, 제안된 트랜잭션(240)를 확인된 트랜잭션으로서 수락할 수 있다. 본 일례에서의 확인 조건은 도 1의 일례에서와 같이 전체 확인(full confirmation)이므로 트랜잭션이 확인될 수 있다. 전체 확인 외에 다른 대안적인 확인 조건들은 본 명세서의 다른 영역에서 논의된다.
특히, 본 일례에서, 시스템의 참가자와 연관된 각각의 노드는 원장(260, 262, 264)을 가질 수 있고, 그에 따라 원장의 부분 또는 전체 사본을 업데이트할 수 있다. 예를 들어, 제출 노드(210)는 원장(260)을 가질 수 있고, 제 1 수신 노드(220)는 원장(262)을 가질 수 있고, 제 2 수신 노드(222)는 원장(264)을 가질 수 있다. 각각의 노드는 외부 노드(230)에 의해 결정된 순서에 따라 각각의 원장(260, 262, 264)에 확인된 트랜잭션을 기록할 수 있다. 일부 예들에서, 원장은 모든 노드들 간에 공유될 수 있는 데이터 저장소이며, 이 경우, 예를 들어, 분리된 데이터에 기반하는 프라이버시 모델은 각 참가자 노드에 대한 각각의 트랜잭션들의 프라이버시를 유지해야할 필요가 있을 수도 있다. 다른 일례들에서, 각 원장은 위에서 설명한 것처럼 "가상" 원장이다.
선택적으로, 도 2a에 예시된 시스템의 변형예는 도 2b에 도시된 바와 같이 중재자(280)를 사용하는 것일 수 있다. 이 시나리오에서, 수신 노드(220, 222)는 확인(250, 252)을 중재자 노드(280)로 전송할 수 있으며, 중재자 노드(280)는 확인을 수신하고 집계 결과를 결정할 수 있다. 제출 노드(210)는 또한 제안된 트랜잭션(240)을 중재자(280)에 제출할 수 있다. 3 개 이상의 수신 노드가있는 경우, 얼마나 많은 수신 노드가 중재자 노드(280)를 사용하여 제안된 트랜잭션(240)를 확인하는지 카운트하는 것이 더 간단할 수 있다. 또한, 중재자 노드(280)는 특정 수신 노드(220, 222)에 의해 확인이 전송되었는지 여부에 대한 권위있는 기록으로서 역할을 할 수 있다. 즉, 확인들이 중재자 노드(280)를 통해 라우팅될 수 있기 때문에, 중재자 노드(280)는 시스템을 사용하여 전송된 모든 확인들의 기록을 가질 수 있으며, 수신 노드(220, 222)는 확인을 전송했거나 전송하지 않았음을 거부할 수 없다. 일부 예들에서, 중재자 노드(280)는 모든 확인을 수신하고, 이들을 집계하고, 그리고 이들을 대응 참가자 노드들로 전송하는바, 따라서 참가자 노드들은 서로 직접적으로 상호작용하지 않는다. 이것은 서로에 영향을 미치는 트랜잭션에 참가자 노드들이 관여하지만, 적어도 하나의 참가자 노드가 트랜잭션 내의 적어도 다른 하나의 노드와의 프라이버시를 보존해야하는 경우에 유리할 수 있는데, 이는 후자의 두 노드는 직접 거래를 하지 않기 때문이다. 즉, 이 경우는 하나의 참가자 노드가, 다른 하나의 참가자 노드가 동일한 트랜잭션에 관여함을 알지 말아야하는 경우이다.
신원 관리자(Identity Manager)
신원 관리자 노드(170, 270)는 예를 들어 다음과 같은 여러 서비스를 제공할 수 있다.
a. 멤버쉽 관리.
b. 가명 관리(Pseudonym Management).
멤버십 관리의 경우, 신원 관리자 노드(170, 270)는 노드들이 시스템(예를 들어, 도 1, 도 2a 및 도 2b에 정의된 시스템)에 가입 및 탈퇴하는 것을 허용할 수 있다. 도 1 및 도 2a-b에서 앞서 서술된 시스템들은 도메인이라 지칭될 수 있으며 하나의 노드는 여러 도메인들의 멤버일 수 있다. 신원 관리자 노드(170, 270)는 노드들이 공개 키들을 등록, 취소 및 교체(rotate)하는 것을 허용할 수 있다. 신원 관리자 노드(170, 270)는 주어진 노드가 나타내는 참가자를 알 수 있다. 또한 각 노드의 신뢰 레벨을 정의할 수 있다. 예를 들어, 신뢰 레벨은 도메인(예컨대, 결제 시스템: settlement system)의 운영자에 대해서는 강할 수 있으며 또는 (예컨대, 결제 시스템의 참가자)에 대해서는 약할 수 있다. 대안적으로, 신뢰 레벨은 각 노드에 대해 동일하도록 선택될 수 있다. 요컨대, 신원 관리자 노드(170, 270)은 노드들이 특정 노드의 신원과 관련된 공개 키들을 등록, 취소 및 교체할 수 있도록 하여 시스템의 다른 노드들이 도메인 내의 특정 노드를 식별할 수 있게한다. 특정 노드의 신원은 본 명세서의 다른 곳에서 상세히 설명된 바와 같이 분쟁 해결과 같은 경우에 유용할 수 있다.
가명 관리의 경우, 신원 관리자 노드(170, 270)는 노드가 가명 키(예를 들어, 서명자의 신원을 드러내지 않고 메시지에 서명하는 키)를 생성하도록 허용할 수 있다. 권한있는(previleged) 참가자(예컨대, 외부 노드 또는 심판 노드)가 이것을 요청하면, 신원 관리자 노드(170, 270)는 이전에 생성된 가명 ID들을 언클로킹(uncloak)할 수 있다. 가명 ID는 가명 주소일 수 있으며, 이는 노드의 실제 ID를 숨기는 동시에 다른 노드들에 의해 식별자로서 이용될 수 있다.
신원 관리자 노드(170, 270)를 사용할 때, 수신 노드(120, 122, 220, 222)는 제출 노드(110, 210) 또는 다른 수신 노드(120, 122, 220, 222)의 신원을 반드시 알아야할 필요는 없다. 본 일례에서, 수신 노드들은 다른 수신 노드들의 신원만을 알고 있으며(이들이 동일한 프로세스(202)의 참가자인 경우); 그렇지 않으면 수신 노드들은 다른 수신 노드의 가명만을 알 수 있다. 외부 노드(130, 230)는 가명 주소를 사용하여 수신 노드에 메시지 전달을 허용할 수 있고, 그리고 신원 관리자 노드(170, 270)를 사용하여 가명의 참가자 ID를 해결(resolve)할 수 있다.
외부 노드
외부 노드(130, 230)는 다수의 참가자들이 참여하는 프로세스를 구성하는 다수의 트랜잭션들에 대응하는 복수의 메시지들에 대한 순서(order)를 제공할 수 있다. 일례에서, 외부 노드(130, 230)는 예를 들어, 외부 노드(130, 230)에 의해 제공되는 고유한 타임스탬프를 통해 메시지들이 고유하게 시퀀싱되는 글로벌 토탈-오더(global total-order) 멀티캐스트(도메인에 대한)를 제공할 수 있다. 따라서, 전역 오더링은 타임스탬프로부터 도출될 수 있다. 그러나, 일부 예들에서, 복수의 메시지들의 순서는 타임스탬프가 아닌 암호화되지 않은 서브메시지의 정보에 적어도 부분적으로 기초할 수 있다는 것을 이해해야 한다. 다른 시나리오에서, 다른 곳에서 설명된 바와 같이, 외부 노드(130, 230)에 의해 제공되는 타임스탬프는 물리적 또는 논리적 타임스탬프일 수 있다.
일부 예에서, 단일 트랜잭션에 대한 순서를 제공하는 것이 가능하다. 즉, 외부 노드(130, 230)는 메시지들이 고유하게 시퀀싱되는 글로벌 토탈-오더 멀티캐스트를 제공할 수 있기 때문에, 다른 트랜잭션들이 아직 존재하지 않더라도 순서가 성립될 수 있다. 예를 들어, 외부 노드에 아직 제출되지 않은 임의의 다른 트랜잭션들 또는 제안된 트랜잭션들이 나중에 타임스탬프될 수 있도록, 제 1 제안된 트랜잭션이 타임스탬프될 수 있다. 따라서, 본 일례에서 제 1 제안된 트랜잭션은 프로세스에 대해 존재할 수 있는 모든 트랜잭션들의 글로벌 토탈 오더에서 첫 번째(즉, 시간상으로 첫 번째)가 될 수 있다.
본 명세서의 일부 예들에서 언급된 바와 같이, 외부 노드(130, 230)는 단일 메시지를 전달하는 대신에 세분화된 메시지 전달(fine-graine message delivery)을 제공할 수 있다. 즉, 서브메시지들(142, 242, 144, 244)의 목록이 수신 노드(220, 222)로 전달될 수 있다. 모든 서브메시지들은 이들이 포함된 메시지(140, 240)와 동일한 타임스탬프를 수신할 수 있다. 특히, 각 서브메시지는 수신 노드들의 상이한 세트를 가질 수 있으며, 각각의 수신 노드는 원본 메시지(140, 240)로부터 도출된 순서대로 서브메시지를 수신할 수 있다.
외부 노드(130, 230)는 또한 제출 증명(proof of submission)을 제공할 수 있다. 즉, 제출 노드(110, 210)은 제안된 트랜잭션(140, 240) 또는 확인(250, 252)의 제출에 대해 외부 노드(130, 230)로부터 증명(proof)을 수신할 수 있다. 증명은 분쟁에서 증거(evidence)로 사용될 수 있으며, 이는 예를 들어, 확인이 누락된 경우(missing)에 이용될 수 있다. 제출 증명에 대응하여, 노드가 트랜잭션 또는 확인을 보냈다는 것을 거부할 수 없도록, 메시지의 부인 방지(non-repudiation)에 대한 추가 요구가 있을 수 있다. 마지막으로, 외부 노드(130, 230)에 의한 전달 증명은 메시지 순서에 대한 증거를 수신 노드에 제공할 수 있다.
일부 예들에서, 외부 노드들(130, 230)은 외부 노드가 전달하는 모든 메시지들 또는 메시지들의 묶음(batch)의 진위성에 대한 암호화 증명(cryptographic proof)을 제공할 수 있다(또는 질의되는 경우 제공하도록 요구될 수 있다). 이들은 제출 노드(또는 중재자 노드(280)와 같은 다른 노드)로 전송된 암호화 "영수증(receipt)"으로 작용할 수 있다.
중재자(Mediator)
중재자 노드(280)는 도 2b에 도시된 바와 같은 시스템의 일부를 형성할 수 있다. 중재자 노드(280)를 갖는 시스템에서, 중재자 노드(280)는 제안된 트랜잭션의 검증에 대한 합의(consensus)가 있는지 여부를 결정하기 위해, 수신 노드들로부터 확인들을 수신하고 확인들을 집계할 수 있다. 일부 경우, 이것은, 더 넓은 네트워크를 통해 전송되는 확인들의 총량을 감소시키기 위해 중재자 노드(280)가 사용될 수 있음을 의미한다. 일 예에서, 중재자 노드(280)는, 트랜잭션이 수락/확인된 것으로 간주되기 위해 중재자 노드(280)가 수신할 것으로 예상해야하는 모든 예측된 확인들을 설명하는 메시지를 수신할 수 있다. 중재자 노드(280)는 수신한 확인들과 예상된 확인들을 비교하여, 트랜잭션이 수락/확인되어야하는지를 결정할 수 있다.
또한, 중재자 노드(280)는 확인이 전송되었는지 수신되었는지에 대한 분쟁이있는 경우 사용되는 노드일 수 있다. 중재자 노드(280)는 수신 노드들로부터의 모든 확인들을 집계할 수 있기 때문에, 특정 노드에 의해서 확인이 전송되었던 경우, 확인이 전송되어야하는데 전송되지 않은 경우, 또는 모든 관련 수신 노드들에 의해서 확인이 적절히 수신된 경우 등에 대한 반론의 여지가 없는(indisputable) 기록 역할을 수행할 수 있다.
확인들을 집계할 때, 중재자는 확인 정책을 고려할 수 있으며, 확인 정책은 제안된 트랜잭션을 검증하고 확인하는데 필요한 노드들을 결정할 수 있을 뿐만 아니라, 제안된 트랜잭션을 선택적으로 검증하고 확인할 수 있지만 제안된 트랜잭션이 확인되기 위하여 그렇게 하도록 요구되지 않을 수도 있는 노드들을 결정할 수 있다. 즉, 일부 확인 정책에서 수신 노드들의 서브세트는 확인에 대해 응답해야할 필요가 있을 수 있다. 수신 노드들의 나머지 서브세트는 선택적 검증자(optional validator)가 될 수 있는바, 선택적 검증자로부터 수신된 확인이 제안된 트랜잭션의 검증에 대한 합의를 결정하는 일부로서 집계될 수 있지만, 제안된 트랜잭션을 확인하고 이를 원장에 입력하기 위해 상기 확인이 필요하지 않을 수 있다는 점에서, 선택적 검증자가 될 수 있다. 중재자 노드를 사용하여 확인들을 집계하는 것은, 프로세스 또는 제안된 트랜잭션에 관여된 노드들의 신원을 보호하는 효과를 가질 수 있다. 즉, 중재자 노드는 특정 확인을 제공하는 노드들의 신원 또는 확인 메시지 그 자체를 반드시 공유하지 않고도, 확인들을 집계하고 확인 조건 또는 정책이 충족되었는지 여부를 결정하는 프록시 역할을 할 수 있다.
또한, 더 복잡한 확인 정책들이 있을 수 있다. 예를 들어, 적어도 제 1 노드로부터 확인을 수신해야만 하지만 2개의 노드들로부터 확인을 수신할 필요가 없는 여러 노드가 있는 시스템에 확인 정책이 있을 수 있다. 구현될 수 있는 확인 정책의 많은 추가 변형예들이 존재함을 이해해야 한다.
일부 예에서, 확인 정책은 트랜잭션을 승인하는 확인 당사자들의 수(또는 세트)에 기초하여 액션에 대한 정족수(quorum)를 지정할 수 있다(나머지 당사자의 일부 또는 전부가 액션을 거부하더라도). 다른 예에서, VIP 확인 정책은 일부 참가자 노드들에 VIP 상태를 제공하며, VIP 상태는 상기 일부 참가자 노드들이 한 명 이상의 다른 이해관계자들(stakeholder)을 대신하여 액션을 검증할 수 있게 하거나 및/또는 이들을 필수 확인 당사자(mandatory confirming party)로 만들 수 있다(VIP에 대한 자세한 내용은 아래에서 별도로 설명됨).
확인 정책은 예를 들어, 암호화 증명자(cryptographic prover)(예컨대, zkSNARK, zkSTARK) 또는 신뢰할 수 있는 실행 환경(예컨대, Intel SGX)에 의한 증명을 통해 하나 또는 복수의 노드들에 의한 증명(attestation)에 의존할 수 있다.
일부 경우에서, 제출 노드는 중재자 노드(280)를 통해 제안된 트랜잭션을 제출할 수 있으며, 그 후 수신 노드(220, 222)로부터 확인을 수신하고 집계할 수 있다. 하나의 중재자 노드 또는 각각이 잠재적으로 다른 수신 노드들을 갖는 여러 중재자 노드가 있을 수 있다. 또한 모든 수신 노드들이 중재자 노드와 관련될 필요는 없다. 일부 경우에, 예를 들어, 제 1 수신 노드는 통상적으로 외부 노드, 제출 노드 또는 다른 수신 노드들에 확인을 전달할 수 있는 반면, 수신 노드의 추가 서브 세트는 중재자 노드를 통해 자신의 확인을 전달할 수 있다. 다른 경우에는, 전체 네트워크가 네트워크 내의 노드들에 의해 전송 또는 수신된 확인들에 대한 일관된 뷰(consistent view)를 갖는 것을 보장하도록, 네트워크의 모든 노드들은 중재자 노드 또는 여러 개의 상호 연결된 중재자 노드들을 통해 확인을 제출해야할 수 있다.
중재자 노드(280)는 수신 노드들로부터 수신된 확인들 및 기타 메시지들을 저장할 수 있다. 이는 감사를 수행하는데 필요한 경우 감사자(auditor)가 확인 또는 메시지를 검색할 수 있으므로 감사가능성(auditability)을 허용한다. 저장소 API는 감사자가 저장소로부터 수신된 메시지를 검색할 수 있게 한다. 저장소 API는 특정 트랜잭션 또는 제안된 트랜잭션에 대한 결과 메시지가 전송되었는지를 감사자에게 알릴 수 있다.
도메인 메시징 API 및 속성
도메인 메시징 API는 해당 도메인의 각 참가자 노드 및 시스템 엔티티들(예를 들어, 제출 노드 110, 수신 노드 120 등)에 노출된다. 이제 도메인 메시징 API가 메시지를 "Send"하는 단일 커맨드와 "수신(Receip)", "전달(Deliver)" 및 "하트비트(Heartbeat)"의 세 가지 이벤트 유형을 갖는 비제한적인 일례를 설명할 것이다.
● 커맨드 Send(messageId, b, Sig(b, sksender)), 여기서 messageId는 메시지 식별자이고, b는 배치(batch), n 개의 튜플 목록(mi, recipientsi)이며, 여기서 mi는 메시지이고 recipientsi 는 0 <= i <n 에 대한 mi 의 수신자 목록이다. 배치 b는 전송하는 참가자의 비밀 키 sksender에 의해 서명되어야 한다. send 커맨드는, 동일한 타임스탬프 하에서의 여러 메시지들(수신자들이 다른)과 같이 메시지들을 일괄적으로 보내는데 사용될 수 있다.
● 이벤트 Receipt(messageId, ts, proof(sender, messageId, ts, b)), 여기서 messageId는 메시지 식별자이고, ts는 타임스탬프이고, sender는 노드 식별자이고 그리고 b 는 배치이다. receipt 이벤트는 제출된 메시지들의 암호화 증거를 수신인들에게 제공한다. proof는 서명을 포함할 수 있다.
● 이벤트 Deliver(ctr, ts, b', proof(recipient, ctr, ts, b')), ctr 는 각각의 수신자에 대한 단조적으로 증가하는 카운터이고, ts는 순서를 정의하는 타임스탬프이고, b' 는 메시지 배치이고, 그리고 proof는 수신인의 신원을 포함하는 전달(deliver)에 대한 암호화 증명(cryptographic proof)이다. 직관적으로, 노드는 자신에게 어드레싱된 모든 메시지들을 알 수 있으며, 뿐만 아니라 각 메시지의 다른 수신자들을 알 수 있다(b는 배치이므로 이것이 가능하다).
● 이벤트 Heartbeat(ctr, ts, proof(recipient, ctr, ts)), ctr 은 감소하지 않는(non-decreasing) 카운터이고, ts 는 타임스탬프이고, proof는 하트비트 방출(heartbeat emittance)에 대한 암호화 증명이다.
일부 예에서, 노드들에 대한 도메인 메시징 API는 다음의 속성들 중 하나 이상 또는 일부 경우 모두를 갖는 것이 바람직하다.
● 안정적인 전달(Reliable delivery): 모든 메시지들은 결국 그들의 모든 수신자들에게 전달된다. 만일, Send(messageId, b, Sig(b, sksender))가 올바르게 작동하는 노드 sender에 의해 호출되는 경우, ts 및 ctr이 있으며, 따라서 Deliver(ctr, ts, b', proof(p, ctr, ts, b')) 이벤트가 결국 수신자 세트(즉, recipients i 로부터의 모든 요소들의 조합(union))의 각 노드 p에서 결국 다음과 같이 트리거된다:
b' = [(m, recepients) ∈ b │p ∈ recepients]
● 생성 없음(No creation): 노드 p에서 트리거되는 모든 Deliver(ctr, ts, b', proof(p, ctr, ts, b'))에 대해, 일부 노드는 일부 messageId와 함께 Send(messageId, b, Sig(b, sksender))를 이전에 호출하며, 따라서
b' = [(m, recepients) ∈ b │p ∈ recepients] 이다.
더욱이, 제출 이벤트에 대한 전달(Deliver)의 유도 매핑은 단사적(injective)이다(즉, 해당 제출 이벤트들 보다 더 많은 전달(deliver) 이벤트는 없다). 이러한 속성은 Send 커맨드에 필요한 서명으로 인해 검증될 수 있다. 따라서 발신자(sender)는 메시지 전송을 거부할 수 없다.
● 순차 전달(In-order delivery): Deliver(ctr, ts, -, -)가 노드에서 트리거되는 경우, 다음 중 정확히 하나가 유지된다(hold):
o ctr = 0 이고 그리고 이 노드에서는 그 어떤 앞선(earlier) 전달(Deliver) 또는 하트비트 이벤트가 트리거되지 않았다.
o ctr은 ctr'+ 1과 같으며, 여기서 ctr'는 전임(predecessor) 전달 또는 하트비트 이벤트의 카운터이다.
또한, ts는 임의의 앞선 전달(Deliver) 이벤트 또는 하트비트 이벤트의 ts 보다 커야한다. 타임스탬프 순서는 배치 내부 순서(batch-internal ordering)와 함께 글로벌 토탈 오더를 제공한다. 이는 암호화 증명과 함께 메시지들이 메시지 스트림 내에 소급적으로(retroactively) 삽입될 수 없음을 보장하고 그리고 생략된 메시지들이 수신자에 의해 감지될 수 있게한다.
● 합의(Agreement):
Deliver(ctr, ts, b, proof(p1, ctr, ts, b)) 및 Deliver(ctr', ts, b', proof(p2, ctr', ts, b'))가 노드 p1 및 p2 에서 각각 트리거되는 경우,
filter bothReceive b = filter bothReceive b' 이고
여기서
bothReceive(m, recipients) = {p1, p2} ⊆ recipients
● 정품 배달 증명(Genuine delivery proofs): Deliver(ctr, ts, b, proof(p, ctr, ts, b))가 노드 p에서 이전에 트리거되지 않는 한, 그 누구도 proof(p, ctr, ts, b)을 생성할 수 없다. 실제로 이것은 proofs 에 대한 서명들을 사용하여 성취된다.
● 제출 증명(Proof of submission): Send(messageId, b, Sig(b, sksender))가 노드 발신자(sender)에 의해 호출되고 발신자(sender)가 충돌하지 않으면, Receipt(messageId, ts, proof(sender, messageId, ts, b))가 발신자에서 결국 트리거되도록 ts가 존재한다. 타임스탬프 ts는 Send에 대응하는 Deliver 이벤트의 타임스탬프와 동일해야만 한다.
● 인과 관계(Causality): 올바르게 작동하는 노드 발신자에 의해 Send(messageId, b, -)가 호출되는 경우, 영수증 Receipt(messageId, ts, _)의 타임스탬프 ts는 발신자 노드에서 트리거된 임의의 앞선 Deliver 또는 하트비트 이벤트의 타임스탬프보다 엄격하게 커야한다.
● 정기적인 하트비트(Regular heartbeats) : 정기적인 간격으로, Deliver 또는 하트비트 이벤트가 각 참가자 110, 120에서 트리거된다.
● 순차 하트비트(In-order heartbeats): 참가자에서 하트비트(ctr, ts, proof(ctr, ts)) 이벤트가 트리거될 때마다, 다음 중 정확히 하나가 유지된다.
o ctr = 0 이고 그리고 이 참가자에서는 그 어떤 앞선(earlier) 전달(Deliver) 또는 하트비트 이벤트가 트리거되지 않았다.
o ctr은 ctr'+ 1과 같으며, 여기서 ctr'는 전임(predecessor) 전달 또는 하트비트 이벤트의 카운터이다.
또한 ts는 임의의 앞선 전달(Deliver) 또는 하트비트 이벤트의 ts보다 커야한다. 하트비트 이벤트에서 카운터를 증가시키면 모든 카운터가 정확히 하나의 타임스탬프에 매핑된다.
제안된 트랜잭션(Proposed Transaction)
제출 노드(110)는 제안된 트랜잭션을 제출함으로써 트랜잭션을 제출할 수 있다. 일반적으로 트랜잭션 프로토콜은 제출 노드가 액션/트랜잭션에 대해 알려야하는 당사자들(즉, 선언된 이해관계자)를 지정하도록 요구할 것이다. 제안된 트랜잭션은 다른 수신 노드들로 어드레싱될 수 있다(이것은 또한, 용량 모니터, 수수료 또는 리소스 어카운팅 유닛, 외부 노드, 중재자 등과 같은 시스템의 다른 측면도 어드레싱할 수 있다). 제안된 트랜잭션의 정보는 비암호화된(unencrypted) 서브메시지 및 암호화된(encrypted) 서브메시지를 포함할 수 있다. 암호화된 서브메시지는 암호화된 형태로 트랜잭션을 이해관계자(예컨대, 제안된 트랜잭션의 영향을 받는 수신 노드들)에게 설명하는 실제 페이로드를 포함할 수 있다.
일부 예들에서, 트랜잭션 프로토콜은 제출 노드(110)가 제출 노드의 정보를 지정하도록 요구한다. 이것은 제출 노드(110)가 트랜잭션 및/또는 제안된 트랜잭션의 일부에 서명하도록 요구하는 것을 포함할 수 있다. 일부 예에서, 이것은 트랜잭션의 모든 최상위 레벨 액션에 대해 제출 노드의 서명을 요구할 수 있다. 다른 예들에서, 이것은 제출 노드(110)가 서명하고(sign) 그리고 영향을 받는 이해관계자들에게 서명(signature)을 포워딩하는 것을 포함한다.
도 3은 제안된 트랜잭션(302)의 일례(300)를 도시한다. 본 일례에서, 참가자 A(330)는 참가자 P(페인트공)(340)가 참가자 A의 집을 페인트칠하기를 원하고 그리고 은행(342)으로부터 참가자 A가 보유하는 IOU를 사용하여 이에 대해 지불할 의향이 있다. 참가자 A는 페인트오퍼(PaintOffer) 프로세스(302)를 이용하여 참가자 P에 이를 제안한다.
본 일례의 문맥에서, 시스템은 여러 액션들을 수행한다. 첫 번째는 제안된 트랜잭션을 정의하는 계약을 생성하는 액션이다(그리고 그 정의를 원장에 기록). 두 번째 유형의 액션은 계약상의 액션들을 실행하는 것이며, 이는 트랜잭션의 여러 액션들을 포함할 수 있다. 예를 들어, 참가자에 의한 계약의 수락은 다수의 서브액션들(310)(그 자체로 액션들로 간주될 수 있음)을 초래하는 최상위 액션이다. 이것은 예를 들어, 은행과 함께 참가자 A의 IOU 로부터 가치(value)의 양도(transfer)을 실행하는 것을 포함할 수 있으며, 또 다른 액션은 참가자 P의 이익을 위해 새로운 IOU를 생성하는 것을 포함한다. 시스템 관점에서 보면, 이러한 액션들은 (i) 그 액션에 대한 트랜잭션 프로토콜에 의해 승인되어야하고 그리고 (ii) 기저 시스템 모델에 순응해야만 한다 - 따라서, 상기 액션이 원장에 유효하게 기록될 수 있다.
트랜잭션의 루트(root)에서 참가자 P(340)는 페인트 제안(paint offer)에 대한 선택권을 행사한다. 다음으로, 이것은 참가자 A(330)가 IOU(310)에서 자신의 양도 선택(transfer choice)을 행사하게하며, 동일한 은행(342)에 의해 지원되는, 참가자 P의 이익을 위해 새로운 IOU(312)를 생성할 수 있다. 이와 동시에, 참가자 P가 참가자 A의 집을 페인팅하는데 동의하는 합의가 생성된다(320). 본 명세서의 맥락에서, 선택을 실행하는 것은, 노드가 실행할 권한이 있는 스마트 계약에서 코드 세그먼트(들)를 노드가 실행한다는 것을 의미할 수 있다. 따라서, 예를 들어, 위의 예시에서 참가자 P(340)는 페인트 제안에 대한 참가자 P의 수락을 기록하는 PaintOffer 스마트 계약 내의 코드 세그먼트(들)를 실행함으로써 페인트 제안을 수락하는 선택을 행사할 수 있다. 본 개시 내용의 시스템과 함께 사용할 수 있는 선택 행사 및/또는 스마트 계약의 행사에 관한 추가 세부 사항은 미국 특허 공보(2017/0316391), WO 2017/189027, WO 2017/187394(모두 US 62/329,888의 우선권을 주장함), 및 호주 특허 번호 2019200933, WO 2019/082142(모두 AU 2017904367의 우선권을 주장함)에서 찾을 수 있다.
각각의 노드(330, 340, 342)는 노드가 이해관계자인 계약들에 영향을 미치는 트랜잭션 부분만을 알아야할 필요가 있을 수도 있다. 전체 트랜잭션은 PaintOffer의 실행으로 인해 발생하므로, 이해관계자(참가자 A 및 참가자 P)는 전체 트랜잭션을 알아야할 필요가 있을 수 있다. 반대로, 은행과 참가자 A는 IOU 양도(IOU transfer)(310)에 대해서만 알면되고, 참가자 P는 생성된 IOU(312)에 대해서만 알면 될 수 있다. 이로 인해, 도 3에 도시된 바와 같이, 트랜잭션의 서로 다른 부분들이 분해될 수 있다.
무결성(integrity)을 위해, 제안된 트랜잭션이 모든 이해관계자에게 전송되면 충분할 수 있다. 하지만, 이것은 프라이버시 보호에 충분하지 않다. 다행스럽게도, 모든 이해관계자가 전체 트랜잭션에 대한 완전한 가시성을 필요로하는 것은 아니다. 그들의 뷰(view)는 당사자 간의 무결성과 동기화를 보장하기에 충분한 정보만을 공개하면 된다.
도 3의 각각의 실선 사각형은 트랜잭션의 해당 부분에 대한 프라이버시 범위(관련 당사자가 이탤릭체 및 밑줄로 표시됨)를 나타낸다. PaintAgree(320)에 대한 별도의 실선 사각형이 없음에 주의해야 한다; 참가자 A와 P는 이미 PaintOffer 실행에 대해 알고 있으므로, 이들은 PaintAgree 320의 생성에 대해 별도로 배울 필요가 없다(이것이 암시적으로 추론될 수 있으므로).
하지만, 상황은 새로 생성된 IOU(312)에 대해서는 다를 수 있다. 은행(342)은 직사각형(302)의 이전 컨텍스트에 대해 어떠한 것도 알아서는 안된다. 특히, 은행(342)은 참가자 P(340)가 트랜잭션의 다른 계약들 중 임의의 계약의 참가자였음을 가정할 수도 없으며 알아서도 안된다. 이것이 바로, 은행(342)과 참가자 P(340) 둘다가 외부 직사각형(310)을 알고있는 것에 의해서 실선 직사각형(312)의 내용을 이미 적어도 부분적으로 알고 있는 경우에도, 은행(342)과 참가자 P(340) 사이에서 공유되는 별도의 실선 직사각형(312)이 존재하는 이유이다. 은행(342)은 다른 직사각형들(302 또는 320)이 무엇인지(즉, A가 무엇을 지불하는지) 또는 이해관계자들이 누구인지를 알아서는 안된다.
트랜잭션
당업자는 본 명세서에서 사용되는 트랜잭션이 트리형 구조를 가질 수 있음을 이해할 것이다. 트랜잭션에는 이해관계자 및/또는 관찰자가 있을 수 있으며, 따라서 다른 이해관계자들이 볼 수 있는 이러한 트리형 구조의 부분들(예컨대, 서브-트리)이 변경될 수 있다. 물리적 전송 저장 형식(physical transport storage form) 내에서, 이러한 트랜잭션 서브-트리는 서브-뷰(sub-views)라고 지칭된다. 일례에서, 각각의 수신 노드(120, 122, 220, 222)는 의미론적으로는 트랜잭션 서브-트리의 서브세트로서, 그리고 물리적으로는 전송된 트랜잭션 메시지의 서브-뷰들의 서브세트로서, 볼 수 있는 자격이 있는 트랜잭션의 일부만을 획득한다.
도 3에 도시된 것과 같은 트랜잭션(가령, 트랜잭션 302)은 본질적으로 원자적(atomic)일 수 있다. 즉, 이것은 하나의 단위로(as a unit) 완료되거나 실패할 수 있다. 일반적으로 당사자들은 트랜잭션의 일부만 볼 수 있으므로, 참가자는 자체적으로 트랜잭션의 유효성 또는 수락 여부를 결정할 수 없을 수도 있다. 더욱이, 본 일례에서, 트랜잭션의 유효성이 위임될 수 있도록 의도된 방식으로 인하여, 전체 트랜잭션을 보는 참가자들에 의해서도 이러한 결정이 내려질 수 없다. 예를 들어, 참가자 P(340)의 노드는 위의 전체 트랜잭션을 볼 수 있지만, 은행(342)이 참가자 A(330)의 노드에 발행한 IOU(310)에 대한 참가자는 아니다. 트랜잭션의 유효성 또는 수락을 평가하기 위해 참가자 P(340)의 노드는 은행(342)으로부터의 확인을 필요로 할 수 있다.
비암호화된 서브메시지(Unencrypted submassage)
도 2a 및 도 2b의 240과 같은 제안된 트랜잭션은 비암호화된 서브메시지(242)를 포함할 수 있다. 암호화되지 않은 서브메시지는 공개적으로 이용할 수 있는 또는 트랜잭션 프로세스의 모든 참가자가 이용할 수 있는 제안된 트랜잭션(240)에 대한 정보를 포함할 수 있으며 그리고 일반적으로는 임의의 참가자에 대한 사적인(private) 정보는 포함하지 않을 수 있다. 예를 들어, 비암호화된 서브메시지는 트랜잭션 시간을 포함할 수 있거나 또는 원장의 이해관계자들 사이에 합의된(암시적으로 또는 명시적으로, 가능한 동시에) 물리적-시간 규칙의 브랜치 버전의 선택을 포함할 수 있다(예컨대, 어떤 용량 또는 샤딩 모델이 사용될 수 있음). 일반적으로, 이러한 정보는 트랜잭션에 대한 공개적으로 이용가능한 정보일 수 있다.
일부 예들에서, 외부 노드는 타임스탬프를 제공함으로써 비암호화된 서브메시지에 트랜잭션 시간을 제공한다. 다른 예에서 제출 노드는 제출 노드에 의해 제공된 타임스탬프를 기반으로 트랜잭션 시간을 제안할 수 있다. 트랜잭션 시간은 단순한 타임스탬프 또는 외부 노드(230)가 제안된 트랜잭션(240)을 수신한 시간의 디지털 기록일 수 있다. 타임스탬프는 날짜 및 시간, 표준시 또는 초 단위 미만의 정확도를 갖는 임의의 시간 측정치를 제공할 수 있으며, 이는 트랜잭션들이 거의 동시에 외부 노드로 전송된 경우에도 트랜잭션들을 오더링하는데 도움을 줄 수 있다.
일 예에서, 타임스탬프는 외부 노드(230)가 제안된 트랜잭션(240)을 언제 수신한지를 지정하는 물리적 타임스탬프가 아닐 수 있으며, 상기 타임스탬프는 논리적 타임스탬프일 수 있다. 논리적 타임스탬프는 외부 노드(230)가 제안된 트랜잭션(240)을 수신한 물리적 타임스탬프와 일부 논리적 시간 오프셋과의 조합일 수 있다. 예를 들어, 논리적 타임스탬프는 외부 노드(230)가 제안된 트랜잭션(240)을 수신한 시간을 지정하는 물리적 타임스탬프에 일부 논리적 시간 오프셋이 더해진 조합일 수 있으며, 따라서, 논리적 타임스탬프는 물리적 타임스탬프 보다 나중일 수 있다. 일례에서, 논리적 시간 오프셋은 제안된 트랜잭션(240)을 제출하는 제출 노드(210)에 의해 제공될 수 있다. 따라서, 외부 노드(230)에 의해 제공되는 물리적 타임스탬프와 제출 노드(210)에 의해 제공되는 논리적 타임스탬프의 연결(concatenation)은 일부 경우에 논리적 타임스탬프를 형성할 수 있다. 다른 경우에, 외부 노드(230) 또는 네트워크의 다른 노드는 논리적 시간 오프셋을 제공할 수 있다.
제출 노드(210)가 논리적 시간 오프셋을 제공하도록 허용하는 것은, 수신 노드들(220, 222)이 제안된 트랜잭션(240)에 대한 확인을 전송해야만 하는 확인 응답 데드라인을 제출 노드(210)가 어느 정도까지는 제어할 수 있게하며 및/또는 다른 트랜잭션들에 대한 제안된 트랜잭션(240)의 오더링을 다소 제어할 수 있게한다. 예를 들어, 일례에서, 본 개시의 시스템은 그것이 확인되고 원장에 입력되기 위해, 제안된 트랜잭션(240)의 확인을 관련 수신 노드들(220, 222)이 보내야만 하는 확인 응답 데드라인을 제공할 수 있다. 확인 응답 데드라인은 논리적 타임스탬프를 참조하여 계산될 수 있다. 예를 들어 확인 응답 데드라인은 제안된 트랜잭션(240)의 논리적 타임스탬프에 미리 설정된 일부 시간 기간을 추가함으로써 계산될 수 있다. 제출 노드(210)가 논리적 시간 오프셋을 제공하도록 허용함으로써, 시스템은 제안된 트랜잭션(240)의 논리적 타임스탬프를 제출 노드(210)가 어느 정도까지는 설정하도록 허용할 수 있으며, 이는 확인 응답 데드라인에 영향을 미칠 수 있다. 단지 일례로서, 제출 노드(210)는 논리적 시간 오프셋을 변경함으로써 자신의 확인 응답 데드라인을 조정할 수 있으며, 따라서 관련 수신 노드(220, 222)는 확인 응답 데드 라인을 충족시킬 수 있으며 그리고 적절한 데드라인 내에서 확인을 전송하는 것을 실패하지 않을 수 있다. 예를 들어, 수신 노드들(220, 222)이 특정 제안된 트랜잭션(240)을 확인하는데 더 많은 시간이 필요하다라고 제출 노드(210)가 결정하는 경우, 제출 노드(210)는 외부 노드(230)에 의해 제공되는 물리적 타임스탬프보다 제안된 트랜잭션(240)의 논리적 타임스탬프를 다소 늦게 설정할 수 있도록 넉넉한 논리적 타임스탬프를 제공할 수 있다. 그 반대의 경우도 가능하다.
또한, 일례에서, 논리적 타임스탬프는 제안된 트랜잭션(240)에 대한 최종적인(definitive) 트랜잭션 시간 역할을 할 수 있으며, 이는 다른 트랜잭션들에 대한 제안된 트랜잭션(240)의 순서(ordering)에 영향을 미칠 수 있다. 즉, 제안된 트랜잭션(240)을 포함하는, 트랜잭션들의 글로벌 토탈 오더는 모든 트랜잭션들의 논리적 타임스탬프를 검사하고 그리고 논리적 타임스탬프를 사용하여 이러한 트랜잭션들을 제때(in time) 정렬함으로써 결정될 수 있다. 이와 같이, 논리적 시간 오프셋을 제공함으로써, 제출 노드(210)는 합리적인 범위 내에서 다른 트랜잭션들에 대한 제안된 트랜잭션(240)의 순서를 어느 정도 지시(dictate)할 수 있다. 구체적으로, 제출 노드(210)가 제안된 트랜잭션(240)의 우선 순위를 염려하는 경우, 제출 노드(210)는 논리적 시간 오프셋을 상대적으로 짧게 설정함으로써, 제안된 트랜잭션(240)이 최상의 논리적 타임스탬프를 수신하고 그리고 트랜잭션들의 글로벌 토탈 오더에서 우선순위를 달성할 가능성을 보장할 수 있다.
일부 경우에, 제안된 트랜잭션(240)을 포함하여 트랜잭션들의 순서를 변경하는 트랜잭션 시간이 주어질 수 있다. 이러한 재정렬(reordering)은, 재정렬이 트랜잭션의 논리적 타임스탬프에 기초할 수 있기 때문에 여기서는 때때로 논리적 재정렬이라 지칭될 수도 있다. 논리적 재정렬의 경우, 특정 일례들에서, 위에서 설명된 바와 같이 논리적 시간 오프셋 및 외부 노드(230)에 의한 물리적 타임스탬프에 기초하는 논리적 타임스탬프가 제안된 트랜잭션(240)에 부여될 수 있다. 경우에 따라, 논리적 시간 오프셋은 물리적 타임스탬프와 논리적 타임스탬프의 차이로 간주될 수 있다. 논리적 시간 오프셋은 다음의 고려 사항들을 감안하여 너무 크거나 너무 작지 않도록 선택할 수 있다. 논리적 시간 오프셋이 크면, 제안된 트랜잭션(240)이 프론트-러닝(front-running)하는 경향이 있을 수 있다. 즉, 단지 일례로서, 트랜잭션 tx1 이 제출되었고 그리고 논리적 타임스탬프(예를 들어, 제출하는 노드(210)에 의해 일부 지시됨)를 수신한 이후에, 네트워크의 다른 참가자 노드는 나중에 앞선(earlier) 논리적 타임스탬프를 수신하는 충돌하는 제안된 트랜잭션 tx2 를 제출할 수 있다(예컨대, 이러한 참가자 노드에 의해 제공된 논리적 시간 오프셋으로 인해). 만일, 후속의 제안된 트랜잭션 tx2가 확인되고 그리고 장부에 입력된다면, tx1 이 자신의 물리적 타임스탬프에 따라 먼저 온 경우라 하더라도, tx1이 tx2와 충돌하기 때문에 tx1이 거부될 수 있다. 따라서, "대기열을 뛰어넘는(jumping the queue)" 다른 충돌 트랜잭션 없이 제출 노드의 제안된 트랜잭션이 확인되고 원장에 입력될 수 있도록, 실제로 제출하는 노드들은 다른 노드들의 리소스 경계들과 트랜잭션을 검증하는데 필요한 시간을 고려하여 논리적 시간 오프셋을 가능한 한 가장 짧게 설정하는 것이 유리함을 알 수 있을 것이다.
대안적으로, 앞선 트랜잭션 tx1 의 확인 응답 데드라인 이후에 나중의 제안된 트랜잭션 tx2 가 거부된다면, tx1에 대한 확인 응답 데드라인이 이미 경과했으므로, tx1 도 거부될 수 있다. 이러한 시나리오에서는, 궁극적으로 2개의 트랜잭션들이 모두 거부된다. 반대로, 논리적 시간 오프셋이 작다면, 수신 노드들은 단순히 계산적 제약 또는 네트워크 제약으로 인해, 확인 응답 데드라인까지 확인들을 보낼 수 없을 수 있다. 결과적으로, 논리적 시간 오프셋이 너무 작게 설정되면 트랜잭션이 거부될 수 있다.
또 다른 시나리오에서, 제안된 트랜잭션 tx1이 제출 노드에 의해 제출되고, 논리적 타임스탬프가 할당되고, 관련 수신 노드들에 의해 확인되고, 그리고 원장에 입력될 수 있다. 후속 제안 트랜잭션 tx2 가 동일한 또는 다른 제출 노드에 의해 제출되고, tx1의 논리적 타임스탬프 보다 앞선 논리적 타임스탬프가 할당되고, 관련 수신 노드들에 의해 확인되고, 원장에 입력될 수 있다. tx2의 트랜잭션 시간(예컨대, 논리적 타임스탬프)이 tx1의 트랜잭션 시간(예컨대, 논리적 타임스탬프) 보다 앞서기 때문에, tx1이 먼저 제출되었다하더라도 트랜잭션들의 글로벌 토탈 오더에서 tx1 에 비해 tx2 에 우선순위를 부여하는 논리적 재정렬이 발생할 수 있다.
암호화(Encryption)
암호화된 서브메시지는 대칭 암호화 또는 비대칭 암호화 또는 둘 모두로 암호화될 수 있다. 비대칭 암호화는 여러 키, 공개 키 및 개인 키를 사용하여 데이터를 암호화하고 해독한다. 임의의 적합한 암호화 방법이 사용될 수 있으며, 예를 들어 RSA 또는 타원 곡선 암호화가 사용될 수 있다.
암호화의 경우 다음의 동작들이 이용될 수 있다:
● 결정론적 비대칭 암호화 체계 Epub(pk, m), 이것은 주어진 공개 키 pk로 임의의 메시지 m을 암호화한다(예컨대, 공개 키 암호화라 지칭됨).
● 대칭 인증 암호화 체계 Esym(symk, m), 이것은 주어진 대칭 키 symk를 사용하여 임의의 메시지 m을 암호화한다. 인증은 외부 노드(230)에 의한 잠재적인 수정들로부터 보호할 수 있다(대칭 암호화라 지칭됨).
● 가명 파생 체계 가명(pseudonym derivation scheme pseudonym)(참가자, 토큰), 이것은 주어진 토큰을 사용하여 주어진 참가자의 가명을 도출한다.
암호화된 서브메시지
암호화된 서브메시지(144, 244)를 준비하기 위해, 제출 노드(110, 210)는 먼저 비밀 토큰 toka(예컨대, 신원 관리자(170)로부터)를 획득하고 각각의 액션 "a"에 대한 새로운 임시(nonce) Keya 를 준비할 수 있다. stkha 는 액션 a에대한 이해관계자들을 나타낸다고 하자. Subsa 는 a의 인-오더 트래버설(in-order traversal)에 의해 획득된 a의(자신을 포함하는) 서브-뷰들의 목록이다.
일례에서, 액션 a에 대한 암호화된 서브메시지는 다음과 같이 유도될 수 있다:
1. 암호화된 액션은 Esym(keya ,(bound(a), desc(a)))이며, 여기서 bound는 영향을 받는 이해관계자들이 스스로 얽매일 선택적 사전-언급된 공유 물리적-시간적 제약들(optional pre-stated shared physical-temporal constraints)을 표현하는 함수이다. 예를 들어, bound는 액션 a(리소스 모델에 의해 제공됨)의 리소스 소비를 추정할 수 있으며 그리고 desc(a)는 a를 서술하는 일부 완전한 수단(some complete means)(예컨대, 누출된(divulged) 입력들과 함께 모델 표현 또는 평가 추적(eval trace))이 될 수 있다.
2. 키들을 a의 서브-뷰들과 관련된 키들의 목록으로 설정한다([key a'I a' <- subsa], "서브-뷰들을 해독하는 키 목록"으로 읽음). 그런 다음 키들은, 트랜잭션 이해관계자 당 엔트리([Epub (pk(stkh), keys) I stkh <- stkha])를 구비한, 키 목록의 공개 암호화 목록으로 랩핑된 키의 형태로 보관 및 전송을 위해 보호된다. 다르게 말하면, 암호화된 서브메시지의 이러한 부분은 예를 들어, 트랜잭션에 대한 각 이해관계자에 대응하는 공개 키들의 암호화된 목록일 수 있으며, 관련 이해관계자는 대응하는 개인 키를 알고있다(예컨대, 이해관계자가 암호화된 서브메시지를 해독하도록 허용됨).
3. 그 액션의 예상 확인자들의 가명들을 생성하는데 사용되는 토큰들은 [toka' I a' <- subsa] 이다. 다르게 말하면, 암호화된 서브메시지의 이러한 부분은 예를 들어, 토큰들의 목록을 포함할 수 있으며, 이로부터 특정 액션을 확인할 필요가 있는 예상된 확인자들 각각의 가명(예컨대, 16 진수 어드레스)이 파생될 수 있다. 예를 들어, 그러한 정보는 네트워크의 노드(예를 들어, 외부 노드 230)가 네트워크의 어느 노드가 특정 액션을 확인해야 하는지를 결정할 수 있도록 하는데 유용할 수 있다.
따라서, 제안된 트랜잭션 페이로드를 포함하는 암호화된 서브메시지는 데이터 유형에 의해 설명될 수 있다(여기에서는 Haskell 로 작성되었지만 여러 다른 언어로 구현 가능함):
type RequestPayload = {
metadata :: RequestMetadata
, stakeholders :: [Pseudonym]
, descriptor :: [(EncryptedActionDescription, [Participant])]
}
예상된 확인들(Expected confirmations)
제안된 각 트랜잭션(예컨대, 도 2a-b의 제안된 트랜잭션 240)에 대해 제안된 트랜잭션을 수락/확인하는데 필요할 수 있는 확인들이 있으며, 그리고 노드는 트랜잭션을 위해 수신할 것으로 예상되는 확인들에 대한 결정할 수 있다라고 가정하자. 예상된 확인은, 제안된 트랜잭션이 수락/확인되고 원장에 입력되는 프로세스에서 참가자 노드로부터 필요한 긍정적인 응답일 수 있다. 일부 실시예에서, 각각의 노드는 어떤 노드들이 확인을 제공할 필요가 있는지를 결정할 수 있다(예를 들어, 그 특정 노드의 트랜잭션 범위의 뷰에 따라). 즉, 노드들(210, 220, 222)은 제안된 트랜잭션(240)을 수락 또는 확인하기 위하여 수신 노드들(220, 222) 중 어떤 것이 확인을 제공할 필요가 있는지를 평가할 수 있다. 예를 들어, 전체 확인(full confirmation)이라는 확인 조건과 함께 제안된 트랜잭션(240)을 제출하는 제출 노드(210)는, 예상된 확인들이 프로세스의 모든 참가자 노드들로부터이고 모든 확인들이 수신되었음을 결정할 수 있다.
일부 예들에서, 프로토콜은 확인 정책을 지정할 수 있다. 다른 예에서, 확인 정책(별도의 제목으로 아래에서 설명된 확인 조건을 포함할 수 있음)은 제출 노드에 의해서 제안된 트랜잭션에서 적어도 부분적으로 지정된다.
예상된 확인은 전체적으로 또는 부분적으로 결정될 수 있다. 즉, 일부 경우에서, 노드는, 트랜잭션 전체가 아니라 노드가 볼 자격이 있는 트랜잭션의 가시적인 부분에 대한 어떤 예상된 확인들이 필요한지를 결정할 수 있다. 이 경우, 상기 노드는 노드가 볼 자격이 있는 트랜잭션 부분에 대하여 노드가 수신한 확인들에 기초하여 트랜잭션의 일부가 수락/확인된 것으로 결정할 수 있다.
일 예에서, 제안된 트랜잭션(240)은 모든 유효한 예상 확인들을 설명하는 암호화된 서브메시지(244)에 정보(예를 들어, 예상된 확인 데이터)를 포함할 수 있다. 이러한 정보는 수신된 확인들을 검증하는데 사용될 수 있으며, 이는 예상된 확인 데이터로 수신된 확인들을 검증하기 위한 암호화 기능의 사용이 포함할 수 있다. 일부 예에서, 예상된 확인은 공개 키와 이러한 키가 서명하는데 필요한 트랜잭션 부분의 해시 형식일 수 있다. 신원 관리자(270)가 사용되는 경우, 키는 알려진 키의 가명일 수 있고 해시는 참가자 노드의 프라이버시를 보호하기 위해 솔트(salted)될 수 있다. 따라서 전체 트랜잭션에 대한 예상된 확인은 다음 데이터 유형(Haskell 로 작성됨)으로 제공될 수 있다:
type ExpectedConfirmations = [([Pseudonym], SaltedHash ActionDescription)]
시스템의 추가 특성들
일부 예에서, 확인들(150, 152, 250, 252)이 적시에 발생함을 보장하기 위해, 타임아웃의 개념이 사용된다. 예를 들어, 도메인 규칙(아래 참조)에 의해 정의될 수 있는 타임아웃 파라미터 이후에 트랜잭션의 유효성을 확인할 수 없는 경우,상기 트랜잭션이 거부될 수 있다.
또한, 일부 예들에서, 노드는 트랜잭션 용량 약속(capacity promise)(예를 들어, 필요한 계산 및 사이즈), 또는 구조적 사용 약속(예를 들어, 스토리지 샤딩 모델과 정렬됨)과 같은 물리적 또는 시간적 트랜잭션 약속을 만들고 발표한다. 일반적으로, 이것은 제안된 트랜잭션을 제출할 때 제출 노드에 의해 수행될 수 있다. 약속은 프로세스 당 약속일 수 있으며, 프로세스 당 및 당사자 당 보장(per-process and per-counterparty guarantees)을 제공한다. 물리적 또는 시간적 트랜잭션 요구 사항은 트랜잭션 타임아웃을 연장할 수 있다.
무응답 노드들이 있는 경우, 상기 노드들은 이와 같이 마킹될 수 있다. 본 발명은 분쟁 해결 메커니즘을 활용하여 무응답 및 용량 약속을 지키지 않는 것을 디스인센티브화할 수 있다(disincentivize).
유효성 결정(Determining validity)
노드는 트랜잭션의 유효성을 결정하기 위해 다수의 검사들(checks)을 수행할 수 있다. 트랜잭션 유효성 검사들의 일례는 다음과 같다:
a. 충돌(Conflicts)
i. 이러한 검사는 관련 계약(예컨대, DAML 계약)을 이미 소비한 이전 트랜잭션들이 있는지 또는 프로세스의 일부를 구성하는 입력(들)이 있는지 결정하는 것을 포함한다.
b. 승인(Authorization)
i. 이러한 검사는 승인 규칙에 따라 제출 노드가 해당 트랜잭션을 제출할 수 있는지를 결정하는 것을 포함한다.
c. 적합성(Conformance)
i. 이것은 트랜잭션이 적합성 규칙에 따라 잘 구성되었는지 결정하는 것을 포함한다.
d. 시간 제약
i. 이것은 트랜잭션 시간이 시간 제약을 충족하는지를 결정하는 것을 포함한다.
e. 물리적-시간적 제약
i. 이것은 물리적 또는 시간적 트랜잭션 약속들이 원장의 이해관계자들 간에 합의된 물리적-시간적 요건 규칙들의 브랜치 버전 선택을 충족하는지 결정하는 것을 포함한다(예컨대, 어떤 용량 또는 샤딩(sharding) 모델이 이용가능한지).
f. 리소스 체크
i. 이것은 트랜잭션 리소스 요건들이 정확하게 지정되었는지를 체크하는 것을 포함한다. 예를 들어, 노드는 트랜잭션의 일부로서 지정된 트랜잭션 리소스 요건들을 읽을 수 있으며, 노드에서 사용되는 리소스가 지정된 리소스 요건들 내에 있으면 상기 노드가 트랜잭션을 실행할 수 있다. 일례에서, 트랜잭션을 실행하는데 사용되는 리소스가 지정된 리소스 요건들을 초과하는 경우, 노드는 트랜잭션을 실패할 수 있다. 이는 네트워크의 노드가 결과없이 노드가 지정한 리소스 요건들을 벗어난 트랜잭션을 제출하는 것을 방지하는 긍정적인 장점을 가질 수 있다.
충돌(Conflicts)
노드들(110, 120, 122, 210, 220, 222)이 수행할 수 있는 검사들 중 하나는 제안된 트랜잭션(140, 240)이 이전에 제안된 트랜잭션 또는 이전에 확인된 트랜잭션과 충돌하는지 여부를 결정하는 것이다. 이러한 충돌은 시스템의 동시 성질(concurrent nature)에서 본질적인 것이며, 내부의 나쁜 행위(악의적인) 또는 운영상의 문제로 인해 발생할 필요는 없다. 충돌은, 계약(예컨대, DAML 계약) 또는 프로세스의 일부인 입력(들)이 하나 이상의 트랜잭션에 의해 이전에 소비되었는지 여부를 포함할 수 있다.
일부 예들에서, 노드들(110, 120, 122, 210, 220, 222)이 수행할 수 있는 검사 중 하나는 제안된 트랜잭션(140, 240)이 현재 또는 예정된 제안된 트랜잭션과 충돌하는지 또는 현재 검증 중이거나 가까운 장래에 검증될 트랜잭션과 충돌하는지 여부를 결정하는 것이다. 이러한 충돌은 불균일한 물리적 구현예 선택이 이루어질 수 있는(예컨대, 샤딩(sharding)) 시스템의 동시 성질에서 본질적인 것이고, 또는 비순차적(out-of-order) 트랜잭션 로직(예컨대, 배치형(batch-like) 활동과 같은 대규모 트랜잭션들의 경우)과 함께, 또는 또는 일반적으로 모든 캐시 또는 잠금형(lock-like) 원장 지원 로직(예컨대, 최적화 목적 또는 추가 원장 기능을 지원하기 위해 유지됨)에 대하여 본질적인 것이며, 내부의 나쁜 행위(악의적인) 또는 운영상의 문제로 인해 발생할 필요는 없다. 충돌은 계약(예컨대, DAML 계약)이 하나 이상의 트랜잭션에 의해 소비되기 위해 이전에 시작되었는지 여부를 포함할 수 있다.
승인(Authorization)
노드(110, 120, 122, 210, 220, 222)가 수행할 수 있는 또 다른 검사는 제안된 트랜잭션(140, 240)이 잘 승인되었는지를 결정하는 것이다. 이것은 트랜잭션을 제출할 수 있도록 원장의 상태 및 규칙에 의해서 제출 노드가 승인되었는지를 결정하는 것을 포함한다.
적합성 규칙(Conformance rules)
노드(110, 120, 122, 210, 220, 222)가 수행할 수 있는 또 다른 검사는 제안된 트랜잭션(140, 240)이 각 노드의 원장 적합성 규칙과 관련하여 잘 구성되었는지를 결정하는 것이다. 제안된 트랜잭션이 잘 구성되었는지를 결정하는 것은 제안된 트랜잭션이 제안된 트랜잭션에 대한 일련의 적합성 규칙들을 준수하는지를 결정하는 것을 포함할 수 있다. 예를 들어, 이것은, 제안된 트랜잭션이 지정된 포맷이나 특정 원장 워크플로우를 준수하는지 또는 제안된 트랜잭션이 필요한 모든 데이터를 포함하고 있는지를 결정하는 것을 포함할 수 있다. 규칙들 중 하나는 제안된 트랜잭션가 승인되었는지 여부를 포함할 수 있다. 이것은 또한, 예를 들어, 제안된 트랜잭션의 물리적-시간적 요구 사항(아래에서 더 자세히 논의 됨)이 이해관계자들에 의해 이전에 정의되거나 합의된 규칙을 준수하는지를 결정하는 것을 포함한다. 따라서, 요청이 적합성 기준(예컨대, 부적절하게 실행된 원장 워크플로우 선택들 또는 물리적 시간적 요구 사항들) 또는 승인 기준(예컨대, 노드의 원장 워크플로우가 제안된 트랜잭션의 제출자가 트랜잭션을 제출하는 것을 허용하지 않음)을 실패한다면, 상기 요청은 어떤 방식으로든 기형(malformed)(잘못된 형식(ill-formed)이라고도 함)으로 간주될 수 있다. 이것은, 일반적으로 참가자들의 플랫폼 컴포넌트들의 악의성 또는 정확성 문제로 인해서만 발생한다(예컨대, 소프트웨어 버그).
특정한 적합성 사례는 스마트 계약 언어(예컨대, DAML)로 정의된 프로그램 또는 스크립트에 대한 준수일 수 있다.
시간 제약(Time constraints)
노드가 수행할 수 있는 추가 검사는 트랜잭션 시간 및 그것이 시간 제약 내에 있는지 여부를 결정하는 것이다. 예를 들어, 노드는 제안된 트랜잭션의 트랜잭션 시간이, 제안된 트랜잭션에 대한 외부 노드의 타임스탬프로부터 너무 멀리 떨어져 있는지를 판별할 수 있다. 트랜잭션 예상 리소스 소비가 제안된 트랜잭션에 추가되는 경우, 제출자가 트랜잭션을 제출하기 전에 트랜잭션을 처리해야할 수 있으므로, 허용되는 편차 윈도우는 리소스 소비에 따라 달라질 수 있다. 즉, 이것은 명시된 예상 리소스 소비에 대한 팩터로서 도메인 규칙들 내에서 정의될 수 있다.
다르게 말하면, 제안된 트랜잭션의 유효성을 결정하는 것은, 현재 시간이 제안된 트랜잭션의 트랜잭션 시간의 타임아웃 윈도우 내에 있는지 여부를 결정하는 것을 포함할 수 있다(예컨대, 현재 시간이 제안된 트랜잭션의 트랜잭션 시간에 미리 설정된 시간 값을 더한 값보다 큰 경우). 본 일례에서 트랜잭션 시간은 트랜잭션의 비암호화된 서브메시지와 함께 제공될 수 있는 논리적 타임스탬프로 간주될 수 있다. 제안된 트랜잭션을 검증하는 노드는 현재 시간을 제안된 트랜잭션의 트랜잭션 시간과 비교하고 그리고 현재 시간이 타임아웃 윈도우 내에 있는지(예컨대, 현재 시간이 확인 응답 데드라인 이전인 경우)를 결정할 수 있다. 만일 그렇다면, 노드는 제안된 트랜잭션을 프로세싱하도록 진행할 수 있으며 그리고 다른 유효성 검사도 통과한 경우, 그에 따라 확인 응답을 보낼 수 있다. 현재 시간이 타임아웃 윈도우 이후이면, 상기 노드는 트랜잭션에 실패할 수 있다.
물리적-시간적 제약
노드가 수행할 수 있는 추가 검사는 물리적 또는 시간적 트랜잭션 약속들이 트랜잭션 또는 도메인의 이해관계자들간에 합의된 물리적-시간적 요건 규칙들의 브랜치 버전을 충족하는지 여부를 결정하는 것이다. 예를 들어, 노드는 트랜잭션 비용 계산이, 지정된 물리적-시간적 요건 규칙들과 호환되지 않는다고 결정할 수 있다. 예를 들어, 제출자 노드는 트랜잭션의 명시된 리소스 소비와 제안된 논리적 시간을 결부시키기 위해 제출자 노드가 이용하는 규칙들을 표현할 수 있거나, 제출자는 활용된 샤딩 모델이 외부 노드 및 중재자 노드의 여러 인스턴스들의 선택과 어떻게 결부되는지를 표현할 수 있다.
확인 조건(Confirmation condition)
신뢰, 무결성 및 가용성 간의 트레이드-오프를 제공하기 위해, 시스템은 다양한 확인 조건들을 허용할 수 있다. 아래에서 자세히 설명되는 것처럼, 확인 조건은 트랜잭션이 수락 또는 확인되고 원장에 입력될 수 있는지를 결정하기에 충분한 확인 임계값이 될 수 있다.
확인 조건은 제안된 트랜잭션이 수락되거나 확인되고 그리고 원장에 적절하게 입력되기 위한 제한 또는 전제 조건이 될 수 있다. 확인 조건은 수신 노드들로부터 하나 이상의 확인들(예를 들어, 확인들의 임계 분량)을 수신하는 것과 관련될 수 있다.
다양한 유형의 확인 조건이 있을 수 있으며, 사용되는 적절한 확인 조건들은 관련 당사자들, 프로세스 및 잠재적으로 네트워크 조건과 같은 고려 사항에 따라 달라질 수 있다. 예를 들어, 네트워크 상태가 양호하면 전체 확인 조건이 요구될 수도 있지만, 네트워크에 트래픽 정체가 있는 경우에는 네트워크가 개선될 때까지 낙관적인(optimistic) 확인 조건으로 만족할 수도 있다.
전체 확인 조건(full confirmation condition)을 사용하면, 프로세스의 참가자에 해당하는 각 수신 노드로부터 확인을 수신해야하는 요건이 될 수 있다.
서명자 확인 조건(signatory confirmation condition)을 이용하면, 프로세스의 서명자 참가자에 해당하는 각 수신 노드로부터 확인을 수신해야하는 요건이 될 수 있다.
낙관적인 확인 조건을 사용하면 최근의 확인 스트림이 지정된 기준을 충족해야하는 요건이 될 수 있다. 예를 들어, 지정된 분량의 확인들이, 할당된 기간 내에 관련 노드들에 의해 수신된다.
"VIP" 확인 조건을 사용하면, 확인 기준은 수신 노드들의 속성에 따라 달라질 수 있다. 예를 들어, VIP 확인 조건은 프로세스의 참가자에 대응하는 수신 노드들의 특정 서브세트(예를 들어, VIP 노드로 지정된)로부터 확인이 수신됨을 지시할 수 있다. 즉, 확인을 제공해야만 하는 일부 노드들과 반드시 확인을 제공할 필요가 없는 다른 노드들이 있을 수 있으며, 이는 확인 조건에 반영될 수 있다.
"VIP" 확인은 암호화 증명자(cryptographic prover)(예컨대, zkSNARK, zkSTARK) 또는 신뢰할 수 있는 실행 환경(예컨대, Intel SGX)의 증명에 의해 구현될 수 있다. 다르게 말하면, 일례에서, 네트워크의 노드는 증명자(attestor) 역할을 수행할 수 있으며(예컨대, VIP 확인 정책이 사용되는 경우), 증명자는 제안된 트랜잭션이 본 명세서에 서술된 바와 같은(예를 들어, 단락 [134]에서 설명됨) 모든 유효성 검사를 충족한다는 것을 제안된 트랜잭션의 당사자들인 다른 노드들에게 증명할 수 있다. 예를 들어, 증명자 노드는 제안된 트랜잭션이 모든 유효성 검사를 충족하고 그리고 확인된 트랜잭션으로서 수락될 수 있음을 암호화 방식으로 증명하는 암호화 증거(proof)(예컨대, zkSNARK, zkSTARK)을 제안된 트랜잭션의 당사자들에게 제공할 수 있다. 전술한 바와 같이, 암호화 증거는 제안된 트랜잭션의 모든 당사자들에게 제공될 수 있는 제로-지식형 증거(zero-knowledge type proof)가 될 수 있는데, 따라서 모든 당사자들은, 제안된 트랜잭션의 유효성에 대해 신뢰를 가질 수 있지만, 관련 당사자가 일반적으로는 액세스할 수 없는 제안된 트랜잭션에 대한 사적인 세부내용들(private details)에는 액세스할 수 없다. 이와 유사하게, Intel SGX와 같은 신뢰할 수 있는 실행 환경은 암호화 증명자와 함께 또는 대신하여 사용될 수 있다.
전형적으로, 악의(즉, 의도적인 나쁜 행동) 없이 행동하도록 노드들이 신뢰될 수 있는 도메인에서, 낙관적인 확인 조건은 트랜잭션 수락을 보장하기에 충분할 수 있다. 즉, 효율성을 위해, 노드들이 악의없이 행동하며 그리고 수신 노드들 중 어느 것도 악의적이지 않다고 가정할 수 있다. 하지만, 악의가 여전히 검출될 수 있으며 입증될 수 있다. 일부 경우에서, 악의적인 거동의 여파(ramifications)는 시스템 외부에서 처리될 수 있다.
일부 예에서, 확인 조건(들)은 또한, 제안된 트랜잭션에 대한 응답(이는 유효성 요청에 대한 확인으로 간주될 수 있음)이 제출 노드에 의해 적시에 수신되어야함(및/또는 수신 노드에 의해 전송됨)을 요구할 수도 있다. 이것은 아래의 추가 일례들에서 논의되는 타임아웃 및 데드라인들을 갖는 것을 포함한다.
도메인 규칙(Domain rules)
도메인 규칙은 도메인의 모든 참가자들이 동의한 규칙들의 세트이다. 도메인 규칙은 분쟁 해결 프로세스 또는 처벌과 같은 결과를 관장할 수 있다. 예를 들어, 노드(120, 122, 220, 222)가 지정된 시간 프레임 내에 확인을 보내지 않는 경우, 해당 노드는 일시적으로 네트워크에서 제외되거나 다른 처벌을 사용하여 처벌을 받을 수 있다. 경우에 따라 네트워크에 대한 완전한 액세스 권한을 다시 부여받기 전에 올바른 거동이 확립될 필요가 있을 수도 있다. 예를 들어, 노드(120, 122, 220, 222)는 네트워크에서 일시적으로 제외되어 트랜잭션을 제출할 수 없을 있으며 이후, 처벌받은 노드에 의해 일련의 정시(on-time) 확인들이 수신될 때까지 "확인 전용" 모드에 있을 수 있다.
트랜잭션의 거부(Rejecting a transaction)
제안된 트랜잭션(140, 240)은 여러 가지 이유로 거부될 수 있다. 거부의 한 가지 이유는 제안된 트랜잭션들(140, 240)이 다수의 도메인들을 가지고 있음을 표방함(signifying)이 없이, 다수의 도메인들을 가지고 있다는 것이며, 이는 제안된 트랜잭션들(140, 240)이 멀티-도메인 트랜잭션임을 표현함이 없이, 제안된 트랜잭션들(140, 240)이 다른 도메인들에 있는 프로세스들(102, 202) 또는 계약들(예컨대, DAML 계약)을 사용하려고 시도했음을 의미한다. 일부 경우에는 이것이 허용될 수도 있지만, 일반적인 규칙은 제안된 트랜잭션(140, 240)이 단일 도메인을 가져야한다는 것이다.
일례에서, 도메인 규칙은 확인 조건을 설정한다. 이 경우 도메인 규칙에 따라 트랜잭션이 최종 승인된 것으로 선언하기 위해 타임아웃 윈도우 내에 불충분한 확인들이 수신되는 것도 가능하다.
제안된 트랜잭션(140, 240)을 거부하는 또 다른 이유는 제안된 트랜잭션(140, 240)이 하나 이상의 다른 트랜잭션과 일치하지 않기 때문일 수 있다. 즉, 이것은 이전에 수락/확인된 트랜잭션과 충돌한다.
일부 예들에서, 트랜잭션 프로토콜은 트랜잭션이 승인되었는지 그리고 반대로 트랜잭션이 거부되었는지를 모든 이해관계자들에게 대해 알려줄 것을 요구한다. 일부 예에서, 프로토콜은 트랜잭션의 선언된 이해관계자가 결정 이유를 알도록 요구한다.
임의의 노드는 분쟁을 일으킬 수 있으며, 이는 위반 노드를 오프라인으로 마킹하게 할 수 있다. 하지만, 무효한 분쟁(invalid dispute)을 야기하는 것도 또한 노드가 처벌을 받게할 수 있다. 따라서 분쟁이 발생하면, 제안된 트랜잭션도 거부될 수 있다. 이는 수신 노드가 제안된 트랜잭션이 잘 형성된(well-formed) 것이 아니다라고 판단하거나 또는 서로 다른 노드들이 동일한 트랜잭션 부분의 유효성에 대해 충돌하는 응답을 제공하는 경우 발생할 수 있다. 예를 들어, 이들 두 가지 모두는, 악의(malice) 또는 소프트웨어 버그로 인해 발생할 수 있다. 즉, 대부분의 경우, 노드들이 제대로 작동할 것으로 예상할 수 있다.
확인 하트비트(Confirmation heartbeats)
트랜잭션들을 구성하는 액티브 계약들(102, 202)(또는 프로세스들)을 공유하는 각각의 참가자 쌍은 때때로 해당 계약에 대해 서명된 진술(signed statements)을 교환하며, 이는 본 명세서에서 확인 하트비트라고 지칭되며, 따라서 참가자들은 양자간(bilaterally)(또는 다자간: multilaterally)으로 계약/트랜잭션의 상태를 확인할 수 있다. 진술들(statements)은, "타임스탬프 ts에서, 이것들은 모두 최종적으로 확인된 액티브 상호 계약들이다" 라는 형태를 갖는다. 이들은 분쟁 해결에서 사용될 수 있다. 예를 들어, 참가자 A는, 타임스탬프 ts 에서 하트비트에서 말하는 c에 포함된 B의 최신 하트비트를 보여주고 그리고 ts 와 t 사이에 발생한 모든 트랜잭션들을 공개함으로써, 참가자 B와 맺은 계약 c가 소정의 시간 t에서 여전히 액티브함을 심판에게 증명할 수 있다. 메시징 계층의 액션 설명들 및 전달 증거들을 신중하게 설계하면, 심판은 공개된 트랜잭션의 계약 ID를 제외하고는 아무것도 배울 필요가 없다.
참가자의 프라이버시를 보호하기 위해, 일부 일례들에서 진술들은 액티브 계약들에 대한 머클 트리(Merkle trees)의 뿌리(roots)만을 포함할 수 있다. 참가자들이 다른 이들의 진술들 각각을 체크함을 보장하기 위하여, 트리의 구성은 결정론적(deterministic)이어야 하며, 두 참가자들에 의해 재현될 수 있어야한다.
프라이버시
개시된 시스템은 다음의 프라이버시 특성 중 하나 이상을 포함할 수 있다.
요구 사항(관련되지 않은 참가자에게 비공개: non-disclosure to unrelated participants). 트랜잭션 프로토콜은 제출된 트랜잭션(이해관계자 및 확인자 포함) 내의 액션을 액션의 이해관계자 참가자들에게만 공개할 수 있다. 이러한 맥락에서, 액션은 분산 원장에 기록된 이해관계자 참가자들과 관련된 권리의 생성 또는 행사이며, 이는 해당 액션에 대한 이해관계자 참가자들에 의해 인식된다(이는 본질적으로 다음을 의미한다: (i) 해당 액션에 대한 트랜잭션 프로토콜에 의해 승인되고, (ii) 기저 시스템 모델을 준수함). 이러한 프라이버시 측면은 도 3에 예시된 트랜잭션을 반영하는 도 l4a 및 도 l4b에 예시된 사례를 참조하여 설명될 것이다.
도 14a를 참조하면, A를 호스팅하는 참가자 노드는 A가 루트 액션의 이해관계자이기 때문에 전체 트랜잭션을 볼 수 있다(제 1 박스 1410). 같은 이유로 P를 호스팅하는 참가자 노드도 전체 트랜잭션을 볼 수 있다(제 1 박스 1410). P를 호스팅하는 참가자 노드는 비록 엄격하게는 이해관계자가 아니지만 제 2 액션을 볼 수 있다(제 2 박스 1420). 어쨌든 제 2 액션은 제 1 액션인 "Exe P(PaintOffer AP)"수락"의 하위 액션이기 때문에, 이를 볼 수 있는 것이다.
은행을 호스팅하는 참가자 노드는 제 2 액션만 본다(제 2 박스 1420). 요구 사항은 트랜잭션 프로토콜이 제 1 액션(1410)의 구조를 은행에 공개하도록 허용한다는 점에 유의한다. 이것은 도 14b의 박스 1410에 의해 예시된다.
1410'에서 물음표 "???"는 은행으로 전달된 메시지는 액션의 가려진 해시(blinded hash)를 포함하고 있음을 나타내지만, 은행은 해시로부터 액션을 도출할 수 없다.
요구 사항(제출자에 대한 비공개: non-disclosure of submitters). 일부 일례들에서, 트랜잭션 프로토콜은 트랜잭션의 최상위 레벨 액션들의 이해관계자 참가자에게만 트랜잭션의 제출 노드 또는 제출자를 공개할 수 있다.
페인트 펜스 트랜잭션에서 A와 P의 참가자들은 이들이 전체 액션을 볼 수 있으므로 제출 노드를 알 수 있다. 하지만, 은행의 참가자 노드는 제출 노드나 제출자의 신원을 알 수 없다(또는 일부 경우에는 알아서는 안된다).
요구 사항(메시지 브로커 및 중재자에 대한 비공개). 트랜잭션 프로토콜은 제출된 트랜잭션의 내용(즉, 암호화된 서브메시지(144)의 내용)을 외부 노드(230) 또는 중재자(280)에 공개해서는 안된다.
제한(Limitation)(이해관계자 및 확인자에 대한 공개). 트랜잭션 프로토콜은 제출된 트랜잭션의 이해관계자 및 확인자를 외부 노드(230) 또는 중재자(280)에 공개할 수 있다. 이 정보는 비암호화된 서브메시지(142)로부터 유도될 수 있다.
제한(암호화된 트랜잭션에 대한 공개). 트랜잭션 프로토콜은 제출된 트랜잭션의 암호화된 버전(예를 들어, 외부 노드에 의해 해독될 수 없는 암호화된 서브메시지 144)을 외부 노드에 공개할 수 있다.
제한(부정한 참가자에 의한 공개). 트랜잭션 프로토콜은 부정직한 참가자가 트랜잭션을 제 3 자에게 공개하는 것을 방지하지 않는다.
제한(감사자에 대한 공개). 트랜잭션 프로토콜은 참가자가 감사자에게 트랜잭션을 공개하는 것을 방지하지 않는다.
트랜잭션 뷰(Transaction views)
시스템의 프라이버시는 아래에서 설명하는 다양한 노드들의 관점에서 트랜잭션 뷰에 의해 더 설명될 수 있다. 트랜잭션 프로토콜은 시스템이 트랜잭션의 모든 액션에 대해 개별적으로 확인 응답을 얻어야한다고 제안할 수 있다. 더 복잡한 일례에서, 이것은 과도한 양의 메시지가 전송되게 할 수 있다. 따라서, 트랜잭션 뷰의 개념을 사용하여 이러한 부담을 감소시킬 수 있다. 이것은 각 노드가 봐야될 필요가 있는 것만을 보고 그리고 데이터 구조 크기를 최소화할 수 있도록, 다수-이해관계자 트랜잭션이 최소한의 개별 뷰들의 세트로 분해되는 방법이다.
트랜잭션 뷰 - 트랜잭션 tx가 주어지면, 트랜잭션 tx의 뷰는 다음 속성들 중 하나를 충족하는 트랜잭션의 서브액션이다.
1. 서브액션은 트랜잭션에 부모 액션(parent action)을 갖지 않는다.
2. tx에서 서브액션의 부모 액션은 서브액션과는 상이한 이해관계자들 또는 상이한 확인 당사자들을 갖는다.
뷰의 코어는 뷰로부터 모든 서브뷰들(뷰 자체는 제외)을 제거함으로써 발생한다.
이것은 도 l6a 및 l6b에 가장 잘 설명되어 있다. 전체 확인 정책이 시행중인 것으로 가정하자: 따라서, 모든 이해관계자는 또는 확인 당사자이다. 도 16a에 도시된 바와 같이, PaintOffer의 수락 및 PaintAgreement의 생성은 동일한 제 1 뷰(1610)에 속하는데, 왜냐하면 이러한 2개의 액션들은 동일한 이해관계자들(따라서 동일한 확인 당사자들도 또한)을 갖기 때문이다. IOU 전송은 은행이 제 1 뷰(1610)의 이해관계자가 아니기 때문에, 별도의 제 2 뷰(1620)에 속한다. P의 IOU의 생성은 다시 별도의 제 3 뷰(1630)에 속하는데, 왜냐하면 페인터(painter) P는 제 2 뷰(1620)의 이해관계자가 아니기 때문이다.
도 16b는 제 1 뷰(1610)의 코어를 예시한다. 따라서 뷰의 코어는 관련없는 정보(extraneous information)를 해당 뷰로부터 제거하며, 이는 메시지 사이즈를 줄일 수 있을 뿐만 아니라 이러한 정보를 저장하기 위한 데이터 요건들(예컨대, 해당 서브메시지들의 부분들과 같은)을 감소시킬 수 있다. 이것은 트랜잭션 뷰들과 관련된 이러한 정보를 분산 원장에 저장하는 것을 포함할 수 있다. 다음이 이해될 것인바, 제 2 뷰(1620) 및 제 3 뷰(1630)는 서로 다른 이해관계자들, 확인 당사자들(및 각각의 노드들)과 관련될 수 있는 각각의 코어를 갖는다. 뷰를 볼 자격이 있는 사람들만 각각의 정보를 볼 수 있기 때문에, 이것은 서브트랜스액션 프라이버시에 도움을 줄 수 있다.
데이터 구조는 전술한 트랜잭션 및 뷰를 표현하도록 구축될 수 있음을 이해해야한다. 여기에는 트랜잭션, 트랜잭션의 모든 뷰에 대한 이해관계자들, 원장 유효 시간 및 확인 정책이 포함될 수 있는 트랜잭션을 나타내는 블라인드가능한 머클 트리(blindable Merkle tree)인 트랜잭션 트리가 포함될 수 있다. 콘텐츠가 동일하더라도, 2개의 서로 다른 서브트리들은 서로 다른 머클 루트 해시(Merkle root hashes)를 가져야 한다는 요구 사항이 있을 수 있다.
트랜잭션 트리
도 17은 페인트 펜스 트랜잭션(paint fence transaction)(1701)을 나타내는 후보 데이터 구조(1700)를 도시한다. 이것은 다음 그룹을 포함할 수 있다:
(1) 1710 및 1711에 의해 표시되는 PaintOffer의 수락
(2) 1720 및 1721에 의해 표시되는 IOU의 양도(transfer)
(3) 1730에 의해 표시되는 양도의 일부로서 새로운 IOU의 생성
본 문맥에서 블라인드가능한 머클 트리(blindable Merkle tree)라는 용어는 다음을 의미하거나 다음과 같은 특성을 가지고 있다.
● 모든 서브트리는 해시를 갖는다.
● 서브트리가 해시로 대체되면 전체 트리의 해시는 변경되지 않는다.
● 공격자가 해시로부터 서브트리의 콘텐츠를 도출하는 것은 사실상 불가능한다. 이를 위해 해시는 트랜잭션 트리에 포함된 블라인딩 팩터들에 의존해야 한다.
서브트리의 해시는 서브트리의 고유 식별자로 사용될 것이기 때문에, 서브트리 해시의 고유성이 요구된다. 또한, 하나의 서브트리를 볼 수 있는 참가자가 다른 서브트리에 동일한 콘텐츠가 있는지 여부를 추론할 수 없도록 해야한다. 서브트리 해시의 고유성은 고유한 블라인딩 팩터를 적용하여 얻을 수 있다.
정의(트랜잭션들 및 뷰들의 해시들). 트랜잭션 트리의 트랜잭션 해시는 트리의 머클 루트 해시(Merkle root hash)이다. 트랜잭션 뷰의 트랜잭션 뷰 해시는 트랜잭션 뷰를 나타내는 트랜잭션 트리의 서브트리의 머클 루트 해시이다다.
도 18은 페인터(painter)가 소유한 IOU를 생성하는 페인트 펜스 트랜잭션의 서브뷰(1730)의 후보 표현(1800)을 도시한다. PaintOffer(1710, 1711)의 수락 및 IOU (1720, 1721)의 양도와 같은 다른 뷰들에 대한 정보는 보여지지 않는다. 이것은 서브-트랜잭션 프라이버시를 제공하는데 이용될 수 있다.
이해관계자 트리. 트랜잭션의 이해관계자 트리는 다음과 같은 속성을 가진 트랜잭션 트리의 부분적으로 블라인딩된 버전이다.
(1) 트랜잭션 뷰들의 콘텐츠가 블라인드된다.
(2) 원장 유효 시간이 블라인드된다.
(3) 확인 정책은 블라인드되지 않는다(unblinded).
(4) 선택된 트랜잭션 뷰들의 해시들은 블라인드되지 않는다.
(5) 트랜잭션 뷰의 해시가 블라인드되지 않은 경우, 뷰의 이해관계자는 블라인드되지 않는다.
트랜잭션의 전체 이해관계자 트리에서, 트랜잭션의 모든 뷰들의 해시들은 블라인드되지 않는다. 도 19는 페인트 펜스 트랜잭션의 전체 이해관계자 트리의 후보 표현(1900)이다. 이해관계자의 정보(1913, 1923, 1933)은 볼 수 있지만, 다른 정보(1950)는 블라인드된다.
당사자들 p1, ..., pn 에 대해 블라인드되지 않은 이해관계자 트리에서, p1, ..., pn 중 하나가 이해관계자인 정확히 이들 뷰들의 해시들은 블라인드되지 않는다. 도 20은 페인트 펜스 트랜잭션의 은행에 대해 블라인드되지 않은 이해관계자 트리의 후보 표현(2000)을 예시한다. 도 19와 달리 이해관계자(1913)는 블라인드된다(2013)(참가자 A 및 P 사이의 페인트 계약(제안자/수락자)에서 은행은 이해관계자가 아니므로). 이해관계자 정보(2023, 2033)는 이해관계자이므로 은행에 보여질 수 있다.
전술한 일례는 이해관계자가 정보를 볼 수 있도록 허용하면서(상기 정보에 대해 이들이 이해관계자이거나, 또는 그러한 정보를 볼 자격이 있음), 상이한 레벨들의 트랜잭션에서 프라이버시를 유지하기 위한 메커니즘을 설명한다. 다르게 말하면, 앞의 일례들은 설명된 프라이버시 모델에 따라, 관련 이해관계자들에게 블라인드된 동일한 트랜잭션의 서로 다른 부분과 함께 트랜잭션이 다수의 이해관계자들에게 어떻게 전송되는지를 예시한다. 이러한 방식으로 다수의 이해관계자들은 동일한 트랜잭션을 수신할 수 있지만, 해당 트랜잭션에 대해 서로 다른 프라이버시 뷰를 가질 수 있다. 이러한 구조는 네트워크의 다양한 노드들 사이에서 프라이버시를 유지하면서도, 공유 원장에 트랜잭션을 제출하고 기록할 수 있게 한다.
가상 공유 원장(Vitual shared ledger)
일부 예에서, 트랜잭션 프로토콜은 암시적으로 가상 공유 원장을 생성한다. 가상 공유 원장의 속성들은 트랜잭션 프로토콜에 의해 시행된다(enforce). 가상 공유 원장은 가상의 개념이다. 일반적으로, 전체 가상 공유 원장을 저장하는 단일 참가자는 존재하지 않는다. 하지만, 모든 참가자가 트랜잭션 프로토콜과의 상호 작용으로 인한 메시지들을 공개하면, 가상 공유 원장은 이러한 메시지들로부터 도출될 수 있다.
먼저, 가상 공유 원장에 대한 일련의 액션을 정의한다. 이상적으로는, 프로토콜이 기본 트랜잭션(underlying transaction)을 승인한 경우에만 액션이 가상 공유 원장에 속한다. 이러한 속성은 트랜잭션의 모든 이해관계자들이 정직한 경우 실제로 유지된다.
그러나 일부 이해관계자 참가자들이 부정직한 경우, 이들이 액션을 승인할 수도 있다(검증 알고리즘에 따라 그것이 거부되어야함에도 불구하고). 특히, 부정직한 참가자들은 트랜잭션 프로토콜이 기본 DAML 모델(또는 대안적인 시스템 모델)을 따르지 않는 트랜잭션을 승인하도록 만들 수 있다. 이러한 이유로 액션이 프로토콜이 승인한 트랜잭션의 일부인 경우, 상기 액션은 가상 공유 원장의 일부가 되기 위해 추가적인 속성을 충족해야만 한다.
가상 공유 원장 상의 액션들: 다음의 속성이 유지되는 경우 액션은 가상 공유 원장의 일부이다.
i. 액션은 트랜잭션 프로토콜에 의해 승인된 트랜잭션의 일부이다.
ii. 액션은 기본 시스템 모델(예컨대, DAML 시스템을 위한 DAML 모델)을 따른다.
iii. 액션의 모든 서브액션 A(액션 그 자체를 포함)에 대해, 선언된 A의 이해관계자들은 시스템 의미론(semantics)(예컨대, DAML 의미론)에 따라 정확히 A의 이해관계자들이 된다.
이러한 예시적인 정의가 페인트 펜스 트랜잭션의 일례에서 설명된다. 기본 시스템 모델(이 경우 DAML 모델)은 예제에서 사용된 모든 액션들을 포함하고 있다고 가정되며, 따라서 트랜잭션은 기본 시스템 모델을 따른다(conform). 또한, 전체 확인 정책과 함께 트랜잭션이 제출되었다고 가정하자. 먼저, 예컨대, DAML 의미론에 따라 이해관계자들이 올바르게 선언된 경우를 고려하자. 트랜잭션 전체가 승인된 경우, 트랜잭션의 모든 액션은 가상 공유 원장의 일부이다. 그렇지 않은 경우, 즉 트랜잭션이 거부된 경우, 트랜잭션의 어떤 액션도 가상 공유 원장의 일부가 아니다.
도 15a는 P 대신에 A가 페인트 펜스 트랜잭션을 제출하였고 그리고 A가 P를 제 1 액션(1510)의 이해관계자로 선언하지 않은 경우를 예시한다. 또한 프로토콜이 트랜잭션을 승인했다고 가정한다.
P가 이해관계자로 선언되지 않았기 때문에, 제 1 액션(1510)은 가상 공유 원장의 일부가 아니다. 이것은 타당한데, 왜냐하면 P가 "수락" 선택의 제어자이지만, 그 액션을 보지도 못했기 때문이다.
PaintAgreement(1520)의 생성은 가상 공유 원장의 일부인데, 왜냐하면 A와 P가 모두 이해관계자로 올바르게 선언되었기 때문이다. A와 P 모두가 그들의 참가자 노드를 통해 액션을 승인했으므로, 상기 액션을 가상 공유 원장에 추가하는 것이 타당하다.
같은 이유로, A에서 P 로의 IOU 양도(액션 1530 및 1540)은 가상 공유 원장의 일부이다. 가상 공유 원장에서 IOU 양도를 제외하는 것은 실현가능하지 않을 것인데, 왜냐하면 은행에 이에 대한 정보를 제공해야만 하기 때문이다.
도 15b는 A가 PaintAgreement(1520')를 생성하는 액션의 이해관계자로 선언되지 않은 경우를 도시한다. 다시, 프로토콜이 트랜잭션을 승인했다고 가정한다.
A가 이해관계자로 선언되지 않았기 때문에 PaintAgreement(1520)의 생성은 가상 공유 원장의 일부가 아니다. 이는 타당한데, 왜냐하면 A에게 알리지 않고 상기 액션이 PaintAgreement를 생성했기 때문이다. 또한, PaintOffer(1510)의 수락도 가상 공유 원장의 일부가 아니다. 만일, 이것이 가상 공유 원장의 일부였다면, 가상 공유 원장은 DAML 모델(또는 대안적인 시스템 모델)을 따르지 않는 것인데, 왜냐하면 DAML 모델은 유효한 PaintAgreement(1520)를 생성함이 없이 PaintOffer를 수락하는 것을 허용하지 않기 때문이다.
앞서와 마찬가지로, IOU 양도(1530 및 1540)는 가상 공유 원장의 일부이다. A와 은행 모두 트랜잭션을 승인했기 때문에 이를 반대할 이유가 없다.
어떤 조건 하에서 액션이 가상 공유 원장의 일부인 것을 설명했으므로, 이제 트랜잭션이 "언제" 가상 공유 원장의 일부인지에 대한 질문이 해결될 것이다.
가상 공유 원장 상의 트랜잭션. 트랜잭션 tx는 다음 속성 중 하나가 유지되는 경우 가상 공유 원장의 일부이다:
1. 트랜잭션 tx는 트랜잭션 프로토콜을 통해 제출되었으며 tx의 모든 액션은 가상 공유 원장의 일부이다.
2. 트랜잭션 tx는 다른 트랜잭션 ptx의 일부로서 트랜잭션 프로토콜을 통해 제출되었다. 트랜잭션 tx는 가상 공유 원장의 일부가 아닌 액션들을 ptx로부터 제거함으로써 발생한다.
마지막으로, 가상 공유 원장의 예는 다음과 같이 정의된다.
가상 공유 원장 일부 예에서, 가상 공유 원장은 다음의 속성을 포함할 수 있다.
i. 가상 공유 원장은 트랜잭션들의 시퀀스이다. 여기에는 위에서 설명한 것처럼 "가상 공유 원장의 일부"인 트랜잭션들이 포함된다.
ii. 가상 공유 원장의 트랜잭션들 순서는 제출 순서에 해당한다. 대안적으로는, 또는 프로토콜에 따른 특정 순서(예컨대, "논리적 재정렬"에서 논의된 순서)에 해당한다.
iii. 가상 공유 원장에 기록된 모든 액션들은 확인 당사자들과 확인자의 서명들(예컨대, 수신 노드의 서명들)로 장식된다(decorated).
iv. 가상 공유 원장의 트랜잭션이 제출된 트랜잭션과 일치하면, 트랜잭션은 제출자와 제출 노드의 서명으로 장식된다.
앞서 언급한 바와 같이, 일반적으로 단일 참가자는 전체 가상 공유 원장을 저장하지 않는다. 그러나 모든 참가자가 트랜잭션 프로토콜에 따라 서로 상호 작용하여 발생한 메시지를 공개하면 이러한 메시지를 결합하여 가상 공유 원장이 파생될 수 있다. 하지만, 모든 참가자들 트랜잭션 프로토콜에 따라 서로 상호작용한 메시지들을 공개하면, 이러한 메시지들을 결합하여 가상 공유 원장이 도출될 수 있다.
예시적인 방법
도 4는 시스템(200)에 의해 수행되는 예시적인 방법을 도시한다. 이 방법은 시스템(100)을 사용하여 수행될 수도 있음을 이해해야한다.
본 일례에서, 외부 노드(230)는 다수의 참가자들을 포함하는 프로세스를 구성하는 다수의 트랜잭션들에 대응하는 다수의 메시지들의 순서를 결정할 수 있다(410). 결정 단계(410)는 아래에 설명된 단계들 중 일부 단계들에 앞서서, 사이에서 또는 이후에 수행될 수 있다는 것을 이해해야한다.
프로세스의 참가자와 연관된 제출 노드(210)는 제안된 트랜잭션(예컨대, 도 2a의 240)을 제출할 수 있으며(420), 제안된 트랜잭션을 제출하는 것은, 부분적으로 암호화된 메시지(예컨대, 암호로 보호된 메시지)를 프로세스의 참가자와 연관된 하나 이상의 수신 노드(예컨대, 수신 노드 220)로 전송하는 것을 포함할 수 있으며, 부분적으로 암호화된 메시지는 외부 노드(230)가 읽을 수 있는 비암호화된 서브메시지(242) 및 암호화된 서브메시지(244)(예컨대, 암호로 보호된 서브메시지로서)를 적어도 포함하여, 적어도 외부 노드(230)로부터 프라이버시를 보존할 수 있다.
수신 노드(220)는 부분적으로 암호화된 메시지의 유효성을 결정할 수 있다(430). 이것은 제안된 트랜잭션(240)에 대해 유효성 검사를 수행한 다음 유효성 검사가 통과하면 확인을 기대하거나 요구할 것이라고 수신 노드(220)가 결정한 다른 노드 및 제출 노드에 확인을 전송하는 것을 포함할 수 있다. 본 일례에서, 수신 노드(220)는 중재자 노드(280)를 통해 확인을 전송할 수 있다. 다른 예에서, 수신 노드(220)는 확인을 피어-투-피어로 전송할 수 있다.
제출 노드(210)는 수신 노드(220)로부터 부분적으로 암호화된 메시지의 유효성에 대한 확인을 수신할 수 있다(440).
제출 노드(210)는 확인 조건을 만족하는 하나 이상의 확인들을 하나 이상의 수신 노드로부터 수신하는 것에 기초하여, 제안된 트랜잭션을 수락되거나 확인된 트랜잭션으로서 마무리할 수 있다(450). 위에서 지정된 확인 조건은 예를 들어, 전체 확인 조건, VIP 확인 조건 또는 시스템의 파라미터로 설정된 기타 확인 조건일 수 있다.
이 경우 제출 노드(210)인 노드는 외부 노드(230)에 의해 결정된 순서에 따라 수락된/확인된 트랜잭션을 원장에 기록할 수 있다(460). 원장은 분산된 "가상"원장을 포함하여 여기에 설명된 모든 원장일 수 있다. 본 일례에서, 트랜잭션의 일부인 수신 노드(220)(또는 노드 220, 222)는, 일단 그러한 노드(들)가 확인 조건을 만족시키기에 충분한 확인들(250, 252)을 수신하면, 수락된/확인된 트랜잭션을 그 자신의 원장의 사본에 기록한다. 어떤 의미에서, 트랜잭션에 대한 노드들(210, 220)은, 노드들(210, 222) 사이에서 발생하는 임의 개수의 트랜잭션들에 특정한 노드들 사이에서 "가상"공유 원장을 형성할 수 있다.
각 노드(110, 120, 122, 130, 210, 220, 222, 230, 330, 340, 342)는 설명된 방법의 대응하는 부분을 수행할 수 있다는 것을 이해해야한다.
예시적인 노드
도 5는 본 명세서에 개시된 노드(110, 120, 122, 130, 210, 220, 222, 230, 330, 340, 342) 중 임의의 것일 수 있는 예시적인 노드를 도시한다. 도 5에 도시된 노드(210)는 프로세서(502), 메모리(503), 네트워크 인터페이스 디바이스(508, 510), 원장(260)과 인터페이스하는 분산 원장 인터페이스 디바이스(509) 및 사용자 인터페이스(512)를 포함한다. 메모리(503)는 명령들(504) 및 데이터(506)를 저장할 수 있으며, 프로세서(502)는 메모리(503)로부터의 명령들을 수행하여 도 3에 설명된 바와 같은 프로세스를 구현할 수 있다.
프로세서(502)는 참가자(516)와 같은 사용자로부터 사용자 인터페이스(512)를 통해 입력을 수신할 수 있다. 프로세서(502)는 분산 원장(152)에 기록된 현재 실행 상태에 기초하여 명령을 결정할 수 있다. 명령은 실행하기 위한 함수일 수 있다. 프로세서(502)는 임의의 출력(514) 또는 결과를 참가자(516)에 표시하기 위해 프로그램 코드(504)에 저장된 명령을 실행할 수 있다.
리소스 모델
제안된 트랜잭션(140, 240)은 미리 언급된 공유된 물리적-시간적 제약(프로세싱 시간, 메모리, 네트워크, 스토리지)의 선택을 표현하는 리소스 유닛의 관점에서 하나 이상의 리소스 요구 사항을 포함할 수 있으며, 예에서 요청 메시지 확인가능한 서브블록 당 하나씩 각 수신자가 트랜잭션을 검증 및 확인한다.
모든 노드(110, 120, 122, 130, 210, 220, 222, 230, 330, 340, 342)는 특정 기간 동안 지정된 양의 리소스를 제공할 것을 약속할 수 있다. 이러한 용량 약속은 프로세스 또는 노드 그룹으로 제한될 수 있다. 모든 리소스 요구 사항은 적용되는 가장 구체적인 용량 약속에 따라 부과된다. 노드는 리소스 요구 사항이 미사용 용량 요구 사항을 초과하는 트랜잭션을 즉시 거부할 수 있다. 노드는 리소스 용량에 대한 할당량이 부족함을 나타내도록 응답할 수 있다. 심판 노드와 같은 용량 모니터는 리소스 용량에 대한 할당량 초과에 기초하여 모든 거부들을 확인할 수 있다. 따라서 용량 모니터는 관련 노드들이 약속한 용량을 체크할 수 있다.
일부 예시적인 시스템에서, 노드들의 용량 약속들은 이전 트랜잭션 또는 제안된 트랜잭션(들) 및 관련 노드들과 그들의 참가자들의 수락들에 의해서, 생성 및 가능하면 업데이트되었다. 이러한 용량 예약(reservation) 트랜잭션(들)은 본 개시에서 설명된 트랜잭션을 사용하여 구현될 수 있다. 일부 예시적인 시스템에서, 용량 약속들은 특정 트랜잭션 유형들의 서브세트를 위해 예약된다. 이것은 일부 예시적인 시스템이 특히 용량 생성 및 업데이트 트랜잭션(들)을 프로세싱할 용량을 약속하는 노드들을 갖도록할 수 있다.
리소스 요구 사항은 트랜잭션에서 선언될 수 있지만, 트랜잭션 자체의 콘텐츠는 선언할 수 없다. 따라서 제출 노드는 이론적으로는 트랜잭션을 프로세싱하고 유효성을 검증하는데 사용되는 실제 리소스보다 더 낮은 리소스 요구 사항을 선언할 수 있다. 수신 노드는 이러한 불일치를 검출할 수 있으며 그리고 제출 노드가 리소스 소비를 속이고 있다는 근거로 분쟁을 일으킬 수 있다.
리소스 수당(Resource Allowances)
리소스 모델과 관련하여, 경우에 따라, 제출 수수료(submission fee) 또는 리소스 수당은 제출 노드(110, 210)(제출 수수료)에 의해서 지불될 필요가 있을 수 있으며 그리고 트랜잭션에서 계약(예컨대, DAML 계약)에 대한 선택권을 행사하는 수신 노드들(120, 122, 220, 222)(검증 수수료)에 적용될 수도 있다. 수수료는 도메인을 운영하는 운영자 및/또는 트랜잭션의 이해관계자에게 지불될 수 있다. 수수료는 트랜잭션, 프로세스 및 도메인에서 사용하는데 필요한 리소스의 분량에 따라 결정되는 트랜잭션 비용의 함수로서 결정될 수 있다. 이를 쉽게하기 위해 각 노드는 수수료가 공제되고 수수료가 신용거래되는 수수료 계정을 가질 수 있다.
어카운팅 컴포넌트는 각 참가자에 대한 계정을 유지할 수 있다. 트랜잭션이 메시지 브로커(예를 들어, 외부 노드 230)에 의해 타임스탬프될 때, 제출 수수료는 제출자의 계정으로 청구될 수 있다. 트랜잭션이 완료되면(become final), 검증 수수료가 양도될 수 있다. 참가자는 전용 워크플로우를 사용하여 수수료 계정을 충전할 수 있다.
일부 예시적인 시스템에서, 수수료 어카운팅 및 트랜잭션 로직은 본 개시에서 설명된 트랜잭션을 사용하여 구현될 수 있다. 이러한 경우, 운영자 또는 운영자의 대표자는 도메인의 노드에 참여할 수 있다. 수수료 어카운팅 규칙 및 수수료 지불 로직은 추가적인 어카운팅 컴포넌트 없이 원장 로직 내에서 구현될 수 있다. 또한, 수수료 데이터 또는 지원 데이터는 추가 트랜잭션 로직 없이도 제안된 트랜잭션 및 확인 메시지(암호화되거나 되지않거나) 내에서 전송될 수 있다. 이를 통해 참가자는 트랜잭션을 통한 수수료 계산에 사용되는 수수료 규칙을 생성 및 업데이트할 수 있으며, 수수료 계산이 참가자 및 트랜잭션 내용에 따라 특화되게 할 수 있다. 예를 들어, 참가자 노드들은 그들의 유일한 역할이 원장 프로세스 내에서의 검증만을 위한 것일 때, 검증 수수료가 면제될 수 있다.
분쟁(Dispute)
참가자가 합의된 시간 내에 트랜잭션을 확인하지 않거나, 검증에 실패한 트랜잭션들을 시스템적으로 요청하거나, 리소스 요구 사항이 부족하다고 선언하는 경우 등과 같이 참가자가 부정행위(misbehaving)하거나 실패하면 분쟁이 발생할 수 있다. 심판 노드는 시스템의 일부를 형성할 수 있으며 그리고 분쟁을 평가하기 위한 증거를 저장할 수 있다. 즉, 심판 노드는 전송된 트랜잭션들 및 확인들을 저장해야할 필요가 있을 수 있다. 분쟁에 관련된 노드들은 분쟁이 해결될 수 있도록 증거, 즉 블라인드되지 않은(unblinded) 트랜잭션을 제공해야할 수 있다. 프라이버시를 유지하기 위해, 노드는 심판 노드만이 해독할 수 있는 방식으로 트랜잭션을 다시 암호화할 수 있다.
일부 예시적인 시스템에서, 분쟁 해결 프로세스는 본 개시에서 설명된 트랜잭션을 사용하여 구현된다. 이러한 경우 심판은 도메인의 노드에 참여할 수 있다. 그런 다음 추가적인 어카운팅 컴포넌트 없이 원장 로직 내에서 분쟁 해결 프로세스를 구현할 수 있다. 추가 트랜잭션 로직 없이도, 분쟁들이 제기되고, 증거가 제출되며, 그리고 해결 결과가 결정될 수 있다. 이를 통해 참가자들은 분쟁을 제기하고, 증거를 제공하며, 트랜잭션을 통해 분쟁을 해결할 수 있다.
타임아웃(Timeout dispute)
위에서 언급한 바와 같이, 일례에서, 확인 조건은 참가자가 제안된 트랜잭션에 적시에 응답할 것을 요구한다. 참가자가 적시에 응답하지 않으면, 해당 트랜잭션에 대한 참가자 노드(또는 대리인)는 심판 노드에 대해 타임아웃 분쟁을 개시할 수 있다. 이것은 비준수(non-compliance)를 결정하는데 이용될 수 있으며, 더 중요한 것은 비준수를 유발한 특정 참가자 노드를 결정하는데 이용될 수 있다는 것이다. 이러한 타임아웃 분쟁을 처리하는 일례는 다음 중 하나 이상을 포함할 수 있다:
● 메시징 API가 전달한 관련 증거 및 응답에 실패한(피소된 참가자의) 가명과 함께, 영향을 받은 확인 요청의 타임스탬프를 심판 노드에 제출한다. 알려진 경우 가명 뒤에 있는 신원도 전송된다.
● 신원이 제공되지 않은 경우, 심판 노드는 신원 관리자(170)에게 그것의 잠금해제(unlock)를 요청한다. 피소된 참가자의 신원을 확인한 후, 심판 노드는 참가자(특히 참가자의 각 노드)가 응답했다는 증거에 대한 요청을 참가자에게 전송한다. 증거는 메시징 서비스로부터의 타임스탬프된 메시지로서, 피소된 참가자 또는 용량 모니터(상기 요청이 OutOfQuota(할당량 부족) 응답으로 거부된 경우)로부터의 확인 응답을 포함한다.
● 증거가 제공되면 요청 개시자는 영구적으로 "확인 전용"모드로 이동한다. 이들은 추가 확인 요청을 시스템으로 전송하는 것이 금지되지만, 우리는 이들이 여전히 메시지들을 수신하고 확인 응답을 전송하게 할 수 있다.
● 만일, 피소된 참가자가 응답하지 않으면, 이들을 오프라인으로 마킹하는 메시지가 브로드캐스팅된다. 오프라인 참가자들은 확인 전용 모드(confirm-only mode)로 이동하고, 다른 참가자들은 그들의 확인 요청들을 거부할 수 있다. 현재 체제에서 제출자들이 익명이므로, 용량 모니터 또는 수당 어카운턴트에 의해 거부가 수행될 수 있다. 피소된 참가자가 온라인 상태로 돌아온 후, 이들은 심판 노드에 의해 이와 같이 다시 마킹되기 위한 요청을 발행할 수 있다. 이러한 요청은 이용가능한 상태를 유지하도록 참가자들에게 인센티브를 제공하기 위해 소정의 "냉각(cool-off)" 기간 이후에만 승인될 수 있다.
● 피고인이 유효하지 않은 증거로 응답하는 경우, 이들은 영구적으로(또는 지정된 패널티 기간 동안) 확인 전용 모드로 이동한다.
참가자의 부정행위(misbehaviour)에 대한 검출 및 증명
악의적인 액션으로 인해 참가자의 부정행위가 발생할 수 있다. 일례들은 다음을 포함한다:
● 참가자가 기본 시스템 모델(예컨대, DAML 시스템의 DAML 모델)을 준수하지 않는 트랜잭션을 제출한다.
● 참가자가 상기 참가자가 호스트하지 않은 제출 당사자를 대신하여 트랜잭션을 제출한다.
● 참가자가 제출 당사자가 아닌 당사자의 승인이 필요한 트랜잭션을 제출한다.
● 참가자가 잘못 형성된(ill-formed) 트랜잭션을 제출한다.
● 참가자가, 선언된 이해관계자 참가자를 DAML(또는 다른 대안적인 시스템) 의미론(semantics)에 따른 이해관계자 참가자와 다르게 정의한다. 따라서, 잘못된 참가자에게 해당 액션에 대한 정보가 전달된다.
● 트랜잭션을 확인하는 수신 노드가, 액션을 검증하기 위해 프로토콜에 의해 지정된 알고리즘을 적용하지 않는다. 예를 들어, 액션이 기록보관된(archived) 계약을 사용하더라도 액션이 승인되는 경우. 또는 검증 알고리즘에 따라 승인되어야만 하는 액션이 거부되는 경우.
● 외부 노드가 수신 노드들의 잘못된 리스트와 함께 메시지를 전달하거나 또는 수신 노드로 메시지를 전달하지 못한다.
부정행위의 일례들과 그것이 시스템에서 어떻게 나타날 수 있는지는 다음을 포함한다:
1. 확인 요청(예컨대, 제출된 제안된 트랜잭션)이 기형으로(malformed) 플래그된다.
2. 충돌 응답(수신 노드로부터 예상되는 것에 대한)이 확인 요청에 대해 도착한다.
3. 용량 약속 소진(예컨대, 리소스 부족)을 잘못 주장함에 의해서 트랜잭션이 거부된다.
이것으로부터, 다음이 결정될 수 있다:
1. 만일, 2 명의 당사자들이 동일한 확인 요청에 대해 충돌되는 확인들을 발행하는 경우, 이들 중 하나는 악의적이다(malicious)(또는 그것의 참가자 노드가 충돌과 다른 방식으로 오작동한다).
2. 정직한 당사자들은, 심판 노드의 도움을 받아, 누가 속임수를 썼는지를 정확히 파악할 수 있는 충분한 데이터를 갖게된다.
다음과 같은 이유로 확인 요청이 기형(malformed)일 수 있다:
1. 전술한 바와 같이, 적합성(Conformance) 및 승인(Authorization) 체크 실패.
2. 제출 노드(110)에 의한 잘못된 리소스 선언.
기형의 확인 요청을 수신한 정직한 참가자는 이것을 심판 노드로 포워딩하여 분쟁을 개시한다. 심판 노드는 분쟁 개시 참가자 노드가 수행한 것과 동일한 검사(check)를 수행할 수 있다. 검사가 실패하면(예컨대, 제출 노드의 제안된 트랜잭션이 규칙을 통과하지 못함), 제출자의 신원이 폭로되고(uncloaked) 그리고 제출자는 영구적으로 확인 전용 모드로 이동한다. 그렇지 않으면 분쟁 개시자는 확인만 하도록 설정된다.
충돌하는 응답들은 하나의 당사자(즉, 수신 노드들 중 하나)가 거부하고, 다른 하나의 당사자(즉, 다른 하나의 수신 노드)가 트랜잭션을 확인하는 경우에만 발생할 수 있다. 거부하는 당사자는 먼저 심판 노드에 거부에 대한 증거를 제공해야만 한다.
1. 승인 또는 적합성 문제로 인해 트랜잭션이 거부된 경우, 확인 요청 자체만으로 충분하다; 또는
2. 일관성 검사로 인해 트랜잭션이 거부된 경우, 현재 트랜잭션과 충돌하는 이전의, 최종적으로 확인된 트랜잭션을 제공해야만 한다.
분쟁에서의 패자는 악의적으로 행동했기 때문에 영구적으로(또는 패널티 기간 동안) 확인 전용 모드로 이동된다.
중앙집중식 메시징 서비스 부정행위 탐지 및 입증
중앙집중식 메시징 브로커(centralized messaging broker)(예를 들어, 외부 노드 230)를 사용하는 경우, 메시징 브로커의 부정행위는 요구되는 메시징 계층 속성들의 위반을 유발할 수 있다. 직관적으로, 브로커의 임의의 관련 부정행위는 참가자 상태들의 다이버전스(divergence)를 유발할 것이다. 참가자들이 확인들 및/또는 하트비트들을 교환하거나 또는 이들이 분쟁을 제기하고자 할때, 이러한 다이버전스가 검출될 것인바, 왜냐하면 이들은 브로커의 부정행위를 가리키는 상충되는 증거를 가질 것이기 때문이다. 영향을 받는 당사자에 의해 부정행위가 검출될 수 있지만 입증가능하지 않는 2 가지 경우가 존재한다: (i) 브로커가 참가자로부터의 모든 메시지를 보류하는 경우 및(ii) 브로커가 참가자의 메시지를 거부하는 경우이다.
기타 예시적인 방법들
이제 3개의 다른 예시적인 방법들이 설명될 것이다. 첫 번째 일례는 단일 도메인에서의 방법의 일례이다. 두 번째 및 세 번째 일례는 다수의 도메인들과 관련된다. 특히 두 번째는 도메인 변경 프로토콜과 관련이 있다. 세 번째는 다중-도메인 트랜잭션과 관련된다.
단일 도메인에서의 추가적인 예시 방법
도 10 내지 도 13은 단일 도메인(1000)에서 전달 대 지불(DvP: delivery-versus-payment)(1001)의 일례를 예시한다. 앨리스(1010)와 밥(Bob)(1012)은 밥(1012)이 소유한 일부 주식(shares)에 대해서 앨리스(1010)에게 주어진 IOU를 은행(1014)에 의해서 교환하고자 한다. 우리는 4 개의 당사자들을 갖는다: 앨리스(일명(aka) A)(1010), 밥(일명 B)(1012), 은행 및 주식 레지스트리(SR)(1016). 또한 3가지 유형의 계약들이 있다:
1. IOU 계약(1031), 후원자로서 항상 은행(1014)을 사용
2. 주식 계약(1033), 레지스트리로서 항상 SR(1016)을 사용
3. 앨리스(1010)와 밥(1012) 간의 DvP 계약(1035)
앨리스는, 그녀가 소유한 IOU(1031)을 밥(Bob)이 소유한 주식(Share)(1033)으로 교환하는 DvP 계약(1035) 인스턴스 상의 "스왑(swap)" 선택권이 있다고 가정하자. 우리는 IOU 및 주식(Share) 계약 인스턴스들이 DvP에 이미 할당되었다고 가정할 수 있다. 앨리스는 이러한 스왑 선택권을 실행하는 트랜잭션을 커밋(commit)하고자 한다; 트랜잭션은 도 10에 도시된 다음의 구조를 갖는다.
이러한 예제 트랜잭션을 커밋하는 것은 2개의 단계들을 포함한다:
제 1 단계 - 앨리스의 참가자 노드(1010)(제출 노드로서)는 트랜잭션에 대한 확인 요청(1041)을 준비한다(1040)(도 12 참조). 상기 요청(1041)은 트랜잭션에 대한 상이한 뷰들을 제공한다. 참가자들은 그들의 당사자들이 이해관계자들인 계약을 실행, 페칭(fetching) 또는 생성하는 서브트랜잭션만을 볼 수 있다(더 정확하게는 이러한 당사자들이 정보수신자들(informees)인 서브트랜잭션들). DvP 및 수신자들에 대한 뷰들이 도 11a에 도시되어 있다(박스들의 우측 하단에 표시됨). 앨리스의 참가자 노드(1010)는 요청을 시퀀서(1018)(즉, 외부 노드(1018))에 제출하며, 시퀀서는 이러한 단일 도메인(1000) 내의 모든 확인 요청들을 정렬(order)한다. 그리고 2명의 참가자들이 동일한 2개의 요청들을 볼 때마다, 이들은 상기 시퀀서(외부 노드 1018) 순서에 따라 요청들을 보게될 것이다. 본 일례에서, 시퀀서(외부 노드 1018)는 오직 2개의 기능만을 갖는다: 메시지들을 오더링하고 그리고 메시지들을 그들의 언급된 수신자들(1012, 1014, 1016)에게 전송하는 것. 페이로드 메시지 콘텐츠는 암호화되며, 시퀀서(외부 노드 1018)에게 보이지 않는다.
제 2 단계 - 수신 노드들(1012, 1014, 1016)은 수신된 뷰들의 유효성을 검사한다. 유효성 검사들(1051, 1053, 1055, 1057)은 3개의 측면들을 커버할 수 있다:
1. 원장 모델에 정의된 유효성: 일관성(consistency)(주로: 이중 지출 없음(no double spends)), 적합성(conformance)(뷰는 유효한 DAML 해석의 결과임) 및 승인(authorization)(액터들과 제출자들이 뷰의 액션들을 수행하도록 허용됨을 보장함).
2. 진정성(authenticity)(액터들과 제출자들이 자신이 주장하는 사람임을 보장함).
3. 투명성(통지되어야하는 참가자들이 통지를 받았음을 보장함).
적합성(conformance), 승인(authorization), 진정성 및 투명성 문제는 제출자(1010)의 악의로 인해서만 발생한다. 일관성(consistency) 문제는 악의가 없음에도 발생할 수 있다. 예를 들어, 밥(1012)에게 양도될 IOU는 이미 소비되었을 수도 있다(DAML에서 "잠금(locking)"기술을 사용하지 않는다고 가정하자). 검사(check) 결과에 기초하여, 확인자들이라고 지칭되는 수신자들(1014, 1016)의 서브세트는 각 뷰에 대해 개별적으로 (긍정적 또는 부정적) 확인 응답을 준비한다. 요청과 관련된 확인 정책은 트랜잭션의 정보수신자들이 주어진 경우 어떤 참가자가 확인자인지를 지정한다.
확인자들은 중재자(1020)에게 응답들(1061, 1062, 1063, 1064)을 전송하며, 중재자(1020)는 전체 확인 요청에 대한 단일 결정으로 응답들을 집계하는 또 다른 특수 엔티티이다. 중재자(1020)는 참가자들의 신원들을 서로에게 숨기는 역할을 수행한다(따라서, 은행 1014 및 SR 1016은 이들이 동일한 트랜잭션의 일부임을 알 필요가 없다). 시퀀서(외부 노드 1018)와 유사하게, 중재자(1020)는 트랜잭션의 내용을 알지 못한다. 대신에, 앨리스의 참가자 노드(1010)는 요청(1041)을 전송하는 것 외에도 이와 동시에 각 뷰의 정보수신자들에 대해 중재자(1020)에게 통지한다(1042). 중재자는 도 11b에서 개념적으로 도시된 바와 같이, 뷰의 정보수신자들(informees)만을 볼 수 있고 컨텐츠가 블라인드된(1032, 1034) 트랜잭션 버전을 수신한다.
이로부터 중재자(1020)는 확인 요청을 승인된 것으로 결정하기 위해, 어떤 (긍정적인) 확인 응답들(1061, 1062, 1063, 1064)이 필요한지를 도출한다.
악의적인 참가자들이 제출한 요청들(1041)은 가짜 뷰들(bogus views)을 포함할 수 있다. 참가자들은 요청들의 일부들만을 볼 수 있으므로(프라이버시를 이유로), 요청에 대한 승인을 수신하면, 각 참가자는 보여지는 가짜 뷰들을 로컬적으로 필터링하고, 그리고 승인된 확인 요청의 모든 나머지 유효한 뷰들을 수락한다. 확인 정책의 신뢰성 가정하에서, 프로토콜은 정직한 참가자들에 대한 로컬 결정들이 이들이 공동으로 보는 모든 뷰들에 대해 매칭됨을 보장한다. 따라서, 프로토콜은 트랜잭션들이 이러한 유효한 뷰들로 구성된 참가자들 사이에서 가상 공유 원장을 제공한다. 일단 승인되면, 수락된 뷰들은 최종적이다. 즉, 이들은 참가자들의 기록들이나 가상 원장에서 절대 제거되지 않을 것이다.
다시 도 12의 예제를 참조하면, 시퀀서(즉, 외부 노드 1018) 및 중재자(1020)는 신원(도시되지 않았지만 다른 곳에서 설명됨)과 함께 단일 도메인(1000)의 일례를 형성한다. 도메인(1000) 내의 모든 메시지들은 시퀀서(외부 노드 1018)를 통해 교환되며, 이는 도메인(1000) 내에서 교환되는 모든 메시지들 간의 전체 순서(total order)를 보장한다.
전체 순서는 참가자들이 모든 확인 요청들(1041) 및 응답들을 동일한 순서로 볼 수 있음을 보장한다. 프로토콜은 또한, 모든 비-비잔틴(all non-Byzantine)(악의적이거나 타협되지 않은) 참가자들이 그들의 공유된 뷰들(예컨대, 은행과 A의 참가자간에 공유되는 IOU 양도 실행)을 동일한 순서로 볼 수 있음을 보장한다(비잔틴 제출자들(Byzantine submitters)과 함께라도). 이것은 다음과 같은 함의를 갖는다.
1. 각각의 뷰에 대한 올바른 확인 응답은 항상 고유하게 결정되는데, 왜냐하면 DAML 모델을 사용하는 일부 예에서는 이것이 결정론적(deterministic)이기 때문이다. 하지만, 성능상의 이유로, 우리는 가끔 부정확한 네가티브 응답들을 허용한다(참가자들이 비잔틴 방식으로 행동하기 시작하거나 논쟁 중인 경우). 상기 시스템은 정직한 참가자들에게 그들의 응답들의 정확성 또는 부정확한 거부 이유에 대한 증거를 제공한다.
2. 글로벌 오더링은 시퀀서(외부 노드 1018)에서 측정된, 도메인 내의 (가상) 글로벌 시간을 생성한다. 참가자들(1010, 1012, 1014, 1016)은 시퀀서(1018)로부터 메시지를 수신할 때마다 시간이 진행되었음을 알게된다. 이러한 글로벌 타임은 충돌들을 감지 및 해결하고 타임아웃들이 언제 발생하는지를 결정하는데 사용된다. 따라서, 개념적으로, 우리는 각 참가자들(101, 1012, 1014, 1016)이 이러한 단계를 상이한 물리적 시간에서 이 단계를 수행하지만, 이러한 글로벌 시간과 관련하여 여러 참가자들에서 동시에 발생하는 단계를 말할 수 있다. 예를 들어, 도 12의 메시지 시퀀스 다이어그램에서, 앨리스(1010), 밥(1012), 은행(1014) 및 주식 레지스트리(1016)의 참가자들은 서로 다른 물리적 시간들에서 확인 요청(1071, 1072, 1073, 1074)을 수신하지만, 개념적으로 이것은 글로벌 시간의 타임스탬프 ts1 에서 발생하며, 이와 유사하게 결과 메시지(1081)는 타임스탬프 ts6 에서 발생한다.
도 10 내지 도 13의 일례들은 단일 도메인을 예시한다. 하지만, 이것은 후속 일례들에서 논의되는 바와 같이, 다중 도메인들을 지원하도록 수정 및 조정될 수 있다.
시스템의 일부 고려사항들은 참가자 노드들이 과부하, 오프라인 또는 단순히 응답을 거부할 수 있다는 점을 감안하여, 확인-기반 설계로 진행됨을 보장하면서도 무결성 및 프라이버시 문제들을 조정하는 것이다. 이러한 고려사항들을 해결하는 방식들의 일례들은 다음을 포함한다:
● 타임아웃들의 사용: 트랜잭션의 유효성이 타임아웃(이것은 도메인-범위 상수임) 이후에도 결정될 수 없다면, 트랜잭션이 거부된다.
● 확인 요청이 타임아웃되면, 시스템은 참가자들이 확인 응답을 보내지 못한 요청을 제출 참가자(1010)에게 알려준다. 이를 통해 제출 참가자는 부정행위에 대한 밴드 액션들을 취할 수 있다.
● 유연한 확인 정책들: 신뢰, 무결성 및 생동감(liveness) 간의 트레이드-오프를 제공하기 위해, 일부 도메인들은 그들 각각의 확인 정책들에 맞게 조정될 수 있다. 확인 정책들은 어떤 참가자들이 어떤 뷰들을 확인해야하는지를 지정한다. 이것은 중재자(1020)가 승인된 요청을 선언하기에 충분한 조건들을 결정할 수 있게한다. 특히 흥미로운 것은 VIP 확인 정책으로, 모든 액션들에 대해 정보수신자로서 신뢰할 수 있는 (VIP) 당사자를 포함하는 트랜잭션들에 적용될 수 있다. VIP 당사자의 일례는 시장 운영자(market operator)이다. 이 정책은 VIP 당사자의 참가자들이 올바르게 행동한다고 가정하여 원장 유효성을 보장한다. 이 경우 잘못된 거동이 여전히 감지되고 입증될 수 있지만, 좋지못한 결과(fallout)는 시스템 외부에서 핸들링되어야만 한다. 또 다른 중요한 정책은 서명 확인 정책(signatory confirmation policy)으로서, 여기서는 모든 서명자들과 액터들이 확인할 필요가 있다. 이것은 서명자들 또는 액터들을 호스팅하는 참가자들이 응답하지 않을 때 생동감을 희생하는 VIP 확인 정책에 비하여, 낮은 레벨의 신뢰를 요구한다. 또 다른 정책(더 이상 사용되지 않음: being deprecated)은 모든 정보수신자들이 확인해야만 하는 전체 확인 정책이다. 이것은 가장 낮은 레벨의 신뢰를 요구하지만, 관련 참가자들 중 일부가 응답하지 않는 경우 생동감을 희생한다.
● 증명자 노드(attestor nodes). 증명자 노드들은 온-디맨드 VIP 참가자로 생각될 수 있다. VIP 당사자들이 모든 액션들에 대해 정보수신자가 되도록 DAML 모델을 구성하는 대신에, 증명자 노드들은 온-디맨드로만 이용된다. 트랜잭션을 커밋하려는 참가자는 서브트랜잭션의 유효성에 대한 명백한(unequivocal) 증거를 증명자 노드들에 제공하도록 충분한 분량의 히스토리를 공개해야만 한다. 그러면 증명자의 진술은, 응답하지 않는 참가자의 확인을 대체한다.
도 13은 확인 요청의 상태 천이도(1300)를 도시한다. "제출됨"을 제외한 모든 상태들은 최종 상태이다. 다른 곳에서 설명했듯이, 확인 요청은 다음과 같은 다양한 이유로 거부될 수 있다: 현재 도메인(1000) 외부에 있는 트랜잭션에 대한 요청(허용가능한 다중-도메인 트랜잭션의 일부인 경우 제외, 이는 개별적으로 설명될 것임), 타임아웃, 시간 초과, 불일치 및 이전 또는 다른 요청과의 충돌.
도메인 변경 및 결합성(Domain changes and composability)
일부 예들에서, 시스템이 상이한 도메인들에 걸쳐 다중 도메인들 및 트랜잭션들을 지원할 것이라는 점에서 상기 시스템은 결합성(composability)을 갖는다. 결합성은 동기화 계층(어플리케이션 계층이 아닌)에서 도메인 간 트랜잭션에 대한 원자성(atomicity)을 보장한다. 이를 통해 어플리케이션 레벨에서 여러 도메인들을 하나의 개념적 원장으로 구성할 수 있다. 도메인 간 트랜잭션들에 대한 접근 방식은 다음을 포함한다:
1. 도메인 변경 프로토콜. 이것은 한 도메인에서 다른 도메인으로 계약을 전송하는 프로토콜이다. 이러한 프로토콜은 필요한 모든 계약들을 단일 도메인으로 이동시켜, 다중 도메인 트랜잭션을 단일 도메인 트랜잭션으로 줄이는데 사용될 수 있다. 즉, 이것은 영향을 받는 모든 계약들의 모든 이해관계자들이 하나의 공통 도메인에 연결될 것을 요구한다.
2. 다중 도메인 트랜잭션을위한 프로토콜. 이 접근 방식은 서로 다른 도메인들 사이에서 릴레이 역할을 할 수 있는 일부 참가자 노드들을 포함한다. 이 접근 방식에서는 모든 이해관계자들이 단일 도메인에 연결될 필요가 없다. 그러나 이러한 시스템에서는 트랜잭션들이 모든 도메인들에 걸쳐 원자적으로 실행되도록 이해관계자들에 의한 적극적인 참여가 중요하다.
이제 2가지 접근 방식에 대해 자세히 설명한다.
도메인 변경 프로토콜
도메인 변경 프로토콜은 하나의 도메인(원점)으로부터 다른 도메인(타겟)으로 개별 계약을 이동시킨다. 계약은 다른 이유들로 이동할 수 있다:
● 후속 트랜잭션이 단일 도메인의 계약에서 작동할 수 있는지를 보장하기 위한 준비 단계로서.
● 서로 다른 도메인들 간의 로드 균형을 맞추기 위해(이해관계자에 의해 수행됨).
● 더 나은 시장 규칙들, 수당(allowances) 또는 서비스 품질(또한, 이해관계자에 의해 수행됨)을 활용하기 위해.
도메인 변경 프로토콜의 일례들은 다음의 특성들 중 하나 이상을 포함할 수 있다.
● 계약은 한 도메인에만 상주하거나 또는 다른 도메인으로 이전 중이다. 계약은 결국 계약의 거주지인 도메인에 있어야한다. 계약에 대한 모든 이해관계자는 해당 거주 도메인에 직접 연결(또는 릴레이를 통해 간접적으로 연결)되어야 한다.
● 모든 이해관계자들은 그들의 모든 계약들이 어디에 있는지 알고 있어야 하며, 이러한 정보를 그들 각각의 해당 계약 저장소에 메타데이터로 보관할 수 있다.
● 계약 ID는 거주지가 변경되어도 변경되지 않는다.
도메인 변경은 원본 도메인 상에서의 트랜스퍼-아웃(transfer-out)과 타겟 도메인 상에서의 트랜스퍼-인(transfer-in)이라는 2개의 단계에서 발생한다. 도메인 변경은 트랜스퍼-중단(transfer-abort)을 사용하여 중단될 수 있다.
이때 참가자들은 도메인 변경을 시작한 사람(개시자: initiator)의 신원을 알게되고, 메시지 브로커(즉, 외부 노드)는 트랜스퍼된 계약의 ID와 타겟 도메인을 보게된다. 더 나은 프라이버시 보장은 향후 작업에서 조사될 것이다.
일부 예들에서, 도메인 변경 프로토콜 접근 방법은 모든 도메인들 간의 협력을 반드시 필요로하지 않고, 대신 그 계약 및 트랜잭션과 관련된 참가자들만을 필요로 하기 때문에 특히 유리할 수 있다. 도메인 변경 프로토콜은 개시자 노드(614)에 의해 개시된다. 일부 예에서, 개시자 노드(613)는 제출 노드(110)이거나 그와 연관된다. 다른 예에서, 개시자 노드는 수신 노드(120)를 포함하는 다른 노드들일 수 있다.
이제 도메인 변경의 2가지 일례들이 도 6 및 도 7를 참조하여 설명될 것이다. 첫 번째 일례에서, 이해관계자 I 및 P와 함께 도메인 1에 상주하는 ID cid를 가진 계약이 존재한다. 개시자 I(614)는 도 6에 도시된 바와 같이 계약을 도메인 2로 이전한다.
1. 개시자 I(614)는 트랜스퍼-아웃 요청(621)을 원본(origin) 도메인의 메시지 브로커(610)(즉, 외부 노드)로 전송한다. 트랜스퍼-아웃 요청(TO)은 계약 ID, 제출자, 타겟 도메인 및 타겟 도메인으로부터의 타임스탬프 tsO를 포함한다.
2. 원본 메시지 브로커(610)는 시간 tsl에서 상기 요청 TO를 타임스탬프하고 그리고 이를 이해관계자(612) 및 개시자(614)에게 전송한다(623, 624). 이들은 계약 cid가 시간 tsl부터 전송되는 것으로 간주한다.
3. 개시자(614)는 트랜스퍼-인 요청 TI(625)를 타겟 도메인의 메시지 브로커(616)(즉, 타겟 도메인의 외부 노드)로 전송하며, 이는 타임스탬프된 트랜스퍼-아웃 요청을 포함한다.
4. 타겟 메시지 브로커(616)는 시간 ts2에서 트랜스퍼-인 요청을 타임스탬프하고, 이를 이해관계자(612)(즉, 수신 노드 및/또는 제출 노드와 관련된 것들) 및 개시자(614)에 전송한다(627, 629). 이해관계자(612)는 ts2 시점부터 계약이 타겟 도메인에 상주하는 것으로 간주한다.
트랜스퍼-아웃 요청(621)은 타겟 도메인 상에서의 독점 타임아웃(exclusivity timeout)(630)에 대한 기준선(baseline)을 설정하기 위해 타겟 도메인으로부터의 타임스탬프 tsO를 포함한다. 독점 타임아웃(630) 이전에는, 도메인 변경을 완료하거나 이를 중단하기 위해 개시자 노드(614)만이 트랜스퍼-인 요청 또는 트랜스퍼-중단 메시지를 타겟 도메인에 전송할 수 있다. 이러한 독점 타임아웃(630)은 아마도 상이한 원본 도메인들 상의 상이한 계약들에 대한 여러 도메인 변경들을 시작하고 그리고 이들을 트랜잭션(도면에 도시되지 않음)과 함께 트랜스퍼-인 전송 메시지로 타겟 도메인에 제출할 시간을 개시자(614)에게 제공한다.
만일, 개시자(614)가 독점 타임아웃(630) 이전에 도메인 변경을 완료하지 않거나 중단하지 않으면, 계약의 다른 이해관계자들(612)이 그렇게할 수 있다. 이것은 개시자 노드(614)가 계약을 무기한으로 트랜스퍼 상태에 놔둘 수 없게함을 보장하며, 이에 따라 다른 이해관계자들(612)이 그들에 대한 선택권을 행사할 권리를 박탈하지 못하게 한다.
도 7에 도시된 바와 같이 두 번째 일례는 앞의 일례와 동일한 설정을 갖지만, 단계 2 이후에, 개시자는 독점 타임아웃(630) 이전에 트랜스퍼-인 요청을 전송하지 않는다. 대신, 단계들은 다음을 포함한다:
3. 이해관계자 P(612)는 트랜스퍼-중단 메시지를 타겟 도메인(616)에 전송한다(731).
4. 타겟 도메인(616)은 시간 ts2에서 트랜스퍼-중단을 타임스탬프하고 그리고 이를 이해관계자와 개시자에게 전달한다(733, 735).
따라서 개시자 노드(614) 및 이해관계자(612)는 앞선 트랜스퍼-인 메시지가 타겟 도메인 상에 없었음을 알고있다. 원본 도메인에 아직 타임스탬프가 없기 때문에 계약 자체는 여전히 트랜스퍼 중이다. 따라서,
5. 이해관계자 P(612)는 타임스탬프된 트랜스퍼-중단을 트랜스퍼-중단 통지로서 원본 도메인 메시지 브로커(610)에 포워딩한다(737).
6. 원본 메시지 브로커(610)는 시간 tsl'에서 이러한 통지를 타임스탬프하고 그리고 이를 이해관계자(612) 및 개시자 노드(614)로 전달한다(739, 741). 그들은 계약이 tsl' 이후에 다시 원본 도메인에 상주하는 것으로 간주한다.
7. 도메인 2로부터 트랜스퍼-중단 메시지를 수신하면(735), 개시자 노드(614)는 타겟 도메인 타임스탬프가 독점 타임아웃(630) 이후인지를 검사하여, 이해관계자 P(612)가 그들의 독점 시간 기간으로 절단되지 않았음을 확인한다.
도메인 변경을 중단하는 대신에, 이해관계자 P는 트랜스퍼-인 메시지를 전송하여 이를 완료할 수도 있다. 이후, 이해관계자 P의 트랜스퍼-인 메시지가 독점 타임아웃(630) 이후에 타임스탬프되었는지를 개시자 노드(614)가 확인하는 것을 제외하고는, 프로토콜은 제 1 일례예에서와 같이 진행될 것이다. 반대로, 첫번째 일례에서, 개시자(614)는 트랜스퍼-중단 메시지를 전송함으로써 도메인 트랜스퍼를 중단할 수 있었다.
앞의 내용은 도메인 변경 프로토콜의 일례들이며 프로토콜의 다른 유형들 및 변형들이 이러한 결과를 달성할 수 있음을 이해해야한다. 도 6 및 도 7에 일반적으로 서술된 프로토콜들의 하나의 일례의 세부 내용이 이제 설명될 것이다.
모든 사람이 계약을 다른 도메인으로 이전할 수 있는 것은 아니다. 모든 이해관계자(제출 노드, 수신 노드 또는 기타 영향을 받는 노드와 관련될 수 있음)는 항상 계약을 이전할 수 있다. 유일한 제한은 모든 이해관계자가 새 도메인을 수락(또는 동의)하기 전에 미리 신호를 보내야한다는 것이다. 이러한 기본 설계에서는 우리는 모든 참가자가 시작시에 어떤 도메인이 동의하는지를 선언하였고 그리고 모든 참가자가 이러한 선언들을 알고 있다고 가정한다.
도메인 변경을 시작하기 위해, 개시자(614)는 (예를 들어, 메시지 브로커 도메인 1(610)을 통해) 계약의 거주 도메인으로 트랜스퍼-아웃 요청(621)을 전송한다(621). 이러한 요청은 트랜스퍼될 계약 ID, 개시자의 신원 및 아마도 프록시된 개시 자 노드, 타겟 도메인, 타겟 도메인의 최근 타임스탬프(예컨대, 브로커의 하트비트로부터) 및 도메인을 변경할 권한에 대한 정당성(justification)을 포함한다. 타임스탬프는 개시자(614)가 도메인 변경을 중단하거나 또는 타겟 도메인 상에 트랜스퍼-인 메시지를 제출할 배타적 권한을 갖는 시간 윈도우에 대한 기준선을 설정한다. (개시자(614)가 계약의 원본 도메인에 연결되지 않은 경우, 그는 이해관계자(612)에게 자신을 대신하여 도메인 트랜스퍼를 시작하도록 요청해야만 한다. 이 경우, 실제 개시자는 프록시 개시자가되고 이해관계자는 개시자가 된다.) 트랜스퍼-아웃 요청은 메시징 계층 상의 모든 계약 이해관계자(612)에게 어드레싱된다. 트랜스퍼-아웃의 일례는 다음을 포함한다:
data TransferOutRequest = TransferOutRequest
{ contractID :: ContractID
, initiator :: Party
, proxiedInitiator :: Maybe Party
, targetDomainID :: SiriusDomainID
, targetTimestamp :: Signature SiriusDomainID Timestamp
, justification :: (ProvenanceProof, Randomness) }
원본(origin) 메시지 브로커(610)는 요청을 타임스탬프하고(623), 제출 확인을 개시자(614)에 전송하고(623), 타임스탬프와 함께 트랜스퍼-아웃 요청을 모든 이해관계자(612)에게 포워딩한다(624). 원본 도메인에서의 수당 어카운팅 컴포넌트는 개시자의 계정으로부터 도메인 변경 수당을 공제한다.
이해관계자 P(612)는 트랜스퍼-아웃 요청에 대해, 다음 중 하나 이상 또는 모두를 포함하는 검사들을 수행한다:
i. 이해관계자의 목록(612)이 완성되었다.
ii. 제출자는 요청에 지정된 개시자(614)이다.
iii. 타겟 도메인은 모든 이해관계자에 대해 수용가능하다.
iv. 타겟 타임스탬프가 타겟 도메인에 의해 서명되었다.
v. 정당성(justification)이 유효하다
vi. 계약이 원본 도메인에 상주한다.
vii. 더 작은 물리적 타임스탬프를 구비한 경쟁하는 도메인 변경 또는 트랜잭션이 없으며, 그리고 동일한 트랜스퍼-아웃 요청에 대해 타겟 도메인에 트랜스퍼-중단 메시지가 없다.
(i)에서 (v)까지의 검사가 실패하면, 트랜스퍼-아웃 요청은 잘못된 것이며, 참가자(612)는 악의적인 거동(전송 프로토콜의 밴드 외)을 보고한다. 검사 (vi)가 실패하면, 이해관계자(612)는 트랜스퍼-아웃 요청(624)을 거부한다. 이러한 거부는 계약의 현재 거주 도메인을 포함한다. 레이싱(racing) 도메인 변경으로 인하여 계약이 현재 트랜스퍼중인 경우, 거부는 그와같이 말한다. 개시자(614)가 이해관계자(612)가 아닌 경우, 개시자(614)가 도메인 변경에 대해 통지받지 않기 때문에 검사 (vi)는 또한 레이스들 없이 실패할 수도 있다. 그러한 경우, 거부(rejection)는 개시자(612)에게 새로운 거주지에 대해 알려준다. 검사 (vii)가 실패하면, 이해관계자(612)는 트랜스퍼-아웃 요청(624)을 거부한다. 모든 검사들이 통과되면, 계약은 트랜스퍼-아웃 요청의 원본 타임스탬프부터 시작하여 트랜스퍼된다.
이해관계자(612)는 도메인 규칙에 의해 정의된 트랜스퍼-아웃 확인 타임아웃 내에서 원본 도메인의 메시지 브로커(610)를 통해 개시자(614)로의 트랜스퍼-아웃 요청을 확인한다. 모든 검사들은 모든 이해관계자가 동의하는 데이터에만 의존한다. 따라서, 이해관계자들(612)은 모두 동일한 결과가 되어야만 한다. 따라서, 이들 사이에서는 확인들을 보낼 필요가 없다.
트랜스퍼-인 단계는 계약을 타겟 도메인에 등록한다. 원본 메시지 브로커 타임스탬프 및 서명과 함께 트랜스퍼-아웃 요청을 가진 이해관계자(612) 및 (프록시된) 개시자(614)는 트랜스퍼-인 메시지(625)를 타겟 메시지 브로커(616)에 제출함으로써 그렇게할 수 있다. 이러한 권리는 트랜스퍼-아웃(621)과 독점적 타임아웃(630) 사이의 기간 동안 개시자(614)에게 독점적인 것이다. 하나의 트랜스퍼-인 메시지(625)는 심지어 서로 다른 원본 도메인들로부터의 여러 계약들을 동시에 등록할 수 있으며 그리고 선택적으로는 DAML 트랜잭션을 포함할 수 있다(요청 페이로드의 형태로; 리소스 요청 메시지는 미리 보내져야 함). 트랜스퍼-인 요청의 일례는 다음을 포함한다:
data TransferInMessage = TransferInMessage
{ inContracts :: [TransferInRequest]
, submitter :: Party
, transaction :: Maybe RequestPayload }
data TransferInRequest = TransferInRequest
{ out :: TransferOutRequest
, originTimestamp :: Timestamp
, originSignature :: Signature }
타겟 메시지 브로커(616)가 트랜스퍼-인 메시지(625)를 수신하면, 모든 트랜스퍼-인 요청들은 타겟 도메인에 의한 동일한 타임스탬프를 획득하고 그리고 트랜스퍼-인 확인 요청들로서 각각의 이해관계자(612)에게 전송된다(629). 만일, 트랜스퍼-인 메시지가 트랜잭션을 포함한다면, 이것은 다음 타임스탬프를 획득한다.
참가자(612)가 트랜스퍼-인 확인 요청을 수신하면(629), 이것은 원본 도메인(610)으로부터 대응 트랜스퍼-아웃 요청을 수신(624) 및 프로세스할 때까지 대기한다(통상적으로, 트랜스퍼-아웃 요청(624)은 트랜스퍼-인 메시지(629) 보다 앞서서 도착하지만, 네트워크 지연이 변동하는 경우에는 반드시 그런 것은 아니다). 이후 이것은 다음의 검사들을 수행한다:
(i) 트랜스퍼-아웃 단계에서 설명한 바와 같이, 원본 도메인 상의 트랜스퍼-아웃 요청을 확인했는지.
(ii) 이러한 트랜스퍼-아웃 요청에 대한 더 앞선 타임스탬프가 있는 트랜스퍼-인 확인 요청 또는 트랜스퍼-중단 통지를 보지 못했는지.
(iii) 트랜스퍼-아웃 요청이 올바른 타겟 도메인을 지정하는지.
(iv) 트랜스퍼 메시지의 제출자가 트랜스퍼-아웃 요청의 개시자가 아닌 경우, 적어도 독점적 타임아웃(630)이 트랜스퍼-아웃 요청의 targetTimestamp와 트랜스퍼-인 확인 요청 상의 타겟 브로커의 타임스탬프 사이에서 경과했는지.
(v) 개시자(614)가 트랜스퍼된 계약의 이해관계자가 아닌 경우, 참가자는 메시지 브로커로부터의 다음 타임스탬프가 트랜스퍼된 계약에 대한 선택을 행사하는 트랜잭션에 있을 것인지를 체크하도록 기억한다.
이러한 검사들 중 어느 하나라도 실패하면, 참가자(612)는 분쟁 해결 섹션에 설명된 대로 부정행위를 보고한다. 그렇지 않으면, 트랜스퍼-인 확인 요청에서 타겟 메시지 브로커의 타임스탬프에 의해 표시된 시점부터 계약이 타겟 도메인에 상주하는 것으로 간주한다. 이와 함께, 계약은 트랜스퍼 상태에 있는 것을 중지한다(즉, 계약은 타겟 도메인에 상주함). 이것은 타겟 메시지 브로커(616)를 통해 개시자(614) 및 프록시된 개시자에게 확인을 전송한다. 그렇지 않으면, 이것은 개시자 및 모든 이해관계자에게 거부를 전송한다.
만일, (프록시된) 개시자 노드가 계약의 이해관계자가 아니라면, 참가자(612)는 다음 타임스탬프가 있는 타겟 메시지 브로커(616)로부터의 메시지가 트랜스퍼된 계약에 대해 선택권(choice)을 행사하는 트랜잭션을 포함하고 있는지 그리고 출처 증명(provenance proof)이 액터(actor) 및 선택권을 포함하고 있는지를 검사한다. 만일 그렇지 않다면, 부정행위가 보고된다.
여러 개의 트랜스퍼-아웃 요청들을 하나의 트랜스퍼-인 메시지로 번들링(bundling)하는 것은 모든 트랜스퍼들의 원자성(atomicity)을 보장하지 않는다. 일부는 성공할 것이고 일부는 실패할 수 있다. 번들링은 모든 후속 트랜스퍼들이 동일한 타임스탬프를 획득하는 것을 보장할 뿐이다. 이러한 방식으로, 트랜잭션에 필요한 계약들의 묶음(bundle)이 동시에 거주할 수 있다. 만일, 이들이 개별적인 트랜스퍼-인들(transfer-ins)에서 이루어진다면, 모든 계약이 동일한 도메인에 상주하기 전에 더 앞선 계약들이 트랜스퍼 아웃될 위험이 있었다. 도메인 변경들 중 하나가 실패하면, 미양도(untransferred) 계약에 대한 선택권을 행사하지 않는 한 트랜잭션도 또한 실패할 것인데, 왜냐하면 트랜잭션의 도메인에 계약이 상주하지 않음으로 인해 계약의 이해관계자들이 트랜잭션을 거부할 것이기 때문이다. (가장 빠른) 독점 타임아웃 전에, 개시자는 자신이 이해관계자가 아닌 각 계약에 대해 하나의 트랜스퍼-아웃 확인을 받았다면 모든 도메인 변경들이 성공할지의 여부를 알고 있다.
각 도메인은 도 7에 도시된 바와 같이 도메인 변경들에 대한 독점적 타임아웃(630)을 지정한다. 독점적 타임아웃(630) 동안, 도메인 변경의 오직 개시자(614)만이 트랜스퍼-인 또는 트랜스퍼-중단 메시지를 전송할 수 있다. 타임아웃(630) 베이스라인은 개시자(614)가 트랜스퍼-아웃 요청(621)에서 사용한 타겟 도메인 타임스탬프에 의해 설정된다. 따라서, 개시자(614)는 가장 최근의 타임스탬프를 사용할 인센티브를 갖는데, 왜냐하면 이것은 도메인 변경을 진행할 독점적 권리를 연장하기 때문이다.
독점적 타임 윈도우 동안, 개시자(614)는 트랜스퍼-아웃 요청 확인들(623)을 모을 수 있으며 그리고 여러 개의 트랜스퍼-아웃들을 하나의 트랜스퍼-인(625)으로 묶을 수 있다. 따라서, 개시자(614)는 트랜잭션에 필요한 모든 계약들이 동일한 도메인으로 이동됨을 보장할 수 있으며 그리고 일부가 실패하면 도메인 변경의 중단을 결정할 수 있다. 트랜잭션을 트랜스퍼-인 요청(625)에 포함시킴으로써, 어떤 경쟁하는 트랜스퍼-아웃도 계약들의 일부를 멀리 트랜스퍼할 수 없다. 트랜잭션에 대한 리소스 요청 메시지는 독점적 타임 윈도우 동안(즉, 독점적 타임아웃(630) 이전에) 전송되어야 한다. 따라서, 독점 기간은 개시자(614)가 또한 트랜스퍼-인 메시지(625)를 제출하기 전에 용량 거부 타임아웃을 기다릴 수 있도록 충분히 길어야 한다.
독점적 타임아웃(630) 이후에, 다른 이해관계자는 개시자(들)이 계약들을 무기한으로 트랜스퍼 상태로 유지하는 것을 방지하고 리소스를 확보하기 위해 도메인 변경의 중단을 시작할 수 있다.
다중-도메인 트랜잭션을 위한 프로토콜
다중-도메인 트랜잭션은 여러 도메인들로부터의 계약들에 걸쳐 있으며 명시적인 계약 도메인 변경을 요구하지 않는다. 본 섹션은 다음의 속성들 및 가정들을 사용하여 다중 도메인 트랜잭션을 위한 프로토콜을 설명한다:
● 제출자는 트랜잭션에서 사용되거나 생성된 계약들이 있는 모든 도메인에 연결되어야 한다.
● 입력 계약이 하나의 도메인에 상주하고 그 자체가 다른 도메인에서 발생하는 서브트랜잭션을 갖는 서브트랜잭션의 이해관계자인 경우 참가자를 릴레이라고 한다.
● 다중 도메인 트랜잭션의 제출자는 항상 릴레이이다. 모든 릴레이는 모든 도메인에 연결되어야 한다.
● 다른 모든 이해관계자들은 그들의 계약들이 상주하는 도메인에만 연결되면 된다. 특히 관련된 모든 참가자가 연결되는 단일 도메인이 있을 필요는 없다.
● 여러 도메인에 연결된 참가자들은 상이한 도메인들의 신원 관리자들에 서로 다른 키들을 등록했을 수 있다.
● 모든 릴레이들 또는 메시지 브로커들 중 하나가 적시에 작동하지 않거나 또는 모든 릴레이들과 메시지 브로커 중 하나 사이에서 연결 문제가 발생하지 않는 한, 다중 도메인 트랜잭션은 모든 도메인에서 원자적으로 실행된다.
● 모든 도메인에서 동일한 원장 유효 시간이 사용된다.
● 서로 다른 도메인 간의 클럭 차이와 클럭 드리프트에 알려진 경계가 있다.
● 다중 도메인 트랜잭션은 비관적 거부(pessimistic reject) 및 조건부 판정(conditional verdict) 확인 요청 규칙들과 함께 작동한다.
● 관련된 모든 도메인은 동일한 최종 모델(전체 확인 또는 낙관적 VIP 확인)을 따라야 한다.
● 단일 도메인 트랜잭션은 다중 도메인 트랜잭션을 프론트-런(front-run)할 수 있다.
● 모든 계약은 모든 이해관계자가 연결된 단일 도메인에 상주하며 그리고 계약의 모든 이해관계자는 그것이 어디에 상주하는지를 항상 알고 있다.
제출자(제출 노드(110)와 관련됨)는 자신이 이해관계자인 트랜잭션에 대한 모든 입력 계약의 거주 도메인을 알고있다. 도메인 변경 프로토콜에서와 같이, 제출자가 이해관계자가 아닌 입력 계약의 경우, 제출자는 과거의 어느 시점에서 거주지를 알고 있다. 트랜잭션에서 생성된 계약의 경우, 제출자는 이러한 계약이 생성될 위치도 알고 있다. 이는 트랜잭션 자체(예컨대, DAML 트랜잭션 또는 DAML 확장)에 지정되거나 또는 제출자가 스스로 결정할 수 있다. 트랜잭션에 관련된 도메인은 트랜잭션에 대한 입력 계약이 상주하거나 트랜잭션이 계약을 생성한 모든 도메인이다.
도 8을 참조하면, 다중 도메인 트랜잭션은 각 도메인(803, 805)에 대해 하나의 부분으로 분할된다. 각 부분은 확인 요청에서 일부 뷰 페이로드들이 누락된 부분적인 단일 도메인 트랜잭션처럼 실행된다(다시 말해, 다른 도메인들 상의 계약들에 영향을 주는). 그럼에도 불구하고 모든 뷰들에 대한 모든 확인들은 모든 도메인으로 전송되어야 한다. 이를 위해, 릴레이들은 한 도메인에서 다른 도메인으로 확인들을 포워딩한다.
도 8은 2 개의 계약들 cidl 및 cid2에 대해 선택권을 행사하는 단순한 2-도메인 트랜잭션에 대한 메시지 흐름을 예시한다. 도메인 할당들은 다음 표에 주어진다:
Figure pct00001
따라서, 상기 트랜잭션은 3 명의 참가자들을 포함한다: 제출 노드(815), 참가자 1(811) 및 참가자 2(819)와 2개의 도메인들 D1 및 D2(및 외부 노드로 작동하는 도메인 1(D1, 803) 도메인 2(D2, 805)의 각각의 메시지 브로커들 813, 817). 트랜잭션에 관련된 모든 참가자들이 연결된 도메인은 존재하지 않지만, 제출자(제출 노드)(815)는 모든 도메인에 연결되어 있으며 따라서 릴레이 역할을 한다. 제출자(815)는 전체 트랜잭션의 확인 요청을 각 뷰에 대해 하나씩, 2 개의 부분적인 단일 도메인 트랜잭션으로 분할한다. 그런 다음, 제출자(815)는 각 부분을 적절한 메시지 브로커(813, 817)(즉, 각 도메인 D1 및 D2의 2 개의 외부 노드)로 동시에 전송한다. 각각의 부분은 2개의 메시지들, 리소스 요청(831, 835) 및 요청 페이로드(833, 837)로 구성되며, 여기서 제출자(815)는 그 어떤 참가자도 임의의 도메인(803, 805)에서 리소스 요청(831,835)을 거부하지 않았음을 확인한 이후에만 페이로드들(833, 837)을 전송함을 보장해야만 한다(예를 들어, 모든 용량 거부 타임아웃들이 경과할 때까지 대기함으로써). 각각의 부분적 단일 도메인 트랜잭션은 다음의 예외들을 제외하고 단일 도메인의 경우와 같이 처리된다:
1. 예상된 확인들(851, 852)은 다른 도메인들의 가명 참가자들을 또한 포함한다. 릴레이들(본 일례에서는 제출자 노드815)은 다른 도메인의 메시지 브로커(813, 817)를 통해 확인을 의도된 수신자(811, 819)에게 포워딩(853, 854)할 책임이 있다.
2. 참가자들(811, 819)이 그들의 확인 응답들(851, 852)를 로컬 메시지 브로커(817, 813)에 보내야만 하는 시간을 결정하는 확인 데드라인(845, 846)은, 확인 데드라인 오프셋 만큼 결정 시간(847, 848) 보다 앞서며(심지어 메시지 브로커의 클럭에 대해서도), 확인 데드라인 오프셋은 제출자(815)가 일부 제약에 따라 선택하는 것이다. 원격 도메인들로부터의 확인들(851, 852)은 결정 시간(848, 847)까지 도메인의 메시지 브로커(외부 노드)(813, 817)에 도달해야한다. 확인 데드라인과 결정 시간 사이의 오프셋은 릴레이들에게 한 도메인으로부터 확인들을 수집하고 이를 다른 도메인으로 포워딩하며 그리고 도메인들(803, 805) 간의 클럭 스큐 및 다양한 확인 응답 타임아웃들을 숨기기 위한 시간을 제공한다.
도 9는 다양한 데드라인들이 어떻게 결정되고 함께 작동하는지를 예시한다. 제출자(제출 노드)(815)는 다음을 선택한다:
● 평가를 위한 원장 유효 시간(LET: ledger effective time)(909).
● 논리적 시간 오프셋(911, 913).
● 확인 데드라인 오프셋(915, 917).
LET는 전체 다중-도메인 트랜잭션에서 동일해야한다. 오프셋(911, 913, 915, 917)은 각 도메인(803, 805)에 대해 다르게 선택될 수 있다.
부분 트랜잭션들이 개별 도메인으로 전송될 때(831, 835), 각각은 다음과 같이 특정 도메인의 모든 시점들을 결정하는 물리적 타임스탬프를 수신한다:
● 논리적 시간 = 물리적 시간 + 논리적 시간 오프셋(911, 913).
● 결정 시간(847, 848) = 논리적 시간 + 확인 응답 타임아웃(915, 917).
● 확인 데드라인(845, 846) = 결정 시간(848, 847) - 확인 데드라인 오프셋(915, 917).
각 시점은 도메인 803, 805에 연결되어 있다. 따라서 이러한 시점들의 절대 시간은 도메인에 따라 다르다. 도 9에서, 제출자(815)는 도메인 1(803)에 대해 더 긴 논리적 시간 오프셋(911)을 선택했으며(예를 들어, 리소스 요청 전송이 도메인 2, 805에서 더 오래 걸릴 것으로 예상했기 때문에) 그리고 도메인 1(803)에서 논리적 시간(921)은 실제로 벽시계 시간(wall-clock time)과 관련하여 도메인 2(805)의 논리적 시간(923) 이후에 도달한다.
제출자(815)는 모든 도메인들이 유사한 논리적 시간으로 종료하도록 도메인의 네트워크 지연에 대한 경험을 기반으로 논리적 시간 오프셋(911, 913)을 선택해야한다. 이는 모든 도메인에서 동일한 원장 유효 시간(909)이, 도메인 규칙의 허용 오차(925, 927)에 의해 결정된 대로, 각 도메인의 논리적 시간(921, 923)에 가까워 야하기 때문이다.
제출자(제출 노드)(815)는 소스 도메인의 확인 데드라인(845, 846)과 포워딩 타겟 도메인의 결정 시간(847, 848) 사이의 시간에서 모든 릴레이들이 확인 응답들을 포워딩(853, 854)하기에 충분한 시간을 갖도록 확인 데드라인 오프셋(915, 917)을 선택해야한다(소스 및 타겟 도메인의 모든 조합에 대해). 하지만, 도메인으로부터의 논리적 타임스탬프를 준수할 시간과 브로커(813, 817)에서의 확인 데드라인(845, 846) 전에 도달할 수 있도록 확인 응답을 전송해야만 하는 시간 사이의 충돌들을 검사(951)할 충분한 시간을 모든 도메인의 모든 참가자가 가질 수 있도록, 오프셋(915, 917)은 충분히 작아야한다.
제출자(815)가 이러한 시간들을 선택하기 때문에, 제출자는 다른 릴레이들에 비해 장점을 가질 수도 있다. 이를 방지하기 위해, 제출자(815)는 확인 데드라인들(845, 846)이 임의의 2개의 도메인들에서 얼마나 멀리 떨어져있을 수 있는지를 제한하는 확인 허용오차(953)를 선택해야한다. 허용오차가 클수록 확인 데드라인 오프셋(915, 917)이 길어져야만 한다.
다중 도메인 트랜잭션 사용 사례: 글로벌 담보(Global collateral)
이제 다중 도메인 트랜잭션의 일례가 다중 도메인 트랜잭션에 대한 글로벌 담보의 맥락에서 설명될 것이다. 글로벌 담보의 키 동기화 및 프라이버시 요건들이 일반 원자 스왑(generic atomic swap)에서 캡처된다.
글로벌 담보 사용 사례에서, 2 명의 당사자 A와 B는 각각 A와 B가 소유한 2개의 자산 X와 Y를 원자적으로 스왑(swap)하려고 한다. 단순화를 위해, 모든 당사자가 그 자신의 참가자 노드를 실행한다고 가정한다. 자산 X의 소유권은 거래소(exchange)의 자산 레지스트리 R1에 의해서 하나의 거래소(exchange) EX1 에 기록된다. 자산 Y의 소유권은 다른 거래소의 자산 레지스트리 R2에 의해 다른 거래소 EX2 에 기록된다. 각각의 거래소 EXi 는 자체 도메인 Di를 운영하고 그리고 거래소의 자산 레지스트리들은 해당 거래소 도메인에만 연결된다. 즉, Ri는 Di에만 연결된다. 당사자 A와 B는 두 도메인 모두에 연결된다.
아토믹 스왑은 DvD(딜리버리 vs 딜리버리) 계약에서 캡처되며, 여기서 둘 중 하나인 A는 스왑을 실행하기 위한 선택을 행사할 수 있다. 이러한 선택은 2개의 서브트랜잭션을 수반한다: A는 X를 B로 트랜스퍼하고; 그리고 B는 Y를 A로 트랜스퍼한다. 이러한 계약은 다른 도메인 D3 에 상주할 수 있으며, 도메인 D3에는 A와 B가 모두 연결되어야한다(이해관계자들이므로).
이러한 트랜잭션은 다중 도메인 트랜잭션의 요구 사항을 충족한다: 자산 레지스트리 R1 및 R2 는 릴레이가 아니며, 왜냐하면 이들 각각은 이들의 거래소 도메인 상에서 하나의 트랜스퍼만을 보며 따라서 이들은 다른 도메인에 연결될 필요가 없기 때문이다. 사실, 이들은 트랜잭션이 모든 도메인에서 원자적으로 실행되는지 여부는 신경 쓰지 않는다. 반대로, 반대로 A와 B는 릴레이이며, 이들 둘다는 3개의 도메인에 모두 연결된다. 원자성은 둘다에 모두 중요하다. A가 X를 B로 트랜스퍼하는데 성공했지만 B가 Y를 A로 트랜스퍼하는데 실패하면, A는 자산없이 남게된다.
B의 경우는 대칭이다. 따라서 이들 둘다는 도메인들 사이에서 메시지들을 적시에 릴레이하는데 관심이 있다.
이러한 트랜잭션은 모든 이해관계자들이 연결된 도메인이 없기 때문에, "도메인 변경 프로토콜"(전술한 바와 같은)으로 실행될 수 없다.
본 섹션의 나머지 부분은 다중 도메인 트랜잭션의 세부 사항과 단일 도메인 트랜잭션과의 차이점에 대해 설명한다.
트랜잭션 제출(Transaction submission)
다중 도메인 트랜잭션 제출은 다음의 측면들에서 단일 도메인 트랜잭션과 다르다:
뷰 형성(view formation)은 계약 거주지를 고려한다. 트랜잭션 트리의 순회(traversal)가 탑-레벨 트랜잭션의 서브트랜잭션을 방문하면 다음과 같은 경우 새로운 박스가 생성된다:
● 서브 트랜잭션의 계약(입력 또는 생성)이 부모 노드의 입력 계약과 다른 도메인에 있거나, 또는
● 이해관계자 집합들이 다른 경우(단일 도메인 사례에서와 같이). 모든 박스에는 관련된 도메인이 주석으로 표시된다.
도 8을 참조하면, 제출자는 트랜잭션에 포함된 각 도메인에 대해 리소스 요청(831, 835) 및 페이로드 메시지(833, 837)로 구성된 확인 요청을 준비한다. 도메인 D에 대한 각 리소스 요청 및 페이로드 메시지는 다음의 수정사항들과 함께 단일 도메인의 경우에서와 같이 준비된다:
● 리소스 요청의 리소스 및 수당(allowances) 필드는 D를 통해 전송된 뷰들의 리소스 요구 사항들 및 트랜스퍼된 수당만을 집계한다. 또한, 모든 릴레이들은 확인 응답을 릴레이하기 위해 모든 도메인에 바인딩된 리소스가 할당된다.
● 대역폭은 D를 통해 전송된 페이로드의 사이즈를 나타낸다.
● 페이로드 데이터는 D를 통해 전송된 뷰들의 액션 설명들(action descriptions)만을 포함한다.
● "allStakeholders" 목록에는 D를 통해 전송된 박스들의 이해관계자의 가명만이 포함된다. 일부 릴레이 P(제출자 포함)가 이들 사이에 포함되지 않지만 D에 연결되어 있는 경우, 제출자는 인위적으로 P에 대한 가명을 생성하고 이를 "allStakeholders"에 추가한다.
● 예상된 확인들의 목록은 모든 도메인에서 필요한 확인들을 포함한다. 페이로드 메시지가 전송될 도메인을 통해 확인들이 전송되더라도, 모든 확인에 대해, 도메인 ID가 설정된다.
● "multiDomain" 필드는 아래와 같이 리소스 요청에서 설정된다. 특히 이러한 필드는 아래에 설명된 확인 데드라인 오프셋 및 허용오차를 정의한다.
data MultiDomainData = MultiDomainData
{confirmDeadlineOffset :: TimeDistance
, confirmTolerance :: TimeDistance
}
● logTimeOffset은 확인 데드라인 오프셋만큼 증가한다.
● 요청 페이로드 메타 데이터의 "multiDomain" 필드는 다른 도메인의 리소스 ID 목록으로 설정된다.
data MultiDomainPayloadData = MultiDomainPayloadData
{remoteRequestlds :: [(DomainID, RequestID)]
}
리소스 요청의 다중 도메인 트랜잭션 메타 데이터에는 다음의 정보가 포함된다:
● 제출자는 확인 데드라인에 대한 오프셋을 각 도메인에 대해 선택한다. 주어진 도메인의 참가자들은 그들의 확인을 먼저 보내야한다
논리적 시간 + crt
대신에
논리적 시간 + crt = confirmationDeadLineOffset
여기서 crt는 단일 도메인 사례의 확인 응답 타임아웃이다. 확인 데드라인 오프셋은 다음의 제약 조건을 충족해야한다:
confirmDeadLineOffset < crt - 2*△
여기서 △는 도메인의 메시지 브로커와 통신하는데 예상되는 네트워크 지연이다. 또한 이것은,
2 * △max + confirmTolerance + skew < confirmDeadLineOffset 를 만족해야한다.
여기서 △max는 관련 참가자로부터 연결된 관련 도메인까지 예상되는 최대 네트워크 지연이며, skew는 임의의 두 도메인 간의 클록 스큐에 대한 상한이다.
● 확인 데드라인 오프셋은 한 도메인에서 다른 도메인으로 확인을 포워딩하기 위한 릴레이로서 역할을 수행할 시간을 제출자(및 다른 참가자)에게 제공한다.
상한은 모든 참가자가 논리적 시간을 준수한 후 확인 응답을 보낼 수 있는 충분한 시간을 갖도록 보장한다. 하한은 릴레이가 도메인들 사이에서 확인 응답을 포워딩할 시간을 제공한다.
● 확인 허용오차는 다른 도메인들의 확인 데드라인들이 얼마나 떨어져 있을 수 있는지를 지정한다. 제출자가 다른 도메인들 상의 물리적 타임스탬프를 더 잘 예측할수록, 실제 확인 데드라인이 더 가까워지고 선택할 수 있는 허용 오차가 낮아진다.
페이로드 요청 대신에, 제출자(815)는 트랜잭션을 중단할 수 있다. 다음과 같은 경우 중단이 필요하다:
● 리소스 요청이 도메인들 중 하나에서 거부된다. 따라서 전체 트랜잭션이 거부되어야 한다.
● 물리적 타임스탬프가 너무 멀리 떨어져 있어, 확인 허용오차가 초과되었다.
메시지 브로커가 리소스 요청이나 요청 페이로드를 수신하면, 단일 도메인 트랜잭션처럼 이들을 처리한다. 특히 제출자는 모든 도메인에 대한 제출 수당을 지불해야한다.
확인 요청들의 프로세싱
확인 요청들(831, 833, 835, 837)은 다음의 양상들을 제외하고는 단일 도메인 트랜잭션과 동일하게 처리된다.
● 참가자는 "RemoteRequestIDs" 필드에 중복 도메인 ID가 없는지를 체크하고 그리고 예상 확인에 언급된 모든 도메인들에 대해 정확히 하나의 엔트리가 포함되어 있는지 체크한다. 모든 참가자는 페이로드 요청에 제공된 요청 ID와 원격 요청 ID들로부터 새로운 요청 식별자를 도출한다. 이러한 도출은 원격 요청 ID들의 순서와 독립적이어야한다. 새로운 요청 식별자는 확인 응답에 사용된다.
● 트랜잭션에 대한 확인 데드라인은 다음에 의해 결정된다.
phys_ts + logTimeOffset + crt - confirmationDeadlineOffset
● 용량 모니터는 수정된 확인 데드라인을 사용하여 트랜잭션이 용량 약속에 맞는지 여부를 결정한다.
● 참가자는 다음을 체크한다
2*△max + confirmTolerance + skew ≤ confirmDeadlineOffset < crt - 2*△ - skew
요청 페이로드들(833, 837)의 경우, 참가자는 추가로 다음 사항을 체크한다.
● 리소스 요청들(831, 835) 및 요청 페이로드들(833, 837)이 동일한 도메인(803, 805)를 통해 전송되었다. 실행들의 경우(For exercises), 입력 계약은 확인 요청이 전송된 도메인에 상주한다. 생성들의 경우(For creates), 요청 페이로드의 도메인은 모든 이해관계자가 수용할 수 있다.
● 각각의 액션에 대해, 참가자는 확인 응답을 보낼 때까지 자신이 이해관계자인 모든 서브트랜잭션들에 대한 박스들을 받게될 것인지를 체크한다.
● 뷰의 서브액션이 다른 도메인에서 작동하는 경우, 참가자는 자신을 릴레이로 간주한다.
● 뷰의 서브액션이 다른 도메인에서 작동하는 경우, 참가자는 확인을 전송하기 전에 다음 모두를 확인한다:
- "remoteRequestIDs"에 있는 모든 원격 요청 ID의 물리적 타임스탬프들이 뷰의 확인 데드라인 이전에 최소한 confirmTolerance + △max + skew에 놓여있다.
- "remoteRequestIDs"에 나열된 모든 도메인에 대한 리소스 요청을 수신했다.
- 모든 요청들의 확인 데드라인들의 모든 쌍이 기껏해야 "confirmationTolerance" 만큼 떨어져 있다.
● 참가자에게 전송되는 액션 박스들의 예상 확인들에 대해 올바른 도메인 ID가 설정된다.
● 메타데이터와 액션 박스들을 교차-체크하는 경우, 참가자는 동일한 도메인에 있는 모든 서브액션들을 체크한다. 참가자가 릴레이인 경우, 참가자는 대응 도메인을 통해 전송된 "allStakeholders" 목록과 함께 다른 도메인의 모든 서브액션들도 교차-체크한다 하위 작업도이 교차 검사를 수행한다(예상 확인자 목록은 어떤 경우에도 모든 서브액션들에 대해 체크된다).
참가자는 "allStakeholders" 목록으로부터 가명들로 확인 응답을 보낸다. 이것은 모든 도메인으로부터 예상 확인들을 수신하는지 체크한다. 확인 응답을 생성할 때 다중 도메인 데이터 md 는 확인 허용오차를 포함한다.
data MultiDomainConfirmationData = MultiDomainConfirmationData
{confirmTolerance :: TimeDistance
}
레이싱 트랜잭션의 경우, 단일 도메인 트랜잭션을 위해 조건부 판정(conditional verdict)이 이용되더라도, 다중 도메인 트랜잭션들은 항상 비관적 거부 규칙(pessimistic reject rules)에 따라 처리된다.
결과적으로, 다중 도메인 트랜잭션의 논리적 타임스탬프가 논리적 시간과 다른(단일 또는 다중 도메인) 트랜잭션의 확인 데드라인 사이에 있으면, 다중 도메인 트랜잭션은 완전히(outright) 거부된다. 이것은 특히 다중 도메인 트랜잭션이 일반적으로 더 긴 논리적 시간 오프셋을 갖기 때문에 다중 도메인 트랜잭션을 2급 시민(second-class citizens)으로 만든다.
확인 응답들의 프로세싱
확인자들(예컨대, 수신 노드들로 작동하는 참가자의 노드들 811, 819와 같은)은, 모든 참가자가 확인 내의 다중 도메인 데이터가 리소스 요청(831, 835)에서 수신한 동일한 확인 허용오차를 포함하고 있는지를 추가로 체크하는 것을 제외하고는, 단일 도메인 트랜잭션과 동일하게 확인 응답들을 프로세싱한다. 모든 예상 확인들이 이러한 도메인을 통해 도착한 경우, 참가자는 소정 도메인(803, 805)에서 트랜잭션이 최종 승인된 것으로 간주한다. 특히, 참가자가 상이한 도메인들 상의 상이한 가명들로 발생하는 경우, 이것은 최종 승인에 대해 두 개의 별개의 엔티티들인 것처럼 행동해야한다. 따라서, 참가자는 트랜잭션이 하나의 도메인(예컨대, 803)에서 최종 승인된 것으로 간주할 수 있는 반면, 다른 도메인(예컨대, 805)에서는 여전히 보류중인 것으로 간주할 수 있다. 특히, 참가자는 하나의 도메인의 최종 승인에 대한 후속 확인들을 기반으로 결정을 내릴 수 있지만 다른 도메인에서는 그렇게해서는 안된다. 그럼에도 불구하고 단일 도메인 트랜잭션의 의미론(semantics)은 계약의 모든 이해관계자가 그것의 상태에 동의함을 보장할 수 있는데, 왜냐하면 계약은 하나의 도메인에만 상주할 수 있기 때문이다. 또한, 최종성에 관한 여러 상태들은 가장 최근(latest)의 결정 시간이 경과하면, 타임아웃들, 분쟁들, 및 충돌들이 발생하지 않는한, 수렴할 것이다.
참가자 노드는 자신이 수신한 임의의 뷰에 대한 릴레이로서 자신을 간주하면, 자신을 릴레이로 간주한다. 릴레이가 하나의 도메인으로부터 확인 응답을 받으면, 단일 도메인의 경우와 동일한 체크들을 수행한다. 또한 다음을 수행한다:
● 모든 도메인으로부터 확인 응답들을 수집한다.
● 하나의 도메인으로부터 충분히 많은 확인 응답들이 도착하면(예상 확인 목록에 의해 결정됨), 릴레이는 다른 도메인들을 통해 모든 참가자들에게 모든 확인들을 전송한다. 여러 도메인에 연결된 모든 참가자는 마치 각 도메인에서 별도의 엔터티인 것처럼 행동하기 때문에, 릴레이는 다른 도메인들 상의 가명을 가진 참가자들이 계약의 이해관계자인 경우에도 이들을 생략해서는 안된다.
제출자가 모든 도메인의 모든 릴레이에 대한 가명을 만들었으므로, 모든 릴레이는 모든 확인 응답을 수신하며, 따라서 이들을 포워딩할 수 있다. 릴레이는 또한 확인 응답을 먼저 수집한 다음에 단일 배치로 전송하는 대신에, 확인 응답들을 즉시 포워딩할 수도 있다. 불필요한 트래픽을 피하기 위해, 릴레이는 아직 확인 응답을 받지 못한 도메인들에만 확인 응답을 포워딩해야한다. 모든 포워드들이 서로 경쟁하기 때문에, 동일한 확인 응답이 다른 타임스탬프를 사용하여 여러 번 도메인을 통해 전송될 수 있다. 누구나 나중 타임스탬프가 포함된 확인 응답을 무시할 수 있다.
도메인들 간의 원자성(Atomicity across domains)
일부 예에서, 확인 응답들(851, 852)은 로컬 확인 데드라인(845, 846)까지 전송되어야한다. 다른 도메인들로부터의 응답들은 결정 시간(847, 848)까지만 도착하면된다. 이러한 2개의 타임스탬프들은 2-페이즈-커밋 프로토콜(two-phase-commit rotocol)의 2개의 페이즈들의 종료를 나타낸다: 모든 참가자들은 확인 데드라인까지 제출자에게 커밋 준비를 보내야하며 그리고 이들은 결정 시간(847, 848)까지 커밋 또는 중단을 예상할 수 있다.
고전적인 2-페이즈-커밋 프로토콜은 하드 타임아웃과 원자성을 결합할 수 없다. 결과적으로, 도메인 특정 결정 시간(847, 848) 이전에 일부 확인 응답들이 모든 도메인들(803, 805)로 포워딩되지 않는 경우, 다중 도메인 트랜잭션은 비원자적으로(non-atomically) 실행될 수 있다. 예시적인 일례에서, 제출자(815)가 참가자 1(811)의 포워딩(854)과 제출자의 도메인(805)으로의 확인(PL1)을 도메인(805)의 결정 시간(847) 이후까지 지연했다라고 가정하자. 그런 다음 참가자 1(811) 및 제출자(815)는 도메인 D1의 트랜잭션이 승인된 것으로 간주한다. 반대로, 참가자 2(819)는 도메인 D2에서의 확인 PL1(854)이 타임아웃된 것으로 간주하고 그리고 제출자에 대해 분쟁을 일으킬 수 있다. 제 2 도메인(805) 분쟁 규칙에 따라, 도메인(805)에서 트랜잭션이 거부될 수 있다. 따라서, 트랜잭션이 원자적으로 실행되지 않았다. 하지만, 우리는 그러한 예에서 제출자(815)만이 원자성에 관심을 갖고 있으며 원자성이 침해된 것은 제출자의 잘못이라고 주장한다. 따라서 아무도 트랜잭션이 원자적으로 실행되지 않았다고 불평할 수 없다.
일반적으로, 시스템 전체가 아닌 특정 당사자들만이 트랜잭션(일부)의 원자성에 관심을 갖는다. 보다 공식적으로(more formally), tx = [a1 , a2 , ..., an]은 관심있는 트랜잭션을 나타낸다고 하자. 모든 액션 ai 자체는 계약을 작성하거나 계약 ci 에 대해 선택권 chi 을 행사한다. 모든 실행(exercise) ai 자체는 추가 서브트랜잭션들 txij 등과 함께 추가 액션들 aij 의 서브트랜잭션 txi를 포함한다. 실행(exercise) ai의 승인자들(authorizers)은 실행에 대한 입력 계약이 생성되었을 때 이들이 원자성을 약속했기 때문에, 원자적으로 실행되는 서브트랜잭션 txi에 관심을 가질 수 있다. 마찬가지로, aij 의 승인자들은 txij 의 원자성에 관심이 있다. txij 가 txi 의 서브트랜잭션이므로, ai의 승인자들은 또한 txij 가 원자적으로 실행되는 것에 대해 (타동적으로: transitively) 관심을 갖는다. 최상위 트랜잭션 tx의 경우, 제출자들이 원자성에 관심이 있다. 요약하면, (서브)트랜잭션 tx..., 의 경우, 루트에서 서브트랜잭션까지의 경로에 있는 제출자(815) 및 모든 승인자들(811, 819)는 그 원자성에 관심을 갖는다. 다른 당사자는 tx...가 원자적으로 실행되는지 여부를 신경쓰지 않아야한다. 특히, 당사자가 서브트랜잭션 txi1 의 이해관계자이지만 서브트랜잭션 txi2 에서는 그렇지 않은 경우, 상기 당사자는 txi2 가 원자적으로 실행되는지 여부는 상관하지 않는데, 왜냐하면 DAML의 프라이버시 모델로 인해 상기 당사자는 txi2 에 대해 알수도 없기 때문이다. 오직 제출자만이 원자적으로 실행되는 모든 탑-레벨 액션들에 대해 관심이 있다.
또한, 당사자가 aij 및 ajk (j≠k)의 승인자이지만, ai 의 승인자가 아닌 경우, 이는 2개의 서브액션들이 원자적으로 실행되는지 아닌지를 신경쓰지 않아야 한다. 특히, 그러한 당사자의 참가자는 릴레이일 필요가 없다.
이러한 원자성 개념을 감안할 때, 모든 참가자는 아래의 논거들에서 볼 수 있듯이 자신이 관심을 갖는 서브트랜잭션들의 원자성을 스스로 보장할 수 있다.
● tx의 하나의 서브트랜잭션 tx1 이 일부 도메인(예컨대, 제 1 도메인 D1)에서 승인되고 tx의 다른 서브트랜잭션 tx2 가 다른 도메인(예컨대, 제 2 도메인 D2)에서 거부된 경우, 참가자는 다중 도메인 (서브)트랜잭션 tx의 원자성이 위반된 것으로 간주한다.
● D1 = D2 또는 tx1 = tx2, 즉, 단일 도메인 또는 단일 서브트랜잭션 상에서의 충돌들을 고려할 필요가 없다. 왜냐하면, 단일 도메인 서브프로토콜은 한 도메인 내에서 무결성과 원자성을 보장하기 때문이다. 특히, 릴레이들이 아닌 참가자들은 무시될 수 있다.
● 따라서 D1≠D2 이고 결과적으로 tx1≠tx2 이다. 전체 트랜잭션 tx에 대한 모든 예상 확인들이 도메인 D1에 도달했지만 도메인 D2에 도달하지 않은 경우에만 원자성 위배가 발생할 수 있다. 확인 응답들을 적시에 포워딩함으로써 참가자자 이러한 상황을 회피할 수 있다는 것을 보여주면 충분하다.
● txi 를 그 확인 응답들이 D1에 도달했지만 D2에 도달하지 않은 임의의 하위트랜잭션이라고 가정하자. Di 는 txi가 전송되는 도메인을 나타낸다고 하자. 릴레이는 트랜잭션과 관련된 모든 도메인에 연결되어 있으므로, 이것은 특히 Di에 연결된다. 이것이 Di를 통해 리소스 요청과 페이로드 요청을 수신했으므로, 이것은 Di 를 통해 전송된 "allStakeholders" 목록의 일부이다. txi에 대한 확인들이 D1에 도달했으므로, 이것들은 확인 데드라인 전에 도메인 Di를 통해 전송되어야한다. 메시지 브로커가 메시징 API를 올바르게 구현한다고 가정하면, 릴레이는 이들 확인들을 적시에 수신했다. 이것은 이들 응답들을 모든 도메인들, 특히 D2로 포워딩한다. 따라서, 응답들은 도메인 D2에 도달할 것이다.
● 이것은 릴레이가 확인 응답들을 적시에 포워딩할 수 있음을 보여준다.
릴레이는 아래의 시간(D2의 메시지 브로커에서 측정됨) 이전에 도메인 Di 로부터 이들을 수신한다.
confirmationDeadlinei + △max + skew
따라서, 참가자가 이들을 즉시 전달하면, 이들은 아래의 시간 이전에 D2의 메시지 브로커에 도달한다.
confirmationDeadlinei + 2 * △max + skew
릴레이는 확인 응답들을 프로세싱하는 동안 다음을 체크하였다.
confirmationDeadlinei ≤ confirmationDeadline2 + confirmationTolerance
2 * △max + confirmationTolerance + skew ≤ confirmationDeadlineOflset2
decisionTime2 = confirmationDeadline2 + confirmationDeadlineOflset2 이므로, 우리는 원하는 관련성을 획득한다.
confirmationDeadlinei + 2 * △max + skew ≤ decisionTime2
다중 도메인 트랜잭션들의 타임아웃
다양한 도메인들(803, 805)에 대한 타임아웃들을 선택하는 파라미터들을 선택하는 것은 제출자(815)이다. 따라서, 제출자는 도메인들 사이에서 확인 응답들을 포워딩(853, 854)하는 책임이 있으며, 제출자 노드(815)가 스스로 설정한 타임아웃들 내에서 실제로 포워딩을 달성할 수 있도록 파라미터들을 선택해야한다. 트랜잭션에 대한 모든 다른 참가자들(811, 819)은 그들이 제 시간에 각자의 업무를 수행하고 거래에 대한 관심을 행사할 수 있도록, 제출자(815)가 타이밍 파라미터들을 선택했는지 여부를 단순히 체크한다.
그럼에도 불구하고 타임아웃들이 발생할 수 있다. 참가자들(811, 819)은 확인 페이로드들(833,837)를 수신할 때만 트랜잭션의 다중 도메인 특성을 알게되는데, 이때가 바로 예상 확인 목록과 요청 ID 목록이 전송될 때이기 때문이다. 따라서, 본 섹션에서는 확인 응답들(851, 852)의 타임아웃에만 초점을 맞추고 요청 페이로드의 타임아웃은 무시한다.
참가자(811, 819)가 확인 데드라인(845, 846)에 참가자로부터 동일한 도메인에 대한 확인이 누락된 것을 알게되면, 참가자(811, 819)는 단일 도메인 트랜잭션에서와 같이 적절한 도메인에 대해 분쟁을 제기할 수 있다. 참가자가 다른 도메인으로부터 확인 응답이 누락되었음을 알게되면, 참가자(811, 819)는 로컬 도메인(803, 805) 상의 제출자(815)에 대해 분쟁을 제기할 수 있다. 이렇게하면 제출자(815)가 도메인들(803, 805)에 걸쳐 확인들을 포워딩(853, 854)하는 것을 주로 책임지는 노드가 된다. 반대로, 다른 모든 릴레이는 자신의 이익을 위해 그렇게할 수 있지만 그렇게할 의무는 없다. 제출자의 잘못이 아니더라도, 예를 들어 다른 도메인의 참가자가 적시에 확인을 보내지 않았기 때문에도, 분쟁은 제출자(815)를 대상으로 한다.
제출자(815) 자체는 다른 도메인에 대해 분쟁을 일으킬 수 있다. 제출자가 후자의 분쟁에서 이기고 전자의 분쟁에서 지더라도, 2개의 분쟁들의 효과들이 상쇄되지 않을 위험이 있다.
타임아웃이 발생하면, 트랜잭션이 원자적으로 실행되지 않을 수 있다. 이전 섹션에서 논의된 바와 같이, 모든 참가자(811, 819)는 관심이 있는 원자성의 정도를 보장할 수 있다. 그러나 참가자(811, 819)는 다중 도메인 트랜잭션의 여러 도메인(803, 805)에 관여할 수 있지만 원자성에 관심이 없다(예컨대, 모든 뷰가 단일 도메인에서 실행되고 따라서 릴레이가 아니기 때문에). 이 경우, 참가자(811, 819)는 트랜잭션이 원자성이 아님을 관찰할 수 있다.
분쟁 규칙에 따라, 참가자(811, 819)는 트랜잭션의 성공과 실패를 모두 고려해야할 수 있다. 보다 정확하게는, 트랜잭션의 모든 효과(생성되거나 보관된 계약)는 거주 도메인에 얽매인다. 효과는 다른 도메인의 결과와 관계없이 거주 도메인에서 트랜잭션이 승인되는 즉시 발생한다.
하지만, 타임아웃은 이중 지출의 기회를 생성하지 않는다. 모든 계약이 단일 도메인(803, 805)에만 상주하므로 이중 지출에 관련된 2개의 트랜잭션들은 동일한 도메인에서 실행되어야한다. 모든 이해관계자는 항상 계약 상태에 동의하므로, 모든 이해관계자는 제 2 트랜잭션을 위해 소비되지 않은(unspent) 계약에 대해 거짓말을 해야한다.
다중 도메인 트랜잭션에서 부정행위 검출(Detecting misbehaviour in multi-domain transactions)
단일 도메인 트랜잭션과 마찬가지로 참가자는 다중 도메인 트랜잭션에서 부정행위를 할 수 있다(misbehave). 본 섹션에서는 다중 도메인 트랜잭션에 특화된 부정행위 사례들을 알아본다. 단일 도메인 트랜잭션에서 발생할 수 있는 부정행위 대한 조치는 동일하게 유지된다.
i. 불일치하는 정보(Inconsistent information)
리소스 요청들(831, 835) 및 요청 페이로드(833, 837) 메시지들이 도메인(803, 805)에 걸쳐 분할되므로, 메시징 API는 모든 참가자들 동일한 메시지 부분들을 수신하는지를 더 이상 보장할 수 없다. 구체적으로, 제출자(815)는 서로 다른 도메인(803, 805)에 불일치 정보를 전송할 수 있다. 참가자의 노드(811, 819)는 다음과 같은 불일치들을 감지하고 그들의 도메인에 대해 적절한 분쟁을 일으킬 수 있다. 이 모든 경우를 다루기 위해 분쟁 규칙들이 확장될 필요가 있다.
● LET: 모든 참가자는 확인 응답의 페이로드 요청으로부터 LET를 포함한다. 참가자가 확인 응답을 프로세싱할 때, 참가자는 LET가 참가자가 본 LET와 동일한지를 체크한다. 만일, 제출자가 다른 뷰들에 대한 LET를 전송하면, 적어도 모든 릴레이들은 차이점을 알 수 있다(릴레이들 중 그 누구도 체크하지 않는 경우, 정직한 참가자는 원자성, 즉 LET 일관성에 대해 신경쓰지 않는다).
● 원격 요청 ID : 모든 참가자는 확인 응답에 사용하는 모든 요청 ID에서 트랜잭션 식별자를 도출한다. 만일, 참가자가 요청 ID들의 다른 목록을 수신한다면, 도출된 트랜잭션 식별자가 달라질 것이다. 따라서, 다른 참가자들은 이러한 확인들을 승인하지 않을 것이며, 참가자(동일한 도메인) 또는 제출자(다른 도메인)에 대해 분쟁(불량 또는 확인 누락으로 인한)을 제기할 것이다. 동일-도메인 케이스는 메시지 브로커가 메시징 API를 지정된 바와 같이 구현하지 않는 경우에만 발생할 수 있다.
● 예상 확인들 : 모든 확인 응답은 예상 확인들의 해시를 포함한다. 예상 확인들의 상이한 목록들은 상이한 해시들을 가지며, 따라서 잘못 형성된(ill-formed) 확인 응답들에 대한 분쟁을 유발할 것이다.
● 확인 허용오차(Confirmation tolerance) : 확인 허용오차는 확인 응답들에 포함되며 그리고 참가자들은 확인들 내의 값이 그들이 수신한 리소스 요청의 값과 동일한지를 체크한다. 따라서, 서로 다른 확인 허용오차들은 잘못 형성된(ill-formed) 확인 응답에 대한 분쟁을 유발할 것이다.
ii. 잘못 형성된 파라미터(ill-formed parameters)
다중 도메인 트랜잭션에서, 제출자는 단일 도메인 트랜잭션에 대한 파라미터들 외에도 다음의 파라미터들을 지정한다:
● 타이밍 파라미터들 "confirmationDeadlineOffset" (per view) 및 "confirmationTolerance"
● 예상 확인들의 도메인 ID들
● 원격 요청 ID들
"confirmationDeadlineOffset"은 도메인별로 선택되는 반면에, 다른 파라미터들은 트랜잭션 전체에 대해 선택된다. 확인 요청을 프로세싱하는 동안 모든 참가자가 체크하는 제약 조건들이 이러한 파라미터에 적용된다. 제약 조건을 위반하는 경우, 참가자는 잘못 형성된 메시지가 전송된 도메인에서 잘못 형성된 메시지로 인해 제출자에 대해 분쟁을 제기한다.
대부분의 체크들은 참가자의 로컬 지식만에 관련되며 따라서 확실히 실행될 수 있다. 유일한 예외는 다른 도메인에 있는 서브뷰가 있는 뷰들에 대해 릴레이들에 의해 수행되는 체크들이다. 만일, 릴레이들이 체크들에 필요한 메시지들을 확인 데드라인까지 다른 도메인들로부터 받지 못한다면, 릴레이는 거부를 전송한다. 하지만, 물리적 타임스탬프들이 적어도 skew + "confirmationTolerance" + △max 만큼 모든 확인 데드라인 전에 놓였있다는 체크는, 정상적인 네트워크 동작하에서 릴레이가 확인 데드라인까지 모든 필요한 메시지를 수신할 것임을 보장할 수 있다. 만일, 그렇지 않다면, 릴레이는 제출자에 대해 누락된 요청 페이로드에 관한 분쟁을 제기할 수 있다. 체크는 또한 모든 정직한 릴레이들이 네트워크 지연들과 관계없이 동일한 판정에 도달하는지를 확인한다(만일, 리소스 요청이 메시지 브로커로부터 릴레이로 이동하는데 skew + "confirmationTolerance"+ Δmax 시간 이상을 소요한다면, 릴레이는 메시지 브로커 또는 해당 ISP와 SLA 분쟁을 제기해야한다).
계약의 모든 이해관계자는 또한, 뷰가 올바른 도메인을 통해 전송되는지를 체크한다. 실행을 위해, 입력 계약이 도메인에 상주하지 않을 수 있다. 이것은 정상적인 동작하에서 즉, 악의 없이도 발생할 수 있다. 이러한 체크가 실패하면 분쟁이 발생하지 않는다. 대신 이해관계자는 거부를 전송하며, 이는 도메인 변경 프로토콜에서와 같이 계약의 현재 거주지를 포함한다.
도메인 변경과의 상호작용(Interplay with domain changes)
원자성은 다중 도메인 트랜잭션의 릴레이들에 부담을 주는데, 왜냐하면 이들은 확인이 적시에 포워딩됨을 적극적으로 보장해야하기 때문이다. 따라서, 참가자(811, 819)는 임의의 다중 도메인 트랜잭션에서 릴레이 역할을 하지 않기를 원할 수 있다. 참가자가 단일 도메인에만 연결되어 있지 않으면 이를 보장할 수 없다.
신원 관리자 및 다중 도메인들(Identity manager and multiple domains)
하나 이상의 신원 관리자 노드들(170, 270)이 제공될 수 있으며, 일부 예에서 서로 다른 도메인들은 각각의 신원 관리자들(170, 270)을 갖는다. 신원 관리자 노드들(및 일반적으로 신원 관리 시스템)는 동기화 시스템과 동일한 신뢰도 및 토폴로지를 가질 수 있다. 참가자가 도메인 운영자로부터 권한을 획득하는 한, 임의의 노드에 의해 도메인이 생성될 수 있고 임의의 참가자 노드가 임의의 도메인에 연결할 수 있도록 시스템이 구성될 수 있다. 즉, 시스템에는 단일 글로벌 신원 관리자가 없거나 필요하지 않다.
각 참가자 노드(110, 120, 210, 220, 811, 815, 819), 외부 노드(130, 230, 813, 817) 및/또는 중재자(280)는 IPS 클라이언트(Identity Providing Service Client)라 지칭되는 로컬 컴포넌트를 가질 수 있다. IPS 클라이언트는 도메인(및/또는 참가자)의 신원 정보를 판독 및 검증하기 위해 도메인의 신원 관리자(170, 270)와 연결을 설정한다. IPS 클라이언트는 도메인 토폴로지 정보 및 하나 이상의 도메인의 신원 관리자(170, 270)에 의해 제공되는 공개 키에 대한 집계된 액세스를 제공하는 판독(read) API를 노출한다.
신원 관리자(170, 270)는 참가자 노드들 또는 다른 도메인 엔티티들의 IPS 클라이언트에 정보를 제시하기 전에, 일부 프로세스를 통해 키 및 인증서를 수신하고 정당성을 평가한다. IPS 클라이언트는 정보를 검증한다. IPS 클라이언트 read API의 로컬 소비자들은 제공된 정보를 정당성을 검증함이 없이 신뢰하며, 이는 동기화 및 신원 관리가 분리되게 한다다.
신원 관리자(170, 270) 및 IPS 클라이언트는 다음의 고려 사항들 중 하나 이상과 함께 설계될 수 있다.
● 참가자들에 대한 당사자들의 매핑. 특정 시간에 상태를 쿼리하고 그리고 알려진 당사자 식별자를 참가자 집합에 연결하고 로컬 참가자를 호스트된 당사자 집합에 연결하는 업데이트 스트림을 구독한다. 참가자 집합에 매핑하면 여러 참가자들을 사용하는 당사자들에 대한 높은 수준의 요구 사항을 충족한다.
● 참가자 자격(Participant Qualification). 특정 시간에 상태를 쿼리하고 그리고 신뢰할 수 없음(신뢰 레벨 0) 또는 신뢰할 수 있음(신뢰 레벨 1)을 나타내는 참가자의 신뢰 레벨에 대해 알려주는 업데이트 스트림을 구독한다.
● 참가자 관계 자격(Participant Relationship Qualification). 참가자 관계에 대한 당사자는 자격이 있으며 제출(확인 포함), 확인 및 준수(observation)(읽기 전용)로 제한된다. 이것은 또한 읽기 전용 참가자에 대한 높은 수준의 요구 사항을 충족한다.
● 키에 대한 참가자의 도메인 인식 매핑(Domain aware mapping of Participants to Keys). 특정 시간에 상태를 쿼리하고 그리고 참가자를 동기화 도메인 당 키 집합에 매핑하는 업데이트 스트림을 구독한다.
● 도메인 엔티티 키. 현재 상태를 쿼리하고 도메인 엔티티들의 키에 대한 업데이트 스트림을 구독한다.
● 키의 수명과 목적(Lifetime and Purpose of Keys). 무엇을 위해 사용될 수 있는지, 어떤 암호화 프로토콜을 참조하는지 및 언제 만료되는지에 대해 임의의 수신된 키에 대해 알아본다.
● 서명 체킹(Signature Checking). IPS 및 서명으로부터 획득된 키인 블롭(blob)이 주어지면, 해당 서명이 특정 시간에 각각의 키로 서명된 상기 주어진 블롭(blob)에 대한 유효한 서명인지 확인한다.
● 불변성(Immutability). 참가자 또는 도메인 엔티티 로그를 감사하는데 사용될 수 있도록 감사 로그들(audit mogs)과 동일한 시간 경계 내에 보존되는 모든 키들의 히스토리이다.
● 증거(Evidence). 신원 관리자로부터 수신한 모든 데이터에 대해 법적 분쟁에서 주장을 증명할 수 있는 관련 증거들의 세트를 가져온다. 관련 증거에는 불투명 블롭(opaque blob)의 정의에 대한 문서를 읽는데 사용할 수 있는 설명자가 포함되어 있다.
● 레이스 조건 무료(Race Condition Free). 인-플라이트(in-flight) 키 변경으로 인한 트랜잭션의 유효성에 불일치가 없도록 트랜잭션에 대한 키의 유효성에 대한 확실성을 확인한다.
● 당사자 쿼리(Querying for Parties). 불투명 한 쿼리 문(opaque query statement), 당사자에 대한 신원 관리자를 이용하여 쿼리하고 그리고 특정 참가자 노드들/IPS 클라이언트에 알려지지 않은 프라이버시 정책에 기초하여 결과를 수신할 것이다.
● 당사자 메타 데이터(Party metadata). 디스플레이 목적으로 당사자와 관련된 메타데이터에 액세스한다.
● 동등한 신뢰 가정(Equivalent Trust Assumptions). 참조 신원 관리 서비스의 연합 프로토콜(federation protocol)은 둘의 능력들 사이에서 미스매치가 없도록 상호운용성 프로토콜(interoperability protocol)과 동등한 신뢰 가정을 기반으로 할 필요가 있다.
신원 관리자 시스템은 다음과 같은 추가 고려사항으로 구성될 수 있다. 동기화 프로토콜은 신원(identity) 프로토콜과 별개이다. 하지만, 동기화 프로토콜의 결합성 속성들(composability properties)을 활용하기 위하여, 동등한 접근 방식이 신원들에 대해 요구된다. 따라서, 어떤 상황에서는 동기화를 위해 의존될 수 있는 글로벌하게 신뢰되는 단일 엔티티가 없다는 점을 감안할 때, 마찬가지로 일부 상황에서는 글로벌하게 신뢰되는 단일 엔티티가 신원들을 구축하는 것이 불가능하며, 이는 제 1 원칙을 유도한다:
글로벌 동기화가 실제로 작동하기 위해서는, 단일 트러스트 앵커(single trust anchor)가 있을 수 없다.
공개 키의 핑거프린트를 통해 암호화 키 쌍을 고유하게 식별할 수 있다. 연관된 프라이빗 키를 소유함으로써, 엔티티는 엔티티가 공개 키의 소유자임을 서명을 통해 항상 명확하게 증명할 수 있다. 이러한 원칙은 시스템에서 참가자들의 활동을 검증 및 승인하는데 사용된다. 따라서 우리는 제 2 원칙을 소개할 수 있다:
참가자는 권한을 부여할 수 있고 그의 권한이 검증될 수 있는 사람이다(알려진 키를 가진 사람에 의해).
즉, 참가자는 하나의 키 또는 함께 속하는 것으로 알려진 일련의 키들을 갖는 엔티티/노드이다. 그러나 이것이 반드시 키 소유자에 대한 지식과 동일하지는 않는다. 소유권은 현실 세계의 추상적인 측면이며 동기화 자체와는 관련이 없다. 실제 소유권은 일부 공유 데이터의 의미 해석에만 관련이 있으며 데이터 프로세싱 자체에는 관련이 없다. 이것은 제 3 원칙을 유도한다:
시스템 신원들과 법적 신원들의 별도 인증(또는 암호화 신원과 메타데이터의 분리)
암호화 키는 일부 소유권 또는 일부 사실이 다른 키와 연관될 수 있음을 증명하는 인증서에 키 서명을 함으로써 신뢰 체인을 구축하는데 사용될 수 있다. 하지만, 이러한 체인의 루트에는 항상 루트 키가 있다. 루트 키 자체는 인증되지 않았으며 법적 소유권이 검증될 수 없다. 참가자는 이를 믿기만 하면된다. 예를 들어, 엔터티가 엔터티 디바이스 상의 로컬 인증서 저장소를 보면, 소정의 루트가 유명한(named) 인증 기관에 의해 소유되고 있음을 신뢰할 필요가 있다. 이러한 신뢰는 합법적인 키만이 포함된 운영 시스템 공급자에 대한 신뢰에 뿌리를 두고 있다.
이와 같이, 인증서를 통한 법적 신원들과 암호화 키들 사이의 모든 링크들은 루트 키를 제어하는 엔티티가 정직하고 신뢰 루트에 연결된 모든 사람이 적절하게 조사되었음을 보장한다는 믿음에 기반한다. 따라서 엔티티는 법적 신원이 적절하게 연관되어 있다고 믿어야 할 수도 있지만, 절대적인 의미에서 이를 검증하는 것은 매우 어렵고 특히 온라인에서는 불가능하다.
또 다른 관련 양상은 신원 요구 사항이 비대칭 속성이라는 것이다. 대기업은 이름(BANK)으로 알려지기를 원하지만, 개인은 보다 폐쇄적인 경향이 있으며 실제로 필요한 경우에만 신원이 공개되기를 원한다(GDPR, HIPAA, 기밀 정보, 은행 기밀). 또한, 무기명 채권(bearer bond)을 살펴보면, 소유자는 채무자의 신원에 훨씬 더 많은 관심을 가지고 있다(채무자가 소유주에 대해 갖는 것 보다). 채무자가 나쁘거나 사기로 판명되면, 소유자는 돈과 투자를 잃을 수 있다. 이와 반대로, 채무자는 몇 가지 규제 이유를 제외하고는 그가 누구에게 채권을 갚아야하는지 신경 쓰지 않는다. 따라서 우리는 제 4 원칙을 결론지었다.
원장 상의 신원들은 비대칭적인 문제이며, 프라이버시와 공공성(publicity)은 사례별로 신중하게 가중치를 부여받아야 한다.
글로벌하게 구성가능한 신원 시스템(global composable identity system)을 구축하기 위해, 신원 체계(identity scheme)는 글로벌하게 고유한 식별자를 생성해야한다. 이것은 글로벌 시스템이 연합(federation)을 회피할 수 있게하는바, 연합은 신원 제공자들 간의 협력 또는 모든 참가자 간의 합의를 필요로 하며 그리고 동기화 프로토콜과 통합하기 어렵다.
우리는 일부 암호화 체계의 공개/개인 키 쌍을 참조하기 위해
Figure pct00002
를 사용할 것이다. 여기서, 위 첨자 x는 키 사용의 컨텍스트를 제공할 것이며, 아래 첨자 k는 키를 구별하는데 사용될 것이다.
이하에서는 키 쌍(pk, sk)을 참조하기 위해, 공개 키의 핑거프린트
Figure pct00003
를 사용할 것이다. 이를 바탕으로, 이하에서 신원 루트 키 쌍(identity root key pair)으로서 Ik, resp.(pk, sk) 를 사용할 것이다. 여러 개가 있을 수 있으며 우리는 그러한 키의 소유자가 누구인지에 대해 어떠한 진술도 하지 않는다.
이제, 우리는 튜플(X, Ik)로서 글로벌하게 고유한 식별자를 도입하며, 여기서 Ik 는 이전에 도입된 신원 루트 키의 핑거프린트를 참조하고 X는 원칙적으로 우리가 동등성을 확인할 수 있는 추상적인 식별자이다. 따라서, 만약 X = Y 이고 Ik = Il 라면, (X, Ik) = (Y, Il) 이다. 식별자는 정의에 따라 글로벌하게 고유하다. 두 식별자가 충돌하는 경우 정의에 따라 동등하도록 정의했으므로 충돌이 있을 수 없다. 따라서, 신원 키 lk 는 네임스페이스에 걸쳐 있으며, 그의 네임 스페이스에서 정의상 충돌이 없음을 보장한다.
프로젝트 내의 고유 식별자는 스칼라 코드(Scala code)의 한 예에서 다음과 같이 정의된다:
/** A namespace spanned by the fingerprint of a pub-key
*
* This is based on the assumption that the fingerprint is unique to the public-key */
final case class Namespace(fingerprint: Fingerprint)
/** a unique identifier within a namespace */
final case class UniqueIdentifier(id: Identifier, namespace: Namespace) {
우리는 참가자 노드들 N=(N,Ik), 당사자들 P=(P,Ik), 및 도메인 엔티티들D=(D,Ik)(이는, X는 (X,Ik)의 약자임을 의미한다)을 식별하기 위해, 글로벌 고유 식별자를 사용할 것이다. 당사자들 P와 참가자 노드들 N의 경우, 프라이버시 때문에 우리는 충분히 긴 랜덤 넘버를 사용해야한다. 도메인 D의 경우, 우리가 읽을 수 있는 이름을 사용한다.
대안적인 도메인 구성(들)
앞선 개시 내용은 각 도메인이 그 도메인 내에서 또는 그 도메인에 걸쳐서 트랜잭션을 수행하기 위한 컴포넌트 세트를 포함할 수 있음을 설명한다. 예를 들어, 도메인은 참가자 노드들(예컨대, 노드 110, 120, 210, 220, 811, 815, 819)에 의해 제출된 트랜잭션을 오더링하기 위한 시퀀서 또는 외부 노드(예컨대, 노드 130, 230, 813, 817, 1018) 및 도메인 내에서 확인들의 충실도를 집계하고 보장하기 위한 중재자 노드(280) 포함할 수 있다. 도메인에 대한 대안적인 구성이 가능하고 본 개시 내용에 의해 고려된다는 것이 이해되어야 한다.
일부 예들에서, 중재자 노드(280)의 기능은 위에서 설명된 것들에 대한 대안으로 구현될 수 있다. 한 예에서, 중재자 노드의 기능은 복제 서버의 내결함성 서비스(fault-tolerant service)에 의해 복제된다(예컨대, 비잔틴 내결함성 상태 머신 복제 사용). 다른 예에서, 중재자 노드의 기능은 더 강력한 프라이버시 및 기밀성을 제공하기 위해 하나 이상의 노드에 있는 소트트웨어 가드 연장(SGX: Software Guard Extension) 엔클레이브(enclave) 내에서 실행될 수 있다. 일부 예에서, 이러한 엔클레이브는 외부 노드와 연관될 수 있다.
본 개시는 각각의 도메인 또는 도메인들의 서브세트가 자신의 합의 프로토콜을 실행하는 분산 시스템(예를 들어, 블록 체인)을 포함할 수 있음을 고려한다. 이 경우, 트랜잭션을 오더링하기 위해 시퀀서 또는 외부 노드(예컨대, 노드 130, 230, 813, 817, 1018)에 의존하는 대신에, 도메인의 참가자 노드들(예컨대, 노드 110, 120, 210, 220, 811, 815, 819)는 그 도메인에 제출된 트랜잭션들을 오더링 및/또는 검증하기 위하여 분산 시스템(예컨대,블록 체인)의 트랜잭션 오더링 프로토콜에 의존할 수 있다. 또한, 앞서 언급한 바와 같이, 트랜잭션은 상이한 도메인들에서 발생하거나 또는 도메인들에 걸쳐서 발생할 수 있다(예컨대, 다중 도메인 트랜잭션). 따라서, 여기에 개시된 동기화 프로토콜은 상이한 분산 시스템들(예를 들어, 블록 체인들)에 걸쳐 가상 원장을 동기화하는데 사용될 수 있다. 그런 의미에서, 여기에 개시된 동기화 프로토콜은 서로 다른 분산 시스템을 동기화하는 방식으로 구성될 수 있으며, 각각 자신의 합의 및/또는 트랜잭션 오더링 프로토콜을 실행하는 서로 다른 분산 시스템들의 웹을 형성할 수 있다.
특히, 그러한 일례들은 다른 도메인들과 시스템들 간의 단순한 상호운용성(interoperability) 이상이다. 도메인의 도메인 인프라스트럭처가 스왑되거나 변경될 수 있도록, 그리고 도메인(들)의 상이한 구현예들이 연결될 수 있도록, 트랜잭션 프로토콜이 가상 원장을 형성하기 위해 동일하게 유지될 수 있다.
일례로, 전술한 분산 시스템의 합의(consensus) 프로토콜은 비잔틴 내결함성 프로토콜(예컨대, BFT, PBFT, aBFT 등)일 수 있으며, 이것은 작업 증명(POW: proof of work) 또는 지분 증명(POS: proof of stake)에서와 같이 시빌-저항 피처(sybil-resistance features)와 함께 사용되는 합의 프로토콜일 수 있거나, 또는 당업계에서 인정되는 또 다른 합의 프로토콜 일 수 있다. 이와 같이, 여기에 개시된 동기화 프로토콜은 다른 분산 시스템(예를 들어, 블록 체인)과 함께 작동하여 서로 다른 분산 시스템들 사이에서 트랜잭션을 동기화하고 서로 다른 분산 시스템들의 가상 원장을 형성할 수 있다는 것이 고려된다.

Claims (62)

  1. 다수 참가자 프로세스를 스케줄링하고 검증하는 방법으로서,
    다수 참가자 프로세스의 참가자와 연관된 제출 노드에 의해서, 암호로 보호된(cryptographically-protected) 메시지를 하나 이상의 수신 노드들로 전송함으로써 제안된 트랜잭션을 제출하는 단계, 상기 암호로 보호된 메시지는 외부 노드에 의해 판독가능한 비암호화된(unencrypted) 서브메시지 및 적어도 외부 노드로부터 프라이버시를 보호하기 위한 암호로 보호된 서브메시지를 적어도 포함하며;
    상기 외부 노드에 의해서, 다른 트랜잭션들에 대한 제안된 트랜잭션의 순서를 결정하는 단계;
    적어도 일부 수신 노드들을 통해, 암호로 보호된 메시지를 검증하는 단계;
    적어도 일부 수신 노드들로부터, 암호로 보호된 메시지의 유효성에 대한 확인을 수신하는 단계;
    확인 조건을 충족하는 하나 이상의 확인들을 적어도 일부 수신 노드들로부터 수신함에 기초하여, 상기 제안된 트랜잭션을 확인된 트랜잭션으로서 파이널라이징하는 단계; 및
    상기 외부 노드에 의해 결정된 순서에 따라, 상기 확인된 트랜잭션을 분산 원장에 기록하는 단계
    를 포함하는 것을 특징으로 하는 방법.
  2. 제1항에 있어서,
    상기 하나 이상의 수신 노드들은 적어도 제 1 수신 노드 및 제 2 수신 노드를 포함하고, 상기 암호로 보호된 서브메시지는 상기 제 1 수신 노드에 의해 판독가능하지만 상기 제 2 수신 노드에 의해 판독되지 않는 것을 특징으로 하는 방법.
  3. 제2항에 있어서,
    상기 제 1 수신 노드는 상기 암호로 보호된 서브메시지를 복호화하기 위한 복호화 키에 액세스할 수 있지만, 상기 제 2 수신 노드는 그렇지 않은 것을 특징으로 하는 방법.
  4. 제1항에 있어서,
    상기 암호로 보호된 메시지는 상기 외부 노드로 전송되고, 상기 외부 노드는 상기 암호로 보호된 메시지를 하나 이상의 수신 노드들로 전송하는 것을 특징으로 하는 방법.
  5. 선행하는 청구항들 중 어느 한 항에 있어서,
    상기 하나 이상의 수신 노드들은 자신의 신원을 다른 수신 노드들로부터 숨기기 위해 가명 주소를 사용하는 것을 특징으로 하는 방법.
  6. 제5항에 있어서,
    상기 제출 노드들과 가명 주소, 그리고 상기 하나 이상의 수신 노드들과 가명 주소 사이의 연관성들을 유지하는 신원 관리자를 더 포함하는 것을 특징으로 하는 방법.
  7. 선행하는 청구항들 중 어느 한 항에 있어서,
    암호로 보호된 메시지의 유효성을 결정하는 단계는 비암호화된(unencrypted) 서브메시지에 기초하는 것을 특징으로 하는 방법.
  8. 제7항에 있어서,
    상기 비암호화된 서브메시지에 기초하여 상기 암호로 보호된 메시지의 유효성을 결정하는 단계는, 상기 제안된 트랜잭션의 트랜잭션 시간이 상기 외부 노드에 의해 제공된 타임스탬프의 윈도우 내에 있는지를 결정하는 단계를 포함하는 것을 특징으로 하는 방법.
  9. 제8항에 있어서,
    상기 제안된 트랜잭션의 트랜잭션 시간은 타임스탬프들의 범위(range)인 것을 특징으로 하는 방법.
  10. 선행하는 청구항들 중 어느 한 항에 있어서,
    상기 암호로 보호된 메시지의 유효성을 결정하는 단계는 암호로 보호된 서브메시지에 기초하는 것을 특징으로 하는 방법.
  11. 제10항에 있어서,
    암호로 보호된 서브메시지에 기초하여 상기 암호로 보호된 메시지의 유효성을 결정하는 단계는, 제안된 트랜잭션이 이전 트랜잭션과 충돌하는지 여부를 식별하는 단계를 포함하는 것을 특징으로 하는 방법.
  12. 제10항 또는 제11항에 있어서,
    암호화된 서브메시지에 기초하여 상기 암호로 보호된 메시지의 유효성을 결정하는 단계는 제안된 트랜잭션이 양호하게 적격(well-formed)인지의 여부를 결정하는 단계를 포함하는 것을 특징으로 하는 방법.
  13. 제10항 내지 제12항 중 어느 한 항에 있어서,
    암호로 보호된 서브메시지에 기초하여 상기 암호로 보호된 메시지의 유효성을 결정하는 단계는, 제안된 트랜잭션이 일련의 적합성 규칙들(conformance rules)을 따르는지를 결정하는 단계를 포함하는 것을 특징으로 하는 방법.
  14. 제11항에 있어서,
    제안된 트랜잭션이 이전 트랜잭션과 충돌하는지 여부를 식별하는 단계는, 이전 트랜잭션이 분산 원장에 기록되었는지를 체크하는 단계를 포함하는 것을 특징으로 하는 방법.
  15. 선행하는 청구항들 중 어느 한 항에 있어서,
    상기 암호로 보호된 메시지의 유효성을 결정하는 단계는 비암호화된 서브메시지 및 암호로 보호된 서브메시지에 기초하는 것을 특징으로 하는 방법.
  16. 제15항에 있어서,
    상기 유효성을 결정하는 단계는, 상기 비암호된 서브메시지가 상기 암호로 보호된 서브메시지와 일치하는지를 결정하는 단계를 포함하는 것을 특징으로 하는 방법.
  17. 선행하는 청구항들 중 어느 한 항에 있어서,
    상기 확인 조건은,
    다수 참가자 프로세스의 참가자에 대응하는 각각의 수신 노드로부터 확인을 수신하는 것;
    할당된 기간 내에 특정 분량의 확인들을 수신하는 것;
    하나 이상의 수신 노드들의 특정된 서브세트로부터 확인들을 수신하는 것; 또는
    암호화 증명자(cryptographic prover) 또는 신뢰할 수 있는 하드웨어와 같은 검증가능한 증명 메커니즘으로부터 확인을 수신하는 것
    중 하나 이상인 것을 특징으로 하는 방법.
  18. 선행하는 청구항들 중 어느 한 항에 있어서,
    심판 노드(referee node)를 더 포함하며, 상기 심판 노드는 상기 하나 이상의 수신 노드들이 각각의 수신 노드에 대해 예상되는 액션에 따라 행동하지 않는지를 결정하는 것을 특징으로 하는 방법.
  19. 제18항에 있어서,
    상기 심판 노드는,
    제안된 트랜잭션의 형식이 적격인지의(well-formed) 여부;
    하나 이상의 수신 노드들에 의해 제공된 확인이 하나 이상의 다른 확인들과 충돌하는지 여부; 및
    제안된 트랜잭션이 용량 약속 소진(capacity promise exhaustion)을 잘못 표시하는지 여부
    중 하나 이상을 결정하는 것을 특징으로 하는 방법.
  20. 제18항에 있어서,
    상기 심판 노드가 분쟁 해결 프로세스를 수행하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  21. 제19항에 있어서,
    상기 제안된 트랜잭션이 적격인지를 결정하는 단계는,
    제안된 트랜잭션이 적합성 규칙들(conformance rules)을 준수하는지;
    제안된 트랜잭션이 하나 이상의 수신 노드들의 필수 서브 세트에 의해 승인되는지; 및
    제안된 트랜잭션이 리소스 요건들에 대한 올바른 선언을 갖고있는지
    중 하나 이상을 체크하는 단계를 포함하는 것을 특징으로 하는 방법.
  22. 제18항 내지 제21항 중 어느 한 항에 있어서,
    상기 하나 이상의 수신 노드들 중 제 1 노드는 제안된 트랜잭션을 심판 노드에 전달하여 분쟁 해결 프로세스를 개시하는 것을 특징으로 하는 방법.
  23. 제22항에 있어서,
    상기 분쟁 해결 프로세스는 상기 제출 노드 또는 상기 하나 이상의 수신 노드들로부터 결정된 부정행위 노드(misbehaving node)에 처벌을 부과하는 심판 노드에 의해서 해결되는 것을 특징으로 하는 방법.
  24. 제23항에 있어서,
    상기 처벌은,
    부정행위 노드의 트랜잭션을 제출하는 기능을 제거하는 것;
    부정행위 노드와 관련된 제안된 트랜잭션을 동결된 것으로 플래그하는 것;
    심판 노드에 의해 결정된 부정행위 노드에 대한 맞춤 처벌;
    도메인 규칙에 정의된 부정행위 노드에 대한 처벌
    중 하나 이상인 것을 특징으로 하는 방법.
  25. 제22항 내지 제24항 중 어느 한 항에 있어서,
    심판 노드는 분쟁 해결 프로세스의 결과를 제출 노드 및/또는 제 1 수신 노드에 전달하는 것을 특징으로 하는 방법.
  26. 제22항 내지 제25항 중 어느 한 항에 있어서,
    분쟁 해결 프로세스는 도메인 규칙에서 정의되는 것을 특징으로 하는 방법.
  27. 제22항 내지 제26항 중 어느 한 항에 있어서,
    상기 제 1 수신 노드 이외의 다른 수신 노드들이, 분쟁 해결 프로세스에 대한 증거로서 하나 이상의 메시지를 상기 심판 노드에 제공하는 것을 특징으로 하는 방법.
  28. 선행하는 청구항들 중 어느 한 항에 있어서,
    제안된 트랜잭션의 순서를 결정하는 단계는 비암호된 서브메시지에 기초하는 것을 특징으로 하는 방법.
  29. 제28항에 있어서,
    상기 제안된 트랜잭션에는, 상기 암호로 보호된 메시지가 상기 외부 노드에 의해 수신된 시간에 대응하는 물리적 타임스탬프가 제공되는 것을 특징으로 하는 방법.
  30. 제29항에 있어서,
    다른 트랜잭션들에 대한 제안된 트랜잭션의 순서는 물리적 타임스탬프에 기초하는 것을 특징으로 하는 방법.
  31. 선행하는 청구항들 중 어느 한 항에 있어서,
    제안된 트랜잭션의 순서는, 상기 제안된 트랜잭션에 할당된 논리적 타임스탬프에 기초하는 것을 특징으로 하는 방법.
  32. 제29항 내지 제30항 중 어느 한 항을 인용하는 제31항에 있어서,
    상기 논리적 타임스탬프는 상기 물리적 타임스탬프의 정의된 시간 윈도우 내의 시간에 대응하는 것을 특징으로 하는 방법.
  33. 선행하는 청구항들 중 어느 한 항에 있어서,
    상기 암호로 보호된 서브메시지는 암호화된 서브메시지인 것을 특징으로 하는 방법.
  34. 다수 참가자 프로세스를 스케줄링하고 검증하는 방법으로서,
    다수 참가자 프로세스에서 참가자와 연관된 제출 노드에 의해서, 암호로 보호된(cryptographically-protected) 메시지를 하나 이상의 수신 노드들로 전송함으로써 제안된 트랜잭션을 제출하는 단계, 상기 암호로 보호된 메시지는 외부 노드에 의해 판독가능한 비암호화된(unencrypted) 서브메시지 및 적어도 외부 노드로부터 프라이버시를 보호하기 위한 암호로 보호된 서브메시지를 적어도 포함하며;
    상기 외부 노드에 의해, 다른 트랜잭션들에 대한 제안된 트랜잭션의 순서를 결정하는 단계;
    상기 외부 노드에 의해, 비암호화된 서브메시지에 기초하여 다수 참가자 프로세스에서 참가자와 연관된 하나 이상의 수신 노드들을 결정하는 단계;
    상기 외부 노드에 의해, 적어도 암호로 보호된 서브메시지를 상기 하나 이상의 수신 노드로 전송하는 단계;
    상기 하나 이상의 수신 노드들에 의해, 암호로 보호된 서브메시지의 유효성을 결정하는 단계;
    상기 외부 노드에 의해, 암호로 보호된 서브메시지의 유효성에 대한 확인을 상기 하나 이상의 수신 노드들로부터 수신하는 단계;
    상기 외부 노드에 의해, 확인을 수신해야만 하는 하나 이상의 노드들을 결정하는 단계;
    상기 외부 노드에 의해, 하나 이상의 노드에 확인을 전송하는 단계;
    상기 제출 노드에 의해, 상기 하나 이상의 수신 노드들에 의해 제공된 확인들이 확인 조건을 충족하는지 여부에 기초하여 제안된 트랜잭션을 확인된 트랜잭션으로서 파이널라이징하는 단계; 및
    상기 제출 노드에 의해, 상기 외부 노드에 의해 결정된 순서에 따라 상기 확인된 트랜잭션을 분산 원장에 기록하는 단계
    를 포함하는 것을 특징으로 하는 방법.
  35. 선행하는 청구항들 중 어느 한 항에 있어서,
    중재자 노드에 의해, 상기 하나 이상의 수신 노드들에 의해 제공된 확인들을 수신하고 집계하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  36. 제35항에 있어서,
    확인들의 집계를 저장하는 단계;
    확인들의 집계를 다른 노드로 전송하는 단계; 및
    확인들의 집계를 기반으로 제안된 트랜잭션을 확인하는 단계
    중 하나 이상을 더 포함하는 것을 특징으로 하는 방법.
  37. 프로그램 명령들을 포함하는 비일시적, 유형의, 컴퓨터 판독가능 매체로서, 상기 프로그램 명령들은 실행될 때, 노드 또는 일련의 관련 노드들로 하여금 선행하는 청구항들 중 어느 한 항의 방법을 수행하게 하는 것을 특징으로 하는 컴퓨터 판독가능 매체.
  38. 다수 참가자 프로세스에서 트랜잭션 또는 일련의 트랜잭션들을 스케줄링하고 검증하는 방법으로서,
    부분적으로 암호화된 메시지를 다수 참가자 프로세스의 참가자와 관련된 하나 이상의 수신 노드들에게 적어도 전송함으로써 제안된 트랜잭션을 제출하는 단계, 상기 부분적으로 암호화된 메시지는 외부 노드에 의해 판독가능한 비암호화된(unencrypted) 서브메시지 및 적어도 외부 노드로부터 프라이버시를 보호하기 위한 암호화된 서브메시지를 적어도 포함하며;
    부분적으로 암호화된 메시지의 유효성에 대한 확인을 수신 노드로부터 수신하는 단계;
    확인 조건을 만족하는 하나 이상의 확인들을 적어도 일부 수신 노드들로부터 수신함에 기초하여, 제안된 트랜잭션을 확인된 트랜잭션으로서 파이널라이징하는 단계;
    다른 트랜잭션들에 대한 확인된 트랜잭션의 순서를 외부 노드로부터 수신하는 단계; 및
    외부 노드에 의해 결정된 순서에 따라 확인된 트랜잭션을 원장에 기록하는 단계
    를 포함하는 것을 특징으로 하는 방법.
  39. 제38항에 있어서,
    상기 하나 이상의 수신 노드들은 제 1 수신 노드와 제 2 수신 노드를 적어도 포함하고, 상기 방법은 암호화된 서브메시지를 상기 제 1 수신 노드에 전송하는 단계를 더 포함하고, 상기 암호화된 서브메시지는 상기 제 1 수신 노드에 의해 제어되지만 상기 제 2 수신 노드에 의해 제어되지 않는 복호화 키에 의해서 복호화될 수 있는 것을 특징으로 하는 방법.
  40. 제39항에 있어서,
    상기 암호화된 서브메시지는 상기 제 2 수신 노드로 전송되지 않는 것을 특징으로 하는 방법.
  41. 제38항 내지 제40항 중 어느 한 항에 있어서,
    각각의 수신 노드의 가명 주소를 결정하는 단계를 더 포함하고, 각각의 가명 주소는 다른 수신 노드들로부터 각각의 수신 노드의 신원을 숨기기 위해 사용되는 것을 특징으로 하는 방법.
  42. 프로그램 명령들을 포함하는 비일시적, 유형의, 컴퓨터 판독가능 매체로서, 상기 프로그램 명령들은 실행될 때, 제출 노드로 하여금 제38항 내지 제41항 중 어느 한 항의 방법을 수행하게 하는 것을 특징으로 하는 컴퓨터 판독가능 매체.
  43. 다수 참가자 프로세스에서 복수의 트랜잭션을 스케줄링하고 검증하는 방법으로서,
    노드 또는 일련의 관련 노드들을 통해:
    A. 다수 참가자 프로세스를 구성하는 복수의 트랜잭션들에 대응하는 복수의 메시지들의 순서를 결정하는 단계;
    B. 다수 참가자 프로세스의 참가자와 연관된 제출 노드로부터 부분적으로 암호화된 메시지를 포함하는 제안된 트랜잭션을 수신하는 단계, 상기 부분적으로 암호화된 메시지는 노드 또는 일련의 관련 노드들에 의해 판독가능한 적어도 하나의 비암호화된 서브메시지를 포함하고;
    C. 상기 비암호화된 서브메시지에 기초하여 다수 참가자 프로세스의 참가자와 연관된 수신 노드를 결정하는 단계;
    D. 상기 부분적으로 암호화된 메시지를 수신 노드로 전송하는 단계;
    E. 상기 부분적으로 암호화된 메시지의 유효성에 대한 확인을 수신 노드로부터 수신하는 단계; 및
    F. 제출 노드로 상기 확인을 전송하는 단계
    를 포함하는 것을 특징으로 하는 방법.
  44. 제42항에 있어서,
    상기 수신 노드의 가명 주소를 결정하는 단계를 더 포함하고, 상기 가명 주소는 다른 노드들로부터 상기 수신 노드의 신원을 숨기기 위해 사용되는 것을 특징으로 하는 방법.
  45. 프로그램 명령들을 포함하는 비일시적, 유형의, 컴퓨터 판독가능 매체로서, 상기 프로그램 명령들은 실행될 때, 노드 또는 일련의 관련 노드들로 하여금 제출 노드로 하여금 제42항 내지 제44항 중 어느 한 항의 방법을 수행하게 하는 것을 특징으로 하는 컴퓨터 판독가능 매체.
  46. 제1항 내지 제36항 중 어느 한 항에 있어서,
    분산 원장은 제출 노드, 외부 노드 및/또는 수신 노드들 사이의 메시지들을 기록하고, 분산 원장에 기록된 확인된 트랜잭션(들)은 기록된 메시지들을 포함하며, 이에 의해서 상기 외부 노드에 의해 결정된 순서가 상기 기록된 메시지들로부터 입증되거나 또는 도출될 수 있는 것을 특징으로 하는 방법.
  47. 제1항 내지 제36항 및 제46항 중 어느 한 항에 있어서,
    분산 원장은 복수의 개별 원장들을 포함하고, 각각의 개별 원장은 원장의 각각의 부분 사본(partial copy)을 유지하고, 상기 분산 원장은 복수의 개별 원장들의 부분 기록들로부터 구성되는 것을 특징으로 하는 방법.
  48. 제1항 내지 제36항 중 어느 한 항에 있어서,
    외부 노드와 관련된 제 1 도메인으로부터 타겟 외부 노드와 관련된 타겟 도메인으로의 상기 다수 참가자 프로세스의 변경을 더 포함하고, 상기 방법은,
    상기 제 1 도메인의 외부 노드에 의해서, 개시자 노드로부터 전송 요청을 수신하는 단계, 상기 전송 요청은 타겟 도메인 및 타겟 외부 노드를 지정하고;
    상기 제 1 도메인의 외부 노드에 의해서, 제안된 트랜잭션을 호스팅할 타겟 도메인 및 타겟 외부 노드의 유효성을 결정하는 단계를 포함하고,
    여기서, 타겟 도메인이 제안된 트랜잭션을 유효하게 호스팅할 수 있다고 결정함에 기초하여, 제안된 트랜잭션을 타겟 노드에서 스케줄링하고 검증하기 위한 승인을 개시자 노드에 전송하며, 제안된 트랜잭션의 순서를 결정하는 단계는 타겟 외부 노드에 의해 수행되는 것을 특징으로 하는 방법.
  49. 제48항에 있어서,
    제출 노드 및/또는 수신 노드에서 전송 요청을 수신하는 단계; 및
    제출 노드 및/또는 수신 노드에서 제안된 트랜잭션을 호스팅할 타겟 도메인 및 타겟 외부 노드의 유효성을 결정하는 단계를 더 포함하고,
    여기서, 타겟 도메인이 제안된 트랜잭션을 유효하게 호스팅할 수 있다고 결정함에 기초하여, 제안된 트랜잭션을 타겟 노드에서 스케줄링하고 검증하기 위한 승인을 개시자 노드에 전송하는 것을 특징으로 하는 방법.
  50. 제48항 또는 제49항에 있어서,
    개시자 노드에 대한 승인은 지정된 타임 아웃 조건과 연관되고, 상기 승인은 지정된 타임 아웃 조건에 기초하여 유효하거나 및/또는 독점적(exclusive)인 것을 특징으로 하는 방법.
  51. 다수 참가자 프로세스를 스케줄링하고 검증하는 방법으로서, 상기 방법은
    제 1 외부 노드, 제 1 수신 노드, 및 다수 참가자 프로세스의 참가자와 연관된 제출 노드와 연관된 제 1 도메인;
    제 2 외부 노드, 제 2 수신 노드, 및 제출 노드 또는 별도의 릴레이 노드와 연관된 제 2 도메인 -상기 제출 노드 또는 릴레이 노드는 제 1 외부 노드 및 제 2 노드 모두와 통신하며-; 와 관련되고,
    상기 방법은,
    - 제출 노드에 의해, 제 1 도메인에 대한 제 1 제안된 트랜잭션 및 제 2 도메인에 대한 제 2 제안된 트랜잭션을 결정하는 단계, 상기 제 1 및 제 2 제안된 트랜잭션들은 조합되어, 상기 제 1 및 제 2 수신 노드와 관련된 제안된 다수 참가자 트랜잭션을 형성하고,
    제 1 및 제 2 제안된 트랜잭션 각각은 각각의 수신 노드들에 대해 암호로 보호된 메시지를 포함하고, 상기 암호로 보호된 메시지는 적어도 각 도메인의 외부 노드에 의해 판독가능한 비암호화된 서브메시지 및 적어도 외부 노드로부터 프라이버시를 보호할 암호로 보호된 서브메시지를 포함하며;
    - 제출 노드 및/또는 릴레이 노드에 의해, 제 1 제안된 트랜잭션을 제 1 수신 노드에 제출하고 제 2 제안된 트랜잭션을 제 2 수신 노드에 제출하는 단계;
    - 제 1 외부 노드에 의해, 제 1 제안된 트랜잭션에 대한 제 1 순서를 결정하는 단계;
    -제 2 외부 노드에 의해, 제 2 제안된 트랜잭션에 대한 제 2 순서를 결정하는 단계;
    - 제 1 및 제 2 수신 노드들을 통해, 암호로 보호된 각각의 메시지를 검증하는 단계;
    - 제 1 및 제 2 수신 노드들로부터 암호로 보호된 메시지들의 유효성에 대한 확인을 수신하는 단계;
    - 확인 조건을 만족하는 확인들을 제 1 및 제 2 수신 노드들로부터 수신함에 기초하여, 확인된 제 1 트랜잭션와 확인된 제 2 트랜잭션의 조합으로서 상기 제안된 다수 참가자 트랜잭션을 파이널라이징하는 단계; 및
    - 제 1 순서에 따라 제 1 확인된 트랜잭션을 제 1 도메인과 관련된 분산 원장에 기록하고, 제 2 순서에 따라 제 2 확인된 트랜잭션을 제 2 도메인과 관련된 분산 원장에 기록하는 단계
    를 포함하는 것을 특징으로 하는 방법.
  52. 제51항에 있어서,
    상기 제출 노드는 상기 제 1 도메인과 상기 제 2 도메인 사이에서 메시지를 수신 및 송신하기 위한 중계자이고, 상기 방법은 또한,
    제출 노드 및/또는 릴레이 노드에 의해, 암호로 보호된 메시지의 유효성에 대한 확인을 제 1 수신 노드로부터 제 2 도메인의 제 2 외부 노드 및/또는 제 2 수신 노드로 전송하는 단계; 및
    제출 노드 및/또는 릴레이 노드에 의해, 암호로 보호된 메시지의 유효성에 대한 확인을 제 2 수신 노드로부터 제 1 도메인의 제 1 외부 노드 및/또는 제 1 수신 노드로 전송하는 단계
    를 더 포함하는 것을 특징으로 하는 방법.
  53. 제51항 또는 제52항에 있어서,
    제안된 다수 참가자 트랜잭션을 파이널라이징하기 위한 승인은, 지정된 타이밍 조건과 관련되고, 상기 승인은 지정된 타이밍 조건에 기초하여 유효하거나 및/또는 독점적인 것을 특징으로 하는 방법.
  54. 제38항 내지 제41항 중 어느 한 항에 있어서,
    제안된 트랜잭션은 다수의 도메인들에 걸쳐 제안된 다수 참가자 트랜잭션의 일부이고, 상기 방법은,
    제안된 다수 참가자 트랜잭션으로부터, 하나 이상의 수신 노드들 및 외부 노드를 포함하는 제 1 도메인에 대한 제 1 제안된 트랜잭션 및 하나 이상의 다른 수신 노드들 및 다른 외부 노드를 포함하는 다른 도메인에 대한 적어도 하나의 다른 제안된 트랜잭션을 결정하는 단계;
    상기 다른 도메인의 다수 참가자 프로세스의 참가자와 연관된 하나 이상의 다른 수신 노드들로 부분적으로 암호화된 다른 메시지를 적어도 전송함으로써 상기 다른 제안된 트랜잭션을 제출하는 단계, 상기 부분적으로 암호화된 다른 메시지는 상기 다른 외부 노드에 의해 판독가능한 비암호화된 서브메시지 및 적어도 상기 다른 외부 노드로부터 프라이버시를 보호하기 위한 암호화된 서브메시지를 적어도 포함하며;
    상기 하나 이상의 다른 수신 노드들로부터 상기 부분적으로 암호화된 다른 서브메시지의 유효성에 대한 다른 확인을 수신하는 단계;
    상기 제안된 트랜잭션을 파이널라이징하는 단계는, 확인 조건을 만족하는 다른 수신 노드들 중 적어도 일부로부터 하나 이상의 확인들을 수신하는 것에 기초하여, 다른 확인된 트랜잭션으로서, 상기 다른 제안된 트랜잭션을 파이널라이징하는 단계를 더 포함하고;
    다른 외부 노드로부터, 다른 도메인의 다른 트랜잭션들에 대한 상기 다른 확인된 트랜잭션의 순서를 수신하는 단계; 및
    상기 다른 외부 노드에 의해 결정된 순서에 따라, 상기 다른 확인된 트랜잭션을 원장 또는 다른 원장에 기록하는 단계
    를 더 포함하는 것을 특징으로 하는 방법.
  55. 제54항에 있어서,
    암호로 보호된 메시지의 유효성에 대한 확인을 제 1 도메인의 수신 노드로부터 다른 도메인의 다른 수신 노드로 전송하는 단계; 및
    암호화로 보호된 메시지의 유효성에 대한 다른 확인을 상기 다른 도메인의 다른 수신 노드로부터 제 1 도메인의 수신 노드로 전송하는 단계
    를 더 포함하는 것을 특징으로 하는 방법.
  56. 제54항 또는 제55항에 있어서,
    제안된 트랜잭션 및 다른 제안된 트랜잭션을 파이널라이징하기 위한 승인은 지정된 타이밍 조건과 관련되고, 상기 승인은 지정된 타이밍 조건에 기초하여 유효하거나 및/또는 독점적인 것을 특징으로 하는 방법.
  57. 제1항 내지 제36항, 제38항 내지 제41항, 및 제43항 내지 제56항 중 어느 한 항에 있어서,
    상기 암호화된 서브메시지는 제안된 트랜잭션에서 모든 예상된 확인들을 암호화적으로 검증하기 위한 예상 확인 데이터를 포함하고, 상기 방법은,
    수신된 하나 이상의 확인들 각각을 예상 확인 데이터로 암호화적으로 검증하기 위해 암호화 기능을 실행하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  58. 제57항에 있어서,
    상기 예상 확인 데이터는 공개 키(들)의 형태이고, 상기 예상 확인 데이터는은 공개 키(들)에 대응하는 개인 키를 갖는 전자 서명을 포함하는 것을 특징으로 하는 방법.
  59. 제1항 내지 제36항, 제38항 내지 제41항, 및 제43항 내지 제56항 중 어느 한 항에 있어서,
    제안된 트랜잭션은 복수의 서브 트랜잭션들을 포함하고, 복수의 서브 트랜잭션들 각각은 적어도 하나의 수신 노드와 관련되며, 각각의 서브 트랜잭션은 관련된 수신 노드에 의해 서브 트랜잭션에 대해 판독될 수 있지만 서브 트랜잭션에 관련되지 않는 수신 노드(들)에 의해서는 판독될 수 없는 개인 정보를 구비한 대응하는 암호로 보호되는 서브메시지와 연관되며, 그리고
    상기 암호로 보호된 서브메시지는 제안된 트랜잭션 내의 적어도 하나의 다른 서브 트랜잭션의 개인 정보를 적어도 부분적으로 나타내는 확인들을 검증하기 위한 개인 정보 검증 데이터를 포함하고, 상기 방법은,
    적어도 하나의 다른 서브 트랜잭션의 확인이 상기 개인 정보 검증 데이터와 대응하는지를 검증하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  60. 제59항에 있어서,
    상기 서브 트랜잭션의 확인은 상기 서브 트랜잭션의 개인 정보의 암호화 해시를 적어도 부분적으로 포함하는 것을 특징으로 하는 방법.
  61. 제60항에 있어서,
    상기 제안된 트랜잭션은 복수의 서브트리를 갖는 트리 구조를 가지며, 서브트리는 상기 복수의 서브 트랜잭션들 중 하나 이상을 포함하는 것을 특징으로 하는 방법.
  62. 제59항 내지 제61항 중 어느 한 항에 있어서,
    상기 암호화로 보호된 서브메시지는 제안된 트랜잭션의 복수의 서브 트랜잭션들의 확인들 중 어느 하나를 암호화적으로 검증하기 위한 개인 정보 검증 데이터를 포함하는 것을 특징으로 하는 방법.
KR1020217015034A 2018-10-19 2019-10-21 프라이버시 보호 유효성 검사 및 커밋 아키텍처 KR20210082194A (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862748327P 2018-10-19 2018-10-19
US201862748315P 2018-10-19 2018-10-19
US62/748,315 2018-10-19
US62/748,327 2018-10-19
PCT/US2019/057248 WO2020082078A1 (en) 2018-10-19 2019-10-21 Privacy preserving validation and commit architecture

Publications (1)

Publication Number Publication Date
KR20210082194A true KR20210082194A (ko) 2021-07-02

Family

ID=70279889

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020217015034A KR20210082194A (ko) 2018-10-19 2019-10-21 프라이버시 보호 유효성 검사 및 커밋 아키텍처

Country Status (9)

Country Link
US (2) US11575683B2 (ko)
EP (1) EP3857422A4 (ko)
JP (1) JP7487214B2 (ko)
KR (1) KR20210082194A (ko)
CN (1) CN113196270B (ko)
AU (1) AU2019362088A1 (ko)
CA (1) CA3116763C (ko)
SG (1) SG11202103877SA (ko)
WO (1) WO2020082078A1 (ko)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10805352B2 (en) 2017-04-21 2020-10-13 Netskope, Inc. Reducing latency in security enforcement by a network security system (NSS)
CN110428055A (zh) 2018-04-27 2019-11-08 阿里巴巴集团控股有限公司 量子计算方法和设备
CN108876560B (zh) 2018-07-18 2020-10-02 阿里巴巴集团控股有限公司 一种基于区块链对作品发布者进行信用评价的方法及装置
WO2020096996A2 (en) * 2018-11-05 2020-05-14 Tunnel International Inc. Methods, systems, and devices for concealing account balances in ledgers
CN109598149B (zh) * 2018-11-20 2020-04-07 阿里巴巴集团控股有限公司 业务处理的方法和装置
US11087179B2 (en) 2018-12-19 2021-08-10 Netskope, Inc. Multi-label classification of text documents
CN110046156A (zh) * 2018-12-20 2019-07-23 阿里巴巴集团控股有限公司 基于区块链的内容管理系统及方法、装置、电子设备
CN110046482A (zh) 2018-12-25 2019-07-23 阿里巴巴集团控股有限公司 身份核实方法及其系统
US11405365B2 (en) 2019-03-13 2022-08-02 Springcoin, Inc. Method and apparatus for effecting a data-based activity
US11374910B2 (en) * 2019-03-13 2022-06-28 Springcoin, Inc. Method and apparatus for effecting a data-based activity
US11329968B2 (en) * 2019-03-18 2022-05-10 Microsoft Technology Licensing, Llc Authentication across decentralized and centralized identities
KR102260093B1 (ko) * 2019-08-30 2021-06-02 연세대학교 산학협력단 내결함성 블록체인 네트워크의 신뢰도 기반 샤드 분배 장치 및 방법
CN110928534B (zh) * 2019-10-14 2021-11-09 上海唯链信息科技有限公司 一种基于区块链的工作流节点认证方法及装置
US11856022B2 (en) 2020-01-27 2023-12-26 Netskope, Inc. Metadata-based detection and prevention of phishing attacks
US11637817B2 (en) * 2020-03-12 2023-04-25 Springcoin, Inc. Method and apparatus for effecting a data-based activity
US20220100733A1 (en) * 2020-09-29 2022-03-31 International Business Machines Corporation Transaction reordering in blockchain
KR102462998B1 (ko) * 2020-12-30 2022-11-03 아주대학교산학협력단 Bft 합의 방식을 이용한 멀티 체인 간의 교차 인증 장치 및 방법
US20230015789A1 (en) * 2021-07-08 2023-01-19 Vmware, Inc. Aggregation of user authorizations from different providers in a hybrid cloud environment
CN114090376A (zh) * 2021-11-09 2022-02-25 中国银联股份有限公司 一种基于联盟链系统的业务处理方法及装置
CN114244788B (zh) * 2022-02-25 2022-06-03 广州锦行网络科技有限公司 数据的响应方法、装置以及系统
CN114553603B (zh) * 2022-04-25 2022-07-29 南湖实验室 一种基于隐私计算的新型数据可信解密的方法
CN115396087B (zh) * 2022-06-20 2024-04-30 中国联合网络通信集团有限公司 基于临时身份证书的身份认证方法、装置、设备及介质
CN115033908B (zh) * 2022-08-11 2022-10-21 西南石油大学 基于云存储的油气勘探细粒度密态数据的检索方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4151432B2 (ja) 2003-02-25 2008-09-17 株式会社日立製作所 Ｘｍｌ署名・暗号化手順生成システム
KR100549504B1 (ko) 2003-10-10 2006-02-03 한국전자통신연구원 서명 암호화를 이용한 웹서비스 보안에서의 ｓｏａｐ메시지 생성 및 검증 방법
JP2006164018A (ja) 2004-12-09 2006-06-22 Hitachi Ltd ＸＭＬ署名・暗号の処理方法、ＸＭＬ署名・暗号処理用プログラム、Ｗｅｂサービス用ノード装置、コンピュータプログラムの生成方法、プログラム、プログラミング装置、ＸＭＬ署名・暗号処理システム
US8307031B1 (en) * 2010-04-28 2012-11-06 Google Inc. Processing data requests using multiple request timers
CA3004263C (en) * 2014-03-18 2020-07-07 nChain Holdings Limited Virtual currency system
CA2986164C (en) * 2015-05-26 2021-11-30 T0.Com, Inc. Obfuscation of intent in transactions using cryptographic techniques
US9992028B2 (en) * 2015-11-26 2018-06-05 International Business Machines Corporation System, method, and computer program product for privacy-preserving transaction validation mechanisms for smart contracts that are included in a ledger
US10237259B2 (en) 2016-02-29 2019-03-19 Securekey Technologies Inc. Systems and methods for distributed identity verification
US10496976B2 (en) * 2016-03-01 2019-12-03 Wipro Limited Method and device for validating transactions pertaining to sharing of services in ad hoc network
US10529041B2 (en) * 2016-04-18 2020-01-07 Rs Ltd. System and method for managing transactions in dynamic digital documents
US10810583B2 (en) 2016-04-29 2020-10-20 Digital Asset Holdings Digital asset modeling
US11663609B2 (en) 2016-10-04 2023-05-30 International Business Machines Corporation Method and apparatus to enforce smart contract execution hierarchy on blockchain
US10708070B2 (en) * 2017-05-24 2020-07-07 Nxm Labs Canada Inc. System and method for utilizing connected devices to enable secure and anonymous electronic interaction in a decentralized manner
AU2019200933B1 (en) 2017-10-27 2019-05-23 Digital Asset (Switzerland) GmbH Computer system and method for distributed privacy-preserving shared execution of one or more processes
CN113609477A (zh) 2017-10-27 2021-11-05 数字资产(瑞士)股份有限公司 用于一个或多个进程的分布式隐私保护共享执行的计算机系统和方法
US10333902B1 (en) * 2017-12-19 2019-06-25 International Business Machines Corporation Data sanitization system for public host platform

Also Published As

Publication number Publication date
EP3857422A1 (en) 2021-08-04
JP2022508948A (ja) 2022-01-19
CN113196270B (zh) 2024-06-25
US20200128022A1 (en) 2020-04-23
EP3857422A4 (en) 2022-06-08
CA3116763A1 (en) 2020-04-23
CN113196270A (zh) 2021-07-30
SG11202103877SA (en) 2021-05-28
JP7487214B2 (ja) 2024-05-20
US11575683B2 (en) 2023-02-07
AU2019362088A1 (en) 2021-06-10
US20230231855A1 (en) 2023-07-20
CA3116763C (en) 2024-02-27
WO2020082078A1 (en) 2020-04-23

Similar Documents

Publication Publication Date Title
US11575683B2 (en) Privacy preserving validation and commit architecture
Zhang et al. Security and privacy on blockchain
Truong et al. Gdpr-compliant personal data management: A blockchain-based solution
Thomas et al. A protocol for interledger payments
Robinson Survey of crosschain communications protocols
JP2020517169A (ja) 安全なブロックチェーンベースのコンセンサス
US20170091750A1 (en) Transactional system with peer-to-peer distributed architecture for exchanging units of account
CN115699000A (zh) 通过计算机网络进行安全的多边数据交换的方法、装置和计算机可读介质
US12010236B2 (en) Blockchain-based crowdsourcing
KR20220093198A (ko) 전용 및 개방형 블록체인을 이용한 거래의 수행
KR102569409B1 (ko) 가상 분산 원장 네트워크를 위한 시스템 및 방법
Herlihy et al. Enhancing accountability and trust in distributed ledgers
JP2023527811A (ja) ネットワーク化されたデータ・トランザクションの認証及び認可のための方法、装置、及びコンピュータ可読媒体
KR20200019944A (ko) 블록체인 네트워크에서 계층적 토큰 분산을 위한 시스템 및 방법
US11621858B2 (en) Anonymity mechanisms in permissioned blockchain networks
Buldas et al. Blockchain Technology: Intrinsic Technological and Socio-Economic Barriers: FDSE’2020 Keynote
Robinson Consensus for crosschain communications
US20230421543A1 (en) Method, apparatus, and computer-readable medium for secured data transfer over a decentrlaized computer network
di Vimercati et al. Empowering owners with control in digital data markets
Amiri et al. Separ: A privacy-preserving blockchain-based system for regulating multi-platform crowdworking environments
Osterland et al. Oracle-based process automation in DLT dominated ecosystems with an application to German waterway transportation
Ellis A decentralized oracle network steve ellis, ari juels, and sergey nazarov
JP2023106055A (ja) エビデンス管理方法、エビデンス管理システム及びノード
JP2024096348A (ja) プライバシーを守る検証およびコミットアーキテクチャ
Lu et al. ZebraLancer: Decentralized crowdsourcing of human knowledge atop open blockchain