這一系列文章將圍繞以太坊的二層擴容框架,介紹其基本運行原理,具體操做細節,安全性討論以及將來研究方向等。本篇文章主要介紹 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 MVP 的生命週期能夠經過下面這幅圖表現出來:框架
首先須要將 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():向某個正在執行的退出提出爭議。
在前面的文章中咱們已經知道 Plasma 子鏈是一個獨立的區塊鏈,那麼也就有獨立的共識機制。在 Plasma MVP 中採用的共識機制就是 PoA(Proof of Authority),即參與共識的只有惟一一個礦工,稱爲 Operator。Operator 負責處理全部子鏈上發生的交易,將其打包成區塊存儲在子鏈上,而且週期性地向 Plasma 合約提交區塊,將子鏈上的狀態(區塊的哈希值)提交到主鏈共識。那麼,既然 Operator 是惟一的礦工,這不就意味着 Plasma 違背了去中心化的初衷了嗎?其實,這是去中心化向執行效率的妥協。在以前的文章中也提到過,Plasma 的安全基礎依賴於底層的區塊鏈,只要底層的區塊鏈可以保證安全,那麼在 Plasma 子鏈上發生的最差結果也只是迫使用戶退出子鏈,而不會形成資產損失。
Operator 能夠採用最簡單的 REST API 方式實現,子鏈中的用戶能夠經過調用簡單的 API 獲取到子鏈中區塊的數據。
用戶 Alice 經過存款(deposit)操做向 Plasma 合約發送帶有必定數額的以太幣或 ERC20 token 加入 Plasma Chain,這時 Plasma 合約會執行 deposit() 函數,生成一個只包含一個交易的區塊,這個交易的 UTXO 記錄了 Alice 從主鏈轉移到子鏈的數額。當這個區塊被主鏈確認後,Alice 就可使用新生成的 UTXO 向其它用戶發送交易了。
在 Plasma MVP 中,全部用戶發送的交易都是直接發送給 Operator,當積累了必定數量的交易後,由 Operator 將交易打包成區塊。這裏須要注意的是,因爲 Plasma MVP 採用的是 UTXO 模型,因此即便交易的收款方不存在,交易也是成立的。
在子鏈上 Alice 向 Bob 發送一個交易的流程以下:
Alice 首先須要獲得 Bob 在子鏈上的地址;
Alice 將一個或多個 UTXO 做爲輸入構造交易發送到 Bob 的地址,並對交易簽名;
等待該交易被打包到區塊中;
Alice 向 Bob 發送確認消息,而且使用相同的私鑰簽名。
在 Plasma MVP 中,一個 Plasma 區塊產生的狀況只有兩種:一種是 Operator 打包生成區塊,另一種是當用戶執行 deposit 操做時,由 Plasma 合約直接生成一個只包含一個交易的區塊。
爲了保證子鏈上資產的安全,用戶須要週期性地檢查子鏈上的數據,保證沒有惡意交易產生。用戶須要運行一種自動化的軟件(例如錢包),每隔一段時間下載子鏈中的區塊數據,檢查每一個區塊中的交易,若是有惡意交易產生,當即退出子鏈。
當 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)」的機制,在下一小節咱們將介紹這一機制是如何工做的。
在 Plasma MVP 中,用戶的退出順序以所要退出的 UTXO 所在的交易的位置爲準。假如 operator 做惡,在一個合法的交易以前插入一個非法的交易,那麼當用戶執行取款時,因爲非法交易能夠先被取出,所以當執行到該用戶的交易時,可能 Plasma 合約中的資產已經被取空。爲了解決這個問題,Plasma MVP 採用了「確認簽名」機制,例如當 Alice 產生一個交易時,她首先會對交易簽名。當該交易被打包入區塊後,Alice 還須要對該交易進行一次簽名,即「確認簽名」。
引入確認簽名機制後,當 Alice 發如今一個區塊中本身的合法交易以前存在非法交易時,能夠拒絕對本身的交易進行「確認簽名」,同時申請取款。這樣可使得當前的交易失效,保證本身以前「確認簽名」後的交易能夠優先於非法交易以前取出。
這種確認簽名機制極大地破壞了用戶體驗,用戶每產生一個交易都要經歷簽名->等待確認->確認簽名。並且因爲確認簽名也須要佔據 Plasma 區塊的空間,所以也下降了子鏈的可擴展性。爲了解決這個問題,Plasma 的研究人員提出了擴展版本 More Viable Plasma 移除了確認簽名的要求[2]。
每一個取款操做都會經歷一個爭議期。例如在 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 的攻擊失效。
Talk is cheap, show me your code.
目前已經有許多機構和公司已經實現了 Plasma MVP,但實現的語言和細節有所不一樣:
FourthState Lab[3]
Omisego[4]
Kyokan[5]
本文介紹了 Plasma 的最小實現版本 Plasma MVP,雖然採用最簡單的 UTXO 模型,但已經足夠體現出 Plasma 的核心思想。在 Plasma MVP 中,用戶資產的安全主要依賴於用戶及時發現惡意行爲,並退出子鏈。接下來的文章將會介紹另一個稍微複雜一點的項目,Plasma Cash。
相關資源
內容首發:Github 原文做者:蓋蓋
擴展閱讀: