Applying Verifiable Computation to the Software Supply Chain

Thank you. You're welcome. Thank you. So, nice. So, I'm Julie.

I use she pronounced and to quickly introduce myself, I am currently a smart contract auditor with ChainSecurity. This is going to be a little bit relevant and also, if I don't say it, the tax authority is going to yell at me in Swiss German, so we don't want that. I'm also a developer at Randomoo, and it's a bit relevant, and a maintainer, one of the maintainers of ethereum.nix, which is also a little bit relevant. So, to get into this presentation, what does this title mean?

Well, I decided to do a little experiment in my free time around how we build and distribute software. And the questions this presentation will answer are what do we mean with software supply chain? How do we currently protect our supply chain? What I think we could do differently, and what I learned during this experiment. Is this a Nix talk masquerading as a blockchain talk?

Yes. Are the exits locked? Also, yes. Now, let me ask you, how do you obtain your software today in the world? Maybe it comes pre-installed with your hardware.

Maybe you go to an app store or software, open source software distribution. Maybe you get it on CD-ROMs, it's a bit old. Maybe you get it through IPFS and torrents. Maybe you get it from books, you get it from t-shirts or QR codes. There are many ways to get software onto the end user's device, and all of these means are what constitutes the software supply chain.

Now, what can go wrong in the software supply chain? Well, if it's unavailable, you will eventually not have the software you need. If there are bugs, you could get buggy software. And worst of all, if the supply chain is compromised by a malicious actor, you might receive compromised software from it. So it's important, it's a part of our infrastructure, and we should make sure that it is robust.

Now, I divide the supply chain in two big pieces. One is the source code, and the other is the compiler pipeline. So the source code is the way we write software. It's mostly humans responsible for this, and they write software that should follow the requirements of the user. And to secure this, you need to decide who you trust, you need to audit the software or read it yourself.

It really depends on your threat model. The other part is the compiler pipeline. It's almost entirely automatic. It's all the processes you use to take the source code and transform it into something that can run. So I'm going to refer to this mostly as a compiler, even though there are so interpreted methods to run software.

Now, how do we make sure that the compiler pipeline has been run correctly on the software that we are about to use? There are currently in the world two methods, I think, to achieve this. One is re-execution, and the other is attestation. Now, the first one, re-execution, is very similar to how most blockchains work today. Basically, it is you re-execute every computation yourself, or you recompile everything from source yourself to make sure that everything was done correctly.

It's great because you don't trust anyone, you just verify yourself, but how many of us actually compile our software from source? It's not very practical, and it's also not very scalable for the purposes of a blockchain, and I will come back to that later. The other method is attestation. It's what a lot of software does. You have a big build server somewhere that will run the computation to compile the software, and then it will cryptographically sign the software in some way, and then it will distribute the software with the signature.

This is very simple and very efficient to verify, but you get this big central point of failure that you need to protect very well so it doesn't get compromised. Now, concretely, compromises do happen, and I will show you three case studies, one of which is the SolarWinds hack, which happened in 2019. It happens that state-sponsored hackers were able to hack SolarWinds, and through that, because a lot of people used their software product, they were able to distribute malware and even managed to compromise the US government. The second case study is the XZUtil attack on the open source, in the open source world. So at some point, a malicious maintainer was trusted with operating this critical library that was used in particular by the SSH daemon on Linux, which is how you can connect remotely to your machine to administer it, so it has the ability to become administrator on the to package releases, which are almost source code, but not really.

It's a bit of a strange thing in the Linux pipeline, and many Linux distributions were affected, and we don't know that anyone actually got hacked from this. I think they were discovered just too early to be able to exploit the malware, but this happened and caused a lot of noise and concern in the affected parties for very good reasons, and the third case study, which we might be more familiar with here, is the Bybit attack. In 2025, the web frontend for safe wallets was compromised, and this was enough to trick Bybit signers, which were responsible for their assets, into signing a malicious transaction that compromised their wallets, and just like that, $1.5 billion were gone, and in the pocket, I think it's North Korea, yeah, it's North Korea that did it. And so this was a supply chain attack, right?

The frontend was a malicious version of the frontend was distributed through the safe wallets website. Now, there's also a theoretical paper that I like by Ken Thompson. It is a special version of the C compiler that has the ability to, when it itself compiles a C compiler, injects the battery into the new C compiler, and so through the generations of compilers, it can propagate malware, and this was never actually exploited, but it highlights how the trust assumptions are transitive throughout the supply chain, and you have to trust the compiler of the compiler, a bit like living beings are not purely the results of their DNA, but they also need to be gestated in order to exist. Now, let's look a bit at threat model. I'm not here saying that if you are coding web games, you should be worrying about Ken Thompson or doing complex stuff.

This is fine, this is a very contained piece of software, it's not going to do a lot of damage, and you also don't need an audit on that, but a lot of infrastructure, especially blockchain infrastructure, has already been targeted in supply chain attack, so I think there's value in trying to understand how our supply chain works and how to make it more secure. Now, to introduce the part of my title, which was verifiable computation applied to the software supply chain, verifiable computation are all of these methods that we have to outsource a piece of computation to an untrusted party and be able to verify that the untrusted party actually computed the thing correctly without re-executing ourselves. For example, you have CK-proofs, you have certain crypto-economic schemes that I will go back to later, and I noticed that a lot of people work on this, but they never talk to the people who are on the software supply chain, so there's kind of a siloing of research, and I think there's value in trying to connect those two areas to try to bring value from one side to the other, and that should bring us to my experiment. So, in one phase, I put a compiler inside of ZKVM and made it work that way. In ZKVM, if you may notice, it is a system that can run computation and produce zero knowledge proof that they were executed correctly.

