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)

Ten Chain Configuration

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.