Data Security
An important aspect for data consumers is the authenticity and security of the data they are receiving. TSN establishes a way for Adapters to filter data based on conditions that isolate responses to only include data with a certain level of verified authenticity and quality control and/or data providers with a certain reputation. For applications that favor a higher programmatic and process trust model, this mechanism of data selection based on security metrics ensures developers and data consumers are only exposed to acceptably secure data. On the contrary, should data be nascent or exotic, these participants can opt to increase human trust assumptions in return for data utility.
Authenticity
TSN incorporates cryptographic mechanisms that strengthen data security.
Cryptographic signatures are associated with data streams, allowing data consumers to verify that data is authentic to the TSN in various software environments, especially on foreign decentralized systems. This is inherent to the Oracles involved in the TSN.
Beyond this, authenticity is also highlighted through specific node technology that Data Providers utilize to prove the authenticity and integrity of their data. Verification of these proofs occurs within the TSN, after data submission, and before data commission to storage. Successfully verified and accepted data improves the Data Provider’s reputation within the TSN.
To facilitate this verifiable transparency [9] into the Data Provider’s data source, two cryptographic primitives are utilized:
Provenance and Integrity proofs anchored in the Elliptic Curve Digital Signature Algorithm (ECDSA) primitive can surface alongside data to be committed to the TSN. With this, the TSN can distinguish between the Data Provider and the official first-party publisher of the data. This is especially necessary in circumstances where data is sourced from decentralized physical infrastructure networks (DePINs), where devices or centralized systems unassociated with the Data Provider are the first-party publishers.
Authenticity proofs—essential for shedding light on real-world and Web2 data—through the Multi-Party Computation Transport Layer Security (MPC-TLS) primitive, are suitable when integrating private, or public API data with the TSN. This proof generation process allows for the TSN to alleviate trust in the Data Provider and ensures tamper-resistance between the off-chain API or TLS-enabled endpoint and the TSN. The authenticity proof verification within the TSN yields the timestamped authentic HTTP request and response conducted off-chain by the Data Provider and guarantees the data is authentic to the API accessed by the Data Provider.
Verification logic for these cryptographic attestations is embedded within the TSN and called upon within Adapters.
Quality Control Measures
Truflation is committed to providing an environment that ensures the delivery of accurate and highest-quality data. TSN Adapters follow a basic quality control protocol during Data Processing that eliminates fraudulent data. When data is gathered from the Data Provider, Adapters begin to scan it for potential red flags using a set of predetermined verification algorithms:
Data presence: Adapters will check if the Data Provider has ensured at least N number of consecutive responses over a T period of time.
Historical data comparison: Compare received data with previous responses over a T period of time to assess consistency.
Current data comparison: Verify if the received data is not identical to the previous response or is not missing.
Data deviation: Adapters will verify if the received data does not deviate from the previous result by some predefined percentage either positively or negatively.
Authenticity: The aforementioned outline of cryptographic authenticity verification on data provision contributes to quality control.
Verification processes can be extended or changed to accommodate the business logic behind received data. Adapters will begin to perform these verifications in real time. If the business logic requires, the verification can be performed when the Data Stream is created or with a 24-hour delay. With the 24-hour delay, Adapters will ensure that data is published into the Data Stream only after 24 hours and only after all other verifications are performed.
Reputation
A crucial aspect of providing Adapter developers control over the level of trust in the data utilized within the TSN is to enable conditions and filters based on the reputation of the Data Providers. To do this, the TSN embeds a deterministic reputation management background process that utilizes various metrics gathered by the TSN; from data consumer engagement frequency, abundance and feedback, to data quality control measures to evaluate reputation scores for each Data Provider.
Reputation is important in scenarios where similar data is weighted based on its applicability. An Analyst, developing an Adapter, may opt to leverage a highly reputable Data Provider’s data set, with joint computations on a data set from a Data Provider with a lower reputation. If the TSN determines sufficient consumption of this Analyst’s data stream, this may increase the reputation of both Data Providers. On the contrary, should an Analyst leverage a data set from a Data Provider that fails to uphold data quality, as per quality control standards, the Data Provider’s reputation will decrease, resulting in decreased adoption from other Analysts and Adapters.
Last updated