What Is a Smart Contract—and Why Its Rules Cannot Be Changed Retroactively?

Disclaimer: This article is for educational purposes only. It is not financial, legal, or investment advice.

A smart contract is often described as a “digital agreement.” That is a useful analogy, but it is not the full picture. More precisely, a smart contract is a program deployed on a blockchain that stores data and executes predefined instructions.

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

शुरुआत से दो सीमाएँ महत्वपूर्ण हैं:

“Smart” का अर्थ यह नहीं कि प्रोग्राम सोच सकता है या इरादे का निर्णय कर सकता है।
“कॉन्ट्रैक्ट” शब्द कोड को अपने-आप किसी कानूनी समझौते का दर्जा नहीं देता।

स्मार्ट कॉन्ट्रैक्ट वही करता है जिसकी उसका कोड अनुमति देता है। यदि लॉजिक में bug, असुरक्षित प्रशासनिक फ़ंक्शन या त्रुटिपूर्ण धारणा हो, तो ब्लॉकचेन उसे अपने आप ठीक नहीं करता।

मुख्य निष्कर्ष

स्मार्ट कॉन्ट्रैक्ट ब्लॉकचेन पते पर संग्रहीत कोड और डेटा है।

नेटवर्क पहले से निर्धारित नियमों के अनुसार अपने फ़ंक्शन निष्पादित करता है।

पुष्टि की गई कार्रवाई को बाद में सामान्य रूप से संपादित नहीं किया जा सकता।

कुछ कॉन्ट्रैक्ट समायोज्य पैरामीटर या अपग्रेड की जा सकने वाली लॉजिक के साथ डिज़ाइन किए जाते हैं।

उपयोगकर्ताओं को केवल कॉन्ट्रैक्ट पता ही नहीं, उसकी भूमिकाएँ, अनुमतियाँ और अपग्रेड तंत्र भी जाँचना चाहिए।

स्मार्ट कॉन्ट्रैक्ट समझने का सरल तरीका

स्वचालित storage locker की कल्पना करें।

उसका नियम कहता है: “प्राप्तकर्ता निर्धारित तिथि के बाद ही locker खोल सकता है।”
प्रेषक एसेट जमा करता है।
प्राप्तकर्ता इसे समय से पहले खोलने की कोशिश करता है और मशीन मना कर देती है।
तिथि आने के बाद, अन्य सभी शर्तें पूरी होने पर वही अनुरोध सफल होता है।

अंतर यह है कि स्मार्ट कॉन्ट्रैक्ट का निष्पादन किसी एक कंपनी के सर्वर द्वारा नहीं होता। ब्लॉकचेन नेटवर्क निर्देश को प्रोसेस करता है, साझा परिणाम पर पहुँचता है और उसे दर्ज करता है।

इसका अर्थ यह नहीं कि कॉन्ट्रैक्ट अपने-आप जानता है कि पैकेज पहुँचा या नहीं, मौसम कैसा है या विनिमय दर क्या होनी चाहिए। ब्लॉकचेन उसके पास उपलब्ध डेटा के साथ विश्वसनीय रूप से काम करता है। बाहरी दुनिया की जानकारी के लिए अतिरिक्त स्रोत चाहिए, जिन्हें अक्सर oracles कहा जाता है। तब परिणाम उन स्रोतों पर भी निर्भर करता है।

कोड, स्थिति और ट्रांज़ैक्शन

स्मार्ट कॉन्ट्रैक्ट के तीन उपयोगी आयाम हैं:

Code: its available functions and checks.
State: its current data, such as balances, statuses, and configuration values.
Transaction history: the sequence of operations that changed that state.

सार्वजनिक डेटा पढ़ने से आमतौर पर स्थिति नहीं बदलती। ऐसी कार्रवाई जो कुछ बदलती है—जैसे टोकन ट्रांसफ़र करना या भागीदारी दर्ज करना—के लिए ट्रांज़ैक्शन आवश्यक है। उपयोगकर्ता उस पर हस्ताक्षर करता है, नेटवर्क उसे प्रोसेस करता है और सामान्यतः शुल्क लिया जाता है।

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

