Revolutionizing Solana RPC layer: insights into our x100 acceleration efforts As promised, we are sharing some new details on how our work to accelerate x100 in the RPC layer on Solana is progressing. We have some important insights about how we have already managed to reduce the delay from an average of 200-399 ms to 9 ms. And this is not all, as we aim to have a delay of no more than 3-5 ms for frequently used methods. The delay issue for users is due to extrnode proxying user requests to public RPC nodes. Some of these nodes are faster/slower than others, and they are also located in different regions. On average, getAccountInfo takes about 350-400ms to be received from a public node. At the current stage of development, we have two modules: public load balancer, which you are already familiar with and can use by connecting to it on our website. It includes a scanner and an HTTP proxy. The other module, which is still in development and has not been released yet, is called Airnode. It's a distributed data storage, similar to Google BigQuery, which has a Solana-compatible RPC and handles the requests in a similar fashion as a real node, while optimizing data storage and operational costs. It includes @solana nodes with the Geyser plugin, Geyser importer, @aerospikedb, and @grpcio API." Let's take a closer look at the Airnode module. This is an application written in Go that aims to reduce the duration of a request by properly indexing and storing blockchain data and providing an API for accessing it. The average selection from DB takes less than 1 ms, making it a much faster way to handle HTTP requests than proxying them to public nodes. The dataflow begins with a Solana validator node configured to the most minimalistic setup possible. It also includes a custom-built Geyser plugin that uses ZMQ as a transport. We decided to move in this direction after experimenting with existing implementations of Geyser, which use Kafka or other message brokers and found a much better throughput while reducing the cost of hardware due to the brokerless nature of ZMQ. On each slot, the accounts are streamed using ZMQ to one of our two importers in binary format. The importers can be connected to more than one node simultaneously and will deduplicate the data and reduce accounts to their most recent states. The accounts are stored in a buffer until we receive a message from Geyser that the slot is confirmed. Afterward, the accounts for those slots are compacted and prepared for storage. Once we have the accounts, we store them in AerospikeDB. We use concurrent writes using batches of around 500 accounts in one batch. The amount of accounts is roughly around 5000-6000 a second. We store all the indexes in memory and the data on SSD storage, which Aerospike is optimized to work with. We use GRPC for communication between the balancer and Airnode. Once a user makes a request to the balancer, and the RPC method is supported by Airnode, a GRPC request is made, and then the result is mapped to a Solana-node format. Very soon we will be back with new development details, but you can already use our public load balancer to make your dApp more stable and censorship-resistant. Just visit extrnode.com and connect to it.