Date   

Re: Fabric strategic priorities

Angelo De Caro
 

Hi Yuval,

For tokens, please look at the Fabric Token-SDK: https://github.com/hyperledger-labs/fabric-token-sdk

Let me know what do you think :)

Best,
./angelo


Re: Fabric strategic priorities

Yuval Carmel
 

I'd add native token support (FabToken)


Re: [fabric-gateway] Is next dev release upcoming?

Mark Lewis
 

it seems that at some point (maybe when we declared a first beta, or maybe just when the automated publishing was being put in place?) a package published to npm got tagged "latest". Which is fine as there needs to be a "latest" version. The problem is that since then, packages have all been published with the "unstable" tag and "latest" was never updated. So, until we can fix this, use 'npm install fabric-gateway@unstable' to pick up fabric-gateway packages. I'll raise an issue to fix this.


Re: Command line to query chaincode data?

gqqnb2005 <gqqnb2005@...>
 

That's educative. Thanks


[fabric-gateway] Is next dev release upcoming?

david liu <david-khala@...>
 

Hi fabric-gateway release managers, 

The latest npm development release happened from 6 months ago.
```
0.1.1-dev.20210325.1.0
```

We see a lot of desired updates from then. So I wonder can we have a new dev release recently?

Thanks
David Liu


Error: error sending transaction for invoke: got unexpected status: NOT_FOUND -- channel does not exist #fabric #channel #fabric-peer

earl1a@...
 

I recently deployed my test network on Kubernetes. It was working well but one day it just started encountering an error when invoking a transaction:
`Error: error sending transaction for invoke: got unexpected status: NOT_FOUND -- channel does not exist - proposal response: version:1 response:<status:200 > payload: ...`.

Running `peer channel list`, `peer channel getinfo -c mychannel`, `peer lifecycle chaincode queryinstalled`, `peer lifecycle chaincode querycommitted -C mychannel` all seem to be returning expected output.

I would appreciate any help on this. Thank you.


Re: Command line to query chaincode data?

Julian Castrence
 

One of the major tenets of Fabric architecture is that only chaincode should have direct access to the blockchain. If we allow the blockchain to be accessed by the application directly, that defeats the whole purpose of membership on a private and permissioned blockchain. To use web app architecture as an analogy, you wouldn't let the client talk directly with the database right? Better to let the server handle requests from the client and access the database. This is the role of chaincode. If the chaincode is poorly written, there's not much you can do but improve it. An application should never have the ability to read or write data directly to the blockchain.

Without knowing the full picture of your situation, you may find this helpful. There's a way to at least view the functions available within a chaincode.


Re: Fabric strategic priorities

David Enyeart
 

I'll add node configuration to the list.

No need to vote now by mail... once we settle on a list I'll put out a survey so that we can gather community rankings, probably next week.


Re: Fabric strategic priorities

Baohua Yang
 

One potential item is to get and set the node configuration at runtime, which helps a lot in monitoring and debugging.

And about the priority, I would like to vote BFT and ledger pruning as top two.

Thanks!

On Wed, Sep 22, 2021 at 6:30 AM David Enyeart <enyeart@...> wrote:

There has been a lot of work on Fabric Gateway this year - the Fabric v2.4.0-beta release is out and we are working towards a final v2.4.0 release before the end of the year.

There is also work ongoing in some other areas to socialize with the community in coming weeks, for example purging private data stores for GDPR scenarios, better kubernetes support, and improved samples.

But with v2.4 coming soon, it is a good time to take a step back and have a discussion about strategic priorities for Fabric. I'll throw out some ideas that have already been discussed, but we'd love to hear about other ideas. Once we catalog the ideas we can also have a community survey to see which ones have the most interest from users and contributors, and then start building a plan.

Here are a few of the items already being discussed:

