Date   

Regarding Client Orderer communication

Amal C Saji
 

Hi,
In Hyperledger Fabric after receiving endorser responses how the client send it to  orderer? Please give me a detailed flow to understand how the client request is reached to orderer?


Re: chaincode 2.0 problems

David Enyeart
 

1. You should be able to re-approveformyorg on the same peer, and the other peer (although it only needs to be done on one peer per org). I've tried this and it works in my environment... I can't think of a reason why you'd get ENDORSEMENT_POLICY_FAILURE on subsequent trials, as the approveformyorg transaction only requires endorsement on the org's own peer. See if you can re-approveformyorg on the same peer as before, just to help narrow down the problem...

2. Your LifecycleEndorsement policy is:

LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"

This will require the chaincode commit to be endorsed by both orgs (majority of '2' is '2'). I suspect you only sent the chaincode commit to one of the org peers. Alternatively, you could update your config to indicate that either org can endorse the commit of a new chaincode, e.g.:

LifecycleEndorsement:
Type: Signature
Rule: "OR('org0examplecom.admin.peer','org1examplecom.peer')"


Dave Enyeart

"Tong Li" ---01/07/2020 11:19:18 PM---Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincod

From: "Tong Li" <litong01@...>
To: fabric@...
Date: 01/07/2020 11:19 PM
Subject: [EXTERNAL] [Hyperledger Fabric] chaincode 2.0 problems
Sent by: fabric@...





Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincode but I have found two problems.

1. with 2 orgs and total of 4 peers, I can only do approveformyorg exactly two approvals. Once I have two approvals, see below output from checkcommitreadiness

{
"approvals": {
"org0examplecom": true,
"org1examplecom": true
}
}

That shows that I have two approvals from two different orgs. Then I tried to use two other peers to do the approval, when I tried that, I got an error below.

peer lifecycle chaincode approveformyorg --channelID mychannel --name simple2 --version 1.0 --package-id simple2_1.0:46b05e58222be471f9c305ad2ca3374e25343076502adcc82159865986dc3288 --init-required --sequence 1 --tls true --cafile $ORDERER_TLS_CA
2020-01-08 04:04:50.026 UTC [cli.lifecycle.chaincode] setOrdererClient -> INFO 001 Retrieved channel (mychannel) orderer endpoint: orderer1.example.com:7050
2020-01-08 04:04:52.130 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [2fb5dafa70316b2d69a736ab8a1be399668f724646e66241ab4c2ce28f873c80] committed with status (ENDORSEMENT_POLICY_FAILURE) at
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

Though I already have two approvals, I expect more approval from different peers wont fail, but it did, I do not know if that is expected behavior, please someone confirm one way or the other.

2. With two approvals from both orgs, I should have already met the majority requirement, but when I tried to do the commit, I was getting the exact same error as the approveformyorg process. Can someone please help with this problem? Please see the configtx.yaml file below if that can give a bit of clue. Thanks very much.

---
Organizations:
- &examplecom
Name: examplecom
ID: examplecom
MSPDir: keyfiles/ordererOrganizations/example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('examplecom.member')"
Writers:
Type: Signature
Rule: "OR('examplecom.member')"
Admins:
Type: Signature
Rule: "OR('examplecom.admin')"
- &org0examplecom
Name: org0examplecom
ID: org0examplecom
MSPDir: keyfiles/peerOrganizations/org0.example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('org0examplecom.admin', 'org0examplecom.peer', 'org0examplecom.client')"
Writers:
Type: Signature
Rule: "OR('org0examplecom.admin', 'org0examplecom.client')"
Admins:
Type: Signature
Rule: "OR('org0examplecom.admin')"
Endorsement:
Type: Signature
Rule: "OR('org0examplecom.peer')"

