[trustless://eil] Marissa Posner - Trustlessness Is The Standard: The Ethereum Interop Layer

Transcript

Wonderful. Um, next up we have somebody that I'm a big fan of, Marissa Pausner, talking about trustlessness is the standard. Big round of applause. Oh, I need the clicker. I need the clicker. Can I get the clicker? Thank you. Hey guys, what's up? Um, it's great to see you. So, you guys may have noticed some of the branding that we have kind of this whole Y2K 2000s theme and this all relates to um, EIL kind of being

this uh, interop layer that is the new like HTTP. Um, wait, let me go back one. So today I'm going to talk about trustlessness is the standard um and kind of how does EIL fit with these interop standards that we currently have. So first I want to talk about why these standards mattered and like in Ethereum we often talk about trust in this as if it's something that you like put into a system after the fact but what we're saying with EIL that no it's the base layer real trust this is in the structure it's in the intention and without standards each rollup kind of becomes its own island and its own isolated framework it has its own RPC

assumptions its own bridge AI by all of those complex things. And so in order to kind of unify these chains and to make things work across chains, we need shared standards. So currently Ethereum has a discoverability problem. And Ethereum has is scaling through L2s, but the issue is that we have fragmented UX. And so I know you guys have all had to switch chains in your wallets. It's annoying, right? So when we add more chains, we get more friction. Um if you want to use like arbitum or optimum or base, you need a separate wallet um balance on each. And if you don't have

the right gas token, you're stuck and you can't move your assets. You have to manually bridge, which is often slow and expensive. Um so bridges kind of feel like these web two custodians that you kind of have to just like click, pray that your money gets to the other side, and just wait. Um, and so if a bridge censors you, you're stuck and you can't move your funds. So another like thing I think to think about is that every time like a new rollup launches, um, wallets basically have to manually integrate it. They have to do a lot of work to support a new chain. Um, and it this does not scale. And if we're thinking about the L2 scaling road map, um, as something like longer term with a very long tale of chains, this is not sustainable. So,

um, currently like discoverability feels broken because like addresses don't carry any routing information. It's just a 0x address and it's kind of like a phone number without a country code. Which leads me to my next analogy. So, currently every L2 is like a different country's phone system. So you need the right area code or chain ID, uh a telecom provider or RPC, and you often have to register a new SIM or a wallet. Uh so just like the internet removed complexity from phone numbers where you don't need to know country codes, carrier routing or prefixes. You basically just have to dial the number

and the system takes care of it. So just like this and how we don't have to know all of those routing numbers today, uh users shouldn't have to know which chain that they're transacting on. Um so like I shouldn't have to manually configure my wallet. So with chain specific addresses like bob atbaseeth, um wallets can resolve the destination, in this case base, fetch the RPC um and handle all of the crosschain execution seamlessly. So I as Alice could just go in and paste bother baseeth and my wallet is going to figure all of this out and send money to the correct address. So chain specific addresses remove friction. They make chains feel

invisible to the users and they are one part of the standards that we need um in order to have better interoperability across chains. Um so this so ERC7828 is the chain specific address standard. Um it basically defines like the format needed for resolving like both user awareness and wallet awareness. Um and like currently like it starts by defining um like uh all of this in um using with a 20 byt style EOA. Um, one other thing to note actually is that with this we also can have something called onchain config using ENS um,

which is ERC7785. Um, why we started thinking about this is how do wallets learn about chains without manual configuration. So I write this Bob at base.eth, right? But how does my wallet actually figure out like what is base? Currently wallets have to use hard-coded chain lists. they need manual user setup for new L2s. And this just doesn't scale with the amount of L2s that we have. Um, the wallet has to know what's the bridge, what's the RPC, what's the light client contract, which is something I'm going to get to in a minute. Um, and if that information sits in Typescript, the user is basically trusting the developer. So, ERC7785 moves all of this onchain. Um, and this

is removes one of the biggest sources of invisible trust. uh creep. Um so basically what 7785 is it's you can kind of think of it as an onchain phone book. Um so like for rollup so it stores like these canonical addresses and metadata so that wallets and infra can basically just fetch one record like this onchain config and everything else kind of sits in beneath it. It's kind of like an array of data you can think of it. Um so this standard is currently we're still thinking about it. We don't have the standard fully developed. Um we need another like um ERC and to agree with like the L2s about what will be in it.

Uh which brings me to um another thing we need a standardized bridge uh API. If you guys have ever looked at the bridge APIs of different chains, you will see that they are all very different. Every L2 has its own deposit API. For example, this is an example of arbitrums and optimisms. And you can see that they're different. So standardizing this is not just a convenience but it's something that is needed in order to basically move assets crosschain better. So if I have this unified wrapper around these like specific APIs, I can then follow like one verified interface like I as the wallet can follow one verified interface and I don't need to customize

everything to each specific chain. So this is like one of the things that we need in order to kind of move interrupt forward. Earlier I mentioned light clients. I don't know if you guys know but currently users like we rely on our RPCs like crazy. We don't check if the information that they give us is true at all. Like we just query a centralized RPC provider like infura to get the data and like just trust that what they tell us is true and hope like I don't know. Um so there's a solution to this and that is like clients for L2 verification. So a Lite client doesn't store like the full blockchain state but it can kind of verify these proofs in an efficient manner. Um so you don't have to depend on like an ETH proof uh RPC

call. Um and you can now verify with using this like client contract that the data that you got back from the RPC provider is true. Um, so if every wallet like had this built in, then my wallet could be verifying onchain state um without having to rely on an RBC. So this is like one of the things I don't know if you saw, but this week we put out the trustless manifesto and in it we talked a lot about trustlessness and what that means. And one of the steps that we like think that builders um and wallets can do today is implementing light client contracts. Um and Helios already is an example of one that does this for OP chains already. Um so like the goal is that wallet should be able

to independently verify L2 state without trusting an RPC. Um so another such standard that I wanted to talk about is that how like I guess L2s currently rely a lot on off-chain sources RPCs bridges multi-igs instead of Ethereum itself and so Ethereum L1 is this source of truth but L2s basically are asking these third parties for the data and currently verifying on L1 is very uh verifying L1 on an L2 is very expensive today. So basically currently I need like a Merkel proof and like I have to build this tree and then I have to pass along proof and do a lot of hashing and it's it's it gets very like gas cost gets very high.

So we have L1S load and so L1S load basically lets L2 smart contracts read L1 storage directly without Merkel proofs which makes L1 verification cheap and so what L1S load enables is key stores. So um you get key stores for multi-chain accounts. So like I could you know when I have accounts across different chains I have all these different wallets and it's really hard to like manage my keys crosschain and so that's where key stores come in. Um and tomorrow we actually have a presentation on key stores um from one such company that's building in the space at our conference tomorrow. So if you're interested you should come check that out. Um but what keys stores enable is basically if a user rotates their key on

um on the L1 then all of the L2s instantly recognize it. Um so without this shared key store on the L1 keys will diverge across L2s and then multi-chain accounts break which like we need for interop. So using L1S load and um like key stores we basically get uh better more trustless interop and safer key management. So you heard about EIL. I'm not going to go into it at length, but I will I will just say that um in in a sentence, EIL basically makes Ethereum feel like one chain again. Um it is a cross-chain interop protocol. And so today we have seen how you know Cloudflare is down.

We've seen how supposedly decentralized servers depend um on centralized servers. Arbiscan was down. Ti Llama was down. These are web three tools that were taken out by a web two outage. And what does that say about us building in the space when tools that we've built end up going down? And just because so like your when your front end depends on a centralized server, your system is not trustless. And if someone hacks the server with UI, they don't need to hack Ethereum. Like you could you can still lose your assets if your front end is hacked. Um, and I really think like the danger with trust is that no one's showing up with a sign that says I'm the weak point like I'm I'm trusted. It it

sneaks in quietly through these little design choices. Um, so previously we talked about standards which tell the wallet where to send things. Now we must protect what it sends. And the user's intent is the most sensitive object in the system. So I'm going to ask Brit to come up on stage. Um and I just want to say so at this point like the standards that we've discussed give the wallet like everything we need. How to find um chains, how to verify chains, um how to bridge and how to identify the user. So we have these rails. So the next question is is what actually happens to the user's intention when it's traveling on those rails? Who gets to see inside

it? Who gets the pre-nowledge? And who can interfere? So I have this envelope and on the front it says users intention. So no one here has seen it and this envelope represents what I want to do crosschain. It's the real call that I want to do. So I'm going to hand this to Britt. Britt is my solver for the sake of the example. So Brit, I want you to open the envelope and show everyone what's inside.

Yeah, that side of it has it on. So, what it says on the envelope is that I want to swap 100 USDC to ETH on arbitum and then I want to send that ETH to my friend on base Bob atbase.eth. So, what this means is that the solver Brit while she's carrying my intention while she's taking it across chain from ETH to arbitrum, she knows exactly who my friend is. She knows my swap. She knows my route. She knows everything about what I want to do. So now Britt can frontr run me. She can censor me.

She can refuse the transfer. And in solverbased systems, the solver has to know everything up front because they're the one executing the transaction. And at the moment that we've opened the envelope, we've reintroduced the entire surface area of trust. front running my IP correlation to where I am and censorship that Ethereum was designed to eliminate. So, thank you so much, Brett. I'm going to put this envelope to the side. And now I want to talk about what happens in the case of EIL. So, in EIL, the innovation in EIL is basically that the user is always the executor. It's always the one in charge of the transactions. They sign the user signs and submits each call themselves.

And the multi-chain account model is built on 437 is the thing that makes this possible. So I have this envelope which represents uh the user in EIL. So it is open. I would like to show you guys firstly that it is empty on the inside. There's nothing inside. Written on the corner up here is the fee 0.02 USDC. It doesn't have to be an ETH because 437 makes that possible. And then I have my two two base. I want to send two base and I want to send 100 USDC.

I don't have my friend's name. I don't have my route. I don't have what I want to do with it. So in what liquidity providers see is what is on the cover. They don't see why they return it to you. And their job the liquidity provider's job and this differs from solver. The liquidity provider's job is basically to put the right amount in the envelope um and return it to me. After that, their role is over. So I give this to the liquidity provider, they put the right amount in and they give it back to me. And only after do I add the message, the actual intent and send it directly to the chain. So the liquidity provider once I add my message inside this and send it to my chain the LP has never

seen my like the message inside and the system now doesn't need to know the user's intention. The full call is basically only revealed when the user's multi-chain account executes it on the destination chain and it's never revealed before. This is the separation between movement between value movement and intention. Yes, bus. So, that's the envelope story. Now, I just want to talk to you a bit about what the trust model actually feels like as a user. It's the difference between taking the bus versus driving your car. The difference between systems that protect you and systems that just expect you to pray that nothing goes wrong. So, buying using an

intent is like buying a bus ticket. You commit, the relayer gets the funds and the call data and often your IP address and executes on your behalf. I buy a bus ticket from Buenoseras to Patagonia and now the bus driver or the relayer can delay me, reroute me, censor me or even stop in the middle and make me get off on the side of the road. It's not adversarial theory, but that is just the trust model that we that it operate under. And to contrast that with EIL, EIL is me driving my own car and buying gas from a gas station. So the gas station or the liquidity provider in EIL's case is just is just the gas station. They either fill fill up my

tank and and and give me the gas or they don't. So they either fill my envelope with the right amount or nothing happens at all. The the LP knows that I bought gas, but they don't know where I'm going. They don't know that I'm going to from Buenos to Patagonia. Um so they don't know my intent. And once I've purchased that gas, they have no influence over where I can go. I I could drive to Chile. I could drive to wherever I want if I wanted to. Um the bus has to read your intention to drive you. Otherwise, it doesn't know where to stop or get off. But the gas station never does. And that is explicit in the model. Um which means that the envelope stays sealed and the chain um until the

chain itself opens it. So if the envelope stays sealed, Ethereum stays trustless. Standards are what let us deliver the envelope correctly, what let us get information from point A to point B. EIL is what ensures that the envelope stays sealed until the chain opens it. If we let intermediaries read intention, we lose Ethereum's trustless guarantees. Um, trustlessness, it's it's a feature. It's it it's not just a feature. Sorry. Trust is not just a feature. It is the point. It is the thing itself.

So I just want to end on a note. This week we came out with the trust manifesto co-authored with Vitalic. And in it we talked a lot about these guarantees and why it's so important to build systems that have that are trustless and um have Ethereum guarantees. So if you guys also believe in trustlessness, I encourage you to put that belief on chain and sign the manifesto. Thank you.