integritee-network / worker

Integritee off-chain worker and sidechain validateer
Apache License 2.0
89 stars 46 forks source link

[sidechain] only sync with latest parentchain block upon slot or sidechain block #423

Closed clangenb closed 2 years ago

clangenb commented 3 years ago

Summary according to discussions:

According to (https://github.com/integritee-network/worker/issues/423#issuecomment-928633944)

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.

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 block n and n-1. Hence some validateers will already have seen block n, 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:

clangenb commented 3 years ago

@brenzi, @haerdib, @mullefel do you see any flaws, suggestions?

brenzi commented 3 years ago

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

clangenb commented 3 years ago

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.

haerdib commented 3 years ago

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?

clangenb commented 3 years ago

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.

brenzi commented 3 years ago

further tackled in #345. @clangenb please close if covered by that issue

haerdib commented 2 years ago

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?

murerfel commented 2 years ago

That's my understanding at the moment, yes

clangenb commented 2 years ago

I agree with @mullefel and @haerdib 👍