CROSS-REFERENCE TO RELATED APPLICATIONS

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

62/634,804, filed February 24, 2018, and U.S. Provisional Application No. 62/644,188, filed March 16, 2018.

TECHNICAL FIELD

[0002] Embodiments are directed to forming a networking group with decentralized auditing and metering in a blockchain network system that includes a plurality of distributed nodes.

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] Blockchain technology has often been proposed as a solution to the problems inherent with centralized systems through decentralized computing, storage, and application suites to realize a decentralized future. However, present blockchain projects all continue to build atop the same underlying network infrastructure consisting of switches and routers connected by the Ethernet, a foundation which remains fragile due to several fundamental problems.

[0005] One problem is that the present global network infrastructure is insecure since it is powered by the Ethernet, a networking technology that has gone relatively unchanged for the past 30 plus years. The Ethernet was devised to focus on connectivity rather than security and has no encryption built in to its design. A second problem is that the core network

infrastructure is inflexible and difficult to manage. The switches, routers, and bridges that form the network are hardware driven and expensive to buy, configure, and maintain. A third problem is that current network infrastructures are centrally controlled. In any given region, a small number of entities (often just one or two Internet Service Providers) serve as the gateway for all Internet traffic. When the service provider suffers failures or outages, all users lose access.

[0006] As network sizes and complexities increase, identifying valid nodes and determining network node availability become paramount concerns. Present blockchain systems based on existing centralized, insecure and inflexible Ethernet networks do not provide adequate mechanisms to facilitate dynamic network formation for rapidly scaling systems.

[0007] What is needed, therefore, is a network protocol that provides decentralized auditing and metering of network nodes within large-scale systems that can leverage dynamic blockchains.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] 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. [0009] FIG. 1 illustrates a large-scale mesh network including wired and wireless links that implements a proof of network elements process, under some embodiments.

[0010] FIG. 2 illustrates implementation of a blockchain for use in network 100 of FIG.

1, under some embodiments.

[0011] FIG. 3 illustrates an example distributed network storing blockchain data.

[0012] FIG. 4 is a flowchart illustrating an example method of processing a transaction in a blockchain network.

[0013] FIG. 5 is a flowchart that illustrates a method of adding and validating a network node, under some embodiments.

[0014] FIG. 6 illustrates a boot and synchronization process of FIG. 5, under some embodiments.

[0015] FIG. 7 illustrates a communications diagram for the boot and synchronization process of FIG. 5 and the flowchart of FIG. 6, under some embodiments.

[0016] FIG. 8 is a flowchart that illustrates the PNSN registration process 504 of FIG. 5, under some embodiments.

[0017] FIG. 9 illustrates a communications diagram for the PNSN registration process of FIG. 5 and the flowchart of FIG. 8, under some embodiments.

[0018] FIG. 10 is a flowchart that illustrates the discovery and query process of FIG. 5, under some embodiments.

[0019] FIG. 11 illustrates a communications diagram for the discovery and query process of FIG. 5 and the flowchart of FIG. 10, under some embodiments.

[0020] FIG. 12 is a flowchart that illustrates the process for the joining negotiation to a peer network of FIG. 5, under some embodiments.

[0021] FIG. 13 is a communications diagram for the joining negotiation to a peer network of FIG. 5 and the flowchart of FIG. 12, under some embodiments. [0022] FIG. 14 is a flowchart that illustrates the process for the work maintenance transaction of FIG. 5, under some embodiments.

[0023] FIG. 15 is a communications diagram for the work maintenance transaction of FIG. 5 and the flowchart of FIG. 14, under some embodiments.

[0024] FIG. 16 illustrates a minimal node group that performs the proof of network element process, under some embodiments.

[0025] FIG. 17 is a flowchart illustrating a process of transmitting signed pings between parent and child nodes of a blockchain network, under some embodiments.

[0026] FIG. 18 is a communications diagram for the process of transmitting signed pings of FIG. 17, under some embodiments.

[0027] FIG. 19 is a graph showing the adjustment of nonce size to reach an optimum size over a time period, under some embodiments.

[0028] FIG. 20 is a graph showing consumption of nonces over the same time period of FIG. 19, under some embodiments.

[0029] FIG. 21 illustrates a method of adding a new node to a blockchain network and storing the transactions on the blockchain, under some embodiments.

[0030] FIG. 22 is a graph of data transmission speed through the n-triangle nodes as plotted against a data transmission (nonce) size, under an embodiment.

[0031] FIG. 23 illustrates a blockchain network configured with a plurality of n-triangles in communication with a database, under an example embodiment.

[0032] FIG. 24 illustrates peer nodes in an example blockchain network, under some embodiments.

[0033] FIG. 25 illustrates an example generic computer device and a generic mobile computer device, which may be used to implement the processes described herein. DETAILED DESCRIPTION

[0034] 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.

[0035] 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.

[0036] 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.

[0037] Embodiments are directed to a process and system of forming network groups within larger networks or systems using decentralized auditing and metering mechanisms to provide proof of network elements. FIG. 1 illustrates a large-scale network that implements a proof of network element 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 112, wired links, and long-distance transmission links 112 that utilize antennas 107. [0038] 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 112 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.

[0039] 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.

[0040] Nodes can be added to the network, or organized into sub-networks as provided by certain known networking protocols. In an embodiment, processes are provided to allow for adding network nodes and forming networking groups or sub-networks using certain de- centralized auditing and metering processes that utilize blockchain technology. [0041] FIG. 1 illustrates one example of a network topology, and embodiments are not so limited. A network of any practical scale, architecture, and configuration can be used with embodiments of the processes and components described herein.

Blockchain Technology

[0042] FIG. 1 illustrates a network system that implements blockchain and smart contract technology. A blockchain is a growing list of records (blocks) that are cryptographically linked. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data. A blockchain is resistant to modification of the data and represents an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. A blockchain is typically managed by a peer-to-peer network adhering to a protocol for internode communication and validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks, which requires consensus of the network majority. Blockchain technology can be integrated into multiple applications, such as cryptocurrencies and smart contracts. A smart contract is a protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of a contract. They allow the performance of credible transactions without third parties through transactions that are trackable and irreversible.

[0043] FIG. 2 illustrates implementation of a blockchain for use in network 100 of FIG.

1, under some embodiments. FIG. 2 illustrates an example chain of three blocks 201, 202, and 203 denoted respectively as Block 0, Block 1, and Block 2. As shown in FIG. 2, 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.”

[0044] 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.” In general, a nonce is an arbitrary random number that is used just once as an input to vary the input to the hash function. 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.

[0045] The security of the blockchain can be further enhanced by storing the blockchain data on a distributed network. FIG. 3 illustrates an example distributed network storing blockchain data. As shown in FIG. 3, a large number of users 302 attempting transactions 303 can have access to the blockchain network 304 and miner nodes 305 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.

[0046] 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.

[0047] 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. FIG. 4 is a flowchart illustrating an example method of processing a transaction in a blockchain network. The process of FIG. 4 starts when a 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, 402. The transaction request can be broadcast to the blockchain network, 404. If the blockchain network of nodes does not validate the transaction as determined in decision block 406, the transaction is stopped and the transfer of ownership is not recorded, 408. If, in block 406, 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, 410, and the new block is added to the blockchain, 412. The recorded transaction in the blockchain is evidence that the next owner identified in the transaction request is now the current owner. [0048] 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.

[0049] 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.

[0050] The blockchain network data structure may include a 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 one example, the peer-to-peer storage protocol may be a distributed hash table (DHT). In one embodiment, 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 through security protocols that 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 block chain via merge hashing; the keys may be incorporated via a Merkle tree.

Proof of Network Element Process

[0051] By storing data across its peer-to-peer network, such as network 304, the blockchain eliminates a number of risks associated with centralized data systems.

