Gold Standard Technical Record: Plasma Chain (Plasma Framework)
Plasma Chain to jest framework do tworzenia 'child blockchains' zakotwiczonych w 'main chain', przetwarzający transakcje 'off-chain' z okresowymi 'state commitments' i mechanizmami 'exit' do odzyskiwania środków w przypadku oszustwa lub awarii operatora.
Plasma framework, często określany jako Plasma Chain w szerszych kontekstach, jest rozwiązaniem skalowalności zaprojektowanym w celu zwiększenia przepustowości transakcji 'parent blockchain' (jak Ethereum) poprzez tworzenie hierarchii 'child blockchains'. Każdy 'child chain' działa niezależnie, ale jest zakotwiczony w 'main chain', okresowo zatwierdzając 'state roots' lub podsumowania transakcji. To 'off-chain processing' znacząco zmniejsza obciążenie 'main chain'. Plasma chains działają poprzez umożliwienie użytkownikom deponowania aktywów na 'child chain'. Transakcje wewnątrz 'child chain' są przetwarzane znacznie szybciej i taniej niż na 'main chain'. Aby zapewnić bezpieczeństwo i zapobiec złośliwemu zachowaniu operatora(ów) 'child chain', Plasma zawiera solidny 'exit mechanism'. Użytkownicy mogą zainicjować transakcję 'exit', aby wycofać swoje aktywa z 'child chain' z powrotem do 'main chain'. Jeśli operator spróbuje oszukać (np. poprzez cenzurowanie transakcji lub przesyłanie fałszywych danych stanu), inni uczestnicy mogą złożyć 'fraud proof' do 'main chain', kwestionując nieprawidłowy stan i umożliwiając uczciwym użytkownikom odzyskanie swoich środków. Ten mechanizm opiera się na bezpieczeństwie 'main chain', aby zagwarantować integralność 'child chains'. Istnieją różne warianty, takie jak Plasma MVP (Minimum Viable Plasma), Plasma Cash i More Viable Plasma (MVP), z których każdy adresuje inne kompromisy dotyczące dostępności danych ('data availability'), złożoności wyjścia ('exit complexity') i obsługiwanych typów transakcji.
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;
🧒 Wyjaśnij jak 5-latkowi
Wyobraź sobie dużą, ruchliwą autostradę (główny [blockchain](/pl/terms/blockchain)), po której samochody poruszają się wolno. Plasma jest jak budowanie obok niej mniejszych, szybszych dróg, po których samochody mogą pędzić, a ty zawsze możesz wrócić na główną autostradę, jeśli tego potrzebujesz.
🤓 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.