आधुनिक Solidity (या Huff यदि आप वास्तव में इसे hard mode में करना चाहते हैं) का उपयोग करके शुरुआत (scratch) से Uniswap v2 को फिर से बनाना बहुत शिक्षाप्रद है। ऐसा करने के लिए यहां कुछ संकेत और सुझाव दिए गए हैं।

• Solidity के अपडेटेड वर्ज़न का उपयोग करें। ध्यान रखें कि इससे सिंटैक्टिक (syntactic) बदलाव आएंगे।
• fixed point numbers को custom data types से बदलें।
• gas बचाने के लिए ERC20 के लिए Solady ERC20 का उपयोग करें।
• Uniswap V2 के वर्तमान reentrancy protection का उपयोग न करें, यह अब gas efficient नहीं है, OpenZeppelin या किसी अन्य विकल्प का उपयोग करें।
• price oracle में unchecked जोड़ने में सावधानी बरतें, इसके overflow होने की उम्मीद होती है।
• Solidity 0.8.0 या उसके बाद के वर्ज़न के साथ safeMath का उपयोग न करें।
• यदि आप router को अलग से इम्प्लीमेंट (implement) नहीं कर रहे हैं, तो slippage के लिए safety checks को कॉन्ट्रैक्ट में ही बनाना होगा। EOAs ट्रांज़ैक्शन के हिस्से के रूप में टोकन नहीं भेज सकते हैं।
• reentrancy lock को सही जगह पर लगाना सुनिश्चित करें। क्या Uniswap V2 read-only reentrancy के अधीन है? क्यों या क्यों नहीं?
• Solidity अपडेट्स के कारण factory contract को assembly के बिना सरल किया जा सकता है।
• fee-on-transfer टोकन या re-basing टोकन से सावधान रहें।
• square root फंक्शन को Solady लाइब्रेरी के साथ अधिक कुशलता से किया जा सकता है, लेकिन सुनिश्चित करें कि आप सही दिशा में rounding कर रहे हैं।
• Uniswap magic numbers के साथ fee को हार्डकोड (hardcode) करता है, यह कोड लिखने का एक आदर्श तरीका नहीं है।
• पेशेवर Solidity स्टाइल गाइड का पालन करना न भूलें (जिसका Uniswap V2 पालन नहीं करता है)।
• जिस तरह से factory pairs को ट्रैक करती है वह gas efficient नहीं है, इसे सुधारने का प्रयास करें।
• ओरिजिनल इम्प्लीमेंटेशन में कुछ storage variables को immutable बनाया जा सकता है (जब Uniswap V2 लॉन्च किया गया था तब immutable variables उपलब्ध नहीं थे)।
• Custom errors से require स्टेटमेंट्स की तुलना में डिप्लॉयमेंट कॉस्ट सस्ती होगी (आमतौर पर)।
• initial supply को बर्न (burn) करते समय, सुनिश्चित करें कि totalSupply शून्य न हो जाए। अन्यथा, first deposit attack के खिलाफ बचाव काम नहीं करेगा। burn के कुछ इम्प्लीमेंटेशन funds को लॉक करने (जैसा कि Uniswap का उद्देश्य है) के बजाय total supply को कम कर देते हैं।
• shares की गणना करते समय reserves को सही क्रम में burn, mint, और update करने में सावधानी बरतें।
• Uniswap V2 का _safeTransfer memory expansion attack के अधीन है (इसकी संभावना बहुत कम है, लेकिन फिर भी इससे बचाव किया जाना चाहिए)। चूंकि केवल एक bool पढ़ा जाएगा, इसलिए केवल एक word को returndatacopy करना सबसे अच्छा है। अन्य contracts से पूरा return data पढ़ने की आदत डालने से बचने का प्रयास करें।
• एक अच्छा invariant test यह है कि यदि burn को कॉल नहीं किया जाता है तो liquidity कभी कम नहीं होनी चाहिए।
• balance variables या pool balance का उपयोग oracle के रूप में न करें, क्योंकि ये flash loan attacks के प्रति संवेदनशील (vulnerable) होते हैं।
• ट्रेड्स (trades) करते समय या shares को मिंट (minting) या बर्न (burning) करते समय हमेशा pool के पक्ष में round करना याद रखें।
• unit tests लिखना न भूलें।
• प्रदर्शन (performance) को बेहतर बनाने के बारे में प्रेरणा के लिए Solidity gas optimization पर हमारी पुस्तक पढ़ें (अपने Uniswap clone का दूसरा या तीसरा ड्राफ्ट पूरा करने और टेस्ट लिखने के बाद)। यदि आप इसे hard mode में करना चाहते हैं, तो readability में महत्वपूर्ण समझौता किए बिना assembly का उपयोग करके gas में सुधार करने के कई अवसर हैं।
• Damn Vulnerable Defi Puppet V2 को आज़माएं। इस स्तर पर इसे हल करना आपके लिए आसान होना चाहिए।

RareSkills के साथ और जानें

यह सामग्री हमारे एडवांस्ड Solidity Bootcamp का हिस्सा है। अधिक जानने के लिए कृपया प्रोग्राम देखें।

मूल रूप से 1 नवंबर, 2023 को प्रकाशित