The Web3 domain is rapidly progressing every day. However, developers and even end-users feel a void because the underlying blockchain infrastructure is not quick enough to provide an ideal user experience (UX) like that of Web2.

In the previous article, "Justifying Quick in QuickNode: A Response Time Comparison of Blockchain Node Providers," we discussed the importance of application performance for Web3 adoption. Additionally, we compared the response times of various blockchain node providers using an ideal model to measure the fastest provider for Ethereum and other EVM-based blockchains (Polygon and BNB Smart Chain). Finally, we concluded that QuickNode is the quickest and most stable blockchain node provider.

The Web3 domain is rapidly progressing every day. However, developers and even end-users feel a void because the underlying blockchain infrastructure is not quick enough to provide an ideal user experience (UX) like that of Web2.

That said, not all blockchains are equal. Every chain has a different architecture and, hence, unique requirements. The performance results of Chain A do not hold true for Chain B, and vice versa. While Ethereum and EVM-based blockchains are somewhat similar, a blockchain like Solana is a different ballgame altogether.

In this article, we will compare the performance and data reliability of blockchain node providers to determine who provides the best infrastructure experience for the Solana blockchain.

The Rise of Solana

Countless blockchains have come and gone, but none have stood the test of time like Ethereum. That's why Ethereum is considered the "gold standard" of programmable blockchains. While every other blockchain yearned to be the "Ethereum killer," Solana, the new kid on the block, took a different approach.

In 2017, Solana's founder, Anatoly Yakovenko, outlined a novel approach for blockchain timekeeping, called Proof of History (PoH), in his draft (later published as the Official Whitepaper). Eventually, PoH and other vital innovations enabled Solana to achieve a throughput of 65,000 transactions per second (TPS), with a theoretical throughput of 710,000 TPS in the future.

Solana's innovative approach has opened many doors for blockchain scalability, but has also introduced new challenges, such as managing blockchain infrastructure.

Node Providers as Deliverers

Running a Solana node to communicate with the blockchain is a demanding task. It requires powerful hardware (a minimum of 16 cores CPU with 256 GB RAM) and constant maintenance to keep up with the block time of 400 milliseconds. A small slip can lead to an unreliable local state of the blockchain.

This is where Solana node providers come to the rescue. They run and manage Solana nodes in-house and provide access to developers through an API endpoint.

Not All Providers Are Equal

As mentioned earlier, Solana is different from other blockchains. Running a node with the validator software and exposing it over an API is not sufficient, as Solana's architecture is sophisticated.

At a minimum, it requires system optimization, constant monitoring, and management of long-term persistent storage. The first two are straightforward, but managing storage with a BigTable instance is not.

While the Solana Foundation team provides a publicly accessible BigTable, it's not ideal for running self-hosted nodes. So, when running your own BigTable instance, factors such as hardware quality play a crucial role in the overall RPC performance.

As we dig deeper, differences between Solana node providers become more visible due to such factors. Therefore, it's important to compare the performance of these node providers with a realistic model and an unbiased approach to choose the best provider for your needs. In the following sections, we will do just that.

Comparing Solana Response Times

We discussed in the previous article that response time is not solely latency, but the sum of the round-trip time (RTT) and the service time. That is, the total time taken for a request to reach the destination, be processed, and sent back to the source as a response.

To measure accurate response time with complete fairness, we will use the same comparison model used earlier with these seven essential points:

1. Using paid accounts.

2. Calling RPC methods that are not easily cacheable.

3. Using multiple cloud providers.

4. Testing from multiple locations.

5. Making concurrent test calls.

6. Conducting continuous and frequent tests.

7. Keeping the data untampered.

Running The Response Time Tests

We have an internal comparison framework called QuickLee ("Quickly"), which is built using the above model and is being used to run these tests. It ticks all the boxes:

1. We use API endpoints created through paid accounts for the following providers:
   a. Alchemy
   b. Ankr
   c. Chainstack
   d. Pokt Network (Registered, not paid, as no self-serve option available)
   e. QuickNode

2. We make test calls using the getBalance RPC method to query the balance of a specific wallet address. The wallet address used as a parameter remains the same for all tests.

3. We use multiple cloud providers where QuickNode doesn't host its own infrastructure (while the others do, which is acceptable to us):
   a. Amazon Web Services (AWS)
   b. Digital Ocean (DO)

4. We set up multiple servers in various geographical locations globally:
   a. AWS
   i. Ohio (US-E)
   ii. Northern California (US-W)
   iii. Frankfurt (EU)
   iv. Tokyo (AP)
   b. DO
   i. New York (US-E)
   ii. London (EU)
   iii. Singapore (AP)

5. We created a script using Go that makes concurrent test calls to all providers.

6. We make test calls every 10 seconds, which means we have 6 data points for each provider every minute.

7. We pipe the test data without any interference into DataDog. Each test, or call, records the total response time along with other metadata, such as the response status code.

Finally, we create multiple charts in Datadog to answer various questions. The charts reflect the results in the selected timeframe.

We have created an Overview table with multiple columns:

