Blockchain: mikä PoC meidän pitäisi rakentaa?

Silmäsi pelkäävät ja kätesi kutiavat!

Aiemmissa artikkeleissa käsittelimme teknologioita, joille lohkoketjut rakennetaan (Mitä meidän pitäisi rakentaa lohkoketju?) ja tapaukset, jotka voidaan toteuttaa heidän avullaan (Miksi meidän pitäisi rakentaa tapaus?). On aika työskennellä omin käsin! Pilottien ja PoC:n (Proof of Concept) toteuttamiseen käytän mieluummin pilviä, koska... niihin pääsee käsiksi mistä päin maailmaa tahansa, eikä useinkaan tarvitse tuhlata aikaa työlään ympäristön asentamiseen, koska On esiasetettuja kokoonpanoja. Tehdään siis jotain yksinkertaista, esimerkiksi verkko kolikoiden siirtämiseen osallistujien välillä ja kutsutaan sitä vaatimattomasti Bitcoiniksi. Tätä varten käytämme IBM-pilviä ja universaalia lohkoketjua Hyperledger Fabricia. Ensin selvitetään, miksi Hyperledger Fabricia kutsutaan universaaliksi lohkoketjuksi?

Blockchain: mikä PoC meidän pitäisi rakentaa?

Hyperledger Fabric - universaali lohkoketju

Yleisesti ottaen universaali tietojärjestelmä on:

  • Palvelinjoukko ja ohjelmistoydin, joka suorittaa liiketoimintalogiikkaa;
  • Liitännät vuorovaikutusta varten järjestelmän kanssa;
  • Työkalut laitteiden/henkilöiden rekisteröintiin, todentamiseen ja valtuutukseen;
  • Tietokanta, joka tallentaa käyttö- ja arkistotietoja:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Virallinen versio siitä, mikä Hyperledger Fabric on, on luettavissa osoitteessa OnlineLyhyesti sanottuna Hyperledger Fabric on avoimen lähdekoodin alusta, jonka avulla voit rakentaa yksityisiä lohkoketjuja ja suorittaa mielivaltaisia ​​älykkäitä sopimuksia, jotka on kirjoitettu JS- ja Go-ohjelmointikielillä. Katsotaanpa yksityiskohtaisesti Hyperledger Fabricin arkkitehtuuria ja varmista, että tämä on universaali järjestelmä, jolla on vain erityispiirteet tietojen tallentamiseen ja tallentamiseen. Erikoisuutena on, että tiedot, kuten kaikissa lohkoketjuissa, tallennetaan lohkoihin, jotka sijoitetaan lohkoketjuun vain, jos osallistujat pääsevät yksimielisyyteen ja tallennuksen jälkeen dataa ei voida hiljaa korjata tai poistaa.

Hyperledger-kangasarkkitehtuuri

Kaavio näyttää Hyperledger Fabric -arkkitehtuurin:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Organisaatiot — organisaatiot sisältävät vertaisryhmiä, ts. lohkoketju on olemassa järjestöjen tuen ansiosta. Eri organisaatiot voivat olla osa samaa kanavaa.

Kanava — looginen rakenne, joka yhdistää vertaiset ryhmiin, ts. lohkoketju on määritelty. Hyperledger Fabric voi käsitellä samanaikaisesti useita lohkoketjuja eri liiketoimintalogiikalla.

Jäsenpalveluiden tarjoaja (MSP) on CA (Certificate Authority) henkilöllisyyden myöntämiseen ja roolien määrittämiseen. Solmun luomiseksi sinun on oltava vuorovaikutuksessa MSP:n kanssa.

