Gateways

Introduction

The Gateway Actor section covers what a Gateway is. Recall that it is a permissionless protocol actor to whom the Application can optionally delegate onchain trust in order to perform offchain operations.

This section aims to cover the cryptographic aspects of Gateway interactions, trust delegation, and how they fit into the Pocket Network protocol.

Modes of Operation

There are three modes of operation to interact with the Suppliers on the network:

1

Sovereign Application

A Sovereign Application is one where the Client manages its own onchain Application and interacts with the Pocket Supplier Network directly.

The Application is responsible for:

  • Protecting its own Application private key on the Client

  • Maintaining and updating its own onchain stake to pay for Supplier services

  • Determining which Supplier to use from the available list in the session

Pocket DA LayerPocket DA Layeralt[App exceeds session limits][App within session limits]loop[Session Duration]Application (Client)Supplier(s)StartSession(App, Block, ...)SessionData([Suppliers], ...)Sign Relay RequestSigned Relay RequestValidate App Signature & App Session LimitsReject RequestHandle Request &Sign ResponseSigned Relay ResponseClaim & Proof LifecycleApplication (Client)Supplier(s)

2

Delegating Application

A Delegated Application is one where an Application delegates to one or more Gateways. Agreements (authentication, payments, etc) between the Client and Gateway are then managed offchain, but payment for the onchain Supplier services still comes from the Application's stake.

The Application is responsible for:

  • Protecting its own Application private key somewhere in hot/cold storage

  • Maintaining and updating its own onchain stake to pay for Supplier services

  • Managing, through (un)delegation, which Gateway(s) can sign requests on its behalf

The Gateway is responsible for:

  • Providing tooling and infrastructure to coordinate with the Client

  • Determining which Supplier to use from the available list in the session

Pocket DA LayerClientPocket DA LayerClientClient-Gateway Handshake (e.g. OAuth, etc...)alt[App exceeds session limits][App within session limits]loop[Session Duration]ApplicationGateway(s)Supplier(s)Delegate([Gateway])StartSession(App, Block, ...)SessionData([Suppliers], ...)RequestSign Relay RequestSigned Relay RequestValidate Ring(App/Gateway) Signature & App Session LimitsReject RequestRejected Response (or backup response)Handle Request &Sign ResponseSigned Relay ResponseResponseClaim & Proof LifecycleApplicationGateway(s)Supplier(s)

3

Gateway Application

A Gateway Application is one where the Gateway takes full onus, on behalf of Clients to manage all onchain Application interactions to access the Pocket Supplier Network. Agreements (authentication, payments, etc) between the Client and Gateway are then managed offchain, and payment for the onchain Supplier services will come from the Application's stake, which is now maintained by the Gateway.

The Gateway is responsible for:

  • Protecting its own Application private key somewhere in hot/cold storage

  • Maintaining and updating its own onchain stake to pay for Supplier services

  • Providing tooling and infrastructure to coordinate with the Client

  • Determining which Supplier to use from the available list in the session

Pocket DA LayerClientPocket DA LayerClientClient-Gateway Handshake (e.g. OAuth, etc...)alt[App exceeds session limits][App within session limits]loop[Session Duration]Gateway(s) (Application(s))Supplier(s)StartSession(App, Block, ...)SessionData([Suppliers], ...)RequestSign Relay RequestSigned Relay RequestValidate Ring(App/Gateway) Signature & App Session LimitsReject RequestRejected Response (or backup response)Handle Request &Sign ResponseSigned Relay ResponseResponseClaim & Proof LifecycleGateway(s) (Application(s))Supplier(s)

For the purposes of this discussion, note that an Application and Gateway are onchain actors/records that stake POKT to participate in the network. The term Client is used to represent an application running on a user's device, such as a smartphone or a web browser.

The goal of Gateways is to enable free-market offchain economics tied into onchain interactions.

Application -> Gateway Delegation

An Application that chooses to delegate trust to a gateway does so by submitting a one-time DelegateMsg transaction. Once this is done, the Gateway will be able to sign relay requests on behalf of the Application that will use the Application's onchain stake to pay for service to access the Pocket Supplier Network.

This can be done any number of times, so an Application can delegate to multiple Gateways simultaneously.

Pocket DA LayerPocket DA LayerGateway can now sign relay requests on behalf of ApplicationGateway can now longer sign relay requests on behalf of ApplicationApplicationGatewayPrepare & Sign Delegation TransactionDelegate(GatewayPubKey)okPrepare & Sign Undelegation TransactionUndelegate(GatewayPubKey)okApplicationGatewayApplication -> Gateway (un)Delegation

Relay Signatures

As explained in the Claim & Proof Lifecycle document, the Application that signs the relay request is the one whose stake is used for access to services provided by the Pocket Supplier Network.

The Application is the one paying for services, but a Gateway could potentially be the one proxying and signing the relay. Ring Signatures are used to enable both since delegation happens at the public key level.

Below we see what the Ring would look like in each of the three modes of operation described above:

Validate Signature

Relay

Relay

Relay

Signature

Signature

Signature

Gateway Application

Ring Signature

Gateway 3

(Application 3)

Delegating Application

Ring Signature

Application 2

Gateway 1

Gateway 2

Sovereign Application

Ring Signature

Application 1

Supplier

Client

Delegating Application Example

As an example, consider an Application that has delegated to two independent Gateways: Gateway 1 & Gateway 2. The diagrams below show a few things:

  • A client with the Application private key can sign the relay itself or delegate to a Gateway to sign the relay on its behalf.

  • A client without the Application private key can only delegate to a Gateway to sign the relay on its behalf.

  • The Supplier does not know who signed the relay, but only that it was signed by one of Application, Gateway 1, or Gateway 2.

  • The Application is always the one paying for the service.

Validate Signature

Request

Request

Request

Request

Ring Signature signed by

Application

Ring Signature signed by

Gateway 1

Ring Signature signed by

Gateway 2

Gateway 2

Gateway 2 Private Key

Gateway 1

Gateway 1 Private Key

Client 2

No Private Key

Client 1

Application Private Key

Supplier

Yes

No

Get Gateways Application

delegated to: [G1, G2]

Is Relay Request signed by one of:

[Application, G1, G2]?

Valid (should service relay)

Invalid (do not service relay)

Signature Validation for Delegating Application

[WIP] Gateway Offchain Operations

Gateways can design and manage offchain operations to coordinate with the Client including but not limited to:

  • Dashboards & user management

  • API Keys

  • Second layer of rate limiting

  • Providing altruist backups

  • QoS (SLA, SLO) guarantees

  • Prove & validate data integrity

  • Provide additional offchain services

  • Guarantee certain SLAs and SLOs

  • Manage onchain Pocket logic (account top-ups, etc...)

  • Etc...

PreviousClaim & Proof LifecycleNextAsync Service Mining

Was this helpful?