fabric@lists.hyperledger.org

Fabric Node SDK for 2.0

Siddharth Jain

#7995

Hello,

I am trying to understand what Node packages to use to develop with Fabric 2.0

https://hyperledger.github.io/fabric-sdk-node/master/tutorial-migration.html

In v2.0, fabric-network is the only recommended API for developing client applications.

but I understand fabric-network will only contain methods to transact with the chaincode (i.e., invoke and query). is that correct?

what packages do I need to use to:

create a channel and join peer nodes to it? or update channel config? is this the channel based administrative API (see below)? will there be no Node SDK for these commands?
install, approve and commit chaincode? would it be fabric-admin? when would it be available? are there are JIRA I can watch to get notified or see the progress?

https://www.npmjs.com/package/fabric-client/v/2.0.0-beta.2

The transactional API's of this package have been replaced by fabric-common.

The chaincode administrative API's of this package will be replaced by fabric-admin.

The channel based administrative API's of this package will not be replaced. Use the Hyperledger Fabric command line feature for those actions.

fabric-client - npm

SDK for writing node.js applications to interact with Hyperledger Fabric. This package encapsulates the APIs to interact with Peers and Orderers of the Fabric network to install and instantiate chaincodes, send transaction invocations and perform chaincod

www.npmjs.com

Pluggable transaction endorsement and validation #fabric-chaincode #fabric #consensus

hariomdebut1503@...

#7994

I am using the fabric 1.4.6. I am unable to use pluggable transaction endorsement and validation. There is no samples available. I also tried http://github.com/hyperledger/fabric-chaincode-go/pkg/statebased but it uses different shim and protos packages.

If i get some sample for pluggable endorsement policy. It will be very helpful.

Re: How decentralized is the Raft orderer?

Hakan Eryargi

#7993

See our Raft sample for an example for Raft orderers spanning multiple organizations.

https://github.com/APGGroeiFabriek/PIVT#scaled-up-raft-network-with-tls

Best,

Hakan

Show quoted text

On Tue, Mar 31, 2020 at 10:51 PM Siddharth Jain <siddjain@...> wrote:

pinging back on this as I have yet to see an example where all the orderer nodes are NOT owned by a single org

e.g., there is only a single org in
https://github.com/hyperledger/fabric-samples/blob/master/first-network/configtx.yaml#L352

Organizations:

- *OrdererOrg

Re: introduce msp into chaincode for authentication

qs meng <qsmeng@...>

#7992

Hi Yacov,

yes, a peer would authenticate the proposal creator, who is a member of fabric network. But in chaincode container, there is no way to authenticate an identity who belongs to one client application. If a chaincode could get CA certificate, it is feasible for chaincode to authenticate identities who belongs to client application.

I do not know if I explain it clearly.

Thank you.

Regards,

qs meng

Show quoted text

At 2020-04-01 14:45:32, "Yacov Manevich" <YACOVM@...> wrote:

The proposal is authenticated by the peer before it gets into the chaincode.

From: "qs meng" <qsmeng@...>
To: "fabric@..." <fabric@...>
Date: 04/01/2020 03:26 AM
Subject: [EXTERNAL] [Hyperledger Fabric] introduce msp into chaincode for authentication
Sent by: fabric@...

Hi,
I suggest to add msp support into chaincode to authenticate identitis in client applications. The getCreator api only get the creator and take it as authenticated already.
A way to do: for an endorsing peer, it has a function to get CA from configure block and autheniticate the transaction creator. Just copy the function to chaicode part. Is it feasible?
Thank you.
Regards,
qs meng

Error: error getting endorser client for channel

music prime

#7991

Error: error getting endorser client for channel: endorser client failed to connect to peer0.fruit.model.com:12051: failed to create new connection: connection error: desc = "transport: error while dialing: dial tcp 192.168.16.2:12051: connect: connection refused"

kindly help

Re: introduce msp into chaincode for authentication

Yacov

#7990

The proposal is authenticated by the peer before it gets into the chaincode.

From: "qs meng" <qsmeng@...>
To: "fabric@..." <fabric@...>
Date: 04/01/2020 03:26 AM
Subject: [EXTERNAL] [Hyperledger Fabric] introduce msp into chaincode for authentication
Sent by: fabric@...

Hi,
I suggest to add msp support into chaincode to authenticate identitis in client applications. The getCreator api only get the creator and take it as authenticated already.
A way to do: for an endorsing peer, it has a function to get CA from configure block and autheniticate the transaction creator. Just copy the function to chaicode part. Is it feasible?
Thank you.
Regards,
qs meng

Re: How decentralized is the Raft orderer?

Yacov

#7989

This is a sample.... You can use Raft with an organization for each orderer node.

From: "Siddharth Jain" <siddjain@...>
To: fabric@...
Date: 03/31/2020 11:51 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] How decentralized is the Raft orderer?
Sent by: fabric@...

pinging back on this as I have yet to see an example where all the orderer nodes are NOT owned by a single org

e.g., there is only a single org in
https://github.com/hyperledger/fabric-samples/blob/master/first-network/configtx.yaml#L352

Organizations:
	- *OrdererOrg

introduce msp into chaincode for authentication

qs meng <qsmeng@...>

#7988

Hi,

I suggest to add msp support into chaincode to authenticate identitis in client applications. The getCreator api only get the creator and take it as authenticated already.

A way to do: for an endorsing peer, it has a function to get CA from configure block and autheniticate the transaction creator. Just copy the function to chaicode part. Is it feasible?

Thank you.

Regards,

qs meng

Re: How decentralized is the Raft orderer?

Siddharth Jain

#7987

pinging back on this as I have yet to see an example where all the orderer nodes are NOT owned by a single org

e.g., there is only a single org in
https://github.com/hyperledger/fabric-samples/blob/master/first-network/configtx.yaml#L352

Organizations:
	- *OrdererOrg

Re: Supported elliptic curves in Hyperledger Fabric #fabric #fabric-ca

Ashutosh Kumar

#7986

