كان 10 يونيو هو اليوم الثالث للتأقلم في هونغ كونغ. وفي آخر 26 ساعة أمضيناها تقريبًا بدون نوم ، قمنا بتطوير مشروع نموذج أولي تحت اسم العمل SensorPay في المرحلة الأولى من هاكاثون EOS Global بمجموع جوائز يبلغ مليون ونصف مليون دولار. لحظة عرض المشروع قبل أن يقترب القضاة.

إذا كنت حريصًا على معرفة كيف انتهت هذه القصة ، فألق نظرة على الجزء الأخير على الفور. في غضون ذلك ، سنبدأ في التحدث بشكل منهجي عن تقنيات EOS وكيف توصلنا إلى فكرة ربط المدفوعات مقابل إنترنت الأشياء بـ EOS. بعد ذلك مباشرة سيكون هناك وصف تفصيلي للحشو الفني للمشروع.

0. الخلفية

EOS هو الجيل الجديد من blockchain ، والبعض يعتبره قاتل Ethereum. إذا كنت لا تعرف فجأة ما هو blockchain أو Ethereum ، فستساعدك Google. وقد حدث أننا بدأنا في حفر EOS منذ حوالي عام ، بما في ذلك من خلال دراسة المنتجات السابقة لمؤلفيها BitShares و Steem.

مزايا EOS مقارنة بـ Ethereum: معدل نقل المعاملات أكبر بثلاثة أوامر من حيث الحجم ؛ وضع نظام أذونات للعقود الذكية ؛ القدرة على استعادة الوصول المفقود وإصلاح الأخطاء في blockchain ؛ إدارة شبكة onchain. نقاط الضعف: مخاوف المركزية ، وإجماع DPoS المحتمل أن يكون أكثر عرضة للخطر ، والشفرة الأولية ، ومنحنى تعلم أكثر حدة للمطورين.

نظرًا لأننا مغرمون بهذه التكنولوجيا لفترة طويلة ونعتبرها واعدة ، لا يمكننا تجاهل سلسلة الهاكاثون ، التي يدعمها مؤلفو EOS. أردنا فقط أن نكون هناك ، ونحقق أفكارنا في هذه البيئة الملهمة ومشاركتها مع جمهور واسع. بالطبع ، أصبحت فرصة الفوز بأموال جيدة بمثابة محفز لطيف إضافي.

لذا ، فإن EOS هو الحل العامل الوحيد لسلسلة blockchain العامة التي نعرف أين يمكنك القيام بالعديد من المعاملات. أين هو مطلوب؟ بالطبع في إنترنت الأشياء! في الواقع ، إذا أصبحت كل محمصة مدفوعات صغيرة ، فستدفع مقابل كل قطعة خبز في الثلاجة (وهذا رائع افتراضيًا ، كما تفهم) ، سيكون هناك الكثير من المعاملات. ناهيك عن جميع أنواع التطبيقات الأخرى في الطب والصناعة والحياة اليومية.

قبل أسابيع قليلة من هاكاثون ، ظهرت أفكار بديلة بشكل دوري ، وعُقدت عصف ذهني صغير. قارنا الأفكار على أساس معايير التحكيم المعروفة: استخدام قدرات EOS والإبداع والتأثير العام وقابلية التوسع. ونتيجة لذلك ، استقرنا على IoT + EOS - وهو حل يأخذ بيانات من أجهزة الاستشعار ويرسل الكثير من معاملات الدفع إلى EOS.

بالمناسبة ، أردنا حقًا أن نخبر هنا أيضًا عن كيفية رفع منتج Block Blocker الخاص بنا لـ EOS ؛ كيف خططوا لطرده منشئ الرموز المميزة مثل ERC721 ودعم الوظائف الثابتة ؛ كيف قاموا بتقديم بروتوكول Merkle Root ACL. لكن كل هذا لا يتناسب مع المقالة ، لذلك سنعود إلى مشروعنا الرئيسي.