So, it is a form of verifiable computation with no trust assumption and just cryptographic assumptions. Now, what I would like to see one day is that people can verify the cryptographic proofs and look at the source code without having to compile everything themselves. And this means that you can still have a build server, but it can be untrusted, which is an upgrade from the current situation. I use the RISC-V ZKVM. It's a RISC-V ZKVM that I found off the shelf.

I didn't choose it for any specific reason, but it worked for me, so that was good. And the compiler I started with is called HEX0. It's a project that is trying to make the smallest compiler possible, and it can just read hexadecimal with comments and output a program. The goal is to be able to bootstrap from this very small compiler all the way to much bigger compilers by compiling less minimalistic compilers as you go along. And there already existed a RISC-V Linux version, so this made my work easier.

I could just port it and port those components to RISC-V inside of the R0 VM. So, I made a little demo. There's no live demo, but I can explain it, which is almost better. So, I had a tool that can verify bundles that contain source code, executable, and a proof that the executable came from the source code. And I made a Hello World for Linux x86-64.

So, if you want to go see the demo, you can build the proof yourself. You can verify the proof that I give you, and if you're satisfied with the proof, you can also run the Hello World. Now, the caveat of this approach is that currently it takes 10 to 20 seconds to generate a bundle with the proof, which is not great, of course, especially for such a simple program and compiler. And ZKVM teams are making new versions a lot. So, I did this on RISC-V version 1, and they already announced version 3.

And it's also not compatible with any other ZKVM that I'm aware of. So, we have this standardization problem, which makes this approach a bit complicated at the current stage. Now, there are also alternative approaches that we could look into, because this idea of I'm just going to use zero-knowledge proof is a way to make something that is maximally paranoid. But we can find more pragmatic and incremental approaches to still improve security compared to the status quo. For example, we could compile inside of a trusted execution environment like Intel SGX or something like that.

There's still going to be a central build server, but it's going to be harder to compromise it because you have to compromise the TE. So, strictly speaking, this is an improvement. And this also has very little performance impact, most likely, and probably less complexity also than doing this inside of a ZKVM. Something a bit more further along in the spectrum are those crypto-economic models, where you can assume that the majority of the build servers, you have multiple build servers or multiple blockchain validators, and you assume that the majority of them are honest, and so you can accept builds that were signed by the majority. You can also use these systems like ELLs, which is used in Polkadot, that can select a subset of validators and then check their work with another subset of validators and achieve some more scaling with that technique.

And you can select your build servers either based on token stake, which is what we usually do with the blockchain, but you can also imagine a system where a bunch of individual human developers come together and say, okay, we are all going to each run a build server and we're going to make a supply chain that way. This was an idea that was suggested to me by Jeff Burgos, by the way. Very, very interesting idea. Now, another last thing I want to point out is that we don't have to use one of those approaches. We can have models where you combine multiple approaches.

This example is the proposed finality gadget for the Ethereum R1 roll-up, and what it does is it combines ZK, CEs, and optimistic challenges in such a way that two of those systems have to fail in a very specific way for the roll-up to accept an invalid state transition. So you could imagine doing something similar for a supply chain with, for example, a combination of TLE and majority honest model. Now, let's do a little bit of science fiction. If you like trains, you might have seen one of these track playing machines that is able to lay down its own tracks and then roll all the way onto them. I think this is fascinating, and this is also something we could do in the blockchain space, where the blockchain itself, after it has scaled its ability to do verifiable computation a lot, can start compiling its own infrastructure, its nodes or its front ends, and hosting them that way and progressing forward while proving that its software is correct.

Of course, this is a long shot, but there's a way you can start from hex zero and compile yourself all the way to some of the Ethereum client software already. So maybe this is something we can do at some point. Now, how do I conclude a talk like this with a lot of experiments? What I came up with is, you know, you can just do things. You can just go grab an off-the-shelf ZKVM and do things like that without asking anyone's permission, and I think it's fun.

I think open source and the Infinite Garden are a nice place to do this. And with that said, I will leave you with the link to a page that has the demo that I said, and also a Telegram group where maybe if you're interested in this topic or if you want to give me feedback, you can come and we can keep discussing those topics after Dapkone is over and we've gone home. And that's it for me. I am open to any questions you might have. Thank you so much, Julie.

Open, I see questions. Yeah, so for questions. Yeah, I didn't get the example, the idea of the train laying tracks, and it seems very interesting. Yes, so the idea is you agree that you can compute stuff on chain, right? So what is the computation you do on chain is taking the source code, which anyone can more easily than the binary read and verify, and then you run the compiler itself on chain and you get an output.

Now you have this output is a client for the blockchain, so you can download it and replace your clients with an upgraded version that can continue verifying the blockchain as you go. So you put the track and then you roll on top of the track. Okay, yeah, it's interesting. All right, more questions? Do you think that this could be an interesting use case for verifying smart contracts?

I think smart contracts, I think, yeah, I think it's even more doable because smart contracts are much smaller in terms of software than a lot of clients, and that's something I'm open to looking into in the future. Okay, do you have, do we have more questions?