The current implementation of KeyValueObjectGraph.getConsensusHashForRepresentation()uses Arrays.hashCode as a stop-gap until we decided which cryptographic function to use, and where the responsibility for calculating the hash should lie (there is an argument that it should be moved out of the critical path).
This item is to track the changes to account for the correct hash function. Unless we change our mind for some specific [documented] reason, I currently propose that we run the raw binary of the SerializedRepresentation through keccak256 (since Ethereum uses that function, just operating on RLP-encoded data).
For now, we will consider changes to where this is done to be beyond the scope of this item and will not change it.
The current implementation of
KeyValueObjectGraph.getConsensusHashForRepresentation()usesArrays.hashCodeas a stop-gap until we decided which cryptographic function to use, and where the responsibility for calculating the hash should lie (there is an argument that it should be moved out of the critical path). This item is to track the changes to account for the correct hash function. Unless we change our mind for some specific [documented] reason, I currently propose that we run the raw binary of theSerializedRepresentationthroughkeccak256(since Ethereum uses that function, just operating on RLP-encoded data). For now, we will consider changes to where this is done to be beyond the scope of this item and will not change it.