WO2019195755A1 - Network protocol for blockchain based network packets - Google Patents

Abstract

Embodiments for a system allowing smart contracts for network packets to overcome the outdated and centralized weaknesses inherent in the current state of network infrastructures, which is being relied upon by many existing blockchain projects. Embodiments include a new and advantageous network infrastructure that provides a network protocol designed down to OSI layer 2 with robust security, performance, and peer-to-peer meshing capabilities, and by providing a blockchain protocol to enable trustless interoperation and exchange of network resources and incentivize participation in bootstrapping this new network. This platform will ultimately empower developers to build novel distributed and decentralized applications within this protocol.

Description

NETWORK PROTOCOL FOR BLOCKCHAIN BASED NETWORK PACKETS

CROSS-REFERENCE TO RELATED APPLICATIONS

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

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

TECHNICAL FIELD

[0002] Embodiments are directed to decentralized networks, and more specifically to a blockchain and smart contract based protocol for wired and wireless mesh networks.

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. This particular issue can be described with reference to the OSI (Open Systems Interconnection) model, which is a multi-layer networking scheme to implement communication protocols. Tinder the OSI model, 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.

The OSI model essentially describes how information from a software application in one computer moves through a network medium to a software application in another computer. FIG. 1 A illustrates a relationship of hardware and protocols under the OSI model, as generally used in IP networks. As shown in FIG. 1 A, the OSI model defines multiple layers in a stack 10 to implement communication protocols, comprising layers Ll to L7: Physical - Data Link - Network - Transport - Session - Presentation - Application. Each layer specifies particular network functions with tasks involved with moving information assigned to each of the seven layers and is self-contained so that the tasks assigned to each layer can be implemented independently. All or at least some of the nodes and network elements implement the OSI model to communicate over Internet Protocol (IP) channels.

[0006] With respect to network security, current Ethernet implementations expose raw network packets, allowing internet service providers (ISPs) and other entities (e.g., governments, corporations, etc.) to easily monitor and surveil user activity. Existing network security protocols operate at several layers above the physical (layer 1) and data link (layer 2) levels of the stack 10, such as TLS and SSL occurring at OSI layer 4 and above, while Ethernet remains insecure at layer 2. Therefore the security protocols layers 4 and above do not protect the entire network packet, leaving network traffic vulnerable to attacks like traffic pattern analysis and packet injection.

[0007] 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. Adding network capacity or new functionality like intrusion detection and prevention systems, virtual private networks or firewalls typically requires installing new network equipment. Even upgrading existing equipment costs considerable overhead since updates often require firmware changes that must be done on site.

[0008] 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 ISPs) serve as the gateway for all Internet traffic. When the service provider suffers failures or outages, all users lose access. Businesses can get hit especially hard as loss of the Internet can halt operations or productivity. In addition, this monopolistic control is problematic for countries that lack net neutrality now that blockchain networks have grown to considerable sizes. As of January 2018, Ethereum’s blockchain data directory size is about 652 gigabytes and has been growing at around 400% annually. As blockchain adoption continues, blockchain traffic will likely fall under the attention of ISPs. This, then, is the centrally controlled platform on which the blockchain ecosystem depends, as shown in FIG. 1B, and represents a fundamental vulnerability of the overall system. That is, as shown in FIG. 1B, all of the decentralized payment platforms (e.g., Bitcoin), all decentralized computing resources (e.g., Ethereum) and all decentralized storage (e.g., Filecoin) are built on a single centralized network

infrastructure 10. [0009] What is needed, therefore, is an ecosystem where new projects are constantly emerging with the goal of decentralizing the services we all use every day, and that is built on a network protocol that is secure and easily scalable.

INCORPORATION BY REFERENCE

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

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0012] FIG. 1 A illustrates a relationship of hardware and protocols under the OSI model, as generally used in IP networks.

[0013] FIG. 1B illustrates a centrally controlled platform upon which the present blockchain ecosystem is built.

[0014] FIG. 2A illustrates a large-scale mesh network including wired and wireless links that implements a blockchain based network protocol, under some embodiments.

[0015] FIG. 2B illustrates the protocol 104 as a layer that maps networks and

subnetworks to respective blockchains, under an embodiment.

[0016] FIG. 3 illustrates three major components of the blockchain based network protocol, under some embodiments. [0017] FIG. 4A illustrates an example network that globally organizes and enables the formation of autonomous networks, under some embodiments.

[0018] FIG. 4B illustrates an overall network comprising a public mesh network and a set of local networks to form a blockchain based protocol platform.

[0019] FIG. 4C illustrates a multi-node network and physical links for a network within the platform of FIG. 4B, under some embodiments.

[0020] FIG. 5 illustrates an implementation of an mPipe, under some embodiments.

[0021] FIG. 6 illustrates a process of mutating encryption to encode data over an mPipe, under some embodiments

[0022] FIG. 7 illustrates a process of processing data packets with smart packet contracts, under some embodiments.

[0023] FIG. 8 is a table that illustrates the composition of a smart packet control API, under some embodiments.

[0024] FIG. 9 illustrates an mLink within the OSI model, under some embodiments.

[0025] FIG. 10 illustrates implementation of a blockchain for use in network 100 of FIG.

2A, under some embodiments.

[0026] FIG. 11 illustrates an example distributed network storing blockchain data, under some embodiments.

[0027] FIG. 12 illustrates a global chain and mesh chains used in a network, under some embodiments.

[0028] FIG. 13 illustrates an example of nodes performing a proof of network elements process by encrypting a nonce n.

[0029] FIG. 14 illustrates the creation of public and private mesh chains using smart contracts, under an example embodiment. [0030] FIG. 15 illustrates an example mesh network implementing an OSI Layer 2 binding process, under some embodiments.

[0031] FIG. 16 illustrates the binding of multiple tunnels to a single virtual MAC address for the mesh network of FIG. 15, under some embodiments.

[0032] FIG. 17 is a graph showing a prospective token supply over time, under an example embodiment.

[0033] FIG. 18 illustrates an example of token migration to a private mesh chain under the network protocol.

[0034] FIG. 19 illustrates phases of decentralization for a blockchain based protocol platform, under some embodiments.

[0035] FIG. 2A0 illustrates a low cost hardware implementation of the blockchain protocol, under some embodiments.

[0036] FIG. 2A1 illustrates an enterprise-grade accelerator for the blockchain based protocol, under some embodiments.

[0037] FIG. 2A2 illustrates an example computer system implementing a blockchain based protocol, under some embodiments.

DETAILED DESCRIPTION

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

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

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

[0041] Embodiments are directed to a networking and blockchain protocol that allows smart contracts for network packets. The protocol is implemented network components embodied in either hardware components or processing components executing software routines, or a combination of both. The protocol is designed down to layer 2 of the OSI model and works with wired and wireless standards. Embodiments allow programmable network packets using smart contracts, forming mesh networks with decentralized traffic auditing and metering, forming private mesh chains, virtualizing and binding OSI layer 2 connections, ranking peer nodes, and performing decentralized distributed network routing.

