The Next Centralised Dependency Is Your Bootloader

Transcript

[music] Okay. Wow, that was one of the most enthusiastic um introductions I've ever had. So, uh thank you very much for this. Uh and it's nice to see so many people here on the last day of DevCon, but lot to get through. So, I'll I'll jump straight into it. Turn it on. Oh, no. Oh, don't tell me this is okay. Now it's working. Okay, so I gave a talk earlier on this year at ETH Prague about sovereignty preservation.

So you've you've achieved your sovereignty by by starting to interact on Ethereum. And one of the things I recommended everyone to do is the the age-old thing of run your own node. That's a a great way to to be sovereign and uh interact with Ethereum and Ethereum based services. But on a uh on inspection, on looking a bit closer, I started realizing that the process for actually pulling the software in and and downloading it onto your computer in order to be able to run a node had quite a number of sort of dependencies on on legacy infrastructure uh coordinated by legacy governance structures. So this

talk kind of delves into that. So going to start with a a headline metric here and the metric is zero and this is the number of ways you can use communitygoverned tooling ETH docker and SGE to fetch binaries for running Ethereum nodes from anyone other than the usual suspects of Docker, Google and Microsoft. Uh so big fat zero. Um and some people here will say but but but Chris doesn't matter. Uh we can still verify that we're getting the right software because they'll publish SHA hashes. And if you actually

take the time to to to to run the the SHA 256 sum and and actually check that the SHA hash is right, then you you can kind of verify it. But there's kind of a broader concept here as well around sort of availability of of of of serving infrastructure. Uh if you if you have one company in the path then uh you know sometimes GitHub does go down and uh then you kind of at some sort of disadvantage at being able to to to fetch and update your software.

So like that that was the broader kind of community thing. I'm now going to zero down in on on G. And I'm sorry if there are any people in the GU team in the audience, but going to roast you guys a little bit because when you when you send people to g.ethereum.org, the Ethereum Foundation's own website and the GU team's own website for for for for giving you the the the age-old and the the most mature execution layer client in Ethereum. you need to rely on five companies to provide the information to allow you to do that. Um various different reasons why those companies are are required. Uh and also this was measured just under a month

ago. So maybe it's changed since then, but not entirely sure I uh I would believe it. So that's that's in some way characterizing the problem statement and and in some ways this talk is a kind of like a call to action for us to to upgrade on our authenticity. We have we have mechanisms for governing data. We have mechanisms for labeling data. We have mechanisms for storing and serving data. All running on systems rooted in Ethereum. but we're just not using them.

So there's something there that every time I'm downloading something from GitHub and requesting permission from Microsoft to get some software, I feel inauthentic. So So this is kind of what drives me uh for some of this work. So the solution I believe is to is to start using swarm which is Ethereum storage layer to to feed your machine with with a hash uh and and have that then fetch data fetch content from swarm that represents the binaries or the software that you want to run. uh it it it kind of removes this manual step of having to to verify that

the software is the same as what it's supposed to be because because you're fetching by hash. It's kind of like the the fetch uh is makes it so that the verification is automatic. And for those of you in the audience who aren't familiar with with Swarm, it's a it's a a very longunning project almost as old as Ethereum itself and is a uh you can think of it as being kind of an extension of of Ethereum block space. If you're you're operating on Ethereum by [snorts] signing transactions using a a traditional key store, then you can use exactly that same key store to sign things for uploading content to Swarm. It's it's kind of like

Ethereum's native storage network that driven by a token with incentives that are minted on Ethereum layer 1 and nodes running the swarm software contribute their capacity to the network. So for me it's kind of like almost no-brainer. So what what this gave us thought to do as part of a a broader initiative called Uncloud is to create something called the Uncloud registry. And this is where we took the the specification for distributing containers defined by the OCI, the open container initiative, and built something that can be effectively like a self-hosted Docker Hub. Uh you

