The daemon is the adapter with which an otherwise SingularityNET-unaware service implementation can be exposed to the SingularityNET network. It is designed to be deployed as a sidecar process alongside the service on a given host. The daemon takes care of authenticating callers and authorizing their invocations of the service, terminating transport encryption, issuing blockchain transactions on behalf of the service owner (e.g. to retrieve funds held in escrow after successful completion of a call), translating incoming requests from a universal gRPC interface exposed by the daemon to proxy them in the format expected by the service, and more.
Supported Service Types
The daemon has been written to support a variety of service implementations. Currently, services that either expose a JSON-RPC endpoint, a gRPC endpoint, or are implemented as executables to be executed on a per-call basis with the input parameters on STDIN can be used with the SingularityNET daemon.
The daemon itself exposes a gRPC/gRPC-Web endpoint regardless of what type of service is paired with the daemon. This enables one consistent protocol to be used to communicate with any service on the SingularityNET network. Note that certain gRPC features such as streaming require the service itself to expose a gRPC endpoint with streaming RPCs. Also note that bi-directional streaming RPCs are only compatible with gRPC clients (not gRPC-Web i.e. browser clients).
Services are encouraged to define their API surface using protobuf as an IDL. This allows SingularityNET clients to determine the request/response schema programmatically. See this for an example of how to create a service model for any of the supported service types, and this for directions on how to publish the service model to the network.
The daemon supports SSL termination using either a service developer-supplied certificate and keyfile or automatic certificates provided by Let’s Encrypt.
Prior to invoking a service through the SingularityNET platform, a consumer must have:
- Funded the Multi-Party Escrow contract (see this article); and
- Opened a payment channel with the recipient as specified by the service definition (see this article).
With each invocation the daemon checks:
- that the signature is authentic;
- that the payment channel has sufficient funds; and
- that the payment channel expiry is beyond specified threshold (to ensure that the developer can claim the accrued funds).
After these successful checks the request is proxied to the service.
The daemon’s behavior with respect to the service type, SSL, blockchain interactions, etc. is configurable via a configuration file, environment variables, and executable flags. See this for a description of the available configuration keys.
Payment channel state
The daemon stores the payment channel state in an etcddb cluster. This is detailed here.