ZK in a Nutshell and the Gem of Pectra (Combined Recording)

Transcript

Stephen, shall we start or when you give me the okay, I will present Franco in Spanish. Come on. English.

Wonderful. Okay.

Blockchain engineer and real world assets. In a [Applause] nutshell, Hola. Well, I'm gonna give the presentation in English. Okay. Um, and I'll take it slow so that everybody can understand. Cool. Okay. So, as one man said, I'm a cryptography enthus. So, I've been studying cryptography for

about two years now. And one of the topics that I find very interesting is ZK proofs, right? And I feel like most people don't even know what they are. So, today's talk is for you to let's see if this works. Yeah. is for you to perhaps leave with an intuition of what this is about and perhaps know some of the tools and important use cases that ZK proofs proofs can be applied to. Okay, great. So, let's go. Great. So, let's start by dividing ZK proofs into two parts. So, we have the zero part and then the knowledge proof, right? So, let's first talk about knowledge proofs. What is a proof of knowledge?

Okay, a proof of knowledge is essentially a mechanism by which I can convince somebody that I know some information or some statement about that information. Right? A very simple example is a password and let's not think about all the hashing that goes uh that happens in the background and the salting. Let's just think about the password. When I want to prove that I know a password, the easiest way to do that is to just provide the password, right? I just tell you a password and you compare with a database maybe and then you know I I know the password so I can prove my identity sort of right it's kind of a very simple example but you know let's start slow and maybe we can take it up a

notch have you guys seen this structure do you know what it is it's a Merkel tree right a Merkel tree is used in in blockchain systems to try and you know compress and consolidate transactions in a talk and what we have here just as a short refresher let's see if this works we have a set of data here and what we do is we hash the data and then we take it in pairs hash well concatenate them together and then hash again and we do this repeatedly until we reach a root what this allows us to do is it's kind of a fingerprint of the data right if we change any of these leaves here then the root will completely change.

Okay. So let's say I want to convince you that I know some element of this original data set. What can I do? Of course, I could provide all of these points of data to to a verifier, right? And they could do the entire process and go go uh get to the root and they would be able to compare roots and verify that the data is correct. But what we can do is do this. Instead of providing all of the original data, we can provide this partial u well this hashes along the path to the root. And with this we can you know concatenate calculate the hash concatenate calculate

the hash and get to the root. So it's a different way to prove that I know this point here. Right? Okay. So, uh, this could work. But I ask you, is this zero knowledge? What do you think? Is it? Raise your hands if if it is. You don't think so? Yeah, you're correct. So, yeah, it's not zero knowledge. And in particular, we have to reveal this point here, right? We have to give that to a verifier so that they can build the the entire path leading to the root.

Correct. Okay. So it seems like we always need to provide some information at least a minimal amount but we need to do so. So I guess the question is can we do better? Can we not reveal anything and can we have this be uh sort of a statement like I want to convince you that I know some data that leads to that route but I don't want to give you the data. Can we do that? And here's a a you know a more tangible example. Perhaps I want to prove that I'm I'm older than 21 years to, you know, to go to a bar or something, but I don't want to tell you my age because I don't want you to think that I'm too old, right? So, that that could be another thing that I wanted to

prove. And can we do that? Can we prove this without revealing our age? And the answer is yes, we can do so. And that's the zero knowledge part. Okay. So what we have is the the way to do this is to hide the information behind a very hard problem, a very hard mathematical problem. And this perhaps sounds uh familiar, right? When we do a signature, a digital signature, what we have is a again a problem that is very hard to reverse. So it's kind of a one-way thing. And this is kind of the same thing. We're going to be trying to to provide a a problem that's very hard to verify but very very uh sorry very easy to verify but very very hard to

solve right and this is called well this type of problems are called uh npmplete but I don't want to wor bore you with the details what I want to do is actually to play a game so you guys probably know this right this is the classic where's Waldo game right So, can you find him? Can you find Wo? Well, I know where he is, right? Uh, and I could tell you where he is, and then I would convince you that I know where he is, right? But let's say I want to do this in ZK style. I don't want to tell you where he is, but I want to convince you that I know where he is.

Can we do that? Yes, we can. Here's a a game we can do around that. We can grab a piece of cardboard, a very big one, and punch a hole through it. Since I know where Waldo is, I can place him under the cardboard and exactly on the hole. Okay? And this is what you would be looking at. That's Waldo, right? Did I convince you? I know where he is, right? Did you learn anything from this? No. See if you can find him.

Right? And the moment I tell you where he is, which is around here, you cannot unsee it. It's there. You know, I leaked information. You don't know, right? So, this is the the type of hard games or hard problems that we can hide information behind. The hard problem here is finding Waldo and the fast solution or verification is the process that we did, right? We can turn this into mathematical problems, but we won't do that today. That's just the idea and the intuition behind this. Okay. But you you may ask why why would I do that? I don't want to hide Waldo. I just want to say it's there, right? Well, of course, we have privacy

