Prototyp produktu TrustAir vznikol vrámci univerzitného projektu Živé IT projekty a umiestnil sa na prvom mieste z pomedzi všetkých projektov. Naším cieľom bolo vytvoriť automatizovaný dôveryhodný systém pre nákup poistenia meškania letov s použitím modernej rozvíjajúcej sa blockchain technológie, ktorá ale bude pred bežným používateľom skrytá za mobilnou aplikáciou s prehľadným rozhraním. V tomto článku Vám priblížime fungovanie platformy Ethereum a technológie blockchain a podelíme sa o naše skúsenosti pri návrhu a implementácii tohto produktu.
Nákup poistenia je jednoduchý. Pred letom si stačí otvoriť mobilnú aplikáciu, zadať základné údaje o lete, systém daný let vyhľadá a zvaliduje. Následne má používateľ možnosť zvoliť jednu z troch cenových ponúk s rôznymi výškami poistného plnenia. Platba prebieha pomocou kryptomeny Ethereum pričom svoju peňaženku si používateľ vie importovať priamo do aplikácie. Systém automaticky vyhodnocuje stav letov a v prípade meškania automatický ihneď odošle zvolené poistné plnenie. Viac informácii o produkte môžete vidieť vo videu alebo postery projektu.
Ethereum - Vytvárajte nezastaviteľné aplikácie
Ethereum je decentralizovaná platforma, ktorá prevádzkuje inteligentné kontrakty (Smart Contracts). Táto technológia zohráva kľúčovú úlohu vzhľadom na našu prípadovú štúdiu a zámer použitia. Platforma poskytuje možnosť vytvorenia aplikácie, ktorá je bez cenzúry, podvodov alebo zásahov tretích strán.
Projekt tejto platformy bol spustený v septembri roku 2014 prostredníctvom fanúšikov po celom svete. Vyvíjaná je švajčiarskou neziskovou organizáciou za pomoci príspevkov investorov z celého sveta.
Aplikácie navrhnuté prostredníctvom platformy Ethereum žijú svoj životný cyklus na gigantickej sieti s názvom blockchain. Táto sieť je charakteristická svojou mimoriadne silnou zdieľanou globálnou infraštruktúrou, ktorá dokáže presúvať určitú hodnotu a reprezentovať tak vlastníctvo určitého atribútu.
Základný pilier blockchain tvorí takzvaná Účtovná kniha (Ledger), kde sa uchovávajú informácie o jednotlivých transakciách, prostredníctvom tejto kvázi knihy sa potom jednotlivé uzly blockchain peer-to-peer siete synchronizujú. Legder je vizualizovaný na nasledujúcom diagrame, kde je možné vidieť ako je táto účtovná kniha štruktúrovaná, obsahuje transakcie tak ako boli v časovej chronológii vyžadované na vykonanie a validáciu. Každá transakcia v sebe nesie informácie o odosielateľovi, prijímateľovi a o objeme danej meny, ktorá má byť prenesená z adresy na adresu.
Výsledná štruktúra blockchainu je komponovaná z blokov, ktoré obsahujú určitý obnos transakcií, teda zápisov údajov a operácie vykonávané nad týmito údajmi a rovnako tieto bloky obsahujú adresu svojho predchádzajúceho a nasledujúceho bloku. Úplne prvý blok v blockchain konštalácii sa nazýva Genesis a neobsahuje adresu svojho predchodcu. Takto štruktúrovaný blockchain tvorí základnú štruktúru krypto sietí.
Krypto siete sa delia na dva druhy, kde prvým je tzv. Mainnet, ktorý predstavuje hlavnú sieť Ethereum platformy. Na tejto sieti sa vykonávajú a validujú reálne transakcie a presúvanou komoditou je tzv. Ether. Druhým typom siete, sú testovacie siete, ktoré slúžia hlavne na vývoj a testovanie Distribuovaných aplikácií (DApp). Náš projekt bol vyvíjaný práve na tomto type sietí, konkrétne na testovacej sieti s názvom Rinkeby, no na vývoj aplikácie je možné použiť ktorúkoľvek z dostupných testovacích sietí, alebo si developer môže vytvoriť aj vlastnú decentralizovanú sieť.
Na prístup a komunikáciu s blockchainom sme použili open-source platformu go-ethereum (Geth). V nasledujúcom bloku je názorne popísaný postup ako sa registrovať v testovacej sieti Rinkeby a ako vytvoriť vlastný uzol v sieti.
Krok 1: Stiahnutie Geth = GO Ethereum [Mac OS]
brew install ethereum
[Ubuntu]
sudo apt-get install software-properties-common
sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt-get update
sudo apt-get install ethereum
Krok 2: Spustenie Geth na Rinkeby sieti
geth —rinkeby
Krok 3: Vytvorenie účtu [Mac OS]
geth —datadir=$HOME/.rinkeby attach ipc:$HOME/Library/Ethereum/rinkeby/geth.ipc console
[Ubuntu]
geth —datadir=$HOME/.rinkeby attach ipc:$HOME/.rinkeby/geth.ipc console
Welcome to the Geth JavaScript console!
instance: Geth/v1.6.1-stable-021c3c28/darwin-amd64/go1.8.1
modules: admin:1.0 clique:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0
> eth.accounts
[]
> personal.newAccount(“notmyrealpassword”)
“0xb2e9fe08ca9a0323103883fe12c9609ed380f475”
> eth.coinbase
“0xb2e9fe08ca9a0323103883fe12c9609ed380f475”
> eth.getBalance(eth.coinbase)
0
Vyššie uvedené skutočnosti teda umožňujú vývojárom konštruovať trhy, v ktorých sa ukladajú registre dlhov lebo sľubov, presúvať finančné prostriedky podľa pokynov definovaných v dávnej minulosti (reprezentované ako určitá vôľa, alebo v budúcnosti existujúci kontrakt) a mnoho ďalších vecí, ktoré ešte neboli vynájdené, a to všetko úplne bez určitého sprostredkovateľa alebo rizika.
V čom je táto platforma odlišná od tých bežných?
Pri tradičných serverových architektúrach musí každá aplikácia, či nasadenie konfigurovať svoje vlastné servery, ktoré spravujú svoj privátny kód v izolovaných kontajneroch, čím dochádza k vytváraniu určitých ťažšie prekonateľných bariér pri spracovávaní zdieľaných dát. Rovnako tu vzniká problém so situáciou, ak je jedna aplikácia ohrozená alebo je offline, je ovplyvnený široký počet používateľov a ďalších závislých aplikácií.
TrustAir a Ethereum
Ethereum ako platforma zohráva v našom prototype kľúčovú úlohu, práve blockchain zabezpečuje uchovávanie všetkých poistných zmlúv vo forme Smart kontraktov. Čo sú to Smart kontrakty? Už z názvu plynie, že sa jedná o určité chytré zmluvy alebo dohody. Definíciu kontraktu môžeme interpretovať nasledovne:
“Inteligentná zmluva, známa aj ako krypto zmluva, je počítačový program, ktorý priamo zaisťuje prenos určitých digitálnych mien alebo aktív medzi stranami za určitých podmienok. Inteligentná zmluva nielenže definuje pravidlá a sankcie súvisiace s dohodou rovnakým spôsobom, ako tradičná zmluva, ale môže tiež automaticky presadzovať tieto povinnosti.”
Náš prototyp sa zaoberá vytváraním a validovaním poistných zmlúv bez potreby vypisovania množstva papierov a bez čakania na poisťovacích agentov, ktorý danú určitú poistnú udalosť overia a vyhodnotia. Hlavnou myšlienkou je teda možnosť urýchliť vytváranie a manipuláciu s poistnými zmluvami či škodovými udalosťami. Prototyp sa konkrétne zaoberá problematikou meškania letov a sprostredkuje jeho používateľom možnosť pripoistenia sa. Používateľ má teda možnosť poistiť sa proti strate svojho času, a z tejto škodovej udalosti úplne hladko získať určitú províziu. Celá táto automatizácia by však bez Smart kontraktov nebola na blockchaine možná. V rámci dekompozície implementácie sme navrhli jeden hlavný Smart kontrakt, ktorý reprezentuje poisťovaciu spoločnosť, ktorá sa stará o všetky náležitosti ohľadom svojich klientov, poisťovacích zmlúv až po refundovanie poistných udalostí, či manipuláciu so ziskom. Druhou časťou návrhu implementácie bol návrh fabriky na poisťovacie zmluvy, kde sme sa rozhodli že každá jedna vytvorená zmluva bude na blockchaine reprezentovaná samostatným Smart kontraktom. Z toho teda plynie že každá jedna zmluva má svoj vlastný životný cyklus, od jej vytvorenia, uhradenia poplatku, validácie poistnej udalosti až po manipuláciu s obnosom uloženým na konkrétnej zmluve (Smart kontrakte). Nasledujúci diagram konkrétne vizualizuje pokrok, ktorý nám zabezpečili Smart kontrakty, a to prechod od papierových zmlúv ku inteligentným automatizovaným zmluvám, ktoré sú súčasťou decentralizovaného blockchainu.
Na vývoj a nasedenie Smart kontraktov sme použili Truffle rámec implementovaný v jazyku Solidity, ktorý nám poskytol široké rozhranie funkcií na manipuláciu s dátami a udalosťami potrebnými na zabezpečenie nášho zámeru. Nakoľko sú Smart kontrakty do značnej miery uzavreté voči vonkajšiemu svetu a sú plne závislé na blockchaine, a svoje operácie a volania vykonávajú len v rámci daného blockchainu, na ktorom sú nasadené, potrebovali sme v rámci implementácie nájsť riešenie a spôsob ako sa dopytovať na nami vytvorené API. Tieto vzdialené volania, mimo blockchain, boli v našom prípade potrebné k dopĺňaniu informácií o letoch v jednotlivých zvolených časových intervaloch, kedy dochádza k validácii poistnej zmluvy. Túto funkcionalitu sme zabezpečili pomocou knižnice Oraclize, ktorá sa zaoberá a rieši tento problém elegantným spôsobom. Prostredníctvom tejto knižnice sme vo finálnej implementácii zabezpečili vzdialené volanie nášho centralizovaného API, a tým aj získanie informácií potrebných pri validácii poistných udalostí, nakoľko kontrakt po jeho vytvorení obsahuje len základne informácie o danej linke, na ktorú je vytvorená konkrétna poisťovacia zmluva.
Čo ponúkajú Smart kontrakty!?
V širokom zmysle pre náš prototyp Smart kontrakty znamenajú oveľa viac než bolo vyššie popísane alebo viac než sa na prvý pohľad zdá. Nasledujúce podkapitoly, popisujú jednotlivé vlastnosti Smart kontraktov a ich vplyv aj na naše konkrétne riešenie.
Transparentnosť
Všetky údaje uložené v blockchain štruktúrach sú viditeľné, plne transparentné a ich validáciu môže vykonať ktokoľvek a kedykoľvek. Skrývanie určitých poistných skutočností teda z pohľadu našej prípadovej štúdie nie je vôbec možné.
Decentralizácia
Sieť Ethereum, tak ako aj iné blockchain platformy je plne decentralizovaná prostredníctvom jej uzlov a ktokoľvek môže byť jej súčasťou. Do tohto nekonečného virtuálneho stroja je možné nasadiť veľmi efektívne, škálovateľné a stabilné decentralizované aplikácie. Decentralizácia v našom prototype prináša zdieľanie informácií medzi jednotlivými uzlami siete, a preto nie je potrebný vlastný serverový hosting aplikácie.
Efektívnosť a Integrita
Akonáhle sú údaje zapísané do blockchainu, sú trvalé. Editovať ich je možné len prostredníctvom špeciálneho rozhrania, ktoré je definované vývojármi danej distribuovanej aplikácie. Prostredníctvom rozhrania je možné limitovať prístup k zmenám a operáciám nad údajmi uloženými v smart kontraktoch. Spojenie hash adresy kontraktu so spomínaným rozhraním vytvára svojou štruktúrou možnosti správy daného kontraktu uchovaného v blockchaine. Tieto skutočnosti prinášajú určitú úroveň integrity a neporušiteľnosti. Ako už bolo uvedené celá Ethereum sieť je jeden obrovský virtuálny stroj, a všetky zápisy dát a vykonávanie operácií sú spoplatnené tzv. “GAS” poplatkami. Výška poplatkov závisí od aktuálnej hodnoty Éteru na burze a od úrovne optimalizácie implementácie a načasovania operácií. Avšak pri vývoji aplikácií na testovacej sieti sú tieto poplatky fiktívne a fungujú len informatívne a tým pádom poskytujú informácie pre ďalšiu optimalizáciu operácií a samotného kódu kontraktu.
Bezúhonnosť a Motivácia
Smart kontrakty rovnako disponujú vlastnosťami ako je bezúhonnosť, spravodlivosť, či motiváciou k dodržiavaniu naozaj striktných pravidiel, konvencií či štandardov. Všetky údaje ktoré sú uchovávané napríklad v našich zmluvách, musia dosahovať a aj dosahujú určitú vyššiu úroveň dôveryhodnosti v porovnaní s bežnými centralizovanými technilógiam a každá akcia vykonaná nad danou zmluvou musí byť korektne overená z hľadiska tenancie či správnosti. Kľúčovou skutočnosťou je však aj to, že každé automatizované vyhodnocovanie musí byť striktne časovo naplánované.
Komunikácia klienta s blockchainom alebo ako sa zrodil backend
Rozhodovanie ohľadom celej architektúry stavaného riešenia bolo ťažké. Na jednej strane sme chceli zachovať logiku decentralizovanosti systému, no na strane druhej a po počiatočných testoch decentralizovaného riešenia jasne vyplynulo, že takéto riešenie by bolo pre “bežných ľudí” viac ako nepoužiteľné. Problémov, ktoré sa objavili bolo hned niekoľko, počínajúc obrovskou veľkosťou mobilného “light” klienta v násobkoch stoviek megabajtov, cez pomalú synchronizáciu blockchainu pri každom spustení aplikácie končiac nespoľahlivosťou klienta samotného. Ak teda malo byť vytvorené riešenie pre verejnosť a nie len pre skupinku informaticky zdatných, bolo potrebné hľadať inde. Nakoniec sme sa rozhodli pre využitie REST API aj za cenu nie úplnej decentralizovanosti systému.
Web3.js
Backend bol vytváraný pomocou NodeJS s primárnym využívaním funkcií knižnice Web3, ktorá ponúka interakciu s lokálnym alebo vzdialeným ethereum uzlom. Knižnica ponúka množstvo funkcií pre prácu s kontraktmi a počas celej implementácie sme sa nestretli so žiadnym problémom alebo funkciou, ktorá by chýbala.
Problém veľkých čísel
Ethereum má metrický systém denominácií použitých ako jednotky éteru. Každá denominácia má svoje vlastné jedinečné meno. Najmenšia nominálna hodnota, aká základná jednotka éteru sa nazýva Wei.
Ako je možné vidieť z tabuľky vyššie, pri Wei sa narába s veľkými číslami a to nielen celými, no najmä číslami s pohyblivou rádovou čiarkou, ktoré ale javascript nedokáže reprezentovať správne. Tento problém čiastočne rieši samotná Web3 knižnica, ktorá pri narábaní s Wei využíva knižnicu BigNumber.
var balance = new BigNumber('13124.234435346456466666457455567456');
balance.plus(21).toString(10);
// toString(10) skonvertuje výsledok do reťazca čísel, ale môže zobraziť maximálne 20 desatinných miest
// "13145.23443534645646666646" výsledok, ktorý bude skrátený len na 20 desatinných miest
Práve kvôli spomenutému samotní tvorcovia knižnice Web3 odporúčajú stále uchovávať hodnoty vo Wei a transformovať ich do iných jednotiek len keď sú prezentované používateľovi.
Ako vyzerá smart kontrakt
Nasledujúci útržok kódu reprezentuje časť zo smart kontraktu našej poisťovacej zmluvy. Uvedený kontrakt dedí od najzákladnejšieho funkčného kontraktu smart kontraktov Mortal, ktorý v sebe obsahuje funkciu kill() prostredníctvom ktorej je možné kontrakt na blockchaine zastaviť a korektne z neho získať všetky prostriedky. Táto časť kódu sa ale v hlavnom zmysle snaží vyjadriť spôsob zmeny stavu poisťovacej zmluvy, ktorá je súčasťou nášho prototypu. Enumeračný typ na začiatku zdrojového kódu, popisuje možné stavy, v ktorých sa zmluva môže nachádzať. Funkcia getPriceWei() sprostredkuje informáciu o cene poistenia vystavenej na konkrétnu zmluvu a funkcia () označená kľúčovým slovom payable reprezentuje rozhranie sprostredkujúce možnosť uhradenia danej poistky. Následne ak je vyvolaná predchádzajúca funkcia a poplatok za poistku je uhradený, celá zmluva je následne aktivovaná prostredníctvom funkcie activateInsurance() ktorú môže vyvolať len administrátor systému (už spomínaný hlavný kontrakt nášho prototypu). Výsledkom tohto procesu je aktivácia poisťovacej zmluvy a smart kontrakt nadobúda stav Active.
pragma solidity ^0.4.5;
contract Insurance is Mortal {
enum InsuranceContractStatus { Created, Active, OnTime, Late15, Late30, Late45, Canceled, PayOutFailed }
...
function () public payable {}
function activateInsurance() public adminOnly {
require(this.balance >= insurance.priceWei);
status = InsuranceContractStatus.Active;
validateFlightState(insurance.flight.arrival);
InsuranceActivated("Insurance activated successfully");
}
function getPriceWei() public constant returns (uint) {
return insurance.priceWei;
}
...
}
Zdrojový kód kontraktu je pred odoslaním do siete skompilovaný a k nemu je vygenerovaný JSON súbor, ktorý špecifikuje komunikačné rozhranie kontraktu tzv. Application Binary Interface (ABI) používané na následnu komunikáciu a volanie funkcií kontraktu nasadeného v sieti Ethereum. Aplikačné binárne rozhranie je štandardným spôsobom interakcie so smart kontraktami v ekosystéme Ethereum, a to ako mimo blockchainu, tak aj pre interakciu medzi kontraktami navzájom. Údaje sa v kontraktoch vždy zakódujú podľa určeného typu, tak ako je to opísané v tejto špecifikácii. Kódovanie nie je samostatne popisujúce, a preto si vyžaduje schému na dekódovanie.
Klientská mobilná aplikácia
Komunikácia s distribuovanou blockchain aplikáciou nie je v súčasnosti používateľský najprívetivejšia. Distribuované webové aplikácie vyžadujú nainštalovanie doplnku MetaMask do webového prehliadača. Našim cieľom bolo pripraviť pre používateľa také rozhranie do systému, ktoré by sa nijako neodlišovalo od klasických aplikácií a skryť pred používateľom čo najviac zložitých prvkov blockchainu. Práve preto sme siahli po natívnej mobilnej aplikácii. Platforma Geth poskytuje knižnice pre systém Android aj iOS. My sme zvolili iOS v kombinácii s jazykom Swift kvôli skúsenosťami, ktoré už s touto platformou máme. Problémom ale bolo, že knižnica Geth mala takmer nulovú dokumentáciu a preto nasledovali experimenty a analýza akýchkoľvek dostupných mobilných projektov na GitHub-e využívajúcich platformu Ethereum.
Mobilný “Light client”
Ako sme už spomenuli pri prvotnom návrhu systému sme chceli dosiahnuť úplnú decentralizáciu a vyskúšali sme tzv. light client knižnice Geth. Pomocou neho sa môže samotná aplikácia, teda smartfón stať uzlom (Node), ktorý je priamo pripojený do siete Ethereum. To umožňuje pripájať sa a priamo komunikovať s rozhraním distribuovanej aplikácie.
Toto riešenie má ale značnú nevýhodu. Pri spustení sa Node musí zosynchronizovať so sieťou a teda stiahnuť si všetky dáta. Tento proces aj napriek rýchlemu pripojeniu vyše 30 minút a zabral vyše 800MB pamäte. Akákoľvek komunikácia s distribuovanými aplikáciami je možná až po úplnej synchronizácii. Táto alternatíva teda nebola vhodná pre naše riešenie a práve preto sme zvolili REST rozhranie. Naším cieľom bola čo najväčšia bezpečnosť platby a vykonanie všetkých citlivých operácii priamo v klientskej aplikácii bez odosielania súkromného kľúča Ethereum peňaženky na server.
Ethereum peňaženka
Používateľ je v našom systéme identifikovaný pomocou adresy Ethereum peňaženky. Peňaženku je možné vytvoriť rôznymi spôsobmi, či už na niektorom z webov učených na nákup kryptomien ako napríklad Coinbase alebo nami používaný web MyEtherWallet.com.
Použitá knižnica Geth umožňuje peňaženku importovať dvoma spôsobmi:
- pomocou zaheslovaného JSON súboru
- alebo priamo pomocou privátneho kľúča.
V aplikácii sme implementovali obidva spôsoby importu. Import pomocou JSON súboru ale nie je až tak jednoduchý a to kvôli uzavretiu iOS aplikácií do tzv. sandboxov. To znamená, že aplikácie môžu narábať iba s vlastnými súbormi a nevedia priamo čítať súborový systém ako v prípade operačného systému Android. Pre nás to znamená, že používateľ nemôže zvoliť JSON súbor v aplikácii ale je potrebné aby nad súborom zvolil možnosť otvoriť v aplikácii TrustAir.
Import pomocou privátneho kľúča je oveľa jednoduchší. V aplikácii sme použili natívny skener QR kódov a používateľ teda nemusí kľúč vpisovať ručne. QR kód je možné vygenerovať priamo na stránke MyEtherWallet.com.
Import účtu je nevyhnutný pre používanie našej aplikácie. Slúži na zaplatenie každého poistenia zakúpeného v našej aplikácii a takisto na vyplatenie prípadného poistného plnenia.
Pri každom nákupe je potrebné peňaženku odblokovať. Počas procesu importu má používateľ možnosť aktivovať použitie funkcie TouchID (ak ním zariadenie disponuje) a teda používať na odblokovanie peňaženky otlačok prstu. Pri zvolení tejto možnosti je heslo na odblokovanie peňaženky uložené do Keychain (kľúčenky) zariadenia a automaticky aplikované pri overení pomocou TouchID. Keychain slúži na bezpečné uloženie citlivých dát ako napríklad hesiel či certifikátov v systémoch iOS a macOS.
Proces nákupu - pohľad používateľa
Aplikácia ponúka nákup poistenia zvlášť pre daný let. V prvom kroku používateľ zadá rezervačné číslo letenky (booking reference), číslo letu a dátum letu. Na základe toho systém overí a vyhľadá daný let. Rezervačné číslo letenky slúži na potvrdenie toho, že zákazník má na daný let letenku skutočne zakúpenú aby sa predišlo zneužívaniu systému. Systém na základe toho vyhľadá a spätne vráti daný len na potvrdenie používateľom. Po potvrdení systém pomocou algoritmu vypočíta 3 cenové ponuky poistenia. Každá ponuka má inú nákupnú cenu a od nej odvíjajúce sa ceny plnenia.
Po zvolení ponuky je potrebné poistenie zaplatiť. Na to slúži už spomínaný importovaný Ethereum účet. Peňaženku môže používateľ odomknúť pomocou TouchID alebo zadaním hesla. Po potvrdení nákupu sa poistenie automaticky vytvorí, zaplatí a aktivuje.
Behind the scenes (ako prebieha proces nákupu z technologickej stránky)
Poďme sa pozrieť na to, čo sa v systéme udeje po potvrdení nákupu. Keďže každá poistka je samostatný smart kontrakt, prvým krokom je vytvorenie tohoto kontraktu. Aplikácia teda požiada server o jeho vytvorenie a zapíše doňho všetky potrebné údaje ako adresa peňaženky zákazníka, ceny ponuky a informácie o lete. Server vráti adresu daného kontraktu, ktorý je zatiaľ v stave čakajúci na platbu.
Nasledujúci krok je zaslanie platby na adresu vytvoreného kontraktu. Platba taktiež pozostáva z podkrokov. Najprv je potrebné vytvoriť tranzakciu pomocou použitej knižnice Geth. Nato aby mohla byť tranzakcia spracovaná na serveri a nie priamo v zariadení je nevyhnutné použiť raw tranzakciu. Do tranzakcie je potrebné zadať cieľovú adresu, sumu, maximálne množstvo Gasu a cenu Gasu. Od nastavenia Gasu závisí ako rýchlo sa tranzakcia vykoná. Nájsť optimálnu hodnotu a zároveň neplatit vysoké poplatky nie je jednoduché. Viac k tejto problematike sa môžete dočítať v článku Calculating Costs in Ethereum Contracts. Keďže sa jedná o raw tranzakciu je potrebné zadať aj číslo nonce. Nonca je vlastne nasledujúce číslo / poradie odchádzajúcej tranzakcie z daného účtu a je potrebné ju získať zo siete. Na serveri teda máme endpoint, ktorý nám požiadavku na zistenie nonce sprostredkuje volaním potrebných web3 rozhraní nad sieťou Ethereum.
Po vytvorení tranzakcie je potrebný jej podpis. Ten sa vykoná taktiež pomocou funkcie z knižnice Geth po odomknutí účtu. Podpis je vykonaný pomocou privátneho kľúča danej peňaženky.
Problémom pri použití RAW tranzakcie je fakt, že pokiaľ používateľ vykonáva v tú istú chvíľu aj nejakú inú odchádzajúcu tranzakciu je použitá rovnaká nonca. Stane sa teda že týchto 2 tranzakcií bude sieťou akceptovaná iba jedna a druhú je potrebne vytvoriť nanovo s novou noncou. My sme ale museli použiť RAW tranzakciu aby mohla byť tranzakcia podpísaná priamo v zariadení a nebolo potrebné odosielať súkromný kľúč používateľa mimo zariadenia.
Po podpise sa tranzakcia odošle na server na vykonanie. Úspešnosť vykonania nie je istá a preto je kontrakt stále v čakajúcom stave. Keď sieť prijme požiadavku na vykonanie tranzakcie, náš systém prejde do stavu overovania, kedy priebežne overuje či už bola daná tranzakcia zrealizovaná. Rýchlosť zrealizovania tranzakcie závisí od vyťaženosti siete a výšky ponúkaného Gasu.
Po úspešnom overení tranzakcie systém kontrakt aktivuje. Ten sa potom v naplánovanú dobu snaží overiť stav letu a na základe toho vyplatiť prípadné plnenie. O ukončení kontraktu je používateľ informovaný pomocou notifikácie, ktorá v klientskej aplikácii spustí zobrazenie detailu výsledku poistenia.
V našom prototype sme mali informácie o demo letoch uložené priamo v databáze, keďže letové dáta nie sú voľne prístupné. Produkčná verzia produktu si teda ešte vyžaduje nájsť poskytovateľa leteckých dát pre kontrolu stavu letov.
Lokálne dáta
Aplikácie okrem vytvárania poistenia ponúka aj bohaté štatistické prehľady. Všetky zobrazované dáta sú získavané zo smart kontraktov pomocou nášho API. Na lokálne udržiavanie tranzakcií a dát je použitá mobilná objektová databáza Realm.
Financovanie
Ku každému poisteniu neodmysliteľne patria aj ceny za ktoré sa toto poistenie bude ponúkať. Určiť výšku poistenia a teda aj následne sumu pri odškodnení za meškanie alebo dokonca zrušenie letu nie je vôbec také jednoduché ako sa na prvý pohľad zdá.
Chcem sa poistiť
Pri určovaní cien je potrebné zohľadniť výšku poistenia konkurencie, hodnotenia jednotlivých letov, ich prípadne meškania z pohľadu leteckých spoločností, myslieť na vysokú pravdepodobnosť meškania letov v zime, pri nepriaznivom počasí a mnoho ďalších faktorov. Jednotlivé ceny poistenia sa preto musia neustále prispôsobovať konkurencii, aktuálnej situácií na trhu, počasím či hodnotením letu.
Pre hodnotenie letov sme v prípade našej aplikácie používali voľne dostupné dáta zo stránky FlightStats ktorá ponúka históriu letov za posledné 3 mesiace. V budúcnosti nevylučujeme použitie vlastných získaných dát ako aj použitie iných zdrojov priamo od leteckých spoločností.
V prvom kroku bolo potrebné zvoliť jednotlivé typy poistenia aby sme vyhoveli bežným občasným cestujúcim ako aj náročným business klientom. Ponúkame 3 typy poistenia ktoré je možné si vybrať priamo v aplikácií pred zakúpením poistenia. Najnižší variant “Economy“ je cenovo dostupné poistenie ktorého základná suma sa vypočítava z 15% ceny letenky. Táto suma je ešte následne prepočítaná hodnotením daného letu. Stredné poistenie “Standard“ a najvyššie “Business“ sú ekvivalentom pre 20% a 30% z ceny letenky.
Čo ak let mešká
V prípade meškania letu ma zákazník nárok na odškodnenie ktoré je vyplácané v závislosti od dĺžky meškania popr. úplného zrušenia letu. Ponúkame 4 typy odškodnenia:
- meškanie viac ako 15 minút
- meškanie viac ako 30 a menej ako 45 minút
- meškanie viac ako 45 minút
- úplne zrušenie letu
Základná suma vyplácaná pri meškaní viac ako 15 minút je dvojnásobok sumy poistenia, trojnásobok pri meškaní viac ako 30 minút, štvornásobok pri meškaní viac ako 45 minút a až 20-násobok ceny poistenia pri úplnom zrušení letu.
Ďalším krokom bolo prehodnotenie jednotlivých cien odškodnenia v prípade meškania podľa hodnotenia letov. Pre let ktorý ma 40% šancu na meškanie 15 minút nemôžeme ponúknuť rovnakú sumu odškodnenia ako pre let ktorý má pravdepodobnosť 5% pri rovnakom meškaní. Preto sme od základnej ceny vypočítanej podľa vzorca odpočítali sumu ktorá bola vypočítaná podľa hodnotenia daného meškania. To v praxi znamená že čím horšie hodnotenie letu, tým nižšie odškodnenie. Výpočet odškodnenia v prípade meškania viac ako 30 minút vyzerá nasledujúco:
Delay30 = ( PriceOfInsurance * 3 ) - ( ( (PriceOfInsurance * 3 ) - PriceOfInsurance) * Late30 / 100 )
Kde PriceOfInsurance je cena základného poistenia a Late30 je percentuálne hodnotenie meškania letu viac ako 30 minút.
Ešte niečo naviac
V našom prípade však treba počítať že overenie transakcií sa vykonáva pomocou blockchain technológie a to niečo stojí. Preto bolo potrebné pripočítať cenu za overenie transakcií k cene poistenia. Výška tejto sumy je ovplyvnená aj od času za aký sa transakcia overí. V konečnom dôsledku to znamená nárast ceny poistenia aj samotného odškodnenia pri meškaní alebo zrušení letu.
Profit
Samozrejme je možné zahrnúť na tieto výpočty aj veľa ďalších faktorov, no pre naše použitie sme zatiaľ využili tieto. Pre výpočet business modelu sme použili dáta z roku 2016 a zobrali do úvahy 0,01% celkovo prepravených osôb v leteckej doprave ktorý by naše poistenie využili. Ako modelový let nám poslúžil OS713 z Viedne do Budapešti. Celkový ročný odhadovaný profit bol od 6 miliónov eur v prípade najnižšieho poistenia až do 16 miliónov eur pri najvyššom business poistení.
Možné právne obmedzenia
Technológia blockchain, ktorú sme v našom projekte použili, má inovačný potenciál vo všetkých oblastiach finančných služieb. V poisťovníckom sektore investovali do aplikácií založených na blockchaine veľké tradičné poisťovne ako je AXA alebo Generalli. Napriek tomu dnes existuje len veľmi málo projektov, ktoré by sa venovali práve poisťovníctvu a vytváraniu inteligentných zmlúv. Samotná implementácia bola preto veľkou výzvou. Keď sa nám podarilo vytvoriť prototyp, ktorý spĺňal nami zvolenú funkcionalitu, začali sme sa zamýšľať nad zapojením projektu do reálneho života a prípadnom obchodnom pláne. Na riešení bolo potrebné plne pochopiť nie len výhody tejto technológie ale hlavne obmedzenia a prekážky, ktoré by pri reálnom používaní aplikácie mohli vzniknúť.
Ako zdaniť Ether?
Transakcie, ktoré sa pomocou blockchainu vykonávajú sú v kryptomene Ether. Tieto transakcie sú oproti klasickým peňažným transakciám oveľa rýchlejšie a bezpečnejšie. Veľkým otáznikom nie len na Slovensku je, ako potenciálne príjmy vypočítať a zdaniť. Je ich vôbec potrebné priznávať?
- Príjem či výnos prijatý v inej mene ako EUR je potrebné prepočítať na EUR a to oficiálnym kurzom Európskej centrálnej banky : V našom prípade by bola teda mena príjmu Ether. Vzhľadom na fakt, že štáty ani národné banky kryptomeny neuznávajú, takýto kurz neexistuje. Existuje len trhový kurz, ten sa však nemení jedenkrát za deň (ako tie oficiálne kurzy), ale každých pár sekúnd. Slovensky právny systém neupravuje žiaden zákon pre virtuálne meny a preto musíme pracovať s tým čo máme. Riešením je buď platobná brána, ktorá by nám posielala lokálnu menu alebo tieto príjmy účtovať ako nepeňažný finančný majetok.
- Postačí výpis z elektronickej peňaženky ako doklad? : Tento doklad musí obsahovať údaje kto, komu, čo, kedy a začo. Mal by teda obsahovať účastníkov, obsah, dátum vyhotovenia a sumu. Vzhľadom na fungovanie tejto siete neobsahuje elektronická peňaženka žiadne označenie účastníkov obchodu ani iný slovný údaj, nehovoriac už o variabilnom symbole či iných párovacích údajoch.
Zhrnutie
Tento projekt bola naša prvá skúsenosť s platformou Ethereum ako aj s blockchain technológiou samotnou. Technológia je to pomerne mladá a informácií potrebných pri riešení problémov je stále málo. Ako je aj možné z článku vyčítať, narazili sme na množstvo problémov počas tvorby nášho prototypu. Jednalo sa či už o otázky z oblasti návrhu, implementácie, ale aj právnej, či finančnej oblasti. Počas implementácie riešenia sme častokrát narazili na bod, kedy sme zistili že to čo sme si navrhli sa nedá pomocou platformy Ethereum implementovať a museli sme hľadať alternatívnu cestu. Produkčne nasadených riešení je takisto zatiaľ málo, no jedná sa o technológiu, ktorá ma veľký potenciál v IT priemysle a jej popularita bude rásť.
Ak sa Vám Ethereum platforma zapáčila a máte nápad, ktorý by ste chceli pomocou nej zrealizovať netreba sa toho báť. Prvým najdôležitejším krokom je ale overiť si, či je možné daný problém pomocou platformy Ethereum implementovať. Potom už stačí len hľadať tutoriály, študovať dokumentáciu a hlavne prezerať implemetnáciu open-source projektov. Distribuovaných blockchain projektov je málo a je teda ľahké s dobrým nápadom vyniknúť.