AnchorPeers:
- Host: peer1.org0.example.com
Port: 7051
- Host: peer2.org0.example.com
Port: 7051
- &org1examplecom
Name: org1examplecom
ID: org1examplecom
MSPDir: keyfiles/peerOrganizations/org1.example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('org1examplecom.admin', 'org1examplecom.peer', 'org1examplecom.client')"
Writers:
Type: Signature
Rule: "OR('org1examplecom.admin', 'org1examplecom.client')"
Admins:
Type: Signature
Rule: "OR('org1examplecom.admin')"
Endorsement:
Type: Signature
Rule: "OR('org1examplecom.peer')"

AnchorPeers:
- Host: peer1.org1.example.com
Port: 7051
- Host: peer2.org1.example.com
Port: 7051

Capabilities:
Channel: &ChannelCapabilities
V2_0: true

Orderer: &OrdererCapabilities
V2_0: true

Application: &ApplicationCapabilities
V2_0: true

Application: &ApplicationDefaults
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"

Capabilities:
<<: *ApplicationCapabilities

Orderer: &OrdererDefaults
OrdererType: etcdraft

Addresses:
- orderer1.example.com:7050
- orderer2.example.com:7050
- orderer3.example.com:7050

BatchTimeout: 2s

BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB

EtcdRaft:
Consenters:
- Host: orderer1.example.com
Port: 7050
ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
- Host: orderer2.example.com
Port: 7050
ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
- Host: orderer3.example.com
Port: 7050
ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt

Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"

Channel: &ChannelDefaults
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"

Capabilities:
<<: *ChannelCapabilities

Profiles:
OrgChannel:
Consortium: SampleConsortium
<<: *ChannelDefaults
Application:
<<: *ApplicationDefaults
Organizations:
- *org0examplecom
- *org1examplecom
Capabilities:
<<: *ApplicationCapabilities

OrdererGenesis:
<<: *ChannelDefaults
Capabilities:
<<: *ChannelCapabilities
Orderer:
<<: *OrdererDefaults
Organizations:
- *examplecom
Capabilities:
<<: *OrdererCapabilities
Application:
<<: *ApplicationDefaults
Organizations:
- <<: *examplecom
Consortiums:
SampleConsortium:
Organizations:
- *org0examplecom
- *org1examplecom


Tong Li
IBM Open Technology





chaincode 2.0 problems

Tong Li
 

Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincode but I have found two problems.

1. with 2 orgs and total of 4 peers, I can only do approveformyorg exactly two approvals. Once I have two approvals, see below output from checkcommitreadiness

{
"approvals": {
"org0examplecom": true,
"org1examplecom": true
}
}

That shows that I have two approvals from two different orgs. Then I tried to use two other peers to do the approval, when I tried that, I got an error below.

peer lifecycle chaincode approveformyorg --channelID mychannel --name simple2 --version 1.0 --package-id simple2_1.0:46b05e58222be471f9c305ad2ca3374e25343076502adcc82159865986dc3288 --init-required --sequence 1 --tls true --cafile $ORDERER_TLS_CA
2020-01-08 04:04:50.026 UTC [cli.lifecycle.chaincode] setOrdererClient -> INFO 001 Retrieved channel (mychannel) orderer endpoint: orderer1.example.com:7050
2020-01-08 04:04:52.130 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [2fb5dafa70316b2d69a736ab8a1be399668f724646e66241ab4c2ce28f873c80] committed with status (ENDORSEMENT_POLICY_FAILURE) at
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

Though I already have two approvals, I expect more approval from different peers wont fail, but it did, I do not know if that is expected behavior, please someone confirm one way or the other.

2. With two approvals from both orgs, I should have already met the majority requirement, but when I tried to do the commit, I was getting the exact same error as the approveformyorg process. Can someone please help with this problem? Please see the configtx.yaml file below if that can give a bit of clue. Thanks very much.

---
Organizations:
- &examplecom
Name: examplecom
ID: examplecom
MSPDir: keyfiles/ordererOrganizations/example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('examplecom.member')"
Writers:
Type: Signature
Rule: "OR('examplecom.member')"
Admins:
Type: Signature
Rule: "OR('examplecom.admin')"
- &org0examplecom
Name: org0examplecom
ID: org0examplecom
MSPDir: keyfiles/peerOrganizations/org0.example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('org0examplecom.admin', 'org0examplecom.peer', 'org0examplecom.client')"
Writers:
Type: Signature
Rule: "OR('org0examplecom.admin', 'org0examplecom.client')"
Admins:
Type: Signature
Rule: "OR('org0examplecom.admin')"
Endorsement:
Type: Signature
Rule: "OR('org0examplecom.peer')"

AnchorPeers:
- Host: peer1.org0.example.com
Port: 7051
- Host: peer2.org0.example.com
Port: 7051
- &org1examplecom
Name: org1examplecom
ID: org1examplecom
MSPDir: keyfiles/peerOrganizations/org1.example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('org1examplecom.admin', 'org1examplecom.peer', 'org1examplecom.client')"
Writers:
Type: Signature
Rule: "OR('org1examplecom.admin', 'org1examplecom.client')"
Admins:
Type: Signature
Rule: "OR('org1examplecom.admin')"
Endorsement:
Type: Signature
Rule: "OR('org1examplecom.peer')"

AnchorPeers:
- Host: peer1.org1.example.com
Port: 7051
- Host: peer2.org1.example.com
Port: 7051

Capabilities:
Channel: &ChannelCapabilities
V2_0: true

Orderer: &OrdererCapabilities
V2_0: true

Application: &ApplicationCapabilities
V2_0: true

Application: &ApplicationDefaults
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"

Capabilities:
<<: *ApplicationCapabilities

Orderer: &OrdererDefaults
OrdererType: etcdraft

Addresses:
- orderer1.example.com:7050
- orderer2.example.com:7050
- orderer3.example.com:7050

BatchTimeout: 2s

BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB

EtcdRaft:
Consenters:
- Host: orderer1.example.com
Port: 7050
ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
- Host: orderer2.example.com
Port: 7050
ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
- Host: orderer3.example.com
Port: 7050
ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt

Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"

Channel: &ChannelDefaults
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"

Capabilities:
<<: *ChannelCapabilities

Profiles:
OrgChannel:
Consortium: SampleConsortium
<<: *ChannelDefaults
Application:
<<: *ApplicationDefaults
Organizations:
- *org0examplecom
- *org1examplecom
Capabilities:
<<: *ApplicationCapabilities

OrdererGenesis:
<<: *ChannelDefaults
Capabilities:
<<: *ChannelCapabilities
Orderer:
<<: *OrdererDefaults
Organizations:
- *examplecom
Capabilities:
<<: *OrdererCapabilities
Application:
<<: *ApplicationDefaults
Organizations:
- <<: *examplecom
Consortiums:
SampleConsortium:
Organizations:
- *org0examplecom
- *org1examplecom


Tong Li
IBM Open Technology


Fabric Interoperability with other Blockchains #hyperledger-fabric #interoperability

@JorisHuynh
 

Hi community, 

For a project under development, our team is investigating different approaches to interoperability between Fabric and other Blockchain networks - and more specifically in the form of token exchanges. 
Are there any work already ongoing on this topic or known and recommended approaches? Any example of implementation using FabToken or ERC20?

Many thanks, 
Joris.


Hyperledger Fabric contributor meetings

David Enyeart
 

As we enter the new year, I'd like to remind everybody that Hyperledger Fabric contributor meetings occur every other Wednesday at 9am US Eastern / 14:00 UTC.

The next meeting is tomorrow, January 8.

If you'd like to propose an agenda topic, reply to this mailing list, or propose on RocketChat fabric-maintainers, and we'll work the agenda topic into a future meeting.

Typically the contributor meeting will include a quick release update and one or more deep dive topics such as feature proposals. However at tomorrow's meeting, we expect to kick off the new year by spending more time discussing some maintainer housekeeping topics (release branches, release cadence and LTS, fabric-rfcs, process for doc reviews).

