Date   

Re: COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY #fabric-chaincode

Faisal
 

I can see how that is a problem when we are upgrading the chaincode (Hash might have changed due to the timestamp) but we tried installing and instantiating a chaincode with a different name first on the same channel and then on a different channel and even then we got the same Policy Violation error. 


Re: COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY #fabric-chaincode

Gari Singh <garis@...>
 

Looks like you were actually not persisting the storage for your peers (ledger, installed chaincode, etc).

It seems the orderer was still running so the channel already considered the chaincode to be instantiated.

I assume that when you started the peers, you installed the chaincode as well as joined the peer(s) to the channel.

The issue is likely that when you installed the chaincode on the "restarted" peer, the package that was built does not actually match the chaincode that was previously installed and instantiated.


please create repo

Christopher Ferris
 

Ry, per the approved Fabric RFC [1], please create the following repo


Thanks,

Chris


Re: Starting Fabric-CA without providing any root certificate #fabric-ca

shrugupt@...
 

Sorry for the delayed response!

Thank you Gari and Jean-Gaël. This is really helpful clearing my doubt!

On Thu, Oct 24, 2019 at 04:13 AM, Gari Singh wrote:
rtificate is actually not the same although the CN will always be the same unless you actually change it in the config.
You can run `fabric-ca-server init` to generate a default config and then edit the "csr" section of the config.


Proposal : Hyperledger Fabric block archiving

nekia <atsushin@...>
 

Hello everybody,

 

 

I’d like to propose a new feature ‘block archiving’ for Hyperledger Fabric. We are working on this block archiving project which is listed under Hyperledger Labs repository. Our current main efforts are focused on improvement of reliability. If we could get some feedback on our proposed feature from members involved in Hyperledger Fabric implementation, it’ll be quite useful for further improvement of UX.

 

- Hyperledger Fabric Block Archiving

    https://github.com/hyperledger-labs/fabric-block-archiving

 

    This enhancement for Hyperledger Fabric is aiming to:

 

        - Reduce the total amount of storage space required for an organisation to operate a Hyperledger Fabric network by archiving block data into repository.

        - For organisations, operate a Hyperledger Fabric network with low resourced nodes, such as a IoT edge devices for example.

 

- Our proposal

    https://github.com/hyperledger-labs/hyperledger-labs.github.io/blob/master/labs/fabric-block-archiving.md

 

- Technical overview

    https://github.com/nekia/fabric-block-archiving/blob/techoverview/BlockVault%20-%20Technical%20Overview.pdf

 

 

Kind regards,

Atsushi Neki

RocketChat:  nekia

 

Atsushi Neki
Senior Software Development Engineer

Fujitsu Australia Software Technology Pty Ltd

14 Rodborough Road, Frenchs Forest NSW 2086, Australia
T +61 2 9452 9036 M +61 428 223 387
AtsushiN@...
fastware.com.au


Disclaimer

The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.


Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.


If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@...


Documentation Workgroup: Agenda for Friday, 15 November

Anthony O'Dowd <a_o-dowd@...>
 

Hello All,

We hold our regular documentation workgroup call this week, both Eastern and Western hemispheres.

As is now usual, you can read the summary minutes for last week's call: https://wiki.hyperledger.org/display/fabric/2019+11+08+DWG+Agenda
and catch up via recordings page: https://wiki.hyperledger.org/display/fabric/Recordings

A particular last week was Nick Lincoln's walk through of the Performance website. Many thanks to Nick for a great session and the discussion that followed.

Please feel free to read, and contribute to, the agenda for this week: https://wiki.hyperledger.org/display/fabric/2019+11+15+DWG+Agenda
If you get a chance to review the MSP material from Pam, that would be very helpful too: https://gerrit.hyperledger.org/r/c/fabric/+/34174/

We've also added an outline agenda for next week's meeting : https://wiki.hyperledger.org/display/fabric/2019+11+22+DWG+Agenda

Again, feel free to add items.

Best regards,

Anthony, Pam, Joe, Nik

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Meeting 105A: Friday 14 Nov
                   1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time    

Meeting 105B: Friday 14 Nov
              1000 Central Daylight Time
                   1100 Eastern Daylight Time
                   0800 Pacific Daylight Time
                   1200 Brasil Standard Time
                   1600 Greenwich Mean Time
                   1700 Central European Time
                   1800 Moscow Standard Time


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Vipin Bharathan
 

Hello Ivan,
I have been following this thread for a while.
Thanks for raising some of these issues.
While it is important to question and to challenge the assumptions underlying Hyperledger Fabric, the best way to get attention, answers and influence the design may not be by using language like "Major Security hole...". This raises hackles and creates an atmosphere of defensiveness.

First- The issue you raised at first (the salted hash) may be just related to documentation according to all who debated this let us drop that from the list.
So that leaves:
1) hashes on chain cannot be validated by any third party, so they can be used by adversaries to trick honest participants (open)-
The design of private data collections, setup in effect "a covert channel" between the people who exchange that information. I use the term "covert channel" guardedly, before the cryptographers and crypto engineers among us object strenuously to that term. All those who need to know have access to methods to check the hash. Please re-examine this and re-read the private channel documentation. In terms of the veracity of the data (or the claim); this is a problem that has to be solved anyway-in any blockchain; through attestation by the party who put the data on the chain (in other words the issuers of the claim). There are many ways to share these "covert" claims  - Edge architectures with certain proof on the chain and so forth- a la Aries supported by Indy etc.

2) private data use gossip to transact data, which would require all participants be connected with any other participant part of a chain. if there are 20 participants in a channel, each participant must open up their firewalls to all other 19 participants of a single channel (open)

