對于傳統數據庫，區(qū)塊鏈支持完全不同的范例。在計算歷史中，我們第一次擁有了一個數據存儲，在這個數據存儲中，我們可以絕對確定數據項的創(chuàng)建日期，并且可以絕對肯定該項沒有被修改。我們如何將區(qū)塊鏈的強大功能集成到數據庫中？

數據庫已經存在了很長時間，盡管已經發(fā)生了一些重大變革——例如關系數據庫的出現和隨后的NoSQL反革命——但是從開發(fā)人員的角度來看，數據庫操作幾乎沒有什么變化。

通常，應用程序創(chuàng)建一個數據記錄，然后讀取它，可能更新它并最終將其刪除。這個創(chuàng)建-讀取-更新-刪除周期被稱為方便的縮寫“CRUD”。CRUD說明了數據庫存儲的短暫性——數據被創(chuàng)建、修改和刪除。更新會銷毀舊版本的數據，一旦刪除，數據庫記錄將永遠消失（除非我們完全恢復數據庫的舊版本）。

此外，我們已經非常習慣于這樣一個事實：數據庫對交易的完整性提供了有限的保證。有特權的開發(fā)人員幾乎總是可以復蓋數據記錄，甚至可以將時間戳設置為他們選擇的任何記錄。在數據庫技術中沒有內在的方法來保證數據元素沒有被復蓋。

區(qū)塊鏈數據存儲

區(qū)塊鏈支持完全不同的范例。在最初的比特幣區(qū)塊鏈中，防止重復使用比特幣的必要性是至關重要的，絕對有必要永遠保存每筆交易的記錄。

因此，區(qū)塊鏈提供了一個僅限追加的不可變分類賬，一個相對簡單的數據庫，其中可以添加數據元素，但不能刪除或修改。比特幣的工作證明算法和連續(xù)的區(qū)塊鏈之間的加密鏈接使得篡改成為不可能。

因此，在計算歷史上，我們第一次有了一個數據存儲，我們可以絕對肯定一個數據項的創(chuàng)建日期，并且可以絕對地肯定該項沒有被修改。這是一場真正的革命！

不幸的是，我們不能把區(qū)塊鏈作為通用的數據存儲區(qū)來使用。與傳統的數據庫相比，它簡單、太慢、昂貴且笨拙。例如，比特幣區(qū)塊鏈每十分鐘就會產生一個新的區(qū)塊，每秒只能處理27個交易，如果將其用作傳統的數據存儲，每千兆字節(jié)將耗費數百萬美元。

如何集成區(qū)塊鏈功能

如果我們確實想將區(qū)塊鏈功能集成到現有的數據庫應用程序中，我們有兩條路可走：

1.構建新的數據庫技術，集成區(qū)塊鏈的概念，但仍然可以提供經濟性能。

2.在數據庫和現有的區(qū)塊鏈之間創(chuàng)建集成層。

一些早期的嘗試是建立在區(qū)塊鏈基礎上的新數據庫系統。不幸的是，它們不是“兩全之優(yōu)”，而是冒著“兩全之劣”的風險：與現有數據庫相比，它們更難以使用，功能也更差，而且沒有以太坊和比特幣等公共區(qū)塊鏈提供的強大完整性保證。

目前，我們只能通過集成層獲得兩個世界的最佳解決方案。

幸運的是，有一些技術模式允許我們維護數據庫記錄的不可變副本，并將它們錨定到區(qū)塊鏈上。

記錄結構的Merge樹和Merkle樹

首先，我們可以將數據構造為日志結構的Merge 樹（LSM）。在日志結構化Merge 樹中，所有數據（包括刪除和更新）都作為插入樹中的插入處理。刪除插入一條“tombstone”記錄，該記錄指出數據項已被刪除。更新會原封不動地保留舊記錄，只需插入一個新版本。

我們可以使用的第二個數據結構是Merkle樹。Merkle樹是一個哈希樹，連續(xù)的哈希對本身進行哈希運算，直到獲得單個根哈希。這個哈希可以用來驗證數千個任意大小的數據元素的完整性。如果我們將這個根哈希存儲在區(qū)塊鏈上，那么這個根哈希就可以用來證明單個區(qū)塊鏈交易中任意數量的數據庫元素的完整性。

因此，如果我們將數據庫模式實現為日志結構化Merge樹，則可以使用Merkle樹將數據庫狀態(tài)錨定到區(qū)塊鏈。這樣我們就擁有區(qū)塊鏈不變性的所有優(yōu)點，以及我們選擇的任何數據庫的強大功能。

如果這聽起來工作量很大，那你就對的。但是，不要絕望。在ProvenDB中，我們已經將這個集成層構建到MongoDB中。使用ProvenDB，您可以照常使用MongoDB，但是在幕后，我們維護了LSM結構，并允許您訪問區(qū)塊鏈的完整性和時間戳證明。