KR20210065933A - 프로토콜들의 검증에 관한 익명의 분산 합의 - Google Patents

프로토콜들의 검증에 관한 익명의 분산 합의 Download PDF

Info

Publication number
KR20210065933A
KR20210065933A KR1020217005836A KR20217005836A KR20210065933A KR 20210065933 A KR20210065933 A KR 20210065933A KR 1020217005836 A KR1020217005836 A KR 1020217005836A KR 20217005836 A KR20217005836 A KR 20217005836A KR 20210065933 A KR20210065933 A KR 20210065933A
Authority
KR
South Korea
Prior art keywords
workflow
component
validation
transition
components
Prior art date
Application number
KR1020217005836A
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 KR20210065933A publication Critical patent/KR20210065933A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06312—Adjustment or analysis of established resource schedule, e.g. resource or task levelling, or dynamic rescheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06316—Sequencing of tasks or work
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0633—Workflow analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0658—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed locally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0609—Buyer or seller confidence or verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Mining & Analysis (AREA)
  • Technology Law (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Stored Programmes (AREA)

Abstract

분산 원장에 통신적으로 결합된 탈중앙화 애플리케이션들(DApp)에 대해 수학적으로 그리고 논리적으로 엄격한 유효성 검사를 수행하는 기법들이 개시된다. 비즈니스 또는 기업 프로세스를 위한 프로토콜은 DApp의 일부로서 레이블 전이 시스템 상에 워크플로우로서 인코딩된다. 전이들은 비동기 Pi 캘큘러스 또는 다른 프로세스 캘큘러스들을 통해 코딩된다. 규칙 엔진은 프로세스 캘큘러스들의 동작들을 사용하여, 또는 대안적으로 레이블 전이 시스템 상에서 수학적 및 논리적 분석들을 수행하여 전이들을 유효성 검사한다. 개발 시간과 런타임 양쪽 모두에 대한 유효성 검사들이 개시된다. 일부 실시예들에서, DApp 배후의 로직은 프로세스들을 표현하는 미리 결정된 컴포넌트들의 세트로 구성된다. 하나의 특정 실시예에서, 미리 결정된 컴포넌트들의 세트는 오로지 입력 컴포넌트 및 출력 컴포넌트로 이루어지고 구성될 때 양쪽 컴포넌트들 중 어느 한 쪽이 다른 컴포넌트로부터 아티팩트 표현들을 수신하거나 어느 쪽도 수신하지 않는 트랜잭션을 수행한다.

Description

프로토콜들의 검증에 관한 익명의 분산 합의
비즈니스 프로세스는 일반적으로 상태(state)들 및 해당 상태들 간의 전이(transition)들로 구성된 워크플로우로서 표현되는 것에 의해 컴퓨터 상에서 자동화된다. 워크플로우에 대한 공식적인 비즈니스 프로세스는 프로토콜이라고 불린다. 상태들은 인스턴스를 표현하고 전이는 인스턴스가 그것의 상태를 변경할 수 있는 규칙들을 표현한다. 프로세스의 인스턴스와 인스턴스의 상태는 일반적으로 중앙 데이터베이스에 저장된다. 예시적인 프로세스(또는 워크플로우 용어로 전이)는, 양쪽 모두 은행 계정이 있는, 두 당사자 간에 결제가 있는 금전 이체 트랜잭션일 수 있다. 지불 당사자는 그 각각의 계정의 차변(debit)에 기입할 것이고, 수취인 당사자는 그 각각의 계정의 대변(credit)에 기입할 것이다. 중앙 데이터베이스는 사용자 인스턴스들의 상태, 이 경우 지불 당사자 계정과 수취인 당사자 계정의 잔고들을 저장하기 위해 사용될 수 있다. 더욱이, 중앙 데이터베이스는 트랜잭션을 하는 당사자들의 감사 로그(audit log), 이체 금액, 영향을 받은 계정들, 및 트랜잭션의 날짜/시간 스탬프를 유지하는 것에 의해 트랜잭션의 상태를 저장할 수 있다.
이 상황은 규칙들을 이용하여 전이들이 검증될 수 있는 소프트웨어 애플리케이션들의 부류에 매우 적합하다. 위의 차변/대변 예의 경우, 규칙은 대변에 기입된 금액이 차변에 기입된 금액과 동등해야 한다는 것일 수 있다. 그렇지 않으면, 어느 한 당사자가 금전을 잃거나, 계정들은 정부가 발행한 것보다 더 많은 금전을 반영한다. 이 워크플로우의 경우, 전이는 이 규칙을 이용하여 자동화된 시스템에 의해 독립적으로 검증될 수 있으므로, 시스템은 일반적으로 계정이 있는 임의의 당사자에게 개방될 수 있고 그럼에도 강력한 방식으로 작용할 것으로 예상된다.
이론에도 불구하고, 사용자들은 그들의 시스템을 보안하기를 원한다. 이는 일반적으로 사용자 계정 보안 및 액세스 제어 리스트들 및 그들의 변형으로 달성된다. 요점은 단지 시스템이 개방될 수 있다는 것 때문에, 사용자들이 시스템을 신뢰한다는 것을 의미하지는 않는다는 점이다. 현재, 중앙 데이터베이스가 있는 위의 예시적인 시스템을 포함하는 중앙화 시스템들에 대해, 신뢰는 암호화 방법들로 영향을 받는다.
그러나, 당사자들이 서로의 시스템들을 신뢰하지 않을 정도로 서로를 불신하는 애플리케이션들의 클래스는 어떻게 되는가? 당사자들의 결제를 수락하는 웹사이트로부터 위젯을 주문하는 당사자를 생각해보자. 위젯이 도착하지 않는다. 당사자는 위젯이 배송되었음을 당사자에게 확인하는 웹사이트 비즈니스 소유자에게 연락한다. 사실, 웹사이트 자체는 그러한 상황을 반영한다. 어느 시점에, 당사자는 웹사이트가 잘못되었거나, 더 나쁘게는 비즈니스 소유자가 사기를 치는 것이라고 생각할 수 있다.
블록체인 기술을 포함하는, 분산 원장 기술(DLT)이 이 문제를 해결한다. DLT는 불변이고 합의와 투명성을 지원하는 소프트웨어 애플리케이션들을 위한 탈중앙화 및 분산 플랫폼을 제공한다. 이 설명을 파싱하여, 워크플로우의 상태가 검증자들이라고 불리는 비교적 많은 제3자들의 세트에 저장될 수 있는 원장에 저장된다. 각각의 검증자는 원장에 저장된 상태들의 서명들의 그 자신의 중복 사본을 가지고 있다. 따라서 원장은 다수의 머신들 상에 상주하기 때문에 분산될 뿐만 아니라, 아무 당사자도 원장을 소유하지 않기 때문에 탈중앙화된다.
원장은 또한 불변이도록 구성되는데, 즉 일단 변경이 이루어지면, 그것은 실행 취소(undo)될 수 없다. 이는 임의의 실행 취소는 모든 원장들에 전파되어야 할 것이기 때문이다. 대신, 실행 취소가 행해져야 한다면, 역 연산(reverse operation)이 모든 원장들에 전파된다 - 그러나 초기 액션은 결코 삭제되지 않는다. 불변성은 또한 투명성의 개념을 지원한다; 구체적으로, 원장에 대해 수행되는 모든 액션들은 독립적으로 검사될 수 있다. 사실, 때때로 DLT의 투명성은 "급진적 투명성(radical transparency)"이라고 지칭된다. 이 투명성은 임의의 당사자의 독립적인 검증을 가능하게 하고, 이로써 원장에 대한 신뢰를 향상시킨다.
마지막으로, 원장은 합의를 지원하도록 구성된다. 구체적으로, 원장의 하나의 인스턴스에 질문을 하면, 그것은 원장의 임의의 다른 인스턴스와 동일한 답변을 줄 것이다. 중앙 데이터베이스에 질문을 할 때, 하나의 저장소만 있기 때문에 그것은 동일한 답변을 반환한다. 그러나, DLT에 의하면, 다수의 중복 원장들이 있고, 따라서 원장들은 중앙 데이터베이스처럼 보이도록 서로 일관성을 유지해야 한다. 이 일관성이 달성될 때, 원장들은 합의를 가지고 있는 것으로 기술된다.
지금까지, 블록체인들과 같은 DLT들은 모두 탈중앙화된, 분산된, 불변의 그리고 합의와 투명성을 지원하는 속성들을 가지고 있다. DLT들은 신뢰를 야기한다. 위젯 구매 당사자의 경우, 위젯의 배송의 상태가 DLT에 저장되어 있으면, 위젯 구매 당사자는 웹사이트 비즈니스 소유자가 사기 데이터를 제시하지 않았음을 확신할 것이다. 사실, DLT는 일종의 대표 에스크로(representational escrow)의 역할을 할 수 있다 - 위젯이 배송되었다는, 또는 더 좋게는, 수신되었다는 알림이 없이는 결제가 완성되지 않는 애플리케이션이 생성될 수 있다. 워크플로우 전체에 걸쳐, 구매자와 판매자 양쪽 모두, 그리고 사실 법 집행과 같은 제3자들을 포함하는 임의의 당사자가 진행을 볼 수도 있을 것이다.
그러한 DLT 기반 애플리케이션들은 종종 "Decentralized Applications(탈중앙화된 애플리케이션들)"의 축약형인 "DApp들"이라고 불린다. DApp들은 트랜잭션 비용들을 낮추는데 그 이유는 그것들이 당사자들에 의한 의무 불이행(non-performance)에 대한 의존의 위험을 낮추기 때문이다.
이 모두가 DLT 자체가 정확하게 프로그래밍되었는지에 대한 질문을 청한다. DApp들에 대해, DLT는 진정한 상황을 표현하기 때문에, DLT 자체가 정확한 것을 보장하는 것이 특히 중요하다.
상세한 설명은 첨부 도면들을 참조하여 설명된다.
도 1은 익명의 분산 합의(anonymous distributed consensus)를 통한 프로토콜 검증을 위한 최상-레벨 컨텍스트 다이어그램이다.
도 2는 익명의 분산 합의를 통한 프로토콜 검증을 위한 예시적인 하드웨어, 소프트웨어 및 통신 환경의 다이어그램이다.
도 3은 익명의 분산 합의를 통한 프로토콜 검증을 갖는 탈중앙화 애플리케이션 개발 환경을 위한 예시적인 아키텍처의 블록 다이어그램이다.
도 4는 익명의 분산 합의를 통한 프로토콜 검증을 갖는 예시적인 탈중앙화 개발 프로세스의 흐름도이다.
도 5는 익명의 분산 합의를 통한 프로토콜 검증을 갖는 탈중앙화 애플리케이션 운영 환경을 위한 예시적인 아키텍처의 블록 다이어그램이다.
도 6은 익명의 분산 합의를 통한 프로토콜 검증을 갖는 예시적인 탈중앙화 동작에 대한 흐름도이다.
익명의 분산 합의를 통한 프로토콜 검증의 수학적 및 논리적 기반들
익명의 분산 합의를 통한 프로토콜 검증의 실시예들을 설명하기 전에, 일부 기초적인 기법들을 논의하는 것이 유용하다. 이들 기법은 "Anonymous Distributed Consensus Regarding the Verified Execution of Health Care Protocols", "Anonymous Distributed Consensus Regarding Contract Sanctioned Transition Sequences with Semantic Attachments", "Symmetric Asset Exchange: A Universal Construction in Contract Patterns for Payments and Logistics", 및 "Cones, Co-Cones and Causality: A Categorical Reconstruction of Digital Contracts"라는 논문들에서 더 상세히 설명되고, 이들 모두는 본 출원이 우선권을 주장하는 가특허들에 포함되고 이들 모두는 본 명세서의 관련 출원 섹션에서 인용에 의해 포함된다. 인용에 의한 포함에도 불구하고, 이들 기법의 일부 개요가 필요하다.
1. 레이블 전이 시스템들(Labeled Transition Systems) + 분산 원장 기술(Distributed Ledger Technology) + 공식적인 방법들(Formal Methods) = 엄격한 검증(Rigorous Verification)
자동화된 컴퓨팅 시스템들은 그것들을 프로그래밍하는 명령어들을 수행한다. 컴퓨터 명령어들을 포함하는 프로그램이 정확하면, 컴퓨팅 시스템은 정확하게 수행한다. 다시 말해서, 컴퓨터 시스템은 프로그래머가 의도한 작업들을, 프로그래머가 의도한 방식으로 수행한다. 이는 의미상 정확성(semantic correctness)이라고 불린다. 프로그램이 정확하지 않으면, 컴퓨팅 시스템이 부정확하게 수행하고, 이로써 의미상 오류를 생성한다. 컴퓨팅 시스템들은 인간들에 의해 프로그래밍되므로, 오류들이 컴퓨팅 시스템들에 들어가는 것은 불가피하다.
오류들의 유입을 최소화하기 위해, "공식적인 방법들(formal methods)"으로 알려진 연구 모음이 있다. 구체적으로, 프로그램들은 표현으로, 종종 공식적인 방법들을 지원하는 언어, 즉, 수학적 및 논리적 연산들로 제시된다. 프로그램들이 공식적인 방법들을 지원하는 표현으로 제시되기 때문에, 프로그램들은 프로그램이 정확한지를 증명하기 위해 수학적 및 논리적 연산들을 사용할 수 있다. 사실, 프로그램들은 수학적 및 논리적 연산들을 사용하여 다른 프로그램들의 정확성을 검증하기 위해 작성될 수 있다. 검증 이외에, 프로그램들은 표현들을 다른 표현들로 변환할 수 있다 - 즉, 다른 프로그래밍 언어들로 번역될 수 있다. 그 번역들은 표현에 의해 지원되는 수학적 및 논리적 연산들이 번역을 포함하는 연산들을 특정하는 엄격한 수단을 제공하므로 신뢰될 수 있다.
요컨대, 엄격한 표현, 및 공식적인 방법들을 지원하는 언어의 사용은 수학적 및 논리적 엄격함으로 DLT에 구축된 프로그램들을 특정, 검증, 및 변환하는 수단을 제공한다.
따라서, 우리는 상호 작용하는 액터(actor)들과 리소스(resource)들의 세트인 프로토콜로 시작한다. 비즈니스 및 기업 프로세스의 기초를 이루는 개념은 전형적으로 프로토콜이라고 지칭된다. 프로토콜이 자동화를 위해 표현되는 경우, 그 표현은 워크플로우, 또는 "프로토콜에 대한 워크플로우"이라고 지칭된다. 프로토콜이 컴퓨터 동작을 통해 시행되는 경우, 프로토콜에 대한 자동화된 워크플로우는 "스마트 계약"이라고 지칭된다. 스마트 계약들에 대한 기초 프로토콜들은 네트워크 또는 "스윔 레인(swim lane)" 다이어그램들 또는 상태 전이 다이어그램들의 형태로 그래픽으로 캡처될 수 있다. 스마트 계약들에 대한 기초 프로토콜들은 BPEL(Business Process Execution Language) 및 Microsoft의 XLANG와 같은 언어들로 표현되었다. 이 정보를 캡처하는 툴들의 동작은 도 3 및 도 4와 관련하여 더 상세히 설명된다.
스마트 계약들에 대한 프로토콜이 자동화를 위해 식별되면, 프로토콜 워크플로우는 일부 자동화 가능한 구조로 캡처되어야 한다. 하나의 자동화 가능한 구조는 레이블 전이 시스템(Labeled Transition System, LTS)이다. LTS는 상태들을 표현하는 노드들과, 상태들 간의 유효한 전이들을 표현하는 유향 에지(directed edge)들로 구성된 유향 그래프(digraph)이다. 액터는 에지들을 통해 상태와 상태 간에 전이하는 것에 의해 프로토콜을 통해 진행한다.
앞서 언급된 바와 같이, 사용자들은 자동화된 시스템이 정확하다고, 즉, 의미상 오류들을 가지고 있지 않다고 가정한다. 의미상 오류들이 발견되면, 사용자들은 시스템을 신뢰하지 않을 것이고 그것을 사용하지 않을 것이다. 따라서, 전이들을 검증하는 일부 수단이 필요하다.
일반적으로 블록체인들 및 DLT는 익명의 합의를 제공하는 수단을 제공한다. 구체적으로, 보통 익명의 제3자들인, 검증자들은 동작들, 이 경우 LTS에서의 전이들을 검토할 수 있고, 전이가 검증되면, 전이가 분산 원장에 게시되도록 허용한다.
검증자가 익명일 필요는 없다는 점에 유의한다. 일반적으로, 익명성은 누구나 검증자가 될 수 있는 개방형 무허가 시스템들의 특징이다. 그러나, 알려진 참여자들의 세트로 참여가 제한되는 허가 시스템들과 같은 일부 실시예들에서는 익명성에 대한 필요가 없을 수 있다.
허가 시스템들을 사용하는 한 가지 이유는 암호화폐의 사용을 피하기 위한 것이다. 무허가 시스템들의 경우, 검증자들은 암호화폐의 형태로 보수를 받기 때문에 DLT 트랜잭션들 검증하기 위해 참여한다. 비즈니스 모델이 암호화폐 경제학에 상당한 의존을 하는 경우, 참여자들이 최대화되는 무허가 시스템들이 유용하다. 비즈니스 모델이 암호화폐 경제학에 상당한 의존을 하지 않는 경우, 허가 시스템들이 더 타당할 수 있다.
그러나 다시, 검증자가 익명인지 여부에 관계없이, 이는 검증자들이 신뢰될 수 있는 방식으로 전이들을 검증할 수 있는 방법에 대한 질문을 청한다.
제안된 해결책은 공식적인 방법들, 즉, 수학적 및 논리적 연산들을 지원하는 언어로 전이들을 특정하는 것이다. 수학적 및 논리적 기법들이 신뢰되는 한, 수학적 및 논리적 기법에 기초한 검증도 그러하다. 더욱이, 수학적 및 논리적 기법들은 자동화에도 적합하다. 일반적으로, 우리는 주장들과 유효성을 프로그래밍하는 공식적인 방법들의 이점을 가지고 있다.
공식적인 방법들을 지원하는 언어의 일 예는 프로세스 캘큘러스(process calculus)이다. 비동기 Pi(Asynchronous Pi, aPi) 캘큘러스는 프로세스 캘큘러스들의 예이다. 프로세스 캘큘러스들은 LTS와 LTS에서의 전이들을 인코딩하기 위해 사용될 수 있다. 프로세스 캘큘러스들은 통신 채널들 및 포트들을 기술하고 메시지들을 표현하는 수단을 제공한다. 프로세스 캘큘러스들은 수학적 동등성을 보여주기 위한 합동 규칙들(congruence rules) 및 표현식들을 변환하기 위한 축약 규칙들(reduction rules)을 제공한다. 따라서, 프로세스 캘큘러스들은 검증을 위한 수학적 증명들을 위해 수학적 및 논리적 연산들(예컨대 Hennessy-Milner 로직들)을 지원하는데, 즉, 소프트웨어가 의미상으로 예상대로 수행하는 것을 수학적으로 그리고 논리적으로 보여준다. aPi 변형은 분산 시스템들에 적합하다.
여담으로, Hennessy-Milner 로직들은 적용될 수 있는 유일한 종류의 로직은 아니다. 선호 로직들(preference logics) 및 모달 로직들(modal logics)도 적용될 수 있다. 선호 로직의 적용은 관련 출원 섹션에서 제시된 가특허들에 포함되고 이로써 본 명세서에 인용에 의해 포함된 "Anonymous Distributed Consensus Regarding Contract Sanctioned Transition Sequences with Semantic Attachments"라는 논문에 더 상세히 설명되어 있다.
프로토콜의 유효성 검사 및/또는 프로토콜의 워크플로우는 공식적인 언어 표현들로 제한될 필요가 없다. 프로토콜/워크플로우의 표현이 수학적 및 논리적 분석에 적합한 구조에 있을 때, 해당 수학적 및 논리적 장치는 프로토콜/워크플로우를 검증하고 번역하기 위하여 이용될 수 있다. 예를 들어, LTS 구조들은, 검증의 일부로서, 워크플로우 LTS의 바이그래프를 연구하는 기법들인, 바이시뮬레이션(bisimulation) 및 코인덕션(coinduction)을 지원한다.
여담으로, LTS에서의 전이들은 aPi 또는 다른 프로세스 캘큘러스로 코딩된다. 급진적 투명성의 이름으로, LTS는 인트로스펙트(introspect)되는 대상에 대한 정보를 보여주는(반영으로도 알려짐) 속성인 인트로스펙션(introspection)을 지원할 수 있다. 일부 실시예들에서, 전이를 검증하거나 임의의 검증을 수행하는 로직은 요구에 따라 사용자에게 제시될 수 있고, 이로써 전이가 유효성 검사되었는지 여부가 아니라, 적용된 로직에 대한 투명성을 제공할 수 있다.
2. 대칭 자산 교환(Symmetric Asset Exchange)
한 당사자가 아티팩트에 의해 표현된 자산(예컨대 상품 또는 서비스)을 제2 당사자로부터의 다른 아티팩트와 교환하는 법적 계약들의 경우, 이행(performance)을 확인하는 것 또는 약인(consideration)의 수령이 실체적인 위반(substantive breach)을 결정하는 데 중요하다. DLT의 사용에 의해, 당사자가 제1 당사자의 이행 또는 약인 전에 다른 당사자의 이행 또는 약인을 보장하는 것이 바람직하다. 이러한 방식으로, 신뢰 손상과 같은 특정 부류의 손상의 위험이 사실상 제거된다.
LTS + DLT + aPi 구성에 의해, 프로토콜들이 바이너리 교환(binary exchange)들로 분해될 수 있고, 바이너리 교환에서는, 양쪽 당사자 중 어느 한 쪽이 다른 당사자의 아티팩트들을 수령하거나 양쪽 모두가 그렇지 않다. 한 당사자는 아티팩트를 수령하고 다른 당사자는 그렇지 않은 교환의 시도는 없다. 교환의 결과들이 양쪽 당사자들에게 동일하므로, 이 교환은 대칭이다. 교환은 자산들을 표현하는 아티팩트들에 대한 것이므로, 이 (서브)프로토콜은 대칭 자산 교환(symmetric asset exchange, SAX)이라고 불린다.
특정 분해는 잠재적으로 제1 프로세스를 표현하는 입력 컴포넌트와 잠재적으로 제2 프로세스를 표현하는 출력 컴포넌트에 대한 것일 수 있다. 이들 2개의 컴포넌트는 더 큰 프로토콜들로 구성될 수 있는 원자 컴포넌트들이다. 이 실시예에서, 입력 컴포넌트는 메시지가 제1 채널에서 수신되었고 그 후 메시지를 제1 채널의 변수에 바인딩한다고 또는 메시지가 제2 채널에서 수신되었고 그 후 메시지를 제2 채널의 변수에 바인딩한다고 논리적으로 결정하도록 구성된다. 차례로, 출력 컴포넌트는 2개의 컴포넌트로 구성된 메시지를 수신하고, 메시지의 수신시, 제1 채널을 통해 제1 컴포넌트를 전송하고 제2 채널을 통해 제2 컴포넌트를 전송하도록 구성된다. 이 둘의 구성은 제1 프로세스가 제2 프로세스로부터 아티팩트를 수령하고 제2 프로세스가 제1 프로세스로부터 아티팩트를 수령하거나, 양쪽 프로세스가 아티팩트를 수령하지 않는 결과를 야기한다. 이 구성에서, 입력 및 출력 컴포넌트들은 대칭 자산 교환을 만족시킨다.
일부 실시예들에서, 컴포넌트들은 프로세스의 완성("완료됨(done)"으로 알려짐)을 나타내기 위해 채널의 이름을 제외하고 임의의 자유 이름 또는 자유 변수를 공유하지 않도록 구성될 수 있다. 일부 실시예들에서, 완료된 프로세스는, 임계 섹션(critical section) 또는 상호 제외(mutual exclusion, mutex)와 동작이 유사한, 분산된 컴포넌트들의 동작을 동기화하기 위해 사용될 수 있다.
비동기 Pi 캘큘러스(aPi)를 사용하는 것의 이점들 중 하나는 그것이 구성 가능성에 적합하다는 것이다. 따라서, 서브프로토콜들의 면에서 프로토콜을 특정할 수 있고, 서브 프로토콜들은 aPi를 사용하여 표현할 수 있다. 입력 및 출력 컴포넌트들의 구체적인 내부 사항들은 관련 출원 섹션에서 제시된 가특허들에 포함되고 이로써 본 명세서에 인용에 의해 포함된 "Symmetric Asset Exchange: A Universal Construction in Contract Patterns for Payments and Logistics"이라는 논문에 더 상세히 설명되어 있다.
DApp가 DLT에서, 특히 무허가 애플리케이션들에 대해, 수행하는 처리가 많을수록, DApp를 동작시키기 위해 더 많은 비용이 든다는 점에 유의해야 한다. 일반적으로, 암호화폐 처리 비용들은 수행되는 처리의 양에 비례한다. 이러한 이유로, 대칭 교환 및 유효성 검사들은 DLT 런타임에서 호스팅되지 않는 유효성 검사기 애플리케이션(validator application)에서 수행되고 이로써 DLT에서 처리를 오프로딩할 수 있다. 유효성 검사기 애플리케이션은 전형적으로, 보통 DApp를 통해, 지속성을 게시하기 위해서만 DLT를 호출한다. 이러한 방식으로, 비-DLT 앱, 여기서 유효성 검사기 애플리케이션은 암호화폐 비용들 및 DLT 런타임 부하를 최소화하기 위해 DApp와 작업을 나눈다.
3. 범주론 보기(Category Theory View)
DLT들은 반드시 전이의 상태를 저장하도록 구성되는 것은 아니다. 오히려, DLT들은 전이의 서명을 표현하는 머클 트리 해시들을 저장한다. 해시들은 전이들을 수행하는 당사자들의 암호화 키들뿐만 아니라 과거 해시들에 기초하므로, DLT는 당사자들이 전이가 합법적인지를 결정할 수 있게 하면서 압축된다. 전이의 실제 상태에 대해, 당사자는 전통적인 중앙화 데이터베이스에 액세스할 수 있다.
중앙화 데이터베이스들을 활용하면 DLT를 사용하는 것의 마찰을 낮출 수 있다. 이 시나리오에서 DLT는 기존 인프라를 대체하는 것이 아니라 그것을 증강시키는 것이므로, 기존 인프라를 이식(porting)할 위험이 최소화된다.
그러나, 전통적인 중앙 데이터베이스의 스키마를 캡처하고 변환이 의미를 보존하는지를 결정하는 것이 바람직할 수 있다. 일부 실시예들에서, 의미 보존 변환을 식별하기 위해 범주형 데이터베이스들이 일종의 중립 공통어로서 사용된다. 범주형 데이터베이스들은 사용자가 동등하고 합동인 데이터베이스 스키마들을 식별하는 것을 가능하게 하는 수학적 범주론을 사용하는 데이터베이스이다. 요컨대, 스마트 계약은 범주형 데이터베이스의 의미 보존 변환으로서 특징지어질 수 있다.
이러한 컨텍스트에서 범주론을 사용하는 방법에 대한 내부 사항들은 관련 출원 섹션에서 제시된 가특허들에 포함되고 이로써 본 명세서에 인용에 의해 포함된 "Anonymous Distributed Consensus Regarding Contract Sanctioned Transition Sequences with Semantic Attachments"이라는 논문에 더 상세히 설명되어 있다.
따라서, 주의를 기울일 범주론으로부터 이용 가능하게 되는 추가적인 장치에 액세스할 수 있다. 이러한 방식으로, LTS + DLT + aPi 구성은 사용자들이 계산, 범주 및 논리적 기법들을 마음대로 적용할 수 있게 한다.
익명의 분산 합의를 통한 프로토콜 검증의 컨텍스트
이제 익명의 분산 합의의 프로토콜 검증을 위한 컨텍스트를 설명할 준비가 되었다. 도 1은 익명의 분산 합의를 통한 프로토콜 검증을 위한 컨텍스트 다이어그램(100)이다. 프로토콜(102)은 상호 작용하는 액터들(104) 및 리소스들(106)의 세트로 구성된 비즈니스 또는 기업 프로세스이다. 액터들은 인간들일 수 있거나 자동화된 프로세스들 자체일 수 있다. 리소스들은 교환될 수 있는 어떤 종류의 자산(상품) 또는 계약의 이행에서 변환되는 어떤 종류의 자산(서비스)을 표현한다. 자산들은 아티팩트(108)로 알려진 어떤 종류의 토큰으로 전자적으로 표현될 수 있다. 프로토콜 배후의 로직은 "워크플로우" 또는 "프로토콜의 워크플로우"로 알려져 있다.
워크플로우는 LTS(112)로 구성된 검증 애플리케이션(110)에서 인코딩될 수 있고, 여기서 전이들은 aPi와 같은 공식적인 언어로 검증 규칙들(114)과 연관된다.
탈중앙화 애플리케이션(DApp)(118)을 통해 분산 원장(116) 상에서 성공적인 전이들의 지속성이 수행되고 검증 로직을 수행하고 저장한다. 검증 애플리케이션(110)은 전이들에 대응하는 DLT에 통신적으로 결합된 원자 대칭 자산 교환 컴포넌트(120)로 구성될 수 있다.
개발 시간 동작은 도 3 및 도 4와 관련하여 더 상세히 설명된다. 런타임 동작은 도 5 및 도 6과 관련하여 더 상세히 설명된다.
익명의 분산 합의를 통한 프로토콜 검증을 위한 예시적인 환경
익명의 분산 합의를 통한 프로토콜 검증은 일반적으로 하드웨어, 소프트웨어 및 통신 인프라로 구성된 컴퓨팅 디바이스들 상에서 수행된다. 도 2는 익명의 분산 합의를 통한 프로토콜 검증을 위한 하드웨어, 소프트웨어 및 통신 환경을 설명하는 예시적인 환경 다이어그램(200)이다.
웹 브라우저, 클라이언트 암호화 지갑 및 DApp 클라이언트와 같은 클라이언트 측 소프트웨어는 일반적으로 클라이언트 컴퓨팅 디바이스(202) 상에서 호스팅된다. 예시적인 클라이언트 컴퓨팅 디바이스들(202)은 이에 제한되는 것은 아니지만 개인용 컴퓨터, 랩톱, 임베디드 디바이스, 태블릿 컴퓨터, 및 스마트 폰을 포함한다. 이들 클라이언트 컴퓨팅 디바이스(202)는 탈중앙화 애플리케이션들에 액세스하기 때문에, 이들 클라이언트 컴퓨팅 디바이스(202)는 네트워킹된다.
클라이언트 컴퓨팅 디바이스(202)는 프로세서(204) 및 메모리(206)를 갖는다. 프로세서는 중앙 처리 유닛, 애플리케이션 처리 유닛, 및/또는 마이크로컨트롤러와 같은 전용 컨트롤러일 수 있다.
클라이언트 컴퓨팅 디바이스(202)는 입력/출력(I/O) 인터페이스(208) 및/또는 네트워크 인터페이스(210)를 더 포함한다. I/O 인터페이스(208)는 RS-232 및/또는 USB(Universal Serial Bus)와 같은 표준 I/O 인터페이스 프로토콜과 함께 사용되는 UART(universal asynchronous receiver/transmitter)와 같은 임의의 컨트롤러 카드일 수 있다. 네트워크 인터페이스(210)는 잠재적으로 I/O 인터페이스(208)와 협력하여 동작할 수 있고 이더넷 및/또는 Wi-Fi 및/또는 임의의 수의 다른 물리적 및/또는 데이터링크 프로토콜을 지원하는 네트워크 인터페이스 카드일 수 있다. 스마트 폰과 같은 많은 클라이언트 컴퓨팅 디바이스(202) 상에서, 클라이언트 컴퓨팅 디바이스(202)는 셀룰러 및 비인가 무선 통신(예를 들어, Wi-Fi) 양쪽 모두에 참여할 수 있다. 따라서, 스마트 폰/모바일 실시예에서, 네트워크 인터페이스(210)는 셀룰러 또는 비인가 통신을 위한 하나 이상의 라디오와 협력하여 동작할 수 있다.
일반적으로, 메모리(206)는 운영 체제(218) 및 소프트웨어 컴포넌트들 및 클라이언트 측 소프트웨어(214)를 포함하는 여러 소프트웨어 컴포넌트를 저장할 수 있는 임의의 컴퓨터 판독가능 매체라는 점에 유의한다. 일반적으로, 소프트웨어 컴포넌트는 개별 전체로서 함께 저장된 컴퓨터 실행가능 명령어들의 세트이다. 소프트웨어 컴포넌트들의 예들은 정적 라이브러리들, 동적으로 링크된 라이브러리들, 및 실행가능 프로그램들과 같은 바이너리 실행 파일들을 포함할 수 있다. 소프트웨어 컴포넌트들의 다른 예들은 서블릿들, 애플릿들, p-Code 바이너리들, 및 Java 바이너리들과 같이 런타임에 실행되는 해석된 실행 파일들을 포함할 수 있다. 소프트웨어 컴포넌트들은 커널 모드 및/또는 사용자 모드에서 실행될 수 있다.
컴퓨터 판독가능 매체는 적어도 2가지 유형의 컴퓨터 판독가능 매체, 즉 컴퓨터 저장 매체 및 통신 매체를 포함한다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어들, 데이터 구조들, 프로그램 모듈들, 또는 다른 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 이동식 및 비이동식 매체를 포함한다. 컴퓨터 저장 매체는, 이에 제한되는 것은 아니지만, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disks) 또는 다른 광학 저장 디바이스, 자기 카세트, 자기 테이프, 자기 디스크 저장 디바이스, 또는 다른 자기 저장 디바이스, 또는 컴퓨팅 디바이스에 의한 액세스를 위해 정보를 저장하기 위해 사용될 수 있는 임의의 다른 비전송 매체를 포함한다. 그에 반해서, 통신 매체는 반송파와 같은 변조된 데이터 신호, 또는 다른 전송 메커니즘에 컴퓨터 판독가능 명령어들, 데이터 구조들, 프로그램 모듈들, 또는 다른 데이터를 구현할 수 있다. 본 명세서에서 정의되는, 컴퓨터 저장 매체는 통신 매체를 포함하지 않는다.
검증 애플리케이션들(110) 및 DApp들(118)과 같은 서버 측 애플리케이션들은 일반적으로 물리적 서버 또는 가상 머신 상에서 호스팅된다. 서버 측 애플리케이션들(110, 118)이 물리적 서버 상에서 호스팅되는 경우, 서버(216)는 네트워크에 참여할 수 있는 임의의 컴퓨팅 디바이스이다. 네트워크는, 이에 제한되는 것은 아니지만, 근거리 통신망("LAN"), 가상 사설망("VPN"), 셀룰러 네트워크, 또는 인터넷일 수 있다. 서버(216)는 다수의 클라이언트에 서비스를 제공하기에 충분한 I/O 컴퓨팅 용량을 갖는 컴퓨팅 디바이스일 수 있다. 구체적으로, 물리적 서버(216)는 프로세서(218), 메모리(220), 입력/출력 인터페이스(222) 및 네트워크 인터페이스(224)를 포함한다. 메모리(220)에는 운영 체제(226) 및 서버 측 애플리케이션들(228)이 있을 것이다.
대안적으로, 서버 측 애플리케이션들(228)은 클라우드 서비스(230)를 통해 가상 머신 상에서 호스팅될 수 있다. 구체적으로, 클라우드 서비스(230)는 가상 애플리케이션 서버(232) 기능 및 가상 저장/데이터베이스(234) 기능을 제공하는 복수의 분리된 서버를 표현할 수 있다. 분리된 서버들은, 프로세서, 메모리, I/O 인터페이스 및/또는 네트워크 인터페이스를 포함할 수 있는, 물리적 컴퓨터 서버들이다. 프로세서, 메모리, I/O 인터페이스 및 네트워크 인터페이스의 특징들 및 변형들은 물리적 서버(216)에 대해 설명된 것들과 실질적으로 유사하다. 분리된 서버들이 처리량 및/또는 분리를 위해 최적화되는 경우 차이들이 있을 수 있다. 서버 측 애플리케이션들(228)을 호스팅하는 것 이외에, 기계 학습/인지 네트워크 소프트웨어(도시되지 않음) 및 다른 서버 측 소프트웨어(도시되지 않음)가 가상 애플리케이션 서버들(232) 상에서 호스팅될 수 있다.
클라우드 서비스(230)는 통합 클라우드 인프라(236)를 통해 액세스 가능하게 될 수 있다. 클라우드 인프라(236)는 클라우드 서비스들(230)에 대한 액세스를 제공할 뿐만 아니라 과금 서비스들 및 다른 수익화 서비스들에 대한 액세스도 제공한다. 클라우드 인프라(236)는 PAAS(Platform as a Service), IAAS(Infrastructure as a Service), 및 SAAS(Software as a Service)와 같은 추가적인 서비스 추상화들을 제공할 수 있다.
익명의 분산 합의를 통한 프로토콜 검증을 위한 예시적인 개발 환경
LTS + DLT + aPi는 익명의 분산 합의를 통해 프로토콜 검증을 수행하도록 구성된다. 키 애플리케이션들은 개발 시간 애플리케이션들 및 런타임 애플리케이션들로 나누어진다. 개발 시간 애플리케이션들은 익명의 분산 합의를 통한 프로토콜 검증을 위한 예시적인 개발 환경의 블록 다이어그램(300)인 도 3 및 그것의 동작에 대한 흐름도인 도 4의 컨텍스트에서 설명된다. 런타임 애플리케이션들은 도 5 및 도 6과 관련하여 더 상세히 설명된다.
도 3에서, 동작은 워크플로우 디자인 툴(302)로 시작된다. 워크플로우 디자인 툴은 상호 작용하는 액터들과 리소스의 사양들을 수신할 수 있다. 사양은 액터들, 상태들, 상태들 간 전이들에 대한 것, 및 교환될 자산들로서 리소스들을 표현하는 아티팩트들에 대한 것일 수 있다. 워크플로우 디자인 툴(302)의 출력은 비즈니스 또는 기업 프로세스의 프로토콜의 사양이지만, 워크플로우 디자인 툴(302)은 네트워크(스윔레인) 다이어그램의 그림 또는 대안으로 상태 머신의 그림을 입력으로 수신하는 그래픽 툴일 수 있다.
네트워크 다이어그램의 경우, 개별 스윔레인들은 액터들에 대응한다. 스윔레인들 간의 화살표들은 액터들 간의 상호 작용들을 지시하고 상호 작용들 동안에 수행되는 아티팩트들 또는 기능들과 연관될 수 있다. 네트워크 다이어그램에서, 흐름이 상태들이 아니라 액터들 사이에 있기 때문에 흐름은 반드시 상태 전이들을 표현하는 것은 아니라는 점에 유의한다.
상태 전이 다이어그램의 경우, 노드들은 상태들을 표현할 수 있고, 상태들 간의 화살표들은 상태들 간의 전이들을 표현할 수 있다. 여기서 다시 전이들은 상호 작용들 동안에 수행되는 아티팩트들 또는 기능들과 연관될 수 있다.
그래픽 표현들은 워크플로우 디자인 툴(302)에 의해, 예를 들어 BPEL 또는 XLANG의 텍스트 형태로 변환될 수 있다. 대안적으로, BPEL 또는 XLANG는 텍스트 편집기로 수동으로 편집될 수 있다.
도 4를 참조하면, 처리는 수신기 모듈(304)이 프로토콜의 그림에 기초한 프로토콜을 수신할 때(402), 또는 워크플로우 디자인 툴(302)로 편집된 텍스트 프로토콜 사양으로부터 시작된다. 특히, 다시 도 3을 참조하면, 수신기 모듈(304)은 입력 사양을 파싱하고, 구문 및 다른 오류들을 찾고, 파싱된 입력 사양을 규칙 검사에 적합한 중간 표현 포맷으로 저장한다. 이 표현은 표현 엔진(308)에 의해 표현 데이터 저장소(310)에 저장된다. 규칙들은 미리 결정되고 규칙 엔진(312)에 의해 관리되고 규칙 데이터 저장소(314)에 저장된다.
일부 실시예들에서, 프로토콜의 중간 표현 포맷은 규칙 데이터 저장소(314)에 저장되고 규칙 엔진(312)에 의해 액세스 가능한 연관된 전이 규칙들을 갖는 LTS의 가상 버전이다. 규칙들은 규칙들을 다시 반사하는 선택된 전이들에 의해 워크플로우 디자인 툴(302)로부터 검토될 수 있다.
정적 테스트 및 동적 테스트 양쪽 모두가 수행될 수 있다. 완전성 검사, 로직 검사 및 바이시뮬레이션과 같은 정적 테스트들은 로직 검사기/유효성 검사기(logic checker/validator)(316)에 의해 수행될 수 있다.
동적 테스트를 위해, 유효성 검사기 애플리케이션(318) 및 DApp(320)를 포함하는 시뮬레이션된 애플리케이션인 유효성 검사기 애플리케이션(320)이 애플리케이션 생성기(322)에 의해 생성될 수 있다. 생성된 애플리케이션은 테스트 또는 이븐 프러덕션 분산 원장(324)과 통신적으로 결합되도록 구성될 수 있다. 입력 트리거들에 대해, 애플리케이션 생성기는 또한 브라우저 애플리케이션들(326) 및/또는 오라클들(328)(무엇보다도 외부 상태의 표현들을 분산 원장들에 제공하는)을 생성할 수 있다.
애플리케이션이 생성되면, 동적 테스트의 일부로서 중간 표현을 유효성 검사하기 위해 테스트 입력들이 실행될 수 있다.
다시 도 4를 참조하면, 블록 406에서 로직 검사기/유효성 검사기에 의해 유효성 검사들이 수행된다. 검사들은 애플리케이션에 특정한 규칙들에 기초할 수 있거나, 임의의 애플리케이션에 적용되는 규칙들일 수 있다. 검사들은, 예컨대 바이시뮬레이션 및/또는 코인덕션을 통해, LTS 자체에 대한 것일 수 있거나, 전이 규칙들 자체, 예를 들어, aPi 검사들에 대한 것일 수 있다.
생성된 애플리케이션은 중간 형태를 갖기 때문에, 테스트가 aPi의 규칙들 및 LTS에 특정한 것일 필요는 없다는 점에 유의한다. 예를 들어, 범주론 기반 검사들을 수행하기 위해 범주형 데이터베이스 표현들이 생성될 수도 있다.
블록 408에서, 애플리케이션 생성기(322)는 위에 설명된 바와 같이 애플리케이션 컴포넌트들을 생성하고 배치한다. 버저닝, 구축 및 배치 사이클은 DevOps 소프트웨어와의 통합을 통해 스크립팅되고 조정될 수 있다.
이러한 방식으로 개발, 테스트, 구축 및 배치 사이클들의 모든 단계들에서 수학적 및 논리적 연산들이 액세스 가능하다.
익명의 분산 합의를 통한 프로토콜 검증을 위한 예시적인 런타임 환경 및 동작
도 5는 익명의 분산 합의를 통한 프로토콜 검증을 위한 예시적인 런타임 환경의 블록 다이어그램(500)이고 도 6은 그것의 동작의 흐름도(600)이다.
위에 설명된 바와 같이, 유효성 검사기 애플리케이션(502)은 애플리케이션 생성기(322)에 의해 생성되었다. 테스트 중인 유효성 검사기 애플리케이션(318)과 달리, 유효성 검사기 애플리케이션(502)은 프로덕션 내에 배치된다.
유효성 검사기 애플리케이션(502)은 소프트웨어 메시지들인 입력 트리거들(504)을 수신하도록 구성된다(메시지 전달과 같은 푸시(push) 통신 프로토콜을 통해 또는 소프트웨어 알림/이벤트와 같은 풀(pull) 통신 프로토콜에 의해).
유효성 검사기 애플리케이션(502)은 일반적으로 LTS 내의 전이들(512)과 연관된 규칙들(510)을 갖는 LTS 형태의 표현을 포함한다. 일부 실시예들에서, 규칙들(510)은 aPi를 통해 인코딩된다. 개발 환경의 테스트 버전과 마찬가지로, 생성된 애플리케이션은 분산 원장(522) 상에서 지속성을 수행하기 위해 옵션으로 암호화폐 지갑을 갖도록 구성된 웹 브라우저(516) 상에서 실행되는 브라우저 애플리케이션(514), 오라클들(518) 및 DApp(520)와 같은 클라이언트들을 또한 포함한다.
도 6을 참조하면, 블록 602에서, 유효성 검사기 애플리케이션(502)은 브라우저 애플리케이션(514) 또는 오라클(518)로부터 입력 트리거(504)를 수신한다. 그 후 블록 604에서, 유효성 검사기 애플리케이션(502)은 프로토콜에서 관련 전이(512)를 식별하고, 전이(512)와 연관된 규칙(510)을 검색한다.
그 후 블록 606에서, 유효성 검사기 애플리케이션(502)은 검색된 규칙(510)을 이행한다. 블록 608에서, 규칙(510)이 만족되면, 즉, 규칙(510)에 의해 지정된 검사들이 검증되면, LTS가 업데이트되고 유효성 검사기 애플리케이션(502)은 DApp(520)를 호출하여 검증된 트랜잭션을 분산 원장(522)에 게시한다.
결론
본 주제는 구조적 특징들 및/또는 방법론적 동작들에 특정한 언어로 설명되었지만, 첨부된 청구범위에서 정의된 주제는 반드시 위에 설명된 특정 특징들 또는 동작들로 제한되는 것은 아니라는 것을 이해해야 한다. 오히려, 위에 설명된 특정 특징들 및 동작들은 청구범위를 구현하는 예시적인 형태들로서 개시되어 있다.

