 Hello and welcome to the session at open source Summit Japan called planning for a multi chain world DLT interoperability and integration technologies. I'm Brian Bellendorf. I'm executive director of hyper ledger and I'll tell you a little bit more about hyper ledger in just a bit, but I'm joined here today with two colleagues, Tracy Kurt, who's a senior technology architect for Accenture. And Shingo Fujimoto, who's a senior researcher for Fujitsu labs. We're going to talk about DLT interoperability in the context of a really exciting project at hyper ledger called cactus. Shingo will walk us through what cactus is and then we'll have a panel conversation amongst the three of us about about the technology and DLT interoperability in general. Next slide. As I mentioned, we're here with hyper ledger all three of us have been involved with the project for a long time actually myself for just just over four years now and Tracy not too much less than that. Next slide. Hyper ledger is a global cross industry open source software initiative advancing business blockchain technologies and business blockchain might sound like a contradiction in terms if most of you know it as the underlying technology behind Bitcoin and Ethereum and other other interesting cryptocurrency projects, but it actually has uses far beyond trading tokens or trying to mint money out of thin air. It actually has a lot of applicability to those kinds of business challenges that have to do with maintaining a ground truth a system of record a single source of truth, which is really hard to do in general. And so hyper ledger is a home for the development of these technologies to go out and build different blockchain networks, but it is ultimately up to you and the companies out there in any given use case to set up that network using these technologies and piece them together. Next slide. This is a project hosted by the Linux Foundation, as we mentioned, and as that we enjoy all the benefits of being, you know, on that Linux Foundation infrastructure. Hyper ledger is also not paying developers dry code it really depends upon organizations like Accenture and Fujitsu and hundreds of other companies thousands actually across the whole of the Linux Foundation, working together to build open source software. Next slide. So actually within hyper ledger, we have a number of different, what we call ledger platforms for building these kinds of networks, some of them that are very widespread today and really the default for building business blockchain networks like hyper ledger fabric, some that are focused on digital systems like hyper ledger indie, some that are focused on some of the cryptocurrency community technologies such as hyper ledger Bezu which is an implementation of the Ethereum platform, and other interesting angles hyper ledger Eroha is a token based system that's very much focused on digital assets hyper ledger borough another take on the Ethereum space, but we found it was actually useful as well to also work on components that can feed into these ledger platforms and connect between them. So for example hyper ledger Avalon which is really focused on confidential computing hyper ledger caliper which is really a benchmarking platform hyper ledger Ursa which is a whole lot of underlying cryptographic routines and embedded as a library inside of some of these platforms. And then next slide, the one we're going to talk about today, which is hyper ledger cactus, which is a really exciting domain. So with that, I think I'd like to turn them the microphone so to speak over to Shingo Shingo take it from here. Thank you Brian. And my name is Shingo Fujimoto from Fujiswaps study, I've been honored to introduce our project cactus. So the rest start from the explanation about to the cactus. So the, well, let me explain about to the box little background for the cactus project. So as you can see that we came today we can see the multiple blockchain on the market prices. But however, the source, the area of the industry is the keep it separated. So the, so, to the, to the, to better world to form the better world, we better to keep the new to the such barriers between the industries. And we better to merge them to the into the single spaces. So the other that could be possible to the to interworking with such a blockchains in for the trading that that is the world we are aiming to the to to enable the such a the trade across the measures. So let me explain about to the issue for the such interworking state interworking scenes. So the just imagine about to the shopping scene on the some of the customers who want to buy the item from the shops. So the that is quite easy in the real world because of the there be in person so the they can give the money and getting to the item. So there's no doubt or trade. The problem. However, if we are talking about to the if we are mapping to the those mechanism for the the blockchain leisure technologies. And that is totally different. So the, the, instead of the trust between the impassants that we find the artists sending to the money to the Bob and the, the, the, well, transferring the ownership of the item from Bob to the artist. So that is totally the power of war. So there is no way to synchronize those trades. So the, the, the problem is how we can build the trust between the, the, the trust across the results. So that is the issue to be solved by the project. So the looking at the, the medias, the observation will be like a one example, like this is a citation from the article of the published by the gardener. And we said to the other the current blockchain technology had the problem for the interoperability perspective, and we need to solve that problem with some technologies. So the, when we are is the such a problem that we are the hyper asia realize to solve this problem for the blockchain markets. So the other. So that we some we need to do not invent but we need to create some new way for the doing the interoperability that is the background of the project. Now, the other this is a hyper asia cactus. So the, the, the cactus enables to do this and tries to secure and the integration framework between the blockchain network so that mean to the, the we can integrate to the multiple users here, like you are there even in the this the figure that was just a drum of the databases, but the actually those are the blockchain, which independently working. And from the other users perspective, the, the, those, the relationship will be automatically solved and intermediate by the hyper asia cactus enables to the, the automatic trading to the asset, one to the others. So that is a concept of the hyper asia cactus. So this concept itself is very useful but that was difficult to achieve. So the, the, the accentory, the, fortunately, the, the two different company had a similar solutions or the other considering to the such a, the common problem. So actually, the, the farm we met the, the, the hyper asia as there are the different perspective, we, Accenture and we agree to working together to use it as both called basis, which was already developed and that's that proved the concept of the structure concept in the across the blockchain regions. So the very beginning of the Cactus project, we started from the figure out what is the necessary requirement for the design perspective that was named the core principle for the interoperability. Those are the four perspectives like maximum positioning for the probabilities and the middleware, no middleware, the middleman for the trading perspective and no human middleman. And also we do not require to the no tokens for the charging, even when the let's say the micro payment cases, that is very difficult to find the touring mechanism was involved, but we are not required or that could be optional. So as a final requirement, so that is kind of the mechanism for the industrial transitions. So from the figure out into such a principle that we are built up to the sum cactus in the basic design for the minimal functionalities. So the first the main functionality of the cactus will be a consistent transaction across the multiple regions. That means that if we are there is no when the inconsistency will be occurred, the cactus will try to resolve the setting consistency into the normal stage. So the second the future of the cactus will be the that is kind of mechanism for the protocols, like a propose and approach first, then they execute. So this is a kind of the that is very important for the case of the trading between to the end users. Otherwise, there are those trading will not be successful. So the final future will be a validity validation. So that is originally from the concept of the Accenture's solutions, like because of the blockchain has a certain mechanism outside of the blockchains. So we need to do some trust towards party need to be guarantees or validity. So the cactus incorporated to such a deal for the validation will be guaranteed as a component of the cactus and that the mechanism will be incorporated as a part of the systems. So let me explain about the common use cases of the cactus. So the intro. So here's a user of the artist. They will be tried to trade into the curve. So there's a kind of big purchase for her. So it has to be avoided. The money will be taken by the rogue seller. That is a kind of serious problem. So the first of all, the artist will be invoked to agree on the trade with the cactus and the cactus will be promised to the trees of the transaction will be successfully executed. As a second step, the cactus will be the cactus will ask to the artist to transfer the money to the to be the cactus itself to be escrowed. And then that the base on the observation for the such the fact, the cactus will also ask to the shop seller, the customer to transfer the ownership from the seller to the artist. And at the same time, the cactus observed to the transferring to the such the transferring of the ownership, the escrowed money will be the settled for the seller. Now the both the artist and both as the both party of the trading will be satisfied. So the even though this period is not mentioning about the error cases, because of the the nature of the escrowed money, if the money transferred was some reason failed, that that money will be transferred back to the original owner of the other the money and regardless. So the as a final, this is a kind of advertisement for our project because of the our project is not serving to the project. So we are encouraging all of you to join us to help or to use to the cactus as a the the common infrastructure. So really, this is a homepage of the cactus, having the well, the all the meeting log on the online in the past and the future. And also, the describing to the GitHub, the which was the currently under the development in the the with the many contributors. Thank you very much for now. Thank you, Shingo. That was a really terrific overview of where cactus came from of the intent behind it, the kind of basic operating model for it. I want to pull in now actually if you could stop sharing your slides so that we can get to kind of a gallery view of the three of us and start in the panel conversation. There we go. Great. So I want to introduce now Tracy Kurt. Tracy is a long history of involvement with the Hyperledger project and has been really leading Accenture's efforts there on the technology side from the blockchain space. Tracy, why don't you tell us actually a little bit about what you do at Accenture now and why you got involved in the cactus project? Yeah, sure. So thanks, Brian. I've been, I guess, involved at the Accenture side in a couple of different ways. Obviously, open source is a big space, trying to figure out how to bring in the work that we're doing at Accenture into Hyperledger. Also architecting solutions for our clients. And I also helped train kind of that next level, the next group of people who are getting into the blockchain space at Accenture. So really focusing in technology architecture and focusing on that aspect. So when I first started at Accenture, and Brian has alluded to this, but I used to work for Hyperledger and I went over to Accenture. And when I joined Accenture, the very first, one of the very first emails that was in my inbox was, hey, we want to open source this interoperability asset that we have. How can we do that with Hyperledger? And so part of the process was helping obviously Accenture understand the processes that we had within Hyperledger for bringing in new projects, be that through labs or through a top level project. Through a number of different discussions, we ended up with bringing this to labs as an initial start. And then secondly, obviously through the work that we did with Fujitsu and bringing in more of the community, we wanted to bring this as a top level project to Hyperledger. Now this all started the work within Accenture on interoperability started before I joined. And it was our labs group that actually has a couple of different patents on interoperability within the blockchain space. One that's focused on kind of that intermediate node, which is kind of a centralized solution where there's a single node that helps to interoperate across the different ledgers. And then the piece that we brought into Hyperledger was kind of an overlay network where we overlay validators on two different networks and then allow for the communication to happen that way. Yeah, interesting. There must be a lot of interesting stories in terms of encouraging a company like Accenture to become an open source friendly company and know how to engage with the community and that sort of thing. Probably some parallels there to helping enterprises understand how to engage with blockchain technology and build these kind of multi-party systems. So Shingo, when you started to work on this, this is something that Fujitsu had built some internal technology around as well. Where did you first hear about what Tracy was working on? And how did you decide to start working together on this? Yes, well, that was a very good opportunity for us to meet together in Tokyo last summer, not last summer, last year. Well, actually, we had a problem to pass away the people to how the interoperability is important for the future of the blockchain world. However, friends, we created and published for the back to three years ago, almost, no one else understood our concept. However, the Accenture member, the friend of the very first conversation, we realized that you think that there's almost the same thing so that we should work together. So that is a very nice meet at the place of the hybrid leisure in Tokyo. But that is kind of the goodness for the open source community, had a certain background for the collaborations. And one of my colleagues, the hard Montgomery, who is also the TSE member and private conversation with Tracy, and that is actually a starting point, I believe. But I'm very happy to have this kind of collaboration that has happened. Shingo was mentioning Tokyo. That was the, and I think Tracy mentioned it too, that was the Hyperledger member summit, which is something we do yearly with our members, kind of a technical conference, but really it's more about bringing the community together. Because I've seen this as well, where a lot of companies, they'll build something interesting internally, something perhaps done for a client or done for a specific project. And then they'll say to themselves, hey, this looks valuable. Should we turn it into a commercial product? Maybe they do that. They go, you know, this is more kind of an infrastructure kind of piece. And for it to be successful, it really should be broadly shared. And so it makes sense to open source. And they put it under, you know, their own GitHub repo. Or maybe they come to somebody like Hyperledger or the Linux Foundation and say, let's open source it. But really, I think both the most valuable thing to do, and one of the hardest things to do, is for two or more companies to realize, hey, we've started building this thing, but, you know, we're really stronger off if we combine efforts and build something bigger than what any of us could do before. For either of you, was there any piece that you had to give up in what you had built in-house when deciding to work together or to work publicly? You know, like anything that was like, well, we built this feature for this customer, but maybe it needs to be generalized a step or some compromise made between the two organizations, different visions for how this would work. I mean, I'm happy to add to that. But I think that the interesting part about Fujitsu and Accenture both developing the same sort of solutions, right, is that we were able to come together and take a step back, right, and start to lay out those first principles behind what should interoperability be. How do we meet those core principles that she can go laid out and think about it in a space that's not just your own space, but think about how this works together as a community and how to bring that community together to have those discussions. And I mean, that's, that's part of the great part of what we did at the Hyperledic Member Summit, right, was the opportunity for us to come together and start those discussions, but then to go back to, you know, for me back to the U.S., right, and bring that forward and make it into something that's real. Yeah, I believe that the discussion is also made during the stage of the hyper leisure labs. That is an incubation project in the other project before the become the official project. So the time of the some sort of the preparation period, we have discussed very the engineer for the details, right, even though we are living to the different zones, that we can be to come together and like we can use to the figures on the hand drawing, and those kinds of the other collaboration was happened. So I believe today we have the rest, the compromise for the post solution, because of the we had the beginning, we have the same concept, and we are designed to the very collaborative. So that is what happened for the Cactus cases. Yeah, the hyper ledger labs, which Shingo mentioned, is our attempt to try to create a place where projects that are still pretty young that seem like a step in the right direction that that, but you know, you don't want to over hype it or oversell it or, you know, start a whole lot of people deploying it yet. It's where projects have a chance to kind of just state operate publicly and be associated with hyper ledger and get some of the IP protection and community development tools that we bring. And that's where Cactus started right as the blockchain integration framework. We have some other projects there the blockchain automation framework, which is another Accenture contribution. Thank you, Tracy. And a couple of other really interesting efforts, one in central bank digital currency and others. So if you're looking for like where that leading edge of enterprise blockchain goodness is coming from, take a look throughout labs. I want to shift back to talking about the features of Cactus and kind of its intended technical direction. You know, I know it's pre one dot Oh, right now it's it's even though it's a it's a it's a full fledged hyper ledger project. It's still something that, you know, is under active development. Could could either of you help characterize kind of where it is right now in terms of developers who want these kinds of features want to be able to use a platform like this? Is it is it ready for production use or is it still a ways off? Yeah, I hope to do such a ready for the product. But that is very difficult because of the we already started to some of the code bases, whatever, however, the for the we are planning to some sort of the point to release is when the it will be a partially available for the, let's say the, that we are having a connectivity part of the the interoperability in the cactus will be released earlier. I guess that would be estimated in the end of this year. You can be enjoyed the play with some of the implementation as a components. However, the we're planning for the more seriously working on the quality of the code at the end of this year. So the I believe to the the first release could be some somewhere in the screen that you can see the as a first derivative from the project as a whole solution. Satisfied? Anyway, I would add to that right within hyper ledger. There's this there's a number of stages that projects go through and they, you know, can start in labs or they can start as a top level project. If they're a top level project, they start in what we call incubation. And this is a state that allows for kind of the growth of the community, right? The understanding of what this community is, how to do releases before it becomes what we call an active project, right? And so obviously hyper ledger cactus is still in that incubation phase. We're still learning what it is that we want this thing to do or learning how to put together the code in a way that's going to allow for this to become active and to become production ready. But you know, for me, one of the things I like to point out is this is a really good time for people to get involved. If they're interested in this space, right, you know, getting in kind of on that ground floor, if you will, right, maybe the first floor, depending on how you want to look at it. But you're really looking at how they how you can add your sort of requirements to the conversation that's ongoing right now. That's great. And I just realized I had my virtual background on as we were talking here. That's why it looked a little weird. And what are the ledger platforms that either are supported today or kind of you consider your first class ones? And then what are some of the others that you think they'll be adapters written for kind of around or soon after kind of the production release? At the current stage of the status of the GitHub that you can see will be here, that we can have the best suit and the glycerine client and the fabric and well, we are still working on the more additional ledger will be supported. So the most important part is those the modules are the independently developed and the core contributed from the different companies. So the ones it was become ready to automatically interoperable between across multiple regions. So the if we are the people seeing to the this video on the open source contributors, the print join us because of the your region technology can be part of the cactus in the new future. So that is a very good opportunity for us to see the such an interoperability enforced the ecosystem which can be delivered from the cactus. Is it anticipated that there'd be support for Corda or some of these other kind of half blockchain, half not kinds of platforms? Yeah, we are working on it. Actually, as a property solution, both Accenture and Fujitsu already had some implementation like visual like system. But for the moment, the first priority, we are working on the leisure technology, which is available within the hyper leisure project because of the hyper leisure hazard only project, which hosts the multiple product blockchain leisure as a choice. So do we have a strong reason to host and to accommodate to those leisure work together? Yeah, one of the first demos that sorry, Brian, one of the first demos that we did within Accenture itself was transferring assets between hyper ledger and Corda. I'm sorry, hyper ledger fabric and Corda. Very cool. Very cool. So is this really just about moving assets or is it also possible to correlate smart contracts across networks too? Or and maybe that's a dumb question, but everything's about moving contracts. But like, could I have a smart contract on one invoke some sort of functionality from a contract on another network? Is that anticipated? It's actually a very good question about the differentiated from the other technologies or similar technology in the market. The currently, in my understanding, most of the inter-regional technologies are more concentrated to the transferring to the money assets one to the other. So like a virtual currency was such a kind of sense. However, in the looking at the real industries, let's say that we need to the try to trace tracking for the fish markets, or maybe we need to the transferring to the car one asset, that kind of the the asset will not be equivalent on the different ratio. That is a gross word. However, the cactus are going to the, of course, the weekend supporting to the actual asset to transferring to the combating to the one to the others. We also supporting to the correlating to the one to the other as a trading as I showed some example. And also we need we can develop to the smart contract to which can be triggered by the events. Like let's say that we can monitoring to the usage of the electric use utilities. And that can be automatically built using to the smart contract to the implemented by the cactus. So the those kind of the new use cases was not the possible in the past. So the those kind of the idea or the concept is already described in the scope of the cactus as a part of the white paper. You can see in the weak page that you can find the white paper. So there is a different contribution from the academic group is also involving to the to create the such a use cases of the target of the future of the cactus. We'll be supporting to the such a new use cases as a variant of the cactus. So that is a I hope that that is explanation for the your questions. Yes, I think that I think the key to Brian is that if you've got two separate ledgers, you need to be able to ensure that you're conforming to the governance of both of those ledgers. Right. And you need to make sure that as you transfer that right as you create this integration, you're not kind of reintroducing the double spend problem that blockchains are intended to solve. I think those are the two key pieces when we're dealing with integration and interoperability across ledgers. Does the fact that the semantics are so different on fabric and ethereum based projects like Bezu and Quorum and and Corda, you know, how they treat confidentiality, even the, as I understand it right fabric is execute, confirm order, right? And isn't ethereum like the other way around? I forget the terminology used exactly. Yeah, doesn't that introduce the potential for I, you know, exactly kind of defeating the double spend problem or some sort of coherence issue when trying to conduct transactions between them? Yeah, I believe that that was the we called the concept of the such a the abstraction for the, the, the series of the transactions. Let's say that for the fabric cases we need to the two phase commit for that is not the actual two phase for the databases that are very different. But however, that we need to do the some interaction with, with the regular technologies, which may be the dependent on the implementations that are dependent. However, those are the, our technology cactus will be carefully designed for the to absorb to the such a difference at the level of the plugins and the two distinguish with communications and the protocols. So they find the case of the ratio required to the interactions that interaction will be implemented as the, well, the business part of the business logic to be involved. And then the, the actual communication will be almost the same for the let's say the, the most of the blockchain support to the JSON format. So the, the business logic interpret the such a differences and that will be described as the scenario type of the program. However, that is the kind of, well, the part of the challenging of the cactus project currently, so that we are still working on the to absorb the completely. However, we can be already see the some of the successful use cases as an example. So the, please see the result in near future. Yeah, so this isn't, this isn't really an abstraction layer then, as I understand it. It's not like it allows you to ignore the operating system underneath the ledger underneath, right? Like this is what you remember when Java first came out, it was, you know, right once run anywhere, which started to write once debug everywhere. But it's intent, right, was to try to make it. So as a programmer, you didn't have to care if it was running on Mac or Windows or Linux or an embedded device or a big mainframe, you know, but it doesn't sound like that's really possible with blockchain technologies because the semantics are so different between them. And you really do end up choosing one architecture over the other much the same way people might choose my SQL for some types of things and MongoDB for something else and Redis for something else that basically they solve different problems with different characteristics. Is that kind of a fair analogy to make? We are not trying to invent the whole thing. So we are using to the many technologies in the open source world, of course. So let's say the database technology can be chosen by the people. So that part that could be solved by the plug-in technology. Plugable architecture helps. Because of the wear, the absorbing to the such a difference as a choice for the implement this, like there is some relationship with in favor, like this is a database on the has to be used for my company. So that's kind of the sense is always happens like that is the same for the Regis. So we are going to the plugable architecture helps to absorb to such a difference as a developer's choice. However, we should remove to the pain for the developers, like such a too many choices, but we can be the simply configurable for the such a choices as a developer's perspective. So it would be the I hope that is a kind of the way of the solving to the such kind of the program as a choice. I think to add to that, right. You nailed it right on the head, Brian. We choose the right technology for the requirements that we have, right. What those requirements are determines what the right technology is. And that's the reason that we need some sort of integration sort of framework is because certain use cases will require different ledgers. And that's okay. Right. We're in a space where one what is it one ledger doesn't rule them all. I think we're in a spot right now where you know there are prototypes and in some cases active production blockchain deployments in a lot of different industries. Some industries, some use cases, some supply chains don't yet have a blockchain in production. And so they still have kind of the freedom to choose a technology. But I imagine, you know, a few years down the road here, any business that is larger than a couple of dozen employees is going to not have necessarily the freedom to choose which technology they're going to be told. Here is the standard payments rail. Here's the standard, you know, supply chain traceability or the two or three supply chain traceability networks that you're expected to be on if you're in the diamond industry or the electronics industry or whatever. And so the reality will be that there'll be multiple options out there. And so this is, to me, it sounds like it's a toolkit to make that kind of world easier to deal with than one where you have to come up and be an expert at the fabric in Bezu and Corta simultaneously, right? So is it really less of an interoperability play and more of an integration kind of thing? Tracy, do you want to speak to like maybe the difference between those terms? Yeah, I think that's an interesting question, right? And I think terminology will always, always get us. So if you look at the dictionaries, I've been working on some work that actually required me to go look up these two particular terms, right? Interoperability is about the exchange of data or the use of data that's being exchanged. Interoperability, I'm sorry, integration is about bringing together multiple systems, so smaller pieces of systems into a larger system. So going back to your question, right, where you're talking about different letters for different ecosystems, what we're looking at doing is building an ecosystem of ecosystems, right? So that network of networks, as Shingo had it on his slides, but really we're looking at how do we bring all these ecosystems together so that they can communicate, exchange assets, right? When they may be very different sorts of solutions for the particular, you know, place that ecosystem that they're trying to solve. Very frackled. Very interesting topic about the interoperability decisions. So because of the interoperability in most of the standardization would be more like semantics or data formats or such a kind of sense. However, as Tracy mentioned, that is not the issue I guess. So because of the blockchain is the kind of the one world that can be already completed within that region. However, as a real world perspective, we need to somehow to do, we cannot live with one single region or asset. We need to buy the money and food and some sort of the different industry involved in the real world. So these are the cases. Well, integration is helpful for the case. But the important point would be the solution cannot be the one. So we cactus is the concept of the arguing to the multiple choices, even the same combination of the region one and region two. We need to have two different solutions could be co-exist. Like we need to choice of the merchant for the buying to the same product. So that is the same concept for the blockchain world. So that is kind of actually stimulated more aggressive for the market for the trading. I hope that is kind of the ideal world for the blockchain as a token economy as a common word. So that is my understanding of the distinction between the intervality and the integrations. Right. It also occurs to me just now talking about this that there's one thing that I think cactus if it's successful can really help us with which is technologies have life cycles. I still have a VCR here, but I can't really say that I watch a lot of videotapes. And I mean, it's one thing for us to no longer use VHS tapes and instead to be using Blu-ray disks and instead of Blu-ray disks to be using Netflix. Right. But these asset kinds of ledgers and these systems, I mean, people haven't really thought about life cycles of these technologies yet. And what really happens at the tail end of a life cycle of a blockchain technology? Right. I think we've been through this Cambrian explosion of a lot of different technologies out there, but haven't really started to think about how do we gracefully, you know, exit a blockchain system for an enterprise that has assets and information and this kind of runtime dependency upon this shared resource? Because inevitably, there'll be a calling of these different platforms inevitably, you know, options explode and then they consolidate, they explode, they consolidate. So one thing cactus might help us do in the long term, I think is have a graceful kind of exit for certain blockchain networks into other more leading blockchain networks where there's more activity, right? And make it easier for enterprises to gracefully stage an exit because not everyone's going to be able to dump an old technology all at the same time. And you won't always be able to just do a hard fork, drop the hammer and cause an entire marketplace on Tuesday at 3pm shift from one technology to the next. And so maybe cactus helps us with that kind of graceful kind of transition for older technologies. We have just a few minutes left. Any kind of closing thoughts on from either view on ways that we can work together as a community to push cactus forward and get it to a production state and to be creating some real value for the blockchain community? Well, we have the, as you can see in the weekly page of the cactus, we have the weekly call for the call contributors for the code basis. So we have not only the code maintainances, we are still the discussion about the technical topics, right? As you mentioned, the traditions are from the regular blockchain to the new blockchain system, like for the post-quantum cryptography use or such kind of things. That is some sort of the academic perspective of the use of the cactus. So that kind of the discussion will be made for the weekly basis for the across the regions. We also have the contributor from the European the communities. So we have a slide, the second, that is not the weekly, but we will the scheduling for the US, Japan, US-Asia region friendly and the US-European friendly time. Sometimes they're traveling to the such meetings for the to sneak around, but that is a very good opportunity to join such a discussion. So if you are not willing to the actual coding, but you can have still the space to move into this work. So that is my introduction over the activities. So please join us. That is my last word. Thank you. Great. Tracy, I think that's so key. It's not just developers that we're looking for at this point. It's people who have some ideas about the way that this should work, have particular examples that they can bring to the community. The ideas are really key here. This community is, as I mentioned, still an incubation. You can get in on that ground floor, bring in your ideas, bring in if you want to be a coder, help contribute to the code, but there's obviously documentation that needs to be done anywhere that you can think of that, that you want to contribute. There's places for you to join and participate and come join us. That's the best I can say. If you join us, then you actually have a saying where this goes. Very cool. Well, Shingo, Tracy, thank you very much and thank you to all of you for giving us an hour and hope to see you all at a future Cactus Working Group developer call or on the mailing list or on Rocket Chat and see you all later. Thank you. Yep. Yes.