Anna (00:05):
Welcome to Zero Knowledge. I'm your host Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online.

Anna (00:27):
This week, James and I chat with Elena Nadolinski, founder of Iron Fish. We talk about what got her into blockchain and zk tech, the work she's been leading first on Beanstalk and now on Iron Fish and how a super light and easy to set up node infrastructure is a key component of a private blockchain system. Now, before we jump in, I want to share two ways that you can connect with the zk community and stay up-to-date on all the activity in the space. The first is the zkMesh newsletter. It's a monthly newsletter that showcases the latest research articles, videos, and resources on the topic of zk and privacy blockchain tech. The next one comes out in a few days, so be sure to sign up today. The second way to connect is to sign up for the ZK Podcast events and announcement newsletter. Sign up here to get the news on what's happening in our podcast community. I've added both of these links in the show notes. There's also more links further down in the show notes to telegram groups or YouTube channels or any other ways that you want to connect. I also want to thank this week's sponsor, Aave. Aave is an open source decentralized non-custodial liquidity protocol on Ethereum. With Aave, users can participate as depositors meaning they provide liquidity to earn a passive income, or they can act as borrowers to borrow in an overcollateralized way or an undercollateralized way. Think: one-block liquidity Flash Loans. Aave has also deployed a new market on Polygon's sidechain to let users pay much lower gas fees. Assets can be transferred from Ethereum with the Polygon bridge and put to use on Aave's Polygon markets. You can learn more about this on the Aave blog. I've added the link in the show notes. So thank you again, Aave. Now here is our interview with Elena from Iron Fish.

Anna (02:13):
So today James and I are chatting with Elena Nadolinski, who's the founder of Iron Fish. Welcome to the show, Elena.

Elena (02:20):
Thank you so much. Really glad to be here.

Anna (02:22):
And nice to see you again, James.

James (02:24):
It's good to be back.

Anna (02:26):
So Elena, this is the first time that you come on the show, but I think we met actually a few years ago in Buenos Aires. Is that possible?

Elena (02:35):
Yeah, that's right.

Anna (02:37):
The hackathon. And I feel like I've seen you over the years, I don't know... Was that the first crypto event you were at actually back then, or were you already in the space?

Elena (02:47):
That was actually the last one that I was at, before I quit my job.

Anna (02:51):
Yeah, I think I remember that. So let's hear a little bit about your background. What were you doing then? And what have you been doing since then?

Elena (03:01):
Yeah, so the way I got into crypto is actually through those hackathons, through these global hackathons. And I guess I could go even back further than that. So my boyfriend at the time, now husband, his roommate was Juan Benet, who is a founder of Filecoin and Protocol Labs. And one day he says, "You know, I have a friend, they're doing a dinner party. Do you want to come?" And so we drive over there and have this dinner and everyone there is talking about Ethereum. This was like mid 2017, I think, like early 2017. And I remember on the car ride back, I'm Googling in the car what is Ethereum? Because I still didn't quite get it after all those conversations. And there was a hackathon announced, the first ETH Global hackathon called "ETH Waterloo". And I remember this conversation where I was thinking "Should I go, should I not go? This sounds really interesting." And Dylan said, "This is gonna be the first hackathon, probably everyone's going to be there. If you're remotely interested, you should go." So I buy my plane ticket and I go to the ETH Waterloo hackathon. And I was just blown away by how open the community was and how many people were there. So the story that I like to use of how I got into crypto is I'm doing this hackathon, I'm doing video streaming IPFS using a "stablecoin". And my MetaMask integrations aren't working. It's 3:00 AM, I'm tearing my hair out, not sure what's happening, it's not working. And I asked someone for help, who's a mentor. And the mentor comes over and says, "I don't know what you're doing wrong, it seems that it should work. But Dan Finlay, who made MetaMask, is right behind you". So I do a 180 with my chair and I asked Dan Finlay for help. And at 3:30 AM Dan Finlay and I are debugging MetaMask on my computer and I was just blown away. I was like, "Whoa, I want to be part of this. This is so cool". So...

Anna (04:59):
That's cool. You were right in the thick of it right off the bat, it sounds like. What were you actually doing at the time though? Cause you were already a dev, right? It sounds like you had already, you'd finished school. You were working professionally, right?

Elena (05:12):
Yeah. I was a software engineer at Airbnb, working on search, auto-complete search to be exact. So definitely not crypto. But Airbnb, funnily enough, actually did have a pretty strong crypto presence. There was a Slack group that, I think at some point, before I left, got to like 400 people, people talking about crypto. But it was very peripheral, it was just casual conversations. So this hackathon was actually the first time that I got to write any Solidity code. It was the first time that I could think about how does this tech work, what are the limitations for it? So that was a really cool experience. And then the next hackathon I did, I was actually with the OpenSea co-founders, Alex and Devin, if you know them. And we built an NFT generator, so like drop-and-drag pictures, and then you make it a piece. This was like 2017-2018. And the next hackathon, which was ETH Denver, someone asked me to do a talk. And so I did a talk on live-coding NFTs on stage. So it was a 30 minute slot. So the whole premise was, if I can live-code onstage an entire NFT smart contract with some very basic UI, then so can you. As an inspiration for "Look, how easy this is", and also to demystify this myth that ERC-20s are hard, because at the time 2017, if you remember, it was all about ERC-20s on the blockchain technology. And so that talk was really successful. And so I got asked to do this talk again and again, and one of the people from ETH Denver that saw me give that talk were the Zeppelin guys, the OpenZeppelin guys, who were in Buenos Aires. So I got involved with them, because they were working on upgradable smart contracts, which I thought were super important in the space. So I dove into that area and wrote an article for them of how these things work and like "blink under the hood" and different kind of approaches to it. And they asked me to be at their conference in Buenos Aires, which was at the same time as ETH Buenos Aires. So I got to do two talks in Buenos Aires, when he saw me there.

