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
Related
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 don't know some details about Fabric in this document.
Document: The application verifies the endorsing peer signatures and compares the proposal responses.
Is it necessary to have all the responses the same when verifying， or most of them？
If it is part of them, what is the ratio?
Whether it can be controlled by the Fabric SDK?
Document: The ordering service does not need to inspect the entire content of a transaction in order to perform its operation, it simply receives transactions from all channels in the network, orders them chronologically by channel, and creates blocks of transactions per channel.
Raft and Kafka are only used to guarantee availability, not for voting. Is this correct?
Document: Transaction is validated and committed.
When committing, is there a process of voting verification?
The application does not actually need to check anything (it's
optional but a good way to avoid sending invalid transactions).
When you instantiate chaincode on a channel, you set the endorsement policy for that chaincode. The endorsement policy specifies how many organization's peers must sign the response. This is actually enforced during validation on the peers (after the peer receives blocks/transaction from the orderer but prior to committing the data). If there are not enough signatures to satisfy the policy, transactions are marked invalid and state is not committed.
With Fabric v1.2 and later, clients can use the discovery service to obtain the minimum list of peers required to meet the endorsement policy for chaincode on each channel.
Kafka / Raft are used to ensure that all ordering service nodes process transactions and deliver blocks in the same order. With Fabric v1.4.1 you will have the option to use Raft consensus rather than Kafka.
See comment in 2. about enforcing endorsement policies during validation.
i have been reading the docs of hyperledger fabric but i have been stuck on something. what does this paragraph actually mean:
"The split between channel and local MSPs reflects the needs of organizations to administer their local resources, such as a peer or orderer nodes, and their channel resources, such as ledgers, smart contracts, and consortia, which operate at the channel or network level.
It’s helpful to think of these MSPs as being at different levels, with MSPs at a higher level relating to network administration concerns while MSPs at a lower level handle identity for the administration of private resources. MSPs are mandatory at every level of administration — they must be defined for the network, channel, peer, orderer, and users."
MSP is both a module in Fabric's nodes (peers and orderers) that validates identities and classifies them to principals, and also an instance of such a module.
So, you can have multiple MSPs in each peer/orderer and they all belong to some channel, or they just belong to the node itself.
Every instance of an MSP is used by Fabric policies and access control code to define who can do what.
The Fabric policy infrastructure, and all access control code, either directly or indirectly use MSPs.
So, if the node uses an access control check, or a policy evaluation in the context of some channel, it uses some MSP in that channel.
If it uses an access control check (or a policy evaluation) that is not related to any channel, it uses the local MSP.
Examples of when channel MSPs are used is - when a peer commits a block, it checks the endorsement policy of the transactions of chaincodes. The endorsement policy is fetched from the world state (which resides in the database) and then the policy string is converted to a policy instance, which uses a channel "MSP manager" which contains all MSPs defined for that channel. Every such MSP - belongs to some organization in the channel.
An Example of when the local MSP is used, is - when you install a chaincode on a peer - the operation is not in the context of any channel, so - the local MSP checks that the gRPC call comes with a signature that is signed by some peer administrator, and the definition of who is the admin is defined in the local MSP.
I am new to blockchain and just have the basic understanding in the Bitcoin PoW scheme.
After reading the key concepts of Hyperledger Fabric https://hyperledger-fabric.readthedocs.io/en//latest/key_concepts.html, I have some difficulties in understanding the setting.
In the Membership section here, it said "KeyStore for Private Key: This folder is defined for the local MSP of a peer or orderer node." But Organization can have multiple Peer nodes. So which nodes are responsible of the private key then? My understanding is that private should be stored at one place only.
For the whole Peer section (see this link), it seems to suggest that the Peer nodes only validate the endorsed transactions according to the endorsement policy. What about the consensus algorithms? (e.g. something like PoW, PoS, PoET)
I know that Fabric implements Kafka (see Hyperledger Architecture, Volume 1). But then, I also find out the paper in arXiv that further confuses me A Byzantine Fault-Tolerant Ordering Service for the Hyperledger Fabric Blockchain Platform. This paper seems to suggest that the orderer nodes are also involved in Byzantine Fault Tolerance (BFT). However, my understanding of orderer nodes is that they are only responsible for ordering the endorsed transactions and broadcast them to all the peer nodes (see this link).
Now, I am confused how the Hyperledger Fabric network verifies the endorsed transactions. What is the default consensus algorithm and how does it fit into the picture of the Peer section as described from the official website?
Thanks.
So which nodes are responsible of the private key then? My
understanding is that private should be stored at one place only.
Each node has its own private key, stored securely in its own file system, or on a hardware device accessible only to it.
it seems to suggest that the Peer nodes only validate the endorsed
transactions according to the endorsement policy. What about the
consensus algorithms? (e.g. something like PoW, PoS, PoET)
The consensus is done on the order of the transactions and not on their content.
The endorsement policy, dictates whether a transaction is seen as valid or not by the network.
This paper seems to suggest that the orderer nodes are also involved
in Byzantine Fault Tolerance (BFT). However, my understanding of
orderer nodes is that they are only responsible for ordering the
endorsed transactions and broadcast them to all the peer nodes
Right, that's correct - The current Fabric implementation has no BFT orderer. However, the consensus is pluggable and in case you implement your own orderer, you can just switch the Kafka based one with a BFT one.
Now, I am confused how the Hyperledger Fabric network verifies the
endorsed transactions. What is the default consensus algorithm and how
does it fit into the picture of the Peer section as described from the
official website?
It verifies them via 2 ways:
Endorsement policy - each transaction has a target to one or more chaincodes (namespaces in the DB). Each such namespace has an chaincode has its own endorsement policy. If the transaction is signed by peers such that the endorsement policy is satisifed, then the transaction is deemed as one that passed the endorsement policy.
MVCC(Multi version concurrency control) - A transaction that read keys during its execution, records their versions, and then upon commit the peer checks that the versions didn't change, so the causality of the data still remains intact.
In Fabric, we know the term of peers, according to the docs, as
a fundamental element of the network because they host ledgers and
smart contracts
Based on that, I assume that peers are some kind of hardware servers that organization assign.
But I'm not so sure about that, so I ask:
What exactly is the physical representation of peers in real-case organization?
Is it a computer that must always be online? Is it operated by some person in the related organizations?
It is also said in this paper on page 6 about the consensus process, that
In particular, this requires all endorsers
as determined by the policy to produce the same execution result
(i.e., identical readset and writeset). Then, the client proceeds to
create the transaction and passes it to the ordering service
This leaves me to the next question:
In real life usage, if the endorsing peers failed temporarily (say, due to electricity issue), does it mean that the blockchain transactions can't happen in that time?
A peer is a software service. An organization can have multiple peers running for resilience. When a peer fails, for whatever reason, when it is restarted, it will catch up with the other peers in an organization's cluster either by receiving missing transaction blocks from the orderer, or by gossiping with other peers.
If an endorsing peer fails, it does not necessarily mean that the transaction processing will be blocked. Again, an org can have multiple redundant endorsing peers, and depending on the endorsement policy chosen for the channel, propose the transaction to other endorsing peers for that channel in order to receive the requisite number of endorsements to satisfy the policy.
Of course, if you ran a single endorsing peer for a channel/network... then yes, if it failed then transaction processing would be blocked. That would not be a wise deployment choice;-) Fabric was designed for resilience.