Date   

Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 03/26/2021 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 26 March 2021
11:00am to 12:00pm
(GMT-04:00) America/New York

Where:
https://zoom.us/my/hyperledger.community.backup?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09

Organizer:
pama@...

Description:
Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Join Zoom Meeting
https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09
 
Meeting ID: 622 333 6701
Passcode: 475869


Re: Fabric Contributor Meeting - March 17, 2021 - any agenda topics?

David Enyeart
 

Thank you Vitalii, sounds good. Based on our side conversation, I've scheduled you for April 14th on the contributor meeting page - https://wiki.hyperledger.org/display/fabric/Contributor+Meetings+2021.


Dave Enyeart

"Vitalii Demianets" ---03/26/2021 04:17:28 AM---Hi David and all! I would like to propose one more item for March 31st agenda. We would like

From: "Vitalii Demianets" <vitalii@...>
To: fabric <fabric@...>
Cc: David Enyeart <enyeart@...>
Date: 03/26/2021 04:17 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Fabric Contributor Meeting - March 17, 2021 - any agenda topics?
Sent by: fabric@...





Hi David and all! I would like to propose one more item for March 31st agenda. We would like to open a discussion on our RFC: https://github.com/hyperledger/fabric-rfcs/pull/44 I am planning to attend and present it from the norbloc side. ‍ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi David and all!

I would like to propose one more item for March 31st agenda. We would like to open a discussion on our RFC:
https://github.com/hyperledger/fabric-rfcs/pull/44
I am planning to attend and present it from the norbloc side.

--
// Vitalii Demianets @ norbloc AB


On Tue, Mar 16, 2021 at 11:53 PM David Enyeart <enyeart@...> wrote:
    Hyperledger Fabric Contributor Meeting

    When: Every other Wednesday 9am US Eastern, 13:00 UTC (during US daylight savings time)

    Where: https ://zoom.us/j/51849 47650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

    Agendas and Recordings: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

    ----------------------------------------------------------------------------------------------------

    Agenda for March 17, 2021

    There are no big agenda topics scheduled for this week yet.
    We will do a quick update on the transition from 'master' to 'main' as the default branch.
    Feel free to propose an agenda item!

    For March 31 meeting, an update on the Fabric Gateway is planned.






Re: peer discovery/collection errors when calling chaincode from nodejs client

Simeon MacMillen
 

Hi Mark,

Thank you for your response and for your helpful direction!  The explicit designation of endorsing peer at transaction submit was exactly what I was looking for.  After adapting this, I was able to successfully resolve the write transactions through the Dockerized client.

Sincerely,
Simeon MacMillen

On 3/25/21 2:42 PM, Mark Lewis wrote:
You might need to set some discovery interests for the private data collections you are using. See the "using chaincode to chaincode calls and collections" section on this page for details:

https://hyperledger.github.io/fabric-sdk-node/release-2.2/tutorial-discovery-fabric-network.html

You can also explicitly specify the endorsing organizations to use for a given transaction submit:

https://hyperledger.github.io/fabric-sdk-node/release-2.2/module-fabric-network.Transaction.html#setEndorsingOrganizations


Re: Editing default signature policy for chaincode triggers error while running transactions: received discovery error:failed constructing descriptor for chaincodes. Commercial paper on Test-network #policies #fabric-chaincode #fabric-questions #fabric-endorser

sangieri@...
 

Hi Nik, 

Thanks for answering. 

 

I confirm the chaincode has been committed to the channel: 

peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --peerAddresses localhost:7051 --tlsRootCertFiles ${PEER0_ORG1_CA} --peerAddresses localhost:9051 --tlsRootCertFiles ${PEER0_ORG2_CA}  --channelID mychannel --signature-policy "OR('Org1.peer', 'Org2.peer')" --name papercontract -v 0 --sequence 1 --tls --cafile $ORDERER_CA --waitForEvent

2021-03-26 13:51:22.432 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [a2633e88ce9a337c523dfb24fc33914cb82fb8fadf24b01609331a64d77c0a7b] committed with status (VALID) at localhost:7051

