作者：Starknet
來源：https://blog.cashu.space/bringing-zero-knowledge-proofs-to-cashu/
在本文中，我們會探究 “零知識證據” 如何讓帶有任意花費條件（由一種圖靈完備的編程語言指定）的 ecash token 可以交換，而 不會 犧牲隱私性。
Cashu 協議概述
以下是對 “Cashu” 協議的一個概括性介紹，想了解其中的細節，要閱讀協議文檔：Cashu NUTs (Notation, Usage, and Terminology)
Cashu 是一種自由且開源的 Chaumian ecash 協議（Chaum, 1982），允許近乎免費、保護隱私的比特幣交易，通過電子 token 實現；這些電子 token 就類似於紙幣和硬幣，由用戶保存。
Cashu 協議定義了三方之間的交互：
發送者（Alice）：傳輸 token 給 ……
接收者（Carla）：接收 token 。
鑄幣廠（Bob）：一個第三方，允許 Alice 和 Carla 執行以下操作：
鑄幣：用戶通過閃電網絡發送比特幣，以鑄造 cashu token
- Alice 發信號給 Bob，表明自己想要鑄造價值一定數額的 cashu token
- 然後，Bob 生成價值該數額的閃電發票，並交給 Alice
- 收到支付後，Bob “盲簽名” 由 Alice 定義的一些秘密值
- 然後，Alice 可以通過解除盲化來獲得 Bob 的簽名，從而生成 cashu token
- 然後，Alice 就可以發送這些 token —— 本質上就是揭曉的秘密之，以及 Bob 對它們的（解除盲化的）簽名 —— 給 Carla
（譯者注：在 Cashu 協議中，token 都有標準化的面額，是 2 的冪數，所以，用戶一次鑄造不是得到一個 token，而是得到多個組合出所需數額的 token）
互換：用其它 cashu token 創建 cashu token
- Carla 發信號給 Bob，表明自己想要互換一個 token（需要把 token 發送給 Bob）
- Bob 驗證了 token 之後，就盲簽名由 Carla 定義的一些新的秘密值，並作廢 Carla 用來交換的 token
- 此外，就像現金的找零一樣，Carla 也可以請求將 token 分割成其它面額，比如，將一個價值 32 “聰” 的 token 分割成兩個價值 16 聰的 token
熔化：使用 cashu token 換回比特幣
- Alice 發信號給 Bob，表示她希望熔化一些 token
- 她把 cashu token 和等價值的閃電發票發送給 Bob
- Bob 驗證了這些 token 之後，就支付閃電發票，並作廢掉這些熔化的 token
案例：Alice 發送 100 聰給 Carla
（以下這個案例是在 cashu.me 網頁版錢包中展示的。）
使用一個更加具體的例子。假設 Alice 測 cashu 錢包中有充足的資金，希望發送價值 100 聰的 ecash 給 Carla 。
- 在 “發送” 頁面，Alice 的錢包軟件將保證她持有至少價值 100 聰的 token 。如果她的餘額超過這個數額，但她的 token 無法恰好組合成 100 聰，而錢包向鑄幣廠執行互換操作。
- 然後，Alice 序列化要發送的 token
- 然後，Alice 就可以把序列化形式的 token 發送給 Carla了（通過通信通道）
- 在 “收款” 環節，Carla 立即拿收到的 token 執行互換。如前所述，互換將讓 Bob 作廢掉用來互換的 token、使用由 Carla 定義的秘密值來創建新的 token，從而完成 token 價值的所有權的轉移
花費條件
Alice 可能想要發送不能被任意花費、只能由某一個公鑰的主人來花費的 token 。這就產生了 “花費條件” 的概念。
token 上的花費條件使得一個 token 僅在能夠提供滿足條件的 “見證（witness）” 時才互換或者熔化。
為了在一些 cashu token 上設定花費條件，在鑄造或者互換環節，秘密值必須遵循約定好的秘密值格式。
比如說，如果條件是 Carla 是某個公鑰的持有者，那麼 Alice 的秘密值必須遵循 “支付給公鑰（P2PK）秘密值格式”。
還是使用我們前面的這個例子，在倒數第二步中，如果這個序列化的 token 價值 100 聰、包含了一個這樣的秘密值：
那麼，Calir 若要收款（也就是互換 token），她就必須提供這個公鑰的有效簽名作為見證。如果 Carl 提供的所有的簽名都得到了在 secret.data 中的公鑰的驗證，那麼 Bob 就執行互換。
當前，Cashu 協議只支持兩種花費條件（P2PK、HTLC）。新型的花費條件的實現需要修改許多活動部分，而且可能非常麻煩。為了解決這些問題，我們引入了一種新的保護隱私的、任意的花費條件，我們稱為 “Cairo 花費條件”。
STARK 證明的計算
Cairo 花費條件允許將任意 Cairo 程序的有效執行設定為花費條件。花費者所提供的見證是被指定的 Cairo 程序的零知識的執行證據、其輸出與條件匹配。
（非常）簡短的 Cario 和 STARK 介紹
“STARK 證據” 用來非常高效地驗證一段計算的正確性（遠遠快於計算本身需要的時間），而無需揭曉計算的輸入數據（這種屬性被稱為 “零知識性”）。
“Cairo” 是一種編程語言，專門設計成與 STARK 證據一起使用，它將人類可讀的代碼編譯為一組多項式求值約束（polynomial evaluation constraints）（證明系統處理的是一個大的有限域 Fp 中的多項式，而一個 Cairo 程序的字節碼則是 Fp 中的一個數值數組）。
我們舉個例子，以下這個 Cairo 程序 fibonacci: Fp → Fp 計算了第 n 個斐波那契數對 p 求模的結果：
計算出下列結果需要花大約 500 毫秒：
然後，我們可以使用 stwo-cairo ，生成一個 STARK 證據來斷言這段計算的正確性。
給定 fibonacci 的字節碼、輸出 c 以及這個 STARK 證據，一個專門的驗證器可以斷言這個語句的有效性：∃n : fibonacci(n) = c ，不需要知曉 n，也不需要運行 fibonacci 計算，只需要 50 毫秒！
你可以在 stwo-cairo.vercel.app 網頁上嘗試這個例子。
現在，如果我們將 fibonacci 替換成我們喜歡的某一種數字簽名方案的驗證函數的實現，我們就獲得了一種定製化的 P2PK 條件！我們來看看它實際上是怎麼工作的。
Cairo 花費條件
（發送者）設定條件：
在發送一個 token 的時候，用戶可以通過指定一個編譯好的程序的哈希值以及輸出條件的哈希值，來添加一個 Cairo 花費條件。
這個程序（以及輸出條件）可能需要通過獨立的通信通道分享給接收者。
（接收者）花費被鎖定的 token：
任何想要花費這個 token 的用戶都不得不運行這段程序、匹配發送者所要的那個輸出條件，然後生成這段計算的 STARK 證據 —— 最後由鑄幣廠來驗證。
關於隱私性的要點
在上面這種設置中，鑄幣廠將在用戶花費一個 token 時知道這個程序的字節碼（這是驗證證據的前提）。
在隱私性非常緊要的情形中，我們可以在原本的程序上使用一種 bootloader 。
這種 bootloader 是一個 Cairo 程序，就像一個虛擬機，它會執行原本的程序，然後輸出 (program_hash, program_output)。
我們可以這樣修改花費條件：
程序哈希值→bootloader_program_hash輸出條件→(program_hash, output_condition)
從此，鑄幣廠將只能知道這個 bootloader 的字節碼，而原本的程序則自始至終對鑄幣廠保持隱秘！
我們的工作
要了解更多細節，請看我們的 NUT 提議，以及這個我們創建的 typescript 語言的代碼庫，用於在瀏覽器中用客戶端證明 Cairo 程序！
樣品視頻
（完）
