In this post we want to explain to you about the overall architecture of Klaytn. Klaytn is a project that started as a fork of Ethereum in June 2018. It has been an open source project since the mainnet launch in June 2019, and is accessible on Github. The complete development process of Klaytn takes place in the repository, so feel free to drop by when you want to know more about it 😀 We also welcome code contributions!
First, here is a complete picture of the Klaytn architecture.
The following sections have short descriptions of each of these layers in more detail.
Application Layer
The application layer includes modules that run on top of Klaytn. This layer does not have anything to do with the actual blockchain core. Currently, it only consists of the contracts module, which contains the smart contract code for various integral purposes like Klaytn’s L2 ServiceChain and mainnet interaction or precompiled contract usage examples. To check out all standard smart contracts supported in the Klaytn ecosystem, please refer to klaytn-contracts.
Wallet Layer
The Wallet Layer includes modules related to wallet management on the Klaytn nodes themselves. With the wallet function nodes can manage private keys and give signatures on transactions, which is useful when individuals are operating nodes. Wallet management is tricky business, beware of vulnerabilities when you are using the same wallets to manage multiple nodes. Unlike Ethereum and other chains, Klaytn allows you to store multiple private keys attached to a single account giving developers to manage accounts through Role Based Access, or on-chain multi-signature account control. Key management and transaction signature features have changed to support this functionality. For more details on the newly added keystore v4, please refer to KIP-3 and to understand the Klaytn Account Model see our documentation here.
Interface Layer
The Interface Layer includes modules related to node execution and API calls.
- The console module includes the functionality to execute JSON-RPC APIs in console mode.
- The api module provides features to read data or execute transactions using JSON-RPC APIs. In this module we have recently added support for the ETH namespace in an effort to make development in the Klaytn ecosystem easier for the community, you can read more about it here.
- The client module provides a go-client required for using JSON-RPC API.
- The node module consists of two modules: cn and sc.
- The cn module is related to the main chain Core Node operations.
- The sc module includes functionalities for Klaytn’s L2 Service Chain solution.
- The cmd module includes various executables(abigen, homi, kbn, kcn, ken, kgen, kpn, kscn, ksen, kspn) provided by Klaytn.
- The params module contains logic for the system parameters such as computation cost, gas cost, governance parameters, KLAY units (peb, ston, KLAY, MKLAY etc.), and other chain parameters.
Execution Layer
The Execution Layer is where the core blockchain functionalities sit. In the blockchain/types module, data structures such as account, transaction, block, receipt are stored. Klaytn has designed and implemented a new account and transaction model for higher performance and scalability. For more details, please refer to Klaytn Docs.
- The blockchain/vm module is where the Ethereum Virtual Machine (EVM) logic is implemented. Klaytn has introduced the concept of computation cost in order to maintain 1-second block creation time; this implementation ensures that the execution time of a transaction will not overrun the 1-second block time.
- Additional precompiled contracts have also been put in place to support account/transaction models that were changed in the EVM. You can find information on these newly added precompiled contracts in Klaytn Docs.
- In the blockchain/state module, there are functionalities to maintain and query state tries in the memory to execute transactions.
- In the work module, there are features to create blocks after sorting transactions from the transaction pool
- In the blockchain module, there are actions for validating transaction pools and blocks and maintaining the latest blockchain data.
- Finally, the event module has features to subscribe to event logs in real-time.
Governance Layer
The Governance Layer is where the governance features are implemented.
- The governance module includes features such as: block, validator add/remove, gas price change, and reward distribution ratio change.
- The reward module has Klaytn’s reward system. The block creators don’t earn the entire block reward, instead a portion of the rewards go to the block creator and some will be distributed to Klaytn’s various ecosystem funds for the ecosystem’s growth in accordance with the ratio set by governance. For more information, please refer to Funding Structure.
Consensus Layer
The consensus layer provides three possible algorithms: PoW, Clique, Istanbul BFT. Klaytn mainnet uses the Istanbul BFT algorithm, while the first two contain the exact same code originally forked from Ethereum and are not currently being maintained by Klaytn.
Cryptography Layer
The Cryptography layer includes various modules related to cryptography. Cryptography is an integral part of the blockchain system, it is used for merkle hashing and fast data verification as well as transaction signing and transaction authentication. Klaytn uses a safe, and widely verified cryptography system based on the ECDSA secp261k1 curve: same as Ethereum, Bitcoin and others blockchains.
Synchronization Layer
The Synchronization Layer provides a data fetcher, and a downloader for syncing with other nodes along with chaindatafetcher, which is used to stream block data effectively.
- The fetcher module is used when blocks are fetched one by one after the latest blocks have been synced.
- The downloader module works when there are many blocks to catch up.
- Lastly, using the chaindatafetcher allows you to subscribe to block data easily via kafka every time a block is validated and added to the node.
Network Layer
The Network Layer enables grpc, p2p, rpc network communications. The components of this layer uses the code forked from Ethereum without active maintenance on the part of the Klaytn Team. Compared to other layers, the Network Layer has been validated and optimized over a long period of time. It requires a long-term approach instead of immediate improvements to its performance.
Storage Layer
The Storage Layer provides the data structure and related features to store the blockchain data in the disc. We have implemented an interface to support various types of database using the database module. Currently, levelDB is being used.
- The statedb module uses the Merkle Patricia Trie to store blockchain states as well as various cache structures to reduce disc access.
- The rlp module uses serialization to store data structures like account, transaction, blocks in the disc. For a more detailed explanation of RLP, please refer to Ethereum Wiki.
In this article, we introduced the various modules in Klaytn in layers for developers and the community to better understand what is going on under the hood of the Klaytn blockchain. To further this understanding, we will go over each module in more detail in future posts. If you are curious about a specific module, please let us know in the comment section. Thank you!