More information, agendas, and recordings can be found at https://wiki.hyperledger.org/display/fabric/Contributor+Meetings.


Thanks,

Dave Enyeart


Re: Source of Randomness in Fabric

Yacov
 

In security related stuff I believe thatcrypto/rand is used, which I think simply reads from /dev/urandomwhile I think that some places in the code that just want to select random nodes to connect to might use math/rand, it depends on the use case.



From:        "Arnab" <arnabkaycee@...>
To:        hyperledger-fabric <hyperledger-fabric@...>
Date:        01/07/2020 02:38 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Source of Randomness in Fabric
Sent by:        fabric@...




Hi Fabric Experts,
 
I was exploring the codebase for sources of randomness in Fabric codebase for a client's Production system release.
Could anyone point me out the source files where random numbers are generated, and what is the source of it?
 
Regards,
Arnab Chatterjee
BOSCH






Source of Randomness in Fabric

Arnab
 

Hi Fabric Experts,

 

I was exploring the codebase for sources of randomness in Fabric codebase for a client's Production system release.

Could anyone point me out the source files where random numbers are generated, and what is the source of it?

 

Regards,

Arnab Chatterjee

BOSCH



Re: Does Orderer maintain ledger for each channel? #fabric-orderer

Adhav Pavan
 

Yes, Kevin.

Orderer will have a chain of the blocks(Blockchain) and it does not maintain the current state of the ledger.

We can find the blockchain at the following path inside the orderer container.

Path: /var/hyperledger/production/orderer/chains/mychannel

where mychannel is channel name. There could be multiple file named like blockfile_000000

Thank you.

Heartfelt Regards,
Pavan Adhav

Cell Phone:+91-8390114357 

E-Mail: adhavpavan@...



On Tue, Jan 7, 2020 at 8:58 AM Kevin X <kevinx8888@...> wrote:
It seems logical for orderer to maintain the ledger (at least the blockchain) for each registered channel? Can someone confirm this?
If not, how does it validate? 

Thanks


Re: New Chaincode Lifecycle and new Programming Model can co exist

Ross Tang <tangross@...>
 

Thank you. 


On Tue, Jan 7, 2020 at 4:01 AM Nikhil E Gupta <negupta@...> wrote:
Hey Ross,

The chaincode lifecycle APIs in the Fabric Node SDK were introduced for the Fabric 2.0 Alpha and Beta, but will not be in place for the 2.0 GA. To deploy a chaincode on a channel, you should use the peer CLI. You can find information on how to deploy a chaincode to a channel from the CLI in the first network tutorial: https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#install-and-define-a-chaincode

Nik



-----fabric@... wrote: -----
To: Matthew White <WHITEMAT@...>
From: "Ross Tang"
Sent by: fabric@...
Date: 01/06/2020 08:30AM
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] New Chaincode Lifecycle and new Programming Model can co exist

I identified my issues. 


In the step 4: Approve. 

It needs to mychaincode.setPackageId(packageId), before below piece of code

const tx_id = client.newTransactionID();const request = { target: peer1, chaincode: mychaincode, // The chaincode instance fully populated txId: tx_id }


In the step 6: Initialize, the documentation is wrong. (a) is_init flag no longer exists, (b) mychannel.sendTransaction should be corrected to mychannel.sendTransactionProposal

I simply turn off init_required.

const request = { chaincodeId : chaincodeId, fcn: 'Init', args: args, txId: tx_id, is_init: true // must be set to initialization}// starting the container will take longer than the normal request-timeoutconst init_results = await mychannel.sendTransaction(request, 20000);const orderer_request = { proposalResponses: init_results[0], proposal: init_results[1]}// send to the orderer to be committedconst results = await mychannel.sendTransaction(orderer_request);

Also, it needs initialise the channel at top of program. 

Client.setConfigSetting('initialize-with-discovery', true);



On 6 Jan 2020, at 5:32 PM, Matthew White <WHITEMAT@...> wrote:

Hello;
 
The Contract API is independent of the lifecycle changes; think of the lifecycle commands really treating your implementation as a black box. 
 
The error you've mentioned typically will occur when you have a mismatch of the names and identifies in the commands. When I get this I'll copy all my commands to a text file - and then double check all the ids that should match do. 
 
Hope this helps .
 
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
 
 
----- Original message -----
From: "Ross Tang" <tangross@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] New Chaincode Lifecycle and new Programming Model can co exist
Date: Thu, Jan 2, 2020 4:08 PM
 
I am trying out the Fabric V2 Beta. 
 
I can successfully commit an approved chaincode, under the new chaincode lifecycle. 
 
Then, I try to run legacy command `peer chaincode list —installed` or `peer chaincode list —instantiated`. Nothing returns. 
 
The new command `peer lifecycle chaincode querycommitted` returns normally. 
 
 
Also, I try to send transaction via new Contract api, with fabric-contract-api v1.4.4. It returns below error. 
 
{ Error: make sure the chaincode micc has been successfully defined on channel mychannel and try again: chaincode definition for ‘micc' exists, but chaincode is not installed…. 
 
 
In the documentation, it invoke transaction via low level api. 
 
 
QUESTION: 
Can new chaincode lifecycle and new Contract api working together? It seems that the new Contract api can only recognise chaincode deployed in legacy way.
 
Is my understanding correct?
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





--
Ross Tang
+852-91937419


Does Orderer maintain ledger for each channel? #fabric-orderer

Kevin X
 

It seems logical for orderer to maintain the ledger (at least the blockchain) for each registered channel? Can someone confirm this?
If not, how does it validate? 

Thanks


Re: New Chaincode Lifecycle and new Programming Model can co exist

Nikhil Gupta
 

Hey Ross,

The chaincode lifecycle APIs in the Fabric Node SDK were introduced for the Fabric 2.0 Alpha and Beta, but will not be in place for the 2.0 GA. To deploy a chaincode on a channel, you should use the peer CLI. You can find information on how to deploy a chaincode to a channel from the CLI in the first network tutorial: https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#install-and-define-a-chaincode

Nik



-----fabric@... wrote: -----
To: Matthew White <WHITEMAT@...>
From: "Ross Tang"
Sent by: fabric@...
Date: 01/06/2020 08:30AM
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] New Chaincode Lifecycle and new Programming Model can co exist

I identified my issues. 


In the step 4: Approve. 

It needs to mychaincode.setPackageId(packageId), before below piece of code

const tx_id = client.newTransactionID();const request = { target: peer1, chaincode: mychaincode, // The chaincode instance fully populated txId: tx_id }


In the step 6: Initialize, the documentation is wrong. (a) is_init flag no longer exists, (b) mychannel.sendTransaction should be corrected to mychannel.sendTransactionProposal

I simply turn off init_required.

const request = { chaincodeId : chaincodeId, fcn: 'Init', args: args, txId: tx_id, is_init: true // must be set to initialization}// starting the container will take longer than the normal request-timeoutconst init_results = await mychannel.sendTransaction(request, 20000);const orderer_request = { proposalResponses: init_results[0], proposal: init_results[1]}// send to the orderer to be committedconst results = await mychannel.sendTransaction(orderer_request);

Also, it needs initialise the channel at top of program. 

Client.setConfigSetting('initialize-with-discovery', true);



On 6 Jan 2020, at 5:32 PM, Matthew White <WHITEMAT@...> wrote:

Hello;
 
The Contract API is independent of the lifecycle changes; think of the lifecycle commands really treating your implementation as a black box. 
 
The error you've mentioned typically will occur when you have a mismatch of the names and identifies in the commands. When I get this I'll copy all my commands to a text file - and then double check all the ids that should match do. 
 
Hope this helps .
 
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
 
 
----- Original message -----
From: "Ross Tang" <tangross@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] New Chaincode Lifecycle and new Programming Model can co exist
Date: Thu, Jan 2, 2020 4:08 PM
 
I am trying out the Fabric V2 Beta. 
 
I can successfully commit an approved chaincode, under the new chaincode lifecycle. 
 
Then, I try to run legacy command `peer chaincode list —installed` or `peer chaincode list —instantiated`. Nothing returns. 
 
The new command `peer lifecycle chaincode querycommitted` returns normally. 
 
 
Also, I try to send transaction via new Contract api, with fabric-contract-api v1.4.4. It returns below error. 
 
{ Error: make sure the chaincode micc has been successfully defined on channel mychannel and try again: chaincode definition for ‘micc' exists, but chaincode is not installed…. 
 
 
In the documentation, it invoke transaction via low level api. 
 
 
QUESTION: 
Can new chaincode lifecycle and new Contract api working together? It seems that the new Contract api can only recognise chaincode deployed in legacy way.
 
Is my understanding correct?
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU




Re: New Chaincode Lifecycle and new Programming Model can co exist

Ross Tang <tangross@...>
 

I identified my issues. 


In the step 4: Approve. 

It needs to mychaincode.setPackageId(packageId), before below piece of code

const tx_id = client.newTransactionID(); const request = { target: peer1, chaincode: mychaincode, // The chaincode instance fully populated txId: tx_id }


In the step 6: Initialize, the documentation is wrong. (a) is_init flag no longer exists, (b) mychannel.sendTransaction should be corrected to mychannel.sendTransactionProposal

I simply turn off init_required.

const request = { chaincodeId : chaincodeId, fcn: 'Init', args: args, txId: tx_id, is_init: true // must be set to initialization } // starting the container will take longer than the normal request-timeout const init_results = await mychannel.sendTransaction(request, 20000); const orderer_request = { proposalResponses: init_results[0], proposal: init_results[1] } // send to the orderer to be committed const results = await mychannel.sendTransaction(orderer_request);

Also, it needs initialise the channel at top of program. 

Client.setConfigSetting('initialize-with-discovery', true);



On 6 Jan 2020, at 5:32 PM, Matthew White <WHITEMAT@...> wrote:

Hello;
 
The Contract API is independent of the lifecycle changes; think of the lifecycle commands really treating your implementation as a black box. 
 
The error you've mentioned typically will occur when you have a mismatch of the names and identifies in the commands. When I get this I'll copy all my commands to a text file - and then double check all the ids that should match do. 
 
Hope this helps .
 
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
 
 
----- Original message -----
From: "Ross Tang" <tangross@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] New Chaincode Lifecycle and new Programming Model can co exist
Date: Thu, Jan 2, 2020 4:08 PM
 
I am trying out the Fabric V2 Beta. 
 
I can successfully commit an approved chaincode, under the new chaincode lifecycle. 
 
Then, I try to run legacy command `peer chaincode list —installed` or `peer chaincode list —instantiated`. Nothing returns. 
 
The new command `peer lifecycle chaincode querycommitted` returns normally. 
 
 
Also, I try to send transaction via new Contract api, with fabric-contract-api v1.4.4. It returns below error. 
 
{ Error: make sure the chaincode micc has been successfully defined on channel mychannel and try again: chaincode definition for ‘micc' exists, but chaincode is not installed…. 
 
 
In the documentation, it invoke transaction via low level api. 
 
 
QUESTION: 
Can new chaincode lifecycle and new Contract api working together? It seems that the new Contract api can only recognise chaincode deployed in legacy way.
 
Is my understanding correct?
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Re: New Chaincode Lifecycle and new Programming Model can co exist

Matthew White
 

Hello;
 
The Contract API is independent of the lifecycle changes; think of the lifecycle commands really treating your implementation as a black box. 
 
The error you've mentioned typically will occur when you have a mismatch of the names and identifies in the commands. When I get this I'll copy all my commands to a text file - and then double check all the ids that should match do. 
 
Hope this helps .
 
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
 
 
----- Original message -----
From: "Ross Tang" <tangross@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] New Chaincode Lifecycle and new Programming Model can co exist
Date: Thu, Jan 2, 2020 4:08 PM
 
I am trying out the Fabric V2 Beta. 
 
I can successfully commit an approved chaincode, under the new chaincode lifecycle. 
 
Then, I try to run legacy command `peer chaincode list —installed` or `peer chaincode list —instantiated`. Nothing returns. 
 
The new command `peer lifecycle chaincode querycommitted` returns normally. 
 
 
Also, I try to send transaction via new Contract api, with fabric-contract-api v1.4.4. It returns below error. 
 
{ Error: make sure the chaincode micc has been successfully defined on channel mychannel and try again: chaincode definition for ‘micc' exists, but chaincode is not installed…. 
 
 
In the documentation, it invoke transaction via low level api. 
 
 
QUESTION: 
Can new chaincode lifecycle and new Contract api working together? It seems that the new Contract api can only recognise chaincode deployed in legacy way.
 
Is my understanding correct?
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Created JIRA story FABCG-12

bram.dufour8@...
 

Dear,

Following the contribution guide I would like to solicite some feedback on a JIRA story that I just created.

I also made a pull request with the implementation already. All CI tests have been passed and it is just waiting for review now.


Thanks a lot and have a great day!

Kind regards,
Bram


Re: New Chaincode Lifecycle and new Programming Model can co exist

Srinivasan Muralidharan
 

Try with the "lifecycle" option please

peer lifecycle chaincode queryinstalled
peer lifecycle chaincode querycommitted -C myc

and

"peer lifecycle chaincode --help" for all the available subcommands.

Murali

On Thu, Jan 2, 2020 at 11:08 AM Ross Tang <tangross@...> wrote:
I am trying out the Fabric V2 Beta. 

I can successfully commit an approved chaincode, under the new chaincode lifecycle. 

Then, I try to run legacy command `peer chaincode list —installed` or `peer chaincode list —instantiated`. Nothing returns. 

The new command `peer lifecycle chaincode querycommitted` returns normally. 


Also, I try to send transaction via new Contract api, with fabric-contract-api v1.4.4. It returns below error. 

{ Error: make sure the chaincode micc has been successfully defined on channel mychannel and try again: chaincode definition for ‘micc' exists, but chaincode is not installed…. 


In the documentation, it invoke transaction via low level api. 


QUESTION: 
Can new chaincode lifecycle and new Contract api working together? It seems that the new Contract api can only recognise chaincode deployed in legacy way.

Is my understanding correct?



--
Thanks,
Murali
"Practice is a means of inviting the perfection desired." - Martha Graham
“We ran and ran. We were exhausted, but we kept running.” - Homare Sawa after winning 2011 Women's Soccer world cup


Re: How to unpack a packaged chaincode

Mr.Phuwanai Thummavet
 

Thanks, I'll check it out.


On Fri, 3 Jan 2020, 03:08 Baohua Yang, <yangbaohua@...> wrote:
You can unpack it using the package  "github.com/hyperledger/fabric/core/common/ccprovider" easily.

Basically, you read the file, un-marshal and store the internal package as the tar file.


FYI.

On Thu, Jan 2, 2020 at 1:37 AM Mr.Phuwanai Thummavet <mr.thummavet@...> wrote:
Hi all,

Does anyone know how to unpack a packaged chaincode (.cds and/or .out extension)? I can't find any documentation regarding it.

Thanks.
--
Best Regards,
Phuwanai Thummavet
Blockchain Architect and Full-Stack Developer



--
Best wishes!

Baohua Yang


Re: How to unpack a packaged chaincode

Baohua Yang
 

You can unpack it using the package  "github.com/hyperledger/fabric/core/common/ccprovider" easily.

Basically, you read the file, un-marshal and store the internal package as the tar file.


FYI.

On Thu, Jan 2, 2020 at 1:37 AM Mr.Phuwanai Thummavet <mr.thummavet@...> wrote:
Hi all,

Does anyone know how to unpack a packaged chaincode (.cds and/or .out extension)? I can't find any documentation regarding it.

Thanks.
--
Best Regards,
Phuwanai Thummavet
Blockchain Architect and Full-Stack Developer



--
Best wishes!

Baohua Yang


Hyperledger Fabric Service Discovery With Multiple Host #fabric-questions

rajasalok1996@...
 

I wanted to use discovery service on a multi-host network(which we're using for production).  But I wanted to run the node service in such a way, that even if I don't run the service in the same docker swarm, all the request go through. So I had looked the way people normally use  fabric discovery :
await channel.initialize({discover:true, asLocalhost:true})
I can't use it this as `asLocalhost`, replaces the hostname with localhost. Moreover, even if the port for peer is not mapped at 7051 the code does not work. 
So ideally I was looking for a way to map the returning hostname and port, with one in configuration. I looked inside the code https://github.com/hyperledger/fabric-sdk-node/blob/v1.4.4/fabric-client/lib/Channel.js#L253, I found out that if we're using service discovery there's no flag or a way to change the url mapping. So using fabric's service discovery with multi-host network is not possible ?
 


New Chaincode Lifecycle and new Programming Model can co exist

Ross Tang <tangross@...>
 

I am trying out the Fabric V2 Beta. 

I can successfully commit an approved chaincode, under the new chaincode lifecycle. 

Then, I try to run legacy command `peer chaincode list —installed` or `peer chaincode list —instantiated`. Nothing returns. 

The new command `peer lifecycle chaincode querycommitted` returns normally. 


Also, I try to send transaction via new Contract api, with fabric-contract-api v1.4.4. It returns below error. 

{ Error: make sure the chaincode micc has been successfully defined on channel mychannel and try again: chaincode definition for ‘micc' exists, but chaincode is not installed…. 


In the documentation, it invoke transaction via low level api. 


QUESTION: 
Can new chaincode lifecycle and new Contract api working together? It seems that the new Contract api can only recognise chaincode deployed in legacy way.

Is my understanding correct?


Re: some question about fabric

David Enyeart
 

I suspect there was some misunderstanding around the second point... missing data comes into play when a peer can't find the private data (at commit time) that it is entitled to based on private data collection definitions. In these cases the peer will periodically attempt to reconcile the missing private data by asking other entitled peers for the private data on a configurable basis. Private data is not included in blocks, therefore ordering nodes never have the private data, and there is no concept of missing data or missing blocks on ordering nodes. I suggest you read the documentation on private data which goes into detail about how private data is configured and disseminated:
https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html
https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html


Dave Enyeart

"Jay Guo" ---01/02/2020 02:37:13 AM---hi, an orderer store *all* blocks of _channels it participates in_ (in

From: "Jay Guo" <guojiannan1101@...>
To: shijian fu <wentingyear@...>
Cc: fabric <fabric@...>
Date: 01/02/2020 02:37 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] some question about fabric
Sent by: fabric@...





hi,

an orderer store *all* blocks of _channels it participates in_ (in
case of Raft), or _all channels_ (in case of Kafka). I don't think the
second point in your statement is accurate. Could you point me to the
original post? thx

- J


On Tue, Dec 31, 2019 at 5:34 PM shijian fu <wentingyear@...> wrote:
>
> Hi, our program group have used fabric for about 8 months. And there are some questions unsolved until now.
> here is the question list:
> 1. Would orderer node store all the block of a channel when there is only one channel and without using any private data? Or the orderer node just need to store the newest N block of a channel?
> 2. I have read some post in stack overflow which indicated that a peer 'A'  from one organization  will pull blocks from peers from other organizations when peer 'A' pull those blocks which are "missing"(not include private data) in orderer.
> In which condition would blocks missing in orderer?
>







4041 - 4060 of 11518