Binance Labs Fellow: Kitsune Wallet, Upgradeable On-Chain Wallet

We would like to introduce the next Binance Fellow, Hadrien Croubois, and his project Kitsune Wallet. Kitsune Wallet (formerly known as UUIP - Universally Upgradeable Identity Proxy) was also the winner at our 2019 ETHParis bounty.

Hadrien is a French computer scientist who received his PhD at the École Normale Supérieure de Lyon. He specializes in parallel processing, distributed systems, and workflow distribution. He is also a research engineer at iExec, where he focuses on the evolution of the interactions between on-chain and off-chain entities. The development of Kitsune Wallet is his take on the improvement of user experience through identity smart contracts and meta-transactions.

While very enthusiastic about the recent development of identity smart contracts and meta-transactions, he realized that all existing projects were lacking features that, while still not standardized, will be essential to the seamless integration of on-chain identities with complex hybrid infrastructures such as the iExec stack. This worry about the long-term sustainability and versatility of on-chain identity led him to develop a UUIP (Universally Upgradeable Identity Proxy). With Kitsune Wallet, the evolution of this initial proof of concept, he hopes to resolve the issue of on-chain identity upgradeability by proposing a wallet proxy that you will keep for the rest of your life and transmit to your next of kin.

To learn more about him and Kitsune Wallet, here’s a Q&A we had with him earlier:

Flora: Can you talk about the genesis of Kitsune? What problem are you trying to solve?

Hadrien: Like most people involved in the development of blockchain projects, I realized UX is a major issue right now. This led me to follow the existing effort on identity smart contracts and meta-transactions. I realized that there is a lot of effort duplication, which is leading to incompatible solutions. It is also clear that no solution is future-proof.

Rather than coming up with a new competing solution, I decided to experiment with my knowledge of contract upgradeability to build a solution that is simple enough to be adopted straight away, but with the ability to upgrade to any existing or future standard.

Flora: Why do you call it Kitsune?

Hadrien: To me, an upgradeable identity smart contract is like a mythical creature that would watch over your assets while being able to change shape so it would always be friendly. I am a fan of Asian (and more particularly Japanese) culture, so the reference to the mystical shape-shifting fox was obvious.

Flora: Please describe what Kitsune Wallet is.

Hadrien: Similarly to the nine-tailed mythical shape-shifting fox, Kitsune Wallet is a smart contract based account that will hold your crypto assets in a single contract (address) while being able to change appearance depending on your needs. This change of appearance includes modifying the security logic of one’s account, adding interfaces (such as ERC1271) but also taking the appearance of common multisigs such as UniversalLogin’s ERC1077.

Flora: What is missing in current multisigs?

Hadrien: A lot of things are missing in the different multisigs currently deployed. I personally believe that support for ERC1271 signature verification is one of these. However, I also believe the most important feature that is missing is upgradeability. It is unlikely that we will identify all the missing features in the near future, but if we can include upgradeability, we will be able to add the missing features when the need arises.

Flora: How is Kitsune Wallet different from an ERC725 proxy?

Hadrien: An ERC725 proxy can keep tokens and assets while its ownership changes. This means users can upgrade their security policy by deploying a new multisig account and transfer the ownership of their proxy to this new multisig. This approach is simple but comes with some drawbacks. First, the proxy acts as a barrier, and querying the multisig for additional information (for example for ERC1271 signature verifications) cannot be done transparently while the proxy is in the way. Also, as the multisig doesn’t hold any assets (they are on the proxy) it cannot easily refund the relayer of meta-transactions.

Flora: Can you explain how Kitsune is significant?

Hadrien: Kitsune Wallet can be significant in many ways. First, it is designed to help wallet developers use proxies more easily. This will improve memory usage on the blockchain. In addition, Kistune makes these proxy upgradeable, so if the wallet logic as an error, or is missing a feature, you can upgrade in a single transaction that preserves your address (along with all the claims attached to it). Last but not least, being able to upgrade your proxy also means you are able to completely change the interface, so a user is not locked with the project that deployed the proxy in the first place.

My hope is that a Kitsune Wallet proxy can be your sole on-chain identity that you will keep for the rest of your life and transmit to your next of kin.

Flora: Can you talk about the technical architecture of Kitsune?

