Fluxe：具有可編程合規性的跨鏈穩定幣支付通用隱私協議

avatar
Ethereum Research
07-08
本文為機器翻譯
展示原文

Fluxe：具有可編程合規性的跨鏈穩定幣支付通用隱私協議

抽象的

我們推出 Fluxe，這是一個通用的隱私協議，支持跨多個區塊鏈網絡進行隱私穩定幣轉移，並符合監管要求。該協議結合了混合證明架構（客戶端 Groth16，服務器端 SP1）、帶有索引默克爾樹的機密 UTXO 模型，以及用於異步合規回調的零知識證明承諾 (zk-promises)。該系統支持跨鏈隱私支付，並具備自動流動性平衡和可編程支付通道。

1. 簡介

當前的隱私協議面臨著隱私、合規性和跨鏈互操作性的三難困境。Fluxe 通過 zk-promises 集成解決了這一難題，實現了異步合規性判斷，同時又不損害交易隱私。

2. 技術架構

2.1 機密UTXO模型

每個音符N N定義為：
N = \ {資產類型、價值、所有者、 \ psi 、鏈提示、合規性數據、沿襲哈希、池ID 、回調} N = {資產類型、價值、所有者、 ψ 、鏈提示、合規性數據、沿襲哈希、池ID 、回調}​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

票據承諾的計算方法如下：

cm = H (資產類型\平行值\平行所有者\平行\ psi \平行鏈提示\平行合規數據\平行沿襲哈希\平行池ID \平行H (回調) ) cm = H (設置_類型∥價值∥所有者∥ ψ ∥鏈_提示∥合規_數據∥線_哈希∥池_ ID ∥ H (回調) )​​​​​​​​​​​​​​​​

無效符派生可防止雙重支付：

nf = H(auth\_secret \parallel \psi \parallel cm ) n f = H ( a u th _ s e c r e t ∥ ψ ∥ cm )

其中auth\_secret a u t h _ s e c r e t來自所有者的私鑰， \psi ψ是每個註釋的熵。

2.2 索引 Merkle 樹

傳統的稀疏默克爾樹需要d = 256次哈希運算來進行成員證明。Fluxe 使用帶有排序鏈表結構的索引默克爾樹，將運算次數減少到d = 64次。

每個葉節點存儲：
葉子節點 = \{值，下一個索引，下一個值\ } l e a f = { v a l u e ， next _ i n d e x ， next _ v a l u e }

非會員證明實施：
使用索引 Merkle 樹，通過查找低無效符（最大值小於目標地址的認可地址）來證明非成員資格：

\text{ NonMembershipProof } ( addr , root , proof ) = NonMembershipProof (地址，根，證明) =

\begin{cases}\text{MerkleProof}(low\_addr, root, path) \land \\low\_addr.value < addr \land \\(addr < low\_addr.next\_value \lor low\_addr.next\_value == 0)\end{cases} ⎧ ⎨ ⎩ MerkleProof ( l o w _ a d d r , r o o t , p a t h ) ∧低_地址.值<地址∧​​​​​​​​​​​​ （ addr < low_addr.next_value∨low_addr.next_value == 0 ）​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

其中low_addr = \{value, next_index, next_value\} l o w _ a d d r = { v a l u e , n e x t _ i n d e x , n e x t _ v a l u e }是目標地址在排序列表中位於其後的認可地址條目。

證明內容包括：

  • 節點v_i的 Merkle 路徑v i （64 個哈希值）
  • 驗證v_i.next\_value = v_{i+1} v i . n e x t _ v a l u e = v i + 1
  • 範圍檢查： v_i < v < v_{i+1} v i < v < v i + 1

2.3 混合證明系統

客戶端電路（Groth16） ：

存款電路：

 Public: deposit_amount, asset_type, tx_hash, cm_out Private: owner_secret, ψ Constraints: - Verify deposit transaction validity- cm_out = H(asset_type || deposit_amount || owner || ψ || ...)

傳輸電路：

 Public: nf _in, cm_ out, merkle _rootPrivate: note_ in, auth _secret, note_ outConstraints: - nf _in = H(auth_ secret || note _in.ψ || note_ in.cm) - MerkleProof(note _in.cm, merkle_ root) - value _in ≥ value_ out + fee - cm _out = H(note_ out)

