3

I observe an issue for a long time that I can't explain.

There is a value produced in BlockImport::import_block that must be included in inherents of n+1. Though sometimes it seems like value is not available yet. I have checked the code multiple times over last months and can't find any issue with it.

This seems to be correlated with blocks produced locally by the node. I'm wondering if it is possible that block n is built locally and block building starts for n+1 (creating inherents, etc) before n goes through BlockImport::import_block successfully (it doesn't do full execution there because block.state_action == StateAction::ApplyChanges)?

Consensus is custom, but based on sc-consensus-slots.

Improve this question
7
  • But the state of N is already there? You are sure that you use the same block import pipeline for import and block production?
    – bkchr
    Mar 30 at 19:37
  • I mean we have a single block import pipeline in the blockchain through which every block goes sooner or later. For locally produced blocks the state is computed during block production, but whether it is already in the state tree (or whatever it is called) or not I'm not sure yet.
    – nazar-pc
    Mar 31 at 8:00
  • No I meant if you really start producing block n + 1 or again n because the block import wasn't not yet finished?
    – bkchr
    Mar 31 at 13:50
  • sc-consensus-slots produces blocks in sequence, I suspect it never tries to produce a block before the previous one succeeds. But concurrent blocks can be created by other nodes on the network (and during last reproduction I observed heavy temporary forking).
    – nazar-pc
    Mar 31 at 17:12
  • 1
    The state is known to other components when it is imported by the DB, before this point you can not use the state anywhere.
    – bkchr
    Apr 3 at 11:13

1 Answer 1

Reset to default
0

The fundamental reason I asked the question was due to an edge-case I was hitting where justifications didn't have expected contents even though the process of creating data for justifications relied on blocks being imported sequentially.

Turned out SimpleSlotWorker imports blocks directly, so it is possible that something relatively long-running before block import exit can eventually return AFTER new block is imported on top of it.

Here is a more detailed description of what was happening: https://github.com/subspace/subspace/issues/871#issuecomment-1722745138

So the answer to original question is both Yes and No. No, technically block is indeed imported before next block is created, so it is not possible create an ancestor before tht. But also yes, it is certainly possible to create a block before corresponding outer BlockImport::import_block has actually returned, which is typically not an issue, but I was hitting exactly that case.

Improve this answer

Your Answer

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

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