From 4ff7b7a2085d8a74875d56db8401987b03d58629 Mon Sep 17 00:00:00 2001 From: SionoiS Date: Wed, 12 Jun 2024 11:06:17 -0400 Subject: [PATCH] waku sync first draft --- standards/core/sync.md | 93 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 standards/core/sync.md diff --git a/standards/core/sync.md b/standards/core/sync.md new file mode 100644 index 0000000..e02f606 --- /dev/null +++ b/standards/core/sync.md @@ -0,0 +1,93 @@ +--- +title: WAKU-SYNC +name: Waku Sync +editor: Simon-Pierre Vivier +contributors: + - Prem Chaitanya Prathi + - Hanno Cornelius +--- + +# Abstract +This specification explains the `WAKU-SYNC` protocol +which enables the reconciliation of two sets of message hashes +in the context of keeping syncronized two Waku Store nodes. +Waku Sync is a wrapper around +[Negentropy](https://github.com/hoytech/negentropy) a [range-based set reconciliation protocol](https://logperiodic.com/rbsr.html). + +# Specification + +**Protocol identifier**: `/vac/waku/sync/1.0.0` + +## Terminology +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, +“RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119](https://www.ietf.org/rfc/rfc2119.txt). + +The term Negentropy refers to the protocol of the same name. +Negentropy payload refers to +the messages created by the Negentropy protocol. +Client always refers to the initiator +and the server the receiver of the first payload. + +## Design Requirements +Nodes enabling Waku Sync SHOULD have the relay and store protocols enabled and +keep messages for at least the last hour. TODO do we need to say this, sounds like an impl. detail + +After each sync session, nodes SHOULD use Store queries to acquire missing messages. + +## Payload + +```protobuf +syntax = "proto3"; + +package waku.sync.v1; + +message SyncPayload { + optional bytes negentropy = 1; + + repeated bytes hashes = 20; +} +``` + +## Session Flow +A client initiate a session with a server +by sending a `SyncPayload` with only the `negentropy` field set. +This field MUST contain the first negentropy payload created by the client for this session. + +The server receives a `SyncPayload`. +A new negentropy payload is computed from the received one. +The server sends back a `SyncPayload` to the client. + +The client receives a `SyncPayload`. +A new negentropy payload OR an empty one is computed. +If a new payload is computed then +the exchanges between client and server continues until +the client computes an empty payload. +This client computation also outputs any hash differences found, +those MUST be stored. +In the case of an empty payload, +the client MUST send back a `SyncPayload` +with all the hashes previoudly found in the `hashes` field and +an empty `engentropy` field. + +### Storage Pruning +TODO? do we need to talk about that, seams like an implementation detail + +### Message transfer +TODO? do we need to talk about that, seams like an implementation detail + +# Attack Vectors +Nodes using `WAKU-SYNC` are fully trusted. +Message hashes are assumed to be of valid messages received via Waku Relay. + +Further refinements to the protocol are planned +to reduce the trust level required to operate. +Notably by verifing message RLN proofs at reception. + +# Copyright + +Copyright and related rights waived via +[CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +# References + - https://logperiodic.com/rbsr.html + - https://github.com/hoytech/negentropy \ No newline at end of file