Written by Sooraj | Reviewed by Matthew Hine & Avaunt

Bitcoin was a technological breakthrough that has fundamentally changed the nature of financial transactions.

Bitcoin enabled transactions to be verified and recorded in a way that does not rely on trust between individuals or centralized authorities like banks. By rendering the need for trusted intermediaries obsolete, Bitcoin embodies a world where absolute certainty is attainable through objective, mathematical verification rather than subjective human trust.

This was a paradigm shift from traditional financial systems underpinned by centralized authorities to a peer-to-peer system without a central governing body.

Ethereum's major technological leap was creating a trustless, decentralized platform for building applications and coordinating human activity. The Ethereum Virtual Machine (EVM) established a "world computer," which provides a single, shared environment where all smart contracts and applications coexist and can freely communicate with each other.

Any application built on the EVM has access to all the data and functionality of other applications on the network. Smart contracts on Ethereum enabled trustless interactions, placing trust in code and cryptography rather than intermediaries. This fundamentally changed how we thought about society's structures, agreements, and relationships.

And what seems to be the biggest challenge in this space right now is how to scale that "world computer" without breaking the composability between the applications in that system.

Let me explain.

When Ethereum pioneered the "world computer" vision, allowing anyone to build applications without permission while maintaining atomic composability, it was a fantastic success. We saw different apps popping up and enabling new use cases.

Such flexibility, often called "composable money legos," allows developers to treat various protocols as building blocks that can be assembled in creative ways to unlock new use cases. For example, a DeFi lending protocol can easily integrate with a decentralized exchange to allow users to seamlessly trade their borrowed assets.

But the problem always was how many transactions this "world computer" can process at a given time.

From platforms like Solana to Sui, the goal is to create a distributed ledger system that supports the world computer and can process more transactions.

But the problem always was that there was always a hard cap on the throughput of this world computer.

Now the question is if we can have a world computer that allows atomic composability between those applications, allows developers to code secure applications, and scales according to demand. This means the system should process billions of transactions a second if needed, and be a linearly scalable system that scales with demand.

Basically, this is the Radix thesis for scalability.

The overarching philosophy of Radix's approach to scalability is that for Web3 applications to achieve mainstream adoption and replace traditional finance, the underlying distributed ledger platform needs to handle increasing transaction volumes and user demand without hitting bottlenecks or performance degradation, and also without compromising on decentralization, security, or atomic composability between applications.

In this write-up, we are going into the technical fundamentals of the approach Radix is taking to enable linear scalability.

So let’s go.

Linear scalability is a fundamental requirement  for realizing the vision of a truly decentralized and globally accessible "world computer" that can support complex applications and agreements at a global scale.

The core idea behind linear scalability is the ability to increase a system's throughput proportionally as more resources (nodes, computing power, etc.) are added to the network.

This allows the system to scale seamlessly without running into bottlenecks or centralized points of control and also retaining the atomic composability between the applications in the network.

The problem with Ethereum's rollup-based scalability approach is that it essentially creates multiple separate execution environments or "rollup chains" rather than scaling the base layer itself.

This fragments the Ethereum network into multiple siloed "rollup chains" rather than scaling the base layer itself. Users and developers must navigate a complex landscape of different rollups, each with its own liquidity, security models, and tooling.

This goes against Ethereum's original vision of a unified, globally composable "world computer."

While blockchains like Solana and Sui aim to scale Ethereum's initial world computer concept, their approaches ultimately face inherent limitations that cap their throughput capacity.

Solana, for example, uses a unique Proof of History consensus mechanism and parallel transaction processing with its Sealevel runtime to achieve high throughput. However, its performance is still limited by the hardware of individual validator nodes that the system can accommodate and it's network is not designed to linearly scale the number validator nodes

As the network grows and transaction volumes increase, Solana may eventually reach a scalability limit, as seen during the meme season, which resulted in congestion on Solana.

Similarly, Sui introduces innovative features like its object-centric data model and parallel execution engine . These optimizations enable impressive scalability gains compared to Ethereum. However, like Solana, Sui's throughput is ultimately bounded by the vertical scaling limits of its validator hardware.

In contrast, Radix's approach aims to achieve true linear scalability at the base layer itself, without any theoretical limits. The key innovation powering this is Radix's Cerberus consensus protocol, which leverages a unique pre-sharded ledger architecture and its tight integration with the Radix Engine application layer.

So let’s explore the 3 core components of the Radix distributed ledger platform, and how these three components together bring the vision of a linearly scalable world computer!

Radix redefines the concept of an execution layer by integrating concepts that are tried, tested, and highly successful in the web2 space, differing significantly from systems like Ethereum or Solana.

Much like game engines such as Unreal Engine revolutionized game development, the core philosophy of the Radix Engine centers around streamlining development processes.

Game engines provide a unified framework that handles graphics, physics, and other low-level functions, allowing developers to focus on game design and storytelling.

Similarly, the Radix Engine aims to simplify the development of web3 applications by offering a comprehensive toolkit that manages the intricate details of asset management and transactions. This abstraction allows developers to concentrate on creating innovative financial applications without getting bogged down by the underlying complexities of blockchain technology.

One of the key aspects of this streamlined approach is the asset-oriented design philosophy that guides the development of the Radix Engine.

This philosophy aims to provide a more intuitive, secure, and efficient approach to building web3 applications and managing digital assets. The Radix Engine treats digital assets, such as tokens and NFTs, as first-class citizens within the platform. Assets are not just balances in smart contracts but are perceived and treated as tangible objects that can be held, transferred, and controlled directly by users. This native asset handling simplifies asset management and reduces the risk of smart contract vulnerabilities.

This design philosophy represents a fundamental shift from the account-based, message-passing model used by platforms like Ethereum. It recognizes that assets are the core of most apps and provides a purpose-built environment that prioritizes their secure and efficient management.

The Radix Engine utilizes the concept of a finite state machine (FSM) to manage assets. An FSM ensures that an asset can only change states in predefined ways, offering several benefits.

FSM guarantees that assets only transition between valid states, preventing errors such as transferring assets without proper ownership or duplicating assets without following specific rules. The FSM model mimics how physical assets behave; for instance, cash cannot multiply on its own, and a ticket can only be used by its holder.

This alignment with real-world logic makes digital asset management more intuitive for developers.

The Radix Engine offers Scrypto, a smart contract language based on Rust, which is known for its safety and performance.

Scrypto extends Rust with native asset management features, providing built-in functions for common asset operations such as minting (creating new assets), burning (destroying assets), and transferring assets. These built-in functions reduce the amount of code developers need to write and test.

By abstracting complex asset management tasks, Scrypto allows developers to focus on building unique features of their applications instead of reinventing the wheel.

In 2022 alone, over $2.598 billion worth of crypto was stolen via DeFi breaches. In 2023, funds stolen from DeFi protocols were around $1 billion. In Q1 2024, DeFi platforms lost more than $336 million in digital funds.

In a world where we lose billions of dollars in DeFi hacks, ensuring security is of paramount importance if web3 applications are to gain real-world adoption.

The asset-oriented approach and use of FSMs inherently prevent many common smart contract vulnerabilities. By enforcing strict rules and state transitions for assets at the protocol level, the Radix Engine eliminates entire classes of bugs and exploits that plague other smart contract platforms.

