The Current Blockchain Landscape: What You Need to Know

By Jaycen Horton, CTO, KryptoPal

Although blockchain and distributed ledger technologies brought the world ground breaking advances, such as triple-entry accounting and trustless computing, they also imposed new scaling limitations and increased overhead costs. To effectively use blockchain for transactions, it’s important to note the current climate for this technology.

Limitations of Mobile and IoT Devices

Blockchain technology has significant overhead in terms of both bandwidth and storage capacity. This particular quality currently excludes the easy interoperability of blockchains and mobile or IoT devices, both of which have limited capacity. Due to this, it is highly unlikely that we will begin to see widespread adoption of many different cryptocurrencies in a variety of applications and devices, unless a seamless and effective solution reduces capacity and bandwidth-based overhead.

Transaction Overhead

Currently, to transact in a cryptocurrency (such as Ethereum), there are a few different ways a user can perform a transaction: by using a full client, a light client, or by broadcasting a transaction.

· Full Client: A full client, or full node, is a device connected to a blockchain that contains all of the transaction history and state of the blockchain since the genesis block. The overhead here is the storage capacity requirements. While one might maintain a full Ethereum node at a size of 12 GB or more, the problem here is that each application must require the consumer to have access to this large storage capacity for each blockchain it wants to allow its consumer to transact on, as well as the ability to scale in parallel with the blockchain’s size. In reality, this is likely not feasible, and in most cases, the additional security that this provides users is less than what is needed for smaller day-to-day transactions.

· Light Client: Although full security is only truly possible in a full node that maintains the entire state history of the blockchain, a light client allows minimal overhead for a reasonable amount of security (with around 1KB of data bandwidth required per second). In a light client (or “partially light client”), a node is required to download the latest block headers as a minimum requirement for basic functionalities relating to the blockchain. In this case, the client is still required to be able to stay in sync with the latest blockchain state. This means that even in the lightest client implementation, there is still some amount of bandwidth or storage capacity required to interact with each individual blockchain.

· Broadcasting: Due to the advent of cryptographic technology, such as Elliptic Curve Digital Signature Algorithm (“ECDSA”), clients now have the ability to implement the most minimal overhead possible required for transacting on the blockchain. In this case, an application provider generally only needs to implement this basic functionality so that it can sign a transaction. The transaction is then handed to any trusted, or untrusted, party without the risk of revealing any information about their private key. The limitation here is not in storage or bandwidth capacity, but in having an all-encompassing platform that manages these unique functional requirements.

Independent Fee Variables

An additional side effect of transacting directly on-chain is that there is a transaction fee associated with all transactions, and this fee is governed by the blockchain’s governing protocol. This creates a predicament for users transacting with an underlying token that exists within a blockchain’s ledger; even when a user wants to send tokens, they must also consume the blockchain’s native currency (Ether in the case of Ethereum). However, the variation of value of the currency is a completely independent variable to the token the user wishes to transact with. This means that every time a user sends a token, they are charged a fee that has value independent of the transaction that they are making.

Different Blockchain, Different Overhead

The overhead mentioned in each previous section only covers the overhead of a single blockchain. To enable cryptocurrency transactions on multiple blockchains, additional — and unique — overhead is required for each separate currency implementation.

Latency and Confirmation Time Restrictions

On-chain transactions are subject to confirmation times the underlying blockchain churns out. This consensus mechanism is used for verifying a blockchain’s inherent cryptocurrency transactions. Although this mechanism is necessary to provide full security against double spend attacks, it sometimes operates independent of an underlying token’s functionality. This means that people transacting in either a blockchain’s native cryptocurrency (such as Ether) or a derived token (such as KPX) are subject to a timeframe in which the rest of the blockchain must come to consensus and affirm a transaction as valid.

While Bitcoin brought us ten-minute block times, and Ethereum brought us sub-minute block times, the speed of transactions is computationally limited by the scaling implementations of each individual blockchain. For instance, the Ethereum blockchain can only handle approximately 5–25 transactions per second. Although there are a number of proposals to help create off-chain transactions that inherit bearable cryptographic security for micro-transactions between parties, there are currently no market-ready solutions.

Interconnectivity of Applications

Before the advent of distributed ledger technologies and blockchain, transaction ledgers and computational connectivity functions were restricted to single centralities and their ability to interconnect with other providers. These centralities must effectively define the rulesets for connectivity within their application or service, as well as between itself and other applications and services.

Although this has obvious implications as relates to corruption, trust and third parties, an indirect implication is that implementing transaction-based functionalities within or between applications requires each provider to engage with third parties (such as other application or service providers) to allow access, both from and to, third party applications or services.