Web3 Galaxy Brain 🌌🧠

Nicholas: Before we get started, if you love this episode, please write a review for Web3 Galaxy Brain. 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. Today's episode is all about EIP-7212. To understand EIP-7212, first, we need to talk about passkeys. Passkeys are a new authentication standard designed to replace passwords. With passkeys, when you sign into an app or website, a passkey is generated on your device and saved either locally to a passkey manager or to a hardware device like a YubiKey. Apple, Google, Microsoft, and Mozilla are adopting passkeys because they're more secure than the traditional username and password scheme. Passkeys use the SCCP256R1 elliptic curve, or R1 for short. Bitcoin and Ethereum use the incompatible K1 variation. In other words, there's no built-in way to verify an R1 signature inside of a smart contract. EIP-7212 proposes to add support for the R1 curve directly to the EVM as a precompiled contract so that every modern device in the world will be able to sign smart wallet transactions natively, no software wallet required. On today's episode, I'm joined by Oulash Erdogan, Jérôme Dutillet, and Lionel Olunescu. Oulash Erdogan is the co-author of EIP-7212. He's also the co-founder of Clave, an account abstraction smart wallet. Jérôme Dutillet is CEO of software dev firm Kamech, which are building AA smart wallets under their Alembic product line. He's also the president of Ethereum France, which organizes ETHCC. Lionel Olunescu is an electrical engineer and software developer with experience building software and hardware wallets. Lionel was prototyping and writing about using the R1 curve on the EVM in 2016. This episode is all about the pros and cons of adding an R1 precompile to the EVM. This was an exciting conversation about a deep technical topic that could have major implications for mainstream adoption. I'm excited to share this panel, which gives insight into next gen wallet and authentication technology and the Ethereum improvement proposal process itself. My thanks to Oulash, Jérôme, and Lionel. 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. Oulash, Lionel, welcome to the show. Thank you for coming to talk about EIP-7212. I think Jérôme from Clave might be coming a little bit later, or no, sorry, from Alembic might be coming a little later. But for now, let's start with you. Welcome, Oulash, Lionel. Happy to have you here.

Lionello Lunesu: Yeah, thanks for inviting us.

Nicholas: Yeah, absolutely. So, okay, I have a million questions. There's so much to talk about. I'm not sure who's gonna be the best to answer each question. So I think I'll just tend to ask questions openly and then whichever of you maybe unmute first can answer, because I don't know who's gonna have the, who's gonna wanna answer each question. But we just started talking about this blog post from 2016 that you wrote, Lionelo, A Tale of Two Curves, which I'll share in the show notes and I put on Twitter for anyone listening live. And you were thinking about, and actually you even referenced some people who were thinking about it even before you, including Vitalik, about this R1 curve. Maybe, I have some beginning questions to sort of set the stage, but maybe is there anything you wanna say about writing this blog post or what brought you to think about this so early on?

Lionello Lunesu: Yeah, I'll give a bit of context. So 2016, I started a contracting company with an ex-colleague of mine. And I guess it's just that the time and place where we were, we happened to be in Hong Kong. We had a job in Shanghai right before and the two of us moved to Hong Kong. We started a contracting company and time and place, we ended up with blockchain contracts. And some of them were enterprise. And so that's where most of the SecP256 R1 requirements came from. In particular, we wanted hardware signing. So we didn't wanna use software to sign keys because we were afraid of side channel attacks, afraid of the software not being able to protect the key adequately. And both Apple and Android around the same time came out with secure elements. But again, they only supported the R1 curve. And so we started looking for solutions. Like we want to do a blockchain. We had this company that wanted to do a consortium for digital identity. Company was called Trusted Key. And so yeah, how do we do hardware signing for blockchain contracts? And Ethereum was the natural choice because we could actually have a chance in supporting and verifying those signatures on chain, which with Bitcoin and there were a bunch of them like Ripple, Multi-chain. We looked at a bunch of blockchains. Yeah, Ethereum allowed us to implement our own verification.

Nicholas: Okay, so maybe before we dive into the details, let's just set the stage for everyone. So Leonello, you're living in Vancouver now, BC based?

Lionello Lunesu: That is correct, yes.

Nicholas: And maybe you want to give a little intro. So you mentioned you were in China working on stuff, but what's your background in crypto? How did you get involved and what have you been doing over the years?

Lionello Lunesu: Yeah, my background is very varied. Like I studied electric engineering back in the Netherlands. That's where I'm from. I dropped out to start a virtual reality company. that was pretty early, 1997. Me and a schoolmate, we started virtual reality, moderately successful. That company got acquired by a multinational company. We started working for them, ended up in Romania for five years, same company. Ended up in Beijing, same company. Then I guess it was 2010, virtual reality wasn't going anywhere, I quit. And I joined Microsoft in Shanghai. That's where I met my co-founder, did three years for Microsoft, learned a ton because back then, until then, I basically had my own startup. So I didn't really know how to run a company or how to do big projects. And I worked on Windows, which is, I still think it still is the biggest software company, product project in the world. Learned a ton, ended up doing that contracting company in Hong Kong with one of my ex-Microsoft colleagues. And yeah, so I landed in crypto because we were desperately looking for things to work on. And Hong Kong 2016 was just, I don't know if it's good or bad, but all the crypto happened there around that time. So I hadn't, I was not in crypto at all prior to 2016. I mean, people had talked about Bitcoin to me, but they all had a weird look in their faces. So I never took them very serious. I was like, do you want to buy my internet beans kind of thing? So I didn't take it very seriously until, yeah, we got contract. First contract I remember was actually a hardware contract. So the first contract we had January, 2016 was to build a hardware wallet for blockchain. And so I had electrical engineering background, did some hardware. And so we actually built that thing. So we built a credit card sized hardware wallet that had an e-paper screen, had a battery inside and a keypad for unlocking your key. So the key was on the chip. I was using a Nordic chip back then. Yeah, pretty cool project. But again, it was built for a customer. So we couldn't really brag about it. I did tweet about it, I remember. And that was my first entry into hardware signing, right? So we had to build this credit card sized, millimeter thick hardware wallet. And we were using hardware signing for that thing. No, actually we weren't. We were using software signing for that thing because it was using the Nordic Bluetooth chip, NRF57, I don't know the exact number anymore. Yeah, and so that was software signing. And so then we ran into, we blogged about it, I remember. And then the next customer saw that and they wanted to do hardware signing. So that, hey, you guys did hardware, you guys did blockchain. So I want, your expertise is perfect for this project that I have in mind, digital identity, but identities should not be stolen. So how do we protect the identity? Can we use hardware signing? And that's when we started looking into secure enclaves. Do we make our own hardware, but everybody already has a phone? iPhone 5S, Android just came out with secure enclaves. So can we use that instead of making our own hardware? It would lower the threshold. And this is how we got into Ethereum and in particular, writing smart contracts that verify our own signatures.

Nicholas: Amazing, okay, so we'll get back to the specifics of this A Tale of Two Curves story in a minute. And you can check the show notes for a link to that if anybody's interested. Maybe we can go around the table. Ullash, so you're the co-author of EIP-7212, president of ITU Blockchain, which is a Turkish blockchain group, co-founder of Clave. Tell us a little bit about your story. How did you get involved in crypto and what brought you to writing this EIP?