Anna (07:17):
Amazing. But at that time, were you interested in zero knowledge proofs already by ETH Buenos Aires? I'm curious, when did the zero knowledge stuff crossed your path?

Elena (07:28):
Oh yeah, it was actually from that first hackathon. It's like the hackathon that keeps on giving.

Anna (07:35):
The Waterloo?

Elena (07:35):
Yeah, the Waterloo.

Anna (07:36):
I did not go to that and I am bummed, cause that has come up so often on the show. I mean that's where CryptoKitties was presented. I don't think it was built there, but it was presented there. There's tons of teams that were formed. But that's where you first came into contact with zero knowledge proofs.

Elena (07:52):
Not quite, but that's where I got the idea. So the project that I was working on, for which I did get a prize for, which was very nice, was video streaming IPFS. I'm sure, as a podcast, you probably know this process of how to take an MP3 file running before file and break it down into different format so it can be streamed somewhere else. So the way it did in my IPFS was, whether we have streaming works is you break up a large file into smaller files and as your player downloads, it actually downloads the next immediate file chunk to play it for you and then discards it. So I broke up the file into smaller chunks and put it on top of IPFS. And then from IPFS, you could actually stream it with the smaller chunks. But the actual process of taking the video and transcoding and transforming it into from one file to much smaller files that was done on AWS. Because for my demo, you can't do it on Ethereum. You can't transcode a video file on Ethereum, that doesn't make any sense. So that got me thinking of, "Well, if I were do this project in a fully decentralized way, where would this heavy computation go?" And for Ethereum it doesn't quite make sense, because it doesn't make sense for every computer in the world to transcode a video that you decided to upload somewhere, it doent's make any sense. So can you make a network of computers that would do this heavy computation of transcoding your video and then get some reward for it? So then I started thinking of, "Okay. Well, if a computer in the world does do this heavy computation, how do they prove that they've done on this computation, so they can get rewarded?'" Which is a pretty perfect setup for zero knowledge proofs. And so at the time, I actually talked to the Truebit team, because they were in that space as well. And they had nothing to do with zero knowledge proofs, but they were working on basically, if you do do the computation and it is dishonest, how do you get caught after the fact? So I thought that was a pretty flawed solution. No offense, I don't wanna...

Anna (09:58):
This is the idea of like, you didn't want to do the submit and then find out later it's wrong, but rather submit it perfectly, be sure in the actual submission that this has been done right.

Elena (10:07):
Yeah.

Anna (10:07):
Validity proofs, kind of.

Elena (10:10):
Exactly. And so the way I sumbled upon zero knowledge proofs is I went to a Coinbase event and I met Joey Krug and I kind of knew who he was at the time. And I wanted to talk to him more and Joey Krug is not the type of person you do small talk with. You can't really ask him about the weather. So I asked him about this problem, like, "You know, I'm thinking about honest computation, what are your thoughts there?" And Joey Krug said, "Well, I don't really know, but I have a friend Charlie Noyes, who's thought about this problem before". And so then I go talk to Charlie Noyes and Charlie Noyes sends me the Pinocchio paper. I don't know, if you're familiar with that one, but this is...

Anna (10:50):
It's a predecessor to a lot of the zk stuff today, right? This is a very academic. Is it a library? Is it a construction or something?

Elena (11:00):
Well, it's a paper. Or, I guess a worker research from Microsoft and IBM research by four authors, I believe, hence I think it's PGHR, don't quote on me that. And it was kind of the first paper that made zk-SNARKs and bit more efficient for generic programs. And the paper itself was actually very short. I think it's something like 16 pages or something. And I remember reading that paper and I remember thinking like, "Firstly, this is very complex. I don't have the background knowledge to understand this, but also wow, this tech is really, really cool". And I immediately understood that, "Okay, this tech is still too early to be used for something like video transcoding, but whatever this tech is, that is the future. Zero knowledge proofs are the future. I don't know how they're going to be used, whether it's privacy, scalability, honest computation. Whatever that thing is, I don't know, but I want to be part of this tech".

Anna (11:57):
Cool. So I guess this brought you right in contact with Zcash. I'm guessing, the next step. If you found the Pinocchio paper, would you have then been like, "Wait, who's doing this in this space, who's working on it?" They were the most visible group using zero knowledge proofs in 2018. At some point though, you jumped in quite deep into it. The talk, was this talk at Zcon1 in Croatia that would have been a year later, where you were presenting the details of Sapling, right? So what were you doing in between those two times? I'm just curious what you were doing then.

Elena (12:32):
Yeah. So I don't remember the exact timing, but ETH Buenos Aires was right as I was leaving Airbnb and then Zcon0 was when I was a week or so after leaving the Airbnb or something, it was very close.

