KR20200032086A - Distributed blockchain data structure distribution through secure access restriction management - Google Patents

Abstract

Disclosed herein is a system for providing an encryption platform for distributing data structures within a peer-to-peer network to exchange encrypted messages between nodes. The system provides the creation and management of a private subspace blockchain, including subspaces that are private but can be identified using the global state root. The global state route is updated based on the subspace route that is also created based on the data in the corresponding subspace.

Description

Distributed blockchain data structure distribution through secure access restriction management

Related applications

This application claims priority to U.S. Patent Application No. 62 / 513,773 filed on June 1, 2017, which is incorporated herein within the limits permitted by law.

Field of invention

The present invention relates generally to private subspace blockchain distributed data structures and systems and methods for managing them. More specifically, the present invention manages a new authorization chain data structure with multiple subspaces, an integrated verification mechanism that also provides authorization and secure access to subspaces within this chain data structure, and management of such authorization chain data structures. It relates to a system and method for.

A distributed database can provide decentralized means for distributing shared data across multiple different users, each of which may need to access shared data while remotely located from each other. . To be able to trust this shared data, there must be a way to verify the integrity of the data in a distributed database. A form of distributed database is a "blockchain" (or "blockchain"), which is a type of data structure consisting of a series of smaller data structures or records linked in chronological order, called a "block", each of which is The block has a link to the previous block in the chain. Each block contains the hash value of the previous block in the blockchain, which serves as a means of connecting the two blocks. The use of hash values ensures the verifiability of the data and prevents data modification within the blockchain. The integrity of the blockchain increases through its decentralized nature, in that it does not require a "official" copy located at the center of the blockchain. Instead, multiple verifiable copies of the blockchain can be stored with different users, thereby preventing unauthorized modification of the blockchain.

As with traditional blockchains, one disadvantage of this decentralized decentralized data structure is that the data stored within these data structures must be accessible to each holder of a copy of the data structure. Accessibility of data to each holder of a copy of the distributed data structure is intended to enable users to verify the integrity of the stored data, and to ensure that data stored within a specific copy of the distributed data structure has not been tampered with or modified. For, it is necessary. As a result, like traditional blockchains, this distributed data structure prevents users from privately storing data within the blockchain. Existing systems that share and use this distributed data structure do not require authorized or authorized access, and instead have the advantage of no access control. This is because the number of copies of the distributed data structure typically increases when there are additional users, and thus, the possibility of tampering with records decreases. In this respect, these traditional systems generally do not have a means to verify the identity and associated authority of the nodes in the system.

Disclosed herein are systems and methods for the creation and distribution management of new data structures that can allow for secure access restrictions. The novel data structure and associated functions are distributed databases that contain linked blocks that together form a chain, and in that each block contains a hash of past blocks in the chain that link two blocks together, It is based on the blockchain principle. However, this new data structure includes important new features and functions that allow private data subspaces within each block's data set, and these subspaces are only nodes that are authorized to access these subspaces. It is different from the conventional blockchain structure in that it is accessible and the copy of the block is propagated in such a way that the node generally only accepts the subspaces of the authorized node. For ease of reference, the novel data structures disclosed herein are referred to as “privately subspaced blockchains,” and recognize that these data structures differ significantly from traditional blockchains, as described in detail below. shall.

As disclosed herein, the novel data structure and its management allows the distribution of data payload (subspace) integrity so that multiple different nodes provide data sharing using data separation while maintaining a copy of a portion of the data structure. Provides the benefits of consensus-based verification. In particular, common reference data in a data structure is available to all authorized nodes, but a portion of the data payload (referred to herein as a “private subspace” in the data structure) is only available to nodes with sufficient access credentials. It is available. The present system and method also provides that data allowing read / write access is allowed as needed by a node having sufficient authority. The systems and methods of the present invention provide novel means for the secure and authorized transmission of these data structures between nodes, and for provisioning interconnections between nodes to facilitate such transmission, thereby providing specific data structures. The communication between nodes does not affect the system function or ability for processing communications between different nodes involving different copies of the data structure. The systems and methods of the present invention further provide an improved consensus mechanism for data structures that ensure isolation, which means that consensus failure between one pair of nodes does not lead to interlocked failure between the other pair of nodes. . The systems and methods of the present invention further provide an improved consensus mechanism for data structures that ensure continuity, which means that the data structure integrity is maintained even in the case of processing nodes that the system continues to properly process and cannot reach. . The system and method of the present invention further provide improved collision management and improved scalability between nodes so that deployment of additional nodes does not require significant updates to existing nodes. In addition, the systems and methods of the present invention further provide improved synchronization with external databases in a way that data can be verified.

The novel private subspace blockchain data structure and related systems and methods herein can be used in various situations where the above features and improvements are advantageous. For example, new data structures and related systems and methods include inventory management, parts tracking (eg tracking aircraft parts maintenance cycles), source verification for high value goods (eg diamonds), medical records, real estate and digital It can be used to implement secure exchange of data in relation to assets, transfer of ownership, secure document processing, and other areas and applications that benefit from a data structure that provides both distributed verification and authorized data storage and access. In addition, new data structures and related systems and methods can be used to implement security systems for smart contract applications, including those related to credit default swap (CDS), equity swap, and foreign exchange (FX) transactions. have.

According to one embodiment of the present invention, a system is provided for an encryption platform for distributing data structures within a peer-to-peer network, the system comprising a non-transitory computer readable storage medium; And a processor configured by executing one or more software modules comprising instructions in the form of code stored on the storage medium, the modules transmitting encrypted data between a first peer node and a second peer node from a remote device over a network. A communication module configuring the processor to transmit and receive, and a core module configuring the processor to generate a state route representing encrypted data exchanged between the first peer node and the second peer node, the core module comprising a plurality of The processor is further configured to create a global state route representing cryptographic data exchanged between peer nodes, and the core module is within a private subspace blockchain that provides identifiable records of data exchanged between the network and peer nodes. Authorized Block And a database module configured to configure the processor to store data propagated between the first peer node and the second peer node in a storage medium, wherein the database module includes a state root, global The processor is further configured to store the state route, and blocks, on the storage medium.

In another embodiment, a computer program product implemented on a computer readable medium for processing distribution of a data structure is provided, comprising: computer code for transmitting / receiving a plurality of encrypted messages between a plurality of peer nodes; And computer code for generating a plurality of state routes for the encrypted messages exchanged between the peer nodes. And computer code for storing multiple state roots within the global state root, where each state root defines a subspace of data-and a private subspace blockchain comprising a plurality of global state roots comprising a plurality of subspaces It contains computer code to generate.

In another embodiment of the present invention, an encryption system is provided for distributing a data structure among peer nodes in one or more networks built on top of a basic network, wherein the data structure comprises a plurality of global state routes, the plurality of The global state route of includes a plurality of state routes, wherein the encryption system comprises: a memory storing a plurality of authorized blocks in a private subspace blockchain; A state route generator that generates a state route based on encrypted messages exchanged between a plurality of peer nodes in the subspace; A global state route generator that creates a global state route based on one or more state routes; A block compiler that compiles the global state root and state root; And an allowed block generator that generates the allowed block such that the allowed block includes the global state route and one or more state routes.

In another embodiment, a system is provided for providing an encryption platform for distributing data structures within a peer-to-peer network, the system comprising data defining multiple global state routes for each of a plurality of blocks Cloud-based database-each global state route includes a plurality of state routes-and a network capable device for transmitting / receiving encrypted data for a plurality of peer nodes; A network capable device and a computer server connected to a cloud-based database, the computer server being programmed to encrypt data transmitted between a first peer node and a second peer node, the agent generating a subspace of information It is programmed to automatically generate a state route for data transmitted between the 1st peer node and the 2nd peer node, and is programmed to automatically update the global state route in response to the creation of the state route, along with a subspace of information. It is programmed to create a block that includes an updated global state route that includes a plurality of state routes, including a state route, and is programmed to store the block in the private subspace blockchain of the cloud-based database.

In another embodiment, a system and method for storing instructions corresponding to a private smart contract and executing such instructions in a virtual machine using a private subspace blockchain data structure is provided.

These and other aspects and advantages will become apparent to those skilled in the art by reading the following detailed description where appropriate in the accompanying drawings. In addition, it should be understood that the above summary is merely exemplary and is not intended in any way to limit the scope or scope of equivalents to which the appended claims are legally granted.