Ulaş Erdoğan: Hello, thanks for inviting us again. And let me start by my story. When I entered to the university, I met ITU Blockchain, the first and biggest university society in Turkey. And I had chance to learn about Ethereum and crypto in general. And I see that there is a value that I want to contribute and change the world with that value. And then I started making research more and then I started to learn blockchain development in general and then found myself in a situation that I'm making educations and events and contributing to the community and creating a community with ITU Blockchain. Then improve myself in developing some blockchain products.

Nicholas: What year was that around?

Jerome de Tychey: Sorry?

Nicholas: Around what time, what year was that?

Ulaş Erdoğan: It's four years ago, 2019. Then I have worked in some DeFi and NFT projects. then started my own startup called ITU LINE Studio that makes third-party developments for other projects. Then we get bored from building other parties' products and we were making research about what should be our product that we should give all of the energy on learning and development and all of our crypto energy. Then one of our friends have been making account abstraction research. They have been doing research about all new concepts. And one day he came with an idea that turning our smartphones to hardware wallets because we see it's a big contribution for the security and also the user experience, it's account abstraction. Then we made the first demo in a hackathon. Then we see it's the project we are finding in general and dropped from all of our projects and gave our focus to build Clay. And the EIP came with business. We have been looking for the best general solutions for making Clay in best position. And we saw this. pre-compiled contracts would be enhancing all of the wallet projects and some other projects' developer experience and user experience. And it's current need of the ecosystem and it will be a bigger need in near future. So we also prepared the EIP.

Nicholas: Awesome. So I'll read the abstract of the EIP in just a second, but first, Jerome, thank you for coming. You're the CEO of Camyth. Maybe correct me if I'm not pronouncing that right. And you're building Alembic, also president of Ethereum France, host of ECC and a professor of economics. Welcome. Would you like to give us a little background on how you got involved in crypto and what your relationship to the EIP is?

Jerome de Tychey: Yeah, I've been doing crypto stuff since, crypto blockchain stuff since about 10 years. I've started with mining initially as a hobby. And then I started to work full-time in the ecosystem since 2016, I think. We started Ethereum France with a bunch of friends just to promote the technology and in Ethereum in the French speaking ecosystem, which led us to run conferences like ECC afterwards. Professionally, I worked for Esten Yong for about a year and a half, managing the blockchain team there. Then I opened the Paris Office of Consensus and then I worked for Ledger for a while. And then I wanted to do my own stuff. So that led me to do Camyth and develop games for locating blockchain into games mainly, which led us to tackle hard problems like onboarding. And on the technical side, technology side with the web of incurred specifically, we are super excited to support this kind of signing methods in our Akat abstraction solution. Just proven to be a very straightforward way to onboard people on blockchain. We showcase a cool demo during ECC, doing exactly that. We create modules and different implementation to be able to use it in those safe, notably. Along with the Ledger team, we did an implementation in solidity of the curve so that we have something to work with before we get the EIP done. And my relationship with this EIP is that I'm a strong supporter of it. Have to help on making it move forward faster. We had a couple of discussion on the side of ECC on how we could push it further. Happy to lobby the EIP to existence. I'm dead serious on using this curve for onboarding people on blockchain. I think it's a really good way to do so. I know it takes some times to get EIP implemented. There is a lot of things that needs to be done for the protocol to continue to develop and to ship new features. Whether it is at the beacon side or at the server side, at the execution side, but there are still room for adding new features of the EVM. And before we can get that, we can definitely do other stuff in the meantime. And I'm here to help and support.

Nicholas: Awesome. So I'll read the, well, two things. Firstly, I think for people who maybe don't understand or aren't familiar, I think it's worth checking out two demos that are online right now. Demo.alambic.tech or, so demo.alambic.tech or also iglootools.xyz. iglootools.xyz are both good demos that just show what kind of passkey driven authentication experience would be like for Ethereum. So you can see a glimpse of what this might look like. Although even those under the hood are not really taking advantage of what 7212 would offer. So I'll read the abstract for the EIP. This proposal creates a pre-compiled contract that allows signature verifications in the SECP256R1 elliptic curve by given parameters of message hash, RS components of the signature and XY coordinates of the public key. So that any EVM chain, principally Ethereum rollups, will be able to integrate this pre-compiled contract easily. So that's the abstract of 7212. Now, Ethereum and the EVM as it is, use SECP256K1. From now on, we'll just refer to them, I guess it's R1 and K1 for simplicity. So K1 is the standard elliptic curve that's used by ECP recover and is native to the EVM. I guess, what was it that drove, K1 was inherited in Ethereum from Bitcoin. What was it that drove Satoshi to choose the K1 curve for Bitcoin in the first place, which led to us having it as the native curve in Ethereum? I'll just like leave these questions open and whoever unmutes first can just jump in and everyone can get a turn.

Lionello Lunesu: Yeah, I remember. Okay, so from memory, I looked into that a little bit. The best I could find was suspicions that R1 had been doctored to the point as being easier to kind of break by NIST or NSA or whoever it might be. But I haven't seen any confirmation of that. It's a rumor, but a rumor might be enough reason for Satoshi to stay away from it, of course. But that's what I remember.

Jerome de Tychey: I do back this memory. I have the same and actually read the EIP-101 of Ethereum, the EIP-101. There are different discussions regarding this R1 key compared to the KYK1 key and people relating these rumors in the comments and so on. And so, yeah, I think there's a reason why as well.

Ulaş Erdoğan: We can consider the K1 curve as what provides the cryptographic security for the Ethereum and Bitcoin accounts. So while there were some rumors about the security of the R1 curve, it's really good idea to create more transparent and exactly secure cryptographic signature for the main elliptic curve. But it doesn't mean the R1 curve is unsecure and should not be used for alternative signature validation method as a pre-compiled contract and used by smart contracts. The R1 curve will be optional for who is already using this curve in their mobile device or other browsers, et cetera. And these topics are different discussions in terms of the security.

Nicholas: Okay, so maybe before we dive into that directly, like what is ECRecover? What does it do? How does it work? Is it the same mechanism for signing transactions that are interpreted or verified by nodes as it is for, like we're using the same elliptic curve for both signing transactions and for signing messages, which is to say, packets that are, data that is signed, that is verified by a node versus data that is verified by a contract. Is it the same exact, like? are nodes essentially doing ECRecover when validating the transactions are indeed valid?

Lionello Lunesu: Yeah, that's exactly what's happening in the nodes, yeah.

Nicholas: So the K1 curve and ECRecover, the pre-compile that allows you to verify K1 signatures is the same thing that's used for transactions in the nodes and for contracts, like for example, if you're doing an approval or maybe signing an order for C port or doing any kind of off-chain signing that can later be passed on chain, like a lazy mint or something like that. These are all using the same K1 curve. Yeah, I don't know if anyone wanted to comment on that or anything about like the context of ECRecover and K1. before we dive into like why it's interesting to add R1 to the mix.

Ulaş Erdoğan: Yes, it's the same curve, the signatures are provided by the private case. It's the case we know from the EOAs. You already have by Metamask or other roles.

