with Dmitrii Petrov, Senior Technical Product Manager at GetBlock 

Infrastructure providers within the blockchain landscape are not always competitors. Sometimes, they work in the same field with completely different clients. Other times they can be each other’s clients. It’s never a simple formula when looking at the blockchain infrastructure space.

So today, in this webinar, our host Radu Enoiu, Co-founder and Head of Product at Bware Labs, is joined by the Senior Technical Product Manager at GetBlock, Dmitrii Petrov. Since both our businesses deal with infrastructure, you can expect a thorough review of the landscape and its current role within the blockchain ecosystem.

Beyond that, Dmitrii talked to Radu about the intricacies of running an API provider platform and our shared responsibility to safeguard the future of Web3 adoption by eliminating bad actors and providing a safe space for the community of blockchain devs to continue innovating.

The main talking points include:

• The role of full nodes in the blockchain ecosystem
• Why enterprise-level apps need an RPC node provider
• What types of users need dedicated nodes as a service
• Solutions to mass Web3 adoption

About the speakers:

Dmitrii Petrov, Senior Technical Product Manager @ GetBlock 

Dmitrii is a blockchain infrastructure geek and Senior Tech Product Manager at GetBlock. In his role, he drives product development while ensuring alignment with market needs and customer demands, working with everyone from engineers to DevOps, marketers, and beyond to identify emerging opportunities, define requirements, project timelines, and manage the entire product lifecycle.

Radu Enoiu, Co-founder and Head of Product @ Bware Labs

With over 10 years of experience in the engineering field, Radu has explored several product management and engineering roles, working for companies like Fitbit and Google. Currently, he leverages his tech expertise and contributes to providing Web3 builders with decentralized infrastructure and high API performance.

____________________________________________________________________________________________________

Subtitles

Intro

Radu 00:01
Hello everyone! And welcome to a new session of Bware Labs’ webinar sessions. For today’s session, we are going to talk about infrastructure because why not? This is what I said the World Labs know best. And together with me here today, I have Dmitrii who comes from another company that’s focused on infrastructure and trying to provide developer services within the Web3 ecosystem, GetBlock.
We will start, as usual, with a brief introduction, and I will let Dmitrii talk a little bit about himself, his experience in the blockchain world, and what he finds exciting about Web3 in general. And then, maybe, also give us an introduction about GetBlock in general.
Dmitrii 01:00
So, hi everyone! Thank you for having me as a speaker today, it’s also a great opportunity, thank you so much! My name is Dmitri, I’m the Product Manager, Tech Product Manager, at GetBlock. GetBlock is a software as a service company and we provide our clients and users with RPC nodes. Through their comprehensive set of APIs, we connect applications such as Exchanges and DeFi platforms, wallets, blockchain oracles, some security apps, and many other options to their blockchain.
Our primary expertise lies in blockchain node management. We are mainly doing nodes and that’s our main thing that we know, what we love with all of our hearts, and yeah! So, I think mainly today, we’re gonna talk about nodes, how to manage them, and how to work with them, why you need nodes, and why you don’t want to run them on your own computer by yourself, so, yeah!
Radu 02:36
Thank you Dmitrii! So, as probably everyone noticed already, this one is a discussion from or in between the same field of activity since GetBlock and Bware Labs, through blast API, struggle to solve practically the same problem: the access to blockchain by Web3 developers.
Basically, what I think we should explain here, since it’s in a webinar form, for non-technical people that try to understand technical stuff, is that in order to access blockchain networks like Ethereum, Arbitrum, or Optimism, you need access to an RPC endpoint or a web socket endpoint that is exposed by a full node or archive node from that chain.
What this means is that if you want to access the blockchain, send transactions, and read data from the blockchain, you would need to run your own node. This is all good and fine if you have a machine you can run a node with, but the problem comes when you have to go into production, and you need not one node, but several nodes, and you don’t need nodes in just one region, you need to have a geographical coverage across the world, and you need someone to make sure that all nodes are in sync with the network. You need someone to ensure that nodes don’t crash the services.
So, basically, you don’t just need some nodes, you need a DevOps team and a lot of other infrastructure. This is what both GetBlock and Blast API are trying to solve, perhaps through different approaches, but in the end, the mission is the same, and the type of service is similar: we’re trying to provide APIs as a service to developers to make their time-to-market and their development a lot easier and faster, by taking away the responsibility of running their own infrastructure in order to access the blockchain.
So, yeah, this is a broad description of what we are trying to achieve. Now, maybe we could go into a little bit more detail because, I come from an engineering background, and I think you do too. In Web3, there is this term “RPC” that is used to define all blockchain APIs, even though some blockchains do not use the RPC protocol, and they use REST or different types. But maybe we could discuss a little bit about what RPC is and what is the role of full nodes in the blockchain ecosystem, so that the audience can be aware of what we are talking about.

