# MMB: Frequently asked questions

*In this blogpost we answer questions that are frequently asked about our MMB project in general, and the current Polkadot referendum [#1667](https://polkadot.subsquare.io/referenda/1667) in particular.*

### 1. *Should MMB simply be added to the Gray Paper and implemented specifically for JAM?*

We'd like to start by pointing out that the idea of MMB is [much older](https://github.com/gavofyork/graypaper/issues/47) than the Gray Paper or JAM.

On top of the application for MMB suggested in the Gray Paper (committing to the set of accumulation outputs), MMB has many other potential applications for Polkadot/JAM, such as bridges and XCMP.

Besides, as Alistair Stewart (Head of Research at W3F) has pointed out in both the [previous referendum](https://polkadot.polkassembly.io/referenda/1317#r0D1h3fF1sLTbleRMTlO) (as a reply to Gavin Wood) and the current referendum (as a standalone comment), there are multiple aspects of MMB that are necessary for JAM, but not covered in the Gray Paper, and thus also not covered by the JAM implementations. Specifically, we refer to proof construction and data structure maintenance.

Moreover, in recent years the use of MMR has become very popular in blockchain research, for the design of light-client protocols (e.g., MiniChain, proof-of-proof-of-stake, FlyClient, the latter used by Zcash), and we believe that MMB beats MMR in all these use cases. Hence, a standalone paper on MMB can be expected to receive considerable interest from researchers.

We're of course glad to see MMB referenced in the Gray Paper, but it would not add value to the Gray Paper to cover these other use cases unrelated to JAM. Hence, we believe it's best to keep MMB as an independent project.

### 2. *How much of MMB is already described in the Gray Paper?*

The Gray Paper makes references to MMB in a couple of places, and we are glad to see it recognized there. However, our assumption is that these must be preparatory placeholders. Specifically (and fully encompassing the Gray Paper's description of MMB), the definition named "MMB append" is, in fact, a description of the MMR append. We have implemented the Gray Paper's definition of "MMB append" ([definition E.8 in appendix E.2 of the Gray Paper](https://graypaper.com/graypaper.pdf)) in Clojure here, and you will see that in fact it builds an MMR, not an MMB: https://onecompiler.com/clojure/43pz3yv4h

Likewise, the Gray Paper's definition of a super-peak is clearly an accurate description of an MMR, rather than an MMB.

Hence, we want to stress that **there is zero description of MMB in the Gray Paper**. On top of that, there is no mention of its main features, nor any motivation of why it should be used in JAM (instead of using MMR).

To clarify, we think that MMB should absolutely be used in JAM, and that the Gray Paper does not need to add any descriptions or motivations of MMB, as it has plenty of content to cover already. Instead, there should be a separate research paper on MMB with all the required descriptions, motivations and analyses, which the Gray Paper can reference.

This modular approach is standard in research: for instance, readers of the Gray Paper might not want to go too deep into, say, ELVES, and similarly readers of the ELVES paper (coauthored by Alfonso, btw) might not want to go too deep into JAM. The same is true for MMB.

### 3. *Does it help JAM implementers to have a Rust implementation and a paper preprint of MMB?*

Absolutely. The [very first rule](https://web.archive.org/web/20241218185040/https://jam.web3.foundation/rules) of the JAM prize excludes cryptographic primitives, so using third party libraries is permitted for these. MMB is a cryptographic accumulator, hence a primitive.

For instance, [this Rust library](https://github.com/davxy/ark-vrf) is - to our best knowledge from discussing with JAM implementers - used by all implementers for the ring-VRF primitive, either natively for the JAM implementations in Rust, or with FFI binding for JAM implementations in other languages.

Similarly, as MMB is a novel data structure, the paper preprint will be an invaluable reference for JAM implementers, to understand *how* MMB works, *why* it works, and therefore *how* JAM benefits significantly from using it.

### 4. *Could/should we have done this with funds from the Fellowship treasury, or by joining the Fellowship?*

a. [We did reach out](https://collectives.subsquare.io/posts/12) to the Fellowship for funding almost a year ago (prior to the original referendum), but were informed that our work's nature was out of scope for funding by Fellowship. And to our knowledge, the Fellowship has not funded any research papers to date.

b. The Fellowship is not open to researchers as members -- note the significant absence from it of, say, Alistair Stewart and Jeff Burdges from the Web3 Foundation's Research team. In particular Alfonso is a researcher, not a dev, so he could not join. Research is classified as merely an *incidental activity* [in the Fellowship Manifesto](https://github.com/polkadot-fellows/manifesto/blob/0c3df46d76625980b8b48742cb86f4d8fa6dda8d/manifesto.tex#L173).

c. Even if we could both join the Fellowship, its salary would be unsuitable as the only source of funding for a project of this size: with its codified rank increase delays, it would take many years to secure the funding needed for completing MMB, and the use case for bridges/BEEFY already exists *today*.

### 5. *Is the proposal's scope appropriate?*

A key deliverable of our original proposal was to have the paper published in a top-tier conference. Given the resistance we received, we have reduced the scope of our research milestones to produce a shorter paper preprint that encapsulates the core components of MMB.

In particular, it will not contain a detailed analysis of its applicability beyond bridges/BEEFY and JAM. We have coordinated our scope reductions with Alistair Stewart, and he finds the reduced scope covers what's missing from the current draft to fully deliver the core components needed for these use cases (bridges/BEEFY and JAM).

Our plan looking forward is to secure additional funding in the future, to complete the analysis needed to prove that MMB beats MMR in a large spectrum of use cases (such as the light client protocols mentioned above), which will turn the preprint into a robust research paper, and to publish it in a top-tier conference.