 All right, welcome everybody to today's interoperability panel discussion on the hyperledger cactus weaver in U.E. Before I started, I wanted to see how many people attended the interoperability panel yesterday with Takuma, Rama, and Jim? Two? Three? Okay. All right, so it sounds like maybe we need to cover some of the same material that we did yesterday, but we'll see what else we can impart for those three of you who did attend yesterday. So first off, I'm going to start by introducing us. So my name is Tracy Kurt. I work for Accenture. I'm a technology architect there. I've been involved in blockchain interoperability since my first day at Accenture. I got an email from the folks there who were really interested in open sourcing the blockchain integration frameworks that they had created. And so that was really the first kind of task that I was given. How can we open source this? And so we brought that to Hyperledger Labs, which blockchain integration framework eventually became hyperledger cactus. So that's how I'm involved with the interoperability space. Takuma, would you like to introduce yourself? What are you working on? Okay, thank you. So my name is Takuma Takeuchi, and so I am a maintainer of hyperledger cactus and the new name Hyperledger Cacti. And so I'm also working Fujitsu as a blockchain research manager. So with the experience of the hyperledger cactus, Cacti and blockchain interoperability, so that I would like to accelerate the token economy technology beyond the various industry. Yeah. Okay, nice to meet you. Hi, I'm Rama. I've been a researcher with IBM for over a decade. And I've been working on hyperledger technologies mainly fabric since its inception, been interested in interoperability since around the end of 2018 and worked on the Weaver before it was called Weaver. It was an internal IBM research project and you open source it about a year and a half ago and interested in all things interoperability. Okay, so my name is Susumu Toriyumi, VP of Product at Data Chain. Data Chain is the main contributor to the Hyperledger Lab called UE. So we are working on the subject of interoperability for more than three years. And last year we have decided to contribute to Hyperledger under the name of UE. UE currently supports the Hyperledger public, Facebook, Koda, Iroha and Koram. And it aims the trustless interoperability solution for networks or blockchains. Thank you. Alright, so I thought maybe we should start with a definition of interoperability. So Rama, I know you've said your definition a couple times already during the conference, also at Member Summit. Tell us what you think interoperability is. Interoperability to me is the way to, when it comes to decentralized ledger systems, is the way to scale up decentralized trust without forcing the networks to integrate or give up their sovereignty, that is integrate in the sense of having to merge together or coalesce into a single network. Interoperability enables two networks to work together in order to conduct transactions when they need to, as they need to and which are completely under their control, that is in an on-demand manner. And there are several different patterns and several kind of base use cases where two distinct networks need to link in this way because there are transactions that cannot afford or in the real world that cannot, just cannot remain within their network boundaries. So interoperability is an absolute necessity here. Now, what we've been seeing the past few years is people have been building networks, especially permission networks, as sort of a minimum viable ecosystem. They've been going slowly. They've been picking small problems and small, and portions of business workflows to run a smart contract within their respective network. Now that the experiments are over, people are now finding that you can't afford to leave these networks, remain in silos, that is in a fragmented manner, and you cannot have their assets be disturbed within the network boundaries. So interoperation is the way to enable the existing networks to come together to link when they want, as they want safely and in a decentralized manner. So Sumo, would you add anything to that? Yeah, I couldn't agree more. At Data Chain, we have a vision of the many, many blockchain-based system, whether it's public or enterprise, working together and interacting with each other to fulfill the complex tasks without losing consistency. It will include the security token dividend, trade finance, or insurance claim and payouts. And the simplest example of such interoperability would be the delivery versus payment of the digital asset. So we have one party transfer the digital asset to another on one blockchain, and the payment is on the other blockchain. So even in this simple setting, without interoperability solution or careful design inconsistency or double spending may occur. So I think the interoperability is an essential piece for the complex tasks like leveraging DeFi from enterprise systems. So yeah, I would say interoperability would be the must for blockchain to realize its full potential. And Takuma, would you add anything to the definition of... Yeah, so I almost agree with the two definitions, but I'd like to add a short definition. So in my sense, interoperability is exchange formless or intangible value across the multiple industries, multiple industries areas. So traditionally, asset exchange means equal to money exchange, but today in this area is not only money exchange, but also formless value such as NFT or environmental value or something. So interoperability is an essential piece to achieve this exchange formless value. Great. So hopefully now you guys all know what interoperability is, so we can base our kind of future questions and answers based on that. So I know when we at Accenture originally contributed Cactus with Fujitsu, part of the contribution was around the overlay network that we had within the two separate blockchain networks that we were trying to interoperate against. So Takuma, tell me how has Cactus changed and what is Cactus today as we look at the project as it stands? Yeah, thank you. So as you know, the Cactus is... So last month, the Cactus became version one and in three days before, the Cactus became the Cactus with Weaver. And so in my understanding, the version one is not the goal, but only the start point because there is a lot of... There are many blockchain interface today. So I think the interpreter user is very confused because what are you... What two should I use? So in order to break this situation, I think it is the merging of the interoperability project is very important. So firstly, Weaver and Cactus is merged to the one project in this time. Great. And Rama, tell us what Weaver brought to Cactus. Okay, so... Or I should say now Cactus. Can you tell me about it? But what did Weaver bring into Cactus? So the Weaver design philosophy as we envisioned it was involved keeping... Weaver sort of value add to any existing network. So what we wanted to do explicitly was to avoid having... Avoid the networks having to fork the DIT stack that they were building on and to avoid adding any components that would increase the trust footprint because any blockchain network is a really complex beast and there are a lot of... There could be a lot of vulnerabilities in any blockchain network. I think... I don't know how many people have done security analysis, but Fabric Network can be a... For example, can be a security analyst nightmare with ordering servers, with so many peers in different roles and so on. So what we wanted to do explicitly was to avoid adding anything that could increase the vulnerability of a network. So we introduced components called relays, which you can also think of as gateways of the kind that Raphael and Denakaran talked about in the previous session, which act as conduits or ingress and egress points for any network for cross-network communication. Again, when I say cross-network communication, it's communication with any external entity, the other side could just be a centralized entity as well. And second, the protocol units that are behind the relays in the networks, they are engineered according to the native smart contract or distributed application logic of that particular network. So like in Fabric, the end, whatever the network does, it does via chain code. So it does it the same... any transaction processes as part of a cross-network transaction is going to be endorsed and ordered and committed just the way any other Fabric transaction is. And that allows us to have any cross-network transaction be as decentralized and as trustworthy as any of that network's native transaction. And the relays that are going to communicate messages, they need to confirm to some kind of standard that other relays can talk to, but they are not going to be trusted for any other purpose. So in our protocols, the relays are not trusted for confidentiality nor for integrity. So relays cannot mount when the middle attacks, for example, nor can they exfiltrate data. So these were some of the... these two components are what I'll mainly highlight, the relays and the interoperational modules as being a big value add when it comes to maintaining... to performing secure cross-network transactions with adequate level of decentralization. Great. Thanks. So tell us about UE and how it differs from what you've heard of this description here in cacti. Obviously also with the research that you've done previously with the work that's being done in cacti. Yeah. So as I understand it, one of the great features about cactus or cacti is that it has a pluggable architecture. So it adopts any type of interoperability, including notary scheme, hash locking, or relay scheme we've attached. And that goes the same way for the messaging layer as well. So developers can bring their own protocols for messaging layer in cacti. But at Data Chain, we believe the relay and light client method is the most secure and the most feasible option for even in enterprise settings. So there was don't trust, verify, go. So also we adopts the IBC, Interblock Chain Communication Protocol, which has several characteristics like reliable transport, authentication, and ordering, which enable the general cross-chain applications. So I think the cacti conceptually is a very generalized framework for blockchain integration, whereas the UE is putting more focus on the communication with a set of concrete protocols and specifications. So not to put you on the spot, Susumu, but I'm going to anyway. UE, do you ever see it integrating and coming into cacti, right? That's a good question. And as I mentioned before, that cacti is very generalized framework and UE is very specific to communication with a concrete protocol. So one can imagine the combination of two. For example, cacti with plug-in of UE installed. But unfortunately, as far as I know, there is no specific customers who would like to have two technologies into one place. So suddenly I must admit that we are not currently working on cacti integration. But to me, it would be very exciting to see developer communities can work on the UE plug-in for cacti. Great. Thank you for allowing me to put you on the spot. And thank you for the honest answer, right? I think it's important for us to recognize that there are many different ways of doing interoperability and that sometimes they don't interoperate to say that poorly. But anyway, I guess the next question, Takuma, you had mentioned the version 1.0 for cactis. Talk to us about what you see in the roadmap for 2.0 for cacti. Yeah, so cacti version 2.0 is, of course, the version, the technology of cactis and cacti. So to be honest, we are now designing the roadmap of the version 2.0. So we are the merging of the cacti. So I think it is needed to sort of the device in the existing cacti. In cacti, we have architecture and API and some features. So I'd like to go forward too. I'd like to make a better interoperability tool than the current now. So we are now sort of revising the architecture of some things and we are now making the roadmap. So the roadmap is fixed. So we will announce it later. Yeah, thank you. OK. There's still being work done as far as what's going to happen. Any sort of specific work that you'd like to see go into that roadmap when it comes to adding weaver into cacti and the version 2.0 for cacti? I think I'll just be happy with the platform that looks coherent where we can point to, OK, here's the common substrate on which we can provide a spectrum of features for, let's say, the validator modules, which are somewhat different in cactus and weaver. If you can bring them all together and then build a base on which we can then go and have people develop more new features, support relays, and different kinds of plugins, like UE plugins, I'll be happy with that as the next iteration. Apart from that, yeah. I mean, in weaver we have been working on some other features that still remains. I think we will continue to work on those after the merge as part of cacti. You want to tell us about what those features are? Sure. Yeah, actively, I mean, we've been working on adding decentralized identity support as a trust enabler for two permission networks. I think it's more crucial for permission networks to have that. So this is something that we have published in research and there's a grad student who's been working with us on this for a couple of years now. There's a POC build, but we haven't yet fully built this into weaver. So I guess we are working on one portion of that right now. I think we'll get that done before the merge into cacti. But after that happens, I think we will offer a solution involving dead registries. It's sort of a more ambitious thing, because the way we're building it for the solution to work and be adopted in the industry requires a lot of purchase. And I think there have been a lot of presentations on decentralized identity. So it's not quite a settled topic yet. And I think even the W3C recommended the drafts just reached recommendation status just a couple of months ago. So I think both of these things are going to go hand in hand. The evolution of decentralized identity and blockchain interoperability. But I think there's some biases there. Both are crucial to each other. Great. Thank you. Susumu, what interesting and new features are you working on within Ui? Yeah. So light client-to-lead as I mentioned before is arguably the most secure way for interoperability. And at the same time, we see a lot of hacks, especially in a public space with a simple notary scheme. So by the way, that I think represents the difficulty of having trusted third party for exchanging information. Anyway, light client and relay is also said to be difficult. And the on-chain verification process requires computational cost and block size. So we are right now working on the LCP, which stands for light client proxy, which is a combination of Ui, IBC, and security enhanced hardware. So what it basically does is that we substitute the on-chain verification process to the security enhanced hardware. So without sacrificing the trust minimized assumption thanks to remote attestation technology. Currently we are working on LCP to apply to enterprise stablecoin and security token DVP swap later this year. Also we are considering applying LCP to build a bridge between Ethereum 2 to EVM-based public blockchain. So we can provide the interoperability not only within the enterprise blockchains, but also with a combination of public and enterprise blockchains. So I think we can hopefully share more information than the lessons learned in the coming months. Great. So Rama, back to you. Tell us about kind of the process of bringing the Weaver code and merging it with Cactus to create Cacti. What was that like? How challenging was that? Just tell us about the process. The challenge shall continue. We've been having almost weekly meetings for several months and thanks to Peter, Sakuma, and the rest of the Cactus team for being so cooperative. Initially we started just doing a deep dive into each other's designs and code bases. We have a kind of vision and I think we are still aligning with that vision which is that there are cross network communication elements that we can kind of merge together into a sort of communication appliance. I think the Weaver relay which Peter who unfortunately could not be here did some investigation on this and he found that the relay could be embedded into a Cactus connector and that could be used as sort of a communication appliance for network. There's something that we're going to talk more about standards which Dinakar and Rafail talked about. This sort of appliance can and should confirm to standards that I agreed upon by the community. So we have communication elements that we can merge. There are the inter-operation modules that Weaver brings which are really the equivalent to the validators that Cactus provides. They have somewhat different philosophies when it comes to generating data state proofs or validating state proofs. So there are reasons to pick one or the other in a given scenario. There's a spectrum of different solutions that one could envision using in production. Some which involve more security or less trust in particular components. Some which involve better usability or less adaptation required in the network that's already deployed. So we want to offer those kind of features or different kind of validation logics as a factor or a set of possible options. And then we want to merge the APIs and the libraries that Cactus and Weaver have respectively built for developers to exercise or to trigger any crossover transaction. And that we can merge and offer as a single unified API which you can use which any user of Cactus API can use and trigger a particular kind of transaction. And these transactions will come in particular types like asset swaps or transferring of asset from one network to another or the communication of a legislative record from one ledger to another. So there are some things that we are working on merging other things which we are working on aggregating and hopefully that will bring to put together a common coherent platform. Someone's down the line I think. All right, thank you. And shout out to Peter if you're watching either on the recorded video or live. We miss you here. We wish you were up here with us. He was supposed to be here with us. So just wanted to call him out as Ramva did as well. So Takuma, question for you. Is there any business proof of concepts that are currently using Cactus API? So there are several proof of concept cases. So first case is environmental. So this is introduced in today's afternoon session. So now this is using cacti2, the taco, the environmental issue. So the connecting to the environmental value and the CO2 accounting. So this is the POC with IHI, the Japanese heavy industry company. And the second POC is the cross-border financial. So this is POC with Asian Bank and so the four blockchain companies are collaboration. So consensus in R3 and the Soramitsu and Fujitsu. So this is the cross-border banking is the second example. And also the cacti provides some example code on several areas such as the supply chain or carbon accounting and so the cart rate and power trade. So I think this is the key to the considering about the new use case. Thank you. Thank you. So Susumu, it wasn't a question on the piece of paper but any sort of use cases that you can talk about that exist for UE and how it's being used today? Yeah. So as I mentioned before, you can be used for general cross-chain application but the demand is from the token transfer right now, just token transfer. So DPP of digital assets, we did with entity data, Japanese system integrator about the connecting trade platform to the payment platform. So we can change the asset ownership on one side and the payment is done on the other. Also we did some experiment with the JCB, Japanese credit card brand with multiple stable coin platforms and basically we would like to exchange the two different kinds of stable coins via liquidity and atomic swap. So these are the things I can share right now and hopefully we will see the application of general cross-chain application. Thank you. Rama, I think yesterday you said you couldn't share those things that you're working on. Okay, there's one. I don't think I need to talk too much about it because if you plan to attend the token workshop tomorrow, you'll get a much longer and more a bigger exposition of that. So do it in that. Just in a nutshell, there was an experiment done by the Bank of France and HSBC together that involved networks built on both fabric and Corda, either running, one of the networks was running, was managing securities like bonds and another was managing CBDC and there were a variety of use cases that involved the two networks having to interoperate either to do interbank settlements to enable coupons to be redeemed across network boundaries and for, yeah, I mean, the case that Susumu mentioned earlier, DDP, which is a delivery of a bond versus a payment on a different network. So what we've seen in the past year and which has driven interest in Beaver and actually in other platforms like Cactus and Imagine UE is CBDC, Central Bank Digital Currency because the very central banks as well as the other retail banks that are regulated by the central banks are really interested in how they can use how they can adopt CBDC for more efficiency but how also can they make it easy for the different platforms like the wholesale CBDC networks and the retail CBDC networks to work together. So you're going to have different networks, they need to interoperate, so they're shopping for different kinds of solutions and Beaver was part of one such experiment last year. There are a few that are ongoing this year which unfortunately I cannot talk about but hopefully soon. Okay, great. So as far as contributing to these projects, I know for Cacti, there are daily pair programming calls that are held, there's weekly calls that are held with the maintainers, obviously good first issues, those sorts of things, anything else, either Takuma or Ramla, you would add on contributing to Cacti and how the people here in the audience or the people watching on the video could participate in the project. Start with you, Takuma. Anything that you would add as far as ways that people can come in and contribute to Cacti? Yeah, so after becoming Cacti, we are always waiting in Discord and so your contacts, please feel free to contact. Discord. Discord, yeah. Great. Ramla, anything else you'd add? Not really, I think one of the benefits of bringing you with Cacti is we can grow our community otherwise it's been mostly an IBM project so far. So it's great to have the, you automatically gain a bigger community by joining with Cacti. So Sumu, how do we contribute to UE? What is the way to get involved and participate in what you guys are doing there with UE? Unfortunately, we don't have the regular community call or discussion like Cacti, but yeah, we are always open to the contribution from developers so please visit GitHub and I think there is very detailed documents right now so that you can start coding soon. So yeah, please visit the GitHub page. So that's all the questions on my piece of paper. Questions that any of the audience members has. There's a microphone there in the center if you have a question for any of the panelists here. Charles from here. So the question I have is with the Cacti is there any questions that you have about Cacti? No. No. No. No. No. So with the Cacti flexibility, it can do everything. Do you see it staying at that level or do you see a handful of things like UE perhaps different things but more specific applications being developed or do you see that people will just take Cacti and use it, adapt it to their own project and that will be the end of that thing. Rama, you want to start? The question makes sense. Yeah. I think you're asking if Cacti is sort of a jack-of-all-trades and will UE as a specialized project? I mean, yeah. So, okay. The way I see it is when we're building Cacti, we're not offering a very blunt hammer that can hit any nail. It's more like we are clearly defining what use cases we are solving. How the protocols that we are providing or the capabilities we are providing in Weaver solve the problem for you in a way that maintains both decentralization and does not expand your footprint of trust and it's, again, there's usability which we are still working on but assuming you provide that then it should really be quite easy for you to take the Cacti SDK and then import the components that you need to configure them, use the library packages, and then adapt your applications in a very minimal way in order to engineer the application. It's very similar to how you would use, say, Firefly because Firefly offers a good developer experience and but even there, I imagine you have to adapt your client applications to confirm to import the Firefly packages, right? So that will be there and we are going to make our best effort to add all the features at the right granularity that can be used by any distributed application that needs cross-chain communication or cross-chain transactions. So I think I didn't actually express my question very well. I didn't think I did when I was asking. But the question is really, do you anticipate seeing a handful of labs project, perhaps, like UI, three or four things that are... Here is a pre-configured preset up. We've taken the SDKs, we've done the adaptation work, we've set it up for a particular kind of use case or approach and lots of enterprises will pick up that rather than... Or do you see enterprises developing their own solution each time? So will there be patterns that are developed that people can just pick up and use as they exist for their particular use case? So will there be a pattern for interoperability type X or interoperability type Y that people can say, OK, this has already been done once? I can use it again and write out a box. I don't see the difference between a platform on that dimension. I think it's more about... UI is great if your network already is compatible with IBC and you want to be able to interoperable with another network that's also talking IBC. What in Weaver and Cactus we are offering is the ability to be interoperable if you are not. If you have not thought about interoperability at all, suddenly you discover there's a case, there's a reason for you to link to a different network, what kind of solution can you use? You can of course pick, choose to, let's say be part of the Cosmos ecosystem, build importer, run a relayer that talks IBC protocol like UI provides, that's a valid way of doing it. Cactus and Weaver offer a slightly different approach that we don't require you to talk the IBC protocol but you have to install a relay that can talk its own protocol which again we are trying to promote standardization of that API but that's some ways to go now. Thank you. Thanks, Charles. Yeah. It could be a repository of different types of protocols and different use cases using those, in this case the application, the higher level using these protocols. At which point it becomes unmanageable and as a single project there's something you'll have to use. Maybe that's your question, right? Will it be a single hammer that will be used for all interoperability applications or you'll have custom things based on some base layer protocols? Yeah, I think that gets out of it. It's basically we'll cactus. You can use cactus to make a lot of hammers. We'll cactus, you know, provide a hammer shop with a collection of those hammers that have been made. Will you manage those as projects or will you just say no? You go and do your own, someone else can handle that. If someone has done what you need, go find them and copy their work. Yeah. Or will that be managed by cactus as a user? Sorry, I don't want to monopolise this, but... Yeah, yeah, yeah, sorry. Okay. So monorepoise, so based on the NPM structure, so this can be combinations, so not only the type escape, but also the term last or another language. So basically, so cactus is written in type escape and Viva is written in... Viva relay is written in... Sorry, last, but we can coordinate with so the monorepoise structure, yeah. So I think one thing which you alluded to earlier was interoperability among interoperability solutions. So this... And we talked about this in the member summit a couple of days ago. There are several interoperability solutions that sprung up in response to the need for interoperability. Now what do we do? Do we try to make these interoperability solutions interoperable when there's like turtle all the way up or down, right? So what do we do? I think I don't have a good answer to this, but I think there are certain... As long as you have a limited number of such interoperability solutions that all solve the problems, that cover the problem spectrum that anybody needs. And I think both Cosmos and Viva, Cactus, combination, they do... they solve all the range of problems that you need. If not, in practice right now, they will because it's part of their vision. So I think you can use any of those solutions. What you may need is the ability to interoperate with the limited number of such solutions. Like the Susumu mentioned, a UV plugin within cacti or a Polkadot bridge within cacti. So these are the kinds of things. As long as you have them, I think if your network is already using a particular interop solution, you need not fear about being able to interoperate with another network. So I know we're at time. Just to call it out before you ask your question. So feel free to, if you need to, leave. But I do want to say, Charles, just to your question, if you have a hammer you'd like to sell, there is the lab proposals that you can do, obviously, to bring that code to make it open source. And I think that's definitely a worthwhile avenue to approach selling of that hammer. No, I understand. But I want to make sure that everybody is aware. You can contribute to a lab. And then at some point, if we decide that it makes sense to bring that hammer into cacti, then we can do that. And it's just then a discussion of, well, here's the source code, here's how it's going to fit and make that happen. So last question to Rafael. I think the more hammers the better, at least in any initial stage. It probably comes down to the trade-offs between blockchains. There will always be more than one blockchain due to the trade-offs of feature, digitalization, security, scalability that they have. And I believe something similar could happen with interoperability solution, especially if we consider that those are often used for scalability purposes as well. So not really a question, but perhaps a comment. Possibly we'll have interoperability solutions with different trade-offs such as decentralization that are not captured right now by these more generic frameworks like cacti or more specific frameworks like UE. And probably upcoming standards will also have a saying on which ones are more easily adaptable to the market needs and to regulate their needs. So I would also like to have an answer for that or to know an answer for that, but I think it's something we are trying to discover on the way. Thank you, Rafael. Thank you. Thank you to all that attended here, hopefully the three people who raised their hand at the beginning actually did get something different out of this conversation. Thank you to the panelists for participating and we will let you go and have a fun for the rest of the day.