3. Kiva Blockchain Architecture

3.1 Definition

Blockchain is a synchronized and distributed ledger formed by distributed data storage, P2Ps, encryption algorithms, consensus mechanism, and smart contracts. Kivachain stores and transmits user keys by using a decentralized peer-to-peer system which does not need Trust Authority (TA) and resists a single point of failure. This map shows the basic structure of the blockchain. The block header includes the version, hash of the previous block (PreHash), Merkle root, timestamp (TS), difficulty target, and nonce. The Merkle root is the root hash of the Merkle hash tree (MHT). If the blockchain uses the proof of work (PoW) consensus protocol, the difficulty target is calculated by the miners as Hash (PreHash | TS | MerkleRoot | nonce) < difficulty target. After a miner finds a nonce and broadcast block in the network, if this block belongs to the parent blockchain, other nodes acknowledge the validity of this block.

Kiva Blockchain Architecture

3.2 Block Producing Process

The blockchain network’s validators collect the newly generated transactions in the blockchain network, verify the legality of these transactions, package the transactions in a block, record them as a new page on the ledger, and broadcast the page to the entire blockchain network. Other nodes will receive the new page and verify the legality of the transaction data on the page and add it to their own ledger. As the validators will repeat this process, all new transaction data in the blockchain system can be recorded in the ledger.

3.3 Delegated Proof of Stake (DPoS) overview

The role of consensus is to select the validators in the blockchain system. The validators verify the transaction data and keep the account in order to broadcast new accounts to other nodes in the network and obtain the approval of the new accounts from other nodes. As a specific implementation of consensus, DPoS works in the following way.

The DPoS consensus selects some nodes as validators in the blockchain system based on the number of votes they receive. First, when the blockchain system starts to operate, a certain number of tokens will be issued, and then the tokens will be given to nodes in the blockchain system. A node can apply to be a validator candidate in the blockchain system with a portion of the tokens. Any token-holding node in the blockchain system can vote for these candidates. Every T period of time, the votes for all the candidates will be counted. Top N candidate nodes with the most votes will become validators for the next T period. After T period of time, the votes will be counted again to elect the new validators, and the cycle continues.

• Kivachain: refers to the Kivachain network. The document does not distinguish between Kivachain, Kivachain blockchain, Kivachain blockchain system, etc.

• Kivachain coin: refers to the equity token issued by and circulating in Kivachain, known as Kiva.

• Valdidator candidates: nodes eligible for becoming validators in Kivachain.

• Validator: nodes in Kivachain qualified for book-keeping. They are usually called validators in the DPoS consensus. In Kivachain, there will be 33 validators, which are also called super nodes (or SR). Here, we will not distinguish between bookkeeper, validator, supernode, SR, etc.

• Bookkeeping: the process of verifying transactions and recording them in a ledger. Because ledgers in Kivachain are carried by blocks, the bookkeeping process is also called block generation. We will not distinguish between bookkeeping and block generation in the document.

• Bookkeeping order: block generation order. The descending order of the 33 validators based on the number of votes they receive.

• Block time: Kivachain sets block time to be 3 seconds. This means a block is generated every 3 seconds.

• Slot: after each block is generated, it can be put into a slot; and each generated block will take up a slot. For example, there are 20 slots for every minute. When a block is generated during the block time, the corresponding slot will be filled. However, if a block is not generated, then the corresponding slot will be empty. The next block generated will fill in a new corresponding slot.

• Epoch: Kivachain sets an Epoch to be 6 hours. The last 2 block time of an Epoch is the maintenance period, during which block generating order for the next Epoch will be decided.

• The maintenance period: Kivachain sets the period to be 2 block time, which is 6 seconds. This period of time is used to count the votes for candidates. There are 4 Epochs in 24 hours, and naturally, 4 maintenance periods. During the maintenance period, no block is generated and block generation order for the next Epoch is decided.

3.4 Election Protocol

During each Epoch, the 33 validators will take turns to generate blocks according to the bookkeeping order. Each validator can only generate blocks when it is their turn. Validators package the data of multiple verified transactions into each block. The hash of the previous block will be included in each new block as the parentHash. The validator will sign the data of this block with his/her private key and fill in validators_signature, along with the address of the validator, the block height, and the time that block is generated, etc.

Through storing the hash of the previous block, blocks are logically connected. Eventually, they form a chain. A typical blockchain structure is shown in the following picture:

In ideal circumstances, the bookkeeping process in a DPoS consensus-based blockchain system proceeds according to the bookkeeping order calculated in advance. Blocks are generated by validators in turn. However, in reality, the blockchain network is a distributed and untrusted complex system in the following three ways.

- Due to the poor network environment, blocks generated by some validators cannot be received by other validators in valid time.

- The normal operation of a certain validator cannot always be guaranteed.

- Some malicious validators will generate fork blocks in order to fork the chain.

As mentioned above, the basis of the blockchain system to operate normally is that most of the nodes in the system are honest and reliable. Furthermore, the primary guarantee for the security of the blockchain system is the security of the ledger, meaning that illegal data cannot be written into the ledger maliciously, and ledger copies saved on each node should be consistent as well. Based on the DPoS consensus, the bookkeeping process is carried out by validators. Therefore, the safety of Kivachain depends on the reliability of the majority of the validators. Kivachain has put confirmed blocks in the system which are irreversible. At the same time, to resist the malicious behaviors of a small number of validator nodes, Kivachain recognizes the longest chain as the main chain based on "the longest chain principle".

3.5 Validators

Every account in the Kivachain network can apply and have the opportunity to become validators. Everyone can vote for validators candidates. The top 33 candidates with the most votes will become validators with the right and obligation to generate blocks. The votes are counted every 6 hours and the validators will change accordingly. To prevent malicious attacks, there is a cost to becoming a validator candidate. When applying, 300,000 Kiva will be burned from the applicant’s account. Once successful, such an account can join the validators election.

3.6 The confirm block Principle

The newly produced blocks are in unconfirmed state, and only those blocks that are "approved" by more than 70% (i.e. 27 * 70% = 18, rounded down) of the 33 Validators are considered to be irreversible blocks, commonly referred to as solidified blocks, and the transactions contained in the solidified blocks have been confirmed by the entire blockchain network. The way to "approve" the unconfirmed state block is that the Validator producing subsequent blocks after it, the Validator C produces block 103, the Validator E produces 104' on the basis of block 103, the block 105', 106', and 107' produced respectively by the Validator G, A and B, are also subsequent blocks of the 103rd block, which means these four blocks approve the 103rd block. It can be seen that when the block of height 121 is produced, the 103rd block becomes a solidified block, since by this time the 103rd block has 18 subsequent blocks, and the point to be emphasized here is that the Validators producing these 18 blocks must be different from each other and from the Validators producing the 103rd block.

3.7 Kiva Smart Chain

Kiva Smart Chain is an innovative solution to bring programmability and interoperability to Kiva Chain. Kiva Smart Chain relies on a system of 33 validators with Proof of Staked Authority (PoSA) consensus that can support short block time and lower fees. The most bonded validator candidates of staking will become validators and produce blocks. The double-sign detection and other slashing logic guarantee security, stability, and chain finality.

The Kiva Smart Chain also supports EMV-compatible smart contracts and protocols. Cross-chain transfer and other communication are possible due to native support of interoperability. Kiva DEX remains a liquid venue of the exchange of assets on both chains. This dual-chain architecture will be ideal for users to take advantage of the fast trading on one side and build their decentralized apps on the other side. The Kiva Smart Chain will be:

• A self-sovereign blockchain: Provides security and safety with elected validators.

• EVM-compatible: Supports all the existing Ethereum tooling along with faster finality and cheaper transaction fees.

• Interoperable: Comes with efficient native dual chain communication; Optimized for scaling high-performance dApps that require fast and smooth user experience.

• Distributed with on-chain governance: Proof of Staked Authority brings in decentralization and community participants. As the native token, Kiva Smart Chain will serve as both the gas of smart contract execution and tokens for staking.

3.8 Design Principles

Standalone Blockchain: technically, Kiva Smart Chain (KSC) is a standalone blockchain, instead of a layer-2 solution. Most KSC fundamental technical and business functions should be self-contained to run well even if the Kivachain stopped for a short period.

Ethereum Compatibility: The first practical and widely-used Smart Contract platform is Ethereum. To take advantage of the relatively mature applications and community, KSC chooses to be compatible with the existing Ethereum mainnet. This means most of the dApps, ecosystem components, and toolings will work with KSC and require zero or minimum changes; KSC nodes will require similar (or a bit higher) hardware specifications and skills to run and operate. The implementation should leave room for KSC to catch up with further Ethereum upgrades.

