No, dPoW Isn’t a Perfect Solution
Satinder Grewal, a Komodo Platform developer, recently posted a Twitter thread claiming that using “delayed Proof of Work” (dPoW) is a strict improvement over existing “Proof of Work” (PoW) systems. Some of their Tweets are below. He compares it to using 2FA, in that it provides additional security.
He’s not the first person I’ve seen lauding the purported benefits of dPoW. The idea is pretty simple: small cryptocurrencies have a tough time securing their blockchain with their own set of miners, so why not fall back on another cryptocurrency’s security?
Komodo is not the first to generally have this idea. Merged mining is the process of sharing the work done on multiple blockchains. A miner does work for Bitcoin and submits it to another cryptocurrency that accepts the same work. Merged mining is not a new idea — Monero forked away from its original creator, who wanted Monero to be merge mined with Bytecoin.
Merged mining has severe limitations, which many dPoW proponents point to. While the point of this article isn’t to cover these, there are security risks when large mining pools manipulate the difficulty of the smaller chain. However, it is understandably appealing to only need one shared PoW pool.
Komodo’s dPoW is different. It uses a traditional PoW system with its own set of miners. However, unlike other systems, it adds an additional layer where the recent Komodo blockchain data is backed up to another service. Currently this is Bitcoin, but it could be backed up to anything (including a server somewhere) as long as it is accessible by everyone.
Komodo proponents (including Satinder) claim that this extra security measure is a no-brainer and comes with few or no limitations. The point of this post is not to definitively prove that dPoW is terrible; however, I will point out important considerations that make the effectiveness of dPoW far more complicated than dPoW proponents claim.
Just because your system hasn’t been compromised yet doesn’t mean it’s secure. It could be that someone hasn’t bothered to attack it yet.
There are only a handful of resources that explain the dPoW mechanism. Most (1, 2, 3) resources only cover the process on an extremely high level. The longest explanation I could find is in their whitepaper, page 23. I am basing most of my information on this. However, this is far short of a traditional security analysis. As far as I am aware, this post is the most in-depth review so far, which is worrying.
dPoW Systems Empower Nodes
The first thing to understand is that a dPoW system provides more power in the hands of nodes than typical PoW implementations. In Komodo’s implementation, 64 notary nodes copy recent Komodo data, archive it somewhere (currently the Bitcoin blockchain), and reference these archives in the Komodo blockchain.
These special nodes are given chances to mine blocks at nearly no difficulty (the rest of the network mines at a standard, adjustable difficulty). Without getting a helping hand from the network, they would not be able to compete against all the other miners. On average, one of these nodes notarizes a block every 10 minutes, though this is not fixed. It is not required that notarized blocks need to occur every X blocks either.
The whole notarization process could be broken, but I do not know enough about the exact implementation to look at it in detail. Therefore, we will make the assumption that it’s sound, but attackers in the future may try and expand on this attack surface more. I’m merely dismissing it as out of scope for this post.
All right, now for the fun stuff. We’re at the point where I explain what an attacker could attempt, and I will explain why either response from the Komodo network comes with its own set of drawbacks.
Consider the example Komodo blockchain below.
Here’s the Bitcoin (BTC) and Komodo (KMD) blockchains. Suppose the first block was notarized (indicated by the black arrow), and suppose an attacker spends KMD in the second block, indicated with the red dot. The attacker wants to reverse this transaction so that they can regain control over their funds.
Thus, the attacker secretly creates their own chain, beginning with the block that they wish to erase (the one with the red dot). It does not matter if the block they wish to erase is before or after a notarized block, or even if it is the notarized block. Let’s suppose the attacker does not have the capability to compete with the larger BTC network, so we will put aside all of those relevant attacks for now. At the moment, the attacker and main chain are neck-and-neck. Suppose that another block is notarized in the main chain, indicated by the second black arrow.
Success! The attacker mines more blocks with greater cumulative difficulty than the main KMD chain. It shares its blockchain with the rest of the nodes. The nodes need to determine if they will accept or reject the new chain. More on that later, but let’s suppose that the nodes will accept the chain with more difficulty for now.
So what happens then? Well, if my suspicions are correct, then the original chain is dropped in favor of the attacker’s longer chain. The greyed-out arrow indicates that the network ignores the notarization as inaccurate. The attacker’s latest block is notarized with the second black arrow, and the attack is “locked in” under KMD’s “rigorous” security standards (which we just discussed a way around). From this point on, the attacker’s chain will serve as the main chain.
A note about normal PoW
To any of you veterans out there, you may be saying “hey wait a second, that looks exactly the same as a normal Bitcoin 51% attack!” You’re right. It is essentially the same. If you want to attack the network, you need to replace the history of blocks on the Komodo network, including those that contain notarized blocks.
A few caveats
All right, a few caveats. I am not sure exactly how the Komodo consensus system works, and it could work in a few ways.
If the notary nodes are treated the same as normal full nodes, then to my estimation, this attack would occur. The network would proceed along fine without these notary nodes participating. The notary nodes may object, but the blockchain is law. The overridden notarization (the greyed out one in Figure 4) would be discarded by other nodes as fake/malicious. In this case the notary node is right of course, but the nodes don’t know that.
The most important measure is that all actions a notary node takes are publicly verifiable, and the Iguana Core software running on the users’ machines verifies notary nodes’ actions. The notary nodes themselves are not arbiters of “truth.”
— Komodo Whitepaper, page 24
If the notary nodes are given “supernode status” such that the normal network nodes would accept the chain with the most notarizations (rather than the most work), then this could be mitigated. However, this would come at the expense of other tradeoffs, including giving these notary notes near-ultimate power over the network. They would be able to only certify desired blocks transactions without any check to their power.
Some hybrid model could attempt to blend the two in some way, but this would still impose additional trust on the notary nodes. It would come with its own set of security implications that are far too nuanced to discuss here. Such an implementation would require an impeccably-detailed security analysis.
Both extreme cases are good at defending against some circumstances and bad at defending against others. Unfortunately, there is no oracle who decides which party is malicious, so the network ultimately needs to choose its poison. Even if it picks somewhere in-between, it’s effectively staggering this decision.
Conclusion
Komodo’s dPoW consensus mechanism sounds cool and is marketed well. Everyone wants to be able to throw in the security of Bitcoin’s network with no downsides. Unfortunately, this seems too good to be true. It’s not fair to compare it to 2FA.
There is opportunity for the notary nodes to act malicious, and there is opportunity for the miners to act malicious (as we saw with the example). Unfortunately, if these two groups disagree, one of these needs to win out. For Komodo, more power is given to the miners, meaning that whatever they say is the true blockchain, no matter what the notary nodes or the data placed on the Bitcoin blockchain says.
If it was the other way around, then the miners wouldn’t matter. Notary nodes would simply mine their own chains and only notarize blocks that they mine. This isn’t a good solution either. Notary nodes would have dominant control over the network, and other network participants couldn’t keep them honest. An annual notary node election isn’t going to hold a motivated attacker accountable if they can spend without restriction. The ability to double-spend money outweighs any economic incentive the network could otherwise provide. Giving even more power to these notary nodes would allow them to compromise the entire network. They’re already more powerful than normal nodes as-is.
I decided to write this piece to proclaim that dPoW has similar tradeoffs to traditional PoW, and I believe I succeeded. dPoW is not a magical solution. It’s another series of tradeoffs that needs to stop being glorified and needs a lot more testing before it should be seriously considered. Networks can attempt hybrid models attacks to not fall under either extreme, but this takes a lot of fine-tuning and creates a perfect environment for attackers to exploit any mistakes. When one gives power to centralized services (such as notary nodes) in a decentralized network, things almost always go wrong.
I encourage the Komodo team to immediately stop its “dPoW is the full security of Bitcoin with no compromises whose implications are akin to using 2FA” advertising. It is misleading, and in the absence of better security analyses, it’s an optimistic statement at best.
Justin Ehrenhofer is a senior at the University of Minnesota studying finance and management information systems. He is an advocate for privacy in distributed systems. He is a moderator of the r/CryptoCurrency subreddit, which is the most active cryptocurrency community.
Twitter: @JEhrenhofer
