[trustless://interop.landscape] Yoav Weiss - Trust-Minimized Interop with EIL

Transcript

day. Please welcome to the stage Yav Weiss. Hi, thanks everyone. Um, can you uh just second uh the font? Can you increase increase the font? Yeah. So hi everyone. So to my talk today uh my talk today is about uh the

challenge the challenges uh with trust assumptions in interop protocols cross2 protocols and then to show how EIL uh address these challenges. So one yeah so one question we need to uh we need to ask ourself whenever we use an inter protocol or anything else on the blockchain is who do we have to trust and how much like what can like who could hurt us and what could they actually do to us.

So one problem is one problem you have to think about when using for example intent protocols or anything that involves moving a state from one chain to another is who can who could who will testify that the operation actually happened at the destination because the destination there is no direct communication at least not fast one between the destination and the source. So let's say you went to a solver uh you went to a solver and asked it to do something and it does it or it doesn't do it at the destination but now the solver wants to claim the funds at the source at the at the source chain. So someone needs to testify that uh someone

need to need to need to attest on L1 that it's okay to release the funds back to the uh to to release the users funds to the solver because it has because it has been fulfilled. So now the question is uh who is authorized to attest for it and what happens if they uh what happens if they lie uh if a if they submit a false attestation or if they just stop working. So in some uh protocols it's a in some protocols it's a it's a permissioned oracle which uh which brings some trust assumptions of course because uh you can't easily replace it. There are other protocols that protect it using a

dispute mechanism. And then you have to ask yourself who do you trust for the dispute mechanism like u who you are appealing to someone when you appeal who can uh I mean who are you appealing to and could they collude with the malicious uh oracle. Now um in um another thing we need to consider when using the blockchain is censorship resistance and uh execution livveness because that's what the blockchain is about. So it's uh so in many protocols then in many protocols the user funds uh become associated are tied to a specific so uh solver before the operation takes place at the

destination and this is important for efficiency. It's uh much it's much harder to do a protocol to implement a protocol without it. But then uh but then the question is what if it doesn't execute? Could the could the user easily switch easily switch to another solver or relayer or is the user stuck for a while? And in some protocols in some protocols you actually do get stuck. It's a you actually do get stuck. you send a fund to someone and uh if they don't deliver uh yeah then you are stuck at least for a while. Uh in other um in other protocols that are in better implemented protocols uh they have something like for example um for

example having an exclusivity period for one solver but if the but if the solver doesn't uh if the solver doesn't take advantage of it then after a while any other solver can also do it. So that's already better, but it's um but there is still some time in which your funds are associated with someone at least someone can now delay you. Um another issue is uh another issue is uh that the solver could uh could grief you. So since the since the server is executing on your behalf, so you're basically using an intermediate intermediary to run the uh to to execute your transaction at the destination. Uh

they could mess with your execution because this is not a transaction, it's a call inside a transaction. So some things that uh some things that can do is for example making your call revert unexpectedly or misbehave unex misbehave and do something that you did not intend and it's still and and it's still considered the intent will still be considered fulfilled. So um it's a like one example uh one easy example is to call to call your uh to make your call at the destination with insufficient gas. Suppose you have a relay. Now the relayer makes the relayer makes the call with insufficient gas. So you run out of gas inside your call. But they do have sufficient gas in the outer call to emit

the fulfilled event. So now it's considered uh so now the intent is considered fulfilled as far as and an oracle will attest that it was fulfilled even though the inner call actually reverted. So you end up having funds at the destination but without your call getting executed. Uh another such example that is uh more because I mean the gaz the g thing could be mitigated. Unfortunately currently many protocols don't pass a gas limit but you could pass a you could implement a protocol with a gas limit that the user signs as part of the intent and say if I'm not given this amount of gas then it's not considered fulfilled. But there are other ways that the other attacks

that are easier that are harder to uh harder to mitigate. For example, uh you could wrap it since it's a call, you can wrap it with an outer call. So what if the solver calls you um what it calls you for example through um through a flesh loan. Suppose you have a the solver the solver takes a flash loan for a very large amount and now it can move token prices and then it makes your defy call at the destination and the defy call fails because they move the price using a flash loan after it reverts um after your call to a contract reverts they just repay the they repay the no when after the intent is ful considered fulfilled but without your intended

result they can still refund uh repay the flash loan. So this is another example of uh being able to mess with the state of the destination. There are other subtle examples like for example many protocols implement re-entry protection using re-entry guard. So what if you are going to use so your intent is going to use something that has re-entry protection but the solver also calls. So the solver calls this protocol with re-entry protection and from the and from its call back it now makes a call to it now makes a call to the intent protocol to fulfill your intent.

So now your intent gets executed but it gets executed. it reverse on the re-entrance guard, but it's still considered fulfilled because they made the call for you and then uh they exit. So in so all of these examples uh bring us to a bring us to a place where the user pays the fee, the solver got the fee, but it's not a but the user did not get the intent executed. And you can think about it not just as griefing because it's also a very strong form of of censorship because now another solver can't help you. Let's say when when looking at a protocol that implements exclusivity period. Suppose the the suppose the exclusive relayer or solver.

So the one that got exclusivity decides to do this to you. So now uh the event so so now the intent was fulfilled during the exclusivity period as far as the protocol concerns even though they reverted your call and now after the exclusivity period it doesn't matter nobody can help you anymore because the intent it no longer exists it was fulfilled. So this is a strong kind of censorship that is quite hard to fix. Uh another question now is uh so we talked about what could happen to the user. Now let's see what could happen to the solver. I mean especially if we try to decentralize solvers which I think we should

uh then who could hurt the solver and one example we already discussed. This is what happens if the oracle refuses to attest. Since the solver dep the solver depends on an uh depends on an oracle attesting for it attesting for the fulfillment in order to get uh in order to get paid. So what if it doesn't and it's a permissioned oracle? So that's a simple example but now we we have to ask ourel also in a decentralized and permissionless network could some could users also uh also mess with solvers and in many cases they can.

So suppose we want to have a suppose we want to have a decentralized solver network that behaves much like a mempool just like the transaction meool. Now we need to consider denial of service attacks on this network. So it's really hard to create a mele for intents uh really hard to to create a mempool because the intent can be quite intense quite intensive to uh uh to simulate and it's um and you can easily flood such a meo with a large number of intents that seem fulfillable like when you simulate it seems fulfillable but actually it's going to fail on chain and you couldn't And you could uh do

something for example like a send operations that take a lot of computing power and then check the time like after spending all the compute power they check the time and they fail after a certain time. So like when you simulate them initially when you see it entering the me pool you can say uh okay it looks fine and then so every solver uh every solver checks it and sees that it's uh it seems fine but then when they actually want to submit a destination it no longer works because the time has changed or they could just check the slot of a a frequency changing slot such as the price feed for a the price feed or the unis swap price of some uh high velocity token. So now so now all the solvers

spend a lot of resources and they don't get paid for it which can create a load on the network and therefore such networks tend to become centralized or to limit or protect themsel by limiting to a specific uses that to specific uses that are known to be safe instead of having a generalized intent framework. Now u um an even an even stronger form of this is griefing the solver uh by causing it to revert onchain. So what happens if the user sends intents that they look fulfillable and even when you simulate them at a destination simulate them against the current state of the destination they still seem fine but then when they put when you put them on

chain they revert. For example, if they do um so if they do a time check, if they do a time check or they check this uh like frequently changing slot that changes during the block, then if you simulate it against the end state of the last block, but then it's not but then the intent happens not to be the first uh transaction in the in the next block, then it would revert. But now the solver actually pays for it. The solver paid Gaz. So uh which uh which brings us to a which brings us to a tradeoff that uh and there is no good trade-off here. So there are two options. Uh you could uh charge the user even though um you could

charge the user even though the intent reverted and was not fulfilled. But then it means that the solver can grief the user just like we described earlier. You could cause the intent to be executed in a bad in a bad way and the user still pays for it. Or the other option is you say you don't charge the user. But if you don't charge the user then now the user can uh grief the solver. Now the solver pays for these reverts which the user causes and the user can cause a large number of those. Now let's take a look at let's take a look at how EIL works and we'll see why these problems don't exist there.

So this is the uh this is the basic flow in in EIL. Let's say Alice. Um, so so Alice wants to mint an NFT on chain B. It costs one ETH. She doesn't have any ETH on chain B, but she has enough on chain A. So she prepares two user ops signed by a single signature because uh we have a so we have a multi-chain account that allows you to use one signature for multiple uh uh for multiple operations, different chains. So the first user op runs on the first she she sends the the first user op to chain A and it locks uh it locks one E plus whatever fee she is paying. Um it

locks it for a very short time uh in the uh on chain A. And now we have XLPS. These are the entities that provide that provide the liquidity and the gas at the destination. So the XLPS compete on a compete on sending her a voucher which uh she's basically buying a voucher that she's going to use on the destination chain. So they get um so they get this um I mean they compete on providing the voucher and it's actually uh on a competitive uh competitive environment it's going to happen within the same block because she submitted it to the meool and since they compete against each other uh then an XLP sees that it actually that it can claim the fee h

right now in this block so it makes sense for it to include the voucher together like to bundle it with the request which means that the user now gets so Alice gets a voucher immediately in a zero latency and as soon as it lands the source chain she can immediately use the voucher. Now how does she use the voucher? She now appends it to the voucher is a signed message from the XLP that gives her the funds. It's an atomic swap. So basically to claim her funds uh there was a there was this voucher and this voucher can now be used to claim funds from the balance of the uh of the XLP. She appends this to her to the user. She she uh prepared for for minting the NFT and she puts this uh she she submits it to

the destination chain to chain B herself. She doesn't use an intermediary. She just uh just sends this to destination. Now uh it uses so this user uses a pay master contract called it a crosschain pay master. Uh this pay master verifies the voucher. It pays for the gas and it gives her the one E liquidity that she asked for and this is deducted from the XLP's uh uh from the XLP's balance in the pay master and the ex and the operation gets executed. So a call gets executed the NFT is minted and then after a dispute period after a dispute period the XLP gets the funds on uh gets gets Alice's funds on chain A. So that's how EIL

works. Now let's see how it uh so let's see um why does it solve all of these problems. So we moved most of the logic to the wallet. This is an account it's an account or a wallet centric interop which means instead of having a solver you run you run all the logic locally. Now since the user self-executes on every chain with no intermediaries and using this single signature which gives you great UX uh there is many of the risks uh become irrelevant. The XLPS they give you a voucher for GA and tokens but they don't execute anything at the destination actually there is no transa there is no transaction by the XLP at the destination and they do not

communicate directly with the user. It's everything happens onchain at the source chain. Now the voucher is also atomic behaving similarly to HTLC. So there is no mid state in which u in which the user sent the funds to an XLP and doesn't and doesn't get uh the funds on chain uh on the destination chain. Um so there is no oracle because we don't need one. It's that we don't need someone to attest to attest for correct execution at the destination because the user executes the destination. So unless Alice wants to uh wants to screw up her own transaction, you don't need to prove

anything about it. Now uh one thing that could happen an XLP could try to withdraw the funds to provide a to provide a a voucher and concurrently withdraw the funds at destination. So now the voucher cannot be used. Now uh this in this case this is a provable offense. You can uh so like so Alice or any of the other XLPS and anyone actually could prove this at the destination because everyone sees the voucher that was given at the source chain and they can now make a call with a call to a prove function at the destination and the pay master sees yeah this voucher is valid and it's insolvent meaning that this is a this slashable offense. So this sends a message to L1

and every XLP staked on L1. So this XLP is getting uh slashed and whoever reported it gets uh gets compensated from the from the stake. So the incentives are built in a way that the incentives are also built in a way that Alice's funds don't get delayed because um the XLP so the XLP um gets a part of the stake for reporting and it gets another part of the stake if it provided an alternate voucher. So from Alice's perspective, if the voucher was insolvent, then in the next block, it's likely that she'll receive h that she'll receive a voucher from another XLP. And from her perspective, nothing happened.

There was like a one block delay. She still has a voucher that she can use. And the incentives there are first of all, the the AL voucher now gets the fees. So like the the signer of the AL voucher gets the fees instead of the original one. And in in addition, it also gets a part of the stake. So you have a you get an extra kickback for delivering this and then later uh so later when it gets proven on L1 uh this XLP gets the it gets the stake of the first XLP and it gets the funds released to it. [clears throat] So the only dependency here is on canonical bridges which every rollup has. There is no instead of an oracle you can just you can just freeze the funds and handily

and handle the dispute through layer one. Now there's also no censorship vector because uh the user self-executes the operations. So there's no one that uh no one's supposed to execute on your behalf and therefore no one can uh censor you. Uh the competition between the XLPs uh in incentivize that you'll get the voucher since they are permissionless. So, if one XLP doesn't want to give you a voucher, then uh someone else will and they don't even know what you're going to do since you don't show them your call. They don't know that Alice is going to mint an NFT on another chain. They only know the amount. They only know they only know the amount and and the destination chain and they compete on who gets the fee.

So, and and they cannot and once they give a voucher, the transaction is over for them. It's atomic. So now they cannot interfere in any way. They cannot they cannot somehow make it fail for Alice because she's the one using the voucher to execute a call. Um the griefing vectors that we talked about like sabotaging the execution also can't happen because Ali self-executes. So she's not going to she's not going to wrap her own call with a flesh loan that uh that's going to get her reverted because she wants it to succeed. the operation always run exactly the way that the user intended and it's also it's also easy in EIL to

make the XLPS decentralized uh making everything permission and decentralized because uh because we don't have all of these vector these do those vectors against it so the XLP cannot be dosed by bad intents because you don't ask it to execute something so there is no call that might uh reverse to the destination. The XLP doesn't handle calls. It just takes your funds, gives you a voucher, which is the same operation and therefore it doesn't need to spend any execution resources. It doesn't need to simulate anything. All it needs to it sees that you uh it sees that you lock the funds and it gives you a voucher in order to receive these funds. Since it cannot fail, so this

operation cannot fail. You can't give a voucher and not get paid. then uh we don't need to worry about uh den of service and it cannot be griefed at the destination uh using reverse because again it doesn't need it doesn't care about execution whether Alice reverts to the destination or not they don't care they they get paid they get paid the fee either way [clears throat] so the the problem of executing something on users behalf is a really hard problem. That's something that we uh we've been thinking about in a while.

EAL solves it by not having someone execute on behalf of the user which removes uh which removes all of these problems. Now the so the user uh the user self-executes the XLP just compiles the fun just provides a funds we don't need or we don't have the censorship problem no u uh no need to worry about reverts. So it's easy to decentralize and the settlement is atomic and in addition you get the great UX of a single signature and the lowest latency possible because of the mele incentives. So this makes uh this makes EIL both great UX and trust minimized and it works it works because the user

is always under full control. The the user is uh the user has full sovereignity over the over the execution at all times and inter becomes trustless. Uh I'd like to take the take the opportunity here to invite wallet developers and dub developers. Uh so please talk to us if you want to explore integrations. We launched uh so we launched a test net and we're going to have uh we're going to have some uh at the hackathon it is global. We're going to have some prizes for for a building on EIL. So please talk to us.

All right. Thank you.