KAPPI network.

KAPPI works as a network of several different independent blockchains, which are called spaces. Each of these spaces is powered through a KAPPI DWARF, ensuring that there are a consistent, high-performing and secure PBFT similar consensus engine wherein the accountability is guaranteed through forks. The KAPPI algorithm is scalable and can be used for proof of stake, public blockchains.The KAPPI is a cryptocurrency that operates a multi-asset proof of stake and has a simple governance system that allows for upgrades and is generally adaptable. The KAPPI DWARF can connect to other spaces allowing it to be extended.

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.

Due to the inter-blockchain communication, any zone can be a DWARF for the purpose of forming an acrylic graph, if desired. The KAPPI DWARF blockchain consists of a multiple asset distribution ledger with tokens being individually used or used within a zone itself. Tokens can be moved between zones through a DWARF responsible for preserving any global invariance of the total token value across each zone. Sender, receiver, or DWARF blockchains can commit IBC coin packet transactions. The KAPPI DWARF is the central ledger for the entire system and its security is of primary importance. Each zone can have a KAPPI blockchain that is secured by no less than 4 (or less if not using the BFT consensus) and is secured by a set of validators that are globally decentralized to serve as being strong enough to stop any type of hack or attack scenario. The KAPPI zone constitutes an individual blockchain which exchanges IBC messages to the DWARF.

The DWARF would conceive a zone to be a multiple asset membership dynamic with a multiple signature account capable of sending and receiving tokens through IBC packets. Like any cryptocurrency account, zones cannot transfer a token if they do not have that token to send but are able to receive tokens. Zones can use one or more types of tokens, which gives it the ability to inflate token supplies. Atoms of the KAPPI DWARF can be staked by any validator of a zone which is connected to the DWARF. This could result in a double spend attack, but it would be slashed through the KAPPI fork accountability, a zone where voting power cannot create any invalid state. KAPPI DWARF will not execute or verify any transaction that is committed in another DWARF, so users must send tokens to trustworthy zones.

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.

This type of multiple ability lets KAPPI zones become bridges to various cryptocurrencies and allows derivatives to be created of those blockchains, using the same codebase and integrating a different initial distribution and validator set. This creates the ability to link to other frameworks using the KAPPI engine as a common network. Within a multiple asset blockchain a singular transaction can include different inputs and outputs, wherein any input can be a different type of token. This enables KAPPI to operate as a decentralized exchange platform directly. Zones can also act as faulttolerant distributed exchanges that is better than other centralized cryptocurrency exchanges in the sense that it is not prone to hacking.

Sharding strategies are also being reviewed by Ethereum in an effort to address their own scalability issues. Ethereum is aiming to create a solution that maintains the abstraction layers that the EVM has across all shared space. This makes it clear that KAPPI and Ethereum operate different design goals, which KAPPI being about tokens and not being bound to the EVM. KAPPI will allow the zone creator to determine who is in a position to validate the zone. In KAPPI, anyone will be able to start a new zone, and the DWARF will act to isolate any failures within a zone for the purpose of preserving any token invariants that are preserved The Lightning Network is a token transfer system which has been proposed to operate one layer above the Bitcoin blockchain, or other public blockchain, and which will allow larger order throughput through pushing most transactions out of the consensus ledger into different payment channels through on-chain crypto scripts.

This would allow bilateral stateful contracts where sharing digital signatures will act to update the state, and then at close the evidence will be added to the blockchain. The Lightning Network can easily extend across more than one blockchain for the purpose of transferring values in an exchange market, but it can’t asymmetrically transfer tokens between blockchains. The KAPPI network does allow such direct token transfers.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.