隱私不是把鏈做小，
而是把選擇權做回來

Osmosis 共同創辦人 Dev Ojha 從 DEX 的成長經驗回頭看隱私：真正要設計的不是「公開或私密」二選一，而是誰能在何時、為何事看見與使用資料。

來源：Zero Knowledge Podcast Episode 397 ｜原始發表日期：2026 年 4 月 2 日

SCROLL

PART 1 ｜成長不是唯一的完成形態

一個成功的 DEX，
仍可能留下沒有解完的問題

Dev Ojha 在節目裡回顧 Osmosis 的歷程：它在 Cosmos 生態中把跨鏈流動性、AMM 與應用鏈做成一個可用的交易場所。協定被採用，不代表所有設計問題都已結束；交易、部位與策略愈公開，使用者能被驗證，也愈容易被觀察、複製與針對。

他離開原本的工作，並不是否定 Osmosis 的成果，而是把注意力從「如何讓市場更有效率」移到「市場參與者是否還有足夠的選擇」。這個轉向把隱私放回產品問題：哪些公開性帶來必要信任，哪些公開性只是把使用者暴露給更快的對手？

節目的出發點：可驗證的系統不必要求所有人把所有訊息攤開。協定要先說清楚，每種資訊公開後由誰受益、誰承擔成本。

PART 2 ｜可組合性與隱私不是天然敵人

DeFi 常把可組合性理解成公開狀態：任何合約都能讀取資料、接續操作。這個模式降低整合門檻，也讓交易細節、資產配置與意圖成為可搜尋的公開訊號。對於散戶、做市商與企業，這些訊號可能直接變成被搶跑、被辨識或被排除的成本。

Ojha 談的方向不是把一切關進黑箱，而是把「可用」與「可見」拆開。下一個程式未必需要讀到原始持倉，可能只需要知道一個條件是否成立、一次授權是否有效，或一筆交易是否符合規則。這讓協定能保留協作，卻縮小不必要的揭露面。

原始狀態帳戶、部位與策略不必預設公開

受限證明只輸出下一步真正需要的條件

協定互動合約依可驗證結果接續執行

可追責規則授權、例外與升級仍可被檢查

PART 3 ｜隱私不是單一開關

訪談把隱私從一個口號拆成多層問題。有人不想公開資產餘額；有人不想讓錢包行為被拼成身分；交易者不想在成交前暴露意圖；開發者則需要在不洩漏敏感資料的前提下除錯與整合。它們不會被同一項技術自動解決。

這也是為何 ZK、TEE、加密、權限系統與協定層設計必須一起被討論。技術選擇會改變成本、延遲、誰需要被信任，以及出事時誰能撤銷或修補。把「有隱私」當成產品標籤，反而會掩蓋這些真正影響使用者的差異。

資料隱私哪些金額、內容與關係不應成為公開索引。

意圖隱私在交易完成前，誰能知道你準備做什麼。

治理隱私規則如何變更、例外由誰授權、記錄是否可追溯。

PART 4 ｜把選擇權寫進協定

隱私不等於拒絕監管、審計或合作。更困難的工作，是設計不同情境下可被揭露的最小資訊：使用者能否證明資格而不交出整份資料？機構能否滿足合規要求而不建立永久可追蹤的資料庫？協定能否處理爭議而不讓管理者取得無限制的後門？

Ojha 的經驗提醒了一個產品順序：先定義使用者要保護的行為與風險，再選技術。若規則只寫「我們很重視隱私」，權力仍會留在預設可看、預設可蒐集的一方；若規則清楚寫出資料用途、存取條件與退出方式，使用者才真的有選擇。

隱私不是讓系統少知道一點，
而是讓使用者重新決定：
誰可以因為什麼理由知道什麼。

可驗證性、可組合性與隱私可以共存；前提是協定把揭露、授權與例外做成可被檢查的規則。

Zero Knowledge Podcast Episode 397 保留 Dev Ojha 對 Osmosis、Cosmos、隱私、可組合性與下一代協定設計的完整討論。