Monthly CodeChain TechTalk — October 2019
We’re excited to share that we have held our first edition of open CodeChain TechTalks last Wednesday! CodeChain TechTalks are small weekly seminars we are hosting for a small group of engineers interested in blockchain technology. We have been keeping it small as we could not afford hosting bigger seminars every week. However, as we felt that more and more developers were curious to learn and share the latest and coolest technology in the blockchain field, we have decided to open the tech talks to the public and organize monthly meetups to further nurture the Korean blockchain developers community.
Our first TechTalk was terrific with over 30 developers who got engaged in the discussions and Q&A sessions. Some feedback even helped us revisit few details of our own design. This is the kind of outcome we wanted to see in the meetups — very rare in the Korean blockchain industry where most meetups are held purely for coin marketing (dumping) purposes — and we have indeed succeeded.
Here is an overview of the topics covered during the tech talk.
1. CodeChain Staking System: a tale of two tokens (by Kwang Yul Seo)
We have seen a rise of proof of stake (PoS) consensus mechanism. Among these are EOS, Tron, Cosmos, Tezos and many others. At first glance, the attraction of holding these coins looks clear because you can earn 5–15% annually on your holdings by just staking your coins.
However, with keen eyes on the staking reward mechanism, you will realize that staking rewards are illusory. Staking rewards are created through inflation and staked tokens are rewarded by diluting not-staked tokens. If everybody stakes their coins, there is no net profit at all!
CodeChain explored the design space in search of a better staking system without these pitfalls. The staking system of CodeChain is different from existing PoS chains in that it has two native tokens: stake tokens (CCS — CodeChain Stake) and fee tokens (CCC — CodeChain Coins). As the names imply, CCS is used for staking and for the network governance.
The rule is clear and simple. CCS holders earn transaction fees (fee tokens) spent on the network regardless of the staking. Decoupling of fee tokens from staking tokens eliminates the need for staking reward through inflation that causes a lot of confusion. CCS tokens have low liquidity, but in exchange, its owners are guaranteed profits for providing a more secure and stable network.
2. Vault language (by Joonmo Yang)
We all know that Bitcoin’s script and EVM are really difficult to use. Sometimes one has to go through an audit process, which is not even guaranteed, to check whether the program they have written has no flaws. Thus, many organizations and research groups are developing newer and easier-to-use smart contract languages.
CodeChain also had its limitations when it came to its script language, and this is the reason why we have developed Vault, a smart contract language for CodeChain. It is inspired by Bitcoin’s miniscript, as we wanted Vault to be as highly composable as miniscript. The compiler basically creates a lock script and an unlock script whenever we input a UTXO condition. One can create complex multi-sigs or HTLC scripts with just one line of code! With Vault, you can express almost all the conditions you can imagine using thresh, which is an expression for m-of-n conditions.
3. Snapshot Sync (by Seongchan Lee)
The current CodeChain implementation requires new nodes to replay the entire history of the blockchain from the genesis and synchronize with the best chain’s state. This initial sync process uses a large amount of resources. As the blockchain grows constantly, the required resources will grow constantly as well.
Parity’s Warp sync and Go Ethereum’s fast sync were proposed to address this problem. However, they provide no incremental way to validate the state along the synchronization process. A node may provide an invalid state, allowing attackers to waste network bandwidth.
Snapshot sync in CodeChain is designed to reduce the resources used during the initial block synchronization process, such as time, CPU, network bandwidth, disk space, and disk I/O. A snapshot consists of multiple chunks with merkle proofs so that a node can easily verify if a downloaded chunk does indeed belong to the state tree.
4. Randomized leader election in Tendermint using VRF (by Seonpyo Kim)
CodeChain is a network that operates under the Tendermint consensus algorithm. It’s simple, and we believe it is, so far, the only consensus algorithm that has been proven in the production level.
However, Tendermint has its own limitations. It rotates through the validator set, i.e. block proposers, in a weighted round-robin fashion. Leaders can be subject to targeted denial-of-service attacks because attackers can predict exactly who will be the next proposer and direct all their bots to simultaneously attack that proposer. Bitcoin is not susceptible to such attacks because it is impossible to predict the next block proposer before the block is propagated to the network. Only the node that solved the proof-of-work problem knows that it can propose a block and other nodes in the network can confirm that the proposed block is from a valid block proposer by verifying the nonce.
To prevent such DoS attacks in Tendermint-based networks, validators can change the network structure, but this approach does not fundamentally solve the problem. To mitigate the possible denial-of-service attacks on Tendermint, we need to introduce randomness into its leader election mechanism so that attackers cannot predict the next proposer. In our roadmap, we are planning to adopt a verifiable random function (VRF) to assign leaders to round numbers in a less predictable way. The benefits of introducing VRF for enhancing Tendermint are as follows:
1. The network gets more secure against seed attacks
2. It also becomes less vulnerable against sybil attacks as the probability to be elected as leader is proportional to the stake
3. VRF is going to be used when validating block proposers so it does not affect the safety and liveness of the Tendermint consensus.
