Key Takeaways
- Decentralized Cloud Infrastructure: Akash Network provides a decentralized cloud platform that allows users to deploy and scale applications with no central control.
- Cosmos-Based: Built on the Cosmos SDK, Akash enables cross-chain interoperability with secure and scalable cloud services.
- Incentivized Marketplace: Features a decentralized marketplace where resource providers and users can connect for cloud services.
- Efficient Pricing: Offers cost-effective cloud computing with competitive pricing.
- Scalable and Secure: Ensures high scalability and security through a permissionless architecture.
Introduction to Akash Network’s Technical Architecture
Akash Network is an open-source cloud infrastructure platform and decentralized public utility generally classified as a Decentralized Physical Infrastructure Network (DePIN).
By foregoing the centralized approach popularized by traditional cloud computing and hosting providers such as Google Cloud and Amazon Web Services (AWS) where a single entity exhibits all-encompassing control of all aspects of access to the cloud infrastructure, Akash Network realizes a fully permissionless user-owned cloud computing framework with a low barrier to entry.
Akash accomplishes this goal by instead relying on a peer-to-peer (P2P) network infrastructure encompassing sovereign distributed ownership of the platform. Specifically, Akash Network is powered by a Proof-of-Stake (PoS) blockchain that leverages the Cosmos SDK, Tendermint Core consensus, the Inter-Blockchain Communication Protocol (IBC), and several additional components to facilitate the cloud’s overall functionality and governance.
To help provision the network's effectiveness and wide-ranging utility, the Akash Network employs industry standards such as Docker Containers and Kubernetes to host cloud deployments, ensuring high portability of code between Akash and other platforms, including numerous self-hosted solutions.
The Akash Network exhibits a high degree of fault tolerance, both administratively and utilitywise, meaning the network’s architecture represents a well thought-out design specifically for cloud computing, cloud storage, accounting, and management.
If you’d like to better understand the intricacies of Akash Network after becoming familiar with its technical architecture, consider taking a look at our introductory blog post that goes over the founding of the Akash platform, the problems Akash solves, and an overview of the network’s use cases.
To attain the far reaching utility of the Akash Network and its numerous use-specific proficiencies, the protocol is composed of several main architectural elements that allow the network to operate as an open and permissionless public utility. These include:
- Akash Layer 1 blockchain - as the main foundational infrastructure layer of the Akash platform, the blockchain layer comprises two main components:
- Akash cloud marketplace - built atop the Akash Layer 1, the Akash marketplace is made up of two main user categories that work together to ensure the operational efficiency of the Akash Network. These are:
- Akash Network validators - the 100 most powerful nodes operating on Akash, validators complement Tendermint Core and the underlying L1’s Proof of Stake consensus, while simultaneously upholding the staking incentivization mechanism that complements the network's overall integrity
Akash Cloud Marketplace
As noted above, the Akash marketplace is made of up two main user categories:
- Providers
- Tenants
In this context, a provider is a user who offers rental of physical hardware, while a tenant is any user who fields an application on the network. In essence, tenants utilize the computing power provided by providers. That said, it is possible for users to be both a provider and a tenant concurrently. An example of this could be a user fielding a web application on the Akash network, while simultaneously auctioning compute resources on a local GPU held by the user.
In order to ensure the Akash Marketplace operates as intended, the system makes use of several interconnected configuration elements that allow the network to carry out its back-end processes in confluence. These include the:
- Deployment Sequence (DSEQ): An important aspect of the Akash Network deployment process is to define a unique Deployment Sequence (DSEQ) identifier for each deployment (a deployment is a user application on the Akash Network). The DSEQ identifier is used to track and manage a user's deployments (see the Application Layer section below). Precisely, when managing deployments, the DSEQ provides a specific reference point for each instance.
- Order Sequence (OSEQ): The DSEQ also leverages an associated Order Sequence number (OSEQ) which is an administrative counter that indicates if an existing lease is closed and if a new order is placed for the same deployment (also see the Application Layer section below).
- Group Sequence (GSEQ): Additionally, several containers may be deployed as a group. To facilitate this process, a Group Sequence (GSEQ) is defined to allow a group deployment to operate with a single set of orders, bids, and leases.
Akash Network Architectural Layers
Akash Network’s architecture encompasses a multilayered structure with multiple interacting layers that work together to provide a decentralized cloud computing platform and accounting system. Therefore, Akash users encompass a “Supercloud” of multiple individual actors that provide computational and network services to tenants. This allows the network to operate in a peer-to-peer manner, as opposed to being managed by a single centralized provider.
The Akash Network is divided into four main architectural layers. These include the:
- Blockchain Layer – the underlying mechanism for smart contracts and payments
- Application Layer – provisions for administration and application deployment
- Provider Layer – provisions for hardware owners seeking to auction resources
- User Layer – provisions for end users, deploying applications on the Akash Network
1. Blockchain Layer
The Akash Network's blockchain layer is formed via a mutually beneficial relationship between the Cosmos SDK and Tendermint Core consensus. The Cosmos SDK is an open-source software development kit (SDK) that allows for the development of application-specific multi-asset blockchains.
Akash Network employs the utility of the Tendermint Core consensus engine to provide system-wide Byzantine Fault Tolerance (BFT), while leveraging the Application Blockchain Interface (ABCI) to ensure BFT replication of any application in the presence of potentially malicious actors.
One of the main benefits of building a bespoke ecosystem on an SDK is that any application specific modules needed can be implemented and added as needed, while still using the complex but well established modules that are core to the blockchain. As a result, aspects such as cryptography, consensus, and other housekeeping utilities can be handled by established code prior to implementation.
By following the design constraints of the Cosmos SDK, Akash ensures interoperability with other Cosmos blockchains, a utility considered to be of utmost importance because of the fact that users may want to handle settlements in various distinct token types.
The interoperability of Cosmos blockchains is realized via the connectivity afforded by IBC. In addition, this allows for the seamless connectivity of AKT between various blockchains (and address types) throughout the larger Cosmos network via Keplr Wallet and other related mediums.
It should be noted that payment costs for deployment on Akash or typically paid in AKT. In general, this is accomplished by procuring ATOM tokens which can easily be converted to AKT through a decentralized exchange (DEX) like Osmosis; which after purchase, allows them to be used later on within the Akash ecosystem. Nonetheless, like most crypto assets, AKT is also available on several centralized exchanges (CEX) such as Coinbase, Binance, Kraken, Revolut, and others.
2. Application Layer
The application layer is the administrative component of the Akash network that allows applications built atop Akash to operate. More particularly, the application layer harnesses four key functionalities that underpin various network-specific processes, including:
- Deployment: A deployment is the utility of the Akash supercloud, consisting of the application configuration and specifications required by the tenant user. In addition to the application code and dependencies required, a fully configured deployment contains information on what type of computational resources are requested, the required storage, billing information, and a particular geographical location (i.e. where the physical deployment will end up).
- Orders: An order is generated based on the specifications laid out in the deployment manifesto and is published by broadcast to the Akash Network marketplace. Once on the marketplace, bids can be placed on the workload by providers using the reverse auction mechanism, meaning that once an agreement has been reached, a lease can be agreed upon.
- Bids: Providers place bids on published orders via a reverse auction to ensure competitive prices to tenants.
- Leases: Finally, leases are the final step used to complete the deployment bid process. When a provider has won a bid and a contract with the tenant is effected, the tenant submits their application deployment to the winning provider. Specifically, a lease is a time and scope limited agreement with a provider to host and make available computational, storage, and connectivity resources, while simultaneously being the billable provision of the Akash ecosystem.
3. Provider Layer
As the owners of physical hardware, providers are arguably the most important users atop the Akash Network. The Provider Layer of the Akash Network comprises the components required for a provider to interact with the larger Akash ecosystem.
Providers leverage computational resources, i.e. hardware such as servers, GPUs, data storage capacity, and network connectivity. Therefore, a provider can offer as little as a single GPU, or as much as an entire data center to prospective tenants as long as unused capacity can be allocated to a deployment on the Akash network. A user who wants to offer resources to the network will need to provide the required hardware, while several additional software prerequisites are needed to manage the interaction with the Akash infrastructure. These include:
- A Provider Daemon
- Container handling
Specifically, a provider will need to run a Provider Daemon that handles the interaction with the application layer. The provider is also required to provide provisions to handle containers holding tenant’s code. The container handling a subsystem can be implemented using Kubernetes, but could also be represented by a Docker Swarm. Regardless of the approach, a container orchestration subsystem is required to ensure security and compartmentalization for both parties involved.
4. User Layer
The User Layer comprises tenants as the end users of computational resources and the provisions required for application deployment. To realize the utility of the user layer, the layer leverages two main user interface components available to tenants. To allow a tenant to deploy on the Akash Network, the user layer provides two user interfaces to realize infrastructure interaction, including the:
- Akash Client – a command line interface (CLI) built to interact with the Akash Network which allows for the creation and management of deployments, resources, and the monitoring of deployed applications
- Akash Console – a web application designed for the deployment of applications atop the Akash Network that consists of a dashboard that allows users to monitor deployments and their administrative processes
A tenant seeking to deploy an application will need to deposit the deployment fee as agreed by reverse auction prior to the lease being finalized and the deployment going live.
Akash Network Node Types
To ensure the integrity of the Akash Network’s infrastructure, the Akash Network blockchain is managed by an independent network of validator nodes.
In particular, a validator is a full Akash Node with an economic interest in the network's integrity. Any validator is required to stake AKT to this effect, and are in return rewarded accordingly. More specifically, validator nodes are responsible for realizing five main utilities with the larger Akash network:
- Block Validation: As is customary with any PoS blockchain, validation is a core functionality used to maintain a balanced and fully operational network consensus. Therefore, like any PoS chain, Akash employs validators to validate transactions and commit blocks on-chain to ensure the efficiency and integrity of the network.
- Network Security: Security is of paramount importance to any infrastructure that handles transactions with a real-world economic impact on its participants. Validators ensure this serviceability by preventing malicious or accidental or unwanted network-specific challenges including double spending and others. By ensuring the integrity of the blockchain, an agreed transaction consensus guarantees robust network security, allowing the network to operate as intended.
- Staking: Similarly to all PoS chains, staking is an important mechanism used to ensure the integrity of validators operating atop the Akash network. This is largely accomplished by requiring any validator participating in the network’s consensus to stake AKT tokens. Consequently, validators are incentivized to remain honest (non-malicious) and generally aligned with the network's best interests. In return, incentivized staking rewards are distributed to delegators (users who choose to delegate their tokens within a validator) in proportion to the validator’s overall stake. Thus, active validator nodes hold voting power proportionally to their respective stakes.
- Governance: Validators participate in the overall governance of the Akash Network via incentivized voting pro rata to their total stake. With no central authority dictating the network’s overall direction, it is the larger validator set’s responsibility to help ensure the decentralized nature of the chain's underlying infrastructure.
- Reliability: To ensure a seamless and uninterrupted experience for all users, it is critical that validators possess as much availability as possible (meaning they require nearly 100% uptime). The act of operating in perpetuity helps improve the total reward incentivization rates that validators receive.
At commencement, the number of active Akash Network validators was 85 of a possible 128 total, while the total Akash validator set is expected to grow to 442 over the next ten years. As of July 2024, the number of active validators has been extended to 100 of the currently possible 250.
In addition to validator nodes, the Akash Network makes use of Remote Procedure Call (RPC) nodes. RPC nodes are servers that give users access to data on the blockchain, while also being responsible for facilitating transaction interaction between other networks (whether on Cosmos or otherwise). In particular, Akash Network exhibits a short list of trusted community RPC nodes that are specifically allocated for public use.
Now that you are familiar with the different types of nodes operating on the network, consider having a look at our extensive overview of the Akash ecosystem and its future potential in our third and final blog post on the project.
Additional Akash Architectural Components
In addition to the numerous core infrastructure components that make up the larger Akash Network, several additional architectural elements are representative of the glue that holds the network together. These include software dependencies, required configuration file syntax definitions, and others. In general, the most important of these constitute:
- Docker Containers – compartmentalized software containers holding deployment code and configuration specificities
- Kubernetes – an open-source standardized container orchestration framework that allows providers to host deployments
- Stack Definition Language (SDL) – a standardized YAML based file format used to contain a manifest of deployment specifications and requirements
Docker Containers
Atop the Akash Network, tenants submit deployments as Docker images which include all required dependencies. These images are decompressed upon deployment and run on the provider's hardware as Docker containers. More precisely, Docker containers are an industry standard, self-contained instance containing all the code and data required for a functional instance of the service deployed.
An additional benefit of the Docker container approach employed by Akash, is that a correctly configured and packaged Docker image can be deployed to any compatible hardware or cloud running the appropriate container handling system. Of great significance, this includes Kubernetes, which are the primary container orchestration subsystems used by Akash providers.
Kubernetes
When a lease with a provider is agreed upon (i.e., between a tenant and a provider), the provider accepts Docker images that are run on their hardware. The management or orchestration of these containers is generally handled by a provider-side local Kubernetes instance. Like Docker containers, Kubernetes is another open-source industry standard that allows for the deployment of multiple independent Docker containers on a single machine.
This model enables fast deployment in a standardized environment that is common between Akash providers and largely compatible with other Kubernetes instances, including many centralized cloud computing platforms, making it easy to migrate a service between providers and even self-hosted solutions.
Stack Definition Language
The Stack Definition Language (SDL) is the format in which the requirements and configuration of an application deployment are submitted to the Akash Network. An SDL file is a human readable configuration file format based on the succinct YAML, with Akash specific key-value pairs used for the interaction with Akash subsystems. As it relates to the interconnectivity of the SDL and the Akash Network specifically, the platform makes use of information related to the client (tenant), memory and resource requirements (e.g. GPU), geographical location requests, sequence specifications (DSEQ, GSEQ, and OSEQ), and payment specifications.
Resources
The information provided by DAIC, including but not limited to research, analysis, data, or other content, is offered solely for informational purposes and does not constitute investment advice, financial advice, trading advice, or any other type of advice. DAIC does not recommend the purchase, sale, or holding of any cryptocurrency or other investment.
