V tomto článku se podělím o to, jak jsme se pokusili vybudovat decentralizovaný systém pronájmu skútrů na chytrých kontraktech a proč jsme přesto potřebovali centralizovanou službu.
Jak to všechno začalo
V listopadu 2018 jsme se zúčastnili hackathonu zaměřeného na internet věcí a blockchain. Jako nápad si naše tým vybral sdílení skútrů, protože jsme měli skútr od sponzora tohoto hackathonu. Prototyp vypadal jako mobilní aplikace, která umožňovala spustit skútr pomocí NFC. Z hlediska marketingu byla myšlenka podpořena vyprávěním o "světlé budoucnosti" s otevřenou ekosystémem, kde se každý může stát nájemcem nebo pronajímatelem, a to vše na základě chytrých kontraktů.
Tato idea se velmi zalíbila našim zainteresovaným stranám, a rozhodly se ji přetvořit v prototyp pro prezentaci na výstavách. Po několika úspěšných prezentacích na Mobile World Congress a Bosch Connected World v roce 2019 bylo rozhodnuto otestovat pronájem skútrů u reálných uživatelů, zaměstnanců Deutsche Telekom. Tak jsme začali vyvíjet plnohodnotný MVP.
Blockchain na berličkách
Myslím, že není potřeba vysvětlovat, jaký je rozdíl mezi projektem pro prezentaci na pódiu a tím, kterým budou používat skuteční lidé. Během šesti měsíců jsme museli převést surový prototyp na něco vhodného pro pilotní projekt. A tady jsme pochopili, co znamená "bolest".
Abychom naši systém udělali decentralizovaný a otevřený, rozhodli jsme se použít chytré kontrakty Ethereum. Výběr padl na tuto platformu decentralizovaných online služeb kvůli její popularitě a možnosti vytvořit serverless aplikaci. Plánovali jsme realizovat náš projekt následujícím způsobem.
Bohužel, chytrý kontrakt je kód, který je prováděn virtuální stroj v okamžiku transakce, a nemůže nahradit plnohodnotný server. Například, chytrý kontrakt nemůže vykonávat odložené nebo naplánované akce. V našem projektu to neumožnilo realizovat minutovou službu pronájmu, jak to dělá většina moderních carsharingů. Proto jsme strhávali kryptoměnu od uživatele po dokončení operace, aniž bychom měli jistotu, že má dostatek peněz. Takový přístup je přijatelný pouze pro interní pilot a rozhodně přidává problémy při návrhu plnohodnotného produkčního projektu.
K tomu všemu se přidává vlhkost samotné platformy. Například, pokud vytvoříte smart kontrakt s logikou odlišnou od tokenů ERC-20, narazíte na problém s chybovou hláškou. Obvykle při nesprávném vstupu nebo chybném fungování našich metod dostáváme jako odpověď chybový kód. V případě Ethereum nemůžeme získat nic jiného než množství plynu, které bylo vynaloženo na provedení této funkce. Plyn je měna, kterou je třeba platit za transakce a výpočty: čím více operací je ve vašem kódu, tím více zaplatíte. Takže abyste pochopili, proč kód nefunguje, musíte ho nejprve otestovat, simulací všech možných chyb, a hardcodovat vynaložený plyn jako chybový kód. Ale pokud svůj kód změníte, tato obsluha chyb se rozpadne.
Kromě toho je prakticky nemožné vytvořit mobilní aplikaci, která by poctivě pracovaly s blockchainem, aniž byste používali klíč uložený kdesi v cloudu. Ačkoli čestné peněženky existují, neposkytují rozhraní pro podepisování externích transakcí. To znamená, že nativní aplikace se bez integrované krypto-peněženky neobejdou, což vyžaduje, aby uživatelé měli nízkou důvěru (já bych nevěřil). V důsledku toho jsme i zde museli udělat kompromis. Smart kontrakty byly dodávány do privátní sítě Ethereum a peněženka byla v cloudu. Přesto naši uživatelé zažili všechny „výlety“ decentralizovaných služeb v podobě dlouhého čekání na transakce několikrát během jedné doby pronájmu.
To vše nás vede k takové architektuře. Souhlasíte, že se výrazně liší od toho, co jsme plánovali.
Eso v rukávu: Self-Sovereign Identity
Není možné vybudovat zcela decentralizovaný systém bez decentralizované identity. O tuto část se stará Self-Sovereign Identity (SSI), jejíž podstatou je, že se zbavujete centralizovaného poskytovatele identity (IDP) a předáváte lidem veškerá data a zodpovědnost za ně. Nyní uživatel sám rozhoduje, jaká data potřebuje a s kým je bude sdílet. Veškeré tyto informace jsou na zařízení uživatele. Pro výměnu však budeme potřebovat decentralizovaný systém ukládání kryptografických důkazů. Všechny moderní realizace konceptu SSI používají blockchain jako úložiště.
„Co má společného s esem v rukávu?“ — zeptáte se. Službu jsme spustili pro interní testování na našich zaměstnancích v Berlíně a Bonnu a před námi se objevily potíže v podobě německých odborů. V Německu je společnostem zakázáno sledovat pohyb zaměstnanců a odbory to kontrolují. Tato omezení znemožňují centralizované uchovávání dat uživatelských identifikátorů, protože bychom v takovém případě znali polohu zaměstnanců. Zároveň jsme je však nemohli neprověřit kvůli možnosti krádeže skútrů. Díky Self-Sovereign Identity však naši uživatelé využívali systém anonymně a samotný skútr ověřoval platnost jejich řidičského průkazu před zahájením pronájmu. Výsledkem byly anonymizované metriky uživatelů, žádné dokumenty a osobní údaje jsme neměli: všechny byly uloženy na zařízeních samotných řidičů. Takže díky SSI bylo řešení problému v našem projektu hotové ještě před jeho vznikem.
Zařízení přineslo problémy
Self-Sovereign Identity jsme nezrealizovali sami, protože to vyžaduje odborné znalosti v oblasti kryptografie a spoustu času. Místo toho jsme využili produkt našich partnerů Jolocom a integrovali jejich mobilní peněženku a služby do naší platformy. Bohužel tento produkt má jeden zásadní nevýhodu: hlavním jazykem vývoje je Node.js.
Tento technologický stack nás velmi omezuje ve výběru hardwaru, který je zabudován do skútru. Naštěstí jsme na začátku projektu zvolili Raspberry Pi Zero a využili jsme všech výhod plnohodnotného mikropočítače. To nám umožnilo spustit objemný Node.js na skútru. Kromě toho jsme získali monitoring a vzdálený přístup přes vpn, s využitím již hotových nástrojů.
Na závěr
Ačkoli jsme museli čelit řadě „bolestí“ a problémů, projekt byl spuštěn. Ne všechno fungovalo podle našich plánů, ale na skútrech se skutečně dalo jezdit, pokud jste si je vypůjčili.
Ano, při navrhování architektury jsme udělali několik chyb, které nám nedovolily vytvořit zcela decentralizovanou službu, ale i bez těchto chyb bychom sotva dokázali vytvořit serverless platformu. Je rozdíl psát další kryptoměnovou pyramidu a naprosto jiná věc je plnohodnotná služba, v níž je třeba zpracovávat chyby, řešit okrajové případy a vykonávat zpožděné úkoly. Doufejme, že nové platformy, které se nedávno objevily, budou flexibilnější a funkčnější.
Zdroj: habr.com
