Fluxe: 프로그래밍 가능한 규정 준수를 갖춘 크로스체인 스테이블코인 결제를 위한 범용 개인 정보 보호 프로토콜
추상적인
규제 준수를 준수하는 여러 블록체인 네트워크에서 프라이빗 스테이블코인 전송을 지원하는 범용 프라이버시 프로토콜인 Fluxe를 소개합니다. 이 프로토콜은 하이브리드 증명 아키텍처(클라이언트 측 Groth16, 서버 측 SP1), 인덱스 머클 트리를 갖춘 기밀 UTXO 모델, 그리고 비동기 규정 준수 콜백을 위한 zk-promise를 결합합니다. 이 시스템은 자동 유동성 밸런싱 및 프로그래밍 가능한 결제 레일을 통해 크로스 체인 프라이빗 결제를 지원합니다.
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 t h _ s e c r e t Matthew ψ Bu c m )
여기서 auth\_secret a u t h _ sec r e t 는 소유자 의 개인 키에서 파생되고 \psi ψ 는 노트당 엔트로피입니다.
2.2 인덱스 머클 트리
기존의 희소 머클 트리는 멤버십 증명에 d = 256, d = 256번의 해시 연산이 필요합니다. Fluxe는 정렬된 연결 리스트 구조를 가진 인덱스 머클 트리를 사용하여 이를 d = 64, d = 64번의 연산으로 줄입니다.
각 리프 노드는 다음을 저장합니다.
잎 = \ { 값 , 다음 \ _ 인덱스 , 다음 \ _ 값 \ } 잎 = { 값 , 다음 _ 인덱스 , 다음 _ 값 }
비회원 증명 구현 :
인덱싱된 머클 트리를 사용하면 대상 주소보다 작은 가장 큰 값을 갖는 승인된 주소(낮은 무효화자)를 찾아 비멤버십임을 증명합니다.
\text{ NonMembershipProof } ( 주소 , 루트 , 증명 ) = 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 ( low_addr , root , path ) ∧ l o w _ a d d r . 값 < a d d r ∧ ( a d d r < l o w _ a d d r . n e x t _ v a l u e ∨ l o w _ a d d r . n e x t _ v a l u e = = 0 )
여기서 low\_addr = \{value, next\_index, next\_value\} l o w _ a d d r = { value , next _ ind e x , next _ v a l u e } 는 정렬 된 목록 에서 대상 주소 가 뒤에 오는 승인 된 주소 항목입니다.
증명은 다음으로 구성됩니다.
- 노드 v_i 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 기본 클라이언트 측 제재 검토
기본적인 규정 준수를 위해 가장 기본적인 요건은 거래 주소가 승인되지 않았음을 증명하는 것입니다. 이는 플래그가 지정된 주소에 대한 약속을 기반으로 클라이언트 측 영지식 증명을 통해 구현됩니다.
제재 목록 공약 :
이 프로토콜은 승인된 주소에 대한 머클 트리 약속을 유지합니다.
제재 \ _ 루트 = \ text { MerkleRoot } ( \ { addr_1 , addr_2 , ... , addr_n \ } ) 제재 루트 = 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 = ∑ j 인출 _j + ∑ k 유동성 _k
크로스체인 작업의 경우 프로토콜은 다음을 조정합니다.
- 소스 체인 인출 : 소각 노트, 증거와 함께 이벤트 방출
- 메시지 전달 : CCTP(USDC의 경우) 또는 LayerZero(기타의 경우)
- 목적지 체인 입금 : 검증 후 민트 상당 지폐
유동성 라우팅 알고리즘은 다음을 기준으로 최적의 경로를 선택합니다.
비용 ( 경로 ) = 가스 _ 비용 + 브리지 _ 수수료 + 시간 _ 벌금 ÷ 지연 비용 ( 경로 ) = 가스 _ 비용 + 브리지 _ 수수료 + 시간 _ 벌금 ⋅ 지연
이 작업은 가스 비용을 지불하고 관찰된 이벤트에 대한 작업을 수행하는 데 도움이 되는 외부 관리자를 통해 수행되지만 밸런싱 기능은 허가 없이 실행되며 누구나 호출할 수 있습니다.
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 Foundation
Fluxe는 각 사용자가 상태를 포함하는 규정 준수 객체와 업데이트를 위한 고유한 nullifier를 유지하는 zk-objects 모델을 확장합니다. 객체 구조는 다음과 같습니다.
obj = \ { state , serial , cbList \ } obj = { state , serial , cbList }
여기서 state s t a t e 에는 규정 준수 정보가 포함되어 있고, serial s er i a l 은 재생 공격을 방지하는 고유 식별자이며, cbList c b L i s t 는 보류 중인 콜백을 유지 관리합니다.
객체 커밋:
cm_{obj} = \text{Commit}(state \parallel serial \parallel H ( cbList ) , r_ { obj } ) cm o b j = Commit ( state ∥ s er i a l ∥ H ( c b List ) , r o b j )
객체 업데이트는 복사-쓰기(Copy-on-write) 의미론을 따릅니다. 유효한 상태 전환을 증명하는 동시에 새로운 무효화자로 새로운 커밋을 생성합니다.
3.2 듀얼 게시판 아키텍처
시스템은 두 개의 글로벌 게시판을 유지 관리합니다.
객체 게시판( bb_{obj} b b o b j ) : 멤버십 증명을 위해 머클 트리를 사용하여 객체 커밋을 저장합니다. 트리 루트 rt_{obj} r t o b j는 모든 유효한 객체 상태를 나타냅니다.
콜백 게시판( bb_{cb} b b c b ) : 멤버십 증명과 비멤버십 증명을 모두 필요로 하는 콜백 호출을 저장합니다. 보수 집합 방식을 사용하여 사용되지 않는 티켓 공간을 범위로 분할합니다.
서명된 범위 집합을 통해 구현된 비회원 증명:
\text{비회원}(티켓) \iff \존재합니다(a,b) \in \text{범위 집합}: a < ticket < b 비회원 ( 티켓 ) ⟺ ∃ ( a , b ) ∈ RangeSet : a < ticket < b
3.3 콜백 생성 프로토콜
사용자는 \text{ExecMethodAndCreateCallback} ExecMethodAndCreateCallback 알고리즘을 통해 트랜잭션 실행 중에 규정 준수 콜백을 생성합니다.
1단계 : 규정 준수 제공자의 공개 키에서 재정렬된 티켓을 생성합니다.
티켓 = pk_ { 준수 } \ cdot r ^ { sk_ { 사용자 } } \ mod p 티켓 = pk 준수 ⋅ r s k 사용자 모드 피
여기서 r r 은 암호학적 난수이고 sk_{user} s k u s e r 은 사용자의 서명 키입니다.
2단계 : 만료 및 암호화를 사용하여 콜백 항목을 만듭니다.
cb_ { entry } = \ { 티켓 , 만료 _ 시간 , enc_ 키 , 메서드 _id \ } c b e n t r y = { 티켓 , 만료 _ 시간 , enc_ 키 , 메서드 _id }
여기서 enc\_key = \text{KDF}(user \ _secret , ticket ) en c _ k e y = KDF ( user _ secret , ticket ) 는 콜백 별 암호화 를 위한 것 입니다 .
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 erial = 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 에 게시하여 콜백을 호출합니다.
호출 = \ { 티켓 , \ text { Enc } _ { enc \ _key } ( 인수 ) , 타임 스탬프 , \ sigma \ } 호출 = { 티켓 , Enc e n c _ 키 ( 인수 ) , 타임 스탬프 , σ }
여기서 \sigma σ는 티켓을 공개 키로 사용 하는 ( 티켓 , 인수 , 타임 스탬프 ) ( 티켓 , 인수 , 타임 스탬프 ) 에 대한 서명 입니다 .
사용자는 \text{ScanOne} ScanOne 알고리즘을 통해 콜백을 처리합니다.
1단계 : cbList c b L i s t 에서 보류 중인 콜백을 반복합니다.
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 .ticket e t = c b e n t r y .ticket e t
3단계 : 발견되고 유효한 경우:
- 인수 복호화: args = \text{Dec}_{enc\_key } ( invocation.args ) a r g s = Dec e n c _ key ( inv o c a t i o n . a r g s )
- 메서드 실행 : state ' = method ( state , args ) s t e ′ = method ( s t a t e , args )
- 콜백 목록에서 제거: 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{링크}(티켓_{생성}, 티켓 _ { 호출 } ) = 1 ] \ leq \ text { negl } ( \ lambda ) Pr [ 링크 ( 티켓 생성 , 티켓 호출 ) = 1 ] ≤ negl ( λ )
sk_{user} 의 k u s e r 또는 r 에 대한 지식 없이.
서명 기반 티켓을 통한 진위성 : 티켓은 서명 체계에서 검증 키 역할을 합니다.
\text{Verify}(티켓, (인수, 타임스탬프 ) , \ sigma ) = 1 \ iff \ text { 유효한 호출 } Verify ( 티켓 , ( 인수 , 타임 스탬프 ) , σ ) = 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 보류\_콜백: \text{목록}[콜백 항목], 보류 중인 콜백 : 목록 [ 콜백 항목 ] ,
\quad 위험\_점수 \in [0, 2^{32}), 위험 _ 점수 ∈ [ 0 , 2 32 ) ,
\quad 관할권\_플래그: \text{BitSet}, 관할권 _ 플래그 : BitSet ,
\quad 거래\_한도: \{일일, 월간, 연간\}, 거래 제한 : { 매일 , 월별 , 연간 } ,
\quad 평판\_벡터: \mathbb{R}^n 평판 벡터 : R n
\} }
상태 전환 함수 :
\text{CreateTxCallback}(S, tx_data ) \ rightarrow S ' CreateTxCallback ( S , tx_data ) → S ' :
- 거래 위험 분석 : 위험 = \ text { RiskScore } ( tx \ _data , S.reputation \ _vector ) 위험 = RiskScore ( tx_data , S.reputation_vector )
- 위험 임계값을 기반으로 콜백 생성
- 보류 목록 업데이트: S'.pending = S.pending \cup \{\text{새 콜백}\ } S ′ .p e n d i n g = S .p e n d i n g ∪ { 새 콜백 }
\text{ProcessCallback}(S, result) \ rightarrow S ' ProcessCallback ( S , result ) → S ' :
- 준수 수준 업데이트
