|
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!
toggle quoted messageShow quoted text
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.
|
|
|
|
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 DisclaimerThe 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
|
|
|
|
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) 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 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/
|
|
|
|
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.
|
|
|
|
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: 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, 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 -----
|
|
|
|
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, 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) 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 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
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:
|
|
|
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
"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