Regarding curve question : Fabric and Fabric CA supports go implementation of elliptic curve , which is short-form Weierstrass curve with a=-3. I know , Fabric supports Pluggable crypto implementation , but I do not know , how this is applicable to elliptic curve. Need to look into that more closely.

Thanks and Regards.

Ashutosh Kumar

From: fabric@... <fabric@...> on behalf of vid.kersic via Lists.Hyperledger.Org <vid.kersic=yahoo.com@...>
Sent: Tuesday, March 31, 2020 3:44 AM
To: fabric@... <fabric@...>
Cc: fabric@... <fabric@...>
Subject: [Hyperledger Fabric] Supported elliptic curves in Hyperledger Fabric #fabric #fabric-ca

Hyperledger Fabric officially supports three elliptic curves: prime256v1, secp384r1 and secp521r1. Is it possible to use other elliptic curves in X.509 certificates? I read something about pluggable cryptography in Fabric, but I don't know if it's related to certificates.

Thanks.

Re: [Hyperpedger Fabric] Emit Multiple Events through single invoke method

Mr.Phuwanai Thummavet

#7985

Single transaction can emit only one event. The latest event will override other events.

Show quoted text

On Tue, 31 Mar 2020, 13:05 Divyansh Rana, <divyanshrana265@...> wrote:

Hi all,

While emitting multiple events in serial through one single chaincode invoke method, I receive only one event that is being sent in last, while I had subscribed to all the events.

Is there a limitation on the events sent through a single invoke method, or am I doing it wrong?

Supported elliptic curves in Hyperledger Fabric #fabric #fabric-ca

Vid201

#7984

Hyperledger Fabric officially supports three elliptic curves: prime256v1, secp384r1 and secp521r1. Is it possible to use other elliptic curves in X.509 certificates? I read something about pluggable cryptography in Fabric, but I don't know if it's related to certificates.

Thanks.

[Hyperpedger Fabric] Emit Multiple Events through single invoke method

divyanshrana265@...

#7983

Hi all,

While emitting multiple events in serial through one single chaincode invoke method, I receive only one event that is being sent in last, while I had subscribed to all the events.

Is there a limitation on the events sent through a single invoke method, or am I doing it wrong?

Re: [EXTERNAL] Re: [Hyperledger Fabric] upgrade not working

Park, Jungil

#7982

Thanks a lot David!!

It works!! I just removed the volume for couchdb compose file and start rebuilding transactions.

4

Met vriendelijke groet / Kind regards

Jungil Park
ABN AMRO | ABN AMRO CLEARING

Gustav Mahlerlaan 10 | 1082 PP Amsterdam | The Netherlands
Mob +31 (0)6 14667692
Email jungil.park@...
Internet www.abnamro.com
Save a tree! Print this message only if it's absolutely necessary

From: David Enyeart <enyeart@...>
Sent: 30 March 2020 19:03
To: Park, Jungil <Jungil.Park@...>
Cc: 'fabric@...' <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] upgrade not working

WARNING: External email – exercise caution. Please forward suspicious emails to your local security team.

The error indicates that you must drop the CouchDB database that is in v1.x format, before starting the v2.0 peer. The first time the v2.0 peer starts, it will rebuild the CouchDB state database in v2.x format.

I've also submitted a PR to clarify the documentation as such:
https://github.com/hyperledger/fabric/pull/949

Dave Enyeart

"Park, Jungil" ---03/30/2020 08:08:51 AM---Hi Team, I am using 1.4.0 with couchdb and tried to upgrade to 2.0.

From: "Park, Jungil" <jungil.park@...>
To: "'enyeart@...'" <enyeart@...>, "'fabric@...'" <fabric@...>
Date: 03/30/2020 08:08 AM
Subject: [EXTERNAL] [Hyperledger Fabric] upgrade not working
Sent by: fabric@...

Hi Team,

I am using 1.4.0 with couchdb and tried to upgrade to 2.0.
I use the following commands.

1. command

docker run --rm -v /opt/hyperledger/production/peer0org1:/var/hyperledger/production/ \
-v /opt/hfabric.v1x/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp/ \
--name peer0.org1.example.com \
--env CORE_LEDGER_STATE_STATEDATABASE=CouchDB \
hyperledger/fabric-peer:2.0 peer node upgrade-dbs

2. ouput

2020-03-30 11:29:56.778 UTC [kvledger] UpgradeDBs -> INFO 001 Ledger data folder from config = [/var/hyperledger/production/ledgersData]
2020-03-30 11:29:56.783 UTC [kvledger] dropStateLevelDB -> INFO 002 Dropping StateLevelDB at location [/var/hyperledger/production/ledgersData/stateLeveldb] ...if present
2020-03-30 11:29:56.783 UTC [kvledger] dropConfigHistoryDB -> INFO 003 Dropping ConfigHistoryDB at location [/var/hyperledger/production/ledgersData/configHistory]
2020-03-30 11:29:56.784 UTC [kvledger] dropBookkeeperDB -> INFO 004 Dropping BookkeeperDB at location [/var/hyperledger/production/ledgersData/bookkeeper]
2020-03-30 11:29:56.784 UTC [kvledger] dropHistoryDB -> INFO 005 Dropping HistoryDB at location [/var/hyperledger/production/ledgersData/historyLeveldb] ...if present
2020-03-30 11:29:56.784 UTC [fsblkstorage] DeleteBlockStoreIndex -> INFO 006 Dropping the index dir [/var/hyperledger/production/ledgersData/chains/index]... if present

3. second command

docker run --rm -v /opt/hyperledger/production/peer0org1:/var/hyperledger/production/ \
-v /opt/hfabric.v1x/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp/ \
--name peer0.org1.example.com \
hyperledger/fabric-peer:2.0 peer node start

