Blockchain network interaction controller

Abstract

Systems and methods for policy enforcement among participants of a virtualized overlay network are described herein. In some embodiments, each of the participants may maintain a separate blockchain network. The overlay network may receive a smart contract or other policy document that includes information about interactions with a particular participant or interactions between participants. A controller that may be implemented on any node of the overlay network may then retrieve an interaction algorithm from the smart contract that may be stored in policy data for use in completing a transaction between two participants of the overlay network. In some embodiments, the policy data may include cost data that may be used to determine the manner in which two entities may interact.

Description

Background Art

[0001] Blockchain technology is rapidly expanding beyond the use of digital currencies. Currently, blockchain is a transaction database shared by all nodes participating in the system based on the blockchain protocol. The blockchain may include multiple blocks of interaction records. Each block in the blockchain may also include a timestamp and a link to the previous block. For example, each block may include or be attached to the hash of the previous block. In other words, the interaction records in the blockchain may be stored as a series of "blocks" or a permanent file that includes records of several transactions that occurred in a given period of time. Blocks may be attached to the blockchain by the blockchain provider after the blocks are completed and verified. The blockchain may be distributed, and copies of the blockchain may be maintained in one or more locations. In some instances, the blockchain may be used to verify transactions. The security of the blockchain may be obtained using an encryption scheme.

[0002] Because blockchain technology enables a decentralized approach to database management, some entities also use blockchain networks as an alternative to typical database management systems, where various services are performed using one or more applications distributed on the blockchain network. However, these blockchain networks are often developed independently by the respective entities and may not use the same protocols (e.g., common data formats, common security protocols, etc.). When two or more entities using these blockchain networks choose to interact (e.g., one entity wishes to use a service provided by another entity), there may be conflicts between the two entities as to which protocols should be prioritized.

[0003] Embodiments of the invention address these and other problems, individually and collectively. Summary of the invention

[0004] Embodiments of the present invention relate to techniques for policy enforcement among participants of a virtualized overlay network. In some embodiments, each of the participants may maintain a separate blockchain network. In some embodiments, the overlay network may receive a smart contract or other policy document that includes information about interacting with a particular participant. A controller that may be implemented on any node of the overlay network may then obtain an interaction algorithm from the smart contract, which may be stored in policy data for use in completing transactions between two participants of the overlay network. In some embodiments, the policy data may include cost data (e.g., monetary cost, resource cost, etc.) that may be used to determine the manner in which two entities may interact.

[0005] One embodiment of the invention relates to a computer-implemented method, comprising: receiving, by a controller and from a first entity associated with a first blockchain network, a request to conduct a transaction through a virtual environment associated with the controller; identifying a first set of policies associated with the first entity; determining a second entity associated with a second blockchain network with which to conduct the transaction based on the first set of policies; identifying a second set of policies associated with the second entity; and facilitating the transaction between the first entity and the second entity using the first set of policies and the second set of policies.

[0006] Another embodiment of the present invention relates to a blockchain node server, comprising a processor and a computer-readable medium coupled to the processor, the computer-readable medium comprising code for causing the processor to perform the following operations: receiving a request to conduct a transaction through a virtual environment from a first entity associated with a first blockchain network; identifying a first set of policies associated with the first entity; determining a second entity associated with a second blockchain network to conduct a transaction with based on the first set of policies; identifying a second set of policies associated with the second entity; and facilitating the transaction between the first entity and the second entity using the first set of policies and the second set of policies.

[0007] Another embodiment of the present invention relates to a blockchain router, comprising: one or more processors; and a memory comprising instructions, which when executed by the one or more processors cause the one or more processors to: receive a request from an overlay network to complete a transaction using a blockchain network accessed through the blockchain router; determine an initiator of the request based on the request; identify one or more policies associated with the initiator within policy information stored in a blockchain ledger; determine one or more restrictions associated with the initiator of the request based on the policy information; and provide instructions to a blockchain to cause the blockchain to complete the transaction according to the one or more restrictions.

[0008] These and other embodiments of the invention are described in further detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 Describes an example system for implementing at least some embodiments of the present disclosure;

[0010] Figure 2 depicts an example of an overlay network having a controller configurable to manage interactions between various blockchain networks in accordance with at least some embodiments;

[0011] Figure 3 depicts an example of policy enforcement within a network of blockchain routers for implementing a secure blockchain routing protocol in accordance with at least some embodiments;

[0012] Figure 4depicts an illustrative example computer architecture of a blockchain router configured to implement a secure blockchain routing protocol in accordance with at least some embodiments;

[0013] Figure 5 depicts an illustrative example computer architecture of a blockchain provider configured to maintain one or more blockchain ledgers in accordance with at least some embodiments;

[0014] Figure 6 depicts an example overlay network that may be implemented according to at least some embodiments; and

[0015] Figure 7 A flow diagram illustrating a process for enabling interaction between network participants through policy enforcement is depicted in accordance with at least some embodiments. DETAILED DESCRIPTION

[0016] In the following description, various embodiments will be described. For the purpose of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it should also be clear to those skilled in the art that the embodiments may be practiced without the specific details. In addition, well-known features may be omitted or simplified in order not to confuse the described embodiments.

[0017] Before discussing the details of some embodiments of the present invention, a description of some terms may aid in understanding the various embodiments.

[0018] An "application" may be any collection of computer executable instructions that are configured to be executed by a processor to cause the processor to perform a function. An application may include computer code or other data stored on a computer readable medium (e.g., a memory element or a secure element) that is executable by a processor to perform a task. An application may have multiple versions, some of which may be specific to a type of hardware. For example, a mobile application may be an application that is configured to operate in conjunction with a mobile operating system and a processor installed within a mobile electronic device.

[0019] A "blockchain ledger" is an electronic record of transactions maintained according to the blockchain protocol. A complete copy of a blockchain ledger may include every transaction executed by the system. Each entry (e.g., block) in the ledger may contain a hash of the previous entry. This has the effect of creating a series of blocks from the genesis block to the current block. Each block is guaranteed to follow the previous block in chronological order, because the hash of the previous block would not be known otherwise. It is also computationally impractical to modify each block once it has been in the series of blocks for a period of time, because each block after the block must also be regenerated. These properties make blockchain ledgers relatively secure and tamper-proof.

[0020] A "blockchain provider" (also referred to as a "blockchain provider node") may be any computing device configured to provide blockchain functionality. A blockchain provider may include a single device, multiple devices, or one or more software modules configured to maintain various aspects of a blockchain (e.g., one or more ledgers, etc.). In some instances, a blockchain provider may additionally provide routing functionality. Thus, in some embodiments, it is contemplated that blockchain and routing management functions may be jointly performed by a blockchain provider.

