KR20190071778A

KR20190071778A - 블록체인을 통한 결정론적 유한 오토마타(DFAs) 구현을 위한 시스템 및 방법

Info

Publication number: KR20190071778A
Application number: KR1020197014561A
Authority: KR
Inventors: 크레이그 스티븐 라이트; 페드로 히메네즈-델가도
Original assignee: 엔체인 홀딩스 리미티드
Priority date: 2016-10-28
Filing date: 2017-10-27
Publication date: 2019-06-24
Also published as: AU2022252826A1; SG11201903387RA; JP7036844B2; US20190279197A1; JP2022071122A; JP7387781B2; AU2017349752A1; JP6646764B2; ZA201902686B; KR102427013B1; JP2020080158A; KR20240027155A; TWI816647B; EP3532924B1; EP3532924A1; AU2017349752B2; JP2024023300A; KR20220108214A; CN109923521A; KR102639537B1

Abstract

본 발명은 비트 코인 블록 체인(Bitcoin blockchain)과 같은 블록 체인(blockchain)에서 테스크 또는 프로세스를 구현, 제어 및 자동화하는 기술에 관한 것이다. 본 발명은 특히 금융 계약을 위한 스마트 계약과 같이 계약의 자동 실행에 적합하지만 반드시 이에 국한되지는 않으며, 다른 유형의 업무 및 비재무 계약이 구현될 수 있다. 본 발명은 블록 체인의 미사용 출력을 사용하여 머신의 상태를 나타내는 블록 체인상의 스테이트 머신 또는 DFA의 구현 또는 구체화로 볼 수 있으며, 머신의 상태가 하나의 상태에서 다른 상태로 전환될 때 그 출력을 소비한다.. 본 발명은 한정된 상태 집합 중 하나가 될 수 있는 관념적인 기계로 간주되는 컴퓨터의 수학적 모델의 기술적 실현 및 구현을 제공하며 유한 집합의 트리거 이벤트(입력이라고 함)가 발생할 때 하나의 상태에서 다른 상태로 전환할 수 있다. 본 발명은 DFA 구현을 위한 컴파일 및 코드화 기술을 포함한다.

Description

블록체인을 통한 결정론적 유한 오토마타(DFAs) 구현을 위한 시스템 및 방법

본 발명은 일반적으로 컴퓨터 기반 프로세스 컴퓨터 프로토콜의 자동화 된 실행을 위한 시스템 및 프로토콜에 관한 것으로, 보다 구체적으로 예를 들어 계약과 관련된 상태 제어 프로세스의 검증, 시행 및 / 또는 성능에 관한 것이다. 그러나, 본 발명은 계약과 관련하여 사용하는 것으로 제한되지는 않는다. 본 발명은 또한 비트 코인 블록 체인(Bitcoin blockchain)과 같은 블록 체인 기술(bitchin blockchain)과 관련되며, 스마트 계약을 이용하여 유리하게 사용될 수 있다.

컴퓨터를 사용하여 작업과 프로세스의 실행을 자동화하고 제어하는 것이 오랫동안 요구되어 왔다. 이는 특히 금융 계약과 관련된 당사자 간의 계약 이행과 관련하여 그러하다. 스마트 계약은 계약의 본질에 대하여 전자 버전에서 더 나은 정의가 시행되며, 이후 컴퓨터에 의해 더 수월하게 실행되고 시행된다는 사실이 알려진 이후, 학술 연구 및 실질적인 관심의 주제가 되었다. 현대 계약 관리의 주요 문제점 중 하나는 수동으로 관리되는 로컬 상점 및 계약서 사본과 함께 임시 방편으로 사용되는 경향이 있다는 것이다. 이 사본은 서로 동기화되지 않을 수 있으며 자체 저장 및 유지 관리가 필요하다. 이는 비효율적이며 보안 및 비용과 관련된 문제를 야기한다. 이러한 문제는 기계 판독 가능하고 실행 가능한 문서(종종 "스마트 계약"이라고도 함)의 성능을 자동화함으로써 적어도 부분적으로 해결 될 수 있다. 이러한 자동화 된 솔루션은 자연어와 법률에서 비롯된 모호성 및 해석을 최소화하는 데에도 도움이 된다. 결과적으로, 계약이 자동화 된 경우 비용이 적게 들지만 보다 효율적이고 신뢰할 수 있는 방식으로 계약을 수행 할 수 있다.

문헌에서 제안된 여러 가지 접근법 중에서 결정 론적 유한 상태 기계라고도 하는 결정적 유한 오토마타(DFA, deterministic finite automata)는 다양한 범위의 상상할 수 있는 재정적인 영역을 대표할만큼 충분히 풍부한 구조(계약뿐만 아니라 다른 종류의 계약도 포함할만큼)를 가지고 있음이 입증되었다. 유한 스테이트 머신 및 DFA의 개념은 컴퓨터 과학 분야에서 잘 알려져 있다. DFA는 한정된 상태 집합 중 하나에 있을 수 있는 관념적인 기계로 간주되는 컴퓨터의 수학적 모델이며, 트리거 이벤트 또는 조건이 발생할 때 하나의 상태에서 다른 상태로 변경(전환)될 수 있다. 그것의 계산 능력은 조합 논리(combination logic)의 계산 능력보다 뛰어나지만 스택 머신(stack machine)의 계산 능력보다는 뛰어나지 않다.

블록 체인 기술과 관련하여 계약의 자동 실행이 최근 연구되고 있다. 예를 들어 CN 105893042 A는 스마트 계약을 실행하는 동안 발생한 상태 전환과 관련된 데이터를 안전하게 저장하는 도구로 블록 체인을 사용하는 방법에 대해 설명한다. 그러나 블록 체인 기술, 거래 출력 및 관련 스크립트는 여기에서 논의된 것처럼 보다 지능적인 동작을 제공하기 위해 훨씬 더 정교하고 기술적으로 복잡한 방식으로 사용될 수 있다.

블록 체인은 거래로 이루어진 변경 불가능한 블록으로 구성된 컴퓨터 구현 중앙 비집중형, 분산형 피어-투-피어 컴퓨터 시스템이다. 여기에는 합의에 기반한 프로토콜이 포함된다. 각 블록은 이전 블록의 해시를 포함하므로 블록이 함께 연결되어 처음부터 블록 체인에 쓰여진 모든 거래에 대한 변조 방지 및 영구 레코드를 생성한다. 이러한 블록은 공개적으로 검사할 수 있지만 블록 체인의 일부가 되면 변경 또는 제거될 수 없으며, 변경시 해시가 바뀌게 된다.

거래에는 입력 및 출력에 임베드 된 스크립트라는 작은 프로그램이 들어 있으며, 이 프로그램은 거래의 출력에 액세스 할 수 있는 방법 및 대상을 지정한다. 각 미사용 거래 (UTXO라고 함)는 새 거래의 입력으로 사용될 수 있으므로, 시간이 지남에 따라 체인이 증가한다. 각 출력에는 출력 잠금 스크립트에 지정된 요구 사항을 준수하는 한 네트워크의 주소로 보낼 수 있는 관련 금액이 있다. 주소는 암호화 비대칭 키 쌍의 공용키이다. P2PKH (pay to public key hash) 출력은 주소 (공개 키)에 직접 값을 지불하는 출력이며,　 P2SH (pay to script hash) 거래의 출력은 제2스크립트의 해시를 포함하는 공개키 스크립트(잠금 해제 스크립트라고도 함)와 수신자가 자신의 서명과 함께 후속 거래에서 제공해야 하는 리딤 스크립트(redeem script)와 연결된다.다른 블록 체인 구현이 제안 및 개발되었지만, 블록 체인 기술의 가장 널리 알려진 응용 프로그램은 비트코인 분산 장부이다. 비트코인은 본 명세서에서 편의 및 설명을 위해 언급 될 수 있지만, 본 발명은 비트코인 블록 체인과 함께 사용하는 것으로만 제한되지는 않으며, 대안적인 블록 체인의 구현은 본 발명의 범위 내에 있다.

블록 체인 기술은 암호 화폐 구현시 사용되는 것으로 알려져 있다. 그러나 최근에 사업가들은 비트코인을 기반으로 하는 암호화 보안 시스템의 사용과 새로운 시스템을 구현하기 위해 블록체인에 저장할 수 있는 데이터를 모두 연구하기 시작했다. 결과적으로 "스마트 계약"으로 알려진 컴퓨터 프로토콜은 부분적으로 또는 전체적으로 계약의 자동 시행 또는 성능 구현을 가능하게 하므로 주목을 받기 시작했다. 블록 체인으로 구현되는 스마트 계약은 보안 강화, 변조 방지 및 영구적인 이벤트 공개 기록, 거래 비용 절감 등과 같은 이점을 제공 할 수 있다.

따라서, 계약과 같은 프로세스의 자동화로부터 발생하는 이익 및 그 자동화를 위해 블록 체인을 사용하는 이점을 제공하는 솔루션을 제공하는 것이 바람직하다.

이와 같은 개선된 해결책이 고안되었다. 본 발명은 첨부된 청구 범위에서 정의된다.

본 발명에 따르면, 블록 체인 구현 방법 / 시스템이 제공 될 수 있다. 이는 기술 프로세스의 자동화 된 성능 및 제어를 위한 방법 / 시스템으로 설명 될 수 있다. 본 발명은 블록 체인 기반 구조에 대한 유한 스테이트 머신 또는 DFA의 구현 또는 실제 구현을 통해 프로세스의 자동화 된 성능을 용이하게 하는 기술 혁신을 제공 할 수 있다. 머신의 상태가 정의되고 결정될 수 있다. 각 상태 전환에 대한 조건 또는 트리거가 저장 될 수 있다. 프로세스가 실행되면 실행된 상태가 영구 블록 체인 장부에 기록 될 수 있다. 블록체인 거래는 머신이 한 상태에서 다른 상태로 이동하게 하는 에이전트 또는 참가자로 기능할 수 있다. 각 상태 전환은 프로세스의 단계를 나타내거나 대응할 수 있다. DFA가 계약을 정의할 때, 본 발명은 기타 조항 및 규정과 마찬가지로 상이한 계약 당사자간의 약속의 자동 실행 및 이행을 위한 메커니즘을 제공 할 수 있다.

부가적 또는 대안적으로, 본 발명은 블록 체인을 사용하여 블록 체인에서 실행되는 컴퓨터 구현 프로세스를 제어하는 방법 / 솔루션으로서 설명 될 수 있다. 따라서, 그것은 그들의 아키텍처와 프로토콜면에서 매우 다른 컴퓨터 기반 시스템의 상호 작용을 포함할 수 있다. 전술한 하나 이상의 특징이 본 발명의 이 양상에 따라 사용될 수 있다.

본 발명의 하나 이상의 실시예는 블록 체인상에서 또는 블록 체인과 관련하여 DFA를 구현(구현 또는 실현)하는 방법을 제공 할 수 있다. DFA는 소프트웨어 기반 DFA 일 수 있다. 블록 체인은 비트코인 기반 프로토콜과 함께 구현되거나 다른 블록 체인 프로토콜을 사용할 수 있다. 부가적 또는 대안적으로, 그것은 블록 체인으로 구현된 DFA의 상태를 결정할 수 있도록 구성된 방법 일 수 있다. 이것은 현재 상태 일 수 있다. 이 방법은 DFA의 상태를 동적으로 (런타임에)결정할 수 있다. 따라서, 본 발명의 하나 이상의 양태는 이미 발생된 이벤트에 관한 데이터를 기록하기 위한 보안 저장 도구로서 단순히 사용되는 것보다 더 정확하고 복잡하고 지능적인 방식으로 블록 체인상에서 DFA를 구현하기 위한 메커니즘을 제공 할 수 있다.