Staking Involved Consensus and Governance: Staking-based consensus is more environmentally friendly and leaves more flexible options for community governance. Expectedly, this consensus should enable better network performance over proof-of-work blockchain systems, i.e., faster blocking time and higher transaction capacity.

Native Cross-Chain Communication: Kivachain will be implemented with native support for cross-chain communication among the two blockchains. The communication protocol should be bi-directional, decentralized, and trustless. It will concentrate on moving digital assets between Kivachain and KSC, i.e., BEP2 tokens, and eventually, other BEP tokens introduced later. The protocol should care for the minimum of other items stored in the state of the blockchains, with only a few exceptions.

Kivachain Consensus

3.9 Communication between Chains

Side-chains communicate with the root-chain and other chains via smart contracts. Kivachain provides the smart contract system for this communication called the Kiva Bridge protocol. Funds on side-chains are also held on the root-chain. This allows for fraud proof deposits and withdrawals of funds on side-chains via state transition. Side-chains do not disclose all information on the root-chain. Instead, blockheader hashes and a list of states are submitted, and if there is proof of fraud on the root-chain, then the block is rolled back and the block creator is penalized by the smart contract system governed by the root-chain. The Kiva Bridge protocol also helps Kivachain to communicate with other Blockchain platforms. I.e. information, token in exchange to Kiva Wallet, Kiva Agriculture, Kiva OTT, Kiva Education, etc. In case of the exchange of tokens to other Blockchain platforms, the Kiva Bridge protocol works as a decentralized exchange.

3.10 DPoS-HotStuff Consensus Algorithm

Consensus is the heart of any Blockchain platform. The popular consensus algorithm in Bitcoin and Ethereum is Proof of Work (PoW) which consumes huge amounts of electric energy to secure a ledger. This type of consensus algorithm makes the Blockchain fully transparent, public and decentralized but cannot scale to adapt to the big volume of transactions. In this paper, We apply Delegated Proof of Stake (DPoS) to our platform. DPoS is not a new consensus algorithm. It has been applied in Bitshare, Konla, and others. However, we combine the DPoS with HotStuff and side-chain architecture to make our system scalable and reach Block finality after one second

DPoS is a consensus algorithm developed to secure a Blockchain by ensuring representation of transactions within it. DPoS is designed as an implementation of technology-based democracy. Using voting and election processes to protect Blockchains from centralization and malicious usage. Before you can fully understand how Kivachain DPoS works, we need to clarify some of the terminologies:

Account: A unique identity on Kivachain. Each account has it’s very own key pair. The addresses are an account representation on Blockchain.

• Kiva Coin: This is the native token of Kivachain.

• Stakeholder: Any account with a token balance > 0

• Node: Refers to regular nodes and is a software that anyone can download to run a node and maintain the ledger, validate- and update transactions.

• Validator node: A ‘full’ node that represents an account with a minimum of 3 billion coins and receives enough approving votes from the community. Transactions and blocks are only validated by validator nodes.

In Kivachain, there are 33 validator nodes by default. That number may be increased. To become a validator node, Stakeholders must deposit at least 3 billion tokens to their accounts and then broadcast transactions to register as a validator node candidate. Other stakeholders will vote to decide the validator. The power of votes is based on the amount of tokens stakeholders have. The top 33 candidates with the ‘largest’ votes will become the validator nodes. The voting process is repeated every 1670 blocks called the epoch. In each epoch validator nodes have the capacity to produce a total of 32 blocks.

How Validator Nodes Produce Block In Kivachain

After the election process, 100 elected validator nodes are now ready for producing blocks. The traditional DPoS algorithm ‘round-robin’ produces blocks. I.e. block n is produced by validator n

Validator ∈ {1, 2, 3, n − 1, n}

Block ∈ {1, 2, 3, n − 1, n}

The process is predicted and may be broken up by a dishonest validator node. To protect the block producing predictions from being turned, we propose a random validator producing blocks while ensuring that every validator produces an equal number of blocks (32 blocks for each epoch).

Random Validator Chosen Algorithm

Validator ∈ {1, 2, 3, n − 1, n} n = 33

magicNumber = hexToIn(last 10 Digits(previousBlockHash))

index = magicNumber mod 33

