Crypto Notebook

Enzo Notebook

Crypto Alpha

Klaytn

TLDR

⁠

https://twitter.com/tradingdisaster/status/1269743274694230023⁠

⁠

What is Klaytn

Klaytn is a public blockchain developed by internet giant Kakao Corp, which operates South Korea’s biggest messaging and social media service. From its onset in early 2018, Klaytn has identified blockchain mass adoption as its foremost goal. Ever since, the project has built a public blockchain network and a business-friendly development platform around it to help entrepreneurs and enterprises in various sectors build highly usable blockchain applications(BApps) for a wide range of end-users regardless of their level of crypto-literacy

Klaytn launched its mainnet,

Cypress⁠

, on Jun/27/2019 with the following specifications.

1-second block generation and confirmation time.

4,000 TPS.

Low gas price that is almost 1/10 of Ethereum.

Runs EVM and supports the execution of Solidity contracts.

19 reputable corporations worldwide initially formed Klaytn Governance Council to operate consensus nodes. The current number of consensus nodes is shown in the

Klaytnscope⁠

More than 50 initial service partners have committed to launch Blockchain Applications on Klaytn.

Klaytn Design

Overview of Klaytn Architecture

Klaytn can be partitioned into three logical subnetworks based on their roles and purposes. The below figure displays the high-level view of the Klaytn ecosystem.

⁠

Core Cell Network (CCN)

CCN consists of Core Cells (CCs) that verify and execute transactions submitted through Endpoint Nodes (ENs). CCN is responsible for creating and propagating blocks throughout the network.

Endpoint Node Network (ENN)

ENN consists of Endpoint Nodes (ENs) that mainly create transactions, handle RPC API requests, and process data requests from service chains.

Service Chain Network (SCN)

SCNs are Klaytn subnetworks composed of auxiliary blockchains independently operated by blockchain applications (BApps). Service chains are connected to the main chain via ENs.

Core Cell Network and Endpoint Node Network form a Klaytn main chain or mainnet. Blockchain Applications can run on the Klaytn main chain, Cypress, or can operate on their own blockchains called Service Chains. If you want to have a dedicated execution environment for your application that guarantees high TPS and configurable network policies, we recommend using Service Chain.

Klaytn Network Topology

In this section, we will describe the network topology of Klaytn main chain. A tiered network architecture with role-based node types is implemented in Klaytn to optimize the network performance.

Role-based Node Types

Before we go over the Klaytn main chain network topology, we need to get familiar with the different types of Klaytn nodes.

Core Cell (CC): Consensus Node (CN) + Proxy Node (PN)

A Core Cell (CC) is composed of a single Consensus Node (CN) and two Proxy Nodes (PNs). Consensus Nodes are participating in the block generation process, while Proxy Nodes provide the interface to the network. PNs transmit the transaction requests to the Consensus Nodes, and propagate the blocks down to the Endpoint Nodes.

Endpoint Node (EN)

ENs serve as endpoints for Klaytn network handling RPC API requests and processing data sent to and from service chains.

Bootnode

Bootnodes are special-type nodes operated by Klaytn to help newly joining nodes register to the network and to discover other nodes to connect with. CN bootnodes reside within the CNN and are not exposed to the public, while PN and EN bootnodes are publicly visible. PN bootnodes only allow permitted PNs to be registered, and let eligible PNs connect with ENs. EN bootnodes provide ENs with information on which PNs to connect to.

Tiered Networks

CNs, PNs, and ENs form logical networks, Consensus Node Network (CNN), Proxy Node Network (PNN), and Endpoint Node Network (ENN), respectively.

Below figure shows the overall topology of Klaytn mainnet, where Core Cell Network (CCN) is further broken down into Consensus Node Network (CNN) and Proxy Node Network (PNN). Endpoint Node Network (ENN) is also shown as the surrounding network connected directly to PNN.

⁠

Consensus Node Network (CNN)

CNs form a full-mesh network among themselves called CNN. CNN applies BFT over a WAN (wide area network) and requires each CN to satisfy

stringent hardware and network resource requirement⁠

to carry out BFT consensus at a sufficient performance level.

Proxy Node Network (PNN)