• (Provider) Name

• Average Response Time aggregated by Datadog using the response time data points.

• Total Calls

• Failed Calls

• Availability calculated using Total Calls and Failed Calls: ((Total Calls - Failed Calls) / Total Calls) * 100

Every region-specific section has:

• Timeseries Graph drawn using the average response time. We have applied a 5-point rolling median function to the chart to remove outliers and cleanly visualize the stability.

• Top List populated based on the average response time in the region.

Which Solana Node Provider Is The Fastest?

For the comparison in the article, we will use data from Jan 22, 2023, 00:00 UTC to Feb 18, 2023, 00:00 UTC (4 weeks). We have more than 1 million data points (for each provider) in this timeframe, which is sufficient to make an unbiased and clear comparison.

In terms of availability, all providers were able to hit the 99.9% mark, except for Ankr (99.6%). Chainstack and QuickNode had the least failed calls, with 14 and 51 calls, respectively.

QuickNode had the fastest global average response time at 104 ms, followed by Chainstack and Alchemy with 361 ms and 401 ms, respectively. Overall, QuickNode was almost 3.5x faster than the next best provider.

Moreover, QuickNode appeared to be the most stable with minimal fluctuations globally.

QuickNode was also the quickest provider across all regions, with an average response time of 115 ms, 54 ms, and 139 ms in the US, EU, and AP, respectively.

In the US, QuickNode and Chainstack were the only providers with a response time under 200ms. In the EU, the difference between QuickNode and the Chainstack (runner-up) was almost 6x, with 54 ms and 300 ms, respectively. In AP, all providers except QuickNode struggled. While QuickNode had an average response time of 139 ms, the next provider in line, Chainstack, had an average response time of 699 ms.

The results above demonstrate that QuickNode is the top-performing provider globally and across all regions. Chainstack offers decent performance, followed by Alchemy, but they are still far behind.

Verifying Data Reliability

One of the biggest challenges faced by blockchain node providers and developers is data reliability. Even if you receive super-fast response times, stale data can degrade your application's performance. This is especially true for applications that use an extremely fast blockchain like Solana.

For example, Solana checks for the latest blockhash before sending a transaction, and if the data is even a minute old, the transaction won't go through. Thus, data reliability is of utmost significance.

Imagine operating a crypto wallet or running an NFT mint website. An instance of unreliable data can break your product's functionality. And if this happens too often, your customers will start looking for alternatives.

The Data Reliability Verification Model

Any data reliability verification model needs to check three essential things:

1. Is the data up-to-date?

2. Is there any lag in receiving the latest data?

3. Does the data update regularly and frequently?

We created an open-source tool, Solana Block Derby, that uses these three key pieces, along with the parts of the framework used for response time comparison. It queries the latest slot number from Solana node providers concurrently, calculates the winner(s), and stores them in a PostgreSQL database. At any point, you can query the database to find the answer to the above questions.

Running the Data Reliability Test

We ran Solana Block Derby from Feb 26, 2023, to March 1, 2023, with a timeout of 3 seconds and an interval of 5 seconds. The tool was run in parallel from three locations covering the US, EU, and AP. The response data was inserted into a database in real-time, and we collected 100,000 entries for each provider by the end of the test.

Which Solana Node Provider Is The Most Reliable?

To accurately measure data reliability, we need to account for all three factors listed above. So, let’s examine each of them one by one.

For the latest available slot data, QuickNode won the most rounds with 77,845 wins, followed by Chainstack with 56,978 wins, and Pokt Network with 54,508 wins. This means that out of every 100 calls, QuickNode provides the latest slot data 78 times.

Timeout results were similar, with Alchemy timing out the least with 67 calls, followed by QuickNode with 70 calls, and Chainstack with 108 calls. Pokt Network timed out 16,326 calls and Ankr timed out 25,531 calls, meaning they timed out 20-30 times out of every 100 calls, demonstrating substantial lag in sending the latest data.

As for updated data frequency, Pokt Network had the lowest duplicate percentage with 12.95%, followed by QuickNode with 15.58%, and Chainstack with 16.29%. Ankr and Alchemy had the highest duplicate percentages with 23.01% and 23.11%, respectively, indicating that they returned the same value 23 times out of every 100 calls, which suggests stale data.

Combining all three factors, QuickNode had the most wins with negligible timeouts and fewer duplicates compared to the others, exhibiting superior data reliability. Chainstack loosely followed QuickNode in terms of data reliability with fewer wins, similar timeouts, and duplicate percentages.

QuickNode Provides The Best Solana Infrastructure Experience

It is easy to conclude that QuickNode provides the quickest response times for Solana globally, as well as the highest data reliability and stability. Achieving this feat requires more than just running the validator software. It takes innovation, similar to Solana, to meet all the requirements and maintain consistency. QuickNode continually develops powerful elements with exceptional capabilities that work alongside regular Solana RPC to provide maximum efficiency for developers. This is how QuickNode excels!

