4 Questions to Ask Before Selecting a Blockchain Platform

Interest in blockchain technology has exploded over the past several years. Distributed ledger technology is capable of solving many of the issues emerging from our increasingly connected society, as well as addressing real-world business concerns. From payment remittance to supply chain logistics to secure user identity verification, blockchains are being applied to an expanding field of domains. For these reasons, businesses across the globe are designing their own decentralized applications.

When considering building a blockchain application, there are a number of questions you need to ask. People often ask the wrong questions, and they end up with a solution that is less than optimal.

Compounding that issue, the ecosystem grows every minute of every day, making it nearly impossible for a new developer to both learn the ins-and-outs of the current environment and keep up with the latest research.

The blockchain analysts and engineers at Object Computing, Inc. (OCI) have decades of combined experience and technical know-how in the blockchain space, from simple Merkle trees and consensus algorithms to zero-knowledge proofs and quantum-resistant cryptography.

In this multi-part article, we explore four key questions that cover the primary design criteria you should consider when selecting a blockchain platform. Add yourself to our blockchain mailing list to be alerted as each question is illuminated.

4 Questions to Ask Before Selecting a Blockchain Platform

1. How much privacy does your application require?

Blockchains come in many flavors. Some are centralized, meaning a single authority controls the network and the information that's available to regular users. Others are decentralized, meaning that work and data is shared across the entire network. There are even hybrid solutions, in which a centralized subchain connects to a decentralized main network.

If your application requires any amount of private information (such as real-world names, addresses, business documents, etc.) to be shared between users, you will probably want to avoid a completely decentralized solution, as any data will be permanently visible to the public.

Conversely, if your application is promoting business transparency and trustlessness, you will want to have the appropriate data stored on a public chain so it can be easily and verifiably accessed.

Remember, not all of your application’s information has to be placed on a blockchain. You can exchange information peer-to-peer without ever including a blockchain. If it is not necessary or desirable to permanently store or publicly verify your data, it is almost always better to maintain it off-chain.

Data Protection

Sometimes, your users will want to show that they have the correct private information but not share the actual data.

To prove that data exists but not reveal it, you can use a cryptographic hash to create a unique tag for that data. Cryptographic hashes are one-way streets; you can easily use the data to recreate a hash, but you cannot use a hash to recreate the data. Anyone else with that data can use the same algorithm to generate the same hash, and comparing hashes can tell you that you share the same information.

Placing hash tags on the blockchain reliably and cost-effectively tells the world that you have a specific set of data without revealing what the data is.


Another aspect of privacy is the concept of anonymity. For a truly anonymous system, there should be no way of knowing which users performed what actions.

Contrary to popular belief, most blockchains are not anonymous; they are pseudononymous. That means that while it may not be easy to specifically correlate a user with a real-world identity from within the network, it can be done using information that is connected from external services.

For example, Bitcoin users are hidden behind a public address and can hide behind infinite public addresses. However, purchasing Bitcoin requires signing up for an exchange, which then has your full name and at least one wallet address. From there, the exchange can easily track where the purchased Bitcoin goes as it moves through accounts.

Even if you do not use an exchange to purchase your Bitcoin, spending it can introduce the same problems if the recipient also knows your real-world information (for example, when purchasing goods for delivery, a merchant must have a shipping address). Combining multiple data sources can provide a complete picture of every player and what they are using the Bitcoin for. In fact, there are multiple companies that have developed software for this very purpose.   

If true anonymity is desired, there are a few blockchains (known as privacy chains) that use more complex cryptography to further hide where data is coming from. Among the most popular of these are ZCash and Monero. However, even privacy chains can be compromised by users unwittingly correlating their on-chain activity with real-world action, or even by multiple people just using standard, default software settings.

In the end, remaining truly anonymous is more up to the diligence of the users than the system’s core design.

More Privacy Considerations

Whatever your privacy requirements are, it is important to consider all the ways that privacy can be compromised in your application.

  • Do users sending transactions personally know each other?
  • Can computers track IP addresses through the network?
  • Is there any geographic context that can locate a particular user, such as network lag or spoken language?

These questions are not always obvious, but with careful consideration, the answers can dramatically impact your application’s architecture.

2. To what scale do you plan to grow your application?

Blockchains are databases that can potentially store any information from a traditional application. The fact that they are distributed, however, dramatically changes their capacity to scale.

As distributed systems grow, it becomes increasingly difficult to retrieve required information from all available nodes (i.e., computers). Finding and routing information between nodes takes time, which we call latency. It also takes effort, which we call computational overhead. Much of this routing must be done in proper sequence, so there is always a minimum latency associated with any network.

Network traffic can be thought of a lot like regular traffic.

Small towns don’t have many roads, but they also don't have many cars. Thus, the ratio of cars to roads is balanced.

With each doubling of town size, emergent factors, like traffic, increase by 15%. It’s plausible to imagine said traffic eventually reaching a breaking point, whereby any further city growth results in frequent, intolerable traffic jams.

Sometimes, cities can gracefully overcome these types of scaling problems, but more often, solutions require expensive rebuilds of major parts of the city’s infrastructure.

This is precisely what we are trying to avoid when posing this scaling question.

Generally speaking, increasing the number of nodes in your blockchain network will slow it down.

There are distributed ledger technologies (DLTs) out there that are not blockchains. Some of these other DLTs continue to operate at the same speed, or sometimes even faster, as their networks grow. These are usually based on directed acyclic graphs (DAGs), which can be thought of as a series of interdependent, interwoven, blockchains.

A DAG may be a good choice for your application if it doesn’t use a lot of complex queries or fine-grained permissions (ask your Object Computing representative about this experimental new field).

Number of Nodes

The size of a blockchain network is typically referred to by the quantity of nodes in the network.

A “node” could be any of thousands of boxes inside a big whirring data center. It could be a cell phone, a desktop computer, or even a simple Raspberry Pi board.

Whether all of these devices are compatible and economically advantageous to connect to a network is dependent upon the blockchain platform chosen.

The Bitcoin blockchain’s node client, for example, can be run on any computer with sufficient memory, but it’s economically irresponsible to do so on a small computer. This is because the Bitcoin consensus algorithm rewards nodes proportionately based on their contribution to relieving the computational overhead of the system. Small computers cannot contribute much to this effort and, consequently, it would cost more to supply the node with electricity than the Bitcoin earned in that same time from the network.

Calculating the number of nodes necessary to support your application’s projected user base is extremely difficult. Every popular blockchain platform has had its speeds and potential for scale benchmarked, but rarely do these numbers tell the whole story.

Blockchain ecosystems proudly pronounce their transactions per second (tps), but this number rarely translates to real life. The speed of a network compared with its quantity of nodes rarely includes a simultaneous comparison to how those nodes are being used and their relative distance. This paper illustrates how complex calculating maximum size and minimum latency can be.

Number of Clients

Number of nodes only tells us how many computers are members of the network, but this is not the upper limit for the number of users. Nodes can typically provide services for multiple clients.

Clients are the interfaces we use when interacting with web-based software on the internet. If a single node can concurrently provide service to a hundred nodes, it’s possible that a 200-node blockchain network could service up to 20,000 users simultaneously.

Assessing the number of clients serviceable by a node is also a complex calculation. This number is dependent upon a number of factors, including:

  • The DLT chosen
  • The consensus algorithm
  • The distance between nodes
  • The geographical distribution of the users
  • The complexity of the transactions
  • The speed of the internet access and computers involved

It’s safe to assume most applications will run dramatically faster in the developed world than they would in emerging economies.

More Scaling Considerations

As you delve deeper into the requirements for your application, it’s important to seriously consider the technological and geographical limitations associated with scaling.

Some other factors you will have to consider include:

  • How far apart are your nodes and clients?
  • How complex are your queries? More complex queries increase your costs, latency, and computational overhead.
  • What are your privacy requirements? Encryption is one of the most computationally taxing and slow processes that a distributed system will have to take on. Reducing the amount of encryption will often speed up a network, but reduce its privacy.

Small systems don’t always work when we try to grow them. In order to create a resilient, sustainable application architecture, questions about the speed and the scale of the application must be answered early.

Question #3

Coming Soon!

Question #4

Coming Soon!

Blockchain Solutions for the Enterprise

Collaborate with our team of experts to design and build the right blockchain solution for your business.

Strategy Development

Get answers to your questions about blockchain technology, determine whether blockchain offers a solution to your specific needs, and establish a plan for moving forward. 

Decentralized Application Engineering

Engage our team of highly specialized blockchain engineers to build enterprise-ready decentralized applications that achieve your unique business objectives. 

Proof of Concept Development

Leverage our technical expertise, industry knowledge, and partnerships across platforms to accelerate the development of blockchain-based technology prototypes.

Blockchain Training

Equip your team with the knowledge and skills to develop and maintain your blockchain applications through our customized training program led by our team of blockchain experts.