摘要：合約會處理由子鏈提交的區(qū)塊，并且將區(qū)塊的哈希值存在主鏈上。負責處理所有子鏈上發(fā)生的交易，將其打包成區(qū)塊存儲在子鏈上，并且周期性地向合約提交區(qū)塊，將子鏈上的狀態(tài)區(qū)塊的哈希值提交到主鏈共識。

本文首發(fā)于深入淺出區(qū)塊鏈社區(qū)
原文鏈接:深入理解Plasma（三）Plasma MVP原文已更新，請讀者前往原文閱讀

這一系列文章將圍繞以太坊的二層擴容框架 Plasma，介紹其基本運行原理，具體操作細節(jié)，安全性討論以及未來研究方向等。本篇文章主要介紹 Plasma 的一個最小實現(xiàn) Plasma MVP（Minima Viable Plasma）。

在上一篇文章中我們已經(jīng)理解了 Plasma 中的一些關鍵操作，但是 Plasma 是一套框架，如果脫離了實際的應用，仍然很難徹底理解它。因此本篇將詳細介紹 Plama 的第一個項目 Plasma MVP（Minimal Viable Plasma），即在 Plasma 框架下的最基礎的實現(xiàn)。Plasma MVP 是 Vitalic 和他的團隊在 2018 年初提出的基于 UTXO 模型實現(xiàn)的 Plasma 設計標準[[1]](https://ethresear.ch/t/minima...，它以最簡單的方式實現(xiàn)了鏈下交易，但無法支持復雜的計算，例如腳本（Script）和智能合約。在閱讀下面的內(nèi)容之前，請確保已經(jīng)理解了這個系列之前的文章。

整個 Plasma MVP 的生命周期可以通過下面這幅圖表現(xiàn)出來：

首先需要將 Plasma 合約部署到主鏈（以太坊）上作為主鏈和子鏈溝通的媒介。Plasma 合約會處理由子鏈提交的區(qū)塊，并且將區(qū)塊的哈希值存在主鏈上。除此之外，還會處理用戶的存款（deposit）、取款（withdrawal/exit）以及爭議（challenge）操作。

Plasma 合約中主要包括的數(shù)據(jù)結(jié)構(gòu)有：

Owner：合約的擁有者（即部署合約交易的發(fā)送者）的地址，即部署合約交易的發(fā)送者；

Plasma 區(qū)塊列表：每個 Plasma 區(qū)塊中存儲了（1）區(qū)塊的 Merkle root（2）區(qū)塊提交的時間；

退出列表：即提交了退出申請的列表，每個退出申請存儲了（1）申請者的地址（2）申請退出的 UTXO 的位置。

Plasma 合約中主要包括的函數(shù)有：

submitBlock(bytes32 root)：向主鏈提交一個區(qū)塊，僅僅提交區(qū)塊中所有交易的 Merkle root；

deposit()：生成一個只包含一個交易的區(qū)塊，這個交易中包含與 msg.value 值相等的 UTXO；

startExit()：執(zhí)行給定 UTXO 的退出操作；

challengeExit()：向某個正在執(zhí)行的退出提出爭議。

在前面的文章中我們已經(jīng)知道 Plasma 子鏈是一個獨立的區(qū)塊鏈，那么也就有獨立的共識機制。在 Plasma MVP 中采用的共識機制就是 PoA（Proof of Authority），即參與共識的只有唯一一個礦工，稱為 Operator。Operator 負責處理所有子鏈上發(fā)生的交易，將其打包成區(qū)塊存儲在子鏈上，并且周期性地向 Plasma 合約提交區(qū)塊，將子鏈上的狀態(tài)（區(qū)塊的哈希值）提交到主鏈共識。那么，既然 Operator 是唯一的礦工，這不就意味著 Plasma 違背了去中心化的初衷了嗎？其實，這是去中心化向執(zhí)行效率的妥協(xié)。在之前的文章中也提到過，Plasma 的安全基礎依賴于底層的區(qū)塊鏈，只要底層的區(qū)塊鏈能夠保證安全，那么在 Plasma 子鏈上發(fā)生的最差結(jié)果也只是迫使用戶退出子鏈，而不會造成資產(chǎn)損失。

Operator 可以采用最簡單的 REST API 方式實現(xiàn)，子鏈中的用戶可以通過調(diào)用簡單的 API 獲取到子鏈中區(qū)塊的數(shù)據(jù)。

用戶 Alice 通過存款（deposit）操作向 Plasma 合約發(fā)送帶有一定數(shù)額的以太幣或 ERC20 token 加入 Plasma Chain，這時 Plasma 合約會執(zhí)行 deposit() 函數(shù)，生成一個只包含一個交易的區(qū)塊，這個交易的 UTXO 記錄了 Alice 從主鏈轉(zhuǎn)移到子鏈的數(shù)額。當這個區(qū)塊被主鏈確認后，Alice 就可以使用新生成的 UTXO 向其它用戶發(fā)送交易了。

在 Plasma MVP 中，所有用戶發(fā)送的交易都是直接發(fā)送給 Operator，當積累了一定數(shù)量的交易后，由 Operator 將交易打包成區(qū)塊。這里需要注意的是，由于 Plasma MVP 采用的是 UTXO 模型，所以即使交易的收款方不存在，交易也是成立的。

在子鏈上 Alice 向 Bob 發(fā)送一個交易的流程如下：

Alice 首先需要得到 Bob 在子鏈上的地址；

Alice 將一個或多個 UTXO 作為輸入構(gòu)造交易發(fā)送到 Bob 的地址，并對交易簽名；

等待該交易被打包到區(qū)塊中；

Alice 向 Bob 發(fā)送確認消息，并且使用相同的私鑰簽名。

在 Plasma MVP 中，一個 Plasma 區(qū)塊產(chǎn)生的情況只有兩種：一種是 Operator 打包生成區(qū)塊，另外一種是當用戶執(zhí)行 deposit 操作時，由 Plasma 合約直接生成一個只包含一個交易的區(qū)塊。

為了保證子鏈上資產(chǎn)的安全，用戶需要周期性地檢查子鏈上的數(shù)據(jù)，保證沒有惡意交易產(chǎn)生。用戶需要運行一種自動化的軟件（例如錢包），每隔一段時間下載子鏈中的區(qū)塊數(shù)據(jù)，檢查每個區(qū)塊中的交易，如果有惡意交易產(chǎn)生，立即退出子鏈。

當 Alice 想要退出子鏈時，需要向 Plasma 合約發(fā)送一個 exit 交易，申請中需要包含（1）所要退出的 UTXO 的位置，包括區(qū)塊號（blknum）、區(qū)塊內(nèi)交易號（txindex）以及交易內(nèi)輸出號（outindex）（2）包含該 UTXO 的交易（3）該交易的 Merkle proof（4）用于生成該 UTXO 所涉及的之前一系列交易的確認簽名。除此之外，exit 交易中還要包含“退出押金（exit bond）”。如果這個 exit 被 challenge 成功，那么取款的操作將被取消，而且退出押金將被發(fā)送給提出 challenge 的用戶。

之后這個申請會被放入一個優(yōu)先隊列中，通過這個公式計算優(yōu)先級：

Priority = blknum  1000000000 + txindex  10000 + oindex

之所以采用這種優(yōu)先隊列的方式處理取款順序的原因是保證舊的 UTXO 總能優(yōu)先于新的 UTXO 被取出。也就是說，當有惡意交易（例如雙花等）產(chǎn)生時，所有在惡意交易發(fā)生之前的交易都可以被優(yōu)先取出。那么如何解決在惡意交易之后被確認的交易的取款問題呢？Plasma MVP 采用了“確認簽名（Confirmation Signatures）”的機制，在下一小節(jié)我們將介紹這一機制是如何工作的。

在 Plasma MVP 中，用戶的退出順序以所要退出的 UTXO 所在的交易的位置為準。假如 operator 作惡，在一個合法的交易之前插入一個非法的交易，那么當用戶執(zhí)行取款時，由于非法交易可以先被取出，因此當執(zhí)行到該用戶的交易時，可能 Plasma 合約中的資產(chǎn)已經(jīng)被取空。為了解決這個問題，Plasma MVP 采用了“確認簽名”機制，例如當 Alice 產(chǎn)生一個交易時，她首先會對交易簽名。當該交易被打包入?yún)^(qū)塊后，Alice 還需要對該交易進行一次簽名，即“確認簽名”。

