# Re: The Three Transitions

Some assorted thoughts on Vitalik's [latest post](https://hackmd.io/@vbuterin/the_three_transitions) by MetaMask co-founder Dan Finlay.

## Preamble

Thanks for sharing this vision of the decentralized future. This seems like a nice opportunity to share some thoughts, and a sense of how MetaMask is building towards enabling all of the solutions listed in this blog post and more.

A number of the approaches listed in this article are things I completely agree with and we already have initiatives underway to address (privacy is mandatory, wallets should sync data, wallets need to seamlessly integrate L2s, cross-chain applications should be feasible, users shouldn't have to think about addresses), and some of the proposals are a bit more technically ambitious and seem to deserve deeper consideration (the [keystore contract proposal](https://hackmd.io/@vbuterin/the_three_transitions#Verification--asset-separation-architecture)). That said, I am happy to say that even the most ambitious proposals here fit well within the current MetaMask roadmap, and I'm happy to now do a review of how.

## The Review of How

### The Pain of Many Addresses

The article begins and ends with thoughts about the pain of having many addresses, and multiple sections are spent ideating on ways of reducing the pain of managing these many addresses, or improving their user experience through services like ENS.

I think this line of thinking merits a bit of unlearning. I think we've done ourselves a disservice to think that users should have to think about addresses at all. "What is an address?", the final section asks. How about: a protocol implementation detail.

I believe we can abstract away the need to think about addresses and eventually, the need for humans to ever view them. In general humans are poor at comparing binary information, and trying to expect people to invites opportunities for mimicry, and in turn phishing. Even extra layers to make binary information more familiar, like identicons, are at least mimicable. We have seen [recent phishing campaigns](https://docs.google.com/document/d/1_xrj8N4hHJaVfmfl7m7bYfZ2M1IFwsLM7TZTFpo4Btc/edit#heading=h.w0w8sbb8mfa9) that rely on the tendency for users to only skim the first and last characters of an address to recognize one. Even ENS names invite the threat of mimicry, and so [arguably ENS does not satisfy the security corner of Zooko's triangle](https://twitter.com/danfinlay/status/1478905965206380547).

There are at least two technical solutions I'm aware of that could allow abstracting addresses out of the user's consciousness. The first one is more of a mitigation, it's to try to compress all addresses into one address. This is what the DID community has been trying to do for years, and could be achieved in a variety of ways. Basically if you can come up with one address format that allows requesting or negotiating additional addresses, then it's the only address you need.

Another exciting possibility comes from inverting the asset sending relationship, via sending delegations. Assuming you have a single secure communication channel with the recipient, and the protocol you are sending from supports composing a cryptographic right to withdraw or claim a given asset, you could compose a "claim link" for the recipient, which allows them to withdraw the funds to any address they want, potentially also integrating a bridge and maybe even a mixer into the same receiving user's interaction, allowing the sender to know nothing about the recipient's wallet to send, and allowing the recipient to manage the funds in whatever way and on whatever chain they prefer. The funds only leave the sender's wallet upon the recipient's successful receipt, also eliminating risk of wrongly-typed addresses or ENS names.

I've advocated for this pattern of claim link for some years, first in [Ethereum Object Capabilities](https://ethereum-magicians.org/t/ethereum-object-capabilities/3035), and more recently via [The Delegatable Framework](https://delegatable.org/) (which works today, as demonstrated with [Giftee](https://www.giftee.cards/)! You can also watch the [EthDenver talk](https://www.youtube.com/watch?v=NMqaCGxSRQY)). At MetaMask we've also been investigating what it can mean to provide general purpose delegation via a EIP-4337 account (currently codenamed Delegatooor), and so far the results have been promising 🔜.

Since not every protocol can support claim links, we will probably be limited to an upper bound of ux for the foreseeable future with something like DID-type multi-protocol addresses with selective disclosure for non-delegation enabled protocols, with an option to form claim links for new users or when getting an address first is not an option on protocols that do support delegation messages.

### Verification/Asset Separation

This section is interesting, the whole potential of having verification logic on a second chain enforcing behavior on a first chain is very appealing.

I've done some preliminary very rudimentary research into this possibility in response to this post, and so far I haven't found concrete examples that seem to demonstrate that a "proof of state on another chain" can be cheap enough that it's an efficient way to validate every transaction, but I'm eager to be proven wrong here.

There's also the possibility of having asynchronously updating cross-chain verification logic that could be built in a variety of ways. For example, I am aware that the Linea zk-rollup team is working on building [a general purpose message bridge](https://docs.linea.build/developers/bridge-architecture) for their rollup. That said, I think async doesn't quite achieve the full vision here, and if we were to rely on asynchronously updating the access policy of each account on each chain, we could also just try to abstract that access policy updating at the wallet layer, and I'm not sure that having it cryptographcially enforced provides significant additional security.

If there was a technique that made this synchronous verification possible, and better if there were a way to achieve privacy with this technique using a zk-SNARK as described, then I would be eager for us to adopt it in our own contract account recommendations.

In the Delegatooor account, we've been experimenting with a contract account whose signer is a modular component, by making its authorization logic rooted in [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) signature verification that is defined by an [ERC-2535 diamond facet](https://eips.ethereum.org/EIPS/eip-2535). Any contract account built in this manner could swap out its signing authority for any of the approaches listed here as they were proven viable and desireable to the user, and thanks to [MetaMask Snaps](https://metamask.io/snaps/), making a contract account whose behavior can be easily substituted or extended is an increasingly feasible future.

### Cross Chain/Rollup Payments

I already described one way that cross chain payments can be made invisible using delegation claim messages. I agree that other approaches are challenging.

### Updating Secondary Infrastructure

Lots to agree with here:

- L1 costs are too high
- experimenting with privacy tech is good (and Snaps is going to enable a lot of that, address formats and name resolvers included)
- Users should own contract accounts more often
- Light cilents should become more common. Also ones that store and assist partial state gossip like [Laconic](https://www.laconic.com/).

- Encryption should be more standardized: At MetaMask we shipped one encryption method already, but it was imperfect. I'm eager for Snaps to provide a broader platform for experimenting with methods of encryption that are maximally safe and useful.

### Wallets should store Data Too

Absolutely. I remember Mark Cuban making a big point of how crazy it was that MetaMask didn't do this yet. We truly have an embarrassment of valuable things to do. Especially if you believe in a future where counterfactual delegation messages can be a useful tool like I do, e2ee user data isn't just nice to have, it's completely necessary for the functionality of the platform.

## Conclusion

I think that wraps it for now. Honestly I barely managed writing this between meetings, I know I skimmed quite a few points, so feel free to reach out on any points you'd like me to expand on!

- Dan