Meetup #19 - Intents - Marcello Bardus

Transcript

for myself. Thank you. So, we're good to start, I guess. So, maybe I'll quickly introduce myself and like say a few words about the talk today. So, okay. Yeah, everything is good. So my name I get some water maybe before we start with this.

So I'm actually like a bit confused. Should I like look at the camera and like treat or like look at whatever >> I can do one slide walking around and a bit seated. So I'm Archalum, founder of Herodotus. We are like um infra company. We do ZK stuff and um ZK stuff more precisely what we do is like co-processor that runs on top of storage proofs and it's not going to be the topic of today. The topic of today will be intense that do leverage the technology that we that we built and um I feel like today it will be really really high level. I want to introduce

what intents are, how we went from transactions like how you know users started interacting with Ethereum, what were the attempts to like improve it, what are the problems of like using Ethereum um and uh how this stuff works, what's the stage of it today and kind of give you like an overview and if we have enough willingness we will like get into like some technicalities. But again the purpose of like this um this meeting workshop is more to like establish some context and uh give you like an idea of what intents are what problems they solve and basically there

are more um and the name of the talk is from transactions to intents um oh I think I don't have intense here so imagine that we have intents here um what not how so we'll So you understand this this title a little bit better. So now let me move on to the agenda. We even have an agenda for today. No. Okay. Oh, amazing. So it's a very high level agenda. Not sure if I'm going to precisely follow that. My plan is to pretty like freestyle the the the meeting quite a lot. Um but the plan is as follows. give

you some overview of what a transaction is, why it looks like, how it looks like, what it really represents, how we deal with transactions nowadays. Then I will kind of walk you through the different attempts in history of how people tried to solve it in Ethereum. Why it why some attempts work, why some didn't work, how they evolved, what seems to be the consensus today. And then I will talk about how messed up Ethereum is getting with having multiple rollups, doing everything crosschain, and why seems like the intents are the only solution.

And so they are the future. And of course I have to do the sponsored part and tell you about storage proofs but I promise to keep it very high level. Um awesome. So what is a transaction first off? So Ethereum is a state machine, right? Like it's a blockchain network with an underlying database. There is a state transition function called EVM and you interact with it somehow and we call those interactions like transactions.

The EVM has is capable of like doing a lot of stuff because first of complete we can save things. We can delete things from it. It's persistent. So you know those actions that we do with that system have to be like very expressible and very like generalized. Um and those objects are transactions and we have to ensure that you know they pay the fees because if we don't pay the fees the validators don't have incentives around the network and so on. There's a lot of like technical nuances that uh have a very good reason to be there but it makes the UX bad. Uh I guess many of you probably all of you use MetaMask and keep using MetaMask. uh you not sure how long you've been using that but if you

use that let's say before EAP1559 you probably find yourself in a situation where you wanted to destroy your computer because when submitting the transaction nothing was really working you had like spikes in the gas price uh the transaction was failing and stuff like that and the reason we pay fees again I said we need to keep the incentives in the network so everything sort of makes sense but the UX is absolutely terrible Um, and there are like many many many attempts to fix all of those problems in uh in Ethereum EIP1559. Maybe it's a uh I shouldn't mention because it's just going to add some confusion but nevertheless uh I I

will cover that when I will talk about metat transactions and one of the first attempts to sort of solve those problems. Yeah. Okay. But maybe first thing first, let me set up some context what a transaction really is. So like I said, it's an object that a user signs with his private key. Um a user on identified by its address that is derived by from the public key and the transaction basically includes who is sending the transaction to. So if it's a simple transfer of fund, the recipient is the recipient of the funds. If you're interacting with a smart contract, let's say ERC20, then the recipient is the smart contract itself, we need to encode

what we actually want to achieve and this is the transaction data which is basically arbitrary. Um, and wallets thankfully handle that. Hello. Um, then we have information about gas. So how much compute resources we expect this transaction to consume. Um I also talk about why this is a bad abstraction for for that and how intense can potentially tackle some future problems. Uh we have nonsis uh nonsis is in order to avoid replication. So let me give you an example why nons are relevant and why they're extremely relevant also in intense and everyone who's dealing with

intents has to like think about those um replay protection. So if you send a transaction that says I want to send 20 if if Bob signs a transaction that says I'm sending 20 if to Alice, he can submit it to the network. Alise will receive the funds but Alice can pick up the same signature submit it again and we have a double spend. We made a transaction twice. But if Bob is going to sign each transaction, you know, like a counter that keeps increasing with every transaction he does, only a valid signature will authenticate the move of funds. So no one without his private key will be able to do that. So that's why we need answers. The same applies to

intense, but we'll get there. Um, okay, let's let's move on. So how do we send transactions? Wait, let me move on a little bit. Okay, so how do we send transactions? first of all like most users do. Uh we have wallets that abstract a lot of things away. Um so they handle AI encoding. AI encoding what that is. So like I mentioned before we do have smart contracts. They're touring complete. They can do a bunch of stuff. Um and because they can do a bunch of stuff it's very like generalized you know. So uh when a user says I want to transfer funds it doesn't say I want to transfer funds. In reality under the hood it's an API encoded call. So we have to like get the function selector like compute the