2021-03-26 13:51:22.456 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [a2633e88ce9a337c523dfb24fc33914cb82fb8fadf24b01609331a64d77c0a7b] committed with status (VALID) at localhost:9051

 

and that all docker containers seem to be properly setup: 

docker ps

CONTAINER ID   IMAGE                                                                                                                                                               COMMAND                  CREATED         STATUS         PORTS                                        NAMES

e0dafb74a871   dev-peer0.org2.example.com-cp_0-ddca913c004eb34f36dfb0b4c0bcc6d4afc1fa823520bb5966a3bfcf1808f40a-5c83b377cab7f417bcf7f196e6cbde2f685ab9db73ea78fa733ccb4c3af65781   "docker-entrypoint.s…"   6 seconds ago   Up 5 seconds                                                dev-peer0.org2.example.com-cp_0-ddca913c004eb34f36dfb0b4c0bcc6d4afc1fa823520bb5966a3bfcf1808f40a

25f6984c346f   dev-peer0.org1.example.com-cp_0-ddca913c004eb34f36dfb0b4c0bcc6d4afc1fa823520bb5966a3bfcf1808f40a-0829f3256ad634f959b8cb39756634e18a5aecbc11e7cc9cdb38c88304e03b4b   "docker-entrypoint.s…"   6 seconds ago   Up 5 seconds                                                dev-peer0.org1.example.com-cp_0-ddca913c004eb34f36dfb0b4c0bcc6d4afc1fa823520bb5966a3bfcf1808f40a

38ebe71216cc   hyperledger/fabric-tools:latest                                                                                                                                     "/bin/bash"              3 minutes ago   Up 3 minutes                                                cli

6bb6d323df4a   hyperledger/fabric-peer:latest                                                                                                                                      "peer node start"        3 minutes ago   Up 3 minutes   0.0.0.0:7051->7051/tcp                       peer0.org1.example.com

d16b32dce7b9   hyperledger/fabric-peer:latest                                                                                                                                      "peer node start"        3 minutes ago   Up 3 minutes   7051/tcp, 0.0.0.0:9051->9051/tcp             peer0.org2.example.com

115460e0646b   couchdb:3.1.1                                                                                                                                                       "tini -- /docker-ent…"   3 minutes ago   Up 3 minutes   4369/tcp, 9100/tcp, 0.0.0.0:7984->5984/tcp   couchdb1

9fb31d32ca3f   couchdb:3.1.1                                                                                                                                                       "tini -- /docker-ent…"   3 minutes ago   Up 3 minutes   4369/tcp, 9100/tcp, 0.0.0.0:5984->5984/tcp   couchdb0

c8795371969d   hyperledger/fabric-orderer:latest                                                                                                                                   "orderer"                3 minutes ago   Up 3 minutes   0.0.0.0:7050->7050/tcp                       orderer.example.com

7adfadccb74a   hyperledger/fabric-ca:latest                                                                                                                                        "sh -c 'fabric-ca-se…"   3 minutes ago   Up 3 minutes   7054/tcp, 0.0.0.0:8054->8054/tcp             ca_org2

78f6a1bfd0d4   hyperledger/fabric-ca:latest                                                                                                                                        "sh -c 'fabric-ca-se…"   3 minutes ago   Up 3 minutes   0.0.0.0:7054->7054/tcp                       ca_org1

f1b15beb5920   hyperledger/fabric-ca:latest                                                                                                                                        "sh -c 'fabric-ca-se…"   3 minutes ago   Up 3 minutes   7054/tcp, 0.0.0.0:9054->9054/tcp             ca_orderer

 

Stefano


Re: Editing default signature policy for chaincode triggers error while running transactions: received discovery error:failed constructing descriptor for chaincodes. Commercial paper on Test-network #policies #fabric-chaincode #fabric-questions #fabric-endorser

Nikhil Gupta
 

Hi,

Can you confirm that the chaincode has been committed to the channel? Or can you do a docker ps to confirm that the chaincode containers have started.

