Parallel Power Unlocked
A look into parallel execution
Current blockchains have challenges
Today’s major blockchains offer a range of applications, including DeFi, NFTs, social media, and even gaming. However, the quality and capability of these applications are limited by a fundamental challenge: blockchains struggle to process transactions concurrently. In decentralized applications, parallel execution is vital because it allows smart contract platforms to process multiple transactions simultaneously, increasing the overall throughput and responsiveness of the network. To address this crucial obstacle, the last five years of development in the industry have largely been dedicated to improving blockchain performance through parallelization.
In previous reports, we delved into various methods for enhancing scalability, showcasing modular design, innovative architectures like DAGs, and case studies such as Aptos and Sui. However, a commonly overlooked aspect in the blockchain domain is how networks address parallel execution and how these methods can be compared.
This research report aims to shed light on upcoming layer 1 blockchains that will help solve issues with current blockchains and to establish a classification framework for parallel execution in the future. We will focus on how these solutions enable parallel execution and compare their approaches to overcoming the limitations of existing blockchain networks. By examining the various strategies and techniques employed by these next-generation blockchains, we hope to provide valuable insights into the future of parallel execution and its role in driving blockchain innovation.
The EVM Paradigm
Most current smart contract platforms rely on the Ethereum Virtual Machine (EVM), which suffers from a major drawback: its inability to execute transactions concurrently. This limitation has prompted the development of a new wave of layer 1 solutions emphasizing parallel execution as a means of enhancing scalability and efficiency.
Smart contract blockchains have two main components: the consensus mechanism, which helps nodes agree on transaction ordering and inclusion, and the virtual machine, which runs application code and updates application states and account balances. Ethereum introduced programmable smart contracts through the EVM, a shared system where each node keeps a copy of all applications and their states. Despite its popularity, blockchains using the EVM face limitations in processing speed. For example, Ethereum can process about 10 transactions per second (tps), while the fastest EVM chain, Binance Chain, reaches just over 200 tps. This inefficiency is due to the EVM’s sequential processing model, where transactions are processed one after another.
Monad, a scalability-focused layer 1, put this in perspective in a recent article, “For reference: a simple card game with 10,000 users making a move every 10 seconds would need to have 1000 tps.”. As it exists today, it is unlikely that the EVM will be capable of supporting this many transactions within a single chain.
In response to this challenge, developers are exploring solutions that enable parallel execution. This report aims to create a framework to classify how these blockchains achieve parallelization, focusing on parallel execution enhancements. By implementing such strategies, the smart contract ecosystem can overcome the limitations of sequential processing and pave the way for more widespread adoption of decentralized applications.
What exactly is parallel execution?
In blockchains, parallel execution can be understood through a simple analogy. Picture a grocery store that needs to collect customer payments for their purchases. If the store had only one checkout lane and register, the line would move slowly, frustrating customers and potentially driving them to shop elsewhere. The store employs multiple checkout lanes and registers to speed up the process. This is parallel processing in action, allowing the store to handle several customers simultaneously rather than one at a time.
Applying this analogy to blockchains, the multiple checkout lanes represent different paths or channels for processing transactions. In parallel execution, these channels exist within a single system, enabling it to process multiple transactions at the same time. This setup allows a single blockchain system to handle a higher volume of transactions more efficiently, leading to better overall performance.
Now that we’ve grasped the importance of parallel execution for blockchain efficiency and scalability let’s delve deeper into its mechanics.
How does parallel execution work?
Parallel execution in blockchains means processing unrelated transactions at the same time. Think of unrelated transactions as events that don’t impact one another. For instance, if two people trade tokens on separate trading platforms, their transactions can be processed simultaneously. However, if they trade on the same platform, the transactions likely need to be executed in a specific sequence.
The main challenge in implementing parallel execution is determining which transactions are unrelated, or independent. This involves understanding how each transaction affects the blockchain’s data. With many interconnected applications, determining which transactions depend on each other can be tricky.
Various blockchain systems use different methods to identify unrelated transactions, typically by managing access to the blockchain’s data. Each account or smart contract has its own designated range of data that it can change. Independent transactions don’t try to change the same data in the same block, whereas related transactions do.
Some transactions are easier to identify as unrelated than others. For example, a simple token transfer between two people doesn’t affect anyone else, so it’s clear that these types of transactions are almost always independent. However, transactions involving the same smart contract or account can change its data and can’t be executed in parallel. An example would be a token trade that involves multiple platforms, where all participating platforms must wait for the initial transaction’s completion before processing other transactions.
In the following sections, we will delve into three distinct methods of achieving parallel execution in blockchain systems: state access/optimistic, sharding, and computation-based parallel execution. It’s worth noting that traditionally, only the state access and optimistic models have been considered as true parallel execution methods by others in the blockchain industry, as they enable a single blockchain to process transactions simultaneously. However, with the advent of sophisticated cross-chain communication protocols, the notion of what constitutes parallel execution has expanded significantly. Sharding, for instance, while not traditionally viewed as a method of parallel execution, indeed facilitates parallel processing of transactions across multiple shards, thus warranting consideration. Lastly, we will explore the relatively new concept of computation-based parallel execution. This innovative model, although not widely known yet, represents a revolutionary approach to parallel transaction processing in blockchain systems, and we will cover it in detail later in this paper. As we explore these methods, we will uncover how each one offers unique advantages and presents distinct challenges, paving the way for a more efficient and scalable future for blockchain technology.
Parallel Execution: State Access and Optimistic Models
Currently, most blockchains that feature parallel execution rely on two popular methodologies: the state access method and the optimistic model. The state access method is a strategic approach that preemptively identifies which transactions have access to which part of the blockchain’s state, thus allowing the blockchain to declare which are independent easily. On the other hand, the optimistic model operates under the assumption that all transactions are independent, only to retrospectively verify this assumption and make adjustments where necessary. Several blockchains utilize these methods to facilitate parallelization, showcasing each of these theoretical approaches in action. When people discuss parallel blockchains, these are typically the models they’re referring to. This section will explain these two methodologies and their applications in the blockchain landscape.
Solana: The Pioneer of Parallel Blockchains
Solana has distinguished itself as a forerunner in the blockchain landscape, pioneering a unique method to manage transactions and amplify scalability. Its groundbreaking innovation is determining which portions of the blockchain state — the comprehensive record of all accounts or assets — can be accessed by a specific operation.
Picture it as an expansive filing system. Each transaction submits a request to access a particular file. If the file requests are unique, the transactions can be processed independently. But if they request the same file, these transactions become intertwined and require coordination. The real trick is pinpointing which transaction is requesting which file.
Solana, as the first-ever parallel blockchain, introduced a solution. Each transaction must upfront declare which file it intends to access. This requirement is included in Solana’s ‘Sea Level’ execution model, where everything functions within an account-based framework. Each account can only be accessed by a transaction that’s linked to it, thereby preventing potential conflicts.
Crucially, Solana also uses stateless programs contained within these accounts. Stateless programs are pieces of code that don’t remember any data between executions — they start from scratch every time they’re run. When a function call is made, these programs are activated, performing their tasks without relying on any past data. This concept helps maintain transaction independence and contributes to Solana’s innovative approach to improving blockchain scalability.
Sui: Introducing The Concepts of Objects
Sui has recently made its debut, causing quite a stir in the blockchain sphere. But what precisely does Sui bring to the table? To dive into the nuances of Sui’s architecture, our team has crafted a comprehensive paper comparing it with Aptos (another blockchain we’ll explore further down the line). At this juncture, however, our primary focus is on understanding Sui’s unique approach to achieving parallel transaction execution.
Sui’s parallelization strategy echoes Solana’s, but with a distinctive twist: replacing accounts with a construct known as ‘objects.’ Sui transactions do not reference accounts, rather, they change the attributes of objects, which can be assets or smart contracts. If a transaction is designated as independent (that is, if no other transaction interacts with the targeted object), it bypasses the consensus mechanism entirely — a feature referred to as byzantine consistent broadcasting.
To illustrate, imagine Alice owns a unique NFT, which in Sui’s context is represented as an object with “Alice” listed as its “owner”. If Alice transfers this NFT to Bob, the transaction, being an independent object transaction, circumvents the consensus process. However, if Alice decides to execute a more complex action, such as purchasing an NFT via a marketplace, the dynamics change. Because the object can be acted upon by other transactions, the transaction may be designated as dependent and may require sequential ordering prior to its execution.
Fuel: Capitalizing on UTXO for Enhanced Execution
Fuel is a standout player in the blockchain space, making optimal use of the UTXO (Unspent Transaction Output) model. If you think of the UTXO model as a physical cash transaction, it’s akin to handing over a 10-dollar bill for a 7-dollar item and receiving 3 dollars in change. By using the UTXO model, Fuel can efficiently parallelize transactions. This is because the UTXO model allows for easy identification of independent transactions — those that don’t overlap in the objects, or “bills,” they are interacting with. This independence means that such transactions can be processed simultaneously without conflict, significantly enhancing transaction throughput.
The UTXO model, also employed by Bitcoin, is leveraged by Fuel to build strict access lists. These lists serve as regulators, controlling which parts of the blockchain state can be accessed. This strategy relies on the idea of Canonical Transaction Ordering, which arranges transactions within a block in a way that simplifies the process of identifying inter-transaction dependencies.
Fuel brings this concept to life through the development of FuelVM, a new virtual machine, and Sway, an innovative programming language. FuelVM is designed as a streamlined yet fully compatible alternative to Ethereum’s Virtual Machine (EVM), which makes it more straightforward for developers to integrate into the Fuel ecosystem.
On top of this, Fuel emphasizes a modular blockchain structure. This modular approach allows transactions executed within Fuel to be settled on the Ethereum mainnet network. Consequently, Fuel is equipped to handle a large number of transactions, all of which are consolidated and settled on Ethereum. This strategic move allows Fuel to manage heavy transaction loads efficiently.
Aptos: Executing Optimistically
In our exploration of blockchain parallelization, we’ve first described how blockchains can establish dependencies right when a transaction is initiated. We call this the state access method, where the smart contract or developer defines which transactions have access to which part of the state. We now pivot to a different technique called optimistic execution. Optimistic execution is a strategy where each transaction is processed as if it’s not connected to any other, allowing all of them to be worked on simultaneously. However, if it turns out that some transactions are linked, they’re stopped, their results are wiped, and they’re run again. This can speed things up when transactions are mostly stand-alone, but when many transactions are linked, the process has to stop and reset often, which can slow things down.
Aptos uses a method called Block-Software Transactional Memory (Block-STM) to apply this kind of optimistic execution. Aptos is built on Diem’s Move language and MoveVM, and it can automatically spot when transactions are linked. It does this without needing the transactions to say which part of the blockchain state (like memory locations) they touch.
In Block-STM, transactions are first set up in a certain order within a block and then split up amongst different processing threads for simultaneous execution. As these transactions are processed, the system keeps track of the memory locations that each one changes. After each round of processing, the system checks all transaction results. If it finds that a transaction has touched memory locations changed by earlier transactions, its result is wiped and run again. This continues until every transaction in the block has been processed.
The success of Block-STM depends a lot on how linked the transactions are. According to the Aptos team, using 32 processing cores can lead to an eight times speed increase when transactions are highly linked, and a sixteen times increase when linkage is low. However, if every transaction in a block is linked, Block-STM may cause a slight slowdown compared to one-by-one execution.
Monad: The Trendsetter of EVM Chains
Monad is pioneering a new approach among EVM-compatible blockchains, being the first to introduce a parallelized architecture to an EVM layer 1. Like Aptos, it takes an optimistic execution path, operating under the assumption that transactions aren’t interconnected, and addressing any dependencies as they arise.
This novel approach hasn’t been without its challenges. Implementing significant modifications to blockchain technology is a complex and long-term commitment. Despite this, Monad has remained dedicated to innovation and has become a beacon for other blockchain networks aiming to enhance their own architectures.
Consider the cases of Polygon and Binance Smart Chain, both prominent blockchains that are now working on upgrading their systems to adopt similar strategies. The importance of Monad’s pioneering work in optimistic execution cannot be overstated, as it has influenced these large-scale platforms to reevaluate and modify their own architectures.
Polygon, for instance, boasts a fast throughput and a daily transaction volume in the millions. Their network’s APIs already provide sufficient data to drive a parallelizable engine, and by exploring an EVM-specific Block-STM, they’ve managed to avoid the need for API changes. However, given the sheer volume of transactions on the Polygon PoS chain, the assumption of zero dependencies among any block is not practical. Hence, they adopted a minimal metadata approach where transaction dependencies are recorded as metadata in a block, reducing redundancy and computational requirements.
Similarly, Binance Smart Chain is also exploring opportunities for parallel execution within their EVM chain via optimistic execution, reflecting the industry-wide impact of Monad’s innovative approach.
Monad’s innovative spirit and its commitment to pushing the boundaries of blockchain technology have set a new trend in the EVM space. Its approach to parallelized architecture in an EVM layer 1 has not only improved the efficiency of its own system but has also influenced and inspired other significant players in the field to follow suit, marking a significant shift in the blockchain industry’s future.
Sharding-Based Parallel Execution:
So far, we’ve discussed how various blockchains shatter sequential ordering and achieve parallelization through concepts such as accounts, objects, UTXOs, and optimistic models. However, the next-generation blockchains we’re about to examine take a distinct approach to parallelization. Instead of having a single blockchain capable of processing transactions in parallel, these platforms resemble sharding models. The blockchain is partitioned into multiple segments, each responsible for processing its own transactions.
Shardeum: a Sharded Approach to the EVM
Shardeum brings a groundbreaking approach to blockchain scalability through dynamic state sharding, enabling linear scalability. Shards, sub-sections of the network, each handle a portion of the network’s transactions, fostering enhanced resource efficiency and improved throughput. Consider a user transacting on a decentralized application (dapp) hosted on Shardeum. The transaction is assigned to a specific shard based on its associated data. The shard processes the transaction concurrently with others in its jurisdiction, acting like a mini-blockchain. The user benefits from quicker processing, optimizing the user experience.
A key feature of Shardeum is its Ethereum Virtual Machine (EVM) compatibility. Developers can migrate their Ethereum-based dapps to Shardeum with ease, combining Shardeum’s dynamic state sharding and parallel processing with the extensive Ethereum ecosystem.
Dynamic state sharding ensures the network’s adaptability to fluctuating demand, facilitating a scalable, efficient system. Shardeum executes cross-shard transactions atomically, allowing for the seamless execution of complex applications that require multiple user inputs, thus enhancing scalability.
The unique feature of Shardeum lies in its linear scaling capabilities. The network scales linearly as more nodes are added, meaning the transaction throughput increases proportionally with the number of nodes. This linear scaling, combined with node flexibility and auto-scaling features, allows Shardeum to handle varying workloads and network growth optimally. Shardeum marks a significant step towards realizing the full potential of blockchain technology by enhancing scalability for complex applications and offering a practical solution for real-world transaction demands.
Linera: A Revolutionary Multi-Chain Protocol
Linera’s innovative solution to blockchain scalability distinguishes itself through its dynamic multi-chain protocol, which encompasses user chains, public chains, and temporary chains.
The illustration above shows the three different chain types in the Linera system: user chains, public chains, and temporary (temp) chains. Each chain type has a distinct role, contributing to the protocol’s overall functionality and scalability.
Unlike Shardeum, which partitions its network into numerous shard chains, each responsible for a subset of transactions, Linera pioneers the concept of user-controlled chains. This granular approach provides users with increased control and autonomy while optimizing resource allocation across the network.
User chains, individually owned and controlled by users, form the backbone of Linera’s architecture. These chains process transactions by a specific end-user independently, allowing for parallel execution and significantly improving throughput while reducing latency.
Public chains constitute another critical component of Linera’s design. These chains are where decentralized applications, such as Automated Market Makers (AMMs), reside. Public chains are open to all network participants and provide a common platform for applications that require open and unrestricted interaction.
Linera also introduces the concept of temporary chains, purpose-built for handling complex operations like atomic swaps. This feature offers a significant advantage over protocols that require transactions to be recorded on the main chain, potentially causing bottlenecks. In Linera, a temporary chain is created for the duration of an atomic swap, processing independently of and in parallel with other transactions. Once the swap concludes, the temporary chain dissolves, and the updated states are reflected in the involved user chains.
The protocol’s structure supports horizontal scaling, an essential feature for maintaining system performance under varying loads. As traffic increases, validators can add more worker machines to manage the increased activity and maintain high throughput under heavy loads.
Unlike other protocols such as Cosmos, where each blockchain or “zone” is operated by a distinct set of validators, Linera unifies all chains within a single set of validators. This unified approach bolsters Linera’s protocol’s efficiency and security, streamlining cross-chain interactions by removing the complexities of validation by separate validator sets, which could potentially lead to increased latency or discrepancies. Consequently, transactions are processed more efficiently across the entire ecosystem, significantly reducing the risk of conflicts.
Quai Network : Powering Parallelism and Interoperability with Proof-of-Work
Quai Network carves its path in the blockchain industry with its distinctive approach to scalability. By implementing a dynamic and interoperable multi-chain architecture, Quai offers a unique Proof-of-Work-based solution to the scalability problem that enables transaction parallelization via infinite execution sharding. This approach differentiates Quai from protocols like Linera, which utilizes user-controlled chains, while sharing some similarities with Shardeum’s dynamic sharding.
Quai employs a version of sharding akin to traditional methods used to enhance database performance in centralized systems. However, Quai diverges from typical sharding schemes with its dynamic, adaptable and deeply interwoven multi-chain architecture. This is somewhat similar to Shardeum’s dynamic sharding, where the network is divided into shard chains that process transactions independently. However, Quai’s use of merged mining to coordinate these distinct shards creates a uniquely interconnected structure that allows for parallel execution of operations across the network. Unlike all existing implementations of sharding, which introduce some new mechanism of trust to facilitate interoperability (cross-shard transactions), Quai Network’s use of merged mining to interconnect shards ensures that the only mechanism required to process cross-chain transactions is mining. Quai Network’s unique method of achieving interoperability via merged mining significantly enhances throughput and provides the ability to accommodate high volumes of simultaneous transactions without any sacrifice to decentralization or performance.
To enable the coordination of an infinite number of execution shards, Quai Network has introduced a new consensus mechanism known as Proof-of-Entropy-Minima (PoEM). PoEM is based on Proof-of-Work (PoW) consensus but differentiates itself from other consensus mechanisms as the first consensus mechanism to eliminate consensus-based forks. When running PoEM, all nodes will always immediately have the same preference for the next block in the sequence given the same set of information. PoEM allows all nodes to immediately and fairly compare any proposed blocks against each other which eliminates all uncertainty for consensus. By ensuring that consensus is always instantaneous, PoEM provides the necessary prerequisite to infinite sharding. If consensus requires any time to be established, there is a hard limit on the number of execution shards that can be coordinated. PoEM, as the first “zero-time” method of reaching consensus, is the first and only consensus algorithm suited to coordinate an infinitely growing set of chains.
A standout feature of Quai’s architecture is the introduction of Parallel Execution Threads (PETs), referred to in Quai as “Zones.” Each “Zone,” or parallel execution thread, independently and asynchronously processes transactions. The ability for each Quai execution thread to independently process transactions enables the network’s parallel processing capabilities and is one of the core concepts behind Quai’s scalability.
The number of chains in Quai Network is dynamic and adaptable, much like Shardeum’s dynamic shards. Uniquely, however, Quai Network’s use of the PoEM consensus mechanism allows this pattern of dynamic sharding to be performed infinitely with no degradation of performance. Quai Network’s addition of execution shards through dynamic sharding has one clear tradeoff: as more execution shards are added to the network, the time a cross-chain transaction takes to be reference-able by its destination shard will increase. This relationship is sublinear — Quai’s expansion from 9 shards to 16 shards, for example, would increase the average time for a cross-chain transaction to reach its destination from 3,300 seconds to 4,400 seconds. A further expansion to 25 shards would increase this average time to ~5,500 seconds. Theoretically, if Quai were to expand to 100 shards, the average time to global cross-chain settlement would be ~11,000 seconds. Quai Network’s dynamic sharding algorithm monitors the gas limit and uncle rate of the network to know when additional throughput is demanded, and automatically braids additional execution shards into consensus to accommodate increased demand for throughput.
Furthermore, Quai’s braided structure supports composable multi-chain smart contracts and allows efficient cross-chain contract interactions. Each Quai execution thread has an EVM on top of it, with new op-codes introduced to enable communication with EVMs located on alternate shards. This capability empowers developers to deploy contracts across multiple or all Quai chains, ensuring the operability of decentralized applications (dapps) across the entire network.
Quai Network’s innovative application of sharding, coupled with its merge-mined interoperability and parallel execution threads, represents a significant stride in blockchain scalability within a work-based consensus mechanism. The robust handling of cross-chain transactions and advanced smart contract functionality positions Quai as a noteworthy contributor in the evolving landscape of scalable blockchain protocols.
Computation-Based Parallel Execution:
An emerging paradigm in blockchain parallel execution is the computation-based model. This term, coined by our research team at Amber Group, describes an approach in which computational tasks are processed simultaneously within a shared environment. Distinct from the state access and optimistic models, the computation-based model does not strictly rely on sequential memory-based computations. Instead, it operates on the principles of a highly parallel virtual machine. This design promotes robust and highly efficient parallel execution. The following section will explore the principles of computation-based parallel execution, its potential applications, and the unique challenges it introduces to the broader blockchain technology landscape, providing a comprehensive understanding of this new category of parallel execution within the blockchain environment.
Kindelia: The Pinnacle of Computation-Based Parallel Execution
Kindelia has emerged as a promising solution in the computation-based model of parallel execution in the blockchain. Developed by the Higher Order Company, it is anchored on a unique runtime known as the Higher-Order Virtual Machine (HVM), which enables highly efficient parallel computations.
Kindelia’s innovation is founded on a new type of computational model known as “interaction nets,” a concept that deviates from the Turing machine model that underpins the majority of modern computers. Interaction nets are based on a graph of interacting nodes, with each node possessing a set of rewrite rules dictating how it interacts with others in the network. Computation is achieved by reducing the interaction net, and systematically eliminating nodes from the network according to their rewrite rules until a final state is reached. This model allows computations to occur in parallel without needing a central clock to dictate the process, as nodes interact locally without any global coordination.
The advantages of this model are manifold. It promotes faster and more efficient computation due to its inherent parallelism, vastly outperforming traditional sequential models of computation. Furthermore, it opens up a realm of applications in various areas of computer science. In the blockchain context, Kindelia stands out as the first truly parallel virtual machine, achieving what many alternative layer 1 companies aspire to. However, due to their reliance on Turing machine-based architectures, these competitors will likely never reach the same level of parallelization.
Kindelia’s design requires fewer computational steps to execute functions, maximizes the use of processing cores, and ensures that operations execute in the correct order — all with a minimal extra effort from developers. This streamlined execution process, coupled with the higher level of security, positions Kindelia as a cutting-edge example of computation-based parallel execution in blockchain technology.
Although the theoretical underpinnings of Kindelia and the HVM are advanced, the practical implications are easy to understand: increased speed, efficiency, and security in blockchain computation. Through Kindelia, we are witnessing a revolutionary leap in blockchain technology, marking a significant milestone in the continuous evolution of this transformative field.
Concerns with Parallel Execution
As we explore the potential of parallel blockchains, it’s crucial to acknowledge that while they present substantial scalability and speed advantages, they also introduce unique challenges and potential drawbacks. Two primary concerns that are frequently highlighted are the possibility of increased centralization and the issue of high transaction conflict rates.
Parallel blockchains distribute transaction processing among numerous nodes, thereby enhancing transaction processing throughput. However, this distribution can also lead to a concentration of power within a few nodes, thus introducing a degree of centralization. This centralization could potentially undermine the trustworthiness and security of the blockchain, making it more susceptible to attacks. Additionally, the risk of network downtime increases with parallel blockchains. For instance, the Solana network experienced a downtime event in September 2021 due to an overabundance of transaction requests. This incident underscores the potential risks associated with scaling blockchain networks and emphasizes the necessity for solutions to handle high transaction volumes without compromising stability.
The transaction conflict rate is another significant concern. This rate refers to the percentage of transactions that cannot be executed simultaneously due to conflicts. A high conflict rate can lead to numerous transaction redos in a parallel blockchain. According to a report by Flashbots, Ethereum transactions in 2017 had a conflict rate of around 35%. With major applications such as OpenSea and Uniswap dominating the Ethereum network today, the conflict rate could potentially be even higher.
In the context of optimistic execution, if the conflict rate exceeds 30%, the number of transaction redos can significantly disrupt the pipeline. Each redo slows down the transaction processing speed, reducing the impending benefits of parallelization. Consequently, managing the transaction conflict rate is of utmost importance for ensuring the efficiency of parallel blockchains.
Conclusion
The blockchain landscape is evolving significantly as it seeks to address scalability and efficiency issues inherent in its design. We have explored the various methods through which parallel execution can be achieved, each with its distinct set of advantages and challenges. The state access-based model marks the first step towards overcoming the sequential nature of blockchains. Optimistic execution, while promising, introduces the risk of conflicts and the need for efficient conflict resolution strategies. Sharding takes us a step further by partitioning the network into smaller, manageable pieces, each capable of processing transactions independently. Lastly, computation-based parallel execution uses cutting-edge computer science to maximize node performance and application security. Although challenges and potential concerns exist, these models demonstrate the potential to enhance the performance and capability of blockchain technology significantly. As these continue to evolve and mature, we stand at the cusp of a new era in blockchain technology.
Author
Robert McTague is an Investment Associate for Amber Group’s Eco Fund, the company’s early-stage crypto venture fund.
Disclaimer
The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.
