Date   

Re: Proposal : Hyperledger Fabric block archiving

Yacov
 

Hey Atsushi,

one thing I noticed while skimming the code, is that while you send the ArchivedBlockFileMsg via gossip, you are not ensuring it is eventually propagated to peers successfully.

This means that if a peer didn't get the message, it won't archive your file.

I suggest that you think of a more robust mechanism, like periodically comparing digests of ranges.

The code in https://github.com/hyperledger-labs/fabric-block-archiving/blob/master/gossip/gossip/pull/pullstore.go is a generic pull mechanism based on digests.  You might want to give it a look.


- Yacov.



From:        "Manish" <manish.sethi@...>
To:        nekia <atsushin@...>
Cc:        "fabric@..." <fabric@...>
Date:        11/25/2019 10:50 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Proposal : Hyperledger Fabric block archiving
Sent by:        fabric@...




Hi Atsushi,

Thanks for your proposal and at high level the objective makes sense to me and below is my high level observations that you may want to consider. 

First, the fundamental assumption that you make is that all the block files are same across peers is incorrect. The block files are not guaranteed to contain same number of blocks across peers. This is because a block file is bounded by the file size and not by the  number of blocks. Further, the size of a given block may vary slightly on each peer. Though the header and the data section of a blocks are of same size across peers but this difference in overall size could be caused by the metadata section which contains concenter signatures. In addition, on some of the peers, the metadata may also include block commit hash as an additional data. So, either you have to operate at the block numbers (i.e., during purging an archiver client on a peer deals a file that should be purged partially based on where in the file the target block is located) or if you want to deal at the files level the archiver client could just consider files up to previous file.

Second, there are certain kind of queries for which a peer assumes the presence of block files in the current way. This primarily includes history queries, blocks related queries, and txid related queries. These queries may start failing or lead to crashes or unexpected results if you simply delete the files. I did not see any details in your design how you plan to handle these. The potential solutions may range from simply denying these kind of queries to more sophisticated solution such as serving the queries by involving the  achiever repository. However, in either of these the challenge would be to know that the desired block/ transaction has been purged from the local peer (e.g., consider blockByHash or transactionByTxid kind of queries.)

Third, somewhat similar to the second point above, peer has a feature wherein it rebuilds the statedb and historydb if they are dropped and peer is simply restarted. For this feature as well it relies on the percense of blockfiles.

Fourth, I am not sure if gossip is the right communication mechanism that you want to employ for this communication. An archiver client perhaps can simply poll (or register for updates with) the archiver repository.

Finally, I would like to understand in more details what are the benefits of having a separate repository? Why not simply let the files be there on the anchor peer and purge from other peers? If the answer is compression, then ideally we should explore a choise of writing the data in blockfiles in compressed format.


Hope this helps.

Thanks,
Manish


On Thu, Nov 14, 2019 at 10:26 PM nekia <atsushin@...> wrote:
Hello everybody,

 

 

I’d like to propose a new feature ‘block archiving’ for Hyperledger Fabric. We are working on this block archiving project which is listed under Hyperledger Labs repository. Our current main efforts are focused on improvement of reliability. If we could get some feedback on our proposed feature from members involved in Hyperledger Fabric implementation, it’ll be quite useful for further improvement of UX.

 

- Hyperledger Fabric Block Archiving

    https://github.com/hyperledger-labs/fabric-block-archiving

 

    This enhancement for Hyperledger Fabric is aiming to:

 

        - Reduce the total amount of storage space required for an organisation to operate a Hyperledger Fabric network by archiving block data into repository.

        - For organisations, operate a Hyperledger Fabric network with low resourced nodes, such as a IoT edge devices for example.

 

- Our proposal

    https://github.com/hyperledger-labs/hyperledger-labs.github.io/blob/master/labs/fabric-block-archiving.md

 

- Technical overview

    https://github.com/nekia/fabric-block-archiving/blob/techoverview/BlockVault%20-%20Technical%20Overview.pdf

 

 

Kind regards,

Atsushi Neki