“पूर्वप्रभावी रूप से नहीं बदला जा सकता” का वास्तविक अर्थ

मान लें कि कोई कॉन्ट्रैक्ट पते A से पते B को 100 टोकन के ट्रांसफ़र को दर्ज करता है। पुष्टि के बाद कोई प्रशासक उस ब्लॉक को खोलकर 100 को 10 से इस तरह नहीं बदल सकता मानो मूल कार्रवाई हुई ही न हो। वह पहले से पुष्टि किए गए ट्रांज़ैक्शन में प्राप्तकर्ता को चुपचाप बदल भी नहीं सकता।

If the code includes a refund, reversal, or compensation function, using it creates a new transaction. The blockchain will show the original action and the later response.

इसीलिए on-chain इतिहास स्वतंत्र सत्यापन में सहायक हो सकता है: अलग-अलग पर्यवेक्षक नेटवर्क को क्वेरी कर घटनाओं का वही क्रम देख सकते हैं।

यह कहना फिर भी गलत है कि ब्लॉकचेन “किसी भी परिस्थिति में कभी नहीं बदल सकता।” नेटवर्क के अपने finality models होते हैं और वे protocol विफलता या हमलों के जोखिम में रहते हैं। व्यावहारिक बात सीमित है: सामान्य संचालन में उपयोगकर्ता या ऐप प्रशासक पुष्टि किए गए ब्लॉकचेन रिकॉर्ड को निजी database की row की तरह संपादित नहीं कर सकता।

क्या इसका अर्थ है कि कॉन्ट्रैक्ट कभी बदल नहीं सकता?

हमेशा नहीं। यहीं “अपरिवर्तनीय कॉन्ट्रैक्ट” वाक्यांश को अक्सर गलत समझा जाता है।

1. अपग्रेड न किया जा सकने वाला कॉन्ट्रैक्ट

डिप्लॉय किया गया कोड अपनी मूल लॉजिक के अनुसार चलता रहता है। डेवलपर नए पते पर नया कॉन्ट्रैक्ट डिप्लॉय कर सकते हैं, लेकिन पुराना पता और उसका इतिहास बने रहते हैं। उपयोगकर्ताओं को जानबूझकर नए संस्करण पर जाना होता है।

2. समायोज्य पैरामीटर वाला कॉन्ट्रैक्ट

कोड में ऐसे प्रशासकीय फ़ंक्शन हो सकते हैं जो सीमा बदलें, कार्रवाई रोकें, allowlist प्रबंधित करें या शुल्क प्राप्तकर्ता अपडेट करें। इन फ़ंक्शन के लिए फिर भी नए ट्रांज़ैक्शन आवश्यक होते हैं और वे केवल कोड में मौजूद शक्तियों का उपयोग कर सकते हैं।

यह अतीत को दोबारा नहीं लिखता, लेकिन भविष्य की कार्रवाइयों के नियम बदल सकता है।

3. अपग्रेड की जा सकने वाली आर्किटेक्चर

एक सामान्य डिज़ाइन प्रॉक्सी कॉन्ट्रैक्ट का उपयोग करता है। प्रॉक्सी पता वही रहता है, जबकि कॉल अलग implementation contract को भेजे जाते हैं। यदि governance उस implementation को बदल सकता है, तो प्रॉक्सी पते का भविष्य का व्यवहार बदल सकता है।

इसका अर्थ है कि “पता नहीं बदला” का मतलब हमेशा “लॉजिक कभी नहीं बदली” नहीं होता। सावधानीपूर्वक समीक्षा में पूछा जाता है:

क्या पता proxy है?
इम्प्लीमेंटेशन को कौन अपग्रेड कर सकता है?
एक हस्ताक्षर पर्याप्त है या कई आवश्यक हैं?
क्या समय विलंब है?
क्या कार्रवाइयाँ रोकी जा सकती हैं?
प्रशासक कौन-से पैरामीटर बदल सकते हैं?

उदाहरण: सीमा बदलना

1,000 इकाइयों की दैनिक सीमा वाले कॉन्ट्रैक्ट की कल्पना करें।