Validator = Validator [index]

Because the previous block’s hash is only known at the processing calculation time, the magicNumber is the unknown number and therefore the next selected validator remains a secret. By using formulations as shown above, one validator may be chosen according to n-time to produce a block and it may exceed the capacity of 32 times correspondingly. To solve this problem, when any validator reaches the maximum number of producing blocks, It is removed from the random selection pool and gives another validator a chance.

HotStuff

HotStuff is a leader-based Byzantine fault-tolerant (BFT) replication protocol for the partially synchronous model. It is used in the Libra project and reduces the communication complexity - linear in the number of replicas. HotStuff changes BFT communication from mesh to star network, which relies on the leader.

Image for post

The traditionally practical BFT uses two rounds of message exchanges. The first phase guarantees proposal uniqueness through the formation of a quorum certificate (QC) consisting of (n − f ) votes. The second phase guarantees that the next leader can convince replicas to vote for a safe proposal.

The algorithm for a new leader to collect information and propose it to replicas is called the view-change. The view-change two-phase is based on traditional BFT and not simple or bug-prone. Any proposal in BFT has a communication footprint of O(n3) authenticators. The total 3 number of authenticators transmitted - if O(n) view-changes occur before a single consensus decision is reached - is O(n4 ) .

HotStuff is three-phased, allowing for a new leader to simply pick the highest QC it knows of. It introduces a second phase that allows replicas to “change their mind” after voting in the phase, without requiring proof of a leader. This alleviates the above complexity, and at the same time considerably simplifies the leader replacement protocol procedure.

In HotStuff:

• Pre-commit phase: Leader receives the prepare-vote for current proposal. It combine to prepareQC and then broadcast the pre-commit to all nodes in the network