Developers and users can trust that assets will behave as expected, which is crucial for financial applications where security and reliability are paramount.

By prioritizing security and reliability from the ground up, the Radix Engine aims to provide a robust and secure foundation for applications, particularly in the web3 space, where security vulnerabilities can have severe financial consequences.

But having a world-class execution engine like the Radix Engine is only one part of the puzzle.

It alone is not enough to enable truly global-scale web3 applications. The execution environment must be able to handle the demands of millions and eventually billions of users without compromising on performance, security, or decentralization. 

The integration of the Radix Engine with Cerberus, Radix's pre-sharded consensus environment, addresses this requirement.

Radix's approach to sharding differs significantly from most other platforms. While many projects opt for dynamic sharding, where new shards are added incrementally as network demand increases, Radix has chosen the path of pre-sharding.

This design decision is rooted in the belief that for a linearly scalable network, it's more efficient to manage the movement of validators than to constantly redistribute state across new shards.

So let's dive deeper into this concept: A Massive Pre-Sharded Ledger with Deterministic Shard Derivation

With Cerberus, Radix starts with a fixed shard space of 2^256 shards from day one. This means the network is divided into an incredibly large number of shards before any transactions even take place. 

Each shard contains a substate, which is a discrete unit of data. Substates can represent anything from a single token to an entire dApp and its users' tokens.

In contrast, most other sharded blockchains start with a single shard and add more shards incrementally as the network grows.

Each shard in Radix's ledger is deterministically derived based on a key reference field, such as a public key. This means that given an input (e.g., a public key), the corresponding shard can always be located efficiently.

As transactions occur, data is added to the appropriate shards based on the deterministic mapping. With a known location ID for each shard, it's simple to route transactions for processing. Nodes then only need to handle data for the shards they manage, not the entire ledger.

This setup makes it easy and efficient to locate the shard responsible for any transaction. Related data stays grouped together, avoiding costly data reorganization as the network grows. This method also speeds up lookups and reduces cross-shard communication. In contrast, dynamic sharding requires constant network monitoring and decisions about when to add new shards, which is more complex.

This pre-sharded ledger with its 18.4 quintillion shards has the theoretical capacity to process millions of transactions per second and store vast amounts of data . As the network grows and more nodes join, additional shards can be allocated to these nodes, allowing the network's throughput to increase linearly.

While having a world-class execution environment and a pre-sharded ledger capable of accommodating global-scale demands is crucial, the real challenge lies in coordinating transactions and maintaining consistency within and across the shards.

This is where Radix's unique consensus algorithm, Cerberus, becomes essential.

The Cerberus protocol is a cross-shard consensus protocol designed to enable fast and secure cross-shard communication in Radix's massively sharded environment.

The operation of Cerberus hinges on two fundamental components:

• Local consensus within each shard and

• Cross-shard communication

Within a shard, validators must reach an agreement on which transactions to process and in what order. This local consensus is crucial for ensuring that all validators within a shard are synchronized and agree on transaction details.

Once this agreement is reached, the cross-shard communication component of Cerberus comes into play. This component allows shards to communicate with each other, coordinate transactions, and maintain consistency across the entire network.

To facilitate these processes, Cerberus uses a serverless mechanism that enables seamless communication between shards. This serverless design means that there is no need for a central server to manage the communication, which enhances the protocol's scalability and robustness.

The consensus within each shard and across shards happens simultaneously in a single 3-phase process. During this process, the validators across all involved shards collectively agree on the correctness and order of a transaction, consistent with the state of their individual shards. If there is a problem in any shard, the entire transaction fails across all included shards. This approach maintains the integrity and consistency of the shard's state and ensures that transactions involving multiple shards are processed correctly.

This mechanism involves exchanging states, producing quorum certificates, and validating these certificates to ensure that transactions are completed successfully across all involved shards.

One of the key innovations of Cerberus is its "braiding" mechanism, which conducts consensus across only the necessary shards for each transaction. When a transaction involves multiple shards, Cerberus dynamically establishes a "braid" that connects the relevant shard sets.

This braid allows the transaction to be processed atomically across the involved shards, ensuring consistency and preventing double-spends.

Cerberus employs a three-phase commit (3PC) process within each shard to establish agreement among the shard's validators.

The braiding mechanism intertwines these 3PC processes across the relevant shards, creating a unified, atomic commit. This ensures that the transaction is either committed or aborted in its entirety across all involved shards.

The braiding of 3PC processes across shards results in an "emergent" multi-shard consensus. This emergent consensus is just as secure and atomic as a single-shard consensus but spans multiple shards. It allows complex, cross-shard transactions to be  executed and committed atomically without compromising composability.

By focusing only on the necessary shards, the braiding mechanism enhances the efficiency and scalability of the protocol. This approach contrasts with traditional blockchains that rely on global transaction ordering, which can be inefficient and slow.

Cerberus also introduces a novel approach to ordering transactions. Instead of relying on a global transaction order, Cerberus allows each transaction to specify its relevant shards so that ordering only needs to occur between transactions when they interact with the same shard – this is called partial ordering.

This enables parallel processing of unrelated transactions across different shards, significantly boosting throughput. The braiding mechanism ensures that related transactions are processed atomically and consistently, maintaining the integrity of the network. But importantly it means that because most transactions aren’t related to each other, more nodes can be added to process more transactions in parallel more quickly. This parallelization is key to Cerberus’ linear scalability

Within each shard, Cerberus employs a Byzantine Fault Tolerance (BFT) style consensus to establish agreement among the shard's validators. BFT ensures that the shard remains secure and consistent, even in the presence of malicious actors.

By combining shard-level BFT with cross-shard braiding, Cerberus can scale securely & linearly while maintaining high performance. This combination of local and global consensus processes ensures that the network can handle a large number of transactions efficiently and securely.

With fully sharded Cerberus, the network will scale linearly according to demand by progressively increasing the number of validators and assigning them to shards as needed. 

Initially, the Babylon network operates with a small set of validators, fixed at 100, and handles around 50 TPS. This phase uses a "single shard" form of Cerberus. As the network approaches its capacity, it will transition to the Xi'an phase, a major protocol update that will implement the fully sharded form of Cerberus. At this point, the validator set will no longer be fixed, and the network's scalability will greatly increase with massive parallelism.

In this phase, the number of validators can increase beyond the initial set, enhancing the network’s capacity and decentralization. As network load increases, the validator set can expand across multiple shards to manage the demand. For example, when the load becomes too high for a single group, it can split into two groups of 250 validators each. Further splits occur as more validators join, such as into three groups of 300 validators each.

Validators also rotate between different shard sets at the end of each epoch in a random fashion. This prevents collusion and control over specific shards.

This process of adding validators and assigning them to shards continues progressively, ensuring a gradual and scalable increase in both capacity and decentralization. Thus, the network scales linearly by adding more validators and distributing them across shards as needed.

The Cerberus consensus protocol has undergone rigorous peer review and formal verification to ensure its security, correctness, and performance.

The academic paper titled "Cerberus: Minimalistic Multi-shard Byzantine-resilient Transaction Processing" was accepted for publication in the Journal of Systems Research (JSys) in June 2023. This peer review process involved independent experts verifying the proof, theory, and soundness of the protocol, comparing it to other state-of-the-art multi-shard consensus protocols like Chainspace, AHL, Sharper, and RingBFT.

Additionally, Cerberus has undergone formal verification to mathematically prove its correctness and security properties, ensuring it is free from logical errors and vulnerabilities, providing a high level of assurance in the design and implementation of Cerberus.

When deployed Cerberus will be tightly integrated with the Radix Engine, which translates application-level actions into discrete "substates" or transactions.

The Radix Engine specifies the relevant shards for each transaction based on the resources and components involved. This integration allows Cerberus to efficiently route transactions to the appropriate shards and establish braids as needed.

Developers do not need to manually manage shard interactions, as the Radix Engine and Cerberus handle these complexities automatically. This tight integration simplifies the development process and ensures that the network operates efficiently and securely.

The implementation of the Cerberus consensus protocol on the Radix mainnet will happen with the upcoming Xi'an upgrade. As of now, this is being tested in the Cassandra Test Network.

The core focus of the Cassandra Test Network is to research, test, and demonstrate various implementations of the Cerberus consensus protocol before it is fully implemented in the Radix Xi'an mainnet upgrade.

The primary purpose of the Cassandra Network is to develop and test concepts for the components needed to build a linearly scalable and decentralized network.

While Cerberus provides an excellent consensus mechanism for cross-shard communication, ensuring linear scalability, there are other essential pieces required to build a complete, functional network.

Cassandra is essentially about "building the rocket around Cerberus," ensuring all necessary components work seamlessly together. It serves as a testbed to identify and solve challenges related to using Cerberus in a live, decentralized test network that will provide valuable data for the final product implementation of Cerberus for the Xi’an update to the Radix Network.

While Cerberus is important, it is just one part of the system. The Cassandra network focuses on testing concepts and techniques for the necessary infrastructure and other technologies around Cerberus to create a fully functional, scalable blockchain network.

One key area being explored in Cassandra is the development of a new local consensus mechanism that ensures liveness and complements Cerberus' cross-shard safety. This is crucial for permissionless networks and helps maintain the network's resilience.

Cassandra is used to research and optimize various aspects of the network, such as reducing authentication complexity, minimizing cross-shard data transfer, lowering bandwidth and CPU requirements, and improving decentralization. The goal is to enable the network to run efficiently on regular hardware and low-bandwidth connections.

The Cassandra network recently achieved a significant milestone, performing a record-breaking 100,000 swaps per second and 80,000 transfers per second, totaling around 180,000 transactions per second. This performance was sustained over 100,000,000 transactions in total, demonstrating the network's impressive efficiency and scalability.

Dan Hughes | Radix

@fuserleer

#cassie update as I've been working hard on efficiency improvements.

Performed a record breaking 100,000 swaps per second PLUS 80,000 transfers per second totalling ~180,000 #tps for a sustained period of time over 100,000,000 transactions total.

#radix $xrd #crypto

753

11:30 • 15 May 2024

There is an ongoing effort to gather more compute resources for testing the Cassandra network. Participation can help achieve further performance improvements. Interested parties are encouraged to fill in the registration form and join the Cassie Telegram group.

Dan Hughes | Radix

@fuserleer

With the #cassie development going well, here's a reminder that we're still looking for compute resources to join the testing so we can smash records.

Fill in the registration form, join the Cassie Telegram!

#crypto #tps

docs.google.com

Cassie 1M+ TPS Community Test

Cassie is a research network used to test and develop various blockchain and DLT technologies here at Radix. It implements our Cerberus linearly scalable consensus and helps us to plot the path to...

224

12:09 • 9 May 2024

Cassandra's research and findings will provide valuable input to the development of the Xi'an network update, ensuring that the Radix Network will be able to scale linearly while maintaining liveness, safety, and decentralization. The network's experiments provide solutions to potential problems, making the transition smoother for the production version.

Radix's approach to building its distributed ledger system demonstrates a clear understanding of the key challenges hindering widespread adoption in the blockchain industry. The Radix team has taken a fresh and straightforward approach to solving these issues, focusing on creating a solid foundation with the Radix Engine before tackling scalability.

Looking back at Ethereum, the main reason it had to pursue a scalability roadmap was the overwhelming success of its core offering—a decentralized execution environment that enabled full composability between applications. EVM unlocked a world of possibilities for developers, leading to the creation of numerous decentralized applications (dApps) and the explosive growth of the DeFi ecosystem.

However, this success also exposed Ethereum's limitations. As demand surged, the network became congested, leading to high gas fees and slow transaction times. Users found themselves paying hundreds of dollars for simple transactions, highlighting the urgent need for scalability solutions.

By focusing on creating a seamless and intuitive developer experience, Radix is laying the groundwork for attracting developers and fostering innovation.

The key question now is whether the Radix Engine will be able to capture the attention and traction of users and developers. If it succeeds in offering a compelling and valuable proposition, the demand for its capabilities will naturally grow, just as it did with Ethereum's smart contract platform.

Should the Radix Engine prove successful and gain significant adoption, the need for scalability will become apparent. This is where Radix's linear scalability system, designed to handle increasing demand by dynamically scaling the network's capacity without compromising security or composability, will come into play.

However, if the Radix Engine fails to gain traction and attract users, the need for such a scalability solution may not arise. The success of Radix's core offering will determine whether its scalability infrastructure will be put to the test.

Do you like our Thesis Approach to understanding crypto and blockchain tech?

Then Subscribe to our Newsletter and we'll deliver a Thesis every week straight to your inbox:

Guaranteed spam-free:)

DISCLAIMER: None of this is financial advice. This newsletter is strictly educational and is not investment advice or a solicitation to buy or sell assets or make financial decisions. Please be careful and do your own research.

The Monad Thesis

The Ethereum Virtual Machine (EVM) is by far the most popular virtual machine in the blockchain space, dominating in terms of user and developer adoption.

However, it has not been synonymous with high performance or security.

This is where Monad steps in, with a refined EVM that pushes the boundaries on both fronts.

In this edition of "Just The Metrics," we are exploring "The Monad Thesis" in depth, presenting a clear overview of how this new platform aims to redefine the EVM paradigm.

So, let's go.

The Ethereum Virtual Machine (EVM) is a global computing engine. In this system, numerous nodes operate in unison, each maintaining a complete and consistent copy of the entire network, including all applications and their current states. This setup ensures that all nodes are synchronized and process transactions uniformly.

To interact with applications on Ethereum, users send transactions to the network. These transactions, which are essentially function calls to smart contracts, are grouped into blocks. Every node processes these blocks in the same sequence, which helps the network remain synchronized.

The EVM provides a single, shared environment where all smart contracts and applications coexist and can freely communicate with each other. Any application built on the EVM has access to all the data and functionality of other applications on the network.

For example, a DeFi lending protocol can easily integrate with a decentralized exchange to allow users to seamlessly trade their borrowed assets.

This is possible because the EVM standardizes how apps run and keeps track of all accounts, balances, and codes. Developers can build apps that work with this existing system without needing special setups; they simply interact with other smart contracts already in place.

Such flexibility, often called "composable money legos," allows developers to treat various protocols as building blocks that can be assembled in creative ways to unlock new use cases.

Specifically, the EVM gave Ethereum the first-mover advantage by being the first blockchain platform to enable full composability between all applications in the system.