Lastly, the purpose of this ongoing exercise is to set and maintain high standards, ensuring that we are pushing the blockchain ecosystem forward. Being an infrastructure provider and building an ecosystem around it takes time, effort, and experience. Quantifying the quality of a service requires data-driven decision-making, not biased numbers or gimmicky keywords. Ultimately, these insights help us improve the industry and support builders, which is the end goal.

Appendix

• Solana Block Derby Data Dump — GitHub Repository | SQL Queries | Data Dump (CSV)

• Justifying Quick in QuickNode: A Response Time Comparison of Blockchain Node Providers

Why QuickNode?

QuickNode is an affordable, globally-distributed, multi-chain, multi-client, premium Web3 infrastructure provider, powering industry leaders like 1inch, MagicEden, Exodus, and Nansen, to name a few. QuickNode serves more than 7 billion API requests per day (at the time of writing this article). Here's why businesses choose QuickNode for Web3 infrastructure!

Moreover, QuickNode is not only a blockchain node provider for 18+ chains but also an ecosystem in itself with a full suite of blockchain APIs and products — Core API, Token API, NFT API, GraphQL API, QuickAlerts — and the first of its kind, blockchain API Marketplace.

We say, "Do your stuff —build — and let us take care of the rest!"

A couple of decades ago, an average Internet user would have been satisfied with an email delivered to the recipient in a few minutes. However, today, it's a different case — a product would not see the light if it's not fast enough. "Speed helped make the internet what it has become."

Similarly, one of the primary causes hindering the mainstream adoption of Web3 is the overall user experience (UX). The poor UX of Web3 applications can be pinned down to many things, mainly the application performance — speed.

Application Performance In Web3

Application performance is a broad term covering many aspects, but we can boil it down to measuring an application's real-world performance and availability. More specifically (maintaining the context of this article), it's how fast the application loads and responds to user interactions. Whether Web2 or Web3, this is a crucial aspect of any application's adoption. While much has been done in the Web2 space to tackle this issue, the Web3 domain is still struggling.

A Case for Performance — Why Does It Matter?

According to research, 47 percent of users will leave a website if it does not load in two seconds, and 70 percent of mobile app users will abandon an app if it takes too long to load. It means the users would jump ship in favor of a competitor due to inadequate performance.

With Web3, this performance stack has an additional layer: continuous interaction with the blockchain. An event doesn't exist if it's not recorded on the blockchain, i.e., there's an always-on blockchain communication layer in any Web3 application.

Imagine running a DeFi / DEX aggregator like 1inch, providing a non-custodial wallet solution like Exodus, or presenting an NFT marketplace like MagicEden. Could you risk your application performance because of this blockchain communication layer? The answer should be clear.

Innovation of Fast Blockchains

The days of Bitcoin are far behind when one had to wait long for transactions to be processed. After the advent of Ethereum, things changed massively. Additionally, Layer 2 solutions built on Ethereum enhanced its efficiency. And then blockchains like Solana took it a step further by eyeing a throughput of 65,000 transactions per second (TPS), with a theoretical throughput of 710,000 TPS in the future. The blockchain space is advancing rapidly; however, these numbers would become a reality only when the underlying infrastructure is robust enough to support the ambitious goals of these blockchains.

Introducing Blockchain Node Providers

Unlike in earlier days when you could run a node on an ordinary computer, things have changed drastically. Running a node now to support your production-ready application requires ample resources — it can be hectic. You not only require costly hardware with massive specifications to set up and run the node, but you also need a full-proof plan to manage that infrastructure regularly. And, with time, these requirements are set to increase. For example, when writing this article, Solana requires a minimum of 12 cores CPU with 128 GB RAM to run its blockchain client.

Node providers come in to solve this dilemma. They run and manage blockchain nodes in-house and usually provide end-users access over an API endpoint, often utilizing blockchain RPC technology. RPC providers act as a bridge between the application and the blockchain, allowing developers to interact with the blockchain without the need to run a full node themselves. As stated earlier, running and managing nodes takes much work, so most of the industry players, including prominent ones, trust and leverage the services of these node providers to power their applications.

Lately, we have seen many new players emerge in this industry, claiming to be the fastest node provider without any evident data. Hence, it's crucial to quantify the quality of the providers transparently as we move forward. In the following sections, we will define a methodology and then compare and discuss the response times of various blockchain node providers in the Web3 space, taking into account factors such as their infrastructure, API performance, and utilization of blockchain RPC technology.

Methodology for Comparing Response Time of Blockchain Node Provider Services

We have seen many tools and discussions pop up in the recent past comparing the response time of blockchain node provider services. However, most of them are flawed at the methodological level — doing one-off tests, using free tier accounts, testing easily cacheable methods, tampering with data as a part of the methodology, etc. Hence, it's essential to have an unbiased and neutral approach to perform this comparison and also build this model realistically.

What Is Response Time?

Before diving into other things, it's essential to understand that response time is not solely latency. It's the summation of the round-trip time (RTT) and the service time, i.e., the total time taken for a request to reach the destination, be processed, and sent back to the source as a response. The response time can be divided into multiple layers — DNS resolution time, TCP connection time, SSL handshake time, time to first byte, and download time. Understanding this is the foundation for building a solid response time comparison methodology for blockchain node provider services.