Claims (15)

  1. 워크플로우 전이 유효성 검사를 수행하는 방법으로서,
    워크플로우의 사양을 수신하는 단계 - 상기 워크플로우는 액터들(actors), 전이들(transitions), 및 아티팩트들(artifacts)로 구성되고, 상기 아티팩트는 상기 워크플로우의 적어도 하나의 관찰할 수 있는 것에 대응함 -;
    상기 수신된 워크플로우 사양으로부터 상기 워크플로우에 대응하는 다이그래프(digraph)로서 구성된 복수의 노드 및 연결로 구성된 상기 워크플로우의 표현(representaion)을 생성하는 단계 - 각각의 전이는 상기 전이의 유효성을 검증하기 위한 적어도 하나의 규칙과 연관되고, 상기 규칙은 공식적인 방법들을 지원하는 프로그램 가능한 언어로 인코딩됨 -;
    상기 워크플로우의 전이를 트리거하는 입력을 수신하고, 트리거된 전이에 대한 각각의 유효성 검사 규칙을 이행하는 단계; 및
    각각의 유효성 검사 규칙이 만족되면, 전이를 수행하고 분산 원장 상에서 전이를 지속시키는 단계를 포함하는, 워크플로우 전이 유효성 검사를 수행하는 방법.
  2. 제1항에 있어서, 상기 다이그래프는 레이블 전이 시스템(Labeled Transition System, LTS)인 것인, 워크플로우 전이 유효성 검사를 수행하는 방법.
  3. 제1항에 있어서, 상기 워크플로우 내의 전이의 유효성을 검증하기 위한 적어도 하나의 규칙은 상기 레이블 전이 시스템 상에 바이시뮬레이션(bisimulation), 코인덕션(coinduction), 또는 양쪽 모두를 포함하는, 워크플로우 전이 유효성 검사를 수행하는 방법.
  4. 제1항에 있어서, 상기 공식적인 방법들을 지원하는 프로그램 가능한 언어는 프로세스 캘큘러스(process calculus)인 것인, 워크플로우 전이 유효성 검사를 수행하는 방법.
  5. 제4항에 있어서, 상기 프로세스 캘큘러스는 비동기 Pi 캘큘러스(aPi)인 것인, 워크플로우 전이 유효성 검사를 수행하는 방법.
  6. 제1항에 있어서, 상기 생성된 표현은 상기 수신된 워크플로우의 범주론적 표현(category theoretical representation)을 포함하는 것인, 워크플로우 전이 유효성 검사를 수행하는 방법.
  7. 제1항에 있어서, 상기 다이그래프는 상기 워크플로우에 대응하는 레이블 전이 시스템(LTS)이고, 상기 공식적인 방법들을 지원하는 프로그램 가능한 언어는 비동기 Pi 캘큘러스(aPi)이고 이로써 구성(composition)을 지원하는 것인, 워크플로우 전이 유효성 검사를 수행하는 방법.
  8. 제7항에 있어서, 미리 결정된 컴포넌트들은 메시지가 처리된 것을 의미하는 자유 이름을 제외하고는 어떠한 자유 이름도 공유하지 않음으로써 디커플링(decoupling)을 최대화하도록 구성되는 것인, 워크플로우 전이 유효성 검사를 수행하는 방법.
  9. 제8항에 있어서, 메시지가 처리된 것을 의미하는 상기 자유 이름은 동기화 메커니즘인 것인, 워크플로우 전이 유효성 검사를 수행하는 방법.
  10. 제8항에 있어서, 상기 미리 결정된 컴포넌트들은 아티팩트들 또는 아티팩트들의 표현들의 교환을 지원하는 것인, 워크플로우 전이 유효성 검사를 수행하는 방법.
  11. 제10항에 있어서, 제2 컴포넌트로 제1 컴포넌트를 구성하는 적어도 하나의 치환은, 양쪽 컴포넌트들 중 어느 한 쪽이 다른 컴포넌트로부터 아티팩트들을 수신하게 하거나, 또는 상기 컴포넌트들 중 어느 쪽도 다른 컴포넌트로부터 아티팩트들을 수신하지 않게 하는, 워크플로우 전이 유효성 검사를 수행하는 방법.
  12. 제7항에 있어서, 상기 미리 결정된 컴포넌트들은 오로지 대칭 자산 교환 입력 원자 컴포넌트들, 대칭 자산 교환 출력 원자 컴포넌트들 중 어느 한쪽으로, 또는 양쪽 모두로 구성되는 것인, 워크플로우 전이 유효성 검사를 수행하는 방법.
  13. 제12항에 있어서, 상기 대칭 자산 교환 입력 원자 컴포넌트는, 메시지가 제1 채널에서 수신되었고 그 후 메시지를 제1 채널의 변수에 바인딩한다고 또는 메시지가 제2 채널에서 수신되었고 그 후 메시지를 제2 채널의 변수에 바인딩한다고 논리적으로 결정하는 것인, 워크플로우 전이 유효성 검사를 수행하는 방법.
  14. 제13항에 있어서, 상기 대칭 자산 교환 출력 원자 컴포넌트는, 2개의 컴포넌트로 구성된 메시지를 수신하고, 메시지의 수신시, 제1 채널을 통해 제1 컴포넌트를 전송하고 제2 채널을 통해 제2 컴포넌트를 전송하도록 구성되는 것인, 워크플로우 전이 유효성 검사를 수행하는 방법.
  15. 제12항에 있어서, 대칭 자산 교환 출력 컴포넌트로 대칭 자산 교환 입력 컴포넌트를 구성하는 적어도 하나의 치환은, 상기 입력 컴포넌트와 상기 출력 컴포넌트 양쪽 중 어느 한 쪽이 다른 컴포넌트로부터 아티팩트들을 수신하게 하거나, 또는 상기 입력 컴포넌트와 상기 출력 컴포넌트 중 어느 쪽도 다른 컴포넌트로부터 아티팩트들을 수신하지 않게 하는, 워크플로우 전이 유효성 검사를 수행하는 방법.