RPC and the Role of Full Nodes in the Blockchain Ecosystem

Dmitrii 05:49
Yeah, sure! So, let’s start I guess with the RPC. So if we’re talking in general, RPC is a remote procedure call. We put in this like web sockets, graph QR requests, gRPC or REST, and you can imagine, like gRPC also.
Also, we are trying to support all of them, but also, you need to understand that different protocols, blockchain protocols, I mean Ethereum, AVAX, Bitcoin, Tron or others, have different implementation of these RPCs, so Bitcoin supports REST, Ethereum supports JSON-RPC and 5 sockets and, sometimes, in terms of… the app, your Web3 application, and your development, you need to understand what type of RPC you need to use and you want to use.
So sometimes you need to explore something new, sometimes you know what you need to have, and maybe you could ask us or you as a plus. I mean, to try some additional things, some add ons for clients, for running node, because sometimes some nodes could be modified by enthusiasts in the blockchain world and they create some stuff, like additional stuff.
For instance, we have an additional thing, like BlockBook, which helps us index bitcoin nodes, and it’s very good and light too, because, as a default option, we block the matters which are related to Wallet Matters, because you can create on your wallet on our node, put some money in there, then tomorrow we’ll decide to update this node and switch on to another and your money’s gonna disappear!
So, that’s why we block these matters. And with this bag of matters also includes some index and other stuff, etc, that’s why you need some additional stuff, like BlockBook, which also supports not only REST RPC, and JSON, and web sockets, too. So there are so many different ways to reach these goals you have as a developer, and we, as a provider, as a company who is trying to help our clients, our friends, to build their amazing apps and products, we are trying to reach this in some way.

Why an RPC Node Provider Is Required for Enterprise-level Apps

