DAPPCON 2025: Applying Verifiable Computation to the Software Supply Chain - Julie Bettens

Transcript

You're welcome. [Applause] Thank you. So nice. So uh I'm Julie. I use she pronounce. And to quickly introduce myself, I am currently a smart contract auditor with chin security. 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 am also a developer at randamu 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 soft 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 next talk masquerading as a blockchain talk? Yes. Are the exit 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 a software open source software distribution. Maybe you get it on CDROMs. It's a bit old. Maybe you get it through IPFS and torren. 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 uh 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 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 also interpreted uh 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 atestation.

Now the first one reexecution 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. Now 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 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 at a station. 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 solar winds hack which happened in 2019. It happens that state sponsored hackers were able to hack solar winds 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 demon 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 machine and they managed to put malicious code into package releases which are almost source code but not really. It's a a bit of a strange thing in the in the Linux pipeline and many Linux distribution were affected and we 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 uh 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 front end for safe wallet was compromised and this was enough to trick by bits signers which were responsible for their assets into signing a malicious transaction that compromised their wallet. And just like that $1.5 billion dollars were gone and in the pockets I think it's North Korea.

Yeah, it's not Kore that did it. And so this was a supply chain attack, right? The front end was a malicious version of the front end was distributed through the safe wallet website. Now there's also a a theoretical paper that I like by Ken Thommpson. It is a special version of the C compiler that has the ability to when it itself compiles a C compiler inject the backtory into the new C compiler. And so the through the generations of compilers it can propagate uh 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 uh living beings are not purely the results of their DNA but they also need to be justestated in order to exist. Now let's look a bit at that model. I'm not here saying that if you are vi coding web games you should be worrying about Ken Thompson or doing complex stuff. This this is fine. This is a very contained piece of software is not going to do a lot of damage and you also don't need an audit from that. But a lot of uh infrastructure especially blockchain

infrastructure has already been targeted in supply chain attack. So I think there's value in trying to understand how our our supply chain works and how to make it more secure maybe. Now to introduce the part of my title which was a 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 interested party actually computed the thing correctly without reexecuting ourselves. For example, you have ZK proofs, you have certain cryptoeconomic 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 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 phrase I put a compiler inside of a ZKVM and made it work that way. So a ZKVM if you 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 those cryptographic proofs instantly 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 risk zero ZKVM. It's a a risk 5 uh ZKVM that I found off the shelf.

It's I didn't choose it for any specific reason, but uh it worked for me, so that was good. And the compiler I started with is called Hex Zero. It's a project that is trying to make the smallest compiler possible. And it can just read hex a decimal with comments and output a program. This is the goal is to be able to bootstrap from this very small uh compiler all the way to much bigger compilers by compiling less minimalistic compilers as you go along. And there already existed Risk 5 Linux version. So this made my work easier. I could just port it and port this those components

to Risk 5 inside of the RZVM. So I have I made a little demo that so there's no live demo but I I can explain it which is almost better. So I had a a tool that can verify bundles that contain source code executable and a proof that the executable came from source code and I made hello world for Linux x8664. So if you want to go see the demo, you can uh 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 LOL. Now the caveats of

this approach is that currently it takes 10 to 20 seconds to generate a bundle with the proof which is uh 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 ZK on risk zero version one and they already announced version three 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 uh 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 cryptoeconomic 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 have accept builds that were signed by the majority. You can also use these uh systems like elves which is used in polka dot that can uh select a subset of validators and then check their work with another subset of validators and achieve some more scaling with that uh technique. And you can select your build servers either based on token stake which is what we usually

do with a blockchain. But you can also imagine a system where a bunch of uh individual human developers come together and say okay we are all going to to each run a build server and we're going to make a a supply chain that way. This was an idea that was suggested to me by Jeff Burgles 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 rollup. And what it does is it combines uh zk and optimistic uh challenges in such a way that two of those systems have to fail in a very specific way for the rollup to accept an invalid state transition. So you could imagine doing something similar for a supply chain with for example a combination of TE 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 laying 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 maybe one day 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 uh proving that it's uh 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 ATM client software already. So, maybe this is something we can do at

some point. Now, I 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 a an offtheshelf ZKVM and do things like that without asking for anyone's permission. And I think it's fun. I think uh open source and the infinite garden are a nice uh place to do this. And uh with that said, I will leave you with the link to a page that has uh 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 uh you can come and we

can keep discussing those topics after Dapcoin is over. And we've gone home and uh that's it for me. I am open to any questions you might have. [Applause] Thank you so much, Julie. Uh, open. I see questions. Yeah, let's go for questions. Yeah. Uh, I didn't get the example the the idea of the train laying tracks and it seems very interesting, but can you explain maybe again? Yes. So the idea is you you agree that you can uh you can compute stuff on chain, right? So what

if the computation you do on chain is taking the source code which anyone can more easily than the binary uh 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 client with an upgraded version that uh that can continue verifying the blockchain as you go. And so you you put the track and then you roll on roll on top of the track.

Okay. Yeah. Bit uh it's interesting. Right. More questions. Yeah. Another one. Do you think that this could be a 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 are much smaller in terms of of software than a lot of clients and that's something I I'm open to to looking into in the future.

Okay. Do you have do we have more questions?