can run Docker push, Docker pull, or Podman push, podman pull. Everything works exactly the same. Uh the version one's been in existence for about a year now, and we're kind of kicking the tires on that and updating it to version two. and is actually currently in use in production by the Swarm Foundation itself who is running a version of this thing backing off the data to Swarm. So if you go and run this command here dockerpool registry.warm.org/ do that that will pull in the latest version of swarm's reference client which is called B. So this is great so far, but it it's still reliant on DNS which typically gets sort of resolved by

some sort of corporate infrastructure. So it's just kind of a step forward and it's great but it's it doesn't get us kind of all the way. So bit of experimentation just taking sort of Ethereum's equivalent of DNS if you like using ENS to just mirror from GitHub and and Azure the the binaries for running an execution layer client in G and running a consensus layer client in loadar mirroring them to swarm and then and then pointing the the the ENS names content hashes at those those hashes and and that that can be fetched from swarm.

It's, you know, it's not it's not rocket science. It's just kind of like using ENS names to label things that are that are hard to to label. But this is still reliant on me, some some single actor, nothing to do necessarily with the guest team and the loadar or any of the execution layer clients. This is me mirroring it. The better answer obviously is for the teams themselves to start to push software onto the infrastructure that is born out of Ethereum. Um so that I can be kind of out of the loop. And good news is Chain Safe have sort of picked up on this and there's an open PR that's going through the process uh to the point where

they're they're planning to start serving Loadar out of Swarm via their own self-hosted Uncloud registry which would be a great step in the right direction. Other clients not yet sort of picking up on this but we'll kind of get there slowly. So it already works. We've already got this thing working as well in the live pit ecosystem. a live pit orchestrator pulls a container from uh a a an uncloud registry that I run and then loads it into memory and starts using that container functioning and and and running paid jobs paid in Ethereum. So it's already kind of in production.

So everything we've talked about so far has been at the operating system layer, the the after it's booted into Linux uh running software um that does things. But the promise of this talk was to go into a lower layer um and think about who gets the actual operating system onto the computer because right now most of the computers that we're running are getting their operating systems from Microsoft or Apple or Canonicle if you're Abuntu or Federal Foundation and and that's interesting but it's still kind of closed source networks for for delivering open-source software.

So this is where I'll introduce Deboot. It's a a project that started at at ETH Berlin 3 a few years ago and has sort of slowly evolved and then kind of like rapidly taken off since Agentic Coding came. And and simply put, you get a computer, you you seed it with a deboot firmware, you give it power, a network, and a key. It then reaches out to Ethereum and and and creates a sort of a PCO connection to Ethereum to to get the ENS name for the machine based on its key and also then the content hash for that ENS name.

And once it has the content hash, it it it it peers with Swarm and pulls in all the chunks that are distributed across the network for Swarm and forms them all together into something that's an operating system that can run on a computer. And no companies exist in this path. It's all running on infrastructure that's born out of Ethereum. So this this isn't a Chris has invented some crazy new way of doing things. This is actually an an old idea 27 years old from from the '9s of something the the preboot execution environment where you would configure your server to go and talk to another server to say hi can you

give me the operating system and the the other server delivers it. This is sort of reimagined in an age of decentralized storage and also blockchainbased decentralized systems for for naming, labeling and governing things. Uh and the important thing is here the the server is sort of subtracted from the from the picture so that it's actually just relying on a storage network instead. So I won't go too much into this, but this is the the flow diagram of how it works. It all starts in the top left with a machine that's been seeded with a key. It then goes finds out what name it is. What what what should I call myself as a machine? Then it will talk about it will go to swarm and fetch the the

record of what it should be. What what what are the details of the identity of what this host ought to be and then it will it will go and fetch its kernel from and in it ramifest from swarm. Uh right now we're using Linux kernel. So that's kind of what it boots into, but we've also been experimenting with BSD and other sort of wildly new experimental kernels that are sort of emerging these days. But once it has all that data, it's able to boot into a working operating system and then running this this deboot dervice which I'll explain now. So that this is now after we've booted into the Linux operating system. Again, this machine

has its key and it resolves its name again and then it it it works out what services I should be running on this host and pulls in the images again from swarm and once it has them, it starts running. And also this kind of loop back every 5 minutes it will check to see if there are any updates and if there are some updates new versions of the software have been released or or the user has configured certain bits of software to to be removed then it will it will do the needful. So when we're making a release of new software, any type of software, whether it's the the the firmware bootloadader or the operating system or the services,

the software services that run on top, that this is the shape of it. We'll build it, we'll push stuff to Swarm, and then we'll use a safe multisig to update an ENS name. And I mean this starts to feel a bit like some of the things that you might do on GitHub for for packaging releases and then publishing binaries. And uh but but this is something that's that's exclusively using systems for storage, systems for governance, systems for naming and labeling that are born out of the Ethereum ecosystem. And once that's done, deboot performs this last mile deployment

uh to the actual silicon that's going to be running this software. So this is an interesting one around around governance is this mechanism. It's not a it's not a kind of like um well what it is is a is a way to to to to entirely govern what runs on your computer yourself by sort of being the dictator of your own sort of computer domain which is entirely valid and reasonable. But you may also wish to do something like delegate the responsibility for what runs on your computer to some other entity. So maybe the Ethereum Foundation multisig may

sign off that yes, this is the latest version of GE. Uh you could even maybe have a DAO that's governing what software ought to run. And that kind of also evokes ideas that you know Microsoft, Apple, Canonicle all could use this exact same structure for governing and and um publishing and fetching software that runs their stacks. Uh and of course it's not just sort of one end of the spectrum or the other. You can have any mix you want with um with full sort of multiplicity.

So this is this is what we've been playing with since since kind of like building this this base layer is getting fully working swarm lightnose ethereum ligh nodes chain lightnose and also live pier gateway for for consuming kind of GPU capacity from the live pier network it it's all running on both arch 64 sort of ARM machines and x86 six uh Intel machines.

The the the top four in here, they they never touch the disk. It's entirely running in RAM, using the network to connect to the networks. Uh but we also did an experiment with uh with actually using a a local storage to store chain state and syncing a full node onto Ethereum that technically could then be used to validate on top of. So th this is what I call now the blank canvas. This is the the starting point the sort of the the minimum viable set of software and services that that you would have running on your machine that

is Linux and Ethereum and Swarm. this kind of this this holy triumphvirate of of of software packages that uh that combine together to provide quite a kind of a a powerful platform for for building on top of. And this blank canvas is is very much an invitation to then encourage and invite you to then paint your artwork onto the top of this canvas knowing that underneath you have an Ethereum node, a swarm node, and a and a Linux kernel. You can then paint on top. And it brings me back to this original tagline of the boot deboot project is to express yourself through

bootloading, which is pretty abstract, obscure concept, but never mind. So coming towards the end now a little bit. This is where I think about how we might personalize uh a running host that's fetched its software from Swarm. And number one headline is this idea of of somehow integrating your home folder with storage from swarm. So that slhome/alice is uh is is where all your my documents, your photos, your pictures, your movies, your music, all these things can be can be stored ultimately on on swarm sort of non-locally but also cached locally if

you want to for example take some music offline for your weekend in the mountains. As well as this, you could also of course fetch desktop interfaces like Gnome or Cinnamon to to run on top of that to give you a kind of a a richer graphical user interface and also apps like maybe you want to install a browser so that you can browse the internet. So this is very much a kind of like personalization of the the debooted machine. So I'm running a bit low on time, but I'm going to sum summarize where we're at now. So I feel bold doing this, but feel like we're now at the level where we can just cross out a lot of these sort of legacy infrastructure networks

who haven't always been the most sort of um sort of collaborative and supportive of of the stuff that's going on in this ecosystem and and replace them with new ways to to serve and publish and fetch software. the there's one blocker still existing in there that the the time um how how does a computer get the time uh so far at the moment I'll hold my hands up yes I don't have a solution other than going and asking a company what time it is also there's this question about how does one start finding peers on Ethereum and right now it is heavily reliant on the Ethereum Foundation boot nodes so this is the number one question I get

asked by people which is why are you doing this? This this this sounds crazy. Um and and it's given me a lot of sort of food for thought and like the number one thought is that we have these machines, we own the hardware, but we we we're still kind of like like blindly delegating the authority for what software runs on the hardware to third party. um to to to third party companies and that for me doesn't doesn't feel so authentic when there are very very viable alternatives to to serving software from tools and from storage

networks that born out of our ecosystem. So coming towards the end now uh the ask to you anyone in the room who is um updating software and and publishing software to to think about next time instead of only using GitHub and and and ways of of publishing software to try to think about how you might use swarm for storing content, safe for governing what content is there and then ENS for naming for labeling to help people discover the content and kind of brings me on to introduce the next talk from the Linux Foundation about how it governs its software releases and I mean for me I feel like

there's a there's potential for collaboration there. So wrapping up, I've actually also put together something that's become affectionately known as the try stick where you can burn something onto USB stick and boot your laptop. It can be an old Intel Mac or any type of PC running Windows. uh and then it will take you a full hands-free booting into a running host that this is an opportunity you can have to to change and select something different. But if you don't change if you don't select anything different it will go on a default option and if anyone wants to actually try this thing

then it's all there. It will not touch your your your hard drive. In fact, it doesn't even have the drivers to allow the computer to see your hard drive. Um, and then so, so this is a way and if you have any feedback, then I'm very open to hearing it. That's me. I realize I'm slightly over time. Thank you for letting me finish. >> All right, ladies and gentlemen, let's give Chris a big round of applause. Thank you, Chris. Fantastic. Very informative. I like what you summarized earlier. You know, Ethereum, Linux, and Swam, the holy triumpvirate. Let's get right to the questions. We've got about 3 minutes now. First question on the top. I'm not familiar with Swarm. Is it like an Ethereum equivalent of IPFS or is it something more like peer-to-peer

file sharing like a piracy website? >> Um I mean there is a way you can look at it and say that it is Ethereum's equivalent of IPFS but at the same time it's not. IPFS is just a file system. It it it may be more like Ethereum's equivalent of Pinata. um if you're familiar with the IPFS ecosystem, but instead of paying Pinata to pin your content for you, you're actually paying Swarm and instead of paying with traditional fiat currency for Pinata, you're actually paying using ERC20 tokens minted on Ethereum. So, >> right, >> um but that that is that's it's not a an an illegitimate kind of way of thinking about it,

>> right? One kind of analogy, but with a little bit of extra details. Great. Let's go to another question. I'll mark that as answered. Okay, the next one which got quite a lot of votes, Chris. It says this. Doesn't this still rely on Infura/Alchemy to provide the correct JSON RPC data or is there a light client syncing before booting the OS? >> It does not rely on any remote RPC endpoint. It's a light client running in firmware that that peers with Ethereum. the EF boot nodes uh make the introductions and as soon as they have enough peers serving the content they need then yeah so and it's yeah it it takes some time to sync with the network

um but yeah it's it's in it's it's very intentionally trying to remove the reliance on any third party RPC endpoint >> fantastic very good answer let's go to the next one this one also got quite a few votes how slow is deboot flow for a normal kind of Linux OS boot. >> So, it's a really good question. So, if you if you tried to um boot into a 600 megabyte ISO, it would it would take days. >> Um but that's not a limitation of Swarm. That's a limitation of probably my own personal engineering skills. Uh this is all sort of vibe coded via Claude and it it works. It's definitely not the most

performant thing. Um but for for fetching a a minimized kernel with a with a very sort of um sparse init ramfs, we're talking about 8 to 10 minutes of of fetch time. The the same content when running in Linux can be fetched in seconds. So there is just some work to be done there to optimize to uh to to to to to smooth off the edges. Um, it's definitely not the fastest thing in the world, but it's also something that's that's kind of like it works right now, and we just need to sort of refactor and optimize.

>> Right. Thanks. Now, there we're just on the clock for the Q&A timer, so if you had [music]