This error looks like the chaincode may not be on the channel.

Nik

On Fri, Mar 26, 2021 at 8:35 AM <sangieri@...> wrote:

Using the default configuration I can run all the functions inside the application folder of commercial paper on test-network without any problem

If I edit the default signature policy in the approval and commitment of the chaincode definition i am unable to run the issue.js code without experiencing the service discovery error: 

" Connect to Fabric gateway.

Use network channel: mychannel.

Use org.papernet.commercialpaper smart contract.

Submit commercial paper issue transaction.

2021-03-26T12:05:04.277Z - error: [DiscoveryService]: send[papercontract] - Channel:mychannel received discovery error:failed constructing descriptor for chaincodes:<name:"papercontract" >

Error processing transaction. Error: DiscoveryService: papercontract error: failed constructing descriptor for chaincodes:<name:"papercontract" >

Error: DiscoveryService: papercontract error: failed constructing descriptor for chaincodes:<name:"papercontract" >

    at DiscoveryService.send (/home/sangieri/TestProject/commercial-paper/organization/magnetocorp/application/node_modules/fabric-common/lib/DiscoveryService.js:363:11)

Disconnect from Fabric gateway.

Issue program complete."

 

According to documentation, to edit the signature policy I use the following commands:

peer lifecycle chaincode approveformyorg --orderer localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --signature-policy "OR('Org1.peer', 'Org2.peer')" --name papercontract -v 0 --package-id $PACKAGE_ID --sequence 1 --tls --cafile $ORDERER_CA

peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --peerAddresses localhost:7051 --tlsRootCertFiles ${PEER0_ORG1_CA} --peerAddresses localhost:9051 --tlsRootCertFiles ${PEER0_ORG2_CA}  --channelID mychannel --signature-policy "OR('Org1.peer', 'Org2.peer')" --name papercontract -v 0 --sequence 1 --tls --cafile $ORDERER_CA --waitForEvent

 

The Anchor peer are set. 

The connectionOptions in issue.js are set properly: 

let connectionOptions = {

            identity: userName,

            wallet: wallet,

            discovery: { enabled:true, asLocalhost: true }

        };

 

Any help? 

 


Editing default signature policy for chaincode triggers error while running transactions: received discovery error:failed constructing descriptor for chaincodes. Commercial paper on Test-network #policies #fabric-chaincode #fabric-questions #fabric-endorser

sangieri@...
 

Using the default configuration I can run all the functions inside the application folder of commercial paper on test-network without any problem

If I edit the default signature policy in the approval and commitment of the chaincode definition i am unable to run the issue.js code without experiencing the service discovery error: 

" Connect to Fabric gateway.

Use network channel: mychannel.

Use org.papernet.commercialpaper smart contract.

Submit commercial paper issue transaction.

2021-03-26T12:05:04.277Z - error: [DiscoveryService]: send[papercontract] - Channel:mychannel received discovery error:failed constructing descriptor for chaincodes:<name:"papercontract" >

Error processing transaction. Error: DiscoveryService: papercontract error: failed constructing descriptor for chaincodes:<name:"papercontract" >

Error: DiscoveryService: papercontract error: failed constructing descriptor for chaincodes:<name:"papercontract" >

    at DiscoveryService.send (/home/sangieri/TestProject/commercial-paper/organization/magnetocorp/application/node_modules/fabric-common/lib/DiscoveryService.js:363:11)

Disconnect from Fabric gateway.

Issue program complete."

 

According to documentation, to edit the signature policy I use the following commands:

peer lifecycle chaincode approveformyorg --orderer localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --signature-policy "OR('Org1.peer', 'Org2.peer')" --name papercontract -v 0 --package-id $PACKAGE_ID --sequence 1 --tls --cafile $ORDERER_CA

peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --peerAddresses localhost:7051 --tlsRootCertFiles ${PEER0_ORG1_CA} --peerAddresses localhost:9051 --tlsRootCertFiles ${PEER0_ORG2_CA}  --channelID mychannel --signature-policy "OR('Org1.peer', 'Org2.peer')" --name papercontract -v 0 --sequence 1 --tls --cafile $ORDERER_CA --waitForEvent

 

