1. #fabric-chaincode
  2. Topics

#fabric #raft Orderers and organization, how to organize them? #fabric #raft

Jean-Gaël Dominé <jgdomine@...>
 

Hi all,

This topic is more a conceptual one around orderers and organizations as we are moving from solo mode to Raft.
In solo mode, as we had a single orderer, the organization matter was quite simple :)

But with Raft we were thinking of having 4 orderers. We just have doubts about how they should be structured on an organization level.
In fact, we created two different 2-orderer organizations. One would be linked to peer organization A and the other one to peer organization B.
Thus, A and B have the same number of orderers.
CAs from A and B would respectively be responsible for issuing the certificates/keys of "their" orderers.

Well, that's one way of designing it we had but we really are not sure that is the good practice.

Would anybody have insight on that matter?

Thank you in advance
Joe Alewine <joe.alewine@...>
 

Jean-Gael,
 
Check out https://hyperledger-fabric.readthedocs.io/en/release-1.4/orderer/ordering_service.html. It should have some of the answers to your questions.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Jean-Gaël Dominé" <jgdomine@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Thu, Nov 21, 2019 10:39 AM
 
Hi all,

This topic is more a conceptual one around orderers and organizations as we are moving from solo mode to Raft.
In solo mode, as we had a single orderer, the organization matter was quite simple :)

But with Raft we were thinking of having 4 orderers. We just have doubts about how they should be structured on an organization level.
In fact, we created two different 2-orderer organizations. One would be linked to peer organization A and the other one to peer organization B.
Thus, A and B have the same number of orderers.
CAs from A and B would respectively be responsible for issuing the certificates/keys of "their" orderers.

Well, that's one way of designing it we had but we really are not sure that is the good practice.

Would anybody have insight on that matter?

Thank you in advance
 
Jean-Gaël Dominé <jgdomine@...>
 

Thanks for you quick reply.

I read this documentation a while ago and indeed some elements are present there:
I have a couple of questions though about some sentences I found:
Just like peers, ordering nodes belong to an organization. And similar to peers, a separate Certificate Authority (CA) should be used for each organization
I feel a bit confused about the notion of organization. I'll take a more concrete example to illustrate and check that I get it right.
Let's take two companies/organizations Org1 and Org2 that have 3 peers each.
Let's say that I want an orderer in each organization so that the ordering service is decentralized.

Then, from my understanding, comes the configtx.yaml file that introduces its own notion of organization since in it I'm going two define 4 organizations:
  • 2 for each orderer: Org1Ord and Org2Ord
  • 2 for each set of peers: Org1 and Org2
From the extract of the documentation, I understand that a dedicated CA should be in place for each organization, meaning I should have 4 CAs.
  • CAOrg1Ord to issue certificates/keys for Org1Ord
  • CAOrg1 to issue certificates/keys for Org2Ord
  • CAOrg2Ord to issue certificates/keys for Org1
  • CAOrg2 to issue certificates/keys for Org2
They could all be Root Certificate Authorities or CAOrgXOrd could be an intermediate of CAOrgX (or the other way around) but in any case the root certificate would be provided by the company in charge of it.

Does my illustration make sense ? Am I understanding things correctly?

Thank you
Joe Alewine <joe.alewine@...>
 

Jean-Gael,
 
So Fabric organizations are similar to organizations as we think of them in the real world (Bank of America is an "organization"), but there are differences that affect the way you should organize things (if you'll forgive the pun).
 
Organizations are defined through an MSP, which is a series of folders that, most importantly, establish two things: 1) the admins of the organization (there are other kinds of users, but admins are the most important), and 2) the root of trust for the organization (its root CA). These organizations then, as you know, are associated with a node during the creation of the node, signaling that the node is "owned" by the organization. 
 
The best practice is for each organization to have its own CA (its own root CA cert), and for individuals or groups or corporations or whathaveyou to create separate organizations for the organizations that own peers and own ordering nodes. This separation of organizations reflects the separation of the roles of the different nodes, even if ultimately the same Bank of America-type "organization" owns all of the CAs and ordering nodes and peers.
 
From a deployment perspective, this means you should have one CA (one root CA, at least, though you're free to create intermediate CAs if you want) that creates an organization that owns all of your ordering nodes. And you should have a separate CA that creates an organization that owns all of your peers. The decentralization of your ordering service will actually come through other people creating their own CAs and their own ordering organizations and then their own nodes and joining their nodes and your nodes together to form the ordering service. 
 
Hope that helps,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Jean-Gaël Dominé" <jgdomine@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 8:30 AM
 
Thanks for you quick reply.

I read this documentation a while ago and indeed some elements are present there:
I have a couple of questions though about some sentences I found:
Just like peers, ordering nodes belong to an organization. And similar to peers, a separate Certificate Authority (CA) should be used for each organization
I feel a bit confused about the notion of organization. I'll take a more concrete example to illustrate and check that I get it right.
Let's take two companies/organizations Org1 and Org2 that have 3 peers each.
Let's say that I want an orderer in each organization so that the ordering service is decentralized.

Then, from my understanding, comes the configtx.yaml file that introduces its own notion of organization since in it I'm going two define 4 organizations:
  • 2 for each orderer: Org1Ord and Org2Ord
  • 2 for each set of peers: Org1 and Org2
From the extract of the documentation, I understand that a dedicated CA should be in place for each organization, meaning I should have 4 CAs.
  • CAOrg1Ord to issue certificates/keys for Org1Ord
  • CAOrg1 to issue certificates/keys for Org2Ord
  • CAOrg2Ord to issue certificates/keys for Org1
  • CAOrg2 to issue certificates/keys for Org2
They could all be Root Certificate Authorities or CAOrgXOrd could be an intermediate of CAOrgX (or the other way around) but in any case the root certificate would be provided by the company in charge of it.

Does my illustration make sense ? Am I understanding things correctly?

Thank you
 
 
Jean-Gaël Dominé <jgdomine@...>
 

Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël
Harris Niavis
 

Hi Joe and Jean,

Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers.

So instead of creating new organizations for each orderer (Org1Ord and Org2Ord), can I have a single Org1 for both peer1 and orderer1 and another Org2 for both peer2 and orderer2?

Best,
Harris

On Fri, 22 Nov 2019 at 10:24, Jean-Gaël Dominé <jgdomine@...> wrote:
Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël


Joe Alewine <joe.alewine@...>
 

Harris,
 
This is not a recommended configuration. Each entity (ie, Bank of America) should have an org that owns their peers and a separate org that owns their ordering nodes. Regulations or business preferences might make it desirable (or necessary) for BOA to split up their operations even further (a different CA for their investment arm than for their housing arm, for example), but ordering nodes and peers should not have the same root of trust (the same root CA).
 
Fabric will ALLOW you to do this --- there is no internal mechanism that checks to make sure the roots of trust are different --- but it is not recommended.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: Harris Niavis <harniavis@...>
To: "Jean-Gaël Dominé" <jgdomine@...>, joe.alewine@...
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 10:43 AM
 
Hi Joe and Jean,
 
Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers.
 
So instead of creating new organizations for each orderer (Org1Ord and Org2Ord), can I have a single Org1 for both peer1 and orderer1 and another Org2 for both peer2 and orderer2?
 
Best,
Harris
 
On Fri, 22 Nov 2019 at 10:24, Jean-Gaël Dominé <jgdomine@...> wrote:
Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël

 

 

 
 
 
Harris Niavis
 

Thanks Joe,

So it is technically feasible but not recommended for decentralization purposes, right? 

I could imagine a use case where we don't have such a large organization with different arms like BoA and it could make sense to have a single organization for peers and orderers. e.g. the fisherman in the supply chain paradigm.
Should we still split the peers and orderers (of the same conceptual organization) to different fabric organizations?

Best,
Harris

On Fri, 22 Nov 2019 at 10:57, Joe Alewine <Joe.Alewine@...> wrote:
Harris,
 
This is not a recommended configuration. Each entity (ie, Bank of America) should have an org that owns their peers and a separate org that owns their ordering nodes. Regulations or business preferences might make it desirable (or necessary) for BOA to split up their operations even further (a different CA for their investment arm than for their housing arm, for example), but ordering nodes and peers should not have the same root of trust (the same root CA).
 
Fabric will ALLOW you to do this --- there is no internal mechanism that checks to make sure the roots of trust are different --- but it is not recommended.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 
----- Original message -----
From: Harris Niavis <harniavis@...>
To: "Jean-Gaël Dominé" <jgdomine@...>, joe.alewine@...
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 10:43 AM
 
Hi Joe and Jean,
 
Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers.
 
So instead of creating new organizations for each orderer (Org1Ord and Org2Ord), can I have a single Org1 for both peer1 and orderer1 and another Org2 for both peer2 and orderer2?
 
Best,
Harris
 
On Fri, 22 Nov 2019 at 10:24, Jean-Gaël Dominé <jgdomine@...> wrote:
Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël

 

 

 
 
 



--
Harris Niavis
Yale Institute of Network Science (YINS)
University of Thessaly (UTH)
Centre for Research and Technology Hellas (CERTH)
s: niavisharris
Joe Alewine <joe.alewine@...>
 

Yes, as I keep saying, your peers and ordering nodes should belong to different Fabric organizations. If there are subgroupings within a large entity like a bank, this separation should still happen between peer and orderer orgs, only now within each subgrouping.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: Harris Niavis <harniavis@...>
To: Joe Alewine <Joe.Alewine@...>
Cc: fabric@..., "Jean-Gaël Dominé" <jgdomine@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 11:14 AM
 
Thanks Joe,
 
So it is technically feasible but not recommended for decentralization purposes, right? 
 
I could imagine a use case where we don't have such a large organization with different arms like BoA and it could make sense to have a single organization for peers and orderers. e.g. the fisherman in the supply chain paradigm.
Should we still split the peers and orderers (of the same conceptual organization) to different fabric organizations?
 
Best,
Harris
 
On Fri, 22 Nov 2019 at 10:57, Joe Alewine <Joe.Alewine@...> wrote:
Harris,
 
This is not a recommended configuration. Each entity (ie, Bank of America) should have an org that owns their peers and a separate org that owns their ordering nodes. Regulations or business preferences might make it desirable (or necessary) for BOA to split up their operations even further (a different CA for their investment arm than for their housing arm, for example), but ordering nodes and peers should not have the same root of trust (the same root CA).
 
Fabric will ALLOW you to do this --- there is no internal mechanism that checks to make sure the roots of trust are different --- but it is not recommended.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 
----- Original message -----
From: Harris Niavis <harniavis@...>
To: "Jean-Gaël Dominé" <jgdomine@...>, joe.alewine@...
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 10:43 AM
 
Hi Joe and Jean,
 
Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers.
 
So instead of creating new organizations for each orderer (Org1Ord and Org2Ord), can I have a single Org1 for both peer1 and orderer1 and another Org2 for both peer2 and orderer2?
 
Best,
Harris
 
On Fri, 22 Nov 2019 at 10:24, Jean-Gaël Dominé <jgdomine@...> wrote:
Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël

 

 

 
 
 
 
 
--
Harris Niavis
Yale Institute of Network Science (YINS)
University of Thessaly (UTH)
Centre for Research and Technology Hellas (CERTH)
s: niavisharris
 
Yueming Xu
 

As I understand it, each org is similar to a real-world business entity, and should have its own CA. Each org may or may not own an orderer node. If an org contributes both peer and orderer nodes, however, you need to define 2 MSP’s, e.g., org1MSP and org1OrdererMSP. But you can use the same org1CA to issue certificates for both MSP’s, since they belong to the same business entity. 

Yueming Xu
Jean-Gaël Dominé <jgdomine@...>
 

Yueming,

From the description you gave and Joe's explanation, you should have two CAs instead one of to issue the certificates for both MSPs (One for org1MSP and one for org1OrdererMSP). Joe explained that the same root certificate (thus Certificate Authority) should not issue the peers and orderers artifacts.
Technically nothing prevents you from doing so but from a best practice perspective, that should be the case.

Hope I'm not mistaken

Jean-Gaël
Todd Little <toddjlittle@...>
 

Why is it a "best practice" to have different CAs for peers and for orderers?  What potential problems is this solving over having a single CA for both?

Regards,
Todd
Yueming Xu
 

I do not think you’d benefit by using different root CA’s for orderer and peer of the same org. Each org already need 2 root CA’s, one for signing cert, the other for TLS. If you double that, it’s just too much management overhead for not much gain, I think. 

Yueming Xu
Jean-Gaël Dominé <jgdomine@...>
 

Hi all,

I cannot say why this is considered as the "best practice... I was merely trying to summarize what Joe was explaining to me. But I don't have the give a good explanation to you.

Sorry

1 - 14 of 14