Network incentivisation - First draft

Archive
1

Network incentivisation - First draft

In this document we described what we have been researching so far, and we give an example implementation in order to get a feel of what it might look like.

Feedback on the principles is most welcome, and also on the potential implementation, although this is just an example, parts of it might make it in the final cut.

For some background reading on the work done: Network incentivisation current state - HackMD

A very similar effort has been undertaken here as well https://loki-project.github.io/loki-docs

What problem are we trying to solve?

Currently the status-network is mainly supported by company-run nodes/mailservers. Without the functioning of these nodes, the status app will likely be unusable.
This is not a desirable behavior as we want the status-app to be able to survive Status. Effectively this means that Status would act much in the same way as the Ethereum foundation, potentially running only the bare minimum services to ensure the continuity of the product (i.e a few bootnodes), while the heavy lifting is done by the community.
In order to achieve this, some form of incentives are necessary.

Type of incentives

Currently two kind of incentives have been identified as promising:

  1. Pay for offline messages
  2. Pay for forwarding (essentially pay to send)

Both come with a set of benefits and tradeoffs, and can be used on their own, or in combination.

Pay for offline messages

This simply means that a client who wants to receive messages that have been sent while the user who offline, will have to pay for this service.
The payment can be in SNT, or other options have been considered (stickers for example). Here some UX exploration can be done to understand whether users would be willing to pay for offline messages, and what is the most convenient option for the user (automatic subscription, pay-as-you go etc).

This offers a lower entry-bar with respect to pay for forwarding, as users who are not interested in offline messages, would potentially still be able to use the network, and only pay for offline messaging if needed, which works much like a freemium model.

The drawback of using exclusively this approach is that it relies on the assumption that enough users will be paying for offline messages to justify the incentivised nodes to forward messages at their own expenses.

Pros

  • Medium entry barrier for new users (can receive messages only when online without paying)
  • Better darkness than pay-to-send
  • Don’t need to be using status to run a node
  • Low threshold of users needed to be profitable
  • Not tied to the transport layer

Cons

  • The benefits of offline inbox needs to outweight the cost of forwarding messages, if used exclusively
  • Free-rider problem
  • Does not solve spam problem

Pay for forwarding

This is similar to what validity labs is doing with their payment layer, essentially a client pays for each packet sent to the network, and every node that forward the packet will receive a share of that payment.

This method has some clear benefits, it is more comprehensive than pay-for-offline messages and it works as a spam prevention mechanism.
Some of the drawbacks is that is more tied to the transport layer (whisper in our case), has a higher entry barrier for new users and given the nature of whisper, is not easy to adapt as the packet is flooded to the whole network.

Pros

  • Works as spam prevention
  • No free-rider problem
  • Highest sustainability
  • Don’t need to be using status to run a node
  • Low threshold of users needed to be profitable
  • Conceptually simple (offline messaging could be just be paid by receiving messages)

Cons

  • High entry barrier for new users
  • Difficult to achieve darkness
  • Difficult implementation with current transport
  • Tied to transport layer

Potential implementation

Data sync layer

A data sync layer is not strictly speaking necessary to achieve this, but it will certainly help with a few things:

  1. Homogenize the interface between nodes & clients. Ideally we want normal peers to act altruistically as “mailserver”, and propagate data.
  2. Being specific on what we are interested in. Currently timestamps are used to query for data, a data sync layer would add message-ids on top of that, which can help in being more accurate (potentially saving bandwidth)

Requirements

  1. It should be seamless for desktop nodes to help in the network
  2. Peers should be useful even if they don’t have 100% uptime
  3. Not too coupled to the current transport layer

Implementation

Peers will only pay for offline messages at first, as that is probably the simplest problem to solve and does not ties us to whisper.

Nodes that would like to be paid for their service, will stake a certain amount and will be added to the pool.

A shared fund will be created, and part of this fund will be used to incentivise all nodes in the network, while the rest will go

