toggle quoted messageShow quoted text
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 is just for running an ordering service, but still, in principle this statement (need of a third party) sounds a bit unsettling.
Anyway, I also understand your point about the permissioned system, just trying to fully consider the implications. Not sure if the scenario I described earlier is possible, but if it is, it would be quite hard to really prove that the orderer misbehaved on purpose. Note that it wasn't a re-ordering or anything that drastic, just a slight, infrequent and extremely selective, timeout.
Please, again, don't get me wrong, just need to understand as much as possible all aspects of Fabric's implementation. To know and to understand...
On Sunday, May 13, 2018, 4:42:52 PM EDT, Christopher Ferris <chris.ferris@...> wrote:
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 of Hyperledger Fabric is that it is a permissioned system, such that even IFF there were a malicious node,
it could be detected and the offending party dealt-with because "we know who you are". If there is concern that the party running
the orderer has a conflict of interest, then give that responsibility (until we have fully BFT orderer) to a trusted third party.
On Sun, May 13, 2018 at 4:32 PM, Luiz Omori via Lists.Hyperledger.Org <luiz_omori=yahoo.com@...>
#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 endorser. The orderer doesn't see the transactions contents (at least that's my understanding), but the endorser obviously does. It could be that the endorser and orderer could collude in such a way to delay certain commits from certain members so that they timeout, allowing the evil member to perhaps execute similar transaction before the original proposer re-posts his. Since this could occur sporadically, the member maintaining the orderer could, for example, claim temporary network issues. Yes, if this is done with enough frequency the negatively affected members would start suspecting something is not right, but you know, a single high value ($$$) transaction could be all it takes.
On Sunday, May 13, 2018, 11:58:59 AM EDT, Alexandre Pauwels <alexj.pauwels@...
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 trusted by all members of the network but not itself a transacting member of the network can run the orderer for everyone.
3. All parties involved in the network each run an orderer and they all communicate and coordinate via Kafka.
I would rank these in order from least to most secure.
Whoever runs the orderer does have significant control over the integrity of the DL. Although it cannot generate arbitrary transactions and submit them to committing peers (as long as the channel chaincode requires endorsements from other members, otherwise, it can; however, this is moot because in that case everyone could submit any transaction anyways), it can decide to re-order the way transactions appear to peers, or select who will or won't receive certain transactions.
There are mitigations to this issue. For one, individual members of the network can regularly compare each other's ledgers and list of blocks to check for irregularities. Although a malicious orderer can't necessarily be kept from performing maliciously, the members of the network can organize themselves in such a way that hijinks are detected quickly and the situation addressed.
Hope that helps, I am also learning so if an expert finds fault in some of my claims please let me know!
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 presumably will be hosted by one of the members of the distributed ledger consortium. The assumption there is that even if the member hosting the Orderer is "devil", the DL can't be compromised? Or is it that in practice most of the consortium members which have the capability to do so will host their own Orderer nodes? If the latter, I guess the second to last step of the protocol, when the endorsed transactions are sent to the Orderer for commit, can be sent to any Orderer?
By the way, NOOB here...
On Sunday, May 13, 2018, 9:02:45 AM EDT, Christopher Ferris <chris.ferris@...
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 few orderer nodes, and again the MSP nodes are optional, though if they are deployed, there would likely be fewer than the number of nodes in an org's cluster.
2) every peer hosts at least one ledger. It would host additional ledgers for each channel in which it participates. All peer nodes have "system" chaincode, which is what manages the validation and endorsement policies, and they also have lifecycle chaincode (lccc) which manages the lifecycle of installed and deployed chaincode. A node only would have application chaincode installed (and optionally instantiated) on a peer IFF that peer node is to be used as an endorsing peer for a given channel.
3) by definition, endorsing peers are a subset of peers. endorsing peers MAY be a strict subset, but that is not a given. every peer MAY be an endorsing peer.