incentivization

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.

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 )

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 ).

Connecting Clients and Server

As a simple rule we can define:

$$The incubed network will serve your client requests, if you also run a honest node.$$

This requires to connect a client key (used to sign his requests) with a registered server. clients are able to share keys as long as the owner of the node is able to ensure their security. This makes it possible to use one key for the same mobile app or device. The owner may also register as many keys as he wants for his server or even change them from time to time. The key is registered in a client-contract, holding a mapping from the key to the server-address.

Esuring Client Access

Connecting a client key to a server does not mean he relies on it, but simply his requests will be serverd in the same quality as the connected node will serve other clients. 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 the connected 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 }$$

The servers will measure the $A\scriptstyle availability$ by checking periodicly (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}) \cdot {Cap\scriptstyle max}}{2 \cdot weight}$$

• $A\scriptstyle long$ - tha ratio between valid request received and sent within the last month
• $A\scriptstyle short$ - 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)
• $Cap\scriptstyle max$ the maximal Number 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 would handle the same amount as he servers and all clients would have a equal share. In order to prevent situations where 80% of the requests come from clients belonging to the same node while the node is only delivering 10% of requests in the network, we need to decrease the score for clients sending more requests than their shares. So for each node the weight can be calculated by:

$$weight = \frac{ {R\scriptstyle served} \cdot {S\scriptstyle total} } {{R\scriptstyle total} \cdot {S\scriptstyle connected} }$$

• $R\scriptstyle served$ - number of request serverd to one of the clients connected to the node
• $R\scriptstyle total$ - total number of request serverd
• $S\scriptstyle total$ - total number of registered servers
• $S\scriptstyle connected$ - number of registered servers in this cluster

Each node will update the $score$ and ther $weight$ for the other nodes after each check and this way prioritize incoming requests.

Registry