The Zero Option Is Possible: Trustless Ethereum on a Phone, Without RPC

Transcript

Can you hear me? Okay, good. Um, so this will basically be three parts. Um, the why you don't uh want to use any centralized server and the how and then hopefully two live demos. I have videos prepared so if the live demo doesn't work for whatever reason um uh we can watch a video. Um so the problem is that every mobile wallet I know of uh uses um a server an RPC server usually or any other trusted ser trusted server. How does that work? Um um your wallet connects to the RPC

provider usually Infura or Alchemy and they talk to the network to the Ethereum network and get the data for you and give the data to your wallet and your wallet usually trusts what it receives. What's the problem with that? um the RPC provider can be pressured not to service you or they can decide that on their own or they one of the problem is that they know a lot about you not only basically they know every question you have to the network they uh see it and they can also u just vanish and not work for example and regarding the trust you might ask

what about if proof So eat get proof is a real improvement. Um I think there were talks before me that mentioned it already. Um but it doesn't solve the problem of availability. So if an use they all the solutions I know of Helios kibbri kela they all still go through an RPC server and um so you still need an RPC server to use them. Um, Bitcoin solved this problem in 2008 already. In the in the white paper, there's already a specification for simplified payment verification. And in 2011, there were at least two wallets

that did this. One on Android uh from Andreas Shipper and one um oh, I forgot his name. Uh called Electrum for the desktop. So the EF released their mandate uh this year and um in that mandate okay let's talk about crops first uh they they uh say crops is important that is censorship resistance open source privacy and security I would add the P could also stand for permissionlessness because that's also important in my And the mandate talks about RPC uh

directly. Um let me let you read this. So RPC servers are choke points that should be avoided if possible. And I think my solution um is well my my project is a way to avoid RPCs as a as a choke point when accessing um Ethereum or yeah getting information from Ethereum.

Um yeah, as I already mentioned, today the path is wallet talks to JSON RPC, JSON RPC talks to Ethereum and the zero option would be the wallet talks directly to the peer-to-peer network, to the execution layer clients and to the um consensus layer clients and that is what Miotus does. It is crops compliant, I would say. Uh it's censorship resistant because it's only a software on your phone. Um, it's open source. Um, it's a little bit more privacy than with an RPC. So, not every question goes through one uh server, but uh, Miotus distributes the questions uh,

among several servers for per performance reasons. Um, security. Yeah, everything is verified that uh miotus returns against um BLS signatures uh from a syn committee participants. the architecture. Um yeah, syncommitties are the base uh verifying me mechanism. Also um there is a checkpoint that is uh included in the application that is basically a hash uh on the on the beacon chain. You can also include your own hash if you don't trust me as a developer. Um then the state is fetched via the snap uh protocol.

Um there's a local EVM running uh inside Miotus um on your phone that can um resolve ENS names, every kind, CCIP, anything, reverse, whatever you want um back and forth. Um it can verify blocks and receipts and it can submit transactions. One thing that is missing is the the full transaction history. Um that is a problem that I'm trying to solve with true blocks but actually I have an implementation with true blocks already but the last index they published is two years old and it's yeah just not useful. I would have to make my own index and I didn't come around doing

that so far. Um at first I wrote the or not wrote uh I created a Java engine based on uh Basu as a V EVM and um a lot of libraries that are available uh in the Java world. Unfortunately they need Java 21 and also I wanted to be multiplatform. So my software runs on iOS uh Android, Mac OS, Linux and Windows.

um and to to reach iOS uh Java is just not an option. Cotlin multiplatform can only um compile to iOS if the source code is in Cotlin. So um I converted this Java engine to Rust. Um and with Rust I can also support older Android phones. Um and and Rust why Rust? First of all, it's I would say a relatively secure uh language and also all the components are available in Rust like EVMS and um SSET uh libraries. Yeah, basically everything you need for this project.

Yeah, the trust roots um are SN committees or SIM committee based signatures. Um those sync committees sign every beacon block header uh to the top and via that you can also verify the snap state data. Um yeah there's not not much more to say about that. Um the client fetches the the uh light client bootstrap and then advances via light client updates.

Um uh there's one small problem uh that's the weak subjectivity uh window on um Ethereum. It's considered unsafe to use a checkpoint that is older than 14 days on um Gnos chain. It's even worse there. It's around 34 hours. So if the client has a checkpoint that is older than that um then it's well my library will ask the user if they are okay to continue or not. So it's their decision but in so I would say there is not a really big risk. So the idea is that