RocketChat:  nekia

 

Atsushi Neki
Senior Software Development Engineer

Fujitsu Australia Software Technology Pty Ltd

14 Rodborough Road, Frenchs Forest NSW 2086, Australia
T
+61 2 9452 9036 M +61 428 223 387

AtsushiN@...
fastware.com.au


Disclaimer

The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.

Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.

If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@...





Re: Proposal : Hyperledger Fabric block archiving

Manish
 

Hi Atsushi,

Thanks for your proposal and at high level the objective makes sense to me and below is my high level observations that you may want to consider. 

First, the fundamental assumption that you make is that all the block files are same across peers is incorrect. The block files are not guaranteed to contain same number of blocks across peers. This is because a block file is bounded by the file size and not by the  number of blocks. Further, the size of a given block may vary slightly on each peer. Though the header and the data section of a blocks are of same size across peers but this difference in overall size could be caused by the metadata section which contains concenter signatures. In addition, on some of the peers, the metadata may also include block commit hash as an additional data. So, either you have to operate at the block numbers (i.e., during purging an archiver client on a peer deals a file that should be purged partially based on where in the file the target block is located) or if you want to deal at the files level the archiver client could just consider files up to previous file.

Second, there are certain kind of queries for which a peer assumes the presence of block files in the current way. This primarily includes history queries, blocks related queries, and txid related queries. These queries may start failing or lead to crashes or unexpected results if you simply delete the files. I did not see any details in your design how you plan to handle these. The potential solutions may range from simply denying these kind of queries to more sophisticated solution such as serving the queries by involving the  achiever repository. However, in either of these the challenge would be to know that the desired block/ transaction has been purged from the local peer (e.g., consider blockByHash or transactionByTxid kind of queries.)

Third, somewhat similar to the second point above, peer has a feature wherein it rebuilds the statedb and historydb if they are dropped and peer is simply restarted. For this feature as well it relies on the percense of blockfiles.

Fourth, I am not sure if gossip is the right communication mechanism that you want to employ for this communication. An archiver client perhaps can simply poll (or register for updates with) the archiver repository.

Finally, I would like to understand in more details what are the benefits of having a separate repository? Why not simply let the files be there on the anchor peer and purge from other peers? If the answer is compression, then ideally we should explore a choise of writing the data in blockfiles in compressed format.


Hope this helps.

Thanks,
Manish


On Thu, Nov 14, 2019 at 10:26 PM nekia <atsushin@...> wrote:

Hello everybody,

 

 

I’d like to propose a new feature ‘block archiving’ for Hyperledger Fabric. We are working on this block archiving project which is listed under Hyperledger Labs repository. Our current main efforts are focused on improvement of reliability. If we could get some feedback on our proposed feature from members involved in Hyperledger Fabric implementation, it’ll be quite useful for further improvement of UX.

 

- Hyperledger Fabric Block Archiving

    https://github.com/hyperledger-labs/fabric-block-archiving

 

    This enhancement for Hyperledger Fabric is aiming to:

 

        - Reduce the total amount of storage space required for an organisation to operate a Hyperledger Fabric network by archiving block data into repository.

        - For organisations, operate a Hyperledger Fabric network with low resourced nodes, such as a IoT edge devices for example.

 

- Our proposal

    https://github.com/hyperledger-labs/hyperledger-labs.github.io/blob/master/labs/fabric-block-archiving.md

 

- Technical overview

    https://github.com/nekia/fabric-block-archiving/blob/techoverview/BlockVault%20-%20Technical%20Overview.pdf

 

 

Kind regards,

Atsushi Neki

RocketChat:  nekia

 

Atsushi Neki
Senior Software Development Engineer

Fujitsu Australia Software Technology Pty Ltd

14 Rodborough Road, Frenchs Forest NSW 2086, Australia
T +61 2 9452 9036 M +61 428 223 387
AtsushiN@...
fastware.com.au


Disclaimer

The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.


Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.


If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@...


Re: Multi-network node deployments #fabric

Nye Liu <nye@...>
 

