PRBS protocol proposal - An incentivized Whisper like protocol for status

Archive
1

Intro

The goal of this proposal is to arrive to a whisper-like protocol that uses Incentivization instead of proof of work while maintaining most of Whisper’s characteristics. In addition it can provide a use case for SNT and continuous funding to Status for the development of the network.

This post is a high level overview ahead of a more formal specification.

Issues with Whisper POW

Whisper uses POW, this has several issues:

  • Not consistent: The generated pow value itself can vary depending on the device the client runs and even programming language used.
  • Wasted Energy consumption: Particularly bad for mobile devices.
  • No incentives to run a node: There is no incentive for nodes to forward messages, or even verify the pow. As such running full whisper nodes essentially depends on good will and as result there isn’t currently a well developed decentralized network nor any incentive for this to happen.

Incentivization

The Incentivization is done by what we shall call PRBS, meaning Pay to Receive, Burn to Send. Connections between nodes are payment channels, and the token amounts used are assumed to be micro-transactions. Message exchange between two connecting nodes update this state channel.

Incentivization of message forwarding

For a node to receive messages, it needs to open a state channel to a peer, signing which topics (a bloom filter) they are interested in, together with how much they are willing to pay for each message they receive in that topic, as well as the minimum cost of that message for the sender.

The values will vary from node to node depending on number of peers they have and which topics they are interested in. For e.g if node A has two nodes willing to pay it for topic X, then node A itself will have the incentive to pay more for topic X. Thus, more popular topics will likely have higher delivery rates and potentially be cheaper. There is also incentive for nodes to connect to more peers to get more potential ‘buyers’ for what they can forward.

Spam prevention

To post a brand new message a sender needs to burn funds. All messages need to be attached with a proof of burning of funds for this message. This acts as a spam prevention mechanism. The cost of sending messages must be higher than the cost of receiving for that topic.

Continuous funding for status

The burner address can be 0x0. However, as part of the protocol it can also be the address of the Status DAO or GmbH. This would introduce a use for SNT plus provide continuous funding for development of the platform.

Normal users & specialized nodes

normal users
Normal users can earn tokens by having their nodes forward messages, they can then use these funds to cover the cost of sending their own messages. This effectively should make the platform ‘free’ to use for most participating users. Another option is for the user to register with 3rd party (status?) that can provide some initial micro-funds enough to get started, or a gateway that provides this service in return for some action.

specialized nodes
Just like miners in Ethereum, dedicated forwarding nodes can be created by users to earn fees from forwarding messages, incentivizing a healthy & decentralized network.

Next steps

To do next:

  • Flesh out state channel & smart contracts (i.e spec + implementation), specially in regards to arbitration. burning funds, etc…
  • Model economics and or simulate network, For e.g:
    —> How much more expensive should be the cost to send be than the cost to receive in order to effectively prevent spam?
    —> If dedicated whisper nodes are launched, how much can they be expected to profit? In what network conditions?
    —> What is the predicted delivery rate and prices for popular channels vs small channels?
  • POC in murmur and/or statusd

Call To Action

We’re Looking for anyone interested in helping this effort through a pragmatic & iterative approach. Let’s build the future!

10 Likes
2

This is great! Once some of the details of the costs are spec’d out, I’d love to know as a user how long it would take me to get “free” messages while running a node. And what sort of uptime would I need? Mostly the reason for this, is that, as a user, i don’t really expect to pay for messaging. So, if the node is running in our pocket (ie in the Status app), it will have some very limited uptime, but would that be enough uptime to get me free messaging?

1 Like
3

I love this idea and I’ve been wanting for someone to try it for a long time.

It seems like it could be nearly 1:1 even. For every message you forward you earn one message of send. Or maybe 0.9:1 whatever it ends up being. That means you can start chatting within mere moments of connecting to peers because you’ll instantly be pummeled with messages to forward from your new peers.

Even if you chat a couple moments at a time, whenever you have your phone open, it seems like it could easily be enough time to earn a useful amount of chat points.

1 Like
4

I know @adam and @dmitrys have been thinking about this problem for a while.

As a potential next step could be interesting modeling PRBS using GitHub - ShrutiAppiah/Simulating-an-Economy-ABM: Simulation of reward tokens in a DAO ⚡️Employs multi-agent simulations and discrete-time Markov random fields.

