The Akash DeCloud is comprised of two main components:
- The Network: an on-chain decentralized marketplace for leasing computing resources.
- The Platform: an off-chain deployment platform used for hosting and managing workloads.
The Network is built with cosmos-sdk - it is a tendermint-based blockchain application.
The Platform is a set of cloud management services that leverage Kubernetes to run workloads.
The software to run the Network, the Platform, and the command-line client used to interact with them are all currently distributed in the akash application.
Deploying applications onto Akash involves two types of users:
- The Tenant: the entity that deploys the application.
- The Provider: the entity that hosts the application.
Given that there are live providers on the network, the lifecycle of a typical application deployment is as follows:
- The tenant describes their desired deployment in [SDL], called a deployment.
- The tenant submits that definition to the blockchain.
- Their submission generates an order on the marketplace.
- Providers that would like to fulfill that order bid on it.
- After some period of time, a winning bid for the order is chosen, and a lease is created.
- Once a lease has been created, the tenant submits a manifest to the provider.
- The provider executes workloads as instructed by the manifest.
- The workload is running - if it is a web application it can be visited, etc...
- The provider or tenant eventually closes the lease, shutting down the workload.
Docker-based deploys
Tenants define workloads requirements, as well as regional and pricing parameters, in a manifest file using a declarative language called SDL (inspired by Docker Compose). The SDL file is essentially a form to request resources from the Network.
Networking - allowing connectivity to and between workloads - can be configured via the SDL for a deployment.
By default, workloads in a deployment group are isolated - nothing else is allowed to connect to them. This restriction can be relaxed by enabling
Audited attributes allow users deploying applications to be more selective about which providers can run their apps. Anyone on the Akash Network can assign these attributes to Providers via an on-chain transaction.
Escrow accounts are a mechanism that allow for time-based payments from one bank account to another without block-by-block micropayments. They also support holding funds for an account until an arbitrary event occurrs.
Escrow accounts are necessary in akash for two primary reasons:
- Leases in Akash are priced in blocks - every new block, a payment from the tenant (deployment owner) to the provider (lease holder) is due. Performance and security considerations prohibit the naive approach of transferring tokens on every block.
- Bidding on an order should not be free (for various reasons, including performance and security). Akash requires a deposit for every bid. The deposit is returned to the bidder when the bid is closed.
It is important for the tenant to send thir manifest to the correct provider, and for the provider to ensure only valid owners can access their deployments. This authentication is implemented with mTLS and involves each account creating a certificate prior to deploying a workload or starting a provider.
Default certificate lifespan is 365 days from the moment of issuance. This can be customized to be valid up to a certain date, or not valid until a certain date.