Embodiments of FIG. 1 provide a decentralized metering protocol that captures network node availability and bandwidth over time, and incentivizes network bootstrapping and continued network participation. For the embodiment of FIG. 1, system 100 includes a server computer 102 executing a proof of network elements process 104. Using this process, any three (or more) nodes on the same subnetwork can agree to participate in the network. They may also receive tokens or other reward or incentive-based acknowledgment upon each successful completion.

[0052] Using process 104, some node A initiates proof of network elements by first broadcasting to its neighbors and measuring the latency of their responses. Since lower latency will generally lead to accumulating more tokens, the node chooses the two closest neighbors B and C as peers for proof of network elements, and creates a transaction on the mesh chain establishing a smart contract which lists the public key hashes of these desired peer nodes. Each peer indicates its agreement to participate in proof of network elements by creating its own transaction to add its signature to the same smart contract. Once agreement occurs, the nodes form transmission pipes (mPipes) between one another. Node A then generates a nonce n and creates a transaction which adds a hash of n to a new smart contract. Node A then encrypts n with its private key and sends the result, EncryptA(n), to node B.

This receiving peer can verify the message by decrypting with A's public key. Then B repeats the process, yielding a message EncryptB (Encrypt A(n)) which it sends to C. Node C does the same, sending the payload EncryptC (EncryptB (Encrypt A(n)) back to A. Finally, A commits this payload to the mesh chain in a transaction that updates the existing smart contract. This payload can be verified by any node in the network 100 by using the public keys belonging to A, B, and C. This procedure is illustrated and described in greater detail below with reference to FIG. 16.

[0053] It should be noted that node A can simultaneously participate in proof of network elements in the opposite direction, by starting a separate smart contract and sending an encrypted nonce to C who sends to B who sends back to A. This allows measuring links bidirectionally, since there may be differences in bandwidth or latency in the real world depending on the direction of data. To demonstrate higher bandwidth, nodes can use larger nonces if their peers agree to it. Since nodes can keep repeating proof of network elements to keep gaining tokens, and since these completed exercises are all encoded in the mesh chain, over time they present a reasonably accurate view of bandwidth and availability for each node. While proof of network elements can potentially take a lot of bandwidth as well as space on the mesh chain, it can employ several mitigations such as truncating mesh chain data older than a defined period (e.g., six months) or sampling methods where nodes participate in proof of network elements for a small fraction of overall time.

[0054] In an embodiment, process 104 implements a specific process to add and validate a“potential network service node” (PNSN) to an existing validated blockchain computer node network, such as network 100. FIG. 5 is a flowchart that illustrates a method of adding and validating a network node, under some embodiments. With reference to FIG. 5, a general process can include boot and synchronization of the potential network node to the blockchain node network, 502. The next step 504 can be a registration transaction followed by DHT discovery and query 506. A negotiation join transaction process 508 can then be performed for the potential network node. A work transaction process 510 can be performed to measure the functionality and performance of the network nodes, which can be a node network maintenance process performed in a primary passive mode. Each of the listed processes of FIG. 5 is described in more detail below.

[0055] FIG. 6 is a flowchart that illustrates a boot and synchronization process 502 of FIG. 5, under some embodiments. As shown in FIG. 6, the PNSN can find blockchain network peers through network DHT via seed or bootstrap nodes, which may contain network peer information to the blockchain network, 602. The PNSN can transmit a boot request package through DHT network traffic to the seed or bootstrap nodes of the network. The boot request package can be transmitted by the PNSN with a defined protocol, such as user datagram protocol (UDP). Random potential network peer nodes can respond to the boot request by transmitting a response package back to the PNSN through DHT network traffic by the defined protocol, 604. The random potential network peer nodes and the PNSN can then synchronize by storing the boot request and response on the main blockchain and any off-chains from the main blockchain, 606. The blockchain synchronization communications can be transmitted through monitoring network traffic by transmission control protocol (TCP) and UDP, or other similar protocol.

[0056] FIG. 7 illustrates a communications diagram for the boot and synchronization process 502 of FIG. 5, under some embodiments. FIG. 7 illustrates some example

interactions between the PNSN 702 and the network 704. The PNSN first finds network peers through network DHT via seed or bootstrap nodes that contain only network peer information, 706. From network 704, random potential network peers respond through DHT, 708. The 706 and 708 transactions are performed using DHT network traffic (such as UDP). The PNSN and network then synchronize main blockchain and side chains using monitoring network traffic (e g., TCP and UDP), 710. [0057] FIG. 8 is a flowchart that illustrates a PNSN registration process 504 of FIG. 5, under some embodiments. As shown in FIG. 8, the PNSN can construct a blockchain registration transaction in the form of a smart contract that contains an infohash of the PNSN’s own public-key, an actual public-key, and a time window that defines how long the peer infohash is valid. The PNSN can broadcast the smart contract transaction package to the network peers through the blockchain network traffic in UDP. The transaction can be prepared for storage on the blockchain at block #n+0, 822. The registration transaction can be received by the network peers if the transaction storage occurs within the limited time window, 824. The latest blocks are synchronized including the previous transaction on the blockchain, 826.

[0058] In an embodiment, the limited time window storage of the registration transaction can be similar to a time to live (TTL) period. The transactions can be maintained in the blockchain according to the TTL time window set for the blockchain. For example, if the TTL time window is one minute, the registration transaction may be deleted from the block chain one minute after the registration transaction has been created. If the transaction or smart contract has expired prior to extending the TTL time 828, as determined in decision block 830, the peer infohash will be invalid and any transactions with expired TTL time windows, 832. These invalidated transactions can be removed from the blockchain.

[0059] In an embodiment, if necessary the PNSN can construct another transaction that can extend the TTL time window for the previous register self-transaction. The PNSN can broadcast this new blockchain transaction to extend the TTL time window to the network peers at block #n+l, 834. The latest blocks including the extended TTL time window transaction are synchronized and the described smart contract process can be repeated in subsequent transactions. [0060] FIG. 9 illustrates a communications diagram for the PNSN registration process 504 of FIG. 5, under some embodiments. FIG. 9 illustrates some example interactions between the PNSN and the network using blockchain network traffic (e.g., UDP). The process constructs a blockchain transaction as a smart contract that contains: infohash of own public key, actual public key, and duration of peer infohash validity. The PNSN broadcasts the blockchain transaction to the network peers at least block #n+0, 942. The transaction is stored in the blockchain for a limited time window similar to the TTL. The transactions can be read by other peers for constructing other transactions and/or generating a symmetric cryptography key. The PNSN and network then synchronize the latest blocks including the previous transaction, 944. The PNSN then broadcasts the blockchain transaction to the network peers at least block #n+l, 946. The PNSN and network then synchronize the latest blocks again, 948. The system can construct another transaction to extend the TTL for a previous register transaction. The peer infohash is rendered invalid if the transaction/smart contract expires.

[0061] FIG. 10 is a flowchart that illustrates the discovery and query process 506 of FIG. 5, under some embodiments. As shown in FIG. 10, the PNSN can find network peers by broadcasting a request package that includes a pre-shared public key which functions as a multicasting mechanism into DHT, 1002. The network cluster peers that have the same infohash of the pre-shared public key can respond to the PNSN request in DHT, 1004. The PNSN can repeat this process to build or update a list of nodes that contains the nearest potential network peer based on OSI 3 and 4 layer protocol monitoring information (e.g., TCP, UDP and ICMP), 1006. In an embodiment, the PNSN can find the nearest network peer network nodes from the received protocol monitoring information and build a list of network peer network nodes, 1010. Once the PNSN builds the list of nearest potential network peers is constructed, a query can be transmitted between the PNSN and the nearest network peers asking for the node capacities and capability for connectivity through remote procedure call (RPC) traffic, 1008.

