Recap of Lava’s Key Components

We’ve added a new feature to Lava which ensures that apps and consumers on Lava can still get service from providers on the network, even if the chain halts.

‍

Lava consists of four core elements:

• A decentralized network of Providers who run nodes and serve data to Consumers e.g. apps
• Specs, permissionlessly added modules which define API methods in a JSON file and are selected to be served by Providers
• The Lava protocol, which pairs Consumers to the best Providers available, based on historical and current QoS parameters like latency, uptime and accuracy
• The Lava blockchain, to which Consumers make requests for pairings lists of Providers and Providers submit transaction claims for the service they have given Consumers

Lava also offers multiple ways for developers to communicate with the network - the managed Gateway UI, the backend Server Kit & the p2p SDK for app developers.

All relays between Consumers and Providers are peer-to-peer and off-chain.

Reducing RPC & Infra Downtime in Web3

Downtime at the RPC node level is every developer’s nightmare - and an extremely common one. Whether it’s a popular NFT mint, inscriptions DDOSing chains or points driving huge traffic to an application, RPC provider often lack the redundancy and fallback mechanisms to scale.

We’ve previously explored the topic of infrastructure downtime in another blog.

Constant Availability - true redundancy and uptime

All node providers - whether centralized or decentralized - face downtime due to single points of failure in their architecture.
‍
Because Consumers on Lava retrieve lists of Providers per epoch from the Lava Blockchain, the blockchain previously represented a vulnerability that could impact users. If it halted in any way, Consumers would not be able to continue communicating with Providers beyond the existing epoch.
‍
Constant Availability removes this single point of failure, enabling Consumers to continue getting responses from Providers indefinitely, while the chain is halted.
This means that as long as there is a Provider supporting the spec you would like to access e.g. Ethereum JSON-RPC, Consumers will have constant RPC availability through Lava. This availability is magnified the more Providers join the network, increasing redundancy.
‍
Consumers benefit from Constant Availability out of the box when using Lava, with no additional configuration required.

Conclusion

We strongly believe there’s a better way to build data infrastructure in web3 that offers faster, more reliable and scalable service to developers and users.
Constant Availability is a key step towards Lava offering the best service across the multi-chain ecosystem. If you’ve read this far, we appreciate your support and would love to hear any further feedback in our Discord.

You can also check out the docs or get RPC from the Gateway to start building with Lava - constant availability comes out of the box ;)