Radu 09:06
That totally makes sense, thank you for the broad explanation. Now, I think we also should touch a little bit upon the difference between using an RPC provider versus self-hosted solution, and I’m not talking just in the case of a developer, but also when it comes from a blockchain perspective. There are a couple or some blockchains that self host some of their infrastructure and offer it, and sometimes, when discussing with them, some of them don’t understand exactly the importance of also having a RPC node provider within the ecosystem and how that is different.
Why do you need an RPC node provider within the ecosystem if you want to get to enterprise level type of applications?
Dmitrii 10:06
Well, if you’re like longer developer and you’re working with some light, like Ethereum Holsky, you can use your own computer, run it on your drive and your CPUs on your computer, and have very low latency and work with it directly and everything’s gonna be amazing because Ethereum has a great support and it’s gonna be easier to maintain it, to update it, and you can just work and have fun.
But, if you’re working with a little bit more high-loaded systems, if you need to create a workload for thousands and millions of RPC calls that are hour or minutes long maybe, then you need something more robust, I would say. Because, if you’re talking about Testnets knowledge, you can have a machine with four cores, like RGB, RAM, and about 100 GB storage. But, if you’re talking about maintenance, for the same Ethereum, you need at least a machine with 12 cores, then 64-128 RAM, and about 4 TB of NVMe storage and only NVMe storage.
So, if we decide to do this on your own computer let’s say it’s gonna cost you about 2K just to buy this computer and run it on your own. Then, you need to pay for electricity, for internet connection, because you need a good bandwidth and network – should be amazing because nodes work with the peer to peer connection and need to be connected to the blockchain constantly, every minute, every second, every moment of life, of blockchain life.
Then you spend a lot of money on this, then you need to keep it updated, always. If the version is not the last, then you risk them not having the right information, or some security risk, or etcetera etcetera.
So there are so many points why you should keep your node updated and DI, why you need to think about it. But also, you could update it to the last version and it’s gonna be dead, because the devs create this thing like deploy last version to the gith you updated, and they made a mistake! And your node is done. That’s that, and you need to sync it from the beginning. So, there are so many issues about it.
Then, you need to keep it synced, always! On the actual head you need to check it with the other nodes, you need to be aware about split situation, you need to be aware about your node health in general, about silver discs, RAM, motherboard, everything, it’s a huge machine, which like.. not machine.. Everything is working together and you need to monitor it, you need a lot of systems, you need a lot of health checks, you need services which are gonna help you keep your node alive.
Then, let’s imagine how many resources you need to spend just for one node to keep it alive, working properly, and like work with it. So, first step, you need to make it work properly, then you can start deploying, and develop your application, or some code or something.
Or, you can go to a node provider, use a free plan or like buy some requests and subscription for minimum, it could be from 10 to 30 bucks per month for different providers and forget about all this stuff and just work with nodes! And most of the providers give you for this price a huge variety of nodes or blockchains that can go with – Ethereum, or EBM, or with Bitcoins with the Tron, ZK, everything you can imagine, Solana even! We don’t talk about Solana today, so let’s skip it. I don’t want to have to end this conversation – it’s a big big problem, and yeah..
So, and then you understand that node could be not only full like you can have archived data when your storage gonna rise by 20 TB of data like full blockchain with all the information site like hashes, smart contracts, and data, everything’s gonna be included and put in your database. And it’s gonna be 20 TB of data for Ethereum, so it’s gonna cost you even more!
So I would pay 20 bucks per month when I use the node provider who takes care about all this stuff instead of me, and work with my application and nothing less. So, in the case of a single node we didn’t even discuss about what happens if a node has like a downtime and then you can’t get it up to date or it breaks and then you need a snapshot in order to put it back down and catch up to the tip of the chain, in which time your application is down, cannot be used.
So, this is something that providers save you with, since there are multiple regions available, there’s fall back in place, and that side-availability which it would be extremely costly and it wouldn’t be worth it from a d-up perspective to invest in it when, as you said, starting with 10 bucks you could simply get an endpoint and then get rid of all that work and responsibility.

Running a Multi-region Architecture and Detecting Faulty Nodes

