Why status needs POS

[barryWhiteHat]

Intro

At the moment status uses POW to rate limit messages. Where each user solves some proof of work in order to limit the amount of messages they can send per second.

Attack

Status is primarily used on mobile devices. These have limited compute and performance. Desktop computers and servers are both better able to perform this proof of work. They have a huge advantage over mobile devices and the entire status network. The difficulty of the proof of work algorithm could be adjusted up by an attacker with small AWS resources to the point where no mobile users are able to use it.

Peer scoring

The first solution attempt is to use P2P network to limit how many messages an attacker can add to the network. So things like

1. Each node will only accept x messages from every peer
2. If someone has been my peer for a long time they can send y*x messages.
3. If a peer sends be x messages every month i reduce their messages to x * z where z is less than 1.

Basically things like this attempt to reduce the amount anyone can send on the network.

However these defenses can be overcome by using bot nets. FYI botnets with millions of nodes exist.

So an attacker rents a botnet from someone and has each bot become a peer of a legitimate network. They then start sending x - 1 messages per month that are just garbage.

The network is not able to cope with all of these messages so the POW difficulty has to be increased.

other possible p2p rules

The network could prevent new nodes from joining the network but this would prevent new users from joining status.

Or the network could add a tag to every message based upon the peer that sent it. And limit or delay these messages somehow. Then every message on the network can be tracked back to its source node which removes the privacy.

RLN

The problem can be solved by replacing proof of work with a privacy persevering proof of stake like https://ethresear.ch/t/semaphore-rln-rate-limiting-nullifier-for-spam-prevention-in-anonymous-p2p-setting/5009

implemented https://github.com/kilic/rlnapp proving key less than 5MB , proving time less than 1 second on desktop and less than 3 on mobile. We think we can get proof time to less than 1 second on mobile with various optimizations.

Conclusion

I think that p2p is deeply scary short term solution which should be changed ASAP. Other attempts at mitigation seem to fail when an attacker with bot net or just many AWS servers acting as peers joins.

[oskarth]

cc @arnetheduck @decanus @dryajov @cammellos for thoughts and comments.

[corpetty]

I've talked with @barryWhiteHat in a DM. We think its' reasonable to start with async comms as we familiarize ourselves with this content. After that, it may be reasonable to have a talk with him to get into some details and subtleties associated with our particular use cases.

[oskarth]

As a reminder, here's the write-up for our previous investigation into this: https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks

Here's the list of current blockers https://github.com/vacp2p/research/milestone/2 - I closed a few of them that are solved with recent improvements.

One question that we need to answer for this is the UX story, outside of all the technical/project specifics. Assuming everything works out wonderfully, this means a user basically has to "signup" for an account to start using the app. This is a significant barrier to entry for new users, especially if they don't have any crypto and/or gas fees are high.

Is there some way to lower barriers to entry here? E.g. @jacqueswww has previously suggested a two-tier approach: https://forum.vac.dev/t/stake-priority-based-queuing/26

[barryWhiteHat]

One question that we need to answer for this is the UX story, outside of all the technical/project specifics. Assuming everything works out wonderfully, this means a user basically has to "signup" for an account to start using the app. This is a significant barrier to entry for new users, especially if they don't have any crypto and/or gas fees are high.

So we don't have to have a deposit for every user signing up. Here are some other ideas

1. Rate limit users joining in some other way, for example google accounts, unique phone number.
2. Start with 1 but once a user sends X messages per day ask them to place a deposit and more them to a new group.
3. The on chain component can be replaced with just a censhorship resistant place to sign up. Have status "deposit" many users without needing to put them all on chain. Then place a small deposit there. If the deposit is less than the cost of slashing a user. We can gossip the slashing around so that user is stopped from spamming and then later we can slash them when gas costs go down.

At the moment there is no limit on entry so replacing it with proof of something.

[jacqueswww]

One question that we need to answer for this is the UX story, outside of all the technical/project specifics. Assuming everything works out wonderfully, this means a user basically has to "signup" for an account to start using the app. This is a significant barrier to entry for new users, especially if they don't have any crypto and/or gas fees are high.

So we don't have to have a deposit for every user signing up. Here are some other ideas

1. Rate limit users joining in some other way, for example google accounts, unique phone number.
2. Start with 1 but once a user sends X messages per day ask them to place a deposit and more them to a new group.
3. The on chain component can be replaced with just a censhorship resistant place to sign up. Have status "deposit" many users without needing to put them all on chain. Then place a small deposit there. If the deposit is less than the cost of slashing a user. We can gossip the slashing around so that user is stopped from spamming and then later we can slash them when gas costs go down.

At the moment there is no limit on entry so replacing it with proof of something.

Yes good point initial staking as an initial proof of concept doesn't even have to run on main net :P Goerli for example could work. And you could redeem credits / SNT or whatever with a funnel + a good captcha when the network is under attack for users that don't have funds. Long term something like rlnp looks sweet.

[barryWhiteHat]

Yes good point initial staking as an initial proof of concept doesn't even have to run on main net :P Goerli for example could work. And you could redeem credits / SNT or whatever with a funnel + a good captcha when the network is under attack for users that don't have funds. Long term something like rlnp looks sweet.

So RLN has a ZKP to provide privacy and a smart contract to decentrlaize it. I think that its okay to temporarily remove the smart contract but removing the ZKP will lead to a lot of privacy concerns. Feel this is the way things should go for status to getting the ZKP integrated and improving it is high leverage thing to do right now.