zkEVM@v0.4.0

This is a new release of projects/zkevm  which:

• Based on bal-devnet-7 (bal@v7.1.0)
• Testing framework:
  • Support a new test marker @pytest.mark.skip_stateless_validation that allows test authors to skip stateless execution & filling. This is currently used only in very limited cases where tests violate the limits of CL-types (e.g., the number of withdrawals). These blocks do not represent a valid payload for CLs, thus indirectly can’t be properly SSZ-encoded following consensus-specs definitions of max sizes. (More info in PR)
  • Automatically skip stateless runs in fixtures that utilise the raw-RLP-modifier. This is done because RLP modifications can’t have a direct semantic mapping to meaningful ones for the guest program, given that we use SSZ. In the near future, more testing focused on raw-bytes guest input modifications (i.e., raw SSZ modifiers/mutations) is planned to ensure this testing angle is covered. (More info in PR — thx @Gabriel-Trintinalia for reporting)
• Specs:
  • Add a schema-id two-byte prefix to the stateless guest program input to indicate how the following bytes should be interpreted for deserialization. This is required since SSZ is not a self-describing encoding format, so the guest program might not know which fork the provided block corresponds to (e.g. ExecutionPayload is different between forks, thus NewPayloadRequest too). This prefix also allows the use of other encoding formats (this is not planned today), thus should not be strictly understood as fork-related encodings, but more generically. (More info in PR).
  • Change ChainConfig type present in StatelessInput to contain a clearer description of the chain configuration to be used. (More info in the PR. Also, the EthR&D #l1-zkevm-protocol thread.)
  • Fill the current public_keys field in StatelessInput. This is a field we had declared in the specs for a long time, but it wasn’t properly filled in the fixtures. The goal is to provide the guest program with the public keys corresponding to the payload transactions, since verifying signatures against public keys is significantly faster than performing a full ecrecover. Note that, temporarily, guest programs could still do an ecrecover, but it is highly recommended that they leverage this optimisation opportunity, since last year's benchmarks show a ~20% performance improvement in proving times. (More info in PR)