Bottlenecks of Multiple-Blockchain Approach

In the recent weeks or months, we saw multiple articles forecasting the future of DApps in multiple-chain. Full disclaimer, ZMOK is an Ethereum API provider, focusing on Ethereum only. This article is not meant to devalue other blockchains, their existence or their quality. Many of our friends have decided to go this way and we do not inveigh your decision. In this article, we’d like to name some pitfalls and bottlenecks of having a multiple-chain approach.

Let’s quickly name some?key arguments why people decide to go the multiple-chain way. Scalability, costs of gas fees, complicated onboarding. But, is emerging of other blockchains or layer-two options the solution to building for Web 3.0? Do we need to interconnect all chains and make them “cooperate together”?— would you name it as a solution?

Do not kill your developers’ team

Hiring for blockchain development is not an easy task. First, you’ll need to define the used programming language, SDK, libraries. We can tell Web3js is a market standard for web3 development using Ethereum. Now, how would you decide on multiple-blockchain? Ethereum defines its own methods, so what methods would you use? Even higher risk waits for you in the future — the maintenance. So far, we did not see any correct method for testing and debugging multiple-chain apps.

Middleware or translator may not save the situation

There are many companies that offer coding for multiple blockchains using one tool. First, we are not aware some of them are decentralised, so you have one more centralised step, centralized organization, on your way to decentralization. The real pitfalls we see are security issues, multiple logs, duplicate savings of data. For example, Alchemy sends a monthly newsletter with statistics about its usage. Its customers’ usage, which is better said. The route is longer, with more steps, which brings an increased risk of possible downtime. Third, you can be more than sure, the “middleware” will slow down/decrease the speed of your application, no matter how your application is designed. Easy interface or SDK, is a big benefit for sure. The only thing is to evaluate benefits versus pitfalls.

Former Ethereum API providers like Infura, Alchemy, Quicknode have decided to go multiple-chain way too. To have a really reliable, fast and multi-region infrastructure, serving billions of API calls per month, providing multiple-chain is a real challenge. Improving the quality every day and keeping competitive pricing, makes it even harder. We do not underestimate our competitors or devalue their decisions. Just saying it’s one of the reasons why we decided to focus on Ethereum only, even though we have the capacity and knowledge to connect other blockchains too.

The black horse vs multi-bet approach

Almost every smart-contracts blockchain attracts companies and developers with lower fees, faster transactions, and other features. Our question is, where’s validators and decentralization? Many blockchains were established by VC funds or still are controlled by a very small group of people. With the power to vote, change, pivot anything. With the intention to have their own token and get profit from their investment. Matter of time when it will be identified as Securities by SEC for example, and the token economics will need to be re-evaluated again.

One good example may be Solana. Downtime for 20 hours! More scaring is a way how they fixed it. Agreed on Discord what to do. Crazy. You can not agree about such important things and pivot blockchain as you wish within hours. Now image big players like banks or insurance companies, deciding about blockchain solutions. They will always watch the settled solutions (benchmark) and hate children’s disputes in the sandbox. It’s a really big risk. If you do not need this, if it’s not a deal-breaker, you possibly should think about a standard database, rather than blockchain.

The real smart-contract based blockchain was raised by a huge community improving it for years. We think it’s better to have a black horse than to bet on multiple unicorns. For now, and everything shows for the upcoming years too, it will be Ethereum. Or from the other point of view, the chance that “Ethereum killers” will do everything to stay cheap, easy to change, not secure — is very high. And from our point of view, very risky.

The strong engine in a user-friendly bodywork

The same as Bitcoin is a king between cryptocurrencies, Ethereum keeps being a king of smart-contract based blockchains. The number of validators and developers community makes it stable and attractive for small and big players.

We do not devalue SDK, middleware, interface, cross-chain interoperability providers. Making web3/DApp development easier is very valuable. If you want to focus on environment development and does not spend time running Ethereum nodes, feel free to contact us regarding a custom big package. We will cover the fast and reliable “engine” for the best price, you can embed into your “bodywork”.

No way back here

Half decision = troubles2. Once you’ll build your project on multiple blockchains, even using a middleware provider, there is no way back. No matter how complex your project is, to migrate back to one blockchain only, will be a nightmare.

Even though we are sure we’d attract more customers by adding multiple chains, ZMOK has decided to focus on providing Ethereum JSON-RPC/WS API only. And make it the best on the market.