Monthly CodeChain TechTalk — January 2020
It’s been great to kick of the year with an awesome tech talk session hosted by CodeChain. We shared the results of our latest implementations with nearly 50 developers from major Korean IT companies who joined the meetup. Again, the talks were followed by great discussions and questions. Here is the recap.
Tenderland: randomized leader election in Tendermint
Tenderland is a solution to the issue that, in Tendermint, a malicious attacker can attack the network by exactly predicting the next block proposer. It is basically about adding randomness to the leader election process while keeping the stake-proportional leader election property. It also assures that proposals from other validators be verifiable. We combined Tendermint consensus algorithm and Algorand’s sortition algorithm to construct Tenderand.
During the talk, Seonpyo walked us through all the tests the team had gone to prove our implementation of Tenderand. He concluded that Tenderland proved to have the random quality comparable to “dev/urandom”’s, which means it’s effective in defending against DOS attacks in public blockchains.
For more details, follow the links:
CodeChain Foundry
We announced CodeChain Foundry, a framework for building blockchain applications. Its goal is to allow developers to easily create custom blockchains from scratch that can natively interoperate with other blockchains.
Foundry is characterized by its built-in support for:
- Scalable Consensus (Tendermint)
- Composable Module System
- Inter Blockchain Communication (IBC)
- Light Client
We are aiming to have an initial version by the end of February, so stay tuned!
VeriSync: a fast and verifiable sync method
VeriSync is the fruition of the snapshot sync implementation proposed last year. It is a fast and VERIfiable SYNC method for blockchains and its main idea is to split a state tree with verifiable chunks.
The talk included the design and implementation details as well as benchmark test results. While the time required for the full synchronization is 10h 40m, our snapshot synchronization took 3m 46s on the same setting, so we can say we got 169x faster in time/efficiency for the initial setup. The database constructed with the full block synchronization required 29GB of space, and the initial database constructed with the snapshot synchronization required 2.8MB of space. Note that these numbers will get even better as the blockchain’s size grows, so the numbers will be far better than now as time goes on.
