Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 24 January 2020
4:00pm to 5:00pm
(GMT+00:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

I have a question.

Can orderers read all the transactions passing through them even from the channels of which their organization is not a part of

If yes, then is there any solution to implement complete decentralization (by having one orderer per organization) + Privacy among the members of the channel. except for using private data.

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When:
Friday, 24 January 2020
6:00am to 7:00am
(GMT+00:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

--

Hyperledger Project Quarterly Update Due #tsc-project-update

When:
Thursday, 23 January 2020

Organizer:
community-architects@...

Description:
Please file a project status report for the TSC here:

https://wiki.hyperledger.org/display/TSC/Project+Status+Updates

I have a 3 Organisation (2 Normal Organization and 1 Orderer Organization) architecture on aws-eks. Each of the organizations has their own ca and tlsca. I have been able to generate the genesis block, the msp anchor transactions and the peers are able to join and create the channel as well as install the chaincode.

I am, however, facing issues when I instantiate the chaincode. The chaincode gets instantiated as seen from the docker-in-docker container. However, when I try to list the instantiated chaincode it does not come up.

I have gone through the following issues:

1. https://stackoverflow.com/questions/56735065/chaincode-is-instantiated-but-doesnt-appear-in-the-list-of-instantiated-codes
2. https://stackoverflow.com/questions/46045970/why-peer-chaincode-instantiate-execuate-many-times-successfully/46048140#46048140
3. https://stackoverflow.com/questions/46035198/why-chaincode-instantiate-success-but-query-failed

These issues hint at errors in ordering service endpoints. I am using raft with 3 nodes and these nodes are able to connect with each other. Apart from this, when I submit peer chaincode fetch command from the peer or the cli container for fetching the block from the orderering service (node 1, 2 or 3), I am able to retrieve the blocks.

However, when I try to list the chaincode it shows nothing.

Following are the logs that I'm getting on peer:

2020-01-23 17:30:42.834 UTC [ConnProducer] NewConnection -> DEBU be6c Creating a new connection

2020-01-23 17:30:42.837 UTC [grpc] infof -> DEBU be6d transport: loopyWriter.run returning. connection error: desc = "transport is closing"

2020-01-23 17:30:42.837 UTC [grpc] DialContext -> DEBU be6e parsed scheme: ""

2020-01-23 17:30:42.838 UTC [grpc] DialContext -> DEBU be6f scheme "" not registered, fallback to default scheme

2020-01-23 17:30:42.838 UTC [grpc] watcher -> DEBU be70 ccResolverWrapper: sending new addresses to cc: [{raft2orderer.<domain>.in:7050 0  <nil>}]

2020-01-23 17:30:42.838 UTC [grpc] switchBalancer -> DEBU be71 ClientConn switching balancer to "pick_first"

2020-01-23 17:30:42.839 UTC [grpc] HandleSubConnStateChange -> DEBU be72 pickfirstBalancer: HandleSubConnStateChange: 0xc000368a60, CONNECTING

2020-01-23 17:30:42.850 UTC [grpc] HandleSubConnStateChange -> DEBU be73 pickfirstBalancer: HandleSubConnStateChange: 0xc000368a60, READY

2020-01-23 17:30:42.850 UTC [ConnProducer] NewConnection -> DEBU be74 Connected to {raft2orderer.<domain>.in:7050 [OrdererMSP]}

2020-01-23 17:30:42.850 UTC [deliveryClient] connect -> DEBU be75 Connected to raft2orderer.<domain>.in:7050

2020-01-23 17:30:42.850 UTC [deliveryClient] connect -> DEBU be76 Establishing gRPC stream with raft2orderer.<domain>.in:7050 ...

2020-01-23 17:30:42.851 UTC [deliveryClient] afterConnect -> DEBU be77 Entering

2020-01-23 17:30:42.851 UTC [deliveryClient] RequestBlocks -> INFO be78 Starting deliver with block [1] for channel <channel_name>

2020-01-23 17:30:42.851 UTC [msp] GetDefaultSigningIdentity -> DEBU be79 Obtaining default signing identity

2020-01-23 17:30:42.851 UTC [msp] GetDefaultSigningIdentity -> DEBU be7a Obtaining default signing identity

2020-01-23 17:30:42.851 UTC [msp.identity] Sign -> DEBU be7b Sign: plaintext: 0AC1090A3B08051A0608C2B0A7F10522...01120D1A0B08FFFFFFFFFFFFFFFFFF01 

2020-01-23 17:30:42.851 UTC [msp.identity] Sign -> DEBU be7c Sign: digest: D8737137258DF932B21B3D16CC73C7A34FC652912476A90C14AAC8E3094E24D2 

2020-01-23 17:30:42.852 UTC [deliveryClient] afterConnect -> DEBU be7d Exiting

2020-01-23 17:30:42.853 UTC [blocksProvider] DeliverBlocks -> ERRO be7e [channel_name] Got error &{FORBIDDEN}

2020-01-23 17:30:43.884 UTC [gossip.comm] func1 -> DEBU be7f Got message: GossipMessage: tag:EMPTY hello:<nonce:9881102125581302162 msg_type:IDENTITY_MSG > , Envelope: 17 bytes, Signature: 0 bytes

Application Policies:

Application: &ApplicationDefaults

    Organizations:

    Policies:

        Readers:

            Type: ImplicitMeta

            Rule: "ANY Readers"

        Writers:

            Type: ImplicitMeta

            Rule: "ANY Writers"

        Admins:

            Type: ImplicitMeta

            Rule: "MAJORITY Admins"

    Capabilities:

        <<: *ApplicationCapabilities

Organizations:

Organizations:

    - &Orderer

        Name: Orderer

        ID: OrdererMSP

        MSPDir: ordererOrganizations/msp

        Policies:

            Readers:

                Type: Signature

                Rule: "OR('OrdererMSP.member')"

            Writers:

                Type: Signature

                Rule: "OR('OrdererMSP.member')"

            Admins:

                Type: Signature

                Rule: "OR('OrdererMSP.admin')"

    - &Orga

        Name: Orga

        ID: OrgaMSP

        MSPDir: peerOrganizations/orga.<domain>.in/msp

        Policies:

            Readers:

                Type: Signature

                Rule: "OR(‘OrgaMSP.admin', ‘OrgaMSP.peer', ‘OrgaMSP.client')"

            Writers:

                Type: Signature

                Rule: "OR(‘OrgaMSP.admin', ‘OrgaMSP.client')"

            Admins:

                Type: Signature

                Rule: "OR(‘OrgaMSP.admin')"

        AnchorPeers:

            - Host: peer0orga.<domain>.in

              Port: 7051

Capabilities:

Capabilities:

    Channel: &ChannelCapabilities

        V1_4_3: true

        V1_3: false

        V1_1: false

    Orderer: &OrdererCapabilities

        V1_4_2: true

        V1_1: false

    Application: &ApplicationCapabilities

        V1_4_2: true

        V1_3: false

        V1_2: false

        V1_1: false

I have also enabled the NodeOUs and set the config.yaml at appropriate MSPs except for the Orderer. From the logs it looks like peer is trying to fetch blocks from the orderer but the orderer gives back 403 error to the peer. The Channel/Readers policy states allow "ANY Readers" and the requesting identity peer/admin does have appropriate rights for this. 

Any ideas where I am getting this wrong?

If you plan on running a p2p node on the public internet, ideally it should be secured such that a firewall (other than possibly a simple port whitelist at the router) isn't needed.

If you believe a firewall is needed, put them all in a shared VPN or put each in a DMZ each with a public address and only allow the protocol ports (or ssh if you don't have a jump box in the DMZ). If you run a patchwork of NAT/forwarding hacks, you are inevitably going to run into DNS/TLS issues unless you are very careful.

In my experience, people generally overly rely on firewalls instead of addressing node security directly.

Apologies for the confusion in my wording,

I accidentally used firewall instead of router. Since the nodes are in different locations, its hard to access them without port forwarding them. From an initial glance, it seems like to build the network, I'll need to port forward all the nodes and make the publicly accessible to deploy them in different locations. I'm concerned about the security risks of doing so since anyone can access the nodes so long as they have the public address and port number.

Thanks for the quick responses,
Cavell Teng

Hello!

We will hold the documentation workgroup call this Friday, both Western and Eastern hemispheres.  A big welcome to everyone - another great turn out last week - thanks to everyone who attended!

The summary minutes for last week's meeting: https://wiki.hyperledger.org/display/fabric/Meetings

You can read all about the call at https://wiki.hyperledger.org/display/fabric/2020+01+17+DWG+Agenda It included an update on V2 from Pam and Joe, an overview of the ledger API from Matthew, Commercial paper network updates from Nik, and a discussion on rationalizing introductory material, also from Nik. You can catch up via the recording: https://wiki.hyperledger.org/display/fabric/Recordings

You'll see that there are lots of interesting items for this week: https://wiki.hyperledger.org/display/fabric/2020+01+24+DWG+Agenda
Please feel free to contribute using the wiki!

You can also help build next week's agenda: https://wiki.hyperledger.org/display/fabric/2020+01+31+DWG+Agenda

Really looking forward to more great work on Fabric documentation in 2020!

Pam, Anthony,  Joe, Nik

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Meeting 112A: Friday 24 Jan
                    1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time    

Meeting 113B: Friday 24 Jan
              1000 Central Daylight Time
                   1100 Eastern Daylight Time
                   0800 Pacific Daylight Time
                   1300 Brasil Time (BRT)
                   1600 Greenwich Mean Time
                   1700 Central European Time
                   1800 Moscow Standard Time

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



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



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

---

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com