The SingularityNET daemon is the adapter that a service can use to interface with the SingularityNET platform. In software architecture lingo, the daemon is a sidecar proxy, —a process deployed next to a core application (the AI service, in this case) to abstract away some architectural concerns such as logging and configuration as well as entire platform aspects, such as the interaction with smart contracts or even the decision to use the Ethereum Blockchain. The two key abstraction responsibilities of the daemon are payments and request translation. In order to authorize payments, the daemon interacts with the Multi-Party Escrow contract. Before invoking a service through SingularityNET, a consumer must have
After these successful checks, the request is proxied to the service. The daemon also keeps track of payment states of different clients.
Once the daemon has validated requests, it translates them into the format expected by the AI service. The daemon exposes a gRPC, so all requests are based on gRPC and protocol buffers, but it can translate requests to a few different formats, as expected by the service: in addition to gRPC/Protobuf, JSON-RPC and process fork–based services (executables to be executed on a per-call basis with the input parameters on standard input) are supported. This translation enables one consistent protocol to be used to communicate with any service on SingularityNET. The daemon and CLI also use gRPC and Protobuf for communication. One can deploy multiple instances of an AI service. Each instance will have its own sidecar daemon, and all daemons will be registered as endpoints in the Registry. When multiple instances exist, they can be put into one or more instance groups (a typical reason for doing so would be to group instances in the same data center or cloud region). Daemons in the same group coordinate to share payment status information through etcd. The daemon provides some additional deployment- and administration-oriented features:
The latest version is , and can be downloaded from the release page.
The daemon has been written to support a variety of service implementations. Currently, the daemon supports services that either:
Note however that the daemon exposes a gRPC/gRPC-Web endpoint regardless of what type of service is paired with the daemon.
This means we have one consistent protocol to be used to communicate with any service on the SingularityNET network, while still allowing service authors to have flexibility in their implementations. Certain gRPC features such as streaming require the service itself to expose a gRPC endpoint with streaming RPCs (streaming is also a work in progress, see here). Also note that bi-directional streaming RPCs are only compatible with some gRPC clients (not gRPC-Web i.e. browser clients).
As noted when discussing Services, the service API is defined using protobuf.
Prior to invoking a service through the SingularityNET platform, a consumer must have:
With each invocation the daemon checks:
After these checks are successful the request is proxied to the service.
The daemon’s behavior with respect to the service type, SSL, Blockchain interactions, etc. can be controlled via a configuration file, environment variables, and executable flags. See the daemon’s README for a description of the available configuration keys and how they map to environment variables and runtime flags.
The daemon stores the payment channel state in an etcddb cluster. This cluster can either be an embedded etcd instance that runs in connection with each snetd replica (default) or an externally configured cluster. This is detailed here. ETCD cluster.
Last modified on : 11-May-20