Rust x Ethereum Day 2023 at The Foundry SF

Jason Vranek presents on "Secure-Signer"

Yeah, as you can see by my desktop, I'm a big Puffer fan.

So, okay, I'm gonna talk about Secure Signer today.

So this was the tool that we built for the validators within our pool, but it's also applicable to actually all proof of stake chains as well as people outside of the Puffer pool.

So the motivation here, you can kind of think of it like a hardware wallet for your validator and the goal here is we want to enhance the validator key management through trusted hardware.

And so the goal here, there's multiple goals.

1 is protecting honest validators from themselves because a lot of these past slashing events have been because of user error, like running multiple validator clients and signing conflicting messages.

Another thing is to provide more security in case your actual validator is corrupted or you're trying to be malicious and attack the chain.

And another is to reduce the severity of these consensus client bugs.

We saw Ethereum lose finality for a little bit a couple of months ago, luckily it wasn't worse and didn't lead to slashing but if that were the case, it's better to have these extra defences in place.

Another thing here is to help increase validator software diversity, so we're trying to just like we have lots of consensus clients and execution clients, we want to add to this remote signing kind of class of software and have people build more diverse clients.

So the outcomes, if we're able to achieve all this, would be to help reduce equivocation across Ethereum, which ultimately leads to a more stable chain.

And then actually reduce operational risks for validators in general.

And this really helps the solo stakers who have kind of less capital to play with here.

And finally, I guess for everyone here, trying to help increase the design space for staking infrastructure.

So yeah, having different remote signing tools in the mix really adds to this.

So right now, it's developed as a SGX enclave, and we're planning to diversify that in the future but it has some primary responsibilities of essentially maintaining this EIP 3076 slash protection database, do the BLS keygen and signing as well as being able to speak the language of the ETH2 beacon chain data types and big shout out to the Web3 signer team from ConsenSys who really kick started all of this, they essentially have the same thing implemented as Java program, so we were able to reuse a lot of the same APIs to speak to all these consensus clients.

So we built this fully Rust native, we used a web server and the main thing here is being able to interface with consensus clients and we used this convenient libOS abstraction layer for actually building the enclave but moving forward we're trying to actually have a modular signing back end that allows you to interchange different types of enclaves besides SGX, because we want to diversify on the hardware manufacturer, and then be able to integrate with things like DVT, and actually 1 thing that we're really excited about is trying to break up this mono repo into lots of smaller crates that we can open source and contribute back to the community.

We've been integrating a lot of Lighthouse's crates into our project.

This is Puffer's Discord, so We're a new protocol getting started.


Speaker 0: Okay, thank you. Yeah, as you can see by my desktop, I'm a big Puffer fan. I'm a CTO at Puffer Finance. So, okay, I'm gonna talk about Secure Signer today. So this was the tool that we built for the validators within our pool, but it's also applicable to actually all proof of stake chains as well as people outside of the Puffer pool.

So the motivation here, you can kind of think of it like a hardware wallet for your validator and the goal here is we want to enhance the validator key management through trusted hardware. And so the goal here, there's multiple goals. 1 is protecting honest validators from themselves because a lot of these past slashing events have been because of user error, like running multiple validator clients and signing conflicting messages. Another thing is to provide more security in case your actual validator is corrupted or you're trying to be malicious and attack the chain. And another is to reduce the severity of these consensus client bugs.

We saw Ethereum lose finality for a little bit a couple of months ago, luckily it wasn't worse and didn't lead to slashing but if that were the case, it's better to have these extra defences in place. Another thing here is to help increase validator software diversity, so we're trying to just like we have lots of consensus clients and execution clients, we want to add to this remote signing kind of class of software and have people build more diverse clients. So the outcomes, if we're able to achieve all this, would be to help reduce equivocation across Ethereum, which ultimately leads to a more stable chain. And then actually reduce operational risks for validators in general. And this really helps the solo stakers who have kind of less capital to play with here.

And finally, I guess for everyone here, trying to help increase the design space for staking infrastructure. So yeah, having different remote signing tools in the mix really adds to this. So what is it? So right now, it's developed as a SGX enclave, and we're planning to diversify that in the future but it has some primary responsibilities of essentially maintaining this EIP 3076 slash protection database, do the BLS keygen and signing as well as being able to speak the language of the ETH2 beacon chain data types and big shout out to the Web3 signer team from ConsenSys who really kick started all of this, they essentially have the same thing implemented as Java program, so we were able to reuse a lot of the same APIs to speak to all these consensus clients. So yeah, on to some Rust stuff.

So we built this fully Rust native, we used a web server and the main thing here is being able to interface with consensus clients and we used this convenient libOS abstraction layer for actually building the enclave but moving forward we're trying to actually have a modular signing back end that allows you to interchange different types of enclaves besides SGX, because we want to diversify on the hardware manufacturer, and then be able to integrate with things like DVT, and actually 1 thing that we're really excited about is trying to break up this mono repo into lots of smaller crates that we can open source and contribute back to the community. We've been integrating a lot of Lighthouse's crates into our project. And yeah, thank you. This is Puffer's Discord, so We're a new protocol getting started.

See all Paradigm transcripts on Youtube

Rust x Ethereum Day - Secure-Signer