The Access Layer - Oskar Thoren

Transcript

Right. Everyone, hey, my name is Oscar. I'm going to talk to you today about the access layer. So, what is access layer? It's basically where crops meets end users. And some of you might be familiar with crops. If you have information recently released a mandate where they talk about these properties, like sensor resistance, open source, privacy and security. And I would say it's something that the Ethereum ecosystem has always cared about. But what's new, I guess, is making it is like a little bit more explicit and being more rigorous about it in terms of like what type of initiatives we care about and so on.

So, sensor resistance, the fact that you can't sort of sensor valid use and selectively block things. Open source and free, so sort of not having open source code bases and license says and sort of no hidden specifications. Privacy, not sort of exposing any any user data beyond what is actually needed. And security, the fact that systems actually do what they claim to do, no more, no less. And I guess the one point I want to make here is that the protocol on its own in the base layer can be decentralized while the user path is stay centralized. So, just because you get certain properties on the protocol layer, it doesn't mean that actually you get the same properties for end users.

So, one way of thinking about access layer is kind of the user-facing path to Ethereum. So, that has sort of things like wallets, RPCs, front ends, how you do things like identity, delegation, and exiting from various protocols and L2s and so on. And the point here is kind of to to share this and this kind of framework about thinking about things. And if you're building something that touches on users, sort of asking yourself like do you actually get the protocol guarantees at the user layer as well. So, before diving into some examples, I want to talk a little bit about the gap and of where we are and where we need to go.

So, the failure kind of happens before we even reach sort of the protocol and protocol guarantees. So, to illustrate that, let's walk through Alice's afternoon. So, she starts by maybe she's using some privacy protocol and she's checking a private balance. Uh but just because the privacy protocol is designed correctly and all of these things, it doesn't mean that you're not leaking any information because she's probably using some kind of RPC and by doing so so you will leak metadata and so on. Uh if she's signing a transaction, uh often times the signing screen hides a lot of important information. So, uh it's not always obvious what you're signing and that can lead to like a lot of security issues, right?

Uh maybe she's proving some eligibility to some system, some kind of KYC process or whatnot. And often times these systems they rely on taking on too much data or even to the extent that they're using maybe CKID systems. There's a lot of problems when it comes to linkability or kind of uh tying their action to other things they're doing as well. So, you sort of end up over disclosing beyond what is absolutely critical necessary. Uh and then maybe she tries to exit from an L2 or some DeFi protocol or whatnot, but it turns out that in a lot of cases the operator still matters. So, it's possible for the operator to censor, whether that's because they have gone rogue or they've gone hacked or they've been pressured from by some nation-state or so on.

So, the point here is not that Ethereum is broken, but that users are experiencing Ethereum through a supply chain and that's kind of what what matters. So, what does this supply chain look like? So, you can look at it through like a few different layers. So, one is the user environment, another is access path, and then the third is sort of inclusion and recovery. So, user environment today usually use some device like a laptop or smartphone. You have some operating system, networking stack, and then you have some browser application. Uh and then when it comes to actually accessing something, you you have like a front end and then some wallet and you do some RPC connections and that then hits the smart contract.

And then when it comes to transaction inclusion and recovery and so on, there's obviously things like mem pools and builders and sequencers that deal with sort of recovery and exit. Uh in the near future, and this is already happening today, what ends up happening is that a lot of people use uh LLMs and that's kind of the new um intermediate layer if you will. So, instead of using a browser app or instead of using a a front end, you might use uh an LLM and then you might use an agent to talk to your wallet for you. Uh and each of these layers can sort of centralize the user path even if the protocol itself remains decentralized.

Uh so, this is a big problem in terms of if LLMs become the sort of composition layer, if you're relying on centralized LLMs or they are relying in turn on like certain RPCs and so on, you don't actually get the security guarantees that we want. So, the protocol is is credibly neutral, but that doesn't mean that you have a sort of neutral supply chain. So, what do I mean by by access layer? What counts as it? It's basically this user boundary, right? So, everything between protocol guarantees and and sort of the user's actual path towards using Ethereum. Uh so, that means user-facing paths like wallets or RPCs and light clients they use. Uh it means like front ends. And also means various type of powers they might have. So, whether it's like taking their identity or