4. ouput :
5. 2020-03-30 09:00:24.383 UTC [nodeCmd] serve -> INFO 001 Starting peer:
6. Version: 2.0.0
7. Commit SHA: 0432c3e
8. Go version: go1.13.4
9. OS/Arch: linux/amd64
10. Chaincode:
11. Base Docker Namespace: hyperledger
12. Base Docker Label: org.hyperledger.fabric
13. Docker Namespace: hyperledger
14. 2020-03-30 09:00:24.384 UTC [peer] getLocalAddress -> INFO 002 Auto-detected peer address: 172.17.0.2:7051
15. 2020-03-30 09:00:24.384 UTC [peer] getLocalAddress -> INFO 003 Host is 0.0.0.0 , falling back to auto-detected address: 172.17.0.2:7051
16. 2020-03-30 09:00:24.414 UTC [gossip.service] New -> INFO 004 Initialize gossip with endpoint 172.17.0.2:7051
17. 2020-03-30 09:00:24.416 UTC [gossip.gossip] New -> INFO 005 Creating gossip service with self membership of Endpoint: , InternalEndpoint: 172.17.0.2:7051, PKI-ID: 65dfd2f8791c19aacad25b10a94d2db1219f7be324344483be4bdf8aee89bd3b, Metadata:
18. 2020-03-30 09:00:24.416 UTC [gossip.gossip] New -> WARN 006 External endpoint is empty, peer will not be accessible outside of its organization
19. 2020-03-30 09:00:24.416 UTC [gossip.gossip] start -> INFO 007 Gossip instance 172.17.0.2:7051 started
20. 2020-03-30 09:00:24.417 UTC [ledgermgmt] NewLedgerMgr -> INFO 008 Initializing LedgerMgr
21. 2020-03-30 09:00:24.456 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 009 DB is empty Setting db format as 2.0
22. 2020-03-30 09:00:24.483 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 00a DB is empty Setting db format as 2.0
23. 2020-03-30 09:00:24.484 UTC [ledgermgmt] NewLedgerMgr -> INFO 00b Initialized LedgerMgr
24. 2020-03-30 09:00:24.484 UTC [lifecycle] InitializeLocalChaincodes -> INFO 00c Initialized lifecycle cache with 0 already installed chaincodes
25. 2020-03-30 09:00:24.485 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00d Entering computeChaincodeEndpoint with peerHostname: 172.17.0.2
26. 2020-03-30 09:00:24.485 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00e Exit with ccEndpoint: 172.17.0.2:7052
27. 2020-03-30 09:00:24.485 UTC [nodeCmd] createChaincodeServer -> WARN 00f peer.chaincodeListenAddress is not set, using 172.17.0.2:7052
28. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 010 deploying system chaincode 'lscc'
29. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 011 deploying system chaincode 'cscc'
30. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 012 deploying system chaincode 'qscc'
31. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 013 deploying system chaincode '_lifecycle'
32. 2020-03-30 09:00:24.490 UTC [nodeCmd] serve -> INFO 014 Deployed system chaincodes
33. 2020-03-30 09:00:24.490 UTC [peer] Initialize -> INFO 015 Loading chain mychannel
34. 2020-03-30 09:00:24.490 UTC [ledgermgmt] OpenLedger -> INFO 016 Opening ledger with id = mychannel
35. 2020-03-30 09:00:24.491 UTC [fsblkstorage] newBlockfileMgr -> INFO 017 Getting block information from block storage
36. 2020-03-30 09:00:24.540 UTC [fsblkstorage] syncIndex -> INFO 018 Start building index from block [0] to last block [35356]
37. 2020-03-30 09:00:24.542 UTC [fsblkstorage] syncIndex -> INFO 019 Indexed block number [0]
38. 2020-03-30 09:00:35.837 UTC [fsblkstorage] syncIndex -> INFO 01a Indexed block number [10000]
39. 2020-03-30 09:00:47.392 UTC [fsblkstorage] syncIndex -> INFO 01b Indexed block number [20000]
40. 2020-03-30 09:01:00.008 UTC [fsblkstorage] syncIndex -> INFO 01c Indexed block number [30000]
41. 2020-03-30 09:01:06.764 UTC [fsblkstorage] syncIndex -> INFO 01d Finished building index. Last block indexed [35356]
42. 2020-03-30 09:01:06.764 UTC [kvledger] recommitLostBlocks -> INFO 01e Recommitting lost blocks - firstBlockNum=0, lastBlockNum=35356, recoverables=[]kvledger.recoverable{(*lockbasedtxmgr.LockBasedTxMgr)(0xc00021cfa0), (*history.DB)(0xc005fda980)}
43. 2020-03-30 09:01:06.765 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 01f Recommitting block [0] to state database
44. 2020-03-30 09:01:06.766 UTC [history] CommitLostBlock -> INFO 020 Recommitting block [0] to history database
45. 2020-03-30 09:01:06.772 UTC [cceventmgmt] HandleStateUpdates -> INFO 021 Channel [mychannel]: Handling deploy or update of chaincode [chaincode]
46. 2020-03-30 09:01:06.778 UTC [valimpl] preprocessProtoBlock -> WARN 022 Channel [mychannel]: Block [4] Transaction index [0] TxId [b5199e1b5d1f4522eca11680757652ae2882ebce5b66d4b534e5a5ccfcd3562d] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
47. 2020-03-30 09:01:09.088 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 023 Recommitting block [1000] to state database
48. 2020-03-30 09:01:09.090 UTC [history] CommitLostBlock -> INFO 024 Recommitting block [1000] to history database
49. 2020-03-30 09:01:11.437 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 025 Recommitting block [2000] to state database
50. 2020-03-30 09:01:11.438 UTC [history] CommitLostBlock -> INFO 026 Recommitting block [2000] to history database
51. 2020-03-30 09:01:13.755 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 027 Recommitting block [3000] to state database
52. 2020-03-30 09:01:13.756 UTC [history] CommitLostBlock -> INFO 028 Recommitting block [3000] to history database
53. 2020-03-30 09:01:16.122 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 029 Recommitting block [4000] to state database
54. 2020-03-30 09:01:16.123 UTC [history] CommitLostBlock -> INFO 02a Recommitting block [4000] to history database
55. 2020-03-30 09:01:16.836 UTC [valimpl] preprocessProtoBlock -> WARN 02b Channel [mychannel]: Block [4297] Transaction index [2] TxId [8a17e87c38c6c8f99e59166695feae179cf5ca99494a6167fe23e7ff23c104e9] marked as invalid by committer. Reason code [MVCC_READ_CONFLICT]
56. 2020-03-30 09:01:16.836 UTC [valimpl] preprocessProtoBlock -> WARN 02c Channel [mychannel]: Block [4297] Transaction index [3] TxId [c78daa54b1c61f6c54d330af34649137d719374bf43a7a8189ae5d09dc1f31ad] marked as invalid by committer. Reason code [MVCC_READ_CONFLICT]

