本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Amazon 的數據驗證 QLDB

使用 AmazonQLDB，您可以相信應用程式資料的變更歷史記錄是正確的。QLDB使用不可變的交易記錄檔 (稱為日誌) 進行資料儲存。日誌會追蹤已提交資料的每項變更，並維護一段時間內完整且可驗證的變更歷程記錄。

QLDB使用 SHA -256 雜湊函式搭配以 Merkle 樹為基礎的模型來產生日誌的加密表示法，稱為摘要。摘要作為資料整個變更歷史記錄的唯一簽名，截至某個時間點。您可以使用摘要來驗證文件修訂相對於該簽名的完整性。

你可以驗證什麼樣的數據QLDB？

在中QLDB，每個分類帳只有一個期刊。一個日誌可以有多個股，這些鏈是分錄的分區。

區塊是在交易期間認可至日誌鏈的物件。此區塊包含項目物件，代表傳遞所產生的文件修訂版本。您可以驗證中的個別修訂或整個分錄區塊QLDB。

下圖說明此分錄結構。

此圖表顯示交易已確認為包含文件修訂分錄的區塊。它還表明每個塊都被哈希鏈接到後續塊，並具有一個序列號來指定其在鏈中的地址。

若要取得有關圖塊中資料內容的資訊，請參閱〈〉Amazon 的期刊內容 QLDB。

資料完整性是什麼意思？

數據完整性QLDB意味著分類帳的日記實際上是不可變的。換句話說，您的資料 (特別是每個文件修訂版) 處於下列條件成立的狀態：

驗證如何運作？

要了解驗證在 Amazon 中的工作原理QLDB，您可以將概念分解為四個基本組成部分。

雜湊

QLDB使用 SHA -256 密碼編譯雜湊函數來建立 256 位元雜湊值。散列充當任意數量的輸入數據的唯一固定長度簽名。如果您變更輸入的任何部分 (即使是單一字元或位元)，則輸出雜湊會完全變更。

下圖顯示了 SHA -256 哈希函數為兩個QLDB文檔創建完全唯一的哈希值，這些文檔僅由一個數字不同。

SHA-256 散列函數是一種方式，這意味著在給定輸出時計算輸入在數學上是不可行的。下圖顯示了給定輸出散列值時，計算輸入QLDB文檔是不可行的。

QLDB為了驗證目的，會雜湊處理下列資料輸入：

摘要

摘要是在某個時間點對分類帳的整個期刊進行加密表示。日誌是僅附加的，並且日誌塊被排序和哈希鏈類似於區塊鏈。

您可以隨時要求分類帳的摘要。QLDB生成摘要並將其作為安全輸出文件返回給您。然後，您可以使用該摘要來驗證在先前時間點提交的文件修訂版本的完整性。如果您從修訂版開始並以摘要結尾來重新計算雜湊，您可以證明您的資料在兩者之間沒有被變更。

默克尔树

隨著分類帳的大小增加，重新計算日誌的完整雜湊鏈進行驗證的效率變得越來越低。QLDB使用默克爾樹模型來解決這種低效率的問題。

默克爾樹是一種樹數據結構，其中每個葉節點表示數據塊的哈希值。每個非葉節點都是其子節點的哈希值。Merkle 樹通常用於區塊鏈，可幫助您通過審核證明機制有效地驗證大型數據集。有關默克爾樹的更多信息，請參閱默克爾樹維基百科頁面。要了解有關 Merkle 審計證明的更多信息以及示例用例，請參閱證書透明度網站上的日誌校樣如何工作。

Merkle 樹的QLDB實現是從日誌的完整哈希鏈構建的。在此模型中，葉節點是所有個別文件修訂版雜湊的集合。根節點表示截至某個時間點的整個日誌摘要。

使用 Merkle 稽核證明，您可以僅檢查分類帳修訂歷史記錄的一小部分來驗證修訂。您可以通過遍歷樹從給定的葉節點（修訂）到其根（摘要）來完成此操作。沿著這個遍歷路徑，您可以遞歸散列節點對兄弟節點以計算它們的父哈希，直到以摘要結束為止。此遍歷具有樹中log(n)節點的時間複雜度。

證明

證明是針對給定摘要和文檔修訂QLDB返回的節點哈希的有序列表。它由 Merkle 樹模型將給定的葉節點哈希（修訂版）鏈接到根散列（摘要）所需的哈希組成。

在修訂版本和摘要之間變更任何已提交的資料都會破壞日誌的雜湊鏈，並且無法產生證明。

驗證範例

下圖說明了 Amazon QLDB 哈希樹模型。它顯示了一組塊哈希捲起到頂部根節點，它代表一個日誌鏈的摘要。在具有單鏈日誌的分類帳中，此根節點也是整個分類帳的摘要。

假設節點 A 是包含要驗證其哈希的文檔修訂的塊。下列節點代表您的證明中QLDB提供的有序雜湊清單：B、E、G。 這些散列需要重新計算從散列 A 的摘要。

若要重新計算摘要，請執行下列動作：

如果您重新計算的摘要符合預期值，則驗證成功。給定修訂散列和摘要，在證明中對哈希進行反向工程是不可行的。因此，本練習證明您的修訂確實寫在此期刊位置相對於摘要。

資料編輯如何影響驗證？

在 Amazon 中QLDB，DELETE陳述式只會以邏輯方式刪除文件，方法是建立將文件標記為已刪除的新修訂。QLDB也支援資料密文操作，可讓您永久刪除表格記錄中非使用中的文件修訂版本。

密文作業只會刪除指定修訂版本中的使用者資料，並保持分錄序列與文件中繼資料不變。編輯修訂之後，版本修訂中的使用者資料 (由data結構表示) 會被新dataHash欄位取代。此欄位的值是已移除data結構的 Amazon Ion 雜湊值。如需密文操作的詳細資訊和範例，請參閱編輯文件修訂版本。

因此，總帳會維持其整體資料完整性，並透過現有的驗證作業保持可加密驗證API。您仍然可以按預期使用這些API操作來請求 digest (GetDigest)，請求證明（GetBlock或 GetRevision），然後使用返回的對象運行驗證算法。

重新計算修訂雜湊

如果您計劃透過重新計算雜湊來驗證個別文件修訂版本，您必須有條件地檢查修訂是否已編輯。如果修訂已編輯，您可以使用dataHash欄位中提供的雜湊值。如果未編輯，則可以使用該字段重新計算哈希值。data

透過執行此條件檢查，您可以識別已編輯的修訂並採取適當的動作。例如，您可以記錄資料操作事件以進行監視。

開始使用驗證

在驗證數據之前，您必須從分類帳中請求摘要並保存以備日後使用。在摘要涵蓋的最新區塊之前提交的任何文件修訂版本都有資格根據該摘要進行驗證。

然後，您向 Amazon QLDB 要求證明要驗證的合格修訂版本。使用此證明，您可以調用客戶端API以重新計算摘要，從修訂散列開始。只要先前儲存的摘要在以外已知且受信任QLDB，如果重新計算的摘要雜湊符合儲存的摘要雜湊，就會證明文件的完整性。

有關如何從分類帳請求摘要，然後驗證數據的 step-by-step 指南，請參閱以下內容：