> **MMB TLDR:**
> The MMB data structure works as a plug-in replacement for MMR, to produce BEEFY commitments which, among other use cases, are employed by the DOT🡘ETH bridges to authenticate messages. Over the next 5 years, MMB would [reduce the average authentication proof size of messages by over 40%](https://docs.google.com/spreadsheets/d/1PRea58H84NpxHeJirpl8KUikfqFLYvVr8l70OFrTxX4) compared to the current implementation with MMR. From our gas and cost estimates, this corresponds to approximately 1.10 USD of savings per transaction for bridge users, adding to six or seven digits of yearly savings for the community, and encouraging the onboarding of new users into Polkadot. Beyond bridges, MMB has multiple other potential applications, where it will reduce the authentication proof sizes (and hence costs) compared to using the MMR structure.
> 
> This post introduces a [follow-up proposal](https://hackmd.io/@MerkleMountainBelts/MMB-Funding-Proposal-Scope-Cut-Against-Original-Referendum) to [referendum #1317](https://polkadot.polkassembly.io/referenda/1317), and we welcome community feedback on our new roadmap.

We've learned much from our first proposal attempt at OpenGov.

We participated in public discussions, answering questions from the public. We negotiated with tech leads from the key teams that would benefit from our proposal, namely Snowbridge, Hyperbridge, and the bridge team at Parity. We discussed with several DVs and DAOs –such as KusDAO, Le Nexus, and Lucky Friday– and we even had a [technical report](https://drive.google.com/file/d/1t02YUwyuPYNZvk9xd4ouQQu8zrLs6A75/view?usp=sharing) kindly offered to us by Saxemberg. From each of these actors, we gathered valuable feedback and adapted to it.

We were overall pleased with the feedback we received. All key players involved seemed be in agreement that the MMB paper deserves to be published, and the MMB implementation deserves to be integrated into the future of Polkadot/JAM. As the original authors of MMB, we are deeply motivated by this sentiment.

Hence, we're back for a second attempt!

Of course, we also received criticism. There seemed to be three main pain points:

1. Our proposed success reward, admittedly ad-hoc, was not well received by many;
2. Some of the content of our proposal was considered non critical, as it had potential but not immediate implications in the development of Polkadot; and consequently,
3. The asking price was deemed too high by some.

***

As research oriented folks without prior experience with OpenGov proposals, we recognize our blunders which, luckily, are now clear to us in hindsight. For instance, there was no need to invent a new policy on future rewards, when the notion of retroactive public goods funding (rPGF) works well and has become standard in the community.

Also, we failed to communicate the importance of each component of our original proposal. A good example of this is the publication of the MMB paper: community members may not be aware of either the benefits nor the time and monetary costs involved in getting a paper published in a top computer science conference. And why would they be? It is our duty to better justify our milestones in the future.

Finally, as much as we love the theory behind the MMB cryptographic structure, and believe in its potential for future applications, we recognize that some of our previously proposed milestones were more explorative than essential, and ours is not the only proposal out there offering potential benefits and seeking funds.

With these teachings in mind, we now envision a roadmap with the following four stages:

1. This proposal (MMB part 1): Following the feedback received from [@gavw](https://polkadot.polkassembly.io/user/gavw) and [@alistair](https://polkadot.polkassembly.io/user/alistair), the first proposal will only contain the most critical milestones for the community, currently essential for Polkadot deployment. Namely, it will deliverThe full first proposal can be found [here](https://hackmd.io/@MerkleMountainBelts/MMB-Funding-Proposal-V3), and specifics on what was removed from our original referendum's scope [here](https://hackmd.io/@MerkleMountainBelts/MMB-Funding-Proposal-Scope-Cut-Against-Original-Referendum).
   * i) A technical report published in an online repository such as Arxiv. This report will cover MMB essentials required for Polkadot/JAM, without exploring other potential applications besides bridging.
   * ii) A barebones Rust implementation delivering the core ingredients required for Polkadot/JAM deployment. This implementation omits increment proofs and the F-MMB variant of MMB, but will immediately start saving fees for bridge users.
2. A follow-up second proposal (MMB part 2): It will be launched soon after completing the first one. It corresponds to content that we consider to be of clear utility for the community, but less time sensitive, and that will make the MMB library fully robust and multi-purpose. Examples are:
   * i) an analysis of the exact expected performance of MMB versus other Merkle structures including MMR, for different applications beyond bridges, to help future designers of light-client protocols in Polkadot decide which structure to choose;
   * ii) publishing the paper in a top rated computer-science conference; and
   * iii) adding increment proofs to the implementation, so that light clients can detect dishonest behavior from a full node that maintains the MMB, and trigger a slash.
3. Co-funding for further research topics. We have developed multiple application ideas related to MMB after leaving Web3 Foundation / Parity (i.e., ideas developed fully on our own time), that we intend to offer to specific teams both within the Polkadot community as well as outside of it. Some of these topics might also be included in the second proposal, if they seem to be beneficial to the community at large by that time.  Examples include
   * i)  tailoring the exact structure of MMB to the specific distribution of data queries in  an application, to minimize the expected query cost, and
   * ii) exploring the applicability of MMB to specific use cases, such as UTXO architecture, stateless architecture, and shielded transactions - [especially relevant to Kusama's privacy roadmap](https://forum.polkadot.network/t/make-kusama-chaotic-again/11123).
4. A proposal for retroactive funds (MMB rPGF), to be aligned with the community's evolving practices around rPGF. We intend to proceed with this if there's a point in the future when the economic impact of our work has exceeded its cost multiple times over. We are confident of the potential beneficial impact of our proposal, which should be easy to verify, such as with our proposed formula of fee savings. We also think that by that time there will likely be further use cases for the MMB library in Polkadot/JAM, beyond bridges, that couldn't be captured in a formula today.

***

For the community, this modular approach reduces the uncertainty risk. By having more stages, the funding cost of each proposal will be low, and will be requested only after we fully deliver the previous one, and we have shown the excellence and impact of our work.

This roadmap naturally entails more work for us. However, it allows us to offer our know-how to teams who need it, when they need it, and it also gives us more room to communicate the significance of each milestone along the way.

We happily accept the challenge of this new MMB roadmap, and we invite the reader to check out the [brand new proposal for MMB part 1](https://hackmd.io/@MerkleMountainBelts/MMB-Funding-Proposal-V3).

Send a batch of dispatch calls.
Unlike `batch`, it allows errors and won't interrupt.

May be called from any origin except `None`.

- `calls`: The calls to be dispatched from the same origin. The number of call must not
  exceed the constant: `batched_calls_limit` (available in constant metadata).

If origin is root then the calls are dispatch without checking origin filter. (This
includes bypassing `frame_system::Config::BaseCallFilter`).

## Complexity
- O(C) where C is the number of calls to be batched.

#1667 Treasury Proposal: Merkle Mountain Belts (MMB): part 1 & new roadmap

No Active Proposals