Private VLAN/VPN, or do a proper public IP p2p setup w/o docker swarm.

Again, docker swarm and k8s are great for distributed microservices and big load balanced, asymmetrical client/server stacks, not p2p. They're both designed by those uninterested in symmetric, stateful node, p2p applications. There are a ton of hacks to get around the various networking issues, but IMO they all try to fit a square peg into a round hole.

On 11/25/2019 8:33 AM, Nancy Min wrote:

Thanks Tong.

 

We are currently using Docker swarm as a method of deploying a Fabric network across multiple hosts. However, this solution can only be properly applied to hosts inside the same LAN. Our attempts to deploy the Fabric network to other remote locations using swarm have been problematic. The simplest solution we have so far is to use port forwarding to make manager nodes publicly accessible to the internet and creating the swarm network that way. This has the unfortunate draw back of creating a dependency for the worker nodes as they require certain manager nodes to communicate with the rest of the network. What are our options for deploying a Fabric network across multiple remote locations, each with their distinct internet networks?

 

Nancy Min

ecoLong

Tel/Direct: +1 518 703 6088

www.ecolongllc.com

 

From: Tong Li <litong01@...>
Sent: Thursday, October 17, 2019 4:36 PM
To: Nancy Min <Nancym@...>
Cc: fabric@...
Subject: Re: [Hyperledger Fabric] Multi-network node deployments #fabric

 

if you have k8s, then it will be very easy to do this and please look into cello ansible agent.

Thanks.

Tong Li
IBM Open Technology


"Nancy Min" ---10/17/2019 04:20:48 PM---Hi All, We're interested in different methods to facilitate multi-network node deployments. One opti

From: "Nancy Min" <Nancym@...>
To: fabric@...
Date: 10/17/2019 04:20 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Multi-network node deployments #fabric
Sent by: fabric@...





Hi All,

We're interested in different methods to facilitate multi-network node deployments. One option we've thought of is to communicate with nodes hosted on different networks by using port forwarding on both ends in order for swarm connections to occur. Are there better ways to do this?

Thanks,
Nancy



Re: Multi-network node deployments #fabric

email4tong@gmail.com
 

I highly suggest that you look into cello ansible agent to deploy your network onto k8s environment. Here is the doc on how to do that. hyperledger/cello

Please let me know if you have questions or errors doing it.


On Monday, November 25, 2019, 11:35:47 AM EST, Nancy Min <nancym@...> wrote:


Thanks Tong.

 

We are currently using Docker swarm as a method of deploying a Fabric network across multiple hosts. However, this solution can only be properly applied to hosts inside the same LAN. Our attempts to deploy the Fabric network to other remote locations using swarm have been problematic. The simplest solution we have so far is to use port forwarding to make manager nodes publicly accessible to the internet and creating the swarm network that way. This has the unfortunate draw back of creating a dependency for the worker nodes as they require certain manager nodes to communicate with the rest of the network. What are our options for deploying a Fabric network across multiple remote locations, each with their distinct internet networks?

 

Nancy Min

ecoLong

Tel/Direct: +1 518 703 6088

www.ecolongllc.com

 

From: Tong Li <litong01@...>
Sent: Thursday, October 17, 2019 4:36 PM
To: Nancy Min <Nancym@...>
Cc: fabric@...
Subject: Re: [Hyperledger Fabric] Multi-network node deployments #fabric

 

if you have k8s, then it will be very easy to do this and please look into cello ansible agent.

Thanks.

Tong Li
IBM Open Technology


Inactive hide details for "Nancy Min" ---10/17/2019 04:20:48 PM---Hi All, We're interested in different methods to facilitate multi-network node deployments. One opti

From: "Nancy Min" <Nancym@...>
To: fabric@...
Date: 10/17/2019 04:20 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Multi-network node deployments #fabric
Sent by: fabric@...





Hi All,

We're interested in different methods to facilitate multi-network node deployments. One option we've thought of is to communicate with nodes hosted on different networks by using port forwarding on both ends in order for swarm connections to occur. Are there better ways to do this?