Radu 17:09
Yeah. I think that makes total sense. So, let’s talk a little bit about some specifics. Like, I was wondering, and then we can basically compare notes, do you guys run a multi-region architecture? And also, how do you make sure that faulty or misbehaving nodes are detected and taken out of the balancing and so on, in order… I mean, if I come and use your endpoint, so that node is not responding with faulty data, so that it affects me?
Dmitrii 18:00
So, talking about multi-regional stories, we have two main clusters. We have one in the US region and a second in Europe. They are separated from each other, they don’t have anything in common. They live their own lives and we don’t connect them in any way because the US has some governing differences, law differences, and so we decided to keep it separate. But sometimes we can copy a database from one server to the other, but, in general, no.
Then, we have, I would say, two main things to keep availability high. So, the first one, as you mentioned, it’s a kind of load balancing. When you have several nodes united in one node balancing under one API, so when you send the request, it’s gonna be sent to one of the nodes, it could create a session, so you would connect to one of these nodes in the load balancing and you interact with one exact node to avoid moments with the head difference with the request you send and information you give just to, you know, it’s gonna be easier. It’s one of the options.
We’re trying to divide the traffic equally. We are not making difficult things such as comparing nodes by the resources, and this one is more powerful, the second one is not so powerful, so, in the first one, we’re gonna send 60% of traffic, on the second one we’re gonna send 40% of traffic. We have similar nodes on the same solars so they load balance, and so, we divide equally.
Then, here, we also have a technology to keep the head or the nodes the same for all of them and, on the actual head, if you’re in the node behind the actual head for more than threshold, it depends on the blockchain, we exclude this node from the load down until it’s gonna be healthy again. So, that’s load balancing.
The second thing we have is called “After Switcher.” So, it’s mainly for our dedicated node users. When you buy your own node, on your own server, and you want to be the only one and work with your application, then we create the system with After-Switching. And if the node is not healthy, if it’s gonna be overloaded, or you have some trouble with the server, I mean, with hardware, it’s gonna be automatically switched with the reserve, and, one second downtime, but it’s better than minutes and hours of downtime, so yeah. That’s the second option.
And, mostly all of these things built with our own technology which we built, named Universal Health Sidecar, for different blockchains, different protocols, have different methods to understand the head that you have and the status of it, be it health or not healthy the nodes for it. For instance, for Ethereum and the EVM like nodes, we have a method like ETH syncing, you can send it and get a response that the node is synced on the actual head, or it’s block deviation, or it’s dead.
So, other blockchains could not have this method and you need to get them at your head and compare it with other nodes with Block Explorer or something. So, we create a Universal Sidecar where you can put the endpoints just of the nodes and compare it between each other and get the status of each node in this service. It’s not perfect, of course, there could be some issues, but, the probability of these issues is around 1% or something. So the other 99% of the solutions are gonna work fine.
Radu 23:08
So, when you say, sorry, just to make sure I understand, when you say that it’s a sidecar, cause we also have somewhat of a sidecar, you mean that there’s like a software that runs along each node and makes sure that the node is responsible for is basically in sync, and by comparing with other nodes or other sources maybe even outside of GetBlock.
Dmitrii 23:40
Yes, yes. We compare our nodes with nodes outside, with nodes inside, we compare all the nodes like with other node providers, with public nodes, with everything. So, this service runs with nodes, then connects to them, like HDK and then goes to the internet.
Radu 24:00
Understood, yeah, that makes total sense.
Dmitrii 24:02
Yes, and I’m thinking to make it public because it’s a pretty easy and useful tool that could help many devs and people in the industry to keep their nodes up.
Radu 24:19
Understood, yeah. I mean, I think, within the industry, and here I’m talking about the API providers, there are different ways in which people try to achieve data consistency for their APIs and it’s interesting to see how everyone thought about it.
In the end, I think it gets boiled down to the same type of approaches, by using sidecars that compare nodes between them and then exclude the ones that are behind or some approaches that I’ve seen are that there’s a forum that is created, and basically, three or four nodes respond with the same hive those are kept and then if there’s a node even if it’s ahead or behind, it’s taken out so that data is consistent for the customers.

What Types of Users Need Dedicated Nodes as a Service

