10 जून को हांगकांग में हमारे समझौते का तीसरा दिन था। और पिछले 26 घंटे हमने बिना नींद के बिताए, ईओएस ग्लोबल हैकाथॉन के पहले चरण में डेढ़ मिलियन डॉलर के कुल पुरस्कार पूल के साथ काम करने के नाम पर एक प्रोटोटाइप प्रोजेक्ट विकसित किया। न्यायाधीशों के समक्ष परियोजना के प्रदर्शन का क्षण निकट आ रहा था।

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

0. पृष्ठभूमि

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

ईओएस की तुलना में ईथेरियम की तुलना में लाभ: लेन-देन थ्रूपुट परिमाण के तीन आदेश अधिक हैं; स्मार्ट अनुबंधों के लिए विकसित अनुमति-प्रणाली; ब्लॉकचैन में खोई हुई पहुंच को बहाल करने और त्रुटियों को ठीक करने की क्षमता; onchain नेटवर्क प्रबंधन। कमजोरियाँ: केंद्रीकरण चिंता, संभावित रूप से अधिक कमजोर DPoS आम सहमति, कच्चे कोड, और डेवलपर्स के लिए एक स्टेटर लर्निंग कर्व।

चूंकि हम लंबे समय से इस तकनीक के शौकीन हैं और इसे होनहार मानते हैं, इसलिए हम हैकथॉन की श्रृंखला की अवहेलना नहीं कर सकते, जो ईओएस के लेखकों द्वारा समर्थित है। हम बस वहां रहना चाहते थे, इस प्रेरणादायक वातावरण में अपने विचारों को महसूस करें और उन्हें व्यापक दर्शकों के साथ साझा करें। बेशक, अच्छा पैसा जीतने का अवसर एक अतिरिक्त सुखद प्रेरक भी बन गया।

इसलिए, EOS सार्वजनिक ब्लॉकचेन के लिए एकमात्र कार्यशील समाधान है जिसे हम जानते हैं कि आप MANY लेनदेन कहां कर सकते हैं। इसकी आवश्यकता कहाँ है? बेशक IoT में! वास्तव में, यदि प्रत्येक टोस्टर माइक्रोएमेमेंट हो जाता है, तो यह रेफ्रिजरेटर को रोटी के प्रत्येक टुकड़े के लिए भुगतान करेगा (और यह डिफ़ॉल्ट रूप से अच्छा है, जैसा कि आप समझते हैं), बहुत अधिक लेनदेन होगा। चिकित्सा, उद्योग और रोजमर्रा की जिंदगी में अन्य अनुप्रयोगों के सभी प्रकारों का उल्लेख नहीं करना।

हैकाथॉन से कुछ हफ्ते पहले, वैकल्पिक विचारों को समय-समय पर पॉप अप किया गया था, और छोटे विचार-मंथन आयोजित किए गए थे। हमने प्रसिद्ध रेफरी के मानदंडों के आधार पर विचारों की तुलना की: ईओएस क्षमताओं का उपयोग, रचनात्मकता, सार्वजनिक प्रभाव और स्केलेबिलिटी। नतीजतन, हम IoT + EOS पर बस गए - एक समाधान जो सेंसर से डेटा लेगा और ईओएस को बहुत सारे भुगतान लेनदेन भेजेगा।

वैसे, हम वास्तव में यहां यह भी बताना चाहते थे कि हमने अपने ब्लॉक निर्माता को ईओएस के लिए कैसे उठाया; कैसे उन्होंने उनके लिए ERC721 जैसे टोकन का निर्माण करने और निरंतर कार्यों के लिए समर्थन करने की योजना बनाई; उन्होंने मर्कले रूट ACL प्रोटोकॉल कैसे दर्ज किया। लेकिन यह सब लेख में फिट नहीं होता है, इसलिए हम अपने मुख्य प्रोजेक्ट पर लौट आएंगे।

1. तैयारी

1.1। IoT

