Clean up terrible file names, make index exhaustive

Blockchain-Primer.md

@@ -2,23 +2,27 @@
 
 ![Blockchain101](../../raw/branch/master/img/Blockchain101a.jpeg)
 
-A number of independent but related ideas must be understood before a deep discussion of the blockchain landscape or explanation of the structure and function of the Gajumaru can be fully appreciated. The following is a brief explanation of the points most relevant to understanding our project and distributed ledger technologies (DLTs) in general.
+A number of independent but related ideas must be understood before a deep
+discussion of the blockchain landscape or explanation of the structure and
+function of the Gajumaru can be fully appreciated. The following is a brief
+explanation of the points most relevant to understanding our project and
+distributed ledger technologies (DLTs) in general.
 
 Subjects:
 
 - [The Nature of Money](Money)
 - [[Monetary Mechanics]]
 - [[Inflation, Deflation, Coins, Tokens, and Prices]]
-- [[Distributed Ledger Technologies (DLTs)]]
+- [[DLTs]]
 - [[Blockchain]]
 - [[Transaction]]
 - [[Mempool]]
-- [[Leader (s)election]]
+- [[Leader Selection]]
 - [[Proof of Work]]
 - [[Mining]]
-- [[The Mint Function, Blockchain Inflation, and Currency Debasement]]
+- [The Mint Function, Blockchain Inflation, and Currency Debasement](Mint)
-- [[The Blockchain Trilemma]]
+- [[Blockchain Trilemma]]
 - [[Consensus]]
 - [[Finality]]
 - [[Smart Contracts]]
-- [[The Sophia Language]]
+- [The Sophia Language](Sophia)

Blockchain-Trilemma.md

@@ -0,0 +1,38 @@
+# The Blockchain Trilemma
+
+In engineering there is a famous trilemma such that:
+
+- A project can be cheap, fast or correct; pick two.
+
+In distributed systems there is a trilemma called "the CAP theorem" such that:
+
+- A distributed system can, at any given moment, have consistency,
+  availability, or partition tolerance; pick two.
+
+The "blockchain trilemma" can be stated as follows:
+
+- A ledger system can be secure, distributed, or scalable; pick two.
+
+To understand the blockchain trilemma it is useful to first **understand** the
+CAP theorem. To expand on its three properties, to a distributed systems
+engineer they mean:
+
+- **Consistency**: all nodes will give the same response to a query
+- **Availability**: the system is highly responsive
+- **Partition tolerance**: if the network splits both parts will behave correctly
+
+The trouble is that the laws of physics conspire in such a way that any system
+can achieve only two of these three qualities at a time. The challenge for the
+designer is to pick which qualities matter most at a given moment rather than
+trying to naively achieve all three and simply failing.
+
+Given that [[DLTs]] are distributed systems, the CAP theorem applies to them.
+Algorand, for example, addresses the problem by favoring security over
+availability — their network simply stops during a sufficiently large network
+split, i.e. dropping the "P" in "CAP". As an example of how the CAP theorem
+forces the blockchain trilemma, consider that in the context of DLTs claiming
+"instant finality" it is relevant to inquire how they can guarantee that in the
+face of network splits.
+
+The Gajumaru solves the blockchain trilemma in a novel way that is related to
+both its architecture and its approach to [consensus](Consensus).

Consensus.md

@@ -1,13 +1,36 @@
 # Consensus
 
-In the context of distributed systems "consensus" means finding some way to agree on a common view of state at a given time. The trouble with the previous sentence is its last word: "[[time]]". There is no absolute notion of "wall clock time" in distributed systems, but it is possible to establish relative sequence in a concrete way. Sequence then becomes the basis for notions of time. This means that sequence is the first thing that must be agreed before anything else can occur.
+In the context of distributed systems "consensus" means finding some way to
+agree on a common view of state at a given time. The trouble with the previous
+sentence is its last word: "[[time]]". There is no absolute notion of "wall
+clock time" in distributed systems, but it is possible to establish relative
+sequence in a concrete way. Sequence then becomes the basis for notions of
+time. This means that sequence is the first thing that must be agreed before
+anything else can occur.
 
