Common Node API FIP

[LesnyRumcajs]

Summary

Create and finalize an FIP to establish a common RPC API for all Filecoin node implementations.

Rationale

The JSON-RPC interface provided by Filecoin node implementations is the primary interaction point for many systems, however a standard interface has yet to be established definitively. Lacking such standards, builders are forced to invest additional time and resources in reverse engineering implementations. Node interoperability is hindered as there are no gurantees about what APIs will be encountered in the wild. A proper specification will enable the development of applications that are implementation-agnostic.

Ultimately the Lotus RPC API is the defacto specification currently, which includes 280+ methods. Based on our exploration and discussions with the Lotus team we have established that some methods provide duplicated functionality (eg. ChainGetGenesis() is equivalent toChainGetTipSetByHeight(0)). Another subset of methods are related to implementation-specific internals (eg. ChainHotGC). And yet another subset are for the purpose of configuring the instance, which could be exposed through other means (eg. CLI, config file) depending on the design principles of a node implementation. This leads us to conclude that the canonical RPC interface should only include a subset of the methods currently supported by Lotus.

The defacto Lotus specification is lacking in several features: complete JSON schemas, descriptions for each method, and reliable consistency with the implementation1. This motivates us to propose a normative OpenRPC schema for the purpose of defining this interface in a machine readable format. This format in turn enables:

1. Compliance checks - enable implementations of the interface to verify the syntax
2. Specificity - it provides a language agnostic format for defining the ABI of the methods in the interface
3. Discoverability - allow consumers to dynamically interact with providers
4. Lack of desire to reinvent the wheel - It's not perfect, but it works...

Acceptance Criteria

• FIP document completed and submitted as a PR to the FIP repo
• List of methods identified based on usage
• OpenRPC specification created in a dedicated repository
• Community feedback received
• FIP PR merged
• Forest OpenRPC specification updated

Separate from this epic we will need to implement the methods included in the FIP.

Dependencies

• Lotus - we may require changes to the Lotus codebase to ensure compatibility. They may also need to clarify the expected behvaiour of certain methods
• FIP authors/process - we don't control the process and will need to adapt our plan as the FIP progresses

User Adoption Impact

While this will not directly lead to adoption, it will promote client interoperability by establishing a common interface for all nodes. With this established, users should be able to replace Lotus with Forest seamlessly.