sorry get the function signature compute the function selector encode the parameters like stuff that is really human unfriendly but it's understandable for machines. Of course we don't do that. It's wallets that deal with those things and wallets know how to deal with those things because you have underlying JavaScript libraries and a very long supply chain of hardware tools. They also handle signatures, dealing with nonsense and quite a lot of things are abstracted away. But still you I'm sure you had that issue with paying gas. You have to think about gas.

You have to think oh is my like uh gas price sufficient or is that transaction going to run out of gas because it might if the wallet does the estimation wrongly. So there's a lot of you know pains that uh come from how Ethereum is structured and how you have to structure things and like blockchain is capable of smart contracts of running smart contracts and some people identified it in the past and thought well we need a solution uh that ideally does not change the protocol and that and this is where the slow journey to where we are today started and today seems like intense are the solution to that.

So, uh let me continue. Uh I said why fees exist? Metatransactions. So, metat transactions. Any questions so far? Maybe before I get into the new chapter. How could how can I check if there are any questions like here on the >> from the I'm checking the chat. >> Okay. All good. >> All good. >> All good. >> They are hearing well. Just uh if you can remove your blur, >> your background will blur it.

>> I'm not sure if I'm such a good of an engineer to do that, but let me try my best. >> Maybe now I think it may work. Here's the Yeah. Uh video. Yeah. Play the slides. Okay, so metat

transactions metat transactions are like a concept that was if I recall properly born in like 2018. So quite old stuff and the basic idea behind it was let's try to make the UX better and back in the days the biggest pain point was that user have to pay user have to pay gas. So you send you have some let's say USDC in your wallet um let's say 1,000 you think oh it's a lot of money I should be able to transact on Ethereum then you want to transact and you see oh I don't have e I cannot pay for guns such a bad thing and apps were like oh maybe we could sponsor like transactions fees for our users and everyone's like how can we achieve that um there was there were some methods and some ideas and one

of them was like metat transactions so to recap the first motivation to even come up with meta transactions was the problem. Can dabs pay gas on behalf of users? That was like the the initial idea. How can we get there? And the answer was uh is yes, they can. At least they could back in the days. But this design didn't work for like many reasons that I will cover today. And the the next thing was um can users pay fees in maybe some other tokens like let's say USDC. So basically there are like two problems to solve. First off can dabs sponsor gas on behalf of users.

Secondly can users pay transaction can can they interact with uh the network paying with a different token and kind of like passing over the responsibility for you know paying for compute and storage in in if to someone else. Um so how was that actually solved? Um we introduced a concept called metat transactions which is quite similar that it's again an offchain message where you say I am willing to interact with that contract. This is the data that I'm going to send. This is like how much USDC or something I am willing to pay

for. uh this is the guy who I allow to forward my transaction to the chain. We'll get there in a second. And a bunch of other parameters of course nonsus because we want to avoid uh duplication and uh replaying. So here the story is pretty like simple. That's why it was called metatransaction because it's an object that is effectively like simpler because we don't have to think about you know how you pay for stuff and gas and all of those things. Um and what happens? We take that offchain message we send to a guy and that guy would eventually send it to the to the validators like back in the days miners and included in the block and those guys

were called relayers and they were the ones that were facing directly the chain. So there were some issues. First off uh you probably can already identify what did the what if the relayer censors you. So that was the first issue with metat transactions that things were getting quite centralized. The UX was still like weird and you could not achieve really complex things such as you can with intense um such as imagine using meta transactions in the crosschain context. That would be pretty pretty complex. Um also the smart contracts that um users interact with had to be aware of

like what metal transactions are which already makes it way more complicated because developers have to like think about it and be like oh is my user just going to be you know a regular like wallet? Is he going to interact with like metat transactions? It was a it was a lot of pain you know to to to build those systems. So, but the UX was sort of achieved. Any questions so far on this front? Maybe from the audience as well. Okay. Nope. There were issues. Uh biggest one was um sensoring and how do you make sure that

the relayer does not censor you? And this is why the gas station network happened. The gas station network was a initiative I think started by some folks from the EF Open Zeppol and the gas station network itself. There was like an entire EI bunch of EIPs around it uh an ecosystem. And here the idea was okay we can have another network a layer on top of Ethereum where relayers you know can discover themselves like users can submit to different relayers uh we can sort of ask what would be the execution price so you can say oh I'm going to pay

for this transaction USDC but how much should I pay you could ask a relayer different relayers could you know compete with who's going to execute it at a better price and stuff like that So you know we sort of rebuilt the dynamics of transactions but we sort of added like this layer of abstraction on top of it. Um and we also had pay masters. So pay m standardized pay masters. This is important. So pay masters is again this idea like I mentioned at the beginning that dabs can pay fees on behalf of users in a standardized way. So what was really achieved thanks to those standards. You had like a bunch of libraries available in open zeppolene that were supporting that station

network. So maybe let me ask a question to everyone also to the audience. Who writes solidity and for how long have been writing solidity? And if you wrote it long enough, do you remember this weird thingy opens up and you had a helper function underscore message sender instead of calling message sender directly? Um, no one's using that today, right? Why? Because this is dead. Everyone forgot forgot about it. And that was one of the attempts, you know, to standardize it and imply that standard on everyone. And that was exactly to achieve pay masters and having users that, you know, can pay like whatever, potentially not even pay for transactions and stuff like that. So that was the gas station network. Um

