Блокчейн: какво ни коства да изградим PoC?

Очите се страхуват, а ръцете се потят!

В предишните статии разгледахме технологиите, върху които се изграждат блокчейните (Каква е цената на изграждането на блокчейн?) и примерите, които можем да реализираме с тяхна помощ (Какво ни пречи да изградим пример?). Настъпи време да работим с ръцете си! За реализиране на пилотни проекти и PoC (Proof of Concept) предпочитам да използвам облачни услуги, тъй като те са достъпни от всяка точка на света и често не е нужно да се губи време в скучна инсталация на среда, тъй като има предварително инсталирани конфигурации. И така, нека направим нещо просто, например, мрежа за прехвърляне на монети между участниците и да я наречем скромно Сitcoin. За това ще използваме облака на IBM и универсалния блокчейн Hyperledger Fabric. Първо, нека разберем защо Hyperledger Fabric се нарича универсален блокчейн?

Hyperledger Fabric — универсален блокчейн

По принцип, универсалната информационна система е:

• Комплект сървъри и софтуерно ядро, изпълняващо бизнес логика;
• Интерфейси за взаимодействие с системата;
• Средства за регистрация, автентикация и авторизация на устройства/хора;
• База данни, съ храняща оперативни и архивни данни:

Официалната версия на това какво е Hyperledger Fabric може да се прочете на сайта, а накратко, Hyperledger Fabric е платформа с отворен код, която позволява изграждането на затворени блокчейни и изпълняването на произволни смарт договори, написани на програмни езици JS и Go. Нека погледнем по-подробно архитектурата на Hyperledger Fabric и да се уверим, че това е универсална система, в която само се заложи специфика по отношение на съхранението и записването на данни. Спецификата се състои в това, че данните, както във всички блокчейни, се съхраняват в блокове, които се добавят в блокчейна само, ако участниците постигнат консенсус и след записването данните не могат да бъдат незабелязано променяни или изтривани.

Архитектура на Hyperledger Fabric

На схемата е показана архитектурата на Hyperledger Fabric:

Organizations — организациите съдържат peer-и, т.е. блокчейн съществува благодарение на подкрепата на организациите. Различни организации могат да влизат в един channel.

Channel — логическа структура, обединяваща peer-и в групи, т.е. определя блокчейна. Hyperledger Fabric може едновременно да обработва няколко блокчейна с различна бизнес логика.

Membership Services Provider (MSP) — това е CA (Certificate Authority) за издаване на идентичности и задаване на роли. За създаване на възел е нужно взаимодействие с MSP.

Peer nodes — проверяват транзакции, съхраняват блокчейн, изпълняват смарт-контракти и взаимодействат с приложения. В peer-овете има identity (цифров сертификат), който се издава от MSP. В отличие от мрежата Bitcoin или Ethereum, където всички ноди са равноправни, в Hyperledger Fabric нодите играят различни роли:

• Peer може да бъде endorsing peer (EP) и да изпълнява смарт-контракти.
• Committing peer (CP) — само съхраняват данни в блокчейна и актуализират „World state“.
• Anchor Peer (AP) — ако в блокчейна участват няколко организации, анкор peer-овете се използват за свързване между тях. Всяка организация трябва да има един или повече анкор peer. С помощта на AP всеки peer в организацията може да получи информация за всички peer-ове в други организации. За синхронизиране на информацията между AP се използва gossip протокол.
• Leader Peer — ако организацията има няколко peer-ове, само лидер peer ще получава блокове от Ordering service и ще ги раздава на останалите peer-ове. Лидерът може да бъде зададен статично или да бъде избран динамично от peer-овете в организацията. За синхронизиране на информацията за лидерите също се използва gossip протокол.

Assets — сущности, които имат стойност и се съхраняват в блокчейна. По-конкретно — това са key-value данни във формат JSON. Именно тези данни се записват в блокчейн „Blockchain“. Те имат история, която се съхранява в блокчейна, и текущо състояние, което се съхранява в базата данни „World state“. Структурите на данните се запълват произволно, в зависимост от бизнес задачите. Няма задължителни полета, единствената препоръка е — asset-ите трябва да имат собственик и да представляват стойност.

