A blockchain calls the code it wants to run in the form of transactions (TX), bundles those transactions into a block, executes the block across many nodes (validators), and then reaches consensus on the result before storing it. Inside a block, transactions run one after another in a fixed order, updating the state data held on the chain. Because blocks themselves are linked into a chain, sequential execution of every transaction is all but unavoidable — and that sequential execution is the single biggest obstacle to making blockchains faster.
Running transactions sequentially is one way a blockchain guarantees that every node arrives at the same result. Change the order and you can change the outcome. That is also why choosing the node with the right to produce a block (the miner, or validator) matters so much. Making sure only one block can be produced or selected at a time is a core job of a consensus algorithm, and sequential transaction execution — one of the most fundamental roles in a blockchain — is not something you can casually rewrite.
So sequential execution is baked into what a blockchain is. But it is equally true that without getting past this limit, you cannot expect a dramatic jump in performance. Even chains built on PBFT (Practical Byzantine Fault Tolerance), an algorithm known for fast consensus, top out at roughly 2,000 TPS (transactions per second) in theory, with the exact figure depending on hardware and network conditions.
The answer to the performance problem is parallel execution
Sharding, DAG, and loopchain's Parallel Execution of Transactions
In any field, a sharp gain in throughput comes from parallelization. Adding buses and trains for the holiday travel rush, or spinning up more servers when a hot concert goes on sale, are everyday examples. The more things you can handle at once, the more volume you get through — and performance climbs quickly.
Blockchains can solve their performance problem the same way. So let's walk through two well-known approaches to parallel execution, sharding and DAG (directed acyclic graph), and then look at the Parallel Execution of Transactions technology PARAMETA developed in-house for loopchain.
[Parallel execution approach 1] Sharding
Ethereum plans to adopt sharding to improve transaction speed. Sharding means splitting data or a network into smaller pieces that are stored and managed in a distributed way. Applied to a blockchain, it divides work by transaction or by address so that each piece is recorded and executed on a different chain. The very fact that records land on separate chains is what makes parallel execution possible. Other blockchains implement much the same idea under names like multi-channel, multi-chain, or side chain.
With a multi-chain approach, state data ends up split across chains, which hurts compatibility between them. Data verification is only valid inside its own chain; step outside that chain and it is effectively off-chain, so interoperability becomes difficult. Ethereum assigns shard chain security and cross-chain communication to a beacon chain, but performance still falls short of what a single chain can do.
* Source: Ethereum Sharding, https://github.com/ethereum/sharding
[Parallel execution approach 2] DAG (directed acyclic graph)
The other well-known approach is DAG, adopted by projects such as the Avalanche blockchain. In a DAG, transactions are not strung together in a single sequence but connected partially, with the ordering pointing in one direction so that the before-and-after relationships between transactions stay unambiguous. Because several transactions can run independently from any given point, this too counts as parallel execution. DAG designs generally handle asset transfers well, but are known to have more trouble with smart contract execution.
* Source: Avalanche Blockchain Consensus
[Parallel execution approach 3] PARAMETA's own parallel execution technology — Parallel Execution of Transactions in loopchain
Rather than sharding or DAG, PARAMETA applies its own Parallel Execution of Transactions technology to loopchain, the blockchain core engine it built from scratch, and the gains in performance are dramatic. Let's look at how it works.
Parallel execution of transactions in loopchain
loopchain supports multi-channel out of the box. Depending on policy, it can be designed so that transactions and contracts are divided across channels, which in theory multiplies performance by the number of channels. Channels can still talk to each other through BTP (Blockchain Transmission Protocol), the interchain technology developed in-house, so they stay organically connected.
That said, communication over BTP is still chain-to-chain communication, so it carries overhead — and some smart contracts have to run on a single chain. Another approach is needed.
loopchain applies Parallel Execution of Transactions, which runs transactions in parallel whenever they can execute independently. Say a block contains TX1, TX2, and TX3. Ordinarily, blockchain nodes execute those transactions one by one, updating state data as they go. But if TX1 transfers from A to B while TX2 transfers from C to D, the two are independent and there is no reason to run them in sequence.
By applying processing technology that runs transactions in parallel whenever the accounts they touch are independent of one another, loopchain lets TX1 and TX2 execute at the same time, sharply cutting the time it takes to execute a block's worth of transactions. The more TXs that can go in parallel, the shorter the block's total execution time. This is not limited to simple asset transfers: smart contract calls can also run in parallel as long as the contract function a TX invokes can execute independently. (In loopchain, an isolated directive marks a function as independently executable.)
And because all of this happens inside a single chain and against a single set of state data, there is none of the overhead that cross-chain communication brings.
With Parallel Execution of Transactions in place, performance (TPS) rose sharply each time we raised the number of processes handling work in parallel — the concurrency level. On a blockchain without parallel processing, adding processes does nothing for throughput; on one with it, throughput climbed noticeably with every process added.
Getting past the performance ceiling of a blockchain requires parallel execution, and different chains are taking different routes to it. By combining multi-channel technology with its own Parallel Execution of Transactions in loopchain, PARAMETA has achieved a notable jump in performance.
Add to that a technique for rearranging the transactions collected during block production so that parallel execution pays off as much as possible, and we expect a substantial further gain in performance within a single chain.
[Reference] Go to the blog section on the official PARAMETA website ▼
Parallel Execution of Transactions in loopchain, for Faster Blockchains
A blockchain calls the code it wants to run in the form of transactions (TX), bundles those transactions into a block, executes the block across many nodes (validators), and then reaches consensus on the result before storing it. Inside a block, transactions run one after another in a fixed order, updating the state data held on the chain. Because blocks themselves are linked into a chain, sequential execution of every transaction is all but unavoidable — and that sequential execution is the biggest obstacle to making blockchains faster...
www.iconloop.com
We appreciate your interest.
Web3 Enabler, PARAMETA