2 Likes
5

The state channel implementation will be crucial to the efficacy of this model… and well as inform the rate of creating/closing channels with peers.

I’m definitely going to give this some deeper thought to try and find where the problems lie.

Great job Iuri for proposing this!

1 Like
6

very cool suggestion to write a spec based on this. love it. Simple, easy to understand for the end user.

here’s a great thread:

https://twitter.com/lwsnbaker/status/1070761288366665728

2 Likes
7

Excellent. Make hosting a specialized node into a Status mode and we have incentivized Status-desktop running.

One thing I’d add - there should be a generic “unreliable” channel, a lobby of sorts where people can post free messages, and they’re forwarded as resources allow or via altruistic nodes or via a queue, or a combo of all three. We don’t want people without the means to pay for prioritizing or receiving their messages (even if only dust is required, they still need to get the dust) to be left in a silent darkness as they open the app and try to start chatting. The teller network can help solve the problems of setting people up with starter funds, but given that a free starter batch of digital cash, BAT-style, would not be an option for the sake of spam prevention and accumulation of free funds, we’d definitely need a special free channel with a message queue maintained.

4 Likes
8

To really know this we need to model it and perhaps simulate it as well. I’m just sure that the cost of burning to send a message needs to be higher than the payment to receive due to spam. The amount of uptime needed will depend on the traffic in the network itself and number of receivers for the particular channel.

1 Like
9

We probably can’t be 1:1 due to spam. i.e an attacker could connect to at least 1 peer wanting to pay, and use that to fund his own messages. The cost to send has to be higher. At a limit it would be (∑payment_per_receiver)+ϵ but probably less if we consider multiple paths, mechanism to avoid duplicated messages, and more importantly the receiver being able to increase their own price tolerance as a spam prevention mechanism (basically the equivalent to whisper nodes increasing the minimum PoW)

1 Like
10

Agree, this is the trickiest and most sensitive part by far.

1 Like
11

So, ideally forwarding packages initially is quick enough to gain funds to send messages, and this way we get a ‘free’ system for ‘normal’ participants. There is always the possibility of supporting the old PoW side by side, for nodes that are willing to accept it.

2 Likes
12

Great idea! Just some thoughts off the top of my head.

I agree that Whisper PoW has a lot of issues. In addition to that, there are some other concerns regarding Whisper: not provable that it’ll scale to a reasonable number of nodes (broadcast based and quadratic bouncing messages); non-rigorous assumptions regarding anonymity (sender anonymity not guaranteed for global passive adversary; relay mode/bloom filter tweaking for perf leads to worse anonymity); little standing/research in anonymity communication protocol research (outside of Ethereum/blockchain space).

A lot of these concerns we are hoping to address in GitHub - w3f/messaging: Messaging for Web3, but this is a longer term effort. It might be useful to join this conversation in Element and #status-protocol, depending on what the time frame for this is.

Alternatively, it can be seen as a completely separate effort that can be swapped in as a component at the layer, so you could imagine Whisper/PRBS/PSS/Mixnet being different transport privacy solutions.

In terms of making sure this is maximally useful, it might desirable to have it compatible with (a new?) Whisper specification, as an alternative anti-spam mechanism. There’s a good opportunity here as there is a Whisper specification effort (Telegram group as well, PM me and I can you - might move though) [WhiSpeG] - Follow-Up: Kick-off call on 06.Dec.2018 - Ethereum Architects - Fellowship of Ethereum Magicians

E.g. one could imagine the anti-spam measure being a choice, and this mode would be a certain protocol version/capability. This could ensure Ethereum nodes in general run this protocol version, as opposed to just being a Status specific thing.

I also agree re challenges for state channel implementation, but this is also what is exciting! I need to chew on this for a while, but I’d like to be involved in the requirements/specification effort of this.

1 Like
13

There’s a similarity of goals here with P2P file-sharing networks like BitTorrent that want to quantify contributions to the network and incentivise certain behaviours. Worth a look at their proposed solutions:

14

How exactly would the burning work? You could do it with an on-chain transaction, but it seems like you’re looking for something much more “micro” than that. Some probabilistic scheme where you make a security deposit, then for each message attach a signed ticket and one week later there’s a 1/65536 chance (based on on-chain randomness) that this ticket could be used to delete a $0.5 deposit and give a commission to whoever includes the transaction?