Closed drequinox closed 4 years ago
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:
2f(n)+1
to ceil(2n/3)
and (2) verifying the commit seal signature included in Commit messages before accepting Commit messagesI 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.
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.
("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)
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.
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.
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
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.