WO2020010270A1

WO2020010270A1 - Dynamic routing using a distributed hash table

Info

Publication number: WO2020010270A1
Application number: PCT/US2019/040632
Authority: WO
Inventors: Jonh Hyeop KIM
Original assignee: Neji, Inc.
Priority date: 2018-07-04
Filing date: 2019-07-03
Publication date: 2020-01-09

Abstract

Embodiments for sharing data within a network or creating networking groups in a distributed peer-to-peer network using an agreed upon key and a distributed hash table (DHT) process. The DHT comprises an abstract keyspace and a partitioning scheme that splits ownership of the keyspace among participating nodes. The DHT is a scalable, decentralized data structure in which a large key-value table is stored among the network nodes, such that each node only hosts a small chunk of a key space. The mapping from keys to values is distributed among the nodes such that a change in the network nodes causes a minimal amount of disruption to the network.

Description

DYNAMIC ROUTING USING A DISTRIBUTED HASH TABLE

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No.

62/693,944, filed on July 4, 2018 and U.S. Provisional Application No. 62/779,357, filed on December 13, 2018. All of which are incorporated by reference in their entirety.

TECHNICAL FIELD

[0002] Embodiments are generally directed to network communications, and more specifically to implementing dynamic routing using a distributed hash table, such as for routing programmable network packets using smart contracts accessed from a blockchain.

COPYRIGHT NOTICE

[0003] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND

[0004] A peer-to-peer (P2P) network architecture is a distributed application architecture that partitions tasks between the nodes (peers) of the network. In such a network, equal peer nodes simultaneously function as both clients and servers to the other nodes of the network, in contrast to the traditional client-server model where communication is typically to and from a central server. [0005] Peer-to-peer networks generally implement some form of virtual overlay network on top of the physical network topology, where the nodes in the overlay form a subset of the nodes in the physical network. Data is exchanged directly over the underlying TCP/IP network, but peers are able to communicate with each other directly at the application level through the logical overlay links, each of which corresponds to a path through the underlying physical network. Such overlays are used for indexing and peer discovery, and make the P2P system independent from the physical network topology.

[0006] In structured P2P networks, the overlay is organized into a specific topology, and the protocol ensures that any node can efficiently search the network for a file or other resource. Common structured P2P networks implement a distributed hash table (DHT) in which a variant of consistent hashing is used to assign ownership of each file to a particular peer. This enables peers to search for resources on the network using a hash table, i.e.,

(key, value) pairs are stored in the DHT, and any participating node can efficiently retrieve the value associated with a given key. However, in order to route traffic efficiently through the network, nodes must maintain lists of neighbors that satisfy specific criteria. This makes them less robust in networks with a high rate of churn (i.e. with large numbers of nodes frequently joining and leaving the network). Such static routing protocols also impose a great deal of administrative and processing overhead by requiring strict maintenance of neighbor lists and routing tables in each node of the network.

[0007] What is needed therefore, is a system and method that implements dynamic routing among nodes in a peer-to-peer network.

[0008] The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.

INCORPORATION BY REFERENCE

[0009] Each publication, patent, and/or patent application mentioned in this specification is herein incorporated by reference in its entirety to the same extent as if each individual publication and/or patent application was specifically and individually indicated to be incorporated by reference.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In the following drawings like reference numerals designate like structural elements. Although the figures depict various examples, the one or more embodiments and implementations described herein are not limited to the examples depicted in the figures.

[0011] FIG. 1 illustrates a large-scale network including wired and wireless links that includes a packet control process for implementing dynamic network routing under some embodiments.

[0012] FIG. 2 illustrates an example of a distributed hash table that may be used in a distributed network, such as network 100, under some embodiments.

[0013] FIG. 3 illustrates a peer-to-peer network for joining a new node, under some embodiments.

[0014] FIG. 4 is a flowchart that illustrates a method of performing a network join using a network key and DHT, under some embodiments.

[0015] FIG. 5 is a flowchart that illustrates a method of seeing network participants using a network key and DHT, under some embodiments. [0016] FIG. 6 is a table 600 that shows a small section of a larger DHT, where two example nodes are illustrated.

[0017] FIG. 7 illustrates an example network that uses smart contracts in conjunction with dynamic routing, under some embodiments.

[0018] FIG. 8 is a block diagram of a computer system used to execute one or more software components of a programmable network packet system, under some embodiments.

DETAILED DESCRIPTION

[0019] A detailed description of one or more embodiments is provided below along with accompanying figures that illustrate the principles of the described embodiments. While aspects of the invention are described in conjunction with such embodiments, it should be understood that it is not limited to any one embodiment. On the contrary, the scope is limited only by the claims and the invention encompasses numerous alternatives, modifications, and equivalents. For the purpose of example, numerous specific details are set forth in the following description in order to provide a thorough understanding of the described embodiments, which may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the embodiments has not been described in detail so that the described embodiments are not unnecessarily obscured.

[0020] It should be appreciated that the described embodiments can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer-readable medium such as a computer-readable storage medium containing computer-readable instructions or computer program code, or as a computer program product, comprising a computer-usable medium having a computer-readable program code embodied therein. In the context of this disclosure, a computer-usable medium or computer- readable medium may be any physical medium that can contain or store the program for use by or in connection with the instruction execution system, apparatus or device. For example, the computer-readable storage medium or computer-usable medium may be, but is not limited to, a random-access memory (RAM), read-only memory (ROM), or a persistent store, such as a mass storage device, hard drives, CDROM, DVDROM, tape, erasable

programmable read-only memory (EPROM or flash memory), or any magnetic,

electromagnetic, optical, or electrical means or system, apparatus or device for storing information. Alternatively, or additionally, the computer-readable storage medium or computer-usable medium may be any combination of these devices or even paper or another suitable medium upon which the program code is printed, as the program code can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

[0021] Applications, software programs or computer-readable instructions may be referred to as components or modules. Applications may be hardwired or hard coded in hardware or take the form of software executing on a general-purpose computer or be hardwired or hard coded in hardware such that when the software is loaded into and/or executed by the computer, the computer becomes an apparatus for practicing the invention. Applications may also be downloaded, in whole or in part, through the use of a software development kit or toolkit that enables the creation and implementation of the described embodiments. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the described embodiments.

[0022] Embodiments are directed to a process and system of providing dynamic routing of network packets in IP networks that may include mesh, wired, and wireless networks. FIG. 1 illustrates a large-scale network that implements a dynamic routing process under some embodiments. As shown in FIG. 1, mesh network 100 comprises a number of network elements such as wireless and/or wired routers 101, computers (servers, desktops, laptops, etc.) 103, transmission interfaces, gateways 105, and the like. Network 100 includes different types of links, such as wireless links 110, wired links 114, and long-distance transmission links 112 that utilize antennas 107.

[0023] Each device or network element represents a node in the network and is coupled to at least one or more other nodes for transmission of messages (data packets) in accordance with defined routing protocols. In a wireless mesh network (WMN), mesh clients are typically computers (e.g., 111), laptop/notebook computers (e.g., 103), tablets, cell phones and other wireless devices while the mesh routers forward traffic to and from the gateways (e.g., 105), which may be connected to the Internet. The wireless protocols may be implemented using IEEE 802.1, Bluetooth, or any other appropriate wireless standard. The transmission links 110 may represent cellular communication links or any other telephonic or WAN/LAN network link, and wired links 114 may be implemented using copper, fiber, or any other appropriate hardwired link. FIG. 1 illustrates one example of a large-scale WMN, and embodiments are not so limited. A mesh network of any size, composition, and transmission media over some or all of the links may be used. Though network 100 illustrates a partial mesh network in which not every node is connected to every other node, a mesh network under embodiments may be a fully meshed network or partial network, or a hybrid network including full and/or partial sub -networks.

[0024] Network 100 may include any number of sub-networks that may be wired or wireless LAN or mesh networks containing different devices or network elements. Each device may be assigned a unique network address (e.g., "lO.x.y.z") that specifies a network, sub-network, and device identifier, or similar unique attribute. It should be noted that FIG. 1 illustrates an example network and many different network configurations and topographies are possible.

