IBFT Proposal

[drequinox]

In the light of the previous discussions held on the matter, and recognition of the fact by all members that a minimum viable BFT consensus protocol is required and should be agreed between all EEA members. I am suggesting IBFT for the reasons listed below.

• IBFT, so far, is the most used protocol for Enterprise Ethereum clients.
• IBFT is regularly used in production for major projects without any difficulties.
• Some enterprise-grade tooling is also built around IBFT, which is an indication that IBFT has a more extensive user base.
• IBFT is implemented (at least in its original EIP 650 form) in all EEA clients namely Quorum, Pantheon and Autonity.
• IBFT adoption for V4 of EEA specification will lead us quickly to the interoperability testing using a BFT protocol and subsequent certification.

It is suggested that we decide IBFTs current implementation as a minimum viable protocol for consensus, with some enhancements (not mentioned in EIP 650). Below we list the number of improvements

• Quorum size calculation formula changed to 2n/3. Note that even though this is not a general issue with IBFT. It was reported in a specific case 'dynamic validator with non 3f+1 configurations', e.g. six node scenario which could lead to safety issues; Quorum has implemented this generally for all scenarios.
• A small number of issues related to IBFT has been reported in the past or found during testing, which were analysed thoroughly and has either been fixed or a detailed explanation has been provided on why those scenarios are unlikely to occur.

We are in favour of any enhancements proposed which can lead to a more robust protocol. Therefore, in conclusion, I suggest that for the reasons listed above, we should adopt IBFT, and after V4 milestone, we can look into enhancements and evaluate other algorithms.

I am submitting this proposal as suggested by @kubasiemion and through the support of @jimthematrix and @kubasiemion at F2F.

[saltiniroberto]

The PegaSys position on this is that the MVP must include at least the three base changes presented at the EEA F2F as without them the protocol does not guarantee the basic safety and liveness properties of blockchain consensus protocols. These three changes are:

1. Finality achievement improvement by (1) changing the threshold for commit seals and prepare messages from 2f(n)+1 to ceil(2n/3) and (2) verifying the commit seal signature included in Commit messages before accepting Commit messages
2. Avoid deadlock situations by adding Prepared-Certificates and Round-Change-Certificates to Round-Change and Pre-Prepare messages respectively
3. Improve block propagation by requiring nodes to sync with peers if they receive a BFT message for a height higher than the current one.

[drequinox]

I raised this proposal in response to requests from various users who have implemented IBFT and would like to see this as a standard adopted for enterprise Ethereum clients. Since IBFT is the most used protocol so far in Enterprise Ethereum world, I believe this fact makes IBFT a reasonable choice, at least for V4. Any future enhancements, including the above, won’t impact the running networks. Our preference is to describe a consensus protocol in sufficient detail and evaluate it against the defined properties, then ensure that the protocol meets those requirements. Once we have that, only then the implementation of the protocol can start. One approach is to write TLA+ spec of the algorithm and verify it before we implement it in the clients.

[ajsutton]

IBFT is implemented (at least in its original EIP 650 form) in all EEA clients namely Quorum, Pantheon and Autonity.

It should be noted that Pantheon/Besu does not have full IBFT support. It is able to import IBFT blocks, but doesn't have any support for block creation so can't act as a validator. Work was stopped on IBFT support due to the problems Roberto mentioned above.

As I understand it, fixing the issues Roberto mentioned cannot be done in a backwards compatible way so would affect running clients and require a hard fork.

[chaals]

("All EEA clients" is probably more than Quorum, Hyperleger Besu (formerly known as Pantheon) and Autonity, unless we want to restrict the term to clients that conform to the spec, which would actually be the ideal definition but there are issues in the spec and clients still that might mean nothing is ready to claim 100% conformance)

[drequinox]

I think the best approach now is to define the requirements and specification of the protocol that we need and then evaluate various protocols against our requirements and choose the one most suitable.