Creating a Realistic Comparison Model

We have laid down the critical points required to ensure complete fairness when running the tests and gathering the data, as well as replicating a real-world use case:

1. Paid accounts - Most providers comment that their free tier is not the most performant. Therefore, using a paid account (wherever available) is crucial.

2. Not easily cacheable blockchain RPC method - Some blockchain methods are easily cacheable and can be served without putting any stress on the system. So, choosing an RPC method that engages the system and puts some pressure on it would be essential.

3. Multiple cloud/hosting providers - Running the tests using a cloud/hosting provider where self-infrastructure is hosted can introduce a considerable bias. Hence, the tests must be run using multiple unrelated cloud/hosting providers.

4. Multiple locations - Node performance can differ from region to region due to various factors — what looks good from the US may not look good from the EU, and vice-versa. Hence, the tests must be executed from multiple locations globally.

5. Concurrent test calls - The state of blockchains changes every second, so conducting these tests one after another can paint inaccurate response times. Thus, the test calls should be made concurrently for all the providers.

6. Continuous and frequent tests - The real-world use of blockchain nodes is persistent and doesn't stop. To replicate this use case, running tests and collecting data frequently for an extended period is vital.

7. Untampered data - When critically analyzing data, it's imperative to have unbiased and unmodified data, which means the data should be passed to the next stage without manipulation.

Executing the Proposed Model

Following the above points, we developed an internal tool for this purpose, QuickLee. It ticks all the boxes:

1. We created paid accounts/API endpoints for the following services and are using those in the tests:
   a. Alchemy
   b. Ankr
   c. Chainstack
   d. GetBlock
   e. Infura

2. We are making test calls using the eth_getBalance RPC method (for all the EVM-based chains). This method queries the balance of a wallet address at a specific block height (the latest in our case). Also, the wallet address used as the parameter remains the same for all the tests.

3. We are using multiple cloud/hosting providers for these tests, where QuickNode doesn't host their infrastructure (while the others do, which is acceptable to us):
   a. Amazon Web Services (AWS)
   b. Digital Ocean (DO)

4. With multiple cloud/hosting providers, we have also set up multiple servers in various geographical locations globally:
   a. AWS
   i. Ohio (US-E)
   ii. Northern California (US-W)
   iii. Frankfurt (EU)
   iv. Tokyo (AP)
   b. DO
   i. New York (US-E)
   ii. London (EU)
   iii. Singapore (AP)

5. We have created a script using Golang that makes concurrent test calls to all the providers at a defined interval.

6. The calls are made once every 10 seconds, which means we have 6 data points for each provider every minute.

7. The test data is piped (without any interference) into DataDog. Each test—call — records the total response time along with other metadata, such as the response status code.

Visualizing the Data

Using the data received in Datadog, we create multiple charts to answer various questions. These charts reflect the results in the selected timeframe.

What's the Average Response Time and Availability of Each Node Provider?

We have created an Overview table with multiple columns — Name, Average Response Time, Total Calls, Failed Calls, and Availability — sorted based on the Average Response Time.

• Average Response Time is aggregated by Datadog using the response time (data points).

• Total Calls are the total number of calls made to a provider, and Failed Calls are the number of failed calls for that provider.

• Availability is a percentage value calculated using Total Calls and Failed Calls: ((Total Calls - Failed Calls) / Total Calls) * 100

Which Node Provider Is the Fastest and Most Stable — Globally and Across Various Regions?

Every region-specific section — Global, US (United States), EU (Europe), AP (Asia-Pacific) — has a Top List and a Timeseries Graph.

• The Top List is populated based on the average response time in the region and is sorted from lowest to highest.

• The Timeseries Graph is a line chart drawn using the average response time. We have also applied a 5-point rolling median function to the chart to remove the outliers and cleanly visualize the stability. Furthermore, we have used a log scale graph instead of a linear one with the y-axis marker set to 750ms to enhance chart readability.

Results and Discussion

Though we are running these tests for multiple chains, we will do a case study on Ethereum in this article (Live dashboards for all the chains are available in the Appendix). To compare and discuss, we will use two weeks of data — from Nov 9, 2022, 12:00 UTC to Nov 23, 2022, 12:00 UTC. This timeframe amounts to almost 5 million data points, sufficient to make a fair comparison with around 600k calls made to each node provider.

From an availability perspective, all the providers were able to hit the 99.9% mark except for GetBlock (80.4%) and Chainstack (99.7%). QuickNode had the least number of failed calls (2), followed by Ankr (3) and Infura (7).

PS: GetBlock reported an attack on their services during this period.

Looking at the global average response time, QuickNode triumphed with 86ms, followed by Ankr and Alchemy with 164ms and 207ms, respectively. Overall, QuickNode was almost 2x faster than the following best and 3x faster than the average response time of the rest of the providers, excluding GetBlock (254ms).

Not just that, QuickNode seemed to be the most stable with the slightest fluctuations globally.

