There's No Freedom Without Encryption

Hello everyone. Uh nice to see you all. Excited to speak today about a couple of projects that are working in the encryption and privacy space. Uh my name is Lisa Qua. I work at Aztec Network.

Um we are building an encrypted Ethereum and uh we launched a product called Aztec Connect as a stepping stone to our full our future fully decentralized network which will allow um private state and private uh uh private contracts. So today I'm really excited to be joined by a a couple of the leaders in the privacy and encryption space to talk about how this space is evolving, what trends they're excited about, what their projects are working on, trade-offs in the privacy space, and how they see the space evolving. Um, so we'll kick off with introductions and just hear a little bit about what are your projects first, your name. What what's your project? What are you working on?

And what is the specific thing that you guys are bringing to the table that's not currently available in the market? Uh, everybody, I'm Paul Brody. the global blockchain leader at EY. Uh we're the big accounting and professional services firm. We've built a couple things on uh we built a couple things privacy oriented.

Uh two of them specifically Nightfall. It's a ZK optimistic rollup. It's being deployed on Polygon and the mainet. Uh it's fully decentralized, completely public and open- source public domain. You can do transfers and payments in the system.

You do need an enterprise SSL certificate to access it though to avoid uh let's say misuse. Um we're being a nice well- reggulated accounting firm. And we also have a a tool called Starlight. And what Starlight does it allows you to mark up a uh Solidity contract with uh the areas that you want private and it will recompile it as a zero knowledge circuit. Uh and both of those are available at github.

com/yblockchain. Awesome. Um, I'm Elena. I'm the co and founder of Ironfish. Ironfish is a layer 1 that only has private transactions and we view Ironfish as the privacy platform for crypto assets.

Um, so we have custom private assets that would allow bridge operators to bridge assets from other chains onto Ironfish for privacy. So our goal is to make privacy accessible, easy to use, and safe. Um, and we are pretty close to mainet. So please check us out. mainet is on Pi Day, I think.

So, check back in on March 14th. Um, I'm Henry. I am the CEO co-founder of Privy and we build onboarding tools for web 3. Uh, the core premise of our our product is that users are not wallets. And so, building rich experiences for users online means taking in more than just onchain data.

Um, we build wallet connectors, embedded wallets, and tooling that allows you as an app developer to onboard your users across the accounts that they have. And the sort of main contribution to privacy that we're working on is really the interfaces that power user control. It's one thing to have sort of an underlying stack that powers private transactions or private assets, but the question is how does that then flow back to the user so they can actually decide who gets access to what and we do a lot of work on the UX of uh I would say consent basically on the web. Hey everyone, my name is Anthony Drenzio. I work on growth at Alo.

Alo is a layer 1 blockchain that is enabling web developers to build private and programmable applications. Um, think programmability of Ethereum mixed with the privacy of something like Zcash. We have a ZK DSL called LEO which abstracts away the complexities of building with zero knowledge, specifically the Snark's construction. We also have our own virtual machine, a ZK VM. Many of you have probably heard of ZK EVMs, just dropped the E.

Uh we've built our own VM from the ground up. We also have our own operating system. And I think what we're enabling is developers to build more complex applications that are leveraging zero knowledge that you may not be able to build in certain other ecosystems. And this was the mindset that we had when we decided again to build everything from scratch. Cool.

So you just mentioned Zcash. I'd consider our projects all to be kind of second generation privacy projects and privacy protocols. Um, what have we learned from our predecessors that are we're incorporating into the way that you guys are building your projects? Do you want to start off since you mentioned Zcash? Yeah, sure.

So, first I just like to say Zcash is an amazing project. We've taken a ton of inspiration from them. Um, and I think one of the the great things about the the Zcash project is they they really introduced, I think, ZK to to the mainstream. They've done so much um, you know, so much of the groundwork for for what Alio has has built today. And I think the the general idea is that uh, for us, you know, Zcash allowed for this idea of like private money, um, which is, you know, and has amazing use cases and is is a really cool concept.

But what we wanted to do is essentially extend a lot of those properties from Zcash uh in such a way that you could create more um programmable applications like maybe you would see on Ethereum. So for example, how can we build something like a private like identity or authentication uh use case using ZK? How could we build, you know, games that have some kind of like private uh state? Um, and so essentially, yeah, we it's essentially just trying to make it uh an extension of what Zcash had already laid the groundwork for. If I could follow up.

Um, so on the same vein, Ironfish would not be here without Zcash for many reasons. One obviously is the tech. I think they paved the way in a lot of ways for ZK Tech to to happen and still continue to do so to this day. And then the other point is regulation. I think Zcash paved the way for regulation to happen so that regulators are even aware that there are different types of privacy solutions.

Not everything is Monero um and that there are different solutions for how you can do safe privacy. Um but in a in a similar way Ironfish kind of took um took like Zcash as a foundation like slightly different direction than Alo did which is how do we make Ironfish more a privacy platform um and have like different assets uh on Ironfish. But yeah, I think we we're all kind of standing on shoulders of giants here. Totally. And Paul, I'd be curious to get your perspective um in terms of why you think privacy tech has taken a long time to get adoption since you've been probably in this space longer than Oh yes.

Um why privacy has taken so long to get adoption. It's hard. It's just really really hard. You know, all private blockchains are really a response to the lack of privacy because enterprises won't do anything if it's not private. But privacy is really hard.

And the most successful conj job I ever pulled was convincing my bosses at EY that $2 million a year invested in a bunch of mathematicians was a good investment. Um, and we're only 5 years longer than I thought it was going to take for us to get there. But it is, it's just really difficult. And you know, uh, when people look at it, you know, if you do, if you're transacting ERC20s through an exchange, a mixer is fine, right? Or an exchange is fine.

You have a lot of privacy. But if you're doing an enterprise transaction with complex logic and nonfgeible assets, and I've got enterprise clients that want to mint half a million NFTts a day, each one for a serialized item. Like, there's no privacy in that. You can follow those NFTs around all of Ethereum. So without a true privacy infrastructure built on real zero knowledge, it's not you the blockchain is just not useful for enterprises.

So it sounds like the tech just wasn't there. And yeah, Henry, go on. I was just going to jump in and say I think from the from the user perspective as well, maybe this is a hot take. I'm not sure, but like privacy to me is less of a binary than it is a spectrum. And so enabling sort of selective disclosure by users.

Um as a developer it's very hard to know where to draw the line. And so it's much easier to engage in it as a binary which is either we pick to go all in on privacy or not at all. Most people are picking not at all. Um and so I think as developers and as I guess infrastructure builders um building for better defaults which takes some regulatory visibility uh is one of the big unlocks that we're still missing. Meaning if I pick up and I just want to build an app and I would like it to be private, how can I pick easily what my definition of privacy for my app and the threat models that I operate under would be?

And I think that's been a piece of the conversation that's been missing a little bit. So that's an interesting point because I think we are all making tradeoffs every day when we're building the technology and building our commercialization strategy in terms of what users we're going after, what use cases we want to support. So I'd be curious to hear how you guys think about that. like what is the thing that your team is optimizing for and willing to not willing to sacrifice on enterprise use cases. We're we're totally focused on enterprise cases.

Um so firstly, thank you because I think a lot of people ask us why why privacy why does privacy matter and actually bring up a why quite a bit of like there's a like if you are in the non-crypto financial institution land privacy is not just a like a a want. It's a need. Um and so that's you know one example. Um For us, for Iron Fish, you know, we're thinking about responsible privacy. Again, how do you how do you protect the consumer?

How do you make sure that crypto users are not part of fishing attacks and scams, but also how do you catch bad actors? And so, one way we do that is through view keys. So, we kind of took the stance that the protocol layer is kind of pure in the sense that, you know, it is private. Um, but on the on the wallet level, you can disclose anything. So, going back to the optional uh disclosure because that's kind of how businesses operate in the non-crypto world today.

And we're mimicking that for crypto assets as well. Yeah. I think for us, what we want to enable is developers to make any kind of application they can think of come to reality. And so our entire system is designed with this in mind. For example, you can have um onchain public state and you can also have off-chain private state.

