Gold Standard Technical Record: Plasma Chain (Plasma Framework)
Plasma Chain est un framework pour la création de child blockchains ancrées à une main chain, traitant les transactions off-chain avec des state commitments périodiques et des exit mechanisms pour récupérer les fonds en cas de fraude ou de défaillance de l'opérateur.
Le Plasma framework, souvent appelé Plasma Chain dans des contextes plus larges, est une solution de scalabilité conçue pour améliorer le transaction throughput d'une parent blockchain (comme Ethereum) en créant une hiérarchie de 'child' blockchains. Chaque child chain opère indépendamment mais est ancrée à la main chain, committant périodiquement des state roots ou des transaction summaries. Ce traitement off-chain réduit significativement la charge sur la main chain. Les Plasma chains fonctionnent en permettant aux utilisateurs de déposer des assets sur la child chain. Les transactions au sein de la child chain sont traitées beaucoup plus rapidement et à moindre coût que sur la main chain. Pour assurer la sécurité et prévenir les comportements malveillants par les opérateurs de la child chain, Plasma intègre un 'exit mechanism' robuste. Les utilisateurs peuvent initier une exit transaction pour retirer leurs assets de la child chain vers la main chain. Si l'opérateur tente de tricher (par exemple, en censurant des transactions ou en soumettant des données d'état frauduleuses), d'autres participants peuvent soumettre une 'fraud proof' à la main chain, contestant l'état invalide et permettant aux utilisateurs honnêtes de récupérer leurs fonds. Ce mécanisme repose sur la sécurité de la main chain pour garantir l'intégrité des child chains. Des variations existent, telles que Plasma MVP (Minimum Viable Plasma), Plasma Cash, et More Viable Plasma (MVP), chacune abordant différents compromis concernant la data availability, la complexité des sorties, et les types de transactions supportés.
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;
🧒 Explique-moi comme si j'avais 5 ans
Imaginez une grande autoroute très fréquentée (la main [blockchain](/fr/terms/blockchain)) où les voitures roulent lentement. Plasma, c'est comme construire des routes plus petites et plus rapides à côté, où les voitures peuvent filer, et vous pouvez toujours revenir sur l'autoroute principale si vous en avez besoin.
🤓 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.