1. التحضير

1.1. إنترنت الأشياء

تحضير جزء إنترنت الأشياء من المشروع هو اختيار الأجهزة المناسبة. في دور قارئ RFID ، تم اختيار RC522 التي تعمل على ناقل SPI: فهي شائعة وسهلة الاستخدام.

عند البحث عن عداد ، ركزنا على وجود خرج النبض ، لأنه يسمح لك بقراءة البيانات ببساطة شديدة: نبضة واحدة هي X kW⋅h (حيث يعتمد X على النموذج) ، ونتيجة لذلك ، توقفنا عند عداد Mercury 201.5.

كان أصعب شيء هو اتخاذ قرار بشأن وحدة التحكم ، التي يجب أن تجمع البيانات من أجهزة الاستشعار ، وتشكل معاملة ، وتوقعها بمفتاحك الخاص وترسلها إلى الشبكة. وفقًا لذلك ، كنا بحاجة إلى جهاز يحتوي على وحدة شبكة يمكن أن توقع معاملة باستخدام ECDSA (في هذه الحالة ، على المنحنى البيضاوي secp256k1 ، حيث يتم استخدامه في EOS للتوقيع).

في البداية ، وقع الاختيار على وحدة التحكم الدقيقة ESP8266 ، ولديه وحدة Wi-Fi وجميع الواجهات اللازمة لتوصيل أجهزة الاستشعار الخاصة بنا. في نفس الوقت ، إنه مضغوط للغاية. ولكن لا يوجد لدى أي من البرامج الثابتة تنفيذ محلي للبدائل الإهليلجية. من الممكن كتابة التنفيذ الخاص بك ، ولكن هذه ليست مهمة hackathon. ونتيجة لذلك ، تم اختيار Raspberry Pi 3 B للنموذج الأولي ، وتم استخدام مكتبة eosjs لإنشاء المعاملات وتوقيعها.

1.2. البنية التحتية

قبل يومين من هاكاثون ، قمنا بإعداد محليًا وعلى خادم eos-hackathon.smartz.io تجميع EOS ( المصدر ). ذهب تركيب التبعية والتجميع والاختبارات بسلاسة مفاجئة لمثل هذا المشروع الصغير (باستخدام الوثائق ). لم يكن هناك وقت كافٍ لإعداد البنية التحتية الأخرى ، وكان عليّ التعامل معها بالفعل خلال أحداث الهاكاثون.

1.3. العمارة

عشية هاكاثون ، ناقشنا الهندسة المعمارية وتوضيح تفاصيل المنتج. سنقوم بتنفيذ الحالات الرئيسية التالية: مدفوعات الكهرباء ودفع المشتريات التي تحمل علامات RFID. كما خططوا لجعل المنتج قابلاً للتوسيع بسهولة واستخدامه في مناطق أخرى.

فكرة الهندسة المعمارية هي أن مقدم الخدمة (المنتج) يبتكر عقدًا واحدًا - نقطة التفاعل المركزية بين المورد والمستهلكين. لكل مستهلك رصيده الخاص ، والذي يمكن تجديده ، يتم خصم الأموال منه بناءً على إشارات المستشعر. يتم تخزين جميع البيانات - المستخدمون وأجهزة الاستشعار والإحصاءات - في عقد المورد.

ترتبط تفضيلات المستخدم مع المستهلك ، أو العلامات (على سبيل المثال ، فئة مستخدم تفضيلية) - user_meta . يمكن توصيل العديد من أجهزة الاستشعار بالمستهلك ، لكل منها إعدادات العقد وإعداد الفواتير ( billing_meta ). حتى تتمكن من الحصول على عقد فوترة غير قابل للتغيير ، يستخدم لعدد كبير من المستهلكين ؛ ستظهر البيانات اللازمة أثناء استدعاء طريقة bill(payload, user_meta, billing_meta) . أيضًا ، تم وضع إمكانية منطق مختلف للفوترة ، أي عقود مختلفة: على سبيل المثال ، يعتبر أحدهما الكهرباء ، والآخر - السلع. يحتوي كل مستشعر على "مؤشر" لعقد الفوترة الخاص به.

