When Serenity comes around, the network will undergo many changes, some of which may have unexpected consequences on existing Smart Contracts. How can I plan so that I am best prepared to take advantage of new features in Serenity and least likely to see unexpected bugs and security flaws?
asked Jan 21, 2016 at 7:11
Add a comment
|
1 Answer
It's not certain yet, but:
- Do NOT rely on very fine-grained calculations of current gas costs. Assume that gas costs of contract calling may go up or down by up to an order of magnitude in a future hard fork.
- If creating contracts in assembly (ie. not serpent, solidity or LLL), do NOT use dynamic JUMP/JUMPI operations (ie. every JUMP/JUMPI should be immediately preceded by a PUSH value specifying the exact point in the code to jump to)
- Do NOT do anything important based on the DIFFICULTY opcode.
- Do NOT rely on the assumption of a block time between 12-20 seconds.
- Do NOT assume that BLOCKHASHes will be a reliable source of randomness.
- Do NOT assume that tx.origin will continue to be usable or meaningful.
- Do NOT assume that opcodes other than 0xfe will continue to be invalid.
It's not certain that all of those steps will be required, or that they will be sufficient, but that should get you most of the way there.
-
So if tx.origin is not meaningful, will msg.sender still be? Commented Jan 21, 2016 at 8:14
-
4
-
1It's likely that we'll make the entry point something other than 0x0 if we see many applications using 0x0 as a stand-in for "no account yet exists in this slot" to the point where making 0x0 the entry point compromises security. Commented Feb 5, 2016 at 21:06
-
3@VitalikButerin What is a reliable source of the initiator of a call chain going forward if not tx.origin?– ShiriCommented May 29, 2018 at 10:58
-
3@VitalikButerin how do we prevent contracts from becoming recipients of value, i.e., malicious fallback function throws in send patterns, without requiring tx.origin == message sender? Commented Sep 18, 2018 at 0:33