Preface

In the recently concluded DoraHacks “Blockchain For Future” hackathon, the first and third winners used NKN’s just-released SDK! To our surprise, 9-year-old girl, Shiry Sree Ju, and her father won the first place with her gun management and personal information security monitoring system based on the NKN testnet. The purpose of the open source community is to encourage community members to participate and co-build the Internet. This is the original intention of the NKN project. Based on blockchain technology, NKN will establish a new Internet infrastructure and ecosystem that is open, decentralized, and shared by the community by enabling digital assetization through micropayments of network resource.

Background

Blockchain technology, after experiencing two important development stages of Bitcoin and Ethereum, is accelerating its integration with the real economy and thus creating new industries and opportunities with its unique token economy. The Internet and networking industry is the field that NKN wants to disrupt. The proliferation of the Internet has made information exchange and transfer ubiquitous and effortless. And once combined with blockchain,, it will make the exchange of value and digital assets as part of people’s daily lives. We call it the future of Value Exchange Internet concept.

What is NKN?

NKN is an open, decentralized, community-built new Internet infrastructure and ecosystem driven by public blockchain. Following that the Ethereum blockchainized computing power, Filecoin/IPFS blockchainized storage, NKN is targeting to blockchainize the third pillar of information infrastructure (network transport) thus creating a new Internet ecosystem. Intuitively, NKN digitally capitalizes network resources and combines the consumption and production of network infrastructure through a unique model of the token economy. Therefore, it can be said that NKN is the first decentralized data transmission exchange, capable of handling large-scale micropayment based on network traffic and serving billions of users. In addition, some shortcomings of traditional telecom industry technologies can be improved. For example, NKN blockchainizes SDN （Software Defined Network), which not only prevents SPOF (single point of failure), but also enables network operators and enterprises to dynamically route based on real-time performance and cost, reducing the cost of data transmission and enhance the efficiency of the entire network.

Through its unique solutions, NKN enables Internet devices in different regions to be interconnected, enabling independent and collaborative construction of decentralized Internet to scale and expand. This new kind of Internet is not constrained by the limitations of computing power, storage, etc., and gives the Internet a powerful capability to expand, achieve true decentralization, openness, self-incentive, privacy and security.

How NKN Empowers the New Internet

At the core of NKN are many connected nodes. The nodes form a logical topology on top of the physical network infrastructure. Each node is only connected to and aware of a few other nodes called neighbors. The topology of the network is verifiable. The network is dynamic such that any node can join and leave the network at any time without causing system failures. Packets can be transmitted from any node to any other node in an efficient and verifiable route. Data can also be sent from and to a client (which only sends and receives data but does not relay data or participate in consensus) without public or static IP address. Instead, permanent NKN address is used with end-to-end encryption.

The relay workload can be verified using our Proof of Relay (PoR) algorithm. A small and fixed portion of the packets will be randomly selected as proof. The random selection can be verified and cannot be predicted or controlled. Proof will be sent to other nodes for payment and rewards.

A node in our network is both relayer and consensus participant. Consensus among massive amount of nodes can be reached efficiently by only communicating with neighbors using our consensus algorithm based on Cellular Automata (CA) and Ising Model. Consensus is reached for every block to prevent fork.

Overview of Design Principles

NKN wants to build a public blockchain platform based on data transmission, to provide services for the entire Internet ecosystem, to power a variety of dApps (decentralized applications), transform traditional telecom business models, design decentralized SDN, empower the IoT (Internet of Things) and vertical industry services. To sum up, NKN intend to become the networking backbone of the Internet to solve decentralization and scalability problems. Therefore, NKN proposed the following design principles:

• Truly decentralized. Use the Cellular Automata methodology to create a peer-to-peer, truly decentralized Internet. No super nodes or root nodes.
• Open and scalable. Any device can easily access NKN whenever and wherever. Scale to millions and billions of smartphones and IoT devices.
• Share network resources. Participants receive rewards from the NKN system by sharing idle network resources with others.
• Co-build network facilities together. NKN encourages individuals and organizations to deploy new nodes and new network infrastructure to serve other nodes and benefit from token rewardt while enhancing network connectivity and throughput.

Design Architecture Overview

The four core elements of NKN technology are decentralized data transmission network (DDTN), proof of relay (PoR), blockchain consensus and incentive allocation mechanism. These elements correspond to the network layer, consensus layer, and incentive layer of the blockchain infrastructure stack, respectively. NKN’s careful design provides a highly reliable, secure and scalable network-oriented blockchain platform.

At the implementation level, the four elements can be extended to seven parts respectively as,

1. Decentralized data transmission network (DDTN)；
2. Proof of relay (PoR)；
3. Consensus and blockchain；
4. Relay path verification (RPV)；
5. Verifiable random function (VRF)；
6. NKN address scheme；
7. Mining economic model.

Here we will introduce these seven parts in turn.

Decentralized Data Transmission Network (DDTN)

The DDTN corresponds to the network layer of the NKN blockchain platform. Its function is to transfer any data to any node/client without any central server.

As a data transmission network, NKN may contain millions of nodes or more. Moreover, the network is dynamic as every node could join or leave the network at any time. At such scale, it is unrealistic for every node to maintain an up-to-date list of all nodes in the network. Instead, every node in the network is only connected to and aware of a few other nodes in the network which are called neighbors.

Network topology, determined by the choice of neighbors, is crucial to performance and security. To be scalable and secure, we need to choose a proper topology that has the following properties: (1) network should be connected and has small diameter; (2) efficient routing algorithms exist between any node pairs using only information about neighbors; (3) load is balanced among nodes given random traffic with uniformly distributed source and destination; (4) choice of neighbors should be unpredictable but verifiable to prevent attacks.

We use the network topology of Chord Distributed Hash Table (DHT). Each node has an m-bit random address on the ring. A node is connected to a set of other O(logN) nodes that have specific distance from it such that the choice of neighbors can be verified. Routing between any node pair is up to O(logN) and is deterministic and verifiable given the topology.

Chord DHT is not the most popular DHT in industry. Kademlia DHT, for example, has been used in more systems. The reason we choose Chord DHT is its verifiability. Chord DHT, despite having a more complex protocol, has the unique advantage that the choice of neighbors and route is deterministic given all nodes addressed on the ring. Both are verifiable to any other nodes. However, in Kademlia DHT, each node is supposed to choose neighbors that have a specific address prefix and are most recently seen, which is not verifiable to other nodes. Thus, a node effectively has freedom to choose its neighbors in each bucket as long as the prefix is the same, and it’s very hard to prevent a node in a malicious party from choosing other nodes in the party as a neighbor or next hop in route. By doing so, the malicious party can gain unfair economic rewards, and can even control the election of mining nodes. This is not a problem in other (non-incentive) distributed systems, but is a disaster in (public) blockchain.

There are two major types of devices in NKN: nodes and clients. A node is a device that sends, receives, and most importantly, relays data. A client is a device that only sends and receives data, but not relays data. Clients interact with the rest of the NKN through nodes.

Nodes are the maintainers and contributors of the NKN network and thus receive token rewards. A node needs to have a public IP address to receive messages from nodes that have not yet established connections with it.

Clients are consumers in the NKN that pay nodes to relay data or receive data through nodes. A client does not need to have an public IP address as it will establish connections with nodes and then send and receive data through them.

Every node and client in NKN has a unique m-bit NKN address between 0 and 2^m — 1. Nodes and clients share the same address space. Once a node or client joins NKN and has a NKN address, an IP address is no longer needed for other nodes to send traffic to it. Instead, the NKN address is the only information needed to send packets to a node or client. The role of the NKN address in NKN is similar to an IP address in the Internet. Please refer to “NKN Address Scheme” section for how nodes and clients choose NKN addresses.

The distance from NKN addresses x to y is defined as

dist(x, y) = (y — x) mod 2^m

which satisfies the following conditions:

• dist(x, y) >= 0
• dist(x, y) = 0 if and only if x = y
• dist(x, z) <= dist(x, y) + dist(y, z)
• dist(x, y) = dist(x + a, y + a)

Note that the distance metric is asymmetric such that dist(x, y) (distance from x to y) is generally not equal to dist(y, x).

Some people may ask, why does NKN define a concept of “distance” in the network? In fact, this is because with the definition of “distance”, you can define the topology of the network. The network topology is extremely important for NKN. E.g:

We first define the successor and predecessor node of any NKN address x