引入確認簽名機制后，當 Alice 發(fā)現(xiàn)在一個區(qū)塊中自己的合法交易之前存在非法交易時，可以拒絕對自己的交易進行“確認簽名”，同時申請取款。這樣可以使得當前的交易失效，保證自己之前“確認簽名”后的交易可以優(yōu)先于非法交易之前取出。

這種確認簽名機制極大地破壞了用戶體驗，用戶每產(chǎn)生一個交易都要經(jīng)歷簽名->等待確認->確認簽名。而且由于確認簽名也需要占據(jù) Plasma 區(qū)塊的空間，因此也降低了子鏈的可擴展性。為了解決這個問題，Plasma 的研究人員提出了擴展版本 More Viable Plasma 移除了確認簽名的要求[[2]](https://ethresear.ch/t/more-v...。

每個取款操作都會經(jīng)歷一個爭議期。例如在 Alice 的某個 UTXO 退出子鏈的過程中，如果 Bob 在爭議期內(nèi)發(fā)現(xiàn)有惡意行為發(fā)生，他可以提出一個爭議（challenge）。一個爭議需要給出針對的 UTXO 的位置，以及該 UTXO 被花費的證明，即該 UTXO 已經(jīng)存在于某個交易中，且這個交易已經(jīng)被打包到區(qū)塊。

合約通過調(diào)用 challengeExit() 函數(shù)執(zhí)行一個爭議，爭議成功后會取消正在執(zhí)行的取款操作，并將提交取款申請所凍結(jié)的押金發(fā)送給 Bob。

在 Plasma 子鏈中主要存在兩種攻擊場景：

Alice 試圖忽視在子鏈中轉(zhuǎn)移給 Bob 的資產(chǎn)，使用最初加入 Plasma 子鏈時的交易證明向主鏈提出取款申請。

Operator 生成一個惡意交易，占有其他用戶的資產(chǎn)，并且嘗試退出子鏈。

下面對這兩個攻擊場景進行分析，觀察 Plasma MVP 如何保證資產(chǎn)的安全性：

場景1

Alice 使用最初加入子鏈時生成的交易作為證據(jù)向主鏈提出取款申請；

Bob（或者其他任意用戶）擁有 Alice 申請退出的 UTXO 被花費的交易證明，并將此作為證據(jù)向主鏈提出一個爭議；

爭議生效，Alice 的退出申請被駁回，同時將 Alice 申請退出的押金發(fā)送給 Bob；

Alice 的攻擊失效。

場景2

Operator 創(chuàng)建了一個非法交易，并且將其打包生成區(qū)塊之后在主鏈得到確認；

Operator 提交取款申請，打算將 Alice 的資產(chǎn)取走；

在爭議期內(nèi)，Alice 發(fā)現(xiàn)了 Operator 的惡意行為，立即提出取款申請，退出子鏈；

由于 Alice 的申請優(yōu)先級較高，因此會在 Operator 之前退出；

Operator 的攻擊失效。

Talk is cheap, show me your code.

目前已經(jīng)有許多機構(gòu)和公司已經(jīng)實現(xiàn)了 Plasma MVP，但實現(xiàn)的語言和細節(jié)有所不同：

FourthState Lab[[3]](https://github.com/fourthstate)

Omisego[[4]](https://github.com/omisego/pl...

Kyokan[[5]](https://github.com/kyokan/pla...

本文介紹了 Plasma 的最小實現(xiàn)版本 Plasma MVP，雖然采用最簡單的 UTXO 模型，但已經(jīng)足夠體現(xiàn)出 Plasma 的核心思想。在 Plasma MVP 中，用戶資產(chǎn)的安全主要依賴于用戶及時發(fā)現(xiàn)惡意行為，并退出子鏈。接下來的文章將會介紹另外一個稍微復雜一點的項目，Plasma Cash。

https://ethresear.ch/t/minimal-viable-plasma/426

https://ethresear.ch/t/more-viable-plasma/2160

https://github.com/fourthstate

https://github.com/omisego/plasma-mvp

https://github.com/kyokan/plasma

本文的作者是蓋蓋，他的微信公眾號: chainlab

深入淺出區(qū)塊鏈 - 系統(tǒng)學習區(qū)塊鏈，打造最好的區(qū)塊鏈技術(shù)博客。