On Validation

Last updated by Tim Delhaes 6 months ago

On Validation 

 
This document started from a conversation  as well as assumptions about security trade offs  in Slack.  
 
We are assuming that validation will be part of our  substrate runtime . In the case of Polkadot we assume we will be able to use  pallets . I believe we need to differentiate between different data types as well as their direction (inbound vs outbound). 
 
 

Type

Example

Inbound

Outbound

Private Web2 API

Google Sheets

Detect new row in sheet

Add row to sheet

Web2 Feed

The weather

Weather

???

Other Substrate

xxx

xxx

xxx

[a]

Other Blockchain

Moloch on Gnosis

Approved proposal

Create proposal

dApp Front end

gPay

xxx

xxx

 
 
The goal of Nexus is to make sure that the different connectors deliver the right and complete information in a timely manner. This requires some form of validation (review, reward, punishment and reputation) protocol. It should protect against intentional manipulation as well as unintentional failure just like any blockchain. While this requirement is usually associated with the “oracle challenge” it is only partially true for our requirements. Furthermore definitions like “timely” can vary between seconds (for blockchain events) and minutes (for new rows in Spreadsheets) as well as user settings. 
 
As a result, when looking at the above fifteen cases it is easy to realize that the validation strategy for each of them has to be drastically different. For example a new row in a data sheet should be detected within a minute while a blockchain event should be detected in real time.  
 
The amount of different types of connectors and the way they interact with other systems will grow over time. This requires the system to be upgradeable: adding new connection types including the validation process as well as modifying the validation process of existing connectors  
 
Given the nature of the different data types and sources different strategies are required for validations. For example, to validate an inbound blockchain event one could simply listen to one or more other nodes or blockchain APIs. Validating an outbound event to a webs2 api would require reading from the destination system and again validating that data. 
 
The amount of different types of connectors (and the way they interact with data) will increase over time. For that reason alone it is fundamental to build a system where validations processes are upgradeable. The initial system should consider parameters for this validation but can be launched without any validation at all, especially as long as it is a fully hosted solution like Zapier. In the long run these upgrades should be governed by the community. 
 
 
Notes by Tim 
Refreshed On: Dec 06, 2022 04:19:07 UTC+00:00