Validator

Overview

The validator is a pivotal component tasked with two main responsibilities: initiating web requests and verifying web transactions. The validator’s design is flexible, allowing for various implementations that align with the network's evolving architecture.

Initially, the validator operates as a singular, centralized entity managing all transactions. Future updates will introduce a committee of validators, employing a consensus mechanism to oversee data transfer sessions, enhancing decentralization and security.

Transaction Verification and Encryption

For web transactions, the validator utilizes a unique set of keys to establish TLS connections, selecting appropriate cipher suites for communication with target web servers. All traffic used to validate the reputation of a node on the network will be encrypted using one of the below algorithms as supported by the target web server:

List of Supported Algorithms

  1. AEAD (primary)

  2. RSA

  3. RC4

  4. Hash-based MD5

  5. Diffie–Hellman

  6. DSA (Digital Signature Algorithm)

  7. Triple DES (Data Encryption Standard)

  8. SHA hash function (SHA-1 and SHA-2)

  9. ECDH (Elliptic Curve Diffie–Hellman)

  10. ECDSA (Elliptic Curve Digital Signature Algorithm)

  11. AES (Advanced Encryption Standard) - with mentions of 128-bits and 256-bits variants

  12. SRP (Secure Remote Password)

  13. IDEA (International Data Encryption Algorithm)

  14. Camellia

  15. ChaCha20

Session management involves creating and securely storing pre-master, master, and session keys, critical for assessing traffic quality from network nodes. Following data validation, the validator passes the data along to the ZK processor to generate a proof for each node's session data, then batches these proofs on the blockchain for settlement. The on-chain proofs ensure that all data represented on Grass is free from tampering and is accurate in illustrating its lineage.

Security

In the current structure, the validator is a point in the system that must operate according to its own security assumptions as it does not derive its security from any underlying L1. If the validator experiences downtime, network users can submit session data directly on the L1 for settlement. In future development, a series of economically collateralized validators will provide security guarantees that prevent any single actor from influencing transactions on the network.

PreviousOverviewNextRouter

Last updated