من المفترض أن يثق المستهلك في الشركة المصنعة لأجهزة الاستشعار ، ولكنه لا يثق بالضرورة في مقدم الخدمة. إن واجهة التفاعل مع المستشعر بسيطة للغاية: إنها استدعاء لطريقة عقد المورد مع معلمة رقمية ، والتي سيتم نقلها إلى الفواتير. يبدأ مقدم الخدمة المستهلكين ، وأجهزة الاستشعار ، وعقود الفوترة وعلاقاتهم في عقودهم ، باستخدام معاملات التحكم - المستوطنون البدائيون. عند استلام المعاملة من المستشعر ، يتم فحص البيانات ، ويتم إنشاء بيانات الفوترة ، وتسمى الفواتير ، ويتم تسجيل الدفع وتسجيل الإحصائيات.

ولعل أكثر من كل شيء ناقشنا القضايا التالية التي تعتبر مهمة لتطبيق المنتج في العالم الحقيقي:

• الدفعة الأولى أو الدفع المؤخّر؟ أعد تعبئة حسابك واستخدمه (مثل الاتصال الخلوي) - أو استخدمه ، ثم سدد ثمنه (مثل AWS)؟ لا توجد إجابة صحيحة أو خاطئة هنا: تفضل الشركات المختلفة نماذج مختلفة. من أجل البساطة ، قررنا أن نستلم الدفعات المسبقة.
• هل يجب على المستخدم الاحتفاظ بحساب منفصل لكل مورد ، أم أن جميع الرسوم تأتي من حساب واحد؟ مرة أخرى - لا يوجد قرار صحيح وخاطئ ؛ بالإضافة إلى ذلك ، يرتبط الجواب بشكل وثيق بالإجابة على السؤال السابق. المدفوعات المسبقة هي أصدقاء جيدين مع حسابات المستهلكين الفردية - تم أخذها.
• هل تفرض رسومًا في EOS ، أو رمزًا لمقدم الخدمة أو عملة مستقرة (مرتبطة بالعملة الورقية)؟ خيارات أخرى غير العملة المستقرة ، بالطبع ، غير ملائمة للمستهلك بسبب التقلب ، والعملة المستقرة في إطار EOS غير موجودة بعد. في ذلك الوقت ، حتى شبكة EOS الرئيسية لم تكن موجودة! من أجل البساطة ، أخذوا رمزًا مشروطًا.

2. الترميز

أولاً ، حددوا واجهة برمجة التطبيقات وإطار عقد المورد من أجل البدء في تطوير الواجهة الأمامية ورمز الجهاز والفوترة والعقد الرئيسي ( المصدر ) في نفس الوقت.

2.1. إنترنت الأشياء

أول تطبيق لرمز قراءة البقول من العداد. للعمل مع GPIO (دبابيس للأغراض العامة) ، تم استخدام مكتبة onoff JS. في وقت لاحق ، تمت إضافة مصباحين LED إلى الدائرة للتوضيح: الأول يومض عند تلقي إشارة من العداد ، والثاني عندما تأتي إجابة حول معاملة ناجحة من عقدة EOS. وبالمثل ، قمنا بتطوير مخطط ورمز لقراءة علامات RFID ، مع الاختلاف الوحيد: تمت القراءة في ناقل SPI باستخدام مكتبة MFRC522-python. كما اتضح ، فإن إعداد SPI لـ Raspberry Pi 3 يختلف عن الإعداد في نماذج اللوحة السابقة ؛ ساعدتنا هذه التعليمات على الفهم.

