App Publishing

(Document status: mostly complete) Much of the architecture of Obscyra revolves around two key pieces, the "Publisher Client" and the "Provider Client". A publisher is a buyer in the Obscyra network seeking to provision their pod/container on the network. A provider is a seller seeking to offer their hardware for rent. The planned version of Obscyra takes care of matching the two and provisioning the pod on a specific target provider. While it offers a way to manually pick a provider, it defaults to automatically picking one for the user. However, it does not take care of operational issues that might subsequently arise; specifically, it does not take care of rescheduling pods when a provider becomes unavailable nor does it make any guarantees about uptime or availability of data—those will be handled in later versions. Such concerns are kept track of in the backlog. Bird's-eye view On-chain TEE Publisher machine List Providers Create Monitor App Container Encrypted App Container Execution request App Container Configuration Execute Metrics Execute Requests Requests Registry Contract Payment Contract Provider Client K8s Control Plane K8s Registry HTTP Facade Application Pod K8s Registry Publisher Client External Clients libp2p/IPFS As a sequence of steps: The user starts the Publisher Client to deploy a container The Publisher Client collects the Pod Manifest The Publisher Client gets the list of providers from the Registry Contract The Publisher Client selects a provider, using the configured strategy (automatic or by asking the user to manually make a choice) The Publisher Client creates a Payment Contract and transfers the initial payment amount (possibly in parallel with steps 5-6) The Publisher Client bundles up the Pod Manifest, any related resources, and the Payment Contract's address and sends them to the Provider Client over the Deployment sub-protocol, encrypted The Provider Client creates the relevant configurations for the Pod using the Kubernetes API, including an HTTP Scaler, an Application Pod, and Monitoring The Provider Client confirms receiving the manifest and resources When HTTP requests come in, the HTTP Scaler contacts the Kubernetes API in order to scale the Application Pod up The Application Pod is started using the configuration from earlier The Application Pod handles the incoming requests After a period of no requests the Scaler uses the Kubernetes API to scale the Application Pod down The Monitoring component keeps track of how many e.g. CPU-seconds the Application Pod has run for, and forwards these metrics to the Provider Client The Provider Client submits the metrics to the Payment Contract and is then able to claim the payment due Whenever the Payment Contract runs out of funds, the Provider Client removes the related configurations from Kubernetes