To give you some perspective, this is how successful the EVM has been so far:

Total Value Locked (TVL): 

EVM-based chains dominate the TVL metrics. According to data from DefiLlama, as of May 2024, EVM-based chains hold 89.48% of the total TVL in the blockchain ecosystem.

From a developer adoption perspective, EVM platforms are the most popular. If you look at the top 10 ecosystems with the most number of active developers, 6 of them are EVM-based.

Key findings from Electric Capital's report on the state of development within the Ethereum network and other EVM chains during the fourth quarter of 2023 show that a significant majority of multichain developers, approximately 9 out of 10, choose to work on EVM-compatible chains.

Both these metrics highlight EVM’s continued dominance in attracting developer talents.

In essence, EVM has established significant network effects in the blockchain space, but it is not the most performant or the most secure VM out there, and this is slowing the pace of innovation that could have been achieved otherwise.

In modern computing, performance gains are often achieved through parallel processing, where multiple computational tasks are carried out simultaneously. Since the EVM processes transactions sequentially, it cannot leverage multi-threading or multi-core processing effectively. This single-threaded design inherently limits the throughput of the system as the transaction load increases.

The EVM design sets a gas limit on blocks, capping the computational work per block. Each transaction uses gas based on its complexity, limiting the number of transactions per block. sequential processing exacerbates this limitation because only so much work can be queued and processed within one block's gas limit.

Additionally, sequential execution does not efficiently use modern multi-core processors, which are designed to handle multiple operations simultaneously. The inability to parallelize transaction processing means the EVM does not fully utilize available computational resources, thereby limiting overall performance.

To put it simply, most blockchains that support the EVM bytecode standard can process up to ~200 transactions per second (tps) or ~20 million transactions per day, which is not enough for high-demand applications.

That's where Solana introduced its VM, which pioneered parallel execution and proved a point!

Solana pioneered parallel execution through Solana Virtual Machine (SVM), which includes the Sealevel parallelization engine.

SVM architecture utilizes stateless programs, meaning the programs do not hold any state. This design choice is crucial for enabling parallel execution because it simplifies the process of determining which transactions can be executed in parallel without causing conflicts.

Transactions on Solana are required to explicitly declare all the states they will read or write during execution. This includes specifying all the accounts and data that the transaction will interact with. By making these requirements explicit, Solana's runtime can easily identify dependencies between transactions and determine which ones can be executed in parallel. This setup is a part of Solana's Sealevel system, which is the world's first parallel smart contracts runtime. Sealevel allows thousands of smart contracts to run in parallel, maximizing throughput and efficiency across the network.

With the explicit state declaration and Sealevel’s capabilities, Solana's runtime can identify transactions that are independent of each other, meaning they do not read or write to the same state. These independent transactions can then be executed in parallel, significantly increasing the throughput of the network.

In addition, Solana improves its parallel processing by allowing concurrent transactions that read from the state as they do not modify the state and cause conflicts. Since these transactions do not modify the state, they can be executed simultaneously without causing conflicts, further enhancing the network's capacity for parallel processing.

These innovations collectively enabled Solana to achieve a throughput of 500–1000 TPS, excluding votes.

The primary approach behind Monad is quite straightforward. Monad adopts the parallel execution model pioneered by Solana, allowing multiple transactions to be processed concurrently to significantly enhance the performance and security of an EVM-compatible blockchain.

So what are the core concepts of monad's architecture?

Monad implements pipelining, which involves dividing transaction processing into stages and executing the stages of each transaction in parallel with other transactions. Monad is integrating here a modular approach in designing an L1 blockchain.

Here's how it works:

Monad breaks down the processing of each transaction into distinct stages, such as fetching the transaction data, verifying signatures, executing the transaction, updating the state, and committing the results.

For example, while one transaction is in the execution stage, another transaction can be in the signature verification stage, and yet another can be in the data fetching stage.

By executing stages of different transactions simultaneously, Monad makes efficient use of available resources (such as CPU cores and I/O bandwidth). This is analogous to the laundry example, where the washing machine and dryer are used concurrently to process multiple loads of laundry more efficiently.

Although the stages of transactions are processed in parallel, Monad ensures that the results are committed in the original intended order. This preserves the correctness and consistency of the blockchain state.

By overlapping the execution of transaction stages and utilizing resources efficiently, superscalar pipelining dramatically improves the overall throughput of Monad.

MonadBFT is Monad's high-performance consensus mechanism for achieving agreement on transaction ordering under partially synchronous conditions while maintaining Byzantine fault tolerance. It is a derivative of HotStuff with improvements from Jolteon/DiemBFT/Fast-HotStuff, reducing the number of communication rounds from three to two in the common case.

MonadBFT proceeds in rounds, with each round having a designated leader. The leader sends a new block proposal along with a quorum certificate (QC) or timeout certificate (TC) from the previous round to all validators.

If validators agree with the block, they send signed YES votes to the next round's leader. The leader aggregates these votes into a QC using threshold signatures. This results in linear communication in the common case.

If validators don't receive a valid block in time, they multicast a signed timeout message to other validators. If a validator collects enough timeout messages, they aggregate them into a TC and send it to the next leader. This results in quadratic communication in case of timeouts.

Validators commit a block when they see two adjacent certified blocks, known as the 2-chain commit rule.

Monad optimizes the consensus payload by referring to transactions by their hash and ensuring they are propagated through the mempool ahead of time. This reduces the amount of data that needs to be included in the consensus process.

Monad separates the consensus process from transaction execution. Nodes first come to an agreement on the transaction order without actually executing those transactions. This is different from Ethereum, where execution is a prerequisite to consensus and the leader and validating nodes must execute transactions before agreeing on a block. This pipelining allows consensus to proceed without waiting for execution to complete.

By decoupling execution from consensus, Monad significantly expands the time available for transaction execution. Execution merely needs to keep up with consensus on average, rather than fitting into a limited time window. This allows for higher gas limits as computation doesn't need to be completed on all nodes within a strict budget.

Since consensus operates on a delayed view of execution, Monad introduces a carriage cost for transactions to prevent spam. Each account maintains a reserve balance to pay for the carriage cost of in-flight transactions.

The carriage cost is charged to the reserve balance at consensus time, deducted from the execution balance during execution, and refunded to the reserve balance after a delay period. This ensures that only paid transactions are included in blocks.

At the core of Monad's Parallel Execution model is the principle of optimistic execution. This means that Monad begins executing transactions before the completion of previous transactions in the block. This approach can sometimes lead to incorrect execution if, for example, two transactions modify the same account balance in ways that would conflict if executed sequentially. To address this, Monad employs a mechanism to "merge" the updated state from each transaction sequentially, ensuring that the final state is consistent with a sequential execution order.

Monad also employs techniques to avoid unnecessary re-executions when possible, such as dependency analysis to identify transactions that can safely run in parallel, and caching of loaded state data to speed up re-execution.

Enabling optimistic parallel execution requires a high-performance database to store the blockchain state. Monad uses a custom database called MonadDb that is optimized for this purpose.

MonadDb leverages asynchronous I/O to allow for concurrent execution while data access is in progress. It fully utilizes the latest kernel support to achieve high-performance asynchronous operations.