取款電路：

 Public: nf, amount, dest_chain, recipient Private: note, auth_secret Constraints: - nf = H(auth_secret || note.ψ || note.cm)- amount ≤ note.value- dest_chain ∈ supported_chains

服務器端驗證（SP1） ：

SP1 使用groth16_bn254預編譯驗證客戶端 Groth16 證明並執行批量狀態更新：

 fn verify_and_update_state (old_root: [ u8 ; 32 ],groth16_proofs: Vec <Groth16Proof>,public_inputs: Vec <PublicInputs>) -> [ u8 ; 32 ] { for (proof, inputs) in groth16_proofs. zip (public_inputs) {groth16:: verify (proof, inputs);} let new_nullifiers = extract_nullifiers (public_inputs);indexed_merkle_tree:: batch_insert (old_root, new_nullifiers)}

2.4 客戶端制裁篩查基本信息

為了實現基本合規性，最基本的要求是證明交易地址未受到制裁。這可以通過客戶端對標記地址的承諾進行零知識證明來實現。

制裁名單承諾：
該協議維護對受認可地址的 Merkle 樹承諾：

制裁\_root = \text{MerkleRoot}(\{addr_1 , addr_2 , ... , addr_n \ } ) s a n c t i o n s _ r o o t = MerkleRoot ( { addr 1 , addr 2 , . . . , addr n } )

其中每個addr_i a d d r i都是一個認可的地址哈希。

基本制裁篩查流程：

 Public: sanctions_root, tx_valid Private: sender_addr, recipient_addr, sanctions_proof_sender, sanctions_proof_recipient Constraints: - NonMembershipProof(sender_addr, sanctions_root, sanctions_proof_sender)- NonMembershipProof(recipient_addr, sanctions_root, sanctions_proof_recipient)- tx_valid = (sender_proof_valid ∧ recipient_proof_valid)

注意：雖然基本的制裁篩查是在客戶端進行的，但該系統的真正優勢在於其能夠通過回調來追溯執行合規性。請參閱第 3.10 節，瞭解如何在交易後發現合規性問題並凍結資產。

2.5 跨鏈橋協議

橋樑合約保持不變性：

\sum_{i} 存款_i = \sum_{j} 提款_j + \sum_{k} 流動性\_k ∑ i d e p o s i t s i = ∑ j w i t h d r a w a l s j + ∑ k l i q u i d i t y _ k

對於跨鏈操作，協議協調：

  1. 源鏈提現：銷燬票據，發出帶有證明的事件
  2. 消息傳遞：CCTP（用於 USDC）或 LayerZero（用於其他）
  3. 目標鏈存款：驗證後鑄造等值紙幣

流動性路由算法根據以下因素選擇最佳路徑：

成本（路徑） = gas_cost +橋接費用+時間懲罰\ cdot延遲成本（路徑） = gas_cost +橋接費用+時間懲罰⋅延遲​​​​​​​​​​​​​​​​​​​​​

這是通過外部管理員來完成的，他們幫助支付 gas 並對觀察到的事件執行此操作，儘管平衡功能是無需許可的，任何人都可以調用。

2.6 與 Twine 多結算網絡集成

Fluxe 作為 Twine 多結算基礎設施之上的應用層運行，利用其輕客戶端架構實現跨鏈功能：

  • 輕客戶端驗證：Twine 為每個支持的鏈維護輕客戶端，以驗證狀態轉換
  • 跨鏈證明：狀態更新在遠程鏈上接受之前通過輕客戶端證明進行驗證
  • 異步結算：每個鏈在輕客戶端驗證後處理 Fluxe 狀態更新
  • 信任最小化橋樑：通過輕客戶端狀態證明驗證資產轉移

這種架構使得 Fluxe 能夠通過加密驗證而不是共識來實現跨鏈互操作性，同時保持隱私。

 ┌────────────────────────────────────────────────────────┐│ TWINE ││ ││ ┌──────────────────────────────────────────────────┐ ││ │ FLUXE │ ││ │ │ ││ │ • Nullifier Tree (IMT) │ ││ │ • Commitment Tree │ ││ │ • Transfer Proofs (Groth16) │ ││ │ • Compliance Callbacks │ ││ │ • SP1 Verification │ ││ └──────────────────────────────────────────────────┘ ││ ↑ ││ Light Clients │└─────────────────────────┼──────────────────────────────┘↓┌──────────┐ ┌──────────┐│ Ethereum │ │ Solana ││ Bridge │ │ Bridge │└──────────┘ └──────────┘(Deposit/ (Deposit/Withdraw) Withdraw)