[0021] A "blockchain router" (also referred to as a "blockchain routing node") may be any suitable computing device or software module that can be configured to perform routing functions using a blockchain protocol. A blockchain routing node may be configured to transmit and receive data over a wired or wireless data network (e.g., 3G, 4G, or similar network), Wi-Fi, Wi-Max, or any other communication medium that may provide network access. A blockchain routing node may include any suitable hardware and software for performing routing functions, and may also include multiple devices or components (e.g., when a device accesses a network by binding to another device - i.e., using the other device as a modem - two electronic devices combined together may be considered a blockchain routing node). A blockchain routing node may be configured to perform functions such as maintaining forwarding and / or routing tables, determining routing costs, selecting a particular route from a number of available routes, and facilitating or enabling routing of data messages to an intended destination. In some instances, a blockchain provider node may be configured to manage one or more blockchain ledgers. Thus, in some embodiments, it is contemplated that blockchain and routing management functions may be performed jointly by a blockchain routing node.

[0022] A "centralized routing model" may refer to a routing model that is centrally implemented using a centralized database (e.g., a single database maintained by a single entity). In other words, the routing table in a centralized routing model is stored at a single "central" node, which may be consulted by other nodes when routing decisions need to be made.

[0023] A "computing device" may be any suitable device or software module configured to process data. In some embodiments, a computing device may include, for example, communication capabilities using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G, or similar network), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet, an overlay network, or the like. Examples of computer devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, personal music players, handheld dedicated readers, server computers, and the like. A computing device may include any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., when a device accesses a network by binding to another device - i.e., using the other device as a modem - two electronic devices combined together may be considered a single computing device).

[0024] "Decentralized network" is intended to refer to a network in which no single computing device or software module controls all of the network's processing. "Centralized network" is intended to refer to a network in which a single computing device or node (or a relatively small number of computing devices or nodes) controls the network's processing. Between the two, a decentralized network may be less likely to fail unexpectedly because it relies on many independent components that are unlikely to fail simultaneously. In addition, decentralized systems are more expensive to attack and destroy or manipulate than centralized networks because decentralized networks lack sensitive central points that can be attacked at much lower costs than the economies of scale of the surrounding systems. In addition, it may be significantly more difficult for participants in a decentralized network to take actions that benefit themselves at the expense of other participants.

[0025] A "distributed routing model" may refer to a routing model implemented using a distributed database (or in other words, a database whose copies are distributed and maintained on many (or all) of the nodes / devices of a network).

[0026] The "extended blockchain protocol" may define the message format and message exchange rules for performing network routing functions. The extended blockchain protocol may include the functions of the standard blockchain protocol that do not define network routing functions.

[0027] A "forwarding table request message" is an example of a message defined by the extended blockchain protocol. In some embodiments, a forwarding table request message may be used to request forwarding table information from another computing device. In some embodiments, a forwarding table request message may be used to request an entire forwarding table from another computing device.

[0028] A "forwarding table response message" is an example of a message defined by the extended blockchain protocol. In some embodiments, the forwarding table response message may be used to provide forwarding table information to another computing device. In some embodiments, the forwarding table response message may be used to provide the entire forwarding table to another computing device.

[0029] "Forwarding table information" may include any suitable data associated with a forwarding table. For example, forwarding table information may include, but is not limited to, a destination, next hop, and performance data (eg, metrics and costs) associated with a particular network route between two computing devices of a network.

[0030] A "message protocol" may be a set of rules for exchanging messages between two computing devices. In some cases, a messaging protocol may include conditions under which actions are to be performed. In some embodiments, a messaging protocol may include specifications that define bit-by-bit implementations of various message formats for the messaging protocol.

[0031] An "overlay network" may be a computer network built on top of another network. Nodes in an overlay network may be viewed as connected by virtual or logical links, each of which may correspond to a path in the underlying network through many physical links. For example, distributed systems such as peer-to-peer networks and client-server applications are often overlay networks because their nodes run on top of the Internet. As discussed herein, an overlay network may include one or more computing nodes (e.g., blockchain routing nodes, computing nodes for maintaining blockchain ledgers, etc.) for performing blockchain functions, including but not limited to managing one or more blockchain ledgers, determining routing costs, selecting a particular route from many available routes, and facilitating or enabling routing of data messages to intended destinations.

[0032] "Performance data" is intended to refer to metrics and / or costs associated with network routing. Metrics may correspond to latency values, processing values ​​that quantify processing costs, etc. In some embodiments, costs may correspond to monetary costs associated with network route utilization.

[0033] A "routing table request message" is an example of a message defined by the extended blockchain protocol. In some embodiments, a routing table request message may be used to request routing table information from another computing device. In some embodiments, a routing table request message may be used to request an entire routing table from another computing device.

[0034] A "routing table response message" is an instance of a message defined by the extended blockchain protocol. In some embodiments, a routing table response message may be used to provide routing table information to another computing device. In some embodiments, a routing table response message may be used to provide an entire routing table to another computing device.

[0035] "Routing table information" may include any suitable data associated with a routing table. For example, routing table information may include, but is not limited to, a destination, next hop, and performance data (eg, metrics and costs) associated with a particular network route between two computing devices of a network.

[0036] A "routing table" may be a data table that lists available routes in a network (and, in some cases, policies and / or metrics (distances) associated with those routes). A routing table contains information about the network topology to which it relates. The construction of routing tables is the primary goal of traditional routing protocols.

[0037] A "forwarding table" may include a subset of the entries of a routing table. A forwarding table may include a route that has been determined to be optimal (eg, based on policy, delay, cost, or other suitable metric) for a plurality of available routes.

[0038] A "peer-to-peer network" refers to a network that includes nodes / devices that are equivalent to other nodes / devices in the network and act as both "clients" and "servers". Peer-to-peer network arrangements differ from the client-server model where communications typically go to and from a central server. Peer-to-peer networks may implement some form of virtual overlay network on top of a physical network topology, where the nodes in the virtual overlay form a subset of the nodes in the physical network. Data may still be exchanged directly via the underlying protocol (e.g., TCP / IP) network, but at the application layer, peers are able to communicate directly with each other through logical overlay links (each of which corresponds to a path through the underlying physical network).

[0039] "Peer discovery process" may refer to operations performed to discover other peers within a network. The peer discovery process may include any suitable operations for performing such tasks, such as referencing a list of nodes from a previous connection to the network (e.g., a locally stored list), requesting and / or receiving a domain name server (DNS) seed, or transmitting an identification request to the network. In some embodiments, the DNS seed resolves a list of IP addresses of nodes known to be operational. Additionally or alternatively, the process may include referencing a static, hard-coded, locally stored list of peers in order to identify one or more peers of the network.

[0040] A "smart contract" may be a computer-executable instruction configured to cause a processor to execute a policy or protocol. A smart contract may be used to represent an agreement between two or more parties, where the terminology of the smart contract is recorded in a computer language as a set of instructions. A smart contract may include several policies that must be executed in order to complete a transaction between two or more parties. Smart contracts may be distributed on one or more nodes of a blockchain network, so that the smart contract may be automatically executed.

[0041] Details of some embodiments of the invention will now be described in greater detail.

