Why do specs exist? Web3 is fragmented ➕

Web3 now faces fragmentation. The number of protocols, verification methods, consensus mechanisms, chain architectures, and APIs grows year-after-year. Some blockchain data is easily accessible via major RPC providers like Infura and Alchemy. Other chains have RPC nodes available but restrict API options to those least costly to implement and serve. And then there are those chains which require lock-in - making API collections available only in bulk.

The modern developer speaks API. Web3 APIs are accessible over various formats: JSON-RPC, TendermintRPC, gRPC, even Web-gRPC and Websockets. Today’s web3 developer is not restricted to naked RPC; calls are made to rich APIs, which have sophisticated functions such as indexing and NFT manipulation. However, the hunt for fast, reliable, and inexpensive API providers which can access blockchain data is creating a bottleneck.

Now, Lava introduces a new standard for modular data access: Lava Specifications (specs).
‍

Specs: The Web3 Primitive 📏

Lava specifications (specs) are a web3 primitive; they make web3 API data access both modular and extensible; any new chain which wants p2p RPC can easily implement a spec on Lava. The process involves detailing the way data is accessed, documenting it in a JSON file, and submitting via governance proposal for an on-chain vote.

Once accepted, specifications make it so any blockchain and any API in web3 can be supported by the growing pool of eager API providers regardless of architecture. Developers then make seemless p2p calls to our incentivized public endpoints, Lava Gateway, Lava SDK, or with the rpcconsumer  (”Server Kit”) process. There is no limitation on what Lava can support → Rich APIs, Smart Contract Lookup/Execution, Web3 DNS Resolution, and Indexing functions all have proven use cases.

Lava already supports 25+ specs across Ethereum-based, Cosmos-based, and alternative chain architectures. Want to try a spec in action? Check out these endpoints from Axelar or look at our AXELAR specification to learn a spec’s structure.

Spec (JSON)
│
├── Proposal (`proposal`)
│   └── Specifications (`specs`)
│       ├── API Collections (`api_collections`)
│       ├── Service APIs (`apis`)
│       ├── Verifications (`verifications`)
│       └── Extensions (`extensions`)
│
└── Deposit (`deposit`)

How Specs Work ⚙️

Specifications work by defining the expected behavior for API providers and those running RPC nodes. Community members can change this expected behavior at any time by changing parameters in a spec and submitting for an on-change vote. If the community agrees to support it, providers can serve the API. But did you know these specifications themselves are both modular and extensible?

- Specs are modular; each spec operates as a module and can be modified without affecting either the protocol or unrelated specs.
- Specs are extensible; new functionality can be added-on or exchanged without affecting providers of the current API.

Let’s review additional really important features which allow contributors to modify and extend the functionality of specs with ease:
‍

‍Imports

APIs/Chains of the same or similar architecture can import methods from an existing spec using its index and implementing any new logic.
‍

If you’re building a chain which has a common base, be it IBC, CosmosSDK, EVM, or FVM, building a spec is simple. You do not have to start from scratch. You can simply import the methods of that chain directly into with the “imports” function. It makes building a new spec a breeze!
‍

Add-Ons

Add-Ons ("add-on") introduce optional new methods and APIs which are beyond the basic requirements for a chain/API.
‍

Specs detail the bare minimum expectations of what an API provider would need to fulfill in order to serve the API. However, there are some features, such as debug functionality that some providers may choose to implement while others stay away from. These packages of elective functions are called “add ons”!
‍

‍‍Extensions

Extensions ("extensions") allow for the adjustment or enhancement of existing methods and APIs within a spec for special use cases.
‍

The bare minimum expectations may change in specific cases. If so, functionality can easily be redefined with “extensions” - in this case altering the way specific calls are handled so as to extend the way they work. This is particularly useful for things like archive nodes, where APIs which may be too expensive to support for the common provider can be supported by a self-elected group. These packages of elective functions are called “extensions”!

Together, this brings the possibility of building highly adaptable and interconnected web3 ecosystems closer.

For a deep dive into specs, take a look at our new documentation!
‍

Additional resources

For more information on how Lava works check out these articles:

• Quality of Service(Part 1): How Lava Network keeps decentralized RPC fast, reliable and accurate
• Lava Phase 2 - mainnet roadmap

‍