Good morning.
I’m Mitsui, a web3 researcher.
Every Saturday and Sunday afternoon, we’ll deliver articles explaining basic vocabulary. We aim to keep each article concise enough for a quick read, while also providing content you can revisit and study.
Today’s topic is “Mempool.”
Please watch until the very end!
Introduction｜Why Ethereum Seems Slow
When you send a transaction on Ethereum, you’ll see the transaction status as “Pending” on the transaction screen. You may have experienced it staying Pending indefinitely, even after waiting 5 minutes or 10 minutes.
Based on these experiences, many people get the impression that “Ethereum is slow.” However, what is actually happening is completely different. Ethereum’s speed itself is fast. The problem lies in the mechanism called the Mempool.
Understanding the mempool reveals the reality that the network isn’t “slow,” but rather has “capacity limitations.” Furthermore, you’ll see that this capacity limitation is actually an extremely rational design. The mempool is the result of transparently visualizing the physical constraints faced by the blockchain.
What is the Mempool? | The True Nature of the Waiting Area
The Mempool (Memory Pool) is a temporary storage location for transactions that have not yet been included in a block. When a user sends a transaction, it does not immediately enter a block. It propagates across the network and arrives at each node’s Mempool. There, it waits for the opportunity to be included in a block.
A key characteristic is that the mempool is not a single entity across the entire network; each node maintains its own independent mempool. This means Node A’s mempool and Node B’s mempool contain different information. In Web2 systems, there is one central “waiting room” where everyone waits their turn. However, in Web3, “countless waiting rooms exist.”
The contents of each node’s mempool are synchronized. By propagating transaction information among nodes on the network, the mempool contents become largely unified. However, they are not completely identical.
A transaction received by Node A may not yet have been received by Node B. This characteristic—where each node operates independently yet remains somewhat synchronized—enables web3’s decentralization.
Equivalent in Web2｜History of Queues
The mempool is not a concept unique to Web3. Rather, it is a phenomenon commonly observed in Web2.
Consider how banks process transfers. When you request a transfer, that request joins a massive processing queue. While a bank’s system handles thousands of transfers per second, it cannot process them all simultaneously. That’s why the processing queue exists. This is essentially the same as the Mempool.
The job queue in cloud computing works the same way. When you send a compute job to a server, it enters the queue and waits for other jobs to finish processing. The same applies to authorization queues in payment systems. In credit card processing, a massive volume of authorization requests flows through the payment network, but they cannot all be processed simultaneously.
So, what is the difference between Web2 and Web3? It’s “who decides the priority.”
In bank transfer processing, the bank determines the priority. Banks set criteria such as “VIP customer transfers take top priority” or “earlier submissions take precedence for identical amounts.” Similarly, in cloud job processing, the cloud provider sets the priority. In Web2, a central administrator completely controls the priority.
In Web3, this prioritization is entrusted to market mechanisms (price). This relates to the Gas Fee, which will be explained in the next section.
Why the Mempool Exists | How to Deal with Physical Constraints
The fundamental reason the mempool exists is simple: the physical capacity of the blockchain is finite.
Ethereum periodically generates blocks. Currently, Ethereum generates a new block approximately every 12 seconds. There is a limit on the amount of data that can be included in each block. For example, suppose a block has a restriction that it can contain “up to 100 transactions.”
However, during peak times, thousands of transaction requests per second reach the network. If 5,000 transactions arrive in 12 seconds, but a block can only contain 100 transactions, where do the remaining 4,900 go? That’s the Mempool. They are gradually processed: 100 are handled in the next block, then another 100 in the following block, and so on.
Furthermore, validators consume computational power when processing transactions. They must perform verification tasks beyond merely recording data—checking whether transactions are valid, account balances are sufficient, and smart contract execution results are correct. All of these constitute computational costs, which are subject to physical limitations.
In other words, the “true resources” web3 provides are not token transfers, but computational power and block space (the capacity for records within a block). The question becomes how to allocate these extremely finite resources. The mempool is where this allocation problem is visualized.
The Relationship Between Mempool and Gas Fee｜Exposing Market Mechanisms
Block space is finite. So, which transactions should be allocated this limited space? Ethereum’s answer to this problem is the Gas Fee.
When users send a transaction, they can decide how much Gas Fee to propose. Validators use Gas Fee as a key criterion when selecting which transactions from the mempool to include in a block. Generally, transactions proposing a higher Gas Fee are prioritized.
As a result of this mechanism, multiple phenomena occur.
During network congestion, everyone wants their transactions processed quickly, intensifying competition for Gas Fees. As a result, Gas Fees skyrocket. Meanwhile, transactions offering low Gas Fees end up waiting for multiple blocks.
The key point is that the mempool is where market forces are directly exposed.
No one manages the validators; each validator independently calculates which transaction is most profitable. Financial incentives determine the priority of all transactions.
This is an extremely unique mechanism not seen in Web2. Whereas in Web2, banks decide to “prioritize transfers from VIP customers,” in Web3, a market mechanism functions where those who pay get priority.
Mempool as the Intersection of Multiple Concepts｜The Big Picture of Web3
The mempool is where several key concepts of the blockchain intersect. Understanding this reveals the structure of web3 as a whole.
Block space is the storage capacity within a block. It is a finite resource. Multiple transactions compete for this limited space.
Gas Fee is the “price” in this competition. When space is limited, those who pay a higher price are prioritized.
Validators have the authority to choose which transactions to include in a block. To maximize their profits, they select transactions with higher gas fees.
MEV is a phenomenon that only occurs because we can observe the mempool. Validators see transactions in the mempool and realize, “If I execute my own transaction before processing this one, I can profit.” They then execute it. Without mempool transparency, MEV would not exist.
In other words, the mempool is not merely a “waiting area,” but rather a crossroads where all key concepts—block space, gas fees, validators, and MEV—converge.
Challenges Posed by the Mempool｜The Price of Transparency
The existence of the mempool and its transparency create multiple challenges.
Front-running is the act of observing transaction information displayed in the mempool and sending one’s own transaction before it. For example, a validator who sees a large sell order displayed in the mempool can insert their own transaction (to buy that asset) before the sell order, thereby profiting from the resulting price movement.
Sandwich attacks are even more malicious. They force losses onto users by inserting their own transactions before and after the user’s transaction. For example, upon finding a swap transaction (exchanging A for B), they insert their own swap before it to cause rate fluctuations, worsening the user’s exchange rate, and then profit from their own transaction afterward.
Transaction experience also becomes opaque. Users are left wondering why their transaction keeps waiting despite high gas fees, or why it suddenly failed.
However, there is an important perspective here. These are not “defects,” but rather “realistic side effects” of distributed networks.
The absence of a central authority is precisely what enables the transparency of the mempool. At the same time, that transparency makes front-running possible. This is a trade-off. If transparency were completely lost, front-running would cease, but so would the fundamental value of the blockchain. Web3 consciously accepts this trade-off.
The Essence Revealed by the Mempool｜A Design Philosophy That Doesn’t Hide Constraints
The mempool demonstrates that blockchain is not an “instantaneous, magical entity,” but rather a computational system with physical constraints.
Computing power is finite. Storage is finite. Network bandwidth is also finite. It is technically impossible to process every transaction instantaneously. Web2 systems share these same constraints, but a central administrator hides them. Banks promise customers that “transfers are reflected immediately,” internally concealing the queues.
The design philosophy of Web3 is different. Ethereum did not hide this constraint; instead, it made it public. That is the mempool. Every user can see for themselves where their transaction is and when it will be processed. This complete transparency is a core value of Web3.
At the same time, this transparency enables front-running and sandwich attacks. However, web3 embraces this not as a security vulnerability, but as a “result of design choices.” Multiple scaling solutions (such as Layer 2) are being developed for a better future, but these too are extensions of the same design philosophy.
Understanding the mempool makes it clear that all of Ethereum’s seemingly strange behaviors are not “bugs,” but “design outcomes.” Slow, unstable, complex—all of these can be seen as the result of web3 choosing “transparency,” “decentralization,” and “autonomy.”
Disclaimer：I carefully examine and write the information that I research, but since it is personally operated and there are many parts with English sources, there may be some paraphrasing or incorrect information. Please understand. Also, there may be introductions of Dapps, NFTs, and tokens in the articles, but there is absolutely no solicitation purpose. Please purchase and use them at your own risk.
About us
🇯🇵🇺🇸🇰🇷🇨🇳🇪🇸 The English version of the web3 newsletter, which is available in 5 languages. Based on the concept of ``Learn more about web3 in 5 minutes a day,'' we deliver research articles five times a week, including explanations of popular web3 trends, project explanations, and introductions to the latest news.
Author
mitsui
A web3 researcher. Operating the newsletter "web3 Research" delivered in five languages around the world.
Contact
The author is a web3 researcher based in Japan. If you have a project that is interested in expanding to Japan, please contact the following:
Telegram：@mitsui0x
*Please note that this newsletter translates articles that are originally in Japanese. There may be translation mistakes such as mistranslations or paraphrasing, so please understand in advance.