Regionally, QuickNode led the charge with an average response time of 45ms, 74ms, and 155ms in the US, EU, and AP, respectively. In the US, QuickNode was followed by Alchemy and Infura, with an average response time of 115ms and 133ms, respectively. In the EU, Chainstack gave tough competition to QuickNode with an average response time of 78ms, followed by Ankr with 154ms. In AP, most providers struggled with high response times — more than 200ms — except QuickNode, and Ankr, with an average response time of 155ms and 193 ms, respectively.

The results above show that QuickNode is the top performer globally across all the regions. Ankr and Alchemy exhibit decent performance following QuickNode; however, they are still far apart. Infura surprises in the US with an average response time of 133ms, while Chainstack surprises in the EU with an average response time of 78ms which is almost neck-and-neck with QuickNode.

QuickNode Provides the Fastest Response Times

For Web3 to gain mass adoption, the UX needs to be pushed to the next level. And that could only happen with highly-performant applications powered by the finest infrastructure and service — nothing short of the best!

As evident through the data, we can conclude that QuickNode is the fastest and most stable node provider (for Ethereum in this case study). In Europe and Asia-Pacific, it gets some competition from Chainstack and Ankr, respectively. However, the overall performance of QuickNode is unmatched, and it outruns the others. The exact test is running for Polygon and BNB Smart Chain, and the results outline the same conclusion (Live dashboards for all the chains are available in the Appendix).

Being an infrastructure provider and building an ecosystem around the same takes time, effort, and experience. The process of quantifying the quality of a service can only happen through data-driven decision-making and not by exhibiting biased numbers or throwing gimmicky keywords. Because eventually, these insights help us improve as an industry to support the builders — the end goal.

Lastly, the ultimate purpose here is to push the Web3 ecosystem forward. This exercise attempts to demonstrate a transparent, unbiased, and neutral perspective around the response time comparison of the blockchain node providers. Not only that, one of our objectives is to promote an industry-wide discussion about how we can align and take this forward together — we are all ears!

Good news, QuickNode has made this process easy for you! Now, you can fetch all the wallet transactions (and filter them) in a single API call with a simple RPC method — qn_getTransactionReceiptsByAddress. Yes, you read that right; one method! 😄

In this guide, we will create a simple Ethereum address explorer to see how the method works. Let's begin!

Requirements

• Python Web3 library

    pip3 install web3
  

• Streamlit
  Streamlit is an open-source framework for building UI-based data apps in Python.

    pip3 install streamlit
  

• QuickNode Endpoint
  Register a free account on QuickNode and verify your email address. Once verified, create an Ethereum-Mainnet endpoint.

As of Nov 11, 22, this method works with Ethereum-Mainnet and Ethereum-Goerli networks.

BUIDL

Fetch data from QuickNode API

1. Import components of the web3 library

    from web3 import Web3, HTTPProvider
   

2. Create a connection to the endpoint

    w3 = Web3(HTTPProvider(YOUR_QUICKNODE_ENDPOINT_URL))
   

3. Get the wallet address from the user

    address = input("Wallet address: ")
   

4. Call the qn_getTransactionReceiptsByAddress method

    txs = w3.provider.make_request('qn_getTransactionReceiptsByAddress', [
            {
                "accounts": [address]
            }
        ])
   

5. Print the response

    print(txs)
   

Now, save the file, run it:

python3 YOUR_FILE_NAME.py

and check the response. Here is what it should look like:

We got the data. Now, it's time to

Make UI

1. Import the streamlit framework

    import streamlit as st
   

2. Redefine the address variable
   In #3 above, we stored the user input (wallet address) in the address variable. With streamlit, we will do the same but with the streamlit text_input component. So, we will change the address variable definition with the following:

    address = st.text_input("Wallet Address")
   

3. Create the submit button
   We will use the streamlit button component to create the submit button.

    submit = st.button("Fetch Txs")
   

4. Call the qn_getTransactionReceiptsByAddress method
   This step and the following step will be part of the logical flow — if the Fetch Txs (submit) button is pressed. So, we will indent them in an if condition:

    if submit:
   

5. Now, we are going to use the same call from #4 above (remove from there) and use it here:

        txs = w3.provider.make_request('qn_getTransactionReceiptsByAddress', [
            {
                "accounts": [address]
            }
        ])
   

6. Iterate over the response and print the data
   We will receive the data as a JSON object from the QuickNode API. So, we will have to access the result key of the object, iterate over the elements and print the data. In the first step, we will create a variable to store the data in a string with Markdown syntax. And in the next step, we will use Streamlit's markdown component to print the data to the UI.

        for r in txs["result"]:
            tx = (
                f'TxHash: **[{r["transactionHash"]}](https://etherscan.io/tx/{r["transactionHash"]})**  \n From: **{r["from"]}**  \n To: **{r["to"]}**')
            st.markdown(tx)
   

If you notice, we are appending the transaction hash to the Etherscan URL. It is done to make it a clickable link that would open the transaction on Etherscan.