Vertaissolmut — tarkistaa tapahtumat, tallentaa lohkoketjun, suorittaa älykkäitä sopimuksia ja olla vuorovaikutuksessa sovellusten kanssa. Vertaishenkilöillä on MSP:n myöntämä henkilöllisyystodistus (digitaalinen varmenne). Toisin kuin Bitcoin- tai Etherium-verkossa, jossa kaikilla solmuilla on yhtäläiset oikeudet, Hyperledger Fabricissa solmuilla on erilaisia ​​rooleja:

  • Peer ehkä kannattavaa vertaista (EP) ja toteuttaa älykkäitä sopimuksia.
  • Sitoutunut vertainen (CP) - tallenna tiedot vain lohkoketjuun ja päivitä "maailmantila".
  • Ankkuri Peer (AP) - jos lohkoketjuun osallistuu useita organisaatioita, niiden väliseen viestintään käytetään ankkurivertaisia. Jokaisella organisaatiolla on oltava yksi tai useampi ankkurikumppani. AP:n avulla kuka tahansa organisaation vertaiskumppani voi hankkia tietoa kaikista muiden organisaatioiden vertaisista. Käytetään tietojen synkronointiin tukiasemien välillä juoruprotokolla.
  • Johtaja Peer — jos organisaatiolla on useita vertaisryhmiä, vain vertaisjohtaja saa lohkot Tilauspalvelusta ja antaa ne muille vertaisille. Johtaja voidaan joko määrittää staattisesti tai valita dynaamisesti organisaation vertaisryhmien toimesta. Gossip-protokollaa käytetään myös johtajia koskevien tietojen synkronointiin.

Varat — entiteetit, joilla on arvoa ja jotka on tallennettu lohkoketjuun. Tarkemmin sanottuna tämä on avainarvodataa JSON-muodossa. Juuri nämä tiedot tallennetaan Blockchainiin. Niillä on historia, joka on tallennettu lohkoketjuun, ja nykyinen tila, joka on tallennettu "World state" -tietokantaan. Tietorakenteet täytetään mielivaltaisesti liiketoimintatehtävistä riippuen. Pakollisia kenttiä ei ole, ainoa suositus on, että omaisuudella on oltava omistaja ja arvoa.

pääkirja — koostuu Blockchain- ja Word-tilatietokannasta, joka tallentaa varojen nykyisen tilan. Maailman valtio käyttää LevelDB:tä tai CouchDB:tä.

Älykäs sopimus — älykkäiden sopimusten avulla toteutetaan järjestelmän liiketoimintalogiikka. Hyperledger Fabricissa älykkäitä sopimuksia kutsutaan ketjukoodiksi. Ketjukoodin avulla määritetään varat ja niiden yli tapahtuvat tapahtumat. Teknisesti älykkäät sopimukset ovat ohjelmistomoduuleja, jotka on toteutettu JS- tai Go-ohjelmointikielillä.

Hyväksyntäkäytäntö — kullekin ketjukoodille voit asettaa käytännön kuinka monta vahvistusta tapahtumalle odotetaan ja keneltä. Jos käytäntöä ei ole asetettu, oletusasetus on: "Kanavan minkä tahansa organisaation jäsenen on vahvistettava tapahtuma." Esimerkkejä käytännöistä:

  • Organisaation järjestelmänvalvojan on hyväksyttävä tapahtuma.
  • Jokaisen organisaation jäsenen tai asiakkaan on vahvistettava;
  • Minkä tahansa vertaisorganisaation on vahvistettava.

Tilauspalvelu — pakkaa tapahtumat lohkoihin ja lähettää ne kanavan vertaisille. Takaa viestien toimituksen kaikille verkon käyttäjille. Käytetään teollisuusjärjestelmissä Kafka viestivälittäjä, kehitystä ja testausta varten Soolo.

CallFlow

Blockchain: mikä PoC meidän pitäisi rakentaa?

  • Sovellus kommunikoi Hyperledger Fabricin kanssa Go-, Node.js- tai Java SDK:n avulla;
  • Asiakas luo tx-tapahtuman ja lähettää sen hyväksyville vertaisille;
  • Peer tarkistaa asiakkaan allekirjoituksen, suorittaa tapahtuman ja lähettää hyväksymisallekirjoituksen takaisin asiakkaalle. Ketjukoodi suoritetaan vain hyväksyvässä vertaisohjelmassa, ja sen suorituksen tulos lähetetään kaikille vertaisille. Tätä työalgoritmia kutsutaan PBFT (Practical Byzantine Fault Tolerant) konsensukseksi. Eroaa klassinen BFT se tosiasia, että viesti lähetetään ja vahvistusta ei odoteta kaikilta osallistujilta, vaan vain tietyltä ryhmältä;
  • Kun asiakas on saanut vahvistuskäytäntöä vastaavan määrän vastauksia, hän lähettää tapahtuman Tilauspalveluun;
  • Tilauspalvelu luo lohkon ja lähettää sen kaikille sitoutuneille vertaisille. Tilauspalvelu varmistaa lohkojen peräkkäisen kirjaamisen, mikä eliminoi ns. reskontrahaarukan (katso kohta "Haarukat");
  • Vertailijat vastaanottavat lohkon, tarkistavat hyväksymiskäytännön uudelleen, kirjoittavat lohkon lohkoketjuun ja muuttavat tilaa "World state" -tietokannassa.

