15.2.2020
//Huom! Iotan teknologinen roadmap ja visio on osin muuttunut tekstin kirjoitushetkestä. Tätä tekstiä ei ole päivitetty, joten teksti saattaa sisältää selvästi vanhentunutta ja täten virheellistä tietoa. Suunnitelmana on päivittää teksti, kun aikataulu sallii. Kiitos ymmärryksestä.//
Tämä teksti pohjaa edellisiin ja on suositeltavaa lukea ainakin Iotan perusteet kirjoitussarja, sekä mielellään myös Ethereum analyysi jossa käydään myös yleisesti hajautetun laskennan perusperiaatteita läpi.
Teksti pyrkii antamaan karkeaa kuvaa projektista ja todennäköisesti sisältää pieniä virheitä/yksinkertaistuksia.
Taulukko1. Yksinkertainen yleiskuva Qubic projektista
Qubic on hajautettun laskennan protokolla johon sisältyy myös datavirtaan pohjaava laskentamalli ja tähän malliin suunniteltu hardwate malli.
Hajautetun laskennan protokolla
Vastaa osin muiden kryptovaluuttojen "smart contract" järjestelmiä. Toisin kuin esim. Ethereumissa, Qubic protokolla rakentuu toiseen tasoon Iotan Tangle-verkon päälle, eikä ole siihen suoraan linkitetty. Suurin ero esim. Ethereumiin on että siinä että Ethereumin smart contractit laskee jokainen verkon tietokone, Qubic protokollassa laskevat tahot muodostavat ryhmiä samanlaisten laitteiden kanssa ja laskentaa tilaava taho valitsee ryhmän joka toteuttaa laskennan (mm. smart contractit) hänen kannaltaan edullisimmin. Ostaja voi valita ryhmän haluaminsa kriteereiden perusteella, esim. laskennan hinta, luotettavuus, nopeus etc. Hajautetun laskennan protokollan kehitys on tällä hetkellä aika suurelta osin erillään laskentamallin (QCM) ja hardwaren kehityksestä, mutta kaikki rakennetaan niin että jatkossa eri tasot ovat yhteensopivia. Suurin lyhyen tähtäimen hyöty on selvästi hajautetun laskennan protokollasta ja projektin muut osat antavat hyötyä pidemmällä aikavälillä, mikäli toimivat kuten oletetaan. En vielä ole törmännyt yhteenkään kryptovaluuttaan jossa olisi mukana laskentamallin tai hardwaren kehitystä, (voi ajatella myös bonuksena projektille).
Ensimmäinen hajautetun laskennan (smart contract) protokollan karkea versio (MVP) toteutetaan Iotan testiverkon Goshimmerin päälle. Koska GoShimmer on testiverkko ei ensimmäinen versio vielä mahdollista todellisten Iotojen siirtoa. Toisaalta Hornet (= Iotan pääverkon Go:lla ohjelmoitu nodeohjelma) jakaa suurelta osin saman koodin (hive.go) kuin GoShimmer joten smart contractien yhdistäminen Hornettiin ja sitä kautta pääverkkoon ei pitäisi olla kovin vaikeaa, mikäli pääverkossa tehdään tarvittavat protokollan muutokset. Lopulta kuitenkin Qubic on tarkoitettu Coordiciden jälkeiseen aikaan ja on todennäköistä että jatkossa Iotan engineering team kirjoittaa Qubic ohjelmistot uudestaan Bee:lle. (Bee on tuleva Iotan pääverkon node-ohjelmisto joka on modulaarinen ja erittäin viimeistelty ja tehokkuudessa optimoitu.)
WASM = WebAssembly, Siinä missä Ethereum käyttää omaa Ethereum virtual machine koodin pyörittämiseen, Qubic hajautetun laskennan protokolla käyttää ainakin toistaiseksi WebAssembly:ä. Tässä lyhyt kuvaus: WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications. WebAssembly (often shortened to Wasm) is an open standard that defines a portable binary-code format for executable programs, and a corresponding textual assembly language, as well as interfaces for facilitating interactions between such programs and their host environment. The main goal of WebAssembly is to enable high-performance applications on web pages, but the format is designed to be executed and integrated in other environments as well. WebAssembly became a World Wide Web Consortium recommendation and, alongside HTML, CSS, and JavaScript, it is the fourth language to run natively in browsers.The World Wide Web Consortium (W3C) maintains the standard with contributions from Mozilla, Microsoft, Google, and Apple.
HLL = High level language, koodikieli jolla ohjelmoidaan smart contracteja Qubic:issa. Tätä ei kirjoitushetkellä ole vielä kehitetty.
Runtime API = Ympäristö jossa koodikieli toimii, tämän eri osa-alueita on hiottu pitkään ja kehitys on ilmeisesti jo kohtalaisen pitkällä. Tämä sisältää mekanismit joilla mm. laskijat muodostavat ryhmiä, laskentaa tilaava taho löytää sopivan ryhmän, päästään sopuun hinnasta laskijoiden ja tilaajan välillä, välitetään laskettava tehtävä laskijoille, laskijat laskevat tuloksen, määritetään onko tulos luotettava, palkkio maksetaan laskijoille mikäli tulos on luotettava, estetään protokollan huijaus, etc. Ajatuksena on että vain pakolliset asiat kulkevat Tanglen kautta (kuten valuutan siirto). Suuri osa kommunikaatiosta kulkee vain niiden kautta jotka laskentaan tai sen tilaamiseen osallistuvat. Näin myös viestin välittämiseen kuluvaa energiaa ja kuluja minimoidaan. Yksistään Qubicin tapa tehdä hajautettua laskentaa pienemmissä ryhmissä ilman hardware-, tai laskentamallin innovaatioitakaan tekee hajautetusta laskennasta joitain kertaluokkia energiatehokkaampaa ja halvempaa verrattuna esim. Ethereumin kaltaisiin protokolliin.
Low level runtime functions = HLL muutetaan yksinkertaisiksi komennoiksi joita virtual machine pyörittää.
QCM = Qubic computational model
Laskentamalli joka perustuu dataflow malliin ja LUT taulukoihin. Yksinkertaisesti asia löytyy selitettynä täältä, ja tämä kannattaa oikeasti lukea:
En kertaa kaikkia QCM periaatteita tässä ja loppuosa tekstistä olettaakin että lukija on lukenut yllä olevan blogpostauken QCM perusperiaatteista.
Monimutkaisempi kuuden blogipostauksen mittainen selitys löytyy täältä, jota voi yrittää lukea jos todella haluaa asiaan vihkiytyä:
Huom! Molemmat ovat vanhoja kuvauksia mallista ja parhaillaan valmistellaan selvästi päivitettyä ja huomattavasti tarkempaa opasta QCM:sta, sekä siihen liittyvästä koodikielestä Abra/Qupla.
HDL = Hardware description language
Abra/Qupla muodostavat ohjelmointikielen jolla kuvataan miten rakennetaan logiikkapiirejä, eli miten sähkö kulkee sirulla. Ne ovat siis hyvin hyvin alkeellisia kieliä. Abra kuvaa sitä miten QCM toimii ja sisältää sen miten data virtaa piirissä, ja miten laskentamallissa oleelliset LUT taulukot toimivat, se ei kuitenkaan itsessään sisällä minkäänlaista koodikieltä.
Qupla on Abra perusteella rakennettu koodikieli joka pohjaa viiteen perusfunktioon joista rakennetaan tavanomaisessa ohjelmoinnissa tutut funktiot kuten +, -. Qupla:lla voi periaatteessa ohjelmoida mitä tahansa tavanomaisia ohjelmia.
Turing incomplete? Turing complete tarkoittaa että kieli sisältää kaikki tavanomaisessa ohjelmoinnissa tarvittavat käsitteet ja sillä voi periaatteessa ratkaista minkä tahansa tavanomaisin keinoin ratkaistavissa olevan ongelman mikäli on riittävän paljon aikaa käytettävissä). QCM ei tue suoraan loop-komentoa, mutta rajallisia loop-rakenteita voi rakentaa EEE perusteella. QCM on tarkoituksella turing incomplete ja tätä rajallisuutta käytetään hyödyksi niin etteivät ohjelmat jää jumittamaan loputtomiin loop komentoihin hajautetussa laskennassa. (vrt. Ethereumissa on gas joka estää loop-käskyihin jumiutumisen), Kuitenkin teoriassa QCM:sa ei pitäisi olla rajoitteita sen suhteen mitä on mahdollista ohjelmoida. Tämä tullaan testaamaan paremmin käytännössä PoC jälkeen, ja varsinkin sitten kun enemmän QCM pohjaisia ratkaisuja alkaa syntyä.
Hardware
Encoding – QCM on trinäärilaskentaan pohjaava järjestelmä sillä sen yksinkertainen dataflow malli toimii tehokkaammin mikäli pohjana on trinäärijärjestelmä verrattuna binäärijärjestelmään. Kuitenkin "aidon" (+ ja - jännitteitä käyttävän) trinäärisirun tekeminen on todella paljon monimutkaisempaa kuin binäärisirun ja ainakaan toistaiseksi kukaan ei ole onnistunut tekemään trinäärisiruja jotka pääsisivät lähellekään suorituskyvyssä binäärisiruja. Kuitenkin QCM taustalle on suunniteltu poikkeuksellinen tapa koodata trinäärilukuja useampaan binääribittiin. Kaksi potentiaalista vaihtoehtoa on: joko koodata yksi trinääriluku (+1,0, tai -1) kahteen bittiin, tai vaihtoehtoisesti jopa kolmeen bittiin. Jo kahteen bittiin koodaaminen on tilan hukkaa sillä kaksi bittiä pystyy sisältämään neljä eri vaihtoehtoa 00, 01,10,11. Kuitenkin molemmilla tavoilla kyetään vähentämään ilmeisesti energian kulutusta, sillä vaikka tilaa (johtoja) tarvitaan enemmän voidaan usein portti korvata sillä että kaksi johtoa risteää keskenään ja energian hukka tapahtuu ilm. pääasiassa porteissa. Tällä hetkellä hardware perustuu kahden bitin hyödyntämiseen, mutta kolmen bitin vaihtoehtoa on tarkoitus tutkia jatkossa lisää kun kahden bitin ratkaisu on saatu riittävän pitkälle.
Mikään näistä QCM hienouksista ei tuo juuri lisäarvoa mikäli niitä emuloidaan tavallisella prosessorilla, toisaalta tavalliselle prosessorille ei ole kovinkaan työlästä muutaa esim. trinääriluku binääriluvuksi. Toistaiseksi Iotan Tangle protokolla on pohjautunut trinäärijärjestelmään, mutta jatkossa on tarkoitus että Tangle on mahdollisimman soveltuva niin tavanomaiselle prosessorille, kun QCM perustein toimivalle piirille. (Tämä päivitys on tulossa tämän vuoden aikana). Huomion arvoista on että IoT laitteissa ei yleisesti ottaen ole tavallisia prosessoreita, vaan yksinkertaisia sensoreita ja näitä varten erikseen suunniteltuja piirejä FPGA/ASIC. Tällöin QCM soveltaminen ei ole niin utopista kuin voisi alkuun kuvitella. Piiriä tilatessa mikäli suunnittelee sen QCM mukaisesti se on todennäköisesti halvempaa (vähemmän monimutkaisia komponentteja), energiatehokkaampaa ja lisäksi piiri on kestävämpi. Näin ainakin IF mainostaa malliaan. Itse piiriin käy tavanomaiset binääripiirin osat. Lisäksi QCM soveltuu laskentamallina hajautettuun laskentaan erinomaisen hyvin. Mikään näistä väitteistä ei ole vielä todistettu ja pian tuleva QCM PoC antaa ensimmäisiä viitteitä siitä kuinka malli käytännössä toimii. Todellista suorituskyvyn tai muiden ominaisuuksien testausta joudutaan todennäköisesti vielä odottamaan jonkin aikaa.
Wavepipelining
Dataflow mallissa data virtaa piirin läpi vain yhteen suuntaan (ei mm. looppeja) ja datan virratessa mikään ulkopuolinen viesti ei pääse vaikuttamaan datan käsittelyyn (ei datan pomppimista välimuistin ja piirin välillä kesken datavirran). Data voidaan ajatella kulkevan aaltona piirin läpi kunnes se tulee piirin toisesta päästä ulos. Datan käsittely on myös asynkronisoitua, eli ei ole tarvetta synkronisoida tapahtumien kulkua tiettyyn rytmiin. Ensimmäisessä PoW pyritään testaamaan datan kulkua piirin läpi, mutta jatkossa on myös tarkoituksena testata ns. wavepipelining tekniikkaa missä yhtä aikaa päästetään piirin läpi kulkemaan useampi datavirta. Mikäli datavirrat kulkevat piirin läpi riittävän kaukana toisistaan ne eivät vaikuta toisiinsa, kuitenkin mikäli joku datavirran lenkki kestää niin kauan että seuraavaa aalto ottaa sen kiinni tulee häiriötä. Wavepipelining tekniikalla on aiemmissa tutkimuksissa onnistuttu saamaan 2-7 kertaa enemmän laskentatehoa piiristä, mutta tällainen on mahdollista vain silloin kun datavirta tapahtuu yhteen suuntaan.
3-d sirut?
Tämä on vielä enemmän kaukaista tulevaisuutta tai spekulointia kuin wavepipelining, mutta koska QCM käyttää ilmeisesti selvästi vähemmän laskentatehoa kuin tavallinen siru, se myös tuottaa selvästi vähemmän lämpöä ympäristöön. Nykyisten piirien valtava lämmöntuotto on syy siihen että piirilevyt ovat edelleen vain yksikerroksisia. Periaatteessa QCM tyyppinen laskenta voisi hyvin toimiessaan mahdollistaa piirilevyjen "pinoamisen" päällekäin, tai 3d-sirujen tekemisen. Tämä on kuitenkin jotain mikä todennäköisesti, mikäli ylipäätään on mahdollista, ei olisi IF:n pienen hardware osaston puuhastelua, vaan jonkun suuren piirilevyjä tuottavan firman laboratorion kehitystyön tulosta vuosien päästä.
Roadmap
Smart contract MVP 6/2020 (Smart contract ensimäinen testiversio PoW)
QCM (Qubic computational model) 6/2020 (Qubic hajautetun laskennan protokolla perustoiminnot)
Assembly business logic language 9/2020 (=HLL)
Assembly business logic language tooling 12/2020 (koodin tallennus Tangleen, Iotojen siirto, HLL koodin kokoaminen, eli tämän jälkeen voi kirjoittaa toimivia smart contracteja käytännöllisellä kielellä)
Mitä puuttuu?
Hardwaren ja laskentamallin (QCM) PoC piti olla tammikuussa, ja sen jälkeen hardware puolella ei ole deadlineja, vaikka tämän osa-alueen kehitys jatkuu hajautetun laskennan protokollan rinnalla. Ilmeisesti hardwarepuolen kehitys on tutkimuspainotteista ja epävarmempaa joten varmoja deadlineja on vaikeampi antaa.
Jos asiat menevät nappiin vuoden lopussa tai ensi vuoden alussa pitäisi siis olla mahdollista tehdä hajautetun laskennan järjestelmällä smart contracteja ja todennäköisesti on myös jonkinlainen kuva QCM tehokkuudesta. Todennäköisesti myös QCM-taso (Qupla) ja hajautetun laskennan taso keskustelevat tuolloin jo keskenään. Hardware puolella kehitystyö todennäköisesti jatkuu vuosia, ja lisäksi hajautetun laskennan järjestelmä koodikielineen todennäköisesti kehittyy vielä pitkän aikaa käytännöllisemmäksi ja helpommaksi.