H, It is said that kafka can tolerate about one half nodes's failure with about 10000 tps and sbft can tolerate about one third nodes's failure with about 2000 tps. From this comparison,

Hi, I tested a simple chain code of mine (in Go) which seems to work fine in "chaincode-docker-devmode" and doing eveything as expected. Now I want to test the same chaincode in "balance transfer"

The reason why channel names must be lower case was to keep the mapping to backing storage simple. The databases used by the peer do not differentiate tables based on case. Rather than mapping a

Hi Jason, What is the answer to the WHY of all lower case for channel-name? Regards Sjir Nijssen -----Oorspronkelijk bericht----- Verzonden: maandag 14 mei 2018 16:29 Aan: Nick Frunza

Yes, the channel name must be all lower case. More precisely, it must be less than 250 characters long and match the regular expression: "[a-z][a-z0-9.-]*" So, must begin with a lower case later,

if you only have 1 peer per org, you don'tneed a bootstrap config. From: "Sunil Suseelan"<sunil.suseelan@...> To: hyperledger-fabric@... Date: 14/05/2018 03:58 PM Subject:

Hello All, As I was referring to Hyperledger Build your First network sample I have some queries against the docker compose yaml file Ø Why do all the peer’s of different Organization have

When I just started to up first-network example by./byfn.sh up of fabric 1.1, I got this error on Macbook pro. What could be the issue and how to resolve this? I tried to change mod to 777, but no

Hello Folks, When am trying to connect my peer to a channel created using cli “peer channel join -b sunsuchannel.block” I fails with below error, anyone can please suggest what am I missing

Hello, Our project currently connected with IoT, and we are concerned about network traffic in HPF. In Fabric 0.6 there was an peer network requests to subscribe to chaincode events and transaction

Well, isn't one of the biggest selling points of (D)LT to avoid the requirement of having third parties to establish trust? Of course, I understand that this is not black and white, and in this case

We have thus far only shipped a crash-fault tolerant ordering service. BFT orderer is coming later this year, along with a less operationally complex RAFT orderer based on etcd-raft. The whole point

Thanks Alexandre, #3 is what I was kind of considering. And regarding the malicious acts, I was wondering too about more subtle cases like let's say the member running the orderer is also an

"is there some general rule of thumb that advises when it's appropriate to create multiple channels within a single network, and when it's appropriate to simply create entirely distinct

is there some general rule of thumb that advises when it's appropriate to create multiple channels within a single network, and when it's appropriate to simply create entirely distinct

Luiz, These are good questions for orderer ownership. The options you have are as follows: 1. One member of the network runs the orderer, that member must be trusted by everyone else. 2. A third party

Hi, I have been wondering about the Orderer nodes also, but from a deployment and ownership perspective. The documentation seems to indicate that there should be of course at least one instance, which

I do agree Sjir, to be more explicit would be helpful. Chris

Very clear answers. I will propose in the Doc WG to include these crystal clear statements in the Conceptual topics, where appropriate. I would prefer instead of the first two sentences of item 2

1) a network is comprised of the peer nodes, the orderer nodes and the optional MSP (fabric-ca or other substitute) nodes. So, yes. The peer nodes obviously comprise the bulk of nodes (there will be