[0042] FIG. 2A illustrates a large-scale network that implements a blockchain based network protocol, under some embodiments. As shown in FIG. 2A, 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.

[0043] 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. 2A 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.

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

2A illustrates an example network and many different network configurations and

topographies are possible.

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

[0046] FIG. 2A 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-Based Network Protocol

[0047] FIG. 2A illustrates a network system that implements blockchain and smart contract technology. As is known, 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 intemode 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 credi ble transactions without third parties through transactions that are trackable and irreversible.

[0048] As shown in FIG. 2A, at least one computer or network resource, such as server 104 executes a block-chain based protocol process 104. In practical application each of the nodes or resources in the network 100 executes at least some portion of the protocol to communicate with other peers using the protocol. As such protocol 104 may be a processing component that is resident or executed in any of the nodes of the network. For purposes of illustration, it is illustrated and described in relation to the example embodiment of FIG. 2A as a processing component executed by server 102.

[0049] The protocol 104 defines the rules and provides the primitives by which peers can securely connect and communicate in order to form and participate in the network, a global construction that nodes can join and leave at will. The protocol facilitates secure network communication and smart contracts for network packets and has been designed down to layer 2 of the OSI model and works with wired and wireless standards. It is interoperable with existing internet infrastructure and provides enhanced layer 2 and layer 1 functionality such as transmission level security.

[0050] FIG. 2B illustrates the protocol 104 as a layer that maps networks and

subnetworks to respective blockchains, under an embodiment. As shown in FIG. 2B, a number of subnetworks, denoted A, B, and C exist in an overall network, such as network 100 of FIG. 2A. Each subnetwork may comprise any appropriate number of nodes and be of any configuration, such as sub-mesh networks, point-to-point networks, LANs, WANs, and so on. Each subnetwork has an associated blockchain. Such a blockchain may be a side chain or mesh chain spawned off of a global blockchain. Thus, as shown in FIG. 2B, global blockchain 220 has associated side chains A, B, and C. The protocol layer 210 maps each subnetwork to the corresponding side chain. FIG. 2B illustrates a simplified example of a protocol mapping under some embodiments, and any scale and configuration of subnetwork and blockchain mapping may be possible.

[0051] In an embodiment, the side chains may be programmatically created from global blockchain 220 or other block or side chains through a programmatic creation method, such as described in co-pending PCT Patent Application No. _ , entitled "Programmatic

Creation of Blockchains," filed on _ , and which is hereby incorporated by reference in its entirety.

[0052] The protocol can be broken down into three major components as illustrated in FIG. 3. The first component is the mPipe, which provides a secure communication channel for transporting network traffic between peers. The pipes are established all the way down to layer 2 of the OSI model and provide encryption, routing, and processing capabilities. The mPipe can be extended by an extension called the mLink that allows the protocol to work with wireless standards to allow the protocol to be used as an overlay on existing internet infrastructure. With the mLinks, the protocol has been designed to be used with wireless protocols such as Bluetooth, Wi-Fi, and the U-NII-3 radio band to power scalable mesh networks, both public and private.

[0053] The second component 304 are smart contracts through which network packets can be routed and processed using smart contracts. This technology unlocks numerous use cases for smart decentralized networking applications such as software-defined networking, intrusion detection and prevention systems, content delivery networks, and distributed virtual private networks.

[0054] The third component 306 is the branch chain. New blockchains can be programmatically jump started by branching from a global chain, and each of these branch chains can have its own custom rules which are specified via a special type of smart contract called a branch contract. For example, if a blockchain project wants to create a new token or migrate its existing token to a dedicated chain, this can be achieved by invoking a branch chain. We also use branch chains to organize nodes participating in mesh networks, decoupling them from having a strong dependency on a global blockchain. This type of branch chain is called a mesh chain.

[0055] Network 100 globally organizes and enables the formation of autonomous networks between peers, which may be infrastructure service nodes, internet-enabled computing devices, or network end users. The network implements smart contracts that are agreements between these peers defining how much data will be exchanged, for how long, what types of smart packet contracts will be enabled, and at what fuel price. FIG. 4A illustrates an example network 400 that globally organizes and enables the formation of autonomous networks, under some embodiments. The network connects peers 401 (which may be infrastructure service nodes, Internet-enabled computing devices, or network end users) through smart contracts 702 that are agreements between these peers defining how much data will be exchanged, for how long, what types of smart packet contracts will be enabled, and at what fuel price. The connections can be implemented through pipes 403 or wireless links 704.

[0056] The network 400 of FIG. 4 A can be expanded to any appropriate scale, and represent a private or local area network (wired or wireless) that can be coupled to a greater network. FIG. 4B illustrates an overall network comprising a public mesh network and a set of local networks to form a blockchain based protocol platform. As shown in FIG. 4B, a number of separate or independent blockchain networks 424 (e.g., Blockchain Network A and Blockchain Network B) and a number of local area company networks 426 (e.g., Company X Network and Company Y Network) are coupled to a public mesh network 422. This overall system 420 may be referred to as a "platform" and supports at least one blockchain based protocol network coupled to one or more other networks, some or all of which may also implement the blockchain based protocol 104. As such, the platform 420 essentially represents a network of networks, and may be of any scale and composition.

[0057] The composition and scale of each individual blockchain or company network (424, 426) may also vary. FIG. 4C illustrates a multi-node network and physical links for a network within the platform of FIG. 4B, under some embodiments. For the example of FIG. 4C, network or sub-network 430 comprises send nodes denoted nodes A to G. Each of these nodes is connected to every other node, either directly or indirectly through intermediary nodes. FIG. 4C is provided as only one example of interconnected nodes within a blockchain network, and many others are also possible.

[0058] In an embodiment, individuals, network operators, and Internet service providers can participate in the network by contributing their bandwidth or compute resources to the network. In return for contributing resources and processing smart packet contracts, network nodes periodically receive network tokens as part of an exchange. In an embodiment, a token used in network 100 is referred to as an "mToken" and is the base unit of measurement for distributed networking and computing, the fuel consumed for network usage, administration, and smart contract processing.

[0059] While the network 100 can interoperate with existing internet infrastructure, it is also self-sustaining, capable of obviating existing network infrastructure by forming direct peer-to-peer connections to facilitate wireless mesh networks that remove the need for hardware switches, routers, and bridges. In essence, the network enables and incentivizes users to assemble and securely exchange network infrastructure resources without the physical, financial, and regulatory limitations that hinder traditional approaches to building, connecting, operating, and maintaining network infrastructure at scale. End users can utilize the network to access the Internet or nearby compute power, either by procuring tokens or by mining them through operating a contributing service node. Developers can utilize the network to create and deploy intelligent, decentralized networking applications that can be run by end users or service nodes. Private institutions and enterprises can utilize the network and the platform its built on to manage their infrastructure and develop smart distributed networking and cybersecurity services.

mPipe

