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:

Payload hash is correct. Payload size is correct. Signature chain is valid. Source NKN address and public key match the first element of the signature chain. 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:

If it’s the first message with the topic id, then compute self initial state and send the state to neighbors. Update sender’s state for the topic id. 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:

The next hop is indeed in segment i 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:

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; 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.

Figure 7 nkn annual mining amount supply curves versus time

Building an Ecosystem

The NKN ecosystem has three main goals:

Ultra open. Any device can easily access NKN whenever and wherever. Share network resources. Participants receive rewards from the NKN system by sharing idle network resources with others. 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.

Figure 8 NKN ecosystem elements and the value of NKN

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.

Figure 9 NKN technology roadmap

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