[0042] Figure 1 An example system is described for implementing at least some embodiments of the present disclosure. Figure 11 depicts a controller 102 in communication with a plurality of nodes 104 (1 to N) via a routing network 106. According to at least some embodiments, the controller may be configured to receive interactive algorithm information 108 (1 to M) from various data sources, generate policies based on the algorithm information 108 and permissions and policy enforcement operations 110, and distribute those policies in a distributed database / ledger 112.

[0043] The controller 102 may be any electronic computing device configured to distribute routing policies to multiple nodes 104 and / or distributed databases 112. In one illustrative configuration, the computer 102 may include at least one memory and one or more processing units (or processors). The processor may be suitably implemented in hardware, computer executable instructions, firmware, or a combination thereof. The computer executable instructions or firmware implementation of the processor may include computer executable or machine executable instructions written in any suitable programming language for performing the various functions described.

[0044] The memory of the controller 102 can store program instructions that can be loaded and executed on the processor separately, as well as data generated during the execution of these programs. Depending on the configuration and type of the user's computing device, the memory can be volatile (e.g., random access memory (RAM)) and / or non-volatile (e.g., read-only memory (ROM), flash memory, etc.). The controller 102 may also include additional removable storage devices and / or non-removable storage devices, including but not limited to magnetic storage devices, optical disks, and / or tape storage devices. The disk drive and its associated computer-readable medium can provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing device. In some embodiments, the memory may include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), or ROM.

[0045] Turning to the contents of the memory, the memory may include an operating system and one or more applications, modules, or services for implementing the features described herein. Additionally, the memory may store configuration information, such as, but not limited to, routing tables, forwarding tables, policy information, and the like. The routing network 106 may be an example of a centralized network in which routing is handled by a single node 104 or a subset (1 to N) of nodes 104 included in the routing network 106.

[0046] In some embodiments, the controller 102 may include a communication interface configured to enable communication between the controller 102 and another computing device (e.g., another computing device accessing the routing network 106). An example of a communication interface may include one or more radio frequency (RF) transceivers configured to send and receive communications using near field communication (NFC), or other radio frequency or wireless communication protocols, such as Bluetooth, Bluetooth low energy (BLE), wireless local area network (e.g., WiFi), iBeacon, etc. In some embodiments, the communication interface may include an infrared communication device. In some embodiments, the communication interface may include long-range and short-range communication means. For example, the communication interface may include an antenna configured to connect to a cellular network so as to enable communication with various other components of the depicted architecture. In some instances, the communication interface may utilize a physical connection between computing devices of the routing network 106 to transmit and receive data.

[0047] Node 104 may be any electronic device configured to perform at least one primary function. In one illustrative configuration, node 104 may include at least one memory and one or more processing units (or processors). The processor may be suitably implemented in hardware, computer executable instructions, firmware, or a combination thereof. The computer executable instructions or firmware implementation of the processor may include computer executable or machine executable instructions written in any suitable programming language for performing the various functions described.

[0048] The memory of node 104 can be stored separately on the program instructions that can be loaded and executed on the processor, and the data generated during the execution of these programs.Depending on the configuration and type of the computing device, the memory can be volatile (e.g., random access memory (RAM)) and / or non-volatile (e.g., read-only memory (ROM), flash memory, etc.).Node 104 may also include additional removable storage devices and / or non-removable storage devices, including but not limited to magnetic storage devices, optical disks and / or tape storage devices.Disk drives and their associated computer-readable media can provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for computing devices.In some embodiments, the memory may include multiple different types of memories, such as static random access memory (SRAM), dynamic random access memory (DRAM) or ROM.

[0049] Turning to the contents of the memory, the memory may include an operating system and one or more applications, modules, or services for implementing a certain function. In addition, the memory may store a copy of one or more databases (e.g., one or more decentralized blockchain ledgers). The routing network 106 may be an example of a decentralized network in which blockchain ledger management is performed by each computing device (e.g., node 104) of the routing network 106. In some embodiments, each node 104 may represent a gateway to a separate blockchain network, so that the routing network 106 may represent an overlay network that manages traffic routed between blockchain networks. Multiple nodes 104 may belong to a single blockchain network and may each represent an entry / exit point. For example, a particular blockchain network may include multiple nodes at which traffic may enter / leave the blockchain network. These nodes 104 may be geographically distributed.

[0050] In some embodiments, the node 104 may include a communication interface configured to enable communication between the node 104 and another computing device (e.g., another node 104 included in the routing network 106). Examples of communication interfaces may include one or more radio frequency (RF) transceivers configured to send and receive communications using near field communication (NFC), or other radio frequency or wireless communication protocols, such as Bluetooth, Bluetooth low energy (BLE), wireless local area network (e.g., WiFi), iBeacon, etc. In some embodiments, the communication interface may include an infrared communication device. In some embodiments, the communication interface may include long-range and short-range communication means. For example, the communication interface may include an antenna configured to connect to a cellular network so as to enable communication with various other components of the depicted architecture. In some instances, the communication interface may utilize a physical connection between computing devices of the routing network 106 to transmit and receive data.

[0051] The routing network 106 may include one or more computing devices configured to route communications between various nodes 104. In some embodiments, the computing device may be a node 104. The routing network 106 may be an instance of an overlay network, which may include various information and communication facilities, consisting of an interconnected network using a standard messaging protocol. As an example, data may be transmitted between computing devices of the routing network 106 using a blockchain protocol according to policies stored in a distributed database 112. In some instances, the computing devices of the routing network 106 may be the same, or may be a subset of the nodes 104 (1 to N). However, in some cases, at least some of the nodes 104 (1 to N) may not participate in performing routing functions as described with respect to the routing network 106.

[0052] The interaction algorithm information 108 may be any information that defines the interaction between two or more entities. In some embodiments, the interaction algorithm information 108 may be derived from a smart contract or other electronic document. The interaction algorithm information may be used to generate policies and may include information about rates to be executed at the entities, maximum / minimum business requirements, or any other suitable interaction conditions.

[0053] To simplify the explanation, Figure 1 A specific number of computing devices is shown in FIG. However, it should be understood that embodiments of the present invention may include more than one of each computing device. In addition, some embodiments of the present invention may include more than one of each computing device. Figure 1 All computing devices shown in the figure may be fewer or more computing devices.

[0054] Figure 2 Depicts an example of an overlay network with a controller that can be configured to manage interactions between various blockchain networks according to at least some embodiments. In some embodiments, the controller 202 can route information within the overlay network. The overlay network can be a consortium or federated blockchain network in which multiple other blockchain networks participate. A federated network is a network in which only authorized / registered participants can participate. A consortium network is a blockchain network in which the consensus process is controlled by a set of pre-selected nodes. For example, a consortium blockchain network may include multiple participating entities, each of which operates a node and at least a predetermined number of entities must sign each block in order for the block to be valid. In a consortium blockchain, the right to read the blockchain may be public or limited to participants. There may also be hybrid routes, such as an API together with a root hash of a public block that enables non-members (e.g., the public) to make limited queries and obtain cryptographic proof of some parts of the blockchain state. In some cases, a consortium blockchain network may be considered "partially decentralized."