Jerome de Tychey: And also obviously ECRecover is an instruction you can have in a Solidity contract and you can build cool stuff about that, like having notably account abstraction, like having a message that is signed and bringing it to a contract that will ECRecover this message to verify that the signature is being properly built and properly signed by the origin you expected to sign. And that's the basis at which account abstraction is built on top of.

Nicholas: Right, so people might be more familiar with things like just signing messages for say making a listing of an NFT on OpenSea using CPORT, but that same technology is useful for account abstraction, which is really where all of this 7212 is headed, is to really enable a lot more people to have account abstraction wallets because the native encryption of their phone or their web browser or their desktop computer will just work on Ethereum should 7212 be adopted.

Jerome de Tychey: EIP 712 is the thing you usually use for signing things on Ethereum. Like if you log in on an application that just asks you to sign something, it's actually this kind of signature that you are providing. And sometimes you use, so sometimes DeFi applications are compatible or NFT applications are compatible with just approving by sending a message, which is like one of the great things about that. But one of the reasons why so few people or you have so few instances where you are able to pay with crypto at an event, or ERL at a... Going into the bar and paying for a beer and picking up your phone just to sign a message. Since Ethereum requires you to have a wallet on your phone to do this kind of signature, it makes it way harder than it should. Like if you were just able to sign with a device that supports the kind of signature that you can generate in the phone natively, because it's in the enclave of the phone and it's well supported, that would be much better. That's the direction we're taking right now.

Nicholas: So this is what Leonelo was talking about a moment ago about software signing versus hardware signing. It's currently the K1 native elliptic curve for Ethereum and Bitcoin is not supported by the secure enclave hardware inside of iPhones and Androids, et cetera. And so if you wanted... Oh, maybe there's a correction, yeah.

Jerome de Tychey: No, it's somehow, somehow it's supported. Like HTC, the phone manufacturer supports it.

Nicholas: Oh, okay.

Jerome de Tychey: But don't really expose it natively or don't really showcase that it's completely exposed. I think Samsung Galaxy S5 was the first flagship Samsung with this kind of support, but it's not super well supported as well. And of course the enclave of the iPhone is like a wild garden like you don't get to have much access to it. So yeah, it can be supported. It can potentially be really easily supported. I think the other speakers will confirm and give you more color about that. It's just a matter of how easy it is for an application to interact with this curve in the enclave, to my knowledge.

Lionello Lunesu: Yeah, Jeroen, you're totally right. The actual hardware, it's not like the curve was implemented using the gates, right? And then all the MOSFETs on the chip. Those chips are just secure enclaves are processors like any other processor. So all the curves are implemented in microcode on those processors. So they're flexible enough to support any curve. It's just like as an iOS or Android developer, you do not have access. It's the operating system which decides that firmware that's running on the secure enclave on those chips is completely determined by the manufacturer. Of course, that's part of where the security comes from. And so the hardware would support any curve, but the software, the firmware that Paul, et cetera, decide to use, they basically lock it down to one or the few curves.

Nicholas: Do you have any sense why they chose R1 as the standard curve?

Lionello Lunesu: Yeah, just NIST, right? Like just a standard that's been standardized a while ago. And that's why the same reason RSA, NIST, the whole family of NIST approved crypto. Why particularly R1, I do not know.

Nicholas: Yeah, so maybe this is a good time to return to the question of whether or not it was compromised. What is it about R1 that people are concerned about? There's like a constant or a coefficient in the spec that is very specific that people are concerned about.

Lionello Lunesu: Yeah, maybe another speaker knows more details, but I'll share what I know. It has happened that a proposal was sent to NIST for standardization and people found out that the constants has somehow been doctored. Now, all of these curves are basically just formulas. They use a bunch of constants, right? In the case of elliptic curves, you have A and B constants, that you have A times X to the third plus B, and that's your Y squared from memory. So those A and B are numbers that are chosen seemingly random numbers. Of course, you have to create a field for the elliptic curve cryptography for the addition and multiplication to work over that field. They have to be, cannot be actually random. They have to be chosen carefully. But if you choose them, if you choose weak numbers, then you do not get your 256 bits of security, but you get like, I don't know, maybe 50 bits of security. You can actually do that. And it has happened. I think if you scroll down in my blog, if I remember correctly, I do link to one of those instances where a cryptographic algorithm was proposed to NIST for standardization, and people actually found out, hey, wait a minute, this claims to have N bits of security, but actually it doesn't because of the choice of the constants. And so, yeah, people, you know, it's good to be suspicious about these claims. Back then, people have discovered a backdoor. R1, I don't think people have. Does, of course, that's not proof that there isn't, but yeah, so not everything that gets standardized is secure, of course.

Jerome de Tychey: Pretty cool blog post, by the way. I loved it. Reddit three years ago and Reddit again a couple of months ago.

Nicholas: Jerome, was it you that shared it? Was it in Ethereum Magicians? or I don't know where I found it but it was awesome to read exactly what we're talking about today from seven years ago.

Jerome de Tychey: I don't remember which I did exactly, but whenever those topics emerge again, we have those kind of documentation at the end and it's really good for bringing the knowledge to the masses and to the authors that are jumping in the conversation.

Nicholas: So why are these constants in the R1 spec not something that's summoned with like a ceremony where you only need one actor? that's honest, like the KZG summoning ceremony that's going on right now? Why are we, it seems like a fault in the way that these NIST standards are set up.

Jerome de Tychey: Oh, well. No, go ahead. I feel like the whole politics and the whole governance inside NIST and things are really hard to grasp. So I honestly, I wouldn't know.

Lionello Lunesu: Yeah, same here. I have no idea. Yeah, it's an interesting point, right? Why NIST should be standardizing the process by which we get those constants as opposed to the actual constants.

Nicholas: Maybe we have something to- Maybe we have a new EIP to write for NIST. Okay, so we've kind of alluded to it already, but which devices support R1 currently?

Lionello Lunesu: Yeah, so in 2016, we had to be picky. And it was so the iPhone 5S and only the newer Android phones. Right now, I think every phone, if it's not a dumb phone, I think R1 is supported.

Nicholas: And every browser as well, as well as every desktop OS from what I understand.

Lionello Lunesu: Yeah, they might not all have a hardware like the MacBooks they do. They have the same secure enclave as the iPhones do. The new MacBooks, they all do.

Ulaş Erdoğan: And some browsers are supporting R1 with WebAuthn standard. It's again, a software signing standard without any hardware, but a similar UX for the users.

Nicholas: Yeah, could you explain a little bit what WebAuthn is? Because it comes up a lot in the documentation.

Ulaş Erdoğan: It's a signature standard, which is used by browsers. And I'm not sure which alliance has standardized this method, but now it has been using for most of the browsers for now. And it allows creating some KPIs for the browsers. then sign some message with that KP.

Nicholas: And do you know if like WebAuthn in a browser, say in Safari, would it be using the secure enclave on a Mac or on an iPhone? Or like, does it tie into hardware if it has access?

Jerome de Tychey: Yes, I think so.

Lionello Lunesu: Yeah, I think that is kind of the added value there, yeah.

