1. Rhyno Smart City
Platform
Nagymajtényi Gábor – 2018.01.23.

2. Fejlődés: Internet2, Web4
● Web1 – Prospektus
● Web2 – Interakció
● Web3 – Együttműködő ( service, microservice )
● Web4 – Smart
– embedded eszközök
– connected tools, connected people ( IoT + IoP =
IoE )
– determinisztikus algoritmusok mellett megjelenik
a ML,AI

3. Mi a „Smart City”?
● Komplex, együttműködő, okos
alkalmazások és okos
infrastruktúrák
● Smart Home-ok és Building-ek,
amikben Smart Familyk élnek
● A Smart Familyk Smart
infrastruktúrákat használnak
– Közlekedés, logisztika
– Víz, gáz, csatorna, internet
– Hulladék-kezelés
– ...
● Smart Gardenek
Transport
Governance
Education
Food,
Water
Health
Social
Security
Entertainment
Sport,
well-being
Smart Grid
Utilities
Environment

4. Miért Smart?
● M2M → IoT → Smart*
● Auto configuration
● Service-2-service interoperability
● AI ( not supervised, agile, evolving ) algorithms
● UX new interfaces ( sense , control )
● Big Knowledge, not Big Data
● Autonom smart agents and actors

5. Miért „kritikus infrastruktúra”?
1
2 3
4
5
6
7
8
10
9
1. A műholdas kommunikáció leállhat
2. Az épületek áramellátása megszűnhet
3. Az olajkitermelés leállhat
4. A vasúti jelzőrendszer meghibásodhat
5. Vízszennyezés történhet
6. Elektromos energiaellátási problémák merülhetnek fel
7. Az üzleti kommunikáció megbénulása
8. Légkondicionáló rendszerek leállhatnak
9. Mobiltelefon hálózati hiba lehetséges
10. Gázellátási problémák jelentkezhetnek

6. Nemzetközi verseny
● Technikai lemaradásban van Magyarország
– Nincs hardver gyártás
– Nincs meghatározott fejlesztő cég a beágyazott és biztonságos
rendszerek piacán
– Technológiai lemaradás 10+ év, a jelenlegi IT cégek „box-moverek”,
nincs hozzáadott-értékteremtés
– Mindenki Web-alkalmazás fejlesztő lett, az alkalmazás infrastruktúrát
külföldi technológia adja
● Protekcionista piacvédelem az EU-ban
– Hollandia → Phillips
– Dánia → Grundfos
– Németország → Siemens
– Svédország → Ericsson
– Finnország → Nokia

7. Pénzügy, tranzakciós sebesség
● Magyar banknak gondot okoz a 200 tps maximális
terhelés => A teljes magyar pénzügyi szektor összes
tranzakciója nem haladja meg a 10,000 tps-t.
● A Prompt Payment (SEPA2) elvárása, hogy 5 sec alatt
legyen tranzakció elvégezve.
● A teljes Visa/Mastercard globális tranzakciós rendszer
750,000 tps-t tud.
Rhyno-t úgy terveztük, hogy 1Mtps-nél többet
tudjon kezelni.

8. Autonóm közlekedés
● Az autonóm járművek ~2Gbps képi információt
dolgoznak fel. Ha egy országban van 1m autonóm
jármű, és ezt egy cloudban szeretnék feldolgozni,
akkor az 2Tbps feldolgozást igényelne, és a latency
nem haladhatja meg a 200ms-et ( a lassú emberi
reakció idő 0,8-1 sec )
● A döntést nem lehet cloudban hozni ( túl lassú,
sérülékeny és roppant költséges )
Rhyno-t úgy terveztük, hogy a node képes
legyen lokálisan dönteni

9. e-ticket
● A RIGO-nál az EBRD hitel követelménye, hogy a világ első Pay-as-You-Go
rendszerét alakítsuk ki. A világon nincs még hasonló (postpaid) rendszer
– Check-in/Check-out és az utazás alatt a sessiont kell kezelni
– Utasbiztonsági okokból a kapukon egy utasnak kevesebb, mint 1 sec alatt
át kell mennie
●
nem lehet megvárni az 5 sec-es prompt paymentet.
●
Check-out: a teljes út árazása , és a fizetése
●
A turistáknak nincs saját terhelhető accountja a rendszerben
●
Az árazásra és a fizetésre van kb 100-100ms ( a fizikai ajtónyitásra is
kell idő, a kártya leolvasásra, írásra )
● Nincs az a tranzakciós rendszer, ami ezt központilag képes kezelni ( hétfő reggel
2m utas egy óra alatt ).
Rhyno decentralizált network, lokálisan kezeli a
tranzakciót, minden jármű egy node. Idén
prototípus készül Mexikóban.