Thanks,
Nancy



Re: Multi-network node deployments #fabric

Nancy Min
 

Thanks Tong.

 

We are currently using Docker swarm as a method of deploying a Fabric network across multiple hosts. However, this solution can only be properly applied to hosts inside the same LAN. Our attempts to deploy the Fabric network to other remote locations using swarm have been problematic. The simplest solution we have so far is to use port forwarding to make manager nodes publicly accessible to the internet and creating the swarm network that way. This has the unfortunate draw back of creating a dependency for the worker nodes as they require certain manager nodes to communicate with the rest of the network. What are our options for deploying a Fabric network across multiple remote locations, each with their distinct internet networks?

 

Nancy Min

ecoLong

Tel/Direct: +1 518 703 6088

www.ecolongllc.com

 

From: Tong Li <litong01@...>
Sent: Thursday, October 17, 2019 4:36 PM
To: Nancy Min <Nancym@...>
Cc: fabric@...
Subject: Re: [Hyperledger Fabric] Multi-network node deployments #fabric

 

if you have k8s, then it will be very easy to do this and please look into cello ansible agent.

Thanks.

Tong Li
IBM Open Technology


"Nancy Min" ---10/17/2019 04:20:48 PM---Hi All, We're interested in different methods to facilitate multi-network node deployments. One opti

From: "Nancy Min" <Nancym@...>
To: fabric@...
Date: 10/17/2019 04:20 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Multi-network node deployments #fabric
Sent by: fabric@...





Hi All,

We're interested in different methods to facilitate multi-network node deployments. One option we've thought of is to communicate with nodes hosted on different networks by using port forwarding on both ends in order for swarm connections to occur. Are there better ways to do this?

Thanks,
Nancy



Next Hyperledger Fabric Application Developer Community call - Thursday Nov 28th @ 4pm UTC (4pm UK) - 11am ET, 8am PT

Paul O'Mahoney <mahoney@...>
 

dear Fabric Application Developer,


the next  Fabric Application Developer community call is scheduled for this  Thursday Nov 28th @ 4pm UTC (4pm UK) - 11am ET (-5 hrs), 8am PT(-8 hrs) - see time zones.   It lasts approx 30-60 mins FYI.

The agenda will be posted here -> https://wiki.hyperledger.org/display/fabric/Meeting+Agendas%3A+Fabric+Application+Developer+Community+Call

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow in their development journey (eg. developing applications, smart contracts,  developing application clients, using the SDKs, tutorials/demos etc - eg. spanning NodeJS/TypeScript, Java, Go etc etc) 
- helping App developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- to foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric. 
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and 
- approx length of your pitch in minutes


The Zoom webconference ID is https://zoom.us/my/hyperledger.community   

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1

mahoney@...



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: #fabric #raft Orderers and organization, how to organize them? #fabric #raft

Todd Little
 

Why is it a "best practice" to have different CAs for peers and for orderers?  What potential problems is this solving over having a single CA for both?

Regards,
Todd


Re: #fabric #raft Orderers and organization, how to organize them? #fabric #raft

Jean-Gaël Dominé <jgdomine@...>
 

Yueming,

From the description you gave and Joe's explanation, you should have two CAs instead one of to issue the certificates for both MSPs (One for org1MSP and one for org1OrdererMSP). Joe explained that the same root certificate (thus Certificate Authority) should not issue the peers and orderers artifacts.
Technically nothing prevents you from doing so but from a best practice perspective, that should be the case.

Hope I'm not mistaken

Jean-Gaël


Re: #fabric #raft Orderers and organization, how to organize them? #fabric #raft

Yueming Xu
 

As I understand it, each org is similar to a real-world business entity, and should have its own CA. Each org may or may not own an orderer node. If an org contributes both peer and orderer nodes, however, you need to define 2 MSP’s, e.g., org1MSP and org1OrdererMSP. But you can use the same org1CA to issue certificates for both MSP’s, since they belong to the same business entity. 

Yueming Xu


Re: #fabric #raft Orderers and organization, how to organize them? #fabric #raft

