Web3 Galaxy Brain 🌌🧠

Nicholas: Before we get started, if you love this episode, please send it to a friend. Thank you. Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guest today is José Aguinaga. José is Head of Digital Custody Services at Ceiba Bank in Switzerland. He was previously Head of Engineering at Hopper. José is also the creator of Passkeys.is and MPC.is, two valuable educational resources that describe and demonstrate passkeys and multi-party computation, respectively. On this episode, José and I go deep on elliptic curve cryptography, ECDSA, passkeys, homomorphic encryption, distributed key generation, account abstraction, smart wallets, and much more. If you're interested in the frontier of self-custody smart wallet user experience, this episode is for you. It was a pleasure talking to José, who is knowledgeable, humble, and generous. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice, or any form of endorsement or suggestion. Crypto has risks, and you alone are responsible for doing your research and making your own decisions. Hey, José, how's it going?

Jose Aguinaga: Oh, hey. How's it going, Nick?

Nicholas: Good, good. Good to hear from you. Nice to meet you.

Jose Aguinaga: Hey, likewise. Thank you for having me here today.

Nicholas: Of course, I'm super excited. I don't remember exactly how I discovered passkeys.is and your passkey expertise, but the site is very clean and a great resource, and I'm really excited to get into talking about passkeys and AA wallets and everything else you're interested in.

Jose Aguinaga: Hey, thank you. Yes, it's been a little bit of a separate for me, but I pretty much have been wanting to set up kind of like just a little source of information for other people who are struggling with the matter. So, hey, that ended up being just, I don't know, I'll put it maybe a grocery and then started growing into something else. I know it's out there, so I'm super happy to talk about it and talk about other things going on in the ecosystem around passkeys wallet, MPT, and yeah.

Nicholas: Awesome. So tell me a little bit about your background before we jump into the passkey stuff.

Jose Aguinaga: Sure. A little bit about myself. So I've been working in the blockchain ecosystem, I don't know, since 2016. Funny enough, most of my career I've been based in Switzerland, where I'm currently speaking from, and I did a stunt in San Francisco. I managed to do a small software engineering job actually. But at that point of time, I think I got so used to the European lifestyle. You'll probably see the memes around there, but yeah, ended up going back. And when I, at that point, I was already getting familiar with a blockchain ecosystem and I will say startups and fintechs were already getting interested around that area. And yeah, I quickly switched into, participated into a, you know, your traditional ICO in 2018, but I started doing some consultancy around crypto. Then, you know, the whole space took off and eventually took one, two, three roles and one thing led to another. And then, yeah, I mean, fast forward, I would say I've been taking mostly engineering roles in layer zero projects. The latest one I was in HopperNet, which is a privacy mixed net developing solutions on top of the TCP layer for RPC and other similar stack. Then I did recently almost two years work at CryptoBank here based in Switzerland. And I know the word crypto and bank usually are not in the same sentence, but that is not uncommon in Switzerland. And yeah, so I've been getting very familiar with the institutional ecosystem. And in the meantime, what I'm, what I was trying to understand, I'm trying to figure out, because I really come from the more cryptography background, so to speak. I wanted to understand how the enterprise sector was viewing the blockchain. So I came very from the, you know, we'll call it maybe DGN side of things, very DeFi, very, you know, just, just ape into whatever project you could find in 2018 to then understanding how institutional investors and fierce institutions and banks are actually poaching a conversation. And currently in that context, and that's where I personally actually found past keys, because in the enterprise sector, you're always thinking about security delegations, the creation of duties, all these fancy terms that, you know, put people in suits at ease, but they're, they're actually quite relevant, right? Because, I mean, if you want to handle operational security on a major level, then it's actually important. So past keys, I mean, the standards, and I think maybe, maybe actually from, from Snowball, the previous podcast share a little bit about it, right? It has been around, it has been around for quite some while, but the, the reason why I took off is because of course, Apple integrated with NiCloud versions. You finally had a little bit of a backup. And I think that's when, you know, other, other, other companies and enterprises started to look at it into more serious matter. And of course, also as well in the crypto system.

Nicholas: And just before we jump into the, the elliptic curve and, and past keys and all this, what is it that you're passionate about? Is it the blockchain, cryptography, the enterprise integration? What, what brings you to the space really?

Jose Aguinaga: I will say really the blockchain. I mean, to me, my really, the first thing I really got engaged with was, I mean, as many of us into Bitcoin, the ability to have a mutable, distributable, open ledger was for me, fascinating. As I mentioned, I worked in the fintech industry for many years and I always, quote unquote, hated the, the, the entire database discussion. You know, like you're always, when you're running, you know, a startup and you're in a company, you're always handling other people's data. And maybe at the very early beginning, I saw a lot of the issues around that, and I never really enjoyed working into the, you know, database section of engineering, which is just very normal, especially, you know, if you're working in your, your web to 2010 kind of startups and you're always spinning, you know, infrastructure for other people, you're always building and let them come. And, you know, I never really liked it. And then when, when Bitcoin came and I discovered you could append small data and people started doing experiments around it, I was like, yes, this is amazing, right? Like you can finally have some openness and you don't have to trust this small startup that are actually taking care of your, your data or credentials or whatever, but you can actually have this distributed ledger. So for me, I, and, and in addition to that, I will say that I was also picking cryptography as, as a, as a, as a topic that I wanted to understand. that I don't think I paid enough attention during college. And then I was like, okay, you know, finally I find something that is just not your quote unquote, boring, you know, secure certificates and the things that you only, you know, hover with when you're doing a normal application and I get hooked up. So if you add blockchain distributed ledger and then public key cryptography, I mean, we can talk just about that for hours. I would say the crypto part of things, it's very interesting. I mean, I really liked the whole DeFi NFT space as well, but I probably didn't engage as much as our friends that I were, you know, very into the whole trading speculation or, you know, DeFi somewhere.

Nicholas: But you're by the sounds of it, kind of a rare breed in the sense that you're interested in the cryptography all the way through to the application layer. So I guess that makes sense. why you're interested in passkeys? because it really sort of addresses both parts.

Jose Aguinaga: Yes. And I think that's also why I think other people are being drawn to it, because I would say it's, as you mentioned, it's an application technology that people can relate very quickly, right? You can just click a button and you see this beautiful UX that, you know, almost all browsers, almost devices, it's just like, oh, you're creating a key pair, right? And people are starting to get familiar with these concepts and they understand how they're way better than, you know, traditional solutions. And I think that's what I think. They're very powerful, right? We're finally aligning ourselves and understanding that passwords are not great. And, you know, we have seen this movement in the industry for moving to magic links, to moving to password logins, right? So passkeys is, as you mentioned, right? It's very interesting and I got drawn to it and people are working on that because it really grabs a very academic concept, which is public key cryptography and just push it up to the user and application.

Nicholas: So before we jump into passkeys, what's the essence of elliptic curve cryptography and public key cryptography?

Jose Aguinaga: That's a tough one, right? So in terms of, I mean, we want to get it.

Nicholas: I have some tough ones in store, don't you worry.

Jose Aguinaga: I think depending on how academic you want to get, but for instance, what are the benefits of elliptic cryptography? I'll speak on the things that most people in software engineering would understand. When you are handling traditional private key, public key mechanisms, if you think about modular or modular space arithmetic, then that has its flaws, right? It's very expensive computational-wise. Usually the bit size of keys that you need to use is huge. And you could have seen, you have seen these limitations or these challenges in the industry for many years, right? So SSH, all these keys that you have to manage and public infrastructure, you see all these challenges on traditional RSA keys. When elliptic curve comes and gives you a faster ability, a faster way to perform and identify common public points that you can agree, and then you can actually generate cryptographic material to then derive keys, then actually then you realize the key space that is needed is way smaller. Then you suddenly are able to look at the cryptographic conversation and say, "Well, why are we doing all these modular space prime number theory when we actually can derive and generate private keys that are faster, that are smaller in size?". And maybe five, six, seven years ago, before blockchain or any of these topics came into the mainstream media, the IT industry was already doing some push into shifting to elliptic curves because of these main benefits, right? So from a practical software engineering point of view, they have very clear benefits into how do they operate. And what it really became very clear that they had an upper edge is in signing, right? So ECDSA, the most common signing, I will say elliptic curve based algorithm over a generic payload. It's incredibly fast, right? And it's incredibly fast. And it's something that we probably were not used to seeing in ecosystem when you see other options in the market.

Nicholas: When you say fast, it's fast to verify or fast to sign? I guess signing is always fast. It's the verification that is the speed delta.

Jose Aguinaga: Correct. Exactly. And you imagine, right? I mean, we're talking about the cryptographical system. It has been everywhere. Maybe the web or traditional, well, not traditional, but one of the most widespread use of technology for software engineers is the web. And the web was not as exposed to these sort of tools and these sort of mechanics until maybe 2016, 2017, when the web cryptography API was actually launched. But a lot of, you know, you're a mind trained developers, you're aged 10 people, like all people, you know, that have been working on MasterCard or Visa, they hadn't been dealing with all these things for years, right? And they see this in the middle of the shift. I participated in one of the digital residency programs here in the European Union, a pioneer by Estonia, where they issue kind of like that Estonian ID. And then you're ready to see that they were using Elliptic Curve 384 to generate your smart card. And this is 2016, right? I mean, almost 10 years ago. And this is incredibly interesting, right? And this is just because these cryptographic primitives are way, way better, way faster as we have already discussed than the tools that we've had in the past. Mostly, of course, I'm talking about RSA.

Nicholas: I like how you say 2016 is almost 10 years ago.

Jose Aguinaga: Yeah. Maybe I'm thinking too much in the future, but I'm just pushing for that 10 years.

Nicholas: You're a forward thinker. So ECDSA is like a specific implementation of Elliptic Curve cryptography. Obviously, we're familiar with ECDSA from the Ethereum context, but maybe can you explain a little bit about what it is relative to Elliptic Curve cryptography in general?

