From fabric First Network example , why set up organization? what is orga use for?
In Hyperledger Fabric, every participant (client, peer, orderer) belongs to some organization.
Organizations have certificate authorities that provide their members (clients, peers, orderers) enrollment certificates in order to authenticate one another, and other organizations.
It also provides an easy way to aggregate participants together in order to define access control rules that span multiple clients, peers and orderers without having to define for each participant separately
Related
Assume we have 100+ organizations in Hyperledger fabric network. One Org can choose another Org randomly and perform a transaction.
The transaction includes sensitive information that should be only accessible by the 2 Orgs involved in the transaction.
How can we achieve this functionality, hide the transaction details from other Orgs.
You need to use private data collection (PDC) for permitted orgs in transaction. In this case all other orgs will have the hash only.
I have isolated two organizations into two different channels. Organizations one and two are part of channel1, and organizations three and four are part of channel two. I would like to ask if it is possible that one peer on channel2 access queries the ledger of channel1 and vice-versa. If it is possible how can I do it?
I very much appreciate your help.
It is not possible in your current setup because the peers who have joined the channel can only access that channel. Peers that are not part of the channel can not access the ledger data.
What you can do is, bring the peers on the common channel and can use PDC (Private Data Collection) to make the transaction private to the organization/Organizations.
Hyperledger Fabric is a private and permissioned blockchain.
A channel is a private blockchain overlay which allows for data isolation and confidentiality. A channel-specific ledger is shared across the peers in the channel, and transacting parties must be authenticated to a channel in order to interact with it. Channels are defined by a Configuration-Block.
At channel creation time, all organizations added to the channel must be part of a consortium. However, an organization that is not defined in a consortium may be added to an existing channel like by adding an new organization into that channel with fulfilling endorsement policy.
So to be a part of a channel, your organizational peer must need access according to the consortium. A peer can be a part of multiple channel and the ledger/database of every peer within a channel is identical/same, to invoke/query the ledger we need smart contact which is also identical among every peer of that channel. So if my peer server is a part of two channel, I need two ledgers/databases. To access the data of a ledger for invoke/query, you need corresponding smart contract.
According to your current setup, it's not possible and this is the nature of private-permissioned blockchain and to make it possible, you have to change the consortium with appropriate endorcement.
Only way to make peer on channel2 to access ledger of channel1 is to join the peer into channel1. Otherwise it is not possible to access the data.
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?
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
Sorry for the long question but Hyperledger is a fairly complex system.
Reading the Blockchain network In the section Generating and accepting transactions
In contrast to peer nodes, which always host a copy of the ledger, we
see that there are two different kinds of peer nodes; those which host
smart contracts and those which do not. In our network, every peer
hosts a copy of the smart contract, but in larger networks, there will
be many more peer nodes that do not host a copy of the smart contract
How to design the blockchain network and to decide how many peers should have smart contracts and how many should not?, Is there any design rules or patterns ?
When we have multiple organizations, should every organization has an endorsing peer, or they all can have only one within one organization and all other can call it ?
How to design the blockchain network and to decide how many peers
should have smart contracts and how many should not?, Is there any
design rules or patterns ?
My rule of thumb is - you first think about the endorsement policy, and then you install the chaincode on peers that belong to organizations that are in the endorsement policy.
Then, you can also optionally install the chaincode for query-only transactions (that don't get into the Blockchain) on peers of organizations regardless of their involvements in the endorsement policy or not, because it makes sense that a client would want to query its own organization (since it trusts it the most).
The only corner case is that sometimes the code of the chaincode is not known and the organizations of the endorsement policy, do not want to share it.
When we have multiple organizations, should every organization have an
endorsing peer, or they all can have only one within one organization
and all other can call it ?
It depends on the use case. Some organizations have clients only, and some organizations have peers only, or only orderers.
Whether an organization is an endorser for a chaincode, usually depends on the endorsement policy.
I am using "https://hyperledger.github.io/composer/tutorials/deploy-to-fabric-multi-org" for Deploying Hyperledger Composer blockchain business network to Hyperledger Fabric(mulriple organizations). In this tutorial why we are creating two connection profiles
The difference between two connection profiles shown in below image.
Why we should create two connection profiles for onenter image description heree organization, i.e 1. Org1 only and Org1 and Org2 ?
The need for the distinct Org1 and Org2 only cards is related to rights on the Fabric. The initial Runtime Install uses the distinct cards (and connection.json) and subsequent commands - Network Start and Commands from Alice and Bob use cards (and connection profiles) that access all peers regardless of organisation as they have rights to the Network.
For the tutorial (and the Dev Fabric) we have combined the Peer Install role and the Channel admin role into a single identity called PeerAdmin. Then you need an identity to handle the Fabric-ca server issuer role. You also need an identity bound to the initial business network participant. These roles have been combined into one for alice/bob.