Miners in Ethereum competitively create blocks by executing EVM code and searching for a solution to a mining puzzle.
And just like before, Proof-of-Work is a competition, and only one miner is able to add a block to the Ethereum blockchain, and claim the associated reward.
Proof-of-Work is essentially a way to randomly select — based on proportion of hash power — one node’s execution result as the correct one to add to the blockchain.
Every Ethereum node runs the Ethereum Virtual Machine as part of its block verification procedure.
As before, network consensus removes the need for a trusted third party.
In order to violate smart contracts, you would have to subvert the entire network.
So this allows enables peer-to-peer agreements that live on the blockchain forever.
Contract code is run by the Ethereum Virtual Machine, or EVM for short, as we mentioned earlier.
Contract code is compiled down, and the code that actually gets executed on every node is EVM code.
And EVM code is a low-level stack based bytecode language.
If you’re familiar with the JVM, it’s like how JVM languages such as Java, Scala, and Groovy all compile down to JVM bytecode.
The fact that we can compile complex smart contract code into simple machine understandable instructions in the form of EVM code that all nodes in the network can execute in the same deterministic way provides the basis for consensus in Ethereum.
Because every node in the Ethereum network is executing smart contracts, one immediate issue we face is: What if a contract has an infinite loop? All of a sudden, this contract is pushed onto the Ethereum network, and someone calls the function foo, which has an infinite loop in it, and all nodes see this transaction and start executing foo — forever.
So every node on the network would be stuck executing this infinite loop.
And by the halting problem, a well known problem in computability theory, we know that it’s impossible to determine ahead of time whether a given contract will ever terminate.
And all of this leads to a very easy way for attackers to launch denial of service attacks: by trapping computers around the world in an infinite loop, thereby making them unable to execute other more meaningful contracts.
Luckily, the developers of Ethereum thought of this and implemented a solution: in the form of what’s known as gas.
Gas is what fuels the execution of a given contract.
Every EVM op-code requires gas in order to execute — thereby preventing the aforementioned infinite loop denial of service attack.
Every transaction specifies two parameters, “startgas”, or the maximum quantity of gas the transaction is willing to consume, and the “gasprice”, or the fee in ether the contract is willing to pay per unit gas.
At the start of a transaction, “startgas * gasprice”, which represents the amount of ether paid for a computation, is subtracted from the sender’s account.
The sender being the one who invokes the contract by sending a transaction.
If the contract successfully executes, then the remaining gas is refunded to the sender.
On the other hand, if the contract execution runs out of gas before it finishes, then the execution reverts.
However, the amount in ether that was consumed is not refunded.
The idea here is that although the contract execution gets reverted, someone on the network had to put in the computational power to execute the EVM code, and once the gas is spent up, it’s proof that someone executed the program, so it isn’t refunded.
So this gives us two end states: either a program terminates or runs out of gas.
Ethereum still allows someone to write an infinite loop in a smart contract.
However, the attacker attempting to DoS the network has to pay enough ether to fund the DoS In a way, you can think of purchasing gas as the price you have to pay to use this distributed, trustless computational power.
This thereby disincentivizes users from running expensive computations without having sufficient funds.
Since each computation requires gas, an attacker looking to DoS the network would need an absurdly large amount of ether, and since the attack is so costly, that pretty much disincentivizes this sort of attack.
We mentioned that nodes come to consensus on the network state, and that code execution on the EVM changes the state.
In a way, you can think of the EVM as the underlying state transition mechanism.
When we execute a transaction, we go from a previous state to a new state.
At the beginning, there was a blank Genesis state, upon which many transactions were executed.
And at any point in time, the final state represents the current state of the Ethereum network.
So you start with the current block state, the gas required, the current memory, the transaction that’s calling a contract, a message which basically contains transaction metadata, the code of the contract, and the stack and program counter.
Basically everything you need to correctly execute a transaction.
And you feed this into the EVM, and get out the new block state, with all the updated account balances and internal state, and the new gas value, which gets refunded.