davidkel
commented
2 years ago Of course this will have an impact on the performance of the chaincode so we should perhaps create a separate fixed-asset version of this again not based on the contract api as it will add overhead
In fabric it's important that when serializing an object to a string that it results an a byte exact stream when run on different peers as part of the endorsement process. There are 2 points in a chaincode where this is important
The contract api is responsible for converting a JSON string into an object on method entry and for converting objects back to a JSON string on return. Pure Shim chaincode need to perform to perform the serialization themselves as required.
Where the code serializes an Object for PutState we should use a deterministic library to be safe, when returning data we should avoid using the inbuilt serializer provided by the contract api and use a deterministic library. For node non contract api I think the JSON parser is safe because we are in total control of the conversion at method entry and method exit and using JSON functions will be consistent across different peers, what I can't be exact about is what the contract api does which means it could be non deterministic if a slightly different version of a library gets used say if chaincode is deployed at different times (need to consider a package-lock.json) but also what the contract-api might actually do under the covers. I can't vouch for Java at all either shim or contract-api based at this time so might be safer just to use a deterministic library
I don't believe Go chaincode would have that problem as the Go JSON Marshaller is deterministic around how objects are serialized.
see https://hyperledger-fabric.readthedocs.io/en/latest/chaincode4ade.html#json-determinism