توسعه نرم افزار برای اجاره اسکوتر غیرمتمرکز. کی گفته راحت میشه؟

در این مقاله در مورد اینکه چگونه سعی کردیم اجاره اسکوتر غیرمتمرکز را بر اساس قراردادهای هوشمند بسازیم و چرا هنوز به یک سرویس متمرکز نیاز داشتیم صحبت خواهم کرد.

توسعه نرم افزار برای اجاره اسکوتر غیرمتمرکز. کی گفته راحت میشه؟

همه اینا چطور شروع شد

در نوامبر 2018، ما در یک هکاتون اختصاص داده شده به اینترنت اشیا و بلاک چین شرکت کردیم. تیم ما اشتراک اسکوتر را به عنوان یک ایده انتخاب کرد زیرا ما یک اسکوتر از حامی این هکاتون داشتیم. نمونه اولیه شبیه یک برنامه تلفن همراه بود که به شما امکان می دهد یک اسکوتر را از طریق NFC راه اندازی کنید. از نقطه نظر بازاریابی، این ایده توسط داستانی در مورد "آینده ای روشن" با یک اکوسیستم باز پشتیبانی می شود که در آن هر کسی می تواند مستاجر یا صاحبخانه شود، همه بر اساس قراردادهای هوشمند.

ذینفعان ما واقعاً این ایده را دوست داشتند و تصمیم گرفتند آن را به یک نمونه اولیه برای نمایش در نمایشگاه ها تبدیل کنند. پس از چندین نمایش موفق در کنگره جهانی موبایل و Bosch Connected World در سال 2019، تصمیم گرفته شد تا اجاره اسکوتر را با کاربران واقعی، کارمندان Deutsche Telekom آزمایش کنیم. بنابراین ما شروع به توسعه یک MVP تمام عیار کردیم.

بلاک چین روی عصا

فکر نمی کنم ارزش توضیح دادن داشته باشد که تفاوت بین پروژه ای که قرار است روی صحنه نمایش داده شود و پروژه ای که توسط افراد واقعی استفاده می شود چیست. ظرف شش ماه باید نمونه اولیه نفت خام را به چیزی مناسب برای یک خلبان تبدیل می‌کردیم. و بعد فهمیدیم "درد" یعنی چه.

برای اینکه سیستم خود را غیرمتمرکز و باز کنیم، تصمیم گرفتیم از قراردادهای هوشمند اتریوم استفاده کنیم. این پلتفرم خدمات آنلاین غیرمتمرکز به دلیل محبوبیت و توانایی ساخت یک برنامه بدون سرور، انتخاب شد. ما برای اجرای پروژه خود به شرح زیر برنامه ریزی کردیم.

توسعه نرم افزار برای اجاره اسکوتر غیرمتمرکز. کی گفته راحت میشه؟

اما متاسفانه قرارداد هوشمند کدی است که در زمان تراکنش توسط ماشین مجازی اجرا می شود و نمی تواند جایگزین یک سرور کامل شود. به عنوان مثال، یک قرارداد هوشمند نمی تواند اقدامات معلق یا برنامه ریزی شده را انجام دهد. در پروژه ما، این به ما اجازه نمی داد که خدمات اجاره در دقیقه را اجرا کنیم، همانطور که اکثر سرویس های مدرن به اشتراک گذاری خودرو انجام می دهند. بنابراین، بدون اینکه مطمئن باشیم که او پول کافی دارد، پس از تکمیل تراکنش، ارز رمزنگاری شده را از او برداشت کردیم. این رویکرد فقط برای یک پایلوت داخلی قابل قبول است و البته مشکلاتی را در هنگام طراحی یک پروژه تولیدی تمام عیار اضافه می کند.

به همه موارد فوق، رطوبت خود پلت فرم اضافه شده است. به عنوان مثال، اگر یک قرارداد هوشمند با منطق متفاوت از توکن های ERC-20 بنویسید، با مشکلات رسیدگی به خطا مواجه خواهید شد. معمولاً اگر ورودی نادرست باشد یا روش های ما به درستی کار نکند، در پاسخ کد خطا دریافت می کنیم. در مورد اتریوم، ما نمی توانیم چیزی غیر از مقدار گازی که برای انجام این عملکرد صرف می شود، دریافت کنیم. گاز ارزی است که برای تراکنش ها و محاسبات باید پرداخت شود: هر چه تعداد عملیات در کد شما بیشتر باشد، بیشتر پرداخت خواهید کرد. بنابراین برای درک اینکه چرا کد کار نمی کند، ابتدا آن را با شبیه سازی تمام خطاهای احتمالی آزمایش کنید و گاز مصرف شده را به عنوان یک کد خطا کدگذاری کنید. اما اگر کد خود را تغییر دهید، این مدیریت خطا خراب می شود.

