 Good morning. Good afternoon. Good evening to all. Appreciate you joining this session. What I'm going to be talking about today is a proposal we're making to extend the Operation Smart Contract for Hyperledger Fabric to support consortia governance. So this is a proposal for work activity to be done, something that we're at Oracle definitely interested in because we see consortia formation and governance as being a major issue when it comes to blockchains. So what I want to cover today is a little bit of just a really brief intro about what is a consortia, a little bit about what the Operation Smart Contract Hyperledger Labs project is all about and then some information about consortia governance, some voting enhances we'd like to see and as well then the summary. So whenever I present, whenever I talk to customers, whenever I talk to other technical folks, I like to refer to blockchain as a team sport. There are certainly a lot of blockchain networks out there that have been created that are managed by a single organization, but then you lose much of the capabilities and much of the advantages of having a decentralized environment. So a consortium basically is just an association of businesses. So it's one or more businesses that want to get together and be able to conduct business together for some mutual benefit. That consortium has been around for a long time. That's nothing new. So what we're looking at is how do we solve some of the issues associated with forming a consortium? There's a number of them that are business related issues. What are the laws that you adhere to, all that sort of stuff. But there's also a bunch of technical issues, especially when it comes to blockchain. So when you create a blockchain instance, you create a network, you need to have members join that network, you need mechanisms to be able to include those in the network. And so all that has to be a bunch of technical issues such as exchanging things like MSP information and that sort of stuff. And the need is for multiple organizations to work together without one being in sort of in control of the Uber organization. A lot of blockchains have that right now where there's one organization that essentially formed the network and it's roughly in control. What we'd like to propose is something that's a bit more decentralized than that. And as well, we think that decisions and any actions that take place in the blockchain network need to be auditable. So they've got to be recorded on a ledger someplace where they can be verified and people know what's actually been, has been decided and what actions were taken. And ideally what we want to do is sort of automate as much of this as possible, especially this technical side of things. So a little bit of introduction to the Operations Smart Contract or OPSSC. This is a Hyperledger Labs project that was contributed by Hitachi. There was a session on this or a demo of this on Tuesday, I believe. And what it consists of is several different components. So the first two major components are there's two smart contracts. One smart contract is used to maintain the chain code lifecycle or manage the chain code lifecycle. And another one to manage channel management. So adding members to the channel, those sort of operations. And largely, this is all around workflow. So it's trying to automate and simplify these operations, which right now are largely manually done and have to be done by each organization that's participating. So what these smart contracts do is they manage the state transition. So from a proposing of a chain code deployment to or proposing a new member to a channel or changing the channel configuration, those are all done as proposals and voted on. And the smart contract is what sort of manages the lifecycle of those proposals and changes. There's also an agent. So this is the OPSSC smart contract agent. And what it does is it automates the operations. So when an agreement is made to say deploy or upgrade a new chain code, the agent gets notification that when sufficient members have agreed to this and so they meet the policy associated with updating or deploying a new chain code. And then the agent does is it automates that for each individual organization. So that's an optional thing. You don't have to use that. But the agent then definitely takes care of automating much of the operations. And then there's also an API server. So the API server is what manages the state of the workflow. So it provides a set of REST APIs to be able to access those chain codes, the chain code for lifecycle chain code and the channel management chain code. And what it does is it basically accepts things like proposals to do some of these operations. And then it also accepts votes from the various members. And again, it runs as a separate server in each organization's instance or somewhere within their organization. And again, I want to focus to say that this is focused largely on automation, not on enforcement. I'll talk a little bit about enforcement because some of that will require some changes to the way fabric manages the decision making process and agreements. So for chain code operations in the current OSSC is that an organization that proposes a new or upgraded chain code calls its API server. So it makes a request to the API server. The API server in turn then invokes the chain code up the channel channel or the smart contract chain code to record the proposal. Once that proposal is recorded, the operation system chain code, chain code, emits an event. And that event is listened to by all the organizations that are part of the consortium and then operates on those events. So in the case of let's say it was a proposal to update a chain code as each organization then votes for that. That information is also done by invoking their API server, which records the vote using the OSSC chain code. And as well then the OSSC system chain code emits an event for each of those such that once enough votes have been achieved to be able to meet the policy associated with upgrading or deploying new chain code that those operations can proceed automatically. So let's say once the vote passes, the organization one agent will download, install, and approve and commit the chain code. And the other two agents in the three organization network would download, install, and approve the chain code as well. And then this happens automatically but based upon once the necessary criteria of voting has been met. Channel operations operate in a similar fashion. So one organization proposes a config update in a human readable format, which is important. And it does that by then calling its API server with this human readable update proposal. The API server then invokes the channel chain code to record the proposal. It converts that proposal into a configuration transaction. And then he also emits an event so that all the other organizations that are associated with the smart contract can receive the notification that a proposal has been made. Other organizations that get to vote on the proposal by calling their API servers. Once the API servers have recorded the vote, and again it emits an event just like they did for the chain code deployment, and that again is received by all the organization's agents. Once sufficient votes have been recorded, then one of the agents will take that converted configuration transaction and then I can perform the channel update operation. So that'll include having all the various signatures. That'll be part of what the voting operation is, is to record the signature of each organization as they approve the vote. So what's missing? So what's missing from our perspective is this notion of consortium governance. So who are the members of the consortium? What are they allowed to do? How do you add or remove or alter what members can do? So all this issue about membership and what they're able to do and who's responsible for what. So we think that's one major piece and I'll get into more about what our proposal is to address this. And as well we believe that we need some of the voting enhancements. Right now we just it's all that the opposite system chain code supports is a simple majority mechanism. What we want is to be able to support things like non-uniform voting rights. There are a lot of cases where some organizations may have more rights than others. There may be a subset of the organizations that are sort of a governing council if you will. But there's a lot of different various use cases for why you might want to have non-uniform voting rights. And as well we'd like to see the support for abstaining and opposing. So right now all the support right now is basically to say I approve. There's no ability to say that I oppose this particular request or particular vote or a way to be able to say I acknowledge it but I'm not going to vote on it. I'm abstaining from voting on it. So what's needed then are some extensions then to the OPC system chain code to be able to support these governance operations. And again I say this is largely focused on automation. Supporting you know the enforcement of it is something that will have to be done as well with not only within the chain code but also inside a fabric itself. And I'll get into some details of what kind of enhancements we need to be able to support that in a minute. So what we're trying to do is let's say move from these oftentimes these what we call founder led consortium to a more decentralized governance. And initially not going to change the enforcement policies within fabric. Ideally we want to do that such that we can provide some of these things like potentially veto capabilities or as I say asymmetric voting capabilities. That's not necessarily part of the initial proposal but something that we believe ought to be done. So there's nothing that we're proposing right now to prevent members from using standard fabric capabilities. So you can create your own config TX transaction. You can solicit the signatures necessary from the various organizations through some out of channel or out of band mechanism. This isn't going to prevent that. Something else is that we want to support as I mentioned before is that all members are not necessarily equal. So in many cases as you have consortiums where for whatever reason some members have more rights or different rights than others. And so we want to be able to support that kind of capability in the voting mechanisms and how it's determined as to what members can propose and do what. So we want to support you know say non voting members. So members who are basically they don't get to say that you have to go along with whatever the agreements are that are made by the voting members. And as well you know with the proposals to be able to change who can do what whose members are those sorts of things are something that we also feel should be supported. And then again as I mentioned earlier that all these decisions and all these actions need to be recorded in the ledger so they're auditable and it can be you know ensured that the proper processes were followed. So one of the issues is probably the major issues in forming the consortium is how do you exchange the information. Right now there are no mechanisms to do that per se. So to form the consortium everything's got to be done out of band meaning that it's not recorded in the ledger there's as there is no network yet you're still forming the network. And so what we're proposing is that this be done partially out of band and I'll explain a little bit more about that in a second. But it has to do with a bootstrapping issue. How do you how do you put something in place that people can use to come to agreement before before everything is settled. So and then you know what information has to be exchanged. We believe in this minimally for each member organization we need the MSP information so we can verify signatures and the like. And we also need some information about the ordering service network that the participants will use. And then finally in terms of you know for the consortium members what actions are they each allowed to perform. So this is something that has to get decided up front and a proposal made to be able to to create this kind of a network. So what is being proposed is that when somebody proposes the formation of consortia or you know how do you bootstrap a consortia there's going to be a single member that at least in theory a member that's what we're calling the proposer. And so the proposer is the one that would create the ordering service and their initial ordering service nodes. It would create the ops channel. So this is the channel over which the various consortia actions would be recorded and voted on. Deploy the two chain codes that mentioned actually the three chain codes now because we're proposing adding an additional one. There's the chain code ops. There's the channel ops. And then there'd be a consortia ops chain code that would be deployed as well for managing consortium operations. And then finally the the the proposer starts his own agent and its own API server. And what we're proposing to be able to solve this bootstrapping problem is that the proposer provided a temporary set of limited credentials to their API server. And what I mean by limited credentials is credentials that can only be used to perform certain operations. And in this case here it would only be able basically to be able to provide their information and accept the membership into the consortium. So the proposal also then defines you know who they the it I'm sorry then the the proposer then commits this initial consortium proposal to the chain code that's only now at the moment running in its own organization. And then the somebody either the proposer or the agent could potentially do this emails the other notifications to give them the access to the API server so it's URL and its temporary credentials. Obviously there's other mechanisms that be used here to exchange that email just the proposed mechanism. There are probably other more secure mechanisms that would be desirable but this is at least the initial go. And then as the other organizations will get this information they'll connect to the API server and they'll provide their MSP information. And then the agent then will then update the ops channel with their information and have them join that channel. Finally the other organizations they say they'll use the the initial members or the proposer's API server. They will download the conversion performance formation proposal and use the information in there such as the OSN information the proposer's MSP information that sort of stuff to configure a minimal instance in their network or in their in their environment. And then if they decide they're going to join the network they would as well provide their MSP info through the initial members API server. So once all that's once that's been done then the initial members agent can add the MSP information to the ops channel and install then the ops game code and start up a local ops agent API server. What we're thinking in terms of what would be in this initial consortium formation proposal would be information about the consortium itself. So this would be things like the name description a list of who the initial organizations are that are being proposed what the voting policy is for the consortium. So this is like what is the policy that it and what that has to be met to be able to change the configuration of the consortium. And then that's in terms like you know like voting policies and other information. But then we'd also have a membership voting policy. So what's it what is it required by the existing members to be able to add or remove members. So that may be that's we're envisioning that as potentially a separate policy. And then for each organization what's required then is we would need the name we obviously want some contact information because they email address of administrators or operators what number of votes are provided if we're using asymmetric voting and what permissions they have are they allowed to perform you know a chain code upgrade are they allowed to do any other sort of operations that would all be listed as a set of permissions that that each organization is allowed. And then also as part of the initial proposal the proposing organization would need to provide its MSP info so the other organizations can then join the ops channel. So a little bit also as well about about voting. So you know voting is basically an issue about how is it how is agreement achieved. So right now in Fabric Fabric uses signature policies for approving or endorsing or allowing the submission of transaction and committee of those transactions as well as for things like channel config updates. So the config TX transactions and a signature policy is is nothing more than an expression of one or more principles. So if you're not familiar with this this is basically says that I can have an MSP and a role so like here org one admin and then I can specify a set of logical operations that that that can be used to specify what what meets the the policy. So there's an example here of an and so it says this is an and of org one member and or two member. So that means that if that's the policy then both a member of org one and a member of org two would need to sign the proposal. There's a more complicated one where we have and of either org one or org two signing as well as org three admin signing. So these are different ways in which the policies are currently defined right now within Fabric but they have a number of limitations and we'd like to try to enhance the voting capability or the agreement capabilities within Fabric to support some of what's proposed here for the operation system chain code. So what is missing so in the operation system chain code itself related to voting there's no ability to abstain there's no ability to veto and abstention is valuable in terms of being able to know whether an organization is voted or not. So it would be valuable to have recorded as part of the voting operations that some organization abstained just to know that they have voted that then and they don't really have an issue with whatever the decision is. You still need to support whatever the policy is but they're just indicating that this is something that was not of interest to them or they want to let people know they're not going to vote for or against it. The current thing only supports a single vote for organization basically a signature and there's no veto capability so in some forms of consortiums there are certain members that would have veto capabilities and if you look at something like you know the United Nations not necessarily that's a consortia but certain organizations or members have veto capabilities and others do not. In Fabric then we would need additional changes then to be able to support additional voting policies here so right now the only thing that's supported in Fabric is what we would call a forevote so basically if you sign the proposal you're agreeing to it if you don't sign the proposal we don't know whether you're agreeing disagreeing or just didn't bother. So this would require some changes in Fabric then to be able to support these kind of voting enhancements. So what we'd like to propose in Fabric is that we and actually into the operations system chain code is the ability to support these consortiums the formation of them and the administration of them so that would entail creating another chain code to support consortium just like there's a chain code for channel operations and a chain code for chain code operations we'd have another one for formation and administration of consortia. We need to add some voting enhancements to the current OSCE voting mechanism and we would also then need to add some additional support endorsement policies and the like to Fabric to support this enhanced voting so there are changes that will be required both in OSCE as well as in Fabric and then ideally it would be helpful to take something like the OSCE agent right now and integrate that with a deployment tool such as something like hyper ledger cello that can be used to then create the initial deployment because right now to create this a network it's largely up to each individual member to take care of all the all the manual steps that have to be taken with something like integrations with the OSCE chain code and cello we can potentially automate a lot of that initial deployment so in summary let's say we think and our experience has been that consortium formation is difficult and often has been you know led by a single organization so it's not particularly decentralized we'd like the formation and management of the consortium to be much more decentralized and and much more automated because right now largely to say it's a manual set of steps we want to leverage the existing operation system chain code as it provides you know much of what we needed and if it's a model that we believe makes sense for consortium management provides you know say the mechanisms to be able to automate stuff to be able to come to agreement on decisions that affect the network and that's all that's all in place right now what's missing is sort of the consortium side of that and especially the consortium forming portion of that and you know the ultimate goal here is to simplify and automate the formation of a consortium based upon hyperledger fabric to join in if you'd like to comment like to help do whatever you'd like there's a rocket chat channel for the operation system chain code the link is provided there on the slide and as well the source code for that project is located at in github as a hyperledger labs project and with that i'm going to open it up for any q&a any thoughts any questions any interest in contributing or you know help helping with this so the question was my hesh asked uh if you're going to provide any of these features as part of the oracle blockchain as a service our oracle blockchain platform i had to be careful here i don't have a safer harbor statement here all i can say is that we are proposing this this is in line with with our thinking about how consortiums should be formed and managed i obviously i can't make any commitment to say that we're going to provide this what kind of peter asked what kind of storage with the initial out of bounds out of band i'm assuming you mean bootstrapping could use so this is the idea that the out of band mechanism is is what we're proposing using these these temporary credentials where the proposing organization would grant temporary access limited access to its api server so that those organizations could then provide the information that's necessary to bootstrap the organization so that would all be stored on chain uh and initially it would only be in the proposers network but as that network then is expanded and other other members join the network agreed to be a participant then that they would automatically get a copy of that ledger as well so there's no really the intent here is there's little to no out of band storage that that all the storage would be maintained in the chain code operations and mark mark willmitch asked how would handling dropping members out of the consortium if they leave again this would be based upon the the voting policies that are for the consortium membership itself um so this would be something where members might have to be careful uh that you don't get yourself uh you know hitched you know the issue right now is like in fabric if you have an endorsement policies is that every organization must endorse a transaction to be accepted and one of those organization drops out uh you're you can't get a valid set of signatures to be able to perform a config transaction to alter the the channel membership so you have to be very careful about this that such that you don't end up in a situation where you can't uh you can't actually meet the endorsement policy or the signature policy required um a hash asks besides the rest api for agents is there a front end for the agents being open sourced um at at the moment there's that's not part of the opposite siege system chain code uh project but i could envision that being something the issue there is that that probably needs to integrate in with whatever sort of you know front end the platform that you're using uh requires so in the case of oracle blockchain platform if we pick this up and integrate this in with ours this would be something that would all be handled through our console and so i would imagine other other fabric implementations would have similar uh sorts of capabilities or some sort of management console and again that's where this stuff would would lie any other questions right if not i thank you and i'll give you back another two and a half minutes of your day uh and i hope you found this uh a valuable session and please if you have interest in this we're you know it would be great to have additional contributors supporting this uh and as i mentioned the the the information in the rocket chat and and github is there in the slides so if you want to go back to that later they should be able to find that without problems and with that uh see no more additional questions then i'll close the session then thank you all