Deterministic L1InfoTreeRoot

[hexoscott]

The l1 info tree event will no emit the index and the parent hash. We have enough detail there now to build the L1 info tree without asking for headers so it will be much faster.

We need to support the new and old ways of building the tree and if possible detect when the move to banana has happened so that we can stop requesting headers at that point.

[hexoscott]

Description here https://hackmd.io/O4t3Xvj9TIydY9UsXfXHiA?view#Deterministic-l1InfoTreeRoot

[Sharonbc01]

Hi @mandrigin Jerry confirmed this feature would be helpful for the rollback feature (RPC node only) to address the case where only L1InfoTree index is change and no re-org in L2 blocks. Who in Gateway FM can implemented?

Then we can incorporate it into Stefan’s PR and 100% of the rollback events will be automatically detected by RPC nodes.

[hexoscott]

Hi @Sharonbc01 - we need confirmation on what the new event will look like and if there are any topic changes before we can implement this.

[Sharonbc01]

@cffls FYI

[cffls]

New event type: https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/update-l1-info-tree-v2/contracts/v2/PolygonZkEVMGlobalExitRootV2.sol#L39-L44

Topic for this event will be 0xaf6c6cd7790e0180a4d22eb8ed846e55846f54ed10e5946db19972b5a0813a59

Work log

>>> from web3 import Web3
>>> event_signature = "UpdateL1InfoTreeV2(bytes32,uint32,uint256,uint64)"
>>> topic_hash = Web3.keccak(text=event_signature).hex()
>>> print(f"Topic hash: {topic_hash}")
Topic hash: 0xaf6c6cd7790e0180a4d22eb8ed846e55846f54ed10e5946db19972b5a0813a59

[hexoscott]

Thanks @cffls - this is useful but we lose two important values here the mainnet and rollup exit roots. We use these to calculate the GER and also then later to retrieve these exit roots for the zkevm_getBatchByNumber call. Could we add Carlos/Jesus into this thread, not sure on their github handles.

[Sharonbc01]

Tagging @krlosMata & @invocamanman can you please advise

[invocamanman]

ye, already anwered on slack but can do it here as well ^^
https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/update-l1-info-tree-v2/contracts/v2/PolygonZkEVMGlobalExitRootV2.sol#L120
As you can see, we emit thes new event alongoside the old one.

It was ofc more optimal to emit jsut a new event with all the info, but this woudl mean that would be needed an orchetrated updated of all the networks.
I would say that emit just one event this would be so much better from the SC and future integration prespective, but it's needed this coordination between all existing networks.
Let me know your thoughs on this. From a SC dev i woudl love to have cleaner code, also you will have to be able to "join" both events.

Even if we start the audit this monday, this kind of event information can be changed^^

[Sharonbc01]

@hexoscott / @cffls can this be closed now?

[hexoscott]

Not yet, there is work to do around gathering the new events and making use of them in the node

[Sharonbc01]

Hi @hexoscott can you review this again. The vTeam have successfully tested the banana rollback feature on Bali. Is there there still work to do on gathering new events and making use of them in the node? Is this a sow stopper item for fork 12?

cc: @ToniRamirezM

[hexoscott]

If the network worked as expected with bridging and we picked up L1 info tree leaves as expected in the tested networks then this won't be a show stopper, it would simply speed up the L1 info tree sync.

Originally we anticipated this to change the way the events were broadcast at fork12, but instead new events were created to make things better for backwards compatibility. Because the original events were kept in tact the existing code can continue to work as normal.

[Sharonbc01]

@ToniRamirezM let revalidate this as part of testing the rollback feature on the Bali alternative.

[cffls]

Agreed with Scott, this could be closed (at least for cdk-erigon). To me, the deterministic L1InfoTree is more useful to the sequence sender, which can now check if the L1InfoTreeIndex already exists in L1 before sending the sequence. This is, in fact, already implemented in cdk here.