How Decentralized Infrastructures Can Empower Web3 Development
Bware Labs Team
Flavian Manea, CEO of Bware Labs, was invited to the First Episode of the MSV podcast! Along with Szabi, the host, he shared some knowledge regarding blockchain APIs, decentralization, and what Web3 brings to the table. Flavian also talked about the story behind Bware Labs and how the project was born.
Read below and find out more about:
- What APIs are and how they’re used in Web2 and blockchain
- Decentralized infrastructures
- Blast API — Bware Labs’ main product
- Bware Labs’ preparations for the Blast API incentivized testnet
The MSV Podcast with Flavian Manea, Bware Labs CEO
Below you’ll find the summary of the first episode of The MSV Podcast. Check out the audio above for the entire conversation.
About Flavian Manea and Bware Labs
Flavian is the CEO of Bware Labs. He has more than 10 years of experience in software development and has been working for big corporations like Poker 888, Intel, and Luxoft.
Previously, he also worked in the army, and after working for two years in the system, he went into the corporate and private domains.
Additionally, he’s been into crypto since 2019, and as he stated, he was raised during the bear market, one of the best times to learn about the crypto industry.
The idea to create Bware Labs appeared along with the sudden crash of Infura, one of the biggest infrastructure providers on blockchain.
All the big exchanges were using them and had their withdrawals disabled. In that moment, Flavian and the other 4 founders realized that there was a monopoly in the industry, and the idea of creating a company that could easily compete with the leading blockchain infrastructure provider started to emerge. Soon after this, in October 2020, they founded Bware Labs.
What Is an API and What is Its Role in the Blockchain Technology?
APIs are everywhere in software development, not just in the blockchain industry. Let’s start explaining them by using an easy exercise: You’re a client at a restaurant and you make an order. You say you want pizza, spaghetti, or whatever you like. You place the order to the waiter, and the waiter goes to the chef. The chef does the work, prepares the food and everything, and the waiter comes back to deliver what you ordered.
So, the order you placed is like an API: you send a request, which in this case is: Bring me pizza and pasta and soda, and the chef, who can be considered the backend or the server side, prepares the order and sends it back to you.
Practically, It’s a form of request and response; you ask about some information and receive a response. It can be considered a communication channel between two entities.
When it comes to development in general and software development, you use APIs almost everywhere. For example, let’s take a regular web page; when you open the link, the information you see is preselected from a bigger database. The webpage can’t display the entire database, as it would take ages for it to open.
“So, how do APIs work: You have all the heavy information on a server somewhere, and the web application just tells the server: “ok, give me information about this topic, and this topic”. And it sends through an API a request to that database, and the database sends the response. Then, the webpage shows you the information in a human-readable format.”
How Does Blockchain Work in General?
The blockchain is like a database, like a big server, but distributed worldwide. Every node has its own database, like 1:1, like a distributed database. And when a transaction is made, then, that transaction is placed into the database. You have to go through an API to gain access to that database, so you query an API, and then it gives you a response, like a transaction or a user balance.
There are two ways to do this: you can either run your own node locally, on Windows or Linux, expose some APIs, and then query them. This solution is more appropriate for DevOps engineers or those with some software engineering background.
For other people who are not necessarily tech-savvy, they can simply go to a company like Infura, and now Bware Labs. They receive an endpoint, like only the API, and they can just query it directly. Circling back to the Infura issue, the blockchain was working without any issues back then. The API that was retrieving information from the blockchain was broken, and not across one exchange, across all, because they were all using the same API provider. To continue with the same restaurant example, we can say that all the waiters were broken.
More about Bware Labs
In less than two years, our team grew from 5 to 31 people, and we are still looking to hire in key positions, such as sales and marketing.
Right now, we are building a suite of products. The infrastructure side isn’t the only product the company offers. We have here two business lines: first, the validators who are securing a lot of proof-of-stake networks.
These products are multi-chain. Many of them run on Tendermint, like Axelar, Umee, and others. Also, Bware Labs works with Layer 1, like Elrond and Casper, but also with Layer 2, like Polygon, for those who are involved in the Polkadot ecosystem by running collators on parachains like Moonbeam, Moonriver, and Astar.
Also, we are bridge operators. For example, on Avalanche, Bware Labs is one of the first four bridge operators, called Wardens. In just one year, we were responsible for approximately $5B worth of assets! Practically, as a Warden, we are controlling and verifying all the transactions bridged between Avalanche and other chains.
About Blast API
The second line of business for Bware Labs is the API Infrastructure, and Blast API, the API platform is our first and main product in this line. Last year in June, we released an Alpha, a centralized version, to see what the clients’ performance requirements are, to what extent they’re satisfied, and what the industry standards would be from a centralized point of view. This year in March, the current version of Blast was released, with lots of improvements regarding payments and additional features, as well as a module that enforces decentralization of our platform (soon to be launched).
Blast offers a free subscription and Public APIs, as well as paid subscriptions that can cater to the needs of any developer or software development company. The type of data you can retrieve is the same, but the amount of data you can retrieve varies from subscription to subscription.
For example, you’re a developer, just starting to write your first lines of code, and you need access to the blockchain. You come to our platform, and you get the free version or a Public API because you don’t make so many API calls, you don’t retrieve so much information; then you develop your decentralized application, your dApp. The next step is that you go to production, publish your code, you have your own website where you have your dApp, etc. When other users are using your dApp, basically each of them is making API calls toward the Blast API, so the more users you have, the more API calls you make. This is the moment when, as a developer, you would end up needing a higher subscription, considering you already have a product, you developed it and now you have a lot of usage, you have a lot of people using it, and now it needs a lot more API calls.
Practically, the type of subscription scales along with the product you are building. As your product grows, the Blast API subscription will also grow. Our product is created to help developers on their blockchain journey, from early stages to successful applications.
Centralized vs Decentralized
When talking about APIs, it depends on what level of decentralization you want to achieve.
For instance, in a fully decentralized manner, one would rely on multiple entities or multiple parts of an API. Then, when one stops working correctly, you will have others that would replace that functionality. So, they will continue to deliver data, even if one part of the service stopped working.
This works like a redundancy mechanism, and that’s what fully decentralized would mean, however that’s pretty difficult to achieve, especially short-term. There are certain parts that can’t really be decentralized, and one of them is the DNS side; there was one example a few days ago, a website wasn’t pointing anymore to where it should, it was pointing to a malicious site. This hack was possible through the providers of the DNS.
If we were to apply this to our first example, with the restaurant, the client, the order and the chef, things get a lot more complicated. Now we have more than 3 entities in this command. In this kind of example, you can see the DNS as part of ordering to an entirely new restaurant, meaning the order goes to another restaurant and you can end up not having the product that you wanted, even though you already paid for it.
So, decentralization has several levels and layers to be considered, and one of the advantages would be that we can eliminate market monopoly. In our case, if people are using different API providers, even if one of them goes down, they have others to choose from and they can switch to another one quite fast. Developers can also have backup solution embedded in their code and if one provider isn’t responding correctly, you just send the requests through another, and the users won’t feel any change. They simply see your product functioning very well.
When deciding on which projects to support, we have the same way of working with everyone. First, we pick the ones that we particularly like from a technical point of view and some other metrics, and we start to build a relationship together.
It’s the same with Elrond, one of the biggest blockchain projects we support; since we first got in touch with them until now, we managed to build a really good technical collaboration.
When we added support for Elrond, our engineers were in contact with theirs every step of the way, and we also had a testing stage; we consider that we have been working by the book with the Elrond team.
We always had a multi-chain approach, and one of the most important things we look at is the level of adoption and how would the demand evolve over time. This is why we chose to start with EVM — Ethereum Virtual Machine — as it is one of the biggest, and a lot of projects copied some parts of what Ethereum did best and added some layers of improvements. For example, Avalanche, Fantom or Binance Smart Chain used EVM or Ethereum as a base layer, with the same APIs and other features, then they upgraded the consensus to Proof of Stake and added more improvements.
At that moment, in June last year, Ethereum was the chain that had the biggest number of applications developed on it. We saw that the other chains will start to bring the same dApps to their chains, as they were offering grants to migrate them. And it was pretty easy to do because basically, they were having the same base there, and once you’ve written a code on Ethereum, you can simply migrate it to other chains as well, with small adaptations.
And this is how we got to 13 chains and this number continues to grow. For instance, at the beginning of this year, we also saw that a lot of projects started to build on Elrond, especially because the VCs were creating ecosystem funds to invest in projects that are building on Elrond. This was the moment when we thought that they will need infrastructure and of course APIs.
Bware Labs in the context of Web3
We can say that Bware Labs is powering up Web3. Each dApp that one develops needs access to the blockchain, so our platform is like a base layer for each application. The company works at a fundamental level to help Web3 thrive. This is how we see ourselves in the Web3 ecosystem.
Short-term and long-term plans
In the next period, we will focus on the testnet, in which we’ll test out the decentralization of our protocol. Right now, the platform runs centralized with our own nodes and we plan to decentralize the node hosting part.
We found that many people are running nodes for their own use or as a hobby, and that these nodes are under-used, they’re not running at their full capacity. And now they can use our API platform to add their nodes so that they are used at full capacity and in a decentralized manner.
This will also allow us to onboard nodes from all over the world and fix another issue: having your nodes hosted in the same data center. The issue here is that if the data center is down, all nodes will go down. However, having them distributed geographically, in different data centers, would solve this problem.
By decentralizing Blast, we will delegate some of the work we do now in a centralized manner to more node providers, who want to ramp up their contribution and also win some rewards for running infrastructure.
Node providers will be able to win BWR tokens and stake some of them to increase the rewards, in a similar way to how Elrond rewards its validators: they earn rewards because they bring their contribution to the network and validate transactions.
Furthermore, the testnet will be incentivized. By participating in this testnet, you’ll receive some initial test tokens, as if you would have bought them in a public sale. After the testnet is done, the participants will be able to use those tokens to continue staking and having their initial nodes onboarded in the upcoming mainnet.
To sum it up, if you are running blockchain nodes, even as a hobby, you can join our incentivized testnet and win some rewards in the near future.
Keep an eye on our socials to find out more about our incentivized testnet and how you can participate!