वॉलेट-प्रूफ पठन

एक नोड के JSON-RPC इंटरफ़ेस पर लगभग हर पठन खुला है, क्योंकि जो यह लौटाता है वह पहले से हर नोड को प्रतिकृत है। कुछ मुट्ठी भर नहीं हैं, और उनके बीच की रेखा «क्या यह गुप्त है» नहीं है — यहाँ कुछ भी गुप्त नहीं — बल्कि «क्या इसका एक अजनबी को उत्तर देना कुछ ऐसा जोड़ता है जिसे प्रोटोकॉल जानबूझकर बिखरा हुआ छोड़ देता है»।

जो संरक्षित है वह व्यापार ग्राफ़ है

एक एंडपॉइंट जो उत्तर देता है यह वॉलेट किसके साथ व्यापार करता है, और कितनी बार किसी को भी असली व्यापार संबंधों का एक नक्शा सौंपता है: एक वॉलेट हमेशा किस व्यापारी के पास लौटता है, एक व्यस्त व्यापारी के नियमित ग्राहक कौन हैं, और इसलिए घर तक किसका पीछा करना सार्थक है। एक पीयर-टू-पीयर फिएट बाज़ार में यह एक वरीयता के बजाय एक शारीरिक-सुरक्षा प्रश्न है।

वह तर्क एक बार दिया गया और एक मेथड (getCounterparties) में लागू किया गया, जबकि वही ग्राफ़ getSettlements, getReservations और getDisputes के माध्यम से उपलब्ध रहा — जिनमें से कोई भी पैरामीटर नहीं लेता था, और सभी नेटवर्क पर हर रिकॉर्ड को दोनों पक्षों के नामित और की-सहित लौटाते थे। द्वार कमज़ोर नहीं था; उसके चारों ओर घूम लिया गया। यह एक के बजाय तीन मेथड भी थे: एक आरक्षण खरीदार को नामित करता है और उसका विज्ञापन व्यापारी को, इसलिए वही किनारा एक कदम पहले उपलब्ध था, उन व्यापारों के लिए भी जो कभी निपटे नहीं।

इसलिए सार्वजनिक पठन अब संपादित हैं, और एक पक्ष यह सिद्ध करके कि वह वॉलेट धारण करता है, अपने रिकॉर्ड पूर्ण रूप में पढ़ता है।

हैंडशेक

इस प्रोटोकॉल में कोई खाते नहीं हैं, इसलिए «क्या यह सचमुच आप हैं?» का उत्तर केवल कॉलर से कुछ ऐसा हस्ताक्षर करवाकर दिया जा सकता है जिसे वे पहले से हस्ताक्षरित नहीं कर सकते थे।

1. एक nonce माँगें

{ "method": "getWalletChallenge", "params": { "wallet": "<base64 PeerId>" } }

{ "result": { "subject": "<base64 PeerId>", "nonce": "<64 hex chars>", "expires_at": 1753800300000 } }

जारी करना जानबूझकर खुला है। उसे हस्ताक्षर करने वाली निजी कुंजी के बिना एक nonce बेकार है, और जिस चीज़ पर आप हस्ताक्षर करते हैं उसे पाने के लिए एक हस्ताक्षर की माँग करना चक्रीय होगा; प्रतिक्रिया वॉलेट के बारे में कुछ भी पुष्ट नहीं करती, यहाँ तक कि यह भी नहीं कि वह मौजूद है। चुनौतियाँ केवल मेमोरी में रहती हैं और पाँच मिनट बाद समाप्त हो जाती हैं — इतना लंबा कि एक व्यक्ति एक वॉलेट संकेत पढ़ और अनुमोदित कर सके, इतना छोटा कि एक अख़र्च nonce इधर-उधर पड़ा न रहे।

getCounterpartiesChallenge और getProviderEarningsChallenge भिन्न नामों के तहत वही जारीकर्ता हैं। एक nonce ठीक एक कॉल का उत्तर देता है, चाहे वह किसी भी इंटरफ़ेस पर खर्च हो।

2. चुनौती पर हस्ताक्षर करें

