The OpenRPC Specification defines a standard, programming language-agnostic interface description for JSON-RPC 2.0 APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenRPC, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, the OpenRPC Specification removes guesswork in calling a service.

Although this was created by ECLC, the ramifications and it’s impact should be felt across all blockchain dApp development.

This Twitter post sums it up best:

Parlez-Vous Blockchain?

Unstoppable code. Un-censorable messages. Incompatible Protocols

Sure, we all love the idea of building things without having someone in charge of everything. The benefit of these systems is a new version of freedom we are all still wrapping our heads around, but the drawbacks have been felt in building. The tools and protocols developers are using are not standardized, and this leads to inevitable complications when trying to organize globe-spanning ecosystems that are supposed to eventually work without any human intervention.

Photo by Paul Green on Unsplash

JSON-RPC is the defacto data exchange protocol that blockchain clients and servers use to communicate. Although most modern frameworks depend on RESTful API’s, “RPC is more suitable due to its it being simple, fast, and communication channel agnostic.” says ECLC developer Shane Jonas

In the case of Ethereum, most developers use Web3, a javascript wrapper for JSON-RPC. The benefit this provides is a very fast and user friendly interface for developers new to blockchain to get started without too much background in RPC. This can be great for addressing a wide audience, but it leads to slower development time and can even starts to create a plethora of mismatched updates and libraries.

Google’s API Design Guide defines Networked APIs as:

Application Programming Interfaces that operate across a network of computers. They communicate using network protocols including HTTP, and are frequently produced by different organizations than the ones that consume them.

As we continue building, different organizations will get out of sync. This is an issue for interacting with systems outside of your own, and inevitably this will become an obstacle towards our collective goal to build decentralized systems that can cooperate with one another. By creating canonical definitions for RPC (which is used by virtually every blockchain), ECLC has created something that the entire ecosystem needed.

Photo by Ilya Pavlov on Unsplash

OpenAPI set the standard for API description adoption

This isn’t a new, novel idea. OpenAPI, the specification most used for REST APIs, has been widely applauded and now supported by the Linux Foundation (including Google), a testament to the importance of having these kind of globally agreed upon protocols.

The OpenAPI Specification wasn’t the first API description format, but so far it has been the most widely used. Before we had API description formats, people hand-wrote the code for their APIs. Then they hand-wrote descriptions of those APIs and handed those to people who wanted to use the APIs, who then hand-wrote code to call the APIs. All of that hand-writing led to a lot of variation and error. As a formal description format, OpenAPI is giving us a great way to communicate about APIs and to have fewer errors and more successes in our API-based systems — Tim Burks

The OpenRPC Specification is built on the same philosophies and methods as OpenAPI

The Benefits

Automatic Updates

High Quality

Tooling

Known Services

There’s more than just a specification….

What’s Next

The Roadmap laid out by the ECLC team shows that this was just the first step in building a better JSON-RPC framework.