Nuo. Tämä johtaa roolien jakoon solmujen välillä. Tämä varmistaa, että lohkoketju on skaalautuva ja turvallinen:

  • Älykkäät sopimukset (ketjukoodi) tukevat vertaisia. Tämä varmistaa älykkäiden sopimusten luottamuksellisuuden, koska Kaikki osallistujat eivät tallenna sitä, vaan vain hyväksyvät kollegat.
  • Tilauksen pitäisi toimia nopeasti. Tämä varmistetaan sillä, että Tilaus muodostaa vain lohkon ja lähettää sen kiinteälle johtajajoukolle.
  • Sitoutuvat kollegat tallentavat vain lohkoketjun - niitä voi olla monia, eivätkä ne vaadi paljon tehoa ja välitöntä toimintaa.

Lisätietoa Hyperledger Fabricin arkkitehtonisista ratkaisuista ja siitä, miksi se toimii näin ja ei muuten, löytyy täältä: Arkkitehtuurin alkuperä tai täällä: Hyperledger Fabric: Hajautettu käyttöjärjestelmä sallituille lohkoketjuille.

Joten Hyperledger Fabric on todella universaali järjestelmä, jolla voit:

  • Toteuta mielivaltainen liiketoimintalogiikka älykkään sopimusmekanismin avulla;
  • Tallenna ja vastaanota tietoja lohkoketjutietokannasta JSON-muodossa;
  • Myönnä ja vahvista API-käyttöoikeus varmenteen myöntäjän avulla.

Nyt kun ymmärrämme hieman Hyperledger Fabricin erityispiirteitä, tehdään vihdoin jotain hyödyllistä!

Blockchainin käyttöönotto

Ongelma

Tehtävänä on toteuttaa Citcoin-verkosto seuraavilla toiminnoilla: luo tili, hanki saldo, täydennä tiliäsi, siirrä kolikoita tililtä toiselle. Piirretään kohdemalli, jota toteutamme edelleen älykkäässä sopimuksessa. Meillä on siis tilejä, jotka on tunnistettu nimillä ja jotka sisältävät saldon, sekä tililuettelon. Tilit ja tililuettelo ovat Hyperledger Fabric -omaisuuden kannalta. Näin ollen niillä on historia ja nykytila. Yritän piirtää tämän selkeästi:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Huippuluvut ovat nykytila, joka on tallennettu "World state" -tietokantaan. Niiden alla on lukuja, jotka osoittavat lohkoketjuun tallennetun historian. Omaisuuden nykytilaa muuttavat tapahtumat. Omaisuus muuttuu vain kokonaisuutena, joten tapahtuman tuloksena luodaan uusi kohde, ja omaisuuden nykyinen arvo jää historiaan.

IBM Cloud

Luomme tilin sisään IBM pilvi. Jotta voit käyttää lohkoketjualustaa, se on päivitettävä Pay-As-You-Go-tilaan. Tämä prosessi ei ehkä ole nopea, koska... IBM pyytää lisätietoja ja tarkistaa ne manuaalisesti. Positiivisena asiana voin sanoa, että IBM:llä on hyviä koulutusmateriaaleja, joiden avulla voit ottaa Hyperledger Fabric -sovelluksen käyttöön heidän pilvessään. Pidin seuraavista artikkeli- ja esimerkkisarjoista:

Seuraavat ovat kuvakaappauksia IBM Blockchain -alustasta. Tämä ei ole ohje lohkoketjun luomiseen, vaan yksinkertaisesti esittely tehtävän laajuudesta. Joten tarkoituksiinmme teemme yhden organisaation:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Luomme siihen solmuja: Tilaaja CA, Org1 CA, Tilaaja Peer:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Luomme käyttäjiä:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Luo kanava ja kutsu sitä citcoiniksi:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Pohjimmiltaan Channel on lohkoketju, joten se alkaa lohkolla nolla (Genesis-lohko):

Blockchain: mikä PoC meidän pitäisi rakentaa?

Älykkään sopimuksen kirjoittaminen

/*
 * Citcoin smart-contract v1.5 for Hyperledger Fabric
 * (c) Alexey Sushkov, 2019
 */
 
'use strict';
 
const { Contract } = require('fabric-contract-api');
const maxAccounts = 5;
 
class CitcoinEvents extends Contract {
 
    async instantiate(ctx) {
        console.info('instantiate');
        let emptyList = [];
        await ctx.stub.putState('accounts', Buffer.from(JSON.stringify(emptyList)));
    }
    // Get all accounts
    async GetAccounts(ctx) {
        // Get account list:
        let accounts = '{}'
        let accountsData = await ctx.stub.getState('accounts');
        if (accountsData) {
            accounts = JSON.parse(accountsData.toString());
        } else {
            throw new Error('accounts not found');
        }
        return accountsData.toString()
    }
     // add a account object to the blockchain state identifited by their name
    async AddAccount(ctx, name, balance) {
        // this is account data:
        let account = {
            name: name,
            balance: Number(balance),       
            type: 'account',
        };
        // create account:
        await ctx.stub.putState(name, Buffer.from(JSON.stringify(account)));
 
        // Add account to list:
        let accountsData = await ctx.stub.getState('accounts');
        if (accountsData) {
            let accounts = JSON.parse(accountsData.toString());
            if (accounts.length < maxAccounts)
            {
                accounts.push(name);
                await ctx.stub.putState('accounts', Buffer.from(JSON.stringify(accounts)));
            } else {
                throw new Error('Max accounts number reached');
            }
        } else {
            throw new Error('accounts not found');
        }
        // return  object
        return JSON.stringify(account);
    }
    // Sends money from Account to Account
    async SendFrom(ctx, fromAccount, toAccount, value) {
        // get Account from
        let fromData = await ctx.stub.getState(fromAccount);
        let from;
        if (fromData) {
            from = JSON.parse(fromData.toString());
            if (from.type !== 'account') {
                throw new Error('wrong from type');
            }   
        } else {
            throw new Error('Accout from not found');
        }
        // get Account to
        let toData = await ctx.stub.getState(toAccount);
        let to;
        if (toData) {
            to = JSON.parse(toData.toString());
            if (to.type !== 'account') {
                throw new Error('wrong to type');
            }  
        } else {
            throw new Error('Accout to not found');
        }
 
        // update the balances
        if ((from.balance - Number(value)) >= 0 ) {
            from.balance -= Number(value);
            to.balance += Number(value);
        } else {
            throw new Error('From Account: not enought balance');          
        }
 
        await ctx.stub.putState(from.name, Buffer.from(JSON.stringify(from)));
        await ctx.stub.putState(to.name, Buffer.from(JSON.stringify(to)));
                 
        // define and set Event
        let Event = {
            type: "SendFrom",
            from: from.name,
            to: to.name,
            balanceFrom: from.balance,
            balanceTo: to.balance,
            value: value
        };
        await ctx.stub.setEvent('SendFrom', Buffer.from(JSON.stringify(Event)));
 
        // return to object
        return JSON.stringify(from);
    }
 
    // get the state from key
    async GetState(ctx, key) {
        let data = await ctx.stub.getState(key);
        let jsonData = JSON.parse(data.toString());
        return JSON.stringify(jsonData);
    }
    // GetBalance   
    async GetBalance(ctx, accountName) {
        let data = await ctx.stub.getState(accountName);
        let jsonData = JSON.parse(data.toString());
        return JSON.stringify(jsonData);
    }
     
    // Refill own balance
    async RefillBalance(ctx, toAccount, value) {
        // get Account to
        let toData = await ctx.stub.getState(toAccount);
        let to;
        if (toData) {
            to = JSON.parse(toData.toString());
            if (to.type !== 'account') {
                throw new Error('wrong to type');
            }  
        } else {
            throw new Error('Accout to not found');
        }
 
        // update the balance
        to.balance += Number(value);
        await ctx.stub.putState(to.name, Buffer.from(JSON.stringify(to)));
                 
        // define and set Event
        let Event = {
            type: "RefillBalance",
            to: to.name,
            balanceTo: to.balance,
            value: value
        };
        await ctx.stub.setEvent('RefillBalance', Buffer.from(JSON.stringify(Event)));
 
        // return to object
        return JSON.stringify(from);
    }
}
module.exports = CitcoinEvents;

