How Chaincode features works? How following chaincode features are achieved
Chaincode lifecycle flow is used in 2.x where all the organization have their say in chaincode to be used in channel in which chaincode definition is committed to ledger. At what point this committed chaincode definition is used? Is this chaincode definition committed to channel later used by peer and orderer when ordering the transaction to check if there are correct endorsements?
Lifecycle 2.x allows to add different chaincode logic on the peers and checkcommit readiness still returns true when organization even approves different chaincode packages.
How this works?
Why different fingerprint is not detected as was detected in v1.4?
At what point this fingerprint check is done
Chaincode lifecycle flow is used in 2.x where all the organization
have their say in chaincode to be used in channel in which chaincode
definition is committed to ledger. At what point this committed
chaincode definition is used? Is this chaincode definition committed
to channel later used by peer and orderer when ordering the
transaction to check if there are correct endorsements?
The 1.x lifecycle has a definition in the "lscc" namespace.
Similarly, the 2.x lifecycle has a definition in the "_lifecycle" namespace.
The chaincode definition is used at the validation of the transaction.
The lifecycle namespace (lscc or _lifecycle namespace) can be thought of as a table that has a row for each application chaincode, and the primary key of the table is the application chaincode name.
Lifecycle 2.x allows to add different chaincode logic on the peers and
checkcommit readiness still returns true when organization even
approves different chaincode packages.
Right, what is important for the 2.x lifecycle is the endorsement policy of the chaincode, and the code itself is not important because the code content does not end up being part of the lifecycle namespace.
This is to make the smart contracts more flexible and to support different logic for different organizations, or have organizations be able to update the dependencies of their chaincodes without needing to collaborate with other organizations on a chaincode upgrade.
How this works? Why different fingerprint is not detected as was
detected in v1.4? At what point this fingerprint check is done
In 1.x, the code package of the chaincode was part of the fingerprint. Now, in 2.x it's not part of the fingerprint anymore and you only care about the "chaincode sequence".
For more info check the lifecycle playback, Jason mentions fingerprinting at time ~ 30m in the video and about sequences at ~ 25m.
Related
In Hyperledger ledger, how could I list endorsing peers of a specific chaincode?
I have a channel with 5 peers but I need that only three of them endorse a transaction while the other two need only to access to same ledger.
You can use the discovery service to get the endorsing peer. Here you can find some information:
https://hyperledger-fabric.readthedocs.io/en/latest/discovery-overview.html
Hyperledger fabric has a CLI tool to query the discovery service:
https://hyperledger-fabric.readthedocs.io/en/latest/discovery-cli.html
For node.js applications, you can follow the tutorial here:
https://hyperledger.github.io/fabric-sdk-node/release-1.4/tutorial-discovery.html
With the latest Fabric Client SDKs (personally using GO client), you don't need to deal with endorsement policies. Client SDK already does this dirty work for you. It extracts:
Which organizations' endorsements are required for this chaincode, key (key level endorsement policy can be defined as well), etc.
Which peers currently exist in the system and what are their MSPs (from discovery service).
According to these information, client SDK builds a set of necessary peers then sends your transaction request to all. It waits response from requested endorsers. Once it collects all responses, it sends to orderer and so on.
If you have a special case which you need to manually set endorsing peers of your choice (I had one use case about private collections so I had to use this approach) check out discovery service API of your client SDK.
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.
Must the chaincode creator be trusted by whole network? From my understanding chaincodes are installed and instantiated by some authorized user. And if my understanding is correct they are distributed in binary form.
Let's assume that we have OrgA and OrgB each of them having one peer and endorsing policy requires both of them to sign the transaction proposal.
Peer.OrgA
Peer.OrgB
Let's assume that OrgA is instantiating chaincode in the channel. Is there any way for OrgB to validate its logic?
I understand that due to endorsement process and read-write sets we are protected on blockchain level against double spending.
But what about business level? What if chaincode is doing some tricky manipulations?
For chaincode instantiation and installation you can stablish policies on who can do it. Also for a chaincode to be instantiated it is needed to create packages that in order to be instantiated and installed need to be signed by all the participants of the network, or whatever policy that you have. You can read more about it here.
https://hyperledger-fabric.readthedocs.io/en/release-1.4/chaincode4noah.html
This packages can be reviewed by the organizations.
Let's say we have a 6 peer in Hyperledger Fabric network and 3 organization. Each organization has 2 peers. All 6 peers belongs to one single channel.
What if one of the peer is down? Is the network still validate transaction and creates block?
This depends on the way your chaincode is set up. On a channel you have chaincode deployed, this chaincode has a specific version number. When you instantiate the chaincode or when you upgrade it, you can specify which endorsement policy to use.
This endorsement policy dictates what rules a transaction must satisfy in order to be validated. To be more specific, it specifies the organisations who must endorse it, via their endorsing peers, of course.
You can read more about it here: https://hyperledger-fabric.readthedocs.io/en/release-1.3/endorsement-policies.html
If one of your orgs has 2 endorsing peers and the endorsement policy requires one peer, then if one goes down, you're still fine.
I have simple question about Hyperledger Fabric. so here is my question:
I know that for committing peers (ordinary peers) it's not 100% necessary to have chaincode installed, but every peer should have ledger and that's 100% necessary.
so suppose I am committing peer and I have not chaincode installed, but I have ledger of course. Now new block arrives from ordering peer.
1) I should check blocks validity, so I need to query ledger
2) I should add this block, so I need to update ledger.
So how can I do this two above without chaincode? Isn't chaincode necessary for above operations? (query and update)
To check the transaction/block's validity, the peer does not need to have the chaincode, the readwrite set available in the transaction is compared against the ledger (available in all peer) to decide the validity.
And adding the block to the ledger is not dependent upon the validity check. If it was found invalid, it will still be added to the ledger but with an invalid tag.
You cannot query a peer without having a chaincode. Must need chaincode installed in the peer in order to query | invoke.
Hyperledger Fabric has two types of peers
1) Endorsing peers
2) Committing Peers
Endorsing peers must need a chaincode which means you need to install chaincode on endorsing peers because its duty is to make sure the transaction owner has sufficient rights and it simulates that transaction against the ledger for that it needs a chaincode interface in order to complete simulation.
Once the simulation is done it sends back the R/W sets and simulation result to client and client will send this to the orderer
Orderer then distributes to committing peers ( No need to install chaincode)
Whole: Applications generate a transaction proposal which they send to each of the required set of peers for endorsement. Each of these endorsing peers then independently executes a chaincode using the transaction proposal to generate a transaction proposal response. It does not apply this update to the ledger, but rather simply signs it and returns it to the application.