How can a Dapp know if the node produces blocks automatically or not?

Question

The substrate-contracts-node changed consensus to manual-seal starting v0.11.0, and now produces blocks only when a transaction is submitted.

Because we were relying on the block 1 hash for some logic, this change was pretty breaking.

Of course, the problem is relying on block 1 in the first place, but I was wondering if there is currently a way to know if the node my Dapp is connected to produces blocks automatically or not.

Answer 1

Since the runtime gets exposed via metadata, you can check for the availability of the pallets and certain methods on them. These can be storage locations, constants, extrinsics, events, etc.

For instance just using storage & JS API (since that is what I'm familiar with) -

• api.query.authorship.author - authorship pallet
• api.query.aura.authorities - aura
• api.query.babe.authorities - babe
• api.query.difficulty.currentDifficulty - Kulupu POW
• api.query.grandpa.pendingChange - grandpa

So basically something like -

if (api.query.aura?.authorities) {
  // aura pallet
} else if (api.query.babe?.authorities) {
  // babe
} else if (api.query.authorship?.author) {
  // authorship pallet
  // can be used in conjunction with aura, see
  // e.g. Statemine parachain
} else if ... // anything else, even POW

It only checks for existence of something specific in the runtime, but doesn't actually make calls in those checks.

Answer 2

I might be misunderstanding what the aims are for this query, but the specific consensus algorithm is an implementation detail that should probably not (need to) be exposed to Dapps. There are many factors that alter the transaction processing service which Dapps rely on and consensus algorithm is only one of them.

Rather, they might want to query the guarantees given by the service which the blockchain provides.

Specifically, the expected period from transaction submission to some minimal non-reversion guarantee (e.g. block inclusion) and some maximal non-reversion guarantee (e.g. "finality"). They might also want to query the strength of consensus (expressed in terms of cost of reversion) for either extreme. On Polkadot, they'd get something like 18 seconds with ~$5 cost of reversion (which is modelled as the opportunity cost for missing a block reward) and 30 seconds with $500m cost of reversion (which is modelled as the slash for 2/3 validators which would need to equivocate).

This might be queried depending on tx fee paid (which in Ethereum's case, depending on the tx pool, would make a big difference to those periods) and it might be reasonable to query typical expectations (e.g. estimations of average and variability for the above periods).

Answer 3

The answer of detecting the capabilities is valid, i.e.

if (api.query.aura?.authorities || api.query.babe?.authorities) {
  // this should be non-manual
} else {
  // this is manual
}

However in your case you are just after "blocks produced", so for manual seal at block 2 it would work as well. So just change the logic to check if there are blocks

const curr_head = await api.rpc.chain.getHeader()

if (curr_head.number.isEmpty()) {
  // nothing has been produced, we are on genesis
} else {
  // block has been produced
}