Waku Store Questions

[D4nte]

I am trying to group questions for a given spec together, feel free to criticize the format and suggest a more practical one.

High availability/uptime

In https://github.com/vacp2p/specs/blob/fb198dc0e46c9ada1d4ddc8a73f431dd3ab978fa/specs/waku/v2/waku-store.md#L37, both high availability and high uptime terms are used. It is unclear (to me) what is the difference between both. I'd suggest to easier clarify or use a unique terminology if they represent the same concept.

Attack by omission

https://github.com/vacp2p/specs/blob/fb198dc0e46c9ada1d4ddc8a73f431dd3ab978fa/specs/waku/v2/waku-store.md#L46, the assumption that a node implementing the WakuStore protocol is made.
As we consider this assumption when defining the protocol, how do we protect users from nodes that are doing omission attacks?

For example, in the context of Waku being used to signal user that it is time to vote on a given DAO, FooDaO. Alice wants to minimize the number of voters, to exercise more influence with her own vote for example.

Alice is running several WakuStore nodes and knows that FooDAO voting notification are being sent now.
She then setup her node to omit any FooDAO related message while otherwise behaving as per protocol.

In this case, her attack could be successful depending on her WakuStore market share.

Note: if she cannot differentiate FooDAO messages to other messages, she could just omit all messages during the notification period.

Digest

The format used for the digest is not specified. It would be good to specify what is currently used by the implementation. Have you looked into multihash?

Received time in HistoryQuery

Considering that the queried node MAY use the receivedTime (as part of the index) to sort messages, it means that a querying node should always retrieve its whole history to ensure no messages are missed. Am I correct? Aren't we worried about bandwidth consumption in this instance?

[staheri14]

, both high availability and high uptime terms are used. It is unclear (to me) what is the difference between both. I'd suggest to easier clarify or use a unique terminology if they represent the same concept.

Availability of a system is defined w.r.t. its objective, e.g., in the store protocol the service availability relies on the fact that all the historical messages transmitted in the network get stored by the respective store nodes. To enable this, nodes participating in the store protocol are required to have high uptime (so that they won’t miss any messages). Note that while availability demands high uptime in this scenario, providing availability in some other systems may demand high bandwidth or computational power.

[staheri14]

Thanks for raising your concern re attacks by omission, I would like to mention two points:
1- This attack is valid under the active adversarial model which is not yet covered in the specs. The focus in the specs is the static adversaries. Such an attack should be certainly addressed in the next round of security analysis against active adversaries.
2- In the voting scenario, the correctness of the voting outcome must/can be verified by looking at the state of all the store nodes not only a subset of them.

Please let me know whether this addresses your question.

[staheri14]

The format used for the digest is not specified. It would be good to specify what is currently used by the implementation. Have you looked into multihash?

Nice point! (discussed in the call), please feel free to open an issue for this

[D4nte]

Done~ #301

[staheri14]

Considering that the queried node MAY use the receivedTime (as part of the index) to sort messages, it means that a querying node should always retrieve its whole history to ensure no messages are missed. Am I correct? Aren't we worried about bandwidth consumption in this instance?

In the implementation, messages are ordered based on the time and the querying node does not have to fetch the entire history (as we discussed in the call). Feel free to open an issue re this to be clarified further in the specs.

[D4nte]

Done~ #302