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