[0060] As shown in FIG. 3, the pipe 302 is the first of the three major components designed to allow secure, seamless connectivity and cooperation between network peers. In an embodiment, the pipe (or "mPipe") is an implementation of a virtualized data link layer which provides a communication channel, or pipe, for transporting network traffic between peers. Conceptually this is similar to the Layer 2 Tunneling Protocol (L2TP). These pipes are a fundamental building block of the network, and because they are established all the way down to layer 2 of the OSI model, they allow several important capabilities such as custom packet routing and processing, increased security via packet-level encryption, and easy discovery of neighboring peers transmitting on the same local medium. FIG. 5 illustrates an implementation of an mPipe, under some embodiments. FIG. 5 shows the hierarchy of the seven OSI Layers 502 with an mPipe 504 implemented between drivers in Layer 2. When creating a pipe, a secure connection is formed between two peers by using a Diffie-Hellman (or similar) exchange to create three shared secrets: one for data encryption, one for checksums to achieve data integrity, and one used as a seed. Each peer combines this seed with the current time truncated to a pre-defmed granularity (e.g., one minute) to obtain a new seed that changes over time. This in turn, is used to mutate the data encryption secret and data integrity secret based on the current time interval, similar to a time-based one-time password (TOTP), to help harden the data stream against attacks such as traffic pattern analysis.

[0061] FIG. 6 illustrates a process of mutating encryption to encode data over an mPipe, under some embodiments. As shown in FIG. 6, over time, a first set of payloads 602 is encrypted using encryption key A, a second set of payloads 604 is encrypted using encryption key B, and a third set of payloads 606 is encrypted using encryption key C. This figure is meant to be for example only, and any number, size, and composition of payloads is possible, and any practical number of encryption keys may be used to encrypt respective sets of payloads.

[0062] A system of symmetric keys is used for performance. Packets will constantly be traversing many pipes, and useful cryptographic operations as defined in AES (advanced encryption standard) are directly supported in the instructions sets of many hardware components. Table 1 lists three keys that can be used in an embodiment.

Table 1

[0063] As shown in Table 1 above, each key is a symmetric key, such as an AES

(advanced encryption standard) cipher key, as known to those of ordinary skill in the art. It should be noted, however that embodiments are not so limited and other types of cipher techniques to embody the keys may also be used. The L2 key is used for checksum and data integrity, the L2/L3 key is used for data encryption and the master key is used for mutating the L2 and L3 encryption by implementing key changes over time, such as by modifying a time stamp. Though embodiments are described with respect to the illustrated symmetric keys, embodiments are not so limited and other keys or even methods of asymmetric encryption are possible.

[0064] The mPipe operates at the level of a network driver and can thus be very performant both in terms of encryption and decryption, as well as in terms of packet-level processing. This enables several interesting network features, such as packet relay, packet throttling, and packet inspection. With respect to packet relay, within the network, packets can be relayed through multiple hops before exiting into the Internet or private networks. Similar to onion routing, this improves privacy and helps protect against snooping, as only the network edge node is aware of the end user. With respect to packet throttling, because connections are at OSI layer 2, the network has access to maximal information. Therefore, it can easily throttle network packets using a variety of different strategies to meet network requirements. With respect to packet inspection, because the network can access data from all OSI layers above layer 2, it can make decisions based on payload contents. Even if data is encrypted at higher layers, interesting metadata is still available, such as domain names and header information. Smart Contracts

[0065] With respect to the smart contract component, with smart packet contracts, developers have the ability to run smart contracts against network packets to do smart routing and packet processing. The network 100 provides a platform where developers can create decentralized networking applications using smart packet contracts. FIG. 7 illustrates a process of processing data packets with smart packet contracts, under some embodiments. As shown in FIG. 7, unprocessed packets are input to network driver 704 and processed packets are output after decoding in codec 706 and processing in the smart contract processor 708. A decentralized application 702 comprises a number of functions, denoted Function A, Function B, and Function C. These are input as a smart packet contract 703 to the smart contract processor 708 of driver 704. Application of the application to the unprocessed packets by the smart contract processor 708 generates the processed packets output by the driver 704.

[0066] FIG. 7 shows the components that interact when executing a smart packet contract. The code is executed on incoming network traffic, and any result or state information (e.g , host ID that has sent back network traffic) could persistent back to the blockchain. Once this information is stored, it can be accessed by the decentralized application. For example, it can be used to show how any host that has seen bad network traffic. The code sample below ("Contract PhishCatcher") provides a code snippet of a sample smart packet contract.

[0067] Any appropriate application may be used for the decentralized application 702. Example applications include software-defined networking (SDN), intrusion detection and prevention systems (IDS/IPS), anti-malware and anti-virus protection, content delivery networks (CDN), virtual private networks (VPN), and new blockchain protocols. [0068] In an embodiment, applications are written in a scripting language programming language, referred to as "mScript," which is a Turing-complete language which has access to network packets and compiles down to bytecode. Embodiments also include three tiers of APIs in a network library: (1) a control API for operations that affect routing and traffic flow, (2) a content API for operations like inspecting payloads, and (3) an intelligence API for pattern analysis and machine learning. Once written, developers deploy applications to a global blockchain, the structure of which will be described in greater detail below.

[0069] FIG. 8 is a table that illustrates the composition of a smart packet control API, under some embodiments. FIG. 8 shows the functions of mOpen, mClose, mApply, and mList with corresponding descriptions. The API of FIG. 8 is intended to be for example only, and any similar set of functions may be used. Example usage of the control API to detect suspicious EIRLs is exemplified by the following programming code:

Contract PhishCatcher {

Init (Address client_address ) {

TunnelRef handle = mOpen ( client_address ) ;

mApply (handle, {PhishFunc});

}

}

Status PhishFunc (PacketRef packet) {

if (packet . src ( ) .url() .as_string() .match (' /u000- /uO07F ' ) ) {

return Status :: UNSAFE ;

}

return Status:: OK;

} [0070] With regard to system performance, it should be noted that since applications may be performing low-level packet processing on a large amount of network traffic through a virtual machine layer. Fortunately, heavyweight processing such as pattern analysis can be done off the critical path by cloning and batching up traffic. For high-throughput real-time processing, embodiments may provide acceleration through custom hardware or other mechanisms.

[0071] Embodiments of the smart packet contract design are also compatible with existing open source projects in this space, for example Snort, a popular network intrusion detection system and intrusion prevention system. Support for these projects is provided to ensure that smart packet contract development model is easily accessible to developers in these open source communities.

OSI Layer 2 Utilization

[0072] Many people take for granted today’s internet infrastructure and topology. For instance, common approaches to building network applications often make several assumptions such as a constant connection to the internet and an IP address obtained through DHCP. However, when operating outside of or slightly beyond the edges of the public internet, these assumptions do not always apply. For example, in private networks, wireless peer-to- peer networks, or when bridging between such networks. In these cases, OSI layer 2 must be considered, such as in peer discovery and mechanisms like the Address Resolution Protocol (ARP).

