Skip to content

incentivization

Jump to bottom
Simon Jentzsch edited this page Nov 24, 2018 · 27 revisions

Incentivization

The original idea of blockchain is a permissionless peer-to-peer network, where anybody can participate if he only runs a node and sync with the other peers. Why this is still true, we know that such a node won't run on a small iot-device.

Decentralizing Access

This is why a lot of users try remote-nodes to server their devices. But this introduces a new single-point of failure and the risk of man-in-the-middle attacks.

So the first step is decentralizing remote nodes by sharing rpc-nodes with other apps.

Alt text

Verification

While this removes the single point of failure it introduces the risc of trust. We cannot simply trust other RPC-nodes. In order to turn this into a trustless Architecture, each Server needs to provide verifiable proofs. (for Details See Ethereum Verification and MerkleProof )

Alt text

Incentivization for nodes

In order to incentivize a node to serve requests to clients there must be something to gain (payment) or to lose ( access to other nodes for it's clients ).

Ensuring access for clients

If we we require each client to sign requests then can lookup the clients address and connect it to a server node. Even though this client can still ask any registered node in the network, the quality or priority this client will be serves depends on the quality of service of his server node. This creates a very strong incentive to deliver all clients, because if a server node would be offline or refuses to deliver, eventually other nodes would also deliver less or even stop responding to requests coming from his clients.

To actually figure out which node delivers to clients, each server node will use one of the client keys to send Test-Requests and measure the Availability based on verified responses.

$${A\scriptstyle availability} = \frac{ R\scriptstyle received }{ R\scriptstyle sent }$$

Alt text

The servers will measure the availability by checking periodcly (like every hour, in order to make sure a malicious server will not to respond to test requests only, these requests may be send through a anonymous network like tor)

Based on the longtime ( >1 day ) and shorttime ( <1 day ) availibility the score is calculated:

$$score = \frac{ ({A\scriptstyle long} + {A\scriptstyle short}) {cap\scriptstyle max}}{2 weight}$$
  • availibilityLong - tha ratio between valid request received and sent within the last month
  • availibilityShort - tha ratio between valid request received and sent within the last 24h
  • weight - the weight of the incoming request from that servers clients (See LoadBalancing)
  • maxCap the maximal Numbner of open Requests the server can handle ( will be configured when starting the server )

This score is then used as priority, for incoming requests. this is done by keeping Track of the number of currently open or serving requests. Whenever a new Requests comes in, the node will do the following:

  1. check the signature
  2. calculate the score based on the score of the node it is connected with.
  3. accept or reject the request
if ( score < openRequests ) reject()

This way nodes will reject requests with a lower score when load is increasing. For a client this means if I have a low score and the load in the network is high, my clients may get rejected often and so have to wait longer for responses. And if I have a score of 0, they even will be blacklisted.

LoadBalancing

In a optimal network each server will handle the same amount as he servers and all clients will a equal share. In order to prevent situations where 80% of the requests come from clients bel,onging to the same node while the only delivering 10% of requests in the network, we need to decrease the score for clients sending more requests than their shares.

$$weight = \frac{ {R\scriptstyle served} {R\scriptstyle total} {N\scriptstyle total} } { {N\scriptstyle connected} }$$
Clone this wiki locally