We have chosen not to add version tags to the modules because they tend to evolve compatibly and are mostly disconnected from the fabric releases. For example, if you pull any version of fabric-chainc

It's less about a race and more about consistency. (A race can cause an inconsistency.) Imagine that when you run the contract on peer one, the sequence observed by the ledger is ["data1", "data2"]; o

#fabric-chaincode #fabric-questions

You'll need to build with "GO_TAGS=noplugin" to disable the plugins when building the docker images. Should be as simple as 'make clean-all docker native GO_TAGS=noplugin'. You can verify the peer bui

I had some time this morning so I played around with the peer image created on linux/aarch64 (linux/arm64). To get to the bottom of why the program was dying during initialization, I commented out all

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 contain

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.

As of v2 of Fabric, the packages we expect applications and chaincode to build and link against have been extracted to `hyperledger/fabric-chaincode-go` and `hyperledger/fabric-protos-go`. Fabric is n

#fabric #fabric-chaincode

EOF - End of File. It's likely indicating the other end of the connection has closed during the handshake, that a network error occurred, or that a record header with an incorrect length was received.

#fabric #tls #ssl #fabric-questions

I have created a proposal for JWT based authentication that can be used with the channel participation API. The goal is enable the use of MSP identities on the API and remove the requirement for mutua

#rfc

Standard error (and only standard error) is redirected from the external builder to the peer's logs. This is already done at info level. The logger is named `chaincode.externalbuilder.<builder-name>`

#fabric-questions #externalbuilders #fabric

Fabric uses protocol buffers for messages and persistence and gRPC+protobuf for inter-process communication. When a proposal message is sent to the peer, several copies of the proposal message end up

Unfortunately, the traceback doesn't really shed any light on the situation as almost all errors invoking chaincode will show the same stack. Did you set 'tls_required' and 'client_auth_required' to t

The chaincode server is your server; it's completely up to you how you want to manage and monitor it. The peer surfaces metrics for chaincode that cover most invocation scenarios (server or client, ex

The peer does not perform any health or liveness checks and only enables keep alive pings on the gRPC connection. The first time the chaincode is invoked, the peer creates a grpc connection, connects

We don't publish images for ARM but it's very easy to build fabric from source. And yes, it is possible to run Fabric on a Pi but only on 64 bit systems as one of the crypto packages used in Fabric on

#fabric

The value is base64 encoded, not encrypted. The value is represented as bytes and base64 is how bytes are represented in JSON. Your value is decoded as: {"class":"aipay.payment","key":"\"0004_workstat

#fabric-sdk-node #database #fabric-questions

When you want to prevent unauthenticated usage of the operations health check endpoint. The metrics and logspec endpoints always require client certificate authentication when TLS is enabled. https://

#ssl

Windows is not a supported platform for running the peer node natively. While it may work, it is not tested. We do, however, generally support the cli. Within Fabric, we try very hard to keep the prod

#externalbuilders

In my experience, Jira issues age more like a weathered parking lot than a fine wine.... The excessive times are most easily observed when running with the race detector enabled and this is how we run

It's likely a bug. The gossip code is sitting in a select where one case is receiving from an error channel and the other is receiving a message. [1] If, however, an error occurs when converting an en