KR20200101328A - 선언적 스마트 계약 - Google Patents

선언적 스마트 계약 Download PDF

Info

Publication number
KR20200101328A
KR20200101328A KR1020207012480A KR20207012480A KR20200101328A KR 20200101328 A KR20200101328 A KR 20200101328A KR 1020207012480 A KR1020207012480 A KR 1020207012480A KR 20207012480 A KR20207012480 A KR 20207012480A KR 20200101328 A KR20200101328 A KR 20200101328A
Authority
KR
South Korea
Prior art keywords
call
block
execution
declarative
calls
Prior art date
Application number
KR1020207012480A
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 KR20200101328A publication Critical patent/KR20200101328A/ko

Links

Images

Classifications

    • 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
    • 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/3825—Use of electronic signatures
    • 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/3829—Payment protocols; Details thereof insuring higher security of transaction involving key 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction 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/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • 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
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • 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
    • 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
    • H04L2209/38—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Measurement And Recording Of Electrical Phenomena And Electrical Characteristics Of The Living Body (AREA)
  • Prostheses (AREA)
  • Storage Device Security (AREA)

Abstract

블록체인의 블록을 그 블록체인에 추가되게 하는 구성은, 엔티티가 이전 블록에 대응하는 정보를 수신하게 하는 단계, 주어진 입력에 대한 스마트 계약 실행의 선언적 호출을 엔티티가 수신하게 하는 단계(이때, 선언적 호출은 실행의 관련 결과 및 다른 관련 데이터를 선언함), 엔티티가 호출의 구문론적 유효성을 검증하게 하는 단계, 호출의 구문론적 유효성의 검증에 응답하여, 엔티티가 선언적 호출을 블록에 통합하게 하는 단계를 포함한다. 관련 결과는, 스마트 계약 실행의 순 효과, 실행 후의 스마트 계약의 결과적인 상태, 및 실행을 위한 단계의 수를 특정할 수 있다. 다른 관련 데이터는, 선언적 호출의 호출자, 시간 정보, 블록 정보, 및/또는 지불가능한 요금을 특정할 수 있다.

Description

