QPQ-AG/public-wiki
12
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clean up terrible file names, make index exhaustive

Peter Harpending 2026-03-17 11:37:58 -07:00
parent a014c60748
commit 2da089c049
17 changed files with 262 additions and 90 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
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 Blockchain Trilemma]]
- [The Mint Function, Blockchain Inflation, and Currency Debasement](Mint)
- [[Blockchain Trilemma]]
- [[Consensus]]
- [[Finality]]
- [[Smart Contracts]]
- [[The Sophia Language]]
- [The Sophia Language](Sophia)

38
Blockchain-Trilemma.md Normal file

@ -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).

35
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.

0
Distributed-Ledger-Technologies-%28DLTs%29.md → DLTs.md

25
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.

0
Inflation%2C-Deflation%2C-Coins%2C-Tokens%2C-and-Prices.md → Flation.md

42
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

0
Installing-Erlang.md → Install-Erlang-and-zx.md

12
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.

31
Leader-Selection.md Normal file

@ -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.

0
The-Mint-Function%2C-Blockchain-Inflation%2C-and-Currency-Debasement.md → Mint.md

8
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.

39
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.

55
Sophia.md Normal file

@ -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.

5
Testnet-Node-Setup.md Normal file

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

25
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).

19
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.