Buffy's IOTA Facts


Hi I am buffy. I do premium IOTA tech consulting.

All articles · FAQ

Hot take: The Mana specification is bad, and the IF should feel bad

TL;DR: Mana is the main Sybil protection mechanism for Coordicide, 15+ months in the making. The specification answers virtually no questions, and (explicitly and implicitly) opens up dozens more.

IOTA has published the Mana specifications in their research update:

This month we have worked on turning the mana research specification into a more detailed document that we are currently using to implement mana in Pollen.

In this specification, IOTA managed to turn the “one, constant mana” from the whitepaper into 4 different manas, in groups of two, leaving it completely unspecified what you would use each one for and how to combine them.

Updated 2020-09-12: Added section at bottom to address criticism

Updated 2020-09-13: Added quote from research update to beginning.

Note: I think lzpap did a good job at collecting the available data & deriving an implementation from it. Even though I do have issues with the implementation design (Why the fuck does Get*() cause a ManaUpdated() event? Leak implementation much?), 99% of criticism is with the state of the research.

Note 2: I didn’t want to spend too much time on this, so this is a list of questions in bullet points. It’s barely more than a rough draft, but it’s already about as long as the “high-level” design section in the specs. You’re welcome. Some of these questions I believe are fundamentally very, very hard to solve and are completely ignored.

The specification adds complexity without telling anyone why.

The specification leaves fundamental questions completely unaddressed

There are obvious DoS vectors that are not mentioned

There are attack vectors through circular dependencies with other modules

Unclear Terminology

The specification doesn’t actually tell us what problems it’s trying to solve, apart from a vague “reputation score”

None of the above matters, because at the end of the day:

Anyway, as trivial as it is to poke holes into this, I don’t want to spend too much time on this. Happy to dig deeper if Mark gives me EDF funds to do so.

There is a quote, “in distributed systems, i++ is a PhD thesis”, and I think that is very much true, even in permissioned systems.

IOTA is trying to build exponentially decaying systems based on multiple, rapidly changing inputs, to be the basis for all their other modules. And after 15 months of research, they’ve written down one equation. Good, but now comes the hard part, finding values and making the calculation consistent across distributed, and potentially hostile, networks. See you in 15-50 years or so ;)

Edit 2020-09-12: Addressing some criticism on this article

The main criticism seems to be that there are more internal specs that are yet unpublished, which address the mentioned problems. However, the research update referred to the specification as follows:

This month we have worked on turning the mana research specification into a more detailed document that we are currently using to implement mana in Pollen.

Notice the past tense in “turned”, the “detailed”, and the “currently using to implement mana”. There is every implication that this is the spec, and no implication that there is any other in-progress document.

The other criticism seem to be that it is fine to do “iterative development” (build a bit of specs, try them out in code, improve on specs and repeat). I’ve already addressed in the last bullet point why this won’t work in this case, but have re-worded the point to be a bit more specific.