An Initial Look at Komodo’s dPoW – Justin Ehrenhofer
A Komodo proponent claims that using dPoW is akin to using 2FA. 2FA is another security requirement to log in to your account; for example, instead of just needing a password, you also need to type in a code from a device you control. 2FA is widely regarded as a good security practice.
I think this metaphor isn’t appropriate, so I have a more accurate yet dumber one. Suppose that Google instituted a requirement that in order to log into your account, you needed to type in your password and have a friend you select approve the process. At a glace, some security experts could claim this is a security improvement, since in order to log in to your account, you need both the password and your friend’s approval. However, there are other limitations. Suppose you and your friend have a falling out. They could maliciously approve other logins to your account, essentially rendering the second verification useless. They could deny you access to your own account, even if it’s a genuine login request.
Again, proponents could claim for the ultimate goal of this verification requirement is to make logins for attackers harder. If the friend acts correctly, then attackers stand a tougher chance. If the friend acts maliciously, the security is as strong as it was before with just the password. However, this overlooks the additional “attack” vector created by the incremental annoyance of you losing access to your account if your friend doesn’t want you to have it. We can’t have a discussion about security without also explaining this unfortunate externality.
This dumb metaphor explains the general series of tradeoffs with Komodo’s dPoW security. It’s a series of tradeoffs with no clear answer. In an open, decentralized network, it’s unclear which exploits attackers will attempt, and we cannot assume they will look at attacks as narrowly as we hope. On paper, we may create narrow scenarios where having additional verification is better, but we also may be overlooking other potential attacks.
Komodo’s main security model boils down to this: nodes will reject reorganizations past the most the most recent notarized block that they have. This is the same as Bitcoin checkpoints, which have been studied far more extensively than Komodo’s notarizations. Bitcoin’s checkpoints are defined below.
Sounds great for security, right? Well, Bitcoin actually removed these checkpoints from their client. And it’s not because Bitcoin developers are stupid. Pieter Wuille from Blockstream writes in regards to why checkpoints were removed:
Associate Professor Nate Eldredge, Ph.D. at the University of Northern Colorado comments:
If [the frequency of checkpoints] is large then it doesn’t help much, because majority attacks can be very damaging even if they only roll back a few blocks. If [the frequency] is small then whoever sets the checkpoints has disproportionate power in determining which is the “right” branch of the blockchain, violating the goal of decentralization. — Nate Eldredge
In Komodo, the notaries notarize blocks to “checkpoint” them. Nodes with these checkpoints will not accept blocks that replace those before a checkpoint. Komodo proponents claim that this means the previous blockchain history is more secure and cannot be changed. Furthermore, since there is a built-in semi-decentralized checkpoint process, Komodo can therefore checkpoint far more aggressively than a standard Bitcoin client.
However, since Komodo’s implementation results in approximately 75% of the blocks being mined by these notaries and checkpoints every few minutes, then the Komodo ecosystem obviously paces significant trust in the notaries. The situation is just like it was in Bitcoin, except instead of developers pushing checkpoints, the notaries push notarizations. I will use notarizations and checkpoints synonymously throughout this article. For Bitcoin, these checkpoints were widely assumed to be a security feature despite most contributors saying this is not the case. This seems to be the case now for Komodo, where they are heavily advertising them as a security feature. Relying on checkpoints is a terrible last line of defense.
Komodo proponents claim that the network is safe in part because existing nodes on the network will simply reject any work done by miners that doesn’t align with the checkpoints. For example, suppose an existing node sees block 1,000,000 as a checkpoint, then receives a different version of block 900,000. The node would not accept the new block, since it interferes with the later checkpoint. This holds even if the 900,000 chain is longer (eg: goes to 1,100,000, while the other chain only goes to 101,000).
Unfortunately, this plays into the nuances of nodes and what information they find first. Sure, nodes may not reorganize past a certain point if they already have the smaller chain with the checkpoints, but what if a node finds the longer chain first?
This is the idea of a “new node,” or a node on the network that doesn’t have this checkpoint. It could select the longest chain and ignore the smaller, notarized chain. If the smaller chain eventually becomes larger, then it could switch over, but there are many situations where this would not happen.
It is therefore incorrect to simply claim that longer, non-notarized chains will be ignored by the network. They could be ignored by some nodes, but other nodes on the network will accept the longer chain. Consensus will have broken down.
In the figure above, some nodes would accept chain A as correct, while others would accept chain B. The network only returns to consensus if chain A grows longer than chain B. However, there is no guarantee this will happen. The black arrows refer to the checkpoints.
Komodo’s wallets are configured to display a specific confirmation number depending if it has received any checkpoints or not. If the transaction has received no checkpoints, the default client will only report 1 confirmation, even if there are several mined blocks. If there is at least 1 notarization, it will report confirmations equal to the number of subsequent blocks. An example showing the number of confirmations for a given transaction that is included in a block (the white circle) on two different chains is shown below.
While this may seem to provide additional security, it allows the notaries to harm the network by withholding confirmations. Furthermore, note that this confirmation number is not a consensus rule. It is simply a wallet config. Users can accept transactions whenever they want. Of course, users should wait for a number of confirmations for large amounts, just like they should with Bitcoin. With smaller chains, you should wait for more.
You should see a parallel here with my dumb friend 2FA example. Notaries have the power to prevent the official wallet clients from labeling transactions as confirmed, essentially grinding the network to a halt.
With cooperation, notaries can notarize whatever they want. There is no requirement that checkpoints need to occur on one single chain. This allows notaries to notarize one chain and then cause more confusion by notarizing another chain, as shown below.
Interestingly, this looks very similar to the diagram I included in my first article, which Komodo proponents claimed was impossible. The diagram above simply shows the situation in a more neutral way.
Notice how in both diagrams, an attacker theoretically receives a notarization for a different chain. Collusion among notaries is necessary for this to happen, but it is possible. In this process, the notaries simply pretend the other chain never existed and certify the other one instead.
This attack is indeed improbable but not impossible. If about 2/3 to 3/4 of the notary nodes decide that chain B is better, then they can notarize blocks there instead. Perhaps even more worrisome, if there ever is a situation where notaries collude to notarize a different chain, then it would be essentially impossible to determine which notaries were the bad actors. The attackers would be rewarded by notarizing more blocks than the notaries who put up resistance, and notary nodes that notarize the most blocks are automatically selected to carry on their duties into the next year. It would take several years to vote out a coalition of unpopular notary nodes if they are able to stay in the top 30 nodes.
Suppose the notaries decide to not notarize any blocks at all. What happens then? Based on the current network configuration, clients will not assign more than 1 confirmation to transactions that are in blocks that have not been notarized yet. Of course, clients could ignore this and accept them anyway, but then what’s the point of the notarization? In effect, it would cause in-the-moment chaos. If people decide to accept funds that have not been notarized, the notaries could exploit this by making transactions on the current chain then building and notarizing their own. Since the notaries can mine blocks at low difficulty, this is a pressing threat they can hold over the network to bring it to a halt.
What is necessary for this attack? They only need to get approximately 1/4 to 1/3 of the notaries to not confirm blocks to cause enough chaos among the notaries to not notarize anything. The ability for Komodo to confirm transactions rests in the hands of about 16 annually-elected nodes.
Komodo proponents claim that by archiving a record of these checkpoints in the Bitcoin blockchain that attackers would need to perform a 51% attack on the Bitcoin network to remove these records. This is blatantly false, The Washington Post “Bottomless Pinocchio” false. Komodo nodes and clients do not connect to the Bitcoin blockchain to check their integrity. None of the attacks I described have touched the Bitcoin network at all.
Putting data in the Bitcoin blockchain helps keep a paper trail, which is the same paper trail that could be collected by other Komodo nodes anyway. Furthermore, who is to say what information is accurate? Maybe this notary information is the malicious piece, not the miner information.
Komodo indeed raised the threshold that miners need to mine to attack the network. They need to compete with the notaries to exceed their network-designated advantage. However, in raising the barriers for the other miners, they lowered them for the notaries. Effectively, the security of Komodo is provided by the notaries. Not the Komodo miners. Not the Bitcoin blockchain. In notaries we trust.
Nevertheless, if miners build a longer chain since Komodo is a small network after all with extremely concentrated mining, then nodes will be torn between a perpetual state of broken consensus. If the SuperNova pool decides to reject notarized blocks in favor of blocks they mine, then they will create a longer chain with more cumulative work and thus will cause new nodes to have no idea which chain is the real one. Nodes who find the longer miner chain first will choose that one, and many parts of the Komodo ecosystem may be pressured to switch over.
You may be quick to say “well of course the mining pool is malicious so don’t follow it,” but how do you know they are the malicious ones? What if the notaries are malicious and not signing legitimately-mined blocks?
Komodo’s delayed Proof of Work consensus algorithm is no where near as understood as Nakamoto Consensus. For all its faults, Nakamoto Consensus is much better understood and researched.
While the Komodo team correctly explains the risks of PoW systems on small blockchains, it attempts to solve these issues by centralizing the network around these notary nodes. While there are some checks in place to limit their malicious behavior, they can manipulate the network more simply than outside participants and at little cost. It is unclear whether trusting these few participants is a better solution than rolling the dice with miners.
The Komodo team seemingly took all the good security assumptions of PoW and tried to improve the bad ones. However, I feel that the teem does not appropriately convey that in changing the system, there are other introduced limitations. The nuances of these limitations are very crudely understood.
Small networks will always struggle with achieving consensus, since they can generally be attacked at minimal cost. Trusting specific people over others may be preferable against most realistic security threats for small networks, but in these cases, we need to be honest and say that we are falling back on centralized security.
Published at Sat, 05 Oct 2019 18:30:57 +0000
{flickr|100|campaign}
