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