10. Jelen állapot, M2M silók
● Különálló M2M eszközök
● Vertikális „siló” alkalmazások
● Valójában „távmenedzsment”
● Ugyanazok a funkciók ismétlődnek
● Nincsenek iparági szabványok
● Az alkalmazások nem integrálódnak
● Változáskezelés lassú, költséges üzemeltetés
– Minden alkalmazásra külön-külön

11. Integráció – Felület
● Kormányablak
● Egy képernyőre „rakjuk” az összes alkalmazást
● A back-office folyamatok különállók maradnak
UI
Process
Data
A alkalmazás
UI
Process
Data
B alkalmazás
UI
Process
Data
C alkalmazás
Egy képernyő

12. Integráció – Folyamatok
● Folyamat integráció, API-k , szabványok, szemantika
● Az adott rendszer fejlesztői gyorsan és hatékonyan
tudnak integrálni
UI
Process
Data
A alkalmazás
UI
Process
Data
B alkalmazás
UI
Process
Data
C alkalmazás
Interoperábilis
Folyamatok

13. Integráció – Adat
● Soha nem készül el - NISZ
– nincs egységes adatmodell, adattisztítás lehetetlen
● Adatbiztonsági problémák ( Big Data )
UI
Process
Data
A alkalmazás
UI
Process
Data
B alkalmazás
UI
Process
Data
C alkalmazás
Adatingtegráció
Konszolidáció

14. Bottom-up infrastruktúra
● Top-down: minden szinten felülről kell lebontani az adott szintre a rendszert –
minden lépés hosszú idő. ( Közmű hálózat – évtizedek alatt épült ki )
● Bottom-Up: sikeres Proof-of-Concept után minden „node” párhuzamosan egy
lépésben bevezethető ( decentralizált hálózatok, folyamatosan lehet node-okat
adni hozzá, a hálózat „robbanás-szerűen” nőhet )
● Minden hálózatban a legdrágább a „last-mile”

15. Spoke-and-Hub
● Úthálózat ( 1910-től - autóút/autópálya )
● Közmű hálózatok ( 20. század )
● Légiközlekedés ( 1960 check-in/check-out – biztosítási események )
● Bankrendszer ( 1964 digitálisan BSP fájlok)
● Indiai vasút ( 1972 , IBM )
● Internet ( ~1980 Tier-ek)

16. Smart City megoldás elvárások
● Biztonságos
● Megbízható, robusztus
● Folytonos működés ( HA, Continuous operation )
● Decentralizált
● Döntések gyorsan, helyben
● Együttműködő ( integrált ) alkalmazás és szolgáltatási környezet ( microSCADA-k )
● Gyors
● Skálázható
● Jogosultság és privacy kezelés
● Könnyen bővíthető, változtatható
=> Platform, ami képes megteremteni az „okos alkalmazás
integrációt”, RAGASZTÓ

17. Smart City Platform elvárásaink
Jelenlegi blockchain platformok tudják
● Megbízható
● Biztonságos ( algoritmikusan, de a kódminőség gyatra )
● Decentralizált => Döntések helyben
● Homogén technikai node-ok
● Smart contractok
Jelenlegi blockchain platformok nem tudják
● Gyors
● Skálázható
● Jogosultság ( authentikáció, authorizáció )
● Jó minőség
● Heterogén üzleti node-ok
● Megbízható smart contractok

18. Platform verseny
● Bittorrent, Ethereum
– trustless, permissionless, nem skálázódik, lassú fejlesztés: 100+ md usd, nincs
ipari megoldás évek óta
● IOTA
– Rossz kódminőség, megbízhatatlan, unsecure: 1,7md usd értékben
● Tezos
– összeomlott a konszenzus, egy ember kezében az erőforrások nagy része, a
delegate business összedőlt
● Emotiq
– 11m USD ICO, jó célok, fizikusok, késnek minden ígéretükkel ( Rhyno jobb
architektúra )
● Arpa
– kínai startup, ZK és homomorf crypto, nincs még blockchainjük, de sajátot
akarnak építeni, nemet mondtak nekünk: nagyon erős crypto szakértelem!
● Egyik jelenleg elérhető platform sem alkalmas Smart City Platformnak
● Magyarországon a Rhyno-n kívül nincs Platform fejlesztő! Mindenki az előző
platformokon alkalmazást fejleszt.