After this, still I got error below

2020-03-30 11:33:03.108 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 00a DB is empty Setting db format as 2.0
2020-03-30 11:33:03.195 UTC [kvledger] func1 -> ERRO 00b Please execute the 'peer node upgrade-dbs' command to upgrade the database format: unexpected format. db info = [CouchDB for state database], data format = [], expected format = [2.0]
2020-03-30 11:33:03.195 UTC [gossip.gossip] Stop -> INFO 00c Stopping gossip
2020-03-30 11:33:03.195 UTC [gossip.discovery] Stop -> INFO 00d Stopping
2020-03-30 11:33:03.195 UTC [gossip.discovery] Stop -> INFO 00e Stopped
2020-03-30 11:33:03.195 UTC [gossip.comm] Stop -> INFO 00f Stopping
2020-03-30 11:33:03.195 UTC [gossip.comm] Stop -> INFO 010 Stopped
panic: Error in instantiating ledger provider: unexpected format. db info = [CouchDB for state database], data format = [], expected format = [2.0]
goroutine 1 [running]:

Does anyone any idea what happen here?

Thanks,
Jungil.

This message has been sent by ABN AMRO Bank N.V., which has its seat at Gustav Mahlerlaan 10 (1082 PP) Amsterdam, the Netherlands, and is registered in the Commercial Register of Amsterdam under number 34334259.

Deleting a range from a private collection

Victor Dods

#7981

Hi all,

With the restriction on range-query and then write in a private collection during the same transaction, I'm wondering how people achieve an effective "delete range". My end-goal is that all private collection keys in some range [start, end) are deleted, and I don't care what the keys are, nor their values.

At the moment I'm doing a rather hacky:
(1) range-query the keys in the range to delete in one transaction.
(2) submitting a second transaction which specifies those keys explicitly for deletion, so that DelPrivateData can be called on each one.

The problems with this though are:
(a) unless additional locking logic is implemented, there's a race condition if someone were to add a key within that range between steps (1) and (2), then the end result is that there's this stray key that step (2) didn't delete.
(b) a potentially huge amount of data (I can easily imagine a realistic scenario with millions of keys) has to be queried and then sent back, even though the essential operation doesn't require any of that information.

It seems like a `DelPrivateDataByRange(collection, startKey, endKey string) error` method would do the trick, but nothing like that is present in Fabric 1.4 or 2.0.

How are others achieving this effect? The main usecase I'm thinking of is complying with GDPR style erasure requests which require deleting ranges of data from private collections.

Re: Limiting dissemination of hashes of private collection keys and values?

Victor Dods

#7980

Interesting, that's a good idea. While I don't like that I have to manage these salts manually, that seems like it should work. Thanks!

Victor Dods

Chief Software Architect

LedgerDomain

Show quoted text

On Sat, Mar 28, 2020 at 4:02 AM Yacov Manevich <YACOVM@...> wrote:

Regarding the "same salt for all keys":
What if you have a special key that stores the salt, per collection: "salt" ---> salt
and when you want to access the other keys you always read from this "salt" key to get salt and then use it to access the other keys?

Regarding:

> (2) still allows an attacker to see that two keys are equal, two values are equal, or a key is equal to a value.
If you use the collection name inside the hash ( hash(collection || key || salt) ) then two keys in different collections are not equal.
You can also make the values be: hash(collection || key || value || salt) and then the key place a role in the hash computation of a value, so two values that are the same but in different keys, do not look the same.

From: Victor Dods <victor.dods@...>
To: Yacov Manevich <YACOVM@...>
Cc: fabric@...
Date: 03/28/2020 02:38 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Limiting dissemination of hashes of private collection keys and values?

Thanks for the reply, Yacov!

Appending a salt to the plaintext of each key* means that I need to retain and supply that salt in order to use GetPrivateData, which further means that I need to know which keys I'll be accessing in advance of the transaction proposal so I can send the appropriate salt(s) in the transient data field. This represents (1) a significant architectural burden, (2) broken encapsulation of the chaincode call (the caller can't and shouldn't be expected to know all the keys that the chaincode will use in advance).

Perhaps it would be useful to elaborate on a more essential version of my suggestion. Forget the part about the HMAC. Add a modified version of PutPrivateData to ChaincodeStubInterface:
- PutPrivateDataWithNonces(collection string, key string, keyNonce []byte, value []byte, valueNonce []byte) error
When this is called, it stores the quadruple (key, keyNonce, value, valueNonce) in the Private State, and it stores (hash(keyNonce+key), hash(valueNonce+value)) in the Channel State. Here, the chaincode author is responsible for generating those nonces. Then the hash scheme is exactly as you say, except that now the nonces don't interfere with the keys and values, and I can use GetPrivateData and other related functions just as I would if I didn't have to worry about nonces (i.e. GetPrivateData etc are backward-compatible). The concerns are now separate.
- PutPrivateData doesn't change, and internally it just uses empty byte arrays for keyNonce and valNonce, so the behavior of the hash scheme is still compatible with the existing Fabric protocol.

