Transparent by Default to Private by Design: Navigating Ethereum’s Privacy Primitives | Guy - Fhenix

Hey folks. Um, glad to see everybody here. I'm Guy. I'm the CEO of Phoenix. We built privacy rails for payments, stable coin, and DeFi applications.

And I'm going to talk about the need for transitioning from uh transparent by default to private by design and give you like a glimpse of the different primitives that we're using today in Ethereum ecosystem to provide confidentiality. I think the first thing that I want to talk is like why privacy. We've been talking a lot in the last couple of days about different privacy technologies, but I think we want to start by understanding what is the value and and actually what have we seen in the last two years around privacy and and I do feel that when privacy just started, it was more of a technology that was trying to find like a product market fit. Um, thinking about what happened in the last year with the growth of stablecoin adoption, the payment space, the institutionals that are moving into web 3 and even the transition from a some semi- idealist kind of approach to more of a pragmatic approach, the need for privacy became prominent. Um, you cannot do a payment application with stable coins with everything is like public by design and that is a really good thing for us privacy companies, but it actually also drives a lot more demand.

Um, having said that, we're in 2026 and you would imagine that many people still understand the difference between anonymity and confidentiality. U, this is literally like a Telegram uh, conversation that we have with a team that's building on us and this is like from two weeks ago when they were asking us, okay, so we're building on you guys, but are we getting just confidentiality or also anonymity? And that's when I said you know what maybe this would be a good talk here to just give an overview of the difference between anonymity confidentiality and the different primitives that are there to solve it. So important to mention privacy has two dimensions anonymity and confidentiality. Anonymity hiding who you are that's a core narrative on the uh web3 ecosystem.

And then confidentiality which is more about hiding the content of the transaction. Uh I'm not going to talk a lot about anonymity. Actually I think the previous call previous talk did a good job. Um but just to make it very very clear we're talking about the ability to hide the identity of the user. So the sender and the receivers are unknown and this is typically achieved through techniques like Rick signatures zero knowledge stealth addresses and mixers uh that are out there.

Uh rail gun and a few others are really doing an amazing job in that respect. We're here actually to talk about confidentiality or transparent by default. I'm sure you know this is a privacy session. Everybody here probably knows everything on the blockchain is transparent by default. You have a block explorer.

You can actually see all the content of the transactions that are out there. So let's look at an example. Um and this is the typical transaction life life cycle. we have the transaction being submitted and then the tracking the transaction being ordered and uh in the sequencer and being executed. The key challenge is that since everything is out there in the public this is a really good opportunity when transactions are being ordered to extract me uh a malicious actor Bob in our case can actually see the transactions in the mele and can frontr run them to achieve me.

The uh problem is not so much just about encrypted meles and transaction ordering. It's also about like how do we solve it? And the way to address it is by offering an encrypted mele. If the transaction is encrypted, then the malicious actor can see the content of the transaction in the mele and cannot frontr run it. So the order that you would do is you would encrypt the transaction on the user side.

You would pro an encrypted transaction. a transaction would be committed and only then after the block has been finalized you would decrypt it and execute it. So encrypted meles definitely a way to mitigate me. Another example is sale bid auctions. This is like a typical example that we always like to give when we're talking about confidentiality.

Um, it is quite easy to understand that if you're bidding and your bid is out there in the clear, then anybody who can see the amount that you've bid can just provide a higher bid and just win the bidder. And this is definitely not ideal for the person who's participating in the sale bid auction mechanism. We've seen the demand for like seal bid auction growing quite a lot in the last couple of months with also some launchpads that are using it for public sales for uh for community. The way to address it is again by having an encrypted transaction. uh the encrypted of the transaction is uh part of the bidder's proposal and in that case the competitors can see the amount that you've bidded as as such cannot really like offer an alternative and this is really good for like price discovery uh uh for both the biders and the auction organizers in both scenarios the order that we follow is encrypt the transaction compute over the transaction and then decrypt the transaction Okay.

So, how do we solve it? Um, there is like a threeletter acronym salad, MPC's, [ __ ] Uh, I'm going to walk briefly through each of them and then at the end offer like a framework if you're building a confidential smart contract of like what type of decisions you need to think about. Um, so just you all know in my previous life I actually managed the team at Intel that was responsible for TE building TE's. I love TE's. I think they're great.

I think they're uh uh extremely valuable and and typically when you want to operate with a trusted execution environment, it allows you to compute inside a trusted hardware. So the flow that you would uh execute is that you would take the transaction or the data that you want to compute on. You would encrypt that data. You would send that encrypted data to the trusted execution environment in which it will actually be decrypted and compute as a decrypted content inside a trusted execution environment only for then to have the computation result encrypted again and sent back as a as a result. It's very fast.

The computation is extremely fast. It's very cheap. But the key challenge is that it's also pruned for attacks. And for those of you who follow the TE space, um about two months ago, researchers showed that by just building a hardware device in less than $1,000, they were able to listen to the memory and extract keys from the trusted execution environment. How do you mitigate it?

In most of the attacks around TEES, typically you need your hands on the physical hardware itself. So if the TEEES are managed in the cloud and this is where proof of cloud is coming in that reduces the risk quite a lot um open sourcing the TEES making sure that you see that the the code of the TE itself is secure definitely helps and also like a multi- vendor strategy but the gist of this is TEES are very fast they can offer secure computation but if you're running uh a huge amount of of of data or confidential data there that has high risk you probably want to look at like an alternative mechanism. The other cryptography that people may have heard of multi-party computation um the ability to compute over data but having the key that is being used to do the computation shared among different entities in a way that each of them computes and none of them can actually see the origins of the data. It typically requires like non-polluding parties to work on it. Um it is definitely a good cryptography technology to offer secure computation.