본 발명은 블록 체인 거래(Tx1)의 미사용 출력(UTXO1)의 잠금 스크립트의 일부를 DFA의 주어진 상태와 연관시키는 단계를 포함 할 수 있다. 잠금 스크립트의 일부는 잠금 스크립트 내의 데이터의 일부일 수 있다. 또는 메타 데이터의 일부일 수 있다. 또는 식별자, 레이블 또는 태그 일 수 있다.

따라서, 본 발명은 블록 체인상의 미사용 거래 출력(UTXO)을 사용하여 실행시 주어진 시점에서 DFA가 존재하였거나 및 / 또는 현재 존재하는 상태를 기록하고 식별 할 수 있다.

상기 방법은,

추가 거래(Tx2)를 사용하여 상기 거래(Tx1)의 출력(UTXO1)을 소비함으로써 상기 DFA의 상태로부터 다른 상태로 전환하는 단계를 포함한다. 상기 다른 상태는 상기 추가 거래의 미사용 출력(UTXO2)의 잠금 스크립트 내에 제공된 데이터의 일부와 연관 될 수 있다. 따라서 UTXO를 사용하면 블록 체인상에서 기록 또는 구현될 예정인 DFA의 상태가 변경될 수 있다.

상기 방법은,

실행될 때 추가 거래(Tx2)가 상기 거래(Tx1)의 상기 출력 (UTXO1)을 소비하게 하여 상기 DFA를 다른 상태로 전환시키는 적어도 하나의 상태 전환 트리거를 구현 또는 표현하기 위해 코드의 일부를 사용하는 단계를 포함할 수 있다.

상기 코드의 일부는 입력 신호에 기초하여 부울(Bloolean) 결과를 제공하는 머신 - 테스트 가능한 조건을 포함 할 수 있다. 입력 신호는 런타임에 결정될 수 있으며, 상기 DFA를 상기 다른 상태로 전환시키기 위해 미사용 출력(UTXO1)이 소비되어야 하는지 여부를 결정하기 위해 상기 코드 일부에 의해 사용될 수 있다.

상기 미사용 출력 (UTXO1)의 데이터 일부는 잠금 스크립트로 제공 될 수 있다.

상기 데이터 일부분는 태그, 라벨 또는 메타 데이터의 일부일 수 있다.

상기 DFA는 기계 실행 가능한 스마트 계약 모델 일 수 있다.

상기 미사용 출력(UTXO1)은 상기 출력 (UTXO1)을 소비하고 상기 DFA를 다른 상태로 전환시키기 위해 추가 거래의 입력에 의해 솔루션이 제공되어야 하는 퍼즐의 해시를 포함하는 잠금 스크립트를 포함 할 수 있다.

상기 미사용 출력(UTXO1)은 상기 출력(UTXO1)을 소비하고 상기 DFA를 다른 상태로 전환시키기 위해 추가 거래의 입력에 의해 제공되어야 하는 리딤 스크립트의 해시를 포함하는 잠금 스크립트를 포함 할 수있다. 상기 리딤 스크립트는 암호키를 포함 할 수 있다.

상기 방법은 하나 이상의 컴퓨팅 에이전트를 사용하여 전술한 또는 후술되는 임의의 특징을 수행하는 단계를 포함 할 수 있다.

본 발명은 또한 전술한 임의의 실시예의 방법을 구현하도록 구성된 시스템을 제공한다. 상기 시스템은,

블록 체인 플랫폼; (비트코인 블록 체인 일 수도 있고, 그렇지 않을 수도 있음)

상기 블록 체인을 통해 상기 DFA를 구현하도록 배치된 적어도 하나의 컴퓨팅 에이전트를 포함할 수 있다.

부가적 또는 대안적으로, 상기 방법은,

적어도 하나의 입력 신호를 사용하여 적어도 하나의 조건을 실행하고, 상기 조건의 실행 결과에 기초하여 상기 DFA에 대한 상태 전환 테이블에 따라 동작을 수행하는 단계를 포함할 수 있다.

동작 수행은 블록 체인 장부의 상태에서 식별 가능하거나 감지될 수 있다. 이것은 하나 이상의 블록 체인 거래의 출력을 보고 / 분석함으로써 성취될 수 있다. 거래가 DFA 및 / 또는 DFA와 관련된 계약과 관련된 경우 출력을 검사하여 출력의 지출 여부를 결정할 수 있다. DFA의 상태는 출력이 여전히 사용되지 않는다는 사실로부터 식별 될 수 있다. 이것은 DFA를 위해 고안된 상태 전환 테이블을 참고하여 식별 할 수 있다. 이는 상기 방법 / 시스템의 실행 전에 고안되었을 수 있다.

동작은 블록 체인에서 거래(Tx)를 사용하여 수행할 수 있다. 동작은 블록 체인상의 하나 이상의 거래의 출력 및 / 또는 입력으로부터 식별 될 수 있다.

상기 방법은 동작이 수행되었는지의 여부에 기초하여 DFA의 현재 상태를 결정하기 위해 블록 체인의 상태를 분석하는 단계를 포함 할 수 있다.

DFA는 계약의 실행을 표현하거나 모델링 할 수 있다. 계약은 기계 실행 가능한 스마트 계약 일 수 있다.

적어도 하나의 입력 신호는 인간 또는 사람이 아닌 소스에 의해 생성 및 / 또는 제공되는 신호 또는 값일 수 있다. 예를 들어, 그것은 방법이 실행되는 컴퓨터에 의해 생성 될 수 있다(예: 시스템 클락에서 파생된 시간 또는 날짜). 그것은 컴퓨터 외부의 소스로부터 수신 될 수 있다(예: 원격 센서 또는 원격 컴퓨팅 리소스).

적어도 하나의 입력 신호는 DFA의 하나의 상태에서 다른 상태로의 전환을 위한 트리거를 제공하거나 또는 트리거의 "발사(fire)" 또는 활성화를 일으켜 계속되는 동작을 유발할 수 있다.

이 방법은 DFA에 대한 상태 전환 테이블을 결정하는 단계를 포함 할 수 있다. 상태 전환 테이블은 소프트웨어로 문서화 될 수 있다. 소프트웨어는 주어진 입력 신호 및 이들이 트리거하는 상태 전환 및 / 또는 기계 실행 가능한 동작에 관한 명령을 포함 할 수 있다.

이 방법은 블록 체인 거래(Tx1)의 미사용 출력(UTXO1)의 잠금 스크립트의 일부(Data in)를 DFA의 주어진 상태와 연관시키는 단계를 포함 할 수 있다. 이 방법은 추가 거래(Tx2)를 사용하여 거래(Tx1)의 출력(UTXO1)을 소비함으로써 DFA의 상태를 다른 상태로 전환하는 단계를 포함 할 수 있다. 상기 다른 상태는 상기 추가 거래의 미사용 출력(UTXO2)의 잠금 스크립트 내에 제공된 데이터의 일부와 관련 될 수 있다.

이 방법은 실행될 때 추가 거래(Tx₂) 가 거래(Tx₁) 의 출력(UTXO₁) 을 소비하게 하는 적어도 하나의 상태 전환 트리거를 구현 또는 표현하기 위해 적어도 하나의 컴퓨터 실행 가능 조건을 포함하는 코드의 일부를 사용하는 단계를 포함하여 DFA를 다른 상태로 전환한다.　코드 부분은 입력 신호에 기초하여 부울 결과를 제공하는 조건을 포함할 수 있다.

이 방법은 특정 상태가 DFA에 의해 점유된 횟수의 기록을 유지하는 단계를 포함할 수 있다. 상기 기록은 루프 또는 반복 구조 내에서 증가하는 인덱스를 사용하여 유지 관리될 수 있다. 루프 또는 반복 구조는 미리 정의된 조건이 충족될 때 종료될 수 있다.

소프트웨어 구현 DFA는 분산 아키텍처 또는 시스템을 사용하여 구현 및 / 또는 실행될 수 있다. 본 발명은 또한 전술한 또는 후술될 방법의 임의의 실시예를 구현하도록 구성된 시스템을 제공할 수 있다.

상기 발명은 적어도 하나의 입력 신호를 사용하여 적어도 하나의 조건을 실행하고, 상기 조건의 실행 결과에 기초하여 상기 DFA에 대한 상태 전환 테이블에 따라 동작을 수행할 수 있으며; 상기 동작의 수행은 블록 체인 장부의 상태로부터 식별 가능하다.

본 발명은 블록 체인 거래(Tx1)의 미사용 출력(UTXO1)의 잠금 스크립트에 있는 일부를 DFA의 주어진 상태와 연관시키는 단계를 포함하는 방법을 제공할 수 있다. 잠금 스크립트의 일부는 잠금 스크립트 내의 데이터의 일부일 수 있다. 또는, 메타 데이터의 일부일 수 있습니다. 또는, 식별자, 레이블 또는 태그 일 수 있다. 따라서, 본 발명은 블록 체인상의 미사용 거래 출력(UTXO)을 사용하여 실행시 주어진 시점에서 DFA가 존재하였거나 및 / 또는 현재 존재하는 상태를 기록하고 식별할 수 있다.상기 방법은 거래(Tx2)를 사용하여 거래(Tx1)의 출력(UTXO1)을 소비함으로써 DFA의 상태를 다른 상태로 변환하는 단계를 포함할 수 있다. 상기 다른 상태는 상기 추가 거래의 미사용 출력(UTXO2)의 잠금 스크립트 내에 제공된 데이터의 일부와 연관 될 수 있다. 따라서 UTXO를 사용하면 블록 체인에서 DFA 상태가 변경되거나 기록 될 수 있다.

본 발명은 명세서의 "체계화 기술"섹션과 관련하여 실질적으로 아래에 기술된 바와 같을 수 있지만, 명세서의 다른 섹션으로부터의 특징을 포함할 수도 있고 여기에 설명된 임의의 특징을 포함할 수도 있다.

부가적 또는 대안적으로, 본 발명은 입력 신호를 모니터링 및 / 또는 수신하고, 입력 신호에 응답하여, 미사용 출력(UTXO)을 포함하는 블록 체인 거래(Tx2)를 생성하고, 이전 거래(Tx1)의 출력을 소비하는 프로그램을 실행하는 단계를 포함 할 수 있다.

상기 이전 거래(Tx1)의 출력은 DFA의 제 1 상태와 연관된 식별자를 포함하는 잠금 스크립트를 포함 할 수 있고, 상기 거래(Tx2)의 미사용 출력(UTXO)은 DFA의 다른 상태와 관련된 추가 식별자를 포함하는 잠금 스크립트를 포함 할 수 있다. DFA 식별자는 레이블, 태그 또는 상태를 식별하기 위한 임의의 수단의 형식일 수 있다. 이는 메타 데이터 또는 암호키와 같은 일부 데이터로 구성 될 수 있다.

상기 프로그램은 DFA의 제 1 상태와 관련된 식별자를 포함할 수 있다. 상기 프로그램은 DFA의 추가 상태와 관련되고, 추가 거래(Tx2)의 UTXO에 포함된 추가 식별자를 포함하는 추가 프로그램을 생성 및 / 또는 실행하도록 구성될 수 있다.

DFA는 (기계 실행 가능)스마트 계약의 실행을 모델링하거나 표현할 수 있다. 스마트 계약은 템플릿 계약에 파라미터를 채워 컴퓨터 기반 리소스로 생성될 수 있다. 따라서 계약 생성은 자동화 될 수 있다.

상기 방법은 상기 DFA에 대한 상태 전환 테이블을 결정하고, 상기 상태 전환 테이블을 컴퓨터 기반 저장 리소스에 저장하는 단계를 포함할 수 있다.

