ZK Paris: Nitya Subramanian - How MPC Enables more Expressive and Programmable Transacting

Transcript

okay up next we have how MPC enables more expressive and programmable transacting by nitia subramanian at capsule um yeah hi everyone uh I'm nitya I'll be

talking about uh what Chloe just mentioned so ways that NPC can enable more expressive types of transactions and some of the ways that we think about that at capsule which is the the project that I'm building so first just a bit about me um I started my career in the fintech space actually and then uh worked on the cello blockchain for several years among other things building a wallet and started working on capsule because uh kind of saw the the possibility to think a lot more about the layer beneath the wallet interface as we describe it today and uh and that's a lot of what we're

working on and I'll share more about kind of how that plays into the topics today so why don't you start with kind of bringing us up like all the way up to the user interaction level we've been talking about a lot of very deeply technical Concepts today but kind of thinking about blockchains at the most foundational level uh ultimately blockchains are a new type of infrastructure with a paradigm where a user owns and controls data the internet's of course not new and we need to think a little bit about how blockchains fit into the the internet and so slack is actually a one example of this I think really any

web 2 app that we use uh falls into this Paradigm um but in slack I can click a button to make a post I can maybe have that post happen a bit later maybe when I'm asleep I could maybe write a bot that posts on my behalf and I can do all of this without necessarily specifying exactly what computation is getting executed so of course uh in crypto we would call all of these trust assumptions um and I think in the um in in the space we've done a really good job of eliminating trust assumptions or minimizing trust

assumptions when possible but on the flip side we've left ourselves with an interaction Paradigm that's basically at the at the metal so irreversible State fully fully specified interaction and unfortunately we've lost a lot of these nice features that we take for granted when interacting with the internet more broadly so as a result of this there's now the pretty difficult task ahead where we have to decide what trust assumptions to reintroduce when how to expose them to users Etc if we hope to have any of these nice features that um have made kind of the internet as accessible as it is today so if we kind of take this a step

further and look at what the actual steps are to perform a transaction so let's take a game for example we start with some interaction in an application followed by some desire for Action many would call this an intent right now then a transaction is proposed it's maybe viewed or inspected within a wallet namely it is viewed and inspected in a wallet which is a separate product from where this intent originated and then it's of course executed and settled and won't go into any detail of anything below that um because of course there's there's a lot of exciting stuff going on at that level so would be remiss to talk about any of

this without mentioning account abstraction account abstraction Builds on this because we are able to basically separate the initiation of transactions from the actual verification and signing of them and so this is through features like session keys that are that are really helpful however in this Paradigm we do still need to go through the steps of proposing some transaction visually inspecting them and verifying them um which is of course a challenge for for many and so kind of in summary we're still in this Paradigm where we don't have uh any trust assumptions or like well understood sets of trust assumptions and are in a place where this manual

inspection of transactions is like the only way that we can actually put anything on chain and it's this is not a bad thing necessarily of course in any system where you need a signature to access funds any trust assumptions that you add introduce some attack Vector where all of your assets could be stolen your account could be compromised without any possibility of of reversal and so um this is of course like there's a good reason this exists but it's important to note that right now we're at a state where we are effectively rebuilding from the ground up and have not necessarily defined or have any well understood sets of trust assumptions that enable all the features

that we might want and so uh the way that transactions fit into all of this is of course in the web 2 world we have these nice ux of interactions where we push buttons things happen sometimes things happen without using to push buttons but in the crypto world we have these really complicated interaction schemes where we need to be aware of specifically what L2 or what chain um specific assets on we might have assets on many different chains but it might be the same asset and we don't necessarily understand that or we need to we need to be very very well aware of that um and even if the the details of that are less important our specific use case

and then additionally we need to be physically inspecting transactions um and kind of hoping for the best in terms of what that leads to and this still has not necessarily created a world where everything that we intend to happen happens like there's still lots of accidents and lots of mistakes so where MPC is uh is interesting here is um basically a couple of things so everyone knows about NPC in the context of of Key Management key recovery namely that we get some nice ux properties of not needing to have users write down seed phrases as well as the ability to do key recovery

additionally um we get some benefits of NPC that people don't talk about as much in the context of of Key Management um so specifically we get some privacy on um on signatures on on which uh Keys provide signatures and additionally um we get a separation of the signing of a transaction or the proposal of a transaction from ownership of the full key which therefore would afford unilateral access and so what's nice here is that we actually get a separation of concerns between proposing a transaction and then execution of some state or execution of some change uh over an account State and then another nice benefit building on that is that you can actually allow many different

applications to propose transactions but then uh gatekeep or block execution at some point that is um that is trusted and so of course like any system where you have multiple applications that are all able to transact specifically on an account is not safe because it gives you least common denominator security and so a notion of adding permissions onto this uh actually expands the space so that we can keep Notions of uh of security along the way so there's actually a really nice web too uh Paradigm around operating on shared State and that's SSO uh where in the example on the left we see that SSO gives us the ability to

manage different state and give applications the ability to even modify a certain state within a Google account in a blockchain context what this actually can look like and this is how we think about it is you can have uh limitations at the transaction level where you can give applications a restricted ability to propose certain types of transactions and not others and so this cleanly kind of creates a mechanism for specifying the type of State changes that different applications can make so introducing a trust assumption but in so doing allowing the ability to do more automated types of transactions and so I'll go in a little bit more into

how we think about this capsule so we basically have a permissions layer uh as mentioned earlier where you can grant permissions up front and then um this adds an upfront step of uh of giving permissions to an app but it gives us the nice ability to remove these explicit proposal and signing steps and so you end up with a transacting paradigm that can happen more in context without necessarily requiring uh multiple applications to perform a single action I don't think we'll be able to like view the demo necessarily oh okay cool oh great okay perfect

um amazing um so this is basically how we think about it with capsule um you can do something like create a wallet with an email and then use an SSO style verification uh that then creates a wallet that you can use to then perform signing in the background um this is like an on-ramp feature that someone could use to top up and then what you see actually is the ability to transact without any separate Standalone product and then when you go to use other products in crypto this same wallet could be accessible through a permission scheme which we'll see later so the same wallet now will have specific permissions that are granted to a wallet and so provided those permissions are satisfied transacting

can happen in the background in cases where they're not satisfied we'd see one-off pop-ups that a user could either decline in this case or accept in another case and so this is really a proposal of a of a certain kind of set of assumptions that we can add that then give us a lot of these properties around being able to do transactions autonomously from applications without uh Standalone products required um yeah so if any of this was interesting um would love to chat more here's my contact info and thanks a lot [Applause] do we have any questions yeah thanks so much for the talk

um one thing I'm wondering is like in web 2 a lot of the times when they ask for permissioning um they ask for pretty much access to all uh resources right and there's kind of this assumption that well if it's an app that I trust and they ask for admin privileges I'm just going to Grant it um how do you see that uh you know potential kind of social engineering attack uh in the web3 space yeah I I think what's interesting is that they're in web 2 as you mentioned there is this like default trust assumption because we have the nice reversibility characteristic um I think to for anything like this to work in the web 3 context it would need to be a default untrusted assumption so until an application or a new party earns the the privilege to be trusted with some certain action the default

should be to not trust but given that assumption we can then I think get to very similar levels of interaction makes sense thanks amazing thank you very much [Applause]