This parallel execution model, combined with MonadDb's optimized data access, allows Monad to achieve significantly higher transaction throughput compared to sequential execution, while still guaranteeing correct results that match the expected sequential behavior.

​​Monad is fully compatible with EVM bytecode, allowing smart contracts written in Solidity or any other language that compiles to EVM bytecode to run on Monad without alterations. Developers can transfer their existing Ethereum contracts to Monad smoothly, benefiting from its high performance without the need to rewrite their code.

Furthermore, Monad fully supports the Ethereum RPC API. This compatibility enables existing tools, wallets, and applications designed for Ethereum, such as MetaMask, Etherscan, and Hardhat, to operate on Monad without any adaptations. By maintaining this level of compatibility, Monad ensures that the extensive Ethereum infrastructure is available to its users, simplifying the transition for developers and users alike.

Yes, from a security perspective, the EVM is currently compromised. The overwhelming scale of on-chain exploits and asset losses has significantly hindered the mainstream adoption of blockchain-based solutions, particularly in DeFi, over the past few years.

Here's what the numbers show:

Total DeFi Losses:

• From 2016-2022, the top 50 DeFi hacks resulted in total losses of $5.5 billion.

• In 2022 alone, over $2.598 billion worth of crypto was stolen via DeFi breaches.

• In 2023, funds stolen from DeFi protocols were around $2 billion.

• In Q1 2024, DeFi platforms lost more than $336 million in digital funds.

EVM vs Non-EVM Losses:

• Ethereum, the biggest EVM chain by active users and value locked, experienced the highest DeFi losses in 2023, with about $1.35 billion erased across an estimated 170 incidents.

• BNB Chain, another EVM-compatible chain, lost $110.12 million across 213 incidents in 2023.

• Emerging EVM-compatible network zkSync Era lost $5.2 million in two incidents in 2023.

• In comparison, the non-EVM Solana chain had a loss of only $1 million in a single attack in 2023.

It's hard to see how EVM-based DeFi could become mainstream given the current situation. However, all hope is not lost for EVM. Monad is also enabling developers to make EVM more secure than it is now.

Let's go into the details here:

Security Is Costly on Ethereum

On Ethereum, implementing robust security measures in smart contracts can be very costly due to the high gas prices associated with additional safety checks and computations.

To reduce gas costs, developers often forego additional safety checks, compromising security for efficiency.

Here Are Some Examples of Gas Optimizations Compromising Security:

Limiting Defensive Assertions:

• Defensive assertions are checks that programmers include in their code to ensure that certain conditions always hold true during the execution of smart contracts.

• They are essential for preventing exploits, especially re-entrancy attacks, where a contract may be manipulated into a vulnerable state without triggering any alerts.

• Developers may omit additional defensive assertions, especially with evolving code, to reduce gas costs.

Tricks for Gas Savings:

• Saving gas by using advanced Solidity features or unconventional coding practices often results in less legible and more complex code. 

• This complexity can obscure the code's function, making it harder for other developers and auditors to review, thus increasing the likelihood of oversight and errors.

Patrick McCorry (💙,🧡)

@stonecoldpat0

Due to the gas mechanics in solidity, there is a real financial incentive for developers to write unauditable, difficult to read, and assembly-level code.

Are you writing mission critical code? Stop optimising for gas efficiency, it isn't a great metric for security.

30

11:19 • 13 Jul 2019

Minimizing On-Chain Interactions:

• Practices like requesting infinite ERC-20 token approvals from users to reduce gas costs compromise security by potentially allowing attackers to drain user funds if the app is compromised.

• With approximately $250 billion secured in ERC-20 tokens and NFTs on Ethereum, the implications of compromised security are immense.

Larry Engineer

@larry0x

you can technically approve only .5 WBTC

however, most frontends do infinite approvals so that users only need to approve once, which saves gas

ultimately, the problem lies in Ethereum’s high gas price

3

15:35 • 2 Dec 2021

By drastically lowering the cost of gas, Monad makes it financially feasible for developers to include comprehensive security measures in smart contracts. This reduction means that developers no longer need to make trade-offs between security and cost-efficiency, and can focus on employing the best practices.

Additionally, by reducing the cost barrier, Monad allows for the implementation of more complex and inherently secure protocols that would be too gas-expensive on Ethereum or other EVM-based L1s or L2s. This includes more advanced state management techniques, and integrated error checking mechanisms.

Monad’s economic model also makes it feasible to implement continuous integrity checks and monitoring systems within smart contracts, which can alert developers and users to anomalous behaviors indicative of breaches or bugs.

You also need to keep this in mind: While you can directly port over your EVM contracts, you won't gain any security benefits. To fully benefit from the low-cost execution environment and create more secure applications, you cannot simply copy and paste the existing code. Instead, you must make changes to enhance security, which essentially results in altered code that then requires re-auditing.

But would these optimizations make the Monad version of the EVM the most secure VM out there?

It's highly unlikely because new-generation VMs like Move are far ahead in terms of enabling secure coding, but the Monad EVM could very well be the version that enables the most secure EVM-based application, and that's a big upgrade from the status quo!

The core focus of Monad is to maximize performance and scalability without compromising decentralization and censorship resistance. Taking the rollup path would be a serious roadblock to achieving that goal.

Let me explain:

Current rollup designs do not have a fully decentralized block production mechanism. They depend on a centralized sequencer to order transactions, creating a central point of control and potential censorship risks.

Although there is ongoing research aimed at decentralizing sequencers, achieving this is unlikely in the near to medium term.

By developing Monad as a layer-1 blockchain that employs a proof-of-stake Sybil resistance mechanism with a decentralized network of validators, the system is designed from the start to maintain decentralization without inheriting the limitations of an existing layer.

Monad's custom architecture is built from the ground up for ultra high-performance transaction execution with the pipelined execution model to efficiently process transactions in parallel across multiple cores.

As a Layer1, Monad can make radical optimizations to its consensus mechanism, peer-to-peer networking layer, and storage layer to minimize overhead and maximize throughput.

Implementing these major architectural changes to push the boundaries of performance would be much more challenging, if not impossible, within the constraints of a rollup design built on an existing Layer1.

Another key factor is the limitations and dependencies that rollups inherit from their data availability (DA) layers.

Rollups rely heavily on their DA layer for state verification and data availability. This introduces constraints around transaction costs, capacity, and time to finality.

As an independent Layer1, Monad has more control over its transaction costs and capacity. It is not beholden to the limitations of an external DA layer.

The crypto market is very noisy mainly because DLT is future-oriented technology. Currently, no blockchain-based applications have user numbers comparable to popular web2 applications. Therefore, every team building an L1 or a rollup is creating their solution for the future.

This results in a high volume of competing narratives, each seeking attention and influence. These narratives shape public perception and influence investment decisions because a leaderboard exists in the blockchain space, with coin market cap acting as a leaderboard of blockchain tokens.

Websites like CoinMarketCap rank cryptocurrencies and tokens based on market capitalization, price changes, and trading volume, creating a leaderboard format.

It's undeniable that there is a sentiment that if a L1 blockchain or an application is lower down this leaderboard, these projects or L1s are considered less significant, even if it has nothing to do with the technological fundamentals of this project.