Radu 25:20
I wanted to ask about this type of service which us at Blast we don’t have, like, the dedicated node type of service that you provide. This means basically, that someone can rent out their own full node or archive node for a specific blockchain, right? And then they pay a monthly fee for having that node available so that they are the only ones that use it. Where do you see like a need for this type of service, basically, who are the personas that would require a dedicated node versus an endpoint that talks to a pool of nodes behind the load balancer?
Dmitrii 26:05
Well, here I have like several use cases. For instance, we have a company Lostless, who is working with a wide range of blockchains, and for them it’s crucial to have powerful, fast and cost active RPCs. Like, for everyone haha.. Yeah, and our nodes, our dedicated nodes help them to work with their workload, because they are working with security, but.. free security, and their customized solution for crypto wallets and smart contracts protection. Their products help defy a team’s enhance, defense against exploits, monitor trades, and implement penetration protection tools.
So, they have huge workload, they need to have their own node with their own parameters, sometimes we change some default options, like we could change the binary, which is included in a client, usually, and we can exchange it in order to change that response for several certain matters and get another response for user, for client, so dedicated nodes is, firstly, a very high loaded solution which could handle this high load and, secondly, it’s customizable. You can have anything you need on this solution. Yes, it costs more than our main Charlotte solution, when you have for one subscription of 20 bucks, 50+ blockchains in one package. And if you’re talking about the dedicated nodes, you have only one node for the price. But for some issues, for some companies who need to have high workload, we work with dedicated nodes also.
One of the examples could be Tanjam and I guess you know them. They’re the first ever card shape hardware crypto wallet that supports thousands of the blockchains or thousands of altcoins. They work with NFTs cables and.. So, we… They also have a lot of the dedicated nodes on our service just to keep their service alive and I’m 100% sure that they’re using not only us, they have two, maybe three requirements at the same time. Because yes, we have availability of 99.99%, but there could be some issues on infrastructure or there could be some issues in network, in general. And then, you need to divide your workload with several node providers, just..
Radu 29:39
Because you could simply do like a faulty upgrade and then some providers that didn’t upgrade they’re the only ones standing and the ones that upgraded and they have to come back to life. So, yeah, this is something that happened a lot of times in the industry. We had a lot of incidents like that.
In our case, because Blast has distributed components, in the sense that we run our own nodes, as you do with similar type of architecture, we have our own health checks, load balancing and so on. And we also have a protocol in which third party node operators can join and then we load balance to all the nodes, not only ours, but the third-party providers as well. And because we have this health check system we know which ones are in load balancing, which ones are out of load balancing.
And what we’ve seen happening, in terms of availability, is that at some point we would upgrade on a network the nodes in a certain region, and the upgrade has to be rolled back, but the providers they don’t do it, because they have more loose notifications around that, or, they simply have another strategy. So the region is still up because providers forgot or didn’t have the chance to update and their nodes are still working while we reverse to the upgrades. Because, you know, blockchain is still a young technology and the blockchains themselves are not as reliable as I don’t know.. the Web2 has accustomed us with.
Dmitrii 31:31
So 2 completely similar nodes and 2 completely similar services could work completely different for no reason just because one decided to go higher than actual head, the second one decided to say that “I’m gonna be fine”. So it’s really sometimes a struggle and even we’re also using other node providers to book up some of our solutions for keeping the availability 99.99%.

How GetBlock Lists New Blockchains

Radu 32:08
Exactly, exactly, yeah
Okay, so how do you decide which blockchains to integrate next? What’s your strategy around that?
Dmitrii 32:20
That’s a good question, ha ha, honestly, honestly I, I can give you an answer how we decide to remove blockchain from our list because it’s my responsibility, mostly, and if you’re talking about new blockchains, it’s mainly related to our marketing team, because they do research, they go to young companies, ask how they’re doing and do they want to have a co-marketing and partnership with us, and then we could list their protocol on our shared nodes list. So, yeah, to add someone in our lists it’s been, honestly it’s quite easy, you just need to have a great product, huge audience.
Radu 33:15
And some traction.
Dmitrii 33:16
Yeah, yeah, for sure.
And, um if we have some issues with blockchain nodes with the protocol and see it’s not as popular as we expected, we have some traction and with some metrics to understand: Is it interesting enough for our users or not?
Then we could make a solution to exclude the blockchain from our shared node list. So, um, that’s the question to exclusion and to add it’s also easy, it’s marketing resources, and sometimes, also, it could be just – you can buy a place on our list. It’s not so popular, but sometimes guys came to us and said like “We get ready to pay, just list us!” and we say like “Mmm, no! Your protocol is not interesting, It’s sht, and we can’t run it on our site, and we don’t want to work with you!” Or, in another way, we can come to a young company who created a great product and ask them: “Guys, we just want to run your product, we already run it, we have it on our list, just – let’s cooperate, let’s make co-marketing, let’s make the documentation, let’s make a blog, let’s go to their podcast or something, we are ready to work with you!” So, it’s a very interesting way to work with the market, and companies on this market, and blockchains, and developers. But mainly, it’s really our marketing staff and our guys from Spotchly and from the business development team.

How Many Chains GetBlock Supports

