The source code is the basis for all blockchain technologies. With poor code, it might be even dangerous to use DLT systems. That is why we, the Institute for Crypto Asset Analysis, analyzed the Dash codebase with an innovative and new method. We used a specialized algorithm to determine the quality of the code and to detect errors. In our analysis, Dash revealed a stable codebase across most components with sustainable improvements in the number of code issues compared to its past code quality. — Authors: Benjamin Horvath, Christian Flasshoff, Philipp Sandner
The Institute for Crypto Asset Analysis (ICAA) analyzes the underlying codebase (e.g., C++, Java) of cryptocurrencies and other DLT solutions. An automated algorithm determines a score about the quality of the code, that is easy to understand, and that makes DLT solutions comparable to each other. In the case of Dash, we analyzed over 84,000 lines of code and identified issues in less than 600 lines of code. In most cases, the problems were minor and not critical, but there are also sections of the code, which require improvements by developers. ICAA aims to provide an innovative approach of reviewing the code of cryptocurrencies to help investors, analysts and other blockchain enthusiasts in the decision-making process. Before we come to the details of the analysis of Dash, let us take a look at the blockchain technology itself. For everyone who is familiar with the concept of Dash, feel free to skip this section and continue reading in the next part.
The technology behind Dash
Launched in 2014, Dash was initially known as “XCoin” or “Darkcoin” and was designed with its prime focus to ensure user privacy. In fact, the cryptocurrency’s whitepaper, co-authored by Evan Duffield and Daniel Diaz, describes it as “the first privacy-centric cryptographic currency” based on Nakamoto’s work. While it still features strong encryption functions, Dash has since recast its ambitions. The cryptocurrency now aims to become a medium for daily transactions — “Dash is Digital Cash you can spend anywhere”, its website proclaims.
In comparison to Bitcoin, Dash uses a different system for handling transactions: The Bitcoin blockchain needs to be validated by all nodes within a network. While this process ensures consensus without authority, it requires substantial investments in infrastructure for full nodes or nodes dedicated to mining. As recent events have indicated, the process is time- and energy-consuming and fails to prevent clogging, as slow processing results in a backlog of transactions within bitcoin’s memory pool. In turn, this can lead to high transaction fees and make bitcoin unsuitable as a cryptocurrency for daily transactions. In contrast, Dash decided to use economic incentives as a starting point by instituting a system of “Masternodes”. Masternodes are essentially full nodes with a starting stake of 1,000 Dash in their systems — “This allows the users to pay for the services and to earn a return on their investment”, according to their whitepaper. Holders of Masternodes are responsible for approving transactions from the miner network and providing extra services to the Dash network, such as “InstantSend” (transaction within seconds) or “PrivateSend” (private transactions). Bitcoin and Dash are mostly based on a Proof of Work (PoW) algorithm, a concept where a person can mine or authenticate block transactions in a blockchain ecosystem according to the computational power they own. Dash’s services InstantSend and PrivateSend a more similar to a Proof of Stake algorithm, a concept where a person can mine or validate block transactions according to how many coins they hold (in this case owners of Masternodes).
Finally, another innovation within Dash’s ecosystem lies in its governance model. In contrast to cryptocurrencies with similar aspirations, such as Bitcoin or Litecoin, Dash did not grow out of an academic institution. Instead, Dash has pioneered a self-funding model by splitting block rewards between three stakeholders — Masternodes, miners, and treasury. The first two get a 45% share each. The remaining 10% share accruing to the treasury is used to finance future development projects at Dash. Masternodes play an important role here as well: their votes determine future development directions for the cryptocurrency.
Review of the Dash codebase
Dash is equipped with peer-to-peer payment features, which are defined in the codebase of Dash. The Dash software is based on the Bitcoin protocol and is distributed across the network. The software functions as a backbone of the cryptocurrency project, which depends on the quality and security of the codebase. Analyzing the codebase of Dash helps to unveil code issues and to ensure the long-term success of the technology. We used an innovative and new approach to examine the quality of the code. With the help of software, we automatically analyzed the C++ codebase of Dash and determined the quality of the code. Since the Dash code is published under the permissive free MIT software license, the codebase is easily accessible on GitHub.
The specialized algorithms of the system automatically define a score for cryptocurrencies on a scale from -5 (worst score) to +5 (best score). This classification makes it easy to interpret the results and to compare it to other blockchain solutions. Technical remark: Our analysis is based on the Dash code version from 2018–06–24 and draws comparisons to an earlier release from 2018–02–16.
Analysis: Dash scores a solid 2.18 on a [-5,+5] scale
At this point, it is interesting to know, which score was reached by the Dash code. The cryptocurrency scores a solid 2.18 with potential for further improvements. To classify this result, the second largest cryptocurrency, Ethereum, scores only 1.69 and is ranked clearly behind Dash. In the following, we will examine the reasons behind this result and break down the score into four categories: design, metrics, duplications and code issues. Every group is represented by an individual score, which allows to narrow down the problems to the components of the codebase or even the exact lines of code. Figure 2 visualizes all of the subcategories of the Dash version from 2018–06–24. In the following, each category is explained in detail, and the results will be interpreted. As always, this part might be a little bit more technical but still plausible for non-coders.
Design issues. In this category, the codebase is analyzed regarding the design of the code. Good code design is characterized by an easy to follow and efficient structure. Even though the functionality of software with well-designed code or less well-designed code might be the same, it is desirable to develop code that every programmer understands easily. The quality of code design can be analyzed automatically with the help of algorithms and includes the detection of anti-patterns. Anti-patterns are sections of code that appears to work but are not optimally constructed. The patterns usually arise over time when new functionalities are added or when changing developers contribute to the code. Anti-patterns may result in errors and make maintenance of the code very difficult. There are several types of anti-patterns. One example is a ‘local breakable’, a component that has many direct outgoing dependencies. Such a component carries excessive responsibility and is typically identified by many long methods. It represents too many local outgoing dependencies, in contrast to a ‘local butterfly, a component that has many direct incoming dependencies. If any of the dependent components fail, local breakables are likely to fail as well. There are also several other anti-patterns but explaining all of them would be beyond the scope of this article. More important are the results of the design analysis. The Dash code has a total number of 457 anti-patterns in over 89.000 lines of code. Only 92 issues are classified as “high”, which relativizes the number of issues. The evaluation of the design issues concludes with a score of 2.42. Figure 3 shows an example of anti-patterns within the “serialize.h” component. It is also important to mention that the score increased compared to an earlier version of the Dash code. The 2018–02–16 snapshot of the codebase shows around 300 anti-patterns and rates with a score of 2.06 in the design category. We can, therefore, conclude that the Dash codebase improved regarding design quality over the last developments.
Metric violations. The next category tracks the quality of the code with software metrics. Such a parameter is for example “number of methods” (NOM). This metric counts the total number of methods (functions) in one class. It is obvious that a higher number of methods makes the code more complex and increases the risk for errors. Other metrics are for example “lack of cohesion in methods” (LCOM), which measures the cohesiveness of a class or “access to foreign data” (ATFD), which measures the frequency of access to external attributes from other classes. To determine the quality of the code, the system we used reports when an undesirable threshold of a metric is exceeded and calculates a score for metric violations. The Dash code shows a total number of 1,826 metric violations, with the most violations in the category LCOM (more than 600). Altogether, the metric violations can be translated into a score of 0.82. Compared to an earlier release of the Dash code (2018–02–16) with a metric score of 0.85, the quality of the code slightly decreased between the two versions.
Duplications of code. As the name already implies, the category duplications search for duplicated code. Duplicated code is usually undesirable, since it may increase the lines of code, lowers the performance or increases software vulnerability. The Dash codebase shows a desirable score of 3.56 and only 2.73% of the code is duplicated. Compared to an earlier release of the Dash code (2018–02–16) with a duplication rate of 2.72%, the score almost remained the same.
Code issues. The last category focuses on code issues. In contrast to design issues, code issues apply only to a local part of the code. Depending on the characteristics of the problem, the impacts on the performance of the software may vary. Therefore, it is essential to classify the implications of the detected code issues. The innovative algorithm defines the criticality within the categories of low, medium, high and critical. The result of the Dash codebase in this category unveils 534 code issues. Even though this number is higher compared to the snapshot of the Dash code from earlier (2018–02–16) with 399 issues, the overall code issue score massively increased from -0.25 to 4.07. This result can be explained by the change of distribution of the code issues within the Dash code. Almost 50% of the problems in the category “medium” got resolved, 25% in the category “critical” and 10% in the category “high”. The majority of these issues is located in the “server.h” component, with a total number of 34 code issues. Figure 4 represents an example of the code issue in this component (line 1634). It flags a potential inconsistency in the code in regards to the use of an erase() function. The remaining code issues (76%) are classified as low. An example of a low code issue would be an unused label within the code. Such an unused label does not interfere with the correct functionality of the software but could be removed to make the code more compact. Software with fewer code issues tends to run more stable and should be the goal of every programmer. The occurrence of code issues is common in computer programming and is part of the development process. Nevertheless, the removal of code issues is necessary to improve the software.
Summary: Overall the codebase for Dash seems promising
The Institute for Crypto Asset Analysis analyzes the codebase of cryptocurrencies with automatic algorithms and translates the results into a score. In the case of Dash, we encountered an overall satisfying codebase with room for further improvements. Summarizing the results into hotspots according to the urgency of the issue shows that one component of the code contains critical issues, five components are ranked as high, and nine components fall into the category of medium criticality. As Figure 5 shows, most of the hotspots can be located in the “rpc” component. The majority of the issues can be traced to the category of metric violation issues, which unveiled by far the worst score among all of the categories in Dash. Even though the code seems to function correctly, developers should review the critical sections of the code. The comparison of the Dash analysis with the previous snapshot (2018–02–16) resulted in a significantly better score for code issues, improving the overall rating of Dash.
In the future, it will be interesting to monitor new developments of the Dash code and to see whether the code will be improved regarding code quality. Also, the Institute for Crypto Asset Analysis continues to compare the results to other cryptocurrencies to determine which blockchain solution has the highest code quality.
The results shown in this paper are based upon an automatic analysis of the code. Please note that this analysis does neither represent financial advice, nor is it supposed to be understood or interpreted as solicitation to buy or sell any securities, coins or tokens.
If you like this article, we would be happy if you forward it to your colleagues or share it on social networks. If you are an expert in the field and want to criticize or endorse the article or some of its parts, feel free to leave a private note here or contextually and we will respond or address.
Do you want to learn more about how blockchain will change our world?
- Blockchain knowledge: We wrote a Medium article on how to acquire the necessary blockchain knowledge within a workload of 10 working days.
- Our two blockchain books: We have edited two books on how blockchain will change our society (Amazon link) in general and the everything related to finance (Amazon link) in particular. Both books are available in print and for Kindle — currently in German and soon in English. The authors have been more than 20 well-known blockchain experts in startups, corporations and the government from Germany, Austria, Switzerland and Liechtenstein — all contributing their expertise to these two books.
Prof. Dr. Philipp Sandner has founded the Frankfurt School Blockchain Center (FSBC). In 2018 and in 2019, he was ranked as one of the “top 30” economists by the Frankfurter Allgemeine Zeitung (FAZ), a major newspaper in Germany. Further, he belonged to the “Top 40 under 40” — a ranking by the German business magazine Capital. Since 2017, he is member of the FinTech Council of the Federal Ministry of Finance in Germany. The expertise of Prof. Sandner includes blockchain technology in general, crypto assets such as Bitcoin and Ethereum, the digital programmable Euro, tokenization of assets and rights and digital identity. You can contact him via mail (firstname.lastname@example.org) via LinkedIn or follow him on Twitter (@philippsandner).
Christian Flasshoff is research fellow at the Frankfurt School Blockchain Center and Alumni of the Frankfurt School of Finance & Management. You can connect with him on LinkedIn (www.linkedin.com/in/christian-flasshoff) or contact him via mail (email@example.com).
Benjamin Horvath is a research fellow at the Frankfurt School Blockchain Center and Alumni of WHU — Otto Beisheim School of Management. You can connect with him on LinkedIn (https://www.linkedin.com/in/benjamin-horvath-90553188/) or contact him via mail (firstname.lastname@example.org).