@Plasma 最初並不是爲了逃避以太坊的吞吐量限制而設計的。自其構思之初，Plasma 就將擴展問題視爲約束問題，而不是原始容量問題。其次，與其在基礎區塊上增加更多計算，它實際上限制了在鏈外可以執行的操作，以維持一個薄而關鍵的承諾：無論如何，總應該能夠安全地回到以太坊。正是這種設計選擇使得 Plasma 在許多後續的擴展方法中顯得根本不同——同時也是對 Plasma 可用性產生混淆的原因。
從本質上講，@Plasma 將以太坊視爲一種最後的仲裁手段，而不是執行層。狀態轉換、計算和交易順序被轉移到子鏈中。以太坊僅偶爾有承諾，Merkle 根捕捉這些鏈的狀態。這種分離顯著減少了鏈上的負載，代價是以太坊不再確保每個轉換的正確性。然而，Plasma 假設錯誤行爲將被對抗而不是預防。擴展是對這種約束的承認。
在這裏，@Plasma 的退出機制成爲焦點。由於以太坊並未對所有交易進行認證，Plasma 必須爲用戶提供加密和程序手段，以單方面贖回他們的資金。退出遊戲的外圍特性、挑戰期和欺詐證明是系統的支柱。Plasma 設計中的每一個選擇：基於 utxo 的存在、各種形式的模型、對智能合約表達能力的任何限制、在較長的提款時間內買斷，都是由退出在對抗環境中可預測的可驗證和可執行的特性所決定。
在這方面，@Plasma 在傳統意義上並不是吞吐量的最佳選擇。它並不追求每秒交易數量的最大化，並且仍然完全通用。相反，它將功能限制到即使是最壞的情況也能存活的地步。當操作員隱瞞數據、禁止用戶（或提供不正確的狀態根）時，系統並不會完全崩潰，而是進入退出過程。這種擴展哲學與 Rollups 的方式截然不同，後者在確保更強保障的情況下重新執行或重新驗證鏈下計算。
這些限制是 @Plasma 許多實際限制的原因。通用智能合約難以支持，因爲退出必須在以太坊中可表達和可挑戰。數據的可用性是一個外部假設，意味着用戶或觀察者必須主動跟蹤鏈。大規模退出的概念，儘管在假設上是安全的，卻對以太坊造成了擁堵的威脅。所有這些並不是某種偶然的缺陷；它們是考慮退出安全性而非執行靈活性的直接結果。
看到 @Plasma 作爲一個約束系統也是其未成爲首選擴展解決方案的一個結果，儘管這是一個美好的事情。隨着以太坊的發展，更多的模型取代了較高的鏈上驗證成本，獲得了生態系統的接受。Rollups 將更多的計算轉移到以太坊的安全模型中，因此用戶不需要爲他們的資金採取防禦措施。另一方面，Plasma 需要警惕，並願意容忍複雜性，以便能夠擁有較小的鏈上足跡。
但 @Plasma 的思想仍然產生影響。實現與結算的隔離、故障模式的具體建模、強調減少對抗性故障而非樂觀表現的恢復，所有這些都影響了後續設計。更重要的是，Plasma 用於表明擴展不是一個單軸優化問題。增加吞吐量的過程並未規定系統如何失敗，用戶如何逃避失敗，這不是擴展而是推遲。
在這方面，@Plasma 成功的原因在於它並未成爲吞吐量的捷徑。這使得協議設計者不得不處理操作員信任、用戶責任和最壞情況行爲等尷尬問題。以太坊可以通過多種不同方式進行擴展，但 Plasma 提醒我們，在進一步推進任何其他可信的方法之前，我們需要回答一個更基本的問題：如果一切都出錯，誰能從戰壕中逃出來，如何做到？