while people were like testing that and you know implementing and applications were appearing being built on top of that some folks actually realized hey what if we abstracted even more and then account obstruction happened and ERC 4337 but before I get to that let me talk about the um the gas station network and like a high level diagram. So like I said there was the transport layer access and accounting and application layer. So the idea was that a client like MetaMask account or whatever like that should I stop to have more people coming in.

We need more people to listen. We'll gladly wait for you. Okay. So, what I'm explaining here is um sort of the flow of what was happening with uh gas station network. one of the first attempts to implement matter transactions and standardize it. So we had a client usually browser that had a specialized provider was signing an offchain message which represents what smart contract want to interact with how much we're willing to pay like what token etc etc

some things that a normal user would not really understand also AI encoded transaction cost blah blah blah cool we have that message we send it to a server u metatransaction relay server that would submit it to like a bunch of um layers potentially. So sort of like another layer on top of like RPC kind of the same thing and there was also like a concept of a meool. Um then once that offchain message is sent the relayer so a specialized actor what he would do he would take that offchain message and send it directly to the chain back to a specialized contract

called um I mean sorry a contract that has the pay master functionality. So the relator would sort of like some would trigger the move of funds towards him that would you know reward him for executing that transaction. That was sort of the flow. Um but like I said the contracts that you were implementing uh had to be compatible with gas station network. This is also why back in the days open Zeppelin libraries had this like weird underscore method send them.

That's exactly like a relic of of these times. Any questions on on that on gas station network? >> Why didn't why didn't this model pick up in the end? What? Why there was an adoption with from the >> because accounts abstraction kicked off? >> Yeah. >> And actually uh what is funny uh ERC 4337 is a one is a standard mostly developed by the gas station networks. I think it was called open GSN at some point started.

Okay. Hello. Um so here the objects got a little bit more fancy. Uh everything was like leaning towards how can you represent more here. Yeah. >> Um and user operations of so another fancy wrapper on top of transactions and expressing what we really want to achieve and how we want to interact with the chain. Um, we also replaced relay layers with bundlers. We still had program we still had pay masters and most importantly programmable wallets. I mean, where you could decide even change stuff such as how do you authenticate transaction cuz

probably what you've seen so far, every single action was being authenticated with me taking my private key and signing a message. But account abstraction enabled things such as you do let's say on wordcoin on word chain every single account on that chain is an account abstraction account and you can authenticate a transaction with your your face or your eye whatever. So that was already like a huge UX improvement that was not possible with the previous infrastructure. Um so biggest use case of uh maybe biggest application of ERC 43537 so far I think is worth chain. This is the chain where literally every account

functions like that. I mean every account that is connected with word app because you can use also metam mask if you wish. Um but yeah this is the best solution in terms of UX so far there. Um but here the architecture changed a lot and a lot of standards had to be had to be made. So let me walk you through that. So similarly to meta transactions we have a user that needs to be aware of what he wants to do. Let's say send a token. So he's interacting with a contract. We do the usual stuff such as encoding the call somewhat signing that with like I said

maybe sec PK1 maybe something else uh here it didn't really matter that object that represents an action was renamed from transaction meta transaction could then be a user operation that was going to a specialized memple from which uh bundlers could pick up bundlers could pick up multiple user operations, send such a bundle on chain and then all of those account abstraction wallets were basically checking oh is this user operation valid. So by checking if it's valid we have to verify the signatures we need to verify the nonsis we need to call the contract that we actually said that we want to call. we need to ensure

it doesn't fail but if it potentially could fail if it fails we still need to pay gas and stuff like that. So that entire entire validation was was happening. Um one more advantage that um this construct brings is that uh you have bundling. So, you can potentially allow users to not even pay for transactions because um I don't know if you guys remember the MUV times, but before EIP1559, it was very common that you could uh transact with Ethereum and like swap

some tokens on unis swap without paying for gas because basically you're paying with sleepage and you're allowing someone to like just sandwich you and that's how the payment was made. Uh why I'm saying that is because uh you know here we have bundlers so we replay so it's like another layer on top of uh block building and those bundlers can for example not not charge you at all but they will like do some me on top of your transaction very likely positive so good stuff which was not really possible it's not possible like normal transactions um what more um a hot topic was uh BLS signature aggregation so something that is done constant constantly on Ethereum.

Every time you submit a transaction, meta transaction, whatever, you verifi you verify signatures. But um thanks to the standard, you can identify an account by let's say a different signature scheme. So you can sign with BLS instead of like BK1. Um and BLS allows you to do signature aggregation. So you know on the blockchain everyone is storing everything forever and signatures are quite big. If you multiply them by a couple of millions or like tens of millions, it's a lot of data to store. So if you bundle it and you have you know one aggregate signature for many people, all of a sudden you know running a blockchain note is just cheaper. Uh so that was also like

the motivation you know like thinking forward how Ethereum should look like. So here things were getting really really interesting. But again the problem in my opinion I wish the best to um those standards is that it still imposes a lot of things and this is sort of where intents started to like kick off like you know people zoomed out maybe there's something more to to do here. So let me stop maybe for 30 seconds. Any questions? Uh with this architecture the problem that you used to have with I need to first approve something and then

