Manish Sethi

@zuowang I could not reproduce this with the latest source code. The panic stack that you pasted could be caused if state modification is being done concurrently - a related...

@corecode please see the comments below. As per my understanding, in our current model - the clients connected to a malicious NVPs or VPs would be affected in many scenarios....

@muralisrini - If we write 'nil' (or a zero-length byte array) to rocksdb, it's hard to differentiate during read time (unless, we do some special replacement for nil values -...

I did some investigation on this. Like rocksdb, protobuf also does not distinguishes between a nil and an empty bytes. It behaves even strangely. E.g., (a) A serialization-deserialization cycle using...

On a side note - the only thing that sounds strange with returning 'ok' along with the value is that, it typically makes sense only if we allow storing 'nil'...

I have submitted a PR https://github.com/hyperledger/fabric/pull/1471. In this PR, I have added the support for an empty array at the ledger side. Now, ledger behavior is a follows. - An...

Just to make it explicit, the flag would be required both way in the communication (setting the key and when getting the key).

No @muralisrini, protobuff does it other way around. It converts a field value from empty array into nil on the destination side. If you want to avoid any implementation specific...

Sorry I think that my previous message was not clear. What I meant to say was that on the sending side, if the value is 'nil' it can be left...

I think folks have a different view on this. @binhn and @mastersingh24 are not convinced for adding support for either nil/empty array. If we think that it is not important...