From Packets to Privacy: Understanding and Evolving Network Security

On Twitter, you know I promised a joyful and uplifting presentation. I lied. This is going to be pretty pragmatic and realistic. I'm going to tell you about how to use Ethereum and specifically smart contracts to do something useful and interesting with privacy. So, a couple of key topics for today.

Number one, let's press the magic button. We're having technical difficulties. So first item I want to talk about is the business case for privacy. And as soon as the clicker works, we will advance to the next slide, which it's not doing. It's not doing that.

So anyway, I'm going to talk from a little bit of memory. So pretty much every business agreement comes down to something very simple. I've got money, you've got stuff, and I would like to exchange my money for your stuff under the terms of a business agreement. And the challenge with that is that for companies, they want that information to be private. How much money you have, how much stuff you have, what you're buying, where it's going, that's all like super secret, sensitive business information.

Oh, it's working now. So business case for privacy. As I said, companies want to do very simple stuff, exchange money for stuff under the terms of an agreement with privacy. And blockchain is actually this incredible piece of infrastructure for doing this way more efficiently. So we can tokenize the money, we can tokenize the stuff, and we can turn all the business terms and conditions into a programmable set of rules that can be implemented very easily.

To make this work, however, we need two kinds of privacy. Number one, we need privacy about the transfer of assets and payments. How much I'm paying you, what you're giving me, where it's going. That stuff needs to be private. But secondly, we also need privacy for the terms and conditions of our agreement.

It's really important. If I can read the agreement between company A and company B and it says I'm going to buy 500 widgets at $10 a piece, I'm going to kind of give away all the information that you need to know anyway. So we need these two kinds of privacy. And in particular, pseudo-privacy or mixers or things like that aren't really good enough for businesses because a lot of companies do lots and lots of recurring business with each other, and eventually, if you do enough of these types of transactions, you're going to be traceable even in a public mixer environment, and most business assets are not fungible tokens. Money might be fungible, but the things that you're buying are often not fungible, and anything that's non-fungible becomes instantly traceable in a public environment.

So it's really hard to design without leaking information, and that's some of the stuff that we've really been working on. Now, before I talk to you about how, I just want to take a second and talk about what is the value proposition? Why is this worth doing? And I want to share with you a very specific example, which is around the use of smart contracts for business automation. About five years ago, EY and Microsoft worked together to replace the procurement system for the Xbox video game network with a set of smart contracts.

And the idea here was to replace an existing system which had a traditional ERP system, and it was sort of semi-automated. At the end of each month, they would look at all the transactions, and they would manually apply some of the rules that they had implemented between Microsoft and their 3,000-odd gaming suppliers. Well, it took, on average, in the old system, about 45 days to calculate how much they were owed and go through all the individual contracts and special rules. When we turn those into blockchain-based smart contracts, the beauty of these kind of smart contracts is they're basically scripts, right? It doesn't matter.

As long as the rules that you and I have agreed upon are logical and clear, then I can automate them and they can run properly. And the result was that we basically took a process that used to take 45 days and we brought it down to about five minutes, right? That is a good improvement. And we did it for about half the cost of the existing system. So the value proposition of being able to take a complex business agreement and turn it into an automated smart contract is incredibly large.

The problem that we had at the time was we didn't know how to do this under privacy on a public blockchain. Eventually, where we want to go to is this ability to put together tokenization with smart contracts and in a way that you can create a complete business model that's running on chain. In this picture, what we have is a very typical supply chain, right? Raw materials, they get manufactured, they get transported, they get put in a warehouse, they get sold to a customer, and then they get supported. Now, every single item in a traditional manufacturing supply chain we can represent as a token.

Some of the things are fungible tokens, most of them are non-fungible tokens. Anything with a serial number becomes a non-fungible token. And so basically in this picture, stuff moves from left to right, and money moves from right to left, and a set of smart contracts governs this movement of the process away. And not only can we run the business process for about half the cost, but we can also run the supply chain much more efficiently. We think we can typically, if we move from traditional supply chain models to a tokenized supply chain model with all the rules of preventing double spend, you can actually cut maybe as much as 20% of the inventory from your supply chain and have the same service level.

