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% 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 to referendum #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 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:
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:
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.