Skip to content

Jefferson is a JSON-RPC API Proxy Frontend For dPay Blockchain

License

Notifications You must be signed in to change notification settings

dpays/jefferson

Repository files navigation

Jefferson

dPay API Server (JSON-RPC)

A reverse proxy that only speaks json-rpc 2.0. Upstream routing is done using json-rpc method "namespaces".

Installation

Install the latest Docker Compose

sudo curl -L "https://github.com/docker/compose/releases/download/1.22.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

Clone Jefferson and Configure

git clone https://github.com/dpays/jefferson.git
cd jefferson
  • DEV_config.json is the main config file, we also use this configuration file in our production environments since we are still in BETA.
  • You will need a server running 0.19.6 for non-appbase RPC calls and a server running 0.20.2 for appbase-based RPC calls.
  • The default configuration is what we use for dSite and dSocial. You can use your own nodes or can use the default nodes operated by dPay Nodes Team.

Launch Jefferson

screen
docker-compose up

Public Jefferson Nodes

Public RPC/WS Nodes (Public domain)

Public RPC/WS Nodes (Witness Nodes)

Namespaces

A json-rpc method namespace is a json-rpc method prefix joined to the method name with a period, so a method in the "dpds" namespace begins with dpds. and will be forwarded to a dpds endpoint:

POST / HTTP/1.1
Content-Type: application/json

{
  "method": "dpds.count_operations",
  "params": {"operation":"account_creates"},
  "jsonrpc": "2.0",
  "id": 1
}

Default Namespace

Any json-rpc method with no period in the method name is presumed to be in the "dpayd" namespace and will be forwarded to a dpayd endpoint:

POST / HTTP/1.1
Content-Type: application/json

{
  "method": "get_block",
  "params": [1],
  "jsonrpc": "2.0",
  "id": 1
}

What Jefferson does

At Startup

  1. parse the upstream config and build the routing, caching, timeout data structures
  2. open websocket and/or http connections to upstreams
  3. initialize memory cache and open connections to redis cache
  4. register route and error handlers

Request/Response Cycle

  1. validate jsonrpc request
  2. convert individual jsonrpc requests into JSONRPCRequest objects, which add its pseudo-urn and upstream configuration
  3. generate cache key (pseudo-urn for the moment)
  4. if a single jsonrpc request:
    1. check in-memory cache, if miss
    2. make a redis get call
  5. if a batch call:
    1. check in-memory cache for all keys
    2. for any misses:
    3. make a redis mget request for any keys not found in memory cache
  6. if all data loaded from cache:
    1. merge cached data with requests to form response
    2. send response
  7. if any jsonrpc call results aren't in cache:
  8. determine which upstream url and protocol (websockets or http) to use to fetch them
  9. start upsteam request timers
  10. fetch missing jsonrpc calls
  11. end upstream response timers
  12. decide if response is a valid jsonrpc response and that it is not a jsonrpc error response
  13. if response is valid, and response is not a jsonrpc error response, determine the cache ttl for that jsonrpc namespace.method
  14. for some calls, verify the the response is a consensus response or not, and modify cache ttl for irreversible block responses
  15. return single jsonrpc response or assembled jsonrpc responses for batch requests
  16. cache response in redis cache
  17. cache response in memory