On the final instalment of the Infrastructure, ZEND&FRIENDS Series, we had none other than the Chainstack team as our featured guest. Ake, Knowledge Manager and Antonio, Developer Advocate, joined Brian on a new AMA on zkLend’s Twitter Space. Nodes, multichain, private networks, and much more, was covered.
Full Recording
Listen to the full recording on our Spotify now.
AMA TLDR
The ‘Why’ of Chainstack [03:41]
Chainstack has been around for four years, and when you look back on how Chainstack started, it makes sense because developers want to focus on building their project (services, smart contracts, dApps, etc.), but infrastructure is something that they find it to be a bit of a chore. So it makes perfect sense to use one of the node providers like Chainstack for it.
Chainstack was started by our CTO and Founder, Eugene Aseev, who at the time was doing a service on blockchain in a proprietary software company that needed a nexus to blockchain nodes on Ethereum in order to provide this service to their customers. They soon realised that to run any client software on Ethereum required a lot of expertise. And even with all this expertise, the path wouldn’t be the same as with other web2 server providers like AWS since you need have geographically dispersed and distributed servers to provide the same kind of service wherever your customers are based.
Once you have this expertise, you can help other builders so they can do what they want to, not what they have to do. — Ake [6:30]
What sets Chainstack apart [07:22]
We offer services to around 12–14 different blockchain protocols on Ethereum, Polygon, BNB Chain, and StarkNet that we launched recently, to name a few. Basically we offer services with the most common blockchains, and we keep adding protocols almost every month.
If there is a protocol that we don’t support and there’s demand from both developers and builders, we go for it and include it as soon as possible. We offer multicloud support, which means that our nodes run AWS, Google Cloud, Microsoft Azure, and Virtuozzo. We deploy our nodes across the globe so developers can decide which cloud provider they want for their node and which region. It is super helpful to get your nodes as closer to your users as possible to get the best performance.
We also have a ton of customisations that we can do. For example, last week we launched new features like warp transactions which distributes transactions across the networks super fast. We also deployed the MEV client, the bottom trace APIs, and we offer different clients for your nodes.
So there are a lot of things that we have like very close relationship with the protocols we work. As soon as we add them to our pool, we have target connections with them, so in case of any trouble or updates they just let us know in advance.
Node Operation [11:20]
A node infrastructure provider sounds relatively easy but when you go into the specifics and talk to all the customers using our infrastructure, there is a lot things and considerations that go in there. One thing that is important for everybody to understand is that there are different types of nodes, there are nodes securing the network and there are nodes that you need in order to scale your application to be able to provide access to the network. Chainstack and other providers mainly deliver nodes that are not securing but the nodes that you need to access the network. It is not a matter about centralisation or decentralisation, it is about the more nodes provided by Chainstack equals more adoption into L3 and more people building decentralised applications.
Another thing, is the usual considerations you get if you are building a Web2 application. For example, you need geographically distributed nodes in different locations. If your end users are in Europe, Asia and the U.S., and you want them to have the same experience in terms of speed and latency, you need to have your nodes in those locations.
And then there are other things like if you need access to the main pool, if you are using different chains, you might need different methods on the nodes themselves. For example, the method that you get on Go Ethereum and Aragon, which are two different node software clients, and the methods that they use are different in some cases. If you have your application tuned to be using Go Ethereum and you want to switch to Aragon which for some cases might be more resource efficient, you need to think of your application architecture if it should support both software client methods.
Multichain [16:40]
If we focused just on Ethereum, it would be a lot easier for us, but we understand that developers they want to go multichain. For example, Aave or Uniswap are running on I don’t know how many blockchains. So we try to support as many blockchains as developers want, and if there is demand for a blockchain we will try to include.
Of course it makes it harder for us cause every blockchain has different clients, and configurations. For example Solana is very different to Ethereum, and Ethereum is not exactly the same to Avalanche C-Chain or Harmony, even though both are EVM. As part of the content team, we have to create tutorials about completely different blockchains almost every month. Last month I was creating content about StarkNet which was super challenging, and next month who knows what will be the next blockchain.
Full vs Archive Nodes [19:36]
Full nodes are technically capable of doing what archive nodes do, but performance wise, they are not the same. What you need to know with full nodes is that on EVM networks you get the states of the network anywhere from 128 to 16 blocks prior to the current block.
With archive nodes, you get network states from the first block to the last block that you are in. What this means is that, for example, if you want to get to the state of an account on an EVM network, you will get this information using an archive node for the entirety of the network. With a full node, you’d be able to get this information for the current state of the network and maybe 20 minutes in the past for Ethereum and Avalance for around 16 blocks.
Private Networks [25:41]
For private networks, one thing that is great is that you can deploy a node with one of the cloud providers that we support, and if you need to deploy some sort of software, for example a decentralised exchange arbitraging bot, that needs the maximum reduced latency you can deploy in a different AWS instance and you can have a private network setup.
Another example if you have an application where most of the customers come from Asia, then you can deploy your node in Singapore, for example, and be fine with that. Then if you get other markets catching up in Europe and the U.S., you now have two or three markets that you want to get the same latency and speed for the end users. They will use the reverse proxy at Chainstack that will route the requests originated from each of those regions to the nodes end point to provide the same latency to each of them.
Node Customisation [30:28]
If you use default node, you will get a good performance, but it is still default. There are some cases where users need to go that extra step. We can offer scaling up resources if you already have a dedicated node, but your application needs more RAM or better CPU; we can customise that.
We can change the parameters of the client, parameters related to transactions and gas fees. We can configure anything on-demand, and as long as it is not completely different we can change few parameters on the client, hardware, and operational-wise. There are no risks in implementing this, it is just an extra step that we can take and gain performance.
Chainstack & StarkNet [32:54]
We were one of the first node providers to support StarkNet, I think we launched it back in April, so we’ve been running nodes for a few months already.
We have direct connections with the StarkNet team, so anytime that they release a software upgrade or new fixes they let us know in advance. — Antonio [33:12]
We have a pretty good connection with them, that also means that by the time they decide to open source the sequencers clients we will be probably one of the first ones to support them. StarkNet runs two different pieces, you have your node clients but all the transactions have to go through a sequencer to generate these rollups. Currently those sequencers are only run by Starkware, but at a certain point they will decentralise the network and open source the code. Everyone will be able to run them, and we will try to be one of the first to support that.
About Chainstack
Chainstack is the leading enterprise-grade platform of fullnode services for blockchains, making it simple to launch and scale decentralised networks and applications.
Their mission is to bring together an ecosystem of blockchain management solutions with high degree of automation, standardisation and compatibility.
Use cases include:
- Node functionalities and tooling for #Web3 builders to scale quickly and expand onto new networks
- Traders to achieve fast transactions & real-time blockchain data, and
- Network to deploy and run subnets & permissioned chains.
Chainstack currently supports over 400 million full node and 60 million archive requests per month across multiple chains, such as Ethereum, BNB Chain, Avalanche, Fantom, Solana, Harmony, StarkNet, Tezos and more.
Chainstack’s key services covers a wide spectrum:
- Protocols — access to all existing and future protocols with unlimited request, users and projects;
- Node customisation — custom full blown node customisation to individual operation parameters;
- Global mempool access with bloXroute — ultra-fast transaction propagation and discovery; and
- Hosting options — increase speed and reduce latency through geographically distributed hosting cloud infrastructure and private networks.
Their current customers include Darkpool Liquidity, Coin98, QuickSwap, Mercury Cash and among other DeFi protocols too.
They successfully handle large volume of data requests, transaction volumes and are accelerated expansion and scaling to new networks.
But thats not all, Chainstack is providing services for StarkNet. There are elastic StarkNet nodes — provide personal, geographically diverse endpoint locations; and dedicated nodes — request-intensive workload with private hosting options.
With its patent Bolt technology, Chainstack can help users to get rapid deployment of fully synced and dedicated StarkNet nodes.
This section was adapted from our original thread, here.
About zkLend
zkLend is an L2 money-market protocol built on StarkNet, combining zk-rollup scalability, superior transaction speed, and cost-savings with Ethereum’s security. The protocol offers a dual solution: a permissioned and compliance-focused solution for institutional clients, and a permissionless service for DeFi users — all without sacrificing decentralisation.