[0025] System 100 may represent any peer-to-peer network or hybrid network (including mesh networks or subnetworks) that comprises and/or integrates both client server and P2P networks. Embodiments of system 100 include a server 102 that executes a dynamic routing process 104 and DHT processing function 105 that may be resident and/or executed in one or more nodes of the network to implement a DHT based dynamic routing system that uses an agreed upon key to facilitate sharing of data or creating network groups or sub-networks. Thus, embodiments are directed to systems and methods of sharing data within a network using an agreed upon key. Embodiments are further directed to systems and methods of creating networking groups with an agreed upon key within the network. Server 102 may represent a bootstrap server that provides certain code elements to new nodes for joining the network.

Dynamic Hash Table

[0026] In an embodiment, certain DHT processing steps are performed by a DHT processor 105 associated with or executed in conjunction with dynamic routing process 104. Embodiments use a DHT to implement certain aspects of the dynamic routing method. In general, a distributed hash table is a scalable, decentralized data structure often used in peer- to-peer networks, in which a large key-value table is stored among many network nodes, such that each node only hosts a small chunk of the key space, with redundancy to account for nodes leaving/joining the network. Keys and values can be added (written) or looked up (read) by communicating with the node(s) which own the corresponding key space. It provides a lookup where (key, value) pairs are stored in a DHT, and any participating node can efficiently retrieve the value associated with a given key. Responsibility for maintaining the mapping from keys to values is distributed among the nodes, in such a way that a change in the set of participants causes a minimal amount of disruption. This allows a DHT to scale up to extremely large numbers of nodes and to handle continual node arrivals, departures, and failures

[0027] FIG. 2 illustrates an example of a DHT that may be used in a distributed network, such as network 100, under some embodiments. For this illustrative example, DHT 200 includes data elements 130, which are each hashed using a hash function 132 to create respective keys 134. The data 130 that is hashed include the network name, or a node's public key identifier, or other similar data. These are hashed using unique hash functions 132 to form respective DHT keys 134. These keys are then provided to appropriate peers 138 in the distributed network 136. Additional data, such as any data that is wished to be shared among the nodes, is stored as values for these keys. Such value data could include data such as node identifiers or verifiable data like node name/number, IP address, node attributes, device types, user names, and so on. Thus, data such as node name, IP/port, attributes, configuration data, user/system profile data, routing/processing requirements, and so on, are stored as values in a table and referenced by keys that are formed by hashing the network name or node public key ID.

[0028] I he structure of a distributed hash table comprises an abstract keyspace, (e.g., a set of 160-bit strings), and a keyspace partitioning scheme that splits ownership of this keyspace among the participating nodes. An overlay network then connects the nodes, allowing them to find the owner of any given key in the keyspace. A typical use of the DHT for storage and retrieval might be to index a file with given filename and data in the DHT. In this case, the SHA (e.g., SHA-l) hash of filename is generated, producing a 160-bit key k, and a message put(k, data) is sent to any node participating in the DHT. The message is forwarded from node to node through the overlay network until it reaches the single node responsible for key k as specified by the keyspace partitioning. That node then stores the key and the data. Any other client can then retrieve the contents of the file by again hashing filename to produce k and asking any DHT node to find the data associated with k with a message get(k). The message will again be routed through the overlay to the node responsible for k, which will reply with the stored data. Several different key space partitioning and overlay network components may be used to map keys to nodes, such as consistent hashing or rendezvous hashing, as may be known to those of ordinary skill in the art. In general, each node maintains a set of links to other nodes. Together, these links form the overlay network. A node picks its neighbors according to the network topology.

[0029] Present TCP/IP networks use the Domain Name System (DNS), which is a hierarchical naming system for computers, services, or other resources connected to the Internet or a private network. It associates various information with domain names assi gned to each of the participating entities. It translates more readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. Embodiments of the dynamic routing process 104 expand and improve present DNS-based routing protocols by: (1) scaling the number of entity identifiers without limit to overcome the present IP address allocations under IPv4, which presently has address space scaling issues because addresses are limited to 32 bits; (2) allowing for discovery of peers without a centralized system; and (3) providing for a true distributed domain name system.

Network Join Process

[0030] Aspects of the dynamic routing process can be used to facilitate a node discovering and joining a network dynamically and without the necessary processing under standard static, DNS procedures. FIG. 3 illustrates an example peer-to-peer network joining a new node, under some embodiments. In diagram 300 of FIG. 3, an existing network 302 comprising nodes A, B, C, and D, are to be joined by a new node E. An agreed upon network key 304 is used as the mechanism to establish credentials and serve as the secure mechanism to enable the DHT -based join process.

[0031] In general, a network key (e.g., key 304) is a password, passphrase, or other alphanumeric string that is known to appropriate nodes of the network. For security purposes it should be a long, arbitrary string that is hard to guess or crack. It is typically distributed to network node users or administrators through non-network means, such as through physical exchange, word-of-mouth, escrow exchange, or other secure exchange method. Depending on the network implementation, the network key may be any appropriate key agreed upon by the network users.

[0032] FIG. 4 is a flowchart that illustrates a method of performing a network join using a network key and DHT, under some embodiments. In step 402, the new node (e.g., Node E) is told the network key, which will be used to discover and join the network 202. The new node connects to the DHT by first talking to bootstrap servers, and downloads a small section of DHT’ s data which this new node will host, step 404. The new node hashes the network key and finds the network entry in the DHT, step 406. The hash function for this step 406 may be predefined and agreed upon by the network nodes, such as a SHA of a known string (e.g., SHA-256 of string“marconi”). The new node signs information which it will share with the network. This signing process comprises information includes signing verifiable node data (e.g., IP address and port number), which is signed using the new node’s private key, step 408. The process then encrypts the verifiable node data and the node’s public key using the network key, step 410; and appends the network encrypted verifiable node data to the entry in the DHT for the network key, step 412. The new node can then broadcast out the updated DHT to the network it just joined, step 414. Seeing Network Participants

[0033] FIG. 5 is a flowchart that illustrates a method of seeing network participants using a network key and DHT, under some embodiments. In step 502, the new node (e.g., Node E) is told the network key, which will be used to discover and see the nodes of the network 202. The new node connects to the DHT by first talking to bootstrap servers, and downloads a small section of DHT’ s data which this new node will host, step 504. The new node hashes the network key and finds the network entry in the DHT, step 506. The hash function for this step 506 may be predefined and agreed upon by the network nodes, such as a SHA of a known string (e.g., SHA-256 of string“marconi”). The new node can then obtain data from each network participant by verifying certain information shared with it, step 508. The node verifies that each participant knows the network key because the network encrypted verifiable node data is correctly encrypted using the network key, step 510. It then verifies that the verifiable node data is actually from the participant because it is properly signed with the participant’s private key, step 512.

[0034] In general, a DHT may be stored on many nodes and may be embodied in a correspondingly large table, such as of a size proportional to the number of nodes. FIG. 6 is a table 600 that shows a small section of a larger DHT, where two example nodes are illustrated. Table 600 shows a DHT portion for two specific nodes denoted "alice" and "bob" have joined two separate private networks names "marconi" and "networkl." FIG. 6 is provided for purposes of example only, and the structure and content of a DHT may be different depending on system configurations and requirements. alice_data = tuple< sign_alice (concat (alice_ip, alice_port) ) , public_key_alice >

bob_data = tuple< sign_bob (concat (bob_ip, bob_port) ) , public_key_bob

> DHT_key = hash ( "marconi " )