[0073] Because components like Marconi Pipe and Marconi Link have access to OSI layer 2 data, they can observe MAC addresses to better understand physical network topology. This enables custom routing techniques for more performant traffic routing. For example, referring to network 430 in FIG. 4C, if node A wants to send data to node G, it can utilize multiple outgoing links through nodes B , C, and D in order maximize data throughput and redundancy. This is especially useful in the context of wireless mesh networks, in which physical links change fairly often as users move around, and which consist of heterogeneous devices with different connectivity capabilities such as smartphones, wireless access points, and wireless repeaters. This ability to perform low-level custom routing is also useful in the context of large wired networks such as private corporate networks, where alternative path optimization strategies can be preferable such as those used in the Open Shortest Path First (OSPF) protocol.

[0074] In an overlay case, such as when communicating through the existing public internet, network nodes typically have less leeway than when communicating directly through one another. With the Internet, traffic must abide by stricter legacy rules to maintain interoperability since we cannot immediately overhaul the packet-switching infrastructure and protocols already in place. Embodiments include a virtualized data link layer that allows nodes to easily communicate whether they are direct neighbors or separated by many physical hops in an underlying network like the Internet. It also provides additional utility via lower level encryption and optional obfuscation techniques by leveraging multiple nodes. mLink

[0075] As shown in FIG. 3, the third fundamental component of protocol 104 is the link function, also referred to as mLink. FIG. 9 illustrates an mLink within the OSI model, under some embodiments. As shown in FIG. 9, an mLink 942 is formed between two drivers residing at OSI layer 2. The access points at OSI layer 1 are coupled together over virtual link 944.

[0076] The mLinks are also a core building block for mesh networks which address problems like wireless network proliferation. The need for coordination is apparent when considering a typical Internet access experience, such as being exposed to many different network names when trying to connect to the Internet over Wi-Fi. Through mLinks, nodes have the ability to easily to join the same network and are incentivized to do so. In this manner, nodes can coordinate to transmit data more efficiently, which additionally yields better network range.

[0077] In an embodiment, a node joins the mesh network 100 through a discovery process in which the node first observes decibel levels to choose the best peers. The node then forms mLinks with those peers on the least loaded available channel. This involves a Diffie-Hellman exchange similar to mPipes in order to secure communication between nodes.

[0078] The mLinks utilize a wireless driver that is compatible with low-cost hardware repeaters and existing wireless standards such as Bluetooth and Wi-Fi, so no custom equipment is required to attain ranges on the order of 10 to 100 meters per device. Certain custom equipment may be used to take advantage of the relatively new U-NII-3 radio band to send information over multiple kilometers each hop, similar to wireless internet service providers. The compatible wireless driver also gracefully handles wireless network congestion through channel negotiation for optimum connections between nodes.

Blockchain Implementation

[0079] As described herein, embodiments of network 100 implements blockchain and smart contract technology. As is generally known, 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 intemode 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.

[0080] FIG. 10 illustrates implementation of a blockchain for use in network 100 of FIG. 2A, under some embodiments. FIG. 10 illustrates an example chain of three blocks 1002, 1002, and 1004 denoted respectively as Block 0, Block 1, and Block 2. As shown in FIG. 10, 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.”

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

[0082] The security of the blockchain can be further enhanced by storing the blockchain data on a distributed network. FIG. 11 illustrates an example distributed network storing blockchain data. As shown in FIG. 11, a large number of users 1102 attempting transactions 1103 can have access to the blockchain network 1104 and miner nodes 1105 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.

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

[0084] 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. A method of processing a transaction in a blockchain network 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. The transaction request can be broadcast to the blockchain network. If the blockchain network of nodes does not validate the transaction, the transaction is stopped and the transfer of ownership is not recorded. If validated, however, the transaction is combined with other transactions occurring at the same time to form data for a new block which is added to the blockchain. The recorded transaction in the blockchain is evidence that the next owner identified in the transaction request is now the current owner.

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

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

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

[0088] In an embodiment, network 100 makes use of several blockchains for network administration and metering. Network administration involves keeping track of nodes as they join or leave the network, while metering involves measuring and recording the bandwidth capacity and contribution of each node. This is accomplished with a system comprised of a single global blockchain and many side chains which are called 'mesh chains.' FIG. 12 illustrates a global chain and mesh chains used in a network, under some embodiments. For the example embodiment of FIG. 12, a global chain 1202 has two mesh chains 1204 and 1206. The mesh chains always originate from the global chain, first branching off and then periodically merging back before rebranching. Certain administration transactions may be recorded in the global chain, while certain metering transactions may be recorded in one or more of the mesh chains.

[0089] The global chain 1202 uses memory-hard proof of work to add blocks, and all nodes in the network can contribute to this chain. Memory-hard proof of work is chosen for an for ASIC resistance in a certain implementation, and so that the existing cryptocurrency mining community can begin mining without changing any of their hardware setup. The particular choice of hashing algorithm is decoupled from the rest of the system design and instead isolated as an implementation detail, that way the specific algorithm can be changed relatively easily if necessary, for example if an otherwise-viable ASIC is developed. The contents of the global chain include registration transactions containing nodes’ public key identifiers, mToken transactions, smart packet contract transactions, and checkpointing transactions which allow branch chains to periodically sync their aggregated state to the global chain.

[0090] Branch chains are a generic construction that allow programmatically creating new blockchains that are attached to and run in parallel with the global chain. Each branch chain can have its own custom rules which are specified via branch contracts. This makes branch chains a flexible primitive that can be used in a variety of interesting ways.

[0091] One example of a branch chain is a mesh chain, which corresponds to a group of nodes that have decided to band together to form a subnetwork. These nodes are typically but not always geographically near one another. Hence there can be many different mesh chains, and they come in two types: public, such that any node can contribute, and private, e.g., for enterprise networks. The purpose of mesh chains is to decouple subnetworks from the global chain in order to improve network robustness and scalability. Mesh chains offload data and communication overhead from the global chain and allow nodes in subnetworks to often avoid interacting with the global chain. The contents of a mesh chain include registration transactions from nodes joining the subnetwork as well as many proof-of-network-elements transactions. These are cryptographically verifiable exercises that are being repeated constantly by nodes in a subnetwork, exercises which involve sending and receiving nonces to and from neighboring nodes to prove availability and bandwidth, and nodes generally are incentivized to keep performing this exercise. In an alternate embodiment, rather than proof of work, mesh chains can use proof of stake to add blocks, where subnetwork nodes who have participated in a larger number of proofs of network elements have a larger stake. Proof of stake for mesh chains is selected for increased transaction throughput and to lower compute power requirements in contributing service nodes.

[0092] In order to join a mesh chain, a node must first have registered its public key and public key hash on the global chain. This allows the node to participate in smart contracts and mToken transfers. Then the node needs to find out which subnetwork to join. This is done by broadcasting to its neighbors to obtain their IP addresses, and by querying a distributed hash table (DHT) maintained by all network nodes which maps subnetwork IDs to a list of IP addresses within each subnetwork. Given this information, the node can register itself on the local mesh chain, a transaction that requires signatures from nearby peers which indicate they can reach the new node.

Proof of Network Element Process

[0093] 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 protocol 104 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. 2 A, protocol 104 thus includes a proof of network elements process. 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.

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

[0095] Using this process, 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 in FIG. 13, which illustrates a triangle 1300 of three nodes, A, B, and C, and the various encrypted data packets transmitted among them in accordance with the description above.

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

