chore(rln-relay): update message validation

[rymnc]

Background

Based on -

• RLN: strengthen security of rln_identifier vacp2p/research#152
• RLN: strengthen security of rln_identifier Rate-Limiting-Nullifier/rln-circuits#1
• fix: update external_nullifier generation Rate-Limiting-Nullifier/rln-circuits#2
• refactor(rln): update APIs after circuit update vacp2p/zerokit#84,

Details

Messages will be sent with rln_identifier, epoch, and external_nullifier as usual, however the epoch is no longer used as the external_nullifier. We need to hash the epoch and rln_identifier (poseidon([epoch, rln_identifier])) to get the external_nullifier, which we compare with the external_nullifier sent along with the message.

Acceptance criteria

• We correctly validate external_nullifier in Waku RLN Relay

[rymnc]

@s1fr0 I'm not sure if Poseidon was implemented for nim. I did find this in rln.nim -

nwaku/waku/v2/protocol/waku_rln_relay/rln.nim

Lines 143 to 150 in 2b1741e

	proc hash*(ctx: ptr RLN,
	input_buffer: ptr Buffer,
	output_buffer: ptr Buffer): bool {.importc: "hash".}
	## it hashes (sha256) the plain text supplied in inputs_buffer and then maps it to a field element
	## this proc is used to map arbitrary signals to field element for the sake of proof generation
	## inputs_buffer holds the hash input as a byte seq
	## the hash output is generated and populated inside output_buffer
	## the output_buffer contains 32 bytes hash output

but it's keccak. Maybe worthwhile to expose the poseidon hasher via ffi as well?

[rymnc]

@s1fr0 should we move this issue to the next release given that there are pending circuit improvements which will change the scope?

[s1fr0]

@rymnc Agreed, although I believe exposing Poseidon is a good idea regardless.

[rymnc]

Reference issue in zerokit: vacp2p/zerokit#110