successor(x) = argmin_y {dist(x, y) | y in all nodes}

predecessor(x) = argmin_y {dist(y, x) | y in all nodes}

Successor and predecessor of a node can be defined similarly, except that the successor and predecessor of a node cannot be itself. If node x is the successor of node y, then y is the predecessor of x.

Each node x in NKN has a few neighbors:

successor((x + 2^i) mod 2^m), 0 <= i < m

and

{y | x is a successor of y}

Since not all NKN addresses are assigned to nodes, some neighbors above point to the same node. It is worth mentioning that neighbors are defined to be symmetric such that if y is a neighbor of x, x is also a neighbor of y. The expected number of neighbors of a node is O(log(N)).

Clients connect to the NKN through nodes. A client at NKN address x is connected to predecessor(x). The client sends and receives data only through established connections with the node it’s connected to and thus no client public IP address is needed. Clients in the NKN are similar to keys in Chord DHT (except that it’s connected to its predecessor rather than successor).

Although there are other topology that may lead to a more efficient routing path, our choice has a critical advantage such that each choice of neighbor can be verified by at least one other node. Suppose a node at address x should choose A as its i-th successor node. In this case, there are no nodes between address (x + 2^i) mod 2^m and A, and A should have known this information from its predecessor. Thus A knows that itself should be a neighbor of x. If node x does not choose A as a neighbor, A is able to falsify it. Similarly, if x chooses another node between A and (x + 2^(i+1)) mod 2^m in addition to A as neighbors, A should also be able to falsify it. Verifiability is crucial to an open network that may have a nontrivial portion of malicious nodes. It greatly reduces the possibility that malicious nodes choose specific neighbors to attack the system.

If you understand the principles of DDTN topology selection, then we can further introduce the DDTN routing technology. Given an established NKN network, routing can be achieved in a greedy algorithm using only information about neighbors. When a node wants to send or relay a packet to a destination address, it sends the packet to the neighbor that has the smallest distance to the destination address. The remaining distance becomes at most half of the previous value for each relay, thus decreases exponentially or faster as the packet is being relayed. Similar to Chord DHT, the expected number of hops is O(log(N)) given uniformly distributed addresses.

If the destination address is a client rather than a node, the above routing stops as long as the packet reaches the node connected to the client. The node then relays the packet to the client through the established connection.

The route between any two node pair is verifiable. Suppose a node sending a packet to destination address D should choose its neighbor A as the next hop while it actually chose neighbor B. From the routing rule we know that dist(A, D) < dist(B, D). Then A is able to falsify the route. If the node chose a non-neighbor node as the next hop, then such route can be falsified by the actual neighbor as discussed previously. The verifiability of routing is crucial to reduce the possibility of forming routes consisting of only malicious nodes. For a practical relay path validation algorithm, please refer to “Relay Path Validation” section.

In addition to network topology and routing, NKN must consider openness in order to build a network-based public blockchain. This requires a set of NKN protocols to define the behavior of the nodes/clients, such as node/client join, node/client exit, channel keepalive messages, network stabilization mechanisms, and so on.

Since NKN is an open network, it is inevitable that nodes will join and leave the network at any time, with or without prior notification. To efficiently maintain the NKN, each node locally maintains three lists:

1. Its successors and predecessors. At least one successor and one predecessor is needed, while keeping more nodes in the list enhances fault tolerance. (For specific principles, please refer to the NKN White Paper Ising Model Mathematical Proof and Simulation Results: https://www.nkn.org/doc/NKN_Whitepaper.pdf ).
2. Its neighbors.
3. Clients connected to it.

Nodes update these lists in response to topology changes. For efficiency, it is important that when a node or client join or leave the network, only a small portion of the other nodes (up to O(logN)) are updates. We have the following protocols that satisfy our goal in dynamic environments.

Proof of Relay (PoR)

One of the key problems in NKN is to prove how much data a node relayed, which we define as Proof of Relay (PoR). PoR is crucial to the NKN as the amount of data being relayed is directly related to token rewards. An ideal proof should satisfy the following conditions:

1. verifiable: anyone, involved in data transmission or not, is able to verify the proof correctly using only public information;
2. unforgeable: no party, unless controlled all involved nodes, is able to forge a valid proof with nontrivial probability;
3. untamperable: no party, unless controlled all involved nodes, is able to modify a valid proof with nontrivial probability.

Unlike Bitcoin and Ethereum mining, PoR is a useful proof of work: mining the data samples under transmission in an active channel. NKN achieve this by using a particular chain of signature. To improve efficiency, we use the hash of the chain to randomly select proofs in an uncontrollable but verifiable way. Moreover, we select a class of proofs that is proven to be hard to forge even for a large malicious party that has controlled a significant portion of all nodes in the network to be eligible for other benefits such as mining rewards.

One of the primary functions of the NKN is to transmit data. To be transparent to higher level applications, NKN works with network packets. Packet originates from source which can be either node or client, then relayed by relayers which can only be nodes, and finally arrives at destination which can be either node or client. The basic transmission unit in NKN is the NKN packet. The fields of a NKN packet are shown in Table 2.

As can be seen from Table 2, the signature chain is part of the NKN packet and is the part of the NKN packet that may be on chain. The signature chain is a signature chain that the relay node signs in turn when forwarding the NKN packet, as shown in Figure 6. Each element in the signature chain consists of the following fields: the NKN address and public key of the relay node, the NKN address of the next relay node, and the signature(signature of the previous element on chain, relayer NKN address, next relayer NKN address) signed with relayer private key.

As illustrated in Figure 6, the essential feature of a signature chain is its verifiability. A signature chain is valid if and only if for each element on chain, the following conditions are satisfied:

• The relayer NKN address matches the next relayer NKN address of the previous element.
• The signature field is valid.

Any modifications to a signed NKN packet except the payload will invalidate the signature chain unless re-signed. Thus, a signature chain is verifiable to anyone who has access to the NKN packet (no need for the payload). A malicious party cannot tamper with or forge a signature chain without having all the private keys along the route.

A NKN packet is valid if and only if the following conditions are satisfied:

1. Payload hash is correct.
2. Payload size is correct.
3. Signature chain is valid.
4. Source NKN address and public key match the first element of the signature chain.
5. Destination NKN address and public key match the last element of the signature chain.

So far, we have covered the NKN data packet, signature chain and its verifiable design. Now , it is time to introduce the NKN’s proof of relay (PoR) mechanism. As demonstrated in Figure 6, we use NKN packet with payload field removed as a proof of relay work for all relay nodes along the route. It satisfies our verifiable, unforgeable and untamperable requirements such that everyone is able to verify the validity of a signature chain, while no one can forge or modify a valid signature chain without controlling (have private keys) of all nodes in the route.

Signature chain cannot be forked because each element contains the NKN address and public key of the next node. If a node on the route is malicious and removes or modifies some previous elements on the chain when generating his signature, the chain is no longer valid. Similarly, If a partially signed signature chain is intercepted by a malicious party, no valid signature chain can be generated without the private key of the designated next node.

On the other hand, considering the need to put the PoR mechanism into practice, it is necessary to consider the efficiency. Therefore, every NKN packet has a proof which can be used as a receipt to generate transactions from source to relayers. However, it is inefficient to create a transaction for every packet transmitted in the NKN. Instead, only packets whose last signature on the signature chain is smaller than a threshold are eligible for transactions.

The last signature on the signature chain is verifiable to everyone, while still being unpredictable and uncontrollable unless all nodes along the route including source and destination are controlled by the same party. The last signature is essentially deterministic given the payload and the full path, but cannot be computed in advance without all the private keys along the route.

With an ideal hash function, the last signature on the signature chain is random across packets. Thus, selecting only packets with small enough last signature for transactions (with adjusted price per packet) does not change the expected rewards for relay nodes but introduced some variation in pricing and rewards. The threshold should be chosen to balance the need for less transactions and smaller reward variation.

As with all public blockchains facing complex open environments, NKN needs to ensure the security of PoR in the case of malicious attacks. Signature chain in NKN packet is unpredictable and uncontrollable as long as the private key of at least one node is kept secret. However, if a malicious party controls all nodes on the route including source and destination, the party is able to predict and create valid signature chain and NKN packet without actually transmitting the packet. To solve this problem, we differentiate two classes of signature chain. One class, which is mathematically shown to have trivial probability to be controlled by a party, can be used to gain more benefits such as mining rewards. The other class has no additional benefits so that nothing but economic loss can be gained by creating signature chains. For more details on PoR security, please refer to the NKN Github wiki page (https://github.com/nknorg/nkn/wiki) . This includes how to design secure paths, session-based data transfer modes, etc.

Consensus and Blockchain

NKN draws on the Cellular Automata (Ising model) to achieve a consensus to improve the scalability of the network. Mathematical proofs and simulation results for consensus between nodes using the majority voting cellular automaton (MVCA) algorithm were described in the NKN white paper (https://www.nkn.org/doc/NKN_Whitepaper.pdf). MVCA is efficient in both time and message count as only a few iterations of communications between neighbors are needed to reach consensus, as shown in the whitepaper.

Information required for consensus (e.g. next block) is sent to all participating nodes at the beginning of the consensus through a gossip-like protocol that takes up to O(logN) time, which is the main time cost for consensus process. Such time can be reduced to O(logN/logk) by having up to k times more neighbors similar to Kademlia DHT as we may implement in our future version.

The consensus algorithm can be implemented by an event-driven protocol triggered by consensus messages. Every consensus message has a topic id identifying what is being agreed on. For each consensus message received from a neighbor regarding a binary state (e.g. accept or reject a block), the following procedures are executed:

1. If it’s the first message with the topic id, then compute self initial state and send the state to neighbors.
2. Update sender’s state for the topic id.
3. If more than half of the nodes choosing self as neighbor have the other state from self state for the topic id, then change self state to the majority state and send the state to neighbors.

The consensus process for a topic id stops after a fixed amount of time since first receiving messages with the same topic id. The correctness and convergence of the MVCA algorithm is shown in our whitepaper.

The production process of the block in NKN is also very characteristic. New block is added to the blockchain by first selecting a “leader” that proposes the new block. The leader selection is uncontrollable but verifiable. The expected probability that a node is elected as leader is proportional to the data relayed by the node on secure paths. The selected leader proposes the next block and sends it to the network for confirmation. The proposed block will be added to the blockchain as the next block if consensus among nodes is reached.

A leader is selected by first selecting a signature chain on a secure path. The signature chain being selected is the one that has the lowest last signature value. As discussed before, signature cannot be predicted or forged until a malicious party has controlled all nodes in the chain. On the other hand, any malicious party has a very low probability to control all nodes on a secure path. These two properties combined guarantees that selecting the signature chain with lowest last signature on secure paths is effectively randomly selecting signature chain on secure paths and the selection cannot be predicted or controlled by any party.

To select the signature chain with lowest last signature, each node who signs the last signature checks if the last signature is smaller than a threshold. If the last signature is smaller than the threshold, the node sends out the signature chain to the network as a candidate for the lowest last signature. The threshold is chosen so that with high probability, the lowest last signature is smaller than the threshold. Let t be the threshold in unit of largest possible signature value, and the signature is distributed uniformly from 0 to the largest value. The probability that all last signature are above the threshold is (1 — t)^L, where L is the number of signature chain. We need (1 — t)^L < e where e is small enough. For small t we have t > — (log e) / L. We choose t = — (log e) / L to minimize the number of candidates. L can be estimated from the average number of signature chains in a number of previous blocks.

Nodes reach consensus about signature chain selection after receiving candidates. The initial choice of each node is the signature chain candidate with lowest last signature. If all nodes receive the same candidates, then consensus is trivial as all honest nodes will make the same initial choice. Otherwise the same signature chain (but not necessarily the one with global lowest signature if initially it is not received by enough nodes) will be guaranteed by the consensus protocol.

When consensus about the signature chain is reached, leader is chosen deterministic from the signature chain. Let S be the last signature of the signature chain. Relay nodes on the signature chain are labeled from 0 to L-1, where L is the number of relay nodes. Then the leader is the node with label S mod L on the signature chain.

Finally, a block is proposed by the selected leader in each round. Proposed block is sent to all nodes for verification and consensus. During consensus phase, each node sends to its neighbors the hash of the block (in case the leader sends out different blocks to different neighbors) and if it is accepted or not. When consensus is reached, all nodes should have the same accepted block or none if rejected. Proposed block is added to the blockchain if accepted.

Relay Path Validation (RPV)

Although signatures in a signature chain guarantee that it is signed by the claimed relayers, they do not guarantee the correctness of the relay path, where a path is defined as correct if it is the designated path of our distributed data transmission network (DDTN). Being able to validate the correctness of a path is crucial for the security of signature chains, otherwise attackers could break the assumption that each hop leads to a random node by selecting specific node as next hop, and a malicious party could construct signature chains fully under control by relaying packets only to nodes under control. Signature chain fully controlled by a party is no longer unpredictable by the party, and can be computed by the party without actually transmitting any data. The malicious party can then gain unfair economic advantage by producing more signature chains than it should, increasing its chance to get mining rewards.

The validity of any relay path should be consensus among all nodes as it is a prerequisite to select globally unique mining node for each block. There are two ways to achieve the consensus: 1. nodes use global information (e.g. previous blocks) that has already be agreed on; 2. nodes use their own local information, and reach consensus later. We choose the first approach as it does not require extra communication between nodes and is much more efficient. The disadvantage of such approach is that global information has time delay so that the topology may be different from the time when past consensus was reached. We consider this to be acceptable as long as the valid path is unique or almost unique, and the valid path still exists and will be selected by honest nodes with nontrivial probability at the time of validation.

To validate a path, we validate if each node on the route is relaying the packet to its neighbor that is closest to the destination address, considering only nodes that appeared in the last X blocks, where X is configurable. To be more specific, at each hop, let the node NKN address be x, the virtual ring can be separated into m segments, where segment i contains nodes whose NKN address is between (x + 2^i) mod 2^m (inclusive) and (x + 2^(i+1)) mod 2^m (exclusive). If there are any nodes within segment i, then the node in segment i that is closest to x will be a neighbor of node x. Similarly, if the destination NKN address is located in segment i, then the node in segment i that is closest to x should be the next hop which x should send the packet to. In practice, each node validating the path will check:

1. The next hop is indeed in segment i
2. No node that appeared in the last X blocks is in segment i and is closer to x than the next hop.

A hop is valid if it satisfies these two conditions. A path is valid if every hop is valid. Since the validation only utilizes information in the signature chain and data in previous blocks, every node in the NKN that receives the signature chain and has previous blocks information will produce the same output, ensuring the consistency of validation.

A consequence of the above validation algorithm is that, if any hop in a path should select a node which appeared in the last X blocks but is now offline, then the actual hop will skip that node and select its immediate successor instead, make the path invalid. This cannot be avoided unless information other than previous blocks is used (e.g. ping the skipped node to see if it’s indeed offline). We argue that this false negative is acceptable because it can be viewed as another random factor that rejects a portion of honest signature chain, similar to the role of the hash of the signature chain. The probability that an actual valid path is identified as valid can be computed as p = (1 — N_off / N)^l, where N_off is the number of nodes that appear in the last X blocks and then go offline when the packet is being relayed, N is the total number of nodes in the network, and l the length of the path. One can choose smaller X or making nodes more stable to reduce N_off and increase the validation rate.

Verifiable Random Function (VRF)

The signature in signature chain needs to satisfy the following conditions:

1. Only the secret key holder can produce valid signature, no one else can compute valid signature of a message without knowing the secret key, even if knowing the valid signatures of other messages;
2. The signature of any message should be unique, i.e. only one signature is valid for any message and key pair.

The first property (verifiability) guarantees the signature is indeed signed by the secret key holder, while the second property (uniqueness) prevents relayers from computing multiple signatures for the same message and choose the one that has largest advantage (e.g. smallest signature).

Although elliptic curved based digital signature algorithms (e.g. ECDSA) provide verifiability, they do not produce unique valid output for the same input message. A random nonce can be chosen freely to produce multiple valid signatures, and validator does not know or verify what nonce is chosen. Even in some deterministic versions of ECDSA where the random nonce is chosen deterministically (e.g. hash of the message), malicious node can still choose different nonce and produces multiple valid signatures for the same message, while the validator cannot know if the nonce is chosen in the specified way. In contrast, hash function provides uniqueness but not verifiability as anyone can compute the output.

We use verifiable random function (VRF) to compute the “signature” in signature chain as it provides both verifiability and uniqueness. In addition to the output (signature) of the message, it also produces a proof which is needed to verify the signature. Similar to signature algorithms, valid signature can only be computed if the secret key is known. Unlike ECDSA, only one signature is valid for any message in verifiable random function, although the proof may not be unique.

NKN Address Scheme

Nodes and clients have different scheme when choosing NKN address.

First, it is important that NKN address of a node is random (or at least uniformly distributed and uncontrollable) for two reasons.

1) It is hard for malicious nodes to choose specific NKN addresses. Being able to choose NKN address makes it easier for malicious nodes to attack the system as neighbors and routing are based on NKN addresses.

2) Load is more balanced among nodes given random NKN addresses, effectively making the network more decentralized.

To guarantee the randomness of NKN address and prevent malicious nodes from choosing specific NKN address, a unique, unpredictable, uncontrollable yet still verifiable function is used to generate NKN address when a node joins NKN. We choose the hash of public IP address and latest block hash at the time of node joining
 
Node NKN address = hash(Node public IP address, latest block hash)
 
 such that it’s verifiable by other nodes but unpredictable in advance.

Second, clients have different NKN address scheme from nodes. The scheme should satisfy the following properties:
 
 1) Client NKN address is permanent such that a client can be reached from the same NKN address when in different physical network.
 2) Client NKN address is associated with its public key to avoid NKN address collision so that other clients cannot receive packets sending to it.