KR1020217005836A 2018-07-31 2019-07-31 프로토콜들의 검증에 관한 익명의 분산 합의 KR20210065933A (ko)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201862712768P 2018-07-31 2018-07-31
US201862712792P 2018-07-31 2018-07-31
US62/712,768 2018-07-31
US62/712,792 2018-07-31
US201962879991P 2019-07-29 2019-07-29
US62/879,991 2019-07-29
US16/526,872 US11410162B2 (en) 2018-07-31 2019-07-30 Anonymous distributed consensus regarding the verification of protocols
US16/526,872 2019-07-30
PCT/US2019/044539 WO2020028585A1 (en) 2018-07-31 2019-07-31 Anonymous distributed consensus regarding the verification of protocols

Publications (1)

Publication Number Publication Date
KR20210065933A true KR20210065933A (ko) 2021-06-04

Family

ID=69228107

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020217005836A KR20210065933A (ko) 2018-07-31 2019-07-31 프로토콜들의 검증에 관한 익명의 분산 합의

Country Status (5)

Country Link
US (2) US11410162B2 (ko)
EP (1) EP3830773A4 (ko)
KR (1) KR20210065933A (ko)
CA (1) CA3107934A1 (ko)
WO (1) WO2020028585A1 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11410162B2 (en) 2018-07-31 2022-08-09 Deixis, PBC Anonymous distributed consensus regarding the verification of protocols
US11676133B2 (en) * 2019-08-22 2023-06-13 Coinbase, Inc. Method and system for mobile cryptocurrency wallet connectivity
US20210281510A1 (en) * 2020-03-05 2021-09-09 Deixis, PBC High-resolution contract-based wireless network virtualization

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040055514A (ko) 2002-12-21 2004-06-26 한국전자통신연구원 지능형 이동체 궤적관리를 위한 위치기반 지식관리 방법
US20070288250A1 (en) * 2006-06-09 2007-12-13 Jens Lemcke Method and system for generating collaborative processes
US8965827B2 (en) * 2011-03-30 2015-02-24 Computer Sciences Corporation Rules execution platform system and method
US20130110576A1 (en) * 2011-10-28 2013-05-02 Infosys Limited System and method for checking the conformance of the behavior of a process
US20150379510A1 (en) * 2012-07-10 2015-12-31 Stanley Benjamin Smith Method and system to use a block chain infrastructure and Smart Contracts to monetize data transactions involving changes to data included into a data supply chain.
US20140229345A1 (en) 2013-02-14 2014-08-14 Microsoft Corporation Application process framework for integrated and extensible accounting system
US20170011460A1 (en) 2015-07-09 2017-01-12 Ouisa, LLC Systems and methods for trading, clearing and settling securities transactions using blockchain technology
WO2017148527A1 (en) 2016-03-03 2017-09-08 Nec Europe Ltd. Method for managing data in a network of nodes
EP3465592A1 (en) * 2016-06-06 2019-04-10 Financial & Risk Organisation Limited Systems and methods for providing a personal distributed ledger
WO2018140913A1 (en) * 2017-01-30 2018-08-02 SALT Lending Holdings, Inc. System and method of creating an asset based automated secure agreement
US11410162B2 (en) 2018-07-31 2022-08-09 Deixis, PBC Anonymous distributed consensus regarding the verification of protocols
US11522690B2 (en) * 2019-06-07 2022-12-06 Bengala Technologies, Llc Supply chain management system

