Can we reduce the changes to zkEVM etc?

[edmundedgar]

May be related to #269

We made changes to zkEVM to make it forkable which then have to be audited. For better compatibility and to reduce the amount that has to be audited, it may be possible to run the stock zkEVM, although we probably still need to tinker with the bridges.

Something like:

• The CreateChildren functionality is moved out of the zkEVM contract into a manager contract
• After a fork, the new chains are created as... new chains, with the starting genesis hash from the old chain
• Since we may not be able to make the change we made to the batch number etc we may have to tinker with the sequencer, rpc node etc to make the infrastructure work
• The old zkEVM needs to be told to stop making new batches after the fork. However it also needs to be able to finalize batches etc between the fork timestamp and the instantiation of the new chain (?). It seems like this may be possible by having a contract that can call the Emergency Halt, but also by the trusted sequencer being a contract, as the trusted sequencer seems to have permission to do stuff after the Emergency Halt.

[josojo]

Yeah, I checked when we used the onlyBeforeForking modifier and it seems to work as always the emergency is also checked.

It's nice that we reduce the diff... but I am not sure how much we are really winning by that. Since the interplay with the bridge needs to be audited anyways and generally the code would become harder to read.

I mean its not unreasonable to do, but it also not plain obvious that its better