Decentralization of the Dash Masternode Network
Since its inception, decentralization has always been at the heart of Dash’s design and evolution. Dash pioneered the DAO, it’s grown to have one of the biggest node counts in the industry, and it continues to implement solutions to keep any possible sources of centralization at bay. As the launch of Dash Platform approaches, Dash Core Group and the community have been evaluating their options for obtaining a good balance between decentralization and user experience, two things which don’t always come hand-in-hand. One solution we are considering is whether or not to run Dash Platform on a subset of higher-performance masternodes rather than every masternode. In light of this discussion, we decided to take a look at the decentralization of the Dash masternode system versus competitor validator systems.
Dash currently has the second-highest number of nodes validating transactions in proof-of-stake networks, with only Ethereum having more. It ranks third among all blockchains, after Bitcoin and Ethereum.
Although a high node count is nice for decentralization, it’s not so nice for fees. This is because for each transaction, users must pay every node to process and store their data. For this reason, some are arguing that 4000 nodes is overkill for Dash Platform.
If the masternode count was reduced by a factor of 10, fees would also drop by a factor of 10. Consequently, the same chart from above would look as follows.
The reduced masternode count would put Dash Platform in the sweet spot between high decentralization and low fees, and smack in the middle of its competitors.
Distribution Among Entities
While other systems may have more validators, the decentralization of validator owners is, in many cases, much weaker than Dash’s. For example, in Ethereum, only two entities – Lido and Coinbase – currently control about 42% of the nodes (1). After the Merge, these two entities added 420 of the network’s first 1000 blocks (1). The top seven entities control more than 67% of the nodes (1).
Although the Dash masternode distribution isn’t precisely known due to the chain being so old, we still have some metrics that provide thorough insight. Perhaps the most telling information comes from www.MNOwatch.org, a community-managed website (shout out xkcd) that compiles information related to Dash DAO proposals, the top masternode whales, and other interesting topics related to the Dash network. Based on their data, we’re able to construct the chart for Dash below, which illustrates the proportion of staked value held by the top seven entities, and compare it to Ethereum.
In comparison to Ethereum’s 42% and 67% held by the top two and seven entities, Dash’s top two and seven entities hold 12% and 25%, respectively. The top whale is Binance, followed by six pseudonymous entities.
The same charts for Cardano and Solana are shown below.
The top two and seven entities in Cardano hold about 20% and 33.3% of the stake (2), and about 4.6% and 11.8% for Solana (3).
While the Cardano chart may not raise any red flags for most users (congrats to them on their broad distribution), the Solana chart certainly will for anyone who has been following Solana the past few years.
The Solana blockchain has notoriously halted, been manually rolled back, and restarted several times in the past few years. Such restarts are only possible if over 80% of the validators work together to roll back and restart it. How can such a seemingly distributed network coordinate this process in under 24 hours? The following chart from Messari might give us some insight.
Less than 2% of Solana’s initial token allocations went to the public. The other 98% went to insiders, community allocations, and foundations. Without digging too deep into where these tokens are now, it would not be unreasonable to assume that many of them are with insiders. Nevertheless, the fact remains that the blockchain has been and can be rolled back and restarted (a practice which is very frowned-upon in the crypto community) in under 24 hours.
Dash is missing from the chart because it never had an initial token allocation, but instead has created all new tokens using an open, permissionless mining process.
Geographic and Hosting Provider Distribution
The next topic to consider is geographic and hosting provider distribution. These are important factors because some countries may impose regulations and sanctions on specific cryptocurrencies, contracts, accounts, etc., or even ban cryptocurrency altogether, as we’ve seen in the past.
A well-known current example of this is the recent sanctions imposed on Tornado Cash by the US Office of Foreign Assets Control (OFAC). Many US-based Ethereum nodes started blocking Tornado Cash transactions due to the sanctions, as they were subject to punishment themselves. Similarly, many services used by Ethereum nodes have begun blocking Tornado Cash transactions. In fact, at the time of writing, 33% of all post-Merge Ethereum blocks have been OFAC-compliant, and therefore blocking Tornado Cash transactions due to using OFAC-compliant mev-boost tools alone (4). That number is increasing, too. In the past 24 hours, 50% of new Ethereum blocks have been OFAC-compliant for this reason (4). If this number reaches 51%, as it’s on track to within the next few days, and the censoring nodes stop attesting to uncensored blocks, Ethereum will officially become a censored blockchain.
The distribution across countries and hosting providers for the Dash masternode network is illustrated in the figure below.
Dash Platform’s consensus mechanism, Tenderdash, is able to handle up to 1/3 byzantine validators in an active validator set. That means it would require 34 out of 100 validators in a set to enforce censorship. However, since validator sets are chosen randomly from the entire pool of masternodes, every new set gives the transaction a new chance to be included in a block, and in all likelihood it would eventually get a validator set which would allow it. With our current distribution of nodes, the chances that a transaction would possibly get censored anytime in the near future are practically zero.
One potential vector of attack that may be on the reader’s mind is – what if there are whales who aren’t currently running nodes, but have enough tokens to take control of the network if they do decide to stake their tokens? Fortunately, the blockchains we’ve been discussing have no whales with such significant single wallet addresses, as can be verified on the various respective blockchain explorers. Of course, a whale may have multiple wallet addresses, which wouldn’t be obvious when looking at an explorer’s rich list, but even then it’s unlikely they would be significant enough to gain control of a network.
A measure of a blockchain’s decentralization wouldn’t be complete without at least a brief discussion of its Nakamoto Coefficient. A network’s Nakamoto Coefficient is the number of entities required to compromise one of its subsystems. It can be evaluated for any part of the network – from the number of developers required to change the code to the number of miners required for a 51% attack. Some evaluations add the various factors up, and some only look at certain subsystems.
A comprehensive evaluation of Dash and its competitors is a topic for another day. Here, we’re just going to look at the number of nodes/validators required to compromise consensus models, the metric which matters most in the context of this discussion. In this sense, Dash Platform’s Nakamoto Coefficient is 34 – representing 34 nodes out of a 100-node Tenderdash validator set.
Note that for Dash Platform, this figure is an absolute, near-impossible minimum. If an attacker only has 34 out of 4000 total masternodes that are being selected at random for a 100-node validator set, they’ll most likely need to wait a very, very long time before all 34 of their nodes are included in the set. The chances of it happening are again, practically zero.
However, there are currently about 15 entities with more than 34 masternodes, which makes their chances a bit higher. That becomes even more so when we’re talking about reducing the total number of masternodes from 4000 to 450 (the tentative number chosen for the leading proposed high-performance masternode solution).
Increased Stake Solution
A counterbalance to this potential problem can be implemented as follows. With the decrease in total number of nodes used for Platform, we can increase the amount of stake required to run a Platform node, effectively reducing the number of nodes that the top whales would have.
For example, the top three whales in Dash currently have around 270, 230, and 130 masternodes, with 1000 Dash staked for each masternode. If the staking requirement was upped to 4000 Dash for the new Platform masternode system, that would cut the top whales’ potential number of Platform nodes by four times – to 67, 57, and 32. Only two whales would remain who could possibly compromise the chain. If the staking requirement was upped to 10,000, it would cut the top whale’s potential number of Platform nodes to 27, guaranteeing that no one at the current node counts could gain enough control to compromise the chain.
While these solutions provide increased security, they also introduce a higher barrier to entry for owning a masternode on Dash Platform, especially with the 10,000 Dash option. This is something that most in the community are not very keen on. Fortunately, such a steep increase as 10,000 Dash is likely not necessary.
With the 4000 Dash option, chances are still extremely thin that the top whale gets 34 of their 67 nodes in the 100-node validator set. It’s a 0.00000174% chance each time the set is selected, to be exact. Even then, it’s most likely that all the attacker could do is halt the chain, which would result in no direct monetary gain, and only hurt the system they have at least 136,000 Dash invested in. It’s unlikely that anyone would want to do this. The 4000-Dash option is, therefore, quite attractive for providing security, reducing fees, and keeping the increase in barrier to entry at a minimum.
Ultimately, the decision of whether or not to implement one of the proposed “high-performance masternode” solutions (name subject to change) is up to the masternode owners themselves, and accordingly, Dash Core Group will write a DAO proposal to be voted on soon.
For more information, you can watch the Dash Core Group YouTube presentation on the topic, or join the discussion in the Dash Discord or forum.