um validators can exit um and then can sign anything but they are also not slashed while they are um um in service or while they have a deposit for so I think the the risk doesn't increase that much um exactly so um Yeah, block we are at block n as that one is not uh attestated by uh the sim committee yet. Uh it's only atestated in the next block. So block plus one n plus one uh has the signatures to verify block n. So I'm my

client is always a little bit behind uh like 12 to 18 seconds necessarily and if there are delays then maybe 20 seconds but I think that is also not that bad. Um yeah that's how yeah how uh how data gets verified. So the snap response has a proof. Um I think that's the same proof that you also get with get proofs. Um, and that's also it's the same mechanism that Helios uses to verify uh data just not using an RPC by but by talking directly to execution layer clients and um beacon chain clients.

Yeah. Uh the snap data is um in a mer petition tree and you can verify it. You have the top hash and then you need for every every layer you need all the siblings and then you can compute the hash of the next layer and this is how uh how the snap data is is verified and you don't need the whole block you only need um a subset to verify everything. This is what I talked about uh of the future uh or maybe not. there is um an EIP uh 7919 pure ETH that might solve this problem uh if it's contract based.

So there was one solution presented it's I think the lock index um uh where a client could um basically gave their address and check what transactions are relevant for that address. The same thing I can do with true blocks but probably not via IPFS because it wasn't reliable for in in my experience. So but that's this part I would say is not ready yet because it has too many missing parts.

One interesting new development uh there are block uh access lists. So right now um I I basically have to verify everything again with every block that comes in because the state could have changed and that is a lot of load that I uh incur on on the execution layer clients. But with block access lists I get basically a list of the changes and also the target values of those changes. everything verifiable and that uh has two positive uh implications. First is I don't have to bother the execution layer clients for all the proofs and the snap data and

also if I don't ask them they do do not know what I'm interested in. So I will ask them or I do ask them once. I asked one once and from then on as long as the uh application is running I can just look at the u block access lists and update the state internally by reading that. So what's already there? Um unfortunately I cannot read my slides here. Uh yeah a long list uh discovery uh ETH 66 to71 beacon light client over lip peer-to-peer balances nonsis storage e

call uh so executing uh contracts um ENS transaction broadcast um and some transactions are also visible um in the app that uses miotus and next is there the B stuff is already implemented actually and the historical accumulators and the transaction history I would put at the at the end uh of the list. Um there are two ways to use uh Miotus at the moment. You can use it as a um local RPC server. So you run it on your phone and then it exposes an RPC uh interface on local host uh port 8545 for

example for Ethereum and then any wallet that is unmodifi any unmodified wallet like Metam mask can just point to I will show that in the demo point to that um address and use Miotus as it was would use any RPC server the other way and that's actually the better way to use it is to use it as an embedded library because if you use it on Android or on iOS then the app is aware of the life cycle like when does the app go into background when does it go come into foreground and as a library that's just um better to handle the um RPC service right now um when when it doesn't get

any requests from a wallet for 5 minutes it also shut shuts down its networking stack to not drain the Tory um and then when the first request comes in it leaves open the server socket when the first request comes in it it has to um yeah start all the networking and that sometimes leads to the problem that the first request fails because it takes too long. So that's the drawback with the um server solution. Who uses this already? So the freedom browser I don't know if you have heard of it. Who's who has heard of the freedom browser? Okay, almost nobody.

It's a browser that uh for the decentralized web um it uses swarm and IPFS to fetch the data and ENS to resolve um ENS names. And um yeah, Zotine is my uh wallet that uses it as a library. There's also a demo soon. Um, and deboot uh is a project that I hope I hope I don't butcher it. Uh, it allows you to boot uh basically a PC via ENS and swarm and uh then yeah bootstrap in a

I don't know I don't know how it really works but maybe Chris can say something about that. Now for the tradeoffs. Um so there's uh bandwidth I have to make this larger here. Um yeah bandwidth is higher than with an RPC service. Then um the disk space is actually reasonable. I would say uh couple of hundred megabytes. Um the um mo the biggest cost is is time. I would say you have sometimes you have to wait a little bit that everything is zunked and also the development needs to

uh follow all the hard forks. So for Glamsterdam I needed to make some adjustments that Miotus is compatible with with Glamsterdam and doesn't stop uh working. And there's also trade-offs on the network. Um basically uh um miotus is leeching uh from the execution layer clients. It doesn't give back much. I found at least one way for the uh consensus layer. Uh I built a really lightweight uh client that can only serve the light client bootstrap and light client updates and thus can handle thousands of connections without any problem on commodity. uh um PC