Look at bitcoin, the "digital gold" narrative has captured the imagination of a significant number of people and made it today a 1.2 trillion dollar asset. If you look at the meme coin action right now, you will also see that memes are powerful tools that can capture value

In effect, narratives and memes are powerful tools that could help projects climb the leaderboard ladder and gain maximum exposure. As they say in the crypto space, "numbers going up is the best marketing you can get.", and Monad is leveraging all those tools to create hype for the project.

Monad ⨀

@monad_xyz

Monad Memes of the Week #14

ty: @andalfthegreat, @ratwell0x, @elearachel, @Evoyudhasamael

Monad ⨀

@monad_xyz

Monad Memes of the Week #13

ty: @calvinncandie, @Evoyudhasamael, @fed_febri

503

22:37 • 5 Jan 2024

Monad's current engagement figures are comparable to some of the top 10 L1s (based on CoinMarketCap). This is already a great success from a community building and marketing perspective. And if you look a bit deeper, this comes as no surprise.

Looking at Monad's backers, you'll find some of the biggest names in the blockchain space who understand how the crypto markets work.

This explains why Monad has almost perfected the crypto marketing game. In a market where meme coins outperform L1 tokens with strong fundamentals, community building and spreading the message through memes is a perfect strategy.

Looking at the Ethereum L1, where most of the focus is still on realizing the Rollup-centric roadmap, and there hasn't been much effort to make EVM more performant. The other EVM-based L1s are mostly seen as copy-pastes of Ethereum L1 and lack the grand vision and narrative to aim at what Monad is trying to achieve.

If you look at the Ethereum L2 ecosystem, the protocols have to deal with the current  limitations of Ethereum DA to providing a cheap execution environment or have to depend on centralized sequencers, compromising censorship resistance which is the core philosophy of DLT.

At the same time, Solana, with the current real throughput limitation around 800-1000 tps, limits the capabilities of Solana to keep up with the increasing demand, and it can take a while until Solana brings the next upgrades to improve throughput.

In this situation, Monad is on its path to fill the gap in the market by bringing 10x more than the current throughput of Solana and also using a VM that has the most developer adoption in the whole blockchain space. Along with that, Monad has already built a huge active community.

The biggest bet Monad is making is on the staying power of EVM. Right now, this would seem like the right thing to do but at the same time we are watching the rise of more secure and efficient VMs like Move, and in a scenario where blockchain-based systems have achieved little to no real-world adoption, betting on the staying power of EVM is a big risk that the Monad team is taking.

Could that happen and could Monad be irrelevant in the next 3-4 years of years' time? We don't know that yet, but one thing for sure, Monad is on its way to be one of the biggest L1 launches of this cycle, and with the recent success of Monad devnet, things are working in favor of Monad.

Do you like our Thesis Approach to understanding crypto and blockchain tech?

Then Subscribe to our Newsletter and we'll deliver a Thesis every week straight to your inbox:

Guaranteed spam-free:)

The 2008 financial crisis will be viewed by history as a pivotal moment that not only demonstrated the fragility of the global financial infrastructure but also underscored the disproportionate impact of such systemic failures on ordinary individuals.

From that point onwards, there was a consolidation of efforts from the fringes to create an alternative financial infrastructure that is inclusive and egalitarian by democratizing access to opportunities.

A financial system, where all participants have equal opportunities to participate and benefit, irrespective of their economic status—a beacon of hope for those disenfranchised by the existing financial order.

That's why the philosophical underpinnings of blockchain-based systems are deeply rooted in principles of inclusivity, democratization, and egalitarianism. From Bitcoin to systems like Ethereum, Cosmos, Solana and Cardano these are all attempts to realize one or the other version of that dream.

As much as this attempt has a philosophical base, this journey is also technologically challenging. It's an incredibly arduous task, dependent entirely on yet-to-be-seen technological developments to fulfill that vision.

That's why I think there are a few projects that have been designed from the ground up where the technological roadmap is viable enough to achieve that end state—a financial system that is inclusive, democratic, and egalitarian. Mina Protocol is one such system that has chosen a path far different from the rest of the blockchain-based systems but has immense potential to realize that ultimate vision or what Vitalik calls "The End Game."

Why does Mina Protocol offer one of the most viable paths in achieving that vision?

Here's an article that breaks down the philosophical and technological foundations of Mina Protocol and why Mina, being arguably the only blockchain that's taking a zk-native approach, is one of the strongest candidates in the entire blockchain space to achieve that ultimate vision.

Ethereum is by far the most ambitious project from a technical and philosophical perspective, having created a core idea to become a foundational layer for a new era of the internet—Web3. Its goal is to achieve a revolutionary digital society, one where the core principles of openness, innovation, and inclusivity are paramount.

The "End Game" of Ethereum, as envisioned by Vitalik and the broader Ethereum community, is to evolve the network into a fully scaled, maximally resilient platform that can serve as a powerful tool for global coordination and innovation.

In other words, it's a platform capable of realizing the end-game vision, including unparalleled scalability, robust decentralization, and impenetrable censorship resistance, ensuring efficient, widespread accessibility while safeguarding user autonomy and data integrity.

That's the end state, and to get there, an elaborate roadmap exists that would bring Ethereum to that end state, probably a decade away from now. At the same time, there are projects progressing towards the same end state faster than Ethereum, by leveraging the scalable, verifiable computational capabilities provided by "ZKPs."

Mina is the most prominent, or perhaps the only, project in the entire blockchain landscape that has been building toward this vision, relying on the concept of zk-nativeness.

Scalable verifiable computation in the context of  systems demanding both efficiency and integrity at scale refers to the capacity to handle an extensive volume of transactions with the ability to prove the correctness of these transactions in a manner that is both swift and lightweight.

This concept is paramount in decentralized technologies, where the goal is to support high transaction volumes with security, transparency, and without central points of failure.

Traditional blockchain systems often struggle to balance scalability, security, and decentralization. As these systems aim to rival the throughput of centralized Web2 systems, they encounter bottlenecks that stem from the need to maintain a distributed ledger across numerous nodes, each of which must process and verify the entirety of the data. 

Zero-Knowledge Proofs (ZKPs) offer a compelling solution for scalable verifiable computation, addressing the need for secure, decentralized systems capable of handling vast amounts of transactions efficiently. Verifiable computation aims to allow a verifier to confirm the correctness of computations without executing them in full.

ZKPs enable this by allowing a prover to demonstrate the validity of a statement without revealing any additional information beyond what is necessary to make the verification. This property is incredibly beneficial for scalable systems because it means that even complex computations can be verified quickly and with minimal resource consumption.

The core value of ZKPs in systems that need to scale is their capacity to compress the verification process for complex computations into brief, efficient proofs. These proofs are small in size, making them quick to transmit over the network, and they can be verified efficiently, regardless of the complexity of the original computation.

This efficiency is a breakthrough for scalability, as it allows networks to process and verify transactions at speeds comparable to centralized systems like Visa, but within a decentralized and trustless framework.

By design, blockchain systems benefit from decentralization, enhancing security and resilience against attacks or failures. ZKPs complement this by ensuring that the verification process itself does not become a bottleneck or a central point of failure.

With ZKPs, the computational burden is significantly reduced, and the verification can be performed by any participant in the network efficiently. This feature is critical for maintaining the decentralized ethos of blockchain systems while enabling them to scale to meet the demands of global financial systems and beyond.

