Although Klaytn and Ethereum are two separate, independent blockchain networks, they share a lot in common mostly because Klaytn forked Ethereum source code. From the way they encode transactions to the elliptic curve they use when signing things (SECP256k1 in case you are curious), Klaytn and Ethereum do things similarly.
Perhaps, it is easier to list how they are different. Here’s a list of things Klaytn and Ethereum handle differently. FYI, the list is not exhaustive; if you have more things to add, please leave a comment down below
This causes transaction incompatibility between Klaytn and Ethereum. While Ethereum users choose gas price for their transactions, Klaytn charges flat rate and does not allow users to indicate their own gas prices. For all transactions in Klaytn, gas price is set to 25 ston (0.000000025 KLAY), and this value does not change unless Governance Council (GC) decides to change.
The reason behind of this fixed gas price is to remove unnecessary fee auctioning. In Ethereum (and many other blockchains), miners tend to pick transactions with higher gas price to maximize their profits given with limited throughput and rather long block generation interval. In order to expedite transactions, Ethereum users write down higher fees because they know miners will pick those high-paying-transactions.
Well, the same does not apply to Klaytn simply because:
Klaytn’s performance is sufficient for a large volume of transactions (4000+ TPS)
Klaytn block generation takes place for every second (1s block interval) so users won’t wait long even if they miss the upcoming block
GC members do not respond much to fees they collect because it only takes insignificant share of block rewards
We only charge fees to prevent spams, not to earn profits. To this reason, we use fixed gas price.
Unlike Ethereum, Klaytn runs a variant of PBFT algorithm to make consensus. Running BFT has some pros and cons.
Pros: faster, efficient consensus Cons: network has to be synchronized
Obviously, if your network has to be synced, it is difficult to achieve decentralized consensus. Since general BFT algorithms require at least two-third of all nodes to be involved to come to an agreement, forming a large network will suffer from significant network overhead.
Klaytn uses a workaround: instead of requiring all nodes to participate consensus, only a random subset of nodes is chosen to run consensus. How do we pick ‘random’ though? There is something called Verifiable Random Function (VRF) which is very handy when you need to generate a random value that can be verified cryptographically. For every block generation, Klaytn picks a random number using VRF, identify a group of nodes — called a committee — to run BFT. The size of a committee is sufficiently small to output high TPS. Currently, Klaytn handles more than 4,000 transactions per second with 50 GC nodes.
Writing a blockchain application without an SDK is … painful. It is doable, but only few people like it. To help developers build blockchain-based applications, Ethereum community provides a suite of SDKs including web3.js.
Klaytn has its own SDK suite: caver-js and caver-java. Since Klaytn transactions are not 100% compatible with those of Ethereum, it is recommended to use Klaytn SDKs when you use Klaytn.
While Ethereum only has one node type, Klaytn has multiple node types where each serves different purpose. Here’s a brief description of three main node types:
1. Consensus Node (CN)
CNs decide blocks by running consensus. Only GC members can run CNs, and, thus, form a private network of CNs called Consensus Node Network (CNN). Together with multiple PNs (at least two), a CN forms a Core Cell (CC).
2. Proxy Node (PN)
The primary role of PNs is to protect CNs. As mentioned above, a CC is composed of a single CN and two PNs. In a CC, PNs function as a bridge between a CN and the network outside of CC; they deliver transactions sent from Endpoint Nodes (ENs) to the CN they protect, and propagate blocks (downloaded from the CN) to ENs they are attached to. This provides effective defense to CNs from adversarial attacks such as DDoS.
3. Endpoint Node (EN)
ENs serve as endpoints for Klaytn network handling RPC API requests and processing data sent to and from Service Chains. ENs continuously download blocks and send transactions from/to PNs. ENs form a peer-to-peer network called Endpoint Node Network (ENN). Unlike CNs, anyone can run an EN and join ENN, effectively running his/her own endpoint.
