About Askemos·design notes·documentation·download·On CD·thanks·support
ACM·BALL·ByzantineAgreement·CORBA·KommunikationsInfra·P2P·ProcessStep·TODO
AskemosDVM·AskemosHLD·DesignAnforderungVerfuegbarkeit·IntrusionResistant·LLD·NEWS·XMLStore·test

ByzantineAgreement

Byzantine Agreement/Protocol

A fundamental problem of distributed computing is that of simulating a (secure) broadcast channel (see also KommunikationsInfrastruktur), within the setting of a P2P network.

A byzantine aggrement 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).

If this sound too "technical", here is a real world application/implementation scrutinised.

Byzantine Agreement in Askemos

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

  • A ProcessStep 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 exclusive 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.

Further Work

Utilizing a setup or preprocessing phase it is possible to lower that requirement to some extend, Y. Lindell, A. Lysyanskaya and T. Rabin show http://www.wisdom.weizmann.ac.il/home/lindell/public_html/composeBA_abs.html upper bounds of utility of that approach.

TODO The 0.7.x version of BALL deploys HTTPS as node-node protocol. Availibility of a second message bus (from the references) is desired feature. The current implementation will be kept readily available and brought forward to protect against anticipated, future security bug in the alternate message bus, to be be deployed at the (accepted) cost of degrading performance until the bug is fixed.

References

Byzantine Generals Problem
Leslie Lamport, Robert Shostak, and Marshall Pease, ACM Transactions on Programming Languages and Systems, Vol. 4(3), July 1982, Pages 382-401
L. Kesteloot: "Fault-Tolerant Distributed Consensus" (1995).
Sintra (16. 4. 2002)
M. Naor and U. Wieder. A simple fault tolerant distributed hash table, 2003
http://citeseer.ist.psu.edu/560557.html
spread

a unified messaging bus (candidate for use in ball implementation).

The recovery algorithm of spread is quite similar to our implementation. The main difference is that when spread delivers a message to the application layer the corresponding Askemos event is the permanent commitment of a transaction (see ProcessStep).

Ensemble
Ensemble another unified messaging bus (candidate for use in ball implementation)
Sintra ( http://www.zurich.ibm.com/~cca/papers/sintra.ps )
A fault tolereant replication architecture based on ByzantineAgreement.
Sitar: http://sitar.anr.mcnc.org/
building intrustion tollerant systems from off the shelf components.
on (broadcast) group membership protocols
http://www.cs.colorado.edu/~mishras/research/papers/pdcs03.pdf
Bft http://pmg.lcs.mit.edu/bft/
A byzantine file system. (No byzantine processes.)
symetric cluster management
http://sources.redhat.com/cluster/faq.html
ibm in Zürich: http://www.zurich.ibm.com/csc/infosec/dti.html
--

http://epubs.siam.org/sam-bin/dbq/article/18708
--
http://www.cs.bham.ac.uk/~dxp/prism/byzantine/
--
A CORBA? based implementation:
http://beta.ece.ucsb.edu/immune/Immune.html
---

A small essay http://szabo.best.vwh.net/coalition.html
see also http://www.google.com/search?q=Byzantine+Generals+Problem

*related notes*
On hardening the underlying host system: http://immunix.org



border
last modification: Thu, 03 Aug 2006 13:17:16 +0200
authors: jfw,
document identifier: A849640f672ed0df0958abc0712110f3c
delivered to public at Thu, 11 Mar 2010 14:55:40 +0100
short comments

rss
pdf :: context view
search

debug-access.scm
27 Nov 2009subscriber
development
12 Jul 2009test
01 Jul 2009TrustCenter
30 Mai 2009SystemRequirements
01 Feb 2009AskemosResources
27 Dez 2008ProjectsOnThePlate
27 Dez 2008JKomG
27 Dez 2008SQLITE
26 Dez 2008FanOut
26 Dez 2008MIME
NetBSD
NOTE
02 Mai 2006AskemosTopMenu
18 Nov 2008StorageAdaptor
18 Nov 2008PStoreStorageAdapt
18 Nov 2008OperationTips
15 Nov 2008PCRE
04 Nov 2008ProgrammingLanguag
09 Sep 2008RelatedProjects
23 Jul 2008ModuleStructure05
17 Jun 2008NEWS
17 Jun 2008HTML
17 Jun 2008ACM
22 Mai 2008HTTP
22 Mai 2008BOSH
10 Mai 2008AskemosBibliograph
10 Mai 2008JerrysDreamAbstrac
20 Apr 2008XSLT
11 Mar 2008CodingStyle
10 Mar 2008
09 Mar 2008MIMEConverter
BSD
07 Mar 2008XML
06 Mar 2008SRFI
01 Mar 2008RFC4810
01 Mar 2008RFC4998
01 Mar 2008KondratieffWerk
04 Jan 2008service-level
04 Jan 2008NameSpaceDSSSLinde
24 Jun 2004KommunikationsInfr
BOINC



Add

About Askemos·design notes·documentation·download·On CD·thanks·support
Web Design by Schwill Dresden