Blockchain: Hva koster det å lage PoC?

Øynene er redde, men hendene klør!

I forrige artikler diskuterte vi teknologiene som blockchain er bygget på (Hva skal vi bygge blockchain for?) og tilfellene som kan implementeres ved hjelp av dem (Hva må til for å bygge et tilfelle?). Det er på tide å jobbe med hendene! For implementering av piloter og PoC (Proof of Concept) foretrekker jeg å bruke skyer, siden de er tilgjengelige fra hvor som helst i verden, og ofte slipper man å bruke tid på kjedelig installasjon av miljøet, da det finnes forhåndsinstallerte konfigurasjoner. Så la oss lage noe enkelt, for eksempel et nettverk for å overføre mynter mellom deltakerne og kalle det beskjedent Citcoin. Til dette skal vi bruke IBM-skyen og den universelle blockchain Hyperledger Fabric. La oss først forstå hvorfor Hyperledger Fabric kalles en universell blockchain?

Hyperledger Fabric — en universell blockchain

Generelt sett er et universelt informasjonssystem:

• En samling servere og et programkjern som utfører forretningslogikk;
• Grensesnitt for interaksjon med systemet;
• Verktøy for registrering, autentisering og autorisering av enheter / personer;
• En database som lagrer operative og arkiverte data:

Den offisielle versjonen av hva Hyperledger Fabric er, kan leses på nettsiden, og hvis man skal oppsummere, så er Hyperledger Fabric en open source plattform som gjør det mulig å bygge lukkede blockchains og utføre vilkårlige smartkontrakter skrevet i programmeringsspråkene JS og Go. La oss se nærmere på arkitekturen til Hyperledger Fabric og forsikre oss om at dette er et universelt system, hvor det bare er spesifikasjoner for lagring og registrering av data. Spesifikasjonen går ut på at data, som i alle blockchains, lagres i blokker som kun plasseres i blockchain når deltakerne har nådd konsensus, og etter at dataene er skrevet, er det umulig å endre eller slette dem usett.

Arkitekturen til Hyperledger Fabric

Diagrammet viser arkitekturen til Hyperledger Fabric:

Organisasjoner — organisasjoner inneholder peer-er, slik at blockchain eksisterer takket være støtten fra organisasjonene. Ulike organisasjoner kan delta i én kanal.

Kanal — en logisk struktur som samler peer-er i grupper, slik at det defineres en blockchain. Hyperledger Fabric kan samtidig håndtere flere blockchains med ulik forretningslogikk.

Membership Services Provider (MSP) — dette er CA (Certificate Authority) for utstedelse av identiteter og tildeling av roller. For å opprette en node må man samarbeide med MSP.

Noder — kontrollerer transaksjoner, lagrer blokkjedene, utfører smarte kontrakter og samhandler med applikasjoner. Noder har en identitet (digitalt sertifikat) utstedt av MSP. I motsetning til Bitcoin- eller Etherium-nettverk, der alle noder er like, spiller noder i Hyperledger Fabric forskjellige roller:

• En node kan være endorserende node (EP) og utføre smarte kontrakter.
• Committing node (CP) — lagrer kun data i blokkjedene og oppdaterer «Verdistatus».
• Anchor Node (AP) — hvis blokkjedene involverer flere organisasjoner, brukes anker noder til å knytte dem sammen. Hver organisasjon må ha en eller flere anker noder. Med hjelp av AP kan enhver node i organisasjonen få informasjon om alle noder i andre organisasjoner. For synkronisering av informasjon mellom AP brukes gossip-protokollen.
• Leder Node — hvis organisasjonen har flere noder, vil kun ledernoden motta blokker fra bestillingstjenesten og gi dem til de andre nodene. Leder kan være både statisk satt og velges dynamisk av nodene i organisasjonen. For synkronisering av informasjon om ledere brukes også gossip-protokollen.

Eiendeler — enheter med verdi som lagres i blokkjedene. Mer spesifikt er dette key-value data i JSON-format. Det er disse dataene som registreres i blokkjedene «Blockchain». De har en historikk som lagres i blokkjedene og en nåværende tilstand som lagres i databasen «Verdistatus». Datakonstruksjoner fylles vilkårlig avhengig av forretningsbehov. Det finnes ingen obligatoriske felt, det eneste rådet er — eiendeler må ha en eier og representere verdi.

