Askemos

What we Pick from prior work

Askemos core structure is influenced by Erlang/OTP. This buys us proven concept, the "actor model", to create distributed systems which need to graceful degrade when the network is partitioned. From L3 we take the idea that processes can be persistent even over a system reboot. From functional programming we take immutable data and store this in immutable "booked memory" (a.k.a. "blockchains sans native crypto currency" these days - though these are not a prior work to Askemos). From Scheme we take a minimal initial language which we use to update shared state in booked memory. From state machines replication we take the concept byzantine consensus about shared facts. Finally we recognize the concepts "privity and privacy" and conclude to distribute shared facts precisely to parties relevant to the fact and possibly witnesses deliberately chooses by those parties.

BALL

Byzantine Askemos Language Layer.

Ball is the first implementation of the Askemos Distributed
Virtual Machine. It provides an autonomous virtual execution
environment for applications, which are executed like contracts
: Running processes proceed only in multilateral consensus
(byzantine agreement of replicas) among a quorums of equal peers.
Processes are persistent; they can communicate by passing
messages to each other. Human users appear therein as processes
which emit arbitrary messages at the persons discretion.

About

This white paper used to be the best one about the design.
While it's old already, it's still recommended as first reading.

Features

Fully distributed (P2P)

Tamper resistant: sustains up to 30% of disconnected nodes or even moles.

Synchronizes data (like e.g. bitorrent) and running processes.

Applications may be written in any language. The core system supports: a "
shebang" language to switch to users preferred languages and a
powerful experimental language.

The choice of consensus over a Merkle tree is the main difference to
recently upcoming alternative approaches based on the concept of a
proof-of-work a.k.a. blockchain. First consensus proofs the same
relevant property, the "correct state", to all relevant parties (the
assigned notaries). However it avoids the overhead and delay due to the
proof-of-work beeing just that: a lot of work to win in the lottery of minting
new coins.

Second: per definition a contract is an agreement, why not model it as such
instead of a lottery?

Furthermore some agent state may be private. Those agents are easily
confined to the notaries owned by the contractors. However it is no good idea
to store even encrypted state in a public, widely distributed blockchain.

The bugtracker is now better configured. But noticed: it can not yet display ongoing issues. Thus it fits well for personal and soho use, but here this is a serious limitation.

The new site now under construction using hoist, which is an
experimental application, but at least it runs reliably atop of
BALL in our setting (nine peers, most of them are small, ARM
based plug computers).