تم تشغيل الأجهزة من بنك الطاقة ، والذي تم تقديمه بنجاح إلى جميع المشاركين في الهاكاثون ، وكان عليهم مشاركة الإنترنت بأنفسهم مع iPhone 5 ، نظرًا لأن Wi-Fi الخاص بالهاكاثون كان يعمل حصريًا بسرعة 5 غيغاهرتز ، وهذا لم يعمل مع Raspberry Pi.

2.2. البنية التحتية والمرافق

نصح المنظمون بأخذ صورة عامل إرساء eos-dev ، لكننا شعرنا بالارتباك بسبب نقص وصف وتوثيق الصورة. على الخادم ، استمروا في العمل مع التجميع المحضر ، وعلى الصعيد المحلي ، لتجنب تثبيت EOS بشكل منهجي ، استخدموا eos-dev.

على الفور الحاجة إلى القدرة على البناء والاختبار بسرعة. مثالي: إنشاء ملف قابل للتنفيذ محليًا وتشغيله. ومع ذلك ، كان من المستحيل تجاهل حقيقة أنه بعد التجميع ، تطلب الإخراج WebAssembly ، وفي بيئة EOS ، مع التحسين المقابل ، والمكتبات ، وعقود النظام. يمكن التجسس على خيارات التجميع الضرورية في eosiocpp.in ، ومع ذلك ، قررنا عدم لعب هذه اللعبة. النتيجة المتوقعة ، وإن كانت أبطأ قليلاً ، هي أكثر أهمية من الحل السريع مع أشعل النار. لذلك ، بالنسبة للتجميع ، أخذنا eoscpp ، الموجود في حاوية eos-dev.

اتضح أن الأمر أكثر صعوبة مع الإطلاق ، وكان عليّ رفع سلسلة بلوكشين EOS المحلية ، ومرة ​​أخرى لم يكن هناك حل جاهز. فقط البرامج. لذا ظهرت النسخة الأولى من البنية التحتية للإطلاق. تكمن الفكرة في إخفاء الفروق الدقيقة في التركيب والتكوين والحصول على مجموعة متسقة ذاتيًا من أربعة إلى خمسة "أزرار" للإجراءات النموذجية. تحكم أقل ، ولكن فرصة أقل للخطأ ، بالإضافة إلى توفير الوقت.

المكونات الرئيسية لـ EOS تشمل العقدة ، و keosd daemons ، وأداة وحدة التحكم cleos ، ومترجم eoscpp:

• nodeos - عقدة EOS ، daemon - مشارك شبكة ، توفر الوصول إلى blockchain وتنتج كتل جديدة اختياريًا ؛
• keosd - برنامج لإدارة المحافظ المحلية التي تخزن أزواج المفاتيح ؛
• يوفر cleos أوامر من الحصول على معلومات حول المعاملات للعمل مع المفاتيح ؛ يتم تنفيذه بناءً على المكالمات في العقدة و keosd عبر HTTP API ؛
• تقوم eoscpp بتجميع العقود في WebAssembly ، كما تتيح لك الحصول على واجهة التطبيق الثنائية بناءً على شفرة المصدر.

أصبح من الواضح على الفور أن أوامر cleos المتعلقة بمكالمات keosd لم تنجح. نظرًا لإصدار خطأ يشير إلى عدم إمكانية الوصول إلى شبكة keosd ، أمضينا وقتًا في تشخيص مشكلات الشبكة في شبكة عامل الميناء. ومع ذلك ، أظهر strace أنه لم يكن هو الشبكة: فقد دخل cleos إلى العنوان الخطأ ، دائمًا إلى المضيف المحلي (وفي حالة البنية التحتية لدينا ، فإن الشياطين المختلفة لديهم عناوين شبكة مختلفة في شبكة عامل ميناء منفصلة). تم تشخيص خطأ في cleos: التحقق من توفر keosd ، الذي يتم تنفيذه قبل أي أمر متعلق بالمحافظ ، يأخذ في الاعتبار المنفذ الذي تم تمريره في الوسيطات ، ولكن لا يأخذ في الاعتبار العنوان. تحت الهاكاثون ، قمنا بالتبديل إلى الشبكة المضيفة في الرصيف كحل بديل.

