Blockchain audit for Dispatch Protocol – look how we did it!
Last weeks of 2018 brought some exciting news for us - after 1,5 months we have finished one of the most interesting blockchain audit we've ever conducted. I'm talking here about Dispatch Labs and their Dispatch Protocol based on completely innovative DAPoS consensus mechanism and probably one of the most interesting application of blockchain technology. Wanna hear more? Let's dive in!
Team from Dispatch came up with a very interesting idea of harvesting the power of blockchain for data storing, exchanging and of course – selling (without that feature it would be needless to use blockchain anyways – as way too many projects currently do). The idea itself doesn’t define whether it should work more like a cloud service, hosting or paid P2P network – you could store your personal data and just pay for the storage you use by yourself or share these files with other people on the Internet with a fee defined by you. Such an approach gives the network wide possibilities of future development, depending on the current situation of network storage services.
What blows our mind is that their team designed a completely new consensus mechanism, called DAPoS (delegated asynchronous proof of stake) for higher network efficiency. As we all know Proof of Work is less efficient than a bunch of kids in kindergarten drawing random illustrations trying to blind-copy Da Vinci’s “Mona Lisa” so this mechanism wouldn’t really work out. Proof of Stake is far more effective but if we’re supposed to store files, often heavy ones, why not rearrange the whole algorhythm? So did the Dispatch team, creating a network of Stakeholders, Delegates, Farmers and Bookkeepers. Sounds brave and it really is – you can read all the technical details in their whitepaper.
Secondly, the network isn’t really based on blocks as most block-chains. In order to increase network throughput, Dispatch team decided to change mining blocks to gossiping the transactions between nodes. It is a nodes’ responsibility to arrange all of them in the correct order based on each transactions timestamp and signature. So technically we shouldn’t talk about blockchain audit but we will for the sake of clarity 🙂
What the audit was all about?
Our job was to audit their current code before the Main Network going live. Their main application is based on Ethereum client (Golang version) although most of it is redesigned and updated with new features. We’ve conduceted an exhaustive check of their HTTP and gRPC API used for internal nodes communication. Further, we have tested backward compatibility with Ethereum smart contracts and bytecode compiler. There weren’t many exciting bugs there, although we have suggested their team some small changes and fixes that would secure the network from possible DoS attacks.
These are usually the ugliest and hard to find, you really need to secure your app from receiving too many requests in each possible way – if not, even the most basic query in big numbers may hang your network. For that we used a more sophisticated way with modified code for a node (if the code is widely available, you could modify it to corrupt the blockchain, right?) and a simpler one – loadtest tool:
loadtest -n 1000 -c 10000 http://[host address]:3506/v1/transactions?page=1
The most interesting part was testing double-spending attack (the Holy Grail of every blockchain audit) and possible network overtake. There were many scenarios for such a hack but neither a malicious node propagating modified transactios, nor separating 49% of the network worked out. Unfortunately one of the RPC methods for internal communication lacked some validation so it was possible to bloat the network with a modified malicious node. We also managed to poison the Kademlia DHT entries responsible for storing nodes adresses which, in specific situation, could lead to a network shutdown. Fixes were suggested and as far as we’re concerned this isn’t a threat anymore.
If you’re working on your own blockchain remember that Proof of Stake isn’t always the best solution. Of course it’s useful to base your mechanism on something that is widely known and adopted but boy, don’t hold down your creativity! Also remember about the following things:
- Create validation schemes for external and internal communication between nodes. You can use this simple cheat sheet from OWASP.
- Always test your application against DoS attacks, even a simple loadtest tool may prove useful.
- If the DoS seems to block your network you need to work out a queuing mechnism!
Summing up, we were extremely happy to be given this opportunity to conduct such a vast blockchain audit with a completely new consensus algorhythm. It was an exciting project which we’ve put a lot of work into and I guess we did a really good job receiving great testimonial from Zane Witherspoon, Dispatch Labs’ CTO.