Notes about Ethereuim
Ethereum in its current state is a failure because the unqualified and uneducared narcissistic “designers” ignored almost every fundamental result produced in the “Golden Age” of so-called Computer Science (70s, 80s, 90s).
First of all, it has to be declarative and pure-functional, to be evaluated with a pen and paper, just like Haskell. By the time vitaliks emerged everything about Functional Programming has been already researched and well-understood.
Considering the distributed aspect, Erlang had all the research and development done in a principle-guided way, resulting in a platform for developing networked and decentralized systems. Again, knowing the fundamental principles helps to avoid embarrasment.
The “solution” of the halting problem as to limit the depth of recursion is as old as the notion of recursive procedures, so there is nothing new.
Notably, at almost the same time, another narcissistic guy applied most these solid principles, climbed on shoulders of the giants, and got almost everything right. His name is Rich Hikey.
The state-machine metaphor
The state-machine on top of an immutable ledger (which represents the state) metaphor is a meme. It is a classic example of the past rationalization, when afterthoughts are being presented as preliminaries.
Notice that a state-machine is way too general concept and could be applied to everything, including an interpreter of the Lambda Calculus, which is good-enough to compute everything commutable.
This result has been demonstrated long ago and popularized in classic book SICP.
The view of a “merkle-tree” instead of the Turing’s “tape” is a nothingburger, given that every list is, technically, a generated tree/ or even a proper tree if we consider the implementation, which includes the “spine” of a list.
The right principles
Now lets quickly state the “right” principles which are “naturally” applicable in the context of a blockchain.
Immutable data
Immutable data is the fundamental principle. The data which can be altered (or modified) behind your back is not data at all. It is some temporal imperative state/, by defintion.
All the research on immutable data structures (Okasaki, and then actual implementations in Haskell, Clojure and Scala 3) show the obvious benefits, with the only downside (performance) is irrelevant in the context of a blockchain.
The innovative idea of enforcing and validating immutability using tree-like structures, which incorporate (use) previous node’s content hashes belongs to Satoshi, not vitaliks.
Immutable “ledgers” (as append-only files or data structures) has been around since 60s. The actual innovation was the “nested cryptogtaphic hashes” scheme.
Pure, declarative code
This is what has been missed due to incompetence and ignorance. The “Implementation of Functional Languages” of Peyton Jones has been published in 1987, so it has to be the G-Machine, the result of decades of research, not some amateur bullshit.
In principle, it is not the Turing Machine, but the equivalent formulation of the Lamda Calculus to be used as the theoretical basis for the whole thing. Same capabilities, with purity and universality of arithmetic or symbolic logic.
Graph-reduction
The graph-reduction methodology as an implementation of the syntactically sugared (and extended with proper ADTs) Simply Typed Lambda Calculus was a major fundamental result at the time.
This result is based on the general observation that almost everything is reducible to some kind of a directed, acyclic graph, both “causality” and “potentiality” views of the “Underlying Reality”.
Notice that with implicit nesting of pure expressions, which is how composition of expressions is “implemented” (realized) and an order of evaluation (precedence) is defined in mathematics, whole classes of “imperative problems” do not arise at all.
pattern-matching on Receive
As long as “send” and “receive” are “expressions” (need a runtime support) it is natural to “pattern-match on receive”, just as Erlang does. The semantics are well-understood and are similar to the classic, pure match expression.
receive threated as a match expression is a major innovation of Erlang.
Monads
Monads, as a generalization of an abstraction barrier, can be used to properly implement “send”, “receive” and other primitives. This will be just a specializarion (several, one for each kind of primitives) of the I/O Monad.
Again, this was a well-researched and well-understood topic way before 2013.
Type-classes
The required set of interfaces (as per ERC-20) is excatly what the universal notion of a type-class captures.
The type system of Haskell can check that all the required interfaces are present and that the “set-subset” relation is honored.
It is “natural” to add an additonal type-level “constraint language” to specify pre-conditions at a type-level (not code-level asserts or predicates) when one “designs a high-level language”.
Notice that Solidity is as bad, incosistent and amateur (bordering “retarded”) as PHP.
Combinators
I am not sure, but it seems intuitively that another well-known implementation techinque, used with the pure-functional language Miranda would also be a fundamentally better choice (as good as Graph Reduction) than some imperative amateur toy VM.