Etherlink: version 9978f3a5

Context

Contains the changes in the kernel up to 9978f3a5, which will be used as the next version.

Note that the upgrade has been tested using the YesEVM sandbox, both with an indexer and https://github.com/trilitech/live-testing-protocols

Manually testing the MR

Testing the MR thoroughly can be cumbersome, as it requires using the YesEVM instructions to check the node can still read the storage, send transactions, BlockScout can index it without any issue, etc (which I did). Fortunately we have migration tests that tries to ensure the kernel is still readable after a migration.

You can use the debugger with a dump of Etherlink's storage and the inputs to upgrade the kernel, then send some inputs and check it still works.

I strongly suggest to try the root hash 009237019ce6e440d550a1d3b6db4e626628346d2131cc41e9b4f7e6e5f2336da3 with these preimages, as this is the one that will be sent on Ghostnet. For example:

1. generate the installable kernel:

./smart-rollup-installer get-reveal-installer --upgrade-to evm_kernel.wasm --preimages-dir evm_9978f3a5f --output evm_9978f3a5f.wasm --display-root-hash

2. prepare the inputs:

[
  [
    {
      "payload": "Right 0x009237019ce6e440d550a1d3b6db4e626628346d2131cc41e9b4f7e6e5f2336da3",
      "sender": "KT1Ewy8Thvqt6nFCWdGPAkCpN2tXmCXadwdF",
      "destination": "sr1HFDt5ZwBVcXTgLA4wQ9vtwMH7EKU5vMFr"
    }
  ],
  [<some transactions>]
]

3. run the debugger:

./octez-smart-rollup-wasm-debugger --kernel etherlink/kernel_evm/kernel/tests/resources/ghostnet_evm_kernel.wasm --inputs upgrade.json --preimage-dir ./evm_9978f3a5f --installer-config evm-dump-storage-2024-01-12T09-51-21.json
> step inbox # runs the upgrade
> step inbox # apply the transactions from your inputs

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR