Սկուտերների ապակենտրոնացված վարձույթի ծրագրային ապահովում մշակել: Ո՞վ ասաց, որ հեշտ կլինի:

Այս հոդվածում ես կխոսեմ այն ​​մասին, թե ինչպես մենք փորձեցինք կառուցել ապակենտրոնացված սկուտերների վարձույթ խելացի պայմանագրերով, և ինչու մեզ դեռ անհրաժեշտ էր կենտրոնացված ծառայություն:

Ինչպես այդ ամենը սկսվեց

2018 թվականի նոյեմբերին մենք մասնակցեցինք հաքաթոնին՝ նվիրված իրերի ինտերնետին և բլոկչեյնին։ Մեր թիմը որպես գաղափար ընտրեց սկուտերների փոխանակումը, քանի որ մենք ունեինք սկուտեր այս հաքաթոնի հովանավորից: Նախատիպը նման էր բջջային հավելվածի, որը թույլ է տալիս գործարկել սկուտեր NFC-ի միջոցով: Մարքեթինգային տեսանկյունից գաղափարը պաշտպանվում էր բաց էկոհամակարգով «պայծառ ապագայի» մասին պատմվածքով, որտեղ յուրաքանչյուրը կարող է դառնալ վարձակալ կամ տանտեր՝ հիմնված խելացի պայմանագրերի վրա:

Մեր շահագրգիռ կողմերին շատ դուր եկավ այս գաղափարը, և նրանք որոշեցին այն դարձնել նախատիպ՝ ցուցահանդեսներում ցուցադրելու համար: 2019 թվականին Mobile World Congress-ում և Bosch Connected World-ում մի քանի հաջող ցուցադրություններից հետո որոշվեց փորձարկել սկուտերների վարձույթը իրական օգտատերերի՝ Deutsche Telekom-ի աշխատակիցների հետ: Այսպիսով, մենք սկսեցինք զարգացնել լիարժեք MVP:

Բլոկչեյն հենակների վրա

Չեմ կարծում, թե արժե բացատրել, թե ինչ տարբերություն կա բեմում ցուցադրվելիք նախագծի և իրական մարդկանց կողմից օգտագործվող նախագծի միջև: Վեց ամսում մենք պետք է անմշակ նախատիպը վերածեինք օդաչուի համար հարմար բանի։ Եվ հետո հասկացանք, թե ինչ է նշանակում «ցավ»։

Մեր համակարգը ապակենտրոնացված և բաց դարձնելու համար մենք որոշեցինք օգտագործել Ethereum խելացի պայմանագրերը: Ընտրությունն ընկավ ապակենտրոնացված առցանց ծառայությունների այս հարթակի վրա՝ նրա ժողովրդականության և առանց սերվերի հավելված ստեղծելու հնարավորության պատճառով: Մեր նախագիծը նախատեսել էինք իրականացնել հետեւյալ կերպ.

Բայց, ցավոք, խելացի պայմանագիրը գործարքի պահին վիրտուալ մեքենայի կողմից գործարկվող ծածկագիր է, և այն չի կարող փոխարինել լիարժեք սերվերին: Օրինակ, խելացի պայմանագիրը չի կարող կատարել առկախ կամ պլանավորված գործողություններ: Մեր նախագծում դա թույլ չտվեց մեզ իրականացնել մեկ րոպեի վարձույթի ծառայություն, ինչպես դա անում են ժամանակակից մեքենաների փոխանակման ծառայությունների մեծ մասը: Հետևաբար, գործարքն ավարտելուց հետո մենք գաղտնագրել ենք կրիպտոարժույթը՝ վստահ չլինելով, որ նա բավականաչափ գումար ունի: Այս մոտեցումը ընդունելի է միայն ներքին փորձնականի համար և, իհարկե, խնդիրներ է ավելացնում լիարժեք արտադրական նախագծի նախագծման ժամանակ:

Վերոհիշյալ բոլորին գումարվում է հենց հարթակի խոնավությունը: Օրինակ, եթե դուք խելացի պայմանագիր եք գրում ERC-20 ժետոններից տարբերվող տրամաբանությամբ, դուք կհանդիպեք սխալների հետ աշխատելու հետ կապված խնդիրների հետ: Սովորաբար, եթե մուտքագրումը սխալ է կամ մեր մեթոդները ճիշտ չեն աշխատում, մենք ի պատասխան ստանում ենք սխալի կոդը: Ethereum-ի դեպքում մենք այլ բան չենք կարող ստանալ, քան այս ֆունկցիան կատարելու համար ծախսված գազի քանակությունը։ Գազը արժույթ է, որը պետք է վճարվի գործարքների և հաշվարկների համար. որքան շատ գործառնություններ լինեն քո ծածկագրում, այնքան ավելի շատ կվճարես: Այսպիսով, հասկանալու համար, թե ինչու կոդը չի աշխատում, նախ փորձեք այն՝ մոդելավորելով բոլոր հնարավոր սխալները և կոշտ կոդավորելով ծախսված գազը որպես սխալի կոդ: Բայց եթե փոխեք ձեր կոդը, այս սխալի մշակումը կխախտվի:

Բացի այդ, գրեթե անհնար է ստեղծել բջջային հավելված, որն ազնվորեն աշխատում է բլոկչեյնի հետ՝ առանց ամպի մեջ ինչ-որ տեղ պահվող բանալի օգտագործելու։ Չնայած կան ազնիվ դրամապանակներ, դրանք արտաքին գործարքներ կնքելու համար միջերեսներ չեն տրամադրում: Սա նշանակում է, որ դուք չեք տեսնի բնիկ հավելված, քանի դեռ այն չունի ներկառուցված կրիպտո դրամապանակ, որին օգտվողները քիչ վստահություն կունենան (ես դրան չէի վստահի): Արդյունքում մենք ստիպված եղանք նաև անկյուն կտրել այստեղ։ Խելացի պայմանագրերը մատակարարվել են մասնավոր Ethereum ցանցին, իսկ դրամապանակը հիմնված է ամպի վրա: Բայց չնայած դրան, մեր օգտատերերը զգացել են ապակենտրոնացված ծառայությունների բոլոր «հաճույքները»՝ վարձակալության յուրաքանչյուր նստաշրջանում մի քանի անգամ գործարքների համար երկար սպասելու տեսքով:

Այս ամենը մեզ տանում է դեպի այս ճարտարապետությունը։ Համաձայնեք, դա շատ է տարբերվում մեր ծրագրածից։

Ace փոսում. Ինքնասուվերեն Ինքնություն

Դուք չեք կարող կառուցել ամբողջովին ապակենտրոնացված համակարգ առանց ապակենտրոնացված ինքնության: Այս մասի համար պատասխանատու է Self-Sovereign Identity (SSI), որի էությունը կայանում է նրանում, որ դուք դուրս եք նետում կենտրոնացված ինքնության մատակարարին (IDP) և բաշխում եք դրա բոլոր տվյալները և պատասխանատվությունը ժողովրդին: Այժմ օգտատերը որոշում է, թե ինչ տվյալներ են իրեն անհրաժեշտ և ում հետ կկիսվեն դրանք։ Այս ամբողջ տեղեկատվությունը գտնվում է օգտագործողի սարքում: Բայց փոխանակման համար մեզ անհրաժեշտ կլինի կրիպտոգրաֆիկ ապացույցների պահպանման ապակենտրոնացված համակարգ: SSI հայեցակարգի բոլոր ժամանակակից իրականացումներն օգտագործում են բլոկչեյնը որպես պահեստ:

«Ի՞նչ կապ ունի սա փոսում գտնվող էսի հետ»: -հարցնում ես։ Մենք գործարկեցինք Բեռլինում և Բոննում մեր աշխատակիցների ներքին թեստավորման ծառայությունը, և մենք հանդիպեցինք դժվարությունների՝ ի դեմս գերմանական արհմիությունների: Գերմանիայում ընկերություններին արգելվում է վերահսկել աշխատակիցների տեղաշարժերը, իսկ արհմիությունները վերահսկում են դա։ Այս սահմանափակումները վերջ են դնում օգտվողի ինքնության տվյալների կենտրոնացված պահպանմանը, քանի որ այս դեպքում մենք կիմանանք աշխատողների գտնվելու վայրը: Միևնույն ժամանակ, մենք չէինք կարող չստուգել դրանք՝ սկուտերների գողության հնարավորության պատճառով: Բայց շնորհիվ Self-Sovereign Identity-ի, մեր օգտատերերը անանուն օգտագործեցին համակարգը, և սկուտերն ինքը ստուգեց նրանց վարորդական իրավունքը նախքան վարձակալությունը սկսելը: Արդյունքում մենք պահեցինք անանուն օգտատերերի չափումները, մենք չունեինք որևէ փաստաթուղթ կամ անձնական տվյալ. դրանք բոլորը պարունակվում էին հենց վարորդների սարքերում: Այսպիսով, SSI-ի շնորհիվ մեր նախագծում խնդրի լուծումը պատրաստ էր դեռևս դրա հայտնվելուց առաջ։

Սարքն ինձ խնդիրներ առաջացրեց

Մենք ինքներս չենք իրականացրել Ինքնավար Ինքնությունը, քանի որ այն պահանջում է կրիպտոգրաֆիայի փորձաքննություն և շատ ժամանակ: Փոխարենը, մենք օգտվեցինք մեր գործընկերների Jolocom-ի արտադրանքից և ինտեգրեցինք նրանց բջջային դրամապանակն ու ծառայությունները մեր հարթակում: Ցավոք, այս արտադրանքն ունի մեկ նշանակալի թերություն՝ զարգացման հիմնական լեզուն Node.js-ն է:

Տեխնոլոգիաների այս փաթեթը մեծապես սահմանափակում է սկուտերի մեջ ներկառուցված սարքավորումների մեր ընտրությունը: Բարեբախտաբար, նախագծի հենց սկզբում մենք ընտրեցինք Raspberry Pi Zero-ն և օգտվեցինք լիարժեք միկրոհամակարգչի բոլոր առավելություններից։ Սա թույլ տվեց մեզ սկուտերի վրա գործարկել մեծածավալ Node.js-ը: Բացի այդ, մենք ստացել ենք մոնիտորինգ և հեռահար մուտք VPN-ի միջոցով՝ օգտագործելով պատրաստի գործիքներ:

Վերջում

Չնայած բոլոր «ցավերին» ու խնդիրներին՝ նախագիծը մեկնարկեց։ Ամեն ինչ չէ, որ ստացվեց այնպես, ինչպես պլանավորել էինք, բայց վարձակալելով դրանք իսկապես հնարավոր էր սկուտեր վարել:

Այո, ճարտարապետությունը նախագծելիս թույլ տվեցինք մի շարք սխալներ, որոնք թույլ չտվեցին ծառայությունն ամբողջությամբ ապակենտրոնացնել, բայց նույնիսկ առանց այս սխալների մենք դժվար թե կարողանայինք ստեղծել առանց սերվերի հարթակ։ Մեկ այլ բան է գրել մեկ այլ կրիպտոբուրգ, և բոլորովին այլ բան է գրել լիարժեք ծառայություն, որում պետք է կարգավորել սխալները, լուծել սահմանային դեպքերը և կատարել առկախ առաջադրանքներ: Հուսանք, որ վերջերս ի հայտ եկած նոր հարթակները կլինեն ավելի ճկուն ու գործունակ։

Source: www.habr.com