AdToken लॉन्च कॉन्ट्रैक्ट्स

हाय। मैं माइक गोल्डिन हूं। मैं ConsenSys में एक सॉफ़्टवेयर डेवलपर हूं और मैंने AdToken लॉन्च कॉन्ट्रैक्ट लिखे हैं।

टोकन लॉन्च करना बहुत तनावपूर्ण है! बहुत ही कम समय में आपके आवेदन पर लाखों डॉलर जमा हो जाते हैं, और हर वी को सही तरीके से संभालने या अस्वीकार करने की आवश्यकता होती है। ब्लॉकचेन पर कुछ गलत होने पर आप बस “सर्वर को रिबूट” नहीं कर सकते हैं; यदि आप किसी का पैसा खो देते हैं तो वह हमेशा के लिए चला जाता है और वे आपसे खुश नहीं होंगे।

AdToken लॉन्च बेहद सरल है। हम निश्चित मूल्य पर सीमित संख्या में टोकन बेच रहे हैं। MeTax का लक्ष्य बिक्री से $10 मिलियन का राजस्व प्राप्त करना है, और $10 मिलियन का आंकड़ा एक हार्ड कैप है। हम उस समय की विनिमय दर के सापेक्ष लॉन्च से एक दिन पहले टोकन की कीमत इस तरह तय करेंगे कि यदि सभी 500 मिलियन टोकन बेचे जाते हैं तो MeTax को उस विनिमय दर पर $10 मिलियन का राजस्व मिलेगा।

कोई गतिशील मूल्य निर्धारण या विदेशी नीलामी तंत्र नहीं है। AdToken लॉन्च एक निश्चित मूल्य, सीमित आपूर्ति वाली बिक्री है। यहां कुछ भी फैंसी नहीं होता है। हमारे द्वारा बिक्री मूल्य निर्धारित करने और बिक्री के स्टार्ट ब्लॉक के बीच के दिन में ईथर की कीमत में उतार-चढ़ाव के आधार पर MeTax को $10 मिलियन के करीब राजस्व प्राप्त होगा।

आइए अनुबंधों को देखें!

मुझ पर भरोसा मत करो, मशीन पर भरोसा करो!

मेननेट पर बिक्री अनुबंध यहां तैनात किया गया है, और स्रोत कोड यहां दिया गया है। सबसे पहले startBlock और freezeBlock नामक स्टोरेज वेरिएबल पर एक नज़र डालें। बिक्री शुरू होने से पहले की गई खरीदारी को अस्वीकार करने के लिए स्टार्टब्लॉक का उपयोग सेलस्टार्टेड संशोधक में किया जाता है। फ्रीज़ब्लॉक का उपयोग isFrozen संशोधक में अनुबंध के मालिक (मुझे!) को रोकने के लिए किया जाता है स्टार्टब्लॉक से पहले मूल्य में बदलाव करने और स्टार्टब्लॉक-फ्रीज़ब्लॉक ब्लॉक से कम स्टार्टब्लॉक ब्लॉक करने से। यदि आप इथरस्कैन पर देखते हैं तो आप देख सकते हैं कि हमारा स्टार्ट ब्लॉक वर्तमान में 3939181 पर सेट है, जो एक प्राइम नंबर है और इसलिए टोकन लॉन्च करने के लिए एक बहुत अच्छा ब्लॉक है। ब्लॉक 3939181 को 26 जून को दोपहर ईएसटी के आसपास आना चाहिए। हमारा फ़्रीज़ब्लॉक 3937741 पर सेट है, जो स्टार्टब्लॉक से लगभग छह घंटे पहले आना चाहिए।

हम अंतिम बिक्री मूल्य को लगभग एक दिन पहले निर्धारित करने की योजना बना रहे हैं और संभवत: इसे अंतिम समय में समायोजित नहीं करेंगे जब तक कि ईथर की कीमत में भारी उछाल न हो। लेकिन आपके लिए, एक खरीदार के रूप में, आप निश्चिंत हो सकते हैं कि हम नहीं कर सकता बिक्री शुरू होने से छह घंटे पहले कीमत में बदलाव करें, ताकि आपको पता चल जाए कि आप किस कीमत का भुगतान कर रहे हैं।

यदि हम startBlock को बदलने का निर्णय लेते हैं, तो changeStartBlock फ़ंक्शन में ध्यान दें कि freezeBlock स्वचालित रूप से नए startBlock को छाया देगा। इसलिए यदि हम स्टार्टब्लॉक को बदलते हैं, तो आप अभी भी निश्चिंत हो सकते हैं कि बिक्री से छह घंटे पहले अंतिम मापदंडों को लॉक कर दिया जाएगा और हम उन्हें बदल भी नहीं पाएंगे।