Hadrien: Technical architecture can quickly be very complex, particularly when talking about upgradeable smart contracts. The thing is, Ethereum smart contracts have their code (the logic they are going to execute) and their memory (the data they hold). Contracts also have the ability to call another contract or to perform a delegate call. Calls are simple as they move the context to another contract, asking it to perform some operation using its own code and memory. Delegate calls are different in the sense that they are executing the targeted contract’s code but using the memory of the caller. This is how libraries work. Using the same pattern Kitsune wallet deployed proxy that contains a minimum of code and uses delegate calls to a master for all the complex wallet logic. This means a single master can serve millions of users, each one of them only needs a lightweight proxy. By simply changing the master a proxy is using, you completely reshape the proxy capabilities. This is how most upgradeable contracts work.

The added value of Kitsune is the way masters are structured, and the way they deal with memory. Kitsune wallet prevents the proxy from linking to dangerous masters and requires the masters to include specific methods for memory cleanup and replay protection through upgrades.

Flora: What were some design trade-offs you’ve made for Kitsune?

Hadrien: Memory management is a big issue with upgradeable smart-contracts. Memory space is either shared across all upgrades and as to be kept intact or is master specific and has to be cleaned before an upgrade. Deciding the extent of the resilient part (the one common to all master and kept between upgrades) is a trade-off between what is currently part of all wallets, and what we think will be required in the future. Some wallets designers might want different fields to appear in this section. My stance is that generic mappings are the way to go and that consensus on how to use these mappings will be discussed long after the first wallets are deployed.

Flora: What are some features that took a lot of longer than you planned and why?

Hadrien: The core design of Kitsune-wallet is pretty simple to anyone that has my level of expertise in smart-contract development. It’s details like variable names that are difficult to get right straight away. Explaining the benefit of Kitsune Wallet to developers and having them adopt this model is always the most difficult step, but things are moving in the right direction.

Flora: What are some features that you made available initially and why?

Hadrien: The core of Kitsune Wallet is the proxy-master interaction. The first step was to build the proxy, build a few masters, and show how the upgrade process solves a real problem. It was not that difficult to find a missing feature in an existing multisig wallet, and showing that Kitsune can reduce the deployment cost of the wallet while giving them the ability to update their logic helped me convince people to consider this approach.

Flora: What are some features that you plan to work on and why?



Hadrien: I have many ideas of features to include in multisig wallets. My initial objective was not to propose a competing wallet implementation, but with upgradeable proxies becoming a thing I’ll be able to work on that in a way that will be reusable by others. Thanks to Kitsune’s upgradeability, we have all the time we need to work on these features and propose new, improved, wallets that include them.

Flora: You have made Kitsune open sourced. How would you see the community can expand on it?

Hadrien: Kitsune will soon be presented as an ERC. I might have missed some issues and I think this is a necessary step when the Ethereum community will be able to improve this design.

Wallet developers will also be able to expand the Kitsune project by building compatible master and using the Kitsune proxy.

Flora: What kind of help would you need from the developer community?

Hadrien: I hope Kitsune can be a catalyst to have developers consider upgradeable proxies. Now that there is a working example it’s easy for them to experiment with is, improve it, and build on top of it. As said previously, contributions to the ERC discussion will be more than welcome. Also, code review is always a good thing.

Flora: What kind of help would you need from the non-developer community?

Hadrien: At some point, I’ll need a better logo. More seriously, I think UX design is moving a lot lately. I hope more non-developer will try the new solutions and give their opinion about what works for them, what doesn’t and how they want to build their own wallet’s security. User requests and feedback is essential for us developers to make the onboarding process in the new web 3.0 as simple as it is in the old web 2.0.

Flora: What do you plan to work on during the Fellowship?

Hadrien: I already have work-in-progress with a few crypto projects that are moving toward upgradeable identity proxies. Building a complete, production-ready, onboarding user experience is my first objective. This will help me understand what tools are required to improve this integration process, and so the development of the necessary tools will be my second priority. I’ll also be working on bringing more projects into Kitsune Wallet, but I think this kind of adoption will really grow when Kitsune wallet and its partners will present working solutions in Q3 to Q4 of 2019.

If you like to check out Kitsune Wallet and contribute to the codebase, you can visit the project’s Github page. Kitsune Wallet is crowdfunding their project on Gitcoin, and you can support the project along with us here.





test list here