execute. >> Oh that's actually a very good point that I missed in both uh metat transactions and um gas station network. this uh what you can do you can like sign multiple things at once because like look today if you just do things normally you want to swap some tokens on unis swap what do you do you first approve and then you only swap so you interact with metam mask you have to pop up twice that's we are used to it but for like a normal user it's it's a mess it's like doesn't make any sense in this architecture you just sign two user operations that's it and you submit them the under he executes it. So I'm not sure if that answers the question.

>> But I need I need in the end I still need to sign two times or can I sign one big >> you can sign one big one big structure. Yes. So you could batch it. So here already you know applications like when you're building the front end on the smart contract you could already like think about those those things. Oh I can batch multiple things together. That's already like huge UX improvement. Um yeah any any more questions? Okay. Um here I might be lying but all of those efforts started more or less 2021 2022. So still the era before when rolloffs were just like kicking off and

Ethereum started to be fragmented. So a new problem appeared. The new problem being fragmentation and uh people using interacting with Ethereum in that way that you had like metamas but you had like assets on like I don't know base optimism arbitum and ethereum so things were getting messy again um and the solution had to be found so we made a full circle back hey what if we sign messages offchain we have like some other guy who's like executing things on my behalf but now it's two chains at the same time Um and sort of intends are like uh kicking off again.

Um maybe uh as I'm sort of freestyling that talk, I want to mention what in my opinion was the real like real first implementation of intense in Ethereum was zero protocol like an exchange. Um I don't know if anyone used it here. >> Okay. >> Limit orders and >> Yeah. Yeah. Yeah. So basically the idea was that you're signing messages, you're sending things to their back end. They're doing stuff and then if a match was found in the order booth, they submit the two signatures on chain and the execution happens. Quite quite nice and that was like 2017 2018. So really ancient times and you know we made a

full full full circle that was in my opinion one of the first um levitation of of intents. Um okay but now with those challenges we had to sort of you know zoom out again and think what what the user actually wants to achieve. not like okay he's calling like this uh function and with those parameters like we actually had to zoom out because you already introduced you know a specialized mele so we had bundlers uh we already zoomed out like uh paying for for fees that was already abstracted you could pay with multiple tokens so what if we can sort of create intens application specific and uh and change architecture

completely so we went from what you want want to do not to how you want to do it. Uh and that mental model switch already allows you to you know not think in terms of like one chain but like multiple we can think about the actual outcome that uh my application wants to give to the user. So I feel like this is like the most important thing when reasoning about about intents but they also have their challenges and I will talk about it. Um so to zoom out one more time we have a new actor called solver when it comes to intense. So today the protocols that heavily run on intense is first of cow swap. I'm sure

almost everyone knows cow swap here. Uh one in uh unis swap v4 if I'm not mistaken v4 um and something else but I will mention that later. So that was like the the switch. Um I'll talk a little bit about cow cow swap. So um the original promise of cow swap was uh removing me. Um cow swap to remind you allows you to exchange one asset for the other basically swaps and the eternal problem of amm was that you have slippage. So again one more parameter that the user

has to think of when in reality what the user thinks of is like oh I want to swap my USDC for if um and that was like causing me. So people what were they doing like you had guys that were like watching for the meool and seeing oh Lena submitted a transaction he's uh his sleepage is let's say 1%. So that means he's willing to accept a price that is potentially one not benefiting him to you know the threshold of like 1%. So what they were doing they were basically selling or like buying an AMA manipulating the price so you pay the worst one then arbitrageing you >> 1% sleepage only is there like people rolling like 10% sleep trying to like dump tokens.

>> Yeah. uh pretty bad stuff was happening. But Kausko thought, okay, what if we uh have like a separate mele for things related to swapping tokens that sits like on first our server, then we would somewhat decentralize it. We can have a a coincidence of situation. The abbreviation is COW, so cow or cow swap. And we can see, oh, one guy is willing to sell, another guy is willing to buy.

Oh, what if first, you know, they sort of do it peer-to-peer, and then the remainder of that order, we match it against a unis swap pool or something like that. Oh, and who's going to do it? Solvers. So solvers will take that order flow and see what's the most optimal execution path. So that's sort of, you know, where intents go. We simplify things from the user. we introduce a new actor who's taking care of like optimal execution. Um, and those guys are called soldiers.

So they basically compete for the best uh fulfillment and the most optimal path. Why? Because they then they can extract the fees effectively from from the user. um and they can compete for their then execute and collect those those fees which again those economic incentives to find the best paths for those users. Uh any questions so far? >> I I I don't have a question but the way you phrased it, it kind of uh uh led me to think that uh intense took the bad behavior of me and then put it into solver. like the bad actors, legit actors,

>> not a question because um good let me move on maybe there's something else that I wanted to to say okay so again we always have the same issues as with transactions we need to make sure that replay is not possible what are the ways to prevent prevented. So a stateful way stateful I mean requires maintaining some state onchain and sort of remembering how many actions have been done by the user which is nonsis. So here the annoying part is that if you have a system that runs on intents and you probably have a smart

contract uh your smart contract needs to keep track of nonsis per each offchain message that you sign that represents that intent. That's quite annoying. Another possibility is like introduce deadlines. So you say that signature, oh that signature is valid only for let's say 60 seconds. And if the contract requires the signature after the deadline, the thing is not valid anymore. So you could replay it, but you know, you have a time window, maybe you can apply both and stuff like that. And then that contract of yours has to mark it as uh as executed and sort of like nullified, consumed, whatever. Um, so why I'm saying all of that is because

