Introduction
In the changing and dynamic world of modern computing where the efficiency and accuracy of an application is the most important aspect. A new metric called Compute Unit has been formed to simplify the way developers access and manage their computation resources more efficiently. Just like how Amazon Web Services (AWS) offers a simplified approach to compute usage pricing, Alchemy's compute units give a clear and reasonable method to pay for the computing resources your applications require.
In this article, we will be looking into the Alchemy compute units and their pricing list.
What are Compute Units?
Compute Units serve as an accurate meter to measure the total amount of computing resources our apps use inside the Alchemy ecosystem. In other words, Compute Units is a standardized measure of the computing resources that are required by our application on the Alchemy platform. This concept is similar to how AWS(Amazon Web Services) charges for computing consumptions. Computer units can be considered like tokens, each representing a unit of computing energy that fuels the functionality of our program.
Whether we are performing simple light-weight queries like eth_blockNumber or more intense queries like eth_getLogs, on alchemy, performing each of these activities consumes some computational unit to get executed
Why use Compute Units in Alchemy?
Compute units provide the most developer-friendly environment across the entire platform. By providing pricing on the compute units of the application, Alchemy charges the developers the most appropriate price. We pay for what we are using in the application and not paying any extra charges for simple requests.
What are Compute Units Per Second(CUPS)?
Alchemy offers Compute Units Per Second (CUPS) as a process that determines the dedicated Throughput for each application in the world of computational dynamics. CUPS tracks the rates at which your application interacts with Alchemy's resources, allowing you to exceed your allotted Throughput during high demand momentarily. Unlike traditional request-based calculations, CUPS weighs the cumulative Compute Units utilized across queries, ensuring fairness in resource consumption representation.
For example
var content = new
{
id = 1,
jsonrpc = 2.0,
@params = new[]
{
"your account address", "latest"
},
method = "eth_getBalance" // method eth_getBalance o get the accounts balance
};
string strContent = JsonConvert.SerializeObject(content, Formatting.Indented);
var client = new HttpClient();
var request = new HttpRequestMessage
{
Method = HttpMethod.Post,
RequestUri = new Uri($"https://polygon-mainnet.g.alchemy.com/v2/{apiKey}"),
Headers =
{
{ "accept", "application/json" },
},
Content = new StringContent(strContent)
{
Headers =
{
ContentType = new MediaTypeHeaderValue("application/json")
}
}
};
var response = await client.SendAsync(request);
In the above code, we are sending one eth_getBalance(19 CUs).
var content = new
{
id = 1,
jsonrpc = 2.0,
method = "eth_chainId" // method to get the chain id of the network
};
string strContent = JsonConvert.SerializeObject(content, Formatting.Indented);
var client = new HttpClient();
var request = new HttpRequestMessage
{
Method = HttpMethod.Post,
RequestUri = new Uri($"https://polygon-mainnet.g.alchemy.com/v2/{apiKey}"),
Headers =
{
{"accept", "application/json"},
},
Content = new StringContent(strContent)
{
Headers =
{
ContentType = new MediaTypeHeaderValue("application/json")
}
}
};
var response = await client.SendAsync(request);
In the above API call, we are using one eth_chainId (0 CUs).
var content = new
{
id = 1,
jsonrpc = 2.0,
method = "eth_estimateGas", // method to calculate gas estimate for a function
@params = new[]
{
new
{
to = "your account address",
gas = "0x00",
gasPrice = "0x09184e72a000",
value = "0x00",
data = "0x"
},
new
{
to = "your account address",
gas = "0x00",
gasPrice = "0x09184e72a000",
value = "0x00",
data = "0x"
}
}
};
string strContent = JsonConvert.SerializeObject(content, Formatting.Indented);
var client = new HttpClient();
var request = new HttpRequestMessage
{
Method = HttpMethod.Post,
RequestUri = new Uri($"https://polygon-mainnet.g.alchemy.com/v2/{apiKey}"),
Headers =
{
{ "accept", "application/json" },
},
Content = new StringContent(strContent)
{
Headers =
{
ContentType = new MediaTypeHeaderValue("application/json")
}
}
};
var response = await client.SendAsync(request);
In this above code, we are calling the eth_estimateGas (87 CUs) request.
If we send all these three requests in the same second, then we will have a total throughput of 106 CUPS.
You will be getting the list of computing units for each Alchemy API call pre-determined by Alchemy below.
Compute Unit Costs Table
Understanding the cost implications of Compute Units is essential for optimizing your application's resource allocation. Below, we present the Compute Unit cost associated with various API calls. This breakdown will empower us to make smart decisions about resource utilization, ensuring a cost-efficient and well-balanced computational experience.
Standard EVM JSON-RPC Methods
Below is the list of the Standard EVM JSON-RPC methods for blockchain networks like Ethereum, Polygon PoS, Polygon zkEVM, Optimism, Arbitrum, and Astar.
Method |
Compute Unit (CU) |
net_version |
0 |
eth_chainId |
0 |
eth_syncing |
0 |
eth_protocolVersion |
0 |
net_listening |
0 |
eth_uninstallFilter |
10 |
eth_accounts |
10 |
eth_blockNumber |
10 |
eth_suscribe |
10 |
eth_unsuscribe |
10 |
eth_feeHistory |
10 |
eth_maxPriorityFeePerGas |
10 |
eth_createAccessList |
10 |
eth_getTransactionReceipt |
15 |
eth_getUncleByBlockHashAndIndex |
15 |
eth_getuncleByBlockNumberAndIndex |
15 |
eth_getTransactionByBlockHashAndIndex |
15 |
eth_gettransactionByBlockNumberAndIndex |
15 |
eth_getUncleCountByBlockHash |
15 |
eth_getUncleCountByBlockNumber |
15 |
web3_clientVersion |
15 |
web3_sha3 |
15 |
eth_getBlockByNumber |
16 |
eth_getStorageAt |
17 |
eth_getTransactionByHash |
17 |
eth_gasPrice |
19 |
eth_getBalance |
19 |
eth_getCode |
19 |
eth_getFilterChanges |
20 |
eth_newBlockFilter |
20 |
eth_newFilter |
20 |
eth_newPendingTransactionFilter |
20 |
eth_getBlockTransactionCountByHash |
20 |
eth_getBlockTransactionCountByNumber |
20 |
eth_getProof |
21 |
eth_getBlockByHash |
21 |
erigon_forks |
24 |
erigon_getHeaderByHash |
24 |
erigon_getHeaderByNumber |
24 |
erigon_getLogsByHash |
24 |
erigon_issuance |
24 |
eth_getTransactionCount |
26 |
eth_call |
26 |
eth_getFilterLogs |
75 |
eth_getLogs |
75 |
eth_estimateGas |
87 |
alchemy_getTransactionReceipts |
250 |
eth_sendRawTransaction |
250 |
eth_getBlockReceipts |
500 |
Transfers API
Below is the method used to get the asset transfers of an account along with its compute unit required for execution.
Method |
Compute Unit (CU) |
alchemy_getAssetTransfers |
150 |
Token API
Below is the list of the methods which are used during ERC20 token-related calls, along with their compute unit (CU).
Method |
Compute Unit (CU) |
alchemy_getTokenBalances |
26 |
alchemy_getTokenMetadata |
16 |
alchemy_getTokenAllowance |
19 |
NFT API
To encourage developers to use as much of NFT API as they need, Alchemy discounted the NFT API request count towards the application. Below is the list of NFT API methods, along with their compute units. To calculate how much NFT API you can use, consider the throughput CU below.
Method |
CU |
Throughput CU |
getNFTMetadata |
100 |
10 |
getContractMetadata |
250 |
10 |
getNFTs |
600 |
100 |
getContractsForOwner |
350 |
100 |
getNFTsForCollection |
600 |
50 |
getOwnersForToken |
100 |
10 |
getOwnersForCollection |
600 |
20 |
getFloorPrice |
100 |
10 |
getNFTSales |
180 |
10 |
computeRarity |
100 |
10 |
summarizeNFTAttributes |
100 |
10 |
isHolderOfCollection |
100 |
10 |
searchContractMetadata |
500 |
50 |
getNFTMetadataBatch |
600 |
100 |
getContractMetadataBatch |
600 |
100 |
getSpamContracts |
600 |
10 |
isSpamContract |
100 |
10 |
isAirdrop |
100 |
10 |
Transact API
Below is the list of Transact API methods, along with their CU.
Method |
Compute Unit (CU) |
eth_sendPrivateTransaction |
250 |
eth_cancelPrivateTransaction |
250 |
alchemy_simulateAssetChanges |
2500 |
alchemy_simulateExecution |
2500 |
Debug API
These methods are used to debug the transaction. Below is a list of the compute unit of these methods.
Method |
Compute Unit (CU) |
debug_traceTransaction |
309 |
debug_traceCall |
309 |
debug_traceBlockByHash |
497 |
debug_traceBlockByNumber |
497 |
Trace API
Below is the list of methods that are used to trace the transaction calls along with their compute units.
Method |
Compute Unit (CU) |
trace_get |
17 |
trace_block |
24 |
trace_transaction |
26 |
trace_call |
75 |
trace_rawTransaction |
75 |
trace_filter |
75 |
trace_replayTransaction |
2983 |
trace_replayBlockTransactions |
2983 |
Polygon PoS Specific Methods
Some specific methods only for Polygon PoS chain along with their compute units are as follows.
Method |
Compute Unit (CU) |
bor_getAuthor |
10 |
bor_getCurrentProposer |
10 |
bor_getCurrentValidators |
10 |
bor_getRootHash |
10 |
bor_getSignersAtHash |
10 |
All the compute unit costs provided in the above tables are referenced from Alchemy's official site.
Conclusion
In conclusion, Compute Units have evolved as a critical element inside Alchemy's ecosystem in the field of computing. These units provide developers with a precise and transparent way to measure and manage computing resources. Alchemy achieves a balance of efficiency, accuracy, and cost-effectiveness using Compute Units and CUPS.
FAQs
Q. What are the key advantages of using Compute Units in Alchemy?
A. Compute Units in Alchemy offer several advantages for developers. First, they provide a standardized and accurate metric for measuring computational resource usage, enabling precise allocation and billing. Second, Compute Units Per Second (CUPS) ensures fair and dynamic resource allocation during high-demand periods. Third, developers pay only for the actual computing resources consumed by their application, eliminating unnecessary charges. Lastly, Compute Units empower developers to optimize their resource allocation, resulting in cost-effective and well-balanced computational experiences.
Q. How do Compute Units differ from traditional request-based pricing models?
A. Compute Units fundamentally differ from traditional request-based pricing models. Traditional models charge based on the number of individual requests made to an API, which can lead to unpredictable and sometimes inefficient billing. In contrast, Compute Units consider the cumulative computational energy consumed by an application's activities, providing a more accurate representation of resource usage. This ensures that developers are charged based on the actual work done by their application, fostering a transparent, developer-friendly, and cost-effective approach to resource management.