Understanding Ethereum

Ethereum was originally “designed” (spat out in a hurry) by a highly ambitious, but incompetent, unqualified and uneducated person – just a wannabe wishful thinking and memes.

No notion of doing things the right way, leave alone mathematical optimality and related conceptual minimalism has been employed – just amateurish zeal and rush.

The “yellow paper” was “my answer” to a poorly understood and hardly comprehended (which requires a mathematical and intellectual maturity to appreciate) the Bitcoin white paper.

Almost every design decision was amateur and simply bad. After almost 15 years of community efforts, it stabilized, and all the major shortcomings were addressed and accepted.

One more time – as an amateur language Solodity was as bad as PHP3 and the EVM was as bad as the PHP2.0 interpreter. Any undergraduate /Programming Languages student would hage done better.

• A set of related concepts
• A set of informal specifications
• The current protocol (both spec and implementations)
• Implementation details

This was (and still is) the “killer-app”, and the case study of how it was possible to actually, unillusory innovate and to bootstrap an “auto-pilot running” profitable business.

It is absolutely astonishing with how little code and a few changes everything has been accomplished. Still seems to be too good to be true.

The key to that accomplishmet was the good conceptual understanding of what is possible, and to focus on a simple product first (the v1).

Conceptually it boils down to “running user’s transactions (swaps) for a fee inside a contract”, called by a web-interface, just like a cgi script. Everything is (originally) minimal and open-source.

The guy with this kind of clear thinking and an unpolluted by abstract bullshit mind deserves his riches. I am Jack’s stinging envy.

Again, just like calling a “cgi-script”, using the contract’s address on the network. Technically – by issuing (broadcasting) these calls to the network.

Conceptually, a piece of code has an address in a network, and can be executed by a node, motivated by the reward of “gas” fees.

An address in a network is conceptually similar to a binding within a library - it is a level of inderection and a lookup and calling mechanism. Nothing new here.

Again, an address is a binding within the network.

In reality a piece of a crappy imperative code, written in a crappy imperative language, compiled into some bytecode to be run by a crappy VM.

The code has access to “standardized” imperative procedures, which perform network-specific tasks, such as requesting “payments” or sending “money”.

This is just an API exposed by the implementation of the network.

The core concepts are:

• contracts (“executables”)
• tokens (which are contracts)
• addresses

• EVM (an “isolated” virtual machine)