Jose Aguinaga: I mean, in terms of digital signature, I mean, the part that it's important is it's mostly because you can actually do a signature on top of finite fields, right? So that is one of the main advantages that you have when Elliptic Curve cryptography. And as I mentioned, this actually revolves into faster computations, reduces storage keys and everything we already discussed. But the part that makes it important is that you can actually use, I will say, maybe put it in one simple way. You can use a public coordinate and base it into a message hash. You can actually compromise it, usually two integers or something. You can verify the staticity and then use Elliptic Curve operations. So this multiplication on two points is the ability to be able to verify that a hash of a particular message has been generated by the corresponding private key of the rabbit in the public point. Now, this might not, I mean, this sounds like a lot of gibberish and again, but if you understand what we had before, so if you understand how modulus number theory do that traditional Diffie-Hellman and public key exchange, then you see this is incredibly interesting because usually to calculate your traditional public key, you need to do exponential number, you need to calculate huge prime numbers, very ineffective. And you have some benefits, which is the ability to have encryption and decryption out of the box, just the way how the most RSA works. But for digital signature, and again, the DSA is of course digital signature algorithm. It's probably among the fastest ways we have right now to verify the authenticity of the owner of a particular private point, right? So that is for a lot of solutions. And again, we're not even touching about cryptocurrency, we're talking about blockchain. For a lot of solutions in the market, you only needed a signature. You don't need it. I mean, you still could see how some governmental applications and how companies were using what was the most common standard, RSA 2048 bytes to generate a signature, which was just like, ah, this is, you know, it's like, you know the phrase, right? When you have a hammer, everything looks like a nail. So sure. Let's, let's go ahead and use it. It was never, I will say that, and I mean, maybe I'm speaking too much on behalf of a lot of encryption people, but it was never meant to be kind of like you to go to, like people have been looking to multiple DSA algorithms for, for years. And once we, we find, found curves that we could agree with and we could feel comfortable with, and then you can open that, you know, the whole discussion about these curves and, you know, safe curves and all whatnot. But when we get to that point, but right now, once we agreed, you know, we have some basic safe curves, then boom, let's go full speed. And then you could see, and you saw in many, many online applications, such as GitHub and so on. And it's like, oh, you can actually use your elliptic curve based keys. You can use any sort of Edward based curves. And then you're like, oh, whoa, this is, this people, then people started looking at it. I was like, oh, why, why we're not, why I'm not going to use my traditional RSA, you know, the typical tutorial that we'll do in RSA and they will shift into elliptic curves. And I will say at this point, the general common understanding is that they're superior and in all ways capacity when signature is needed. I mean, you can, we can talk about encryption elliptic curves, but I think that is usually most people don't use it, although it's, it's, it's part of in some protocols and some, some data exchanges for, for especially also actually an NPC where you need to, to also do some encryption and create some secure channels. But for now, I think ECDSA, EDDSA are most of the algorithms that people know and the advantage on their, their improvements over traditional ones.

Nicholas: And when you mentioned the GitHub application, you're saying for signing commits, for example. Yes. So you can be sure that the person who made a commit is really the person they claim to be, not just someone who has maybe the, the password to their GitHub account.

Jose Aguinaga: Well, no, that's a different, so just in some capacity, but the first thing that people did for elliptic curves in GitHub was not around PGP commits, but more on, we'll verify commit using PGP keys, but more on connecting to GitHub. So usually you create your SSH key for your local machines, such as when you push into a cloud repository, in this case, GitHub, then GitHub says, Oh, you are who you say you are. I'm going to allow you to push on behalf of this user that you have registered. And since the inception of this, this is what I mentioned about one of the advantages of, of elliptic, elliptic curves over a traditional RSA based cryptography is that they were huge, right? Like if you wanted to, to put like a 4,000 bytes elliptic, sorry, public key, then you had this chunk of data. And then imagine that, you know, if you're a company, you have to handle four kilobytes per user, then it can get fucking chunky. So this is mostly what they were used for authenticating yourself against a remote server, SSH on all people that they, all the DevOps in the world and all the systems, they have been doing all this for years. And when elliptic curves were supported by SSH, it was a breath of fresh air. Let's put it that way.

Nicholas: So the private key is smaller and the corresponding public key is smaller also. Is that right?

Jose Aguinaga: Correct.

Nicholas: Fascinating. Okay. Well, I'm glad we, we, we covered some of the basics and not just jumping into the, the more fun stuff, but now that we've done that, maybe what is a passkey? And what's the point? What, from a user's perspective, what's the point of a passkey versus say a password?

Jose Aguinaga: Yes. So from a standard, let's put it as well, from the web standard, the Web3C standard, passkey is nothing but the quote unquote commercial name of the web out and workflow for generating a key pair into a user's device. So passkey was a little bit of, it was, it was maybe marketing for, let's say Apple passkey, but it's kind of like the, now the to-go word for describing the, this web out and workflow where your device uses biometrics on whenever it's available or any sort of, I don't know, we'll get into that, but we'll, it can use biometric authenticators or roaming authenticators, aka UB key or some sort of any, any sort of hardware based device to then generate a private key and public key on your device. The, the important part here is unlike traditional security generation mechanisms, these, these standard ensure that the generation was done on your device and the privacy will never be exposed, but you could still find data with it. Now the, the passkey and what we understand as passkey is that it's just a key pair that is expected to be used within a traditional web out and workflow, which means to register your public key of your device to a web out and enable server. The server then keeps the public key of that particular key pair. And then whenever you come back, you match, you, you, you match the username to that public key. And then the server request is with this public key and you provide a signature against that to showcase you and you, you all have the private key of that public key. And then the server grabs a signature, which you can then verify very quickly, very fast. Again, let's take her again, the public key that they have in store now.

Nicholas: So, so before you go, so to summarize for someone who is maybe more familiar with the cryptocurrency blockchain space than the cryptography space, passkeys and WebAuthn are kind of a set of procedures around an elliptic curve. or would you call it ECDSA as well or not?

Jose Aguinaga: Yes, for sure. Yeah.

Nicholas: So it's very similar, but it's like the same technology, private public key pairs, but a standard process around generating them and interact on device and interacting between the device and the server for authentication under this WebAuthn protocol. But under the hood, it's really the same kinds of technology and process as getting a wallet for Ethereum or Bitcoin and having it generate the private key either on your Ledger or Trezor or Metamask or Rainbow or whatever you might be using. But some specific interaction on top of that, that requires the private key be generated on the device itself and some standards around passing the public key to the server so that it can authenticate you in the future.

Jose Aguinaga: Correct. I think that I will say that the only thing that is different and this is more of a feature than a bug, I will say, is that the passkey/WebAuthn workflow was never sort of intended to be an isolated ECDSA sign-in mechanism. So it was always expected, the passkeys were always expected to be created within the context of WebAuthn. And what that means is that you can, as mentioned, you can have the same behavior you have in your traditional Metamask wallet, which you generate a key and then you have the public key and then you use public key to derivate your Ethereum address account. But in the passkeys world, A) you never get access to the private key, you have no way to get access to the private key and B) that public key that you have to be able to derive any sort of account addresses in whatever blockchain we're working with is expected to be sent to a third party server. And we'll talk about this and I'm sure about it, but now we're not really doing that. We're not, we're kind of like using something that we found that was meant for something else and we say, "Hey, why don't we do some blockchain magic with this?".

Nicholas: So before we go any further, can you just define WebAuthn?

Jose Aguinaga: Sure. I mean, Web Authentication, I think the full name is just Web Authentication. It's just not much. I might be mistaken, but it's definitely a worldwide web consortium. So we treat it as the standard and it's part of the FIDO2 specification. If I'm, again, just take it with a grain of salt here. This is all the standard that pretty much ensures or guarantees that a password is no longer needed for engaging in an authentication system. So an important part is that WebAuthn is always trying to target a multi-factor authentication. It was, it is not really, the goal is not always to just fully replace a password, but instead being a supporting authenticator against a user's identity. And right now, if you think about a traditional second-factor authentication, you will have like OTP, SMS, which you should never use, as we have seen in recent events, unfortunately. But there was never a standard for that sort of second device that supports you. WebAuthn was that, or WebAuthn is that. It's the standard for generating a passwordless authentication process using roaming or biometric authenticators and creating an attestation that allows you, on a private matter, create an authentication layer for whatever platform.

Nicholas: So it's a standard from W3C. It's an API that will be accessible anywhere where a modern web browser or OS exists. And it's sort of standardizing all these private-public key pair interactions between the web application or native application that you're interacting with and a server that it's trying to authenticate with. And that's basically what WebAuthn is, right?

Jose Aguinaga: Yes. I think one part that we should not make this as a small feat, like the fact that all major vendors like Chrome, Firefox, Edge, Safari, they have agreed on this and they have implemented it successfully in most modern browsers and operating devices. It's a major peak.

Nicholas: Yeah, you're right. We shouldn't ignore. So Google, Microsoft, Apple, YubiKey, Mozilla, everybody who has a major stake in the platforms that most people are using is adopting WebAuthn as an extension. pass keys. Correct.

Jose Aguinaga: I mean, now you made me open, can I use WebAuthn just to see the adoption?

Nicholas: Double check.

Jose Aguinaga: Ninety percent. Yeah, that's, I mean, anyone that has been in the web ecosystem for the past five years plus, anything that has 90% is amazing, especially because it's also not that old, like. it's not that new, but it's also not that old, right? Which is, it's impressive.

Nicholas: So yeah, I see on the site, they say since January 2019, it's supported in Chrome, Firefox, Edge, and Safari. So pretty good. Pretty, pretty recent, but almost 10 years ago, right? So, okay. So how do pass keys differ from the ECDSA, and this is going to be a mouthful, but the SECP256K1, or we'll just call it K1 for short. The K1 elliptic curve that we're familiar with from Satoshi having chosen it for Bitcoin and ultimately Ethereum inheriting the K1 curve. What's different about pass keys?

Jose Aguinaga: Yeah, so that we're going to do a lot of SECP256K1, but usually the easiest way to describe it is by the last two digits. So K1 stands for a public score. So that is usually the curve that is used as a reference point for calculating the public key. And then on the R1, it's a random curve.

Nicholas: So just to be clear, R1 is the pass keys variant, and K1 is the one in Bitcoin and Ethereum, or EVM, I should say.

Jose Aguinaga: Exactly. And this curve is a very specific curve that allows specific automated operations, even particular use cases. And again, that's the one that was picked by Satoshi in its white paper, and it became very famous because of Bitcoin and the Satoshi white paper, right? I mean, I think it was not, if I'm talking about, again, just moving from the cryptography enterprise worrying world, I will say that cold scores were not as popular because usually in the enterprise sector, you have to use the National Institute of Standards and Technology, aka the NIST curves, because in many places, particularly if you ever did any governmental-based contracting work, those were the tools that you were pretty much forced to do, right? And that's why pass keys uses R1. Now, as you probably already mentioned, and I think it was already mentioned in one of your podcasts already, one of the reasons why Bitcoin and Ethereum was picked the cobalt curve was because there were always rumors about potential backdoors around the R1, the random elliptic curves. But as of today, that's still just kind of like a word in the street, so to There's no proof whatsoever. And that's why, as of today, you have major tech billionaire, billion-based companies that are implementing this as part of the cryptographic ecosystem. And that's why path key is the R1 or P256.

Nicholas: So if people want to hear more about that, they can check out the 7212 episode from a few weeks ago. But in short, the elliptic curve is described by a formula. And in the K1 variant, some of the constants, some of the numbers in the formula are zero, which makes it faster to compute. And in the R1 variant, these constants or coefficients, I don't even know, but some of the numbers in the formula are chosen by, well, I guess I don't know the details of the process, but the NIST standard has certain numbers in those positions, wherein the K1 curve that Satoshi chose, they're zero. In the NIST-approved R1 curve, there are numbers there. And there is no openness in the cryptography community about where these numbers came from, which makes people worried that they are very specific numbers, that maybe somebody involved in the design process has some insight into a backdoor where they could, I don't know, I guess the fear is that you could generate, you could detect with a private key from just having a signed piece of data. Right. And also potentially, I mean, if you can do that, then you can also forge data. Forge signatures, I should say.

