DAPPCON 2019: The Implications of Contract-based Accounts - Paul Cowgill (Tasit Labs)
DappCon 2019 · August 2019 · 15:27
Paul Cowgill of Tasit Labs discusses the implications of contract-based accounts at DappCon 2019. He covers how moving account logic into smart contracts could reshape wallet design, addressing the tradeoffs for security, recovery, and mobile-first decentralized applications built on Ethereum.
Speakers
Topics
From DappCon 2019, hosted by Dappcon Berlin.
Transcript
hey everyone my name is Paul and I'll be talking about contract based accounts and in particular what they mean for mobile daps UX censorship and developer experience I am Paul Cowgill on Twitter feel free to check out check me out there and I'm the founder and tech lead of a project called tacit where our focus is native mobile aetherium depp's a couple assumptions and premises for this talk are that UX is very important and it should drive all downstream decisions in particular you want to consider who the user is so I'm talking here about the early majority in an adoption cycle and often as we saw in the last talk there isn't
really there doesn't need to be a trade-off between UX and decentralization so that's another underlying premise here so what are we talking about today contract based accounts for a quick definition the idea is basically that you have a contract holding funds or sending transactions rather than a vanilla etherium account and the state of the art for this space this is being used in smart wallets obviously gnosis is putting on this conference they have the gnosis safe also argent is a great smart wallet there are a couple depths that have tried this as well in particular dharma and instead ab I know have this abstraction between the users account and the DAP and they're starting to be some SDKs as well in particular I should
give a shout out to universal logins a lot of this is inspired by Alex Madison's talks about that there's also some cool SDKs abridged and aetherium that you should check out but our focus for today will be on what this means for dabs and why is this interesting well it offers all the same great benefits that you get for smart wallets so if the contract is holding the funds you're able to do a count recovery you basically just swap out to a new key that can't that has control over the funds in that contract which means that the user doesn't have to be presented with cede phrases which is a huge UX win I know we're probably losing 99.9% of mainstream folks because of that and it
also means that users don't have to worry about OPSEC I know for instance the first time I was trying crypto kitties I paused for a good 15 minutes and thought about so do I need multiple accounts like how does this map to what I do with like my work and personal email am I worried about like doing dphi things with my game account so taking this approach kind of removes that question for the user and taking this more opinionated contract-based account approach makes it a lot simpler but it's still fully self custodial so as I said there's not a trade-off here between UX and decentralization and then you also get the other great UX wins that you get with argent and gnosis safe like batch transactions multi-factor
author and find gain fine-grained controls like daily limits or whitelisting particular contracts for using your funds or particular addresses to send your funds to but what does this mean for dabs well that it's all the we get all these benefits but not just for smart wallets you can get these benefits like recovery but for adapt and in particular it means that if you have a given interface let's say there's a native mobile app that you've downloaded but then Apple decides to remove the app from the App Store if you had your funds with a vanilla aetherium account that was an in-app key you'd have essentially no recourse you wouldn't be able to
continue using those funds but if it's in a contract based account the problem becomes as simple as swapping out the primary key that you use to control those funds so that means that native mobile like essentially the main argument against native mobile taps goes away which is great because again the focus here is on UX for mainstream users and that's kind of the de-facto flow today people usually are on mobile and they're used to downloading things from the app store so it's kind of my prediction that we can 100 X or a thousand X the number of users if we tend to follow the standard ways that users do things right now and there was a great talk from seller yesterday but
really I mean if you think of any young person or any person in the world that's not us they mostly aren't using their laptops may not even have laptops but there are more and more people with smartphones so and even today so we need to be embracing that reality I also think that if you zoom out two years from now the way aetherium will really take off is most likely from a particular DAP that finally nails the UX and delivers a lot of user value and in that case you might have let's say some scalability issues aside you end up with a million users at that time maybe hopefully there's a hundred thousand
users with wallets so building an experience that requires that they go through a wallet setup flow or a pre assumes that they already have a wallet setup is pretty backwards and it's gonna limit the virality of that depth so embedding a flow for contract based accounts into the dab onboarding flow keeps that viral coefficient high and can actually make this stuff go mainstream which which brings me to a small gripe I have even about the word wallets like if you have an app right now in web 2 that's using the stripe API just because it involves financial transactions doesn't mean that there's a special name for that class of app and yet we have this abstraction in aetherium or certain things our wallets
and other things are daps I picture this blending over time where wallets become more ubiquitous and pieces of DAPs that can or cannot interlink with proper wallets and what that means is that wallets don't need to be a part of the interface and certainly not the entire interface in a case of mobile web mobile wallets with web 3 browsers they're the entire interface that UX is weird for a user because you have to say first download this then you can use the app that you actually care about and even in the case where you're kicking the user regularly over to a wallet to approve transactions as if you're a team that really values design and wants to make a
truly viral dab that can kill the feel of the flow which really does matter to users if it feels awkward they're not going to tell their friends to download it so moving the wallet into the day can be a new pattern that I think more and more people should look into I know wallets certainly will continue to be a very important thing but I the way I map it to my web to understanding is that they're more like a savings or investment account I basically just want my eath or maybe my CDI to be as secure as possible and then I pretty much don't want to ever touch it kind of like I do with my regular savings or investment
accounts it's still nice if you can interlink seamlessly like if you want to move funds from your savings to your checking account and then use that to pay for credit card payments I think we'll start to see something similar in the dab world where you can still seamlessly move funds between them or approve usage of funds but there's no reason to mash all the you exes together if every time I was doing a credit card transaction I was kicked over to like my Bank of America a mobile app that would you can just picture how gross of an experience that would be so what I see happening is that contract based accounts will become ubiquitous and had to appear to Austin Griffith this is partially inspired by the notion of burner wallets this is kind of like
burner smart wallets or burner contract paste accounts where's the time okay so how do we make this happen we want a smart wallet with in every dab so one way to do this and the way we're doing this with the tacit project through our gecko program funding is the DAP deploys a new safe contract that's not the safe contract that was deployed by the nose a safe iOS or Android app but rather by a DAP that's a entirely separate dedicated safe contract and there are a few ways you can do this but probably the simplest one to consider is that there's
an in-app key like an indepth key on the device that's specific to that tap and that device and then the recovery key at least for like power aetherium users can be your main gnosis safe so if you ever switch phones you can always swap that out but you know I mentioned ubiquitous contract-based accounts we don't wanna be flooding the etherium Network we only want to be doing this for users that have used the dap enough that warrants actually deploying the contract so you can do the standard create to magic and have the likes let's say you give a user a 10 ft for signing up they can have a contract address that has permissions to
have that nft but there's no actual contract yet and the way I picture this you Explo going is with rare or batched topping up at the account I mentioned the savings and investment account thing versus your checking account or your venmo so there's still a linkage with the gnosis safe and there should be a flow perhaps there deep linking for moving funds from the gnosis safe to the contract based account for the DAP but that you X should be very infrequent and you can also leverage batch transactions to do clever things like doing one of these transfers only on demand when you're actually going to do something of high value in the gap like purchase a parcel of decentraland land so there have been some great blog posts about
progressive decentralization I don't want to compromise on decentralization but I think maybe an alternate way to think of this as progressive security so if a user downloaded an app never came back to it they had an NF t that nobody cares about it's kind of fine that they don't have a seed phrase backed up it's also fine that there's not any multi-factor authentication account with a mobile wallet linked and then it's one of two signing or you can do the same things you would do with smart wallets like you might just for that really important DAP add social recovery
perhaps leveraging the same social recovery you used in argent or something like that or hook up a ledger wallet is your recovery key and then finally if you're really like let's say you're holding a lot of IRC 20 tokens or a lot of 71 tokens you can always sweep those - a proper wallet and the DEP should not aim to be more secure than that but it should have a nice flow from moving things in that direction when it's appropriate the approach we're using here is many simple instances venosus safe rather than trying to really decorate one singleton gnosis safe and that's because it becomes really hard to reason about like under what scenarios the four of seven signing
would be right and the daily limit would be right for the cryptic kiddies app as opposed to you defy app having them each separately configured allows for a better dev X and it's just simpler to reason about speaking of def X I think we do need more SDKs that facilitate this approach again abridged and etherium and universal logins are doing some interesting work in this direction I do think by having a more opinionated stance on how the DAP should work it means that it's a little harder for existing gaps to port their approach over to this approach but if you're really trying to make a viral mainstream gap it's not so bad to kind of rethink
the entire way you do onboarding with a more mobile first approach three box is a really awesome tool for linking your existing social profiles etc with a particular address doing things this way makes their life's a little more challenging but not prohibitively challenging so you can always select which of your many contract-based accounts that make sense to link with a particular social profile how I see this playing out is kind of like with slack today it feels ridiculous and slack you're probably in all in 20 workspaces but if you rewind three or five years you were probably only in one workspace and that felt great and that can feel like a mistake in retrospect but I think it was actually the right thing for slack to do because
everyone was only in one workspace three to five years ago and they can now begin to rethink the UI and start linking between workspaces and simplifying that UX but it would have been a mistake to assume people would have been in multiple workspaces a long time ago and I think it'd be easy to fall into that trap Ford apps - realistically a mainstream user probably only cares about one tap that'll be true for the next four years so you want to optimize the experience around making that one tap great but over time you can imagine that a particular contract based account for adapt would be shared between all of you different game apps or all of your different investment account like apps and so on
and over time I see this your identity is kind of defined by the apps you use in the group's you belong to had sceptic Len while for this concept I think it relates to OPSEC point this is a much better way to naturally kind of annotate your many different presences on the web by having the different contract based accounts separated so this all enables native mobile adapts we're working on this with the tacit project here is a flow where you start by seeing the value in a DAP and only later are prompted to set up an account again this is all graciously funded through the gecko program which I highly recommend here are some of our social links Twitter
discord telegram github medium and again a quick plug for gecko they really have helped so much with outreach funding and support so that's can't recommend it highly enough and I think I'm out of time so yeah one or two questions oh the the approach is plenty secure if the user is at a stage where I'm I'm just saying there's no reason to have yet deployed it yeah that's an interesting subtlety I wouldn't really
call it insecure it's just in the sequence of events you don't deploy it until the user has enough funds that it's worth deploying it okay thank you thank you for