資料庫
不只回答案，
還要附證明
Provably 的兩位共同創辦人談一種資料基礎設施：當你不能看原始資料、也不能只相信資料庫營運者時，SQL 的答案能不能自己帶著可驗證的理由？
來源：Zero Knowledge Podcast Episode 398 ｜ 原始發表日期：2026 年 4 月 8 日
SCROLL
Provably 的兩位共同創辦人談一種資料基礎設施：當你不能看原始資料、也不能只相信資料庫營運者時，SQL 的答案能不能自己帶著可驗證的理由？
來源：Zero Knowledge Podcast Episode 398 ｜ 原始發表日期：2026 年 4 月 8 日
一般 SQL 查詢的信任模型很簡單：資料庫說答案是什麼，你就把它當作答案。這在單一公司內部通常足夠，但一旦資料屬於別人、資料不能外流、或結果要拿去觸發付款、交易、授權與自動決策，問題就變了。你不只要一個數字，也要能檢查這個數字是否真的由約定的資料與規則得出。
Zero Knowledge Podcast 第 398 集訪談 Provably 的 Shyam Duraishwami 與 Emanuele Ragnoli。兩人把「可驗證資料庫」描述為：在不揭露底層資料的情況下，對資料庫上的某項敘述或查詢結果給出證明。這是受訪團隊的產品與技術主張，不是節目替其做出的獨立效能驗證。
可驗證不等於把整個資料庫公開。它要回答的是更窄的問題：某個結果是否依照指定資料、指定查詢和指定規則被正確、完整地算出。
這個設計不取代 SQL，也不要求每個人改學密碼學。查詢仍然像資料庫查詢，差別在輸出多了一份可由外部驗證者檢查的 proof。驗證者不必持有整份私密資料，也不必重跑所有計算，仍可檢查結果是否對得上承諾過的資料與查詢。
圖示是依本集討論整理的概念模型，不代表 Provably 的完整實作或所有部署情境。
受訪者把這件事放在資料交換與資料協作的脈絡裡。當彼此不完全信任的系統要合作，問題往往不是「有沒有資料」，而是「誰能證明這份資料導出的結論足以被採用」。proof 把那個信任跳躍縮小成一個能驗的技術介面。
節目花了很長一段時間區分兩條路。ZKVM 是較通用的計算機器：能為很多類型的程式計算建立證明，但通用性有成本。Provably 的受訪者則主張，若問題集中在基本的關聯式 SQL、線性代數與資料查詢，可以把系統設計得更專門，避開讓通用機器處理不必要部分的負擔。
受訪者提到從早期 verifiable analytics、Bulletproofs 的限制，轉向更接近 SQL algebra 的設計，並討論線性 vector commitments 與多項式承諾等工具。這不是宣稱某一條路全面勝過另一條路，而是提醒：先問工作負載是什麼，再選擇證明系統的通用程度。
節目提出的應用不是單一產品清單，而是幾種協作困境。私密資料查詢需要證明結果沒有偏離；鏈上資料與市場資料需要讓外部系統採信；多代理人系統若要替人執行工作，也需要把「我依規則做完了」變成可檢查的輸出。
這些情境仍有實作、成本、資料治理與責任歸屬的問題。proof 能證明指定的計算關係，不能自動保證輸入資料沒有造假、商業規則是公平的，或人們選了正確的問題。可驗證資料庫把一段信任鏈變短，但不會讓整個制度自動可信。
未來的資料查詢，不只要給答案，還要讓答案能被檢查。
proof 不替你判斷資料值不值得信任，但能讓你不必只靠對方說「相信我」。
選完之後，分享你的觀點
這頁整理自 Zero Knowledge Podcast Episode 398。原始訪談保留 Provably 共同創辦人對資料承諾、SQL、ZKVM、證明系統與應用限制的完整技術脈絡。
閱讀完整文章 →喜歡這種分析嗎？
從零知識證明、資料基礎設施、AI 代理人到平台策略，用台灣讀者看得懂的語言，把複雜的產業變局說清楚。
免費訂閱區塊勢 →也可以直接付費支持，解鎖每週完整文章