The Anchor peer are set. 

The connectionOptions in issue.js are set properly: 

let connectionOptions = {

            identity: userName,

            wallet: wallet,

            discovery: { enabled:true, asLocalhost: true }

        };

 

Any help? 

 


Re: Problematic raspberry support

Nikos Karamolegkos <nkaram@...>
 

Thank you for your time. I just ran the test-network (after your contribution) but the error remains. My steps were: make docker clean, make docker, make native, copy the bin into fabric samples.


Re: Fabric Contributor Meeting - March 17, 2021 - any agenda topics?

Vitalii Demianets
 

Hi David and all!

I would like to propose one more item for March 31st agenda. We would like to open a discussion on our RFC:
https://github.com/hyperledger/fabric-rfcs/pull/44
I am planning to attend and present it from the norbloc side.

--
// Vitalii Demianets @ norbloc AB


On Tue, Mar 16, 2021 at 11:53 PM David Enyeart <enyeart@...> wrote:

Hyperledger Fabric Contributor Meeting

When: Every other Wednesday 9am US Eastern, 13:00 UTC (during US daylight savings time)

Where: https ://zoom.us/j/51849 47650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Agendas and Recordings: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

----------------------------------------------------------------------------------------------------

Agenda for March 17, 2021
There are no big agenda topics scheduled for this week yet.
We will do a quick update on the transition from 'master' to 'main' as the default branch.
Feel free to propose an agenda item!

For March 31 meeting, an update on the Fabric Gateway is planned.


Re: peer discovery/collection errors when calling chaincode from nodejs client

Mark Lewis
 

You might need to set some discovery interests for the private data collections you are using. See the "using chaincode to chaincode calls and collections" section on this page for details:

https://hyperledger.github.io/fabric-sdk-node/release-2.2/tutorial-discovery-fabric-network.html

You can also explicitly specify the endorsing organizations to use for a given transaction submit:

https://hyperledger.github.io/fabric-sdk-node/release-2.2/module-fabric-network.Transaction.html#setEndorsingOrganizations


Re: Fabric network org structure reg.

Tsvetan Georgiev
 

Hi Indirajith,

Yes it is better to use dedicated MSP for the ordering orgs. This means a business organization may use multiple MSPs to run peers or orderers.



I recommend going though the production deployment guide: https://hyperledger-fabric.readthedocs.io/en/release-2.2/deployment_guide_overview.html

Hope that helps!

Senofi

Tsvetan Georgiev
Director, Senofi Inc.

438-494-7854 | tsvetan@...

www.senofi.ca

www.consortia.io







---- On Wed, 24 Mar 2021 04:40:35 -0400 indirajith <indirajithv@...> wrote ----

Dear Fabric Community,

I would like to know what is the best practice or prefered method to design a fabric network in 2.x versions? Shall we have orderers in the same organization as peers or should we need to have a seperate org for orderers? Or should we have two different orgs for peers and orderers for each participating orgs? Can anyone shed some light and point me to resources? I could not get any response for the query in the chat channel.

Thanks in advance. 
Regards,
Indirajith.






Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 03/26/2021 11:00am-12:00pm #cal-reminder

fabric@lists.hyperledger.org Calendar <fabric@...>
 

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 26 March 2021, 11:00am to 12:00pm, (GMT-04:00) America/New York

Where:https://zoom.us/my/hyperledger.community.backup?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09

View Event

Organizer: Pam Andrejko pama@...

Description: Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Join Zoom Meeting
https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09
 
Meeting ID: 622 333 6701
Passcode: 475869


peer discovery/collection errors when calling chaincode from nodejs client

Simeon MacMillen
 

Hello Fabric community,

I am encountering a couple issues when accessing/writing data to a Fabric (2.3) network from a Node.js client.  I have a 4-org network running on 4 different VPS instances.  (Each VPS hosts 1 org with dockerized peer and orderer instances.  The VPSs are linked via a Docker swarm overlay network.)  There are 2 shared private data collections, one with 3 orgs, 1 with 2 orgs.  (Only 1 org is a member of both collections.)

When I start my node client (on any of the VPS instances), I get error messages like these:

2021-03-25T10:48:10.616Z - error: [ServiceEndpoint]: Error: Failed to connect before the deadline on Endorser- name: peer0.orgb.scm.com:7051, url:grpcs://localhost:7051, connected:false, connectAttempted:true
2021-03-25T10:48:10.617Z - error: [ServiceEndpoint]: waitForReady - Failed to connect to remote gRPC server peer0.orgb.scm.com:7051 url:grpcs://localhost:7051 timeout:3000
2021-03-25T10:48:10.618Z - error: [DiscoveryService]: _buildPeer[scm1] - Unable to connect to the discovered peer peer0.orgb.scm.com:7051 due to Error: Failed to connect before the deadline on Endorser- name: peer0.orgb.scm.com:7051, url:grpcs://localhost:7051, connected:false, connectAttempted:true

It seems that the client org is having trouble connecting with the other orgs outside of Docker.  Note that "asLocalhost" is set to true.

However, after displaying the error messages, I can use the client to successfully read and write to the ledger.  So it seems the error messages are more of a cosmetic issue than a functional issue?  (They certainly would not inspire confidence in a demo!)  The error messages also occur randomly after other read/write requests.


To deal with this problem, I tried dockerizing my node client.  This way, the client could use the same docker overlay network and natively resolve the other hosts.  This worked great (I thought) - no more errors on startup or queries!  However, when I try to write data to the ledger, I get this error:

--> Submit Transaction: AddPart A2
2021-03-24T23:18:55.339Z - error: [Transaction]: Error: No valid responses from any peers. Errors:
    peer=peer0.orga.scm.com:7051, status=500, message=AddPart cannot be performed: Error client from org ORGBMSP is not authorized to read or write private data from an org ORGAMSP peer
Error detected when calling addPart function:Error: No valid responses from any peers. Errors:
    peer=peer0.orga.scm.com:7051, status=500, message=AddPart cannot be performed: Error client from org ORGBMSP is not authorized to read or write private data from an org ORGAMSP peer

So I solved the discovery problem, but now the client is connecting to any organization peer it wants to?  I could avoid calling the verifyClientOrgMatchesPeerOrg function in the Chaincode, but that would potentially introduce other problems.

Is there a way to force the client to only use the client org's peer?  Or is there a better approach here?

Sincerely,
Simeon MacMillen



Re: HyperLedger Fabric v2.3 Endorsement Policy did not come into action

David Enyeart
 

This is working as expected. You updated the size field but not the version field. The read set check only checks the version field. It is up to the chaincode to check other fields such as asset ownership (and size, if there are business rules around that, such as size not being allowed to change in an update). The asset transfer chaincode is a trivial sample and only checks for asset existence in state database by key. So in your case chaincode execution succeeded because it passed the asset existence check, endorsements succeeded, and validation succeeded since both endorsements were over the same read set (version) and write set.
You get the CouchDB warning because the internal CouchDB revision number was different due to your external update, but this is not a fatal problem and gets resolved by a retry (CouchDB internal revision numbers are not guaranteed to be the same across state databases since peer may update the same state multiple times, e.g. in crash recovery scenarios).


Dave Enyeart

"Ming Xian Ng" ---03/25/2021 12:11:11 AM---Hi, I was trying to test out the endorsement policy feature of Fabric with

From: "Ming Xian Ng" <ngmx.sean@...>
To: fabric@...
Date: 03/25/2021 12:11 AM
Subject: [EXTERNAL] [Hyperledger Fabric] HyperLedger Fabric v2.3 Endorsement Policy did not come into action
Sent by: fabric@...