-In blockchain the way this works is that a "leader" can be picked (see [[Leader (s)election]]), and whatever that leader says can be accepted by all nodes in the system as the agreed truth until that leader is replaced. This reduces the problem of consensus to the problem of leader selection.
+In blockchain the way this works is that a "leader" can be picked (see
+[[Leader Selection]]), and whatever that leader says can be accepted by all nodes in
+the system as the agreed truth until that leader is replaced. This reduces the
+problem of consensus to the problem of leader selection.
 
-The Gajumaru works via leader selection as described above, and the mechanism for leader selection on Groot is [PoW](Proof-of-Work). There are other mechanisms of leader selection and also consensus paradigms that do not depend on selection of a single leader.
+The Gajumaru works via leader selection as described above, and the mechanism
+for leader selection on Groot is [PoW](Proof-of-Work). There are other
+mechanisms of leader selection and also consensus paradigms that do not depend
+on selection of a single leader.
 
-As mentioned above, PoW has the special property that the participants do not need to be known, nor do they need to be trusted. Trustless and anonymous are synonymous in this context and are required for a mint to function properly.
+As mentioned above, PoW has the special property that the participants do not
+need to be known, nor do they need to be trusted. Trustless and anonymous are
+synonymous in this context and are required for a mint to function properly.
 
-[[Proof of Stake]] (PoS) differs radically from PoW as a consensus mechanism. PoS systems are vulnerable to a variety of attacks unless the actors in that system are known and trusted to some degree. Further, if the collateral that has been put at stake is not valuable independent of the staking system the system winds up with what is called the "nothing at stake" problem where the sacrifice of stake may be painless to a malicious actor because it was never externally valuable to begin with.
+[[Proof of Stake]] (PoS) differs radically from PoW as a consensus mechanism.
+PoS systems are vulnerable to a variety of attacks unless the actors in that
+system are known and trusted to some degree. Further, if the collateral that
+has been put at stake is not valuable independent of the staking system the
+system winds up with what is called the "nothing at stake" problem where the
+sacrifice of stake may be painless to a malicious actor because it was never
+externally valuable to begin with.
 
-The entire field of consensus research in distributed systems is dedicated to exploring the tradeoffs that exist and categorizing which systems are viable in which contexts, whether identified or anonymous, trusted or trustless, malicious or benign, closed or open, and so on.
+The entire field of consensus research in distributed systems is dedicated to
+exploring the tradeoffs that exist and categorizing which systems are viable in
+which contexts, whether identified or anonymous, trusted or trustless,
+malicious or benign, closed or open, and so on.

Finality.md

@@ -1,9 +1,26 @@
 # Finality
 
-In classical blockchain consensus, it is common to employ the "longest fork wins" rule, meaning that if conflicting blocks (called "[forks](fork)") appear at a given height, this will eventually resolve itself by one fork outpacing the other. In traditional distributed systems parlance, this could be described as "eventual consistency".
+In classical blockchain consensus, it is common to employ the "longest fork
+wins" rule, meaning that if conflicting blocks (called "[forks](fork)") appear
+at a given height, this will eventually resolve itself by one fork outpacing
+the other. In traditional distributed systems parlance, this could be described
+as "eventual consistency".
 
-On [[Bitcoin]], a rule of thumb is that a transaction is practically impossible to evict from the chain once six blocks have been added on top of it. Given Bitcoin's 10 minute block interval, this means that a transaction can be said to have reached finality after an hour. The six-block rule is based on the exponentially increasing cost of rewriting the chain for each added block. Some other chains simply impose a certain depth beyond which they do not accept any forks being introduced.
+On [[Bitcoin]], a rule of thumb is that a transaction is practically impossible
+to evict from the chain once six blocks have been added on top of it. Given
+Bitcoin's 10 minute block interval, this means that a transaction can be said
+to have reached finality after an hour. The six-block rule is based on the
+exponentially increasing cost of rewriting the chain for each added block. Some
+other chains simply impose a certain depth beyond which they do not accept any
+forks being introduced.
 
