On Validation

Last Modified Avatar

Last updated by Tim Delhaes 2 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).
Private Web2 API
Google Sheets
Detect new row in sheet
Add row to sheet
Web2 Feed
The weather
Other Substrate
Other Blockchain
Moloch on Gnosis
Approved proposal
Create proposal
dApp Front end
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

Can't find what you're looking for?

Contact Us
Refreshed On: Aug 15, 2022 19:33:58 UTC+00:00