This may not be as it seems as gossip protocols can transmit information using connections to a limited number of "near peers". Overlay this with the three types of nodes (i.e. endorsing peers, validating peers and orderers- with Anchor peers being special types of peers that can serve as the "gateways" for endorsing and validating peers. As far as the orderers, I am not aware of the exact network that they participate in (i.e. is it gossip driven?). Also this interaction can be over TLS which is a widely used method today to protect communications over the open internet. I believe Fabric has this feature.

You have a point about firewalls, the disposition of the components in a regulated enterprise may need some design modifications to accommodate  firewalls. Since Firewalls, whether  on prem or in the cloud are not monolithic (include multiple layers like the DMZ etc.) currently use reverse proxies (for incoming messages) and Socks compliant protocols for outgoing. In Corda Enterprise, there is a component called the "Float" which functions as a reverse proxy. I was involved in conversations around the design of this component, when I was working in a regulated financial institution. I do not know the status of "the float" since that is available only in Enterprise Corda. There are also multiple architectural patterns written up on the provisioning of the components inside firewalls. We need that thought process in fabric if it does not exist.

Another feature that is demanded by IT architecture and security teams in Enterprise are the componentization of nodes. By that I mean the breaking up of (say) any endorsing or validating peer into data access and smart contact execution layers with the possibility of scaling and housing in various parts of the enterprise stack.

All this points to having community involvement in Architecture best practices for projects and the presence and participation in such exercises so that the Fabric team can take advantage of expertise such as yours that exist in the open source community.

We must collaborate, otherwise why be in an open source consortium?

Best,
Vipin

On Wed, Nov 13, 2019 at 10:09 PM Ivan Ch <acizlan@...> wrote:
Hi Yacov

again you are bypassing the question, to be honest I am quiet frustrated now.

the community is not about defending a stance but to find a solution to on going problems, and if something is wrong (which happens frequently in any open source project) we may need to discuss and consider another approach. the current questions about private data listed from various people are listed here:

Security issues
1) hashes put on chain don't have salt added to it, which is vulnerable to dictionary attack (solved)

Methodology issues
1) hashes on chain cannot be validated by any third party, so they can be used by adversaries to trick honest participants (open)
2) private data use gossip to transact data, which would require all participants be connected with any other participant part of a chain. if there are 20 participants in a channel, each participant must open up their firewalls to all other 19 participants of a single channel (open)

Engineering issues:
1) when using k8s and behind load-balancers or proxies, users do not even get a chance to use a shared port (in the aforementioned example, each participant can't even open firewalls to 19 other participants without extensive hacking, and I assumed all participants need to deployed these hacked code to make it work. (discussed)


Hyperledger Fabric Application Developer Community call - today's call is cancelled - the next is Thursday Nov 28th

Paul O'Mahoney <mahoney@...>
 

hi folks,

please note that today's Fabric Application Developer Community call is cancelled -  the content and presenters I had lined up deemed it better to wait for the next call,  to show/demonstrate a more complete story for the topics being presented.

therefore,  the next scheduled FADC call  is  Thursday Nov 28th @ 4pm UTC (4pm UK) - 11am ET (-5), 8am PT(-8)  see time zones.

if you have any questions or issues, please let me know


best regards
Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1

mahoney@...
----- Forwarded by Paul O'Mahoney/UK/IBM on 14/11/2019 10:47 -----

From:        Paul O'Mahoney/UK/IBM
To:        Paul O'Mahoney/UK/IBM@IBMGB
Date:        11/11/2019 11:31
Subject:        Next Hyperledger Fabric Application Developer Community call - Thursday Nov 14th @ 4pm UTC (4pm UK) - 11am ET (-5 hrs), 8am PT(-8 hrs)  



dear Fabric Application Developer,


the next  Fabric Application Developer community call is scheduled for this  Thursday Nov 14th @ 4pm UTC (4pm UK) - 11am ET (-5), 8am PT(-8) - see time zones.   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 in their development journey (eg. developing applications, smart contracts,  developing application clients, using the SDKs, tutorials/demos etc - eg. spanning 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
- to 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


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Ivan Ch <acizlan@...>
 

Hi Yacov

again you are bypassing the question, to be honest I am quiet frustrated now.

the community is not about defending a stance but to find a solution to on going problems, and if something is wrong (which happens frequently in any open source project) we may need to discuss and consider another approach. the current questions about private data listed from various people are listed here:

Security issues
1) hashes put on chain don't have salt added to it, which is vulnerable to dictionary attack (solved)

Methodology issues
1) hashes on chain cannot be validated by any third party, so they can be used by adversaries to trick honest participants (open)
2) private data use gossip to transact data, which would require all participants be connected with any other participant part of a chain. if there are 20 participants in a channel, each participant must open up their firewalls to all other 19 participants of a single channel (open)

