Flavijus Piliponis â stock.ado


4 distributed ledger technology risks and how to solve them

Ready to use distributed ledger technologies for smart contracts or other transactions? Know what risks to avoid and overcome to maximize these platforms for your organization.

As use of blockchain grows, so too does the adoption of distributed ledger technology in its many forms. Blockchain is the underlying storage mechanism for DLT, and with smart contracts a blockchain can execute behavior as well.

That combination of behavior with storage makes DLT a viable application platform. And as DLT matures, its inherent risks are being addressed.

Let's review what DLT is, how it works, and then discuss the risks that come with it as well as how to remedy them.

DLT 101

A distributed ledger, also known as a blockchain network, is a collection of independent computers and computer clusters networked together in a peer-to-peer manner to store identical copies of a particular blockchain. In blockchain parlance, the computers on the network are called nodes.

A blockchain is a data storage technology that stores blocks of data, typically one or many transactions, in an immutable manner. A common example is the transfer of cryptocurrency from one party to another, but one can execute many types of transactions on a blockchain network, including smart contracts.

Think of a blockchain as a giant spreadsheet that exists as identical copies among many computers, and a spreadsheet row as a block on the blockchain. Adding a row of data to the spreadsheet on one computer notifies all other computers on the blockchain network to add the row to their copy of the spreadsheet.

Once a row of data is added it can never be changed. The overall integrity of a blockchain depends upon the immutability of its data.

A piece of intelligence called a consensus algorithm ensures that a row of data is safe to add to the spreadsheet. Different blockchain networks use different consensus algorithms; for example, the Bitcoin blockchain network uses the proof of work consensus algorithm while the Ethereum blockchain network uses proof of stake.

Figure 1 illustrates the general process by which transactions are added to blocks which are then added to the blockchain.

The process for adding data to a blockchain network.
Figure 1. The general process by which transactions are added to blocks which are then added to the blockchain.

What is happening in the above illustration is as follows:

  1. Bob creates a transaction using either a client-side cryptographic wallet such as Metamask or a Web3 program.
  2. The transaction goes to a common mempool along with all the other transactions submitted by other users.
  3. An independent node on the blockchain pulls down a transaction from the mempool. The node's validator determines that the transaction is from the user and adds it to a block that gets submitted to the node.
  4. The block is submitted using the blockchain network's consensus algorithm. The node propagates the block to other nodes on the chain.

The key takeaway about distributed ledger technology and blockchain is that the network is not hierarchical. No single node is in charge; everything happens on a peer-to-peer basis. If one of the nodes on the network goes down, another node submits blocks to the blockchain network for propagation. Also, since all the data on each node's blockchain is identical, one can query any node to read data.

Another benefit is that data on public blockchains is auditable, which means anybody can trace transaction activity among parties. (Private blockchains are more the exception than the rule.) Transparency is a key selling point for distributed ledger technology, which makes it particularly compelling for activities that involve public records, such as real estate deeds and public stock exchanges.

DLT risks and remedies

Still, distributed ledger technology has risks, including performance, security and cost. Fortunately, many of them have been or are being remediated.


A risk common to all blockchain networks is the theft of a user's key pair. A user's identity is known only by the unique address on the blockchain. That address is created with a crypto wallet, which can be either hardware or software.

A user creates a public and private keypair using a wallet, which generates a 12-word seed phrase. That seed phrase is the de facto password for the user to access the blockchain. Should a malicious party steal the seed phrase, or the underlying keypair associated with the seed phrase, that thief can not only access the user's cryptocurrency funds but also impersonate the user on the blockchain.

The standard precaution to prevent the theft of a keypair or seed phrase from a software or hardware wallet is to keep the information in a very safe place, ideally in the owner's possession.

Some emerging technologies aim to replace the need to use a wallet to access a blockchain. The Ethereum blockchain's ERC-4337 specification, also referred to as account abstraction, does not require a seed phrase-generated private keypair to access an Ethereum blockchain. Instead, users create a recoverable username-password pair or log into the blockchain with social media credentials.

Another security risk, called a 51% attack, involves the fundamental architecture of a blockchain network. Some blockchain networks, such as those that use the proof of work consensus algorithm, add a block to the given blockchain when a majority of the nodes agree to do so. However, a malicious actor potentially could take over a majority of the nodes on the network and approve the addition of fraudulent blocks of data. This malicious majority could, for example, block impending transactions or execute double payments fraudulently from an unsuspecting account to one of their accounts.

For blockchains that have been operational for a while, a 51% majority is a low-probability occurrence. They have many legacy nodes to offset additional malicious nodes and thus thwart a network takeover. However, the risk is real for newer chains with a small number of nodes.

The remedy is for the user to beware that all blockchain networks are not created equal. Users should research thoroughly the blockchain network on which they intend to do business, and scrutinize those that have come online recently.

Transaction Speed

One of the issues facing blockchains of all types is slow transaction speeds. The blockchain network requires a lot of work to add a user's transaction into a block and then add that block onto each node's copy of the blockchain. That creates latency, which in turn bogs down transaction processing.

For example, some reports show the Bitcoin network operates at seven transactions per second (TPS), while Ethereum runs at 15 TPS. These speeds vary depending on network congestion how much in fees a user is willing to pay to process their transaction. Meanwhile, credit card companies process around 20,000 TPS, so those blockchain transaction speeds leave a lot to be desired.

Fortunately, several remedies such as the following can address this risk of long transaction times:

  • Use blockchain networks that have fast transaction processing algorithms or architectures designed to reduce transaction processing time. Two such examples are Solana and Hedera.
  • Use a blockchain network or blockchain applications that employ off-chain resources, often called Layer 2, to increase transaction speeds. Examples include Lightning Networks, Polygon zkEVM and Optimism.


In private information technology infrastructures, cloud-based or on-premises, the owner absorbs the cost of computing. On a blockchain, the party that submits transaction data pays the computing cost, which is called gas. The submitter pays the amount of gas consumed multiplied by the price of gas. Gas prices vary by blockchain and by demand on the given blockchain -- the more people who want to add data to the blockchain, the higher the price of gas versus at low usage times.

The cost of computing can be high, particularly when using smart contracts. Companies that use blockchain and DLT are always looking for ways to reduce the cost of computing. One way to address excessive gas fees is to separate mission-critical transactions that must operate even when network activity is high, and thus are more costly, from those that can wait until network traffic and costs are low.

Another tactic to reduce blockchain costs is to optimize a smart contract's structure before it is executed, because well-structured and optimized code is less costly to run. Different blockchain networks rely on different programming languages -- smart contracts intended for Ethereum-compatible blockchains are programmed in Solidity, while programs for the Solana blockchain are programmed in Rust or Python using the Seahorse framework. Each of these programming languages has its own optimization techniques.

Another option to lower blockchain costs is to use intermediary third parties, such as Skale, that offer low-gas or no-gas transactions.

There is also emerging support for the concept of a paymaster entity, as described in the Ethereum ERC-4337 specification. A paymaster pays gas fees on a user's behalf, much like some brokerage companies absorb the cost of buying and selling stock on a stock exchange on behalf of a client. The credit card company Visa is experimenting with providing paymaster services, while Pimlico and Candide also provide paymaster integration services.


At the block level, data is immutable. To make any changes, one must publish another transaction that references data in a previous block. Essentially, this is an exercise of change management.

One way to facilitate data updates is to store change-prone data in off-chain storage, such as a virtual folder on Amazon S3 storage. The URL to the Amazon S3 folder will be immutable, but the data within can be changed.

Things get a little trickier with smart contracts stored on a blockchain. Unless special measures are taken, upgrading code in a smart contract involves the release of an upgraded version of the new code at a new address on the blockchain. Then, impractically, all users and entities tied to the old smart contract must update to the newly released version.

Fortunately, some blockchains, such as those that are Ethereum-compatible, support upgradable smart contracts. The mechanics of that upgradability vary by blockchain platform. Use a blockchain network that supports upgradable smart contracts, or risk havoc on your software development life cycle.

Putting it all together

Adoption of distributed ledger and blockchain technologies continues to grow, for use in commerce and gaming and even as the foundation for general application development. At the same time, users must be aware of the requirements and risks to navigate these emerging technologies. Understanding how to use DLT and blockchain effectively and safely is important in any adoption initiative.

Bob Reselman is a software developer, system architect and writer. His expertise ranges from software development technologies to techniques and culture.

Dig Deeper on Software development best practices and processes

App Architecture
Software Quality
Cloud Computing