Plokiahel: mida me peame PoC’i loomiseks?

Silmad kardavad, kuid käed sügelevad!

Eelmistes artiklites arutlesime tehnoloogiate üle, millele plokiahelad toetuvad (Mis on vajalik blockchain'i loomiseks?) ja juhtumite üle, mida nende abil ellu viia (Mis meid takistab juhtumi loomisel?). On aeg asuda tegudele! Pilootprojekti ja PoC (Proof of Concept) elluviimiseks eelistan kasutada pilveteenuseid, kuna neile pääseb ligi igast maailma nurgast ja sageli ei pea aega raiskama tüütule keskkonna seadistamisele, kuna eksisteerivad eelkonfigureeritud lahendused. Alustame millegi lihtsa loomist, näiteks võrku raha ülekandmiseks osalejate vahel, ja nimetame seda tagasihoidlikult Citcoiniks. Selleks kasutame IBM-i pilve ja universaalset plokiahelat Hyperledger Fabric. Esmalt uurime, miks Hyperledger Fabrici nimetatakse universaalseks plokiahelaks?

Hyperledger Fabric — universaalne plokiahel

Üldiselt öeldes on universaalne teabesüsteem:

• Serverite kogum ja tarkvara süda, mis täidab äri loogikat;
• Liidesed süsteemiga suhtlemiseks;
• Seadmete / inimeste registreerimise, autentimise ja autoriseerimise vahendid;
• Andmebaas, mis salvestab operatiivsed ja arhiivandmed:

Hyperledger Fabrici ametlikku definitsiooni saab lugeda veebisaidil, kuid lühidalt öeldes on Hyperledger Fabric avatud lähtekoodiga platvorm, mis võimaldab luua suletud plokiahelasid ja teostada mis tahes nutikaid lepinguid, mis on kirjutatud programmeerimiskeeltes JS ja Go. Vaatame lähemalt Hyperledger Fabrici arhitektuuri ja veendume, et see on universaalne süsteem, millel on ainult andmete salvestamise ja kirjutamise eripära. Eripära seisneb selles, et andmed, nagu kõigis plokiahelates, salvestatakse plokkides, mis lisatakse plokiahelasse ainult siis, kui osalised saavutavad konsensuse, ja pärast salvestamist ei saa andmeid märkamatult muuta või eemaldada.

Hyperledger Fabrici arhitektuur

Diagrammil on kujutatud Hyperledger Fabrici arhitektuur:

Organisatsioonid — organisatsioonidesse kuuluvad peerid, seega toetavad plokiahelat organisatsioonid. Erinevad organisatsioonid võivad kuuluda ühte kanali.

Kanal — loogiline struktuur, mis ühendab peer'e gruppidesse, seega määratleb plokiahela. Hyperledger Fabric suudab samal ajal töödelda mitmeid plokiahelaid erineva äri loogikaga.

Liikmeministeerium (MSP) — see on CA (sertifitseerimisasutus), mis annab identiteete ja määrab rolle. Noodi loomiseks tuleb suhelda MSP-ga.

Peer nodes — kontrollivad tehinguid, salvestavad plokiahelat, täidavad nutilepinguid ja suhtlevad rakendustega. Peeridel on identiteet (digitaalne sertifikaat), mille annab välja MSP. Erinevalt Bitcoin või Etheriumi võrgust, kus kõik nodid on võrdsed, mängivad Hyperledger Fabricis nodid erinevaid rolle:

• Peer võib olla endorsing peer (EP) ja täita nutilepinguid.
• Committing peer (CP) — salvestavad andmeid plokiahelasse ja uuendavad "World state".
• Anchor Peer (AP) — kui plokiahelas osaleb mitu organisatsiooni, kasutatakse ankur-peer'e nende vaheliseks suhtlemiseks. Igal organisatsioonil peab olema üks või mitu ankur-peer'i. AP abil võib iga peer organisatsioonis saada teavet kõigi teiste organisatsioonide peer'ide kohta. Teabe sümbioosi saavutamiseks kasutatakse gossip protokolli.
• Leader Peer — kui organisatsioonil on mitu peer'i, siis ainult liider-peer saab blokeerida Ordering service'ist ja edastada neid teistele peer'idele. Liidrit võib määrata staatiliselt või valida dünaamiliselt organisatsioonis olevate peer'ide poolt. Liidrite vahelise teabe sünkroniseerimiseks kasutatakse samuti gossip protokolli.

Assets — väärtuslikud üksused, mida hoitakse plokiahelas. Veelgi täpsemalt — need on key-value andmed JSON formaadis. Just need andmed salvestatakse plokiahelasse "Blockchain". Neil on ajalugu, mida hoitakse plokiahelas ja praegune seisund, mis hoitakse andmebaasis "World state". Andmestruktuure täiendatakse vastavalt ärivajadustele. Kohustuslikke välju ei ole, ainus soovitus on, et varadel peab olema omanik ja need peaksid esindama väärtust.

Ledger — koosneb plokiahest "Blockchain" ja andmebaasist "World state", kus hoitakse varade praegust seisundit. World state kasutab LevelDB või CouchDB.

Smart contract — nutilepingute kaudu rakendatakse süsteemi äriloogikat. Hyperledger Fabricis nimetatakse nutilepinguid chaincode'iks. Chaincode'i abil määratakse varad ja tehingud nendega. Tehniliselt öeldes on nutilepingud programmeerimismoodulid, mis on ellu viidud programmeerimiskeeltel JS või Go.

Endorsement policy — iga chaincode'i jaoks võib määrata poliitika, kui palju ja kellelt on vaja tehingu kinnitust. Kui poliitika pole määratud, kasutatakse vaikimisi: "tehingut peab kinnitama iga liikmesorganisatsiooni liige kanalil". Poliitika näidised:

• Tehingu peab kinnitama organisatsiooni mis tahes administraator;
• Peab kinnitama organisatsiooni mis tahes liige või klient;
• Peab kinnitama organisatsiooni mis tahes peer.

Tellimisteenus — pakib tehingud plokkidesse ja saadab need peer-idele kanalis. Tagab sõnumite edastamise kõikidele peer-idele võrgus. Tööstuslike süsteemide jaoks kasutatakse Kafka sõnumite maaklerit, arendamiseks ja testimiseks Solo.

CallFlow

• Rakendus suhtleb Hyperledger Fabric'iga, kasutades Go, Node.js või Java SDK-d;
• Kliendil on tehingu tx ja saadab selle endorseerimise peer-idele;
• Peer kontrollib kliendi allkirja, viib tehingu läbi ja saadab tagasi endorsement signature kliendile. Chaincode viiakse läbi ainult endorseerimise peer-ides ning selle täitmise tulemus saadetakse kõigile peer-idele. Sellist töömeetodit nimetatakse — PBFT (Practical Byzantine Fault Tolerant) konsensus. Erineb klassikalisest BFT-st selle poolest, et sõnum saadetakse ja oodatakse kinnitamist mitte kõigilt osalejatelt, vaid ainult kindlast kogumist;
• Pärast seda, kui klient on saanud vastuste arvu, mis vastab endorsement policy-le, saadab ta tehingu tellimisteenusele;
• Tellimisteenus koostab ploki ja saadab selle kõikidele kaasaskantavatele peer-idele. Tellimisteenus tagab plokkide järjekindla kirjutamise, mis välistab nn raamatupidamise fork'i (vt jaotist "Forkid");
• Peer-id saavad ploki, kontrollivad veelkord endorsement policy-d, kirjutavad ploki plokiahelasse ja muudavad olekut "World state" andmebaasis.

See tähendab, et node'de vahel toimub rollide jagamine. See tagab plokiahela skaleeritavuse ja turvalisuse:

• Nutikaid lepinguid (chaincode) viivad läbi endorseerimise peer-id. See tagab nutikate lepingute konfidentsiaalsuse, kuna need ei ole kõigi osalejate, vaid ainult endorseerimise peer-ide valduses.
• Tellimine peab toimuma kiiresti. See tagatakse sellega, et tellimine koostab ainult ploki ja saadab selle kindlale juhivõrgustikule.
• Kaasaskantavad peer-id ainult hoiavad plokiahelat — neid võib olla palju ja nad ei vaja suurt võimsust ega kohest tööd.

Rohkem Hyperledger Fabric'i arhitektuurilahenduste kohta ja miks see töötab nii, mitte teisiti, saab vaadata siit: Architektuuri originaalid või siit: Hyperledger Fabric: jaotatud operatsioonisüsteem lubatud plokiahelate jaoks.

Seega, Hyperledger Fabric on tõeliselt universaalne süsteem, millega saab:

• Reaaliseerida igasugust äriloogikat, kasutades nutikate lepingute mehhanismi;
• Salvestame ja saame andmeid plokiahela andmebaasist JSON formaadis;
• Pakume ja kontrollime API-le ligipääsu, kasutades sertifikaadi ametit.

Nüüd, kui oleme natuke paremini tuttavad Hyperledger Fabric spetsiifikaga, laseme lõpuks teha midagi kasulikku!

Käivitame plokiahela

Ülesande seadmine

Ülesanne on luua Citcoin võrk, mis sisaldab järgmisi funktsioone: luua konto, saada saldo, täiendada kontot, edastada münte ühest kontost teise. Joonistame objekti mudeli, mille me hiljem teeme tarklepingus. Niisiis, meil on kontod, mis tuvastatakse nimede (name) kaudu ja sisaldavad saldo (balance) ning konto loend. Kontod ja konto loend on Hyperledger Fabricis varad (assets). Vastavalt on neil ajalugu ja praegune seisukord. Proovin seda visuaalselt esitada:

Ülemised kujundid – see on praegune seisukord, mis salvestatakse "World state" andmebaasi. Allpool on kujundid, mis näitavad ajalugu, mis salvestatakse plokiahelasse. Varade praegune seisukord muutub tehingute kaudu. Vara muutub ainult täielikult, seega tehingu teostamise tulemusena luuakse uus objekt ja vara praegune väärtus läheb ajalukku.

IBM Cloud

Loome konto IBM Cloudis. Plokiahela platvormi kasutamiseks tuleb see uuendada Pay-As-You-Go versiooniks. See protsess ei pruugi olla kiire, kuna IBM küsib täiendavat teavet ja kontrollib seda käsitsi. Positiivse külje pealt võin öelda, et IBM-l on head õppematerjalid, mis võimaldavad Hyperledger Fabricit nende pilves käivitada. Mulle meeldis järgmine artiklite ja näidete tsükkel:

• Loo põhiline plokiahela võrk, kasutades plokiahela platvormi
• Looge ja käivitage plokiahela tarkleping
• Emiteerige sündmusi plokiahela platvormilt

Järgnevalt on toodud ekraanipildid IBM plokiahela platvormist. See ei ole juhend plokiahela loomise kohta, vaid lihtsalt ülesande ulatuse demonstreerimine. Niisiis, meie vajaduste järgi loome ühe organisatsiooni:

Loome selles sõlmed: Orderer CA, Org1 CA, Orderer Peer:

Loome kasutajad:

Looge kanali ja nimetage see citcoin:

Põhimõtteliselt on kanal plokiahel, seega algab see nullbloki (Genesis block) lõpetamisest:

Kirjutame tarklepingut

/*
 * 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;

Siin peaks kõik intuitiivselt selge olema:

• On mitu funktsiooni (AddAccount, GetAccounts, SendFrom, GetBalance, RefillBalance), mida demo program kasutab Hyperledger Fabric API abil.
• Funktsioonid SendFrom ja RefillBalance genereerivad sündmusi (Event), mida demo programm saab.
• Funktsioon instantiate kutsutakse välja ainult üks kord nutika lepingu instantiimise ajal. Tegelikult kutsutakse seda välja mitte ainult üks kord, vaid iga kord nutika lepingu versiooni muutmisel. Seetõttu on loetelu algse tühi massiiv - halb idee, kuna nüüd kaotame nutika lepingu versiooni muutmisel praeguse loendi. Kuid see pole probleem, ma alles õppin).
• Account'id ja account'ide (accounts) loend - need on JSON andmestruktuurid. Andmete manipuleerimiseks kasutatakse JS-i.
• Käesoleva asset'i praeguse väärtuse saab kätte funktsiooni getState kaudu, samas kui seadistamiseks kasutatakse putState'i.
• Account'i loomisel kutsutakse välja funktsioon AddAccount, kus võrreldakse plokiahelas maksimaalselt lubatud account'ide arvu (maxAccounts = 5). Siin on viga (kas märkisite?), mis põhjustab account'ide arvukuse lõputu kasvu. Selliseid vigu tuleks vältida).

Edasi laadime nutika lepingu Channelisse ja instantiime selle:

Vaadake nutika lepingu seadistamise tehingut:

Vaadake meie Channeli üksikasju:

Tulemusena saame järgmise plokiahela võrgu skeemi IBM-i pilves. Skeemil on ka demoprogramm, mis töötab Amazoni pilves virtuaalsel serveril (üksikasjad on järgmises osas):

GUI loomine Hyperledger Fabric API kutsumiste jaoks

Hyperledger Fabric'il on API, mida saab kasutada:

• Channeli loomiseks;
• Peer'i ühendamiseks channeliga;
• Nutika lepingu seadistamiseks ja instantiimiseks channelis;
• Tehingute nn kutse jaoks;
• Informatsiooni küsimiseks plokiahelas.

Rakenduse arendus

Meie demoprogrammis kavatseme kasutada API-d ainult tehingute kutsumiseks ja informatsiooni küsimiseks, kuna ülejäänud sammud oleme juba teinud, kasutades IBM-i plokiahela platvormi. Kirjutame GUI, kasutades standardset tehnoloogiate virna: Express.js + Vue.js + Node.js. Kuidas alustada kaasaegsete veebirakenduste loomist, võiks kirjutada eraldi artikli. Siin jätan lingi loengusarjale, mis mulle enim meeldis: Full Stack Web App using Vue.js & Express.js. Tulemusena sai kliendi-serveri rakendus tuttava Material Design stiilis graafilise liidese. REST API kliendi ja serveri vahel koosneb mitmest kutsetest:

• HyperledgerDemo/v1/init - plokiahela initsialiseerimine;
• HyperledgerDemo/v1/accounts/list - saada kõigi account'ide loend;
• HyperledgerDemo/v1/account?name=Bob&balance=100 - luua Bob account;
• HyperledgerDemo/v1/info?account=Bob - saada teavet Bob account'i kohta;
• HyperledgerDemo/v1/transaction?from=Bob&to=Alice&volume=2 - edastada kaks münti Bobilt Alicele;
• HyperledgerDemo/v1/disconnect — lukusta blockchaini ühendus.

API kirjeldus koos näidetega on pandud «Postman» site'ile — laialdaselt tuntud programm HTTP API-de testimiseks.

Demo rakendus Amazonis

Rakendus on üles laaditud Amazonisse, kuna IBM ei ole siiani suutnud uuendada minu kontot ning lubada virtuaalserverite loomist. Nagu kirss tordil on domeen: www.citcoin.info. Hoian serverit natuke sisse lülitatuna, seejärel lülitan välja, kuna rendihinnad voolavad, aga citcoin müntide kauplemine börsil ei ole veel alustatud) Panen artiklisse ekraanipildid, et selgitada rakenduse toimimist. Demo rakendus oskab:

• Alustada blockchaini;
• Luua Konto (aga praegu ei saa uut Kontot luua, kuna blockchainis on saavutatud maksimaalne number kontosid, mis on määratud nutilepingus);
• Saada Kontode nimekiri;
• Edastada citcoin münte Alice'i, Bob'i ja Alexi vahel;
• Saada sündmusi (aga hetkel ei saa sündmusi näidata, seega on kasutajaliideses lihtsuse huvides kirjutatud, et sündmusi ei toetata);
• Logida tegevusi.

Esiteks alustame blockchaini:

Seejärel loome oma konto, ei kisenda saldo üle:

Saame nimekirja kõikidest saadaval olevatest kontodest:

Valime saatja ja saaja, saame nende saldode: Kui saatja ja saaja on üks ja sama, toimub tema konto täiendamine:

Logis jälgime tehingute täitmist:

Kuna demo programm sellega ka lõppeb. Edasi saab vaadata meie tehingut blockchainis:

Ja kogu tehingute loend:

Selleks saime edukalt lõpetatud Citcoini võrgu PoC rakendamise. Mida on veel vaja teha, et Citcoinist saaks täieõiguslik münte ülekandmise võrk? Ainult vähe:

• Konto loomise etapis rakendada privaatse / avaliku võtme genereerimist. Privaatvõti peab olema kontoa kasutaja käes, avalik võtme blockchainis.
• Teha münsü transfer, kus kasutaja identifitseerimiseks kasutatakse mitte nime, vaid avalikku võtme.
• Krüpteerida tehingud, mis lähevad kasutajalt serverisse tema privaatse võtme abil.

Kokkuvõte

Oleme rakendanud Citcoin võrku funktsioonidega: konto lisamine, saldo saamine, oma konto täiendamine, münte edastamine ühelt konto teisele. Nii et, mida maksis PoC ehitamine?

• Peame uurima blockchaini üldiselt ja Hyperledger Fabric'i eriti;
• Õppima kasutama IBM'i või Amazoni pilvi;
• Õppima programmeerimiskeelt JS ja mõnda veebiraamistikku;
• Kui mõnda teavet tuleb hoida mitte plokiahelas, vaid eraldi andmebaasis, tuleks õppida näiteks PostgreSQL-iga integreerima;
• Ja viimane nimekirjas, kuid mitte vähenenud tähtsusega — ilma Linuxi tundmiseta ei pääse tänapäeva maailmas kuhugi!)

Muidugi, see ei ole raketiteadus, aga veidi tuleb vaeva näha!

Allikakood GitHubis

Allikaid olen pannud GitHub. Lühike kirjeldus repodega:
Kataloog „server“ — Node.js server
Kataloog „client“ — Node.js klient
Kataloog „blockchain“ (parameetrite väärtused ja võtmed on muidugi mitte töökindlad ja näidatud ainult näiteks):

• contract — nutilepingu allikas
• wallet — kasutaja võtmed Hyperledger Fabric API kasutamiseks.
• *.cds — kompileeritud versioonid nutilepingutest
• *.json failid — näited konfiguratsioonifailidest Hyperledger Fabric API kasutamiseks

See on alles algus!

Allikas: habr.com