fabric@lists.hyperledger.org | is an orderer node technically a peer node?

Home Messages Hashtags Subgroups

Date Date 1 - 12 of 12

is an orderer node technically a peer node?

jufengyao@...

#3709

Another helpful information :

http://hyperledger-fabric.readthedocs.io/en/latest/membership/membership.html#msp-levels

jufengyao@...

#3708

this maybe helpful:
http://hyperledger-fabric.readthedocs.io/en/latest/Fabric-FAQ.html#ordering-service

Question:	Can I have an organization act both in an ordering and application role?
Answer:	Although this is possible, it is a highly discouraged configuration. By default the `/Channel/Orderer/BlockValidation` policy allows any valid certificate of the ordering organizations to sign blocks. If an organization is acting both in an ordering and application role, then this policy should be updated to restrict block signers to the subset of certificates authorized for ordering.

jufengyao@...

#3707

I'm also interesting in ownership of orderer, but can't find any doc about this topic. as a blockchain system, any one can have a vote. so my understanding is that any organization in fabric should have its right to vote, that means any organization can have its own orderer which it can believe.

from ordering system genesis block, "Orderer" contains a list of organizations, so any organization can be a member of this list. what I don't very clear is : why orderer's MSP should be separately from Peer's MSP? (if orderer and peers belong to same organization)

Version 0.6 didn't have Orderer, only Peer, from 1.0, old peer's function was divided into 2 parts: Peer & orderer.

Luiz Omori

#3696

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...

Regards,

Luiz

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.

Cheers,

Chris

Show quoted text

On Sun, May 13, 2018 at 4:32 PM, Luiz Omori via Lists.Hyperledger.Org <luiz_omori=yahoo.com@...> wrote:

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 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.

Regards,
Luiz

On Sunday, May 13, 2018, 11:58:59 AM EDT, Alexandre Pauwels <alexj.pauwels@...> wrote:

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 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!

Thanks,
Alexandre Pauwels

On Sun, May 13, 2018, 10:34 AM Luiz Omori via Lists.Hyperledger.Org <luiz_omori=yahoo.com@lists. hyperledger.org> wrote:

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 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...

Regards,
Luiz

On Sunday, May 13, 2018, 9:02:45 AM EDT, Christopher Ferris <chris.ferris@...> wrote:

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.

4) yes.

Cheers

Chris

On Sun, May 13, 2018 at 8:30 AM, rpjday@... <rpjday@...> wrote:

(more nitpicky pedantry ...)

currently perusing the entire section on "peers" under key concepts,
and want to clarify a few things that don't seem clear.

first, in the opening sentence, a fabric network is defined as
consisting "primarily" of peer nodes, which plainly suggests that
there may/will be nodes in a fabric network that are *not* peer nodes
-- is that the implication that that first line is trying to leave
with the reader?

next, while there may be weird corner cases, is it understood that
any meaningful/useful peer node should be hosting at least one ledger
and at least one example of chaincode that has access to that ledger?

third, are endorsing peers in a network a strict subset of the peers
in that network? that is, do endorsing peers still host ledgers and
chaincode as do regular peers, they simply have extra authority to do
endorsing?

finally, are orderer nodes a completely different animal from peer
nodes? it appears that way from that section, but i just want to make
sure, as in -- orderer nodes do not host either ledgers or chaincode.
or can they? can orderer nodes be specialized instances of peer nodes,
or must they necessarily be a distinct set of (non-peer) nodes in the
network?

rday

Christopher Ferris

#3695

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.

Cheers,

Chris

Show quoted text

On Sun, May 13, 2018 at 4:32 PM, Luiz Omori via Lists.Hyperledger.Org <luiz_omori=yahoo.com@...> wrote:

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 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.

Regards,
Luiz

On Sunday, May 13, 2018, 11:58:59 AM EDT, Alexandre Pauwels <alexj.pauwels@...> wrote:

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 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!

Thanks,
Alexandre Pauwels

On Sun, May 13, 2018, 10:34 AM Luiz Omori via Lists.Hyperledger.Org <luiz_omori=yahoo.com@lists.hyperledger.org> wrote:

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 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...