problems. Waldo is not something that we want to keep private. That's fine. But for example, I I here are some examples of things that may be sensitive and may reveal some information that we don't want to reveal. Just to give you an example, account balances is something that is public on blockchains. Generally speaking, some blockchains have private balances. But the idea is that if we could keep that private in some way, hide it behind something like a hash for example and you know just prove that we have enough funds to perhaps do a transaction. That would be cool. uh we don't really have to expose ourselves and put a target on our backs by saying hey I got lots of money and you know you

get hacked and you get attacked and whatever so yeah some types of information are sensitive so it it's desirable to hide that information behind a hard problem right okay so that's one aspect of zk proofs that we need to to try to you know g gain an intuition about there's another one and it's called interactivity These processes tend to be interactive. Okay. And this means that there there's some back and forth between a prover and a verifier. The prover being the one that wants to convince a verifier about some statement. So again, let's play a game. Uh you guys know the Rubik's cube, right? So what can we do? Let's say I

want to prove to you that I know how to solve a cube. Pretty easy, right? So a verifier would scramble that, give it to me, and I would take it, solve it, and give it back. Okay? But okay, the verifier could say, "hm, this guy perhaps he has good memory. Perhaps he memorized the steps. Perhaps that's the way he figured out how to solve the p the puzzle, right? So maybe what he does is okay he takes back the cube he turns around he scramles it gives it back and now I cannot know how to solve that from memory correct so I take it and let's say for good measure I also turn around I solve it I give it back to you solved

ahuh you say this guy now I have more confidence that he knows right but for good measure he does the same process again he turns around scrambles it gives gives it back, solves it. Good. Okay. After three times, I can say yes, this guy knows how to solve the cube. Did I learn anything about how to solve the cube? No, not really. Exactly. So, this back and forth increases the likelihood of the provering a statement or a solution or whatever information each time we do the process. And this is something that's uh natural of this type of of process. And also think about this. If

the prover solves the cube partially and gives it to me, I will say no, you don't know how to solve the queue. Correct? So these two properties are very important. And actually after seeing that we can now give a more formal definition. Okay. We have that a proof of knowledge is an interaction between a prover and a verifier in which a prover convinces a verifier that some statement is true. The statement is I know how to solve the cube. The statement is I am over 21. The statement is I know where Waldo is correct. And it has two properties completeness and soundness. And actually we know what it is because we we gave an

example. Now that's the Rubik's cube example that actually has those properties. Completeness means that if the statement is true, if I know how to solve the cube, I will always be able to convince you that I know how to solve a cube. That property is important because it means that the proof will always work if I'm being honest. And soundness is the other property we mentioned over the end which is if I don't know how to solve the cube then I will solve it partially for you and you will not be convinced that I know how to solve it. Okay. Of course these properties are more rigorous and we need to define them in mathematical terms but we won't do that today because it it's it would take lots of time.

So cool. But where's zero knowledge in this? We didn't say anything about zero knowledge. So zero knowledge is an extra property. Essentially we say if we don't reveal any extra information other than this is true then that's zero knowledge. This also has a more formal definition but we won't go there today. We can talk about that later if you want. Uh but it's pretty pretty involved. Okay. So those are some of the basic ideas behind zero knowledge proofs and we with this we can gain some intuition on how they work. But now I want to tell tell you about some of the examples uh of zero knowledge proof zero knowledge proofs that we actually can

use and exist. Okay. And this started with the first wave as I say here of protocols of games cryptographical games that involve some particular statements some particular facts that we want to be uh we want to prove are true. For instance, uh the Schnore protocol was one of the first ones that emerged and it proves knowledge of what's called a discrete logarithm. We don't need to care about that now, but it's, you know, it's a very particular thing. Uh all of these also are very particular. For instance, range proofs allow us to prove that a number lies in some range between zero and another number. And well these other ones you can check the links later

but yeah it's it's also they're also very particular things right and do do you believe that this is a problem the fact that we have very particular things or or proving systems for particular problems. What do you think? Yes. Why? Well, yeah, that's true. If one breaks, then we don't have many more things to do. That's right. But there's also the fact that this is inefficient in terms of implementation. Let's say none of these problems really solve the let's say the where's Wilder

problem, right? So, if I wanted to create a proof system, a proving system for that, I would need to go to a cryptographer and say, "Hey, I want to prove this. build something for me, right? And that's inefficient because we have to build that, we have to test that, we have to audit that, we have to battle test it and that's that's not very efficient. So yeah, this is a problem. Uh the first wave of zero knowledge proof were just very particular things. The question is can we do better? And yes, we can. there's a a new wave of more modern uh zk proofs that basically separates the problem in two.

