 Hello, everyone. I'm Tatsuya Sato from Hirachi. Today, I'd like to talk about 12 fully decentralized system with Hyperledge Fabric Equipment and Nurses of decentralized system configuration and operation and potential use of a decentralized system operation 2 of CSC. Here is an introduction to this presentation. Target system using Hyperledge Fabric. Hereafter, we call Hyperledge Fabric just a fabric. Also, we call a system using Fabric, Fabric-based system. Fabric-based system provides the value of executing across multiple organizations in a decentralized manner. To maximize the value, it is essential to decentralization not only in the execution system, but also the entire system, including system configuration and management. However, there are gaps between them. And it may be a disincentive for production use. So in this presentation, 12 fully decentralized Fabric-based systems. First, we try to analyze comprehensive basic requirement for realizing fully decentralized Fabric-based systems and design a reference architecture to satisfy the requirement. And then, we will demonstrate the applicability of CSC, which is a decentralized system operation 2 to add achieving some of the requirement on management perspective. First, let's briefly review Fabric-based systems. This slide explains execution system of Fabric-based system. And here is an overview of a Fabric-based system. So each organization form a trust domain in Fabric. In other words, organization is unit with participant independence. Also, from version one, Fabric introduces execute order-valued architecture, which enables transaction across multiple organizations with increasing scalability. In this architecture, Fabric separates the trust model into two parts. The first one is ordering service, and second one is transaction validation. So trust model for ordering depends on communication protocol, and trust model for transaction validation depends on endorsement policy. Next, let's explain about management side of Fabric-based system. Fabric manages chain code, which is the Fabric smart contract and the laser for each channel, which is Fabric subnetwork. This figure shows an example of a Fabric-based system with a small management path. And shown in the figure, in Fabric can update the configuration by the combination of Fabric CLI sub-command, executed by each organization. And it needs to coordinate across multiple organizations with config parameters, like chain code definition. Internally, Fabric issues special transactions and store the configuration on chain. So typical steps to update the config here. OK. Then let's discuss about trust model design in Fabric-based systems. So the level of decentralization required for Fabric-based systems depends on assumed trust model and configuration. In the past, the main focus on have been on enjoying decentralization in execution system, mainly this part. But in secret trust model, decentralization in the management system become also important, this part. Now, let's consider about some trust model as example. First case of consortium is here. In this consortium, transaction participants are not trustable each other. This is very, very cheap. And the consortium has a single consortium owner, which has their consortium. In this case, if the owner does not participate in the transaction, other participants can trust the owner because owner has no interest on transactions. In this case, centralized management by owner like this would not be a problem, again, because owner has no interest on transaction. The second case on the other hand, the consortium owner also participate in the transactions. In this case, other participants don't fully trust the owner. In this case, for management side, if centralized management by owner is executed, the owner can control the blockchain network to its advantage. So such centralized management would not be acceptable in this case. So in stick up trust model, one of the challenges is that can it be completely decentralized, including management. The next topic is related work. We could find some activities that focus on certain aspect of based blockchain based system and mention enjoying decentralization. However, there are no lack systematically organized requirement to achieve decentralized or permissioned blockchain or fabric. So our motivation is to know comprehensive requirement for realizing fully decentralized public based system. In this part, we try to consider basically comment and reference architecture of fully decentralized public based systems. We extracted the full basic requirement for decentralized public based systems based on both related work and our experiences findings. We categorized statement and important description in related work and consolidated them as a basic requirement. The perspectives of the basic requirement are following. I will explain perspective one by one in subsequent slide. The first perspective is ID, identity, that is ideas to identify participant and node in the blockchain network and method of managing them. Requirement for the perspective is that unit of stakeholder, business, individual should have an independent root of trust. Left part shows typical case of inter-companies. So in fabric, a share acts a root of trust. This is one important point. And if there is a conflict of interest regarding transaction, the share should be separated between companies like this. Right shows another case that stakeholders individual and the single owner of the consortium. As a back practice, if owner issue ideas for all users, the endorsement on the consortium makes no sense because the endorsement is executed by a single organization. So as good practice, each user should be considered an organization and has its own share. Second perspective is transaction execution, that is execution and management method about the blockchain network. A requirement for the perspective is that all transaction should be processed by a significant number of organization with identical result in each organization. So as shown in the figure, a fabric-based system should have proper endorsement policy set in and chain code design, including private data and ordering communication protocol with accordion single point of trust parts. Third perspective is management and governance. That is management of the blockchain network and governance of consortium. The requirement for this aspect is that management and operation related to the consortium should be decided, performed by multiple organization and processes and operational history should be transparent. The left part shows back practice. So as shown in the figure, inter-organizational operation is decided, performed by single organization of one in a centralized manner with centralized script. So as good practice, inter-organizational operation should be performed by each organization's admin and configure parameter should be coordinated among organization. Also, it needs to endure transparency of coordination process, coordination process and operational history. So the last perspective is system configuration. That is configuration of the blockchain network and the blockchain-based system. So a requirement for the perspective is that the configuration must be such that data on the laser cannot be changed without the agreement to multiple organization. To do this, the configuration must be considered on ownership and management setting to mitigate and authorize the data modification for example like this. Also, the system must be verifiable and detectable in case of unauthorized data modification, for example, with comparing a laser. Next, we try to consider reference architecture. The goal here is to elaborate on a specific architecture of fully decentralized public-based system. However, the basic requirement to abstract to consider a reference architecture directly. So first, we try to specify the requirement from the architecture perspective, and then we design a reference architecture with specified requirements. And this is a list of specific requirements. So each specific requirement correspond to basic requirement and fabric component. And a specific requirement annotated with these labels. Label fabric means a special functionality that fabric should have as a blockchain platform. And Label machine is mechanism currently machine from official released functions. This is the overview of a reference architecture to satisfy specific requirements. Subsequent slide here explain the specific requirement part by part. This slide explain the base part of transaction execution system, ID, and system configuration. And during decentralization of the execution system required proper system design and configuration. Spot, single point of trust on the transaction processing must be eliminated. So to do this, first each O has its own independent share. And also the blockchain network has a BFT ordering service. We will discuss about the requirement later again. And furthermore, each chain code has an endorsement policy set in including private data to get agreement from enough organization's peers for BFT, launching for tutorial. And each organization should have its own API server to submit transaction to fabric network by themselves. For system configuration, it must avoid a single organization or admin's later becoming single point of trust. To do this, each component, especially peers on order share, is not owned or managed by a single organization. This slide shows an accomplished requirement with associated community activities. Mechanisms for achieving some requirement are missing. But some are being proposed, developed in the community, and will enable them to be achieved in the future. First one is for BFT ordering. In the consortium with low mutual trust, ordering should also have BFT. But it's not supported as of version 2.5. This is the next released version of fabric. Of course, consortium has recognized the realization of BFT order as a top priority for version 3 series. And specific future proposal and development in progress. And as another requirement, the system should be able to verify detect data cloud. But fabric itself does not detect data cloud. So the system needs to check the integrity of blocks transaction state later. The following two tools can be used to achieve this. First one is blockchain verifier, which is a project in Hyperledge labels. And this is a tool to verify the integrity of blocks and transactions. And blockchain verifier already supported fabric. Laser utility is a fabric command to identify potential divergent transaction among snapshots. It will be available from version 2.5. This slide discuss the perspective of management and governance. As a requirement, a system should have mechanisms whereby config values, config changes for the consortium are determined by multiple organizations. As shown in previous slide, config values on the blockchain network, especially channel chain code, can be managed on chain without depending on a specific organization by using public GLI. So the mechanism is in place and need to be used properly. We need to remember that other configs on the consortium are handled offline. And as another requirement, the system has a mechanism of cross-organizational operations management workflow. It should have a capability of cross-organizational coordination and execution. And it should have transparency of operational process and operational history. But the fabric does not support such end-to-end operational workflow. So coordination and execution must be done offline. And it is difficult to endure transparency, process, history of chain. So management tool to streamline them would be required. To us, satisfying the above requirement, we are expecting the possibility use of OXS-C. From here, I'd like to discuss about potential use of OXS-C. Professor, I want to talk about what is OXS-C. OXS-C is operation smart contract, which we proposed. And the goal is to establish a decentralized system management across multiple organizations. And the primary idea is to define a system operational workflow as a smart contract, like this. And each organization, admin or agent program, something like that, operates their own nodes according to the smart contract. As a result, the operations are unified over much organization. The value of OXS-C is that inter-organizational operation can be performed without relying on decision by a specific organization with uniform procedure, configure parameters, efficiently. We have implemented OXS-C for Hyperledge Fabric version 2.x, and the implementation is registered as a Hyperledge Labos project in 2020. The purpose is to streamline end-to-end operation workflow using the individual tasks, like Fabric, OXS-C arise, subcommand. And the first phase, as a first phase, is implementation provide OXS-C for managing the Fabric network, especially for operating chain code and channels. The left shows a typical blockchain operation in Fabric version 2. In version 2, only individual tasks can be executed in a decentralized manner. So the perspective of end-to-end operations, organizations need to share, adjust, configure parameters of chain. And then each organization executes the command with adjusted parameter manually. On the other hand, OXS-C, in OXS-C, end-to-end operations can be executed in a decentralized manner. So organizations can share, adjust, configure parameters on chain, especially on OXS-C chain codes. And then each organization's agent automatically executes the command based on the proposal on OXS-C chain code. This slide presents OXS-C for operating chain code. New chain code lifecycle is introduced in Fabric version 2. The new step for approving chain code definition by each organization is added. And it can eliminate centralized process in deploying chain code. However, as a remaining issue, it increases operations which are executed by each organization and must be used the same parameters. Also, it needs to share and negotiate the chain code source code and configure parameters like chain code definition with other organizations in a typical case. OXS-C for operating the chain code through a line, such end-to-end chain code deployment. In a typical use case, an organization creates a proposal with chain code source code and chain code definition. And then other organizations vote for the proposal shared on the OXS-C. When the majority of both is collected, each agent automatically deploying the chain code based on the proposal with downloading, installing, approving, and committing chain code. And OXS-C, this slide shows OXS-C for operating channel. In the left shows processes for channel update across multiple organizations, like add-in and organization. In this typical process, an organization creates a configured key X to update channel config. And then other organization signs the config TX. Then an organization send to the config TX to know to update the channel configs. So as shown in the figure, as a remaining issue, it needs to share config TX with other organizations. OXS-C, so in line, such operation channel update across much organization, the sequence is same as plans for operating chain code. Now I give a demonstration using a customized test network in fabric samples. This is a scenario for deploying a new chain code. And this is a portal screen with the interacting OXS-C. And in this case, there are three organizations of 1, 2, 3. And each OXS admin uses separate portal executed by, sorry, separate portal for each organization. Now OXS-C create and submit the proposal to deploy new chain code. And then the proposal is shared on OXS-C chain code. And then the chain code notifies the information to other organization. Next, the OXS-C approves the proposal. When the majority of approval is collected, each agent for each organization deploys to the proposal chain code to all nodes for each organization based on the OXS-C. Now each agent for each organization is deploying the chain code. And now chain code is deployed over all nodes for all organization. So in summary, OXS-C enables, in this case, decentralized coordination of operational information across organizations. And it enables automated unified chain code deployment. Let's go back to the slide. Current implementation of OXS-C only focuses on channel chain code management. But we expect that the OXS-C concept of defining operational workflow as a smart contract has potential for application to other management processes. I think this is our future work. Let's summarize my presentation. To add fully decentralized hyper-adjusted public-based systems, not only execution system, but also management and system configuration, we try to analyze comprehensive for basic requirement and design a reference architecture to satisfy the requirement. If BFT order is implemented in version 3 series, it will be ready as a blockchain platform to satisfy the requirement. And we will be demonstrating the applicability of OXS-C. The goal is to establish decentralized system operations across multiple organizations. And the primary idea is to define a system operation as a smart contract. In the current implementation, support end-to-end operational workflow on chain code and channel management. And I'm going to expand the scope of type of management in the future. That's all my presentation. Thank you. Thank you, Samari. Say that practically what you are trying to do is to streamline the out-of-bounds communication, like exchanging channel configuration and use the pre-existing fabric infrastructure that different organizations can exchange this information that currently is done out of bounds. So consequently, you only need to bootstrap yourself once in the network. And then being part of the channel where the operation chain code is installed. And then you use the blockchain itself for communicating the data that was done out of bounds, right? Yeah, that's right. So end-to-end inter-organization end-to-end workflow is our scope. Do you support the current feature that exists in 2.4, whereby you don't have to use a system channel? So does it work with that capability? Not yet. Currently, the implementation supports version 2.4, but with system channel. But we are going to implement a version without system channels. The theory should simplify things, right? Yeah, it's an OSN admin. This is one of the nearest future work. Sounds good. Thank you. The ability to do something. I'm sorry, I'm not sure. It's just watching the OSN activity on the community in the outside of it. It depends on the decision of the community. And how ready is the OSC as far as, like, can we start using it for production deployments? Or is it still in development? Or what's the status? How would you rate it in terms of production readiness? Actually, I'm not sure. Of course, I try to apply the production, but not yet. And this implementation is open source. And somewhere, eventually, use this in production, but I'm not sure. And production use is one of our future work. The general workflow of the hyper-related foundation would apply. So right now, it's in lab. You have to go through incubation, and then it would become, let's say, officially production readiness. Anything there? Anything OK? OK, thank you very much.