How dPow Works?
During the ten minutes before notarization, an asset chain using delayed Proof of Work is vulnerable to attack. However, so long as the developer understands the nature of this vulnerability, this does not actually present a danger to their asset chain or to their subset of the Komodo ecosystem.
Assuming they are using a vanilla version of the Komodo asset-chain setup, the developer simply needs to program their smart contracts and other ecosystem transactions to never consider a transaction to be complete until the transaction’s data has penetrated the desired level of Komodo’s security.
Within ten minutes, any transaction made on an asset chain will be notarized into the Komodo main chain. This provides a baseline level of security, though it is not as strong a defense as what occurs within another ten minutes: their data is then notarized into the Bitcoin blockchain. (See the whitepaper for full details.)
Developers simply need to make sure that the speed of transactions in their ecosystem matches the value of the transaction to the necessary level of security.
An Example
For example, consider this line of defense against a double-spend attack.
Let us first suppose an honest user who makes a transaction on the asset chain requesting an item of value. The mindful developer will write a smart contract that sends back a signal to the user indicating to them that their funds have been received and the blockchain product is on its way. The developer can even program software that allows the user to see that the item now belongs to them–but with one caveat: the blockchain product is locked in a smart contract for a few minutes while the asset chain waits to make sure that everything was done properly. Once the user’s transaction hits the desired level of security (as determined by either the developer, the user, or both), the smart contract releases the blockchain product to the user, and they are free to do with it as they wish.
Now let us suppose a malicious user intending to perform a double spend attack. They send their transaction requesting an item of value. The mindful developer sends back the item of value on the blockchain, using the protective smart contract. This smart contract is watching to make sure that the item of value is not released to the malicious user until the transaction reaches the desired level of security.
If, during that time period, the malicious user performs a double spend attack, what they are doing in effect is simply erasing the transaction where they sent their item of value. The developer’s smart contract sees that the transaction disappeared from the asset chain’s record, and the smart contract realizes there’s been an attack. It returns the item of value to its original owner. The malicious user may get to keep their original money, but they do not receive the item of value. The seller keeps it.
All of this is performed through automation, removing the need for a developer to manually manage these situations.
There are many other methods that developers can also take to facilitate smooth and hazard-free transactions on their system. For instance, they can also create their own network of trustless and verifiable notary nodes, similar to the notary nodes of the main Komodo chain. This can give them the option of lowering the required number of notarizations they desire on the Komodo main chain, and on the Bitcoin network, thus speeding up transaction time.