Network Administration

[0097] There are generally three types of actors who participate in the network 100. First is the node operator, who runs one or several service nodes that contribute resources to a public mesh network. These nodes perform functions chosen by the operator, which might include allowing end users to connect, processing smart packet contracts, confirming blocks on the global chain or mesh chain, traffic metering, or bridging different mesh subnetworks. The operator may choose to contribute to an existing mesh network, or generate a new mesh network as a branch from the global blockchain by invoking the proper smart contract for creating a new mesh chain.

[0098] The second actor is the network operator, who needs to manage a fleet of hardware in particular ways. The network operator invokes a smart contract on the global chain which generates a new private mesh chain to form a new private network. An example of this is shown in FIG. 14, which illustrates the creation of public and private mesh chains using smart contracts. As shown in FIG. 14, global chain 1402 has two mesh chains 1404 and 1406, and a smart contract public mesh chain and a Company X mesh chain. Also specified in this smart contract are the rules specific to the private network such as which smart packet contracts are enabled, e.g., for network efficiency through software- defined networking, or for end user protection through anti-phishing tools. Examples of network operators include companies, local ISPs, or new blockchain protocols.

[0099] The third actor is the end user, who may join a public mesh network at any time or a private mesh network if authorized to do so. When joining a public mesh, the user opts into the smart packet contracts they choose, while in a private mesh they must abide by the rules of that mesh.

[00100] Embodiments of protocol 104 also include a peer rank mechanism. This comprises a reputation system to measure node and subnet quality. The network can track each node’s capacity and availability over time by observing the results generated by its proof of network elements exercises in order to produce a normalized score based on these metrics relative to nearby peers. Nodes that behave well and coordinate with peers who have a strong score will themselves tend to have a better score. This weighting system is called PeerRank and yields a stack rank of network nodes and subnets which can be used in a variety of situations such as determining which nodes can accept new connections from network peers and still maintain their current connections. Scores are also a convenient signal for end users when deciding which nodes to which to connect.

[00101] The PeerRank score for each node is periodically synced to the global chain based on the node’s recorded behavior in its respective mesh chain. This associates the score with a public key identifier so that any other node can observe and make use of it.

[00102] Embodiments also include a mechanism to reduce complexity in mesh networks. As stated above, the protocol 104 supports wireless networks and peer-to-peer mesh networks. Managing connections between nodes and ensuring performant traffic routing in such networks can be challenging since the number of possible connections grows as 0(n ) where n is the number of nodes.

[00103] Consider for example a mesh network of just four nodes A, B, C, and D, as shown in FIG. 15. If node A wants to send data to node D, there are many possible paths to choose from: AD, ABD, ACD, ABCD, and ACBD. To reduce this complexity, the protocol combines and binds multiple OSI layer 2 connections in a given network node into a single virtual network interface with OSI layer 3 configuration data, similar to how operating systems can bridge multiple physical network interface controllers to achieve higher capacity and redundancy for network connectivity. This binding removes complexity for node and network operators as well as for developers writing smart packet applications. It also provides connection redundancy and fault tolerance in case a network link is lost, and increased throughput since it grants the ability to distribute outgoing traffic over multiple paths.

[00104] FIG. 15 illustrates a simple example mesh network 1500 comprising four nodes (n=4) in which each node is connected to every other node. Network 1500 is provided as an example of a network implementing an OSI Layer 2 binding process under some

embodiments. If any node wants to communicate with a specific other node, several network paths are available. For a full mesh network, the network topology formula is generally expressed as (n(n-l))/2, where n is the number of nodes in the network. For example, in network 200, if node A wants to communicate with node C, there are six total interfaces to node C including C itself and five possible paths from A to C:

A to C

A to B to C

A to D to C

A to D to B to C

A to B to D to C

[00105] It should be noted that FIG. 2A illustrates a simple four node network for simplicity and purposes of example and description only. Actual deployed networks using embodiments described herein may be more complex and of different configurations.

[00106] Under the OSI model of FIG. 1A, layers 1, 2 and 3 are media layers while layers 4 along with layers 5, 6 and 7 are host layers. The data link Layer 2 is a broadcast MAC level network, and provides error-free transfer of data frames between nodes over the Layer 1, where the data frames contain MAC addresses. Layer 2 establishes and terminates the logical link between nodes, provides frame traffic control, sequencing, acknowledgement, delimiting, and error-checking. The network Layer 3 provides segmented routing over IP network and controls operations of the subnet by deciding which physical path the data takes. It processes data packets that contain the IP addresses. Layer 3 provides routing, subnet traffic control, frame fragmentation, logical-physical address mapping, and usage accounting functions. The transport Layer 4 delivers messages in sequence and error-free. It provides flow control functions between hosts through message segmentation, acknowledgment, traffic control, and session multiplexing. [00107] As used herein and corresponding to known conventions, a MAC address or Media Access Control address of a device is a unique identifier assigned to a network interface controller (NIC) for communications at the Data Link layer of a network segment.

MAC addresses are typically used in the medium access control protocol sublayer, and are usually presented as six groups of two hexadecimal digits. A MAC address may also be referred to as the burned-in address (BIA), hardware address or Ethernet hardware address (EHA), or physical address. A node may have multiple NICs and each NIC must have a unique MAC address. MAC addresses are most often assigned by the manufacturer of a NIC and are stored in its hardware.

[00108] Under the OSI model 300, Layer 3 works on top of Layer 2, which works on top of Layer 1. While the actual data bits are transferred over the physical or wireless medium on Layer 1, frames are used to define the data between two nodes on a data link. When there are more than two nodes, an address or routing protocol is used to route and control the traffic flow. Thus, traditional switching operates at Layer 2 of the OSI model, where packets are sent to a specific switch port based on destination MAC addresses. Routing operates at Layer 3, where packets are sent to a specific next-hop IP address, based on destination IP addresses. Devices in the same Layer 2 segment do not need routing to reach local peers. The destination MAC address is resolved through an Address Resolution Protocol (ARP).

[00109] With respect to data addressing, Layer 2 defines the protocol to both establish and terminate a physical connection between two devices. Layer 2 works with the device MAC addresses, which are unique identifiers for the network adaptor present in each device. A MAC address is thus a fixed address to the network adaptor and cannot be changed on a device without changing the hardware adaptor. Layer 2 networks forward all their traffic so data transmitted by one device on Layer 2 will be forwarded to all devices on the network. Such broadcast traffic is fast, but as the network grows it creates congestion and leads to inefficiency.

[00110] In contrast to Layer 2, Layer 3 works with IP addresses, which are essentially ‘leased’ or‘assigned’ generally to the nodes by a DHCP (dynamic host configuration protocol) server. As IP addresses are a layer of abstraction higher than MAC addresses, traffic using this layer is generally slower than Layer 2. Furthermore, Layer 3 traffic restricts broadcast traffic through segmentation and restricting broadcast traffic to subnetworks. In a Layer 3 transmission, for each data package, the IP portion is read by stripping the data link layer (Layer 2) frame information and is then reassembled again. From there, the hop count is decremented, the header checksum recalculated and a routing lookup executed. In general, a Layer 2 network is more useful broadcasting information between two nodes in close proximity where a broader network would not be affected by congestion, while a Layer 3 network is better for managing network traffic over multiple sites and through the internet because L3 network switches work with routing of IP addresses.

