A potentially useful idea that recently came to mind, which might inspire prospective grantees:
Putting a new “migration public key” inside the preimage of an aztec address, to enable a user to migrate their state from one rollup version to the next.
This public key would be understood to be an alternative identifier for a user, for the sole purpose of proving their identity to smart contracts of the next rollup instance:
“I am Bob because I know the secret key of Bob’s ‘migration public key’, so please let me copy-over this state (which belonged to Bob on the old rollup), and let me ascribe ownership to my new address on this new rollup”.
Why does Bob need another public key to prove who he is to the next rollup instance?
Well, Aztec has account abstraction, which technically means there’s no enshrined public key to represent Bob. Bob is represented by his account contract, which means the way Bob proves “I am Bob” to a particular rollup instance is not “Here is a signature over some canonical public key”, but instead “A function of my account contract has successfully executed”. The network doesn’t care about the internals of that function: the function might actually validate a signature against some public key, but the network doesn’t see that; it only recognises the successful execution of a function of Bob’s account contract as evidence of “I am Bob”.
So if Bob wants to migrate his state from one (“old”) rollup to another (“new”) rollup, why can’t he provide a proof of execution of a function of his old account contract to functions of the new rollup? Well, whether that is a safe approach would depend on why a new rollup is being created. As mentioned in the original post above, it’s possible that the reason for a new rollup is due to a bug in the old rollup (because the network is in its Alpha phase). If there’s a bug in the proving system, for example, then Bob’s old account contract might contain a bug. In that case, the new rollup should not trust proofs from Bob’s old account contract. In that case, Bob’s mechanism for proving “I am Bob” – of furnishing a proof of successful execution of a function of his account contract – is broken. App developers who wish to design ways for users to migrate state between rollups should account for this possibility.
Hence, a new migration public key – which cannot be corrupted by any bugs in the Alpha phase of Aztec – is an attractive mechanism through which Bob could prove to functions of the new rollup “I was Bob on the old rollup, so please let me migrate Bob’s state over to this new rollup. I have generated a new address to be the owner of that state on this new rollup”.
Where should such a new “migration public key” live?
This is an advanced section for people familiar with the protocol
EDIT: we actually have an unused public key placeholder (currently dubbed “tagging public key”, but never used) which could be repurposed for this, if this idea is a good one. You can possibly ignore the rest of this message.
Ideally, the design of the preimage of an aztec address would be tweaked to include a new ‘migration public key’ field. Unfortunately, there probably isn’t enough engineering time to do this before Alpha. That’s not to say that some future network upgrade couldn’t tweak the design of an aztec address if the network chooses, but until then we’d need a cheekier way of storing this key.
Chatting with Palla, we realised the salt of a contract address could be abused to contain a public key: salt = h(actual_salt, migration_public_key).
But… we need to be forward-thinking with how this cheeky salt preimage is designed, because it could quickly proliferate to become an standardised layout across the ecosystem, and no one would be able to abuse it in other ways.
You might want to make it something like a hash chain: salt = h(actual_salt, root) , where root is itself h(some_value, some_root) and so on. (I think I’m stealing this idea off Palla from a couple of months ago). You end up with tiers of information being stored within the salt.
So initially, salt = h(actual_salt, h(migration_pubkey, root)) , where root is reserved for other future stuff. The actual salt lives at the 0th tier, and the migration public key lives at the 1st tier. Other stuff can live at lower tiers, if the community wants.
With this, Aztec smart contract devs (“app devs”) could design functions in their “new” smart contracts (smart contracts that will be deployed to future versions of the Aztec rollup) which enable a user to prove ownership of an “old” account, by proving knowledge of the secret key of that account’s ‘migration public key’.
I.e. “I am Bob. I wish to migrate my state from an app of the old rollup to the same app on the new rollup. The forward-thinking app devs have designed a function in the new smart contract which enables me to migrate my state.” The function will read the preimage of Bob’s address and extract the ‘migration public key’ from within the abused salt. The function will then demand proof of knowledge of the migration secret key. Such a proof of knowledge could be done with a signature, e.g. a schnorr signature. Bob can then provide to the function old notes that were owned by Bob on the old rollup, prove that Bob’s old address was the owner of those, and then provide a new address to become the owner of some corresponding new notes. Those new notes can then be inserted into the new rollup’s note_hash tree.
Danger: this migration approach will not always be safe!!! It will depend on the reason for the new rollup. E.g. if the old rollup contained a bug that would enable someone to insert arbitrary notes, or create notes of infinite value, then apps should not offer the ability to migrate notes, because then corrupted notes from the old app would be copied over and would corrupt the storage space of the new app. So whilst app teams might wish to explore the approach outlined in this message, and whilst they might want to go ahead and design migration functions, they will need to assess at the time of each new rollup instance whether it is safe to deploy those migration functions. I.e. they will need to understand the nature of any bugs that caused a new rollup to be deployed before offering migration.
Advanced technical note: ecosystem teams shouldn’t abuse the salt for their own custom use cases: the salt should only be abused for use cases that the whole ecosystem would benefit from. For custom use cases, you could abuse the
constructor_argsof the preimage of an address instead.