Hi, I was trying to test out the endorsement policy feature of Fabric with the Running a Fabric Application tutorial and I have encountered a few questions/issues. Instead of using LevelDB, I up the network using CouchDB by changing the command ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi,
I was trying to test out the endorsement policy feature of Fabric with the Running a Fabric Application tutorial and I have encountered a few questions/issues.
Instead of using LevelDB, I up the network using CouchDB by changing the command to ./network.sh up createChannel -c mychannel -ca -s couchdb. After the call to InitLedger, I manually edit asset2's "Size" field value to another random value through fauxton, accessed from http://127.0.0.1:5984/_utils/ (couchdb0, which belongs to organization 1). So at this point, asset2 has 2 different value sitting in couchdb0 and couchdb1.
Then I invoke the UpdateAsset function in the chaincode to update asset2's value. I was expecting an error about endorsement policy is not met or something to be thrown as the different value of asset2 in couchdb0 and couchdb1 should results in different RW set.
peer0.org1.example.com|2021-03-23 09:03:09.568 UTC [statecouchdb] commitUpdates -> WARN 0b4 CouchDB batch document update encountered an problem. Reason:Document update conflict., Retrying update for document ID:asset2

I did notice this warning in logspout however there was no error caught in my try catch block, and it seems that a valid block is committed and the world states is getting updated as usual without any error.
Shouldn't the different RW Set would cast the transaction as invalid and the world states wouldn't be updated?

Regards,
Sean





HyperLedger Fabric v2.3 Endorsement Policy did not come into action

Ming Xian Ng
 

Hi,

I was trying to test out the endorsement policy feature of Fabric with the Running a Fabric Application tutorial and I have encountered a few questions/issues.

Instead of using LevelDB, I up the network using CouchDB by changing the command to ./network.sh up createChannel -c mychannel -ca -s couchdb. After the call to InitLedger, I manually edit asset2's "Size" field value to another random value through fauxton, accessed from http://127.0.0.1:5984/_utils/ (couchdb0, which belongs to organization 1). So at this point, asset2 has 2 different value sitting in couchdb0 and couchdb1.

Then I invoke the UpdateAsset function in the chaincode to update asset2's value. I was expecting an error about endorsement policy is not met or something to be thrown as the different value of asset2 in couchdb0 and couchdb1 should results in different RW set.

peer0.org1.example.com|2021-03-23 09:03:09.568 UTC [statecouchdb] commitUpdates -> WARN 0b4 CouchDB batch document update encountered an problem. Reason:Document update conflict., Retrying update for document ID:asset2

I did notice this warning in logspout however there was no error caught in my try catch block, and it seems that a valid block is committed and the world states is getting updated as usual without any error.

Shouldn't the different RW Set would cast the transaction as invalid and the world states wouldn't be updated?


Regards,

Sean


Re: Problematic raspberry support

Matthew Sykes
 

I had some time this morning so I played around with the peer image created on linux/aarch64 (linux/arm64). To get to the bottom of why the program was dying during initialization, I commented out all of the code in the peer main and slowly added back in the package imports until I hit the segfault again. I went to the package introducing the problem and repeated the process until I got to the bottom.

