У гэтым артыкуле я раскажу пра тое, як мы спрабавалі пабудаваць дэцэнтралізаваны пракат скутэраў на смарт кантрактах і чаму нам усё роўна спатрэбіўся цэнтралізаваны сэрвіс.
Як усё пачыналася
У лістападзе 2018 года мы прынялі ўдзел у хакатоне, прысвечаным інтэрнэту рэчаў і блокчэйн. У якасці ідэі наша каманда выбрала скутэршэрынг, бо ў нас быў скутэр ад спонсара гэтага хакатона. Прататып выглядаў як мабільнае прыкладанне, якое дазваляе запускаць скутэр праз NFC. З пункту гледжання маркетынгу, ідэя падмацоўвалася аповедам пра "светлую будучыню" з адкрытай экасістэмай, дзе кожны можа стаць арандатарам або арэндадаўцам, і ўсё гэта на базе разумных кантрактаў.
Гэта ідэя вельмі спадабалася нашым стэйкхолдэрам, і яны вырашылі ператварыць яе ў прататып для дэманстрацыі на выставах. Пасля некалькіх паспяховых паказаў на Mobile World Congress і Bosch Connected World у 2019 годзе было прынята рашэнне пратэставаць пракат скутэраў на рэальных карыстальніках, супрацоўніках Deutsche Telekom. Так мы прыступілі да распрацоўкі паўнавартаснага MVP.
Блокчейн на мыліцах
Я думаю, што не трэба тлумачыць, якая розніца паміж праектам для паказу на сцэне і тым, якім будуць карыстацца рэальныя людзі. За шэсць месяцаў нам трэба было ператварыць сыры прататып у нешта прыдатнае для пілота. І тут мы зразумелі, што значыць "боль".
Для таго каб зрабіць нашу сістэму дэцэнтралізаванай і адчыненай, мы вырашылі выкарыстаць разумныя кантракты Ethereum. Выбар упаў на гэтую платформу дэцэнтралізаваных анлайн-сэрвісаў з-за яе папулярнасці і магчымасці пабудаваць serverless-дадатак. Мы планавалі рэалізаваць наш праект наступным чынам.
Але, нажаль, смарт кантракт - гэта код, выкананы віртуальнай машынай у момант транзакцыі, і ён не можа замяніць паўнавартасны сервер. Напрыклад, смарт кантракт не можа выконваць адкладзеныя ці запланаваныя дзеянні. У нашым праекце гэта не дазволіла рэалізаваць штохвілінны сэрвіс арэнды, як робяць большасць сучасных каршэрынгаў. Таму мы спісвалі крыптавалюце з карыстальніка пасля завяршэння аперацыі без упэўненасці, што ў яго ёсць дастатковая колькасць грошай. Такі падыход прымальны толькі для ўнутранага пілота і, безумоўна, дадае праблем пры праектаванні паўнацэннага прадакшэн-праекта.
Да ўсяго вышэйсказанага дадаецца волкасць самай платформы. Напрыклад, напісаўшы смарт кантракт з логікай, выдатнай ад токенаў ERC-20, вы сутыкнецеся з праблемай апрацоўкі памылак. Звычайна пры некарэктным уводзе ці няправільнай працы нашых метадаў, мы атрымліваем у адказ код памылкі. У выпадку Ethereum мы не можам атрымаць нічога, акрамя колькасці газу, затрачанага на выкананне гэтай функцыі. Газ - гэта валюта, якую неабходна плаціць за транзакцыі і вылічэнні: чым больш аперацый у вашым кодзе, тым больш вы заплаціце. Таму, каб зразумець, чаму код не працуе, вы спачатку тэстуеце яго, сімулюючы ўсе магчымыя памылкі, і хардкодзіце затрачаны газ у якасці кода памылкі. Але калі вы зменіце свой код, гэтая апрацоўка памылак паламаецца.
Акрамя гэтага, практычна немагчыма стварыць мабільнае прыкладанне, якое працуе з блокчейном па-чэснаму, не выкарыстоўваючы ключ, які захоўваецца дзесьці ў воблаку. Хоць сумленныя кашалькі і існуюць, яны не падаюць інтэрфейсаў для падпісання вонкавых транзакцый. Гэта значыць, што натыўнага прыкладання вам не відаць, калі ў ім не будзе ўбудаваны крыпта-кашалёк, да якога ў карыстачоў даверу будзе мала (я бы не давяраў). У выніку тут нам таксама прыйшлося зразаць кут. Смарт кантракты дастаўляліся ў прыватную сетку Ethereum, а кашалёк быў хмарным. Але нягледзячы на гэта, нашы карыстачы адчулі ўсе "любаты" дэцэнтралізаваных сэрвісаў у выглядзе працяглага чакання транзакцый па некалькі разоў за сесію арэнды.
Усё гэта прыводзіць нас да вось такой архітэктуры. Згадзіцеся, яна моцна адрозніваецца ад таго, што мы планавалі.
Туз у рукаве: Self-Sovereign Identity
Нельга пабудаваць поўнасцю дэцэнтралізаваную сістэму без дэцэнтралізаванай ідэнтыфікацыі. За гэтую частку адказвае Self-Sovereign Identity (SSI), сутнасць якой заключаецца ў тым, што вы выкідваеце цэнтралізаваны правайдэр ідэнтычнасці (IDP) і раздаеце народу ўсе дадзеныя і адказнасць за іх. Цяпер карыстач сам вырашае, якія дадзеныя яму патрэбныя і з кім ён будзе імі дзяліцца. Уся гэтая інфармацыя знаходзіцца на прыладзе карыстальніка. Але для абмену нам спатрэбіцца дэцэнтралізаваная сістэма захоўвання крыптаграфічных доказаў. Усе сучасныя рэалізацыі канцэпцыі SSI выкарыстоўваюць блокчэйн у якасці сховішча.
"Пры чым тут туз у рукаве?" - спытаеце вы. Сэрвіс мы запускалі для ўнутранага тэста на сваіх жа супрацоўніках у Берліне і Боне, і перад намі ўзніклі цяжкасці ў асобе нямецкіх прафсаюзаў. У Нямеччыне кампаніям забаронена сачыць за перасоўваннямі супрацоўнікаў, і прафсаюзы гэта кантралююць. Гэтыя абмежаванні ставяць крыж на цэнтралізаваным захоўванні дадзеных пасведчанняў карыстальнікаў, бо ў гэтым выпадку нам было б вядомае месцазнаходжанне супрацоўнікаў. У той жа час не правяраць іх мы не маглі з-за магчымасці згону скутараў. Але дзякуючы Self-Sovereign Identity нашы карыстачы карысталіся сістэмай ананімна, і наяўнасць правоў кіроўцы сам скутэр правяраў у іх перад стартам арэнды. У выніку ў нас захоўваліся абязлічаныя метрыкі карыстальнікаў, ніякіх дакументаў і асабістых дадзеных у нас не было: усе яны ўтрымліваліся на прыладах саміх кіроўцаў. Такім чынам, дзякуючы SSI вырашэнне праблемы ў нашым праекце было гатова яшчэ да яе з'яўлення.
Прылада падкінула праблем
Мы не рэалізоўвалі самастойна Self-Sovereign Identity, бо гэта патрабуе экспертызы ў крыптаграфіі і вялікай колькасці часу. Замест гэтага мы скарысталіся прадуктам нашых партнёраў Jolocom і інтэгравалі іх мабільны кашалёк і сервісы ў нашу платформу. Нажаль, гэты прадукт валодае адным істотным мінусам: асноўная мова распрацоўкі Node.js.
Такі тэхналагічны стэк вельмі моцна абмяжоўвае нас у выбары жалеза, які ўбудоўваецца ў скутэр. На шчасце, у самым пачатку праекту наш выбар упаў на Raspberry Pi Zero, і мы скарысталіся ўсімі перавагамі паўнавартаснага мікракампутара. Гэта дазволіла нам запусціць грувасткі Node.js на скутэры. Апроч гэтага мы атрымалі маніторынг і выдалены доступ праз vpn, выкарыстоўваючы гатовыя прылады.
У заключэнне
Нягледзячы на ўвесь "боль" і праблемы, праект быў запушчаны. Не ўсё працавала як мы планавалі, але на скутэрах сапраўды можна было пакатацца, узяўшы іх у арэнду.
Так, мы дапусцілі шэраг памылак пры праектаванні архітэктуры, якія не дазволілі нам зрабіць сэрвіс цалкам дэцэнтралізаваным, але нават без гэтых памылак нам ці наўрад атрымалася б стварыць serverless платформу. Адна справа пісаць чарговую крыпта-піраміду і зусім іншае - паўнавартасны сэрвіс, у якім трэба апрацоўваць памылкі, вырашаць памежныя кейсы і выконваць адкладзеныя заданні. Будзем спадзявацца на тое, што новыя платформы, якія з'явіліся ў нядаўні час, будуць больш гнуткімі і функцыянальнымі.
Крыніца: habr.com