UTXO 和 Account 模型對比

在當前區塊鏈世界中,主要有兩種記錄保存方式,UTXO 模式(Unspent Transaction Output) 和 Account 模式。Bitcoin 採用的是 UTXO 模型,Ethereum 採用的 Account 模型,一樣 CITA 也採用了 Account 模型。

Bitcoin 的設計初衷是點對點的電子現金系統,在比特幣中,每一個交易消耗以前交易生成的 UTXO 而後生成新的 UTXO,帳戶的餘額即全部屬於該地址的未花費 UTXO 集合,Bitcoin 的全局狀態即當前全部未花費的 UTXO 集合。Ethereum 意圖建立一個更爲通用的協議,該協議支持圖靈完備的編程語言,在此協議上用戶能夠編寫智能合約,建立各類去中心化的應用。因爲 UTXO 模型在狀態保存以及可編程性方面的缺陷,Ethereum 引入了 Account 模型。下面咱們對兩種模型的優缺點作進一步展開。git

UTXO 模型

UTXO 模型中,交易只是表明了 UTXO 集合的變動。而帳戶和餘額的概念是在 UTXO 集合上更高的抽象,帳號和餘額的概念只存在於錢包中。github

優勢:

  1. 計算是在鏈外的,交易自己既是結果也是證實。節點只作驗證便可,不須要對交易進行額外的計算,也沒有額外的狀態存儲。交易自己的輸出 UTXO 的計算是在錢包完成的,這樣交易的計算負擔徹底由錢包來承擔,必定程度上減小了鏈的負擔。
  2. 除 Coinbase 交易外,交易的 Input 始終是連接在某個 UTXO 後面。交易沒法被重放,而且交易的前後順序和依賴關係容易被驗證,交易是否被消費也容易被舉證。
  3. UTXO 模型是無狀態的,更容易併發處理。
  4. 對於 P2SH 類型的交易,具備更好的隱私性。交易中的 Input 是互不相關聯的,可使用 CoinJoin 這樣的技術,來增長必定的隱私性。

缺點:

  1. 沒法實現一些比較複雜的邏輯,可編程性差。對於複雜邏輯,或者須要狀態保存的合約,實現難度大,且狀態空間利用率比較低。
  2. 當 Input 較多時,見證腳本也會增多。而簽名自己是比較消耗 CPU 和存儲空間的。

ACCOUNT 模型

對於 Account 模型,Account 模型保存了世界狀態,鏈的狀態通常在區塊中以 StateRoot 和 ReceiptRoot 等形式進行共識。交易只是事件自己,不包含結果,交易的共識和狀態的共識本質上能夠隔離的。編程

優勢:

  1. 合約以代碼形式保存在 Account 中,而且 Account 擁有自身狀態。這種模型具備更好的可編程性,容易開發人員理解,場景更普遍。
  2. 批量交易的成本較低。設想礦池向礦工支付手續費,UTXO 中由於每一個 Input 和 Out 都須要單獨 Witness script 或者 Locking script,交易自己會很是大,簽名驗證和交易存儲都須要消耗鏈上寶貴的資源。而 Account 模型能夠經過合約的方式極大的下降成本。

缺點:

  1. Account 模型交易之間沒有依賴性,須要解決重放問題。
  2. 對於實現閃電網絡/雷電網絡,Plasma 等,用戶舉證須要更復雜的 Proof 證實機制,子鏈向主鏈進行狀態遷移須要更復雜的協議。

UTXO VS Account 

對於以上幾個優勢和缺點,咱們再作一些分析和對比。

第一,關於計算的問題的。UTXO 交易自己對於區塊鏈並無複雜的計算,這樣簡單的講其實並不徹底準確,緣由分有兩個,一是 Bitcoin 自己的交易多爲 P2SH,且 Witness script 是非圖靈完備的,不存在循環語句。而對於 Account 模型,例如 Ethereum,因爲計算多在鏈上,且爲圖靈完備,通常計算較爲複雜,同時合約安全性就容易成爲一個比較大的問題。固然是否圖靈完備對因而否是帳戶模型並無直接關聯。可是帳戶模型引入以後,合約能夠做爲一個不受任何人控制的獨立實體存在,這一點意義重大。

第二,關於 UTXO 更易併發的問題。在 UTXO 模型中,世界狀態即爲 UTXO 的集合,節點爲了更快的驗證交易,須要在內存中存儲全部的 UTXO 的索引,所以 UTXO 是很是昂貴的。對於長期不消費的 UTXO,會一直佔用節點的內存。因此對於此種模型,理論上應該鼓勵用戶減小生產 UTXO,多消耗 UTXO。可是若是要使用 UTXO 進行並行交易則須要更多的 UTXO 做爲輸入,同時要產生更多的 UTXO 來保證併發性,這本質上是對網絡進行了粉塵攻擊。而且因爲交易是在錢包內構造,因此須要錢包更復雜的設計。反觀 Account 模型,每一個帳戶能夠當作是單獨的互不影響的狀態機,帳戶之間經過消息進行通訊。因此理論上用戶發起多筆交易時,當這些交易之間不會互相調用同一 Account 時,交易是徹底能夠併發執行的。

第三,關於 Account 模型的交易重放問題。Ethereum 使用了在 Account 中增長 nonce 的方式,每筆交易對應一個 nonce,nonce 每次遞增。這種方式雖然意在解決重放的問題,可是同時引入了順序性問題,同時使得交易沒法並行。例如在 Ethereum中,用戶發送多筆交易,若是第一筆交易打包失敗,將引發後續多筆交易都打包不成功。在 CITA 中咱們使用了隨機 nonce 的方案,這樣用戶的交易之間沒有順序性依賴,不會引發串聯性失敗,同時使得交易有並行處理的可能。

第四,存儲問題。由於 UTXO 模型中,只能在交易中保存狀態。而 Account 模型的狀態是在節點保存,在 Ethereum 中使用MPT 的方式存儲,Block 中只須要共識 StateRoot 等便可。這樣對於鏈上數據,Account 模型實際更小,網絡傳輸的量更小,同時狀態在節點本地使用 MPT 方式保存,在空間使用上也更有效率。例如 A 向 B 轉帳,若是在 UTXO 中假設存在 2 個 Input 和2個 Output,則須要 2 個 Witness script 和 2 個Locking script;在 Account 模型中則只須要一個簽名,交易內容只包含金額便可。在最新的隔離見證明現後,Bitcoin的交易數據量也大大減小,可是實際上對於驗證節點和全節點仍然須要針對 Witness script 進行傳輸和驗證。

第五,對於輕節點獲取某一地址狀態,UTXO 更復雜。例如錢包中,須要向全節點請求全部關於某個地址的全部 UTXO,全節點能夠發送部分 UTXO,錢包要驗證該筆 UTXO 是否已經被消費,有必定的難度,並且錢包很難去證實 UTXO 是全集而不是部分集合。而對於 Account 模型則簡單不少,根據地址找到 State 中對應狀態,當前狀態的 State Proof 則能夠證實合約數據的真僞。固然對於 UTXO 也能夠在每一個區塊中對 UTXO 的 root 進行驗證,這一點與當前 Bitcoin 的實現有關,並不是 UTXO 的特色。瀏覽器

結論

綜上來看,Account 模型在可編程性,靈活性等方面更有優點;在簡單業務和跨鏈上,UTXO 有其很是獨到和開創性的優勢。對於選擇何種模型,要從具體的業務場景進行出發。安全

參考資料

《Thoughts on UTXOs》 by Vitalik Buterin網絡

《What are the pros and cons of Ethereum balances vs. UTXOs?》架構

《Mastering Bitcoin 2nd Edition - Programming the Open Blockchain》併發

《Accounts and not UTXOs》編程語言

《交易中的nonce的做用是什麼?》微服務

《Why is EVM-on-Plasma hard?》

做者介紹

NingNing,Architect at Cryptape, former core developer at EthFans.org.

Github:u2 (zhangyaning)

------------------------- End --------------------

We're hiring

若是你對創造將來的加密經濟感興趣,對本身的能力有自信,歡迎投簡歷到 join@cryptape.com 加入咱們:

  • Appchain Team - Appchain 是 Nervos Network 的 Layer 2 方案之一,以 CITA 爲核心,包含 Neuron 錢包和 Microscope 瀏覽器。不管你是移動應用高手,Web 應用高手,仍是有特殊技能的產品小王子,Appchain Team 都歡迎!

  • CITA Core Team - CITA 是世界上第一個使用微服務架構的許可鏈項目,用 Rust 實現,追求高性能與高穩定性。CITA 與大多數許可鏈不一樣,不是 Ethereum 或者 Fabric 的 fork,而是一個從零開始設計的項目,這給咱們帶來了許多挑戰,也帶來了許多樂趣。這裏隱藏大佬不少哦~

  • CKB Core Team - CKB 是 Nervos Network 的 Layer 1, 是一條公有鏈,用 Rust 實現,追求安全性與穩定性。這裏隱藏大佬也不少哦~

  • Cryptape Research

相關文章
相關標籤/搜索