How Confidential UX Unlocks Markets You Can’t Touch Today - Kate stapleton

Transcript

All right. Uh, so yeah, I'm Kate. I'm a head of community and ecosystem at Phenix. Uh, so I guess just to get started, who raise of hands, who here knows what FHE is? Okay. Okay, very cool. Um, and I guess yeah, the second question that I always like to start with is who here cares about privacy? Okay. So then my follow-up question to that is anyone who didn't raise their hand, would you be willing to come up on stage, cast your, you know, phone to the screen and go through your recent transactions, your Visa bills, all of your DMs?

Probably not. So I mean, that's kind of, you know, how I think about privacy is that we we traditionally we think of privacy as almost a negative thing is like you have something to hide, right? Like there's something that you want to keep from the world, you're, you know, acting nefariously in the shadows. But, you know, I think privacy is a lot more normalized today than we really think it is. Um, and you know, kind of applying this to to blockchain, um, I've mentioned this in in a bunch of talks before, but with blockchain, we've kind of taken the inverse approach as we have to, you know, building the rails of the internet, right? We we started slow with the internet, we added these different networking layers, um, you know, transport layer secure, trans- uh, TLS, secure socket layer, all of these compounded, you know, to create privacy

on the internet, which is what allowed for e-commerce, you know, to take off in a big way. Blockchain is the inverse, right? We kind of shipped day one and then retroactively we're like, "Ooh, we should think about interoperability. How do these blockchains communicate with each other? Ooh, we should really start tackling, you know, anonymity, privacy, confidentiality now that, you know, the big players like the institutions and the banks are coming on board in a meaningful way." So, you know, we are kind of doing the inverse of of what we really should have done. And so I guess that's the that's a kind of the point that I want to get across today is that privacy, you know, most decentralized apps are architected for pri- for transparency by default, right?

That was kind of the core tenant of Bitcoin that is, you know, followed us along our journey to, you know, to the Ethereum landscape of today. But that architectural decision defines your user base, right? And Ethereum is it's really is a glass house, right? All Ethereum state is public. Your balances, your votes, your bid, your preferences, all of your behavior. Um and this also opens up, you know, the door to leaking sensitive data, right? Exposing your trading strategies. Um it invites, you know, MEV exploitation. Um so in existing methods, right? Like zero-knowledge, multi-party compute, they don't necessarily support persistent encrypted state with flexible logic.

And this creates, you know, the $500 million problem. So, um in 2023 alone, MEV losses in DeFi, you know, were above 500 million. 14 Sorry, 15 to 40%, you know, auction value extracted. And 75% of this and I think this is the the key the key um factor here is that 75% were from losses from trades under $20,000, right? So these were like your your not your whales, not your power users. These were your everyday retail users, the hobbyists.

And so I think we're we're very much at a critical kind of inflection point in in DeFi and in crypto is that we've been talking about, you know, mass adoption forever. Um We've been talking about it from over, you know, the more than 10 years that I've been coming to these conferences, giving talks, listening to talks. And I think, you know, now like I said we are at this very critical inflection point because now we have institutional and enterprise um kind of adoption in a in a really meaningful way, right? And so I know email was mentioned before, but back in the day, um you know, if you were sending an email, it was by default plain text, right?

There was no encryption added to it. And so, what you had to do is you had to manually sign each one of your emails with PGP, which stands literally for pretty good privacy, and that's exactly what it is, pretty good privacy. So, the body would be encrypted, but, you know, the um kind of the subject line, the sender, the receiver, all of that, you know, metadata was you were not able to encrypt that. And so, that was kind of how we just operated, right? We had to manually encrypt your emails if you really cared, if you were kind of a privacy maxi back then. And the shift for, you know, towards encrypting things end-to-end, the, you know, uh reliability of that in terms of the logging and and all that can be debated, but the shift from plain text by default to end-to-end encrypted by

default was really driven by enterprise adoption of email in the workforce, right? That's really what moved the needle. The Cypherpunks obviously got us to where we are today. Um it was a very kind of vocal minority, but real change in terms of, like I said, end-to-end encryption being the norm for emails, for communications, that was really driven by, you know, institutional demand, which now we're now seeing, um you know, in a meaningful way, like I said, in the Web3 space. There's also a lot of regulatory pressure, right? With um DAC here in Europe, with the Genius Act in, you know, in uh in the US. So, privacy as a compliance enabler, thinking of this as a way to enhance regulatory, you know, um basically the ease of of being regulatory regulatorily compliant.

Um stablecoin adoption, right? Everyone here, there's a lot of hype around stablecoins. There's a lot of uh governments adopting stablecoins and launching stablecoins as well as RWAs, like I I think Korea has just launched um they're tokenizing gold, the the Korean government, as well as launchpad evolutions, right? We're moving to a sealed bid auctions. I don't know if anyone followed along with the Zama auction, but that's kind of the new way of like thinking about and and approaching uh you know, TGEs and and ICOs. So, the window is open, and this is kind of, you know, the the point that I brought up before, right? From 2020 to 2023, the cryptographic readiness of of these solutions, you know, like F H E, zero knowledge, um they were really not there yet, right?

Like they were they were very kind of theoretical. Whereas now, right, the private shared state unlocks the production ready, right? Phoenix we're in we're in mainnet, sorry, we're in testnet, we're going to mainnet this year. Zama, Aztec, you're seeing these, you know, these privacy compliant these privacy preserving technologies actually going to mainnet and we're seeing that they are production ready. The issue though is that, you know, if you don't adopt privacy by default from the beginning, protocols ossify, right? Retrofitting is brutal. It is very, very difficult to kind of retroactively add privacy, um you know, to to your design, right? So, for institutions, it's an absolute requirement. No institutions are going to meaningfully come on chain

unless there is a way to protect their trades, to protect their strategies, and, you know, to to add privacy, you know, and anonymity and and confidentiality to, you know, their anti chain activity. Um it's a demand for traders. Like I said, the the the the people getting hit by these MEV attacks are the smaller traders. It's these trades under 20,000, you know, it's not the big whales, it's the everyday kind of crypto user. Um and then for compliance, you know, we're having for the first time meaningful discussions about compliance, what that looks like. Um you know, so privacy is going to have to play a huge role in that.

Um and so yeah, I mean, we're seeing we're seeing you know, new markets that are that are unlocked by, you know, the the potential of really meaningfully adding privacy to to web 3, right? Capital protection, right? Payroll. Nobody wants everyone to be able to see, you know, what they're getting paid. Um contractor payouts, treasury moves, you know, all of these expose your strategy. You don't want this to be public. You don't want this to be on chain. R W you know, R W A's in compliance, right? Real estate ownership, valuation, you know, being able to encrypt that, transfer restrictions enforced at the decrypt layer via permits. These are all things that we're being able, you know, to really actually build out for the first time now that can scale.

As well as strategic coordination, right? Multi-party deals stay hidden until settlement, right? Mergers and acquisitions, these, you know, only go public once it's ready to go public. Partnerships, really large trades like institutional trades, they can execute without copying, you know, people copying trading or front running their trades, which is really one of the big blockers like I said to actual meaningful institutional adoption, um you know, of of crypto. So, confidential by design is kind of what we what we really preach, right? Privacy is a primitive, not as a feature. So, when you start when you start to think about privacy as a primitive and not as a feature, you understand the importance of implementing it by design from day one, right? It's very, very difficult um to retrofit, right? It it break you know,

breaking changes to core logic. We had a hackathon, for example, with Uniswap and we were developing some um you know, FHE-powered hooks. We were in talks with Uniswap about, you know, ways we could partner and they're basically like it would break the core logic. There's really nothing that we we can do, right? Um you know, so building with privacy from day one, it gives you institutional grade architecture from day one that can scale, selective disclosure from, you know, from day one, clean composability, again, regulatory ready. Um but if you don't, right? This technical debt compounds, right? Playing catch-up is very, very, very difficult. Um and there's also user migration friction, right? By by definition and and you know, if you're kind of retroactively

trying to fit privacy into what you're building, there is going to be this user friction because you do have to kind of break the core logic and add new flows for users, especially if they're very familiar with the product. Um this could be the difference between, you know, retaining users and them just hopping ship, you know, to somewhere else. So, privacy-enhancing technologies, I know there's a lot of like acronyms in crypto. So, I mean, I'm sure everyone's heard of TEEs, trusted execution environment. You know, this is an isolated hardware, right? Yeah, running code and and managing data privately. The limitations there is that they requires trust in the hardware vendor, right? We've seen some hacks around TEEs recently.

MPC, right? Multi-party compute. Distributes computation across multiple parties without revealing individual inputs. But, yeah, there's obviously, you know, some tradeoffs there like high coordination, communication overhead. Zero-knowledge proofs, I think people are most familiar with with ZK. You know, one party can prove a statement is true without revealing the underlying data. Again, the the composability of this uh is not great. It's difficult, you know, to model the complex logic that's associated with it. FHE, which is what Phoenix runs on. Fully homomorphic encryption allows computation on encrypted data without needing to decrypt it.

Um so, fully homomorphic encryption for those that are not familiar with it. Homo is same and morph is change. Seems a little bit counterintuitive. But, basically, it's encryption that changes the plain text into cipher text that is structurally the same. So, it allows you to compute on encrypted data that nowhere along the data's life cycle has to be decrypted. So, before, you would have to, you know, kind of decrypt this this, you know, cipher text into plain text, compute on that, re-encrypt it, and then, you know, uh broadcast whatever, you know, logic or you know, re-broadcast to the, you know, the chain or or return whatever, you know, functions that you're running on it.

Whereas with, you know, FHE, it allows computation to be done on encrypted data while remaining fully encrypted. So, this means your data is hidden during the transit and processing the entirety of this data's life cycle. It does not ever have to be decrypted for you to compute on it. And so, you know, for people that are familiar with FHE, it's been around for a very long time. It was kind of, you know, deemed as like the the gold standard of encryption, but there was a lot of issues, right? Like really in the last year we've actually seen FHE become production ready. FHE was very complex, right? Now with with Phoenix's co-FHE, so our co-processor, our SDK uses the same patterns as Wagmi, right? So U int becomes E int. It becomes just a encrypted version of the

function that you would usually call when you're writing a Solidity smart contract. FHE is too slow. Yes, it was very slow in the past. Zama's libraries have tackled this. We have a library that is in production right now called DBFE that has the potential for 10,000 TPS. FHE isn't production ready. This is kind of the biggest one that we had to contend with. Um, we are on testnet, but we're on Sepolia, Arbitrum, and Base. And like I said, Aztec and Zama, they've kind of paved the the way for this.

Our users don't care. Like I said, this, you know, in general I think people are a little bit apathetic, especially in this space, about privacy. But like I said, 75% of MEV MEV losses hit these trades under 20K, right? So retail is really the victim, you know, of of this yeah, of of non-encrypted or unencrypted data. And this is also the big thing that we see is like, "Oh, we'll add it later." You know, institutions are evaluating now. From an institutional perspective, first mover advantage is is now, obviously, but like I said, it is very very difficult to retrofit privacy into whatever you're building.

So, co-FHE, so co-FHE, this is a fully homomorphic encryption co-processor for EVM chains. This is actually new, so I think we launched about last month. So it lets smart contracts compute, like I said, on encrypted data, meaning values stay encrypted not just in storage, but throughout every single step of processing. So, uh Coffee, Coffee, um sits off-chain, but it proves its work on-chain, right? So, developers write contracts in Solidity, so language that they're very familiar with. It's, you know, sorry, Aztec, but you don't have to learn new language, you don't have to learn, you know, a new language. You can write in Solidity that you're very, you know, comfortable with and and familiar

