Monad is an EVM compatible L1, and expected to have a throughput of 10,000 TPS. So, you’re thinking, just another L1, right? Not really. Monad uses multiple different foundational pillars to be this efficient. We will go through each one of them in this blog.

1. MonadBFT: this is the consensus mechanism used by Monad for achieving consensus (duh) about the txn ordering under partially synchronous conditions in the presence of Byzantine actors. What the hell is BFT? In very short terms, Byzantine Fault Tolerance (BFT) uses a consensus algorithm that prevents double-spending, censorship and DOS attacks. It requires a certain percent of nodes in the network to agree on a txn before that txn is added to the blockchain. MonadBFT is a derivative of HotStuff, which is a leader-based BFT replication protocol. HotStuff basically enables a correct leader to drive the protocol consensus at the pace of actual network delay (called responsiveness). It is very well explained in the 2019 research paper which you can find here: https://arxiv.org/pdf/1803.05069.pdf

   MonadBFT operates in a two-phase pipeline manner, featuring optimistic responsiveness. It typically has a linear communication cost, but this can increase to quadratic in scenarios where a timeout occurs. Similar to other BFT protocols, it involves a process where, in each phase, a leader dispatches a signed message to voters. These voters then forward their signed replies to the subsequent leader. The use of pipelining permits the inclusion of the quorum certificate (QC) or timeout certificate (TC) for a given block `k` within the proposal for the next block k+1. I will not bore you with how the consensus protocol actually work, but in general MonadBFT is a “pipelined consensus mechanism” which goes in rounds. The general idea of going into rounds is basically that for every 3 "bad" nodes, you need at least 1 "good" node. This ensures that the majority of the nodes are reliable. A block is only considered final and part of the chain if the following round's block also gets agreed upon. This makes sure that even if a leader was bad and only sent the proposal to some of the nodes, the block doesn't become final until the next block is also agreed upon by everyone. If a leader acts badly, either by proposing something that doesn't follow the rules or by not proposing to enough nodes, enough nodes will notice and trigger a timeout. This leads to the creation of a TC (Timeout Certificate), alerting the next leader that there was an issue. There is another term called QC, which is basically a Quorum Certificate and is derived by aggregating (via threshold signatures) YES votes from 2f+1validators.

2. Shared Mempool: Validators have a mempool where user transactions await inclusion in a final block. To efficiently distribute these transactions to other validators, they're fragmented via erasure coding and shared through a broadcast tree, streamlining the process. But, MonadBFT efficiently reaches consensus but transmitting large data blocks strains validator bandwidth. For example, a 5 MB block from 10,000 transactions requires significant bandwidth. To reduce this, block proposals use transaction hashes (32 bytes each) instead of full txns, significantly cutting data transmission size. Validators must have the transactions in their mempool for verification during voting and block finalization. Like pending transaction sharing, submitted transactions are distributed to other validators through erasure coding and a broadcast tree, enhancing efficiency.

3. Deferred Execution: The main idea here is that Monad has separated out the execution and consensus. This essentially means that the leader suggests a sequence before understanding the final outcome or state, and the nodes that check for correctness cast their votes on whether the block is valid or not, even without knowing details like whether all transactions in the block will be completed successfully without any need to undo them. It’s done by something that is currently limited. When transactions are arranged in a specific order, the final outcome or state becomes predetermined. Discovering the actual state requires executing these transactions, but their outcomes are fixed once the order is set. Using this as a leverage, Monad eliminates the need for nodes to execute transactions before reaching an agreement. The consensus among nodes focuses solely on establishing the correct sequence of transactions. Each node then processes the transactions in block N on its own while simultaneously working on achieving consensus for block N+1.

   This approach allows for the allocation of the entire block time to the gas budget, as the only requirement is that transaction execution keeps pace with the consensus process. Moreover, this method is more adaptable to differences in processing times since the execution needs only to match the consensus rhythm on average. At the same time, in MonadBFT, finality is single-slot (1 second), and execution outcome will generally lag by less than 1 second for those using a full node.

