Date   

Peer cant join channel

Sunil Suseelan <sunil.suseelan@...>
 

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

 

Error: proposal failed (err: rpc error: code = Unimplemented desc = unknown service protos.Endorser)

 

 


Sunil Suseelan | Associate Presales Consultant

Phone: +918898549399
Oracle Sales Consulting Centres – MiddelWare

Oracle India | Krishna Magnum | 4th Floor | Bangalore-560076


 

 

Visit the SCC website at http://my.oracle.com/go/epc


Oracle is committed to developing practices and products that help protect the environment

 

 


Chaincode events and transaction outcome API

Oleg Sesov <osesov@...>
 

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 outcome notifications, and they were separated from new block event - so that a connected devices could download only the necessary information.

Since 1.0, these requests seems to be abandoned - while subscription/unsubscription still works, the methods to deliver these events to the client, are not called at peer side. Instead both the node.js and java client SDKs relay on receiving new blocks and parsing them at client side to deliver these events locally. This behavior imposes some issues with connecting IoT devices, especially over the low-bandwidth networks.

In HPF 1.1 situation has been improved a bit, providing filtered blocks, and filtering by channel, however this still generates extra unwanted traffic to connected devices when several devices share the same channel. 

Since the code to deliver these events is mostly here, I wonder are there any plans to bring this functionality, or something similar back to life? I could not get the final impression from reading Fabric's Jira.

Thanks,
Oleg Sesov.



This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.


Re: is an orderer node technically a peer node?

Luiz Omori
 

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

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






Re: is an orderer node technically a peer node?

Christopher Ferris
 

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

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






Re: is an orderer node technically a peer node?

Luiz Omori
 

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





Re: multiple channels versus multiple networks?

Christopher Ferris
 

"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 fabric
networks?"

no. unless the set of members is disjoint and it were unlikely that membership would ever be overlapping, there would be no reason
that one should go to that extreme.

Chris

On Sun, May 13, 2018 at 2:28 PM, rpjday@... <rpjday@...> wrote:

  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 fabric
networks?

  clearly(?), one of the driving rationales behind multiple channels
is the efficiency in sharing commonality across the channels, such as
when many of the same orgs are involved, or some of the same
chaincode, and so on. but does there come a point where there's just
not enough commonality to justify multiple channels in a single
network?

  my analogy is someone saying, "hey, let's check all this content
into a git repository," while someone else observes, "well, all that
content really is two fairly disparate code bases, i'm thinking it
makes more sense to create two independent repositories."

  is there some analogy with fabric in here somewhere?

rday





multiple channels versus multiple networks?

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

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 fabric
networks?

clearly(?), one of the driving rationales behind multiple channels
is the efficiency in sharing commonality across the channels, such as
when many of the same orgs are involved, or some of the same
chaincode, and so on. but does there come a point where there's just
not enough commonality to justify multiple channels in a single
network?

my analogy is someone saying, "hey, let's check all this content
into a git repository," while someone else observes, "well, all that
content really is two fairly disparate code bases, i'm thinking it
makes more sense to create two independent repositories."

is there some analogy with fabric in here somewhere?

rday


Re: is an orderer node technically a peer node?

Alexandre Pauwels
 

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





Re: is an orderer node technically a peer node?

Luiz Omori
 

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





Re: is an orderer node technically a peer node?

Chris <alaskadd@...>
 

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

Chris 


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


 


Re: is an orderer node technically a peer node?

Sjir Nijssen <sjir.nijssen@...>
 

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


 


Re: is an orderer node technically a peer node?

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

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





is an orderer node technically a peer node?

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