Jose Aguinaga: Yes. It's a lot about, yeah, exactly, about a signature forging and delivery of signatures, being able to leak information, make some signatures. But that's, I mean, that's really also out of my deep, right? It's, this is a, it's a heavy, this heavy prime-based aromatics that even the numbers and the parameters, like as you mentioned, I think that was a very good podcast. The issue is the transparency, right? The way some of the standards were picked and the way that the formula is based, you nailed it, right? Like, so I believe maybe B, maybe A, the parameter that is zero on the Copland's curve.

Nicholas: Right. So, and we talked about it a little bit in that other episode, but being zero for those constants makes it a little bit faster to calculate, which may be one of the reasons why Satoshi picked it. But also, yes, what was I going to say? It's zero, but also, I guess the concern is that there's some John Nash character in the background who has figured something out about the, these particular numbers for the R1 variant. However, it has been adopted by all of these major corporations. Not clear if that's what that says, but the takeaway that most people seem to have is that because it hasn't been proved to be compromised so far, it's more or less okay, maybe especially for consumer applications. But if you plan to have a vault with millions of ether in it, and you would like it to be the most secure possible, then maybe you don't want a passkey as a signer that can control those assets.

Jose Aguinaga: Yeah. And again, I think what it's, what passion is, what it's really, I'm going to use maybe a fancy word, really cool about it, is that, I mean, you have to understand that elliptic curve math has been around for years, like more than 30 years. And this is not me exaggerating, as if I'm saying in 10 years into the future, right? I think the original couple of curves work, it wasn't from the 80s, maybe. I mean, I need to double check again, but a lot of the mathematics around these digital signature operations and a lot of these ciphers and just general cipher and curves, it's over 20 years, right? Nobody was thinking, I mean, I think the first digital cash paper was early 2000s, like just the very, you know, before the Satoshi paper, anything around that. And even, I mean, people were recently on Twitter, probably like, oh, there was some work about it, NASA in 1997. Yes, still all the bricks that we are building or, you know, or castle on top have been around for 30 years, right? So nobody ever thought that we could use these primitives as a way to secure millions and millions of dollars, right? So that's just the fact of the ecosystem as it is today.

Nicholas: We did talk about it slightly on the other episode, but it is a shame that these constants in the R1 variant were not summoned with like a KZG ceremony style process, so that even if all but one actor is dishonest, then you get a good source of randomness. It's a shame, and I wonder if NIST is thinking about incorporating that or not.

Jose Aguinaga: I also think, so definitely, that's an interesting way to solve some of the benefits of all these key ceremonies. But I also will say that maybe, and this is playing too much of Dale's Hypocage, the amount of cryptographers that Bitcoin and Ethereum has produced over the last 10 years, I guarantee you that is tenfold. That's, you know, working for your PCI, smart car, master card provider in the 90s is huge, right? And I think we now have a very different set of tools and a different approach of some of these solutions, just because this field became so exciting. I mean, it's the same with AI, right? I mean, I still remember learning about AI in college, right? And that is definitely more than 10 years ago. And it was nothing, right? I mean, nobody got excited about backtracing. I couldn't see anybody. really, you know, we had at 7am in the morning these classes that people were just struggling to just go through, right? Because it was just not sexy, right? People were talking about distributed computing, and there were other things that people were paying attention. It was the same with cryptography in general. As I mentioned, I never really, it was hard to see the value of understanding the underlying black boxes of all these magical processes. You really had to be captured by the math or by the algorithms, right? Even the history, there's a really good history, I think it's called Codebook, that describes the history of cryptography and ciphers, and you probably know the Caesar cipher and all the things. Cryptography or the art of hiding things has been around or human history for millennia, right? But we now have a very clear use case, like people that are smart enough to understand the cryptographic primitives around blockchain or can get really good paid jobs. They can maybe become security auditors, not saying hackers, but yes, that can also be a path, which was not an option anymore, the same way that now your traditional machine learning expert can become an AI or pump engineer if you want to, and also get a very good situation. And for instance, maybe this could be a good segue, but MPC, right? So MPC, again, has been around for the past 40 years, and nobody really put attention, everybody knew about the millionaires problem. And then suddenly someone say, what if we do actually distributed key generation? And then why do we use it for this particular use case? And boom, now we have multi-million dollar companies in the enterprise sector, providing data custody solution on MPC.

Nicholas: Yeah, absolutely. So basically what you're saying is Bitcoin is the rock and roll of cryptography, and maybe Ethereum and account abstraction and multi-party computation problems are doing the same thing around even further topics in deeper, this deeper area of multi-party cryptography that previously was quite nerdy, but now has a real practical application that we'll get into.

Jose Aguinaga: For sure. I mean, before you wouldn't hear much about elliptic curves in many places, but hey, now you can actually engage and hey, listen to a cool podcast about it.

Nicholas: You're too kind. So just before we jump to MPC, I just wanted to really be clear, when you create a passkey, the passkey, the private key is created on the device, and then the public key is communicated to the server. Is that the only information that's communicated to the server? Like, let's say, if I make a website, and I want you to be able to log in with a passkey, I can ask you to create a passkey in the website, and then I just receive on my API, on my server side, I just get the public key?

Jose Aguinaga: You also get the raw ID of the public key, well, the key in general. So it depends on, so usually what happens, so there's a few things. So the first one is the server doesn't, you can execute, and this is one of the things where I think I got sucked into passkeys. You can use passkey without a server. Like you can tell a browser, hey, generate me a key and have no server involved. This is extremely important. And again, it was not meant to be the case, but that is a reality. You can choose once you complete the expected workflow of the passkey generation, to send the public key to a web app info, and that's how some MPC solutions like iGlue and Leap Protocol use to create wallets and all these things, but you don't have to. So that is expected workflow, but the prompt of the key generation, it's all client-side technology. And the second part is once the server side, or let's put it the counterparty, that it's able to authenticate you, knows information about you, usually they need a way to ID you mostly by a raw, like an ID that says, hey, this is the key that belongs to you or the public key. And the public key is extremely important because that's how you're going to verify signatures. But the browser specifications, they're going to always know, they haven't agreed on whether it's a must requirement. There's a couple options where you can say, you know, you also need to keep the raw ID. But for instance, and I think, again, Vivi commented on this, a little bit of a bad user experience is that you don't know or you can't know whether the user has a passkey that you have, right? So you have to prompt it, and then if they don't have it, then you have to create it, and it's kind of like a blind guess. But that's the two pieces of information, the public key and an ID that matches a unique ID for that key.

Nicholas: So this ID, is it useful for anything? How can it be used?

Jose Aguinaga: It's just a parameter that you use for prompting the key, to be really honest. It also, it's like an index, and I would say for the device.

Nicholas: Why not just use the public key for that? Why do you need this extra data? Is there a clear use?

Jose Aguinaga: I think it's just, to be real, and again, don't quote me here, but I think that it's just part of the specification. Like if you go, so when you are prompting, so the prompting of the WebOptain Workflow for the navigator.getCredentials, which is the code that is needed for prompting a passkey on a user device, I believe it needs the raw ID. And actually, it might not need the, okay, so I remember now. So the public key is what you as a server want to verify against. And the raw ID is the data that you might have for identifying the key that it's available on the user. So a better user experience can be that if you're able to actually can actually see and ensure, hey, please just prompt between this list of raw IDs, rather than all the passkeys the user might have. Not that much of a better user experience, but at least it's something.

Nicholas: So you mentioned this, you made reference to the conversation with Viv about Snowball and Igloo Tools, where she talks at the end of the episode about this UX problem. One of the, one of a handful of UX gotchas with passkey integration, which is you as the website or app developer, don't know if the user has passkeys already or not. And you are required to use two different methods on this WebAuthn API, one to sign in and one to create. And so you need to sort of ask the user which one they want to do. You can't just, you can't just present it like an SSO OAuth sign in where it's like a big Gmail button. Instead, you have to give the option. So that's a bit of a, that's a bit unfortunate. I don't know, do you have any sense of if that'll improve or kind of stuck with that forever now?

Jose Aguinaga: I mean, that's a little bit of very briefly what we mentioned about the raw ID discussion, right? So you can keep on the client side some information about the keys that you know, but the workflow, the expected workflow was always to be done against an authenticated user, right? So we discussed that the root resource of passkeys WebAuthn is to improve or to move away from the password list setup, but it always comes from an authenticated user. So you can not really, I mean, only in the crypto world, you can generate a user with only the passkey because we can do account obstruction and all this magic. but on the web-to-world, they have no idea about crypto and where this protocol was originally designed for. The goal is that you log in into your traditional user password, magic, whatever. And once you're there, you set up a passkey as a second factor authentication. Because again, we only allow the syncing of a cloud device these literally this year. And what could happen in the? if you only allow the user to log in with, let's say a passkey, if the user lost that device, then they couldn't access the system anymore, right? Which is just not the idea.

Nicholas: That's fascinating, because in the demo, I think it's on the FidoAlliance.org site, they have a demo where they show off sort of cross-platform passkeys, etc. And they even demonstrate a banking application and a workflow for upgrading people from password-based username, password-based authentication to passkey only. So it seems like they are at least a little bit aware that you might just want to have passkey authentication and ditch the password or whatever other kind of prior authentication and not use it as a second factor, but use it as, I guess, a second factor in the sense that you maybe are using biometrics and iOS or whatever operating system is the one that's authenticating you initially, but then that grants you access to the passkeys, which are really used to establish the connection with third-party services. So it seems like maybe they're becoming hip to it.

Jose Aguinaga: Yes, and I mean, I know exactly which demo you're talking about. And I think that's where exactly where the term passkeys come from. Because I do think within the context of Fido, WebAuthn, Serial Blockchain, Serial Crypto, passkeys was meant to be the thing that synchronizes over the cloud, right? So we briefly mentioned about roaming and authenticators. And I think the word is not biometric is, let me see if I have it somewhere here, cross-platform authenticators, right? So platform authenticators and cross-platform authenticators. So the difference between a biometric, let's say a touch ID, which is in your keyboard and a YubiKey that you plug into your computer, right? And in the context of passkey, that YubiKey device will always be on that hardware device. If you add that as your sole access to your system and you lose that YubiKey, then it's game over for you, right? It's never a good option when you have that. However, if you're able to synchronize across platform, and that's where the name, sorry, a platform authenticator comes from, then you can go to another device. Let's say I log in with my iPhone and I go out with another device and then the device is there because the passkey has been synchronized. And that's the powerful, I think, I'm quoting her too much, but I think one of the things that I think it was not, I'm not saying that she was mistaken, but I don't know whether the way she phrased it may have been a hundred percent accurate is that you cannot back up a passkey. I think the concept of passkey was always meant to have like a cloud version in mind. And that's the only operating system that is able to do that right now as of today is Apple. And even then, if you're even removing the key, the iCloud equation, for instance, you can back up a passkey with another iPhone. So even if you, I've done, as you can imagine, I mean, this is the whole goal of that passkey.is is that I do all these experiments and quirky videos and whatnot. If you have, let's say your iPhone with an Apple ID, Nick, and then I go close to you and you have been my contacts and I have a very different Apple ID, you can airdrop me a passkey for whatever login account. But the only condition is I have to, it's only airdrop and I have to be in your context. That is possible.

