Are there anything that is unique maybe combine with time, user address or something else, and send it to the smart contract, and the contract can know that it is indeed the unique thing that user doesn't not tell a lie?
2 Answers
I would argue that any time system integrity hinges on something the user does the contract should strictly enforce the rules. For example, if the user is to provide a unique identifier then the contract should enforce uniqueness. Here is a simple approach to give you some ideas.
pragma solidity 0.4.25;
contract Uniqueness {
mapping(bytes32 => bool) public isUsed;
function claimId(bytes32 key) public returns(bool success) {
require(!isUsed[key]);
isUsed[key]=true;
return true;
}
}
You can also give the user a pure
function that can help them create a unique given unique inputs. The burden of making a unique key remains with the user and the burden of enforcing the rules remains with the contract.
pragma solidity 0.4.25;
contract Uniqueness {
mapping(bytes32 => bool) public isUsed;
function claimId(bytes32 key) public returns(bool success) {
require(!isUsed[key]);
isUsed[key]=true;
return true;
}
function createKey(address user, uint salt) public view returns(bytes32 key) {
return keccak256(abi.encodePacked(user, salt, address(this), block.number));
}
}
Hope it helps.
-
but what is the purpose of such system Rob? the user address is a unique identifier.– JaimeCommented Nov 1, 2018 at 7:29
-
The OP's question is about a unique thing the user can generate. The OP didn't say exactly what the use-case is. Possibly ID keys for records/docs where there is more than one per user. Commented Nov 1, 2018 at 8:04
-
-
I think if you ask a general question then only a general answer is possible. Commented Nov 1, 2018 at 14:16
It's up to the account that sends data to the smart contract to get the unique "thing". Like Rob said above, you can check it the "thing" is already present by that function (that is free to query) If you're use case is gaming, lottery etc. you can use something like Oraclize it
The design described there prevents Oraclize from tampering with the random results coming from the Trusted Execution Environment (TEE) and protects the user from a number of attack vectors.
The authenticity proof, attached with the result, can be easily verified not just off-chain but even by any Solidity contract receiving them.
This way you can verify that the random result you got is indeed "unique" and the user doesn't lie