Network incentivisation log

Archive
1

In the same spirit as @pedro 's log for nix, I will try to keep regular updates on the progress for the network incentivisation swarm.

Currently we are at the point where we have a proof of concept of the contract we would like to use: GitHub - status-im/network-incentivisation . This allows nodes to register and votes on other nodes, and the contract will handle membership.
An earlier version of the contract is already used in status-react Add reading nodes from contract by cammellos · Pull Request #7869 · status-im/status-mobile · GitHub to fetch the initial bootnodes/static nodes/mailservers.

The plan towards an implementation is to have a simple end-to-end implementation and iterate over that, slicing the planning horizontally rather than vertically.

Currently we have a simple enough contract that is usable, and we are now focusing on service nodes.

Upon start up a node will:

  • register (or check if it is registered) with the contract (already implemented)
  • it will post a ping on a whisper channel advertising it’s address (already implemented), which can also be used as a mean of discovery (not for bootstrapping clearly)
  • it will check that other nodes in the contract do the same (already implemented)
  • it will report periodically to the contract and get rewarded if has passed these checks

The plan for this week is to have the nodes report to the contract on the result of the ping checks and be rewarded. Ideally by the end of the week we will be able to have some docker-images that anyone can spin up and they will be registering with the contract, start servicing and get rewarded if behaving correctly.

Once this step is done we will likely focus on improving some of the parts, so adding better checks, better rewarding system, hardening the contract against sybil attack or adding a way for user of the app to contribute to the SNT pool of the contract, but that’s still to be defined.

Research notes here: https://docs.google.com/document/d/10ZVIkYkM8_YwpEbxLX05pIcL8ISuZZvDPV6L_t27xgw/edit#heading=h.b9h1jmb28d8t

5 Likes
2

Two questions:

  • is there any kind of staking mechanism which would punish a misreporting/spamming node?
  • how are tx costs for contract registration covered?
3

at this stage of the implementation there’s no staking, nodes will just be removed from the list and will have to re register.

In the future that’s something we discussed, although other implementations get away without staking (DASH), so we haven’t made a decision yet, and we are open to any suggestion.

The price of the transaction (and voting) will have to be covered by the rewarding system (and needs to cover the costs of running a node), and will be paid off in SNT. How much nodes will be rewarded has not been decided, but it will be a function of the number of paying users, the number of nodes and possibly other factors.

1 Like
4

Progress as of today 17/04/2019:

  • Managed to get the modified versions of status-go running in a docker container
  • they now register with the contract and listen to whisper pings
  • they vote at regular intervals, checking whether they received pings from other nodes

Next I will verify that the voting removes the misbehaving nodes correctly and add a basic reward system.

5

Progress as of today 18/04/2019:

  • Tested contract & nodes on goerli testnet, 3 nodes joined the network, 1 went offline, it was removed from the list after a voting session, once back online it was added back to the list of active nodes after a voting session
  • Gas fee are currently fairly low https://goerli.etherscan.io/address/0x61f6d683be830617981ce5c9ea7cd2d1f22cf251 , but requires more testing and higher number of nodes to verify

Next I will work on a basic rewarding system, polish up the implementation and provide a docker image.

3 Likes
6

Progress as of today 19/04/2019:

  • Added a simplistic reward system and tested with 3 nodes, picked the first formula that came to mind which is: contractBalance / numberOfTransactionMadePerNodePerMonth / nodesToBeRewarded, each node is rewarded every time it votes (and is allowed to vote, which means it’s well behaved). We assume users of the app will be paying in a monthly subscription to use the service (configurable).

With the current settings (1 transaction per 10 minutes, 3 nodes), it would cover the transaction costs if roughly 2 eth are in the contract balance each month. Given 100 paying users that would be around 3 dollars monthly, (0.3 for a 1000 etc). 1 transaction per 10 minutes is also set just for testing, probably 1 per hour is what we’d settle on, but it’s too early stages to think about that.

This is all very rough and just wanted to get a very basic rewarding system, for the more economically inclined of you, suggestions are very welcome (looking at you @barry :slight_smile: )

Next I will polish status-go code and provide a docker image, probably at some point it would be time to formalize the rewarding scheme and make sure it makes sense.

1 Like
7

These are exciting steps in the right direction. Would love to see a write up or presentation on the reward system itself and the current design thinking behind it at some point.

1 Like
8

To clarify, what is considered a transaction? Are there multiple categories such as relaying messages, storing messages, retrieving messages?

Is a subscription for unlimited transactions or is there a limiting factor or subscription tiers?

Has any thinking been done around having individual nodes set their own prices? I think coupling such functionality with client side price X capacity based routing should incentivize new nodes to come online as demand grows and create a decentralized price discovery mechanism.

9

Thanks for the questions:

To clarify, what is considered a transaction? Are there multiple categories such as relaying messages, storing messages, retrieving messages?

Here I was only referring to the transactions made by the service nodes, to register and votes with the smart contract, not those made by clients.

Is a subscription for unlimited transactions or is there a limiting factor or subscription tiers?

Currently the idea (although we haven’t explored it deeply), is that it will be unlimited but we will have a fair usage policy (i.e you can send X messages per month, where X is what we think the upper limit, to avoid spamming), but pay-per-message/pay-per-data consumed is also an option.

Has any thinking been done around having individual nodes set their own prices?

Yes, we discussed this before, though I think we have a preference to shelter the nodes behind a subscription paid to the smart contract by users.
This allows us to decouple what the user pays for and how the money is used (i.e the user might be paying for a badge, extra functionalities, offline inboxing etc, and the money goes to the nodes for offline-inboxing/forwarding or any other functionality that we think it is useful to the network), which is inline with DASH and Loki for example, where nodes are not rewarded directly for the specific service or able to set their own prices, but they are expected to provide certain services, for which they are probabilistically rewarded based on how long they have been servicing without getting paid (part of the mining goes to them in DASH).

The decision was also made because of how whisper works, basically envelopes are flooded into the network and every node forward/receives them, so there are multiple path to a destination, on top of that the receiver is not known, which makes employing strategies such as http://www1.cs.columbia.edu/~mariana/papers/par.pdf for example quite difficult, and means that theoretically every node should be reward for any message sent by any user, as the workload is identical for each node.

Offline inboxing can be modeled as you described though and possibly we will go for a mixed mode, where nodes will be rewarded based on resource consumption as well, at which point they might be able to set their own price per envelope for example, but that’s still to be defined.

1 Like
10

Progress as of today 30/04/2019:

Code has been merged in status-go, I will provide at some point some instructions and a docker image so people can start playing with it.
Next steps would be probably to add some other checks (storage, connection etc) or look more deeply into the reward, not quite sure as of now what’s best, will be on holiday for the rest of the week, so some time to think about it.