General feedback: I’m not a fan of using a zkEVM as I think the benefits don’t outweigh the costs. For a simple example, IIUC a VM with backward jumps (loops) is significantly harder to generate proofs for than a VM that simply doesn’t have any backward jumps. Also, EVM is 256-bits which I have heard is problematic for ZK provers (something about 224 bits being a better fit?). Further, a lot of lessons have been learned in developing the EVM and if you ask any of the core developers who work on it they can list off a bunch of things they would change if they didn’t have to worry about supporting already deployed contracts, like the completely removal of
SELFDESTRUCT, weird gas accounting subtleties (EIP-2730), support for smaller width storage slots, removal tx.origin, etc.
All in all, I think any L2 project would be far better served at least using a strict subset of the EVM, and potentially better off using a derivative of it or something entirely new. The problem with “entirely new” of course is that you need to build a new compiler and toolchain, which I do understand is a pretty big undertaking. By doing a subset or a derivative, you may be able to still use most of the Ethereum toolchain.