Jerome de Tychey: It's even better than that actually. When you have the keychain available, the keychain features available, I think Apple has a trick on linking the state of your secure enclave cross device connected and synced in some way. I don't know exactly how they achieve it if they save something, an encrypted version somewhere. But when we tested the demo that you showed the link before, like demo.alambic.tech, we had situations where people were on Safari going to do the demo and creating a WebAuthn passkey on their iPhone. And then later on, they will go again on the website with their desktop, it will wake up their Apple iWatch, just to validate the thing. So it's weird to notice, and I don't know exactly what's the jinx behind it, but they managed to have it available across device once you are connected with the same authentication, the same authentication, Apple ID everywhere. And I heard from, I think it's a Google blog that they plan to do the same on the Google account as well. So it's getting very widely supported.

Nicholas: So basically, they're coming up with ways to securely sync to a cloud keychain, these passkeys that are, so maybe, would someone like to define what a passkey is and maybe relative to WebAuthn also?

Lionello Lunesu: I haven't used it, but I think it's just the newer version of WebAuthn. It's kind of, it used to be Fido, if I remember correctly, then it became WebAuthn, and passkey's kind of the latest iteration of those specifications for cross-browser support.

Jerome de Tychey: Yeah, the whole goal, as I understand it, from those actors is to standardize the way we authenticate on the web, so that they remove the need for storing password, remembering password, and so on.

Nicholas: For anyone who's, yep, for anyone who's interested in that, I'm gonna be talking to Jose Aguinaga in a week or two, who has this passkeys.is site, which covers a lot of info on passkeys, and especially the intersection with crypto. So we'll get into more details on passkeys in a future episode. Did you wanna throw anything else in, Gerald?

Jerome de Tychey: No, I'm good.

Nicholas: Great, so basically, passkeys are kind of like the UX for someone on a phone or on a computer, when, for anyone who's not able to try one of the demos, just to give you a sense of how this feels, if you go to demo.alembeck.tech or igloo-tools.xyz, you go to the page, you click create, you know, create an account, essentially. It offers you with a native popup for either the browser or OS that you're on to create a passkey on device. The passkey is generated on your device, and then, at least in the iOS experience, but I think in principle everywhere, you're offered the option to either store the passkey locally on the device only, to sync it to iCloud Keychain, if you have an Apple ID logged in, or to save it to a YubiKey for a hardware key experience. So pretty cool. Maybe I'll ask, because I don't know, I'm assuming, but can we trust things like Apple Secure Enclave? And if so, why? Why are we able to trust Secure Enclave more than software execution?

Lionello Lunesu: Yeah, go ahead, Gerald, make sure you have something.

Jerome de Tychey: Well, I'm always a bit cautious on that. Like, I've been working with this for a while, and I love the devices of single purpose. Like, if you're just using your Fido key, and I navigate this thing specifically for that, I'm not super familiar on how the Enclave is actually being accessed, or is actually being backed up by the manufacturer, and so on, so, but yeah. No, I don't want to add anything. How much can you trust this? Probably more than you can trust a website that generates a private key for you, that's for sure. But yeah.

Lionello Lunesu: I think the security comes from the fact that this CPU is not doing anything else, right? The firmware is locked, would help if we could see it, but there's not running anybody else's code, no user code is running on that CPU, and it's only doing those crypto operations. That's where the security comes from. So side channel attacks are not possible. Is a firmware backdoor possible? Yeah, hardware backdoor is possible, but yeah, though they get scrutinized pretty thoroughly though. So on your regular CPU in your mobile phone, on your MacBook, there is a lot of code happening there. The JavaScript from different websites are executing on the same core, or maybe on a separate core, but on the same die, and still side channel attacks happen from one core to the other. So it's very hard to protect if that CPU is doing multiple things that you don't know at the same time. So having one dedicated CPU with no user code, no nobody's code other than Apple's then running, yeah, that's where the security comes from.

Ulaş Erdoğan: And the keys can be accessed app-specific, so any other application or any other purpose can reach key to sign transactions. Or any message, also the keys cannot be exported in any way. So we can think it's secure if not any backdoor in hardware, but it's well misadapted. And we also rely on secure enclave for nearly all of our applications in mobile phones. So another consideration or discussion for the security.

Lionello Lunesu: Good point.

Nicholas: So maybe we can think of it a little bit similar to the recent Ledger experience, where we have some trust in the hardware because it's not running arbitrary code, it's not executing arbitrary code that could maliciously exfiltrate keys from the secure enclave. However, firmware upgrade, either in the Ledger case, voluntarily upgraded by the user, or in the Apple case or other devices, potentially just done in the background silently without us realizing it, could allow for a change in the firmware that's running on the secure enclave. So there is still trust in whoever the hardware platform is, because they could change the software such that it would no longer be a secure enclave. Is that a fair summary?

Lionello Lunesu: Yeah, I think so.

Nicholas: So we're trusting Apple or whichever hardware manufacturer slash OS creator, but it is certainly more secure than, for example, I don't know, maybe the standard right now for hot wallets is, or for software wallets, is something like MetaMask, where the key is living inside a piece of software that's running on the same CPU as your browser and on World of Warcraft and everything else on your computer. So it's certainly better than that, but there is still a significant degree of trust in the manufacturer because they do have opportunities to exfiltrate the keys if they want to through upgrading the software. Okay, but at the same time, it's not to fearmonger, it's also the same level of security that we have for the rest of our ecosystem when we store passwords in iCloud key chain locally on a device, it's the same level of security. So it's as good as anything else is secure in most people's lives.

Lionello Lunesu: Yeah, there are schemes to make the trust less important, like you have now key splitting schemes, where maybe part of the key is on the secure enclave and part of the key is in software or even across secure enclaves. And so a single secure enclave would not be able to retrieve the key. So you can do those kind of key splitting things. And in theory, you can do them in a smart contract, you could actually have a multi-sig. And so if you go to that trouble, then you could have a multi-sig across different devices, different manufacturers even.

Jerome de Tychey: Yeah, I think from a long-term perspective of Ethereum accounts, and if we make the bet that EVM is going to be the standoff in the next couple of years, I think the whole point is to help the users migrate to something more smart wallet oriented than just EOA oriented, and let them spread the security and the recovery of their accounts across many devices that they will trust. Like if you have a quite hot key in a secure enclave of your Samsung phone or your iPhone, and this key can manage a couple of dollar per day on a single signature on your phone, it's great. And for whatever that's more than 1,000, 10,000, 1 million, whatever you have, you get to activate your ledger, your Trezor, your other accounts to let it live. It's just, for me, I think the right way for users to be managing their accounts in the midterm. And now we have standards emerging and things getting more and more easy to use and implement and distribute. The whole account abstraction movement right now is trying to push people to onboard on applications that provide them with a smart wallet. So you create an account, like you would create an account on the web to applications, and then you get a smart wallet that is used as your address for this application. Maybe you want to decorate this smart wallet with your own EOA, where you have your NFTs, your funny things, and so on. Or maybe not, you can remain quite anonymous to these applications with what you put inside. In this context, WebAuthn keys are really useful to get the user to sign stuff that they want to have happened on the chain. And that's something extremely powerful for the adoption of push technology as a whole.