with intense you you're really like um as a developer taking a lot of responsibility because you're not letting the chain itself and you know set the rules of how users interact with your system. You're sort of taking that completely. You can even say okay I don't want people to have wallets. They can like authenticate their actions however I want. Right? So and then you can like submit this onchain and you really like change the the mental model here. Um yeah I want to mention about dydx but I think we can we can talk about it a bit later.

Okay so where we are today we have another complexity which is crosschain stuff. So let's say I want to bridge some tokens. I want to move them from base to optimism. It's going to be like multiple clicks because I have to like click first approve on base. I have to click uh like bridge which is one additional transaction that is going to take my tokens on base and log them into some contract.

Then I have to wait for the crosschain message. If we use the canonical messaging bridge to, you know, notify one chain that the funds arrived. So, I have to wait. I'm getting really nervous. Then I have to open MetaMask again, switch the chain. Oh, but I need to import the RPC. So, I go to like RPC list. I check. Oh, okay. The RPC of optimism is I don't know the the RPC, but you see what I mean? Oh, I also have to check the chain ID and stuff like that. And then it happens. Oh, I don't have any if on the I cannot pay for gas fees. It's terrible.

But I somehow got some some if on that chain and I can finally, you know, claim back my funds. Congratulations. It took me a lot of stress, a lot of time and a lot of money and frustration. Um but some people thought hm what if we have guys who actually take care of the execution and will just run that money and the guy just signs a message that will allow to pull his funds. So you know here again you're assigning an intent how you do it let's say on a cross or another bridge that I'll introduce called the most again you zoomed out you build um the system of authenticating user action that is very specific to your

application um and that works in the in the in the crosschain context and it could represent stuff such as oh take my money on optimism I will have a solver that will take that money and maybe even do a crushing swap right like he will it's going to give me if on the other side or I can do some crazy stuff such as I do on let's say bungee where I spending USDC on optimism uh sorry on base and I'm getting on optimism if and USDC because I also want to have a little bit of the gas token so we see more stuff is available because we zoomed out and we sort of delegate the responsibility of finding the optimal path to external actors Um

any questions on that so far okay good there is one more complexity a lot of them but in the crosschain context we also have settlement so coming back to the original example where I'm using let's say um the canonical message bridge to inform one chain that the funds arrived is setting like we have to wait until that message arrives. But if you use a breach such as a cross, it's almost instant. How is it possible? Uh well, you have a guy who basically takes on the risk. See, he he sees that he locked the money into a contract on base

and he's going to front that on on the other chain for you and he's waiting for the settlement. He will, you know, wait until optim base settles back to Ethereum so that message can be propagated to optimism. we can get the funds and optimism or the other way around whatever we introduce like another layer of and we defer the settlement. Um so this is something that is achievable only with tense here only and this is sort of you know where the UX in Ethereum where the UX in Ethereum is going.

Um any questions? I always need um kind of a software that is listening the events and the in the chains by because when I submit a transfer from chain B >> to chain A, I I will trigger uh a kind of event telling you I wanted to transfer this value to train to chain A and you need to kind of software that is listening to the event the banks there is no other way right >> as a user why why do we need

>> I don't know somebody a third party a trust trustworthy third party nowadays for instance CCP this trustworthy third party is the is the chain for instance but uh for instance in polygon if I want to to send some stuff among Ethereum and Polygon. Polygon does this as well. Well, is listening and make transfers among Polygon chain POS and and Ethereum. They they have a software that is listening their smart contracts events.

>> Yeah. Let's say the bridge providers they they need to have that software. >> Yeah. So for this this is something that there is no other way to >> Yeah. I always but the user he's happy because you know one click >> but doesn't sol that isn't that the incentive to run the software >> um because >> I mean they have access to the order flow they have access to the order flow they can they can capture those fees have access they need to listen to it so yes >> because before the start the session the my my the discussion I I was having with Robson is that nowadays the problem is each uh each provider has their own

signature or their own steps to do this you know the their grids they have their own you know math u >> standard >> standard methods or standard uh events names blah blah blah. If we have a single standard you know that okay I have my I have my chain I have my bridge but I follow at least the same name everybody follow the same name as a developer this will make my life easier you know like we have a RC20 I love everybody post the same name >> this will make it start to make my life

easier you know as a developer >> uh It's a good point that you're raising. I don't have this covered in the slides. U but there are actually standards being developed around intents. Um let me let let me phrase it politically because I have a strong opinion here which I don't want to express but there are some standards being made because indeed as a as a developer from your standing it's going to get really messy uh with those architectures sort of like taking off. Um but in my my opinion I okay I think I have to express it uh we are sort of doing a full circle you know and getting

back to like the GSN base that is trying to build a standard around it that will then will like break again no one's going to follow it but anyways uh some work around standardization is actually happening already in the in the intense ecosystem do you know the the optimism super chain inter operability protocol is that like one of those standards because it's it's the one that's being built right now. >> It's a it's a little bit um unrelated. I mean it is related because you know when it comes to intense nowadays when we build systems that utilize intense it's usually crushing intense because this is like the biggest problem that we have to solve nowadays and every