4. Parallel Execution: In Monad, txns are executed in parallel using optimistic execution, which initiates the execution of subsequent transactions before earlier ones in the block are fully completed. This approach can occasionally lead to incorrect executions, although such instances are rare. To address potential discrepancies, Monad carefully monitors the inputs and outputs during transactions. For example, if the outputs from txns 1 do not match the expected inputs for txns 2, Monad re-executes with the correct data, ensuring accuracy by sequentially merging the updated states for each txn. To optimize this process, scheduling plays a crucial role. A straightforward application of optimistic execution might attempt to execute the next transaction as soon as processing resources become available. However, this could lead to inefficiencies, especially when transactions within a block depend on the outcomes of previous transactions, creating long "chains" of dependencies. Executing these dependent transactions in parallel could cause many failures. To circumvent this, Monad employs a static code analyzer to identify these dependencies in advance, strategically scheduling transactions only after their prerequisites are met. This proactive approach minimizes wasted effort by ensuring transactions are executed in an order that respects their inter-dependencies. In scenarios where predicting dependencies is challenging, Monad defaults to a more basic execution strategy, striking a balance between efficiency and practicality in transaction processing.

5. MonadDb: It is a “custom database” for storing blockchain state. According to Monad, Eth’s MPT data structure approach is sub-optimal because one data structure is embedded into another data structure of a different type. However, Monad implements a Patricia Trie data structure natively, both on-disk and in-memory. What does this mean now?

   Monad processes several transactions at the same time. When a transaction requires fetching data from the storage, it's inefficient to halt and wait for this data retrieval to finish. Instead, the system should request the data and then proceed to handle another transaction while the data is being fetched. This approach necessitates the use of asynchronous input/output (async I/O) capabilities for database operations. Traditional key-value databases are not fully equipped for efficient async i/o, although there are ongoing efforts to enhance this functionality. MonadDb, on the other hand, effectively leverages the most recent developments in async I/O support provided by the operating system. This advanced utilization means there's no need to create numerous operating system threads just to manage waiting i/o tasks, allowing for smoother and more efficient asynchronous operations. Let’s understand what is async I/O real quick. Async I/O is basically input/output processing that allows CPUs to continue executing concurrently while communication is in progress. The reason why CPU is used because a CPU can initiate these operations faster than SSDs or Networks if it knows that a certain instructions don’t depend on the result of I/O operation. Here is a quick comparison between different devices provided by the Monad’s documentation:

Wrapping all of it, and thinking about what Monad is building, it really looks that they are looking to get a hyper-scaled EVM compatible L1. Using techniques like pipelining, async I/O, MonadBFT etc, I personally think that they can push past limits and build a great L1. A bigger thing about Monad is the community of Nads and Purple Pepes. They are everywhere, they are excited about Monad launching and they are constantly in the discord server talking, making friends, and making dope memes and driving the content. While we still don’t know how everything will work out when mainnet launch, I am excited about the future of Monad and its team.

That’s all for today. If you like this, feel free to follow my blog and like this post! Thanks my fellow Nads!

The hype was rather interesting. Devs who understood JS/TS stack and a bit of solidity hyped the position as something where you are engaging with community, going to events, being a speaker, and earning a 6 fig salary while sitting in your home country and doing minimum coding. Any new dev coming to the web3 space or a college student will think that they are qualified after hosting a few events and building basic dapps and doing some basic coding. However, I think the reality is far from it. We will break down both good and bad.

Some good things: a basic DevRel job is to engage with the devs, projects, and companies to foster good relationships, take feedback and give it to engineering team. it's also fascinating because you get to organise events, speak at them and get content for your twitter. But this also involves some bad points: -Companies and teams don't know what they want -you don't have real KPIs and metrics -You are not coding "actively" -you are part of marketing team, content creation and other 10 billion things. the issue: it creates more grifters.

ouch. Naruto wdym grifters? How can a real job at a real company have grifters? Let me break it down for u. a lot of times, companies are looking for a face on twitter for their company. The problem is that they are trying to find a needle in a haystack.

A lot of these devrels either dont get time to code or willingly dont code at all. It depends on the company's needs and wants ofcourse, but devrels look at the job position from a BD POV rather than a dev POV. your number one job as a devrel is to code. At least 50% of the time. If you're engaging with community 100% of the time and going to an event every month, are you even a dev? Sure, you are not getting the time, and you tell the world that you wanna code more, but have you told this to your company? Hence, Deciding weather devrel is a BD or tech is imp.

In 2023, a devrel told me that he has been in crypto/web3 for 5 years. And my inner thought was, "doing what?" Were you coding? talking to people? managing projects? trading? I stalked them, and the answer was: nothing. If you are coding for 5 years in crypto, you are a dev. if you are talking to people, you are a BD/community manager. if you are managing projects, you are a PM if you are trading, a trader. Very simple dynamics. I look up their github, and they have 12 repos. Grift. I have seen college students having more web3 repos than someone with 5 years in crypto, This is true for a lot of devrels that I have seen in the course of 4 years. There are devrels who's github has minimal activity, and the ones who don't understand solidity well.

This doesnt mean everyone is like this though. I have seen some great devrels, who i respect and am friends with. Wouldnt name or show favoritism, but there exists a true class of devrels. The hustlers, everything doers, builder mindset and kind. I admire them. So essentially, the whole devrel grift comes to two certain questions: 1) Are you a dev? 2)Do we expect devrels to code? Then the whole events shenanigans is a different topic. Should devrels be in charge of hosting events? Why do you have marketin/ops team then?

Events is a fun thing and need a separate thread in itself. But if devrels take events as their main persona, then it's a red flag. You cant be doing 20 events a year, and portray that u can ship. But maybe that's part of the job? Where do you draw the line? In essence, the whole devrel ecosystem needs have huge reforms. From devrels to companies to community's expectations, there needs to be a clear path and vision. For me an ideal devrel would be: someone who codes 60% of the time, and puts other 40% in everything else. This does overwork people though. I agree. You can't be doing content creation + videos + blogs + events + codes + engaging with projects and community. But you can also not have either one or two of them and make all of it your persona. There needs to be a balance.

And regardless, the balance needs to be inclined towards coding. Because if you lose your coding skills, and the second you are not needed at a company, you'll find yourself in a tough job market. Regardless, I still think it's a great position. Just very wrongfully hyped. I am not pointing out anyone specifically. Never. All of the devrels put in their best according to their best abilities. I like everyone's work in the space. But, I still believe that there needs to be more focus on coding and researching part for devrels.

Come in =nil; sharded zkRollup – this is a complete game-changer for devs and web3 as a whole as =nil; scales Ethereum through a protocol-level parallel transaction when execution. =nil; leverages horizontal scaling which reduces liquidity fragmentation created by hundreds of other rollups at the moment. The other important part is that there is direct Ethereum data access to L1 data from L2 data, which ensures a more unified and seamless environment than the other current rollup designs. We are going to take a deep dive into the tech but let's discuss the benefits of using =nil; zkRollups first.

1. Scalability: zkSharding promises no scalability limits with parallel execution, boasting impressive throughput capabilities, approximately 60,000 ERC-20 TPS

2. Security and Liquidity: It ensures a holistic security and liquidity model across shards, minimizing the need for liquidity migration and offering transparent access to Ethereum's data.

3. Decentralization and Security: Leveraging Ethereum's staking mechanism and a competitive proof market, zkSharding offers a decentralized, secure, and efficient framework for smart contract execution.

4. Enhanced Functionality: With features like a Type-1 zkEVM fully compatible with EVM bytecode and tailored environments for complex applications, zkSharding caters to a broad spectrum of smart contract applications.

Let’s get into a bit of technical details on how =nil; does it and what the zkSharding looks like. ZkSharding for =nil; is based on some big ideas: zkLLVM. a Placeholder proof system, crypto3 and a Proof Market:

1. zkLLVM is a circuit compiled to translate high level languages, such as C++ and Rust, for circuits for proof systems. By enabling algorithms to be compiled directly without relying on a specialized Domain Specific Language (DSL), it eliminates the need for code duplication and simplifies the development process. zkLLVM's architecture bypasses any intermediary layers, such as zkVMs, linking the algorithm and its final circuit representation more closely. This approach not only minimizes the circuit's size but also speeds up the computation's proving time. The compiler also allows for the direct manipulation of the circuit representation, enabling the generation of optimized verifier code suited for specific virtual machines, thereby boosting efficiency and performance. Built on the LLVM infrastructure, zkLLVM ensures wide-ranging compatibility with extensions based on LLVM IR, providing developers with flexibility and expansive application potential.

2. Placeholder Proof system is a modular framework for Incrementally Verifiable Computation (IVC) that leverages a PLONK-inspired proof system, offering tailored adjustments to meet the demands of specific applications. Its design allows for variations in underlying fields, enabling the shift from standard 256-bit to 64-bit fields for non-cryptographic algorithms, optimizing proving and verification times. Placeholder's modularity extends to the selection of commitment schemes, offering a balance between the need for trusted setups and verification costs, and the use of different lookup and gate generation techniques to minimize overhead and enhance efficiency. This flexibility makes Placeholder adept at reducing L1-layer confirmation times and accelerating zkBridge data provision through quicker generation of IVC-based zkVM and Ethereum consensus proofs, showcasing its potential to adapt and improve blockchain verification processes.

3. Crypto3 is a C++17-based modular cryptographic suite designed to foster innovation in cryptographic research and development.

4. Proof Market is a decentralized platform designed to decentralize the task of zkProof generation by connecting those in need of hardware-intensive proof generation with independent entities such as professional hardware operators, equipment owners, and circuit/hardware designers. It creates a dynamic marketplace where hardware operators meet the demand for proof generation, attracting substantial user engagement and incentivizing large-scale operators to maximize resource utilization. This competitive environment pushes proof producers to optimize their operations, either by scaling infrastructure to benefit from economies of scale or by refining hardware for enhanced efficiency. Producers who manage to offer competitive pricing and rapid service can gain market dominance, encouraging continuous improvement among competitors. Through Proof Market, =nil; zkSharding leverages decentralized proof generation from the outset, clearly separating the roles of validators and proof generators, thereby ensuring efficiency and scalability in its operations.

This is how the Trustless transaction processing work between Main shard, secondary shards, Proof Market, and Ethereum. This Novel mechanism helps in keeping =nil; zkrollup scalable, secure and trustless:

One great question that comes up in mind is how does zkSharding work? zkSharding is the crux of =nil; foundation’s rollup. =nil; uses something called Dynamic sharding where each shard interacts with other shards within the framework of a unified protocol. We have one primary shard that holds the key data about the protocol’s consensus and its current parameters. This primary shard synchronizes and consolidates data from the secondary shards, and also sets the protocol's rules and parameters. The secondary shards have the responsibility to work as “workers”, executing user transactions, and finally, these shards maintain said unified liquidity and data through a cross-shard messaging protocol. Here’s how Cross-shard messaging protocol looks like:

How does it work among shards? A table is defined for a minimal data unit, and an account is characterized by its address and its source code. Each of these secondary shards manages a subset of tables (accounts) and are defined by a deterministic function FS : (pk Mshards) -> idshards . These shards are maintained by a group of validators called committees and are responsible to run a local consensus algorithm to ensure consistency in the shard’s state. There are conditions to be met for dynamic sharding such as “Split Condition” and “Merge Conditions,” which are basically conditions looking for a shard’s block occupancy at its capacity or below capacity respectively.

The advantage of these shards is that the cross-shard communication is done because it’s integrated directly into the protocol rather than being managed by separate bridges. This prevents the data fragmentation on the protocol level, and each committee helps in keeping the cross-shard communication alive through their additional tasks like cross-shard messages within near shards which are determined on the basis of Hamming distance in shard identifiers. At the same time, to maintain consistency and transaction processing time, the protocol relies on “Colocation technique,” which basically ensures that two accounts { pk1 , pk2 } are consistently located within the same shards. So this means we can say that: Fs(pk1Mshards) = Fs(pk2, Mshards) for every possible value of Mshards. Here is an image of explaining how Parallel transaction execution work with =nil;

