search

0xPolygonHermez / cdk-erigon

Ethereum implementation on the efficiency frontier
GNU Lesser General Public License v3.0
30 stars 26 forks source link

Verify AccInputHash #794

Open hexoscott opened 2 months ago

hexoscott commented 2 months ago

Because the L1InfoRoot is now deterministic, the sequencer will be able to calculate the AccInputHash without needing to call the L1. There are places in the RPC where we call the L1 for this information that we need to switch over to calculating locally.

Details here: https://hackmd.io/O4t3Xvj9TIydY9UsXfXHiA?view#Verify-accumulate-Input-Hash

Sharonbc01 commented 1 month ago

Hey @mandrigin who can work on this issue please to support Banana changes?

Sharonbc01 commented 1 month ago

Ideal if we can get done sooner rather than later to have 100% coverage on all rollback cases

V-Staykov commented 1 month ago

We can't calculate this in the sequencer, because we don't have the sequence timestamp, so nothing to do on our side currently.

cffls commented 1 month ago

Sequence sender sets the timestamp of the batch the same as the timestamp of the last block in that batch: https://github.com/0xPolygonHermez/zkevm-sequence-sender/blob/develop/sequencesender/sequencesender.go#L1036. If this assumption is correct, cdk-erigon will have everything it needs to compute accinputhash.

hexoscott commented 1 month ago

If my understanding is correct though, it is the last block timestamp of the last batch in the "sequence", because this is determined by the sequence sender the sequencer will always need to look this up from the L1 as it doesn't control what goes into a sequence.

cffls commented 1 month ago

Agreed. Thanks for the insights. Only sequence sender will be able to calculate this first. However, I think it will be still beneficial to have this calculation in cdk-erigon, with the timestamp retrieved from L1. For example, in a rollback event, only L1Info index has changed, a RPC node will be able to detect the inconsistency when it verifies the AccInputHash for a range of batches.

cffls commented 1 month ago

Looking into the implementation of AccInputHash, it seems to me that AccInputHash is calculate per batch, not per range of batches. Also see this diagram from this page.

hexoscott commented 1 month ago

Thanks @cffls - that definitely looks like it's calculated on a batch by batch basis

cffls commented 1 month ago

Thanks for confirming. Looks like we have all information required to proceed with the implementation.

hexoscott commented 1 month ago

I've dropped a comment on the l1 info root changes which affect this here https://github.com/0xPolygonHermez/cdk-erigon/issues/793#issuecomment-2293197956