Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Description of GossipLog in the context of Waku #68

Open
ABresting opened this issue Nov 27, 2023 · 0 comments
Open

Description of GossipLog in the context of Waku #68

ABresting opened this issue Nov 27, 2023 · 0 comments

Comments

@ABresting
Copy link

ABresting commented Nov 27, 2023

Introduction to GossipLog

GossipLog, as part of the Canvas project, is a decentralized, authenticated, multi-writer log designed for peer-to-peer applications. Functioning as a replicated data store, a database transaction log, or even the execution log of a virtual machine. GossipLog operates across various environments, including browsers using IndexedDB, NodeJS with LMDB, and in-memory systems. Its design incorporates a causal dependency graph for message structure, ensuring delivery of messages only after all their transitive dependencies are met, while also requiring deterministic self-authentication for logs.

Distinction Between Waku and Canvas Messaging Systems

Waku Message Structure

In the realm of Waku, the message possesses a unique structure, which includes a timestamp attribute. This feature is critical for establishing a chronological order of events.

Canvas Message Structure

Conversely, the Canvas message diverges significantly. The absence of a timestamp necessitates an alternative approach for ordering messages, which Canvas addresses through the implementation of logical clocks.

GossipLog: Operational Mechanism

Message Transmission and Causal Ordering

GossipLog operates at the libp2p level, transmitting messages to peer nodes. The lack of timestamps in these messages led Canvas to adopt logical clocks, enabling the establishment of a causal order based on transitive dependencies of messages i.e. their parents.

Conflict Resolution and Prolly Tree Construction

Upon causal ordering of the messages, if any conflict arises then it is resolved using some application-specific logic to obtain an order. The culmination of this process is the formation of a Prolly tree, a data structure that is instrumental in sharing differential updates across nodes, ensuring data consistency and currency.

Implications in Waku Protocol

In the context of Waku, the timestamp attribute in Waku message can help prepare an order of events such that a Prolly tree can be constructed using it. Based on different indexes the Prolly tree can cater to specific data to synchronize.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant