Blockchain: what does it take to build a PoC?

Silmad kardavad, aga käed sügelevad!

Eelmistes artiklites käsitlesime tehnoloogiaid, millel plokiahelad põhinevad (Mis meil maksab plokiahela ülesehitamine?) ja juhtumeid, mida nende abil ellu viia (Mida on vaja juhtumi loomiseks?). On aeg hakata kät tööle panema! Pilootide ja PoC (tõestus kontseptsioonist) elluviimiseks eelistan kasutada pilveteenuseid, kuna neile pääseb juurde igast maailma nurgast ning tihti ei pea kulutama aega tüütule keskkonna seadistamisele, kuna on olemas eelnevalt seadistatud konfiguratsioonid. Alustame lihtsa asjaga, näiteks võrguga, et saata münte osalejate vahel ning nimetame seda tagasihoidlikult Citooniks. Selleks kasutame IBM-i pilve ja universaalset plokiahelat Hyperledger Fabric. Esiteks, miks nimetatakse Hyperledger Fabricit universaalseks plokiahelaks?

Hyperledger Fabric — universaalne plokiahel

Üldiselt öeldes on universaalne teabehalduse süsteem:

• Serverite kogum ja tarkvaratuum, mis teostab äriloogikat;
• Liidesed süsteemiga suhtlemiseks;
• Seadmete/inimeste registreerimise, autentimise ja autoriseerimise vahendid;
• Andmebaas, mis salvestab operatiivseid ja arhiivandmeid:

Ametlikku versiooni sellest, mis on Hyperledger Fabric, saab lugeda veebilehel, ja lühidalt öeldes on Hyperledger Fabric avatud lähtekoodiga platvorm, mis võimaldab luua erablokke ja teostada mis tahes nutikaid lepinguid, mis on kirjutatud programmeerimiskeeltes JS ja Go. Vaadakem lähemalt Hyperledger Fabric'i arhitektuuri ja veendugem, et see on universaalne süsteem, millel on vaid spetsiifilised andmete salvestamise ja kirjutamise omadused. Spetsiifilisus seisneb selles, et andmed, nagu kõigis blokeeringutes, salvestatakse blokkidesse, mis lisatakse plokiahelasse ainult siis, kui osalejad on jõudnud konsensusele, ja pärast salvestamist ei saa andmeid märkamatult muuta ega kustutada.

Hyperledger Fabric'i arhitektuur

Diagrammil on näidatud Hyperledger Fabric'i arhitektuur:

Organisatsioonid — organisatsioonid sisaldavad peer'e, seega eksisteerib plokiahel organisatsioonide toetuse tõttu. Erinevad organisatsioonid võivad kuuluda ühte kanalisse.

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

Liikmesuse teenuste pakkuja (MSP) — on CA (Certificate Authority) identiteedi väljastamiseks ja rollide määramiseks. Nodede loomiseks tuleb suhelda MSP-ga.

Peer nodid — kontrollivad tehinguid, salvestavad plokiahelat, täidavad nutilepinguid ja suhtlevad rakendustega. Peeridel on identiteet (digitaalne sertifikaat), mille väljastab 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 ainult andmeid plokiahelas ja ajakohastavad 'World state'.
• Anchor Peer (AP) – kui plokiahelas osaleb mitu organisatsiooni, siis kasutatakse ankur peer-e omavaheliseks ühendamiseks. Iga organisatsioon peaks omama ühte või mitut ankur peer-i. AP kaudu saab iga peer organisatsioonis teavet kõikide peer-ide kohta teistes organisatsioonides. AP-de vahelise teabe sünkroniseerimiseks kasutatakse gossip protokolli.
• Leader Peer — kui organisatsioonil on mitu peer'i, siis ainult juhtpeer saab blokke Ordering service'ilt ja jagab neid teiste peer'ide hulka. Juht võib olla määratud staatiliselt või valida dünaamiliselt peer'ide seas organisatsioonis. Infovahetuseks juhtide üle kasutatakse samuti gossip protokolli.

Varad — väärtuslikud üksused, mida hoitakse plokiahelas. Täpsemalt on need key-value andmed JSON formaadis. Just need andmed salvestatakse plokiahelasse „Blockchain”. Neil on ajalugu, mis salvestatakse plokiahelas, ja hetke seis, mis salvestatakse andmebaasis „World state”. Andmestruktuurid täidetakse vastavalt äriülesannetele. Kohustuslikke välju ei ole, ainus soovitus on, et varadel peaks olema omanik ja need peaksid omama väärtust.

Raamatupidamine — koosneb plokiahest „Blockchain” ja andmebaasist „World state”, kus hoitakse varade hetke seise. World state kasutab LevelDB-d või CouchDB-d.

Nutileping — äriga smartlepingute abil rakendatakse süsteemi äri loogikat. Hyperledger Fabricis nimetatakse smartlepinguid chaincode'iks. Chaincode abil määratakse varad ja nendega seotud tehingud. Tehniliselt öeldes on smartlepingud programmimoodulid, mis on kirjutatud programmeerimiskeeltes JS või Go.

Kinnituspolitika — iga chaincode jaoks saab määrata poliitikad, kui palju ja kellelt tuleb tehingu kinnitusi oodata. Kui poliitikat ei ole määratud, kasutatakse vaikimisi: „tehingu peab kinnitama ükskõik milline liige (member) ükskõik millisest organisatsioonist kanalil (channel).” Näiteid poliitikatest:

• Tehingu peab kinnitama igasugune organisatsiooni administraator;
• Peab kinnitama iga liige (member) või organisatsiooni klient;
• Peab kinnitama iga organisatsiooni peer.

Tellimisteenus — pakib tehingud plokkidesse ja saadab need peer'idele kanalisse. Tagab sõnumite saatmise kõigile võrgus olevatele peer'idele. Tööstuslikes süsteemides kasutatakse Kafka sõnumivahendajat, arenduseks ja testimiseks Solo.

CallFlow

• Rakendus suhtleb Hyperledger Fabriciga, kasutades Go, Node.js või Java SDK;
• Kliendil on tehing tx ja ta saadab selle kinnitavatele peer'idele;
• Peer kontrollib kliendi allkirja, viib tehingu läbi ja saadab endorsement signature kliendile tagasi. Chaincode töötab ainult endorsing peer'il ja selle täitmise tulemus edastatakse kõikidele peer'idele. See töömehanism on tuntud kui PBFT (Practical Byzantine Fault Tolerant) konsensus. See erineb klassikalisest BFT selle poolest, et sõnum saadetakse ja oodatakse kinnitust mitte kõigilt osalistelt, vaid ainult kindlast hulgast;
• Pärast seda, kui klient on saanud vastuseid, mis vastavad endorsement policy'le, saadab ta tehingu Ordering service'ile;
• Ordering service koostab ploki ja saadab selle kõikidele committing peer'idele. Ordering service tagab plokkide järjestikuse salvestamise, mis välistab nn ledger fork (vt jaotist „Forkid”);
• Peer'id saavad ploki, kontrollivad uuesti endorsement policy't, salvestavad ploki plokiahelasse ja muudavad seisundit „World state” DB-s.

St. see tagab rollide jagamise sõlmepunktide vahel. See võimaldab skalaarida ja suurendada plokiahela turvalisust:

• Nutilepingud (chaincode) täidavad endorsing peer'id. See tagab nutilepingute konfidentsiaalsuse, kuna need ei ole kõikide osalejate juures, vaid ainult endorsing peer'idel.
• Tellimus peab toimuma kiiresti. Seda tagab asjaolu, et tellimus loob ainult plokki ja saadab selle kindlale rikkapeeride kogumile.
• Kohustavad peers lihtsalt hoiavad plokiahelat — neid võib olla palju ja nad ei nõua suurt võimsust ega kiiret toimimist.

Üksikasjalikumalt arhitektuuri lahendustest Hyperledger Fabric ja miks see töötab just nii, saab vaadata siit: Arhitektuuri algused või sealt: Hyperledger Fabric: jaotatud opsüsteem privileege saanud plokiahelatele.

Nii et Hyperledger Fabric on tõeliselt universaalne süsteem, mille abil saab:

• Rakendada suvalist äriloogikat, kasutades nutikate lepingute mehhanismi;
• Salvestada ja saada andmeid plokiahela andmebaasist JSON-formaadis;
• Osutada ja kontrollida ligipääsu API-le, kasutades sertifitseerimisasutust.

Nüüd, kui oleme veidi tutvunud Hyperledger Fabric eripäradega, teeme lõpuks midagi kasulikku!

Seame üles plokiahela

Ülesande seadmine

Ülesanne on luua Citcoin võrk järgmiste funktsioonidega: konto loomine, saldo saamine, konto täiendamine ja müntide ülekandmine ühest kontost teise. Joonistame objekti mudeli, mille hiljem rakendame nutilepingus. Seega on meil kontod, mida tuvastatakse nimede (name) ja mis sisaldavad saldo (balance) ning konto loend. Kontod ja konto loend on Hyperledger Fabric'i mõistes varad (assets). Vastavalt on neil ajalugu ja hetkeolek. Proovin seda visuaalselt illustreerida:

Ülemised kujundid on hetkeolek, mis on salvestatud andmebaasi „World state“. Allpool on kujundid, mis näitavad ajalugu, mis salvestatakse plokiahelas. Varade hetkeolekut muudetakse tehingute kaudu. Vara muutub ainult tervikuna, seega tehingu täitmise tulemusena luuakse uus objekt ja vara hetkeväärtus läheb ajalukku.

IBM Cloud

Loome konto IBM Cloude. Ettevõtte blockchain platvormi kasutamiseks tuleb seda uuendada Pay-As-You-Go mudelile. See protsess võib olla ajamahukas, kuna IBM küsib lisainfot ja kontrollib seda käsitsi. Positiivse poole pealt võin öelda, et IBM-il on head õpikurid, mis aitavad Hyperledger Fabricit nende pilves käivitada. Mulle meeldis järgmine artikkel ja näidisprotsesside tsükkel:

• Loo põhiline blockchain võrgu kasutades Blockchain platvormi
• Loo ja täida blockchain nutileping
• Emit events from Blockchain Platform

Järgnevalt tuuakse välja IBM Blockchain platvormi ekraanipildid. See pole juhend blockchain'i loomise kohta, vaid lihtsalt ülesande ulatuse näitamine. Nii et meie eesmärkide jaoks loome ühe organisatsiooni:

Selle alla loome sõlmed: Orderer CA, Org1 CA, Orderer Peer:

Loome kasutajad:

Loo kanal ja nimeta see citcoiniks:

Sisuliselt on kanal blockchain, seega algab see nullplokist (Genesis block):

Kirjuta nutileping

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

Intuitiivselt peaks siin kõik selge olema:

• On mitu funktsiooni (AddAccount, GetAccounts, SendFrom, GetBalance, RefillBalance), mida demoprogramm kutsub Hyperledger Fabric API kaudu.
• Funktsioonid SendFrom ja RefillBalance genereerivad sündmusi (Event), mida demoprogramm saab.
• instantiate funktsioon käivitatakse üks kord nutilepingu instantsimise ajal. Tegelikult käivitatakse see mitte ühe, vaid iga kord, kui nutilepingut muudetakse. Seega on loetelu algväärtustamine tühi massiiv — halb mõte, sest nüüd, kui nutilepingut uuendatakse, kaotame me praeguse loendi. Aga pole hullu, ma alles õpin).
• Account-id ja account-ide (accounts) loend on JSON andmestruktuurid. Andmete manipuleerimiseks kasutatakse JS-i.
• Võite praeguse asset-i väärtuse saada, kasutades funktsiooni getState, ja uuendada seda funktsiooniga putState.
• Account-i loomisel käivitatakse funktsioon AddAccount, kus võrreldakse blockchainis maksimaalset account-ide arvu (maxAccounts = 5). Ja siin on aps (kas märkate?), mis viib account-ide arvu lõpmatu kasvu. Selliseid vigu tuleks vältida).

Seejärel laadime nutilepingut Channelisse ja instantsime selle:

Vaadake Smart Contracti seadistamise tehingut:

Vaadake meie Channeli üksikasju:

Saame järgmise plaani IBM-i pilve blockchaini võrgust. Skeemil on samuti demo programm, mis töötab Amazonis virtuaalses serveris (üksikasjad on järgmises peatükis):

GUI loomine Hyperledger Fabric API kutseteks

Hyperledger Fabric'il on API, mida saab kasutada:

• kanali loomiseks;
• peer'i ühendamiseks kanaliga;
• tarkade lepingute seadistamiseks ja instantsimiseks kanalil;
• tehingute kutsumiseks;
• informatsiooni pärimiseks blockchainis.

Rakenduse arendamine

Kasutame meie demo programmis API-d ainult tehingute kutsmiseks ja informatsiooni pärimiseks, kuna kõik muud sammud on juba tehtud, kasutades IBM-i blockchain platvormi. Loome GUI, kasutades standardtöötleja tehnoloogiaid: Express.js + Vue.js + Node.js. Kuidas alustada tänapäevaste veebirakenduste loomist võib kirjutada eraldi artiklis. Siin on link loengute seeriale, mis mulle kõige rohkem meeldis: Full Stack Web App using Vue.js & Express.js. Tulemuseks on kliendi-serveri rakendus tuttava graafilise liidesega, mis järgib Google'i Material Design'i stiili. REST API kliendi ja serveri vahel koosneb mitmest kutsetest:

• HyperledgerDemo/v1/init — blockchaini initsialiseerimine;
• HyperledgerDemo/v1/accounts/list — saada kõigi kontode nimekiri;
• HyperledgerDemo/v1/account?name=Bob&balance=100 — loo konto Bob;
• HyperledgerDemo/v1/info?account=Bob — saa teavet Bob konto kohta;
• HyperledgerDemo/v1/transaction?from=Bob&to=Alice&volume=2 — saada kaks münter Bob-ilt Alice'ile;
• HyperledgerDemo/v1/disconnect — katkesta ühendus plokiahelaga.

API kirjeldus koos näidetega on saadaval veebilehel "Postman" — laialdaselt tuntud programm HTTP API testimiseks.

Demorakendus Amazonis

Olen rakenduse üles laadinud Amazonile, kuna IBM pole siiani suudnud minu kontot uuendada ja lubada virtuaalsete serverite loomist. Nagu kirsiks tordil, lisasin domeeni: www.citcoin.info. Hoian serverit natuke sisse lülitatuna, siis lülitan välja, kuna renti kajastuvad sendid ja citcoin mündid börsil pole veel noteeritud) Artiklis lisasin ekraanipildid demost, et oleks arusaadav tööloogika. Demorakendus saab:

• Algatada plokiahela;
• Luua konto (kuid praegu uut kontot luua ei saa, kuna plokiahelas on saavutatud maksimaalne arvu kontosid, mis on määratud nutilepingus);
• Saada konto nimekiri;
• Üle kanda citcoin münte Alice, Bobi ja Alexi vahel;
• Saada sündmusi (aga hetkel ei saa sündmusi mingil moel näidata, seega on liideses lihtsuse huvides kirjas, et sündmusi ei toetata);
• Logige tegevused.

Esialgu initsialiseerime plokiahela:

Seejärel loome oma konto, mitte ei hõlma põhjaga:

Saame kõikide saadaval olevate kontode loendi:

Valime saatja ja saaja, saame nende bilansid. Kui saatja ja saaja on sama, siis toimub tema konto täiendamine:

Logis jälgime tehingute täitmist:

Demoprogrammiga on see kõik. Järgmine samm on meie tehingu vaatamine plokiahelas:

Ja tehingute üldine nimekiri:

Sellega oleme edukalt lõpetanud Citcoin võrgu PoC rakendamise. Mida veel on vaja teha, et Citcoinist saaks täieõiguslik müntide ülekandmise võrk? Väga vähe:

• Konto loomise etapis rakendada privaatse/publikus võti genereerimist. Privaatne võti peab olema kasutaja kontol, publiku plokiahelas.
• Teha müntide ülekandmine, kus kasutaja tuvastamiseks kasutatakse mitte nime, vaid publikust võtit.
• Krüpteerida tehingud, mis lähevad kasutajalt serverisse, tema privaatse võtmega.

Kokkuvõte

Meie oleme loonud Citcoin võrgu funktsioonidega: konto lisamine, saldo saamine, oma kontot täiendamine, müntide edastamine ühest kontost teise. Nii et mis maksis meile PoC ehitamine?

• Tuleb uurida plokiahelat üldiselt ja Hyperledger Fabric'i eriti;
• Õppida kasutama IBM või Amazoni pilvi;
• Selgeks saada programmeerimiskeel JS ja mõni veebiraamistik;
• Kui mingid andmed tuleb salvestada mitte plokiahelasse, vaid eraldi andmebaasi, siis õppida integreeruma näiteks PostgreSQL-iga;
• Ja viimane, kuid mitte vähem oluline — ilma Linuxi tundmisega ei pääse tänapäeva maailmas kuhugi!)

Muidugi, ei ole see just rocket science, aga higi tuleb valada!

Allikakoode GitHubis

Allikakoode olen pannud GitHub. Lühikirjeldus hoidlast:
Kataloog „server“ — Node.js server
Kataloog „client“ — Node.js klient
Kataloog „plokiahel“ (parameetrite väärtused ja võtmed, loomulikult, ei ole töötavad ja on toodud ainult näitena):

• contract — nutilepingute algfail
• wallet — kasutaja võtmed Hyperledger Fabric API kasutamiseks.
• *.cds — kompileeritud versioonid nutilepingutest
• *.json failid — näidised konfiguratsioonifailidest Hyperledger Fabric API kasutamiseks

See on alles algus!

Allikas: habr.com