The patent or application file contains at least one drawing executed in color. A copy of this patent or patent application publication with this color drawing will be provided by the Office upon request and upon payment of the applicable fee. The invention is described below in connection with the following exemplary drawings.
1 is a diagram illustrating components of a system for the generation and distribution management of a data structure having secure access restrictions according to an embodiment of the present invention.
2 is a diagram illustrating components of a core module and a database module of the system according to an embodiment of the present invention.
3 is a diagram illustrating components of a peer or verification node according to an embodiment of the present invention.
4 is a diagram showing the contents of a block according to an embodiment of the present invention.
5 is a diagram illustrating two nodes exchanging encrypted data according to an embodiment of the present invention.
6 is a diagram illustrating a service node that requests data, checks authority, and verifies data according to an embodiment of the present invention.
7A and 7B are diagrams illustrating a node transmitting information in a subspace accessible to another authorized node according to an embodiment of the present invention.
8 illustrates an accessible subspace of data for three different nodes, according to one embodiment of the present invention.
9 is a diagram illustrating that a message exchanged in a subspace is added to a private subspace blockchain according to an embodiment of the present invention.
10 is a diagram illustrating creation of a state route and a global state route to be included in a block header according to an embodiment of the present invention.
11A to 11D are diagrams illustrating exchange of data including state routes from all subspaces, verification of data, and generation of blocks according to an embodiment of the present invention.
12A-G are diagrams showing a consensus process between nodes according to an embodiment of the present invention.
13 is a diagram illustrating verification of a node in an authorized network according to an embodiment of the present invention.
14 is an example of subspace verification mapping according to an embodiment of the present invention.
15 is a diagram illustrating a corresponding interaction of a component and a subspace of a smart contract to components, according to an embodiment of the present invention.
16A to 16E are diagrams illustrating application of a core module according to an embodiment of the present invention.
17A to 17C are views showing another application of the core module according to an embodiment of the present invention.
18 is a diagram illustrating the application of a system using ongoing rights management with automated physical connection and contract authority, according to one embodiment of the present invention.
19 is a diagram illustrating a relationship between a domain and a subspace for a private subspace blockchain according to an embodiment of the present invention.
20A and 20B are diagrams illustrating the use of a private subspace blockchain and related systems in implementing a mortgage backed security (MBS) pool.

The invention can be implemented in various forms, but for the sake of simplicity and illustrative purposes, the principles of the invention are partially described with reference to some embodiments thereof. However, it should be understood that the present disclosure should be considered as illustrative of the claimed subject matter, and is not intended to limit the appended claims to the specific embodiments shown. It will be apparent to those skilled in the art that the present invention may be practiced without being limited to these specific details. In other instances, well-known methods and structures have not been described in detail in order not to unnecessarily obscure the present invention.

1 shows a system 100 for creating and managing distributed distribution data structures and creating other distributed data structures with secure access restrictions, according to an embodiment of the present invention. The system 100 is built around a distributed network of nodes 112 communicatively connected to each other via a local area network (LAN) or a wide area network (WAN), such as the Internet, or a combination thereof. Each node can be implemented on one or more servers with logic to perform the functions described herein. The components of system 100 (eg, core module 104 and database 106) may reside on separate servers or on one or more servers. The core module 104 provides core functions of each node in the system. Each node with the core module 104 can interact with the database module 106, which can be located on a separate server. In addition to the functionality associated with the core module 104, each node may include functionality associated with the API 102 (as described further below), and hardware key management 108 for security enhancement. The core module 104 includes functions for providing creation, configuration and registration of nodes. After the node is created, the core module 104 initializes the node, connects the node to the integration tool (API) 102, and connects the node to one or more consensus nodes via a peer-to-peer network. The core module 104 configures a node based on the type of node (verification, peer, service) that determines the role of the node in the system 100, as described below. The core module 104 also configures the node by providing the node with information indicating which subspace the node can access based on an identifier that identifies the party or user creating the node. In certain embodiments, the identifier of the party or user can be associated with the node type and can be used to identify the node type. For example, as part of the registration process, the system maintains and distributes a table to each node that associates each party / user's identifier with a particular node type (verification, peer, service). Additionally or alternatively, the system distributes a table to each node that associates the node's unique node identifier with the node type (validity, peer, service). Additionally or alternatively, node registration is maintained using information maintained in a common subspace accessible by all nodes in the system, thus ensuring that registration data is consistent and available to all nodes. The node properties include a list of subspaces to which the node is authorized, and for each subspace, the level of access rights (for example, whether the peer has validator, peer, or service node access rights). In this way, nodes can have different levels of access to different subspaces. For example, one node at the same time may be a "validator" of one subspace and a "peer" of another subspace. Node registration can be managed in a specific script (eg, smart contract) executed in a common subspace. Changes to the registration data set are implemented by sending a message to a script in the common subspace, and the change is applied when the message requesting the change is confirmed in a block in the private subspace blockchain.

Each node stores type information that indicates the type of node (validation validity, peer or service), the role and behavior of the node in relation to the system 100, and the level of data access of other nodes on the network, such as the node and The main function is determined, as shown in FIG. 2. The verification node 202 can access all subspaces to which the node is authorized. The verification node is included in the consensus process for verifying blocks in the private subspace blockchain, as discussed further below. In particular, the verification node matches other nodes in a particular subspace with respect to valid messages and blocks. The verification node 202 also relays all received messages to the node authorized to receive those messages, and commits the message to blocks on the private subspace blockchain. Like the verification node 202, the peer node 204 can access any subspace to which the node is authorized. However, unlike verification nodes, peer nodes are observers who do not participate in the consensus process. For this reason, the peer node can be referred to as an observer node. In terms of functionality, peer node 204 also relays all messages received to the node authorized to receive those messages, but does not commit the messages and blocks to the private subspace blockchain. In addition, the peer node 204 and the verifier node each provide access to and interact with the external system. The peer node (like other nodes) is configured to maintain the enterprise database 208 as described below. In this regard, the enterprise database includes an expanded data set, and each node stores and aggregates data in the database 208 and database 208, such as the ability to efficiently query the database 208 according to the node type. Includes logic and programming to enable interaction with. In particular, the peer node has logic and programming that allows the node to query the database 208. The verifier node has logic and programming that allows the node to query the database 208 and store and aggregate data in the database 208 through events linked to smart contracts. In addition to the database functionality provided by database 208, API 102 provides an extension that allows system 100 to be integrated with external legacy systems with different data formats. For example, the API 102 may query data, such as for accessing data stored in an external legacy system in a data format different from the blockchain structure described herein, to import data into the enterprise database 208. For integrating such data into the system 100, for converting the data set into a format suitable for use with the blockchain structure described herein, and for converting data from the blockchain structure described herein. Functions and procedures may be included for export in a format suitable for use by an external system. In other embodiments, the verification node can also interact with external systems. The service node 206 can access a limited set of smart contracts within a specific subspace. Service node 206 also receives and relays a limited number of messages, but all messages in a common subspace.

3 provides a representation of a peer node or verification node 300 according to one embodiment of the present system, which illustrates the features and logic associated with each node. Each node has an interface for communicating with other network nodes and components of the system 100 via a LAN or WAN, internal logic for performing the functions listed therein, and internal storage for storing variables and data. While equipped, it may be implemented in one or more servers. Each peer node or verification node includes communication logic 302 for communicating with other nodes via a peer-to-peer (p2p) protocol, as described further herein. In the preferred embodiment, the nodes of system 100 use an extensible versioned binary encoding scheme such as recursive length prefix (RLP) to format messages for communication. Messages sent by the node are signed with a private key to verify the identity of the sending node and prevent spoofing. Each peer node or verification node is a remote procedure call (RPC) protocol that a node can use to send notifications to other nodes and system components, and to invoke the execution of procedures and subroutines on other system components. The API logic 304 for implementing is further included. In the preferred embodiment, the node uses the JSON-RPC protocol. Each peer node or verification node further includes consensus logic 306 used to implement the consensus algorithm used by the system to verify messages and blocks, as discussed further herein. According to one embodiment, the system uses a Raft consensus algorithm, but other consensus algorithms may be implemented by logic 306. In another embodiment, a byzantine fault tolerant (BFT) consensus mechanism is used. In other embodiments, the system verifies messages and blocks using a rotation agreement mechanism or federated signature. The consensus logic 306 also serves to process the message and add the verified message to the block. Each peer node or verification node further includes logic 308 for script execution that can function as a runtime environment for executing the script, including, for example, executing code associated with the smart contract. The logic 308 for script execution may be compatible with the Ethereum Virtual Machine (EVM) implementation. Each peer node or verification node further includes a data store 310 with associated logic for storing, retrieving and querying the data store. The data store 310 functions as a database repository of messages, blocks and related metadata. In particular, data store 310 includes one or more databases for long-term storage of system variables, such as private subspace blockchain data. The data store 310 provides each node with access to data for all subspaces to which the node is authorized. When the private subspace blockchain is associated with a smart contract, the data store 310 stores smart contract information and provides a quick fetch of such information for the node.

Service node 206 differs from peer and verification nodes in that it does not process all messages (for example, it does not execute all messages in the virtual machine) and does not maintain a complete state tree for each subspace. The service node may receive a subset of data in a subspace, process a message in a virtual machine, or simply receive data generated as a result of executing a script (eg contract data). For example, the service node receives all messages for a specific transaction (eg, a specific contract) or simply receives the latest status of the transaction data and cannot process the message. The service node 206 requests any part of the state tree from the verifier or peer node to which the service node is authorized. The service node may be authorized to receive all messages or a subset of messages in the subspace. This granular level of access is possible because the subset is defined by flexible filtering rules (eg, account transfer).