with. Um so, the users encrypt they they encrypt their inputs before they hit the chain, right? So, the co-process the co-processors are are Coffee PG. Uh that does the heavy lifting on the encrypted data, and it in turn returns encrypted results. So, when decryption is needed, a threshold network of independent MPC nodes handle it. No single party ever sees plain text. I think that's really, you know, the the impressive thing about, you know, Coffee or Coffee. Um So, yeah, we've got the smart contract, so right, so this is the Solidity library, the client side, so our Coffee SDK. This is a JavaScript library. Um and again, we're writing these libraries out, right? So, like the next move is to be live on Solana. We can write out a

Rust library. Um testing happens in uh with these mock contracts, and then decryption, right? With a custom threshold network. So, that's kind of the very high-level flow. Um yeah, this is kind of getting a little bit more into the weeds here, but encrypting the data, so contracts receive um EUint types, so encrypted EUint types uh as inputs. Um then to work with them, uses FHE as EUint 64, for example, to convert them into usable EUint 64 valuables, sorry, variables inside the contract. Um all encrypted math is done via the FHE library, FHE.add, FHE.sub, etc. And then access control must be explicitly set for each result with FHE.allowed this. Um and

this is set by Yeah, so access control list basically determines uh who can access the data and to what degree, what capacity. So, yeah, access control, this is a very key uh kind of part of of everything. So, access control lists um determines the and encryptographically enforces who can decrypt data. This is very key um you know, to kind of the the functioning of uh of of Phoenix. Is, you know, so you can grant um you know, who can reuse this value in future transactions, a specific wallet that can decrypt this value, current transaction sender can decrypt, or anyone can decrypt. So, it really lets you set the logic uh at the smart contract level.

Uh and then yeah, what can you I don't know how technical folks are here, but yeah, uh arithmetic, comparison, selections, and and randomness. So, these are all things that you can set that you have control over when you're writing out your smart contracts. Um yeah, I'll kind of move on to the next one. I'm not sure how technical folks are. But, yeah, so decryption has has two paths. Um so, view decrypt, show value in the UI. So, this is uh when users want to see their own encrypted data, like your token balance, if you're sending encrypted transfers.

Uh requires a permit, and this is entirely off-chain. It returns a typed scalar for display only. Not sure if this means anything to anyone. Uh but basically, yeah, there's no on-chain verifiable signature for this. And then there's transaction decrypt, which publishes a value on chain, right? So, this is used when a contract needs plain text for logic, like token unwrap, you know, auction finalization, tally, stuff like that. Um and this is when the threshold network returns a signature with plain text. So, the contract verifies the result on chain before use. Um so, yeah, this is kind of uh like I said, the the very high-level um kind of life cycle. So, encrypt, submit, compute, uh decrypt. So, step one, the client encrypts. Step two, contract

operates on encrypted data. Step three, the coprocessor computes. And then step four, there's, you know, you can choose between these two decrypt paths. Um, so this is actually our head of developer relations, Lauren. If anyone has very technical questions, she'll be able to uh to take them. But um, I guess just getting back Oh, sorry, I'll move that there. Getting back to, you know, to ACLs, so the the access control list. So, this is kind of what we consider, you know, the aha moment, right? On a standard EVM chain, all state is public, right? Anyone can read balances and in balances at address.

Coffee, um that changes the the default. Data is encrypted and ACL determines who can decrypt it, which is then enforced cryptographically. So, traditional blockchain privacy relies on access gates, uh who can call a function. Coffee's ACL controls who can see the underlying data even if they have even if they call the same function, right? So, it's a fundamentally different layer enforced at the cryptographic level, and there's no way to really like read around it, right? So, hacks become obviously not impossible, but very cryptographically uh different, right?

So, what ACL unlocks is confidential transfers, private voting, hidden game assignments, sealed auctions, um you know, and more. So, basically, your smart contract determines exactly who can decrypt what at the cryptographic layer, not just who can call um you know, the the functions. So, like I said, we are on testnet right now. Uh our roadmap is such that uh hopefully, if everything is on track, we go live in November of this year. Um and yeah, our plan is to go live with as many use cases on mainnet as we can.

Obviously, private, you know, token transfers are kind of the the default that we're seeing a lot of. Um we're also seeing some really cool projects like privacy-preserving DeFi aggregators, encrypted asset management, confidential DEXes, a lot of dark pools, privacy-preserving lending, confidential payment protocols, uh and then some perp dexes and some Uniswap V4 hooks. Um confidential portfolio rebalancing, really this the sky is the limit. Also stealth auctions, there's a lot of sealed bid auctions that we're seeing being built um on Phoenix. And like I said, you don't need to learn a new language, you don't really need to learn new logic. It really is if you understand Solidity, you can make calls through our co-processing library, encrypt the functions that you're already familiar

with calling, and you know, the EU and Eble becomes encrypted with Phoenix's uh FHE library. So, yeah, I didn't realize I had more time than this, but that is my talk. Like I said, if you take one thing away, it's that, you know, privacy should be by default. It should be something that you don't even think about. The end user shouldn't understand how it works. It should just work very well hidden under the hood, hopefully um secured with FHE, and that, you know, it should not be an afterthought. It's a primitive, kind of not a feature that you add retroactively because, trust me, it is very difficult to do.

Um so, yeah, that is my that's my talk. >> Thank you, Kate. >> Cool. All right. >> Thank you, Kate. Uh any questions? >> Perfect. >> No No questions? >> It was all super clear then. Oh. >> M- Maybe I've missed that, but what are the current limitations of the uh of the fully homomorphic uh encryption?

>> So, the the current limitations that I did I did kind of glaze over that. But yeah, I mean, it's complex. It is very complex to design around branching logic. That's something that's very difficult. Um asynchronous execution model is a little bit difficult for people to wrap their minds around. And we are working on improving this, but there is still a higher compute cost to other solutions like zero knowledge and uh and TE. So, those are kind of the three main ones. Um Yes. I did glaze over those, but yeah. Those are the uh the limitations that we're seeing right now.

And in latency, like they it is slower than other solutions, but um like I said, with DBFE, our novel cryptographic um FHE library, we are working um the engineers, not me, are working very hard to to address that. >> Uh Kate here here. >> Yes. >> Um what do you think about the tension between the cryptographic um theoretical cryptography and the necessity of people are saying right now, privacy is not enough, uh and it will be this always the tension between like can we have one day the ultimate holy grail of privacy, or there will be always this kind of like um applied cryptographers pushing things forward, and the product managers

pushing UX forward, but then it it will be never like a perfect solution. Like, what's your opinion on those two things? >> Yeah, I mean, I I don't think perfect solutions exist. I wish there was one, because we'd all just be adopting it, and none of us would be having any of these discussions. But I mean, Phoenix, like we're not in L2, we're not in L1, we are infrastructure, right? So, what all we can do is provide the best developer tooling to create the most seamless experience for coders to, you know, and developers to write these programs.

Uh continually building out our, you know, our our cryptographic libraries that are powering FHE. Like, the fact that people can vibe code with with Phoenix, I think is incredible. Um and I know there's a lot of contention between TE, MPC, ZK versus FHE. I think, you know, the pie is still too small to really kind of pick one hill and die on it. I think there's a place for, you know, in terms of use cases, there's place for everyone, right? There's utility for everyone. All we can do is make sure that the developer experience is as seamless as possible. The cryptography that underpins, you know, the the encryption is as kind of robust as possible, and then in turn that gives the end user the best experience possible, right? I don't

think we're there yet. I think there are still some trade-offs between UX and the underlying kind of cryptography and you know, technical solutions. I wish like I said, I wish there was one um perfect solution. In the future, I hope it'll be Phoenix. But yeah, there's no one perfect solution, but all we can do is kind of marry those three elements and produce, you know, the best solution possible, which I think, I'm biased, is Phoenix. >> Well, sorry, we're out of time. I'm sorry.

>> We can chat after. >> Thank you, Kate. >> Thanks, guys. Oh, we're done? >> No, that's it. That's thank you. >> Cool.