That's it! Now we can run the script using streamlit: streamlit run YOUR_FILE_NAME.py

It will give you a CLI output like this:

You can now view your Streamlit app in your browser.

Local URL: http://localhost:8501 Network URL: http://192.168.29.35:8501

Opening the Local URL will take you to the running instance of the (Streamlit) app in your browser.

🧪 Now, enter the address, click the Fetch Txs button, and see the magic happen! ✨

Conclusion

We witnessed something magical — a logic that took much of your time and resources now takes a single API call. You saw it by creating your own Ethereum address explorer with a few lines of code. What an achievement! QuickNode — Making BUIDLing easy for the developers. 🚀

Lastly, there's more to the qn_getTransactionReceiptsByAddress method:

• Filter block range — From/To block

• Filter address — From/To address

• Sort transactions

• Use pagination

We only covered a small aspect of this method. For more, you can refer to the official documentation.

Until next time... 🫡

Access

Live Demo

⚠️ Please check the notice below.

Full Code

⚠️ As of Dec 1, 2022, the method qn_getTransactionReceiptsByAddress has been disabled by QuickNode. So, the above code will break. Once the method is reenabled, the code should work.

To achieve this highly ambitious goal, the Solana Foundation team constantly updates the blockchain with new features, enhancements, and improvements. They can back this claim with data, as we can see that the team has made 4349 commits in the past one year².

Recently, they released a new feature 'Address Lookup Tables'; and furthermore, another feature 'Versioned Transactions' to support the lookup tables.

In this guide, we will

• Learn about the Address Lookup Tables and the Versioned Transactions, and,
• Create an Address Lookup Table and send a Versioned Transaction using it.

Versioned Transactions

Versioned Transactions are the new transaction format that provide additional runtime functionality to the transactions on the Solana blockchain. This means new transaction features would be available without changing the on-chain programs.

The first of these Versioned Transactions is a v0 or version 0 transaction that allows the use of an Address Lookup Table program in a transaction.

Note: All the transactions in the old format would now be tagged as legacy version transactions.

Address Lookup Tables

The Address Lookup Tables or lookup tables allow the developers to create a collection of related account addresses directly on-chain, empowering them to load more addresses in a single transaction efficiently.

A single account address is a 32-byte of arbitrary data on the Solana blockchain. And, every transaction on the Solana blockchain requires listing all the addresses it has interacted with during that transaction. This means that a single transaction can have a maximum of 35 addresses^{3 4}.

Using the lookup tables, each address can be referenced as a 1-byte index in the transaction (instead of a full 32-byte address). This method effectively compresses a 32-byte address into a 1-byte index value, allowing the users to store up to 256 addresses in a single transaction — 8x more than the old format!

Well, let us see it live... 👀

Requirements

• Node.js / Solana SDK
  Though you can use the programming language of your choice, we will use Node.js with the @solana/web3.js SDK in this guide.

  • Install Node.js on your local machine.
  • Install @solana/web3.js using the Node Package Manager (NPM):

    npm i @solana/web3.js
    

• RPC API endpoint (QuickNode)
  We will use QuickNode as it provides the fastest, most stable, and most reliable RPC API endpoints.

  • Register for a free account on QuickNode and verify your email address.
  • Create a Solana-Devnet endpoint.

• Solana wallet (Phantom)
  You can use any Solana-compatible wallet that grants you access to your private keys. We will use the Phantom wallet because of its simple UI and smooth UX.

  • Download the Phantom wallet for your browser.
  • Create a new wallet.
  • Change the Phantom wallet network to Devnet.
  • Export your Private Key and store it somewhere safe. ❗️NEVER SHARE YOUR PRIVATE KEY WITH ANYONE ❗️

Tip: We can also use Solana's File System Wallet to generate a wallet Keypair using CLI without the need for the Phantom wallet.

• Solana faucet (QuickNode Faucet)
  We will require some test funds — SOL — to experiment. Again, QuickNode provides a free multi-chain faucet to help us with this.
  • Go to the Faucet webpage.
  • Connect your (Phantom) wallet.
  • Select the Solana chain and Devnet network.
  • Follow the next steps to request your free 1 SOL on the Solana-Devnet.

That's all. We are set. 🏃🏻

Let's Code!

Define functions and variables

1. Import required modules

const solana = require('@solana/web3.js');
const bs58 = require('bs58');

Along with the @solana/web3.js SDK, we use the bs58 module to decode our private key.

2. Set required variables

const PRIVATE_KEY = [YOUR_PRIVATE_KEY_FROM_PHANTOM_WALLET];
const ENDPOINT = [YOUR_QUICKNODE_ENDPOINT_URL];

Set the variable values with the ones you have.

3. Add account addresses

let tableEntries = [
  // List of account addresses for address lookup table
];

These account addresses will be added to the lookup table later and can be any valid account address on the Solana blockchain.

4. pause()

async function pause() {
    await new Promise((resolve) => setTimeout(resolve, 5000)); // Value in ms
}

We will use this function to pause the app at a few stages to ensure that we are waiting and fetching the updated data from the blockchain.