Ledger — състои се от блокчейн „Blockchain“ и база данни „Word state“, в която се съхранява текущото състояние на asset-ите. World state използва LevelDB или CouchDB.

Смарт контракт — с помощта на смарт-контракти се реализира бизнес логиката на системата. В Hyperledger Fabric смарт-контрактите се наричат chaincode. С помощта на chaincode се задават asset-ите и транзакциите по тях. Ако говорим технически, смарт-контрактите са програмни модули, реализирани на програмни езици като JS или Go.

Endorsement policy — за всеки chaincode може да се зададе политика колко и от кого е необходимо да се очакват потвърждения за транзакцията. Ако политиката не е зададена, по подразбиране се използва: “транзакцията трябва да бъде потвърдена от всеки член (member) на която и да е организация в channel”. Примери за политики:

• Транзакцията трябва да бъде потвърдена от всеки администратор на организацията;
• Всеки член (member) или клиент на организацията трябва да потвърди;
• Всеки peer на организацията трябва да потвърди.

Услуга за поръчване — опакова транзакции в блокове и ги изпраща на peer-ите в channel. Гарантира доставяне на съобщения до всички peer-ове в мрежата. За индустриални системи се използва брокер на съобщения Kafka, за разработка и тестване Solo.

CallFlow

• Приложението взаимодейства с Hyperledger Fabric, използвайки Go, Node.js или Java SDK;
• Клиентът създава транзакция tx и я изпраща на endorsing peer-ите;
• Peer-ът проверява подписа на клиента, изпълнява транзакцията и изпраща endorsement signature обратно на клиента. Chaincode се изпълнява само на endorsing peer, а резултатът от изпълнението му се разпраща на всички peer-ове. Този алгоритъм на работа се нарича — PBFT (Practical Byzantine Fault Tolerant) консенсус. Различава се от класическия BFT по това, че съобщението се разпраща и се очаква потвърждение не от всички участници, а само от определен набор;
• След като клиентът получи брой отговори, съответстващи на endorsement policy, той изпраща транзакцията на услугата за поръчване;
• Услугата за поръчване формира блок и го изпраща на всички committing peer-ове. Услугата за поръчване осигурява последователно записване на блокове, което изключва така наречения ledger fork (вижте раздел „Форки“);
• Peer-ите получават блока, отново проверяват endorsement policy, записват блока в блокчейна и променят състоянието в „World state“ DB.

Така се получава разделение на ролите между нодовете. Това осигурява мащабиране и сигурност на блокчейна:

• Смарт-контрактите (chaincode) се изпълняват от endorsing peer-ите. Това осигурява конфиденциалност на смарт-контрактите, тъй като те не се съхраняват от всички участници, а само на endorsing peer-ите.
• Услугата за поръчване трябва да работи бързо. Това се осигурява от факта, че услугата за поръчване само формира блока и го изпраща на фиксиран набор от leader peer-ове.
• Committing peer-ите просто съхраняват блокчейна — те могат да бъдат много и не изискват голяма мощност и мигновена работа.

Повече архитектурни решения на Hyperledger Fabric и защо работи така, а не иначе можете да видите тук: Произход на архитектура или тук: Hyperledger Fabric: Дистрибуционна операционна система за разрешени блокчейни.

И така, Hyperledger Fabric е наистина универсална система, с помощта на която можете да:

• Реализирате произволна бизнес логика, използвайки механизма на смарт-контрактите;
• Записвайте и получавайте данни от блокчейн база данни в формат JSON;
• Предоставяйте и проверявайте достъп до API, използвайки Certificate Authority.

Сега, когато малко се запознахме със спецификата на Hyperledger Fabric, нека най-накрая да направим нещо полезно!

Разгръщам блокчейн

Формулиране на задачата

Задачата е да реализираме мрежа Citcoin с следните функции: създаване на акаунт, получаване на баланс, попълване на сметка, прехвърляне на монети от една сметка на друга. Нека нарисуваме обектна модел, който впоследствие ще реализираме в смарт-контракт. И така, ще имаме акаунти, идентифицирани с имена (name) и съдържащи баланс (balance), и списък с акаунти. Акаунтите и списъкът на акаунтите представляват asset в терминологията на Hyperledger Fabric. Следователно, те имат история и текущо състояние. Ще се опитам да го илюстрирам визуално:

Горните фигури представляват текущото състояние, което се съхранява в базата "World state". Под тях фигурите показват историята, която се съхранява в блокчейна. Текущото състояние на asset-ите се променя чрез транзакции. Asset-ът се променя изцяло, така че в резултат на изпълнението на транзакция се създава нов обект, а текущата стойност на asset-а отива в историята.

IBM Cloud

Създайте профил в IBM Cloud. За да използвате блокчейн платформата, трябва да актуализирате до Pay-As-You-Go. Този процес може да не е бърз, тъй като IBM изисква допълнителна информация и я проверява ръчно. От положителна страна мога да кажа, че IBM предлага добри учебни материали, които позволяват разгръщането на Hyperledger Fabric в техния облак. Хареса ми следният цикъл от статии и примери:

• Създайте основна блокчейн мрежа, използвайки Blockchain Platform
• Създайте и изпълнете смарт-контракт на блокчейн
• Излъчвайте събития от Blockchain Platform

Следват экранирани изображения на IBM Blockchain платформата. Това не е инструкция за създаване на блокчейн, а просто демонстрация на обхвата на задачата. Така че, за нашите цели, създаваме една Organization:

В нея създаваме възли: Orderer CA, Org1 CA, Orderer Peer:

Създаваме потребители:

Създаваме Channel и го наричаме citcoin:

По същество Channel е блокчейн, поради което започва от нулев блок (Genesis block):

Пишем смарт-контракт

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

Интуитивно тук всичко трябва да е ясно:

• Има няколко функции (AddAccount, GetAccounts, SendFrom, GetBalance, RefillBalance), които демо програмата ще извика с помощта на Hyperledger Fabric API.
• Функциите SendFrom и RefillBalance генерират събития (Event), които демо програмата ще получава.
• Функцията instantiate — се извиква веднъж при инстанцирането на смарт-контракта. Всъщност, тя се извиква не веднъж, а всеки път при промяна на версията на смарт-контракта. Затова инициализацията на списък с празен масив е лоша идея, тъй като при смяна на версията на смарт-контракта ще загубим текущия списък. Но нищо, аз само уча).
• Account-ите и списъкът с account-ите (accounts) — са JSON структури от данни. За манипулации с данните се използва JS.
• Можете да получите текущата стойност на asset-а, като извикате функцията getState, а да я обновите чрез putState.
• При създаването на Account се извиква функцията AddAccount, в която се осъществява сравнение с максималния брой account-и в блокчейна (maxAccounts = 5). И тук има грешка (забелязали ли сте?), която води до безкраен ръст на броя на account-ите. Такива грешки трябва да се избягват)

След това зареждаме смарт-контракта в Channel и го инстанцираме:

Виждаме транзакцията за инсталиране на Smart Contract:

Виждаме подробности за нашия Channel:

В резултат получаваме следната схема на блокчейн мрежа в облака на IBM. В схемата има и демо програма, стартирана в облака на Amazon на виртуален сървър (подробно за нея ще бъде в следващия раздел):

Създаване на GUI за извиквания на Hyperledger Fabric API

Hyperledger Fabric има API, което може да се използва за:

• Създаване на channel;
• Свързване на peer към channel;
• Инсталиране и инстанциране на смарт-контракти в channel;
• Извикване на транзакции;
• Запитване за информация в блокчейна.

Разработване на приложение

В нашата демо програма ще използваме API само за извикване на транзакции и запитване за информация, тъй като останалите стъпки вече сме извършили, използвайки блокчейн платформата на IBM. Пишем GUI, използвайки стандартен технологичен стек: Express.js + Vue.js + Node.js. За това как да започнете да създавате модерни уеб приложения може да се напише отделна статия. Тук оставям линк на серия лекции, която ми хареса най-много: Full Stack Web App using Vue.js & Express.js. В резултат получихме клиент-сървърно приложение с познат графичен интерфейс в стила на Material Design от Google. REST API между клиента и сървъра се състои от няколко извиквания:

