Gold Standard Technical Record: Plasma Chain (Plasma Framework)
Plasma Chain es un framework para crear child blockchains ancladas a una main chain, procesando transacciones off-chain con periodic state commitments y exit mechanisms para recuperar fondos en caso de fraude o failure del operator.
El Plasma framework, a menudo referido como Plasma Chain en contextos más amplios, es una scalability solution diseñada para mejorar el transaction throughput de una parent blockchain (como Ethereum) creando una jerarquía de 'child' blockchains. Cada child chain opera independientemente pero está anclada a la main chain, periódicamente committing state roots o transaction summaries. Este off-chain processing reduce significativamente la carga en la main chain. Las Plasma chains funcionan permitiendo a los usuarios depositar assets en la child chain. Las transacciones dentro de la child chain se procesan mucho más rápido y barato que en la main chain. Para asegurar la seguridad y prevenir el comportamiento malicioso por parte del child chain operator(s), Plasma incorpora un robusto 'exit mechanism.' Los usuarios pueden iniciar una exit transaction para retirar sus assets de la child chain de vuelta a la main chain. Si el operator intenta hacer trampa (e.g., censurando transacciones o enviando fraudulent state data), otros participants pueden enviar un 'fraud proof' a la main chain, desafiando el invalid state y permitiendo a los usuarios honestos recuperar sus fondos. Este mechanism se basa en la seguridad de la main chain para garantizar la integridad de las child chains. Existen variaciones, como Plasma MVP (Minimum Viable Plasma), Plasma Cash, y More Viable Plasma (MVP), cada una abordando diferentes trade-offs en cuanto a data availability, exit complexity, y 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;
🧒 Explícalo como si tuviera 5 años
Imagina una autopista grande y concurrida (la main [blockchain](/es/terms/blockchain)) donde los coches se mueven lentamente. Plasma es como construir carreteras más pequeñas y rápidas al lado donde los coches pueden ir a toda velocidad, y siempre puedes volver a la autopista principal si lo necesitas.
🤓 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.