Në këtë artikull, do t'ju tregoj se si ne u përpoqëm të ndërtonim një shpërndarje të decentralizuar të skuterëve me kontrata inteligjente dhe pse na nevojitej gjithsesi një shërbim qendror.

Si filloi gjithçka
Në nëntor të vitit 2018, morëm pjesë në një hackathon që ishte e dedikuar për internetin e gjërave dhe blockchain. Idéia e ekipit tonë ishte skuter-sharing, pasi kishim një skuter nga sponsori i këtij hackathoni. Prototipi dukej si një aplikacion mobil që lejonte aktivizimin e skuteri përmes NFC. Nga pikëpamja e marketingut, ideja mbështetej në një tregim për "të ardhmen e ndritur" me një ekosistem të hapur, ku secili mund të ishte marrës ose ofrues, dhe e gjitha kjo mbi bazën e kontratave inteligjente.
Kjo ide i pëlqeu shumë palëve tona të interesit dhe ata vendosën ta kthejnë atë në një prototip për të demonstruar në ekspozita. Pas disa shfaqjeve të suksesshme në Mobile World Congress dhe Bosch Connected World në vitin 2019, u mor vendimi për të testuar shpërndarjen e skuterëve me përdorues të vërtetë, punonjës të Deutsche Telekom. Kështu, ne filluam zhvillimin e një MVP të plotë.
Blockchain mbi paterica
Mendoj se nuk ka nevojë të shpjegojmë se çfarë ndryshimi ka mes një projekti për shfaqje në skenë dhe një projekti që do të përdoret nga njerëz të vërtetë. Gjatë gjashtë muajve, na duhej të kthente një prototip të papërpunuar në diçka të përshtatshme për pilotin. Dhe këtu kuptuam se çfarë nënkupton "dhembja".
Për të bërë sistemin tonë të decentralizuar dhe të hapur, ne vendosëm të përdorim kontratat inteligente Ethereum. Zgjedhja ra mbi këtë platformë shërbimesh online dekontalizuar për shkak të popullaritetit të saj dhe mundësisë për të ndërtuar një aplikacion pa server. Ne planifikonim të realizonim projektin tonë kështu.

Por, fatkeqësisht, kontrata inteligjente është kod që ekzekutohet nga makineria virtuale në momentin e transaksionit dhe ajo nuk mund të zëvendësojë një server. Për shembull, kontrata inteligjente nuk mund të kryejë veprime të vonuara ose të planifikuara. Në projektin tonë, kjo na pengoi të realizonim një shërbim me minutë, siç bëjnë shumica e shpërndarjeve moderne. Prandaj, ne debitonim kriptovalutën nga përdoruesi pas përfundimit të operacionit pa siguri se ai ka një shumicë të mjaftueshme parash. Ky qasje është e pranueshme vetëm për pilotin e brendshëm dhe, sigurisht, sjell probleme në projektimin e një projekti të plotë prodhimi.
Në përmbledhje, duhet të luftojmë me lagështinë e platformës vetë. P.sh., nëse shkruani një kontratë të mençur me logjikë që i përket ndryshe nga tokenet ERC-20, do të hasni në një problem me përpunimin e gabimeve. Zakonisht, kur kemi hyrje të gabuar ose kur metodat tona nuk funksionojnë siç duhet, marrim një kod gabimi si përgjigje. Në rastin e Ethereum, nuk mund të marrim gjë tjetër përveç sasisë së gazit të shpenzuar për kryerjen e kësaj funksioni. Gazi është valuta që duhet të paguani për transaksionet dhe llogaritjet: sa më shumë operacione të jenë në kodin tuaj, aq më shumë do të paguani. Prandaj, për të kuptuar pse kodi nuk funksionon, për herë të parë e testoni atë, duke simuluar të gjitha gabimet e mundshme dhe duke e hardkoduar gazin e shpenzuar si kod gabimi. Por nëse ndryshoni kodin tuaj, kjo përpunim gabimesh do të prishët.
Përveç kësaj, është pothuajse e pamundur të krijosh një aplikacion mobil që funksionon me blockchain në mënyrë të ndershme, pa përdorur një çelës që ruhen diku në cloud. Edhe pse ekzistojnë portofolë të ndershëm, ato nuk ofrojnë ndërfaqe për nënshkrimin e transaksioneve të jashtme. Kjo do të thotë se nuk do të ketë një aplikacion natyror, nëse nuk ka një portofol kripto të integruar, për të cilin përdoruesit do të kenë pak besim (unë sigurisht nuk do të besoja). Si rezultat, edhe këtu na detyroi të shkurtojmë. Kontratë të mençura u dërguan në rrjetin privat Ethereum, ndërsa portofoli ishte cloud. Por pavarësisht kësaj, përdoruesit tanë përjetuan të gjitha "të mirat" e shërbimeve të decentralizuara në formën e pritjeve të gjata për transaksionet në disa raste gjatë sesionit të qirasë.
E gjithë kjo na sjell në një arkitekturë të tillë. Prano, është shumë ndryshe nga ajo që patëm planifikuar.