상기 프로그램은 다음과 같은 방법으로 입력 신호에 응답하여 블록 체인 거래(Tx2)를 생성하도록 구성될 수 있다:

블록 체인 거래(Tx1)의 잠금 스크립트에서 식별자를 사용하여 DFA의 현재 상태를 결정하는 단계;

상기 현재 상태 및 상기 입력 신호에 기초하여, 상기 DFA에 대한 상태 전환 테이블을 사용하여 상기 다른 상태 및 관련 식별자를 결정하는 단계.

상기 방법은 블록 체인 거래(Tx2) 및 / 또는 이전 거래(Tx1)를 블록 체인 네트워크에 제출하는 단계를 포함할 수 있다.

각각의 프로그램은 DFA의 상태를 고유하게 식별하기 위한 식별자를 포함하는 복수의 프로그램이 생성되고 실행될 수 있다. 따라서, 일련의 프로그램 (스크립트)이 계약을 실행하는데 사용될 수 있으며, 각 스크립트는 상태의 기간, 즉 얼마나 오래 DFA가 그 주어진 상태에 있거나 얼마나 오래 있는지에 상응하는 수명을 갖는다.

소비하고 DFA를 다른 상태로 전환하기 위하여, 거래(Tx2) 및 / 또는 이전 거래(Tx1) 출력의 미사용 출력 (UTXO)은 퍼즐의 해시를 포함하는 잠금 스크립트를 포함 할 수 있으며, 이 솔루션은 다른 블록 체인 트랜잭션의 입력으로 제공되어야 한다.출력 (UTXO)을 소비하고 DFA를 다른 상태로 전환하기 위하여, 거래(Tx2) 및 / 또는 이전 거래(Tx1) 출력의 미사용 출력 (UTXO)은 다른 거래의 입력에 의해 제공되어야 하는 리딤 스크립트의 해시를 포함하는 잠금 스크립트를 포함할 수 있다.　리딤 스크립트는 암호 키를 포함할 수 있다.

DFA의 상태는 블록 체인의 거래에서 미사용 출력 (UTXO)으로 나타낼 수 있다. 주어진 UTXO 소비는 다른 상태로의 전환을 나타낼 수 있다. 상태, 동작, 조건 및 트리거는 DFA의 전환 테이블에 제공되거나 소프트웨어로 인코딩될 수 있다.

본 발명은 소프트웨어 기반 DFA를 구현, 실현 또는 구체화하도록 구성된 시스템을 제공할 수 있다. 블록 체인을 통해 이 작업을 수행 할 수 있다. 이는 다음을 포함할 수 있다:

블록 체인; (비트코인네트워크를 사용하여 구현되거나 그렇지 않을 수도 있음)

위에서 설명된 임의의 방법의 단계(들)에 따라 적어도 하나의 프로그램을 생성 및 / 또는 실행하도록 구성된 하나 이상의 컴퓨팅 에이전트들;

상기 DFA에 대한 상태 전환 테이블을 저장하기 위한 저장 리소스를 포함하는 저장 매체; 이것은 예를 들어 해시 테이블 또는 분산 해시 테이블 일 수 있다; 및 / 또는

블록 체인 거래를 위한 적어도 하나의 템플릿 및 / 또는 스마트 계약을 위한 적어도 하나의 템플릿을 포함 할 수 있다.

본 발명은 "소프트웨어 구현 DFA의 컴파일 및 실행"이라는 제목의 다음 섹션에서 설명된 것과 실질적으로 동일할 수 있지만, 명세서의 다른 섹션의 기능이 적용될 수도 있다.

시스템은 (스마트)계약의 자동 실행을 실행하도록 수행하는 블록 체인상의 스테이트 머신을 구현하거나 또는 이를 구현하도록 구성될 수 있다.

본 발명의 시스템과 관련하여 언급된 임의의 특징은 또한 본 발명의 대응되는 방법에 적용될 수 있으며, 그 반대 일 수도 있다. 본 발명의 한 양태 또는 실시예와 관련하여 본 명세서에 언급된 임의의 특징은 임의의 다른 실시예 또는 양태에도 적용될 수 있다.

본 발명의 블록 체인 기반 DFA는 적어도 다음 주요 특징을 포함한다:

·유한 상태 집합 중 하나가 될 수 있는 관념 머신으로 간주되는 컴퓨터의 수학적 모델을 블록 체인 기반으로 구현하고,　유한 집합(입력이라고 함)의 트리거 이벤트가 발생할 때 하나의 상태에서 다른 상태로 변경(전환)할 수 있음

·블록 체인 플랫폼에서 연산 및 저장 구조로 구체화 된 DFA(Deterministic Finite Automaton)와 같이 다양한 당사자의 약속을 기술적으로 실현하여 계약을 수립하고 자동 실행하는 새로운 기술을 제공함

·기존 블록 체인 인프라 및 프로토콜을 사용할 수 있음

·스마트 계약의 자동화 된 생성, 제어 및 수행을 가능하게 하고 용이하게 함

·컴퓨터에 의해 자동으로 실행 및 수행 가능

·계약, 실행 및 결과에 대한 영구적이고 불변의 기록

본 발명은 적어도 다음과 같은 이점을 제공하고 이용하는데, 이는 블록체인 프로토콜 및 플랫폼에 내재되어 있다:

·본질적 보안 설계(비트코인 프로토콜은 신뢰 당사자를 필요로 하지 않음)

·분산형이므로 대규모 단일 장애 지점(single point of failure)을 피할 수 있으며 공격에 취약하지 않음

·관리 및 유지가 용이함(비트코인 네트워크의 사용은 직관적임)

·저렴함(비트코인 프로토콜에서는 일반적으로 소량의 거래 수수료가 부과됨)

·지리적으로 제한적이거나 한정되지 않음 - 인터넷에 접속할 수 있는 모든 사람이 언제 어디서나 사용할 수 있음

·투명함, 데이터가 블록 체인에 쓰여지면 누구나 확인할 수 있음

·변경 불가, 블록 체인에 데이터를 쓰면 아무도 변경할 수 없음

·프라이버시가 관리되며, 개인 신상 정보가 연관되지 않음

본 발명의 이들 및 다른 양태는 본원에 기술된 실시 예를 참조하여 명백하게 설명될 것이다. 본 발명의 실시예는 첨부된 도면을 참조하여 예로서만 설명될 것이다:
도 1은 본 발명의 일실시 예에 따라 구성된 시스템의 개략을 도시한다.
도 2는 트리거되는 다양한 상태 전환을 나타내기 위해 P2PKH 거래를 사용하여 블록 체인 상에 구현된 DFA로서, 스마트 계약이 실행되는 본 발명의 예시적인 실시예를 도시한다.
도 3은 아래에 설명된 예제에 따라 블록 체인 기반 DFA를 도시한다.
도 4는 아래에 설명된 퍼즐 기반 구현의 개시(상태 s0) 거래(o)의 예시를 도시한다.
도 5는 전환(상태 s0에서 상태 ff 로) 거래(tf) 의 예시를 도시한다.
도 6은 완료(상태 ff로부터의) 거래(cf)의 예시를 도시한다.
도 7은 도 4와 유사하지만 DFA 상태에 대해 P2SH 거래 유형을 사용하는 블록 체인 거래를 도시한다.
도 8은 도 5의 예시와 비슷하지만 DFA 상태에 대해 P2SH 거래 유형을 사용하는 예시이다.
도 9는 도 6의 예시와 유사하지만 DFA 상태에 대해 P2SH 거래 유형을 사용하는 예시를 도시한다.
도 10은 본 발명의 일 실시예에 따라 사용될 수 있는 체계화 기술의 예시 1의 채권에 대한 스테이트 다어어그램이다. 표시된 입력과 관련된 상태(원형) 및 전환(연결 선)을 나타낸다.
도 11은 반복되는 상태를 갖는 예시 2의 쿠폰 채권의 스테이트 다어어그램을 도시한다.
도 12는 도 11의 예시와 관련된 반복되는 상태의 내부 스테이트 다어어그램을 도시한다.
도 13은 본 명세서의 "컴파일 및 실행"섹션의 유럽 통화 옵션 예제에 대한 스테이트 다이어그램으로 제출될 상태(원형) 및 블록 체인 거래(삼각형)을 나타낸다: 개시(o), 전환(t), 및 완료(c).

본 명세서에서는 이 기술분야에서 현재 가장 널리 알려진 용어로서 편의를 위해 '블록 체인'이라는 용어를 사용한다. 이 용어는 블록 체인, 알트 체인(alt-chain), 사이드 체인(sidechains) 및 거래 체인 기술, 허가된 및 허가되지 않은 장부, 공유 장부 및 그 변형을 포함하여 모든 형태의 전자 컴퓨터 기반 분산 장부를 포함하여 여기에서 사용된다. 블록체인 기술의 가장 널리 알려진 적용은 비트 코인 장부이지만 다른 블록 체인 구현이 제안되고 개발되었다. 비트코인은 본 명세서에서 편의 및 설명을 위해 언급 될 수 있지만, 본 발명은 비트 코인 블록 체인과 함께 사용하는 것만으로 제한되지는 않으며, 대안적인 블록 체인 구현 및 프로토콜은 본 발명의 범위 내에 있다 할 것이다.

본 발명의 예시적인 실시예는 계약과 같은 프로세스 또는 태스크를 모델링하는 DFA에 대한 정의와, 에이전트 또는 "봇"으로 지칭 될 수 있는 컴퓨팅 리소스의 관련 시스템을 포함한다. 에이전트는 거래를 생성하여 블록 체인에 제출한다. 그러나, 본 발명은 계약과 관련하여 사용하는 것으로 한정되지는 않는다.

다시, 도 1을 참조하면, 본 발명은 하드웨어 플랫폼 및 소프트웨어 컴포넌트를 포함하는 컴퓨팅 플랫폼(블록 체인)상에서 구현된 관념상의 DFA로서 프로세스의 실현을 제공한다. 도 1은 본 발명의 예시적인 실시예에 따라 배열된 시스템의 개요를 제공한다. 시스템은 명령을 수신하기 위해 다른 개체(4)(예를 들어, 인간 또는 다른 컴퓨터)와 상호 작용할 수 있는 컴퓨팅 에이전트(3)를 포함한다. 이 명령은 예를 들어 어떤 스마트 계약을 생성하고 실행할 수 있는지에 대한 것이다. 따라서, 컴퓨팅 에이전트(3)는 물리적 세계와 상호 작용하여 "실제 세계"에서 자신들 외부의 이벤트에 응답하고 원인을 유도함으로써 발명을 구현한다.

계약 명세서 자체는 예를 들면, xBRL과 같은 기계 실행 가능한 형식으로 제공될 수 있으며, 토렌트 네트워크의 DHT(distributed hash table)(5)와 같이 안전하고 분산된 방식으로 저장 될 수 있다. 계약 명세서로부터 컴퓨팅 에이전트는 하나 이상의 에이전트에 의해 블록 체인(1)에서 구현되는 DFA(2)를 구성한다.DFA(2) 자체는 유한 집합 {S, I, t, s0, F}로 지정된다. 여기서 S는 계약 / DFA가 될 수 있는 가능한 상태의 (유한) 집합을 나타낸다. I는 본 발명의 맥락에서 계약과 관련하여 발생할 수 있는 모든 사건 또는 조건을 의미하는 입력 (알파벳으로도 알려짐)의 (유한) 집합이다(예를 들어, 지불이 이루어지고, 상품의 만기가 도래하고, 거래 상대방의 불이행 등); 본 발명의 메커니즘에서 이러한 입력 신호는 하나 이상의 에이전트에 의해 수신 / 생성되고 시스템의 다음 상태를 결정한다 (가능하면 동일한 상태).

