Date   

Re: Orderer ledger pruning

Vitalii Demianets
 

The RFC draft has been submitted, here:
https://github.com/hyperledger/fabric-rfcs/pull/44

Please review!
--
// Vitalii Demianets @ norbloc AB


On Thu, Feb 25, 2021 at 1:06 PM Vitalii Demianets via lists.hyperledger.org <vitalii=norbloc.com@...> wrote:
Thank you all for the discussion and your input!
I think we now have a high-level understanding of what has to be done, looks simple enough.
Now we start the process of drafting the RFC. It will take some time though, as we want to familiarize ourselves with the internals of the code and the architecture from the Fabric dev point of view, but I hope it will not take more than 3-4 weeks.

--
// Vitalii Demianets @ norbloc AB


On Tue, Feb 23, 2021 at 3:56 PM Manish Sethi <manish.sethi@...> wrote:
In regards to changes to the blockstore, Jason is right that they would be very trivial. For the peers case, this function (https://github.com/hyperledger/fabric/blob/e0253ef0466e4e16364f3d1d3cc537ad9d8b1c4f/common/ledger/blkstorage/blockstore_provider.go#L103) does the job. For the orderer, I would expect an even simpler function (say, "BootstrapFromSnapshotInfo"), as there is nothing much other than the information of the initial state that needs to be supplied.

Thanks,
Manish

On Tue, Feb 23, 2021 at 6:27 AM Vitalii Demianets <vitalii@...> wrote:
Hi Jason!

>
> At a very high level I would suggest.
>
> 1) Modifying the channel participation API to allow specifying a minimum block sequence number to replicate to when joining.
> 2) Add a new pruning function to the channel participation API, which allows reconfiguring that minimum block sequence to a higher sequence number. (Implicitly existing channels would have this sequence set to 0).
> 3) Ignoring the system channel case, instead prereq-ing that channel participation API.
> 4) Introducing a new return status for the Deliver API indicating to peers and clients that the sequence is too old to help users understand why a block request is being rejected.  You'll actually notice that the APi already has the notion of 'OLDEST' as a seek position, as the earliest incarnations of the orderer ledger were RAM based and self-pruning.
>
> Perhaps Manish can weigh in here, but I believe the block storage code was already modified in the peer to handle starting from a later block.  The orderer uses a thin wrapping layer around the peer blockstore, so if not already exposed, exposing it should be relatively simple.

In the above description you do not mention snapshot at all. Do I understand this correctly that we basically do not need any of the peer snapshot functionality (private data collections, stateDB, transactions id list) to start an orderer from an arbitrary block? Basically from your description it follows that we only need to supply the latest config block and the desired start block number, and the orderer will happily start from that info? (given it is able to fetch the start block and other blocks on top of it)
In other words, for orderers the "snapshot" is only the latest config block + start block number?

>
> It might also be helpful to extend the block height discovery in the orderer block replication to discover the lowest block height as well, to detect when an orderer cannot catch up, though I'm not sure I would consider this a blocking item for an initial implementation.

Yes, in our use case the condition that we start the orderer from the block that can be discovered is satisfied, so it makes sense not to add this complexity from the start.
After all if an orderer is not able to find a block, it will be more or less obvious from the logs.

>
> I would argue that the most challenging aspect of implementing pruning at the orderer is an operational one.  The orderers are necessarily not involved in the peer snapshot operations, but, if the orderers prune to a block after the peer's most recent snapshot, onboarding will be broken until peers take a new snapshot.  In the worst case, if the orderer prunes before the blocks are disseminated to the peers, then data loss could occur.
>

We are going to keep several peers as "archiving" nodes, having all the history of blocks from block 0.
Will this solve the issue?

--
// Vitalii Demianets @ norbloc AB


Private Chaincode Lab - Tue, 03/23/2021 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Private Chaincode Lab

When:
Tuesday, 23 March 2021
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer:
bur@...

Description:
Two of the Hyperleger Labs projects (private data objects and private chain code) are collaborating to develop a "private smart contracts" capability.

Join Zoom Meeting https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Meeting ID: 518 494 7650 Passcode: 475869


Re: Problematic raspberry support

Matthew Sykes
 

Yeah, they’re all my commits so I’m very familiar with them. The change you’re referencing this time was required to get through the link phase in the alpine containers but the binaries in the containers still aren’t exercised.

As for clues, I don’t have any. If the binaries are going belly-up with a segfault, I’d start with that. It’s probably related to the musl libc used in the alpine container.


Re: Problematic raspberry support

Brett T Logan <development.brett@...>
 

While I hold that those changes do in fact make building Fabric for ARM64 possible, as Matt mentioned it's not officially supported. I can say that I've tested that change on PI4 and when done right with Go chaincode, that change in itself makes it possible to run Fabric on ARM64. There are many threads all over the place with people who have had success doing this.


On Tue, Mar 23, 2021 at 9:46 AM Nikos Karamolegkos <nkaram@...> wrote:

Sorry I misclick the commit link. The correct one is this. Also, this answer made me believe that raspberry pi4 is supported (even at an early stage). I can take a look on the problem but I need some clues. Where should I start?

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Problematic raspberry support

Nikos Karamolegkos
 

Sorry I misclick the commit link. The correct one is this. Also, this answer made me believe that raspberry pi4 is supported (even at an early stage). I can take a look on the problem but I need some clues. Where should I start?

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Problematic raspberry support

Matthew Sykes
 

Nikos, the Fabric team doesn’t do anything to support Raspberry Pi. The commit you’re referencing enables _development_ of Fabric on the new arm64 based M1 macs using the code in the core Fabric tree. That should not be interpreted as “added support for fabric in raspberry.”

We do not build and publish images for linux/arm64, we do not run CI on linux/arm64, we don’t exercise the samples and test networks on lnux/arm64, and we certainly don’t do anything with Java chaincode on linux/arm64. Since we don’t exercise the paths, it’s not surprising that you’re running into difficulties.

If the containers are exiting with a 139, it’s dying with a segmentation fault. That means it’s a bad binary. Given everything above, that’s not a huge surprise. If you end up finding the cause of these problems and wish to deliver a fix upstream, we’d be happy to work with you.


Problematic raspberry support

Nikos Karamolegkos
 

In latest commits you added support for fabric in raspberry as described here. I am trying so many days to build fabric-chaincode-java without success (the help in the chats or the list was almost zero). So I decide to check the test-network in GO. Thus the steps are:

1) In latest fabric folder: make docker, make native
2) I ignored the fabric-ca
3) copy bin/ from fabric folder to samples folder, same for the config/
4) In latest fabric-samples/test-network folder:  ./network down, ./network up

Starting nodes with CLI timeout of '5' tries and CLI delay of '3' seconds and using database 'leveldb' with crypto from 'cryptogen'
LOCAL_VERSION=2.4.0
DOCKER_IMAGE_VERSION=
Local fabric binaries and docker images are out of  sync. This may cause problems.
/home/ubuntu/fabric-samples/test-network/../bin/cryptogen
Generating certificates using cryptogen tool
Creating Org1 Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output=organizations
org1.example.com
+ res=0
Creating Org2 Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-org2.yaml --output=organizations
org2.example.com
+ res=0
Creating Orderer Org Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-orderer.yaml --output=organizations
+ res=0
Generating CCP files for Org1 and Org2
Creating network "fabric_test" with the default driver
Creating volume "docker_orderer.example.com" with default driver
Creating volume "docker_peer0.org1.example.com" with default driver
Creating volume "docker_peer0.org2.example.com" with default driver
Creating orderer.example.com    ... done
Creating peer0.org2.example.com ... done
Creating peer0.org1.example.com ... done
Creating cli                    ... done
CONTAINER ID        IMAGE                               COMMAND             CREATED             STATUS                       PORTS                                            NAMES
fb943546dc4f        hyperledger/fabric-tools:latest     "/bin/bash"         3 seconds ago       Up Less than a second                                                         cli
d0a9bed586c3        hyperledger/fabric-peer:latest      "peer node start"   6 seconds ago       Exited (139) 2 seconds ago                                                    peer0.org1.example.com
a2bd075ecac5        hyperledger/fabric-orderer:latest   "orderer"           6 seconds ago       Up 2 seconds                 0.0.0.0:7050->7050/tcp, 0.0.0.0:7053->7053/tcp   orderer.example.com
67f4a76afb85        hyperledger/fabric-peer:latest      "peer node start"   6 seconds ago       Exited (139) 1 second ago                                                     peer0.org2.example.com

DOCKER_IMAGE_VERSION is empty, and the peer containers are exiting with code 139.

Is this a bug?

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


docker run to extract images version

Nikos Karamolegkos
 

Hello,
When I am running docker run --rm hyperledger/fabric-peer:latest peer version the command does not return anything. Why?
The command docker run --rm hyperledger/fabric-orderer:latest orderer version returns the versions as 
orderer:
 Version: 2.2.2
 Commit SHA: bebb75f
 Go version: go1.14.12
 OS/Arch: linux/arm64

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Rename default branch to 'main' in Fabric repositories

David Enyeart
 

The switch to 'main' is complete in all Fabric repositories. Please use the instructions below to switch any local development environments over to 'main'.


Dave Enyeart

David Enyeart---03/15/2021 01:52:34 PM---Based on industry and Hyperledger recommendations, we will be switching default branch from 'master'

From: David Enyeart/Durham/IBM
To: fabric <fabric@...>
Date: 03/15/2021 01:52 PM
Subject: Rename default branch to 'main' in Fabric repositories




Based on industry and Hyperledger recommendations, we will be switching default branch from 'master' to 'main' on all Fabric repositories.

I plan to switch all Fabric repositories on Friday March 19th. Doing them all the same day will limit any temporary link breakages across the repositories and docs. Everything should be in working order by Monday.

A few of the repositories have been done already. I've tested the process on Fabric CA repository since it follows similar CI and doc approach as Fabric.

Here is the process that I will be following for each repository:
- Use the new Github feature to rename default branch. This automatically re-targets PRs to "main" and updates branch protections rules.
- PR to update master references in CI pipelines, docs, etc
- Update default branch in Azure Pipelines

Once it is done for a repository, each developer that has a local fork will need to perform the following steps to update their local environment, push the main branch to their fork and associate with local main branch, and ensure local main is rebased on the upstream main branch:
git checkout master
git branch -m master main
git fetch origin
git push origin main
git branch -u origin/main main
git fetch upstream
git rebase upstream/main

The steps assume you are following the Github fork and upstream remote instructions here:
https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html

Please let us know if you have any other suggestions or comments.


Thank you,

Dave Enyeart



Re: Hyperledger Fabric 2.2 - Unable to connect to the discovered orderer #docker #docker-compose #fabric

earl1a@...
 

I have actually solved the problem by adding the DNS (org.example.com, peer0.org1.example.com, etc) in the application's /etc/hosts.

Thanks!


Re: Hyperledger Fabric 2.2 - Unable to connect to the discovered orderer #docker #docker-compose #fabric

Chris Gabriel
 

Did you configure ingress on your k8s cluster? Also, if you have eliminated that you may have a misconfiguration of your connection profile. 


On Mar 19, 2021, at 9:07 PM, stpcmferiwbtnundnx@... wrote:

Hi, can anyone help me solve this? I've been trying to find a way to connect to the orderer but to no avail.

https://stackoverflow.com/questions/66701510/hyperledger-fabric-2-2-unable-to-connect-to-the-discovered-orderer

I have a cloud VM that runs my Hyperledger Fabric network (i.e., inside the VM are docker containers that run the peers, orderer, CAs, couchdbs). I also have a node.js application on Kubernetes (in the same VPC) that connects to the VM. However, whenever the application tries to connect to the blockchain via org1's connection profile, I get this error:

```
2021-03-16T02:28:46.320Z - error: [ServiceEndpoint]: Error: Failed to connect before the deadline on Committer- name: orderer.example.com:7050, url:grpcs://orderer.example.com:7050, connected:false, connectAttempted:true
2021-03-16T02:28:46.320Z - error: [ServiceEndpoint]: waitForReady - Failed to connect to remote gRPC server orderer.example.com:7050 url:grpcs://orderer.example.com:7050 timeout:3000
2021-03-16T02:28:46.320Z - error: [DiscoveryService]: _buildOrderer[mychannel] - Unable to connect to the discovered orderer orderer.example.com:7050 due to Error: Failed to connect before the deadline on Committer- name: orderer.example.com:7050, url:grpcs://orderer.example.com:7050, connected:false, connectAttempted:true
```

More details:
- In the application, I use this to connect:
`await gateway.connect(connectionProfile, {discovery: { enabled: true, asLocalhost: false}});`

- Before I changed `CORE_PEER_GOSSIP_BOOTSTRAP` and `CORE_PEER_GOSSIP_EXTERNALENDPOINT` from `peer.org.example.com` to the VM's internal IP address, it also produced the same errors for all discovered peers in the network *(please see `docker-compose-test-net.yaml` below)*.

- When I changed `ORDERER_GENERAL_LISTENADDRESS` from `0.0.0.0` to the VM's IP address, I couldn't build the network successfully.

- `docker-compose-test-net.yaml`:
```
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

version: '2'

volumes:
  orderer.example.com:
  peer0.org1.example.com:
  peer1.org1.example.com:
  peer0.org2.example.com:
  peer1.org2.example.com:

networks:
  test:

services:

  orderer.example.com:
    container_name: orderer.example.com
    image: hyperledger/fabric-orderer:$IMAGE_TAG
    environment:
      - FABRIC_LOGGING_SPEC=DEBUG
      - ORDERER_GENERAL_LISTENADDRESS=0.0.0.0
      - ORDERER_GENERAL_LISTENPORT=7050
      - ORDERER_GENERAL_GENESISMETHOD=file
      - ORDERER_GENERAL_GENESISFILE=/var/hyperledger/orderer/orderer.genesis.block
      - ORDERER_GENERAL_LOCALMSPID=OrdererMSP
      - ORDERER_GENERAL_LOCALMSPDIR=/var/hyperledger/orderer/msp
      # enabled TLS
      - ORDERER_GENERAL_TLS_ENABLED=true
      - ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key
      - ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt
      - ORDERER_GENERAL_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
      - ORDERER_KAFKA_TOPIC_REPLICATIONFACTOR=1
      - ORDERER_KAFKA_VERBOSE=true
      - ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt
      - ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key
      - ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
    working_dir: /opt/gopath/src/github.com/hyperledger/fabric
    command: orderer
    volumes:
        - ../system-genesis-block/genesis.block:/var/hyperledger/orderer/orderer.genesis.block
        - ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp:/var/hyperledger/orderer/msp
        - ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/:/var/hyperledger/orderer/tls
        - orderer.example.com:/var/hyperledger/production/orderer
    ports:
      - 7050:7050
    networks:
      - test

  peer0.org1.example.com:
    container_name: peer0.org1.example.com
    image: hyperledger/fabric-peer:$IMAGE_TAG
    environment:
      #Generic peer variables
      - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
      # the following setting starts chaincode containers on the same
      # bridge network as the peers
      # https://docs.docker.com/compose/networking/
      - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_test
      - FABRIC_LOGGING_SPEC=INFO
      # - FABRIC_LOGGING_SPEC=DEBUG
      - CORE_PEER_TLS_ENABLED=true
      - CORE_PEER_PROFILE_ENABLED=true
      - CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt
      - CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key
      - CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
      # Peer specific variabes
      - CORE_PEER_ID=peer0.org1.example.com
      # - CORE_PEER_ADDRESS=peer0.org1.example.com:7051
      - CORE_PEER_ADDRESS=<VM's IP Address>:7051
      - CORE_PEER_LISTENADDRESS=0.0.0.0:7051
      - CORE_PEER_CHAINCODEADDRESS=peer0.org1.example.com:7052
      - CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7052
      # - CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051
      - CORE_PEER_GOSSIP_BOOTSTRAP=<VM's IP Address>:7051
      # - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.example.com:7051
      - CORE_PEER_GOSSIP_EXTERNALENDPOINT=<VM's IP Address>:7051
      - CORE_PEER_LOCALMSPID=Org1MSP
    volumes:
        - /var/run/:/host/var/run/
        - ../organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp
        - ../organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls:/etc/hyperledger/fabric/tls
        - peer0.org1.example.com:/var/hyperledger/production
    working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
    command: peer node start
    ports:
      - 7051:7051
    networks:
      - test

  peer1.org1.example.com:
    container_name: peer1.org1.example.com
    image: hyperledger/fabric-peer:$IMAGE_TAG
    environment:
      #Generic peer variables
      - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
      # the following setting starts chaincode containers on the same
      # bridge network as the peers
      # https://docs.docker.com/compose/networking/
      - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_test
      - FABRIC_LOGGING_SPEC=INFO
      # - FABRIC_LOGGING_SPEC=DEBUG
      - CORE_PEER_TLS_ENABLED=true
      - CORE_PEER_PROFILE_ENABLED=true
      - CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt
      - CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key
      - CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
      # Peer specific variabes
      - CORE_PEER_ID=peer1.org1.example.com
      # - CORE_PEER_ADDRESS=peer1.org1.example.com:7055
      - CORE_PEER_ADDRESS=<VM's IP Address>:7055
      - CORE_PEER_LISTENADDRESS=0.0.0.0:7055
      - CORE_PEER_CHAINCODEADDRESS=peer1.org1.example.com:7056
      - CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7056
      # - CORE_PEER_GOSSIP_BOOTSTRAP=peer1.org1.example.com:7055
      - CORE_PEER_GOSSIP_BOOTSTRAP=<VM's IP Address>:7055
      # - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.example.com:7055
      - CORE_PEER_GOSSIP_EXTERNALENDPOINT=<VM's IP Address>:7055
      - CORE_PEER_LOCALMSPID=Org1MSP
    volumes:
        - /var/run/:/host/var/run/
        - ../organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/msp:/etc/hyperledger/fabric/msp
        - ../organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls:/etc/hyperledger/fabric/tls
        - peer1.org1.example.com:/var/hyperledger/production
    working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
    command: peer node start
    ports:
      - 7055:7055
    networks:
      - test

  ... same goes for peer0.org2.example.com and peer1.org2.example.com ...
```

Question: What should my configuration be so that the discovery service can successfully locate the orderer in my VM?


Hyperledger Fabric 2.2 - Unable to connect to the discovered orderer #docker #docker-compose #fabric

stpcmferiwbtnundnx@...
 

Hi, can anyone help me solve this? I've been trying to find a way to connect to the orderer but to no avail.

https://stackoverflow.com/questions/66701510/hyperledger-fabric-2-2-unable-to-connect-to-the-discovered-orderer

I have a cloud VM that runs my Hyperledger Fabric network (i.e., inside the VM are docker containers that run the peers, orderer, CAs, couchdbs). I also have a node.js application on Kubernetes (in the same VPC) that connects to the VM. However, whenever the application tries to connect to the blockchain via org1's connection profile, I get this error:

```
2021-03-16T02:28:46.320Z - error: [ServiceEndpoint]: Error: Failed to connect before the deadline on Committer- name: orderer.example.com:7050, url:grpcs://orderer.example.com:7050, connected:false, connectAttempted:true
2021-03-16T02:28:46.320Z - error: [ServiceEndpoint]: waitForReady - Failed to connect to remote gRPC server orderer.example.com:7050 url:grpcs://orderer.example.com:7050 timeout:3000
2021-03-16T02:28:46.320Z - error: [DiscoveryService]: _buildOrderer[mychannel] - Unable to connect to the discovered orderer orderer.example.com:7050 due to Error: Failed to connect before the deadline on Committer- name: orderer.example.com:7050, url:grpcs://orderer.example.com:7050, connected:false, connectAttempted:true
```

More details:
- In the application, I use this to connect:
`await gateway.connect(connectionProfile, {discovery: { enabled: true, asLocalhost: false}});`

- Before I changed `CORE_PEER_GOSSIP_BOOTSTRAP` and `CORE_PEER_GOSSIP_EXTERNALENDPOINT` from `peer.org.example.com` to the VM's internal IP address, it also produced the same errors for all discovered peers in the network *(please see `docker-compose-test-net.yaml` below)*.

- When I changed `ORDERER_GENERAL_LISTENADDRESS` from `0.0.0.0` to the VM's IP address, I couldn't build the network successfully.

- `docker-compose-test-net.yaml`:
```
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

version: '2'

volumes:
  orderer.example.com:
  peer0.org1.example.com:
  peer1.org1.example.com:
  peer0.org2.example.com:
  peer1.org2.example.com:

networks:
  test:

services:

  orderer.example.com:
    container_name: orderer.example.com
    image: hyperledger/fabric-orderer:$IMAGE_TAG
    environment:
      - FABRIC_LOGGING_SPEC=DEBUG
      - ORDERER_GENERAL_LISTENADDRESS=0.0.0.0
      - ORDERER_GENERAL_LISTENPORT=7050
      - ORDERER_GENERAL_GENESISMETHOD=file
      - ORDERER_GENERAL_GENESISFILE=/var/hyperledger/orderer/orderer.genesis.block
      - ORDERER_GENERAL_LOCALMSPID=OrdererMSP
      - ORDERER_GENERAL_LOCALMSPDIR=/var/hyperledger/orderer/msp
      # enabled TLS
      - ORDERER_GENERAL_TLS_ENABLED=true
      - ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key
      - ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt
      - ORDERER_GENERAL_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
      - ORDERER_KAFKA_TOPIC_REPLICATIONFACTOR=1
      - ORDERER_KAFKA_VERBOSE=true
      - ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt
      - ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key
      - ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
    working_dir: /opt/gopath/src/github.com/hyperledger/fabric
    command: orderer
    volumes:
        - ../system-genesis-block/genesis.block:/var/hyperledger/orderer/orderer.genesis.block
        - ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp:/var/hyperledger/orderer/msp
        - ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/:/var/hyperledger/orderer/tls
        - orderer.example.com:/var/hyperledger/production/orderer
    ports:
      - 7050:7050
    networks:
      - test

  peer0.org1.example.com:
    container_name: peer0.org1.example.com
    image: hyperledger/fabric-peer:$IMAGE_TAG
    environment:
      #Generic peer variables
      - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
      # the following setting starts chaincode containers on the same
      # bridge network as the peers
      # https://docs.docker.com/compose/networking/
      - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_test
      - FABRIC_LOGGING_SPEC=INFO
      # - FABRIC_LOGGING_SPEC=DEBUG
      - CORE_PEER_TLS_ENABLED=true
      - CORE_PEER_PROFILE_ENABLED=true
      - CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt
      - CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key
      - CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
      # Peer specific variabes
      - CORE_PEER_ID=peer0.org1.example.com
      # - CORE_PEER_ADDRESS=peer0.org1.example.com:7051
      - CORE_PEER_ADDRESS=<VM's IP Address>:7051
      - CORE_PEER_LISTENADDRESS=0.0.0.0:7051
      - CORE_PEER_CHAINCODEADDRESS=peer0.org1.example.com:7052
      - CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7052
      # - CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051
      - CORE_PEER_GOSSIP_BOOTSTRAP=<VM's IP Address>:7051
      # - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.example.com:7051
      - CORE_PEER_GOSSIP_EXTERNALENDPOINT=<VM's IP Address>:7051
      - CORE_PEER_LOCALMSPID=Org1MSP
    volumes:
        - /var/run/:/host/var/run/
        - ../organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp
        - ../organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls:/etc/hyperledger/fabric/tls
        - peer0.org1.example.com:/var/hyperledger/production
    working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
    command: peer node start
    ports:
      - 7051:7051
    networks:
      - test

  peer1.org1.example.com:
    container_name: peer1.org1.example.com
    image: hyperledger/fabric-peer:$IMAGE_TAG
    environment:
      #Generic peer variables
      - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
      # the following setting starts chaincode containers on the same
      # bridge network as the peers
      # https://docs.docker.com/compose/networking/
      - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_test
      - FABRIC_LOGGING_SPEC=INFO
      # - FABRIC_LOGGING_SPEC=DEBUG
      - CORE_PEER_TLS_ENABLED=true
      - CORE_PEER_PROFILE_ENABLED=true
      - CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt
      - CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key
      - CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
      # Peer specific variabes
      - CORE_PEER_ID=peer1.org1.example.com
      # - CORE_PEER_ADDRESS=peer1.org1.example.com:7055
      - CORE_PEER_ADDRESS=<VM's IP Address>:7055
      - CORE_PEER_LISTENADDRESS=0.0.0.0:7055
      - CORE_PEER_CHAINCODEADDRESS=peer1.org1.example.com:7056
      - CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7056
      # - CORE_PEER_GOSSIP_BOOTSTRAP=peer1.org1.example.com:7055
      - CORE_PEER_GOSSIP_BOOTSTRAP=<VM's IP Address>:7055
      # - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.example.com:7055
      - CORE_PEER_GOSSIP_EXTERNALENDPOINT=<VM's IP Address>:7055
      - CORE_PEER_LOCALMSPID=Org1MSP
    volumes:
        - /var/run/:/host/var/run/
        - ../organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/msp:/etc/hyperledger/fabric/msp
        - ../organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls:/etc/hyperledger/fabric/tls
        - peer1.org1.example.com:/var/hyperledger/production
    working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
    command: peer node start
    ports:
      - 7055:7055
    networks:
      - test

  ... same goes for peer0.org2.example.com and peer1.org2.example.com ...
```

Question: What should my configuration be so that the discovery service can successfully locate the orderer in my VM?


HSM in a wallet of GO application #hsm #fabric-sdk-go

agustincharry@...
 

Hello.
I have a question about consuming an HSM from GO SDK to use in a wallet.
The project is a GO application which connects to the Blockchain using a wallet to invoke chaincode functions. Today, this wallet stores the public certificate and private key, but the idea is that the HSM stores the private key of the wallet.
 
In resume, the project has the next structure:
 

wallet, err = gateway.NewFileSystemWallet(walletPath)
err = PopulateWallet(wallet, orgMSPId, walletIdentityLabel, userCertPath, privateKeyPath)
gw, err = gateway.Connect(
    gateway.WithConfig(config.FromFile(filepath.Clean(conectionProfileFilePath))),
    gateway.WithIdentity(wallet, walletIdentityLabel),
)
network, err := gw.GetNetwork(channelName)
contract = network.GetContract(contractName)
result, err := contract.EvaluateTransaction("")
 
 
But this uses the Fabric-CA, in my project we are using ACM PCA to manage public certificates and CloudHSM to manage private keys, both services are of AWS.
 
Are there any examples available that use an HSM without Fabric-ca, please? Or can you guide me on how to implement this, please?


Re: Install fabric-chaincode-java to raspberry 4 #fabric-chaincode #fabric-questions

Nikos Karamolegkos
 

I decided to apply a workaround and set as comments the part of the test creating this problem (Will this be a problem?). I just want to see what is coming next. So, the next problem is that adoptopenjdk/openjdk11:jdk-11.0.4_11-alpine used by the Dockerfile does not exist for arm64. So the error is
> Task :fabric-chaincode-docker:buildImage
Step 1/38 : FROM adoptopenjdk/openjdk11:jdk-11.0.4_11-alpine as builder

> Task :fabric-chaincode-docker:buildImage FAILED
:fabric-chaincode-docker:buildImage (Thread[Execution worker for ':' Thread 2,5,main]) completed. Took 5.526 secs.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':fabric-chaincode-docker:buildImage'.
> Could not build image: no matching manifest for linux/arm64/v8 in the manifest list entries

Can I replace it with something else?


Fabric Contributor Meeting - Wed, 03/17/2021 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Fabric Contributor Meeting

When:
Wednesday, 17 March 2021
9:00am to 10:00am
(GMT-04:00) America/New York

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer:
enyeart@...

Description:
For meeting agendas, recordings, and more details, see https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

Join Zoom Meeting
https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09
 
Meeting ID: 518 494 7650
Passcode: 475869


Fabric Contributor Meeting - March 17, 2021 - any agenda topics?

David Enyeart
 

Hyperledger Fabric Contributor Meeting

When: Every other Wednesday 9am US Eastern, 13:00 UTC (during US daylight savings time)

Where: https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Agendas and Recordings: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

----------------------------------------------------------------------------------------------------

Agenda for March 17, 2021
There are no big agenda topics scheduled for this week yet.
We will do a quick update on the transition from 'master' to 'main' as the default branch.
Feel free to propose an agenda item!

For March 31 meeting, an update on the Fabric Gateway is planned.


Get private data collection's key history #hyperledger-fabric #fabric-sdk-node #fabric-questions

luciano.pereira@...
 

Is there any way to get a private data collection's history for a particular key in Hyperledger Fabric 2.3? We are using Nodejs for our chaincode implementation

I read about a workaround here, which consists of writing to the public state when updating the private data, and then use the normal getHistoryForKey method to retrieve the transactions where the private data was modified.

  1. In this case, how could we then access the private data from these transactions Ids inside the chaincode?
  2. Is there a different way of doing this right now?

Thanks,

Luciano


Private Chaincode Lab - Tue, 03/16/2021 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Private Chaincode Lab

When:
Tuesday, 16 March 2021
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer:
bur@...

Description:
Two of the Hyperleger Labs projects (private data objects and private chain code) are collaborating to develop a "private smart contracts" capability.

Join Zoom Meeting https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Meeting ID: 518 494 7650 Passcode: 475869


Re: Rename default branch to 'main' in Fabric repositories

Jay Guo
 

Okay, thanks!

On Tue, Mar 16, 2021 at 20:54 David Enyeart <enyeart@...> wrote:

The github rename function will automatically re-target open PRs to main and automatically redirect master web traffic to main.


Dave Enyeart

"Jay Guo" ---03/16/2021 07:34:20 AM---Hi Dave, some minor questions here: 1. will outstanding PRs be automatically updated to re-target ma

From: "Jay Guo" <guojiannan1101@...>
To: David Enyeart <enyeart@...>
Cc: fabric <fabric@...>
Date: 03/16/2021 07:34 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Rename default branch to 'main' in Fabric repositories
Sent by: fabric@...





Hi Dave, some minor questions here: 1. will outstanding PRs be automatically updated to re-target main? 2. will visits to master branch be redirected automatically to main? (I suppose github should support this via renaming feature?) ‍‍‍‍‍‍


Hi Dave, some minor questions here:

1. will outstanding PRs be automatically updated to re-target main?
2. will visits to master branch be redirected automatically to main? (I suppose github should support this via renaming feature?)
3. If the answer to 2 is yes, then I suppose other projects that pull Fabric master during CI should not be affected?

Thanks!

On Tue, Mar 16, 2021 at 1:52 AM David Enyeart <enyeart@...> wrote:

    Based on industry and Hyperledger recommendations, we will be switching default branch from 'master' to 'main' on all Fabric repositories.

    I plan to switch all Fabric repositories on Friday March 19th. Doing them all the same day will limit any temporary link breakages across the repositories and docs. Everything should be in working order by Monday.

    A few of the repositories have been done already. I've tested the process on Fabric CA repository since it follows similar CI and doc approach as Fabric.

    Here is the process that I will be following for each repository:
    - Use the new Github feature to rename default branch. This automatically re-targets PRs to "main" and updates branch protections rules.
    - PR to update master references in CI pipelines, docs, etc
    - Update default branch in Azure Pipelines

    Once it is done for a repository, each developer that has a local fork will need to perform the following steps to update their local environment, push the main branch to their fork and associate with local main branch, and ensure local main is rebased on the upstream main branch:
    git checkout master
    git branch -m master main
    git fetch origin
    git push origin main
    git branch -u origin/main main
    git fetch upstream
    git rebase upstream/main

    The steps assume you are following the Github fork and upstream remote instructions here:
    https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html

    Please let us know if you have any other suggestions or comments.


    Thank you,

    Dave Enyeart





Re: Rename default branch to 'main' in Fabric repositories

David Enyeart
 

The github rename function will automatically re-target open PRs to main and automatically redirect master web traffic to main.


Dave Enyeart

"Jay Guo" ---03/16/2021 07:34:20 AM---Hi Dave, some minor questions here: 1. will outstanding PRs be automatically updated to re-target ma

From: "Jay Guo" <guojiannan1101@...>
To: David Enyeart <enyeart@...>
Cc: fabric <fabric@...>
Date: 03/16/2021 07:34 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Rename default branch to 'main' in Fabric repositories
Sent by: fabric@...





Hi Dave, some minor questions here: 1. will outstanding PRs be automatically updated to re-target main? 2. will visits to master branch be redirected automatically to main? (I suppose github should support this via renaming feature?) ‍‍‍‍‍‍
Hi Dave, some minor questions here:

1. will outstanding PRs be automatically updated to re-target main?
2. will visits to master branch be redirected automatically to main? (I suppose github should support this via renaming feature?)
3. If the answer to 2 is yes, then I suppose other projects that pull Fabric master during CI should not be affected?

Thanks!

On Tue, Mar 16, 2021 at 1:52 AM David Enyeart <enyeart@...> wrote:
    Based on industry and Hyperledger recommendations, we will be switching default branch from 'master' to 'main' on all Fabric repositories.

    I plan to switch all Fabric repositories on Friday March 19th. Doing them all the same day will limit any temporary link breakages across the repositories and docs. Everything should be in working order by Monday.

    A few of the repositories have been done already. I've tested the process on Fabric CA repository since it follows similar CI and doc approach as Fabric.

    Here is the process that I will be following for each repository:
    - Use the new Github feature to rename default branch. This automatically re-targets PRs to "main" and updates branch protections rules.
    - PR to update master references in CI pipelines, docs, etc
    - Update default branch in Azure Pipelines

    Once it is done for a repository, each developer that has a local fork will need to perform the following steps to update their local environment, push the main branch to their fork and associate with local main branch, and ensure local main is rebased on the upstream main branch:
    git checkout master
    git branch -m master main
    git fetch origin
    git push origin main
    git branch -u origin/main main
    git fetch upstream
    git rebase upstream/main

    The steps assume you are following the Github fork and upstream remote instructions here:
    https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html

    Please let us know if you have any other suggestions or comments.


    Thank you,

    Dave Enyeart




581 - 600 of 10283