[trustless://eil] Fireside Chat - The Trustless Manifesto

Transcript

question. >> Um, so welcome everybody to this panel about the trustless manifesto which is on the floor there. So, uh, with us we have, uh, people that, well, I think Vitalik needs no introduction and I would say that Marissa and Yav are on the account and chain abstraction team at the EF working together with me on account abstraction, chain abstraction, EIL, all those interesting things. So um a couple of u a couple of days ago about a week ago I would say the trustless manifesto was published and I think it uh stirred up some conversation and that's why we're all here to kind of

like continue this conversation and see what more we can expand on this. So the manifesto itself starts with uh the danger of drift towards trust and intermediaries and I would ask like what moment or trend made you feel like this message need to be written now? What was the trigger? Yeah, I think when we were thinking about it, one of the things that we we were seeing in the industry um specifically we were looking at the interop side of things and we were seeing a lot of cases where the user was basically giving control of their funds letting letting a intermediary know their intention and we thought hm why is this the case like this doesn't have to be the case and so we thought about

really reinforcing some of the principles of Ethereum why are there all these interop solutions that don't abide or that don't maybe that don't enhance Ethereum's values. And so we were we were thinking about this and we saw the landscape and we saw that people there were a lot of trust assumptions not just in interop but in RPCs. People trust RPCs all the time. No one is verifying their data. Um one of like we're thinking a lot about new interop standards to help um improve uh trustlessness across the board um and verification. So we were just we were seeing all of these things happen. And like Tom alluded to, trust it's a drift.

It is not a mal inention set out from the beginning but it happens slowly over time and so we were seeing that whether that was from RPCs interop frontends today arbitiscan was down because cloudflare was down there all of these web 3 frontends that actually really rely on web 2 backends. Um, yeah, I I pretty much agree. We saw a very good demonstration today about the risks of uh trusting in a centralized way on an entity. And another thing, a very strong sentence that was said in the manifesto, which I wholeheartedly agree with, is that trustlessness is the thing itself. So, can maybe each one of you briefly define

what trustlessness means to you personally? Okay, that's so um uh to define trustlessness, I first have to refer to how I define trust. And one way to think about uh about trust, you trust someone who can hurt you. If someone can't hurt you in any way, you are not really trusting them. They can't do anything to you. So with that in mind, being trustlessness is about not putting yourself in a position where they can hurt you. And we have so many examples of that uh in the uh uh in this uh space like for example the the dependence on RPC and all of these these are all good demonstrations of someone actually can

hurt you. They can lie to you about your balance or anything of that sort. We try to remove all of these cases where someone can hurt you. >> No, I feel like I like uh gave my presentation just now and I think I ended up saying the exact same thing. Yeah. >> Uh yeah, same. >> Okay, moving on. So, um I I want to talk a little bit about L2s. So, Ethereum road Ethereum's road map, you know, in order to scale, it depends increasingly on L2s. How does this rise of rollups change the urgency of of you know, addressing and defining trustlessness?

>> Yeah, I think so. With these roll-ups, you have this long tale of chains that are like firstly not discoverable to the user or maybe not discoverable to the wallet, I would say. Um, so you need all these standards around interop and how you can um like access and use more uh chains at scale. So you need things like um light client contracts, onchain configs, uh standardized bridge wrappers to kind of create this um easier way to access this long tail of chains. And when you have more chains, you have more places for there to be trust assumptions. You have more attack vector surface that you then need to think about because not every ch like not every chain is I guess designed the same and some may rely on other things. So I

think like thinking about this as the number of chains grows, the more important it is for like the the base layer like Ethereum to to stay trustless to stay trustless. I think of it as kind of a pyramid. If Ethereum is like the base and if Ethereum is not trustless then nothing that is built on top of it can be because you can always you can always build trust on top of trustlessness but you can never build trustlessness on top of trust. >> So building on a little bit on top of that on you know how this whole concept of trustlessness has now trusted elements inside. One of the things that uh we talk a lot about is the role of

decentralization but the manifesto suggests the real risk is the access layer like sequencers, RPCs, relayers, solvers. Which of these do you think is drifting fastest towards centralized defaults? >> Okay. Okay. So, um yeah, I mean they're all they're all drifting but some of them have been doing it for a while. So you know like RPCs or and for some of them we are seeing we are seeing at least a direct for for improvement whereas in others we do not. So for example sequencers there is progress in decentralizing them although right now most rollups are single sequencer with RPCs we can fix it with light client and it's been going slow but it's going now

with relayers or with solvers it's going in the other direction. It's actually uh we are not seeing a process where the situation is improving but instead uh it gets uh I mean the competition is mainly on a price between them. So if you can do something cheaper by for example not verifying things on chain then this is what most users will choose because it's cheaper. So that's where we see the most drift in my opinion. >> Okay. Um so going back to the manifesto there were three laws of trustlessness defined there. No secrets, no indispensable intermediaries and no unverifiable

outcomes. And so I would ask and VidC maybe I'll point this one to you. If you could force one change across the entire ecosystem tomorrow that would best align with these three laws, what would it be? I actually have a somewhat kind of oblique um answer in that uh I would love to see like DAP UIs replace as much of their centralized stuff as possible with the RPC. And uh the reason why I say this is because it's not going to solve the problem today, but what it does do is that the RPC is one thing and it's one target and it's one target that we can improve, right? Because if you set up

something that talks to the RPC then if you as a user have a local phone node which with Glamsterdam will be much will become uh like much more viable then you can immediately replace the RPC with that. If any of this you know and row o or even better the p stuff to do trustless reads actually works then you can immediately apply it right and so like basic like I think in general in computer science there's this common pattern where like if you can force a problem into a standardized container then like you can have a lot of people work hard on improving the standardized container and then that benefits like everyone automatically right and uh I think it's the same here right and so

actually the more we do things through the uh RPC, the more we're actually creating uh a world where we can like work hard on this one piece and uh improve it. We could give give people better opportunities for actually like reading uh data in a trustless way and then that actually benefits people, right? Because uh the alternative is like if you're talking to a 100 hard-coded servers like even if we make the RPC perfect like still there's 99 other people who are seeing all your all of your uh private data >> and also cloudflare can go down and then that's also a problem.

>> Um okay so um another thing we talked about is delegation versus dependence in the manifesto which I think it's also an interesting subject. So it the manifesto itself says the delegation may exist but dependence must not. So what's an example of a place today where users think they're delegating but they're actually depending. So uh one example one example that I already mentioned is uh the RPC that you may think about is just a way to exit say no I'm just using it for convenience. But then let's say uh you sell me something in the real world and um and I'm giving you a and I'm and I'm giving you a 100 USDC for it. But what if you go to an RPC and you actually

depend on it to ask to get your balance and you're not running a local node which again is right now a bit difficult will become easier. So you are not really um so you haven't you haven't delegated you actually you actually depend on it. If he doesn't tell you the right answer, you don't know the right answer. So that's like one example. >> Um, right. Anyone else has runs? >> I mean, price oracles are one, right? Because it's easy to think of them as just being like UX convenience. But, uh, if a price oracle is like upstream of the price limit that you set on a swap, then you know that could be combined with a sandwich attack and extract a lot of money from you.

>> Yeah. So you know this is actually um so this uh since I bring up this dependency on all this actually it ties back to what we said about L tools because you know one of my pet peeves about uh when when we say that anyone can exit you know that the L2s that rollups are fine because you can always exit. So if the funds are in your account then yeah you can use the force inclusion mechanism to exit. >> But if if your funds are in a D5 contract that has a dependency on an oracle and now the the sequencer goes down or sends on the oracle.

>> Mh. >> Now you can uh it's not enough that you use the force inclusion. Now the oracle also needs to so you you now have a dependency. You can't even exit from the L2 without the oracle's help. >> Yeah. Orum another example is like if you let's say you have a position in poly market right and let's say we're in theoretically a better world and let's say poly market be gets is on a a stage 2 L2 and let's say it has a rule that the governance has an upgrade window of 180 days right and like this looks like very nice but then the problem is that the markets on poly market have potentially a resolution time of more than 180 days right like a lot of the most interesting ones. I like

potentially two or four or five years, right? And so if uh the logic is like that internal logic is not cognizant of the fact that if something goes wrong on the L2, then you might need to like exit this position that's that's still kind of in flight then uh potentially you know you are actually still trusting the who you know the rollup governance even if you know originally you don't think you were. Okay. So, um um I think that one of the things that we see when it comes to trustlessness and something that's challenging is UX. So, there is sort of this tension between on the one hand you want to reduce the cognitive load for

users, right? Like we can't expect everybody to be these kind of like uber conscious people over security and hold everything themselves. But on the other hand, we want to protect trustlessness. So any ideas on how we can resolve it without drifting to gatekeepers? >> Yeah, I think that comes down to essentially of like a couple things. One is that the user should be aware of this and they should be able to make that choice. If let's say I'm sending I don't know $10 10 USDC across chain and I want to use a centralized relay because it's only $10. That's a choice that the user should be aware of and they should be aware of the risks and and be able to make that choice for themselves. But I think like at the base layer uh like

trustlessness and things such as like the walk away test like can can the user walk away from an app or protocol with their funds. Can there be forced inclusion in the L1 without depending on you know other things like such as an oracle like y mentioned. Um all of those things need to be I guess built into to the application and protocol level. >> Yeah. And one one example that all this reminds me of is uh you know like like we I use you know like IPFS my blog is on IPFS right and uh you know the kind of standard works for everyone way to use uh IPFS is of course to put limo after the ETH and then there's like a centralized forwarder and it's like nice

and convenient right but then you know you have you're exposed in three ways right one of them is like what if limo goes down two is what if lilo feeds you the wrong information and then three is what if uh you know like libo gets your your personal data and your access patterns and uh I remember like brave right uh like it had this feature where it basically you could put in e and it would use its own internal way to like try to actually fetch the data right but then the thing I did I discovered is like I gave up on using it and I just like switched using limo and the reason is that uh it took about like the specific forwarder that they used it was like actually pretty low quality right?

Like it took about 10 seconds uh sometimes for it to load, sometimes it would not load different things at all and uh it basically yeah like it ended up just uh like not actually being you know like fit for fit for purpose at all at that time, right? And so the yeah like for that particular case the question is like well what is the best experience that you actually can uh give especially you know given this like set of constraints right we're probably some people have specialized software some people don't some people are more paranoid about eth limo getting your data some people are not like some people care like access data that's more likely to be censored and like one of

the classic techniques is of course the kind you know like the one of N approach where like you have a request and you send it out to like five different servers and also to the decentralized network and whoever answers first like you actually check their answer and if it matches the hash then you accept it and uh you know like this is nice in that perspective but then it also has the weakness that you're like exposing your data to like five different uh servers so it's uh like in a lot of these situations I think uh it actually is this kind of like subtle mix of different trade-offs and uh often like you have to figure out something that like actually solves all of the

different problems and like often even like with things sometimes with things like P you actually can which is uh interesting. Um but like it it does get application specific and there are challenges I think in like communicating to the user like what are the properties that you get and what you don't get. Like we also don't want to replicate you know the GDPR dystopia where like you have to like check a checkbox that everyone forgets what the checkbox actually means. So this is like an area to highlight where I think there's actually unsolved problems and like you can do some work and figure out how to improve them. Yeah, that's really interesting because I think a lot of us are just so quick to click the approve or like accept all terms and conditions

and not read them. But then I think the question is like what is the right way to like inform the user of the risks and I think like wallets are starting to tackle this you know with some of the things the initiatives around clear signing um to to let the user know exactly what they're signing but yeah it's an interesting question. Now I wanted to add that since since you you brought up the cognitive load. I think that actually it's on us on builders to try to reduce it by by building systems to be trustless by default where possible because when it's not uh when it's not possible when this is not trustless now the user has to comprehend what the what risks am I taking by performing this action like who can hurt me here who can steal my funds who can

sensor me. Um so even I I don't know if in every case we can make everything as a trustless but in every case where we can make it trustless this should be this should be a choice and this actually reduces the cognitive load. The user doesn't have to think about it because I mean I'm not at risk. If I'm not at risk I don't have to to think about it too much. >> Yeah. I kind of think of it as an iceberg where the top of the iceberg is kind of, you know, you have hosted UI, you have this great UX, you have all of these things and then underneath the water you have things like trust dependency, dependencies, um, etc., etc., like all of those things that go underneath it. And I think the challenge as builders is to build that underneath system in a trustless way so

that you can then put the great UX on top of it. >> Yeah. And and I guess the the question of how we can actually you know design UX so users can choose convenience without you know making the protocol dependent on intermediaries. Uh maybe that's a bigger question to answer right now in the panel but I think that's a very interesting question to kind of like uh consider afterwards in other talks. And so when you when you mentioned talking to servers and asking for a question, it kind of brought up the whole concept of um you know financial incentives because you know if you have a server someone's paying for that and I you know trustlessness doesn't work if it's not uh properly incentivized. Ethereum works and Bitcoin works because at the end of the day the

miners or the block builders in case of Ethereum they can work and they know they'll make money and we kind of count on the fact that individuals if they can make money they will do it and they will do it kind of like they don't care about what you want to transact and it will just work. There's no kind of like something in the middle where they have to decide oh do I want to do this? Okay. And so um the manifesto itself says that a protocol that relies on unpaid altruism will decay and a protocol that rewards control will centralize. So what do you think is the sustainable incentive design for you know tr as trust as possible systems?

>> That's a very application specific question. I think it'll have a lot of I think it'll have a lot of application specific answers. Uh yeah so the general answer is mechanism design it's that I mean we want to we want in protocol fees to incentivize because if there's no I mean if the if there is no incentive to do something then economy I mean basically like economy 11 teaches us that something is not going to sustain if uh it's not profitable and if it's profitable by some externalities not by not by fees not by something in the protocol then uh bad things then things uh tend to happen. So we need protocols to be designed in a way that

to reach a shelling point where earning the protocol fees is the is the best this it is the winning strategy and yeah it differs between protocols but that's something that every protocol designer should take into account. Okay. So in in your eyes like what role do neutral and open source client teams and independent operators play in preserving trustlessness as as we start scaling like how do we make that work? >> You're referring to the >> Okay, fine.

>> Well, see this is a good example of redundancy in action, right? And uh just like when this microphone failed, Marissa's microphone uh came up to save uh my ability to answer the question back in 2016 when we had the Shanghai DOSs attacks. You know, the uh the GU client uh completely crashed and parody with the other Ethereum client was still able to run and process the blocks and then a few days later Parody crashed and GU was able to come in and uh save the day, right? And so I think uh the fact that that we had multiple clients like actually really did save us uh back then. And uh now of course Ethereum has like a lot of kinesthetus clients, a lot

of execution clients and none of them have more than about 40% of the network. And so there's like no bug in any single client that would be able to cause uh the Ethereum network to go down, which is uh pretty amazing. that's uh like that's not something that's true of like basically any other decentralized network, right? Like even Bitcoin is uh not like does does not have that. And so I think it's uh it's it's a good example of how it's like always valuable to have multiple levels of resilience and uh defense and depth, you know, including against things like software bugs.

>> Yeah. Okay. That's that's a very good point, you know. Um so um if you each of you had to choose one metric to measure we talked about in the manifesto about trust reduced per transaction that's a very nice term and if you had to choose like one metric to measure it what would it be >> I think to measure trustlessness I think the way to measure that is the walkway test can the user >> exit um a blockchain a app with their funds intact can they and can they do this in a way that is like anyone could do this. Like I don't mean they have to run like 12 different scripts and like it's very complicated. I mean actually do this and they're not relying on like any other trusted dependency in order to

do that. Um and then like in terms of protocol like I would just say also forced inclusion to the L1 like can I force my transaction down um as well. >> Yeah. I think uh the other kind of the the one that's uh suitable for the pessimistic short term is uh number of people who can rug you right. Like as I mentioned in my presentation like often the problem like relative to the status quo if only one person can rug you that's like almost a utopia right and uh you know we have this like big zoo of uh like 14 different dependencies of uh dependencies and uh if you can enumerate that number and like look at the software libraries I mean like and you

know who is serving you the UI and uh the the code in your wallet and the blockchain itself but also your operating system like and then go ultimately hardware as well and like try to track that number and then like continue to find ways to push that number down over time like I think that's something that can uh like really rally our ecosystem uh around like really improving things quite a bit in the short term. >> Yeah, I think that's like one vector is like how many and then I think there's another vector of how bad. So, like how many people and then how bad can they can they hurt you in the end and like both of them combine together?

>> Um, okay. So, we're starting to get to the end of this panel. So, um, if someone um like were to sign the Trustless Manifesto, what is one concrete change they should make in how they build or use Ethereum tomorrow? >> Right. So, so this, so my uh uh my gold standard is going to be walk away test that we keep coming back to. It's uh if a builder commits to always be thinking in terms of what happens if uh what happens if everyone including myself goes rogue like either we go away or worse yet I want to screw I want to screw with my users. what uh what is the recourse like how uh so what will the

how bad can I hurt my own users me or anyone else any component in the system and how easy is it for them to recover and it goes and and h and it comes in different flavors and with different levels for example like maybe technically like in the case of a rollup they can't uh so technically the user can exit but how many roll-ups actually offer a tool in IPFS something that doesn't require their server and helps them to to exit. And so so as a developer, you should always be thinking what happens what happens if I decide if I stop being aligned with my own users, are they still safe? Will they still be able to use the system or at least exit?

>> Yeah, I think anyone coming from security would be of the mindset that it's not necessarily me going rogue, but someone took over my system and now I'm rogue by, you know, I don't have a choice. So you kind of have to keep that mindset >> I guess. >> Yeah. I mean like it there you can even think of it selfishly. It's reducing the extent to which you yourself as a developer become the target. >> Exactly. And so before we take questions from the audience I would kind of finish with this question. So what does a fully trustless L2rich Ethereum look like in 2030? Like what's the optimistic vision of where we should be?

I think I mean so first of all I expect you know we'll have a lot more L1 scaling to the point where a lot of applications are able to run on uh L1 uh directly and at the same time we'll have uh things like ZKVMs and so like basically everyone's wallet including phone wallets including browser wallets will also be fully verifying wallets. uh this is uh important then to go to take the scalability even further above that you know we can have we will have lots of uh stage two uh rollups that have instant settlement that settle down to the L1 every block um and uh where there are standardized easy protocols for

moving your assets uh in and out of them ideally efficient enough so that uh you know even default flows don't necessarily go through a server. Um then uh you know we needs to have wallets that are able to actually interpret all of these things in a standardized way. ideally in a way where even if new uh new L2s come into the picture like the real mathematical utopia right is like if a new L2 comes into existence then it comes with some kind of formally verified proof of its security and then wallets are able to automatically uh interpret that proof and then uh if uh an application asks you to move your

funds in there then it still tells you that your coins are safe. Um but even uh uh even like before we could get to that kind of level, right? Like being uh like like wallets uh being able to tell you um like like how safe are your funds if you take a particular action. And ideally we uh move away from this world where you need to like do five clicks uh for everything, but where it's like a risk based approach and like it's a it's a very easy or even zero click to move $10. But on the other hand, there's a lot more security and a lot more checks behind moving $100,000.

Um then uh the the you know UIS from the privacy side. I hope we can uh like really uh take um like server minimization uh much more seriously and uh we can even have more frameworks that try to make things much more local first uh by uh default and then when things have to go offline uh for them to uh or go online uh go go online in uh trust minimized ways and uh like we really start thinking not just about the yeah blockchain but also about like full supply chain in security.

>> Okay. Um I think we have questions from the audience, so I'll turn to the lovely Brit to >> Yeah, we've got a couple questions. We'll see what we can get through. Thank you for submitting them. Um the first is, do you think it's possible to have a trustless LLM these days? >> It depends what that means, right? Like I have, you know, Q133B on a laptop and like it, you know, it does things. Um it's uh I mean it's definitely like a step quite a step less efficient than uh you know like fullon like GPT level things. Um I think uh you know like there is this kind of trade-off of like especially if you're a nomad of like how many watts the thing you're consuming

and like the convenience tradeoff and all that right and there's like this curve of use cases where for things like translation like how that can run on a phone are totally good enough for things like uh debugging your newest discovery in quantum physics like realistically even GPT lies about that half the time right and so it's you know way. Yeah. Up there on the curve, right? Um and but then the other challenge of course is like even if you have a local LLM, like what was the supply chain that was used to create that LLM? You know, like are there bugs in the uh LLM that is like that are there deliberate back doors inserted into the LLM that is a thing that exists? And uh it would be really cool if we could have like zkonarchs

with 1.1x overhead and so we could prove you know a full training pipeline and like I think we're less far from that than we think but we're also quite far from that. Um, >> yeah, but >> the data set is still I mean even even if you prove the whole thing I mean proving what data set it was trained on >> that's the real uh >> Yeah. >> Yeah. All right. We're out of time but I've got one more quick one was the highest voted one. Are centralized stable coins a risk to trustlessness? >> Oh okay. Yeah. So it's uh it depends it depends on what what they are pegged to and how. So yeah that's uh I mean you

can have different flavors of them. If it's something that is pegged to the US dollars and it doesn't depend on on overcolateralization like like maker used to do then it has to be then there has to be some centralized party such as a bank account holding US dollars. So in that sense yeah it cannot be trustless but even then you can have a spectrum of trustlessness. For example, you can have a token you can have a token where h the onchain presence of the token once it's minted it it is not there is there are no whiteies there's no no freeze functions and then it's so even though uh during onboarding you have to know about uh I mean during onboarding there is a bank involved and someone can uh

can can sensor you once it's on chain at least uh we can be protected so I don't I don't see how it can be 100% trustless while peg to the dollar because the dollar itself is not uh is not trustless but we can approximate. >> Yeah, I think it ties into what Marissa said before is that you can build trusted on top of trustlessness but it can't do can't go the other way around and the US dollar by definition is trusted. >> Yeah. Thank you guys. Big round of applause for our fireside chat.

[applause] Oh, and just one last plug. Uh, if you guys haven't, you guys should sign the Trustless Manifesto um on chain. There's a bunch out there. >> All right, make sure you sign that trustless manifesto. And there is going to be a coffee break. We'll see you back in a couple