Open axelhodler opened 6 years ago
Great, another step towards an actual federated prototype :) I like the idea of reusing an existing property as unique ID. There two questions that come to mind:
Are IPFS addresses unique enough [...]
Yes, in case there will ever be collision I guess ipfs will switch their hashing algorithm
[...] make sure we can deal with identical models?
Will we support users adding identical models?
Storing the ipfs address is still relevant and the hash would be an additional property right?
Depends, where would I promote my model? There i would probably provide the IPFS hash which can then be used to calculate its ID in the contract. Meaning the IPFS hash would not have to be stored on-chain. Only ethereumHash(IPFSHash(myModel))
.
We currently store the IPFS hash of our model split into two parts.
PySonar currently uses it as such:
leads to race conditions.
e.g. Bob and Alice add a Model at the same time, both their local nodes will return them the same id. but the definite order is decided by how the miner orders the transactions in the block. In the end either the Bob or the Alice model will get the index they got from
self.call.getNumModels()-1
Suggestion: We keccak/sha3 the ipfs hash and store it in a single
bytes32
instead of an array of twobytes32
, this makes it easier to work with the ids and the calle knows the id of his model before he persists it with the contract.