DHT_value = list[

encrypt (derive_encryption_key ( "marconi" ) , alice_data) ,

encrypt (derive_encryption_key ( "marconi" ) , bob_data)

Blockchain and Smart Contract Implementation

[0035] In general, a blockchain can include a history of data, messages, or transactions in a series of blocks where each block contains a mathematical summary, called a hash, of the previous block. This creates a blockchain where any changes made to a block will change that block's hash, which must be recomputed and stored in the next block. This changes the hash of the next block, which must also be recomputed and so on until the end of the chain.

In the illustrated example, Block 0 has a hash“0x3a34ad...55.” The next Block 1 includes the hash“0xf6elda2...deb” and the previous (Block 0) hash“0x3a34ad...55.” The following Block 2 includes the hash“0x9327eblb.. 36a2l” and the previous block’s hash

“0xf6elda2...deb”

[0036] The hash is based on a mathematical function that is not reversible and system users cannot predict what input can be used to produce the desired output. A valid hash can be found by repeatedly adjusting a changeable value in the block, which is known as a “nonce.” The nonce can be adjusted and the hash can be recalculated until a valid hash is found that meets the validity requirements. The unpredictable nature of the hash considerably increases the difficulty of finding a nonce that produces a valid hash of the block. Typically, trillions of different nonces may be tried before a valid hash is found. Therefore, changing the value of previously stored data in the blockchain can require a substantial amount of computational effort, although not impossible. The security of the blockchain is further enhanced by storing the blockchain data on a distributed network. A large number of users can have access to the blockchain network and miner nodes can be continuously attempting to add blocks to the end of the blockchain by finding a nonce that produces a valid hash for a given block of data.

[0037] Blockchains can be used with various types of transactions. For example, a transaction can use identity tokens for physical or digital assets. The identity tokens can be generated using a cryptographic hash of information that uniquely identifies the asset. The tokens can also have an owner that uses an additional public/private key pair. The owner of a public key can be set as the token owner identity and when performing actions against tokens, ownership proof can be established by providing a signature generated by the owner private key and validated against the public key listed as the owner of the token. The identity token for an entity may be the public key of a public/private key pair, where the private key is held by the entity. The creation of an identity token for an asset in a blockchain can establish a provenance of the asset, and the identity token can be used in transactions of the asset stored in a blockchain, creating a full audit trail of the transactions.

[0038] To record a simple transaction in a blockchain, each party and asset involved with the transaction needs an account that is identified by a digital token. For example, when one person wants to transfer an asset to another person, the current owner and next owner create accounts, and the current owner also creates an account that is uniquely identified by an asset identification number. The account for the asset identifies the current owner. With reference to FIG. 4 a flowchart for a simple transaction is illustrated. The current asset owner creates a transaction against the account for the asset that indicates: 1) the transaction is a transfer of ownership, 2) the public keys (i.e., identity tokens) of the current owner and the next owner, 3) the identity token of the physical asset, and 4) the transaction is signed by the private key of the current owner. The current owner of the asset can create a transaction request that includes the transaction information on a user interface of a computing device. The transaction request can be broadcast to the blockchain network. If the blockchain network of nodes does not validate the transaction, the transaction is stopped and the transfer of ownership is not recorded. If the blockchain network of nodes validates and verifies the transaction, the transaction is combined with other transactions occurring at the same time to form data for a new block and the new block is added to the blockchain. The recorded transaction in the blockchain is evidence that the next owner identified in the transaction request is now the current owner.

[0039] To enable more complex transactions, a blockchain system can use "smart contracts" which is computer code that implements transactions of a contract. The computer code may be executed in a secure platform that supports recording transactions in

blockchains. In addition, the smart contract itself can be recorded as a transaction in the blockchain using an identity token that is a hash of the computer code so that the computer code that is executed can be authenticated. When deployed, a constructor of the smart contract executes initializing the smart contract and its state. The state of a smart contract is stored persistently in the blockchain. When a transaction is recorded against a smart contract, a message is sent to the smart contract and the computer code of the smart contract executes to implement the transaction. The computer code ensures that all the terms of the contract are complied with before the transaction is recorded in the blockchain. For example, a smart contract may support the sale of an asset. The inputs to a smart contract to sell the asset may be the identity tokens of the seller, the buyer, and the asset and the sale price. The computer code ensures that the seller is the current owner of the asset and that the buyer has sufficient funds in their account. The computer code then records a transaction that transfers the ownership of the asset to the buyer and a transaction that transfers the sale price from the buyer's account to the seller's account. If either transaction is not successful, neither transaction is recorded in the blockchain. [0040] When a message is sent to a smart contract to record a transaction, the message is sent to each node that maintains a replica of the blockchain. Each node can execute the computer code of the smart contract to implement the transaction. For example, if all nodes each maintain a replica of a blockchain, then the computer code is executed at each of the nodes. When a node completes the execution of the computer code, the results of the transaction are recorded in the blockchain. The nodes can employ a consensus algorithm to decide on which transactions to record and which transactions to discard. A majority of the nodes must verify the transaction, in order for the transaction to be recorded on the blockchain. The execution of the computer code at each node helps ensure the authenticity of the blockchain.