परियोजना का IoT भाग तैयार करना सही हार्डवेयर चुन रहा है। RFID रीडर की भूमिका में, SPI बस पर ऑपरेटिंग RC522 को चुना गया था: यह लोकप्रिय और उपयोग करने में आसान है।

एक काउंटर की खोज करते समय, हमने एक पल्स आउटपुट की उपस्थिति पर ध्यान केंद्रित किया, क्योंकि यह आपको डेटा को बहुत सरलता से पढ़ने की अनुमति देता है: एक पल्स एक्स kW ish है (जहां एक्स मॉडल पर निर्भर करता है), नतीजतन, हम मर्करी 201.5 काउंटर पर रुक गए।

सबसे मुश्किल काम था नियंत्रक पर निर्णय लेना, जो सेंसर से डेटा इकट्ठा करना चाहिए, एक लेनदेन तैयार करना चाहिए, इसे अपनी निजी कुंजी के साथ हस्ताक्षर करना चाहिए और इसे नेटवर्क पर भेजना चाहिए। तदनुसार, हमें एक नेटवर्क मॉड्यूल के साथ एक उपकरण की आवश्यकता थी जो ईसीडीएसए का उपयोग करके लेनदेन पर हस्ताक्षर कर सकता है (इस मामले में, अण्डाकार वक्र secp256k1 पर, क्योंकि यह साइन इन करने के लिए ईओएस में उपयोग किया जाता है)।

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

1.2। आधारभूत संरचना

हैकाथॉन से कुछ दिन पहले, हमने स्थानीय रूप से और eos-hackathon.smartz.io सर्वर पर EOS असेंबली ( स्रोत ) तैयार किया। निर्भरता स्थापना, विधानसभा, और परीक्षण ऐसे युवा परियोजना ( प्रलेखन का उपयोग करके) के लिए आश्चर्यजनक रूप से सुचारू रूप से चला गया। अन्य बुनियादी ढांचे की तैयारी के लिए पर्याप्त समय नहीं था, और मुझे हैकथॉन के दौरान पहले से ही इसका सामना करना पड़ा।

1.3। आर्किटेक्चर

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

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

उपयोगकर्ता प्राथमिकताएं उपभोक्ता या झंडे (उदाहरण के लिए, एक तरजीही उपयोगकर्ता श्रेणी) से user_meta - user_meta । कई सेंसर को उपभोक्ता के साथ जोड़ा जा सकता है, उनमें से प्रत्येक के लिए एक अनुबंध और बिलिंग सेटिंग्स ( billing_meta ) इंगित की गई हैं। तो आप एक अपरिवर्तनीय स्टेटलेस बिलिंग अनुबंध प्राप्त कर सकते हैं, जिसका उपयोग बड़ी संख्या में उपभोक्ताओं के लिए किया जाता है; आवश्यक डेटा bill(payload, user_meta, billing_meta) विधि bill(payload, user_meta, billing_meta) के आह्वान के दौरान दिखाई देगा। इसके अलावा, अलग-अलग बिलिंग तर्क, यानी, अलग-अलग अनुबंधों की संभावना रखी गई है: उदाहरण के लिए, एक बिजली मानता है, दूसरा - माल। प्रत्येक सेंसर के पास अपने बिलिंग अनुबंध के लिए "सूचक" होता है।

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

शायद हम में से अधिकांश ने निम्नलिखित मुद्दों पर चर्चा की, जो वास्तविक दुनिया में उत्पाद की प्रयोज्यता के लिए महत्वपूर्ण हैं:

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

2. कोडिंग

सबसे पहले, उन्होंने एपीआई और आपूर्तिकर्ता के अनुबंध की रूपरेखा को निर्दिष्ट किया ताकि एक साथ फ्रंटएंड, डिवाइस कोड, बिलिंग और मुख्य अनुबंध ( स्रोत ) का विकास शुरू हो सके।

2.1। IoT