[0062] FIG. 11 illustrates a communications diagram for the discovery and query process 506 of FIG. 5 and the flowchart of FIG. 10, under some embodiments. FIG. 11 illustrates some example interactions between the PNSN and the network using DHT network traffic and monitoring network traffic. As shown in FIG. 11, the PNSN finds network peers through broadcasting a pre-shared public key as a multicasting mechanism into the DHT, 1102. From the network, the potential network peers respond with the peer that has the same infohash as the pre-shared key, 1104. The PNSN and peers then find the nearest network peers from a group of potential network peers using OSI 3 and 4 protocols and monitoring information, 1106. In a query step, they then request each nearest network peer for their capacity and capabilities through RPC, 1108. This process is repeated to build a list containing nearest potential network peers based on OSI 3 and 4 layer protocol monitoring information, and certain protocols (e.g., TCP, UDP, and ICMP).

[0063] FIG. 12 is a flowchart that illustrates the process for the joining negotiation transaction 508 of FIG. 5, under some embodiments. As shown in FIG. 12, the PNSN can communicate with the blockchain node network via blockchain network traffic. The PNSN can construct a smart contract transaction containing an infohash of the PNSN’s own public key, infohash of the potential network peer’s public key list which can be randomly ordered primary and secondary network peers and may include details of how the node connections should be configured. The smart contract transaction can also include a security deposit or a capital penalty, 1202. The latest blocks including joining negotiation transaction are synchronized and stored on the blockchain, 1204. The PNSN can broadcast the transactions in a package as connection requests to the blockchain network peer nodes which can designate block #n+2 for storage of these transactions, 1206. The latest blocks are then synchronized including the previous transaction, 1208. The blockchain network can accept or reject the network connection requests, 1210. If the request is accepted, by the peer network, the peer nodes can construct the same type of blockchain transaction with a signature to the corresponding public key infohash. The blockchain transactions are broadcast to the network peers at block #n+2 or after #n+2 for confirmations, 1214. These transactions and these latest blocks are synchronized including all previous transactions and stored on the blockchain. After confirming that previous transactions are successfully included on block #n+2, the network connection can accept peers open port and the network can listen for other requests from potential network peers, 1216. If, in block 1210, the blockchain network rejects the network connection requests, the network peers do not broadcast blockchain transactions, 1212

[0064] FIG. 13 is a communications diagram for the joining negotiation transaction 508 and the flowchart of FIG. 12, under some embodiments. FIG. 13 illustrates some example interactions between the PNSN and the network using blockchain network traffic. As shown in FIG. 13, the latest blocks including transactions are synchronized between the PNSN and network, 1302. The PNSN broadcasts blockchain transactions to network peers at block #n+2, 1304. This transaction constructs a blockchain transaction as a smart contract that contains an infohash of the node's own public key, the infohash of the potential network peer's public key list (randomly ordered primary and secondary network peers) and details of how the connectives should be including security deposit/capital penalty. The latest blocks including the previous transaction are then synchronized, 1306. The blockchain transactions are then broadcasted to network peers earliest at block #n+2 or after #n+2 confirmations, 1308. In this communications diagram, the network peers respond with whether to accept or reject network connection requests through transactions. If the peer can accept the request, it constructs the same type of blockchain transaction by adding a signature to the corresponding public key infohash. After confirming the previous transaction is successfully included on block #n+2, the network connection accepted peers open a port and listen for requests from the potential network peer.

[0065] FIG. 14 is a flowchart that illustrates the process for the work maintenance transaction 510 of FIG. 5, under some embodiments. This transaction occurs between the PNSN and nodes of a blockchain network in a primary passive mode. The process of FIG. 14 can be used with an n-triangle of nodes of a blockchain network which include a parent node and two child nodes arranged in a triangle configuration. Such an arrangement is shown as element 1501 of FIG. 15 showing the parent node (p) and two child nodes (c). With reference to FIG. 14, the PNSN can construct a smart contract transaction which contains a infohash of the PNSN’s own public-key, infohash of the parent network node’s public-key infohash and the first and second child node public-key infohashes, 1402. The smart contract transaction can also include a deposit amount, which can be a capital penalty or a security deposit. The PNSN can broadcast the blockchain transactions as a request package to the n-triangle network peers at designated block #n+3 and possibly subsequent blocks. The n-triangle nodes can accept the request. The transactions can be broadcast and the latest blocks are

synchronized including the previous transactions by the PNSN and the blockchain network and stored on the blockchain. The n-triangle network peer nodes can respond to request by updating the transaction smart contact with acknowledgement from a pair of child nodes, 1404. The response transaction can include an updated smart contract which can be broadcast to blockchain network peers at designated block #n+4 and possibly subsequent blocks. The latest bocks are synchronized and include the previous transaction and stored on the blockchain, 1406.

[0066] FIG. 15 is a communications diagram for the work maintenance transaction 510 and the flowchart of FIG. 14, under some embodiments. FIG. 15 illustrates some example interactions between the PNSN and the network using blockchain network traffic. As shown in FIG. 15, the PNSN broadcasts blockchain transactions to network peers at least block #n+3, 1502. It constructs one of the blockchain transactions as a smart contract that contains an infohash of its own public key, an info hash of the parent node's public key infohash and primary and secondary sibling node's public key infohashes. There may also be a deposit amount. The latest blocks including the previous transaction are then synchronized, 1504.

The blockchain transactions are then broadcast to network peers at least block #n+4, 1506. In this communication, the network parent and direct sibling node respond to the request of 1502 by updating the transaction smart contract as acknowledgment with randomly selecting its pairing with another child node from the list. The latest blocks including the previous transaction are then synchronized, 1508. The blockchain transactions are then broadcast to network peers at least block #n+5, 1510. In this communication, the network parent constructs the transaction to update to the following state: (1) the parent node's sibling node's public key infohash list as secondary observers or submitters, (2) list of nonce (random number signed with parent node, and (3) $timestamp update transaction with proof result to complete the proof of network elements. The latest blocks including the previous transaction are then synchronized, 1512.

[0067] In different embodiments, the n-triangle nodes 1501 can be selected from various nodes in the blockchain network. For example, the n-triangle nodes can be selected from the closest or fastest responding peer nodes in the blockchain network or from peer nodes having the required bandwidth availability. Because the PNSN is attempting to join the blockchain network, the peer nodes selected for the n-triangle can be selected from known good actor nodes. Alternatively, the n-triangle nodes can be randomly selected peer nodes in the blockchain network. [0068] As shown in FIG. 15, the n-triangle parent node can then construct the transaction to update the following state information: (1) the parent node’s and the child sibling nodes’ public-key infohash list as secondary observers or submitters, (2) a nonce (random number signed with parent’s node), and (3) $timestamp of the update transaction with proof result to complete the proof of network elements. The parent node can generate nonces and store them in a list of nonces. When needed, a nonce can be taken from the parent node’s nonce list. These nonces are used for the purpose of verifying data transmitted around nodes of the n- triangle rather than solving a math problem for generating a block on the blockchain. The nonce package format can be Sign($randomnumber + $timestamp). The parent node of the n- triangle can be broadcast this transaction to the network peers and this transaction can be designated for storage at block #n+5 and possibly subsequent blocks of the blockchain. The latest bocks are synchronized and include the previous transaction and stored on the blockchain.

[0069] In order for the blockchain system to function optimally, it can be beneficial to perform validity checks on the blockchain network nodes to measure the operations and security qualities of each node in the blockchain network. In an embodiment, a base protocol can be used to test network elements in a blockchain network, which can be known as“proof of network elements.” Any three nodes in the same subnetwork can agree to participate in the proof of network elements and the nodes can be rewarded for each successful proof process. A parent node A can initiate a proof of network elements by first broadcasting to a request to neighbor nodes. The neighbor nodes can respond to the request by transmitting a response and the parent node A can measure the latency of the neighbor node responses. Since lower latency will generally lead to greater rewards, the parent node A can choose the two closest (fastest response time ) neighbor nodes B and C as peers for proof of network elements process. [0070] FIG. 16 illustrates a minimal node group 1601 that performs the proof of network element process, under some embodiments can be known as a (“network service node triangle” or“n-triangle”) of three nodes which is created from a larger network of n nodes.

