تطوير برنامج لتأجير السكوتر اللامركزي. ومن قال أنه سيكون من السهل؟

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

كيف بدأ كل شيء

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

أعجب أصحاب المصلحة لدينا بهذه الفكرة حقًا، وقرروا تحويلها إلى نموذج أولي للعرض في المعارض. بعد العديد من العروض التوضيحية الناجحة في Mobile World Conference وBosch Connected World في عام 2019، تقرر اختبار تأجير السكوتر مع مستخدمين حقيقيين، وموظفي Deutsche Telekom. لذلك بدأنا في تطوير MVP متكامل.

Blockchain على العكازات

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

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

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

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

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

كل هذا يقودنا إلى هذه العمارة. موافق، الأمر مختلف تمامًا عما خططنا له.

الآس في الحفرة: هوية السيادة الذاتية

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

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

الجهاز سبب لي مشاكل

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

تحد مجموعة التكنولوجيا هذه بشكل كبير من اختيارنا للأجهزة المدمجة في السكوتر. لحسن الحظ، في بداية المشروع، اخترنا Raspberry Pi Zero، واستفدنا من جميع مزايا الكمبيوتر الصغير المتكامل. هذا سمح لنا بتشغيل Node.js الضخم على السكوتر. بالإضافة إلى ذلك، حصلنا على المراقبة والوصول عن بعد عبر VPN باستخدام أدوات جاهزة.

في الختام

ورغم كل "الألم" والمشاكل، انطلق المشروع. لم يعمل كل شيء كما خططنا، ولكن كان من الممكن حقًا ركوب الدراجات البخارية عن طريق استئجارها.

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

المصدر: www.habr.com