Comparison of Blockchain Technologies (DLTs) for Enterprise Applications
By Sebastian Richter on The Capital
When aiming for the implementation of a commercial business idea/application that is underpinned by a Distributed Ledger Technology (DLT), there are several to choose from. But first, the question whether a DLT is needed and necessary will be addressed.
First, the following are the basic preconditions for the use of DLTs: Actors for an exchange of something of value, a potential relationship (transactions), potential damage through fraud or abuse, and reasons why actors should make transactions with each other. Does your use case fulfill these preconditions? If not, a traditional database might be a better solution to your problem.
When deciding between a conventional database and DLT, you can relate to decision models proposed by Sebastien Meunier, for example. However, some of these models cannot be used for discussion at decision maker level because they have an architectural focus, evaluate only in terms of openness and access or evaluate in a specific context. It is far more important to analyze the problem area that the use case in focus addresses. There are studies that identify the most common problems that are addressed by Blockchain, such as this one. Some of these problems are the following:
- The balance between control and trust
- Lack of evidence in transactions
- Time-consuming interactions / time losses.
Especially, time-consuming interactions and time losses play an important role, as companies do not have to conduct complex workshops and draft contracts, but instead only have to sign up on the common Blockchain-based application and enter into business with other companies. Smart contracts (representing contracts between these companies) monitor SLAs that are agreed on. Furthermore, the DLT-based approach promises a solution to the lack of evidence problem by making the exchange (or the rights of use) of assets and contract formation auditable. Using a DLT also addresses the problem of having a single point of failure (centralization), decentralizes power by giving it to the ecosystem, avoids any intermediary, avoids any abuse of power by governments, supports demand-based dynamic pricing and most importantly enables a true ecosystem that is open to any institutional user of the business platform no matter what industry.
Now it is your turn to decide whether your use case is addressed by these problems or if a traditional database fulfills your requirements as well. Assuming that a DLT is still a consideration, let’s look at four different types:
Hedera Hashgraph
Hashgraph describes itself as an extremely fast (Transactions per Second (TPS)) and public DLT. The consensus is democratically reached across all nodes using a voting procedure (“permission-less”). The special feature lies in the “permissioned” governance model: 39 parties vote in different committees about the rules, the programming and the native cryptocurrency (hbar). “Swirlds” manages the Hashgrpah license (it is not open-source), but developers can develop distributed applications on Hedera Hashgraph with their own token and license model. Hedera Hashgraph provides four main features: Smart contracts, a file system, consensus service, and cryptocurrency that developers can use to build decentralized applications (DApps). Currently, it is worth observing the ecosystem since their DApp marketplace recently launched. Building a commercial business application may experience several technology-related changes due to Hedera Hashgraph’s infancy. But in general, building a DApp is a legitimate way to realize your business application using the Hedera ecosystem for extended functionality (a stable coin is on the list of available DApps as well).
IOTA Tangle DAG
The IOTA Tangle DAG DLT is a public system (“permission-less”), with potentially thousands of TPS: the more participants the better it scales. Since the network is still somewhat small, they use a central coordinator to select approving nodes for new transactions.
IOTA addresses several challenges that come to the typical blockchain, such as transactions: IOTA allows for micropayments and supports thousands of TPS, whereas the Bitcoin blockchain currently supports around 7 TPS. Additionally, there is no mining in IOTA (some Proof of Work for spam protection is still required), everyone pays for their transaction with their own energy and by validating two other transactions. Also, since there is no mining in IOTA the energy consumption is at a fraction compared to the Bitcoin network, which consumes more energy than Switzerland. IOTA is invulnerable to 51% attacks and quantum attacks by using a one-time signature scheme.
IOTA has interesting partnerships with Bosch, trive.me and Jaguar-LandRover. Bosch, for example, provides a programmable sensor, development kit, prototyping platform including a secure data exchange interface for the IOTA marketplace.
Permissioned & Consortium-based DLTs
There are open-source frameworks on the market such as Hyperledger or Enterprise Ethereum Alliance (EEA), which provide companies with the opportunity to quickly implement blockchain projects (private and permissioned, see Hyperledger Fabric or Sawtooth. For companies these types of DLT offers some advantages: The possibility for private transactions, exchangeable consensus mechanisms, own user administration and further functions for regulated industries. The goal of the EEA, for example, is to create an industry standard to accelerate interoperability and adoption of Enterprise Ethereum. So the focus here is primarily on regulated industries with special security and data protection requirements and to ensure integration with existing processes and systems. EEA published several use cases in white papers, related to the Telecom market.
The downside of this approach is that the frameworks and projects are mostly research and development initiatives and lack proven real-world implementations. They lack an existing worldwide infrastructure and interoperability between systems on the same Blockchain (compared to public Ethereum, for instance). However, the potential to adapt a permissioned enterprise-grade DLT for a decentral marketplace is high due to the possibilities tailored for businesses, rather than for end consumers. Since there is no proprietary cryptocurrency associated with these frameworks, either a token-based payment mechanism or other fiat currencies can be integrated.
Another issue with private DLTs is that they tend to be centralized. Such scenarios make sense for company internal DLTs or for special purposes for internal auditing and known identities. For a design choice, it must be clarified whether participants prefer a consortium over a public DLT because the insight to the very few transactions in the consortium can lead to unwanted competitive advantages (think of Blockexplorer).
Public Blockchains such as Ethereum
Ethereum is a well-established and proven ecosystem of developers, users, and projects. It has several advantages over Bitcoin, such as transaction cost (gas), which is required for every operation performed on the blockchain. Additionally, Ethereum provides the capability of smart contracts, which may be a key requirement for certain business applications. If there are requirements around cryptocurrency volatility, there are some ERC-20 coins to be aware of such as DAI or USD Coin. These can be integrated into an Ethereum-based application to avoid any currency fluctuations. This is important to consider because there are regulatory implications that are relevant when building a Blockchain-based business application. Germany, for example, has published a blockchain strategy paper which presents concrete legislative plans that no stable coin should become a state currency, but that dialogue on the European central bank should be promoted. This regulatory hurdle speaks against a private stable coin (such as Libra). From a technological perspective, a way needs to be found to use an ERC-20 token to either take on this risk and agree a fixed exchange rate. Or the native ERC-20 token interacts with other stable coins (USDC, DAI or others). Looking at IOTA, the parking provider trive.me has apparently found a way to integrate the IOTA Tangle technology without any cryptocurrency fluctuations. The solution allows the end-users to pay with real money instead of the native IOTA currency. On Ethereum, this might be easier to achieve with ERC-20 stable coins, because the conversion is technically easy to integrate due to the Ethereum’s ecosystem standards.
Since the TPS on Ethereum are at around 15, the question around performance arises. In the future, Ethereum will support hundreds more TPS, but they have not yet released an update to their Blockchain to support this. Until then, a way needs to be found to overcome this issue: Something similar to Bitcoin’s lightning network is described in the white paper of Crossbar.io. They use state channels that sum up the transactions between two parties; once a transaction-based interaction terminates, the total sum of the transaction will be stored on the Blockchain.
To evaluate which Blockchain ecosystem is the most appropriate, it is necessary to list your own requirements of the solution you are trying to build. Some of these include performance, number of transactions, volatility of cryptocurrency, data security, operations and the integration to off-chain applications. The latter is probably the most difficult to integrate and can be an entry door for cyber attacks since the data (especially if the workload is large) is not hashed and stored on the Blockchain.
The industry (especially Hashgraph and IOTA) is in a very early stage with new projects, announcements and use cases announced every month. Furthermore and across all four cases, real use cases that are in production are seldom as of today. This shows the current fragmentation and hype, which is slowly gaining maturity. This evaluation as seen above will need to be revised in the coming years to capture the market changes. But instead of waiting for the market to mature, there might be market opportunities for you requiring you to pick a technology provider who has proven success in the past years of DLT existence to implement the DLT-based solution, especially the off-chain components (There are a couple such as Streamr or Crossbar.io).
I hope the above described approach helps to verify whether you actually need a blockchain and if yes, what type of DLTs can be considered. Please note that the list of DLTs is by far not complete. There are others that might fit to your specific needs better like The Ocean Protocol, Holochain, LTO Network, Monet, EOS, Ripple, etc …
