> If the 'value' of executing contracts in $/gas exceeds the cost of renting AWS/EC2 nodes you're basically created a market for mining arbitrage, and perverse incentives where those miners want to push the prices in one direction.
I think you misunderstand what gas is for. The cost (in terms of transaction fees) to execute something on the EVM is already many many orders of magnitude higher than what it would cost for a single person to run the computation by renting some CPU time from AWS.
Think about it in the case of Bitcoin. Simplifying a bit, most Bitcoin transactions just consist of subtracting a number from one account balance and adding it to another account balance. That's an incredibly cheap operation by any metric, yet Bitcoin burns through a million dollars of electricity every day.
The reason it costs so much to run code on the EVM is, most of the "cost" goes toward ensuring consensus (or, from the contracting parties' point of view, immutability). Transaction costs and block rewards currently go to miners (in the current PoW world anyway, in PoS this explanation will be slightly different), and miners don't spend most of their CPU cycles running the computation, they spend most of their CPU cycles trying out a hash function (Keccak-256) as directed by ethereum's PoW algorithm (ethhash), and if they're lucky with the values they hash they mine the block. This CPU time only serves to reach consensus, and does not to do any useful work for "just running" the EVM code itself.
Another thing that proves that gas does not really correspond to CPU cost directly is that they recently extended it with new primitives (specifically, "elliptic curve multiplication, addition and pairing") as part of a research effort collaborating with zcash (which uses those primtives in their zero-knowledge-proof protocol for allowing private transactions). Of course the EVM could do it before this change (since it's Turing-complete), so if gas = cpu time, why bother adding this primitive?
As to what purpose gas serves, the best source is probably http://vitalik.ca/general/2017/09/14/prehistory.html, but as I understand it it's to prevent DoS attacks and to limit the size of the blockchain (since every contract call ever made, its source code, and hence every EVM instruction executed, is part of the immutable ledger).
> Event-oriented programming is old hat in every modern programming language. C/C++ have plenty of frameworks out there you can use to get at it, so do other languages. In some environments it's the de-facto way to write code.
Sure, but it would have to be a core part of the language, it can't be a framework or library. For instance in this contract https://theethereum.wiki/w/index.php/ERC20_Token_Standard#Sa... there's a transfer "function" that addresses call to transfer tokens around. It doesn't run in the context of a "main" function (in the C sense), it just runs and updates some state. So there's some different semantics here (not big differences, just enough that I would call it necessarily a different language). Similarly an event-oriented programming framework for C would probably include a runtime scheduler (probably written in C or assembly), but the EVM and the block-mining framework is the scheduler in EVM's case, it makes no sense to have a runtime scheduler run as "bytecode" or "CPU instructions".