intent system has two things that are sort of like extra and special. So we have solvers and we have settlement logic and that settlement in that case is crosschain and within the super chain within chains that are like part of the super chain we can have like some communication protocol that allows for like faster settlement. Uh so it's a little bit unrelated but it's work that let's say can facilitate setting intense between base and optimism. Previously you mentioned about a cross doing like very fast swapping thing because someone else is willing to take the risk right.

>> Yeah. >> What is it? What is this risk specifically that you're talking to reorganization of the blocks in >> and the L2 potentially not settling like reorganizing transactions and not settling back to the base layer and stuff like that. By base layer I mean the L1 original. Yeah. So like I pay you I as a solver I give you the money but the money that I was going to pick as the payment reorganize it. >> Yes. Exactly. >> So the risk calculation that I need to do is like the probability of reorg of your origin >> and and look how crazy this is getting.

Like as a solver you're becoming really fancy because you have to understand how the L2 actually works. What are the risks involved? when is it going to settle? You're like, oh, optimist will probably settle to Ethereum in an hour. So, my funds will be stuck for an hour and within that hour I could take that money, put it on a make some yield. So, my effective cost is this, this and this. It's getting really complicated, you know, to price those things. But from the usual perspective, just just an intent, you know, and then there's like some specialized guy that is going to price it, execute it, and and so on and eventually even settle. This would uh basically Um I think I'm going to continue with the

slides. Um so now I have to mention about it because this is like the work that I've been doing for the last 3 years. So feel really bad not talking about storage result. Um so today the word is becoming um fragmented on Ethereum and settlement is crucial. Storage proofs are like a very funny cryptographic construction that is possible on like stateful blockchains such as Ethereum especially blockchains that merkeize a state and every block comes with the root of that state called state root. It is possible to prove that something within that database existed or exists um and based

on that you can do settlement. So um every chain that is a roll of to ethereum such as optimism and so on follows the same construct. What you can do you can generate miracle proofs that say something happened or like something is present in the state or it was present and you can basically use those statements on the other side and execute the settlement right you can do even tracer stuff you can compress it into zk and you can you know compress multiple settlements at the same time and access multiple storage slots access multiple events multi multiple actions and so on and then one proof can potentially aggregate facts from mult multiple chains because I can have one proof that

says this happened on Ethereum, this happened on Optimus, this happened on Arbitrum. So look, even though I'm a solver, I pulled money from let's say multiple different chains from that user because the user had like funds everywhere and he wanted to receive it on let's say Polygon, but he had 10 USDC here, 10 USC here, 10 USC on another place. He signed one thing, but they do the settlement, you know, in one go. So this is like what storage crews effectively enabled what you could potentially build with that with with that um and yeah we have that tool that enables efficient settlement.

So wait did I yeah I didn't proceed with the with the slide. So um with what we built um one can build on top of our stuff systems that utilize intense and um sort of access crush data as well as historical data why historical data is even relevant uh in intense so I think I has a slide about cow swap or it's the next one but uh I have it here so on cow swap solvers like get reimburse also when it comes to bridging once a solver proves that he fronted the funds and you know when he proves that that's he

settles things that were happen that happened in the past right so he has to access historical data and again the only thing that gives you access to this historical data from a different chain is like storage proofs so those architectures are actually getting really relevant in today's Ethereum um and it's becoming like possible to even build that but also I can for example prove that I'm the best solver so I get access to deal flow or I will collect fees I will collect like more of them or I can you know make some faster settlement and sort of like uh have some follow different rules in the protocol than other untrusted and

unproven solvers cannot because I you know had a good track record or stuff like that and reputation So this is sort of what we what we are doing and what's our contribution into that ecosystem. Um and now to maybe getting towards the end of my talk but I would like to first talk about like the stable a little bit. So there are like I mentioned a couple of uh applications that do utilize intents and they differ quite a bit. Um I mentioned like the five I'm the most familiar with. So swap I think the most popular one unis

swap x one each and uh zero x um who is getting paid. So who's the guy you know who gets paid by the execution? Um as you can see the name is different for every single one of them because there are no standards yet. Some are being developed but no one is following those. Uh they play sort of like different roles. They do execute some me. They sometimes find the most optimal path but very often they also execute it and they do both things at the same time and they also hedge it and they do a lot of like weird uh magic in the in the in the middle.

um they are rewarded like differently. Their payout is also different. Uh the way gas is paid also differs and there are like different constraints. Um, so like step out and allow you to like take a picture if you if you want. And I think that this is I'm getting towards the end of the talk and happy to like engage into like a conversation discussion and uh answer any questions.

>> Yes. Do you think there is a way that solvers can hedge against the settlement not having >> yes um so there is some risk like I said let's say you're a solver for a bridge a market maker for a bridge what could happen is that you front end the funds for the user and then the L2 let's say I don't want to name any L2 that would do that but let's say there is a new L2 completely untrusted an optimistic one and they say oh yeah I give you this preconfirmation this transaction you know like happened and then be like ah you know I this transaction didn't really happen um and as market maker you paid out your funds and you won't be

