In most exaplanations of the essentials of Ethereum, I miss an important detail: "Who runs the computations of a smart contract?".

Say I make a call, add some gas, all of which allows me to, say, extract some tokens from a (solidity) contract.

Where is the code ran?

Reading a question about fees makes me believe it is a miner.

If the Solidity is being executed in a transaction, the fee always goes to the miner of the block, even if there is an Out of Gas or execution error of any kind.

If that is the case, what miner will run the code? All of them? The winning one?

However, reading a question on the how- of executing contracts makes me beleive it is the node executing this. Would that be the node one is connected to? And when a node needs to call another contract as part of this contract-call, will it do so on itself, or delegate that to another node?

And if it is the nodes, do miners need to re-run a contract in order to decide whether it's outcome state was properly ran?

Another question covers the when: at what time are they ran. The answer there does cover some of the "who", but does not explain explicitely who is running it.


Smart contracts can acccess data that is stored on the blockchain, they can process the data and write new or modified data back to the blockchain. In order to answer your questions, we have to look into detail on these cases.

Let's assume that a function is limited to reading data from the blockchain, so it won't change the state of the blockchain. As a consequence, the function can be ran directly on the node you are connected to, since it only reads from the current state, which is available on the node. Such functions should be defined with the view modifier, and they are invoked using a call. Another case that belongs into this category is a function that does not even access any data on the blockchain. Such a function should be defined using the pure modifier.

In many other cases, however, a contract wants to add data to the block chain or modify the data on the blockchain. Such action obviously changes the blockchain, such that is has to be found a consensus on the changes the contract wants to do. In order to find consensus, mining is required, such that the function has to be invoked by a transaction. The miners receive the transaction and carry out the requested function of the contract. Based on the result of the function and the new blockchain state, they solve the cryptographic problem in which the actual mining process consists.

The contract below show examples for view and pure functions and for a function to be invoked via a transaction:

Contract C {

    // A counter
    uint cnt;

    // Constructor
    function C() {
        cnt = 0;

    // View function, runs on the connected node
    function getCount() view returns (uint) {
        return cnt;

    // Pure function, runs on the connected node
    function multiply(uint a, unitr b) pure returns(uint) {
        return a*b;

    // This function has to be mined
    function incCount() {

So to summarize, both of the scenarios you mentioned exist, depending on if the state of the blockchain is changed or not.

  • So a hypothetical contract that would call an outside API, should be programmed in a way that calling this outside API can be done over and over? i.e. be Idempotent? – berkes Nov 21 '17 at 9:32
  • I'm not sure if I understand right. A contract cannot call an outside API, if you need to access resources outside of Ethereum, you need to use an Oracle. Apart from that, when you design the functions of a contract you should think about spending gas of the users of the contract efficiently. As an example if you have a contract in which certain data is written once but viewed thousend of times, you should make the reading process such that it does not cost Ether. So you could for example not count the number of reads – gisdev_p Nov 21 '17 at 9:40
  • Reading up on Oracles, I now understand that it provides the solution to my question: it hides the fact your contract may be ran an arbitrary amount of times from the external API. – berkes Nov 21 '17 at 9:43

Every node runs everything. Think of everything in the EVM, every contract and all their states, running in 1 virtual computer. The blocks don't contain the state, they're just the transactions that cause changes in the state. Every node then must simulate every transaction to generate the current state of the network.
