Gold Standard Technical Record: Plasma Chain (Plasma Framework)
Plasma Chain – це framework для створення child blockchains, які прив'язані до main chain, обробляючи транзакції off-chain з періодичними state commitments та exit mechanisms для відновлення коштів у разі шахрайства або збою оператора.
The Plasma framework, який часто називають Plasma Chain у ширших контекстах, є scalability solution, розробленим для підвищення transaction throughput батьківського блокчейну (як-от Ethereum) шляхом створення ієрархії 'child' блокчейнів. Кожен child chain працює незалежно, але прив'язаний до main chain, періодично роблячи state commitments або transaction summaries. Ця off-chain обробка значно зменшує навантаження на main chain. Plasma chains функціонують, дозволяючи користувачам deposit assets на child chain. Транзакції в межах child chain обробляються значно швидше та дешевше, ніж на main chain. Щоб забезпечити безпеку та запобігти зловмисній поведінці з боку оператора(ів) child chain, Plasma включає надійний 'exit mechanism'. Користувачі можуть ініціювати exit transaction для виведення своїх активів з child chain назад на main chain. Якщо оператор намагається обдурити (наприклад, шляхом цензури транзакцій або подання шахрайських state data), інші учасники можуть подати 'fraud proof' до main chain, оскаржуючи недійсний стан і дозволяючи чесним користувачам повернути свої кошти. Цей механізм покладається на безпеку main chain для гарантування цілісності child chains. Існують різні варіації, такі як Plasma MVP (Minimum Viable Plasma), Plasma Cash та More Viable Plasma (MVP), кожна з яких вирішує різні компроміси щодо data availability, exit complexity та підтримуваних типів транзакцій.
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;
🧒 Простими словами
Уявіть собі велику, завантажену магістраль (the main [blockchain](/uk/terms/blockchain)), де машини рухаються повільно. Plasma схожа на будівництво поруч менших, швидших доріг, де машини можуть мчати, і ви завжди можете повернутися на головну магістраль, якщо це необхідно.
🤓 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.