Gossipping => Finality

[jonas089]

The way gossipping is implemented there will be a loop of requesting commitments for multiple blocks => a validator could cheat the network by submitting 2 blocks to different nodes.

A finality gadget could help solve this problem.

[jonas089]

Update: My current idea is that the past 10 blocks can be "challenged". If someone gossips a proposal with a lower hash than the one that was accepted, then the block is replaced. The timestamp will remain the same and therefore not impact the consensus established over future blocks.

This wouldn't work for a Blockchain that processes transactions, but since this is a sequencer we don't have to worry about temporary balance discrepancies. Finality will be reached after n + 10 Blocks so the L1 contract should await that period before processing the Transaction. The L2 should be mindful of this when submitting batches.

To anyone reading this, please let me know if you have better suggestions / ideas.

[jonas089]

From my notes:
Synchronization must be adjusted to fetch Blocks where h<i<j.

h: block height
i: finality span
j: chain height

Also the longest chain should win whenever there is a conflict of two valid chains.

[Saksham010]

What would happen if there were more than 1 chain with same height at the 10th block seemingly broadcasted at nearly same time ?

[jonas089]

What would happen if there were more than 1 chain with same height at the 10th block seemingly broadcasted at nearly same time ?

Sorry, nevermind. My first comment wasn't exactly on point. Here the real explanation for you scenario:

It can't happen because of the way the consensus is designed.

It's a bit complicated but essentially one of the reasons why a chainsplit won't happen is the majority threshold and perfectly deterministic validator selection algorithm.

There is always only one truth and it won't happen that nodes start accepting different blocks.