• HyperledgerDemo/v1/init — инициализиране на блокчейн;
• HyperledgerDemo/v1/accounts/list — получаване на списък на всички account-и;
• HyperledgerDemo/v1/account?name=Bob&balance=100 — създаване на account на Bob;
• HyperledgerDemo/v1/info?account=Bob — получаване на информация за account на Bob;
• HyperledgerDemo/v1/transaction?from=Bob&to=Alice&volume=2 — да се преведат две монети от Bob към Alice;
• HyperledgerDemo/v1/disconnect — да се прекрати връзката с блокчейна.

Описание на API с примери сложих на сайта „Postman“ — широко известна програма за тестване на HTTP API.

Демо приложение в облака на Amazon

Държах приложението в Amazon, тъй като IBM все още не е могъл да ъпгрейдира моя акаунт и да разреши създаването на виртуални сървъри. Като вишенка добавих домейн: www.citcoin.info. Ще поддържам малко сървъра включен, после ще го изключа, тъй като се начисляват такси за наем, а монетите citcoin на борсата все още не се търгуват) В статията поставям екранни снимки на демото, за да е ясна логиката на работа. Демо приложението може:

• Да инициализира блокчейн;
• Да създава акаунт (но сега нов акаунт не може да бъде създаден, тъй като е достигнато максималното число акаунти, определено в смарт контракта);
• Да получава списък с акаунти;
• Да превежда монети citcoin между Alice, Bob и Alex;
• Да получава събития (но сега събитията не могат да бъдат показани, така че в интерфейса за улеснение е написано, че събитията не се поддържат);
• Да логва действия.

Първо инициализираме блокчейн:

След това създаваме своя акаунт, без да пестим от баланса:

Получаваме списък на всички налични акаунти:

Избираме изпращача и получателя, получаваме техните баланси. Ако изпращачът и получателят са едно и също лице, то ще се извърши попълване на неговата сметка:

В лога следим за изпълнението на транзакциите:

Собственно с демо програмата на това е всичко. Следва да видим нашата транзакция в блокчейна:

И общия списък на транзакциите:

На това успешно завършихме реализацията на PoC по създаването на мрежа Citcoin. Какво още трябва да се направи, за да стане Citcoin пълноценна мрежа за превод на монети? Направо малко:

• На етапа на създаване на акаунта да се реализира генерирането на частен / публичен ключ. Частният ключ трябва да се съхранява при потребителя на акаунта, публичният в блокчейна.
• Да се извърши превод на монети, в който за идентификация на потребителя се използва не името, а публичния ключ.
• Да се шифроват транзакции, идващи от потребителя на сървъра с неговия частен ключ.

Заключение

Реализирахме мрежа Citcoin с функции: добавяне на акаунт, получаване на баланс, попълване на сметка, превод на монети от един акаунт на друг. И така, какво ни струваше PoC да построим?

• Трябва да изучим блокчейн изобщо и Hyperledger Fabric в частност;
• Да се научим да използваме облаците на IBM или Amazon;
• Да научите езика за програмиране JS и някакъв уеб фреймуърк;
• Ако трябва да се съхраняват данни, които не са в блокчейна, а в отделна база, то трябва да се научите да интегрирате например с PostgreSQL;
• Последно по списъка, но не по важност - без знания по Linux в съвременния свят не можете да се справите!)

Разбира се, не е ракета наука, но ще трябва да се потрудите!

Изходният код е на GitHub

Изходният код е поставен на GitHub. Кратко описание на репозитория:
Каталог «server» - Node.js сървър
Каталог «client» - Node.js клиент
Каталог «blockchain» (стойностите на параметрите и ключовете, разбира се, неработещи и приведени само за пример):

• contract - изходен код на смарт-контракта
• wallet - ключовете на потребителя за използване на Hyperledger Fabric API.
• *.cds - скомпилирани версии на смартконтрактите
• *.json файлове - примери за конфигурационни файлове за използване на Hyperledger Fabric API

Това е само началото!

Източник: habr.com