credentials and using those. Uh delegation you might do to a like a smart account wallet or agents. Uh as well as like L2 exits and how you recover your funds and so on. So, it's it's basically where protocol guarantees meet end users. And kind of output here, I don't think you it's not just about like better UX or product and so on because you actually want to be able to be rigorous and sure about these guarantees. So, that's why you need things like protocol specifications to have like clear threat models, you need audited libraries, you need these like reference paths for sort of how to do certain things as well as conformance tests, and so on. And this is kind of what makes these claims checkable and not just like promises.

Uh so, right now the user path is still centralized and the protocol is not the whole path. Um so, Ethereum has has mostly answered "Can the protocol be censored?" There's obviously still a lot of work to be done and we saw that in the two presentations ago in terms of the road map that there's things going on when it comes to fossil and also like base layer privacy. But, in general, the protocol has a lot sort of more security properties than everything that's built on top of it. So, in general, I would say that we have not answered "Can a user be censored at like the access layer uh boundary?"

Uh and you see this show up a lot with like hosted RPCs or the fact that you have mutable frontends and hacks around that, like opaque signing, like weak delegation to agents, and like unclear exits from L2. So, I guess the question here is like, can a user actually get these protocol guarantees? Like, how how much how much closer can we get to the guarantees that the protocol layer have for normal end users? So, let's break this down a little bit more, uh look at five things that users actually do. Um so, read, write, prove, delegate, and exit. So, they're reading uh from from a from a chain or reading some kind of state and usually this is not a passive thing cuz you actually have to, you know, use some RPC or whatnot. You're writing to the chain,

whether that's transactions or something else. Uh there's also proving, so you might uh maybe make some proofs around your identity or if you do some private transactions, you create a proof and then you put it on chain. And you often want to delegate something, so maybe if it's like uh uh social key recovery or some smart account abstraction or maybe you're delegating to an agent to do something for you, and so on. So, you want to have rich semantics around that. And then also exit, so maybe you want to exit some L2 or you want to exit uh some DeFi protocol or whatnot. And for each of these kind of fundamental actions, there's a few things we can check. So, first of all, is like a good path available? So, is it even possible to get these kind of crops properties that we care about?

And second of all, is it legible? So, is it something that that a normal user can actually see what they trust and what they reveal and what they authorize and what they verify? And then finally, survivability. So, does this still work if a provider fails or they censor or they just walk away? And if any of these kind of claims fails, then you don't actually have this as a systemic property in a supply chain. So, the missing work here is basically whatever closes one of these gaps. So, let's look at these like five verbs as kind of failure modes and then for each verb, seeing what breaks, what exists today, and what is needed for this to become sort of a more reliable system.

So, when it comes to reads, key question is like, can users see Ethereum use read Ethereum state without revealing themselves to a gatekeeper? And there's a lot of things here that breaks like when you do RPC queries, you can sort of see these and then you can also link addresses and so on or if you use something like Etherscan, this is a big problem. Front ends also shape what users see. So, a lot of front ends now, they're not verifiable. So, you see a lot of attacks related to this where you think a certain front end is something but it turns out it's not.

And when we talk about private apps and like privacy preserving transfers, it also needs things like private reads because just because you have a smart contract that's privacy preserving doesn't mean that the wallet interaction is is private because of metadata leakage and so on. There's a bunch of current work that's that's going in this direction. So, light clients for example, portal network and Helios sort of help verifying state so you know that the state that you get from some RPC provider is actually authentic. Also things like private queries. So, there's a PIR, private information retrieval research, which basically allows you to ask a larger database and then uh without revealing what specific piece of information you need and just getting

that from it. And there's also work when it comes to front-end integrity, so verifiable front-ends and so on. There's a bunch of things that are missing here, so like having some kind of defaults for wallets when it comes to these kind of privacy-preserving or trust-minimizing reads. Uh as well as sort of visible trust in RPCs and and front-end path. Sort of having that baked into more wallets and and and uh RPC providers. When it comes to the rights, so can users get a valid transaction included and and actually know what they are signing? Uh there's there's many things here that breaks uh when it comes to especially like censorship resistance and privacy.

Um and I guess one question is like will it get included in first place and did the user offer us the right right thing? Um there's a lot of problems here for example with the transaction path often is leak leaking some kind of intent. Uh when we look about the relayers and builders and sequencers, they can filter transactions. Uh and wallets can't always explain sort of the effects uh or authority and so on. There's a bunch of different work uh not going going to too much detail here, but we touch on like fossil inclusion lists if you like the previous talk or two talks ago. Uh encrypted mempools, clear signing and and sort of assertions around transactions.

