 Hello everyone. Welcome to the other session titled Hyper-Asia Cactus Project Update. This session will be presented by the co-author of the Shingo Fuji model from the Fujitsu and Peter Samugari from Accenture. We are expecting 30 minutes presentation and we would like to reserve the 10 minutes box metering for the questions and answers. So please be prepared for your questions and comments. So let's get started for the sessions. So as an introduction, unfortunately Peter is not on the stage yet, but Peter and I are the co-mentioner of the cactus project. Over the two years, we are collaborating to develop the cactus from the beginning. I'm the manager of the data and security research laboratory in Fujitsu. I've been working on blockchain technology for several years. So Peter is a technical architect in Accenture. He is the active manager of Accenture and is also maintained to the top of the Hyper-Asia project. So the very first half will be I will present to the background of the project and the status. And later on, I will give the mic to Peter to introduce to several working examples and future plans. That is the consistent structure of today's sessions. So the first of all, I'd like to explain to you some background of the cactus. So just imagine the shopping scenes in the towns. And the users want to buy some of the shopping items from the shopping truck box. That is very easy to trust because they are in person. So both parties can trust each other for the payment and giving items at the same time. So that was happening in the real world. However, that is not as easy as in the virtual world. So for example, for the payment, we need some sort of the virtual currency or a stable coin will be used on the blockchain. And that blockchain has an account for the Alice or Bob. And also the shopping items need to be some sort of the management systems, which keep the record of the ownership of the digital assets. So when the trade between the user Alice and Bob will be made, that means the coin will be a transfer from the Alice to Bob on the one reger. And another reger, Bob will be transferring to the ownership of the item to the Alice. So the problem on the use cases will be there is no mechanism exist for the synchronization between the blockchains. So here's a scene of the cactus comes. So the cactus will be providing to the security mechanism to integrate to the blockchain security. So I believe Peter has come to the stage. Hello Peter, can you hear me? Hi Jingu, yes. I'm ready to take over my slide. Okay, thank you. Well, I just started with the first slide. Can you give yourself an introduction as a short? Yes, and apologies for being late. I'm Peter Shomodivari. I'm one of the maintainers of Hyperledger Cactus. My day job is to work as a technology architect at Accenture. And part of that is me being one of the maintainers of Cactus. And nice to meet you all. Thank you, Peter. I will give the mic for you for introducing to the use cases and future plans later. So the second slide showing to the role of the cactus in the Hyperledger greenhouse. So in the Hyperledger project, we have several blockchain platforms at the same umbrella. Best Barrow, Fabric, Indie, Iwoher, and Sotus. So I believe that those are the competing each other because there is no one fits all solution for the digital asset management and some sort of the trial kind of the mechanism. So the cactus will be a collaborate with such a blockchain project potentially. And also we need to be collaborate potentially as the library prospective like Aries and Arthur. Because of those providing to the useful script libraries and features in use of the blockchains. So the cactus is categorized in the one, the tools in the Hyperledger. And we had a born in the 2020 in the spring that was the 16th official project in the greenhouse. So the other recent update after the almost one years from our establishment of the cactus, we announced the blog post as some sort of the interim achievement, which was version 0.4 was released. That was the first release of the source code for the public. So that was improved from the architecture from the beginnings. And now that we are at some sort of the modularity was improved. And we had a very stable architecture now. And the important part of the architecture will be a tool. The first one will be a razor plugins. That will consist with a barifier and validator and the connector for the features the interworking blockchain dependent. So the other validator will be a node on the deployed on the interworking regions. And that will be providing some sort of abstraction operation on the razor and monitoring. And also, on the other hand, the cactus will be integrated into the cactus application, which will be consistent with the infrastructure part, which is named to the cactus node server. And we also have the very application specific logic named to the business logic plugin, which might be the vendor specific. So as a collaboration of those two components, the cactus will be provided to the various sort of the application we can be provided. So the basic concept of the cactus will be the business logic plugin will be an interact with the validator server in the three type of the communications. The first communication type of the communication will be submitting to the transaction data, which was the supposedly that is already signed. And that is the kind of briefing for the difference of the abstract to the difference of the communication protocol. And the business logic will be sent to those abstract data through the communication channels. And because of the submeters of the transaction data will be a synchronous manner, the blockchain business logic will be also needed monitoring for those transactions is successfully accepted or not. And those are determined by the monitoring for the blockchain data, which was generated. Those notification will be also come through the communication channel in the bidirectional manner. And the business logic plugin also the in occasionally need to the making the query type of the operations, like getting to the balance or the current ownership of the asset. So those kind of the mechanism will be some also provided as a asynchronous way. However, in the communication perspective that was integrated as asynchronous and that will be absorbed differences. So the following slide we are providing to the information about how that we can develop to the reger plugin for the specific regers. So the in the center, we will have the cactus node is could be running. And we determine to the which the blockchain reger technology will be the interworking. And at that time, we will start to the building to the Docker container, which name to the test net or one or in one container will be provided as a tool. And the second step, we will be implementing to the bar data server, which contain to the other reger specific part of the operations, like we need to the sending to the transaction. So the that we bear the bar data server will forward those operation to the actual reger protocol in as a breach. And also that we also providing the testing mechanism testing framework, that can be tested for those bar data as a parts. And, and finally, we will providing to the some of the example application, which can use to the bar data as a application. So the those connectivity will be absorbed in the two way of the two choice, the one for the socket IO and the one for the other one will be an open API. And the user the communication mechanism was chosen. The cactus make the business logic plug in other example application can be absorbed to the the minimum to the the difference of the operations and the protocols. So the other as I mentioned in the two page before, the cactus was not published as the public comment for the stage for the evaluation purposes. So these those are contained to the four example applications like a car trade, electric trade and supply chain management and the renewal energy trade. All those are very well the interesting topics. So the those application using the actually for the following the other region province. Those are the we are enhancing to the support before the version one will be released. Those plan will be presented by the Peter Rayder. So the folder that I really explained to the how the cactus application work with the cactus in by step by step manner using to the first example and named the car trade application. That is the that is not the creating to from the scratch. The you may know that you probably may know the other fabric, the high pressure fabric has the famous application name to the public car, which manage the transport to the the ownership of the car one to the others. We use to the that application as a part of the other cactus application. And also we use to the the Ethereum, the private chain for the simulator for the stable coins. So the the in that configuration, the that fabric will be interconnected to the cactus and the Ethereum network will be also connected to the cactus independently. So defend the artists as a user issuing to the the trade that is a stream to the the one now or the the rent a car for the the paid money. So the that is agreement of the service contract between to the Alice and Bob. And Bob will be the responsible to execute the services, but the other cactus will be intermediate for the security purposes. So the friend cactus received to the request. The cactus will be a help to issuing to the artist to the the sending money to be or the cactus as a escrowed. So the defend the cactus, the determined detected that the money was safely deposited. The cactus will be issuing to the second logic to the Bob to the, sorry, the artist will be used to the curve. And finally, the this transferring the transfer, the this service providing is the successfully ended. The the the the cactus will be executed to the the deposit money to the transfer to the Bob as a successful case. So the there is another the example like a electricity trade record that we also use be used to the sawtooth application, which name to the into integer values. So the we assume to the we assume to the the integer value system will be keeping record of the smart meter record, reading met meter records will be keep the recorded as for the case of the let's say the two kilometer watts will be generated from the solar powers. Does that will be a charge for the the the smart contract and will be a send to the money to the the Well, prosumer can be received to the the the the folder and 80 cents as a reward for the power generations. So the the interesting point will be there is a no the the implicit invocation of the application was not happening in this use cases. The example will be automatically executed by the smart contract as the the the smart contract like application will be executed. So the next slide will be presented by the Peter. Can you continue to the explanation Peter? Yes, I'm going to share my screen just one second. Can you see my slides? Yeah. Great, thank you. The single said we also have a supply chain example, which features the most basic form of interoperability that we know where you can present a consistent data view of different lectures in the application layer by having a backend that has the ability to talk to all the different lectures where you're storing data. And our supply chain example demonstrates this ability by being an end to end example containerized where you get a front end application that can track this made up use case where a bamboo horror circles then bookshelves are made out of that material and then those bookshelves are then shipped. And the interesting thing there is that all these three steps of the end to end supply chain are tracked on a different lecture. The first one basically the second one quorum and the lastly it's a shipments or fabric. And I'm not going to demo this right now we are short on time but if you're interested in an actual demo there was a breakout session a couple days ago. So feel free to look that up as well. And regarding our expected 1.0 features, we would like to add more support for additional distributed ledger technologies. And we really hope to showcase how the plugin architecture can enable this and how it can foster an open source community around the cactus project where people come in and contribute their plugins either as connectors or other types of extensions which leads me to my next point which is that we also have a library of extension plugins such as atomic slopes via HDLCs which are still in their infancy but we are getting there. And of course we would like to have more examples, more stability in the code. We need to nail down the API design for 1.0 and pass all the security checks of course which is very much in progress as we speak. And another thing I should mention is Cordo Enterprise Support of course. We do have Cordo as a supported ledger as of right now but that's only been tested with the Cordo open source version so that's why it's important to highlight Cordo Enterprise separately. And the other important thing is that we take interrupt seriously. We're also talking to other projects, labs or even just proposals within Hyperledger about joining forces in some shape or form. You know whatever it may be however we can work together and reuse each other's code it should be done in our opinion for creating the community that's going in the same direction and does as little duplicate work as possible because at the end of the day if we are all working on similar things then the quality could be, the overall quality could be improved if we are sharing some parts of the code at least. We also have collaborations with Hyperledger special interest groups such as the Climate Action and Accounting SIG and the Trade Finance SIG. The Climate Action and Accounting SIG has a carbon accounting tool that we are exploring with them how we could add a cactus connector plugin in there to help them out with certain fees that they are having right now with lecture communication. And the completely breaking news there is that we are also talking about coming out with a use case that combines Trade Finance and Climate Action but that is so new that it is literally just an e-mail thread for now that started up this week so I cannot say much more about that just yet. The release plan is we would like to start with a release candidate in autumn. The moment is we don't know which month is going to be yet but definitely this fall and then after that once we are satisfied through the release candidate that we are ready for the actual release 1.0 then we will make that happen. And in the meantime as in between right now and the fall we also plan on issuing bi-weekly minor releases with any new features, any interface changes as we go along. So if you would like to keep up with the development of cactus then definitely check out the releases as they come every two weeks. And I will conclude there just one more thing I wanted to mention is that there is a link to our wiki page where there is a link to our calendar where you can find daily pair proof that we run every day in the morning hours of specific time. So if you wanted to try out cactus and something is not working or maybe you just had a quick question feel free to join in there and ask us because that session is just there specifically for community members to be able to hop in and ask something and get an answer right away. And with that said I will open it up to Q&A. Thank you very much. Thank you Peter. So I believe the people in the floor cannot speak up so can you type in the question on the Q&A window if you have any questions or comments? Yes we do have a few questions as of right now. Oh really? Yes you just have to click on the Q&A tab instead of the chat tab. Yeah I couldn't see any updates so can you read out some questions? Yes I'll do that. We only have a few minutes. So Mohan asked who or which party would run the cactus infrastructure and how will transaction costs be charged to the parties involved? Technically it sounds good. Can you? Okay yeah. Please go ahead and answer it. Yeah go ahead. You first. Okay. So the idea is that companies who join together to form a consortium could all run A-node but if you want to you can run your own node just by yourself. There's flexibility in that so the short answer is it depends. And then transaction charges would still be paid by the person or the application interacting with the cactus APIs themselves. Cactus does not introduce a sort of a toll booth. We want to stay away from that in that sense the usage of cactus is free there's no additional sort of transaction payment infrastructure introduced on top of what the ledgers do themselves whatsoever. Second question. Thanks for the presentation. This is from Craig. Craig, how would you classify the production releases or readiness of the Hyperledger Cactus project EG for integrating Hyperledger Fabric and Corno and do you expect 1.0? I think this is before the client. Yes. Yeah we do not have any judgment for the prospective however we think we will rest up to the certain rest of the expected future as a part of the release plan. So when the release plan is safely produced and there is no back. That is kind of the perspective of the we are ready to go for the release candidates. That is all the common in the Hyperledger project. That is my understanding. And the last question is from Guzman. Which guarantees cactus provides to assure receiver blockchain the information passed the consensus protocol from the origin blockchain? Yeah, I believe that is well in the week. Can you back to the slide of the architecture? We are providing to the validator as a stress point. So the validator will be a previous slide. I guess. The validator will be determined to the other finalities. Even the original result itself does not provide such a sense. So the validator and the cactus node will be also having a trust relationship between. So that was named to the consortium mechanism. So that is the mechanism that you are asking I guess. So the other well the basically the cactus does not provide to the general. Well, the wide range of the trust, but we will providing to the user to user contract. We'll be providing to the level of the assurance or service grades. So that is our assumption in the use of the cactus. So the even the same pair of the razor. There is a multiple the cactus node can be deployed for the third purposes to differentiate it to the service level or qualities. Yes. And unfortunately, this is all we have time for. We have to finish on time. So thank you all for joining and have a great conference. Thank you very much for the participating. And we are expecting to the many people to join us for the exciting project to be achieved the great goal. Thank you very much and have a good day. Bye bye. Thank you. Bye.