Solana में नए आने वाले लोग अक्सर “owner” और “authority” के बीच के अंतर को लेकर भ्रमित रहते हैं। यह लेख इस भ्रम को यथासंभव संक्षेप में दूर करने का प्रयास करता है।
Owner बनाम Authority
केवल प्रोग्राम ही अकाउंट्स में डेटा लिख (write) सकते हैं — विशेष रूप से, केवल उन अकाउंट्स में जिनके वे owner हैं। कोई प्रोग्राम किसी भी मनमाने अकाउंट में डेटा नहीं लिख सकता।
बेशक, प्रोग्राम अपने आप अकाउंट्स में डेटा नहीं लिख सकते। ऐसा करने के लिए उन्हें किसी वॉलेट से निर्देश (instruction) प्राप्त करने की आवश्यकता होती है। हालाँकि, प्रोग्राम आम तौर पर किसी विशेष अकाउंट के लिए लिखने के निर्देश केवल एक विशेषाधिकार प्राप्त (privileged) वॉलेट से ही स्वीकार करेंगे: जो कि authority है।
किसी अकाउंट का owner एक प्रोग्राम होता है। एक authority एक वॉलेट होता है। एक authority किसी प्रोग्राम को ट्रांजैक्शन भेजता है और वह प्रोग्राम उस अकाउंट में लिख सकता है।
Solana में सभी अकाउंट्स में निम्नलिखित फ़ील्ड्स होते हैं, जो स्पष्ट रूप से समझे जा सकते हैं:
- Public Key
- lamport balance
- owner
- executable (a boolean flag)
- rent_epoch (can be ignored for rent-exempt accounts)
- data
हम टर्मिनल में solana account <our wallet address> चलाकर (बैकग्राउंड में Solana validator चलाते हुए) इन्हें देख सकते हैं:
एक दिलचस्प बात पर ध्यान दें: हम अपने वॉलेट के owner नहीं हैं! एड्रेस 111...111 system program है।
वॉलेट के खुद के owner होने के बजाय, system program वॉलेट्स का owner क्यों होता है?
केवल अकाउंट का owner ही उसके डेटा को संशोधित (modify) कर सकता है।
इसका अर्थ यह है कि हम सीधे अपने बैलेंस को संशोधित करने में सक्षम नहीं हैं। केवल system program ही ऐसा कर सकता है। अपने अकाउंट से SOL ट्रांसफर करने के लिए, हम system program को एक हस्ताक्षरित (signed) ट्रांजैक्शन भेजते हैं। system program यह वेरिफाई करता है कि अकाउंट की प्राइवेट की (private key) हमारे पास है, और फिर वह हमारी ओर से बैलेंस को संशोधित कर देता है।
यह एक ऐसा पैटर्न है जिसे आप Solana में अक्सर देखेंगे: केवल अकाउंट का owner ही अकाउंट के डेटा को संशोधित कर सकता है। प्रोग्राम अकाउंट के डेटा को तभी संशोधित करेगा जब उसे किसी पूर्व-निर्धारित एड्रेस: एक authority से वैध सिग्नेचर (valid signature) दिखाई देगा।
एक authority वह एड्रेस है जिससे एक प्रोग्राम वैध सिग्नेचर देखने पर निर्देश स्वीकार करेगा। एक authority सीधे किसी अकाउंट को संशोधित नहीं कर सकती। इसे उस प्रोग्राम के माध्यम से काम करने की आवश्यकता होती है जो उस अकाउंट का owner है जिसे वह संशोधित करने का प्रयास कर रहा है।
हालाँकि owner हमेशा एक प्रोग्राम होता है, और वह प्रोग्राम किसी और की ओर से अकाउंट को संशोधित करेगा यदि ट्रांजैक्शन के लिए सिग्नेचर वैध है।
हमने इसे उदाहरण के लिए, modifying accounts with different signers पर हमारे ट्यूटोरियल में देखा था।
अभ्यास (Exercise): एक ऐसा प्रोग्राम बनाएं जो एक स्टोरेज अकाउंट को इनिशियलाइज़ (initialize) करे। आप प्रोग्राम और स्टोरेज अकाउंट्स का एड्रेस अपने पास तैयार रखना चाहेंगे। टेस्ट्स में निम्नलिखित कोड जोड़ने पर विचार करें:
console.log(`program: ${program.programId.toBase58()}`);
console.log(`storage account: ${myStorage.toBase58()}`);
फिर इनिशियलाइज़ किए गए अकाउंट पर solana account <storage account> चलाएं। आपको owner के रूप में प्रोग्राम दिखाई देना चाहिए।
यहाँ अभ्यास चलाए जाने का स्क्रीनशॉट दिया गया है:
जब हम स्टोरेज अकाउंट के मेटाडेटा को देखते हैं, तो हम पाते हैं कि प्रोग्राम ही इसका owner है।
चूँकि प्रोग्राम स्टोरेज अकाउंट का owner है, इसलिए वह इसमें लिखने में सक्षम है। यूज़र्स सीधे स्टोरेज अकाउंट में नहीं लिख सकते, वे एक ट्रांजैक्शन साइन करते हैं और प्रोग्राम को डेटा लिखने के लिए कहते हैं।
Solana में owner, Solidity में owner से बहुत अलग है
Solidity में, हम आमतौर पर owner को स्मार्ट कॉन्ट्रैक्ट पर एडमिन विशेषाधिकारों (admin privileges) वाले एक विशेष एड्रेस के रूप में संदर्भित करते हैं। “owner” कोई ऐसा कॉन्सेप्ट नहीं है जो Ethereum रनटाइम स्तर पर मौजूद हो, यह Solidity कॉन्ट्रैक्ट्स पर लागू किया गया एक डिज़ाइन पैटर्न है। Solana में एक owner बहुत अधिक बुनियादी (fundamental) है। Ethereum में, एक स्मार्ट कॉन्ट्रैक्ट केवल अपने स्वयं के स्टोरेज स्लॉट्स में लिख सकता है। कल्पना करें कि हमारे पास एक ऐसा मैकेनिज्म होता जो एक Ethereum स्मार्ट कॉन्ट्रैक्ट को किसी अन्य स्टोरेज स्लॉट में लिखने की अनुमति देता। Solana के संदर्भ में, यह उन स्टोरेज स्लॉट्स का owner बन जाएगा।
Authority का अर्थ यह हो सकता है कि किसने कॉन्ट्रैक्ट डिप्लॉय किया और कौन किसी विशेष अकाउंट के लिए राइट ट्रांजैक्शन (write transactions) भेज सकता है
एक authority प्रोग्राम स्तर पर एक संरचना (construct) हो सकती है। Anchor signers पर हमारे ट्यूटोरियल में, हमने एक ऐसा प्रोग्राम बनाया जहाँ Alice किसी और को ट्रांसफर करने के लिए अपने अकाउंट से पॉइंट काट सकती थी। यह जानने के लिए कि केवल Alice ही उस अकाउंट के लिए कटौती का ट्रांजैक्शन भेज सकती है, हमने उसका एड्रेस अकाउंट में स्टोर कर लिया:
#[account]
pub struct Player {
points: u32,
authority: Pubkey
}
यह याद रखने के लिए कि किसने कोई प्रोग्राम डिप्लॉय (deploy) किया है, Solana इसी तरह के मैकेनिज्म का उपयोग करता है। Anchor deploy पर हमारे ट्यूटोरियल में, हमने ध्यान दिया था कि जिस वॉलेट ने प्रोग्राम को डिप्लॉय किया है, वही उसे अपग्रेड करने में भी सक्षम होता है।
किसी प्रोग्राम को “अपग्रेड” करना उसमें नया डेटा लिखने के समान है — यानी नया बायटकोड (bytecode)। केवल प्रोग्राम का owner ही उसमें लिख सकता है (यह प्रोग्राम BPFLoaderUpgradeable है जैसा कि हम जल्द ही देखेंगे)।
इसलिए, Solana को कैसे पता चलता है कि किसी विशेष प्रोग्राम को डिप्लॉय करने वाले वॉलेट को अपग्रेड विशेषाधिकार कैसे दिए जाएं?
कमांड लाइन से किसी प्रोग्राम की authority देखना
प्रोग्राम को डिप्लॉय करने से पहले, आइए टर्मिनल में solana address चलाकर देखें कि anchor किस वॉलेट का उपयोग कर रहा है:
ध्यान दें कि हमारा एड्रेस 5jmi...rrTj है। अब चलिए एक प्रोग्राम बनाते हैं।
सुनिश्चित करें कि बैकग्राउंड में solana-test-validator और solana logs चल रहे हैं, फिर Solana प्रोग्राम को डिप्लॉय करें:
anchor init owner_authority
cd owner_authority
anchor build
anchor test --skip-local-validator
जब हम लॉग्स को देखते हैं, तो हमें उस प्रोग्राम का एड्रेस दिखाई देता है जिसे हमने अभी डिप्लॉय किया है:
याद रखें, Solana पर सब कुछ एक अकाउंट है, जिसमें प्रोग्राम भी शामिल हैं। अब आइए solana account 6Ye7CgrwJxH3b4EeWKh54NM8e6ZekPcqREgkrn7Yy3Tg का उपयोग करके इस अकाउंट का निरीक्षण करें। हमें निम्नलिखित परिणाम मिलता है:
ध्यान दें कि authority फ़ील्ड अनुपस्थित है, क्योंकि “authority” कोई ऐसा फ़ील्ड नहीं है जो Solana अकाउंट्स में होता है। यदि आप इस लेख में ऊपर स्क्रॉल करते हैं, तो आप देखेंगे कि कंसोल में दी गई कुंजियाँ (keys) उन फ़ील्ड्स से मेल खाती हैं जिन्हें हमने लेख की शुरुआत में सूचीबद्ध किया था।
यहाँ, “owner” BPFLoaderUpgradeable111...111 है, जो सभी Solana प्रोग्राम्स का owner है।
अब आइए solana program show 6Ye7CgrwJxH3b4EeWKh54NM8e6ZekPcqREgkrn7Yy3Tg चलाते हैं, जहाँ 6Ye7...y3TG हमारे प्रोग्राम का एड्रेस है:
ऊपर दिए गए हरे बॉक्स (green box) में, हम अपना वॉलेट एड्रेस देखते हैं — जिसका उपयोग प्रोग्राम को डिप्लॉय करने के लिए किया गया था और जिसे हमने पहले solana address के साथ प्रिंट किया था:
लेकिन यह हमें एक महत्वपूर्ण प्रश्न की ओर ले जाता है…
Solana प्रोग्राम के लिए “authority” को कहाँ स्टोर करता है, जो कि वर्तमान में हमारा वॉलेट है?
यह किसी अकाउंट में कोई फ़ील्ड नहीं है, इसलिए इसे किसी Solana अकाउंट के data फ़ील्ड में होना चाहिए। “authority” को उस ProgramData Address में स्टोर किया जाता है जहाँ प्रोग्राम का बायटकोड स्टोर होता है:
हमारे वॉलेट (authority) की Hex एन्कोडिंग
आगे बढ़ने से पहले, ProgramData Address की base58 एन्कोडिंग को hex रिप्रजेंटेशन में बदलना मददगार होगा। इसे पूरा करने के लिए कोड लेख के अंत में दिया गया है, लेकिन अभी के लिए हम पाठक से यह स्वीकार करने के लिए कहते हैं कि हमारे Solana वॉलेट एड्रेस 5jmigjgt77kAfKsHri3MHpMMFPo6UuiAMF19VdDfrrTj का hex रिप्रजेंटेशन यह है:
4663b48dfe92ac464658e512f74a8ee0ffa99fffe89fb90e8d0101a0c3c7767a
ProgramData Address अकाउंट में डेटा देखना जहाँ executable स्टोर किया गया है
हम ProgramData Address अकाउंट को solana account के साथ देख सकते हैं, लेकिन टर्मिनल पर बहुत अधिक डेटा डंप होने से बचने के लिए हम इसे एक अस्थायी (temporary) फ़ाइल में भी भेजेंगे।
solana account FkYygT7X7qjifdxfBVWXTHpj87THJGmtmKUyU4SamfQm > tempfile
head -n 10 tempfile
उपरोक्त कमांड का आउटपुट हमारे वॉलेट को (hex में) data के अंदर एम्बेडेड (embedded) दिखाता है। गौर करें कि पीले रंग से रेखांकित (yellow underlined) hex कोड हमारे वॉलेट (authority) की hex एन्कोडिंग से मेल खाता है:
किसी प्रोग्राम का बायटकोड प्रोग्राम के एड्रेस पर नहीं, बल्कि एक अलग अकाउंट में स्टोर होता है
कमांड्स के उपरोक्त क्रम से यह निहित होना चाहिए, लेकिन इसे स्पष्ट रूप से बताना उचित है। भले ही कोई प्रोग्राम एक ऐसा अकाउंट हो जिसे executable के रूप में मार्क किया गया हो, बायटकोड इसके अपने डेटा फ़ील्ड में स्टोर नहीं होता है, बल्कि किसी अन्य अकाउंट में स्टोर होता है (जो थोड़ा भ्रमित करने वाला है क्योंकि यह executable नहीं है, यह केवल बायटकोड स्टोर करता है)।
अभ्यास (Exercise): क्या आप पता लगा सकते हैं कि प्रोग्राम उस अकाउंट का एड्रेस कहाँ स्टोर करता है जो बायटकोड रखता है? इस लेख के परिशिष्ट (addendum) में कुछ कोड है जो उपयोगी हो सकता है।
सारांश (Summary)
केवल किसी प्रोग्राम का owner ही उसके डेटा को बदल सकता है। Solana प्रोग्राम्स का owner BPFLoaderUpgradeable system program है, इसलिए डिफ़ॉल्ट रूप से, जिस वॉलेट ने प्रोग्राम को डिप्लॉय किया है, वह किसी अकाउंट में स्टोर डेटा (बायटकोड) को बदल नहीं सकता है।
प्रोग्राम्स को अपग्रेड करने में सक्षम बनाने के लिए, Solana रनटाइम डिप्लॉयर के वॉलेट को प्रोग्राम के बायटकोड में एम्बेड कर देता है। यह इस फ़ील्ड को “authority” के रूप में संदर्भित करता है।
जब डिप्लॉय करने वाला वॉलेट बायटकोड को अपग्रेड करने का प्रयास करता है, तो Solana रनटाइम यह जाँचेगा कि क्या ट्रांजैक्शन साइनर ही authority है। यदि ट्रांजैक्शन साइनर authority से मेल खाता है, तो BPFLoaderUpgradeable authority की ओर से प्रोग्राम के बायटकोड को अपडेट कर देगा।
परिशिष्ट (Addendum): base 58 को hex में बदलना
निम्नलिखित Python कोड इस रूपांतरण को पूरा करेगा। यह एक चैटबॉट द्वारा उत्पन्न किया गया था, और इसलिए इसका उपयोग केवल उदाहरण के उद्देश्यों के लिए किया जाना चाहिए:
def decode_base58(bc, length):
base58_digits = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
n = 0
for char in bc:
n = n * 58 + base58_digits.index(char)
return n.to_bytes(length, 'big')
def find_correct_length_for_decoding(base58_string):
for length in range(25, 50): # Trying lengths from 25 to 50
try:
decoded_bytes = decode_base58(base58_string, length)
return decoded_bytes.hex()
except OverflowError:
continue
return None
# Base58 string to convert
base58_string = "5jmigjgt77kAfKsHri3MHpMMFPo6UuiAMF19VdDfrrTj"
# Convert and get the hexadecimal string
hex_string = find_correct_length_for_decoding(base58_string)
print(hex_string)
RareSkills के साथ और जानें
Solana के और अधिक विषयों को जानने के लिए हमारा Solana development course देखें! अन्य ब्लॉकचेन विषयों के लिए, कृपया हमारा blockchain bootcamp देखें।
मूल रूप से 11 मार्च, 2024 को प्रकाशित