L1 <> L2 messages need to be scoped to a particular version of Aztec

[joeandrews]

Portal contracts need to define which version of Aztec, they can consume messages from.

Example

Lets say a portal contract manages Dai deposits. A user deposits 1,000 Dai to the portal contract that adds a message to the L1 > L2 Message Box.

The rollup implementation is then upgraded to support a less secure hash function / or some other change the user / dApp developer does not agree with.

In order to protect against the message being consumed in the newer version, the message needs to be scoped to a version.

[LHerskind]

Currently the implementation is assuming one rollup due to the upcoming upgrade RFP this have not been changed yet, as it depends on the mechanism chosen.

[LHerskind]

Idea to limit based on versioning that is enforced fully on L1 (no circuit changes).

• At the registry:
  • add a mapping rollupToVersion that maps from an address to the specific version. This entails that a specific rollup can only be listed once, to not have multiple version with same address.
  • at upgrade ensure that rollup is not already listed, and update the version in rollupToVersion, revert if already defined.
  • add getVersionFor(address) function that returns the version for a specific address. Revert if the address is not the rollup for any version.
  • at the constructor insert a "dead" rollup to ensure that 0's is not a "catch-all". Also beneficial to start version 1 to align with rest of system.
• For the MessageBox library,
  • the entry structure can be updated to include a version number. We can use 32 bits just fine, as it is increment we will probably be fine with 2**32-1 versions supported.
  • the insert function also check that the versions match and version != 0.
• In the Inbox:
  • at sendL2Message, store the version number in the entry.
  • at batchConsume fetch the version for msg.sender and for every message check that entry.version matches this version,
  • Can delete onlyRollup modifier as this is implicitly checked through the version check.
• In the Outbox:
  • at sendL1Messages, read the version using REGISTRY.getVersionFor(msg.sender) and insert into the entries
  • at consume check that entry.version matches the version of the message.
• Note. The Rollup contract itself stores a version that it is passing on to the execution layer in the globals, but this value does not necessarily matches the version number, so invalid config can make it impossible for a rollup to send stuff to L1. Also, the listing is permissioned now, but can be altered to match other proposals.