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.


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


  • 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.
  • Maintains DNS records for dynamic IP's of peers.
  • WebDAV file system.
  • SOCKS4a for use with tor.

Get It

  1. legal: GPL license (with rscheme) or BSD (with chicken) – (contact us for other license conditions)
  2. factual:
    1. system requirements
    2. install from source

Use It

  • screen shots from starting the live system till modification of the personal web site.
  • see docs

In The Press

see blog entry 2015-11-04

History, People & Testing

There is an ongoing self test of the development network (which serves the website an others).

See here for old notes on people, history and details.


Lacking the resources to deal with SPAM, there are only two options by now:

  1. Leave your message here. (Up to 160 characters, don't forget to include your email.)

    If you are redirected to my personal page, the message arrived. (At most peers that is.)

  2. Use the askemos mailing list from This list is as well as the sourceforge repository factually abandoned since many years. I'm still subscribed, though there is zero traffic.

05 Nov 2015 Agreement vs. Blockchain

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.

25 Jul 2014 Demo:Wallet

There is a Demo Wallet in the works to show BALL implementing a payment system based on contracts.

19 Jul 2013 New website.

The old one has been retired.

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