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