Ex-J.P. Morgan Heads’ Multi-Chain Smart Contract Platform Kadena
As the fight for scalability rages on, ex-JP Morgan blockchain leads throw their hat in the ring with Kadena and its Parallel-Chain Proof-of-Work consensus.
Kadena is a smart contract platform with a new approach to Proof-of-Work (PoW). It implements the Chainweb protocol, a PoW Parallel-Chain Architecture built for high throughput. While the technology appears robust and well-tested, many question the viability of the parallel-chain architecture. Kadena is looking to become the go-to enterprise solution in DLT and already has an anchor Fortune 100 healthcare company for a client.
Kadena has built two versions of its blockchain: public and permissioned/enterprise. On Kadena’s public network, a braid of multiple chains integrate their Merkle roots together, ensuring that while each individual chain acts as a unique blockchain, it can still share information and reach consensus with the other chains linked by Chainweb. Each linked chain will transact Kadena’s native tokens and Chainweb will implement Simple Payment Verification (SPV) by deleting coins that are sent to another chain before being generated on the receiving chain. This allows Kadena to increase scaling by gradually adding more individual chains to the network without adversely affecting the scarcity properties of the native token. Kadena’s private chain mechanism is based on a derivative of the Raft consensus algorithm, a single leader-based system for managing a replicated log. Based on Raft and Juno, Kadena embeds its own full smart contract language (Pact) into its blockchain that can be run as either public or encrypted transactions. It uses ScalableBFT to offer high-performance (8k-12k transactions per second) with full replication and distribution holding at significant scales (up to 500 nodes). This, along with the multi-layered security model and incremental hashing allows for a truly robust blockchain.
Chainweb
Chainweb is a parallel chain Proof-of-Work mechanism that combines potentially thousands of separately mined peer chains braided in a single network, capable of achieving throughput in excess of 10,000 tps. Chainweb consists of two features that operate at different layers of its stack:
- Cross-chain cryptocurrency transfers via on-chain SPV smart contracts = Each chain in the network mines the same cryptocurrency which can be transferred cross-chain via a trustless, two-step Simple Payment Verification (SPV) at the smart contract level.
- Parallel-chain braiding at the hashing level via peer-chain Merkle root inclusion = peer chains incorporate each other’s Merkle roots to enforce a single super chain that offers an effective hash power that is the sum of the hash rate of each individual chain.
In Bitcoin, SPV is used to verify payments without running a full network node. This is done by obtaining the Merkle branch linking the transaction to the block it’s timestamped in, and ”linking” it to a Merkle root obtained from the block header stream of the longest chain. The transaction hash and the hashes needed for a merkle proof, known as a merkle branch, can be given as a form of verification. Then one can do a Merkle proof to prove that the transaction hash exists in the merkle tree. The incorporation of peer Merkle roots in Chainweb serves to provide a trustless oracle of the longest chain of a given peer to the SPV validation process.
Braided Parallel-Chain Consensus
Imagine that instead of having one chain and one group of miners, you build a Bitcoin-like PoW network with 10 chains each with their own subgroup of nodes (many miners will mine on more than one chain and an expected 30–50% of them will mine the whole set, so a subgroup here refers to ). So how do you reach consensus on all chains together, especially without losing speed? (See Ten Chain Configuration figure below)
In Bitcoin, each block mined must contain/reference the block header created by the previous block of its chain to be accepted by the network, making consensus basic but potentially insecure.
In the Chainweb Protocol, every block mined must contain the block headers of its own chain and other chains according to well-tested graph theory solutions. These solutions draw connections, or vectors (←→), between nodes/subgroups that are closest by number of steps; these vectors determine which chains’ headers must be referenced by each subgroup.
For Example, in the situation of a Ten Chain Configuration, miners who wish to mine a block on Chain 1 (node 1 in Ten Chain Configuration figure) must reference headers from chains 3, 4, 6, and, of course, 1. All ten chains execute this function and it propagates transactions semi-exponentially. A transaction added to Chain 1 will be recognized by Chains 3, 4, and 6 after just one proceeding block and exist on all ten chains by the second block.
Graph theory proves that this model can potentially scale to >100,000 chains. By setting up consensus this way, it not only maximizes throughput but allows for many chains to run more securely than one. To alter a transaction, an attacker would have to produce a longer proof-of-work branch on ALL chains that reference the transaction, which becomes increasingly difficult with each additional block. This is visualized as Merkle ‘cones’ as shown by the most right graph of each Chainweb above. As every layer has a probability mass, so too do Merkle cones. Known as Merkle mass, it is the sum of the mass of the sequential layer intersections of the cone and it increases at a nearly exponential rate as the future Merkle cone of a block is being constructed by the network. This measure dominates the security model of any Chainweb configuration since an attacker must overwhelm the full mass to successfully double spend.
Pact
Pact is a smart contract language whose interpreter is built in Haskell (standardized, compiled programming language). In Kadena, every transaction is a smart contract and Pact is database-focused, transactional, and Turing-incomplete. There are key differences between it and Ethereum’s Solidity smart contract language: it is interpreted, meaning the code you write is what directly executes on chain, while Solidity is compiled, adding an addition layer making it hard to verify code and solve security issues in older versions once compiled. Pact has its own interpreter, but can run in any deterministic-input blockchain. The newest version of Pact, 2.4, was released in June.
Problems with PoS
But wait, I thought we decided PoW is bad?
Efficiency, electricity, environment, scalability, governance, mining pools, oh my. Since mid-2017, there has been a serious amount of criticism of Proof of Work and newfound support for Proof of Stake, a staking consensus mechanism in which control of the network is determined by token share rather than hash power. Even Ethereum core developers have been working on Casper, a dynamic staking protocol, to transition the Ethereum network to a more hybrid PoW/PoS model over time. You can read more in my PoW vs. PoS article for Blockchain at Columbia here.
But turns out that it’s not so simple. While PoS offers the attractive advantages of deterministic confirmation and a significant boost in performance, PoS is inherently limited by the execution speed of the application layer, which restricts throughput. The only good solutions so far to this issue requires PoS-style blockchains like EOS, Cardano, and NEO to lean towards a relatively centralized system that may resemble our existing financial networks. Unlike PoS, PoW has no effective limit on the number of participants, despite the fact that most PoW blockchains have faced other issues of throughput and finality. Kadena looks to capitalize on the strengths of PoW and implement parallel-chain consensus to provide a truly decentralized and scalable blockchain.
Origin
The history behind Kadena is quite extensive and noteworthy for this new ecosystem. Kadena is a continuation of the JP Morgan project Juno, which was forked from Tangaroa, which was developed based on the Raft consensus algorithm, none of which are longer under active development. Juno was a proof of concept to scale Tangaroa to 50 nodes and throughput of 5000 transactions per second. The JPM team behind Juno saw the potential that a Tangaroa-like approach represented — a high performance private blockchain. They iterated on the idea for a year and open sourced the project in February of 2016, adding Pact, fixing mistakes and succeeding in achieving a significant performance increase. JP Morgan’s new blockchain Quorum varies notably from Juno and uses a fusion of ideas from sidechains and Ethereum; public smart contracts are allowed on the blockchain in addition to private contracts which are represented as encrypted hashes and replicated via side-channels. The Kadena founders find this approach counter-productive and split their product into two chains: public and permissioned. Kadena was spawned from the open source code of the Juno project and was built by the two key developers who built Juno: Will Martino and Stuart Popejoy.
Kadena’s expected and real-world performance as it scales. Kadena executes over 7000 transactions per second, with latency in the low milliseconds, with consistent performance on cluster sizes of up to 256 nodes. We forecast steady performance well into the 1000s of nodes. — Will Martino, Co-Founder of Kadena
Conclusion
In short, Kadena is a two-part blockchain project of JP Morgan origins, building both permissioned and public blockchains. The public chain protocol is Chainweb which implements parallel-chain consensus. This structures multiple individual PoW chains to run in parallel and reference one another’s block headers. The mechanism allows for scalability, security, and decentralization. Kadena is solidifying new partnerships with a few behemoths in the healthcare, banking, and accounting industries. It will be interesting to see how Kadena’s public blockchain will fare against current solutions and how its private blockchain will be able to onboard enterprise clients.
___________________________________________________________________
Hold down the clap button to 50 claps if you liked the content!
I love getting questions or suggestions, so comment away.
You can reach me at nir.k@columbia.edu
