Prototype CometBFT (formerly TendermintBFT) as the finality subprotocol.

[nathan-at-least]

The current draft aims to be generic wrt the finality subprotocol because (a) we want to ensure the design is modular and does not have hidden/unexpected dependencies on the specific subprotocol, and (b) we want to have agility in selecting a subprotocol or changing the subprotocol down the road.

However, the risk of being too generic early on is that we overlook requirements or complexities that come from a real world concrete protocol.

So, let's "prototype" Tendermint as the finality subprotocol to validate if the TFL design is at least coherent and practical, and then if that works, we can generalize from there if we need to consider other subprotocols.

Pros/Cons

Benefits:

• We help ensure the TFL design is practical and accounts for unexpected implementation complexities.
• The result is that much closer to being implementable as a prototype or productionized for the Zcash network.
• Because Tendermint is already designed with "app chain modularity" in mind, it may be a good fit for a subprotocol.

Drawbacks:

• This may introduce unnoticed dependencies on the particulars of Tendermint (which is why we originally aimed to be subprotocol-agnostic in the TFL design).

Next Steps

We need to resolve what the requirements on the Subprotocol Interface are for tracking PoS bookkeeping:

1. Investigate if ABCI or ABCI++ explicitly accounts for this entanglement of a "generic application" vs PoS bookkeeping.
2. If so, investigate if ABCI or ABCI++ can work, out-of-the-box, as an instance of one side of the Subprotocol Interface.
3. If not, examine what requirements Tendermint places on appchain logic in order to correctly manage PoS state.
4. If that also fails, hunt for other modular protocols to try this approach of plugging in a concrete protocol.

[daira]

I do not think this should be in Implementation Phase 1; I think we should use Streamlet for that phase. It definitely isn't feasible for the current Implementation Phase 1 due date of October 27th. I will put this in "Design and Implementation Phase 2" for now.

Also, it's ambiguous to me whether this means to prototype Tendermint in the simulator (which might be difficult, since the simulator is a discrete event simulation and not a "real" implementation), or as a change to zcashd or Zebra, or in some other new codebase. The milestone scoping comment would apply to any of these options.

[nathan-at-least]

It looks like CometBFT should be the priority, since I gather than Tendermint is compromised by a Trademark and unreliable or malicious organization.

Here's an intro post about CometBFT.

[nathan-at-least]

Also, it's ambiguous to me whether this means to prototype Tendermint in the simulator

Oh, I filed this a while ago, and my focus was on starting a proof-of-concept prototype as soon as possible, so this would be a functional prototype, not necessarily a simulator. So to start a prototype, we'd need at minimum #70 (which is already a prereq).

My intuition is that it may be worth starting that prototype as soon as we believe the adaption as a PoS subprotocol seems feasible, even before simulation, if we have concurrent bandwidth, because it would help us begin sorting out other integration/implementation issues quicker (such as "can the interface between the code implementing Zcash PoW subprotocol be correctly adapted to ABCI++ in order to integrate CometBFT?").

I should state explicitly that my bias has CometBFT at the top of the list of PoS subprotocol candidates not for consensus protocol motivations per se, but for "software development" and "toolchain / integration" reasons: there's wide support for developing on the SDK and auxillary benefits such as IBC support for bridging.

(Actually, I'm not yet clear how much we'd need to modify the Zcash address/txn semantics to support IBC, and that's definitely outside the scope of TFL design, but is still a useful practical/strategic consideration… Not sure where/how to track these kinds of considerations. Should they be tracked within the tfl-book repo, even though they are not in the scope of the TFL design?)