हस्ताक्षर करने के बाइट UTF-8 स्ट्रिंग हैं:

<domain>:<subject>:<nonce>

subject वह विहित base64 peer id है जिसके साथ चुनौती वापस आई, न कि जो भी base64 वर्तनी आपने भेजी। domain प्रति मेथड निश्चित है:

मेथड	डोमेन
getMySettlements	openfiat-my-settlements
getMyReservations	openfiat-my-reservations
getMyDisputes	openfiat-my-disputes
getCounterparties	openfiat-counterparties
getProviderEarnings	openfiat-earnings

डोमेन विभाजक ही वह कारण है कि एक द्वार-युक्त इंटरफ़ेस के लिए एकत्र एक हस्ताक्षर दूसरे पर प्रस्तुत नहीं किया जा सकता, भले ही दोनों अपने विषय को एक ही तरह पहचानते हों और एक ही खाते से nonce खींचते हों।

3. मेथड कॉल करें

{
  "method": "getMySettlements",
  "params": {
    "wallet": "<base64 PeerId>",
    "public_key": "<base64 raw 32-byte Ed25519 public key>",
    "nonce": "<the nonce from step 1>",
    "signature": "<base64 64-byte Ed25519 signature>"
  }
}

getMyReservations, getMyDisputes और getCounterparties ठीक वही चार फ़ील्ड लेते हैं। सार्वजनिक कुंजी wallet से पुनर्प्राप्त होने के बजाय स्पष्ट रूप से भेजी जाती है, इसलिए पहचान का दावा वह है जो कॉलर कथन करता है और नोड जाँचता है, न कि कुछ जो नोड कॉलर की ओर से अनुमान लगाता है — इसे ठीक उसी वॉलेट तक व्युत्पन्न होना चाहिए जिसके बारे में पूछा जा रहा है।

जो वापस आता है वह असंपादित है, और केवल उन रिकॉर्ड के लिए जिनका वॉलेट पक्ष है। getMyDisputes एक बैठे हुए मध्यस्थ को भी उत्तर देता है, क्योंकि पूरे मामले को पढ़ना उनका काम है।

यदि आप इसे लागू कर रहे हैं तो मायने रखने वाले विवरण

अस्वीकार, संकुचन नहीं। एक कॉलर जो वॉलेट सिद्ध नहीं कर सकता उसे एक त्रुटि मिलती है, कभी एक फ़िल्टर किया उत्तर नहीं। एक फ़िल्टरिंग कार्यान्वयन हर पास होते टेस्ट में एक जैसा दिखता है, ठीक तब तक जब तक एक रीफ़ैक्टर फ़िल्टर गिरा नहीं देता; एक अस्वीकार ज़ोर से और तुरंत विफल होता है।

जाँचों का क्रम। कुंजी-व्युत्पत्ति जाँच पहले होती है, nonce को छूने से पहले, ताकि एक अजनबी का विफल प्रयास उस nonce को खर्च न कर सके जिसे उसका असली मालिक हस्ताक्षर करने के बीच में है। फिर nonce हस्ताक्षर के सत्यापित होने से पहले खर्च हो जाता है, ताकि एक कैप्चर किए हस्ताक्षर को प्रस्तुत करना nonce को जला दे, न कि उसे फिर से चलाए।

«अज्ञात» और «पहले ही खर्च» वही त्रुटि हैं। उन्हें अलग करना यह पुष्टि करेगा कि उस विषय के लिए कोई अन्य पक्ष हैंडशेक के बीच में है।

कुछ भी नया संग्रहित नहीं होता। बकाया चुनौतियाँ मेमोरी में हैं और उत्तर उन रिकॉर्ड से माँग पर मोड़े जाते हैं जिन्हें नोड पहले से प्रतिकृत करता है। एक नोड ऑपरेटर को इसका कोई रिकॉर्ड नहीं मिलता कि किसने क्या पूछा — जो मायने रखता है, क्योंकि ऑपरेटर ठीक वह पक्ष है जिसके लिए इसे चुपचाप एक डोज़ियर नहीं बनाना चाहिए।