NKN chooses the scheme such that client NKN address is computed from a url-like NKN address string consisting of an arbitrary string chosen by the client and its public key
 
Client NKN address = hash(“arbitrary-string.client-public-key”)
 
 In the NKN address string, the last substring separated by a dot (client public key) represents the unique identity of the client, similar to root domain in a url; the rest is chosen by the client, similar to subdomain in a url. Such a scheme satisfies the above two properties. In addition, a user (key pair holder) can generate as many NKN addresses as he wants sharing the same account (key pair).
 
 Clients do not distribute their NKN addresses directly. Instead, a client distributes its NKN address string to nodes or other clients and they compute the client’s NKN address locally such that they know both the client’s NKN address and public key at the same time. Using such a scheme, end-to-end encryption between any clients is easy to implement.

Mining Economic Model

The total number of NKN tokens (nkn) is one billion. When the mainnet goes alive, the genesis block will generate 70% nkn. The remaining 30% will be produced by mining data transmission, and the annual output will decrease linearly within 25 years, as shown in Figure 7. The annual supply (in millions) of NKN tokens (Q) is distributed according to the time variable “T” and is excavated according to the following formula:

Because the total amount of NKN tokens is limited and mining production decreases linearly over time. This part of the mining mechanism for issuing tokens is to encourage the community to participate in the co-construction and sharing of the new Internet. The cost of NKN token is determined by the bid between the customer and the miner (similar to the Ethereum system fee); therefore, the market price change of the NKN token does not affect the equivalent price of the data transfer transaction or data transfer fee.

