TheGraphcast

Waku
1

heGraph intends to use Waku for the Graphcast. Details here: GRC-001: Graphcast - a Gossip Network for Indexers - Graph Request for Comment (GRC) - The Graph

Several requirements have been identified from their use case. We will discuss the requirements and possible solutions here.

Original document: ipfs gateway.

Replay Attack Protection

Attack Scenarios

Bob repeats transmission:

  1. Alice sends message M
  2. Bob saves M, forward it as part of Waku Relay protocol
  3. Bob re-sends M at a later time

Bob delays transmission:

  1. Alice sends message M
  2. Bob saves M, does not forward it (delays message, possible sibyl attack in progress)
  3. Bob sennds M at a later time.

Proposed Design

a. M’s timestamp is checked and drop if too old
b. block hash is included in M, block hash existence is verified (Ethereum mainnet).

Remarks

  1. Can you please clarify the context of the replay attack and the difference with past message injection? It is difficult to setup a replay attack countermeasure when the nature of the message is not defined (ie, login, asset transfer, etc). Are the scenarios describe above correct?
  2. In the proposed design, no correlation is made between the timestamp of the message and the block hash. Is the intent for the message timestamp to be equal to the block’s timestamp?
  3. Note that the reference implementation of Waku Store (nwaku) drops messages that are older than 20s (but I believe it is not your intent to use Waku Store).

Past Message Injection

Attack Scenarios

  1. Alice sends message M1
  2. Bob saves M1
  3. Carole joins network
  4. Alice sends message M2
  5. Bob transmits M1 to Carole
  6. Carole thinks M1 is the latest message from Alice

Proposed Design

Include a nonce to the messages.

Remarks

  1. The Waku Store protocol enables node to retrieve cached messages from services nodes. This could assist with herd immunity has Carole could retrieve the most recent messages from another node when joining the network
  2. Are you able to describe the nature of the messages being sent? Could the timestamp be used as a nonce (if signed by the sender).

Validate Message Sender

Design Requirement

Only accept/forward messages from a pre-defined list of senders.
In this context, senders must:

  • have a graphAccount
  • have a stake greater than minStake

Remarks

  1. We have recently started to work on a way for application to design their validation logic: Application Defined Message Validation · Issue #141 · vacp2p/research · GitHub
  2. If privacy is preferred, then it may make sense to enable senders to join an on chain zk group if they match the given requirements and have Waku use the zk group as a sender validation reference, similar to/using RLN.
1 Like
2

Hi Franck, thanks very much for creating this post!

I would generalize the nature of the messages in this context to be status update on off-chain values. Say that a peer has produced an erroneous proof locally and send the proof to the network, then when we consider this message we would like to make sure this error is not from the past, either it is a repeated message or a relayed message.

When an observer receive a replayed message, it rejects the seen messages by checking local history. Past message injection is a specific instance where there isn’t a local history to check for sequencing.

We are currently handling this concern by checking signed payloads (nonce which is assigned to system unix timestamp, block number, and block hash) after receiving the message, and dropping the first message from new peers.

Message block number is used for sequencing and grouping messages, and the block hash is used to verify that the message cannot be sent before the block is produced. This check would then reject messages when sender produces invalid block information.

This sounds like a great idea - we currently use a registry smart contract that doesn’t provide privacy at the moment, and we check the sender qualifications afterwards. I would be interested to return to this when we consider privacy in relation to reputation systems.

Amazing stuff! will keep track of the issue.

These are very helpful remarks. We recently finished a proof of concept using waku relay, for an example use case. Thus I would like to invite you to check out our repo and we are open to any suggestions. We are starting to plan out a roadmap for the SDK and a few use cases, so this is also a good time to reconsider Waku Store vs RLN as Waku Store seems to suit well for messages with historic values and comes with other security benefits. thanks!

1 Like