Um and in general we want to behave sort of these uh inclusion paths that a user can fall into so they can always guarantee that their transactions get included. And then also having signing that actually exposes all of the effects of of signing and sort of the authority you give to some interaction. In general sort of safer transaction semantics across different applications. Uh when it comes to proving uh like users want to be able to prove something without exposing any of the rest of themselves, right? Um and this is not like a lack of proving systems or anything like this. It's very much a problem of like fragmentation at the user boundary.

So, there's a lot of things that break here. Uh, there's a lot of credentials floating around, but they don't really compose. Uh, the default is still that you have sort of over-disclosure when you interact with various systems. Uh, and when you look at things like nullifiers and and how you deal with revocation of various credentials, it's kind of very fragmented and people invent their own way of doing things. Um, PNC has done a lot of work here when it comes to for example membership and voting as well as web and email uh, provenance with things like CK email and TLS notary and so on. Uh, there's also been some work on CK ID systems with open AC, so open anonymous credentials, which gives you unlinkability.

And there will be a talk uh, tomorrow if you're interested in checking this out, uh, which will also go into how you might get like human verification in online forums. Um, also things like Mo Pro, which is like a client-side proving uh, library uh, because at the end of the day if you want to have guarantees for end users for private transactions, you need to actually create those proofs from where the device is sits and often times that's the that's the mobile phone or browser. There's lots of things that are missing here so kind of like these wallet native proving flows. Uh, there's some work in that direction, but in general it's not something that there there are good standards for.

Um, there are no like shared nullifier or revocation patterns, either. Uh, and general sort of users understanding what they trust and what they like who they trust and what they actually reveal when they're approving something. When it comes to delegation, so can users delegate power without actually losing control of of their keys? Um, there's a bunch of work in this direction, so 7702 makes of smart account behavior available to externally owned accounts, which is definitely UX win. Um, but permissions are still very much fragmented and and users can't it's kind of hard to reason about like uh reading or revoking authority in like a in a sane way.

Um there's a bunch of work in this direction so smart account wallets, uh various ERCs related to permissions, making them more sort of legible, uh and also other type of like revocation patterns and so on. Um there's still things that are missing here so like for example wallet readable permissions like if you do some kind of uh delegation, you should be able to understand what do you delegating, what are the conditions, and and what's the worst case scenario? And the same thing for like revocation paths so if you have delegated something, how do you revoke that? And then having some kind of uh security assurances around that.

Uh and generally like a shared policy language for apps and agents. When it comes to exit, so can users leave without the operator uh cooperating? So there's like a lot of for example L2 beats has these stages um and that's great. That's definitely a great start like if it's a stage one, stage two, and so on, but it doesn't answer sort of the whole user user question. Uh things like force inclusion is still uneven and it's hard to reason about upgrade powers for L2s for example. Um and here something that's missing is some kind of like exit conformance so being able to like know under what conditions you can exit and how that looks for different systems you enter.

Uh and ideally this should be this should be readable in a wallet so whenever you enter an L2 or enter some kind of protocol, you should understand what are the risks you're taking and what's the worst case scenario in terms of you getting your funds back out. Uh so I'm going through a bunch of different things. I just want to talk a little bit about things that we want to ship here. Um so one thing here is that these Ethereums promises, they should be checkable. Like these are this is like not a marketing world. It's not like oh this is the first decentralized X or privacy preserving X or whatever. It's not a marketing thing. It should be something that you can actually trust and you can expect and have rigorous guarantees on, just like we have at the protocol layer.

So, a working access layer uh should ship things like uh specifications with clear like threat models, uh audited libraries that you can you can know you have some guarantees around the security, uh reference implementation, conformance tests, and benchmarks, and so on. And the point here is that uh this is like a ecosystem effort and user-facing systems should be able to sort of prove what they claim. So, we sort of move beyond this kind of marketing thing and actually having uh a stronger supply chain for everyone. To make this like a little bit more concrete cuz some of these things might sound a little bit abstract. There's all these standards and stuff. I just want to mention Quaku. Uh so, Quaku is this like experimental wallet and it's basically like an early