Finally, we will quickly talk about =EVM++; which is enhance for efficient execution of general purpose algorithms of EVM. It is made for highly optimized state transition proof generation through zkLLVM. =EVM++; is based on three key properties. Firstly, it ensures binary compatibility with existing EVM applications, meaning any application run on =EVM++; will produce the same output as if it were executed on a standard EVM, preserving the integrity and expected outcomes of applications. Secondly, it expands the execution capabilities to include general-purpose programming languages like C++ and Rust, enabling the deployment of complex applications not traditionally suited for blockchain environments, such as shared sequencers. This is facilitated through modifications to the EVM's architecture, including a more versatile set of opcodes that form a superset of the original EVM opcodes, the introduction of opcodes for efficiently handling memory blocks smaller than 256 bits, and adjustments to reduce the limitations of the EVM stack, such as allowing infinite stack depth with manageable gas implications for deeper stacks. Additionally, it incorporates new control flow commands for enhanced programming flexibility. Lastly, =EVM++; focuses on efficient state transition proof generation by aligning its opcode set with zkLLVM, optimizing for both traditional blockchain applications and more general-purpose computing tasks. This approach not only maintains compatibility with existing blockchain applications but also opens up new possibilities for blockchain technology application, making it a versatile and powerful tool for developers.

There are other things to consider here like Type-1 secure zkEVM which is not much different from other zkEVM implementations. It has two types of proofs: the State Proof that ensures that operations are performed correctly, and the EVM proof which confirms that the State Proof selected the correct data location. When it comes to the Data Availability layer for L2 solutions, it varies between the main shards and secondary shards. The main shard employs Ethereum as its DA whereas the secondary shards have an option to use Ethereum or to choose another DA like Celestia or Avail Project. The system begins with two types of shards: those with Data Availability (DA) and those without. Only shards within the same DA category can merge, requiring accounts to be assigned to a specific DA category from the start. This setup can later incorporate additional DA types. Utilizing Ethereum as the DA layer offers a cost-effective solution for storing the data necessary to recover Layer 2 (L2) states by using transaction calldata, benefiting from lower storage costs due to its non-persistent nature. This approach ensures data from shards is archived, with metadata maintained for easier access and retrieval. A shard's state is deemed finalized once its corresponding transaction on Ethereum is completed. DA transactions are divided into two segments: the payload for state restoration and metadata for shard identification, with the understanding that the payload, generally not needing direct access, can be archived.

Let’s finally look at it from the end user (developer’s) perspective. A regular developer is interested in direct access to Ethereum data which is based on the Data Provider module within the protocol’s node. Even after all the pieces like zkBridge and =EVM++; coming together, accessing Ethereum data does not differ from any other calls within the original ethereum network This is accomplished by differentiating between traditional Ethereum addresses and =nil; zkSharding addresses within the =EVM++;. When =EVM++; instructions interact with addresses, they determine if the address is part of the Ethereum Network. If so, =EVM++; fetches data from the Data Provider module, bypassing the original database. This is how data access looks like in a diagram:

Key takeaway for all developers building on top is that =nil; is using zksharding to build one of the most composable and scalable Ethereum L2 zkRollup. Using zkLLVM along with crypto3, devs can generate input for any arbitrary ZKP system or protocol, which eliminates the need to write any code in a specific DSL or libraries. Similarly, developers can use Proof Market Toolchain which provides tools for proof requestors and producers and is a game changer for incentivizing proof generations and selling while being reliable and less costly. Everything that =nil; is currently doing will shape up the future of scaling ethereum while keeping developers in the community, getting constant feedback, and to make the whole developer experience very seamless, so that developers don’t have to learn multiple DSLs or new tech!