Hyperledger Fabric Ownership of the Orderer Organization

Question

According to most examples, there are logically minimum 3 organizations (org1, org2, orderer). Actually there are only 2 physical organizations (org1, org2). Either one of the organizations or an agreed 3rd party has to hand over the orderer organization's responsibilities.

Q1: Who should be the owner of the "Orderer Organization" in Hyperledger Network?

Q2: Would there be a security flaw if an organization becomes the "Orderer Organization" and owns all of the orderer nodes (Raft) in the Hyperledger Network?

Answer 1

Q1: Who should be the owner of the "Orderer Organization" in Hyperledger Network?

Answer to first question is tricky. Just to give preface to answer, because Fabric’s design relies on deterministic consensus algorithms, any block validated by the peer is guaranteed to be final and correct. Ledgers cannot fork the way they do in many other distributed and permissionless blockchain networks like Bitcoin or Etherium. Orderer/Ordering node does this transaction ordering, which along with other orderer nodes forms an ordering service.

Just like peers, ordering nodes belong to an organization and everything that interacts with a blockchain network, including orderers acquires their organizational identity from their digital certificate and their Membership Service Provider (MSP) definition.

Every channel runs on a separate instance of the Raft protocol, which allows each instance to elect a different leader. This configuration also allows further decentralization of the service in use cases where clusters are made up of ordering nodes controlled by different organizations. While all Raft nodes must be part of the system channel, they do not necessarily have to be part of all application channels. Channel creators (and channel admins) have the ability to pick a subset of the available orderers and to add or remove ordering nodes as needed (as long as only a single node is added or removed at a time).

So Channel Creator and Channel Admins can choose subset of the available orderers or add/remove single orderer. Also multiple organizations can control cluster having ordering nodes. So it is upto you whom you call owner.

Q2: Would there be a security flaw if an organization becomes the "Orderer Organizaion" and owns all of the orderer nodes (Raft) in the Hyperledger Network?

Just some points to Note before answering definitively:

• Orderers can not see transaction data, they only order the transactions.
• Everything that interacts with a blockchain network, including peers, applications, admins, and orderers, acquires their organizational identity from their digital certificate and their Membership Service Provider (MSP) definition.
• Although an organization can act both in an ordering and application role but it is a highly discouraged configuration. By default the /Channel/Orderer/BlockValidation policy allows any valid certificate of the ordering organizations to sign blocks. If an organization is acting both in an ordering and application role, then this policy should be updated to restrict block signers to the subset of certificates authorized for ordering.
• Before any transaction(ordering) is authorized it is validated by peers and after validation consensus transaction is committed.
• In Hyperledger Fabric, the blocks generated by the ordering service are final. Once a transaction has been written to a block, its position in the ledger is immutably assured. As we said earlier, Hyperledger Fabric’s finality means that there are no ledger forks and validated transactions will never be reverted or dropped.
• Raft follows a “leader and follower” model, where a leader node is elected (per channel) and its decisions are replicated by the followers.

So if above points are considered in implementation with security consideration it should not be a security flaw since orderer is only doing ordering, can't see transaction, is validated by Peers before transaction is committed, Peers & orderers are different organisations and once transaction is committed in order it is final & immutable in it's order & position.

Sources:

https://hyperledger-fabric.readthedocs.io/en/release-2.0/orderer/ordering_service.html

https://hyperledger-fabric.readthedocs.io/en/release-2.0/Fabric-FAQ.html

https://medium.com/@kctheservant/add-a-new-organization-on-existing-hyperledger-fabric-network-2c9e303955b2

https://medium.com/swlh/hyperledger-chapter-6-hyperledger-fabric-components-technical-context-767985f605dd