एक काउंटर से दालों को पढ़ने के लिए एक कोड लागू करने वाला पहला। GPIO (सामान्य प्रयोजन पिन) के साथ काम करने के लिए, ऑनऑफ JS पुस्तकालय का उपयोग किया गया था। बाद में, स्पष्टता के लिए सर्किट में दो एल ई डी जोड़े गए: पहला पलक जब काउंटर से एक सिग्नल प्राप्त हुआ, और दूसरा जब ईओएस नोड से एक सफल लेनदेन के बारे में जवाब आया। इसी तरह, हमने आरएफआईडी टैग पढ़ने के लिए एक योजना और कोड विकसित किया, एकमात्र अंतर के साथ: MFRC522-python पुस्तकालय का उपयोग करके SPI बस पर रीडिंग हुई। जैसा कि यह निकला, रास्पबेरी पाई 3 के लिए एसपीआई सेटिंग पहले के बोर्ड मॉडल में सेटिंग से अलग है; इस निर्देश ने हमें समझने में मदद की।

डिवाइस को पावर बैंक से संचालित किया गया था, जिसे सफलतापूर्वक सभी हैकाथॉन प्रतिभागियों को प्रस्तुत किया गया था, और उन्हें खुद को iPhone 5 के साथ इंटरनेट साझा करना था, क्योंकि हैकाथॉन के वाई-फाई ने विशेष रूप से 5 गीगाहर्ट्ज पर काम किया था, यह रास्पबेरी पाई के लिए काम नहीं करता था।

2.2। अवसंरचना और उपयोगिताएँ

आयोजकों ने ईओएस-देव की डॉक छवि को लेने की सलाह दी, लेकिन हम छवि के विवरण और प्रलेखन की कमी से भ्रमित थे। सर्वर पर, वे तैयार विधानसभा के साथ काम करना जारी रखते थे, और स्थानीय रूप से, ईओएस को व्यवस्थित रूप से स्थापित करने से बचने के लिए, वे ईओस-देव का उपयोग करते थे।

तुरंत निर्माण और परीक्षण करने की क्षमता की तत्काल आवश्यकता है। आदर्श: स्थानीय रूप से निष्पादन योग्य फ़ाइल बनाना और चलाना। हालांकि, इस तथ्य को नजरअंदाज करना असंभव था कि असेंबली के बाद, आउटपुट को WebAssembly की आवश्यकता होती है, और EOS वातावरण में, इसी बढ़ावा, पुस्तकालयों, सिस्टम अनुबंधों के साथ। आवश्यक संकलन विकल्प eosiocpp.in में जासूसी की जा सकती है, हालांकि, हमने इस खेल को नहीं खेलने का फैसला किया। अनुमानित परिणाम, थोड़ा धीमा, संभावित रेक के साथ त्वरित समाधान की तुलना में अधिक महत्वपूर्ण है। इसलिए, असेंबली के लिए हमने ईस्कोप लिया, जो ईओस-देव कंटेनर में है।

यह लॉन्च के साथ और अधिक कठिन हो गया, मुझे स्थानीय ईओएस ब्लॉकचेन को उठाना पड़ा, और फिर से कोई तैयार समाधान नहीं था। केवल सॉफ्टवेयर। इसलिए लॉन्च इंफ्रास्ट्रक्चर का पहला संस्करण दिखाई दिया। बढ़ते और विन्यास की बारीकियों को छिपाने और विशिष्ट कार्यों के लिए चार से पांच "बटन" का आत्म-सुसंगत सेट प्राप्त करने का विचार है। कम नियंत्रण, लेकिन त्रुटि की कम संभावना, साथ ही समय की बचत।

ईओएस के मुख्य घटकों में नोडोस, केओसड डेमोंस, क्लोस कंसोल यूटिलिटी और एस्कॉप कंपाइलर शामिल हैं:

• नोडोस - ईओएस नोड, डेमन - नेटवर्क प्रतिभागी, ब्लॉकचेन तक पहुंच प्रदान करता है और वैकल्पिक रूप से नए ब्लॉक का उत्पादन करता है;
• keosd - स्थानीय वॉलेट्स के प्रबंधन के लिए एक डेमन जो प्रमुख जोड़े को संग्रहीत करता है;
• क्लोस कुंजी के साथ काम करने के लिए लेन-देन के बारे में जानकारी प्राप्त करने से कमांड प्रदान करता है, यह HTTP API के माध्यम से नोड और केओस्ड में कॉल के आधार पर कार्यान्वित किया जाता है;
• eoscpp WebAssembly में अनुबंध संकलित करता है, और आपको स्रोत कोड के आधार पर एप्लिकेशन बाइनरी इंटरफ़ेस प्राप्त करने की अनुमति देता है।

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

अगला चरण कंटेनर ( कमिट ) में संकलक का उपयोग करके अनुबंध संकलन उपयोगिता था। इनपुट और आउटपुट निर्देशिकाओं को माउंट किया गया था। और अंत में, ब्लॉकचैन को एक अनुबंध अपलोड करने और लेनदेन ( कमिट ) भेजने की क्षमता। फिर से - एक सुसंगत शैली में उपयोगिताओं, सरल "बटन"। इसने बुनियादी ढांचे को समाप्त कर दिया, लेकिन आश्चर्य जारी रहा: हम स्मृति के साथ काम करने के लिए सी-फ़ंक्शन की समस्या पर ठोकर खाई (नीचे और अधिक विवरण में)।

अंत में, उन्होंने एक फ़ाइल में प्रत्येक खाते को स्थापित करना शुरू कर दिया (प्रत्येक अनुबंध और प्रतिभागी को अलग-अलग खातों की आवश्यकता होती है) प्रमुख जोड़े के साथ-साथ ब्लॉकचैन शुरू होने पर स्वचालित रूप से बनाई जाती हैं, ताकि एक टीम परीक्षण वातावरण बढ़ा सके। इस वातावरण की एक प्रति eos-hackathon.smartz.io पर तैनात की गई थी।

2.3। स्मार्ट कॉन्ट्रैक्ट

2.3.1। आपूर्तिकर्ता अनुबंध और बिजली बिलिंग

हैकाथॉन की शुरुआत के बाद, हमने ऊपर की योजना के अनुसार अनुबंधों की संरचना को तैयार करना शुरू किया। प्रणाली में निम्नलिखित अनुबंध शामिल थे:

• supplier - supplier अनुबंध;
• billing_electricity - मीटर के प्रत्येक टिक के लिए बिजली के लिए भुगतान की गणना के लिए एक अनुबंध।

supplier अनुबंध में, अधिकांश काम साधारण सीआरयूडी संचालन द्वारा किया जाता है: उपयोगकर्ता, टैरिफ, काउंटर को जोड़ना, उपयोगकर्ता के संतुलन को बढ़ाना या घटाना। मीटर से डेटा प्राप्त करने के लिए और अधिक जटिल तरीके जिम्मेदार थे, एक बिलिंग अनुबंध से कॉलबैक के बाद एक उपयोगकर्ता के व्यक्तिगत खाते पर डेबिट, भुगतान (बिलिंग) की गणना करने के लिए अनुबंध करना। उपयोगकर्ता के टैरिफ के आधार पर आवश्यक बिलिंग अनुबंध निर्धारित किया गया था।

बिलिंग के लिए अनुबंध में कॉल के बाद, भुगतान की गणना की गई और उपयोगकर्ता के व्यक्तिगत खाते से भुगतान को डेबिट करने के लिए विधि को कॉल किया गया। मुख्य तर्क देने के बाद, हमने सोचा कि अगर हम बहुत सरल अनुबंध कर रहे हैं। थोड़ी देर बाद, नोड में अनुबंधों की तैनाती और उनके परीक्षण के बाद, यह स्पष्ट हो गया कि अनुबंध सरल हो सकते हैं, लेकिन बारीकियां हैं। :)