In the minimal node group 1601 can transmit data packages that each contain a nonce bi- directionally between parent node A 1603, left child node B (left sibling node) 1605, and right child node C (right sibling node) 1607 of the minimal group 1601. In this example, data package 1“e _c (noncel)” is transmitted from parent node A to child node C, data package 1 “e _b (e _c (noncel))” is transmitted from node C to child node B and package 1

“e _a (e _b (e _c (noncel)))” is transmitted from child node C back to parent node A. Simultaneously data package 2“e _a (nonce2)” is transmitted from parent node A to child node B, data package 2“e _b (e _a (nonce2))” is transmitted from parent node A to child node C and data package 2 “e _c (e _b (e _a (nonce2)))” is transmitted from child node C back to parent node A.

[0071] Each of the member nodes parent node A 1603, child node B 1605, and child node C 1607, envelopes (“Signed Hash/Encrypts”) the data packages with their digital signatures on the transmitted data. More specifically, the nodes 1603, 1605 and 1607 can add a signed layer“Signed Ping” and then passes the information to the next n-triangle node 1603, 1605, and 1607 until the data package reaches the originator parent node A 1603.

[0072] The parent node A 1603 receives the two data packages data package 1 and data package 2 and can broadcast both packages to neighboring nodes in the blockchain network. The neighbor nodes can verify (“decrypt”) the data packages and store the results on a blockchain. ETsing data package information stored on the blockchain, decentralized use cases are possible.

[0073] The process illustrated in FIG. 16 represents a process wherein nonces are encrypted by the parent and child nodes prior to transmission to the other nodes, and then decrypted by the receiving nodes. The encryption and decryption processes may utilize symmetric or asymmetric encryption methods, where symmetric encryption uses a single key that needs to be shared among the people who need to receive the message while

asymmetrical encryption uses a pair of public key and a private key to encrypt and decrypt messages when communicating

[0074] FIG. 17 is a flowchart illustrating a process of transmitting signed pings between parent and child nodes of a blockchain network, under some embodiments. The network parent node can initiate the process by creating a signed ping package

($SignedPingFromParent) can include the infohash of the parent node’s public key

(Infohash(Parent’ sPubKey)) and a signed first nonce (Sign(Noncel)), 1702. The signed ping package ($SignedPingFromParent) can be transmitted form the parent node to the child 1 node, 1704. The child 1 node can repeat this process and create a signed ping package ($SignedPingFromChildl) which can include the infohash of the parent node’s public key (Infohash(Childl’ sPubKey)) and a signed ping package from the parent node

(Sign($SignedPingFromParent)), 1706. This package from child 1 is transmitted to a child 2 node, 1708. The Child 2 node can repeat the process again creating the signed ping package ($SignedPingFromChild2) which can include the infohash of the parent node’s public key (Inf ohash(Child2’ sPubKey)) and a signed ping package from the parent node

(Sign($SignedPingFromChildl), 1714 to 1716. The signed ping package

($SignedPingFromChild2) can be transmitted from the child 2 node to the parent node, 1718.

[0075] The network parent node receives an encrypted package payload from each of the child nodes of the n-triangle. When the encrypted package payload is received by the parent node, the smart contract is updated and placed in a transaction that is broadcasted to the neighboring nodes in the blockchain network that are not nodes of the n-triangle. This payload can be verified by any neighbor node by using the public keys belonging to nodes A, B, and C. The neighbor nodes decrypt the encrypted package payload to verify that the payload is valid, 1710. If the transaction is verified as valid, the neighbor nodes put the transaction into a memory pool (mempool) which holds the transaction before the transaction is added to a block of the blockchain. In embodiments,“claimer” infohashes can be added to a corresponding list for attributing a reward to peer neighbor nodes for decrypting, 1712.

The blockchain transaction and list for attributing rewards to peer neighbor nodes can be stored at designated block #n+6. The latest blocks can then be synchronized on the blockchain including this transaction.

[0076] When the parent node broadcasts the transaction, the neighboring nodes work on decrypting the package payload by solving a nonce for the generating a block stored on a blockchain. The nonce can have a dynamic field size value that is set so that the hash of the block will contain a plurality of leading zeros. The rest of the fields may not be changed, as they have a defined meaning. Any change to the block data including the nonce will make the block hash completely different. Since it is believed to be infeasible to predict which combination of bits will result in the right hash, many different nonce values are tried, and the hash is recomputed for each value until a hash containing the required number of zero bits is found. The number of zero bits required by the hash determines the difficulty of the required computation. A hash with more leading zeros will be more difficult to solve by finding the correct nonce than a hash with fewer leading zeros. This iterative calculation requires time and computational resources. The presentation of the block with the correct nonce value constitutes proof of network element.

[0077] Basically, in order to form proof of network elements, the peers will sign their signature as acknowledgements before or at the start of the process, such as through the blockchain's smart contract. This is performed through the following operations:

key = value ( ack/ sign)

hash (pubKeyl ) => signBy (privateKeyl ) ex> shal (pubKeyl ) => signBy (privateKeyl )

[0078] Although embodiments are described with respect to blockchain systems, embodiments are not so limited. Other mechanisms can also be used, such as a centralized database as a verification mechanism or even through a shared file system.

[0079] FIG. 18 is a communications diagram for the process of transmitting signed pings of FIG. 17, under some embodiments. FIG. 18 illustrates some example interactions between the PNSN 1801 and the network 1803 using blockchain network traffic. For the embodiment of FIG. 18, node 1801 represents a node that creates signed ping data randomly broadcast to parent and/or observer nodes. The network parent node 1803 initiates the process by transmitting data in a certain $SignedPingFromParent format. It pops one nonce from the list and formats it accordingly. The nonce is the "lucky number" to be claimed by the observer or monitor delegation nodes and validated by the remaining peers. The first child node 1801 then responds with data in a certain $SignedPingFromChildl format, 1804. This is repeated for other child nodes. The network parent or observer nodes verify and decrypt the encapsulated signed data packets. At the end of the loop (for all of the child nodes), the parent node should find the shal/infohash value of the public key and nonce# 1 which require update into the smart contract state through a transaction. The blockchain transactions are broadcast to network peers at least #n+6, 1806, and the latest blocks including the previous transaction are synchronized, 1808. In these transactions, the network parent or observer node constructs and broadcasts the transaction to update and validate nonce# 1 with adding 'claimer' infohash to the corresponding list for the reward.

[0080] In an embodiment, the size of the nonce is dynamic and can be adjusted to achieve an ideal size over time. The number of bits comprising the nonce can be adjusted between defined upper and lower limits by any number of bits. [0081] FIG. 19 is a graph showing how the system adjusts the dynamic nonce size so that it reaches an ideal size over a time period, and FIG. 20 is a graph showing how the system consumes nonces over the same time period of FIG. 19. As shown in FIGS. 19 and 20, in a time period, a total of N nonces are generated. If nonce bit size is too small the system will consume all available N nonces is that time period. In contrast, if nonce bit size is too big then the system will consume less than N nonces. The system can be configured to find the optimum nonce bit size so that the system consumes all N nonces with no time left in a period. This will create equilibrium between nonce bit size and the consumption rate within a time period.

[0082] The system can monitor and record the nonce consumption rate and make adjustments to the nonce size based upon the nonce consumption rate in order to get to a target nonce consumption rate. The system can perform nonce size correction in an automated manner. If the nonce consumption rate rises above the target nonce consumption rate, the system can increase the size of the nonce to reduce the nonce consumption rate. Conversely, if the nonce consumption rate falls below the target nonce consumption rate, the system can decrease the size of the nonce to increase the nonce consumption rate. With reference to FIG. 19 the system can start with a small nonce size 801 and increase the nonce size over time 802, 803. Because the initial nonce size is small, the nonce solutions are more easily found. With reference to FIG. 20, the nonce consumption rate is initially at a maximum level 811, 812, 813 because the system is consuming all available nonces. When nonce size exceeds the optimal nonce size (804), the computational requirements increase and the nonce consumption rate drops below the target nonce consumption rate (814). The system can compensate by reducing the nonce size (805) which can result in the nonce consumption rate rising to the maximum level again (815). The system can then increase the nonce size (806) and the nonce consumption rate is reduced again (816 FIG. 20). A smaller adjustment is made and the nonce size is reduced (807) and the nonce consumption rate rises (817). A minor adjustment is made to increase the nonce size (808) and the nonce consumption rate can match the target nonce consumption rate (818). Using this process, the system can adjust the nonce size to stabilize the nonce consumption rate to the target rate which can result in a system that has high security while providing the desired operating speed.

[0083] The nonce size can be controlled by various methods. In an embodiment, the nonce size can be controlled by a smart contract transmitted to the blockchain network. The smart contract can effectively be a manual input from a system administrator that is transmitted to a parent node of an n-triangle from a peer node. Alternatively, in an embodiment, the blockchain network can control the nonce size based upon a feedback loop.

[0084] New nodes can be added to the network using certain functions of process 104 with transactions stored on the blockchain. FIG. 21 illustrates a method of adding a new node to a blockchain network and storing the transactions on the blockchain, under some embodiments. In block 2102, the PNSN can construct a registration transaction in the form of a smart contract that contains an infohash of the PNSN’s own public-key, an actual public- key, and a time window that defines how long the peer infohash is valid which is stored on block #n+0 of the blockchain (as shown in FIG. 9). If necessary, as shown in block 2104, the PNSN can broadcast this new blockchain transaction to extend the TTL time window to the network peers which is stored on block #n+ l of the blockchain (FIG. 9). The PNSN can broadcast a connection request to the blockchain network peer nodes transaction which can be stored on block #n+2 (Fig. 13), block 2106. In block 2108, the PNSN can broadcast a smart contract request transaction to the network peer nodes which can be stored on block #n+3 (Fig. 15). The n-triangle nodes can broadcast a response to the smart contract request transaction to the PNSN which can be stored on block #n+4 (Fig. 15), block 2110. In block 2112, the n-triangle nodes can broadcast a state update transaction to the PNSN which can be stored on block #n+5 (Fig. 15). The n-triangle nodes can broadcast noncel and nonce2 transaction to the PNSN which can be stored on block #n+6 (Fig. 15), block 2114.

Applications

[0085] The proof of network element protocol process can be used for various tasks or applications including: validation of network existence, measurement of network quality, metering network traffic, and validation of good actors, among other tasks.

[0086] With regard to validation of network existence, process 104 provides the ability to verify if nodes are operational and provide secure connections. In an embodiment, the proof of network can be used to provide validation of“good actor” nodes and identify“bad actor” nodes through a process of collaborative filtering. Bad actor nodes can fake data transfers and/or throttle data transmitted through the node. Various methods can be used to identify bad actor nodes. As described above, the nodes of an n-triangle can be operational and secure if the transmission times of the nonces in opposite directions through the nodes of the n- triangle are substantially equal. However, if the transmission times of the nonces through the n-triangle are not equal beyond a predetermined timing value, this transmission time asymmetry can indicate an operational or security defect with at least one of the nodes of the n-triangle. However, in some cases an n-triangle that includes a bad actor node can have substantially equal transmission times of the nonces in opposite directions which are slower than they should be. Thus, it can be difficult to identify a bad actor node through

collaborative filtering in isolation. In order to detect these bad actor nodes, the nonce transmission times through multiple n-triangles that include the bad actor node can be measured. The transmission times of nonces through n-triangles that only include good actor nodes can be faster than the transmission times of nonces through n-triangles that include bad actor nodes. Thus, by analyzing the nonce transmission times through multiple n-triangles that include only good actor nodes and n-triangles that include bad actors, the specific nodes that are bad actors can be identified. These individual nodes that are not operational or not secure can be designated bad actor nodes and their bad actor status can be stored on the blockchain. This process can be repeated and the node operation and security information can be periodically and continuously stored on the blockchain. In an embodiment, the blockchain network can be configured based upon the capacities of the nodes with the higher capacity nodes in a center portion of the network and the lower capacity nodes on the periphery of the network. The system may remove or isolate the bad actor nodes from the blockchain network.

[0087] With regard to measurement of network quality, in an embodiment, process 104 can be used to measure speed and reliability (uptime) of each node, n-triangle, subnet and the blockchain network. The proof of network processing can also be used to measure these blockchain network qualities. The speed of a node can be measured by determining the time required to transmit data packages through the n-triangle parent and sibling nodes as described above. The initial transmission times will be for the entire n-triangles. However, as discussed, by measuring the transmission speeds through multiple different n-triangles that have different combinations of the blockchain network nodes, the transmission speeds for each individual node in the network can be determined. This speed will be consistent when the data throughput is within the bandwidth of the node.

[0088] The bandwidths of the nodes can be determined by measuring delays in the transmissions times of the data packets through the n-triangles when the volume of data exceeds the bandwidth of the nodes. In an embodiment, the n-triangle nodes can agree to using larger nonces to determine bandwidths of the n-triangle nodes. FIG. 22 is a graph of data transmission speed through the n-triangle nodes as plotted against a data transmission (nonce) size, under an embodiment. For data transmissions below the bandwidth, the data speed for the node can be equal as shown in portion 2202 of the plot. When the data transmission exceeds the bandwidth of the node or n-triangle, the measured transmission speed can show a degradation of data transmission speed, as shown in portion 2204 of the plot. In this example, the degradation of the data speed through the node is shown as the downward sloping measured data speed through the node. Since nodes can continue to repeat the proof of network elements process to keep gaining rewards, and since these completed exercises can all be recorded, over time this information can provide a reasonably accurate view of band width and availability of each node of the blockchain network.

[0089] The system has the ability to measure data transmission speed using different test methods. In a first embodiment, the inventive system can perform bandwidth testing by continuously and repeating the described process of transmitting a sequence of data packages that have increasing sizes through n-triangles. These data package sizes can be controlled by a test protocol, which can transmit predetermined package sizes in an increasing size sequence. When the data transmission speed through a node begins to degrade, the bandwidth of the n-triangle can be determined. By analyzing the transmission speeds for multiple n- triangles that have common nodes, the bandwidths for each of the individual nodes can be determined. The node bandwidths can be stored and continuously updated by repeating the described process.

[0090] Because the proof of network data is stored in the blockchain, the stored data can be used to determine the reliability (uptime) of each network service node triangle (n- triangle). The described proof of network processing can be applied to additional n-triangle to analyze all combinations of n-triangles in subnets and the entire blockchain network. By measuring the proof of network for the n-triangles, performance characteristics can be stored to provide speed, bandwidth, reliability for all n-triangles in a blockchain network. For example, the system can validate good actor nodes that are contributing to the system bandwidth. [0091] As discussed, the respective performance of each of the individual nodes in the blockchain network can be determined. Some nodes may consistently perform high speed packet processing. Because the system can continuously measure and monitor the processing speeds, the fastest and most reliable nodes can be determined and these nodes can be validated as good actor nodes. In an embodiment, the good actor nodes can be rewarded in various possible ways. For example, good actors can receive a reward for performing a certain quantity of transactions or maintaining a certain quality of performance for a certain period of time. The reward can be similar the reward provided to peer nodes for decrypting nonces as described above.

[0092] Although the blockchain has been described in conjunction with a distributed network, embodiments are not so limited. For example, it may be implemented in conjunction with a database or other organized data system. FIG. 23 illustrates a blockchain network configured with a plurality of n-triangles 2302 in communication through their parent nodes with a database 2304. The database may be maintained by a server computer and stored in local or network memory accessible by the server. A system administrator can utilize the server/database to provide administrative information to the n-triangles 2302. For example, the information can be stored on the database and accessed by the parent nodes of the n-triangles can include: nonce size controls, DHT data, node status data, node status/performance information, and so on. By controlling the nonce size through a user interface of the server/database, the system administrator does not need to use a smart contract to control the nonce size, such as described with respect to FIGS. 19 and 20.

[0093] As mentioned above, the times for transmitting nonce packet through each of the n-triangles in the blockchain network can be measured and processing speeds can be determined. The speed can be expressed in units of packets per second (PPS) or other units such as gigabits per second (Gb/s), transactions per second (t/s), etc. By analyzing the package processing speeds for each of the n-triangles in the blockchain network, the speeds and bandwidths of the individual nodes can be calculated. The speed testing can be repeated and the node speed and bandwidth information can be periodically and continuously stored on the blockchain.

[0094] With regard to metering network traffic, process 104 provides the ability to meter data packages flow through the nodes of the blockchain network can be performed by monitoring and testing the data flow rates through the n-triangles of the blockchain network. In an embodiment, the packet data sizes and speeds through the nodes of the n-triangles can be measured during normal operations when new PNSNs are added to the blockchain network. Alternatively, the packet data sizes and speeds through the nodes of the n-triangles can be measured by performing data traffic testing of the n-triangles.

[0095] FIG. 24 illustrates peer nodes in an example blockchain network, under some embodiments. Network 2402 is used to illustrate examples of some n-triangle testing that can be performed to determine the node traffic performance characteristics. In Table 1 below, example time measurements and bandwidths for a plurality of n-triangles are obtained as described above.

Table 1 [0096] In this example, the system measures the n-triangle nonce transmission time and based upon the measured information, the nonce transmission times for the parent node, the first child node and the second child node can be calculated. The n-triangle time = parent node time + first child node time + second child node time. The n-triangles that include the peer nodes A, B, C, D, E and G each have a measures nonce transmission time between 4.835 and 4.864 milliseconds. However, the n-triangles that include the F peer node have a measures nonce transmission times 10.125 and 10.104 milliseconds, which is a substantially higher nonce transmission time than the other nodes that do not include the F peer node. The system can perform calculations to determine the individual nonce transmission times.

Nodes A, B, C, D, E and G can have transmission times between 1.593 milliseconds (node E) and 1.645 milliseconds (node D). The system can determine that the transmission time of F node is 6.862 milliseconds, which indicates that this node is defective or a bad actor node. The system can record and store the defective or a bad actor status of the F node on the DHT so that this node can be removed or isolated so that data transmissions is only transmitted through good actor fully functional nodes in the blockchain network. The described process can be periodically repeated to update the status of the F node. If the measured nonce transmission times are measured to be within the acceptable range, the system can change the F node status to a fully functional good actor node.

Table 2

[0097] With reference to Table 2 above, the blockchain network can also determine the bandwidths for a plurality of nodes in n-triangles as described above. Although the speed measurements for the n-triangles that include the F node, the speed measurement is independent of the bandwidth measurement. The bandwidth of an n-triangle can be equal to the bandwidth of the node having the lowest bandwidth. In this example, the n-triangles that use nodes A, B, D, E, F and G each have a bandwidth that is between 4.35 and 4.67 Gbit/sec. However, the bandwidths of the n-triangles that include node C are both 0.49 Gbit/sec. This indicates that the bandwidth of the C node is 0.49 Gbit/sec. A similar process can be used to determine the bandwidths of the other nodes in the blockchain network.

System Implementation

[0098] As described above, in an embodiment, system 100 includes a proof of network function 104 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.

[0099] FIG. 25 illustrates an example generic computer device 900 and a generic mobile computer device 950, which may be used to implement the processes described herein.

Computing device 900 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Computing device 950 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be an example only, and are not meant to limit any described embodiments.

[00100] Computing device 900 includes a processor 902, memory 904, a storage device 906, a high-speed interface 908 connecting to memory 904 and high-speed expansion ports 910, and a low speed interface 912 connecting to low speed bus 914 and storage device 906. Each of the components processor 902, memory 904, storage device 906, high-speed interface 908, high-speed expansion ports 910, and low speed interface 912 are

interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate. The processor 902 can process instructions for execution within the computing device 900, including instructions stored in the memory 904 or on the storage device 906 to display graphical information for a (graphical user interface) GUI on an external input/output device, such as display 916 coupled to high speed interface 908. In other implementations, multiple processors and/or multiple busses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices 900 may be connected, with each device providing portions of the necessary operations (e.g., as a server bank or a multi-processor system).

[00101] The memory 904 stores information within the computing device 900. In one implementation, the memory 904 is a volatile memory unit or units. In another

implementation, the memory 904 is a non-volatile memory unit or units. The memory 904 may also be another form of computer-readable medium, such as a magnetic or optical disk. [00102] The storage device 906 is capable of providing mass storage for the computing device 900. In one implementation, the storage device 906 may be or contain a computer- readable medium using known magnetic, optical, or tape technologies. A computer program product can be tangibly embodied in an information carrier. The computer program product may also contain instructions that, when executed, perform one or more methods, such as those described above. The information carrier may be a non-transitory computer- or machine-readable storage medium, such as the memory 904, the storage device 906, or memory on processor 902.

[00103] The high speed controller 908 manages bandwidth-intensive operations for the computing device 900, while the low speed controller 912 manages lower bandwidth intensive operations. Such allocation of functions is exemplary only. In one implementation, the high-speed controller 908 is coupled to memory 904, display 916 (e.g., through a graphics processor or accelerator), and to high-speed expansion ports 910, which may accept various expansion cards (not shown). In the implementation, low-speed controller 912 is coupled to storage device 906 and low-speed expansion port 914. The low-speed expansion port 914, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), may be coupled to one or more input/output devices, such as a keyboard 936 in communication with a computer 932, a pointing device 935, a scanner 931, or a networking device 933 such as a switch or router, e.g., through a network adapter.

