Closed joeandrews closed 1 year ago
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.
Idea to limit based on versioning that is enforced fully on L1 (no circuit changes).
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.upgrade
ensure that rollup is not already listed, and update the version in rollupToVersion
, revert if already defined.getVersionFor(address)
function that returns the version for a specific address. Revert if the address is not the rollup for any version.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.2**32-1
versions supported. insert
function also check that the versions match and version != 0.sendL2Message
, store the version number in the entry.batchConsume
fetch the version for msg.sender
and for every message check that entry.version matches this version, onlyRollup
modifier as this is implicitly checked through the version check.sendL1Messages
, read the version using REGISTRY.getVersionFor(msg.sender)
and insert into the entriesconsume
check that entry.version
matches the version of the message.
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.