The Pocket Network’s Servicing layer is comprised of 2 main actors: Applications and Servicers. An Application submits a Relay Request, or an API requests to be routed to any Relay Chain. A Servicer ‘services’ the Application, by routing the Relay Request to the Relay Chain and forwarding the response to the Application. This interaction between an Application and a Servicer is the fundamental utility of Pocket Network.
- To register for decentralized infrastructure, an Application must stake the native cryptocurrency POKT in the network.
- The amount of the sanctioned throughput (per request) is determined by the amount the Application stakes in the network.
- To register to provide decentralized infrastructure, a Servicer must stake the native cryptocurrency POKT in the network.
- After the subsequent staking, an Application is paired with Servicer(s), during which time the servicing interaction takes place.
- For providing the decentralized infrastructure, Servicer receives an amount of the native cryptocurrency POKT proportional to the amount of throughput (in requests) served.
- Once an Application or Servicer unstakes, they are unregistered from Pocket Network and the stake is returned to their account.
The Servicer(s) that are paired to service an Application in a Session are equally distributed among all of the Servicers in the network.
Meaning that every Servicer theoretically serves the same amount as their peers and every Application theoretically will be evenly serviced by each Servicer over time.
The generation of a Session is key to the equal distribution property.
Equally distributed sessions are generated with pseudorandom seed data:
- BlockHash: Hash of the last Session Block
- AppPubKey: The Application’s public key
- RelayChain: The identifier of the Relay Chain
The result of using this seed data is unique sessions for every Relay Chain of Application at any given Session period.
The Servicers over time that will serve each Application at any given time are extrapolated using this data, meaning any actor with the following blockchain data is able to generate the proper serving Servicers.
A single Dispatch API call to any full node on Pocket Network will provide an Application client with the ServiceURI of their Session period Servicers.
Tumbling is the act of regenerating a Session with new seed data.
Sessions are tumbled periodically every predetermined (by governance) quantity of blocks.
The tumbling mechanism allows for much greater Application security, as the same Validator(s) will only service the Application for a certain amount of time.
The max Application throughput (in number of requests) is proportional to the amount staked.
The maximum a Servicer in a Session can service for a certain Application is determined using the following formula:
max_app_relays = base_throughput / (# of Servicers in Session * # of relay_chains staked for)
The request payload is the body of the RPC request
- Data: The actual request body to be forwarded to the Relay Chain
- Method: The HTTP CRUD method
- Path: Path variable for REST support
- Headers: HTTP Headers
The Relay Metadata is Protocol level descriptive information that is needed for servicing.
- BlockHeight: The Pocket Network block height when the request was made
The metadata mechanism allows for a configurable client syncronization module, enabling the Servicer to reject out of sync clients.
Since the Metadata is grouped into the request hash, this mechanism is a protection against Client level synchronization attacks where the Client is able to challenge single Servicers by requesting chain data at a different time than the majority.
Proof of Relay (Evidence)
A Proof of Relay is the portion of a Relay Request that is used for verification of the atomic work completed.
For each Application of each Session, a Servicer collects Relay Evidence in the form of a Proof of Relay. The amount of Relay Evidence is completely proportional to the amount of Relays serviced, meaning for each Relay successfully completed, the Servicer stores one piece of Relay Evidence.
Structure of the Proof of Relay
- RequestHash: The SHA3-256 hash of the request payload
- Connects the specific payload with the proof
- Needed for the Application Challenge Mechanism
- Entropy: A unique nonce (random number) that ensures uniqueness
- Unique Relays are a requirement of Pocket Network for Claim/Proof Submission
- Collisions are rejected by the Servicers
- SessionBlockHeight: The block height of the session when the Relay was serviced
- Needed to verify the participants of Session
- ServicerPubKey: The ED25519 Public Key of the servicer
- Needed to identify the servicer
- RelayChain: The identifier of the ‘relayed to’ blockchain
- AAT: The Application Authentication Token for the client serviced
- Includes both App Public Key and Client Public Key
- Needed for protocol level verification (app node pairings, client permissions, etc.)
- ClientSignature: The Elliptic Curve Digital Signature of the client
- Preserves the integrity of the Relay data
- Needed at Proof/Claim verification level
The response payload is the body of the RPC response:
- Response: String representation of the HTTP response
The servicer signature completes the signature exchange needed to verify all parties in the servicing protocol.
- Signature: preserves the integrity by signing the hash of the Proof of Relay and the response payload.
In order to participate in the network economic incentive mechanism, the Servicer must first Claim and then Prove the completed work. For each Application of each Session, after servicing is complete and Relay Evidence is collected, the Servicer must send two subsequent transactions:
- Claim Transaction
- Merkle Root of Relay Evidence
- Number of Relays serviced
- Evidence Type (Relay or Challenge)
- Proof Transaction
- Selected Relay
- Corresponding Merkle Proof for selected Relay
- Evidence Type (Relay or Challenge)
Upon successful completion of BOTH transactions, the Servicer is minted reward directly to their address.
Pocket Network requires a specific Merkle tree implementation that ensures no two leafs of the Merkle tree are identical (for Relay replay protection). Plasma-Core’s Merkle sum tree satisfies this property.
By using the hash of the Relay data (integrity is validated by verifying the Application Client Signature) in conjunction with the replay protection from the Plasma tree, Pocket Network can probabilistically guarantee work completed without the Servicer actually transmitting the entirety of its Relay Evidence to the rest of the network.
A fancier name for this is a Zero Knowledge Range Proof.
Zero Knowledge Range Proof
In order to complete a successful ZKRP in Pocket Network, the following steps must be executed by each Servicer for each Session:
- Generate the Merkle Tree using the SHA3-256 hash of the Relay Evidence as the leafs
- Submit a Claim Transaction to preserve the integrity of the local Merkle tree and corresponding Relay Evidence, as well as inform the protocol of the range or number of leafs possible to select from
- After a protocol wide waiting period (determined by governance), the Servicer generates the selected leaf (using the latest block hash as pseudorandom entropy to prevent knowledge of the selection during claim generation) and subsequently creates a Merkle Proof (branch) for the pseudorandomly selected leaf.
- The Servicer submits a Proof Transaction containing the selected leaf (Relay Evidence) and the corresponding Merkle Proof (branch)
- The protocol verifies the Merkle proof against the previously submitted Merkle root (in the Claim Transaction), verifies the session (proper app/node pair, not overserviced etc.), and then verifies the client signature against the Proof of Relay (integrity check)
- All of the Validators confirm the validity of the Proof Transaction, completing the Zero Knowledge Range Proof
- Tokens are minted to the address of the Servicer proportional to the amount of Relays served.
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.
The probability due to randomized selection without replacement is:$$
P (A∩B) = P (A) P (B|A)
Thus the probability of selecting any combination of Validators at any given Session in Pocket Network is:$$
1 / (allvals (allvals-1) (allvals - 2) ... * (allvals - valspersession))
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.
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.
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