LISTEN TO THE PODCAST:
One of the most common questions in the crypto space is how hard is the chain to attack, or how much does it cost per hour to take over the chain with a 51% attack. Most chains don’t give up this information easily, which causes third-parties to build their own tools to evaluate chain security. In Decred’s case, the project is very proud of the effectiveness of its hybrid security and has built a tool to simulate the full cost of an attack.
In the DCRDATA sidebar, scroll down to the “Attack Cost”. In this section, you have the information needed to assess how the chain's security is performing under current conditions. The initial controls and data show the cost of attack if the attacker has obtained 20,429 tickets and 83 Ph/s in miner hash power. This data shows the attacker will be able to generate blocks at the same average speed as the honest network. This calculation includes the costs for hardware, electricity, and ticket purchase. With these vectors, Decred would cost $243 million to attack initially. It’s important to note, the cost of attack does become a lot cheaper after this initial investment. But arguably, if this barrier to attack remains high, the incentive to attack is very low.
The parameters of the attack cost calculator can be changed to consider other circumstances, like what would happen if the attacker had more tickets or more hash power. But in each case these calculations show, as long as Decred has a good level of decentralisation across tickets and proof of work, the project is extremely difficult to attack.
Next in the menu bar is the parameters section. This section lets us check the rules for the Decred chain. When you’re comparing various blockchains this can be incredibly useful to see how the chains differ in their implementation -for instance if one chain has a block interval of 5 mins and the other has a block interval of 10 minutes.
Each parameter set, is divided up, starting with chain parameters. Here you can check the basic elements for the chain, including interval between blocks. Furthermore, you get to look into the first block in the chain, the genesis block, and the premine block to see how the initial distribution was performed. This section also includes the maximum block size and maximum transaction size. As we saw in a previous article, this information can tell us if blocks are exceeding their maximum limits and the chain and validating nodes are performing as expected.
The subsidy parameters section lets us look at how the block reward is distributed. The first part shows how the reduction occurs, for example – a reduction of 1% every 6144 blocks or approximately every 21 days, in contrast Bitcoin has a block reward halving every four years. The idea with Decred’s block reward reduction is to be more gradual and remove the supply shock factor.
Next you have the division of the block reward which changed recently from 60% Proof of work, 30% proof of stake, 10% treasury to 10% proof of work, 80% proof of stake, 10% treasury. Unfortunately, this information hasn’t been updated and is currently undergoing discussion for the best way to be displayed.
The stake parameters section defines the elements for the ticket process. Including – Target ticket pool size; Tickets that can vote each block; how long it takes for a ticket to mature before and after participating in voting; And how long it takes for a ticket to expire if it doesn’t vote. As discussed previously, Decred’s ticket system is used to validate the miner's proof of work; vote on consensus changes; vote on community proposals and to vote on treasury spending.
The treasure parameters section describes the rules and process for treasury spending. I’ll go into more detail in a future article, but for now, this is how a treasury spend is conducted.
Next we have the Rule change parameters which determine the rules and intervals for a consensus rule change, including – Number of votes required for a vote to take place, and the rule change activation interval. Which is how long it takes for the change to take effect if the voting approves the change, in this case, 8064 blocks or approximately 28 days.
The last section, are the Address parameters which identify and describe the addresses used and implemented on the Decred chain. For reference – Each address has a 2-byte prefix that can be used to identify its type, and a checksum suffix to detect improperly entered addresses.
Next up is the agendas area. Here we get an overview of all the consensus changes that have occurred on the Decred chain, starting with the most recent and when they were implemented.
As discussed previously, Decred has a systemised approach to upgrades which has been so successful that in the last consensus change they decided to formalise the process as an explicit version upgrade. Which basically means that everyone participating in the protocol now has to run the same version of the software, making Decred the first hard fork only blockchain. Previous and future versions now need to be explicitly approved by Decred stakeholders to become valid.
Also, available in this area, are the stats for how the vote progressed including yes, no and abstain votes and the approval rate. As you scroll down, you can dig a little deeper into these upgrades and their states by clicking on the link provided.
If you want to dig even deeper, there is a better site called voting.decred.org, which allows you to see the same stats available on the agenda page but also links to the proposal information.
As you can see, DCRDATA aims to make Decred’s on-chain information as accessible as possible. And although this information can be daunting, there’s an important emphasis, on open and transparent. Anyone who wishes to participate has the opportunity to do detailed research and investigation without relying on second hand or bias information.