كانت الخطوة التالية هي أداة تجميع العقد باستخدام المحول البرمجي في الحاوية ( الالتزام ). تم تركيب أدلة المدخلات والمخرجات. وأخيرًا ، القدرة على تحميل عقد إلى blockchain وإرسال المعاملات ( الالتزام ). مرة أخرى - المرافق بأسلوب ثابت ، "أزرار" بسيطة. هذا أنهى البنية التحتية الأساسية ، لكن المفاجآت استمرت: تعثرنا في مشكلة وظائف C للعمل مع الذاكرة (بمزيد من التفاصيل أدناه).

في الختام ، بدأوا في إعداد حسابات في ملف واحد (يتطلب كل عقد ومشارك حسابات منفصلة) مباشرة مع أزواج المفاتيح التي يتم إنشاؤها تلقائيًا عند بدء تشغيل blockchain ، بحيث يمكن لفريق واحد رفع بيئة الاختبار. تم نشر نسخة واحدة من هذه البيئة إلى eos-hackathon.smartz.io.

2.3. العقود الذكية

2.3.1. عقد المورد وفواتير الكهرباء

بعد بدء هاكاثون ، بدأنا في وضع هيكل العقود وفقًا للمخطط أعلاه. يتكون النظام من العقود التالية:

• عقد supplier - supplier ؛
• billing_electricity - عقد لحساب دفع الكهرباء لكل علامة من أجهزة القياس.

في عقد supplier ، يتم تنفيذ معظم العمل من خلال عمليات CRUD العادية: إضافة المستخدمين ، والتعريفات الجمركية ، والعدادات ، وزيادة أو تقليل رصيد المستخدم. كانت الطرق الأكثر تعقيدًا مسؤولة عن تلقي البيانات من العداد ، واستدعاء عقد لحساب الدفع (الفوترة) ، وخصم حساب المستخدم الشخصي بعد الاستدعاء من عقد الفوترة. تم تحديد عقد الفوترة اللازم بناءً على تعرفة المستخدم.

بعد المكالمة في عقد الفوترة ، تم حساب الدفعة وطُرحت الطريقة لخصم الدفعة من حساب المستخدم الشخصي. بعد إلقاء المنطق الرئيسي ، فكرنا حتى إذا كنا نقوم بعقود بسيطة للغاية. بعد ذلك بقليل ، بعد نشر العقود في العقدة واختبارها ، أصبح من الواضح أن العقود قد تكون بسيطة ، ولكن هناك فروق دقيقة. :)

بعد النشر ، اتضح أن مكالمات العقد المتوقعة من بعضها البعض لم تنجح. حقوق غير كافية. على عكس العقود الذكية في Ethereum ، حيث يتم استدعاء العقد من العقد نيابة عن العقد طالب ، في EOS ، تبدأ السلسلة بأكملها مع بادئ المعاملة. عندما يتم استدعاء العقد من العقد ، يتم التحقق مما إذا كان البادئ قد سمح للعقد بالقيام بذلك.

اقترح الموجهون على الفور كيفية التصرف في حالة بسيطة. تتم إضافة الحقوق على النحو التالي (عبر الاتصال بالعقد الذكي لنظام eosio):

 ./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 باستدعاء عقود أخرى نيابة عنه. يمكنك قراءة المزيد عن الحقوق في Technical 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 وبدأنا بالفعل في التفكير في خيارات بديلة ، دون سلسلة من المكالمات. لقد منع بشكل جميل أن آلية استدعاء العقود الأخرى في EOS تختلف أيضًا عن الأثير. عند استدعاء عقد آخر ، يتم وضع هذه المكالمة في قائمة الانتظار ولن تكتمل إلا بعد اكتمال المكالمة الحالية. لن يعمل لاستدعاء العقد وبعد المكالمة لقراءة البيانات المسجلة بواسطة هذا العقد.

