/w=3840,quality=90,fit=scale-down)
Hello everyone, welcome to Harmony DayOne event. Harmony as the fast and scalable blockchain has been getting lots of attention and our ecosystem is growing very fast this year. Here I would talk about two of the key projects on the blockchain protocol side. It's 1s finality and resharding. 1s finality brings speed to harmony blockchain and resharding guarantee the security of it. We strive to be the infrastructure for the future of Web3 and believes that Web3 can achieve same if not better UX than Web2.
/w=3840,quality=90,fit=scale-down)
Web3 should as as fast as web2. Why would we call it Web3 if it's worse than Web2 in terms of UX? It's not gonna get enough traction is the UX is bad. Harmony support smooth Web3 experience through extreme low-latency transaction and high Throughput. Our current mainnet finalize txns in 2 seconds and soon we will achieve 1s finality. Study shows that 47% of consumers expect a web page to load in 2 seconds or less. 40% will abandon a website that takes more than 3 seconds to load. Having 1s finality is a must for Web3 to get mass adoption.
With 4 shards, our network throughput can scale to the need of current and future open economy's activities. With all the performance, we also guarantee strong security through the technology of EPoS, resharding, secure randomness and consensus etc.
/w=3840,quality=90,fit=scale-down)
1s finality will make Dapps on Harmony as fast as those Web2 applications. Well the question is how is that possible? Our unique designed consensus FBFT can be partially-synchronous on the quorum agreement process which means the finality can be as fast as the network and the nodes process the blocks. Most other BFT-based blockchain runs synchronously and waits for a long block time such as 5s (in cosmos) due to the concern of failure of reaching quorum. We don't have the concern thanks to the synchronous view change protocol which will switch the leader if quorum fail to reach. Basically, the synchronous part is moved from consensus to view change so that consensus can be as fast as the network allows.
We also did extensive optimization on code efficiency on the node level such as signature aggregation and pipelining to make the node run as efficient as possible. On the protocol level, we are also innovating on the way signature are collection so that no time is wasted on waiting for redundant signatures.
/w=3840,quality=90,fit=scale-down)
To briefly talk about a few technologies that we deployed to make finality as fast as 2s. Pipelining is one of them which allows the leader to optimistically start the proposal for new block while waiting for the rest of the signature after 2/3 of the commit signatures are collected. This saved us around 0.5s when we brought down the block time from 5s to 2s.
To achieve 1s finality, one of the main protocol change is to led the leader only wait for 2/3 of the commit signatures and let the rest of the 1/3 signatures to be collected during the quorum for next block. This way, signature collection for the 1/3 commit won't block the consensus anymore, and it shouldn't because 2/3 commit is enough to reach quorum for the consensus. The only reason to collect the last 1/3 commit is to make the chain signed by more validators so it's heavier in staked signatures.
/w=3840,quality=90,fit=scale-down)
Resharding is the last milestone which allows our network to go fully decentralized and gain the full security property from the protocol design. Our resharding is based on secure randomness protocol which involves VRF and VDF. In fact, we already deployed VRF on mainnet which is generated on very block and usable by all Dapps developers to build secure randomness Dapps. Our resharding is based on Bounded cuckoo rule which only requires a constant number of validators to shuffle around the shards, causing minimal burden to our validators, and for sure, it guarantees security against join-and-leave attacks or slowly adaptive attackers trying to overtake a single shard.