The major components of blockchain include consensus, peer-to-peer networking, ledger storage, and computation (smart contracts). Participating nodes perform a computation on a shared set of data and reach consensus on the output. The group then records that output to the immutable ledger. This design allows the blockchain to work in trustless environments, but by nature the process is slow.
One of the most fundamental questions facing any blockchain-backed solution involves which pieces of business logic should be implemented directly on the blockchain, and which can be implemented off-chain. These questions largely boil down to a trade-off between the benefits of decentralization and the performance gained from executing code outside the blockchain.
It’s an important challenge. As a business lead you’re trying to decide how to shape a solution to do the work, interact with legacy systems, keep auditable records, and, increasingly important, meet data regulations around the world.
In this article, we’re going to go deep on on-chain logic, or where your smart contracts live, and discuss the levers an enterprise can pull to tune an application to work faster. We’re using smart contracts to guide the conversation but you’ll see a lot of the give and take could just as easily apply to on- and off-chain storage.
Business logic is the part of your program that processes rules about how data can be created, stored, and changed. In the web3 world, we often talk about how these rules can be represented in smart contracts on the blockchain—but in reality, most business processes will involve some combination of on-chain and off-chain logic. To illustrate this, let’s look at an asset purchase.
Assume we’re buying some shares of a particular asset with a fluctuating price. To compute the total for the purchase, our business logic needs to retrieve the current price of the asset, then multiply the price by the number of shares, then report the result.
If you were to build a blockchain-backed application around this simple bit of business logic, there are at least three different ways to approach it:
Even with this very simple bit of business logic, it’s clear that there’s a spectrum of options. The first leverages the blockchain ledger as an auditable proof of a calculation, while the last relies on sophisticated smart contracts and oracles in order to perform as much work as possible on the chain. Each option is equally valid, and each has significant pros and cons versus the others. Choosing the correct one for each business scenario will depend on a host of factors.
The spectrum becomes even wider as we look into more complex pieces of business logic. It becomes clear that all of this is a gray area – a matter of trade-offs and gains. Therefore, when applying blockchain technology to practical business problems, it’s important to understand the full spectrum of these trade-offs, and why you might choose one option over another for a particular use case.
By nature, blockchain is a push-pull between three tenets: scalability, security, and decentralization. As the “blockchain trilemma” illustrates, if we over index toward one of those tenets, we sacrifice another.
For example, if we put all our logic on-chain (decentralize to the max) we’ll kill our ability to scale. On the other hand, if we keep all our processes safe and private to increase security, we eliminate transparency and reduce decentralization. What we’re after is a balance, and one that may look slightly different for each use case.
Moving some processes off-chain is a way to gradually index away from decentralization in order to achieve more scale. After all, most enterprises don’t operate in a completely trustless environment. Many come to the table with some institutional trust and, thus, can orient their “triangle” more toward scale.
With this in mind, it can help to write some general opinions about where logic should live based on our use case. These are more guideposts than rules, of course, but will give us a starting point.
Business logic that requires trustlessness, transparency, and immutability is often implemented on-chain. This ensures that the rules and conditions of the system are transparent, tamper-proof, and verifiable by anyone. An example is a crypto exchange – on an exchange we want all the rules to be visible and let everyone see transactions. On an exchange, the smart contracts (self-executing agreements with terms of the agreement written into the code) are critical for facilitating trust between anonymous parties, so we want these contracts displayed and executed on-chain.
Business logic that does not require the same level of decentralization can be implemented off-chain. This might include logic that involves heavy computation, or that deals with sensitive data that should not be stored on the blockchain. It might also be computations that are simple and easily verifiable, represented on the chain only as an outcome. We’ll talk below in detail about reasons to move logic off-chain.
Business processes that are executed off-chain can still be connected to the blockchain in many different ways. When you break it down, every process has some amount of inputs, outputs, and rules. Each of these three elements can be recorded on the blockchain in various ways. Putting all of the logic into a smart contract is simply choosing a specific way to represent all three—that is, as source code.
Another option is to record the inputs and outputs in a blockchain transaction, with no record of the rules at all (useful when the rules are so universal and well understood that anyone could easily check the work). Yet another option could include writing the rules themselves into the blockchain transaction, or storing them in IPFS (whether as a text document, a structured DSL, or any other verifiable representation) and referencing them from there. Still other options may involve performing complicated processes off-chain, but having a smart contract that performs a simpler verification check on the output, to give assurance that the computation was performed correctly. All of these options leverage some amount of trust in the off-chain process, but allow it to be balanced with the extra verifiability of a shared and immutable blockchain ledger.
Put another way, a common approach is to use the blockchain as the source of truth for key data, and to use off-chain systems to perform more complex or resource-intensive operations based on that data. For example, a decentralized application (dApp) might use the blockchain to track the ownership of digital assets and to enforce rules around the transfer of those assets. However, the actual transfer of the assets could be performed off-chain, allowing for faster and cheaper transactions. Should an off-chain process fail to be performed correctly, any party can point to the blockchain ledger as the source of truth for what should have been done.
So although business logic that is kept off-chain is not physically executed on the blockchain, it can still be connected to the blockchain through many mechanisms that allow it to leverage the advantages of the blockchain. At the risk of blundering an analogy, we can use the blockchain to display our outputs without also using it as our calculator, GPS, or spreadsheet along the way.
Business logic can live off-chain in cases where only the result needs to be proven, and the connected system can be trusted to properly handle the inputs and rules without doing the actual computation on-chain. There are several use cases that illustrate where this may work.
Privacy-sensitive applications: In applications where privacy is a concern, such as medical records or financial transactions, it may be required to keep the business logic off-chain. This allows for the processing of sensitive data without exposing it to the public, and for maintaining the privacy of the information even if the blockchain is compromised.
Interoperability: In applications that require interoperability with legacy systems, it may be more practical to keep the business logic off-chain. This allows for the integration of the blockchain system with existing systems and processes without seeking to re-implement them all in a new way. This can enable much quicker adoption and a more seamless user experience.
In general, applications are good candidates for off-chain logic if they require complex transactions, need to talk to multiple systems, or involve private data that a node doesn't want to share to every other node. Especially in an enterprise setting where the involved parties are known good actors, we have more opportunities to move logic off the chain, and can provide alternative methods of recourse in the event that a process is applied incorrectly or challenged.
There are use cases where all business logic should be kept on-chain. In general, these are applications that require a tamper-proof and transparent record of all transactions, where the parties involved have little outside knowledge of one another, and where the security of the system is of utmost importance.
Decentralized exchanges (DEXs): In a decentralized exchange, all business logic, including the matching of orders and the settlement of trades, should be kept on-chain. This is because the exchange operates without intermediaries and requires a tamper-proof and transparent record of all transactions.
Identity management: In an identity management application, all business logic for verifying and managing identities should be kept on-chain. This ensures that the identity information is secure and tamper-proof, and that the system is transparent and auditable.
When our goal is to ensure results are tamper-proof and transparent, and that the system is fair and auditable, we want to keep as much logic on-chain as possible.
Confidence in the data on the blockchain depends on several factors, including the design of the system, the security measures in place, and the trustworthiness of the actors involved. In the context of what lives on-chain and what stays off-chain, trust comes down to what you want to prove and who you need to prove it to.
If we capture the inputs, outputs, and the rules that were used, in most cases, we don’t need to do the actual work on-chain, as we all have the information needed to audit transactions later. We know what the outputs should be.
Now, if the data on the blockchain is being updated by an off-chain source, such as an oracle or legacy backend system, it's important to ensure that source is secure, reliable, and tamper-proof. This can be accomplished through various measures, such as using multiple independent oracles to provide the same data, implementing smart contract logic to validate the data before it is added to the blockchain, or adding additional off-chain checks for involved parties to verify and confirm the data after it is added to the blockchain.
In the public chain world, the most important thing is that everyone sees the code and knows how it runs and is comfortable with the steps being taken. These systems generally trade transaction volume for greater transparency and decentralization.
Enterprise applications are different. If we’re not trying to prove the validity of the code, we don’t gain much by showing everyone the code that we’re running. For enterprise applications, often our goal is simply to display rules and state how they were enforced, without actually having to certify the exact code that was used to enforce them. This means we can still build an audit trail without placing the computation on-chain.
Depending on the nature of the use case, various steps can be taken to ensure consistent application of the business rules. The rules may be expressed in a standard DSL (domain specific language) of some kind, which can be parsed and executed against a set of inputs. Or the source code itself may be examined and hashed to provide a cryptographic proof of the code that was used. The code may also be built into a virtualized environment or container, which can be shared across nodes or published to a container registry. In all cases, by including some pointer to the logic that was used, any set of results should be immediately reproducible by providing the same set of inputs to a given snapshot of the rules.
Ultimately, we want to establish a clear and agreed-upon set of rules and procedures, then verify consistent application of those rules to each set of inputs.
The main bottlenecks for scalability are the processing power of the nodes, the bandwidth for transmitting data, and the convergence of the consensus algorithm on the blockchain network. It’s hard to scale an application if we’re running all business logic on-chain, as blockchains are fundamentally designed for slow, reliable, decentralized ordering of data. We find more room to grow as we start to move computations and storage off the chain.
It’s worth noting that many blockchain-focused technologies can also be leveraged to increase scalability and throughput in some regards without moving entirely off-chain, including upgradeable contracts, roll-ups, L2s, and sharding solutions. However, in reality each of these options comes with its own trade-offs, by nudging the triangle slightly away from security or decentralization, or by increasing the overall complexity of the solution.
In terms of performance, the answer is complex. Various online studies can be found to estimate throughput for common public and private chain scenarios, and we can look at performance numbers for similar applications running in production on our platform.
However, the only way to truly quantify performance is to measure it. As use cases vary so dramatically in the amount and type of data being processed, there’s no single formula to give us a percentage of transactions gained each time a process is moved off-chain.
Smart contracts are excellent at intermediation. They are a stand-in where previously a third party was needed to check conditions and enforce rules. They matter when the “how” of a transaction is really important, or when we want to show exactly why a particular outcome was reached. For example: if one plus one is always two, and the users of an application all agree that one plus one is two, and those users have enough trust in a particular off-chain system to think it can reliably add one plus one, and they have a way to see the proof that it added one plus one and arrived at two… then sharing the source code for performing the math itself is likely not providing a significant added value. It does provide increased transparency, but at a cost to scalability and maintenance that may not be acceptable for every use case.
If any of those pre-conditions are not met—if the users do not trust the system, for instance—then there is value to be gained from executing that logic on chain, allowing the user to trust the logic even if they do not trust the entity behind it.
Think of the current shift in many industries to remote work. In certain ways it may be desirable to have everyone in the office, but for some jobs it doesn’t make sense to sit in traffic, burn gas, and lose time when the work gets done just as well off-site. If we don’t need a role in the office, directing processes, onboarding team members, adapting, making calls, we can let them get their work done remotely and report on outputs. We may need the deskspace for a more dynamic role in the future.
Similarly, representing detailed logic in smart contracts becomes less important when the inputs and rules are known to all, and when the actors involved can be trusted to behave in a predictable way. If we can represent inputs and rules in a clear, consistent way, allow nodes to do complex computation off-chain, and provide processes for recording and verifying the results using a blockchain ledger, we can gain immensely on performance and scalability without diminishing the impact of the blockchain on the solution overall.
This is a topic with a lot of gray area. These resources from around the web help add more color to the discussion.
Evolution of Blockchain Components to Off-Chain Models
What Is Off-Chain Data and Computation?
Performance and Scalability of Private Ethereum Blockchains
Scaling Blockchains with Off-chain Data
On-Chain Versus Off-Chain: The Perpetual Blockchain Governance Debate
Our team is standing by to answer your questions—and help you get your application live.
Schedule TimeOur team is standing by to answer your questions—and help you get your application live.
Schedule Time
Our team is standing by to answer your questions—and help you get your application live.
Schedule TimeOur team is standing by to answer your questions—and help you get your application live.
Schedule Time
Your guide to everything from asset tokenization to zero knowledge proofs
Download Now
Learn how Swift, the world’s leading provider of secure financial messaging services, utilizes Kaleido in its CBDC Sandbox project.
Download Now
