The first set of fixes on v2.0 is now available. See release notes for details: https://github.com/hyperledger/fabric/releases/tag/v2.0.1 We expect the next quarterly release v2.1 to be available by

Hi - the world state is a set of key-value pairs - the value can be whatever data format you wish. Marshalling these is part of the job of the client applications. Regards, Matthew. Matthew B

Hi, I had two questions. I wanted to know if it would be possible to define an asset which is self-referential. Also when defining assets such as these, do they work in the traditional way of

in what aspect you mean hashing the world state? 发件人: fabric@... <fabric@...> 代表 qwert limframe <qwertlimframe@...> 发送时间: 2020年2月27日 0:00 收件人: hyperledger-fabric@...

Is the World State Hashed? If yes, though world state is a constantly changing database. why is it hashed?

A few more fixes got merged in the last week, so we went ahead and released Fabric and Fabric CA v1.4.6

Before you blame it to fabric-ca-client, please help to re-test it again with `fabric-ca-client` command tool. 发件人: fabric@... <fabric@...> 代表 chauhan.kartik25@...

I see. Then maybe orderer should accept a version it doesn’t recognizeonly when It’s higher than orderer’s binary version some–force flag or similar used This way, at least you can

Unfortunately, this is "working as designed". We could revisit the validation that ordering does, but the original capabilities concept was to allow independent management of the orderers and peers.

Hakan, I understand your concern. However, the only way for the ordering service to know about the newest application capability levels is to keep it at the latest binary version. A 1.3 ordering

Hi Joe, Thanks for the clarification. So, there is no way of reverting back from that state except restoring from a backup. I guess it’s a good idea to guard against this at orderer as

As it says in our conceptual documentation on capabilities: Take caution when specifying or modifying an application capability. Because the ordering service does not validate that the capability

Sure, they are attached. From: Yacov Manevich <YACOVM@...> Sent: Monday, 24 February 2020 12:56 To: Eryargi, Hakan <hakan.eryargi@...> Cc: fabric@... Subject: [External] RE: [Hyperledger Fabric]

Can you attach logs? From: "Eryargi, Hakanvia Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...> To: Yacov Manevich <YACOVM@...> Cc: fabric@... Date: 02/24/2020 01:51

Yup exactly that happened. I made a config update for application capability for version V1_4_3, orderers accepted the block and peers crashed. Below json path to be more

Did you manage to reach a situation wherethe orderers accepted the block but the peers didn't? Were the orderersat a higher software version than the peers? From: "Eryargi, Hakanvia

Hi, Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup) For example Application capability V1_4_3 does not exist, and

The first part works, then the final commit fails (page 202 of the Fabric 2.0 manual) - peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com

Hyperledger Fabric Documentation Workgroup call - Western hemisphere When: Friday, 21 February 2020 4:00pm to 5:00pm (GMT+00:00)

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere When: Friday, 21 February 2020, 4:00pm to 5:00pm, (GMT+00:00)