We have a programmable part where we uh can define our statement can define one what we want to prove and then we have another part which is like a framework or sort of a compiler let's say yeah we have a way to define our problem and then this compiler thing takes our problem and generates a proof. So by doing that we have flexibility. We can create any any amount of proofs that we want right and there are two types of of uh proving systems that exist and you may have heard of this. These are CK snarks and CK Starks. Snarks are proofs that are very very small in size, very

fast to verify. You may have heard them in the context of perhaps ZK rollups. Uh so yeah they're pretty cool and we won't dive too in that. I just want you to you know uh remember the name. Then you have ZK Starks which are quite different. They use this idea of what's called a state transition function and they're used generally speaking to prove that we can get to a state from an initial state by following some uh you know rules of state transition. But we don't want to reveal all the intermediate states because that that would perhaps be too heavy to you know to parse to use. So yeah these are the two big names today and again they separate the problem into

a part where we program the zik proof and sort of a compiler that takes that and generates a proof. Okay. And then there's the other thing. How do we represent these statements, these things that we want to prove? There are ways to do this, but one of the most common is talking about circuits. Circuits are this sort of uh you know, you you know circuits, right? We we use them in computers or computers have them, right? But these are sort of uh circuits on steroids, we could say.

Instead of using ones and zeros, they use many more numbers. And with that we can start doing some arithmetic and with arithmetic and maths we can represent problems. Again we won't get into the the finer details of this but I just want you to remember we can build statements out of this seemingly simple constructions. Okay. Okay. So what now? What we have here is a list of concepts and ideas that we need to dive into to really understand how this works. And I just wanted to create this slide for you to really see that this is a very deep topic. We don't really need

to get into the the math behind this and study a lot of things. Um you know we have miracle trees here. We have hashing. This may ring a bell. Uh perhaps polomials ring a bell. uh we just talked about arithmetic circuits but like what the hell are p pairings? What the hell is a root of unity? It's it's you know things. Um and in particular one thing that I want to talk about is when we produce a signature a digital signature we tend to expect uh you know we produce a signature and send it to a verifier and they just verify verify it and that's that's that right but in the proving systems that we

saw we have this back and forth and that's not very efficient as well. So could we turn that into a non-interactive thing where I just build a proof send it they verify it and that's the end of it and we can because there's this fiat shamir heristic thing again let we won't really talk about that but I just want you to know that we can so we have lots of primitives here that in conjunction can allow us to build this zero knowledge proofs right okay so now I just want to you know mention that there There are lots of tools nowadays for us to build uh zero knowledge proofs. Uh some of them like circum and noir are uh DSLs. Uh so

DSL is uh well it's a it's a domain specific language, right? And what this means is that this is kind of like a programming language that we can write and it looks something like this. That's similar to Rust if anybody has used Rust. And yeah, it actually I mean it it really looks like we're programming something, right? We are building our system ourselves and we don't really care what happens in the background. That's done for us. Uh these are just some names for you to remember and maybe uh after the talk you can investigate yourselves. Again, this is just to give a general idea. Uh and there are more of course I don't want anybody to think that this is all

that there is, right? And to finish things off, I just want to give you a couple examples of things where or situations where we would want to apply ZK proofs. Um, this is again just for you to have an idea of how to use them. There are many more applications. So let's start first. I already talked about private balances on chain. So blockchains again generally speaking are these public uh environments. So if I have a balance, it's it's public, right? So it would be nice if I could hide that, but still I could, you know, make transactions with that. So let's say I encrypt a balance.

Now, everybody that looks at my balance doesn't really understand what that means. So how does a blockchain know that I can do a transaction if that's hidden? Well, you can build a ZK proof, right? What you do is essentially you prove that you have enough balance and also a couple more things like you're encrypting correctly to the send to the receiver that you know the value that you're sending. But essentially the most important part is this one. You prove that you have enough balance and that's it. Right? Uh this usually comes coupled with something that's called homorphic encryption but again that's you know anecdotic. Um so yeah that's one

application. Second, Zikke roll-ups. We were just talking about that, right? ZK roll-ups are this uh you know layer 2 blockchains that essentially they bundle transactions. Yeah. So they receive lots of transactions in a sequencer what's called a sequencer and they build this bundle in a zk proof uh manner and what they do is hey they they tell the layer one hey you have this state initial state this final state and this bunch of transactions that I don't really want to tell you about because that would take lots of time for you know validating that the state is correctly calculated but I want to convince you that it's correctly calculated so you just take that and you say okay that's good this