(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


GO SDK error

PM <hyperledger@...>
 

Hi,
I am trying following steps from Go SDK (quoting package instructions
with my comments).

### Running a portion of the test suite

```bash
# In the Fabric SDK Go directory
cd $GOPATH/src/github.com/hyperledger/fabric-sdk-go/

# Ensure dependencies are installed
make depend (the output is attached as 1.txt)

# Running code checks (license, linting, spelling, etc)
make checks (this one produced an error, attached as 2.txt)

Any pointers on fixing this error?
Thanks,
Pankaj


Re: error when following tutorial

Kamal R. Prasad
 

hello,

 I was getting this error because the default nodes is not the latest, but an older one. After fixing this, I ran 
#./runApp.sh  on 1 terminal and 

#./testApis.sh -l gaoling in another terminal and hit this error. Can someone tell me what this error means or how to fix it? I can see in terminal 2 that barry has been added, but there is an error in creating a channel.

thanks
-kamal
——————————————————

Signature {
  r: <BN: bb6958aa6d2192e1b07e0264a7c7fae2ce483443be3f42cbc6d05081b7939b63>,
  s: <BN: 29554bcdbdc81db7ab60dd14a2ffbebef4d0ad36244270ec103e340b6362bc42>,
  recoveryParam: 1 }
[2018-05-12 17:40:42.376] [DEBUG] Helper - [NetworkConfig101.js]: getChannel - name mychannel
[2018-05-12 17:40:42.377] [DEBUG] Helper - [NetworkConfig101.js]: getPeer - name peer0.org1.example.com
[2018-05-12 17:40:42.377] [DEBUG] Helper - [NetworkConfig101.js]: getPeer - name peer1.org1.example.com
[2018-05-12 17:40:42.378] [DEBUG] Helper - [NetworkConfig101.js]: getPeer - name peer0.org2.example.com
[2018-05-12 17:40:42.378] [DEBUG] Helper - [NetworkConfig101.js]: getPeer - name peer1.org2.example.com
[2018-05-12 17:40:42.379] [DEBUG] Helper - [NetworkConfig101.js]: getOrderer - name orderer.example.com
[2018-05-12 17:40:42.399] [DEBUG] Helper - [crypto_ecdsa_aes]: ecdsa signature:  Signature {
  r: <BN: 94c325034cbbff81642a858e9c4942eeb1be0f8f2d8113c81db26c9b5044a2c7>,
  s: <BN: 2e7cd6cbd463965bfc974fb67d049e5069eb830678869016b85018462cc43bfb>,
  recoveryParam: 0 }
E0512 17:40:42.479610623   15629 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
error: [Orderer.js]: sendBroadcast - on error: "Error: 14 UNAVAILABLE: Connect Failed\n    at createStatusError (/home/kamal/fabric-samples/balance-transfer/node_modules/grpc/src/client.js:64:15)\n    at ClientDuplexStream._emitStatusIfDone (/home/kamal/fabric-samples/balance-transfer/node_modules/grpc/src/client.js:270:19)\n    at ClientDuplexStream._readsDone (/home/kamal/fabric-samples/balance-transfer/node_modules/grpc/src/client.js:236:8)\n    at readCallback (/home/kamal/fabric-samples/balance-transfer/node_modules/grpc/src/client.js:296:12)"
[2018-05-12 17:40:42.483] [ERROR] Create-Channel - Error: SERVICE_UNAVAILABLE
    at ClientDuplexStream.<anonymous> (/home/kamal/fabric-samples/balance-transfer/node_modules/fabric-client/lib/Orderer.js:136:21)
    at ClientDuplexStream.emit (events.js:182:13)
    at ClientDuplexStream._emitStatusIfDone (/home/kamal/fabric-samples/balance-transfer/node_modules/grpc/src/client.js:271:12)
    at ClientDuplexStream._readsDone (/home/kamal/fabric-samples/balance-transfer/node_modules/grpc/src/client.js:236:8)
    at readCallback (/home/kamal/fabric-samples/balance-transfer/node_modules/grpc/src/client.js:296:12)
(node:15629) UnhandledPromiseRejectionWarning: Error: Failed to initialize the channel: Error: SERVICE_UNAVAILABLE
    at Object.createChannel (/home/kamal/fabric-samples/balance-transfer/app/create-channel.js:65:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:15629) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:15629) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
E0512 17:40:43.426011206   15629 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
E0512 17:40:45.050714780   15629 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
E0512 17:40:47.640724763   15629 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
E0512 17:40:52.099385221   15629 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
E0512 17:40:57.427516749   15629 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
E0512 17:41:08.849937823   15629 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
E0512 17:41:26.425395615   15629 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
E0512 17:41:53.992461558   15629 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
E0512 17:42:40.409525709   15629 ssl_transport_security.cc:989] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.


On 09-May-2018, at 4:56 PM, Kamal R. Prasad <kamalp@...> wrote:

hello,

 when I execute this as option 1 in the tutorial at

I get this error. Can someone tell me what to check for/fix in my environment?

thanks
-kamal
—————————————————————————————
oot@kamal-VirtualBox:~/fabric-samples/balance-transfer# PORT=4000 node app
/home/kamal/fabric-samples/balance-transfer/app.js:109
app.post('/users', async function(req, res) {
                   ^^^^^

SyntaxError: missing ) after argument list
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:374:25)
    at Object.Module._extensions..js (module.js:417:10)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)
    at Function.Module.runMain (module.js:442:10)
    at startup (node.js:136:18)
    at node.js:966:3



Idemix functionality

Subhra Mazumdar
 

How is Idemix going to prevent same person impersonating as two different entities while signing (handle the problem of double signing) ?

--
Yours sincerely,
Subhra Mazumdar.


Re: ChannelName - case matters

Nick Frunza
 

Yes, i got similar error

On Fri, May 11, 2018 at 6:32 PM, PM <hyperledger@...> wrote:
I was getting an error (Invalid characters) while creating a channel
with upper case name. The error went away when the name was changed to
all lower case.

I do not recall anywhere in documentation that channel needs to be
lower case so just curious if channel name needs to be lower case in
all instances.
Thanks.







--
Nik Frunza


Re: Route to create Hyperledger fabric Blockchain solution

Kim Letkeman <kletkema@...>
 

Composer 19 exposes fabric SDK, so it is quite possible to write chaincode with the same behaviors as those in node or Go, however transactions and queries written that way do bypass the excellent Composer ACL system. So there is no free lunch. But it certainly helps if you want to have one point of contact and explore channel heights and blocks for example. Quite a lot can be accomplished with these simple APIs.

I agree that working with Composer is so easy and so powerful that it behooves one to use it for small projects with expectations of only moderate transaction flow. It's just too good to ignore. However, bursty traffic on Fabric 1.0.x and Composer 15 has been giving us a few issues, so I would jump on 1.1 if possible. But using an IBM Cloud lite Kubernetes cluster (free) and the open source IBM Container Service together make for a compelling prototype and development framework, and for now it is Fabric 1 and Composer 16.2. A pretty good starter arrangement in my book.

Kim

Container service on github: https://github.com/IBM-Blockchain/ibm-container-service
Docs for same: https://ibm-blockchain.github.io/
Clusters on IBM Cloud (click create at bottom right to see the lite option): https://console.bluemix.net/containers-kubernetes/catalog/cluster?bss_account=5187d965e477471e465c85cec634a765



Kim Letkeman
Senior Technical Staff Member, IBM Watson IoT

IoT Blockchain


Phone: +1 (613) 762-0352
E-mail:
kletkema@...


"Arnaud Le Hors" ---05/11/2018 11:34:48 AM---Hi, There is no universal answer to your question. Each possibility has its

From: "Arnaud Le Hors" <lehors@...>
To: "Sunil Suseelan" <sunil.suseelan@...>
Cc: hyperledger-fabric@...
Date: 05/11/2018 11:34 AM
Subject: Re: [Hyperledger Fabric] Route to create Hyperledger fabric Blockchain solution
Sent by: fabric@...





Hi,

There is no universal answer to your question. Each possibility has its own pros and cons. Composer can certainly speed things up when it comes to development because it provides you with a higher level of abstraction. On the other hand, if you want to have direct control over your chaincode and work with one of the SDKs Composer isn't going to be helpful. Also, because Composer builds on top of Fabric it is inevitably always a bit behind so if you want to use the latest and greatest features of Fabric you may not be able to do so with Composer before some time.

This said, while it would probably be useful to document those pros and cons somewhere, as a rule of thumb I would say that you should use Composer unless you have a good reason not to.

Hope this helps.
--
Arnaud Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




From:
"Sunil Suseelan" <sunil.suseelan@...>
To:
hyperledger-fabric@...
Date:
05/11/2018 11:19 AM
Subject:
[Hyperledger Fabric] Route to create Hyperledger fabric Blockchain solution
Sent by:
fabric@...



Hello Folks,

Am trying to develop Blockchain solution using Hyperledger and the approach that I have taken is to use the fabric samples “BYFN” sample for the configuration file templates and am modifying it individual files trying out the solution.

My concern here is that, do we have any defined roadmap for creating Blockchain solution, Should one use Hyperledger Composer for solution development or SDK or what exactly one should use to setup blockchain solution.

Please suggest.


Sunil Suseelan | Associate Presales Consultant

Phone: +918898549399
Oracle
Sales Consulting Centres – MiddelWare

Oracle
India | Krishna Magnum | 4th Floor| Bangalore-560076



Visit the SCC website at http://my.oracle.com/go/epc


Oracle is committed to developing practices and products that help protect the environment









ChannelName - case matters

PM <hyperledger@...>
 

I was getting an error (Invalid characters) while creating a channel
with upper case name. The error went away when the name was changed to
all lower case.

I do not recall anywhere in documentation that channel needs to be
lower case so just curious if channel name needs to be lower case in
all instances.
Thanks.


Re: Calling a Javascript-based chaincode function from Go-based chaincode

Gari Singh <garis@...>
 

Invoking chaincode from chaincode is language independent. Both the Go and Node ChaincodeStub objects provide the "InvokeChaincode" function and it can be used to call chaincode written in any language.

-- G


-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: hyperledger-fabric <hyperledger-fabric@...>
From: Yongrae Jo
Sent by: fabric@...
Date: 05/11/2018 10:52AM
Subject: [Hyperledger Fabric] Calling a Javascript-based chaincode function from Go-based chaincode

I can find some documents that explain how to call chaincode function from another different chaincode written in same language (Go).
But I don't know whether it is also possible to call a chaincode function written in different language such as Go and Javascript. If it is possible, how one can write such kinds of codes?

Regards,

7821 - 7840 of 11518