The difference between this and my original suggestion is that Fabric would be:
- generating those nonces for you (so no repetitive boilerplate for chaincode authors)
- automatically (so all chaincode authors benefit without additional work on their part)
- using a well-defined, tested scheme (so each chaincode author isn't burdened with having to implement it correctly themselves).

*You might suggest that you could just use a single salt for all keys, but (1) that still imposes a burden to manage that salt outside of the chaincode and (2) still allows an attacker to see that two keys are equal, two values are equal, or a key is equal to a value.

Victor Dods
Chief Software Architect
LedgerDomain

On Fri, Mar 27, 2020 at 1:43 PM Yacov Manevich <YACOVM@...> wrote:
why do you need a MAC? What's wrong with just appending a salt to the plaintext? You're not protecting against any length extension attacks or doing any kind of authentication.

From: "Victor Dods" <victor.dods@...>
To: fabric@...
Date: 03/27/2020 05:28 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Limiting dissemination of hashes of private collection keys and values?
Sent by: fabric@...

Hi all, I'm wondering if there's a mechanism for specifying that the hashes of private collection keys and values should not be disseminated beyond the peers of that private collection. Basically my use case is such that I know that a particular private collection's data will never be used outside of the peers of that collection, and the issue regarding having to put nonces into private values and KEYS in particular is a total pain. Because I don't need this extra-collection verification, I don't want the overhead that comes along with that.

Or failing that, what is a reasonable scheme for putting nonces into the keys of a private collection? It can't be truly random, otherwise there's no way to recover the nonced key (e.g. "abc@...%00<random-nonce>") from the "bare" key (e.g. "abc@..."). One could make it deterministic by making the nonce a the hashed value of the bare key, but then if an attacker knows which hash function you're using, they could brute force the key in smaller spaces (phone numbers, email addresses, etc). You could use an HMAC with a specified key, but then you (1) have to manage that HMAC key, (2) have to tie the lifetime of that HMAC key to the lifetime of the key/value pair, and (3) have to use the same HMAC key for all key/value pairs OR have some scheme for using multiple HMAC keys and mapping them to the key/value pairs. Basically the problem of having to manually embed the nonces in the keys and values really gets in the way.

One thing that comes to mind is using truly random nonces for the keys, and then doing a GetPrivateDataByPartialCompositeKey using the bare key to deal with not knowing the nonce, but then you're in the situation where you've done a range-based query, and are then subject to the limitations detailed here: https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data-arch.html#querying-private-datawhich is a total pain.

Anyway, I'd generally like to hear about how people have been dealing with this issue.

As a side comment for the Fabric maintainers -- I've brought this issue up in the past, and so have others -- why not have Fabric do this sort of nonce bookkeeping automatically? If everyone is responsible for manually implementing it themselves, how many people are (1) going to do it at all and (2) going to do it correctly?

An idea for how this could work:
- If a transaction is going to write any private data, require a RNG seed be set using a new SeedRNG method in the chaincode stub (otherwise the transaction fails with error). This RNG seed would be passed into the endorsing peer via the transient data field. Potentially the name of the HMAC scheme should be a channel configuration value.
- When a private data write is done, generate a pair of HMAC keys from the seeded RNG, one for the key and one for the value, and keep them in parallel with the key and value. Thus the diagram in this section https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data/private-data.html#what-is-a-private-data-collectionwould have a quadruple (k1, k1HMACkey, secret-value, secret-value-HMACkey) for Private State.
- Then instead of hash(k1) and hash(secret-value) being stored in the Channel State, it's HMAC(k1, k1HMACkey) and HMAC(secret-value, secret-value-HMACkey), which can be verified just as easily as before.
- Finally, all the stub's Get/Put/Del methods for private data operate on the "bare" key/value pairs as expected and ideally desired, and there's no interference from the details of the HMAC scheme, and all is well in the world again.

I'd be curious to hear thoughts on this from Fabric maintainers and other interested people.

PS: Thanks to Mike Lodder for educating me on HMACs and other security mechanisms.

Re: upgrade not working

David Enyeart

#7979

The error indicates that you must drop the CouchDB database that is in v1.x format, before starting the v2.0 peer. The first time the v2.0 peer starts, it will rebuild the CouchDB state database in v2.x format.

I've also submitted a PR to clarify the documentation as such:
https://github.com/hyperledger/fabric/pull/949

Dave Enyeart

"Park, Jungil" ---03/30/2020 08:08:51 AM---Hi Team, I am using 1.4.0 with couchdb and tried to upgrade to 2.0.

From: "Park, Jungil" <jungil.park@...>
To: "'enyeart@...'" <enyeart@...>, "'fabric@...'" <fabric@...>
Date: 03/30/2020 08:08 AM
Subject: [EXTERNAL] [Hyperledger Fabric] upgrade not working
Sent by: fabric@...

Hi Team,

I am using 1.4.0 with couchdb and tried to upgrade to 2.0.
I use the following commands.

1. command

docker run --rm -v /opt/hyperledger/production/peer0org1:/var/hyperledger/production/ \
-v /opt/hfabric.v1x/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp/ \
--name peer0.org1.example.com \
--env CORE_LEDGER_STATE_STATEDATABASE=CouchDB \
hyperledger/fabric-peer:2.0 peer node upgrade-dbs

2. ouput

2020-03-30 11:29:56.778 UTC [kvledger] UpgradeDBs -> INFO 001 Ledger data folder from config = [/var/hyperledger/production/ledgersData]
2020-03-30 11:29:56.783 UTC [kvledger] dropStateLevelDB -> INFO 002 Dropping StateLevelDB at location [/var/hyperledger/production/ledgersData/stateLeveldb] ...if present
2020-03-30 11:29:56.783 UTC [kvledger] dropConfigHistoryDB -> INFO 003 Dropping ConfigHistoryDB at location [/var/hyperledger/production/ledgersData/configHistory]
2020-03-30 11:29:56.784 UTC [kvledger] dropBookkeeperDB -> INFO 004 Dropping BookkeeperDB at location [/var/hyperledger/production/ledgersData/bookkeeper]
2020-03-30 11:29:56.784 UTC [kvledger] dropHistoryDB -> INFO 005 Dropping HistoryDB at location [/var/hyperledger/production/ledgersData/historyLeveldb] ...if present
2020-03-30 11:29:56.784 UTC [fsblkstorage] DeleteBlockStoreIndex -> INFO 006 Dropping the index dir [/var/hyperledger/production/ledgersData/chains/index]... if present

3. second command

docker run --rm -v /opt/hyperledger/production/peer0org1:/var/hyperledger/production/ \
-v /opt/hfabric.v1x/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp/ \
--name peer0.org1.example.com \
hyperledger/fabric-peer:2.0 peer node start

4. ouput :

2020-03-30 09:00:24.383 UTC [nodeCmd] serve -> INFO 001

2020-03-30 09:00:24.384 UTC [peer] getLocalAddress -> INFO 002

2020-03-30 09:00:24.384 UTC [peer] getLocalAddress -> INFO 003

2020-03-30 09:00:24.414 UTC [gossip.service] New -> INFO 004

2020-03-30 09:00:24.416 UTC [gossip.gossip] New -> INFO 005

2020-03-30 09:00:24.416 UTC [gossip.gossip] New -> WARN 006

2020-03-30 09:00:24.416 UTC [gossip.gossip] start -> INFO 007

2020-03-30 09:00:24.417 UTC [ledgermgmt] NewLedgerMgr -> INFO 008

2020-03-30 09:00:24.456 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 009

2020-03-30 09:00:24.483 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 00a

2020-03-30 09:00:24.484 UTC [ledgermgmt] NewLedgerMgr -> INFO 00b

2020-03-30 09:00:24.484 UTC [lifecycle] InitializeLocalChaincodes -> INFO 00c

2020-03-30 09:00:24.485 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00d

2020-03-30 09:00:24.485 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00e

2020-03-30 09:00:24.485 UTC [nodeCmd] createChaincodeServer -> WARN 00f

2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 010

2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 011

2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 012

2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 013

2020-03-30 09:00:24.490 UTC [nodeCmd] serve -> INFO 014

2020-03-30 09:00:24.490 UTC [peer] Initialize -> INFO 015

2020-03-30 09:00:24.490 UTC [ledgermgmt] OpenLedger -> INFO 016

2020-03-30 09:00:24.491 UTC [fsblkstorage] newBlockfileMgr -> INFO 017

2020-03-30 09:00:24.540 UTC [fsblkstorage] syncIndex -> INFO 018

2020-03-30 09:00:24.542 UTC [fsblkstorage] syncIndex -> INFO 019

2020-03-30 09:00:35.837 UTC [fsblkstorage] syncIndex -> INFO 01a

2020-03-30 09:00:47.392 UTC [fsblkstorage] syncIndex -> INFO 01b

2020-03-30 09:01:00.008 UTC [fsblkstorage] syncIndex -> INFO 01c

2020-03-30 09:01:06.764 UTC [fsblkstorage] syncIndex -> INFO 01d

2020-03-30 09:01:06.764 UTC [kvledger] recommitLostBlocks -> INFO 01e

2020-03-30 09:01:06.765 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 01f

2020-03-30 09:01:06.766 UTC [history] CommitLostBlock -> INFO 020

2020-03-30 09:01:06.772 UTC [cceventmgmt] HandleStateUpdates -> INFO 021

2020-03-30 09:01:06.778 UTC [valimpl] preprocessProtoBlock -> WARN 022

2020-03-30 09:01:09.088 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 023

2020-03-30 09:01:09.090 UTC [history] CommitLostBlock -> INFO 024

2020-03-30 09:01:11.437 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 025

2020-03-30 09:01:11.438 UTC [history] CommitLostBlock -> INFO 026

2020-03-30 09:01:13.755 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 027

2020-03-30 09:01:13.756 UTC [history] CommitLostBlock -> INFO 028

2020-03-30 09:01:16.122 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 029

2020-03-30 09:01:16.123 UTC [history] CommitLostBlock -> INFO 02a

2020-03-30 09:01:16.836 UTC [valimpl] preprocessProtoBlock -> WARN 02b

2020-03-30 09:01:16.836 UTC [valimpl] preprocessProtoBlock -> WARN 02c

After this, still I got error below

2020-03-30 11:33:03.108 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 00a DB is empty Setting db format as 2.0
2020-03-30 11:33:03.195 UTC [kvledger] func1 -> ERRO 00b Please execute the 'peer node upgrade-dbs' command to upgrade the database format: unexpected format. db info = [CouchDB for state database], data format = [], expected format = [2.0]
2020-03-30 11:33:03.195 UTC [gossip.gossip] Stop -> INFO 00c Stopping gossip
2020-03-30 11:33:03.195 UTC [gossip.discovery] Stop -> INFO 00d Stopping
2020-03-30 11:33:03.195 UTC [gossip.discovery] Stop -> INFO 00e Stopped
2020-03-30 11:33:03.195 UTC [gossip.comm] Stop -> INFO 00f Stopping
2020-03-30 11:33:03.195 UTC [gossip.comm] Stop -> INFO 010 Stopped
panic: Error in instantiating ledger provider: unexpected format. db info = [CouchDB for state database], data format = [], expected format = [2.0]
goroutine 1 [running]:

Does anyone any idea what happen here?

Thanks,
Jungil.

This message has been sent by ABN AMRO Bank N.V., which has its seat at Gustav Mahlerlaan 10 (1082 PP) Amsterdam, the Netherlands, and is registered in the Commercial Register of Amsterdam under number 34334259.

Re: upgrade not working

Park, Jungil

#7978

Hi Team,

Can anyone help with this?

Does anyone experience a similar issue like this?

Met vriendelijke groet / Kind regards

Jungil Park
ABN AMRO | ABN AMRO CLEARING

Gustav Mahlerlaan 10 | 1082 PP Amsterdam | The Netherlands
Mob +31 (0)6 14667692
Email jungil.park@...
Internet www.abnamro.com
Save a tree! Print this message only if it's absolutely necessary

From: jungil.park@... <jungil.park@...>
Sent: 30 March 2020 14:09
To: 'enyeart@...' <enyeart@...>; 'fabric@...' <fabric@...>
Subject: [External] [Hyperledger Fabric] upgrade not working

Hi Team,

I am using 1.4.0 with couchdb and tried to upgrade to 2.0.

I use the following commands.

1. command

docker run --rm -v /opt/hyperledger/production/peer0org1:/var/hyperledger/production/ \

-v /opt/hfabric.v1x/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp/ \

--name peer0.org1.example.com \

--env CORE_LEDGER_STATE_STATEDATABASE=CouchDB \

hyperledger/fabric-peer:2.0 peer node upgrade-dbs

2. ouput

2020-03-30 11:29:56.778 UTC [kvledger] UpgradeDBs -> INFO 001 Ledger data folder from config = [/var/hyperledger/production/ledgersData]

2020-03-30 11:29:56.783 UTC [kvledger] dropStateLevelDB -> INFO 002 Dropping StateLevelDB at location [/var/hyperledger/production/ledgersData/stateLeveldb] ...if present

2020-03-30 11:29:56.783 UTC [kvledger] dropConfigHistoryDB -> INFO 003 Dropping ConfigHistoryDB at location [/var/hyperledger/production/ledgersData/configHistory]

2020-03-30 11:29:56.784 UTC [kvledger] dropBookkeeperDB -> INFO 004 Dropping BookkeeperDB at location [/var/hyperledger/production/ledgersData/bookkeeper]

2020-03-30 11:29:56.784 UTC [kvledger] dropHistoryDB -> INFO 005 Dropping HistoryDB at location [/var/hyperledger/production/ledgersData/historyLeveldb] ...if present

2020-03-30 11:29:56.784 UTC [fsblkstorage] DeleteBlockStoreIndex -> INFO 006 Dropping the index dir [/var/hyperledger/production/ledgersData/chains/index]... if present

3. second command

docker run --rm -v /opt/hyperledger/production/peer0org1:/var/hyperledger/production/ \

-v /opt/hfabric.v1x/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp/ \

--name peer0.org1.example.com \

hyperledger/fabric-peer:2.0 peer node start

4. ouput :

5. 2020-03-30 09:00:24.383 UTC [nodeCmd] serve -> INFO 001 Starting peer:

6. Version: 2.0.0

7. Commit SHA: 0432c3e

8. Go version: go1.13.4

9. OS/Arch: linux/amd64

10. Chaincode:

11. Base Docker Namespace: hyperledger

12. Base Docker Label: org.hyperledger.fabric

13. Docker Namespace: hyperledger

14. 2020-03-30 09:00:24.384 UTC [peer] getLocalAddress -> INFO 002 Auto-detected peer address: 172.17.0.2:7051

15. 2020-03-30 09:00:24.384 UTC [peer] getLocalAddress -> INFO 003 Host is 0.0.0.0 , falling back to auto-detected address: 172.17.0.2:7051

16. 2020-03-30 09:00:24.414 UTC [gossip.service] New -> INFO 004 Initialize gossip with endpoint 172.17.0.2:7051

17. 2020-03-30 09:00:24.416 UTC [gossip.gossip] New -> INFO 005 Creating gossip service with self membership of Endpoint: , InternalEndpoint: 172.17.0.2:7051, PKI-ID: 65dfd2f8791c19aacad25b10a94d2db1219f7be324344483be4bdf8aee89bd3b, Metadata:

18. 2020-03-30 09:00:24.416 UTC [gossip.gossip] New -> WARN 006 External endpoint is empty, peer will not be accessible outside of its organization

19. 2020-03-30 09:00:24.416 UTC [gossip.gossip] start -> INFO 007 Gossip instance 172.17.0.2:7051 started

20. 2020-03-30 09:00:24.417 UTC [ledgermgmt] NewLedgerMgr -> INFO 008 Initializing LedgerMgr

21. 2020-03-30 09:00:24.456 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 009 DB is empty Setting db format as 2.0

22. 2020-03-30 09:00:24.483 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 00a DB is empty Setting db format as 2.0

23. 2020-03-30 09:00:24.484 UTC [ledgermgmt] NewLedgerMgr -> INFO 00b Initialized LedgerMgr

24. 2020-03-30 09:00:24.484 UTC [lifecycle] InitializeLocalChaincodes -> INFO 00c Initialized lifecycle cache with 0 already installed chaincodes

25. 2020-03-30 09:00:24.485 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00d Entering computeChaincodeEndpoint with peerHostname: 172.17.0.2

26. 2020-03-30 09:00:24.485 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00e Exit with ccEndpoint: 172.17.0.2:7052

27. 2020-03-30 09:00:24.485 UTC [nodeCmd] createChaincodeServer -> WARN 00f peer.chaincodeListenAddress is not set, using 172.17.0.2:7052

28. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 010 deploying system chaincode 'lscc'

29. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 011 deploying system chaincode 'cscc'

30. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 012 deploying system chaincode 'qscc'

31. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 013 deploying system chaincode '_lifecycle'

32. 2020-03-30 09:00:24.490 UTC [nodeCmd] serve -> INFO 014 Deployed system chaincodes

33. 2020-03-30 09:00:24.490 UTC [peer] Initialize -> INFO 015 Loading chain mychannel

34. 2020-03-30 09:00:24.490 UTC [ledgermgmt] OpenLedger -> INFO 016 Opening ledger with id = mychannel

35. 2020-03-30 09:00:24.491 UTC [fsblkstorage] newBlockfileMgr -> INFO 017 Getting block information from block storage

36. 2020-03-30 09:00:24.540 UTC [fsblkstorage] syncIndex -> INFO 018 Start building index from block [0] to last block [35356]

37. 2020-03-30 09:00:24.542 UTC [fsblkstorage] syncIndex -> INFO 019 Indexed block number [0]

38. 2020-03-30 09:00:35.837 UTC [fsblkstorage] syncIndex -> INFO 01a Indexed block number [10000]

39. 2020-03-30 09:00:47.392 UTC [fsblkstorage] syncIndex -> INFO 01b Indexed block number [20000]

40. 2020-03-30 09:01:00.008 UTC [fsblkstorage] syncIndex -> INFO 01c Indexed block number [30000]

41. 2020-03-30 09:01:06.764 UTC [fsblkstorage] syncIndex -> INFO 01d Finished building index. Last block indexed [35356]

42. 2020-03-30 09:01:06.764 UTC [kvledger] recommitLostBlocks -> INFO 01e Recommitting lost blocks - firstBlockNum=0, lastBlockNum=35356, recoverables=[]kvledger.recoverable{(*lockbasedtxmgr.LockBasedTxMgr)(0xc00021cfa0), (*history.DB)(0xc005fda980)}

43. 2020-03-30 09:01:06.765 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 01f Recommitting block [0] to state database

44. 2020-03-30 09:01:06.766 UTC [history] CommitLostBlock -> INFO 020 Recommitting block [0] to history database

45. 2020-03-30 09:01:06.772 UTC [cceventmgmt] HandleStateUpdates -> INFO 021 Channel [mychannel]: Handling deploy or update of chaincode [chaincode]

46. 2020-03-30 09:01:06.778 UTC [valimpl] preprocessProtoBlock -> WARN 022 Channel [mychannel]: Block [4] Transaction index [0] TxId [b5199e1b5d1f4522eca11680757652ae2882ebce5b66d4b534e5a5ccfcd3562d] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]