Building an Ecosystem

The NKN ecosystem has three main goals:

1. Ultra open. Any device can easily access NKN whenever and wherever.
2. Share network resources. Participants receive rewards from the NKN system by sharing idle network resources with others.
3. Building network facilities together. NKN encourages individuals and organizations to deploy devices to serve other nodes and benefit from automatic settlement while enhancing network connectivity and throughput.

Therefore, the NKN ecosystem has four main elements: network equipment/device, network infrastructure, Internet service providers, and decentralized applications, as shown in Figure 8.

In transforming traditional network infrastructure, NKN focuses on its own blockchain technology advantages and cooperation with traditional telecommunications and the Internet service providers. Recently, NKN joined the TIP (Telecom Infra Project) , a telecommunications alliance founded by Facebook, Deutsche Telekom, Intel, Telefonica, Nokia, Vodafone and BT. NKN will play a key role in the working groups such as Edge Computing Group, OpenCellular Group and TIP Community Labs. NKN’s innovative economic incentive model combined with blockchain in the field of network transport will enable members of the TIP Alliance to embrace technology innovation more quickly and broadly.

In addition, NKN is also a member of the ONF(Open Networking Foundation). ONF is a non-profit organization of telecom industry giants such as AT&T, Google, Comcast, Deutsche Telekom, NTT and Turkey Telecom, which aims to introduce open source innovation into formal commercial deployment. One of the organization’s most important tasks is the research and exploration of new business models and application scenarios of SDN (Software Defined Network), which coincides with NKN’s innovative model of combining SDN and blockchain. NKN will focus on the following projects of ONF: SDN, ONOS, CORD, P4/Stratum, and other major related projects.

