Why do smart contract languages need to be deterministic?

Question

I read somewhere that smart contract languages need to be deterministic. Why?

Answer 1

As reminded in the first comment from Richard, smart contracts have to be deterministic because each nodes of the network have to be able to find the same result given the same input for a contract method. Otherwise each node that executes the contract method to validate the transaction would end with different results and no consensus would be possible.

But why the smart contract language itself such as Solidity have to be deterministic? It doesn't have to be.

Solidity is deterministic because it's a convenient language well designed for its purpose, but the Lisk network for instance uses standard JavaScript which is not deterministic. That means that nothing can avoid the use of a method to generate a random value in Lisk smart contracts. Developers thus have to be very careful to avoid using non deterministic functions. Sometimes this can be tricky. Math.random() function is obvious, but some other math methods can use roundings that won't always give the same result or some date functions as the new Date() which gives the current date and is thus non deterministic. As you can read in the Lisk documentation developers are warned not to use this functions. But if you are not careful you can completely wreck your contract.

The power of Solidity and other deterministic languages is that developers don't even have to care about determinism because there is no non deterministic functions in the language.

Answer 2

The determinism prevent any fork in the network. The same goes for Solidity which uses the EVM.

To complete @NicolasMassart 's answer and @user1870400 comment that proposes to generate random values based on a possible Solidity implementation of the Go code used for random number generation, based on https://golang.org/src/math/rand/rng.go you can notice that this code doesn't rely on any random at all but uses hard coded entropy.

If you try it twice without specifying entropy, you'll get the same predictable result. To use this in a concrete use-case, you're supposed to bring your own source of entropy, i.e.: rand.NewSource(time.Now().UnixNano()) for example.

Hopefully inside the EVM, each source of entropy generate the same value for a single transaction across each node of the network, whether you use the timestamp (aka block.timestamp or now -- because it's the timestamp of the time the block was issue by the single miner of this block) or any other pseudo random value.

So even implementing this algorithm in a smart contract using Solidity will lead to a deterministic result.