क्या साबित करना होता है
एक fill के रिलीज़ होने के लिए, पेमेंट साक्ष्य को ऑर्डर से मेल खाना होता है। महत्वपूर्ण फ़ील्ड हैं राशि, करेंसी, प्राप्तकर्ता, पेमेंट तरीका, समय, और पूरा किया जा रहा intent।
verifier को पूरी पेमेंट हिस्ट्री प्रकाशित करने की ज़रूरत नहीं है। उसे इतना प्रमाणित साक्ष्य चाहिए कि यह कह सके कि यह पेमेंट, इस राशि के लिए, इस payee को, इस intent से संबंधित है।
वर्तमान वेरिफ़िकेशन मॉडल
ZKP2P V3 समर्थित पेमेंट फ्लो के लिए एक TEE-hosted attestation service का इस्तेमाल करता है। service एक AWS Nitro Enclave के अंदर वेरिफ़िकेशन तर्क चलाती है, टाइप किए गए platform schemas के विरुद्ध पेमेंट डेटा की जांच करती है, और पेमेंट मेल खाने के बाद एक EIP-712 PaymentAttestation साइन करती है।
इसने कई फ्लो के लिए पुराने buyer-भारी zkTLS मॉडल की जगह ली क्योंकि browser-side प्रूफ़ generation धीमा, extension-निर्भर, और तब नाज़ुक था जब पेमेंट platforms अपने web इंटरफ़ेस बदलते थे। समझौता स्पष्ट है: हर buyer से एक स्थानीय प्रूफ़ बनवाने के बजाय hardware-attested निष्पादन और पुनरुत्पादनीय enclave builds।
TEE-TLS बनाम लेगेसी zkTLS
| प्रश्न | लेगेसी zkTLS | TEE-TLS |
|---|---|---|
| वेरिफ़िकेशन कहां चलता है | Buyer browser या extension | Nitro Enclave attestation service |
| Buyer UX | Extension/प्रूफ़ generation भारी हो सकता है | पेमेंट साक्ष्य enclave के अंदर server-side जांचा जाता है |
| वेरिफ़िकेशन तर्क | Provider templates और प्रूफ़ matching | टाइप किए गए schemas और platform-विशिष्ट transformers |
| Trust root | प्रूफ़ सिस्टम प्लस notary/proxy मान्यताएं | Hardware attestation प्लस audited enclave कोड |
| Onchain परिणाम | साइन किया गया या वेरिफ़ाई किया गया release डेटा | verifier द्वारा जांची गई EIP-712 PaymentAttestation |
गोपनीयता सीमाएं
- व्यक्तिगत पेमेंट डेटा onchain पोस्ट नहीं किया जाता।
- counterparty पेमेंट पूरा करने के लिए आवश्यक payout identifier देखता है।
- chain hashes, nullifiers, signatures, राशियां, contract पते, और release events देखता है।
- USDCtoFiat न आपका fiat अकाउंट रखता है, न आपकी private keys custody करता है, और न ही एक पेमेंट-ऐप ट्रांसफ़र को उलट सकता है।