On-Chain Transparency: What Blockchain Data Can—and Cannot—Prove

सार्वजनिक ब्लॉकचेन एक खुला रिकॉर्ड है जिसकी कोई भी व्यक्ति स्वतंत्र रूप से जाँच कर सकता है। इससे स्क्रीनशॉट, निजी डैशबोर्ड और प्लेटफ़ॉर्म के अपने दावों पर निर्भरता कम होती है। फिर भी यह किसी परियोजना से जुड़े हर प्रश्न का उत्तर नहीं देता।

Transparency is useful only when we separate on-chain facts, interpretations, and information that exists outside the blockchain.

यह लेख केवल शैक्षिक उद्देश्यों के लिए है। सार्वजनिक on-chain डेटा किसी प्रोजेक्ट की सुरक्षा, अखंडता या प्रतिफल की गारंटी नहीं देता।

“On-chain” का क्या अर्थ है

On-chain डेटा ब्लॉकचेन के इतिहास या उसकी वर्तमान स्थिति में दर्ज होता है और नेटवर्क नोड से क्वेरी किया जा सकता है। BNB Smart Chain पर इसमें शामिल हैं:

ट्रांज़ैक्शन हैश, Status, ब्लॉक और timestamp;
sender and recipient addresses;
ट्रांसफ़र किया गया native BNB और चुकाया गया gas;
कॉन्ट्रैक्ट call डेटा;
निष्पादन के दौरान उत्सर्जित इवेंट या logs;
डिप्लॉय किया गया bytecode;
सार्वजनिक रूप से पढ़ी जा सकने वाली कॉन्ट्रैक्ट स्थिति;
native और टोकन बैलेंस;
ट्रांज़ैक्शन और ट्रांसफ़र इतिहास।

Addresses are normally pseudonymous. A string beginning with 0x does not, by itself, reveal the legal identity of its controller.

पाँच प्रश्न जिनका उत्तर on-chain डेटा दे सकता है

1. क्या कोई विशिष्ट ट्रांज़ैक्शन हुआ?

ट्रांज़ैक्शन हैश से आप सत्यापित कर सकते हैं कि ट्रांज़ैक्शन शामिल हुआ या नहीं, सफल हुआ या नहीं, किस पते ने शुरू किया, कौन-सा पता call हुआ और कौन-से logs निकले।

This is stronger evidence than a screenshot. But सफलता confirms technical execution, not the truth of a marketing claim or the economic value of the result.

2. किसी पते पर अभी कौन-सी परिसंपत्तियाँ हैं?

An explorer can show native BNB and balances of specific BEP-20 tokens. A standard token balance can also be queried with balanceOf(address).

दिखाई देने वाला बैलेंस अपने आप परियोजना का “रिज़र्व” नहीं बन जाता। ऐसा दावा करने से पहले यह स्थापित करना होगा कि:

पता प्रोजेक्ट का है या उसके नियंत्रण में है;
सभी संबंधित पते बताए गए हैं;
एसेट पहले से अन्य दायित्वों के अधीन नहीं हैं;
टोकन के पास उपयोग योग्य तरलता है;
निकासी और प्रशासकीय शक्तियाँ समझी गई हैं।

3. धनराशि कैसे स्थानांतरित हुई?

ट्रांज़ैक्शन, टोकन ट्रांसफ़र इवेंट और internal calls पतों के बीच गतिविधि का पता लगा सकते हैं। उनकी तुलना प्लेटफ़ॉर्म की प्रकाशित प्रक्रिया से की जा सकती है।

इवेंट कॉन्ट्रैक्ट कोड द्वारा बनाया गया log है। यह सिद्ध करता है कि log सफल ट्रांज़ैक्शन में दिखाई दिया, लेकिन डेवलपर द्वारा चुना गया नाम बताए गए आर्थिक अर्थ की गारंटी नहीं देता। इवेंट को state changes, कोड और वास्तविक token गतिविधि के साथ पढ़ें।

4. कौन-सा कोड डिप्लॉय किया गया?

Deployed bytecode is always public. If source code has been verified, BscScan can match it to the bytecode and expose अनुबंध पढ़ें और अनुबंध लिखें interfaces.

सोर्स सत्यापन निरीक्षण की क्षमता बढ़ाता है। यह ऑडिट नहीं है: सत्यापित कोड में फिर भी त्रुटियाँ या जानबूझकर दिए गए शक्तिशाली फ़ंक्शन हो सकते हैं।

5. पैरामीटर कौन बदल सकता है?

सोर्स कोड और read फ़ंक्शन owner, admin, operator, pauser या upgrader जैसी भूमिकाएँ दिखा सकते हैं। जाँचें कि क्या ये भूमिकाएँ यह कर सकती हैं:

कार्रवाइयाँ pause करना;
शुल्क या सीमाएँ बदलना;
टोकन mint करना;
एसेट ट्रांसफ़र करना;
proxy implementation बदलना;
नई भूमिकाएँ प्रदान करना।

प्रशासनिक भूमिका दुरुपयोग का प्रमाण नहीं है। यह विश्वास से जुड़ी निर्भरता है जिसे उपयोगकर्ताओं को समझना चाहिए।

क्या off-chain रहता है

ब्लॉकचेन सामान्यतः सीधे यह प्रमाणित नहीं कर सकता:

टीम की पहचान और कानूनी स्थिति;
off-chain कॉन्ट्रैक्ट या दायित्व;
ग्राहक सहायता की गुणवत्ता;
वेबसाइट, DNS, सर्वर या टीम डिवाइस की सुरक्षा;
मार्केटिंग की सत्यता;
बाहरी टोकन मूल्य का स्रोत और विश्वसनीयता;
वास्तविक दुनिया के एसेट का स्वामित्व;
भविष्य के प्रशासकीय निर्णय;
उपयोगकर्ता के अधिकार क्षेत्र में कानूनी अनुपालन।

