But this leads to a problem: how do you ensure consistency between root chains? For example, suppose you have a Plasma chain with ETH and ETC chains as roots and ETH and ETC as two assets. Assume that block X of the Plasma chain contains A transaction that sends ETH from A to B and ETC from B to A (this is an exchange for A decentralized exchange). A malicious operator colluding with B can attack by creating block X and then publishing the root to the ETH chain but not to the ETC chain (or some alternate root X ‘to the ETC chain that does not contain the transaction). This causes ETH to complete but does not meet the requirements of ETC.
We can solve this problem with Lamport’s 99% fault tolerance consensus. Suppose the plasma chain has its own native token, and the deposit of this coin forms a proof of the equity system, with a bound validator. We add the following rule: in order for one of the roots to be linked to the head of the block, it must be signed by the validator; The index of the validator used is used as a random seed to pick the other 40 validators randomly. The include transaction must also specify the include timestamp T, and must commit between time T and time T + D (for example, D = 1 hour). The same containing transaction can then be published to other root chains within the same time window, or, if k validators from a random subset are jointly signed, before time T + k * D. Blocks are contained within a root chain, and any honest validators can therefore add their own signatures and have them submitted to other root chains within the D second additional time window where their signatures extend the deadline.
This does require the trust assumption of the Plasma chain, but it is very limited, requiring only about 1-10% of the validators to be honest, depending on the risk tolerance and validator set size (it can be less than or greater than 40 as needed).
Plasma:
Plasma is a framework for incentivizing and enforcing smart contracts. It can scale up to a large number of status updates per second (up to 1 billion levels per second) and support a large number of decentralized financial applications worldwide on the blockchain. These smart contracts are used to incentivize continuous automation through network transaction fees, and ultimately rely on the underlying blockchain (e.g., Ethereum) to enforce transaction state locking.
The decentralized, scalable, automated applications we propose can be used not only to handle financial behavior, but also as an alternative to current centralized cloud services through the economic incentives to build globally oriented persistent data services.
Plasma consists of two core components: recombining all blockchain calculations into a set of MapReduce functions, and an optional way to implement a Pos token deposit mechanism on an existing blockchain using the Nakamoto consensus principle that does not encourage block retention.
This build enforces state locking on the main chain by writing smart contracts on the main chain, using proof of fraud. We group blockchains into a hierarchical tree structure, treat each blockchain as an independent branch, and force the entire history of the blockchain, and MapReduce-capable calculations, to be submitted to the Merkle proof. By forcing a chain’s ledger information to be packaged into a sub-blockchain through the main chain, the chain will achieve incredible expansion with minimal trust (assuming the availability and scalability of the root chain).
Block capture attacks are a complex problem surrounding globally enforced availability of non-global data. Plasma mitigates this problem by removing problematic chains and creating a mechanism that incentivizes and consistently enforces data correctness.
Simply by periodically broadcasting a healthy Merkle proof to the main chain (such as Ethereum), this allows incredible scalability, reduced transaction costs and computational overhead. Plasma enables continuous operation of large-scale decentralized applications.
This article is an exclusive translation for Aether Chinese. Click to view the original article