The architects of the Mina protocol identified ZKPs as the most viable path towards a decentralized scalable system when it was established in 2017 by O(1) Labs. That’s why Mina had integrated ZKPs into its foundation architecture, or in other words, in every aspect of a blockchain where ZKPs can be leveraged for accessibility, scalability, programmability, and privacy, making Mina a zk-native blockchain by design.

At the core of Mina's design is the use of recursive zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge), which are a form of cryptographic proof that enables the protocol to maintain a constant-sized blockchain, regardless of the number of transactions processed.

zk-SNARKs are a form of ZKPs which enable one party to prove to another that a statement is true, without revealing any information beyond the validity of the statement itself. zk-SNARKs are characterized by their succinctness and non-interactive nature, meaning the proofs are very short and can be verified quickly

Here’s a thread where is describe the concept of zk-SNARKs in detail: Link

Recursion in computer science refers to the process of a function calling itself directly or indirectly, which allows for the efficient solving of problems that can be broken down into smaller, similar problems. When applied to zk-SNARKs, recursion enables the construction of proofs that verify other proofs, leading to a hierarchical structuring of information that can significantly compress the data needed to verify a series of computations.

Recursive zk-SNARKs work by taking the output of one zk-SNARK proof and using it as an input for another zk-SNARK proof. This process can be repeated multiple times, creating a chain or tree of proofs where each subsequent proof verifies the correctness of the previous one. The key to making this recursion feasible is the use of a cryptographic technique known as "proof composition," which allows for the efficient combination of multiple proofs into a single, succinct proof.

Another fundamental element is the bootstrapping process, which involves a zk-SNARK proof validating itself. This is accomplished by designing a SNARK capable of verifying the correctness of its computations, including its own verification procedure.

The bootstrapped proof acts as the foundational element for recursion, facilitating the development of proofs that can recursively verify an indefinite number of computations.

By capitalizing on the inherent conciseness of zk-SNARKs, the recursive approach ensures that the ultimate proof remains compact and can be verified in a constant timeframe, regardless of the quantity of computations it encompasses. This efficiency is vital for enhancing scalability, as it permits the authentication of intricate computation sequences without necessitating a corresponding increase in computational power.

Leveraging recursive SNARKs, Mina aspires to establish a scalable and decentralized settlement layer underpinned by inclusive consensus and zk-programmability.

At the heart of Mina’s design is the principle of ensuring that the blockchain remains accessible and verifiable by anyone, regardless of their hardware capabilities. 

Unlike other blockchains like Bitcoin or Ethereum, where participants must download and verify a vast amount of data to fully engage with the network, Mina's entire blockchain state can be verified quickly and efficiently, regardless of how many transactions have taken place, all within a proof that's about the size of a couple of tweets.

This is achieved through the use of recursive zk-SNARKs, which compress the entire history of the blockchain into a fixed-size cryptographic proof. This cryptographic technique allows Mina to compress the entire history of its blockchain into a succinct, fixed-size proof, approximately 22kb in size, irrespective of the number of transactions processed. 

Here’s how Mina achieves this remarkable feat:

• Recursive zk-SNARKs: They bundle transactions and blocks together into one small proof, making it possible to verify the whole blockchain without needing to store all its data. This not only saves space but also allows for faster and more efficient verification.

• Protocol State: This is essentially a snapshot of the blockchain's current state, including essential information like account balances. It's a part of what gets verified by anyone looking to check the blockchain's integrity, ensuring that users are always interacting with a true and accurate version of the network.

• Non-consensus Nodes: Mina allows for what are called non-consensus nodes, meaning participants who don't create new blocks but can still check the network's state. These nodes don't need the entire blockchain history to verify the current state; they just need the latest proof, a specific account's information, and a way to verify that information (a verification key). And these have full-node security!

• Efficient Data Verification: Each new block in Mina doesn't just carry the latest transactions; it also contains a proof of the transactions and the summarized history up to that point. This allows anyone to verify the entire blockchain from just this new block, drastically simplifying the process.

• Merkle Paths: To confirm account balances without the entire ledger, nodes use what's known as Merkle paths. This technique allows a node to check if an account is legitimate and its balance is correct, based on the summary provided in the blockchain proof, without needing to trust other nodes blindly.

The beauty of Mina's system is in its simplicity and inclusivity. By keeping the blockchain's size so small, Mina makes it possible for anyone, even those with basic smartphones, to participate in the network's security by verifying its state. This not only makes the network more accessible but also strengthens its decentralization and security.

Ouroboros Samasika is a pivotal part of how the Mina Protocol operates, drawing its roots from the Ouroboros consensus algorithms initially created for Cardano.

This consensus protocol is specially designed to maximize inclusivity and decentralization within Mina's settlement layer.

Inclusivity ensures that anyone can participate in the network, regardless of their location or resources, enhancing its resilience, security, and health through diversified contributions, while uncapped participation ensures that there are no restrictions on participating in Mina's block production at any point in time.

Self-Bootstrap: This feature allows new or returning nodes to independently determine the active blockchain chain without relying on external, potentially centralized, checkpointing services. This is crucial in scenarios where two chains of equal length exist due to forks.

Samasika uses a genesis block copy for bootstrapping and employs two chain selection rules based on the age of the fork. For recent forks, the longest chain rule applies.

For older forks, a special rule evaluates a succinct summary of each chain's post-fork state, enabling decision-making with limited information.

This mechanism ensures that all nodes, regardless of their offline duration, can autonomously rejoin and contribute to the network, enhancing decentralization.

Dynamic Availability: Recognizing the variable online availability of nodes, Samasika is designed to accommodate fluctuating participation without compromising security.

It achieves this through epoch-based time division and the use of verifiable random functions (VRFs) to maintain independent randomness across epochs.

This allows for fair block producer sampling relative to stake size, even as stake distributions change, thereby ensuring all nodes have an equal opportunity to contribute, regardless of their intermittent connectivity or power availability. And in Mina the VRFs  are even implemented in a SNARK!

Uncapped Participation: Unlike protocols that limit the number of validators or rely on centralized nodes for efficiency, Samasika imposes no such constraints.

This opens the door for unlimited node participation, sidestepping potential centralization and communication complexity issues inherent in BFT (Byzantine Fault Tolerance) and BA (Byzantine Agreement) protocols.

By not limiting the number of participants, Samasika ensures a truly decentralized network where more nodes can engage in consensus processes, thereby enhancing security and network robustness.

Succinctness: The protocol's design to use only limited local information aligns with Mina Protocol's goal of creating a succinct blockchain.

This approach supports the overarching objective of decentralization by allowing nodes to operate without the need for extensive data from the blockchain's history, facilitating easier participation and verification processes.

Universal Composability: Samasika's security is validated under the universal composability (UC) framework, ensuring that it remains secure even when interacting with other protocols.

This is critical for maintaining liquidity and interoperability between different blockchain systems. By ensuring UC security, Samasika guarantees that its consensus mechanism does not introduce vulnerabilities when Mina Protocol is part of a larger, interconnected blockchain ecosystem.

Basically, Ouroboros Samasika's design principles—self-bootstrap, dynamic availability, uncapped participation, succinctness, and universal composability—collectively ensure Mina Protocol achieves its vision of enabling a lightweight, accessible, and truly decentralized blockchain.

