Blockchain: vad kostar det att bygga en PoC?

Ögonen skräms, men händerna kliar!

I tidigare artiklar har vi gått igenom de teknologier som blockchain bygger på (Vad kostar det att bygga en blockchain?) och de fallstudier som kan realiseras med deras hjälp (Vad kostar det att bygga en fallstudie?). Det är dags att arbeta praktiskt! För att genomföra piloter och PoC (Proof of Concept) föredrar jag att använda moln, eftersom de är tillgängliga från vilken plats som helst i världen och ofta sparar tid på att installera miljöer, eftersom det finns förkonfigurerade inställningar. Så låt oss göra något enkelt, till exempel ett nätverk för att överföra mynt mellan deltagare och kalla det blygsamt Citcoin. För detta kommer vi att använda IBM:s moln och den universella blockchainen Hyperledger Fabric. Låt oss först ta reda på varför Hyperledger Fabric kallas en universell blockchain?

Hyperledger Fabric — en universell blockchain

Om man talar i allmänna termer, så är ett universellt informationssystem:

• En uppsättning servrar och en programkärna som utför affärslogik;
• Gränssnitt för interaktion med systemet;
• Verktyg för registrering, autentisering och auktorisering av enheter / personer;
• En databas som lagrar operativa och arkiverade data:

Den officiella versionen av vad Hyperledger Fabric är kan läsas på webbplats, och kort sagt, Hyperledger Fabric är en öppen plattform som möjliggör byggandet av privata blockchain och utförande av godtyckliga smarta kontrakt skrivna på programmeringsspråken JS och Go. Låt oss titta närmare på arkitekturen i Hyperledger Fabric och försäkra oss om att det är ett universellt system där det bara finns specifika krav för lagring och registrering av data. Specifika krav innebär att data, precis som i alla blockchains, lagras i block som läggs till blockchainen endast om deltagarna når konsensus och efter registrering kan data inte ändras eller tas bort obemärkt.

Arkitektur av Hyperledger Fabric

I diagrammet visas arkitekturen för Hyperledger Fabric:

Organisationer — organisationerna innehåller peers, vilket gör att blockchainen existerar tack vare stödet från organisationerna. Olika organisationer kan ingå i en och samma channel.

Channel — en logisk struktur som förenar peers i grupper, vilket definierar blockchainen. Hyperledger Fabric kan samtidigt hantera flera blockchains med olika affärslogik.

Membership Services Provider (MSP) — detta är CA (Certificate Authority) för att utfärda identiteter och tilldela roller. För att skapa en nod måste man interagera med MSP.

Peer-noder — kontrollerar transaktioner, lagrar blockkedjan, utför smarta kontrakt och interagerar med applikationer. Peer-noder har en identitet (digitalt certifikat) som utfärdas av MSP. Till skillnad från Bitcoin- eller Ethereum-nätverk, där alla noder är lika, spelar noder i Hyperledger Fabric olika roller:

• Peer kan vara endorsing peer (EP) och utföra smarta kontrakt.
• Committing peer (CP) — sparar endast data i blockkedjan och uppdaterar "World state".
• Anchor Peer (AP) — om flera organisationer deltar i blockkedjan, används anchor peers för att koppla samman dem. Varje organisation måste ha en eller flera anchor peers. Med hjälp av AP kan varje peer i en organisation få information om alla peers i andra organisationer. För att synkronisera information mellan AP används gossip-protokollet.
• Leader Peer — om en organisation har flera peers, kommer endast ledande peer att ta emot block från Ordering service och vidarebefordra dem till de andra peers. Ledaren kan antingen ställas in statiskt eller väljas dynamiskt av peers inom organisationen. För att synkronisera information om ledarna används även gossip-protokollet.

Tillgångar — enheter som har värde och som lagras i blockkedjan. Mer specifikt är detta key-value data i JSON-format. Det är dessa data som registreras i blockkedjan "Blockchain". De har en historia som lagras i blockkedjan och ett aktuellt tillstånd som lagras i databasen "World state". Datastrukturer fylls jämnt beroende på affärsbehov. Det finns inga obligatoriska fält, den enda rekommendationen är att tillgångarna bör ha en ägare och representera ett värde.