And I think that's really important because it gives developers the optionality to decide what do I want to have as being public and what do I want to have as being private. Um and I think that's a really important uh yeah thing that we want to have in our system. I guess in terms of tradeoffs like with Alo people always say like you know why are you developing your own programming language? Why do you have your own virtual machine? I think for us there comes more complexity with that in terms of its design but again it enables you to do more complex things that maybe you otherwise wouldn't be able to do in other contexts but sometimes that can be daunting for people and for example like Alo has like a UTXO account hybrid model and so people coming from the Ethereum ecosystem for example that maybe want to start using Alo that can be a tough mental model to sort of understand at first but I think once you're able to conceptualize where it makes sense and the kinds of use cases that are enabled by building on Alio.

Um you know that drives interest but I guess you can find some complexities there. That is a really good transition to the next question around like yeah privacy is needed for some of these use cases but there is a large barrier to entry in some ways like we're asking developers to change their mental models to learn a new language in the case of us they were asking them to learn noir you guys are asking them to learn um UTXO model versus what they're used to with Ethereum how do you convince developers it's worth it so so this is exactly why we built Starite we struggled so hard to teach are developers and I my first thought was they're developers they're engineers they're really smart this should be no problem and they're like wow this is really difficult it's not really what I signed up for so that's why we said okay maybe the the right answer is we need to make a transpiler so you mark up a solidity contract and you can compile it into a zero knowledge circuit cuz we learned the hard way it is that that developer barrier to entry is really tough to surmount so for um for us we kind of took the stance that let's solve one thing at a time. So transfers is important. How do we make just storing, swapping, transacting private assets and custom assets easy and then kind of build up from there? Uh because right now like there's not even a go-to privacy solution for general and so like let's kind of take baby steps in terms of solving that first and then moving on to more complex.

Yeah, I I think in our case it's really meant looking at things from a sort of jobs to be done perspective. I think we're lucky to be uh a SAS company. Uh and we had a choice to make very early on like you know how do we actually build this out? What is the product? And I think being SAS means we're literally asking for people for money in exchange for using our product and so they want you know to know exactly what they're going to use it for from day one.

Um it's an annoying forcing function because you have to build very specific stuff, but it's a very useful forcing function because you have to build very specific stuff. And so um for us it's been sort of how do we shape the underlying architecture of the systems that we built so users remain in control of how they're sharing data across apps. Um but thereafter the types of use cases we're really building for are ones that developers are coming in wanting to do in the first place. Yeah. So yeah, I think for us the the main thing has just been creating a like to convince people has been creating a really great user experience both from in terms of applications that we want to build in house that people use but then for developers like the way our programming language is designed.

Our the the Leo team at Alio has put so much effort into making like the syntax and everything just about the language like super clean and nice. So even if you're even even though you have to learn like a new language, it's it's really easy to onboard into and just an amazing experience. I like to use myself as a case study. I'm not an engineer, but I learned how to program in Leo. So basically what I say to people is like if I can do this and you're a a web developer that already knows like TypeScript or JavaScript, like you should have no problem uh being able to to come into our ecosystem.

So I guess that's how we try to sell people. And then just showing like the end applications themselves like oh here's something tangible that you can actually uh start using and I think the proof is in the pudding in terms of uh yeah what what you can do with it. Yeah I think the best we can do is make it as easy as possible for developers to enter the space and continuously educate them. So for Ironfish for instance we want to make the full node experience really easy to use and so anyone can install Ironfish today with just one command line tool npm install- Ironfish and you're good to go. Yeah.

How many participants did you have in your in your recent ceremony? Um, it's still ongoing, so it's going to end March 3rd. Um, and we have over 8,000 contributors right now. And people actually had to install the full node SDK in order to participate. So, we wanted to kind of test out how easy it was for that process to go.

And, you know, it's, you know, I think we had like over 45,000 npm installs that week that we launched. Um, so we kind of proven our point that if you make it really easy for people to download the thing and to run the thing, then people will do The docs are super beautiful. Thank you. Our designer is awesome. So, shout out to Skyler.

Yeah. And that's another theme, right? It's um how do you make what we're building accessible to folks? Um and thinking about the end user or the developer in our ca in some cases and having empathy. Um I think that's like sometimes really challenging when you have this like really long development cycle in some cases.

And so I'm curious how your teams manage with that and building that developer empathy and making sure that like that user is taken into consideration in how you're developing the product. All of our engineers are in our Discord channel every single day. So actually Rohan's on the front row right now. He's an engineer infish. So he can tell you firsthand we're we're all in there and so we can actually see what users are saying.

Uh and the majority of the time they're giving us really good feedback of like, hey, this is not working. And so engineers have like a really direct communication to the end user and so they're you kind of have to build empathy because you're literally seeing them struggle and then you make the product better. That's awesome. I think for us it's it's come down to to three things. One is dog fooding.

So you know building with our own systems which is fairly I think common advice. The second is having a development partner that we actually work with. So either a developer or company for every feature that we put out who's very very clearly driving this is what I want your solution works or doesn't work for it. And then the third is is quite a bit creepier and I was very against it up front. uh but it's we record every call that we have with folks that we work with third parties and that's turned out to be absolutely invaluable because I think there's sort of a wishful translation layer that happens when you're like oh yeah I spoke to you know whoever and this is what they want and you can kind of like graft your own ideas onto it very easily even if you're well meaning and so I think actually having the core recordings the source of truth being a snippet that you can cut from the recording to show everyone else on the team this is what they want this is what they said they're like no that's not what they said this is what they said um has been super helpful in actually building empathy.

Yeah. So, I agree with what everybody said here. I guess maybe one tangible thing is like through our grants program that we've run, uh part of the the process is one trying to help the developers that are putting together these these ideas that they want to build out figure out, okay, what is it that you can do today? What cuz like we're we're still in our test net. we still have a lot of things that we need to to build out in order for us to be, you know, 110% to where where we want to be at mainet launch.

Um, so a lot of it is is helping them to scope out like, okay, here's tangibly like what you can do right now. This is how it's actually going to actively contribute to the ecosystem, right? And how you can get more people interested in what you're building, sort of creating this hype and interest around these project ideas. And then the other thing is internally we usually have like regular calls or cadence with uh people building in our ecosystem and we open up those calls to to anybody on our team that wants to join and we really highly encourage people to come to those calls like sit in maybe even like ask some questions. Um, so you might have somebody from like our Leo engineering team or you might have somebody from like the growth team or you might have somebody from like the marketing team and they all have like these different perspectives that can help um a lot of these teams that are trying to build out their own uh projects like better understand uh where the gaps are and how we can support them and vice versa.

Yeah, I think you mentioned uh you mentioned the grants program as a tool to like start building your community. Um, I'm curious how you guys have thought about building your community and what role the community plays in your projects today and then how you envision that expanding over time. Well, we we've got, you know, a couple things in mind, right? Number one, we want to reach out to the general Ethereum developer community. So, that's that's a very big part of the community for us.

We want to see other people. We've made our tools public domain and open source. So, we want to be able to see other people build applications and and infrastructure on top of that. And then we have a we have our own very specific community inside of EY. We have, you know, 225,000 people who are doing audits, building stuff, and we need them to know about it.

And it's it's still amazing to this day like how many people inside of such a large firm don't know what we're doing. And you get these emails like, hey, are we doing like anything with this like blockchain thing? And I'm like, yes, yes, we are. And but you need you need they are the people who are out there selling for you. And so you have all these different constituencies.

You've got developers who are quite sophisticated and then you've got people who their idea of developing is really just like touching a couple APIs and you got to make it ultra simple and accessible for them. Yeah. So for us, our community is a lot different because we are new layer 1 chain and so we kind of had to build that from the ground up. So a lot of our people are people who are like full node operators or miners or people who really care about decentralized networks and optimizations. Um so we kind of you know we actually ran probably one of the longest test nets uh of over a year and so we just completed our third phase.

Um and so you know the way we grow our community was pretty unique. Um like for our last test net we had 60,000 concurrent nodes online which was like pretty incredible. Uh and so you know it's it's it also drives this kind of um comra camaraderie within the team but also within the community because you know even in our test net we're facing scaling problems that you know some maintenance don't even face uh and so kind of how you think about building layer ones and especially ones that deal with your launch proofs and verification times and optimizations there um is just like that level of complexity um I don't know I think made made the first community probably one of the more healthiest and and like welcoming communities that I've seen in crypto which I'm pretty proud of. Sorry, I I'll rep again just also like very good engagement um on the the websites and every every way like you had leaderboards for the test nets and and ways like that to actually build engagement super productively. Um I think for us maybe bringing identity into the privacy conversation for just a second.

A lot of identity is super nebulous because you don't it's hard to define where it begins and ends. And so for us building authentication tooling and uh wallet infrastructure uh having a clear sense of where our stack begins and ends so we can play really well with partners. So partner ecosystems that we think would benefit from uh integrating with us or vice versa. uh but sort of having a clear stop at this is where the interfaces will connect with these partners so that we can build community with these other projects as opposed to you know having an unclear line of this is your job, this is our job and so on. Yeah, I'll keep mine quick, but basically TLDDR, the community, Alio's community is Alio.

Like we're an open source project. Everybody who's contributing to Alo is is part of our the the team from our perspective. And um I think one of the main things we try to do is align all the different players in Alo's ecosystem. So we basically have application developers, right? They write deploy applications.

You have provers on our network, right? These are people that are actually running those applications and doing that by generating zero knowledge proofs. Then you have validators that are um contributing to consensus on the network. So it's really important that we align the incentives of all three of those players so that uh we can build like a strong community. Cool.

Another thing that I think is kind of a misconception about the privacy and encryption space is that it's um a space that's attracting bad actors when in fact I think a lot of the developers and the folks the end users that we talk to are like asking us for tooling to be compliant and to make sure that they're adhering to like regulation as it's involve as as as it's evolving. And so I'm curious how you guys are thinking about embedding that into the protocol um or into the tooling that you offer to folks that are building with the protocol to make sure that it's you know something that can be global and something can that can evolve as the space is evolving. So uh we we made a decision to be we wanted to have enterprise identity. So you have to have an enterprise SSL certificate to access the Nightfall ZK rollup. However, and this was really really important to us, enterprise SSL certificates are themselves a public and open standard and you can get them from any SSL certificate provider.

And that is that's super important to us to have it to have privacy with identity and remain completely and fundamentally permissionless. Yeah. So for us, we do that through view keys again. So the holder of key can see the full transaction history. And we did actually amend the sapling protocol to even give you more visibility in terms of where the funds are actually coming from.

Um but uh but yeah, I mean like we want to we want to have Ironfish be used by good actors. Like none of us are working so hard so that Ironfish can be used by by you know the human traffickers and or like the hackers of the world. And so we are putting a lot of effort into that. And I think like everyone who's working on privacy genuinely wants to protect the consumer and protect crypto users. We're not building this for bad actors.

I I think for us it's meant uh targeting a couple of standards. So GDPR, CP and actually picking where the lines today that we know we need to enable like immediately and then from there building a system that's uh flexible enough that basically as regulation evolves we can continue to grow our system to to play nice. Yeah. So just quickly we we think the same way. So we're a private by default platform.

That just basically means when you're writing in a program in Alio, everything by default is fully private, then you're selectively deciding, okay, what's going to be public, state, and what's going to be private? And again, that allows us to evolve with regulation. So, if we want to build an application for a government, we can be as compliant as we want to be, right? It's just is the compliance going to be so tight that like what we're building doesn't make any sense or is it going to be reasonable compliance, right? And that's maybe a trickier topic to navigate, but yeah, I think it's on us as people in the ZK community to educate regulators on how this technology works and why it could be beneficial and the different use cases.

And I think that people are open to that. Like I think that they want to be educated on it. Um, and so it's like our responsibility as builders in the space to kind of collaborate and make sure that we're like going with, you know, a unified position in that. Um, cool. And a couple more questions um as we're wrapping up.

So, what area of privacy do you wish you had more time to learn about? Uh this is a specific I mentioned this on a panel I said yesterday, but an application of ZK is like ZK machine learning. I'm not a machine learning expert, but I've started diving into it and it's really fascinating. So, I wish that was a a topic that I could be uh more of an expert on, but definitely trying to work my way through it. I I'm going to follow up on this I guess with differential privacy and uh bias in the space around uh machine learning models AVMs.

Yeah. Whatever the next panel is on. Yeah. Awesome. Thank you everyone.

Thank you.