KR20210087552A - 분산 리소스 할당을 위한 시스템 및 방법 - Google Patents

분산 리소스 할당을 위한 시스템 및 방법 Download PDF

Info

Publication number
KR20210087552A
KR20210087552A KR1020217020352A KR20217020352A KR20210087552A KR 20210087552 A KR20210087552 A KR 20210087552A KR 1020217020352 A KR1020217020352 A KR 1020217020352A KR 20217020352 A KR20217020352 A KR 20217020352A KR 20210087552 A KR20210087552 A KR 20210087552A
Authority
KR
South Korea
Prior art keywords
transaction
account
transactions
computing device
amount
Prior art date
Application number
KR1020217020352A
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 KR20210087552A publication Critical patent/KR20210087552A/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1074Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0631Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06313Resource planning in a project environment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061Partitioning or combining of resources
    • G06F9/5072Grid computing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N7/00Computing arrangements based on specific mathematical models
    • G06N7/01Probabilistic graphical models, e.g. probabilistic networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/389Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/403Solvency checks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1087Peer-to-peer [P2P] networks using cross-functional networking aspects
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00Business processing using cryptography
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • Game Theory and Decision Science (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Tourism & Hospitality (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Educational Administration (AREA)
  • Marketing (AREA)
  • Mathematical Analysis (AREA)
  • Computational Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Algebra (AREA)
  • Probability & Statistics with Applications (AREA)
  • Computer Hardware Design (AREA)
  • Hardware Redundancy (AREA)

Abstract

리소스 할당 시스템(분산 원장이라고 알려짐)은 확장성 문제를 극복하면서 시스템 리소스 양이 손상되지 않고 리소스 수신자가 거래 수수료 등의 대가로 계정 내역을 유지 관리하는 분산 노드를 요구하여 그들에게 전달된 리소스를 신뢰할 수 있도록 보장하여 확률적으로 거래 내역을 검증하고 유효하지 않은 이전 거래로 손상된 거래를 복구하기 위해 자신의 계정에 예비 리소스를 유지한다. 권한이 없는 환경에서도 이러한 시스템은 유지 관리하지 않는 사용자의 계정을 손상시키지 않고 거래 내역의 최종 일관성을 유지할 수 있다.

Description

분산 리소스 할당을 위한 시스템 및 방법
관련 출원
본 출원은 2018년 11월 30일 제출된 미국 가출원 특허 제62/773,692호에 대해 우선권의 이익을 주장하며, 그 전체 내용은 모든 목적을 위해 본 명세서에 참조로 포함된다.
기술분야
본 개시는 분산 리소스 할당을 위한 시스템 및 방법에 관한 것이다. 보다 구체적으로, 본 개시는 분산 쿼럼 시스템(distributed quorum system)을 사용하도록 설계된 분산 스토리지 및 데이터베이스뿐만 아니라 암호 화폐 및 분산 원장(distributed ledger)과 같은 분산 컴퓨팅 시스템에 관한 것이다. 추가적으로 또는 대안적으로, 본 개시는 분산된 저장 및 검색, 리소스의 추적 및 합의를 설정, 판정 및/또는 유지하고 거래를 검증하는 메커니즘을 포함하는 분산 컴퓨터 시스템에 관한 것이다.
배경 섹션에서 논의된 주제는 단순히 배경 섹션에서 언급된 내용 때문에 선행 기술로 간주되어서는 안된다. 마찬가지로, 배경 섹션에서 언급되거나 배경 섹션의 주제와 관련된 문제는 종래 기술에서 이전에 인식된 것으로 간주되어서는 안된다. 배경 섹션의 주제는 단지 다른 접근법을 나타내며, 그 자체로도 청구된 실시예에 대응할 수 있다.
관련없는 에이전트에 의해 제어될 수 있는 분산 컴퓨팅 노드의 시스템은 개별 노드 및/또는 노드의 서브세트에 도달하는 다양한 입력을 기반으로 작업을 수행할 수 있다. 예를 들어, 작업은 컨텐츠 저장 및/또는 검색, 및/또는 외부 시스템(예를 들어, 장치, 네트워크, 에이전트 및/또는 인터페이스)으로부터 메시지를 수신 및/또는 외부 시스템으로 메시지를 송신하는 것을 포함할 수 있다. 분산 시스템의 예는 분산 데이터베이스, 분산 머신 러닝 시스템, 암호 화폐 시스템 및/또는 분산 소스 제어 시스템을 포함하지만 이에 제한되지 않는다.
특정 작업을 수행할지 여부를 결정하고, 그러한 결정을 전파 및 기록하고, 이전 결정을 취소하고, 복구(repair) 작업을 수행하는 것은 결정 자체와 마찬가지로 모두 비용을 포함할 수 있다. 잘못된 결정의 비용은 매우 높을 수 있다; 그러나 완벽한 의사 결정은 일반적으로 실행 가능하지 않거나 비용이 매우 많이 든다. 규모에 맞는 실제 응용 프로그램은 불완전성을 처리할 수 있는 시스템을 사용할 수 있지만 도입되어 스스로를 치료할 수 있다.
일부 예에서, 분산 컴퓨팅 시스템은 시스템의 의도된 목적을 전복(subvert)시키거나 잠재적으로 전복시킬 수 있는 방식으로 의도적으로 및/또는 비의도적으로 행동 및/또는 행동하지 않는 엔티티(예를 들어, 노드 및/또는 사용자)를 포함할 수 있다. 따라서, 일부 애플리케이션은 이러한 사용자 또는 노드에도 불구하고 목적을 달성하도록 설계되었다.
중앙 서비스 및/또는 하나의 엔티티가 제어하는 서비스에 의존하는 애플리케이션은 사용자가 해당 중앙 서비스의 제공자와 동일한 동기 및 인센티브를 갖지 않을 수 있기 때문에 신뢰할 수 없을 수 있다. 예를 들어, Google 및 Facebook과 같은 검색 및 소셜 미디어 서비스의 제공자의 경우, 광고 수익을 추구하고 전 세계 정부의 규정을 준수하면 사용자가 원하는 목적이 아닌 다른 목적으로 사용자 데이터를 활용할 수 있는 인센티브가 생길 수 있다. 가상 화폐의 제공과 같은 다른 애플리케이션도 다양한 목적을 위해 중앙 엔티티의 작업에 악영향을 미칠 수 있다.
한편, “피어 투 피어” 서비스로 제공되는 애플리케이션은 여러 다른 엔티티에 의해 제어되는 컴퓨팅 노드 간에 애플리케이션의 동작이 분산되어 서비스의 일부 개별 노드 운영자가 서비스의 목적에 맞지 않는 동기를 가질 수 있으며 서비스를 다른 사람에게 신뢰할 수 없게 만드는 방식으로 행동할 수 있다는 문제에 직면할 수 있다. 예를 들어, 피어 투 피어 파일 공유를 지원하기 위한 Napster 및 Gnutella 네트워크에서 많은 “프리 라이더” 노드는 자신을 호스팅하지 않고 단순히 피어에서 파일을 다운로드했다[FC2005]. 신뢰할 수 없는 노드에 의한 서브버젼(subversion)을 피하기 위해 일부 분산 시스템은 확장 능력과 같은 시스템의 다른 기능을 손상시키는 다른 형태의 중앙 집중화를 도입할 수 있다. 예를 들어, 비트 코인과 같은 암호 화폐 네트워크의 노드는 전체 거래 내역의 사본을 저장하고 유지하므로 병렬 처리로 거래 속도를 높일 수 없다. 다른 상황에서 프리 라이딩 거동은 분산 노드의 제한된 정보 및/또는 계산 리소스로 인해 발생할 수 있다. 예를 들어, 분산 머신 러닝 애플리케이션에서 개별 노드는 리소스 제약 및/또는 제한된 데이터 가용성으로 인해 패턴을 불완전하게 훈련시킬 수 있다. 결과 모델은 종속 변수에 대한 예측을 주장하여 “프리 라이딩” 거동을 나타낼 수 있지만 예측은 보이지 않는 데이터로 일반화되지 않을 수 있다.
암호 화폐 구현은 계정 소유자 간의 합성 재정 리소스의 거래를 추적한다. 거래 검증 및 기록에 참여하는 컴퓨팅 노드는 관련없는 당사자가 제어할 수 있다. 암호 화폐는 주어진 개인 키를 소유한 당사자만 가능하게 생성할 수 있는 암호화 서명된 거래 요청만 수락하며, 이는 리소스를 전송할 계정의 리소스의 양이 최소값을 초과하는 경우에만 유효하다. 이러한 시스템은 거래를 불변으로 저장해야 하며, 전송된 리소스를 적절하게 설명해야 한다. 이러한 방식으로 계정 소유자는 수락된 거래로 인한 잔액을 유지하고 불법적으로 리소스를 생성하지 않기 위해 시스템에 의존할 수 있다.
암호 화폐 기술은 다른 종류의 거래를 추적하기 위해 더 널리 채택되었다. 이러한 맥락에서 이 기술을 구현하는 시스템을 분산 원장이라고 한다. 첫번째 암호 화폐인 비트 코인은 암호화로 서명된 블록에 저장된 거래에 의존하며, 여기서 셔명은 이전 거래 블록의 신원(따라서 “블록 체인”)에 암호화 방식으로 연결된다. 비트 코인은 “작업 증명” 통화이다: 체인에 새로운 블록을 추가하려는 노드는 상당한 컴퓨팅 리소스가 필요한 암호화 퍼즐을 완료해야 한다. 이 작업의 결과는 이전 블록에 연결된 그들이 공개한 거래 블록으로 암호화 방식으로 인코딩된다. 블록이 체인에 통합되지 않으면 블록 공개에 대한 리소스 투자가 손실된다. 그러나 통합되면 공개 노드와 관련된 계정이 보상을 받는다. 블록의 데이터의 무결성은 다른 노드에서 확인할 수 있기 때문에 해당 노드는 거래를 충실하게 기록해야 다른 노드에 의해 선택될 수 있는 기회를 갖게 된다. 또한 노드는 가장 긴 체인의 끝에 있는 이전 블록을 선택하는 경향이 있으며, 그러면 해당 노드가 더 긴 체인의 끝에 있고 스스로 선택될 가능성이 더 커진다. 이 2 가지 요소는 계정 소유자의 암호화 방식으로 서명된 지시문(directive)에 표현된 동작을 충실하게 반영하는 거래 블록의 선형 체인을 구축하는 것이 노드의 공통 관심사임을 함께 보장한다.
분산 원장은 비트 코인과 같이 상당 수의 노드가 시스템을 손상시키려 하는 경우에도 거래 기록의 무결성을 보장하기 위해 설계된 경우 “무허가(permissionless)”라고 한다(문헌에서 전체 시스템의 의도에 악의적인 당사자가 운영하는 부분이 존재하는 경우 기능하도록 설계된 절차는 그 중 일부가 프로세스를 방해하고 하는 당사자 간에 메시지를 전달함으로써 계획에 대해 합의에 도달하는 “비잔틴 장군 문제(Byzantine generals problem)”[LSP1982]의 이름을 따서 명명된 “비잔틴(Byzantine)” 절차로 알려져 있으며, 다음에서는 이런 의미에서 가끔 “비잔틴”을 사용할 것이다.).
무허가 시스템은 신중하게 설계된 인센티브 및 암호화 절차를 갖는 프로토콜을 제공함으로써 기능하여 작업이 취해지고 데이터가 변조되지 않았음을 보장한다. 상대방은 개별 기록 보관인을 신뢰하지 않고 거래할 수 있다. 그러나, 무허가 시스템을 높은 거래 속도로 확장하는 것은 어려웠으며 일부 중앙화된 또는 컨소시엄 권한에 의존하여 시스템을 방해할 수 있는 임의의 악의적인 노드의 능력을 완화하는 “허가된” 시스템의 도입으로 이어졌다. 그러나 허가된 시스템은 권한 제공자에 대한 참여자의 신뢰에 의존하여 분산 원장의 의도된 목적을 손상시킨다.
현재 안전하다고 알려진 모든 무허가 시스템은 진정한 분산 시스템이 아니라 복제된 변형이다. 각 노드는 주어진 제안된 거래가 유효한지 보장하기 위해 거래 기록의 사본 또는 그 상당 부분을 유지해야 하며, 각 새로운 블록은 단일 선형 체인의 조각이어야 한다.
작업 계산의 증명에 의존하는 무허가 시스템은 상당한 리소스가 필요하다. 제안된 여러 대안 거래 블록 중 하나만 다음 블록으로 선택되므로 많은 계산이 낭비된다. 후자의 문제는 “지분의 증명” 시스템에 의해 해결되며, 계산 문제의 해결에 투자하는 대신 거래를 제안하는 노드는 그것이 결함이 있는 블록을 제안한다면 손실될 수 있는 재정 리소스에 상당한 지분을 가짐을 확인해야 한다. 시스템이 거래를 병렬로 처리 및/또는 저장할 수 없다는 이전 문제는 심각하다. 이는 시스템의 거래 속도를 제한하며 많은 실제 애플리케이션의 요구 사항에 맞게 확장하기 매우 어렵다. “샤드(shard)” 또는 “사이드 체인”을 포함하는 몇 가지 솔루션이 제안되었다. 그러나, 이러한 솔루션은 부적절하다. 이는 거래 내역을 부분으로 나누는 동시에 다른 측면에서는 블록 체인의 선형 특성을 유지하려고 시도하는 것을 포함한다. 부분이 너무 작으면 커뮤니티 합의의 보호를 누리지 못한다. 그들이 작지 않다면 그들의 도입은 많은 도움이 되지 않는다. 또한 샤딩된 시스템은 서로 다른 샤드에 있는 계정 간의 거래도 처리해야 한다.
분산 저장 시스템은 분산 문서 저장소와 같은 다른 분산 저장 시스템뿐만 아니라 분산 객체 및/또는 관련 데이터베이스를 포함한다(다음에서, “기록”은 분산 저장 시스템이 저장할 수 있는 모든 것이다). 분산 저장 시스템은 기록 및/또는 다른 데이터에 대한 변경을 안정적으로 저장, 검색 및 추적하는 것을 목표로 한다. 분산 저장 시스템은 일반적으로 분산 원장에서 예상되는 거래보다 더 일반적인 성격의 거래를 처리할 수 있다: 거래는 기록의 생성, 업데이트 및/또는 삭제를 포함하여 시스템의 상태에 대한 동시 변경의 세트로 구성될 수 있다.
분산 저장 시스템의 시스템 상태 일관성의 개념은 분산 원장 보다 분산 데이터베이스에 대해 또한 엄격히 더 일반적이다. 분산 원장의 경우, 두 거래가 둘 다 주어진 계정에서 리소스를 전송하면 충돌할 수 있으므로 계정이 최소값 미만으로 남는다. 다시 말하면, 거래는 특정 계정 수준을 전제하고, 하나가 처리될 때 다른 것의 전제를 위반하는 경우 충돌할 수 있다.
분산 저장 시스템에서 거래 중 하나에 의해 도입된 변경이 다른 거래가 어떤 측면에서든 손상을 입히는 시스템의 상태를 전제로 하는 경우 두 거래가 충돌할 수 있다. 예를 들어, 한 거래는 두 기록의 관계를 기록하고 다른 거래는 기록 중 하나를 삭제할 수 있다. 거래 충돌은 일반적으로 서로에 대해 거래를 오더링(ordering)함으로써 해결된다. 후속 거래는 이전 거래가 상점을 떠난 상태에서 작동해야 하며; 전제가 해당 상태와 충돌하는 경우 후속 거래는 거부된다.
그러나 분산 시스템에서 거래를 오더링하는 것은 본질적으로 비용이 많이 들며, 이는 참여 노드가 자체 시간 지연과 불확실성을 유발하는 불완전한 네트워크에 걸친 결정을 조정해야 하기 때문이다. 악성 노드의 도입은 어려움을 가중시킨다.
분산 저장 시스템은 최근까지 악성 노드가 존재하는 경우 안정적으로 기능하도록 설계되지 않았다. 그러나, 추가 분산 컴퓨팅 노드를 추가하여 거래 속도를 확장하는 이러한 시스템의 능력이 광범위하게 조사되었다. 특히, 악의적이지 않은 노드 장애와 조각으로의 시스템 분할을 초래하는 네트워크 장애가 연구되었다.
이러한 조사의 하나의 결과는 소위 “CAP 정리”이다. 분산 저장 시스템은 거래 일관성, 가용성(새로운 거래에 대한 커밋(commit) 능력) 및 파티션 허용 오차를 동시에 충족시키지 못할 수 있다. 분산 저장에 대한 최근 연구는 CAP 정리 및 관련 작업에 의해 부과된 제약을 인식하면서 거래 속도를 확장하고자 했다. 예를 들어, 인과적으로 일관된 데이터베이스는 기록에 대한 작업이 충돌할 수 있는 세분화된 분석을 도입하고, 이러한 제약 조건 하에서 충돌하는 거래의 오더링만 요구하는 시스템을 제안하면서 상호 오더를 결정하지 않고 인과 관계가 없는 거래가 기록되는 것을 허용한다.
분산 원장은 분산 저장 시스템의 한 유형임이 분명하다. 분산 원장 설계는 처음에 모든 거리를 체인으로 선형화하여 충돌을 처리했다. 사이드 체인 또는 샤드와 같은 변형은 서브 체인 내의 거래를 선형화하고 서브 체인 경계 간의 거래를 위한 추가 체인 간 해결 메커니즘(inter-chain resolution mechanism)을 제공한다. 다른 변경이 제안되었지만 지금까지 악성 노드의 상당 부분에서도 시스템이 안정적으로 기능해야 한다는 전체 요구 사항을 유지하면서 확장할 수 없었다. 실제로, 허가된 분산 원장은 후자의 목표를 완전히 지원하지 않는다.
분산 저장 확장의 발전으로 인해 거래 간의 상호 작용 또는 시스템의 장애 모드를 분석하여 관련 노드의 수를 최소화하고 해당 노드 사이의 메시지 양과 복잡성을 최소화하는 경우가 많다. 악성 노드의 잠재적인 존재는 더 많은 노드를 포함해야 하며, 비잔틴이 아닌 설정(non-Byzantine setting)에서 사용될 수 있는 많은 계획을 방해한다.
일부 실시예는 [US6463532B1, KG2009]에 예시된 것과 같은 분산 합의 및/또는 서명 프로토콜과 같은 다양한 암호화 프로토콜을 사용할 수 있다.
일부 양태가 리소스 할당 시스템의 컴퓨팅 장치와 관련된다. 컴퓨팅 장치는 적어도 하나의 프로세서 및 적어도 하나의 프로세서에 의해 실행될 때 적어도 부분적으로 리소스 할당 시스템에 기록된 거래 내역에서 확률적으로 하나 이상의 이전 거래를 선택하는 단계; 하나 이상의 이전 거래가 유효한지 결정하는 단계; 및 제안된 거래가 유효한지 손상되었는지 결정하는 단계로서, 적어도 하나의 이전 거래가 유효하지 않다고 결정되거나 제안된 거래가 유효하지 않다고 결정되는 경우 제안된 거래가 손상된 것으로 결정되는, 결정하는 단계에 의해 제안된 거래가 유효한지 또는 리소스의 부족으로 손상되는지 결정하기 위해 적어도 하나의 프로세서를 프로그래밍하는, 그 상에 인코딩된 명령을 갖는 적어도 하나의 비 일시적 컴퓨터 판독 가능 저장 매체를 포함한다.
일부 실시예에서, 제안된 거래가 손상되지 않았다는 결정 시 컴퓨팅 장치는 제안된 거래가 수락되었음을 나타내기 위해 제안된 거래를 리소스 할당 시스템에 기록하도록 추가로 프로그래밍된다.
일부 실시예에서, 컴퓨팅 장치의 저장 매체는 리소스 할당 시스템에서 거래 기록을 갖는 분산 원장의 적어도 일부를 추가로 인코딩한다.
일부 실시예에서, 컴퓨팅 장치에서는, 하나 이상의 이전 거래 각각이 하나 이상의 소스 계정 각각으로부터의 거래량, 하나 이상의 소스 계정 및 소스 계정의 잔액과 연관되며,
하나 이상의 이전 거래가 유효한지 결정하는 단계는, 각 이전 거래에 대해, 각 소스 계정에 대해, 소스 계정의 잔액이 상기 소스 계정에 대한 거래량의 나가는 이체(outgoing transfer)를 지원하기에 충분했는지를 확인하는 단계를 포함한다.
일부 실시예에서, 컴퓨팅 장치와 관련된 리소스 할당 시스템에서, 리소스는 제안된 거래에서 사용되는 선택된 유형의 리소스이고, 제안된 거래는 부분적으로 선택된 유형의 리소스의 양을 하나 이상의 소스 계정의 밖으로의 전송을 포함하며; 그리고 하나 이상의 이전 거래는 하나 이상의 소스 계정으로부터 추적 가능한 복수의 이전 거래로부터 선택된다.
일부 실시예에서, 컴퓨팅 장치와 관련된 리소스 할당 시스템에서, 리소스는 제안된 거래에서 사용되는 선택된 유형의 리소스이고, 제안된 거래는 부분적으로 선택된 유형의 리소스의 양을 하나 이상의 소스 계정의 밖으로의 전송을 포함하며; 그리고 하나 이상의 소스 계정으로부터 추적 가능한 리소스 할당 시스템에 기록된 거래 내역으로부터의 제2 거래는 선택된 유형의 리소스의 제2 양을 소스 계정으로 전송한다.
일부 실시예에서, 컴퓨팅 장치와 관련된 리소스 할당 시스템에서, 리소스는 제안된 거래에서 사용되는 선택된 유형의 리소스이고, 제안된 거래는 부분적으로 선택된 유형의 리소스의 제1 양을 하나 이상의 제1 소스 계정의 밖으로의 전송을 포함하며; 그리고 하나 이상의 제1 소스 계정으로부터 추적 가능한 이전 거래는 하나 이상의 제2 소스 계정으로부터 제2 양을 전송한 제2 거래 및 제2 거래 이전에 선택된 유형의 리소스의 제3 양을 제2 소스 계정으로 전송한 제3 거래를 포함한다.
일부 실시예에서, 컴퓨팅 장치와 관련된 리소스 할당 시스템에서, 리소스는 제안된 거래에서 사용되는 선택된 유형의 리소스이고, 제안된 거래는 부분적으로 선택된 유형의 리소스의 양을 하나 이상의 소스 계정의 밖으로의 전송을 포함하며; 하나 이상의 이전 거래는 하나 이상의 소스 계정으로부터 추적 가능한 복수의 이전 거래로부터 선택된다; 또한 하나 이상의 이전 거래의 확률적 선택은 선택을 위해 고려된 하나 이상의 이전 거래의 총량에 대한 각각의 이전 거래의 양에 기초한 각각의 확률을 하나 이상의 이전 거래 각각과 연관시킴으로써 수행된다.
일부 실시예에서, 컴퓨팅 장치와 관련된 리소스 할당 시스템에서, 리소스는 제안된 거래에서 사용되는 선택된 유형의 리소스이고, 제안된 거래는 부분적으로 선택된 유형의 리소스의 양을 하나 이상의 소스 계정의 밖으로의 전송을 포함하며; 그리고 하나 이상의 이전 고래는 하나 이상의 소스 계정으로부터 추적 가능한 복수의 이전 거래로부터 선택된다; 또한, 하나 이상의 이전 거래의 확률적 선택은 타겟 계정으로 전송된 하나 이상의 이전 거래의 총량에 대한 타겟 계정으로 전송된 이전 거래의 양에 기초한 각각의 확률을 하나 이상의 이전 거래 각각과 연관시킴으로써 수행된다.
일부 실시예에서, 컴퓨팅 장치와 관련된 리소스 할당 시스템에서, 리소스는 제안된 거래에서 사용되는 선택된 유형의 리소스이고, 제안된 거래는 부분적으로 선택된 유형의 리소스의 양을 하나 이상의 소스 계정의 밖으로의 전송을 포함하며; 그리고 하나 이상의 이전 거래는 하나 이상의 소스 계정으로부터 추적 가능한 복수의 이전 거래로부터 선택된다; 또한, 하나 이상의 이전 거래의 선택에 의한 총량의 확인은 확인을 위한 리소스 버짓(resource budget)을 기준으로 하고, 리소스 버짓은 제안된 거래에서 전송될 선택된 유형의 리소스의 양에 기초하여 결정된다.
일부 실시예에서, 추가적으로, 리소스 버짓은 복수의 리소스 유닛을 포함하고, 각각의 리소스 유닛은 하나 이상의 이전 거래 중 하나의 유효성을 확인하는데 사용되는 리소스의 양에 대응한다.
일부 실시예에서, 추가적으로, 하나 이상의 이전 거래 중 하나의 유효성을 확인하기 위해 사용되는 리소스의 양은 계산 작업(computational effort)의 양에 기초한 양을 포함한다.
일부 실시예에서, 추가적으로, 계산 작업은 리소스 할당 시스템에서 노드 사이에 전송된 메시지의 수에 기초하여 측정된다.
일부 실시예에서, 컴퓨팅 장치와 관련된 리소스 할당 시스템에서, 리소스는 제안된 거래에서 사용되는 선택된 유형의 리소스이고, 제안된 거래는 부분적으로 선택된 유형의 리소스의 양을 하나 이상의 소스 계정의 밖으로의 전송을 포함하며; 그리고 하나 이상의 이전 거래는 하나 이상의 소스 계정으로부터 추적 가능한 복수의 이전 거래로부터 선택된다; 또한, 하나 이상의 이전 거래의 선택에 의한 총량의 확인은 확인을 위한 리소스 초기 버짓에 기초하며, 그 양은 제안된 거래에서 전송될 선택된 유형의 리소스의 양에 기초하여 결정되지만 발견된 유효하지 않은 거래의 수, 발견된 유효하지 않은 거래의 총량 및/또는 제안된 거래에 의해 전송된 양과 유효하지 않은 거래에 대해 추적 가능한 총량을 할인한 후 사용 가능한 양 사이의 마진을 기준으로 조정된다.
일부 실시예에서, 컴퓨팅 장치의 적어도 하나의 프로세서는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드로 구성될 수 있으며, 리소스 할당 시스템의 거래 내역은 복수의 계정의 복수의 거래 내역 복제본에 기록될 수 있으며; 제안된 거래는 적어도 하나의 소스 계정의 밖으로 전송하는 것을 포함하며; 소스 계정 복제 노드는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드로부터의 하나 이상의 컴퓨팅 노드를 구성하며, 이는 적어도 하나의 소스 계정의 거래 내역 복제본을 유지하기 위한 책임이 있으며; 소스 계정 복제 노드는 또한 하나 이상의 선택된 이전 거래 중 일부를 독립적으로 선택하고 하나 이상의 선택된 이전 거래의 소스 계정을 유지하기 위한 책임이 있는 하나 이상의 컴퓨팅 노드를 쿼리(query)함으로써 하나 이상의 선택된 이전 거래의 소스 계정으로부터 데이터를 얻도록 프로그래밍되며; 소스 계정 복제 노드 중 적어도 하나는 컴퓨팅 노드에 의해 선택된 하나 이상의 이전 거래가 유효한지 여부를 독립적으로 결정하며; 제안된 거래가 손상되었는지 결정하는 단계는 소스 계정 복제 노드의 쿼럼을 형성하는 단계를 포함하며, 여기서 쿼럼의 공동 결과는 제안된 거래의 손상 여부를 결정하는데 사용된다.
일부 실시예에서, 추가적으로, 쿼럼은 소스 계정 복제 노드의 쿼럼을 포함하며; 적어도 하나의 쿼럼 노드는 제안된 거래에 대한 쿼럼의 합의를 거래 로그에 기억하도록(memorialize) 더 프로그래밍된다.
일부 실시예에서, 추가적으로, 적어도 하나의 프로세서는 복수의 로그 노드를 추가로 포함하며; 쿼럼의 각 노드는 쿼럼의 컴퓨팅 노드로부터 로그를 수집하기 위한 책임이 있는 적어도 하나의 관련 로그 노드를 갖는다.
일부 실시예에서, 추가적으로, 쿼럼은 제1 쿼럼을 포함하고, 적어도 하나의 관련 로그 노드는 복수의 독립적인 로그 노드를 포함하고, 제2 쿼럼은 제2 쿼럼이 거래 기록을 수신했다는 합의를 형성하고 합의를 형성하는 것에 응답하여 거래 기록이 거래 로그에 기록되도록 하며; 적어도 하나의 소스 계정의 거래 내역 복제본을 유지하기 위한 책임이 있는 하나 이상의 컴퓨팅 노드는 각 멤버에 대한 로그 노드가 거래 기록을 기록하기 위해 합의를 이룬 대응하는 쿼럼을 갖는 제3 쿼럼의 각 멤버로부터 인증을 수신할 때만 제안된 거래에 대한 합의를 기록하는 제3 쿼럼을 포함한다.
일부 실시예에서, 추가적으로, 그러나 잠재적으로 마지막 언급된 실시예와 독립적으로, 적어도 하나의 관련 로그 노드는 적어도 하나의 소스 계정의 거래 내역에 대한 쿼리에 응답하도록 추가로 프로그래밍되고, 소스 계정을 유지하기 위한 책임이 있는 하나 이상의 컴퓨팅 노드를 쿼리하는 것은 소스 계정 노드 또는 관련 로그 노드를 쿼리하는 것을 의미한다.
일부 실시예에서, 컴퓨팅 장치의 적어도 하나의 프로세서는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드로 구성될 수 있으며, 리소스 할당 시스템의 거래 내역은 복수의 계정의 복수의 거래 내역 복제본에 기록될 수 있으며; 제안된 거래는 적어도 하나의 소스 계정 밖으로 전송하는 것을 포함하며; 소스 계정 복제 노드는 적어도 하나의 소스 계정의 거래 내역 복제본을 유지하기 위한 책임이 있는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드로부터의 하나 이상의 컴퓨팅 노드를 구성하며; 소스 계정 복제 노드는 하나 이상의 선택된 이전 거래의 일부를 독립적으로 선택하고 하나 이상의 선택된 이전 거래의 소스 계정을 유지하기 위한 책임이 있는 하나 이상의 컴퓨팅 노드의 쿼리에 의해 하나 이상의 선택된 이전의 거래의 소스 계정으로부터의 데이터를 얻도록 추가로 프로그래밍되며; 소스 계정 복제 노드 중 적어도 하나는 컴퓨팅 노드에 의해 선택된 하나 이상의 이전 거래가 유효한지 여부를 독립적으로 결정하며; 제안된 거래의 손상 여부를 결정하는 단계는 소스 계정 복제 노드의 쿼럼을 형성하는 단계를 포함하며, 여기서 쿼럼의 공동 결과는 제안된 거래의 손상 여부를 결정하는데 사용된다; 또한, 적어도 하나의 프로세서는 로그를 수집하기 위한 하나 이상의 노드를 포함하며; 제안된 거래는 리소스를 적어도 하나의 타겟 계정에 전송하는 거래를 포함하며; 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 노드는 적어도 하나의 타겟 계정에 대한 책임이 있는 노드를 포함하며; 리소스 할당 시스템에 제안된 거래를 기록하는 단계는 적어도 하나의 타겟 계정에 대해 책임이 있는 노드에 의해 제안된 거래를 로그를 수집하기 위한 하나 이상의 노드에 통신하는 단계를 포함한다.
일부 실시예에서, 추가적으로, 로그를 수집하기 위한 노드는 제안된 거래 및 적어도 하나의 소스 계정의 하나 이상의 특성의 기능 및 노드의 주소 사이의 대응성에 기초하여 선택되며, 하나 이상의 특성은 소스 계정 ID, 거래 번호 및/또는 제안된 거래의 기간을 포함하며, 노드는 제안된 거래에 대해 저장된 정보를 검색하기 위해 어드레스에서 질의할 수 있다.
일부 실시예에서, 추가적으로, 컴퓨팅 장치의 적어도 하나의 프로세서는 하나 이상의 이전 거래의 적어도 하나의 이전 거래가 유효하지 않다고 결정하는 것에 응답하여 추가로 프로그래밍되고, 적어도 부분적으로 적어도 하나의 이전 거래를 하나 이상의 대체 거래로 대체함으로써 리소스 할당 시스템에서 거래 내역을 수정한다.
일부 실시예에서, 추가적으로, 제안된 거래가 더 이상 손상되지 않을 수 있도록 대체될 수 있는 적어도 하나의 과거 거래의 서브 세트가 있다면, 시스템은 제안된 거래의 손상에 대한 복구와 일치하는 리소스의 가능한 최소한의 양을 포함하는 적어도 하나의 과거 거래의 서브 세트를 대체하도록 추가적으로 프로그래밍된다.
일부 실시예에서, 추가적으로, 그러나 잠재적으로 마지막 언급된 실시예와 독립적으로, 유효하지 않은 것으로 결정된 적어도 하나의 이전 거래는 선택된 유형의 리소스의 제1 양을 제1 소스 계정의 밖으로의 전송을 포함하며; 적어도 하나의 이전 거래는 제1 양의 전송을 지원하기 위해 제1 소스 계정의 잔액이 제2 양만큼 부족하다고 결정하는 것에 응답하여 유효하지 않은 것으로 결정되며; 적어도 하나의 이전 거래를 하나 이상의 대체 거래로 대체하는 것은 제1 소스 계정으로부터 전송된 제1 양을 제2 양만큼 감소시키고, 제2 양이 배분되는 하나 이상의 다른 소스 계정을 추가하는 것을 포함한다.
일부 실시예에서, 추가적으로, 리소스 할당 시스템은 복수의 노드에 의해 유지되며; 다른 하나 이상의 소스 계정은 제1 소스 계정에 대한 복제본으로 작동하고 유효하지 않은 것으로 결정된 적어도 하나의 이전 거래를 수락한 노드와 관련된 적어도 하나의 소스 계정을 포함한다.
일부 실시예에서, 추가적으로, 그러나 잠재적으로 마지막에 언급된 실시예의 가능성과 독립적으로, 리소스 할당 시스템은 복수의 노드에 의해 유지되며; 하나 이상의 다른 소스 계정은 유효하지 않은 것으로 결정된 적어도 하나의 이전 거래를 처리하고 하나 이상의 다른 소스 계정의 잔액에 의해 지원되는 최대량을 구성하는 제2 양의 일부인 제3 양에 대해 총괄적으로 책임이 있는 노드와 관련된 하나 이상의 소스 계정을 포함하며; 제2 양과 제3 양의 차이는, 적어도 하나의 이전 거래의 하나 이상의 타겟 계정 및/또는 제1 소스 계정으로부터의 후속 거래의 하나 이상의 타겟 계정 사이에 분배되고 합계가 그로부터 제거되며; 그리고 리소스 할당 시스템은 적어도 하나의 이전 거래를 복구한 결과 다른 이전 거래가 유효하지 않다는 결정에 응답하여 다른 이전 거래를 복구하도록 추가로 프로그래밍된다.
일부 실시예에서, 추가적으로, 그러나 잠재적으로 실시예에 대한 마지막 2 개의 언급된 가능성과 독립적으로, 리소스 할당 시스템은 노드와 관련된 계정이 있도록 추가로 프로그래밍되며; 서로의 계정을 상호적으로 관리하는 노드는 관리하는 다른 노드의 계정이 최소량의 리소스를 유지하는 것을 요구하도록 프로그래밍된다.
일부 실시예에서, 추가적으로, 그러나 잠재적으로 실시예에 대한 마지막 3 개의 언급된 가능성과 독립적으로, 거래 내역은 복수의 계정의 거래 내역 복제본을 포함하며; 적어도 하나의 프로세서는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드를 포함하며; 제1 소스 계정 복제 노드는 적어도 하나의 소스 계정의 거래 내역 복제본을 유지하기 위한 책임이 있는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드로부터의 하나 이상의 컴퓨팅 노드를 구성하며; 하나 이상의 다른 소스 계정은 유효하지 않은 것으로 결정된 적어도 하나의 이전 거래가 수락된 제1 소스 계정 복제 노드와 관련된 제2 소스 계정을 포함하며; 제2 양은 제2 소스 계정의 잔액에 의해 지원되는 제2 양 이하의 총량인 커버된 양(covered amount)과 제2 양에서 커버된 양이 공제된 후의 나머지인 잔여량으로 나뉘며; 제2 소스 계정 복제 노드는 제2 소스 계정의 거래 내역 복제본을 유지하기 위한 책임이 있는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드로부터의 하나 이상의 컴퓨팅 노드를 구성하며; 제3 소스 계정은 제2 소스 계정 복제 노드와 관련된 계정을 포함하며; 리소스 할당 시스템은 잔여량이 제3 소스 계정에 배분되도록 추가로 프로그래밍된다.
일부 실시예에서, 추가적으로, 제2 소스 계정 복제 노드는 체인된 복제 노드(chained replica node)의 제1 레벨을 포함하며; 1보다 큰 레벨의 체인된 복제 노드는 이전 레벨의 체인된 복제 노드의 계정 복제본을 유지하기 위한 책임이 있는 노드를 구성하며; 시스템은 주어진 레벨의 체인된 복제 노드의 계정에 이전 레벨에서 커버되지 않은 잔여량을 배분하도록 추가로 프로그래밍된다.
일부 실시예에서, 추가적으로, 실시예에 대한 마지막 2 개의 언급된 가능성과 독립적으로, 제3 계정 각각에 배분된 잔여량의 일부는 계정에서 이용 가능한 최대량 및 고정된 양 중 더 작은 것에 의해 제한된다.
일부 실시예에서, 추가적으로, 그러나 잠재적으로 마지막 3 개의 언급된 실시예의 가능성과 독립적으로, 계정 내역 복제본을 관리하는 노드는 제1 복제 노드를 포함하며; 제1 복제 노드의 계정은 제1 복제 노드 계정을 포함하며; 제1 복제 노드 계정의 계정 내역 복제본을 관리하는 노드는 제2 복제 노드를 포함하며; 리소스 할당 시스템은 제1 복제 노드가, 제1 복제 노드가 내역을 관리하는 계정 상에 거래를 처리하기 위한 제2 복제 노드로부터 주기적으로 허가를 요청하고 허가가 부여될 때까지 추가 거래를 처리하지 않을 수 있도록 추가로 프로그래밍된다.
일부 실시예에서, 컴퓨팅 장치는 주기적으로 허가를 요청하는 것이 리소스의 특정 총량의 최대량까지 전송하는 거래를 처리하기 위한 허가를 요청하는 것을 포함하도록 추가로 프로그래밍된다.
일부 실시예에서, 추가적으로, 그러나 잠재적으로 마지막에 언급된 실시예의 가능성과 독립적으로, 제2 복제 노드에 의해 부여된 허가는 거래를 처리하기 위한 하나 이상의 인증 토큰을 구성하며; 컴퓨팅 장치는 수락된 거래의 기록의 일부로서 인증 토큰에 대한 참조(reference)를 기록하도록 추가로 프로그래밍된다.
일부 실시예에서, 추가적으로, 그러나 잠재적으로 실시예에 대한 마지막 2 개의 언급된 가능성과 독립적으로, 제2 소스 계정 복제 노드는 체인된 복제 노드의 제1 레벨을 포함하며; 1보다 큰 레벨의 체인된 복제 노드는 이전 레벨의 체인된 복제 노드의 계정 복제본을 유지하기 위한 책임이 있는 노드를 구성하며; 시스템은 더 낮은 레벨에 대한 허가를 부여하기 위해 이전 레벨의 체인된 복제 노드가 후속 레벨의 노드에 주기적으로 허가를 요청하도록 일정 레벨까지 추가로 프로그래밍된다.
일부 실시예에서, 추가적으로, 제1 레벨에서 요청된 허가는 리소스의 특정 총량까지 전송하는 거래를 처리하기 위한 허가를 구성하며 후속 레벨에서의 허가는 리소스의 특정 총량까지 전송하는 거래를 승인하는 다음 이전 레벨에 허가를 부여하기 위한 허가를 구성한다.
일부 실시예에서, 추가적으로, 그러나 잠재적으로 마지막 4 개의 실시예에 대해 언급된 가능성과 독립적으로, 거래를 처리하기 위한 허가는 리소스 할당 시스템에 의해 관리되는 리소스의 유형으로서 기능한다.
일부 실시예에서, 추가적으로, 그러나 잠재적으로 마지막 5 개의 실시예에 대해 언급된 가능성과 독립적으로, 거래를 처리하기 위한 허가는 리소스 할당 시스템에 의해 관리되는 리소스의 유형을 구성한다.
일부 실시예에서, 컴퓨팅 장치의 하나 이상의 프로세서의 프로세서는 제1항의 리소스 할당 시스템의 절차를 따르지만 이 프로세스에 의해 검색된 정보를 사용하여 제안된 거래 중 임의의 것이 손상되었는지 여부를 결정함으로써 여러 제안된 거래 중 임의의 것이 손상되었는지 여부를 결정하도록 프로그래밍된다.
일부 실시예에서, 추가적으로, 여러 제안된 거래는 동일한 타겟 계정으로 또는 동일한 소스 계정으로부터의 거래를 포함하며, 소스 내역의 랜덤 조사로부터 얻는 정보는 거래에 의해 총괄적으로 전송된 것으로 간주되는 선택된 유형의 리소스의 총량을 조정하는데 사용된다.
일부 실시예에서, 컴퓨팅 장치와 관련된 리소스 할당 시스템에서, 거래는 데이터 기록과 관련된 일부 리소스를 추적하거나 하나 이상의 소스 계정에서 데이터 기록에 기인할 수 있는 리소스의 양에 각각 대응하는 하나 이상의 계정 및 데이터 기록의 상태에 의해 계산될 수 있는 하나 이상의 소스 계정과 독립적으로 또는 개별적으로 관련된 하나 이상의 소스 데이터 기록과 연관되며, 거래가 유용한지 결정하는 것은 각 소스 계정에 대해 소스 계정에 의해 추적된 리소스의 양은 추적된 리소스의 양이 수정된 데이터 객체 대한 작업을 지원하기에 충분한지 확인하는 것을 포함한다.
일부 실시예에서, 추가적으로, 컴퓨팅 장치의 적어도 하나의 프로세서 중 하나는 냅색 문제(knapsack problem)에 대한 근사 알고리즘으로 대체할 서브 세트를 찾도록 프로그래밍된다.
일부 실시예에서, 컴퓨팅 장치는: 적어도 하나의 프로세서; 및 적어도 하나의 프로세서에 의해 실행될 때 적어도 부분적으로 리소스 할당 시스템에 기록된 거래 내역에서 확률적으로 하나 이상의 이전 거래를 선택하는 단계; 하나 이상의 이전 거래가 유효한지 결정하는 단계에 의해 이전 거래가 유효한지 결정하기 위해 적어도 하나의 프로세서를 프로그래밍하는, 그 상에 인코딩된 명령을 갖는 적어도 하나의 비 일시적 컴퓨터 판독 가능 저장 매체를 포함한다.
일부 실시예에서, 추가적으로, 컴퓨팅 장치는 프로그램을 주기적으로 실행하도록 프로그래밍된다.
일부 실시예에서, 추가적으로, 그러나 잠재적으로 실시예에 대해 마지막으로 언급된 가능성과 독립적으로, 컴퓨팅 장치는 프로그램이 최근 검증되지 않은 검증 계정을 선택하도록 프로그래밍된다.
일부 실시예에서, 리소스 할당 시스템의 컴퓨팅 장치로서, 컴퓨팅 장치는: 적어도 하나의 프로세서; 및 적어도 하나의 프로세서에 의해 실행될 때 적어도 부분적으로 이전 수락에 대한 암호화 인증 및 거래의 체인에서의 위치를 포함하는 쿼리와 관련된 거래 기록을 반환하여 거래 내역에 대한 쿼리에 응답하는 단계에 의해 제안된 거래가 리소스의 부족에 의해 손상 되었는지의 결정을 허락하도록 적어도 하나의 프로세서를 프로그래밍하는, 그 상에 인코딩된 명령을 갖는 적어도 하나의 비 일시적 컴퓨터 판독 가능 저장 매체를 포함한다.
일부 실시예에서, 본 발명은 위에 요약된 실시예 중 어느 하나에서 컴퓨팅 장치에 의해 수행되는 방법을 포함한다.
전술한 내용은 첨부된 청구 범위에 의해 정의된 본 발명의 비 제한적인 요약이다.
첨부된 도면은 일정한 비율로 그려지지 않았다. 도면에서, 다양한 도면에 도시된 각각의 동일하건 거의 동일한 구성 요소는 유사한 번호로 표시된다. 명확성을 위해, 모든 구성요소는 모든 도면에서 레이블이 지정되지는 않는다. 도면에서:
도 1은 일부 실시예에 따른 제안된 거래, 계정 및 이전 거래 사이의 관계를 나타내는 다이어그램이다.
도 2는 일부 실시예에 따른 시스템을 도시하며 및 계정 내역 복제본의 저장을 도시한다.
도 3은 일부 실시예에 따라 시스템을 도시하며 복제 노드 및 로그 노드 사이의 관계를 도시한다.
도 4는 일부 실시예에 따라 유효하지 않은 거래의 복구를 보여주는 다이어그램을 도시한다.
도 5는 일부 실시예에 따른 유효하지 않은 거래에 대한 책임이 있는 체인을 보여주는 다이어그램을 도시한다.
도 6은 일부 실시예에 따른 시스템의 블록 다이어그램을 도시한다.
1. 분산 원장 및 리소스 할당 시스템
일부 실시예에서, 리소스 할당 시스템(“RAS”)은 리소스의 일부 유형의 일부 또는 전부를 이동, 생성, 파괴 또는 변형하라는 복수 당사자의 오더에 응답하면서 일부 가치 있는 리소스의 추적을 유지할 수 있다. 일부 실시예에서, RAS는 하나 이상의 유형의 리소스의 추적을 유지하기 위해 분산 원장을 사용할 수 있다. 그러나, 본 개시의 양태는 재정 리소스의 추적을 유지하기 위해 배경기술에서 논의된 바와 같이 분산 원장을 사용하는 것으로 제한되지 않고, 분산 시스템으로 제한되지 않는다는 것을 이해해야 한다. 발명가는 리소스 할당 시스템이 재정 리소스에 제한되지 않으므로 다른 유형의 리소스를 어드레스할 수 있음을 인식하고 이해했다. 하나 이상의 리소스의 유형이 추적될 수 있다. 예를 들어, 주어진 기간에 전력의 공급 및/또는 소비는 생산자와 소비자 사이의 적절한 전기 흐름의 할당을 보장할 수 있는 시스템에 의해 추적될 수 있다. 대안적으로 또는 추가적으로, 예를 들어, 컴퓨팅, 저장 또는 메시징 용량과 같은 컴퓨터 네트워크의 하나 이상의 용량이 추적될 수 있고, 그러한 리소스를 소비하는 컴퓨팅 작업 사이에 할당될 수 있다. 리소스 할당 시스템의 일부 실시예는 예를 들어 그 동작이 전체 시스템의 기능을 협력하거나 방해하도록 판단됨에 따라 노드 또는 시스템 사용자에 대한 보상 또는 페널티 시스템과 같은 일부 대규모 컴퓨팅 시스템의 기능을 측정 및/또는 개선하기 위해 생성된 리소스의 유형을 추적할 수 있다. 리소스 할당 시스템의 일부 실시예는 일부 대규모 시스템과 관련된 비용 또는 가치 기능으로서 암시적으로 추적할 수 있다: 예를 들어, 시스템에 의해 사용되는 그리고/또는 시스템의 일부에 의해 사용되는/기여 가능한 노드 또는 다른 리소스의 수.
본 발명의 일부 실시예는 분산 원장 또는 리소스 할당 시스템에 대한 최종 일관성의 분산 저장 개념[BG2013]을 적용하는 동시에 그 유용성을 향상시키기 위해 리소스 할당의 특화된 특성을 활용하는 것으로 불 수 있다.
일부 실시예에서, 리소스는 계정 사이에 이동될 수 있다. 계정은 예를 들어 네트워크 위치, 암호화 키 또는 계정 식별을 위한 다른 메커니즘에 기초하여 임의의 적절한 방식으로 식별될 수 있다. 예를 들어, 리소스의 양은 직접 표현될 수 있다(예를 들어, 숫자 값을 사용하거나 다른 유형의 경우 숫자 값에 대한 유형 식별자의 관련 맵). 추가적으로 또는 대안적으로, 리소스의 양은 간접적으로 표현될 수 있다(예를 들어, 존재하는 리소스의 양의 확률에 기초하거나, 리소스의 양의 존재 또는 부재의 증거에 기초). 본 개시의 양태는 양을 수치적으로 나타내는 것으로 제한되지 않는다는 것을 이해해야 한다. 모든 시스템은 리소스의 특정 표현과는 독립적인 리소스 할당 시스템이며, 본 명세서에서는 양이라고 부르지만 다음과 같이 결합되거나 비교될 수 있는 한 임의의 정보를 포함할 수 있다: (i) 제1 양이 제2 양 이상으로 계산될 수 있고 제2 양이 제3 양 이상으로 계산될 수 있는 경우 제1 양은 제3 양 이상으로 계산될 수 있으며; 그리고 (ii) 제1 양이 제2 양 이상으로 계산될 수 있고, 제3 양이 제4 양 이상으로 계산될 수 있는 경우 제1 및 제3 양의 합이 제2 및 제4 양의 합 이상으로 계산될 수 있음.
예를 들어, 리소스 할당 시스템은 불완전하게 전송할 수 있는 리소스를 사용하기 위한 허가를 기록할 수 있다. 예를 들어, 피어 투 피어 카 쉐어링 서비스는 사용자가 차량을 사용할 수 있는 기간 동안 차량을 유지해야 할 사용자의 책임을 예견할 수 있다. 그들이 다른 사용자에게 시간의 일부 또는 전부를 전송하는 경우, 전송됨에 따라 리소스의 상태에 대해 약간의 추가 불확실성이 발생할 수 있다. 따라서 사용하기 위한 허가의 표현에는 이전의 보유자의 이름 문자열(string of name)과 함께 기본 리소스에 대한 식별자가 포함되며 이전에 보유한 허가의 세트를 새로 전송된 허가의 세트와 결합하는 작업은 값의 약간의 저하를 고려하는 것을 포함할 수 있다. 비교 및 조합은 여전히 위에 표현된 규정(stipulation)과 일치한다.
RAS의 일부 실시예에서, 리소스는 시스템의 다른 부분 사이에서 전송될 수 없다. 예를 들어, “계정”은 단순히 데이터 객체일 수 있으며 리소스는 객체의 크기 또는 중요도일 수 있다. 이러한 경우, 한 계정에서 다른 계정으로 리소스를 전송하지 못할 수 있다. 이러한 시스템은 거래가 리소스와 관련하여 어떤 일관성 제약을 받는 경우에도 RAS를 구현한다. 예를 들어, 객체가 중요도를 갖는 경우 객체 캐시와 같은 시스템은 객체의 총 중요도를 낮추지 않도록 거래를 제한할 수 있다. 그럼에도 불구하고, 많은 계산 시스템은 그것이 전체적으로 RAS가 아니더라도 중요한 구성 요소로 그를 포함한다. 아래 설명에서 리소스가 일부 객체 또는 시스템의 일부의 계산된 속성인 경우 “계정”은 리소스의 값을 계산할 수 있는 객체 및/또는 부분을 의미할 수 있다(리소스 값은, 저장될 수 있지만 명시적으로 저장될 필요는 없다). 이러한 경우 계정 거래 내역은 해당 객체 및/또는 부분을 수정 및/또는 포함하는 거래 내역일 수 있으며, 그로부터 명시적으로 저장되었는지 여부와 관계 없이 리소스의 값 및/또는 값의 변경이 계산될 수 있다.
본 개시의 양태는 리소스 할당이 중심 목적인 시스템뿐만 아니라 리소스 할당 또는 관례에 의해 값이 할당될 수 있는 수량 및/또는 토큰의 할당이 어떤 다른 목적의 서비스에서 책 보관 장치로 역할을 하는 시스템에도 적용된다는 것을 이해해야 한다. 예를 들어, 일부 실시예에서 시스템의 목적은 임의의 데이터의 저장 및 유지일 수 있다. 예를 들어, 데이터베이스 시스템은 특정 거래 및/또는 시스템의 특정 노드에 의해 수행되는 검증의 양을 관리하기 위해 리소스 및/또는 리소스 유사 엔티티(resource-like entity) 및/또는 측정을 사용할 수 있다.
2. RAS의 확률적 거래 검증
일부 RAS는 일관성이 없는 거동을 피하기 위해 모든 동작을 선형화한다. 일부 RAS 구현은 데이터를 샤딩(sharding)하고 샤드 내에서 그리고 샤드 간에 선형화하는 분할 및 정복 전략을 사용하여 확장성 문제를 개선하려고 시도한다. 발명자는 리소스 할당 시스템의 모든 거래를 선형화하여 일관성을 보정하면 확장성에 병목 현상이 발생할 수 있으며 샤딩이 이러한 병목 현상을 극복하는데 있어 제한적인 효과가 있음을 인식하고 이해했다. 그럼에도 불구하고, 발명자는 불일치 거래를 식별하고 제거하기 위한 메커니즘을 RAS에 제공하는 것이 바람직할 수 있음을 인식하고 이해했다(예를 들어, 거래가 계정 잔액을 선택된 임계값 아래로 감소시키는 경우). 따라서, 일부 실시예에서, 거래 사이의 부분적인 오더를 유지하고 소스 계정으로부터 이전 거래를 확인함으로써 둘 이상의 계정 사이에 리소스를 전송하는 주어진 새로운 거래가 일관성이 있는지를 부분적으로 또는 확률적으로 검증하는 기술이 제공된다. 일부 실시예에서, 검증 체크는 이전 거래의 확률적 프로브를 사용한다. RAS에서 이전(previous)의 개념은 클럭 시간(clock time)을 참조할 수 있지만 그렇게 해야할 필요는 없으며, 하지만 RAS에 포함된 하나 이상의 컴퓨팅 노드에서 동작의 효과적인 오더 측면에서 이전을 의미할 수 있음을 이해해야 된다. 주어진 작업의 오더를 알 수 없거나 지정하지 않은 경우, 이전은 오더가 알려져 있고 주어진 순서와 관련하여 순서 또는 동시성이 알려지고 지정되고 그리고/또는 가정된 임의의 다른 동작에 의해 가능하게 전이적으로(transitively) 유도된 오더의 측면에서 “따르지 않음”을 의미할 수 있다.
일부 실시예에서, 계정의 리소스의 양은 가능하면 초기 잔액에 의해 증가된 계정의 거래 내역에 기록된 계정으로/계정으로부터 적절하게 형성된(예를 들어, 암호화로 서명된) 거래의 거래 이력에 의해 결정된다. 일부 실시예에서, 특정 실시예의 규칙에 의해 결정된 바와 같이 적절하게 기록된 거래는 수락된 것으로 지칭될 수 있다. 일부 실시예에서, 유효한 거래는 소스 계정의 리소스의 양이 충분하여 임의의 소스 계정의 양이 해당 소스 계정에 대한 최소량에 속하지 않는 거래일 수 있다. 일부 실시예에서, 손상된 거래는 소스 계정의 양이 유효해야 하지만 소스 계정의 양이 의존하는 거래의 전이적 폐쇄(transitive closure)가 유효하지 않은 거래를 포함하는 거래일 수 있다.
일부 실시예에서, 제안된 거래 Tp가 주어지면, 시스템은 모든 이전 거래 중에 랜덤으로 선택할 수 있으며 해당 거래 전송 리소스가 그렇게 하기에 충분한 양의 적절한 리소스 유형을 갖는 계정을 검증할 수 있다. 그렇지 않은 경우 시스템은 불일치 상태에 있음을 발견했으며, 예를 들어 복구 및/또는 전류 및/또는 다른 거래를 보류하는 것과 같이 아래에서 설명하는 다양한 여러 작업을 수행할 수 있다. 어떤 변형을 선택하든 랜덤 선택이 균일하게 이루어지면, 시스템에 총 d 개의 이전 거래가 있을 때 주어진 이전 거래가 확률 1/d로 확인되므로, 이전 거래의 수가 계속 증가함에 따라 확실성에 접근할 확률로 제한없이 자주 확인된다. 이 특성 또는 유사한 특성은 보존되거나, 아래에서 설명하는 많은 변형에 의해 일부 조건 하에서 보존된다.
일부 실시예에서, 확인된 이전 거래는 제안된 거래와 관련될 수 있다. 도 1은 제안된 거래(120)뿐만 아니라 계정(151, 152, … 160) 간의 이전 거래(101, 102, 103, … 114)의 예의 다이어그램(100)을 도시한다. 시스템은 각 계정에 대한 로컬 거래 내역을 유지할 수 있다. 로컬 거래 내역은 계정과 관련된 모든 수신 및 발신 거래를 포함할 수 있으며, 거래는 선형적으로 정렬될(ordered) 수 있다(예를 들어, 수락된 오더에 기초함). 그러나, 일부 실시예에서, 로컬 거래 내역은 선형적이지 않을 수 있다. 오히려, 일부 실시예에서, 시스템은 발신 거래가 없는 일부 오더가 존재하여 계정의 잔액이 일부 선택된 임계값 아래로 떨어지도록 하는 경우 주어진 계정에 대한 거래의 세트를 수락할 수 있다. 예를 들어, 주어진 임계값 아래로 계정의 잔액을 별개로(in isolation) 낮추는 주어진 거래를 고려한 후 특정 기간 내에 및/또는 특정 기간을 고려하는 동안이면, 다른 거래가 2개의 거래가 함께 취해질 때 계정의 잔액이 임계값과 동일하거나 그 위로 유지되도록 존재하므로, 거래의 세트가 거래의 오더가 존재하는지와 관계없이 유효한 것으로 간주될 수 있다.
일부 실시예에서, 계정으로부터의 제안된 거래가 손상되지 않았음을 검증하기 위해 차례로 들어오고 나가는 거래의 양, 유형 및 유효성에 의존하는 명백한 계정 잔액이 주어지면, 시스템은 들어오는 거래 사이에서 확률적으로 확인한다. 예를 들어, 다이어그램(100)의 계정(151)으로부터 제안된 거래(120)를 참조하면, 시스템은 주어진 확률로 이전 거래(101 및 102) 중 하나 또는 둘 모두를 확인하기로 결정할 수 있으며, 거래(101)의 선택에 따라 컨디셔닝될 수 있으며, 어떤 거래(103, 104)를 확인할 지 선택하도록 계속 진행할 수 있으며, 결과적으로 거래(111, 112) 중 하나 또는 둘 모두를 확인할 수 있다.
일부 실시예에서, 소스 계정(Aj)과의 거래(Ti)가 주어지면, 시스템은 Ti가 제안되었을 때 Aj가 충분한 양의 리소스를 보유하고 있는지 확인할 수 있다. 예를 들어, 머의 거래 내역에서 Ti가 제안된 시점까지의 모든 수신 및 발신 거래의 잔액이 7Y를 지원하기 충분하지 않은 경우 Ti는 유효하지 않다고 고려될 수 있다(예를 들어, Ti로 인해 Aj 잔액이 선택된 임계값 아래로 떨어짐).
일부 실시예에서, 거래 전에 존재하는 것으로 간주되는 계정(Am)의 리소스 중 일부가 거래의 경로를 통해 유효하지 않는 거래(Tj)로 역추적될 수 있는 경우 소스 계정(Am)을 갖는 거래(Ti)는 손상된 것으로 고려될 수 있다.
일부 실시예에서, 시스템은 Ti 이전의 Aj 계정 내역에 기록된 모든 수신 거래로부터 랜덤으로 머의 하나 이상의 수신 거래를 선택하고 이러한 거래가 손상되었는지 여부를 확인할 수 있다. 일부 실시예에서, 이 유효성 확인은 (소스 계정(Al)을 갖는) 선택된 수신 거래(Tk)가 유효한지 여부를 확인하는 것을 포함한다. 일부 실시예에서, 이 유효성 확인은 T¾ 이전에 발생한 Al의 수신 거래가 손상되었는지 여부를 재귀적으로(recursively) 확인하는 것을 포함할 수 있다.
일부 실시예에서, 시스템은 모든 수신 거래로부터 랜덤으로 균일하게 거래를 선택할 수 있다. 이 방식으로 모든 거래가 계정의 거래의 수가 증가함에 따라 제한없이 증가하는 예상 횟수를 확인하도록 할 수 있다. 일부 실시예에서, 시스템은 덜 최근의 거래보다 최근의 거래에 더 많은 가중치를 둘 수 있다. 예를 들어, n 개의 거래가 있는 경우, 시스템은 확률로 i번째 가장 최근 거래(k>=1)를 선택할 수 있다.
Figure pct00001
여기서 합계는 1부터 n까지 범위에 있는 i 초과이다. 이러한 방식으로, 주어진 거래가 선택되는 확률의 합이 나누어지는 방법을 선택함으로써, 더 최근 거래에 더 높은 가중치를 부여하면서 시스템은 (i) 주어진 거래가 주어진 계정의 거래의 수가 증가함에 따라 제한 없이 확인되며 동시에 (ii) 주어진 거래가 주어진 횟수만큼 확인되기 전의 지연에서 계정의 총 거래 수에 따라 증가를 제한하도록 할 수 있다.
일부 실시예에서, 시스템 노드는 모든 거래 및/또는 그것이 알고 있는 모든 계정을 확률적으로 확인할 수 있다. 예를 들어, 시스템 활동이 낮은 기간 동안 새로운 거래에 대한 응답 및/또는 백그라운드에서 주어진 속도로 이러한 확인을 수행할 수 있다. 일부 실시예에서, 시스템은 거래의 크기에 의해 거래의 선택에 가중치를 둘 수 있다.
손상된 거래가 발견되면 다양한 작업이 취해질 수 있다. 일부 실시예에서, 손상된 거래는 다른 작업이 취해지는 동안 보류될 수 있다. 일부 실시예에서, 거래가 손상된 것으로 밝혀질 때 소스 계정에 대한 추가적인 랜덤 확인이 수행될 수 있다. 이러한 방식으로 리소스 없이 이송된 것으로 추정되는 양을 제거한 후 실제로 존재하는 리소스의 총량이 추정될 수 있으며, 손상 때문에 충분한 리소스가 이용 가능하지 않다고 추정되는 경우 거래는 유효하지 않다고 표시될 수 있다. 추가 작업은 이 추정 절차 중에 계산된 확률 또는 다른 수량을 기반으로 할 수 있다. 일부 실시예에서, 유효하지 않은 거래의 복구(아래에서 논의됨)는 손상이 제거되도록 할 수 있다. 일부 실시예에서, 주어진 제안된 거래의 내역에서 유효하지 않은 거래가 발견되면, 복구 및 추가 랜덤 확인이 병렬로 수행될 수 있으며, 제안된 거래가 그것이 유효하지 않다는 확실성의 임계값에 도달했을 때 진행될 수 있으며, 다른 거래에 대한 복구 또는 추가 확인에 의해 발견된 유효하지 않은 거래의 복구는 주 거래가 지워진 후에도 비동기적으로 진행될 수 있다.
3. 복제
일부 실시예에서, 계정에 대한 기록 저장 및 거래의 수락에 대한 책임은 일부 또는 모든 데이터를 복제할 수 있는 다른 컴퓨팅 노드 간에 분산될 수 있다. 다음에서, 복제본 노드는 계정 기록을 포함하는 데이터와 같은 특정 데이터의 복제본을 저장하는 노드이다. 데이터 자체의 사본은 복제본 데이터(예를 들어, 복제본 계정)로 표시될 것이다. 복제 계정 데이터와 함께 복제 노드는 단순히 복제본으로 알려져 있다. 일부 실시예에서, 각 계정은 계정에 대한 거래 내역을 유지하는 하나 이상의 복제 노드와 관련될 수 있다. 이러한 방식으로, 하나 또는 여러 개의 노드가 실패하더라도 시스템은 계속 기능할 수 있으며, 결함이 있거나 악의적인 노드의 작업을 극복할 수 있다. 주어진 컴퓨팅 노드가 가능한 많은 다른 계정에 대한 복제 노드 역할을 할 수 있다는 것을 이해해야 하며; 계정에 대한 복제 노드에 대해 말할 때, 우리는 그 역할의 노드를 해당 계정에 대한 복제 노드로 간주하지만, 다른 계정에 대한 복제 데이터를 제공하는 것 및/또는 예를 들어 로깅(logging)과 같은 다른 작업을 수행하는 것과 같은 RAS 또는 다른 시스템 내의 다른 기능을 배제하지 않는다.
거래를 수락하기 위해 복제 노드는 쿼럼이라고 하는 복제 노드의 서브 세트를 선택하는 시스템을 사용할 수 있으며, 이는 가능하지만 반드시 그의 대부분이지는 않을 수 있으며, 거래 승인 또는 거절과 같은 데이터 변경과 관련하여 결정을 내리기 위해 합의 프로토콜을 사용하여 선택된다. 문헌은 가능한 많은 합의 프로토콜(예를 들어, 비잔틴 합의 프로토콜)을 포함한다. 일부 실시예에서, 쿼럼은 거래에 서명하고 그리고/또는 하나의 거래가 이전 거래에 바로 뒤따른다는 것을 증명하기 위해 임계값 서명 또는 다른 암호화 기술을 사용할 수 있다; 예를 들어, [KG2009]에 설명된 기술을 사용할 수 있다. 이러한 방식으로, 계정의 거래 내역을 쿼리하는 임의의 노드는 피어의 쿼럼의 협력 없이 발신 거래를 생략하거나 수신 거래를 잘못 표시한 노드가 없음을 보장할 수 있다.
일부 실시예에서, 거래 수락을 위한 쿼럼에 참여하기로 동의하기 전에, 복제 노드는 독립적인 랜덤 선택을 사용하여 계정 내역을 확인할 수 있다. 이러한 방식으로, 손상된 거래를 더 쉽게 발견할 수 있다.
도 2는 6 개의 계정, 즉 계정(210, 220, 230, 240, 250 및 260)을 갖는 일부 실시예에 따른 예시적인 시스템(200)을 도시한다. 각 계정은 식별된 복제 노드에서 각각 복제본을 구비하는 5 개의 계정 복제본을 갖는다. 특히, 계정(210)은 노드(211, 212, 213, 214 및 215) 각각에 복제본을 가지며; 계정(220)은 노드(221, 222, 223, 224 및 225)에 복제본을 가지며; 계정(230)은 복제 노드(231, 232, 233, 234 및 235)에 계정 복제본을 가지며; 계정(240)은 노드(241, 242, 243, 244 및 245)에 복제본을 가지며; 계정(250)은 노드(251, 252, 253, 254 및 255)에 복제본을 가지며; 계정(260)은 노드(261, 262, 263, 264 및 265)에 계정 복제본을 갖는다. 화실표(271-287)는 계정(210)으로부터 제안된 거래에 응답하여 수행될 수 있는 하나 이상의 작업을 나타낸다. 각각 5 개의 노드를 갖는 6 개의 계정을 선택하는 것은 예시적이라는 것을 이해해야 한다; 적절한 수의 계정이 있을 수 있으며 각 계정은 적절한 수의 노드를 가질 수 있다. 계정의 거래 내역에 대한 로컬 지식이 주어진 각 노드는 다른 계정의 복제본을 제어하는 노드를 독립적으로 선택한다. 예를 들어, 노드(213)는 각각 노드(223, 234)를 갖는 계정(220, 230)으로부터 수신 거래의 상태를 검증하도록 선택될 수 있다(화살표 273 및 275 참조). 검증 체인은 계정 4 및 5로부터 거래 검증을 진행할 수 있다(화살표 279 및 287 참조).
일부 실시예에서, 검증은 후속 노드(예를 들어, 노드 223 및 234)에 의해 유지되는 계정 이력으로부터 기록을 요청하고 검색된 계정 내역 자체로부터 추가적으로 랜덤 선택을 수행하는 원래 노드(예를 들어, 213 및 계정(210)의 다른 복제 노드)에 의해 수행될 수 있다. 다른 실시예에서, 원래 노드는 계정 내역을 검색하지 않고, 예를 들어 무결성을 보장하기 위해 해시 또는 샘플을 검색할 수 있으며, 대신 하나 이상의 서브 검증 단계를 해당 내역을 저장하거나 이에 대한 직접 액세스 권한을 갖는 노드에 위임할 수 있으며, 예를 들어 노드(213)는 계정(220)의 거래 확인을 해당 계정에 대한 복제 노드에 위임한다.
일부 실시예에서, 각 계정을 제공하는 복제본의 수는 시스템의 고정된 특성일 수 있다. 다른 실시예에서, 복제본의 수는 다양할 수 있다. 예를 들어, 복제본의 수는 리소스에 대해 계산된 통계 또는 계정에서 리소스의 변경에 따라 변경되고 그리고/또는 개략적으로 비례할 수 있도록 선택되거나 조정될 수 있다. 예를 들어, 계정의 리소스의 양은, 시간에 따른 이동 평균량 및/또는 거래량의 합 및/또는 양의 시간에 따른 이동 평균 및/또는 다른 통계에 비례하거나 그리고/또는 그에 따라 변하도록 선택될 수 있다. 일부 실시예에서, 주어진 계정을 제공하는 복제본의 수는 다른 시스템 특성에 따라 달라질 수 있다. 예를 들어, 시스템은 복제 노드의 네트워크 연결성, 처리량 및/또는 복제 노드의 지연 데이터 및/또는 노드의 신뢰성 및/또는 가용성을 반영하는 다른 통계를 반영하도록 이를 조정할 수 있다.
일부 실시예에서, 쿼럼에 참여하는 복제본의 수는 상기 와 같이 합의 프로토콜의 선택과 일치한다. 다른 실시예에서, 더 작은 쿼럼은 시스템에 의해 지정된 조건에서 거래를 수락할 수 있다. 예를 들어, 복제 노드 자체가 자원을 에스크로(escrow)에 커밋하는 경우 시스템은 전체 쿼럼을 구축하지 않고 소규모 거래 및/또는 할당한 에스크로의 양보다 작은 거래를 그것이 수락하는 것을 허용할 수 있다. 예를 들어, 다른 충돌하는 거래로 인해 거래가 불가능한 것으로 판명되면 시스템은 거래의 어떤 부분이 충돌될 수 있는지를 커버하기 위해 에스크로로부터 거래를 생성할 수 있다. 이러한 방식으로 노드 운영자는 위험이 적을 때 및/또는 에스크로와 관련하여 관리할 수 있을 때 임의의 거래 수수료의 더 큰 몫을 대가로 위험을 수용하도록 선택할 수 있다.
일부 실시예에서, 쿼럼이 발신 거래를 수락한 후, 결정은 쿼럼에 참여하지 않는 하나 이상의 로그 노드(아래에 더 자세히 논의되고 도 3에 예시됨)에 의해 기록될 수 있다. 로그 노드 역할을 하는 노드는 일반적으로 노드가 시스템에서 다른 역할을 수행한다는 것을 배제하지 않는다는 것을 이해해야 한다. 일부 실시예에서, 시스템은 주어진 계정에 대한 로그 노드가 동일한 계정에 대한 복제 노드가 되는 것을 배제하는 방식으로 로그 노드를 지정할 수 있다. 일부 실시예에서, 결정 쿼럼에 참여하는 각각의 소스 계정 복제 노드에 대해 그 복제 노드의 결정을 위한 로그 노드로서 기능하도록 지정된 여러 노드가 있을 수 있다. 추가적으로 또는 대안적으로, 결정은 거래의 하나 이상의 타겟 계정에 대한 책임이 있는 하나 이상의 클라이언트 컴퓨터 및/또는 복제본에 통신될(communicate) 수 있다. 이러한 방식으로 디지털 서명은 쿼럼이 주어진 거래를 수락할 때 존재하는 이전 거래의 시퀀스가 서명의 사본을 가진 사람이 발견하지 않고는 은밀하게 변경할 수 없도록 보장할 수 있다. 이러한 방식으로, 로그 노드에 대한 이러한 서명과 함께 수락된 거래의 통신은 손상된 거래의 발견을 전복시키기 위해 발신 거래의 언급을 생략하도록 협력해야 하는 노드의 수를 보장할 수 있다.
일부 실시예에서, 로그를 수집하는 하나 이상의 노드는 동적으로 변경되지만 쉽게 계산할 수 있는 방법에 의해 식별될 수 있다. 이러한 방식으로 악의적인 공격자가 어떤 노드를 전복시킬 것인지 예측하는 것은 어려울 수 있지만, 검증자가 추후에 누락된 발신 거래를 찾기 위해 쿼리해야하는 노드를 계산하기는 쉬울 수 있다. 예를 들어, 하나 이상의 노드는 계정에 대한 공개 식별자 및 수신 거래의 수를 기반으로 합의된 해싱 기술에서 파생된 하나 이상의 번호 또는 비잔틴 합의 알고리즘에 의해 선택된 타임 스탬프 또는 논리적 뷰 번호를 기반으로 선택될 수 있다.
일부 실시예에서, 주어진 거래에 대한 로그 노드 역할을 하는 노드의 수는 시스템의 고정 특성일 수 있다. 다른 실시예에서, 로그 노드의 수는 변할 수 있다. 예를 들어, 로그 노드의 수는 거래의 크기에 기초하여 통계에 대략적으로 비례하도록 선택되거나 조정될 수 있다. 일부 실시예에서, 주어진 거래에 대한 로그 노드의 수는 다른 시스템 특성에 따라 달라질 수 있다. 예를 들어, 시스템은 네트워크 연결성, 처리량 및/또는 로그 노드의 지연 데이터 및/또는 노드의 신뢰성 및/또는 가용성을 반영하는 일부 다른 통계를 반영하도록 조정할 수 있다.
일부 실시예에서, 로그 노드가 거래 기록을 수신하는 프로토콜에 대한 변형 또는 추가가 사용될 수 있다. 일부 실시예에서, 로그 노드가 소스 계정 쿼럼에 참여하지 않더라도, 로그 노드의 쿼럼의 형성 및 소스 계정의 참여자가 로그 쿼럼에 의해 서명된 인증서의 제시가 제안된 거래에 대한 소스 계정 쿼럼의 약정을 위한 추가 조건으로 작용할 수 있다. 추가적으로 또는 대안적으로, 제안된 거래에 대한 하나 이상의 타겟 계정과 관련된 하나 이상의 노드는 거래에 대한 로그 기록을 복제본과 통신할 책임이 있을 수 있다. 이러한 방식으로, 거래의 기록을 보존할 인센티브를 갖는 계정에 대한 노드는 거래의 기록(memorialization) 및 검색 가능성을 보장할 책임이 있을 수 있다.
도 3은 일부 실시예에 따른 계정 복제 노드(310, 320, 330, 340 350 및 360)를 갖는 예시적인 시스템(300)을 도시한다. 계정 복제 노드(310)는 로그 노드(311, 312, 313, 314 및 315)를 가지며; 계정 복제 노드(320)는 로그 노드(321, 322, 323, 324 및 325)를 가지며; 계정 복제 노드(330)는 로그 노드(331, 332, 333 및 334)를 가지며; 계정 복제 노드(340)는 로그 노드(341, 342, 343, 344 및 345)를 가지며; 계정 복제 노드(350)는 로그 노드(351, 352, 353, 354, 355 및 356)를 가지며; 계정 복제 노드(360)는 로그 노드(361, 362, 363, 364 및 365)를 갖는다. 로그 노드는 각각의 계정 복제 노드에 의해 수락된 거래를 로그화(log)한다.
4. 거래 가중치
일부 실시예에서, 검증자는 거래의 동일한 가중치 이외의 것을 사용하여 검증하기 위해 계좌의 거래 내역으로부터 수신 거래를 랜덤으로 선택할 수 있다. 예를 들어, 일부 실시예에서, 수신 거래는 계정 이력에서 모든 수신 거래 밖으로 수신 거래에 의해 전송된 리소스의 양에 비례하는 확률로 검증된 발신 거래 전에 계정 이력으로부터 선택될 수 있다. 이러한 방식으로, 무효화를 유발할 가능성이 가장 높은 거래가 확인될 가능성이 가장 높다.
일부 실시예에서, 총 검증 버짓(total verification budget)은 수신 거래 사이에서 랜덤으로 분할될 수 있고 따라서 각각의 선택된 거래(예를 들어, 도 1의 예에서 거래(101))는 하위 버짓이 부여되고, 이는 이전 거래(예를 들어 도 1의 예에서 거래(103 및 104))를 검증하기 위해 재귀적으로 분할될 수 있다. 일부 실시예에서, 검증 버짓은 평균이 거래의 크기에 의존하는 분포로부터 랜덤으로 선택될 수 있다.
일부 실시예에서, 검증 버짓은 확인된 거래의 수의 유닛으로 지정될 수 있다. 대안적으로 또는 추가적으로, 검증 버짓 유닛은 예를 들어 전송된 메시지의 수, 소비된 CPU 시간 및/또는 사용된 컴퓨터 메모리의 양과 같은 검증을 위해 수행된 작업의 척도를 나타낼 수 있다.
일부 실시예에서, 검증자는 수신 거래를 검증하는 것과 계정 리소스를 고갈시키는 수신 거래가 생략되지 않았음을 복제본 및/또는 로그 노드로 검증하는 것 사이에서 전체 버짓을 분할할 수 있다. 일부 실시예에서, 이 할당 전략은 또한 재귀적으로 사용될 수 있다.
5. 복구
일부 실시예에서, 유효하지 않은 거래가 발견되면, 하나 이상의 소스 계정으로부터 전송된 야을 조정하고 하나 이상의 다른 소스 계정으로 이를 보완함으로써 복구될 수 있다. 이러한 방식으로, 소스 계정은 사용 가능한 리소스의 양보다 많은 양을 전송하는 것을 피할 수 있는 반면 타겟 계정은 동일한 양의 리소스를 수신할 수 있다. 일부 실시예에서, 유효하지 않은 거래만이 발견되면 교체될 수 있다. 예를 들어, 거래가 발생한 시점에서 거래를 지원할 충분한 잔액이 없었떤 소스 계정은 총괄적으로 충분한 잔액이 있는 하나 이상의 다른 계정으로 보완될 수 있다. 이러한 방식으로, 향후 거래를 밝히지 않고 유효하지 않은 거래의 발견 후 계정 내역을 일관된 상태로 되돌릴 수 있다.
일부 실시예에서, 유효하지 않은 거래에 대한 소스 계정을 보충하는 계정은 소스 계정을 유지하기 위한 책임이 있는 노드 또는 노드의 소유자와 관련된 계정일 수 있다. 일부 실시예에서, 유효하지 않은 거래 이후의 발신 거래의 경로를 따라 계정을 유지하는 복제 노드의 계정이 책임을 지게 될 수 있는데 이는 그러한 복제 노드가 유효하지 않은 거래를 확인하고 발견할 기회를 가지기 때문이다. 이러한 방식으로 복구 책임은 계정으로부터 발신 거래를 수락하기 전에 계정의 거래 내역을 적절하게 확인하는 인센티브를 제공할 수 있다.
일부 실시예에서, RAS는 노드 소유자가 계정을 유지하고 노드의 작동을 위한 조건으로서 이들 계정에서 최소량의 리소스를 유지하도록 요구할 수 있다. 이러한 방식으로, 시스템은 거래 복구에 사용할 수 있는 리소스가 항상 있는지 확인할 수 있다. 일부 실시예에서, 노드는 거래를 처리하기 위해 거래 수수료를 부과할 수 있다. 이러한 방식으로, 시스템은 때때로 거래를 복구해야 할 수도 있다는 사실에도 불구하고 거래 처리가 평균적으로 노드 소유자에게 이익이 될 수 있도록 보장할 수 있다.
예를 들어, 도 4의 다이어그램(400)에 도시된 바와 같이, 제안된 거래(405)를 검증하는 방법으로, 복제 노드(411)는, 수신 거래(404)를 따라 계정(420)의 복제 노드(426)의 복제 노드(421)로 확인한 다음 거래(402)에 따라 계정(410)의 복제 노드(436)의 복제 노드(435) 및/또는 복제 노드(435)와 관련된 로그 노드(438) 중 하나를 확인함으로써 계정(430)으로부터 계정(420)으로의 리소스의 거래(402)가 유효하지 않다는 것을 찾은 경우, 복구 프로세스를 시작할 수 있으며, 이에 따라 복제 그룹(426 및 436)에서 노드의 소유자와 관련된 계정(450)은 계정(420)에 리소스를 제공하여 계정(430)으로부터 불법적으로 송신된 임의의 양을 대체함으로써 손상된 거래(404)에 대한 리소스를 복원하고 제안된 거래(405)를 가능하게 한다.
일부 실시예에서, 거래 내역의 검증은 다수의 가능한 유효하지 않은 거래를 초래할 수 있으며, 일관성 제약을 만족시키기 위해 그 서브 세트만이 무효화될 필요가 있다. 예를 들어, 계정(430)에는 X와 Y 크기의 2개의 거래가 있었으며 X는 계정(420)에 Y는 일부 다른 계정에 있어서 X 및 Y는 함께 사용 가능한 최대 리소스를 초과했다. 일부 실시예에서, 그러한 경우에, 시스템은 다른 기준에 따라 무효화할 거래의 세트를 선택할 수 있다. 그 합이 제한을 공동으로 초과하는 발신 거래의 세트가 있는 일부 실시예에서, 무효화될 서브 세트는 이용 가능한 리소스가 주어지면 가능한 작도록 선택될 수 있다. 이러한 서브 세트가 여러 개 있는 일부 실시예에서, 하나는 랜덤으로 선택될 수 있다. 많은 수의 거래가 있는 일부 실시예에서, 냅색 문제에 대한 적절한 다항식 시간 근사 방식([KU1999]에 설명된 바와 같음)이 서브 세트를 선택하는데 사용될 수 있다. 일부 실시예에서, 시스템에 참여하기 위해 노드는 할당된 양의 에스크로를 제출해야 한다. 이러한 방식으로 시스템은 일부 리소스를 복구를 위해 사용할 수 있음을 확신할 수 있다.
실시예는 책임을 분배하기 위해 다양한 방법을 사용할 수 있다. 예를 들어, 일부 실시예에서, 원래 유효하지 않은 거래를 수락하기 위한 책임이 있엇던 노드는 유효하지 않은 거래를 복구할 수 있는 완전한 능력까지 공동으로 책임을 질 수 있다. 일부 실시예에서, 임의의 추가 책임은 제1 유효하지 않은 거래 이후 모든 발신 거래에 대한 책임이 있는 복제본의 계정 간에 비례적으로 분할될 수 있다. 일부 실시예에서, 직접 책임이 없는 노드가 제한될 수 없는 리소스의 양 및 부족한 리소스를 유지하기 위한 책임은 유효하지 않은 거래 또는 동일한 계정으로부터 후속 발신 거래로부터의 리소스가 흐르는 계정의 복제본에 대해 책임이 있는 노드의 계정으로 재귀적으로 전달될 수 있다. 이러한 방식으로, 단순히 운이 나쁘고 악의적이지 않은 노드는 복구에 대한 제한된 책임으로 제한될 수 있지만 이러한 확률의 가능성을 최소화하기 위해 검증 확인을 수행할 인센티브를 여전히 가진다. 이러한 방식으로, 노드가 거래의 성공적인 처리에 대한 보상을 받으면 가끔 예기치 않은 리소스 비용이 발생하더라도 평균적으로 거래 처리가 유리할 것으로 예상할 수 있다.
일부 실시예에서, 리소스에 대한 비용을 최소화하거나 값을 최대화하기 위해 복구가 진행될 수 있다. 예를 들어, 리소스가 기본 객체 및/또는 부분의 계산된 속성인 경우, 거래를 무효화해야하는 복구 메커니즘은 거래 전체를 대체할 수 없다. 이러한 경우 복구 단계는 최소 값 및/또는 최대 비용으로 거래를 무효화할 수 있다. 예를 들어, 시스템이 이러한 어셈블리의 값인 리소스를 사용하여 부품과 어셈블리에 대한 계획된 포함(inclusion)을 추적하고 시스템이 2 개의 분리된 어셈블리에 포함된 것으로 특정 부품이 잘못 기록된 것을 발견하면, 시스템은 어셈블리의 전체 값을 최소한으로 줄이는 포함을 무효화하도록 선택할 수 있다. 일부 실시예에서, 발생할 수 있는 임의의 손실을 보상하기 위해 다른 종류의 리소스가 전송될 수 있다. 예를 들어, 시스템이 부품, 어셈블리 및 그 소유자를 모두 추적하고 소유자와 관련된 가치있고 이송 가능한 리소스를 갖는 계정을 유지하는 경우 이러한 전송 가능한 리소스를 무효화와 관련된 값의 손실을 보상하기 위해 부품의 소유자의 계정으로부터 무효화된 어셈블리의 소유자의 계정에 전송할 수 있다.
6. 책임 체인(responsibility chaining)
복구에 대한 책임을 분배하는 위의 방법에 더하여 또는 그 대안으로, 시스템은 다른 계정의 리소스를 복구에 사용되도록 지정할 수 있다. 일부 실시예에서, 특정 즉시 책임 계정(certain immediately responsible account)이 유효하지 않은 계정을 수락한 복제본의 노드 소유자에 속하면, 시스템은 즉시 책임 계정이 제공할 수 없는 양의 일부 또는 전부에 대한 책임이 있는 즉시 책임 계정의 기록을 유지하는 복제본의 소유자를 만들 수 있다. 일부 실시예에서, 이 책임은 이전 레벨이 복구하지 않은 양에 대해 전이적으로 공동 책임을 지는 폭 우선 방식(breadth-first manner)으로 레벨로 흐르는 책임과 함께 재귀적으로 다른 계정으로 유사한 방식으로 더 확장될 수 있다.
일부 실시예에서, 유효하지 않은 거래를 악의로 수락하는 노드를 제외하고, 책임 체인의 노드는 거래 및/또는 책임이 있는 계정 별로 제한된 책임을 가질 수 있다. 이러한 방식으로, 불운한 노드의 예상 비용이 제한된다.
도 5는 일부 실시예에 따른 계정(512)에서 유효하지 않은 거래에 대한 책임을 예시하는 다이어그램(500)을 도시한다. 계정(512)은 계정 복제 노드(520)(복제 노드(521,522 및 523)로 구성됨)를 갖는다. 제1 레벨(레벨(510))에서 계정(512)의 적자(deficit)를 복구하기 위한 책임은 복제 노드(520)(즉, 계정(513), 계정(532) 및 계정(533))가 소유한 계정(530)에 있을 수 있다. 복제본(520)은 원래 거래를 검증할 책임이 있기 때문에, 그 책임은 그 계정(530)으로부터 제한되거나 인출되지 않을 수 있다. 그러나, 부족한 양과 리소스의 유형을 복구하는 계정(530)의 능력은 불충분할 수 있다. 따라서, 일부 실시예에서, 임의의 잔여 적자는 계정(531)에 책임이 있는 복제 노드(550)(노드(551, 552, 553)), 계정(532)에 책임이 있는 복제 노드(560)(노드(561, 562, 563)) 및 계정(533)에 책임이 있는 복제 노드(570)(노드(571, 572, 573))로 구성되는 제2 레벨(540)로 흐를 수 있다. 이러한 계정은 잔여 적자를 복구히가 위한 제한된 책임을 부담할 수 있으며, 임의의 추가 잔여량은 유사한 방식으로 레벨(540)(및 후속 레벨)에서 노드의 계정을 유지하기 위한 책임이 있는 복제 노드를 포함하는 제3 레벨 및 임의의 후속 레벨(590)으로 흐를 수 있다.
일부 실시예에서, 거래를 처리하고 그 소유자가 계정을 유지하는 노드는 체인된 복제 노드라고 하는 그 노드를 관리하는 복제 노드로부터 더 많은 거래를 처리하는 능력을 주기적으로 요청할 수 있다. 일부 환경에서 이러한 허가의 증거는 거래 서명에 사용될 수 있는 소스 계정의 각 복제 노드에 대한 체인된 복제 노드의 쿼럼에 의해 서명된 암호화 인증 토큰일 수 있다. 일부 실시예에서, 거래가 적절한 체인된 복제 노드에 의해 발생된 유효한 인증 토큰에 대한 서명된 참조를 포함하지 않는 한 거래는 수락된 것으로 간주되지 않을 수 있다. 책임 체인의 체인된 복제 노드는 예를 들어 주어진 거래 수수료의 비율에 대한 대가로 더 많은 토큰에 대한 요청을 허용할 수 있다. 일부 실시예에서, 이러한 요청은 전이적으로 사용될 수 있다. 이러한 방식으로, 계정을 관리하는 노드에 대한 계정을 관리하는 것은 때때로 거래 복구에 참여하더라도 잔액에 대해(on balance) 유리할 수 있다.
일부 실시예에서, 시스템은 복제 노드가 복제하는 계정에 대한 거래를 처리할 때 체인된 복제 노드 쿼럼에서 인증 토큰을 사용하여 거래를 검증하면서, 체인된 복제 노드 쿼럼으로부터의 인증 토큰을 별도 리소스로 관리할 수 있다. 일부 실시예에서, 1차 리소스에 대한 주어진 거래를 처리하는데 필요한 인증 토큰의 양은 1차 리소스의 총량, 나가는 1차 리소스 및/또는 들어오는 1차 리소스에 대한 1차 리소스의 양에 비례할 수 있다. 일부 실시예에서, 인증 토큰의 검증은 거래의 전체 검증의 일부로서 달성될 수 있으며, 이에 따라 검증자는 검증 버짓 및/또는 사용된 확률적 선택 방법의 세부 사항 모두에 따라 1차 리소스 또는 인증 토큰의 리소스를 검증하기 위해 확률적으로 선택한다.
일부 실시예에서, 인증 토큰의 생성은 체인된 복제 노드에 의해 관리될 수 있다. 일부 실시예에서, 책임 체인의 주어진 레벨에서의 인증 토큰의 생성은 다음 레벨에서의 인증 토큰의 사용을 요구한다. 일부 실시예에서, 체인된 복제 노드의 쿼럼에 의한 임의의 레벨에서 인증 토큰의 허가는 에스크로의 양과 체인된 복제 노드 소유자에게 처리되는 거래의 인지된 위험성 모두에 의존할 수 있다. 이러한 방식으로 낮은 레벨에서 거래를 처리하도록 더 높은 레벨로부터의 거래를 처리하기 위한 인증 토큰을 요구하는 명백한 회귀(apparent regress)는 에스크로의 제공 및/또는 거래 평균 유효성이 책임 체인의 제한된 수의 레벨만을 포함하면서 높은 볼륨 및/또는 처리될 거래의 값을 허용할 수 있기 때문에 시스템 확장에 필수적인 장애가 될 필요가 없다.
7. 배치 거래
일부 실시예에서, 예를 들어 거래 비용으로 인해, 노드는 거래 크기가 작아짐에 따라 거래의 일부로 커질 수 있는 보상 없이 작은 거래를 처리하지 않거나 처리할 수 없을 수 있다. 발명자는 금지된 수수료 없이 작은 거래를 처리하는 것이 종종 바람직하다는 것을 인식했다. 따라서, 일부 실시예에서, 거래의 그룹은 랜덤 검증을 사용하여 함께 처리될 수 있다. 일부 실시예에서, 이는 배치가 하나의 더 큰 거래인 것처럼 거래 배치의 소스 계증을 확인함으로써 달성될 수 있다. 이러한 방식으로, 검증을 위해 위에서 설명된 임의의 이전 기술이 전체 거래 그룹에 적용될 수 있다.
일부 실시예에서, 거래의 배치는 공동 책임을 나타낼 수 있다: 예를 들어, 취해진 많은 작은 작업에 대한 책임. 검증은 배치의 분석을 취하는 것으로 간주될 수 있다; 이 책임의 총량은 샘플에서 발견된 유효하지 않은 그리고/또는 손상된 거래의 비율에 따라 전체 또는 벌금으로 수락될 수 있다.
8. 유지
일부 실시예에서 RAS는 결국 유효하지 않은 거래를 찾아서 정정할 수 있다는 것을 이해해야 한다. 그러나, 일부 실시예에서, 주어진 유효하지 않은 거래가 발견될 확률이 후속 거래의 수의 함수로서 확실성에 수렴하는 기간의 길이이다. 이 확률은 후속 거래의 수와 독립적으로 수렴하는 것이 바람직할 수 있다. 일부 실시예에서, 시스템은 주기적으로 계정을 검증하고 그리고/또는 후속 거래와 독립적일 수 있다. 일부 실시예에서, 거래 또는 계좌는 그 내역의 확률적 검증을 위해 랜덤으로 선택될 수 있다. 일부 실시예에서, 임계 수 미만의 거래를 갖는 계정은 검증 노드를 갖는 거래로서 구현된 주기적인 유지 수수료를 발생시킬 수 있으며, 이는 부작용으로서 내역이 검증을 트리거할 것이다. 일부 실시예에서, 유지 임계값은 계정의 자산에 비례할 수 있다. 이러한 방식으로, 후속 거래에 관계 없이 유효하지 않은 거래가 발견될 수 있다.
9. 시스템 다이어그램
도 6은 다양한 실시예가 구현될 수 있는 일부 실시예에 따른 리소스 할당 시스템(600)의 블록도를 도시한다. RAC(600)는 네트워크(650)를 통해 연결된 노드(610, 620, 621 … 629)로 도시된 복수의 노드를 포함한다. 개략적으로, 본 개시의 임의의 양태가 구현될 수 있는 예시적인 컴퓨터(600)이다.
노드는 컴퓨팅 장치일 수 있다. 일부 실시예에서, 노드는 여러 컴퓨터에 의해 구현될 수 있고/있거나 여러 노드는 단일 컴퓨터의 작업에 의해 구현될 수 있다. 컴퓨팅 노드는 여러 역할을 가질 수 있다. 예를 들어, 계정 복제 노드와 로그 노드 모두가 될 수 있다; 대안적으로, 서로 다른 역할이 분리된 컴퓨팅 노드에 의해 구현될 수 있다. 각 노드는 적절한 컴퓨팅 장치를 통해 또는 임의의 적절한 방식으로 구현될 수 있다. 일부 실시예에서, 다수의 노드가 동일한 컴퓨팅 장치에서 구현되고 일부 컴퓨터 하드웨어를 공유할 수 있다. 일부 실시예에서 하나 이상의 노드가 가상 머신에서 구현될 수 있다. 일부 실시예에서, 컴퓨팅 장치는 네트워크 또는 통신 버스를 통해 연결되거나 동적으로 할당되는 하드웨어 리소스를 사용하여 자체적으로 분산될 수 있다. 복수의 노드가 동일하거나 유사한 구현을 가질 수 있지만 각 노드는 동일한 방식으로 구현될 필욘느 없다. 일부 실시예에 따른 노드(610)는 프로세서(611), 메모리(612), 네트워크 인터페이스(613) 및 사용자 입력/출력(615)을 포함한다.
프로세서(611)는 노드(610)의 다양한 양태를 제어하도록 구성될 수 있으며 메모리(612)에 동작 가능하게 연결될 수 있다. 프로세서(611)는 예를 들어 중앙 처리 장치(CPU), 디지털 신호 프로세서(DSP), 컨트롤러, 어드레서블 컨트롤러(addressable controller), 범용 또는 특수 목적 마이크로프로세서, 마이크로 컨트롤러, 어드레서블 마이크로 프로세서, 프로그래머블 프로세서, 프로그래머블 컨트롤러, 전용 프로세서, 전용 컨트롤러 또는 임의의 적절한 처리 장치와 같은 임의의 적절한 처리 장치일 수 있다. 일부 실시예에서, 프로세서(611)는 하나 이상의 프로세서를 포함할 수 있으며, 예를 들어, 프로세서(611)는 다중 코어를 가질 수 있고 그리고/또는 다중 마이크로칩으로 구성될 수 있다. 다양한 실시예에서, 프로세서(611)에 의한 처리는 순차적으로, 병렬로 또는 일부 다른 방법 또는 방법의 조합에 의해 수행될 수 있다.
메모리(612)는 프로세서(611)에 통합될 수 있고/있거나, 예를 들어 메모리 버스(미도시)를 통해 프로세서(611)에 액세스할 수 있는 “오프 칩” 메모리를 포함할 수 있다. 메모리(612)는 프로세서(611)에 의해 실행될 때 원하는 기능을 수행하는 컴퓨터 실행 가능 명령을 저장할 수 있다. 메모리(612)는 메모리(612)로 로딩될 수 있는 애플리케이션 프로그램(예를 들어, 소프트웨어 라이브러리)에 의해 사용되는 하나 이상의 애플리케이션 프로그램 및/또는 외부 구성 요소를 저장할 수 있다. 본 명세서에 설명된 기능 중 임의의 것을 수행하기 위해, 프로세서(611)는 프로세서(611)에 의한 실행을 위한 프로세서 실행 가능한 명령을 저장하는 비일시적 컴퓨터 판독 가능 저장 매체로서 기능할 수 있는 메모리(612)에 저장된 하나 이상의 프로세서 실행 가능 명령을 실행할 수 있다.
메모리(612)는 예를 들어 RAM, 나노 기술 기반 메모리, 광학 디스크, 휘발성 및 비 휘발성 메모리 장치, 자기 테이프, 플래시 메모리, 하드 디스크 드라이브, FPGA(Field Programmable Gate Array)의 회로 구성 또는 다른 반도체 장치 또는 다른 유형의 비 일시적 컴퓨터 저장 매체와 같은 비 일시적 컴퓨터 판독 가능 저장 매체의 임의의 적절한 유형일 수 있다.
네트워크 인터페이스(613)는 네트워크를 통해 통신하도록 구성된 하드웨어 및 소프트웨어의 임의의 적절한 조합일 수 있다. 네트워크 인터페이스는 전기 신호를 사용하여 네트워크의 정보를 송신 및/또는 수신하기 위해 노드(610)의 다른 구성 요소로부터 명령을 수신하도록 구성될 수 있다. 네트워크 인터페이스(613)는 네트워크에 대한 케이블 연결 및/또는 케이블 연결되지 않은(“무선”) 연결을 가질 수 있다.
노드(610)는 사용자와 상호작용하기 위한 하나 이상의 입력 및 출력 장치(615)를 가질 수 있다(사용자 I/O(615)). I/O(615)는 무엇보다도 사용자 인터페이스를 제공하기 위해 사용될 수 있다. 사용자 인터페이스를 제공하는데 사용될 수 있는 출력 장치의 예는 출력의 시각적 표현을 위한 프린터 또는 디스플레이 스크린 또는 출력의 청각적 표현을 위한 스피커 또는 달느 음향 생성 장치를 포함한다. 사용자 인터페이스를 위해 사용될 수 있는 입력 장치의 예는 마우스, 터치 패드 및 디지털 태블릿과 같은 포인팅 장치 및 키보드를 포함한다. 다른 예로서, 입력 장치는 오디오 신호를 캡쳐하기 위한 마이크로폰을 포함할 수 있고 출력 장치는 인식된 텍스트를 시각적으로 렌더링하기 위한 디스플레이 스크린 및/또는 청각적으로 렌더링하기 위한 스피커를 포함할 수 있다.
노드(610-649)는 네트워크(650)를 통해 통신할 수 있다. 네트워크(650)는 인터넷, 다른 사설 또는 공용 네트워크, 유선(예를 들어, 이더넷, 광섬유) 네트워크, 무선 네트워크 또는 네트워크 및 네트워크 기술의 임의의 적절한 조합과 같은 임의의 적절한 네트워크일 수 있다.
일부 실시예에서, 계좌 거래는 단말기(660-669)와 같은 임의 수의 단말기로부터 시작된다. 단말기는 그러한 거래를 용이하게 하기 위한 적절한 컴퓨터 하드웨어 및 소프트웨어를 가질 수 있다. 예를 들어, 거래가 RAS(600)에서 초기화될 수 있기 전에 계정 소유자의 인증이 필요할 수 있다. 일부 실시예에서, 거래는 동일하거나 중첩하는 컴퓨터 하드웨어에서 작동하거나 그리고/또는 적절한 네트워크 인터페이스를 통해 이용 가능한 리소스 할당 시스템을 사용할 기회를 가질 수 있는 임의의 다른 기능을 수행하는 다른 컴퓨팅 시스템에 의해 생성될 수 있다.
이와 같이, 적어도 하나의 실시예의 여러 측면을 설명하였지만, 다양한 변경, 수정 및 개선이 당업자에게 쉽게 발생할 수 있음을 이해해야 한다. 그러한 변경, 수정 및 개선은 본 개시의 사상 및 범위 내에 있는 것으로 의도된다. 따라서, 전술한 설명 및 도면은 단지 예일 뿐이다.
전술한 본 발명의 실시예는 임의의 다양한 방식으로 구현될 수 있다. 예를 들어, 실시예는 하드웨어, 소프트웨어 또는 이들의 조합을 사용하여 구현될 수 있다. 소프트웨어로 구현될 때, 소프트웨어 코드는 단일 컴퓨터에 제공되든 다수의 컴퓨터에 분산되어 있든 상관없이 임의의 적합한 프로세서 또는 프로세서의 모음에서 실행될 수 있다.
또한, 본 명세서에 설명된 다양한 방법 또는 프로세스는 다양한 운영 시스템 또는 플랫폼 중 임의의 하나를 사용하는 하나 이상의 프로세서에서 실행 가능한 소프트웨어로 코딩될 수 있다. 추가적으로, 이러한 소프트웨어는 다수의 적절한 프로그래밍 언어 및/또는 프로그래밍 또는 스크립팅 도구 중 임의의 것을 사용하여 작성될 수 있으며, 실행 가능한 기계 언어 코드 또는 프레임워크 또는 가상 기계에서 실행되는 중간 코드로 컴파일링될 수도 있다.
이와 관련하여, 본 명세서에 개시된 개념은, 하나 이상의 컴퓨터 또는 다른 프로세서에서 실행될 때 상술한 본 개시의 다양한 실시예를 구현하는 방법을 수행하는 하나 이상의 프로그램으로 인코딩된 비 일시적 컴퓨터 판독 가능 매체(또는 다중 컴퓨터 판독 가능 매체)(예를 들어, 컴퓨터 메모리, 하나 이상의 플로피 디스크, 콤팩트 디스크, 광 디스크, 자기 테이프, 플래시 메모리, FPGA로 구성된 회로 또는 다른 반도체 장치 또는 다른 비 일시적 유형의 컴퓨터 저장 매체)로 구현될 수 있다. 컴퓨터 판독 가능 매체 또는 미디어는 전송 가능할 수 있고 그에 따라 저장된 프로그램은 하나 이상의 상이한 컴퓨터 또는 다른 프로세서에 로딩되어 전술한 바와 같이 본 개의 다양한 양태를 구현할 수 있다.
용어 “프로그램” 또는 “소프트웨어”는 상술한 바와 같이 본 개시의 다양한 양태를 구현하기 위해 컴퓨터 또는 다른 프로세서를 프로그래밍하는데 사용될 수 있는 임의의 유형의 컴퓨터 코드 또는 컴퓨터 실행 가능 명령의 세트를 지칭하기 위해 사용된다. 추가로, 이 실시예의 일 양태에 따르면, 실행될 때 본 개시의 방법을 수행하는 하나 이상의 컴퓨터 프로그램은 단일 컴퓨터 또는 프로세서 상에 상주할 필요가 없지만, 모듈 방식으로 다수의 상이한 컴퓨터 또는 프로세서 사이에 분산되어 본 개시의 다양한 양태를 구현할 수 있음을 이해해야 한다.
컴퓨터 실행 가능 명령은 하나 이상의 컴퓨터 또는 다른 장치에 의해 실행되는 프로그램 모듈과 같은 다양한 형태일 수 있다. 일반적으로, 프로그램 모듈은 특정 작업을 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 구성 요소, 데이터 구조 등을 포함한다. 일반적으로, 프로그램 모듈의 기능은 다양한 실시예에서 원하는 대로 결합되거나 분배될 수 있다.
또한, 데이터 구조는 임의의 적절한 형태로 컴퓨터 판독 가능 매체에 저장될 수 있다. 설명의 단순화를 위해, 데이터 구조는 데이터 구조에서의 위치를 통해 관련된 필드를 갖는 것으로 표시될 수 있다. 이러한 관계는 마찬가지로 필드 사이의 관계를 전달하는 컴퓨터 판독 가능 매체의 위치를 갖는 필드에 대한 스토리지를 할당함으로써 달성될 수 있다. 그러나, 포인터, 태그 또는 데이터 요소 간의 관계를 설정하는 다른 메커니즘의 사용을 포함하여 데이터 구조의 필드에 있는 정보 간의 관계를 설정하는데 임의의 적합한 메커니즘이 사용될 수 있다.
본 개시의 다양한 특징 및 양태는 단독으로, 둘 이상의 임의의 조합으로 또는 전술한 실시예에서 구체적으로 논의되지 않은 다양한 배열로 사용될 수 있으며, 따라서 그 적용이 이전 설명 또는 도면에서의 예에서 설명된 구성요소의 배열 및 세부 사항으로 제한되지 않는다. 예를 들어, 일 실시예에서 설명된 양태는 다른 실시예에서 설명된 양태와 임의의 방식으로 결합될 수 있다.
또한, 본 명세서에서 개시된 개념은 예가 제공된 방법으로 구현될 수 있다. 방법의 일부로 수행되는 행위는 임의의 적절한 방식으로 오더링될 수 있다. 따라서, 예시적인 실시예에서 순차적인 동작으로 도시시되더라도 일부 동작을 동시에 수행하는 것을 포함할 수 있는 설명된 것과 다른 순서로 동작이 수행되는 실시예가 구성될 수 있다.
청구 요소를 수정하기 위해 청구항에서 “제1”, “제2”, “제3” 등과 같은 서수 용어를 사용하는 것은 그 자체로 다른 것에 대한 하나의 청구 요소의 우선 순위, 또는 순서 또는 방법의 동작이 수행되는 시간적 순서를 의미하지 않으며, 단지 특정 이름을 갖는 하나의 청구 요소를 동일한 이름을 갖는 다른 요소와 구별하여 청구 요소를 구별하기 위한 레이블로서 사용된다.
또한, 본 명세서에 사용된 어법 및 용어는 설명을 위한 것이며 제한적인 것으로 간주되어서는 안된다. 본 명세서에서 “포함하는(including)”, “포함하는(comprising)”, “갖는”, “함유하는”, “포함하는(involving)” 및 이들의 변형의 사용은 이후에 나열된 항목 및 그의 등가물 및 추가 항목을 포함하는 것을 의미한다.
10. 참조 문헌
[AS2007] Awerbuch, Baruch, and Christian Scheideler. “Towards Scalable and Robust Overlay Networks.” IPTPS. Vol. 7. 2007.
http://citeseerx.ist.psu. edu/viewdoc/download?doi=10.1.1.176.6088&rep=rep l&type=pdf
[BG2013] Bailis, Peter, and Ali Ghodsi.“Eventual consistency today: Limitations, extensions, and beyond.” Queue 11.3 (2013): 20, http://www.bailis.org/papers/eventual· queue2013.pdf
[FC2005] Feldman and Chuang,“Overcoming Free-Riding Behavior in Peer-to-Peer Systems,” ACM sigecom exchanges 5.4 (2005): 41-50.
http://www.sigecom.org/exchanges/volume_5_(04)/5.4-feldman.pdf
[FYS2005] Fiat, Amos, Jared Saia, and Maxwell Young. “Making chord robust to byzantine attacks.” European Symposium on Algorithms. Springer, Berlin, Heidelberg, 2005.
https://s3. amazonaws.com/academia.edu. documents/32883830/chord.pdf?AWSAccessKeyId= AKIAIWOWYYGZ2Y53UL3A&Expires=1537461008&Signature=wT9jeMWBS4izqreaGsEG Mv5bbE8%3D&response-content-disposition=inline%3B%20filename%3DMaking_Chord_Robust_to_Byzantine_Attacks.pdf
[KG2009], Kate and Goldberg, Kate, Aniket, and Ian Goldberg. “Distributed key generation for the internet.” 2009 29th IEEE International Conference on Distributed Computing Systems. IEEE, 2009.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.216.7018&rep=repl&type=pdf
[KU1999] Kellerer, Hans, and Ulrich Pferschy. “A new fully polynomial time approximation scheme for the knapsack problem.” Journal of Combinatorial Optimization 3.1 (1999): 59-71.
[L2010] Lamport, Leslie. “Byzantizing Paxos by refinement.” International Symposium on Distributed Computing. Springer, Berlin, Heidelberg, 2011.
https://lamport.azurewebsites.net/tla/byzsimple.pdf
[LSP1982] Lamport, Leslie, Robert Shostak, and Marshall Pease. “The Byzantine generals problem.” ACM Transactions on Programming Languages and Systems (TOPLAS) 4.3 (1982): 382-401.
[LCP2005] Lua, Eng Keong, et al. “A survey and comparison of peer-to-peer overlay network schemes.” IEEE Communications Surveys and tutorials 7.1-4 (2005): 72-93, https://ieeexplore.ieee.org/abstract/document/1610546/
[YKG2013] Young et al, “Towards Practical Communication in Byzantine -Resistant DHTs,” http://www.cypherpunks.ca/~iang/pubs/ByzantineDHT_Journal.pdf
특허:
[M2016] Michali 2016, “Distributed transaction propagation and verification system”, US Patent PCT/US2017/031037
[US6463532B1] System and method for effectuating distributed consensus among members of a processor set in a multiprocessor computing system through the use of shared storage resources.
[US20130290249A1] Large distributed database clustering systems and methods
[US20180341930A1] Sharded Permissioned Distributed Ledgers
[WO2019032891A1] Verification of interactions system and method
[US20170264428A1] Data storage system with blockchain technology
[US10135609B2] Managing a database management system using a blockchain database

Claims (45)

  1. 리소스 할당 시스템의 컴퓨팅 장치로서,
    상기 컴퓨팅 장치는:
    적어도 하나의 프로세서; 및
    그 상에 인코딩된 명령을 갖는 적어도 하나의 비 일시적 컴퓨터 판독 가능 저장 매체를 포함하며,
    상기 비 일시적 컴퓨터 판독 가능 저장 매체는, 적어도 하나의 프로세서에 의해 실행될 때 적어도 부분적으로:
    리소스 할당 시스템에 기록된 거래 내역에서 확률적으로 하나 이상의 이전 거래를 선택하는 단계(또는 거래 내역이 하나의 요소만을 포함할 때 확실성으로 선택하는 단계);
    하나 이상의 이전 거래가 유효한지 결정하는 단계; 및
    제안된 거래가 손상되었는지 결정하는 단계로서, 적어도 하나의 이전 거래가 유효하지 않다고 결정되는 경우 제안된 거래가 손상된 것으로 결정되는, 결정하는 단계;에 의해 제안된 거래가 리소스의 부족으로 손상되는지 결정하기 위해 적어도 하나의 프로세서를 프로그래밍하는,
    컴퓨팅 장치.
  2. 제1항에 있어서,
    상기 제안된 거래가 손상되지 않았다는 결정 시, 컴퓨팅 장치는 제안된 거래가 수락되었음을 나타내기 위해 제안된 거래를 리소스 할당 시스템에 기록하도록 추가로 프로그래밍되는,
    컴퓨팅 장치.
  3. 제1항에 있어서,
    상기 저장 매체는 리소스 할당 시스템에서 거래 기록을 갖는 분산 원장의 적어도 일부를 추가로 인코딩하는,
    컴퓨팅 장치.
  4. 제1항에 있어서,
    하나 이상의 상기 이전 거래 각각이 하나 이상의 소스 계정 각각으로부터의 거래량, 하나 이상의 소스 계정 및 소스 계정의 잔액과 관련되며,
    하나 이상의 상기 이전 거래가 유효한지 결정하는 단계는, 각 이전 거래에 대해, 각 소스 계정에 대해, 소스 계정의 잔액이 상기 소스 계정에 대한 거래량의 나가는 이체(outgoing transfer)를 지원하기에 충분했는지를 확인하는 단계를 포함하는,
    컴퓨팅 장치.
  5. 제1항에 있어서,
    상기 리소스는 제안된 거래에서 사용되는 선택된 유형의 리소스이고;
    상기 제안된 거래는 선택된 유형의 리소스의 양을 하나 이상의 소스 계정의 밖으로의 전송을 포함하며; 그리고
    하나 이상의 상기 이전 거래는 하나 이상의 소스 계정으로부터 추적 가능한 복수의 이전 거래로부터 선택되는,
    컴퓨팅 장치.
  6. 제5항에 있어서,
    상기 제안된 거래는 제1 거래를 포함하며;
    선택된 유형의 리소스의 양은 하나 이상의 소스 계정의 소스 계정의 밖으로 전송될 선택된 유형의 리소스의 제1 양을 포함하며; 그리고
    하나 이상의 선택된 이전 거래는 소스 계정으로 선택된 유형의 리소스의 제2 양이 전송되는 제2 거래를 포함하는,
    컴퓨팅 장치.
  7. 제5항에 있어서,
    상기 제안된 거래는 제1 거래를 포함하며;
    하나 이상의 소스 계정은 하나 이상의 제1 소스 계정을 포함하며;
    선택된 유형의 리소스의 양은 하나 이상의 제1 소스 계정의 밖으로 전송된 선택된 유형의 리소스의 제1 양을 포함하며;
    하나 이상의 소스 계정으로부터 추적 가능한 복수의 이전 거래는 제2 소스 계정의 밖으로 선택된 유형의 리소스의 제2 양이 전송된 제2 거래를 포함하며; 그리고
    하나 이상의 소스 계정으로부터 추적 가능한 복수의 이전 거래는 제2 거래 이전에 일어나는 제3 거래를 더 포함하며, 제3 계정은 제2 소스 계정으로 선택된 유형의 리소스의 제3 양을 전송하는,
    컴퓨팅 장치.
  8. 제5항에 있어서,
    하나 이상의 이전 거래를 확률적으로 선택하는 것은, 선택을 위해 고려된 하나 이상의 이전 거래의 총량에 대한 각각의 이전 거래의 양에 기초한 각각의 확률을 하나 이상의 이전 거래 각각과 연관시키는 것을 포함하는,
    컴퓨팅 장치.
  9. 제5항에 있어서,
    하나 이상의 이전 거래를 확률적으로 선택하는 것은, 타겟 계정으로 전송된 하나 이상의 이전 거래의 총량에 대한 타겟 계정으로 전송된 이전 거래의 양에 기초한 각각의 확률을 하나 이상의 이전 거래 각각과 연관시키는 것을 포함하는,
    컴퓨팅 장치.
  10. 제5항에 있어서,
    하나 이상의 상기 이전 거래의 선택에 의한 총량의 확인은 확인을 위한 리소스 버짓(resource budget)을 기초로 하고, 리소스 버짓은 제안된 거래에서 전송될 선택된 유형의 리소스의 양에 기초하여 결정되는,
    컴퓨팅 장치.
  11. 제10항에 있어서,
    상기 리소스 버짓은 복수의 리소스 유닛을 포함하고, 각각의 리소스 유닛은 하나 이상의 이전 거래 중 하나의 유효성을 확인하는데 사용되는 리소스의 양에 대응하는,
    컴퓨팅 장치.
  12. 제11항에 있어서,
    하나 이상의 상기 이전 거래 중 하나의 유효성을 확인하기 위해 사용되는 리소스의 양은 계산 작업(computational effort)의 양에 기초한 양을 포함하는,
    컴퓨팅 장치.
  13. 제12항에 있어서,
    상기 계산 작업은 리소스 할당 시스템에서 노드 사이에 전송된 메시지의 수에 기초하여 측정되는,
    컴퓨팅 장치.
  14. 제10항에 있어서,
    상기 리소스 버짓은 초기 버짓을 포함하며, 최종 버짓은 발견된 유효하지 않은 거래의 수, 발견된 유효하지 않은 거래의 총량 및/또는 제안된 거래에 의해 전송된 양과 유효하지 않은 거래에 대해 추적 가능한 총량을 할인한 후 사용 가능한 양 사이의 마진에 기초하여 조정되는,
    컴퓨팅 장치.
  15. 제1항에 있어서,
    상기 거래 내역은 복수의 계정의 복수의 거래 내역 복제본을 포함하며;
    적어도 하나의 프로세서는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드를 포함하며;
    제안된 거래는 적어도 하나의 소스 계정 밖으로의 전송을 포함하며;
    소스 계정 복제 노드는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드로부터의 하나 이상의 컴퓨팅 노드를 구성하며, 이는 적어도 하나의 소스 계정의 거래 내역 복제본을 유지하기 위한 책임이 있으며;
    소스 계정 복제 노드는 하나 이상의 선택된 이전 거래 중 일부를 독립적으로 선택하고 하나 이상의 선택된 이전 거래의 소스 계정을 유지하기 위한 책임이 있는 하나 이상의 컴퓨팅 노드를 쿼리(query)함으로써 하나 이상의 선택된 이전 거래의 소스 계정으로부터 데이터를 얻도록 추가로프로그래밍되며;
    소스 계정 복제 노드 중 적어도 하나는 컴퓨팅 노드에 의해 선택된 하나 이상의 이전 거래가 유효한지 여부를 독립적으로 결정하며; 그리고
    제안된 거래가 손상되었는지 결정하는 단계는 소스 계정 복제 노드의 쿼럼(quorum)을 형성하는 단계를 포함하며, 쿼럼의 공동 결과는 제안된 거래의 손상 여부를 결정하는데 사용되는,
    컴퓨팅 장치.
  16. 제15항에 있어서,
    상기 쿼럼은 소스 계정 복제 노드의 쿼럼을 포함하며; 그리고
    적어도 하나의 쿼럼 노드는 제안된 거래에 대한 쿼럼의 합의를 거래 로그에 기억하도록(memorialize) 더 프로그래밍되는,
    컴퓨팅 장치.
  17. 제16항에 있어서,
    적어도 하나의 상기 프로세서는 복수의 로그 노드를 추가로 포함하며; 그리고
    쿼럼의 각 노드는 쿼럼의 컴퓨팅 노드로부터 로그를 수집하기 위한 책임이 있는 적어도 하나의 관련 로그 노드를 갖는,
    컴퓨팅 장치.
  18. 제17항에 있어서,
    상기 쿼럼은 제1 쿼럼을 포함하고, 적어도 하나의 관련 로그 노드는 복수의 독립적인 로그 노드를 포함하고, 제2 쿼럼은 제2 쿼럼이 거래 기록을 수신했다는 합의를 형성하고, 합의를 형성하는 것에 응답하여 거래 기록이 거래 로그에 기록되도록 하고; 그리고
    적어도 하나의 소스 계정의 거래 내역 복제본을 유지하기 위한 책임이 있는 하나 이상의 컴퓨팅 노드는 각 멤버에 대한 로그 노드가 거래 기록을 기록하기 위해 합의를 이룬 대응하는 쿼럼을 갖는 제3 쿼럼의 각 멤버로부터 인증을 수신할 때만 제안된 거래에 대한 합의를 기록하는 제3 쿼럼을 포함하는,
    컴퓨팅 장치.
  19. 제15항에 있어서,
    적어도 하나의 상기 프로세서는 로그를 수집하기 위한 하나 이상의 노드를 포함하며;
    제안된 거래는 적어도 하나의 타겟 계정으로 리소스를 전송하는 거래를 포함하며;
    복수의 계정을 유지하기 위한 책임을 공유하는 복수의 노드는 적어도 하나의 타겟 계정에 대한 책임이 있는 노드를 포함하며; 그리고
    리소스 할당 시스템에 제안된 거래를 기록하는 것은 로그를 수집하기 위한 하나 이상의 노드에 적어도 하나의 타겟 계정에 대한 책임이 있는 노드에 의해 제안된 거래를 통신하는 것을 포함하는,
    컴퓨팅 장치.
  20. 제19항에 있어서,
    로그를 수집하기 위한 노드는 제안된 거래 및 적어도 하나의 소스 계정의 하나 이상의 특성의 기능 및 노드의 주소 사이의 대응성에 기초하여 선택되며, 하나 이상의 속성은 소스 계정 ID, 거래 번호 및/또는 제안된 거래의 기간을 포함하며, 노드는 제안된 거래에 대해 저장된 정보를 검색하기 위해 어드레스에서 질의할 수 있는,
    컴퓨팅 장치.
  21. 제1항에 있어서,
    적어도 하나의 상기 프로세서는 하나 이상의 이전 거래의 적어도 하나의 이전 거래가 유효하지 않다고 결정하는 것에 응답하여 추가로 프로그래밍되고, 적어도 부분적으로 적어도 하나의 이전 거래를 하나 이상의 대체 거래로 대체함으로써 리소스 할당 시스템에서 거래 내역을 수정하는,
    컴퓨팅 장치.
  22. 제21항에 있어서,
    유효하지 않은 것으로 결정된 적어도 하나의 상기 이전 거래는 선택된 유형의 리소스의 제1 양을 제1 소스 계정의 밖으로의 전송을 포함하며;
    적어도 하나의 이전 거래는 제1 양의 전송을 지원하기 위해 제1 소스 계정의 잔액이 제2 양만큼 부족하다고 결정하는 것에 응답하여 유효하지 않은 것으로 결정되며;
    적어도 하나의 이전 거래를 하나 이상의 대체 거래로 대체하는 것은 제1 소스 계정으로부터 전송된 제1 양을 제2 양만큼 감소시키고, 제2 양이 배분되는 하나 이상의 다른 소스 계정을 추가하는 것을 포함하는,
    컴퓨팅 장치.
  23. 제22항에 있어서,
    상기 리소스 할당 시스템은 복수의 노드에 의해 유지되며; 그리고
    다른 하나 이상의 소스 계정은 제1 소스 계정에 대한 복제본으로 작동하고 유효하지 않은 것으로 결정된 적어도 하나의 이전 거래를 수락한 노드와 관련된 적어도 하나의 소스 계정을 포함하는,
    컴퓨팅 장치.
  24. 제22항에 있어서,
    상기 리소스 할당 시스템은 복수의 노드에 의해 유지되며;
    하나 이상의 다른 소스 계정은 유효하지 않은 것으로 결정된 적어도 하나의 이전 거래를 처리하고 하나 이상의 다른 소스 계정의 잔액에 의해 지원되는 최대량을 구성하는 제2 양의 일부인 제3 양에 대해 총괄적으로 책임이 있는 노드와 관련된 하나 이상의 소스 계정을 포함하며;
    제2 양과 제3 양의 차이는, 적어도 하나의 이전 거래의 하나 이상의 타겟 계정 및/또는 제1 소스 계정으로부터의 후속 거래의 하나 이상의 타겟 계정 사이에 분배되고 합계가 그로부터 제거되며; 그리고
    리소스 할당 시스템은 적어도 하나의 이전 거래를 복구한 결과 다른 이전 거래가 유효하지 않다는 결정에 응답하여 다른 이전 거래를 복구하도록 추가로 프로그래밍되는,
    컴퓨팅 장치.
  25. 제23항에 있어서,
    상기 리소스 할당 시스템은 노드와 관련된 계정이 있도록 추가로 프로그래밍되며; 그리고
    서로의 계정을 상호적으로 관리하는 노드는 관리하는 다른 노드의 계정이 최소량의 리소스를 유지하는 것을 요구하도록 프로그래밍되는,
    컴퓨팅 장치.
  26. 제22항에 있어서,
    상기 거래 내역은 복수의 계정의 거래 내역 복제본을 포함하며;
    적어도 하나의 프로세서는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드를 포함하며;
    제1 소스 계정 복제 노드는 적어도 하나의 소스 계정의 거래 내역 복제본을 유지하기 위한 책임이 있는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드로부터의 하나 이상의 컴퓨팅 노드를 구성하며;
    하나 이상의 다른 소스 계정은 유효하지 않은 것으로 결정된 적어도 하나의 이전 거래가 수락된 제1 소스 계정 복제 노드와 관련된 제2 소스 계정을 포함하며;
    제2 양은 제2 소스 계정의 잔액에 의해 지원되는 제2 양 이하의 총량인 커버된 양(covered amount)과 제2 양에서 커버된 양이 공제된 후의 나머지인 잔여량으로 나뉘며;
    제2 소스 계정 복제 노드는 제2 소스 계정의 거래 내역 복제본을 유지하기 위한 책임이 있는 복수의 계정을 유지하기 위한 책임을 공유하는 복수의 컴퓨팅 노드로부터의 하나 이상의 컴퓨팅 노드를 구성하며;
    제3 소스 계정은 제2 소스 계정 복제 노드와 관련된 계정을 포함하며; 그리고
    리소스 할당 시스템은 잔여량이 제3 소스 계정에 배분되도록 추가로 프로그래밍되는,
    컴퓨팅 장치.
  27. 제26항에 있어서,
    제2 소스 계정 복제 노드는 체인된 복제 노드(chained replica node)의 제1 레벨을 포함하며;
    1보다 큰 레벨의 체인된 복제 노드는 이전 레벨의 체인된 복제 노드의 계정 복제본을 유지하기 위한 책임이 있는 노드를 구성하며; 그리고
    시스템은 주어진 레벨의 체인된 복제 노드의 계정에 이전 레벨에서 커버되지 않은 잔여량을 배분하도록 추가로 프로그래밍되는,
    컴퓨팅 장치.
  28. 제26항에 있어서,
    제3 계정 각각에 배분된 잔여량의 일부는 계정에서 이용 가능한 최대량 및 고정된 양 중 더 작은 것에 의해 제한되는,
    컴퓨팅 장치.
  29. 제26항에 있어서,
    계정 내역 복제본을 관리하는 노드는 제1 복제 노드를 포함하며;
    제1 복제 노드의 계정은 제1 복제 노드 계정을 포함하며;
    제1 복제 노드 계정의 계정 내역 복제본을 관리하는 노드는 제2 복제 노드를 포함하며; 그리고
    리소스 할당 시스템은 제1 복제 노드가, 제1 복제 노드가 내역을 관리하는 계정 상에 거래를 처리하기 위한 제2 복제 노드로부터 주기적으로 허가를 요청하도록 추가로 프로그래밍되는,
    컴퓨팅 장치.
  30. 제1항에 있어서,
    상기 컴퓨팅 장치는 제1항의 리소스 할당 시스템의 절차에 따르지만 이 프로세스에 의해 검색된 정보를 사용하여 제안된 거래 중 임의의 것이 손상되었는지 여부를 결정함으로써 여러 제안된 거래 중 임의의 것이 손상되었는지 결정하도록 추가로 프로그래밍되는,
    컴퓨팅 장치.
  31. 제0항에 있어서,
    여러 제안된 거래는 동일한 타겟 계정으로 또는 동일한 소스 계정으로부터의 거래를 포함하며, 소스 내역의 랜덤 조사로부터 얻는 정보는 거래에 의해 총괄적으로 전송된 것으로 간주되는 선택된 유형의 리소스의 총량을 조정하는데 사용되는,
    컴퓨팅 장치.
  32. 제1항에 있어서,
    상기 거래는 데이터 기록과 관련된 일부 리소스를 추적하거나 하나 이상의 소스 계정에서 데이터 기록에 기인할 수 있는 리소스의 양에 각각 대응하는 하나 이상의 계정 및 데이터 기록의 상태에 의해 계산될 수 있는 하나 이상의 소스 계정과 독립적으로 또는 개별적으로 관련된 하나 이상의 소스 데이터 기록과 연관되며, 거래가 유용한지 결정하는 것은 각 소스 계정에 대해 소스 계정에 의해 추적된 리소스의 양은 추적된 리소스의 양이 수정된 데이터 객체 대한 작업을 지원하기에 충분한지 확인하는 것을 포함하는,
    컴퓨팅 장치.
  33. 제21항에 있어서,
    상기 제안된 거래가 더 이상 손상되지 않을 수 있도록 하기 위해 대체될 수 있는 적어도 하나의 과거 거래의 서브 세트가 있다면, 시스템은 제안된 거래의 손상의 복구와 동일한 리소스의 최소한의 가능한 양을 포함하는 적어도 하나의 과거 거래의 서브 세트를 대체하도록 추가적으로 프로그래밍되는,
    컴퓨팅 장치.
  34. 제32항에 있어서,
    컴퓨팅 장치는 냅색 문제(knapsack problem)에 대한 근사 알고리즘으로 대체할 서브 세트를 찾도록 추가적으로 프로그래밍되는,
    컴퓨팅 장치.
  35. 제17항에 있어서,
    적어도 하나의 관련 로그 노드는 적어도 하나의 소스 계정의 거래 내역에 대한 쿼리에 응답하도록 추가로 프로그래밍되고, 소스 계정을 유지하기 위한 책임이 있는 하나 이상의 컴퓨팅 노드를 쿼리하는 것은 소스 계정 노드 또는 관련된 로그 노드를 쿼리하는 것을 의미하는,
    컴퓨팅 장치.
  36. 컴퓨팅 장치로서,
    적어도 하나의 프로세서; 및
    그 상에 인코딩된 명령을 갖는 적어도 하나의 비일시적 컴퓨터 판독 가능 저장 매체를 포함하며,
    상기 비일시적 컴퓨터 판독 가능 저장 매체는 적어도 하나의 프로세서에 의해 실행될 때 적어도 부분적으로:
    리소스 할당 시스템에 기록된 거래 내역에서 확률적으로 하나 이상의 이전 거래를 선택하는 단계; 및
    하나 이상의 이전 거래가 유효한지 결정하는 단계;에 의해 이전 거래가 리소스의 부족 때문에 유효하지 않은지 결정하기 위해 적어도 하나의 프로세서를 프로그래밍하는,
    컴퓨팅 장치.
  37. 제36항에 있어서,
    상기 프로그램은 주기적으로 실행되는,
    컴퓨팅 장치.
  38. 제36항에 있어서,
    상기 프로그램은 최근에 검증되지 않은 검증 계정을 선택하는,
    컴퓨팅 장치.
  39. 제29항에 있어서,
    주기적으로 허가를 요청하는 것은 리소스의 특정 총량의 최대량까지 전송하는 거래를 처리하기 위해 허가를 요청하는 것을 포함하는,
    컴퓨팅 장치.
  40. 제29항에 있어서,
    제2 복제 노드에 의해 부여된 허가는 거래를 처리하기 위한 하나 이상의 인증 토큰을 구성하며; 컴퓨팅 장치는 수락된 거래의 기록의 일부로서 인증 토큰에 대한 참조(reference)를 기록하도록 추가로 프로그래밍되는,
    컴퓨팅 장치.
  41. 제29항에 있어서,
    제2 소스 계정 복제 노드는 체인된 복제 노드의 제1 레벨을 포함하며;
    1보다 큰 레벨의 체인된 복제 노드는 이전 레벨의 체인된 복제 노드의 계정 복제본을 유지하기 위한 책임이 있는 노드를 구성하며;
    시스템은 더 낮은 레벨에 대한 허가를 부여하기 위해 이전 레벨의 체인된 복제 노드가 후속 레벨의 노드에 주기적으로 허가를 요청하도록 일정 레벨까지 추가로 프로그래밍되는,
    컴퓨팅 장치.
  42. 제41항에 있어서,
    제1 레벨에서 요청된 허가는 리소스의 특정 총량까지 전송하는 거래를 처리하기 위한 허가를 구성하며, 후속 레벨에서의 허가는 리소스의 특정 총량까지 전송하는 거래를 승인하는 다음 이전 레벨에 허가를 부여하기 위한 허가를 구성하는,
    컴퓨팅 장치.
  43. 제29항에 있어서,
    거래를 처리하기 위한 허가는 리소스 할당 시스템에 의해 관리되는 리소스의 유형으로서 기능하는,
    컴퓨팅 장치.
  44. 리소스 할당 시스템의 컴퓨팅 장치로서,
    적어도 하나의 프로세서; 및
    그 상에 인코딩된 명령을 갖는 적어도 하나의 비일시적 컴퓨터 판독 가능 저장 매체를 포함하며,
    상기 비일시적 컴퓨터 판독 가능 저장 매체는 적어도 하나의 프로세서에 의해 실행될 때 적어도 부분적으로:
    이전 수락에 대한 암호화 인증 및 거래의 체인에서의 위치를 포함하는 쿼리와 관련된 거래 기록을 반환하여 거래 내역에 대한 쿼리에 응답하는 단계;에 의해 제안된 거래가 리소스의 부족에 의해 손상 되었는지의 결정을 허락하도록 적어도 하나의 프로세서를 프로그래밍하는,
    컴퓨팅 장치.
  45. 이전 청구항 중 어느 하나의 컴퓨팅 장치에 의해 수행되는 방법.
KR1020217020352A 2018-11-30 2019-11-26 분산 리소스 할당을 위한 시스템 및 방법 KR20210087552A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201862773692P 2018-11-30 2018-11-30
US62/773,692 2018-11-30
PCT/US2019/063463 WO2020112914A1 (en) 2018-11-30 2019-11-26 Systems and methods for distributed resource allocation

Publications (1)

Publication Number Publication Date
KR20210087552A true KR20210087552A (ko) 2021-07-12

Family

ID=70851869

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020217020352A KR20210087552A (ko) 2018-11-30 2019-11-26 분산 리소스 할당을 위한 시스템 및 방법

Country Status (4)

Country Link
US (1) US20220058549A1 (ko)
EP (1) EP3888334A4 (ko)
KR (1) KR20210087552A (ko)
WO (1) WO2020112914A1 (ko)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3715981A1 (de) * 2019-03-27 2020-09-30 Siemens Aktiengesellschaft Verfahren und steuersystem zum steuern einer ausführung von transaktionen
US11606205B2 (en) 2021-05-28 2023-03-14 International Business Machines Corporation Causal total order broadcast protocols using trusted execution environments
US11706320B2 (en) 2021-05-28 2023-07-18 International Business Machines Corporation Scalable leader-based total order broadcast protocol for distributed computing systems
US11665067B2 (en) * 2021-05-28 2023-05-30 International Business Machines Corporation Managing reconfigurations of distributed computing systems
US20240061494A1 (en) * 2022-08-17 2024-02-22 Red Hat, Inc. Monitoring energy consumption associated with users of a distributed computing system using tracing

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6463532B1 (en) 1999-02-23 2002-10-08 Compaq Computer Corporation System and method for effectuating distributed consensus among members of a processor set in a multiprocessor computing system through the use of shared storage resources
US8468134B1 (en) * 2010-09-21 2013-06-18 Amazon Technology, Inc. System and method for measuring consistency within a distributed storage system
WO2013192198A2 (en) * 2012-06-18 2013-12-27 Actifio, Inc. Enhanced data management virtualization system
WO2015175722A1 (en) * 2014-05-13 2015-11-19 Nant Holdings Ip, Llc Healthcare transaction validation via blockchain proof-of-work, systems and methods
EP3516545A1 (en) * 2016-09-21 2019-07-31 R-Stor Inc. Systems and methods for using a distributed ledger for data handling
US11146535B2 (en) 2016-10-12 2021-10-12 Bank Of America Corporation System for managing a virtual private ledger and distributing workflow of authenticated transactions within a blockchain distributed network
US10636082B2 (en) * 2017-03-23 2020-04-28 Electronics Arts Inc. Proxy agent for distributed computing transactions
US10740733B2 (en) 2017-05-25 2020-08-11 Oracle International Corporaton Sharded permissioned distributed ledgers
US20200250780A1 (en) * 2017-10-23 2020-08-06 George Karypis Decentralized Autonomous Evaluation Engine for Intellectual Property Assets
KR20180046930A (ko) * 2018-04-18 2018-05-09 클레이웍스 주식회사 블록체인 기반 원산지증명시스템, 방법 및 프로그램

Also Published As

Publication number Publication date
WO2020112914A1 (en) 2020-06-04
EP3888334A4 (en) 2022-08-24
EP3888334A1 (en) 2021-10-06
US20220058549A1 (en) 2022-02-24

Similar Documents

Publication Publication Date Title
JP7422806B2 (ja) ブロックチェーン・ネットワークにおける暗号座礁リソースを回避又は削減する方法、電子デバイス及び記憶媒体
Christidis et al. Blockchains and smart contracts for the internet of things
US11921682B2 (en) Extracting data from a blockchain network
Baird et al. Hedera: A public hashgraph network & governing council
Zhang et al. Towards Dependable, Scalable, and Pervasive Distributed Ledgers with Blockchains.
TWI765019B (zh) 區塊鏈上之快速分散式共識
CN114514732B (zh) 用于区块链dag结构的共识协议的方法、计算系统和可读介质
KR20210087552A (ko) 분산 리소스 할당을 위한 시스템 및 방법
McConaghy et al. Bigchaindb: a scalable blockchain database
CN110771127B (zh) 用于区块链网络中一致分布式内存池的方法和系统
Debus Consensus methods in blockchain systems
CN109691015A (zh) 区块链上的动态访问控制
WO2018172439A1 (en) Method for operating a blockchain
US20200389521A1 (en) Holochain - A Framework For Distributed Applications
JP2023076628A (ja) 一対の結合ブロックチェーンを構成するバイナリブロックチェーンに関連するコンピュータ実装システム及び方法
KR20220088956A (ko) 기밀 지식의 특화된 증명을 제공하는 시스템들 및 방법들
KR20220027809A (ko) 가상 분산 원장 네트워크를 위한 시스템 및 방법
Li et al. Cost-effective data feeds to blockchains via workload-adaptive data replication
Ren et al. Interoperability in blockchain: A survey
CN112350863B (zh) 一种基于交易的去中心化访问控制方法和系统
Wels Guaranteed-TX: The exploration of a guaranteed cross-shard transaction execution protocol for Ethereum 2.0.
Gao et al. Improved byzantine fault-tolerant algorithm based on alliance chain
Bagchi Using blockchain technology and smart contracts for access management in IoT devices
US20210081430A1 (en) System and method for managing a role-based blockchain network
Davidson State machine replication and consensus with Byzantine adversaries