1. 程式人生 > >深入理解Plasma(3):Plasma MVP

深入理解Plasma(3):Plasma MVP

image

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

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

深入理解Plasma(1):Plasma 框架

深入理解Plasma(2):Plasma 細節剖析

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

image

1

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():向某個正在執行的退出提出爭議。

2

Operator

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

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

3

存款(Deposit)

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

4

交易(transaction)

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

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

  1. Alice 首先需要得到 Bob 在子鏈上的地址;

  2. Alice 將一個或多個 UTXO 作為輸入構造交易傳送到 Bob 的地址,並對交易簽名;

  3. 等待該交易被打包到區塊中;

  4. Alice 向 Bob 傳送確認訊息,並且使用相同的私鑰簽名。

5

生成區塊

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

6

監視子鏈

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

7

取款/退出(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)”的機制,在下一小節我們將介紹這一機制是如何工作的。

8

確認簽名(Confirmation Signatures)

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

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

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

9

爭議(Challenge)

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

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

10

攻擊場景

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

  1. Alice 試圖忽視在子鏈中轉移給 Bob 的資產,使用最初加入 Plasma 子鏈時的交易證明向主鏈提出取款申請。

  2. Operator 生成一個惡意交易,佔有其他使用者的資產,並且嘗試退出子鏈。

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

場景1

  1. Alice 使用最初加入子鏈時生成的交易作為證據向主鏈提出取款申請;

  2. Bob(或者其他任意使用者)擁有 Alice 申請退出的 UTXO 被花費的交易證明,並將此作為證據向主鏈提出一個爭議;

  3. 爭議生效,Alice 的退出申請被駁回,同時將 Alice 申請退出的押金髮送給 Bob;

  4. Alice 的攻擊失效。

場景2

  1. Operator 建立了一個非法交易,並且將其打包生成區塊之後在主鏈得到確認;

  2. Operator 提交取款申請,打算將 Alice 的資產取走;

  3. 在爭議期內,Alice 發現了 Operator 的惡意行為,立即提出取款申請,退出子鏈;

  4. 由於 Alice 的申請優先順序較高,因此會在 Operator 之前退出;

  5. Operator 的攻擊失效。

11

相關專案

Talk is cheap, show me your code.

目前已經有許多機構和公司已經實現了 Plasma MVP,但實現的語言和細節有所不同:

  • FourthState Lab[3]

  • Omisego[4]

  • Kyokan[5]

12

總結

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

13 相關資源

相關資源

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

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

  3. https://github.com/fourthstate

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

  5. https://github.com/kyokan/plasma

內容首發:Github
原文作者:蓋蓋

擴充套件閱讀:

深入理解Plasma(1):Plasma 框架

深入理解Plasma(2):Plasma 細節剖析