Documentation

Preamble

Kynno is a decentralised, open-source, energy-efficient public blockchain with high speed and low transaction fees. Kynno is designed to support the new Defi system of the world.

Kynno is designed to serve the next billion Web3 users and to help them experience the full promise of self-custody of their digital assets.

Kynno allows for running vanilla Ethereum as a Cosmos application-specific blockchain. This allows developers to have all the desired features of Ethereum, while at the same time, benefit from Tendermint’s PoS implementation.

Also, because it is built on top of the Cosmos SDK that supports the Inter-Blockchain Communication (IBC) protocol. Accordingly, end-users can import cryptocurrencies from the Ethereum, Cosmos and other chain families into Kynno, and subsequently use, trade or invest them in innovative smart contract-based protocols leveraging the rich application ecosystem of Ethereum / Solidity.

Here we present Kynno, a novel blockchain network architecture that addresses all of these problems.

Kynno Value Proposition

As an open-source Layer 1 blockchain, Kynno aims to massively scale the Web3 user community by providing builders with the ability to instantly port apps and crypto assets from other blockchains while benefiting from low transaction fees, high throughput, and fast transaction finality. Key value propositions of Kynno include:

  • EVM Compatibility: Kynno is built on Ethermint, which supports rapid porting of apps and smart contracts from Ethereum and other EVM-compatible chains;

  • Scalability: Kynno aims to deliver faster, cheaper, and eco friendly transactions and smart contract execution than proof of work chains;

  • Interoperability: The Inter Blockchain Communications (IBC) protocol enables interoperability and bridging to other IBC-enabled chains, such as Cosmos Hub, Osmosis, etc;

  • Proof of Stake (POS): Utilising POS as a more streamlined and scalable consensus mechanism while still maintaining security through a range of experienced and carefully-vetted validators;

  • Open Source: High involvement of the community is welcomed to proactively review and provide suggestions to strengthen Kynno.

  • Developers: Exposing a fully compatible Web3 JSON-RPC layer for interacting with existing Ethereum clients and tooling (Metamask, Remix, Truffle, etc).

The sum of these features allows developers to leverage existing Ethereum ecosystem tooling and software to seamlessly deploy smart contracts which interact with the rest of the Cosmos ecosystem!

Technology

Architecture

Overview

Kynno is one of the very few blockchains that exist at the intersection of the Ethereum Virtual Machine (EVM) and the Cosmos ecosystem. It is an EVM compatible Chain built on the Cosmos SDK, allowing the chain to exist in the intersection of the Cosmos and Ethereum ecosystems while enjoying benefits from both ecosystems.

Tendermint

In this section we describe the Tendermint consensus protocol and the interface used to build applications with it.

VALIDATORS

In classical Byzantine fault-tolerant (BFT) algorithms, each node has the same weight. In Tendermint, nodes have a non-negative amount of voting power, and nodes that have positive voting power are called validators. Validators participate in the consensus protocol by broadcasting cryptographic signatures, or votes, to agree upon the next block.

Validators’ voting powers are determined at genesis, or are changed deterministically by the blockchain, depending on the application. For example, in a proof-of-stake application such as Kynno, the voting power may be determined by the amount of staking tokens bonded as collateral.

CONSENSUS

Tendermint is a partially synchronous BFT consensus protocol derived from the DLS consensus algorithm [1]. Tendermint is notable for its simplicity, performance, and fork-accountability. The protocol requires a fixed known set of validators, where each validator is identified by their public key. Validators attempt to come to consensus on one block at a time, where a block is a list of transactions. Voting for consensus on a block proceeds in rounds. Each round has a round-leader, or proposer, who proposes a block. The validators then vote, in stages, on whether to accept the proposed block or move on to the next round. The proposer for a round is chosen deterministically from the ordered list of validators, in proportion to their voting power.

The full details of the protocol are described here.

Tendermint’s security derives from its use of optimal Byzantine fault-tolerance via super-majority (>⅔) voting and a locking mechanism. Together, they ensure that:

  • ≥⅓ voting power must be Byzantine to cause a violation of safety, where more than two values are committed.

  • if any set of validators ever succeeds in violating safety, or even attempts to do so, they can be identified by the protocol. This includes both voting for conflicting blocks and broadcasting unjustified votes.

Tendermint consensus can process thousands of transactions per second, with commit latencies on the order of one to two seconds. Notably, performance of well over a thousand transactions per second is maintained even in harsh adversarial conditions, with validators crashing or broadcasting maliciously crafted votes.

Block Structure

Valid transactions are grouped into blocks with a structure shown in figure 1. The validation and transactions hashes are merkle tree root hashes of the signatures and transaction data included in the block [2]. The state hash, included in the header, is likewise the merkle root hash of the persistent account state (external to the blockchain) after applying the transactions of the block. Finally the block hash is computed by hashing the header, validation, and transactions hashes. This way, the block hash itself is a merkle root hash such that any component of the block and account state can be verified with a merkle hash trail that leads to the block hash. A block is said to be valid if all the transactions in the block are valid and sufficient signatures are included in the validation.

Cosmos SDK

Cosmos is a network of independent parallel blockchains that are each powered by classical BFT consensus algorithms like Tendermint 1.

Cosmos SDK is an open-source framework suited for PoS or PoA blockchains. With the Cosmos SDK developers can create custom blockchains from scratch on top of Tendermint, and natively interoperate with other Cosmos SDK blockchains.

The Cosmos SDK allows for composable open-source modules that can be easily integrated. Developers can use pre-built modules or create custom modules that can be imported into the existing blockchain application.

Inter-Blockchain Communication Protocol (IBC)

The Inter-Blockchain Communication protocol (IBC) is an end-to-end, connection oriented stateful protocol used for reliable, ordered, and authenticated communication between heterogeneous blockchains.

This interoperability is achieved by specifying a set of data structures, abstractions, and semantics such that they can be implemented by a distributed ledger satisfying this set of requirements.

The IBC is used for cross-chain applications such as token transfers, atomic swaps, multi-chain smart contracts and data and code sharding.

Kynno Modules

Feemarket

This module allows to define a global transaction fee for the network. And it has been designed to support EIP1559 [3] in cosmos-sdk.

This module describes a pricing mechanism that was proposed on Ethereum to improve to calculation of transaction fees. It includes a fixed-per-block network fee that is burned and dynamically expands/contracts block sizes to deal with peaks of network congestion.

Before EIP-1559 the transaction fee is calculated with

fee = gasPrice * gasLimit

With EIP-1559 enabled, the transaction fee is calculated with

fee = (baseFee + priorityTip) * gasLimit

The Cosmos SDK uses a different terminology for gas than Ethereum. What is called gasLimit on Ethereum is called gasWanted on Cosmos.

Citations

  • 1 DLS: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf

  • 2 R. Merkle, “Protocols for public key cryptosystems,” Proc. 1980 Symposium on Security and Privacy, pp. 122–133, April 1980

  • 3 EIP1559 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md

Last updated