[Consensus] Twins: BFT Systems Made Robust

[Olshansk]

Objective

Implement the Twins Test originally authored by the Facebook Novi team on top of HotPOKT to guarantee the safety against Byzantine attacks as well as capture bugs during development and DevNet deployments, and prior to TestNet.

Origin Document

The original paper can be found here.

Ths Twins Test generates Byzantine unit tests that simulate 3 types of behaviour:

• Leader equivocation
• Double voting
• Losing internal state

This was implemented atop of DiemBFT, but the same specification can be applied to any other BFT algorithm. Intuitively, since DiemBFT and HotPOKT are both Hotstuff-based algorithms, it should translate well.

Additional Resources

1. As a potential point of reference, another open-source implementation of the Twins Test atop a Hostuff implementation in Go can be found here.

2. The implementation of the consensus module can be found here with the existing unit tests accessible here.

3. The consensus specification is available here.

Goals / Deliverables

• [ ] Implementation: Library / framework implementing the Twins Test around HotPOKT
• [ ] Tests: A few unit tests for a basic LocalNet
• [ ] Documentation: Documentation (text and/or diagram) of the Test's functionality, source code structure, and implementation.
• [ ] Follow up work: Github issues and/or milestones + TODOs for future work needed for exhaustive Byzantine behaviour testing.

Non-goals

• A fully functional Twins Test on a remote DevNet environment
• Exhaustive testing of all possible Byzantine combinations

Creator: @Olshansk Co-Owners: ???

[Olshansk]

AptosBFT (which is now live) is based off of DiemBFT, so that means that the Twins BFT approach described in the paper is being used to validate BFT algorithms in production and covers these scenarios:

1. leader equivocation
2. Double voting
3. Losing internal state such as forgetting 'locks' guarding voted values

@DragonDmoney I know you've mentioned you considered looking at this ticket of work, so lmk if you still plan on doing so.

---

In addition, just wanted to share a random idea I had as our team starts working on improving consensus and building peer discovery there are lots of different scenarios we need test for. Aside from byzantine / non-byzantine actors, we need to account for different permutations including the following state transitions:

• New (full) node comes online (from genesis) -> syncs to network state
• New (full) node comes online (from snapshot) -> syncs to network state
• Staked validators falls behind -> catches up
• Staked validators falls behind -> does not catch up
• (Full) Node is staked to be a validator -> after catching up to network state
• (Full) Node is staked to be a validator -> before catching to network state
• (Full) Node is eclipsed -> before / after catching up to network state
• Stake Validator is eclipsed -> before / after catching up to network state
• number of new blocks created in between each step can vary from 0 to N

This is only a small list that I came up with off the cuff related to peer churn & discovery, and there is a lot more when it comes to Consensus attacks and P2P attacks. @DragonDmoney, I know you've been looking at AI & natural language lately, so I think there's an opportunity to use something like GPT-3 and use transfer learning to train a model that'll create deterministic test cases for us which we will later automate.

Chaos testing and penetration testing are great, but if we can get a couple hundred deterministic scenarios defined for us by BFT AI (name is still a WIP) without needing to do the manual work, that would be 🔥🔥🔥🔥