3. zk-Promises 集成以實現異步合規性

3.1 zk-Objects基金會

Fluxe 擴展了 zk-objects 模型，其中每個用戶維護一個包含狀態的合規性對象，以及用於更新的唯一 nullifier。對象結構如下：

obj = \{state，serial，cbList\} o b j = { s t a t e ， s e r i a l ， c b L i s t }

其中state s t a t e包含合規性信息， serial s er i a l是防止重放攻擊的唯一標識符， cbList c b L i s t維護待處理的回調。

對象承諾：
cm_{obj} = \text{Commit}(狀態 \parallel 串行 \parallel H(cbList), r_{obj}) c m o b j = Commit ( s t a t e ∥ s e r i a l ∥ H ( c b L i s t ) , r o b j )

對象更新遵循寫時複製語義：使用新的無效符創建新的承諾，同時證明有效的狀態轉換。

3.2 雙公告板架構

系統維護兩個全局公告板：

對象公告板 ( bb_{obj} b b o b j ) ：使用 Merkle 樹存儲對象承諾，用於成員資格證明。樹根rt_{obj} r t o b j表示所有有效的對象狀態。

回調公告板 ( bb_{cb} b b c b ) ：存儲需要成員資格和非成員資格證明的回調調用。使用補集方法將未使用的票據空間劃分為不同範圍。

通過簽名範圍集實現的非會員證明：
\text{非會員}(票證) \iff \exists (a,b) \in \text{RangeSet}: a <票證< b非會員(票證) ⟺ ∃ （ a ， b ） ∈RangeSet ： a < ticket < b​​​​​​

3.3 回調創建協議

用戶通過\text{ExecMethodAndCreateCallback} ExecMethodAndCreateCallback算法在交易執行過程中創建合規回調：

步驟 1 ：根據合規提供商的公鑰生成重新隨機化的票證：
ticket = pk_{compliance} \cdot r^{sk_{user}} \mod p t i c k e t = p k c o m p l i a n c e ⋅ r s k u s e r模組頁

其中r r是加密隨機數， sk_{user} s k u s e r是用戶的簽名密鑰。

步驟 2 ：創建具有到期和加密的回調條目：
cb_{entry} = \ { ticket , exp_time , enc_key , method_id \ } c b e n t r y = { t i c k e t , exp _ t i m e , enc _ key , method _ i d }

其中enc\_key = \text{KDF}(user\_secret , ticket ) enc_key = KDF ( u s e r_s e c r e t , t i c k e t )用於每個回調加密。

步驟 3 ：使用新的回調列表更新對象：
obj'.cbList = obj.cbList \parallel cb_ { entry } o b j ′ .c b L i s t = o b j.c b L i s t ∥ c b e n t r y
obj'.serial = \text{Fresh}() o b j ′ . s e r i a l = Fresh ( )

步驟 4 ：生成有效轉換的 ZK 證明：

 Public: cm_old, cm_new, method_idPrivate: obj_old, obj_new, r_old, r_new, cb_entryConstraints:- cm_old = Commit (obj_old, r_old)- cm_new = Commit (obj_new, r_new)- obj_new.cbList = obj_old.cbList || cb_entry- obj_new.state = ValidTransition (obj_old.state, method_id)

3.4 回調調用與處理

合規提供商通過發佈到bb_{cb} b b c b來調用回調：

調用= \ { ticket ， \ text { Enc } _ { enc \ _key } ( args ) ，時間戳， \ sigma \ }調用= { ticket ， Enc_key ( args ) ，時間戳， σ }​​​​​​

其中\sigma σ是使用票證作為公鑰對( ticket , args , timestamp ) ( ticket , args , timestamp )進行的簽名。

用戶通過\text{ScanOne} ScanOne算法處理回調：

步驟 1 ：遍歷cbList中的待處理回調
步驟 2 ：檢查bb_{cb} b b c b中的成員資格：
\exists 調用 \in bb_{cb}: invocation.ticket = cb_{entry } .ticket ∃ in v o c a t i o n ∈ b b c b : in v o c a t i o n . t i c k e t = c b e n t r y . t i c k e t

