 So, welcome to our session. I'll be talking today about decentralized network governance with Hyperledge Fabric. A bit of agenda of what I'll be covering. Talk about us a bit, just to let you know who we are and what we do. I'll be talking about the network governance challenge that we faced throughout different projects that we've done in the past. I'll be talking about the network model, how we see it in terms of and how it is in terms of how the network nodes are deployed, how they're managed in a production kind of environment. I'll be talking also the governance of those networks and how actually smart contracts can be used to implement the governance process for those production networks. Then my colleague, Janko, will walk you through a bit of technicalities on the smart contracts that we've done and the concept itself from a technical perspective. At the end, you can ask questions or just if you have something on top of your mind, just interrupt me and shoot the question. So, we are Senofi. It's a young company founded four years ago. What we do, we provide services for a blockchain and Hyperledge Fabric in particular. That's our strength. We also build a tool named Consortia.io. It's think of it as a software, as a service that allows you to manage and deploy Hyperledge Fabric networks across different cloud providers. And we are also infrastructure partners for OpenIDL and we are Linux Foundation members. So, a bit of, did I wrong one? Next one, yeah. A bit of history. We ended up building our tool Consortia.io because we had to do throughout the project implementations, a lot of repetitive steps. And that means, you know, preparing configuration files, scripts, execute a bunch of steps just to deploy Fabric now. Everyone knows how complex that could be when you want to deploy on a machine, on premise or on different cloud providers. So, we ended up thinking, let's build something that automates that and gives us a nice UI to manage it. So, throughout building it, it was kind of, you know, hard job to do. But after kind of a six month or something, I remember, then we asked ourselves a very basic question. Well, we have a network and you can deploy a node, but what happens with other parties that want to join the network? Because a network of one participant, blockchain network or a DOT network doesn't make sense a lot, right? So, you want to have other parties join your network. So essentially, the biggest issue here to solve is not that about automating and deploying your node on a cloud provider. It's how you manage the lifecycle of those networks after. Okay, so it's not like a one time installment you do with a regular software. You have to maintain the software, you have to maintain the network to organize, to manage, to orchestrate throughout the lifecycle. Parties can join, parties can leave the network. And that comes with complexity because you need a lot of technical expertise, right? So, you need to know people to know what they're doing. You need to have a very strong understanding of the infrastructure and the tools being used because different participants, even though they may use the community provider tools, they may use some homegrown tools or some native tools provided by the cloud provider itself or another service provider. So, we ended up thinking about what could be the solution here for that. And that presentation is about that. How we ended up thinking that and implementing something that's actually on top of running on top of a duty network that is driven by smart contracts, chain code in a fabric world. So, how the usual network, when we talk about production network, not those test networks or proof of concept kind of a thing. So, here on the left, usually have a network of participants. I'll be putting that into a context of supply chain, very famous one, food visibility, right? So, you want to know, for example, how a lettuce goes from which farmer, how it goes to the processor, then how it reaches the retailer. Essentially, that helps a lot. You know the case, the Walmart case, very famous. So, it's easy to understand here. I have four participants, as you see, each one of them has a technically speaking network operator that's going to take care of the notes and, you know, manage the signatures and updates and all of that. And they usually go through a service provider. What I mean by service provider, it could be a company that provides tools or manages all of them on their behalf. And that could be running on different infrastructures, right? So, it could be running on different cloud providers. It could be running on AWS, Google Azure, sorry, Digital Ocean, and it could use different technologies. It could use Docker, it could use Kubernetes as well, right? Of course, some of the participants can go and self-manage the note, right? So, it depends on the company. But think about smaller companies. They usually don't have the capability to do that. So, usually they would go with the service to manage that network on their behalf. So, I talked about the tools, talked about how that's been managed. So, now the problem is, that's a given, right? So, what happens if a new participants come and what happens if that participant already have notes, right? Because you could be part of different networks, right? Let's dream in the future that you may be dealing with different partners, especially in the supply chain. So, you may be part of different networks that may not necessarily talk to each other. So, at some point of time you may want to join your notes to a service, to a network of other consortium. And what's the challenge here, right? Wait, let me go there. So, how, I'll be talking here in particular how you add a new organization, but the process is very similar to whatever updates you do on the network. It could be removing an organization or doing some changes on the channel that may require a signature or consensus among the participants. It depends on the policy. For example, you may want to change the policy. So, what happens is, let's say that you have a network with three participants. Here I have the farmers, I have a retailer and let's say the regulator or government body or someone who wants to be part of it, like getting information real-time on the network, wants to join. So, what usually happens purely from business perspective is going to be that the requester sends a request with whatever artifacts attached to it, technically speaking, it could be certificates. Then each one of the existing participants on the network is going to review that request. Technically, after they have to prepare a transaction that's going to update the network, saying, hey, a new participant is about to join. Of course, after that, they need to sign to satisfy the consensus, whatever the policy is already accepted for the network. And then the final step is someone deploys that on the network. Then the requester has the right to join their notes on the channel. So, how you do that? Of course, you could do that manually and it could be out of ban solution, right? So, the requester sends a formal email or whatever and it goes through a couple of steps. Now, because all of the existing participants may use different type of tools or software to achieve that, they may have different ways of signing, different ways of deploying a transaction. Some could be very simplistic depending on the tools provided by the service provider they are using at the moment, or could be self-managed, right? So, how we actually automate that process? You know, the most logical solution was, yeah, let's come up with a service. So, you could upload those artifacts on the service and then provide some APIs and nice UIs. So, different participants can log on to that service and do a ceremony of transaction creation, updates and all of that. Now, the problem with that approach is that you have a central party, right? So, you're losing that thing about decentralization of the solution. And, of course, data can be compromised and all of those things we want to avoid. So, the next logical thing was about, well, why not using DOT for that? Meaning that you get the advantages of decentralization. You don't have anymore a central point of failure. Of course, it comes with the complexity. It's not the perfect solution, but it is much, much better compared to a manual process or a centralized service. So, how this looks like? Okay. So, the idea here is to essentially create a DOT network that is going to be deployed and governed by the service providers, where through set of smart contracts, the whole process of governance can be implemented and managed. So, for that purpose, we chose, of course, our strength is fabric. So, we implemented some smart contract chain codes that solve that problem on a fabric network. So, think about the following. Think about that you have AWS with their managed service, right? They do support, for example, adding a new participant on their network, but that participant must have an AWS account. And the nodes of that new participant has to be on AWS. So far so good, but what happens with companies that use Azure? Bad luck, right? I know it's a question of, you know, everyone wants to get more clients, but at the end of the day there should be a compromise, because here we're talking about the usability of the network. You cannot expect that every consortium on the earth is going to run on AWS, right? Or on a Google platform, a cloud platform. So, the idea is that every service provider or cloud provider, whoever is providing that as a service to the client, they can jump on a DOT network, completely transparent for the end clients, and organize the whole ceremony of transaction updates and governance of the network through those smart contracts. So, from end-user perspective, it should be fully transparent. But the benefit for the client will be huge, because then they will be able to join clients, to join nodes of clients that use different service providers, right? So, that means I'm sitting behind my AWS, you know, dashboard or whatever, and I want to add a participant from another cloud provider. I could do that transparently, saying, hey, that's the guy I want to invite and go through the steps of the transaction updates and the governance process in order to deploy the transaction. That's the idea. So, what you get here is an advantage, of course, decentralization, privacy of data. You have the visibility of all those transactions, automation, obviously, right? So, you don't need to do much. No central point of failure. And the providers there that provide the tools, they can integrate and they can implement in whatever way they want to, right? So, there is no need, there is no UI involved, right? The service provider may have their own UIs to drive over the processes. It could be completely different than the implementation of other service providers, but as soon as that satisfies the overall process and follows the process steps, it's a transparent view from end user perspective, right? And of course, it could be community driven, depending on how that's being implemented, okay? Now, I'll let my colleague, Janku, take care of the technicalities behind that. He will talk more about smart contracts and how they're set up and as well how we integrated that implementation in consortia.io. And that is so ready actually, running like that. Yeah, Janku, please. Thank you, Svetan. So, first of all, I think the idea is now clear to everyone. Of course, you can ask a question and, you know, challenge us on that idea in a couple of minutes or when you finish the presentation, we'll be happy to hear that. One thing that we should acknowledge and restate of what Svetan already mentioned is that what we're going to talk to about in terms of implementation is more or less a reference implementation, right? So, we started with this project with consortia maybe three years ago and then we're happy to see in the Hyperledger forum that there's so much innovation coming through. So, it's not just us, it's not just other providers like this. There are a lot of companies right now, or a few maybe I should say, that have attempted to solve the problem with complexity in Hyperledger Fabric. So, it's not only Hyperledger Fabric but also all the products that come out of Hyperledger, right? Because we're talking about complex products that require many steps and so forth. So, we did that, we decided to go with the approach of being open. So, we didn't want to be, well, this is our platform. If you use it, you're going to get the benefits if you don't, well, sorry, but we don't really care about that. So, we wanted to bring a solution that would be open for everyone and it would be a solution that would be able to touch on the core principles of Hyperledger being open and being innovative in a way that you don't just close the doors. And the solution here is based on DOT, right? We'll take a look at how we've implemented this in terms of steps. And the idea for this particular slide here is to present how we are executing on join request and how this works in the real world. So, let's assume that we have an organization that needs to join an existing network. What we do is we've created a so forth account ID. So, that's an identifier that basically states the account number and the provider, right? It doesn't have to be anything fancy and that we don't want to include any sensitive information yet. But, in general, once you have this account ID, then you can identify the network that you want to join and also the requester or the approver. So, the approver sends their account ID and they say, well, if you want to join this channel and this network, here's your ID. The second step of the process is that the requester will create that request to join the network or to make or, yeah, in this case, to join the network. And then the approver will review that request. On the request, what do we have? We have the account ID, we have the channel ID, and then we also have some additional information that's non-sensitive. But as soon as we do that, and then the approver receives that request, they can review that information. They can see, we also provided the ability to pull the certificates of that requester once they're on the network, or not on the network, but once they're in our account. And they have their identity certificate authority and their identity. And as soon as we do that, the approver reviews all that information, they acknowledge that this is the person they invited. And then once the request is approved, we create a transaction. So that transaction is not signed until we get to the particular minimum requirements for the policy to be fulfilled. So we have the participants, they have to go and sign the transaction. Once that transaction is signed by the minimum count of participants that have to approve it, we get to commit the transaction. One of the participants gets to commit the transaction, and then that change is applied on the network. So this is really not a simple process per se, but the way it could be implemented is very straightforward. There is only a few steps that need to be executed by each participant. And overall, it just fulfills the whole process without major manual processes, because once everything is integrated in the system, you have everything for granted. Here's a short overview of how the network works or looks like when you have multiple service providers. So those are our particular chain codes that we've used. They are segregated based on major responsibility, right? The John request processor is the chain code that would take the transaction or the, sorry, would take the request, would save the required data in the private data collection. And then it would trigger the public record management. So the public record management is what exists on the ledger as a public information. Our reference implementation just saves the request. So it just has information to identify that there was a request created from an organization to join a particular network. That's everything. Of course, in the future, of course, we can add more non-sensitive information, but that's how it is at the moment. So this is the request record management chain code. It only saves and reads from that public key store. There's nothing else that it does. And then the channel change management is actually the logic where we assign the change to different participants. It gives you the permission to or the opportunity to sign that transaction and then opportunity to commit and to trigger an event. The service integration, the service provider integration layer. So this is the layer that basically integrates with the DOT network, the service provider DOT network. That's usually an integration layer that makes it easier for the end user to communicate with the system, to execute actions, to sign the transaction and so forth. And then we have the registry channel where this is our registry main channel for communicating between different service providers. This is what we use. We only have one channel and it works for us. I'm not saying that it may work for every other service provider the way it is implemented. But in our use case, we believe that's the minimum reference information that you would need. And then if we continue the bigger picture, so what the previous slide was depicting is the service provider DOT network here, right? And this is our kind of landscape for consortia. We have the managed customer DOT nodes, which is basically the participant network, let's say, that you would want to add an organization to. And then this is the service provider DOT network, which is the means of recording that transaction and keeping it on the ledger for feature reference. So the way this works is that we have in blue, as you can see, we have a set of orchestration services. And those are basically services that allow us to apply the change and to read from the DOT nodes whenever we need to, the information that we need for the network. Then we have that's done through AUX, which is the open source project for Ansible Tower in this one. Well, if we're talking about a service provider DOT network, which is supposed to be done through a config initially, right? So, I mean, ours was created like that we have maybe a couple of nodes right now. But if you add new service providers, then that means we have to initiate this process of adding a new organization, but that would be a manual process, right? And the governance service is basically responsible for performing all those transactions for communicating with the network, making sure that transaction is executed. And then we have account PKI persistency and service provider certificate authority for that particular network. That's why this is surrounded with a dotted line. But this is our idea of or and how this works in our landscape. So, yeah, as soon as we, I mean, the thing is that as soon as if we ever add a service provider, we want to be clear on that they don't have to have the same landscape, right? That's the beauty of the service provider DOT network where every provider can have their own landscape. They can use whatever they need. But then the customers here, they'll get all the benefits of being able to connect to any other organization in the world, right? Okay, so then we have a few minutes for questions and any comments. So the question is, yeah, the question is whether we need to have a network of service providers for this to work, right? Yes and no. So yes to a point if you want to automate the process. Okay, so then you need that network up there to automate the governance process between service providers. That's the benefits that different clients will get that are running on those service providers that are part of DOT network automation. Of course, if they are not on that, if the service provider is not on the network, you have to go through the manual process through their IPs, yes, IPO or DNS names. And when we say network, if we take technically speaking, it's a channel, right? So if they're part of one channel, their peers can be part of another channel that is part of another network. It depends how you design and structure your networks, right? Of course, you cannot mix channels like you could add organizations or remove organizations from a channel, but you cannot join channels, right? So one existing channel, another one, you cannot merge them. Of course, you could pull the data and create a new channel, but technically speaking from fabric perspective, there is no merging existing channels, right? Right, it all depends on the way we vision that is that the requester, whoever wants to join the channel, they may or may not know what is the internal structure of the channel they want to join. Okay. When I say internal structure means the membership service providers that are already there on the network. It could be due to privacy, right? So some may not accept formally the request, the requester to join. So they don't want to expose that. It's like a voting, right? So they vote, oh, do we want this guy in? So some of them may vote no. Okay. And they may want to just let the guy, hey, you are in or you are out without exposing who voted, you know, and what were the votes. So that means the requester needs to send their public information, meaning certificates, and a bit of detail about what channel they want to join. After that, it's a question of process that is driven between the participants, current participants on the channel. So then they decide what to do. So if they decide to proceed with that, they will inspect the certificates, see if that's the guy they really trust. Of course, there is a business process running in parallel. I'm talking here about the technical execution of the business contract, right? So they will sign the certificates, then they will, first they will create, sorry, create the transaction update, including the certificates of the party that joins, wants to join. Then everyone depending on the policy of the channel will have to sign the transaction and when enough signatures are collected, then deployments are going to happen. So you need a channel, of course. It's always a channel. Network from fabric perspective is a channel. You don't need to, you may verbally tell the requester what they want to join. What is the name, technical name of the channel? That's all. That's all you need to expose. Of course, but you just expose the name. That's it. You don't need to expose where the peers of the network are. Nothing, nothing more than that. So that is the whole beauty of it because we assume that requester, whoever requests may not be approved. So the requester must see the minimum information. Yeah, the network, if we're talking about the registry channel, yeah, the question is what are the organization that joined the registry? So here we have one channel where all transactions are happening. The idea is that on that channel, there will be all service providers. The kind of DLT here we are, you are seeing has nothing to do with the DLTs of the customers. Okay, this DLT is just for the service provider to orchestrate and automate the governance process of between them when their customers want to join their peer on existing networks. Yeah, that's the governance. So the question is how for that DLT network for the service provider, how you make sure when you can, okay, different cloud. Yeah, so the assumption here is that that will be used by service providers, right? So that means that all the communication should be already secured by using the standard fabric techniques like TLS. I believe it should be. Okay, and it's a technicality that needs to be clarified when partners join the network, but usually, yes, you want to have the best security possible. Because if you make an exception from that rule, you introduce a weak point, security weak point in the network that may compromise all the data and all the ideas inside. Yeah. So the question is, if I understood right, you have different networks, right? And then they want to, you actually participate, you don't have, you don't mix up networks, right? You add participants on the network. So to start with, right? Those participants may carry their notes. It's not necessarily that the note needs to be bootstrapped from scratch, because one note of a client may be part of different networks. That's allowed. That's fabric feature. So, of course, if you're part of different networks, you don't want to have like 10 notes. That would be a nightmare, you know, to manage. So that's why when I'm saying, hey, I bring up my notes to another network, this actually doesn't mean creating new notes. This means reusing your existing notes to join new networks, new channels. Yeah, usually if you don't have between service providers, okay, assuming you use a service provider to manage your note, right? So in order to join the network, you need to send your certificates to the party, to the participants on the existing network so they can prepare the transaction update sign and do all of that, right? That process, as of now, from fabric perspective is out of bounds, community saying it's a manual process. It cannot be for now. That's why we introduced that. It's not managed on the chain. So it needs to be managed outside. So that's why for the purpose of simplifying the process, because believe me, every client may have different service providers and the way they join participants from outside to their network may be different, depending on the implementation of the service provider. AWS, I'm pretty sure they have some APIs to do that. I don't know the details. Maybe they don't know. For sure they can join, but you need to have an account with AWS. So it's like that. So the whole point is connecting people that having notes on various cloud provider, various infrastructures and all of that. Otherwise, you are centralizing things, right? I don't think that that's networks that are executed or you cannot force people. Again, think about companies, how the business works. Nowadays, I have a couple of examples. They may change cloud provider once in two years, depending on the contract they get from someone else. It could be half the price. It happens. They may jump from Azure to AWS or to the GCP and vice versa. So you cannot force someone to stay with a particular cloud provider forever, just because you don't have the governance process across cloud providers. That's not going to happen. No one is going to be part of such network. Not yet, but that's our next steps. We'll probably take it with the community, see what they think about it. So that's why we wanted to present that to the community today and see what they think and if we can open source it and contribute it and make it part of the community. Not quite, not quite, but to some point, yeah, but it's a different, it's more about here, not that much about the source code of the contracts we are talking about, it's about the concept. Because as you see here, you need to get the buy-in from the different service provider, otherwise that won't work. As with any, you know, DOT network. You need to get the buy-in, the business buy-in from the participants before you can do it, technically. But what we wanted to showcase is that it's a concept that should work, that works, and we have a reference implementation that showcase it. So it's a question of onboarding the rest. There are other companies, we'll be talking to them today as well on the forum, so we'll see how it goes. What happens if you cannot collect enough approvals? That's the question. Well, there's no transaction. It will be rejected. So you may decide that as a, you know, you either do it from business perspective, say you have a deadline, or give some time for the processors and approvals to sign the transaction. The question is about the voting mechanism. Here there is nothing custom or proprietary. The voting mechanism I'm talking here about here is the voting mechanism that we have in Fabric already. So it's not a, it is just the concept and the smart contracts that the others needs to agree on. Of course they may have different implementations, but we're talking about taking that, those simple smart contracts and integrating them in their own platforms. So the whole process could work platform across platforms. That's the whole idea. Yes, yes, it's selecting the basic minimum. So we don't want to force too much logic because we know every platform may have their own architecture, their own design, their own components. Right. So you cannot force them a particular implementation, but, but you could force the bare minimum. And then the way we see it is, is the request itself. And of course reference implementation if they want to change the implementation of the smart contract to fit their needs. Of course that that could be done. It's the contract. It's the interface here we're talking about the concept. Yeah. Yeah, the question is, when you joined the network, you need to join what you, you need to know what you're joining right. Okay, let me put it that way. Let's say that you may not trust the, the, the existing participants and they joined take your certificates that are public. Right. And put them in the network. So you're allowed to join. No one can force you actually to add your notes there. Okay, that's the beauty of it. Your request may be approved. Okay. And the network may be open for you to join, but you may decide not to. Yeah. So, so that that's why, so the information about what you're joining assumption here is that it's provided upfront. That's why I'm saying if it's a permission network, it needs to go through some approval and that means speaking from business perspective, you're not signing a contract because you're bringing your own notes into something and you need to cover some ways and all of that. Right. So, no one can let you in in the network and vice versa. Right. You cannot join a network that you cannot rely on. So that those things needs to be signed upfront. Right. So that that's how of course you could have a public channel with it will be a question of trust like you're joining a chat channel and something so you assume it works. You know, it's a question of if you want to go take the risk or you want to sign a contract to, you know, of course, of course, it's what I'm talking here about the technical implementation of the concept right. It's not about signing business. I'm not a business legal guy. Right. Exactly. It's a parallel business process. Yes, it's for any any consortium regardless of the technicalities behind. Of course, oh, when I'm saying governance, I'm here. We're talking about in particular just to make it a bit more simple, adding an organization but everything you do on a channel like of boarding an organization is the same thing. Then changing the policy of course you could change the set of of concenters on the channel that that also requires signatures so everything that requires signatures and voting. Could be driven through exactly the same process. The whole point of that is to simplify and to break the boundaries between service providers and cloud infrastructures we have right now, because I think that's that's topping really a lot the adoption of the network. Because really you cannot expect you have to think about business and then, oh, but I have a restriction on the then, you know, those kind of networks cannot cannot exist. If there is, you know, limits and barriers. Correct. Yes. Yes. Yeah, of course, any transaction. That's what I'm saying. It's open enough. I'm doing something. And then it's a question of preparing the particular transaction. And then the rest just needs to sign signing a transaction. It's, you know, just, you know, taking your private key and generating the hash code and all that. Yeah, any other questions. Okay, good. Thank you so much.