[00104] The computing device 900 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server 920, or multiple times in a group of such servers. It may also be implemented as part of a rack server system 924. In addition, it may be implemented in a personal computer such as a laptop computer 922. Alternatively, components from computing device 900 may be combined with other components in a mobile device (not shown), such as device 950. Each of such devices may contain one or more of computing device 900, 950, and an entire system may be made up of multiple computing devices 900, 950 communicating with each other.

[00105] Computing device 950 includes a processor 952, memory 964, an input/output device such as a display 954, a communication interface 966, and a transceiver 968, among other components. The device 950 may also be provided with a storage device, such as a Microdrive, solid state memory or other device, to provide additional storage. Each of the components computing device 950, processor 952, memory 964, display 954, communication interface 966, and transceiver 968 are interconnected using various busses, and several of the components may be mounted on a common motherboard or in other manners as appropriate.

[00106] The processor 952 can execute instructions within the computing device 950, including instructions stored in the memory 964. The processor may be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor may provide, for example, for coordination of the other components of the device 950, such as control of user interfaces, applications run by device 950, and wireless communication by device 950.

[00107] Processor 952 may communicate with a user through control interface 958 and display interface 956 coupled to a display 954. The display 954 may be embodied in any appropriate display technology. The control interface 958 may receive commands from a user and convert them for submission to the processor 952. In addition, an external interface 962 may be provided in communication with processor 952, so as to enable near area

communication of device 950 with other devices. External interface 962 may provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces may also be used.

[00108] The memory 964 stores information within the computing device 950. The memory 964 can be implemented as one or more of a computer-readable medium or media, a volatile memory unit or units, or a non-volatile memory unit or units. Expansion memory 974 may also be provided and connected to device 950 through expansion interface 972, which may include, for example, a SIMM (Single In Line Memory Module) card interface. Such expansion memory 974 may provide extra storage space for device 950, or may also store applications or other information for device 950, such as security information.

