Askemos

Help: This page shows how the referencing vocabulary definitions are maintained and interlinked for controlled consistency of documentation. Click on the hyperlinks to see how the terms are defined within the Askemos architecture. more… Tip: Remember the back-button!

This page has three main sections. (Note that the listings could be empty.)

  1. The first item displays a term, URL, text or picture.
  2. Followed by a (still unordered) listing of statements about this subject. (for details follow ">"-link)
  3. Separated by a horizontal rule a "reverse" listing of statements referring to this item in object position.

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 ").
do we need this link?
1724 see also >

Processing In Agreement

Once the transaction request has been received by at least the qualified majority of the commissioned peers (as controlled by the configuration of the service) the processing stages is entered.

All selected hosts will locate the associated contract (the source code) for the service. Then execute it to obtain updates to local state and further transaction messages, which might have to be sent.

However updates and messages are held back until the byzantine agreement protocol has reached the commit stage.

The agreement protocol requires two rounds of message exchanges (step "3" in the next picture) between those selected peers. Each message is signed by the peer approving the transition. Note that the users peer (representative) may or may not be involved here.

1041 comment >

Transition (Process Step)

An atomic element of the sequence of activities carried out by a process. Within a transition (a.k.a. process step) data from the input area is maped (transformed) into a change of data in the output area.

The details of that transformation are abstracted away. They are not visible when the transformation itself is understood as atomic and "black box".


Askemos Virtual Space description