Intuitiivisesti kaiken pitäisi olla selvää tässä:

  • On olemassa useita toimintoja (AddAccount, GetAccounts, SendFrom, GetBalance, RefillBalance), joita esittelyohjelma kutsuu Hyperledger Fabric API:n avulla.
  • SendFrom- ja RefillBalance-toiminnot luovat tapahtumia, jotka demo-ohjelma vastaanottaa.
  • Instantiate-toimintoa kutsutaan kerran, kun älysopimus instantoidaan. Itse asiassa sitä ei kutsuta vain kerran, vaan joka kerta, kun älykäs sopimusversio muuttuu. Siksi luettelon alustaminen tyhjällä taulukolla on huono idea, koska Nyt, kun vaihdamme älykkään sopimuksen versiota, menetämme nykyisen luettelon. Mutta ei hätää, minä vasta opettelen).
  • Tilit ja tililuettelo ovat JSON-tietorakenteita. JS:ää käytetään tietojen käsittelyyn.
  • Voit saada omaisuuden nykyisen arvon getState-funktiokutsulla ja päivittää sen käyttämällä putStatea.
  • Tiliä luotaessa kutsutaan AddAccount-toimintoa, jossa verrataan lohkoketjun tilien enimmäismäärää (maxAccounts = 5). Ja tässä on jamb (oletko huomannut?), joka johtaa loputtomaan tilien määrän kasvuun. Tällaisia ​​virheitä tulee välttää)

Seuraavaksi lataamme älykkään sopimuksen kanavalle ja instantoimme sen:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Katsotaanpa Smart Contractin asennustapahtumaa:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Katsotaanpa kanavamme yksityiskohtia:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Tuloksena saamme seuraavan kaavion lohkoketjuverkosta IBM-pilvessä. Kaaviossa näkyy myös Amazon-pilvessä virtuaalipalvelimella toimiva demo-ohjelma (lisätietoja seuraavassa osiossa):

Blockchain: mikä PoC meidän pitäisi rakentaa?

GUI:n luominen Hyperledger Fabric API -kutsuille

Hyperledger Fabricilla on API, jota voidaan käyttää:

  • Luo kanava;
  • Yhteydet vertaiskanavaan;
  • Älykkäiden sopimusten asennus ja toteutus kanavaan;
  • Soittotapahtumat;
  • Pyydä tietoja lohkoketjusta.

Sovellus kehitys

Demo-ohjelmassamme käytämme API:ta vain tapahtumien soittamiseen ja tietojen pyytämiseen, koska Olemme jo suorittaneet loput vaiheet IBM blockchain -alustan avulla. Kirjoitamme graafisen käyttöliittymän käyttämällä vakiotekniikkapinoa: Express.js + Vue.js + Node.js. Voit kirjoittaa erillisen artikkelin nykyaikaisten verkkosovellusten luomisen aloittamisesta. Jätän tähän linkin luentosarjaan, josta pidin eniten: Full Stack Web App käyttäen Vue.js & Express.js. Tuloksena on asiakas-palvelinsovellus, jossa on tuttu graafinen käyttöliittymä Googlen Material Design -tyyliin. Asiakkaan ja palvelimen välinen REST API koostuu useista kutsuista:

  • HyperledgerDemo/v1/init - alusta lohkoketju;
  • HyperledgerDemo/v1/accounts/list — saat luettelon kaikista tileistä;
  • HyperledgerDemo/v1/account?name=Bob&balance=100 — luo Bob-tili;
  • HyperledgerDemo/v1/info?account=Bob — hanki tietoja Bob-tilistä;
  • HyperledgerDemo/v1/transaction?from=Bob&to=Alice&volume=2 — siirrä kaksi kolikkoa Bobilta Alicelle;
  • HyperledgerDemo/v1/disconnect – sulje yhteys lohkoketjuun.

API:n kuvaus ja esimerkkejä mukana Postimiehen nettisivut - tunnettu ohjelma HTTP API:n testaamiseen.

Demosovellus Amazon-pilvessä