1, the client terminal 114 can access the functionality of the system 100 and the core module 104 through the use of a series of application programming interfaces (APIs), system integration tools 102. These APIs 102 allow the client terminal 114 to manage authorization of the client node, perform remote procedure calls (RPC), establish a connection with the node in the system network, manage client accounts with the system, Includes functional calls to manage the content of a data record (eg, smart contract) in the private subspace blockchain disclosed herein. In particular, these APIs 102 access the functionality of the core module 104 to create, configure and register nodes; Interact with the novel distributed data structures disclosed herein; Includes functionality that can be invoked by client terminal 114, which configures authorization and access to the system network. These APIs 102 are accessed by client terminals 114 that access the functions of database modules 106 to access data stored in database modules 106, manage such data, and perform queries on such data. It further includes functions that can be called. In embodiments where hardware key management is used, these APIs provide functionality that can be called by client terminals 114 that access the functions of the hardware key management module 108 to store and retrieve private keys and sign transactions. It includes more. The API of the integration tool 102 interacts directly with the private subspace blockchain. API commands that create or interact with data records in the private subspace blockchain generate a blockchain message and return a message hash value that can be used to identify the message, which can later be retrieved and viewed by system 100 users To make. The client terminal 114 can take a variety of forms. For example, client terminal 114 provides means for interfacing with API 102 by providing data to the API, calling functions provided by API 102, and displaying prompts and data from API 102. It can be a graphical user interface provided (used by end users). The client terminal 114 may be fully automated software that monitors external events that call functions through the API 102 when external events occur. For example, the client terminal 114 may be a matching platform that calls a ledger (also referred to as a 'leisure') function through the API 102 to match opponents in a trade.

Each node of the system 100 created by the core module 104 also stores specific information used by the node to interact with the system 100's network. This information can be stored in a node's data directory, in a database, or in a table structure. Each node stores its type (validation, peer or service). Each node of the system 100 further includes a name shared with other nodes of the system and displayed as a log file. Each node further includes a node identifier (or node ID), which is the full certificate of the node. Alternatively, a secure hash can be used to implement the node ID, so different certificate types and lengths can be used if the hash is a fixed length value (eg a fixed length 32 byte hash value). In this way, the permission agreement (or "chainperm" script as discussed further herein) stores only fixed-length values that can be efficiently managed on-chain without compromising security. You can do it. Therefore, in the case of node ID, the entire certificate of the node can be used, or a hash of the certificate (for improving efficiency and speed of processing on-chain data) may be used according to specific requirements for each distribution of the system.

In the preferred embodiment, the node of the system 100 uses a TLS authentication procedure, so the security certificate is a TLS certificate. This node ID uniquely identifies the node and is unique to the network. Each node further contains a signature address, which is a hash of the node's public key and is used to sign messages and blocks in the private subspace blockchain. The signature address information need not be present at the observer node (eg peer type node). Each node also contains an array of domain names where the node acts as a verifier and an array of domain names where the nodes act as observers. Before participating in the creation of blocks and messages, each node must have its own security certificate (such as a TLS certificate) and a signing key, which is stored in the node's data directory. In this regard, each node has two private keys-one private key for the TLS authentication procedure and other private keys to sign blocks and voting, in particular according to the block creation and voting process described herein, e.g. ECDSA Private key)-

1 and 2, the system 100 further includes a database module 106 that includes one or more databases 208 for storage of private subspace blockchain data. The database module 106 provides one-way synchronization from the private subspace blockchain to a common database format for storage. The database module 106 also allows auxiliary data to be added to the private subspace blockchain data. The database module 106 further performs complex data query and analysis on data stored in one or more databases. The database module 106 may reside on the same server as the core module 104 or may reside on a separate server.

The core module 104 further includes a function that provides creation of an account associated with the local node. Each account defines the identity of the user in the private subspace blockchain. In addition, when data stored within a block of a private subspace blockchain is associated with a smart contract or other self-executing / self-executing script, the account is used to identify actors in relation to the smart contract and / or script. The account is a unique identifier for sending and receiving messages and self-executing scripts (eg smart contracts). Each account is referenced by the address corresponding to the public key. Each account also has an associated private key that is used to sign and interact with scripts on the private subspace blockchain. The account further defines each user's ID in the private subspace blockchain. For example, when a private subspace blockchain is used to implement a smart contract, the account is used to identify the parties to the smart contract.

The core module 104 provides logic to provide a node with the functionality needed to communicate with other network nodes 112a-112d, including the ability to receive and relay messages and commit the message to a private subspace blockchain. It includes more. The communication network of the system 100 is set up as a peer-to-peer network, and there is a known identification for each node in the network. As described here, connections between nodes are authenticated using TLS certificates, and only nodes with TLS certificates included in the approved list can connect to the network. In a preferred embodiment, the core module 104 determines the subspace of the message or command based on the identity of the party / user that originated the message or command, and the identity of the other party / user. For example, if Party A sends a message or command and designates Party B as Party B for the message or command, the core module 104 determines that the message or command should be sent on the AB subspace.

4 provides a representation of block 400 in a private subspace blockchain, according to an embodiment of the present invention. Each block acts as a repository of data and contains links to previous blocks in the private subspace blockchain. Each block 400 includes a header 402 with status information used to verify the contents of the block. As described in more detail herein, the header includes a global hash value based on one or more basic hash values corresponding to subspaces and other data in the block. In a preferred embodiment, the global hash value is the state root of the hash tree, such as the Merkle tree, and the base leaf of the tree represents the subspace. The header also contains the message root, which is a summary of all messages contained in the block, and is updated based on events triggered by the contents of the private subspace blockchain. Each subspace contains, in addition to the status root of the subspace, the message root of the subspace, the receiving root, and the amount of "gas" used for execution (ie, the number of computational steps to execute the transaction). The message route and the reception route are tree root hashes that are updated based on events triggered by the addition of messages and receptions, and are based on data included in the corresponding message and reception. For example, the message root and receive route are calculated Merkle tree root hashes by adding all the messages (or receiving messages in the case of a receive route) that the block identifies a subspace of the Merkle tree structure, and by getting the root value. Can be The header further includes an encrypted signature used to verify the block. Each block further includes a data payload divided into one or more subspaces, for example subspaces A, B, N. These subspaces are separate areas in the shared blockchain that only a defined subset of users can access and add. In this way, the subspace creates a private area where participants can store records and data that only authorized participants receive. A subspace is unique to and protected by the subspace. A set of data records, such as logic (such as self-executing scripts, smart contracts) and data sets (such as messages and receipts), protected by access rights so that only nodes that have permission to access that subspace are accessible ) Is included. Each subspace can only access nodes authorized to that subspace, and can contain a single party, multiple parties, or all parties in the network. In this regard, the private subspace blockchain of the present invention is quite different from traditional blockchain implementations that rely on public visibility of the contents of each block to ensure the validity and integrity of the blockchain. The private subspace blockchain's subspaces can be separated based on specific transactions (e.g., credit default swap (CDS) between two parties), or can access these subspaces as described further herein. It can be separated based on the parties. For example, each subspace can store a series of transactions between a group of parties, and the message list of the subspace provides a complete history of those transactions. Only the transaction party has the authority to access the subspace corresponding to the transaction, and when messages and transactions are propagated by the system, only the node corresponding to the party receives the contents of the corresponding subspace. In this regard, data stored in these subspaces are stored in separate databases and can be individually synchronized by nodes in the network.

In one embodiment, the data of the subspace is organized by account. Accounts are referenced by address, message nonce (a random or pseudo-random number used to uniquely identify something, in this case a message record), scripting code or "byte code" (eg smart contract code), and account on storage Has any key-value pair that can hold. There are two types of accounts: (1) user accounts and (2) script / smart contract accounts. User accounts are accounts that users use to send messages to the system. The user account's address is derived from the user's public key. The user account has no associated byte code or key-value pair. The script / smart contract account, on the other hand, has a scripting code / byte code and can store key-value pairs to hold data. The address of the script / smart contract account is derived from the address and nonce of the generating account, but there is no private key that matches the address of the script / smart contract account (public key). In this arrangement, the user cannot send a script / smart contract message to the sender account.

8 provides another representation of block 800 in a private subspace blockchain showing the arrangement of subspaces in the block's payload, according to one embodiment of the present invention. In addition to the block header 802, as described above, the block 800 includes a plurality of subspaces divided based on the parties accessing the subspace. The subspace includes single-party subspaces 804 to which only a single party is authorized and has access to data, which includes subspace 804a corresponding to Party A, subspace 804b corresponding to Party B, and Party Subspace 80c corresponding to C is included. Records or transactions related to a single party, such as stock purchases on a stock exchange, commodity trading or medical records, can be included in a single party subspace. The subspace of block 800 further includes a bilateral (also referred to as 'quantum') subspace 806 to which the two parties are each authorized and have access to the data. In the illustrated example, these subspaces are quantum subspaces 806ab corresponding to parties A and B, quantum subspaces 806ac corresponding to parties A and C, and quantum subspaces 806bc corresponding to parties B and C. It includes. Quantum subspace 806 may include records or transactions involving two parties, such as credit default swap or equity swap. The common subspace 808 includes reference data, a service node permission list, a node ID of each node of the system 100, and an identity directory (or peer registry) providing types and permissions corresponding to each node, and access by nodes. And other information and scripts for general use by all parties and nodes in the system, required by the node to perform authorization decisions. The transaction manager provides a message scheduling service so that a user can schedule a message to be automatically executed later or when a specific event occurs. This message scheduling service function may be provided by other components. The message scheduling service can be used, for example, to automate payment of coupons for a transaction contract (time trigger instance), or to change the name of a reference entity in the transaction contract when the entity name is updated in the entity registry (event trigger) Instance). The common subspace may further include script / smart contract byte code, application binary interface (ABI), smart contract factory, database configuration information, and other domain or subspace status information. Additional subspaces are possible that include different combinations of one or more parties. For example, as shown in FIG. 19, multiple subspaces may be included in a given domain. For example, a quantum domain can access two parties (eg, Party A and Party B), both of which will act as validators for that domain. Within the domain, both parties can access all subspaces of the domain (the parties' true private subspaces are located in separate, private, domains for privacy). Within a domain, different subspaces can be used to specify separate record groups or separate transactions. For example, in a bi-directional domain, multiple subspaces can be created to process transactions of different asset classes, each subspace corresponding to a different asset class, and the parties handle these transactions individually and independently. And make it traceable.

Similar to blocks in traditional blockchain data structures, data records in each subspace are combined with keys based on data (such as hash values) (such as data corresponding to a particular transaction between the parties). Includes data and links to previous data records in the subspace. Subspaces allow nodes to reliably synchronize data and validate data, while isolating data sets associated with other users. In addition, the use of subspaces allows system 100 to provide simultaneous processing of messages in different subspaces. In a traditional blockchain, messages and transactions must be processed sequentially to maintain the integrity of the blockchain. Subspaces in the private subspace blockchain allow simultaneous processing of messages and transactions in different subspaces, and require that only messages in the same subspace be processed sequentially. In order to process messages in the virtual machine, the node must have access to all accounts associated with each message that are each up-to-date (for example, smart contracts including bytecode and storage). Therefore, because the transaction status can be changed for each message, messages in the same subspace must be processed sequentially, which can affect the result of subsequent message execution. In other words, messages can make specific calls to certain different subspaces, thus creating additional requirements for data access. For example, a message can make calls to a common subspace and other subspaces in the domain.

Each copy of the block maintained at the party's node reflects the privacy and access restrictions created by the subspace. In particular, the node of the party includes a copy of the block that contains only the data from the subspace to which the party and node are authorized. As shown in the example of FIG. 8, the copy of block 800 maintained on Party A node contains only data located in a subspace to which Party A is authorized and accessible, where Party A node is a single party sub Means to include a copy of block 800 that contains data from space 804a, both subspaces 806ab and 806ac, and common subspace 808. Party A node means that Party A does not have data from an unauthorized subspace, so Party A node does not have any data from either subspace 804b or 804c, or both subspaces 806bc. . Likewise, the copy of block 800 maintained on the Party B node only contains data in the subspace to which Party B is authorized and has access, and does not include data in the subspace to which Party B is not authorized. , This includes a copy of block 800 where Party B node contains data from single party subspace 804b, quantum subspaces 806ab and 806ac and common subspace 808; This means that there is no data from the single-side subspace 804a or 804c or both-side subspace 806ac. Similarly, the copy of block 800 maintained at the Party C node only contains data in the subspace to which Party C is authorized and has access, and does not include data in the subspace to which Party C is not authorized. This includes a copy of block 800 where Party C node contains data from single party subspace 804c, quantum subspaces 806ac and 806bc, and common subspace 808; This means that it does not have data from either one side subspace 804a or 804b or both side subspace 806ab. Because the node does not receive data for sub-authorized subspaces, the subspace remains completely private and there is no risk of accidental disclosure of data to parties or nodes that cannot access this data.

9 is a diagram illustrating the creation of a block in a private subspace block chain based on an update to a subspace, according to an embodiment of the present invention. Initially, nodes in the network from Party A and Party B exchange messages 912 and 914 related to the transaction between the two parties, resulting in status AB2 for a series of transactions. Similarly, Party A and Party C exchange messages 926 regarding transactions between them, generating status AC1 for transactions between these two parties. After consensus and verification of these messages, a new block 902 of the new private subspace blockchain 900 is created as a secure record of these transactions and related information. The private subspace block chain 900 and the blocks therein have two bidirectional subspaces: subspace AB 908 corresponding to transactions between parties A and B, and sub corresponding to transactions between parties A and C. Space AC (910). Block 902 records messages 912 and 914 in subspace AB 908 and message 926 in subspace AC 910. In a preferred embodiment, each message in a particular subspace is stored in a subspace in a block form based on the blockchain principle, where each block in the chain has an associated hash value, and the current block using the hash value of the previous block Create a link between blocks by calculating the hash value of For example, the first message 912 is stored as a first block in the blockchain corresponding to subspace AB 908, and the second message is subsequently recorded in the blockchain. More specifically, messages in a particular subspace are stored in the subspace in the form of a private subspace blockchain, as disclosed herein, which may have additional subspaces (also in the form of a private subspace blockchain). In addition, state route AB2 908a is generated based on the message stored in the AB subspace (consisting of messages 912 and 914 at this point). The state root is a state key based on the data in the subspace, and is usually a hash value that is the result of a hash function performed on the data in the subspace. For example, the state root for each subspace can be the root of a hash tree, such as a Merkle tree; These state roots can be part of a larger hash tree that includes state roots for all subspaces, as discussed further herein. Similarly, state route AC1 910a is generated based on the message stored in the AC subspace (consisting of message 926 at this point). These state routes are created by leader nodes within a specific subspace to incorporate into the block header as described in more detail herein. In this way, the block contains status information most recently submitted from each subspace. Also, and as discussed further below, before being included in a block of a private subspace blockchain, an agreement is reached between verification nodes for each individual message or transaction within a given subspace. Each individual message must go through a consensus process so that the results are always predictable and reliable. This is because the validator node cannot reliably determine the order of messages received.

The creation of a new state route for the subspace in the block is also updated with the global state route for the block. This is because the state root for the subspace is used as input to the hash function resulting in the value of the global state root. 10 shows how the state root of a subspace affects the value of the global state root for a block. Similar to the block of FIG. 9, block 1000 of FIG. 10 includes two subspaces, subspace AB 1012 and subspace AC 1014. Each of these subspaces has a state route: AB state route 1004 and AC state route 1014, respectively. If there are no additional subspaces within a particular subspace (effectively, "subsubspaces"), the state root of a particular subspace can be a hash value for the latest block in the chain. If a subspace has one or more subspaces within it (i.e., multiple subsubspaces), the state root for the subspace is based on the hash tree, such as the Merkle tree, based on the value of the state root of the one or more subsubspaces. It can be the root. In this way, each subspace is a recursive data structure element, and may be composed of a hierarchical structure of a blockchain structure as shown in FIG. 10. Subspace AB 1012 has a number of subspaces 1008 therein, and the state roots of these subspaces act as inputs to a hash function that creates AB state route 1004. Similarly, subspace AC 1014 has multiple subspaces 1010 therein, and the state roots of these sub-subspaces act as inputs to the hash function that creates AC state route 1006. The subspace's validator node can either approve or reject the subspace's status root.

As shown in the example of FIG. 9, subsequent messages 916 and 918 are generated in relation to transactions in the AB subspace, resulting in a new state root AB4 908b for the AB subspace 908. Created and verified before these messages and new state routes are stored in the new block 904 of the private subspace blockchain 900. Similarly, a subsequent message 928 is generated for the transaction in AC subspace 910, thereby creating a new state root AC2 910b for the AC subspace. Message 928 and the new state route 910b are also verified before being stored in block 904. As further shown in FIG. 9, as additional messages (messages 930 and 932 in AB subspace 908, and 930 and 932 in AC subspace 910), correspondingly updated status routes (AB subspace 908 ) 'S state route AB6 908c and AC subspace 910's state route AC4 910c) are created, and these additional messages and state routes are verified and added to a new block in the chain (e.g., block 906 ). This process continues and additional blocks are added to the private subspace blockchain 900 as additional messages are exchanged in the subspace.

In a preferred embodiment, new blocks are created at fixed time intervals based on the most recently submitted status information from each subspace. As an alternative, a new block can be created based on the message exchange. For example, a new block may be created whenever a message related to a subspace in the private subspace blockchain is transmitted. The creation of a new block for a new or existing blockchain may also be triggered based on other events, including events outside the system 100.

The creation block, which is the initial block of the blockchain, is generated according to the same configuration file for all nodes on the blockchain. Unlike all other blocks, the generation block is unsigned and can contain any number of unsigned messages. For example, in the case of a “public” domain with a “common” subspace, the creation block deploys a dedicated script or smart contract for permission management (such as a “chainperm” script) and a verifier on that dedicated script or smart contract. Contains a message that registers the initial set of nodes.

