 Hey everyone, we're here to talk today about our journey from Solidity Dev to ZKDev. Talk about how we went from Solidity developers, got introduced to zero-knowledge cryptography and went on to implement battleships. So my name's Ian, and I'm Jack. And yeah, like we said, we're going to walk you through our journey and how we got to where we are today. But first off, I want to start by thanking the Ethereum Foundation. Just over a year ago today, Battleships was just an idea. And to go from presenting at Eat Denver, receiving a grant from the Ethereum Foundation up here, presenting at DevCon today, you know, it's a pretty surreal experience. So none of us expected this, so thank you. So before jumping into our journey in ZK, first let's start off with a question. What is Web3? Shout it out. Yeah, please raise your hands. What is Web3? What is Web3? Decentralize. Decentralize. All right, answers. I think to really get an appreciation for what the definition of Web3 is, though, it'd be helpful to look at what some of the tight ends of the industry have said. So Satoshi, oh wait, that's not Satoshi, I guess. Okay, you know, we'll go with that. Satoshi, and I just want to preface real quick, blockchain predated Web3 by about five years. So this is defined as Satoshi's terms of what Bitcoin was. He basically said Bitcoin is a purely peer-to-peer version of electronic cash, which would allow online payments to be sent directly from one party to another without going through a financial institution. Next, someone we probably all recognize here as well, Vitalik Buterin. In the context of Ethereum, his definition of Web3 was, what Ethereum intends to provide is a blockchain with a built-in, fully-fledged, Turing-complete programming language that could be used to create contracts that then could be used to encode arbitrary state transition functions. But none of this would be possible if it weren't for the work of Nick Szabo, who coined the term smart contract and came up with the idea in 1994. And his idea of what this ecosystem represented was, the obscurity of a large random number so vast that a lucky guess is unlikely in if desired the lifetime of the universe. And that's the foundation on which cryptographic protocols and intern smart contracts are built. And then finally, appropriately ending at the pointer of the term Web3, Gavin Wood, his definition was, in short, we engineer the system to mathematically enforce our prior assumptions since no government or organization can recently be trusted. So that leaves us with our own definition. Web3 is sovereignty in cyberspace. And following from that, cryptography is authority, the enforcer of the laws in this new inset space. So now that we have a definition, a little bit of the etymology of Web3, let's talk about the actual state of this industry and specifically some of the issues that are plaguing it. Personally, we see the biggest issue as being the almost zealous conviction in tokenization of all assets. And perhaps this might be a little America-centric, but you could just take a look at the housing market as an example of an asset class that maybe you don't want to hyper-financialize. And what we essentially are seeing is that as time has gone on, protocols focus more and more on financial prosperity rather than the actual core tenets of what Web3 is supposed to be as we just went over. And beyond that, I'm sure a lot of you here have heard a lot of talk about privacy and scalability over the past few hours. Again, from an individual perspective and from an enterprise perspective, it's unusable a lot of the time. So, I mean, if you tried to make a swap when Ether was at $4,800, you probably paid $50 for a swap, that's bad, that hurts. And while some of us have gone ahead with Web3, despite privacy concerns, there are a lot of ways that private information can be leaked. And then on the front of enterprises, they've just full-blown written it off for these reasons. A $50 transaction fee is a non-starter. And the fact that certain information is public on a public blockchain, again, is a non-starter. So we saw the rise of private blockchains, and those were also ruled out as while they are private and scalable to the outside, you are still sharing critical business information with the other validators who happen to be competitors in the industry. So what we've seen is essentially, at least until recently, the solutions were just not there. So, really, we think that we can summarize this issue in a single way, that Web3, which has mostly become synonymous with DeFi, DeFi decentralized finance has lost the plot of Web3. Cryptocurrency has become this mechanism for profit generation, whereas that's not really what Bitcoin was supposed to be. Bitcoin, while it has appreciated considerably from being worthless back in 2000, 2009, it appreciated because of its financial agency instability relative to fiat currencies. It was designed to be not censorable or manipulatable. You can print more than $21 million. And the fact that it appreciated in this economic condition is a consequence. It wasn't explicitly engineered to go up. And then we have protocols like Terra Luna, where there wasn't too much innovation on the side of the decentralization or peer-to-peer networks or cryptography. But they did present a novel algorithmic stablecoin, which turned out to be a financial weapon of mass destruction. A lot of capital was destroyed, both for retail investors and institutional investors lost a lot of money. And not only is this bad for the industry just because there are resources that are suddenly taken away. It actually causes a recession in decentralization in this industry, and this is I think something even Vitalik has brought up. As we create these insane volatile liquidity events, governments notice and they decide their mandate is to exert force or exert power over these industries. So as we create more of these opportunities for them to notice, we lose decentralization. So essentially what we want to see to have Web 3 grow to where I think we all see it being in the future is for Web 3 to break out of decentralized finance and become something more than just a monetary tool. And we kind of see that with decentralized science, decentralized social media. Some governance tools are definitely more focused on information rather than the financial aspect. What we really believe is that zero knowledge cryptography is going to cause an explosion in these tools. So specifically you might, if you're a little unfamiliar with zero knowledge, you might think of tornado cash and how zero knowledge can be used as a tool of anonymity or potentially even subversion of central authority or surveillance. However, it's actually important to note that at pretty much its inception, one of the thought experiments for justifying the need for zero knowledge was denuclearization between bitter enemies, the United States and the Soviet Union. They needed to prove to each other that they were actually denuclearizing, but they didn't want to send or they didn't want to allow inspectors from each other's countries into their nuclear bases. So to have disjointed or adversarial parties that are able to coordinate and prove things to each other is incredibly valuable both in the decentralized context where parties are just disinterested and perhaps in more centralized contexts like the relationship that individuals often have with central authorities where incentives are very much misaligned. We can start to build solutions that kind of bridge that gap. So going into the specifics, again, on one end we have tornado cash, coin mixers which are alternate tools of anonymity and on the exact opposite end of the spectrum with very similar code, we have tools of compliance, know your customer, anti-money laundering. And moving on, there's also, and I'm sure a lot of you have seen like the temporary anonymous zone, all the semaphore stuff, there's the ability to create anonymous social media programs that again allow coordination without any sort of central authority. And on a completely unrelated vertical, we can construct IFF signals, which many of you probably don't know what those are, but essentially identification friend or foe signals go on combat aircraft and when they're flying through an airspace, you can basically, with zero knowledge, IFF, you would prove that you're allowed to be flying in that airspace without actually revealing the details of that mission. Then we can start to fortify trustless computing, even bulletproof hosting, and again on the other side of things. We can be fortifying centralized processes, specifically let's take the IRS. There's a little bit of entropy that goes into the audit lottery, so we want to make sure that entropy is sampled correctly. As well, all of the parameters that are used to choose how someone is audited, we want to make sure that those are all correctly chosen and proved. And then finally, something that is not so new, Chainlink has been working on proof of reserves for a while, but facilitates the unbanking of populations. And again, on the other hand, we can have centralized supply chains. So take the distribution, let's say of alcohol, when you go to a bar, you need to prove that you are of age, and the bartender needs to prove that they are only distributing alcohol to people who are of age. And this takes the form of literal cops sending in minors to actually test these places. And that is a reactive solution that uses resources, whereas if we were able to have a system where you can't even get in the door if you can't prove you're 21, we create a lot more. We free up resources for obviously the people who are checking the cops. And then as well, it makes the lives of both really the distributor a lot easier given that compliance is managed in a programmatic way and a provably correct way. So just to summarize it, we have SEMIFOR again, which is something that could be used for anonymous coordination or KYCAML. So what you should really be thinking is that zero knowledge is an incredibly versatile tool and how it is actually molded into whatever product, that's up to you. So specifically, if you are kind of intrigued by SEMIFOR and you think that you have some way to contribute, there's actually a grant round going on right now. It said 14th on an earlier thing, but I'm pretty sure that this link says the 28th. So I would highly encourage you, again, if this is remotely interesting, to look into that grant because there is a huge community of like-minded people. Awesome, yeah, with the background of some of the applications of zero knowledge, let's jump into the actual history and how this came into being. So no doubt, zero knowledge has very much been somewhat of a zeitgeist this past year. Everyone's talking about it, how it could be used for privacy purposes, scalability. But what not many people might know is that actually you can trace its genesis back to 1985, two years after the founding of TCPIP and six years prior to the first website on the World Wide Web. It was first published in an obscure paper by Goldwasser, Macaulay, and Rakoff. And really, with this paper, it first introduced the whole entire concept of zero knowledge cryptography, but it'd be about three decades until we actually saw some additional work on this. In 2013, we saw the first ZK-SNARK implemented through something called Pinocchio. We saw the first example of a ZK-VM through TinyRAM. These weren't blockchain-specific per se, but three more years we would begin to realize the opportunity that zero knowledge cryptography really could provide in terms of scaling and providing privacy to Ethereum. And this happened through the proving mechanism called Grot16, which was really the first practical ZK-SNARK, something that could handle almost any arbitrary computational problem and encrypt it. Two years later, we would see a golden year in zero knowledge cryptography. Barry White had implemented the first roll-up as far as we were able to ascertain. CIRCUM, a language made specifically for writing ZK circuits, were released by an organization called IDEN3. The foundation of the ZK-SNARK, which is a different type of zero knowledge proof apart from SNARKs that stands for Scalable Transparent Argument of Knowledge. And what it really provides that SNARKs don't is it's quantum-resistant, and it also removes the need for a trusted setup, which up until this point has been a major complaint of implementing zero knowledge proofs. It's forward to 2019, and Aztec released a new proving scheme for SNARKs called PLONK. The student totally get rid of the trusted setup, but what it did allow is a universal trusted setup. So instead of needing to perform a lengthy trusted setup for every single SNARK you implement, you only have to do one that can then be applied to many. A year after that, StarCnet released their own ZK-VM called StarCX with its native language called Cairo. Finally to us, ZCASH started to work on the Halo 2 proving scheme, which is foundational for Battleships V2, what we want to accomplish sure enough. We'll talk about that a bit later in our presentation. A year after that, MENA came along with the idea of SNAPs, zero knowledge applications or zero knowledge SNAPs, as well as Circum released, or IDEN3 released Circum 2.0, which really with that, that's what made it possible to release Battleships V1 and present at ETH Denver back earlier in 2022. Then fast forward to modern day, a year later, 2022, PLONK-E2, the successor to PLONK, allows proving speeds that are 100 times faster, ZK EVMs are beginning to enter the mix in the experimental stage that include Polygon Hermes, SCRL, which actually implements Halo 2, and then ZK-SYNC as well. And then finally, an interesting application that exists now is ZPRIZE, which is a zero knowledge analog of XPRIZE. What it basically aims to do is provide a list of bounties so that those interested in improving the efficiency, which with zero knowledge algorithms compute, can go and claim these prizes. But yeah, no, now that we've gone through the lengthy history, let's talk about how you can actually apply ZK to the EVM. And to do this, you really have two options. You have the option of applying a domain-specific language or utilizing a ZK virtual machine. And both methods have their own pros and cons, their own trade-offs. And ultimately, what it comes down to is what are you trying to achieve with your application, what's the scope of it. But we'll go through the pros and cons right here. This pointer is tricky. So when it comes to a DSL, scaling requires expertise. But with ZK EVM, the entire purpose of this other network is really to allow scalability of your applications. With DSL, its computation is verified directly on layer one. But with ZK VMs, technically they are a layer two, so all computations take place on a SIP layer two. And then consensus for DSLs comes from the root Ethereum network of your choice. And then again, touching on the point just before, a layer two, or a ZK VM being a layer two, you're relying an entirely separate set of security and validators that you trust will put your eventually reach consensus on layer one. But ultimately it's up to this external network. And then when it comes to DSLs, the software development kits that exist right now do their best to abstract away complexity. But really what ends up happening is you kind of have to put on another thinking cap. For those of us who are used to developing in standard languages, you really, when writing zero knowledge proofs, can't get away without learning some of the cryptographic principles, underlying elliptic curves, finite fields, constructing arithmetic circuits. So there's definitely a lot of overhead and a lot of investment you have to put in before you can actually get to writing your own program. Whereas in a VM, it's specifically abstracting a lot of the ZK overhead away, so you can get in with knowledge as a developer and get ahead and run your apps like that. And then finally, talking about portability between DSLs and VMs. What a DSL basically allows you to do is it's a way of constructing your files for proving and verifying zero knowledge proofs. And then it's up to you where you want to deploy them to, be it a slowly smart contract on the Ethereum chain. It's really up to you where you deploy to. But when it comes to ZK VMs, you face vendor lock and risk. You might have a specific idea of what chain you want your application to end up on, but down the road, if the scope of your project changes, you can end up being locked in and lose some flexibility that way. But the route we ended up going on is DSL route. And for that we chose Syrcom. Syrcom was an obvious choice because it intuitively provides a language that closely mirrors the cryptography you have to learn. So after going through that headache, learning the ins and outs of the underlying cryptography, you can pretty much write out everything you've been working on in the past weeks or months, however long it takes you. But anyways, as much as we love Syrcom, we found it difficult to actually go from beginner ZK developer to releasing battle zips. We actually have crafted our own good book called Awesome Syrcom. And you can reach it there by scanning the QR code or go to battleships.com slash resources. But I just want to preface that it's not quite done yet, but come this Friday it should be complete. Yeah, check it out for sure. Yeah, so again, we are working to get that just about finished. But we have basically taken the topics that we think are important from someone who's absolute newbie to basically be introduced to borderline spoon fed. And there are some that are really well documented via the proving systems. Groth 16 and Plonk and the powers of Tau ceremony that is trusted setup for Groth 16, we don't really need to do a lot for that. We are really just aggregating existing documentation and putting it in an easy to access format. On the other hand, we have multiplexing in Syrcom. This is a little hidden tidbit that took us a while to figure out. If you read the Syrcom documentation, you will be misled into thinking that you can use if statements. You cannot use if statements the way you think. If you try to use an if statement to select a conditional statement in Syrcom, you will get an error called non quadratic constraints, not allowed. Very dreaded. And to circumvent it, essentially you need to do something called signal multiplexing, which is where in zero knowledge, you compute both cases. Or let's say you have n different branches of logic, you compute all n branches. And only once you've computed every single branch in zero knowledge, then can you select which branch you want. And this is an analogy from electrical signal processing. I believe this is how TV channels and cable even works. But the point is, if you aren't familiar with this, I know I wasn't when I was looking through various code bases and looking at multiplexing. And while you see an if statement in the documentation, it can be very confusing. But so that's an example of something we go more in depth on. For the sake of time, I'm going to speed through a little bit of this. But we have some stuff that's, again, more documented, which is the arithmetic friendly implementations of different hashing algorithms, which then underlie the signing algorithms. So SHA-3 and ECDSA out the window. We're now using Poseidon or MMC at the very least and EDDSA, which are far more efficient. We have Merkle trees, which I'm sure a lot of you are aware of. But they are one of the most powerful tools, both for privacy and scalability. We can take a massive, massive data set and compress it into a tiny hash. And not only is this clearly a method for scaling, but we're also taking that data set and obscuring the data within it, while still being able to operate on it. So this gives us both privacy and scalability. So you will definitely be working with Merkle trees. And then there is first and third party dev tooling. The first party dev tooling you literally just have to use. CIRCOM relies on start.js to actually put proofs in the EVM. And then there's also CIRCOM tester, which unless you want to spend two hours running tests every single time, you're going to want to use something that simulates the logic rather than actually running the entire overhead. And then there's also third party tooling, which is maybe not as required, but still is very important for having a good time developing. So there is the Shield CLI, which was just released, I believe, two weeks ago. They've released their first non-beta version. And you can think of Shield as hard hat or maybe truffle for CIRCOM. Essentially, you'll see in the BattleZip's code base, there are a couple of bash files that handle the generation of circuits. And this is something that requires an understanding of what you're doing. Whereas the Shield CLI will just do this for you. So whether you're already experienced with the CIRCOM start.js in Solidity Stack or you are brand new especially, it's going to be very helpful for kick-starting a new repository. And then there's also the CircumSpect static analyzer. And this is another thing in CIRCOM, the debugging and error messages leave a little bit to be desired. So having a tool like CircumSpect to analyze your code, point out areas where perhaps you're misconstraining something or you're just not correctly writing code is very valuable. So again, CircumSpect and Shield CLI, very important. And then finally, implementations. We've done a couple of videos and we've got stuff on there. So I'm not really going to go into it, but the actual specifics of using CIRCOM. So now that we've kind of gone through all of what that is, again, I think there's like one more minute, so I'll be quick. But we built our original version of BattleZip's as purely a privacy preservation tool. And this is mostly what we've been speaking to you about today, CIRCOM. So this essentially allowed us to prove an adversarial interaction between two parties where they could still trust each other without revealing all this information. So it was a great proof of concept for us to demonstrate private information on a public blockchain, but it fell short in a lot of ways. The scalability is pretty trashed, to be honest, and the intermediate state. So you're still hiding the ship positions, but hits and misses all the different turns in a game. All that's public. So moving on, what we're now working on with the assistance of the Ethereum Foundation through the grant is BattleZip's V2. And this is a little more exciting a novel, we think. Essentially, we want to demonstrate using battleships, the generation of state in a state channel, off chain. And then we summarize the entire state channel in a single transaction using zero knowledge. And what this allows us to do is produce these interesting proofs. So you get this almost immutable or indivisible object, a battleship game, a valid battleship game occurred between Alice and Bob, where Alice won and Bob lost. We'll talk about that in a second, but essentially this benefits both privacy in that you have the intermediate state shield and scalability in that you're batching all these transactions. And we intend to demonstrate how that can be used to drive qualitative insights without revealing a ton of personal information using ELO scores. So I think we'll just skip to the next slide, because it's kind of the same thing. Again, BattleZip's and Zip's is a kind of data structure, is basically state channel summary, where we're rolling up all of the state that we generate in a femoral layer two. We collapse it back on the layer one as soon as the state generation is done. And we already talked about the battleship proof, but there are a couple of more real-world examples that are exciting to us, take proof of a valid delivery. There's a bunch of different parts that go into it. Perhaps there's IoT, temperature controls, or perhaps there's an inertial sensor on something that's fragile and can't be moving in transit, chain of custody. Whatever you decide is necessary for your supply chain, you can then package that into a single proof of delivery. And the consequence of that is that the participants in this, say the delivery drivers who have no interest in being doxxed on chain, don't have to be doxxed on chain. You can start to involve them in these economies without them being exposed to all these negative externalities that Web 3 currently exposes us to. And again, just another example, which is a little less novel. Obviously, there's a snapshot, which is somewhat centralized. But essentially, we can take this entire voting process off chain. I assume it probably looks a lot like Macy, too, actually, in premise. But instead of it occurring all of the state accumulating on chain, where in Molek style, it's all even public, we are accumulating the vote off chain and then rolling up a proof that a vote occurred on this proposal, where 65% of stakeholders approved it, or 65% of governors or whatever. So it creates these kind of indivisible proofs that can be used for various things. So, yeah, so if you guys have any, sure, yeah, really quick, any desire to be working on this and you're struggling to get started. We have, I think, in the Battleships resources, we have a link to our Discord. You can go in there and drop literally any question and we'll do our best to answer it. Yes, sir. And then, are there any questions? You maybe have time for like one or two. Okay, if not, another huge round of applause for Jack and Ian. Thank you.