Askemos

Virtual Space Context

So far we established in natural language two universal properties of contracts we can rely on: a) contracts are immutable and b) can not alienate personal rights. In their simplicity this might appear almost useless.

Next we need to define a machine-executable (example) language for derived contracts. Again we will not reinvent any wheel. and adhere to Standard is Better than Better. This section introduces some glossary terms for further use.

Domain Model

Our the scope is defined as persons, be them juristic or human, interacting by means of communication. The "virtual machine" - or model of this domain - we use is well known and researched as "agent oriented", "event driven" and " actor model".

Topology

The Askemos space as seen by applications consists of nodes and edges. Nodes (termed places) represent actors while edges identify communication channels to other places.

Persistence

By holding a named edge (a.k.a. link) a source node expresses interest in continued existence of the target. (Effective locally to the source the target is to be remembered.)

The exclusively local data (e.g. the root) and contracted contacts are always preserved.

Operations by Effect

↗Idempotence of Analysis: just (re)reading changes nothing. The result is whatever output value is returned from the place. Any replica may answer.

↗Autonomoy of State: All information and operations upon nodes are actively replicated by the commissioned parties.

Elementary Operation

Actors undergo a transition when they receive a message . To enable decoupling of the application language and the core system their state is explicit maintained by the core. Actors are purely functional transformations producing any combination of a) intended state transition, b) messages to be sent to other actors and c) new actors to create. In each step reply function

reply = function(place, message)

is computed, where

  • reply: an aggregate expressing the reaction of actor to the incoming message.

    A programmer who is used to hardware operating system terms might think of the reply element content as a list all those system calls which the function needs to complete and which might modify values.

  • function: a two-ari function; defined by the governing contract type .

  • message: A read only accessor to the aggregate denoting the current input.

  • place: A r/o (read type request) or r/w (write type request) accessor to the aggregate denoting "this" place. Often called "me".

The core system takes the reply synchronizes with the other copies and - once and only if agreement is reached - applies updates and routes result messages.

language modules

  1. A minimal CoreAPI for services. The reply shall use to control the system.
  2. A almost arbitrary (but simple and general) language (a.k.a shebang ) to write those functions. Simple, general and standard (as in not "defined by implementation ").