KitsuneWallet's take on memory reset during contract upgrade

Since EthCC’s hackathon, I have been working on KitsuneWallet, which isn’t a wallet but rather a proxy/master pattern for the upgrade of self-governed onchain wallets.

I’ve been working with UniversalLogin from the start to address their need for upgradeability, but now is the time to discuss this approach and seek opinions from other developers. While OpenZeppelin proposes tools for upgradeability, my opinion is that your approach works best with contracts such as token, dapps and other, where the upgrade process changes some method but not the underlying memory space.
I, on the other hand, am focussing on small contract with potentially radical memory space evolution (imagine having a UniversalLogin account, which is a proxy pointing to an implementation, and wanting to transform it into a GnosisSafe account that uses the GnosisSafe implementation).

Code is available for review/testing at https://github.com/Amxx/KitsuneWallet-ERC1836.

Please have a look and share your impressions. Documentation is lacking but the code and tests should be self-explanatory to anyone with a good understanding of inheritance and delegation.

3 Likes

Welcome to the community @Amxx

Thanks for sharing the implementation for https://github.com/ethereum/eips/issues/1836

Suggest reading (if you haven’t already) @spalladino’s article on getting the most out of CREATE2. Counterfactually instantiating user identity contracts looks really interesting for user onboarding.

Looping in @chris.whinfrey, who may have some ideas as well :wink:

2 Likes

Really cool concept @Amxx! I think, if you wanted to, you could actually use this pattern within ZeppelinOS and take advantage of all of the tooling around managing upgrades that’s already in place. The “resets” could be handled in the initialize function of the implementation (master) being upgraded to. I think you would need a way to override the errors that zos would give you for attempting to overwrite storage though.

I’m currently working on contract based accounts as well with Authereum and love to see the innovation in this space! We’re using zos for upgradability but our primary use for it is to layer in new functionality rather than allow the user to switch to a different wallet architecture.

1 Like

This is exactly what I want to avoid!

If the new master has to do the reset that means it must be aware of the memory structure of its predecessor, which would tremendously increase the complexity.
Imagine you have Agent, UniversalLogin (erc1077) and gnosis masters … rather than just having a function to reset their own memory space, each one would need initializers to reset the other 2, That would be a nightmare.
At some point, the compatibility would be very limited as the size of a master would have to grow linearly with the number of other masters.
Downgrades would also be painful as you would not be able to reuse an old, proven, master that is not aware of your current (younger) master

I understand this, but I also think that locking a user to a particular wallet architecture is a bad thing. Of the current multisig wallets developers, how many will still be here in 10 years? And what if the architecture turns out to have big drawbacks?
As a user, I wouldn’t want that … which is why I started this project.

The thing is, you could leave the default reset method, and leave this feature out for now, only allowing “simple” upgrades … and later out publish a new master with the same memory stores which adds the reset function. Going through this master would allow a user to bridge with another multisig provider. (this is what I call upgradeable upgradeability)

1 Like

For anyone interested, I recently released version 0.3.x that inherits from ZeppelinOs Proxies.

2 Likes