The system uses a distributed consensus algorithm for private subspace blockchains. The algorithm is designed with strong cryptographic protection against malicious actors and uses Byzantine Fault Tolerance (BFT) protection. According to a preferred embodiment, the consensus algorithm functions as follows. First, a node that is authorized as a validation node in a subspace selects a leader node. The leader node then serves to inform the remaining validation nodes in the subspace of messages and blocks, which act as follower nodes. The follower node responds to the reader with a cryptographic signature type of approval to sign off new messages and blocks. When the relative majority (more than 50%) of the follower nodes approve, the leader node informs the follower node of the validity of the new message or confirmation of the new block. Other nodes in the network that do not participate in the consensus process can verify the signature in the message or block in an unreliable way that the message or block has been approved by a relatively large number of verification nodes.

11A-11D provide examples of message propagation and verification processes for subspaces, and subsequent block generation processes, according to embodiments of the present invention. 11A shows the generation and communication of an initial transaction creation message. In the example shown in FIG. 11A, the party node representations 1104, 1106 and 1108 represent a cluster of nodes managed by the party, in this case party A, party B and party C, respectively. The cluster of nodes 1104, 1106, 1108 and service node 1102 are communicatively connected via a peer-to-peer communication network. The service node 1102 transmits a transaction creation message for a transaction between Party A and Party B. The transaction creation message includes a transaction condition, may take the form of a self-executing script or a smart contract, and further includes an associated subspace identifier, in this case AB subspace. In particular, because the party C is not authorized in the AB subspace and therefore cannot access transaction information on the AB subspace, the service node 1102 does not send a transaction creation message to the party C cluster of node 1108, and the node ( Party A of 1104 and Party B clusters of node 1106 do not propagate transaction generation messages to Party C clusters of node 1108, as further described herein. As a result, the party C cluster of the node does not receive the transaction creation message and does not recognize the transaction creation message.

11B and 11C, each message is propagated to all verification nodes in the authorized network on the associated subspace to facilitate the verification and block creation process. First, the service node sends a message to all validation nodes connected to the authorized service node in the relevant subspace of the message. 11B, service nodes 1110 and 1102 are non-verifying nodes used as entry points for sending messages. Service node A 1110 receives a transaction creation message from service node 1102, and identifies that the message is related to the AB subspace. Consequently, service node A 1110 propagates the message from service node 1102 to all verification nodes with an AB subspace. The identification of the verification node for a particular subspace can be contained within a block in the private subspace blockchain or managed by a script or smart contract located in the private subspace blockchain. For example, in one embodiment, a dedicated script or smart contract (eg, "chainperm" script) for managing rights is placed in a common subspace of the generation block. To authorize the node, the message chainperm contract with the name of the new node, the Public Transport Layer Security ID (TLS-ID), the public signing address, and a list of domains and subspaces that the node can access and / or verify. Is sent to. Validator permissions are granted at the domain level, and observer (non-validator) access can be granted at the subspace level. Suppose that all nodes that allow connections to other nodes can access and verify the chainfirm contract, at least because they have access to the "common" subspace. Since data in the blockchain ensures that all nodes in the network are synchronized, all nodes view the chainperm contract at a consistent time and accept / deny node connections accordingly. In the example shown in FIG. 11B, the server nodes are nodes Al 1112a and A2 1112b in the Party A cluster of node 1104 and nodes B1 1114a and B2 1114b in the Party B cluster of node 1106. ) As a validation node for the subspace. Again, the Party C node does not receive the message because it is not authorized in the AB subspace.

Second, after the message is propagated by the server node from the associated subspace to the authorized connected verification node, the verification node proceeds with the verification of the message through a consensus process, such as the Raft Consensus Protocol, but other consensus algorithms, such as rotation leader mechanisms. This can also be used. As shown in FIG. 11C, the randomized process is used to select a leader node, ie node A1 1112a, for the consensus process. The elected leader proposes the message received for voting by all other verification nodes to which the authorized leader is connected in the subspace. In the illustrated example, leader node A1 1112a is another verification node in the authorized subspace, that is, node A2 1112b of party A cluster of node 1104 and node B1 1114a of party B cluster of node 1106. ) And B2 1114b to propose a message received from the service node 1102 for voting. At the end of the voting period (determined by a specific consensus protocol and can be determined by a certain amount of time elapsed (timeout) or by receiving voting from all or a sufficient number of voting verification nodes), and a sufficient number of votes Assuming that it has been received, the status route is submitted to be included in the block header.

If the status route for the subspace is approved to be included in the block header, an updated block for the network can be created. According to one embodiment, one of the verification nodes for the system is randomly selected as a leader for the generation of blocks. All subspace leaders then submit their respective state routes to the block leader. In the example shown in FIG. 11D, nodes in a party C cluster of node 1108 (eg, node C1) are randomly selected as a leader for the creation of the block. Thus, all subspace leaders, such as AB subspace leader A1 1112a, submit each selected state route to a block leader, ie node C1 of the party C cluster of node 1108. As a block leader, node C1 combines the state routes from the subspace to determine the global state route and the updated block header, and requests approval of the updated block header from the network's follower node. The follower node compares the updated block header of the block leader with its own determination of the block header, and indicates approval for the block leader. Upon approval, the block leader (node C1 in this example) creates an official block in the private subspace blockchain, consolidating state routes from all subspaces.

12A-G provide further detailed examples of the consensus process according to one embodiment of the present invention. As described above, the entire system typically includes multiple domains and subspaces as shown in FIG. 19. Each domain contains one or more subspaces, and each subspace is included in exactly one domain. Each domain has its own private subspace blockchain starting at the genesis block. The consensus process is executed for the domain. In this sense, the subspace does not have a leader node or a follower node directly, but the domain containing the subspace has a leader and follower node. Each domain has its own set of validator nodes. One validator node can validate one or more domains. However, the consensus process runs independently for each domain. In other words, the validator node that validates the two domains runs two separate instances of the consensus process. As a result, the validator node can "win" leadership in one domain, but can act as a follower in another domain. In the preferred embodiment, there is only one implementation of the consensus process, which is the same for all domains.

In a preferred embodiment, the consensus process used by the system is a Byzantine Fault Tolerance (BFT) raft consensus process as shown. This process includes an election process and a verification process to determine the leader. 12A-C illustrate the election process according to one embodiment of the present invention. As shown in this example, there are five verify nodes A-E (nodes 1202, 1204, 1206, 1208 and 1210) that verify messages and transactions for a given subspace. There are no leader nodes at the beginning of the process, and all nodes are considered followers. Each follower node waits for a random amount of time (“timeout”) before attempting to start an election and designating itself as a candidate node requesting a verification vote from another verification node. As shown in FIG. 12B, node A 1202 reaches the timeout before another verification node (or before receiving a request for a verification vote from another verification node), becomes a candidate node, and sends the request. The candidate node sends a request to each connected verification node that is authorized in the associated subspace to request a confirmation vote or a “yes” vote. The timeout of each node is randomized over a sufficiently long period of time (depending on network latency conditions) to optimize the probability that only one node will be first candidate. Each node sends an acknowledgment vote or a “yes” vote to the candidate node with the request being received first. In other words, each follower node votes which candidate first contacts the follower node as the election request. Candidates with a sufficient number of votes are elected leaders. Election success requires a relatively large number of followers to vote. In addition, to ensure the integrity of the voting process, all verification procedures, followers 'votes are signed by the node generating the vote, and the validity of all followers' vote signatures is verified. After a follower vote is sent, a candidate with a sufficient number of confirmation votes sends a message to the follower, confirming the election results and confirming that he has been elected leader. 12C, node A 1202, which has timed out and has sent a voting request prior to any other follower node, has four follower nodes B 1204, C 1206, D 1208, and E ( 1210) A confirmation vote is received from each. Node A 1202 verifies the signature in the vote, and after verifying the vote, sends a confirmation message to the four followers nodes confirming the election result that identifies Node A 1202 as the leader, and accordingly The follower node stores information that node A is the current leader. If there are no transactions, the elected leader sends a regular heartbeat message to all followers at fixed intervals. As long as a valid periodic message is received from the selected leader node, the node remains a follower. If the current leader does not respond and fails to send a periodic heartbeat message, a new leader election is held to obtain a new relative majority vote.