Anna (12:44):
Okay. So you said that you left Airbnb and I guess you were looking for your next project or something like that. But what did you do after that? Did you spend a lot of time doing research? Were you doing some open source contribution? What were you up to?

Elena (12:58):
Yeah, so at that point, I knew that I wanted to work with privacy and I wanted to work with zero knowledge proofs, to some degree, this was still exploratory. And a part of the reason why I left my job was because I wanted to focus on that full-time and it was starting to get hard. And I actually met an investor, his name's Elad Gil, and he's pretty prolific in Silicon Valley, also a very kind human. And we had a conversation where he basically said, "What would it take for you to focus on this full-time?" and I said something like, "I need some funding, because I want to hire people, and mentorship, because I've never done a company before". He was like, "Great!" So that was a pretty easy conversation. So I hired my friend from Facebook, he actually lives in Canada and he worked at Facebook, when I was working at Microsoft. That's how we met. And then he decided to work remotely in Canada. And so that didn't quite work out and I was able to grab him and to hire him. And honestly, for the first six months after Zcon0, it was just research. It was just research on different privacy solutions. How does Monero work? How does this Grin work? Grin was just coming out. How does Zcash work? And also research in zero knowledge proofs, like how does elliptic curve cryptography works? Because we were both engineers, but we were not cryptographers whatsoever. Like how does Diffie-Hellman work? Very, very basic stuff. So we actually started basically from the ground up of learning how all this works. So for me, when I learned it works through a forcing function. And so DevCon 4 was coming up, so I decided to sign myself up for a talk explaining how zero knowledge proofs work. And we got approved for that talk. And that talk was October, 2018, I think. And so that was a forcing function for, we need to learn how this tech works. And yeah, so the talk was actually very much how our learning experience went, how does basic cryptography work? What's the history behind it? How do elliptic curve math works? And then kind of a buildup to here's a very high level of how zk-SNARKs work, but it was like a mid-level, because the frustration that we were working with is there wasn't any mid-level conversation around how zk-SNARKs work, it's either very high level of like Alice and Bob are running through some cave. And then it went from that level to way deep of like, this is how the construction works. And so it was very difficult to get the high level of how zk-SNARKs work.

Anna (15:31):
That is so true. I feel like it's starting to be filled in a little bit more, but I completely appreciate that issue. I mean, I've given talks on zero knowledge proofs, which are very, very high level, and they're so far away from actually using them that I wonder, if it's like a great introduction maybe for people to imagine business cases, but it's not a great introduction for developers to really jump in. And this is what you were providing. That's pretty cool.

Elena (15:59):
Yeah. And then at the time, I think ZoKrates was the only DSL (domain-specific language) for SNARKs. So a DSL is kind of like you write in pseudocode and in the background, the language will construct circuits for you, which will translate to the zero knowledge proof. And for Zokrates in particular, the thing that they've done, which was super convenient, is they would auto-generate a Solidity smart contract for you that you can deploy for verification. Which was actually a very small step, but it was very, very useful. So yeah, so we did that, I did that talk at DevCon 4, and that was great, because I got to meet, again, a lot of people who were working in the space. And my experience so far, being in crypto in particular, is the people are extremely welcoming. And if they see that you care about the same problems that they do, they will help you, which is such an amazing encouraging open and welcome system, that I keep wanting to emphasize that, especially now that there's a lot of toxic things happening in various communities. But I do want to remind people that in comparison to other industries, this is amazing.

Anna (17:09):
You are also talking your period and also mine, my onboarding period was mostly during a bear market. Tarun has mentioned this a few times, like you make the best friends during a bear market, because that's when the tide is out and nobody really cares what you're doing. And the people who are there are pretty genuine. Whereas when it's more bull market, there's a lot more people, it's a lot harder to tell, who's going to stick around for the long run.

Elena (17:35):
Totally.

James (17:35):
And who's here to help you, instead of help themselves.

Anna (17:39):
But anyway, that's a tangent. I think I'm with you though. I think, given how early so much of this stuff is, there is much to build that often if someone is genuinely interested in working on it, I feel the same way. I've seen people in the study clubs or in the groups and the telegram groups, or whatever, really start to emerge just as genuinely curious people who continue to ask questions and continue to try to contribute or help out somebody else, even if they're not in an advanced level. Those are the people who start to really show.

Elena (18:12):
Yeah, exactly. So throughout this journey, when we're looking at privacy mechanisms, and part of the reason why we started Iron Fish, and back then it was called Beanstalk, is because I still believe that zero knowledge proofs are going to be a big part of whatever future tech is going to come out. But going back to my previous example, they're not advanced enough to do things like video transcoding. So for us, it was important to get involved with the tech, but also build a platform for it so that the tech can be used later on, when it does get a bit more evolved. And then, looking in terms of, "Okay, I really want to give back to this space. I want to contribute to the crypto ecosystem. How do we do that with the most impact?" And privacy was just the resounding answer. Everybody at the time was working on stablecoins and scaling, and to a very large extent, they're still working on those things. And very few people were working on privacy. Grin was the only new project in that space, Aztec was just starting to happen. And so for me it was like, "Well, yeah, of course we need privacy. How are we going to make a global borderless unbiased payment system, when everyone can see your funds and that would impact the holder of those coins, if everybody knows how much they have". And so when looking at privacy mechanisms, we looked at Monero, Grin, Zcash, and many, many others. The Zcash Sapling approach was by far the best. And so then when we looked at Zcash, as the company and the product, and again, I'm very, very thankful for them. So everything I say, I don't want to dismiss that. I think they're an incredible project and team. And in terms of community, they're probably one of the most kindest, most open people. And so for us, when we looked at Zcash, we thought, "Oh, we could take Sapling and we could transform it to be something more usable in terms of a privacy coin, but also use that as kind of the groundwork for becoming a privacy shield or privacy layer for other assets". And so that's still our very long-term goal and there's a ton that we have to do to get there. But for us, this was a clear starting point of: "Sapling is, in my opinion, still clearly the best privacy solution. So how do we get close to that and work with it and figure out how to expand on it". So when we started reading the Zcash paper, especially their Sapling spec paper, it's like a mammoth of a document it's like 140-160 page document and it's very complex. So it took us a very long time to get through it.

Anna (20:50):
And so you decided, "You know what, this is a bitch, I'm going to help other people."

Elena (20:57):
Basically.

Anna (20:57):
Because I remember you saying something along those lines, I was at that workshop, and I remember you giving everyone a heads up. I think wasn't the name something like, "I read the Sapling paper, so you don't have to", or something like this?

Elena (21:08):
Yeah. That was my tweet.

James (21:09):
It's a good tweet.

Anna (21:13):
I thought that was great though. And I think that that's exactly the kind of stuff that this space needs more of in terms of, I guess, it's education, it's that bridging between that deep technical side of it and very, very high level, helping people kind of navigate through it and potentially use it.

James (21:31):
Is a video of that talk available anywhere?

Elena (21:34):
Unfortunately it's not, because it was labeled as a workshop and they weren't recording workshops, but the slides are available. So...

Anna (21:42):
Cool. I want to add those, if you have them publicly. I think it would be fantastic to add to the show notes. You don't know how many times in the groups, I get so many questions for onboarding resources and I can be like, "Go to the podcast!" I'm trying to direct people in different places, but I think those kinds of resources should really be highlighted, because they're super useful.

James (22:03):
Well, I have a very distinct memory of being at Zcon1 and sneaking into the back of the workshop, while it was in progress. And the specific slide about all of the different key derivations that are part of Sapling immediately clearing up my understanding of how it works. This very distinct memory of exactly what it looks like.

Elena (22:25):
Well, thank you. Oh, I've actually had some of the people who were working at the Zcash Foundation and Zcash approach me directly or over Twitter DMs and say, "We're using your slides, because it's much more accessible look up material than the spec, in terms of onboarding or explaining to others how this works". And so that was also very cool.

Anna (22:50):
So let's talk now about Iron Fish, because this is the project that was recently announced and what is Iron Fish? Is that an extension of the project you were doing before with Beanstalk? Is it still a research-focused project or is there a product now?

Elena (23:07):
We're much more product-focused. So Iron Fish technically is Beanstalk and the reason why it got renamed is because we actually couldn't trademark Beanstalk, there's a credit card company, I believe in Denver, that took the name, and we wanted to trademark it. And so we went with the name Iron Fish and ironically, or weirdly enough, a lot actually has changed in the code base from the transition of Beanstalk to Iron Fish, in a very pragmatic way. We doubled down even more in terms of making Iron Fish more accessible and I mean that in so many aspects, like running a full node for layer one has traditionally been hard for various reasons. Running a miner for a full node has been traditionally hard. And I think Grin, for instance, to give them a lot of credit, is probably one of the more easier projects to get started in terms of running a full node and running your miner. And they've done a lot of work on making their terminal UI work. And I remember, one of the engineers we hired, who's senior engineer, very brilliant, and it took him two hours to figure out how to run a Grin miner.

Anna (24:15):
And that was the easy one.

Elena (24:17):
That was the easy one. And so for us really wanting to make an emphasis of "This is a product, we're focusing on privacy. This is a new blockchain, but everything we're building from the ground up is very much focused on usability because we strongly believe that if you are building this currency for the people, then the people should be able to run your software". So Iron Fish is still very early, and we have a ton of bugs and we have a ton of flaws. So I'm not trying to hide that, but our ethos is still the same. So we did launch our testnet on April 6. And if you want to run Iron Fish, you have to brew tap, and then brew install Iron Fish. And then Iron Fish start, you have a full node running, open other terminal, Iron Fish miner start, you have a miner running, and that's it, you're done, you are now onboarded. Congratulations!

Anna (25:10):
Wow. But would you still have to set parameters? Is that like the onboard is easy, but then do you still have to do something, if you want it optimized in a particular way?

Elena (25:22):
Sure. I mean, we have configs available. If you want to connect two different bootstrap nodes, you can actually do almost everything from the command line. And then some things you have to go to the config file to change, but if you're a power user, you're probably familiar with that anyways. But if you're just curious and you wanted to figure out, "Okay, I want to set up a full node, how do I do that?" That part we try to make really easy. And I want to be pretty humble about it, there was a ton of learnings that we had throughout this project, and we know we have still a long way to go. I think Iron Fish did receive the hug of death on day 3 post our launch, which was like a double-edged sword. It's great to see how many people were using it. But after, I think, it was roughly 450 full nodes and probably that many miners, we definitely did get synching problems. So if you launch Iron Fish today, you might have some problems. However, we do have a fix coming, it's staging right now.

Anna (26:18):
You've just called this "the hug of death"? Is this like too much love? What is it?

Elena (26:23):
The hug of death is like when someone posts something on the Hacker News or it becomes viral on Twitter and then the website goes down, because too many people are clicking on it. So before we launched Iron Fish, I think we tested on something like, consistently tested, on like 20 nodes, 20 miners. And it was all fine. And when we talked to a bunch of other people, who've launched testnets before, we thought, "Okay, we're going to have roughly 200 people run a full node". This is from casual conversations of just other projects. And then we had more than double that, we had 450 people run a full node on day 3. And that's when we started to have synching issues. So, again, the fixing it, it's on stage.

Anna (27:07):
I want to know a little bit more about what this client software is. First of all, is it a fork of Zcash? Because there is some relationship, right? As I've understood it, Sapling and all that work that you did on Sapling, it's connected to what you're doing with Iron Fish. Is it a fork of the actual client software or is it something else?

Elena (27:25):
So Iron Fish, as it is, is not a fork of Zcash. It's a new project from the ground up. And the reason why we did that, because we wanted to have flexibility of really building out the features from the ground up to make it more usable.

James (27:40):
I was going to ask, Zcash inherited a lot from the Bitcoin code base. Is this a completely new implementation or we're trying to inherit from older blockchains?

Elena (27:50):
No. So this is an entirely new implementation, which, again, it's a double-edged sword, it comes with benefits and drawbacks. So when we were called Beanstalk, we were actually fully in Rust. So we started with Sapling and we took Sapling. We didn't even take full Sapling. We actually just took the proof generation verification and we inherited some other things to make it, again, a more readable Sapling in terms of code. And then we decided to build on top of that, because we started with Rust and Rust is a very performant, efficient language. And so we decided to build out the entire blockchain implementation in Rust as well. And we realized that was actually a very daunting challenge for many reasons. Rust will make you go slower in terms of development cycles. And the open source community is getting to be more mature, but it's still not quite there yet. And if you want it to have integrations, like we were very much fighting the language and then when we raised a round and were able to hire more people, we realized hiring Rust developers was very difficult. And if we wanted to make changes....

Anna (28:58):
Because there's not that many.

Elena (28:58):
Yeah, there's not that many.

James (29:00):
I'm struggling with that right now.

Anna (29:01):
Oh man.

Elena (29:03):
And we wanted to experiment with a lot of ideas. Like we wanted to experiment with a new block synching technique. And we realized that every experimentation cycle, because we were doing things in Rust, would just take us a very long time. So it was very hard to innovate, when your development cycles were 3 months instead of 3 weeks, as it would be in a different language. So we actually decided to switch to TypeScript, which in terms of performance, of course, is going to be slower than Rust. But in terms of development cycles, it gave us a ton of flexibility to be more experimental and to think about efficiency in a much different way, and also to hire really great talent ,that didn't have to have this really steep learning curve. So Iron Fish is a new blockchain from the ground up. And so for us, since we think about efficiency in a very different way, in terms of how do we sync faster, but logically, not so that the node takes up all of your CPU, because Rust is pretty great in that regard. It's more like, how do we think about it in a more logical way? How do we make it sync faster? So it's kind of a blessing in disguise as well, because we're able to run on basically any device, any device that can support Node can support Iron Fish. And the crazy idea that we realized was actually our entire tech stack can be fit directly into the browser. We can have a full node implementation be directly in the browser, which at the time that I thought of this idea, I thought that was super revolutionary. And this was actually done before, there's a project called Bcoin, which is a Bitcoin implementation in JavaScript. And they have client that works directly in the browser. I think that project, for what it's worth, is somewhat abandoned, I'm not entirely sure.

James (30:55):
Bcoin is maintained by the Purse team and they put a lot of their development resources into handshake. And so HNS, the handshake node, is based on Bcoin. So it's still somewhat maintained, but not as much as it was 3 years ago.

Elena (31:14):
Gotcha. I mean, that project for us was just very encouraging to see that this is possible, this had been done for Bitcoin. And Bitcoin is, in terms of size, a much bigger blockchain, and this is still possible to be done in the browser.

Anna (31:29):
What are the pros and cons of being able to run a node in the browser? I guess it's more accessible to people, it's lighter, but is there some downside to doing that too?

Elena (31:40):
Yeah. So a little bit more on the pros. For a private sequence in particular, if you want full privacy, then you're going to have to run a full node. And even light clients and Zcash has their implementation. You will be giving up some privacy, when you're using it. And I don't want to get into the details, cause it's a very philosophical argument of like, "Okay, well, if this happens, then that happens, and maybe you'lI lose some privacy". But I think most people will agree that to some extent you are leaking some privacy. So if you really want full foolproof privacy, you're going to be running a full node. And so for us, it's very important to make that accessible. How do you make a full node run faster, easier and so on. So for us, the idea of Iron Fish running in the browser is a pretty powerful one. Because, again, if we're building this for the people, then people should be able to run it, and if you can make the argument that it's as easy to run as opening a tab, with persistent storage so don't worry, every time you close the tab, it doesn't mean you have to restart redownloading Iron Fish, so that was a very powerful thing for us. That's kind of more what we're focused on.

Anna (32:45):
Cool. I guess, if you have a shielded account wallet, are you running a light client on your phone, if you had that? Is that how you're syncing? Or is your wallet syncing to a light client or a regular node and sending you the information back? This is actually just a clarification.

Elena (33:00):
So I think the way ZecWallet works, which is on your phone, so ZecWallet wallet, it does support shielded transactions on your phone. I believe how it works is first, there has to be dedicated light client server that can support a phone and as it can support the phone, basically the phone will say, "I would like these block headers, or I'd like these nodes and whatnot". And this particular light client server can give them like a trimmed down version of the block, so that the phone can actually process it. So for instance, if you've used your ZecWallet app for the first time, then there's zero syncing time, because the wallet understands "It's a wallet, I don't need to sync". if you use it once and then don't use it for, let's say a couple of weeks, then the next time you come back to it, your wallet will be syncing to catch up.

James (33:48):
When we think about these things, there's really two questions you want to ask, which is: "What can the server learn about the phone or the light client?" So can it learn what block the phone is on? Can it learn who's running that, what the OS is, what kind of private information can it learn about the phone. And the other is: "What kind of thing can the server conceal from the phone?" So can the server just not send me information about a block or a node and prevent me from learning that I received a payment, or show me the wrong balance for my account.

Anna (34:28):
I understand that example. Now I want to go back to this browser example. So what you're talking about is you would actually be doing... I guess, as an end user, I never imagined that I would be running a node, but this is the way to get actual privacy. And the only way you can do that is if the node is so accessible, that the end user, the wallet is not talking to anything, it is the node that you're actually running, that's what you're working from.

Elena (34:56):
Exactly. So instead of relying on the server to give you information, you are that server, because that server is a full node. So now you're a full node. So most people use a router. So right now you're probably on a laptop recording this, and you're probably connected to a router. So this means that your router is now ferrying things back and forth. So your router assigns an IP for you to be used by other things. So your laptop, as of now, it doesn't actually know its public IP. If public IP is the name to your device, your laptop currently doesn't know its name. So if it's trying to reach out to another node, let's say, you're trying to reach out to James, because James has a public computer, so you know James has public IP directly. So you reach out to James and you get some information from James, but James actually doesn't know how to reach back to you, because there's this router in the middle, there's this router between you and your computer. And so you need to tell James your name, but the problem is you don't know your name yet, cause you router needs to assign that for you. So James doesn't know how to reach you, because he doesn't know how to get to your computer through this router.

Anna (36:07):
In this example, if I already requested something from him so I can actually get some info from him, but he's not sending it at me. It's like, I want this and I fish it and pull it back, but it's not like he knows where that trajectory is exactly.

Elena (36:24):
Exactly.

Anna (36:27):
Okay.

James (36:27):
And after that connection is done, I can't push anything else out to you. I have to wait for you to call me again.

Elena (36:34):
Right. So if you are nodes in a peer-to-peer distributed system, in this regard, you would be kind of like the greedy node. You would be getting everything that you want, but James can't get information from you because James doesn't know how to connect to you.

Anna (36:50):
Got it.

Elena (36:50):
So going back to the full node and why WebRTC is so exciting is because it makes that entire process a lot easier. The process of two nodes connecting to one another and the two nodes actually talking to one another without this kind of hindrance of going into your router settings and telling the router to forward your port and so on. So again, this is an easier process to run a full node, because if you wanted to run a full node on Bitcoin or Ethereum, and if you want it to be actually fully connected, so be fully active listening node, you have to go through those extra steps, probably in your router or in your firewall to actually be fully connected. And WebRTC is a technology that was actually invented by Google for video streaming for exactly this problem. Because they realized if you have video streaming going through a centralized server, you're probably going to get, to some degree, a poor user performance, because it has to go through another party and then go to someone else's computer. Since then they were like, "Okay, how do we actually connect two computers together to do video streaming better?" And they actually basically made the WebRTC and incorporated that into the Chrome browser, so you can do video streaming. So we're using WebRTC web sockets right now for a full node implementation that runs on your terminal. But this was actually a technology that was built for the browser to make video streaming better. Anyways, so we're using the same technology that we're probably using right now for video streaming.

Anna (38:14):
But I want to understand back to the way you described launching an Iron Fish node, is it actually running in the browser? Or is that the future is going to be running in the browser?

Elena (38:23):
So the current implementation runs in the terminal only, but because we're using TypeScript, Wasm or I guess Rust with Wasm. The full implementation actually could run in the browser. And so that is definitely a feature that we're pretty excited about, but we do want to focus on making sure that the core protocol works as intended in the terminal, to make sure that those bugs are out of the way before progressing to the next one.

Anna (38:49):
And you built this entirely from the ground up, as you'd mentioned before, and yet it still has this privacy part. How has Sapling integrated into that? What is that connection point then? So it's not similar to the Zcash node software, or I guess it still has some of these Sapling principles in it, or some of that code is running within it. So how does that connect?

Elena (39:11):
Yeah. So Sapling is the mechanism for making transactions private. We took Sapling and we took someone for Zcash code. We wrote some of our own code to make it kind of our own implementation Sapling to some degree. I totally want to give them a lot of credit though. So that means basically that the privacy transaction mechanism and Sapling is written in Rust. So we have it working in our TypeScript implementation through Wasm as the glue layer, effectively. And then, in terms of our implementation of the full node, that we've done, basically from the ground up and we did take a lot of inspirations from Bitcoin, honestly, and some inspirations from Ethereum. But in terms of implementation, we did it all from the ground up and Sapling is just our mechanism for making those private transactions.

James (39:58):
So, like Zcash. This is a blockchain with Sapling for making transactions.

Elena (40:05):
Correct. The distinction is that we have no way of doing transparent transactions, it's only private transactions.

James (40:12):
So you don't have any of the weird Bitcoin script craft.

Elena (40:17):
No. Speaking of scripts though, we do want to go into that trajectory. So going back to the thing that I've said at the beginning of the talk, is we want to make this more into a privacy platform. Right now it only supports Iron Fish, the native currency, but we want to get to a world where we could bridge assets from other chains and basically be the shielded pool for all the assets. So again, we want to make Iron Fish the privacy platform. So we don't have programmability yet, but we do want to get there so that we can support other assets from other chains and make Iron Fish more privacy platform for everybody else too. So, yeah, it's a long road and we have some ideas of how to get there, but we will be getting to a future where we have some functionalities or permissions. So it'll be a lot less flexible than a smart contract on Ethereum. It'll probably look a lot more like permissions per account per asset, but we will have some concept of programmability in the future.

Anna (41:15):
You talk about it being the privacy center of other networks, other chains, but would you then be thinking about it as creating bridges to a lot of different places? Or could you turn this into an L2 to Ethereum and then allow that to be your connection point?

Elena (41:31):
Yeah, I guess, when we look at L2 designs, and especially for Ethereum and, you know, Aztec is working on one, that's more privacy-focused for Ethereum, the question is, "Are they looking a lot like L1s?" Are these just L1s with bridges to specifically Ethereum?.

Anna (41:54):
More and more!

Elena (41:54):
Yeah, they're looking more and more like L1s, but very integrated to a particular chain, which gives them the right to call themselves L2s to some reguard. And so for us, when we think about Iron Fish, it's we want to build bridges not to just one chain, but to many chains. And so right now we're definitely an L1. We only have Iron Fish as the only asset. We want to get to a world where we support assets from other chains. And so instead of building bunch of L2s for other chains, we have Iron Fish, where it's like this huge shielded pool for all these other assets where one transaction is indistinguishable from a different transaction. So regarding, if you trade some Cosmos asset for some Ethereum asset, for some native Iron Fish asset, the transactions will be indistinguishable. So you can't actually tell that.

Anna (42:45):
Would you use something like IBC as well? If you implemented IBC, would you then automatically, this is actually for you, James, would you then be able to be connected to all of the zones in the Cosmos context?

James (43:01):
I think so. This is a really interesting question, because there are a lot of choices for bridging right now. So IBC is one avenue that you could go down to connect to the Cosmos ecosystem. Elena, do you have a concrete plan for bridges? Or is this something that's still very much in development?

Elena (43:21):
Yeah. So I think we talked about bridges when you were still working on Sumo, which was two years ago, right? Like Zcon1?

James (43:28):
Yeah.

Elena (43:28):
And so back then, there were already a lot of bridging solutions and now we have even more bridging solutions, and there are different types of bidging solutions, ones like Sumo, which are totally decentralized in terms of there's no middleman. Then there's ones that Keep Network, where the middleman is decentralized, but there is a middleman, so to speak, which is the Keep Network. And then there's ones that are fairly centralized, where the thing's called federated or something like that, where there is literally a centralized authority that says, "We'll escrow your Bitcoin. And then give you wrapped Bitcoin on top of Ethereum or whatever". So for us, in terms of bridging solutions, we're pretty agnostic. We want to be able to support all those bridging solutions. And I also want to make sure that we don't work on the bridging solutions, as Iron Fish, that we work with others, for two reasons. One, because it makes the community stronger. And two, because as much as we can learn on this, there are now experts on bridges. There are companies being built around this, multiple ones. And so for us it would be kind of silly to build our own bridge, when we can convince these other people to partner with us and to build those bridges, you know, nudge, nudge, Keep Network, or somebody else. So, I mean, it depends on... I think it would be a per case basis. I think we'll focus on Ethereum first. That seems like a very clear thing to focus on first. We might focus on Bitcoin next, somewhere down the line, we might focus on Cosmos. So I think it might be like a very per chain or per protocol sort of basis. And we'll probably try and focus on existing solutions. So if someone already did make a bridge from Cosmos to Ethereum, and I think someone actually did, we'd probably go to them and talk to them and work with them. So, yeah, that's how we think about it. Like our job is to make sure that Iron Fish can support those bridges and then go to people who actually make a business out of it to work with them.

Anna (45:21):
I want to explore a little bit the actual use of Iron Fish. I want to kind of go from a user's perspective. Like you mentioned, it could be a privacy platform with private computation, maybe not extensive computation, but some computation.

Elena (45:36):
Like permissions, like very basic ones. So the permissions we'll want is primarily to support stablecoins and bridges. So these permissions are going to be very much like, "'Can this address burn or mint a certain asset", because they have the permission to do so. So it'll not be a full zk computation, I don't think we'll get to that anytime soon, but we do want to focus on very pragmatic use cases of how do we support DAI on top of Iron Fish, so now you can transact stablecoin or synthetic dollar on Iron Fish totally privately. And then even with just the very basic permissions of like, "can this address mint or burn", we can support stablecoins that are not algorithmic, like USDC-style, when there's an actual bank account and there is an address that has permissions to mint that coin. And so something like USDC could mint the stable privacy coin on top of Iron Fish.

Anna (46:32):
The idea here has really been to provide primarily a private transaction in a shielded environment that is running in your browser potentially, which sounds really cool. So you would be running your own full node in the browsers. Everything you do is completely private, without needing even to call a light client, you wouldn't even have to have that extra step.What kind of economy do you really envision happening in there? Do you see it as just like" I'm paying for something and I'm doing subscriptions", maybe? What kind of use cases do you imagine people using this for?

Elena (47:06):
Yeah. So for privacy coins in particular, I get this question a lot: "Well, who's going to use you?" And this is very like...

Anna (47:13):
Is it criminals?

Elena (47:14):
Exactly! Is it criminals? Is it illicit activity? Are you going to make Silk Road be... Alive?

Anna (47:21):
I'm definitely not asking you that in that tone, but I think it would be cool to hear your answer anyway.

Elena (47:26):
Yeah. So, I mean, when I think about privacy, there's two use cases. One is very philosophical of: we need privacy, cash is going away, we don't have a digital cash alternative, we need a very private dollar for everyday use cases. And these are not necessarily illicit use cases. Like maybe you want to go see a therapist and not have anybody know about that, because that's private information. Maybe you're going through the US immigration process, and even now, if you buy weed in a state where it's totally legal, that could actually jeopardize your immigration process. There's like a ton of use cases, where you might just want privacy and we're going to a world where without cash, everything happens online. You're starting to lose that. So that's a very philosophical question. I'm like, "We actually need privacy and we're losing it pretty rapidly". And then the other answer is a very pragmatic one, which is like, I think if crypto is going to have a future as a payment system or as a banking solution, you're going to have to need privacy. When you talk to normal people and explain to them how Ethereum works, that yes, you actually can open Etherscan in incognito window even, and still look at your wallet and realize that everyone else can too, people are pretty shocked about that. And so the very pragmatic approach is, if we want to have crypto have mass adoption, we need to have a privacy layer, because this is actually a privacy coins that are probably the closest to the paradigm that we have today of having some expectation about our financial privacy. Like if you and I interacted, and maybe I bought you coffee, I shouldn't have the right to look at your bank account, right? And in crypto, it's kind of like that. And so for me, it's a very pragmatic approach of like, actually crypto probably doesn't have a future as a payment system, if everything is so out in the open.

Anna (49:21):
This has come up a few times in, I don't know if it was on the podcast or event or something, but it was the idea of trying to add privacy after the fact versus trying to build it in at the beginning. A lot of the problems with trying to claw back privacy, when it's gone, is that you're not really going to get what you need. It's just sort of, add-ons, it might obscure a little bit about what you're doing to certain people, but there's ways around that. Whereas if you have systems that have privacy at the heart, then you can actually potentially have truly private systems. That's been something that I'm hearing a lot from various camps. And this is where it's kind of interesting: you build it from the ground up, with privacy in mind, to be very usable without having to use these other agents in order to connect to other people. Do you want this to be used actually by the big businesses of the world? Or do you actually prefer this to be used by the individuals of the world? I'm trying to figure out if this is something that eventually becomes an institutional play or if it's really for everyday people.

Elena (50:28):
I mean, the double-edged sword of building out in the open, a very decentralized way, is that you kind of don't have a choice. And you can direct the product to some degree. We can make it maybe more polished so that banks would be more comfortable with using it, or maybe more casual so that it's more of a product for the people, but at the end of the day, you don't really have a choice. Now I actually do think that it is important for banks to get into crypto before, once again, a crypto adoption. And banks right now are pretty nervous about the fact that everything's so out in the open. I think that was why Ripple was so popular. And also why Ripple got a lot of backlash, because banks weren't using the public Ripple that we were using, they were using kind of on-prem Ripple, because privacy was a big concern for these banks. So to some degree, do I prefer one way or the other? I don't think I have a preference. I think both are actually very important and we're definitely building Iron Fish that it could potentially be used for both.

Anna (51:22):
Cool. So if somebody wants to start participating in the Iron Fish community or running some of the infrastructure, where should they go?

Elena (51:29):
Yeah. So we'll post links on the onboarding docs for how to get started. We'll also post at our GitHub, so you can look at all the code and also the installation instructions from source. And then we have a Discord, which is a pretty huge community at this point of other people who are running the Iron Fish node, who have questions about it. So if you want to talk to any of us or have questions or a feedback to post, please get to our Discord.

Anna (51:55):
Cool. Well, I'm really excited to hear more about this as it develops. And I want to say thank you so much for coming on the show and sharing with us not only Iron Fish and how it works, but your journey to getting to this point and your hope for what it could be.

Elena (52:10):
Thank you so much. Really appreciate to be on here.

James (52:13):
Yeah. I'm running a node downstairs. I'm really excited to be able to get to use it when it goes mainnet.

Anna (52:19):
Very cool. So thanks again. And thanks, James.

James (52:23):
Thank you, Anna. It's good to be here again.

Anna (52:25):
And thank you to the podcast producer, Andrey, the podcast editor Henrik, and to our listeners.