Optimistic parachain block finalization

Question

Question

Is there some some way to configure a parachain to produce blocks in a way which

1. has high finalization rate (not PoA though)
2. predictable finalization rate, yielding a clear optimistic processing policy
3. has small reorgs. this is similar to 1, but with an emphasis on avoiding large numbers of blocks getting dicarded, even infrequently.

Premise

A Polkadot parachain is powering some DApp where transaction latency is quite important, say like some social use case, and you'd like the vast majority of user actions to be settled in a few seconds. The DApp is also using a caching layer to efficiently query the parachain state/history, sort of like "The Graph" from the Ethereum ecosystem, meaning that this infrastructure is processing parachain events/txs of interest to build it's on queryable state.

Problem

Polkadot itself has a block finalization time of roughly 1 min, when things are going well, when they are not, I understand it can take many minutes to finalize parachain blocks. This means that the query infrastructure would have to wait for at least 1 minute before parachain blocks can be processed, and thus the DApp user experience would have very large latency on updating the UI to reflect some user transaction.

Solution

A possible solution is to have the query infrastructure by some reasonable policy attempt to process unfinalized blocks earlier optimistically, and then on the rare a occasion that the block is not finalized, the infrastructure has to be able to reverse any side-effects of such processed blocks.

Problem with the Solution

This only really works if there is some way to configure a parachain to produce blocks in a way which is described in the question, hence the question.

Answer 1

Is there some some way to configure a parachain to produce blocks in a way which

1. has high finalization rate (not PoA though)

No

2. predictable finalization rate, yielding a clear optimistic processing policy

No

3. has small reorgs. this is similar to 1, but with an emphasis on avoiding large numbers of blocks getting discarded, even infrequently.

Reorgs depend on the relay chain. So, that is nothing you could currently really prevent. In the future with Sassafras that will not be a problem anymore, because there will be no more forks.

For your general problem, you could work on un-finalized blocks? You would just need to make the user aware that some data is not yet finalized and thus, still can change.