Merklux & Plasma Plant


#1

I am now implementing a plasma for dApps which manages its state with Merklux(A merkleized unidirectional data flow for state verification across evm based blockchains) pattern.

The key is using the following concepts for plasma operation

  1. Merklux: Using flux pattern to make the side chain to be verifiable
  2. PEPoW: When block proposers are pseudo-randomly selected, gives them different priorities to mine each block to backup an irregular block proposing activities.
  3. Casper for PEPoW: Using Casper to finalize the plasma blocks and giving maximum incentives when each signed block is proposed by the highest priority block proposer.

Here is a brief introduction to the plasma plant project. (I’ll try to update more detail article and spec sheet about this project after the PoC implementation)

And now I am in Prague for Devcon4, so please let me know if you have any interest to have a talk around the conference hall about plasma together.


#2

Hi, I’m struggling to understand your model because I’m not familiar with neither Flux or Redux. :slight_smile:

Can I just as what “Plasma for dApps” means? Are Plasma Plant chains running EVM?


#3

If I understand correctly, the entire state is stored in the contract, ie the entire merkle tree, not just the root hash?


#4

From what i understand the roots are differences in state transitions. Only roots live permanently on-chain. During a challenge, the operator submits the transactions that resulted in the given state transition.

The smart contract then runs the transactions and computes the expected state transition. I think the issue would be when there are a lot of transactions necessary to compute a proper state transition.


#5

Hi, plasma plant chains run evm. So when if you want to run your dApp with reducing transaction costs, you can deploy your app on to your own plasma plant chain & submit only root hash to the root chain.

In this situation I thought that the state transition should be verifiable on the root chain. So if we write a dApp using flux pattern, it can be much easier to run the verification process.

Here, Merklux is just a pattern which makes it easy to verify state transitions. And it does not still solve the Data Availability problem. So when if validators participate like beacon-chain, we can handle the DA problem by increasing the attack costs.

As a result, if you write a dApp using Merklux pattern, it can be run on the other chain. And as many as proposers and validators participate to manage your dApp by staking assets, your dApp bocomes more secure on the root chain.


#6

Entire state is stored in the contract on the child chain. And only root hash is stored in a plasma manager contract on the root chain.


#7

Right. So in plasma plant concept, one submission has a limited number of transactions and the number is proportional to the amount of total stakings on the root chain.


#8

Hi @kfichter I really like the term plapp! Merklux is an idea to write a plapp as we use redux to write a react application.


#9

Thanks for the answer @Wanseob-Lim! :slight_smile:

So basically, a centralized operator collects transactions from users, constructs blocks of valid ones and periodically submits roots/checkpoints to the main chain? In parallel with that, users need to constantly monitor the Plasma chain and submit a challenge if they spot a malicious transaction/state transition? Also, block withholding (data unavailability) attack remains unsolved?


#10

You’re welcome @MihailoBjelic.

Anyone can participate as a node by staking and they propose and validate each block. Here the period & transactions per submission depends on the configuration how much amount to stake.

On the plasma chain, the nodes confirms its plasma blocks using Casper. And the submissions are finalized on the root chain using an accusatorial system. If the submission is not accused for a while, cross-links in the snapshot are executed(withdrawal is possible). On the other hand, if a snapshot is wrong, another node can accuse the snapshot and make a fork. Then the snapshot submitter should defend its case by submitting data to verify its state transitions (merklux helps this process).

The submitter and validators will be slashed when they fail to defend the case or the accuser will be slashed. Therefore, to do the block witholding attack, 2/3 of validators should be taken by the attacker and the dApp will be safe when the benefit is under the attack costs which depends on the number of nodes and amount of stake.

Thus to make a secure plasma dApp, you should customize its secure level by adjusting its stake settings. Maybe a big exchange should get a lot of staking while a small exchange needs only a small amount of stakinf.

Because this needs PoS nodes, this concept might be suitable for dApps which mints its tokens giving some of them as an incentive.