This is a
playground to test code. It runs a full
Node.js environment and already has all of
npm’s 400,000 packages pre-installed, including
monoplasma with all
npm packages installed. Try it out:
This service is provided by RunKit and is not affiliated with npm, Inc or the package authors.
Basically wherever you repeatedly fan out value to a dynamic set of accounts, and want self-service withdrawals.
Monoplasma is a framework for scalable one-to-many payments of ERC-20 tokens on Ethereum.
It is a side-chain with monotonously increasing balances. Like in Plasma, side-chain state hash is committed to root chain. It is not a blockchain: blocks are not linked to earlier side-chain blocks, but rather to the root chain blocks. Unlike Plasma, unidirectionality meaning no transfers between (withdrawable) accounts means no double-spend problem. This simplifies the exit procedure remarkably. No challenge periods are needed, and exit proofs are non-interactive. User experience is thus instant withdrawal, minus the lag (waiting while the newest block are frozen, see threat scenario below).
Operator's job is to allocate tokens to community members, and publish "side-chain blocks" to root chain. In case the allocations can't deterministically be deduced from root chain events, the operator also must provide upon request the complete contents of the "block" corresponding to that hash, e.g. over HTTP or IPFS. In the MVP case, revenues are split equally, and a validator doesn't need to communicate with the operator in order to sync the side-chain state and verify the published blocks.
The name was so chosen because we wanted a sidechain to handle the token distribution calculation, and chose Plasma as the inspiration. Of course Plasma is not a payment channel, and while it might have worked for our use-case, the overhead of the exit game was not desired (mainly the challenge period in the happy path case).
For more information, also check out this blog post.
Main threat scenario: plasma side-chain operator creates a sock-puppet account, assigns it infinity tokens, publishes the hash, and drains the root chain contract by withdrawing. To combat this, there's a freeze period after the side chain block hash is published. In case of faulty or missing (withheld) side chain block contents, everyone can exit using old unfrozen root hashes.
There could be fraud proofs for this particular scenario: (interactive) proof that sum of balances is greater than amount of tokens held in the root chain contract; proof that a particular balance decreased; etc.
But in case the operator simply doesn't provide the fudged accounts book (operator availability failure), exits from old blocks could be used as proxy for suspicion of admin's behaviour. Freeze period could, for instance, be extended in case members use on old block to exit, giving other members more time to react. This must be balanced with DoS griefing, but should definitely increase the likelihood of everyone getting their tokens out in case of operator fails.
Build Monoplasma and the Revenue sharing demo:
git clone https://github.com/streamr-dev/monoplasma.git cd monoplasma npm install npm run build
To build the demo as well:
cd demo npm run build
The demo UI will be started at http://0.0.0.0:8080/
In another terminal tab:
WATCHED_ACCOUNTS, give a comma separated list of accounts you'd like the validator to exit if an operator fraud is detected.
By default the demo runs on
ganache, with a mnemonic that creates a certain set of accounts. We'll use two of them. Import to your Metamask the following private keys (do not use these accounts on real networks):
The demo creates a demo unicorn token (🦄). Let's configure that to Metamask as well.
0xbaa81a0179015be47ad439566374f2bae098686f. The token name 🦄 and its settings should be filled automatically. Click Next, then Add Tokens.
Let's add some accounts to the revenue sharing pool:
0x4178baBE9E5148c6D5fd431cD72884B07Ad855a0to the textbox under "Management", and click the "Add users" button.
Now Bob is alone in the pool, and all revenue would be attributed to him. Let's add him some company! You can add whatever addresses you want, or just paste in these 99,999 addresses.
Now you should have a bunch of people in the pool, with everything else zero. Let's add some revenue!
You should see the revenue pool numbers increase by the amount of tokens, and a block published by the Operator become visible in the table.
In the demo there's a 20 second freeze period for the funds, during which they can't be withdrawn. In real life this could be a few days, enough time for validators to exit people in case the Operator commits fraud.
Now let's try to withdraw Bob's share from the side channel!
On-chain, all the tokens are in the Monoplasma smart contract. But off-chain, Bob owns some of them. He can withdraw them from the Monoplasma smart contract by presenting a cryptographic proof of his earnings.
0x4178baBE9E5148c6D5fd431cD72884B07Ad855a0to the input field in the "User account" section, and click the "View" button beside it.
Whoa, you just sprayed tokens to 100,000 addresses as Alice with a few clicks, and withdrew some of them from the side channel to your on-chain wallet as Bob!
ganachewas running implicitly within it, you can restart from scratch by doing a
npm run build && node start_operator.js.
To start the demo UI so that it's easier to debug e.g. in web developer tools:
Open in a terminal tab:
cd demo npm start
The demo UI will be started at http://0.0.0.0:8000/