Working on multiple blockchains

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.