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.
byzantine agreement
759 is a > Consensus protocol
1475 description >

A fundamental problem of distributed computing is that of simulating a (secure) broadcast channel, using an insecure network.

A byzantine consensus can always be reached, if more than 2/3 of the parties are honest, i.e., cast vote for the correct result according to their actual input (which in turn might be falsified).

Askemos Implementation

TODO: This section needs to be moved into the "details" area.

The distribution uses a home grown implementation, which was originally intended to live only until some ready-made library would be easy enough to be reused. It abstracts over many aspects of the protocol implementation and just tries to do something reasonable. In practice it is not that bad, though rather slow.

Askemos deploys atomic broadcast protocol (see Sintra section 2.2) to synchronize process steps's with slight variations:

A transition is defined in such a way, that the binary value to agree in the voting (the checksum of state changes during the step) is often deterministic. Therefore the agreement protocol does not need to proceed in (possibly infinit many) rounds.

"Often deterministic" means here, is deterministic, if it depends exclusively on the input and internal state of the process. But if, for instance, the process reads additional input with "fetch" while processing the message, or depends on local values like the current time, it can become non-deterministic. See the accuracy test for actual measurements of such a case. The BALL implementation could easily proceed in additional rounds as standard byzantine algorithm do. I don't think additional rounds should be made standard behaviour instead we should put that into applications control.

If the network is fragmented messages can be lost. If nodes miss - one by one - the final ready message in the agreement, the network can get out of sync in such a way, that resynchronisation becomes impossible. The BALL implementation extents the echo/ready messages in such a way, that the last phase can be recovered.

1501 kind/genre/type > General will
2224 alternative > Agreement

Tendermint kind/genre/type