פיתוח תוכנה להשכרת קטנועים מבוזרת. מי אמר שזה יהיה קל?

במאמר זה אדבר על איך ניסינו לבנות השכרת קטנועים מבוזרת על חוזים חכמים ולמה בכל זאת היינו צריכים שירות מרוכז.

איך הכל התחיל

בנובמבר 2018, השתתפנו בהאקתון המוקדש לאינטרנט של הדברים ובלוקצ'יין. הצוות שלנו בחר בשיתוף קטנועים כרעיון מכיוון שהיה לנו קטנוע מהספונסר של ההאקתון הזה. אב הטיפוס נראה כמו אפליקציה סלולרית המאפשרת להפעיל קטנוע דרך NFC. מנקודת מבט שיווקית, הרעיון נתמך בסיפור על "עתיד מזהיר" עם מערכת אקולוגית פתוחה שבה כל אחד יכול להפוך לשוכר או לבעל בית, הכל על בסיס חוזים חכמים.

בעלי העניין שלנו מאוד אהבו את הרעיון הזה, והם החליטו להפוך אותו לאב טיפוס לתצוגה בתערוכות. לאחר מספר הפגנות מוצלחות ב-Mobile World Congress וב-Bosch Connected World בשנת 2019, הוחלט לבדוק את השכרת הקטנוע עם משתמשים אמיתיים, עובדי דויטשה טלקום. אז התחלנו לפתח MVP מן המניין.

בלוקצ'יין על קביים

אני לא חושב שכדאי להסביר מה ההבדל בין פרויקט שיוצג על הבמה לבין כזה שישמש אנשים אמיתיים. תוך שישה חודשים היינו צריכים להפוך את אב הטיפוס הגולמי למשהו שמתאים לטייס. ואז הבנו מה המשמעות של "כאב".

על מנת להפוך את המערכת שלנו למבוזרת ופתוחה, החלטנו להשתמש בחוזים חכמים של Ethereum. הבחירה נפלה על הפלטפורמה הזו של שירותים מקוונים מבוזרים בגלל הפופולריות שלה והיכולת לבנות אפליקציה ללא שרת. תכננו ליישם את הפרויקט שלנו באופן הבא.

אבל, למרבה הצער, חוזה חכם הוא קוד שמבוצע על ידי מכונה וירטואלית בזמן עסקה, והוא אינו יכול להחליף שרת מן המניין. לדוגמה, חוזה חכם אינו יכול לבצע פעולות ממתינות או מתוזמנות. בפרויקט שלנו, זה לא אפשר לנו ליישם שירות השכרה לדקה, כפי שעושים רוב שירותי שיתוף הרכב המודרניים. לכן, חייבנו מטבע קריפטו מהמשתמש לאחר השלמת העסקה מבלי להיות בטוחים שיש לו מספיק כסף. גישה זו מקובלת רק לפיילוט פנימי וכמובן מוסיפה בעיות בעת תכנון פרויקט ייצור מלא.

לכל האמור לעיל מתווספת רטיבות הפלטפורמה עצמה. לדוגמה, אם תכתוב חוזה חכם עם לוגיקה שונה מאסימוני ERC-20, תיתקל בבעיות טיפול בשגיאות. בדרך כלל, אם הקלט שגוי או שהשיטות שלנו אינן פועלות כהלכה, אנו מקבלים קוד שגיאה בתגובה. במקרה של Ethereum, אנחנו לא יכולים לקבל שום דבר מלבד כמות הגז שהוצאה לביצוע פונקציה זו. גז הוא מטבע שיש לשלם עבור עסקאות וחישובים: ככל שתשלמו יותר פעולות בקוד שלכם. אז כדי להבין מדוע הקוד לא עובד, תחילה תבדוק אותו על ידי הדמיית כל השגיאות האפשריות וקוד קשה את הגז שהוצא כקוד שגיאה. אבל אם תשנה את הקוד שלך, הטיפול בשגיאה הזה יישבר.

בנוסף, כמעט בלתי אפשרי ליצור אפליקציית מובייל שעובדת עם הבלוקצ'יין ביושר, מבלי להשתמש במפתח המאוחסן איפשהו בענן. למרות שקיימים ארנקים כנים, הם אינם מספקים ממשקים לחתימה על עסקאות חיצוניות. משמעות הדבר היא שלא תראה יישום מקורי אלא אם כן יש לו ארנק קריפטו מובנה, שלמשתמשים יהיה אמון בו מעט (לא הייתי סומך עליו). כתוצאה מכך, גם כאן נאלצנו לחתוך פינה. חוזים חכמים נמסרו לרשת Ethereum הפרטית, והארנק היה מבוסס ענן. אך למרות זאת, המשתמשים שלנו חוו את כל ה"תענוגות" של שירותים מבוזרים בצורה של המתנה ארוכה לעסקאות מספר פעמים בכל סשן השכרה.

כל זה מוביל אותנו לארכיטקטורה הזו. מסכים, זה שונה מאוד ממה שתכננו.

אס בתוך החור: זהות ריבונית עצמית

אתה לא יכול לבנות מערכת מבוזרת לחלוטין ללא זהות מבוזרת. על החלק הזה אחראית Self-Sovereign Identity (SSI) שמהותו היא שאתה זורק את ספק הזהות הריכוזית (IDP) ומפיץ את כל הנתונים והאחריות עליו לאנשים. כעת המשתמש מחליט אילו נתונים הוא צריך ועם מי הוא ישתף אותם. כל המידע הזה נמצא במכשיר של המשתמש. אבל בשביל ההחלפה נצטרך מערכת מבוזרת לאחסון ראיות קריפטוגרפיות. כל ההטמעות המודרניות של תפיסת SSI משתמשות בבלוקצ'יין כאחסון.

"מה זה קשור לאס שבחור?" - אתה שואל. השקנו את השירות לבדיקות פנימיות על העובדים שלנו בברלין ובבון, ונתקלנו בקשיים בדמות איגודי עובדים גרמניים. בגרמניה נאסר על חברות לפקח על תנועות העובדים, ואיגודים מקצועיים שולטים בכך. הגבלות אלו שמים קץ לאחסון מרוכז של נתוני זהות המשתמש, שכן במקרה זה נדע את מיקומם של העובדים. יחד עם זאת, לא יכולנו שלא לבדוק אותם בגלל אפשרות של גניבת קטנועים. אבל הודות ל-Self-Sovereign Identity, המשתמשים שלנו השתמשו במערכת באופן אנונימי, והקטנוע עצמו בדק את רישיון הנהיגה שלהם לפני תחילת ההשכרה. כתוצאה מכך, אחסנו מדדי משתמשים אנונימיים; לא היו לנו מסמכים או נתונים אישיים: כולם היו כלולים במכשירים של הנהגים עצמם. כך, הודות ל-SSI, הפתרון לבעיה בפרויקט שלנו היה מוכן עוד לפני שהופיע.

המכשיר עשה לי בעיות

לא יישמנו בעצמנו זהות ריבונית עצמית, מכיוון שהיא דורשת מומחיות בקריפטוגרפיה והרבה זמן. במקום זאת, ניצלנו את המוצר של השותפים שלנו Jolocom ושילבנו את הארנק והשירותים הניידים שלהם בפלטפורמה שלנו. לרוע המזל, למוצר הזה יש חיסרון אחד משמעותי: שפת הפיתוח העיקרית היא Node.js.

ערימת טכנולוגיה זו מגבילה מאוד את בחירת החומרה המובנית בקטנוע שלנו. למרבה המזל, כבר בתחילת הפרויקט בחרנו ב-Raspberry Pi Zero, וניצלנו את כל היתרונות של מיקרו-מחשב מלא. זה איפשר לנו להפעיל Node.js מגושם על הקטנוע. בנוסף, קיבלנו ניטור וגישה מרחוק באמצעות VPN באמצעות כלים מוכנים.

לסיכום

למרות כל ה"כאב" והבעיות, הפרויקט יצא לדרך. לא הכל עבד כפי שתכננו, אבל באמת היה אפשר לרכוב על קטנועים על ידי השכרתם.

כן, עשינו מספר טעויות בתכנון הארכיטקטורה שלא אפשרו לנו להפוך את השירות למבוזר לחלוטין, אבל גם בלי הטעויות הללו כמעט ולא היינו מצליחים ליצור פלטפורמה ללא שרת. זה דבר אחד לכתוב עוד פירמידה קריפטו, ודבר אחר לגמרי לכתוב שירות מן המניין שבו אתה צריך לטפל בשגיאות, לפתור מקרים גבוליים ולבצע משימות ממתינות. נקווה שהפלטפורמות החדשות שצצו לאחרונה יהיו גמישות ופונקציונליות יותר.

מקור: www.habr.com