If a leader is elected among the verification nodes for a specific block or a specific domain, the nodes can continue the transaction verification and block generation process within the subspace. Fig. 12d-g illustrates the consensus process according to one embodiment of the present invention. After selecting a leader node, all follower nodes recognize which node is the leader node of a particular block or subspace. The leader is responsible for creating a block at the end of each consensus "condition", where each consensus condition lasts only for a certain period of time (eg somewhere between 1 to 3 seconds, preferably 2 seconds) or in the system. It can only last until a certain event occurs. During each condition, the leader is responsible for pre-committing transactions and messages to subspace data. At the end of the condition, pre-committed transactions and messages are approved by the follower, where the official block is completed and committed to the private subspace blockchain. 12D, after the election, all follower nodes recognize that Node A 1202 is the leader of the confirmed election. When a message is received by a node, the message is propagated by that node according to the peer-to-peer message propagation described herein. For example, as shown in FIG. 12E, Node B 1204 receives a message indicating a particular transaction (Tx 1) and sends the message to all other nodes in the system (Node A 1202, Node C 1206). , By responding to node D 1208 and node E 1210. The nodes A, C, D and E in turn propagate messages to all other verification nodes in the network, including the selected leader node A (12012). Upon receiving the propagated message, the leader node sends a message to all follower nodes requesting approval, pre-committing the message to the private subspace. Each follower node examines the message in the approval request from the leader node, and the follower node sends an approval message to the leader node. The message is authorized to be pre-committed by the follower node if it meets certain criteria to ensure that the message is valid, including the appropriate signature and appropriate nonce value. In the preferred embodiment, if the message is (i) correctly formatted (complies with the message structure defined by the p2p protocol), (ii) signed, and (iii) has a nonce value equal to the expected nonce of the sending account, the follower It is authorized to be pre-committed by the node. When a relative majority of the follower nodes send an acknowledgment for pre-commit, the reader pre-commits the message to the subspace. The number corresponding to a relatively large number of follower nodes is determined by the number of nodes authorized to access the common subspace. As shown in the example of FIG. 12F, reader node A 1202, which has received the message indicative of transaction Tx 1, sends a message to all follower nodes requesting approval to pre-commit the message to the associated subspace. The follower nodes 1204, 1206, 1208, and 1210 determine that the Tx 1 message sent by the leader node A 1202 is valid, and the leader node A 1202 approves to pre-commit the Tx 1 message to the subspace. To send.

The leader node continues to receive, acknowledge and pre-commit messages according to the above process until the condition is over. When the condition is over, the leader node creates an official block containing all the pre-committed messages, and sends a copy of the block with an approval request to all follower nodes. When the leader node receives an acknowledgment message from a relatively large number of follower nodes, the block is completed and committed to the private subspace blockchain. A new condition begins immediately after the block is completed and added to the private subspace blockchain. The leader may serve for a number of conditions, or may be elected at the time of each condition. The condition number is incremented with each election. The block does not terminate the condition. Thus, a leader is elected for a single condition, but if you keep making blocks, you can act as a leader for multiple hours / dates / weeks. If there is a re-election, the condition number is incremented for each election round until a new leader is determined. The new leader may be the same as the previous leader. As shown in the continuous example of FIG. 12G, during the period, the leader node has received and pre-committed the messages corresponding to transactions Tx 1, Tx 2 and Tx 3 (after approval from the follower node). Upon expiration of the condition, the leader node A creates a formal block and sends it to the follower nodes Node B 1204, Node C 1206, Node D 1208 and Node E 1210 for approval. When leader A receives an acknowledgment message from a relatively large number of follower nodes, it commits the block to the private subspace blockchain. Then, a new condition is started as the subsequent message is pre-committed to a new block.

As mentioned elsewhere in this specification, node permissions are per subspace. In particular, the number of verification nodes may be different for each subspace. For example, as shown in Figs. 13 and 14, a node's peer-to-peer network according to the present invention may include a number of verification nodes corresponding to several parties, but a node is authorized to serve as a verification node. It can be different in terms of space. As shown in FIG. 13, the Party A cluster of the node 1300 includes the node AO 1300a, the node A1 1300b, and the node A2 1300c, which are verification nodes; The party B cluster of node 1302 includes node BO 1302a, node B1 1302b, node B2 1302c, which are verification nodes; Party C cluster of node 1034 detects nodes (CO) 1304a, node C1 1304b, node C2 1304c, which are verification nodes, all of which access system network 1308 And communicate with each other based on their type and authority. However, as shown in Fig. 14, the nodes are all verification nodes, but the subspaces permitted as verification nodes are different. For example, node AO 1300a is allowed as a verification node only in subspace A 1408, AB 1400 and AC 1402, but is not a common subspace 1406 (node AO is allowed as a peer node for the common subspace). Can, but thus access the data in that subspace). As another example, node B2 1302c is allowed as a verification node in B-only subspace 1410 and common subspace 1406 but not AB subspace 1400 or BC subspace 1404 (node B2 is AB And as a peer node for the BC subspace, but can thus access data in that subspace). However, in any implementation, less than 3 verification nodes for a subspace are not optimal, which is acceptable because using only 2 verification nodes in a subspace does not equally vote for 2 verification nodes in the approval process. This is because it carries an unprecedented risk of failure.

As can be seen from the above discussion of adding blocks to the private subspace blockchain, these distributed data structures grow relatively large over time and as the number of messages and blocks in the private subspace blockchain increases. You can. Unlike the traditional blockchain structure, the private subspace blockchain disclosed herein can be reduced in size through a new pruning process as disclosed herein, and this pruning process is a private subspace blockchain Ensures the ability to maintain data integrity, verify data and maintain the consensus process. Eliminating (pruning) the private subspace blockchain significantly reduces the memory required for the data structure, saving hard disk space and improving the efficiency associated with data storage. In addition, organizing private subspace blockchains allows parties to comply with data retention and destruction policies that are not possible with existing blockchain structures.

The pruning process described herein is triggered based on predetermined criteria, such as time-based criteria. For example, a private subspace blockchain can remove messages and blocks after a certain period of time, such as 2 or 3 years after message creation. This time may be determined according to the regulatory policy or the party's own data retention policy. The predetermined criterion for initiating the pruning process to delete messages and blocks can be implemented in subspace units, which means that each subspace can have its own policy and criteria for pruning. In addition, different parties can utilize different policies and criteria to clean up the private subspace blockchain maintained by the party nodes and data stores. In a preferred embodiment, in each case, the pruning policy and criteria that trigger the pruning process are the private subspace blockchain itself, for example, in a self-executing script or a smart contract implemented in the private subspace blockchain. Is maintained at. The core module 104 of the system 100 manages the removal process. The core module 104 retrieves the pruning policies from each private subspace blockchain and monitors criteria that trigger the pruning process according to these policies. Once the criteria are met, the core module 104 preserves a hash of the blocks and messages (such as the state roots of the various subspaces in the block) while at the same time identifying a set of messages that can be removed (pruned). Pruning process is implemented by deleting blocks and messages based on criteria or filters. For example, the removal process can remove blocks and messages from a specific contract or set of contracts, or blocks and messages past a specified retention date. During the cleanup process, all hash values are maintained, so the consensus process is not affected. However, when I try to access the deleted blocks and messages due to the removal process, I get an error indicating that the data has been removed.

The pruning process provides for the removal of data from the state database (eg, Merkle Tree), which enables compliance with data retention policies and space savings as described above. Each data object (e.g., each instantiated smart contract) exists as an object in its state database. When removing objects for data retention policies or other reasons, the system should ensure that the state root of the tree does not change, at least for reasons other participants may implement different data retention policies. To maintain agreement between the parties with different data retention policies, removing the object from the database does not change the state root of the tree. In order to remove data while ensuring consensus is maintained, the pruning process described herein is the same root hash as if the object was in place when all neighbor tree nodes hashed all the way to the root (e.g., Merkle tree hashing). It is guaranteed to be calculated as if. In this regard, to remove an object, the system maintains a data object tree node, but removes all payloads from the object. What is persisted is the address of the data object and the hash of the tree node. Also, the data object is marked as "cleaned up" or the payload is removed. When accessed, the data object of the form is identified as "removed", so the system can differentiate between the data object that does not exist and the data object that has been removed. After the cleanup process, the information held in the object (eg, the address and hash of the data object) does not allow recovery of the original data payload.

In one embodiment, additional information is embedded in the tree node of the data object to prevent recovery of the removed data payload. In certain situations, simply deleting the data payload can cause the data object to fall into an attempt to neutralize the effort to restore the data, such as guessing the value removed until a matching hash is found. For example, if the blockchain is only used for one contract type and the only field in the contract is a date and value, an attacker could create a tree node that matches the contract bytecode with all reasonable date and value combinations until a matching hash is found. have. To protect against such attacks, salts (i.e., random data used as additional input for hashing information) are embedded in each tree node of each private subspace blockchain, so that even if all non-random data is known, it is indiscriminate Substitutions and random guess attempts can make it more difficult to attempt to recover the removed data.

5 provides an example of a secure communication process between nodes in the network of system 100. In a preferred embodiment, system 100 uses Transport Layer Security (TLS) functionality for authentication and identity management. The secure communication process includes a two-way authentication procedure, where the node accepting the connection (accepting node) verifies that the credentials of the connecting node (the connecting node) are approved (e.g., security certificate), and the connecting node is eligible for the accepting node. Verify that the proof has been approved. In the preferred embodiment, the bidirectional process requires that the accepting node confirms that the TLS certificate of the connecting node has been approved, and that the connecting node confirms that the TLS certificate of the accepting node has been approved. Before the node is successfully authenticated and communicates with other nodes on the network, a hash value of the node's security certificate (eg, TLS certificate) must be registered in the system 100. In one embodiment, each node's certificate is registered by the core module 104 of the peer registry 512, 514, with each node maintaining a copy of the peer registry. In this registration, the security certificate must be associated with the node type (validation, peer or service) so that each node's TLS certificate is registered as being associated with a specific role. As shown in FIG. 5, when establishing a connection with another node in the system network, Node A, which is the first node 502, can first communicate with the TLS module 514 of Node B, which is the second node 508. Through the use of the connected TLS module 504, a TLS handshake procedure is performed. The initial exchange and verification of TLS certificates is according to the TLS protocol specification. As part of the handshake process, in addition to or alternative to the TLS protocol specification process, Node B provides an identity in the form of its digital certificate, the TLS certificate. Node A verifies the validity of Node B's TLS certificate by checking whether the TLS certificate is registered in peer registry 512. Additionally or alternatively, the node can self-sign without using a signing authority.

