Engineering Update #4

Engineering calls offer our community a glimpse into the hard work our engineers are doing to build Lava — the community-led standard for blockchain RPC and APIs. It’s important for us to provide transparency into our progress, and to open the floor to questions and feedback from our community.

On the latest call we discussed:

• New Feature: Concurrency Enhancements
• In Development: Offline-service accountability aka Jail
• Challenge: State Sync

Here’s a short Summary!

New Feature: Concurrency Enhancements

With this new feature, Providers are able to select the number of concurrent node connections they want to initiate, using a simple flag. These connections are between their provider client and their RPC nodes for the chains they support. Giving Providers the ability to have better control over the number of connections allows for improved latency and faster response time, which contributes to the overall efficiency of the network.

Additionally, our Provider client now includes an automatic load-balancing mechanism, designed to detect heavy loads and to increase the number of connections in its pool, as needed to handle the increased traffic. When the load decreases, the Provider will automatically lower the number of connections, conserving resources and ensuring optimal performance.

Q: How does it enhance Lava’s scalability?
A: Optimizing each Provider increases the amount of total requests Lava can serve. This feature is estimated to improve scalability by 10x or more.

Q: Are there further scalability features planned in the future?
A: Future scalability features include aggregation of transactions (grouping multiple relay payments in one transaction), and spreading payment requests over time instead of concentrating them at the beginning of each epoch — which will significantly lower gas fees, and increase the success rate of transactions on the Lava blockchain.

In Development: Offline-service accountability aka Jail

The purpose of offline-service accountability is to detect and deter unresponsive Providers, who are delivering poor uptime and a lower standard of service to the network. A Provider that appears in the Application’s pairing list, but is not responding to queries, will be reported by the Application. Once an unresponsive Provider has been reported by enough Applications (depending on their CU usage) they are sent to jail, which means that they’re kicked and unstaked from the network to fix their issues without hurting Applications.

Q: What can Providers do to avoid Jail?
A: Providers that stay online and answer queries will naturally avoid jail. In the future, providers that experience down-time will be able to “freeze” their service instead of going to jail.

Q: What metrics should Providers track to do so?
A: Providers can track their stake and relay payments to make sure that they’re online and giving service.

Challenge — State Sync

Cosmos chains have a feature called State Sync, which allows a new node to join a network by fetching a snapshot of the application state at a recent height, instead of fetching and replaying all historical blocks. This can reduce the time needed to sync with the network from days to minutes.

A number of node runners from our community tried to use State Sync, but it caused their nodes to crash. This happened because our team designed Lava’s blocks to include less data than the standard Cosmos block, which increases Lava’s scalability, but affects Validators’ ability to use State Sync. More specifically, Lava’s blocks don’t contain enough previous block headers to be used by State Sync.

Q: How are we fixing this?
A: Our team is working to update the blocks to allow nodes to use State Sync. This will slightly increase the state size in order to store more headers every block state, but will improve the experience of node runners in our community.

Summary

We thank everyone for who attended, our Discord is always open for questions and support.

See you all at the next call, February 28 at 16:00 UTC!

About Lava 🌋

Lava is a decentralized network of top-tier API providers, where developers make one subscription to access any blockchain. Providers are rewarded for their quality of service, so your users can fetch data and send transactions with maximum speed, data integrity and uptime. Pairings are randomized, meaning your users can make make queries or transact in privacy.

We help developers build web3-native apps on any chain, while giving users the best possible experience.