Regards,
Luiz

On Sunday, May 13, 2018, 9:02:45 AM EDT, Christopher Ferris <chris.ferris@...> wrote:

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.

4) yes.

Cheers

Chris

On Sun, May 13, 2018 at 8:30 AM, rpjday@... <rpjday@...> wrote:

(more nitpicky pedantry ...)

currently perusing the entire section on "peers" under key concepts,
and want to clarify a few things that don't seem clear.

first, in the opening sentence, a fabric network is defined as
consisting "primarily" of peer nodes, which plainly suggests that
there may/will be nodes in a fabric network that are *not* peer nodes
-- is that the implication that that first line is trying to leave
with the reader?

next, while there may be weird corner cases, is it understood that
any meaningful/useful peer node should be hosting at least one ledger
and at least one example of chaincode that has access to that ledger?

third, are endorsing peers in a network a strict subset of the peers
in that network? that is, do endorsing peers still host ledgers and
chaincode as do regular peers, they simply have extra authority to do
endorsing?

finally, are orderer nodes a completely different animal from peer
nodes? it appears that way from that section, but i just want to make
sure, as in -- orderer nodes do not host either ledgers or chaincode.
or can they? can orderer nodes be specialized instances of peer nodes,
or must they necessarily be a distinct set of (non-peer) nodes in the
network?

rday

Luiz Omori

#3694

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 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.

Regards,

Luiz

On Sunday, May 13, 2018, 11:58:59 AM EDT, Alexandre Pauwels <alexj.pauwels@...> wrote:

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 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!

Thanks,

Alexandre Pauwels

Show quoted text

On Sun, May 13, 2018, 10:34 AM Luiz Omori via Lists.Hyperledger.Org <luiz_omori=yahoo.com@...> wrote:

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 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...

Regards,
Luiz

On Sunday, May 13, 2018, 9:02:45 AM EDT, Christopher Ferris <chris.ferris@...> wrote:

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.

4) yes.

Cheers

Chris

On Sun, May 13, 2018 at 8:30 AM, rpjday@... <rpjday@...> wrote:

(more nitpicky pedantry ...)

currently perusing the entire section on "peers" under key concepts,
and want to clarify a few things that don't seem clear.

first, in the opening sentence, a fabric network is defined as
consisting "primarily" of peer nodes, which plainly suggests that
there may/will be nodes in a fabric network that are *not* peer nodes
-- is that the implication that that first line is trying to leave
with the reader?

next, while there may be weird corner cases, is it understood that
any meaningful/useful peer node should be hosting at least one ledger
and at least one example of chaincode that has access to that ledger?

third, are endorsing peers in a network a strict subset of the peers
in that network? that is, do endorsing peers still host ledgers and
chaincode as do regular peers, they simply have extra authority to do
endorsing?

finally, are orderer nodes a completely different animal from peer
nodes? it appears that way from that section, but i just want to make
sure, as in -- orderer nodes do not host either ledgers or chaincode.
or can they? can orderer nodes be specialized instances of peer nodes,
or must they necessarily be a distinct set of (non-peer) nodes in the
network?

rday

Alexandre Pauwels

#3691

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 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.

Hope that helps, I am also learning so if an expert finds fault in some of my claims please let me know!

Thanks,

Alexandre Pauwels

Show quoted text

On Sun, May 13, 2018, 10:34 AM Luiz Omori via Lists.Hyperledger.Org <luiz_omori=yahoo.com@...> wrote:

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 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...

Regards,
Luiz

On Sunday, May 13, 2018, 9:02:45 AM EDT, Christopher Ferris <chris.ferris@...> wrote:

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.

4) yes.

Cheers

Chris

On Sun, May 13, 2018 at 8:30 AM, rpjday@... <rpjday@...> wrote:

(more nitpicky pedantry ...)

currently perusing the entire section on "peers" under key concepts,
and want to clarify a few things that don't seem clear.