The system 100 implements a second verification step that checks whether the TLS certificate is approved in the peer registry (eg, "chainperm" script or contract). This is done only after the TLS certificate exchange is completed and before the connection is used for blockchain purposes. Referring to FIG. 5, the peer registry 512 corresponds to a dedicated script or smart contract (eg, "chainperm" script) for managing rights. When the TLS certificate returned by Node B is registered in the peer registry 512, Node A, the connecting node, determines that the TLS certificate of Node B, which is the accepting node, has been approved, and accordingly Node A 502 receives the session key. Based on this, the data is encrypted, and the data and its TLS certificate are transmitted to the Node B 508 via the network 510. Node B verifies Node A's TLS certificate by checking whether the TLS certificate provided by Node A is out of registration in peer registry 514 through the use of TLS module 506. If the TLS certificate returned by Node A is registered in the peer registry 514, Node B, the accepting node, determines that the TLS certificate of Node A, which is the connecting node, has been approved, and accordingly Node B 508 interprets the message. To retrieve the data in the message and process the data accordingly. This secure communication process provides significant advantages over previous systems because the Transport Layer Security (TLS) function is used for authentication of the system as well as encryption.

Through the connection process, the node also determines the type of each connected node. As discussed above, each node is registered with a specific type (validity, peer, service) in the system, and each node can be granted different node types for different subspaces and domains. This property is maintained in a dedicated peer registry (eg "chainperm" script). Specifically, the system maintains and distributes a registry that associates each node's unique identifier with a type to a node in the network. As described above, the unique identifier of each node is derived from the corresponding TLS certificate. When a connecting node connects to another node in the system, the connecting node obtains the TLS certificate of the other node in the system, and based on the TLS certificate and information maintained in the registry, the connecting node determines the related type of the other node. As a result, each node determines the connected verification node, connected peer node, and connected service node. The type of each node and the type of node connected to it affects how the node processes messages in the system. Nodes registered as validation nodes automatically participate in the block and message validation process, but delete validation peer-to-peer messages received from observers or service nodes. Also, a node that receives a message and a block that requires consensus will send the message and block only to a node that has been authenticated as a validation node.

As mentioned above, permissions-or actions that a node can take in relation to other nodes and data in the network-are grouped into subspaces, for example, one node can be a verification node for one subspace This means that it can be a peer node on another subspace. In particular, a node can have a series of subspaces that can verify to participate in the consensus voting and block-forming signature process. In addition, a node can have a set of subspaces that can be viewed as peers to participate in passive fetching of blocks and messages. And the node can have a specific set of subspaces where the node is only allowed to connect to the service node (or API client), so the node does not participate in consensus or engage in active or passive activities with respect to blocks and messages. In this regard, the node is permitted to originate only blocks and messages in subspaces that are authorized to perform validation, serving or role with the service node / API client. According to the system, the initial block of each authorized blockchain, referred to as a generation block, contains a set of initial verification nodes for each subspace within it. The generation block may further include a list of peer nodes and service nodes for each subspace. Thus, the identified node set for each subspace and its role (and permission level) remain on-chain and are used to determine the actions that the node can perform for each subspace. The identified node set and corresponding role (and permission level) for each subspace can be updated with specific messages.

6 provides an example in which a node with limited access and authority, such as a service node, can participate in an untrusted verification process. The service node 602 requests information regarding data in a specific subspace, such as a specific smart contract 608, for example. First, the service node 602 establishes a secure connection with the server node 606 (which may be a peer node or an affinity verification node) through the TLS gateway 604 and then creates a request for the data 604. The server node 606 handles the request by resolving the request from the service node 602 and first checking 616 whether the service node 602 has any level of authority for the requested subspace. To check the authority (616), the server node 606 fetches a private subspace blockchain with the associated subspace, and then a given authority level (peer, validation, service) for that subspace 608 Access a specific subspace 608 (cover (eg, a smart contract)) to retrieve a list of nodes with. If the service node 602 is listed as having service / API privileges for a specific subspace, The authorization is granted 618. In this regard, it should be noted that the permission level is hierarchical, the validation node has greater authority than the peer node, and the peer node has greater authority than the service / API node. As a result, lower-level authorities are included in higher-level privileges, so nodes with higher-level privileges are granted for requests that require lower-level privileges. For example, if a node is a validation node for a particular subspace, it is accepted for requests that require peer or service / API permissions, as another example, if the node is a peer node for a specific subspace, the peer or service / API Authorization is granted for requests that require authorization, the system can support additional levels of authorization as needed, and if the service node 602 determines that it has permission to access data in a particular subspace, the server node will service. Node 602 responds by returning verification data 622 that can determine that the response is valid, for example, this verification data includes a complete block header (signature, message route and status route from server node 606). Includes) but excludes data from subspaces for unauthorized service nodes (e.g., requested) It contains only the data in the data payload from the associated subspace for the authorized service node 602 (such as a mart contract), and a hash value or index 610 from the portion and excluded data. Despite the fact that it returns a limited part of, the service node generates the root 612 by performing proof on the hash tree, for example, and compares it to the state root in the block header to produce an equivalent value for the state root. By confirming, the data can be verified by evaluating the verification data. If the state root is the root of the Merkle tree, the service node 602 will perform Merkle proof to verify the data returned by the server node 606.

FIG. 15 illustrates the various ways in which participants in the network can store data and execute logic, using the private subspace blockchain described above, so that specific data and logic can be accessed only by nodes that are authorized to access the subspace. It provides examples of smart contracts and corresponding common and private subspaces. Subspace 1500 includes Party A's private and enrichment smart contract 1506. The smart contract 1506 stores personal data from Party A's trade contract. The common subspace 1504 includes market data, rights registry and basic template contracts. The basic template contract 1520 includes rules and logic related to the financial contract. The rights registry agreement 1524 maintains a list of parties' rights in various private subspace blockchains. The market data contract 1526 provides input to execute the logic of the smart contract. The quantum subspace 1502 includes a series of smart contracts that record transactions between the parties, namely Party A and Party B. The trade contract 1528 stores the current contract status 1522, the specific transaction terms 1508, and the update set 1512 for this trade, and the bytecode 1518 for rule / logic execution of the trade contract. Subspace 1502 also incorporates registry agreements 1510 to store all transaction agreements, event scheduler 1514 to track time stamps in block headers, and payments owned from transaction agreements and calculates netted values. And a payment smart contract 1516. The reinforcement data portion of the trade agreement terms 1508 is populated by both parties through the reinforcement agreement 1506 present in their own private private subspace 1500. The trade agreement 1528 itself is instantiated using the default template 1520 and filled with the specific conditions of the trade 1508. Authority to the parties that can execute the logic of the trade agreement 1528 is managed through the registry agreement 1524 in a common subspace.

16A-16E illustrate various life cycle events of an IRS (Iorate Rate Swap) contract implemented in a private subspace blockchain, according to one embodiment. 16A shows the structure of the IRS contract. The smart contract used to implement the IRS is located in two subspaces, (1) both subspaces 1600 between the parties, and (2) a common subspace 1602. The IRS data contract 1608 includes the terms of the transaction, the registry contract 1606 maintains the IRS instance, and the payment contract 1610 is used for payment consolidation and netting. The common subspace 1602 includes three contracts used to implement the IRS. The basic contract 1612 is a template for the IRS contract, the rights registry contract 1614 manages the rights of the parties across the subspace, and the reference data contract 1616 maintains public reference data. 16B shows a sequence of events during the creation of a new IRS. The matching engine 1620 interacts with the server node 1818 in both subspaces 1600 to initiate recording of transactions on the private subspace blockchain. The server node accesses the basic template agreement 1612 from the common subspace, instantiating the new IRS agreement 1608. Service provider rights are verified by accessing registry agreement 1614. Upon verifying the credentials, the new contract is stored in registry 1606, and the upfront payment is sent to payment contract 1610. New contracts are also added to scheduler 1604 to track block header time stamps. 16C shows the sequence of events resulting in the update of the IRS contract in quantum subspace 1600. The clearing house node 1624 is connected to the server node 1622 of the common subspace 1602. The server node sends a message to the reference data contact. The event scheduler 1604 on the quantum subspace observes this message and notifies the IRS registry agreement 1606. Next, the registry agreement updates the status of the basic IRS agreement 1608. 16D shows the sequence of events after a time-based trigger. When a predefined time stamp is reached, event scheduler 1604 triggers a time triggered event by notifying IRS registry 1606. The registry notifies the basic IRS contract 1608 and the payment of the contract is appropriately updated in the payment contract 1610. 16E shows the creation of new two-sided subspaces. The clearing node 1624 sends a message to the server node 1622 to create a new quantum private subspace blockchain. The rights registry agreement 1614 verifies rights and creates new two-sided subspaces, and also sends notifications from both parties to the relevant node.