एक महत्वपूर्ण मालिक-केवल फ़ंक्शन जिसे isFrozen संशोधक द्वारा संशोधित नहीं किया गया है, वह है इमरजेंसी टॉगल। अगर यहां कोई भी बिंदु हमें लॉन्च कॉन्ट्रैक्ट में कुछ समस्या का पता चलता है, हम बिक्री को आगे बढ़ने से रोकने के लिए इमरजेंसी टॉगल को सक्रिय कर सकते हैं।

द क्रिटिकल पाथ

बिक्री अनुबंध 242 लाइन लंबा है, लेकिन 31 लाइनें (16 माइनस टिप्पणियां और व्हाइटस्पेस) हैं जो वास्तव में महत्वपूर्ण रास्ते में हैं। यह PurchaseTokens फ़ंक्शन है। सबसे पहले ध्यान दें कि यह अनुबंध में देय के रूप में निर्दिष्ट एकमात्र फ़ंक्शन है, जिसका अर्थ है कि अनुबंध को भेजे गए कच्चे प्रेषण वापस आ जाएंगे। दरअसल, जिन संदेशों में खरीद टोकन के अलावा किसी भी फ़ंक्शन पर भेजा गया ईथर बैलेंस शामिल होता है, वे वापस लौट आएंगे। देय संशोधक के अलावा, PurchaseTokens फ़ंक्शन के संशोधक के लिए आवश्यक है कि बिक्री शुरू हो गई है, आपातकालीन ध्वज को टॉगल नहीं किया गया है और अनुबंध का सेटअप पूरा हो गया है (सेटअप) है पूरा करें, इथरस्कैन पर अपने लिए देखें!)

ठीक है, संशोधक बहुत सरल लगते हैं। PurchaseTokens फ़ंक्शन में क्या होता है?

178—180 की तर्ज पर हम यह निर्धारित करने जा रहे हैं कि प्रेषक ने कोई अतिरिक्त ईथर भेजा है या नहीं। यदि adToken की कीमत 2 Wei है और उपयोगकर्ता हमें 3 Wei भेजता है, तो दुख की बात है कि हम उपयोगकर्ता को आधा AdToken नहीं दे सकते। हमें उन्हें उनके कुछ पैसे वापस देने होंगे! इन पंक्तियों में हम यही करते हैं: यह निर्धारित करें कि क्या कोई अतिरिक्त ईथर भेजा गया था ताकि हम उन्हें वापस भेज सकें।

एक बार जब हम ऐसा कर लेते हैं, तो हमें ठीक-ठीक पता होता है कि प्रेषक हमें भेजे गए ईथर की मात्रा को देखते हुए कितने AdToken खरीद सकता है। लाइन 183 पर हम यह सुनिश्चित करते हैं कि वास्तव में बिक्री के लिए अभी भी पर्याप्त AdToken उपलब्ध हैं और यदि नहीं है तो लेनदेन को वापस कर दें। अगर वहाँ है हैं क्रेता के लिए उनके द्वारा निर्दिष्ट राशि खरीदने के लिए पर्याप्त AdToken उपलब्ध है, फिर हम लाइन 187 पर उनके द्वारा भेजे गए किसी भी अतिरिक्त ईथर को आगे बढ़ने से पहले उनके पास वापस भेज देते हैं।

ठीक है, हम लगभग पूरा कर चुके हैं! लाइन 191 पर हम प्रेषक द्वारा भेजे गए ईथर को हमारे वॉलेट में स्थानांतरित करते हैं। इसके ठीक बाद हम प्रेषक द्वारा अभी-अभी खरीदे गए टोकन को उनके द्वारा भेजे गए खाते में स्थानांतरित करते हैं।

ध्यान दें कि हम लाइन 191 पर भेजने के बजाय ट्रांसफ़र का उपयोग करते हैं। ट्रांसफ़र और सेंड दोनों ही रिसीविंग एड्रेस पर केवल 2300 गैस फ़ॉरवर्ड करेंगे, जो रीएंट्रेंसी को रोकता है, जिसके जैसे डीएओ को नीचे लाया गया था, लेकिन अगर रिसीवर फ़ॉलबैक फ़ंक्शन में आउट-ऑफ़-गैस त्रुटि उत्पन्न होती है, तो ट्रांसफ़र वास्तव में पूरे लेनदेन को वापस कर देगा।