The key challenge with MPC is that there is a lot of communication overhead. And what it means is that if you have a limited amount of participants that do the computation, it works very well. We see it with wallets and custodians. But if you want to really move into like a decentralized environment where you have tens or hundreds of nodes computing together, this is where MPC actually is not very scalable. Even though there are now um progress quite a lot with like optimized protocols and garbble circuits, if some of you may have heard of it as a faster iteration for MPC and then we have the new kid on the block fully encryption uh which is what we do.

Um I I call it as a new kid on the block even though it's been out there for like 15 years. Um a funny story to say is like I was in consensus last week and uh we went and interviewed a couple of peoples and asked them like what does homorphic mean. Um not a lot new. Um one even said that it sounds like a dumpling with pork and chocolate. Um but it is a very efficient cryptography uh that allows you to compute over encrypted data.

So let's explain briefly like how it works. Uh encryption 101 u without homorphic encryption typically you have your key you encrypt uh kept in Ethereum in that case and you get an encrypted data and when you want to decrypt you just use the key to decrypt the data and you get the same result. Fe offers you now another layer. So you start by encrypting the data but this time you encrypt it homorphically and now you can actually also compute over that encrypted data. In the example here you have a prompt that says you know let's change the color of the image from uh uh whatever this is purple to black and you get a respon a result which is encrypted.

So it is fully uh private from start to end and then later on you can actually decrypt it and get the new output coming up. So it is quite powerful and enable you secure computation and the good thing is that it's math-based. Um there is no trust assumption in in any hardware components. So FHE as I said been out there for quite some time. Uh it allows you to compute over encrypted data.

Some of the key limitations that are typically associated with fullorphic encryption is the scalability of FHE. It is definitely slower than the likes of trusted execution environment. Even though there's been a lot of progression both in hardware just running it on like CPUs and FPGAAS and AS6 that make it significantly faster than before as well as just newer FHE schemes like the one that we released like uh two weeks ago that just make it significantly faster. So in that regards there is going to be a significant trajectory of even uh a faster photomorphic encryption operations uh into the future. Okay.

So let's say you're a builder and you want to build uh your confidential smart contract. What are some of the considerations that I would advise you to follow? And I think the first one is really to do data classification. Meaning look at like what you're trying to build and try to understand within this data which type of data is okay to be public what type of data can be confidential or select se selectively disclosure like some of the data needs to be disclosed to some entities or others. The second part is build a risk model.

So define who can attack your solution. What is your tolerance for leakage? If the leakage happens an hour after is that still a problem? Is the data still uh valuable or need to be secured long term? And then of course the third thing is figure out your performance needs.

Are you looking for a significantly high throughput or are you okay with like uh 10 transactions per second? What is the latency that you need for each operation? Um and all of it will actually eventually define the type of solution that you want to use. Security level. We didn't talk a lot about the key that requires to decrypting the data.

Verifying who holds the decryption key is like significantly important because your solution is only as secure as the ability to decrypt it. Making sure that the decryption key is not managed by a single entity and cannot be stolen is extremely important. I want to take like a minute to also talk about compliance. Many people have this assumption that privacy contradicts compliance. Like they think about it in like the old days, I'm adding privacy and now I'm not going to be compliant.

This is actually a question that we hear both from institutionals that are working from us but also from developers that think about building. So compliance and in my opinion there's not like a set of regulation that we can follow. But the key thing to remember is if you're working on confidentiality of transactions, you can still do KYC and AML because we're not hiding the identity of the sender of the receiver. This is not like an anonymous solution. This is more about hiding the content of the transaction.

So you can still verify, you can still do KYC and AML, which is extremely important in the compliancy space. If you also need to add another tier which is KYT knowing your transaction. So have the ability to know the content of the transaction. Also here the technology has been progressed so much that we now have a way to offer permits and define the set of criteria that would allow a third party whether that's the regulator or the likes of G analysis etc predicate to actually see the content of the transaction under certain conditions. So the technology now is no longer a barrier for compliance and you can actually eat your cake and have it all like you can achieve both privacy and compliance infrastructure.

Where do you want your solution to reside? Do you need to build it on a specific L1 or an L2 because that's where your target audience is or do you prefer to go where the builders are at or where the liquidity is? And now you actually want to achieve a solution that offers you privacy as a service with a co-processor architecture. So figuring out like your base layer uh is extremely important because that will also define the type of solution that you want to work with. Do you want to go to like the Aztec or the Alo of the worlds or do you actually want to operate like on arbitum base Ethereum and in that case a co-processor solution may be a better fit.

And then last and this is literally like my last thing quantum safe. I know we're it seems like very far into the future where quantum computers still come. I see a significant growth in interest around figuring out which type of cryptography will allow you to be quantum safe in the long run. If your data needs to be secured for two, three, four, five years into the future, you definitely want to start thinking about that now. out of the different cryptographies that I mentioned uh FHE is based on latisbased cryptography.

So it's quantum safe. There is work happening both on ZK and MPC that will allow variants of them that will be quantum resistance in the future. So is that like the key decision factor today? Probably not. But definitely keep it as part of your decision tree.

Uh uh if you're especially if you're targeting institutionals. So just want to make sure don't be the naked guy, be this guy. Make sure that you're using confidentiality and that you achieve your privacy as a competitive edge. Thank you all.