17A-17C illustrate the creation of an equity swap contract, according to one embodiment. 17A shows the contract required for both the private subspace 1700 and the common subspace 1702. The common subspace includes a basic template contract 1712, a rights registry 1714, and a market data contract 1716. Quantum subspace 1700 between the parties includes equity swap contract 1708, payment contract 1710, registry contract 1706 and event scheduler contract 1704. 17B shows creating a new equity swap contract in quantum subspace 1700. Market node 1720 interacts with server node 1718 to initiate the creation of a new trade contract. The server node generates a blockchain message to generate the swap contract 1708 from the template defined in the basic contract 1712. When the swap contract is created, the registry contract 1706 and scheduler contract 1704 are updated. 17C shows a sequence of events during the day and post update of payments between the parties. The market data provider 1724 is connected to a server node 1722 in a common subspace. The server node updates the market data contract 1716 by sending a message. The event scheduler contract 1704 in both subspaces triggers a Mark to Market (MTM) event that fetches outstanding contracts from the registry 1706. The outstanding transaction contract 1708 queries the market data contract 1716 for the latest interest rates, calculates the MTM, and eventually sends a message to the payment contract 1710.

18 shows how the reference data provider 1816, verification service provider 1812, and other nodes interact through a common connectivity network 1822. Buying companies, dealers and other service providers maintain different connections to the network. Matching and verification service providers 1812, reference data providers 1816, and other service providers 1814 maintain only software-defined networking (SDN) based connections to the network. Because these three services have only service level nodes, visibility to the network is limited. These nodes can only access a limited set of contracts within a particular subspace. It also receives all messages in the common subspace. Dealer node 1800 is a full node, meaning that it receives all messages from the authorized subspace (s) and commits the block to the subspace blockchain. Dealer nodes 1802 and 1804 are also full nodes and maintain SDN and client connections to the network. The purchasing-side nodes 1806, 1808 and 1810 are service nodes and access a limited set of messages in the authorized subspace.

Although the invention has been described in terms of several preferred embodiments, it should be understood that there are many variations, substitutions and equivalents that fall within the scope of the invention. It should also be noted that there are alternative methods of implementing both the process and apparatus of the present invention. For example, the steps need not necessarily occur in the order shown in the accompanying drawings, but can be rearranged as appropriate. Accordingly, the appended claims are intended to cover all such modifications, substitutions, and equivalents as fall within the true spirit and scope of the invention.

The invention may be implemented in digital electronic circuitry, or computer hardware, firmware, software, or a combination thereof. The present invention can be implemented as a computer program product, i.e., a computer program tangibly embodied in an information processing device, for example, a machine-readable storage device or a radio wave signal, for execution or control by data processing. A device, such as a programmable processor, computer or multiple computers. Computer programs may be written in any form of programming language, including compiled or interpreted languages, and distributed in any form, including those suitable for use as standalone programs or modules, components, subroutines, or other devices. . Computing environment. Computer programs may be distributed on one computer or on multiple computers at one site, or distributed over multiple sites and interconnected and distributed over a communication network.

The method steps of the present invention can be performed by one or more programmable processors executing a computer program to perform the functions of the present invention by manipulating input data and generating output. The method steps can also be implemented as a special purpose logic circuit, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), and the apparatus of the present invention can be implemented.

Processors suitable for the execution of a computer program include, for example, microprocessors and any one or more processors of any high performance digital computing platform. The processor will receive instructions and data from read-only memory or random access memory or both. An essential element of a computer is a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer is also operable to receive data from, or to receive data from, one or more mass storage devices for storing data, such as, for example, magnetic, magnetic optical disks or optical disks, or both. Will be connected. Information media suitable for embodying computer program instructions and data include, for example, all types of non-volatile memory including semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; Magnetic disks, for example internal hard disks or removable disks; Magneto-optical disk; And CD ROM and DVD-ROM discs. The processor and memory may be supplemented by special purpose logic circuitry or incorporated into special purpose logic circuitry.

The use of the terms “a” and “an” and “the” and similar references in the context of this specification (especially in the context of the following claims) should be construed to include both singular and plural. Unless otherwise specified, there is no apparent contradiction in context. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples or exemplary languages (eg, preferably preferably) provided herein is only to further illustrate the present disclosure and does not limit the scope of the claims. No language in this specification should be construed as representing elements that are not claimed to be essential to the practice of this disclosure.

A number of embodiments are described herein that incorporate the best mode known to the inventors for carrying out the claimed invention. Of these, variations of the disclosed embodiments will become apparent to those skilled in the art upon reading the above disclosure. The inventors expect those skilled in the art to appropriately utilize such modifications (eg, alterations or combinations of features or embodiments), and the invention is intended to be practiced differently than specifically described herein.

Accordingly, the present invention includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. In addition, any combination of the elements described above in all possible variations is included in the present invention, unless otherwise indicated herein or clearly contradicted by context.

Claims (20)

A system for providing a distributed platform to enable the secure and secure exchange of data and to ensure the reliability of data,
A plurality of nodes communicatively connected to each other via a network-each node of the plurality of nodes has logic to receive messages exchanged in a common subspace;
A subset of nodes in a plurality of nodes-the subset of nodes corresponds to a domain and has authority to access messages exchanged within private subspaces within the domain;
A set of verification nodes in a subset of nodes, each verification node having logic to generate a state route based on messages exchanged within the private subspace,
The node in the subset of nodes has additional logic to generate a global state route value based on the state route. The method of claim 1, wherein the state route is a hash value resulting from a hash function performed on data of the private subspace, and the global state route is a hash function performed on a set of data including the state route. The resulting hash value system. The method of claim 1, wherein each node in the set of verification nodes has logic to verify messages exchanged within the private subspace based on a consensus voting process involving other nodes in the set of verification nodes. system. The system of claim 1, wherein the authority information for each node is maintained in a common subspace, and changes to the authority information are managed through a plurality of nodes exchanging and verifying messages in the common subspace. 5. The system of claim 4, wherein each node in the plurality of nodes has logic to deliver the received message to another node authorized for the received message based on the authorization information. The system of claim 1, wherein each node in the plurality of nodes is communicatively coupled to the database, and each node in the plurality of nodes is stored in a validated database message and block. 7. The system of claim 6, wherein each node further includes logic to delete messages and blocks according to one or more sets of criteria, wherein deletion of messages preserves subspace hash values and global hash values. As a network node in a distributed platform to enable private and secure exchange of data and to ensure the reliability of data,
To receive messages exchanged in a common subspace-all nodes in the network have permission to access messages in the common subspace-and receive messages exchanged in private subspaces about authorized nodes For, logic;
Logic to generate a subspace hash value based on the messages exchanged in the private subspace; And
A network node that includes logic to generate a global hash value based on the subspace hash value. 10. The network node of claim 8, further comprising logic to verify messages exchanged within a private subspace based on a consensus voting process involving other nodes in the distributed platform. The authorization information for each node in the distributed platform is maintained in the common subspace, and changes to the authorization information are managed through a network node exchanging and verifying messages in the common subspace. Network node. 11. The network node of claim 10, further comprising logic for forwarding the received message to another node authorized to receive the message based on the authorization information. 10. The network node of claim 8, wherein the network node is communicatively coupled to a database, the network node being stored in a validated database message and block. 13. The network node of claim 12, further comprising logic for deleting messages and blocks according to one or more sets of criteria, wherein deletion of messages preserves the subspace hash value and global hash value. In a distributed data structure implemented in a computer memory, to securely exchange private data between multiple nodes in a distributed network and ensure data reliability,
One or more private subspaces with content accessible only by nodes in a plurality of nodes with sufficient access credentials, each subspace including a state root;
A common subspace accessible to all nodes in the plurality of nodes-the common subspace identifies a verification node for each private subspace; And
A distributed data structure comprising a header containing a global state root based on the state root of one or more subspaces. 15. The distributed data structure of claim 14, wherein the state root of each private subspace is a hash value resulting from a hash function performed on data in the private subspace. 15. The distributed data structure of claim 14, wherein the global state route is a hash value that is the result of a hash function performed on a set of data comprising state routes of one or more private subspaces. 15. The distributed data structure of claim 14, wherein the common subspace includes a script for managing authority of each node in the plurality of nodes. 15. The distributed data structure of claim 14, wherein each private subspace includes a policy for deleting blocks and messages in the private subspace through a deletion process that preserves the hash value of the subspace. 15. The distributed data structure of claim 14, wherein the header further comprises one or more cryptographic signatures used to verify the distributed data structure. 15. The distributed data structure of claim 14, wherein the header further comprises a message route having a value that is a function of all messages included in the distributed data structure.

Images