## An universally fair, fully agnostic way to measure the costs of a computation

## The problem

One of the challenges decentralized computing networks like Ethereum face is: how to measure the costs of executing programs? Ethereum solves that by running every program in a virtual computer, the EVM, which is a stack machine where each primitive computation has a fixed gas cost. While such approach has proven solid in practice, it has a few problems. 

1. It is hard to balance the gas costs among different primitive operations. For example, in 2016, Ethereum has been attacked with spam transactions which abused the fact certain operations were underpriced with respect to how much computing resources they consumed. This motivated the creation of the [https://github.com/ethereum/EIPs/blob/master/EIPS/eip-150.md](EIP-150), which increased the costs to more sensible levels. While that solved the issue on the short term, the solution isn't future-proof. If either computer architectures or Ethereum clients evolve in a direction that favors certain opcodes over another, then new imbalances will show up, requiring further changes (hard-forks) to the base protocol.

2. It inevitably favors certain programming paradigms in detriment of others. The EVM is a stack machine with opcodes for memory read/write, branching and basic arithmetic. In other words, it has a very "imperative" flavor, making it unviable to run functional languages on it: the cost of emulating their primitive operations (such as substitution) would be beyound prohibitive. This is particularly annoying when trying to prove properties about contracts, since most theorem provers are based on functional paradigms.

That raises the question: what is an universally fair way to measure the costs of a computation? I.e., one that captures the intrinsic cost of executing a specific program in a way that is agnostic to the hardware architecture, the client implementation and the high-level programming paradigm used? I'll try to shed some light on that topic with insights from different fields of research.

## A detour: the optimal implementation of functional programming languages

Functional programming languages exist since at least 1930, when the λ-calculus was first described. Regardless, it wasn't until 