Nicholas: Other applications, other platforms are enabling this over QR scanning, right? It is possible to communicate them via camera, is it not? Or is that just for doing the link between a sort of dumb device and the device that holds the passkey?

Jose Aguinaga: Yes, exactly. So if you don't have a biometric device or any device that it's able to actually, that was actually one of the questions that was in the 4337 group, which is like, well, if I don't have a device and I see the QR code and I scan where does the key is generating is just a way to communicate between the two devices. And one device that is dumber than the other says, Hey, give me, give me a hand. Like I need you to, to, to generate this. And it's the same way. If you want to log in with that device, it will also prompt your QR code. And then you will sign the login part with the, with the mobile device. And then you will get access to it.

Nicholas: So that's familiar for anyone who's maybe, I don't know if it still works this way, but something like WhatsApp, if you want to use it on desktop, you scanner, there's a way to sign into discord this way. It's not the only way, but basically a QR code, which you authenticate from a device, like a phone that has biometrics. So the other device just has like a temporary session into it. So, so, okay. So maybe I confused the two and it's not actually possible, or at least I haven't seen it to be able to exfiltrate a passkey from a secure device over QR. They, they don't offer that. They just offer this kind of login mechanism.

Jose Aguinaga: Exactly. Exactly. You, you, you can not forward it from, from a QR device. It's just more like sign. I mean, but did you nail it, right? Like WhatsApp or discord, they have this, this workflow and that works great. It's just having that direct prompting director for your phone. And what is really cool is that right on most devices, if you have the camera, it will automatically prompt the, the, you know, the passkey workflow, so to speak, and without having you to download an app or being on the browser.

Nicholas: Right. So, so I guess maybe the point of all this is that it's, we're still stuck in this UX challenge over creating a passkey or signing in with an existing passkey because the original workflow was not designed to assume that that would be your only way of authenticating. And you'd be relying entirely on iCloud key chain, for example.

Jose Aguinaga: Exactly. And it gets more complicated with crypto, right? I mean, we, we, we have been on the sidelines with the whole crypto equation and the whole account wallet and what companies are doing and, you know, like whether you implement your own web out and server, and then that's how you validate against some sort of security model or whether you try to send that to a smart contract. But the challenge there goes into the storage of the public key. So you, you only have one part that is very important to understand. And I have it on my passkey that is, is you only get access to public key during the key generation process. Yes. So if you generate a key and a browser, and then you never keep that public key on a smart contract in a database, wherever you want to do it, you will never see that public key again. And then you cannot verify. that doesn't mean that you can not do something with that key, then you effectively lose the capability to verify the signatures from whatever that passkey is doing that. And that's dangerous because again, because we're moving, we have moved away so far from God, but because we have really using, you know, something that was not necessarily meant to design it for, for, for blockchain distributed ledger authentication mechanism. You can actually move ahead with a passkey that just don't store anything. You just say like, okay, I'll give you a signature, I'll validate against my smart contract, validate it, that it's a valid R1 curve, and then I'll activate my smart contract. Right. And that, yeah, I mean, that's dangerous. That's what I think I really like. expression of, you know, chewing glass, because there are all these, you know, little edge cases that are extremely annoying. And, and again, that's, that's why that website was created. And I need to really update it because there's more and more things popping out there.

Nicholas: So I guess we didn't really say it flat out. Maybe people who have the context of the other episodes on the subject will understand this. And if you haven't listened to them, the Privy episode 7212 and Snowball are the three so far, and actually obvious wallet this morning also. But the point we're driving at here is that you could replace something like MetaMask or Rainbow or Ledger or Trezor's generation of a private key that's compatible with Ethereum or Bitcoin or other blockchains with just a straight passkey that's generated on device in, let's say, Safari, or in an iOS app, or an Android app, or inside of Chrome or Brave or Firefox on a given website. And the passkey that's generated on the device and authenticated via biometrics and potentially stored in a cloud keychain or a local keychain or on a device like a YubiKey, that passkey could directly be a signer on an account abstraction wallet, which is a new form of contract based wallets where instead of holding the assets directly in a public address associated with a private key derived from a private key, you instead store your assets in a smart contract. And that smart contract allows anyone with whatever type of authentication you choose when setting it up to execute transactions from that contract, such as, you know, moving their ETH around, moving ERC-20s or NFTs around, or interacting with other smart contracts. And the benefit of this is that you can have iOS, Android, Chrome, Firefox, Windows native private keys that are built into the OSs and the web browsers such that you don't need a separate piece of software like MetaMask or Rainbow or Ledger or Live or whatever Trezor's equivalent is.

Jose Aguinaga: I mean, Yannick, I don't know what you have in here. You nailed it, right?

Nicholas: It's a little more complicated than that.

Jose Aguinaga: No, no. I mean, I will say two parts. And I mean, so the two parts that are really good are the key management. So yes, it solves the equation that is like, you don't need to have a key management solution because that comes out of the box with your device. AKA, you don't need a Ledger, you don't need a Trezor, you don't need any sort of aid to actually generate a secure key and find a secure key.

Nicholas: Or something less secure like a software wallet like MetaMask or Rainbow where they don't have direct access to the secure enclave because Apple, for example, doesn't include the K1 curve in the APIs for accessing their secure enclave. So they can't generate a super, they can't use the sort of the best form of private key generation because Apple simply doesn't support it.

Jose Aguinaga: Correct. That is, you hit it right in the nail. I think that there was one wallet, I need to remember, but I think it was Dawn Wallet that they actually open sourced their key management solution and they were actually trying to, you know, they would say like, "Apple, please solve this," right? Because we really are like not hacking our way through it, but like we're implementing as good as we can for key generation using libraries, audited and whatnot, but it's not natively included and so it's not supporting a secure enclave. But the second part, and I think this is even more important because key generation will get there, but the second part is the signing.

Nicholas: And this

Jose Aguinaga: is maybe if I hover into the enterprise sector and it's hard for the average individual in the crypto ecosystem to understand how much money and time is needed to develop a software or a solution that is able to, once you have access to a secure key, it's able to parse these magical bytes into something to make sense for executed transaction, right? So it's, you have that out of the box. You have ECDSA implemented out of the box. You don't have to do that yourself. You don't have to import the library. The fact you have both a key and an ECDSA implementation is extremely valuable and we're only getting started. I think, I mean, I know it's such a cliche phrase that we're early, but I talk with teams and we also only see that a lot of the times, right, from the Ethereum ecosystem, right? But there's a lot of companies and projects out there looking at this technology and really evaluating as an alternative for a wallet. If you are a new player in the ecosystem, let's say you want to launch your layer one, you know, your own layer one, you're like, I need to explore, I need to do bridges, I need to do wallets. If you have past case in mind, you might not need to, you might be able to have a wallet out of the box. Right now, yes, the closest we have to that sort of smart wallet abstraction is ERC4337 and that it's okay because I think the challenge is that, you know, you can not immediately pour that solution to a non-EVM ecosystem, whereas by having the key and by having ECDSA, you can support pretty much any cryptographic schema, right? So, for instance, Sui Blockchain, right? I think they are one of the predecessors from the original Libra Facebook meta ledger project to use the move language. They actually are trying to implement WebOutend as a workflow in the same way that, you know, EIP-7212. They're trying to do the same thing because at the end of the day, you can actually, in their ecosystem, you can generate a wallet transaction natively with a P256 signature. P256. Jesus, I know, I know. We love to poke at other blockchains, but they actually natively support P256, right? So, you can actually, yeah, you can actually generate a Tezos wallet with a passkey signature. I mean, I don't think anyone's building that.

Nicholas: When you say P256, that means R1 in cryptographer circles?

Jose Aguinaga: Yes, it's the same thing.

Nicholas: Yeah.

Jose Aguinaga: Cryptographic computing just likes to pick names just because, you know, why don't make things more confusing. But yes, it's the same.

Nicholas: So P256 refers to the R1 passkey variant. And if you want to talk about the Bitcoin and Ethereum K1 variant, that's when you specify. But if you say P256, you're referring to the R1, typically.

Jose Aguinaga: Correct. Exactly. Yeah. It's a one-to-one name convention just because that's the standard name.

Nicholas: Before we move on, I just want to catch one thing. With passkeys, we don't even use it really to that great of an extent in all the UI versions of ECDSA and Ethereum and EVM. But hierarchical deterministic wallets allow you to generate tons of public keys. And you can actually even have very cool, like, hierarchical structures where you could reveal some information that could reveal your ownership of a bunch of wallets or a bunch of, I mean, I guess, wallets in the EVM context, but a bunch of public addresses. We barely scratch the surface of that with the UI, like, you know, a typical metamask or rainbows just deriving more and more public addresses from the same private key, but not any kind of sophisticated hierarchy to them. However, with passkeys, do you always just have like a one-to-one private-public relationship, or is it possible to derive more from a passkey?

Jose Aguinaga: No, I think, sadly, I do think you always will have a one-to-one because it's a XY pointing to a card. So this is a little bit of a limitation. There's a couple, I mean, that doesn't necessarily mean that you cannot feed some additional data or additional input and then create like a deterministic signature or something that it's able to then generate something close to hierarchical determination. But yes, I will say that from the passkey perspective, it is meant to be a particular one key pair. And I think that most people are taking that approach for the user wallet. There's some projects that are, of course, using the other web open attribute, which is the display name and kind of like the username. So that's why you see in some demos that they will prompt the user, but that's also why we say like you don't need this. This is not something we'll necessarily use it. It's just that. it's also, it could be a nice way to also tell people, hey, you can generate as many keys as you want because by having a different username, you pretty much have a new wallet. So, I mean, it's nice to have a demonic that derives one billion, a billion wallets. But, you know, it's also nice having a very quick way to generate different wallets that can be processed as their own standalone. And they have this similar security model, I would say.

Nicholas: Do you, where do I want to go from here? The, there's so many directions. I do want to get to MPC. Oh, yes. I remember what I was going to ask. With passkeys, we have this problem. we discussed about either calling the create method on the API or the sign-in method. But there's another issue around passkeys being specific to a certain domain. Like, for example, the domain name of a given web app. Yes. Are you able to use a passkey generated using on let's say passkeys.is on passkeys.xyz? Or will iOS and presumably the other OS's following suit not allow you to connect, you know, to sign data with that passkey on a different domain? What are the rules around that? And do you think they're fixed or will they change over time?