this is a new state. So what we do is we build a ziki proof again. Uh and yeah what we prove is that the pre the next state is correct that the transactions are all valid that there are no funky things and after we do that the layer one is going to say yeah okay that's good this is a new state end of story. So yeah, ZK proofs are useful. And then uh last but not least, verifiable credentials and identity, which would be similar to the example of us being over 21. We want to prove uh things about our identity, but perhaps we don't want to reveal much of our identity. For example, let's say I want to access some credit, but I don't want

to tell you how much uh I earn per month. So, okay, I build a ziki proof and I say, "Hey, I know I have this salary that I don't want to share, but I'll convince you that's enough for you to give me a credit." Cool. End of the story. I produce a proof, the verifier believes me, and they give me a credit. That's all. So, yeah, these are some examples of things we can do with ZK proofs. Of course, this is not the end of the story. We can build many more statements, but yeah, just to give you an idea. And then just to summarize things, we saw essentially what a ZK proof is, which is a system where two parties interact and they well a prover convinces a verifier about some

statement. They do this by not leaking information by hand hiding things behind a hard problem, right? And then this uses lots of funky maths that we won't talk about today. But yeah by that by hiding things behind this hard problem we can convince people about those statements. Uh and yeah we have lots of tools nowadays. Uh this these are not that new. You can check that yourselves after the talk. Yeah the system is really flourishing. There are lots of things that you can do lots of new things that are coming out all the time.

And yeah see technology is not something that's you know just uh some stuff that's there and nobody cares about. It's a reality. It's really being used in production. It's being used in systems and you should be aware of that and you should try to start understanding what it's all about. Of course, there's much more to to dive into and I just want to, you know, give you a rough idea of what this is so you can leave and then continue studying yourself. Uh it's I can say that it's it's kind of hard but, you know, it's fun. So, yeah, I invite you to keep looking at this technology. That's pretty cool. And yeah, that's the end of the presentation. That's me. Uh, this is my LinkedIn, I think. And then you have

my socials here. I also write on Medium, so you can follow me if you want. Yeah, that's that's it. [Applause] question. Um, what is your favorite what what is your favorite DSL for the for CK? Mine I I I've used a bit of Noir and a bit of Circum, but I think I feel like circum is way too convoluted. Yeah. Yeah. circum has the

property that or the characteristic maybe you need to really understand what you're doing when you build a circuit. I I didn't bring any examples but you need to understand the math and the constraints you're working with. Noir is more of a you know friendlier thing for users or developers right um so yeah I think I need to dive more into cir uh noir I've been using circum so far but I think no is a better choice if you are a newcomer and perhaps if you want to use circum you need to start study a bit more yeah any other question okay maybe the reason that CK exist is for privacy as one of the main factors,

right? But how to make people realize they need privacy as long as many don't care and they should. Yeah, that that's a good question. Uh I feel like that's more of a communication thing. Uh we need to be able to transmit that, you know, we need to take care of some of our of our users data and I know that users are not really aware of that. So it's our responsibility as developers to try and incorporate this into our systems and then communicate correctly. But first we need to build correctly as well.

Franco, software engineer. contract. Speech. Speech.

[Music] Much in English. Let's see.

Fore technos. Anybody else? See, okay. So, hopefully you'll be able to understand me. if you don't just tell

me to slow down. Um but yeah, so let's try to start. Um so this talk is called the gem of spectra because of Ethereum's new update. Um but I want you to be able to uh infer when we finish this talk why it's called the gem of PCRA. Right? So let's just uh go over the agenda for today. Um I wanted to start talking a little bit about account obstruction and um how we usually implement it nowadays.

So there are lots of proposals um to to take care of the problems of account obstruction. Um but yeah we're we're going to go through a few of those a few of the existing ones and then we're going to try to build a new one. Right? So build a new solution for um account abstraction. Then we're going to try to iron out the details of the new solution that we built and finally just go over what we think the future may hold for um this issue. Right? So let's just move on and start strong here. So we know that externally owned accounts um are the way

for end users to interact with uh blockchain right and the EVM compatible networks. So um let's just put an an example forward so that we try to uh so that we understand a little bit about the process right so a new user like Alice comes to the web web3 ecosystem and um she goes to a wallet provider of her choice and asks the wallet provider to give her a new wallet. Right? So the wallet is going to be represented as a public key and a private key that we can see right here. Um and behind the scenes the structure of Alias's um externally

owned account. Um which is basically the idea of the wallet being represented on chain. So this externally owned account you can think of as what we call wallets. Uh it's going to look something like this, right? So it's going to have a nons, a balance, a code hash. Just forget about the hash part. It's just where we store the code and also the storage route that again you can forget about the root. It's basically where we store all the data for these accounts. So one thing that we need to know about is that all of Ethereum's accounts look like this including smart contract accounts. So the main differentiator between uh externally owned accounts and

smart contract accounts are that smart uh that externally owned accounts don't have any code associated to it and no storage right um so now that we know a little bit about how uh externally owned accounts look let's just try to um understand what account obstruction is. So it's basically the this idea of just abstracting ourselves away from the limitations that externally owned accounts have. So we know that externally owned accounts um can trigger transactions, right? It's the way for us to just start transacting transacting and basically just playing around with um the Ethereum blockchain. But there

are lots of limitations that come with it. So these are a few of the examples that I could come up with but I'm sure that you can come up with a few more yourself. Um so basically one of the things that I'm want to mention here is that we can only send one instruction one transaction at a time right so there's no transaction batching. We would like to uh sort of have an a way for us to send more instructions in one single transaction. We can see this in the um if you've ever worked with ERC20 tokens then um we know that sometimes if we need to use a few tokens from an externally owned account we need to um ask the owner of the externally owned

account to signed uh to sign I'm sorry the um the approval of the usage of those tokens and then just move on to the transfer of of the tokens. Um then another example here is the uh requirement of funds. Uh so externally owned accounts cannot interact with the blockchain if we don't have funds, right? Um it's sort of uh embedded in the nature of the blockchain, right? Um and that creates a lot of friction for onboarding on boarding new users. And it's something that it's quite interesting to see that it's a problem that we have had since the very beginning, right? Um so we would want to

fix that. We would want a way to work around that. And um yeah, the other two examples are sort of uh niche, but I still want to mention them. Um Juan Manuel uh gave a talk a few days back about uh and he mentioned something about account recovery um where we cannot if we lose our private key or our seed phrase we cannot access any of the funds any of the identity that we got from the externally on account. So uh we would want to also have a protocol or a way to fix that to to basically just recover the the account that we lost.

And uh finally just if you think of multi-ix we would want a way to have that be a native native feature right we would want uh externally owned accounts to be able to have more complex processes or schemes uh for signatures. So basically the idea is that they're not flexible enough. We want to make them more flexible. Um so the idea here is that we basically want to have bo the best of both worlds. We want to have the good things about the EOAS which is they can trigger transactions but uh we also want to add the things that it's missing right. So we want as it says here the best of both both worlds. Um so how do we usually go

about this? How do we handle account obstruction today? Well, there are lots of uh different uh attempts at solving this. Some of them go uh just for a few of the features that we just mentioned, which is in this case with meta transactions and sponsoring. We have all of these EIPs and I'm sure there are lots more um that try to solve the idea of sponsoring transactions, right? Not having to pay for uh transactions. the the problem that we mentioned when we uh mentioned that we don't want to have funds to interact and to play around with the uh blockchain. So the idea here for all of these EIPs is that we try to

assign a piece of data cryp cryptographically of course and then h have someone else that has funds send it to to uh the network. So this is just one way that we can solve sponsoring. But what if we wanted to go over maybe um a bit more of a broader solution to uh account obstruction? Well, we can think of EIP4337, which as you can see, I'm not going going to um just go over how it works, but as you can see, it's a pretty complex protocol, and I want to thank Alchemy for the illustration. Um but it's very complex. It has lots of entities and lots of contracts that need

to be deployed. So we will want to make this simpler, right? And if we were thinking about making it simpler, we could also look at uh EIP374 um which basically says, okay, just let's try to make the smart contract accounts take over an externally owned account. So just basically just have uh the code from a smart contract take over everything that we have on um on externally on accounts the balance the nons everything that we uh just went through. So what I want you to take away from this is that EIP 4337 one of the main implementations of uh against account obstruction uh or

against the account obstruction problems is way too complex. and the other ones that we know of are too broad, right? Like they may have lots of problems down the line. Um so let's try to find an alternative. Um what if we wanted to uh find a new solution? Let's try to work on this together. And uh we know that the main objective here is to maybe transform in some way an our externally owned account into a smart account, right? So a smart account would be the concept here of an account that can handle both the best of both worlds. Um so can we use what we saw on the

previous EIPs? Yes, of course. The idea here is to learn from our mistakes and from the good things that work and one of the things that works is um smart contracts. So smart contracts have the programmability that we're looking for. Um, so we know we're somehow going to have to associate our externally owned account to a smart contract. But how do we do this, right? So let's just go over another resource we have at our disposal, which is the um transaction envelope PIP, right? So this transaction envelope um has well yeah there there is the the envelope uh basically says that we can introduce new types of

transactions into the Ethereum ecosystem. Uh so it's been great. We have used it a lot. We currently have uh four different types of transactions starting from zero to number three. So if we wanted to let the blockchain know that we want to assign or associate code to our externally owned account, we could just use this, right? So let's just build a new transaction that for just clarity sake, let's just call it set code transaction because we want to set code on our externally owned account. And um we now know how to let the blockchain know what it is that um we want to do, but we don't know how to

do it yet. But let's think about what we need to do it, not how we want to do it. So um what do we need in order to to authorize uh this setting of code on our externally owned account? Well, as we said, we know that we're going to need a smart contract. So, we're probably going to want the address of the smart contract that we're going to relate to. And um we another thing that we want another feature that we want is not requiring funds, right? So, we want any externally owned account either uh if it's one that has funds or not. We want it to be able to set it um even if they don't have any. So, that's another requirement. And then the last one is

that we want only the externally owned accounts owner to be able to uh set code and uh sort of make the transformation. Right? So we can we can already smell like uh it sort of looks like we could implement it something like this. Just having the idea of an authorization be an address and a signature that guarantees the s the cryptographic signature uh guarantees that only the externally owned account owner can sign it and then uh that we don't require funds because we know that metransactions already handle um the signature of uh a piece of data and then send it by someone else. So basically

this could look pretty good. Um, but what if we wanted to set code in multiple chains? Well, this is where we're getting way closer now. Um, so the thing we could do is just add the chain ID parameter to the signature. And that would be basically it, right? So instead of having um the authorization just be the signature, the address and the signature, we could do it um with having the chain ID to know to which uh chain we want to uh associate the address with and then of course the nons basically just for replay protection. Um but this is the idea of just having multiple

authorizations be linked to the uh envelope transaction uh in an authorization list. So you would have basically multiple uh signed uh pieces of these code and uh then just add it to a list in the transaction that you want to send. So um what happens here is that we haven't discussed how that would be done, right? So we know that we send a new transaction and uh we know what data it needs but we haven't gone over um how we're going to associate an externally on account to the smart contract. So one thing that I do want to mention here is that uh like we said in the beginning

externally on accounts cannot trigger transactions if they are association associated directly to code. So that would make them smarter contract accounts and it's basically defined by this EIP that you can all go read. But basically that's the difference. If you have code on your account, it's basically a smart account uh smart contract account and you cannot trigger transactions. So we need to work around this. Um and the way we can do that is just by saying okay let's just flag the code that we want to um associate to our account. We will we're going to still be um storing set code in our externally own account and the code hash but we

want to flag it in some way that um when we send it to the actual client nodes they know that they're seeing some delegation and not necessarily a piece of code that actually says okay this is a smart contract. Um, so it's going I don't want to go too deep into this, but there's an EIP um that specifies or says that um it it's not possible to deploy smart contracts that start with this prefix, right? So there's no smart contracts on chain and ever that can start with EF, right? So we can use that to say, okay, this is a delegation. This is a special kind of code. And then just for um future proofing we are going to

use the number of the transaction the set the co the code to identify in in case we want to use this kind of structure in the future right um so it the the result would look something like this right a delegation designator which is basically just saying okay this is a pointer to a smart contract and it's identified by the prefix of ef the number four uh transaction in binary And then the the following byes are just the smart contract account. So um just to recap uh a new user comes and asks the wallet provider to give him a private key and an address which uh

grants them access to an externally owned account. Uh they sign uh an authorization that sort of looks like this. They just send it to a relayer, a bundler, whatever you want to call it. And uh that bundler has some gas to send the transaction on chain and the node is going to associate um the address to the code of the smart contract that we're pointing to. Um so basically that's it. We have just set code on our soundly on account. Well, kind of. So, there are lots of things that we need to talk about and and a lot of details that are important here, but I just want to mention a few that I think um provide a

good uh idea of what's going on. So, the thing that we just did is basically what is specified in the EIP702 that is coming in the Pectra upgrade of uh Ethereum. And uh yeah, let's just try to understand a few some use cases to to uh maybe yeah, go over and see if we can learn something else. Uh so what if we for some reason I wanted to set my uh set code on my externally owned account. Um but I signed two different uh authorizations, right? So this one here and this one here. You can see chain ID is the same one. Address is different, but the nons is the same. And let's say that the signature are uh both both

signatures are valid, right? Um so in this case, the IP specifies that just for simplicity sake. Uh we're just going to always pick the first one, right? So in if you ever find this that you have to deal with something like this, then you just know that the EIP specifies that you only need to grab the first one. Um then a second scenario that I that I think it's uh confusing at times if you review the uh EIP is that um we know that smart accounts or smart contracts um handle storage in their own way, right? Um but now we're sending code and sort of trans uh transforming our externally owned account into a smart

account. Um so where does the state or the data live now? Well, basically it's just simple. It's what what you would imagine, but um I needed some confirmation when I read this. So, uh I went deep and uh I discovered that it's actually just as simple uh as that since we discussed that all accounts in Ethereum look like this. um then what the EIP specifies is that we're just going to start using the storage from the externally owned account and um it's not going to live somewhere else. It's so it's just like proxies, right? Uh if you've ever dealt with uh upgradability and proxies, then it's just the same