DFA의 세 번째 구성 요소는 전환 함수 t : S × I → S이다. "DFA"에서 용어 "결정론적"은 결정의 고유성을 나타낸다: 상태와 입력이 주어지면 단 하나의 새로운 상태(아마도 동일한 상태)가 존재한다. 따라서 초기 상태(S0)와 입력의 이력이 주어지면 계산 결과(계약)는 유일하며, 이는 모든 가능한 최종 결과(F ⊆ S)의 집합 중 하나가 된다. 이러한 모든 요소가 설정되면 DFA는 모든 가능한 현재 상태 및 입력 신호에 대하여 미래 상태를 지정하는 전환 테이블에 의해 완전히 정의된다. DFA의 상태는 자체 블록 체인의 미사용 거래 출력 (UTXO)과 관련되어 있다. 당업계에 공지 된 바와 같이, 비트코인 네트워크는 이용 가능한 모든 UTXO를 연속적으로 추적한다. 본 발명에 따르면, DFA가 하나의 상태에서 다른 상태로 전환하는 메커니즘은 블록 체인 거래에 의해 본 발명에 따라 구체화(구현)된다. 효과적으로, 블록 체인상의 거래는 하나의 상태(이전 거래의 입력)와 연관된 UTXO를 소비하고 다음 상태(출력)와 연관된 UTXO를 생성한다.

간단한 DFA 예시 : 할인(제로 쿠폰) 채권

예를 들어, 우리는 이제 보통 가격(일반적으로 액면가에 대한 할인 )으로 구입 한 간단한 부채 수단인 할인(제로 - 쿠폰) 채권을 고려한 후, 원금이 만기가 될 때까지 이를 얼마 동안 보유하도록 한다. 따라서 쿠폰 채권은 마지막 쿠폰 외에도 채권 원금이 지급 될 때까지 만기까지 계약자가 수령하는 주기적인 이자 지급 (쿠폰)이 있는 채무이다.

우리가 고려할 수있는 상태는 S = {s0, f0, f1}이다. 각각의 상태는 홀딩 상태 (s0), 계약의 정상적인 결론 (해피 패스를 따르는 경우) 또는 해피 엔딩(f0), 그리고 일이 잘못되는 상태 (f1)(예를 들면, 소송) 등을 나타낸다. 따라서 시스템의 최종 상태는 F = {f0, f1}이다. 우리가 고려할 알파벳은 각각 I = {r, d, e}로, 각각 만기 전 (또는 만료 전)의 원금 상환(r), 만기전 (또는 만료 전) 발급 기관의 채무 불이행(d), 그리고 미상환 계약 만료(e)을 나타낸다. 이 간단한 계약의 전환 행렬은 표 1에 나타나 있다.

표 1 - 제로 - 쿠폰 채권을 나타내는 DFA의 전환테이블

최종 상태는 계약의 완료를 나타내므로 더 이상 상태를 지정할 필요가 없다는 점에 유의해야 한다(해당 선은 생략 할 수 있지만 전환 테이블에서 '-'로 표시됨). 원칙적으로, 더 많은 상태 및 / 또는 입력(및 동작)이 이 명령에 대하여 정의될 수 있지만, 본 명세서에서는 단순성과 명료성을 위하여, 계약의 복잡성과 관련하여 주의를 분산시키는 것보다는 근본적으로 본 발명의 진보적인 측면을 설명하기 위하여, 이 작업을 수행하지 않았다.

도 3은 (비트코인) 블록 체인상의 제로 - 쿠폰 채권 DFA의 실시예를 나타낸다. 상태는 파란색 삼각형에 의하여 머신을 하나의 상태에서 다른 상태로 전환시키는 원 및 비트코인 거래로 표시된다. 에이전트에 의해 수신된 입력은 도 3에서 생략되었지만, 각 상태에서 하나 또는 다른 비트코인 거래(예 : 상태 s0에서 t0 또는 t1)의 구성에 의해 다이어그램에 반영된 이러한 입력에 따라 하나 또는 다른 이전환 발생해야 한다. 상태를 변경하지 않는 이전에는 거래가 필요하지 않으므로 생략되었다. 또한, DFA 의 과도기 거래(ti) 외에도 초기 거래(o) 및 계약 완료(ci)에 해당하는 거래가 고려된다.

이제 거래(초기, 이전 및 완료)에서 자금 흐름으로 주의를 전환한다. 중요한 사항은 DFA와 (금융) 계약의 유한 속성으로 인해 여러 이전 후에 프로세스가 완료된다는 것이다. 이것은 계약의 수립 및 이행에 대한 최대 비용이 구속되어 있으며 사전(예를들면, DFA 설립 시점)에 결정될 수 있다는 것을 필연적으로 의미한다(관련 컴퓨팅 에이전트 및 비트코인 채굴자에 대한 일부 유한 수수료를 가정함). 이것은 상상할 수 있는 가장 경로를 따라 계약을 이행하는 데 필요한 자금의 총액으로 주어진다. 이것은 물론 실행의 무한 루프 가능성을 배제한다. 그러나 이것은 현재의 (금융) 계약과 관련이 없으며, 영속재산(perpetuities )과 같은 계약조차도 이름에도 불구하고 미래의 어떤 시점에서 완료되어야 할 의무가 있다(예를 들어, 부채가 존재하지 않거나 인플레이션으로 인해 지급액이 무시 될 때).

수수료의 특정 분포, 각 대리인이 실제 업무의 중요성을 감안하더라도, 얼마나 많이 받는지는 본 발명의 핵심 요소는 아니다. 간소화 된 제로 - 쿠폰 채권에 대한 우리의 예시를 계속해서, 우리는 임의로 3 mBTC의 개시거래 수수료(o), 1 mBTC의 전환 수수료(ti 거래) 및 완료 거래에 대해 2 mBTC의 수수료를 부과한다 (ci); 이러한 수수료는 거래 자체에 자동으로 포함된다. 3 건의 거래에 대한 총 채굴 수수료 3mBTC와 함께 총 최대 9mBTC의 비용이 발생한다. 우리의 아주 간단한 예에서 모든 경로의 길이는 동일하다. 따라서 계약의 최종 비용은 최대 비용과 확실하게 일치한다. 이것이 일반적일 필요는 없기 때문에 일반적 자금 흐름을 완전히 설명하기 위해 계약 이행을 위해 제공되는 자금은 10 mBTC이고, 1 mBTC는 완료 후 동일한 자금원으로 반환된다고 가정한다. 완료시 최종 미사용 자금 대신에 사용된다(예를 들면, 최대 및 사용 자금이 다를 경우).

계약의 수립 및 이행을 위한 자금(10 mBTC)은 초기에 '창시자'라고 불리는 자금 소스에 의해 제공된다고 가정한다. 언급한 바와 같이, 본 예시에서 이 소스는 완료 후 사용되지 않은 1 mBTC 자금을 받게된다. 원칙적으로, 거래에서 자금의 추가적인 투입 및 산출을 할 수 있다(예를 들면, 제로 쿠폰 채권에 대해 지불한 가격, 원금 상환 또는 다른 상상할 수 있는 자금 이전). 이것은 실제 이자의 대상이 될 수 있지만, 이 시점에서 그것은 본 발명의 필수 요소를 모호하게 하는 역할을 한다. 명확성을 기하기 위해 이러한 세부 사항은 아래 예시에 포함되지 않는다. 그러나 그러한 구조는 완전히 일반적이며, 그러한 가능성이 배제되지 않는다는 점에 유의해야 한다.

기술적 솔루션 구현 예시 - DFA 시스템 및 방법

당업자라면 시스템이 다양한 방식으로 구현 될 수 있다는 것을 쉽게 이해할 것이며, 이러한 변형은 여전히 본 발명의 범위 내에 있다. 예를 들어, 에이전트 시스템(3)의 구성 및 아키텍처는 예시적으로 관련된 특정 대리인이 사전에 알려 졌는지 여부에 따라 변형될 수 있다. 여기에서는 설명을 위해 두 가지 기술 설계 옵션을 고려할 것이다.

1. 다양한 컴퓨팅 에이전트가 참여할 수 있도록 계약 참여가 상대적으로 열려 있으면. "거래 퍼즐"유형의 표준 블록 체인 거래를 기반으로하는 구조가 가능하다.

2. 반대로, 각 상태에 대한 거래가 특정 에이전트(또는 에이전트 그룹)에 미리 할당 될 수 있는 경우 pay-to-script-hash (P2SH) 거래를 사용할 수 있다.

퍼즐 기반 블록 체인 거래 및 P2SH 거래는 블록 체인 기술 분야에서 잘 알려져 있다. 당업자는 또한 상기 두 가지 옵션에 부가하여 또는 대안적으로 다수의 가능성이 존재할 수 있음을 이해할 것이다. 예를 들어, 실시예는 시간에 따라 변하는 복수의 에이전트 및 / 또는 에이전트 계층 구조 등을 사용할 수 있다. 가능성은 많지만 여기서는 2 개의 옵션만을 설명할 것이며, 이로부터 당업자는 용이하게 다른 가능한 변형 예 및 옵션을 구현할 수 있을 것이다.

그러나, 거래에서 자금을 제공 / 수신하는 당사자(발행자, 구매자, 수취인 등)가 본 발명의 필수가 아닌 것처럼, 본 발명의 실시예에서 사용되는 블록 체인 거래의 유형이 본 발명에 필수적인 것은 아니다. 대신, 본 발명의 중요한 요소는 임의의 시점에서 작업 / 계약의 상태가 블록 체인 내에 정의되고, 계약의 자동화 된 생성, 블록 체인에서의 실행, 및 발생하는 사건의 순서에 따라 적절한 결과를 이행하는 메커니즘(구체적인 구체화가 무엇이든 간에)을 제공한다는 것이다. 전체 메커니즘이 블록 체인상에 구현 되었기 때문에 본질적으로 계약의 내역 및 결과에 대한 영구적인 불변 기록을 제공하며 다른 많은 이점이 존재한다.

구현 옵션 1 : 거래 - 퍼즐 접근법

본 발명의 하나의 가능한 실시예에서, 에이전트 시스템(3)은 인터넷에 연결된 처리 능력을 가진 누군가가 참여할 수 있는 개방된 네트워크의 컴퓨터로서 구성되며, 시스템에 소정의 처리 능력을 제공 할 수 있으며(예를 들어, 블록 체인 기반 DFA 계약의 성립 및 실행의 제공자), 리소스에 대한 보상을 받을 수 있다. 그러한 상황에서 어떤 특정 에이전트가 거래를 블록 체인에 제출할 것인지 사전에 파악할 수 없다. 즉 에이전트에 대한 특정 정보(예: 공개 키)를 사용할 수 없다. 그러나, 거래 퍼즐 형식은 이러한 상황에서 사용하기에 적합하다. 이 거래 유형의 일반 잠금 / 잠금 해제 메커니즘은 다음과 같다:

잠금 스크립트(Locking Script): OP_HASH256 <state si puzzle> OP_EQUAL

잠금 해제 스크립트(Unlocking Script): <puzzle si solution>

<state si puzzle> = HASH (<state si 퍼즐 솔루션>) 및 퍼즐 솔루션 자체에는 계약 코드, 상태 라벨 및 기타 원하는 정보를 포함하여 원하는 정보가 포함될 수 있으며, 추가 보안을 위한 솔트(salt)예시는 다음과 같다:

<state si puzzle solution> = HASH (<contract code; state si; other data; salt>)

'솔트'의 개념은 선행 기술에 공지되어 있고 본 발명의 내용에서 당업자가 쉽게 이해할 수 있다. 동작 시퀀스는 도 1 및 2를 참조하여 다음과 같다. 먼저 에이전트 시스템(3, 101 단계)은 DFA 구조 2를 생성한다.