[0041] Embodiments of the dynamic routing method using a DHT mechanism may be used in a blockchain network data structure may that may include a DHT peer-to-peer storage protocol. A peer-to-peer storage protocol may be a protocol for storing data in a distributed fashion among nodes in a network such as the Internet. As described above, a DHT maps elements of data, such as data files or the names of data files, to keys in a keyspace. The keys may be created by hashing the elements of data; for instance, all keys in the keyspace of a particular DHT may be created by hashing each element of data using a hashing algorithm, such as the Secure Hash Algorithm ("SHA-l"), producing uniformly sized keys having sensitive and reproducible relationships to the data elements to which they correspond.

The DHT may define a "distance" function within the key space that assigns any pair of keys a distance, analogous to geometric distance, between the pair of keys. The DHT may include an overlay network, which labels data storage elements, such as memories of computer devices as nodes in the network; each node in the overlay network may provide information, for each key, that indicates either that the key corresponds to data stored at that node, or that a proximal node stores keys closer to the key according to the distance function. In some embodiments, keys are assigned to nodes in the overlay network according to their distances, so that adjacent nodes in the network have keys that are close to each other according to the distance function. In other embodiments, where particular nodes must possess particular data, the topology of the overlay network shifts, in response to data acquisition, so that adjacent nodes have closer keys. The data may be secured: security protocols may prevent one node from accessing the data possessed by another node without authentication information pertaining to the possessing node, such that the only freely available information in the DHT is the set of keys and the information concerning nodes possessing their

corresponding data. In some embodiments, some data in the DHT is secured and other data is not secured. Keys from the DHT may be included in the blockchain via merge hashing; the keys may be incorporated via a Merkle tree.

[0042] Under an embodiment, programmable network packets processed through dynamic routing may be implemented through the use of a smart contract, such as smart contract 124 in FIG. 7. With smart packet contracts, developers have the ability to run smart contracts against network packets to do smart routing and packet processing. FIG. 7 illustrates an example network 700 that uses smart contracts in conjunction with dynamic routing, under some embodiments. The network connects peers 122 (which may be infrastructure service nodes, Internet-enabled computing devices, or network end users) through smart contracts 124 that are agreements between these peers defining how much data will be exchanged, for how long, what types of smart packet contracts will be enabled, and at what fuel price. The connections can be implemented through pipes 126 or wireless links 128.

[0043] A network driver may perform the following transformation function:

Smart Contract ==> Bytecode ==> Packet Header [0044] This embedded contract process produces a packet that comprises the data packet and an executable header portion in which the functions represented in the smart contract dictate how the packet is to be processed and is encoded as part of the packet itself to be executed by a smart packet processor in a receiving host. Essentially, the embedded contract process tags the smart contract to the packet header or encodes the processing instructions as part of the packet itself, where the instructions are provided as a smart contract to the incoming unprocessed packet. After the encoding step, the encoded packet is output as a processed packet from the network driver.

[0045] The embodiment above describes the use of nonce values. In general, a blockchain creates a history of data, messages, or transactions in a series of blocks where each block contains a hash of the previous block. This creates a chain of blocks where any changes made to a block will change that block's hash, which must be recomputed and stored in the next block. This changes the hash of the next block, which must also be recomputed and so on until the end of the chain. The hash is based on a mathematical function that is not reversible and system users cannot predict what input can be used to produce the desired output. A valid hash can be found by repeatedly adjusting a changeable value in the block, which is known as a“nonce.” The nonce can be adjusted and the hash can be recalculated until a valid hash is found that meets the validity requirements. The unpredictable nature of the hash considerably increases the difficulty of finding a nonce that produces a valid hash of the block. Typically, trillions of different nonces may be tried before a valid hash is found. Thus, though not impossible, changing the value of previously stored data in