लाइन 194 पर हम अपने टोकन ट्रांसफर को लपेटते हैं (ईथर ट्रांसफर से अलग!) एक दावे के बयान में। हम जिन ERC-20 टोकन कॉन्ट्रैक्ट का उपयोग कर रहे हैं, वे विफल होने पर गलत रिटर्न देते हैं, और यदि टोकन ट्रांसफर किसी भी कारण से विफल हो जाता है, तो हम पूरे लेनदेन को वापस करना चाहेंगे।

अंत में, लाइन 196 पर हम एक ईवेंट का उत्सर्जन करते हैं ताकि दुनिया को पता चल सके कि खरीदारी सफल रही!

ध्यान देने योग्य बातें: एक बार बिक्री बिक जाने के बाद, टोकन खरीदने के लिए सभी लेनदेन लाइन 183 पर चेक के कारण फेंक दिए जाने चाहिए। इसका मतलब है कि बिक्री खत्म होने के बाद सेल कॉन्ट्रैक्ट ईथर देने का कोई तरीका नहीं होना चाहिए। इसी तर्क का अर्थ यह भी है कि बिक्री पूरी तरह से बिक जाने से पहले ही, उपलब्ध टोकन से अधिक की खरीदारी विफल हो जाएगी — छोटी खरीदारी से आपको टोकन बेचने से पहले उन्हें प्राप्त करने का बेहतर मौका मिल सकता है! एक रैपर कॉन्ट्रैक्ट लिखना भी संभव है, जो बिल्कुल सही मात्रा में टोकन खरीदेगा और प्रेषक को कोई भी अतिरिक्त शेष राशि लौटाते समय बिक्री को बंद कर देगा, लेकिन हम इसे पाठक पर एक अभ्यास के रूप में छोड़ देते हैं (सुनिश्चित करें कि आप टोकन वापस लेने के लिए एक फ़ंक्शन लिखते हैं! टोकन का श्रेय msg.sender को दिया जाता है, जो आपका कॉन्ट्रैक्ट होगा! जब तक आप निकासी फ़ंक्शन निर्दिष्ट नहीं करते हैं, तब तक आप ऐसा करते हुए अपने टोकन लॉक कर देंगे!)।

टेस्टिंग मिशन क्रिटिकल कोड

मेरे एक इंटर्न ने हाल ही में मुझसे पूछा कि इस तरह के महत्वपूर्ण कोड का परीक्षण कैसे किया जाए। जवाब: बहुत सावधानी से! हमारे पास यूनिट टेस्ट की 950 लाइनें हैं (सभी 42 पास हो चुके हैं!) और रिंकेबी और कोवन पर तीन लाइव परीक्षण किए हैं, साथ ही अंतिम परिनियोजन मापदंडों के साथ वर्तमान में चौथा परीक्षण चल रहा है। इन अनुबंधों को लिखने और यह जानने के तनाव में रहने से कि बहुत सारे लोगों के पैसे जलाने के लिए मैं जिम्मेदार हो सकता हूं, ने मुझे ईवीएम प्रोग्रामिंग और तैनाती स्कैफोल्डिंग दोनों के लिए कार्यात्मक भाषाओं को फिर से देखने के लिए बहुत उत्साहित किया है। यह जानकर अच्छा लगेगा कि कंपाइलर द्वारा बग्स की पूरी श्रेणी को हटा दिया गया है। लेकिन यह अगली बार होगा। अभी के लिए हमारे पास अच्छी पुरानी (गतिशील रूप से टाइप की गई) जावास्क्रिप्ट और (अनिवार्य) सॉलिडिटी है।

इस टोकन लॉन्च की सुरक्षा के बारे में मुझे बहुत अच्छा महसूस कराने का अंतिम चरण है... एक सार्वजनिक बग बाउंटी!

AdToken लॉन्च कॉन्ट्रैक्ट बग बाउंटी!

हमारे कॉन्ट्रैक्ट तैनात किए गए हैं कोवन पर मेननेट के साथ-साथ, और हम बड़े इनाम (500 हजार adToken!) की पेशकश कर रहे हैं उन बगों के लिए जो ये कर सकते हैं:

1. ईथर या एडटोकन को लॉक/बर्न करें
2. ईथर या adToken की चोरी को सक्षम करें

हम उन बग के लिए छोटे इनाम की पेशकश करेंगे जो अप्रत्याशित व्यवहार उत्पन्न करते हैं जो संपत्ति की चोरी के स्तर तक नहीं बढ़ते हैं। अगर आपको कोवन ईटीएच की ज़रूरत है या आप अन्य बाउंटी हंटर्स के साथ संवाद करना चाहते हैं, AdChain स्लैक में शामिल हों!

कृपया सभी बग bugs@metax.io पर भेजें