I will ask you thought Endorsement Policy example below
peer chaincode instantiate -C <channelid> -n mycc -P "AND('Org1.member', 'Org2.member')"
My understanding(Promise)
Org1.member or Org2.member refer to Peer.
The example means that Org1.member and Org2.member should have to get the same result as instantiating mycc.
Question
If Org1.member and Org2.member have same chaincode, could their
result be different?
Are Org1.member and Org2.member refer to one peer of Organization?
(2-1. If so, does the peer be set on organization randomly?)
Can I use regular expressions like "AND('Org1.member > 10', 'Org2.member > 10')"
I hope you have referred to the fabric documentation on endorsement already. If not, then please find it here endorsement-policies
A principal is described in terms of the MSP that is tasked to validate the identity of the signer and of the role that the signer has within that MSP. Currently, two roles are supported: member and admin. Principals are described as MSP.ROLE, where MSP is the MSP ID that is required, and ROLE is either one of the two strings member and admin. Examples of valid principals are 'Org0.admin' (any administrator of the Org0 MSP) or 'Org1.member' (any member of the Org1 MSP).
AND (Org1.member, Org2.member) means that for successful endorsement, the transaction proposal response which is sent to Orderer ( from the client SDK) is expected to be signed by the member certificate of Peer of org1 and member certificate of the Peer of org2
It is possible to have different result if your chaincode is Non-Deterministic ( ie, say its getting current time etc and putState() ). So write sets can be different.
Org1.member & Org2.member are two different Peers. One peer belonging to Org1 and another peer belonging to Org2. [ You cannot have the Peer belonging to two organizations randomly ]
I am not sure. Please check the link of Fabric Documentation above.
Related
I've created a network based on 2 organizations under one two CA's (one normal, and one for TLS certificates). There's one orderer and one peer per organization.
I run the network as binaries on separate virtual machines.
After I create identities for organizations, I add the signcert directory from the CA admin to their respective msp directories as admincerts. I then enroll the identities on their respective machines, and add the admincerts directory. I create the ordererchannel genesis block and run the orderer binary. Next I generate mychannel.tx sign it with the peer's identity and submit the channel creation transaction (as far as I know, admin privilages are needed to successfully run peer channel create). Then, with the same identity, I try to join my peer to mychannel with peer channel join,and I get this error:
Error: proposal failed (err: bad proposal response 500: access denied for [JoinChain][mychannel]: [Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]])
Which is weird, because I could create the channel without problems, so the identity I'm using must be an admin. This happens on both peers. I would appreciate some input on the issue.
JoinChannel checks that the submitter is an admin of the peer itself. Peer admin(s) is(are) stores in local MSP admincerts directory.
The Fabric documentation explains in detail what a chaincode definition is and which role it plays for the lifecycle and governance of a chaincode. It says, that an organisation needs to approve a definition in order to use the chaincode. What it doesn't explain - imho - is, how to VIEW a chaincode defintion prior approving it.
Question: Is there a command to view a chaincode definition? Or is there another workflow that I missed, so that an organization can study the definition before approving it?
The parameters to the approval is the definition. You can think of a chaincode definition as being all the parameters required to execute and validate a chaincode transaction. You supply the definition via the parameters you see in the documentation, so, it is in fact impossible to perform the approval without already knowing the definition.
Generally speaking, the definition is agreed to out of band, and then all participating organization approve the externally agreed to definition. However, if you are on a network and wishing to discover what other members have approved, or what definitions have committed, there are a number of query utilities provided via the peer CLI. You can see what definition an org has approved using the queryapproved subcommand, you can see what orgs have approved a particular definition using the checkcommitreadiness subcommand, and you can view the currently committed definition using the querycommitted subcommand or by using the queryinstalled subcommand.
Step 1: Each organization have to agree on a chaincode package which have a unique hash value and a label, they all may get the chaincode package from a developer and if someone try to change something on chaincode, that chaincode package will give different hash value compare to others.
Step 2: Each organization will install that chaincode package on there peers.
Step 3: After that each organization get an identical Package ID which is a combination on that chaincode package's hash value and label. You can get it by "peer lifecycle chaincode queryinstalled" command.
step 4: Now you can approve that identical Package ID with channelID, name, version, init-required etc etc from your organization. Before approval you can also check the checkcommitreadiness.
step 5: TO check the checkcommitreadiness of that identical Package ID with channelID, name, version, init-required, sequence 1 etc etc follow the command given below. If it gets enough approval, It's ready for commit.
So each organization will give approval of it's own chaincode with other definitions like channelID, name, version, init-required etc etc & due to the system a fraudulent activity will not get enough approval.
Check whether a chaincode definition is ready to be committed on a channel.
Usage:
peer lifecycle chaincode checkcommitreadiness [flags]
Flags:
--channel-config-policy string The endorsement policy associated to this chaincode specified as a channel config policy reference
-C, --channelID string The channel on which this command should be executed
--collections-config string The fully qualified path to the collection JSON file including the file name
--connectionProfile string The fully qualified path to the connection profile that provides the necessary connection information for the network. Note: currently only supported for providing peer connection information
-E, --endorsement-plugin string The name of the endorsement plugin to be used for this chaincode
-h, --help help for checkcommitreadiness
--init-required Whether the chaincode requires invoking 'init'
-n, --name string Name of the chaincode
-O, --output string The output format for query results. Default is human-readable plain-text. json is currently the only supported format.
--peerAddresses stringArray The addresses of the peers to connect to
--sequence int The sequence number of the chaincode definition for the channel (default 1)
--signature-policy string The endorsement policy associated to this chaincode specified as a signature policy
--tlsRootCertFiles stringArray If TLS is enabled, the paths to the TLS root cert files of the peers to connect to. The order and number of certs specified should match the --peerAddresses flag
-V, --validation-plugin string The name of the validation plugin to be used for this chaincode
-v, --version string Version of the chaincode
Global Flags:
--cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
--certfile string Path to file containing PEM-encoded X509 public key to use for mutual TLS communication with the orderer endpoint
--clientauth Use mutual TLS when communicating with the orderer endpoint
--connTimeout duration Timeout for client to connect (default 3s)
--keyfile string Path to file containing PEM-encoded private key to use for mutual TLS communication with the orderer endpoint
-o, --orderer string Ordering service endpoint
--ordererTLSHostnameOverride string The hostname override to use when validating the TLS connection to the orderer.
--tls Use TLS when communicating with the orderer endpoint
As answered before chaincode defination is the combination of parameters.
My fabric network's consortium(in configtx.yaml) has two organizations: ORG1 and ORG2. ORG1 has 4 main peers and ORG2 has only 1 peer. ORG2 peer's only purpose is to have the copy of the ledger(for the auditing purpose).
They all joined the same channel and let's say ORG1's admin already installed/instantiated the chaincode version 0.1
Now, ORG2's admin will be also able to 'peer chaincode upgrade" to version 0.2 with the same chaincode name and when the proposal reaches one of the ORG1 peers, it will say something like :
endorsement failure during invoke. response: status:500 message:"cannot retrieve package for chaincode [chaincode name]/0.2, error open /var/hyperledger/production/chaincodes/[chaincode name]/0.2: no such file or directory"
How we completely prevent ORG2 from upgrading the chaincode version? so that only ORG1's admin can perform the administrative operations?
I have searched the ACL, but it seems the administrative operations are not controlled by ACL settings.
After the research, we figured out we can set this on the instantiate policy on chaincode package.
please see below fabric document:
https://hyperledger-fabric.readthedocs.io/en/release-1.4/commands/peerchaincode.html#peer-chaincode-package
with the flag -i, you can set the instantiate policy when packing the chaincode. Then only the Org(s) allowed on the policy will be able to instantiate or upgrade the chaincode on the channel
Am working on hyperledger fabric, i have network setup of 2 org,1 channel and 1 orderer.
I installed chaincode(Say CH1) in Org1, with endoserment policy "AND(Org1.member,Org2,member)". Now i need to install same chaincode(CH1) in Org2 to validate and endorse transaction.
Since chaincode(CH1) installed in Org2(for endorsement purpose), also permitted to execute transaction using same chaincode(CH1), which will affect state, created by Org1. How to prevent this?
You need to separate 3 concepts here:
Installing chaincode
Instantiating chaincode on a channel
Endorsing chaincode
Installing chaincode simply makes the bytes of the chaincode available on the peer on which it is installed.
Instantiating chaincode on a channel makes that chaincode available for execution on the channel.
The endorsement policy determines which peers need to successfully execute and sign a transaction (technically peers sign the endorsement response).
In your case, installing the chaincode on the peers for both Org1 and Org2 makes the chaincode bytes available to the peers.
Instantiating the chaincode on a channel will make it available for execution.
The endorsement policy you set requires that a peer from Org1 AND a peer from Org2 must execute and endorse the transaction.
Once the client has collected the endorsements, the transaction will be send to the ordering service and then delivered to all peers in the channel. When the peers in the channel receive a transaction which involves CH1, they will check to make sure that the endorsement policy has been met (in this case that a peer from both Org1 and Org2 signed the transaction) and only then can it be committed (after the other validation checks)
I am a beginner on hyperledger fabric programming. I was wondering where exactly we define the signature policy (SignaturePolicy / ImplicitMetaPolicy) for the network? Is it in some configuration file?
I saw video in below link but I could not understand: "Signature Policy Sample"
Can anyone please guide me?
The signature, or endorsement policy is defined when instantiating a chaincode deployed to a given channel using the -P switch using the following syntax: EXPR(E[, E...]) where EXPR is a boolean expression (AND or OR) and E is either a principle or a nested boolean.
For instance, a policy of AND(Org1.member, Org2.member) would require that a member of Org1 and Org2 each sign a transaction for it to be validated. A policy of AND(Org1.member, OR(Org2.member, Org3.member)) would require a member of Org1 and a member of Org2 or Org3 sign a transaction for it to be validated.
Here's an example chaincode instantiate command:
peer chaincode instantiate -C <channelid> -n mycc -P "AND('Org1.member', 'Org2.member')"
The documentation can be found in the Endorsement Policy section of of the Hyperledger Fabric documentation.