Date   

CouchDB crashs due to some error resulting Peer getting crashed #fabric #hyperledger-fabric

santosh kumar
 

HI Team,

We are using HLF 1.4.2 , and getting below error on our couchDB. Please suggest any solution to mitigate this issue. 

[error] 2021-06-27T10:51:21.242416Z nonode@nohost emulator -------- Too many processes

[error] 2021-06-27T10:51:21.242448Z nonode@nohost emulator -------- Too many processes

[error] 2021-06-27T10:51:21.242473Z nonode@nohost emulator -------- Too many processes

[error] 2021-06-27T10:51:21.242515Z nonode@nohost <0.8929.1304> -------- _all_docs open error: test_test 63541:: {error,system_limit} [{erlang,spawn_link,[erlang,apply,[#Fun<rexi_monitor.1.96358472>,[]]],[]},{erlang,spawn_link,1,[]},{fabric_doc_open,go,3,[{file,[115,114,99,47,102,97,98,114,105,99,95,100,111,99,95,111,112,101,110,46,101,114,108]},{line,50}]},{fabric_view_all_docs,open_doc_int,4,[{file,[115,114,99,47,102,97,98,114,105,99,95,118,105,101,119,95,97,108,108,95,100,111,99,115,46,101,114,108]},{line,271}]},{fabric_view_all_docs,open_doc,4,[{file,[115,114,99,47,102,97,98,114,105,99,95,118,105,101,119,95,97,108,108,95,100,111,99,115,46,101,114,108]},{line,260}]}]

[error] 2021-06-27T10:51:21.242508Z nonode@nohost <0.5729.1102> -------- _all_docs open error: test_test 63900 :: {error,system_limit} [{erlang,spawn_link,[erlang,apply,[#Fun<rexi_monitor.1.96358472>,[]]],[]},{erlang,spawn_link,1,[]},{fabric_doc_open,go,3,[{file,[115,114,99,47,102,97,98,114,105,99,95,100,111,99,95,111,112,101,110,46,101,114,108]},{line,50}]},{fabric_view_all_docs,open_doc_int,4,[{file,[115,114,99,47,102,97,98,114,105,99,95,118,105,101,119,95,97,108,108,95,100,111,99,115,46,101,114,108]},{line,271}]},{fabric_view_all_docs,open_doc,4,[{file,[115,114,99,47,102,97,98,114,105,99,95,118,105,101,119,95,97,108,108,95,100,111,99,115,46,101,114,108]},{line,260}]}]

[error] 2021-06-27T10:51:21.242749Z nonode@nohost <0.260.0> -------- gen_server rexi_server terminated with reason: system_limit at erlang:spawn_opt/1 <= erlang:spawn_monitor/3 <= rexi_server:handle_cast/2(line:72) <= gen_server:try_dispatch/4(line:615) <= gen_server:handle_msg/5(line:681) <= proc_lib:init_p_do_apply/3(line:240)

  last msg: {'$gen_cast',{doit,{<0.19558.1942>,#Ref<0.0.258736132.219590>},undefined,{fabric_rpc,open_doc,[<<"shards/60000000-7fffffff/test_test.1623094991">>,<<"62870">>,[deleted,deleted,{user_ctx,{user_ctx,<<"">>,[<<"_admin">>],<<"default">>}}]]}}}


Re: Private Data Purging - FAB-5097

Matthew White
 

 
 
 
 
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: "Artem Barger" <artem@...>
Sent by: fabric@...
To: "Matthew White" <whitemat@...>
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Private Data Purging - FAB-5097
Date: Mon, Jun 28, 2021 11:17 AM
 
Hi Matt, Can you please share the design doc you have found? Best, Artem Barger 28 июня 2021 г., в 13:06, Matthew White <whitemat@...> написал(а):  Hello; Just an FYI note to the community that I'm starting to actively look at ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi Matt,
 
Can you please share the design doc you have found?
 
Best,
        Artem Barger 
 
28 июня 2021 г., в 13:06, Matthew White <whitemat@...> написал(а):
 

Hello;
 
Just an FYI note to the community that I'm starting to actively look at https://jira.hyperledger.org/browse/FAB-5097 
On-demand removal of private data to support making a solution using Fabric easy to meet GDPR and other privacy requirements. 
 
There has been some work on this already based on the google docs I've found; thank you for this. 
Going to use FAB-5097 as the main tracking point so please add any comments there (or mailing list) if you have any.
 
Just started on the scoping of this - so couldn't answer at the moment "does it do X?"  but if you believe that this feature should do 'X' please let me know :-)
 
Thanks. Matthew
 
 
 
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"
 

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

 
 

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: Private Data Purging - FAB-5097

Artem Barger
 

Hi Matt,

Can you please share the design doc you have found?

Best,
        Artem Barger 

28 июня 2021 г., в 13:06, Matthew White <whitemat@...> написал(а):


Hello;
 
Just an FYI note to the community that I'm starting to actively look at https://jira.hyperledger.org/browse/FAB-5097 
On-demand removal of private data to support making a solution using Fabric easy to meet GDPR and other privacy requirements. 
 
There has been some work on this already based on the google docs I've found; thank you for this. 
Going to use FAB-5097 as the main tracking point so please add any comments there (or mailing list) if you have any.
 
Just started on the scoping of this - so couldn't answer at the moment "does it do X?"  but if you believe that this feature should do 'X' please let me know :-)
 
Thanks. Matthew
 
 
 
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"
 

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



Private Data Purging - FAB-5097

Matthew White
 

Hello;
 
Just an FYI note to the community that I'm starting to actively look at https://jira.hyperledger.org/browse/FAB-5097 
On-demand removal of private data to support making a solution using Fabric easy to meet GDPR and other privacy requirements. 
 
There has been some work on this already based on the google docs I've found; thank you for this. 
Going to use FAB-5097 as the main tracking point so please add any comments there (or mailing list) if you have any.
 
Just started on the scoping of this - so couldn't answer at the moment "does it do X?"  but if you believe that this feature should do 'X' please let me know :-)
 
Thanks. Matthew
 
 
 
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"
 

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: Cross chaincode invoke, ACL policy problem (MSP not defined in called channel, but in caller) #fabric-chaincode

Sergio C
 

Hi,
Thank you very much for your response.

ChaincodeA only makes use of GetState calls, so I'm not modified the ledger.
I can't install chaincodeA in channel-2, I need to keep it isolated in another channel (channel-1).

I'm getting this warning when I call chaincodeB from channel-2 (logs from Org3Peer):
2021-06-28 08:52:56.258 UTC [policies] SignatureSetToValidIdentities -> WARN 0d7 invalid identity: certificate subject=CN=Admin@...,OU=admin,L=New York,ST=New York,C=US serialnumber=249376481855686298878436353699729151421 error="MSP Org4MSP is not defined on channel"
And the policy error:
 Failed to handle INVOKE_CHAINCODE. error: failed evaluating policy on signed data during check policy [/Channel/Application/Readers]: [implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied]
And the Application policy:

Application: &ApplicationDefaults

    ACLs: &ACLsDefault

    ...

    # ACL policy for chaincode to chaincode invocation

    peer/ChaincodeToChaincode: /Channel/Application/Readers

    ...   

Policies:       
    Readers:           
        Type: ImplicitMeta          
        Rule: "ANY Readers"


Hyperledger Fabric- How do I resolve 'ProposalResponsePayloads do not match' when my smart contract should be deterministic?

cs19b081@...
 

I'm trying to invoke a chaincode function that sets details about a crop. This function doesn't use date/time, and is logically deterministic. I've checked that the chaincode is successfully installed for each organization of the channel and committed to the channel using peer lifecycle chaincode queryinstalled and peer lifecycle chaincode querycommitted.

However, when I run peer chaincode invoke, it yields an error Error: could not assemble transaction: ProposalResponsePayloads do not match.

There was a broader question that covered some common causes of error, but I'm not completely sure if any of the reasons listed are applicable in my case (Hyperledger Fabric: Error: could not assemble transaction: ProposalResponsePayloads do not match).

This was the invoke command:

peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile /home/ubuntu/fabric-samples/extended-test-network/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n papercontract --peerAddresses localhost:7051 --tlsRootCertFiles /home/ubuntu/fabric-samples/extended-test-network/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles /home/ubuntu/fabric-samples/extended-test-network/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt --peerAddresses localhost:11051 --tlsRootCertFiles /home/ubuntu/fabric-samples/extended-test-network/organizations/peerOrganizations/org3.example.com/peers/peer0.org3.example.com/tls/ca.crt --peerAddresses localhost:12051 --tlsRootCertFiles /home/ubuntu/fabric-samples/extended-test-network/organizations/peerOrganizations/org4.example.com/peers/peer0.org4.example.com/tls/ca.crt --peerAddresses localhost:13051 --tlsRootCertFiles /home/ubuntu/fabric-samples/extended-test-network/organizations/peerOrganizations/org5.example.com/peers/peer0.org5.example.com/tls/ca.crt -c '{"function":"plant","Args":["bhut jolokia", "ghost pepper farms", "sustainable agriculture company", "two dozen", "three quintal per year", "yes", "polyculture", "organic, pesticide-free", "direct sowing"]}'

Here is what the error message looks like, after adding some newlines and tabs:

Error: could not assemble transaction:
ProposalResponsePayloads do not match -
proposal response: version:1 response:<status:200

payload:"{
    \"field1\":\"\",
    \"field2\":\"\",
    \"field3\":\"\",
    \"field4\":\"\",
    \"field5\":\"\"}" >
    
payload:"\n \335-\3101\315<\016\327\324\005\037\202%\360\305\177\2369T\273\334\324X\363\020\302\"f\r6\030\373\022\325\020\n\343\010\022>\n\n_lifecycle\0220\n.\n(namespaces/fields/papercontract/Sequence\022\002\010\016\022\240\010\n\rpapercontract\022\216\010\032\213\010\n\030\000SpiceList\000bhut jolokia\000\032\356\007{
    \"field1\":\"\",
    \"field2\":\"\",
    \"field4\":\"\",
    \"splitKey\":[\"bhut jolokia\"],
    \"field3\":\"\",
    \"field5\":\"\"}"}
    
\032\330\007\010\310\001\032\322\007{
    \"field1\":\"\",
    \"field3\":\"\",
    \"field4\":\"\",
    \"field2\":\"\",
    \"field5\":\"\"}"}
    
\"\022\022\rpapercontract\032\0010" endorsement:<endorser:"\n\007Org4MSP\022\252\006-----BEGIN CERTIFICATE-----\nMIICKTCCAc+gAwIBAgIRAJhO/KCN82dUT2ZWdlM5uREwCgYIKoZIzj0EAwIwczEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzQuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh\nLm9yZzQuZXhhbXBsZS5jb20wHhcNMjEwNjI1MDQxMjAwWhcNMzEwNjIzMDQxMjAw\nWjBqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN\nU2FuIEZyYW5jaXNjbzENMAsGA1UECxMEcGVlcjEfMB0GA1UEAxMWcGVlcjAub3Jn\nNC5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABGKB9vyBmDC9\nW9IGOaA7qlpAHUu2zuHxZGhuwcxqQSDY63/6L2Hpxhg3uVBhtxcOiROJvfZmjOxb\nkZxt2P25D9ujTTBLMA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMCsGA1Ud\nIwQkMCKAIIEDOx3pOppcqaQjtVPfOozh9/NnLuOCB7UWNlSKndMZMAoGCCqGSM49\nBAMCA0gAMEUCIQDkmp/qnb0DpwPlRYSPH6Cv0JE4HkgKgoY9FUAFVR6rpwIgEsXH\nDn2uHMeio475cLoKbayZo87BRDsykM1rBNl1/bI=\n-----END CERTIFICATE-----\n" signature:"0D\002 \013v\273\205\327I >1\212\007\031\233o\276\315v\233\343\345\265r7\366\321\230\355z\361\023\005e\002 `\221\250!\372v\366\247H\213m\236\230\377\246\331\236\000\240< \337\346U\230RV\2040\376\035H" > 

Does the output of the invoke command actually return the proposal response payloads? I've noticed that splitKey present in only one payload, and the order of the fields different in the payloads.

What could be a cause of this inconsistency?

And how do I get the proposal response payloads to be consistent?


I've also put this question up on stackoverflow in case the format here isn't working: https://stackoverflow.com/questions/68143539/hyperledger-fabric-how-do-i-resolve-proposalresponsepayloads-do-not-match-whe


Thanks, Ravi.


Re: CouchDB performance awfully slow

Samyak Jain | TraceX
 

Hi David,
Thanks so much for your quick turnaround. Apologies I couldn't respond sooner.

The solution that you've suggested is what we have implemented now and seems to be working so far as there are only a limited number of records to be queried in a given shot. We've also implemented caching via S3 buckets to further improve response times as this is mostly consumer-facing API and data does not change that frequently. 

We would also be exploring further ways of improving the query times, for instance only querying a limited number of keys and allowing the client applications to request for more data as necessary.

Once again, thanks so much for your help, and we would definitely be happy to contribute to that ticket and give back to the community.

Sincerely yours,
Samyak Jain
Software Development Engineer | TraceX Technologies


From: David Enyeart <enyeart@...>
Sent: Wednesday, June 23, 2021 4:57 AM
To: Samyak Jain | TraceX <samyakj@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] CouchDB performance awfully slow
 

You are correct - CouchDB does full database scans with $or and $in clauses so that approach is expected to be awfully slow.

The solution is to make a GetState() call for each key you need. Although this will require a call to CouchDB for each key, each call will return very quickly since it will utilize a direct index hit. This will work well if you have a small number of keys to lookup, obviously it will not scale well if you have many keys to lookup.

To support many key lookups efficiently, it would be possible for Fabric to implement a new GetStateMultipleKeys() chaincode API which calls the CouchDB bulk retrieve API. I've created a story if anybody would like to contribute the feature - https://jira.hyperledger.org/browse/FAB-18507.


Dave Enyeart


"Samyak Jain | TraceX" ---06/22/2021 11:06:02 AM---Hi Community, We are trying to fetch multiple keys from Fabric ledger as part of traceability of a p

From: "Samyak Jain | TraceX" <samyakj@...>
To: fabric@...
Date: 06/22/2021 11:06 AM
Subject: [EXTERNAL] [Hyperledger Fabric] CouchDB performance awfully slow
Sent by: fabric@...





Hi Community, We are trying to fetch multiple keys from Fabric ledger as part of traceability of a product. We are trying to do selector queries on a ledger containing already around ~40k transactions, and just fetching 2 ids (using primary ZjQcmQRYFpfptBannerStart 
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

Hi Community,

We are trying to fetch multiple keys from Fabric ledger as part of traceability of a product. We are trying to do selector queries on a ledger containing already around ~40k transactions, and just fetching 2 ids (using primary key) with the $or clause is taking close to 8 seconds from the client application. The performance was much better when there were fewer records. I read in a lot of places that the index may not be supported for $or and $in clauses, in which case is there any other way to fetch multiple keys from the ledger in a single query? Note that keys are not part of a range. Please suggest optimization startegies.

I feel that this level of performance should not be the case, and if this is so, does this mean we have to store data off-chain? This would be a step backwards for showing traceability directly from the chain.

Example selector query: { $or: [ { asset_id: "xyz", }, { asset_id: "abc", }, ], }

Thanks, Samyak.






Re: Hyperledger fabric token sdk #fabric-questions

Yacov
 

1. I think that NFT is future work. The token SDK is an active project and it is extended on a daily basis.
2. It is up to the system configuration to decide. When you select the "dlog" driver in AddTMS it will initialize the Token management system with the DLOG driver and then the token identities are interpreted by the DLOG driver.



From:        shivanisb10@...
To:        fabric@...
Date:        06/26/2021 03:54 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Hyperledger fabric token sdk #fabric-questions
Sent by:        fabric@...




Hi , Had a few questions about fabric token sdk. 1. Can you create non fungible token in fabric token sdk if yes how? And can you extend the tokens to include other characteristics? 2. Fabric token sdk comes with two token implementation fabtoken ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi ,
Had a few questions about fabric token sdk.
1. Can you create non fungible token in fabric token sdk if yes how? And can you extend the tokens to include other characteristics?
2. Fabric token sdk comes with two token implementation fabtoken and ZKAT Dlog .How is it decided which implementation is used for token?  





Re: Connection from Client Application to the (endorsing) Peers

Daniel
 

Thank you very much for your inputs! 


Hyperledger fabric token sdk #fabric-questions

shivanisb10@...
 

Hi ,
Had a few questions about fabric token sdk.
1. Can you create non fungible token in fabric token sdk if yes how? And can you extend the tokens to include other characteristics?
2. Fabric token sdk comes with two token implementation fabtoken and ZKAT Dlog .How is it decided which implementation is used for token? 


Re: Cross chaincode invoke, ACL policy problem (MSP not defined in called channel, but in caller) #fabric-chaincode

satheesh
 

From what I understand, only "query" (read only) transactions work cross-invoking in different channels.
If state is modified by chaincode, then channel has to be same as callers chaincode.

In the example, if chaincodeB is invoking chaincodeA, can chaincodeA be deployed in channel-2 ?

Regards,
-Satheesh

On Tuesday, June 22, 2021, 04:34:16 PM GMT+5:30, Sergio C <schica@...> wrote:


Hi,
Is it possible to cross-invoke a chaincode in other channel (channel-1) (using an identity that isn't part of the channel) from a chaincode in the channel-2 (identity is declared here)?

Example:
Org3 and Org4 are part of channel-2.
Org1, Org2 and Org3 are part of channel-1.
Org3 has chaincodeA (instantiated in channel-1) and chaincodeB (instantiated in channel-2) installed.

Org4.member invokes (query) chaincodeB (in Org3Peer) in channel-2 (ok, because Org4 is in channel-2), then chaincodeB internally invokes (query) chaincodeA (fails, because Org4Member MSP isn't defined in channel-1).

Is it possible to bypass this problem?
Any help appreciated.


Re: [Hyperledger Learning Materials Development WG] Setting up a Hyperledger Fabric network in MacBook Air M1

Ry Jones
 

LMDWG to BCC

Hi, Amitansu Patnaik.
Have you tried with minifabric? My guess is that the docker images for Fabric on M1 have not been pushed. This is what I see:
(preface elided)
# Running operation: ******************************************
  download images
....................
# Retrieve the image if it does not already exist *************
  non-zero return code
  no matching manifest for linux/arm64/v8 in the manifest list entries

# STATS *******************************************************
minifab: ok=65 failed=1
Ry



On Fri, Jun 25, 2021 at 1:15 PM <reevinfra@...> wrote:
Hi,
Any luck from anyone to figure out the issue with Macbook Air M1 not allowing the binay download of fabrics?



--
Ry Jones
Community Architect, Hyperledger


Re: Connection from Client Application to the (endorsing) Peers

David Enyeart
 

You were the one asking for alternatives to the submitTransaction() approach!

In a nutshell, if you don't know or don't care who the endorsers are, use submitTransaction(). If you know the endorsing orgs (for example if you are transferring an asset from OrgA to OrgB and require these two orgs to endorse due to a state-based endorsement policy, or just prefer these two orgs to endorse) use the setEndorsingOrganizations() pattern.


Dave Enyeart


"Nikos Karamolegkos" ---06/25/2021 09:11:41 AM---So why is useful no to use service discovery for automatic selection of endorsers? I mean why not to

From: "Nikos Karamolegkos" <nkaram@...>
To: fabric@...
Date: 06/25/2021 09:11 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Connection from Client Application to the (endorsing) Peers
Sent by: fabric@...





So why is useful no to use service discovery for automatic selection of endorsers? I mean why not to use this type of code https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-ledger-queries/application-java/src/main/java/application/java/App.java ZjQcmQRYFpfptBannerStart 
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
So why is useful no to use service discovery for automatic selection of endorsers? I mean why not to use this type of code
https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-ledger-queries/application-java/src/main/java/application/java/App.java which (as I understand) follow the policies defined in the configtx.yaml file?





Re: Connection from Client Application to the (endorsing) Peers

Nikos Karamolegkos
 

So why is useful no to use service discovery for automatic selection of endorsers? I mean why not to use this type of code https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-ledger-queries/application-java/src/main/java/application/java/App.java which (as I understand) follow the policies defined in the configtx.yaml file?


Re: Connection from Client Application to the (endorsing) Peers

David Enyeart
 

Good explanation Mark.

In terms of a code sample, here is a sample of a Node SDK gateway application that doesn't use service discovery for automatic selection of endorsers:
https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-secured-agreement/application-javascript/app.js#L480-L486

It uses setEndorsingOrganizations() which is appropriate when you already know the target endorsing organizations but you want service discovery to choose the peers. Another variant of this is setEndorsingPeers() if you want to pick the actual peers yourself. I believe Java SDK supports the latter pattern as well.

I believe this covers the main use cases well... if you have other compelling use cases please share!


Dave Enyeart

"Mark Lewis" ---06/25/2021 05:22:25 AM---The transaction endorsement and submit process is the same whether you are using a client applicatio

From: "Mark Lewis" <Mark.S.Lewis@...>
To: fabric@...
Date: 06/25/2021 05:22 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Connection from Client Application to the (endorsing) Peers
Sent by: fabric@...





The transaction endorsement and submit process is the same whether you are using a client application that deals with protobuf / gRPC messages directly, the old low-level SDK, the current Gateway SDK, or the future Fabric Gateway SDK. The client ZjQcmQRYFpfptBannerStart 
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
The transaction endorsement and submit process is the same whether you are using a client application that deals with protobuf / gRPC messages directly, the
old low-level SDK, the current Gateway SDK, or the future Fabric Gateway SDK. The client sends proposals to peers and collects enough successfully endorsed responses to satisfy the endorsement policy, then the endorsed proposal is sent to the orderer to be committed to a block, and finally you wait for events from peers to see that the transaction committed successfully.

A local connection profile tells the client application about nodes in the network. Service discovery allows the client to dynamically obtain both:
  1. All the nodes in the network
  2. The endorsement requirements for a given transaction

Even with service discovery, you still need a local connection profile containing at least enough information for the client to connect to a peer and discover the rest of the network.
The current Gateway SDK is built on top of the of low-level SDK. In both cases you either use service discovery (in which case they can access all the available network nodes and optimise the peers used for endorsement based on knowledge of the endorsement policy) or not use service discovery (in which case they can only use nodes described in their connection profile and try to get endorsement from all network nodes to ensure the endorsement policy will be met). The high level SDK just allows you to achieve in a single line of code what would take tens of lines of error-prone boiler-plate code with the low-level SDK.

The future Fabric Gateway API will follow a similar model, except that much of the work of gathering appropriate endorsements, submitting to the orderer and waiting for commit status is moved to a service within the peer. So connection profiles disappear entirely and all your client needs to know is the endpoint of the Gateway service on the peer. Or better still, the endpoint of a load balancer or ingress controller that can dispatch to any appropriate Gateway peer. From the client application perspective, apart from configuration being simpler, there is still a friendly (high-level) API for submitting and evaluating transactions with a lot of similarity to the current Gateway APIs, so there shouldn't be a significant difference.

Finally, the existing gRPC service endpoints aren't going away -- in fact they are still used by the Fabric Gateway to communicate with other peers, just as client applications do today -- so you can choose to do as much or as little work as you want within your client application, right down to creating protobuf messages and sending them directly using gRPC APIs if you prefer.






Re: Connection from Client Application to the (endorsing) Peers

Mark Lewis
 

The transaction endorsement and submit process is the same whether you are using a client application that deals with protobuf / gRPC messages directly, the old low-level SDK, the current Gateway SDK, or the future Fabric Gateway SDK. The client sends proposals to peers and collects enough successfully endorsed responses to satisfy the endorsement policy, then the endorsed proposal is sent to the orderer to be committed to a block, and finally you wait for events from peers to see that the transaction committed successfully.

A local connection profile tells the client application about nodes in the network. Service discovery allows the client to dynamically obtain both:
  1. All the nodes in the network
  2. The endorsement requirements for a given transaction

Even with service discovery, you still need a local connection profile containing at least enough information for the client to connect to a peer and discover the rest of the network.
The current Gateway SDK is built on top of the of low-level SDK. In both cases you either use service discovery (in which case they can access all the available network nodes and optimise the peers used for endorsement based on knowledge of the endorsement policy) or not use service discovery (in which case they can only use nodes described in their connection profile and try to get endorsement from all network nodes to ensure the endorsement policy will be met). The high level SDK just allows you to achieve in a single line of code what would take tens of lines of error-prone boiler-plate code with the low-level SDK.

The future Fabric Gateway API will follow a similar model, except that much of the work of gathering appropriate endorsements, submitting to the orderer and waiting for commit status is moved to a service within the peer. So connection profiles disappear entirely and all your client needs to know is the endpoint of the Gateway service on the peer. Or better still, the endpoint of a load balancer or ingress controller that can dispatch to any appropriate Gateway peer. From the client application perspective, apart from configuration being simpler, there is still a friendly (high-level) API for submitting and evaluating transactions with a lot of similarity to the current Gateway APIs, so there shouldn't be a significant difference.

Finally, the existing gRPC service endpoints aren't going away -- in fact they are still used by the Fabric Gateway to communicate with other peers, just as client applications do today -- so you can choose to do as much or as little work as you want within your client application, right down to creating protobuf messages and sending them directly using gRPC APIs if you prefer.


Re: Connection from Client Application to the (endorsing) Peers

Nikos Karamolegkos
 

Hmm, I am a bit confused. As I see here https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-basic/application-java/src/main/java/application/java/App.java using the gateway functionality you can propose transactions to the network without having some information about the network setup. In this way, you can evaluate the transaction result (pass or fail). So in 2.4 you will move this functionality to the peers? Also, can you give an example code with the client application (without the gateway functionality) where the client gathers endorsement from the different peers? I thought that the endorsement of endorsement policies was a automatic-predefined process of HF.


Re: Connection from Client Application to the (endorsing) Peers

David Enyeart
 

Currently the client application must gather the endorsements from the required number of peers. The 'gateway' functionality within the client SDK can manage this for you. There is work ongoing to shift the gateway component into the peer, so that your client application can delegate this function to your peer(s), and then your peer will gather endorsements and submit the transaction on behalf of the client application. The feature is available for trial in the recent v2.4.0-alpha. See the full announcement with links to more details: https://lists.hyperledger.org/g/fabric/message/9872.

You are correct that is is sometimes painful to have the client application connect to remote peers (open up ports between client application and peers, etc). This is one of the motivations for shifting the gateway into the peer. Please try out the v2.4.0-alpha and let us know your thoughts as we work to finalize the release.


Thanks,

Dave Enyeart


"Daniel" ---06/23/2021 02:16:14 PM---Hey guys, as I understand, the client application proposes transactions to the peers. Is the client

From: "Daniel" <shimanski@...>
To: "fabric@..." <fabric@...>
Date: 06/23/2021 02:16 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Connection from Client Application to the (endorsing) Peers
Sent by: fabric@...





Hey guys, as I understand, the client application proposes transactions to the peers. Is the client application sending it to only one peer or all the peers (as defined in endorsement policy)? Or is it possible, that the endorsing peer (that ZjQcmQRYFpfptBannerStart 
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hey guys,

as I understand, the client application proposes transactions to the peers. Is the client application sending it to only one peer or all the peers (as defined in endorsement policy)? Or is it possible, that the endorsing peer (that is receiving the proposal) is sending the proposal to the other endorsing peers? What if the peers are physical apart, how is client able to connect to nodes which are physical far away?

Thanks in advance.
 






Connection from Client Application to the (endorsing) Peers

Daniel
 

Hey guys,

as I understand, the client application proposes transactions to the peers. Is the client application sending it to only one peer or all the peers (as defined in endorsement policy)? Or is it possible, that the endorsing peer (that is receiving the proposal) is sending the proposal to the other endorsing peers? What if the peers are physical apart, how is client able to connect to nodes which are physical far away? 

Thanks in advance.
 


Re: off chain database that replicates the data from your peers

David Enyeart
 

The sample demonstrates how to track block event progress so that your processing logic can resume where it left off if it is interrupted. Also the block events are replayable so you can re-process them from any block height if the downstream data is in doubt, assuming your downstream data store has an idempotent design. Of course, these are just tools, ultimately the data integrity is in your own hands once you pull the data out.


Dave Enyeart
IBM Blockchain
enyeart@...


"Nikos Karamolegkos" ---06/23/2021 08:05:33 AM---Thank you. I am not sure that I understand the part with the downstream data integrity. As I know, i

From: "Nikos Karamolegkos" <nkaram@...>
To: fabric@...
Date: 06/23/2021 08:05 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] off chain database that replicates the data from your peers
Sent by: fabric@...





Thank you. I am not sure that I understand the part with the downstream data integrity. As I know, in a BC network with on-chain database if you want to retrieve some data you have to query the ledger of a peer (or more) and these data are build ZjQcmQRYFpfptBannerStart 
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Thank you. I am not sure that I understand the part with the downstream data integrity. As I know, in a BC network with on-chain database if you want to retrieve some data you have to query the ledger of a peer (or more) and these data are build from the transaction log so you are sure that these data are correct. In case there is an external (off-chain database) how is this feasible? I mean I can be sure for the data in on-chain DB but how can I be sure for the replicated data in off-chain DB.





1121 - 1140 of 11218