في وقت لاحق ، بعد كل شيء ، وجدوا في كود EOS سبب الخطأ عند تحديد حقوق عقدين. اتضح أن الحسابات في قائمة الحقوق يجب أن يتم فرزها حسب الحساب: تأكد من أن جميع المفاتيح فريدة ومرتبة وأن جميع أذونات الحساب فريدة ومرتبة ( Authority.hpp ). بعد تغيير ترتيب الحسابات ، نجح تحديث الحقوق - وبدأ نظام العقود لدينا في العمل.

2.3.2. مشكلة وظائف C مع الذاكرة

من السخف أن نقول ، ولكن في النهاية لم نتمكن من استخدام الوظائف الجاهزة لتحليل الأرقام (!) لقراءة تكوين الفواتير. بعد std::istringstream تم سحب الدالة std::istringstream لأعلى ، وهو أمر غريب نوعًا ما. وعند استخدام atof وما شابه ، وكذلك sscanf - env.realloc تشديد env.realloc . لسبب ما ، لم يتم العثور على الوظائف المذكورة للعمل مع ذاكرة مكتبة C القياسية أثناء تحميل التعليمات البرمجية في العقدة. تعمل وظائف C ++ مع الذاكرة.

بالطبع ، عند تنفيذ عقد WebAssembly ، لا يتم استخدام مخصص ذاكرة قياسي ، ولكن يتم توفير وضع الحماية الخاص به ، والذي يتم توفيره لكل معاملة في ظل ظروف معينة. أيضًا ، تم تنفيذ دعم وظائف C للعمل مع الذاكرة أعلى صندوق الحماية هذا لفترة طويلة ، ويتم تنفيذها في عقود EOS القياسية . ربما حدث خطأ ما في مرحلة الربط.

بعد قضاء حوالي ساعة في البحث عن مخرج ، بما في ذلك بمساعدة أحد الموجهين ، قررنا عدم المتابعة وإجراء حل بديل: اكتب الكود الخاص بنا الذي يحل مشكلة تحليل الأرقام. لم تكن آلية DATastream EOS مناسبة لنا: فقد تطلبت القدرة على حفظ حزم البيانات للهياكل المختلفة في مجال واحد وتشكيلها يدويًا (تكوينات الفوترة نفسها).

2.3.3. فواتير التسوق

في الريح الثانية ، التي افتتحها إما مهندسو الكهرباء أو عن طريق الإفطار المبكر ، كتبوا فواتير للتسوق في المتجر. المخطط العام للعمل هو كما يلي:

1. يُنشئ المورد عقد إعداد الفواتير ويصفه في عقده العام.
2. في منفذ المتجر ، يضع المورد أطرًا يمكنها قراءة RFID والتفاعل مع EOS ولها حسابات خاصة بها منصوص عليها في عقد الفوترة.
3. تم تجهيز كل منتج في المتجر بعلامة RFID ، ويتم تسجيل جميع العلامات في عقد الفوترة.
4. يدفع المشتري ثمن البضائع عن طريق مسح RFID الخاص به ، ويتم إزالة البضائع من عقد إعداد الفواتير.
5. عند الخروج من المتجر ، تقرأ الإطارات أيضًا مشتريات RFID. إذا كانت البضاعة لا تزال في المتجر ، لا تمر المعاملة ، ويجب أن يصدر الإطار إنذارًا (نعم ، في الواقع ، لا يمكنك حتى إرسال المعاملة ، ولكن فقط قراءة الجدول).

لا معنى للتركيز على رمز العقد نفسه: هذا هو معيار C ++ 14 مع بعض الإنشاءات والمكتبات الخاصة بـ EOS. قال بشكل أفضل في EOSIO Wiki و EOSIO Developer Portal .

2.3.4. الواجهة الأمامية