47. 2020-03-30 09:01:09.088 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 023 Recommitting block [1000] to state database

48. 2020-03-30 09:01:09.090 UTC [history] CommitLostBlock -> INFO 024 Recommitting block [1000] to history database

49. 2020-03-30 09:01:11.437 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 025 Recommitting block [2000] to state database

50. 2020-03-30 09:01:11.438 UTC [history] CommitLostBlock -> INFO 026 Recommitting block [2000] to history database

51. 2020-03-30 09:01:13.755 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 027 Recommitting block [3000] to state database

52. 2020-03-30 09:01:13.756 UTC [history] CommitLostBlock -> INFO 028 Recommitting block [3000] to history database

53. 2020-03-30 09:01:16.122 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 029 Recommitting block [4000] to state database

54. 2020-03-30 09:01:16.123 UTC [history] CommitLostBlock -> INFO 02a Recommitting block [4000] to history database

55. 2020-03-30 09:01:16.836 UTC [valimpl] preprocessProtoBlock -> WARN 02b Channel [mychannel]: Block [4297] Transaction index [2] TxId [8a17e87c38c6c8f99e59166695feae179cf5ca99494a6167fe23e7ff23c104e9] marked as invalid by committer. Reason code [MVCC_READ_CONFLICT]

56. 2020-03-30 09:01:16.836 UTC [valimpl] preprocessProtoBlock -> WARN 02c Channel [mychannel]: Block [4297] Transaction index [3] TxId [c78daa54b1c61f6c54d330af34649137d719374bf43a7a8189ae5d09dc1f31ad] marked as invalid by committer. Reason code [MVCC_READ_CONFLICT]