तैनाती के बाद, यह पता चला कि एक दूसरे से अपेक्षित अनुबंध कॉल काम नहीं करता था। पर्याप्त अधिकार नहीं। इथेरेम में स्मार्ट कॉन्ट्रैक्ट के विपरीत, जहां कॉलिंग कॉन्ट्रैक्ट की ओर से एक कॉन्ट्रैक्ट से कॉल किया जाता है, ईओएस में, पूरी श्रृंखला लेनदेन के आरंभकर्ता से शुरू होती है। जब किसी अनुबंध को अनुबंध से बुलाया जाता है, तो यह जांचा जाता है कि क्या सर्जक ने अनुबंध को ऐसा करने की अनुमति दी है।

Mentors ने तुरंत सुझाव दिया कि एक साधारण मामले में कैसे कार्य किया जाए। अधिकार निम्नानुसार जोड़े गए हैं (ईओसियो सिस्टम स्मार्ट अनुबंध को कॉल करके):

 ./cleos push action eosio updateauth '{"account":"electricity","permission":"active","parent":"owner","auth":{"keys":[{"key":"EOS7oPdzdvbHcJ4k9iZaDuG4Foh9YsjQffTGniLP28FC8fbpCDgr5","weight":1}],"threshold":1,"accounts":[{"permission":{"actor":"supplier","permission":"eosio.code"},"weight":1}],"waits":[]}}' -p electricity 

इस मामले में, electricity खाता supplier को अपनी ओर से अन्य अनुबंधों को कॉल करने की अनुमति देता है। आप तकनीकी WP EOS में अधिकारों के बारे में अधिक पढ़ सकते हैं। हमारे देश में, supplier अनुबंध ने billing अनुबंध का कारण बना, और बदले में, फिर से supplier बुलाया। इस रूप में अधिकारों के सादृश्य द्वारा जोड़ने से काम नहीं हुआ:

 ./cleos push action eosio updateauth '{"account":"electricity","permission":"active","parent":"owner","auth":{"keys":[{"key":"EOS7oPdzdvbHcJ4k9iZaDuG4Foh9YsjQffTGniLP28FC8fbpCDgr5","weight":1}],"threshold":1,"accounts":[{"permission":{"actor":"supplier","permission":"eosio.code"},"weight":1},{"permission":{"actor":"billelectro","permission":"eosio.code"},"weight":1}],"waits":[]}}' -p electricity 

एक त्रुटि जारी की गई थी: अमान्य प्राधिकरण। यहाँ संरक्षक अब हमारी मदद नहीं कर सकते: उन्होंने कहा कि उन्होंने खुद ऐसा नहीं किया। और किसने किया? शायद केवल डैन लैरीमर। हम ईओएस कोड में त्रुटि का कारण जल्दी से पता नहीं लगा पाए हैं और पहले से ही वैकल्पिक विकल्पों पर विचार करना शुरू कर दिया है, बिना कॉल की श्रृंखला के। यह खूबसूरती से रोकता है कि ईओएस में अन्य अनुबंधों को कॉल करने का तंत्र भी ईथर से अलग है। जब किसी अन्य अनुबंध को कॉल किया जाता है, तो यह कॉल कतारबद्ध होती है और केवल वर्तमान कॉल के पूरा होने के बाद ही पूरी हो जाएगी। यह अनुबंध को कॉल करने और इस अनुबंध द्वारा दर्ज किए गए डेटा को पढ़ने के लिए कॉल करने के बाद काम नहीं करेगा।

बाद में, आखिरकार, उन्होंने दो अनुबंधों के अधिकारों को निर्धारित करते समय EOS कोड में त्रुटि का कारण पाया। यह पता चलता है कि अधिकारों की सूची में खातों को खाते द्वारा क्रमबद्ध किया जाना चाहिए: सुनिश्चित करता है कि सभी कुंजियाँ अद्वितीय और क्रमबद्ध हैं और सभी खाते अनुमतियाँ अद्वितीय और क्रमबद्ध हैं ( प्राधिकारी ।hpp )। खातों के क्रम को बदलने के बाद, अधिकारों के अद्यतन ने काम किया - और हमारी अनुबंध प्रणाली संचालित होने लगी।