Also Published As

Publication number Publication date
US11410162B2 (en) 2022-08-09
EP3830773A1 (en) 2021-06-09
US20200042991A1 (en) 2020-02-06
EP3830773A4 (en) 2022-04-20
US20220383222A1 (en) 2022-12-01
WO2020028585A1 (en) 2020-02-06
CA3107934A1 (en) 2020-02-06

Similar Documents

Publication Publication Date Title
US20240028587A1 (en) System and method for a hybrid contract execution environment
Marchesi et al. An agile software engineering method to design blockchain applications
Marchesi et al. ABCDE—Agile block chain DApp engineering
CN109154885B (zh) 区块链平台上的业务处理执行
De Kruijff et al. Understanding the blockchain using enterprise ontology
Alketbi et al. Novel blockchain reference model for government services: Dubai government case study
US20220383222A1 (en) Anonymous distributed consensus regarding the verification of protocols
US20190286490A1 (en) Event-driven blockchain workflow processing
Holbrook Architecting enterprise blockchain solutions
US20220156725A1 (en) Cross-chain settlement mechanism
Gaur et al. Blockchain with hyperledger fabric: Build decentralized applications using hyperledger fabric 2
Baset et al. Blockchain Development with hyperledger: build decentralized applications with hyperledger fabric and composer
US11818206B2 (en) Visibility of digital assets at channel level
CN107277108B (zh) 一种区块链的节点处的消息处理方法、装置及系统
US20220311595A1 (en) Reducing transaction aborts in execute-order-validate blockchain models
CN115705256A (zh) 就服务事务达成共识的请求促进
Liu FSM Modeling of Off-Blockchain Computation
Soelman Permissioned blockchains: A comparative study
Rasti et al. A Coin Marketplace Implementation on Blockchain Using the Hyperledger Platform
US20230097203A1 (en) System and method for generating blockchain token support from a set of declarations
CN109032921A (zh) 一种结构化需求用例自动生成方法及装置
US20240146712A1 (en) Dynamic user interface (ui) framework
US20220255990A1 (en) Topological ordering of blockchain associated proposals
Sousa Exploring the use of blockchain in academic management systems
Conceição Validation of Smart Contracts Through Automated Tooling

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E601 Decision to refuse application