선언적 스마트 계약
본원은, 전자 트랜잭션 분야에 관한 것으로서, 더욱 구체적으로는, 전자 트랜잭션을 위한 트랜잭션 블록들의 시퀀스의 콘텐츠를 안전하게 하는 분야에 관한 것이다.
스마트 계약은, 사용자와 마찬가지로, 자신의 고유한 돈을 소유할 수 있는 컴퓨터 프로그램이라고 여겨질 수 있다. 이러한 계약(C)은, 각각의 호출(invocation) 후에 수정될 수 있는 자신의 고유한 보유 (연산) 상태, 및 자신의 고유한 식별자, 예컨대, 스트링(H(C))을 가질 수 있으며, 여기서, H는 해시 함수이다. 간단히 하기 위해, 이 식별자를 C 자체로 표기한다. 독자는 C가 프로그램 자체일 때 또는 식별자일 때를 쉽게 결정할 수 있다. 바람직하게, 스마트 계약(C)은 일반 사용자와 쉽게 구별될 수 있다. 본원에서 플레이어란, 스마트 계약 또는 일반 사용자를 의미한다.
스마트 계약(C)의 실행은 하나 이상의 적절한 사용자에 의해 호출될 수 있다. 간단히 하기 위해, 그러나 의도한 일반성을 전혀 잃지 않고서, 여기서는, C가 단일 사용자(i)에 의해 호출된다고 가정한다(주석 1: 결국, 여러 사용자가 C를 호출할 수 있을 때, 이러한 사용자들 중 한 명이 종종 C를 먼저 실행하므로, 다른 적절한 사용자가 C를 호출하기 전에 보유 상태를 수정하게 된다. C가 상태값을 갖지 않는 경우라면, 적절한 사용자들의 순서는 중요하지 않을 수 있다. 그렇지 않다면, 예컨대 두 명의 적절한 사용자가 C를 독립적으로 동시에 호출하더라도, 한 명이 두 개의 실행을 위한 순서를 고를 수 있고, 두 번째 실행을 실행하기 전에 첫 번째 실행이 "종료"되기를 기다릴 수 있다. 당업자는, 다수의 사용자에 의해 호출된 경우에만 C가 실제로 '시스템에 의해' 실행되고 또한 이러한 계약들이 본 발명자들의 기술에 의해 처리될 수 있도록 C를 작성할 수 있음을 인식할 수 있다).
i를 시스템의 C 실행을 호출할 수 있는 사용자라고 하자. 사용자(i)는 디지털 서명에 의해 C를 호출한다. 이러한 i의 서명된 호출은, C 외에도, 입력(input) 및 요금(fee)을 특정할 수 있다.
이를 상세히 설명하고자 한다.
● input은 C를 실행할 특정 입력을 자세히 설명하는 것이다. 물론, 기본 입력과 같은 추가 입력이 있을 수 있으며, 예를 들어 C의 현재 상태(
Figure pct00001
)(실제로 입력으로 여겨질 수 있음) 및 시스템의 전체 상태(예를 들어, 주어진 블록에서 각 플레이어가 소유하는 금액)가 있다.
● fee는, 'C를' 실행하는 데 발생하는 연산 비용을 시스템에 보상하기 위해 i가 지불가능한 금액을 포함한다.
C를 호출할 때, 사용자(i)는 일부 추가 정보를 특정할 수도 있다. 예를 들어, 사용자는, 주어진 블록(및 이에 따라 블록체인의 주어진 '스냅샷'), 또는 계약(C)의 실행이 주어진 블록에서 또는 블록들의 간격에서 시행될 수 있음을 특정할 수 있다. 또한, C가 지금까지의 전체 블록체인 이력을 고려할 수 있음을 생각할 수 있다. 요약하자면, 추가 (및 암시적일 수 있는) 입력이 있을 수도 있다.
요금은, 또한, 다른 임의의 트랜잭션처럼, 블록체인에 사용자의 호출을 포함하기 위해 i가 지불해야 하는 금액을 포함할 수 있다. 그러나, 본 발명에 의해 완화되는 문제점에 중점을 두도록 통상적인 요금인 이러한 금액을 무시하고자 한다.
C 실행의 연산 단계들의 수는 실행이 실시되는 기계에 의존한다. 이에 따라, 고정된 (가상) 기계(M)에서 C(입력)를 연산하는 것을 고려한다.
C를 실행함으로써, 일반적으로 새로운 보유 상태(
Figure pct00002
)를 생성하고, 몇 명의 플레이어(x, y,...)가 소유하는 금액을 아래의 금액만큼 각각 증분 또는 감분한다.
Figure pct00003
C의 사용자(i)의 서명된 호출은, 그 시점에서, i가 i의 호출에 특정된 요금인 fee 이상의 금액을 보유하는 경우에만, 주어진 블록에서 블록체인에 진입할 수 있다.
호출이 실제로 단일 실행에 해당하는 것을 방지하기 위해 통상적인 방법(예를 들어, nonces)이 사용된다. 이러한 방법은, 당면한 문제 및 발명에 중요하지 않으므로, 의도된 일반성을 전혀 잃지 않고 본원에서 무시된다. 유사하게, 모든 종류의 다른 발명마다 독립적인 세부 사항에 대해서도 마찬가지이다.
일단 i의 호출이 블록체인의 블록에 진입하면, 사용자들의 클래스(U)의 모든 사용자(u)는, 요금에 의해 커버되는 단계들의 금액에 대하여 (C에 의해 도달되는 최종 보유 상태를 이용하여 가상 기계(M)에서) C를 실행하고, i가 보유하는 금액으로부터 요금을 차감함으로써 블록체인 데이터의 자신의 고유한 버전을 갱신하고, 실행이 적절하게 종료되면, (C 자체가 보유하는 금액을 포함할 수 있는) C 실행에 의해 영향을 받는 플레이어가 보유하는 금액을 (다시, 블록체인의 자신의 고유한 버전으로) 수정한다. 이러한 모든 사용자에 의한 C의 실행을 C의 시스템 실행이라고 칭할 수 있다. 전형적으로, 클래스(U)는, 모든 사용자 또는 매우 많은 수의 사용자(예를 들어, 블록체인에 새로운 유효한 블록을 생성하는 데 기여하고자 하는 모든 사용자)로 이루어진다.
사용자들의 수가 많으면, 단계들의 수가 다소 적더라도 시스템의 총 비용이 매우 높을 수 있다. 이는, 단계들의 수는 전혀 많지 않지만 호출자가 지불할 수 있는 요금도 매우 높아야 함을 의미한다. 이 상황에서, 블록체인 시스템에서는, 단계들이 거의 없는 스마트 계약만을 실행하는 것이 타당하다. 이것은 유감스러운 일이다. 시스템의 사용자들은, 적지 않은 수의 연산 단계를 필요로 하는 많은 스마트 계약의 실행을 호출함으로써 이익을 얻을 수 있지만, 지불해야 하는 과다한 요금으로 인해 이러한 실행을 호출할 수 없다.
본원에서 설명하는 시스템에 따르면, 트랜잭션들이 블록들로 조직되는 트랜잭션 시스템에서, 이전 블록들(B0, B1,..., Br - 1)의 시퀀스에 관하여 새로운 블록들(Br 및 Br+ 1)을 제공하는 구성은, 블록(Br)이 블록(Br-1)의 트랜잭션들의 상태와 일치하는 트랜잭션들의 초기 상태들을 나타냄을 확인한 후에 블록(Br)이 구성되게 하는 단계; 블록(Br+1)이 블록(Br)의 트랜잭션들의 상태와 일치하는 트랜잭션들의 초기 상태들을 나타냄을 확인한 후에 블록(Br+1)이 구성되게 하는 단계; 및 블록(Br+1)이 구성된 후에 복수의 엔티티가 블록(Br)의 이전에 검증되지 않은 트랜잭션들을 검증하게 하는 단계를 포함한다. 트랜잭션들은 스마트 계약들일 수 있다. 사용자는, 블록(Br)의 스마트 계약들 중 적어도 하나에 트랜잭션을 게시하는 것과 관련하여 블록(Br)을 구성할 수 있다. 사용자는, 또한, 블록(Br)의 스마트 계약들에 대한 트랜잭션 결과를 게시할 수 있다. 사용자는, 또한, 블록(Br)의 스마트 계약들에 대한 스마트 계약 결과의 실행을 위한 단계의 수를 게시할 수 있다. 사용자는, 또한, 블록(Br)의 트랜잭션들을 검증하도록 복수의 엔티티가 수신하는 요금을 게시할 수 있다. 복수의 엔티티는 블록(Br)의 모든 사용자들의 서브세트일 수 있다. 복수의 엔티티는 랜덤하게 선택될 수 있다. 복수의 엔티티를 랜덤하게 선택하는 단계는, 시간 정보, 블록들 중 하나 이상에 대한 정보, 블록들 중 하나 이상에 포함된 데이터, 또는 블록들 중 하나 이상으로부터 추론된 데이터 중 적어도 하나를 포함하는 데이터에, 암호화 해시 함수를 적용하는 단계를 포함할 수 있다.
또한, 본원에서 설명하는 시스템에 따르면, 블록체인의 블록(B)을 블록체인에 추가하는 구성은, 엔티티가 이전 블록에 대응하는 정보를 수신하게 하는 단계; 주어진 입력에 대한 스마트 계약 실행의 선언적 호출을 엔티티가 수신하게 하는 단계로서, 선언적 호출은 실행의 관련 결과 및 다른 관련 데이터를 선언하는, 단계; 엔티티가 호출의 구문론적 유효성(syntactic validity)을 검증하게 하는 단계; 및 호출의 구문론적 유효성의 검증에 응답하여, 엔티티가 선언적 호출을 블록(B)에 통합하게 하는 단계를 포함한다. 관련 결과는, 스마트 계약 실행의 순 효과, 실행 후의 스마트 계약의 결과적인 상태, 및 실행을 위한 단계의 수 중 적어도 하나를 특정할 수 있다. 다른 관련 데이터는, 선언적 호출의 호출자, 시간 정보, 블록 정보, 및/또는 지불가능한 요금을 특정할 수 있다. 선언적 호출은, 요금이 실행을 위한 단계의 수에 대하여 적합하고 요금의 지불자가 요금을 지불하기 위한 충분한 자산을 갖고 있다면, 구문론적으로 유효하고, 선언적 호출이 블록체인에 보이면 요금이 지불될 수 있다.
또한, 본원에서 설명하는 시스템에 따르면, 블록체인의 검증자들의 세트를 지정하여 주어진 입력에 대한 스마트 계약 실행의 하나 이상의 선언적 호출의 세트(S)를 검증하는 단계(선언적 호출은 스마트 계약 실행의 관련 결과를 선언함)은, 검증자들이 세트(S)를 수신하는 단계; 검증자들이 S의 선언적 호출 중 어느 것이 의미론적으로 유효한지를 결정하는 단계; 및 검증자들이 의미론적으로 유효한 하나 이상의 선언적 호출의 인증된 응답을 제공하는 단계를 포함한다. 검증자들의 세트는, 주어진 암호화 함수를 통해 의사 랜덤 방식으로 S에 기초하여 선택될 수 있다. 적어도 하나의 검증자는, 적어도 하나의 검증자의 비밀 키를 수반하는 연산을 통해 적어도 하나의 검증자가 선택되었다고 결정할 수 있고, 적어도 하나의 검증자는 적어도 하나의 검증자가 선택되었음을 다른 검증자들에 증명할 수 있다. S에 지정된 적어도 주어진 개수의 검증자들의 응답이 호출(I)이 의미론적으로 정확함을 나타내면, S의 호출(I)은 정확한 것으로 간주될 수 있다.
또한, 본원에서 설명하는 시스템에 따르면, 선언적 스마트 계약 호출들의 세트(S)가 미리 등록되었으며, 검증자들의 세트가 S에 지정되고, 검증자들이 S의 호출들 중 의미론적으로 유효한 호출에 관한 인증된 응답들을 제공한 블록체인에서, S의 호출들의 베르딕트(verdict)가 블록체인에 통합되게 하는 구성은, 엔티티가 검증자들의 인증된 응답들을 수신하게 하는 단계; 엔티티가 S의 호출들의 정확성을 추론하게 하는 단계; 및 엔티티가 S의 호출들의 정확성에 관한 최종 베르딕트를 블록체인에 통합하게 하는 단계를 포함한다. S의 호출(I)의 최종 베르딕트는, S에 지정된 적어도 주어진 개수의 검증자들의 응답들이 I가 의미론적으로 유효함을 나타내면, I가 정확함을 나타낼 수 있다. S의 호출(I)의 최종 베르딕트가 I가 정확함을 나타내면, 다른 사용자들이 스마트 계약의 상태를 갱신하게 하고 스마트 계약의 실행의 선언된 순 효과가 발생한 것으로 간주하게 할 수 있다.
또한, 본원에서 설명하는 시스템에 따르면, 블록체인의 블록(B)을 블록체인에 추가하는 구성은, 엔티티가 이전 블록에 대응하는 정보를 수신하게 하는 단계; 주어진 입력에 대한 스마트 계약 실행의 커밋(commit)된 선언적 호출을 수신하는 단(커밋된 선언적 호출은, 실행의 적어도 일부 관련 결과, 실행의 다른 관련 결과에 대한 커밋, 및 다른 관련 데이터를 선언함); 커밋된 선언적 호출의 구문론적 유효성의 검증을 야기하는 단계; 및 커밋된 선언적 호출의 구문론적 유효성의 검증에 응답하여, 블록(B) 내의 커밋된 선언적 호출의 통합을 야기하는 단계를 포함한다. 관련 결과는 실행의 순 효과, 실행 후의 계약의 결과적인 상태, 및/또는 단계의 수를 특정할 수 있고, 다른 관련 데이터는 호출의 호출자, 시간 정보, 블록 정보, 및/또는 지불가능한 요금을 특정할 수 있다. 선언적 호출은, 단계의 수에 대하여 요금이 적절하고 요금의 지불자가 요금을 지불할 충분한 자산을 시스템에서 갖고 있으면, 구문론적으로 유효할 수 있고, 호출이 블록체인에 나타나면 요금이 지불될 수 있다.
또한, 본원에서 설명하는 시스템에 따르면, 주어진 입력에 대한 스마트 계약의 실행(e)을 특정하는 적어도 하나의 커밋된 선언적 호출(I)을 포함하는 선언적 호출들의 세트(S)를 검증하도록 블록체인 내의 검증자들의 세트가 지정되게 하는 구성(I는 e의 적어도 일부 관련 결과(rr)에 대한 커밋을 포함함)은, 검증자들이 세트(S)를 수신하는 단계; 검증자들이 실행(e)을 재구성하여 관련 결과(rr)를 연산하는 단계; 검증자들이 검증자들의 rr에 대한 개인화된 커밋을 포함하는 인증된 응답을 제공하는 단계를 포함한다. 지정된 검증자들은, 주어진 암호화 함수를 통해 의사 랜덤 방식으로 S에 기초하여 선택될 수 있다. 적어도 하나의 검증자는, 적어도 하나의 검증자가 적어도 하나의 검증자의 비밀 키를 포함하는 연산을 통해 선택되었음을 결정할 수 있고, 적어도 하나의 검증자는 적어도 하나의 검증자가 선택되었음을 다른 이들에게 증명할 수 있다. S 내의 커밋된 선언적 호출(I)은, S에 지정된 적어도 주어진 수의 검증자들의 응답들이 I에 커밋된 관련 결과(rr)에 대한 개인화된 커밋을 포함하는 경우에만, 정확한 것으로 간주될 수 있다.
또한, 본원에서 설명하는 시스템에 따르면, 선언적 스마트 계약 호출들의 세트(S)가 미리 등록되고, 검증자들의 세트가 S에 지정되고, 세트(S)는 주어진 입력에 대한 스마트 계약의 실행(e)을 특정하는 적어도 하나의 커밋된 선언적 호출(I)을 포함하고, I는 e의 적어도 일부 관련 결과(rr)에 대한 커밋을 포함하고, 검증자들은 S의 호출들에 관한 인증된 응답들을 제공한 블록체인에서, S의 호출들의 베르딕트가 블록체인에 통합되게 하는 구성은, 엔티티가 검증자들의 인증된 응답들을 수신하게 하는 단계; 엔티티가 S의 호출들을 정확성을 추론하게 하는 단계; 및 엔티티가 S의 호출들의 정확성에 관한 최종 베르딕트를 블록체인에 통합하게 하는 단계를 포함한다. S에 지정된 적어도 주어진 수의 검증자들의 응답들은 I에 커밋된 동일한 관련 결과(rr)에 대한 개인화된 커밋을 포함할 수 있고, S 내의 커밋된 선언적 호출(I)의 최종 베르딕트는 I가 정확함을 나타낼 수 있다. I의 정확성의 최종 베르딕트는, 다른 사용자들이 스마트 계약의 상태를 갱신하게 하고 스마트 계약의 실행(e)의 순 효과가 발생한 것으로 간주하게 할 수 있다.
또한, 본원에서 설명하는 시스템에 따르면, 비일시적 컴퓨터 판독가능 매체에 제공된 컴퓨터 소프트웨어는, 본원에서 설명하는 단계들 중 임의의 것 또는 모두를 구현하는 실행가능 코드를 포함한다.
스마트 계약을 위한 대체 기술.
블록체인 상에 스마트 계약을 구현하기 위한 새로운 기술을 제시한다. 이러한 새로운 기술은, 통상적인 기술과 더불어 구현될 수 있으며, 매우 고가이어서 전통적인 기술을 통해 다룰 수 없는 부류의 계약들을 효율적으로 다룰 수 있다.
큰 부류의 계약들.
새로운 기술은, 아래와 같은 스마트 계약에 특히 유용하다.
● 실행으로부터 다음 실행으로 변할 수 있는 내부/연산 상태(간략하게, 상태)
● 순 효과(예를 들어, 새로운 상태, 한 당사자로부터 다른 당사자로의 금전 이체 등)를 간결하게 기술할 수 있다. 이 기술에 의해 이하의 사항들을 필요로 하는 스마트 계약도 다룰 수 있다는 점을 강조하고자 한다.
● 매우 많은 연산 단계, 및
● 매우 많은 양의 메모리
실제로, 실행에 사용되는 메모리는 매우 클 수 있는 반면, 다음 실행을 위해 보유되는 상태 정보는 매우 간결할 수 있으며, 예를 들어, 몇 개의 경계값 변수로 이루어질 수 있다. 중요한 것은, 상태비저장(stateless) 스마트 계약이 이러한 특성을 대수롭지 않게 충족하며 매우 강력하다는 점이다.
물론, 일부 스마트 계약은, 주어진 원하는 바를 달성하기 위해 상태 저장일 필요가 있을 수 있다. 그러나, 우리의 새로운 기술에서는, 스마트 계약의 보유 상태의 크기를 간결화하도록 이러한 스마트 계약을 설계하는 것이 애플리케이션 설계자들의 관심 사항일 것이다.
블록체인 - 애그노스틱 기술.
이 기술은, 알고랜드(Algorand) 기술의 핵심 구성요소인 암호적으로 안전한 자체 선택 기술인 (비밀) 암호화 추첨을 새롭게 이용하며, 이 기술은 2017년 5월 4일에 출원된 국제출원번호 PCT/US2017/031037에 개시되어 있으며, 이 문헌은 본원에 참고로 원용된다. 또한, 알고랜드 기술은, 본원의 다른 섹션에서 참고로 원용되는 특허 출원들 중 전부는 아니더라도 대부분에서 설명되어 있다.
그러나, 다른 장점들에도 불구하고, 새로운 부류의 스마트 계약들을 다루기 위한 새로운 기술을 사용하기 위해 알고랜드를 기본 블록체인 플랫폼으로서 사용할 필요는 없다. 새로운 기술은 비트코인, 이더리움 등의 다른 임의의 플랫폼들과 함께 사용될 수 있다.
나중에 언급하겠지만, 이러한 알고랜드를 기본 블록체인 엔진으로서 사용하면, 몇 가지 추가 장점이 있다.
본원에서 설명하는 시스템의 실시예들은 도면의 해당 도에 따라 보다 상세하게 설명되며, 이러한 도면은 다음과 같이 간단히 설명된다.
도 1은 본원에서 설명하는 시스템의 일 실시예에 따른 네트워크 및 연산 스테이션의 개략도이다.
도 2는 본원에서 설명하는 시스템을 포함하는 블록체인의 개략적이고 개념적인 요약이다.
본원에서 설명하는 시스템은, 스마트 계약을 포함하는 블록체인 내의 블록들을 검증하기 위해 워크스테이션(검증자)이 필요로 하는 연산을 감소시키고 효율을 개선하는 메커니즘을 제공한다.
도 1을 참조하면, 이 도면은 인터넷과 같은 데이터 네트워크(24)에 접속된 복수의 연산 워크스테이션(22a 내지 22c)을 도시한다. 워크스테이션(22a 내지 22c)은, 본원의 다른 곳에서 더욱 상세히 설명되는 바와 같이, 분산형 트랜잭션 전파 및 검증을 제공하도록 네트워크(24)를 통해 서로 통신한다. 워크스테이션(22a 내지 22c)이 서로 통신할 수 있다면, 시스템은 본원에서 설명하는 기능을 제공할 수 있는 임의의 수의 워크스테이션을 수용할 수 있다. 각각의 워크스테이션(22a 내지 22c)은, 본원의 다른 곳에서 더욱 상세히 설명되는 바와 같이, 시스템의 다른 모든 워크스테이션에 트랜잭션을 전파하고 트랜잭션/블록을 검증하고 검증자로서 기능하는 처리를 독립적으로 수행할 수 있다.
도 2를 참조해 보면, 블록체인(200)은 복수의 블록(202 내지 205)을 포함한다. 각각의 블록은, 본원의 다른 곳에서 더욱 상세히 설명되는 바와 같이, 하나 이상의 스마트 계약 및 추가 정보를 포함한다. 블록(202)은 블록체인(200)의 가장 오래된 블록이고, 블록(203)은 다음으로 가장 오래된 블록이며, 이러한 방식으로 계속된다. 블록(205)은 블록체인(200)의 최신 블록이다. 블록체인(200)에는 임의의 수의 블록이 있을 수 있다. 블록들(202 내지 205) 각각은, 예를 들어, 블록(203)이 블록(202)의 유효성을 확인하는 정보를 포함하고 블록(204)이 블록(203)의 유효성을 확인하는 정보를 포함하도록 이전 블록의 유효성을 확인하는 정보를 포함한다. 따라서, 블록체인(200) 내의 블록들(202 내지 205) 중 검증된 하나의 최신 블록은 선행 블록의 유효성을 직접 확인하고 다른 모든 선행 블록들의 유효성을 간접적으로 확인한다. 본원의 일 실시예에서, 블록들(202 내지 205) 각각은 블록들(202 내지 205) 중 이전 블록의 서명된 해시를 포함하지만, 당업계에 알려진 다수의 종래의 블록체인 메커니즘을 비롯한 다른 메커니즘들이 이전 블록들을 확인하거나 이러한 블록들의 유효성을 확인하는 데 사용될 수 있다. 또한, 본원의 다른 곳에서 더욱 상세히 설명되는 바와 같이, 블록들(202 내지 205) 중 하나 이상이 검증될 수 있고 블록의 진위성 여부에 대한 베르딕트를 포함할 수 있다. 블록들(202 내지 205) 중 하나 이상의 최신 블록은, 본원의 다른 곳에서 더욱 상세히 설명되는 바와 같이, 초기에 검증되지 않을 수 있으며 후속하여 검증 및 인증될 수 있다.
이상적으로, 스마트 계약(C)의 실행을 호출하는 요금은, 그 실행으로 인해 시스템에서 발생하는 연산의 총 비용과 일치해야 한다. 그러나,
C를 실행하는 시스템의 총 비용은 얼마인가?
사용자가 n명이고 (주어진 기계(M)에서) C의 실행이 #개 단계(#steps)로 이루어진 경우, 총 시스템 비용은 다음과 같이 추정될 수 있다.
n × #steps(주석 2: 여기서, 모든 사용자는 새로운 블록의 정확성을 확인하고 그 블록이 포함하는 모든 스마트 계약을 실행한다고 가정한다. 일부 블록체인 플랫폼에서는, 전체 노드만이 이러한 책임을 갖고, 가벼운 노드는 그러하지 않다. 어느 경우이든, n은 매우 클 수 있다).
따라서, n이 크면, 단계의 수(#)가 다소 적더라도 시스템의 총 비용이 매우 커질 수 있다. 이것은, 단계의 수(#)가 전혀 많지 않지만 C의 호출자(i)가 지불해야 하는 요금도 매우 커야 함을 의미한다. 이 상황에서는, 블록체인 시스템에서, 적은 수의 단계가 필요한 스마트 계약만을 실행하는 것이 타당하다. 이것은 유감스러운 일이다. 시스템의 사용자들은, 적지 않은 수의 연산 단계를 필요로 하는 많은 스마트 계약의 실행을 호출함으로써 이익을 얻을 수 있지만, 지불해야 하는 과다한 요금으로 인해 이러한 실행을 호출할 수 없다.
본 발명의 기술을 특정한 부분 선택으로 설명하는 것이 편리하다는 것을 알게 되었다. 그러나, 각 부분은 그 자체가 신규하고 개별적으로 사용될 수 있으며, 부분의 다른 분할도 본 발명의 범위 내에서 가능하다는 것을 이해해야 한다.
1. 호출
스마트 계약(C)의 선언적 호출(I)은, (주어진 입력/입력들 및 초기 상태에 대한) C의 실행(e)의 관련 결과 및 다른 관련 데이터 특정한다.
관련 결과는, e에 의해 도달된 새로운 상태 및 e에 대응하는 플레이어-양 조정을 포함할 수 있다.
관련 데이터는, 계약, 상태, 및 해당 입력의 표시, (참조 기계(M)에 관한) e의 단계의 수 또는 이러한 단계의 수에 대한 상한값, 호출이 시스템에 야기한 비용 또는 비용에 대한 상한을 나타내는 요금을 포함할 수 있다(이 비용은 모든 사용자가 e를 실행할 때 야기된 비용보다 상당히 작다는 것을 알 수 있을 것이다).
관련 데이터는, 또한, 적어도 호출을 담당하는 적절한 사용자(i)의 표시, 및 i가 실제로 시스템에 대한 비용을 비롯하여 호출의 책임을 수락함을 나타내는 i의 디지털 서명(또는, 다른 형태의 인증)을 포함할 수 있다. 이러한 사용자(i)는 실제로 관련 데이터를 연산하기 위해 자신이 실행을 생성했을 수 있다.
관련 데이터는, 또한, 호출이 블록체인에 공식적으로 등록될 것으로 예상되는, 즉, 보일 것으로 예상되는 블록 또는 블록들의 세트의 표시를 포함할 수 있다(실제로, 사용자(i)는, r에서 블록체인에 진입하지 않으면 호출의 책임을 부인할 수 있다).
간단히 하기 위해, 선언적 호출(I)을 간단하게 호출이라고 칭할 수 있다.
설명 및 추가 세부 사항
전술한 바와 같이, 적절한 사용자(i)는 자신의 디지털 서명을 전파함으로써 입력(input)에 대한 시스템의 C 실행을 호출한다. 그러나, 이번에는, C, 입력, 정확한 요금에 더하여, i의 서명도 C 실행의 효과 및 실행에 쓰인 단계의 수를 인증한다(주석 3: 위 정보는 다소 중복성이 있을 수 있다는 점에 주목한다. 이는, 명확성을 위한 것이며, 어떠한 제한을 가하려는 것이 아니다. 예를 들어, 요금은, 총 길이(또는 예컨대, 효과의 길이만) 및/또는 단계들의 수 등의 다른 금액들로부터 시스템의 현재 "가격 리스트"를 통해 결정될 수 있다. 마찬가지로, 단계들의 수는 요금 등에 의해 상한을 가질 수 있다. 전체적으로, 다른 금액으로부터 추론/추정될 수 있는 언급된 금액은 명시적으로 보이지 않을 수 있지만, 추론/추정될 수 있다).
샘플 설정에 있어서, i는 먼저 C(input)의 실행을 연산하고, 또는 다른 누군가가 그를 위해 e를 연산하여 실행(e)이 어떠한 결과를 초래할지를 파악하고, 이어서 이들 결과를 확인하도록 시스템에 요청한다. e 실행시, C는, 보유 상태(
Figure pct00004
)로 시작하고, 즉, 이 상태는, 블록체인에 기록된 C의 실행들의 시퀀스 후에 C에 의해 도달된 최신 유지 상태이다.
예를 들어, 그러나, 일반성을 잃지 않고서, i는 이하의 것들을 연산하고 전파를 시작한다.
Figure pct00005
여기서,
● i는, i의 서명으로부터 추론될 수 있다면, 주로 편의상 포함되는 호출 사용자의 식별자이다.
● C는 해당 계약이다.
● r은, 이 예에서, i가 호출이 등록될 것으로 예상하며 호출이 블록(r)에 등록되어 있지 않으면 i가 호출의 책임을 거부하는 특정 단일 블록이다.
● r'은 (예를 들어, 호출된 실행에 대한 최종 베르딕트가 블록(r')에 의해 블록체인에 나타나면 호출을 폐기해야 함을 전달하도록) 미래 블록의 표시일 수 있다.
● 입력(input)은 C의 실행을 호출하도록 i가 선택하는 입력(들)(i)이다.
● #steps은 (주어진 참조 기계(M)에서의) e의 수이다.
●
Figure pct00006
는, 초기 상태이며,
Figure pct00007
는 e에 의해 생성된 C의 새로운 유지 상태이다.
●
Figure pct00008
는 e에 의해 생성되는 플레이어-양 조정 쌍이다.
● 요금(fee)은 (이 특정 예에서) i가 지불할 수 있는 금액이다.
● n은 호출에 대한 검증자들의 세트의 (예상) 크기이다(후술됨).
● t는, 호출을 정확한 것으로 간주하는 데 필요한 호출에 대한 일관된 응답들(coherent responses)의 수를 나타내도록 포함될 수 있는 정수이다(개념에 대해서는 후술됨).
Figure pct00009
는 C(입력)의 i의 호출이라고 할 수 있고,
Figure pct00010
는 선언된 실행 요약이라고 할 수 있다.
지불가능한 요금은, #steps, 선언된 실행 요약의 크기, 및 결과 상태(
Figure pct00011
)의 크기 등의(이러한 예로 제한하려는 것이 아님))의 일부 선택된 금액에 따라 달라질 수 있다. 따라서, C의 상태들이 간결하도록 C를 설계하고 그 순 효과를 간결하게 설명할 수 있는 계약에 집중하는 것이 중요하다. 호출이 이러한 금액을 포함하는 경우, 요금은 금액(n, t)에도 의존할 수 있다. 요금은 최종 베르딕트의 크기 등의 기타 금액에도 의존할 수 있으며, 이에 대해서는 후술할 것이다. 요금이 실제로 선택된 금액에 해당하는 금액과 동일하거나 그 금액을 초과한다면, 요금이 적절하다고 말한다.
요약하자면,
Figure pct00012
는, 본질적으로 선언된 실행 요약의 정확성을 검증한 다음 (a) C의 새로운 유지 상태를 갱신하고 (b) C의 실행에 의해 영향을 받는 플레이어가 소유하는 금액을 조정하기 위한 시스템에 대한 i의 요청이다.
이제, 이러한 호출(I)이 어떻게 등록되는지를 살펴본다.
2. 등록
호출(I)은 일반적인 지불과 매우 유사하게 블록체인에 진입할 수 있다. 새로운 블록 생성을 담당하는 일부 사용자(u)가 새로운 블록을 자신의 블록에 넣을 때까지 호출(I)이 사용자들 사이에 전파될 수 있다. 바람직하게, u는 I가 구문론적으로 유효한지를 확인해야 한다.
구문 유효성을 확인하려면, 몇 가지 간단한 조건을 확인해야 한다. 예를 들어, 이는, I에 표시된 C의 초기 상태가 블록체인에 등록된 C의 최종 호출에 표시된 최종 상태와 일치함을 확인하는 것을 포함할 수 있다. 또는, 호출하는 사용자가 존재한다면, 호출하는 사용자가 실제로 호출을 행할 자격이 있음을 확인하는 것을 포함할 수 있다. 따라서, 블록체인에 호출을 등록할 때, C를 실행할 필요가 없다.
구문 유효성은, 또한, I를 호출하는 사용자(i)가 실제로 I에 특정된 요금을 지불할만큼 충분한 돈을 소유하고 있음을 확인하는 것도 포함할 수 있다. 실제로, 이러한 요금은 i에 의해 자동으로 지불될 수 있다(또한, 예를 들어, 호출을 요청한 계약이기 때문에, 요금 지불에 책임이 있는 계약인 것으로 고려될 수 있다. 이러한 계약에 의해 소유된 돈으로 요금이 지불된다면, 구문 유효성은 계약이 요금을 지불하기에 충분한 돈을 갖고 있는지를 확인하는 것을 포함할 수 있다. 이 경우, I가 블록체인에 진입할 때, 이러한 요금이 계약에 의해 자동으로 지불될 수 있다).
구문 유효성은, 또한, I의 요금이 I에 의해 표시된 단계들의 수에 적합함을 확인하는 것을 포함할 수 있다.
구문론적으로 유효하지 않은 스마트 계약 호출을 포함하는 블록은 유효하지 않은 것으로 간주된다. 이에 따라, 정직한 u는 새로운 블록에 구문론적으로 유효하지 않은 호출을 포함해서는 안 된다.
I의 전파 중에도 구문 유효성을 확인할 수 있다. 실제로, 구문론적으로 유효하지 않은 I를 수신하는 사용자(x)는 그것을 다른 사용자에게 포워딩하지 않을 수 있다.
설명 및 추가 세부 사항
호출(I)의 구문 검증은 전형적으로 해당하는 의미론적 검증보다 훨씬 가볍다는 점에 주목한다. 후자의 용어는, I에 의해 호출되는 실행(e)을 실시함으로써 실제로 선언된 실행 요약이 생성됨을 검증하는 것을 의미한다. 스마트 계약의 실행에는 많은 단계가 필요할 수 있기 때문에, 이러한 의미론적 검증은 매우 길 수 있다.
이에 따라, 바람직한 실시예에서, 블록 구성자(u)는 I의 구문론적 유효성만을 검증하고 그것의 의미론적 유효성은 검증하지 않는다는 점이 주요 이점이다. 전형적인 블록은 수천 개의 트랜잭션을 포함하며, 예를 들어 이들 중 1,000개가 스마트 계약 호출이고, 이들의 각 트랜잭션을 실행하는 데 평균 1초의 연산이 걸린다고 가정한다. 이어서, 다른 모든 연산을 무시하더라도, 새로운 블록(u)을 구성하기 위해서는, 자신이 생성하는 새로운 블록의 호출의 의미론적 유효성을 검증해야 한다면 적어도 1,000초(즉, 약 16분)가 필요하다. 이는, 실제로 기존의 스마트 계약 모델에서 블록 계약자가 해야 하는 것이다. 그러나, 16분마다 블록을 생성하는 것은 너무 느릴 수 있다. 당연히 몇 초 안에 새로운 블록을 만드는 것이 바람직하다!).
이러한 느림은, 메시지 전파 중에 사용자들이 다른 사용자들에게 포워딩하는 호출의 의미론적 유효성을 확인해야 한다면, 더 안 좋을 수 있다.
바람직한 실시예에서, 호출은, 블록체인에 진입할 때 공식적인 것으로 간주되며, 그 시점에서만, 시스템이 의미론적 유효성을 확인하기 위해 필요한 노력을 기울일 것이다. 그러나, 전체 시스템 노력은 상당히 포함되고 실용적임을 알 수 있을 것이이다.
3. 지정
하나 이상의 블록에 등록된 하나 이상의 스마트 계약 호출들의 세트(S)는 스마트 계약 검증자들의 세트에 지정된다.
예를 들어, S는 주어진 블록에 포함된 모든 스마트 계약 호출들로 이루어질 수 있다. 대안으로, S는 단일 호출로 이루어질 수 있다. 다른 대안으로, 주어진 블록의 호출이 여러 세트로 분할될 수 있다. 예를 들어, 제1 세트는 소정의 주어진 정수 k에 대한 처음 k개의 스마트 호출로 이루어질 수 있고, 제2 세트는 다음 k개의 스마트 호출로 이루어질 수 있으며, 이러한 식으로 계속된다(그러나, 최종 세트는 k개 미만의 호출을 포함할 수 있다). 다른 일례로, 블록의 스마트 계약 호출들은, 각 세트의 실행 요약들에 선언된 단계들의 총 수를 제어하도록 (예를 들어, 정준(canonical) 방식으로) 다수의 세트로 분할될 수 있다. 예를 들어, 선언된 실행 요약에서의 단계들의 수의 합(X)이 주어진 수(N)를 초과하지 않으면서 다음 호출의 선언된 실행 요약에서의 단계들의 수와 X의 합이 주어진 수(N)를 초과하면, 제1 세트는 블록에서 처음 k개의 호출로 이루어질 수 있다. 세트(S)는 검증자 세트들의 (예상된) 크기에 의존할 수 있다. 예를 들어, S는 비슷한 (예상된) 크기의 검증자 세트들을 특정하는 호출들을 그룹화할 수 있다.
S에 지정된 일련의 스마트 계약 검증자들의 세트(VS)는, 주어진 사용자들의 대다수가 정직하다고 가정할 때 선택된 검증자들의 대다수가 정직하다는 점을 높은 확률로 보장하도록, 충분히 랜덤하면서 충분히 많다. 또한, VS의 검증자는, 블록체인에 따라 사용자가 시스템에서 현재 보유하고 있거나 주어진 시점에서 보유하고 있는 금액량에 비례하여 선택될 수 있다. 이 경우, 검증자는 더 큰 가중치를 갖는 VS에 속하도록 선택될 수 있으며, 이는, 자신이 두 개 이상의 투표를 갖고 있으며, 대부분의 투표가 정직하게 진행되는 것을 보장하길 원할 수 있음을 의미한다.
또한, 세트(VS)를 확인할 수 있는 것이 바람직하다. 즉, (a) S로부터 VS를 연산할 수 있고, 또는 (b) VS의 검증자가, 그가 실제로 VS의 구성원임을 결정할 수 있으며, 그러하다면, 이것이 사실임을 다른 이들에게 증명할 수 있다.
설명 및 추가 세부 사항
본 발명은 검증자들의 비교적 작은 세트(VS)를 스마트 계약들의 각 세트(S)에 지정하는데, 이들은 S의 호출의 선언된 실행 요약의 의미론적 정확성을 검증하는 데 필요한 시간을 투자하고, 시스템 내의 다른 사용자들이 동일한 작업을 행하지 않게 한다. VS가 작고 고정되어 있으면, 적대자가 시간이 지남에 따라 모든 검증자 또는 대다수의 검증자를 손상시킬 수 있기 때문에, 시스템이 매우 안전하지 않게 된다.
이러한 결과를 방지하기 위해, S와 일부 추가 정보(P)에 기초하여, 각 VS를 랜덤하게 또는 의사 랜덤 방식으로 선택한다. 예를 들어, 해시 함수 또는 다른 적절한 암호화 함수(H), 예컨대, VS = H(S, P)를 사용할 수 있다. P의 가능한 선택은, 시간 정보, S가 나타나는 블록 또는 블록들에 관한 정보, 이들 블록에 포함되거나 이들 블록으로부터 또는 더욱 일반적으로는 어떠한 정보 없이 블록체인 등으로부터 추론될 수 있는 데이터를 포함할 수 있다(VS는, S가 나타나는 블록 또는 블록들에 기초하여 선택됨으로써, S에 기초하여 선택될 수 있다는 점에 주목한다. 예를 들어, S가 블록(B) 또는 블록번호(n)의 모든 호출의 세트이면, B 또는 n에 기초하여 VS를 선택할 수 있다. 다른 일례로, S가 주어진 소정의 순서로 블록번호(n)의 제2 호출 세트이면, 쌍(n, 2)을 포함하는 정보에 기초하여 VS를 선택할 수 있다. S에 기초하여 선택하는 단계는, S 및 기타 정보에 기초하여 선택하는 단계를 포함한다).
이러한 VS의 랜덤한 선택에 의해, 적대자가 VS의 검증자들 중 일부를 손상시키는 것이 훨씬 어렵다, 실제로, 검증자들의 세트는 매번 극적으로 변경될 수 있다.
이상적으로, VS의 검증자들은 비밀 추첨 방법을 통해 선택된다. 이러한 방법에서, 사용자(v)는, 자신이 VS의 검증자인지를 비밀리에 배우지만, 이것이 실제로 사실이라면 이를 다른 이들에게 증명할 수 있다. 예를 들어, v는 자신의 비밀 키를 사용하여 자신이 VS에 속하는지를 연산할 수 있다. 예를 들어, v는,
Figure pct00013
를 연산할 수 있고, 이렇게 연산된 데이터스트링이 주어진 속성을 충족하는지를 확인할 수 있다. 어떠한 제한도 의도되지 않은 이러한 한 특성에서는, 값(
Figure pct00014
) 또는 그 값의 해시가 주어진 수(t)보다 작을 수 있다. 실제로, 다른 임의의 데이터스트링과 마찬가지로
Figure pct00015
는 수로서 고유하게 해석될 수 있으며, 이 수는 "대상" 수(t)와 쉽게 비교된다. 예를 들어, t=0.001인 경우, 암호화 함수(H)가 랜덤 함수로서 취급되면,
Figure pct00016
일 확률은 천분의 1이다. 이에 따라, 이 예에서, 천 명의 가능한 사용자들 중 한 명이 Vs의 검증자이다. 이 예에서 검증자 세트(VS)는 확인가능하다는 점에 주목한다. 실제로, V가 VS에 속하는 경우, v는 자신의 서명(
Figure pct00017
)을 해제함으로써 이것이 사실임을 증명할 수 있다. 실제로, 이 데이터스트링을 고려하면, 누구라도 이 데이터스트링이 VS에 속하는 것으로 결정되는 원하는 속성을 소유하고 있는지를 알 수 있다. 그러나 v가
Figure pct00018
를 드러낼 때까지 적대자는 v가 누구인지를 알지 못한다는 단순한 사실 때문에, 적대자가 v를 손상시키는 것은 매우 어려울 것이다. 실제로, v가 VS에 속하는지를 결정하는 비밀 키(위의 예에서는 비밀 서명 키)를 자신만이 알고 있기 때문에, v는 비밀리에 선택된다. 실제로, 비밀 추첨을 통해 VS를 선택하는 것은 매우 안전하다.
4. 검증
스마트 계약들의 세트(S)가 블록체인에 등록되면(나타나면), VS의 각 검증자(v)는 S의 각 호출(I)의 의미론적 정확성을 검증한 다음 자신의 응답을 인증 및 전파한다.
세트(VS)가 비밀 추첨을 통해 선택된 경우, v는 자신이 실제로 VS에 속하는 증거도 전파한다.
검증자(v)는 S의 각 I에 대한 자신의 응답을 개별적으로 인증할 수 있다. 예를 들어,
Figure pct00019
를 연산하고 전파함으로써 그렇게 할 수 있다.
검증자(v)는, 또한, 자신의 모든 응답을 함께 인증하여, 어떤 호출이 유효하고 어떤 호출이 유효하지 않은지를 나타낼 수 있다. 예를 들어, S의 호출이 I1, I2, I3, I4,...이고 호출(I1, I3,...)이 유효하고 호출(I2, I4,...)이 유효하지 않은 경우, v는 다음과 같이 연산하고 전파할 수 있다.
Figure pct00020
보다 간결하게, v는 1을 사용하여 유효성을 나타내고 0을 사용하여 비유효성을 나타낼 수 있다. 따라서 위의 예에서는,
Figure pct00021
를 전파함으로써 자신의 모든 응답을 함께 인증할 수 있다. 보다 간결하게, S의 호출(I1, I2, I3, I4,...)이 실제로 미리 결정되고 모호하지 않은 방식으로 순서화된다면, 위의 경우에, v는
Figure pct00022
를 전파할 수 있다. 즉, 첫 번째 위치에 있는 첫 번째 1은, 제1 트랜잭션, 즉, I1이 유효함을 나타내고, 위치 2에 있는 첫 번째 0은 제2 트랜잭션인 I2가 유효하지 않음을 나타내며, 나머지도 마찬가지이다.
검증자(v)는, 또한, 자신의 응답들을 함께 인증할 수 있지만, S의 개별 호출에 대한 v의 인증된 응답을 추출할 수 있게 한다. 예를 들어, v는 머클 트리를 구성할 수 있으며, 이 트리의 각 리프는, S에 개별 호출에 대한 v의 응답을 저장한 후, 머클 트리의 루트에 저장된 값을 인증한다.
VS의 정직한 검증자는, S의 각 호출(I)에 대한 정확한 응답(및 이에 따라 단일 응답)만을 제공한다.
VS의 검증자가 유효하다고 간주하는 S 호출과 유효하지 않다고 간주하는 호출을 인증하는 데 사용할 수 있는 방법에 관계없이, 적어도 VS의 검증자들 중 주어진 수(X)가 I가 의미론적으로 유효함을 인증하면, S의 호출(I)은 정확한 것으로 간주될 수 있고, 그렇지 않으면 정확하지 않은 것으로 간주될 수 있다. 대안으로, 적어도 VS의 검증자들 중 주어진 수(Y)가 I가 의미론적으로 정확한 것임을 인증하면, I가 잘못된 것으로 간주될 수 있다. 의미를 극대화하기 위해, X와 Y는 충분히 크게 선택되며, 이에 따라, VS의 대부분의 검증자가 정직할 때, (a) 의미론적으로 유효한 S의 각 호출(I)은 정확한 것으로 간주되고 부정확한 것으로 간주되지 않으며, 유사하게, (b) 의미론적으로 무효한 S의 각 호출(I)은 부정확한 것으로 간주되고 정확한 것으로 간주되지 않는다.
설명 및 추가 세부 사항
VS의 검증자들이 S의 호출의 의미론적 유효성에 대한 인증된 응답을 전파하는 것으로는 충분하지 않다. 예를 들어, 시스템에 최근 가입하고 지금까지 전체 블록체인을 배우는 사용자는, 자신이 가입하기 전에 무엇이 전파되었는지를 전혀 모를 수 있다. 이에 따라, 사용자는, 호출(I)이 블록체인에 등록되었음을 알지만, I가 정확한지 여부를 모른다. 따라서, 블록체인 자체에 I에 대한 최종 "베르딕트"을 등록하는 것이 중요하다.
머클 트리가 문헌에서 널리 공지되어 있다는 점을 상기한다. 머클 트리를 사용함으로써, 트리의 루트에 저장된 값(r)과 관련하여 머클 트리의 노드들에 저장된 많은 정보를 인증할 수 있다. 트리의 노드에 저장된 값(v)을 인증하려면, 루트에서 v를 저장하는 노드까지의 인증 경로를 제공해야 한다. 이러한 경로는 트리 내에서 인증된 값들의 시퀀스보다 훨씬 짧을 수 있다(예를 들어, 대수적으로 짧을 수 있다). 값(r)이 알려지지 않은 경우, 트리의 노드에 저장된 값(v)을 인증하기 위해, r을 (예를 들어, 디지털 서명을 통해) 개별적으로 인증한 후에 r에 관한 v에 대하여 인증 경로를 제공할 수 있다.
5. 베르딕트
새로운 블록을 구성하는 사용자(u)는, 이러한 블록에, 블록체인에 아직 나타나지 않은 유효한 일반 트랜잭션(예를 들어, 유효한 지불)뿐만 아니라 최종 베르딕트, 즉, 어느 쪽이든 블록체인에 미리 등록된 호출에 관한 정확성 또는 부정확성에 관한 정보도 포함할 수 있다. 바람직하게, 이러한 정보는 아직 최종 베르딕트가 체인에 나타나지 않은 트랜잭션을 위해 제공된다.
S를 블록체인에 이전에 등록된 호출들의 세트라고 하고 u를 새로운 블록(B)을 구성하는 사용자라고 하자. 이어서, u는, 예를 들어 S의 각 I에 대해 I가 정확한지 여부를 알기 위해 VS의 충분히 많은 검증자의 응답을 수신한 후, S의 호출에 대한 최종 베르딕트(예를 들어, S의 모든 호출)을 B에 포함할 수 있다. 이러한 최종 베르딕트는, 또한, 세트(S) 자체를 식별하는 정보를 포함할 수 있으며, 바람직하게 인증된다. u가 B를 인증하면, u에 의해 이러한 베르딕트가 자동으로 인증된다. 대안으로, u는 S의 호출에 대한 최종 베르딕트를 별도로 인증할 수 있다. 예를 들어, S의 호출에 대한 최종 베르딕트를 특정하기 위해, u는 VS의 검증자들이 사용하는 방법들 중 하나를 사용하여 S의 호출의 의미론적 유효성에 대한 자신의 응답을 전달할 수 있다.
대안으로, u는, VS의 충분히 많은 검증자들의 인증된 응답들을 블록에 포함할 수 있어서, 이렇게 포함된 응답들로부터 S의 유효한 호출 및 S의 유효하지 않은 호출을 결정할 수 있다. 아마도, 이러한 응답과 함께, u는, 또한, 해당 검증자들이 실제로 VS에 속한다는 것을 증명하는 하나 이상의 데이터스트링을 포함할 수 있다.
대안으로, u는, SV의 일부 검증자들, 바람직하게는, 블록체인에 응답이 아직 기록되지 않은 검증자들의 S에 관한 응답을 자신의 블록에 포함할 수 있지만, 이렇게 포함된 정보로부터만 S의 호출의 정확성을 추론할 수는 없다. 그러나, 사용자는 다수의 블록에 대한 S의 호출의 정확성을 추론할 수 있다. 체인에 기록된 충분히 많은 응답이 I의 정확성 또는 부정확성(어느 것이든 상관없음)을 입증할 때 실제로 S의 호출(I)에 대한 최종 베르딕트에 도달할 수 있다.
사용자(u)는, S에 있는 모든 호출 또는 이들 중 단지 하나 이상의 정확성에 관한 정보를 B에 포함할 수 있다. 예를 들어, 사용자는, S의 하나 이상의 호출(I)에 대한 VS의 검증자들의 하나 이상의 응답을 B에 포함할 수 있다. 또는, 사용자는 S의 적어도 일부 트랜잭션(들)의 정확성을 추론할 수 있는 정보를 포함할 수 있다. VS의 검증자들이 S의 단지 일부 트랜잭션(I)에 대한 인증된 해당 응답을 추출할 수 있는 방식으로 S의 호출의 유효성에 대한 자신의 응답을 인증하면, u는 I에 대한 이러한 추출된 인증을 포함할 수 있다. 예를 들어, VS의 검증자(v)가 머클 트리의 루트(r)를 인증함으로써 S의 호출에 대한 자신의 응답을 인증하면, S의 호출(I)에 대한 v의 인증을 B에 포함하기 위해, u는, r에 대한 v의 인증 및 r로부터 i의 유효성에 대한 i의 응답을 포함한 값까지의 인증 경로를 포함할 수 있다.
토론 및 추가 상세
블록(B)은, 일반 트랜잭션이 유효한 경우뿐만 아니라 이전에 등록된 호출에 대한 최종 베르딕트가 유효한 경우에도 유효한 것으로 간주될 수 있다.
새 블록을 생성하기 위해 작업 증명에 의존하는 블록체인에서, 정직한 광부는 새로운 블록을 유효하지 않은 블록에 연결하지 않는다.
새로운 블록(B)이 제안된 후 체인에 추가되도록 사용자들의 적절한 세트(예를 들어, 검증자들의 적절한 세트)에 의해 투표되거나 동의되는 알고랜드와 같은 블록체인에서, 무효한 블록은 투표되지 않거나 동의되지 않을 수 있다.
프로토콜은, 주어진 계약의 동시 실행을 허용할 수 있고, 또는 이러한 실행 중 일부를 무시하는 단계를 포함하여 C의 실행 중의 실행들의 특정한 순서를 부여할 수 있다. 예를 들어, 주어진 계약(C)의 호출(I)이 블록체인에 등록되면, 프로토콜은, I에 대한 최종 베르딕트가 블록체인에 나타날 때까지 C의 다른 호출이 블록체인에 등록되지 못하게 할 수 있다. 특히, 새로운 블록(B)을 구축하는 사용자(u)는 C의 2개 이상의 실행을 B에 포함하지 않을 수 있다. 대안으로, C의 2개 이상의 호출이 나타날 수 있지만, 이들 중 하나는 (예를 들어, 미리 결정된 소정의 방식으로) 먼저 실행되도록 선택된다. 다른 것(들)은 결코 실행되지 않을 수 있거나 첫 번째 호출에 대한 최종 베르딕트에 도달한 후에만 실행될 수 있다. 대안으로, 계약 유형 및 계약이 특정하는 것에 따라, 하나의 호출을 먼저 실행한 다음 두 번째 호출을 실행하도록 선택을 행하며, 이러한 식으로 계속 적용된다.
계약(C)의 호출(I)은, 또한, 블록 번호(r)를 포함할 수 있어서, I에 대한 최종 베르딕트가 블록(r) 이후에 블록체인에 진입할 수 있다는 최종 베르딕트가 없다. 대안으로, 이러한 r은, I가 등록된 블록 및 I에 선언된 단계들의 수에 기초하여 자동으로 결정될 수 있다. 이렇게 함으로써, 원래 베르딕트가 최종 베르딕트 없이 남아있는 경우 C의 새로운 호출을 가능하게 한다. 이러한 경우, I가 블록체인에 등록되었을 때 자신의 지불한 요금에 대해 호출(I)을 담당하는 사용자에게 자동으로 상환하는 것을 고려할 수 있다.
일단 계약(C)의 호출(I)의 최종 베르딕트(의 표시)이 블록체인에 진입하면, 베르딕트가 긍정적인 경우, 이를 이해하는 사용자(x)는 C의 현재 상태를 적절하게 갱신하고 발생하는 모든 관련된 순 효과를 고려한다(예를 들어, 호출(I)이 사용자로부터 주어진 지불을 다른 사용자에게 선언하면, 이러한 사용자가 소유하는 돈이 자동으로 갱신된다). 최종 베르딕트가 부정적이면, C의 상태가 갱신되지 않으며 순 효과가 발생하지 않는다. 그러나, 호출(I)을 담당하는 사용자에게는 추가 요금이 자동으로 부과될 수 있다.
1 일반 분석
보안, 효율성, 및 비용
주어진 세트(S)의 호출에 대한 단일 검증자(v)의 응답은, v가 정직하다고 확신된다면, 충분할 것이다. 그러나, 물론, 블록 구성자/제안자 또는 다른 사람은 어떤 검증자가 정직한지를 모를 수 있다. 그러나, 대다수 검증자의 정직성을 확신하는 것은 쉽다. 따라서, 충분히 많은, 바람직하게는 랜덤하게 선택된 검증자들이 S의 어떤 호출이 유효하고 어떤 호출이 유효하지 않은지를 다른 모든 사용자에게 알리면, 그 유효성을 스스로 검증할 필요없이 S의 호출의 정확성을 배울 수 있다. 이것이 본 발명의 체계가 안전하면서 동시에 효율적인 이유이다.
예를 들어, 사용자의 80%가 정직하고 S 내의 I의 검증자들의 수가 약 500이면, 300명의 검증자의 응답은 실제로 매우 높은 보안을 보장할 수 있다. 동시에, S에 예를 들어 100개의 호출이 포함된 경우, 평균적으로 5명의 사용자만이 각 호출의 유효성을 검증하여, 시스템을 매우 안전하게 하는 것에 더하여 효율적으로 만들 수 있다.
비교적 적은 검증자들이 (특히 평균적으로) 선언된 실행의 유효성을 직접 확인하므로, 주어진 실행을 등록하는 데 필요한 요금이 매우 낮을 수 있다. 실제로, 예를 들어 시스템의 모든 사용자가 아니라 평균적으로 5명만 있는 위의 예에서, 매우 적은 사용자의 연산 비용을 상환해야 한다. 스마트 계약을 호출하는 데 필요한 요금을 종종 "가스"(gas)라고 한다. 이에 따라, 본 발명의 시스템에서,
가스는 매우 많은 바람직한 유형의 계약에 대하여 훨씬 저렴하다!
높은 보안성은, 높은 효율성 및 저렴한 비용과 함께, 본 발명의 시스템을 많은 종류의 스마트 계약에 대하여 매우 매력적으로 만들 수 있으며, 실제로 이러한 계약의 대규모 사용을 허용할 수 있다.
실제로, 본 발명의 시스템에서, 스마트 계약은 다른 시스템보다 훨씬 더 긴 실행 시간을 가질 수 있지만, 총 연산량은 훨씬 적다.
돈에 대한 가중치
본 명세서 전체에 걸쳐, 호출들의 주어진 세트(S)의 검증자들(VS)의 세트는, 주어진 순간에(예를 들어, S가 블록체인에 등록될 때) 시스템에서 소유하는 금액량에 기초하여, 지분 증명의 소정의 형태에 적어도 부분적으로 기초하는 알고랜드 또는 기타 블록체인에서처럼, 선택될 수 있다는 점에 주목한다. 실제로, 주어진 사용자는 1보다 큰 다중성을 갖는 VS를 입력할 수 있다. 사실, SV는 검증자들의 세트의 다수의 투표로 이루어질 수 있으며, 각 검증자는 자신이 소유하는 금액에 따라 더 많은 투표를 가질 수 있다. 즉, 본 발명의 시스템은 돈의 대부분이 정직한 손에 있다고 가정할 때에도 적용된다.
연산 효율
시스템의 사용자들의 수인 n이 엄청 클 수 있지만(예를 들어, n=100M), T(예를 들어, T=500)명의 검증자만이 C(입력)를 실행하면 된다는 점에 주목한다. 따라서, 본 발명의 기술로 C의 실행에 대한 총 연산 비용은 100M #steps이 아니라 ≤500 #steps이다. 이에 따라, 알고랜드의 스마트 계약은 다른 시스템보다 훨씬 긴 실행 시간을 가질 수 있지만, 총 연산량은 훨씬 적을 수 있다. 다시 말하면, 이러한 새로운 기술은 훨씬 더 큰 유연성을 제공하며 훨씬 더 많은 종류의 스마트 계약을 사용할 수 있게 한다.
비용 효율
새로운 스마트 계약 기술의 연산 효율은 자동으로 비용 효율을 의미한다. 100M명의 사용자가 있는 시스템에서 1시간의 연산이 필요한 스마트 계약(C)의 실행을 호출하는 것을 고려해 본다. 이러한 시스템에서, C의 통상적인 호출 요금은, 본질적으로 100M 시간의 연산에 대한 총 비용을 포함해야 하기 때문에, 반드시 매우 높아야 한다. 대조적으로, 새로운 기술의 경우, C의 동일한 호출에 대한 해당 요금은 단지 500시간의 연산만 커버하면 된다. 실제로, 이러한 후자의 비용은, 적당할 뿐만 아니라 시스템의 총 사용자 수가 1B 이상인 경우에도 동일하게 유지된다. 다시 말하면, 새로운 본 발명의 시스템에서, '가스'는 매우 많은 바람직한 유형의 계약에 대하여 훨씬 저렴하다!
처리량 효율
본 발명의 기술로, 블록(B)에 등록된 계약(C)의 호출(I)은 검증자들의 적절한 세트인 '오프 체인'에 의해 C의 실행을 트리거한다. 따라서, 이러한 실행에 오랜 시간이 걸리더라도, 블록(B)의 유효성을 확인하는 데 오랜 시간이 필요하지는 않다. 따라서, 다음 블록의 생성이 바로 시작될 수 있다. 다시 말하면, 본 발명의 시스템은 매우 높은 처리량을 가질 수 있다. 일단 I의 적절한 검증자들이 실행을 완료하면, 심지어 이러한 실행에 오랜 시간이 걸렸더라도, 체인을 늦추지 않고 I에 대한 최종 베르딕트가 블록체인에 진입한다. 대조적으로, 통상적인 방법에서는, I가 블록(B)에 게시되면, 다음 블록을 생성하기 전에 e 호출을 완료해야 한다. 따라서, 새로운 기술은, 개별적으로 또는 전체적으로 실행하는 데 1시간의 연산을 필요로 한 스마트 계약을 블록이 포함하더라도, 몇 초 내에 새로운 블록을 생성할 수 있게 한다.
2 변형 및 추가
위에서는 바람직한 실시예들을 제시하였다. 당업자는, 몇몇 다른 변형 및 대안이 가능하며, 이들 모두가 본 발명의 범주 내에 있다는 점을 인식한다. 이중 일부만을 이하에서 고려한다.
호출 등록이 없는 최종 베르딕트. 바람직한 실시예에서, 호출(I)은 '시스템 실행'을 트리거하기 위해 블록체인에 등록되어야 한다. 그러나, 대안으로, I는 블록체인에 올려지지 않고, 그 최종 베르딕트(의 표시)가 올려질 수도 있다. 예를 들어, I는 단지 충분히 많은 검증자에 의해 발견되고 처리될 때까지 전파될 수 있으며, 그러면 검증자들은 I에 대한 자신의 개별 응답을 전파하고, 일단 자신만이 충분히 많은 일관된 응답을 보게 되면, 새로운 블록(B)의 구성자가 I의 최종 베르딕트에 대한 정보(예를 들어, I의 검증자들 중 일부 또는 상당수의 개별적으로 서명된 응답)를 B에 포함한다.
추가 척도 및 결과
스마트 계약의 호출에 있어서, 이용된 단계의 수는 호출의 복잡성에 대한 중요한 척도이며, 궁극적인 지불/효과는 중요한 결과들 중 일부이다. 그러나, 추가의 척도 및 결과가 있으며, 이들 모두는 본 발명 내에서 처리될 수 있다. 아래에서는, 몇 가지 예만 자세히 설명한다.
스마트 계약은 임의의 프로그램일 수 있으며, 계약(C)을 실행하면 C 자체의 다른 실행 또는 다른 스마트 계약을 자동으로 트리거할 수 있다(실제로, 스마트 계약은 Turing-complete 언어로 종종 작성된다.) 이 사실은 이점이 될 수 있지만 단점이 될 수 있으며, 계약(C)의 호출(I)로 인해 발생할 수 있는 콜(call)의 수를 포함하길 원할 수 있다.
예를 들어, 콜의 수(#calls)는, invokei 내에 (별도의 구성요소 및/또는 다른 구성요소의 일부로서) 특정될 수 있고, #calls에 따라 I의 요금(fee)이 조정될 수 있다. 이러한 의존성은, 단순히 비례적일 수 있으며, 또는 #calls과 함께 극적으로 증가할 수 있다. 따라서, I의 검증자는, #calls이 정확하다는 것 및 이에 따라 #calls을 포함하여 모든 복잡성 척도에 비해 요금도 정확하다는 것을 검증하도록 요청받을 수 있다.
대안으로 또는 추가로, 콜의 수를 제한할 수 있다. 예를 들어, 선언된 #calls가 주어진 범위보다 크거나 C가 실제로 행하는 콜의 수가 #calls보다 큰 경우, #steps 및 fee의 값들에 관계없이, 호출은 유효하지 않은 것으로 간주된다. 개별 베르딕트 및 최종 베르딕트에 대해 전술한 모든 메커니즘은 이러한 새로운 복잡성 척도에 쉽게 적용된다.
또한, 일반 콜과 '중첩된 콜'(nested call)을 구분할 수 있다. 예를 들어, C의 실행(e)이 계약(C')의 실행(e')을 야기하고, 이러한 후자가 계약(C")의 실행(e")을 야기하면, e"은 '수준' 2의 중첩된 콜로 간주될 수 있다. 마찬가지로, 수준 3, 4 등의 중첩된 콜이 있을 수 있다. 또한, 중첩된 콜 및/또는 이들의 해당 수준은 호출(I)에서 선언될 수 있으며, 이렇게 추가로 선언된 정보를 포함하도록 I의 요금, 유효성, 및 처리를 간단하게 확장할 수 있다는 점에 주목한다.
호출(I)의 직접적인 순 효과에 더하여, 콜의 효과도 고려할 수 있다. 예를 들어, 직접적으로 또는 해당 콜을 통해 이체되는 총 금액을 I에 명시적으로 나타낼 수 있다. 다시 말하지만, 주어진 수준의 콜을 금지할 수 있거나 일반 콜보다 비싸게 할 수 있다.
인센티브
호출 또는 호출들의 세트의 검증자들은 적절한 보상을 통해 인센티브를 받을 수 있다. 특히, 호출(I)에 대한 그 검증자의 응답이 I에 대한 최종 베르딕트에 동의하는 경우, 그러한 검증자는 보상받을 자격이 있을 수 있다.
이러한 검증자들의 전부 또는 일부(예를 들어, 샘플)는 보상받을 수 있다. 보상받을 검증자들은, (예를 들어, 암호화 추첨 및/또는 랜덤 비콘의 도움으로) 암호화 방식으로 선택될 수 있다(주석 4: 이러한 샘플은, 또한, 자체적으로 매우 자주 새롭게 선택될 수 있는 전문 당사자에 의해 선택될 수 있다. 특히, 이러한 당사자는, 암호화 추첨에 의해 스스로 선택될 수 있고, 하나 이상의 검증자를 디지털 서명하여 보상을 받을 수 있고, 그 서명은 블록에 나타날 수 있다). 대안으로, 이러한 검증자들은 블록 구성자에 의해 선택될 수 있다. 호출(I)(또는 호출들(S)의 세트)의 보상된 검증자들 및 I(또는 S)의 최종 베르딕트는 동일한 블록에 표시될 수 있다.
예를 들어, 블록 구성자(u)는, 보상받을 하나 이상의 검증자(v)를 식별하는 정보뿐만 아니라 I에 대한 최종 베르딕트(V)(또는 S)을 자신의 블록에 삽입할 수 있다(대안으로, 보상받은 검증자들을 식별하는 정보는, 후속 블록에 삽입될 수 있으며, 다른 블록 구성자/제안자에 의해 선택될 수도 있다). 예를 들어, u는, v의 응답이 V와 일치하는지를 확인할 수 있도록, 최종 베르딕트(V) 외에도, 검증자(v)가 실제로 I(또는 S)를 검증하도록 지정되었다는 증거도 블록체인에 포함할 수 있다. 대안으로, 구성자는 V를 자신의 블록에 포함하지 않아도 된다. 예를 들어, I의 단일 검증자(v) 또는 응답들이 일관된 이러한 다수의 검증자에 대해, 단지 v와 v의 디지털 서명된 개별 베르딕트를 포함하는 것으로 충분하다. 실제로, 이러한 개별적인 응답들로부터, 최종 베르딕트(V) 무엇인지를 추론할 수 있다. 예를 들어, 블록이 단일 검증자(v)의 I에 대한 개별 응답만을 포함하면, 이 정보는, I에 대한 최종 베르딕트가 I의 개별 베르딕트와 일치함을 나타내도록(또한, v가 보상 대상이 되었음을 나타낼 수 있도록) 사용될 수 있다. 모든 보상받은 검증자(들)는 일단 블록에서 식별되면 자동으로 지불받을 수 있다.
정직한 블록 구성자는 랜덤하게 또는 다른 소정의 방식으로 보상받을 I의 검증자(들)를 선택할 수 있다. 악의적 구성자가 다른 방식으로(예를 들어, 악의적 검증자들을 선호함으로써) 검증자들을 선택할 수도 있더라도, I의 검증자들은 여전히 실제 해당 응답을 보고하도록 인센티브를 받는다. 실제로, 대부분의 검증자는 정직할 것으로 예상되며, 블록 구성자도 그러할 것으로 예상된다.
또한, 하나 이상의 호출(I)의 검증자들에게 보상하기 위해 또는 이들의 개별 베르딕트를 고려하기 위해, 검증자들이 실제로 C를 정확하게 실행했다는 증거가 필요할 수 있다. 이러한 증거는, 일부 유형의 CS 증거, 스나크(snark), 또는 스타크(stark)를 포함할 수 있다. 이러한 검증자-제공 증거는, 또한, I에 대한 최종 베르딕트의 일부(또는 전체 증거)로서 블록에서 사용 및 게시될 수 있다.
긍정적인 보상 외에도, 블록체인은 처벌도 사용할 수 있다. 예를 들어, 정확성에 대한 최종 베르딕트와는 다른 호출(또는 호출들의 세트)에 대한 응답을 보고하는 검증자(v)에게 벌금이 부과될 수 있다. 이러한 벌금은 v가 소유한 돈에서 자동으로 공제될 수 있다.
블록체인은, 또한, 의도적으로 의미론적으로 유효하지 않은 적어도 하나의 호출(I)을 블록체인에 의도적으로 등록하는 것을 예상할 수 있다. 이것은 의미론적 유효성(I)을 검증하기 위해 지정된 검증자를 발견하는 데(그리고 처벌할 수 있는 데) 도움이 될 수 있으며, 이러한 검증자는, I가 의미론적으로 유효하다는 것을 (직접적으로 또는 I를 포함한 호출들의 세트의 유효성에 대해 보고할 때) 악의적으로 보고한다.
예를 들어, 의미론적으로 유효하지 않은 호출의 등록을 야기하는 사용자들은, 이들이 악의적이기 때문이 아니라 악의적인 검증자들의 발견을 돕도록 선택되었기 때문에, 그렇게 하지 못할 수 있다. 따라서, 바람직하게, 이렇게 도움을 주는 사용자들의 선택은, (의도적으로 의미론적으로 유효하지 않은 호출의 검증자들이 그 호출이 그렇게 유효하지 않다는 점을 알지 못하도록) 비밀스럽고 (도움을 주는 적어도 일부 정직한 사용자들이 선택되었음을 보장하도록) 랜덤이다. 예를 들어, 이러한 도움을 주는 사용자들을 선택하는 데 사용되는 프로세스는, 호출(I) 또는 호출들의 세트(S)에 대한 검증자(v)를 선택하는 것과 유사할 수 있다. 즉, 도움을 주는 사용자는, 다른 데이터(예를 들어, 스트링 "HELPING USER")와 함께, 블록체인으로부터 추론될 수 있는 주어진 금액(Q)을 디지털 서명함으로써 선택될 수 있고, 그 서명을 해시 처리할 수 있고, 이것이 주어진 대상 수보다 작은지를 확인할 수 있다. 이 프로세스는, 소정의 사용자(u)가 자신의 선택(위 예에서 자신의 디지털 서명)이라면 증거를 밝힐 때까지 사용자(u)가 도움을 주는 사용자로 선택되었음을 다른 사용자들이 인식하지 못하는 것을 보장한다. 이 증명은, u가 등록한 의도적으로 의미론적으로 유효하지 않은 호출(I)에 대한 최종 베르딕트가 블록체인에 진입한 후에 밝혀질 수 있다. 이러한 증명은 상당히 유효한 트랜잭션으로서 블록체인에 삽입될 수 있다. 이러한 방식으로, u에게 부과된 요금 또는 임의의 벌금은, 블록체인 내의 스마트 계약의 정직한 기능을 보장하는 데 도움을 주기 위한 프로토콜에 따라 u가 행동했음을 누구나 인식하기 때문에, (보상 이외에도) u에게 자동으로 상환될 수 있다.
3. 커밋된 (committed) 선언적 스마트 계약
이제, 특별한 유형의 선언적 스마트 계약인 커밋된 선언적 스마트 계약(Committed Declarative Smart Contract: CDSC)을 설명한다. 이러한 계약의 호출은 해당 실행의 적어도 일부 순 효과를 일시적으로 숨긴다. 이들 호출은 이전과 같이 등록될 수 있다. 이러한 호출의 구문론적 유효성은 이전과 같이 확인될 수 있다. 검증자는 이전과 같이 이러한 호출들의 세트에 지정될 수 있다. 그리고, 최종 베르딕트는 이전과 같이 블록체인에 게시될 수 있다.
그러나, 이러한 새로운 호출의 검증자는 이전과 같이 의미론적 유효성을 확인하지 않는다. 이는, 이러한 새로운 호출들이 특정하는 실행의 순 효과 중 적어도 일부를 일시적으로 숨기기 때문이다. 실제로, 이러한 호출에는 이러한 순 효과에 대한 커밋이 포함된다(이러한 커밋은, 이러한 순 효과를 숨기지만, 나중에는, 초기에 커밋된 순 효과가 무엇인지를 나중에 공개적으로 밝히기 위해 문을 열어둔다).
따라서, 이러한 하나의 호출(I)을 검증하도록 지정된 검증자는, I에 의해 특정된 실행(e)을 재현할 수 있으며, e의 모든 순 효과가 무엇인지를 알 수 있지만, I 내의 커밋된 순 효과가 자신이 연산한 효과인지를 결정할 수는 없다. 이에 따라, 자신의 응답에서, 이러한 검증자는, 자신의 값이 일치하는지 여부를 알지 못한 채, 자신이 연산하고 I 내에 커밋된 e의 순 효과에 대한 자신의 고유한 개인화된 커밋을 보고한다. 이러한 개인화된 커밋은, 단지 I의 해당 커밋을 복사함으로써 얻어질 수 없으며, 후자의 커밋으로부터 또는 다른 임의의 개인화된 커밋으로부터 실현가능하게 연산할 수 없다. 실제로, CDSC의 아이디어는, I의 검증자가 I에 의해 숨겨진 순 효과가 무엇인지를 알게 한 후 이러한 효과에 대한 자신의 고유한 커밋을 연산하여 자신의 응답에 포함하는 것이다. 따라서, 어떤 의미에서, I의 각 검증자는 독립적으로 행동하야 하고 실제로 I에 의해 콜된 실행(e)을 실시해야 한다.
나중에야, 본 발명의 시스템은, I에 커밋된 순 효과가 I의 충분히 많은 검증자들의 응답에 있는 (개인화된 방식으로) 커밋된 순 효과와 일치하는지 여부를 확인할 수 있게 함으로써, I의 정확성을 검증할 수 있는 정보를 밝힌다. 이에 따라, CDSC의 개별 호출 또는 호출들의 세트에 대한 최종 베르딕트가 블록체인에 게시될 수 있고, 인센티브 및/또는 처벌이 이전과 마찬가지로, 또한 새로운 방식으로 사용자에게 지정될 수 있다.
어떠한 제한도 의도하지 않고, CDSC의 추가 세부 사항을 설명한다.
1. 커밋된 호출
스마트 계약(C)의 커밋된 선언적 호출(I)은, 선언적 호출과 매우 유사하게, (주어진 입력/입력들 및 초기 상태에 대한) C의 실행(e) 및 다른 관련 데이터를 특정하지만, 대신 s에 대한 커밋을 포함함으로써 e의 순 효과의 세트(s)를 숨긴다.
주어진 값(x)에 대한 커밋은, 주어진 시점에서 x를 비밀리에 핀다운할 수 있게 하지만 나중에는 핀다운 값(x)이 무엇이었는지를 증명할 수 있게 한다. 예를 들어, 순 효과들의 세트(s)에 커밋하기 위해, I는 주어진 (충돌 방지) 해시 함수(H)에 대해 h=H(s)를 포함할 수 있다. 실제로, s에 대해 전혀 모른다면, s를 h로부터 연산하기가 어렵다. 동시에, s를 결국 밝히는 것은, 밝혀진 s가 실제로 원래의 커밋된 값이라는 것을 h를 아는 사람에게 확신시킨다. 이는 H(z)=H(s)이도록 임의의 값(z ≠ s)을 연산하는 것이 어렵기 때문이다. 대안으로, I는, 이러한 각 효과의 해시를 개별적으로 포함함으로써 순 효과들의 세트에 대하여 커밋할 수 있다. 예를 들어, s가 e에 의해 생성된 C의 새로운 상태(
Figure pct00023
) 및 e에 의해 생성된 플레이어-양 조정(
Figure pct00024
)으로 이루어지면, I는
Figure pct00025
를 포함함으로써 s에 대하여 커밋할 수 있다. 대안으로, I는, 노드들이 해당 순 효과들을 저장하는 머클 트리의 루트 값을 포함함으로써, 순 효과들의 세트(s)에 커밋할 수 있다. 보다 일반적으로, 본 발명의 시스템은 다른 커밋 방법을 사용하여 I의 일부 순 효과를 일시적으로 숨길 수 있다.
스마트 계약의 (적어도 부분적으로) 커밋된 선언적 호출의 관련 데이터는 일반적인 선언적 호출에서와 같을 수 있다.
간단히 하기 위해, 문맥이 충분히 명확하다면, 커밋된 선언적 호출(I)을, 간단하게 선언적 호출이라고 할 수 있으며, 또는 더욱 간단하게 호출이라고 할 수 있다. 스마트한 계약의 호출이 커밋된 선언적 호출이 아니라는 점을 강조하려면, 일반 호출이라는 용어를 사용할 수 있다.
설명 및 추가 세부 사항
커밋된 선언적 호출에 적용가능한 일반 호출에 대한 설명 및 및 추가 세부 사항은 자동으로 커밋된 선언적 호출로 확장된다.
적절한 호출 사용자에 의해 디지털 서명된 커밋된 호출은, C의 관련 실행의 모든 순 효과를 계속 인증하지만, 이들의 세트(s)는, 간접적인 방식으로 인증될 수 있다는 점이며, 즉, s에 대한 커밋을 인증함으로써 인증될 수 있다는 점에 주목한다.
알 수 있는 바와 같이, 본 발명의 시스템은, I에 의해 특정된 실행(e)을 연산하기 위해 모든 사용자 또는 너무 많은 사용자에게 부담을 주지 않으면서, 블록체인을 관찰하는 모든 사용자가 계약(C)의 커밋된 호출(I)이 정확한지 여부를 결정할 수 있게 한다.
이제, 이러한 커밋된 호출(I)이 어떻게 등록되는지 살펴본다.
2. 커밋된 호출의 등록
커밋된 호출(I)은 일반적인 호출과 매우 유사하게 블록체인에 진입할 수 있다. 예를 들어, I의 구문론적 유효성은 I가 블록체인에 진입하기에 충분할 수 있다.
이러한 구문론적 유효성을 검사하는 것은, I의 요금이 특정된 실행에 대해 I에 선언된 단계들의 수에 적절한지 여부를 확인하는 것을 포함할 수 있다. 실제로, 요금 및 선언된 단계의 수는, 블록체인에서 발생한 것임이 틀림없는 I에 특정된 실행(e)의 순 효과로 간주되지 않을 수 있다. 이에 따라, 요금 및 선언된 단계의 수는 공개적으로 I에 나타날 수 있다.
다시, 구문론적으로 유효하지 않은 커밋된 호출을 포함하는 블록은 유효하지 않은 것으로 간주되며, 커밋된 호출(I)의 구문론적 유효성은 I의 전파 중에 다른 사용자에게 I를 포워딩하는 데 필요할 수 있다.
커밋된 호출 I이 블록체인에 등록되면, 시스템은 그 호출의 정확성을 확인하는 프로세스를 시작한다. 이제, 이 프로세스를 설명하고자 한다.
3. 커밋된 호출의 지정
하나 이상의 블록에 등록된 하나 이상의 커밋된 스마트 계약 호출의 세트(S)는, 일반적인 호출들의 세트의 지정에 대해 설명된 방법들 중 하나에 따라 검증자들의 세트(VS)에 지정된다.
4. 커밋된 호출의 검증
커밋된 호출들의 세트(S)가 블록체인에 등록되면, VS의 각 검증자(v)는, 적절한 입력(s) 및 상태에 대해 S 내의 각 호출(I)의 계약(C)을 실행한 다음 자신의 응답을 인증하고 전파한다. 전술한 바와 같이, 이러한 응답은 I에 특정된 실행(e)의 순 효과들 중 일부에 대한 개인화된 커밋만을 포함할 수 있다. 이제, 이러한 응답의 일부 가능한 예를 살펴본다.
I가 명백하게 유효하지 않은 경우(예를 들어, 호출(e)의 단계의 수가 I에 선언된 단계의 수를 초과하는 경우), v는, 이것이 S에 대한 자신의 응답에 해당하는 경우임을 나타낸다. 예를 들어, 자신의 응답에 쌍
Figure pct00026
을 포함하는 것이다.
두 번째 예에서, e를 I(에 특정된)에 의해 콜되는 실행이라고 하고, I가 e에 대한 정확한 단계의 수를 선언한다고 하고, ne가 미리 정해진 순서와 방식으로 제시된 e의 모든 순 효과로 이루어진다고 하고, I가 커밋(H(ne))을 포함함으로써 ne를 숨긴다고 하자. 이후, e (및 이에 따라 ne)를 재구성한 후, v는, I 및 바람직하게는 ne에 대한 개인화된 커밋을 식별하는 정보를 인증할 수 있다. ne에 대한 v의 개인화된 커밋이라는 것은, (a) v가 I에 포함된 커밋(H(ne))을 알고 있고 ne에 대한 다른 커밋도 알고 있을 수 있더라도 v가 ne를 모른 채 hv를 연산하는 것이 어렵고 (b) ne와 v를 아는 상태에서 누구라도 ne에 대한 v의 개인화된 커밋을 연산하기 쉬운 것처럼, ne에 대한 커밋(hv)을 의미한다.
예를 들어, ne에 대한 v의 개인화된 커밋은
Figure pct00027
로 이루어질 수 있으며, 여기서, Hv는
Figure pct00028
와 같이 설정된 해시 함수이다. 따라서,
Figure pct00029
는 실제로 ne에 대한 v의 커밋이다. 실제로, 아무도
Figure pct00030
와 같이 다른 값(ne')을 찾을 수 없으며, 일단 값(ne)이 밝혀지면, 누구라도 실제로
Figure pct00031
를 검증할 수 있다. 또한, v에 대한 이러한 커밋은, z≠v이면 H(z, ne)로부터 및 v가 I에 제공된 커밋(H(ne))으로부터 그 값을 쉽게 연산할 수 없기 때문에, 개인화된다.
v를 ne와 함께 해싱하는 것은, ne에 대한 v의 개인화된 커밋의 일례일 뿐 어떠한 제한을 의도한 것이 아니라는 점에 주목한다. 예를 들어, H(v, ne)의 v를, v에 바람직하게 고유하게 의존하는 임의의 데이터로 교체하는 것도 좋다. ne에 대한 임의의 형태의 개인화된 커밋은 본 발명의 범위에 있다.
(일반 호출의 경우, 세트(VS)가 비밀 추첨을 통해 선택되면, v는, 자신의 응답 외에도, 실제로 자신이 VS에 속한다는 증거도 전파한다. 다시, v는 S 내의 각각의 커밋된 호출(I)에 대한 자신의 응답을 인증할 수 있고, 또는 일반 호출에서와 같이 함께 호출할 수 있다)(주석 5: 예를 들어, S의 호출들이 I1, I2, I3, I4,..이고, 호출(I1, I3,...)이 유효하고(또한 순 효과(ne1, ne3,...)를 각각 갖고), 호출(I2, I4,...)이 명백하게 유효하지 않으면, v는
Figure pct00032
를 연산 및 전파할 수 있다. 다시 말해, 더욱 간결하게, I1, I2, I3, I4,..이 주어진 순서로 S의 호출이면, v는
Figure pct00033
를 인증 및 전파할 수 있고, 여기서, 0은 대응 호출이 명백하게 유효하지 않음을 나타낸다. 검증자(v)는, 또한, 자신의 응답들을 함께 인증할 수 있지만, S 내의 개별 호출에 대한 v의 인증된 응답을 추출할 수 있게 한다. 예를 들어, v는 머클 트리를 구성할 수 있으며, 머클 트리의 각 리프는, S에 개별 호출에 대한 v의 응답을 저장한 다음 머클 트리의 루트에 저장된 값을 인증한다).
커밋된 호출(I)의 실행(e)의 순 효과(ne)에 대한 개인화된 커밋을 사용하면, 예를 들어, I에 의해 콜되는 실행(e)을 실제로 실시함으로써 값(ne)이 어떠한지를 알지 못한 채 호출(I)이 적절히 준비되었다고 v가 확신하더라도, VS의 검증자(v)가 I가 유효함을 인증하는 것이 어렵다. 동시에, ne를 알게 되면, 커밋이 I에 포함된 값(ne)이 v에 의해 개인화되는 커밋이 I에 대한 v의 응답에 포함된 값과 동일한지 여부를 누구라도 검증할 수 있다.
커밋된 호출의 정확성
VS의 정직한 검증자는, S 내의 커밋된 각 호출(I)에 대한 정확한 응답 및 이에 따라 단일 응답만을 제공한다. 이러한 호출(I)은, I에 커밋된 숨겨진 순 효과가 VS의 적어도 주어진 수(X)의 검증자들의 응답에 커밋된 순 효과와 동일한 경우, 정확한 것으로 간주된다(증명된다). VS 내의 검증자들의 적어도 Y개 응답이 I가 유효하지 않음을 나타내면, 호출(I)이 정확하지 않은 것으로 간주될 수 있다. 대안으로, I는, 블록체인의 특정 시점에서 아직 정확한 것으로 증명되지 않은 경우에는 정확하지 않은 것으로 간주될 수 있다.
그러나, ne를 알지 못하면, H(ne) = Hv(ne)인지 여부를 결정하는 것이 어렵다는 점에 주목한다. 따라서, 시스템은 어떠한 커밋된 호출이 정확한지를 결정하기 위한 소정의 방식을 필요로 한다. 이하에서는 이러한 다수의 방식을 설명한다.
4.5 숨겨진 순 효과의 개시
i를 I를 호출한 적절한 당사자라고 하고, ne를, 커밋이 I에 나타나는 I에 의해 특정된 실행(e)의 순 효과라고 하자. 의도된 일반성을 잃지 않고서, I 내의 ne에 대한 커밋 방식이 ne의 해시로 이루어진다고 가정한다. i가 정직하다고 가정하면, 아마도, i는, (1) 값(ne) 알고 있고, (2) 커밋(H(ne))을 적절하게 연산하고 I에 포함하였으며, (3) 순 효과(ne)가 실제로 블록체인에서 발생하는 것이 바람직하다.
이에 따라, VS 내의 X개보다 많은 검증자(v)가 ne에 대한 개인화된 커밋, 예를 들어, H(ne)를 해당 응답에 포함함을 i가 알게 될 때, i는, 바람직하게 인증된 방식으로 호출(I)을 식별하는 정보와 함께 ne를 전파한다.
일단 ne가 밝혀지면, 블록체인 메시지를 관찰하는 누구라도, 값(ne)이 VS 내의 적어도 X개의 검증자의 응답의 개인화된 커밋에 있으며 I에 대해 커밋된 값과 동일함을 인식하게 되며, 다시 말해, 모든 관찰자는 커밋된 호출(I)이 정확하다는 점을 알게 된다.
ne를 밝히는 것이 호출자(i)일 필요는 없다는 점에 주목한다. 예를 들어, 이는, e를 실행하였으며 ne를 연산하였고 실제로 ne가 VS 내의 적어도 X개의 검증자의 응답의 개인화된 커밋에 있으며 I에 대하여 커밋된 것과 동일함을 인식한 임의의 엔티티(예를 들어, I가 속하는 커밋된 호출들의 세트(S)에 지정된 특별한 검증자)일 수 있다.
이제, 블록체인에서 이러한 실현을 공식적으로 행할 차례이다.
5. 커밋된 호출에 대한 베르딕트
블록체인에 이미 등록되어 있지만 최종 베르딕트가 없는 커밋된 호출을 I라고 하자. 이어서, 새로운 블록(B)의 구성자(u)는, I가 정확하다는 것을 인식하고, I가 정확하다는 점을 나타내는 정보를 B에 포함하여, I에 대한 최종 베르딕트를 제공한다.
시스템은, 또한, 최종 베르딕트가 아직 존재하지 않는 블록체인에 이미 등록된 커밋된 호출들의 세트(S)에 관한 모든 커밋된 호출의 동시 최종 베르딕트를 제공할 수 있다.
예를 들어, S 내의 어떤 호출이 정확한 것인지를 알게 된, 새로운 블록(B)을 구성하는 사용자(u)는, S 내의 이러한 호출에 대한 최종 베르딕트를 B에 포함할 수 있다. 이러한 최종 베르딕트는, 세트(S) 자체를 식별하는 정보도 포함할 수 있으며, 바람직하게 인증된다. u가 B를 인증하면, 이러한 베르딕트는 u에 의해 자동으로 인증된다. 대안으로, u는 S 내의 호출에 대한 최종 베르딕트를 별도로 인증할 수 있다.
대안으로, u는 VS의 충분히 많은 검증자의 인증된 응답을 블록에 포함할 수 있어서, 이렇게 포함된 응답으로부터 S 내의 유효한 호출 및 S 내의 유효하지 않은 호출을 결정할 수 있게 한다. 이렇게 하는 경우, 일반적인 호출의 경우에 설명된 방법들 중 임의의 하나를 사용할 수 있다.
설명 및 추가 세부 사항
블록(B)은, 블록의 일반적 트랜잭션이 유효한 경우뿐만 아니라 이전에 등록된 (일반적 또는 커밋된) 호출에 대한 최종 베르딕트가 이러한 호출의 정확성을 적절히 반영하는 경우에도 유효한 것으로 간주될 수 있다.
일반적 호출에 대해 설명된 기타 설명 및 추가 세부 사항은 커밋된 호출에도 적용된다. 이것은 일반적 호출을 위해 제시된 다양한 변형 및 추가에 대해서도 마찬가지이다.
특히, 어떠한 제한도 의도하지 않고, 돈 기술에 대한 가중치는 커밋된 호출의 검증자에도 적용된다. 이에 따라, 가중치(n)를 갖는 검증자를 n개의 개별적인 검증자들로서 취급할 수 있다.
커밋된 호출(I)에 대한 응답이 I의 확립된 정확성 및/또는 I에 커밋된 순 효과의 확립된 밝혀진 값과 일치하는 검증자는, 예를 들어, 일반적 호출 또는 새로운 호출의 검증자를 설명한 인센티브 방법들 중 임의의 것에 의해, 보상을 받을 수 있다.
마찬가지로, 커밋된 호출(I)에 대한 응답이 I의 확립된 정확성 및/또는 I에 커밋된 순 효과의 확립된 밝혀진 값과 일치하지 않는 검증자는, 예를 들어, 일반적인 검증자를 전술한 인센티브 방법들 중 임의의 것에 의해 벌금을 받을 수 있거나 처벌을 받을 수 있다. 특히, 검증자들은, 적어도 몇 개의 다른 호출을 검증하도록 지정될 자격이 없어질 수 있다.
정확하지 않은 커밋된 호출(I)의 호출자는, 또한, 특별 벌금을 받거나 어떤 식으로든 처벌을 받을 수 있다.
4 변형 및 추가
스마트 계약(C)의 커밋된 호출(I)에 의해 특정된 실행(e)의 순 효과들의 세트를 s라고 하고, h=H(s)를 I에 포함된 s에 대한 커밋이라고 하자. 이어서, 다음 일부 당사자(예를 들어, I를 포함하는 호출들의 세트에 지정된 검증자와 같이 I에 지정된 검증자)는, s 자체가 충분히 예측할 수 없는 경우에 H(s)로부터 s를 연산하는 데 어려움을 겪을 수 있다. 그러나, s가 예를 들어 겨우 몇 비트로 이루어져 있다면, 일부 당사자가 h를 산출하는 해시된 값을 찾을 때까지 s에 대한 모든 가능성을 시도할 수 있다. 이러한 가능성을 막기 위해, 예를 들어, e의 모든 순효과로 이루어지도록 s를 매우 크게 선택할 수 있어서, 당사자가 이들 모두를 완전하게 추측하는 것을 어렵게 할 수 있다. 그러나, 이것으로도 때로는 충분하지 않을 수 있다.
e의 커밋된 순 효과들의 정확한 추측을 어렵게 하는 것을 보장하도록, 예측하기 어려운 특별히 선택된 금액을 이러한 순 효과들에 인위적으로 포함할 수 있다. 예를 들어, 관심을 갖는 e의 순 효과들이 새로운 상태(
Figure pct00034
) 및 소수의 플레이어-양 조정(
Figure pct00035
)이더라도, I의 적절한 호출자는, 실행(e)의 종료시 C의 특별한 보조 변수의 콘텐츠(x)를 이러한 순 효과들에 인위적으로 추가할 수 있고,
Figure pct00036
라고 하자. 실제로, 항상 e의 순 효과들을 예측하기 쉽더라도, e의 연산은, 간단한 효과를 생성하기 위해 충분히 예측할 수 없는 가변 콘텐츠를 가질 수 있거나 이러한 가변 콘텐츠를 갖도록 설계될 수 있다. 따라서, x가 예측하기 어려운 경우,
Figure pct00037
를 예측하는 것이 상당히 쉽더라도
Figure pct00038
를 H(s)로부터 예측하는 것은 어려울 것이다(당연히, x는, 순전히 보조 역할을 하므로, 호출(I)이 정확하면 블록체인에서 발생하는 순 효과로서 취급되어서는 안 된다).
대안으로, 값(x)은, e 및 완전히 분리된 특정 프로그램(P)의 실행, I에 포함되거나 I로부터 추론가능한 완전히 분리된 특정 입력(y)에 의존할 수 있다. 이러한 프로그램(P) 및 입력(y)은, x를 P 및 y로부터 예측하기 어렵도록 선택될 수 있다. 예를 들어, P의 연산은 때때로 실행(e)으로부터 얻어지는 금액을 포함할 수 있다. 대안으로, P(y)의 연산은 e와 완전히 무관될 수 있다.
다시, I는, x에 대한 커밋, 및 I의 실행 e를 검증하도록 (직접적으로 또는 간접적으로) 지정된 검증자(v)를 포함할 수 있고, 또한, x를 연산하고 자신의 응답에 x에 대한 개인화된 커밋을 포함하도록 요청받을 수 있다. I에 지정된 충분히 많은 검증자의 이러한 개인화된 커밋의 기본 값들이 서로 일치하고 I에서 커밋된 기본 값(x)과 일치하는 경우에만, I가 정확한 것으로 간주될 수 있다. 따라서, I에 지정된 검증자는, I에 대한 자신의 응답이 적절하게 카운트되는 것을 원한다면, x를 적절하게 연산하도록 권장된다.
당업자가 사용할 수 있는 상술한 임의의 가능한 변형 및 다른 가능한 변형에 있어서, I에 선언된 총 단계의 수는 x를 연산하는 데 필요한 단계의 수도 포함해야 하고, 따라서 I의 지불가능한 요금을 증가시킬 수 있다는 점에 주목한다. 그러나, I의 적절한 호출자는, I의 검증자가 x를 적절하게 연산한다는 점을 더욱 확신하기 위해 기꺼이 더 높은 요금을 지불할 수 있다.
또한, 이러한 값(x)이 어떠한 방식으로 사용되든, I가 e의 실제 순 효과를 포함하는 것이 가능할 수도 있으며, 예를 들어, I가 정확한다면 블록체인에서 실제로 발생해야 하는 순 효과가 있으며, 또한, 공개적인 방식으로, x에 대한 개인화된 커밋이 I의 유일한 커밋으로 되게 할 수 있다. 이 경우, I를 포함하는 세트(S)에 지정된 검증자(v)는, (1) 공개적으로 선언된 e의 순 효과가 정확한지 여부를 나타내며 (2) x에 대한 개인화된 커밋을 포함하는 응답을 생성하도록 요청받는다. 이 경우, 호출(I)은, I에 커밋된 x의 값이 S에 지정된 충분히 많은 검증자(v)의 응답들에서 커밋된 값과 일치하고 이러한 응답들이 공개적으로 선언된 I의 순 효과들이 정확함을 나타내면, 정확한 것으로 간주된다.
본원에서 설명하는 메커니즘은 일반적으로 검증가능한 방식으로 검증과 같은 특정 목적을 위해 사용자들의 서브세트를 랜덤하게 선택하는 것이 바람직한 다른 블록체인 시스템에 적용가능하다는 점에 주목한다. 따라서, 본원에서 설명하는 시스템은 이더리움 또는 라이트코인 등의 다른 블록체인 체계, 또는 심지어 통화와 직접 관련이 없는 블록체인 체계에 대하여 구성될 수 있다.
본원에서 설명하는 시스템은, 다음에 따르는 미국 및 PCT 특허출원건들 중 임의의 것 또는 모두에 개시된 메커니즘에 적용 및 결합되도록 구성될 수 있으며, 이들 모두는 본원에 참고로 원용된다: 2015년 2월 17일에 출원된 제62/117,138호, 2015년 2월 26일에 출원된 제62/120,916호, 2015년 4월 2일에 출원된 제62/142,318호, 2015년 9월 15일에 출원된 제62/218,817호, 2016년 3월 29일에 출원된 제62/314,601호, 2016년 2월 17일에 출원된 국제출원번호 PCT/US2016/018300, 2016년 4월 25일에 출원된 제62/326,865호, 2016년 5월 4일에 출원된 제62/331,654호, 2016년 5월 9일에 출원된 제62/333,340호, 2016년 5월 31일에 출원된 제62/343,369호, 2016년 6월 2일에 출원된 제62/344,667호, 2016년 6월 7일에 출원된 제62/346,775호, 2016년 6월 16일에 출원된 제62/351,011호, 2016년 6월 22일에 출원된 제62/353,482호, 2016년 6월 24일에 출원된 제62/354,195호, 2016년 7월 19일에 출원된 제62/363,970호, 2016년 8월 1일에 출원된 제62/369,447호, 2016년 8월 24일에 출원된 제62/378,753호, 2016년 9월 2일에 출원된 제62/383,299호, 2016년 9월 13일에 출원된 제62/394,091호, 2016년 9월 27일에 출원된 제62/400,361호, 2016년 10월 3일에 출원된 제62/403,403호, 2016년 10월 20일에 출원된 제62/410,721호, 2016년 11월 3일에 출원된 제62/416,959호, 2016년 11월 16일에 출원된 제62/422,883호, 2017년 2월 6일에 출원된 제62/455,444호, 2017년 2월 14일에 출원된 제62/458,746호, 2017년 2월 16일에 출원된 제62/459,652호, 2017년 3월 15일에 출원된 제62/471,562호, 2017년 5월 16일에 출원된 제62/507,074호, 2017년 5월 25일에 출원된 제62/510,905호, 2017년 6월 21일에 출원된 제62/522,927호, 2017년 7월 24일에 출원된 제62/536,061호, 2017년 8월 4일에 출원된 제62/541,568호, 2017년 8월 21일에 출원된 제62/548,201호, 2017년 5월 4일에 출원된 국제출원번호 PCT/US2017/031037, 2017년 8월 17일에 출원된 제15/551,678호, 2017년 9월 28일에 출원된 제62/564,670호, 2017년 10월 4일에 출원된 제62/567,864호, 2017년 10월 10일에 출원된 제62/570,256호, 2017년 11월 2일에 출원된 제62/580,757호, 2017년 12월 19일에 출원된 제62/607,558호, 2018년 2월 20일에 출원된 제62/632,944호, 및 2018년 3월 15일에 출원된 제62/643,331호.
본원에서 설명하는 시스템의 소프트웨어 구현예들은, 컴퓨터 판독가능 매체에 저장되고 하나 이상의 프로세서에 의해 실행되는 실행가능 코드를 포함할 수 있다. 컴퓨터 판독가능 매체는, 비일시적일 수 있고, 컴퓨터 하드 드라이브, ROM, RAM, 플래시 메모리, CD-ROM, DVD-ROM, 플래시 드라이브, SD 카드 등의 휴대용 컴퓨터 저장 매체, 및/또는 예를 들어 범용 직렬 버스(USB) 인터페이스를 갖는 기타 드라이브, 및/또는 실행가능 코드가 저장될 수 있고 프로세서에 의해 실행될 수 있는 다른 임의의 적절한 유형 또는 비일시적 컴퓨터 판독가능 매체 또는 컴퓨터 메모리를 포함할 수 있다. 본원에서 설명하는 시스템은 임의의 적절한 운영 체제와 관련하여 사용될 수 있다.
당업자에게는, 본 발명의 다른 실시예들이 본원에 개시된 본 발명의 명세서 또는 실시를 고려하여 명백할 것이다. 본 명세서와 예들은 예시적인 것으로만 간주하고, 본 발명의 진정한 범위 및 사상은 하기의 청구범위로 나타내고자 한다.

Claims (30)

  1. 트랜잭션들이 블록들로 조직되는 트랜잭션 시스템에서, 이전 블록들(B0, B1,..., Br- 1)의 시퀀스에 관하여 새로운 블록들(Br 및 Br+1)을 제공하는 방법으로서,
    블록(Br)이 블록(Br-1)의 트랜잭션들의 상태와 일치하는 트랜잭션들의 초기 상태들을 나타냄을 확인한 후에 상기 블록(Br)이 구성되게 하는 단계;
    블록(Br+1)이 상기 블록(Br)의 트랜잭션들의 상태와 일치하는 트랜잭션들의 초기 상태들을 나타냄을 확인한 후에 상기 블록(Br+1)이 구성되게 하는 단계; 및
    상기 블록(Br+1)이 구성된 후에 복수의 엔티티가 상기 블록(Br)의 이전에 검증되지 않은 트랜잭션들을 검증하게 하는 단계를 포함하는, 방법.
  2. 제1항에 있어서, 상기 트랜잭션들은 스마트 계약들인, 방법.
  3. 제2항에 있어서, 사용자는, 상기 블록(Br)의 상기 스마트 계약들 중 적어도 하나에 트랜잭션을 게시하는 것과 관련하여 상기 블록(Br)을 구성하는, 방법.
  4. 제3항에 있어서, 상기 사용자는, 또한, 상기 블록(Br)의 스마트 계약들에 대한 트랜잭션 결과를 게시하는, 방법.
  5. 제4항에 있어서, 상기 사용자는, 또한, 상기 블록(Br)의 스마트 계약들에 대한 스마트 계약 결과의 실행을 위한 단계의 수를 게시하는, 방법.
  6. 제5항에 있어서, 상기 사용자는, 또한, 상기 블록(Br)의 트랜잭션들을 검증하도록 상기 복수의 엔티티가 수신하는 요금을 게시하는, 방법.
  7. 제1항에 있어서, 상기 복수의 엔티티는 상기 블록(Br)의 모든 사용자들의 서브세트인, 방법.
  8. 제7항에 있어서, 상기 복수의 엔티티는 랜덤하게 선택되는, 방법.
  9. 제8항에 있어서, 상기 복수의 엔티티를 랜덤하게 선택하는 단계는, 시간 정보, 상기 블록들 중 하나 이상에 대한 정보, 상기 블록들 중 하나 이상에 포함된 데이터, 또는 상기 블록들 중 하나 이상으로부터 추론된 데이터 중 적어도 하나를 포함하는 데이터에, 암호화 해시 함수를 적용하는 단계를 포함하는, 방법.
  10. 블록체인의 블록(B)을 상기 블록체인에 추가하는 방법으로서,
    엔티티가 이전 블록에 대응하는 정보를 수신하게 하는 단계;
    주어진 입력에 대한 스마트 계약 실행의 선언적 호출(declarative invocation)을 상기 엔티티가 수신하게 하는 단계로서, 상기 선언적 호출은 상기 실행의 관련 결과 및 다른 관련 데이터를 선언하는, 단계;
    상기 엔티티가 상기 호출의 구문론적 유효성(syntactic validity)을 검증하게 하는 단계; 및
    상기 호출의 구문론적 유효성의 검증에 응답하여, 상기 엔티티가 상기 선언적 호출을 상기 블록(B)에 통합하게 하는 단계를 포함하는, 방법.
  11. 제10항에 있어서, 상기 관련 결과는, 상기 스마트 계약 실행의 순 효과, 실행 후의 상기 스마트 계약의 결과적인 상태, 및 실행을 위한 단계의 수 중 적어도 하나를 특정하고, 상기 다른 관련 데이터는, 상기 선언적 호출의 호출자, 시간 정보, 블록 정보, 및 지불가능한 요금 중 적어도 하나를 특정하는, 방법.
  12. 제11항에 있어서, 상기 선언적 호출은, 상기 요금이 상기 실행을 위한 단계의 수에 대하여 적합하고 상기 요금의 지불자가 상기 요금을 지불하기 위한 충분한 자산을 갖고 있다면, 구문론적으로 유효하고, 상기 선언적 호출이 상기 블록체인에 보이면 상기 요금이 지불되는, 방법.
  13. 블록체인의 검증자들의 세트를 지정하여 주어진 입력에 대한 스마트 계약 실행의 하나 이상의 선언적 호출의 세트(S)를 검증하는 방법으로서, 상기 선언적 호출은 상기 스마트 계약 실행의 관련 결과를 선언하고, 상기 방법은,
    상기 검증자들이 상기 세트(S)를 수신하는 단계;
    상기 검증자들이 상기 S의 선언적 호출 중 어느 것이 의미론적으로 유효한지를 결정하는 단계; 및
    상기 검증자들이 상기 의미론적으로 유효한 하나 이상의 선언적 호출의 인증된 응답을 제공하는 단계를 포함하는, 방법.
  14. 제13항에 있어서, 상기 검증자들의 세트는, 주어진 암호화 함수를 통해 의사 랜덤 방식으로 S에 기초하여 선택되는, 방법.
  15. 제14항에 있어서, 적어도 하나의 검증자는, 상기 적어도 하나의 검증자의 비밀 키를 수반하는 연산을 통해 상기 적어도 하나의 검증자가 선택되었다고 결정하고, 상기 적어도 하나의 검증자는 상기 적어도 하나의 검증자가 선택되었음을 다른 검증자들에 증명할 수 있는, 방법.
  16. 제13항에 있어서, S에 지정된 적어도 주어진 개수의 검증자들의 응답이 호출(I)이 의미론적으로 정확함을 나타내면, S의 호출(I)은 정확한 것으로 간주되는, 방법.
  17. 선언적 스마트 계약 호출들의 세트(S)가 미리 등록되었으며, 검증자들의 세트가 S에 지정되고, 상기 검증자들이 S의 호출들 중 의미론적으로 유효한 호출에 관한 인증된 응답들을 제공한 블록체인에서, S의 호출들의 베르딕트가 상기 블록체인에 통합되게 하는 방법으로서,
    엔티티가 상기 검증자들의 인증된 응답들을 수신하게 하는 단계;
    상기 엔티티가 상기 S의 호출들의 정확성을 추론하게 하는 단계; 및
    상기 엔티티가 상기 S의 호출들의 정확성에 관한 최종 베르딕트를 상기 블록체인에 통합하게 하는 단계를 포함하는, 방법.
  18. 제17항에 있어서, 상기 S의 호출(I)의 최종 베르딕트는, 상기 S에 지정된 적어도 주어진 개수의 상기 검증자들의 응답들이 I가 의미론적으로 유효함을 나타내면, I가 정확함을 나타내는, 방법.
  19. 제17항에 있어서, 상기 S의 호출(I)의 최종 베르딕트가 I가 정확함을 나타내면, 다른 사용자들이 상기 스마트 계약의 상태를 갱신하게 하고 상기 스마트 계약의 실행의 선언된 순 효과가 발생한 것으로 간주하게 하는, 방법.
  20. 블록체인의 블록(B)을 상기 블록체인에 추가하는 방법으로서,
    엔티티가 이전 블록에 대응하는 정보를 수신하게 하는 단계;
    주어진 입력에 대한 스마트 계약 실행의 커밋(commit)된 선언적 호출을 수신하는 단계로서, 상기 커밋된 선언적 호출은, 상기 실행의 적어도 일부 관련 결과, 상기 실행의 다른 관련 결과에 대한 커밋, 및 다른 관련 데이터를 선언하는, 단계;
    상기 커밋된 선언적 호출의 상기 구문론적 유효성을 검증하는 단계; 및
    상기 커밋된 선언적 호출의 구문론적 유효성의 검증에 응답하여, 상기 블록(B) 내에 상기 커밋된 선언적 호출을 통합하는 단계를 포함하는, 방법.
  21. 제20항에 있어서, 상기 관련 결과는 실행의 순 효과, 실행 후의 상기 계약의 결과적인 상태, 및 단계의 수 중 적어도 하나를 특정하고, 상기 다른 관련 데이터는 상기 호출의 호출자, 시간 정보, 블록 정보, 및 지불가능한 요금 중 적어도 하나를 특정하는, 방법.
  22. 제21항에 있어서, 상기 선언적 호출은, 상기 단계의 수에 대하여 상기 요금이 적절하고 상기 요금의 지불자가 상기 요금을 지불할 충분한 자산을 시스템에서 갖고 있으면, 구문론적으로 유효하고, 상기 호출이 상기 블록체인에 나타나면 상기 요금이 지불되는, 방법.
  23. 주어진 입력에 대한 스마트 계약의 실행(e)을 특정하는 적어도 하나의 커밋된 선언적 호출(I)을 포함하는 선언적 호출들의 세트(S)를 검증하도록 블록체인 내의 검증자들의 세트가 지정되게 하는 방법으로서, I는 e의 적어도 일부 관련 결과(rr)에 대한 커밋을 포함하고, 상기 방법은,
    상기 검증자들이 상기 세트(S)를 수신하는 단계;
    상기 검증자들이 실행(e)을 재구성하여 상기 관련 결과(rr)를 연산하는 단계;
    상기 검증자들이 상기 검증자들의 rr에 대한 개인화된 커밋을 포함하는 인증된 응답을 제공하는 단계를 포함하는, 방법.
  24. 제23항에 있어서, 지정된 상기 검증자들은, 주어진 암호화 함수를 통해 의사 랜덤 방식으로 S에 기초하여 선택되는, 방법.
  25. 제34항에 있어서, 적어도 하나의 검증자는, 상기 적어도 하나의 검증자가 상기 적어도 하나의 검증자의 비밀 키를 포함하는 연산을 통해 선택되었음을 결정할 수 있고, 상기 적어도 하나의 검증자는 상기 적어도 하나의 검증자가 선택되었음을 다른 이들에게 증명할 수 있는, 방법.
  26. 제23항에 있어서, S 내의 상기 커밋된 선언적 호출(I)은, S에 지정된 적어도 주어진 수의 검증자들의 응답들이 I에 커밋된 상기 관련 결과(rr)에 대한 개인화된 커밋을 포함하는 경우에만, 정확한 것으로 간주되는, 방법.
  27. 선언적 스마트 계약 호출들의 세트(S)가 미리 등록되고, 검증자들의 세트가 S에 지정되고, 상기 세트(S)는 주어진 입력에 대한 스마트 계약의 실행(e)을 특정하는 적어도 하나의 커밋된 선언적 호출(I)을 포함하고, I는 e의 적어도 일부 관련 결과(rr)에 대한 커밋을 포함하고, 상기 검증자들은 S의 호출들에 관한 인증된 응답들을 제공한 블록체인에서, 상기 S의 호출들의 베르딕트가 상기 블록체인에 통합되게 하는 방법은,
    엔티티가 상기 검증자들의 인증된 응답들을 수신하게 하는 단계;
    상기 엔티티가 상기 S의 호출들을 정확성을 추론하게 하는 단계; 및
    상기 엔티티가 상기 S의 호출들의 정확성에 관한 최종 베르딕트를 상기 블록체인에 통합하게 하는 단계를 포함하는, 방법.
  28. 제27항에 있어서, S에 지정된 적어도 주어진 수의 상기 검증자들의 응답들은 I에 커밋된 동일한 관련 결과(rr)에 대한 개인화된 커밋을 포함하고, 상기 S 내의 커밋된 선언적 호출(I)의 최종 베르딕트는 I가 정확함을 나타내는, 방법.
  29. 제28항에 있어서, 상기 I의 정확성의 최종 베르딕트는, 다른 이들이 상기 스마트 계약의 상태를 갱신하게 하고 상기 스마트 계약의 실행(e)의 순 효과가 발생한 것을 고려하게 하는, 방법.
  30. 제1항 내지 제29항 중 어느 한 항의 방법을 구현하는 실행가능 코드를 포함하는, 비일시적 컴퓨터 판독가능 매체에 제공된 컴퓨터 소프트웨어.
KR1020207012480A 2017-10-04 2018-10-04 선언적 스마트 계약 KR20200101328A (ko)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US201762567864P 2017-10-04 2017-10-04
US62/567,864 2017-10-04
US201762570256P 2017-10-10 2017-10-10
US62/570,256 2017-10-10
US201762580757P 2017-11-02 2017-11-02
US62/580,757 2017-11-02
US201762607558P 2017-12-19 2017-12-19
US62/607,558 2017-12-19
US201862632944P 2018-02-20 2018-02-20
US62/632,944 2018-02-20
US201862643331P 2018-03-15 2018-03-15
US62/643,331 2018-03-15
PCT/US2018/054311 WO2019070938A1 (en) 2017-10-04 2018-10-04 INTELLIGENT DECLARATIVE CONTRACTS

Publications (1)

Publication Number Publication Date
KR20200101328A true KR20200101328A (ko) 2020-08-27

Family

ID=65994758

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020207012480A KR20200101328A (ko) 2017-10-04 2018-10-04 선언적 스마트 계약

Country Status (12)

Country Link
US (1) US20200313896A1 (ko)
EP (1) EP3692699A4 (ko)
JP (2) JP7305627B2 (ko)
KR (1) KR20200101328A (ko)
CN (2) CN111567009B (ko)
AU (2) AU2018346326B2 (ko)
CA (1) CA3078328A1 (ko)
IL (1) IL273767A (ko)
MX (1) MX2020003931A (ko)
RU (1) RU2020115149A (ko)
SG (1) SG11202002848VA (ko)
WO (1) WO2019070938A1 (ko)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7040218B2 (ja) * 2018-03-29 2022-03-23 富士通株式会社 ブロックチェーンプログラム及びブロックチェーン方法
CN113095822A (zh) * 2018-06-27 2021-07-09 创新先进技术有限公司 基于区块链的智能合约调用方法及装置、电子设备
CN109003078B (zh) 2018-06-27 2021-08-24 创新先进技术有限公司 基于区块链的智能合约调用方法及装置、电子设备
CN110300167B (zh) * 2019-06-28 2020-07-31 京东数字科技控股有限公司 基于区块链的业务信息处理方法、设备及可读存储介质
CN110298643A (zh) * 2019-08-22 2019-10-01 深圳市先河系统技术有限公司 基于区块链的手续费分配方法、装置及存储介质
CN111930717B (zh) * 2020-08-07 2024-06-07 暨南大学 基于区块链与自然语言处理的众包数据库构建方法及装置
US20230014140A1 (en) * 2021-07-14 2023-01-19 Fortior Blockchain, Lllp Smart contract system using artificial intelligence
CN114338006B (zh) * 2021-12-24 2023-01-24 浙江大学 基于半可信硬件的互相关伪随机数的远程获取方法及装置

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2476646A1 (en) * 2002-02-14 2003-08-21 Zachary Pessin Apparatus and method of a distributed capital system
US7809777B2 (en) * 2005-07-01 2010-10-05 Qnx Software Systems Gmbh & Co. Kg File system having deferred verification of data integrity
US7873683B2 (en) * 2005-07-01 2011-01-18 Qnx Software Systems Gmbh & Co. Kg File system having transaction record coalescing
US9501795B1 (en) * 2010-08-23 2016-11-22 Seth Gregory Friedman Validating an electronic order transmitted over a network between a client server and an exchange server with a hardware device
EP2634738A1 (en) * 2012-03-02 2013-09-04 Alcatel Lucent Decentralized electronic transfer system
GB201407614D0 (en) * 2014-04-30 2014-06-11 Piksel Inc Content delivery system
US20170140408A1 (en) * 2015-11-16 2017-05-18 Bank Of America Corporation Transparent self-managing rewards program using blockchain and smart contracts
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
WO2017136643A1 (en) * 2016-02-03 2017-08-10 Luther Systems System and method for secure management of digital contracts
US20170243193A1 (en) 2016-02-18 2017-08-24 Skuchain, Inc. Hybrid blockchain
US10475030B2 (en) * 2016-02-22 2019-11-12 Bank Of America Corporation System for implementing a distributed ledger across multiple network nodes
US10762504B2 (en) * 2016-02-22 2020-09-01 Bank Of America Corporation System for external secure access to process data network
US10387878B2 (en) * 2016-02-22 2019-08-20 Bank Of America Corporation System for tracking transfer of resources in a process data network
US10223685B2 (en) * 2016-02-26 2019-03-05 Arithmetic Operations Incorporated Systems, methods, and media for pay-per-access micropayment-based web browsing and server applications
US10063529B2 (en) * 2016-03-28 2018-08-28 Accenture Global Solutions Limited Secure 3D model sharing using distributed ledger
CN105893042A (zh) * 2016-03-31 2016-08-24 北京航空航天大学 一种基于区块链的智能合约的实现方法
US10204341B2 (en) * 2016-05-24 2019-02-12 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permissioned blockchains using bloom filters and audit guarantees
US10198325B2 (en) * 2016-05-24 2019-02-05 Mastercard International Incorporated Method and system for desynchronization recovery for permissioned blockchains using bloom filters
US10305694B2 (en) * 2016-05-27 2019-05-28 Mastercard International Incorporated Method and system for efficient distribution of configuration data utilizing permissioned blockchain technology
US10565570B2 (en) * 2016-09-27 2020-02-18 The Toronto-Dominion Bank Processing network architecture with companion database
CN106385319B (zh) * 2016-09-29 2020-11-27 江苏通付盾科技有限公司 区块链网络中信息的验证方法及系统
CN106780033A (zh) * 2016-12-16 2017-05-31 杭州云象网络技术有限公司 一种基于联盟链的数字票据交易系统构建方法
EP3593305A4 (en) * 2017-03-08 2020-10-21 IP Oversight Corporation SYSTEM AND PROCEDURE FOR GENERATING TOKENS SECURED BY THE VALUE OF GOODS FROM RESERVES
WO2018175666A1 (en) * 2017-03-21 2018-09-27 Dappsters, LLC Blockchain systems and methods
US10310918B2 (en) * 2017-03-22 2019-06-04 International Business Machines Corporation Information sharing among mobile apparatus
WO2018222066A1 (en) * 2017-05-30 2018-12-06 Siemens Aktiengesellschaft Industrial network using a blockchain for access control, and access control method
US10795977B2 (en) * 2017-08-24 2020-10-06 Oracle International Corporation Digital asset traceability and assurance using a distributed ledger
US20190147553A1 (en) * 2017-11-14 2019-05-16 TitleFlow LLC Storing linked lists of mineral rights transactions in directed acyclic graphs of cryptographic hash pointers
US11468046B2 (en) * 2018-01-17 2022-10-11 Geeq Corporation Blockchain methods, nodes, systems and products
EP3610450A4 (en) * 2019-03-28 2020-06-10 Alibaba Group Holding Limited SYSTEM AND METHOD FOR PARALLEL PROCESSING OF BLOCK CHAIN TRANSACTIONS

Also Published As

Publication number Publication date
SG11202002848VA (en) 2020-06-29
AU2023270268A1 (en) 2023-12-07
WO2019070938A1 (en) 2019-04-11
US20200313896A1 (en) 2020-10-01
AU2018346326A1 (en) 2020-04-16
IL273767A (en) 2020-05-31
AU2018346326B2 (en) 2023-08-24
MX2020003931A (es) 2020-10-12
JP7305627B2 (ja) 2023-07-10
CN111567009B (zh) 2022-07-12
CN111567009A (zh) 2020-08-21
CN114677135A (zh) 2022-06-28
RU2020115149A (ru) 2021-11-08
CA3078328A1 (en) 2019-04-11
EP3692699A1 (en) 2020-08-12
RU2020115149A3 (ko) 2021-11-08
JP2020537391A (ja) 2020-12-17
JP2023138978A (ja) 2023-10-03
EP3692699A4 (en) 2021-08-25

Similar Documents

Publication Publication Date Title
KR20200101328A (ko) 선언적 스마트 계약
Teutsch et al. A scalable verification solution for blockchains
KR102609711B1 (ko) 블록체인을 사용한 동시적 상태 머신 프로세싱
Miller et al. Nonoutsourceable scratch-off puzzles to discourage bitcoin mining coalitions
CN110097467B (zh) 一种针对智能合约安全性和稳定性的侧链测试系统和方法
CN109039648B (zh) 一种区块链的创建方法、设备及可读存储介质
Allombert et al. Introduction to the tezos blockchain
JP5166654B2 (ja) 電子取引を認証するためのシステムと方法
KR102537774B1 (ko) 기밀 지식의 특화된 증명을 제공하는 시스템들 및 방법들
JP2022531742A (ja) ブロックチェーンネットワークにおいて作業履歴を記録し及び評判を証明する方法及び装置
CN113875188A (zh) 哈希函数攻击
CN114175036A (zh) 使用区块链交易提供链下功能
JP2022531741A (ja) ブロックチェーンネットワーク内でマイナーアイデンティティを登録及び認証する方法及び装置
CN114175035A (zh) 用于核实区块链交易有效的协议
KR20190078668A (ko) 검증가능한 추첨을 위한 장치 및 방법
CN112367174A (zh) 一种基于属性值的区块链共识方法及装置
JP2021530173A (ja) コンピュータネットワークの間のタスクの分配のためのアキュムレータに基づくプロトコルのためのコンピュータ実施システム及び方法
CN112070503A (zh) 一种基于区块链的合同执行方法、装置、设备和存储介质
CN111881147A (zh) 计算任务的处理方法和装置、存储介质及处理器
CN113875185A (zh) 知识证明
BR112020006828A2 (pt) contratos inteligentes declarativos
Buterin et al. Notes on Scalable Blockchain Protocols (verson 0.3)
KR102671062B1 (ko) 보안 거래를 위한 방법 및 시스템
Andersen Implementation of a tournament based distributed lottery on Ethereum
Vaes Blockchains and the evolution of smart contract languages: an overview

Legal Events

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