步驟 3 ：如果找到並且有效：

  • 解密參數： args = \text{Dec}_{enc\_key}(invocation.args) a r g s = Dec e n c _ k e y ( i n v o c a t i o n . a r g s )
  • 執行方法： state' = method(state, args) s t a t e ′ = m e t h o d ( s t a t e , a r g s )
  • 從回調列表中刪除： cbList' = cbList \setminus \{cb_{entry}\} c b L i s t ′ = c b L i s t ∖ { c b e n t r y }

步驟 4 ：生成正確處理證明：

 Public: cm_old, cm_new, timestampPrivate: obj_old, obj_new, args , cb_entryConstraints:- ValidDecryption(cb_entry.enc_key, invocation. args , args )- obj_new.state = ExecuteMethod(obj_old.state, args )- obj_new.cbList = obj_old.cbList \ {cb_entry}- timestamp < cb_entry.exp_time

3.5 安全屬性和不可鏈接性

取消創建和調用的鏈接：重新隨機化方案確保：
\Pr[\text{Link}(ticket_{create}, ticket_{invoke } ) = 1 ] \ leq \ text { negl } ( \ lambda ) Pr [鏈接( ticket_ { create } , ticket_ { invoke } ) = 1 ] ≤ negl ( λ )

無需瞭解sk_{user} s k u s e r或r r 。

通過基於簽名的票證實現真實性：票證在簽名方案中充當驗證密鑰：
\text{驗證}(ticket, (args, timestamp ) , \ sigma ) = 1 \ iff \ text {有效調用} Verify ( ticket , ( args , timestamp ) , σ ) = 1 ⟺有效調用

保密性：每個回調加密可防止未經授權的訪問：
\text{Enc}_{enc\_key}(args) \text{ 計算上與隨機不可區分} Enc e n c _ k e y ( a r g s )計算上與隨機不可區分

3.6 合規狀態機實現

增強支付協議的合規狀態：

S = \{ S = {
\quad 合規性\等級 \in \{0,1,2,3\}，合規性_級別∈ { 0 , 1 , 2 , 3 } ,​​​​​​​​​​​
\quad 上次審核時間 \in \mathbb{N}，上次評論時間∈N ，​​​​​​​​​​​​​​
\quad pending_callbacks:\text{List}[CallbackEntry]，待處理_回調：列表[回調入口] ，​​​​​​​​​​​​​​​​​​​​​​​​
\quad 風險評分 \in [0, 2^{32}),風險得分∈ [ 0,232 ) ,​​​​​​​​ ​​​
\quad 管轄區\_標誌：\text{BitSet}，管轄權標誌： BitSet ，​​​​​​​​​​​​​​​​
\quad 交易限制：\{每日、每月、每年\}，交易限制： {每日、每月、每年} ，​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​
\quad 聲譽向量：\mathbb{R}^n聲譽_向量： R n​​​​​​​​​​​​​​
\} }

狀態轉換函數：

\text{CreateTxCallback}(S, tx\_data) \rightarrow S' CreateTxCallback ( S , t x _ d a t a ) → S ′ :

  • 分析交易風險： risk = \text{RiskScore}(tx\_data, S.reputation\_vector) r i s k = RiskScore ( t x _ d a t a , S . r e p u t a t i o n _ v e c t o r )
  • 根據風險閾值生成回調
  • 更新待處理列表： S'.pending = S.pending \ cup \ { \ text { newcallbacks } \ } S ′ . pending = S . pending ∪ { newcallbacks }

\text{ProcessCallback}(S, result) \ rightarrow S ' ProcessCallback ( S , result ) → S ′ :

  • 更新合規水平： S ' .level = f ( S.level , result.determination ) S ′ . l e v e l = f ( S . l e v e l , result . determination )​​​
  • 調整風險評分： S'.risk\_score = \text{UpdateRisk}(S.risk\_score, result) S ′ . r i s k _ s c o r e = UpdateRisk ( S . r i s k _ s c o r e , r e s u l t )
  • 如有必要，修改限制： S'.limits = \text{AdjustLimits}(S.limits, result) S

相关赛道:
生成式AI
智能合約公鏈
Layer 1
來源
免責聲明：以上內容僅為作者觀點，不代表Followin的任何立場，不構成與Followin相關的任何投資建議。
喜歡
1
收藏
評論
相關推薦