thing. Um so now let's just say I just sent the set code transaction, but the account storage is not initialized. Well, this is kind of important important. We don't use init code. So, uh by not using init code, by not passing a piece of code that we run um when we set the code into our uh externally owned account, then that basically means we don't have an initialization of storage. Um which it was done just to save gas. So that means that just as we do with proxies, we need to um call an initialization method. So this is just another thing to to keep in

mind. And of course we when we implement this we need to take care of um fronting and replay attacks. Um and just the two last scenarios before we uh wrap up with this talk. Um, what if I regret having transformed my externally owned account into a smart account? Um, what if I just wanted to go back or what if I wanted to update it, upgrade uh the contract that we're pointing to? Well, that's easy. We can do both things. Uh so um in order to revert your smart account into an externally owned account, you just pass the address zero as the address you're pointing to in the authorization that we

saw earlier. And that basically just turns it all back. Um the one thing that you need to take care of and to be careful about is um that by setting this address to zero does not clear the account storage. So if you ever go back to a smart account, you may find some um storage clashing. Um but yeah, and if you wanted to uh just update it, it's the same thing. Instead of passing the address zero, you just sign the new authorization with the uh smart contract address that uh you wanted to update to.

And finally, one thing that I find that almost is is almost never mentioned, but I think it's quite important is that how do we handle the nons when we do this. So, if you don't know, externally owned accounts uh increase the nons of the account by one every time they send a new transaction. And smart contracts uh yeah, smart contract accounts increase the nons by every creation of a new contract that they trigger. So how do we handle this? Well, we handle it just by having both work at the same time. So what that would mean is that um now for every transaction that we send, we may be um increasing the nons of the account

by more than one. So this could break there are some use cases where uh could break some implementations. Uh so it's something that I thought was worth u mentioning. So just to wrap up, what now? Well, uh this uh EIP, which is what we went through, uh is part of the latest Spectra update of Ethereum. And I'm sure you can all think of why uh I named the talk the gem of Spectra. Well, basically because I think it's the most important EAP of the whole update. Um, so, uh, yeah, it's scheduled to release May 7th on mainet. So, notes are actually currently being updated and

preparing for May 7th. So, that's it. Just get ready to use uh, smart accounts. Uh, yeah, that's me and that's I think that's my LinkedIn as well. So, yeah, thank you so much. [Applause] Hey, hello. Yeah. Uh, so essentially this means that for just that every person that wants to use the new smart contracts after Perra has to migrate to uh to one of the new to this to a new wallet to the wallet that has the smart ability. Therefore, there won't be something like a like

uh upgrade in the background for the existing accounts that people already have. Um I'm not sure I understood the question, but let me just say this. Uh you can starting May 7th, just choose whether you want to turn your account into a smart contract account or actually a smart account or a um or just keep it an externally owned account. You don't need to change it if you don't want to. And any existing externally owned account can change can um have this done. So they can always transform into a smart account. Um the only thing that you need is just

actually to have a smart contract you can delegate to. So that's the hard part of the adoption. You also want uh wallet providers to make it easy for you. But if you know how to code and then you know how to send a new transaction and let's say your wallet provider does not have this ability yet then you can just do it by yourself. Um so be careful if you do it by yourself. There are lots of uh security issues with this if you are not careful enough but um yeah you can basically do it to any uh account you want. Yeah. But but in that but in that case, let's say I I have a I migrate to a smart account. I have an EOA. Yeah.

And I want to send and I want to give another person my address. With which address will that person require in order to deposit into my smart account into my smart account? Will they use the contracts address or they use my address? So do have you ever worked with uh proxies? Yes. So basically you would just give the address that holds the the storage, right? So in this case it would be the externally own accounts address because you're delegating. So the delegation is just what happens with proxies, right? So you just use the code but in the context of your externally owned account. So you if you wanted someone else to start interacting with

your uh new smart account uh you would just use or give them the externally on account address which is now a smart account. Okay. So everybody so if I migrate then I going to have a new then I'm going to have to be using a new address. No not necessarily. So the the idea here is that um uh why I want to get well basically this so this I'm I'm sorry uh uh am I going forward or backwards?

There we go. So this um this code hash is the one that we saw. Um I don't have I don't know why I don't have one closer but uh so it's it's this code hash. So if your certainly own account looks like this then you here when you haven't before you transform it then this would just store like the hash of code zero empty uh string but once you transform it what you're going to have is this and that's enough to use your externally own account you don't need a new account you

don't know you don't need anything else you just keep your same address same everything and this is going to be what's stored in your code hash. So now that tells everything else. So whenever send someone sends a new transaction to your address uh they're going to be executing the code of this address but you keep the same address. Oh okay. That's what I was asking. So it will technically be transparent if I just move to to the new version. Yeah. Yeah. Great. 100%. Yeah.