first, in the opening sentence, a fabric network is defined as
consisting "primarily" of peer nodes, which plainly suggests that
there may/will be nodes in a fabric network that are *not* peer nodes
-- is that the implication that that first line is trying to leave
with the reader?

next, while there may be weird corner cases, is it understood that
any meaningful/useful peer node should be hosting at least one ledger
and at least one example of chaincode that has access to that ledger?

third, are endorsing peers in a network a strict subset of the peers
in that network? that is, do endorsing peers still host ledgers and
chaincode as do regular peers, they simply have extra authority to do
endorsing?

finally, are orderer nodes a completely different animal from peer
nodes? it appears that way from that section, but i just want to make
sure, as in -- orderer nodes do not host either ledgers or chaincode.
or can they? can orderer nodes be specialized instances of peer nodes,
or must they necessarily be a distinct set of (non-peer) nodes in the
network?

rday

Luiz Omori

#3690

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 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...

Regards,

Luiz

On Sunday, May 13, 2018, 9:02:45 AM EDT, Christopher Ferris <chris.ferris@...> wrote:

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.

4) yes.

Cheers

Chris

Show quoted text

On Sun, May 13, 2018 at 8:30 AM, rpjday@... <rpjday@...> wrote:

(more nitpicky pedantry ...)

currently perusing the entire section on "peers" under key concepts,
and want to clarify a few things that don't seem clear.

first, in the opening sentence, a fabric network is defined as
consisting "primarily" of peer nodes, which plainly suggests that
there may/will be nodes in a fabric network that are *not* peer nodes
-- is that the implication that that first line is trying to leave
with the reader?

next, while there may be weird corner cases, is it understood that
any meaningful/useful peer node should be hosting at least one ledger
and at least one example of chaincode that has access to that ledger?

third, are endorsing peers in a network a strict subset of the peers
in that network? that is, do endorsing peers still host ledgers and
chaincode as do regular peers, they simply have extra authority to do
endorsing?

finally, are orderer nodes a completely different animal from peer
nodes? it appears that way from that section, but i just want to make
sure, as in -- orderer nodes do not host either ledgers or chaincode.
or can they? can orderer nodes be specialized instances of peer nodes,
or must they necessarily be a distinct set of (non-peer) nodes in the
network?

rday

Chris <alaskadd@...>

#3689

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

Chris

Show quoted text

On May 13, 2018, at 8:26 AM, Sjir Nijssen <sjir.nijssen@...> wrote:

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 the following sentence:

Every peer has exactly one ledger for every channel to which it is joined.

Could you agree with that?

Regards

Sjir Nijssen

Van: fabric@... [mailto:fabric@...] Namens Christopher Ferris
Verzonden: zondag 13 mei 2018 15:03
Aan: rpjday@...
CC: Hyperledger Fabric discussion list <hyperledger-fabric@...>
Onderwerp: Re: [Hyperledger Fabric] is an orderer node technically a peer node?

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.

4) yes.

Cheers

Chris

On Sun, May 13, 2018 at 8:30 AM, rpjday@... <rpjday@...> wrote:

(more nitpicky pedantry ...)

currently perusing the entire section on "peers" under key concepts,
and want to clarify a few things that don't seem clear.

first, in the opening sentence, a fabric network is defined as
consisting "primarily" of peer nodes, which plainly suggests that
there may/will be nodes in a fabric network that are *not* peer nodes
-- is that the implication that that first line is trying to leave
with the reader?

next, while there may be weird corner cases, is it understood that
any meaningful/useful peer node should be hosting at least one ledger
and at least one example of chaincode that has access to that ledger?

third, are endorsing peers in a network a strict subset of the peers
in that network? that is, do endorsing peers still host ledgers and
chaincode as do regular peers, they simply have extra authority to do
endorsing?

finally, are orderer nodes a completely different animal from peer
nodes? it appears that way from that section, but i just want to make
sure, as in -- orderer nodes do not host either ledgers or chaincode.
or can they? can orderer nodes be specialized instances of peer nodes,
or must they necessarily be a distinct set of (non-peer) nodes in the
network?

rday

Sjir Nijssen <sjir.nijssen@...>

#3688

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 the following sentence:

Every peer has exactly one ledger for every channel to which it is joined.

Could you agree with that?

Regards

Sjir Nijssen

Show quoted text

Van: fabric@... [mailto:fabric@...] Namens Christopher Ferris
Verzonden: zondag 13 mei 2018 15:03
Aan: rpjday@...
CC: Hyperledger Fabric discussion list <hyperledger-fabric@...>
Onderwerp: Re: [Hyperledger Fabric] is an orderer node technically a peer node?

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.

4) yes.

Cheers

Chris

On Sun, May 13, 2018 at 8:30 AM, rpjday@... <rpjday@...> wrote:

(more nitpicky pedantry ...)

currently perusing the entire section on "peers" under key concepts,
and want to clarify a few things that don't seem clear.

first, in the opening sentence, a fabric network is defined as
consisting "primarily" of peer nodes, which plainly suggests that
there may/will be nodes in a fabric network that are *not* peer nodes
-- is that the implication that that first line is trying to leave
with the reader?

next, while there may be weird corner cases, is it understood that
any meaningful/useful peer node should be hosting at least one ledger
and at least one example of chaincode that has access to that ledger?

third, are endorsing peers in a network a strict subset of the peers
in that network? that is, do endorsing peers still host ledgers and
chaincode as do regular peers, they simply have extra authority to do
endorsing?

finally, are orderer nodes a completely different animal from peer
nodes? it appears that way from that section, but i just want to make
sure, as in -- orderer nodes do not host either ledgers or chaincode.
or can they? can orderer nodes be specialized instances of peer nodes,
or must they necessarily be a distinct set of (non-peer) nodes in the
network?

rday

Christopher Ferris

#3687

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.

4) yes.

Cheers

Chris

Show quoted text

On Sun, May 13, 2018 at 8:30 AM, rpjday@... <rpjday@...> wrote:

(more nitpicky pedantry ...)

currently perusing the entire section on "peers" under key concepts,
and want to clarify a few things that don't seem clear.

first, in the opening sentence, a fabric network is defined as
consisting "primarily" of peer nodes, which plainly suggests that
there may/will be nodes in a fabric network that are *not* peer nodes
-- is that the implication that that first line is trying to leave
with the reader?

next, while there may be weird corner cases, is it understood that
any meaningful/useful peer node should be hosting at least one ledger
and at least one example of chaincode that has access to that ledger?

third, are endorsing peers in a network a strict subset of the peers
in that network? that is, do endorsing peers still host ledgers and
chaincode as do regular peers, they simply have extra authority to do
endorsing?

finally, are orderer nodes a completely different animal from peer
nodes? it appears that way from that section, but i just want to make
sure, as in -- orderer nodes do not host either ledgers or chaincode.
or can they? can orderer nodes be specialized instances of peer nodes,
or must they necessarily be a distinct set of (non-peer) nodes in the
network?

rday

rpjday@crashcourse.ca <rpjday@...>

#3686

(more nitpicky pedantry ...)

  currently perusing the entire section on "peers" under key concepts,
and want to clarify a few things that don't seem clear.

  first, in the opening sentence, a fabric network is defined as
consisting "primarily" of peer nodes, which plainly suggests that
there may/will be nodes in a fabric network that are *not* peer nodes
-- is that the implication that that first line is trying to leave
with the reader?

  next, while there may be weird corner cases, is it understood that
any meaningful/useful peer node should be hosting at least one ledger
and at least one example of chaincode that has access to that ledger?

  third, are endorsing peers in a network a strict subset of the peers
in that network? that is, do endorsing peers still host ledgers and
chaincode as do regular peers, they simply have extra authority to do
endorsing?

  finally, are orderer nodes a completely different animal from peer
nodes? it appears that way from that section, but i just want to make
sure, as in -- orderer nodes do not host either ledgers or chaincode.
or can they? can orderer nodes be specialized instances of peer nodes,
or must they necessarily be a distinct set of (non-peer) nodes in the
network?

rday

1 - 12 of 12

Previous Topic Next Topic

Home Hashtags Subgroups Terms