علاوه بر این، تقریباً غیرممکن است که یک برنامه موبایلی ایجاد کنید که صادقانه با بلاک چین کار کند، بدون استفاده از کلید ذخیره شده در جایی در ابر. اگرچه کیف پول های صادقانه وجود دارند، اما رابطی برای امضای تراکنش های خارجی فراهم نمی کنند. این بدان معنی است که شما یک برنامه بومی را نخواهید دید مگر اینکه کیف پول رمزنگاری داخلی داشته باشد، که کاربران به آن اعتماد کمی خواهند داشت (من به آن اعتماد ندارم). در نتیجه ما هم مجبور شدیم گوشه ای را اینجا کوتاه کنیم. قراردادهای هوشمند به شبکه خصوصی اتریوم تحویل داده شد و کیف پول مبتنی بر ابر بود. اما با وجود این، کاربران ما تمام «لذت‌های» خدمات غیرمتمرکز را در قالب انتظار طولانی برای تراکنش‌ها چندین بار در هر جلسه اجاره تجربه کردند.

همه اینها ما را به این معماری سوق می دهد. موافقم، با آنچه ما برنامه ریزی کرده بودیم بسیار متفاوت است.

توسعه نرم افزار برای اجاره اسکوتر غیرمتمرکز. کی گفته راحت میشه؟

آس در سوراخ: هویت خودمختار

شما نمی توانید یک سیستم کاملاً غیرمتمرکز بدون هویت غیرمتمرکز بسازید. هویت خودمختار (SSI) مسئولیت این بخش را بر عهده دارد که ماهیت آن این است که شما ارائه‌دهنده هویت متمرکز (IDP) را بیرون می‌اندازید و تمام داده‌ها و مسئولیت آن را بین مردم توزیع می‌کنید. حالا کاربر تصمیم می گیرد به چه داده هایی نیاز دارد و با چه کسانی به اشتراک بگذارد. تمام این اطلاعات در دستگاه کاربر قرار دارد. اما برای تبادل به یک سیستم غیرمتمرکز برای ذخیره شواهد رمزنگاری نیاز داریم. تمام پیاده سازی های مدرن مفهوم SSI از زنجیره بلوکی به عنوان ذخیره سازی استفاده می کنند.

"این چه ربطی به آس در سوراخ دارد؟" - تو پرسیدی. ما خدمات آزمایش داخلی را روی کارمندان خود در برلین و بن راه اندازی کردیم و در قالب اتحادیه های کارگری آلمان با مشکلاتی مواجه شدیم. در آلمان، شرکت ها از نظارت بر جابجایی کارمندان منع شده اند و اتحادیه های کارگری این موضوع را کنترل می کنند. این محدودیت‌ها به ذخیره‌سازی متمرکز داده‌های هویت کاربر پایان می‌دهد، زیرا در این صورت مکان کارمندان را می‌دانیم. در عین حال، به دلیل احتمال دزدیده شدن اسکوترها، نمی‌توانستیم آنها را بررسی نکنیم. اما به لطف Self-Sovereign Identity، کاربران ما به صورت ناشناس از سیستم استفاده کردند و خود اسکوتر گواهینامه رانندگی آنها را قبل از شروع اجاره بررسی کرد. در نتیجه، معیارهای کاربر ناشناس را ذخیره کردیم؛ هیچ سند یا داده شخصی نداشتیم: همه آنها در دستگاه های خود درایورها موجود بودند. بنابراین، به لطف SSI، راه حل مشکل در پروژه ما حتی قبل از ظاهر شدن آماده بود.

دستگاه به من مشکل داد

ما خودمان Self-Sovereign Identity را پیاده سازی نکردیم، زیرا نیاز به تخصص در رمزنگاری و زمان زیادی دارد. در عوض، ما از محصول شرکای خود Jolocom استفاده کردیم و کیف پول موبایل و خدمات آنها را در پلتفرم خود ادغام کردیم. متأسفانه، این محصول یک اشکال قابل توجه دارد: زبان اصلی توسعه Node.js است.

این پشته فناوری انتخاب سخت افزاری را که در یک اسکوتر تعبیه شده است بسیار محدود می کند. خوشبختانه در همان ابتدای پروژه، Raspberry Pi Zero را انتخاب کردیم و از تمام مزایای یک میکروکامپیوتر تمام عیار بهره بردیم. این به ما اجازه داد تا Node.js بزرگ را روی اسکوتر اجرا کنیم. علاوه بر این، ما نظارت و دسترسی از راه دور را از طریق VPN با استفاده از ابزارهای آماده دریافت کردیم.

در نتیجه

با وجود همه "درد" و مشکلات، این پروژه راه اندازی شد. همه چیز آنطور که ما برنامه ریزی کرده بودیم کار نکرد، اما واقعاً می شد اسکوتر را با کرایه سوار کرد.

بله، ما در طراحی معماری چندین اشتباه مرتکب شدیم که به ما اجازه نداد سرویس را کاملاً غیرمتمرکز کنیم، اما حتی بدون این اشتباهات به سختی می‌توانستیم یک پلتفرم بدون سرور ایجاد کنیم. نوشتن یک هرم رمزنگاری دیگر یک چیز است، و نوشتن یک سرویس کامل که در آن باید خطاها را مدیریت کنید، موارد مرزی را حل کنید و وظایف معلق را انجام دهید کاملاً چیز دیگری است. بیایید امیدوار باشیم که پلتفرم های جدیدی که اخیراً ظهور کرده اند، انعطاف پذیرتر و کاربردی تر باشند.

منبع: www.habr.com

اضافه کردن نظر