0

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.

3
  • to get a deeper grasp of what parachains can do, you might read the github.com/w3f/parachain-implementers-guide - it's very detailed and may provide some answers
    – Nuke
    May 2, 2022 at 22:18
  • Where does the info in you problems section come from? Can you link to sources in the question?
    – Nuke
    May 2, 2022 at 22:20
  • - I have already read that guide, my question is very specific, and its not about parachains per say, its about how to configure a Substrate chain in a way that may allow for effective optimistic finalization. - What info are you asking about specifically? the 1min finalization time you can see in any block explorer, the fact that it can be much larger on occasion requires you to understand how Polkadot finalizes parachains, there is lots of information on this. May 3, 2022 at 8:12

1 Answer 1

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

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

No

  1. 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.

1
  • Thank you. This what I want to do, but this only works if I have a way of picking such blocks which does not constantly result in reverting, because at some rate this becomes unacceptable for the UX. I am surprised that you say I cannot impact this rate, e.g. Aura would seem to be lower rate than BABE? Beyond this some param values perhaps could impact it, but I may be misinformed here. In any case: I guess I need to collect some real data on orphan rate of parachains as they currently stand to see how acceptable this is. Do you know if such data exists already? May 4, 2022 at 12:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.