What problem are you solving?
Describe the pain point. What are the shortcomings of current solutions?
Proof of Stake achieves the consensus through a voting system which is implemented through a BFT protocol. The well-known BFT protocols are Tendermint, Hotstuff, PBFT which are bi-modal approaches: the protocol typically consists of a simple normal path where a leader makes proposals and everyone votes. When the normal path fails, the protocol switches to a much more complicated fall-back mode typically called a âview changeâ. The view change protocol must essentially embed a âfull-fledgedâ consensus that offers both consistency and liveness. As such, the complexity of classical protocols arises due to the view change.
In this work, we propose a new approach that could overcome the limitation of view change approach.
What is our solution?
Why is it a good idea? Whatâs new about what youâre doing? The more details, the better. Sketches, mockups, demos, prototypes, videos, pictures - it all helps community members get excited as you are.
In the case of network traffic peaking, some nodes could commit a block, while other nodes fail to reach the commitment. The idea is on the network, nodes will maintain multi chain view in which the committee could choose the longest branch as a finality chain. For block aggreement, We use a modified pBFT protocol consisting of 3 phases.
After commit phase, the block is inserted into the multi-view graph in which there will be algorithm to select the block as final and the longest chain for next propose phase. The detailed spec will be announced later in the comment section.
Who are you?
Introduce the project team members (schools, jobs, projects, github, twitter, blogs, etc.) and any similar work youâve done.
We consist of 1 researcher and 5 enginneer at Incognito Scalability team (@0xkumi, @hungngo, @jason, @lam, @hyng, @duybao). Our research interests lie in building efficient blockchain that can scale to thousands of node.
Why do you care?
Tell people why youâre passionate about your privacy project and committed to making it happen.
An efficient BFT protocol which takes into account the following conditions is still a challenge for blockchain community:
- The adversary can arbitrarily delay messages sent by honest processes.
- Proposer can be byzantine.
- The network traffic delay is unpredictable.
To design a new consensus that could solve these issues more efficiently than the view change approach is an interesting problem.
Whatâs your plan? Whatâs your schedule?
There are 3 parts to this plan:
- Building consensus v2 (new consensus) module
- Refactor all other packages to use multiview
- Run multiview with consensus v1 (old consensus)
- Run multiview with consensus v2
Schedule (total 9 months), starting from Feb 15:
- Writing protocol detail spec
- Implement consensus module with multi-view chain
- Refactor other package using multi-view chain
- Testing and Launch testnet/mainnet
- Working on byzantine problem
- Testing and Launch testnet/mainnet
Milestone | Deadline |
---|---|
Development Consensus v2 | |
Development MultiView Protocol | |
Integration with other core features | |
Deploy multiview for consensus bft-v1 on testnet | |
Deploy multiview for consensus bft-v2 on testnet | |
Deploy multiview for consensus bft-v1 on mainnet | |
Deploy multiview for consensus bft-v2 on mainnet | 30 Oct |
How do you validate your work?
In the current network, when fork situation occurs, the fork block will be revert and network could be stuck for a long time. With this multi-view protocol, we allow fork block to insert into chain, and the block proposer selects the longest branch to continue. Hence, block fork will not make the network stuck. We expect to experience no delay during fork situation.
Whatâs your budget?
A simple breakdown lets community members know youâve thought things through and have a workable plan, so they can trust you to use funds wisely.
The project will be undertaken by 6 engineers for 10 months:
Feb-2020
Resource | Cost | Resource | Monthly Cost |
---|---|---|---|
Incognito Protocol Researcher - @dungtran | 2000 PRV | 1 | 2000 PRV |
Incognito Protocol Platform Engineer - @0xkumi | 2000 PRV | 1 | 2000 PRV |
Incognito Engineer - @lam | 1000 PRV | 1 | 1000 PRV |
Incognito Engineer - @hungngo (1/2 resource) | 1000 PRV | 1 | 500 PRV |
Incognito Engineer - @duybao (1/4 resource) | 2000 PRV | 1 | 500 PRV |
Incognito Engineer - @hyng (1/4 resource) | 1000 PRV | 1 | 250 PRV |
Subtotal | 6250 PRV | ||
Total (x 1 months) | 6250 PRV |
March-April 2020
Resource | Cost | Resource | Monthly Cost |
---|---|---|---|
Incognito Protocol Researcher - @dungtran | 2000 PRV | 1 | 2000 PRV |
Incognito Protocol Platform Engineer - @0xkumi | 2000 PRV | 1 | 2000 PRV |
Incognito Engineer - @lam,@hungngo,@hyng | 1000 PRV | 3 | 3000 PRV |
Incognito Engineer - @duybao | 2000 PRV | 1 | 2000 PRV |
Subtotal | 9000 PRV | ||
Total (x 2 months) | 18000 PRV |
From May-July 2020
Resource | Cost | Resource | Monthly Cost |
---|---|---|---|
Incognito Protocol Platform Engineer - @0xkumi | 2000 PRV | 1 | 2000 PRV |
Incognito Engineer - @hungngo,@hyng | 1000 PRV | 2 | 2000 PRV |
Incognito Engineer - @duybao | 2000 PRV | 1 | 2000 PRV |
Subtotal | 6000 PRV | ||
Total (x 3 months) | 18000 PRV |
Is there an existing conversation around this idea?
To the best of our knowledge, Streamlet protocol is one of the approaches attempting to solve this problem.