So in short, this is worth crazy amounts of money. Now, let's talk about a specific use case that we are implementing for clients and rolling out worldwide, and this is renewable energy. And I want to talk about why renewable energy is such an incredible use case and application and how we got there. I want to start with the roadmap for privacy that we are working on at EY. We've got two applications that we're building.

I talked about two types of privacy that we are working on at EY. We've got two applications that we're building. I talked about two types of privacy that we want to do. One is privacy of moving stuff around, and the other is privacy of the terms and conditions of a business agreement. So for the privacy of tokenization and moving things around, we have created a Layer 2 ZK rollup called Nightfall.

Nightfall allows you to move around fungible and non-fungible tokens. It's an EVM compatible layer two, so it actually can run on top of the main net. It can also run on top of, say, a layer two as a layer three. So Nightfall is for moving stuff around. Starlight is a transpiler that basically takes a Solidity Smart contract and turns it into a set of zero knowledge circuit.

Our idea, our concept is to get each one of these pieces working independently and then bring them together so that you can have this full business to business kind of complex road map. Both of these, to be clear, are, although they are largely developed by EY, we have put them into the public domain. They are public domain, open source contributions to the Ethereum ecosystem. There are no proprietary gotchas here. There are no surprise, like, you know, special terms and conditions in the open source license.

It is full public domain. We have relinquished all ownership to these assets. Thank you, sir. That is how much we love and believe in the Ethereum ecosystem. And we have been on this journey for a while, by the way.

I know we're getting a lot of attention from the Noir program that's launched this week. I tell you that we started about the same time as the folks at Aztec, and most of our team is across town from them in London. And one of the things that delights me so much is to come to DevCon and see how much competition is now in the privacy space. I really believe that even if we lose in a competitive race with some of the other solutions, we win. But I'm not yet given up on losing.

We have been on this journey for a while, even though the numbers didn't sort of look out correctly. We started in 2017. And here we are in 2024. We're on Nightfall version 4. Nightfall version 3, which is currently in production, is a ZK optimistic roll-up.

ZK for privacy, optimism for finality. Nightfall version 4, which we showed off earlier this year and will be in production next year, is a ZK, ZK roll-up. So one ZK for privacy and one for instant finality. All right, let's talk about renewable energy and exactly how we implemented this. So the way that renewable energy contracts work, and the reason why they're such a good candidate for zero knowledge applications is that they are kind of complicated.

And this is a simplified version. Very simply, you got a power buy. You got somebody, they got a factory, they want electricity, they want a lot of electricity, they're going to buy it from somebody. But maybe they're a large company, they have a good social responsibility plan, they have committed to become carbon neutral. So what power buyers do is they reach an agreement with a renewable energy seller, somebody who's got solar facilities, battery facilities, whatever it is that's renewable and fully green.

Here's the problem. Electrons are fungible, right? You might want to have your locally produced organic artisanal electrons, but actually the way it works is you have to take what the power company is giving you. And so what happens is the power buyer basically buys electricity from the power company at whatever the market price is in their environment. The power company in turn buys power from a whole bunch of suppliers.

Some of them are very green, some of them are not so green. The agreement exists between the renewable seller and the renewable buyer. And what the smart contract does is it basically keeps track of the market price that the power buyer paid to the electric company and the difference between that and the agreed upon price and then they settle up usually every month or so if one party owes the other. And there's usually complex terms and conditions like a commitment to buy a certain minimum amount of power in the grid or a certain maximum price that they have to pay. And the idea is that they are basically providing the incentive and enough financial value to the renewable provider to structure long-term investment.

And these renewable energy contracts are incredibly important because a lot of these solar facilities, wind facilities, they could not be built without the advanced commitment of buyers like these kinds of factories or other companies that are committed to be carbon neutral. These advanced commitments that they make, they're often five or ten years at a certain price for a certain number of megawatts. These are incredibly important to guaranteeing the revenue that provides the investment funding to build these kinds of facilities. Right, so that's what the structure is. So a little bit like, you know, video game contracts with thresholds and minimums and rebates, renewable energy contracts can be quite complex.

To build this renewable energy contract, we went through a multi-step process, which I want to explain. We started by just creating a Solidity smart contract without privacy that followed the terms and conditions that we wanted to implement. And once we had that working, we created a modified Solidity application, which we call a Solidity application. And all we did was mark up the variables and the logic that we want to be private. So we have a little guide on how to do this.

And then we put that into the Starlight transpiler. And what that does is it spits out a zero-knowledge circuit, a whole application that you can run on-chain, which we call a ZAP, right, for a zero knowledge app. And please don't ask me who is in charge of our naming, but there's a lot of Zs in there. And so the idea here is to keep it very simple. And Starlight itself came out of a really important learning experience we had.

So about three or four years ago, we tried to teach our research team, our PhD mathematicians, tried to sit down and teach our developers how to write zero knowledge circuits using tools like Socrates. It was a spectacular train wreck. Like, it just did not work at all. Our solidity developers were like, this is too difficult. I don't like this.

I don't want to do this. And so we went back to the drawing board and we said, we need to find a way to make this much easier and much simpler, and you just should have to do some minor changes to a Solidity smart contract. And that's how we ended up with Starlight. So Starlight is really designed to be as easy as possible. It allows you to take a Solidity application that you know already works and turn it into a zero-knowledge application.

You still have to think very carefully about how to design it in such a way that you're not going to leak really sensitive metadata. Because if you're not careful, you will accidentally end up leaking metadata. But the goal is to get to the point where anybody can do applications. As I said, it's public domain and open source. You can go and try it out yourself.

There are currently about 100 companies worldwide that are designing and testing applications using Starlight. And in particular, we've been working very closely with the Central Bank of Brazil. We have about 60 or 70 banks in Brazil that are testing out Starlight-based applications. And for the last year, we've been working really hard to refine the Starlight application development process and tooling. Right now, where we are is that we are in a kind of a stateless environment.

So the Starlight application receives data, it calculates the amounts owed, but it does not store anything on-chain, it doesn't store any commitments even off-chain, it's a stateless component, and transactions are relatively inexpensive, provided you deploy them on a layer two network. The future path is that we want to integrate Starlight with on-chain payment and with some level of off-chain stateful storage of things like the amount of electricity consumed and the amount of money paid so that you really have a proper continuous record of the entire set of business transactions. But that's the goal. As I said, we're following a kind of crawl, walk, run strategy, and the goal is to start and build things that are very pragmatic and useful to business users rather than try to bite off the whole thing at once. So we have fundamentally a bit of a different approach than, say, Aztec or some of the others who I think have a very ambitious and kind of complete approach.

We welcome participation. Our content, it's public domain, it's open source. All of our tools are open and available, and we publish them on the EY blockchain site on GitHub. So that's really important to us. We have many, many contributors, but underpinning all of this is kind of a long-term commitment from EY to invest in privacy because we believe it is the one thing that enterprises need in order to get fully engaged with on-chain business and to give up this fixation that a lot of people have with private blockchains.

Lastly, we are here. We have an impact booth. Our research team is here, and quite a few members of our engineering team as well. We would love to talk to you about how to help you make privacy-enabled applications that are regulatory compliant. They will not end you up in jail.

I feel like I myself would not do very well in prison, so I don't want to go there. And then lastly, I'm ready to take a couple questions, but I also want to share with you my little QR code. It will take you to a website that will give you what we call a proof of Paul NFT, which is minted on the Polygon proof of stake blockchain, and we made a special one just for DevCon. So, am I on time? Have we got enough time for a couple minutes of questions?

Yeah, we've got some time. We've got about six, seven minutes. Perfect. So, we've actually got a lot of questions, but feel free to ask some more on here. So, it looks like the top question here is, why did you build Nightfall rather than contribute to other open source ZK roll-ups?

Well, at the time that we got started, there weren't any other open source ZK roll-ups. I mean, this was seven years ago. And by the way, almost all the ZK roll-ups that are out there are ZK for scaling, not ZK for privacy. And in fact, one of my frustrations was, you know, seven, eight years ago when we got started down this path, everyone's like, hey, we got to fix the scaling problem for Ethereum. And while I agree with that, and I'm really pleased with the progress that Ethereum has made on scaling, I think it's incredible.

And the end of the day for business users, there's no scaling. The scaling problem is not a problem until you solve the privacy problem. Without privacy, no business user is going to touch Ethereum. And I want every business agreement in the future to be on Ethereum. Awesome.

Well, how do you tokenize real-world assets without them being centralized? That's a great question. So I think, let's see here. I guess the quick answer is, I think for individual companies, those assets are going to be, if you're tokenizing your own assets, it is going to be, to a certain degree, centralized in your company. And this is kind of an issue that we've talked about a lot with other people, is in certain circumstances, there are some things where only one participant really knows the status of that asset.