hardware. Um and with B with um block access lists, I think I can also lessen the load or have also maybe a front end or a sidecar before an execution layer client that can also handle maybe thousands of clients. Um that remains to be seen. Um oh yeah get there are some uh RPC codes that are not fully supported and one of them is get locks. Um with get locks if you know what contract you want to support for example the rail gun uh contract or the swarm contract then you can bundle uh that data and then with

miotus and then miotus can also answer these questions. uh if a rail gun client connects or a swarm client. And the third one uh yeah it's not the the privacy improvement is uh not that great. Um I did some experiments with using to but the problem with to is that uh exit nodes are basically um blacklisted on execution layer clients. Not not necessarily explicitly blacklisted but they behave in a way that the execution layer clients downrank them and it was tough to get any data uh from via tour.

Also, tour only supports TCP, so the discovery is a problem. But I hear that the Ethereum Foundation is working on something uh tour based for private reads and private rights. So maybe that helps then the clients accept the connections. And you don't have to believe me. It's everything is open source. You can run it yourself. There's uh there's another mode. You can also run it as a demon. That was actually the first mode. and then uh send requests uh JSON requests um via a local socket.

And now the demo. Okay, I have prepared a video. So if for some reason it doesn't work, I can show you the video. Ah, that worked already. Just a second. Uh no no no no no no. Sorry. So on the left side you see Metam Mask and on the right side Miotus and just to confirm that it's talking to local hosts. So for Ethereum it talks to

local host 8545. Oh, wait. Yeah, sorry. Forgosis chain 8546 and for Zapoleia 8547. Now we go into creating a transaction. Let's do some XDI to some address. Oh, actually I wanted to show you can see the requests coming in uh here in the locks. So it fetched the um nons and uh the price and now I can confirm and then you see ETH send ro I hope you can read it e send ro trans

transaction and then it checks uh the transa checks whether the transaction is still pending or not how much time oh I am out of time um okay so this was the motus demo more. Um, looks like do we have time for questions? >> Sorry, I really uh lost track of time. There would have been another demo.

>> Anyway, >> can we get the questions on the >> Yeah, sure. >> on the screen. And uh yeah, first I think a bunch of people asked how would they install uh MASS on their phone and laptop. >> Currently it's only available uh on GitHub as a um APK for Android. And yeah, for iOS there are several problems. Um so for iOS you basically have to compile it and build it yourself and install it yourself because IO uh it will probably not be in the app store soon.

because you need to have a organizational developer account if you want to put a wallet and this is and actually the one more thing uh on iOS the demon mode doesn't work because it will be killed in the background you need to have a wallet that uses this as a library um which zerotin does uh so you can use zerotin compile it yourself install it on your iPhone and then use it is that was that question, >> how things like ethos or phone tie into this.

>> So, I haven't yet talked to the ETHOS people, but I would be interested if they are interested. Um, so I'm looking for uh projects. I actually that was on one of my slides. I'm looking for projects that want to integrate Miotus and find out what it doesn't do, what they need, and then I would try to implement that. Uh what do you most need help with? >> Yeah, as I said, I need uh projects that want to use it. They that they try it and then tell me what what was not okay or what could be improved. That's the most important thing I would say.

Oh, maybe an audit. Maybe if somebody knows a company that can do a code audit, that would also be helpful if I don't have to pay for it. >> Yeah, currently the project is unfunded. Uh I do this in my free time and yeah. >> Yeah, I think we have time for one final question. Uh uh let's say what happens if every user uh Yeah, this one is uh tough. Uh what is the inventive for nodes to serve peers which are not giving back anything?

>> Yeah, currently there's um so I do store the headers on the phone or every data that I get that could be asked by other clients I store that and I have a statistic how often miotus is asked for it not very often. Um but if it is it can serve also data but yeah that's the the the biggest problem. One solution could be to put this on swarm like do the bootstrap to the point where it can use swarm and then get uh the state data also from swarm. I hear there is a project uh in the swarm um team to put state on swarm. So I could get it from there.

Yeah. Other than that, >> uh, and yeah, we we just have, uh, for another one. Uh, so can I embed uh it in my browser app without having to install anything? >> Uh, as a plugin, probably, but it uses uh sockets on arbitrary ports and not only HTTP and also it uses uh UDP for discovery, so you cannot run it within the JavaScript context. um of a browser uh but as a plugin it should so the yeah I mean the freedom browser also uses it uses it at as a a note plugin I think

it's called but it's mainly meant for mobile iOS Android or your desktop