reference path. Uh it is not the whole access layer, uh but it what it what it has is it has kind of provides this SDK for wallet privacy patterns. So, how showing sort of what's possible in terms of private reads and queries, uh how you do things like sealed transactions, uh how you do account and app isolation, and all the all of these things. And the goal is basically to to create these reusable pieces for other wallets. And I want to point out here that if someone is developing a wallet or something, it's hard enough to sort of get product market fit, and a lot of this technology is very experimental.

So, it's maybe not the most natural thing to sort of start to use all of this experimental technology while you have a lot of other problems to deal with. So, what Quaku's doing is trying to sort of derisk this a little bit for other app developers and showing what is possible. So, sort of leading by example and then making it easier for other wallets to sort of integrate the work and and showing how we can sort of get uh a more secure access layer. Another one thing I want to talk about is agents as users and uh for many this is already becoming like the default where agent is kind of integration layer. And this is not sci-fi. Um we already have a lot of people and sort of agents connecting prompts to wallets or RPCs and so on.

And they will continue to grow over the next few years. Um And the problem here is that if the defaults ends up with like hosted RPCs or centralized wallet flows, uh that's that becomes like a problem. Becomes like a centralizing vector, right? Um and you don't get these properties uh just by default. And it might be not even be something that the user is aware of cuz they just download some skill and they run it through Sorry. They run it through a cloud and they don't actually understand the implications. So, we have an opportunity to sort of create these safer defaults.

But to do that, we need to have things like machine-readable safety rules and also things like signing flows that don't expose keys. So, you don't just end up sticking your your hot wallet and giving it to an agent and whatnot. But basically figure out ways that we can make these crops properties uh more secure as defaults when we talk to agents and so on. And thinking about this uh ahead of time. Another thing I want to mention is this idea of like natural allies. Um So, Ethereum obviously didn't invent self-sovereignty. It has a very long tradition going back to Bitcoin and then before that the Cypherpunk movement and then even further back. Uh also different groups that sort of deal with this in slightly different ways. Whether

it's like technology first or maybe it's more about civil liberties and so on. Um but there's like a lot of natural allies in this world, especially outside of the crypto space. Um And they also care about these properties. They also care about censor resistance and and privacy and security and sovereignty and so on. And and often times they already serve users who who need, for example, private communication or uh resilient publishing, secure devices, uh or some kind of like coordination mechanism under some uh pressure. Um so, it makes a lot of sense to see how Ethereum can help these these groups and how we can have sort of symbiosis between these different ecosystems, especially when they don't always talk to each other.

So, examples of this is like secure communication, for example, Signal and Tor, integrating that. Um There's also high-risk publishing, so things like SecureDrop for whistleblowing and Freedom of the Press Foundation, uh hardened user environments like GrapheneOS, um as well as sort of non-tech organizations and products which are more like on the civil society NGO side. So, that can be anything from like digital rights groups or humanitarian orgs or local resilience networks. And none of these like formal relationships, it's just like generally this idea of not just staying in the crypto space, but going to these natural allies and finding people who actually need the properties that Ethereum uh provides.

So, sort of how how how do you think about how this connects? So, access layer is basically like this ecosystem surface, everything between a protocol and user. Uh what EF can help with is making the surface a little bit more legible and sort of naming the gaps and and convening builders and supporting these kind of shared artifacts. Uh and then this is basically like an an ecosystem question in terms of shipping and adopting these paths, so whether it's like wallets, RPCs, L2s, identity, or these kind of agent uh solutions. Um a lot of this also feeds back into protocol work. Uh there's obviously a lot of work that has to be done there, whether like fossil or encrypted mempools, native account abstraction, or confidential state. So, there's always more work to be done at other layers of the stack as well.

Uh so, right now we have a lot of promises, but we don't necessarily have these properties, especially for normal end users, and the user boundary is actually a real test in terms of if we have these properties for end users. So, if users can't read, write, prove, delegate, and exit with these uh crops properties in mind, then uh if you have guarantees remain just promises. And we want to make sure that all of these paths are available, so it's actually something that is possible uh in a technological sense uh and consumable. It also needs to be legible, so people normal humans need to understand what they are verifying uh what they're using, what they're trusting. And then it also needs to survive pressure, whether that's like

someone walking away or there's some kind of pressure from a nation state or whatnot. Um so hopefully we can all build towards that together and move from promises to actual properties. Uh that's it for me. Any questions?