Allow apps to verify data from Service Nodes

Build Research
1

A possible issue with the current model is that if a Service Node (SN) submits faulty data to an app, the app has no way to verify that the data is correct. Apps have to then completely trust a Service Node. This could be a big problem with corporations using Pocket because they may have mission critical systems that rely on good info and one bad set of data could set throw everything off.

I think it would be good for apps to have the ability to get multiple SN to submit data from a single request thus allowing the app to compare the answers to verify data. Therefore Apps themselves can compare the data from multiple SN, preventing an app from having to fully trust a single SN for good data.

This could also allow apps to choose to receive the same answer from multiple pools of SNs, thus allowing an app from having to completely trust a pool of SNs.

With this model, an app chooses how many responses it receives from a single request. If an app chooses to verify the results of 3 SNs, the one call would be considered 3 calls in terms of that apps allocated bandwidth. Apps can then choose if they want more single SN calls, or fewer calls that are statistically verifiable on the app level. The SDK could have a consensus mechanism to automatically accept the most common result, or not accept the data at all if one of the results is different. Below is a diagram to give a visual.

App%20verify%20data%20diagram
App%20verify%20data%20diagram1566×1372 246 KB

2

In this scenario the SDK or plugin should verify the 3 results and get the most concurrent one 2/3 right ?

3

Correct. In the diagram above, the app would choose the 2BTC as the result because it has the majority. Devs should have the ability to decide how many similar results constitutes a “verified” result.

4

In the protocol there is an after-the-fact mechanism, which is relay verification. It is not in the Service Node’s economic interest to serve bad data, because their stake will be slashed after the data verification process done by the Validator Nodes. If a certain app wants to implement this scheme, we don’t need to apply any protocol updates, as the dispatch sequence will return multiple service nodes that are available to service that particular app, which means they can manually request the same information multiple times (except for write state transactions, those can only happen once) and cross reference the response themselves, however it is pointless to do so on the client side, because the Validators themselves will do this same exact process during their verification of the request.