Asi në mëngë: Identiteti i Vetë-Sovran
Nuk mund të ndërtohet një sistem krejtësisht të decentralizuar pa identifikim të decentralizuar. Pjesa për këtë e drejton Identiteti Autonom (SSI), e cila përfshin heqjen e ofruesit të centralizuar të identitetit (IDP) dhe dhënien e të gjitha të dhënave dhe përgjegjësive për to në duar të popullit. Tani përdoruesi vetë vendos se cilat të dhëna i duhen dhe me kë do të ndajë ato. Të gjitha këto informacione ndodhin në pajisjen e përdoruesit. Por për shkëmbim, na nevojitet një sistem decentralizues i ruajtjes së provave përkatëse. Të gjitha realizimet moderne të konceptit SSI përdorin blockchain si depo.
“Çfarë ka të bëjë me ashtin e fituesit?” – do të pyesni. Shërbimin e lançuam për një test të brendshëm me punonjësit tanë në Berlin dhe Bonn, dhe na dolën vështirësi përballë sindikatave gjermane. Në Gjermani, kompanitë ndalohen të monitorojnë lëvizjet e punonjësve, dhe sindikatat e kontrollojnë këtë. Këto kufizime hedhin poshtë ruajtjen e centralizuar të të dhënave të identifikimit të përdoruesve, pasi në këtë rast do të dimesht këtu vendndodhjen e punonjësve. Në të njëjtën kohë, nuk mund të mos i kontrollonim për shkak të mundësisë së grabitjeve të skuterave. Por falë Identitetit Autonom, përdoruesit tanë përdornin sistemin anonimisht, dhe skuterat vetë kontrollonin nëse ata kishin patentë para fillimit të qirasë. Si rezultat, ne mbajtëm metrika të degraduara të përdoruesve, pa asnjë dokument dhe të dhëna personale: të gjitha ato ishin ruajtur në pajisjet e vetë shoferëve. Kështu, falë SSI, zgjidhja e problemit në projektin tonë ishte gati përpara se të shfaqej.
Pajisja solli probleme
Ne nuk e realizuam vetë Identitetin Autonom, pasi kjo kërkon ekspertizë në kriptografi dhe shumë kohë. Në vend të kësaj, ne shfrytëzuam produktin e partnerëve tanë Jolocom dhe e integruam portofolin e tyre mobil dhe shërbimet në platformën tonë. Fatkeqësisht, ky produkt ka një disavantazh të rëndësishëm: gjuha kryesore e zhvillimit është Node.js.
Ky kyç dhe teknologji na vendos në një kufizim të madh në zgjedhjen e pajisjeve që integrohen në skuter. Për fat të mirë, në fillim të projektit, ne zgjodhëm Raspberry Pi Zero dhe shfrytëzuam të gjitha përfitimet e një mikrokompjuterit të plotë. Kjo na lejoi të ekzekutonim Node.js të mbushur në skuter. Përveç kësaj, morëm monitorim dhe qasje të largët përmes vpn, duke përdorur mjete të gatshme.
Në përfundim
Pavarësisht gjithë "dhembjes" dhe problemeve, projekti u lançua. Jo gjithçka funksionoi si ne e kishim planifikuar, por me të vërtetë mund të kalosh me skuterët, duke i marrë ata në qira.
Po, ne bëmë një sërë gabimesh gjatë ndërtimit të arkitekturës, që nuk na lejuan të bëjmë shërbimin plotësisht të decentralizuar, por edhe pa këto gabime është vështirë të krijosh një platformë serverless. Është një gjë të shkruash një tjetër piramidë kripto dhe krejt tjetër të kesh një shërbim të plotë, ku duhet të trajtosh gabimet, të zgjidhësh raste kufitare dhe të realizosh detyra të vonuara. Le të shpresojmë që platforma të reja që kanë dalë së fundmi do të jenë më fleksibile dhe funksionale.
Burimi: habr.com