[00109] The memory may include, for example, flash memory and/or NVRAM memory, as discussed below. In one implementation, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as the memory 964, expansion memory 974, memory on processor 952, or a propagated signal that may be received, for example, over transceiver 968 or external interface 962.

[00110] Device 950 may communicate wirelessly through communication interface 966, which may include digital signal processing circuitry where necessary. Communication interface 966 may provide for communications under various modes or protocols, such as GSM voice calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others. Such communication may occur, for example, through radio-frequency transceiver 968. In addition, short-range communication may occur, such as using a Bluetooth, Wi-Fi, or other such transceiver (not shown). In addition, GPS (Global Positioning System) receiver module 970 may provide additional navigation- and location- related wireless data to device 950, which may be used as appropriate by applications running on device 950.

[00111] Device 950 may also communicate audibly using audio codec 960, which may receive spoken information from a user and convert it to usable digital information. Audio codec 960 may likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of device 950.

[00112] The computing device 950 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a cellular telephone 980. It may also be implemented as part of a smartphone 982, personal digital assistant, a tablet computer 983 or other similar mobile computing device.

[00113] Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs

(application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. In an embodiment, an ASIC design can be used to implement system algorithms as well as hardware accelerated designs for specific use cases. For example, the nodes may have ASIC processors, which can perform the encryption and decryption of the packets as described above. By providing the proof of network in a hardware configuration, the data processing through the blockchain network can be designed for the described use cases.

[00114] These computer programs (also known as programs, software, software applications or code) can include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms "machine-readable medium" "computer-readable medium" refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

[00115] Embodiments are directed to a method for analyzing nodes in a computer blockchain network comprising:

a. providing a parent node, a first child node and a second child node, wherein the

parent node, the first child node and the second child node are nodes of the computer blockchain network;

b. transmitting from the parent node, a first nonce encrypted by the parent node, to the first child node;

c. transmitting from the second node, the first nonce encrypted by the parent node and the first child node, to the second child node;

d. transmitting from the second child node, the first nonce encrypted by the parent node, the first child node and the second child node, to the parent node;

e. transmitting from the parent node, a second nonce encrypted by the parent node, to the second child node;

f. transmitting from the second child node, the second nonce encrypted by the parent node and the second child node, to the first child node;

g. transmitting from the first child node, the second nonce encrypted by the parent node, the second child node and the first child node, to the parent node;

h. decrypting and validating the first nonce and the second nonce by the parent node; e. determining a first transmission time for the transmission of the first nonce from the parent node through the first child node and the second child node and back to the parent node; f. determining a second transmission time for the transmission of the second nonce from the parent node through the second child node and the first child node and back to the parent node;

g. storing the first transmission time and the second transmission time on a blockchain of the computer blockchain network;

h. determining by the parent node, a performance characteristic of the parent node, the first child node, and the second child node based upon the first transmission time of the first nonce the second transmission time of the second nonce;

i. storing the performance characteristic of the parent node, the first child node, and the second child node on the blockchain.

[00116] The method may further comprises determining by the parent node, an asymmetric transmission time measurement between the first transmission time and the second transmission time, wherein the asymmetry measurement is greater than a

predetermined time value; and identifying by the parent node, that the first node, the second node or the third node is not operational or not secure based upon the asymmetry

measurement.

[00117] The method may yet further comprise determining by the parent node, an asymmetry measurement between the first transmission time and the second transmission time is within a predetermined time period; identifying by the parent node, that the parent node, the first child node and the second child node are operational and secure based upon the asymmetry measurement; and storing operational and secure data for the parent node, the first child node and the second child node on the blockchain.

[00118] The method may further comprise repeating the steps b - i multiple times;

determining data speed measurements for the parent node, the first child node and the second child node; and storing the data speed measurements for the parent node, the first child node and the second child node on the blockchain.

[00119] The method instead further comprise repeating the steps b - g multiple times; determining data bandwidth measurements for the parent node, the first child node and the second node; and storing the data bandwidth measurements for the parent node, the first child node and the second node on the blockchain.

[00120] The method may further comprise determining a validity status for the parent node, the first child node and the second child node; and storing the validity status for the parent node, the first child node and the second child node on the blockchain.

[00121] Embodiments are also directed to a method for analyzing nodes in a computer blockchain network comprising:

a. providing an observer node, a parent node, a first child node and a second child node, wherein the parent node, the first child node and the second child node are nodes of the computer blockchain network;

b. transmitting from the parent node, a first nonce encrypted by the parent node, to the first child node;

c. transmitting from the second node, the first nonce encrypted by the parent node and the first child node, to the second child node;

d. transmitting from the second child node, the first nonce encrypted by the parent node, the first child node and the second child node, to the parent node;

e. transmitting from the parent node, the first nonce encrypted by the parent node, the first child node and the second child node, to the observer node;

f. transmitting from the parent node, a second nonce encrypted by the parent node, to the second child node; g. transmitting from the second child node, the second nonce encrypted by the parent node and the second child node, to the first child node;

h. transmitting from the first child node, the second nonce encrypted by the parent node, the second child node and the first child node, to the parent node;

i. transmitting from the parent node, the second nonce encrypted by the parent node, the second child node and the first child node, to the observer node;

j . decrypting and validating the first nonce and the second nonce by the observer node; k. determining by the observer node, a first transmission time for the transmission of the first nonce from the parent node through the first child node and the second child node and back to the parent node;

l. determining by the observer node, a second transmission time for the transmission of the second nonce from the parent node through the second child node and the first child node and back to the parent node;

m. storing the first transmission time and the second transmission time on a blockchain of the computer blockchain network;

n. determining by the observer node, a performance characteristic of the parent node, the first child node, and the second child node based upon the first transmission time of the first nonce the second transmission time of the second nonce;

o. storing the performance characteristic of the parent node, the first child node, and the second child node on the blockchain.

[00122] This method may further comprise determining by the observer node, an asymmetric transmission time measurement between the first transmission time and the second transmission time, wherein the asymmetry measurement is greater than a

predetermined time value; and identifying by the observer node, that the first node, the second node or the third node is not operational or not secure based upon the asymmetry measurement.

[00123] This method may further comprise determining by the observer node, an asymmetry measurement between the first transmission time and the second transmission time is within a predetermined time period; identifying by the observer node, that the parent node, the first child node and the second child node are operational and secure based upon the asymmetry measurement; and storing operational and secure data for the parent node, the first child node and the second child node on the blockchain.

[00124] The method may yet further comprise: repeating the steps b - i multiple times; determining by the observer node, data speed measurements for the parent node, the first child node and the second child node; and storing the data speed measurements for the parent node, the first child node and the second child node on the block of the blockchain.

[00125] The method may alternatively comprise repeating the steps b - o multiple times; determining by the observer node, data bandwidth measurements for the parent node, the first child node and the second child node; and storing the data bandwidth measurements for the parent node, the first child node and the second child node on the blockchain.

[00126] The method may further comprise determining by the observer node, a validity status for the parent node, the first child node and the third node; and storing the validity status for the parent node, the first child node and the second child node on the blockchain.

[00127] Embodiments are also directed to a method for analyzing nodes in a computer blockchain network comprising: identifying a plurality of three node groups in the computer blockchain network wherein each of the plurality of three node groups is a different combination of nodes; performing steps a - j for each of the plurality of three node groups; a. providing a parent node, a second node and a third node, wherein the parent node, the second node and the third node some of the nodes of the computer blockchain network;

b. transmitting from the parent node, a first nonce encrypted by the parent node, to the first child node;

c. transmitting from the first child node, the first nonce encrypted by the parent node and the first child node, to the second child node;

d. transmitting from the second child node, the first nonce encrypted by the parent node, the first child node and the second node, to the parent node;

e. transmitting from the parent node, a second nonce encrypted by the parent node, to the second child node;

f. transmitting from the second child node, the second nonce encrypted by the parent node and the second child node, to the first child node;

g. transmitting from the first node, the second nonce encrypted by the parent node, the second child node and the first child node, to the parent node;

h. decrypting and validating the first package and the second package by the parent node; i. determining a first transmission time for the first nonce and a second transmission time for the second nonce by the parent node; and

j . determining by the parent node, a performance characteristic of the parent node, the first child node, and the second child node based upon the first transmission time and the second transmission time.

[00128] This method may further comprise determining by the parent node, asymmetry measurements between the first transmission time and the second transmission time, wherein the asymmetry measurement is greater than a predetermined time value for a first three node group of the plurality of three node groups; and identifying by the parent node, that the parent node, the first child node or the second child node of the first three node group is not operational or not secure based upon the asymmetry measurements.

[00129] The method may yet further comprise repeating the steps b - j multiple times for each of the three node groups; determining by the parent node, data speed measurements for the nodes of the blockchain network; and storing by the parent node, the data speed measurements for the nodes of the blockchain network on the blockchain.

[00130] The method may alternatively comprise repeating the steps b - j multiple times for each of the three node groups; determining by the parent node, data bandwidth measurements for the nodes of the blockchain network; and storing the data bandwidth measurements for the nodes of the blockchain network on the blockchain.

[00131] The method may further comprise determining by the parent node, a validity status for the nodes of the blockchain network; and storing the validity status for the nodes of the blockchain network on the block of the blockchain.

[00132] Embodiments are yet further directed to a method for analyzing nodes in a computer blockchain network comprising identifying by the parent node, a plurality of three node groups in the computer blockchain network wherein each of the plurality of three node groups is a different combination of nodes; performing steps a - j for each of the plurality of three node groups;

a. providing an observer node, a parent node, a second node and a third node, wherein the parent node, the second node and the third node some of the nodes of the computer blockchain network;

b. transmitting from the parent node, a first nonce encrypted by the parent node, to the first child node;

c. transmitting from the first child node, the first nonce encrypted by the parent node and the first child node, to the second child node; d. transmitting from the second child node, the first nonce encrypted by the parent node, the first child node and the second node, to the parent node;

e. transmitting from the parent node, the first nonce encrypted by the parent node, the first child node and the second child node, to the observer node;

f. transmitting from the parent node, a second nonce encrypted by the parent node, to the second child node;

g. transmitting from the second child node, the second nonce encrypted by the parent node and the second child node, to the first child node;

h. transmitting from the first node, the second nonce encrypted by the parent node, the second child node and the first child node, to the parent node;

i. transmitting from the parent node, the second nonce encrypted by the parent node, the second child node and the first child node, to the observer node;

j . decrypting and validating the first package and the second package by the observer node;

k. determining by the observer node, a first transmission time for the transmission of the first nonce from the parent node through the first child node and the second child node and back to the parent node;

l. determining by the observer node, a second transmission time for the transmission of the second nonce from the parent node through the second child node and the first child node and back to the parent node;

m. storing the first transmission time and the second transmission time on a blockchain of the computer blockchain network;

n. determining by the observer node, a performance characteristic of the parent node, the first child node, and the second child node based upon the first transmission time of the first nonce the second transmission time of the second nonce; o. storing the performance characteristic of the parent node, the first child node, and the second child node on the blockchain.

[00133] The method may further comprise determining by the observer node, asymmetry measurements between the first transmission time and the second transmission time for each of the plurality of three node groups, wherein the asymmetry measurement is greater than a predetermined time value for a first three node group of the plurality of three node groups; and identifying by the observer node, that the parent node, the first child node or the second child node of the first three node group is not operational or not secure based upon the asymmetry measurements.

[00134] The method may yet further comprise: repeating the steps b - n multiple times for each of the plurality of three node groups; determining by the observer node, data speed measurements for the nodes of the blockchain network; and storing the data speed measurements for the nodes of the blockchain network on the blockchain.

[00135] The method may alternatively comprise: repeating the steps b - n multiple times for each of the plurality of three node groups; determining by the observer node, data bandwidth measurements for the nodes of the blockchain network; and storing the data bandwidth measurements for the nodes of the blockchain network on the blockchain.

[00136] The method may further comprise determining by the observer node, a validity status for the nodes of the blockchain network; and storing the validity status for the nodes of the blockchain network on the block of the blockchain.

[00137] Embodiments are yet further directed to a method of providing proof of a network element in a large-scale network having a plurality (n) of nodes, by defining a minimal group of m nodes, where m is less than n; transmitting, from an originator node of the group, a respective data package of at least two data packages bi-directionally to other nodes in the group; enveloping, in each of the node of the group, their respective digital signature on the respective data package to form information; transmitting the information from each node of the group to a next peer until the information reaches the originator node; receiving, in the originator node, the at least two data packages, one from each direction of the bi-directional transmitting step; broadcasting, from the originator node, each of the two data packages to its neighboring nodes; and decoding, in the neighboring nodes, the at least two data packages for verification; and storing the result of the verification on a blockchain. The minimal group may comprise a triangle of three nodes having parent node as the originator and two child nodes as the neighboring nodes. The blockchain may include a history of transactions and data among the group in a series of blocks where each block contains a hash of a previous block generated by a hash function. In this method the data package may comprise a nonce comprising an arbitrary random number that is used just once as an input to vary the input to the hash function, and the enveloping step may comprise generating a signed hash and encrypting the digital signature on the data, and each node of the group adds a signed ping as their respective digital signature on the data. The proof of the network element may comprise a network protocol used to provide one or more of validation of network existence, measurement of network quality, metering of network traffic, and validation of good actors within the network.

[00138] Embodiments are yet further directed to a method of providing decentralized auditing and metering of nodes in a network, by initiating, from an originator node, a proof of network element transaction by first broadcasting to its neighbors and measuring the latency of their responses to identify nearest neighbor nodes; creating a transaction on a blockchain establishing a smart contract which lists the public key hashes of the nearest neighbor nodes; receiving an indication from each nearest neighbor node an agreement to participate in proof of network element transaction, wherein the indication comprises adding its respective signature to the smart contract; forming secure transmission pipes among the nodes once agreement occurs; and distributing tokens or other reward upon each successful completion of a transaction within the group to incentivize continued network participation. This method may further comprise: generating, in the originator node (node A), a nonce n and creating a transaction that adds a hash of n to a new smart contract; encrypting, in node A, n with its private key and sending the result as a message, EncryptA(n), to a first neighboring node (B); verifying, in node B, the message by decrypting the message with A's public key; repeating, by node B, this process to create a message EncryptB (Encrypt A(n)) which it sends to a second neighboring node C; repeating, by node C, this process to create a message

EncryptC (EncryptB (Encrypt A(n)) which it sends as a payload back to node A; and committing, by node A, the payload to the blockchain in a transaction that updates the new smart contract.

[00139] This method may further comprise verifying the payload in any of nodes A, B, or C using their own respective public keys. It may also further comprise initiating, by node A, a second proof of network elements process in an opposite direction, by starting a separate smart contract and sending an encrypted nonce to node C; sending, from node C, a payload to node B; and sending, from node B, the payload back to node A. The method may further comprise measuring a latency of each of the first direction and opposite direction to determine differences in bandwidth or latency of the nodes depending on the direction of data, and modifying the size of the nonce depending on bandwidth limitations.

[00140] The present disclosure, in various embodiments, includes components, methods, processes, systems and/or apparatus substantially as depicted and described herein, including various embodiments, subcombinations, and subsets thereof. Those of ordinary skill in the art will understand how to make and use the present disclosure after understanding the present disclosure. The present disclosure, in various embodiments, includes providing devices and processes in the absence of items not depicted and/or described herein or in various embodiments hereof, including in the absence of such items as may have been used in previous devices or processes, e.g., for improving performance, achieving ease and/or reducing cost of implementation.

[00141] 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.

[00142] 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.