rjones (Wed, 28 Apr 2021 14:16:18 GMT):
tatsu-sato

rjones (Wed, 28 Apr 2021 14:16:25 GMT):
@tatsu-sato here you go!

tatsu-sato (Thu, 29 Apr 2021 02:38:08 GMT):
@rjones Thank you for making the channel!

rjones (Thu, 29 Apr 2021 13:05:50 GMT):
Has left the channel.

tatsu-sato (Thu, 06 May 2021 01:13:35 GMT):
Operations Smart Contract for Hyperledger Fabric (https://github.com/hyperledger-labs/fabric-opssc)

tatsu-sato (Thu, 06 May 2021 01:15:12 GMT):
Operations Smart Contract for Hyperledger Fabric (https://github.com/hyperledger-labs/fabric-opssc)

tatsu-sato (Thu, 06 May 2021 01:17:56 GMT):
Operations Smart Contract for Hyperledger Fabric (https://github.com/hyperledger-labs/fabric-opssc)

tatsu-sato (Thu, 06 May 2021 01:21:27 GMT):
Discussion related to Operations Smart Contract (OpsSC) for Hyperledger Fabric, which is a Hyperledger Labs project

tatsu-sato (Thu, 06 May 2021 01:21:27 GMT):

tatsu-sato (Thu, 06 May 2021 01:21:27 GMT):
[Operations Smart Contract (OpsSC) for Hyperledger Fabric](https://github.com/hyperledger-labs/fabric-opssc)

shimos (Mon, 17 May 2021 23:56:50 GMT):
Has joined the channel.

toddinpal (Tue, 25 May 2021 15:05:32 GMT):
Has joined the channel.

toddinpal (Tue, 25 May 2021 15:22:42 GMT):
In looking over the API server API for voting, it's not clear how to vote to disagree if that's even possible. I see that if no payload is passed, the task status is set to "agreed". So would one provide a payload with the updateRequest.status being "disagreed" to vote against a proposal?

tatsu-sato (Wed, 26 May 2021 07:03:37 GMT):
We have only prepared the states for chaincode ops and have not yet implemented the ability to vote against it in the Vote API. - API server: - For chaincode ops, the Vote API internally can handle a payload of TaskStatus type, but it needs more work to support the "disagreed" status. So, setting "agreed" or "disagreed" into the type is not yet considered. - For channel ops, the Vote API does not have a payload for TaskStatus yet. - Chaincode: - chaincode_ops's vote function can accept Agreed or Disagreed an argument. However, it does not yet have a specific flow for receiving "disagreed" votes. - channel_ops is not able to accept "agreed" or "disagreed" because it does not yet manage the state transition model. I think the implementation of OpsSC needs to be improved to vote against an proposal.

tatsu-sato (Wed, 26 May 2021 07:04:15 GMT):
We have only prepared the states for chaincode ops and have not yet implemented the ability to vote against it in the Vote API. - API server: - For chaincode ops, the Vote API internally can handle a payload of TaskStatus type, but it needs more work to support the "disagreed" status. So, setting "agreed" or "disagreed" into the type is not yet considered. - For channel ops, the Vote API does not have a payload for TaskStatus yet. - Chaincode: - chaincode_ops's vote function can accept Agreed or Disagreed an argument. However, it does not yet have a specific flow for receiving "disagreed" votes. - channel_ops is not able to accept "agreed" or "disagreed" because it does not yet manage the state transition model. I think the implementation of OpsSC needs to be improved to vote against an proposal.

tatsu-sato (Thu, 03 Jun 2021 05:36:51 GMT):
@toddinpal I will be giving a presentation on OpsSC on the first day of Hyperledger Global Forum. I would like to promote your presentation at the end of my presentation, is that OK?

toddinpal (Thu, 03 Jun 2021 13:27:16 GMT):
Yes, that would be fine and thanks!

raduke (Tue, 08 Jun 2021 16:57:51 GMT):
Has joined the channel.

knagware9 (Thu, 10 Jun 2021 17:03:33 GMT):
Has joined the channel.

ksanjayk (Fri, 11 Jun 2021 05:03:55 GMT):
Has joined the channel.

toddinpal (Sat, 12 Jun 2021 17:58:42 GMT):

Consortia Governance with OpsSC v0.4.pdf

toddinpal (Sat, 12 Jun 2021 20:36:04 GMT):
Would love to get some feedback on whether this makes any sense, how it can be improved, suggestions for implementation, etc.

tatsu-sato (Mon, 14 Jun 2021 08:12:24 GMT):

HyperledgerGlobalForum_OpsSC_sato.pdf

tatsu-sato (Mon, 14 Jun 2021 08:14:14 GMT):
p.8 shows the roadmap for OpsSC at the current time. NOTE: The development items are just a list of everything we can think of at the moment. Priorities and schedules will need to be reviewed in the future.

tatsu-sato (Mon, 14 Jun 2021 08:15:51 GMT):
Thank you again for your great presentation and contribution to the OpsSC project. I mostly agree with your motivation and suggestions. I believe that the following features listed on p.8 of my deck at HGF correspond to your proposal. - Full support for workflow state transitions (e.g., Rejecting a proposal) - RBAC/ABAC for OpsSC chaincodes - Voting policy configuration What I am trying to say is your proposals are important to make OpsSC more practical.

tatsu-sato (Mon, 14 Jun 2021 08:20:02 GMT):
Here are my comments on what I have noticed at this moment: - *About voting Enhancements* - I think it's a great idea. - As an initial step, it seems like a good idea to implement it without making any changes to the policy of Fabric itself (as you mentioned in your presentation). - *About consortia management* - I agree with the importance of consortium membership management in your proposal. However, I still don't understand the intent of the design. 　It seems that it could be implemented by managing the ops-channel as the consortium on channel_ops. So, could you clarify what are the benefits to have a separate consortium management as consortia_ops? If you already have a more detailed design or initial implementation that you can share, I think I can better understand your intentions and we may be able to have a more in-depth discussion.

toddinpal (Mon, 14 Jun 2021 19:42:57 GMT):
I don't have a more detailed design or initial implementation. I may need to understand the channel_ops chaincode a bit more as I don't really recall anything that deals with consortia membership as a higher level thing than a channel configuration.

tatsu-sato (Wed, 16 Jun 2021 04:58:09 GMT):
@toddinpal Thank you for your reply. As per your comment, the current channel_ops does not deal with a higher level thing than a channel configuration. IMHO, all the organizations which join the consortium can be assumed to join ops_channel, and the operations by channel_ops for ops_channel can be also treated as those for the consortium. So, I think there is an option as the implementation to enhance channel_ops to also manage the consortium (ops-channel is handled as a special channel in channel_ops). In order to understand which implementation option makes more sense, I would like to discuss the advantages of the option of adding consortia_ops as a separated chaincode to manage the consortium. I would be happy to get your opinion.

toddinpal (Wed, 16 Jun 2021 23:24:48 GMT):
I should clarify. I see channels as basically separate ledgers that one or more members of a consortia can join. The proposed enhancements elevate a consortium to a higher level entity that leverages the existing API server and Agent. As I believe consortia management is different from channel management, I thought it made most sense to have a separate chaincode for it.

tatsu-sato (Thu, 17 Jun 2021 06:27:54 GMT):
Do you assume that a single consortia_ops chaincode will manage a single consortium, or multiple consortia?

toddinpal (Thu, 17 Jun 2021 14:33:46 GMT):
That's a really good question. Not sure how a single channel where the consortia_ops is instantiated could be part of multiple consortia. I suppose with the correct endorsement policies it could work, but it would potentially be leaking a lot of information about the consortium to other consortia on the same channel.

tatsu-sato (Tue, 22 Jun 2021 09:28:12 GMT):
We agree that a lot of information about the consortium may be leaked to other consortia on the same channel. Therefore, at least for the first implementation, it would be better to have one consortium_ops manage only a single consortium.

tatsu-sato (Tue, 22 Jun 2021 09:28:55 GMT):

20210622_OpsSC_DesignMemo.pdf

tatsu-sato (Tue, 22 Jun 2021 09:29:11 GMT):
Based on your suggestion so far, I have roughly designed and drawn the flow diagram (Please see pp. 0-1 in the slide). Does this diagram match your idea?

toddinpal (Wed, 23 Jun 2021 15:21:58 GMT):
As far as I can tell it looks good. The diagram is a little complicated so I'm not entirely sure it matches my proposal. Not sure what the x-y' operations are. It seems as though the NewOrg is contacting both Org1 and Org2's Admin server. Is that the case as I'm not sure why it would need to do that as its requests are basically being proxied through the temporary credentials provided for Org1. A more detailed sequence diagram showing just the new flow would really help, but I think we're very close to agreement.

tatsu-sato (Thu, 24 Jun 2021 08:53:14 GMT):
Thank you for your comments. >Is that the case as I'm not sure why it would need to do that as its requests are basically being proxied through the temporary credentials provided for Org1. First, we assume that adding a new member (e.g., NewOrg) requires approval from multiple existing organizations (e.g., Org1 and Org2)　(the terms of which depend on something like the consortium policy). If there were no x-y' operations, then Org2 would vote on a proposal to add NewOrg as in the 1-4 operation in the current implementation. In this case, in terms of the correctness of NewOrg's information (including MSP), Org2 would need to either trust Org1, or obtain MSP information from NewOrg separately and compare it and the information in the proposal as in the 0-1' and 1-3 operations in the current implementation. The x-y' operations help to turn this into system processes on OpsSC. Does it make sense? >A more detailed sequence diagram showing just the new flow would really help, but I think we're very close to agreement. Also, we are going to try to draw a more detailed sequence diagram about the new flow. Please allow us some time to draw the diagram.

tatsu-sato (Wed, 30 Jun 2021 10:07:06 GMT):

sequence.png

tatsu-sato (Wed, 30 Jun 2021 10:08:02 GMT):
I tried to make a sequence diagram (the step numbers correspond to the slides I made the other day) as I attached. While creating the diagram, I noticed that it would be hard to realize the sub-flow of adding NewOrg to ops-channel automatically via channel_ops (See the NOTE in the diagram). This flow shows only one example scenario. Because channel_ops only provides a simple feature to handle ConfigUpdate transactions, it would be consortium_ops that is responsible for supporting multiple specific scenarios (such as adding, removing organizations, renewing certificates for organizations). Your other suggestion "voting enhancements", on the other hand, seems to be relatively less difficult, with a smaller scope and impact on the current implementation. I think that the patches may be easier than ones for consortium_ops. In addition, I expect the consortium_ops will also need the enhanced voting function and will reuse its internal sub-functions. So, my idea is to start by considering Voting enhancements. Do you think this is a good idea? Or would you like to start from implementing consortium management?

toddinpal (Wed, 18 Aug 2021 17:52:38 GMT):
Voting enhancements are needed no matter what. So that is a fine place to start. Our interest though is getting to consortia management as that is the more difficult task for customers trying to create or maintain a consortia.

tatsu-sato (Fri, 27 Aug 2021 06:09:17 GMT):
@toddinpal Thank you for your reply. Let's work on the voting enhancements as the first step to further align our images and thoughts with each other. For the consortium management, I believe such a functionality is important, but as I mentioned you earlier on the chat, I don't yet fully understand your idea and how to implement it. So, it will help us if we can discuss this in parallel (e.g., answers to questions I posted earlier, additional design documents, etc.). Of course, submissions of any patches regarding OpsSC are also welcome.

tatsu-sato (Tue, 05 Oct 2021 10:46:32 GMT):
As a first step of voting enhancements, I have enhanced voting functions for chaincode_ops. The new chaincode_ops can cover a series of state transitions of chaincode update proposals, including proposal rejection and withdrawal, although it is not yet flexible enough (e.g., still only support simple majority). The current design is as follows: https://github.com/hyperledger-labs/fabric-opssc/tree/main/docs/design @toddinpal Is this implementation getting any closer to your proposals? If so, I will make similar improvements to channel_ops. We would love to get any comments or feedback about the enhancements from you.

tatsu-sato (Tue, 15 Feb 2022 04:02:09 GMT):
New chat channel on Discord is [here](https://discord.gg/G8uhB4hCvE) [Operations Smart Contract (OpsSC) for Hyperledger Fabric](https://github.com/hyperledger-labs/fabric-opssc)

rjones (Wed, 23 Mar 2022 17:25:00 GMT):