Gold Standard Technical Record: Plasma Chain (Plasma Framework)
Plasma Chain is a framework for creating child blockchains anchored to a main chain, processing transactions off-chain with periodic state commitments and exit mechanisms to recover funds in case of fraud or operator failure.
The Plasma framework, often referred to as Plasma Chain in broader contexts, is a scalability solution designed to enhance the transaction throughput of a parent blockchain (like Ethereum) by creating a hierarchy of 'child' blockchains. Each child chain operates independently but is anchored to the main chain, periodically committing state roots or transaction summaries. This off-chain processing significantly reduces the load on the main chain. Plasma chains function by allowing users to deposit assets onto the child chain. Transactions within the child chain are processed much faster and cheaper than on the main chain. To ensure security and prevent malicious behavior by the child chain operator(s), Plasma incorporates a robust 'exit mechanism.' Users can initiate an exit transaction to withdraw their assets from the child chain back to the main chain. If the operator tries to cheat (e.g., by censoring transactions or submitting fraudulent state data), other participants can submit a 'fraud proof' to the main chain, challenging the invalid state and allowing honest users to reclaim their funds. This mechanism relies on the security of the main chain to guarantee the integrity of the child chains. Variations exist, such as Plasma MVP (Minimum Viable Plasma), Plasma Cash, and More Viable Plasma (MVP), each addressing different trade-offs regarding data availability, exit complexity, and supported transaction types.
graph LR
Center["Gold Standard Technical Record: Plasma Chain (Plasma Framework)"]:::main
Pre_cryptography["cryptography"]:::pre --> Center
click Pre_cryptography "/terms/cryptography"
Rel_layer_2["layer-2"]:::related -.-> Center
click Rel_layer_2 "/terms/layer-2"
Rel_advanced_propulsion_systems["advanced-propulsion-systems"]:::related -.-> Center
click Rel_advanced_propulsion_systems "/terms/advanced-propulsion-systems"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Простыми словами
Imagine a big, busy highway (the main [blockchain](/ru/terms/blockchain)) where cars move slowly. Plasma is like building smaller, faster roads next to it where cars can zoom, and you can always get back to the main highway if you need to.
🤓 Expert Deep Dive
Plasma chains represent a form of optimistic rollups, where transactions are processed off-chain under the assumption of operator honesty, with a challenge period allowing for fraud proofs to revert invalid state transitions. The security model hinges on the ability of users to exit the chain, which requires data availability guarantees. In the original Plasma MVP design, data availability was a significant bottleneck, as users needed to download all transaction data to verify potential fraud. Subsequent designs like Plasma Cash introduced data availability committees or utilized Merkle trees with explicit data availability proofs to mitigate this. The exit mechanism is critical: a user initiates an exit by submitting a UTXO (Unspent Transaction Output) commitment. During a challenge period, any party can submit a fraud proof, which typically involves presenting a Merkle proof of a transaction that invalidates the committed state. If the fraud proof is valid, the exiting user's funds are returned to the main chain, and the operator may be penalized. The complexity of implementing secure and efficient exit games, especially for multi-transaction scenarios or complex smart contracts, remains a significant research area. Furthermore, the reliance on users actively monitoring the chain and submitting proofs introduces a 'liveness' problem, as users must be online or delegate monitoring to third parties.