Sonar
Sonar copied to clipboard
Suggest changing the identifier of a model
We currently store the IPFS hash of our model split into two parts.
PySonar currently uses it as such:
deploy_trans = self.get_transaction(model.owner,value=self.web3.toWei(model.bounty,'ether')).addModel([ipfs_address[0:32],ipfs_address[32:]],model.initial_error,model.target_error)
return self.call.getNumModels()-1
self.call.getNumModels()-1
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 two bytes32
, 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.
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 or should we add sth else to make sure we can deal with identical models?
- Storing the ipfs address is still relevant and the hash would be an additional property right?
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))
.