Please help me if my conceptualization is incorrect ---
Setup:
I am trying to understand how to achieve decentralization in Hyperledger Fabric - smart contracts. Assume Org 1 and Org 2 are in the same channel. Each of these Org have peers and endorsers. The endorsement policy is 100% of Org 1 and Org 2
Question:
In my understanding the SAME SMART CONTRACT needs to be installed in both Org 1 and Org 2 peer. In other words, So when a incoming transaction is sent to Org 1 and Org 2, the same smart contract is executed by both peers.
Is this understanding correct?
REF: https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/smartcontract.html
In the PaperNet network, the smart contract is shared by the different network participants, such as MagnetoCorp and DigiBank. The same version of the smart contract must be used by all applications connected to the network so that they jointly implement the same shared business processes and data.
If it is correct, the smart contract code must have been written by some developer (Possible Org 1 who originated the blockchain network),How is this decentralization?
I my understanding, In a decentralized environment, should not be there a way where ORG 2 can separately create its own smart contract and install and use that to validate / commit?
If this is possible, any articles / blogs that show how to do this?
As you can see te question is nothing to do with endorsement policies etc.
thanks in advance and please feel free to correct me if my basic understanding of decentralization is incorrect
Regards
VJ
Hyperledger fabric is a DLT(decentralized ledger technology) platform. As from the word DLT, you may understand here ledger is decentralized. So, yes your basic understanding is wrong.
Smart Contract:
Its similar like to real world contract between multiple parties, on which all parties has been agreed(Like a property deed on which both parties i.e. seller and buyer will agree). Similar here in Hyperledger fabric, a smart contract is business logic, on which all parties(all participating organization, in particular channel) have to agree. So, you may say a smart contract will be written by some developer of any organization and all other organization can review the source code and will agree to use that smart contract.
How it is decentralized:
So, in every DLT, ledger is decentralized, i.e. each party will be having their own copy of transactional data.In Hyperledger fabric, each organization is having a peer that contains transactional data and world state.
Related
My names is Antonio and i come from Italy. In this days i'm designing an fabric architecture for an important project.
My network will have one channel that represents a community of n peer. This latter can endor the transaction and to do basic operations.In that community there will be and Administrator.
is The ordere a physical peer where someone have that role? In that case i will define the Community Manager responsable for the Channel configuration, network configuration and as orderer.
The administrator will receive the reward from external national institutions. The idea is to distribute that reward to the peer in the community with a smart contract.
The Administrator, therefore orderer, will receive the reward then the smart contract automatically distribute the reward based on some parameters. The question is:
The smart contract can receive the events from orderer, therefore administrator network and channel, of reward received and automatically distribute the reward?
Antonioy
you probably misunderstand a bit how the Hyperledger Fabric works. The orderer is a separate entity and it receives transaction candidates from the peers putting them into blocks and them broadcasting these blocks in a specific order (that's why it's called "Orderer"). You can not receive events from the orderer inside the chaincode (the name of smart contracts in Fabric) and the chaincode is agnostic to what peers it is being run on, you can only work with an identity of a signer of a transaction that has been sent to a peer for endorsement.
I'm developing a blockchain solution on Hyperledger Fabric. This solution should be used to provide the interactions bewtween manufacturers and suppliers. I supposed that in this case there should be a single blockchain ledger with information about manufactured goods. This ledger should be used both by manufacturers (to register new goods) and by suppliers (to update goods: for example, mark some item as delivered).
The Hyperledger Fabric official documentation (https://hyperledger-fabric.readthedocs.io/en/release-2.0/fabric_model.html#privacy) says that the ledger is strictly linked with a channel:
Blockquote
Hyperledger Fabric employs an immutable ledger on a per-channel basis, as well as chaincode that can manipulate and modify the current state of assets.
So I intended to create a single channel and install 2 different chaincodes on:
chaincode for manufacturers (to register manufactured goods)
chaincode for suppliers (to mark registered goods as delivered)
But when I prepared a demo application, I revealed, that the second chaincode cannot query the items created with the first one (i.e. each chaincode has an isolated ledger).
How can I deploy the ledger, which should be shared between organizations having various roles (access rights), if I don't want to force all of them (manufacturers and suppliers) to install the full chaincode (containing both 'register goods' and 'mark as delivered' operations) on their environment?
Thanks & Regards
Igor Egorov
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.
Following is given as part of hyperldedger fabric documentation for v1.1:
Switching between organizations to sign a config transaction (or to do anything else) is not reflective of a real-world Fabric operation. A single container would never be mounted with an entire network’s crypto material. Rather, the config update would need to be securely passed out-of-band to an Org2 Admin for inspection and approval.
Say we have 4 organizations Org1,Org2,Org3 and Org4 and we are in the process of creating Org5.
Let Org1 and Org2 belong to same cli whereas Org3 be in Org3cli and Org4 be in Org4cli
Let us say all initial steps to launch org5 into network has been done.
On coming to peer channel signconfigtx I first sign from cli using peers of Org1 and Org2.But I need one more signature as majority says 3.
I go to Org3cli as sign on behalf of org3 but since peer channel signconfigtx method is local cli (Containing Org1 and Org2) doesn't come to know about it.(result is not send to the orderer).
So given in a real world scenario that a single cli isn't expected to handle all configuration,How do u handle interaction between 2 different cli ?
As you have correctly interpreted, the documentation is telling you that setting up a multi-org network using a single control point which has access to the crypto material for multiple organizations is not reflective of how things work in the real world. We do this in the samples to make it easy to bootstrap a multi-org sandbox network.
In the real world, you would need to pass the serialized configuration (update) transaction out of band to all of the organizations who need to sign it based on the channel policy. Fabric currently does not provide any tools for handling the out of band communication ... this is left up to the members of the network to decide.
There are vendors out there that are providing governance and lifecycle management tools for Fabric as part of their offerings, but there are currently no Fabric-specific tools available in open source for this.
Here is our use-case:
Anna would like to sell her shares to Peter, and Olga needs to approve it (as an owner of the company).
How would that work on blockchain hyperledger fabric/composer with consensus?
In particular, what part of that is a transaction, what is a proposal (is a proposal requires a physical approval of a transaction by a living person?) and how is that handled on blockchain, what happens in the application and outside of the application.
Please be as specific as possible.
Thanks!
A few things first:
Composer uses whatever consensus algorithm the underlying blockchain is configured to use. So; Hyperledger Fabric at the moment offers SOLO or KAFKA.
KAFKA offers fault tolerance only, not byzantine fault tolerance.
So:
Endorsement Policies do exist which is what you are describing. It does not require approval by a living person, you can make everything programmatic, it could even be an IoT device. The approver must simulate the transaction and see if they agree with the output. Olga is the approver in your scenario.
It's important to make all chaincode (transactions in Composer) deterministic, so they can be simulated in that way.
There is a good description on transaction flow on Fabric's docs: http://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
I'm releasing a paper in a month that has a section on consensus comparisons and Composer/Fabric specifically. I can send you a draft if you're interested further.
There are two aspects to your question, one is the approval aspect of a living person and second is the integrity of the ledger state (consensus).
I will explain in the reverse order.
Consensus Part
So Hyperledger Fabric is an enterprise solution that targets to maintain a consistent ledger on which all organization of the consortium needs to agree upon. This is achieved by combining the ledgers of multiple organization into one ledger and the transactions recorded in this one ledger will include transaction from each party.
These transactions are not random transactions but rather implementation of Smart Contract called chaincode in Fabric terminology. Whenever a chaincode is deployed on a Fabric channel(a private subnet associated with its own ledger) it initializes the World State i.e default assets and their values.
Next each organization agree upon an endorsement policy, for example 1 peer from each organization should endorse the transaction(called transaction proposal in this state), the endorsement is simply a read-write set of the transaction having read set(values of assets before transaction simulation), write set(values of assets after the transaction simulation). If the endorsement from all peers(all those peers that satisfy the endorsement policy) is same, which means the world state of assets is consistent across all the peers(atleast those that satisfy endorsement policy) and hence ledger data integrity is achieve.
The consensus further includes batching transactions into blocks and ordering of the transactions within the block by ordering service which validates the endorsers signatures again and the World State validation is done one final time when the block reaches peers for committing.
Approval part
When you have an approval process that requires a participant interaction, it is something that you will have to take care of in your chaincode. Composer is the best place to start.
From Composer examples look at the CarAuction example and you will understand the for each state transition you will have to have registery e.g a seller participant owns an asset Car but when the Car is auctioned for selling it has to be added to a listing registry using transaction where it will be visible to all bidder participants, this movement of state of Car asset is achieved by a transaction AuctionMyCardOrSomething invoked by authorized party here seller. Then when the Auctioneer(another participant with a different role) executes another transaction called closed bidding then the Car ownership can be transferred to the highest bidder if all conditions are satisfied. Node that placing a bid is also a transaction.
Pay attention the the Auctioneer and state transitions in this example and the same model can be applied to your case. Each time state transition is required you have to execute a transaction and update the ledger.
Hope this helps.