Skip to main content

Provider Features

This page details the various features available to providers in the Lava network, along with instructions on how to operate them:

Freeze and Unfreeze

The freeze command allows a provider to freeze its service, effective next epoch. This enables providers to pause their services without the impact of a bad QoS rating. While frozen, the provider won't be paired with consumers. To unfreeze, the provider must use the unfreeze transaction, effective next epoch. This feature can be useful in cases like a provider needing to halt its services during maintenance.

Usage

Freeze:

# required flags: --from alice. optional flags: --reason
lavap tx pairing freeze [chain-ids] --from <provider_address>
lavap tx pairing freeze [chain-ids] --from <provider_address> --reason <freeze_reason>
lavap tx pairing freeze ETH1,COS3 --from alice --reason "maintenance"

Unfreeze:

# required flags: --from alice
lavap tx pairing unfreeze [chain-ids] --from <provider_address>
lavap tx pairing unfreeze ETH1,COS3 --from alice

The freeze command requires the --from flag to specify the provider address. Optionally, you can provide a --reason flag to give a reason for the freeze.

The unfreeze command also requires the --from flag to specify the provider address.

Advanced Auth configuration

In this example, COS3 tendermint URLs are using client authentication, assuming the node URL is capable of processing this authentication.

Auth using HTTP headers

The following RPCProvider Config Example demonstrated authentication using the "auth-headers" option:

endpoints:
- api-interface: tendermintrpc
chain-id: COS3
network-address:
address: 127.0.0.1:2221
node-urls:
- url: ws://127.0.0.1:26657/websocket
auth-config:
auth-headers:
WANTED_HEADER_NAME_1: xyz
- url: http://127.0.0.1:26657
auth-config:
auth-headers:strings.Join(goodChains, "; ")
Authorization: 'Bearer xxyyzz'

Auth using Query Params

The following RPCProvider Config Example demonstrated authentication using the "auth-query" option:

endpoints:
- api-interface: tendermintrpc
chain-id: COS3
network-address:
address: 127.0.0.1:2221
node-urls:
- url: ws://127.0.0.1:26657/websocket
auth-config:
auth-query: auth=xxyyzz
- url: http://127.0.0.1:26657
auth-config:
auth-query: auth=xyz

gRPC TLS configuration

If you want to add TLS authentication to your gRPC endpoint you have 3 options:

1. Dynamic certificate

endpoints:
- api-interface: grpc
chain-id: LAV1
network-address:
address: 127.0.0.1:2221
node-urls:
- url: 127.0.0.1:9090
auth-config:
use-tls: true

2. Provide a certificate and a key:

endpoints:
- api-interface: grpc
chain-id: LAV1
network-address:
address: 127.0.0.1:2221
node-urls:
- url: 127.0.0.1:9090
auth-config:
use-tls: true
key-pem: /home/user/key.pem
cert-pem: /home/user/cert.pem

3. Provide a root certificate:

endpoints:
- api-interface: grpc
chain-id: LAV1
network-address:
address: 127.0.0.1:2221
node-urls:
- url: 127.0.0.1:9090
auth-config:
use-tls: true
cacert-pem: /home/user/cert.pem

ip-forwarding configuration

If you want to IP load balance / throttle this is also supported by adding "ip-forwarding: true" The IP will be added to the following header: X-Forwarded-For

endpoints:
- api-interface: jsonrpc
chain-id: ETH1
network-address:
address: 127.0.0.1:2221
node-urls:
- url: ws://your_node_url/
ip-forwarding: true

node-timeout configuration

If your node is too far from the rpcprovider or responds too slowly, and you still want your provider process to start (note this will provide inferior QoS for consumers) without troubleshooting, you can overwrite the timeouts with custom values using a flag in the node-urls configuration

endpoints:
- api-interface: jsonrpc
chain-id: ETH1
network-address:
address: 127.0.0.1:2221
node-urls:
- url: ws://your_node_url/
timeout: 1s