[0055] The overlay network may include a plurality of edge nodes 204 and core nodes 206. The core nodes 206 are computing devices that form the infrastructure of the overlay network. The edge nodes 204 are computing devices that act as an interface between the overlay network (e.g., a consortium) and another blockchain network (e.g., a participant of the consortium). Thus, each edge node 204 may manage a registrar gateway 208 connected to one or more blockchain networks. The registrar gateway may be a gateway through which only network traffic associated with a registered entity (e.g., a consortium participant) may be routed. Although depicted as separate entities, each edge node and / or core node may perform the functions of the controller 202.

[0056] In some embodiments, the controller 202 of the overlay network may facilitate transactions between various blockchain networks (e.g., consortium participants) based on policy information related to those blockchain networks. For example, the controller 202 may facilitate transactions between network 1 and network 2 using an interaction algorithm 210 specifically for transactions between those specific networks. The interaction algorithm 210 may be generated by analyzing information from a smart contract or other policy document. For example, the controller 202 may receive a smart contract from each of network 1 and network 2, which indicates one or more policies (rates, formats, conversion formulas, etc.) for completing transactions with the corresponding network. In another example, a smart contract may be provided that indicates how transactions should be handled for specific networks (e.g., transactions between network 1 and network 2). Upon receiving these policies, the controller 202 may generate an interaction algorithm from the policy file, which may then be used to facilitate transactions. In some embodiments, the policy may include an algorithm for converting data from a first format used by network 1 to a second format used by network 2.

[0057] In some embodiments, when the controller 202 facilitates a transaction between two networks within the consortium 212, the transaction may be recorded in separate ledgers 214 (A and B) associated with each of the networks. In this scenario, the controller 202 may send the same information or a subset of the information to each of the networks with respect to the transaction, but the information may be formatted according to the requirements of the network to which it is provided. Each of the networks may then use an aggregator 216 (A and B) to aggregate the provided data and write the transaction 218 (A and B) to a blockchain ledger maintained by and distributed across the respective blockchain network. In this way, each respective blockchain network to which the transaction is made may independently record the transaction details.

[0058] As an illustration, consider a scenario where entity 1 operating network 1 conducts a transaction with entity 2 operating network 2. In this scenario, upon completion of the transaction between entity 1 and entity 2, the ledgers maintained relative to each of network 1 and network 2 may be independently updated to reflect the transaction. This may involve each of the ledgers being updated by its respective blockchain network based on information provided to the network. In some embodiments, the information provided to each of the networks may be formatted according to a data format specific to the network. For example, one or more of the interaction algorithms identified relative to network 1 and / or network 2 may be a data formatting (e.g., conversion) algorithm for communicating information to the respective network.

[0059] In some embodiments, the controller 202 may identify policies regarding conditions and / or costs associated with a particular blockchain network. For example, the controller 202 may identify (e.g., from a smart contract associated with at least one blockchain network) services provided by the blockchain network, costs of using the blockchain network, conditions under which the blockchain network may be used, or any other suitable policy to be enforced with respect to the blockchain network. The cost may be a monetary cost, or the cost may refer to a resource cost (e.g., latency, memory usage, etc.).

[0060] The blockchain networks within the consortium may each perform a plurality of available services. For example, some or all of the blockchain networks in the consortium may perform services related to trust management, fraud and disputes, underwriting (e.g., for a line of credit), data routing, policy enforcement, membership services, or any other suitable services. When a node of an overlay network acting as a controller receives an indication that a transaction will be processed using one or more services, the node may reference a policy to determine which blockchain networks may be used to complete the transaction (e.g., based on which blockchain networks are associated with conditions satisfied by the transaction). Additionally, reference may be made to a policy regarding an entity submitting a transaction. For example, an entity may be associated with a policy indicating that a transaction should be conducted so that it minimizes monetary cost. In another example, an entity may be associated with a policy indicating that a transaction should be conducted so that the time to complete the transaction is minimized.

[0061] As an illustrative example, a node may receive an instruction to complete a particular transaction for network 1. Controller 202, which may be a node of an overlay network, may determine that network 2 and network 3 are each capable of completing a transaction. In this example, controller 202 may determine that network 1 is associated with a policy indicating that transactions on behalf of network 1 should be conducted so that monetary costs and delays are minimized. In this example, controller 202 may determine that network 2 is associated with a policy that charges $2 for this particular type of transaction. Controller 202 may also determine that network 3 is associated with a policy that charges $3 for this particular type of transaction. Controller 202 may also query a metric database associated with each of networks 2 and 3 to identify the delay for each of those networks. For this example, it is assumed that the delay for each of the networks is the same. In the event, the controller will select network 2 to complete the transaction in order to minimize monetary costs. After determining that network 2 will be used, controller 202 may identify one or more policies applicable to the transaction. In this example, one or more policies may be specific to transactions conducted between network 1 and network 2, using network 2 to conduct transactions and conducting transactions on behalf of network 1. Once each of the applicable policies has been identified, the controller 202 may identify a certain interaction algorithm 210 that should be used to complete the transaction. In some embodiments, the interaction algorithm 210 may include instructions for converting information from a first format used by network 1 to a second format used by network 2. The controller 2 may then facilitate the transaction by routing the information between the two networks according to the interaction algorithm 210. Each of the networks may record the transaction separately in its respective ledger.

[0062] In some embodiments, because each individual blockchain retains the details of the transaction within its respective ledger, the controller 202 can provide zero-knowledge proofs to the virtualization. Zero-knowledge proofs are a method by which one party (the prover) can prove to another party (the verifier) ​​that a given statement is true without conveying any information other than the fact that the statement is indeed true. Specifically, the controller 202 is able to provide non-interactive zero-knowledge proofs because a common reference string is shared between the prover and the verifier (where each of the prover and the verifier is a separate blockchain network), which is sufficient to achieve computational zero-knowledge without interaction.

[0063] Figure 3 An example of policy enforcement within a network 300 of blockchain routers for implementing a secure blockchain routing protocol is depicted according to at least some embodiments. The network may include any suitable number of blockchain routers (e.g., blockchain routers A through F). One or more of the blockchain routers may perform the functionality of the controller 302 described herein. Figure 2 The blockchain routers A to F are expected to participate in the overlay network (e.g. Figure 1The routing network 106) Figure 1 Thus, a blockchain router may independently be a device or software module configured to perform the routing functions described herein and corresponding to controller 302. In some examples, such functions may be performed by Figure 2 In some embodiments, a blockchain router may be independently a device or software module configured to perform blockchain ledger management. In these instances, such functionality may be performed by an application operating on one or more of the blockchain routers. Figure 2 The application is executed on one or more of the blockchain routers. Figure 2 A specific number of blockchain routers are depicted in FIG, but it should be understood that any suitable number of blockchain routers may be utilized. Some examples of methods for using blockchain routers for implementing a secure blockchain routing protocol may be found in International Patent Application No. PCT / US2017 / 032762 to Wang, filed on May 15, 2017, which is incorporated herein by reference in its entirety.

