[p2p-hackers] lockstep synchronization protocol problem

[coderman]

hi jinz,

i don't have time for a detailed reply but i thought a little more
info would be useful


On 3/28/06, UE=x <jinz at mail.ustc.edu.cn> wrote:
> I'm doing research about synchronization problem in P2P system,and the basic
> synchronization protocol is the lockstep protocol,and it use rounds to synchronize
> all the peer's movements,the problem is lockstep only synchronize peer's
> movements?what about the event created by all the peers?can it use rounds to
> synchronize them?and how to ?

i mentioned quorum systems and group key distribution to achieve a
shared and authenticated state among a group of peers that can be kept
in sync / coherent via frequent attestation (group re keying with
quorum consensus to distribute new keys).

there are many ways to implement this so i'll stick to conceptual
features / attributes and how this relates to a private group network
system we are implementing.

quorum authorities are those who sign all the other authorities keys
as part of the group key distribution.  quorum  or group members are
those who receive keys from one or more quorum authorities.

the quorum authorities maintain an index of all known / trusted group
members and the trust metrics assigned to the roles / services they
can perform.

and peer may solicit, provide and consume the services of another once
they verify they are trusted to do so.  they can contact any of the
quorum authorities (who have a full index and trust metric state /
graph) to certify the remote peer before doing so.

a group authorities may issue a revocation signed by his current group
identity key to disband the quorum / group.

if consensus cannot be reached within the next group re-key interval
(due to failure, lack of consensus at the meatspace / user level, or
malicious attack / DoS) the group must be re-keyed from the face to
face ground up and all reputation rebuilt.

the identifiers signed by the quorum during each iteration consist of:
- the key digests for each authority for the next group key exchange
- the sha-256 digest of the current base share file state image
(includes base OS and private group files/keys)
- the sha-256 digests of all delta based overlay filesystem images. 
these are optional among group members but mandatory for all quorum
authorities.

upon this base you can build / tie to various group synchronization
mechanisms that are strongly authenticated and yet still fully
decentralized.

i hope that helps.