 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 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. 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 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 to 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 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, 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. But on the other hand, being able to utilize and optimize and coordinate across these component parts is critical for success. So 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 component parts and these hyper-specializations and hyper-specialists together. And that's where the real return on investment is if you're implementing DLT technologies. And then on top of that, blockchain is complicated. As we said, you've got just a few things that a business needs to understand, you've got libraries, you've got wallets, course cryptography, the networks themselves, 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, particularly if you're talking about smart contract-based and more complex implementations and of course smart contracts themselves. 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 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 an isolated POC. So a little bit of history of us, an introduction to Simba and what our journey has been. So company was born in 2017, it came out of a DARPA phase one SBIR contract that was awarded to two entities in Northern Indiana, a TAMCO, 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 ARPANET that some of you may be familiar with and 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 developed 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 in experiencing it from day one, from being able to develop something like this. And this is a time that there were no tools. You had a pretty much or at least 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 going to 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 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, whether it's governments, whether it's individual developers, whether it's universities, whether it's traditional commercial enterprises, is the importance of simplification, the importance of being able to do that 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 or 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 this, 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. 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. 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, learning 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 well, you're starting from scratch. And then at that point, 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 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 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 of practical blockchain adoption and DLT adoption. A, you lower the barrier, you democratize through education by lower the barriers to adoption. So trying to get as many non-technology enthusiasts, non-early adopters in as possible, those who are maybe adjacent to the technology sector or technology roles, getting that 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 because at the end of the day, 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. 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 to 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 because we're not doing DLT in a vacuum. And I think this is where the hyperledger community will understand, most of this community, our community comes from enterprise or enterprise related disciplines, enterprise sectors. So we have to operate in the real world of the enterprises that we're working in. 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 community will understand this the best because we are all operating in the real world. 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 community. If you look at the traditional technology hype cycle, I like to say 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 barriers 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, Web 3.0 architecture. 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, it was all about posting data. Web 2 was more about posting and consuming data. And then Web 2 was more about your ability to post data and be your own publisher, but 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 in the middle tier. But then the disruption we're seeing, and that's what our focus is, 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 through that, but I did that in purpose because I want to give Adam enough time for his demos. So I'm going to 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 going to talk a little bit about hyperledger. I'm going to talk some more in detail about our graph model that we use, why we use it and then after that I'm going to show you a demo. So first of all, before I get into the demo, before I get into the graph model, I'm going to show you later on that we're using solidity. And so I just want to 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 Anjan 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 borough and that is 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 borough 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 the 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 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 auditability 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 have, 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, also 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. It's 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 supported blockchains, Burrow hyperledger fabric. And so once from here, this actually opened up 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, especially with hyperledger fabric, where you have different channels. And channels are essentially just 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 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 two different channels or blockchains together. And then we've extended it actually to relate two different versions of the same contract. Because the business problem that you're trying to solve on a distributed ledger is it's not static. It's not permanent. It changes over time. And so you 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 on the underlying 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, 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 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? All 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 supply event to the supplier part depot where a stock item is an asset that belongs to their 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 parameter, 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 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 that 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 ingrained in relationships onto the blockchain. And then we can graph that back. There's, of course, I just showed you to the graph view here. 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, right, 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 query, a graph QL query that will bring back for me those relationships. But first, like a very simple query would be I can just select 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? 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, supplier 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 give 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, I can find all the relationships linked to this particular stock item, you know, that I've chosen. So I could say, okay, well, who's the, who are the suppliers? And we could see there's, 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, 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 debug and a fake warehouse where this was supplied to. And so you could say this, this could be like a pseudo-debo, it could be something like an intermediate location where this, 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, I can pause here and then ask, 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, other, other members that are in your consortium with that query work as well? Yeah, that's true. So this is exactly why we have this, this tool here. So if you click on that up at the top, you can actually get the, 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, you can copy, paste this and reuse that. Yeah. Yeah, so there's some other features here. I talked briefly, because 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 businesses growing, now you have multiple channels, now you have multiple blockchains, they have multiple versions of a smart contract. And we use, you know, 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, you know, 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 your, your, the entire business model that, that's behind using a distributed ledger. Sure. Yep. And there's different views, of course, you can take here. And so I'm going to, 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, why would 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, so if you want to go ahead, Adam, and then if, you know, if you have any, I can add some to that if you have anything else. Yeah, go ahead. Yeah, sure. So, so what we were seeking in terms of when, when we added hyper ledgers. And so I, we were actually thinking of throughput is number one in the fact that hyper ledger fabric, our choice that for, for a blockchain actually has baked in security, right? And so it's private. The identities and roles that, that exist within the fabric network are all governed by the organization. And if even if you, 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 part 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, 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 get gain entry. That might be a good, 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 might be the that could possibly answer that. I'm not sure. Hmm. 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 C, new cipher. 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 just, 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. You know, yeah, I mean, we're, you know, I'd say architecturally as well, strategically, you know, we, we do have that, you know, we have that room that can be added. But put your first question on to bring it back to hyper ledger versus Ethereum. I mean, I think just broadly speaking, you know, there is a reason why hyper ledger has, has the footprint it does, you know, 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 in 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, and, and so that clearly drives the choice. You know, I mean, we're getting into probably a much bigger debate of between protocols and Ethereum and hyper ledger, and there's probably, you know, passionate debates that, you know, take place, you know, on that topic. But, but clearly, you know, there's, you know, hyper ledger is strong in enterprises, and there's reasons for it. And the other thing would as, you know, you Adam, you mentioned, you know, secure channels, I mean, that being able to do, you know, communicate across channels, you know, 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 chat 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 a an important need for enterprises. So, and that's probably why this community is, you know, is strong, you know, 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 current tool? Yeah, so this is something that we're actually working on in terms of exporting the data that that is the goal here, because we want to find the whole purpose of this tool is to find insights that aren't really obvious right away. And we, 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 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 it's 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, the 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, 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 Faber 2.2. 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 Beisu fall into this? It's not so much Ethereum versus hyperledger anymore. If Beisu supports the Ethereum mainnet as well as permission channels, he's asking us to comment on this. It's really more of a comment. So do you guys care to make a comment here? Yeah, so Beisu is like the Java-based client for Ethereum, right? So it's a lot like in terms of you have Geth, which is Go Ethereum, and you have this written in Golang, and you have Parity as well. So Beisu is just the Java-based version of that. Yeah, it is. It can't support permission channels, and we are actually going to support Beisu. That's next. 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 obviously, the hyperledger is working on their own tool set 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 EVM-based distributed ledger built on Tendermint. I think it's called Tendermint, the consensus algorithm. I don't see it as Ethereum versus hyperledger really, and we are working on supporting Beisu 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 want to talk a little bit about another slide we had in Reserve Atom? 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. I'm going to skip past. This slide, basically this is showing something I would call them autonomous fabric networks or autonomous MSPs. What I mean by that is, let's say you have several organizations and they've already have their established networks. Their networks are already peered up with clients of their own. I think one relationship you 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. Maybe there's a pre-established fabric network that exists. The difficulty, the challenges, is how do you connect these together? How do you peer them together if you have all these different self-governed MSPs and identities? There's different ways you could do this. Obviously, hyperledger fabric has cascading CAs. You have a root CA, and then you could establish intermediate CAs between the different organizations. 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. We had a particular challenge, and I won't go into too much detail. 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. 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. I was just showing you how do you do it if you have all these different self-governed MSPs and you want to peer them together? How do you do that? You have to somehow export the certificates of the identities that you want to enroll into your channel from the other organization. I was just going to show just briefly how we've done this. We've actually come up with a secure messaging system or secure file exchange system, really, is what this is. These autonomous MSPs that want to 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 the file exchange is used very frequently. It's used only to share these secrets and crypto material. 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 kind of like, you know, 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. 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 Simba Chain 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 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, it's, there's other ways of doing it. We also have connectors. We have, we've actually published SDKs, so those SDKs are actually public right now. If you go to like Simba Chain, if you go to the GitHub repo for Simba Chain, you can actually download and use those SDKs to build applications or import that into your application for ingesting data into Simba chains through Simba Chain'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, the, 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, or hyperledger fabric that we, that we support. And then the tools that we have actually construct a solidly 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 and instantiate chain code, we have, we have some documentation that, 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 schedule. 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.