2020 Goals for the xBFT subgroup

[kubasiemion]

We have been asked by the board to commit to deliverables and deadlines in 2020. Can we articulate anything?

[shapeshed]

I feel we need to agree on whether we can agree on a single xBFT algorithm or seek to place multiple xBFT algorithms in the spec. If it is a single algorithm we could commit to providing a formal specification for that algorithm, along with implementation details. If it is multiple we could seek to specify the criteria for selection and provide a formal specification and implementation guide for each of the algorithms.

The former is clearly preferable but given that teams are taking quite different paths I fear it might be hard to agree on a single algorithm that all clients implement.

[robertusr]

A logical approach suggested by members of the task force previously was to first define definitions and agree on requirements, then perform an assessment of consensus algorithms against the requirements to see which ones satisfy the requirements. Following that, agree on which algorithm(s) should be documented in a formal specification.

In terms of a skeleton of timelines, something like this perhaps:

Q4 2019 Finalise draft of definitions Q1 2020 Finalise draft requirements Q2 2020 Assessment of algorithms against requirements and agree on which algorithm(s) to move forward with to specification stage. Q3/Q4 2020 Document specification of agreed algorithm(s)

This timeline would need wider review and input from other members to see if it is felt this is realistic and achievable, or if the goals can be achieved sooner.

[kubasiemion]

I feel we need to agree on whether we can agree on a single xBFT algorithm or seek to place multiple xBFT algorithms in the spec. Good point. I would rephrase it as: if EEA decides on implementing Tendermint in an interoperable manner, is there a further role for this Task Force and is there a need for another protocol?

[bobsummerwill]

NB: For the EEA Launch event, one of our demos was intended to be using Quorum in Tendermint mode.

Tendermint was implemented in HL Burrow (previously Monax, previously ErisDB) in 2014. There has been Tendermint support in Parity-Ethereum for several years. And there is Tendermint support in Ethermint as well.

The only reason that IBFT happened rather than Tendermint is because AMIS did the work of integrating it first into Geth (PR never merged) and then into Quorum (PR was merged) and of writing the EIP (which is still not accepted 2.5 years later):

https://github.com/ethereum/EIPs/issues/650

It would certainly make a LOAD of sense to me for "Tendermint in an interoperable manner" to be chosen as a sensible approach here.

Tendermint/Cosmos's reaction to IBFT was "Why did they do that? They should have just used Tendermint" to which the response was "Well - if you had done the work in 2016/2017 then it would never have happened".

Aside - contribution of https://github.com/tendermint/tendermint into Hyperledger would make this choice a lot easier too.

[kubasiemion]

Ok, a lot has happened in the last six months, and it is time to update our immediate goals. As discussed, we should have:

• Implementation documentation of Quorum update published
• New Quorum code released,
• Theoretical paper published and then (hopefully) the Besu implementation. Imran, Roberto, could you comment on this?