[sidechain] consensus (fork mitigation)

[clangenb]

I have been thinking about sidechain consensus. Although we trust the workers, there are still certain scenarios that must be considered.

Latency of gossiped block

The current block author gossips a valid block close to the end or after his production slot N.

Scenario:

• the next block author already started block production for slot N+1 based on the state of slot N-1 because he did not receive block N in time.
• Some workers receive the block of slot N before they receive the block of slot N+1. Other workers might not see the block N before block N-1.

Effect:

• Some workers will realize that the block N+1 was built without having seen block N, but as block N was valid, they will discard block N+1, which was built on an invalid state root. Hence, they will not import any block for slot N +1.
• The workers that receive block N+1 have already executed its effects, but then receive block N, which they can also interpret as a valid block as long as they have access to the previous state root.

Now there are two options for the workers that receive block N+1 before 1:

1. roll back state and discard N+1 afterwards.
2. discard block N. -> the chain will then define the correct sidechain, which would include block N, as it is perfectly valid.

Option 1 implications

Potential Attacks:

• A malicious administrator could prevent the worker from gossiping its block until almost the end of layer 1 block production time thereby forcing several sidechain blocks to be reverted.

Potential Mitigation:

• introduce a rollback threshold, which defines a certain block height at which the state cannot be reverted. However, this logic would need to be included on the layer 1 chain, such it can find out when to discard a perfectly valid block. Hence, this threshold still needs must be big enough to prevent worker collusion. With the additional layer 1 chain logic in mind, it might not be worth it to mitigate this scenario.

Option 2 implications:

I don't actually think that this is an option, it has too many disadvantages.

• worker's operate on different forks more often than with option 1, leading to more reverted sidechain transactions.
• too much additional logic on the layer 1 chain.

[brenzi]

It has to be option 1 IMO.

The problem you describe just puts a practical lower limit to the block time. We have to ensure that in 99% of all cases, the network delay is short enough for sequential block production.

In contrast to non-TEE blockchain consensus, our sidechains will only need a handful of validators, so I believe the network delay is pretty much controllable within practical limits - to a sufficient probability at least

[brenzi]

status? can we close this?

[clangenb]

Not really covered yet. Only happy flow implemented.

[murerfel]

@clangenb and I had a discussion about this issue, since I started to think about it in more detail. I'll document the essence of our discussion here. I think it will be necessary to have another dedicated meeting, with @clangenb and @brenzi .

Identifying the ordering of blocks

When we detect a fork, we need to know the ordering of the blocks that we received. Since the block number will be the same for two competing blocks, we will probably have to resort to the timestamp to determine the ordering.
In the Aura-verifier, we already verify that a block was authored in the correct slot time. We might have to add additional sanity checks (the minimal bounds for timestamp t of block N are: t_N > t_N-1 and t_N < now).

Rollback mechanisms

In the case where we need to rollback changes, we face a couple of challenges:

• We have indirect calls that can alter the state in-between top-pool operation execution. In case of a rollback, these would just be lost. So a simple solution could be to disable indirect-calls with sidechain?
• When we rollback the state, we would have to rollback the top-pool as well and restore trusted operations that were rolled-back. Or we accept the fact that trusted operations are lost after a rollback.
• We will need a flexible scheme to easily rollback and replay our state. Depending on how we define finality (see below), we'd have multiple blocks worth of state mutations that need to be rolled back. This might require some profound changes/extensions to our state.

Finality

The concept of finality emerged in our discussion in order to define how far into the past we detect and correct forks. @clangenb mentioned, that the parentchain finalizes sidechain blocks. However, it is not clear to me how the finalization is affected by a sidechain fork. Also we then still have the issue of a fork happening right at the boundary where a parentchain block is produced.

This led us to discuss if we could re-use and adapt the substrate/Polkadot consensus algorithm, GRANDPA, to our needs in the sidechain.

Regardless of whether we decide to use GRANDPA or not, we must have a clear definition of finality in our sidechain in order to properly devise a solution for potential forks.

[murerfel]

Closed - any further specification and implementation will be done through the epic #685