able to like execute the set because that chain did not settle to the base layer so you cannot even initiate the dispute methane whatever so yes you you are taking some risks because the sequencer can like mess up with you um do they hedge against those things today no is there a provider for that know like there's no liquidity on those markets but it would absolutely make sense for them to hedge against such such events >> and if they have to hedge it and hedging always comes with a cost users who will sign such an intent they will like pay the price for it but again they have no clue how to price it as solv the itself let's say 100% of the risk to

say let's say a couple of for example. So it's like distribution. >> Yeah. >> Okay. >> Um >> yes >> uh I in this table you are not mentioned at least I don't know if they are but they are not known as bridges like cross or lifi or those guys >> why you didn't just coincident or they are not doing that. No uh no specific reason. I just focus purely on like uh swapping and stuff like that because there is like more um me involved more me dynamics and I really want to talk about MV dynamics today. So that's purely the reason yeah and we also have

like Dutch options in many of them the reason for that is to reduce that me and create like different different dynamics. So yeah, no specific reason because in tens or today the architecture is used I think mostly dominantly like region >> and do I saw that some of those bridges I don't know about those place but you have permission solvers is not every bridge you have like why >> um so very often there are some like assumptions that were made where a solver could censor you or like could give you a really bad price um and could

mess with you. So, we probably want that solver to have some stake. Uh so, if we prove him some misbehave misbehavior, we can like slash him. So, I think that it was one. >> Yeah, in one each you have you have to lock up some some tokens and basically stake. And the reason for that is that if you misbehave, you'll get punched. So yeah, that's why often you have to like sort of white list or like whitelist once they stake stuff like that.

>> One question that I had is so as Jeff mentioned about like the bridge providers. So nowadays do we have a trustless bridge model? >> There is a model. I even have a diagram. I'm going to shield sort of my bags again. So with working with a bridge called most WTF which does have an architecture is like fully trustless and they use proof for settlement for the most part. Um I'm thinking how to phrase it, you know, because I'm biased and I being recorded, so I have to be like very political the

way I say things. Um but the biggest bridges nowadays are not like fully decentralized. There are some trust assumptions being made. Um and there are reasons for that, right? Because trustlessness and decentralization is something you have to pay for. So let's say if you have a settlement mechanism is like fully trusted and you have like just an oracle let's say chain link or like some something something different like it's going to be way cheaper right than generating the proof. So that means that pricing in such bridging solutions is also going to be more favorable but as a user you don't have such strong guarantees that you're getting let's say the best price or um your money will actually arrive and stuff like that.

someone can can mess with you or potentially if you're a liquidity provider who's providing liquidity to facilitate those like swaps you might be taking a lot of risk right because if the oracle misbehaves like you're screwed um yeah some other like applications of intense something I'm personally really involved in is crushing lending and borrowing exciting >> uh portfolio manager management so you could build an internet based system where you say I want to have a portfolio that is I don't know exposed to a specific class of assets and you just allow external solvers to like

rebalance every so often. So you say 40% of my portfolio should be something with this level of volatility. So if some asset within your portfolio gains value or like loses value, this balance is going to change. So you could have a solver that you know sort of does that rebalancing and on your behalf is going to execute some scripts and stuff like that. There's a lot of designs that become possible um and you know you can even have subscriptions. So something that was completely not poss is not still not possible with standard transactions because every time you make an action on chain you have to click but with intense you can just sign it once and then someone's going to take that signature and be like oh hey in the past

you actually allowed this thing to happen and now I'm executing this on your behalf. So you could have some pre-balancing things you could even have subscriptions so you pay like every month or something without you know clicking because you just take the signature of the guy and stuff like that. So the conclusion I I want to say is that um the way we do interact with the chain is really changing today because we're not interacting with one chain anymore and um the user patterns are like changing a lot and uh happy to answer any questions now.

>> Could you go back to slides where you have a kind of flow Yes. No. No. No. Yeah. >> Could you explain again this? >> Yeah. >> So this is how the bridge works. So what happens is that let's say bridge USDC from base to optimism. Um do we want to make it complicated and make it a crosschain swap or just like a simple bridge?

USDC to USDC or USDC to EF? USC to EF. >> Okay. Amazing. So, what I do as a user, I would first uh call an API and ask some solvers what they're able to offer. So, I say, "Hey, I have 1,000 USDC. How how much E can I get on the other side?" You'd get a bunch of like different quotes. Once you find a code that sort of satisfies you, you're just gonna take your money, lock it into um an estro contract and your money is locked, >> the guy who's like constantly listening for events and you know >> price will see okay you lock the assets

so let me fulfill my obligation and take that and put it in your wallet. On the other hand, on the other side, you as a user, the whole flow is done. You're happy. You got your E. But then there is the other part which is a settlement. The that guy that fronted that liquidity has to generate the proof that he did it on the destination train, take that proof, >> show it to the Astro and unlock the funds. >> Yeah. Because I used to work for a protocol called Panther. >> Mhm. And they in banther protocol they we used to work to build something similar you know. So when you deposit here, you create a a kind of, you know, you receive a a kind of a receipt and

and we generate a proof that you receive you deposit kind of asset in in a kind of AMM. >> Yeah. >> A pool. And then u Okay, you you we have a micro proof here. And then in the other side we have a kind of a you know kind of some some miracle trees that uh we have a kind of um macro forest actually where we sync this macro forest across the chains >> and u settlement is a really tricky part of like the synchronization.