Joe Alewine <joe.alewine@...>
 

Yes, as I keep saying, your peers and ordering nodes should belong to different Fabric organizations. If there are subgroupings within a large entity like a bank, this separation should still happen between peer and orderer orgs, only now within each subgrouping.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: Harris Niavis <harniavis@...>
To: Joe Alewine <Joe.Alewine@...>
Cc: fabric@..., "Jean-Gaël Dominé" <jgdomine@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 11:14 AM
 
Thanks Joe,
 
So it is technically feasible but not recommended for decentralization purposes, right? 
 
I could imagine a use case where we don't have such a large organization with different arms like BoA and it could make sense to have a single organization for peers and orderers. e.g. the fisherman in the supply chain paradigm.
Should we still split the peers and orderers (of the same conceptual organization) to different fabric organizations?
 
Best,
Harris
 
On Fri, 22 Nov 2019 at 10:57, Joe Alewine <Joe.Alewine@...> wrote:
Harris,
 
This is not a recommended configuration. Each entity (ie, Bank of America) should have an org that owns their peers and a separate org that owns their ordering nodes. Regulations or business preferences might make it desirable (or necessary) for BOA to split up their operations even further (a different CA for their investment arm than for their housing arm, for example), but ordering nodes and peers should not have the same root of trust (the same root CA).
 
Fabric will ALLOW you to do this --- there is no internal mechanism that checks to make sure the roots of trust are different --- but it is not recommended.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 
----- Original message -----
From: Harris Niavis <harniavis@...>
To: "Jean-Gaël Dominé" <jgdomine@...>, joe.alewine@...
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 10:43 AM
 
Hi Joe and Jean,
 
Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers.
 
So instead of creating new organizations for each orderer (Org1Ord and Org2Ord), can I have a single Org1 for both peer1 and orderer1 and another Org2 for both peer2 and orderer2?
 
Best,
Harris
 
On Fri, 22 Nov 2019 at 10:24, Jean-Gaël Dominé <jgdomine@...> wrote:
Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël

 

 

 
 
 
 
 
--
Harris Niavis
Yale Institute of Network Science (YINS)
University of Thessaly (UTH)
Centre for Research and Technology Hellas (CERTH)
s: niavisharris
 


Re: #fabric #raft Orderers and organization, how to organize them? #fabric #raft

Harris Niavis
 

Thanks Joe,

So it is technically feasible but not recommended for decentralization purposes, right? 

I could imagine a use case where we don't have such a large organization with different arms like BoA and it could make sense to have a single organization for peers and orderers. e.g. the fisherman in the supply chain paradigm.
Should we still split the peers and orderers (of the same conceptual organization) to different fabric organizations?

Best,
Harris

On Fri, 22 Nov 2019 at 10:57, Joe Alewine <Joe.Alewine@...> wrote:
Harris,
 
This is not a recommended configuration. Each entity (ie, Bank of America) should have an org that owns their peers and a separate org that owns their ordering nodes. Regulations or business preferences might make it desirable (or necessary) for BOA to split up their operations even further (a different CA for their investment arm than for their housing arm, for example), but ordering nodes and peers should not have the same root of trust (the same root CA).
 
Fabric will ALLOW you to do this --- there is no internal mechanism that checks to make sure the roots of trust are different --- but it is not recommended.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 
----- Original message -----
From: Harris Niavis <harniavis@...>
To: "Jean-Gaël Dominé" <jgdomine@...>, joe.alewine@...
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 10:43 AM
 
Hi Joe and Jean,
 
Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers.
 
So instead of creating new organizations for each orderer (Org1Ord and Org2Ord), can I have a single Org1 for both peer1 and orderer1 and another Org2 for both peer2 and orderer2?
 
Best,
Harris
 
On Fri, 22 Nov 2019 at 10:24, Jean-Gaël Dominé <jgdomine@...> wrote:
Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël

 

 

 
 
 



--
Harris Niavis
Yale Institute of Network Science (YINS)
University of Thessaly (UTH)
Centre for Research and Technology Hellas (CERTH)
s: niavisharris


