Signing and verification of messages from L1

What

Messages passed from the inbox file are passed along with a signature. The kernel first verifies that the signature is valid against the public key before executing the evm transaction.

Why

This is more realistic workflow as seen in etherlink. Cryptography is expensive so its important to include it in the benchmark.

How

tezos_crypto_rs has much of the primitives required to for signing and verification, but jstz_crypto also wraps this up into convenient data structures. Directly use some of jstz_crypto, and modify it's SignedOperation struct to support TxEnv as the payload instead of the jstz specific thing.

Note the unconventional (de)serialization. TxEnv works well bincode's serde backend (not having (De/En)code while jzts_crypto data structures work well with the native backend (having implmentation of (De/En)code traits). Additionally there's some difficult to debug error on "Any types not being supported by serde", when using serde on the jstz_crypto data structures PublicKey and Signature are attempted. So for the SignedOperation struct uses the serde backend for the outer part and TxEnv field while native backend is used for PublicKey and Signature fields, using serde's with field attribute.

relevant code from revm/utils/src/crypto.rs

#[derive(Serialize, Deserialize)]
pub struct SignedOperation {
    #[serde(with = "serde_bincode_native")]
    pub public_key: PublicKey,
    #[serde(with = "serde_bincode_native")]
    signature: Signature,
    inner: Operation,
}

Another thing to note is that instead of every address generating a transaction being associated to a public-private key pair, I have a unique public-private key for every transaction. This was just simpler, and doesn't matter since this is just a benchmark. There should be no performance loss due to this, as I don't see how having more of the same public-private key pairs may introduce a greater scope for compiler optimisations.

Manually Testing

No changes. From src/riscv. Run:

make build-revm
make run-revm

Expected outcome is:

ignore internal message 
ignore internal message 
Successful transaction
Successful transaction
Successful transaction
Successful transaction
ignore internal message 

Benchmarking

N/A. This benchmark is a work in progress and can't be conveniently run yet.

Tasks for the Author

• Link all Linear issues related to this MR using magic words (e.g. part of, relates to, closes).
• Eliminate dead code and other spurious artefacts introduced in your changes.
• Document new public functions, methods and types.
• Make sure the documentation for updated functions, methods, and types is correct.
• Add tests for bugs that have been fixed.
• Put in reasonable effort to ensure that CI will pass.
  • make -C src/riscv
  • dune build src/lib_riscv
  • dune build src/rust_deps
• Benchmark performance and populate the table above if needed.
• Explain changes to regression test captures when applicable.
• Write commit messages to reflect the changes they're about.
• Self-review your changes to ensure they are high-quality.
• Complete all of the above before assigning this MR to reviewers.