5. createConn()

async function createConn() {
    return new solana.Connection(ENDPOINT, 'confirmed');
}

We will use this function to create an active (endpoint) connection to interact with the blockchain.

6. getLatestBlockhash()

const getLatestBlockhash = (connection) => {
    return connection
        .getLatestBlockhash('finalized')
        .then((res) => res.blockhash);
};

We will need the latest blockhash to send the transactions. This function will use the active connection to fetch the latest blockhash from the blockchain.

7. createLookupTable()

async function createLookupTable(connection, payer) {
    const [lookupTableInst, lookupTableAddress] =
        solana.AddressLookupTableProgram.createLookupTable({
            authority: payer.publicKey,
            payer: payer.publicKey,
            recentSlot: await connection.getSlot(),
        });
    return [lookupTableInst, lookupTableAddress];
}

We will use this function to create the lookup table by passing an active connection and account owner to it. It will return lookup table instructions and address, which we will use to register the lookup table on-chain through a transaction.

8. extendLookupTable()

async function extendLookupTable(payer, lookupTableAddress, addressList) {
    const extendInst = solana.AddressLookupTableProgram.extendLookupTable({
        addresses: addressList,
        authority: payer.publicKey,
        lookupTable: lookupTableAddress,
        payer: payer.publicKey,
    });
    return extendInst;
}

We will use this function to extend the lookup table by passing a list of account addresses. It will return lookup table instructions which we will use to update the lookup table on-chain through a transaction.

9. sendTx()

async function sendTx(connection, payer, inst, lookupTable, compareTxSize) {
    let message;

    if (lookupTable) {
        message = new solana.TransactionMessage({
            instructions: inst,
            payerKey: payer.publicKey,
            recentBlockhash: await getLatestBlockhash(connection),
        }).compileToV0Message([lookupTable]);
    } else {
        message = new solana.TransactionMessage({
            instructions: inst,
            payerKey: payer.publicKey,
            recentBlockhash: await getLatestBlockhash(connection),
        }).compileToV0Message();
    }

    const tx = new solana.VersionedTransaction(message);
    tx.sign([payer]);

    if (compareTxSize) {
        console.log(
            lookupTable
                ? '🟢 [With Address Lookup Table]'
                : '🔴 [Without Address Lookup Table]',
            'Tx Size:',
            tx.serialize().length,
            'bytes'
        );
    }

    const txId = await connection.sendTransaction(tx);
    return txId;
}

We will use this as our primary function to send transactions (register events on the blockchain). It accepts multiple parameters:

• Active connection
• Account owner
• Transaction instructions
• Lookup table account
• Choice to calculate transaction message size

It's a multi-step process — create message; create versioned transaction; sign transaction; send transaction.

Define main app

10. Create main app()

async function app() {
  // Everything after this point would be added to this function
}

11. Setup wallet Keypair

  console.log('👀 Solana - Address Lookup Tables / Versioned Transactions 👀');

  const privKey = bs58.decode(PRIVATE_KEY);
  const myWallet = solana.Keypair.fromSecretKey(privKey);

12. Establish connection

    const conn = await createConn();
    console.log('✅ Endpoint connected!');

13. Create lookup table

    const [lookupTableInst, lookupTableAddress] = await createLookupTable(
        conn,
        myWallet
    );
    console.log(
        `📝 Address Lookup Table Details --- ${lookupTableAddress} | https://explorer.solana.com/address/${lookupTableAddress.toBase58()}?cluster=devnet`
    );

    await pause();

    const createTableTxId = await sendTx(conn, myWallet, [lookupTableInst]);
    console.log(
        `✅ Address Lookup Table Created: https://explorer.solana.com/tx/${createTableTxId}?cluster=devnet`
    );

    await pause();

14. Extend lookup table

    let addressList = new Array();
    addressList.push(myWallet.publicKey);
    tableEntries.forEach((entry) => {
        addressList.push(new solana.PublicKey(entry));
    });

    const extendInst = await extendLookupTable(
        myWallet,
        lookupTableAddress,
        addressList
    );

    const ExtTableTxId = await sendTx(conn, myWallet, [extendInst]);
    console.log(
        `✅ Address Lookup Table Extended: https://explorer.solana.com/tx/${ExtTableTxId}?cluster=devnet`
    );

    await pause();

15. Fetch lookup table data

    const lookupTableAccount = await conn
        .getAddressLookupTable(lookupTableAddress)
        .then((res) => res.value);

    console.log('🧾 Verifying Addresses in the Lookup Table...');

    for (let i = 0; i < lookupTableAccount.state.addresses.length; i++) {
        const address = lookupTableAccount.state.addresses[i];
        console.log('Address', i + 1, address.toBase58());
    }

16. Create transaction instructions

    const txInst = new Array();
    for (let i = 0; i < lookupTableAccount.state.addresses.length; i++) {
        const address = lookupTableAccount.state.addresses[i];
        txInst.push(
            solana.SystemProgram.transfer({
                fromPubkey: myWallet.publicKey,
                toPubkey: address,
                lamports: 0.0001 * solana.LAMPORTS_PER_SOL, // 0.0001 SOL
            })
        );
    }