Latasin sovelluksen Amazoniin, koska... IBM ei ole vieläkään voinut päivittää tiliäni ja antaa minulle mahdollisuuden luoda virtuaalisia palvelimia. Kuinka lisätä kirsikka verkkotunnukseen: www.citcoin.info. Pidän palvelimen päällä jonkin aikaa ja sammutan sen sitten, koska... vuokrasenttejä tippuu, eikä citcoin-kolikoita ole vielä listattu pörssiin) Lisään artikkeliin kuvakaappauksia demosta, jotta työn logiikka tulee selväksi. Demosovellus voi:

  • Alusta lohkoketju;
  • Luo tili (mutta nyt et voi luoda uutta tiliä, koska älysopimuksessa määritetty enimmäismäärä tilit on saavutettu lohkoketjussa);
  • Vastaanota tililuettelo;
  • Siirrä citcoin-kolikoita Alicen, Bobin ja Alexin välillä;
  • Vastaanota tapahtumia (mutta nyt ei ole mahdollista näyttää tapahtumia, joten yksinkertaisuuden vuoksi käyttöliittymä sanoo, että tapahtumia ei tueta);
  • Lokitoiminnot.

Ensin alustamme lohkoketjun:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Seuraavaksi luomme tilimme, älä tuhlaa aikaa saldon kanssa:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Saamme luettelon kaikista käytettävissä olevista tileistä:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Valitsemme lähettäjän ja vastaanottajan ja saamme heidän saldonsa. Jos lähettäjä ja vastaanottaja ovat samat, hänen tilinsä täydennetään:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Seuraamme lokissa tapahtumien toteutumista:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Itse asiassa tämä kaikki on demo-ohjelmassa. Alla näet tapahtumamme lohkoketjussa:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Ja yleinen luettelo tapahtumista:

Blockchain: mikä PoC meidän pitäisi rakentaa?

Tämän avulla olemme saaneet onnistuneesti päätökseen PoC:n toteutuksen Citcoin-verkoston luomiseksi. Mitä muuta on tehtävä, jotta Citcoinista tulisi täysimittainen kolikoiden siirtoverkko? Erittäin vähän:

  • Ota käyttöön yksityisen/julkisen avaimen luominen tilin luomisvaiheessa. Yksityinen avain on tallennettava tilin käyttäjälle, julkinen avain on tallennettava lohkoketjuun.
  • Tee kolikonsiirto, jossa käyttäjän tunnistamiseen käytetään nimen sijaan julkista avainta.
  • Salaa käyttäjältä palvelimelle menevät tapahtumat hänen yksityisellä avaimellaan.

Johtopäätös

Olemme toteuttaneet Citcoin-verkoston seuraavilla toiminnoilla: lisää tili, hanki saldo, täytä tiliäsi, siirrä kolikoita tililtä toiselle. Joten, mitä meille maksoi PoC:n rakentaminen?

  • Sinun tulee opiskella lohkoketjua yleensä ja erityisesti Hyperledger Fabricia;
  • Opi käyttämään IBM- tai Amazon-pilviä;
  • Opi JS-ohjelmointikieli ja jokin verkkokehys;
  • Jos joitain tietoja ei tarvitse tallentaa lohkoketjuun, vaan erilliseen tietokantaan, opettele integroimaan esimerkiksi PostgreSQL;
  • Ja viimeisenä mutta ei vähäisimpänä - et voi elää nykymaailmassa ilman Linuxin tuntemusta!)

Se ei tietenkään ole rakettitiedettä, mutta sinun on tehtävä lujasti töitä!

Lähteet GitHubissa

Lähteet laitettu GitHub. Lyhyt kuvaus arkistosta:
Luettelo "palvelin» — Node.js-palvelin
Luettelo "asiakas» — Node.js-asiakas
Luettelo "blockchain"(parametrien arvot ja avaimet tietenkään eivät toimi ja annetaan vain esimerkkinä):

  • sopimus - älykäs sopimuslähdekoodi
  • lompakko — käyttäjän avaimet Hyperledger Fabric API:n käyttöä varten.
  • *.cds - älykkäiden sopimusten käännetyt versiot
  • *.json-tiedostot – esimerkkejä määritystiedostoista Hyperledger Fabric API:n käyttöä varten

Se on vasta alkua!

Lähde: will.com

Lisää kommentti