تم تنفيذ الجزء الأمامي من المشروع باستخدام React. بدلاً من المعتاد ، قرر العديد من Redux استخدام MobX ، مما يسرع بشكل كبير من التطوير ويسمح لك بإدارة الحالة العالمية دون صداع.

لم تسير مرحلة دمج blockchain الأمامية بسلاسة كما هو متوقع. يتم الانتهاء من حزمة eosjs بنشاط شديد ، تليها محفظة EOS لمتصفح Scatter . في هذه المجموعة ، غالبًا ما يسبب هذا مشاكل. وليس حقيقة أن الشفرة التي عملت بالأمس ستعمل بشكل جيد اليوم. داسنا على هذا أشعل النار (وليس المرة الأولى). ساعة من المحاولة والتصحيح في حالة نعاس - تم حل المشكلة.

ضع في اعتبارك مخططًا مبسطًا لتفاعل جانب العميل من التطبيق مع eos. للقيام بذلك ، تحتاج إلى مكتبة eosjs وملحق متصفح Scatter.

نذكرك! يتم تحديث مبعثر بنشاط بعد eosjs ، لا تنس تحديث المكتبة.

بعد ذلك ، نظرة سريعة على القراءة والكتابة. هناك طريقتان للتواصل مع العقود الذكية في EOS: إرسال المعاملات (يؤدي إلى تعديل blockchain ، مع عدم توفير قيم الإرجاع) وجداول القراءة (إجراء للقراءة فقط).

خذ بعين الاعتبار رمز إرسال المعاملة:

  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 }); }); }); } 

وسيطات الإدخال: اسم الوظيفة والكائن ، وقيمها هي وسيطات لهذه الدالة. الخط الثالث: نؤكد على الشبكة التي نتفاعل من خلالها مع EOS. السطر الرابع: نحصل على identity ، المعلمة هي كائن بحقل accounts (لهذه الشبكة). تُرجع الدالة getAccountName الحساب الأول من قائمة الحسابات المستلمة (في كائن identity ).

في هذا المثال ، يتم استخدام Scatter لتوقيع معاملة. مبعثر هو التفاف على مثيل لفئة Eos . في السطر 9 ، نسمي طريقة eos ، معلماتها:

1. this.network - كائن بمعلمات الشبكة.
2. Eos هو مثال على eosjs.
3. this.configEosInstance - كائن بمعلمات لمثيل Eos (انظر dock eosjs).

تقبل طريقة transaction الأخيرة accountName callback كمدخل ، تكون وسيطة callback هي عقد موجود في account accountName . في callback 'e ، نسمي طريقة العقد المستلم مع الكائن ، ومفاتيحه هي وسيطات الطريقة المطلوبة.

فكر في طريقة قراءة الجداول:

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

هنا للقراءة نحتاج فقط إلى مثيل eos .

لتصميم الواجهة ، أسقطنا Materialize و Semantic و Ant ، وجلدنا أنفسنا. في الساعات الأخيرة من الهاكاثون ، ظهرت فكرة لإحياء واجهة المستخدم ، وإضافة تصور للعملية. أبرزت الصفوف الجديدة للجدول لمدة ثانيتين باللون الأخضر وحصلت على تأثير رائع في أسعار الأسهم. زاد التحسن بشكل كبير من جاذبية المشروع وأصبح المرحلة النهائية من بناء واجهة المستخدم.

3. الجمعية

قبل ثلاث ساعات من نهاية الوقت ، كان لدينا Raspberry Pi مع عداد كهرباء Mercury وقارئ RFID متصل به ، بالإضافة إلى إشارة ضوئية. كل كهرباء المائدة مرت عبر عطارد. مقابل كل 0.3125 واط / ساعة يتم إنفاقه ، وكذلك لكل عملية "شراء" ، أرسل Raspberry Pi المعاملات إلى سلسلة الكتل لدينا ، ويمكن لمزود الخدمة إدارة المستخدمين وأجهزة الاستشعار والفواتير والاطلاع على إحصاءات الاستهلاك.