-Since an hour is much too long to wait for many transactions ("paying for coffee" is often given as an example), users often choose to settle for much less—again in the case of Bitcoin, perhaps even peeking into the "[mempool](Mempool)" (list of pending transactions) and spotting the transaction there. Accepting a transaction that hasn't even reached the chain yet is called a "zero-confirmation" trade.
+Since an hour is much too long to wait for many transactions ("paying for
+coffee" is often given as an example), users often choose to settle for much
+less—again in the case of Bitcoin, perhaps even peeking into the
+"[mempool](Mempool)" (list of pending transactions) and spotting the
+transaction there. Accepting a transaction that hasn't even reached the chain
+yet is called a "zero-confirmation" trade.
 
-Several competing systems claim finality within seconds. Given knowledge of the CAP Theorem (see [[The Blockchain Trilemma]]), one wonders if their models cover all potential situations, especially in a fully decentralized setting.
+Several competing systems claim finality within seconds. Given knowledge of the
+CAP Theorem (see [[Blockchain Trilemma]]), one wonders if their models cover
+all potential situations, especially in a fully decentralized setting.

Home.md

@@ -1,16 +1,34 @@
 Gajumaru Wiki: Home
 =====================================================================
 
-Index
+# Index (Alphabetical, Exhaustive)
----------------------------------------------------------------------
+
+Title                       | Brief Description
+--------------------------- | -----------------
+[[API Encoding]]            | `ak_...` etc garbage explained
+[[BaseN]]                   | Given `xy_ABCD`, what is the `ABCD`
+[[Blockchain Primer]]       | Introductory information necessary to interpret any discussion about blockchain
+[[Blockchain Trilemma]]     | Terminology
+[[Consensus]]               | Terminology
+[[DLTs]]                    | Terminology
+[[Finality]]                | Terminology
+[[Flation]]                 | Terminology: Inflation, Deflation, Coins, Tokens, and Prices
+[[Install Erlang and zx]]   | Tech Support
+[[Leader Selection]]        | Terminology
+[[Mempool]]                 | Terminology
+[[Mining]]                  | Terminology
+[[Mint]]                    | Terminology
+[[Monetary Mechanics]]      | Terminology
+[[Money]]                   | Terminology
+[[Proof of Work]]           | Terminology
+[[RLP]]                     | If the binary `ABCD` is some data with fields (e.g. a transaction), how to destructure the binary data to fields
+[[Serializations]]          | Conventions for field order in Gajumaru data structures
+[[Smart Contracts]]         | Terminology
+[[Sophia]]                  | Introduction to Sophia, the Gajumaru smart contract language
+[[Testnet Node Setup]]      | Tech support
+[[Transaction]              | Terminology
+
 
-- [[Blockchain Primer]]: Introductory information necessary to interpret any discussion about blockchain
-- [[API Encoding]]: `ak_...` etc garbage explained
-- [[BaseN]]: Given `xy_ABCD`, what is the `ABCD`
-- [[Installing Erlang]]
-- [[RLP]]: If the binary `ABCD` is some data with fields (e.g. a transaction),
-  how to destructure the binary data to fields
-- [[Serializations]]: Conventions for field order in Gajumaru data structures
 
 
 ## Principles
@@ -35,6 +53,11 @@ Index
 - **VIDEO:** If it's something that is conceptually complicated, maybe
   make/link a video explainer
 
+### Pet Peeves (PRH)
+
+- Filenames that start with `The` (screws up alphabetization)
+- Filenames not matching `/[A-Z][A-Za-z0-9\- ]*\.md/`
+
 ## TODOs
 
 -   Articles needed:
@@ -62,3 +85,4 @@ Index
     - Serializations:
         - write
         - need exhaustive reference
+

Leader-%28s%29election.md

@@ -1,12 +0,0 @@
-# Leader (s)election
-
-The idea of the distributed ledger is important but also comes with an obvious problem: who has the authority to make an update to the ledger? Enforcing sequence is a critical feature of blockchain, so updates to the ledger in parallel is a non-trivial problem, meaning that the most obvious way to maintain correctness is to only have a single node be permitted to issue updates at a time. The node with this update authority is called the "leader". Picking the leader in a way that all nodes agree upon is the problem of leader selection.
-
-There are two common approaches to this that simplify the problem:
-
-1. Hold an election
-2. Hold a competition
-
-In the case of voting we must have some reason to trust that the participants in the vote are acting in good faith. Voting participants must place a costly symbol of their faith at risk for all to see, and they must also be known (not anonymous) parties to prevent gaming of the system. That is, for a voting system to work we must have some trust in the voters, and that can either be because we assume they are trusted (we know their identity) or because they have placed something valuable at stake and we know their identity.
-
-In the case of puzzle solving, however, we do not require any special faith in stake, nor do we require known identities because the act of solving a difficult puzzle is itself a costly signal. The cost of solving the puzzle is moderated by the number of other participants against which all other participants are in competition, and in the ideal case the cost associated with compromising or capturing the system is greater than the value to be gained by going to the expense and trouble.

Leader-Selection.md

@@ -0,0 +1,31 @@
+# Leader (S)election
+
+The idea of the distributed ledger is important but also comes with an obvious
+problem: who has the authority to make an update to the ledger? Enforcing
+sequence is a critical feature of blockchain, so updates to the ledger in
+parallel is a non-trivial problem, meaning that the most obvious way to
+maintain correctness is to only have a single node be permitted to issue
+updates at a time. The node with this update authority is called the "leader".
+Picking the leader in a way that all nodes agree upon is the problem of leader
+selection.
+
+There are two common approaches to this that simplify the problem:
+
+1. Hold an election
+2. Hold a competition
+
+In the case of voting we must have some reason to trust that the participants
+in the vote are acting in good faith. Voting participants must place a costly
+symbol of their faith at risk for all to see, and they must also be known (not
+anonymous) parties to prevent gaming of the system. That is, for a voting
+system to work we must have some trust in the voters, and that can either be
+because we assume they are trusted (we know their identity) or because they
+have placed something valuable at stake and we know their identity.
+
+In the case of puzzle solving, however, we do not require any special faith in
+stake, nor do we require known identities because the act of solving a
+difficult puzzle is itself a costly signal. The cost of solving the puzzle is
+moderated by the number of other participants against which all other
+participants are in competition, and in the ideal case the cost associated with
+compromising or capturing the system is greater than the value to be gained by
+going to the expense and trouble.

Proof-of-Work.md

@@ -1,6 +1,10 @@
 # Proof of Work
 
-In the "hold a competition" case of [leader selection](Leader-(s)election) we need a special kind of puzzle that has a few important properties:
+In the "hold a competition" case of [[Leader Selection]] we
+need a special kind of puzzle that has a few important properties:
 
-1. Difficult to solve, but easy to verify. A human-type puzzle that fits this description would be a jigsaw puzzle: it takes a long time to figure out where all the pieces go, but once complete anyone can check whether it is correctly solved by merely glancing at it.
+1. Difficult to solve, but easy to verify. A human-type puzzle that fits this
+   description would be a jigsaw puzzle: it takes a long time to figure out
+   where all the pieces go, but once complete anyone can check whether it is
+   correctly solved by merely glancing at it.
 2. Given a set of equally powerful contenders, the outcome should be random.

Smart-Contracts.md

@@ -1,13 +1,40 @@
 # Smart Contracts
 
-[DLTs](Distributed-Ledger-Technologies-(DLTs)) exist on computer systems, so arbitrary accounting rules can be placed into the system and executed when desired. A way to think of this is like spreadsheet macros. You can place a magic cell into the spreadsheet and have some code waiting behind it, the logic of the macro attached to that cell, and the output of entering data into that cell propagates across the spreadsheet (or perhaps across other, related spreadsheets, or even into other systems) according to the rules that have been programmed in the form of that macro.
+[[DLTs]] exist on computer systems, so arbitrary accounting rules can be placed
+into the system and executed when desired. A way to think of this is like
+spreadsheet macros. You can place a magic cell into the spreadsheet and have
+some code waiting behind it, the logic of the macro attached to that cell, and
+the output of entering data into that cell propagates across the spreadsheet
+(or perhaps across other, related spreadsheets, or even into other systems)
+according to the rules that have been programmed in the form of that macro.
 
-For this to work, of course, there must be some language defined by the spreadsheet system, and the spreadsheet program must have a way to communicate with a runtime engine that can interpret the commands programmed into the macro.
+For this to work, of course, there must be some language defined by the
+spreadsheet system, and the spreadsheet program must have a way to communicate
+with a runtime engine that can interpret the commands programmed into the
+macro.
 
-In a distributed ledger such as Ethereum there is a language called "Solidity" and it can encode commands for the "ethereum virtual machine" (EVM), similarly to macros executing in a spreadsheet.
+In a distributed ledger such as Ethereum there is a language called "Solidity"
+and it can encode commands for the "ethereum virtual machine" (EVM), similarly
+to macros executing in a spreadsheet.
 
-The Solidity language and the EVM suffer quite a bit from the same kinds of problems that can occur in spreadsheets, such as missing data having an unexpected impact on an outcome or having impossible looking outcomes based on the quirks of the underlying system. In the Gajumaru these problems have been fixed through the introduction of the Sophia language (which can be checked prior to execution and lacks the surprising corner cases that plague Solidity) and the Fast Aeternity Transaction Engine (aka "FATE VM").
+The Solidity language and the EVM suffer quite a bit from the same kinds of
+problems that can occur in spreadsheets, such as missing data having an
+unexpected impact on an outcome or having impossible looking outcomes based on
+the quirks of the underlying system. In the Gajumaru these problems have been
+fixed through the introduction of the Sophia language (which can be checked
+prior to execution and lacks the surprising corner cases that plague Solidity)
+and the Fast Aeternity Transaction Engine (aka "FATE VM").
 
-The important thing to understand about smart contracts is that instead of entering data into a spreadsheet cell to make the macro machinery execute, a "contract call transaction" must be sent to the blockchain. The leader will take the data in that transaction, put it into whatever function is to be called, and then update the ledger state the same way the spreadsheet program would update the spreadsheet according to a macro's rules. This is an "atomic" action, meaning all changes encoded in the function happen or none of them do.
+The important thing to understand about smart contracts is that instead of
+entering data into a spreadsheet cell to make the macro machinery execute, a
+"contract call transaction" must be sent to the blockchain. The leader will
+take the data in that transaction, put it into whatever function is to be
+called, and then update the ledger state the same way the spreadsheet program
+would update the spreadsheet according to a macro's rules. This is an "atomic"
+action, meaning all changes encoded in the function happen or none of them do.
 
-This idea of macros/smart contracts being able to encode complex actions within the ledger coupled with consensus being focused on all nodes agreeing to the sequence of events (what events happened in what order, and how that affects the ongoing state within the chain's data), all nodes can come to an agreement about what exactly has happened on the chain to date.
+This idea of macros/smart contracts being able to encode complex actions within
+the ledger coupled with consensus being focused on all nodes agreeing to the
+sequence of events (what events happened in what order, and how that affects
+the ongoing state within the chain's data), all nodes can come to an agreement
+about what exactly has happened on the chain to date.

Sophia.md

@@ -0,0 +1,55 @@
+# The Sophia Language
+
+[Sophia](https://git.qpq.swiss/QPQ-AG/sophia/src/branch/master/docs/sophia_features.md)
+is the smart contract language for the Gajumaru. It was first implemented on
+Aeternity, along with FATE, and then used as the basis for smart contracts on
+the Gajumaru. As we have noted that the EVM and Solidity language were created
+by people with little experience of virtual machines and language design, it
+seems fitting to list the main contributors to the Sophia language:
+
+- Ulf Norell, PhD, Chalmers University and Quviq AB, known for the creation of
+  the Agda programming language
+- Erik Stenman, PhD, Happi Hacking AB, distinguished member of the
+  High-Performance Erlang Group at Uppsala University, where he wrote the first
+  native code compiler for Erlang. Project manager for the 1.0 release of the
+  Scala programming language. Later Chief Scientist and CTO at Swedish
+  factoring giant Klarna. Author of The BEAM Book - the closest thing to an
+  authoritative documentation of the Erlang VM internals
+- Thomas Arts, CTO and co-founder of Quviq AB, Professor of Software
+  Engineering, Chalmers
+- Hans Svensson, PhD, Quviq AB, specialist in software verification using
+  testing, model checking and theorem proving
+
+Supporting contributions from:
+
+- Robert Virding, co-inventor of the Erlang programming language
+- John Hughes, Professor of Computer Science, Chalmers, co-founder, Quviq AB,
+  editor on the original Haskell Committee, co-inventor of the QuickCheck
+  property-based testing tool
+
+At first, the Aeternity team ported the EVM virtual machine to Erlang, into the
+AEVM, which became the first smart contract VM for Sophia. The Sophia language
+development was informed by the many known flaws in Solidity/EVM as well as by
+the massive collective language and VM design experience on the team. Quviq, a
+pioneer in property-based testing of software, used QuickCheck to validate many
+aspects not only of the Aeternity chain, but also specifically of Sophia, the
+compiler, and the VMs. To our knowledge Aeternity and Cardano are the only two
+major blockchains that have been tested using Property-Based Testing.
+
+After having run Sophia on top of AEVM for a while, Erik Stenman drafted a new
+VM architecture, which later came to be released as FATE (Fast Aeternity
+Transaction Engine). The key insight was that performance of a smart contract
+VM is decided to a great extent by the cost of setting up and managing
+blockchain context, as well as interacting with the chain. The instruction set
+of the FATE VM is very high-level and optimised for the Aeternity architecture
+using a family of high-level transaction types. The virtual machine is
+"functional", in the sense that “updates” of data structures, such as tuples,
+lists or maps do not change the old values of the structure. Instead, a new
+version is created, unless specific operations to write to the contract store
+are used. FATE also draws heavily on the functional nature and automatic memory
+management of the Erlang Runtime System, greatly simplifying its design and
+making its correctness easier to verify. The very high-level language of FATE
+also results in a much smaller footprint of smart contracts on-chain.
+
+Our experience from Aeternity is that the high sophistication of Sophia aside,
+users find the language easy to learn and a pleasure to program in.

Testnet-Node-Setup.md

@@ -0,0 +1,5 @@
+# Setting Up a Testnet Node
+
+## Devuan 6 (Excalibur)
+
+1. [[Install Erlang and ZX]]

The-Blockchain-Trilemma.md

@@ -1,25 +0,0 @@
-# The Blockchain Trilemma
-
-In engineering there is a famous trilemma such that:
-
-- A project can be cheap, fast or correct; pick two.
-
-In distributed systems there is a trilemma called "the CAP theorem" such that:
-
-- A distributed system can, at any given moment, have consistency, availability, or partition tolerance; pick two.
-
-The "blockchain trilemma" can be stated as follows:
-
-- A ledger system can be secure, distributed, or scalable; pick two.
-
-To understand the blockchain trilemma it is useful to first **understand** the CAP theorem. To expand on its three properties, to a distributed systems engineer they mean:
-
-- **Consistency**: all nodes will give the same response to a query
-- **Availability**: the system is highly responsive
-- **Partition tolerance**: if the network splits both parts will behave correctly
-
-The trouble is that the laws of physics conspire in such a way that any system can achieve only two of these three qualities at a time. The challenge for the designer is to pick which qualities matter most at a given moment rather than trying to naively achieve all three and simply failing.
-
-Given that [DLTs](Distributed-Ledger-Technologies-(DLTs)) are distributed systems, the CAP theorem applies to them. Algorand, for example, addresses the problem by favoring security over availability — their network simply stops during a sufficiently large network split, i.e. dropping the "P" in "CAP". As an example of how the CAP theorem forces the blockchain trilemma, consider that in the context of DLTs claiming "instant finality" it is relevant to inquire how they can guarantee that in the face of network splits.
-
-The Gajumaru solves the blockchain trilemma in a novel way that is related to both its architecture and its approach to [consensus](Consensus).

The-Sophia-Language.md

@@ -1,19 +0,0 @@
-# The Sophia Language
-
-[Sophia](https://git.qpq.swiss/QPQ-AG/sophia/src/branch/master/docs/sophia_features.md) is the smart contract language for the Gajumaru. It was first implemented on Aeternity, along with FATE, and then used as the basis for smart contracts on the Gajumaru. As we have noted that the EVM and Solidity language were created by people with little experience of virtual machines and language design, it seems fitting to list the main contributors to the Sophia language:
-
-- Ulf Norell, PhD, Chalmers University and Quviq AB, known for the creation of the Agda programming language
-- Erik Stenman, PhD, Happi Hacking AB, distinguished member of the High-Performance Erlang Group at Uppsala University, where he wrote the first native code compiler for Erlang. Project manager for the 1.0 release of the Scala programming language. Later Chief Scientist and CTO at Swedish factoring giant Klarna. Author of The BEAM Book - the closest thing to an authoritative documentation of the Erlang VM internals
-- Thomas Arts, CTO and co-founder of Quviq AB, Professor of Software Engineering, Chalmers
-- Hans Svensson, PhD, Quviq AB, specialist in software verification using testing, model checking and theorem proving
-
-Supporting contributions from:
-
-- Robert Virding, co-inventor of the Erlang programming language
-- John Hughes, Professor of Computer Science, Chalmers, co-founder, Quviq AB, editor on the original Haskell Committee, co-inventor of the QuickCheck property-based testing tool
-
-At first, the Aeternity team ported the EVM virtual machine to Erlang, into the AEVM, which became the first smart contract VM for Sophia. The Sophia language development was informed by the many known flaws in Solidity/EVM as well as by the massive collective language and VM design experience on the team. Quviq, a pioneer in property-based testing of software, used QuickCheck to validate many aspects not only of the Aeternity chain, but also specifically of Sophia, the compiler, and the VMs. To our knowledge Aeternity and Cardano are the only two major blockchains that have been tested using Property-Based Testing.
-
-After having run Sophia on top of AEVM for a while, Erik Stenman drafted a new VM architecture, which later came to be released as FATE (Fast Aeternity Transaction Engine). The key insight was that performance of a smart contract VM is decided to a great extent by the cost of setting up and managing blockchain context, as well as interacting with the chain. The instruction set of the FATE VM is very high-level and optimised for the Aeternity architecture using a family of high-level transaction types. The virtual machine is "functional", in the sense that “updates” of data structures, such as tuples, lists or maps do not change the old values of the structure. Instead, a new version is created, unless specific operations to write to the contract store are used. FATE also draws heavily on the functional nature and automatic memory management of the Erlang Runtime System, greatly simplifying its design and making its correctness easier to verify. The very high-level language of FATE also results in a much smaller footprint of smart contracts on-chain.
-
-Our experience from Aeternity is that the high sophistication of Sophia aside, users find the language easy to learn and a pleasure to program in.