2.3.2। स्मृति के साथ सी-कार्यों की समस्या

यह कहना हास्यास्पद है, लेकिन अंत में हम बिलिंग कॉन्फ़िगरेशन को पढ़ने के लिए तैयार किए गए कार्यों को पार्सिंग संख्या (!) के लिए उपयोग करने में सक्षम नहीं थे। निम्नलिखित std::istringstream फ़ंक्शन को खींच लिया गया था, जो कि बल्कि अजीब है। और जब atof और जैसे, साथ ही sscanf - env.realloc कड़ा कर env.realloc । किसी कारण से, नोड सी में कोड लोडिंग के दौरान मानक सी लाइब्रेरी की मेमोरी के साथ काम करने के उल्लिखित कार्य नहीं पाए गए थे। मेमोरी के साथ काम करने वाले C ++ फ़ंक्शन ने काम किया।

बेशक, जब WebAssembly अनुबंध को निष्पादित किया जाता है, न कि एक मानक मेमोरी एलोकेटर का उपयोग किया जाता है, लेकिन इसका अपना सैंडबॉक्स, जो कुछ शर्तों के तहत प्रत्येक लेनदेन को प्रदान किया जाता है। इसके अलावा, इस सैंडबॉक्स के शीर्ष पर मेमोरी के साथ काम करने के सी-कार्यों के लिए समर्थन लंबे समय से लागू किया गया है, उनका कार्यान्वयन मानक एसओएस अनुबंधों में है । शायद लिंकिंग स्टेज पर कुछ गलत हो गया।

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

2.3.3। खरीदारी बिलिंग

दूसरी हवा में, जिसे या तो बिजली इंजीनियरों द्वारा या शुरुआती नाश्ते द्वारा खोला गया, उन्होंने स्टोर में खरीदारी के लिए बिलिंग लिखी। कार्य की सामान्य योजना इस प्रकार है:

1. आपूर्तिकर्ता एक बिलिंग अनुबंध बनाता है और इसे अपने सामान्य अनुबंध में निर्धारित करता है।
2. स्टोर के आउटलेट पर, आपूर्तिकर्ता ऐसे फ्रेमवर्क स्थापित करता है जो आरएफआईडी पढ़ सकते हैं, ईओएस के साथ बातचीत कर सकते हैं और बिलिंग अनुबंध में अपने स्वयं के खाते निर्धारित कर सकते हैं।
3. स्टोर में प्रत्येक उत्पाद RFID टैग से सुसज्जित है, सभी टैग बिलिंग अनुबंध में पंजीकृत हैं।
4. खरीदार अपने आरएफआईडी को स्कैन करके माल का भुगतान करता है, और माल बिलिंग अनुबंध से हटा दिया जाता है।
5. स्टोर से बाहर निकलने पर, फ़्रेम अतिरिक्त रूप से RFID खरीद पढ़ता है। यदि सामान अभी भी स्टोर में है, तो लेन-देन पास नहीं होता है, और फ्रेम को अलार्म बजना चाहिए (हाँ, वास्तव में, आप लेन-देन भी नहीं भेज सकते हैं, लेकिन सिर्फ तालिका पढ़ें)।

यह कॉन्ट्रैक्ट कोड पर ही रहने का कोई मतलब नहीं है: यह कुछ ईओएस-विशिष्ट निर्माणों और पुस्तकालयों के साथ मानक C ++ 14 है। EOSIO विकी और EOSIO डेवलपर पोर्टल में बेहतर कहा गया है।

2.3.4। दृश्यपटल

