Dynamic Pairing by Epoch

Lava works by establishing and distributing a Pairing List to all RPC Consumers. Consumers request a list of eligible Providers for their requested chain and geography by making an RPC call or sending a transaction. They submit an API call Pairing() to the Lava Blockchain to receive the most recent Pairing List. This list contains Providers that will service their API requests for that period or epoch, based upon at least four factors*:* 1) provider stake, 2) epoch blockhash, 3) geolocation, and 4) consumer address. In the future, more complicated considerations, such as consistent quality of service excellence per cluster of providers in a geolocation will be implemented.
‍

Epochs are multiple blocks in length. A new pairing list is calculable each epoch. Epochs are used instead of blocks to lessen overhead, optimize efficiency, and reduce the Lava blockchain’s storage size. For scalability and maximal efficiency, the number of blocks within a given epoch can be changed via on-chain governance. Therefore the Lava community can mediate how often new Pairing Lists will be issued.
‍

Providers become eligible for inclusion on a Pairing List by staking LAVA tokens. Once a provider completes setup, they can begin servicing requests. Their verified requests will be included in the Pairing List from the next Epoch. Although tokens are used for payment, Compute units (CUs) are assigned to each service API to measure a provider’s workload, which determines their rewards.
‍

On Lava, increasing the number of Consumer pairings a Provider receives does not require new nodes or addresses. Consumers can access RPC through our Gateway, SDK, or Server Kit, streamlining their workflow and abstracting away the Pairing List.
‍

Modular RPC and Rich API Specifications

Lava works by empowering its users to add additional configuration sets through the use of modular specifications. A specification (affectionately referred to as a ‘spec’) establishes the APIs provided by Providers for Consumers through JSON. Lava already has numerous specs, which are modified and added in modular fashion through governance proposals.
‍

When adding a new blockchain, the JSON (spec file) must specify that chain’s available RPC APIs, its minimum stake, and a few other base configurations. Using this very same method, a consumer can even add specs for Rich APIs to Lava by simply specifying the accepted calls to the node(s) in their spec! After that, the spec is submitted to the chain with a simple command: lavad tx gov submit-proposal spec-add [path-to-JSON]. Those staked on the network are given a chance to vote on the proposal. Once the vote is passed - a spec becomes the standard by which users of the network agree to use the APIs of a chain.

With the use of spec modules, Lava aims to offer total flexibility to developers needing access to web3. You can read more about specs here.
‍

Incentives for high Quality of Service — Latency, Freshness, Availability

Lava keeps Providers accountable using rewards and disincentives: Providers are subject to scoring, burning, slashing, and jailing. However, the true goal of Quality of Service (QoS) in blockchain technology is to incentivize providers to deliver good service by offering rewards in the form of more clients and higher payments.
‍

On Lava, QoS is measured using three metrics: availability, latency, and freshness, with a cumulative score ranging between 0 and 1. We define each of these terms for clarity; availability is measured by the number of messages a provider is able to answer, latency tracks the time it takes for provider to respond to a client, and freshness measures how up-to-date the provider is with the blockchain.
‍

All three of these give a comprehensive picture of how a given RPC provider is performing in relation to the demands of the network. As such, Consumers assign scores per relay and those scores are used to deterministically rank providers per epoch— assuring that the most performant and reliable providers are consistently servicing relays.
‍

Data Reliability Checks

Data reliability is also an explicit goal of the protocol. Primarily, its ensured through two means: provider-funded data reliability and client-funded data reliability. Although data and requests are handled off-chain, Lava uses cryptographic signatures, which means providers can be held liable for their inaccurate responses (should they exist)!
‍

Provider-funded data reliability is achieved by sending two messages endorsed by a Verifiable Random Function (VRF). The client sends a duplicate message to a different provider, compares the finalized results and reports any discrepancies on-chain for fraud handling/slashing.
‍

Client funded data reliability involves the client choosing how many messages to verify from finalized blocks and sending them to two or more providers. If a discrepancy is found, it’s reported on chain as fraudulent for conflict resolution. These client-funded data reliability checks can also be done in secret.
‍

Lava resolves conflicts in data through an Honest Majority protocol. A stakeweighted vote of a majority of validators determines the data in the case of a discrepancy, as imaged below. It bears relaying here that — in the future — light clients can be used to communicate with other RPC nodes and verify state with lower trust assumptions around data integrity!

Collaborate ahead of Mainnet in Q1 2024

Lava is a single network for fast, reliable and cost-efficient access to any blockchain. Its first service is to provide a performant RPC solution for developers and users, and it will later expand to any type of data infrastructure e.g. indexing and oracles.
‍

If you’re looking to grow with us as we move towards Mainnet, we are already working with:

• Ecosystems - on supporting their public RPC needs
• Dapps - on serving them fast and reliable multi-chain responses

You can get in touch with the Lava team here: lavanet.xyz/partnerships

Alternatively, join our Discord to speak directly with our community and ask questions: discord.gg/bKkEtU6AMQ