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
With each invocation the daemon checks for the following:
After performing the above checks, the request is proxied to the service.
Besides, the daemon monitors the payment states of different clients.
After the requests are validated by the daemon, they are translated into the format recognizable by 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 the usage of one consistent protocol 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 can have its own sidecar daemon, and all daemons are registered as endpoints in the Registry.
When multiple instances are available, they can be grouped in to multiple instance groups (a typical reason for doing so would be to group instances in the same data center or cloud region).
Daemons within the 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:
stdin
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. 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.
The daemon supports SSL termination using a developer-supplied certificate and keyfile. See our SSL guide for step-by-step instructions on how to set this up with Let’s Encrypt.
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 : 02-Feb-23