深刻理解Plasma(3):Plasma MVP

image

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

上一篇文章中咱們已經理解了 Plasma 中的一些關鍵操做,可是 Plasma 是一套框架,若是脫離了實際的應用,仍然很難完全理解它。所以本篇將詳細介紹 Plama 的第一個項目 Plasma MVP(Minimal Viable Plasma),即在 Plasma 框架下的最基礎的實現。Plasma MVP 是 Vitalic 和他的團隊在 2018 年初提出的基於 UTXO 模型實現的 Plasma 設計標準[1],它以最簡單的方式實現了鏈下交易,但沒法支持複雜的計算,例如腳本(Script)和智能合約。在閱讀下面的內容以前,請確保已經理解了這個系列以前的文章。github

深刻理解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)區塊提交的時間;3d

  • 退出列表:即提交了退出申請的列表,每一個退出申請存儲了(1)申請者的地址(2)申請退出的 UTXO 的位置。code

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 細節剖析

相關文章
相關標籤/搜索