You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is because Corda automatically de-duplicates multiple occurrences of objects in the serialized data using an IdentityHashMap, i.e. by reference equality (see objectHistory in SerializationOutput.kt). Supposedly this is done to reduce the size of serialized data in some cases.
The behavior is a bit unfortunate because transaction hashes now depend on the degree of sharing in the heap. Reference equality is irrelevant from a semantic perspective for all data classes, so two transactions can be semantically equivalent but still have different serialized representations. This doesn't cause any problems when transactions are created by a central party and distributed from there, but consider a use case where a transaction contains fairly large data objects which are already known by all parties in a flow that need to sign the transaction. In that case, the parties can just exchange information such as the privacy nonce and deterministically derive the transaction locally, thereby avoiding transmitting large objects to each other. This approach however becomes quite brittle when reference identity of data (which is often non-deterministic, e.g. in the case of a cache eviction) affects the transaction hash.
I think that this behavior should be disabled or at least be optional.
The text was updated successfully, but these errors were encountered:
Consider the following program:
This prints:
Serialization is not bijective!
This is because Corda automatically de-duplicates multiple occurrences of objects in the serialized data using an
IdentityHashMap
, i.e. by reference equality (seeobjectHistory
inSerializationOutput.kt
). Supposedly this is done to reduce the size of serialized data in some cases.The behavior is a bit unfortunate because transaction hashes now depend on the degree of sharing in the heap. Reference equality is irrelevant from a semantic perspective for all data classes, so two transactions can be semantically equivalent but still have different serialized representations. This doesn't cause any problems when transactions are created by a central party and distributed from there, but consider a use case where a transaction contains fairly large data objects which are already known by all parties in a flow that need to sign the transaction. In that case, the parties can just exchange information such as the privacy nonce and deterministically derive the transaction locally, thereby avoiding transmitting large objects to each other. This approach however becomes quite brittle when reference identity of data (which is often non-deterministic, e.g. in the case of a cache eviction) affects the transaction hash.
I think that this behavior should be disabled or at least be optional.
The text was updated successfully, but these errors were encountered: