I came across Hashgraph like consensus rfc which is for binary decision making in p2p networks while thinking about DOS protection in mixnets built using libp2p-mix.
What if Waku-Relay-RLN memberships or mixnet RLN memberships are managed via this consensus mechanism? Basically move the membership consensus off-chain.
Would it remove the need to interact with a blockchain which inturn reduces load on the nodes ?
After briefly discussing with @ugur , realized that slashing and staking lookups would still require onchain interactions.
This would require detailed analysis though, but would it make sense to use this in combination with peer-scoring(which would avoid the need for slashing)? Waku-Realy which uses gossipsub already supports peer-scoring.
Similarly, what if define local peer-scoring in mixnet and combine it with RLN memberships using hashgraph consensus? Any challenges seen here?
Are there any obvious points/issues i am missing here?
Thanks @ugur for entertaining this thought in a private chat!
Thank you @prem, for bringing this discussion point.
RLN has two crucial parts for on-chain interaction: the first one is holding the membership tree, and the second is slashing. Staking also requires on-chain items, but let’s skip it for now.
For membership management, we can update with consensus which identical local membership trees only change with the YES-voted proposals from the system. So, every peer sees the voted tree changes proposal, they update their local tree, and eventually they manage the same state. The leaf of the tree consistf og RLN commitments. We can fix the rate limit as the RLN V2 fixed rate. The first risk here, I see it looks like we should set some entry price to the membership, otherwise, spammers can create unlimited commitment for a sybil attack.
For slashing, in case there is spam, the peer can initialize a spam declaration with evidence, which is obvious with two different ZKP with the same nullifier. So, the system votes this action as a malicious behaviour and drops the corresponding commitment from the local trees.
I think the stake for Sybil is the key concern against using RLN here. Even if not economically, the peers need to cost something. Also @prem mentioned that the risk the peers can rotate their peer ID to bypass low peer-scoring. For that, we can consider linking peer-id to RLN commitment; they cannot rotate peer-id, but it may require some changes on the RLN circuit too.
agreed, what if we think of some sort of chain of trust model i.e each new user should be carrying some sort of referral by few existing users to indicate that the user can be trusted and allowed to be part of membership.
But then again, this would not prevent sybil completely as users can keep generating memberships and then refer to create new users. This makes attackers work little hard.
But chain of trust works in real world where identities are unique and verifiable. In online world especially when privacy is required, identities are not tied to any real world identities. Maybe by tying identity to something like ZkPassport or AnonAadhar this type of sybil can be prevented?
How about we take this kind of an approach for Logos-core+tech stack installations which would in-turn provide RLN memberships for modules that come by default such as Waku/Messaging, mixnet?
Another thing to think of is that RLN provides network-level protection exactly because it uses on off-network (and on-chain) membership-based access. This means that messages must be valid before entering the network or the message publisher faces punishment.
If we use a network-based mechanism (such as hashgraph) to gain consensus on this membership set, we will have to protect this mechanism itself against abuse (which may require an outer layer RLN ). Even if, say, the published commits must carry references to be valid, nothing prevents an attacker from publishing an unlimited amount of commits, whether they’re considered valid or not, with no means to punish them.
Note that deposits are just the first way to acquire a membership.
The consensus you need is:
how to get in
who is in
who is out (slashed)
If getting in is about doing some PoW, or showing some ZKP, then you don’t need the staking, but some reference data against which you validate the zkp.
Thanks, i missed that the routing layer itself needs to have RLN membership.
But for the mixnet RLN, i am wondering if we can assume that Waku/Logos-Messaging module already has an RLN included and hence can be used for gossipping its own memberships or nullifiers?
Then again if the Logos-Messaging is already having RLN and is using some chain for registration events, then the mixnet RLN can also use the same chain in order to manage the memberships.
then the mixnet RLN can also use the same chain in order to manage the memberships
My thoughts too. That said, our requirements of different RLN use cases (with differentiated rate limits) may eventually require us to maintain different “levels” of RLN membership, with only the routing layer (Layer 1 if you will :D) RLN requiring on-chain consensus and the rest using lighter off-chain consensus.
). Even if, say, the published commits must carry references to be valid, nothing prevents an attacker from publishing an unlimited amount of commits, whether they’re considered valid or not, with no means to punish them.