[trustless://eil] Shahaf Nacson - Understanding EIL: A Deep Dive

Transcript

Um just a quick check in the audience. Uh who here defines themsself as technical? >> Hands up. >> And that's it. >> All right. And hands down. Anybody here self-declared non-technical? All right. Cool. Uh the next h talk we have coming up is a technical talk. Um let me just get the name of the talk up for you guys. All right. understanding EIL a deep dive with Shahav Knoxan who I think if you are not available oh you are over there hey all right awesome well this is a man that needs no introduction but a wonderful EF researcher and he's going to deep dive on EIL with us everyone give a big round

of applause while we call our speaker up >> thank you >> um hi So, ah, that's a good picture of me. Uh, so right now I'm going to do more of an overview of the system and the main flow and not as deep dive as I wanted it to be at first, but this is the first time we introduced the protocol. So, hopefully it will be more understandable that way. So, some of what I say will be overlapping with what you have said and that's okay.

But I hopefully I will focus right now mostly on the on the flow itself and bring it up to more concrete terms instead of the highle goal and the vision that you have presented earlier. Okay. So that is not updated. Alex is sitting right here. Okay. So what is EIL? So as we wrote here, EIL is an onchain protocol that allows you to seamlessly interact with the Ethereum ecosystem that is mostly L1 and L2s uh which we which we wanted to bring in order to defragment the currently very highly fragmented network that we currently have because as

opposed to 2015 where we only had or 2016 where we only had Ethereum and all of the DAPs, all of the interactions were with one chain. Right now if you want as as you have also showed in in his example if Alice wants to send 100 USDC she needs to know that this USDC for example is on arbitum and if she wants to send it to someone on base or on optimism or another network uh then she needs to know all the details and we'll see soon the way I explained that we there are a lot of friction involved in inside of it. So an EIL just is the off the onchain protocol that allows you to seamlessly interact with the network.

Now it is built on top of 437 ecosystem. So we bring all the good things from uh 467 including gas payment and obstruction with pay masters which we also utilize here. And the main uh the main uh features that we introduce right now is crosschain asset transfer and multi-chain execution. And of course, as I said, crosschain gas abstraction. Okay. So, compared to 437 where you can use a pay master to pay for a transaction on one chain, here you can transaction on all chains.

What EIL is not? Okay, it is not a D5 protocol. We have no governance, no token. Okay, we don't have any validation, any validators. we just enable seamless crosschain D5 interactions. Okay. So we uh we I think that we we complement uh D5 protocols very well and what it is not as well it's not an intent framework as you have suggested as well. Okay. Because that was brought up. So we decided to preemptively make state it here. Okay. This is not an intent framework. We don't solve any user wish into a transaction. we rely on the on the wallet to already know exactly what it wants to do. We just bring it the tools

to do it uh seamlessly for the end user. Okay. So we think that actually we work very well as a back end or as you said as the transport layer for the for any uh any solver framework. Okay. And so what's good about EIL? Why did we decided to to work on it? Why did we decide to to introduce it when there are already some kind some type of solutions that overlap at least in terms of functionality with what we do? So EI as we as we uh as we implemented it is private that is communication between

parties are only done on chain. Okay, you don't need to expose anything else to to a third party uh to a third party solver or to any uh to any external service that you that you use. Okay, on all communication is done on chain and no need which is the difference the big difference between a solver and an intent framework for to what we do. No need to reveal user actions on on either chain. that is if a user wants to perform an elaborate swap or buy an an NFD that that is not exposed to the to the liquidity provider that we will introduce here. Okay, he doesn't know any uh any action that the user does except for the crosschain asset transfer that the user explicitly wants to do.

For example, moving 100 USDC from arbitum to base or optimism. Okay, it is trustless because it is self-custodial. The user doesn't rely on any solver to benevolently send him send it the funds on the destination chain if it wants to transfer the funds from the from the source chain to the destination. So it is self-custodial. The user never relies on on such server. Okay. And because of also because of that then because there are no intermediaries it it works very well with censorship resistant proposal such as fossil.

Okay. And the last last but not least it is decentralized as I said no trusted third parties no first bridges it just works okay so how Ethereum feels like today suppose Alice I'll I'll elaborate more on I'll extend what you have already said as an example suppose Alice wants to send 100 USDC on arbitum okay she has 100 USDC on orbit and she knows it okay it is very much she is very much aware ware of the fact that this USC sits on arbitum. Suppose Alice wants to buy an NFT for 90 USDC on optimism. Now what Alice needs to do and that that needs several transaction confirmations and a lot of UIX hurdles

involved. Okay, she she needs to find an arbitum to optimism bridge and unless it is a fast bridge that has its downfalls as well, she needs to go through the full FOD proof window that is 7 days in order to send a message from arbitum to L1 and then from L1 back to back to optimism. Okay, to optimism in order to send an actual message even for the simple asset transfer of 90 USDC from arbitum to optimism. Now the first transaction that she needs to do suppose she find she found a a fast bridge she needs to approve 90 USDC to the bridge that is already the first that Alice needs to do. The second one is an

executing of the bridging and waiting for patiently for the for the benevolent bridge to to also uh relay the the message and release the funds on the destination chain. So what happens if the the fastest breeze is hacked or simply doesn't work malfunctions? Alice loses its funds. Okay. And the same goes and this is another pain point. Okay. The same goes for native ETH for gas pay for gas payment because what if Alice was already only working on arbitum because her wallet supports arbitum mainly and this this is where all her asset assets are. So she needs to do all of that also for native ETH. Okay. And then after all of that, okay, she needs

to go back to the NFT market on optimism and sign the transactions over over there, which is already at least four transactions. And that is a very uh optimistic uh optimistic flow. Now compare that to how EIL feels right now. Okay, the way we implemented it. So Alice uses an EIL enabled wallet that is just an EIL wallet that uses our own SDK and goes through our own EAL contracts on chain that we will see soon. Okay. She has 100 USDC. She doesn't care that it is on orbit room. She doesn't care where it is. Okay. It happens to be on orbit room internally. Okay. And Alice wants to buy an NFT for 90 USDC. Again, she doesn't know and doesn't care that

this NFT marketplace is on optimism. She just clicks one button to sign all of the transaction. confirms once and it just works. That is the goal and that is how it is currently implemented as we'll see. So the first thing about how EIL works I would like to to show you is the entities involved before we dive into the uh to the actual flow I want to show you how uh what entities are involved and explain a bit in order to set up the terminology. Okay. So the first one is the crosschain pay master contract. Okay, which is a pay master in the 437 sense that is a destin on the destination chain. It is uh it is obstructing the gas from the

user. Okay, so in our case because Alice works with 100 USDC and behind the scene the the 100 USDC is only on orbit room and she doesn't happen to have native ETH or USDC on optimism. How would she pay for gas? That is where the crosschain pay master uh gets into gets into play and we'll see in the flow that the crosschain pay master is paying for the gas on the destination chain. So Alice doesn't need to go through all of that also for the native ETH.

Okay. So it is deployed on each chain that is supported by EIL once just like entry point that is a singleton contract. No need for for more than one. Okay. And it acts as an XLP which we I'll elaborate later. This is the crosschain liquidity provider that I'll explain right in this presentation. Okay, it acts as an XLP registry. The crosschain liquidity provider registry and deposit manager. Okay, which handles the deposit both for the liquidity providers and for the users to get on the on the other side on the destination chain. Okay, it acts as as I said as as a payer on the destination chain contract, a pay master in a 437 sense.

Now the second contract involved is the L1 stake manager contract while you can register and liquidity provider and it is permissionless. Okay, anyone can register a liquidity provider still it is it needs to be staked. Now it's worth mentioning that the stake itself is uh uh the ST itself as we will see soon uh is is fixed and it doesn't grow with the amount of liquidity that the stake that the liquidity provider wants to provide. The the third entity that we have is the crosschain liquidity provider as I said that the XLP that is just a very simple server. It listens to event to events on the destination chain on the source chain and and afterwards it just uh it issues the it it accept the the user's

uh request to move fund to transfer funds from the source to the destination. Okay, as this is as I said here. Okay. So what we call okay what we call for the for the user when it when they when Alice wants to deposit 100 USDC or 90 USDC uh in order to uh to withdraw on optimism and she wants to deposit it on uh on arbitum we just call it a voucher request. So so so she requests a voucher in the crosschain payer and the liquidity provider listens to this type of voucher request and issue vouchers that can be redeemed on the destination on the destination chain. Okay, I said anyone can register.

Okay, the last component that we have that is both onchain and offchain is the empowered wallet and smart account that is 457 smart account. Okay. Okay, that's as I mentioned before and that's it. So it's worth noting that while the smart account itself both onchain and offchain uh preferably would have some type of extensions that we that we uh provide as as extension to the to its functionality. These extensions are not mandatory but it they are highly recommended in order to achieve the full UIX that we wanted to uh that we wanted to give the users the end users in order to to uh to uh benefit from EIL completely.

Now, so let's go into the actual flow of how it works. Now, the wallet builds two user operations, one for arbitum and one for optimism. Okay, the these are ERC 457 user operations and I assume that uh many of you already know what 457 looks like. So, it's a very we rely on that heavily in our system. Okay, as I said, the wallet locks 90 USDC deposit on the arbitum a contract that is the crosschain pay master and afterwards the wallet gets as we send we call it a voucher request. The wallet uh the wallet waits for a liquidity provider to

issue a voucher and this uh the liquidity provider that we just mentioned just says the voucher request. There is no communication between the wallet and the liquidity provider outside the blockchain itself. Okay. So it is a very simple server. Okay. Anyone can run it even anyone can develop it from scratch. It's very simple and anyone can run it locally and uh on Google cloud on on Amazon or whatever cloud you're using. Okay. So the last the last part that the wallet does after the it sees that the voucher was issued on the source chain. So Alice wants to send 90 USC from Arbitum. She asks for the voucher on Arbitum and the

liquidity provider provides the voucher on on arbitum as a search chain that can only be redeemable on the destination chain that is optimism. Then the wallet sees this voucher that was signed on on Arbitum. It takes this voucher, appends it to the optimism user operation and sends it and that's it. Okay, it once once the user operation on orbit room is submitted, first the transaction uh first the user operation uh withdraws the funds from the crosschain pay master on optimism releases effectively releases the funds for for the for the transaction and then Alice can can batch inside this user operation the next operations that she wants to do. In our

case, just buy an NFT on optimism. That's it. we left some things out in this flow and one of the things that I wanted to mention here is the how EIL manages gas on the source chain as well because while I said that the cost chain pay master acts as a pay master on the destination chain it pays for the gas for the user transaction. what what can be done on the source chain and this is actually very simple because we are heavily using 437 any pay master that is already out there is deployed and any pay master service can be used to to provide the gas abstraction on the source chain okay now it's worth noting that because

Alice not doesn't necessarily have any any asset on the destination change he might not not have used it any time before then the gas the gas for the the gas cost for the destination is actually being paid on the source chain and she can choose even with what asset she's going to pay it. She can even choose to use uh native ETH on the G on the source chain to to pay for the transaction gas cost and then send USDC 90 USDC from optimis from orbit room to optimism. Now this this enables fully crosschain gas payment. When we talk about uh when we talk about the fragmentation of our of the ecosystem, you can you can do it not only for one source chain and one

destination chain. You can actually batch many source chains and many destination chains and pay for the transaction with any with any token that you want on one source chain as long as there is a pay master that is willing to support the token. Okay. And again that is not our pay master. This is already existing pay masters that are out there for for 457. Okay. On the destination chain is quite simpler. Okay. The the crosschain pay master is is the one uh that is paying for the transaction gas cost and it is being done by appending the voucher to the user of pay master data on the destination chain. The the pay master just checks the uh the voucher is valid because the the liquidity provider is registered both on the source and the

destination chain. It it checks that it has enough solveny have enough deposit and just charges the the liquidity provider for the for the user uh gas cost on the destination chain. Okay, this is the flow as we see it the the main flow that we talked about and we can see it here as the flow diagram that I uh uh that uh I am showing right now and it's basically describing what I already said. The wallet account first prepares the two user ops for the arbit room and optimism just deposit to the orbit room pay master the 90 the 90 USDC that is the voucher request. The liquidity provider listens to this voucher request created events and once

it it sees one it issues a voucher for 90 USDC plus the gas fees that is going to be paid on on optimism. Once the wallet sees that the voucher was issued, it takes the voucher signed from the voucher from from this event and just submits the user on with the voucher on the destination chain. Okay. And it can change it can concatenate as many vouchers that it wants. It can collect as many vouchers that it wants. For example, for more elaborate schemes, if you want for example to to have different type of swaps from source chains to different destination chains and the I think that the major per The major feature in our system in this case is that again we don't we don't provide

any information on what what is actually being done a aside from asking the uh the liquidity for provider for the voucher request. It doesn't know the user action outside of that you can you can uh just uh append batch to the both on the source chain and the destination chain any any generic action that you would like to perform. Okay. So the one thing that we didn't discuss right now is the XLP registration that is the crosschain liquidity provider registration and this one is is very simple. I already mentioned it but I'll repeat it again here. So the way it's being done is the the the liquidity provider decides which chains it wants to support. So it

transacts on L1 stake manager. Okay. It just provides the information all the all the chain information for all the chains that it wants to support once. Okay. and the chain information main it's mostly the chain ID the pay master address that it supports on the on the destination and the source chains and and of course the bridge that it would uh that it would authorize in the case of uh of a dispute resolution that we are not getting into right now but we will discover discover later in the workshop okay now as I mentioned it needs to lock a fixed amount per chain thus this amount is fixed it's not growing with the liquidity providing the the liquidity that is provided by the by

the crosschain liquidity provider and I think that this is also a pain point that we solved that the the staking in the system doesn't doesn't explode when the system grows in liquidity which is which grows much faster than the number of chains the liquidity provider wants to support. Now as as I mentioned this is this acts not only as registration but also as an authorization to for the contracts the pay masters on these chains and the bridge the canonical bridge that it's using to perform operations in the case of the disput. So it acts as an authorization for these contracts to perform the dispute resolutions on L1 in the in the P in the L1 stake manager.

Okay. So L1 once it gets the transaction it broadcast the the LP information the liquidity provider information to all to all EIL payers through the canonical bridge because it's uh it's a transaction from L1 to L2. There is no fraud proof window. It happens immediately and that's it. Now the XP is ready to is ready to listen to events and is allowed to issue vouchers and participate in the network and that's it. Now, so we touched briefly as as you have mentioned before what wallet extensions we want and as as I said these wallet extensions are not mandatory but they are highly recommended in order to support the full flow that is signing once on all chains getting the full gas abstraction and uh

supporting the full EIL experience as we mentioned compared to the current fragmented networks that we have on all chains. So the first one is 50 5792 extension that is wallet calls API. If if you if anyone here is a wallet developer they are probably aware of the wallet send calls API that is the abstracted layer in the wallet for the for for for DAPs to allow you to allow ds to uh to send multiple actions for for the wallet to uh to perform on whatever chain that they are using. So we are extending uh wallet call capabilities specifically for EIL that is a natural uh extension for that. The

the second one that sounds very elaborate but it's really not is smart account runtime parameter resolution which namely means that what if you don't know how much value you want to move from the source chain to the destination chain. Okay. What if you want to perform a swap then take the resulting of the swap the resulting amount of the swap and then move that to the destination chain. we also support that but the smart account needs to uh uh to also extend this uh uh uh this functionality with what we already provide. So we have this functionality implemented for the smart account to uh module to uh to install but uh this is mainly if you again if it wants to support dynamic uh dynamic values like that okay uh this is what I mentioned

now the the third one is the multi-chain user operation hashion signature because if you if the if the smart account isn't using that one then it means that it needs to sign repeatedly for every action that it that it does on every Okay, interoperable addresses you have mentioned before and advanced topics for the workshop as I mentioned. Okay, that is okay. The runtime parameter resolution we will mention in the workshop. Okay, what if we don't talk the exact amount the session data that we didn't mention here out of time and the dispute mechanism we'll dive into that a little bit more. What happens if the the liquidity provider is is insolvent? What happens in case of a

chain reorg? what happens in case of civil attacks against the liquidity provider and how we handle that part. Now running an XLP also we're going to show uh briefly in the in the workshop because it's actually very easy to run an XLP in the system. Okay. And last but not least is the the liquidity prior discovery and selection that is done from the client side. Okay. In our SDK how it's how it works. Okay. And that's it. What's next for for AIL? Okay. is just the SDK is already public. Okay, we are working live on multiple uh test nets in Solia and thanks to de to tenderly team we are live with DevNet that is designed for uh for the Echaton right now and we have a world

interaction live thanks to Empire and last we have the bundlers live uh the ERC 437 bunders that support uh that support uh the the 09 entry point version thanks to spot. Um that's it. Just get in touch with us. >> Thank you so much, Shah. And we don't unfortunately have time for Q&A today. There were a lot of really good questions. Uh we do have a fivem minute coffee break coming out to the uh outside to the right. So feel free to ask any of the team questions during that time. There's also the account abstraction hub uh which is in the building over down there to the left.

Um, but we'll regroup back here at 11:10. So, feel free to go outside, get some coffee, stretch your legs, and we'll be right back. Thank you so much. >> Thank you. Thank you everyone. And we're happy for to hear from you. You can connect us on GitHub, Discord, and come ask us questions. That's it. >> Thank you.