Working on Multiple Blockchains
Developing across multiple blockchains means navigating different mental models, constraints, and goals. Learn which questions to ask first to avoid hours of misdirected work and frustration.
TL;DR
Before building on a new blockchain, understand the problem's constraints, the nature of your solution, and the chain's own characteristics: its founding purpose, cost and transaction-time limits, the quality and update cadence of available contracts and SDKs, and its developer community. Each chain carries its own mental model, so resist applying assumptions carried over from Ethereum or other chains directly.
When approaching a new blockchain to implement a solution, we must pay attention to some details that will avoid hours of poorly focused work and frustration, and will allow us to make the most of the resources we have at hand.
Not all blockchains are Ethereum
When we start to build solutions based on different blockchains, we find ourselves with various technological proposals. These proposals are based on the experience of other blockchains, certain assumptions, premises, objectives and mental models, different from each other. Some examples of the differences on the focus are: some of them are oriented to interoperability, others to speed, or to low transaction costs, others aim to achieve speed without sacrificing too much security, decentralization, decentralized governance, evolution through peer-reviewed proposals, and so on.
The developer’s temptation is often to come with our experience in another blockchain and pretend to apply the same concepts directly in the new one. By focusing on completing the technical knowledge, absorbing new concepts and extrapolating previous knowledge, we run the risk of not making a good diagnosis of the feasibility of implementing the required solution, in this particular technology.
What previous steps help me reduce the implementation time in a new blockchain? In summary, I would like to highlight the following:
🔷Understand the constraints of the problem I want to solve.
🔷Reflect on the nature of the solution that I want to implement on a blockchain.
🔷Learn about the characteristics of the blockchain on which I am considering the implementation.
🔹Know the fundamental idea for which this blockchain was built.
🔹Know the restrictions, for example: cost and transaction time.
🔹Know the available contract and SDK implementations and the quality of them, as well as the cadence of updates, the speed at which bugs are fixed and the general quality of the software on which we will depend.
🔹Look for the community of reference, observing if it is receptive and collaborative.
Choosing a blockchain implies choosing an entire ecosystem. However, I would like to highlight some aspects that seem relevant to me after some experiences with Ethereum, Nervos and Solana. Specifically, how to break the allure of technical details, how to look at all the relevant aspects of the technology we’re approaching, and how to have useful interaction with the developer community. This is an iterative process in which each iteration increases the quality of our understanding, our interactions, and the product we build.
The spell of technical details
In a stack that has us engrossed in its details, we run the risk of making some pretty obvious mistakes in hindsight. By forcing ourselves to stop obsessing over technological details and focus on building an accurate perception of our situation in the context of the technology being addressed, we will avoid wasting time controlling pieces of technology that we may not need.
Community
This ecosystem is made up of a set of server-side components, such as: the different types of nodes, the explorer, the faucet, among others. It is also made up of client-side tools, such as the various CLIs, SDKs, libraries, adapters in various languages, and wallets. Both categories of components are being actively developed and maintained by a community that we would like to be broad, open, distributed, with support in the most used communication channels and with effective communication of news, as much as possible. A collaborative and friendly community with new participants, which is a valuable resource when it comes to solving problems and doubts that will surely arise.
The importance of the right mental model
It is necessary to build a new mental model based on the fundamental ideas of the creators of the blockchain that we want to use. Once we get this, we’ll think in reasonable terms about the technical stuff, start asking the right questions, and make the most of our time and that of the community that’s helping us. In addition, we will be able to realize that the work of other programmers is very useful for us to achieve our goals, and very likely we will discard some of the ideas that we brought from other experiences and that we originally intended to apply in the new context.
Frequently asked questions
Why can't I reuse my Ethereum knowledge directly on another blockchain?
Each blockchain is built on different fundamental ideas, assumptions, objectives, and mental models. One chain may optimize for interoperability, another for speed, low transaction costs, security, or decentralized governance. Extrapolating concepts from Ethereum risks a poor diagnosis of whether your solution is even feasible on the new technology, leading to misdirected work.
What should I evaluate before committing to a new blockchain?
Understand the constraints of the problem you want to solve and the nature of the solution itself, then study the target chain: the fundamental idea it was built for, its restrictions such as cost and transaction time, and the quality of its available contract and SDK implementations including update cadence and how fast bugs get fixed. Also assess whether its developer community is receptive and collaborative, since choosing a blockchain means choosing an entire ecosystem.
Why does getting the right mental model matter so much?
Building a mental model grounded in the blockchain creators' fundamental ideas lets you reason sensibly about technical details, ask the right questions, and make the most of your time and the community's. It also helps you recognize useful work from other developers and discard assumptions carried over from prior chains that don't apply in the new context. The author bases this on experience with Ethereum, Nervos, and Solana.