لمدة ساعة أخرى ، انخرطنا بهدوء في الشيكات وأضفنا اللمسات الأخيرة. قبل ساعتين من نهاية الوقت ، تلقينا منتجًا كاملاً مع حالتين تم تنفيذهما ، يوضحان المفهوم بشكل كامل ، وحتى لم يتم الالتزام في الدقائق الأخيرة!

4. مظاهرة

تتألف العروض التوضيحية للمشروعات (المعروفة أيضًا باسم الملاعب) من مرحلتين. في المرحلة الأولى ، تم تقسيم 69 فريقًا مشاركًا إلى أربع مجموعات ، تم إطعام كل منهم بشكل منفصل أمام قاضيين وبدون متفرجين. أعطى الحكام علامات (أربعة معايير لكل منها 5 نقاط) ، وبناءً على هذه العلامات ، تم اختيار أفضل 10 فرق للمرحلة الثانية. أعطيت هذه الفرق الفرصة لتنظيم مشروع على خشبة المسرح الكبيرة أمام الجمهور وجميع القضاة الثمانية.

انتهى بنا الأمر في المجموعة الأولى ، وكان قضانا هم الرئيس التنفيذي والرئيس (أتساءل كيف تختلف هذه المواقف) من Everipedia. تم تخصيص ثلاث دقائق للأداء ، وتمت مراقبتها بدقة بواسطة جهاز ضبط الوقت. لقد أنهينا عملنا غير المتسق ، ولكننا استدعينا لإعجاب الكلام قبل 30 ثانية من الموعد المحدد. سأل القضاة شيئًا سطحيًا وقريبًا إلى حد ما ، وانتهت المظاهرة.

لقد فوجئنا نحن ، السذج ، بأننا لم ننتبه إلى قدرة العمل الحقيقية للمنتج ، وأكثر من ذلك إلى قانون القاضي. قضايا التنفيذ الفني لم تهمهم حتى في أدنى درجة. يمكننا أيضًا عرض مصابيح Raspberry Pi الوامضة والصورة في الأمام.

كان هناك شعور بأننا فشلنا في تقديم المشروع ، لأننا توقعنا أن نثير إعجابنا بالحل الفعلي ، ونموذج أولي ، وليس مجرد وصف ملون لمشروع مهم وطموح اجتماعيًا. تم لعب كل شيء كما لو كان بالملاحظات: وصفنا المشكلة ، والألم ، وحلنا ، وأظهرنا كيف يعمل ، ووصفنا خطط تطوير المشروع. بمعرفة مسبقة عن طرق التحكيم ، كنا سنفعل الكثير بشكل مختلف.

خفض الحكام من الجداول الأربعة في الجولة الأولى نتائجهم وتبادلوا وجهات النظر بعد 15 دقيقة من نهاية الرميات. بعد أن بدأ الإعلان عن الفائزين. ساد جو عصبي في القاعة: متعبًا بعد ماراثون 26 ساعة ، أراد الناس الفوز ، كان هناك العديد من الفرق القوية ، وكانوا يعلمون أنه يمكنهم المطالبة بالنصر. وكنا نعلم ذلك - وانتظرنا النتائج.

ولمنع المشاهدين من الاسترخاء ، تم الإعلان عن النتائج في ثلاثة أجزاء. أول أربعة متسابقين ، ثم ثلاثة آخرين ، ثم ثلاثة آخرين. بين الإعلانات وفي النهاية - العروض. لم ندخل في المراكز العشرة الأولى ولم تتح لنا الفرصة لدخول المرحلة الكبيرة. وصل فريقان ناطقان بالروسية إلى المراكز العشرة الأولى ، وأصبح أحدهما في النهاية الثالث. مبروك للفائزين ، إنهم يستحقون جوائزهم.

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)