रिएक्ट का उपयोग करके परियोजना के सामने का हिस्सा लागू किया गया था। सामान्य के बजाय कई Redux ने MobX का उपयोग करने का फैसला किया, जो विकास को काफी तेज करता है और आपको सिरदर्द के बिना वैश्विक स्थिति का प्रबंधन करने की अनुमति देता है।

सामने-ब्लॉकचैन एकीकरण चरण उम्मीद के मुताबिक सुचारू रूप से नहीं चला। ईओजेएस पैकेज को बहुत सक्रिय रूप से अंतिम रूप दिया जा रहा है , इसके बाद स्कैटर ब्राउज़र के लिए ईओएस वॉलेट का उपयोग किया जाएगा। इस गुच्छा में, यह अक्सर समस्याओं का कारण बनता है। और इस तथ्य से नहीं कि कल काम करने वाला कोड आज ठीक काम करेगा। हमने इस रेक पर कदम रखा (और पहली बार नहीं)। एक घंटे की कोशिश और एक सुस्त राज्य में डिबगिंग - समस्या हल हो गई है।

ईओएस के साथ आवेदन के ग्राहक पक्ष की बातचीत के एक सरल आरेख पर विचार करें। ऐसा करने के लिए, आपको eosjs लाइब्रेरी और स्कैटर ब्राउज़र एक्सटेंशन की आवश्यकता है।

हम आपको याद दिलाते हैं! Eosjs के बाद स्कैटर को सक्रिय रूप से अपडेट किया जाता है, लाइब्रेरी को अपडेट करना न भूलें।

अगला, पढ़ने और लिखने पर एक संक्षिप्त नज़र। ईओएस में स्मार्ट कॉन्ट्रैक्ट के साथ संवाद करने के दो तरीके हैं: लेनदेन भेजना (यह ब्लॉकचेन को संशोधित करता है, जिसमें कोई रिटर्न मूल्य नहीं दिए गए हैं) और रीडिंग टेबल (रीड-ओनली एक्शन)।

