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.
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.
3. How do digital assets fit into your strategy?
This is where we get into a discussion of tokenomics and cryptocurrencies, two concepts that naturally go hand-in-hand with blockchain technology, but possibly not in the exact ways you imagine.
It’s common for people in the industry to conflate “blockchains” and “cryptocurrencies.”
Cryptocurrencies are protocols running on top of complex distributed databases that allow us to establish finite supply in a digital space; in other words, they cannot be copied and pasted and therefore can retain value.
Historically, most cryptocurrencies have been built on top of blockchains or other distributed ledger architectures, like DAGs.
These definitions get especially blurry for the casual user because some blockchains are dedicated exclusively to maintaining a cryptocurrency and nothing else, while cryptocurrencies like Ether can serve both as a store of value and as a sort of “cryptographic fuel” that allows users to purchase computing capacity spread throughout the Ethereum network. In other words, the value of Ether is both a product of perception, like the U.S. dollar or the euro, and a product of its intrinsic functionality, like oil.
This pricing model is even more precise and complex in an ecosystems like EOSIO, which dynamically evaluates both available computing power and available memory space.
Ethereum can also price memory for usage, but it’s typically abstracted through a token like storj. Other platforms like Sia exclusively use memory.
Tokenomics & Consensus Algorithms
Earlier, we discussed consensus protocols, like proof-of-work and proof-of-stake. These protocols describe the rules and reward mechanisms that incentivize people to use a trustless distributed network.
Distributed ledgers are referred to as trustless because the burden of establishing the trustworthiness of a counterparty in a transaction is abstracted away from use using complex mathematics.
In reality, though, trust is still invested; it's just in a technological system rather than in a human being.
The implication, then, is that distributed systems must be designed to provide enough benefit to their users, while maintaining a relatively fair and untampered track record, until it’s worth the risk to the user.
With proof-of-work, the collective confidence that no party could outwit the mathematical search for a prime number on a classical computer is so high, there is virtually no need for trust at all and virtually no risk to the miners.
Proof-of-stake consensus requires users to risk money in order to participate. This risked ante disincentivizes miners from tampering with or otherwise devaluing the system. As a reward for their risk, they earn a slow trickle of interest from the system. In proof-of-stake systems, this is typically where all of the cryptocurrency originates.
All of this is becoming increasingly varied and complex as new consensus protocols are still being developed.
Monetary policy when managing an economy or a reward system is a function of how much supply and demand there is for a currency.
If we broaden the scope of this idea to not just be about currency, but instead about any quantitative or context-specific resource, it becomes increasingly clear how complex these systems and their corresponding economic systems have, and will, become.
Example: Imagine if the Federal Reserve were seeking to lower interest rates, and it did so by opening up a data center and introducing new computing capacity to the system. Imagine if a currency were issued that had a progressive sales tax built into its functionality, such that no party could ever accumulate more than a certain amount.
What distributed ledgers will do for economics as a whole is extremely difficult to know at this point in time. There are, however, a few questions business leaders can ask themselves now in order to build the most intuitive and resilient systems possible.
3 Questions to Ask Today
1. Do you intend for your platform to be on a private chain?
Most private chains, including those built on private forks of public ecosystems or private ecosystems like hyperledger, rarely require tokens or cryptocurrency. If your business is pursuing this strategy, you should seriously consider whether tokens or coins are even necessary.
2. Does your platform have fees?
If you are using one of the public chains, like EOSIO or Ethereum, you will notice every transaction costs cryptocurrency or something similar. The pricing models on systems like Ethereum are mostly static, whereas ones like EOSIO are far more dynamic and dependent upon the state of the community.
Even if you build a system with a centralized gateway and microservices, like many clients, if you're porting to any sort of public chain, your business is subject to the tolls necessary to pay for those computations. These costs should be approximated and factored into both costs and design decisions going forward.
3. Do you expect your platform to become interoperable with other chains?
As the time, monetary, and computational costs of transferring tokens and coins between ecosystems decreases, we are likely to see a rapid devaluation of context-specific utility tokens.
Example: If an American in Europe were able to immediately convert his or her dollars into euros at point of sale at no cost, why would he or she ever bother to convert currencies ahead of time? The value of the euro is dependent upon its supply being sufficiently low. If there were no reason to hold it, because a person could always convert later, then the value of the euro would decrease, and demand would concentrate around the most liquid currencies out there.
You should factor in the degree to which you believe conversion costs will be reduced into their expectations around their economics.
For Further Thought
Tokenomics is enormously complex and is still developing. Game theoretic proofs will ultimately be available in the most effective of systems as we slowly crawl around in the dark of economic theory, hoping cryptocurrency will help us resolve some of the greatest woes surrounding fairness, fidelity, and equitability.
Right now business leaders need to focus on whether tokens are really necessary for their projects and how they expect their businesses to fit into a dramatically different economy.
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.
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.
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.