[0064] In some embodiments, controller 302 may be configured to generate and maintain a routing table (e.g., routing table 304) for network 300. Routing table 304 is intended to depict an example routing table for network 300. Routing table 304 may include Figure 2 . Each entry in the routing table 304 may include a destination (e.g., an Internet Protocol (IP) address of the destination), a next hop address (e.g., an IP address of the next hop), a metric (depicting processing cost, distance, latency, etc.), and a suitable combination of monetary costs. The routing table 304 may be viewed as a set of policies formatted in a table format in this case for determining where packets transmitted via the network 300 will be directed. The controller 302 may be configured to generate the routing table 304 from one or more data messages received from one or more of the blockchain routers of the network 300. Such data messages may be formatted according to an extended blockchain protocol that defines message formats and message exchange rules for performing the functions of the controller 302. The extended blockchain protocol utilized may include the functionality of a standard blockchain protocol that does not limit routing capabilities / functionality. In some embodiments, the routing table 304 may be generated based on policies obtained from one or more smart contracts received by the controller 302. For example, upon receiving a smart contract related to an interaction between blockchain router A and blockchain router B, the controller may be configured to update information in routing table 304 and / or forwarding table 306 based on the information according to the permission and policy execution operations.

[0065] The controller 302 may be further configured to generate a forwarding table 306 from the routing table 304. The forwarding table 306 may include some subset of the routes included in the routing table 304. In some instances, the entries of the forwarding table 306 may include the best routes determined from the routing table 304. For example, the forwarding table 306 may include a single best route between any pair of blockchain routers that constitutes the lowest total cost. In some instances, the best route may be the route with the lowest total value determined according to various policies by multiplying the corresponding metric by the corresponding monetary cost.

[0066] As an example, with respect to the initial blockchain router 308, the routing table 304 indicates that there are two routes to the destination D (e.g., route 310 and route 312). Therefore, the controller 302 may be configured to calculate the total cost of route 310 (e.g., 10×3=$30) and the total cost of route 312 (e.g., 8×$6=$48). In this non-limiting example, the controller 302 may be configured to determine that route 312 is the best utilized route based on route 312 associated with the lowest calculated value. Therefore, the controller 302 may include route 312 and exclude route 310 from the forwarding table 306. In some embodiments, the controller 302 may be configured to communicate one or more forwarding tables (e.g., forwarding table 306) to one or more blockchain routers (or another suitable computing device) in the network 300.

[0067] In some embodiments, controller 302 may be configured to facilitate data message routing within network 300. Controller 302 may be configured to transmit and receive data messages formatted according to the extended blockchain protocol so that data messages are transmitted through network 300 according to routing table 304 and / or forwarding table 306.

[0068] In some embodiments, the controller 302 may be configured to maintain one or more blockchain ledgers. As an example, the controller 302 may maintain a blockchain ledger for the routing table 304 and / or the forwarding table 306. By maintaining the blockchain ledger, the routing table 304 and / or the forwarding table 306 may be tamper-proof. As an example, each update of the routing table 304 may be stored as a transaction in the blockchain ledger, where each entry of the blockchain ledger includes a hash of the current routing table and the previous entry in the blockchain ledger corresponding to the previous version of the routing table. In another example, when the controller receives policy information about two or more blockchain routers, the controller 302 may initiate a transaction to record those policies. By identifying the latest transactions about those blockchain routers in the ledger, the ledger can then be used to identify the current policy for a pair of blockchain routers. Therefore, the blockchain ledger can be used to ensure that the routing table 304 has not been tampered with. Similarly, the controller 302 may be configured to maintain one or more blockchain ledgers for the forwarding table 306 (or any forwarding table) to ensure that the forwarding table 306 has not been tampered with. In this example, the controller 302 may receive smart contracts for two or more of the blockchain routers in the network 300. In this example, the controller may analyze the contents of the smart contracts and derive one or more policies to be applied to transactions between those blockchain routers. The controller 302 may then update the routing table within the blockchain ledger to reflect those values ​​associated with the derived policies. The blockchain ledger may then be signed and distributed to multiple network nodes (e.g., blockchain routers).

[0069] In some embodiments, network 300 may depict a centralized network in which a single computing device (e.g., blockchain router B) may perform the functions of controller 302. In some embodiments, it may be the case that generation and maintenance of routing table 304 and / or forwarding table 306 is performed by controller 302 and distributed across some or all of the blockchain routers of network 300. In other examples, network 300 may depict a decentralized network in which any / each of the blockchain routers may perform the functions of routing controller 302.

[0070] In some embodiments, a task may be submitted by an application (e.g., application 314). The submitted task may be any suitable task that requires routing between two computing devices. Controller 302 may be configured to consult authority and policy enforcement operations and forwarding table 306 to determine the next hop address of the data packet corresponding to the submitted task. In some instances, forwarding table 306 may be associated with the current blockchain router that most recently received the data packet. Controller 302 may be configured to cause the data packet to be transmitted to the identified next hop address. This process may be repeated any suitable number of times until the data packet reaches the intended destination.

[0071] Figure 4 Depicting a blockchain router 402 (e.g., Figure 3 The blockchain router 402 may execute Figure 3 The routing functions may be performed by an application stored in the computer-readable medium 410 and operating on the blockchain router 402.

[0072] In some embodiments, blockchain router 402 may include processor 404, which may be coupled to system memory 406 and external communication interface 408. Computer readable medium 410 may also be operatively coupled to processor 404. Computer readable medium 410 may include any suitable combination of software modules including network manager 412, table management engine 414, routing engine 416, and inter-controller routing engine 418. The modules of blockchain router 402 may be software and / or hardware modules. It should be understood that with respect to Figure 4 Any functionality described by the modules may be combined to be performed by a single module, or may be performed by a module external to the blockchain router 402.

[0073] The network manager 412, a component of the blockchain router 402, may be configured to cause the processor 404 to execute a join network (e.g., Figure 1 The network manager 412 may be configured to cause the processor 404 to perform operations to discover peers within a network (e.g., network 106).

[0074] In some embodiments, the table management engine 414, a component of the blockchain router 402, may be configured to cause the processor 404 to perform operations to maintain one or more routing tables (e.g., Figure 3 routing table 316) and / or one or more forwarding tables (e.g., Figure 3 Forwarding table 306 and / or Figure 3 The routing information received by the table management engine 414 may specify a specific route known by a particular blockchain router and / or a suitable computing device of the network. The route information may include a destination, a next hop, a metric, and a monetary cost associated with each route known to the device. It should be appreciated that the routing information may contain any suitable information associated with the route.

[0075] In some embodiments, the route may be generated from smaller routes that are recursively generated based on a policy. For example, consider a scenario where a message needs to be routed from the initial blockchain router 308 to blockchain router F. Blockchain routers D and E may each determine that they are in direct communication with blockchain router F. Therefore, each blockchain router may identify the direct path as the most appropriate path. Blockchain routers B and C may then determine that they are in direct communication with at least one of blockchain routers D and E. Blockchain router B may determine the cost associated with routing the message from BDF because this is the only appropriate path. However, blockchain router C may calculate the cost associated with routes CDF and CEF, both routes being available. Based on the policy data, blockchain router C may identify the route of the two identified routes that most closely matches the policy set forth by the message sender (e.g., minimizes monetary cost, etc.). In this example, blockchain router C may determine that the CDF route will incur a monetary cost of $3, and the CEF route will incur a monetary cost of $5. Blockchain router C may then provide an indication to the initial blockchain router that the route cost is $3. The initial blockchain router may also receive an indication from blockchain router B indicating a cost of $6. Based on this, the initial blockchain router 308 may generate a route including an initial CEF.

[0076] In some embodiments, table management engine 414 may be configured to cause processor 404 to calculate a total cost associated with each route. As described above, the total cost may be calculated by table management engine 414 by multiplying the metric by the monetary cost associated with the route, but other suitable methods for calculating the total cost may be utilized. After calculating the total cost for each route, table management engine 414 may be configured to construct one or more forwarding tables (e.g., Figure 3 In some embodiments, the table management engine 414 may be configured to provide the generated routing table and / or forwarding table to one or more other blockchain routers.

[0077] In some embodiments, the table management engine 414 may be configured to cause the processor 404 to store any suitable combination of one or more routing tables and / or one or more forwarding tables maintained by the table management engine. As an example, the table management engine 414 may be configured to store such routing / forwarding tables in a data storage area 420, a storage location configured to store such information. The data storage area 420 may exist as part of the memory 410, which is local to the blockchain router 402, and / or the processor 404 may have access to the data storage area 420, but the storage area exists external to the blockchain router 402.

[0078] In some embodiments, routing engine 416, a component of blockchain router 402, may be configured to cause processor 404 to execute a request based on a routing table (e.g., Figure 3 routing table 304) and / or one or more forwarding tables (e.g., Figure 3 Routing engine 416 may be configured to modify the data message in any suitable manner so as to transmit the data message to the appropriate destination. As an example, routing engine 416 may be configured to cause processor 404 to modify the address field of the message so as to direct the data message to the appropriate next hop address. In general, routing engine 416 may be configured to cause the processor to perform operations corresponding to routing controllers (e.g., Figure 3 Any suitable operation of the controller 302).

[0079] In some embodiments, the inter-controller routing engine 418, a component of the blockchain router 402, may be configured to cause the processor 404 to execute a request based on a routing table (e.g., Figure 3 routing table 316) and / or one or more forwarding tables (e.g., Figure 3 The inter-controller routing engine 418 may be configured to cause the processor 404 to modify the data message in any suitable manner so as to transmit the data message to the appropriate destination. As an example, the inter-controller routing engine 418 may be configured to cause the processor 404 to modify the address field of the message so as to direct the data message to the appropriate next hop address. In general, the inter-controller routing engine 418 may be configured to cause the processor to perform operations corresponding to an inter-network routing controller (e.g., Figure 3 Any suitable operation of the controller 302).

[0080] Figure 5 An illustrative example computer architecture 500 is depicted of a blockchain provider 502 configured to maintain one or more blockchain ledgers according to at least some embodiments. The blockchain provider 502 may be configured to maintain various aspects of a blockchain (e.g., one or more ledgers, etc.). In some embodiments, it is contemplated that at least a portion of the functionality of the blockchain provider 502 may be included as Figure 4 A module of the blockchain router 402.

[0081] In some embodiments, blockchain provider 502 may include processor 504, which may be coupled to system memory 506 and external communication interface 508. Computer readable medium 510 may also be operably coupled to processor 504. Computer readable medium 510 may include any suitable combination of software modules including network manager 512 and blockchain ledger management engine 514. The modules of blockchain provider 502 may be software and / or hardware modules. It should be understood that with respect to Figure 5Any functionality described by the modules may be combined to be performed by a single module, or may be performed by a module external to the blockchain provider 502.

[0082] The network manager 512 may be a component of the blockchain provider 502 that may be configured to cause the processor 504 to execute a join network (e.g., Figure 1 The network manager 512 may be configured to cause the processor 504 to perform operations to discover peers within a network (e.g., the routing network 106). Such operations may conform to conventional techniques for discovering peers within a blockchain network (e.g., the routing network 106).

[0083] In some embodiments, the blockchain ledger management engine 514, a component of the blockchain provider 502, may be configured to cause the processor 504 to perform operations to maintain one or more blockchain ledgers. As described above, a "blockchain ledger" is an electronic transaction record maintained in accordance with a blockchain protocol. A complete copy of a blockchain ledger may be included in a blockchain network (e.g., Figure 1 Each transaction executed within the routing network 106 of the ledger. Each entry (e.g., block) in the ledger may contain a hash of the previous entry. This has the effect of creating a series of blocks from the genesis block to the current block. Each block is guaranteed to be chronologically after the previous block, because the hash of the previous block would not otherwise be known. It is also computationally impractical to modify each block once it has been in the series of blocks for a period of time, because each block after the block must also be regenerated. These properties make the blockchain ledger relatively secure and tamper-proof.

[0084] In some embodiments, when the functionality of blockchain provider 502 is Figure 4 When accessed or executed by the blockchain router 402 of the embodiment of the present invention, one or more routing tables and / or one or more forwarding tables may be maintained as a single or separate blockchain ledger. Therefore, the routing / forwarding table corresponding to the routing controller may be stored as a blockchain ledger. Similarly, the routing / forwarding table corresponding to the inter-network routing controller may be stored as a blockchain ledger.

[0085] In some embodiments, the blockchain ledger management engine 514 may be configured to cause the processor 504 to store any suitable combination of one or more blockchain ledgers. As an example, the blockchain ledger management engine 514 may be configured to store the blockchain ledger in a data store 516, a storage location configured to store such information. The data store 516 may exist as part of the local memory 510 of the blockchain provider 502, or the processor 504 may have access to the data store 516, but the data store exists external to the blockchain provider 502.

[0086] In some embodiments, the blockchain ledger management engine 514 may be configured to cause the processor 504 to perform operations for transmitting / receiving data messages between blockchain providers of a distributed blockchain. A distributed blockchain may include any suitable number of blockchain providers that are collectively responsible for maintaining one or more blockchain ledgers.

[0087] Figure 6 Depicts an example overlay network that may be implemented in accordance with at least some embodiments. Figure 6 , an overlay network 602 is depicted as including a plurality of nodes 604. Some of the nodes 604 may be blockchain routers 606, which act as entry / exit points for various network participants. In at least some embodiments, each of the nodes of the overlay network may act as a controller as described herein. The overlay network 602 may be a consortium (or federation) blockchain network in which only member entities may participate.

[0088] In some embodiments, policy data may be stored in a blockchain ledger associated with an overlay network. For example, as new policies are identified with respect to an overlay network and its participants, information about those policies may be written to a policy ledger and then distributed to participants of the overlay network. It should be noted that policy information distributed throughout an overlay network in this manner may become permanent by virtue of being included in a blockchain ledger format. Thus, a policy with respect to a particular participant may be associated with multiple transactions. In some embodiments, policy data may be stored in a database table (e.g., Figure 3 In the routing table 304 or forwarding table 306), the database table can be distributed to each of the participants of the overlay network.

[0089] In at least some embodiments, one or more policy files 608 (A to D) (e.g., smart contracts) may be provided to each node 604 of the overlay network 602 (e.g., by a network participant). The policy files 608 may relate to specific network participants and / or specific transaction types. In some cases, the policy document may relate to a transaction conducted between two specific network participants, a transaction conducted on behalf of a specific network participant, or a transaction conducted by a specific network participant. Upon receiving one of these policy documents 608, the node 604 may analyze the policy document 608 to identify the policies within the document. Each policy may be used by the node 604 to generate one or more interaction algorithms that can be used to govern the interactions between the network participants. For example, a first policy may indicate a first specific data format utilized by a first network participant, and a second policy may indicate a second specific data format utilized by a second network participant. In this example, the policy data may be updated to include a conversion algorithm that converts data from a first format to a second format and vice versa. In some embodiments, the overlay network may maintain a standard data format used by the overlay network. In these embodiments, a first interactive algorithm may be used to convert information between a first specific data format and a standard data format, and a second interactive algorithm may be used to convert information between a second specific data format and a standard data format. In this way, the controller may convert between a first specific data format and a second specific data format by using the standard data format as an intermediate data format.

[0090] In some embodiments, data may be routed within the overlay network based on an algorithm for routing data included in the policy. For example, one or more blockchain networks may be accessed by each of the blockchain routers. In order to reach a specific network address, a message may be transmitted between a plurality of these blockchain routers. In some embodiments, the policy may indicate costs (e.g., monetary costs and / or resource costs) and / or restrictions (e.g., types of data that may be routed) associated with using a specific blockchain router 606 of the overlay network. A controller of the overlay network that may be implemented on one of the blockchain routers 606 may identify a routing path based on stored policy data. In some embodiments, the controller may identify a policy associated with an entity requesting routing of a message to determine how the message should be routed (e.g., what restrictions should be implemented, what costs should be minimized, etc.). For example, the controller may identify a policy associated with an entity submitting a message, the policy indicating that a routing path for the message should be identified so as to minimize a specific cost (e.g., monetary cost). In this instance, the controller may identify a plurality of available routes for the message, and may identify the best route from the routes identified based on the route with the minimum cost of the available routes. In some embodiments, an entity may have a not-exceeding restriction that indicates that the message is routed unless the controller is able to identify a route whose cost does not exceed a predetermined value.

[0091] In some embodiments, the overlay network may maintain policies associated with specific types of tasks that may be performed. For example, the overlay network may be used to perform tasks related to asset management, fraud dispute resolution, auditing and policy enforcement, trust management, underwriting, registration (e.g., enrollment), verification / aggregation, or any other suitable service. The controller, upon receiving a request from a participant using the overlay system to complete a task, may determine which participants are in compliance with the policies maintained by the controller. In some embodiments, each portion of completing a transaction may be governed by a different set of policies.

[0092] As an illustrative example, a first entity A may submit a request to complete a transaction related to a trust management service. In this example, the controller may determine that entity B is able to complete the requested transaction. In order to facilitate the transaction between two entities A and B, the controller may identify policies associated with each of the two entities. For example, the controller may determine that entity A needs to use a specific security protocol to perform each of its transactions. In this example, the controller may determine that entity B does use the required security protocol. In addition, the controller may determine the cost of the transaction with entity A in order for entity B to complete the transaction. The controller may then determine whether the cost is within an acceptable range governed by the policies associated with entity A.

[0093] Continuing with the above example, each of entities A and B may maintain a separate blockchain network with its own operational protocol. Upon determining that a transaction requested by entity A may be completed by entity B, the controller may identify an interaction algorithm within the policy data that may be used to convert data between format A used by entity A and format B used by entity B and vice versa. In some embodiments, this may involve a direct conversion between the two formats. In some embodiments, this may involve a conversion to an intermediate format (e.g., a standard format used by an overlay network). In this way, the blockchain networks associated with entity A and entity B each receive data in the format they require. In some embodiments, each of entity A and entity B may record the transaction to its own ledger.

[0094] Figure 7 A flow chart illustrating a process 700 for implementing interactions between network participants through policy enforcement is depicted in accordance with at least some embodiments. Some or all (or variations and / or combinations thereof) of any of the processes described herein may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications). In accordance with at least one embodiment, Figure 7 The process 700 may include at least Figure 2 The controller 202 or Figure 4The blockchain router 402 of the embodiment of the present invention is executed. The code may be stored on a computer-readable storage medium, for example in the form of a computer program including a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.

[0095] When a policy document is received by a controller, process 700 may begin at 702. In some embodiments, the policy document may be a smart contract or other electronic document with computer executable instructions. In some embodiments, the policy information may be provided by an administrator. The controller may receive policy documents related to multiple participants of a consortium.

[0096] At 704, the controller may obtain one or more interaction algorithms from the policy document. In some embodiments, the policy document may include computer-executable instructions to be implemented with respect to a particular overlay network participant. At 706, the controller may distribute the interaction algorithms within the policy document based on those computer-executable instructions.

[0097] At 708, the controller may receive a request to complete a transaction. The requested transaction may include an indication of a particular type of transaction to which the request relates. In some embodiments, the request for a transaction may include an indication to a network entity to complete the transaction. For example, the request for a transaction may indicate the entity with which the requester wishes to complete the transaction and the type of transaction to be completed. In some embodiments, the requested transaction may relate to asset management, fraud dispute resolution, auditing and policy enforcement, trust management, underwriting, registration (e.g., enrollment), verification / aggregation, or any other suitable service.

[0098] At 710, the controller may identify a policy associated with a requestor from which the request is received. For example, the request may include an indication of the identity of the requestor. In some embodiments, the requestor may be identified based on an address (e.g., an Internet Protocol (IP) address) from which the request originates. After identifying the requestor, the controller may query policy data to identify a set of policies related to the requestor. The policy may include restrictions related to the requested transaction. In another example, the controller may identify a format used by the identified requestor.

[0099] At 712, the controller may determine a second participant of the overlay network suitable for completing the requested transaction. This determination by the controller may be made based on a policy regarding the requester identity. For example, the controller may determine which entities are able to provide services associated with the request based on restrictions regarding the requester identity. In some embodiments, this may involve determining which entity is able to perform the requested service in a manner that optimizes or reduces one or more costs.

[0100] At 714, the controller may identify a policy associated with the determined second entity. For example, the controller may identify one or more costs, protocols, and / or routing requirements associated with performing the requested transaction with the identified entity. In another example, the controller may identify a format used by the identified entity, the identified entity being within a blockchain network in which it operates. In some embodiments, the policy associated with the entity completing the transaction and / or the requestor may include an indication of the access rights that various network participants may have with respect to data in the blockchain network. In some embodiments, the policy may include write permissions that various network participants may have with respect to data in the blockchain network. In some embodiments, at least one of the several groups of policies associated with the two entities may indicate which parties may interact with the entity (e.g., using the blockchain network associated with the entity).

[0101] At 716, the controller may facilitate completion of the transaction between the two overlay network participants. This facilitation by the controller may involve using both the policy regarding the requestor identification and the policy regarding the second participant identification. For example, the controller may identify a first data file format used by the requestor from a set of policies associated with the requestor, and identify a second data file format used by the entity from a set of policies associated with the entity identified to complete the transaction. In this example, the controller may convert data from the first format to the second format, and vice versa, according to the policy.

[0102] Embodiments of the present invention provide a number of technical advantages. For example, embodiments of the present invention enable interactions between various blockchain networks by enforcing policies. Conventional systems are generally unable to reach consensus between two entities with different policies. Therefore, the technology described herein provides an overlay network that provides policy enforcement of transactions, wherein the policies to be enforced by the overlay network are maintained by some or all of the overlay network participants. This eliminates the need for participants to interact using a centralized network such as the Internet while providing a technique for reaching consensus. Therefore, the privacy of the data being exchanged can be protected to a greater extent than possible using standard message protocols utilized by the Internet while enforcing the rights and policies associated with the participants of the system.

[0103] Additionally, in some embodiments, the techniques provided herein enable monetization of network routing, and routing / functional decisions can be performed using such monetary costs. Such costs can be collected through traditional billing / payment processes. Policies maintained for each participant allow those participants to outline the costs that may be incurred for using any particular service, while also indicating which services should be used.

[0104] It should be understood that any of the embodiments of the present invention can be implemented in the form of control logic using hardware (e.g., an application specific integrated circuit or a field programmable gate array) and / or using computer software, wherein a general purpose programmable processor is modular or integrated. As used herein, a processor includes a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will know and understand other ways and / or methods of implementing embodiments of the present invention using hardware and a combination of hardware and software.

[0105] Any software components or functions described in this application may be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, suitable media including random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a compact disk (CD) or digital versatile disk (DVD), flash memory, etc. The computer-readable medium may be any combination of such storage devices or transmission devices.

[0106] Such programs can also be encoded and transmitted using carrier signals suitable for transmission by wired, optical and / or wireless networks that meet multiple protocols including the Internet. Therefore, the computer-readable medium according to an embodiment of the present invention can be created using data signals encoded with such programs. The computer-readable medium encoded with program code can be packaged with compatible devices or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or in a single computer product (e.g., a hard drive, a CD, or an entire computer system), and can be present on or in different computer products within a system or network. The computer system may include a monitor, a printer, or other suitable displays for providing any result mentioned herein to the user.

[0107] The above description is illustrative rather than restrictive. After those skilled in the art have read this disclosure, many variations of the present invention will become apparent. Therefore, the scope of the present invention should not be determined with reference to the above description, but should be determined with reference to the pending claims and their full scope or equivalent.

[0108] One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0109] Unless specifically indicated to the contrary, the mention of "a," "an," or "the" is intended to mean "one or more."

[0110] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. No admission is made that they are prior art.

Claims

1. A computer-implemented method comprising: Receiving, by a controller included in the overlay network, a request from a first entity associated with a first blockchain network to conduct a transaction through the overlay network; identifying a first set of policies, the first set of policies comprising information associated with interacting with the first entity; determining, based on the first set of policies, a second entity associated with a second blockchain network with which to conduct the transaction; identifying a second set of policies, the second set of policies comprising information associated with interacting with the second entity; determining whether the first entity can interact with the second entity based on the first set of policies or the second set of policies; as well as In response to successfully determining that the first entity can interact with the second entity, facilitating the transaction between the first entity and the second entity over the overlay network, the facilitating comprising: generating an interaction algorithm based on the first set of policies and the second set of policies, the interaction algorithm comprising: one or more rules for completing the transaction between the first entity associated with the first blockchain network and the second entity associated with the second blockchain network; and instructions for converting information in a first format used by the first blockchain network into a second format used by the second blockchain network; Using the interaction algorithm, convert information of the transaction in the first format used by the first blockchain network into the second format used by the second blockchain network; selecting, by the controller based on the interaction algorithm, a subset of a plurality of routers in the overlay network to route the transaction from the first entity to the second entity; and The transaction is routed from the first entity to the second entity using a subset of the plurality of routers.

2. The computer-implemented method of claim 1 , wherein at least one of the first set of policies or the second set of policies indicates access rights of the first entity with respect to data stored in the second blockchain network.

3. The computer-implemented method of claim 1 , wherein at least one of the first set of policies or the second set of policies indicates write permissions of the first entity to the second blockchain network. 4 . The computer-implemented method of claim 1 , wherein at least one of the first entity or the second entity is a person or a computer network. 5 . The computer-implemented method of claim 1 , wherein the first set of policies is identified based on a network address associated with the first entity.

6. The computer-implemented method of claim 1, wherein the transaction involves at least one of trust management, fraud and disputes, underwriting, data routing, policy enforcement, or member services.

7. The computer-implemented method of claim 1, wherein the first set of policies is generated from a policy document received regarding the first entity.

8. The computer-implemented method of claim 1, wherein the policy document received with respect to the first entity comprises a smart contract.

9. A blockchain node server, comprising: processor, and A computer readable medium coupled to the processor, the computer readable medium comprising code for causing the processor to: receiving a request from a first entity associated with a first blockchain network to conduct a transaction over an overlay network; identifying a first set of policies, the first set of policies comprising information associated with interacting with the first entity; determining, based on the first set of policies, a second entity associated with a second blockchain network with which to conduct the transaction; identifying a second set of policies, the second set of policies comprising information associated with interacting with the second entity; determining whether the first entity can interact with the second entity based on the first set of policies or the second set of policies; as well as responsive to successfully determining that the first entity can interact with the second entity, facilitating the transaction between the first entity and the second entity over the overlay network using the first set of policies and the second set of policies, wherein the processor is further configured to: (i) generate an interaction algorithm based on the first set of policies and the second set of policies, the interaction algorithm comprising: one or more rules for completing the transaction between the first entity associated with the first blockchain network and the second entity associated with the second blockchain network; and instructions for converting information in a first format used by the first blockchain network to a second format used by the second blockchain network; (ii) convert information of the transaction in the first format used by the first blockchain network to the second format used by the second blockchain network using the interaction algorithm; (iii) select a subset of a plurality of routers in the overlay network based on the interaction algorithm to route the transaction from the first entity to the second entity; and (iv) The transaction is routed from the first entity to the second entity using a subset of the plurality of routers.

10. The blockchain node server of claim 9, wherein the first set of policies indicates a first data file format associated with the first entity, and the second set of policies indicates a second data file format associated with the second entity.

11. The blockchain node server according to claim 9, wherein an intermediate data file format is used to convert the information of the transaction from the first format to the second format.

12. The blockchain node server of claim 9, wherein the first set of policies and the second set of policies are assigned to at least the first entity and the second entity within a blockchain ledger.

Images