전환 테이블은 DFA를 하나의 상태에서 다른 상태로 이동할 트리거 이벤트를 지정 및 구성한다. 전환 테이블은 가능한 각 상태 전환에 대한 적어도 하나의 트리거 이벤트 또는 조건을 포함한다. 따라서, 트리거는 현재 상태(즉, 이로부터 트리거 이벤트 후에 DFA가 이동할 상태) 및 새로운 상태(즉, 트리거가 시작된 전환 후에 DFA가 존재하는 상태)와 관련된다.

도2의 102 단계에서 DFA의 각 가능한 상태에 대한 퍼즐이 가능한 한 컴퓨팅 에이전트에 의하여 생성된다. 각 전환에 대한 전환 테이블과 관련 퍼즐은 외부에 저장된다. 이것은 일종의 데이터베이스 또는 DHT에 존재할 수 있다. 퍼즐은 계약 실행에 참여할 수 있는 에이전트에게 안전하게 분배된다. 이 분배가 어떻게 달성 될 수 있는지에 대한 많은 가능성이 존재한다. 바람직한 실시예에서, 이들 단계는 사람의 개입없이 컴퓨팅 에이전트(들)에 의해 자동화 된 방식으로 수행된다.

단계 104에서, 에이전트는 상태 S0에 대한 개시 거래를 생성한다. 이는 도4와 같을 수 있다. 계약에 할당된 자금은 10 mBTC로, 에이전트 수수료는 3 mBTC, 계약의 추가 처리를 위한 출금 자금은 6 mBTC (채굴 수수료 1 mBTC가 내포되어 있음)로 가정하였다. 이 단계에서, 계약은 블록 체인상의 구조로서 구체화되고 그 첫 번째 상태 s0에 있다. 즉, 블록 체인상의 특정 계약의 상태 s0와 연관된 UTXO가 존재한다.

도4의 예시적인 거래에서 계약에 할당된 자금은 10 mBTC로, 에이전트(botnet) 수수료 3 mBTC 및 계약의 추가 처리를 위한 출금 자금 6 mBTC로 가정된다. 채굴 수수료1 mBTC는 내포되어 있다.

도4의 거래를 연구함으로써 추론할 수 있듯이 P2PKH 유형 거래를 통해 원래의 계약 자금이 수신된다(예 : '개시자'로 부터); 출력 0 (퍼즐 기반)는 퍼즐 솔루션의 속해 있는 임의의 에이전트에 의해 잠금 해제 될 수 있디; 출력 1(P2PKH)은 거래를 블록 체인에 배치하는데 성공한 에이전트(3)에게 필요한 수수료를 지급한다.

계약의 실행에 따른 연속적인 전환은 도 5와 같은 방식으로 자동화 된 에이전트(3)에 의해 수행된다. 에이전트는 현재 상태(s0)에 해당하는 퍼즐 솔루션을 얻거나 생성하거나 수신하도록 구현된다. 또한 일부 개체 또는 개체들 (예 : 에이전트 시스템의 일부 다른 컴퓨터 또는 다른 데이터 / 신호 소스)과 상호 작용하여, 적절한 입력을 수신하고, 전환 테이블(또는 현재 상태에 해당하는 부분)을 판독하며, 적절한 다음 상태(ff)에 대응되는 퍼즐을 획득한다. 그런 다음 에이전트는 거래를 블록 체인에 제출할 수 있다. 거래가 블록 체인 네트워크에 의해 유효성이 확인되면 에이전트는 관련 수수료를 받고 DFA는 상태 ff에 존재하게 된다. 도 5의 전환에서 들어오는 자금은 6 mBTC로, 대리인 수수료는 1 mBTC, 계약의 추가 처리를 위한 출금 자금은 4 mBTC(채굴 수수료 1 mBTC 는 내포되어 있음)로 가정하였다.

도6은 가능한 거래의 마지막 구조, 즉 계약 실행을 완료함(cf)을 나타낸다. 도6에서 입력 섹션은 이전과 동일한 거래 퍼즐 로직을 따르고, 출력 0은 사용되지 않은 자금을 개시자에게 반환하고(위에서 설명한 것처럼 1mBTC), 출력 1은 에이전트에게 수수료를 지불한다. 도 6에서 들어오는 자금은 4mBTC로 가정하고, 미사용 자금 1mBTC 는 개시자에게 반환되며, 에이전트 수수료는 2mBTC이다 (채굴 수수료1mBTC 는 내포됨).

구현 옵션 2 : P2SH 기반 거래

옵션 1에 설명된 퍼즐 기반 접근법은 선험적으로 알 수 없는 많은 참가자가 있을 때 사용하기 적합하다. 그러나, 다른 경우에, 제한된 또는 수용 가능한 소수의 확인된 컴퓨팅 에이전트(3)가 본 발명과 관련하여 사용되도록 지정 될 수 있다. 이 경우 P2SH 유형의 거래는 알려진 에이전트(3)의 공개키를 포함하도록 구성 될 수 있어 추가 보안 계층을 제공하므로 사용하기에 더 적합 할 수 있다. 확인된 단일 상담원의 경우, 거래를 위한 실현 가능한 잠금 / 잠금 해제 메커니즘은 다음과 같다:

잠금 스크립트(Locking Script): OP_HASH160 <state si redeem script hash> OP_EQUAL

잠금 해제 스크립트(Unlocking Script): OP_0 <agent signature> < state si redeem script>

리딤 스크립트(Redeem Script): OP_1 <state si metadata> <agent public key> OP_2 OP_CHECKMULTISIG

이것은 서명을 포함시킴으로써 많은 수의 확인된 에이전트로 확장 될 수 있다는 점에 유의해야 한다. 이전과 같이 상태 si의 메타 데이터에는 원하는 정보가 포함될 수 있다. 예를 들면 다음과 같다:

<state si metadata> = HASH (<contract code; state si; other data>)

동작 시퀀스는 퍼즐 기반 접근 방식의 경우와 유사하다. 먼저, 에이전트 시스템(3)은 DFA 구조를 생성하고, 외부에 전환 테이블을 저장한다(예를 들어, DHT). 그런 다음 어떤 에이전트가 거래를 처리하고 공개키를 검색 / 생성하는지 결정한다. 그런 다음, 공개키는 DFA의 각 가능한 상태의 리딤 스크립트에 포함되어진다. 이 스크립트는 외부적으로(블록 체인 외부에서)저장될 수 있으며, 보안 전송이 필요 없다. 다음으로, 컴퓨팅 에이전트는 도 7에 나타난 개시 거래를 생성한다. 도 7의 예시는 도 4와 유사하지만, DFA 상태에 대해 P2SH 거래 유형을 사용한다.

이 단계에서 계약은 블록 체인의 구조로 구체화되고, 첫 번째 상태 s0에 존재한다. 도4의 거래와 관련하여 거래의 유일한 변경 사항은 출력 0이다. 이 출력은 현재 P2SH 유형이며, 위에서 설명한 알려진 에이전트의 공개키를 포함한다.

변경 사항은 유사하지만, 완전성을 위해 도 8 및 9는 P2SH 거래 유형을 기반으로 한 전환 거래 및 완료 거래의 예시를 제공한다. 자금 흐름은 이전과 동일하다. 도 8은 도 5의 예시와 유사하지만 DFA 상태에 대해 P2SH 거래 유형을 사용하는 예시이다. 도 9는 도 6의 예시와 유사하지만 DFA 상태에 대해 P2SH 거래 유형을 사용하는 예시를 나타낸다.

컴퓨터 구현 DFA를 위한 새로운 체계화 기법

블록 체인 기반 DFA를 위에 설명했으므로 이제 본 발명의 특별히 유리하고 새로운 측면에 주목하도록 한다. 이 섹션에서는 DFA의 상태를 컴퓨터에서 읽을 수 있고, 실행 가능한 형식으로 체계화하기 위한 새롭고 창의적인 기술을 설명한다.

이러한 기계에 관한 종래의 방식에서, 상태는 정적으로(선험적으로) 정의되고 시스템의 일부 특정 구성을 나타내거나 특정 의미를 갖는다. 예를 들어 블록 체인 기반 DFA에 대해 위에서 설명한대로 태그 집합, 미사용 거래 출력 집합(UTXO)과 연관된 집합 또는 이름을 지정할 수 있다. (출력의)연산은 입력 체인을 받아들이는 동안 시스템이 상태간 이동 방법에 의해 결정되기 때문에 시스템이 작동하기에 충분하다.

