utxo 模型和賬戶模型本質上是一樣的，utxo 模型只是一個軟體定義版本的賬戶模型。
原文標題：《當我們在說賬戶模型的時候，我們在說什麼》
撰文：學姐
在區塊鏈世界中，人們普遍認為，在可用性方面，帳戶模型比 utxo 模型更有優勢，我一直在努力彌合區塊鏈 [1] 中的 utxo 模型和帳戶模型之間的差異。
關於這個問題，有一些初步嘗試 [2]。
但是最近，我開始覺得 utxo 模型和賬戶模型本質上是一樣的，或者如果我們用術語來重新表述的話，utxo 模型只是一個軟體定義的版本的賬戶模型。如果你對此感到疑惑，我將在下面詳細解釋。
為了使事情更容易理解，在這篇文章中，我將只使用 utxo 模型的說法。瞭解我們的人都知道，我們將 utxo 模型推廣到了 cell 模型。cell 模型的附加優勢在這裡並不重要。下面我將討論任何能夠儲存資料的 utxo 模型 (比如 ckb 的 cell 模型，或者在使用 op_pushdata 的老式普通的比特幣的 utxo 模型)，在程式設計模型方面都可以與帳戶模型等價。
什麼是賬戶模型？
在基於賬戶模型的區塊鏈中，交易只說明操作或帶有引數的函式呼叫。實際的狀態，是從區塊鏈中計算和推匯出來的，如下圖所示 :
而在基於 utxo 的區塊鏈中，狀態都包含在交易中。你直接在交易中放入你想要的資料。通常，多個 utxo 可以一起工作來提供整個狀態的一部分。當你希望更改一部分資料時，你可以將該部分的 utxo 作為交易中的輸入包括進來，並提供一個包含更新資料的新 utxo。
如下圖所示：
關於這兩種模型的爭論已經有一段時間了。一個明顯的考慮是，賬戶模型的交易體積更小，但作為交換，必須在基於賬戶的區塊鏈中計算狀態，更糟糕的是，同一賬戶的交易需要順序執行。另一方面，基於 utxo 的區塊鏈只需要進行驗證工作，以確保提交的資料格式正確，訪問同一賬戶不同部分的交易也可以並行驗證，以獲得更好的效能。但是，我們要付出交易體積比較大的代價，因為交易需要包含實際的資料。
但這不是本文的重點，每種解決方案都有避免各自缺點的方法。人們普遍認為，在構建 dapp 時，賬戶模型比 utxo 模型更具有優越性。另一種說法是，基於 utxo 的區塊鏈不能使用帳戶模型擁有 dapps。這是真的嗎 ? 讓我們在這裡找到答案。
一個小轉換
我們將在這看到一個類似於 erc20 的 token 的轉賬操作。在帳戶模型中，通常有一個 token 帳戶儲存所有使用者的 token 餘額。當有人想要轉賬時，只需要提交說明 from, to 和 balance 的交易以進行轉帳：
然後，區塊鏈執行鏈上的交易，並更新包含更改的內部狀態。
我們如何在 utxo 模型中表示它？一種觀察是，典型的基於帳戶模型的透過鍵-值儲存表示整個帳戶狀態。我們可以接受同樣的抽象概念：
- 為每個帳戶建立預定好的一定數量的 cell(注：可理解為格子)。實際上，你只需要定義這裡的數字，缺少的 cell 可以解釋為虛擬的 cell。
- 每個單元格都將整個空間的一部分儲存在鍵-值中；
- 如果交易需要更新某個值，它首先查詢包含該值的鍵的 cell，並將相應的 cell 作為交易輸入，然後提供一個包含更新資料的新的 cell;
下圖顯示了這種交易示例：
這裡整個帳戶狀態包含 4 個 cell，但是由於只需要更新 2 個 cell，所以交易只包含這 2 個 cell。
你可能會注意到，這看起來很像資料庫和檔案系統中使用的 b-tree[3] 資料結構。在 b-tree 結構中，你希望最小化實際修改的 page，這與我們基於 utxo 的設計完全相同：你希望在交易中包含和修改儘可能少的 cell。這意味著雖然我們擁有一個簡單的設計，但是你可以利用在 b-tree 領域積累的豐富的研究來構建更好的設計，從而提供更好的結果。
如果我們考慮這裡的方案，它實際上並沒有利用任何特定於應用程式的知識，唯一的假設是帳戶模型使用鍵-值儲存，現在已經是這種情況了。這意味著我們可以在 utxo 模型的基礎上構建一個賬戶模型 generator：
- generator 響應來自 dapp 開發者的讀取請求，查詢該賬戶當前活動的 cell，提取所提供的鍵的值；
- generator 還接受帳戶模型風格的函式呼叫，它使用當前的活動的 cell 執行該函式，並生成包含更新 cell 的交易，將交易傳遞給區塊鏈以供接受。為了提高靈活性，我們可以在這裡引入 賬戶模型風格的虛擬機器，如 evm、move 等 ;
- 然後，鏈上智慧合約 可以執行由 generator 執行的相同程式碼，以驗證生成的資料是否正確。如果使用了 evm 或 move 這樣的 vm，我們可以將相同的 vm 移植到鏈上智慧合約，並在這裡執行相同的操作。
當然，需要構建這個新的 generator，使基於 utxo 的區塊鏈的行為類似於基於帳戶的區塊鏈。我在這裡的觀點是，這是一條完全可行的路線，這意味著基於 utxo 的設計，永遠不會妨礙基於帳戶模型構建的 dapp。
在 generator 中複製邏輯不是一個壞主意
對這條路線的不斷批評，也是我之前所擔心的，是我們在鏈外 generator 部分和鏈上智慧合約中都複製了邏輯。但最近，我一直在質疑這一點：這真的是一個問題嗎？在區塊鏈的世界裡，一個被廣泛遵循的原則是「不要相信它，去驗證它」（don't trust, verify）。一項交易中包含的智慧合約不僅會在單個節點上執行，還將在每個區塊鏈節點上執行。我們已經執行了 n 次相同的智慧合約，如果 generator 再執行一次，並使其成為 n + 1，這真的很重要嗎？我們都知道 n + 1 和 n 沒有區別。我個人認為 generator 部分只是另外一個輕量級客戶端節點，可以再次驗證智慧合約。這不會給我們現有的區塊鏈設計帶來任何問題。
如果你仍然對此感到疑惑，那麼實際上還有另外一個觀點：除基於鍵值儲存的帳戶模型外，以上設計均基於其他假設。當我們談論特定的 dapp 時，很有可能會利用某些屬性，因此鏈上智慧合約不必執行與鏈下 generator 完全相同的程式碼。例如，在一個 erc20 token 例子中，實際上只有 2 條規則需要在鏈上驗證：
- 交易具有有效的簽名；
- 正常交易不能發出大於當前發行量的 token。
一旦滿足了這兩個規則，erc20 相關程式碼的其餘部分就可以在鏈下安全地執行了。這意味著你不必再次在鏈上重新執行相同的程式碼。但這只是針對特定 dapp 的最佳化，我甚至會質疑是否有必要進行最佳化。對我來說，前面的更通用的解決方案已經工作得很好了。
軟體定義世界
當然以上描述的 generator 部件需要進一步開發。但是，如果我們將目光投向區塊鏈世界之外，再看看一般的軟體行業，我們會注意到一種不可阻擋的趨勢：
- cpu 從 cisc[4] 設計轉移到 risc[5] 設計，使用基於軟體的編譯器來填補 risc 中缺失的部分。
- 高度專業化的基於硬體的交換機正在被利用複雜軟體 [6] 的普通計算機吃掉
- 附加儲存或儲存區域網路的傳統網路已被採用軟體定義的儲存 [7] 的商品雲所取代
- 即使在通訊塔中，也已經部署了更多軟體 [8] 提供更好的效能
你注意到一個模式了嗎？我們看到的是一個複雜的硬體被簡單的硬體迅速取代的世界。越來越多地使用高度專業化的軟體來補充過去硬體中的功能。在 nervos network 中，我們認為區塊鏈更像是硬體而不是軟體，並且，如果我們看看 utxo 模型與帳戶模型的爭論，我們會看到類似的衝突：
- 基於帳戶的區塊鏈在區塊鏈（硬體）部分增加了更多邏輯；
- 基於 utxo 的區塊鏈在區塊鏈（硬體）部分中加入了更少的邏輯，並利用軟體來補充更多的特性。
如果我們只看到一種或兩種情況，這可能只是一個異常，但我們看到的是：從行業角度來看，看到了更多從硬體向更多軟體的轉變。我不確定你的看法，但我個人認為，我們這個行業的所有聰明人都做出了正確的選擇 :p
參考資料：
[1] 區塊鏈 :
https://github.com/nervosnetwork/ckb[2] 初步嘗試 :
https://medium.com/nervosnetwork/https-medium-com-nervosnetwork-animagus-part-1-introduction-66fa8ce27ccd-cfb361a7d883[3]b-tree:
https://en.wikipedia.org/wiki/b-tree[4]cisc:
https://en.wikipedia.org/wiki/complex_instruction_set_computer[5]risc:
https://en.wikipedia.org/wiki/reduced_instruction_set_computer[6] 複雜軟體 :
https://github.com/snabbco/snabb[7] 軟體定義的儲存 :
https://venturebeat.com/2019/06/17/ericsson-updates-5 g-cell-tower-software-to-improve-speed-and-coverage/
來源連結：mp.weixin.qq.com