After this, still I got error below

2020-03-30 11:33:03.108 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 00a DB is empty Setting db format as 2.0

2020-03-30 11:33:03.195 UTC [kvledger] func1 -> ERRO 00b Please execute the 'peer node upgrade-dbs' command to upgrade the database format: unexpected format. db info = [CouchDB for state database], data format = [], expected format = [2.0]

2020-03-30 11:33:03.195 UTC [gossip.gossip] Stop -> INFO 00c Stopping gossip

2020-03-30 11:33:03.195 UTC [gossip.discovery] Stop -> INFO 00d Stopping

2020-03-30 11:33:03.195 UTC [gossip.discovery] Stop -> INFO 00e Stopped

2020-03-30 11:33:03.195 UTC [gossip.comm] Stop -> INFO 00f Stopping

2020-03-30 11:33:03.195 UTC [gossip.comm] Stop -> INFO 010 Stopped

panic: Error in instantiating ledger provider: unexpected format. db info = [CouchDB for state database], data format = [], expected format = [2.0]

goroutine 1 [running]:

Does anyone any idea what happen here?

Thanks,

Jungil.

This message has been sent by ABN AMRO Bank N.V., which has its seat at Gustav Mahlerlaan 10 (1082 PP) Amsterdam, the Netherlands, and is registered in the Commercial Register of Amsterdam under number 34334259.