Radu 35:13

Yeah, makes total sense. You know, in our case, we also have like – our CEO likes to say we have similar to a VC approach – in which we verify the chain in terms of a couple of dimensions like technology, team, community, and then traction after they launch and these are the main components that are important when deciding if we should integrate them, yeah. Can I ask how many chains do you guys currently support?

Dmitrii 35:48

Oh, I would say between 50 and 60.

Radu 35:52

Oh, that’s like a big number!

Dmitrii 35:57

Recently we have some movement, and I don’t remember exactly number right now. So some something between two of these numbers.

Radu 36:06

Okay, and one last, I don’t know, logistical question before we go to my more philosophical part of the discussion – I was curious about how do you guys handle the approach, approach the team and team members, is it like a distributed team that’s globally and remote? Or do you have like an office and a team that sits closer together? Or it’s a mix?

Dmitrii 36:37

It was mixed, like we used to have an office and part of our team was distributed, but I would say about a year ago we decided to go only for remotely, and all our team is distributed, some of us sit in Europe, several guys in US, I would say, several guys moved to Dubai, and part, I would say, the hugest part sitting in Georgia and Serbia because we have two, like, legal entities, and our main one, like headquarters in Serbia, in Belgrade.

Radu 37:30

It’s close by! That’s close by, I’m actually calling from Bucharest.

Dmitrii 37:35

Yeah, yeah, yeah, yeah… I’m sitting in Berlin, Germany and we’re gonna team gather in the beginning of June, on Ethereum Belgrade, and also have a small party for guys who can come. So, right now, we are like spread everywhere, but yeah, mostly it’s Europe and Asia.

The Initial Vision of GetBlock

Radu 38:05

Sounds good. Now – next I would like to go into, more into the vision for the company and services. I’m curious how – what was the initial vision for the company, if that has changed, and what is the vision going forward?

Dmitrii 38:05

Um… we exist almost for four years already, and I came to the company about three years ago in August ‘21, and then we had 15 people, right now we’ve about 60. And those years like, then, our CEO told me that initially we were a team who help our Founder’s pet project to run the nodes. We weren’t considered like a company who’s gonna sell the nodes and be a node provider. We were just considered like helpers and just support the main project of our founders. And then, we found some clients, just accidentally, and sold them several nodes and understood that it could be, possibly, a solution to cover some costs that we have, and then we started to grow. We ran a lot of BNB’s marching nodes, those times it was BNC. In 2021 it was about 100 nodes only for BNC and several hundred for other blockchains. Right now, we are moving to 2,000 and, yeah we are thinking about creating new, like, solutions for Devs because of course, the node the blockchain node is the first step in any dApp development. You need to be connected to the blockchain, you need to work with the API, but nowadays we see that a lot of users, a lot of our clients would prefer to work with ready APIs, like indexers or event trackers, and of course they wanted to have some security for their app and they don’t want to develop it by themselves they just want to have the ready solution and work with it. So, right now we are thinking about moving to some APIs which are working on the nodes, but with our own documentation, with our own development, and it’s gonna be our own things, which we created with the years of experience we have working with nodes and know how a market exists, how a market appears, what do the people and clients need, too. So I think it’s gonna be our next steps, to, like, make it look bigger and greater.

The Split Between Dedicated and Shared Nodes

Radu 41:59

Nice! Would you say that in terms of usage, the split would be predominantly towards dedicated nodes or it goes more on the shared, or as you call it, I think shared portion?

Dmitrii 42:17

If you’re talking about people, and quality of people, of users, that’s definitely shared nodes there. It’s the most interesting product, but we still have big clients for dedicated nodes and we don’t want to, like, say them, like “Bye, bye, we don’t want to work with dedicated nodes anymore, we’re gonna work with shared.” No, of course not, we’re gonna support both these products because they’re our main products for a while and, and, all the stuff we’re gonna develop is gonna be additional. So, we, right now, concentrate on shared nodes mainly. Of course, we still support dedicated nodes, and because it’s shared nodes and dedicated nodes, it’s all nodes, and they are connected between each other and support, and, like stuff, like health sidecars and other services which could help us to monitor and alert the problems and keep the availability in the same place. So we concentrate on shared nodes – we don’t give up on dedicated nodes, and we are thinking to create our new APIs which are gonna help our users to work with blockchains.