이러한 의미에서, DFA(즉, 상태, 전환 등의 집합)는 고유하지 않으며 두 개의 DFA가 동등할 수 있다. 즉, 비록 상태에 대해 선험적으로 고안된 해석이 매우 다르다 할지라도, 주어진 입력 체인에 대해 동일한 출력을 생성한다. 예를 들어, 다른 물리적 시스템에 배치되거나 다른 문제를 해결하기 위해 고안된 경우를 고려해보면, 이는 자연스럽게 DFA 최소화 개념(https://en.wikipedia.org/wiki/DFA_minimization 참조)으로 이어진다.

상태의 정적 결정(태깅)은 스테이트 머신 자체의 관념적인 기능에 충분하고, 계산 결과만 관련되는 많은 문제에 충분하다. 그러나, 상태 자체의 의미가 실제적으로 중요하며 상태의 태그에서 추론 할 수 없는 경우가 존재한다. 예를 들어 개인 정보 보호 또는 기밀 유지를 위해 의도적으로 숨겨져 있기 때문일 수 있다. 시스템에 대한 충분한 정보를 가지고 있지 않은 에이전트를 통하여 계산이 분산 수행되는 경우에도 예제를 찾을 수 있다. 이러한 경우 런타임시 시스템의 상태를 결정하는 동적 결정이 필요하다.

여기에 기술된 본 발명의 유리한 양태는 DFA 상태의 동적 결정(런타임시 즉석에서)을 가능하게 하는 코드화 기술이다. 이러한 DFA는 상술한 바와 같이 계약의 분산된 실행과 관련된 것들을 포함 할 수 있지만, 배타적이지는 않다. 본 발명은, 본 발명의 기술이 사용되는 DFA의 목적 또는 그들의 특정 구현에 관해서 제한되지 않는다. 종래의 접근법은 상태를 정적 방식으로 미리 정의하는 것이므로, 본 발명의 동적 상태 결정은 종래의 방법론에 반하는 것으로서 당업계에 공지된 것과 완전히 다른 기술적 해결책을 제공한다. 이는 발생한 이벤트에 대해 데이터를 저장하기 위한 블록 체인의 단순 사용을 넘어서는 것이다.

본 발명의 체계화 기술에 대한 설명 및 예시를 위해, 본 발명은 이러한 예시적 용도 또는 응용에 결코 제한되지 않지만, 쿠폰 채권 및 영속성을 예시로서 사용할 것이다. 이는 비재무 응용 프로그램 및 컨텍스트에도 똑같이 적용된다. 쿠폰 채권의 성격은 앞에 설명되었다. 영속성은 끝이 없는 지불의 흐름이다. 즉, 원칙적으로 쿠폰 지급은 영원히 계속된다. 실제로, 양적(positive)인 금리 복리의 효과로 인해 어떤 시점에서 쿠폰의 양은 실용적인 의미가 없기 때문에 계약의 할인된 가치는 실제로는 유한하다.

창의적인 체계화 기법의 예시1 - 간단한 시나리오

이미 설명했듯이 DFA는 가능한 상태(S), 입력(I), 전환(t), 초기 상태(S0) 및 최종 상태(F)를 각각 나타내는 유한 집합 {S, I, t, s0, F}으로 구성된다. 최종 상태 (F)는 승인 상태라고도 한다. 또한 실행의 부작용을 나타내며 계산 결과를 결정하지 않는 일련의 동작(a)이 정의될 수 있다.

본 발명의 설명 및 예시를 위해 3주기 쿠폰 채권을 고려할 것이다. 이러한 계약에서 고려할 DFA의 요소(및 표기)는 표 2에서 4까지와 같이 정적으로 정의될 수 있다. 본 발명의 표기법에서 초기 상태는 표기법에서 S로 지정되고, 승인 상태는 F0 및 F1이다.

표 2 : 쿠폰 채권을 위한 계약 상태 리스트:

표 3 : 쿠폰 채권에 대한 계약 입력 리스트(이벤트 알파벳).

이러한 모든 입력은 컴퓨터에 의해 자동으로 감지되고 결정될 수 있다. 표 3의 위의 예시에서 컴퓨터는 특정 날짜 / 시간에 도달했는지 또는 블록 체인 거래를 통해 특정 지불이 있었는지 여부를 확인할 수 있다. 블록체인은 장부에 지불을 요하는 거래가 있는지 여부를 확인하기 위해 통과될 수 있다. 비트코인 블록 체인은 영구적인 공개 및 변조 방지 레코드를 제공하므로 이 검증은 사람의 개입 없이 컴퓨팅 에이전트에서 수행 할 수 있다.

표 4: 쿠폰 채권에 대한 계약 조치 리스트.

일단 이러한 요소가 정의되면, 시스템의 기능은(시스템의 현재 / 초기)상태(행)와 적절한 입력(열)이 결정하는 상태 전환 테이블에 따라 시스템의 다음(최종 / 종료) 상태 및 전환과 병행하여 수행할 작업에 의해 완전히 구체화 될 수 있다. 예시가 표 5에 도시되어 있다. 실행은 초기 상태(S)에서 시작하는 것으로 이해되어야 하며, 가능한 유일한 최종 상태(승인)는 F0 및 F1이다. 이들 상태는 실행의 완료를 표시하는데, 즉 이들과 관련된 전환이 없기 때문에 테이블의 행에서 생략 될 수 있다. 전환 테이블의 대체 형식은 표 5에 나와 있다.

표 5: 쿠폰 채권의 상태 전환 테이블. 시스템이 특정 상태(행)에 있고 특정 입력(열)이 발생하면 지정된 상태로 전환되고, 표시된 작업(상태 / 동작)을 수행한다; 하이픈은 입력이 주어진 상태와 관련이 없다는 것을 나타낸다(즉, 그 상태에 적용되지 않는다).

스테이트 머신의 기능을 구체화하는 또 다른 방법은 소위 상태 다이어그램이다. 여기서, 예를 들어 도10에 도시된 바와 같이, 시스템의 상태는 방울원으로 표시되고, 입력 및 동작은 부착된 레이블로 주어지며 전환은 연결 화살표로 표시된다. 최종 (승인) 상태 F0 및 F1은 규칙에 따라 겹선 방울원으로 표시된다. 단순화를 위해 시스템의 실행과 관련이 없으므로 상기 동작은 이 다이어그램에서 생략되었다. 파선 상자의 의미 (반복적인 상태)는 아래에 명확히 정의될 것이다.

전술한 바와 같이, DFA의 기능을 위해 반드시 필요하지는 않지만, 인간 및 컴퓨터 판독 가능한 시스템의 상태를 동적으로 결정하는 것은 실질적으로 필요할 수 있으며, 본 명세서에서 설명된 본 발명의 일 양상을 구성한다. 각 상태는 특정 조건에 따라 성립되거나 성립되지 않는, 또는 특정 조건에 무관한 고유한 조건 집합으로 특징된다. 각 조건은 명시적이며 (기계) 테스트가 가능해야 한다. 다시 말해, 조건이 성립하는지 여부를 판단 할 수 있는 확실한 계산 방법이 있어야 한다. 이러한 방식으로, 본 발명의 실시예는 테스트를 위한 값 또는 입력이 하나 이상의 외부 소스로부터 수신될 수 있다는 점에서 소프트웨어가 실행되는 컴퓨터 외부의 물리적 세계 또는 적어도 세계와 상호 작용할 수 있다. 예를 들어, 날짜에 도달하거나 온도 임계값이 센서에 표시된 대로 초과되거나 다른 컴퓨터에서 알림이 수신되는 등의 조건이 위에서 설명한 컴퓨팅 에이전트에 의해 테스트 될 수 있다.

본 발명의 예시에서 이것은 표 6에 제시된 조건 집합에 의해 달성 될 수 있다. 표6에서, 테스트되는 상태가 행으로 주어지고 우리가 정의한 조건이 열에 주어진다. 각 t 조건은 특정 날짜가 도착했는지 여부를 나타낸다. 예를 들어, t0로 표시된 조건은 t > t0)을 의미하고 각 ci(또는 p) 조건은 해당 지불이 이루어 졌는지 여부를 나타낸다. 아직 만기가 도래하지 않은 쿠폰(또는 원금)의 지급은 해당 만기가 도래하기 전에 발생한 상태와 관련이 없다는 점에 유의하여야 한다.

물론 이 상태 또는 동등한 조건 집합이 사용되는지 여부는 모든 가능한 상태를 고유하게 결정하는 한 관련이 없다(즉 각 상태에 대한 참, 거짓 또는 연관 없는 값의 체인이 고유하다). 이 예시에서는 바이너리(참 또는 거짓) 또는 연관 없는 조건만 고려했지만 원칙적으로 여러 값을 취할 수 있다. 또한 여기에서 고려된 원자(atomic) 조건 외에도 각 조건은 차례로 여러 조건에서 만들어진 합성 조건을 나타낼 수 있다. 이러한 모든 변형은 당업자에게 명백 할 것이며 본 발명의 범위 내에 속한다.

설명하려는 마지막 포인트는 도 10의 점선 상자의 의미이다. 다이어그램이 완벽하게 유효하고 쿠폰 채권의 동적 성질을 올바르게 설명해야 하지만, 상태 Ti와 상태 Ci 사이에 흥미로운 유사점이 있다는 것에 주목하여야 한다. 그것들은 의미가 매우 유사하기 때문에, 그들이 참조한 기간이나 쿠폰의 숫자만 상이하다(i). 따라서 그들은 공통 반복 또는 반복적인 공통 상태와 그들이 참조하는 쿠폰 / 기간을 나타내는 추가 정보로 나타낼 수도 있다. 이것은 자연스럽게 끊임없이 반복되는 상태로 자연스럽게 확장 될 수 있어, 영속적인 체계화 가능성을 열어준다. 이러한 반복적인 상태를 갖는 목록 체계화의 정의는 다음 절에서 다루어 질 것이다.

표 6: 상태 정의 테이블. 각 상태는 특정 상태에 대해 참(T), 거짓(F) 또는 관련 없음(-) 일 수 있으며, 따라서 이 동적으로 테스트 가능한 값의 집합으로 정의된다.

창의적인 체계화 기법의 예시1 - 반복되는 상태

전술했듯이, 마지막 섹션 또는 쿠폰 채권(Ti 및 Di 상태)으로부터의 쿠폰 채권 DFA 상태의 일부 하위 집합은 스테이트 머신의 상태에 대한 매우 유사한 해석에 상응하며, 기간이나 쿠폰 수에 있어서만 상이할 뿐이다. 즉 어떤 의미에서 그것들은 스스로를 여러 번 반복하는 상태로 간주 될 수 있다(i = 1에서 주어진 imax까지, 본 발명의 경우 imax = 3). 이를 감안할 때 모든 상태를 별도 처리되는 반복적인 상태(R)에 포함시켜 DFA 표현을 단순화 할 수 있다. 이 단순화를 통해 예시적인 쿠폰 채권에 대한 DFA의 계약 상태 리스트(표 7), 상태 전환 테이블(표 8), 등가 상태 다이어그램(도 11) 및 상태 정의 테이블(표 9)을 아래에 제시한다. DFA의 다른 요소(입력 및 동작)는 이전 섹션과 관련하여 변경되지 않는다.

표 7: 반복되는 상태의 쿠폰 채권에 대한 계약 상태 리스트.

표 8: 반복되는 상태의 쿠폰 채권의 상태 전환 테이블

표 9: 상태 정의 테이블. 특정 상태에 대해 각 조건은 참(T), 거짓(F) 또는 관련 없음(-) 일 수 있다. 따라서 각 조건에 대해 하나씩이 값 집합으로 정의됨 (조건이 여러 구성 요소를 가질 수는 없음).

물론 이 모든 것은 단지 반복적인 상태의 내부에서 채권 역학의 복잡성을 숨기고, 별도로 구체화해야 한다. 그러나 복잡한 스테이트 머신의 경우 이 단순화가 중요할 수 있다. 분명한 유사점은 프로그래밍 언어로 루프를 도입한 것이다. 반복적인 상태 자체는 또한 스테이트 머신으로 정의된다. 그러나 관념적인 계산의 실행은 반복되는 상태에서 시작하거나 끝내기 위한 것이 아니기 때문에, 이 맥락에서는 초기 및 승인 상태가 엔트리(entry) 및 종료점(exit points)으로 대체된다. 다음은 반복되는 상태에 대한 계약 상태(표 10), 상태 전환 테이블 (표 11) 및 스테이트 다이어그램(도 12) 목록이다.

표 10: 반복되는 상태에 대한 계약 하위 상태 리스트 :

표 11: 반복 상태의 내부 상태 전환 테이블 :

이 접근법의 참신성은 상태가 얼마나 많이 점유되었는지를 추적하는 지표(i)의 도입이다. 이 지수의 증가와 유사한 수량(예: 지불 총액)은 모두 상태 C에 대하여 표 11에 표시된대로 외부에서 계산되거나(아래의 코드화 체계의 경우와 같이) 또는 추가 DFA 동작에 의해 달성될 수 있다. 이러한 반복되는 상태의 내부 상태에 대한 입력(알파벳)은 잠재적으로 내부 인덱스(i) 및 / 또는 유사한 수량에 의존 할 수 있음에 유의하여야 한다. 앞에서 설명한 것처럼, 시스템의 예정-승인 상태(would-be accepting states )는 종료점으로 대체되었다. 해당 등가 스테이트 다이어그램은 도 12에 도시되어 있다.

이러한 반복되는 상태에 대한 체계화는 확장될 때 표 5의 관련 부분과 매우 유사하게 보일 것이다. 그러나 이 접근 방식의 정신은 각 내부(하위) 상태를 별도로 확장하고 다루는 것이 아니기 때문에, 명시적으로 테이블에 표시하는 것이 더 자연스러운 것처럼 보인다. 대신, 도 4에서는 스테이트 머신 체계화 조건과 관련된 변수에 올바른 값(True 또는 False)을 할당하는 알고리즘의 의사 코드를 제시한다. 관련성이 없는 조건과 관련된 변수에는 물론 어떤 값도 할당할 필요가 없다. 위의 표 5에서와 같이 도 4에서, 각 ti 조건은 특정 날짜가 도래하였는지(즉, ti = T는 t ≥ ti를 의미함), 각 ci 조건은 해당 i 번째 쿠폰이 지급되었는지 여부를 나타낸다.

아래에서는 반복되는 상태의 내부 상태에 대한 체계화의 조건과 관련된 변수에 적절한 값을 할당하는 알고리즘의 의사 코드를 제공한다.