Technical Roadmap

Figure 9 demonstrates the latest NKN development roadmap (updated at https://nkn.org/), which can be divided into two phases: testnet and mainnet. We will be able to provide a full-featured testnet before January 2019. An early version of the NKN mainnet will be released in March 2019 and will be officially launched in June next year, which is three months ahead of the previous plan.

As shown in Figure 9, the new roadmap started in May 2018. The main task of this phase was to develop the Testnet preview of Decentralized Data Transmission Network (DDTN), Proof of Relay (PoR), and Cellular Automata Consensus subsystems, including:

• Implemented and released the first version of NKN JavaScript client
• Implemented decentralized data transmission network base on Chord DHT
• Implemented proof of relay using signature chain
• Implemented the first version of cellular automata based consensus algorithm
• Redesign and unify REST/RPC/Websocket api
• Improve building flow and add Docker support
• Many other improvements and bug fix

Now NKN is in the development phase of the testnet, and released the v0.1 version testnet, “Firefox” on June 16, 2018. This is the first testnet that contains all of the core subsystems, enabling the globally deployed nodes to work and test in real time. The main tasks at this stage are:

• Release the design and preliminary implementation of distributed data transmission network based on Chord DHT;
• Release the design and initial implementation of Proof of Relay (PoR);
• Release the design and initial implementation of the decentralized public ledger based on PoR and CA consensus algorithm;
• Launch a prototype blockchain system with data transmission capacity and PoR;
• 15 node testnet deployed in 15 regions globally;
• Develop clients with graphical user interface (GUI) to provide network connectivity and user interaction;
• Preview of SDK for dAPP experiments.

The next stage is the release of the v0.3 version of the testnet in August 2018, “Lemur”: Optimizing system scalability and efficiency, the alpha version of the SDK. The main tasks at this stage are:

• Optimize NKN system design to improve scalability and efficiency;
• Further develop and improve NKN core system;
• Develop public protocols and interfaces of NKN for other applications including decentralized applications (dApps).

In October 2018, NKN will release the v0.5 testnet, “Koala”: enhanced anti-attack capability, a larger scope of testnet, and SDK Beta version. The main tasks at this stage are:

• Introduce anti-attack mechanism to prevent malicious party and collusion attacks;
• Build test network with hundreds of nodes for testing and demonstration.

In January 2019, NKN will release version 0.7 testnet, “Meerkat”: full-featured test network, complete implementation and performance, and SDK version 1.0. The main task of this phase is to introduce a fully functional NKN testnet, including fault tolerance, data transmission and routing, relay path verification, and a complete implementation of the consensus algorithm. This consensus algorithm will enable fast convergence in large-scale networks.

In March 2019, NKN announced the release of the v0.9 of the mainnet at the end of the testnet phase, “Beluga”. The main tasks of this phase include:

• Further develop and improve NKN core system based on status of the testnet;
• Develop network-intensive dApps based on NKN ecosystem.

Finally, in June 2019, NKN will officially release the v1.0 of the mainnet, “Narwhal”, which mainly includes:

• Launch NKN mainnet;
• Launch NKN ecosystem.

Conclusion

NKN is a public blockchain and a common network layer infrastructure that provides next-generation network technology to other areas. This is a strategic exploration and innovation that uses blockchain technology to change the Internet. A highly reliable, secure and decentralized Internet is critical to us so that every individual and every industry can reach its full potential in the digital world. NKN will provide tremendous potential for a fully decentralized peer-to-peer system to make the Internet more efficient, sustainable and secure. At present, the Internet has many shortcomings in terms of network neutrality, resource utilization, and excessive reliance on central control. Now it is the time to rebuild the new Internet we always wanted. NKN will empower the blockchain technology to reshape the future of the Internet, let us wait and see.

About NKN

Home: https://nkn.org/

Testnet Preview: http://preview.nkn.org/

Email: contact@nkn.org

Telegram: https://t.me/nknorg

Reddit: https://www.reddit.com/r/nknblockchain/

Twitter: https://twitter.com/NKN_ORG

Medium: https://medium.com/nknetwork

Github: https://github.com/nknorg