एक्सप्लोरर पर दिखाई गई कुछ जानकारी off-chain भी होती है: नाम, लोगो, वेबसाइट, स्वामित्व लेबल और मूल्य चार्ट जमा किए गए मेटाडेटा या बाहरी प्रदाताओं से आ सकते हैं। BscScan स्वयं टोकन पृष्ठों को on-chain और off-chain दोनों जानकारी वाला बताता है। महत्वपूर्ण जाँच दृश्य ब्रांडिंग पर नहीं, पूरे पते और कच्चे रिकॉर्ड पर आधारित करें।

अवलोकन, व्याख्या और अनुमान

इन स्तरों को अलग रखें:

Observation:
“In block N, address A sent 100 units of token T to address B.”

Interpretation:
“According to the published architecture, B is the distribution contract.”

Assumption:
“Therefore every participant will certainly receive a future payment.”

पहला कथन सीधे on-chain जाँचा जा सकता है। दूसरे में किसी पते को भूमिका से जोड़ने के लिए दस्तावेज़ और कोड चाहिए। तीसरा भविष्य से संबंधित है और ऐतिहासिक ट्रांज़ैक्शन से सिद्ध नहीं होता।

पारदर्शिता की व्यावहारिक समीक्षा

चरण 1: सटीक पते निर्धारित करें

आधिकारिक दस्तावेज़ों से इनका नेटवर्क और पते एकत्र करें:

मुख्य कॉन्ट्रैक्ट;
यदि उपयोग हों तो proxy और implementation कॉन्ट्रैक्ट;
संबंधित टोकन;
यदि बताए गए हों तो treasury और सहायक घटक।

पूरे पते सहेजें। नाम और संक्षिप्त स्ट्रिंग पर्याप्त नहीं हैं।

चरण 2: कोड का निरीक्षण करें

On BscScan’s अनुबंध tab:

सत्यापन का प्रकार नोट करें;
जाँचें कि कॉन्ट्रैक्ट proxy है या नहीं;
वर्तमान implementation का पालन करें;
भूमिकाएँ और पैरामीटर बदलने वाले फ़ंक्शन पहचानें;
compiler और deployment जानकारी नोट करें।

यदि source सत्यापित नहीं है, तो सामान्य उपयोगकर्ता की व्यवहार जाँचने की क्षमता बहुत कम होती है।

चरण 3: वर्तमान स्थिति पढ़ें

उपयोग अनुबंध पढ़ें for read-only queries such as:

owner और भूमिका के पते;
pause Status;
वर्तमान शुल्क और सीमाएँ;
counters और साइकल Status;
जुड़े हुए कॉन्ट्रैक्ट पते।

डेटा पढ़ने के लिए हस्ताक्षर या gas की आवश्यकता नहीं होती। केवल सार्वजनिक स्थिति देखने के लिए वॉलेट कनेक्ट करने की ज़रूरत नहीं है।

चरण 4: कई ट्रांज़ैक्शन की तुलना करें

अलग-अलग परिस्थितियों के लिए जाँचें:

call किया गया फ़ंक्शन और पैरामीटर;
टोकन गतिविधि;
आंतरिक calls;
लॉग;
पहले और बाद की स्थिति।

एक ट्रांज़ैक्शन केवल एक निष्पादन पथ दिखाता है, हर संभावित व्यवहार नहीं।

चरण 5: बदलाव का इतिहास देखें

इनसे संबंधित प्रशासनिक ट्रांज़ैक्शन और इवेंट देखें:

स्वामित्व ट्रांसफ़र;
भूमिका प्रदान करना और वापस लेना;
रोक की अवस्थाएँ;
implementation upgrades के बदलाव;
पैरामीटर में बदलाव;
एसेट निकासी।

वर्तमान configuration महत्वपूर्ण है; इतिहास दिखाता है कि अधिकार वास्तव में कैसे उपयोग हुए हैं।

सामान्य गलतियाँ

“The address is public, so its owner is known.”
No. Ownership requires separate evidence.

“Funds are visible in a contract, so they are permanently locked.”
No. Code or an administrator may allow them to move.

“The source is verified, so the contract is safe.”
No. Verification matches source to bytecode; it does not assess security.

“An event is named RewardPaid, so returns are guaranteed.”
No. Developers choose event names. Verify actual state and asset movements.

“Transparency removes risk.”
No. It makes some risks observable while technical, administrative, market, and legal risks remain.

जाँच सूची

सटीक नेटवर्क और पते प्रकाशित हैं।
सोर्स सत्यापन का प्रकार ज्ञात है।
प्रॉक्सी और वर्तमान इम्प्लीमेंटेशन की जाँच की जाती है।
Owner, admin और upgrader की शक्तियाँ समझी गई हैं।
बैलेंस सटीक token पतों से जाँचे जाते हैं।
ट्रांज़ैक्शन इतिहास प्रकाशित प्रक्रिया के अनुरूप है।
On-chain तथ्यों को लेबल और व्याख्या से अलग रखा जाता है।
जिन प्रश्नों का उत्तर ब्लॉकचेन नहीं दे सकता, वे अलग सूचीबद्ध हैं।

स्रोत और आगे पढ़ने की सामग्री

BscScan Information Center — ट्रांज़ैक्शन देखना
BscScan Information Center — टोकन पृष्ठ को समझना
BscScan Information Center — कॉन्ट्रैक्ट सत्यापन के प्रकार
BscScan Information Center — पता क्या है?
Solidity Documentation — सुरक्षा संबंधी विचार
OpenZeppelin Docs — Proxy Upgrade Pattern