Mina Protocol has also integrated ZKPs into its core programming layer. This integration is manifested through two primary components: the ZK smart contract layer, known as zkApps, and the proof system, Kimchi.

Each of these components plays a crucial role in offering both high-level accessibility for developers and powerful low-level customization options.

zkApps are Mina's implementation of smart contracts that utilize zk-technology to preserve user privacy while enabling complex computations.

These smart contracts allow developers to create applications where users can prove specific facts about their data without revealing the data itself. For instance, a user can prove they are eligible for a financial service based on their credit score without disclosing the actual score.

This capability is crucial for privacy-preserving applications and is facilitated by o1js, a TypeScript library designed for building zkApps.

o1js provides developers with familiar programming semantics enriched with zk-functionalities, including privacy, scalable verification, recursion, and composability.

At a lower level, Mina employs Kimchi, an extensible proof system that supports the generation of recursive proofs, keeping the blockchain's size constant and manageable.

Kimchi is based on PLONK, a universal SNARK with enhancements for better performance and flexibility with recursion at its core. It allows for the creation of proofs of proofs, a feature that significantly contributes to scalability and efficiency.

Developers can extend and augment Kimchi without necessitating a hard fork, thanks to its design that encourages the addition of new, high-performance components as needed.

This flexibility makes Kimchi akin to a "zkCPU," where developers can live-add enhancements to improve the system's capabilities over time.

Mina's architecture is designed to be both accessible and powerful. For everyday development, zkApps provide a high-level interface for leveraging ZKPs in smart contracts, making it easier for developers to create privacy-preserving applications.

On the other hand, Kimchi offers a robust foundation for those looking to dive deeper into the cryptographic underpinnings of Mina or to extend its capabilities.

This dual approach ensures that Mina can serve a wide range of use cases, from simple applications requiring basic privacy features to complex systems demanding extensive customization and optimization.

Mina aims to optimize the performance of its Settlement Layer by improving latency, finality, and throughput.

The goal is to achieve low-second or millisecond latency, instant finality, and hundreds or thousands of proofs settled per second.

To achieve these ambitious goals, Mina is taking a multifaceted approach, which also includes an L2 scalability roadmap similar to Ethereum's:

Recursive ZKPs: Mina has already accomplished the primary step towards optimizing settlement layer performance: Recursive ZKPs.

In Mina, transactions are proof verifications, and each transaction is a recursive proof that can be a zk-Rollup of thousands or millions of recursively bundled transactions.

This allows Mina to scale the number of ZK proofs per second that can be settled on the chain and minimize the time to finality for those proofs.

Hardware Acceleration and Parallel Processing:In parallel, strides in hardware acceleration for ZKPs using cutting-edge technologies like Field Programmable Gate Arrays (FPGAs) and Application Specific Integrated Circuits (ASICs) are being made.

This effort is bolstered by parallel processing for SNARK operations, potentially leveraging FPGAs or GPUs. This multifaceted approach aims to enhance the execution of complex ZKPs operations, such as Multiple Scalar Multiplications (MSMs) and Fast Fourier Transforms (FFTs), speeding up the verification process and reducing latency to improve system performance.

Improving Composability: For better UX, L2 scalability requires seamless composability between those layers, and Mina is working on improving composability between platforms and enabling applications and platforms to connect and build off of each other.

With recursive ZKPs, Mina can realize trustless bridging between chains and provide trustless bridges between Mina and its L2 zk-rollups and zk-App chains and the rest of the space.

This opens possibilities where Mina can also provide private verification of existing real-world data, and with Mina’s efficient verifiability, enable new use cases.

zk-Rollup SDK: The efforts are on track for the development of an SDK designed for creating composable platforms.

This facilitates the straightforward construction of zk-Rollups and zk-AppChains, which are capable of mutually recursive verification, all the while leveraging the security infrastructure of Mina as a foundational settlement layer.

Random Committee BFT: Plans are underway to redesign the consensus mechanism to use randomly selected committees.

This allows the protocol to still enable anyone in the network to participate while achieving instant finality for transactions and increased performance.

Implementing a Random Committee BFT mechanism, where a committee of nodes witnesses a block for consensus, achieves instant finality. Once a transaction is included in a block and the block is agreed upon by the committee, the transaction is considered final.

Optimized Block Production: Reducing block times and increasing the number of transactions per block contribute to achieving more throughput. This requires engineering improvements to enhance SNARKs proving/verification and networking efficiencies.

Efficient Networking Layer: Implementing an efficient networking layer, such as adapting bitswap, reduces the time it takes for transactions to propagate through the network. This is crucial for minimizing latency as it ensures transactions reach validators quickly for processing.

In 2024, the Mina ecosystem will undergo a significant upgrade with the Berkeley hardfork, introducing fully ZK enabled smart contracts, or zkApps, to the mainnet.

This will unlock a plethora of possibilities for both infrastructure and application enhancements within the network, including complex, privacy-preserving computations.

Key improvements with this upgrade will also include performance boosts through reduced slot times and optimizations for validators, enhancing network efficiency and scalability without sacrificing decentralization.

As we look towards a future where there will be seamless integration of blockchain technology into daily life, Mina's approach, with a lightweight, scalable, and user-centric platform, sets a new standard for what is possible.

By enabling privacy-preserving tools and ensuring equitable access to the blockchain, Mina is paving the way for a future where technology serves as a force for good, democratizing access to opportunities and empowering individuals and businesses across the globe.

If you want to listen to a deeper conversation that will take you to the fundamentals of Mina protocol and ZKPs, here's my interview with the CEO of o(1) Labs, Brandon Kase.

DISCLAIMER: None of this is financial advice. This newsletter is strictly educational and is not investment advice or a solicitation to buy or sell assets or make financial decisions. Please be careful and do your own research.

Write anything - from your smallest paragraph to your grandest masterpiece - and publish it online or send it as email newsletters directly to your readers.

Your Paragraph publication is blazing-fast, SEO optimized, and combines the best parts of both web2 and web3 to help you create content and grow your community better than ever.

Getting started

What you're looking at right now is the Paragraph editor. We support markdown, callouts, code, and rich media embeds like Twitter and YouTube.

paragraph.xyz

@paragraph_xyz

On paragraph.xyz, all posts are stored on @ArweaveTeam. This means they're immutable, uncensorable, permanent, and composable

paragraph.xyz

Paragraph | all-in-one publishing & newsletter platform

Create, publish and share web3-native blogs & newsletters.

16

7:12 PM • Aug 18, 2022

When you publish a post, you'll have the option of sending it as a newsletter or storing it in the permanent & uncensorable Arweave.

Helpful links

Here's a few helpful pointers to customize your publication & get the most out of Paragraph:

• Theming & customization. Change your publication's font & colors; truly make this space your own.

• Set up a welcome email. This is the email your readers receive when they subscribe to your newsletter.

• Configure your publication's settings. Add links to your homepage, set up a custom domain, configure Google Analytics & more.

Need help or have feedback?

We've put together some documentation here, but if you still have questions you'd like answered we’d love to hear from you.

You can reach us via email at hello@paragraph.xyz or subscribe to our newsletter here. We're also pretty active on Discord.