설명될 마지막 요점은 인덱스 imax로 표시되는 종단점이 필요하다는 것이다. 일반적인 쿠폰 채권은 한정된 만기를 가지고 있지만, 영속성은 원칙적으로 영원히 실행되는 도구와 유사하다. 반복되는 상태의 체계화 기술을 사용하면 아래에 제시된 의사 코드의 간단한 수정으로 이를 수행 할 수 있다. 이 경우 while 루프는 만기 단계에 도달하지 않은 첫 번째 기간을 만났을 때 종료된다. 물론 이러한 변수는 무관하며 그 시점에서 모든 상태가 체계화 기술에 의해 고유하게 정의된다. 즉, 각 상태에 고유한 참 값과 거짓 값의 조합이 존재한다. 다음 의사 코드는 영속성을 위한 것이다.

표 12: 표 5의 쿠폰 채권의 상태 전환 테이블에 대한 대체 포맷

컴파일링 및 컴퓨터 실행 - DFA구현

여기서 우리는 스테이트 머신으로 모델화 된 컴퓨터 구조로서, 다른 당사자들의 약속(및 다른 조항 및 조항)의 실현에 기반한 계약상 합의의 수립(컴파일) 및 실행을 위한 새로운 기술을 설명한다.

이 섹션에서는 블록 체인을 통한 스마트 계약의 수립 및 실행에 관한 시스템의 유리한 기술적 측면을 설명한다. 이것은 계약을 효과적으로 수행할 다른 (컴퓨터)에이전트간의 정보 흐름을 다룬다. 매우 일반적으로, 우리는 이 시스템을 ‘봇네트, botnet’(컴퓨팅 에이전트 모음)라고 부르며, 종종 어떤 에이전트가 실제로 설명된 작업을 수행하는지를 구체화하지는 않을 것이다. 당업자라면 그러한 구현 세부 사항이 적용될 수 있는 많은 방법이 있음을 이해할 것이다.

전술한 바와 같이, 본 발명의 일측면을 설명하기 위해 유럽 통화 옵션에 대한 계약을 예로 사용한다. 유럽 통화 옵션은 특정 날짜(실행일)에 지정된 가격 (행사 가격)으로 주식, 채권, 원자재 또는 기타 자산을 매입할 권리를 투자자에게 부여하는 권리(의무는 아님)를 부여하는 합의이다. 옵션의 작성자(판매자)는 해당 날짜에 해당 가격으로 자산을 보유자(구매자)에게 판매 할 것을 약속하며, 구매자가 그것을 행사하기로 결정한 경우 해당 날짜의 자산 가격이 행사 가격(strike)보다 높은 경우 (합리적으로)발생한다. 이를 감안할 때 우리는 실행일에 행사 가격을 제외한 자산의 시장 가격과 동일한 금액을 보유자에게 지급함으로써 계약을 대신 해결할 수 있다고 가정한다. 그렇지 않으면 지불할 필요가 없으며 옵션은 행사되지 않은 채로 만료된다.

(재정)계약을 수립하고 이행하는 표준 방법은 법률 문서에 서명하고 그 조항을 사람이 해석하고 이행하며 때로는 논쟁하도록 하는 것이다. 이러한 계약은 용어로 정의되는 텍스트와 손에 들고 있는 계약에 고유한 파라미터에 대한 값의 집합으로 간주 될 수 있다(예를 들어 실행일, 작성자, 공개키 등). 전술한대로, 계약 텍스트의 본질이 관념적인 머신, DFA로 캡쳐되고, 계약의 특정 사례의 파라미터에 대한 값 집합이 독립적으로 제공되는 본 발명의 시스템에서 이러한 별개의 요소는 분리되어 있다.

본 발명의 예시로 돌아오면, DFA 컴퓨터 시스템은 가능한 상태(S), 입력(I), 전환(t), 초기 상태(s0), 및 최종 상태(F)(승인 상태라고도 함)를 각각 나타내는 유한 집합 {S, I, t, s0, F} 로 구성된다. 또한 DFA 구조 자체에 필수적이지는 않지만 여기서는 에이전트가 거래 제출과 병행하여 수행해야 하는 일련의 작업(a)을 고려한다. 다음과 같이 전통적으로 현재 시간(날짜)을 t, 만기일을 T, 만기일의 자산 가격을 ST, 그리고 행사 가격(strike price)을 K로 표시한다.

이 섹션의 주요 초점은 DFA시스템의 상태와 관련된 컴퓨터 에이전트를 설정하는 것이다. 이들은 스크립트를 포함하는 컴퓨팅 자원으로 구현된다. "스크립트"라는 용어는 본 맥락에서 잠금 해제 또는 잠금 스크립트와 같은 블록 체인 거래의 스크립트와 혼동되어서는 안된다. 여기서 "스크립트"라는 용어는 보다 일반적인 컴퓨팅 개념에서 사용된다. 당업자는 이것을 쉽게 이해할 수 있으며 용어의 의미를 문맥으로부터 해석 할 수 있다.

에이전트(스크립트)는 상태를 변경하고 전환을 구현하며 이와 병형해여 후속 상태와 관련된 다른 스크립트 집합을 스핀-오프(spin-off) 할 수 있다. 적절한 능력을 갖는 컴퓨터 스크립트를 이용한 DFA 상태의 동적인 런타임 식별은 본 발명의 이러한 측면의 주요 발명 요소이다. 본 발명의 간소화 된 예시의 경우, 계약의 가능한 상태와 정의를 위한 충분한 조건이 표 12에 주어져 있으며, 상태에 대한 (XML)레이블과 상태에 대한 자연(인간)어 설명이 제공된다.

모든 상상할 수 있는 상태가 계약에서 고려된 것은 아니라는 점에 유의하여야 한다(예를 들면, 파산, 소유주의 사망, 인터넷 중단 등의 경우에 어떤 일이 일어날 것인가). 그러나 이 섹션의 현재 초점은 DFA 자체의 복잡성이 아닌 계약서 작성 및 집계 분석이므로, 예시는 적절하고 가능한한 단순하지만, 더 많지는 않다.

표 13은 이 섹션의 예시에 대한 상태 정의 테이블을 표시한다. 각 조건은 특정 상태에 대해 참(T), 거짓(F) 또는 관련 없음(-) 일 수 있으며, 따라서 이 값 집합으로 각 조건에 대해 하나씩 정의된다. 순차적으로, 조건에는 여러 구성 요소가 있을 수 있음을 주목하여야 한다:

관념적인 DFA의 다른 요소에 대한 설명을 계속하여 이제 입력 리스트로 전환한다. 이를 이벤트 알파벳이라고도 한다. 예를 들어 계약과 관련하여 발생할 수 있는 이벤트의 리스트이다(예를 들어, 만기일 도래, 지불 받음 등). DFA의 현재 상태 집합과 함께 이러한 입력은 블록 체인에 제출할 거래와 에이전트에 의해 수행될 병행 조치를 결정한다: 그러나 기술적으로 전환 함수는 S × I → S 매핑이지만, 모든 입력이 모든 상태와 관련이 있는 것은 아님을 알아야 한다. 간소화 된 예시에서 이러한 항목은 (XML)레이블 및 이벤트에 대한 자연어 설명과 함께 표 13에 나와 있다.

표 14 : 계약 입력(이벤트 알파벳)의 리스트:

계산상으로, 언급된 바와 같이 일부 이벤트는 일부 (또는 전체)상태와 관련이 없으며 상태 전환을 일으키지 않지만, 이벤트는 상태를 정의하는 조건의 변화로 간주될 수 있다. 같은 의미로 가능한 모든 동작에 대한 리스트(모든 상태와 관련 있는 것은 아님)가 표 15와 같이 구체화될 수 있다.

표 15 : 계약 동작의 리스트 :

이 모든 요소는 전환과 병행하여 수행해야 할 작업과 마찬가지로, 시스템의 현재 (초기)상태(행)와 적절한 입력(열)이 시스템의 다음 (최종)상태를 결정하는 상태 전환 표에 수렴한다. 본 발명의 DFA에서는 전환 거래 외에도 완료 거래를 고려한다. 이는 시스템을 후속 상태로 두는 대신 승인 상태(f)에 놓는다. 이는 계약의 실행 종료를 나타내는 가상 상태(예: 블록 체인에서 생성되지 않고 어떠한 스크립트와도 관련되지 않음)이다. 유럽 통화 옵션의 예시가 표 16에 주어여 있다. 표 16에서는 초기 상태가 행과 연관되고, 열이 있는 입력 및 각 셀이 후속 상태 / 동작 필드를 포함한다.

표 16: 계약의 상태 전환 테이블 :

또한, 관념적인 DFA를 스테이트 다이어그램으로 표현하는 것이 일반적이다(예: 본 발명의 도 13). 이 다이어그램과 (계산적으로 유용한) 상태 전환 테이블 간에는 일치하는 면이 있으므로, 다이어그램 자체에 추가 정보는 포함되어 있지 않다. 도 13은 제출 예정인 상태(blob)와 블록 체인 거래(삼각형): 개시(o), 전환(t) 및 완료(c)를 보여주는 유럽 통화 옵션의 스테이트 다이어그램을 나타낸다.

기술적 설명

DFA 컴파일 메커니즘은 여러 요소와 파일로 구성되며 순차적으로 설명될 것이다. 이러한 파일에 포함 된 컴퓨터 구조, 다른 상태와 연관된 스크립트가 블록 체인 거래 뿐만 아니라 계약을 완전히 실행하는 후속 스크립트를 생성하는 방법이 본 응용 프로그램의 현재 섹션의 주요 초점이다. 우선 시스템은 예시적으로 두 개의 소스 파일을 사용한다:

DFA European call option - parameters.xml

DFA European call option - script.py

여기서 우리는 구체적으로 후속 파일 생성 및 계약 실행에 사용되는 주요 언어가 Python 3.5이고 파라미터가 XML 1.0 문서로 제공된다고 가정한다. 물론, 이러한 구현 세부 사항은 본 발명에 필수적인 것은 아니며, 당업자는 다른 표준의 사용이 동등하게 적용될 수 있음을 이해할 것이다.

XML 문서는 (XML 태그에 의해 지정된)파라미터 필드의 리스트 및 특정 계약의 값, 즉 임의의 특정 유럽 통화 옵션을 포함한다. 이 예시에서는 수동으로 작성했지만, 자동으로 생성될 수도 있다. 즉, 컴퓨터 자원 또는 에이전트를 계산하거나 사람이 Python으로도 만들 수 있는 GUI (Graphical User Interface)를 통해 적절한 값을 입력하는 것이다.

시스템의 기술적 구체화를 위한 주요 파일은 (Python)메인 스크립트이다. 이 파일은 DFA 입력 및 고려해야 할 동작을 지정하는 하드 코딩된 함수(예 : 가능한 상태, 입력 및 동작) 및 하드 코딩된 버전의 관념 상태 전환 테이블을 포함하거나 실행시 삽입한다(예: 주가를 확인하는 방법, 클락 등). 관련성이 있는 경우 (예: 블록 체인 기반 DFA 구현의 경우) 스크립트에 의해 네트워크에 제출되는 (비트코인) 거래의 하드 코딩된 템플릿이 포함될 수 있다.

전술한 바와 같이, 상태 전환 테이블은 관념적인 레벨에서 DFA를 완전히 결정하며, 이는 그 자체 기능을 위해 필요한 유일한 요소이다. 단, 법적 텍스트와 DFA 상태 전환 테이블 간에는 일치성이 존재함을 주목하여야 한다. 이러한 필수 요소에 더하여 선택적으로 스크립트는 사람이 판독할 수 있는 다양한 설명서를 포함하거나 생성할 수 있다(예: 스테이트 다이어그램, 알파벳 등).

