Upgrade Summit 🚀 Join us for the ETHOnline 2023 Upgrade Summit!

[Music] uh I'm me Tai can you guys hear me okay everything's great awesome I learned uh I don't know if this will work but I learned there's a new Apple trick let's see if this works yes it does great this is is my new entry to every uh video call going forward uh but that yeah exactly this is your incentive it's uh there's also balloons but I'm not going to show if goes well we're that that's right that's right this is this is really this is the just so everyone knows this is the highlight of the presentation everything is downhill from here but uh we will uh start should we start should we get going let's do it so uh uh we will talk today about two erc's actually so ERC 1271 which is the topic is about but also ERC 6492 which is important especially within an account abstraction world and we'll get to it but it deals with contracts that have not yet been deployed uh we'll start with a couple things on the agenda uh let's see if this works uh we'll talk about uh Dynamic which is the company I'm the co-founder of just in 60 seconds so you guys have context as to why I'm here and actually talking to you we'll talk about the smart wallet Revolution and why uh these are important eips and essentially erc's uh we'll talk about some of the challenges is with signing uh with smart contracts uh we'll talk about the two solutions and we'll uh leave you with a hopefully an optimistic note about the future uh but with that real quick uh about Dynamics I'm I'm one of the co-founders uh Dynamic um has been around for about two years we're backed by uh a6z and first rank capital and salana and circle and a bunch of uh other amazing folks and really what we do is kind of an all-in-one Authentication platform so uh if you go on sound or token proof or Anoka or longside or or parcel or Doodles and you click log in that's powered by Dynamic you can either create embedded wallets or you can log in with uh kind of thirdparty wallets in the context of why I'm telling you this is because we deal with ERC 1271 on a day-to-day basis right we have to deal as a provider to daps uh we have to ensure that if someone comes in with the smart contract wallet they can sign into that dap so that's the context for why I'm here and why I'm talking about this um the just so folks know the dynamic product and this is not I do not mean this as a sales uh uh kind of at all although I wouldn't be a Founder if I don't at least mention uh the company uh you know that I worked for uh this is what dynamic looks like so it's essentially kind of a multi-chain wallet adapter on steroids so you can do a bunch of really cool things with it it uh and if anyone ever wants to talk about it let me know but this is the last I'll talk about us until the very end um and we'll actually talk about uh the topic at hint so if anyone has been in web 3 for last year and uh has been living under a rock uh then you might not know but besides that the smart contract wallets are coming uh and really what we think will happen over the next couple years and the reason these erc's are important is that the web is kind of moving to a account abstraction based world right it's essentially a combination of a couple really cool things the ability for you to spin up a private public key type um kind of you know system for for users so a wallet per user but also make that wallet super smart so make that wallet something that can do a bunch of really great things so uh in our vision in the way we see the world is that if you fast forward a couple years every app on your phone has some sort of smart contract wallet a tab to it might be hidden you might not know it exists but it will be there and it will allow you to interact with other apps it'll allow you to transfer money it'll allow you to kind of interact with games and so on uh sometimes behind the scenes sometimes in uh kind of a center stage but that's kind of the world we're living and moving to and that creates a bunch of really cool opportunities but a lot of really uh uh challenging problems right and if we think account about account abstraction we had Dynamic kind of divided into uh two types of wallets we think about branded wallets so wallets like sequin or Argent or embri and and and others um and some multiple up and cominging ones that essentially are a wallet that you have on your phone uh you pull it up but it is a smart contract wallet so it is not just an eoa just just a single private public key and and some basic stuff on top of it but it's a contract that has been deployed or about to be deployed uh they let you interact with other uh contracts on on ch right and that's one category the second category uh that we think about and is a fascinating category where we spend more of our time is the embedded wallet category so um how can you log in with an email or social to an account and spin up as part of it a smart contract wallet that let you lets you sponsor gas for your users lets you create session Keys social login and so on and there you have really interesting players like Zer Dev like alemy that just announced some cool stuff uh over the last couple of days there uh and that's where where we're gonna focus a little bit more uh now if anyone's interested uh on the account abstraction side and again these are all kind of just contexts for whyc 1271 is important uh you have this massive ecosystem that's spinning up right so you have wallet sdks you have uh smart wallet apps you have kind of gaming Focus sdks uh infra so it's a pretty kind of healthy uh ecosystem that's growing uh in order to make everything an account abstraction wet now by the way I'm this is an extremely long monologue it sounds like we'll take questions at the end but please note them down and ask me anything uh as you can tell by now I can talk for a very long time so at the end please pause uh stop me and ask me actual questions about uh all this stuff uh let's continue so uh the last thing before I dive into the details is um as developers we should be focused on creating flows that people want and if you take nothing else away from this conversation take a single thing which is no one besides us cares account about account abstraction and no one besides us developers cares about EIP or erc1 1271 right and that inherently means is everything we're going to talk about is about how do you abstract that away from end users right no one cares no one should care no one should care that you log in with your Google and you're using oos no one should care and that is one key takeaway I want to make sure everyone gets as we dive into the details so let's talk about the actual details the very basic premise is the following when you uh want to sign a message as in for instance sign in with ethereum you uh generate Anns and will go through it and you have an EA a regular wallet sign and return that you verify it and you're good to go the problem is in a smart contract wallet the signer is is the contract not the private public key uh that is the signer for the contract right and the Second Challenge there is because smart contract wallets have all this cool functionality around signers there's no standardization for what uh can be used as a signer right there isn't a standard ver uh validation method so unlike an EA externally owned account so a basic account uh that can use uh EC uh ecdsa and kind of keep it to the very Basics there's no standardization around smart contract wallets in how signing works now I'll say one more thing here which I'm not going to go into details in this deck but there are some interesting blog posts out there about it which is this is doubly true for things like safes where it's not just an account abstraction wallet but it has multiple signers so there's an async nature to it so when you deal with smart contract wallets as compared to externally owned accounts you inherently deal with an order of magnitude more complexity as to what can be accepted as a signature and that is what inherently erc1 1271 tries to solve at the very basic level it tries to create some sort of method that allows you that appap developer to verify a signature uh from a smart contract let's talk through what that means so how regular signatures work and we alluded to this but let's dive in the server requests a unique message right with a nons uh to sign right the there's a hashing uh component and then uh end user using their private Key signs the message and the nons signs the hash essentially and then the server using the uh EC recover method can actually just validate that and they're done so that inherently means what that means to an end user is they go into a website they click login with metam mask they have uh signning with ethereum popup they sign a message and they are good to go they finish the process now again with smart contract wallets it doesn't work that way right this is where erc1 1271 comes in so who needs it what is it used for it it's implemented by daps it's implemented by openc by sound. XYZ uh by uh you know uh fair. XYZ any any company that um is big enough and supports uh wallets usually has an implementation of ERC 1271 they either have done it on their own they use a service like dynamic or other services similar to that uh what what this uh kind of EIP does and E uh proposal does is the following it introduces into the smart contract an is valid signature uh function which the DAP can call and get a standard response as to um to how to sign or or to to sign and verify ownership of the contract and we'll see the function here in a second but the basic idea is that it introduces uh kind of the ability to adjust in is valid signature uh type um uh function and check the signature using that versus using EC recover so at the very very basic level what you're doing is you're introducing an if statement right where you check hey does this uh signature match a regular EA wallet or it's a smart contract wallet signature if it is if it's uh EA use this method to verify it if it's a smart contract wallet use this method to verify so at the very basic level you're introducing kind of a fork in the road for how you verify signature right uh the actual function uh here and we'll we'll talk about it uh briefly is on the left is kind of the the uh the way in which the validation is done right so checking whether um they're actual checking inherently whether the signature uh it complies with is valid uh uh signature on the right and I apologies for everyone for presenting C Cod on screen and and hoping everyone reads through it so I can send Links at the end for for where to actually dive into this uh but on the right you can inherently see that really what we're talking about and hopefully you can see my mouse is a function to validate signature that breaks uh and moves from just kind of a single we to verify to an if statement that says look if you verify with if you detect it's a smart contract wallet verify using this method otherwise verifying us using this method so at the very basic level you've introduced one fork in the road for how to verify things I've talked for a very long time I'm going to pause for 10 seconds as and if people ingest this um then we're going to continue to one more level of complexity so now that we've done this we have one more level of complex just to keep this interesting what that inherently means is the following with 4337 which is smart contract account abstraction coming in what you see is this really really cool uh method and be me for a second as um I just let my uh doging otherwise you will hear barking for a very long time but um what's really interesting is the following with account abstra action coming in um you have this really cool feature that was introduced which is counterfactual deployment what that inherently says is the following it says that I can actually get a contract wallet address a public address uh for a smart contract wallet before that is deployed on chain before the contract is actually deployed and that's really really cool because it means that if ie apologies I am uh I'm gonna kick my dog out as we do this presentation so apologies again but at the very basic level and sorry about that everyone at the very basic level what that means is that if you log in with an email account or Social account and generate a smart contract wallet you delay deploying it on chain you delay actually putting it on chain until later on in the life cycle until you actually have to run your first transaction and that saves significant gas costs that essentially means that you don't have to actually take gas costs into account until very late in the process that's really really cool but it creates a problem which is how do you verify a signature of something that has not yet been deployed right how do you actually validate uh that a contract that has not been deployed can sign and that's where ERC 64 uh 92 comes in so a second iteration of uh 1271 is 6492 which essentially gives you another method an additional if to verify a contracts that have not yet been deployed and that's really really cool and the way that works and I'm taking here in full credit to the zerod dev team for writing about this and mger uh Team for coming up with the law of the solution and so this is from the zero Dev blog at the very very basic level what you do is you introduce some sort of contract that validates a signature or checks whether the contract is deployed on Chade checks the address type to see whether its sequence is uh an an address that has not yet been deployed a counterfactual address and then essentially simulate running it uh and kind of using an eth call to simulate running the contract and get the signature based on that and then use his valid signature so inherently what that means is adap looks at a smart contract while it has not been yet been deployed simulates it and then gets an invalid his valid signature in order to sign uh and have validate the signature of that contract so it's a little bit of kind of uh ninja tricks but what it inherently does is it allows you to validate signatures for contracts that have not yet been deployed which is really really Co so it's not just about e uh erc1 1271 but inherently what folks have to do is Implement erc1 1271 followed by ERC 6492 in order to really cover the universe of uh verifying smart contract walls now uh I've been talking for a very long time and in a minute I'll I'll pause and and talk and and take questions if anyone has those and again we can send resources at the end um but I will say one thing here which which is um I would strongly strongly strongly recommend against doing any of this on your own the idea is that you have um you know uh ethers and V and you have libraries on top of that like Dynamic and you have um other kind of options that do this for you unless you are open see or unless your maybe Foundation maybe one or two others you should not need to implement this stuff on your own you should be able to use tools that exist that already support this stuff uh out of the box right uh it is not a good use of your time to write validate things and ensure they're validated correctly they're additional complexities specifically with account abstraction here which is a contract is deployed on deployed on specific chain so validating across multiple chains is is extremely difficult uh and if I you leave with nothing else here hopefully you leave with the with the takeaway that when in doubt don't implement this stuff on your own but rather use providers or use open source libraries to do that for you and with that a quick note about the future uh and this is again a Shameless plug for dynamic just for a second which is we fundamentally believe that what you're going to start seeing in the world is kind of this combination of a pass key based login uh and count abstraction on top of it so you're going to start seeing a lot of these types of uh products that let a user log in with an email address log in with social or log in straight with Pass Key generate kind of a a tua with a pass key and then at that point um at that point uh be able to um um to kind of spin up an account abstraction wallet on top of it and so you're going to see the friend Tex the world Etc really become wallets for all intents and purposes and really be able to interact with third party sites just like uh a rainbow or a metam mask would do right they would have a QR code maybe a wild connect or anything of that sort so this is becoming more and more relevant as everything inherently becomes a wallet as everything creates a pasy plus cap abstraction stack uh these types of VC's become critical for DBS to implement and uh I will leave you with an optimistic uh thing which is this stuff should matter to us for any developer on the line that is deep into web3 it should matter to you and to no one else the idea is that no one this should be our secret no one should know about erc1 1271 no one should know about additional year season they should be invisible to end users they should be invisible to 99% of developers it should just kind of work right no one should know about the just like in if anyone has web to experience no one should know about the nuances of saml no one should know about the nuances of ooth no one should know about the complexities of tops that is for us to know and for 99% of developers to just continue with their day to build the experiences uh they want and so that is the another I think I have two main takeaways at this point I will say this is the third one uh around um uh ERC 1271 and so forth