Engineering issues:
1) when using k8s and behind load-balancers or proxies, users do not even get a chance to use a shared port (in the aforementioned example, each participant can't even open firewalls to 19 other participants without extensive hacking, and I assumed all participants need to deployed these hacked code to make it work. (discussed)


fabric-rfcs

David Enyeart
 

We have a new fabric-rfcs repository that will be used for new proposals and major enhancements to Fabric and related repositories. Read all about the rfc process in the README at: https://github.com/hyperledger/fabric-rfcs/

Thanks to Chris Ferris and our colleagues working on Sawtooth for helping to put together a consistent Hyperledger process that will improve the visibility and tracking of new open source proposals.


Dave Enyeart


s390x release artifacts

David Enyeart
 

As discussed on the contributor meeting today... we are shifting Fabric from Jenkins to Azure Pipelines for our CI and release processes. Since Azure Pipelines does not support s390x environments, we will no longer be able to publish s390x release binaries and docker images, starting with release v1.4.4. Those interested in s390x binaries and images will still be able to build on their own from the tagged release code.

Thanks,

Dave Enyeart


Re: Updated Go chaincode to the new programming model (contract API) #fabric #fabric-chaincode

David Enyeart
 

Thanks Andrew! As always, the recording can be found at:
https://wiki.hyperledger.org/display/fabric/Contributor+Meetings


Dave Enyeart

andrew.hurt1---11/13/2019 05:37:48 AM---Hello, On today's contributors call I will be discussing the design for the updated programming mode

From: andrew.hurt1@...
To: fabric@...
Date: 11/13/2019 05:37 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Updated Go chaincode to the new programming model (contract API) #fabric #fabric-chaincode
Sent by: fabric@...





Hello,

On today's contributors call I will be discussing the design for the updated programming model for Go chaincode in Fabric.

Attached are the slides that will be run through which explain the approach for Go in comparison to the already delivered contract API in Node and Java chaincodes.





Updated Go chaincode to the new programming model (contract API) #fabric #fabric-chaincode

andrew.hurt1@...
 

Hello,

On today's contributors call I will be discussing the design for the updated programming model for Go chaincode in Fabric.

Attached are the slides that will be run through which explain the approach for Go in comparison to the already delivered contract API in Node and Java chaincodes.


Interested in adding csharp support - guidelines needed

Segments
 

Hello,

I am interested in adding csharp support to Fabric and bringing it on par with Java or even Go support. I want to add chaincode support and client.

Could someone please help me find my way and provide me a high-level list of what I'll need to do and where I'll need to look into. I do not have much experience with Fabric but I've read the docs extensively so I am familiar with the concepts. I also have a basic background in blockchain programming.

This undertaking (which is a prerequisite for us to be able to work with Fabric), will also allow me to get familiar with it in depth in a productive way.

Thank you,

Segments


Sent with ProtonMail Secure Email.


Re: Creation of channel in basic-network is broken after fixing warning "Omitting the channel ID for configtxgen for output operations is deprecated. ..."

Jason Yellick <jyellick@...>
 

There are two channels in this example.  The orderer system channel (historically called "testchainid" when the ID is omitted), and "mychannel" (the channel specified by "$CHANNEL_NAME".).  In order to make this work, you would need to pick a unique name for each.  Note, you should look for other hardcoding of 'testchainid' if you are modifying the orderer system channel name or you will likely see other failures.
 

----- Original message -----
From: "D0nAnd0n" <d0nand0n@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Creation of channel in basic-network is broken after fixing warning "Omitting the channel ID for configtxgen for output operations is deprecated. ..."
Date: Mon, Nov 11, 2019 11:21 AM
 
Hi,

I'm playing around with fabric-samples v1.4.3:
/HyperLedger/fabric-samples$ git status | head -n 1
HEAD detached at v1.4.3
$

and

/HyperLedger/fabric-samples$ git log | head -n 5
commit f86ec95726cdb9d015b0ca1d4d95d583050fa6b4
Author: Varun Agarwal <varunagarwal315@...>
Date:   Sun Aug 25 14:19:02 2019 +0530

     [FAB-16390] Added filter for invalid transactions
/HyperLedger/fabric-samples$


When I run basic-network/generate.sh I get following output:
<BEGIN>
/HyperLedger/fabric-samples/basic-network$ ./generate.sh
org1.example.com
2019-11-11 16:25:06.858 CET [common.tools.configtxgen] main -> WARN 001
Omitting the channel ID for configtxgen for output operations is
deprecated.  Explicitly passing the channel ID will be required in the
future, defaulting to 'testchainid'.
2019-11-11 16:25:06.858 CET [common.tools.configtxgen] main -> INFO 002
Loading configuration
2019-11-11 16:25:06.863 CET [common.tools.configtxgen.localconfig]
completeInitialization -> INFO 003 orderer type: solo
2019-11-11 16:25:06.863 CET [common.tools.configtxgen.localconfig] Load
-> INFO 004 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:06.867 CET [common.tools.configtxgen.localconfig]
completeInitialization -> INFO 005 orderer type: solo
2019-11-11 16:25:06.867 CET [common.tools.configtxgen.localconfig]
LoadTopLevel -> INFO 006 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:06.867 CET [common.tools.configtxgen.encoder]
NewChannelGroup -> WARN 007 Default policy emission is deprecated,
please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:25:06.867 CET [common.tools.configtxgen.encoder]
NewOrdererGroup -> WARN 008 Default policy emission is deprecated,
please include policy specifications for the orderer group in configtx.yaml
2019-11-11 16:25:06.870 CET [common.tools.configtxgen.encoder]
NewOrdererOrgGroup -> WARN 009 Default policy emission is deprecated,
please include policy specifications for the orderer org group
OrdererOrg in configtx.yaml
2019-11-11 16:25:06.872 CET [common.tools.configtxgen.encoder]
NewConsortiumOrgGroup -> WARN 00a Default policy emission is deprecated,
please include policy specifications for the orderer org group Org1MSP
in configtx.yaml
2019-11-11 16:25:06.872 CET [common.tools.configtxgen] doOutputBlock ->
INFO 00b Generating genesis block
2019-11-11 16:25:06.877 CET [common.tools.configtxgen] doOutputBlock ->
INFO 00c Writing genesis block
2019-11-11 16:25:06.999 CET [common.tools.configtxgen] main -> INFO 001
Loading configuration
2019-11-11 16:25:07.003 CET [common.tools.configtxgen.localconfig] Load
-> INFO 002 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:07.006 CET [common.tools.configtxgen.localconfig]
completeInitialization -> INFO 003 orderer type: solo
2019-11-11 16:25:07.006 CET [common.tools.configtxgen.localconfig]
LoadTopLevel -> INFO 004 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:07.006 CET [common.tools.configtxgen]
doOutputChannelCreateTx -> INFO 005 Generating new channel configtx
2019-11-11 16:25:07.006 CET [common.tools.configtxgen.encoder]
NewChannelGroup -> WARN 006 Default policy emission is deprecated,
please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:25:07.006 CET [common.tools.configtxgen.encoder]
NewApplicationGroup -> WARN 007 Default policy emission is deprecated,
please include policy specifications for the application group in
configtx.yaml
2019-11-11 16:25:07.010 CET [common.tools.configtxgen.encoder]
NewApplicationOrgGroup -> WARN 008 Default policy emission is
deprecated, please include policy specifications for the application org
group Org1MSP in configtx.yaml
2019-11-11 16:25:07.010 CET [common.tools.configtxgen.encoder]
NewChannelGroup -> WARN 009 Default policy emission is deprecated,
please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:25:07.010 CET [common.tools.configtxgen.encoder]
NewApplicationGroup -> WARN 00a Default policy emission is deprecated,
please include policy specifications for the application group in
configtx.yaml
2019-11-11 16:25:07.014 CET [common.tools.configtxgen.encoder]
NewApplicationOrgGroup -> WARN 00b Default policy emission is
deprecated, please include policy specifications for the application org
group Org1MSP in configtx.yaml
2019-11-11 16:25:07.014 CET [common.tools.configtxgen]
doOutputChannelCreateTx -> INFO 00c Writing new channel tx
2019-11-11 16:25:07.146 CET [common.tools.configtxgen] main -> INFO 001
Loading configuration
2019-11-11 16:25:07.151 CET [common.tools.configtxgen.localconfig] Load
-> INFO 002 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:07.153 CET [common.tools.configtxgen.localconfig]
completeInitialization -> INFO 003 orderer type: solo
2019-11-11 16:25:07.153 CET [common.tools.configtxgen.localconfig]
LoadTopLevel -> INFO 004 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:07.153 CET [common.tools.configtxgen]
doOutputAnchorPeersUpdate -> INFO 005 Generating anchor peer update
2019-11-11 16:25:07.154 CET [common.tools.configtxgen]
doOutputAnchorPeersUpdate -> INFO 006 Writing anchor peer update
HyperLedger/fabric-samples/basic-network$
<END>


Then I run basic-network/start.sh without errors, docker containers are
started and channel is created and joined.


Then I try to fix the first warning from generate.sh
"WARN 001 Omitting the channel ID for configtxgen for output operations
is deprecated.  Explicitly passing the channel ID will be required in
the future, defaulting to 'testchainid'."
adding "-channelID $CHANNEL_NAME" to line 23 of generate.sh:
configtxgen -profile OneOrgOrdererGenesis -outputBlock
./config/genesis.block -channelID $CHANNEL_NAME

When I run basic-network/generate.sh with this fix, "WARN 001 Omitting
..." disappears as expected:
<BEGIN>
/HyperLedger/fabric-samples/basic-network$ ./generate.sh
org1.example.com
2019-11-11 16:30:26.749 CET [common.tools.configtxgen] main -> INFO 001
Loading configuration
2019-11-11 16:30:26.752 CET [common.tools.configtxgen.localconfig]
completeInitialization -> INFO 002 orderer type: solo
2019-11-11 16:30:26.753 CET [common.tools.configtxgen.localconfig] Load
-> INFO 003 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:26.755 CET [common.tools.configtxgen.localconfig]
completeInitialization -> INFO 004 orderer type: solo
2019-11-11 16:30:26.755 CET [common.tools.configtxgen.localconfig]
LoadTopLevel -> INFO 005 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:26.755 CET [common.tools.configtxgen.encoder]
NewChannelGroup -> WARN 006 Default policy emission is deprecated,
please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:30:26.755 CET [common.tools.configtxgen.encoder]
NewOrdererGroup -> WARN 007 Default policy emission is deprecated,
please include policy specifications for the orderer group in configtx.yaml
2019-11-11 16:30:26.758 CET [common.tools.configtxgen.encoder]
NewOrdererOrgGroup -> WARN 008 Default policy emission is deprecated,
please include policy specifications for the orderer org group
OrdererOrg in configtx.yaml
2019-11-11 16:30:26.760 CET [common.tools.configtxgen.encoder]
NewConsortiumOrgGroup -> WARN 009 Default policy emission is deprecated,
please include policy specifications for the orderer org group Org1MSP
in configtx.yaml
2019-11-11 16:30:26.760 CET [common.tools.configtxgen] doOutputBlock ->
INFO 00a Generating genesis block
2019-11-11 16:30:26.761 CET [common.tools.configtxgen] doOutputBlock ->
INFO 00b Writing genesis block
2019-11-11 16:30:26.882 CET [common.tools.configtxgen] main -> INFO 001
Loading configuration
2019-11-11 16:30:26.887 CET [common.tools.configtxgen.localconfig] Load
-> INFO 002 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:26.890 CET [common.tools.configtxgen.localconfig]
completeInitialization -> INFO 003 orderer type: solo
2019-11-11 16:30:26.890 CET [common.tools.configtxgen.localconfig]
LoadTopLevel -> INFO 004 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:26.890 CET [common.tools.configtxgen]
doOutputChannelCreateTx -> INFO 005 Generating new channel configtx
2019-11-11 16:30:26.890 CET [common.tools.configtxgen.encoder]
NewChannelGroup -> WARN 006 Default policy emission is deprecated,
please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:30:26.890 CET [common.tools.configtxgen.encoder]
NewApplicationGroup -> WARN 007 Default policy emission is deprecated,
please include policy specifications for the application group in
configtx.yaml
2019-11-11 16:30:26.892 CET [common.tools.configtxgen.encoder]
NewApplicationOrgGroup -> WARN 008 Default policy emission is
deprecated, please include policy specifications for the application org
group Org1MSP in configtx.yaml
2019-11-11 16:30:26.892 CET [common.tools.configtxgen.encoder]
NewChannelGroup -> WARN 009 Default policy emission is deprecated,
please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:30:26.892 CET [common.tools.configtxgen.encoder]
NewApplicationGroup -> WARN 00a Default policy emission is deprecated,
please include policy specifications for the application group in
configtx.yaml
2019-11-11 16:30:26.894 CET [common.tools.configtxgen.encoder]
NewApplicationOrgGroup -> WARN 00b Default policy emission is
deprecated, please include policy specifications for the application org
group Org1MSP in configtx.yaml
2019-11-11 16:30:26.894 CET [common.tools.configtxgen]
doOutputChannelCreateTx -> INFO 00c Writing new channel tx
2019-11-11 16:30:27.010 CET [common.tools.configtxgen] main -> INFO 001
Loading configuration
2019-11-11 16:30:27.016 CET [common.tools.configtxgen.localconfig] Load
-> INFO 002 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:27.020 CET [common.tools.configtxgen.localconfig]
completeInitialization -> INFO 003 orderer type: solo
2019-11-11 16:30:27.020 CET [common.tools.configtxgen.localconfig]
LoadTopLevel -> INFO 004 Loaded configuration:
/HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:27.020 CET [common.tools.configtxgen]
doOutputAnchorPeersUpdate -> INFO 005 Generating anchor peer update
2019-11-11 16:30:27.021 CET [common.tools.configtxgen]
doOutputAnchorPeersUpdate -> INFO 006 Writing anchor peer update
/HyperLedger/fabric-samples/basic-network$
<END>

So far so good. When run basic-network/start.sh, it crashes:
<BEGIN>
/HyperLedger/fabric-samples/basic-network$ ./start.sh
...
... Docker containers are started without problems ...
...

# Create the channel
docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e
"CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/users/Admin@.../msp"
peer0.org1.example.com peer channel create -o orderer.example.com:7050
-c mychannel -f /etc/hyperledger/configtx/channel.tx
2019-11-11 16:02:31.978 UTC [channelCmd] InitCmdFactory -> INFO 001
Endorser and orderer connections initialized
Error: got unexpected status: FORBIDDEN -- implicit policy evaluation
failed - 0 sub-policies were satisfied, but this policy requires 1 of
the 'Writers' sub-policies to be satisfied: permission denied
/HyperLedger/fabric-samples/basic-network$
<END>

Channel cannot be created because of unsatisfied policy. Again, the only
difference to the case, where everything is fine, is added "-channelID
$CHANNEL_NAME" to line 23 of basic-network/generate.sh. There are not
changes at the policies at all.

What is going here wrong?

Regards

D0nAnd0n




 
 


Re: Event Consumers and ACLs #fabric

aramachandran@...
 

Hi All,

Are there any solution to what Mr Robert Broeckelmann's Problem. I am currently working on a project that has a similar his as we too are looking at ways to restrict access to certain events to sub set of organizations peers.  Any leads on this will be helpful.

Thanks in advance 
Aravind


Creation of channel in basic-network is broken after fixing warning "Omitting the channel ID for configtxgen for output operations is deprecated. ..."

D0nAnd0n
 

Hi,

I'm playing around with fabric-samples v1.4.3:
/HyperLedger/fabric-samples$ git status | head -n 1
HEAD detached at v1.4.3
$

and

/HyperLedger/fabric-samples$ git log | head -n 5
commit f86ec95726cdb9d015b0ca1d4d95d583050fa6b4
Author: Varun Agarwal <varunagarwal315@...>
Date: Sun Aug 25 14:19:02 2019 +0530

[FAB-16390] Added filter for invalid transactions
/HyperLedger/fabric-samples$


When I run basic-network/generate.sh I get following output:
<BEGIN>
/HyperLedger/fabric-samples/basic-network$ ./generate.sh
org1.example.com
2019-11-11 16:25:06.858 CET [common.tools.configtxgen] main -> WARN 001 Omitting the channel ID for configtxgen for output operations is deprecated. Explicitly passing the channel ID will be required in the future, defaulting to 'testchainid'.
2019-11-11 16:25:06.858 CET [common.tools.configtxgen] main -> INFO 002 Loading configuration
2019-11-11 16:25:06.863 CET [common.tools.configtxgen.localconfig] completeInitialization -> INFO 003 orderer type: solo
2019-11-11 16:25:06.863 CET [common.tools.configtxgen.localconfig] Load -> INFO 004 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:06.867 CET [common.tools.configtxgen.localconfig] completeInitialization -> INFO 005 orderer type: solo
2019-11-11 16:25:06.867 CET [common.tools.configtxgen.localconfig] LoadTopLevel -> INFO 006 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:06.867 CET [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 007 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:25:06.867 CET [common.tools.configtxgen.encoder] NewOrdererGroup -> WARN 008 Default policy emission is deprecated, please include policy specifications for the orderer group in configtx.yaml
2019-11-11 16:25:06.870 CET [common.tools.configtxgen.encoder] NewOrdererOrgGroup -> WARN 009 Default policy emission is deprecated, please include policy specifications for the orderer org group OrdererOrg in configtx.yaml
2019-11-11 16:25:06.872 CET [common.tools.configtxgen.encoder] NewConsortiumOrgGroup -> WARN 00a Default policy emission is deprecated, please include policy specifications for the orderer org group Org1MSP in configtx.yaml
2019-11-11 16:25:06.872 CET [common.tools.configtxgen] doOutputBlock -> INFO 00b Generating genesis block
2019-11-11 16:25:06.877 CET [common.tools.configtxgen] doOutputBlock -> INFO 00c Writing genesis block
2019-11-11 16:25:06.999 CET [common.tools.configtxgen] main -> INFO 001 Loading configuration
2019-11-11 16:25:07.003 CET [common.tools.configtxgen.localconfig] Load -> INFO 002 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:07.006 CET [common.tools.configtxgen.localconfig] completeInitialization -> INFO 003 orderer type: solo
2019-11-11 16:25:07.006 CET [common.tools.configtxgen.localconfig] LoadTopLevel -> INFO 004 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:07.006 CET [common.tools.configtxgen] doOutputChannelCreateTx -> INFO 005 Generating new channel configtx
2019-11-11 16:25:07.006 CET [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 006 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:25:07.006 CET [common.tools.configtxgen.encoder] NewApplicationGroup -> WARN 007 Default policy emission is deprecated, please include policy specifications for the application group in configtx.yaml
2019-11-11 16:25:07.010 CET [common.tools.configtxgen.encoder] NewApplicationOrgGroup -> WARN 008 Default policy emission is deprecated, please include policy specifications for the application org group Org1MSP in configtx.yaml
2019-11-11 16:25:07.010 CET [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 009 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:25:07.010 CET [common.tools.configtxgen.encoder] NewApplicationGroup -> WARN 00a Default policy emission is deprecated, please include policy specifications for the application group in configtx.yaml
2019-11-11 16:25:07.014 CET [common.tools.configtxgen.encoder] NewApplicationOrgGroup -> WARN 00b Default policy emission is deprecated, please include policy specifications for the application org group Org1MSP in configtx.yaml
2019-11-11 16:25:07.014 CET [common.tools.configtxgen] doOutputChannelCreateTx -> INFO 00c Writing new channel tx
2019-11-11 16:25:07.146 CET [common.tools.configtxgen] main -> INFO 001 Loading configuration
2019-11-11 16:25:07.151 CET [common.tools.configtxgen.localconfig] Load -> INFO 002 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:07.153 CET [common.tools.configtxgen.localconfig] completeInitialization -> INFO 003 orderer type: solo
2019-11-11 16:25:07.153 CET [common.tools.configtxgen.localconfig] LoadTopLevel -> INFO 004 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:25:07.153 CET [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 005 Generating anchor peer update
2019-11-11 16:25:07.154 CET [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 006 Writing anchor peer update
HyperLedger/fabric-samples/basic-network$
<END>


Then I run basic-network/start.sh without errors, docker containers are started and channel is created and joined.


Then I try to fix the first warning from generate.sh
"WARN 001 Omitting the channel ID for configtxgen for output operations is deprecated. Explicitly passing the channel ID will be required in the future, defaulting to 'testchainid'."
adding "-channelID $CHANNEL_NAME" to line 23 of generate.sh:
configtxgen -profile OneOrgOrdererGenesis -outputBlock ./config/genesis.block -channelID $CHANNEL_NAME

When I run basic-network/generate.sh with this fix, "WARN 001 Omitting ..." disappears as expected:
<BEGIN>
/HyperLedger/fabric-samples/basic-network$ ./generate.sh
org1.example.com
2019-11-11 16:30:26.749 CET [common.tools.configtxgen] main -> INFO 001 Loading configuration
2019-11-11 16:30:26.752 CET [common.tools.configtxgen.localconfig] completeInitialization -> INFO 002 orderer type: solo
2019-11-11 16:30:26.753 CET [common.tools.configtxgen.localconfig] Load -> INFO 003 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:26.755 CET [common.tools.configtxgen.localconfig] completeInitialization -> INFO 004 orderer type: solo
2019-11-11 16:30:26.755 CET [common.tools.configtxgen.localconfig] LoadTopLevel -> INFO 005 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:26.755 CET [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 006 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:30:26.755 CET [common.tools.configtxgen.encoder] NewOrdererGroup -> WARN 007 Default policy emission is deprecated, please include policy specifications for the orderer group in configtx.yaml
2019-11-11 16:30:26.758 CET [common.tools.configtxgen.encoder] NewOrdererOrgGroup -> WARN 008 Default policy emission is deprecated, please include policy specifications for the orderer org group OrdererOrg in configtx.yaml
2019-11-11 16:30:26.760 CET [common.tools.configtxgen.encoder] NewConsortiumOrgGroup -> WARN 009 Default policy emission is deprecated, please include policy specifications for the orderer org group Org1MSP in configtx.yaml
2019-11-11 16:30:26.760 CET [common.tools.configtxgen] doOutputBlock -> INFO 00a Generating genesis block
2019-11-11 16:30:26.761 CET [common.tools.configtxgen] doOutputBlock -> INFO 00b Writing genesis block
2019-11-11 16:30:26.882 CET [common.tools.configtxgen] main -> INFO 001 Loading configuration
2019-11-11 16:30:26.887 CET [common.tools.configtxgen.localconfig] Load -> INFO 002 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:26.890 CET [common.tools.configtxgen.localconfig] completeInitialization -> INFO 003 orderer type: solo
2019-11-11 16:30:26.890 CET [common.tools.configtxgen.localconfig] LoadTopLevel -> INFO 004 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:26.890 CET [common.tools.configtxgen] doOutputChannelCreateTx -> INFO 005 Generating new channel configtx
2019-11-11 16:30:26.890 CET [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 006 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:30:26.890 CET [common.tools.configtxgen.encoder] NewApplicationGroup -> WARN 007 Default policy emission is deprecated, please include policy specifications for the application group in configtx.yaml
2019-11-11 16:30:26.892 CET [common.tools.configtxgen.encoder] NewApplicationOrgGroup -> WARN 008 Default policy emission is deprecated, please include policy specifications for the application org group Org1MSP in configtx.yaml
2019-11-11 16:30:26.892 CET [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 009 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml
2019-11-11 16:30:26.892 CET [common.tools.configtxgen.encoder] NewApplicationGroup -> WARN 00a Default policy emission is deprecated, please include policy specifications for the application group in configtx.yaml
2019-11-11 16:30:26.894 CET [common.tools.configtxgen.encoder] NewApplicationOrgGroup -> WARN 00b Default policy emission is deprecated, please include policy specifications for the application org group Org1MSP in configtx.yaml
2019-11-11 16:30:26.894 CET [common.tools.configtxgen] doOutputChannelCreateTx -> INFO 00c Writing new channel tx
2019-11-11 16:30:27.010 CET [common.tools.configtxgen] main -> INFO 001 Loading configuration
2019-11-11 16:30:27.016 CET [common.tools.configtxgen.localconfig] Load -> INFO 002 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:27.020 CET [common.tools.configtxgen.localconfig] completeInitialization -> INFO 003 orderer type: solo
2019-11-11 16:30:27.020 CET [common.tools.configtxgen.localconfig] LoadTopLevel -> INFO 004 Loaded configuration: /HyperLedger/fabric-samples/basic-network/configtx.yaml
2019-11-11 16:30:27.020 CET [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 005 Generating anchor peer update
2019-11-11 16:30:27.021 CET [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 006 Writing anchor peer update
/HyperLedger/fabric-samples/basic-network$
<END>

So far so good. When run basic-network/start.sh, it crashes:
<BEGIN>
/HyperLedger/fabric-samples/basic-network$ ./start.sh
...
... Docker containers are started without problems ...
...

# Create the channel
docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/users/Admin@.../msp" peer0.org1.example.com peer channel create -o orderer.example.com:7050 -c mychannel -f /etc/hyperledger/configtx/channel.tx
2019-11-11 16:02:31.978 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
Error: got unexpected status: FORBIDDEN -- implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied: permission denied
/HyperLedger/fabric-samples/basic-network$
<END>

Channel cannot be created because of unsatisfied policy. Again, the only difference to the case, where everything is fine, is added "-channelID $CHANNEL_NAME" to line 23 of basic-network/generate.sh. There are not changes at the policies at all.

What is going here wrong?

Regards

D0nAnd0n


Re: Wrong world state #fabric #fabric-questions

Tong Li
 

Joan,
This is really interesting problem. I wonder if you can share the things that you did to the network and the timing etc, so others who are also interested in the problem can try to do similar things to watch the behavior.

Thanks.

Tong Li
IBM Open Technology

"Joao Antunes" ---11/09/2019 11:37:48 AM---Thank you for reaching out again Dave, In my case, for some unknown reason, I had 1 good world state

From: "Joao Antunes" <joao.antunes@...>
To: fabric@...
Date: 11/09/2019 11:37 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Wrong world state #fabric #fabric-questions
Sent by: fabric@...





Thank you for reaching out again Dave,

In my case, for some unknown reason, I had 1 good world state and 3 bad world state. After updating fabric image on peers and resetting all peers, the world state got coherent with the ledger. So from my analysis, world state was wrong, but the ledger was correct.
I had 3 wrong peers and 1 correct, but even then I was not able to change anything due to my queries readset. One of the readsets was different so, no actions were possible.
How this happened I don't know. I know that these entities originated from a single huge transaction (10K new entities created) but the ownership of some of them (3 or 4) were not coherent in the peers. Even after deleting the CouchDB database from the peer, it still recovered but with wrong data. Only resetting the peer solved the issue.

I'll investigate more and if possible I'll provide more data to this thread and if that's the case a Jira issue





Next Hyperledger Fabric Application Developer Community call - Thursday Nov 14th @ 4pm UTC (4pm UK) - 11am ET (-5 hrs), 8am PT(-8 hrs)

Paul O'Mahoney <mahoney@...>
 

dear Fabric Application Developer,


the next  Fabric Application Developer community call is scheduled for this  Thursday Nov 14th @ 4pm UTC (4pm UK) - 11am ET (-5), 8am PT(-8) - see time zones.   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 in their development journey (eg. developing applications, smart contracts,  developing application clients, using the SDKs, tutorials/demos etc - eg. spanning 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
- to 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


Re: Hyperledger Fabric Scalability

Vipin Bharathan
 

Hi all,
Fascinating thread. All excellent suggestions from Brian/Chris.
However, invariably the question pops up about the number of replicas or shall I say peers.
Are there documented and public cases of the number of peers in real use cases and attendant tps etc? Which Chris says below  " might only be tens or hundreds of organization nodes operating peers". This question comes up when we try to persuade enterprises to look at adoption of Fabric. Proper application architecture is important like what Brian/Chris says
  • What to put on the ledger (level of granularity and content for IoT or other data and their rates)?
  • Who needs to run peers?
  • Using channels
Even given all these best practices, given sufficiently large ecosystems; it may be necessary to run larger numbers of decentralized orderers, endorsers, validators etc.

To compare there are about 10,000 nodes on Bitcoin, around the same in Ethereum(?), Libra gave an estimate of 8,000 or so nodes in a study about their consensus algorithm. I understand that these are very different applications. Public, payment systems with vastly more participation and engagement.

It is important for us to come up some of these numbers for one of the most successful Enterprise Blockchains (Fabric) so far.

The Performance and Scale working group/Caliper will also lend these numbers a level of objectivity.
Best,
Vipin

On Sat, Nov 9, 2019 at 8:30 AM Christopher Ferris <chris.ferris@...> wrote:
Indeed, I think there's often confusion about network topology when it comes to "organizations". To be clear, there are 3 types of users,
orgs that operate ordering nodes, orgs that operate peer nodes and end users of the system/application who likely do not operate more than
just an application leveraging one of the SDKs. As for orgs that operate peer nodes, these could be distinguished between those who
are operating an endorsing node, and those merely operating a validating/committing node. The former need to be able to operate the chaincode
the latter do not, they just maintain a copy of the ledger.

In a system with thousands or more users, there might only be tens or hundreds of organization nodes operating peers. Think of it
using the banking example. The banks may create a consortium network and Bank America, TD Bank, Wells Fargo, Sovereign Bank each
operate peer nodes that are both endorsing and validating. Maybe they also operate ordering nodes. Then, all the TD bank account
holders would have identities affiliated with TD Bank, and all the Bank America account holders similarly have identities affiliated with
Bank America, etc. The account holders don't operate nodes, they simply interact with the system from their mobile or web application.

The channels might be bilateral between the banks, and transactions that exchanged funds from one bank to another would be
processed over those bilateral channels. Otherwise, there would be a channel per bank against which account holders would process
their individual transactions. The chaincode would leverage access controls that ensured that the account holder, or an authorized
entity could process transactions against their account.

As for future blog posts, I plan to publish updates once we have 2.0 images published. I'll share the blog links here.

Chris

On Sat, Nov 9, 2019 at 1:00 AM Brian Behlendorf <bbehlendorf@...> wrote:
The blog posts are the right place to start your exploration of the issues, but you can't go much further without testing it yourselves.

You should be apprehensive about depending upon any blockchain for high TPS and high numbers of nodes at the same time. Proper blockchain engineering at this point will be about finding ways to store the least amount of data on chain, with the least number of required TPS, as possible. Do not confuse Fabric or any other blockchain to be a high performance big data management tool. If anything, it's about "small data" that happens to be trust-critical.

As I understand your use case, in my opinion, you should not be storing all sensor data and transaction history directly on ledger; store that in large files chunked by time and gas station network, share those offledger (encrypted S3 buckets ate cheap and global, or IPFS), and use Fabric for storing hashes that can attest to the timing, provenance, metadata and integrity of that off-ledger data.

You also shouldn't try to have every gas station be a node in the network - I presume they are already part of a chain of gas stations, and within a chain there is already the trust of a single corporation, so the corp office itself should run nodes on behalf of its stations. It doesn't sound like you need prevention of double spend; I'm not even sure why you need smart contracts (you mean chaincode?) to "monitor fuel levels".

If scale is your number one goal, constantly look for ways to reduce the frequency and amount to write to the blockchain. (Reads, of course, are cheap and easy to scale).

Brian

On 9 November 2019 10:47:52 AM GMT+08:00, alok gupta <metech11@...> wrote:
Hello Mark & Christopher,

Thanks for your reply. I have gone through the blog but I am still apprehensive whether we would be able to support hundreds or thousands of organisations? We did TPS optimisation after struggling a bit with MVCC error, our solution is running fine for a single fuel station. Right now there are max 50 tps.  But not sure how to take this forward. What should be our approach?  Please advise.



On Sat, 9 Nov 2019, 07:59 Mark Rakhmilevich, <mark.rakhmilevich@...> wrote:

Alok,

    We have seen throughput in high hundreds of TPS to low thousands of TPS in Oracle projects.  The scalability and performance depend on many factors well explained in Chris’ blog posts.  Certainly transaction payload size, batching parameters in the ordering service, number of channels an ordering cluster has to support given certain network bandwidth play a significant role. There are also techniques to batch transaction data, which are useful, for example,  to capture an audit log from many IOT sensor readings. Feel free to reach out directly to discuss specifics.

 

Best Regards,

    Mark

 

From: Christopher Ferris <chris.ferris@...>
Sent: Wednesday, November 06, 2019 3:33 AM
To: alok gupta <metech11@...>
Cc: fabric@...
Subject: Re: [Hyperledger Fabric] Hyperledger Fabric Scalability

 

Alok,

 

I wrote a couple of blog posts earlier this year on Hyperledger Fabric performance and scale.

 

There have been some more recent improvements that should improve performance even more when 2.0 ships.

I'll have another post up with those results. There are some additional efforts in the community where performance

has been pushed even further.

 

Hope this helps.

 

Chris

 

On Wed, Nov 6, 2019 at 3:36 AM alok gupta <metech11@...> wrote:

Hello There,

We are conducting a POC for Oil & GAS Retail automation. In which, we are recording all digital/ cash sales onto the Fabric ledger. We monitor the stock levels in the fuel tanks through smart contract. The idea is to replace the current automation system in India which requires massive investment in installation and maintenance. Our app is running successfully on a fuel station at a fuel station in Chandigarh, India. 

My query is about the scalability of fabric over no. of channel, organizations, and peers. Can we scale up our solution to connect the fuel companies ( IOCL. HPCL etc.) with India wide fuel stations? I have seen other use cases like Wallmart food safety where there are running a huge network on blockchain. To move forward in our idea, we need a clarity on scalability Please advise.

Thank you
Alok


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.