深入理解Plasma（三）Plasma MVP

安全技術 · 發表 2018-11-06 16:46:24

摘要：這一系列文章將圍繞以太坊的二層擴容框架 Plasma，介紹其基本執行原理，具體操作細節，安全性討論以及未來研究方向等。本篇文章主要介紹 Plasma 的一個最小實現 Plasma MVP（Minima Viable Plasma）。在上一篇文章中我們已經理解了 Plasma 中的一...

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

在 ofollow,noindex">上一篇文章中我們已經理解了 Plasma 中的一些關鍵操作，但是 Plasma 是一套框架，如果脫離了實際的應用，仍然很難徹底理解它。因此本篇將詳細介紹 Plama 的第一個專案 Plasma MVP（Minimal Viable Plasma），即在 Plasma 框架下的最基礎的實現。Plasma MVP 是 Vitalic 和他的團隊在 2018 年初提出的基於 UTXO 模型實現的 Plasma 設計標準 [1] ，它以最簡單的方式實現了鏈下交易，但無法支援複雜的計算，例如指令碼（Script）和智慧合約。在閱讀下面的內容之前，請確保已經理解了這個系列之前的文章。

整個 Plasma MVP 的生命週期可以通過下面這幅圖表現出來：

Plasma 合約

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

Plasma 合約中主要包括的資料結構有：

Owner：合約的擁有者（即部署合約交易的傳送者）的地址，即部署合約交易的傳送者；
Plasma 區塊列表：每個 Plasma 區塊中儲存了（1）區塊的 Merkle root（2）區塊提交的時間；
退出列表：即提交了退出申請的列表，每個退出申請儲存了（1）申請者的地址（2）申請退出的 UTXO 的位置。

Plasma 合約中主要包括的函式有：

submitBlock(bytes32 root)：向主鏈提交一個區塊，僅僅提交區塊中所有交易的 Merkle root；
deposit()：生成一個只包含一個交易的區塊，這個交易中包含與 msg.value 值相等的 UTXO；
startExit()：執行給定 UTXO 的退出操作；
challengeExit()：向某個正在執行的退出提出爭議。

Operator

在前面的文章中我們已經知道 Plasma 子鏈是一個獨立的區塊鏈，那麼也就有獨立的共識機制。在 Plasma MVP 中採用的共識機制就是 PoA（Proof of Authority），即參與共識的只有唯一一個礦工，稱為 Operator。Operator 負責處理所有子鏈上發生的交易，將其打包成區塊儲存在子鏈上，並且週期性地向 Plasma 合約提交區塊，將子鏈上的狀態（區塊的雜湊值）提交到主鏈共識。那麼，既然 Operator 是唯一的礦工，這不就意味著 Plasma 違背了去中心化的初衷了嗎？其實，這是去中心化向執行效率的妥協。在之前的文章中也提到過，Plasma 的安全基礎依賴於底層的區塊鏈，只要底層的區塊鏈能夠保證安全，那麼在 Plasma 子鏈上發生的最差結果也只是迫使使用者退出子鏈，而不會造成資產損失。

Operator 可以採用最簡單的 REST API 方式實現，子鏈中的使用者可以通過呼叫簡單的 API 獲取到子鏈中區塊的資料。

存款（deposit）

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

交易（transaction）

在 Plasma MVP 中，所有使用者傳送的交易都是直接傳送給 Operator，當積累了一定數量的交易後，由 Operator 將交易打包成區塊。這裡需要注意的是，由於 Plasma MVP 採用的是 UTXO 模型，所以即使交易的收款方不存在，交易也是成立的。

在子鏈上 Alice 向 Bob 傳送一個交易的流程如下：

Alice 首先需要得到 Bob 在子鏈上的地址；
Alice 將一個或多個 UTXO 作為輸入構造交易傳送到 Bob 的地址，並對交易簽名；
等待該交易被打包到區塊中；
Alice 向 Bob 傳送確認訊息，並且使用相同的私鑰簽名。

生成區塊

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

監視子鏈

為了保證子鏈上資產的安全，使用者需要週期性地檢查子鏈上的資料，保證沒有惡意交易產生。使用者需要執行一種自動化的軟體（例如錢包），每隔一段時間下載子鏈中的區塊資料，檢查每個區塊中的交易，如果有惡意交易產生，立即退出子鏈。

取款/退出（withdrawal/exit）

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

之後這個申請會被放入一個優先佇列中，通過這個公式計算優先順序：

Priority = blknum 1000000000 + txindex 10000 + oindex

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

確認簽名（Confirmation Signatures）

在 Plasma MVP 中，使用者的退出順序以所要退出的 UTXO 所在的交易的位置為準。假如 operator 作惡，在一個合法的交易之前插入一個非法的交易，那麼當用戶執行取款時，由於非法交易可以先被取出，因此當執行到該使用者的交易時，可能 Plasma 合約中的資產已經被取空。為了解決這個問題，Plasma MVP 採用了“確認簽名”機制，例如當 Alice 產生一個交易時，她首先會對交易簽名。當該交易被打包入區塊後，Alice 還需要對該交易進行一次簽名，即“確認簽名”。

引入確認簽名機制後，當 Alice 發現在一個區塊中自己的合法交易之前存在非法交易時，可以拒絕對自己的交易進行“確認簽名”，同時申請取款。這樣可以使得當前的交易失效，保證自己之前“確認簽名”後的交易可以優先於非法交易之前取出。

這種確認簽名機制極大地破壞了使用者體驗，使用者每產生一個交易都要經歷簽名->等待確認->確認簽名。而且由於確認簽名也需要佔據 Plasma 區塊的空間，因此也降低了子鏈的可擴充套件性。為了解決這個問題，Plasma 的研究人員提出了擴充套件版本 More Viable Plasma 移除了確認簽名的要求 [2] 。

爭議（Challenge）

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

合約通過呼叫 challengeExit() 函式執行一個爭議，爭議成功後會取消正在執行的取款操作，並將提交取款申請所凍結的押金髮送給 Bob。

攻擊場景

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

Alice 試圖忽視在子鏈中轉移給 Bob 的資產，使用最初加入 Plasma 子鏈時的交易證明向主鏈提出取款申請。
Operator 生成一個惡意交易，佔有其他使用者的資產，並且嘗試退出子鏈。

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

場景1

Alice 使用最初加入子鏈時生成的交易作為證據向主鏈提出取款申請；
Bob（或者其他任意使用者）擁有 Alice 申請退出的 UTXO 被花費的交易證明，並將此作為證據向主鏈提出一個爭議；
爭議生效，Alice 的退出申請被駁回，同時將 Alice 申請退出的押金髮送給 Bob；
Alice 的攻擊失效。

場景2

Operator 建立了一個非法交易，並且將其打包生成區塊之後在主鏈得到確認；
Operator 提交取款申請，打算將 Alice 的資產取走；
在爭議期內，Alice 發現了 Operator 的惡意行為，立即提出取款申請，退出子鏈；
由於 Alice 的申請優先順序較高，因此會在 Operator 之前退出；
Operator 的攻擊失效。

總結

本文介紹了 Plasma 的最小實現版本 Plasma MVP，雖然採用最簡單的 UTXO 模型，但已經足夠體現出 Plasma 的核心思想。在 Plasma MVP 中，使用者資產的安全主要依賴於使用者及時發現惡意行為，並退出子鏈。接下來的文章將會介紹另外一個稍微複雜一點的專案，Plasma Cash。