PNN consists of PNs. Typically, PNs maintain just one connection with a PN in a neighboring Core Cell. The number of peer connections is subject to change depending on the network configuration.

Endpoint Node Network (ENN)

The outermost subnetwork, ENN, is solely composed of ENs connected to each other and also to a number of PNs.

Block Generation and Propagation

Block generation and propagation design, along with the consensus algorithm used, plays an important role in reducing the latency of a blockchain platform. For consensus algorithm, please directly refer to below for more explanatory language, although this section entails its entirety.

Block Generation Cycle

A 'round' is a block generation cycle in Klaytn. Each round generates a new block, and is immediately followed by the start of a new round. Klaytn targets each round to be approximately one second, although block generation interval may be influenced by network traffic and node operation conditions.

Proposer and Committee Selection

In each round, Klaytn randomly but deterministically selects a Consensus Node (CN) as the proposer for the block to be created, and then selects a group of CNs as the committee for the given round. Klaytn is not directly involved in the selection of either the proposer or committee; instead, each CN uses a random number derived from the most recent block header to run a cryptographic operation which yields proof that the CN has (or has not) been selected for this round. The committee size should be Byzantine resistant; if the size of the CNN is small, all CNs (except the proposer) are eligible to be selected as committee members.

Block Proposal and Validation

Once selected, the proposer broadcasts its proof of selection for the round (i.e., a cryptographic proof verifiable by the public key of the proposer) to all CNs. Thereafter, the CNs selected as committee for the given round responds to the proposer with their own proofs of selection, notifying the proposer to whom to broadcast the new block to be proposed. The proposer then selects a set of transactions from its transaction pool and creates a block by ordering them. Lastly, the proposer executes consensus with the committee to agree upon and finalize the newly created block. Note that Klaytn plans to continuously improve its consensus algorithm to achieve higher security and efficiency.

Block Propagation

A proposed block must receive signatures from more than two-thirds of the committee members to be successfully finalized. When the committee reaches consensus, the new block is propagated to all CNs and the consensus round ends. Once the new block is propagated to all CNs, the information of the newly created block can be made available to all Klaytn network participants by delivering block header and body data to ENN through PNN.

Public Disclosure and Open Validation

Service providers and end-users on Klaytn network can freely validate block generation results and check if the CN committee have generated the block according to proper procedures. Such validation includes checking if the block header contains more than two-thirds of the committee signatures. All CNs must support open validation and are required to post their public keys (used to sign blocks) in a publicly accessible space (e.g., block headers). Open validation promotes transparency, deter censorship, and prevent malicious behaviors.

Separated Propagation Channels for Blocks and Transactions (Multichannel Propagation)

A network's latency is heavily affected by its degree of congestion. Assuming the network's throughput remains constant, increased number of transactions will cause the network's latency to be proportionately delayed. Latency delay is a critical issue in BApps; typical users of legacy mobile apps or web services will not tolerate response time that takes more than a few seconds, and blockchain services have no reason to assume a higher user tolerance.

Klaytn adopts a multichannel approach in order to handle network congestion issues. By assigning separate propagation channels for transactions and blocks, Klaytn network is able to propagate newly created blocks in a timely manner even when the network faces heavy congestion with high number of transactions. In this way, Klaytn ensures that BApps on its network can stay responsive to end-user requests regardless of intermittent network traffic spikes.

Block Rewards

For each round, block reward (which is the sum of 9.6 newly minted KLAY and transaction fees paid to process the block) will be distributed to the network participants according to preset distribution ratios. The proposer of the newly created block will receive 100% of the reward to be awarded to CNs, whereas the committee will receive none. Note that the probability of being selected as the proposer is influenced by the amount of KLAY staked by the CN, implying that a CN with more KLAY invested in the platform will probabilistically receive more rewards.

Consensus Mechanism in Klaytn

Klaytn is aiming to be an Enterprise-ready and Service-centric platform. Therefore we need to solve the finality problem written above and the network should be able to allow many nodes to participate in the network. To make this possible, Klaytn is using an optimized version of Istanbul BFT, which implements PBFT with modifications to deal with blockchain network's characteristics.

