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.

Anonymity

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.

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.

4. What are your application's accessibility requirements?

All software is about supporting the goals of people. Sooner or later, your blockchain project will need to be accessible to users. Consider what kinds of capabilities user’s should have. These could be the kinds of tokens they exchange, the ease with which they launch smart contracts, or the levers by which they contribute to the governance of a decentralized system.

User Interfaces

User interfaces for the DLT space come in the form of web apps, mobile apps, and desktop nodes. End users should be protected by avoiding storing data unencrypted. Private keys and seeds should be disseminated only under very certain circumstances. This means isolating your project's front- and back-end functionality as much as possible, as well as requiring user input validation on all forms, and calls to the back-end.

Web APIs

Web APIs are programming-language specific web-based beacons for accessing the functionalities of your blockchain project. These API’s expose a predefined set of actions that can be triggered by others accessing over the internet. All major blockchain and distributed ledger platforms provide web APIs via the same nodes that host the ledger itself. Javascript, Java, Python, and Go are among the most popular languages for web APIs in the blockchain space.

Generalizable

For your blockchain project to be highly useable, it’s important that it's as “generalizable” as possible. The platform chosen will determine what kind of hardware is necessary to use the system, or if a given user will be at an advantage due to his of her hashing capabilities.

Generalizable systems don’t require highly specific hardware, nor do they require lengthy amounts of training and education to become useful.

Data Storage

Some blockchain platforms allow complex data and functionality to be stored on chain, but more often than not, it's best to store complex, non-blockchain data offchain. This could mean a server in the context of hosting application-level data, such as graphics, that coincide with a user’s financial transactions stored on the blockchain. 

Decentralized storage using distributed systems like Internet Protocol File Storage (IPFS) allows developers to supply internet addresses as references to externally stored databases. This protects end users from malicious administration like hackers.  

Geographic Availability 

Consider how the latency of your application and tokenomics may depend on your users' internet speeds and geographic locations. Make sure you create data redundancy in a geographically distributed fashion. This can be decentralized, like a meshnet, or simply well-placed servers running in the cloud.