After running down the tree, the package that caused the problem was `plugin’ and the only import left in Fabric is from `github.com/hyperledger/fabric/core/handlers/library`. It looks like plugins work with glibc (the native builds and tests seem fine) so it has something to do with musl.

I’ll put together a PR to enable builds without plugins some time today. After that’s in, the images built with alpine and musl should work on linux/aarch64 (linux/arm64). It’s still not something we’ll be testing and supporting at this time but it may unblock your efforts.


Fabric network org structure reg.

indirajith
 

Dear Fabric Community,

I would like to know what is the best practice or prefered method to design a fabric network in 2.x versions? Shall we have orderers in the same organization as peers or should we need to have a seperate org for orderers? Or should we have two different orgs for peers and orderers for each participating orgs? Can anyone shed some light and point me to resources? I could not get any response for the query in the chat channel.

Thanks in advance. 
Regards,
Indirajith.


Re: Smart BFT

grapebaba
 

Hi guys

I looked at several git branch prefix release-1.4-BFT, what is the difference between them? What is the correct version for docker https://hub.docker.com/r/smartbft/fabric-peer

On Mon, Oct 26, 2020 at 10:59 PM Oleg Martianov <olegmartianov@...> wrote:
Dear Community members! 

IDEAS Center has been deeply involved in the development of SmartBFT consensus library and would like to propose RFC https://github.com/hyperledger/fabric-rfcs/pull/33 that argues about  the necessity of BFT protocol as part of enterprise grade blockchain platform. The RFC highlights the implementation details and the efforts required to integrate the library into Hyperledger Fabric. Currently we are seeking for engagements with community and in particular with Hyperledger Fabric maintainers in order to identify milestones and formulate reasonable integration strategy and the roadmap, striving to generate small self containable deliverables and providing on going support going forward. 

In the heart of the BFT ordering service for Hyperledger Fabric implementation lies a new consensus library, based on the BFT-Smart protocol, implemented in Go. The library presents APIs suited for permissioned blockchain applications, such as Fabric. It delegates many of the core functions that any such library must use to the application employing it, allowing for maximal flexibility and generality. For example, cryptographic functions, identity management, as well as point to point communication are not embedded but are exposed through proper interfaces, to be implemented by the application using it. This allowed us to re-use some of the sophisticated mechanisms that Fabric already possessed. In the quest to make Fabric a truly end-to-end BFT system, it is not enough to augment the ordering service alone. We took special care to ensure that the peer and the client SDK interact properly with the BFT ordering service.

We chose to implement the BFT-Smart protocol because of its simplicity and elegance. This protocol is significantly simpler than PBFT, because it does not allow for a transaction pipeline. In BFTSmart there is only a single proposed transaction by a given leader at any point in time, which dramatically simplifies the view change sub-protocol. This simplicity greatly increases our confidence in the correctness of the implementation and reduced the effort it took to implement the library. However, these advantages come with a cost – reduced performance. This is especially salient when comparing against the highly mature and optimized etcd/raft library, which uses pipelining extensively. Despite the cost of reduced performance relative to etcd/raft, our implementation exhibits levels of performance that are sufficient for most permissioned blockchain applications: a 7 node BFT ordering service (𝐹 = 2) can support over 2500 TPS in a LAN, and over 1000 TPS in a WAN. These numbers are for a single channel; a Fabric network can scale horizontally by adding channels.

IDEAS Center is managing Smart BFT additional development at the moment and will be responsible for the following support and new Fabric versions compatibility.


Thank you!


Begin forwarded message:

From: Oleg Martianov <olegmartianov@...>
Subject: Smart BFT
Date: 17 September 2020, 17:41:51 GMT+3

Hello Team!

SC Idea sponsored and worked on BFT based ordering service - Smart BFT (BYZANTINE FAULT TOLERANCE) library (https://github.com/SmartBFT-Go/consensus/) that has been developed in Open Source by IBM Research lab in the frames of the contract with SC Idea. There is an implementation of Hyperledger Fabric BFT based ordering service which is built on top of Smart BFT library: https://github.com/SmartBFT-Go/fabric/

SC Idea team would like to suggest resources and integrate BFT based ordering service with the Hyperledger Fabric mainstream, we strongly believe that that will significantly improve functionality and provide long long desired  end to end functionality into. In order to initiate the process we would like to propose RFC: https://github.com/hyperledger/fabric-rfcs/pull/33

We would be glad to hear and collect your feedback and really looking forward for fruitful collaboration and maintainers support for our initiative.


Re: Orderer ledger pruning

Vitalii Demianets
 

The RFC draft has been submitted, here:
https://github.com/hyperledger/fabric-rfcs/pull/44

Please review!
--
// Vitalii Demianets @ norbloc AB


On Thu, Feb 25, 2021 at 1:06 PM Vitalii Demianets via lists.hyperledger.org <vitalii=norbloc.com@...> wrote:
Thank you all for the discussion and your input!
I think we now have a high-level understanding of what has to be done, looks simple enough.
Now we start the process of drafting the RFC. It will take some time though, as we want to familiarize ourselves with the internals of the code and the architecture from the Fabric dev point of view, but I hope it will not take more than 3-4 weeks.

--
// Vitalii Demianets @ norbloc AB


On Tue, Feb 23, 2021 at 3:56 PM Manish Sethi <manish.sethi@...> wrote:
In regards to changes to the blockstore, Jason is right that they would be very trivial. For the peers case, this function (https://github.com/hyperledger/fabric/blob/e0253ef0466e4e16364f3d1d3cc537ad9d8b1c4f/common/ledger/blkstorage/blockstore_provider.go#L103) does the job. For the orderer, I would expect an even simpler function (say, "BootstrapFromSnapshotInfo"), as there is nothing much other than the information of the initial state that needs to be supplied.

Thanks,
Manish

On Tue, Feb 23, 2021 at 6:27 AM Vitalii Demianets <vitalii@...> wrote:
Hi Jason!

>
> At a very high level I would suggest.
>
> 1) Modifying the channel participation API to allow specifying a minimum block sequence number to replicate to when joining.
> 2) Add a new pruning function to the channel participation API, which allows reconfiguring that minimum block sequence to a higher sequence number. (Implicitly existing channels would have this sequence set to 0).
> 3) Ignoring the system channel case, instead prereq-ing that channel participation API.
> 4) Introducing a new return status for the Deliver API indicating to peers and clients that the sequence is too old to help users understand why a block request is being rejected.  You'll actually notice that the APi already has the notion of 'OLDEST' as a seek position, as the earliest incarnations of the orderer ledger were RAM based and self-pruning.
>
> Perhaps Manish can weigh in here, but I believe the block storage code was already modified in the peer to handle starting from a later block.  The orderer uses a thin wrapping layer around the peer blockstore, so if not already exposed, exposing it should be relatively simple.

In the above description you do not mention snapshot at all. Do I understand this correctly that we basically do not need any of the peer snapshot functionality (private data collections, stateDB, transactions id list) to start an orderer from an arbitrary block? Basically from your description it follows that we only need to supply the latest config block and the desired start block number, and the orderer will happily start from that info? (given it is able to fetch the start block and other blocks on top of it)
In other words, for orderers the "snapshot" is only the latest config block + start block number?

>
> It might also be helpful to extend the block height discovery in the orderer block replication to discover the lowest block height as well, to detect when an orderer cannot catch up, though I'm not sure I would consider this a blocking item for an initial implementation.

Yes, in our use case the condition that we start the orderer from the block that can be discovered is satisfied, so it makes sense not to add this complexity from the start.
After all if an orderer is not able to find a block, it will be more or less obvious from the logs.

>
> I would argue that the most challenging aspect of implementing pruning at the orderer is an operational one.  The orderers are necessarily not involved in the peer snapshot operations, but, if the orderers prune to a block after the peer's most recent snapshot, onboarding will be broken until peers take a new snapshot.  In the worst case, if the orderer prunes before the blocks are disseminated to the peers, then data loss could occur.
>

We are going to keep several peers as "archiving" nodes, having all the history of blocks from block 0.
Will this solve the issue?

--
// Vitalii Demianets @ norbloc AB


Private Chaincode Lab - Tue, 03/23/2021 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Private Chaincode Lab

When:
Tuesday, 23 March 2021
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer:
bur@...

Description:
Two of the Hyperleger Labs projects (private data objects and private chain code) are collaborating to develop a "private smart contracts" capability.

Join Zoom Meeting https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Meeting ID: 518 494 7650 Passcode: 475869


Re: Problematic raspberry support

Matthew Sykes
 

Yeah, they’re all my commits so I’m very familiar with them. The change you’re referencing this time was required to get through the link phase in the alpine containers but the binaries in the containers still aren’t exercised.

As for clues, I don’t have any. If the binaries are going belly-up with a segfault, I’d start with that. It’s probably related to the musl libc used in the alpine container.

1401 - 1420 of 11120