msg.senderdoesn't do anything special there, just an address variable
mintprobably wouldn't cause harm by itself, it doesn't impact any internal state of the contract
temp: bytes32[BATCH_SIZE] temp_from_supplies: bytes32[BATCH_SIZE] for i in ragne(BATCH_SIZE): id: uint256 = _ids[i] temp[i] = convert(id, bytes32) supply: uint256 = _from_supplies[i] temp_from_supplies[i] = supply hash: bytes32 = keccak256(concat(temp, temp_from_supplies))
hash: bytes32 = keccak256(abi_encode(_ids, _from_supplies))
concat(bytes32[N], bytes32[N])works to give you a string of bytes. I don't think I've seen someone do that yet
aggregate_hash: bytes32 = keccak256(concat(convert(_ids, bytes32), convert(_from_supplies, bytes32), convert(_to_supplies, bytes32))) for i in range(BATCH_SIZE): if not i == 0: aggregate_hash = keccak256(concat(aggregate_hash, convert(_ids[i], bytes32), convert(_from_supplies[i], bytes32), convert(_to_supplies[i], bytes32))) hash: bytes32 = keccak256(concat(convert(_from, bytes32), convert(_to, bytes32), aggregate_hash, convert(_value_eth, bytes32), convert(_nonce, bytes32))) return hash
I am wondering, would it be possible to do transaction-like behavior for reading and changing persisted attributes?
_x: uint256 = self.x ... self.x += 1 ... _y: uint256 = self.x ** 2 ...
Creates three heavy reads and one heavy write.
Is it possible to cache the value of
self.x at first operation automatically (sload), and do the sstore only at the end of transaction? Or is that how it works?
x: ERC20gives the same error. I recall a discussion here about it quite a while ago, but I can't find it now. I thought the outcome of that discussion was that it was by design. (I think the intention was to force developers to do
ERC20(foo).transfer()each time to make it obvious what function was being called.)