Re: [p2p-hackers] lockstep synchronization protocol problem
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@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.
participants (1)
-
coderman