Disclaimer
This is not a full grant application and is fairly opinionated.
Similarities with warptoad
Warptoad works by creating cross-chain private state, where it’s state lives on multiple (rollups) chains at once. This is very similar to state migrations! So naturally this state migration idea got me nerd sniped. Ill share my thoughts here:
Problems with the proposal request in my opinion:
“Migrating private state requires user interaction” assumption
This is not true! Private state is actually easier to migrate!
“Purely onchain” approach and the aztec address problem
This is practically impossible. Aztec contracts and accounts use the vk_hash during derivation, which changes when the proof system updates. The ACIR byte code can be used but it needs to be verified off-chain. (zk-VMs can solve this, but likely is very computationally expensive).
Our state migration approach
Migrate-able Private State
This is pretty simple and very warptoad like to do. The old contract should no longer accept transaction after the upgrade timestamp, and the new contract should allow users to refer to a old note hash tree root, that is bridged over at the migration timestamp.
Privacy stays the same on the new chain and users don’t need to do anything!
Disabling the old contract: we can use context.include_by_timestamp and check it against public variable that stores a timestamp called no_migration_till_timestamp. Where no_migration_till_timestamp can be updated in a public call to be current_timestamp + 30 days but only while no upgrade is voted on by the aztec dao.
Bridging the old state root: This should be done through aztecs native bridge, and then the root should be accessible in public storage on aztec. The circuit then privately reads that root instead of the new L2 root, if a user makes their first tx after migration.
Migrate-able Public State
Aztec state tree is an indexed merkle tree which is very suitable for an ethereum statelessness style approach.
Here we would initialize slots of migrated contracts by proving inclusion in a old aztec state root that is bridged over at the migration timestamp.
In addition, every transaction interacting with an uninitialized slot needs to provide a proof of non membership inside the old aztec state root.
The aztec address problem
Like stated before, i don’t think this can be purely on-chain verifiable. But we can have a the dao vote on a list that remaps all know existing aztec contract ids to the new ids with the new prover. This wouldn’t be on-chain verifiable, but can be off-chain by the public. Simply by recompile the contracts and checking the ids against that list.
If the hashing algo is deemed insecure the list should contain addresses instead, but more things potentially break since above the merkle proofs assume the hash function is secure aswell.
Interoperability
In example a lending contract. If your collateral contract migrates but the lending contract doesn’t, things break. This means we need standards to identify if/how contracts migrates.
My suggested approach
I believe that security, simplicity and interoperability of immutability is more important than the conveniences of upgradability. Not just interoperability within aztec, but also in broader context. For example: warptoad cant build immutable crosschain private state if someone can change the rules, even if it is a dao.
Instead i suggest having a more simple approach where users can opt in to have their balances or state pulled to L1 once “something bad happens”. Either by a “proof of broken zk”, a trusted 3rd party, or whenever aztecs dao decides on an upgrade.
Grant Milestones and Roadmap
TBD