19. Rhyno Platform alapvetései
● Valós üzleti és fizikai folyamatok támogatására alkalmas
platform
● A valós élet folyamatai „trustfull”-ok ( szerződéseken
alapulnak ), a valós élet hálózatai heterogének
– a jelenlegi blockchain hálózatok trustless-ek
– homogén node-jaik vannak → nem skálázódnak
● Alternatív megoldások közül mindig a legalacsonyabb
energiájút választjuk ( fizikai rendszerek hosszú távú
stratégiája )

20. Platform gondok, Rhyno megoldás
● Hogyan integráljunk heterogén alkalmazásokat?
– Smart Contract ( alkalmazás és adat is egyben )
● Nem jó a kódminőség
– CI/DevOps – Saját megoldást készítünk saját HA/Perf tesztrendszerrel ( decentralizált
agentekkel )
– Teljes teszt toolchain → Unit, Functional, Integration, HA, Perf , Stress testing + UAT
● Crypto nem erős
– Nem kvantum-proof : a smart home-nak 10+ évig „feltörhetetlen” algoritmusokkal
kell dolgoznia
– Rhyno: Node2Node strong crypto
– Rhyno: Device2Node crypto ( AES256 + pár huncutság )
– Verified Random
● Smart Contract nyelvek nem ellenőrizhetők, informális és formális gap
– Formálisan nem verifikálhatók → Rhyno Language – Panda ( Coq verifikálható )
– Statisztikailag nem tesztelhetők → Panda cgall compliant → SPIN tesztelhető
– Smart Contract MINDEN : nyelv, hálózat, program, adat
● Lassú
– Saját consensus-ok ( smart contract configurált ): egy node-on 300,000 TPS
● Skálázható

21. Smart City Platform architektúra
● Trusted ( business ) network
– node2node communication permitted by smart contract
● Components
– Nodes
●
Rhyno VM – Smart Contracts
●
Node-2-Node communication ( cModule )
●
NodeDB/FS ( decentralised DB, Bittorent FS )
●
Applications ( Smart Contracts integrated aModule )
– Devices
●
DeviceDB ( light NoSQL )
●
Device-2-Node communication, light but strong crypto
●
Device IoT app ( sensor data collection,
actuator/controllers commands )
– Meta services
●
Content addressed metastorage
●
Aggregation Node-s definded by Application or Platform
Smart Contracts
● Heterogen nodes
– platform functions are identical on the nodes
– heterogen business functions ( *api-s, app and user smart
contracts and, applications )
● Crypto
– Quantum resistance

22. Rhyno Panda nyelv
● Panda az Ethereum2-höz fejlesztett Bamboo
nyelv továbbfejlesztett, kiterjesztett
változata
– Formálisan verifikálható ( Coq)
– SPIN teljes állapot tér verifikációja
● Compiler fordítja „natív” kóddá.
– compiler és a VM kész
● <= a 42. Fibonacci számot kiszámoló
program, amit 0.002 másodperc alatt
számolt agép ki, ezzel megelőzve a gcc -o 1
sebességét.
● A futási sebességből látható, hogy az
egyetlen „bottleneck” a hálózat lehet

23. Rhyno Panda IDE
● Senkit nem kötelezünk
arra, hogy kézzel írjon
Assembly kódot.
( bár azt felvesszük , aki
képes rá )
● Készül egy interaktív,
korszerű web IDE,
ahonnan a teljes
fejlesztés menete
menedzselhető
● A Panda nyelv intenzív
tesztelése folyik.

24. Rhyno Panda modularitás
● A modularitást tárolható és remote
hívható smart contractok
biztosítják.
● Egy kód bármikor mondhatja azt,
hogy ő innentől egy teljesen másik
contract, ekkor tárolásra kerül, kap
egy memóriacímet és a
későbbiekben ezen keresztül
bármikor elérhető lesz.
● Teljes frameworkök írhatók úgy,
hogy egy közös contractban
elmentik a funkcionalitásukat.

25. Rhyno Panda API
● A modulok kintről ( API ) –
autentikáció után – hívhatók, egy
egyszerű RPC API-n keresztül.
● Ezzel nagyon könnyű integrációt
teszünk lehetővé, ahol egy kezdő
„handshake” után bármilyen eszköz
részt tud venni a kommunikációban.

26. Rhyno Platform státusz
● 2018
– Csapat
– Fejlesztési környezet
– Teszt infrastruktúra
– Technológiai kutatás kész v1-hez
– Proof-of-conceptek, modul prototípusok elkészültek
– Node modulok integrációja történik
● 2019 terv
– Két alkalmazás elkészítése, bevezetése
– Entelor Smart City Prototípus elkezdése
– Termékek, szolgáltatások ( Deal.Services, SMark2, DataGate, … )
– Külső fejlesztőknek a platform biztosítása, integráció

27. Köszönöm
a figyelmet!
Kérdezzenek bátran!