Jose Aguinaga: I've seen some people exploring cross-origin domain requests on passkeys. But my understanding, and this is a good question that I would like to explore later, but my understanding is this only on the subdomains of the root domain that you have created. So I believe if you create, I might be mistaken, but if you create a passkey within a subdomain, I think you can make use of that one from the domain or the other way around. But I don't think it is expected for you to be able to use a passkey from that you have on Google.com and log into Apple.com, right? I do think, and I'm very curious, and I'm a little bit surprised that doesn't exist yet. We will get to see a way where people, because at the end of the day, they don't really, people don't really care about the passkey. And this is just more against a feature, not a bug that the web authentication actually binds you to. I think it's CoreLayer ID, just a fancy way of saying just that the website that you're creating that passkey. But what that means is that nothing really stops someone to creating a project that is just kind of like your OAuth 2 of passkeys, right? That if you want to log in into Apple.com, then you first go to passkeymanager.io, you register, you get some payload that you sign, and then you can just pass that payload to Google.com or Apple.com. Because for the purpose of signing this information or verifying that you own that key, it makes no difference to, or it's invisible to the website. It's just, again, it's just because the workflow is expected you to have a web and server enabled, but nothing stops from verifying against that one single server against any other things and then generate it, I don't know, like a cookie or JSON web token, and then you can do your traditional OAuth 2. And you know, that's what some people were complaining about when in some of these new generation projects that, you know, we see that friend stack or other wallets, right? It's like, "Ah, I have to create yet another wallet, right? It would be really nice that, you know, instead of doing this, I've just fetched my wallet, right?". But yeah, right now, I don't think it's the case.

Nicholas: Yeah. So is that a correct summary of it? That basically you're using the same context for associating the passkey with the same context, and then that context needs to be imported by different web apps or native apps in order for them to get access to the passkeys across different applications.

Jose Aguinaga: Yes. I mean, one question that I didn't, I mean, one thing that doesn't let me, well, not that doesn't let me sleep at night, but that I think it's a true challenge, again, the way of the protocol works is if you have a passkey, let's say, again, you know, cool project, like a friend.tech, right? Yeah. And they change domain. Like if your authentication model will have been different than what they do at Privy, but it's still a passkey-based, we use that same passkey because the protocol doesn't let you use the passkey that you have for a different domain, right? So that could be the case. And then you get, again, this sort of decentralization issue where this says, "Well, I mean, yes, I can use my key. It's mine, but because of the way the protocol is designed, I could not use it if you, as a provider of GitHub, do something.".

Nicholas: Right. If it goes away. So you could imagine even a different version, like let's say Tornado Cache was hosted on IPFS, but using a domain like they were using, a .cache domain, and decided to do a built-in passkey-based self-custodied signer on a custom AA wall that they deploy, if tornado.cache were to be seized by the registrar, government, et cetera, then you would lose access to that site. because even if you still have your iCloud keychain, the passkey and iCloud keychain, the keychain in WebAuthn won't let you sign with it unless you can get to that domain.

Jose Aguinaga: I mean, I don't know what are, and again, this is all this funny edge cases. I don't know if you can trick your computer to sign, like if you change the host file in your computer and just pretend that you're running that particular domain when in reality you're just changing the host file. I don't know whether you can trick your computer to use that passkey. Yeah, someone will have to do that experiment and figure it out. But yeah, that all brings again to all the centralization, right? This is also a different highway, but I think to me it's important, which is that a lot of solutions are there that are trying to look at passkeys and they try to really say, okay, well, you just authenticate against my server because it's the cheapest, it's not the most valid, it's the easiest way to do it. I do struggle a little bit with that, right? Because for me it's like, well, if you're using a security model that actually relies on another central piece of architecture, I don't know how. is that any different, any better than any sort of solution that takes a lot of security into account, right? Like I like Privy. I mean, I did a tweet where I analyzed their security model and that seems pretty legit to me. And sure, you are into this kind of setup where you need a secret share to be able to sign a transaction. And if the company goes down, you're out of luck, or if you're never able to get the backup secret share, then it's tough. But it's not any different if you put a web app and server. But again, that's a whole discussion because again, we go back to the whole, well, if you don't have an account obstruction bundler, if you rely on a paymaster, right? Like I do think we, one of the, I'm really looking forward. And I think Peter from Foreman Dials was early here joining, right? Like that they are actually doing some of the implementation, like some of the optimization to be able to actually just use a passkey with a smart contract. That is definitely the most expensive solution. But I think that is the only true decentralization that I think a lot of people will really follow with the ecosystem rather than, you know, just always go for the centralized global debt server. Nothing against that approach. I just think that there will be people that they will look at this solution will say, well, this is not an improvement. I rather stick to my own security solution because it has the known dangers that I know.

Nicholas: Yeah, absolutely. Well, I want to get into the MPC in detail. But before we do, I guess let's finish out the sort of passkey UX gotchas. We talked about it a little bit, but basically, if I sign in with Gmail, for example, the passkey is not associated with Gmail. So I might sign into two different applications with the same SSO OAuth or SMS or social login and not be, you know, both apps are not going to be aware that I already have an AA wallet that's got a passkey signer. I guess there's no real solution for that. That's just, as you say, due to the design of the protocol not really being being made for crypto and AA wallets.

Jose Aguinaga: Yes, although there could be a solution and I explored that with I was lucky enough to work with a ceramic network team. I did a grant for ETH Denver where we wanted to do kind of like passkey ceramic composite group solution using the ceramic network. And what I realized when I was building that is that if you have a registry of all the, let's say, you as a user, same way you have like a ENS, you're able to say, well, these are all my passkeys, then you can effectively pretty much have an ID that you can people look at this registry and say, well, this is, you know, this is Nick. He has said to the registry that he has three public addresses. I'm just going to prompt you for all these three. And if you have any of these three, then, you know, you're Nick. And if you don't, then you're not. Right. And again, that could be done by all the dApps that you want to log in and use in this context switch. But it's all these edge cases that I think people are still struggling to get, you know, passkey validation before they can actually look into the registry of public keys or passkeys and all those things.

Nicholas: Got it. We talked about how if you don't grab the public address at the time that the passkey is created, you'll never have access to it again. Dan Romero of Farcaster mentioned on Twitter a couple of weeks ago that Safari 17, which is the current version, introduced this large blob feature. And I think he even implied it in the tweet that you could basically let you store additional data in addition to the passkey. that could be retrieved in the future by an app that gets access biometrically to the passkey, if I understood correctly. So I guess the implication was you could create a new passkey and then store maybe its raw ID and also especially its public address or public key, I should say, right in the large blob space alongside the passkey so that in future cases where you get access to the passkey, you could find out what the public address is without having to necessarily store it off-device. Is that a correct understanding of what large blob enables?

Jose Aguinaga: Yes. I have seen that post from them, and I haven't been able to really explore that. I only recently updated my computer to Safari 17, so I will be able to give it a try. There's two extensions of the traditional passkey that are out there and people are looking into for multiple use cases, one of them being exactly the large blob and the public key storage. And the other one is the pseudo random generator function that you can also request. I don't know if you have seen that one, but that one is being pushed heavy by the 1Password team because that allows you to generate cryptographic material that you can then use for encryption and decryption. So the passkey, as we agreed on very early at today's session, is mostly used for signing and being able to have access to generate ECDSA signatures. You cannot encrypt with that. However, if you're able to access the extension with a pseudo random generation function, then you're effectively giving your passkey the ability to do encryption and decryption. And for instance, that's how teams like 1Password are trying to approach this as a way to say, "Hey, you can use this as your master password.".

Nicholas: Very cool. That's very cool. You also mentioned in the passkeys.is site, the difference between DER and CBOR formats. What's that about? I don't understand that.

Jose Aguinaga: Yes. So that's actually, I mean, if someone wants to really get into the whole passkey dynamic and wants to make a major improvement on how they are implementing their own passkey interaction, I think that one of the best or one of the biggest advancements that I did in the passkey.is library is being able to verify a signature from the raw contract based on calculating divides of the ASN.1 sequence. So in other words, the DER format, it's just a format that is being used traditionally for packaging data. So you will see in a lot of applications, then these different formats are able to encode some content and they're able to have a binary representation, but they come from the way PKI infrastructure has been used, particularly DER, and the way that data is being sent. Now, CBOR is usually smaller. You have a binary representation, and as a result, you need to have some parsers that are able to get some of the data.

Nicholas: When we're talking about data, you're talking about signed data?

Jose Aguinaga: The signature. Just the signed data. Exactly. So this DER and CBOR discussion, it's about the signature. Now, what most people, when you get to see this sort of ASN1 data representation, there is a fair amount of libraries that know how to process the data, say, "Okay, I know this parse this, obtain the...". You have this information and it gives you the chunks that you need.

Nicholas: Basically, you don't know in the CBOR style where the end of one piece of information is and where the start of the next is. The padding is not as obvious as DER.

Jose Aguinaga: Exactly. That's pretty much it, right? It's a binary format data. Now, the good thing, though, is you can actually, if you understand how the ASN format works and the sequence, you can, if you're a masochist, let's put it that way, you can actually calculate the bytes and do what is called a view of the specific R and S variables of the signature, which is, at the end of the day, the only thing you care for from a signature, and actually parse it in a format that is understood by a web cryptographic API. So, what I'm trying to make a point on that section of the past keys is, yes, you can use your CBOR library to be able to parse this information very quickly and get your signature and other relevant information if you might need, or you could use this snippet that I put together that already knows where the data is going to look like and get your signature and then use the web cryptographic API to verify the signature. So, right now, because that data, you cannot verify the signature as it is, you cannot do the traditional verification. Most people are having to rely on CBOR encoding decoding library to be able to fetch the data and then to verify that data. On the small snippet that I have on the past keys, I'm actually untangling the data, I'm feeding it to the web cryptographic API that it's able to understand it, and then you can verify without no external dependencies. The main takeaway is you can skip a dependency, which is, I don't think it's the worst thing to do in the world.

Nicholas: No, it's the best thing to do in the world. So, if you want to dive in deeper, there's the caveat section of past key studies under the DER format. You can see more about that. You also mentioned this. P384 keys are not supported. Why is that a problem?

Jose Aguinaga: It's mostly because, to be really honest, for their context, as I mentioned, a lot of my background comes from the enterprise sector and their enterprise solutions where they usually. P256 is or has not been enough. You will see that on home security modules, PCI cards, and other sections. So, the ability to natively send a past key, like a signature that is able to fit into the systems is huge. For instance, as I mentioned before, the Estonian government uses this elliptic curve for their own digital ID certificates. I was very excited to be able to use that because in the documentation, actually, it says that they support it. However, nobody has actually done it. So, I tested all the paraded systems. Nobody really has supported P384. It's a pity, but yeah, I don't think you can actually do anything there. And yeah, it's just dead end for the time being.

Nicholas: So, you've got this new site, npc.is, which is kind of a partner, a sister site to pastkeys.is. And I guess where I want to start with npc multiparty computation. Well, maybe first off, can you explain what multiparty computation is?

Jose Aguinaga: Yes. I think multiparty computation, again, has been around for years, over 40 years, is pretty much the ability to generate a defined output with not having all the required inputs given. And I maybe give it a similar description, but it's the ability to be able to compute data in different devices, isolated from each other, and that data makes sense of all the inputs without having access to all the inputs. So, that is in very, very, very rough terms.

Nicholas: No, that's great. I like the example I've seen in some videos explaining npc. They talk about trying to figure out what the average salary is between a bunch of people.

Jose Aguinaga: Millionaire's problem.

Nicholas: Yeah. Oh, millionaire's problem. So, it's very interesting. So, you can imagine like, let's say your salary is five and my salary is three. Let's say my salary is, which is obviously four. Each of us can generate three numbers that when summed give our actual salary. So, I'll come up with three numbers that will sum to three. So, these can be positive and negative numbers. So, if I could pick like five and two and minus four, and that sums to three. And you could pick five and four and minus four, which sum to five. But knowing each of those numbers independently doesn't really tell you what the sum is for that person. So, obviously, with only two parties in the npc, it's probably not really secure. But let's just run with the example. So, we each generate three numbers that when summed equal our secret number that we don't want to share directly because we're, I don't know, not comfortable sharing our salaries. And we then share these shares, the three numbers that we've come up with across all the devices incorporated in the npc. And then if you take the sum of all of the numbers, so of the numbers that I just listed, the sum would be eight. Or actually, is it eight? I might have messed up my Excel spreadsheet here. In any case, if the sum of all the numbers, I think I'm going to go with it. I think it is eight. If you divide it by two, which is the number of parties involved in the computation, then you get four, which is the average between three and five, the two secret pieces of information that we didn't want to share. So, you can come up with a computation where although you're sharing some information derived from the secret information that you want, you don't actually reveal that secret information in the first place. This is useful for things like if you want to collaborate across industry or something and you don't want to reveal your private intellectual property, but you do want to come up with some kind of computation on the private intellectual property held by different corporations, or potentially for a cryptographic and especially blockchain application. There's other reasons you might want to use MPC. Is that a fair summary of how MPC works and what it's good for?

Jose Aguinaga: Yes, that is a beautiful explanation. I will only add for the nerds in the chat. But for people looking out, that is usually called a Pilear cryptosystem. And it's a property of additive homomorphism. So, that is just if people want to get fancy on that. That is also a little bit of the area that people can explore. And in general, homomorphism is a fascinating field in cryptography. Please don't ask me follow-up questions.

Nicholas: Don't worry. I was going to ask you about Pilear. I was going to ask you about Pilear because you mentioned it on the MPC.is site. If people want to check that out, you do a demo, actually, where you can spin up to this website in two different tabs or two different devices, and they can interact to do distributed key generation. So, maybe you could explain, what is DKG? Yes.

Jose Aguinaga: So, DKG, the name stands for distributed key generation. Pretty much is what you already described, that it's the ability to compute over public information that you share between two or more parties in a way that you can agree on a common secret that can be derived based on the distributed parts of it. So, the part that I think made it very clear for me when I was understanding from an inflation point of view is that with distributed key generation, you get two very important pieces of a whole system where looking at them individually means nothing. So, that's a little bit what we're already saying about your example of being able to have these public keys and this information that is related to your original input, but on their own, they are useless. They just happen to have a more meaningful value when put together. And in the context of digital assets, it's generating a private key or the equivalent of joint private key, which is not really a private key. It's more like the ability to generate a single curve point. But again...

Nicholas: That's an interesting specification about what it actually is doing because distributed key generation, you're effectively getting an EOA, but there's no place in the world or on any computer where the private key exists. Instead, by doing a multi-party computation, you're able to sign data. Can you explain a little bit more about what you said about a point on the curve? Is it really what you're getting?

Jose Aguinaga: Yes. So, this is just more from the concept that a public key is just to point to XY points in your curve. And that's where these two points, X and Y, those are the ones that you use for deriving an account address. in any blockchain system, right? Like in Ethereum, it's, I believe, like a KKAC hash of these two points. And then you just take the first 40 characters. that is your Ethereum address. So, you always need a public key to do that. When you successfully complete a DKG, and I will not go again into like there is multiple algorithms, there is GG18, GG20, Lindel 17. But in general, when you complete the traditional, what we understand, state of the art DKG, you get key shares where you can compute or you have already agreed on these points into the curve. So, both key shares, they know, "Hey, we both have agreed on these X and Y points.". And what that effectively translates is that one, each key share knows, sorry, within the context of Ethereum, and that's another point that I will make later. Within the context of Ethereum, these two key shares know what Ethereum address they control. And the beauty part of them being an X, Y endpoint is that that can be applied for any blockchain. That doesn't have to be an Ethereum blockchain. That's one of the beauty of MPCs, being able to have an even lower, so to speak.

Nicholas: So, if we were going to sign an intent with a DKG solution, I guess the intent would have to be communicated to all of the parties in the MPC

Jose Aguinaga: DKG

Nicholas: computation, and then they would do some operation, like in your MPC.IS example, like back and forth to generate the signed data that would be communicated to an Ethereum RPC?

Jose Aguinaga: Yes. I'm using GG18, but the way it works, and I'm trying to make it as obvious as possible on the website, I hopefully can finish pretty soon, but you already can generate a website, a key on the website, but you cannot sign it on the website. But the signature part is you have a payload that is very clear that it's just, let's say, an Ethereum transaction. And what you're passing that to one device, we again generate the Polyera cryptographic keys, and we do back and forward with the device. We are signing and co-signing with our own key shares, and then eventually we agreed on, we are able to generate a full ECDSA that then we can transmit. But that process of back and forward, those rounds, which is a more technical term, are transmitting part of the payload. And that's why usually you have encryption mechanisms around these rounds, such as zero knowledge proofs and other sort of utilities to be able to transfer that information. That's how, at the end of the day, the core concept, you cannot just be having the keys and not exchange information with other keys, because then you cannot sign anything. Both those keys, they need to talk to each other and they need to do a couple of rounds before they're able to compute this value that is valid.

Nicholas: And that's not just for creating DKG in the first place, getting a public address in the first place. But every time you want to, for example, sign a transaction with a DKG MPC wallet, you would have to do multiple rounds.

Jose Aguinaga: Yes. And you know, most white papers out there on the MPC and on the topic are how to make these rounds more effective, like reducing the amount of computation, reducing the amount of rounds, reducing the size of the keys needed. Some major companies, probably the one in front of my head is Fireblocks. They recently, as early as last year or two years ago, maybe, they launched an algorithm that is called MPC-CMP, which is probably, as of today, the fastest one to be able to execute both DKG and TSS in record time for a generic amount of data.

Nicholas: Fascinating. You mentioned TSS. Can you just define threshold signature scheme while we're here?

Jose Aguinaga: Sure. As I mentioned before, once you have a distributed key generation system, you then have to set up... The distributed key generation system is created in a way to have a threshold signature scheme in mind. What that means is that usually you cannot think one without the other. And that's where the concept of M out of N or T out of N exists. So pretty much very similar, like multi-sig signatures that you need two out of three to generate a signature on a threshold signature schema. The only difference is that to be able to generate a valid signature, you need a minimum amount of key shares for generating a valid signature. So in the example that I put on the website, I just do a two out of two. So you need both key shares to be able to generate one signature. But in reality, you can have as many as you want based on the configuration as you want. And then, of course, you can refresh the key shares. Again, that's a different topic. But the goal or the purpose is that you can... In the same way that in a multi-sig system, you don't want to get isolated or one single point of failure. You can actually here have a set of keys that are good enough to generate a signature. One very key difference, and no pun intended, on the multi-sig is that, again, you don't have any meaningful data on the key shares during this process. That can be argued. There are some attacks that have been shown that there might be some ability to actually extract some valuable data. But in reality, the concept is that on their own, these pieces of information mean close to nothing. And whereas in a multi-sig, they are part of a whole system. You have a whole private key that is able to actually execute an on-chain transaction and do a governance ascent. And this translates to MPC wallets being transparent on-chain. So when you have a multi-sig wallet and they are doing transactions with all the members of the multi-sig, you always will see these on-chain transactions. Whereas an MPC wallet, all these governance is done off-chain, which is great for privacy. But of course, that also has a drawback that for an external, it's not always very clear what sort of tool, model, algorithm is there. You might not know who was involved.

Nicholas: Could be a problem. Exactly.

Jose Aguinaga: Or how many, or what is the operational control, which is, again, depending on your target user, this can be a benefit. And I guess just as a side comment there, I will say that the benefit in terms of, well, there's two comments. So the first one is one of the unfortunate parts is that the field is so new, like literally. so new, like the first major MPC conference happened this week in Singapore.

Nicholas: Really?

Jose Aguinaga: Like literally this week. Yeah. The Compute MPC, which is just had like the major players over there, cryptographers from all over the world, very interesting. I promote really hard by missing it, but yeah.

Nicholas: First MPC ever? But I thought MPC was old.

Jose Aguinaga: Yeah, but for the context of digital assets, it's...

Nicholas: Okay, for blockchain.

Jose Aguinaga: Right? Yeah, exactly. So for instance, Fireblock, which is one of the major MPC custodian providers in the enterprise sector, was founded in 2018, right? That's nothing, right? So if you think about it, like now they're worth like, they're way over the unicorn status and they have been around for less than five years, right?

Nicholas: What was the name of the conference you mentioned?

Jose Aguinaga: Decompute.

Nicholas: Very cool.

Jose Aguinaga: Decompute. Yeah, Decompute.org. They probably already, yeah, Silence Labs, based in Singapore. They have people from DFS, Aptos, Sengo, Certiq, Fireblocks, Microsoft, yeah, just Haskellog also.

Nicholas: The obvious technology team mentioned Silence Labs earlier today. So yeah, apparently they're very, very much leading kind of the solution to... Actually, the problem I want to talk to you about next, which is... MPC, DKG, it's very cool that you can do this kind of multi-party signing in a blockchain context. But what it really seems to be most useful for in the context of PaaS keys and AA smart wallets is we talked about this problem where the R1 curve that's used for PaaS keys is not compatible with the EVM natively, at least currently, unless this EIP-7212 is to pass, which seems maybe won't happen. It's not a surefire thing. And so in the interim, one solution is to use a smart contract that will verify R1 signatures. And so far the best, sort of the state of the art is Ledger has got that down to 70,000 gas to do such a verification, which is acceptable, but really not something you want to force on all of your users, even on an L2, that every single time they do a transaction, they're essentially wasting 70,000 gas or close to it every single time. And so there's a couple other solutions, but it seems to me from surveying all the options out there that pretty much everybody is putting something in between the PaaS key and the smart contract wallet such that it can just be a K1 signer, a traditional EOA, at least from the perspective of the AA wallet that is the signer. And yet the PaaS key is kind of what will allow you to initiate that signature through something in the middle, something like MPC, DKG. One example that I've seen come up several times is LitProtocol. Is that more or less a summary of where MPC fits in in this stack?