Nicholas: Great, so let's dive right into the 7212 piece of this now that we have a kind of understanding of what the context is. Ulas, can you explain, what does it mean for 7212 to propose to incorporate a precompile for R1? If you can just walk us through, what actually is 7212 proposing?

Ulaş Erdoğan: Okay, for the verification purpose, we should execute some copies inside of the EVM, then be able to understand the signature is valid or not. We can do it with Solidity. Also, the Ledger team has a great implementation in Solidity, but it's still not very much efficient. And when we want it to be used by many users and many applications, we need more efficient approach and solutions to verify these signatures inside of the EVM. And precompiled contracts are special codes that are running inside of the clients. And the output is given to the smart contract directly so that we can have cheaper transactions or operations with the precompiled contracts. And our solution presents this verification operations are being executed as precompiled contracts in the clients. Then we use them in this whole difficult time. We are having an efficient implementation of this curve signature verification operations.

Nicholas: So what you're saying is that you can already actually, like for example, what we're maybe just, what we're trying to get towards here is that people will be able to sign in, as Jerome explained, with their Apple ID and then just be able to sign directly using Face ID or Touch ID, or in the worst case, PIN code or password. And then just this key that their iPhone is handling or whatever platform they're on will be directly able to sign transactions or messages that an account abstraction wallet can verify. But you're saying that actually Ledger, this design that Jerome also mentioned earlier, that Ledger already has a contract that can do this, it's just too gas costly to execute.

Jerome de Tychey: Yeah, well, it's something that we worked, my team worked on with Ledger. We did the first naive implementation. that was 400,000 gas, 400K gas for verifying a message.

Nicholas: That's like 4X, like an FTM.

Jerome de Tychey: Yeah, yeah, at least 4X, 4 to 5X in an FTM. I mean, so basically you create a smart contract where you describe what the elliptic curve is and you have a function that's verified signature and you call this function. So the flow you describe as a user is logging in with his key and signing a message and sending this message to the blockchain for account abstraction purposes. We had to call this smart contract and execute the verification on chain and inside a really not optimized implementation, inside a really not optimized virtual machine for this kind of operation, the EVM, and thus you get the 400K gas. So that's completely out of the question to run that on mainnet. It's really not feasible, like it's really bad. On an L2, even the really naive implementation of 400K gas, it's okay-ish. Like if your L2 is not that expensive at the moment or if the, it's all right. It's not the best, but it's all right-ish. And after a few optimization and that'll be the latest ledger team optimization, we are down to 70K gas. But that's becoming quite okay, but still not the best. Like, yeah.

Nicholas: You don't want to sign every transaction that way.

Jerome de Tychey: You don't want to, yeah. You don't want to sign them. You don't want, yeah. It's actually, it's adding some overhead. that's kind of detrimental to the usage of the chain. If you have a quite empty chain, like if you have an app chain dedicated to a video game, for example, in this case, it's okay to work with this. I think, yeah, it's okay to use that kind of thing. But if you are like on optimism, on Arbitrum, it's not okay. But running that on Polygon, which is kind of less expensive than both Optimism and Arbitrum, it's okay-ish to use this kind of thing. But if we had a pre-compiled, we will go from 70K gas to probably 2002 or 2001. I don't know, guys, what do you think? I don't remember in the description of the EIP that if you provided this kind of calculation or not.

Nicholas: In the EIP, it mentions, for context, EC recover costs 3000 gas. So for listeners, what we're talking about is taking this kind of contract that Jerome just described, which costs 70K gas, and then including it as essentially an opcode, a pre-compiled contract. that's super efficient.

Jerome de Tychey: In which case, if you run GIF, you would have the curve in Go written in the same language as GIF. And whenever a contract is calling for this kind of execution, we consider that the client is executing it locally and giving the answer to the smart contract. So there's, yeah, it's as good as if it was native.

Nicholas: Right, awesome detail. So what that means is that the gas cost for making a call using this opcode can be arbitrarily set by the EIP. For example, EC recover costs 3000 gas, and Ulash in the 7212 proposal suggests, because it's 15% slower than EC recover over the K1 curve, they suggest 3450 compared to 3000. So 3450 is the gas currently, but maybe you think it could go even lower?

Ulaş Erdoğan: Yes, it's up to the first reference implementation. And if we get a more efficient implementation by a Get team or other developers, the proposed gas amount can be changed by the performance comparison.

Nicholas: Awesome. Did anyone else want to jump in on that?

Lionello Lunesu: Maybe a nice anecdote. When I first wrote the EC, the R1 verification algorithm in first Serpent and then Solidity, it was like 3 million gas. Then Ethereum added the modular exponent built-in, that's number built-in 0x5. That happened in 2018, if I remember correctly. And that dropped it down to 600K. So it was still way too expensive for us. It's also the reason why we ended up using a self-hosted Ethereum consortium and not the main chain. Back then for that company that I was building this for.

Nicholas: Very cool. So in 7212, the P256 verify precompile mentions it's 15% slower than EC recover. But is this new ledger implementation faster than that? And is there anything fundamental that should make it differently computationally expensive to compute than the K1 computation? Why is it more expensive to verify R1 than K1? Is there any real, is it more complicated?

Lionello Lunesu: Actually, it's a funny thing. My blog post touches upon this a little bit. They are using the same formula, just different constants. Just so happens that in K1, one of the constants is zero. So any addition, any multiplication with that particular constant just completely disappears in the code. So the code is significantly shorter because there's just less multiplications and less additions that you need to do because one of the constants, one of the two, right? So we have A and B and A is, if I remember correctly, is zero. And so, yeah, you end up with shorter code. In fact, a lot of the trouble I had to go through is find a good algorithm that actually bothers having all the additions and multiplications in there because most of them, they just ripped out any addition with A or any multiplication by A.

Nicholas: Wow.

Lionello Lunesu: That would explain the 15% easily, yeah. I can see that.

Nicholas: Right, right. So it'll always be a little bit more compute, but not noticeable if it's executed natively on the node clients.

Lionello Lunesu: Sorry, go ahead, John.

Jerome de Tychey: Sorry, I was about to say maybe that's one of the reasons why Satoshi picked this curve as well. The code, there's a lot of zeros, it should be faster.

Lionello Lunesu: Yeah, it's true. But what Geth could do, of course, is use the hardware it's running on, right? So if Geth is running on a PC with a secure enclave, they should just call that.

Nicholas: Oh, very cool. Does that mean anything meaningful for doing that kind of operation on even mobile devices or more limited computers that have secure enclaves? Does it make the chain somehow easier to, like less computationally expensive to verify? I guess not because- Exactly.

Lionello Lunesu: All the blocks that come in are still K1, so no transactions.

Nicholas: So this leads me to a question. Would you expect ECRecover to remain very important or do you think this would completely take over and everyone would be on R1 instead of K1?

Jerome de Tychey: Well, I think if we had this new curve implemented, it would be a giant boost for all the abstraction solutions. Everybody can agree that the number of downloaded wallets like around there is so small compared to the number of compatible device for this curve. So if the next wave of users is 10x, 100x, 1000x, the number of users that we have right now, we would have much more usage being done with this curve than we have right now with the current wallet situation, I think.