블록 체인 기반 DFA 계약을 컴파일하고 실행하려면 사용자(사람 또는 컴퓨터)가 파라미터의 값을 채우고 메인 스크립트를 실행해야 한다. 이 하드 코딩된 정보를 스크립트 및 파라미터 값에 사용하면 실행시에 스크립트는 계약을 수립한다. 예: 이를 블록 체인에 배치하고 계약을 실행하는 컴퓨팅 에이전트 시스템에 의해 지속적으로 실행될 하나 이상의 컴퓨터 프로그램 (다른 스크립트)을 생성한다. 이를 수행 할 수 있는 명령 시퀀스는 다음과 같다:

1. 파라미터 값을 판독하시오(또는 GUI에서 직접 값을 입력하시오). 이렇게 하면 메모리에 파라미터 값이 로드 된다(예: 해시 테이블(HT) 구조(파이썬에서는 사전(dictionary)이라고 함) 또는 분산 해시 테이블(DHT)(예: 몇 가지 장점을 제공한다면 비트 토렌트 네트워크)).

2. 파라미터와 하드 코딩된 계약 템플릿을 사용하여 법적 계약을 생성하시오. 이 문서는 옵션 작성자가 (디지털 방식으로)서명해야 한다.

3. (선택 사항) 계약서에 사람이 판독할 수 있는 문서를 작성하시오.

4. 파라미터와 하드 코딩된 입력 및 동작 함수를 적절한 파라미터 값과 함께 사용하여 이러한 함수의 인스턴스(instances)를 생성하시오.

5. 상태 전환 테이블을 메모리(HT 또는 DHT)에 로드하시오.

6. 해당하는 경우 지정된대로, 개시 거래를 생성하여 블록 체인 네트워크에 제출하시오. 이것은 Pybitcointools 라이브러리를 사용하여 수행할 수 있다. 위의 설명과 같이 비트코인 블록 체인의 특정 계약 상태와 관련된 블록 체인에 UTXO가 생성된다.

7. 초기 상태(s0)와 연관된 Python 스크립트를 작성하고 실행하시오(동일 또는 다른 컴퓨터에서). 이 에이전트(또는 에이전트 집합)는 적절한 입력을 수신 / 생성하고 적절한 동작을 실행하며 상태와 호환 가능한 계약을 실행하고, 결국 계약 실행을 완료하거나 이러한 상태를 제어하는 후속 스크립트를 스핀 오프 하는 것과 같이 다른 상태로 전환 거래를 생성한다.

8. 컴파일을 종료하시오(메인 스크립트).

컴파일 단계가 종료되면 시스템이 가동되어 실행된다. 본 발명의 실시예에 따르면, 블록 체인에 계약의 초기 상태와 관련된 UTXO가 있을 것이며, 입력을 모니터링 할 하나 이상의 에이전트(봇네트 에이전트에서 실행되는 Python 스크립트)가 준비될 것이다. 또한, DFA의 상태를 다른 상태로 변경하거나 종료하는 적절한 전환을 생성한다.

전환을 위한 명령 시퀀스는 다음과 같다:

1. DFA 입력 모니터링 또는 생성 - 클락 확인, 메시지 수신 등과 같은 함수 호출

2. 입력이 현재 상태에 대한 전환 테이블을 읽은 것으로 판단되면, 이것은 다음 상태와 가능한 조치를 결정한다.

3. 복잡성에 따라 임의의 서브 루틴이나 함수 호출이 가능하도록 어떠한 행동을 취하시오.

4. 관련성이 있는 경우 이에 따라 전환 거래를 생성하여 블록 체인에 제출하시오.

5. 다음 상태와 관련된 Python 스크립트를 생성하고 실행하시오.

6. 현재 스크립트를 종료하시오

계약 완료를 위한 명령 시퀀스는 다음과 같다:

1. DFA 입력을 모니터링하거나 생성한다. 이것들은 클락 체크, 메시지 수신 등과 같은 서브 루틴이나 함수 호출일 수 있다.

2. 입력이 현재 상태에 대한 전환 테이블을 읽은 것으로 판단되면, 계약이 완료 되어야 하고 가능한 조치를 취할 것을 결정한다.

3. 복잡성에 따라 함수 호출이 가능하도록 어떠한 동작을 취하시오.

4. 관련성이 있는 경우 이에 따라 완료 거래를 작성하여 블록 체인에 제출하시오; 이것은 계약과 관련된 마지막 UTXO를 소비한다.

5. 현재(및 마지막) 스크립트룰 종료하시오.

따라서 DFA는 이전 에이전트에서 충분한 정보를 차례로 수신하여, 초기 메인 스크립트 및 파라미터 파일로 돌아가는 일련의 독립 에이전트(스크립트)에 의해 실행된다.

따라서, 본 발명의 일 실시예에 따르면, 계약은 (스크립트로서 구현되는) 에이전트 집합에 의해 실행되고, 상태로부터 상태로 이동하는 시스템으로서, 동적으로 생성된다. 이러한 에이전트는 시스템의 현재 상태(예: 블록 체인의 UTXO에 의해 구체화 됨)에 액세스하고, 실제 세계에서 일어나는 이벤트에 따라 적절한 입력을 수신하거나 생성하고, 적절한 동작을 취하고, 적절한 거래를 실행해야 한다. 이 모든 작업은 적절하게 정의된 함수와 기존 라이브러리를 사용하여(예: Python) 스크립트 내에서 수행될 수 있다. 예를 들어, 유럽 통화 옵션의 경우 클락에 액세스하여 계약 만기일에 도달했는지 여부와 자산의 현재 가격을 확인해야 한다. 이 정보가 주어지면 파라미터에 따라 고려해야 할 적절한 입력을 결정할 수 있다. 이에 따라, 전환 행렬에 따른 동작이 지정되면, 에이전트는 생성할 블록 체인 거래를 결정할 수 있으므로, 시스템을 다음 상태(본 발명의 경우 하나만 있음)에 배치하거나 계약의 실행을 적절하게 완료 할 수 있다.

전술한 실시예들은 본 발명을 제한하는 것이 아닌 예시임을 알아야하며, 당업자는 첨부된 청구 범위에 의해 정의된 본 발명의 범위를 벗어나지 않고 많은 대안적인 실시 예를 설계 할 수 있음을 알아야 한다. 청구 범위에서, 괄호안의 임의의 참조 부호는 청구 범위를 제한하는 것으로 해석되어서는 안된다. 용어 "포함하는" 및 “포함한다” 등은 청구 범위 또는 명세서 전체에 열거된 요소 또는 단계 이외의 요소의 존재를 배제하지 않는다. 본 명세서에서, "포함한다"는 "포함하거나 구성된다"를 의미하고 "포함하는"은 "포함하거나 구성되는"을 의미한다. 요소의 단일 참조는 이러한 요소의 복수 참조를 배제하지 않으며, 그 반대도 마찬가지이다. 본 발명은 몇몇 별개의 요소들을 포함하는 하드웨어에 의해, 그리고 적합하게 프로그래밍 된 컴퓨터에 의해 구현 될 수 있다. 여러 수단들을 열거하는 장치 청구항에서, 이들 수단들 중 몇몇은 하나의 동일한 하드웨어 아이템에 의해 구현 될 수 있다. 특정 측정 값이 서로 다른 종속 항에서 인용된다는 단순한 사실만으로 이 측정 값의 조합을 활용할 수 없다는 것을 의미하지는 않는다.

Claims

블록 체인 상에 DFA를 구현하는 방법에 있어서,
블록 체인 거래(Tx1)의 미사용 출력 (UTXO1)의 잠금 스크립트에 있는 데이터의 일부를 DFA의 주어진 상태와 연관시키는 단계를 포함하는 방법.
제 1 항에 있어서,
추가 거래(Tx₂)를 사용하여 상기 거래(Tx₁)의 출력 (UTXO₁)을 소비함으로써 상기 DFA 상태로부터 다른 상태로 전환하는 단계를 더 포함하며,
상기 다른 상태는 상기 추가 거래의 미사용 출력(UTXO₂)의 잠금 스크립트 내에 제공된 데이터의 일부와 연관되는 방법.
제 1 항 또는 제 2 항에 있어서,
실행될 때 추가 거래(Tx2)가 상기 거래(Tx1)의 상기 출력 (UTXO1)을 소비하게 하여 상기 DFA를 다른 상태로 전환시키는 적어도 하나의 상태 전환 트리거를 구현 또는 표현하기 위해 코드의 일부를 사용하는 단계를 더 포함하는 방법.
제 3 항에 있어서,
상기 코드의 일부는 입력에 기초하여 부울(Boolean) 결과를 제공하는 머신 - 테스트 가능한 조건을 포함하는 방법.
제 4 항에 있어서, 상기 입력은 런타임시에 결정되며, 상기 DFA를 상기 다른 상태로 전환시키기 위하여 상기 미사용 출력(UTXO1)이 소비되어야 하는지 여부를 결정하기 위해 상기 코드의 일부에 의해 사용되는 방법.
이전 청구항 중 어느 한 항에 있어서, 상기 미사용 출력(UTXO1)의 데이터 일부는 잠금 스크립트로 제공되는 방법.
제 6 항에 있어서, 상기 데이터 일부는 태그, 라벨 또는 메타 데이터의 일부인 방법.
이전 청구항 중 어느 한 항에있어서,
상기 DFA는 기계 실행 가능한 스마트 계약 모델인 방법.
이전 청구항 중 어느 한 항에 있어서,
상기 미사용 출력(UTXO1)은,
상기 출력 (UTXO1)을 소비하고 상기 DFA를 다른 상태로 전환하기 위해 추가 거래의 입력에 의해 솔루션이 제공되어야 하는 퍼즐의 해시를 포함하는 잠금 스크립트를 포함하는 방법.
이전 청구항 중 어느 한 항에 있어서,
상기 미사용 출력(UTXO1)은 상기 출력(UTXO1)을 소비하고 상기 DFA를 다른 상태로 전환시키기 위해 추가 거래의 입력에 의해 제공되어야 하는 리딤 스크립트의 해시를 포함하는 잠금 스크립트를 포함하는 방법.
제 10 항에 있어서, 상기 리딤 스크립트는 암호키를 포함하는 방법.
이전 청구항 중 어느 한 항에 있어서,
전술한 임의의 단계를 수행하기 위해 하나 이상의 컴퓨팅 에이전트를 사용하는 단계를 더 포함하는 방법.
블록체인상에 DFA를 구현하는 방법에 있어서,
입력 신호를 모니터링 및 / 또는 수신하고, 상기 입력 신호에 응답하여, 미사용 출력(UTXO)을 포함하는 블록 체인 거래(Tx2)를 생성하고 이전 거래(Tx1)의 출력을 소비하는 프로그램을 실행하는 단계를 포함하며,
상기 이전 거래 (Tx1)의 출력은 상기 DFA의 제 1 상태와 관련된 식별자를 포함하는 잠금 스크립트를 포함하고,
거래 (Tx2)의 상기 미사용 출력 (UTXO)은 상기 DFA의 다른 상태와 연관된 추가 식별자를 포함하는 잠금 스크립트를 포함하는 방법.
블록체인상에 DFA를 구현하는 방법에 있어서,
적어도 하나의 입력 신호를 사용하여 적어도 하나의 조건을 실행하고, 상기 조건의 실행 결과에 기초하여 상기 DFA에 대한 상태 전환 테이블에 따라 동작을 수행하는 단계를 포함하며,
상기 동작의 수행은 블록 체인 장부(blockchain ledger)의 상태로부터 식별 가능한 방법.
제 1 항 내지 제 14 항 중 어느 한 항의 방법을 구현하도록 구성된 시스템.
제 15 항에 있어서, 상기 시스템은,
블록 체인 플랫폼;
상기 블록 체인을 통해 상기 DFA를 구현하도록 배치된 적어도 하나의 컴퓨팅 에이전트를 포함하는 시스템.