47

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?

q9f
  • 32,913
  • 47
  • 156
  • 395
Tjaden Hess
  • 37,046
  • 10
  • 91
  • 118

1 Answers1

67

It's not certain yet, but:

  1. 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.
  2. 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)
  3. Do NOT do anything important based on the DIFFICULTY opcode.
  4. Do NOT rely on the assumption of a block time between 12-20 seconds.
  5. Do NOT assume that BLOCKHASHes will be a reliable source of randomness.
  6. Do NOT assume that tx.origin will continue to be usable or meaningful.
  7. 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.

Vitalik Buterin
  • 3,086
  • 20
  • 13
  • So if tx.origin is not meaningful, will msg.sender still be? – Tjaden Hess Jan 21 '16 at 08:14
  • 4
    Yes, msg.sender will remain meaningful. – Vitalik Buterin Jan 21 '16 at 11:56
  • should we add: "Do NOT relay on that 0x0 can never be a msg.sender?" - or is this idea of the table? – mKoeppelmann Jan 21 '16 at 18:09
  • 1
    It'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. – Vitalik Buterin Feb 05 '16 at 21:06
  • Why aren't blockhashes a reliable source of randomness? – Cedric Martens Jan 10 '18 at 21:49
  • 3
    @VitalikButerin What is a reliable source of the initiator of a call chain going forward if not tx.origin? – Shiri May 29 '18 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? – Garen Vartanian Sep 18 '18 at 00:33
  • @VitalikButerin and another big one ... do NOT rely on the block number or variables being consistent across contracts. Right now it’s basically one global blockchain for all contracts, so while your transaction runs, it can rely on variables in other shards being consistent. But in the sharded scenario can we then have race conditions BETWEEN shards, or does it still act in full ACID mode as if there is one giant blockchain and the block numbers will increase monotonically across all shards as before? Will it “look the same from inside the EVM?” – Gregory Magarshak Oct 13 '20 at 16:25