For AI agents: an LLM-friendly Markdown version of every page is available by appending .md to its URL or by sending an Accept: text/markdown request header. The full documentation index is at https://www.ankr.com/docs/llms.txt
Skip to main content

Overview

Ankr provides the top-performing globally-distributed infrastructure of nodes to empower your Web3 projects with blockchain interaction capabilities.

Your project requires blockchain interaction?
Head straight to Web3 API platform.


Web3 API Service​

Web3 API Service (https://www.ankr.com/rpc/) — a platform that provides access to our top-class nodes infrastructure to query the vast list of supported chains, monitor requested data telemetry, and test the RPC API methods you require before actually using them.

Our Web3 API platform has the following solutions to offer:

  • Node API — the endpoints that enable your Web3 projects to start interacting with an extensive list of supported blockchains, give access to viewing the usage statistics for the data queried, and provide the means for RPC API methods testing.

  • Advanced API — a ready-to-use indexed collection of endpoints that supports simultaneous querying of multiple blockchains (19 mainnet and 7 testnet chains available) for the most popular Web3 scenarios at near-instant speeds; available via JavaScript/Python SDKs and React Hooks. Advanced API also gives you access to the usage statistics for the data queried.

Learn using our platform in the Getting Started docs.

Architecture​

The thing we stand out by is that we don't have a single centralized Gateway. Similar to the competition, our infrastructure consists of nodes behind a load balancer that gets a request from the client and calculates the fastest processing solution to route the request through.


RPC Service dataflow

Our fundamental distinction is that we use a whole network of geo-distributed load balancers instead of a single one for that purpose. Such an approach reduces the time needed for the request to get to a load balancer. And you don't have to work in NASA to realize that it's quicker for a user from Australia to reach an Australia-based load balancer than the one elsewhere.

Secondly, we can boast having a vast geographical distribution of nodes themselves, which never really ends to expand. And we're committed to building our network of nodes coupled by location to the network of load balancers. Thereby, we reduce the requests processing time (the time a request goes from the load balancer to the node and back), making the geographical distribution and the nodes-to-load-balancers coupling a powerful solution to increase infrastructure effectiveness and reduce querying latency.

The idea behind our geo-distributed architecture of nodes and load balancers is to provide the user with the same predictable top-quality services regardless of the user's location.

Technology​

From a technology point of view, RPC Service infrastructure relies heavily on the following pillars to provide the highest quality blockchain interaction to power your Web3 projects:


There is a monitoring system that checks the nodes' performance with a very high regularity. If something goes wrong with a node, it will be disconnected from a load balancer. Certainly, it's not performed instantly, but the speed is rather high. In other words, if anything goes wrong with a node, then it disconnects from the load balancer, and the load balancer doesn't regard that node as a candidate for sending user requests.


The load balancing algorithm uses a scoring system to determine the best possible node to serve an RPC request at any given time. A load balancer selects the quickest node to answer. To do so, each load balancer instance regularly sends a standard request to each node and measures their answer times to find out the quickest one. Therefore, we can say that each instance of a load balancer knows the quickest nodes to serve the requests for each of the blockchains.


We cache the nodes' responses. The information is stored depending on the response type. Caching duration depends on the request type. Caching serves as an additional way to reduce request processing times.


Our monitoring system checks the nodes' performance 24/7. The implemented safeguard mechanisms protect us from connecting our infrastructure with the nodes sending incorrect data. Moreover, before updating the nodes' software, we always research the peculiarities of each specific version and never use it without a complete understanding of what the update brings us, if there are any benefits in it, and how secure it is.


User transactions data is stored on the backend in anonymized form. The system knows an Ethereum address the data associates with, but it doesn't know, for example, the private endpoint that has been used. We don't store that kind of information. Therefore, even if the inconceivable happens and someone hacks into our production database, the only thing to be seen is the existence of transactions — no one would be able to create fraudulent tokens or steal funds.

Premium user-service interaction​

User transactions security relies on two premises: smart contracts and consensus mechanism.


First is that the Premium user interacts with the system via a straightforward logic of a smart contract — you can't negotiate with it, you can't outsmart it — you deposit funds (USD, ANKR) into the contract, and then you can use the corresponding amount of API Credits to make requests. Also, if you'd like to withdraw your funds, you request the operation, which will also be performed via a smart contract.


The second premise is our consensus mechanism. The consensus mechanism is the means to confirm that a user has fulfilled particular conditions and therefore qualifies for particular services. It is implemented by means of three identical oracle-like services. They receive information on the transaction being made and the user claiming to have a right for some service regarding it. Each of the consensus mechanism's parties goes to a particular blockchain involved and checks the transaction completion, verifies if that's the right smart contract the transaction made to, checks whether the transaction has been mined yet, and whether the transaction's block has at least 12 blocks on top of it.


Meeting all the conditions confirms the claimed interaction with the smart contract. If all the three parties of the consensus mechanism agree on meeting all the conditions, then a JWT token is issued for the user that enables the person to use Premium RPCs. The token issued by the consensus mechanism is encrypted. The only moment it appears in the consensus mechanism explicitly is upon generation. Then it gets stored encrypted in the database.


The system uses asymmetric encryption. It means there is a pair of keys, one of which is used for encryption and another for decryption. The user transaction data passed into the consensus mechanism contains a public encryption key by means of which the issued JWT token gets encrypted before storing. Therefore, even if anyone hacks the consensus mechanism, the only thing to be found would be encrypted data which needs private keys to be decrypted, and those private keys only the users have, so no explicit data can be found.


In the future, we are also planning to increase the number of consensus mechanism participants to involve the collaborating third parties willing to work with us. In such a case, not only our internal microservices but also the external ones would participate in the consensus mechanism to confirm its validity of providing tokens security.