# Bringing MMB to Polkadot


*By [Alfonso Cevallos](https://hackmd.io/@MerkleMountainBelts/MMB-Funding-Proposal-V3#Alfonso-Cevallos). This blogpost presents a simplified explanation of our proposal on Polkadot's [ref. 1667](https://polkadot.polkassembly.io/referenda/1667). Please keep in mind many concepts are presented loosely for the sake of simplicity. Check out our [full proposal](https://hackmd.io/@MerkleMountainBelts/MMB-Funding-Proposal-V3) for a more rigurous presentation.*

## 1. The problem

Polkadot was conceived as a platform with a strong focus on **interoperability**. This is how it was described to me in 2019, when I started working in this community. And in 2025, Polkadot continues to be called [interoperability's poster child](https://www.thestandard.io/blog/polkadot-dot-interoperabilitys-poster-child---2025-network-analysis).

Now, the focus on interoperability can be understood both **internally** -- making sure it’s easy to move data and tokens across the different parachains and Dapps within the network -- as well as **externally**, reducing the costs of communication bridges to and from other networks. We hope that, in the near future, whenever the Ethereum user Alice is curious about trying out a Dapp on Polkadot, she can move some funds back and forth cheaply and in a trustless manner. And once inside Polkadot, she might choose to stay :smiley:.

We're halfway through in making this vision true. Since last year, we finally have fully decentralized and trustless **bridges**, such as Snowbridge and Hyperbridge. However, they remain **very expensive** to use. Sending a message from Polkadot to Ethereum via one of these bridges typically costs over 10 USD in gas fees.

Which is why many users opt for **centralized** alternatives such as exchanges to move funds around. Alice may care about decentralization, but only if the price is reasonable. Worse, she may never get around to trying out that Polkadot Dapp she was curious about!

## 2. The proposal


*Using decentralized bridges is like buying organic food: Alice knows it's the right choice, but a little discount certainly helps!*

We can reduce by **more than 1 USD** the average gas fee of a transaction from Polkadot to Ethereum, in bridges like Snowbridge and Hyperbridge. Assuming that at least one of these bridges has a [reasonable volume](https://hackmd.io/@MerkleMountainBelts/MMB-Funding-Proposal-V3#Total-savings) in the future, this translates to yearly USD savings between **6 and 7 digits** for the Polkadot community.

To see how we can do this, let's first consider a typical transaction over one of these bridges. If Alice wants to move funds from Polkadot to Ethereum, she might send a message that reads "I just sent one wrapped ETH from my account to the bridge smart contract on the Polkadot side five minutes ago, so please go ahead and release one ETH from the bridge smart contract to my account on the Ethereum side".

Of course, the Ethereum smart contract does not necessarily trust Alice, so it needs an **authenticity proof**: a proof that the Polkadot-side of the transaction was actually executed. **We can make this proof considerably shorter**. In turn, this shortens the overall transaction (message + proof) being sent to Ethereum, resulting in less gas fees.

## 3. Authenticity proofs


*All transactions that have ever been executed on Polkadot form a digital book, that validators maintain and sign.*

Polkadot has been producing blocks since 2020 at a rate of 10 blocks per minute (here and in the rest of the blogpost, we only make references to relay-chain blocks). All of these millions of blocks, and the hundreds of millions of transactions within them, form a **giant digital book** or ledger. Acting as both notaries and accountants, validators maintain this book, keep it up to date, and sign onto it from time to time. Their signatures are a guarantee that all transactions contained in it have been correctly verified and executed.

An authenticity proof (a.k.a. Merkle proof) is simply a proof that a particular transaction actually appears somewhere in this book. This raises a technical challenge:

**How can you efficiently verify that a digital book has been signed by someone, and contains a particular statement, without having to download the full book?**

Hint: the answer has to do with **hierarchical trees**.


*An example of a hierarchical tree to organize files. My files look almost this organized, except for a folder called* "¯\\\_(ツ)\_/¯" *where I keep 10-years worth of random stuff.*

A hierarchical tree is what you typically use to organize files in a computer. We can think of it as an inverted tree: files are the leaves, each folder is a branch holding together a bunch of sub-branches or leaves, and finally the root is the main folder that contains everything.

Such a tree helps you group items logically, and also assign **references** to items. For instance, in the tree above, I can give to someone the reference
> Documentos\Finanzas\Reportes\Trimestrales\Q1_2025.pdf

which consists of the path from the root to a leaf in the tree, naming every branch along the way. The recipient can use it to quickly find the referenced item, starting their search from the root, much faster than doing a brute-force search.

## 4. The BEEFY tree


*The leaves of the BEEFY tree are the millions of finalized blocks, and its root is the starting point of any reference. By signing its root, validators approve the whole tree.*

A similar structure is used for Polkadot's giant book: transactions are maintained in hierarchical trees within every block, and in turn all the millions of blocks form the leaves of a single tree, which we call the **BEEFY tree**, as it is maintained in the [BEEFY protocol](https://spec.polkadot.network/sect-finality#sect-grandpa-beefy).

For technical reasons, every branch of the BEEFY tree may contain at most two sub-branches (it is a binary hash tree) so it is indeed an enourmous tree. Yet, currently each block is only about 25 branches away from the root (the power of logarithmic growth!). From time to time, validators update this tree with new blocks, and sign its root.

Now we can see that an authenticity proof simply consists of
- the validators' signatures on the BEEFY root,
- a path from the root, passing by a block, and ending in a transaction, and
- a proof that each branch along this path actually contains the next sub-branch.

## 5. The current structure (MMR)


*The authenticity proof for leaf 6 proves the existence of all the colored branches. MMR builds a well balanced tree, where all leaves are equally far from the root.*

In order to maintain the BEEFY tree, validators currently use a data structure called **MMR**. It is a relatively new invention, simple and elegant, with two main features:
- it is fast to update whenever a new block is created and, more importantly,
- it keeps the tree **balanced**, so that all blocks are (roughly) equally far from the root.

This makes sense intuitively, because the farther a block is from the root, the longer the authenticity proofs will be for the transactions in that block. Hence, this is a fair policy that tries to keep all proofs equally long and equally expensive.

*However, the most fair and elegant solution is not always the optimal one*.

## 6. Our new structure (MMB)


*Like old politicians, MMR promises to treat all blocks equally. Our MMB political party is more modern and pragmatic: it offers a "slightly unbalanced" treatment.*

If all transactions that have ever been executed in Polkadot were equally likely to be queried today, then the current MMR structure would be optimal. **But this is not the case!** Newer transactions are queried by users much more frequently than older ones. And this is a consistent and heavily marked tendency: the great majority of user queries are for transactions less than one-day old (see Figure 3 in [this paper](https://www.nature.com/articles/s41597-022-01254-0.pdf)).

This is why we propose a new data structure, **MMB**, that places **newer blocks** (those on the right-hand side of the trees in the image above) **closer to the root**.

In fact, in MMB the distance of a block to the root depends **only on its age**, as opposed to in MMR, where this distance depends on the total number of blocks. For instance, as Polkadot currently has about 27 million blocks, a balanced tree would place any block at a distance of roughly **25 branches** from the root.

| Age of a block | Distance from root (measured in branches) |
| -------- | -------- |
| 1 minute | 7 |
| 5 minutes | 10 |
| 1 hour | 15 |
| 1 day | 21 |
| older | at most 38% longer than with a balanced tree |

In contrast, we see in the table above that MMB gives **much shorter distances** to recent blocks. Older blocks end up a bit farther away, but they are queried so rarely that the trade-off is totally worth it.

For instance, in the example of Alice's use of a cross-chain bridge, how long will she typically wait from the moment she makes a transaction on the Polkadot side, until she sends a message (along with an authenticity proof) to the Ethereum side of the bridge? It will rarely take longer than an hour, so she will love the savings offered by MMB!

## 7. Conclusions

MMB is a novel data structure that minimizes the expected size -- and related costs -- of a transaction's authenticity proof, by **tayloring the shape of the BEEFY tree** to the users' actual behavior, instead of treating all blocks equally.

This is similar to the use of [cache memory](https://en.wikipedia.org/wiki/Cache_replacement_policies#:~:text=Caching%20improves%20performance%20by%20keeping%20recent%20or%20often%2Dused%20data%20items%20in%20memory%20locations%20which%20are%20faster%2C%20or%20computationally%20cheaper%20to%20access%2C%20than%20normal%20memory%20stores.) in a computer: recently opened files and programs are given preferential treatment, by being stored in a part of the computer that is cheaper to access. Since users are more likely to come back to these recent files than to open an old file, the overall user experience is improved.

Here are other features of MMB:

- **Generic solution**: beyond our example on bridges, users of most applications observe the same **recency bias** in their queries. Hence, most applications (if not all) will benefit from MMB. Examples are: XCMP for communication across parachains, or Alice checking on her phone if her NFT purchase is confirmed.
- **Faster updates**: after adding a new block, updating the tree is even faster with MMB than with MMR.
- **Faster re-syncs**: many re-sync operations, such as updating a leaf's authenticity proof after the tree was updated, are also faster with MMB than with MMR.
- **ZK-friendly**: the fact that MMB offers **constant-sized proofs** for recent blocks (independent of the total number of existing blocks) makes it particularly friendly to some ZK applications that require **constant-sized circuits**.

Finally, we mention that MMR has become a popular data structure in academia, particularly in the very active research area of light-client protocols for blockchains. A quick Google Scholar search shows that in 2025 alone, there have been 15 research papers that mentioned MMR. We strongly believe that in most use cases given to MMR in academia, MMB would perform even better (for instance in [FlyClient](https://ieeexplore.ieee.org/abstract/document/9152680), used by [Zcash](https://electriccoin.co/blog/explaining-flyclient-2/)). Hence, we expect that our MMB paper will have a **strong impact in academia**.

---

Thank you for your interest in the MMB data structure and in our [referendum](https://polkadot.polkassembly.io/referenda/1667)! If you'd like to know more, please check out our [full proposal](https://hackmd.io/@MerkleMountainBelts/MMB-Funding-Proposal-V3), and contact us via [Telegram](https://t.me/+b-a0VFO1NZVhZDE0)!