Solana में fallback या receive functions नहीं होते हैं
एक Solana transaction को उन accounts को पहले से निर्दिष्ट करना चाहिए जिन्हें वह transaction के हिस्से के रूप में modify या read करेगा। यदि कोई “fallback” function किसी अनिर्दिष्ट (indeterminant) account को एक्सेस करता है, तो पूरा transaction विफल हो जाएगा। यह यूजर पर यह अनुमान लगाने का भार डालेगा कि fallback function किन accounts को एक्सेस करेगा। परिणामस्वरूप इस प्रकार के functions को अनुमति न देना बहुत सरल है।
Solana में “view” या “pure” function की कोई धारणा नहीं है
Solidity में एक “view” function यह गारंटी देता है कि state दो तंत्रों (mechanisms) का उपयोग करके नहीं बदलेगा:
- view function में सभी external calls staticcalls होते हैं (वे calls जो state में बदलाव होने पर revert हो जाते हैं)
- यदि compiler state-changing opcodes का पता लगाता है, तो यह एक error फेंकता है
एक pure function इसे और भी आगे ले जाता है जहाँ compiler यह जाँचता है कि क्या ऐसे opcodes मौजूद हैं जो state को देखते (view करते) हैं।
ये function प्रतिबंध मुख्य रूप से compiler स्तर पर होते हैं, और Anchor इनमें से किसी भी compiler जाँच को लागू नहीं करता है। Anchor, Solana programs बनाने के लिए एकमात्र framework नहीं है। Seahorse एक और framework है। शायद कोई अन्य framework function annotations के साथ आएगा जो स्पष्ट रूप से बताएगा कि functions क्या कर सकते हैं और क्या नहीं, लेकिन अभी के लिए हम निम्नलिखित गारंटी पर भरोसा कर सकते हैं: यदि कोई account, Context struct परिभाषा में शामिल नहीं है, तो वह function उस account को एक्सेस नहीं करेगा।
इसका मतलब यह नहीं है कि account को बिल्कुल भी एक्सेस नहीं किया जा सकता है। उदाहरण के लिए, हम किसी account को पढ़ने और उस डेटा को किसी तरह संबंधित function को भेजने (forward करने) के लिए एक अलग program बना सकते हैं।
अंत में, Solana virtual machine या runtime में staticcall जैसी कोई चीज़ नहीं है।
वैसे भी Solana में View functions आवश्यक नहीं हैं
चूंकि एक Solana program उसे पास किए गए किसी भी account को पढ़ सकता है, इसलिए यह किसी अन्य program के स्वामित्व वाले account को पढ़ सकता है।
Account के मालिक वाले program को किसी अन्य program को उस account को देखने की अनुमति देने के लिए view function लागू करने की आवश्यकता नहीं होती है। web3 js client — या कोई अन्य program — सीधे Solana account data को देख सकता है।
इसका एक बहुत ही महत्वपूर्ण निहितार्थ (implication) है:
Solana में read only reentrancy से सीधे बचाव करने के लिए reentrancy locks का उपयोग करना संभव नहीं है। Readers को यह जानने के लिए कि डेटा विश्वसनीय है या नहीं, program को एक flag एक्सपोज़ (expose) करना चाहिए।
Read only reentrancy तब होती है जब कोई victim contract किसी ऐसे view function को एक्सेस करता है जो हेरफेर किया हुआ (manipulated) डेटा दिखा रहा हो। Solidity में view function में एक nonReentrant modifier जोड़कर इससे बचाव किया जा सकता है। हालाँकि, Solana में किसी अन्य program को किसी account का डेटा देखने से रोकने का कोई तरीका नहीं है।
हालाँकि, Solana programs अभी भी उन flags को लागू कर सकते हैं जिनका उपयोग reentrancy guards करते हैं। किसी अन्य program के account का उपभोग (consume) करने वाले programs यह देखने के लिए उन flags की जाँच कर सकते हैं कि क्या account वर्तमान में reentrant state में हो सकता है और उस पर भरोसा नहीं किया जाना चाहिए।
Rust में कोई custom modifiers नहीं हैं
onlyOwner या nonReentrant जैसे Custom modifiers एक Solidity निर्माण (construct) हैं, और Rust में उपलब्ध सुविधा नहीं हैं।
Rust या Anchor में Custom units उपलब्ध नहीं हैं
चूंकि Solidity, Ethereum के साथ गहराई से जुड़ा हुआ है, इसलिए इसमें Ethereum को मापने के लिए ethers या wei जैसे सुविधाजनक कीवर्ड हैं। आश्चर्य की बात नहीं है कि LAMPORTS_PER_SOL Rust में परिभाषित नहीं है, लेकिन कुछ आश्चर्यजनक रूप से, यह Anchor Rust Framework में भी परिभाषित नहीं है। हालाँकि यह Solana web3 js library में उपलब्ध है।
इसी तरह, Solidity में 84,600 सेकंड के सुविधाजनक उपनाम (alias) के रूप में days है, लेकिन Rust/Anchor में ऐसा कोई समकक्ष (equivalent) मौजूद नहीं है।
Solana में “payable” functions जैसी कोई चीज़ नहीं है। Programs यूजर से SOL ट्रांसफर करते हैं, यूजर program में SOL ट्रांसफर नहीं करते हैं
यह अगले ट्यूटोरियल का विषय है।
RareSkills के साथ और जानें
अगले अध्याय के लिए हमारा Solana development course देखें।
मूल रूप से 1 मार्च, 2024 को प्रकाशित