The only company that knows where your UPS or FedEx package is, is UPS or FedEx, right? And so you have to accept that. And one thing that is a really cool thing is there's a process, a well-accepted business process from the world of TradFi. It's called a SOC audit, right, which is a systems and organizations control. And what it is, is you have an independent organization come in and assess your reporting mechanism.

And so in the cases where you can't have proper decentralization, you should have external auditing and testing to make it more reliable. And I think we have time for one more question. Can you talk about the Brazilian CBDC and how the experience is of using Starlight on Drex? And for my sake, can you explain what Drex is? Yes.

So Brazil has a really cool, they've had some really cool thoughts about their CBDC. So as many of you may know, CBDCs are really struggling with acceptance and success because they don't offer a lot of value. The Brazilian Central Bank has taken note of that and they've really thought a couple of steps ahead and they've said, you know what, if we want our CBDC to be successful, we really should consider making it programmable in an EVM environment, which I think is fantastic. Now, I have urged them to go one step further and just plug their whole CBDC into public Ethereum. I'm not sure they're ready for that yet, but what is exciting about this is that in this environment, Brazil has clear banking secrecy laws, and so if I want to trade with you, if I want to do a transaction with you, the Brazilian government doesn't just say privacy is nice.

The Brazilian government says you must respect the privacy of your users. You must build privacy enabled applications. And so they have been testing a number of different privacy solutions. What I think is really exciting about Starlight compared to some of the other ones is that it is...our whole goal in building Starlight Nightfall is to be 100% compatible with an EVM environment where you use native Ethereum tokens like ERC20s and 721s.

You preserve all of the true native Ethereum functionality around like the prevention of double spend, the proper management of assets. Our goal is not to create something new. It's to make these things fully compatible and transparent in a very straightforward way. So we want to make it simple. And I think that's a big part of the value proposition.

We'll see how Drex evolves, right? But I think this idea of like fully programmable privacy respecting kind of CBDC EVM is quite exciting. Thank you, and I actually lied. You have about three minutes left for this Q&A. Oh, fantastic.

So it looks like we've got a couple other questions. What made you choose ZK over Oasis Sapphire or the Secret Network? I assume that's because you guys started back in 2017. It's partly because we started back in 2017, but it's also because, again, we want true, full, native privacy, and one of the things that's also really important to us is that we don't want any kind of off-chain systems that are required. We don't want any special security, like hardware security modules or proprietary tools.

Our goal is to have a fully open source ethereum native privacy application with no kind of built-in tax or license or you know system so that was our goal is to be completely open and another question it's more applicable but like I'm curious all the smart contracts that you've developed for NIFOL and Starlight, are they compatible with like just any smart contract and being converted into ZK circuits? Or are there any changes required to satisfy those constraints? So there are some changes. And basically, the Starlight kind of user guide explains how to make those changes, you really do have to be careful. You know, if you design, what you end up with is like a black box.

And so if you're not careful, you know, if I have a black box and I have only two parties in it, and I put in $10 and you put in two widgets, it doesn't matter how fancy the logic is in there. From an external point of view, you know that your contract is basically saying the pricing is $5 a widget, right? You've leaked all the meaningful information. So you have to really carefully design your application so that it is optimal for preserving privacy. Before I've got one minute left, I want to talk about this one around privacy for governments and how regulators view this kind of thing.

And here's, I want to share with you kind of the one really, really important insight that we have learned in terms of working effectively with regulators. It's really important to help them understand privacy and anonymity are not the same thing. So when we design NYFO, which is our privacy layer two, in order to use it, you need to have an enterprise identity certificate. This doesn't mean that your transactions are visible and there are no back doors in the system, but externally, governments and regulators can see who is transacting. They cannot see what you're doing.

They cannot see with whom you are transacting, but they can see that you are transacting. These enterprise ID certificates, X.509s, can only be issued to companies that can pass basic backgrounds and sanctions checks as well. So I would not call it, by the way, KYC, but it is identity. It is a legally accepted form of business identity in many countries, including the United States.

And if a regulator comes to you, you can tell them what you're doing and, very importantly, you can also prove to them that what you're sharing with them is truthful. So I think we're done.