Hovedbok — består av blokkjedene «Blockchain» og databasen «Word state», der den nåværende tilstanden til eiendelene lagres. Verdistatus bruker LevelDB eller CouchDB.

Smart kontrakt — forretningslogikk i systemet implementeres ved hjelp av smarte kontrakter. I Hyperledger Fabric kalles smarte kontrakter chaincode. Gjennom chaincode defineres eiendelene og transaksjonene i dem. Med teknisk språk brukes smarte kontrakter — programmoduler implementert på programmeringsspråkene JS eller Go.

Endorsere politikk — for hver chaincode kan det defineres politikk for hvor mange og fra hvem som må bekrefte transaksjonen. Hvis politikken ikke er definert, brukes som standard: “transaksjonen må bekreftes av ethvert medlem (member) fra enhver organisasjon i kanalen”. Eksempler på politikk:

• Transaksjonen må bekreftes av en hvilken som helst administrator i organisasjonen;
• Hvilken som helst medlem (member) eller kunde i organisasjonen må bekrefte;
• Hvilken som helst peer i organisasjonen må bekrefte.

Bestillingstjeneste — pakker transaksjoner i blokker og sender dem til peer-er i kanalen. Sikrer levering av meldinger til alle peer-er i nettverket. For industrielle systemer brukes meldingsmegler Kafka, for utvikling og testing Solo.

CallFlow

• Applikasjonen interagerer med Hyperledger Fabric ved hjelp av Go, Node.js eller Java SDK;
• Klienten oppretter transaksjonen tx og sender den til endorsing peer-er;
• Peer-verifiserer klientens signatur, utfører transaksjonen og sender endorsement signature tilbake til klienten. Chaincode kjøres kun på endorsing peer, og resultatet av utførelsen sendes til alle peer-er. Denne arbeidsalgoritmen kalles — PBFT (Practical Byzantine Fault Tolerant) konsensus. Det skiller seg fra klassisk BFT ved at meldingen sendes og bekreftelse forventes ikke fra alle deltakere, men bare fra et bestemt sett;
• Når klienten har mottatt antallet svar som samsvarer med endorsement policy, sender han transaksjonen til bestillingstjenesten;
• Bestillingstjenesten danner en blokk og sender den til alle committing peer-er. Bestillingstjenesten sikrer sekvensiell innspilling av blokker, noe som utelukker, såkalt, ledger fork (se avsnitt «Forker»);
• Peer-er mottar blokken, sjekker endorsement policy på nytt, registrerer blokken i blokkjeden og endrer tilstanden i «World state» DB.

Det vil si at det oppstår en rollefordeling mellom nodene. Dette sikrer skalerbarhet og sikkerhet i blokkjeden:

• Smartkontrakter (chaincode) kjøres av endorsing peer-er. Dette sikrer konfidensialitet for smartkontraktene, da de ikke lagres hos alle deltakerne, men kun på endorsing peer-ene.
• Bestilling må fungere raskt. Dette sikres ved at bestillingen kun danner blokker og sender dem til et fast sett med leder peer-er.
• Committing peers lagrer bare blokkjeden — det kan være mange av dem, og de krever ikke stor kraft eller umiddelbar ytelse.

For mer informasjon om arkitektoniske løsninger i Hyperledger Fabric og hvorfor det fungerer slik, se her: Arkitekturens opprinnelse eller her: Hyperledger Fabric: Et distribuert operativsystem for tillatelsesbaserte blokkjeder.

Så, Hyperledger Fabric er virkelig et allsidig system som kan gjøre:

• Implementere vilkårlig forretningslogikk ved hjelp av mekanismen for smartkontrakter;
• Lagre og hent data fra blockchain-databasen i JSON-format;
• Gi tilgang til og verifisere API-bruk ved hjelp av et sertifiseringsorgan.

Nå som vi har forstått spesifikasjonene til Hyperledger Fabric litt bedre, la oss endelig gjøre noe nyttig!

Distribuerer blockchain

Definering av oppgaven

Målet er å implementere et Citcoin-nettverk med følgende funksjoner: opprette en konto, hente saldo, fylle på konto, overføre mynter fra én konto til en annen. La oss tegne en objektmodell som vi senere vil implementere i en smart kontrakt. Vi vil ha kontoer som identifiseres med navn (name) og inneholder saldo (balance), samt en liste over kontoer. Kontoer og listen over kontoer er, i henhold til Hyperledger Fabric, eiendeler (assets). De har dermed en historikk og en nåværende tilstand. Jeg vil prøve å illustrere dette tydelig:

De øverste figurene representerer nåværende tilstand, som lagres i «World state»-databasen. Under dem er figurer som viser historikken, som lagres i blockchain. Den nåværende tilstanden for eiendeler endres av transaksjoner. En eiendel kan kun endres helt, så resultatet av en transaksjon opprettes som et nytt objekt, mens den nåværende verdien av eiendelen går inn i historikken.

IBM Cloud

Opprett en konto i IBM-cloud. For å bruke blockchain-plattformen må den oppgraderes til Pay-As-You-Go. Denne prosessen kan ta tid, ettersom IBM ber om ekstra informasjon og sjekker den manuelt. Til det positive kan jeg si at IBM har gode læringsressurser som lar deg distribuere Hyperledger Fabric i skyen deres. Jeg likte denne serien av artikler og eksempler:

• Opprett et grunnleggende blockchain-nettverk ved hjelp av Blockchain-plattformen
• Opprett og kjør en smart kontrakt
• Send hendelser fra Blockchain-plattformen

Her er skjermbilder fra IBM Blockchain-plattformen. Dette er ikke en instruksjon for å lage en blockchain, men en enkel demonstrasjon av omfanget av oppgaven. Så for våre formål lager vi én organisasjon:

I den oppretter vi noder: Orderer CA, Org1 CA, Orderer Peer:

Oppretter brukere:

Oppretter en kanal og kaller den citcoin:

I bunn og grunn er kanal en blockchain, så den begynner med nullblokken (Genesis block):

Skriver Smart Contract

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

Intuitivt bør alt her være forståelig:

• Det er flere funksjoner (AddAccount, GetAccounts, SendFrom, GetBalance, RefillBalance) som vil bli kalt av demoprogrammet ved hjelp av Hyperledger Fabric API.
• Funksjonene SendFrom og RefillBalance genererer hendelser (Event) som demoprogrammet vil motta.
• Instantiate-funksjonen kalles én gang når smart-kontrakten instansieres. Faktisk blir den ikke kalt bare én gang, men hver gang smart-kontrakten endres. Derfor er det en dårlig idé å initialisere listen med en tom matrise, ettersom vi nå vil miste den nåværende listen ved versjonsendring av smart-kontrakten. Men det er okei, jeg lærer bare).
• Account-er og listen av account-er (accounts) er JSON-datastrukturer. JS brukes til å manipulere dataene.
• Den nåværende verdien av asset kan hentes ved å kalle funksjonen getState, og oppdateres med putState.
• Når en Account opprettes, kalles funksjonen AddAccount, som sammenligner med det maksimale antallet accounts i blokkjeden (maxAccounts = 5). Og her er det en feil (la merke til?), som fører til uendelig vekst av antall accounts. Slike feil må unngås)

Deretter laster vi opp smart-kontrakten til Channel og instansierer den:

Vi ser på transaksjonen for å etablere Smart Contract:

Vi ser detaljene om vår Channel:

Som et resultat får vi følgende diagram av blockchain-nettverket i IBM-skyen. Diagrammet inkluderer også et demoprogram som kjører i Amazon-skyen på en virtuell server (mer om det i neste avsnitt):

Opprettelse av GUI for å kalle Hyperledger Fabric API

Hyperledger Fabric har et API som kan brukes til:

• Å opprette channel;
• Å koble peer til channel;
• Å installere og instansiere smart-kontrakter i channel;
• Å kalle transaksjoner;
• Å be om informasjon i blokkjeden.

Utvikling av applikasjoner

I vårt demoprogram vil vi bruke API kun til å kalle transaksjoner og be om informasjon, da vi allerede har fullført de andre trinnene ved å bruke IBM-blockchain-plattformen. Vi skriver GUI ved å bruke standard teknologistack: Express.js + Vue.js + Node.js. Hvordan man kan begynne å lage moderne webapplikasjoner kan skrive en egen artikkel om. Her legger jeg igjen lenken til en serie forelesninger som jeg likte best: Full Stack Web App using Vue.js & Express.js. Resultatet ble en klient-server-applikasjon med en kjent grafisk grensesnitt i Material Design-stil fra Google. REST API mellom klient og server består av flere kall:

• HyperledgerDemo/v1/init - initialisere blokkjeden;
• HyperledgerDemo/v1/accounts/list - hente listen over alle accounts;
• HyperledgerDemo/v1/account?name=Bob&balance=100 - opprette Bob account;
• HyperledgerDemo/v1/info?account=Bob - hente informasjon om Bob account;
• HyperledgerDemo/v1/transaction?from=Bob&to=Alice&volume=2 — overføre to mynter fra Bob til Alice;
• HyperledgerDemo/v1/disconnect — avslutte forbindelsen til blokkjeden.

API-beskrivelsen med eksempler la jeg på nettstedet «Postman» — et velkjent program for testing av HTTP API.

Demoapplikasjonen på Amazon Cloud

Jeg lastet opp applikasjonen til Amazon, ettersom IBM fortsatt ikke har klart å oppgradere kontoen min og tillate opprettelse av virtuelle servere. Som en liten bonus har jeg festet domenet: www.citcoin.info. Jeg vil holde serveren på en stund, men deretter slå den av, ettersom leiekostnadene øker, og citcoin-myntene er ennå ikke notert på børsen) I artikkelen legger jeg inn skjermbilder av demoen for å gjøre logikken tydelig. Demoapplikasjonen kan:

• Initialisere blokkjeden;
• Opprette Account (men nå kan ikke ny Account opprettes, ettersom det maksimale antallet account-er i blokkjeden, som er spesifisert i smartkontrakten, er nådd);
• Få en liste over Accounts;
• Overføre citcoin-mynter mellom Alice, Bob og Alex;
• Få hendelser (men nå kan ikke hendelser vises, derfor står det i grensesnittet for enkelhetens skyld at hendelser ikke støttes);
• Loggføre handlinger.

Først initialiserer vi blokkjeden:

Deretter oppretter vi vår egen account, og vi sløser ikke med balansen:

Vi får en liste over alle tilgjengelige accounts:

Vi velger avsender og mottaker, og får deres balanser. Hvis avsender og mottaker er den samme, vil kontoen bli fylt opp:

I loggen følger vi med på utførelsen av transaksjoner:

Egentlig er dette alt med demo-programmet. Videre kan vi se transaksjonen vår i blokkjeden:

Og den samlede transaksjonslisten:

Vi har nå med suksess fullført implementeringen av PoC for å opprette Citcoin-nettverket. Hva må vi gjøre for at Citcoin skal bli et fullverdig nettverk for overføring av mynter? Ikke mye:

• Ved opprettelse av account, implementere generering av privat / offentlig nøkkel. Den private nøkkelen skal lagres av brukerens account, den offentlige i blokkjeden.
• Gjøre overføringer av mynter der identifikasjon av brukeren skjer ikke med navn, men med offentlig nøkkel.
• Kryptere transaksjoner som går fra brukeren til serveren med hans private nøkkel.

Konklusjon

Vi har implementert Citcoin-nettverket med funksjoner: legge til account, få balanse, fylle opp kontoen, overføre mynter fra en konto til en annen. Så hva kostet det oss å bygge PoC?

• Vi må studere blokkjeden generelt og Hyperledger Fabric spesielt;
• Lære å bruke IBM- eller Amazon-skyer;
• Lære programmeringsspråket JS og en web rammeverk;
• Hvis data må lagres ikke på blokkjeden, men i en egen database, så lær deg å integrere, for eksempel med PostgreSQL;
• Og sist, men ikke minst — uten kunnskap om Linux kommer man ikke langt i dagens verden!)

Selvfølgelig, det er ikke rocket science, men det vil kreve litt arbeid!

Kildekode på GitHub

Kildekoden la jeg på GitHub. Kort beskrivelse av lageret:
Katalogen «server» — Node.js-server
Katalogen «klient» — Node.js-klient
Katalogen «blockchain» (verdiene til parametere og nøkler er selvfølgelig ikke operative og bare gitt som eksempel):

• contract — kildekoden til smarte kontrakter
• wallet — brukerens nøkler for å bruke Hyperledger Fabric API.
• *.cds — kompilerte versjoner av smarte kontrakter
• *.json-filer — eksempler på konfigurasjonsfiler for bruk med Hyperledger Fabric API

Det er bare begynnelsen!

Kilde: habr.com