[00111] In an embodiment, a binding process of the protocol 104 groups or "binds" connections in a mesh network to reduce the complexity of connections between sets of nodes in a mesh network. For example, in FIG. 15, all of the connections between nodes A and C can be bound together to look like one connection, thus significantly reducing connection complexity, such as by a factor of 5 to 1 in the case of full four-node mesh network. In an embodiment, this binding is performed by implementing the node connections at the OSI Layer 2 data link layer. An Ethernet bridge is created to bind all the tunnel connections with a specific node. A virtual NIC (network interface controller) is used to generate a single MAC address for the bound connections. The virtual NIC behaves as a switch in routing traffic from the MAC address to bound tunnels from the bridge. A new IP address is generated to represent the MAC. Communication between newly generated IP addresses will then work with any Internet protocols.

[00112] In general, a tunnel is defined as a communications link that uses a tunneling protocol to repackage data traffic into a different form for transmission between network nodes. A tunnel is a mechanism used to ship a foreign protocol across a network that normally would not support it. For example, a tunnel allows IP networks to send another protocol in the data portion of the IP datagram. In this case, the tunneling protocol uses the data portion of a packet (payload) to carry the packets that provide the service. In the OSI layered protocol model, it can be used to break the layering when using the payload to carry a service not normally provided by the network. In an embodiment, the tunneling protocol of the OSI model of FIG. 1 A uses the data link layer, such as using the Layer 2 Tunneling Protocol (L2TP). Other tunneling protocols can also be used, such as SSH (secure shell),

GRE (generic, routing encapsulation), and so on.

[00113] FIG. 16 illustrates the network of FIG. 15 showing binding of multiple tunnels to a single virtual MAC address for a node. FIG. 16 shows all of the possible links between nodes A and C for the mesh network FIG. 15, which are as follows:

A - C

A - B - C

A - D - C

A - D - B - C

A - B - D - C

[00114] The binding process of component establishes Ethernet bridges between each pair of nodes in the network. These bridges effectively bind all the tunnel connections with a specific node. Thus, as shown in FIG. 16, the five possible connections between nodes A and C are bound to a single virtual MAC address in Layer 2 for the possibly different IP addresses of the individual links shown above. The virtual NIC for node A (VNIC_A) is used to generate the single virtual MAC address for the bound connections. The virtual NIC thus behaves as a switch in routing traffic from the MAC address to bound tunnels from the bridge for node A, and a new IP address is generated to represent the MAC for node A. Through this mechanism, data is essentially aggregated to form a virtual bridge.

[00115] As shown in example diagram 1600 of FIG. 16, the tunnel connections between network peers are combined and bridged into a virtual network interface which is assigned for enforced OSI Layer 3 configuration data by the network to communicate among all of the network peers. This is somewhat similar to how modem operating systems (such as Linux or BSD) can create a virtual interface such as bridge interface through combining multiples physical network interface controllers (NIC) to achieve higher capacity and redundancy for network connectivity.

[00116] In an embodiment, the individual OSI Layer 2 tunnel connection that implements the bridge connections represents the mPipe described above. Since the network peers are connected and bridged through OSI Layer 2 tunnels, this bridge mechanism provides similar redundancy and recoverability in physical network layers. For example, if one of the direct network Layer 2 tunnel connections with a peer node is disconnected, (unintentionally or intentionally), the network utilizes the Layer 2 protocol address resolution protocol (ARP) to find an alternative OSI Layer 3 path to transmit the data, while the lost or disconnected Layer 2 tunnel connection is recovered or replaced with other network service nodes.

Token Implementation

[00117] As mentioned previously, the mToken is the token that powers the network 100. These utility tokens can be used for network bandwidth or consumed as fuel for smart packet contract processing. Service nodes receive mTokens when confirming blocks or successfully completing proofs of network elements. MTokens are also required for some types of network operations such as staking in a mesh chain or creating a transaction to start a new private mesh chain. The mToken is essentially a number that represents or embodies an entry, value, or account balance on the distributed ledger. As such, it may be any appropriate numerical value or ledger entry.

[00118] The number of mTokens required to perform work in the network is determined by several parameters. It can be modeled as a function / (a, b, y, d) where a is the bandwidth used, b represents the quality of service of the delivered bandwidth, y represents the complexity of any executed smart packet contracts in terms of compute and storage, and d is the fuel price set by the client. A provider may accept the fuel price in which case the work is performed, or reject the fuel price in which case the work is ignored. Similar to other minable fuel -based blockchains, the supply of mTokens will initially increase at a larger rate to incentivize miners to bootstrap the network, then slow down to reach a minimum rate of increase after a total of ten years. FIG. 17 is a graph showing a prospective token supply over time, under an example embodiment. As shown in FIG. 17, it is expected that after an initial supply, the mined supply will grow and gradually taper off as the time period approaches 10 years. Graph 1700 of FIG. 17 is provided for purposes of illustration only, and other amounts of token supply over time are also possible.

Applications

[00119] The blockchain based network 100 using protocol 104 and its smart packet contracts provide a robust decentralized networking stack and platform that enables developers to build many powerful applications.

[00120] New blockchain protocols can be developed and launched on top of the network protocol platform using smart contracts, gaining its built-in benefits for free such as security and net neutrality. Existing blockchain protocols can begin using the Marconi Network for inter-node communication, taking advantage of its augmented and eventually fully decentralized network infrastructure, with virtually no code change. FIG. 19 illustrates phases of decentralization for a blockchain based protocol platform, under some embodiments. As shown in FIG. 19, the phases include a centralized network infrastructure 1901 in which users and company resources are coupled to services through a central ISP, thus leading to the disadvantages described previously. A better solution is the augmented network infrastructure 1903 that implements some direct and secure links between the users/company to the services and at least partially bypasses the central ISP. An optimum solution, such as provided by the blockchain protocol 104 is the decentralized network infrastructure 1905 which provides a comprehensive set of independent secure links between the users/company to the services. In such an environment, only a local ISP is used, such as when certain users may need or want to utilize locally or centrally available resources.

[00121] In an embodiment, the platform can power existing protocols as well via a migration process. For example, if a token is implemented in terms of a common standard such as ERC20, then its rules can easily be reimplemented using the smart contracts. Once this implementation is in place, it can be specified as the basis for a new private mesh chain that gets branched from the global chain, and a smart contract migration service can be used to copy built up state such as account balances to this new private chain. FIG. 18 illustrates an example of token migration to a private mesh chain under the network protocol. As shown in FIG. 18, for global chain 1802, a private chain 1804 is generated. Contract migration service 1806 is used to generate a new platform from the old platform for the private chain 1804. After this private chain has proved to be running smoothly, all services can be pointed to use it, and the old token implementation can then be turned off, at which point the new chain is used for all token transfers. This new chain 1804 is still powered by proof of network elements, and still periodically checkpoints back to the global chain. However the parameters are tunable by the creator of the private chain, such as how often proof of network elements can occur and how many tokens are received for completing the exercise.

