Skip to main content

Crate taceo_oprf_service

Crate taceo_oprf_service 

Source
Expand description

This crate provides the core functionality of a node for TACEO:OPRF.

When implementing a concrete instantiation of TACEO:OPRF, projects use this composable library to build their flavor of the distributed OPRF protocol. The main entry point for implementations is the OprfServiceBuilder. It loads node information (party ID, address) from the secret manager and initializes a cache-backed key material store. With the OprfServiceBuilder::module method, implementations can add multiple OPRF modules, each with its own authentication mechanism. Finally, the OprfServiceBuilder::build method returns an axum::Router that should be incorporated into a larger axum server that provides project-based functionality for authentication.

If internal services of the OPRF service encounter an error, the provided CancellationToken will be cancelled, allowing the hosting application to handle the shutdown process gracefully. Additionally, the CancellationToken can be cancelled externally to signal the OPRF service to stop its operations.

For OPRF modules, implementations must provide their project-specific authentication. For that, this library exposes the oprf_types::api::OprfRequestAuthenticator trait. A call to [OprfServiceBuilder::module] expects an OprfRequestAuthService, which is a dyn object of OprfRequestAuthenticator.

The general workflow is as follows:

  1. End-users initiate a session at $n$ nodes.
    • the specified OPRF module of the OPRF service receives the request.
    • the module router calls oprf_types::api::OprfRequestAuthenticator::authenticate of the provided authentication implementation. This can be anything from no verification to providing credentials.
    • the node creates a session identified by a UUID and sends a commitment back to the user.
  2. As soon as end-users have opened $t$ sessions, they compute challenges for the answering nodes.
    • the router answers the challenge and deletes all information containing the sessions.

For details on the OPRF protocol, see the design document.

Clients will connect via web-sockets to the OPRF node. Axum supports both HTTP/1.1 and HTTP/2.0 web-socket connections, therefore we accept connections with any.

If you want to enable HTTP/2.0, you either have to do it by hand or by calling axum::serve, which enabled HTTP/2.0 by default. Have a look at Axum’s HTTP2.0 example.

Modules§

config
Configuration types for a TACEO:OPRF node.
metrics
Metrics definitions for the OPRF service.
secret_manager
Secret manager interface for OPRF nodes.
web3
HTTP RPC provider utilities for interacting with Ethereum nodes.

Structs§

OprfServiceBuilder
OprfServiceBuilder to initialize a OprfService with multiple OprfRequestAuthServices.
StartedServices
A struct that keeps track of the health of all async services started by the service.
VersionReq
SemVer version requirement describing the intersection of some version comparators, such as >=1.2.3, <1.8.

Enums§

Environment
The environment the service is running in.