Re: #fabric #raft Orderers and organization, how to organize them? #fabric #raft

Joe Alewine <joe.alewine@...>
 

Harris,
 
This is not a recommended configuration. Each entity (ie, Bank of America) should have an org that owns their peers and a separate org that owns their ordering nodes. Regulations or business preferences might make it desirable (or necessary) for BOA to split up their operations even further (a different CA for their investment arm than for their housing arm, for example), but ordering nodes and peers should not have the same root of trust (the same root CA).
 
Fabric will ALLOW you to do this --- there is no internal mechanism that checks to make sure the roots of trust are different --- but it is not recommended.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: Harris Niavis <harniavis@...>
To: "Jean-Gaël Dominé" <jgdomine@...>, joe.alewine@...
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 10:43 AM
 
Hi Joe and Jean,
 
Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers.
 
So instead of creating new organizations for each orderer (Org1Ord and Org2Ord), can I have a single Org1 for both peer1 and orderer1 and another Org2 for both peer2 and orderer2?
 
Best,
Harris
 
On Fri, 22 Nov 2019 at 10:24, Jean-Gaël Dominé <jgdomine@...> wrote:
Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël

 

 

 
 
 


Re: #fabric #raft Orderers and organization, how to organize them? #fabric #raft

Harris Niavis
 

Hi Joe and Jean,

Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers.

So instead of creating new organizations for each orderer (Org1Ord and Org2Ord), can I have a single Org1 for both peer1 and orderer1 and another Org2 for both peer2 and orderer2?

Best,
Harris

On Fri, 22 Nov 2019 at 10:24, Jean-Gaël Dominé <jgdomine@...> wrote:
Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël



Re: #fabric #raft Orderers and organization, how to organize them? #fabric #raft

Jean-Gaël Dominé <jgdomine@...>
 

Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël


Re: To install chaincode, do you use source code or packaged cds file?

Yueming Xu
 

Ah. Thanks for the explanation.

On Nov 22, 2019, at 7:58 AM, Gari Singh <garis@...> wrote:

There's not actually a flag ... you simply specify the full path to the package (e.g. ./mypackage.cds) as an argument (e.g. after all the flags).

peer chaincode install -n mycc -v 1.0 -p github.com/mycc mycc.cds



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


Re: To install chaincode, do you use source code or packaged cds file?

Gari Singh <garis@...>
 

There's not actually a flag ... you simply specify the full path to the package (e.g. ./mypackage.cds) as an argument (e.g. after all the flags).

peer chaincode install -n mycc -v 1.0 -p github.com/mycc mycc.cds



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


Re: To install chaincode, do you use source code or packaged cds file?

Yueming Xu
 

How do you do it, Gari?  I checked 'peer chaincode install --help', and could not see a flag to specify a cds package.  My version of the peer command is 1.4.4.  Thanks.


Re: #fabric #raft Orderers and organization, how to organize them? #fabric #raft

Joe Alewine <joe.alewine@...>
 

Jean-Gael,
 
So Fabric organizations are similar to organizations as we think of them in the real world (Bank of America is an "organization"), but there are differences that affect the way you should organize things (if you'll forgive the pun).
 
Organizations are defined through an MSP, which is a series of folders that, most importantly, establish two things: 1) the admins of the organization (there are other kinds of users, but admins are the most important), and 2) the root of trust for the organization (its root CA). These organizations then, as you know, are associated with a node during the creation of the node, signaling that the node is "owned" by the organization. 
 
The best practice is for each organization to have its own CA (its own root CA cert), and for individuals or groups or corporations or whathaveyou to create separate organizations for the organizations that own peers and own ordering nodes. This separation of organizations reflects the separation of the roles of the different nodes, even if ultimately the same Bank of America-type "organization" owns all of the CAs and ordering nodes and peers.
 
From a deployment perspective, this means you should have one CA (one root CA, at least, though you're free to create intermediate CAs if you want) that creates an organization that owns all of your ordering nodes. And you should have a separate CA that creates an organization that owns all of your peers. The decentralization of your ordering service will actually come through other people creating their own CAs and their own ordering organizations and then their own nodes and joining their nodes and your nodes together to form the ordering service. 
 
Hope that helps,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Jean-Gaël Dominé" <jgdomine@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 8:30 AM
 
Thanks for you quick reply.

I read this documentation a while ago and indeed some elements are present there:
I have a couple of questions though about some sentences I found:
Just like peers, ordering nodes belong to an organization. And similar to peers, a separate Certificate Authority (CA) should be used for each organization
I feel a bit confused about the notion of organization. I'll take a more concrete example to illustrate and check that I get it right.
Let's take two companies/organizations Org1 and Org2 that have 3 peers each.
Let's say that I want an orderer in each organization so that the ordering service is decentralized.

Then, from my understanding, comes the configtx.yaml file that introduces its own notion of organization since in it I'm going two define 4 organizations:
  • 2 for each orderer: Org1Ord and Org2Ord
  • 2 for each set of peers: Org1 and Org2
From the extract of the documentation, I understand that a dedicated CA should be in place for each organization, meaning I should have 4 CAs.
  • CAOrg1Ord to issue certificates/keys for Org1Ord
  • CAOrg1 to issue certificates/keys for Org2Ord
  • CAOrg2Ord to issue certificates/keys for Org1
  • CAOrg2 to issue certificates/keys for Org2
They could all be Root Certificate Authorities or CAOrgXOrd could be an intermediate of CAOrgX (or the other way around) but in any case the root certificate would be provided by the company in charge of it.

Does my illustration make sense ? Am I understanding things correctly?

Thank you
 
 


Re: To install chaincode, do you use source code or packaged cds file?

Gari Singh <garis@...>
 

You can actually specify the package as an argument to the command:

peer chaincode install [flags] pkg

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

-----fabric@... wrote: -----
To: fabric@...
From: "Yueming Xu"
Sent by: fabric@...
Date: 11/21/2019 12:47AM
Subject: [EXTERNAL] [Hyperledger Fabric] To install chaincode, do you use source code or packaged cds file?

When you use `peer chaincode install` to install chaincode from source code, it automatically package it as cds format and upload it to a peer node. But how would you install a cds file if you already packaged the code into cds format and got it signed by multiple orgs? Do you simply copy the signed cds file to the peer node using `kubectl cp` or `docker cp`? Guess that is why release 2.0 made improvement on this, but not sure if I misunderstood.


Re: #fabric #raft Orderers and organization, how to organize them? #fabric #raft

Jean-Gaël Dominé <jgdomine@...>
 

Thanks for you quick reply.

I read this documentation a while ago and indeed some elements are present there:
I have a couple of questions though about some sentences I found:
Just like peers, ordering nodes belong to an organization. And similar to peers, a separate Certificate Authority (CA) should be used for each organization
I feel a bit confused about the notion of organization. I'll take a more concrete example to illustrate and check that I get it right.
Let's take two companies/organizations Org1 and Org2 that have 3 peers each.
Let's say that I want an orderer in each organization so that the ordering service is decentralized.

Then, from my understanding, comes the configtx.yaml file that introduces its own notion of organization since in it I'm going two define 4 organizations:
  • 2 for each orderer: Org1Ord and Org2Ord
  • 2 for each set of peers: Org1 and Org2
From the extract of the documentation, I understand that a dedicated CA should be in place for each organization, meaning I should have 4 CAs.
  • CAOrg1Ord to issue certificates/keys for Org1Ord
  • CAOrg1 to issue certificates/keys for Org2Ord
  • CAOrg2Ord to issue certificates/keys for Org1
  • CAOrg2 to issue certificates/keys for Org2
They could all be Root Certificate Authorities or CAOrgXOrd could be an intermediate of CAOrgX (or the other way around) but in any case the root certificate would be provided by the company in charge of it.

Does my illustration make sense ? Am I understanding things correctly?

Thank you

4301 - 4320 of 11527