Next Hyperledger Fabric Application Developer Community call (with revised agenda link) - this Thursday, 2nd April @ 3pm UTC time (4pm UK (+1), 11am ET (-5 hrs), 8am PT(-8 hrs)

Paul O'Mahoney <mahoney@...>

#7977

dear Fabric Application Developer,

the next Fabric Application Developer community call is scheduled for this Thursday 2nd April @ 3pm UTC - 4pm UK time (+1), 11am ET (-5 hrs), 8am PT(-8 hrs) - see time zones here. It lasts approx 30-60 mins FYI.

The agenda is here -> https://wiki.hyperledger.org/display/fabric/Agendas%3A+Fabric+Application+Developer+Community+Call+Meetings

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow (eg. developing applications, smart contracts, developing application clients, using the SDKs, tutorials/demos etc - NodeJS/TypeScript, Java, Go etc etc)
- helping App developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric.
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and
- approx length of your pitch in minutes

The Zoom webconference ID is https://zoom.us/my/hyperledger.community

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat: mahoney1
mahoney@...

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

Next Hyperledger Fabric Application Developer Community call - this Thursday, 2nd April @ 3pm UTC time (4pm UK (+1), 11am ET (-5 hrs), 8am PT(-8 hrs)

Paul O'Mahoney <mahoney@...>

#7976

dear Fabric Application Developer,

the next Fabric Application Developer community call is scheduled for this Thursday 2nd April @ 3pm UTC - 4pm UK time (+1), 11am ET (-5 hrs), 8am PT(-8 hrs) - see time zones here. It lasts approx 30-60 mins FYI.

The agenda will be posted here -> https://wiki.hyperledger.org/display/fabric/Meeting+Agendas%3A+Fabric+Application+Developer+Community+Call

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow (eg. developing applications, smart contracts, developing application clients, using the SDKs, tutorials/demos etc - NodeJS/TypeScript, Java, Go etc etc)
- helping App developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric.
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and
- approx length of your pitch in minutes

The Zoom webconference ID is https://zoom.us/my/hyperledger.community

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat: mahoney1
mahoney@...

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