एक सार्वजनिक पठन क्या लौटाता है

getSettlement, getSettlements, getReservation, getReservations, getDispute और getDisputes खुले, अप्रमाणित पठन हैं और वे अब पक्ष की पहचान नहीं लौटाते। एक पक्ष वॉलेट-प्रूफ मेथड के माध्यम से अपने रिकॉर्ड पूर्ण रूप में पढ़ता है।

प्रमाणन के बजाय संपादन क्यों

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

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

यह ईमानदारी से कितना मूल्यवान है

ये रिकॉर्ड हर नोड को gossip किए जाते हैं। कोई भी जो एक चलाता है सब पढ़ता है, और संपादन इसे नहीं बदलता। जो संरक्षित है वह क्वेरी की आसानी है — किसी और के सार्वजनिक एक्सेस नोड को curl करने और नेटवर्क को अनुक्रमित करने के लिए एक नोड खड़ा करने के बीच का अंतर। वह अंतर आकस्मिक कटाई का अधिकांश हिस्सा है।

इसे स्पष्ट रूप से कहना जितना लगता है उससे अधिक मायने रखता है: एक इंटीग्रेटर जो मानता है कि ये रिकॉर्ड गोपनीय हैं, वह कुछ ऐसा बनाएगा जो प्रोटोकॉल द्वारा न दी गई एक गारंटी पर टिका होगा।

आकार

Settlement

रखा गया	हटाया गया
id, reservation_id, amount, state	buyer, buyer_public_key
escrow_release_signature	seller, seller_public_key
payment_submitted_at, merchant_responded_at	payment_reference
payment_discrepancy, created_at, updated_at

escrow_release_signature बना रहता है क्योंकि यह एक ऑन-चेन लेनदेन को नामित करता है जिसे कोई भी पहले से Solana पर पढ़ सकता है, और यही एक निपटान को स्वतंत्र रूप से जाँच-योग्य बनाता है।

payment_reference यकीनन दोनों हटावों में बदतर है: यह मुक्त पाठ है जिसमें एक खरीदार अपना बैंक संदर्भ डालता है, इसलिए यह नियमित रूप से एक असली नाम या एक खाता संख्या ले जाता है।

Reservation

रखा गया	हटाया गया
id, advertisement_id, amount, state	requester
requested_at, updated_at, expires_at	requester_public_key

advertisement_id जानबूझकर रखा गया है। एक विज्ञापन एक सार्वजनिक प्रस्ताव है और पहले से हर ऑर्डर-बुक पंक्ति पर अपने व्यापारी का peer id ले जाता है, इसलिए यह एक ऐसे किनारे का एक छोर उजागर करता है जो कभी निजी नहीं था। जो यह उजागर नहीं करता वह दूसरा छोर है — जो इसे एक किनारा बनाता है।

Dispute

रखा गया	हटाया गया
id, settlement_id, status, resolution	buyer, seller, opener और उनकी कुंजियाँ
required_arbitrators, arbitrators_seated	reason
commitments, reveals (गणनाएँ)	arbitrators, arbitrator_keys
onchain_execution_signature	अलग-अलग प्रतिबद्धताएँ और रिवील
opened_at, updated_at	आपसी-निपटान सहमति ध्वज

ध्यान दें कि यहाँ commitments और reveals गणनाएँ हैं, सूचियाँ नहीं — इतना कि एक एक्सप्लोरर एक मामले को आगे बढ़ते दिखा सके, बिना किसी का मत उसके नाम से जुड़े।

जो गिराया जाता है उसके तीन अलग कारण। पक्ष, क्योंकि एक विवाद वही मामला है जहाँ यह जानना कि किसका किससे झगड़ा हुआ, सबसे स्पष्ट रूप से दुरुपयोग के लायक है। reason, क्योंकि यह असली पैसे को लेकर एक असली असहमति के बारे में मुक्त पाठ है और सहज रूप से लोगों, बैंकों और संदर्भों को नामित करता है। मध्यस्थ सूचियाँ, क्योंकि एक मध्यस्थ एक पंजीकृत प्रदाता है जिसकी पहचान स्वयं कोई रहस्य नहीं है — पर कौन-सा मध्यस्थ कौन-सा मामला मिला, और उन्होंने कैसे मत दिया ठीक वह जोड़ी है जो एक पर दबाव डालना सार्थक बनाती है। आपसी-निपटान ध्वज उनके साथ जाते हैं: «विक्रेता सहमत है और खरीदार नहीं» एक बातचीत की स्थिति है, और उसे दर्शकों को प्रकाशित करना दो लोगों के बीच एक बातचीत को बदल देता है।

यदि आप एक फ़ील्ड जोड़ रहे हैं

एक फ़ील्ड एक सार्वजनिक दृश्य में केवल तभी शामिल है जब वह लोगों के बजाय व्यापार के बारे में कुछ कहती है। संदेह में यह बाहर रहती है: बाद में एक जोड़ना एक रिलीज़ नोट है, और एक हटाना एक प्रकटीकरण है जो पहले ही हो चुका।