लेनदेन भेजने वाले कोड पर विचार करें:

  sendTransaction(funcName, data) { return this.scatter .suggestNetwork(this.network) .then(() => this.scatter.getIdentity({ accounts: [this.network] })) .then((identity) => { let accountName = this.getAccountName(identity); // wrap eos instance const eos = this.scatter.eos(this.network, Eos, this.configEosInstance); return eos.transaction(accountName, (contract) => { contract[funcName](data, { authorization: accountName }); }); }); } 

इनपुट तर्क: फ़ंक्शन नाम और ऑब्जेक्ट, इसके मान इस फ़ंक्शन के तर्क हैं। तीसरी पंक्ति: हम उस नेटवर्क की पुष्टि करते हैं जिसके माध्यम से हम ईओएस के साथ बातचीत करते हैं। चौथी पंक्ति: हमें identity मिलती identity , पैरामीटर accounts फ़ील्ड (इस नेटवर्क के लिए) के साथ एक ऑब्जेक्ट है। getAccountName फ़ंक्शन खातों की प्राप्त सूची ( identity ऑब्जेक्ट में) से पहला खाता लौटाता है।

इस उदाहरण में, लेनदेन पर हस्ताक्षर करने के लिए स्कैटर का उपयोग किया जाता है। स्कैटर Eos वर्ग के उदाहरण पर एक आवरण है। लाइन 9 पर, हम eos विधि, इसके पैरामीटर कहते हैं:

1. this.network - नेटवर्क पैरामीटर्स के साथ एक ऑब्जेक्ट।
2. Eos ईओजेएस का एक उदाहरण है।
3. this.configEosInstance - एक this.configEosInstance उदाहरण के लिए मापदंडों के साथ एक वस्तु (डॉक ईओएसज देखें)।

अंतिम transaction विधि accountName और callback को एक इनपुट के रूप में स्वीकार करती है, callback तर्क खाता accountName में स्थित एक अनुबंध है। callback 'ई' में, हम ऑब्जेक्ट के साथ प्राप्त अनुबंध की विधि को कहते हैं, इसकी चाबियां तथाकथित विधि के तर्क हैं।

तालिका पढ़ने की विधि पर विचार करें:

  readTable(data) { this.eos = this.scatter.eos(this.network, Eos, this.configEosInstance); return this.eos.getTableRows({ json: true, limit: 1, ...data, }); } 

यहाँ पढ़ने के लिए हमें केवल एक उदाहरण की आवश्यकता है।

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

3. असेम्बली

समय समाप्त होने से तीन घंटे पहले, हमारे पास पारा बिजली मीटर के साथ एक रास्पबेरी पाई और उससे जुड़ा एक आरएफआईडी रीडर, साथ ही साथ एक हल्का संकेत भी था। सभी टेबल बिजली बुध के माध्यम से चली गई। खर्च किए गए प्रत्येक 0.3125 के लिए, साथ ही साथ प्रत्येक "खरीद" के लिए, रास्पबेरी पाई ने हमारे ब्लॉकचेन को लेनदेन भेजा, और सेवा प्रदाता उपयोगकर्ताओं, सेंसर, बिलिंग का प्रबंधन कर सकता है और खपत के आंकड़े देख सकता है।

एक और घंटे के लिए, हम शांति से चेक में लगे रहे और फिनिशिंग टच को जोड़ा। समय समाप्त होने से दो घंटे पहले, हमें दो कार्यान्वित मामलों के साथ एक पूर्ण उत्पाद प्राप्त हुआ, पूरी तरह से अवधारणा को दिखाता है, और यहां तक ​​कि अंतिम मिनटों में भी नहीं होता है!

4. प्रदर्शन

परियोजनाओं (उर्फ पिचों) के प्रदर्शनों में दो चरण शामिल थे। पहले चरण में, 69 प्रतिभागी टीमों को चार समूहों में विभाजित किया गया था, उनमें से प्रत्येक को दो न्यायाधीशों के सामने और दर्शकों के बिना अलग-अलग खिलाया गया था। न्यायाधीशों ने अंक दिए (प्रत्येक में 5 अंक के चार मानदंड), और इन अंकों के आधार पर, शीर्ष 10 टीमों को दूसरे चरण के लिए चुना गया। इन टीमों को दर्शकों और सभी आठ न्यायाधीशों के सामने एक बड़े मंच पर एक परियोजना का मंचन करने का अवसर दिया गया।

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

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

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

पहले दौर की चार धाराओं के न्यायाधीशों ने अपने स्कोर को कम किया और पिचों के अंत के 15 मिनट बाद विचारों का आदान-प्रदान किया। विजेताओं की घोषणा के बाद शुरू हुआ। हॉल में एक घबराया हुआ वातावरण था: 26 घंटे की मैराथन के बाद थक गए, लोग जीतना चाहते थे, कई मजबूत टीमें थीं, और वे जानते थे कि वे जीत का दावा कर सकते हैं। और हम जानते थे कि - और परिणामों का इंतजार किया।

दर्शकों को आराम करने से रोकने के लिए, परिणाम तीन भागों में घोषित किए गए। पहले चार फाइनल, फिर तीन और फिर एक और तीन। घोषणाओं के बीच और अंत में - प्रदर्शन। हम शीर्ष 10 में नहीं आए और हमें बड़े मंच में प्रवेश करने का अवसर नहीं मिला। दो रूसी-भाषी टीमों ने इसे शीर्ष दस में बनाया, जिनमें से एक अंततः तीसरा बन गया। विजेताओं को बधाई, वे अपने पुरस्कार के पात्र हैं।

5. निष्कर्ष और योजना

AngelHack . , . — , , . , , , — .

26 IoT- EOS. , .

— UI ( — -- Smartz ), . - , blockchain-ready , , — . :)

, , «», «» . . 5 . , 100 , . SensorPay !

:

Yuvasee (entrepreneur)
algs (hardware & backend developer)
therealal (architect, backend developer, devops)
bolbu (frontend developer)
quantum (blockchain & backend developer)