如果未來
區塊鏈的目標是作為通用平臺，用以存儲多種類型的數據，則其日志格式與存儲必須回歸數據庫的通用性本源。當前的賬本模式可以作為該體系中的一個特別模塊存在用以進行賬戶間結算，但是無法將其擴展為通用業務平臺。
既然要成為通用數據存儲平臺，那么UTXO模型存在一定局限性。在一個典型的銀行業務中，零售業務可能會包含千萬甚至億級別的賬戶，不同賬戶可能使用不同的利息計算規則，也可能存在凍結等特殊狀態。而交易流水信息每天可能達到千萬筆，如果將其業務擴展到非
金融行業，流水信息每天幾億也是可能的。因此，從一個通用賬戶+流水的業務模型中，一般企業會建立一個賬戶表與一個流水表，以不同的策略進行管理。
賬戶表俗稱余額類數據，在典型的數據治理體系中需要做到定期快照備份（例如月初數和月末數）；而流水表則成為流水類數據，一般來說以原始交易格式直接存儲和備份。通過對余額類數據快照備份的恢復，對指定賬號重做某個時間范圍內的全部交易流水，可以得到該賬號任意時間點的余額信息。
而UTXO的本質在于日志存放的信息不是記錄的最終結果，而是變化行為。在傳統數據庫中，每條事務記錄的是數據的寫前與寫后內容。例如將一條記錄從5更改為8，其數據庫日志記錄原始數據為5且新數據為8，而不是記錄“+3”的操作。但是UTXO記錄的是變更信息，其主要的目的是解決雙花問題（例如對于一個有100塊錢的賬號，一個人在中國轉走10塊錢，另一個人在美國同時轉走10塊錢，如果記錄的是最終結果，那么中國的服務器會認為這個人有90塊，美國的服務器在沒有全局鎖的情況下也會認為這個人有90塊，最終寫到區塊中就變成90塊余額，而非80）。
UTXO的機制可以有效地在無鎖的情況下避免雙花問題，但是其劣勢則在于不存儲余額表，所有的信息均通過重做流水數據，從零開始生成。對于一個存在了十年以上，包含幾百億筆交易的系統來說，這樣的做法就好比每次重啟都要從都重做幾百筆交易并存入內存中（或KV數據庫里），是一種非常原始且不經濟的方式。
另一方面，區塊鏈日志的結構看來，由于多活系統中全局鎖很難實現，因此需要通過交易日志結構的調整來滿足傳統數據庫中事務的功能。傳統數據庫中當涉及到兩賬戶之間轉賬操作時需要開啟一個事務。在事務日志中一個賬戶增加一個賬戶減少的業務邏輯，需要體現為包含三條記錄的鏈表（最后的提交操作也是一個記錄）。在數據庫崩潰或發生異常后，只要通過重做所有的任務，并最后對全部沒有提交記錄的事務進行反向操作，即可得到原子性（Atomic）與持久性（Durability）。
而在區塊鏈體系中由于不存在事務的概念，同時操作日志與結算業務進行了緊密耦合，因此每條交易記錄都會包含一個輸入賬號以及若干個輸出賬號，也就是說只要一條事務記錄被成功發送給一個節點，則可以保證在該記錄內部的全部輸入輸出賬戶統一進行了變更。可以說，區塊鏈通過定制化交易日志簡化了事務操作的復雜性，但是帶來的影響便在于業務與代碼的緊密耦合不可分割。
但是無論如何，首先UTXO并不是通用數據結構，而是為交易業務高度定制化的數據結構，如果想要運行圖靈完備的智能合約（或者說存儲過程），使用UTXO會有很多局限性。第二，對長期運行的大型系統（相比起大中型銀行核心交易系統所產生的交易流水，
比特幣從誕生到現在的交易量少得可以忽略不計），UTXO每次初始化需要全部的歷史交易日志。這種模式完全不可能適用于大型交易系統。
因此，可以存在兩種做法解決該問題。第一種方式使用傳統賬戶表與流水表的機制，將UTXO以流水的方式體現出來，同時定期保存賬戶快照，以避免每次重構數據庫都需要重做全部交易（這種機制需要考慮到賬戶與流水表在多活系統中，沒有全局鎖的情況下如何實現一致性的問題）。而對于非結算類交易，通用型
區塊鏈項目則可能采用日志結合用戶數據存儲的模式，才能夠普適性地滿足通用業務需求（這種機制需要依靠比nonce更好的排序機制避免雙花）。
版權申明：本內容來自于互聯網，屬第三方匯集推薦平臺。本文的版權歸原作者所有，文章言論不代表鏈門戶的觀點，鏈門戶不承擔任何法律責任。如有侵權請聯系QQ：3341927519進行反饋。
