Since Algorand’s MainNet launch, PureStake has focused on building and delivering highly performant infrastructure to support early adopters of the Algorand network. Earlier this year, we launched an Algorand infrastructure service offering that delivers relay and participation nodes as a service targeted at early supporters and customers that want to be active participants in the network. However, we found that these services are not ideally matched to the needs of developers building applications on top of the Algorand network. So we’ve released a new Algorand API service that is specifically designed to help developers get started with Algorand REST APIs quickly and easily.
The Need for an Algorand API Service
PureStake’s Algorand infrastructure services are centered around managing the lifecycle of Algorand relay and participation nodes in an automated and secure way. Managed relay and participation nodes make sense for customers that want to — or have an obligation to — support running the network, but don’t fulfill the needs of developers who are writing applications that interact with the Algorand blockchain.
For DApp developers, the nodes are a means to an end — a way of reading data from or sending transactions to the network. They need a simpler alternative to running their own nodes, which can be costly and time-consuming.
The PureStake API service simplifies interactions with the Algorand network by hiding the complexity of running and managing nodes from the user.
Why Running Algorand Nodes Can Be Challenging
Developers always have the option of downloading and running their own nodes. However, running Algorand nodes requires both significant infrastructure investment and the right operational skills.
For example, most development use cases dictate running full archival transaction indexer nodes to achieve the best possible performance for querying transactions. The storage and sync time requirements for this type of node quickly increase as the block height increases. In the case of the Algorand MainNet, which has been live for about two months and has a block height of 1.4M blocks (as of August 2019), a transaction indexer node requires at least 20GB of storage. However, since the index database grows as a function of the number of transactions, we can expect the storage growth rate to significantly increase as transaction volume on the MainNet increases, further expanding the storage requirements.
The PureStake API Service Simplifies Interactions with the Algorand REST APIs
The API service is a natural extension of PureStake’s Algorand infrastructure platform that we built to support Algorand relay and participation nodes. Our platform uses an infrastructure-as-code approach to deploy security, networking, cloud configurations, compute, storage, and other elements into cloud data centers in an automated fashion.
The API service, which was built on top of this platform, is spread across multiple cloud data centers and features an API network layer, an API management layer, a caching layer, a load balancing layer, and a node backend layer. Each of these layers is fully redundant and managed/monitored 24×7.
How the API Service Works
The API network access layer is supported by a worldwide edge network with many peering points for request ingress, where requests are then privately routed to one of our POPs. In the POP, the API management layer then handles authentication, authorization, accounting, and further routing of API requests. It will check received requests for a valid API key header, whether the request is valid according to the account requests limits, and other security checks. It then logs the request, which is used to power end user-facing features such as endpoint utilization charts in the API dashboard. The management layer then routes API requests to backend services that can handle them.
Some queries will be handled by a high-performance cache. Other queries will be routed to the load balancer layer, which has awareness of the node resources available and routes requests on to an available Algorand node. The node layer has pools of Algorand transaction indexer nodes that can be swapped out and maintained without any downtime. These nodes are patched and updated with the latest Algorand node software as new versions are available.
What is the Difference Between the PureStake APIs and the Algorand REST APIs?
The PureStake API Service supports the official Algorand node API in the same form as exposed by the Algorand node software, which adds consistency and makes it easy to move off our service and back to self-managed nodes if needed. This design choice was an intentional one, since many proprietary APIs create vendor lock-in for its users. The only differences in our API service and the official Algorand REST APIs are the addition of the X-API-Key header that we require to secure access to our service, and the removal of the API that provides metrics about the nodes themselves. Through this approach, our users have the freedom to move between API services and self-managed nodes as needed.
Currently, our API service supports the Algod API, but not the KMD API. The Algod API can be used for querying historical information from the blockchain, getting information about blocks and transactions, and sending transactions. The KMD API, by contrast, is used for wallet management, key management, and signing transactions with private keys. We have intentionally chosen not to expose the KMD API, as we do not want any customer secrets or keys on our servers. However, customers can manage secrets and sign transactions within their applications, and post signed transactions to our API.
How the PureStake API Service Impacts the Decentralization of the Algorand Network
An essential property of the Algorand network is its decentralization. PureStake is a centralized company providing a centralized service to access that decentralized network. At first glance, it may seem like a centralized service could threaten the decentralized nature of the network (particularly if all or most of the access to the Algorand network happens through the service). Similar concerns have been raised in the Ethereum community in relation to the large number of applications relying on the Infura service to access the Ethereum network. While it may seem counterintuitive, centralized services can actually serve to support and promote the best interests of decentralized networks such as Algorand.
The first thing to point out is that this decentralization risk is not a design or protocol-level risk. No one is forced to use the service. Anyone using the service can leave and run their own nodes at any time.
In fact, there is no reason decentralization can’t proceed normally with lighter weight nodes. Algorand is going to great lengths to make sure nodes supporting the consensus mechanism do not have large storage or other infrastructure requirements. So, if someone just wants to get current account balances, submit transactions, and support consensus, they can do this with non-archival participation nodes that have much lower requirements and may not require a service provider. In addition, the upcoming vault improvements to Algorand will greatly reduce the sync time for participation nodes as well. The developer use case specifically lends itself to larger infrastructures and a service provider approach.
Secondly, Algorand needs developers, applications, and utilization of the network to be successful in the long term. The PureStake API service makes the on-ramp for developers substantially easier and will help grow the utilization and traction of the network. While there may be a hypothetical form of centralization risk in the future if the service is wildly successful, this possible future risk is far outweighed by the direct benefits to the Algorand community in helping to get traction that drives transaction volume and network utilization. In a future with more developers, applications, and network utilization, we expect competitive developer-oriented services to enter the market, which will continue to fragment the market.
Future Expansion and Long-Term Vision for the API Service
Support for the base Algorand node API is the first step for our API service. In the future, potential enhancements could include:
Additional Query-Optimized Data Stores: Taking Algorand block and transaction data and loading it into relational or NoSQL datastores opens possibilities for much more performant queries across the historical data set. These optimized data stores could be used to improve the performance of node API requests or to power net-new APIs.
Eventing Infrastructure: The idea would be to provide support for subscriptions for certain types of events, and to receive callbacks whenever they occur. DApp developers frequently implement these backend infrastructural features to improve the performance of their applications.
Getting Started with the PureStake API Service
Users can register for a free account at https://developer.purestake.io/.
Once logged into the API Services application, users will have access to an API key that is unique to their user account in their dashboard. This API key needs to be added as the value of the X-API-Key request header for any API requests being made to the PureStake service.
There are examples of how to do this and how to use the API once you have logged in at https://developer.purestake.io/code-samples and also in our Github repo https://github.com/PureStake/api-examples.
Do you have a question or an idea for a useful enhancement to the API service? Feel free to reach out to us!