Visio:
ChainLink pyrkii luomaan hajautetun oraakkelijärjestelmän, millä turvataan lohkoketjuihin syötettävän tiedon luotettavuus. Pidemmällä tähtäimellä ChainLinkin tavoitteisiin sisältyy myös laskennan siirtäminen osin oraakkelijärjestelmään mm. käyttämällä luotettuun laskentaa suunniteltua laitteistoa (trusted hardware). Kun laskentaa tehdään lohkoketjun ulkopuolella, voidaan vähentää lohkoketjujen smart contract järjestelmän kuormitusta, ja lisätä käsitellyn datan määrää.
ChainLink ltd – noin 18 henkeä
ChainLink ltd on perustettu syyskuussa 2014 Sergey Nazarov ja Steve Ellis toimesta Cayman saarille. ChainLink on SmartContract yhtiön tytäryhtiö.
Market cap:
$834 milj. USD, Rank 17 (kirjoitushetkellä 6.4.2020)
Link:
token, jolla välitetään maksut oraakkeleille. Link kokonaismäärä on 1,000 miljoonaa. Tällä hetkellä kierrossa on 350 miljoonaa Link tokenia. Link ICO tapahtui syyskuussa 2017, jolloin 350 miljoonaa Link tokenia myytiin. Jatkossa 350 Link tokenia tullaan jakamaan järjestelmään pyörittäville nodeille (=oraakkeleille), ja 300 miljoonaa Link tokenia on ChainLink ltd:n hallussa suunnattuna protokollan kehitykseen. Link tokeneita ”louhitaan” myymällä lohkoketjun ulkopuolisia palveluita ja dataa ChainLink verkon kautta lohkoketjulle. Link token pohjautu Ethereumiin ja on ns. ERC20 token, joka kuitenkin sisältää myös ERC223 token ominaisuuksia. (Ethereumin päälle on mahdollista rakentaa erilaisia token-järjestelmiä. Näitä järjestelmiä varten on luotu ns. mallipohjia, joilla on eri ERC-luku).
Oraakkelien ongelma:
Smart contracteissa ohjelman suorittaminen jaetaan useammalle taholle, niin että kukaan yksittäinen taho ei pysty estämään tai muuttamaan ohjelman suoritusta. Smart contract siis toteutuu sen sisältämän koodin mukaisesti, riippumatta smart contractin ulkoisista tapahtumista. Kuitenkin useimmissa käyttökohteissa on tarpeen saada smart contract keskustelemaan myös ulkomaailman kanssa. Voi olla tarpeellista, että smart contract esimerkiksi reagoi lohkoketjun ulkoiseen dataan, tai välittää dataa lohkoketjun ulkopuolelle. Mikäli datan tuottaa luotettu taho joka allekirjoittaa datan kryptografisesti, voidaan data saada siirtymään lohkoketjuun ilman erillistä välittävää tahoa. Useimmiten nykyään kuitenkaan ei näin ole. Suurinta osaa datasta ei pystytä todistamaan aidoksi ja dataa tuottava taho voi esimerkiksi välittää dataa nettisivullaan. Nettisivu ei itsessään keskustele lohkoketjun kanssa, ja lisäksi luotettavan datan saaminen voi vaatia datan seuraamista useammasta eri nettiosoitteesta luotettavuuden lisäämiksi. Tällaisiin käyttökohteisiin tarvitaan erillistä tahoa joka kerää datan halutusta kohteesta ja siirtää sen lohkoketjuun. Tätä kutsutaan oraakkeliksi. Mikäli oraakkeli on yksittäinen luotettu taho, voi koko smart contractin toiminta riippua tästä luotetusta tahosta. Tuolloin herää kysymys miksi edes käyttää smart contractia ratkaisuun? ChainLink on järjestelmä, missä useampi node muodostaa hajautetun oraakkelijärjestelmän ja yhteisellä konsensuksella siirretään lohkoketjun ulkopuolista dataa lohkoketjuun. Chainlink ei pyri itsessään olemaan lohkoketju, vaikka pohjaakin Ethereumin lohkoketjuun toiminnassaan. Sen sijaan se pyrkii tarjoamaan eri lohkoketjuille hajautetun oraakkelijärjestelmän ja lisäämään eri lohkoketjujen käytännöllisyyttä. Ratkaisu perustuu kolmeen mekanismiin:
1. Käytetään useampia tietolähteitä datan keruuseen
2. Käytetään useampaa oraakkelia datan siirtämiseen
3. Käytetään datan luotettavuutta lisäävää hardwarea
Yhteistyötahot:
SWIFT: Suuri pankkien välinen kommunikaatio verkosto (suurin yhteistyökumppani)
Zeppelin OS: Käyttöjärjestelmä, mikä on kehitetty erityisesti smart contractien luomista varten
Request Network: Pyrkii olemaan yleinen standardoitu välitysalusta fiat ja kryptovaluuttojen välillä
Signal Capital: Lontoossa toimiva yritys joka hallitsee yksityistä varallisuutta
TEKNOLOGIA
ChainLink whitepaper on poikkeuksellisen helposti luettava ja ymmärrettävä, joten projektista kiinnostuneelle voi lämpimästi suositella sen lukemista. Tiivistän teknologia osuudesta tärkeimpiä kohtia, jotta teksti ei olisi täysin whitepaperin suomennos.
ChainLink on rakennettu Ethereumin pohjalle, mutta pyrkii laajenemaan yhteensopivaksi kaikkien tärkeimpien smart contract järjestelmien kanssa. (Tällä hetkellä sopii yhteen Bitcoinin, Ethereumin and Hyperledgerin kanssa) Järjestelmä on suunniteltu modulaarisesti, joten yksittäisiä osioita on helppo päivittää ja muokata. Eri osuudet ovat myös muokattavissa tarvittaessa eri käyttäjien toiveiden mukaisesti.
Oraakkelin toiminta:
USER-SC = smart contract mikä pyytää oraakkelipalvelua (=palvelun ostaja)
CHAINLINK-SC = oraakkelin osa joka on yhteydessä lohkoketjuun (=ns. on-chain osuus oraakkeli ohjelmasta)
CHAINLINK-SC sisältää:
Reputation contract – seuraa oraakkelipalvelun tarjoajan suoriutumiseen liittyviä määreitä (=oraakkelin mainetta)
Order-matching contract – tallentaa SLA* tiedot lohkoketjuun, kerää oraakkelipalvelun tarjoajien tarjoukset ja valitsee sopivat oraakkelipalvelun tuottajat käyttäen reputation contract:in tietoja. Lopulta order-matching contract viimeistelee SLA:n, ja tallentaa sen lohkoketjuun.
Aggregating contract – Kerää oraakkelipalvelun tarjoajien tuottamat vastaukset, laskee näistä tiedoista lopullisen vastauksen USER-SC:lle, sekä tallettaa tietoja reputation contract:lle.
*SLA = service level agreemet, eli palvelutasosopimus on tilaajan ja palveluntarjoajan välinen sopimus, jossa määritellään mitä palvelu sisältää ja mitkä ovat vaatimustasot. Käytännössä SLA sisältää esimerkiksi tiedot siitä: mitä tietoja oraakkeleilta pyydetään, kuinka monta oraakkelia sopimukseen sisältyy, millä perustein oraakkelit voidaan hyväksyä sopimukseen, ja miten kerätty data yhdistetään ostajalle annettavaksi vastaukseksi, etc.
On-chain osuus järjestelmästä toimii kolmessa vaiheessa:
1. Oraakkelin valinta – Palvelun tilaaja (=ostaja) lähettää SLA ehdotuksen order-matching contractiin, ja oraakkelit tekevät tarjouksia sopimuksesta. Kun sopimus syntyy, se tallennetaan lohkoketjuun. Oraakkeleiden tekemät tarjoukset ovat sitovia ja sopimuksen rikkomisesta oraakkeli menettää sopimuksessa määritellyn summan tokeneita. Oraakkelin valintaan voidaan käyttää reputation contractin tarjoaman lohkoketjuun tallennetun tiedon lisäksi myös muuta ns. off-chain dataa. Tällaista tarjoaa mmm. ChainLink Security Services (tästä lisää edellä). Periaatteessa kuka tahansa voi perustaa oman järjestelmän ChainLinkin päälle ja tarjota arvioitaan luotettavista oraakkeleista.
2. Datan raportointi - Oraakkelit keräävät off-chain dataa ja raportoivat sen lohkoketjuun.
3. Tulosten yhdistäminen – tilaaja määrittää miten tulokset yhdistetään, tässä on monia vaihtoehtoja (voidaan käyttää keskiarvoa, poistaa selvästi vääriä vastauksia, käyttää vastausta joka saa eniten ääniä, etc). Yhdistetty tulos raportoidaan tilaajalle.
Lohkoketjun ulkopuolinen (ns. off-chain) osuus järjestelmästä:
Lohkoketjun ulkopuolinen osuus kattaa tiedon keruun määrätyistä lähteistä ja tiedon raportoinnin lohkoketjuun. Ensimmäisessä versiossa ChainLink protokollasta tulosten kerääminen ja yhdistäminen (vrt. konsensus) tapahtuu on-chain tasolla (CHAINLIN-SC:n kautta). Kuitenkin jatkossa ChainLink pyrkii tarjoamaan mahdollisuuden luoda myös tietojen yhdistämisen ja tähän liittyvän konsensuksen off-chain tasolla. Tällöin siis kaikkien oraakkelien ilmoittamat tulokset kerätään yhteen lohkoketjun ulkopuolella, ja vain lopullinen yhdistetty tulos syötetään yksittäisenä transaktiona lohkoketjuun. Tämä vähentää lohkoketjun kuormitusta ja laskee protokollan käyttökustannuksia. Käyttäjien on myös mahdollista luoda omia lisäosia off-chain osuuteen jotka mahdollistavat oraakkeleille lisäpalveluiden tarjoamisen (esim. off-chain laskenta, datalouhinta, lohkoketju ulkopuolisen maailman kanssa kommunikointi, yms).
Ensimmäisen version ratkaisu tarkemmin:
Oraakkelilla voisi syntyä houkutus kopioida toisen oraakkelin julkaisema vastaus omakseen, ja välttää näin oikean datalähteen seuraamiseen liittyvät kulut (ns. classroom attack). Tämän vuoksi protokolla käyttää commit-reveal ratkaisumallia, missä jokainen oraakkeli lähettää ensin vastauksestansa kryptografisesti salatun tiivistetyn version (commit), ja nämä tallennetaan lohkoketjuun. Kun riittävä määrä salattuja versioita vastauksista on lähetetty, jokainen oraakkeli paljastaa todellisen vastauksensa ja vain mikäli vastaus täsmää salatun version kanssa se hyväksytään. Tämän jälkeen lohkoketjuun tallennetuista hyväksytyistä versioista yhdistetään CHAINLINK-SC:n toimesta USER-SC:lle annettava vastaus.
Jatkossa käytettävä ratkaisu tarkemmin:
Mikäli halutaan muodostaa oraakkeleiden ryhmässä ryhmän enemmistön hyväksymä yhteinen konsensus, törmätään samankaltaisiin ongelmiin kuin muissakin DLT konsensuksissa, (mm. silloin kun halutaan määrittää lohkoketjun yhteinen konsensus). Kuitenkin oraakkelien kohdalla ongelmassa on muutamia eroja: Oraakkelit pyrkivät luomaan vastauksen joka on yhdistetty useamman oraakkelin vastauksesta, ei ainoastaan äänestämään oikeasta vastauksesta. Mikäli vaihtoehtoina on A tai B, oraakkelien tulisi kyetä valitsemaan näistä toinen. Toisaalta ongelmana voi olla esimerkiksi arvioida lämpötilaa eri sensoreiden antaman datan perusteella. Tällöin rehellisetkin oraakkelit voivat antaa toisistaan poikkeavia lämpötila-arvoja ja järjestelmän tulisi muodostaa jonkinlainen keskiarvo vastauksista. Monet klassiset tavat millä hyökkääjä voi hyökätä tavanomaiseen lohkoketjuun ovat mahdollisia myös oraakkelien konsensuksen suhteen, ja järjestelmän tulisi kyetä torjumaan näitä ainakin riittävällä luotettavuudella.
ChainLink pyrkii jatkossa muodostaan off-chain konsensuksen käyttäen tiettyä treshold signature menetelmää. (Chainlink käyttää nimenomaan Schnorr signaturess menetelmää.) Tässä menetelmässä oraakkeleilla on yhteinen public key (pk), ja sitä vastaava private key, joka jaetaan osiin kaikkien mukana olevien oraakkeleiden kesken, niin että jokaisella oraakkelilla on erillinen private key /public key pari. Jokainen oraakkeli pystyy luomaan osittaisen allekirjoituksen, mutta tarvitaan ennalta määrätty osuus oraakkeleita luomaan kokonainen allekirjoitus tuloksesta. Jokaisen oraakkelin luoma osittainen allekirjoitus voidaan tarkistaa suhteessa yhteiseen public key (pk) suhteen. Näin ollen osittaiset allekirjoitukset vastaukselle A voidaan yhdistää yhteiseksi allekirjoitukseksi Sig_sk(A), ja lisäksi tarvitaan riittävän monta oraakkelia luomaan onnistunut allekirjoitus (treshold ylittävä määrä allekirjoituksia).
Huomioitavaa on, että oraakkelit voisivat edelleen keskenään viestiä tulostaan, jolloin vain yhden oraakkelin tarvitsisi hankkia vastausta alkuperäisestä lähteestä (=freeloading). Tämä pyritään estämään järjestelmällä jossa tilaaja maksaa vain niille oraakkeleille, jotka ovat siteeranneet alkuperäistä datalähdettään vastauksessaan. Off-chain järjestelmä käyttää niin ikään commit-reveal ratkaisumallia (vrt. ensimmäisen version ratkaisu edellä), mutta off-chain järjestelmässä commitment ja vastaus lähetetään ainoastaan muille oraakkeleille ja tilaajalle.
Ratkaisu vaiheittain:
Alkuvalmistelu:
1. Luodaan treshold signature järjestelmän vaatimat avaimet oraakkeleille
2. Orakkelit keräävät datansa datalähteistään
3. Lasketaan osittainen allekirjoitus
Commitment lähetys:
4. Lähetetään commitment muille oraakkeleille
5. Odotetaan, kunnes riittävä määrä commitmenteja on saatu muilta oraakkeleilta
6. Lähetetään kerätyt commitmentit tilaajalle
Valmistaudutaan vastausten jakamiseen:
7. Lähetetään viesti ”valmiina” muille oraakkeleille
8. Odotetaan kunnes riittävästi ”valmiina” viestejä on vastaanotettu
Vastausten jakaminen
9. Lähetetään vastaukset muille oraakkeleille
10. Odotetaan, kunnes riittävä määrä vastauksia on saatu muilta oraakkeleilta
Lopullisen vastauksen laskenta
11. Mikäli Chainlink SC:ssä ei vielä ole nähtävillä yhdistettyä vastausta
12. Yhdistetään kerätyt vastaukset lopulliseksi tulokseksi
13. Lähetetään lopullinen tulos Chainlink-SC
14. Lähetetään edeltävästi kerätyt vastaukset tilaajalle (jotta tilaaja voi varmistua oikein lasketusta tuloksesta)
Ratkaisun rajoitukset:
Ratkaisun myötä oraakkeli ei voi kopioida vastausta toiselta, sillä commitment ja vastausten jakaminen on erotettu toisistaan. Lisäksi oraakkelin täytyy siteerata alkuperäistä datalähdettä vastauksessaan, joten ”freeloading” ei suoranaisesti onnistu. (Kuitenkin ns. sybil attack on edelleen mahdollinen, tästä lisää myöhemmin mm. kohdassa Certification service). Kuitenkin ratkaisussa rehelliset oraakkelit voivat jäädä ilman maksua, mikäli eivät ehdi mukaan protokollan eri vaiheisiin. Tämä johtuu siitä että protokolla on ns. asynkronoitu, eli etenee seuraavaan vaiheeseen aina kun tietty kynnysarvo on ylitetty. Tämän voisi estää lisäämällä ”odota” komennon vaiheiden väliin, jolloin oraakkelien tulisi odottaa tietty määritelty aika ennen seuraavaan vaiheeseen siirtymistä. Järjestelmä olisi tuolloin synkronoitu, mikä kuitenkin hidastaisi protokollaa ja sopivan aikamääreen määritteleminen on avoin kysymys. Lisäksi vaiheessa 10-13 usea oraakkeli voi lähettää yhtä aikaa vastauksensa lohkoketjuun, mikä ei ole toivottavaa. Tätä voidaan osin ehkäistä seuraamalla Chainlink-SC:n lisäksi mm. mempooleja, ja muutoinkin odottavia transaktioita. Osin avoimia kysymyksiä on lisäksi: miten salattuja avaimia hallinnoidaan nodejen liittyessä, ja lähtiessä oraakkelisopimuksesta? Tähän on erinäisiä teknisiä ratkaisuja, mitä ei white paperissa käyty tarkemmin läpi.
ChainLink protokollan rakenne (eli miten itse ohjelma on rakennettu):
ChainLink Core – protokollan ydin, joka jakaa tehtävät ja yhdistää protokollan lohkoketjuun. Järjestelmän tehtävät ovat nimeltään assignment ja ne jakautuvat pienempiin osioihin = subtasks. Yksittäinen subtask käsitellään kerrallaan ja sen tulos siirtyy seuraavalle subtask:lle. Yksittäinen subtask voi esimerkiksi kääntää tapahtuman halutulle lohkoketjulle.
Ulkoiset adapterit:
ChainLink protokollan tarjoamien subtask:n lisäksi protokolla mahdollistaa ulkoisten adapterien luomisen. Näillä ChainLink voidaan saada esimerkiksi keskustelemaan halutun ohjelmointikielen, tai käyttöliittymän kanssa.
Subtask Schemas: (JSON Schema)
Ulkoiset adapterit ja käyttäjien luomat omat subtaskit voivat aiheuttaa järjestelmään yhteensopivuus ongelmia. Ne pyritään minimoimaan käyttämällä JSON Schema protokollaa (JSON on datastruktuuri, ja JSON Schema on yleisesti käytetty JSON spesifikaatio). JSON Schema määrittää mitä syötteitä mikäkin adapteri tarvitsee ja miten ne tulisi muotoilla. Samoin spesifikaatio määrittelee miten subtask:n tuottama data tulisi muotoilla. JSON Schema määrittää ”järjestelmän pelisäännöt”, jotta yhteensopivuus ongelmilta vältyttäisiin.
Alla on kuvattu, miten data siirtyy järjestelmässä ostajan tilauksesta (USER-SC) ulkoiseen käyttöliittymään (=data lähteeseen) ja takaisin
USER-SC ↔ CHAINLINK-SC ↔ ChainLink Core ↔ Adapteri ↔ Ulkoinen käyttöliittymä
ChainLink Security Services
ChainLinkin white paper esittää mekanismeja millä lisätään entisestään oraakkelien luotettavuutta. Trusted hardware käsitellään omassa osuudessaan. Security Services ovat kuin lisäpalveluita, mitä käyttäjät voivat halutessaan hyödyntää. Ne antavat joko lisätietoa oraakkeiden suorituskyvystä, tai tarjoavat lisäpalveluita käyttäjille (kts. Contract-Update Service). Jatkossa tarkoituksena on, että ulkopuoliset yritykset ja tahot voivat tarjota kilpailevia tai erilaisia palveluita ChainLinkin tarjoamien palveluiden lisäksi.
Validation System
Tämä järjestelmä tarkkailee on-chain tapahtumia ja ilmoittaa palvelua ostaville tahoille:
1. Kuinka suuren osan ajasta oraakkeli on online ja tarjoaa palvelua
2. Kuinka usein oraakkeli antaa vääriä vastauksia. (Väärä vastaus määritellään palvelusopimuksessa. Esimerkiksi lämpötilaa ilmoitettaessa pienet poikkeamat keskiarvosta voidaan hyväksyä oikeaksi vastaukseksi.)
Kun oraakkelin toiminta siirtyy jatkossa enemmän off-chain tasolle, yllä olevia tietoja ei saada suoraan lohkoketjusta. Tällöin suunnitelmana on luoda validointijärjestelmästä smart contract, joka palkitsee oraakkeleita jotka välittävät sille todisteita muiden oraakkeleiden vääristä vastauksista. Väärät vastaukset on helppo todistaa, sillä oraakkelit allekirjoittavat omalla avaimellaan antamansa vastaukset. Vaikeamaa on todistaa, milloin node on offline ja ei vastaa pyyntöihin. Chainlink esittää järjestelmän missä ryhmän jokainen oraakkeli allekirjoittaisi omalla avaimellaan ne vastaukset joita on saanut, ja toimittaisi nämä tiedot validointijärjestelmän smart contractille. Mikäli riittävän usean oraakkelin välittämän tiedon perusteella yksittäinen oraakkeli ei ole välittänyt vastauksia, voidaan tämän oraakkelin ajatella olevan offline.
Kun validointi järjestelmä on kerännyt tarvittavat tiedot se siirtää ne lohkoketjuun, jotta jokainen käyttäjä pystyy seuraamaan oraakkelien suorituskykyä lähes reaaliajassa.
Reputation System
Validation järjestelmä luo pohjan luottamukselle. Sen lisäksi reputation järjestelmä tarjoaa lisää tietoa oraakkelin valintaan. Reputation järjestelmä tarjoaa kokonaisvaltaisempaa tietoa oraakkeleista ja koska tietoa on paljon, ei ole tarkoituksen mukaista tallettaa kaikkea tätä lohkoketjuun. Reputation järjestelmän tiedot välitetään suoraan järjestelmästä tietoa pyytävälle käyttäjälle lohkoketjun ulkopuolelta. Reputation järjestelmä tarjoaa mm. seuraavia tietoja:
1. Vastaanotettujan tehtävien kokonaismäärä
2. Suoritettujen tehtävien kokonaismäärä
3. Kuinka suuren osuuden tarjotuista (oraakkelille mahdollisista) tehtävistä oraakkeli on vastaanottanut
4. Keskimääräinen vastausaika
5. Rangaistusmaksujen määrä (palvelusopimus voi määrittää rangaistusmaksu oraakkelille, mikäli se ei suorita tehtävää palvelusopimuksen määrittämällä tavalla)
Certification Service
ChainLink voi myös tulevaisuudessa ottaa käyttöön sertifikointijärjestelmän, millä estetään ns. Sybil- and mirroring-hyökkäykset.
ChainLinkin datan yhdistämiseen ja konsensuksen muodostamiseen suunniteltu (nykyinen on-chain ja jatkossa suunniteltu off-chain) järjestelmä estää ns. freeloading hyökkäyksen, sillä huijaava taho ei voi kopioida rehellisten tahojen vastauksia. Kutienkaan järjestelmä ei estä ns. sybil-hyökkäystä. Tässä hyökkäyksessä hyökkääjä kontrolloi useita erillisiä oraakkeleita (mahdollisesti samalta laitteelta), ja yrittää saada riittävän enemmistön oraakkeliryhmässä tuottaakseen vääriä vastauksia sopivina hetkinä. Tämä voidaan myös toteuttaa useamman hyökkääjän yhteistyönä. Lisäksi hyökkääjä voi vähentää hyökkäyksen kuluja lähettämällä yhden tietolähdeteen tiedon kaikille hyökkääjän omille oraakkeleilleen (=mirroring). Tämä tekee hyökkääjän toiminnasta halvempaa verrattuna tilanteeseen, missä hyökkääjä joutuisi keräämään dataa jokaisella oraakkelilleen erikseen. Näin olleen hyökkääjällä on helpompaa kerätä hyvää mainetta oraakkeleilleen, verrattuna vastaavaan määrään rehellisiä oraakkeleita. Hyökkääjän käyttäessä vain yhtä tietolähdettä vastauksen luotettavuus heikkenee. Kuitenkaan tämä ei yksistään aiheuta niin suurta vaaraan tilaajalle, kuin yllä kuvattu sybil-hyökkäys.
ChainLink tarjoaa vapaaehtoisen mahdollisuuden oraakkeleille osallistua sertifikointijärjestelmään. Tässä järjestelmä luotettu kolmas osapuoli tarkkailee sekä validointi järjestelmää, että tekee lisäksi jälkikäteen tarkastuksia oraakkelin antamista vastauksista suhteessa alkuperäiseen tietolähteeseen, erityisesti silloin kun tämä tieto liittyy kohde smart contractissa suuriin summiin. Osallistuminen sertifikointiin on oraakkelille maksullista, mutta lisää toisaalta oraakkelin luotettavuutta. White paperin arvion mukaan tällainen oraakkeli voisi pyytää palveluistaan niin paljon korkeampaa palkkiota, että sertifikointijärjestelmällä olisi todennäköisesti kysyntää, ja sen ylläpitäminen olisi taloudellisesti kannattavaa.
Contract-Update Service
Contract-Update järjestelmä on suunnattu tilanteeseen missä smart contract toimii aiemmin suunnittelemattomalla tavalla. Täydellisen smart contract ohjelman kirjoittaminen on vaikeaa ja esimerkiksi toimintaympäristön muutokset, ohjelmointivirheet tai onnistunut hakkerointi voivat saada smart contractin toimimaan suunnittelemattomasti. Contract-update järjestelmän ensimmäisessä versiossa smart contractin luonut taho voi halutessaan tehdä uuden smart contractin, jolloin järjestelmä mahdollistaa uuden palvelusopimuksen luomisen ja uusien oraakkelien valinnan helposti aiemman palvelusopimuksen pohjalta. Tällöin uusi palvelusopimus luodaan kuitenkin teknisesti kuten muutkin palvelusopimukset.
ChainLinkissä.Jatkossa on suunnitteilla järjestelmä, mikä mahdollistaa aiemman palvelusopimuksen siirtämisen uuteen smart contractiin. Tällöin ei tarvita uutta palvelusopimusta ja samat oraakkelit voivat jatkaa datan toimittamista, mutta kohde smart contract vaihtuu. CHAINLINK-SC sisältää silloin ohjeen, minkä mukaan palvelusopimus siirtyy uuteen CHAINLINK-SC:iin mikäli kyseisestä CHAINLINK-SC:sta tulee päivitetty versio. Siirtymisestä voidaan tehdä myös ehdollista, jolloin siirtyminen vaatii toteutuakseen luotetun kolmannen tahon hyväksynnän. Tällainen järjestelmä tarjoaa takaportin tilanteeseen, missä smart contract toimii poikkeavasti. Kuitenkin järjestelmä voi myös avata uusia mahdollisuuksia hakkeroinnille ja sopimuksen väärin käytölle, joten päätös contract-update palvelun käytöstä tekee tilaaja siinä vaiheessa, kun CHAINLINK-SC luodaan.
Trusted hardware
ChainLink nojaa pidemmän tähtäimen visiossaan vahvasti ns. trusted hardware käyttöön. Trusted hardware pyrkii lisäämään laskennan luotettavuutta hardware ratkaisujen keinoin. Lisäksi trusted hardware parantaa tietosuojaa, ja jatkossa mahdollisesti myös ulkoistaa lohkoketjussa tapahtuvaa laskentaa oraakkeleille. Lisäksi ChainLink esittää palvelutarjoajien infrastruktuurin muutoksia, millä voitaisiin mahdollistaa luotettavan tiedon tallentaminen lohkoketjuun ilman oraakkeleja. Seuraavassa käydään nämä visiot tarkemmin läpi:
ChainLink nojaa tulevaisuuden visiossaan erityisesti Intel Software Guard eXtensions (=SGX) järjestelmään. Tässä tietty ohjelma voidaan suorittaa piirillä omassa fyysisesti rajatussa alueessaan ja tällä tavalla ulkopuolinen ohjelma ei pysty vaikuttamaan ohjelmaan (=integriteetti). Rajattu alue suojelee ohjelman tietoturvaa, tarkoittaen että data, koodi ja koodin tila ovat näkymättömissä piirin muille osioille. SGX pyrkii suojaamaan rajatulla alueella toimivaa ohjelmaa jopa piirin käyttöjärjestelmältä ja käyttöjärjestelmän (ja piirin) haltijalta.
Aiempiin trusted hardware ratkaisuihin nähden SGX mahdollistaa, että rajatulla alueella toimiva järjestelmä luo todistuksen järjestelmässä olevasta ohjelmasta, ja todistus voidaan vahvistaa etäyhteyttä käyttäen. Näin ollen luotettu kolmas taho voi vahvistaa SGX järjestelmässä toimivan ohjelman aitouden. Tietty ohjelma voidaan liittää tiettyyn julkiseen avaimeen ja näin voidaan luoda salattuja, ja aidoksi todistettuja yhteyksiä toisiin ohjelmiin. Periaatteessa rajatussa ympäristössä olevan ohjelman aitous voidaan varmistaa SGX:ssä helposti. Mikäli tätä käytetään oraakkeli järjestelmässä, ohjelma voi lisäksi ottaa yhteyden esim. internetsivuun HTTPS välityksellä ja näin varmistua, että ulkopuolinen taho ei pääse peukaloimaan dataa. SGX vaikeuttaa järjestelmän väärinkäyttöä, datan väärennöstä, Sybil-hyökkäystä etc. Erityisen hyödyllinen järjestelmä on kuitenkin luomaan tietosuojaa.
Tietosuoja
Tavanomaisin menetelmin on erittäin vaikea saada korkeaa tietosuojaa oraakkelijärjestelmään. Tiedon keruu pyynnöt lähetetään lohkoketjun kautta, jolloin ne ovat kaikkien nähtävillä. Vaikka pyynnöt tehtäisiin salatulla järjestelmällä, oraakkeli joutuu kuitenkin purkamaan salauksen osatakseen hakea tietoa oikeasta tietolähteestä. Periaatteessa SGX järjestelmää käyttävä oraakkeli voi kuitenkin toimia kuin luotettu kolmas osapuoli ja käsitellä dataa rajatulla piirin alueella, niin että oraakkelin haltija ei pysty havainnoimaan tai puuttumaan dataan tai datan keruu pyyntöön.
Town Crier system (=TC) on Ethereumille kehitetty järjestelmä, mikä mahdollistaa Ethereumin yhdistämisen SGX järjestelmään oraakkelien luomiseksi. TC on ChainLinkin yhteistyöprojekti. Siinä tiedon keruu pyyntö lähetetään TC järjestelmään, ja kryptataan TC palvelun tarjoajan public key:llä. (tämä tapahtuu siis palvelun tarjoajan SGX järjestelmässä ja ei näy palvelun tarjoajalle). Trusted hardwarea purkaa salauksen ja ottaa yhteyttä datalähteeseen HTTPS protokollalla. Vastaanotetusta tiedosta seulotaan vain haluttu vastaus, ja tämä lähetetään on-chain. Vain lähetetty on-chain vastaus näkyy ulkopuolisille (mukaan lukien TC-palvelun tarjoaja). TC-järjestelmä voi myös kerätä dataa useammasta lähteestä ja suorittaa luotettua laskentaa useammasta lähteestä kerätylle tiedolle (esim. laskea keskiarvon). TC-järjestelmällä on myös mahdollista tehdä monimutkaisempaa tiedon keruuta ja käsittelyä.
SGX järjestelmä validoi käytössä olevan ohjelman seuraavasti. Ennen ohjelman suorittamista järjestelmä ottaa yhteyttä Intel Authentication Service – IAS, ja luo todistuksen ohjelman aitoudesta. Todistus varmistaa mm. että ohjelmassa määrätyt tehtävät suoritetaan SGX järjestelmässä, missä on asianmukaiset hardware ominaisuudet, että järjestelmän luotettu toimintaympäristö on päivitetty ajan tasalle, ja että vain valtuutettuja algoritmeja käytetään ohjelman tehtävien suorittamisessa.
Off-chain computation
SGX-järjestelmän ja TC-järjestelmän avulla raja oraakkelin ja lohkoketjun välillä muuttuu joustavaksi. Oraakkeli voi esimerkiksi hallinnoida käyttäjätunnuksia, louhia dataa, tehdä hajautettua laskentaa etc. Jo nyt ChainLink tukee regex-pohjaista koodikieltä, minkä myötä käyttäjät voivat joustavasti ohjelmoida oraakkeleille erilaisia tehtäviä. ChainLinkin pitkän tähtäimen suunnitelmassa oraakkelit ovat keskeinen off-chain laskentaa suorittava taho. Vain välttämätön data ja laskenta tapahtuu on-chain tasolla. Tämä lisää tietoturvaa, vähentää laskennan kustannuksia ja mahdollistaa ratkaisuja ja käyttötarkoituksia jotka ovat vielä toistaiseksi mahdottomia.
Infrastruktuurin muutokset
Mikäli dataa tarjoavat tahot allekirjoittaisivat digitaalisesti datansa, voitaisiin datan autenttisuus helposti varmistaa ilman oraakkeli järjestelmää. HTTPS protokolla ei nykyisin mahdollista datan allekirjoitusta. Kuitenkin se sisältää public-key infrastruktuurin (PKI) minkä mukaan servereillä täytyy olla sertifikaatit. Tätä voitaisiin periaatteessa käyttää datan allekirjoittamiseen. Tämän myötä on kehitetty TLS lisäosa, millä HTTPS serveri voi digitaalisesti allekirjoittaa halutun osan lähettämästään datasta. Kuitenkaan TLS ei ratkaise koko oraakkeliongelmaa mm. seuraavista syistä:
1. TLS käyttöönotto on hidas prosessi ja vaatii jokaisen datan tarjoajan erikseen ottavan järjestelmän käyttöön, (ellei järjestelmästä tule osa HTTPS standardia).
2. Järjestelmä ei voi suorittaa datan yhdistämistä ja laskentaa
3. TLS järjestelmällä allekirjoitetun datan varmentaminen on kohtalaisen kallista (vaatii paljon laskentatyötä)
4. TLS ei mahdollista tietosuojaa samalla tavoin kuin SGX-järjestelmä
Oma analyysi
Trusted Hardware ja SGX
Ennen kuin paneudun ChainLink järjestelmään tarkemmin, en malta olla puuttumatta trusted hardware kysymykseen. Aihe oli minulle täysin vieras ennen ChainLinkiin tutustumista. Mikä on trusted hardwaren käytännön potentiaali? Miten se ja DLT suhtautuvat toisiinsa? Mitä ongelmia trusted hardwaren käytössä on?
Lähdin hahmottamaan näitä kysymyksiä pohtimalla mitä voisimme tehdä, jos käytössä olisi täydellinen trusted hardware? Mikäli luotettu kolmas taho pystyy etäältä varmistamaan ohjelman aitouden, ja hardware järjestelmä estäisi ulkopuolisen tahon puuttumisen ohjelmaan, silloin luottamus kyseiseen ohjelmaan olisi yhtä suuri, kuin luottamus luotettuun kolmanteen tahoon. IoT maailmassa tämä olisi mullistavaa. Jokaisen pienen laitteen ohjelmisto olisi yhtä luotettava kuin varmennusta tarjoavan luotetun kolmannen tahon. Luotettu varmennuspalvelua tarjoava kolmas taho voisi itse olla auditoitu useamman muun yrityksen ja viranhaltijan toimesta, jolloin luottamuksen taso olisi erinomainen. Voisimme mahdollisesti tehdä ohjelman, mikä mahdollistaisi tokenien vaihdon ilman DLT protokollaa, eikä se häviäisi luotettavuudessaan juuri DLT protokollille. Tieto transaktiosta tallentuisi vain transaktiota suorittavien osapuolten laitteisiin, mutta koska voisimme luottaa laitteissa oleviin ohjelmiin lähes täysin, kukaan ei voisi luoda tokeneita tyhjästä tai tehdä ns. double spend -tilannetta. Ohjelma ei yksinkertaisesti sallisi sitä.
Toisaalta etäällä suoritettu laskenta voitaisiin tehdä aina vain yhdellä laitteella (vrt. smart contract), ja näin voitaisiin säästää huimasti laskentakuluissa. Mikäli ulkopuolinen taho haluaisi peukaloida yhdenkään IoT laitteen antamia vastauksia laskennasta tai datasta, sen tulisi pystyä korruptoimaan validointia tarjoava luotettu kolmas taho. Tulisiko siis myydä kryptot ja ostaa Intelin osakkeita?
Aina kun tulee uusi turvallisena pidetty järjestelmä, valtava määrä hakkereita ja tietoturva asiantuntijoita yrittää murtaa järjestelmän. Myös Intel SGX järjestelmää kohtaan on kehitetty monia hyökkäysmekanismeja, joista kuitenkin monet ovat enemmän teoreettisia, tai akateemisia kuin käytännön uhkia. Kuitenkin löysin seuraavan artikkelin: ”Practical Enclave Malware with Intel SGX” Schwarz, et. all. Missä tutkijat onnistuvat ujuttamaan mallwaren SGX-järjestelmän turvamekanismien ohi, ja tämän jälkeen kaappaamaan koko järjestelmän. Asian tekee erityisen ongelmalliseksi, että mikään ulkopuolinen virusten torjunta järjestelmä ei pääse arvioimaan mitä piirilevyn eristetyllä alueella tapahtuu. Mallware on ns. ”super-mallware”, ja voi touhuta rajatussa järjestelmässä mitä haluaa. Intelin vastaus ongelmaan oli: ”The value of Intel SGX is to execute code in a protected enclave; however, Intel SGX does not guarantee that the code executed in the enclave is from a trusted source," ja tätä seurasi suositus ladata SGX:lle tallennetut ohjelmat aina luotetusta lähteestä, ja kiitokset tutkijoille.
Yllä oleva lainaus kiteyttää paljon oleellista trusted hardware:n rajoitteista. Piirin omistaja lopulta ratkaisee mistä ohjelman ladataan järjestelmään. Mikäli piirin omistaja päättää syöttää SGX:ään viruksen, on hyvin vaikeaa tehdä läpäisemätöntä palomuuria, mikä torjuisi kaikki mahdolliset hyökkäykset. Toisaalta piirin omistajalla on kaikki mahdollisuudet rakennella hyökkäyksiä rajatun alueen ulkopuolella. SGX tekee suoritetun ohjelman korruptoimisesta vaikeampaa piirin haltijalle, mutta se ei tee sitä mahdottomaksi. Mikäli ohjelma kuitenkin ladataan luotetusta lähteestä, voi olla mahdollista rakentaa trusted hardware järjestelmä, mitä ulkopuolinen taho ei voi murtaa.
Toisaalta trusted hardwarea voi lähestyä toisesta näkökulmasta: Jos trusted hardwarella saavutetaan parhaimmillaankin vain sama luottamus kuin mitä luotetulla kolmannella taholla, eikö ole yksinkertaisempaa ulkoistaa tehtävä suoraan luotetulle kolmannelle taholle? On paljon cloud computing järjestelmiä ja suuryritysten datakeskuksia, mitkä voisivat toimia oraakkeleina miljoonille smart contracteille. Miksei käyttää niitä? Toisaalta mikäli oraakkelina toimii luotettu kolmas taho, ja smart contractin toiminta riippuu oraakkelin vastauksesta, voi monissa käyttökohteissa koko järjestelmän (myös smart contractin) ulkoistaa luotetulle kolmannelle taholle. Tämä kysymys liittyy myös siis DLT:hen yleisesti. Onko järkevämpää valita käyttötarkoitukseen DLT järjestelmä, vai luotettu kolmas taho?
Tämän kaltaisissa pohdinnoissa palataan aina takaisin IoT maailmaan, mikä on DLT järjestelmien suurin käyttökohde. IoT maailmassa kaikkea dataa ja laskentaa ei voi ulkoistaa pilvipalveluille, sillä datan siirtäminen edes takaisin on sekä liian kallista, että mahdotonta. Sensori voi kerätä valtavan määrän dataa ja datayhteyksien kaistalaajuus mahdollistaa vain oleellisen tiedon eteenpäin lähettämisen. Tarvitaan siis väistämättä paikallista laskentaa, ja datan analyysiä. Tällä hetkellä DLT:n tuomaa luotettavuutta käytetään lisäksi silloin kun halutaan luoda luottamusta useamman eri yrityksen/tahon kesken, eikä yksittäisen tahon tarjoaman palvelun luotettavuus riitä kaikille.
Johonkin kahden yllä olevan pohdinnan väliin asettuu trusted hardware:n käyttöpotentiaali. Trusted hardware tekee laskennasta luotettavampaa, sillä järjestelmien hakkerointi on selvästi vaikeampaa. Trusted hardware myös lisää tietoturvaa. Monet asiaan vihkiytyneet ovat arvioineet, että tulevaisuudessa suuri osa IoT laitteista on FPGA/ASIC pohjaisia, eli monet IoT laitteet voi olla jopa ns. ”piirille kirjoitettua koodia” (ASIC), mitä on mahdotonta jälkikäteen ohjelmoida/muuttaa. Tällainen siru on vielä SGX järjestelmää vaikeampi hakkeroida (,tosin siru suorittaa vain ennalta määrättyä tehtävää). Joka tapauksessa tulevaisuudessa hardware puolelta tullaan todennäköisesti näkemään monia eri ratkaisuehdotuksia, joilla lisätään laitteiden luotettavuutta.
Infrastruktuurin muuttuessa monet laitteet tulevat todennäköisesti myös suoraan siirtämään dataa DLT järjestelmiin, ja varmentamaan lähettämänsä datan digitaalisella allekirjoituksella. Tällöin oraakkelia ei tarvita datan siirtoon, mutta toisaalta rajattu laitteiden joukko voidaan edelleen tarvita datan keräämiseksi yhteen ja keskiarvon laskemiseksi. Sen lisäksi on vielä kehitteillä ns. Decentralized Identifiers (DID) ratkaisuja. DID järjestelmässä luodaan erilaisia fyysiseen maailmaan liittyviä tunnisteita, joiden pohjalta rakennetaan luottamusta järjestelmän toimijoihin. Esimerkiksi retina-skannauksen tulokseen, tai tehtaassa laitteeseen liitettyyn tunnisteeseen linkitetään oma julkinen ja yksityinen salausavain, ja näitä käytetään DLT verkossa estää mm. Sybil hyökkäyksiä. DID ratkaisuissa kukaan yksittäinen taho ei hallinnoi toimijoiden identiteettiä, toisin kuin perinteisissä valtion tarjoamissa identiteettiratkaisuissa (esim. passi).
DLT ratkaisut tulevat siis todennäköisesti tulevaisuudessa liittymään yhä vahvemmin fyysiseen maailmaan, ja monet fyysisen maailman innovaatiot lisäävät DLT ratkaisujen luotettavuutta. Onko SGX siis oikea suunta? Se selvästi lisää ChainLink järjestelmän luotettavuutta, mutta yksistään se ei estä kaikkia hyökkäyksiä. Kuitenkin yhdessä ChainLink:in muiden ratkaisujen kanssa se mahdollistaa erittäin luotettavan oraakkelijärjestelmän. Se myös vie oraakkelien tietoturvan aivan uudelle tasolle, vaikka taitava hakkeri voikin edelleen hakkeroida oman SGX sirunsa, ja saada järjestelmän suojaaman tiedon luettua. Hajautetussa laskennassa tulkitsen SGX:n potentiaalia samojen rajoitteiden kautta. Se lisää luotettavuutta, jolloin mahdollisesti pienempi ryhmä oraakkeleita riittää suorittamaan laskentaa, mutta mikäli tarvitaan erittäin luotettavia tuloksia, ei voida tukeutua pelkästään SGX -järjestelmään.
ChainLink
ChainLinkistä lukiessa ymmärtää, miksi se on viime aikojen kovimpia nousijoita krytovaluutoissa. Se ratkaisee ongelmaa mikä on todellinen, ja mihin moni muu ei ole tarjoamassa ratkaisua. ChainLinkillä on kiistaton first mover-etu oraakkeliratkaisuna. Itse ratkaisuehdotuksesta lukiessa en löytänyt paljoa kritisoitavaa. Oraakkelijärjestelmät ovat tosin minulle vieraampi aihe kuin kryptovaluutat, ja en tiedä mitä kaikkea muut ovat yrittäneet. Oraakkeliongelmasta muutama sana: Silloin kun DLT järjestelmän smart contractit pohjaavat perinteiselle ajatukselle, missä kaikki järjestelmän laskijat laskevat jokaisen smart contractin ja muodostavat yhteisen konsensuksen, syntyy yllä kuvattu oraakkeli ongelma. Näissä tilanteissa sekä ChainLinkin nykyiset ratkaisut, että tulevaisuuden visiot ovat mielestäni looginen tie edetä ongelmassa. Kuitenkin esimerkiksi Iotan smart contract -järjestelmässä smart contract:in luoja valitsee haluamansa tahot suorittamaan laskentaa. Tällöin ei tarvita erillistä oraakkelijärjestelmää, sillä smart contractit toimivat jo itsessään samojen periaatteiden mukaisesti kuin ChainLink (valitut tahot suorittavat laskennan). Tällaisissa järjestelmissä oraakkeli on vain yksi smart contract:in muoto.
ChainLinkin heikkoudeksi (tällä hetkellä) voi mainita, että se on ERC20-token. Se siis pohjaa Ethereumiin ja sisältää kaikki Ethereumin järjestelmän rajoitukset. Datan tallentaminen ketjuun on kallista (vrt. Iotassa ilmaista), tps (transaktions per second) luvut ovat matalia, ja voi kestää kauan ennen kuin tilisiirto vahvistetaan. Lisäksi järjestelmän käyttökustannukset vaihtelevat suuresti verkon kuormituksen mukaan. Toisaalta (ainakin toistaiseksi) on joitain käyttökohteita, missä Ethereumin kaltainen DLT verkko on hyödyllinen. Silloin kun smart contractilla hallinnoitava omaisuus on suurta, tilisiirtoja tapahtuu harvoin, ja vaaditaan korkeaa turvallisuustasoa, Ethereumin kaltainen järjestelmä toimii hyvin. Silloin voidaan sallia myös korkeammat kustannukset ja järjestelmän hitaus. Tällaiset DLT ratkaisut eivät siis tule todennäköisesti kokonaan häviämään lähivuosina, vaikka halvempia ja nopeampia smart contract järjestelmiä kehitetään. ChainLink tavallaan yhdistää näihin hitaisiin luotettaviin DLT-verkkoihin modernimpien ja ketterämpien verkkojen ominaisuuksia (mm. halpaa matalamman turvallisuustason laskentaa, luotettavia oraakkeleita, etc). ChainLink voi siis olla myös keino jolla Ethereumin kaltaiset järjestelmät pärjäävät paremmin kovenevassa kilpailussa.
Erityismaininnan ChainLink saa trusted hardware visiostaan, vaikka sillä onkin omat rajoitteensa. Silloin kun hajautettu laskenta siirretään osin oraakkeleihin, tulee kuitenkin aina huomata, että järjestelmä on yhtä vahva kuin sen heikoin lenkki. Mikäli oraakkelissa suoritettu laskenta pettää, ja se määrää smart contractia, on turhaa käyttää itse smart contractiin kallista Ethereumin kaltaista teknologiaa.
ChainLinkin kohdalla kritiikkiä voi myös esittää Link tokenia kohtaan. Periaatteessa mikäli Ethereumin päälle rakennettaan oraakkelijärjestelmä, se voitaisiin rakentaa hyvin ilman erillistä tokenia. Voidaan perustella Link tokenin yhdistävän eri kryptovaluuttojen oraakkelijärjestelmät. Kuitenkin käytännössä Link token vaikuttaa turvaavan lähinnä ChainLink -projektin rahoitusta. Tietysti token myös rikastuttaa kehittäjiään, sekä muita tokenin omistajia, mikäli tokenin arvo nousee edelleen jatkossa. Kryptomaailma ei tarvitsisi uutta tokenia jokaiseen innovaatioon, mutta tämä on ollut talon tapa jo pitkään. Uusi token on paras tapa saada rahaa ja huomiota projektille, joten on myös toisaalta hyvin ymmärrettävää miksi ChainLink päätyi perustamaan oman tokeninsa.
Ehkä keskeisin kysymys pohdittaessa sijoituskohdetta on kuitenkin: ”Minkä ongelman ratkaisisin kyseisellä teknologialla?”Mikäli haluan IoT laitteiden vaihtavan dataa tai tietoa, en harkitsisikaan ChainLinkiä, sillä sen käyttökustannukset ovat toistaiseksi liian kalliit. Mikäli haluaisin automatisoida vakuutuksen, voisi Ethereum + ChainLink olla ratkaisu (esim. saan rahaa, jos lento ilmoitetaan peruutetuksi, tai riittävän pitkä kuivuus kurittaa peltoa). Toisaalta silloin vakuutuksen täytyy olla spesifi tiettyä selvästi todistettavissa olevaa tapahtumaa kohden. Yleistä matkavakuutusta en voisi/haluaisi automatisoida ylipäätään. Jos haluaisin automatisoida suurten summien sijoitusta, tai projektien rahoitusta voisin käyttää järjestelmää, mutta silloin luovuttaisin oikeuden perua ennalta tehdyt suunnitelmat maailman tilanteen muuttuessa. Kenties käyttökohteita voisi löytyä yleisistä taloudellisista sopimuksista. Kun laiva saapuu satamaan riittävän nopeasti siitä hetkestä, kun on määritellyn matkan päässä satamasta (GPS laitteesta saadun tiedon mukaisesti), luotsiveneen kuljettaja saa palkkansa. Tällaiset järjestelmät voitaisiin automatisoida Ethereumiin luodun smart contractin perusteella, ja ChainLink varmistaisi laivan saapumisen ja sijainnin useasta eri lähteestä luotettavasti. Tällaisissa käytännön ongelmissa näen suurimman ChainLinkin potentiaalin, vaikka tällöinkin täytyy huomioida smart contracteihin sisältyvät epävarmuudet. Yllättävä sää, tai laiskan kapteenin kahvitauko vie luotsilaivan palkan. Tällaisia suuren rahan sopimuksia automatisoidessa täytyy punnita aina automatisoinnin hyöty ylipäätään. Automaattinen järjestelmä säästää rahaa, sillä ihmistä ei tarvita vahvistamaan tapahtunutta. Kuitenkin kun summat kasvavat, harvinaisetkin järjestelmän virheet aiheuttavat yhä suurempia tappioita, ja koulutetun ihmisen harkinta tulee yhä tärkeämmäksi.
Yhdistyessään mihin tahansa perinteiseen lohkoketjujärjestelmään ChainLink hyödyttää lohkoketjua ja tekee siitä luotettavamman. Oraakkelijärjestelmän myötä lohkoketjuun syötettyyn dataan voidaan luottaa. Lisäksi järjestelmästä tulee skaalautuvampi, sillä osa datasta voidaan prosessoida ketjun ulkopuolella. Näin ollen mikäli yksikin perinteinen permissionless lohkoketjujärjestelmä lyö läpi ja yleistyy, se hyödyttää ChainLink:iä ja ChainLink todennäköisesti myös em. lohkoketjua. (Permissionless = järjestelmä, missä järjestelmää pyörittävät tahot voivat olla tuntemattomia, vrt. permissioned = järjestelmä missä järjestelmää pyörittää tunnetut osin luotetut tahot.) ChainLink pyrkii yhteensopivaksi kaikkien suurimpien permissionless lohkoketjujen kanssa, mutta mikäli joku selvästi nousee muita edelle, projekti todennäköisesti priorisoi kyseisen lohkoketjun yhteensopivuuden ja voi saavuttaa sen nopeastikin. Tämä on yksi suuri syy sijoittaa ChainLink:iin.
Toisaalta voi perustellusti kysyä, onko perinteisten permissionless-lohkoketjujen aika jo ohi? Tällä hetkellä on viitteitä siitä, että suuryritykset ovat kyllä ottamassa lohkoketjuteknologiaa käyttöön järjestelmien automatisoinnissa, mutta tämä pohjaa suurelti permissioned-lohkoketjuihin. Vain niillä saavutetaan tällä hetkellä riittävä nopeus ja taloudellisuus. Mm. Hyperledger Fabric on tullut yhä suositummaksi ja suuret teknologia jätit tarjoavat permissioned-lohketjupalveluja monille eri teollisuuden sektoreille. Permissionless-teknologialla on selvät edut (ei tarvitse luottaa tiettyyn palvelun tarjoajaan), mutta perinteinen lohkoketjuteknologia ei vain yksinkertaisesti skaalaudu riittävästi, ja lisäksi se on liian kallis. Tällä hetkellä näen DLT teknologian yleistyvän ensin permissioned-teknologian kautta, ja vasta todella hyvin skaalautuvat permissionless-teknologiat voivat jatkossa korvata ketterät pienemmät permissioned-verkot. Permissioned-lohkoketjut eivät samalla lailla hyödy ChainLinkistä, sillä luotettu taho/ryhmä voi toimia niissä sekä lohkoketjun laskijana, että oraakkelina.
TLDR: Tällä hetkellä kallistun kuitenkin siihen, että vaikka ChainLinkin ratkaisu itsessään tekee lähes kaiken oikein, se pyrkii kuitenkin lopulta ratkaisemaan ongelman millä ei todennäköisesti ole riittävää taloudellista hyötyä reaalimaailmaan. Toisaalta, mielipiteeni ChainLinkistä on vaihdellut paljon, ja DLT maailma kehittyy tällä hetkellä niin nopeasti, että saatan edelleen jatkossa vaihtaa kantaani. Lisäksi tämä arvio koskee ChainLinkin yleistymistä teollisuudessa, kryptomarkkinat rakentuvat nykyisin vielä paljon spekulaation varaan, ja Link tokenin arvo voi muuttua paljon riippumatta sen käyttöönotosta teollisuuden eri aloilla.