Closed clangenb closed 2 years ago
@brenzi, @haerdib, @mullefel do you see any flaws, suggestions?
I think your rules are incomplete. If everyone waits until the first validateer produces block based on n, we will stall
Finality can propagate quickly and I think a tolerance of n-1 OR n is fine, given that sidechain blocks will be more frequent than parentchain blocks
Why do we stall? If it is our slot, and we have a pending block import, we import the parentchain block first and then produce a sidechain block.
I am quite confident that we can't simply implement a tolerance, as this might cause state inconsistencies.
For this case; does it make sense to put the whole parentchain header in the sidechain block?
I think that sounds reasonable.
When parentchain block n is received, we wait with its import until:
it is our slot we receive the first sidechain block that was built on block n.
Hm. I can see this working but that means the sidechainblock production will always include atleast one block syncing. Also: are you talking about buffering the header or the actual block?
Hm. I can see this working but that means the sidechainblock production will always include atleast one block syncing. Also: are you talking about buffering the header or the actual block?
Here is a misunderstanding. Most of the time, all the workers have an equal view of the parentchain, so they will produce sidechain blocks just as they do now. Only close to the parentchain block production instant, there will be discrepancies. To condense what I propose above.
Only the authoring validateer can progress from parentchain block n-1
to n
, all others wait with the import of block n
until they receive a sidechain block built upon block n
.
further tackled in #345. @clangenb please close if covered by that issue
Let me summarize: This issue is now only about this sentence:
Only the authoring validateer can progress from parentchain block n-1 to n, all others wait with the import of block n until they receive a sidechain block built upon block n.
And this is not tackled in #345 which is about state reverting of sidechain state only.
This issue here is only about the light client: only sync next parentchain block (n) once one the following conditions are met:
is my take correct?
That's my understanding at the moment, yes
I agree with @mullefel and @haerdib 👍
Summary according to discussions:
According to (https://github.com/integritee-network/worker/issues/423#issuecomment-928633944)
This issue is now only about the light client syncing. I.e. when sidechain is active, only sync with latest parentchain block (n) once one of the following conditions are met:
Original description:
I have never thought the following issue to the end. What do we do when the parentchain header of the sidechain block to be imported diverges from the latest finalized parentchain head known to the importing validateer?
Two scenarios can occur:
1. SidechainBlock Parentchainhead > LatestFinalizedHead
Here we can simply put the block in an
ImportBuffer
and wait with the import until we have imported the parentchain head. For this case; does it make sense to put the whole parentchain header in the sidechain block? This would allow ancestor verification of the future block and only include it in the buffer if the ancestor check is ok.1. SidechainBlock Parentchainhead < LatestFinalizedHead
I think this one is tricky. If we do this wrong, our sidechain might fork. In general, we should only accept blocks that lag at most 1 parentchain block behind (
n-1
). (Otherwise, something is seriously wrong with the authoring validateer, and it should not be able to produce a valid block anyhow). I assume validateers frequently receive sidechain blocks produced just at the border between parentchain blockn
andn-1
. Hence some validateers will already have seen blockn
, while others won't.Under the assumption that this occurs regularly, I suppose to handle this case proactively with the following scheme:
When parentchain block
n
is received, we wait with its import until:n
.