Jose Aguinaga: Yes. I mean, the LitProtocol team have been lucky enough to talk with them in multiple contexts, and I believe they're probably also among the most interesting ones to piece together the whole wallet, MPC, PaaS key equation. They also have a very good demo. I mean, I think it's based also on LitProtocol. And early before they were doing these threshold nodes where exactly you have that, right? Once you have a ECDSA signature, even if it comes from a couplet curve or a random one, like a PaaS key one, you can then create some sort of governments and then you can translate that government into a valid signature that works for whatever system you have. That's what LitProtocol is currently doing on their PaaS key implementation. I checked their smart contracts and they have kind of like a relay. Again, it raised eyebrows in the concept for the sake of decentralization and what we're all trying to do. But it is a very valid, very practical solution, very pragmatic solution in terms of key management.

Nicholas: Basically, for people who aren't familiar with it, they have a separate network of nodes that conforms to this LitProtocol, which are doing this MPC DKG computation.

Jose Aguinaga: Yes, exactly.

Nicholas: So it's great because you get some of the advantages we just talked about and more still. For example, you can add permissions or multi-sig kind of behavior at the MPC step in the process and not have to do all that work on-chain, which saves you gas, lets you do it more privately. As you mentioned, so you can have multi-sigs or you could have restrictions on what kinds of things the MPC DKG will allow you to sign from a PaaS key or whatever kind of authentication you're using to initiate that signature process computation. But it also introduces a dependency on a whole new network that is distributed, but of questionable decentralization, of course. And even if it is decentralized, you know, you're sort of introducing another dependency on a whole other decentralized network. So it's not just pure EDM or L2 or L1, but now you have a whole new dependency, which is maybe something you don't want to introduce, especially when it's as significant as being decisive in whether or not you have access to your wallet.

Jose Aguinaga: Exactly. I mean, this is the challenge with MPC. And this is an idea that I wanted to voice earlier, right? I mean, the challenge goes very simple, that there's no current standard on how like MPC is this huge chainsaw that you can use to demolish anything. And you can use it as the whole DKG, glue together wallets, create governance protocols. It's a very versatile tool that allows anybody to provide governance, transactional layers and all sorts of things on top of your wallet management solution. But the problem is that there is no standard. I work, and I mentioned before that my previous job was at CryptoBank, and I've been lucky to talk with like over 10, 15, 20 custodian provider solutions that are popping everywhere from steady players to non-incumbent players that are just building. And everybody's building their own thing, right? So the same way, and maybe I need to talk with the Privy team, but in the same way that when you're doing Shamir secret sharing schema, and then you're splitting these bytes of data for a key that you want to later use, there's no standard on how to do that. How do you store that? Like, what does that mean? There's no metadata. There are not any different than 30 to 64 bytes of data, right? And that's the problem a little bit with MPC. Right now, there's an algorithm that gives you a little bit of information. But if you were to look at an NFT token, and you will see at the metadata that it has, then you will know that it's an NFT token. Right now, the MPC ecosystem is very fragmented on the protocols. First of all, on the algorithms that it uses, on the protocols that it supports, and last but not least, on the implementation that it has, right? So there are not that many implementations that are open source. It was actually a little bit of a challenge for me to put together the website, just because I had to use a bunch of libraries that were a little bit obscure. And it's just not so easy as creating a random 32 bytes and calling it a private key. That is the major challenge that MPC has. It has very good benefits and has a lot of room to grow. But it will never be as easy as just generating, you know, running, generating, giving 32 bytes. All right, that's my private key. Call it a day.

Nicholas: Right, of course, of course. But what you're saying to me seems to indicate that there's room left for standardization across this MPC space. So it's exciting to hear that there's this conference and people are getting together. It sounds like there may still be progress to be made in the next couple of years on this.

Jose Aguinaga: For sure.

Nicholas: So one question I had about this is, do you have any insight into how people are able to, I think you even talked about it as governance, you referred to it, but I spoke of multi-sig kind of functionality or permissions. Do you know how someone would add permissions at this MPC layer? When I ask you this question, I'm thinking of, I spoke with the people from Use Capsule, or I guess it's just called Capsule, but their website is Use Capsule, who are building another smart wallet protocol or platform. I'm not sure which they would self-describe as, but they are using MPC for the majority of the permissioning. So that instead of having, you could still have some permissions on the AA wallet. For example, if you imagine like Frentech, you know, you could say, I want this or maybe Frentech is not a great example, but I want this passkey to only be able to move this much ETH and only interact with this and this contract. That kind of permission could be in the AA wallet as a part of the authentication limitations on a certain signer for that wallet, or it could be imposed at the MPC layer. Do you have any kind of sense of how one would do that at the MPC layer? It's something you, I guess, configure when you set up a lit protocol?

Jose Aguinaga: Yes. So I have an idea. And this, I think the only part, or like the answer might not be very satisfying because it goes against the same concept that I say before that everybody's implementing their own. So I'm a little bit from that about a capsule team. And this is some of the solutions that I, that it's not that I struggle to see the major benefit, but that I think their approach to non-custody and self-custody can be very challenging for someone coming from the enterprise world. And what I mean by that is, and answering your question, technically all these governance protocols and layers are implemented in a server somewhere, right? So they are hard-coded into a centralized solution in the same way that, you know, if you go to your traditional web2 application that has an RBAC model, when you have say, well, user A has able, they can only access files from, created by user A and user B can only access files from user B. You have similar rules on a centralized infrastructure that allows us to say, well, if this is a valid ECDSA signature, that means this signature came from user A, what resources can user A have? What policies can user A have? And these are very good use on the enterprise level. Like this, you will see it is like, okay, if this is a transaction that was signed after 6pm, then my governance layer, my AWS key management system will block the transaction, will not co-sign, right? And that's how these governance layers are enforced. The protocol is the outlier here because they are pushing on the centralized solution, but a lot of these key wallets are like, I need to look at the current key and all these other solutions that are popping everywhere. But it's effectively what they do. is they have a web2 infrastructure, like HSM or whatever, IntelliJ X, or whatever it's available on the web2 ecosystem. They do exactly what you mentioned, like you use some ECDSA signature. It could be passkey or it could be your Google loading or whatever that identifies you as you. And this is authorization. And then they get into their systems and in that systems, they tweak the policies and the control that is needed and they give you the resources based on those policies.

Nicholas: So it's not something that could be, it's not just the opaqueness of it not being represented on a public blockchain, but it's that they could potentially even manipulate the permissions despite it being MPC, DKG based?

Jose Aguinaga: For sure, I mean, why it became, yes, so this is a serious concern. And this is, I like what you said about, okay, you can guarantee or you're guaranteed that they won't be able to do a transaction without you. But the problem is twofold. That also means that you are not able to do a transaction without them.

Nicholas: Right, exactly.

Jose Aguinaga: And that is a tricky part. It doesn't give you that much flexibility if even, let's say we have the cryptographic primitives pleaded and we have to put in together, you know, all that Dragon Ball Z push and style. If you get to pick the rules, where do we meet and how do you take my key or when do you take my key or how do you take, well, not my key, you will never take my key, but how do you take my signature or my code signature and

Nicholas: how

Jose Aguinaga: do you open or close the gates? And the problem in the enterprise sector is, and I'm only speaking about enterprise sector because I think it's interesting and it gives a glimpse of how the retail sector will mature, which is like, is this really non-custodial? if you get to define your rules of engagement, even if you can never generate a signature without me, if I can still not generate a signature without you and you are the one that defines the rules on when and how do we meet, is that really self-custody?

Nicholas: You can be censored, essentially. I spoke with the people from Capsule and I'm going to have them on the show, so we'll dive into this more in a slightly less speculative way, but I think they have some solutions around making sure that you can always exit, so they provide you with enough of the keys, enough of the shards that you can always exit the key, from what I understand, but we'll talk to them directly to get to the bottom of it.

Jose Aguinaga: But that's also the same with the premium, right? And a lot of solutions like, well, we'll export your full key and I think that's how they will say they're non-custodial. But yeah, when you have them, just ask them tough questions.

Nicholas: Of course, you're not the only one, don't worry.

Jose Aguinaga: I'll be listening.

Nicholas: The Dragon Ball reference you make is maybe appropriate. I bet you could do a whole kind of site themed around...

Jose Aguinaga: Well, that would show my age, Nate.

Nicholas: Everybody loves Dragon Ball, but there's a fusion, but there's also collecting all of the Dragon Balls to get a wish. There's a few different metaphors. There's the earring way of fusing. There's all these different ways. So, okay, let's round this out. We've had a wonderful conversation. A couple last things. Do you have a sense of what the permissions architecture is going to look like for limiting access to certain types of transactions, either at the AA piece of the stack or in the MPC? Do you have a sense of how we can even do that? It just doesn't seem obvious to me. For example, let's say Frentech was not on Privy's Shamir solution, but instead built with passkeys and MPC DKG and an AA wallet, whatever. Let's say it's state-of-the-art and we ignore all the problems that we mentioned. It does still seem like if I were to log into Frentech with an existing passkey-based AA wallet and only grant certain permissions to Frentech, if I were to limit how much, for example, ETH I could spend when interacting with the Frentech contracts or limit that the passkey signer associated with Frentech only be able to interact with certain contracts and not others, it does seem like almost immediately the composability elements of, I don't know, let's say I want to buy something that's worth more than my limit, or if I want to move an NFT and the NFT is in one contract, but I don't have permission with that passkey to interact with OpenSea, for example, or the Seaport protocol. It seems really complicated to me to present this. I mean, even to work through it at all, but to present it in a way that's reasonable for users who are, let's say, less technical or less crypto-native, it seems like it's going to be very, very challenging to create some kind of nutritional facts or App Store-style permissions or iOS-style permissions around these really nuanced and potentially permissions that you want to change actually quite frequently if you decide that you want to do some behavior that's not permitted by the prior permissions you set. Is there any real serious work on this or is everyone still just trying to figure it out?