Ulaş Erdoğan: I think the answer- Do you guys agree? Yes, I think this answer is dependent how account abstraction wallets will be evolved and be adopted. If you will see lots of smart contract wallets with lots of onboarded new users, we can see the R1 curve will be more adopted as a pre-compiled contract. But I still think EC-Recover will always have a significant usage inside of the EVM.

Nicholas: And by extension, EOAs, like traditional private key EOAs. Okay, so the idea is not that it will replace EOAs and that EOAs will still have an important role. Do you have a sense of what EOAs will be important for, for more secure kinds of wallets or for some other kind of transaction? Where do you think the line will be drawn between, obviously, as Jerome points out, if 4 billion people come onto EVM chains or 4 billion devices plus, maybe even 10 billion devices, given everyone has so many computers in their lives, there will be more people signing, more humans signing and more devices signing with R1. Or it's conceivable that that could happen. What do you think K1 will still be used for?

Ulaş Erdoğan: The Atarium as a core design still needs EOAs to execute transactions. The smart contracts cannot execute any transaction directly. So we will always need any type of EOAs to start transactions. If that we won't see any core protocol chains for account abstraction, that I don't expect in a soon term. So I think we will leave it EOAs. And Metamask and the other EOAs still have some kind of adoption, but we can break this line with lots of onboarded new users. But for that, we need more real life use case to bring more users with good user experience and real world applications. So I think we need time to break this usage of EOAs.

Nicholas: Do you think it's possible that with like rollups and centralized sequencers that can include transactions with zero gas, is it possible to skip the EOA, like skip a paymaster even and just directly have signatures being brought on chain by sequencers?

Ulaş Erdoğan: For example, in ZK-Sync design, this cancer includes smart contract wallets transactions directly. It's really good approach and ZK-Sync is doing well for smart contract wallets. I think I agree with you, we can see more of this kind of applications in rollups.

Jerome de Tychey: From my point of view, we have a, it's a weird topic. When you start to distribute account abstraction, everybody was pumped up with 4337, like, oh, this is the future. Yay, let's do it and so on. The reality so far for us, and maybe it's different for different providers of account abstraction, but so far, people like the paymaster approach, like the philosophy behind the paymaster approach. To be fair, they don't necessarily care to have the complexity of the whole message mempool that needs to be brought up and then having the payments done with a token and so on. So it's, I don't really see right now a strong demand, but, you know, tides and winds can change super fast on the blockchain for something super decentralized and just smart contract based. But should this really become important? Like everything is abstracted 4337 style and we have paymasters and so on. For me, this market of relaying transaction from the mempool and pushing them on chain will be completely taken over by MEV searchers, block builders and centralized sequencers. Like that's just the way to go. So yeah, I totally think that if we abstract another thing not at the protocol level and we use a or not at a direct one to one relationship between a few providers and the applications that want to sponsor those transactions, we will get in a situation where those messages, if that takes off, gets directly sent by the block builders.

Nicholas: So Ullash, in the EIP-7212, there's this section that reads, in the rationale section you say, even if recovering the public key on the curve is possible, most of the applications are not generating the component of the signature and it causes an uncertainty of the result values. However, the signatures can be verified with only R and S values. in order to provide an exact and more compatible method, verification is preferred over recovery to propose in a pre-compile. Can you explain what that means?

Ulaş Erdoğan: Okay, we can start with what is verification and what is recovery. A signature consists of three type of values. It's V, R and S value. It's the coordinates of the signature in the elliptic curve in three dimensions. And V is the sign, the region of the signature point in the elliptic curve. And when we do verification, we only need R and S values of the signature with the public key. Then with the signature, it's at the signed message. We can obtain that the signature is valid for the given public key or not. But for the recovery, we need three of the values, the V, R and S one. And we only need the signature itself without the public key. And when we give them signature components, R and S and the signature itself, we obtain the public key. It's the public key of the signer, private key. And for the K one and R one curve, these methods are working in the same way. And the public address we know from EOAs are the hash of the public case. So when we do recovery in the K one elliptic curve, and when we use the recovery, we are directly reaching the public address of the EOAs. But for the R one curves, it's completely separated from the public address mechanism of the smart contract account. And even if we do recovery, we are obtaining some public case values, which we are storing in the smart contract accounts. It doesn't help us to use the public address or similar pre-stored data. We still have to store this public key in the smart contract accounts. So it doesn't help us to use the current public key directly. And the same time, the providers of these R one signatures, for example, WebAuthn or SecureAnkly, don't give the V value of the signature for us. The V values can only be zero, one or two. We can basically try all of the values in the mobile application side. And when we find the V value, we can give it to the smart contract to recover this signature. It's a possible way. But I think that verification provides a more simple and more standardized solution for the R one curve as no lots of efficient things are being by the recovery.

Nicholas: So let me repeat that back to you as I understood, and you can tell me if I made a mistake in my understanding. But essentially, in the K one curve, we're relying on the hash of the public key to create an address, which is commonly used in EOAs, et cetera. Addresses are something that's very frequently used in even in contract design. Implementations of contracts will depend on addresses. But if you're presuming that pass keys are used primarily as signers on account abstraction wallets, then the pass keys themselves, we don't need to derive. It doesn't really matter what the public address would be of a given pass key, because we can directly verify that this pass key signed this message, which is a transaction that an account abstraction smart wallet will be executing. And that smart wallet has its own public address, which can be used for composability with other contracts or other EOAs on the EVM chain, which it's found. So because we don't need the public address, we don't need the V component for recovering that public address when it's a pass key, because you're anticipating that's primarily used for signing AA transactions. Am I understanding correctly?

Ulaş Erdoğan: Yes, but the choosing the carrier verification is still an ongoing discussion. Some of the core developers and community members as recommended to use the carrier to follow the standards of EC recovery, then being able to make in recovery for any possible potential use case. But it's my view and I'm still open to hear more suggestions and change the way of the EIP from verification to recovery. That's one of the most important feedback that I want to hear during the review stage of the EIP.

Nicholas: Jerome or Leonel, do you have thoughts on this?

Lionello Lunesu: Yeah, I went through the same process as Ulas. Like I implemented the verification first, where you provide the transaction hash, the RS component of the signature and the XY component of the public key. And much later I added recovery to that smart contract. And to be honest, the main reason was just symmetry with EC recover. Both, so the whole algorithm recovery, signature creation, signing, verification, they work identical between K1 curve, R1 curve. And so it seems clean to me to provide a recovery function because EC recover is kind of the way that people are used to using the K1, verifying the K1 signatures. And that's mainly the reason purely for symmetry reasons. Verification is easier to understand, that was easier for me to understand back then. But security wise, if you have the three components that you need for recovery, V, R and S, and you don't have to guess the V, right? That is a good point that Ulas made. If you have to guess the V, I think you're a little bit compromising a few bits of your security. Maybe not worth talking about, but if you have the three components and R1 can use recovery algorithm just as K1 could, and you end up with less data, right? You end up with, you don't have to provide like five, I think, 32 byte numbers. You just have to provide the V, R and the S.

Nicholas: In which situation would you not have the V? If you're signing from a passkey on a AA wallet, you don't need to pass the V? Is that the idea?