सोमवार को कोई उपयोगकर्ता 800 इकाइयों की कार्रवाई पूरी करता है।
मंगलवार को कोई अधिकृत पता एक नए ट्रांज़ैक्शन के माध्यम से सीमा को 500 में बदलता है।
सोमवार की कार्रवाई न तो गायब होती है और न किसी दूसरे रिकॉर्ड में बदलती है।
यदि कॉन्ट्रैक्ट का लॉजिक ऐसा निर्धारित करता है, तो मंगलवार से वह 500-इकाई सीमा लागू करता है।

ब्लॉक एक्सप्लोरर दोनों ट्रांज़ैक्शन दिखा सकता है। उनके परिणाम समझने के लिए फिर भी यह जानना आवश्यक है कि कौन-से फ़ंक्शन कॉल किए गए और उनके पास कौन-से अधिकार हैं।

ब्लॉकचेन क्या साबित करता है—और क्या नहीं

सार्वजनिक ब्लॉकचेन निम्न को सत्यापित करने में मदद कर सकता है:

भाग लेने वाले पते;
ट्रांज़ैक्शन का समय और Status;
ट्रांसफ़र किए गए एसेट और राशियाँ;
डेटा सही decode होने पर call किया गया फ़ंक्शन;
इवेंट और कार्रवाइयों का क्रम;
सोर्स कोड, जब उसे डिप्लॉय किए गए bytecode से सत्यापित किया गया हो।

Deployment on a blockchain does not by itself guarantee:

बग या कमज़ोरियों का अभाव;
ईमानदार डेवलपर;
आर्थिक स्थिरता;
सटीक बाहरी डेटा;
प्रशासकीय शक्तियों का अभाव;
कानूनी सुरक्षा;
गलत ट्रांसफ़र के बाद रिकवरी।

पारदर्शिता का अर्थ है कि साक्ष्य का निरीक्षण किया जा सकता है। इसका अर्थ यह नहीं कि दिखाई देने वाली हर चीज़ सुरक्षित है।

interaction से पहले की व्यावहारिक जाँच सूची

Verify the address. Obtain it from an official project source and compare it carefully.
Verify the network. The same address format may exist across several EVM networks.
Check source verification. Published source code makes analysis easier, but it is not a security audit.
Look for proxies and upgrades. Identify the implementation and the upgrade authority.
Review administrator powers. Look for owner, admin, pause, upgrade, fee, and access-control functions.
Review token approvals. Before approving, confirm the token, spender, and allowance.
Start small. For a first interaction, consider a small test amount while accounting for fees.

उपयोगकर्ता का हस्ताक्षर क्यों महत्वपूर्ण है

स्मार्ट कॉन्ट्रैक्ट को अपने आप पूरे वॉलेट की पहुँच नहीं मिलती। उसे विशिष्ट call मिलता है और वह केवल दिए गए permissions का उपयोग कर सकता है।

लेकिन हस्ताक्षर साधारण ट्रांसफ़र से अधिक की अनुमति दे सकता है। यह token खर्च को approve कर सकता है, unlimited allowance दे सकता है, परिसंपत्तियों का विनिमय कर सकता है, NFT ट्रांसफ़र कर सकता है या calls की जटिल श्रृंखला शुरू कर सकता है।

यदि वॉलेट अनुरोध स्पष्ट न समझा सके, तो उपयोगकर्ता “blind signing” जोखिम में है। केवल परिचित chat से लिंक आने या वेबसाइट आधिकारिक जैसी दिखने के कारण ट्रांज़ैक्शन स्वीकृत न करें।

निष्कर्ष

स्मार्ट कॉन्ट्रैक्ट न तो वादा है और न निष्पक्षता की जादुई गारंटी। यह ऐसा प्रोग्राम है जो कोड किए गए नियम लागू करता है और सत्यापन योग्य इतिहास छोड़ता है।

A confirmed operation cannot be quietly edited after the fact. However, future parameters or logic may be changeable if the architecture was designed that way. The most useful question is therefore not only “Is there a smart contract?” but also: “What does its code allow, and who can influence how it works in the future?”

मुख्य निष्कर्ष