Solutions to Mass Web3 Adoption

Radu 43:41

Okay, makes total sense, and now for the last question of the day – What would you say it requires – it is required, from an infrastructure standpoint, to make web3 technology get to mainstream adoption? In my opinion, all layers, like the product layer, or business layer, the infrastructure layer, the blockchain layer itself, they have a responsibility in order to bring Web3 to mass adoption. I was wondering, like from a dev tools and infrastructure provider, what would you think would be the responsibility that we share? Into making our contribution to achieve this?

Dmitrii 44:32

So, we share a lot of responsibility, because because of shtty nodes because of block deviation, clients and devs who’re working with their dApps could lose a lot of money just because they got no actual information and they got, like, messed up with something and just lost the moment when to buy or sell or do other stuff. That’s the biggest of our responsibility and we’re really, like, thinking about it every day and that’s why we have a reserve of our infrastructure with the other node providers, just because we understand the responsibility.
Then, the second one is security, of course, that’s also a very big thing because – We had a client who didn’t anonymize himself, he just used his email and stuff like this, and he bought a lot of dedicated nodes, and made a big check, and started to abuse in it, and then one way, let’s say. Then we start to look for information, “what is he doing?”, and we found his Twitter because it was on the same email he joined our service with, and in this Twitter he sent the information on how he scammed people on the blockchain, how he frauded people and get so much money. That’s the most like – the issue for us, like, we understand that we could have a lot of money with this guy but we don’t want to work with this guy because it’s not ethical, it’s not ethical it was, yeah, so we just made a refund and sent him, like, “Goodbye, have fun, and please don’t get back.”
Oh – sometimes you need to choose between being a good person, a good business, and a responsible business, and money and like, on the first side, in the first place, it could seem like money is good for business, and that’s the only thing, like businesses exist for money, of course, we, all of this understand, but I would say on long distance, being a good person, being a good business for me, is more profitable rather than having money right here and right now. So, responsibility for your users, for your clients is a very big thing, and you need to be honest and transparent in front of them. And as I’m, like, leading technical and customer support, trying to, like, say “Guys, don’t lie, tell them how it’s, if we messed up, we messed up, just be honest, that’s fine!”
Radu 47:59
Yeah, actually it’s – you create more trust by being transparent and people remember you like that, rather than trying to cover up when it’s obvious.
Dmitrii 48:14
Yes, people are not stupid, they see. Even devs who are working with the stuff, they know why you could mess up and they just understand, they can like make 1 + 1 and understand that you, you messed up, you’re trying to say that “It’s the weather, it’s a storm on the East Coast, that’s why our node is down!” No, of course not, you just messed up with updates or something, and just be honest and it’s gonna be fine.
Radu 48:42
Yep, that makes sense, I always tell the team that sometimes a bad situation that is handled perfectly, or in a good way, gives you, it’s more valuable for you and in regards to your customers than if the situation never happened. So an incident can put you in a very good light if you answered in time if you were fully transparent and fixed it quickly, then you get more trust and if you didn’t fail at all. So, cause people will remember your behavior during crisis more than when they didn’t need you at all. So yeah.
Dmitrii 49:21
And long distance, you gonna have clients who believe in you, who know that you are not lying there, they can rely on you, you wanna just keep them and it’s much more profitable rather than working with guys who come and and leave you.

Radu 49:41
That totally makes sense. Okay, sir, I think we reached the final of our current discussion, the, we will make this available for our community, and your community, and I hope there was like an interesting discussion, and people understood the struggles of RPC providers within the ecosystem, and our role within all this web3.
Dmitrii 50:10
Like we are not enemies, we are working on the same field.
Radu 50:17
Yeah, thank you, and have a great rest of the day!