Contents:
The Akash Marketplace revolves around Deployments, which fully describe the resources that a tenant is requesting from the network. Deployments contain Groups, which is a grouping of resources that are meant to be leased together from a single provider.
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.
Akash uses a reverse auction. Tenants set the price and terms of their deployment, and the Cloud providers bid on the deployments.
In a very simple reverse auction:
- A tenant creates orders.
- Providers bid on orders.
- Tenants choose winning bids and create leases.
A typical application deployment on Akash will follow this flow:
- 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
- The provider or tenant eventually closes the lease, shutting down the workload.
The general workflow is:
- A tenant creates orders.
- Providers bid on orders.
- Tenants choose winning bids and create leases.
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
- The provider or tenant eventually closes the lease, shutting down the workload.
Leases are paid from deployment owner (tenant) to the provider through a deposit & withdraw mechanism.
Tenants are required to submit a deposit when creating a deployment. Leases will be paid passively from the balance of this deposit. At any time, a lease provider may withdraw the balance owed to them from this deposit.
If the available funds in the deposit ever reaches zero, a provider may close the lease. A tenant can add funds to their deposit at any time. When a deployment is closed, the unspent portion of the balance will be returned to the tenant.
Escrow accounts are a mechanism that allow for time-based payments from one account to another without block-by-block micropayments. They also support holding funds for an account until an arbitrary event occurs.
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.
Bidding on an order requires a deposit to be made. The deposit will be returned to the provider account when the bid transitions to state CLOSED
.
Bid deposits are implemented with an escrow account module. See here for more information.
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.
Name | Initial Value | Description |
---|---|---|
deployment_min_deposit |
5akt |
Minimum deposit to make deployments |
bid_min_deposit |
5akt |
Deposit amount required to bid |
Creates a deployment, and open groups and orders for it.
Name | Description |
---|---|
DeploymentID |
ID of Deployment. |
DepositAmount |
Deposit amount. Must be greater than deployment_min_deposit . |
Version |
Hash of the manifest that is sent to the providers. |
Groups |
A list of group descriptons. |
Add funds to a deployment's balance.
Name | Description |
---|---|
DeploymentID |
ID of Deployment. |
DepositAmount |
Deposit amount. Must be greater than deployment_min_deposit |
Closes a group and any orders for it. Sent by the tenant.
Name | Description |
---|---|
ID |
ID of Group. |
Puts a PAUSED
state, and closes any and orders for it. Sent by the tenant.
Name | Description |
---|---|
ID |
ID of Group. |
Transitions a group from state PAUSED
to state OPEN
. Sent by the tenant.
Name | Description |
---|---|
ID |
ID of Group. |
Sent by a provider to bid on an open order. The required deposit will be returned when the bid transitions to state CLOSED
.
name | description |
---|---|
OrderID |
ID of Order |
TTL |
Number of blocks this bid is valid for |
Deposit |
Deposit amount. bid_min_deposit if empty. |
Sent by provider to close a bid or a lease from an existing bid.
When closing a lease, the bid's group will be put in state PAUSED
.
name | description |
---|---|
BidID |
ID of Bid |
Object | Previous State | New State |
---|---|---|
Bid | ACTIVE |
CLOSED |
Lease | ACTIVE |
CLOSED |
Order | ACTIVE |
CLOSED |
Group | OPEN |
PAUSED |
Sent by tenant to create a lease.
name | description |
---|---|
BidID |
Bid to create a lease from |
This withdraws balances earned by providing for leases and deposits of bids that have expired.
name | description |
---|---|
Owner |
Provider ID to withdraw funds for. |
Name | Description |
---|---|
ID.Owner |
account addres of tenant |
ID.DSeq |
Arbitrary sequence number that identifies the deployment. Defaults to block height. |
State |
State of the deployment. |
Version |
Hash of the manifest that is sent to the providers. |
Name | Description |
---|---|
OPEN |
Orders may be created. |
CLOSED |
All groups are closed. Terminal. |
Name | Description |
---|---|
ID.DeploymentID |
Deployment ID of group. |
ID.GSeq |
Arbitrary sequence number. Internally incremented, starting at 1 . |
State |
State of the group. |
Name | Description |
---|---|
OPEN |
Has an open or active order. |
PAUSED |
Bid closed by provider. May be restarted. |
CLOSED |
No open or active orders. Terminal. |
Name | Description |
---|---|
ID.GroupID |
Group ID of group. |
ID.OSeq |
Arbitrary sequence number. Internally incremented, starting at 1 . |
State |
State of the order. |
Name | Description |
---|---|
OPEN |
Accepting bids. |
ACTIVE |
Open lease has been created. |
CLOSED |
No active leases and not accepting bids. Terminal. |
Name | Description |
---|---|
ID.OrderID |
Group ID of group. |
ID.Provider |
Account address of provider. |
State |
State of the bid. |
EndsOn |
Height at which the bid ends if it is not already matched. |
Price |
Bid price - amount to be paid on every block. |
Name | Description |
---|---|
OPEN |
Awaiting matching. |
ACTIVE |
Bid for an active lease (winner). |
CLOSED |
No active leases for this bid. Terminal. |
Name | Description |
---|---|
ID |
The same as the bid ID for the lease. |
State |
State of the bid. |
Name | Description |
---|---|
ACTIVE |
Active lease - tenant is paying provider on every block. |
CLOSED |
No payments being made. Terminal. |