Monoplasma: A simple way to broadcast money to millions of people.

Henri Pihkala
Feb 22, 2019 · 6 min read
You can use Monoplasma for revenue sharing, distributing dividends or repeated airdrops

Monoplasma is a special-purpose off-chain scaling solution for one-to-many payments. It’s a good fit for any system where you repeatedly need to:

  1. Distribute value to a large and dynamic set of Ethereum addresses.
  2. Allow recipients to accumulate value over time.
  3. Withdraw tokens at their preferred moment.

We built Monoplasma because we needed it for the upcoming Data Unions feature on the Streamr Marketplace. Data Unions will allow end users who produce data through a connected gadget, like a Fitbit, or a Tesla, to pool and sell data collectively. And when that conglomerated data product sells, the revenue will then be automatically distributed out to potentially hundreds of thousands of data contributors.

The Monoplasma framework is reusable and un-opinionated, and as such, it’s a piece of software that might help others too. That’s why we wanted to make it standalone as a (hopefully useful) contribution to the Ethereum scaling space.

What problem does it solve?

  • Revenue sharing
  • Dividend distribution
  • Staking rewards
  • Repeated airdrops
  • Community rewards
  • Pension/benefit payments
  • Loyalty reward schemes

To outline something more specific I’ll pick an example way outside of our own use case of data monetisation and smart devices.

Imagine a decentralized Airbnb service where ownership shares in apartments are tokenised. An individual apartment could have hundreds, even thousands, of owners, each owning a fraction of it. When a guest stays in said apartment, the fee needs to be split among the owners. Ideally, this would happen on-chain within the payment transaction, but looping through each recipient, calculating their share, and sending tokens to them in a smart contract costs more and more gas as the number of recipients grows. This approach works fine for a handful of people, but it is simply not feasible beyond, say, 100 recipients — the transaction will simply become too large to even be included in a single block!

Design principles

  • It must distribute individual lump sum payments among a large group of recipients.
  • Recipients must be able to accumulate value for as long as they want, and withdraw at will by making a transaction on-chain.
  • Recipients must be able to join the pool without making a transaction or placing a stake. This is different from many other payment channels, and in fact crucial for us. In our use case, the people are mainstream users and we need to minimise obstacles for joining, such as having to buy ETH on day one.
  • And finally, the system should be trustless and transparent.

So we decided to roll out our own, and try to keep things as simple as possible. We were inspired by the different Plasma variants and payment channel stuff, but we basically threw out everything we didn’t need, to find the simplest possible mechanism that does what we want (and only that!), while maintaining good security properties and trustlessness.

I won’t dive into the endless depths of how Monoplasma compares to every other side-channel/side-chain/payment channel solution out there. I’ll focus on the major functional difference with the rest of the family. This is the one thing to remember after reading this article:

We sacrificed generality in favour of special-purpose.

This is not a generic payment system where everyone can arbitrarily transact with each other. The system is unidirectional: there are no transfers between accounts in the side channel.

In other words, tokens can’t be spent on the side channel. But why is that a good thing? Since tokens can’t be spent there, there can be no double spending! And as you might know, preventing double spending is arguably the hardest problem in designing any distributed system that transfers value. Not having to deal with this simplifies things immensely, which is exactly what we wanted.

Positive balance off-chain, negative balance on-chain

So what about withdrawals then? Withdrawals are tracked on-chain instead of off-chain. The side channel records your cumulative earnings (credits) and the smart contract keeps track of your cumulative withdrawals (debits).

Your withdrawable balance is the difference. To withdraw, all you need to do is prove your positive balance to the smart contract. You do this by providing a simple Merkle proof.

Let’s look at an example. The Monoplasma smart contract holds all the non-withdrawn tokens of the side channel. If we can prove we have earned 100 tokens, and the Monoplasma smart contract has seen us withdraw only 30 so far, it will allow us to withdraw 70 more.

The smart contract updates its internal record keeping to reflect that we now have withdrawn 100. If we try to withdraw again with a proof of earnings of 100 (or less), it won’t give us any further tokens. In other words, Monoplasma relies on the secure consensus mechanism of Ethereum to prevent people from withdrawing more than their provable share.

Other similarities and differences

  • There’s an Operator/Validator model. The Operator controls the off-chain state, and in Monoplasma they are actually the only party who can cheat. The job of the Validators is to check that they don’t.
  • Both the Operator and Validators maintain the off-chain state in a Merkle tree, and the Operator periodically publishes the root hash to the on-chain smart contract to enable withdrawals from that state. This is all familiar from other Plasma variants.
  • One difference, however, is that there’s no challenge period/exit game, as there can’t be double spending. Instead, there’s a non-interactive freeze period to allow time for Validators to exit people’s funds using the last validated honest block in case the Operator cheats. So earned funds do become withdrawable with a few days of latency, which is fine for many use cases, including ours.

Although somewhat simplified, the below table summarizes some of the similarities and differences between Monoplasma and other typical implementations in the same space:

As a developer, how can I try it out?

We hope Monoplasma will be useful to other #buidlers out there! It will be reasonably well maintained for the time being, because we will be needing it ourselves for at least as long as similar scale and cost can’t be achieved on-chain, which is probably several years away from now.

Kudos to Juuso Takalainen of Streamr who’s done almost all of the heavy lifting, and to Kelvin Fichter of OmiseGO (and recently plasma.group) for support and putting us on the right track. A shout-out also to some prior art we came across including RicMoo’s airdrop utility and the OUTPACE protocol by the folks at AdEx.

You can follow the Streamr community’s progress on Peepeth and Twitter and also join the community on Telegram and our developer forum.

Good luck!

Streamr

Open source infrastructure for real-time data

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store