the blockchain can require an impractical amount of computational effort.

System Implementation

[0055] As described above, in an embodiment, system 100 includes a dynamic routing process and mechanism that may be implemented as a computer implemented software process, or as a hardware component, or both in a computer such as server 102 in FIG. 1. As such, it may be an executable module executed by the one or more computers in the network, or it may be embodied as a hardware component or circuit provided in the system. The network environment of FIG. 1 may comprise any number of individual client-server networks coupled over the Internet or similar large-scale network or portion thereof. Each node in the network(s) comprises a computing device capable of executing software code to perform the processing steps described herein. FIG. 8 is a block diagram of a computer system used to execute one or more software components of process 104, under some embodiments. The computer system 1000 includes a monitor 1011, keyboard 1017, and mass storage devices 1020. Computer system 1000 further includes subsystems such as central processor 1010, system memory 1015, input/output (I/O) controller 1021, display adapter 1025, serial or universal serial bus (USB) port 1030, network interface 1035, and speaker 1040. The system may also be used with computer systems with additional or fewer subsystems. For example, a computer system could include more than one processor 1010 (i.e., a multiprocessor system) or a system may include a cache memory.

[0056] Arrows such as 1045 represent the system bus architecture of computer system 1000. However, these arrows are illustrative of any interconnection scheme serving to link the subsystems. For example, speaker 1040 could be connected to the other subsystems through a port or have an internal direct connection to central processor 1010. The processor may include multiple processors or a multicore processor, which may permit parallel processing of information. Computer system 1000 is an example of a computer system suitable for use with the present system. Other configurations of subsystems suitable for use with the present invention will be readily apparent to one of ordinary skill in the art.

[0057] Computer software products may be written in any of various suitable

programming languages. The computer software product may be an independent application with data input and data display modules. Alternatively, the computer software products may be classes that may be instantiated as distributed objects. The computer software products may also be component software.

[0058] Although certain embodiments have been described and illustrated with respect to certain example network topographies and node names and configurations, it should be understood that embodiments are not so limited, and any practical network topography is possible, and node names and configurations may be used. Likewise, certain specific programming syntax and data structures are provided herein. Such examples are intended to be for illustration only, and embodiments are not so limited. Any appropriate alternative language or programming convention may be used by those of ordinary skill in the art to achieve the functionality described.

[0059] Embodiments as described herein may be applied to mesh networks of any scale (full or partial), and may also be applied to any other physical, virtual or hybrid

physical/virtual network, such as a very large-scale wide area network (WAN), metropolitan area network (MAN), or cloud-based network system. Aspects of the one or more embodiments described herein may be implemented on one or more computers executing software instructions, and the computers may be networked in a client-server arrangement or similar distributed computer network. The network provides connectivity to the various systems, components, and resources, and may be implemented using protocols such as Transmission Control Protocol (TCP) and/or Internet Protocol (IP), well known in the relevant arts.

[0060] For the sake of clarity, the processes and methods herein have been illustrated with a specific flow, but it should be understood that other sequences may be possible and that some may be performed in parallel, without departing from the spirit of the invention. Additionally, steps may be subdivided or combined. As disclosed herein, software written in accordance with the present invention may be stored in some form of computer-readable medium, such as memory or CD-ROM, or transmitted over a network, and executed by a processor. More than one computer may be used, such as by using multiple computers in a parallel or load-sharing arrangement or distributing tasks across multiple computers such that, as a whole, they perform the functions of the components identified herein; i.e., they take the place of a single computer. Various functions described above may be performed by a single process or groups of processes, on a single computer or distributed over several computers. Processes may invoke other processes to handle certain tasks.

[0061] Unless the context clearly requires otherwise, throughout the description and the claims, the words“comprise,”“comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of“including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words“herein,”“hereunder,”“above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word“or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.

[0062] All references cited herein are intended to be incorporated by reference. While one or more implementations have been described by way of example and in terms of the specific embodiments, it is to be understood that one or more implementations are not limited to the disclosed embodiments. To the contrary, it is intended to cover various modifications and similar arrangements as would be apparent to those skilled in the art. Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.

Claims

CLAIMS What is claimed is:

1. A method of scaling a peer-to-peer network comprising:

distributing a known network key to a new node joining the network; connecting the new node to a distributed hash table (DHT) through a bootstrap server for downloading of DHT data hosted on the new node;

hashing, in the new node, the network key to find a network entry in the DHT; signing, by the new node, verifiable node data using the private key of the new node;

encrypting the verifiable node data and a public key of the new node using the network key to form encrypted verifiable node data;

appending the encrypted verifiable node data to the network entry in the DHT to form an updated DHT; and

broadcasting, from the new node, the updated DHT.

2. The method of claim 1 further comprising:

obtaining, in the new node, data for each participant node;

verifying that a participant node knows the network based on correct encryption of the encrypted verifiable node data by the participant node using the network key; and verifying that the encrypted verifiable node data is from the participant node based on proper signing with the participant node's private key.

3. The method of claim 2 wherein the distributed hash table storing key -value pairs is a scalable, decentralized data structure in which a large key-value table is stored among the network nodes, such that each node only hosts a small chunk of a key space.

4. The method of claim 3 wherein the keys and values are written or read by communicating with the node that owns the corresponding key space, and maintaining the mapping from keys to values is distributed among the nodes such that a change in the network nodes causes a minimal amount of disruption.

5. The method of claim 1 wherein the key comprises data including a network name or the node's public key identifier.

6. The method of claim 5 wherein the key further comprises additional data including data that is wished to be shared among the nodes and that is stored as values for the key.

7. The method of claim 6 wherein the additional data comprises a node identifier, and verifiable data such as node name/number, IP address, node attributes, device type, user and name, and so on.

8. The method of claim 6 wherein the additional data is stored as values in a table and referenced by keys that are formed by hashing the network name or node public key ID.

9. The method of claim 5 wherein the distributed hash table comprises an abstract keyspace and a keyspace partitioning scheme that splits ownership of the keyspace among participating nodes.

10. A system for scaling a peer-to-peer network comprising:

an interface connecting the new node to a distributed hash table (DHT) through a bootstrap server for downloading of DHT data hosted on the new node;

a first processing component hashing, in the new node, network key to find a network entry in the DHT, wherein the network key is was distributed to a new node joining the network, and wherein the new node provides verifiable node data using the private key of the new node; and

an encryption component encrypting the verifiable node data and a public key of the new node using the network key to form encrypted verifiable node data, and appending the encrypted verifiable node data to the network entry in the DHT to form an updated DHT, wherein the new node broadcasts the updated DHT.

11. The system of claim 10 further comprising:

the interface, obtaining, in the new node, data for each participant node; and a second component verifying that a participant node knows the network based on correct encryption of the encrypted verifiable node data by the participant node using the network key, and verifying that the encrypted verifiable node data is from the participant node based on proper signing with the participant node's private key.

12. The system of claim 11 wherein the distributed hash table storing key-value pairs is a scalable, decentralized data structure in which a large key-value table is stored among the network nodes, such that each node only hosts a small chunk of a key space.

13. The system of claim 12 wherein the keys and values are written or read by communicating with the node that owns the corresponding key space, and maintaining the mapping from keys to values is distributed among the nodes such that a change in the network nodes causes a minimal amount of disruption.

14. The system of claim 10 wherein the key comprises data including a network name or the node's public key identifier, and further comprises additional data including data that is wished to be shared among the nodes and that is stored as values for the key.

15. The system of claim 14 wherein the additional data comprises a node identifier, and verifiable data such as node name/number, IP address, node attributes, device type, user and name, and so on, and wherein the additional data is stored as values in a table and referenced by keys that are formed by hashing the network name or node public key ID.