Hey, great talk. Uh, so my question is around the multiplicity of of uh authorizations, right? Yeah. So you mentioned that you will always use the first uh authorization that matches um you know the signature for for a user. So I was wondering what's like what's the purpose of having multiple authorizations because here you you you have chain ID one chain ID 2 but my understanding is that you will always be on a on a single chain when you transact and and have an authorization. Uh so yeah why we want to to have more authorizations there. Yeah. So um I skipped that in the talk because I

didn't want it to take too long but it's a good thing. Thanks for asking. Uh I love that. So um a few days ago uh on Juan Manuel Juan Manuel's talk uh someone asked what happens if we uh have multiple chains, right? So we know that our externally owned accounts live in every uh EVM compatible chain. So um we basically want this well not this not repetition but uh chain ID 1 2 and three because we want um to make it as easy as possible to transform all of our accounts into a smart account. So um so

whenever you connect to uh Ethereum and then to Polygon you would want to keep the idea of uh a smart account. So let's say chain ID 1 is Ethereum and chain ID 2 is uh Polygon. You would want to sign both of these so that um when you go use your externally owned account as a smart account on either chain um then they would be both set up. So, of course, the bundler or the relayer or whoever sends the transaction would have to send the transaction um on each of the the chains. But of course, it's just the same transaction. I'm sorry, the same

transaction and uh they would just copy paste it and send it on each chain. So, that's the reason why. Yeah. Great. Thank you. Great. Okay, let's give it another applause to Gonzalo. Thanks, E blockchain.

[Applause] Blockchain crypto [Music]

Um blockchain Summit International. Blockchain cryptos.

So in Panama says Eric Vorhees Shape shift. No.

technolog Crypto blockchain. forryto. One

coin. One coin. Bitcoin. for coin. One coin. Bitcoin. I'm one

coin backgrounds. Okay. One coin. Bitcoin. Scientific line. Bitcoin

[Music] Bitcoin. Bitcoin. Andreas, Master Bitcoin, introductory.

And it's a moment. Bitcoin. Bitcoin. meetups. Yes,

meetups. forto coffee. Roberto [Music]

blockchain blockchain. Foreom spech.

[Music] Central. Foreign blockchain blockchain space.

Transparenc. Transparencitor principle. Mastering Bitcoin. Mastering Bitcoin

Bitcoin Bitcoin. Mastering Etheum. America's blockchain summit. [Music]

Crypto blockchain. Global competences exchanges.

Global crypto. fortosign.

Fore specific. Fore hackathons, Microsoft hackathon. informal idea.

Standard International forstrument.

Check says It's a background. the blockchain

space. foridentific. foridentific. local. Tower bank.

Crypto Bitcoin Etheum. significanc.

Staking the mining. for particip

the ecosystem etc. Blockchain space.

[Music] Pacific. Crypto friendly.

friendly. International Oh, ENF public goods.

[Music] Pacific is no coiners.

International. Fore techno particip.

Cryptos blockchain Web blockchain web three. Gracias.

[Applause] network.

Universch. foress. Trading multi etc.

[Music] Studio Pacific. [Music]

Proinces. Yeah.

Hey. Oh yeah. That's it. Okay. No.

forgular. forificance. They have Nochech.

Fore conversation. feedback. for

international. forch. Regulator.

Thank you, Rodrigo. Uh, thank you everyone for bearing with us for an amazing week so far. [Music] um our friends from Space Dev, Gonzalo, Franco Manuel from UTP. Um I think we've had an amazing week of learning, collaboration, inspiration, some walking through our past and how we got here. Um couple of uh housekeeping things.

There's a DJ out there. We have still lots of uh kindness from Heineken. Um there is uh an event tonight over at the convention center. There's a bit of a party. Um I think everyone's invited to go. There's also a Binance VIP event at uh Ahazar, which is a great venue at the U. And uh I think there's a party tomorrow night at uh Embassy which is nearby uh at uh it's an offchain social event and tomorrow we have a half a day of hackathon finals and we'll have uh I think one or two talks. Um I want to

thank everyone for participating in ETH canal. I think this is a uh as Rodrigo highlighted for us a transition and we got here because of all the the things that have been happening and you know you guys have been super great supporters. Um you know I think collaboration between uh us small countries is something that we need to continue and uh continue in a big in a big way. Um thanks you guys. Uh thank you L mansana Edwards. Thank you for all the support. Uh we have one more day and our hope is that we uh can make La Mansana and Kasco VJO u a logical place for expats and locals to build from. I think it's a great neighborhood. I I love the

um kind of like open campus feel and uh thank you uh everyone