Core Graphene Issues Uncovered by the Karma Team

Dear friends,

In summer 2017, Karma development team decided to create its own blockchain, based on the Graphene fork. We've compared several public blockchains existed at the time, and Graphene suited us best:

• 100,000 transactions per second against 20–30 for Ethereum and 7 for Bitcoin.
• 0.01 USD per transaction against 1 USD in ETH and 10 with BTC.
• Less security problems at the application level. 34,500 Solidity smart contracts (Ethereum) have critical vulnerabilities. While in Graphene you can build an app using the most tested and the fastest C++ language.
• Graphene is still the most popular blockchain in the world in terms of the number of signed transactions. Thanks to the Bitshares, Steemit and Golos.

However, the more we've drilled down the Graphene core source code, the more we've understood why Dan Larimer left the project and completely switched to EOS. Here are some main issues we've found:

Using the FC Library

1. The implementation of the FC library in the Graphene code looks extremely raw;
2. The redundant override of the boost::thread is used to implement task queues;
3. A singleton model is used to organize the main queue, which, in all likelihood, leads to mutual locks and idle tasks in the queue;
4. It can be concluded that inefficient use is not related only to the boost code, but also to the hardware. Overhead computation takes place where it could be avoided;
5. The problem can be solved by completely rewriting the task queue maintenance layer. For example, removing dynamic multithreading and replacing it with thread pools that serve a limited set of queues: requests, database read/write, blocks closing. So you can get a performance increase on the node from 20 to 100%;

Using boost::multi_index to implement memory objects storage

1. Realization of a proprietary DB;
2. The in-memory approach itself does not a problem, but the implementation based on revision management synchronization, i.e. the data sync takes place periodically: by creating a number, copying data and writing it to the disk. However, the data is stored in raw format;
3. Multi-indexes are also saved to the disk, which can lead to the saving of the state at the time of locking. And then when the node is restored from the last stored database, a “hang-up” situation is possible. If you imagine that when the request is made on behalf of the node wallet, the data will be “cleared” and the node falls at the same time, then recovery from the data will be impossible. Also, it will be impossible to close the block with this node and completely roll back the last chain sate, since you’ll have to copy the whole blockchain again. And if the node was included in the consensus, the wallet of the nondeholder loses its “privilege”.

Limit of 20–30 Master Nodes

1. Graphene is designed to support a maximum of a couple of dozen master nodes per unit of time.
2. This creates opportunities for corrupting delegates.
3. Moreover, there's proxy registrar tool in Graphene, and that leads to the power concentration, so 5–7 people can manage the entire ecosystem (as it turned out in Bitshares). It's better than 2 in Ether and 3 in Bitcoin, but still not enough.

Conclusions

All of these problems can be tolerated, but not for too long :)

Completely cutting out the fc library is quite difficult, as it is easier to completely rewrite the code. But the fc is used in all Graphene libraries. Having a wrapper over wrapper over not-so-fast boost:asio for p2p, instead of using libuv or libevent is also not the most optimal choice.

Using the proprietary hard drive database is also a very controversial solution, although it can be completely replaced as the interface is transparent. It can be replaced with leveldb or rocksdb, for example.

In general, we can conclude that Graphene was a very good prototype, showing that the dPOS consensus could work. But, in the end, it was more of an experiment, than a production solution. In addition, the transparency and documentation of the code does not reach the level of an enterprise framework.

We truly admire the Dan Larimer's talent and his huge contribution to the blockchain industry. So, we wish him a good luck with EOS blockchain development.

Cheers
ˆ_ˆ