The Three Transitions: Cross-Chain Smart Wallets with Privacy by Niran Babalola | Devcon SEA

[Music] all right hello everybody uh thanks for coming uh this talk is about the three transitions how we're going to get cross chain smart wallets that keep users private uh my name is neron Baba I'm a software engineer on the Bas team at coinbase so this three transitions concept comes from a blog post that vitalic last year about the changes that are going to have to happen to the ethereum ecosystem uh for normal people to be able to use this uh new Financial system that we've promised them uh so those three transitions are L2 scaling smart contract wallets and privacy uh so L2 scaling is what we need to make sure that transactions are cheap enough people can't send transactions on L1 when the fees are super high uh smart contract wallets are needed because right now seed phrases are how people man their funds and people are not comfortable with them they're afraid of them and then we need privacy because most normal people aren't willing to put their entire Financial history up on ether scan uh we need to have a way for them to be private when they're on chain um so we've all kind of experienced this problem with seed phrase wallets about how hard they are to use especially when you're trying to get a new user on board uh first you have to install an app that's special for your wallet uh there literally 400 you can choose from I didn't believe this until I actually went through the process and saw the popup the other day it says 400 plus wallets it's crazy uh you have to write down your seed phrase you can't lose it uh it's this magical phrase that you doesn't work the same way as anything else that users have ever used uh you have to fund your account to pay for gas if you want to use multiple accounts you have to put gas money in each one and then you have to sign multiple transactions to get stuff done you can't batch anything you have to do your erc20 approved then your trans transer it's just not very great but luckily now we're in the world of smart wallets smart wallets are here if you haven't used one definitely try one go to wallet. coinbase.com and try ours out uh but those smart wallets solve those problems you don't have to use seed phrases and you can batch transactions and you don't have to pay for your own guess so the way that we handle configuration changes for a smart wallet is that when you want to add a signer to your smart wallet uh that same transaction can be replayed on any chain that you're using so if you're using five different chains and you want to update your signer you can Replay that transaction on those chains but right now there's no mechanism to keep those in sync so the uh it's possible for the configuration to diverge across chains so you don't really have one wallet that lives on multiple chains you have one wallet per chain that might have a different configuration from the others and that's not the experience that we want users to have when they're using these wallets uh so there's no eventual consistency they can diverge over time uh when it comes time to develop new features uh like uh session keys that uh people were working on recently the uh the replay feature is specific to signer changes so if there's other configuration that you need to add to your wallet you have to build another process to be able to replay those changes across chains and that's just kind of a mess it would be nice if there was a way to do more kinds of configuration at once and lastly every wallet vendor has to build this functionality themselves uh if you want to be a vendor of a wallet that uses smart wallets and keeps them in secret crash chains there's a huge engineering lift to make that happen it would be nice if there was a common set of tools that wallet vendors could use for their smart wallets to stay in sync uh so vitalic vision for this has been key store wallets uh key store wallets instead of writing your configuration for your wallet directly in the storage of the smart contract on each chain what smart wallets do uh what key store wallet do is have a key store that's the single source of Truth for your wallet's configuration and then all your wallet contracts on every chain are pointing to that same key store to be able to read the configuration from that place so there are three blog posts that vitalica is written about this one is uh uh two of them are from last year and then there was one a couple weeks ago as part of that futures of ethereum blog series uh that you can read and there have been several teams that have been pushing forward this concept over time uh safe wallet scroll stacker and others and on the base team what we've been working on is keyspace uh keyspace is a key store for cross chain smart wallets that keeps their configuration in sync it's an implementation of this key store wallet model uh that's specifically designed to address the problems that we run into with the coinbase smart wallet so the way you use keyspace is first you give your smart wallet a key store uh so the way to think of how your key store loing this model it's not a separate thing for your wallet and keyspace your key store is built into your wallet and keyspace so your smart wallet contract literally inherits from this key store to be able to gain the functionality to write the configuration locally and syn it across chains that's built into your wallet so you deploy your wallet on one chain Two Chains as many chains as you want one of those chains is the master chain the source of Truth for your wallet configuration the other chains are replica chains that are syncing configuration from that Master chain so when you make a change to your signer configuration you're writing it directly to the master chain and on your replicas you're sinking from the master chain so the approach that we've taken uses general purpose l2s as the master chain for your wallet and that's uh there are other designs out there one of them has a dedicated uh L2 just for key store stores in uh specifically so the we the path that we've chosen is cheaper the transactions are cheaper uh it's easier we don't have to build a whole El uh a specific rollup from scratch uh but the downsides are that it finalizes more slowly and it involves more moving Parts if you're using a general purpose L2 for this purpose so a lot of the issues that I'll talk through are how we've gotten over those hurdles uh to make it usable so as a wallet vendor when you're integrating a key store into your wallet you need to choose which chain is going to be the master chain for your wallet uh we don't expect that every wallet vendor is going to want to use Bas as the master chain for their wallet in fact many wallet vendors have their own l2s that seems to be an emerging Trend and we expect that they're going to want to use their own L2 as the master chain for their wallet so right now keyspace has built-in support for op stack chains to be the master chain so any op stack chain can already use it out of the buck uh but it's also pluggable so if there's another stack that you wallet uh for the master chain that your wallet wants to use uh we want to help you with your pull request to get that functionality in there to be able to use your stack as the master chain for a key store wallet so you've deployed your wallet to all these chains you started using them with your initial configuration but then you eventually got to this point where you got a new phone and you want to add a signer to be able to access your wallet from that phone so now you need to update your configuration and what that looks like behind the scenes is you're signing a hash of the new configuration and you're setting that as the new configuration on the master chain so there are hooks that your wallet contract needs to implement to be able to handle each stage of the process the first one is authorizing the new configuration update so typically it's just checking the signature and making sure that it's signed by one of the signers in the previous configuration and if so the new configuration is authorized uh after that happens uh the key store itself does its own bookkeeping because it needs to store that hash of your configuration that's what's being synced across chains we're not syncing your whole configuration we're syncing the hash and you're doing the syncing of the configuration at the end of the day in the client so once that's stored the wallet can then apply that new configuration to its own storage uh the you've the user has provided a new configuration that gets handed over to the wallet to write to its local storage on the master chain and on the replicas so you don't have to change how your wallet stores data necessarily to be able to use keyspace you're going to get a payload from keyspace to be able to write to whatever storage format you want to use so there are minimal changes that happen to the logic in your actual smart contract when you're using this lastly there's a hook to validate the new configuration and this is important because if you think about the way that most smart wallets work typically there's a function to add a signer a function to remove a signer there are these uh specific Atomic actions that you're taking uh when you're changing the configuration of a wallet but with a key store wallet you're not just changing a signer you're swapping out an old configuration and putting in a new configuration there's so much more that can change and there's so much more wiggle room for something to potentially go wrong so this validate Hook is there for you to be able to verify that the new configuration can actually verify the signature that it's supposed to be able to and if it can't you can revert to make sure that you don't apply an invalid update but if it can you know that you've done a successful update and things are good to go so once you've uh updated your configuration on the master chain you might want to use your configuration on a replica so the way that keyspace works is that it's eventually consistent uh each wallet vendor can determine how often they want to require their users to sync their configuration from the Master chain and a lot of the examples that we use we just choose seven days as an example but you can choose anything you want and our typescript library for uh wallet clients allows you to generate the cross chain Merkel proofs that you need to verify that your key store on the master chain uh to verify the state of your key store on the master chain to any replica that you want to prove it to so again since we're using general purpose uh l2s as the master chain in the system um uh these are a lot of them are optimistic rollups that take a long time to actually finalize uh the three and a half days to 10 days if there's a challenge um so the the data that you're syncing from the master chain to the replica isn't necessarily that latest thing that new signer you added it's the state from three and a half days ago so when you're actually trying to use that new configuration immediately what the wallet client does is pre-confirmation to use so imagine that your wallet's Master chain is base and your user wants to send a transaction on optimism so they set the new configuration on base that's going to take three and a half days to get to optimism so literally you take that same payload that you executed on base and you execute it on optimism to make a local change uh of the configuration on that chain uh so uh the the way to think about what the sying is doing for you is not that it's providing the latest data on every chain for you to use it's really coming behind you it's making sure that the local state changes that you've applied don't diverge from the state of the master chain so imagine you have a chain of uh four configuration updates you've made on a chain as it syncs the older data from the master chain it's going to confirm that those are consistent and allow you to keep using that latest configuration change that you've made uh but in the case where something has diverged and it notices that the master chain state is different from what's on the replica the master chain state is going to overwrite that and take precedence uh so one special case here is when the user wants to revoke a signer uh because again in the normal case you're adding a signer you want to pre-confirmation for helping the user to broadcast that pre-confirmation to Every Chain they have assets on uh to detect when a signer has is being removed and to broadcast that uh uh pre-confirmation appropriately so we talked about what happens when you create a wallet and what happens when you update it uh when you upgrade a wallet there are some special cases as well as when you initialize a wallet on new chains so when you think about how the proxy implementation contract of a smart wallet interacts with the configuration they're very much intertwined the configuration doesn't mean anything without the implementation contract that's reading from it so if you do an upgrade and you upgrade the implementation contract but you have an old configuration things might not work and if you sync a configuration but you haven't synced the uh but you haven't synced the implementation then your old implementation might not be able to read your new configuration so you really need a way to do automic upgrades of both the conf configuration and the implementation at the same time and keyspace lets you do that the way you do it is by storing your wallet's implementation address within the key store that gets s across Chained and when you when that up uh when that apply update hook gets called your wallet can check to see if the implementation address in the contract matches the implementation address in the key store and if necessary perform that upgrade just like the normal configuration updates there's a that verify hook to make sure you didn't mess things up because if you swap out the implementation and you're swapping out the configuration there are a number of ways that things can go wrong if you call that verify hook you can make sure that the signatures you expect to be valid with that new configuration and that new implementation still validate at the end of the day uh we also expect that there's going to be many new chains over time and on every new chain that pops up you're going to want to be able to claim the address that represents your wallet but your address is forever tied to the factory that created it in the first place and the factory that created your wallet is written in 2024 maybe 2025 there's going to be a new chain that pops up in 2030 that you want to use and that same logic needs to be valid but every time there's a hard Fork of L1 or L2 the cross chain syncing process is put at risk uh L1 can break sinking if they change how the state route works and they have promised to change how the state route works the Merkel Patricia tree is going to become a veral tree or something else and then sinking will no longer work likewise the l2s are going to have hard Forks that change the system contracts the dispute game Factory is relatively recently that change would have broken the syncing uh if the system contracts on the L2 itself like the L1 block contract that we use if that changes that would also break syncing so to make sure that in 2030 you can claim the same address that you want the eventual consistency requirements do not apply when you are pre-confirmation changes on a chain it doesn't matter how old your last sync is you can replay any change you've made in the past on a chain without triggering any uh uh syncing requirements so the way that that helps you out is that on that new chain in 2030 you can take every configuration change that you've played on the master chain you can replay it as a confirmation no syncing just pre-confirmation and then once you've synced both a configuration and an implementation that knows how to sync across l2s in the way that is actually valid in 2030 you now can sync and make that happen so you need to be able to replay those configuration changes to get back up to speed and claim your address on any new chain that pops up so with keyspace wallet vendors can deliver an account for every chain that's as easy to use as offchain accounts we need a way to get to uh usable account for normal people if this is actually going to become the new Financial system that people that we onboard people to but the missing piece still is privacy how do we make sure that when people start using onchain systems that they can have similar privacy to what they have in the existing system if not better uh when it comes to privacy there are really three levers that we have to pull uh one is pseudonymity uh where senders and recipients are using as many fresh identities as they can and if you've used the Bitcoin HD wallet that's kind of how they work they're using a new address every time there's anonymity where the senders and recipients are completely unknown the amounts are known but the senders and recipients are aren't uh so that's how tornado cache works you have these different Bill sizes but the you don't know who's sending them and then there's confidentiality where the transaction amounts are not known but the sender and recipient are so you know that Alice is sending something to Bob you just don't know how much so these are the levers that we have to play with and the lever that keyspace gives us is pseudonymity uh keyspace allows us to bring pseudonymity to ethereum again when uh when we shifted from this Bitcoin world to this ethereum world what was sacrificed was the ability to use many fresh accounts because you have to fund your account with gas and if you have tokens or nfts in your account you can't send anything with that account now that we have Smart wallets we have pay masters that can fund our transactions uh so we can have as many uh smart contract identities as we want and now that we have key store wallets we can keep those in sync so you have these many uh as many accounts as you want that use the same signer configuration so you can use it on any device you want so the problem is that if you implement that that that the naive way where all of your pseudonyms are pointing directly at your key store then you've lost the pseudonymity everybody knows that this fresh account is tied to all the other ones the way you get that back is by uh using zero knowledge proofs to make the link between the key store and the pseudonym private so if you imagine what's actually stored in the smart contract of your pseudonym it's not the address of your key store wallet anymore what it is is a hash of that address and a random number that nobody else knows so when somebody else is looking at this wallet they just see a hash they don't know who this wallet belongs to and the way you send a transaction from the pseudonym wallet is by generating a zero knowledge proof of your key store address that random number that you generated the same cross chain Merkle proof that proves the state of your key store so you know which signers are valid and then the signature that's used to actually authorize the transaction at the end of the day those are all private inputs to a ZK snark that you're sending with your transaction so the link between your key store and your pseudonim are never exposed to the public all your pseudonyms are usable by the same keys store usable with the same pass keys on all the devices you have but nobody else knows what they are so what that gives us is access to kind of a swe sweet spot of privacy for ethereum if you have pseudonymity and confidentiality we can end this world where you look up somebody's ether scan page and you see all their financial history since 2015 instead uh you can have pseudonymity from keyspace which allows you to create as many accounts as you want and use them for each new transaction and then you can have confidential ERC 20s which use fully homomorph fully homomorphic encryption to hide the amounts that are being sent in each transaction and if you combine both of those obscuring the Senter and the recipient and hiding the amounts that are being sent users can now have privacy for the transactions that they're sending so the keyspace team is me Baptist and Michael at coinbase uh and we want you to reach out to us the documentation is up at Doc ke. space if you look at that right now that will be outdated uh but if you look at it a month from now that will match what I've said here uh but definitely excited to answer any questions that you have all right good stuff awesome um so we got some QA Q&A some questions before uh we go on to the next talk uh the first question the first question was how is this private I think you answered that in the last few slides um that question came up early but the next question asked um actually just came right up to the top isn't stud nomy just ethereum so yes and no uh right now the common practice for users using ethereum is to use the same account over and over and over again and that includes the ens names that they use so uh if you have vitalic uh you you used to have a pseudonym that was your address but now you've told everybody who you are and that's what most of us do when we use these assistance it's hard to manage many addresses each time you create a new address you do have a new pseudonym but because it's a typically an eoa account you have to fund that with gas uh and it's it's just hard to uh and you can't change the keys so it's really adding the ability to create as many pseudonyms as you want funded by pay masters because it's a smart wallet and with configurable signers uh so you can use it on any device you want cool um I think the next one is if we provide the same payload on optimism for base without waiting for the period of 3 days potentially allows for a replay attack again right what problem is this solving so there's it's not that there's a well I'm not sure what replay attack you're referring to but really the idea is that uh your configuration for your wallet is something that you actually want to apply to as many chains as possible so if you update your configuration on base and you take that same payload and you play it on optim ISM that was your desired outcome that's that's not something that you didn't want to happen you wanted all your wallets to stay in sync so it's not what it's giving you is making sure that after a certain period of time all your wallets will be in sync they never diverge permanently because there's a point in time that 7-Day window when you'll have to sink and your wallets are guaranteed to not permanently diverge from each other you can have that experience of having a single wallet on many chains rather than one wallet on on each chain cool um oh this yeah bumped W to the top just now does this only work on evm based change um what if it what what if it would be worked like on Tron or ton and they're asking about l1's but also I'm going to extend this what about l2s that are alt VMS um like eclipse and movement so this can work anywhere you have uh a virtual machine so again you won't get the same address because it's using a different virtual machine uh you'll have to use a different Factory to create your wallets but anywhere you can verify a proof of the state of the key store and verify that against the L1 block hash you can use the same key store you could use it on salana if you wanted to uh the the problem there is that once you are outside of the rollup world you now don't have a trustless source of the L1 blash to do those proofs against so it does get trickier you do have to make more trust assumptions about what's happening but if you want to use the key store outside with the ethereum ecosystem you can use it anywhere you want and keep those in sync cool so when do you expect the coin by smart wallet will use keyspace will it be a simple upgrade to existing users uh early 2025 that's uh it it will be a simple upgrade for existing users uh that's what we're designing for great to hear um how do you deal with reorgs on specific chains so when there's a re or the your uh wallet configuration updates do not depend specifically on chain State outside your wallet so if you think of your uh configuration as having its own nons that is upgraded with every uh new change you make uh if there's a reorg the transaction can just be played again and it will work uh there's there's no State you can get into where you now have incompatible states of your it because again the master chain is the source of truth if you prove something uh wrong across chains that ends up rolling back later it's the it's whatever was on the master chain that's going to be the final value so if there if there's okay so in the case where there's a temporary reorg you sync from the master chain but now the master chain says something different from what it did before when you do your next sync whatever's on the master chain is going to blow away whatever you have locally so that's how reor head all right everyone applaud for an uran great talk on the on keys and wallets our next talk