NKN Code Review: Decentralized Internet
Share this article
Here goes with the NKN code review for the “New Kind of Network” connectivity protocol & ecosystem powered by blockchain for an open, decentralized, and shared Internet. But what is wrong with the precious Internet that we have now?
I like to start off a review by understanding what they are trying to achieve. So I’m heading over to the whitepaper. See you on the other side!
… MATH!
- Cellular Automata — referenced 7 billion times in the Whitepaper. My basic understanding of it is; a model where you have a ‘Network’ of ‘Cells’. Each Cell has the same ‘Rules’ defined as all the other Cells in the Network. Each Cell has their own ‘State’. A specific Cell’s State can only be updated using the Rules defined, the knowledge of the Cell’s state and the State of its neighbouring Cells. This will be the basis of their Distributed Network.
- Proof of Relay (Improved PoW) — a reward system based on their network usage vs. their network contribution. The more bandwidth you provide and the less you use, the better your rewards.
- Networking Toolkit for DApp developers — tools to help DApp developers by providing a decentralised network platform.
Those are my main takeaways from the whitepaper. Let’s see if we can find what NKN are doing to achieve those goals.
7 repositories. Let’s dig in! I’m going to kick things off at the bottom of the repo. Fortunetree.
This is a front end for a forum, built on vue.js. It has a wallet route in it. That’s about the only thing that caught my eye that is not a standard forum layout. Standard front end structure with a store, components, routers, etc. — good, but I don’t see the relevance of the repo. So I am going to move on.
keytransparency — forked from Google to get p256 functionality. Skip!
vxeddsa — forked from Scratch-net to get more cryptography functionality.
coniks-go — forked from Coniks-sys. Still nothing that is worth reviewing.
Nice test tool to simulate their consensus and cellular automata theories. The results are described in the README.md files for each simulation. The result of the consensus simulation is what is described in the whitepaper under the section 5.2.7 Simulations of CA Consensus Algorithm.
consensus.py -> Neat little python script to simulate the model. Nice documentation.
There is very little happening in here in nkn-client-js, so not much to say. It creates a NKN client which sends an RPC call to get the webserver address and then listens on the returned web socket for a couple of basic events. It’s just a prototype to test some functionality, so not worth going in to.
Very nice! A detailed README.md with more information in the Wiki! Build instructions, deployment instructions, even a style guide for coders. I’ve never actually read this much documentation in my life. I’m more of a get to coding and read up if/when I get stuck. But this project has me intrigued.
A quick click through of the repo shows that are almost no unit tests written for this yet. Not great, but it’s probably still a prototypical project. It’s best to write tests during the dev cycle though.
From reading the documentation, there should be a couple of subsystems that are maintained in here. They each run independently of each other, but combine to form the full ecosystem.
Distributed Data Transmission Network
Proof of Relay
Blockchain Consensus
I’m going to hop into the consensus folder. 2 kinds of consensus? dbft and ising.
- Dbft (Delegated Byzantine Fault Tolerance). The code has very limited comments. It’s a service that subscribes to consensus events. On new message received, it does the verification of the transaction.
- Ising is the consensus algorithm that is based on the model described in the whitepaper. It’s a service that listens for consensus events, verifies the sender and prepares the response message to be sent. It has a voting mechanism for SigChains and blocks. The voting only considers the neighbouring nodes and current node.
relay -> a service that subscribes to relay events. Basically it just passes packets on to the next destination address in the chain. Calls the Proof of Relay Service to sign the packet to prove that it relayed it then moves it on. The Proof of Relay Service. Verifies SigChains that are passed to it then adds its signature, using the local wallet to the SigChains to prove relay occurred.
Good error handling, a couple of TODOs, but the code is well written.
core->the actual functionality to handle validation of different signatures, signing data, transaction object for creating and processing different types of transactions. Ledger functionality for handling blocks and bookkeepers.
net->there is code here to emit a couple of different types of messages. Consensus payloads, blocks, transactions. There is relay functionality, heartbeat/ping neighbour status updates, management of neighbour nodes and syncing blocks from neighbours. They are using Chord Distributed Hash Table for their network topology to identify nodes on the network. The net code is clean and well separated. I like!
db -> LedgerStore, ChainStore, PersistBlock handler, Transaction Store, Block Store, Voting. All maintained in one file. I would like to see this stripped out into smaller pieces. Everything is stored in a leveldb. They are using a UTXO model for transactions.
rpc -> they have a JsonRPC API and RESTful API. The RPC calls are used in their CLI tool. It’s nice that they added both JsonRPC and REST options, but not really necessary. Perhaps for their developer toolkit eventually?
websocket -> standard webservice to handle events passed to it. A lot of the same functionality that the RPC and REST interfaces contain, with some new, some removed.
They have a cli tool for management, a vm to run certain processes, a wallet used for local signing and account. And that’s about all I’m going to go through.
NKN definitely have the building blocks in place for their Distributed Network. Nodes can discover each other, transmit packets and come to consensus. In terms of the actual performance of the network, only time will tell.
Their Proof of Relay system — they are signing packets and adding it to the signature chain in a verifiable way when nodes relay them. I didn’t find anything around reward distribution, which is fundamental to adoption, but not necessary for their POC.
I didn’t see much around their networking toolkit for developers, which is scheduled to be alpha released in August. I don’t know what their full plan is, but that should just be wrapping up the existing functionality into a clean package and documenting it. I’m not too worried about that.
NKN Code Review Conclusion
NKN has come into the game with an exciting angle. They aren’t looking to re-create and improve on existing platforms. Instead, they are looking to define a new leg of decentralization, a New Kind of Network. Their goals are backed by theoretical models which, based on my basic understanding, make sense.
The code isn’t quite production ready, with lots of TODOs, FIXMEs and comments of “add this later”, but that is fine for a work in progress. I’m disappointed by the lack of unit tests written and inline comments. That said, it doesn’t mean their code doesn’t work. They released their first leg of their alpha testnet ahead of schedule so something is definitely going right in the camp. With optimizations and the alpha release of their SDK coming out in August, this project definitely has potential.
Disclaimer: Crypto Briefing code reviews are performed by auditing what is on display in the master branch of the repo’s made available. This was performed as an educational review and any comments in the article are the opinion of the writer. It is normal for code to change rapidly, hence we timestamp our code reviews so that they present a snapshot at a moment in time. Information contained herein should not be used as any comment or advice on the project as a whole.
NKN Code Review Timestamp: June 2018
Share this article