• Commit phase: Leader receives pre-commit votes from (n-f) nodes, then combines it into precommitQC message and finally broadcasts to all nodes in the network. When replicas receive the message, It locks the state transition request so that q`1 of the consensus decision can be reached.

• Decision phase: When the leader receives enough commit-votes from the network, it combines them to CommitQC then broadcasts the decide-message to the network. Replicas in the network receive the decide-message which executes state transition, commit the state and then start the next view.

The pipelined HotStuff

HotStuff has the ‘same phase’ at all times: Prepare (not an official phase), pre-commit, commit, and decide. The flow structure: other nodes vote on a message and the leader combines the votes and broadcasts them to other nodes. These phases can be represented uniformly and pipelined

Become a validator node

Every stakeholder can also be a validator candidate. Stakeholders must have at least 300.000 Kiva Coin in their wallet. The following steps describe how stakeholder K becomes a validator:

• K deposits 300.000 Kiva Coin to K’s Kiva wallet, This amount will be burnt directly as the validator fee.

• K creates a proposal transaction to become a validator node

• If K’s transaction is valid, K will be listed as validator candidate and wait in line for the voting process

• Other stakeholders can see the list of validator nodes in the pool, and start voting for trustworthy nodes. The voting power depends on the total of tokens stakeholders have.

• The 33 validator node candidates that received the most votes will become the official validator nodes. The rest will remain in the pool for the next voting process. In case of a validator node failing to produce a block in time, waiting candidates may also become full validator nodes.

3.11 Incentive Model

To attract more people to Kivachain, the following incentive model has been created:

For each epoch a checkpoint is created. Validators at the end of epoch iteration will be responsible for calculating the network rewards. Tokens for the network reward in one year will be ~ 1% of total token (10 Millions token). It is equal to the annual inflation rate of 1%. The total token reward for each epoch are

Reward Token Epoch = Token per yearBlock per yearx Block per Epoch = 3.000.000(60*60*24*365)/3x7200 = 2055 tokens

The network reward tokens are divided into two portions: The first 40% go directly to the active validator nodes and the other 60% will be shared between stakeholders that voted for the validator nodes

Kivachain Specification

• Block Time: 3s

• Transactions per second (TPS): 50.000 transactions

• Block confirmation (finality) 1/s

• Native token: Kivachain Coin

• Total token: 1.000.000.000 (One Billion tokens)

• Transaction fee: Based on computational complexity. the normal transfer token cost 0.0001 token

• Consensus algorithm: DPoS-HotStuff

• Number of validator node: 33 nodes

• Smart contract language: Solidity. (Javascript and GoLang in the future)

• Digital signature algorithm: ECDSA

• Multi chain: Yes

• Cross chain communication: Yes

Technical Spec	Bitcoin	Ethereum	IOTA	Konla	Kivachain
Consensus algorithm	PoW	PoW	Tangle	DPOS-BFT	DPOS and Hotstuff
Transactions per second	3	15	300	Thousand	Fifty Thousand
Block time (second)	600	15	NA	1	3
Confirmation time (in seconds)	3300	150	NA	1	1
Smart Contract	x	✔	x	✔	✔
Multi chain	x	x	x	x	✔
Cross chain communication	x	x	x	x	✔
Validator node	x	x	x	x	✔

3.12 Decentralized Autonomous Organizations (DAOs)

What are DAOs?

A decentralized autonomous organization (DAO) is a blockchain-specific organizational model that addresses a perennial challenge present in almost every industry and organization: the principal-agent dilemma. Whenever a system is structured in a way in which an individual or entity (the “agent”) has the ability to make decisions or take actions on behalf of another individual or entity (the “principal”), there is inherent risk in the divergent goals, priorities, or access to crucial information of the respective parties. This is the principal-agent dilemma, and it means that the agent may be motivated to act in accordance with its own self-interest, even if the agent was selected to make decisions on behalf of the principal’s interests.

At present, this dilemma is a common challenge that affects a broad spectrum of public and private entities. Aiming to address this problem by reducing or bypassing the need for hierarchical human intervention or centralized coordination, DAOs are often referred to as “trustless” systems. By ensuring that the incentive structures and information flow within an organization are properly aligned in a codified format, DAOs play a central role in mitigating the typical problems associated with the principal-agent dilemma. The alignment of incentives is a defining concept of blockchain protocols, and DAOs apply similar logic to organizations and governance. A properly executed DAO aligns the incentives of stakeholders — from founders, to token holders, to users, and the general community — in governing an organization or decentralized platform. The potential effects of implementing DAOs on a broad scale are enormous, as are the real-world challenges of effectively applying technology that enables a DAO.

DAO	A traditional organisation
Usually flat, and fully democratized.	Usually hierarchical.
Voting required by members for any changes to be implemented.	Depending on structure, changes can be demanded from a sole party, or voting may be offered.
Votes tallied, and outcome implemented automatically without trusted intermediary.	If voting allowed, votes are tallied internally, and outcome of voting must be handled manually.
Services offered are handled automatically in a decentralized manner (for example distribution of philanthropic funds).	Requires human handling, or centrally controlled automation, prone to manipulation.
All activity is transparent and fully public.	Activity is typically private, and limited to the public.

How DAOs work?

While the specific underlying mechanisms powering a DAO vary across different blockchain projects, there are several general phases a DAO must undergo to launch in a sustainable manner:

• Smart contract setup: Before a DAO can be deployed, the underlying rules must be defined and encoded in a series of smart contracts. Given that future changes to the DAO’s operational workflows, governance system, and incentive structures will need to be voted on in order to take effect, this phase is arguably the most important step to creating a sustainable and truly autonomous DAO, as any initial mistakes or overlooked details can potentially destabilize the project down the line.

• Funding: Once the creators of a DAO have established its governing smart contracts, the DAO needs to receive funding in order to operate. The DAO’s smart contracts must entail the creation and distribution of some form of internal property, such as a native token that can be spent by the DAO, utilized in voting mechanisms, or used to incentivize certain activities. From there, individuals or entities interested in participating in the DAO’s growth can purchase or otherwise acquire the DAO’s native token, which typically results in acquiring voting rights.

• Deployment: Once a DAO receives enough funding to be deployed, all of its decisions are made via a consensus vote. As a result, all token holders become stakeholders who can make proposals regarding the DAO’s future and how its funds are spent. If the DAO’s token distribution policy and consensus mechanisms defined in its underlying smart contract architecture are well-designed, the DAO’s stakeholders will naturally work towards the most beneficial outcome for the entire DAO network.

The resulting DAO organization can therefore operate independently from its creators or any other central authority. Since DAOs are open source, all of their rules, transactions, and activities are recorded on the blockchain and can be reviewed by anyone, which generally ensures full transparency and immutability. In short, a DAO’s stakeholders are bound together by a common goal, which they will vote to advance through the pursuit of specific network incentives defined by the DAO’s underlying consensus policies.