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

Joe Alewine <joe.alewine@...>

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@...
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

Join to automatically receive all group messages.