Periodically each node in the pool will be checked randomly for two tests:

  1. A bandwidth test (for example https://loki-project.github.io/loki-docs/Advanced/SwarmFlagging/)
  2. A storage test (for example Mailservers and proof-of-uptime - HackMD or https://loki-project.github.io/loki-docs/Advanced/SwarmFlagging/)

A responsibility of nodes in the pool is also to be checking other nodes for well behavior, and report misbehaving nodes.

This two checks will ensure that the node is forwarding and storing packets.

Clients who are willing to pay for offline messages will select one or more node in the pool, based on the successful tests they passed, and connect to them.

On request of messages, they will pay to a shared fund, and give a receipt to the mailserver, which can be reedemed to get a compensation from the shared fund or could be a separate transaction, depending on how we decide to have clients pay for messages.

Part of this shared fund will also be distributed equally to those nodes that have passed the checks, favouring those that have consistently passed those tests, in order to incentivise uptime.

From a node perspective, once started it will join the network and potentially sync messages, and start forwarding/serving messages.
It might also be subject to tests, the result of which will be recorded by other nodes, and eventually it will be rewarded if well behaving.

A node that is not interested in being paid for their services, say a desktop node that has only short uptime (less than an hour at a time), and wants only to act altruistically, without any guarantees of uptime etc, can simply do so but will not rewarded for their services. Clients will have no assurance that it is a well behaving node, but can still connect/retrieve data in the same way they would from a node in the pool, potentially at no cost.
Desktop nodes that have a longer uptime (> 1 hour), can participate as paid nodes if they wish to do so.

Next steps

Once we settle on a strategy, it would be time to flesh out a POC and dig more deeply into the details and the nuances. At the same time we can explore the UX components to get a better perspective on how it will look like from a user perspective.

This is light on implementation details as that’s not yet our focus, we would like to first gather some feedback on the direction taken, please let us know!

6 Likes
2

For private messaging I see an implementation path:

  1. When someone wants to ping someone as offline inbox, they would sign an authorization, with message content hash, of payout to the mailnode that is supposed to deliver that message and to the message receiver, by requiring also message receiver signature.
  2. If receiver gets message, it can compute hash and sign that message hash with mailnode address, giving it back to mailnode.
  3. Mailnode can commit inchain (or possibly in state channel) for the changes.

This would work because:

  • whoever wants to send a message have the incentive of paying that message to be delivered, this is only needed for offline inboxing.
  • This cost would go mostly to message receiver (simillar to t2t) but part would be split with the “mailnode”, so they have incentive of delivering the signature.
  • When you are messaged back you would get funds to message others.

This might require an inchain registry of public keys hashes → mailnode uri, so they know what mailnode to use.

Tribute to talk compatibility

T2T could use the 50% payment, meaning that if the value paid to receive that message is bigger than whats needed, it would sign the message received signature, otherwise not.

The mailnodes would know the minimum that pubkey accept from new users, however not if that user is allowed (mailnode dont know user contact list). To workaround this a signature from message receiver could be presented to mailnode for it know that this user already had paid the T2 and therefore can pay only the cost of deliverance.
In case that sender dont have paid T2T, it would sign a payment with T2T value to receiver, and a normal deliverance cost to mailnode address.

3

By who?

To who?

Sorry for these short questions but from what I remember they are fundamental to well-define the strategy. If a single entity will be a curator, that’s easy, otherwise it might get as complex as writing our own PoS algorithm.

What if a mailserver takes a receipt but does not respond? (because of network issue or a selected mailserver is malicious)?

Generally, it’s a very good description but I would love to see more details how dishonest mailservers and clients will be handled. I don’t think this is implementation detail and it should be discussed before going further.

In my opinion, “Pay for forwarding” is the way to go because even if we implement payment for offline messages, we won’t fix other fundamental issue which is spam prevention. IMO this is more crucial problem to the whole network than offline messaging, which might seem like more important now but it’s just from the UX perspective.

Another interesting approach is to mimic your social graph on the network topology (I believe scuttlebutt does something like that). Generally, the idea is to form a minimal network to receive and send messages between your friends first and then build more robust network which could fulfil other properties like darkness. The threat might be that if the network is attacked, it will lose its additional properties.

4

Thanks for the feedback, mind that the implementation proposed is an example, so it hasn’t been fully fleshed out, having said that, I don’t think we are breaking new ground, and similar systems already exists (dash masternodes, nucypher, loki’s etc), so we know it’s technically feasible, although challenging.

By who?

By other nodes participating in the network, we can decide on whether they will be picked at random (both, src and target, based on some entropy based of group membership for example etc), and perform active tests, or if the tests are passive, all the nodes might be participating.

To who?

To all the nodes in the network, nodes that are reported as misbehaving by more than 50% of the testers will be excluded and won’t be able to collect rewards.

What if a mailserver takes a receipt but does not respond?

You can minimize the risk by splitting in multiple receipts until it’s not convenient for the mailserver to act maliciously. i.e. you give one receipt for envelope each pays 0.2 SNT, you only give the receipt upon receiving the previous message.
Worst case scenario you lose 1 receipt 0.2, at which point you are not going to use that mailserver again, if that happens frequently.
Other solution are possible I guess, this is just the first that comes to mind.

otherwise it might get as complex as writing our own PoS algorithm.

I think this hit the nails on the head, what I think it would be the best solution is to have this status-node offer different services (forwarding/offline inboxing), and be rewarded by a shared pool of SNT.
The idea is to decouple how the money gets into the shared pool (it can be through paying for offline services, burn to send, donations, extra features for example, stateofus.eth domains etc), and what it is used for.
In that way, we can change the way it is used, from the way it is collected (i.e you pay for offline messages, but you reward for forwarding and offline messages).

This is complex, there’s no question about that, but also has been already implemented (dash, loki etc), so we are not breaking new ground, and allows us to be flexible about what actions we want to incentivize.

In my opinion, “Pay for forwarding” is the way to go because even if we implement payment for offline messages, we won’t fix other fundamental issue which is spam prevention.

I agree that Pay for forwarding is important, and likely more important than pay for for offline messages, but it’s not what I would start with, I think it’s a much more difficult problem to solve both technically and in terms of UX.

Having said that, the solution proposed does not preclude pay-for-forwarding, as nodes are already rewarded for forwarding, from the shared pool. We can always implement burn to send, where you are sending money to the shared pool, on top of that, and possibly have a rate-limited allowance for messages that don’t have a proof of burn (to lower the entry bar). Essentially by decoupling what users pay for and how the nodes are rewarded we can always pay-for-forwarding on a later stage.

1 Like
5

As part of #368-token-economy I have created two interactive notebooks attempting to create economic models of the above specifications. They can be found at:

and

let me know if some assumptions are completely off and feel free to comment, fork and suggest in the notebooks directly.

4 Likes
6

@barry thanks! That’s very insightful!