In Klaytn, there are three types of nodes, CN (Consensus Node), PN (Proxy Node) and EN (Endpoint Node). CNs are managed by CCOs (Core Cell Operators) and are in charge of block generation. These blocks are verified by all nodes in the network.

Klaytn achieves fast finality by adopting and improving Istanbul BFT. Because validation and consensus are done for each block there is no fork and the block's finality is guaranteed instantly as soon as the consensus is made.

And also the issue of increasing communication volume in the BFT algorithm is solved by utilizing randomly selected Committee. CNs collectively form a Council and on each block generation, part of them are selected as a member of Committee using a VRF (Verifiable Random Function).

⁠

Block archiving - Storage

The high throughput of Klaytn should result in high storage costs. Klaytn plans to perform block-archiving to ease storage burdens of participating nodes. With block archiving enabled, ENs may remove bodies of stale blocks, maintaining only a certain number of the last blocks. Only a subgroup of Klaytn network nodes will keep all the blocks in cost-effective storage and they will serve read requests by verifying older transactions no longer stored in ENs. However, even block archiving ENs will still have to keep the headers from all archived blocks in order to allow clients to securely verify the contents of the archived blocks.

This process can effectively reduce the storage cost of ENs, encouraging diverse participants to join the ENN. Assuming 100 TPS in average and 1-second block latency, the size of data that an EN must replicate can be significant. If the average transaction size is 300 bytes, the expected EN daily storage requirement is 2.5 GB/day (=300x100x86400). While this does not hinder servers and desktops (where storage space is more easily expandable and less expensive), certain ENs running their nodes on lighter machines such as laptops could find this storage requirement a burden. By allowing ENs to only keep a fixed number of blocks, block archiving will extend its benefits to a broad spectrum of audiences on the network, fortifying data redundancy and security without requiring ENs to replicate an ever-growing ledger of blocks.

Whereas removing block bodies may be perceived as weakening decentralization as block archiving nodes cannot independently verify all historical transactions without the help of other nodes. Nonetheless, not all applications need constant access to the complete history of transactions, and we believe that block archiving is a welcome feature strongly preferred by certain groups of services --- services that require only the latest states of applications. Serving all blocks in this context is inefficient and less desirable. We believe that block archiving will benefit many applications requiring high replication levels and the security of blockchain technology.

Token Economy & Governance

KLAY

KLAY is the main internal transferable cryptocurrency of Klaytn and is used to pay transaction fees when creating or executing smart contracts or when transferring KLAY.

KLAY is a necessary element--a fuel--for operating the Klaytn distributed application platform. It is a form of payment made by the clients of the platform to the consensus nodes (CNs) executing the requested operations. To put it another way, KLAY is an incentive; it ensures that developers write high-quality applications (wasteful code costs more) and that the network remains healthy (CNs and RNs are compensated for the resources they contribute).

Funding Structure

Klaytn’s funding structure runs continuously with Klaytn network’s block generation. With every new block, newly issued KLAY and the sum of transaction fees used in the block (collectively called “block reward”) are aggregated and distributed to the following three destination accounts in accordance to the predetermined ratio:

Klaytn Governance Council Reward: 34%

Klaytn Growth Fund (KGF): 54%

Klaytn Improvement Reserve (KIR): 12%

At the time of Klaytn mainnet launch, 9.6 KLAY will be minted per block. This implies that approximately 300 million KLAY will be minted annually, which is equivalent to 3% annual inflation against the 10 billion KLAY issued at genesis (the annual inflation rate is subject to change through the Klaytn Governance Process). Transaction fee is charged per OPCODE and is metered according to the

transaction fee table⁠

⁠

Klaytn Governance Council Reward

Klaytn Governance Council is the collective group of Core Cell Operators (CCOs). Council members are responsible for maintaining Core Cells (CCs), which makes the Council an essential body in the Klaytn ecosystem responsible for providing the underlying infrastructure. To become a Council member, the candidate must undergo a qualification review by the Klaytn Governance Process and must stake at least 5 million KLAY.

Klaytn Governance Council Reward Mechanism

For every block, a Committee composed of randomly selected Council members is formed. Each Committee has one member assigned the role of Proposer; all other Committee members assume the role of Validators. When a block is successfully created and added to the Klaytn blockchain, the Proposer of the said block is rewarded with 100% of the block reward. The probability of a Council member being selected a Proposer is proportional to the amount of KLAY staked by the member.

To make the platform trustworthy in its initial stages, only trusted entities are considered as potential Klaytn Governance Council members. This is designed to improve the protocol in a rapid manner for the development and stabilization phase.

As long as the minimum 5 million KLAY staking requirement is met, Klaytn Governance Council members can freely stake or unstake his or her own KLAY. Staking information is updated every 86,400 blocks, and newly staked KLAY comes info effect two update cycles later from when the staking is completed. Withdrawing staked KLAY requires one week of delay to prevent malicious members from immediately exiting.

To prevent monopolized claiming of Klaytn Governance Council Reward by small groups of highly invested Council members, Gini coefficient may be used to adjust the effective amount of staked KLAY. The application formula is as follows, where G stands for gini coefficient of Governance Council's KLAY staking distribution:

Adjusted staking amount = (Council member's staking amount)^(1/1+G)

Penalty for Misbehaving Council Members

A Council member may be subject to penalties for conducting misbehaviors defined below. In the future, more penalty rules can be established and refined through the Klaytn Governance Process.

Causing Safety Failure:

A Council member selected as Proposer may not create more than one block in the same height

A Council member selected as Proposer may not intentionally omit certain transactions

Causing Liveness Failure:

A Council member selected as Proposer must create a valid block

A Council member selected as Validator must validate the block proposed by the Proposer

Klaytn Growth Fund

The Klaytn Growth Fund (KGF) aims to bring Klaytn economy forward by providing grants and investing in various organizations and individuals that contribute to the Klaytn economy. Since it is an open network, anyone can join to build an application without obtaining any permissions. However, a wider adoption of blockchain has been hindered because the technology is still in its early phase, and most of the values and data are still being managed in traditional ways in the form of contracts, local storage, etc. And solving these problems are exactly what the KGF is intended for. During its initial phase, digital asset applications and infrastructures will be some of its focus areas. To operate the KGF, various programs for promoting the adoption of Klaytn in the digital asset industry may be included.

Klaytn Improvement Reserve

The Klaytn Improvement Reserve (KIR) will be managed on the platform for the investment and research on the Klaytn ecosystem. The spending necessary to set up the ecosystem can be categorized as following.

KIP setup

KIP setup

Governance Roadmap

The bodies participating in governance must act in consideration of Klaytn’s long-term benefits rather than just for their personal interests, and they must actively participate in the governance process. Additionally, all participants that contribute to the network as Klaytn Governance Council members must secure computing resources that are greater than the platform requirements and stake a set amount KLAY of their own or from third parties. For smooth operations in development and stabilization of the platform, Klaytn Foundation will take on many roles in governance related matters in the initial development phase. In the future, however, other bodies will gradually take on greater roles in the decision-making process, and they will have the right to participate independently.

Development Phase: The initial development phase after the mainnet launch must quickly see parameter adjustments, new feature developments, etc. For this to be possible, many issues will be decided through gathering the opinions of the Klaytn Governance Council members, service providers, and community members. To secure initial stabilization, Klaytn Foundation will lead the decision-making process. Additionally, all decided matters will be transparently shared with the public.

Stabilization Phase: The Klaytn Governance Council has governing rights on many proposals and this phase will gradually begin starting Jan 2021. For special matters such as those concerning platform development, and matters that directly affect the overall Klaytn ecosystem, Klaytn foundation may facilitate the discussion and execution.

Decentralization Phase: Following the stabilization period, to gather additional opinions, more service providers and other bodies may be brought into the decision-making process. Decentralization phase may be gradually achieved through multiple stages with different governing rules and participants.

For the grainy detail of governance proposal & procedure, please refer to Section 4.3 - 4.5 of

Klaytn’s Token Economics and Governance Paper⁠

Bibliography

⁠

https://www.klaytn.com/developers⁠

⁠

https://docs.klaytn.com/⁠

⁠

https://www.klaytn.com/Klaytn_Token_Economics_and_Governance_Paper_V1.01.pdf⁠

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.