This bounty is no longer available
Web3 DAO | databrokerglobal Logo

Create complete and clean JSON-RPC schema's in the OpenRPC format

Organization

databrokerglobal

Deadline

in over 262 years

Status

ENDED

1770.25 USD

INSTRUCTIONS

The chains Databroker interacts with all provide a JSON RPC interface. Documentation of those interfaces ranges from html pages, Postman collections or semi-complete/broken OpenRPC schemas.

To ease development, we would like to create comprehensive OpenRPC schemas for the JSON RPC interfaces of Geth, Hyperledger Besu, Avalanche, and the Binance Smart Chain Geth fork (cannot find any docs for their custom parlia namespace). These schemas have most of the function in common (the eth_ calls etc), but each of them has a few extra or slight differences.

The OpenRPC standard is documented here: https://open-rpc.org

Existing schemas:

  • https://github.com/ethereum/eth1.0-apis (there is a difference between these calls and e.g. Geth's capabilities as described in the geth docs: https://geth.ethereum.org/docs/rpc/ns-eth) <-- this is the official starting point
  • https://github.com/etclabscore/ethereum-json-rpc-specification/blob/master/openrpc.json (reasonably complete but older version of OpenRPC and not maintained, but mostly works with Geth specifics)

Other documentation:

  • geth documentation on their API's: https://geth.ethereum.org/docs/rpc/server
  • geth style postman collection: https://documenter.getpostman.com/view/4117254/ethereum-json-rpc/RVu7CT5J?version=latest
  • besu docs + postman collection: https://besu.hyperledger.org/en/stable/Reference/API-Methods/
  • avalanche docs: https://docs.avax.network/build/avalanchego-apis
  • avalanche postman collection: https://docs.avax.network/build/tools/postman-avalanche-collection

Some conventions:

    {
      "name": "eth_getBalance",
      "description": "Returns the balance of the account of given address.",
      "params": [
        {
          "name": "Address",
          "required": true,
          "summary": "0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B",
          "schema": {
            "$ref": "#/components/schemas/address"
          }
        },
        {
          "name": "Block",
          "required": true,
          "summary": "latest",
          "schema": {
            "$ref": "#/components/schemas/BlockNumberOrTag"
          }
        }
      ],
      "result": {
        "name": "Block number",
        "schema": {
          "$ref": "#/components/schemas/uint"
        }
      }
    },

...


      "BlockNumberOrTag": {
        "title": "Block number or tag",
        "description": "A block number at which to request the information or 'latest', 'earliest' or 'pending'",
        "oneOf": [
          {
            "title": "Block number",
            "$ref": "#/components/schemas/uint"
          },
          {
            "title": "Block tag",
            "$ref": "#/components/schemas/BlockTag"
          }
        ]
      },
  • name: obviously the the call itself
  • description: the most official version of the explanation of this endpoint, preferably copied from the official docs
  • params:
    • consistently capitalised names (cfr official docs)
    • described with required or not
    • with an official description
    • on the highest level with a summary field that has a working example value in the context of this call

Acceptance criteria:

  • 4 OpenRPC JSON Schema's
  • Each covering all namespaces provided by the client
  • Adherance to the conventions listed above
  • Using the example values in the summaries, all calls should work without modifications on the playground: https://playground.open-rpc.org -> please document in the readme which public (infura etc) endpoints you used.