 OK, so thank you for joining us. Originally, we have a plan to introduce IBC at first by Geoffrey. And then I'll introduce our current product, base IBC or public IBC, of course we won't. But we will call Geoffrey now. So I want to start our session. OK, so I skip an explanation for overview of IBC protocol. Sorry, but it's a Geoffrey part. So I start my session about our product about IBC. So base IBC, public IBC, cross framework, or public IBC, sorry for this inconvenience. So before my presentation, let me introduce myself. I'm Ryosato, a senior blockchain architect at Data Chain. Data Chain is a tech startup working on interoperability solutions for blockchains. And I'm working on open source products we have such as public IBC and also these several interoperability projects. So I'm going to talk about the design of IBC modules, such as base IBC and public IBC. Then I will show you an overview of our cross framework, which provides a cross-chain operation, like a mix up on top of IBC. Finally, I'd like to introduce our current work on hybridization loss, OK? Sorry. OK, so IBC utilize cross authentication for verification, which means that your voice on-chain live client provides a header on the state in the JX. Also, there's a relayer that fetches and relays how to go in pockets between data X and Y, as well as block headers of each blockchain. A pocket consists of a payload from one blockchain to another and a verifiable proof for it. There are two important functions to achieve cross authentication, namely verifying membership and check header. These function names are actually a bit longer, but we are simplifying them here. In the receiver chain, measure Y on this line, check header is keeping a header of measure X and updates current state on measure Y. Also, verifying membership is keeping a key value pair and its proof, then verifies this as a pair exists in the measure based on the proof. These functions should make use of underlying measure structure. So we design and develop such functions for the hyperledger base and hyperledger fabric. So I'd like first to explain the concept of base IBC. For hyperledger base, the grant works in a similar way as the live grant for Ethereum works. In base, a block header contains a root hush of a macro tree consisting of all account stretches. Each contract's account stretch is also a macro tree and proofs for a key value pair on each stretch can be obtained from base nodes. As such, grant state maintains a root hush of a specific contract account and updates it on receiving a new header. A specific key value pair can be verified with its macro path and the root hush. So verifying membership verifies a key value pair with its macro path and the root hush. So IBFT2 base consensus algorithm features a dynamic var data set. So we also need to verify it. In base IBC, a var data set is verified in check header. In a full node case, verification of such a dynamic set is easy as you can verify a newly-elected bar by checking the problem of the last var data sets. However, this is not the case for inter-block chain communication. Typically, not all block headers are presented. We think it is not realistic to relay all the block headers between two regions. So we introduced a trusting period inspired by Tendermint and Cosmos. Here, we have four varities A, B, C and D for a valid block header. Then another block header with var data A, B, D, F is received. If the interval between these two blocks is in the trusting period, we can say A, B and D are trusted thus skipping verification of these three varities. I think this is a reasonable assumption and convenient for lightweight verification. These refer to our documentation for modules. Okay, so let's move on to Fabric ADC. Hyperledger Fabric manages a world state differentiating from Hyperledger base. Since Fabric does not provide inclusion proof for its tree structure, we need to come up with a different idea for verifying which state. Fabric IBC utilizes proposal response or read-write set for verification. The basic idea is that if you query a chain code, you will get a read-write set for corresponding tree value pairs with an endorsement signature. We use this signature as membership proof in Fabric IBC. Here, in Leisure X, Relayer invokes a chain code to query specific key value pairs to its world state and return the proposal responses from endorsers that satisfy an endorsement policy, make a packet to be relayed. Then in Leisure Y, the packet is verified using verify membership with an endorsement policy for IBC. Here, plant states use endorse set signatures for verification. So speaking of endorsement policy for IBC, Hyperledger Fabric does not support on-chain functionality of synchronization of an endorsement policy with other ledgers. Moreover, an endorsement policy can be dynamic on runtime. At such, designed to provide a policy as a property for client in Leisure Y. Namely, you can call create client to set an IBC policy and call update client to verify a new one with the old one and then update it. This policy should be designed to be compliant with the original Leisure X endorsement policies. The client in Leisure Y checks endorse set signatures according to this IBC policy for verification. Oh, sorry, Jeffrey. Hi, we change part-parts for that, okay? Yeah, please continue, please continue. Deeper sorry for I met a terrible network problem. Okay, so next, we would also like to mention how we make use of these IBC modules for cross-chain operations. We have developed cross framework which enables developers to implement a cross-chain smart contract on top of IBC. Cross framework mainly consists of two modules. The first one is a transaction coordinator. This coordinates a request to execute multiple contracts among blockchains. It authenticates each contract call within the request, invokes them and manage their results. The second one is a state store and this is a wrapper for the contract state store with a locking mechanism for enabling cross-chain transactional operation such as a two-phase commit. With this mechanism, we can first lock a key before updating, then after checking everything's went right, so we commit a new value to it. Cross framework supports an atomic commit among blockchains. For example, suppose we have two Leisure X and Y with two contract transactions A and B respectively that we want to execute atomically. If contract transaction A fails on Leisure X, the result of contract transaction B will not be reflected in chain Y. We believe that cross framework will further expand the application scenario of blockchain interoperability. So as a practical use case, we conducted a proof of concept using IBC modules and cross framework for delivery versus payment, DVB settlement. The 8-mix swap between asset and payment token for global trade operation. In this project, we teamed up with entity data, a company that has a blockchain-based trade platform. Here, the asset trading course is maintained in Hyper Leisure Fabric as a trade platform and the payment token is maintained in standard network as a payment platform. With cross framework, we can achieve a cross-chain atomic operation between two networks, thus mitigating the need for a trusted Fed party such as an SQL account. Also, with cross framework, we can reduce user interactions in comparison with another trustless method, HDLC, it requires both an exporter and importer to monitor the other party's transaction and respond to it appropriately, which results in a complicated use interaction during a trade. We believe the scheme that cross framework provides reduced burden of trade settlement. We continue working to commercialize this technology on a trade platform. We also seek opportunities to try it in other application areas. So lastly, in my part, I'd like to talk about our current work on Hyper Leisure. We have released our Hyper Leisure Lab called UE as an inter-verbal solution for the Hyper Leisure family and it includes related products such as Fabric IBC, a base IBC and called the IBC. We expanded this lab to add a framework for cross-chain applications like cross framework, as there are tools like X-Bowler for cross-chain transactions. They were initially developed and are mainly maintained by data chain for now. However, BNCAI is also supporting and contributing to the UE lab. So please refer to the lab page for more details. Okay, so my part is over and... Okay, can you hear, see my screen right now? So, yeah, okay. Let me start with my part of the presentation. Yeah, so actually for this session, with I and Liao San for data chain team, we'll talk about the IBC particle, how this kind of the IBC particle can be integrated with permissioned enterprise that the proxies can bring this kind of interoperabilities. So actually, it is a deeply sorry for that. I late for the presentation, so I will just make a very short introduction for myself and also the Benjie. I am the research director of the Benjie team right now heads for the strategy and also the technical research right now. Also the ecosystem development of Benjie, and actually Benjie is a high-tech enterprise in China. And we are also a co-debt team of the public blockchain project called RSnet. And we are also the co-debt team for contributing to the BSN Wenchang Open Permissioned Blockchain and also a blockchain project called IRETA Hub, which is focused on the interoperabilities. So, and Leo-san, you already gave a self-introduction before. Maybe you want to... Okay, I will move to the next page. So I believe that Leo-san have already introduced a lot about the base of IBC, fabric of IBC is kind of the module based on the IBC particle. So for my part, I will focus down the IBC particle. This introduction and also the differences and how this kind of the IBC can be applied in the infrastructure level. We practiced the IRETA Hub, how we combine the IBC and the I-Service, which is called the Inter-Service. So what is IBC particle? It is short for the Inter-Blockchain Communication Particles, which is proposed by the Cosmos project. And it's focused on the heterogeneous blockchain communications. Also, it assumes no topologies between this kind of network, how they are connected. So it is also a design idea quite similar to the GCP IP. So it is abstracted how the ledgers, how this connection works and how this data pack can be transmitted between the different networks. So here are also a picture that can show this kind of ability at the red corner of this slide. So each dot you can see here, actually it is a blockchain network. So each network can be connected with each other freely or trustlessly. That can almost, even it can become a circle that connected with each other. So it assumes not a hub-spoke topology between this kind of network. So it's really like a GCP IP, which can be fully leveraged in this kind of the question abilities. And for more information, you can also refer to this website. So what is IBC is and what is it is about? Actually, there are many kinds of misunderstandings about the IBC and also the Cosmos project. Well, the IBC protocol is actually it's not only about the application layer particles, like some people may argue that it only handles the asset crossing chance, the option, actually it is not because IBC is it handles the data transport and actually it's quite on the communication layer. So it can be verified trustlessly by another blockchain. And it's also not a top and also no route chains in this kind of networks. So it is also not a layer two particles, like we can see many solutions in the Ethereum right now. Going to this kind of architectures. So IBC, this kind of module actually has some core concept in the whole particles. So the first one is for sure is a ledger or we can call this distributed ledgers. It abstracted like we can see that ledger, it is a state machine and also it store a key value in this kind of a ledger. And we can go deeper into this kind of ledger. We can see the module here, which is the sub component of ledger. It handles the state transition between the state machine. And also we can see like many kinds of smart contracts can be seen as a module on like on a blockchain. So it is also a special module called IBC module, which is specifically handles the question transaction into ledger. So this is called the IBC module, which contains also another kind of components like the client, which is verify another, which is a client to verify another blockchain's transactions. Also there are connections to maintain the state, consensus state and also the channels for the message delivery ordering and also the like the authentications. And here is also another very important concept. I also noticed that already I have questions in the session six, what is a relayer? Actually a relayer is off-chain like client process that can just focus down the message transmit. So actually both the ledger A or ledger B do not need to trust the relayer because these two blockchains verify each other's transactions respectively. So relayer just a translist kind of a message to between this IBC modules and the client inside of this IBC module will verify the message from another blockchain. So both the ledger don't need to trust this relayer. So it is not a gateway or third party risk inside of the relayer. So if there is at least one relayer is working, the whole cross-chain work. So here is also a flow for this kind of transaction because of the time problem. I may do not have enough time to go deeper into this, but from this kind of flow, you can see that it's quite like the GCP IP flow because the message will go on the top level, go deeper into like the connection and also go to the consensus. And this kind of message will be transmitted to a relayer by a relayer to a chain B and the transactions will be handled through this kind of consensus on the chain B and also go up to the application layer on a chain B. So this is basically a transaction flow of this whole IBC process. So actually there are many kinds of differences between the IBC and other particles, like we also measured or compared with Polkadot and the Cosmos or maybe IBC. Actually it is not the same because the whole IBC protocol is the bottom up. Well, the Polkadot is more like a shorting protocol. So it is a root chain, but when you see IBC, there's no kind of this root chains in the enterprise blockchain. And we can also see there are many question projects like characters and beaver in Hyperledger right now, but IBC actually is not assumed that can connect with only permission blockchain but can also connect with permissionless blockchain like or even centralized system with using the protocol that's being proposed by the BNGAT. So here are two examples that actually I believe Nelson had already mentioned about the data chains integration with Fabric IBC and other modules. And another example I would like to share is that IRETA Hub can leverage the IBC and also the I-Service to connect with different blockchains like the public blockchain and the construction blockchain and also the legacy systems. So it leveraged mainly about two techniques. So if another blockchain that can already implement the whole IBC protocols, it can like the Fabric IBC, it can directly connected on the IRETA Hub we developed. And also there are also many kinds of blockchain that haven't been implemented the IBC protocol right now. So we also can leverage the I-Service on the IRETA Hub. And for this kind of module, we also use another tools called the, we call it for the moment is called smart relayer because it needs to know about the application semantics of the message it transmitted compared with the relayer, traditional relayer. It just don't know about the message what it's about. So you can hear, you can find more information about this IRETA Hub on the BSN environment. So this is a whole process of how I-Service can work between the different networks. So the service provider can register their abilities and their functions as a service on the IRETA Hub. And with this relayers which we call the I-Service over the IBC because IBC is a communication layer and I-Service more about the application layer. So this kind of service definition can be transmitted to another, which we call the app chain, another blockchain. And the client or user can request this kind of service on the app chains with a service fee that we can call this kind of service. And this kind of service will be information will be transmitted by the relayer to back to the IRETA Hub and service provider listen to this kind of information and transactions will get back to the response and the response and the result will get back to the client on the app chain. So this basically is a whole process of the I-Service. So with this kind of abilities, we are right now developing on a BSN network right now, the IRETA Hub can connect with a fabric using the model and it can be connected by the layer on the IRETA Hub, which we believe will be realized later this year. And with the smart relayer, we can also connect with different kind of permission blockchain like physical because superchain and other construction blockchains. But the users need to know about the service definitions through the smart relayer, but also can query many kinds of like the data form chain link also many kinds of service on different public blockchains. So it's quite useful. And we also, we are also implementing also kind of the application layer particles besides the functional token transfer. We are also implementing a question NFT right now. So you may see some applications about the empty questions, like between the permission blockchain and also permissionless blockchains connected by the IRETA Hub on the BSN environment. So this is because basically the contents I want to share for today. And at the last of our presentation, we also, there are some contact information about our two teams, Benji and the data chain. You can always find me here. Thank you. And that's also in a deep discussion. So is there any other questions besides the relayer? No question. No questions? I saw the question about the relayer. The relayer actually is not need to trust it. You need to trust it. Okay, so thank you for joining us. And yeah, if you have any questions, please contact us. Yes, thank you. Okay, bye. Bye.