>> Exactly. Yeah. Because we have to sync >> Yeah. across chains and and a single chain was a kind of leaves. The micro roots of the chains was a leaves on this micro forest in and the leaves when and when when I have the a user take this this this proof here to another chain to to withdraw the other the funds. I I send the send the the the proof. I calculate the leaf the side of the micro for the the side of the micro forest and I release the the funds.

>> Mhm. >> Uh because and of course time to time somebody needs to check the balances rebalance the funds y >> to have enough of balance in different chains. But uh yeah, this ised is something kind of similar. >> Yeah. When when u when was that protocol built? >> Uh 2023. >> Okay. >> Uh I think they still I don't know if they they become live but you can you can check this plant protocol if they know was very aashurious at that moment.

uh but um was very very interesting the following the they're following the what you what you're mentioning but it's very I think what we what we uh what we me what felt that we uh that we missing a lot was kind of a standard of the that's something that be in for the the community of the how many the no the other the other blockchain >> polka dot polka dot they have the they

have the protocol to to exchange a message across the the the >> the power chains right >> the power chains X I forget the the protocol X it starts with if X >> XMTP something like Yes. I say, >> you know, I think nowadays it's time to to Ethereum to have something similar. You know, >> it's fine. Yeah. Yeah. >> Yeah. Because nowadays everything is based on a layer and you know we have a a etheum like a set a set layer and uh we have a I don't know several different layer two networks. We need we need a standard you

know for you know standardize the names the a protocol for you know to exchange because it's terrible you know okay now I need to optim yeah optimism I need to do this way ah now with the I don't know with the uh CCA I need to do this now with the I don't know nowadays with the circle >> I do find it really funny that Polka Dot sort of spinned off Ethereum and now Ethereum did exactly what Polka Dot did.

>> Yeah, exactly. >> Taking off Shark. Oh, wow. >> Yeah, exactly. >> Consensus layer. >> Yeah. And the risk V. >> Yeah. Right. >> Exactly. Yeah. The the point the point is the doctor I forget >> the name. David Wood. >> He is the guy. >> Yeah. >> The problem is he's not politician. That's the he doesn't have patient. >> Well, another Ethereum co-founder called Hopkins, the Cardano guy.

>> He's a character. Yeah. >> Charles. >> Yes. DJ J. >> Yeah. But I think it's great. >> So one question regarding the jobs in the settlement when you create when you generate a clue then you did the transfer the destination chain I need to verify that back on the origin chain. Correct. >> That's right. Yes.

>> Yes. Okay. So in order to verify this style I would need to know like the mer root of the destin like I still need to connect like how the origin channel is going to know that this proof that generating the destination is really correct. I wouldn't need like an oracle of miracle. >> Oh I I love that question. I love that question. I feel like I should make another talk about storage process. Um but here the the magic is like storage.

So basically it's a combination of uh we leverage how blockchains are built especially what's the ethereum architecture today. So if you think about it what happens is that you have a bunch of alus that settle back to ethereum right eventually and they will post the state somehow. So if you can access the block hash of K1 and L2 and you can because you have the canonical messaging bridge or you can verify a consensus group. So if you just run a live client on the destination chain you can sort of access the commitment of those other layer 2s and you can decompress them cryptographically and access the information about what

happened there. That's sort of our like contribution to to all of that. >> The main contribution. So you already have the information layer one or the other layers because >> Yes. >> But if you are bridging from an L2 to another L2. >> Mhm. >> Do you still have this information in the >> Yes. Because that one L2 uh where initiated the the bridge um like the bridging operation will eventually settle to layer one because otherwise it wouldn't be an L2. But the guy who's like taking risk here is the market maker. The guy who's going to front the funds on the other side.

If that L2 decides not to settle for some reason, he won't be able to unlock the funds from the escro. >> Perfect. Yeah. And for chains that they find out to like a week is a lot of risk. >> Yes. Yes. Especially you're doing like a crosschain swap because imagine you're facilitating um a swap from like USDC to EF. So as a market maker you're effectively selling your E to the guy and during that week the price of E went up. you will feel bad. But you can be a smart market maker and like let's say buy that E on an exchange and be like delta neutral and it comes with like some risk

or you know that you let's say it's the other way around the user is like um selling if and getting USDC so you know that in a week you will have some if unlocked. So for a week you have exposure but you can be smart and be like huh I will pay buy a put option. I'll have the right to sell that if Yeah. And then the price that the user will pay for let's say that bridging operation is gas fees plus you know black and shows whatever is like the proper way to price it. So you see for the user it's getting really simple but

the solvers they are the guys doing that's are doing like the the fancy operations. >> Yeah. >> Okay then. So in answering my question, the oracle is the storage proof that is already inside of the blockchain because of the layer one layer two thing >> and and do you have a take on if you prefer optimistic longer finality layer twos or to zero one like do you have an opinion on that or zero knowledge because like well what's going to be cheaper nowadays through generation is getting really Um and if we have like a lot of economic activity on a optimistic product let's

say bridging let's assume that people want to do it trust processly what's going to be more expensive generate the proof or hedge that much money the cost of hedging is like way higher right so zk all the way and fast settlement >> okay So, if there are no more questions or questions from the online audience, I think I'm going to call it a night.

Thank you.