A Glance at Friday Consensus Mechanism
We prefer the term “consensus mechanism” over “consensus algorithm”. In the sense of decentralized platforms, we believe it is more appropriate to treat “consensus” as a system or a mechanism of many algorithms rather than just one.
In this post, we will discuss the direction we are taking in building the Friday Consensus Mechanism. Needless to say, we will tweak our ways by conducting extensive experiments and research, and this may lead us to bigger changes. But it should be worthwhile to share what is currently on our mind.
Decentralized Platform Trilemma
There is a well-known “trilemma” in decentralized consensus mechanisms. That is, it is infeasible to achieve scalability, security and decentralization simultaneously. However, we can always set the direction we want to take and find the right compromise. Even though all three objectives cannot be fulfilled at the same time, we can advance each facet through continuous research and development.
Our Goals
The Ethereum network has faced some scalability issues, which led to countless new platforms flaunting their remarkably scalable networks with high TPS figures. However, scalability is not as significant unless the platform is used extensively, to the point where its throughput becomes an issue.
Rather than trading off other aspects just to enhance scalability and thereby increase the platform’s throughput, we want to strike a balance among the said three objectives. Of course, we will continue to strive for higher scalability.
After much thought and discussions, we have decided to focus on the following goals first:
- Shorter block time for a shorter wait
- Near-instant finality for a reduced processing time
To achieve the above, there needs to be an appropriate balance between scalability and finality. We are also conducting R&D for the following objectives, although they are not our top priority, to better decentralization without sacrificing scalability.
- Application of randomness for participation of more validators
- Reward system that prevents concentration of voting power and evenly distributes delegation
Difficulties of Designing a Consensus Mechanism
It is quite difficult to design a brand new consensus mechanism because all sorts of parameters are intricately tied to one another. Modifying one parameter entails taking into consideration how it would affect others. Otherwise, the platform may not operate properly or even break down at any given moment due to an unexpected event. Working on such theoretical aspects is definitely a challenge, but we also need to carry out various experiments to understand the current state of the global network and deal with different situations we may come across along the way.
That is why building a new consensus mechanism and ensuring the platform is stable and does not break down requires much time and thorough verification. The good news is, not everything needs to be applied all at once — adjustments can be made separately and in small doses. We plan to apply new technology on a testnet first, experiment and stabilize the technology, and then implement relevant changes on the mainnet.
More on Consensus Mechanism
We plan to elaborate on the following topics regarding consensus mechanism in our upcoming posts. In addition, we will make time and effort to communicate with you whenever anything interesting comes up mid-development.
- General structure and flow of the Friday Consensus Mechanism
- PBFT and FBFT / HotStuff — mesh communication network vs. star communication network and our choice
- Application of VRF and BLS signature scheme
- Possible implementation of DAG structure
Thank you for your interest and support.
