SOLVING THE BLOCKCHAIN TRILEMMA
INTRODUCING THE AMATE WAY: DUOCHAIN HYBRID PROTOCOL
Blockchain Trilemma Or DCS Triangle
Trent McConaghy [1] from BigchainDB published an excellent article called “The DCS Triangle — Decentralized, Consistent, Scalable. Pick any two! [2]” in Jun 2016. Shortly thereafter, Vitalik Buterin from Ethereum and Greg Slepak also made similar statements. Vitalik calls it “scalability trilemma” [3] or “blockchain trilemma”. By October 1977, Greg Slepak published the article the “DCS Theorem”, used the math language, proved this theorem, and later posted it at Cornell University in January 2018 [4].
In summary, the DCS triangle states that we can have any two of the three key attributes of blockchain: Decentralization; Consensus; Scalability, but not all three at the same time. Or, in other words, if we fixed an attribute, the other two attributes would compensate each other. For example, if we fixed the Decentralization attribute, and increase the Consensus, we would certainly have sacrificed the speed and scalability of the system. And vice versa.
At the moment, autumn of 2018, we all know that the transactions processing speed of public blockchain platforms is still a kind of disappointed. Bitcoin can handle around 7 transactions per second. Ethereum can handle just about 15 transactions per second. Too slow! And the obvious consequence is that platform scalability is something impossible. So, the question is how can we speed up transaction processing, increasing the platform scalability, without sacrificing much of the decentralization and consensus?
February 2018, Trent McConaghy updated his article and listed some approach to get around the limitation of the DCS triangle including:
- Improving the consensus protocol. Examples: Ouroboros [Kiayias2017][5], Dfinity [Hanke2018][6], Red Belly [Crain2017], OmniLedger [Kokoris2018][7]
- Sharding so that each node only has a fraction of the compute or data workload. Example: [EthSharding2018][8]
- Independent networks/chains with “glue” connectors. Examples: Interledger [Thomas2015][9], Cosmos [Kwon2017][10], PolkaDot [Wood2016][11], Plasma [Poon2017][12], TrueBit [Teusch2017][13]
- “Layer 2” payment channels. Examples: Lightning [Poon2016][14], Raiden [Raiden2018][15]
In his article “DCS Theorem”, Greg Slepak also proposed two approaches to solve the problem:
- Combining DC and DS systems: This is actually the state channels solution used in the Lightning Network and the Raiden Network as described above
- Combining multiple DC systems: Also known as sharding, this approach is mentioned above in Ethereum Sharding and OmniLedger too.
In this article, I will describe a new approach to solve blockchain trilemma: A new hybrid protocol to speed up transaction processing capability for blockchain platforms that support smart contracts. This hybrid protocol, called Duochain, is used in the Amate public blockchain platform that we are developing.
Blockchain And DAG
The slow processing speed of the current blockchain platforms is mainly due to algorithms and data processing protocols. Most current blockchain systems have a fixed block time, and blocks of data containing transactions within it are usually assigned a maximum size. Therefore, each block usually stores up to a certain number of transactions. And it means there is an upper limit of the transaction processing throughput. The protocols described above are considered to be synchronous protocols.
From 2014, there are a number of initiatives to use a different data architecture and transaction confirmation protocol based on the Direct Acyclic Graph (DAG) topology. Some well-known platforms can be listed include IOTA, ByteBall, and NANO (formerly Raiblocks). The DAG architecture allows new transactions to be generated, verified, and stored in the database immediately, without waiting for synchronization with other transactions. This asynchronous nature can theoretically allow for infinite transactions at any given time. However, due to many other constraints of computer networks, the transaction processing throughput with the DAG architecture still has its limit. However, this limit is usually much higher than the synchronous protocol based platforms.
Due to the asynchronous nature, adding smart contracts to DAG based platforms is very difficult. Smart contracts require that the initial global state and the input data is being synchronized to ensure the same output when running on different nodes at different times. The asynchronous nature of the DAG-based platforms simply does not support this feature.
Duochain Protocol
Duochain is a multi-chain, hybrid architecture that uses a hybrid transaction processing mechanism to integrate both blockchain and DAG architectures into one platform, taking advantages of both.
Duochain divides the transactions into two main categories: Direct account-to-account transfer of funds, and conditional fund transfers using smart contracts.
For direct account-to-account transfers, Duochain uses block-lattice architecture, a DAG-based multi-chain architecture proposed and implemented by Nano Currency (formerly Raiblocks).
In block-lattice architecture, each account owns and manages a blockchain of its own, called an account-chain. This blockchain only contains transactions related to the owner account. Only the account owner has the right to create and sign blocks and transactions in its blockchain.
With block-lattice, each transfer between the two accounts will be separated into two transactions: Send transaction from the sender account, and receive transaction of the receiver account.
When an account initiates a transfer transaction, it will be broadcasted to the system, verified, and will be posted into the blockchain of the sender account. In block-lattice architecture, each block contains exactly one transaction.
When the receiver’s node gets online, it will receive the send transaction addressed to his account, and the node will create a receive transaction then post it into the receiver’s account-chain. These two transactions take place asynchronously, without waiting for each other.
As noted above, the asynchronous protocol in DAG is a major impediment to smart contracts (hereinafter referred to as SC). SCs should have a global synchronized state of the system in order to be executed correctly in a decentralized manner.
Duochain proposed a solution to add a blockchain using a synchronous protocol to the system, which is used for smart contracts and their associated transactions only, called SC-chain (Smart contracts chain). The SC-chain will run in parallel with the account-chains of the block-lattice architecture.
The SC-chain is based on the customized and improved Ethereum platform, which uses the weighted DPOS consensus algorithm, instead of the current Ethereum POW. This is a shared blockchain, so any account can publish smart contracts to the SC-chain, and the SC calling and execution mechanisms have to follow the traditional synchronous blockchain protocol, similar to Ethereum and Bitcoin. This approach ensures that the SC-Chain always has a synchronized chain state, similar to the world state of Ethereum, which is the basis for SC execution.
From a general perspective, Duochain divides the blockchain network into two sub-networks. One subnet is used to transfer money between accounts, and the other subnet is used for smart contracts. So there is a question about inter-networks communication. How can an account call for a smart contract, and how can smart contracts transfer money/assets to an individual account located in another subnet?
Thanks to the block-lattice mechanism of splitting sending and receiving transactions, inter-network communication is quite easy. When an account wants to invoke an SC to execute, this account simply creates a transaction to address of the SC, and broadcast it to the network. When the nodes in the SC-chain subnet receive this transaction, they will generate a receive transaction, store it into the SC-chain, and launch the SC. After SC execution, normally new transactions will be created. These transactions will be verified and stored in the SC-chain, following the system’s consensus protocol. If a transaction is addressing an account in another subnet, this transaction will be broadcasted to the network as other account-to-account send transactions and will be processed accordingly by the asynchronous protocol of the block-lattice architecture mentioned above.
What is solved by Duochain?
By dividing the network as mentioned above, Duochain can help speed up the processing of the system many times. Let have a look at the following imagination:
Today’s smart contracts platforms could be compared to a single lane street. Buses (smart contracts) and cars (direct money transfer), all running on one lane, at a fixed speed, no one can pass the others.
With Duochain, we have a highway system, with countless lanes. A traditional line for buses (smart contracts), still running at the same fixed speed. And the cars (direct transfer transactions), will be moved to a countless number of lanes of its own. Each car has its own lane. Then, no one has to wait for the others, and speed can be maximized depending on the car capability. And even in the traditional lane, the number of buses — smart contracts will also increase, as the cars are diverted to its own highways.
Back to the DCS triangle, Duochain actually offers a hybrid protocol solution and a multi-chain architecture that extends the transaction processing bandwidth for the smart contracts platform. With the same level of decentralization, with a traditional SC platform, Duochain can add a P2P direct transfer network to the existing one, reducing the load on the smart contracts blockchain, increasing the processing bandwidth up a lot. And, reducing the load on the SC blockchain network is increasing the computing throughput of the SC blockchain itself.
The Duochain protocol adds a new method for solving the DCS triangle limitations of the current smart contract platforms. This approach does not conflict with the ones listed by Trent McConaghy in his article. It can be combined perfectly with the mentioned methods to get more incredible results getting around the limitations of the DCS triangle.
[1] https://blog.bigchaindb.com/@trentmc0
[2] https://blog.bigchaindb.com/the-dcs-triangle-5ce0e9e0f1dc
[3] https://github.com/ethereum/wiki/wiki/Sharding-FAQs
[4] https://arxiv.org/pdf/1801.04335.pdf
[5] https://eprint.iacr.org/2016/889.pdf
[6] https://dfinity.org/pdf-viewer/pdfs/viewer?file=../library/dfinity-consensus.pdf
[7] https://eprint.iacr.org/2017/406.pdf
[8] https://github.com/ethereum/wiki/wiki/Sharding-FAQ
[9] https://interledger.org/interledger.pdf
[10] https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md
[11] https://github.com/polkadot-io/polkadotpaper/raw/master/PolkaDotPaper.pdf
[12] https://plasma.io/plasma.pdf
[13] https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf
