I’m unsure if “consensus” is the optimal terminology here…
A typically parachain receives “true consensus” from the relay chain, meaning the collators build upon who they like, but the relay chain backers and block producers choose which progresses, with other relay chain protocol playing roles under situations like disputes, etc. We expect this remains true under asynchronous backing and all our methods for “selling blockspace”.
In particular, if a parachain runs aura, babe/praos, sassafras, or even proof-of-work then polakdot does not give the parachains time to reach probabilistic finality, so these act like block production protocols, not exactly consensus protocols.
There are parachain rolls which should run their own true consensus before collation, but doing so adds complexity and latency for them. We merely need them to export consensus proofs in their blocks for polkadot to verify. A bridge cannot export anything unfinalized by the other side for example, but they merely “forward” consensus and do not necessarily establish their own. All those DAG designs have similar properties I think.
At what point do parachains really need their own true consensus? A threshold VRF chain like drand achieves consensus of some form I guess. In fact, a drand bridge would merely be a pallet usable anywhere, not a parachain per se, although maybe a SPREE makes more sense. You could easily imagine fancier threshold signing or decryption parachains though, which then require pre-collation true consensus.
Now what new block production schemes which make sense for parachains? At least two…
- Sassafras for an SSLE with memepool-less operation or Tor integration.
- Whisk for an SSLE which runs few nodes and requires a memepool. Also Whisk supports more flexible block space patterns than Sassafras.
Also…
There is some tendency for parachains teams to favor pre-collation true consensus, which maybe helps sound cleaver when raising money, but definitely costs them in complexity, dev ops, etc, even ignoring the developer time. It likely makes them value their parachain slot less too. It might even risks more of our ecosystem working over less secure bridge protocols like IBC too.
I’d suggest we gently steer parachains teams away from pre-collation true consensus whenever sensible. Initially this means explaining the costs. In cases, we should listen to why they desire it, identify if they actually need it, and in most cases teach them patterns which address their needs more simply. This does not mean we should not assist teams building pre-collation true consensus schemes, but we should always ask if they have the right reasons for wanting it.