Huvudbok — består av blockkedjan "Blockchain" och databasen "World state", där det aktuella tillståndet för tillgångarna lagras. World state använder LevelDB eller CouchDB.

Smart kontrakt — genom smarta kontrakt implementeras systemets affärslogik. I Hyperledger Fabric kallas smarta kontrakt för chaincode. Med hjälp av chaincode definieras tillgångar och transaktioner på dem. Om man talar tekniskt är smarta kontrakt programmoduler som implementeras i programmeringsspråken JS eller Go.

Endorsement policy — för varje chaincode kan man ställa in policys för hur många och från vem bekräftelser måste förväntas för en transaktion. Om policyn inte är angiven används som standard: “transaktionen måste bekräftas av varje medlem (member) i någon organisation i channel”. Exempel på policys:

• Transaktionen måste bekräftas av en administratör i organisationen;
• Måste bekräftas av en medlem eller kund i organisationen;
• Måste bekräftas av en peer i organisationen.

Ordering service — paketerar transaktioner i block och skickar dem till peers i channel. Den garanterar leverans av meddelanden till alla peers i nätverket. För industrisystem används meddelandebroker Kafka, för utveckling och testning Solo.

CallFlow

• Applikationen interagerar med Hyperledger Fabric med hjälp av Go, Node.js eller Java SDK;
• Klienten skapar transaktionen tx och skickar den till endorsing peers;
• Peer kontrollerar klientens signatur, utför transaktionen och skickar endorsement signature tillbaka till klienten. Chaincode körs endast på endorsing peers och resultatet av denna körning distribueras till alla peers. Denna arbetsmetod kallas – PBFT (Practical Byzantine Fault Tolerant) konsensus. Den skiljer sig från klassisk BFT genom att meddelandet skickas och ett bekräftande svar inte förväntas från alla deltagare, utan endast från ett visst urval;
• Efter att klienten fått ett antal svar som motsvarar endorsement policy, skickar han transaktionen till Ordering service;
• Ordering service skapar ett block och skickar det till alla committing peers. Ordering service säkerställer en sekventiell inspelning av block, vilket utesluter så kallad ledger fork (se avsnittet "Forks");
• Peers får blocket, kontrollerar ytterligare endorsement policy, skriver blocket i blockchain och ändrar tillståndet i "World state" DB.

Dvs. det blir en uppdelning av roller mellan noderna. Detta möjliggör skalning och säkerhet för blockchain:

• Smartkontrakt (chaincode) körs av endorsing peers. Detta säkerställer konfidentialitet för smartkontrakten, eftersom de inte lagras av alla deltagare, utan endast av endorsing peers.
• Ordering måste arbeta snabbt. Detta säkerställs genom att Ordering endast skapar block och skickar det till en fast uppsättning leader peers.
• Committing peers lagrar endast blockchain — de kan vara många och de kräver inte stor kraft och omedelbarhet.

För mer information om den arkitektoniska lösningen för Hyperledger Fabric och varför den fungerar så, kan du se här: Architecture Origins eller här: Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains.

Så, Hyperledger Fabric är verkligen ett mångsidigt system, med hjälp av vilket man kan:

• Genomföra godtycklig affärslogik, med hjälp av smartkontraktssystemet;
• Skriva och hämta data från blockkedjedatabasen i JSON-format;
• Tillhandahålla och verifiera åtkomst till API, med hjälp av certifikatutfärdare.

Nu när vi har förstått några specifika aspekter av Hyperledger Fabric, låt oss äntligen göra något nyttigt!

Sätter upp en blockkedja

Uppgiftsställande

Uppgiften är att implementera ett Citcoin-nätverk med följande funktioner: skapa konto, hämta saldo, fylla på konto, överföra mynt från ett konto till ett annat. Vi kommer att rita en objektsmodell som vi sedan implementerar i smarta kontrakt. Så, vi kommer att ha konton som identifieras av namn (name) och som innehåller saldo (balance), samt en lista över konton. Konton och lista över konton är tillgångar (assets) i termer av Hyperledger Fabric. Därför har de en historia och ett aktuellt tillstånd. Jag ska försöka att visa detta tydligt:

De övre figurerna representerar det aktuella tillståndet som lagras i "World state". Under dem finns figurer som visar historiken som lagras i blockkedjan. Det aktuella tillståndet för tillgångar förändras genom transaktioner. En tillgång ändras endast helt, så i resultatet av transaktionen skapas ett nytt objekt, medan det aktuella värdet för tillgången går till historien.

IBM-molnet

Skapa ett konto i IBM-molnet. För att använda blockkedjeplattformen måste den uppgraderas till Pay-As-You-Go. Denna process kan ta tid, eftersom IBM begär ytterligare information och kontrollerar den manuellt. På den positiva sidan kan jag säga att IBM har bra utbildningsmaterial som gör det möjligt att sätta upp Hyperledger Fabric i deras moln. Jag gillade följande artiklar och exempel:

• Skapa ett grundläggande blockkedjenätverk med Blockchain Platform
• Skapa och kör ett blockkedje-smart kontrakt
• Sänd händelser från Blockchain Platform

Nedan följer skärmdumpar av IBMs Blockchain-plattform. Detta är ingen instruktion för att skapa en blockkedja, utan bara en demonstration av uppgiftens omfattning. Så för våra ändamål skapar vi en organisation:

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

Skapar användare:

Skapa Channel och kalla den citcoin:

I grunden är Channel en blockkedja, så den börjar med block noll (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 allt vara självklart här:

• Det finns flera funktioner (AddAccount, GetAccounts, SendFrom, GetBalance, RefillBalance) som demoprogrammet kommer att kalla via Hyperledger Fabric API.
• Funktionerna SendFrom och RefillBalance genererar händelser (Event) som demoprogrammet kommer att ta emot.
• Funktionen instantiate anropas en gång vid instansiering av smarta kontrakt. Faktiskt anropas den inte bara en gång utan varje gång vid ändring av versionen av det smarta kontraktet. Därför är det en dålig idé att initiera listan med en tom array, eftersom vi nu kommer att förlora den aktuella listan vid versionbyte. Men det är okej, jag lär mig ju bara).
• Conton och listan över konton (accounts) är JSON datakonstruktioner. För datahantering används JS.
• Det aktuella värdet av tillgången (asset) kan hämtas med hjälp av funktionen getState, och uppdateras med putState.
• Vid skapandet av ett Account anropas funktionen AddAccount, där en jämförelse görs med det maximala antalet konton i blockkedjan (maxAccounts = 5). Här finns en bugg (la ni märke till det?) som leder till en oändlig ökning av antalet konton. Sådana fel måste undvikas).

Därefter laddar vi upp det smarta kontraktet till Channel och instansierar det:

Vi tittar på transaktionen för installation av Smart Contract:

Vi ser detaljer om vår Channel:

Som resultat får vi följande schema av blockkedjenätverket i IBM:s moln. Schemata visar också ett demo-program som körs i Amazons moln på en virtuell server (detaljer om det kommer i nästa avsnitt):

Skapa GUI för att anropa Hyperledger Fabric API

Hyperledger Fabric har ett API som kan användas för:

• Att skapa channel;
• Ansluta peer till channel;
• Installera och instansiera smarta kontrakt i channel;
• Anropa transaktioner;
• Begära information i blockkedjan.

Utveckling av applikation

I vårt demo-program kommer vi att använda API:et endast för att anropa transaktioner och begära information, eftersom de andra stegen redan har gjorts med hjälp av IBM:s blockkedjeplattform. Vi skriver GUI med hjälp av en standardteknikstack: Express.js + Vue.js + Node.js. Hur man börjar skapa moderna webbapplikationer skulle kunna bli en separat artikel. Här lämnar jag en länk till en serie föreläsningar som jag tyckte mycket om: Full Stack Web App using Vue.js & Express.js. Som resultat blev det en klient-serverapplikation med ett bekant grafiskt gränssnitt i stil med Material Design från Google. REST API mellan klienten och servern består av flera anrop:

• HyperledgerDemo/v1/init — initiera blockkedjan;
• HyperledgerDemo/v1/accounts/list — hämta lista över alla konton;
• HyperledgerDemo/v1/account?name=Bob&balance=100 — skapa Bob konto;
• HyperledgerDemo/v1/info?account=Bob — hämta information om Bob konto;
• HyperledgerDemo/v1/transaction?from=Bob&to=Alice&volume=2 — överföra två mynt från Bob till Alice;
• HyperledgerDemo/v1/disconnect — stänga anslutningen till blockkedjan.

API-beskrivningen med exempel har jag lagt på sidan "Postman" — en välkänd programvara för testning av HTTP API.

Demoprogrammet i Amazon-molnet

Jag har laddat upp appen till Amazon, eftersom IBM ännu inte har kunnat uppgradera mitt konto och tillåta skapande av virtuella servrar. Som pricket över i:et har jag lagt en domän: www.citcoin.info. Jag kommer att hålla servern påslagen ett tag, men sedan stänga av den eftersom kostnaderna för uthyrning tickar, och citcoin-mynten är fortfarande inte noterade på börsen) I artikeln lägger jag in skärmdumpar av demon så att logiken för arbetet blir tydlig. Demoprogrammet kan:

• Initiera blockkedjan;
• Skapa konto (men just nu går det inte att skapa nytt konto eftersom det maximala antalet konton som anges i smartkontraktet har nåtts);
• Hämta lista över konton;
• Överföra citcoin-mynt mellan Alice, Bob och Alex;
• Hämta händelser (men just nu kan händelser inte visas, därför har det skrivits i gränssnittet för enkelhetens skull att händelser inte stöds);
• Logga åtgärder.

Först initierar vi blockkedjan:

Därefter skapar vi vårt konto, vi snålar inte med saldot:

Vi hämtar lista över alla tillgängliga konton:

Väljer avsändare och mottagare, vi får deras saldon. Om avsändare och mottagare är samma person, så kommer dennes saldo att öka:

I loggen följer vi transaktionernas genomförande:

Det var faktist allt om demoprogrammet. Vi kan nu se vår transaktion i blockkedjan:

Och den totala listan över transaktioner:

Härmed har vi framgångsrikt avslutat genomförandet av PoC för att skapa nätverket Citcoin. Vad mer behövs för att Citcoin ska bli ett fullfjädrat nätverk för överföring av mynt? Inte mycket:

• Vid skapandet av kontot implementera genereringen av privat/offentligt nyckel. Den privata nyckeln ska lagras av kontoanvändaren, den offentliga i blockkedjan.
• Göra överföring av mynt där användarens identifiering använder den offentliga nyckeln istället för namnet.
• Kryptera transaktionerna som går från användaren till servern med dennes privata nyckel.

Slutsats

Vi har implementerat nätverket Citcoin med funktionerna: lägga till konto, få saldo, fylla på sitt konto, överföra mynt från ett konto till ett annat. Så, vad krävdes för att bygga PoC?

• Vi måste studera blockkedjan i allmänhet och Hyperledger Fabric i synnerhet;
• Lära oss att använda IBM:s eller Amazons molntjänster;
• Lär dig programmeringsspråket JS och någon webbramverk;
• Om vissa data behöver lagras inte i blockchain, utan i en separat databas, så lär dig att integrera, till exempel med PostgreSQL;
• Och sist men inte minst — utan kunskaper i Linux kommer man inte långt i dagens värld!)

Självklart, inte rocket science, men det kommer att kräva lite ansträngning!

Källkoden på GitHub

Källkoden har lagts på GitHub. Kort beskrivning av förvaret:
Katalogen "server" — Node.js-servern
Katalogen "klient" — Node.js-klienten
Katalogen "blockchain" (parametervärden och nycklar är givetvis inte funktionella och endast exempelvis):

• contract — källkod för smart kontrakt
• wallet — användarnycklar för att använda Hyperledger Fabric API.
• *.cds — kompilerade versioner av smarta kontrakt
• *.json-filer — exempel på konfigurationsfiler för att använda Hyperledger Fabric API

Det är bara början!

Källa: habr.com