 first few waiting minutes from the recording before I publish it. YouTube, people don't have to listen to us chatting away. Hello everyone, you are in the correct place. If you wanted to see the Simba Chain webinar, we will be starting shortly. You are in the correct place. If you are waiting for the Simba Chain webinar, we will shortly be starting the webinar. We are just waiting for a couple of people to join us. So I'll give one more minute and hopefully we will get most people in. Okay, I guess we can start. Welcome everyone, this is our webinar series. And today we will hear a presentation from representatives of Simba Chain, a company that just recently joined Hyperledger. This webinar is being recorded. So if you miss it or if you want to share it with anybody else, please go to our webinar website and you will find it shortly after the presentation finishes. The slides will also be available after the presentation as speakers share them with us. Please remember this meeting is held under antitrust policy, which you can view by scanning the QR code in the bottom left side. The antitrust policy requests you to remember that you are here with potentially your competitors and you shouldn't be sharing any information that might be considered an IP. And finally, if you have any questions, please do use Q&A. Box in the dialogue. If you would like to chat with anybody, please use the chat window. Don't use the chat to ask questions. It's easier for everyone if we just use the Q&A session. If you'd like to speak up, please raise your hand and we will be able to unmute you. And with that, I will hand it over to Adam, Tom and Andrew for their presentation. Hi, thank you so much and thank you all. This is Anjan Roy and thank you for your attendance and your interest here in our webinar with the Hyperledger community. I'm going to go ahead and share my screen and bring up my presentation here and I will rely on my colleagues to confirm that you see the screen. Fabulous. Well, thank you so much and we're going to get right into it because we have quite a bit to cover and we also want to leave some time at the end for questions and still finish before the top of the next hour. We know that your time is valuable and you probably spend a lot of time on Zoom and your computers nowadays, given the state of the world. And so we appreciate you prioritizing this. We should also state that Simba Chain is very, very thrilled to be part of this community. You know, this is a fantastic community and I think it really fits in well with kind of our mission of democratizing and lowering the barriers to adoption for blockchain in a very successful and practical way and that really jives with the Hyperledger community's focus on practicality and like real world results. And so I think this is going to be, I think our kind of experience with blockchain and DLT technologies more generally will be hopefully very applicable and informative for all of you. So I'll start off, you know, we're going to talk about the plan is going to talk about just general blockchain challenges and approaches to those challenges based on some of the experience we've had. Tommy's going to talk about generally his take on web three-point applications, some big picture trends that we're seeing out there. And then Adam's going to speak to Simba Chain's approach to Hyperledger and especially this graph-based approach which is really key to our platform. And then finally Tommy and Adam are going to kick the tires and give you a demo of the Simba Chain platform, particularly our new enterprise release that just came out and Adam's going to speak then specifically and show you demonstrate the Hyperledger portion of the platform and example as well as how our graph-based approach elucidates that further and further extends our traditional approach. So taking a breath here and you just, you know, if we look at blockchain and I'm using blockchain and DLT technologies here interchangeably, I know I've noticed one thing just being part of the community that DLT is definitely more in favor as a terminology within Hyperledger. So these kind of multi-party systems so to speak, the ecosystem has many moving parts and they're subject to kind of hyper-specializations even within the community because if you think about blockchain, and you think about DLT, you're mixing in cryptography, you're mixing in consensus algorithms, decentralized databases, technologies that have in some cases been around but they were put together in a way that was very, very novel and each of those technologies themselves have lots of specializations and that's a challenge. Hyper-specialization is a challenge within the technology community and frankly within the broader economy at large and then when you've got multiple hyper-specializations interacting that make that kind of multiplies that challenge. You know, but on the other hand, being able to, you know, utilize and optimize and coordinate across these component parts, you know, is critical for success. So, you know, yes, you've got hyper-specializations, that presents a challenge but if you're going to get the real value out of it, you need to be able to bring these, you know, these component parts and these hyper-specializations and hyper-specialists together and that's where the real kind of, you know, return, you know, return on investment is and, you know, if you're implementing DLT technologies and then on top of that, you know, blockchain is complicated. You know, as we said, you know, you've got just a few things that a business needs to understand, you know, you've got libraries, you got wallets, course cryptography, the networks themselves, you know, there's so much focus on the network and then on top of that off-chaining of file systems, that's a very key part, you know, particularly if you're talking about smart contract-based and more complex implementations and of course smart contracts themselves and this is just, you know, and even this is just a snapshot of what you need to understand. So what do you have? You have a lot of moving parts. You have a discipline that is prone to hyper-specialization and on top of that, being able to coordinate across those moving parts and leverage, you know, personnel and knowledge across these specializations is really key to success. So that's certainly a challenge if you're dealing with DLT technologies, particularly if you're talking about production applications and really going into the real world and changing that as opposed to, you know, an isolated POC, you know, so a little bit of history of us, you know, an introduction to Simba, you know, and what our journey has been. So the company was born in 2017. They came out of a DARPA phase one SBIR contract that was awarded to two entities in Northern Indiana, Atamco, a manufacturing firm that's been around since the 1950s. That's always been on the kind of a leading edge when it came to CAD and other digital tools, bringing digital into manufacturing. They've been doing it for decades and then Notre Dame's Center for Research Computing. So they came together and they applied for this DARPA SBIR Small Business Innovation Research contract with the famed Institute DARPA that many of you may be familiar with. They do really a lot of the primary basic research going back to the 1950s. I mean, the internet itself came out of DARPA or the old ARPA net that some of you may be familiar with in the, you know, the first computer switch and then more recently autonomous vehicles and a lot of other research. So DARPA came out with what was one of their first, either first or second ever blockchain solicitations and this team came together, competed for it and won it. And it was to develop a secure, unhackable messaging and transaction platform for the US military. And one of the lessons that came out of that experience was this is really hard to do. You know, the team kind of backward engineered like the conclusions that we kind of came up with there and I shared with you in the last few slides is born from not just theory, not just reading others' research, although that's part of it, but really living it and experiencing it and experiencing it from day one from being able to develop something like this. And this is a time that there were no tools. You know, you had a pretty much, or at least no, very little in the way of blockchain specific tools. So they had to build this from scratch and the conclusion was this is hard and it can be easier and it should be easier because you're spending a lot of time just building kind of basic component blocks. If we can just give people that, give people a leg up then that's gonna really increase their chance of success and be able to kind of lower the barrier to adoption. So, you know, since that time, the company's grown, you know, we do quite a bit in government contracts, do work on the, you know, commercial side. Our community also includes individual developers. You know, we have a premium line and enterprise sectors and the education sector as well is a major focus area. But in all these cases, what we found in all these communities where there's governments, where there's individual developers, whether it's universities or there's traditional commercial enterprises is, you know, is the importance of simplification, the importance of being able to do that, you know, across kind of the range of the innovation life cycle. So our approach is let's just simplify it. Let's make it easy. And central to that is our API based approach where, you know, we take a business process, whatever that is, it's contextual to the use case. We develop a smart contract around that over the intelligence that can be shared kind of across the network. And then we generate a REST based API which can then connect to your connected network and connect to the off chain. And that's the real kind of, that's the, and it's clearly it's more complicated than that. But the, if we were to really boil it down to take the most simplified explanation of our simplified approach, that's really it. And why do we take this API based approach? Because we see the API, this dynamic API that's very contextual, very use case specific as kind of the efficient point. Sometimes we call it the Preto Optimize Point where it's on that right point between customization and kind of turnkey. You know, if something is too turnkey and you're talking about real kind of no code solutions, the problem there is that you have to, they're not custom. You know, and on top of that, you're bringing a lot of contextual, you have to bring a lot of complexity into the system at that point. You know, learning, you know, no code tools can be like incredibly complicated if they're going to be robust. On the other hand, if you're starting from scratch, then while you're starting from scratch and then at that point, you know, you're not getting the efficiency gains and lowering the barriers to adoption. So our API based approach, we see as kind of the optimized approach when you're trying to, you know, get the right mix of turnkey on one hand and customization on the other. And that's kind of at a high level kind of our approach and why we believe that, you know, this approach is helpful for the most number of people, the most number of organizations. And then our broader innovation is really, really four principles, a practical blockchain adoption and DLT adoption. Eight, you lower the barrier, you democratize through education by lowering the barriers to adoption. So trying to get as many non-technology enthusiasts, non-early adopters in as possible, those who are maybe, maybe adjacent to the technology sector or technology roles, getting those who are subject matter experts, getting them into the development process, particularly when you're talking about a DLT systems, multi-party systems with a lot of moving parts. It's very important that we're able to democratize through education and get those who are outside of kind of the more traditional technology disciplines into the process. So democratization is key. Then of course we know we got to accelerate prototypes, you know, because at the end of the day, you know, if you're kind of doing blue sky or leading edge kind of work, you can only theorize so far at some point you have to build something ideally quickly at a reasonable cost and to see how it works, you know, because at the end of the day, you need the data, you don't know, you're operating in a cloud of uncertainty and the only way to bring certainty in the cloud of uncertainty is to go out and do something and try it and learn from it and then iterate on it. So you got to accelerate. Then you got to connect to the broader ecosystem, you know, because we're not doing DLT in a vacuum. And I think this is where the hyperledger committee will understand, you know, most of this community, our community comes from enterprise related disciplines, enterprise sectors. So we have to operate in the real world of the enterprises that we're operating, you know, that we're working in, you know, and so we have to be able to connect to this ecosystem, legacy applications, as well as non-legacy, even modern applications you have to connect to. And so the importance of connection is really key. And then finally, you got to scale for real world production. And so all of those are really important for a practical approach to success with blockchain and DLT systems. And I think out of all the DLT communities, I got to think that the hyperledger committee will understand this the best because we are all operating in the real world, you know, and we are dealing with the practical realities of how do you cross the chasm? How do you go from the technology innovators and the technology enthusiasts and the early adopters and then into kind of mainstream pragmatic fast forward, fast forward community. If you look at the traditional technology, you know, hype cycle, you know, and I like to say, you know, maybe practical revolutionaries or another term I heard was revolutionaries that actually work. And so hyperledger is out of all the kind of DLT communities, I think will appreciate our approach and this approach as a suggestion of lowering the barrier to entry, accelerating, connecting with the broader system, accepting the world as is, but then scaling within that and then changing. So with that, I'm going to hand things off. I believe, yes, I'm going to hand things off to Tommy and he's going to talk about the trends around a web 2.0, a web 3.0 architecture. And so Tommy hand things off to you. Perfect. Thank you, Anjan. And so I wanted to kind of just briefly kind of just discuss a bit about identifying areas of need for a blockchain. So with that being said, what I'm doing here is I'm just depicting kind of the transition of web 1 to web 2 to web 3, our traditional front end, middle tier, back end, and then talking a bit about where a blockchain might fit in in that basic workflow that we probably are using with anything that we're doing internet related. So with that being said, web 1, you know, it was all about posting data. Web 2 was more about posting and consuming data. And then web 2 was a more about your ability to post data and be your own publisher about you're publishing it for somebody else, right? Like Facebook or YouTube or and they kind of owns your data. So how can we get ownership of that particular transactional data, the individual pictures that we're putting up and things like that? How do we have ownership of that instead of it being owned by the platform? And so with that being said, I think that's what's driving web 3. And so a lot of the pieces and parts of web 3, of course, are things like machine learning and AI and alternate reality and virtual reality. And I think that what we're seeing is that those parts like virtual reality, alternate reality, ubiquitous computing, IoT devices, things like that. That's all more front end, right? Because the front end piece is where we're finding those pain points with inputs and outputs. And so that's what we're going to see a lot of disruption there. But then in the middle tier, we're going to see the disruption with making modifications to those static algorithms that we're constantly using and modifying those so that it's more of a fluid architecture so that the inferences on those inputs can change dynamically. And so that's going to be more of the big disruption we'll find at the middle tier. But then the disruption we're seeing and that's what our focus is on the back end where we need to have immutable data. We need to have distributed data so that not one individual owns all the keys to the data set. We need to have microservice architectures that might be tokenized so that we can confirm that that was the actual Kubernetes cluster that actually took that particular input, right? And it can form to that input data type, right? So you can start to have truth in data, right? And so that's something that traditionally has been a big pain point with any distributed computing model or really any distributing workforce model. And so what we believe in Simba is that instead of trying to focus on figuring out how to fit all those pieces together, maybe just figure out where you need to have immutability in your data structure and then we'll help you index that and start to digitize your data and then start to figure out how you can prepare yourself for the disruption that we think is coming. And so I did kind of brief, I went pretty fast to do that, but I did that in purpose because I want to give Adam enough time for his demos. So I'm gonna go ahead and turn things on over to Adam and then we can answer any questions you might have at the end. Thanks. Okay, thanks, Tommy. And I'm going to ask Tom if you can see my screen. Okay, it's showing okay. All right, perfect. All right, so I'm gonna talk a little bit about Hyperledger. I'm gonna talk some more in detail about our graph model that we use, why we use it. And then after that, I'm gonna show you a demo. So first of all, before I get into the demo, before I get into the graph model, I'm gonna show you later on that we're using Solidity and so I just wanna show you how we're using Hyperledger, specifically the fact that we are using something called Fabric EVM Chain Code so we can deploy Solidity onto the Hyperledger Fabric distributed ledger. So historically all of our tools were built for Solidity and they were built for running on Ethereum. And so this includes our smart contract designer and it includes the restful API generator that Angie and touched on earlier in the talk and it includes our graph model and everything. It was kind of built around this idea that we are using Solidity to define our assets and transactions and we're pretty much using historically just EVM. And so in order to support Hyperledger Fabric, there's a couple of projects out there. Number one is Hyperledger Burrow and that is a completely EVM based private distributed ledger and so we support that fully. But then there's Fabric 2.2, which is not EVM based but there's a project out there called Fabric EVM Chain Code that actually takes components of from Hyperledger Burrow and uses those in chain code that can be deployed directly to Fabric. And then what we do is we put a, I call it an EVM proxy, it's a Fab 3 proxy. We put that in front of the ledger that communicates with that Fabric EVM Chain Code and the Fab 3 proxy is essentially if anybody has worked with Web 3 before or tried to deploy Solidity using like programmatically, then you'll know what Web 3 is. Web 3 is a library that allows you to just programmatically interact with Ethereum and to interact with the Solidity Smart Contracts that you deploy to Ethereum. The Fab 3 proxy is kind of like a play on that. It's a, it basically takes commands as though we're a Web 3 library. So you could send the same commands to it. You can interface with it as though you're interfacing with Web 3. And so the tooling that we built for, you know, for Solidity can now work directly with Hyperledger Fabric. So you can see this diagram here of proxy, the chain code, then the Solidity that's deployed to the ledger. And a couple of things came out of this effort. Number one, we did kind of help with the Fab 3 proxy. There was a minor bug fix that came out of this effort. In addition to that, we did write some documentation on how you can deploy the EVM chain code to later versions of Fabric like Fabric 2.2 or 2.21 and later. Okay. So I'm going to talk about a little bit about the graph model that we have at Simba. So this is, well, first of all, so the problem to think about here and the reason why we have this graph model is to define relationships between assets and transactions and also between the different transactions on the ledger. And so blockchains and distributed ledgers, they don't inherently support relationships that may exist between the transactions. And so from an Audibility standpoint, you know, the question is, how do I know the relationships between these different transactions that I'm reading from the ledger? And oftentimes these relationships are defined either off-chain or they're defined or interpreted by a higher level application that's reading those transactions from the ledger. And what we want to do is we kind of want to ingrain those relationships onto the distributed ledger. That way it stays distributed. And so it's not open to interpretation. We know this is an asset and we know that this transaction actually belongs to this asset. We want to have that ingrained. And so we've leveraged something in the Solidity smart contract code where we annotate the parameters or the method calls to the smart contract. And through that annotation that gets stamped onto the blockchain, we know, okay, this is an asset and this is a transaction that relates to an asset. And whenever we do that, I'll show later on in the demo, I'll give an example. I'll show some Solidity code and show you exactly how we do that. But we basically build like a tree graph or a DAG where every time you put an asset on the blockchain, it comes back with a transaction hash and then you can actually refer back to that transaction hash and a different transaction. And this way we can build a tree. So we have this graph based model. We also have a GUI that can construct smart contracts and through this GUI, you don't have to know how to annotate your smart contract just done automatically for you. You just basically say, I want this business model. I want this asset. I want this transaction to relate to this. And then our GUI, our designer will automatically construct those annotations in the contract for you. And then once it's ready, of course it can be deployed on any of our smart, our supported blockchains, burrow, hyperledger fabric. And so once from here, this actually opened up some, some newer possibilities for us. And this is where we get into scalability. Once we learned how to graph relationships between assets and transactions, then we started thinking about, you know, especially with hyperledger fabric where you have different channels and channels are essentially just, you know, they're different blockchains if you think about it because each channel, each different channel has its own Genesis block. They have their own identities that join that channel. And so they're kind of like different distributed ledgers in a sense. And so we do have, you know, some problems where we have perhaps one identity on one channel, but not on another channel. Whereas we have a parent company, let's say that has to have view on both these channels. And so how do we link that across? How do you graph that across? Of course. And so we extended this further so that we can actually graph across different blockchains and relate the, relate two different channels or blockchains together. And then we've extended it actually to relate two different versions of the same contract. Cause, you know, like the business problem that you're trying to solve on a distributed ledger is that it's not static. It's not permanent. It changes over time. And so we want to be able to, if I have to update my smart contract, I don't want to lose my interface to all the previous data that's been transacted onto the blockchain through that. Instead, I want to kind of graph those together and keep those together. And so we've extended the graph model to do that as well. Okay. So this is just a production example. So this model connects everything together by representing relationships between entities, of course, as I've said before. So on the left, we have data from a supply chain and this data is actually disconnected. It's disparate. It comes from different data sources. And then that's being stored. I'm going to link blockchain. Simba chain applies the use of a model to annotate smart contracts just like I said in the previous slide whereby those assets are being tracked. And then this process results in a graph being stored on the ledger that provides structure to the data and gives the necessary semantics so that the data can be interpreted using graph queries to gain insights into the stored data. And so this kind of leads into how do you actually, so we got this graph model right. We're storing this in a structured way in the blockchain. The relationships are ingrained into the ledger. Now we want to be able to actually query those results and get insights. And this is where we kind of lead into the reason for choosing GraphQL. Simply because it's just, it's a much easier way to graph these relationships. And so, and that's kind of the centerpiece of the demo is this GraphQL tool that we've built. It's much more effective in terms of querying of time and transactional relationships. And you can query, like I said, you know, the graph it's not just between assets transactions. It can consist of nodes which could just be blockchains. The nodes could be smart contracts, different versions of smart contracts. And then the relationships are of course the edges between all of these nodes. So GraphQL just kind of, kind of fits into that we want to do. Okay, so then I'm going to stop sharing here for just a moment. And I'm going to share the demo. And I'm going to share my screen for the demo, but I did notice there's two questions in the Q&A. So as I'm switching screens here, I will try and answer those questions. Why don't you go ahead and do the demo? Charles, thanks for the questions. I want you to go ahead and just get started with the demo. And then we'll hold questions until we get past the demo, if that's okay. Okay, sure, sure. Yeah, why don't we do that? Okay. And then I'm again going to ask Tommy, can you give me a thumbs up? You can see my screen, okay? Right, perfect. Okay, so let me just log in here real quick. And I'm going to show you what we have here. So this is a very simple smart contract. In it, there's four assets. Those are the supplier depot part stock item. This is just a very basic supply chain smart contract. That's not too complicated. We have one transaction or one event and that's the supply event. And you can see here that we've related that's the supply event to the supplier part depot where a stock item is an asset that belongs to either supplier. And then we have part, which is a very specific like a specification of a stock item. So I'm going to show you the code real quick and I talked about annotations. This is just a very, very simple example of annotations but if you look at the part function here on line six, we have as a perimeter, we have underscore, underscore part. So this is an example of an annotation. And then we have down, if you look down here at the bottom for a supply event, you can see that it actually refers to a depot supplier part. So basically when you stamp onto the blockchain or register a part on the ledger, it comes back with a transaction hash. So anytime you do a invoke a supply event, we actually take and remember that supply, we remember that transaction hash and we kind of refer back to that as that is the part that this supply event refers to. And so this is what I mean when I say we're kind of in granting relationships onto the blockchain and then we can graph that back. There's of course, I just showed you to the graph you hear and I'm going to open up this graph QL tool. So you can see what this looks like. So I'm going to click on supply. I refer it to load. Okay, so this is the query builder. So we call the query builder. This, I mean, the view looks just like what I've just shown you. You can see the relationships between the different assets and transactions at a very simple, a very simple query. I'll just show you real quick here is I can click on any one of these and I can begin to build a query. Like for example, if I want to relate a stock item to a supplier to a supply event then I click on those and I can build a graph, a graph QL query that will bring back for me those relationships. But first, like a very simple query would be I can just like one asset, hit query and then it shows me the results of all the supply events that have occurred on the blockchain, including some of the information like what you would normally see if you were to read directly from the blockchain you would have like receipts and you can see that information here as well. And if I click up here at the very top and those kind of small icons are a little bit small but there's an icon there at the top right that if I click on that it actually shows me the graph QL query that was constructed. And then let me go back here. Okay, so that's a very simple query. Now let's say I want to take stock items, suppliers, supply and I can actually filter on, let me find it let me just find one stock item here that I can filter on. So I'm going to grab this stock item here for example, I'm going to go back. I'm going to relate I want to find all the stock items that supplier has supplied for a particular depot perhaps. And this is kind of, I get this as an example all the time but why would I want to find all the supply events from supplier for a particular stock item and this might be useful for depots or warehouses or anyone who wants to track stock and transit they want to know where it is at any point in the supply chain. So this is just kind of a basic query that we can do. So I'm going to take that stock item and you can see here I can project on the fields that are in the smart contract that we saw before and then I can filter on those fields and I said stock item contains very nice. Now if I hit query should give me, there's the stock item and then from here I can drill down and I can find all the relationships linked to this particular stock item that I've chosen. So I could say, okay well who are the suppliers and we can see there's multiple suppliers that actually supply the stock item. Most of these are just examples of course they're not real and then I can drill down even further into all of the supply events including their dates and when they were supplied. You see this is ACME depot and a fake warehouse where this was supplied to. And so you could say this could be like a pseudo depot could be something like an intermediate location where this stock happens to be before it was moved on to its destination. So you can kind of navigate through all of these relationships using the GraphQL tool. Now let me go back here. And so that is, I believe that is the demo I wanted to show you and so I can pause here and then ask the audience if there's any questions about that and then I can hand it off again to. I think one good question Adam would be, could you save that query that you created out and then possibly share it with other members that are in your custodium with that query work as well? Yeah that's true. So this is exactly why we have this tool here. So if you click on that up at the top you can actually get the very GraphQL query that was used. And you can copy paste this and reuse this. And so we have tools you can either download this or you can copy paste this and reuse that. Yeah so there's some other features here. I talked briefly, cause this is a very simple example, right? But before I get going back to the issue of scalability and the issue of scalability is you have your business is growing now you have multiple channels. Now you have multiple blockchains. They have multiple versions of a smart contract. And we use, in the same way that we annotate these transactions and ingrain them onto the blockchain we've extended that graph model. So now you could, if you scale out to multiple channels or scale out to multiple smart contracts you can graph those all together and keep those as part of the entire business model that's behind using a distributed ledger. Sure. Yep. And there's different views of course you can take here. And so I'm gonna, is there any other questions? We had two that came up in the chat window and we'll go ahead and just take a look at those real quick. So one, the first question is kind of two questions in one but basically why would did we add a hyper ledger as an optional foundation for one of the distributed ledger texts and then what attributes would be the driving choice between Ethereum and hyper ledgers? So if you wanna go ahead and add them and then if you have any, I can add some to that if you have anything else, yeah, go ahead. Yeah, sure. So what we were seeking in terms of when we added hyper ledgers and so we were actually thinking of throughput is number one in the fact that hyper ledger fabric our choice that for a blockchain actually has baked in security, right? And so it's private. The identities and roles that exist within the fabric network are all governed by the organization. And even if you link like two autonomous organizations together so you have somebody out there that has their own hyper ledger fabric network and we have our own hyper ledger fabric network they can still govern their own identities and then they come together with like a peering relationship or a business relationship and they're able to kind of choose, okay, I want this identity to be part of the channel that exists between our two networks. And so like that security and privacy is built is like baked into the fabric and mainly really also just because of the high throughput and compared to Ethereum. Now the other question was what are the attributes of the use case that drive the choice between Ethereum and hyper ledgers, the DLT foundation? Actually, could you expand a little bit on that question? I may not understand it too well. I would say that probably generally speaking it would be some where you don't want to have an anonymous application. It's more of where you have to have a secure identity before you can gain entry. That might be a good attribute that might drive you towards hyper ledger versus Ethereum. But if it was more anonymous completely anonymous type application then you might lean towards Ethereum that could possibly answer that, I'm not sure. So there's another question. Is the room in the toolkit for other DLT chains optimized or directed at additional feature function? For example, a new cypher. There definitely is. We're actually adding new distributed ledger technologies often. We started with one, we started with just like I said historically, we started with Ethereum. And since then we've added a bunch more including I think we have like Stellar which is completely different from Ethereum, right? But we can build the same tools on top of Stellar. We have, we've supported Binance. Of course, like I said fabric and a few others I think there's so many that I can't really come up come up with them at the top of my head right now but there's definitely room in the toolkit for that. And we're constantly thinking of ways to adapt that technology. Yeah, I'll add to that. And thanks for your questions, Charles. Yeah, I mean we're, I'd say architecturally as well as strategically, we do have that room that can be added. But put to your first question on to bring it back to hyper ledger versus Ethereum. I mean, I think just broadly speaking there is a reason why hyper ledger has the footprint it does has a real estate is does in enterprises and kind of traditional enterprises and other organizations and institutions. And it's well suited for that. And an example and a very, if you go one layer deep it's exactly what Adam said, it's the security aspect and those types of properties of hyper ledger that are going to be important to traditional institutions and organizations. And so that clearly drives the choice. I mean, we're getting into probably a much bigger debate of between protocols and Ethereum and hyper ledger and there's probably passionate debates that take place on that topic. But clearly, there's hyper ledger is strong in the enterprises and there's reasons for it. And the other thing, Adam, you mentioned secure channels. I mean, that being able to communicate across channels. So kind of collaborate securely or safely within a secure environment. So having these kind of layers of security and these layers of collaboration being able to do cross-channel like certain amount of autonomy within a channel and a certain amount of flexibility across channel, all of that is well suited to hyper ledger and is an important need for enterprises. So, and that's probably why this community is strong within traditional institutions. Did get a couple more questions that came in in the chat too. Let's see, is there a way to export Simba query data to visualize data analytics tools such as Tableau and click. Do you know on that Adam, do you know if there's good query data as far as like with our query tool? Yeah, so this is something that we're actually working on in terms of exporting the data, that is the goal here because we wanna find the whole purpose of this tool is to find insights that aren't really obvious right away. And we are looking into adding another data analytics tool to our tool chain. It could be Tableau, it could be something else could be something that's kind of homegrown. But the idea there is, yes, you can actually export this data out of this tool and then visualize that somewhere else, that is the goal. Yeah, we see another question from Claudio. How to install and instantiate chain code or how to create chain code from the tool? So yeah, so chain code in terms of, for example, if you're writing chain code for hyperledger fabric. So like I said before, we kind of, the tool chain itself is based off of Solidity. So what we do is we've installed the EVM chain code and that's something that's already done. And then you would construct your Solidity smart contract and deploy that through the EVM chain code. So, but in terms of your question, like how to install or instantiate chain code the tool itself doesn't generate the chain code, it generates smart contract, this Solidity smart contract that gets installed. And if you would like to know how to install or instantiate chain code, like I said, there's like, I'm sure hyperledger fabric has plenty of documentation on that. I've been through it. They have plenty of examples, pretty plenty of documentation but we also wrote a document of our own at the Simba chain site that walks through how to deploy chain code onto FabriQ 2.2. Well, more specifically the EVM chain code onto 2.2. Great, thank you. We have a question. It's more of a comment I'd say from Oliver. Where does hyperledger BESU fall into this? It's not so much Ethereum versus hyperledger anymore. If BESU supports the Ethereum mainnet as well as permission channels. He's asking us to comment on this. You know, it's really more of a comment. So you guys care to make a comment here? Yeah, so BESU is like the Java based client for Ethereum, right? So it's a lot like in terms of you have Gath, which is go Ethereum and you have this written in Golang and you have a parody as well. So BESU is just the Java based version of that. And yeah, it is, it can't support permission channels and we are actually going to support BESU. That's next. And so in terms of, it's not so much Ethereum versus hyperledger anymore. I'd never thought of it as Ethereum versus hyperledger to be honest, but we, you know, we're obviously, their hyperledger is working on their own tools to support all kinds of Ethereum based stuff. Just like I said in the previous slides, I was showing hyperledger borough for example, which is a private UVM based distributed ledger built on Tendermint, I think it's called Tendermint Consensus Algorithm. And so, yeah, I mean, I don't see it as Ethereum versus hyperledger really. And we are working on supporting BESU in the future. Great, I don't think we have any questions now, but feel free if you have more questions to put them into the chat. One thing we could do is, because we do have a little bit of extra time until some more questions trickle in. Did you wanna talk a little bit about another slide we had in Reserve Atom on, because this is a question that has come up in the past in the hyperledger community related to fabric? Let me just bring it up now. Give me just one moment. Let's get past. Okay, so this slide, basically this is showing something, I would call them autonomous fabric networks or autonomous MSPs. And what I mean by that is, let's say you have several organizations and they've already have their established networks. And they may even have, their networks are already peered up with clients of their own. And I think one relationship we could think about is, you have tiers of suppliers. You have a major supplier and then they have their own sub tier suppliers applying to them, but then they also have their customers, right? So maybe there's a pre-established fabric network that exists and the difficulty, the challenge is, how do you connect these together? That is, how do you peer them together if you have all these different self-governed MSPs and identities? And there's like some alternative, there's like different ways you could do this. Obviously, so hyperledger fabric has like cascading you have a root CA and then you could establish intermediate CAs between the different organizations and you can establish identities and channels through that methodology. There's other ways of doing it. I've heard of people using cloud native solutions such as Azure AD or Key Vaults and things like that. For the, we had a particular challenge which, and I won't go into too much detail. Well, there's a third one. You could also use IBM blockchain platform, of course, to do this and you could set up all of your networks inside of the IBM blockchain platform. So without going into too much detail though, these three forms of peering were not really an option to us. There's a bit of a challenge and so I was just showing you how do you do it if you have all these different self-governed MSPs and you wanna peer them together, how do you do that? Because you have to somehow export the certificates of the identities that you want to enroll into your channel from the other organization. And I was just gonna show just briefly how we've done this. So we've actually come up with a secure messaging system or secure file exchange system really is what this is. And so these autonomous MSPs that wanna peer together, they would export and share their certificates, other secrets and we would share that and then be able to vet one another and then connect one another through that. So that the file exchanges use very infrequently, right? It's used only to share these secrets and crypto material. And then after that, we have secure channels that between endorsers, we set up secure channels between endorsers and then those endorsers using a secure channel can vet outside MSPs and bring them in and help them join the network this way. So this is kinda like, there's different ways of doing this but I do know after talking with a lot of people that this happens to be a question on a lot of people's minds in terms of how do you connect two different networks together. And I just wanted to share this is how we're doing it on our side. Great, thank you. I think that, are there any more questions? It's your last chance of asking questions while you have amazing guys from CymbaChain on the line. There is a new one. Does it support private data collection as well? It does support private data collection, yes. So the tool chain that we've developed, we actually developed something called, it's an ETL, we're calling it Kettle, but this ETL actually allows you to push, so we would deploy this within your own network or within your own infrastructure, completely private to you, you manage it, and you're able to push private data through the ETL onto a private or secure channel. And so we have that, there's other ways of doing it, we also have connectors, we've actually published SDKs, so those SDKs are actually public right now, if you go to like CymbaChain, if you go to the GitHub repo for CymbaChain, you can actually download and use those SDKs to build applications or import that into your application for ingesting data into CymbaChain's, through CymbaChain's API and onto the blockchain. So there's SDKs that you can use and build your own, there's connectors, we have connectors, and we also have an ETL tool that can be deployed within your infrastructure. So yes, we can most definitely, we can ingest private data, yeah. Thank you. Well, oh, how to, there are two more questions, how to install or initiate chain code or how the tool can generate chain code? Yeah, so that, so that this tool, because it's, most of the tools were kind of built on solidity, so we don't generate chain code directly. What we do though is for hyperledger fabric in particular, we deploy the EVM chain code onto that ledger, the hyperledger fabric that we support. And then the tools that we have actually construct a solidity smart contract and deploy that to the ledger through that chain code. So it doesn't actually generate chain code, it generates solidity, but then we use that to deploy through the chain code. I think I answered that question before, but also if you're interested in how to install an instantiate chain code, we have some documentation that can help out with that as well. I hope that answered that question. Yes, I think it did. Thank you so much for your presentation. Thank you for the time you spent preparing for it and delivering this very interesting talk. As I said, the talk has been recorded or is being recorded as we speak, and we will be publishing it later today probably. Now, if I go back to sharing my screen, I have a couple of slides to wrap it up. So as a reminder, this is a webinar series, so Nantes one off, and we will have new webinars coming up. First one will be, or the next one will be delivered by Swisscom on the October 14th, and then on October 21st, we'll hear from Tec Mahindra. If you are looking for more content and you are looking for more videos, please check out our YouTube channel. We have some very good recordings from our Hyperlogic Global Forum there. Also, all of the presentations, slides are available through our sketch. And please do get involved. We love participation from the community and everybody is welcome in Hyperlogic community. So jump on the chat, email us, and we'll help you get started. So again, thank you so much, Adam, Tom and John, and I'm looking forward to seeing you again soon. Stay safe. Thank you. Thanks everyone.