8

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.

2
  • What is "manual consensus"?
    – Gav
    Apr 5, 2022 at 14:51
  • edited the question a bit, sorry for the confusion :) Apr 5, 2022 at 20:29

3 Answers 3

3

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.

5

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

1

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
}

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.