An Initial Look at Komodo’s dPoW
On December 7, I published an article titled “No, dPoW Isn’t a Perfect Solution.” It sought to take an initial first look at delayed Proof of Work and discuss some of its tradeoffs and limitations. This article is an extension of the previous article after discussing it for about 4 hours with the Komodo community, consuming several responses to the article, and then sitting on the article for months. Ultimately, my overall position remains the same: dPoW comes with tradeoffs.
Introduction to delayed Proof of Work
Komodo uses a hybrid security model they call “delayed Proof of Work” (dPoW). You can read a number of articles they have written about this topic, but it essentially goes like this:
Komodo has a network of normal miners and notary nodes. Normal miners proceed with their typical PoW function, mining blocks in a chain and competing against other miners to verify transactions. But they only mine approximately 25% of the blocks on average. Notary nodes mine the other approximately 75% of the blocks in (ideally) the same chain at a much lower difficulty than the other miners, and they perform additional network functions as they mine blocks.
In the simplest sense, Komodo’s network security is backed by “notarizations” (checkpoints) and this easy mining. Komodo has made some extremely aggressive claims regarding its supposed security, including that it’s as secure as Bitcoin. I knew there probably was some catch, so I went digging.
Simple Examples and a Dumb Metaphor
Here are a few extreme cases and a dumb metaphor to help explain the limitations of dPoW. Note that this is not how the network operates, but by covering these hypothetical extremes, you should hopefully see some limitations in trusting certain parties too much.
Ultimately, nodes need to determine a source of truth, notably “who made what transactions when.” For centralized services, we look at banks and payment processors to provide this source of truth. Visa says this happened, so I will believe them. In decentralized systems, we aren’t so lucky. We need to look to other information to determine what information is genuine. We need other mechanisms to tell us nodes what information to follow.
For Bitcoin and other PoW-based cryptocurrencies, we follow the information with the longest cumulative work put on it. We often simplify this as the longest chain, but this usually isn’t exactly correct. If two people have different viewpoints, we ask to see which of them worked harder to get to that point, then we follow their word. In this case, “work” is the mining they have done.
Suppose you have a case with two sources of truth: a group of nodes, and a group of miners. You normally expect them to work together, but there could be an instance where they disagree for some reason. In this case, who do you trust? You ultimately need to pick one of these truths if you want the network to keep moving along smoothly.
If you always trust the nodes, then the miners don’t really have a strong control over the security. If the nodes act maliciously, then the miners can’t adequately keep them in check. Likewise, if you always trust the miners, then the miners can act maliciously without restraint from the nodes. You can attempt to come up with a middle ground, but you will ultimately need to pick one set of data as the source of truth. You cannot have a network with conflicts. You need a way to resolve them.
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 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.
Notarizations, Checkpoints, and Bitcoin Research
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.
New Nodes vs. Old Nodes
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 Confirmations
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.
Notaries Can Notarize Whatever They Want
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.
Notaries Can Prevent All Transactions From Being Confirmed
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.
Bitcoin Has Nothing to Do With It
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.
Repeated claims, including that “with Komodo, you get the same level of security that you’re getting on Bitcoin” and that “Bitcoin’s energy is being recycled” are completely false and a case of malicious, runaway marketing.
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.
In Notaries We Trust… Until We Don’t
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 one or several large pools decide 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?
Conclusion
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.