17. Send transactions

    // Tx with lookup table
    const sendNewTx1 = await sendTx(
        conn,
        myWallet,
        txInst,
        lookupTableAccount,
        true
    );

    // Tx without lookup table
    const sendNewTx2 = await sendTx(conn, myWallet, txInst, null, true);

    console.log(
        `🚀 Versioned Transaction with the Address Lookup Table: https://explorer.solana.com/tx/${sendNewTx1}?cluster=devnet`
    );

18. Initialize app()

app();

Output

👀 Solana - Address Lookup Tables / Versioned Transactions 👀
✅ Endpoint connected!
📝 Address Lookup Table Details --- 7x3zgryXe9RSucuV3DriSqTcj4kKPBikZPTEnAWRK8kT | https://explorer.solana.com/address/7x3zgryXe9RSucuV3DriSqTcj4kKPBikZPTEnAWRK8kT?cluster=devnet
✅ Address Lookup Table Created: https://explorer.solana.com/tx/3BcHwivCv2NQjdkZpfbpJwjUMfRQbbjTFhxTTekKsKBCPQGvd6MKKZsfQ7r8A8ZZvkpQVVY1PJvrV1rJBgEtcGZh?cluster=devnet
✅ Address Lookup Table Extended: https://explorer.solana.com/tx/3nqHuPBRxS7rupwninpTwrTxikDwGWBM8F5gGbxjKUbQ1zHEg8fTKoeJbkLaajRv7PbM48HLc43GmLXKmGe8ZLqm?cluster=devnet
🧾 Verifying Addresses in the Lookup Table...
Address 1 5FoZtVFxvSwkyyJWKiadcX4vQrTDdEcHVhwB6179bRgq
Address 2 BXBk9wAw424EQEpxMFjaqjs3D3rjfqezuKh8sobbPVy5
Address 3 FN69Pe14FDC6iEeQEb1usyy3m5EMZB2xBED6o91YaNU4
Address 4 4PUuD5o6fzjGniqTbsUKaW5cJACoJAVeJQ91JkPmTzyH
🟢 [With Address Lookup Table] Tx Size: 273 bytes
🔴 [Without Address Lookup Table] Tx Size: 332 bytes
🚀 Versioned Transaction with the Address Lookup Table: https://explorer.solana.com/tx/47ftfMgLVcSxjdCSiGiXbcnLACmsSXHPzQwH953MXC74tdDLkDGtAchfYvQLaj9ADUMEYJvvfthzA2TD2i7d735a?cluster=devnet

Conclusion

As you notice, there is a good difference in the size of the transaction message with the Address Lookup Table. The benefit would be more noticeable during transactions with custom programs and a large number of account addresses.

Hopefully, this is the first of many transaction features to come that would make the Solana blockchain more efficient.

Also, if you use RPC methods to fetch the blockchain data, it is essential to note that these changes have also impacted some RPC methods. I have posted a Twitter thread with the details about how this feature activation would affect the developers.

I hope you found this guide helpful! Until next time... 🫡

Full Code

Other Resources

• https://docs.solana.com/developing/programming-model/transactions
• https://docs.solana.com/proposals/transactions-v2
• https://solana-labs.github.io/solana-web3.js/

1. At the time of writing this guide. ↩

2. At the time of writing this guide. ↩

3. Solana blockchain uses a conservative MTU size of 1280 bytes. After accounting for headers, signatures, and other metadata, the transaction is left with around 1120 bytes. ↩

4. https://github.com/solana-labs/solana/blob/090e11210aa7222d8295610a6ccac4acda711bb9/sdk/src/packet.rs#L13 ↩

Requirements

• Python Web3 Library
  Install Python 'Web3.py' Library by executing the following command:

pip install web3

• Ethereum Node API Endpoint
  Though there are many Ethereum node service providers available online, we'll use Pocket Network for our project as it is free.

  1. Signup for an account at Pokt.network and verify your email address to get access to the endpoints.

  2. Select Apps from the side menu and click Create.

  3. Enter desired App Name and click Launch Application.

  4. Copy the Endpoint provided. (Ensure that Ethereum Mainnet is selected as the Endpoint network!

The web3 library will allow us to interact with the Ethereum blockchain through the API endpoint.

Let's Code!

1. Import required modules

from web3 import Web3, HTTPProvider

1. Save the endpoint URL in a variable

endpoint = 'YOUR_ENDPOINT_URL_HERE'

1. Make a connection to Ethereum blockchain through the endpoint

connection = Web3(HTTPProvider(endpoint))

1. Get the wallet address input from the user

address = input("Enter ETH wallet address: ")

1. Fetch the latest ETH balance from the blockchain and convert it to ether denomination.

balance = connection.fromWei(connection.eth.getBalance(address, 'latest'), 'ether')

1. Display the balance

print(f"Balance: {balance} ether")

Save the file; run it; enter ETH address and get your balance right in the terminal. That simple!

So, what's your balance? 😁