Lionello Lunesu: You can create, you can get, so the problem is you will have to calculate it yourself. So that is kind of the downside. Ulas mentioned that, right? So if you sign with a crypto secure enclave, you get your R and S, and then you have to kind of in software calculate that V. So it's true, yeah. That is an extra step that the software has to do and possibly a place for bugs, right?

Nicholas: I wonder if this has anything to do with Safari 17 introducing this large blob, and I'll quote Dan Romero saying, he quotes the Safari documentation, websites can use the additional storage of large blob to save data that can later be retrieved when signing in with a passkey. These saved blobs are synced and shared along with passkeys. So I guess you could be generating a public address or maybe several and saving them with a passkey so that when someone logs in, you don't have to compute it, but instead it's part of the biometrically authenticated experience that the DAP gets access to the public address if it was saved in a large blob when the passkey was created. Have any of you thought about that or is it relevant here?

Lionello Lunesu: Oh, I would have to read up on it. I can't tell whether that is something that would help here. for the V case, right? For the recovery case.

Jerome de Tychey: Our team have had a look about it and we are still digesting on what we could do with it. And definitely there are some cool use cases where you store keys or even burner wallets inside of it. That's all. those are use case of leveraging that. But so far we haven't done many things around. We're just discovering this addition.

Nicholas: So Ulash, the difference between whether the implementation or the spec for 7212 is symmetrical with the EC recover spec, if it were to be as written today without the recovery piece, then 7212 would be primarily useful for signing on AA wallets. But if it is made symmetric, then maybe there are a broader set of applications and every passkey would automatically have a public address associated with it. Is that the lay of things?

Ulaş Erdoğan: Actually I couldn't get it.

Nicholas: Like just, what is the contention? What are the two possible worlds that are in front of us here? Either we don't have recovery in 7212 and so passkeys are only useful for signing messages on contracts such as AA wallets, or we do get recovery built into 7212 and that means that every passkey has its own EOA, is its own EOA directly. Is that the kind of two paths in front of us?

Ulaş Erdoğan: I think having the recovery or verification don't change any use cases. If we are... Yes, it will only affect the implementation and usage of it. Even if we are making recovery, we still need to obtain public key from somewhere. It can be stored in the smart contract or it can be obtained by anywhere and we'll be comparing this output and the other obtained key. And if you are using the verification, we will be giving this obtained key to the verifier contract, then smart contract or pre-compiled contract and we will be getting the result directly by this code piece.

Nicholas: Leonel, did you wanna jump in on that before we move on?

Lionello Lunesu: Yeah, I think I agree with Ulaş. Recovery versus verification shouldn't affect the actual use cases. It's just a different API. You need more data if you need verification because you have to provide the full public key. With recovery, you're basically recovering the public key. So the comparison of whether the signature is valid is different. In the verification case, you get a Boolean, the signature is valid or not. In the recovery case, you get a public key. So now it's up to you to compare, is that the public key that I expected? So the API is different, but the use cases should be similar.

Nicholas: So I wanna jump in more to like use cases, how this actually feels in the absence of R1 and 7212. What's the current workflow for an AA wallet that wants passkey signers?

Jerome de Tychey: So you need to be on a chain where you have a mean to verify the signature of such a signer. So you need to deploy the verification contract and then that's it. Like when you deploy a new AA wallet for someone, you decorate this AA wallet with this signer as the signer, and you make a call to your implementation of the curve to verify the message. And you pass along this message as a transaction from your users, an abstracted transaction from your users. And that's pretty natural flow and you don't really see the blockchain at all and it feels very good. Yeah.

Nicholas: And then I guess for L1, I've also seen in the wild, some people are using the passkey as a signer in a, either they're deriving a private key directly from the passkey and then using that private key to sign transactions in order to avoid this 70K gas you mentioned earlier, or they're using the passkey as a signer in an MPC computation, which also allows them to do other multi-sig stuff at that stage before the AA wallet. So you can have a single signer that's MPC on the AA wallet, but maybe multiple passkeys that feed into that potentially. And then the MPC is effectively acting like an EOA and signing using the K1 curve. Does that all scan? Does that make sense?

Jerome de Tychey: Yeah, that's the way to see it.

Nicholas: Like there's this alternative way where people are deriving regular old K1 EOA wallets from the passkeys. that is kind of a stopgap until 7212 or something like it comes to pass.

Jerome de Tychey: So- Sorry, the sun is a bit clipping on my end, sorry.

Nicholas: Oh, that's okay. Anyway, so currently the status quo is that there's two options. Either you can like essentially derive a regular private key from a passkey as a kind of stopgap in order to not have it cost more gas, but to put more trust in some kind of wallet provider or someone who is going, or some software that you developed that's going to do that process, which is dangerous. And there's also a private key somewhere that could leak, or you can use this ledger or whatever, state of the art contracts come in the future that are highly optimized for verifying R1 signatures, which makes sense on L2s maybe more than other places. So with 7212, how would signing look like inside of a DAP? Let's say I have an iPhone. Would I be required to do biometric authentication or some form of authentication on the device every single time I want to sign? Or would I be signing in one time and then the DAP has some kind of access securely to the passkey?

Jerome de Tychey: You get a notification saying, it depends on how the Secure Enclave is accessed on the device. You get a pop-up like a native notification on your screen saying, do you want to put your face ID? Do you want to put your thumb or something? And that every time the Secure Enclave is triggered, at least that's what we've seen so far. And I'm not sure if the flow can be that changed or that customized afterwards, but it feels really natural. Like when you pay with your iPhone and then you get the notification saying, do you want to do this payment? Like you want to give it access to credit card details that are stored in the Enclave as well. So it's pretty natural for DAP that we're using that as a method of signing.

Ulaş Erdoğan: Also, it speeds up significantly the onboarding process. when a user downloads the application, it can be a wallet. They can reach all of the functionalities of the wallet by scanning their face ID for one time, which is creating a K-pay for the application inside of the Secure Enclave. It's a second of onboarding compared to other UA wallets and it's a great thing. And a comment for the thing you mentioned a bit earlier, for making more signature verifications with just one scanning of face ID, the session case can be implemented for the account abstraction wallets. So that's for just the face ID, with just the face ID scan, more transactions can be made by the application.

Nicholas: Very cool. So I could have like, I sign up for a new DAP, like a Frentech is the one that's in my mind. I don't know if all of you have played with Frentech, but you could imagine signing into Frentech one time with face ID, creating an account, it creates an AA wallet. And then maybe the passkey, that passkey has total control over the AA wallet, but you have a session key that has limited access that can do smaller transactions and that I don't need to face ID like I do with Apple Pay. Every single time I do a transaction, if it's like a less risky transaction.

Ulaş Erdoğan: Yes, I can let Frentech to use my 0.1X and the application can do transactions for me.

Nicholas: Very cool. That's awesome. I was thinking that all this passkey stuff and the reliance on the Apple APIs would mean that you'd have to do face ID every single time because the DAP couldn't have it. But this generating session keys is really, really cool. I haven't seen anybody do that. Have any of you seen any DAPs in the wild that are doing something like that?

Ulaş Erdoğan: We have implemented a bit proof of concepts inside of our team to try how it's going on and implementing our product, but I don't know if there are any applications in production that use session keys.

Nicholas: Cool, well, it's something to look forward to.

