I have written about multichain clusters where they are all setup to be 1:1 fungible with each other. The way it is implemented is so that to issue coins from a cross chain transfer, you need to get proof of the burn of the matching amount. Additionally, you need to make sure the same burn isnt allowed to issue twice, ie. prevent double spends.
Using komodo runtime forks, this cross chain burn/import is a matter of specifying the same clusterid and notarizing it. All the support to do it is built into komodod.
Let us now explore a special case of a cluster, namely two chains. We want to be able to do cross chain transfers from A -> B and also from B -> A while keeping the combined supply the same. Since we have a special case cluster, we will require that daemons for both chains are always running. This is called a dual-daemon chain.
Given a brand new protocol (actually any non-bitcoin protocol) coin, we can create a dual-daemon with it and a komodod runtime fork. Some custom code needs to be added to the non-komodo coin to implement the burn and import, but once that is done, then a 1:1 fungible dual-daemon can be created.
What are the practical benefits to doing something like this?
The primary benefit is that a brand new protocol can be integrated into the komodo ecosystem and also the larger bitcoin protocol system at large. So integrations into exchanges and other services can be done using standard code invoking the komodo side of the dual deamon. All such coins are 1:1 equivalent to the other side of the dual daemon.
As long as the other daemon can run on the same system and the burn protocol implemented, any such protocol can be supported. Be it, mimblewimble, cryptonote, ripple, ethereum, coda, etc.
We are working on a coda dual daemon, as it offers the solution to massive scaling. A single coda blockchains state can be stored in about 20kb of a zero knowledge proof, regardless of how many transactions. The limit is the number of transactions that can be processed by a single coda protocol chain. The transaction records for a specific wallet stays local to that node and it is not needed to be processed by all nodes, just when it is mined into the blockchain is it needed to be broadcast to the miners.
The unsolved problem of massive scaling is not in the transaction processing, or validation, but simply dealing with the terabytes of data. That is a lot of data and having to synchronize all of it, makes any million tx/second solution quite expensive. Using komodo chain clusters, it is indeed possible and the data would be automatically “sharded” into each chain in the cluster, but still if you are transacting on all of the chains in a cluster, you would need all the data from all the chains. a million tx/sec and 1/4 kb per tx, is 250 MB/sec of data. Not very realistic outside of a data center.
Let us combine the coda dual-daemon with a komodo chain cluster!
Now, each chain (that uses a pair of daemons) in the cluster is updating its blockchain state into a fixed 20kb size. even 1000 chains is only 20 MB, regardless of how many transactions. Also, the limit of creating the coda 20MB proof (which is computationally expensive) puts a cap on the number of tx per second. Whatever that cap is per coda chain, the cluster can multiply by N.
The komodo chain cluster of coda dual-daemons is thus the ultimate solution for scaling transactions. Make sure to only do the minimal amount of transactions on the komodo side, ie. exchange transfers and cross chain transfers to other chains in the cluster. By putting all of the high volume transactions on the coda side of the dual daemon, only the nodes that are involved in those transactions needs to store the data about them.