Consensus work items for next Architecture proposal

Separate out consensus service

"solo" consenter

• Simon says we already have this, via f=0 N=1. Do we want something 'simpler' like noops 2.0, which is easier to understand, but is likely not to be crash fault tolerant etc.?
• There is a loopback mode in the fabric peer that could be a simple solo consenter.

separate consensus repository

• Binh is apparently not sold on this?

plugin other consensus protocols

• Kafka
• etcd (China?)

state transfer between fabric peers

• Modify existing peer impl?

state transfer between pbft replicas

• Is this really necessary? Must commit on 2f+1 peers, with f failures can always find f+1 copies.
• encode state in checkpoint value?

reconfiguration

• Dynamically, at runtime

Persisting the raw log

• As separate dedicated committers
• Requirement for commitment configurable
• Does the consenter reply to log requests, or is it directly to the external committer?

Endorser workflow

Is this part of consensus, or part of fabric peer?

Dynamic timeouts

• Rough idea: Keep running averages of request latencies, adjust request timeout (and maybe others?) accordingly

Allow non-byzantine replicas to keep up

• With all non-byzantine nodes, the slowest f will invariably fall out of sync, would be nice to optionally give these replicas time to keep up with the network

Virtual Clients / Slots

• Today we are exposed to censorship, because there are multiple requests from the same client in flight, this is intended to fix that