 everyone to the Hyperledger Foundation Meetup. Today, we are live streaming. So hello to those of you who are in virtual access. So thank you for joining us both in virtual as well as in person. Can everyone hear me okay? All right, if I need to be louder, I will. My name is Daniela Barbosa. I am the executive director of the Hyperledger Foundation. I also serve as general manager across the Linux Foundation for blockchain and identity projects as well. Today in our Meetup, we're really going to be focusing on Hyperledger, Ethereum and some future of enterprise blockchain. Going to take a couple of seconds to introduce for those of you who might not be super familiar with Hyperledger and what the Hyperledger Foundation is. And also, I'll talk to you a bit about how Hyperledger has been working in the Ethereum ecosystem since very early on in our history. This is a Hyperledger Meetup. I want to thank the Edge and Node House of Web3 folks for hosting us today in this beautiful space. It's been wonderful partnering with them for this event and other events that we'll be doing here at this location. All Hyperledger meetings, Meetups, whether you're in person or virtual, we do have all our welcome here and we have a policy to make sure that we're safe and welcoming for everybody in the community. And if you see something, you should say something to any of the staff members. Staff members, please raise your hand. We got Hart, Montgomery and David Boswell over there as well as myself. But hopefully we won't have to worry about that. So all are welcome and we're really looking for a place where it's inclusive. Once again, I want to thank the Edge and Node folks. George, fantastic work as usual. Thank you for hosting us and thank you for helping us get this all set. Today's agenda is jam packed. We got some great speakers. So I'm not going to spend a lot of time talking because the people that make Hyperledger what it is is our community members and you're going to get to meet some of them today. We're going to have Ryan Williams providing an EVM support for Hyperledger fabric. It's a fantastic new lab that I'm very excited to also see his presentation about. Antoine is going to talk about Hyperledger Bezu. He's one of the original maintainers on Bezu, a longtime contributor and maintainer in the Hyperledger community. So we always love to hear him talk. And then we have Serb deep talking about a tale of snark. So we're very interested in that presentation as well. And then to end up, we're going to have David Boswell as our senior director of community architecture talk about how you too can get involved in the community. We are an open community. We are looking and always interested in talking to people and how they can contribute, how they can participate and obviously how they can use the technology as well. And then we'll break out some networking. Oh, there you go. For those of you who don't know the Hyperledger foundation, you know, since 2015, we've been the place for enterprise blockchain technologies. And we started and I'll go through the history a little bit really with an approach of how enterprises were going to use distributed ledger technology. And there was a lot of interest for many companies early on in 2015. And in 2016, we actually formed the foundation with 23 founding member companies. And today we have hundreds of member companies and even thousands more externally who are supporting the foundation and the work that we do. Why is the Hyperledger important and what makes it so unique? We are part of the Linux foundation. So the Linux foundation is an umbrella foundation of open source projects. I would say some of the world's most important open source projects live in the Linux foundation, including the Linux kernel, for example. If you look at cloud computing, we have Kubernetes, which is part of cloud native computing. And we really do a range of different type of industry use cases and open source projects. For example, the Academy Film Academy, the Academy Film software has open source projects within the Linux foundation where the film companies came together and basically said, hey, we're not software developers. We want to basically build common software that we can all utilize to make great movies for people to see without having to compete one another at the software level. And that's a lot of the projects that come to the foundation are really companies, organizations, academic institutions who want to partner, who want to collaborate in an open development way and open governance of the code so that they can continue to have shared knowledge working with things. So then they can build their businesses and their government infrastructures on top of these technologies. And they know that long-term, they have a healthy community ecosystem, they have long-term support of their code bases. And we're very proud at Hyperledger to be doing that for blockchain. Today, we have hundreds of member companies that participate, but more importantly, we have thousands and thousands of contributors and maintainers and people who are creating documentation and people who are speaking like the ones you're gonna see today who are really part of our community, who are voice and who are contributing to the code bases as well. And we continue to grow. Just last year, we had 22 members join the foundation. We have large government organizations, for example, the central bank of France, for example, joined last year. Yep. So it's an open source project. So any company can participate. You can download the code. You can start contributing. You can start participating. You can use the code. It's all Apache 2.0 license. And you can build anything and multi-billion dollar business on top of the code. And it's okay. The member companies are those that join as members of the foundation. It's an annual membership fee. And they join to support the work that the foundation is doing to support the open source projects. You're welcome. Great question, though. So just a brief history of Hyperledger. As I mentioned, since 2015, 23 companies got together and decided that they were going to join and produce a product, which is called Hyperledger Fabric, which was the first project in the Hyperledger Foundation. And today, we have 13 different projects that are at different stages in graduated or incubated or graduated status. And we also have over 50 labs. And this is a place where innovation is happening and researchers or companies or individuals come and bring their code in order to build, once again, a collaborative community working on those code projects as well. And the evolution of the projects and the communities that we have at Hyperledger really, really follows how enterprises are using blockchain technology. We started with permission distributed ledgers in 2016. And many of these are still some of the most used DLTs in the world like Hyperledger Fabric. In 2017, we had projects that were focused on digital identity. And today we have Indie Aries and Anon Creds, which are really focused on decentralized identity use cases. And we had other projects, but today we really wanna focus on talking about why Hyperledger is here talking about Ethereum. A lot of people don't understand the history of Hyperledger and Ethereum and how far back has gone. And in the beginning, from the beginning, although many people still see Hyperledger as a permission private blockchain project, we really understood that there was no blockchain, not one blockchain to rule them all. There was gonna have to be a need and different use cases and different enterprises would require different types of blockchains as well. So if you think about the timeline that we looked at before, starting in 2017, we had our first EVM project, which was Hyperledger borough. Since then, that project has been end of life, but the EVM support came in with Hyperledger borough. And even in 2017, that EVM support was being looked at for Fabric and Sawtooth, which are the two permissioned DLTs. And we're gonna have Ryan talk about how we're doing EVM on Fabric now too as the next talk. So that was in 2017. In 2018, the Enterprise Ethereum Alliance, and this is the organization that maintains the standards on the Ethereum for the enterprises, they joined as a member, as an associate member of the Foundation, once again to support the work that we did. And we, the Hyperledger project, it was called at the time also joined the EEA. In 2019, we had a major contribution by consensus the company with the Y. They had a client called Pantheon and they contributed the whole Pantheon client to the Hyperledger Foundation in 2019 and we renamed it Hyperledger Bezu. People always ask me, what does Bezu mean? It means base in Japanese, the word base for Japanese. I also thought it sounded like kiss. So I thought in Portuguese you say Bezu and I thought it was a cute name. So they went with Bezu as well. So that was in 2019 and at the same year, the Ethereum Foundation joined the Hyperledger Foundation once again to support the work that the open source projects that were supporting Ethereum was doing here. And we worked very closely with the EF and I'll talk a bit about that soon. In 2021, we had a couple of projects come in as well and Hyperledger Firefly is one who is like a super node and it supports Mainnet and other EVMs including the Ethereum Mainnet and Quorum, Bezu and pretty much I think they're like 12 other both public layer ones as well as permission DLTs as well. In 2022, I'll talk about that in a second and then the EVM lab that Ryan is gonna talk about that just came in this year, which is pretty interesting to see that there is a lot of interest for the EVM in the permissioned blockchain space as well. In 2020, so last year in 2022, we also got awarded an Ethereum Foundation client for the Client Inceptive Program and it's because Hyperledger Bezu really serves two parts. It can be used as a Mainnet execution client and can also be used in as a permissioned blockchain network client. So when the merge happened, the Mainnet got split into consensus clients and execution clients. Today Bezu on average typically runs over 10% of the Ethereum Mainnet nodes on the Hyperledger Bezu code set. And this is why it's very important and why the Ethereum Foundation granted us a very nice grant to support Mainnet on the Ethereum client CIP program as well. And I just have one more slide, I think, oops, before Ryan but we have lots of use cases and Ryan, if you wanna get set up, then you can go. We have lots of use cases. You can go to our use case tracker or case study. Bezu specifically has had a lot of interest. We have large networks like LackChain which is funded by the Inter-American Bank down in Latin America and in the Caribbean. And that's a public permissioned blockchain. It's a really, really interesting work that they're doing on there. In Europe, EPC, which is the European blockchain infrastructure, they're building a public permissioned network for the whole of the European Union. They're building out some very interesting case studies and use cases as well across the European Union and both of those are based on Hyperledger Bezu. The Central Bank of Brazil just made a selection for doing their central bank digital currency with Bezu. And I can actually go on and on and on about support and if you wanna talk about use cases, you can catch me after the talk as well. All right, I'd like to introduce, as I said, I'm actually very excited about this presentation as well. Oops, no, I'm excited about it, it's one too good. Ryan Williams with the Blockchain Academy. Thank you, thank you. I'm more excited for Antoine as well. I'm Ryan Williams, CEO of the Blockchain Academy and I think here's my clicker. Well, welcome everybody. I'm here to talk about the Hyperledger or the Fabric EVM Library, which we just recently took over. I was end of life with Burrow. I wanna say about a year ago or actually a little less. And quick overview, we'll talk about what it is we're doing in this space, mostly on the education front, announcing the EVM lab on Fabric and we'll go into a little more detail on all of these things, particularly building the community. That's why I'm here. So we are the Blockchain Academy. We develop curriculum for various different protocols, but even more so on the non-technical side, right? Everybody's thinking about developers, developers, developers. Can't build anything without them, but we also need use cases. We need different companies in healthcare and real estate, et cetera. Everybody trying to get into this space and we need to marry those two, but both need to understand what Blockchain is. So we do education curriculum and we white label that content through UC Santa Barbara, Texas A&M Clemson, and associations, meetups. Anybody that wants the curriculum will white label it for them. They can silo it and basically know who's getting educated through their community. And we also, something we're very excited about is soulbound NFT credentials. So basically you achieve a credential and this is a big thing issue right now. People are copying pasty stuff, fed a GitHub and saying they can do slidity development and when in fact they can't, right? So if you can verify that you actually know how to do something, not just code commits, which is really important, but have you taken an exam? Do you really understand the architecture, governance, consensus mechanisms, et cetera? In order to be hired, right? That's the big problem right now. Who can develop? Who knows this stuff? So that's what we're trying to solve, but it's also then putting a marker on you, you get a NFT. Who hears of a heard of a soulbound token yet? Okay, so most are familiar. Basically it's an NFT you can no longer trade. It is tied to you, your soul. And this, you'll see this for vital records, your marriage, birth certificates, all these things will become soulbound tokens. That's the real magic and a lot of things that you can see beyond DeFi out there. So the EVM Labs currently being built is just taken over. We're looking to launch by the fall, big, big initiatives or interoperability and portability. And that's where EVM comes in because so many people can build with this in the space and all the tools are there. It just makes it a lot easier to then do a private application using hyperledger fabric. Okay. What is EVM? Who here is not, or should I say, here is familiar with EVM? We'd say, yeah, again, about half, maybe a little more. So Ethereum Virtual Machine is now being used by many, many public blockchains. And so we're trying to big it. Bezos uses the EVM as well. And I think, I don't know, too many other private blockchains that do it. So I applaud any efforts you've made in that space, Antoine, and we'll maybe hear a little more about that. But we're looking to bring this interoperability and portability to the fabric blockchain, private blockchain. And so why EVM? Because people can use these tools and we'll get more into what it exactly it is, but that is what we're after in launching and building this community and the library. So rich set of tools. So Solidity Programming Language is an object-oriented language, Java programmers, developers can quickly and easily pick up Solidity, which is really convenient for getting into the space. Remix and development, it's got panels, syntax, compilers, local time, and then mostly code errors. It shows the errors. And so you're kind of halfway there to seeing where you really are and what issues you might be encountering as you're launching your first smart contract. And if you don't have these tools, it is you'd be banging your head up against the wall. So the EVM brings a lot of tools to be able to deploy and get you much further up the learning curve than without it. Truffle Suite, also a great set of tools. So we're trying to bring all these tools with the EVM to Hyperledger Fabric and Web 3.js, et cetera. So there's just a lot of, you can't beat what the EVM's providing. I'm curious to see if whether or not anything else emerges. Happy to hear if there's any inklings out there. All right, just clicker to work. All right, so it's even on Truffle. So here we go, configuration is still up. It still shows, even though borough is end of life, you can still find the Hyperledger EVM still listed on the documentation there. So you can actually go and find it. It's Port 5000, as you can see. So it's still publicly out there. We're just looking to build the community to mature it a lot further. And so anybody that wants to build smart contracts on Hyperledger Fabric, please. And we'll get more into that and how you can get involved. All right, so here's a list of the architecture. You have company A and company B. They both have peers, but then you have an ordering peer in order to work together and have that operability. So it is having those smart contracts and private blockchains at company A and company B and being able to use Hyperledger Fabric and the EVM as a workflow to accomplish it. All right, okay. So I assume considering we're at the house of Web 3, most are familiar with DAPS, but that's the backend infrastructure of what makes blockchains work. But it's a full stack solution with ReactJS and other languages that can build the front end to work with the backend, but smart contracts all operate on the backend. And so that's where we are bringing the magic to it. And then those front end coders can bring the user design to make these things really adopted by the mainstream. So it's marrying those two things that we wanna try to accomplish. And with, particularly in the private blockchains. So you're seeing a lot of the EVMs deployed on public, but you're not seeing it on the private. And so that's exactly what we wanna bring. And so let's keep going here if I can get this thing to work. So here's a actual screenshot of the interoperability. And so if you actually take the courses, we run through a number of these different examples and there's about seven different examples within the course itself. And so you can actually get a look and a feel for it. And there's also emails and support we provide to help you figure out what, if any, hangups you're getting. So our big announcement is Hyperledger Fabric EVM Lab. I mean, this is, again, Bezos is the only one out there that I'm familiar with that's doing it privately. And we're just wanna bring it to fabric and we're just on the education front. So anybody that wants to learn how to deploy smart contracts, or we can help on the public side, but on the private chain with fabric and we're looking to develop that community. And so we hope you can join us. Anybody that wants to get involved, please get involved. The stuff is not done in a echo chamber. We need to talk to as many people that have use cases that are trying to build things in this space for enterprise. And we're not looking to reinvent anything. Bezos is kind of the tip of the spear, but they're doing on their blockchain, private blockchain, and we're bringing it to fabric, but it's a great community out there. And so the more we can bring this interoperability and portability with private blockchains, talking to each other when the use case needs it, we wanna be able to provide it. And so the community will bring, we're looking to upgrade the compatibility to fabric 2.4. And Jim Sullivan's leading the charge on this. He's actually Jim Chilipers and our CTO, by the way. And so bugs and defects is, and we're actually looking for documentation that people can really understand. That's a big problem, right? If you don't have clean documentation, it's not maintained, people are gonna go elsewhere. So we just, we need that support in order to have that on-ramp to developing smart contracts on fabric. And then finally, you know, we plan to work with Bezu and Solange. So love to talk to you further. And so the live demo, oh, you took the slide. So I was just gonna, so I won't be able to do the demo myself. I'm not a developer, but we did have a recording, but it set an integer, returned an integer. And the point is you can actually see a number of these videos in depth and have all the documentation, the step-throughs, through the free course that we're providing with and through Hyperledger Fabric. Oh, let's see, it's trying to play it, but it couldn't. Okay. All right, well, we have EVM training. So that's the point is if you wanna get involved, the easiest way to do so is actually, you know, jumping on and trying to launch your first smart contract on a private blockchain. And I don't know to the extent that Bezu has education for this, any streamlined way, but we're happy to hear more about that, but we're trying to develop on Fabric. And so we have a plenty of ways you can do that. Anybody that would like this, when this recording sent out, you can look forward on Twitter and various other places and there's a link where you can easily grab the course and start building smart contracts on EVM. But the most important thing is come up. If you have interest in joining the community, I beg you to do so because, again, you know, we're all doing many projects, things, but together we can build really cool stuff. So that is all I have. And Daniela, is she still around? Okay. No, all good. Well, thank you, everybody. Any questions for Ryan? That'd be a better question. The Fabric 3.0 release, which is supposed to come this summer, will have a modular consensus API that is decoupled from everything and it will have multiple modes of BFT consensus. So I'd say maybe two months. I'm not entirely sure. I think it depends on what the, there's an IBM research team out of Zurich that is doing a lot of the consensus stuff and it's probably whatever they decide to put in the package. Yep, that I would consider a smart BFT probably one of the likeliest ones. Any other questions? Okay, Daniela. I have a question and maybe you answered it in the beginning. In regards to enterprises who are very familiar with Fabric and who have been building, you know, some networks and solutions for many years with Fabric, why do you see them coming with interest for the EVM? Yes. Enterprise still wants private permission blockchains and there will always be a use case for that. And so I feel like, you know, IBM, in fact donated obviously Fabric to Linux and that's not gonna go away. And there's a lot of other companies that are starting to build in this space and enterprises where the money flows and it's one thing to be on the public side but I feel like, you know, we were talking to Oracle, we're talking to a number of Accenture's interested in seeing this happen. So I feel like the use case is there, it just needs to be given support, community support. Thank you, Ryan. All right. And you're sticking around for questions after the fact. All right. And he'll be around for questions. Next up, we're gonna have a deep dive. Is it a deep dive, Antoine, that we're gonna get on basis? All right. As I mentioned before, Antoine's been with our community for a long time. I'll let him introduce what his new role is. Well, it's not that new, he's been there for a long time. And take us through what he's got. All right. Thanks. Okay. Thank you everyone for being here. I hope to make the best use of us 20 minutes with you. So let's see, how do I use this thing? This is not a good sign. Oh, okay. Thanks. Hello. My name is Antoine Toulme. I am from France. I work at Splunk. People asked me during the happy hour earlier, what is Splunk? Feel free to look it up. It's a company with 8,000 employees worldwide. IPO in 2008. We do everything with data. We deal with logs. We deal with metrics. We are presenting most of 1,400 companies. I'm pretty proud to work there. And it's a pretty awesome place to be. And we work on all sorts of things. Now, part of my journey at Splunk was to actually lead the blockchain team there, where I worked with them on how to use data and how to bring insights to blockchain users so they could understand how to leverage mainnet for their own use cases or private use cases. And we worked with many, many customers across the enterprise sphere, but also public mainnet startups as they try to understand how to leverage all the data that the blockchain gives you. Thank you. So I'm really happy you're all here. So we can all celebrate together the anniversary of the workshop that I gave a year ago. So if you like French accents and you have four hours, you can watch this on YouTube. And you can just stop right here, go get a beer. Don't listen to me for 20 minutes. You can just get this. It's a very expanded form. You can probably build a certification course out of it. Feel free. Go ahead. It's all open. And it deals with a bunch of things, right? And I'm going to give you a very, like a glimpse of it, right? It's not going to be the full four-hour session in 20 minutes. But I was trying in those four hours to give people a sense of how they could use Bezu as a user, what it does, how it's coming together, where it's coming from, kind of an architecture standpoint, why it exists. And then we had about two hours actually went into the code. And I modified Bezu in front of people, showed them how they could change it for their own use cases. And I've learned since actually you shouldn't do that. But you can try. It's fun, right? So we changed the EVM, actually. We add EVM upcodes. We play with it. We change the way the blockchain is able to take this new upcode so that it doesn't break, stuff like that. So feel free. It's on YouTube. It's available. And I'm sure you can learn some French very easily using this function. Thank you. OK, so we're going to talk about Ethereum because Bezu is all about Ethereum, right? So when I was a consensus in the best life before all this work at Splunk, we started working on Ethereum and the mantra back then was we want to build an enterprise Java client for maintenance, right? So Ethereum for people who might not know, I mean not that many here, second largest crypto by market cap, started in 2014, many different clients, which is a very different move from Bitcoin, where Bitcoin you have just one corp team and one client, right? And instead of a single application, the whole spiel of Ethereum back then is that you can run many different things on top of it using the EVM. You just got a little bit of a deep dive into that. It's very helpful for me as context. And then the enterprise come in as in existing businesses. So we're not looking here for the spooky enterprise, it's more like the actual your bank, your government, everybody's trying to get something out of this new technology. Why not? It's helpful. It goes faster than doing this paper. So we wanted, and this was the goal of Bezu coming out, is that we wanted to be able to support the enterprise with a well-supported client, with different approach to deployments and that had the security mindset that was maybe different from what you would see from kind of the GIF client, for example, which might be a bit more specialized in mainnet, but does not care for things like FIPS 140 or stuff like that. So the enterprise different alliance is all about that. And the first attempt was Corm, who here knows about Corm. Okay, you don't, I don't count you. Okay. I mean, you know about this more than I do. So JP Morgan Chase one time decided that he wanted to invest into Ethereum, but they were going to do it their way. They were going to do it so that he would be able to do this with the bank. So for everybody here who doesn't want to be a developer, let me explain this very simply. They wanted to make sure that the data would not leave the bank. So you would be getting the hash of the transaction, but you would never actually see the data between each other. Pretty cool concept, and they actually implemented it, and it took fire, right? So they built this on top of a fork of GIF. They got massive success out of it. I think they got a great ROI for the number of hours they spent on it. And they kind of built an enclave on the side of the client that was actually going to store all the information that was very sensitive, right? But it's a fork of GIF, it's GPL. It's dirty IP. We cannot build on top of this. You cannot build, like you mentioned at the beginning of the talk, you cannot build a multi-billion dollar business on top of a fork of something that's GPL license. This is very dangerous. So therefore came this contribution from consensus to 2019 under the name of Pantheon, which became this database mainly calling for Ethereum that supports enterprise requirements. And this is the end of our presentation. Next slide. Then we have the Hyperledger Greenhouse, right? So those projects are coming together and they are all providing all the information. Basically it's just one facet of what you can get. So don't stop here when you're home and you've watched my four hours YouTube presentation, you may also have free time to go and check out all those projects which all do really cool stuff. So let's not talk about how these clients is coming together at a high level, right? I'm going to talk at a high level. So we're not going to talk about the consensus algorithms too much. I'm sorry about that. And hopefully I'm going to appeal to people here business minded, but maybe not. We'll see, we'll try, right? So let's go about the requirements. You wanna build an Ethereum client. It's got a few things that it needs to do really, really well, right? So first off, a client is not a client client. It's a server, right? It's going to internet, it's going to other things. It's actually going out, right? It's a peer to peer server. It's connecting all their clients, but also need to connect back to you. So you're going to need to expose this stuff to the internet so it can get to you, right? It runs as a single process because you really want to make sure that this stuff is running properly, right? And it's independent. Now, this is the crux of all the requirements about blockchain. You don't trust anybody, right? You don't want to trust anyone. You want to recalculate everything you get. You're not trusting anything that's coming through the wire. So you can perform all these changes. You can submit transactions for yourself. You don't need someone else to submit a collection for you. And you can interrogate the change for any data that may have happened at any point in time in the past. That leads you to a complex software stack. Now, this little diagram here shows you all supports which are opened on the basic client when you play. So for example, on the left, we have the Dev peer-to-peer port 30303 which is a TCP port used to connect to all the other clients over peer-to-peer. So you would connect to GIF using this, right? You would connect to parity back then using this. On the right, you have the RPC port. You have 8545, HTTP, 8546, WebSocket. At the bottom, you have common ports which are a bit more exotic. One is Tratham, which is 8008 if you want to do mining, which is no longer a thing that much. And then you have GIF stats and you can connect to an GIF stat server that's outgoing on, right? And GIF stats is a WebSocket connection. So you can actually report all sorts of things about you. So that's already for a 90% that's a nightmare, right? Now I have all those things to think about. And if you notice, those permissions would not be applied uniformly between the RPC layer, for example, which might be only open to your local network because you can actually study collections over there. And this, which needs to be wide open to the world if you want to do mainnet or to your internal network if you're going to do a blockchain that's private. And also to add to your complexity, now you're having to deal with data. So now you have a database, but not just one database, actually multiple database because you're going to store multiple different things which are going to come together and create the actual reality of your blockchain. So in the blockchain, you're going to have specifically for Ethereum, all sorts of different. For this one, you're going to have all the accounts, all your transactions, all the receipts of the execution of those transactions, and you're going to have all for all in every account a storage, key value pair of everything that you store in those accounts. So now you're storing all this information and by default we use ROXDB for that, which is just going to be a file-based database. Continue on the complexity side, you're getting collections now. Those collections are coming to you and they can be either local or remote depending on who's submitting them. Maybe they're being passed on through a gossip network, and you're going to have to apply some rules here to actually order them properly according to the rules of your blockchain. So this has one more requirement there. And on top of that, it requires configuration needs to be completely independent. So when you boot up, basically for the first time, it's like you boot up your PC, it's going to look for the CDISC, it's going to look for the BIOS. The first thing in your BIOS, what it says is that there's memory address where you can start looking for other things and eventually everything bootstraps. Same here, you have a Genesis block, it's block zero. That block has a hash. Any block following that block is going to be valid. Anything else just cannot accept it, right? So you actually create a hierarchy that you're going to trust on the ground using this approach. You're going to also say it's great to have a bunch of blocks, but you're going to also buy by consensus rules. And so you have a consensus engine definition as part of your Genesis. And then finally you have a boot node. So you know who to connect to, to kind of start to phone home and get a bunch of peers that you can work with. Okay. To make that a bit deeper. So when you connect to other nodes and you want to talk to them, you're going to have to do this in a way that is independent on any client of Ethereum. So when GEF started doing this, they started doing a UDP-based system where you would connect over to the internet and do lossy connections, UDP is lossy. You can just lose those packets. People might not respond to you. And constantly bombard all the other peers you can find on the network to create a web of them that you can work with, right? So you start with one, responds in about eight, you know you interact eight and then so on and so forth until you get to 256. Then you keep asking for more information just in case. And you store all the information into KMDA buckets which are going to allow you to filter them so you're not being attacked by one guy who just keeps telling you what's going on, right? Hey, that's actually pretty complicated and kind of hard to explain. So it said what we did is just use DNS now and you just connect to something and it gives you a bunch of information and you're good. So I'm sorry I wasted your time. Okay. So you can also do static peering and bypass all this crap and just put the e-nodes right there in your config. But so of course kind of fun about this e-node is that it starts with e-node colon slash slash and then you have the actual public key of that node right here and there. So when you connect to it, you can connect to it and you can encrypt your message using the pub key to tell them that you know who they are and that you have an idea how do you want to connect to them? And if someone is trying to spoof them then it won't work because they don't have the private key. So just a thing if I am right that happens. Okay, let's go. So you're a business network client. Whenever you do this and you've identified a bunch of peers now you're going to connect to them. You're going to say hello and you're going to say what you speak, right? So there are a number of sub languages you can talk to the biggest one of course if but you could also talk whisper which used to be a big thing about secret communication or IDFT also requires certain messages to be sent on a different sub protocol. So you can do that and that allows you to connect to peers and negotiate the connection with them and make sure they speak the same language as you. Next one. Which brings us to the big wheel of life of a BSU client which is a constant hamster wheel of going between the moment you start the moment you get new blocks from your peers eventually you think you reached the top you're not sure, right? You've got the latest block but you're not sure. Then you feel like maybe you can mint new blocks because you're at the top. So maybe your block will be accepted when you were to mint one and eventually you participate in propagating blocks that you see if you're cleaning yours and you go back to, oh gosh, I'm behind. So you're constantly having this thing and you never really know if you're up to speed or not, right? It may be that your network's partition only three nodes are talking to you everybody else is moving faster. So business part of consensus is actually an old Splunk dashboard. It's kind of cool. You should buy Splunk. And here you have all sorts of ways to see consensus consortium health. We have multiple clients that are working together. Here you can see also how those consortiums could be using click IDFT proof of work but really why would you? And now proof of stake after the marriage, right? So the BSU client has this ability to really manage all those consortiums. And this is kind of an illustration of the consortium coming together where some organizations might be able to also report some metrics and show you how they're doing health laws. Okay. All right, finally, if you have an RPC server you can interrogate the chain. You can do a lot of things. You can understand what's going on. And to do that, you're going to use and bombard your clients with a bunch of queries. Actually, most of the time when you do that you're going to take it down. It's actually that bad, right? And so you're going to use the JSON RPC server for that. Here's at the top a very simple query where you say I want to see the Web3 client version and you'll hear all the ways you can go about this. Maybe I'll save you some time today, next one. So in recap, if you were to look at BSU and trying to do an architecture of this it looked like it's a monster. It's extremely difficult to manage and in general it's a bad idea, but let's go. It's a database, it's a message queue because it's doing all sorts of transaction pulling, submitting transactions over time. It's an API, you can ask it for data about your stuff about your blocks, about your transactions about anything that happens and it's a peer-to-peer network client. So this is BSU in a really small nutshell in five minutes. Okay, so one more thing and then talk about the EVM did you notice? It's because it's everywhere and every step of every participation of everything of those things. When you call the API, for example, to get a block or to get some information from an EVM contract actually running the EVM under the hoop. When you submit a transaction it's being very dated using the EVM. When you want to update to what states because you have a new block and you want to change the database you're running the EVM. All this happens all over the place. So it's very intertwined all over the place. Okay, configuring Hyperledger BSU, let's go. So maybe I got you a little curious you're going to go home much far as of this then look at all the Hyperledger projects and now you have free time you want to learn about BSU. So how would you run BSU? First, the configuration stop notch at the bottom here you have the CLI syntax just take a snap of it, it's really great but pretty much what's happening is they thought about this very thoughtfully and you have a way to have a command line arguments which can be replaced by environment variables which can be replaced by a config file, right? So in the order of priority where command line first environment variables and then your config file allows you to do all sorts of things. Next, thank you. So first options is if you don't have time it's 2 a.m because you watched my thing it's really late. You can just do dash dash network equals dev it's going to run it on your local host and it's just going to do a little node for itself as it's on that work, right? You can give it data is a different folder. So if you were to run it twice and you want to start again from clean slate you can do that. There are some peer to peer options here local host by default, 30303 and then you can also do discovery like I mentioned you can enable that by default it's not and then you can set the boot nodes you want. So by default, if you're to try to create that base node it wouldn't work because we don't enable that by default for security reasons. So you're going to have to add a few additional flags and I have to say RPC HTTP enabled and then you can use the RPC HTTP API to allow more things, right? So by default we will only allow if net web three if you want to do things like deleting blocks or playing with things or doing truffle development like this gentleman was showing you may need a slew of other options and to do that there's a great documentation here which is the same across I think GIF and basically. We have hidden flags. Now I'm giving you a secret tip here please don't mention it to anyone but you can do a dash dash X and then you get a lot more. So we have a number of things that you can tweak that helps you when you're trying to get faster at syncing or connect to more peers than you should be or getting more transactions that you should be doing all these things possible. Okay, so how do you get to install this thing? We go to GitHub, download the release, easy. You're on Mac, brew install basic, done. You want Docker, Docker pool, hyperledger, such things. Easy enough, right? From source, relative assemble. It works with x86 with net libraries and I think M1 support has landed now and it's the old slide, sorry. More options just for fun. I mentioned that you have a Genesis block. You can do a different JSON file for your Genesis block. You can do all sorts of things around RPC security if you just want to enable that. So your neighbor can find any good access here. Here's how you do it. You can enable metrics. That's a thing that's dear to my heart, I like it. So you can do metrics enabled. It will allow you to open up from a few standpoints. You can scrape for metrics and you can also do all sorts of things with Lightning. Okay, contributing to hyperledger basic. So this was just a spiel to get you to actually become Java developers and hopefully at this point to resign to this option. So you can get all the prerequisites here in order to do anything with the base you can have to install Java. You will take not that long. Git, Docker, the compose your favorite ID and you'll need the basis sources and probably Chrome Dev Quickstart so you can build a bunch of consortiums on your machine. And by default, when you start using BASU you can do spotless supply and checks which are just very simple things you can run against your code base to make sure that everything is up just enough and that you're not going to have an inter-issues. This catches like 99% of Java common mispractices as behind this. And then the hyperledger base layout itself is a Gradle project. If you're not familiar, Gradle is one of those built tools that's kind of become very re-critice with Java. It contains both the sources and the distribution logic. So it contains all the way to the Docker file so no other repo it needed. And we even centralized all the versions of all the dependencies in one file. So if you're in security minded, you can go read that and you'll know exactly if you have CVS to worry about on that. So you wanna install it, you wanna run it, Gradle W assemble. It's very easy. The repository itself is made of modules and so you're gonna need to see different modules that do different things. We code the domain codes and their source main Java. This is a Gradle thing. You have tests, you have integration test under source integration test Java. And if you're ever interested in understanding how we test it against standard reference test, we have other things like acceptance test and reference test to test them against EF test, right? The EFAM foundation has a set of things that you can use to check that your EVM is up to now. Okay, so if you dive into the repo you'll see that there are a number of interesting things there and there are some modules related to EFAM but we also just can feel free to peruse any of the things in there, right? So we have an enclave, we have crypto code you can use to do any sort of crypto for your own projects. We have anything related to data types that is really custom made so you can do math for EVM, for example with such two bytes, words, things like that if you're into that. We have the EVM itself which we now ship as a Java that you can just download, use for any projects you may want and we have anything around metrics or how you can do NAT network, network traversals thing like that. So there's, I think it is in there that are awaiting you to be used for any other use case you may think about. Okay, so there's a common bribe with Bezu is that there's no dependency injection framework non whatsoever, which means that it's actually it's very easy to see how the Java code is made it's just spaghetti all the way, right? So there's a lot of moving pieces it's using the builder pattern and you're going to find yourself if you're like me just clicking around in a code base aimlessly for hours so you can find those dependencies of your pieces of software. So if you ever feel like it go and scroll through Bezu controller and Bezu controller builder and you'll see that all the domain objects which are part of an Ethereum client are all here which is kind of cool so you can actually understand them and for example, you'll see that we end up injecting really passing around objects which are useful such as a fork ID so know which fork you own so we know which version of the EVM to use which version of the network consensus to use for example, based on the block number we pass that around all over the place for example and that's it, any questions? Yes, I'll tell you, no idea to deploy smart contracts is a different thing, right? So to actually run it against mainnet and deploy using them I think you want to go with Daniela's answer there which is about 10% of the nodes of mainnet are actually using Bezu apparently for hosting so that's probably going to be the number we can go with in terms of transactions Yeah, yes, I've never seen an enterprise use both of stake yet, right? So it's possible, but the problem is what's the value of your stake? So for example, Hedera had done that but they've done that with actual cache and they had people, you know, caching like actual Hedera tokens for their blockchain so I have not seen that have you seen any private use case? No, it's private use case, not yet, right? That's a thing, I have to mention it, it's possible I think we did already. So actually it's even more than that so there's IBFT, IBFT2 and now we have QBFT which is a slightly different version that works well with Quorum as a way to kind of make sure that everything works well with the original GIF fork. I really glided over this but the consensus algorithms are pluggable so it's really possible for you to also come up and say I want to do something else I mean I've been itching for 50 hours of free time so I can do raft but I never got to that so I don't think that's possible. Thank you. Sure. You have a large ride. I'm going to move this over here so that you want to stay over here. Excellent, so thank you Antoine. Like you, like he said please watch the four hours and his beautiful French English accent. Merci beaucoup Antoine. When I first saw this come through my inbox I read it as a tale of two snarks and I was like, oh, that's interesting what's that topic going to be about? I'd like to introduce Sarah Deep who is with Visa. Visa has been a hyperledger foundation member since 2018 and there's different groups within Visa that interact with the foundation in multiple ways but we're very excited about his presentation today so Sarni, thank you. Okay, maybe one slide back. Right, so these things doesn't seem to work. I just want to introduce myself. I'm Shubhurti. I'm a research scientist at Visa Research so this talk will be a little technical but I'll try to keep it at a high level. So my talk will be about the tale of snarks. So maybe people have heard about what is a snark? So zero knowledge proofs, right? But with some additional properties. So we'll try to understand what is a snark? How is it being deployed in and how is it being deployed to do private transactions on public blockchain? And finally I'll conclude the talk with some of the efforts, research efforts that we are doing at Visa Research along this line. Okay, so well, this is certainly not an imaginary animal from the poem of Louis Carroll. So what is a snark? So a snark is a way to prove statements. So it's a succinct proof that tells you that a certain statement is true without revealing the secrets. For example, I might claim that I know a message M such that a SHA-256 of the message is equals to zero. So this is a cryptographic hash function. And okay, so what does snark stand for? A succinct non-interactive argument of knowledge. So what a snark lets you do is that, so you have the message M that you don't want to give out publicly. So it's your secret, but you want to prove that a hash of this message is zero. So a snark lets you output a proof, which is very short. So it's succinct and it's very easy to verify. So for example, let's consider the trivial proof. I have the message M, so I give out the proof and it's a sound proof, but the problem is that if the message is large, say I have a video file, so it's like one gigabytes, the trivial proof is neither succinct because I have to download one gigabytes of data and the verifier has to run the SHA-256 of the message, hash it and then check whether it's equals to zero. So it's a large computation. So for snarks, what it lets you do is that the proof will be kilobytes long, so it's not gigabyte and the verifier runtime will be few milliseconds, okay? So an additional property that you'd want from a snark is zero knowledge. Let's call it zksnark. That basically says the proof does not reveal anything about your message M. Right, so what are the applications of zksnark? So it has a lot of applications and it's an interdisciplinary tool, so it has a lot of applications in computing, but ever since like blockchain kicked, like so zksnark has a lot of compelling applications in blockchain. So for example, I'm gonna list a few. The first is doing private transactions on a public blockchain. Like there are apps like Tornado Cash, ZCash, Iron Fish that basically lets you transfer asset from one person to another, but like to an outsider, they can verify that the transaction is valid, but they will not know what is the content of the transaction, how much money I transferred, what's from what wallet to what wallet. So everything remains private, but you get the guarantee that the transaction was valid. And you also can use zksnark to launch decentralized apps on blockchain like this company Elio is doing. So basically it's like a way to run smart contracts, such that the code of your smart contract is hidden and everybody can basically get convinced that what comes out of the application is correct, but the code of the application, that is the business logic is hidden. So another company application is zero knowledge in compliance. So for example, an exchange might want to prove that it's solvent, meaning that it wants to prove that it has more assets than obligations, but it does not want to reveal assets to a third party. So I don't wanna give up my financial information. So naturally zero knowledge proves is a way to give a proof of solvency. Another application that might sound like a science fiction for now, but hopefully it's not too far in the future. It's like combination of zero knowledge proves and blockchains. And hopefully in the future, we should be able to prove that we paid our taxes correctly to the tax authority in zero knowledge because we don't want to give out our financial information to the tax authority. And finally, I want to stress on scalability. You might have heard of ZK rollups. So instead of verifying all the transactions on chain, so I'm gonna batch the transactions and they finally give you a succinct proof that you can verify on chain. So the verifiers will basically take this small proof. Note that here I crucially rely on the fact that the proof is succinct. So it does not take up storage on the blockchain and the verifiers will be able to verify this proof very fast, okay? So good. Okay, so now that we are convinced why this creature is important in the blockchain space, let's try to dig into the details a little bit. So for this, I want to go through something, like a bit of cryptographic background. So let's try to understand what's an argument system. So let's fix some circuit C that we want to prove. So this circuit takes as input an X. So think of X coming from some underlying finite field. So for people who are not familiar with finite field, just think of integers, zero, one, dot, dot, dot to P minus one for some prime P where you can do addition and multiplication, module of the prime, okay? Some mathematical structure. So the statement comes from F to the N and there is a secret witness. So think of the witness as your message M that I had in the first slide. And the statement says that I know that the SHA-256 of this message is zero, okay? Right, so this is a protocol between two parties, the prover and the verifier. The prover has the statement and the secret witness and the verifier holds the statement. And the goal of the prover would be to convince the verifier that I know the message M such that SHA-256 of this message is zero, but I don't want to give out the message. So how do we do this? The idea is that we'll communicate across rounds. So potentially the verifier will send challenges and the prover will respond. And at the end of the day, the verifier will either accept the transcript of the interaction or reject, okay? But you might have already raised your eyebrows by now because it's an interactive process. In blockchain, we don't want it to be interactive because I have one proof and there are like thousands of verifiers and everyone, and should be publicly verifiable and it should be non-interactive because you have to, if I have to communicate with everyone, then it's like takes forever, right? But notice that interactive proofs are also useful. So for the application, like when you want to prove that you have like zero knowledge taxes, for example, the tax authority is a single entity. So you can communicate back and forth, but in blockchain, you want non-interactive proof systems. That's what, so now we'll understand what's a non-interactive pre-processing argument system. So we are slowly going to version arcs, okay? So we have the setup as before. We have the circuit, the statement and the witness. Now we have a setup phase where there is this algorithm S that takes the circuit, like think of the circuit as the description of our hash function and it spits out some public parameters. sp is public parameter for the prover and sv is the public parameter of the verifier. And now the prover sends a one-shot message to the verifier. That's why it's non-interactive and the verifier either accepts or rejects. And note that the prover additionally takes sp and the verifier takes sv. And what are the requirements from this argument system? First is completeness. If I have a valid witness, so if I indeed know a message such that it hashes to zero, I should be able to convince a verifier if I have the witness by giving out a proof for this. Second, the property that I need is knowledge soundness which says that if the verifier accepts my proof, then I indeed know the message that hashes. So I cannot cheat. That basically another way to say is that if the prover, if any malicious prover do not know the witness, the verifier will never accept such a proof. In fact, it will, well, technically we say that it will accept, but only with negligible probability. But for now we can imagine that it will never accept such a false proof if I do not know a witness. And optionally, we need the zero knowledge property which says that this transcript, SPSVX and the proof by reveals nothing about W. Good. So formally a succinct pre-processing argument system is this tuple of algorithms. Yeah. And the main property that I want to stress here is succinctness. Note that the proof that comes out, it should be short. So in particular, the length of the proof is logarithm in the size of the circuit. So the circuit can be gigantic. It can have millions of gates, but the size of the proof is tiny, tiny. It's just log. So if it's like a million gates, the size of the proof is like 20 bytes, something like that. And you can ignore the lambda for now. It's a security parameter. It's a technical reason why it's there. And the verification should also be fast. Well, the verifier additionally, the running time depends on the size of the statement because if I want to verify something I should at least read it. So, but the important part is that the verification time is also quite small. It's logarithm in the size of the circuit. So in effect, what's happening here is that, well, the verifier, why we need this pre-processing step? The verifier does not have the time to even read the entire circuit. So how can it verify? So it turns out that this SP and SV, these are basically short summary of the circuit. So the verifier takes this SV, right? So we can think of it as like it takes a circuit, squeezes it into a very short digest of the circuit that lets you verify in very, very, very short time, okay? Which otherwise was impossible because you have to at least read the statement and the circuit to verify it. But that's the magic which happens here because of the pre-processing, right? So what's the schnark now? Schnark is an argument system that's pre-processing based, that's complete, knowledge sound, and succinct. And additionally, if you want zero knowledge property, that's a zekeshnark, okay? So that's what a zekeshnark is. So let me go over the trivial argument system again, which I said that the prover just sends the witness, W. So the prover just sends the message to the verifier. Why this is not a schnark? This is because one, I might want to keep my message secret, so it does not satisfy the zero knowledge property. Second, it might be, the message might be too long. As I said, the message can be one gigabytes long, but the proof should be short. So it does not satisfy succinctness. And third, the verifier has to run a long time because it needs to read the entire circuit and then check. So in our case, it needs to hash all the things and then check whether it hashes to zero, which is too expensive. Advance one more slide. Right, so for this proof system, if my witness, think of the witness W as bits, right? And so the size of the proof in the verifier runtime is just log n, which is remarkable. So if n is order of the order of two to the power 30, right? So the proof is just 30 bytes. And the verifier running time is also of that order. So it's, it will be of the order of few milliseconds. So which is amazing, right? So for the interest of time, I will skip this slide. So this basically tells you, so as I said, there will be a set of phase that basically takes a circuit and squeezes it into a small summary. But the point is that, what is the trust that we need from this setup? It seems that someone trusted should be there and who does this, who can summarize this circuit, but turns out that, well, there are different level of, there are different trade-offs that one could go for, but I'm not gonna, in the interest of time, I'm not gonna do this, but after the talk, if you're interested, ask me. So I'm gonna skip this slide. Good, but I'm gonna show some figures. So what are the most commonly used snarks that are used in the blockchain space now? The most familiar, the most used is GROT 16, which is due to Yen's GROT from 2016. The proof is of the order of 200 bytes. And the verifier run time is around three milliseconds. Just ignore the last column because I did not go through the slide last. There are plongs and Marlin, which is like two times GROT 16. The verifier run time is also again twice, but it has something beneficial, which improves over GROT 16 in terms of the setup. And now there are other systems like bullet proofs, starks, darks, so on, which gives you slightly longer proof and longer verification time, but it's more secure. In the sense the setup is less trusted, but for GROT 16 plong and Marlin, the setup needs to be trusted, okay? Of course, one can do a ceremony and generate the setup as it's done in most of the blockchains, but you have to run a multi-party computation protocol to do the ceremony, so I'm not going there. Good, and I'm kind of stressing on the last three because they are more secure, but at the expense of kind of inflating our proof sizes a bit more compared to GROT 16 or plong, okay? So these are the kind of, of course, this is a very partial list, but these are some of the most widely used snarks today. Good, and I want to stress something. Well, nothing, no one has a free lunch, okay? So what's the catch? Well, the proof sizes are very small. Verification run time is very small. So somewhere the circuit complexity should figure in. It turns out it's a prover. To generate the proof, I have to run this computation for a long time, which is okay for blockchain applications because I can do it off-chain, but then I can produce the proof on-chain and then the proof takes very short memory because it's succinct, and the verification run time, it takes very small time to verify and this is exactly what we need for blockchain applications, so we can leave with this. But there has been efforts also, like to trying to reduce it to, so the earlier snarks would be like crazy. It runs so in time, which is quadratic in the size of the circuit. So now we got it to linear in the size of the circuit. And recently there have been papers that allow the prover to even run in sub-linear time in the size of the circuit. So there are some research efforts going on in that direction, good. And finally a slide about how to implement snarks. So it's a snark software system. So you have your favorite domain-specific language, which for snarks it's like circum-zocrates, leo-zinc, chyranoir, and so on and so forth. You compile it into what is known as a snark-friendly format. So these are like all rank one constrained systems. Plonk CG is like Plonk with custom gates, but ignore this, these are like some sort of arithmetic circuits, okay? So arithmetic circuits are nothing but it encodes all polynomial time computation that we do. And finally, so we take our high-level programming language, compile it into a snark-friendly format and then basically run the snark backend prover to generate the proof. So the snark prover basically takes the statement and your witness and takes the pre-processed argument from the snark-friendly format and generates the proof. And as I said, the heavy computation is at the snark-prover end, okay? Good. Okay, so what we are doing at Visa Research. Okay, so as you have noted till now, most of the traditional zero-knowledge systems are considered two-party view. There is one prover, one verifier. Of course, there can be multiple verifiers, but when, for example, there is a transaction that posted in the blockchain, I know like the transaction, so I'm gonna prove. So the assumption is that I know the entire transaction details, so I can prove in zero-knowledge that the transaction was valid without giving away the transaction details. But often in applications, this is not true. Consider one application, like the money laundering application where, for example, Eve has to receive some ransom from colonial pipeline. And the banks would want to prove that Eve has received such a ransom from this guy. So this basically translates to the entire transaction graph that's out there. And there are certain patterns, like some loops, that kind of tell you whether they are fraudulent transactions or not. So basically, I have to find a path in this graph. But turns out nobody has the global view of the entire graph because different financial institutions have their own local view of transactions, right? Visa has their own local view, MasterCard has their own local view, and so on and so forth. So it's a collaboration between multiple financial giants that define the transaction graph. So it's a distributed data. So now how can you prove a secret, how can you prove properties of our distributed secrets? That's a hugely challenging job. Similarly for healthcare statistics, when different hospitals would want to prove, like generate some aggregate statistics about their data, but of course they don't want to give out the patient's data because you cannot. And but you still want to collaborate, right? So these are the settings where the data does not, is not held by one single party, but it's held by multiple institutions. And you'd still want to do zero knowledge proofs of a distributed data. Good. So it turns out there's a framework called Collaborative Zekeshnark. This is a paper by Dan Bonet and a student of his. So this is the traditional view where there is one prover and one verifier. And now we'd want to split this prover into multiple provers. Think of the different provers as like Visa, MasterCard and so on and so forth. Everyone has their own witness, W1, W2, W3. Think of the witness as the transaction graph, okay? And now I want to collaborate with, all the provers would want to collaborate with each other to generate a final proof that's publicly verifiable, okay? But the important thing is that note that this W vector, nobody possesses this W vector in his entirety. So everyone possesses a piece of it, okay? Oh, sorry. So all we are doing is now kind of, we're gonna split this proving algorithm. So there are now multiple provers to hold multiple witness or there should be a bracket around W1, but yeah, it's a typo. So what we are essentially doing in some sense is running a multi-party computation protocol among the provers. So we have multiple distrusting parties who have their own secret inputs, but I still want to compute some statistics about our data. So how do you do it turns out that multi-party computation is exactly gives you that handle. So on a bit technical level, take the prover circuit, that's your snark circuit and distribute it, run it under the hood of an MPC protocol. Good. But there is a problem with this approach is that, well, if this solution requires everybody to remain online at the same time, which is clearly not an realistic assumption in the internet, like nobody can be online at the same time, right? So basically, and also it depends on the computation, our computational resources, but somebody may have more resources, somebody may have less resources, I might have other commitments so I can drop out in the middle of the computation. So traditional MPC says that, well, it puts your hands up. I bought the computation and all the work that I've done till this phase goes to waste, right? So as I said, yeah. So also if you want to do very complicated applications, if you want to do zero knowledge proofs, like for example, proving correctness of machine learning algorithms on massive distributed data sets, it's a long winding computation because it's a deep neural network. So you cannot expect all the participants to be online throughout the entire computation process because it might take hours, even days, okay? So the question that we ask is that can we design collaborative zikation arcs where with dynamic participation? So I can join the protocol at any time I want, I can drop out. And is there a way to kind of take the computation from one stage to another stage and design such a protocol? So this is basically one of the main problems that we at Visa Research are working on. So I'm not gonna bore you with the details here, but basically believe me it can be done. So we call it fluid collaborative zikation arcs. So the term fluid because participants can be fluid. I mean, I can come into the protocol, join at any time, live at any time, okay? There are some technical restrictions of course, but majorly it can be done. Good. And I want to stress that this actually results in a weighted privacy preserving distributed computation system. Why weighted? Because it depends on the resource. If I have less resource, I will just participate in one stage dropout. If you have more resource, you can utilize it and stay in the computation for more time. So you can basically use this to get what we can call zikation arc as a service. It can be a paid service where there will be a client who delegates the computation to multiple servers. The servers can do their computation at their own will. So it's a voluntary network. So if I have enough resource and free resource, I can join the computation else not. And I can use this like a zikation arc as a service framework. So yeah, so there is a huge potential here. So with this, I would want to conclude the talk and I'm open for question. And I want to say that many of the slides are curtsy Dan Bonet who is a professor at Stanford. And if you want to learn more about snarks, this is a fantastic, fantastic area of research. Many exciting things are coming up. This is kind of like a power horse in the blockchain ecosystem. And it's also people who are like love math like me. Do definitely look up this course. It's a zero knowledge MOOC. That's given by many professors, Dan Bonet, Shafi Goldwasser from MIT, Justin Taylor, and many others. It's a fantastic resource. Do check it out if you're interested and open to questions. Yeah, got it, got it. It's a good question. Yeah, so if I theoretically want to give you the answer, it's possible. But of course, now you have to look into the efficiency consideration. Like these are like large language models which are to prove statements about these kind of things like integrity of the computation of LLMs. It's like the prover runtime would like take a toss because the circuit sizes are huge, right? But like, but for example, you can do something. Well, so there's something called recursive snark. So basically that basically allows you to prove that I know a proof of something. So for example, here I take a statement and a witness and give a proof, right? And now the thing is that I can take such a proof and produce another proof that I know a proof of this proof of the statement that the statement is true. So why am I telling this? Generally, the bottleneck of snark is that the prover runtime is slow. But with this recursive snark, what you can do is that you can make the proofs, a prover runtime, you can get the best of both worlds. The proofs are short and the prover runtime is also much less. So the catch is that, well, the catch is pretty technical. So I don't know how to explain this. So the thing is that you, okay. So you cannot prove this multiple time. So as I told, this is a two level recursion that I know a proof of a proof. So I can continue doing this. I know a proof of a proof of a proof and so on and so forth. But turns out that for most large language models, I need to do it for a polynomial number of steps. There's a large number of steps that depends on the depth of the circuit, okay? And the current recursive snark do not support it because of some technical reasons. But there are some computations where you can basically take such a large computation and kind of roll it down into a much short depth circuit. And for those you can do recursive snarks, but we are not like there for like all possible computations, especially those LLMs, but maybe at some point in the future. Yeah, but that's a good question. Okay, yeah, do look it up. It's fascinating as well. It's getting better, yeah. Yeah, so basically the main reason why we want snarks and not any general zero knowledge proof is because of the, as you said, the succinctness and the extremely fast running time to verify. Because we have like thousands of transactions per second. And we need to verify at a blazingly fast speed with general zero knowledge proof do not allow you to do, but snarks do allow you to do. And so the motivation of course, stems from there. But of course, now a lot of research is happening, how to even kind of optimize the snarks, how to, as I said, like how to even like reduce the bottleneck, the proof of running time and so on. And there has been like a flurry of papers now. I'm also part of some of them like trying to do. So yeah, I think basically the motivation is like fast on-chain verification, but I think we'll take a more holistic view of the problem and kind of attack it from that angle. Yeah, for this I guess I have to wait some more years to see. I mean, the rate of adoption of these technologies and the way that it's getting faster is, I would say it's like happening in an exponential speed. And it's really fascinating to see all the developments. So you never know, maybe at some point, as I said, like at some point, maybe two years down the line, you can actually prove integrity of creativity for computations using zero knowledge. So I think our imagination is the limit. Yeah. And thank you everyone for coming out tonight. I'm gonna be brief. I wanna make sure that you still have time to talk to the speakers and network with each other before we need to leave tonight, but I did wanna just say a few words. My name is David Boswell. I work with Danielle and Hart and Hyperledger. My role is to help people get involved in the community if you're interested in doing so. So anything you heard tonight about the EVM Lab, about Bezu, about DK Snarks, if you wanna get involved, we're an open-source community, which means that you're welcome. You're invited. Come on in and connect with the people here, connect with the people on the community all around the world. And I just wanted to say just a few minutes, how to do that. So again, if you wanna get involved, we welcome you to do some, sorry. There we go. And we want you, you know, an open-source community, if you have an open-source community and people don't get involved, that's not much of a community, right? So we exist because people have stepped up and created the tools that we talked about today and are doing all the things that are happening in here. And it wouldn't happen if people didn't show up. So we do want you to get involved. And Hyperledger is 100% open. Everything that we do, public accessible, you can show up. And I'm gonna show you really quickly how to do that. First off, if you've not been involved in the open-source community, I just wanted to say a few words about why you would do that. It's not necessarily obvious why you might wanna get involved. So just to say a few words about that. Oh, sorry. One is if you're building something, you can accelerate your work by working with others, right? It's one thing for you to be on your own at your house or in your own company working on something. But if you wanna go faster, there's a whole world, a literal world of people out there who might share your same interest. And you can work with them if you wanna collaborate in an open way. And you can learn a lot from people. You heard people today talking about their expertise. So if you wanna learn from others who really know this information and technology on a deep level, get involved in the community. That's a mentoring opportunity, a learning opportunity just to be here. Be at these meetings, be online, be in the calls. Take part in the community, you will learn a lot. I think I need to be pointing this in a very specific way. And then you can gain great experience that looks great on a resume. If you show up and contribute to an open source community, your GitHub profile is your resume, right? You can show, hey, I've got my code and this, you know, hyperledger fabric or hyperledger and whatever it may be. You can show that you have this knowledge and expertise and skill set. And that's very much be helpful for you if you're looking for opportunities in this space. And again, tap into a worldwide group. We're here in San Francisco today but we have community members all over the world and we have a huge number of organizations. This is just one glimpse of the community. These are the different organizations that are members in the community. It's really hard to see all the different logos in there but you can see it's over 100 different organizations. Some of the biggest organizations in the world, some small startups, kind of a range of different organizations that are in the community that you can interact with and network with by being a part of the community. And then again, individuals, we have, this is one of the meetups that we have all around the world but we have over 180 groups and 80 countries all around the world. So if you're interested in seeing what people are doing with this technology in Brazil or Africa or Europe or wherever it may be, again, you know, getting involved in the community will allow you to connect with those people who are all over the world and as part of hyperledger. So those are some of the reasons about why you might wanna get involved in the community. So how do you do that? If you've never been involved in an open source community before, it might not be very clear exactly what do I do, how, you know, what I'm not really sure what I'm supposed to do, what does that even mean to be involved in the community? One thing is just show up and listen, right? I mean, I call it here, feel free to learn, right? That just means go to an open call, go, you know, go on a mailing list, go on Discord and just listen to what people are doing. There's no need to necessarily do anything. You're just kind of seeing how the community operates. That's a really good first step. And then don't wait for an invitation. All the, you know, I'm happy to give you an invitation, but don't wait for one. If you wanna, if you're interested in Bezu, because Antoine talked about it, show up on a Bezu call, right? Nobody, you know, nobody's gonna say why you're here, they're happy to see you there. So don't, you don't need to wait for an invitation to do anything in the community. And then the lastly on this slide, Danielle referenced it earlier, but if you're concerned about what would it be like to be involved in open source community, read our code of conduct. We take it very seriously. We make sure that if you are involved in the community, you're gonna be a part of a professional, you know, safe space. So, you know, we have a code of conduct. We enforce it, we take it seriously. And if you're curious to see what it says, you know, it's online, take a look and, you know, read it and understand how we've seen, you know, set up the community. I'm not gonna go through this. We'll share the slides for everybody who registered. But, you know, if you're again interested in getting involved in the open source community, all sorts of resources online about how to do that. And then Antoine and some others referenced this, but we also, part of the role of the Hyperledger Foundation is to take the code that's being developed by people all around the world and then help people use that. So one of the ways we do that is provide training. We have a lot of resources online that you're welcome to take a look at. We have a lot of material that, you know, Antoine referenced the workshop he had done earlier. We have meetups that have just like this where we talk about things. All this material is recorded and available. If you're curious, go to our YouTube channel, go to our website, all that information is available. And then again, you don't need an invitation. It's all out there, but if you'd like an invitation, we would love to see you in the community. Hopefully this is the start of a conversation with you, you know, over time and we would love to see you, you know, at future calls, future meetups, you know, future activities. Yes, is there a question? This one, where are the links? I'll share the slides and you can click, these are all links that you can click and I'll share these. Yeah, so everybody who registered I'll sit in the link around. There we go, all right. And again, I'm not going to spend a lot of time on this because I want us to have time for the last, you know, 20, 30 minutes we have in the meetup. So I'm not going to go into this in a lot of detail, but just to share that we have a set of tools our community operates with a set of tools. Again, if you want to show up and start using them, you know, please do so. You don't need permission. All these are open, accessible. You don't need a permission to do anything on these tools, but we operate as a global community. Obviously not everything we do is obviously in person. So a lot of what we have to do is online. So we have a lot of online tools. We use Discord for chat. We have mailing lists. We have all sorts of different things. Again, you're welcome to start using them. And just to point out some of the resources, again, Antoine covered some of this earlier in his talks. I won't go over this, but we do have, if you're interested in specifically some of the things that got covered today, there's a lot of information about Bezu. We have a series Bezu as many projects in the community. They make it easy for people to get involved. If you were wanting to contribute, for example, there are what's called good first issues, which are easy places to get started. So take a look. The community members want you to, you know, show up and take a look at those and, you know, grab one and contribute to those. So see what's there. And again, this is your invitation and take a look at those. And then we also talked about one of the hyperlider labs. That's available. That's information that, you know, is on our website you can go and take a look at. Not only can you contribute to an existing lab, but if you're doing something here and you would like to collaborate with others, you can start your own lab too. So again, it's an open source community. What happens in that community is what you bring to it. So you can either contribute to something that's already happening or bring your own effort and then start collaborating with others on that. And that was it. I went quickly. Again, I wanted to have time for all of us to speak more and talk before we had to leave tonight. But if you have questions about getting involved in the community, please feel free to come to speak to me or Danielle or Hart. And if you have any questions about any of the speakers who spoke earlier, I think we're all still here. And I think we've got, what, 15, 20 more minutes or so? Great. So thank you again for coming tonight. Please feel free to stick around. And if you have questions for me or anybody else, let's talk over the next 20 minutes. It's cool. Well, thank you.