[00122] Embodiments of the protocol can also implement anti-phishing, anti-malware, and anti-virus protection. This protection can be provided out of the box for end users and even for corporate networks without installing any special software or hardware by instead using smart packet contracts. This is possible through analyzing packet payloads if unencrypted or otherwise through analyzing packet headers, size of packets, number of packets, and domain names. For instance, a common phishing strategy involves constructing misleading URLs which look similar to URLs that users trust, e.g., replacing an ASCII character with a nearly identical Unicode character, then registering the resulting domain name and disguising the new site to appear as the trusted site. Detecting such misleading URLs is quite simple with a few lines of smart packet contract code (e.g., as shown in the example code segment Contract PhishCatcher shown above). While some of the most popular browsers and email clients already implement anti-phishing protection, it remains an afterthought or completely absent from many of the less popular or more basic user applications such as text messaging. By solving this problem just once on the network protocol platform low-level networking layers, it is no longer necessary to reimplement the same solution multiple times at higher layers in every possible user program. This implementation can also be extended with other common anti-phishing techniques such as a database of known bad sites and content, or a machine learning model trained on such sites and content. Finally, the platform allows developers to require mTokens for usage of their decentralized application if they so choose, and these mTokens can, in turn, be used to incentivize end users to report suspicious sites or content.

[00123] Another application is Intemet-of-Things (IoT) device management. As the number and capabilities of IoT devices increase, so too will the number of possible applications they can power, as well as the need for secure communication between them. Through the protocol and its smart packet contracts, these devices can securely and gracefully interoperate and be coordinated on-demand to work together to solve complex problems, putting locally available hardware to good use in a modern day variant of distributed grid computing. Taken together, the network protocol and APIs provide a platform that can put directly into the hands of developers the combined power of multiple smartphones, workstations, and even GPUs (graphics processing units) in self-driving cars to benefit users both nearby and far away, enabling a new class of applications.

[00124] Also implemented is a content delivery network (CDN). Large or commonly accessed internet content can be cached by nodes in the network so that it can be served more locally to consumers, yielding more efficient use of bandwidth and improved latency.

Examples of such content include video files or historical blocks from various popular blockchains which must be synced by new mining nodes. This would drastically decrease the time needed to set up mining nodes from scratch. A decentralized, peer-to-peer CDN is also a competitive option for content providers because there’s no overhead cost for initially bringing up the delivery network, nor any ongoing cost for maintaining network hardware. There is only the cost of deploying and serving the bytes themselves, and the ability to do traffic metering is already built into the network.

[00125] Also possibly implemented is Software-Defined Networking (SDN). Machines can be managed and controlled through distributed network virtualization which allows for dynamic reconfiguration and reprogramming of network hardware from a single console; for example, spinning up new nodes for load balancing or traffic shaping.

[00126] Advanced Intrusion Detection and Prevention System (IDS/IPS) solutions can also be implemented. In private networks, monitoring can be put in place to detect anomalies in traffic and malicious activity happening on the network, protecting from both external and internal attackers by either notifying administrators or actively blocking suspicious packets.

[00127] Virtual Private Network (VPN) implementations can also be improved. A private network can be extended over a public or shared network, preventing unauthorized access via authentication and protecting privacy via encrypted traffic and a level of indirection. The mLink is especially helpful here for users who demand strong obfuscation of network routes, since wireless hops are much more difficult to track than hops through wired connections. In both the wired and wireless case, users can enjoy the benefits of extra protection with low- level encryption at OSI layer 2. Users can even rotate among multiple entry nodes and exit nodes to further obscure their traffic.

[00128] With respect to security applications, there are several types of attacks to which networks and blockchain systems are potentially susceptible, such as transaction flooding attacks, packet injection, and Sybil attacks. The protocol is designed to mitigate these attack vectors. Because it addresses these attacks at a foundational layer, new blockchain protocols that build on top of it also gain the same protection.

[00129] A transaction flooding attack might add many no-ops or otherwise useless transactions onto the global chain or a particular mesh chain, in an attempt to overwhelm the network with so much work that it prevents normal transactions from being added or processed. To mitigate this attack, most of the transaction types in the protocol require a small security deposit which only gets refunded after some time has passed, and only if the operation completes successfully. For example, if an attacker tries to generate many mesh chains in a short span of time, the number of chains will be limited by the attacker’s available funds, since any transaction without the necessary backing deposit will be rejected immediately. In these newly created mesh chains, if no nodes registered and contributing to them, which itself requires a security deposit, then the deposits used to create the mesh chains will be slashed rather than refunded.

[00130] Packet injection is another common type of attack. Injecting forged network packets into communication streams becomes much more difficult in the blockchain protocol based network due to each hop between nodes being individually protected by OSI layer 2 encryption with a particular combination of symmetric keys via the mPipe or mLink implementation. Without the secret keys, an attacker cannot decrypt the data, which in turn makes it hard to analyze the traffic in order to figure out a possible point for packet injection. Nor will the attacker be able to properly encrypt any malicious packets they construct, hence target nodes can easily differentiate them from trustworthy packets. Even replaying previous packets becomes much less effective due to the mutating encryption keys described above, since the same data may no longer be considered valid due to timestamp mismatch.

[00131] As mentioned, another type of attack is a Sybil attack. The first line of defense against Sybil nodes in the network is cost. Because public key registration and most other transactions require a security deposit, the number of identities an attacker can construct is limited by their available funds. The second line of defense against Sybil nodes is the PeerRank mechanism. Honest nodes tend to prefer working and coordinating with nodes they can trust since they can obtain more mTokens this way and avoid slashed deposits as well avoid drops in their own PeerRank score. For instance, if a node fails to send or receive an appreciable fraction of nonces during a proof of network elements exercise, not only will it and its peers receive less mTokens, but their PeerRank scores will be adversely affected as well.

[00132] Many widely-used cryptographic algorithms can be cracked by a quantum computer utilizing a large enough number of qubits. Though it is unlikely that such computers exist today, they may well exist in the near future. Further developments in the protocol can be adapted to harden the system with post-quantum cryptographic techniques as they continue to unfold.

[00133] As described herein, embodiments are directed to a system allowing smart contracts for network packets as well as programmatically generating branch chains and secure networks. These embodiments overcome the outdated and centralized weaknesses inherent in the current state of network infrastructures. This weak infrastructure is being relied upon by many existing blockchain projects, and thus needs strengthening. This is provided by a new and advantageous network infrastructure that provides a network protocol designed down to OSI layer 2 with robust security, performance, and peer-to-peer meshing capabilities, and by providing a blockchain protocol to enable trustless interoperation and exchange of network resources and incentivize participation in bootstrapping this new network. This platform will ultimately empower developers to build novel distributed and decentralized applications within this protocol.

System Implementation

[00134] Embodiments of the network protocol may be implemented as hardware, firmware, or software, or any combination thereof. The hardware platform executing the software code may be of any appropriate scale.