Jose Aguinaga: Yes. No, I can actually answer that question because I mean, it's going to have a gamut. They're sponsoring me, but they are not. I just really like their team. Lucas Schroeder and the Safe team is one of those ecosystems that are exactly handling that, right? So Safe, I mean, they're also pioneering the concept of the smart wallet. They make a very good metaphor between an EOA wallet being kind of like a feature phone and the smart wallet being like the iPhone. And they're really building, they're like modularizing their entire multisig ecosystem because I think people still think that it's just a multisig, right? Like that's what Safe is like. The Gnosis Safe is the one that you use in 2018 to handle your treasury of your ICO. But nowadays, it's an entire App Store. It's a modular ecosystem for intents, for pie masters, for all these things. And what I like about this, and answering your question, not as much on their protocol, but the way I see it is, I do think the future will really take advantage of the on-chain nature of the blockchain. And what I mean by that is, I do think in the future, you're going to go to Etherscan, you're going to see a wallet, and it's going to be a smart wallet, right? I think we're going to be moving away from all this EOA. We're going to have all smart wallets. And then in that wallet, on-chain, you'll be able to say, "Hey, this is a wallet that can only spend up to this amount of money.". You'd usually get, it can only be used between 3 and 5 p.m It has four signers, and you will be able to see all that information in the same way, like in a very granular way, such as that gives you the visibility of your ability to engage. And we're talking very clearly about intents, your ability to actually use these tools. Because right now, what is happening, and you see on this old phishing attacks and hacks that you might have 1,000 approvals, you will not know about it. Maybe you approved some random core pool in 2020, and now that got drained or on the fork, they send a message. Like, it's really hard to, on a traditional wallet, understanding how the system works to do that on a purely EOA base. And the problem, again, with MPCs, is that this might not be very transparent. So even though if your wallet is fully managed, and you have this kind of address that will never have this private key, will never generate a bad signal transaction, the problem is that you will still have an operational mistake or something going wrong on that side of things. that will not be ideal. If you were to put, really identify where I think we're going to move to a lot of on-chain primitives where there will be a modular system that I should put in there, I will take a look very close to the safe ecosystem, what they're doing there. And yeah, I do think that's where we're going to go. That's just my take.

Nicholas: Because really, we need to, so I guess one research topic for the future is this, is it possible to have MPC or some equivalent solutions? Are they naturally going to move to cheaper blockchain contexts in order to be more easily verified? Or is there some way to fix in the MPC DKG setup that the rules can not be changed by the operator of whatever the DKG network is? And obviously, blockchain and AA wallets are kind of a solution to that already. So maybe that is just the solution.

Jose Aguinaga: I mean, you will probably see both. And that's a little bit on the standard question, right? So you will see an improvement and a standardization of all the MPC solutions and tools out there. You will eventually see more open source implementation. You will see the standards. I will say that, you know, we're an MPC where we're very close to early ages of WordPress, right? Like everybody was installing WordPress and, you know, it was just like a mismatch of. you could do monstrous things in a WordPress installation back in 2000, right? And even earlier. But the point is, eventually people understood was the best way to use WordPress. How do you install it? You had a common partner, like all these things, but it could only be there because it was open source, right? And now the open source community, like the MPC community around digital assets has some things open source, but they're not quite there yet. We are a little bit already on this WordPress chaos mode with a lot of MPC solutions, but we're going to standardize the way you create plugins. You're going to standardize, I mean, how these key shares are parsed, right? I mean, today it's crazy, but the marshalling and marshalling, like the encoding and decoding of some of these key shares, that's one of the most annoying problems that I had. Like it's just filling this demo page for me was a nightmare because a lot of these MPC solutions, they expect some sort of like by manipulation that is usually mostly done on the backend, and they don't account for the ability of a DOM browser being able to just parse a leaked core point that they cannot be strongly fired. But anyway, that is just me complaining.

Nicholas: - No, no, no, it's real because making everything client capable is sort of the logic of the thrust of serverless, you know, design. for the past few years, doing things like a Cloudflare worker or any kind of worker that's essentially just a client, but in the cloud to not have those abilities seems to kind of ignore the thrust of where a lot of the development energy has been going. So it is interesting.

Jose Aguinaga: - And also I think, and one last comment there, I think that's where we're going to go, right? Like you see the, I mean, also Vivi was very vocal about the future being about native apps and app stores being open about all these things. I'm a fool on the web. Like I know it's going to be, it's super hard to get, you know, this non-janky feeling of on most mobile applications. But really, if I really go to my roots, if I remove my fancy banker suit and I go to my cyberpunk root, it's like, no, like you really want something that has full client validation. I can host it on an IPFS node. I can deploy it on my own node, put my own RPC endpoint, and, you know, literally configure everything so I control the full stack. I think there's still a lot of people in the crypto ecosystem that want that. And until you can get that done on account abstraction without having, I mean, until you don't have to, well, you can still run your own bundlers and paymasters when you can still run your own web apps and servers to engage whatever decentralized, as long as there's an option for a full decentralized stack that you can use, I think that's going to be the best way to go.

Nicholas: Have you seen KnowNothing Labs and their noseedphrases.xyz demo of Halo 2-based signing rather than R1 signing?

Jose Aguinaga: I think you mentioned, but I honestly, yeah. So, I mean, I saw in some capacity, but to me it was hard to tell or how different it was from just yet another passkey.

Nicholas: Yes, agreed, agreed. But they're using like a ZK technology under the hood instead. Unfortunately, I talked to them and they said that currently it's, I think, 400,000 gas to verify on-chain, but it does seem like maybe an alternative to MPC solutions and DKG solutions where instead you use a ZK prover instead of an MPC DKG in the middle between the passkey and the AA wallet. It doesn't seem like it's very applicable, at least for a multi-chain EVM context, but perhaps on a chain where the curve is built into the chain as a precompile on a specific L2, then it might make a lot of sense. If it was as cheap as EC recover to verify, then maybe, what interested me about this example, and I asked them, it's on the authority of the team, I really don't understand how it works beyond what they've told me, but they tell me that the prover doesn't require any secret information and doesn't require any ASICs or advanced hardware. So if their service were to go down, aside from the domain passkey problems we talked about earlier, presuming that that's not a problem, you could spin up your own ZK prover, maybe even locally or in the cloud or someone else could do it for us. And that would mean that even if their service went down, we could still have the ability to sign and control smart wallets with a ZK solution in between the passkey and the AA wallet, as opposed to the MPC DKG solutions which required this whole network, which could go down or censor you.

Jose Aguinaga: I mean, yes. So I see that's a little bit of how they hollow, hollow, I don't know if I'm pronouncing it, halo ZK prover fire. That's a little bit on, I mean, I'm familiar with some of the serial knowledge solutions out there, and I do think we'll see more and more implementations, particularly on ECDSA verification. So one of the, I think there's some people that are working on implementing circuits that are able to validate an ECDSA signature, like on serial knowledge, although I don't think we are getting there quite yet. I mean, Sysmo is one of those projects, but that you need to do to generate it, join a group for prover verification. The problem with serial knowledge is that usually you need to enroll yourself in some capacity, but there's right now not an easy way to know whether you can prove you are the owner of an address without showcasing you are the owner of an address of an NFT or whatever. But I can see how, because of the way that some of the cryptographic primitives work, how that can be used as a way to proof of change. At the end of the day, the prover might be able, I mean, that's the whole sequencer dilemma and blah, blah, blah. But this is the way that you can actually approve transactions with primitive data that is not accepted on a traditional network. But I totally agree with you, the added benefit will be when it is possible, because then your speed goes incredibly fast, your gas goes incredibly low. And that becomes actionable on a day-to-day basis.

Nicholas: Yeah, without a new dependency, or at least a dependency that can be replicated without a problem. It doesn't require a whole network of active nodes or any secrets that they have. At least that's what they tell me. But it seems very cool, promising, but probably more long-term solution. And maybe not a multi-chain EVM solution or multi-chain outside of EVM, but maybe specific to a particular chain that would have this built in.

Jose Aguinaga: Yeah. I mean, there's already non-AVM, well, I mean, a little like CK Sync already has natively has implemented, I mean, Relive Finance was one of the first, first, first projects that I saw that was using path keys. And they have that natively implemented on CK Sync. So that works there.

Nicholas: R1 is built in to CK Sync.

Jose Aguinaga: I don't think it's built in. I need to remember how do they, either it's super cheap, you actually know, maybe, they have a really good repository, current abstraction. They have a really good repository where they are actually showing how this was mostly updated. And I don't think they support naturally path keys, but they, I do think, I think the difference is that they support 4237 naked.

Nicholas: Ah, yeah, yeah.

Jose Aguinaga: This is, that's the difference. So probably the signature and might not be as expensive as it is in, you know, your layer one, but because they support natively, the ER27 said, yeah, okay, they have a template. I need to find that out and I'll share later.

Nicholas: All right, yeah, let me know. I'll add it to the show notes. Jose, this was an amazing episode, a true marathon about path keys. Thank you for your energy and insights. This was really wonderful.

Jose Aguinaga: Hey, no, I had a blast. Things are too unique. And yeah, sorry for the disconnection times, but I really enjoyed it. I hope that, yeah, people find it interesting and I'll still be available online. So if anyone wants to keep poking, I'll keep trying to expand resources in the network. And yeah, we're all, we're all in this together, I guess. Yeah, definitely.

Nicholas: We appreciate you. So passkeys.is, npc.is, where can they find you on Twitter? and Farcaster?

Jose Aguinaga: Yes, so 0xjjpa. I know that's not a valid X code, but yeah.

Nicholas: Cryptographers are going to be angry.

Jose Aguinaga: Yeah, exactly. You have no idea how many times I have heard that. This one is like, all right.

Nicholas: All right. So it was enough to get you to change your name for Farcaster a little bit. Yeah.

Jose Aguinaga: No, I just say I'm thinking what it is for digits. I bought enough domains. I'm not gonna do that again.

Nicholas: But on Farcaster, you're just jjpa, I think. Is that right?

Jose Aguinaga: Could be, yeah.

Nicholas: It'll be in the show notes if anyone has a doubt.

Jose Aguinaga: Yeah, no, I think it is. Yeah, yeah, you're right. You're right. I need to pause more there. More often. I'm trying to get more out on lens. I am like 0xjjpa, so.

Nicholas: Is there anywhere else, a mirror, blog, LinkedIn, something else you like to point people to?

Jose Aguinaga: Most of my networks are on jjpers.winaga, which is my full last name. It's like good Latin origin person. I have like 11 last names. So it took me a little bit of time before I managed to compromise to the four letters. But any tunnels on my network, you will be able to see me there.

Nicholas: Well, thank you so much. And thank you to everyone who came through and listened live and who's listening to the recorded version. If you're listening to this live next week, Friday, September 22nd, I'll be talking to Scott Sonarto, who's building his own L2 from scratch, which should be an interesting conversation. So I hope to see you all there. Jose, thanks again. This was great.

Jose Aguinaga: Thanks, Yannick. Appreciated time and have a great one. All right.

Nicholas: You too. Bye-bye. Bye, everybody.

Jose Aguinaga: Thank you. Goodbye.

Nicholas: Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter @Nicholas with four leading ends. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at web3galaxybrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5 p.m. Eastern Time, 2200 UTC on Twitter Spaces. I look forward to seeing you there.