Jerome de Tychey: Dorko. I'm sorry, I need to walk off unfortunately. I need to run. But it was really pleasant to catch up and discuss this topic. And always nice to have a relation. you are on the same space.

Nicholas: Thanks for coming. Thank you.

Lionello Lunesu: Yeah, thanks.

Ulaş Erdoğan: Thanks for joining us.

Nicholas: Yeah, there's just a couple of questions I had left. So P. Caversaccio, who's a kind of Twitter dev personality, people might know, mentioned in the Ethereum Magicians conversation about this that the yellow paper says that opcodes should be preferred over precompiles and that precompiles are kind of a short-term solution. And as a result of that, he argues that we should not introduce new precompiles. Do you have any thoughts on that?

Lionello Lunesu: Yeah, what I can imagine is that precompiles are much less risky.

Nicholas: Than introducing opcodes?

Lionello Lunesu: Than new opcodes, yeah. But to be honest, I don't have any data to back that up, but that's just a gut feeling.

Ulaş Erdoğan: And I can't imagine how it can be operated with opcodes. It can still be costly for the Solidity implementation. And I should research more for an opcode implementation.

Nicholas: So there is a difference between a precompile and an opcode. It is a, there's a technical difference.

Ulaş Erdoğan: Yes, the opcode is for running Solidity codes and precompile contracts are operated inside of the client. So it's generally more efficient than the opcodes.

Nicholas: Okay.

Ulaş Erdoğan: I think it's up to the approach for the precompile contracts. It's a general discussion for Ethereum having more precompile contracts or not having any more and keep Ethereum simple. And also Pascal, the guy you mentioned, is proposing to remove some of the previous precompile contracts to simplify the Ethereum. It's completely a different approach.

Nicholas: Got it. Okay, so it's just an implementation choice that maybe the community will decide one way or the other what it prefers. And I guess the final question I had was, if you have any thoughts on how all of this relates to social recovery, do you think that the introduction of 7212 makes it more viable? for, I mean, I'm very excited about this in the Apple ecosystem, the way that they've implemented it. Seems like you really do start to get, we talked about this a little bit on a recent episode with Privy, but if you create a passkey on device, sync it to iCloud Keychain, you use the enhanced protection feature where Apple throws away their access to your iCloud Keychain. So it's end-to-end encrypted by the password for your Apple ID. And then you introduce the recovery contacts feature they have where, I actually learned a little bit more since the last episode. Essentially, you add anybody who has an Apple ID, and if they accept to be your recovery contact, they individually can recover your, essentially they can give you a recovery opportunity on a device that was previously logged in as you. So that seems to be pretty close to what we imagine social recovery would be like and built into over a billion, maybe two billion devices in the world. Do you have any other thoughts about how this relates to social recovery?

Ulaş Erdoğan: I think it allows more recovery people to onboard in the volatile stand, because I should trust my social recovery person to be able to store their case in a safe way. But if they are storing their case inside of secure enclave without any external effects, I can trust them to store my secure social recovery functionality.

Nicholas: Do you imagine that an individual DApp will have a single passkey to access it? Or that if I have multiple devices, maybe in different software ecosystems, like an Android phone and a Mac with Safari, would I have two passkeys that are both signers for the same DApp on a given AA wallet?

Ulaş Erdoğan: Definitely there should be more signers for your wallet to improve the usability from more devices and also more security if they are set up like multisigs. And I personally prefer having a key from my mobile device than having the key from my laptop. Then add some recovery opportunities like having social recovery or backup. So I imagine it's more case.

Nicholas: So the future might be something like, I have an AA wallet, I have a passkey that is shared between all of my iOS devices because of iCloud Keychain, and I have a separate key for maybe all my Android, Google ecosystem devices because they have the same password manager. Or maybe I even use another password manager, a third-party password manager that's cross-platform. And so I could just have one key, but maybe I choose to have multiple. And one benefit of that would be maybe for a larger transaction, I have to both sign from my iPhone and from my Windows laptop and Mac laptop or something like that, in addition to the recovery opportunities that that creates.

Ulaş Erdoğan: Yes, these are just security considerations to have a key shared by online recovery mechanism like iCloud or directly having it only inside of the secure enclave.

Nicholas: All right, that's the end of my list of questions. Is there anything that I neglected to mention that we should discuss before we call it?

Ulaş Erdoğan: We are also thinking about a progressive pre-compiled contract idea by DC. They are also building a wallet application with secure enclave support. How would that work? We can maybe just, okay. It's using a Solidity smart contract to create progressive future pre-compiled contracts in a specified address with create-to. And you are deploying these Solidity codes with the pre-compiled contract interface in the same address in different EVM chains. Now I'm proposed to change this address smart contract with a pre-compiled contract in a future time. And until that future time, having an adoption to the ECOSYSTEM to a pre-compiled contract for this purpose. It's for the chicken egg problem for the pre-compiled contracts. We need more use cases to have and use this pre-compiled contract. But if there are not use case for now, it don't make sense to use a pre-compiled contract for this purpose. And it's kind of a loop. And if we can get an adoption with this Solidity codes as a future pre-compiled contract, then we can change this Solidity code with pre-compiled contract and it will be a backward compatible use case.

Nicholas: So basically this would let us start using it today. And then if 7212 passes, evolve into 7212, which will be more gas efficient.

Ulaş Erdoğan: Yes.

Nicholas: Very cool.

Ulaş Erdoğan: It's kind of starting with latest implementation and changes with a pre-compiled contract.

Lionello Lunesu: That's a great difference between upcode and pre-compile. That is true. Any user, any smart contract using the existing contract would simply have to point to the pre-compile and it's ready to go.

Nicholas: Very cool. And it's possible to do that securely.

Lionello Lunesu: You don't need a new Solidity compiler. Yeah, you don't need a new Solidity compiler or anything which you would need for a new upcode.

Nicholas: Which would make it impossible to upgrade because the contract would be stuck on the older version predating that upcode's introduction.

Ulaş Erdoğan: But the important thing is that you cannot have state for this progressive Solidity code as pre-compiled contracts don't have a state. So the implementation with 7k gas of the ledger has some pre-computations for each k that you have to do. when you initialize the k as a public k that can be made verifications. So it can be worked with the implementation with 200k gas.

Nicholas: That's very interesting. What's that called? Where can we find out more about that?

Ulaş Erdoğan: The Solidity implementation or progressive idea.

Nicholas: Progressive idea. Is there a discussion about that somewhere?

Ulaş Erdoğan: There is an Italian magician's discussion. Let me share the link.

Nicholas: Great, I'll add that to the show notes for anyone who's curious. Okay, I think we did a pretty good job covering 7212. What do you guys think?

Lionello Lunesu: Yeah, it was very good. Thanks for hosting. Great questions and I learned things as well because I have been out of the space for a bit.

Nicholas: Awesome, great. Well, Ulas, Leonello, thank you so much for coming. Thanks to Jerome who had to run a little bit earlier. This was a great conversation.

Ulaş Erdoğan: Thanks for hosting us.

Nicholas: Of course, all right. See you soon, bye bye. Thanks everyone for listening. See you next week. Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter, at Nicholas, with four leading ins. 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.