Security
By enforcing POKT to be staked from both the Applications and the Validators, the protocol is able to economically penalize either actor participating in servicing
Session Security
The probability due to randomized selection without replacement is:
Thus the probability of selecting any combination of Validators at any given Session in Pocket Network is:
Meaning, the more Validators in the network, the higher level of randomization and by extension security.
The deterministic yet unpredictable properties of the block hash seed data in Session Generation, ensure that no malicious actors will be able to determine Application and Validator pairings. This is a common security mechanism used in Pocket Network.
Application Security
The Application Authentication Token is the key mechanism for Applications to balance the security of their stake and UX of clients during servicing. Through the AAT, the Application is able to sanction clients to access their throughput via Digital Signature. Future implementations of the AAT include enforcing a lifecycle through expiration and other client access configurations such as Relay Chain specification.
Application Distribution Configuration is the recommended practice of distributing an Application 's throughput over multiple Application stakes (or identities) to ensure the highest level of data accuracy, uptime, and data privacy.
Client Side Validation is the recommended practice of redundantly sending the same request to multiple Validators. CSV allows the client to come to a majority consensus on the Relay Responses. This configuration ensures the highest level of data accuracy and enables the Application to use the Application Challenge Mechanism of the protocol, where corresponding minority Validator(s) providing invalid data are economically penalized.
Validator Security
A Validator will not receive mint for any service they provided while breaking the servicing protocol rules.
These rules are enforced by the Validators by verifying all the work reported to the network.
Examples of breaking the Servicing Rules include:
Overservicing an Application
Incorrect App/Validator Pairing
Incorrect Relay Chain
Non-Unique Proof of Relays
Invalid Merkle Root / Proof pairings
Invalid Application Authentication Token
A minority Validator in Client-Side Validation
Invalid Servicer in Proof
Below minimum Relay count
Last updated
Was this helpful?