11.1.2020
Analyysi perustuu: (Ethereum whitepaper, 99Bitcoins Ethereum jaksot, Ethereum research updare 5/2818 (https://www.youtube.com/watch?v=J4rylD6w2S4 ), useampaan Ethereumin tekniseen analyysiin.)
Lohkoketjuun perustuva smart contract järjestelmä
Perustettu 2014 Vitalik Buterin toimesta
Ethereum organisaatio on non-profit organisaatio joka kehittää Ethereum alustan koodia ja yhteisöä
Ethereumilla on erittäin laaja yhteisö ja valtava määrä sovellusten kehittäjiä.
Ethereum tekee hajautettujen ohjelmien (=DApp) rakentamisen yksinkertaiseksi ja jokaiselle mahdolliseksi. Ennen Ethereumia hajautettu ohjelma olisi vaatinut aina oman DLT alustan tai toimimisen Bitcoinin rajoitetussa ohjelmointiympäristössä.
Solidity – Ethereumin ohjelmointikieli joka on suunnattu DApp rakentamiseen
Ethereumia pyörittää tuhannet tietokoneet - täysin hajautettu
Ether on Ethereumin token jolla maksetaan laskija nodeille DApp pyörittäminen
Visio: Tehdä täysin hajautettu internet ja yhdistää ihmiset suoraan toisiinsa tehokkaan hajautetun supertietokoneen välityksellä.
Selitys: Tällä hetkellä suuret toimijat mm. Facebook, Netflix, Google, Amazon, Ebay kontrolloivat suurinta osaa internetistä, ja alustoista joita ihmiset käyttävät. Ethereumin myötä esimerkiksi ihmiset voivat vuokrata säilytystilaa suoraan koneeltaan ja näin ei tarvita Dropboxia. Ethreumin myötä välikäsiä ei tarvittaisi myöskään monilla muilla alustoilla kuten kryptopörsseissä. Kts. tarkemmin käyttökohteita DApps esimerkkejä - osuudesta.
Bitcoin on turing-incomplete, eli se kykenee ymmärtämään käskyjä vain kapealta osa-alueelta. Ethereum on turing-complete eli se kykenee ymmärtämään kaikki käskyt mitä ohjelmien rakentamiseen tarvitaan (myös mm. loop-käskyn).
Teknologia
Solidity on Ethereumin oma koodikieli jolla kirjoitetaan smart contracteja. Smart contractit toimivat komentoina DApps:eille. Smart contract koostuu komennoisat if ja then. Solidity-koodi muutetaan yksinkertaiseksi EVM-koodiksi (Ethereum virtual machine) ja Ethereumin laskenta-alusta Ethereum virtual machine toteuttaa tämän koodin.
Ethereumissa käyttäjällä on adress ja private key, kuten Bitcoinissa.
Ethereumin smart contract sisältää kaikki klassisen sopimuksen ominaisuudet: sopimuksen vahvistaminen, hallinta, suorittaminen ja valuutan siirto.
Ethereillä maksetaan sopimuksen laskemiseen tarvittava työ.
Smart contract lyhyesti: Mikäli transaktio tai viesti valitaan lohkoon, sen validointiin kuuluu transaktion laukaiseman smart contractin laskenta. Täten jokainen node joka lataa kyseisen lohkon (ja tulee osaksi Ethereum verkkoa) validoi erikseen lohkon transaktiot ja täten suorittaa lohkon laukaiseman smart contractin laskutoimitukset. Tästä syntyy Ethereumin hajautettu laskenta. EVM on se osa Ethereum ohjelmaa joka laskee smart contracteja . Transaktiossa itsessään ei tarvitse olla kaikkea sitä tietoa minkä muut koneet laskevat, vaan se voi laukaista aiemmin lohkoketjuun tallennetun smart contractin.
Gas
tarvitaan smart contract koodin pyörittämiseen, ja se on mittayksikkö sille paljonko olet valmis maksamaan koodisi pyörittämisestä Ethereitä. Mikäli smart contarctin Gas loppuu kesken ennen kuin koodi on tullut päätökseen sopimusta ei tapahdu mutta sen luoja menettää Gas määrittämän määrän Etheriä. Gas kuvastaa työtä joka koodin pyörittäminen vaatii, joten pystyt etukäteen tarkastikin määrittämään ennalta oletetun työmäärän koodillesi. Mikäli määrittäisit ainoastaan Ethereinä paljonko olet valmis maksamaan, Etherin hinnan vaihtelut tekisivät smart contractin toteutumisesta arvaamatonta. Gas:n lisäksi määrität enimmäishinnan mitä olet valmis maksamaan sopimuksen toteutumisesta. Ennalta pystytään myös tarkasti määrittämään montako Gas yksikköä jokainen toiminta vaatii. Esimerkiksi rahan siirtäminen tililtä toiselle on 21 000 Gas. Gas hinta vaihtelee verkon aktiivisuuden (tungoksen) mukaan. Kun lähetät transaktionin (jossa voi olla koodia sisällä) maksat kaiken transaktionille varatun Gas etukäteen. Mikäli maksoit liikaa, saat ylimääräiset rahasi takaisin kun transaktio on validoitu ja siihen mahdollisesti liittyvä smart contract laskettu. Mikäli lähtökohtaisestikin transaktiossa on liian vähän Gas louhijat eivät ota sopimusta pyörittääkseen. Mikäli määrittää liian alhaisen maksimihinnan sopimuksen toteutumiselle joudut odottamaa todella kauan että sopimus toteutuu (verkon aktiviteetti on niin matala että vähänkin palkkiota maksava transaktio kelpaa uuteen lohkoon).
Ethereumissa on kahdenlasia tilejä:
Externally Owned Account (EOA) = toimii kuten Bitcoin wallet, mutta niillä on myös mahdollista luoda smart contracteja ja laukaista niitä.
Contract account = tilejä jotka sisältävät koodia. Jokaisella koodilla Ethereum alustalla on oma tili. Kuitenkaan näihin ei liity private key:tä jolla hallita tiliä. Tiliä hallitsee ennalta määrätyt laukaisimet. Contract accountit voivat säilyttää Ethereitä, lähettää Ethereitä tai luoda uusia contract account:eja. Kun Contract account on liitetty Ethereum alustaan sitä ei voi enää muuttaa.
EOA:t voivat keskustella toisten tilien kanssa transaktioneilla.
Transaktionilla voi siis: 1. siirtää tokeneita, 2. luoda smart contract:eja 3. laukaista smart contracteja
Transaktionissa on seuraavat tiedot
vastaanottajan tiedot
lähettäjän allekirjoitus
siirrettyjen tokeneiden määrä
Vapaaehtoinen data kenttä
Startgas - joka määrittä sen kuinka paljon Gas yksiköitä (=laskennallisia askelia) transaktionin toteutus saa maksimissaan viedä. Kts. edellä tarkemmin kohta Gas.
Gasprice – hinta jonka maksaja on valmis maksamaan yhdestä laskennallisesta askeleesta.
Contract accountit voivat vastaavasti keskustella muiden tilien kanssa viesteillä (Messages), joissa on seuraavat tiedot
vastaanottajan tiedot
lähettäjän tiedot
siirrettyjen tokeneiden määrä
vapaaehtoinen data kenttä
Startgas
Smart contractit ovat siis itsenäisiä ohjelmia Ethereum alustalla, joita transaktionit tai viestit laukaisevat.
Esimerkiksi: lähettämällä rahaa ICO (initial coin offering) smart contract tilille, aktivoit sopimuksen joka lähettää sinulle takaisin ICO tokeneita.
Ethereumissa on sekä full nodeja (jotka suorittavat laskentaa) ja light nodeja joilla voi käyttää Ethereumia suorittamatta laskentaa. Light nodet luottavat full nodeihin toiminnassaan.
Geth on Ethereum organisaation luoma full node alusta.
Mist on helpotettu käyttöliittymä Geth:lle
Parity kaupallinen full node alusta organisaatioille ja yrityksille
Ether valuutta voidaan jakaa 1e18 yksikköön (1 ja 18 nollaa perään), pienin yksikkö on wei.
Lohkoketju
Lohkoketju itsessään muistuttaa Bitcoinin lohkoketjua. Merkittävin ero lohkoketjussa on että Bitcoin tallentaa kaiken datan tilisiirtojen muodossa. Ethereum tallentaa jokaiseen lohkoon sekä tilisiirrot, että sen hetkisen datan tilan (=state). Data tallennetaan Merkle tree kaltaisella tavalla, mutta koska vain pieni osa datasta muuttuu kahden peräkkäisen lohkon välillä on kehitetty Merkle treen kaltainen "Patricia tree". Tässä ensinnäkin voidaan viitata aiempiin lohkoihin sen datan suhteen mikä ei ole muuttunut, ja muuttuneen datan suhteen on mahdollista datayksiköiden lisäys ja poisto toisin kuin Merkle treessä. Yksinkertaistetusti sanoen dataa kuvatessa käytetään paljon "kts. yst. edellä" kaltaista viittausta.
PoW algoritmi on nimeltään Ethash ja se ASIC-resitentti. Ethash on algoritmi joka vaatii erityisen paljon datan siirtoa ympäri muistia, toisin kuin esimerkiksi Bitcoinin PoW algoritmi SHA256. Bitcoinin algoritmi vaatii lähinnä erityisen paljon määrätyn laskuoperaation suorittamista. Tavanomaisten kuluttajien grafiikkakortit ovat erittäin tehokkaita suorittamaan Ethash algoritmia ja ASIC suunnittelijat eivät helposti saa luotua parempaa ratkaisua. Mikäli joku onnistuisi luomaan paremman ratkaisun, olisi todennäköisesti kannattavampaa myydä innovaatio grafiikkakortteja valmistaville yrityksille, kuin alkaa kilpailla kryptovaluutan louhinnassa.
Modified GHOST (Greedy Heaviest Observed Subtree)
Lohkoketjuissa joissa uusia lohkoja luodaan nopeasti (Ethereumissa noin 15s välein), syntyy erityisen paljon järjestelmän hylkäämiä lohkoja. Mikäli node A onnistuu luomaan lohkon ja lähettää sen eteenpäin muille nodeille, voi node B ehtiä luomaan toisen lohkon ennen tiedon vastaanottamista. Tämä lohko todennäköisesti hylätään sillä suurin osa louhijoista vastaanottaa ensin A:n lohkon ja siirtyy louhimaan A:n lohkosta eteenpäin. Louhija B ei saa tällöin työstään korvausta. Tämä johtaa siihen että paljon työtä menee hukkaan. Lisäksi mikäli A:lla on 30% verkon laskentatehosta ja B:llä 10%, A:lla on 70% riski luoda muiden hylkäämä lohko (sillä 30% tapauksista A luo ensimmäisen lohkon) ja B:llä vastaa riski on 90%. Näin ollen louhija A on tehokkaampi ja saa paremman korvauksen louhinnastaan kuin B. Tämä johtaa herkästi laskentatehon keskittymiseen muutamalle taholle. GHOST on tähän ongelmaan kehitetty ratkaisu. Pisintä lohkoketjua laskiessa otetaan huomioon osittain myös lohkon rinnalle luodut lohkot. Lisäksi se että onnistuu luomaan uusimman lohkon rinnalle lohkon oikeuttaa osittaiseen korvaukseen (12,5%) jaetuista tokeneista (ei kuitenkaa käyttäjien fee:stä). Näin ollen suuret louhijatahot eivät saa kohtuutonta hyötyä vaikka hallitsisivat suurta osaa laskentatehosta. Modified tulee siitä että Ethereumin järjestelmä on mukautettu alkuperäisestä GHOST järjestelmästä.
Dapps - esimerkkejä
- Token systeemit: Ethereumin päälle on helppo rakentaa muita tokeneita. Esim. utility token on digitaalinen token jolla rahoitetaan projektia, ja tokenilla voi myöhemmin ostaa projektin tuottamaa tuotetta tai palvelua. Security token on sijoituskohde ja tokenin omistajat voivat esim. saada ajoittain lisää tokeneita omistustensa perusteella (vrt. osingot). On myös erilaisia standardoituja malleja jotka helpottavat uuden tokenin luomista Ethereum alustalle mm. ERC-20 token.
- E-voting
- Taloudelliset johdannaiset ja vakaat valuutat: Smart contractilla voidaan vakauttaa valuuttaa. Esim. A ja B laittavat kumpikin 1000€ edestä tokeneita smart contractiin ja A saa 30 päivän päästä 1000€ arvosta tokeneita takaisin itselleen ja loput tokenit menevät B:lle. A saa tällöin vakaan valuutan ja B saa mahdollisuuden vivuttaa tokeninsa arvon nousua.
-Identiteetti alustat ja rekisterit (esim. kiinteistö kauppa rekisterit)
-Hajautettu sosiaalinen media
-Hajautettu datatallennus. Tässä käyttökohteessa haluttu data jaetaan osiin. Osat muutetaan kryptattuun muotoon ja niistä tehdään Merkle tree. Data jaetaan vapaasti halukkaille. Tämän jälkeen aina tietyin väliajoin, esim. joka 100 block smart contract valitsee satunnaisen osan rakennetusta merkle treestä ja maksaa sille joka ensimmäisenä todistaa transaktiolla hallitsevansa dataa. Tällä varmistetaan että data todellakin on jollakin taholla säilössä. Lisäksi on mekanismeja joilla vähennetään riskiä yksittäisten datan palasten katoamisesta.
-DAO (Decentralized Autonomous Organization) on smart contracteihin pohjautuva virtuaalinen järjestö jossa valta on jaettu ennalta sovitulla tavalla jäsenten kesken. Esimerkiksi valta voidaan jakaa virtuaalisten osakkeiden hallinan perusteella, tai vaikka niin että jokaisella järjestön jäsenellä on yksi ääni. Lisäksi on ennalta määritetty millä tavoin järjestön varoja voidaan jakaa eteenpäin, esimerkiksi palkkioina, palkkana tai vaikka järjestön omana tokenina. Lisäksi yleensä määritetään vielä miten järjestön sääntöjä voi muuttaa. Tässä käytetään usein 67% enemmistöä. Vaikka smart contract itsessään on muuttumaton, voidaan hyödyntää koodin jakamista useaan osoitteeseen ja Ethereum alustan muuttuvia muistiyksiköitä johon eri osoitteita tallennetaan.
Esimerkki.
smart contract rekisteröi transaktionissa olevan ehdotuksen uudeksi osoitteeksi
seuraava smart contract rekisteröi transaktioina annetut äänet jotka puoltavat tai vastustavat ehdotusta
viimeinen transaktio hyväksyy ehdotuksen mikäli riittävästi ääniä puoltaa ehdotustan ja tallentaa muutoksen muistiin
Monimutkaisemmissa malleissa voi olla esimerkiksi liquid democracy tyylisiä ratkaisuja, joissa oman äänen voi antaa toisen henkilön käyttöön kokonaan tai tietyn äänestyksen ajaksi. DAO voi olla esim. järjestö, projekti tai yritys.
Dao event ja Ethereum classic
DAO hack tai DAO event on 1.8.2018 tapahtunut hakkerointi, jolloin eräs pääomasijoitukseen tarkoitettu DAO onnistuttiin hakkeroimaan. Hakkeroinnin teki mahdolliseksi virhe järjestön omien smart contractien suunnittelussa ja järjestöltä vietiin 150 miljoonaa dollaria. Ethereumin kehittäjät muuttivat protokollaa niin että kyseiset smart contract:it saatiin peruttua ja rahat palautettua. Tästä syntyi hard fork sillä kaikki verkon osapuolet eivät pitäneet smart contractien palautusta oikeutettuna, tai muusta syystä kieltäytyivät perumasta tapahtunutta. Alkuperäinen Ethereum jatkoi nimellä Ethereum classic, ja uusi päivitys nimellä Ethereum.
Ethereum 2.0 – Serenity
(huom. perustuu osittain viime aikasiin uutisiin, mutta teknologisen rakenteen katsoin research update videosta joka julkaistu 5/2018. Tieto voi siis olla osittain vanhentunutta.)
Ethereum Serenity on PoS perustuva järjestelmä. Validoinnin suorittaa siis nodet jotka laittavat jotkainen pantiksi Ethereitä. Mikäli validoija node rikkoo protokollan sääntöjä, se voi menettää pantatut varat. Huom. Tällöin luovutaan nykyisen Ethereumin PoW mekanismista.
Serenityssä on neljä eri tasoa:
Deposits – Main chain SMC (sharding manager contract)
Clock – Beacon chain
Data – Shard headers and blocks
State – State root claims
Deposits: Pääketju johon validoijat tallettavat panttinsa ja johon muut ketjut linkitetään
Clock: Luo tahdin "heart beat" muulle systeemille, ja joka heart beat antaa uuden satunnaisen numeron, jota käytetään satunnaisuuden luontiin alemmilla kerroksilla (data ja state).
Data – Validoijat muodostavat konsensuksen datasta joka hyväksytään shard:iin. (=konsensus)
State – tulkitsee ja käsittelee raakadataa, vrt. Ethereum virtual machine. (=laskenta kerros)
Main chain on lohkoketju johon jokainen validoija tallettaa siis 32 Ether pantin. Lisäksi pääketjuun tallennetaan Beacon chainiin liittyvä RANDAO commitment (tästä myöhemmin lisää). Validoijat jaetaan satunnaisesti neljään eri rooliin:
Proposer – lisää shardiin uutta dataa
Attester – lataa dataa ja tarkistaa että data on saatavilla ja allekirjoittaa että data on tarkastettu
Notary - vahvistaa datan
Meta-notary – valitsee tietyin väliajoin lohkon shardista (=checkpoints) ja tallentaa ne main chain
Jokainen shard on rakenteeltaan blockchain, jossa jokaisessa on tavallisen blockchainin tapaan header ja block. Jokainen validoija seuraa kaikkia header:eita, ja lisäksi validoija kutsutaan satunnaisesti lataamaan satunnaisen shardin block.
Beacon chain yhdistää main chain:in ja shardit (data kerroksen). Jokainen validoija aloittaa luomalla seedin ja laskemalla siitä hash, ja tästä hash:sta edelleen hash todella monta kertaa. Viimeiseksi luotu hash on nimeltään commitment (=RANDAO commitment) ja se on siis numerosarja. Kun commitment on käytetty siirrytään yhtä aiempaan hash:iin joka on seuraava commitment. Näin saadaan näennäisesti satunnaisten lukujen sarja. Commitmenteista ei voida muiden nodejen toimesta ennustaa seuraavaa, mutta voidaan todistaa että kyseinen commitment on luotu paljon aiemmin, eikä ole esim. noden hiljattain tarkoituksella luotu numerosarja jolla node voisi yrittää peukaloida satunnaisuutta.
Beacon chain perustuu globaalille kellolle ja jokaisella kellon lyönnillä (5s välein) valitaan satunnaisten validoijien lista. Listan ensimmäinen paljastaa commitmenttinsa uudeksi satunnaiseksi numeroksi. Tämän satunnaisen numeron pohjalta valitaan seuraava käyttäjien ryhmä joista jälleen ensimmäinen paljastaa commitmenttinsa. Mikäli valittu käyttäjä ei paljasta mitään commitmenttia jatketaan seuraavan kellon lyöntiin samalla commitmentilla ja tämän jälkeen saa toisella sijalla oleva aiemmin valittu käyttäjä paljastaa commitmenttinsa. Näin saadaan hajautettu satunnaislukugeneraattori, jota kukaan yksittäinen taho ei voi peukaloida. (Kaikki tulevissa kerroksissa perustuva satunnaisuus perustuu tähän satunnaislukugeneraattoriin.)
Beacon chain tukee 1024 shardia joissa jokaisessa on 128 validoijanodea.
Tavoitteena on noin 30 000 tps
Data layer
Validoijien roolit:
Proposer – datan lisäys shardiin. Jotta voisi tehdä hyviä ehdotuksia shardin dataan tulisi tietää mitä dataa shard sisältää. Vie paljon aikaa validoijalta ladata uusi blockchain kokonaisuutena laitteelleen. Tämän vuoksi proposer tehtävään valitaan pidemmäksi aikaa sama node (esim. viikoksi). Jokaiseen shardiin arvotaan validoija nodeja jotka muodostavat proposer pool ryhmän. Näistä arvotaan satunnaisesti node joka saa toimia seuraavana proposer vuorossa shardissa.
Attestater – rajoittavat proposer nodejen valtaa (jotta pelkkä proposer pool haltuun saaminen ei mahdollista protokollaan hyökäystä). Jokaista shardia kohden valitaan myös atterster pool ja jokaista blokkia kohden valitaan attester:it (esim. 5 nodea) joista enemmistön (esim. 3) täytyy hyväksyä juuri luotu block jotta se voidaan lisätä lohkoketjuun. Tämän jälkeen lohko on validoitu. Tämä ei kuitenkaan vielä tarkoita lopullista hyväksyntää datalle.
Notary – lopullinen hyväksyntä. Joka 100. lohko käy läpi tarkemman validoinnin. Nämä lohkot validoidaan 400 notary noden toimesta (=committee). (Tämä ryhmä ei siis ole shard kohtainen, vaan hoitaa koko notary toimintaa). Committee arvioi mikä ketju on pisin ja antaa kyseisen ketjun uusimmalle lohkolle checkpoint merkinnän. Tämän jälkeen kyseinen ketju on lopullisesti varmistettu.
Metanotary – kaikkien shardien checkpointit liitetään pääketjuun. Mahdollistaa shardien välisen kommunikaation. Pääketju ja shardit ovat täten tiukasti linkitettyjä
Muut mekanismit:
Proof of custody – Attestater - ja notary nodet saavat palkkiota siitä että suorittavat validointi työtä (=äänestävät). Tämä luo tilanteen jossa nodejen voisi olla taloudellisesti kannattavaa antaa ääniä tarkastamatta itse dataa. Proof of custody:ssa em. nodejen on todistettava että heillä on hallussaan (=laitteelleen ladattuna) se data mistä he tekevät arviota. Data pilkotaan pieniin palasiin, ja jokaiseen palaseen yhdistetään pieni pala satunnaisdataa (salt). Tämän jälkeen palasista tehdään merke hash tree. Merkle hash treen root liitetään siihen ääneen minkä node antaa datan puolesta tai sitä vastaan. Äänestyksen jälkeen noden on paljastettava "salt" ja tällöin kaikki muut nodet pystyvät arvioimaan oliko kyseisellä nodella data kokonaisuudessaan. (Mikäli ei ole, node ei pystyisi luomaan oikeaa Merkle hash tree:n root:ia).
Aggregate signatures – Tätä en täysin ymmätänyt videolta, mutta kyseessä on ilmeisesti keino jolla minimoidaan tiedonvaihtoon tarvittavaa datamäärää. Nodejen allekirjoitusten prosessointi on ilmeisesti suuri pullon kaula skaalautuvuudessa ja tällä ratkaisulla jokaisen noden ei tarvitse todistaa käsitelleensä allekirjoituksen, vaan riittää että node julistaa tehneensä niin. Mikäli node yrittää huijata saaneensa allekirjoituksen jota ei todellisuudessa ole saanut, voi kyseessä olla tilanne jossa lähettäjä node ei ole vielä allekirjoitusta lähettänytkään ja tällöin huijaava node ennen pitkään jää asiasta kiinni lähettävän noden huomatessa asian.
eWASM– Korvaa nykyisen EVM (Ethereum virtual machine). Järjestelmässä suoritetaan smart contracteihin liittyvä laskenta ja datan käsittely. EVM tukee Ethereumin omaa koodikieltä, eWASM tukee lukuisia yleisiä koodikieliä
Roadmap:
Phase 0 – Beacon Chain käynnistys Ethereumin rinnalle 2019
Phase 1 – Shard Chains – testi 2020
Phase 2 – eWASM (korvaa nykyisen EVM) ja tämän myötä protokolla tukee smart contracteja.
2020-2021
--------vasta tämän jälkeen nykyisen Ethereumin siirtyminen Ethereum 2.0. versioon--
Samaan aikaan jatketaan nykyisen Ethereumin kehitystä ja projekti kulkee nimellä Ethereum 1.x. Vielä on epäselvää miten lopullinen siirtyminen Ethereumista Ethereum 2.0 tapahtuu. Yksi ajatus on käyttää Beacon chain:ia yhdistämään molemmat alustat (=finality gadget).
Nyt aikataulu on siirtynyt niin että Beacon chain aiotaan käynnistää 2020 alkuvuodesta ja muiden vaihdein aikataulusta en löytänyt varmaa tietoa.
Miksi viivytykset?
Beacon chain viivästyi hieman, mutta ilmeisesti suurin epäselvyys tällä hetkellä on miten kaksi eri järjestelmää saadaan yhdistettyä. Ethereumia pyörittää valtava määrä laitteita ja koska järjestelmä on hajautettu kukaan ei pysty pysäyttämään verkkoa siksi aikaa kuin "breaking change" tehdään. Louhijat eivät myöskään todennäköisesti ole kovin innokkaina edistämässä muutosta. Mikäli DLT alusta käsittelisi vain tokeneita voitaisiin luoda kaksi eri verkkoa ja siirtää tokeneita vapaaseen tahtiin verkosta toiseen kunnes toinen verkko kuihtuu pois. Kuitenkin verkossa suuri osa tokeneista on sidottu smart contracteihin, ja osassa sopimuksista kukaan ei välttämättä pääse rahoihin kiinni ennen smart contractissa määrättyä aikaa. Mikäli verkkoa aletaan kuihduttaa, on verkossa mukana yhä vähemmän käyttäjiä ja louhijoita ja sen turvallisuustaso laskee. Parasta olisi mikäli voisi siirtää sekä tokenit, että smart contractit vapaasti verkosta toiseen, mutta tämä on teknisesti vaikeaa sillä smart contracteja ei kukaan yksittäinen taho hallitse ja niitä voidaan käynnistää usein hyvin monen eri tahon toimesta. Juuri kun smart contractia ollaan siirtämässä voi joku käynnistääkin sen ja saada yllättäviä vaikutuksia aikaan. Yksi vaihtoehto on myös luoda kokonaan uusi kryptovaluutta tai tarkoituksellinen hard fork. Tällöin kuitenkin nykyisen Ethereumin arvo todennäköisesti laskisi arvaamattomasti ja todella monet tahot kärsisivät. Tämä veisi myös uskottavuutta uudelta Ethereum 2.0. tokenilta, sillä kehittävät olisivat "menettäneet kasvonsa". Ihmiset voisivat silloin pelätä että Ethereum 2.0:lle kävisi samoin kuin edeltäjälleen mikäli tulevaisuudessa syntyisi vielä Ethereum 3.0.
Tätä ongelmaa voi peilata vaikka Iotan rakenteeseen. Nyt käytössä on vielä Coordinator joten koko järjestelmä voidaan pysäyttää tarvittaessa ja ajaa päivitys läpi (näin on tehty useasti). Coordicide aiotaan toteuttaa luomalla kaksi eri verkkoa ja siirtymällä verkosta toiseen asteittain, jotta uuden verkon turvallisuus saadaan testattua. Coordiciden jälkeenkin Qubic ja Tangle ovat eri tasoissa joten Tangle käsittelee vain tokeneita. Qubicissa smart contracteja laskevat tahot on myös tarkemmin rajattu ja tiedossa. Voidaan siis jatkossakin helpommin luoda tarvittaessa kaksi eri verkkoa ja ihmiset voivat siirtää tokeneita verkosta toiseen. Qubic voidaan tällöin päivittää keskustelemaan molempien verkkojen kanssa. Toisaalta Iotan tuleva Bee alusta (=Coordiciden jälkeinen Tangle) on modulaarinen mikä mahdollistaa helpommin yksittäisten osien päivittämisen ja mahdollisesti myös verkon eri versioiden toimimisen yhtä aikaa (soft fork). Lisäksi Iotassa ei ole tahoja jotka todennäköisti kärsisivät tulevista päivityksista (vrt. louhijat), ainakaan niin kauan kuin Iotaa hyödyntäviä ASIC pohjaisia IoT laitteita ei ole.
Oma analyysi
Ethereum eroaa esimerkiksi Bitcoinista siinä että se pyrkii olemaan ennen kaikkea jaettu smart contract alusta, ja kryptovaluutta itsessään on vain sivuroolissa DLT ratkaisussa. Se siis on hajautetun laskennan protokolla joka pyrkii tarjoamaan globaalisti smart contracteja. Tähän on hyvä pysähtyä saman tien ja hieman pidemmäksi aikaa. Hajautettu laskenta on aiheena niin massiivinen että on runsauden pulaa siinä mistä lähteä liikkeelle. Jotain aiheen laajudesta kertoo se että kryptovaluutat joka sekin on aiheena varsin laaja on vain palapelin palanen hajautetussa laskennassa. Tässä tekstissä vertaan myös Ethereumia Iotan Qubic ratkaisuun kahdesta syystä. Ensinnäkin pidän Qubic:ia Ethereumin pahimpana kilpailijana, ja toisaalta Qubic:n kautta hahmottuu se mitä Ethereum ei ole.
Jotta voisi arvioida Ethereumia pitää osata vastata seuraaviin kysymyksiin: mitä on smart contract? Mitä on hajautettu laskenta. Mitä eri muotoja hajautetulla laskennalla on? Sekä mitä ominaisuuksia on hyvällä hajautetun laskennan alustalla?
Tässä tekstissä keskitytään hajautettuun laskentaan protokolla näkökulmasta ja vain sivutaan lyhyesti hajautetun laskennan muita osa-alueita. Ethereum on ohjelma jonka voi ladata netistä ja laittaa pyörimään kotikoneella. Tässä tekstissä ei siis juurikaan käsitellä hajautetun laskennan hardware vaihtoehtoja, laskentaan liittyviä matemaattisia malleja, tai hajautettuun laskentaan suunnattuja matalan tai korkeamman asteen ohjelmointikieliä. Todetaan vain että nykyinen hardware ja sen päälle rakennetut käyttöjärjestelmät lähtevät siitä että muisti, välimuisti ja prosessori ovat lähekkäin. Nykyisiä tietokoneita ei ole suunniteltu hajautettuun laskentaan ja jokainen em. hajautetun laskennan osa-alueista on oma tieteenalansa täynnä mahdollisuuksia parempaan kokonaisratkaisuun.
Tyvestä puuhun – hajatettu laskenta:
Laitteessa voi olla joko itsessään kaikki tarvittava laskentakapasiteetti, tai se voi ulkoistaa laskentaa kokonaan tai osittain toiselle taholle. Toinen taho voi olla keskitetty kuten pilvilaskennassa (cloud computing), tai hajautettu useamman eri laitten kesken (distributed computing). Hajautetussa laskennassa ajatuksena on että useampi laite laskee saman laskutehtävän. Mikäli laite päättää jakaa osan tehtävistä toiselle pilvipalvelimelle ja osan toiselle mutta kunkin laskutehtävän laskee vain yksi kone, puhutaan silti pilvilaskennasta.
Etänä tapahtuva laskenta voi olla tehokkaampaa. Usein cloud computing käyttää erityiskoneita suurissa datakeskuksissa joiden suorituskyky on optimoitu, jäähdytysjärjestelmät ensiluokkaiset ja energiatehokkuus selvästi parempaa kuin tavallisille kuluttajille suunnatuissa laiteissa. Miksi kännyköissä on sitten omat prosessorit? Kännykkä voisi periaatteessa olla vain kommunikointiväline datakeskukseen jossa tehtäisiin kaikki tarvittavat laskennat ja vastaukset välitettäisiin ruudulle. Ongelma syntyy viiveestä datan siirrosta keskukseen ja takaisin (käyttöjärjestelmä tökkisi), ja toisaalta siinä että datan siirto on liian hidasta (-> kaistalaajuus ei riitä internetin kautta). Kuitenkin mikäli laskutehtävä vaatii erityisen paljon laskentaa ja tehtävänanto ei ole kovin suuri data määrältään, voi datakeskuksessa tehty laskenta olla järkevämpää.
Hajautettu laskenta vaatii aina enemmän laskentatehoa kuin keskitetty. Mikäli joudutaan laskemaan sama tehtävä useampaan kertaan se ei voi olla energiatehokkaampaa kuin asian kertaalleen laskeminen. Myös käytetyt laitteet ovat hajautetussa laskennassa epäoptimaalisempia. Voi ajatella niin että keskitetyssä laskennassa voi valita optimaalisimman tahon laskemaan tehtävää. Hajautetussa laskennassa joutuu ottamaan vähintäänkin toiseksi parhaan mukaan parhaan lisäksi. Käytännössä hajautetussa laskennassa ei kuitenkaan pyritäkään ottamaan laskentatehon kannalta optimaalisimpia tahoja vaan optimaaliset laskijat valitaan muilla perustein. On myös hyvä muistaa että mitä useampi taho joutuu laskemaan tehtävää tulee laskennasta suurinpiirtein samassa suhteessa kalliimpaa ja energiaa vaativampaa. Hajautetussa laskennassa on siis suuren mielenkiinnon kohteena laskevien tahojen lukumäärä.
Miksi sitten laskea jotain useampaan kertaan? Yksinkertaistetusti sanottuna hajautetulla laskennalla saadaan lisää luotettavuutta tulokseen. Kyseessä voi olla tilanne jossa et löydä riittävän luotettavaa keskitettyä tahoa laskemaan tehtävää (harvemmin näin on). Toisaalta voi myös olla tilanne jossa laskutehtävän lopputulos vaikuttaa useampaan eri osapuoleen ja ei löydy sellaista yksittäistä keskitettyä tahoa johon kaikki osapuolet olisivat tyytyväisiä. (Tämä on todennäköisempi tilanne ja mm. smart contract vastaa yhteen tällaiseen tilanteeseen. Asiasta lisää myöhemmin.) Voi myös olla ettet tunne tahoa joka suorittaa laskutehtävän jolloin et voi luottaa myöskään vastaukseen. Mikäli et löydä verkosta riittävän luotettavaa tahoa, voit ottaa ryhmän epäluotettavampia tahoja ja hyväksyä vastauksen mikäli riittävän suuri osuus tahoista päätyy samaan tulokseen. Laskentatehon sijasta IoT maailmassa kaistalaajuus on suurin rajoittava tekiä (vrt. kännykkä esimerkki), joten vaihtoehtona on lähinnä laskea data itse tai turvautuva lähiverkossa oleviin tahoihin. Hajautetussa laskennassa vaaditaan siis aina enemmän sekä laskentaenergiaa että kaistalaajuutta (tieto pitää lähettää useammalle koneelle), mutta lähiverkossa voidaan käyttää viestimiskanavia joiden kaistalaajuus on monta kertaluokkaa suurempi kuin internetin (esim. LoRa). Tämä tuo yhden merkittävän käyttötarkoituksen hajautetulle laskennallinen.
Sitten on vielä tilanne jossa ei luoteta omaan laitteeseen. Mikäli koko tehtaan toiminta riippuu yhden laitteen laskennan tuloksesta voi olla hyvinkin järkevää ostaa muutama laite lisää ja varustaa nämä erilaisin suojauksin. Hakkerin tulisi tällöin kyetä murtamaan yhtä aikaa useampi laitteista. Myöskin mikäli yksi laitteista hajoaa koko tehdas ei pysähdy.
Luotettavuutta voidaan myös lisätä muilla keinoin kuin hajauttamalla laskenta kokonaan useammalle eri laitteelle. Erityisesti keskitetyssä pilvilaskennassa voidaan saada lisää luotettavuutta sillä että laskentaa pyytävä taho tarkistuslaskee itse (tai luotettu taho tarkistaa) esimerkiksi 1/30 osan laskutehtävistä. Mikäli tarkistettavat laskutehtävät valitaan satunnaisesti, toistuvasti huijaava toinen osapuoli jää väistämättä jossain vaiheessa huijauksestaan kiinni. Ongelmana on kuitenkin että jo kertaalleen onnistunut vääristelty laskentatulos voi vaikuttaa paljon kokonaisuuteen ja huijaava taho voi saada sillä suurta etua itselleen.
Noniin, nyt kävimme läpi mitä eroa on laskea tehtävä itse, käyttää keskitettyä tahoa tai hajautettua laskentaa ja mitä ongelmia kuhunkin liittyy. Voimme siis alkaa rakentaa hajautetun laskennan protokollaa!
Monimutkaisinta on tehdä protokolla jossa käytetään tuntemattomia tahoja laskennassa, joten suunnataan protokolla tähän tilanteeseen. Muut tilanteet ovat lähinnä erityistapauksia, ja niihin voidaan yksinkertaistuksilla johtaa vastaus em. tilanteesta.
Tuntemattomien tahojen kanssa tilanne on tietynlainen kaupankäynti. Ostajalle (=laskentaa tarvitsevalle) on tärkeää saada määrittää mahdollisimman monipuolisesti toivomaansa palvelua, sekä tietysti on myös tärkeää mitä rahalla ylipäätään saa vastineeksi. Koska hintaan vaikuttaa paljon se kuinka monta konetta laskennan suorittaa se on tärkeä määritettävä parametri. Toisaalta ostaja voi toivoa että laskeva taho täyttää esim. tietyt luotettavuus-, kaistanopeus-, laskentateho-, tai energiatehokkuus kriteerit. Hajautetun laskennan protokollassa ostaja määrittää mitä haluaa ja tämän jälkeen protokolla etsii palveluntarjoajia jotka täyttävät mahdollisimman hyvin ostajan toiveen. Protokollassa pitää olla myös tapa päästä sopuun hinnasta. Ostajan kannalta hyvin toimiva protokolla houkuttelee paljon ostajia ja tämä taas tuo protokollaan lisää laskentaa tarjoavia tahoja. Lisääntyvä kilpailu tehostaa markkinoita ja parantaa sitä mitä ostaja saa rahoilleen vastineeksi. On myös muita tapoja parantaa ostajan saamaa vastinetta, mutta palataan siihen myöhemmin.
Kilpailutuksen lisäksi protokollan tulee pystyä välittämään data valituille laskijoille ja laskun vastaus takaisin ostajalle. Datan siirto pitää tapahtua turvallisesti ja tehokkaasti. Tarvitaan myös mekanismit jotka estävät protokollan huijauksen. Tämä on vaikea osuus protokollan luomisessa aivan kuten kryptovaluutoissakin. Hajautetussa laskennassa on torjuttava laskevan noden naamioituminen useaksi nodeksi. Toisaalta laite voi myös napata toisen laitteen laskeman vastauksen ja lähettää sen omana tuotoksenaan säästäen laskentaan tarvittavan työn. Näiden lisäksi on muitakin keinoja huijata ja jokainen huijaus pitää olla mahdollisimman hyvin torjuttavissa. Vähintäänkin huijauksen tulisi olla huijaavalle taholle taloudellisesti kannattamatonta.
Lisäksi tarvitaan keino maksaa laskijoille. Tässä fiat valuutat ovat kömpelöitä ja kehittyneet kryptovaluutat voivat tarjota etua, sillä ne mahdollistavat maksun nopeasti ja edullisesti. Mutta kuka varmistaa että ostaja maksaa laskijalle vastauksen saatuaan? Ostajan ja laskijan kannattaa jo etukäteen määrittää kriteerit joiden perusteella ostaja on valmis maksamaan palvelusta. Peruskriteerinä voidaan ajatella olevan että riittävän moni laskija päätyy samaan lopputulokseen, mutta ostaja voi määrittää muitakin kriteereitä ostajien ja laskijoiden väliseen sopimukseen. Voidaan esimerkiksi sopia että mahdottomat vastaukset jotka selvästi ovat virheellisiä hylätään.
Ostaja ja maksajat ovat eturistiriidassa rahan siirrossa vastauksen saamisen jälkeen ja tähän ongelmaan on useita vaihtoehtoja:
Voidaan valita luotettu kolmas taho/tahot joka arvioivat vastauksen laadun ja siirtävät rahat.
Voidaan minimoida sopimusrikkomuksesta tuleva haitta ja yrittää saada kaikkien taloudelliseksi eduksi sopimuksen noudattaminen. Tällöin oleellista on että maksuista tehdään hyvin pieniä (sentin murto-osia), niin että ostajalle on kannattavampaa maksaa kuin menettää hyviä laskijoita. Toki voidaan myös sopia että ostaja maksaa etukäteen ja tämän jälkeen laskijat laskevat jolloin riski sopimuksen rikkomisesta on ostajalla.
Vastauksen arvioiminen ja maksun suorittaminen voidaan yhdistää kryptovaluuttaa käsittelevään tietokantaan. Käytännössä tehdään silloin sopimus ja tämä lähetetään kryptovaluutan DLT tietokantaan datatransaktionina. DLT tietokanta tarkistaa vastauksen laadun ja siirtää rahat mikäli kriteerit täyttyvät. Tällöin itse laskutoimenpide ei siis tapahdu tietokannassa, vaan tietokanta vain tarkistaa että vastaus täyttää sen mitä etukäteen on sovittu ja siirtää rahat. Tällöin haittana on että kaikki DLT tietokannan nodet joutuvat tekemään tämän arvioinnin. Toki DLT tietokannassa voi olla shardin mahdollisuus, jolloin vain valitun lohkon nodet käsittelevät arvioinnin. Tällöin ratkaisu alkaa muistuttaa kohtaa 1.
Sitten on vielä keinoja parantaa ostajan saamaa vastinetta. Suuri tekijä on protokollassa mukana olevien laskijoiden laitteiden (hardware) laatu, mutta itse protokollakin voi yrittää vaikuttaa ostajan kokemukseen yrittämällä tehdä algoritmeistä mahdollisimman kevyitä, ja minimoimalla ylimääräistä tiedonsiirron tarvetta. Ostaja voi haluta jakaa laskettavan ongelman useisiin osiin eri ryhmille mikäli protokolla tarjoaa tähän mahdollisuuden. Protokolla voi myös yrittää pienentää viiveitä tarjoamalla laskentatapoja jotka eivät ole niin riippuvaisia laskennan välivaiheiden synkronisaatiosta. Tämä on hieman vaikeammin hahmotettava asia, mutta paikallisessa laskennassa on tavallista että lasketaan yksi askel eteenpäin, ja tallennetaan se välimuistiin, tämä jälkeen otetaan uudelleen välivaihe välimuistista ja ajetaan se laskentayksikön läpi. Tämä ei ole ongelmallista mikäli pitkäaikainen muisti, välimuisti ja laskentayksikkö on vierekkäin, mutta mikäli nämä hajautetaan, viiveet kasvavat. Muuttamalla sitä tapaa jolla tietoa käsitellään voidaan minimoida viiveiden kasvusta laskennalle aiheutuvaa haittaa. Pelkällä laskentatavan muutoksella ei kuitenkaan saada yhtä suuria hyötyjä kuin optimoimalla hardware tehtävää varten kehitettyyn laskentatapaan. Mikäli hardware on tehty eri tarkoitusta varten joudutaan "emuloimaan" toisella tavalla toimivaa järjestelmää, eli toimimaan epäoptimaalisella hardware alustalla.
Nyt kun olemme muutaman sivun tekstillä rakentaneet järkevästi toimivan hajautetun laskennan protokollan, (oikeasti kyseessä on toivelista ominaisuuksista joita hyvässä protokollassa on) voimme todeta ettei lähes yksikään nykyinen smart contract järjestelmä täytä edes ylläolevan perusvaatimuksia. Tämä johtuu siitä että nykyiset smart contract järjestelmät eivät ole lähteneet rakentamaan hajautettua laskentaa suoraan, vaan kehitys on kulkenut nurinkurisesti. Ensin keksittiin kryptovaluutta, sen jälkeen ymmärrettiin että DLT alustaan voi tallettaa myös dataa. Joku keksi että data voi olla myös koodia ja mikäli samat nodet laitetaan lisäksi pyörittämään koodia (=virtual machine) saadaan hajautetun laskennan alusta.
Nodejen laskentoja alettiin kutsua smart contracteiksi koska ajateltiin että käyttötarkoitus voisi olla sopimusten validointi ilman kolmatta luotettua osapuolta. Näin onkin, mutta hajautetun laskennan näkökulmasta järjestelmä on todella kankea, kallis ja jäykkä. Jos astelisin Ethereumin ylläpitäjien luokse ja tiedustelisin hajautetun laskennan palvelua olisin ymmälläni:
Miksi ihmeessä en voi vaikuttaa mitenkään siihen kuka laskee ja millaisilla laitteilla? Alusta tarjoaa vain yhden ainoa vaihtoehdon: kaikki koneet laskevat ongelman. Vastaus tulee yleensä hitaimpien tahdin mukaisesti. Ota tai jätä. Tämä nostaa laskentaan vaadittavaa hintaa kohtuuttomasti.
Toiseksi en maksa vain laskuni vaativia kustannuksia ja vaivan palkkaa laskijoille mikä olisi kohtuullista, vaan lisäksi täytyy maksaa kulut jotka syntyvät siitä että laskijat kisaavat tarpeettomalla algoritmilla siitä kuka saa valita mitä lasketaan (=PoW).
Kolmanneksi protokolla on niin hidas että yhtään järkevää hajautetun laskennan sovellusta ei saa sillä skaalautumaan. Yksittäinen kissojen keräilypeli jumitti aiemmin koko verkon. Joudun siis vielä maksamaan siitä että laskuni priorisoidaan siihen pieneen joukkoon joka mahtuu protokollan kapeaan suorituskykyyn (tps).
Hajautetun laskennan protokollana Ethereum ei siis menesty, eikä maailman hajautettuna supertietokoneena kuten välillä valheellisesti mainostetaan. Ethereumin päälle on yritetty myös rakentaa toisen tason ratkaisuna hajautetun laskennan protokollaa. Tällöin protokolla voidaan rakentaa ylläolevien periaatteiden mukaisesti ja käyttää Ethereumia vahvistamaan laskijoille suunnatut maksut ja muut tarvittavat arvon siirrot (kohta 3 maksujen käsittelyn tavoissa). Tällöin kuitenkin ongelmaksi muodostuu edelleen Ethereumin kalleus. Yksi tilisiirto on tämän tekstin kirjoittamisen aikoihin yli 0,40€ ja se on kallis hinta verrattuna etälaskentaa suorittavan tahon palkkioon. Tämän lisäksi tulee kulut jotka liittyvät vastauksen tarkistukseen liittyvään laskentaan (smart contractiin). Toki voidaan ajatella että pidennetään laskenta-aikaa ja vuokrataan ryhmä koneita esim. vuorokaudeksi (eli tulosten laatua arvioidaan vasta vuorokauden kuluttua). Kuitenkin tällöin mikäli ryhmässä on vääriä vastauksia antavia koneita tämä huomataan vasta vuorokauden kuluttua. Tästä on haittaa sekä laskennan tilaajalle, että oikeita tuloksia antaville koneille. Yksi vaihtoehto on myös käyttää Bitcoinin Lightningin network kaltaista järjestelmää jossa kumpikin osapuoli panttaa rahaa alustalle ja tämän jälkeen osapuolet voivat suorittaa alustan ulkopuolella (toisella tasolla) rajoittamattoman määrän kahden keskisiä hyvinkin pieniä tilisiirtoja ilman kuluja kunhan kumpikaan ei velkaannu toiselle pantattua summaa enempää. Tällöin Ethereum alustan ei tarvitse tarkastaa tilisiirtojen oikeellisuutta vaan laskentaa tilaava taho voi tehdä sen (kohta 2 laskennan arvioinnissa). Kuitenkin tässäkin tilanteessa Ethereum on edelleen kallis ja laskijoiden kilpailutus kärsii sillä aina sopimuksen toista osapuolta vaihdettaessa joudutaan maksamaan kalliit siirtomaksut.
Ainoa minun tiedossa oleva protokolla joka rakentuu yllä kuvattujen perusajatusten pohjalle on Iotan Qubic (huom. yllä kuvattu ei kuitenkaan ollut kuvaus Qubicin toiminnasta. Yllä kuvattiin perusperiaatteita joita hyvässä hajautetun laskennan protokollassa on. Qubicissa on monia samoa periaatteita, mutta lisäksi se pyrkii lisäämään sitä mitä ostaja rahallaan saa hyvin monella eri tasolla, mm. hardwaren, matalan asteen koodikielen, korkeamman asteen koodikielen, ja kommunikaatiokerroksen tasolla.)
Ethereum on kuitenkin löytänyt kapean sektorin jolla se voi kyetä jatkossa tarjoamaan riittävän hyvän alustan. Mikäli Serenity projekti saadaan toteutettua ja sharding ratkaisu toimii, voi suorituskyky jatkossa riittää maailman laajuiseen smart contract alustaan niin että käytännön sovellusten toteuttaminen on järkevää. 30 0000 tps on nykyisellä mittapuulla todella nopea DLT ratkaisu ja sen kapasiteetti riittää todennäköisesti lähivuosien ajan smart contractien tarvitsemaan arvon ja datan siirtoon. Laskentakapsiteetista en löytänyt tarkempaa tietoa Serenity projektin onnistuessa, mutta ilmeisesti myös laskentakapasiteetti riittäisi yksinkertaisten smart contractien ohjelmointiin skaalautuvasti. Mutta mikä on hajautetun laskennan ja smart contractin ero?
Smart contract
Smart contract on hajautetun laskennan kapea erityismuoto. Siinä luodaan itsenäinen ohjelma joka säilytetään DLT alustalla usealla eri nodella. Itsenäisellä ohjelmalla tarkoitan ohjelmaa joka sisältää kaiken sen suorittamiseen tarvittavan datan, sekä taloudellisen kannustimen ohjelman suorittamiseen verkossa (=Gas). Ohjelma koostuu if ja then komennoista. Usein ohjelman luodaan odottamaan tiettyä tapahtumaa ja usein ohjelman tehtävänä on myös siirtää tokeneita DLT alustalla mikäli ennalta määrätyt ehdot toteutuvat. Usein on myös niin että pelkästään protokollassa oleva smart contract ei riitä, vaan tarvitaan ohjelmalle linkki todelliseen maailmaan: oraakkeli (oracle). Oraakkeli kuuntelee jotain ulkomaailman tietolähdettä ja syöttää tietoa DLT alustaan. Smart contract kuuntelee tätä tietoa, ja tällöin tietty ulkomaailman tapahtuma laukaisee smart contractin toiminnan. Kun ohjelma on kertaalleen jaettu DLT alustaan kukaan ei kykene enää muokkaamaan sitä tai vaikuttavaan sen toimintaa. Ainoastaan mikäli merkittävä osa DLT alustan nodeista päättää olla noudattamatta smart contractin sisältöä voi sopimus peruuntua. Tällöin on kuitenkin suuri riski että koko DLT protokolla haarautuu kahteen eri versioon -> hard fork.
Ajan myötä on huomattu että on hyvin vaikeaa tehdä täydellistä smart contractia. On myös huomattu ne ovat usein sitä arvaamattomampia mitä monimutkaisempia ne ovat. Yhteys ulkomaailmaan lisää smart contractin arvaamattomuutta mutta myös käytännöllisyyttä.
Otetaan yksinkertainen esimerkki:
Kaksi henkilöä päättävät lyödä vetoa jalkapalloturnauksen lopputuloksesta. He päättävät tehdä smart contractin varmistaakseen ettei kumpikaan taho pääse huijaamaan. Tulos ilmoitetaan valitulla palvelimella muodossa A-B, jossa A on ensimmäisen tiimin pisteet ja B toisen. He luovat smart contractiin säännöt joiden mukaan mikäli A >B ensimmäinen henkilö saa rahat ja mikäli B>A toinen henkilö saa rahat. Mikäli A=B palautetaan rahat omistajilleen. Mikäli palvelin ilmoittaa tietokannassaan tekstin peruttu (=ottelu peruttu) rahat palautetaan omistajilleen ja mikäli palvelimella lukee "siirtynyt" (=ottelu jouduttu siirtymään), ei tapahdu vielä mitään.
Kuitenkin ennen ottelua seuratulla palvelimella tapahtuu tietojärjestelmän päivitys ja tilan säästämiseksi tietokannassa tekstit "peruttu" ja "siirtynyt" muutetaan koodeiksi 0 ja 1. Nyt smart contract algoritmi ei tiedä kuinka tulkita yksittäsiä numeroita ja se voi olettaa esimerkiksi jälkimmäisen numeron olevan 0. Näin ollen "siirtynyt" ottelu johtaa ensimmäisen henkilön voittoon.
Mikäli kyseessä ei olisikaan kahden henkilön veto, vaan vedonlyöntiä välittävän yrityksen luoma smart contract voisi virheen huomannut henkilö houkutella valtavan määrän ihmisiä lyömään kanssaan vetoa suurilla summilla rahaa siinä vaiheessa kun tietää ottelun siirtyneen. Ainoa asia mitä yritys pystyisi tekemään olisi tiedottaa mahdollisimman monelle tapahtuneesta virheestä, tai saada seuratun palvelimen päivitys peruuntumaan. Jo hyvin yksinkertaista smart contract:ia voi siis olla vaikea luoda niin että se kykenee toimimaan oikein kaikissa tilanteissa mitä tulevaisuudessa voi tapahtua.
Tähän asti smart contracteilla on lähinnä yritetty välttää ulkopuolisen kolmannen tahon tarvetta sopimuksissa joissa aiemmin on turvauduttu luotettuun tahoon. Tavoitteena on silloin ollut lisätä luotettavuutta, sekä vähentää sopimuksen kustannuksia. Usein nämä sopimukset ovat olleet ainakin osin ihmisten välisiä. Minulle on hieman epäselvää kuinka usein tällainen on johtanut ongelmiin, ja kuinka usein aiempaa parempaan ratkaisuun. Smart contracteissa ei tunneta force major:ia, eikä ole mahdollisuutta perua sopimusta joka osoittautuu epäreiluksi, lain-, tai lain hengen vastaiseksi. Toki joissain tilanteissa voi olla mahdollista haastaa sopimuksen toinen osapuoli oikeuteen, mutta pääsääntö smart contracteissa on, että niiden sopimukset ovat aina peruuttamattomia. Lisäksi smart contractit ovat sen verran uusia että useinkaan ei ole selvää lain käytäntöä niistä aiheutuneiden ongelmien suhteen.
On myös mahdollista luoda sopimuksia joissa koodi on ennalta jaettu useampaan osoitteeseen DAO:n tavoin ja tietyillä kriteereillä on silloin mahdollista muokata koodia. Toinen tapa välttää em. tilanne on luoda suojamekanismeja väärinkäytösten varalle. Molemmat tavat lisäävät smart contractin monimutkaisuutta sekä käyttökustannuksia. Lisäksi eri suojamekanismit tarjoavat myös hakkereille aina uusia rajapintoja joihin hyökätä. Lisäksi monimutkaisempi smart contract on vaikeampi tarkastaa itse. Kyseessä on kuitenkin aina sopimus ja yksinkertaisen smart contractin pystyy pienellä harjoituksella itse lukemaan ja ymmärtämään. Monimutkaisempi smart contract vaatii herkästi luottamisen johonkin ulkopuoliseen tahoon joka tarkastaa sopimuksen sisällön ja silloin herää kysymys miksi edes käyttää hajautettua smart contractia. Smart contracteissa siis yksinkertaisuus on etu ja Ethereumin suurin taloudellinen potentiaali on todennäköisesti yksinkertaisissa smart contracteissa.
Mikäli Ethereumin Serenity projekti saataisiin toteutumaan nopeasti voisi maailma ainakin jonkin aikaa hyötyä tällaisesta globaalista smart contract protokollasta. Yllä kuvattu smart contract voitaisiin toteuttaa nykyisellä Ethereumilla, Serenityllä tai Qubic alustalla. Mikäli kuitenkin halutaan luoda monimustkaisempi DApp, varsinkin jos tarvitaan klassisen smart contract sopimuksen lisäksi esimerkiksi tekoälyä on selvästi järkevämpää käyttää hajautetun laskennan periaatteiden mukaisesti luotua protokollaa. Esimerkkinä voisi olla valmiiksi koulutettu tekoälyalgoritmi, joka tietyssä tilanteessa alkaa analysoida osakemarkkinoita ja tehdä itsenäisiä ostoja mikäli arvioi tämän kannattavaksi. Ethereum olisi tällaiseen aivan liian kallis ja hidas. Myös IoT maailmassa Ethereum on todennäköisesti liian kallis. Tästä myöhemmin vielä hieman lisää.
Mutta ennen kuin viedään vertailua pidemmälle täytyy vielä vähän jatkaa hajautetun laskennan periaatteiden mukaan luodun alustan parissa. Iotan Qubic on siis ainoa tietämäni hajautetun laskennan ratkaisu joka toimii em. periaatteiden mukaisesti. Qubic:issakaan ei ole kaikkia yllä pohdittuja vaihtoehtoja käytössä, vaan esimerkiksi ostaja maksaa laskijalle tällä hetkellä ainakin vielä kohdan 2. periaatteen mukaisesti. (Eli niin pieninä maksuina ettei sopimusrikkomus tarjoa kummallekaan osapuolelle merkittävää taloudellista hyötyää, tai tappiota). Qubic ei kuitenkaan ole itsessään smart contract alusta, vaan smart contract täytyy rakentaa Qubicin päälle omaksi kerroksekseen. Tällä hetkellä ei ole vielä julkaistu tarkempaa tietoa siitä miten tämä aiotaan toteuttaa, joten voi hyvin esittää kysymyksen onko tämä edes mahdollista?
Koska Qubic on Ethereumin uhkaavin kilpailija pohditaan seuraavassa eri vaihtoehtoja smart contract järjestelmälle Qubic:ssa.
Smart contractissa ei ole kohde laitetta joka ostaisi laskentatyötä. Data säilytetään hajautetulla alustalla ja tässä on useita eri vaihtoehtoja. Pienet määrät dataa voidaan säilyttää DLT alustalla suoraan, tai mikäli alustalla on käytössä sharding voidaan data säilyttää yhdessä alustan lohkossa. Toisaalta data voidaan yhtä hyvin säilyttää myös vain niillä tahoilla jotka suorittavat laskutoimitusta, tai jopa yhdellä keskitetyllä taholla (pilvipalvelimella). Tällöin on kuitenkin todennäköisesti järkevää luoda data:sta hash ja tallettaa se DLT alustaan, jotta voidaan olla varmoja ettei kukaan pääse muokkaamaan dataa muiden huomaamatta. Smart contract tarvitsee myös oman tilin josta siirtää rahaa laskijoille ja arvon siirrossa tililtä on samanlaisia vaihtoehtoja käytössä kuin silloin kun lompakon omistaa IoT laite. Oraakkeli tarvitaan samalla tavoin kuin Ethereumissa ja Oraakkeli voi välittää ulkopuolisen datan suoraan laskeville tahoille, tai tehdä sen DLT alustan kautta. Todennäköisesti ei ole ongelmaa tehdä sitä DLT alustan kautta useimmissa sovelluksissa, sillä Oraakkeli kykenee seuraamaan valtaviakin tietomääriä ja tiivistämään datasta oleellisen. Laskevat tahot määräytyvät Qubic protokollan kautta samoin kuin muussakin hajautetussa laskennassa. Mikäli käytetään jalkapalloturnaus esimerkkiä tulee laskijoiden kyetä myös siirtämään rahaa smart contractin määräämälle taholle. Tässä voisi esimerkiksi tulla kyseeseen multisig lompakot joissa olisi ennalta määrätty vastaanottavat tahot, muttei siirrettäviä määriä. Multisig tarkoittaa että tilisiirron hyväksyntä vaatii useamman kuin yhden tilisiirron hyväksyvän tahon allekirjoituksen. Esimerkiksi voitaisiin määrittää niin että kun laskennan alusta on kulunut 30s tarkastetaan nodet jotka osallistuivat laskentaan ja mikäli yli 70% nodeista on samaa mieltä ja allekirjoittavat saman tilisiirron se hyväksytään. Qubic tulee todennäköisesti rakentumaan aivan eri periaatteelle mutta tarkoituksena oli kuvata etten keksi mitään periaatteellista syytä miksei smart contracteja voisi rakentaa myös hajautetun laskennan periaatteiden mukaisesti luodun alustan pohjalle.
Qubic roadmapissa on smart contract ratkaisu vuoden 2020 aikana joten mikäli ei tule yllättäviä hidasteita päästään tällaisia smart contracteja arvioimaan pian käytännössä. Ethereumin sharding ratkaisu sen sijaan on kokenut runsaasti viivytyksiä ja viimeisimpien tietojen mukaan vie vielä useita vuosia ennen kuin se saadaan kokonaisuutena toimimaan. PoW poistuminen, sharding ja sitä myöten tuleva protokollan nopeutuminen ovat ehdottomasti suuri edistysaskel, mutta protokolla jää vielä kauas Qubic:n tarjoamasta joustavuudesta smart contracteissa:kin puhumattakaan muista sovelluksista. On suuri hyöty mikäli pystyt räätälöimään smart contractin sisällön lisäksi myös sen toteutukseen liittyvät parametrit ja optimoimaan smart contractin kustannukset, (tämän lisäksi siis vielä Qubic:iin linkittyvät hardware:n ja laskentatavan innovaatiot jotka pudottavat kustannuksia entisestään).
IoT ja smart contract
IoT laitteet voivat tehdä sopimuksia monella eri tapaa. Yksi tapa on maksaa sitä mukaan kun vastaanottaa haluttua asiaa. Esimerkiksi latauksessa tällainen toimii hyvin. Kuitenkin on myös selvää että tarvitaan smart contracteja IoT maailman pyörimiseksi. Kaikkea ei voi jakaa riittävän pieniin osiin niin että toinen osapuoli ei voisi saada merkittävää hyötyä sopimuksen rikkomisesta. Myöskään kolmannen osapuolen käyttäminen tuomarina ei aina ole käytännöllistä IoT laitteiden ollessa usein tuntemattomassa ympäristössä ja paikallisen verkon armoilla. Koneiden välillä smart contractit todennäköisesti tarjoavat enemmän hyötyä kuin ihmisten välisissä sopimuksissa. Kuitenkin IoT maailma on myös niukkuuden maailma ja Qubicin smart contract järjestelmä joka on väistämättä paljon joustavampi (=tarvittaessa halvempi) on selvästi Ethereumin ratkaisua parempi IoT laitteille. Ethereumin smart contractit eivät myöskään lähtökohtaisesti voi toimia mesh-verkoissa. Tällä hetkellä Iotan DLT ratkaisu Tangle ei toimi mesh-verkoissa, mutta tavoitteena Iotalla on lopulta luoda mesh verkkoihin sopiva protokolla. Qubic sen sijaan on todennäköisesti kohtalaisen helposti muokattavissa mesh-verkoikkoihin, ainakin rakenteensa puolesta. Yksi piirre DLT protokollasta johdetulla smart contract järjestelmällä kuitenkin, mikä tuo sille etua. Tokeneiden siirto on suoraviivaisempaa mikäli kaikki on samassa tasossa. Aiemmin kuvattu hajautetun laskennan protokolla ei ole suorassa yhteydessä tokeneihin protokolla tasolla, eli mikäli tarvitaan arvon siirtoa se vaatii erillisen ratkaisun. Yllä kuvattu multisig lompakko oli vain esimerkki, ei missään nimessä loppuun asti pohdittu ratkaisu.
Datan tallennus
Mikäli jaetun laskennan protokolla tulisi rakentua kysynnän ja tarjonnan lakien mukaisesti ollakseen mahdollisimman tehokas, eikö sama tilanne ole sitten myös DLT ratkaisuissa jotka keskittyvät datan tallennukseen? Optimaalinen protokolla kykenisi tällöin unohtamaan datan jolla ei ole taloudellista arvoa ja optimaalinen tapa tehdä sharding olisi niin, että kenenkään ei tarvitsisi säilyttää pitkään dataa jota eivät itse koe taloudellisesti hyödylliseksi. Suuret datamäärät voitaisiin tallentaa muutamaan datakeskukseen ja pienet datamäärät pysyisivät verkossa niin kauan kun joku on valmis niistä riittävän todennäköisesti maksamaan. Näin voi kenties olla, mutta datan tallennuksen kohdalla on hyvä muistaa että ongelma ei ole kuitenkaan läheskään niin kriittinen kuin hajautetussa laskennassa. Mikä tahansa sharding ratkaisu auttaa jo paljon sillä suurestakin datamäärästä voidaan aina tallentaa vain hash DLT protokollaan ja muu data voidaan säilyttää keskitetysti. Hash:lla voidaan varmistaa että keskitetysti säilytettyä dataa ei ole peukaloitu. Kuitenkaan hash:lla ei voida tehdä laskentaa, se on vain datan "sormenjälki", tämän vuoksi ongelmaa ei voi suoraan rinnastaa datan säilytyksen ja hajautetun laskennan välillä.
Loppusanat
Kun aloitin kryptomaailmaan tutustumisen noin nelisen vuotta sitten ihmeteltiin silloin yleisesti mihin edes tarvitaan altcoineja. Bitcoin oli jo ratkaissut kryptovaluuttojen suurimman ongelman: double-spend:in ja osa ihmisistä tosissaan uskoi että se tulisi korvaamaan nykyistä pankkijärjestelmää ihmisten välisenä valuuttana. Nykyään tuollaiset ajatukset ovat (ainakin Bitcoinin kohdalla) naurettavia ja jokainen kryptomaailmaan tutustuva törmää kryptotrilemmaan ja perinteisten kryptovaluuttojen kalleuteen ja tehottomuuteen. Uudemmat kryptovaluutat esittävät vuoron perään askelia ongelmien ratkaisemiseksi ja ymmärretään ettei kukaan ole vielä ratkaissut koko ongelmaa. Toisaalta on myös ymmärretty että kryptovaluuttojen suurimmat mahdollisuudet eivät ole nykyisten valuuttojen korvaajana vaan sellaisten ratkaisujen mahdollistajana mitkä eivät olisi mahdollisia ilman hajautettuja alustoja.
Kun seuraa keskustelua smart contracteista tulee samanlainen tunne kuin neljä vuotta sitten kryptovaluutoista. Kaikki kysyvät: "Voiko sillä tehdä smart contracteja?", enkä missään ole törmännyt kunnolliseen keskusteluun hajautetusta laskennasta laajemmin, siihen liittyvistä ongelmista ja sen tuomista mahdollisuuksista. Smart contractit ovat hajautetun laskennan kapea-alainen erityisosa-alue ja siitä perspektiivistä käsin ei voi hahmottaa mitä mahdollisuuksia hajautettu laskenta todellisuudessa tarjoaa. Tällä tekstillä pyrin osoittamaan tavan arvioida yleisesti ja karkeasti hyvinkin erilaisia hajautetun laskennan alustoja ja esittämään hajautetun laskennan keskeisimpiä ongelmia.
Siinä vaiheessa kun hajautetun laskennan alustat (myös smart contract alustat) alkavat todella ottaa mittaa toisistaan on todennäköistä että oleellisiksi asioiksi nousee yllä kuvatut ominaisuudet: Kuinka mukautuva alusta on "asiakkaan" (=ostajan) toiveisiin, ja mitä vastinetta asiakas saa rahoilleen?
Tarkemmin eriteltynä kuinka luotettavaa, laadukasta ja edullista suoritettu laskenta on? Toki on myös muita kriteereitä kuten kuinka helppokäyttöinen protokolla on, ja miten protokolla on yhdisteltäväsissä nykyisiin laitteisiin ja muihin protokolliin, mutta nämä ovat enemmän käyttöliittymään kuin itse protokollaan liittyviä tekijöitä.
Samoin kuin Bitcoinin kohdalla aikoinaan, voi Ethereumin kohdalla todeta että ei olla ymmärretty edes oikeaa kysymystä, saatikka päästy lähelle ratkaisua. Protokolla joka tarjoaa todellisen hajautetun laskennan ratkaisun voittaa kapea-alaisemmat smart contract alustat tehokkuudessa, mutta tarjoaa myös paljon enemmän käyttökohteita ja mahdollisuuksia.