[00135] In general, the protocol works with existing hardware owned by miners and casual users, but certain users may decide to specialize in a particular facet of network resources such as hashing power to add blocks to the global chain or NICs and access points for connectivity and bandwidth. Depending on the geographical parameters, their mining setups could look very different. For example having access to cheap electricity would naturally point to using more GPUs, while being located in a dense urban environment with many smartphone users might incentivize focusing on connectivity hardware. [00136] To further expand and increase access to the network, open source drivers for low-end devices and hardware (such as the Raspberry Pi) can also be developed. This would allow node operators to build and extend their networks at very low cost. Such as solution could be implemented as shown in FIG. 2A0, which illustrates a low cost hardware implementation of the blockchain protocol, under some embodiments. In FIG. 2A0, Wi-Fi dongles are used to couple end users 2006 to a wireless access point (WAP) 2002 through a single-board computer 2004. The single board computer is generally a low cost personal computer or laptop/notebook computer, and the Wi-Fi dongle is generally a low-cost easily installable component. FIG. 2A0 is intended for example only, and many other low-cost configurations are also possible.

[00137] Embodiments may also be implemented on enterprise-level hardware platforms. Such hardware may meet the needs of certain private enterprises, and custom hardware configurations can be tailored to optimize for client-specific workloads on private mesh chains that differ significantly from the public mesh and global chain cases. An even larger benefit would come from designing and releasing open hardware specifications, tooling, and an open instruction set architecture that provide hardware acceleration for smart packet contracts. This way companies have the ability to relatively easily design, fabricate, and assemble custom hardware to lower costs as well as drastically increase speed and efficiency, thereby enabling a new set of advanced applications and functionality that were previously impossible. FIG. 2A1 illustrates an enterprise-grade accelerator for the blockchain based protocol, under some embodiments. As shown in FIG. 2A1, an accelerator 1902 comprising various processing units, such as CPUs (central processing units, GPUs, and FPGAs

(programmable gate arrays) can be used to provide certain smart packet and proof-of-work acceleration. Such an accelerator can be placed within system of access points 1906 that provide wireless mesh chain acceleration, and NICs 1904 that provide wired mesh chain acceleration. FIG. 2A1 illustrates one example configuration, and other accelerator configurations are also possible.

[00138] As described above, in an embodiment, system 100 includes a blockchain based network protocol 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. 2 A or in any other device in the network. 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. 2A 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.

[00139] FIG. 2A2 illustrates an example computer system implementing a blockchain based protocol, under some embodiments. FIG. 2A2 illustrates a computer device 900 and a 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.

[00140] 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

CLAIMS What is claimed is:

1. A method of defining a blockchain based protocol for transmission of data packets among nodes in a network, comprising:

providing a pipe to provide a secure communication channel for transporting network traffic between peer nodes, wherein the pipe is established at layer 2 of the open systems interconnect (OSI) model

processing the data packets through smart contracts that are implemented as part of a blockchain that includes a history of transactions and data among the nodes in a series of blocks where each block contains a hash of a previous block generated by a hash function; and

providing a branch chain allowing new blockchains to be programmatically generated by branching from a global chain, wherein the branch chain has its own custom rules which are specified through a branch contract.

2. The method of claim 1 wherein the network comprises a wired or wireless mesh network comprising one or more private sub-networks coupled to a global network.

3. The method of claim 2 wherein the pipe provides encryption, routing, and processing capabilities to the network, and further provides extensions through links that allow the protocol to work with wired network standards and to be used as an overlay on an existing Internet infrastructure, and to also utilize wireless communications protocols for coupling the peer nodes, and wherein the wireless communications protocols comprise one of: Bluetooth, Wi-Fi, and the U-NII-3 radio band.

4. The method of claim 3 wherein the pipe is formed between two peers by using a Diffie-Hellman exchange to create three shared secrets: one for data encryption, one for checksums to achieve data integrity, and one used as a seed, and wherein each peer combines this seed with the current time truncated to a pre-defmed granularity, to obtain a new seed which changes over time, and wherein the new seed is used to mutate the data encryption secret and data integrity secret based on a current time interval to help harden the data stream against attacks such as traffic pattern analysis.

5. The method of claim 1 wherein the smart contracts provide smart decentralized networking applications such as software-defined networking, intrusion detection and prevention systems, content delivery networks, and distributed virtual private networks.

6. The method of claim 5 wherein the smart contracts embody application functions that are written in a proprietary Turing-complete script language that has access to network packets and compiles down to bytecode.

7. The method of claim 6 further comprising: providing three tiers of application programming interfaces (APIs) in a network library, and including: a control API for operations that affect routing and traffic flow, a content API for operations including inspecting payloads, and an intelligence API for pattern analysis and machine learning of traffic patterns in the network.

8 The method of claim 1 further comprising defining a mesh chain type of branch chain, wherein the mesh chain comprises nodes participating in mesh networks and that are decoupled from having a strong dependency on the global blockchain.

9. The method of claim 1 further comprising providing proof of a network element in a the network by:

defining a minimal group comprising a triangle of three nodes having parent node as the originator and two child nodes as the neighboring nodes;

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;

decoding, in the neighboring nodes, the at least two data packages for verification; and

storing the result of the verification on the blockchain.

10. The method of claim 9 wherein the data package comprises a nonce comprising an arbitrary random number that is used just once as an input to vary the input to the hash function, and wherein the enveloping step comprises generating a signed hash and encrypting the digital signature on the data, and the decoding step comprises decrypting the digital signature.

11. The method of claim 9 further comprising defining a peer rank reputation metric to measure node and subnet quality by tracking each node’s capacity and availability over time by observing the results generated by its proof of network elements process in order to produce a normalized score based on these metrics relative to nearby peers, and assigning better scores to nodes that behave well and coordinate with peers, wherein a node's peer rank score is periodically synced to the global chain based on the node’s recorded behavior in its respective mesh chain.

12. The method of claim 11 further comprising defining a token as a data element that is used for network bandwidth or consumed as fuel for processing network traffic and running smart contracts, the method further comprising issuing tokens to service nodes that confirm blocks or successfully completing proofs of network elements.

13. The method of claim 2 further comprising binding groups of connections in the mesh network to reduce the complexity of connections between sets of nodes in the mesh network by implementing the node connections at the OSI Layer 2 data link layer, creating an Ethernet bridge to bind all the tunnel connections with a specific node, implementing a virtual NIC (network interface controller) to generate a single MAC address for the bound connections, wherein the virtual NIC behaves as a switch in routing traffic from the MAC address to bound tunnels from the bridge, and generating a new IP address to represent the

MAC.

14. A method for transmitting data in a decentralized network, comprising:

using smart contracts to embody and transmit for network packets;

defining a global chain based chain among nodes in the network, and using a blockchain protocol to enable trustless interoperation and exchange of network resources;

programmatically generating branch chains and secure networks from the global chain; and

providing a network protocol for the network designed down to OSI layer 2 with robust security, performance, and peer-to-peer meshing capabilities.

15. The method of claim 14 further comprising incentivizing participation in the new network through the use of tokens.