- BFT support in ordering service. This has been long discussed and there have been investments in SmartBFT (https://github.com/SmartBFT-Go/consensus/) and MirBFT (https://github.com/hyperledger-labs/mirbft) that could be leveraged to bring BFT support to Fabric.

- Fabric Smart Client - Released as a lab last year, this is a new pattern for multi-party applications backed by Fabric that provides flexibility and privacy beyond existing chaincode and private data capabilities. We could further invest in this pattern and work towards full project status - https://github.com/hyperledger-labs/fabric-smart-client

- Replace goleveldb with a more modern key/value embedded database with better performance characteristics.

- Queryability options - We continue to see requests for additional ledger query options, and could consider query language support in peer on top of the embedded key/value state store, versus using a queryable external database (CouchDB or otherwise).

- Pruning old blocks from peer and orderer to alleviate concerns around long term storage growth

- Performance improvements - refactor peer validation/commit logic and private data handling to alleviate known performance bottlenecks

If you have thoughts on any of these or other ideas, we'd love to hear them, either in this mail thread or an upcoming contributor meeting.



--
Best wishes!

Baohua Yang


Re: Fabric strategic priorities

David Enyeart
 

The SmartBFT fork is indeed a great starting point but on an out-of-date version of Fabric. Fabric maintainers provided feedback in the SmartBFT RFC https://github.com/hyperledger/fabric-rfcs/pull/33 related to how to bring SmartBFT to mainline Fabric in a maintainable way. It would be great to pick up the conversation in the RFC and check the progress from the contributing team.


"Yacov" ---09/22/2021 10:37:00 AM---Since you mentioned SmartBFT, I would like to note, that the BFT library of https://github.com/Smart

From: "Yacov" <yacovm@...>
To: "David Enyeart" <enyeart@...>
Cc: fabric@...
Date: 09/22/2021 10:37 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Fabric strategic priorities
Sent by: fabric@...





Since you mentioned SmartBFT, I would like to note, that the BFT library of https://github.com/SmartBFT-Go/ has been integrated into a fork of Fabric more than a year ago and is in fact used in production and is publicly available for anyone ZjQcmQRYFpfptBannerStart 
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Since you mentioned SmartBFT, I would like to note, that the BFT library of  https://github.com/SmartBFT-Go/ has been integrated into a fork of Fabric more than a year ago and is in fact used in production and is publicly available for anyone to try out: https://github.com/SmartBFT-Go/fabric/
 
It is based on Fabric 1.4 and there are ready to use docker images at https://hub.docker.com/u/smartbft (use the "rotation" docker tag)
 
For anyone interested in reading about it, there is a research paper: https://arxiv.org/pdf/2107.06922.pdf
 
It might not employ the latest, most exotic and interesting BFT protocol the scientific literature has to offer, but it was designed from the ground up to fit Fabric, to run in production, and it has "good enough" performance for all existing use cases that use Fabric, but most importantly - it exists, it is finished, and among its makers are the people that made a significant part of the Fabric core.
 
So if the Fabric community wants BFT support, it's right there next door ;-)
All it needs is to knock on the neighbor's door and invite it in :-)
 
 

 
    ----- Original message -----
    From: "David Enyeart" <enyeart@...>
    Sent by: fabric@...
    To: "fabric" <fabric@...>
    Cc:
    Subject: [EXTERNAL] [Hyperledger Fabric] Fabric strategic priorities
    Date: Wed, Sep 22, 2021 4:30 PM

    There has been a lot of work on Fabric Gateway this year - the Fabric v2.4.0-beta release is out and we are working towards a final v2.4.0 release before the end of the year. There is also work ongoing in some other areas to socialize with ZjQcmQRYFpfptBannerStart
     
    This Message Is From an External Sender
    This message came from outside your organization.
    ZjQcmQRYFpfptBannerEnd

    There has been a lot of work on Fabric Gateway this year - the Fabric v2.4.0-beta release is out and we are working towards a final v2.4.0 release before the end of the year.

    There is also work ongoing in some other areas to socialize with the community in coming weeks, for example purging private data stores for GDPR scenarios, better kubernetes support, and improved samples.


    But with v2.4 coming soon, it is a good time to take a step back and have a discussion about strategic priorities for Fabric. I'll throw out some ideas that have already been discussed, but we'd love to hear about other ideas. Once we catalog the ideas we can also have a community survey to see which ones have the most interest from users and contributors, and then start building a plan.


    Here are a few of the items already being discussed:


    - BFT support in ordering service. This has been long discussed and there have been investments in SmartBFT (
    https://github.com/SmartBFT-Go/consensus/) and MirBFT (https://github.com/hyperledger-labs/mirbft) that could be leveraged to bring BFT support to Fabric.

    - Fabric Smart Client - Released as a lab last year, this is a new pattern for multi-party applications backed by Fabric that provides flexibility and privacy beyond existing chaincode and private data capabilities. We could further invest in this pattern and work towards full project status -
    https://github.com/hyperledger-labs/fabric-smart-client

    - Replace goleveldb with a more modern key/value embedded database with better performance characteristics.


    - Queryability options - We continue to see requests for additional ledger query options, and could consider query language support in peer on top of the embedded key/value state store, versus using a queryable external database (CouchDB or otherwise).


    - Pruning old blocks from peer and orderer to alleviate concerns around long term storage growth


    - Performance improvements - refactor peer validation/commit logic and private data handling to alleviate known performance bottlenecks


    If you have thoughts on any of these or other ideas, we'd love to hear them, either in this mail thread or an upcoming contributor meeting.


 







Re: Fabric strategic priorities

Yacov
 

Since you mentioned SmartBFT, I would like to note, that the BFT library of  https://github.com/SmartBFT-Go/ has been integrated into a fork of Fabric more than a year ago and is in fact used in production and is publicly available for anyone to try out: https://github.com/SmartBFT-Go/fabric/
 
It is based on Fabric 1.4 and there are ready to use docker images at https://hub.docker.com/u/smartbft (use the "rotation" docker tag)
 
For anyone interested in reading about it, there is a research paper: https://arxiv.org/pdf/2107.06922.pdf
 
It might not employ the latest, most exotic and interesting BFT protocol the scientific literature has to offer, but it was designed from the ground up to fit Fabric, to run in production, and it has "good enough" performance for all existing use cases that use Fabric, but most importantly - it exists, it is finished, and among its makers are the people that made a significant part of the Fabric core.
 
So if the Fabric community wants BFT support, it's right there next door ;-) 
All it needs is to knock on the neighbor's door and invite it in :-)
 
 
 

----- Original message -----
From: "David Enyeart" <enyeart@...>
Sent by: fabric@...
To: "fabric" <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Fabric strategic priorities
Date: Wed, Sep 22, 2021 4:30 PM
 
There has been a lot of work on Fabric Gateway this year - the Fabric v2.4.0-beta release is out and we are working towards a final v2.4.0 release before the end of the year. There is also work ongoing in some other areas to socialize with ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

There has been a lot of work on Fabric Gateway this year - the Fabric v2.4.0-beta release is out and we are working towards a final v2.4.0 release before the end of the year.

There is also work ongoing in some other areas to socialize with the community in coming weeks, for example purging private data stores for GDPR scenarios, better kubernetes support, and improved samples.

But with v2.4 coming soon, it is a good time to take a step back and have a discussion about strategic priorities for Fabric. I'll throw out some ideas that have already been discussed, but we'd love to hear about other ideas. Once we catalog the ideas we can also have a community survey to see which ones have the most interest from users and contributors, and then start building a plan.

Here are a few of the items already being discussed:

- BFT support in ordering service. This has been long discussed and there have been investments in SmartBFT (https://github.com/SmartBFT-Go/consensus/) and MirBFT (https://github.com/hyperledger-labs/mirbft) that could be leveraged to bring BFT support to Fabric.

- Fabric Smart Client - Released as a lab last year, this is a new pattern for multi-party applications backed by Fabric that provides flexibility and privacy beyond existing chaincode and private data capabilities. We could further invest in this pattern and work towards full project status - https://github.com/hyperledger-labs/fabric-smart-client

- Replace goleveldb with a more modern key/value embedded database with better performance characteristics.

- Queryability options - We continue to see requests for additional ledger query options, and could consider query language support in peer on top of the embedded key/value state store, versus using a queryable external database (CouchDB or otherwise).

- Pruning old blocks from peer and orderer to alleviate concerns around long term storage growth

- Performance improvements - refactor peer validation/commit logic and private data handling to alleviate known performance bottlenecks

If you have thoughts on any of these or other ideas, we'd love to hear them, either in this mail thread or an upcoming contributor meeting.
 

 



Fabric strategic priorities

David Enyeart
 

There has been a lot of work on Fabric Gateway this year - the Fabric v2.4.0-beta release is out and we are working towards a final v2.4.0 release before the end of the year.

There is also work ongoing in some other areas to socialize with the community in coming weeks, for example purging private data stores for GDPR scenarios, better kubernetes support, and improved samples.

But with v2.4 coming soon, it is a good time to take a step back and have a discussion about strategic priorities for Fabric. I'll throw out some ideas that have already been discussed, but we'd love to hear about other ideas. Once we catalog the ideas we can also have a community survey to see which ones have the most interest from users and contributors, and then start building a plan.

Here are a few of the items already being discussed:

- BFT support in ordering service. This has been long discussed and there have been investments in SmartBFT (https://github.com/SmartBFT-Go/consensus/) and MirBFT (https://github.com/hyperledger-labs/mirbft) that could be leveraged to bring BFT support to Fabric.

- Fabric Smart Client - Released as a lab last year, this is a new pattern for multi-party applications backed by Fabric that provides flexibility and privacy beyond existing chaincode and private data capabilities. We could further invest in this pattern and work towards full project status - https://github.com/hyperledger-labs/fabric-smart-client

- Replace goleveldb with a more modern key/value embedded database with better performance characteristics.

- Queryability options - We continue to see requests for additional ledger query options, and could consider query language support in peer on top of the embedded key/value state store, versus using a queryable external database (CouchDB or otherwise).

- Pruning old blocks from peer and orderer to alleviate concerns around long term storage growth

- Performance improvements - refactor peer validation/commit logic and private data handling to alleviate known performance bottlenecks

If you have thoughts on any of these or other ideas, we'd love to hear them, either in this mail thread or an upcoming contributor meeting.


Now: Private Chaincode Lab - 09/21/2021 #cal-notice

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

Private Chaincode Lab

When:
09/21/2021
8:00am to 9:00am
(UTC-07:00) America/Los Angeles

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

Organizer: Marcus Brandenburger bur@...

View Event

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


Calling chaincode to chaincode in hlf -2.2 external chaincode service

Chinmay Sahoo
 

Hi Team,

Please someone can help me with the ethos to call chaincode from chaincode . I have hyperledger fabric 2.2 blockchain network and using external chaincode service.


Currently I am facing no error When I am calling chaincode fro chaincode but also function is not invoked in called chaincode.

Regards,
Chinmay sahoo


Command line to query chaincode data?

gqqnb2005 <gqqnb2005@...>
 

Take the asset-transfer-basic as an example, the Java chaincode creates assets and uses stub.putStringState to save them to the blockchain.

Is there a command line counterpart of stub.getStringState?

In my bash, I would like to run
$ peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n basic --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"TransferAsset","Args":["asset6","Christopher"]}'2019-12-04 17:38:21.048 EST [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 001 Chaincode invoke successful. result: status:200
$ peer getStringState 'asset6'
{"ID":"asset6","color":"white","size":15,"owner":"Christopher","appraisedValue":800}
 
Is `peer getStringState` sort of things available?

I know I can revise chaincode and provide a method for CLI to call. But what if I can only access the source code but not modifying it? What if the chaincode is poorly written that it caches the data internally and does not actually query the blockchain?

Therefore I'm seeking a way to query blockchain from CLI without the help of user chaincode.

If you are saying CLI cannot directly query blockchain, is this a key point that differenticiates chaincode and application, that an application can not read or write chain data, but only call chaincodes?


Re: Minimal Implementation

david liu <david-khala@...>
 

how about give minifabric a try?


From: fabric@... <fabric@...> on behalf of Nicholas Leonardi via lists.hyperledger.org <nlzanutim=yahoo.com@...>
Sent: Sunday, September 19, 2021 7:55:32 PM
To: fabric@... <fabric@...>; mhdalkhaldibc@... <mhdalkhaldibc@...>
Subject: Re: [Hyperledger Fabric] Minimal Implementation
 
Em domingo, 19 de setembro de 2021 01:33:02 BRT, mhdalkhaldibc@... <mhdalkhaldibc@...> escreveu:


I'm trying to trim down fabric. My use case is simple, basic token transfer with utxos, so I want to simplify and remove features and components I'm not using. I will most likely have one org, one ca, and no special endorsement policies.
Could you please help me find some relevant resources to look at?

Thanks


Error in running External chaincode

K Sanjay Kumar
 

Hi to all, 

I followed the steps provided in the documentation to run the external chaincode i.e  https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-basic/chaincode-external/README.md

The error I get is 
failed to start basic_1.0:0262396ccaffaa2174bc09f750f742319c4f14d60b16334d2c8921b6842c090c -- peer will not accept external chaincode connection basic_1.0:0262396ccaffaa2174bc09f750f742319c4f14d60b16334d2c8921b6842c090c (except in dev mode)

Screenshot from 2021-09-20 20-33-34.png

https://hyperledger-fabric.readthedocs.io/en/release-2.3/peer-chaincode-devmode.html , the documentation here says  " In order to use the DevMode flag on a peer, TLS communications must be disabled on all the nodes in the network." 

Could you point  me to any github links or resource , to get external chaincode running , 

Is it possible to run the external chaincode without a dev mode ? or what changes do I have to make to run the external chaincode? I disable the TLS communication on all the nodes and I got an error in creating the genesis block , could you point in which places I should make changes.  




Re: Node sdk CA does not exists error

Julian Castrence
 

Hey indirajith,

Can you provide more context? What type of environment is being used? Can you provide more log messages?


Node sdk CA does not exists error

indirajith
 

Hi all, 

Hi all, I am encountering a problem when trying to enroll an admin user. Getting an error of CA does not exists, but it actually exists.
```
error: [FabricCAClientService.js]: Failed to enroll mogtestadmin, error:%o message=fabric-ca request enroll failed with errors [[ { code: 19, message: "CA 'rca-org2-map.example.com' does not exist" } ]], stack=Error: fabric-ca request enroll failed with errors [[ { code: 19, message: "CA 'rca-org2-map.example.com' does not exist" } ]] at IncomingMessage.<anonymous> (/home/indirajith/map/app/node_modules/fabric-ca-client/lib/FabricCAClient.js:298:19) at IncomingMessage.emit (events.js:412:35) at endReadableNT (internal/streams/readable.js:1317:12) at processTicksAndRejections (internal/process/task_queues.js:82:21), result=, errors=[code=19, message=CA 'rca-org2-map.example.com' does not exist], messages=[], success=false Failed to enroll admin user : Error: fabric-ca request enroll failed with errors [[ { code: 19, message: "CA 'rca-org2-map.example.com' does not exist" }
```


Can anyone please shed some light on it?

Thank you,
Indirajith.


Transaction response from the endorsers #fabric-endorser

sohaib ali gill <sohaibgill8@...>
 

Hi, 
hope you are doing well
 
I am working on a project in which I have to sign the transaction proposal offline like the user's private key, who wants to make the transaction, is stored somewhere else , remotely,wherever the user wants to keep it, not on the system where the network is running, for security purposes. To make a transaction in this way first, user has to sign the transaction proposal with the private key and then send it to the endorsers where endorsers validate the transaction proposal and then send back the transaction response to the user, then user has to send the transaction response to the orderer to commit the transaction on the ledger.Till now, I am able to sign the transaction proposal with user key and then send it to the endorsers in the network. Transaction proposal is received by the endorsers. I can confirm it by inspecting the logs of the network. but I am unable to get a response from the endorsers. Anybody who achieved this, kindly guide me.I am using Hyperledger Fabric 2.2 for this task.
 .
Any thoughts are appreciated
 
Best Regards
Sohaib