Kappi Network is a hybrid blockchains ecosystem.

DEWI08

Kappi is a network of independent and decentralized hybrid blockchains.

Introduction

Creating success through the use of decentralized file-sharing in an open-source ecosystem to run a public cryptocurrency has allowed more people to understand how such infrastructure can improve basic social economics. Bitcoin, and Zero cash are two examples of specialized blockchain applications, and the best example of a smart contract platform would still be Ethereum, which allows for many applications of the Ethereum Virtual Machine (EVM). There have been drawbacks to the different blockchains that have been created thus far, such as the lack of energy efficiency, lack of any type of well thought out governance mechanisms and limited or poorly performing blockchains. Scalability was not thought of when Bitcoin was incepted, and now there are proposals to create scalability throughout Bitcoin’s transaction process

These include Bitcoin and Segregated-Witness, which are both vertical scaling models which are still bound by a lack of capacity within any single machine. This approach is necessary for pre-existing blockchains that didn’t consider their scalability due to the requirement to maintain a complete auditability. There is also the Lighting Network, which could be used instead of alternative options to bring scalability to Bitcoin transaction volume. This would be accomplished in the Lightning Network by reducing the number of transactions that are on the ledger. This approach is suitable for privacypreserving payment rails and for micropayments but might not suit more generalized scaling requirements.

Multiple blockchains running in parallel could use this solution advantageously, allowing for interoperation and still keeping all security properties of the blockchain. Proof-of-work approaches make this all but impossible. For merged mining, work is allowed to be done for the securing of a parent chain to be used again on a child chain but does not take away the need for each individual transaction to be validated by each node in order. Merged mined blockchains are also open to attack from a hashtag power majority on the parent chain, where there is no active merging of the child chain. This is where KAPPI comes in. KAPPI is a unique blockchain which has network architecture that addresses each of the above problems.

Why Kappi?

Kappi solves many problems of the existing blockchains:

Scalability
TPS
Usability
Security
Sovereignty

KAPPI Consensus Protocol

The KAPPI consensus protocol and the interface which was used to build the application is backed by nodes which retain voting power which is no-negative. This is different than the classic Byzantine Fault Tolerant (BFT) algorithm that has each node carrying the same weight. In the KAPPI consensus, validators are able to participate in the consensus protocol through broadcasting cryptographic based signatures, which are referred to as votes, that agree on the next block. The voting power of each validator is determined at genesis and can be altered deterministically within the blockchain, which would be dependent on what the application is. An example of this is that the staking tokens can be bonded as collateral to determine the voting power. Unless all the validators have an equal weight, fractions would not be used to refer to the validator but only for the total voting power.

One the benefits to the KAPPI consensus algorithm is its client security, allowing a versatility that can be used for any of the internet of things or mobile applications. Whereas a client of Bitcoin has to sync chains of block headers to find the one with the highest proof of work, the KAPPI clients only have to follow the validator set changes and verify any PreCommits within the newest block to create the latest state. Proofs in KAPPI also allow for inter-blockchain communication. Proactive steps are included in KAPPI that prevents specific notable attacks like censorship or double spends. The KAPPI consensus algorithm is opened in a program called KAPPI, which is an application-agnostic consensus engine that turns any black box, deterministic application into a replicated distributed blockchain.

The KAPPI DWARF connects to other blockchain applications through the Application Blockchain Interface, which can be programmed with any language regardless of the language used in the consensus engine. The application blockchain interface also allows for an easy changeover of any existing stack. An analogy can be made with Bitcoin, which is known as a cryptocurrency blockchain that operates by having each node carrying a fully audited Unspent Transaction Output (UTXO) database. If someone wished to create that type of system on an ABCI foundation the KAPPI DWARF would have the responsibility to share transactions and blocks between each node. This would establish an immutable or canonical order to the transactions in the blockchain.

The ABCI application would maintain the responsibility for:

The UTXO database.
Validating all cryptographic signatures within a transaction.
Stopping transactions from spending funds which do not exist.
Allowing client query through the UTXO database.

Scalability and Decentralization

KAPPI is comprised of a network of many blockchains that being powered by KAPPI. KAPPI allows many blockchains to be running concurrently with each other whilst retaining interoperability. At its DWARF, KAPPI DWARF manages multiple independent blockchain ‘zones’, that are also referred to by some as shards. With a constant stream of block commits coming from zones on the DWARF, it can keep up with each zone’s information and its current state. In turn, the zones keep up with the DWARF, but not each other except through the DWARF. Information packets are sent from one zone to another through the DWARF through Merkle-proof posting showing that the information was both sent and received accurately.

Inter-zone Communication

Using an example, let’s say there are three blockchains, one of which is the DWARF. We want to produce a packet that is destined to arrive at one of the 2 non-DWARF zones. For a packet to be moved between blockchains it is first posted on the receiving chain; the proof will state that a packet was published by the sending chain for the destination. For this proof to be checked by the receiving chain it has to keep speed with the sender’s block headers.

This is quite similar to sidechains that require interacting chains to be aware of each other through bidirectional chains through the use of datagram proof of existence transactions. The IBC protocol is able to define two types of transactions, a packet which facilitates the blockchain proof to observers of the last block hash and one that allows the blockchain to prove that the sender’s application published any given packet through the Merkle-proof. Since these mechanics are split into different transactions there is an allowance for the native fee mechanism of the receiver chain to determine what packet is acknowledged whilst allowing freedom for the sending chain to send any number of outbound packets.

Bridge Zones

A bridge is what the relationship between the DWARF and the zone is called. Both have to keep up to date information on the other’s blocks for the purpose of verifying proofs when tokens move between the two. The bridge zone has an indirection which lets the DWARF logic to stay agnostic and simple to the other blockchain’s consensus algorithm strategies. Every bridge zone validator will operate an KAPPI powered blockchain that includes an ABCI bridge app and a full node of the original blockchain. As new blocks are mined the bridge zone validators reach agreement on committed blocks through signing and sharing each perspective view of the blockchain tip origin. When payment is passed through a bridge zone on origin and there have been enough confirmations a corresponding account is created on the bridge with that balance. The bridge zone can share validator sets on networks such as Ethereum.

When such an exploit occurs the delegator and validator will be inactivated and 5% of everyone’s tokens will get sent to the hacker’s bounty address. The validator will then have to recover any tokens that remain through the use of their backup key. For the prevention of this feature being abused, a portion of unvested vs vested tokens and delegators before and after the hacker report will stay the same and the hacker’s bounty will be inclusive of any unvested tokens. Practical Byzantine Fault Tolerance was the original blockchain consensus, but KAPPI consensus is simpler to execute and use.

This is because the blocks in KAPPI have to commit sequentially, which supersedes PBFT’s view changes. In our blockchain there is no need to make a block commit if the original block has yet to commit. If it transpires the reason why n doesn’t commit within the KAPPI zone it will not help to integrate bandwidth sharing votes for N+I block. N+I will not commit if the reason is due to an offline node or a network partition. Block batching transactions facilitate Merkle-hashing of the application state, which works better than PBFT’s checkpoint and runs faster transaction commits that are provable inter-blockchain communication.