Claustrum: quid PoC aedificare debemus?

Oculi mei timent, sed manus meae pruriunt!

In articulis prioribus, technologias quibus catenae catenerum (blockchain) innituntur inspeximus (Quid faciamus stipitem?) et casus qui eorum auxilio exsequi possunt (Quanti nobis constat causam construere?Tempus est manibus operam dare! Pro pilotis et probationibus conceptus (PoCs), nube uti malo, cum ex quolibet loco mundi accessibilis sit et saepe necessitatem taediosae configurationis ambitus tollat, cum configurationes praeformatae praesto sint. Itaque, construamus aliquid simplex, sicut rete ad nummos inter participes transferendos, et Citcoin vocemus. Utemur nube IBM et universali catena catenae Hyperledger Fabric. Primo, intellegamus cur Hyperledger Fabric catena catenae universalis appellatur.

Claustrum: quid PoC aedificare debemus?

Hyperledger Fabric — catena catenarum universalis

Generaliter loquendo, systema informationis universale est:

  • Series servorum et nucleus programmatum qui logicam negotialem exsequitur;
  • Interfacies ad interactionem cum systemate;
  • Media ad registrationem, authenticationem et auctoritatem instrumentorum/personarum;
  • Index datorum notitias operationales et archivales continens:

Claustrum: quid PoC aedificare debemus?

Versio officialis quid sit Hyperledger Fabric legi potest apud websiteBreviter, Hyperledger Fabric est suggestus fontis aperti qui constructionem privatarum catenarum (blockchains) et exsecutionem contractuum intelligentium (smart contracts) consuetudinariorum, in JavaScript et Go scriptorum, permittit. Architecturam Hyperledger Fabric propius inspiciamus et videamus systema universale esse, cum tantum requisitis specificis ad data conservanda et notanda. Haec requisita sunt ut, sicut in omnibus catenis (blockchains), data in segmentis conserventur, quae catenae tantum adduntur si participes consensum attingunt, et semel scripta, data non possint non detegi nec deleri.

Architectura Texturae Hyperledger

Diagramma architecturam Hyperledger Fabric ostendit:

Claustrum: quid PoC aedificare debemus?

organizations — organizationes pares continent, id est, catena catenarum (blockchain) exstat gratia auxilii organizationum. Organizationes diversae partem unius canalis esse possunt.

Channel — structura logica quae pares in greges coniungit, ita catenam catenarum (blockchain) definit. Hyperledger Fabric simul plures catenas catenarum cum diversa logica negotiali tractare potest.

Provisor Servitiorum Sodalium (MSP) — est CA (Auctoritas Certificationis) ad identitates edendas et munera assignanda. Ad nodum creandum, cum MSP (Procuratore Servitiorum Administratorum) interagere debes.

Nodi pares — transactiones verificare, catenam nodorum (blockchain) reponunt, contractus digitales exsequuntur, et cum applicationibus interagunt. Pares identitatem (libellum digitale) a MSP emissum habent. Dissimiliter retibus Bitcoin vel Ethereum, ubi omnes nodi pares sunt, in Hyperledger Fabric nodi diversa munera agunt:

  • Par potest esse parem probantem (EP) et contractus callidos exsequi.
  • Par committens (CP) - tantum data in catena catenarum serva et "statum mundi" renova.
  • Par Anchorae (AP) - Si plures organizationes in catena catenarum (blockchain) participant, pares ancorae (anchor-pares) ad communicationem inter eas adhibentur. Quaeque organizatio unum vel plures pares ancoras habere debet. AP utens, quilibet par in organizatione informationem de omnibus paribus in aliis organizationibus obtinere potest. Ad informationem inter AP synchronizandam, rete par-ad-parem adhibetur. Protocollum rumorum.
  • Dux Par Si organizatio plures pares habet, solus dux par partes a Servitio Ordinationis accipiet et eas aliis paribus distribuet. Dux vel statice assignari vel dynamicē a paribus intra organizationem eligi potest. Protocollum "gossip" etiam ad synchronizationem informationis de ducibus adhibetur.

bONA — entitates valoris in catena catenarum (blockchain) repositae. Praecipue, hae sunt data clavis-valoris in forma JSON. Haec data in "Catena Catenae" (Blockchain) notantur. Historiam habent, quae in catena catenarum servatur, et statum praesentem, qui in basi datorum "Status Mundi" servatur. Structurae datorum arbitrio implentur secundum necessitates negotii. Nullae sunt areae necessariae; sola commendatio est ut bona dominum habeant et valorem repraesentent.

ledger — constat ex catena catenarum (blockchain) et basi datorum Status Mundi (World State), quae statum praesentem bonorum servat. Status Mundi (World State) LevelDB vel CouchDB utitur.

contractus dolor — Contractus intelligentes (vel "smart contracts") logicam negotialem systematis efficiunt. In Hyperledger Fabric, contractus intelligentes "chaincode" appellantur. Chaincode ad res et transactiones eas implicantes definiendas adhibetur. Technice, contractus intelligentes sunt moduli programmatum in JS vel Go implementati.

Ratio commendationis — Pro singulis codicibus catenariis, normas constituere potes de numero et a quibus confirmationes transactionis exspectandae sint. Si nulla norma constituta est, praedefinitum est "Transactio ab quolibet membro cuiuslibet organizationis in canali confirmanda est." Exempla normarum:

  • Transactio ab quolibet administratore organizationis confirmanda est;
  • Ab quolibet socio vel cliente organizationis confirmandum est;
  • Ab quavis societate pari verificandum est.

Officium ordinationis — transactiones in partes congerit et ad pares in canali mittit. Traditionem nuntiorum ad omnes pares in reti praestat. Pro systematibus industrialibus, hoc adhibetur. Nuntiorum interpres Kafkaensis, ad progressionem et probationem Solo.

Fluxus Vocationum

Claustrum: quid PoC aedificare debemus?

  • Applicatio cum Hyperledger Fabric utens Go, Node.js, vel Java SDK interagitur;
  • Cliens transactionem transmissionis creat et ad pares probantes mittit;
  • Par signaturam clientis verificat, transactionem exsequitur, et signaturam probationis clienti remittit. Codex catenatus (Chaincode) solum in pari probante exsequitur, et eventus omnibus paribus divulgatur. Hic algorithmus consensus PBFT (Practical Byzantine Fault Tolerant) appellatur. Differt a... classicum BFT quod nuntius mittitur et confirmatio non ab omnibus participibus, sed tantum a certo grege exspectatur;
  • Postquam cliens numerum responsionum secundum normas commendationis accepit, transactionem ad servitium Ordinationis mittit;
  • Officium ordinationis formam quadrati format et omnibus paribus committentibus mittit. Officium ordinationis efficit ut quadrati ordine scribantur, quod furcam libri (ledger fork) appellatam eliminat.vide sectionem "Furcae");
  • Pares frustum accipiunt, rationem approbationis iterum inspiciunt, frustum in catenam catenarum scribunt, et statum in "Status Mundi" DB mutant.

Hoc divisionem munerum inter nodos efficit. Hoc scalabilitatem et securitatem catenae catenarum (blockchain) praestat:

  • Contractus callidi (codices concatenati) a paribus probantibus exsequuntur. Hoc secretum contractuum callidorum praestat, cum codex solum a paribus probantibus, non ab omnibus participibus, servetur.
  • Ordinatio celeris esse debet. Hoc eo efficitur quod Ordinatio tantum unum blocum generat et ad certum numerum parium ductorum mittit.
  • Pares committentes tantum catenam catenarum (blockchain) servant—multi eorum esse possunt nec magnam potentiam aut operationem instantaneam requirunt.

Plura de decisionibus architecturae Hyperledger Fabric et cur eo modo operetur hic discere potes: Origines Architecturae vel hic: Hyperledger Fabric: Systema Operandi Distributum pro Catenis Blockchain Permissis.

Ergo, Hyperledger Fabric est systema vere universale quod tibi permittit:

  • Rationem negotiorum propriam per mechanismum contractuum callidorum implementa;
  • Data ex basi datorum catenarum catenarum (blockchain) in forma JSON scribere et recuperare;
  • Accessum API concede et verifica utens Auctoritate Certificatoria.

Nunc, cum aliqua de Hyperledger Fabric specificis verbis explicavimus, tandem aliquid utile agamus!

Distributio catenae catenae (vel catenae catenae)

DE PECCATO quaestio

Propositum est reticulum Citcoin cum his functionibus implementare: rationem creare, bilancium accipere, rationem amplificare, et nummos ex una ratione in aliam transferre. Delineemus exemplar obiecti, quod deinde in contractu intelligenti implementabimus. Itaque rationes habebimus, nominibus identificatas et bilancium continentes, et indicem rationum. Rationes et index rationum sunt bona secundum Hyperledger Fabric. Proinde, historiam et statum praesentem habent. Hoc visualiter illustrare conabor:

Claustrum: quid PoC aedificare debemus?

Figurae superiores statum praesentem in indice datorum "Status Mundi" repositum repraesentant. Sub his figurae historiam in catena catenarum repositam ostendunt. Status praesens bonorum per transactiones mutatur. Bonum tantum in toto mutatur, ergo transactionem exsecuta novum obiectum creat, et valor praesens bonorum in historia perditur.

IBM Nubes

Rationem crea in IBM nubesAd suggestum "blockchain" utendum, necesse est illud ad "Pay-As-You-Go" promovere. Hic processus tempus multum consumere potest, cum IBM informationes additionales petat et eas manu verificet. Ex parte positiva, dicere possum IBM bonas materias institutionis habere ad Hyperledger Fabric in nube sua disponendum. Series articulorum et exemplorum sequens mihi placuit:

Infra sunt imagines suggestus IBM Blockchain. Haec non est dux ad creandam catenam catenarum, sed potius demonstratio amplitudinis operis. In nostro proposito, unam Organizationem creabimus:

Claustrum: quid PoC aedificare debemus?

In ea nodos creamus: Ordo CA, Org1 CA, Ordo Peer:

Claustrum: quid PoC aedificare debemus?

Usores creamus:

Claustrum: quid PoC aedificare debemus?

Canalem creemus et ei nomen "citcoin" imponamus:

Claustrum: quid PoC aedificare debemus?

Canalis essentialiter est catena catenarum (blockchain), ergo incipit a segmento zero (sectio Genesis):

Claustrum: quid PoC aedificare debemus?

Contractum Intelligentem Scribere

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

Intuitive, omnia hic clara esse debent:

  • Complures functiones (AddAccount, GetAccounts, SendFrom, GetBalance, RefillBalance) sunt quas programma demonstrationis per API Hyperledger Fabric vocabit.
  • Functiones `SendFrom` et `RefillBalance` eventa generant quae programma demonstrationis recipiet.
  • Functio "instantiate" semel vocatur cum contractus callidus instantiatur. Re vera, non semel tantum vocatur, sed quotiescumque versio contractus callidi mutatur. Ergo, indicem cum serie vacuo initiare mala idea est, quia indicem praesentem amittimus quotiescumque versio contractus callidi mutatur. Sed bene est, modo disco.
  • Rationes et index rationum sunt structurae datorum JSON. JavaScript ad manipulationem datorum adhibetur.
  • Valorem praesentem rei accipere potes functione `getState` vocando, et eum functione `putState` renovare.
  • Cum Ratio creatur, functio `AddAccount` vocatur, quae numerum maximum rationum in catena rationum (`blockchain` = 5) comparat. Hic vitium est (animadversumne?) quod ad infinitum incrementum numeri rationum ducit. Tales errores vitandi sunt.

Deinde, contractum intelligentem in Canalem imponimus et instantiam eius creamus:

Claustrum: quid PoC aedificare debemus?

Videamus transactionem ad Contractum Intelligentem instituendum:

Claustrum: quid PoC aedificare debemus?

Plura de Canali nostro inspice:

Claustrum: quid PoC aedificare debemus?

Diagramma retiaculi "blockchain" in nube IBM resultans tale est. Diagramma etiam programma demonstrativum in servo virtuali in nube Amazonica currentem includit (plus de hoc in sectione sequenti):

Claustrum: quid PoC aedificare debemus?

Creando GUI pro Vocationibus API Fabric Hyperledger

Hyperledger Fabric API habet quae adhiberi potest ad:

  • Creatio canalis;
  • Nexus inter pares et canales;
  • Institutio et instantiatio contractuum intelligentium in canali;
  • Vocatio transactionum;
  • Informationem in catena catenarum petere.

Applicationem progressio

In programmate nostro demonstrativo, API tantum ad transactiones initiandas et informationes petendas utemur, cum reliquos gradus iam per suggestum IBM blockchain perfecerimus. Interfaciem graphicam graphicam (GUI) scribemus utens acervo technologiae communi: Express.js + Vue.js + Node.js. Articulus separatus scribi posset de modo quo applicationes interretiales modernas creare incipias. Hic nexus est ad seriem lectionum quam maxime mihi placuit: Applicatio Telae Plenae Stack utens Vue.js et Express.jsResultatum est applicatio clientis-servitoris cum interfacie graphica familiari in stylo Designis Materialis Google. API REST inter clientem et servitorem constat ex pluribus invocationibus:

  • HyperledgerDemo/v1/init — catenam catenarum initiare;
  • HyperledgerDemo/v1/accounts/list — indicem omnium rationum accipe;
  • HyperledgerDemo/v1/account?name=Bob&balance=100 — rationem Bob crea;
  • HyperledgerDemo/v1/info?account=Bob — informationem de ratione Bob accipe;
  • HyperledgerDemo/v1/transaction?from=Bob&to=Alice&volume=2 — duos nummos a Bobo ad Aliciam transfer;
  • HyperledgerDemo/v1/disconnect — nexum cum catena catenarum claudere.

Descriptio API cum exemplis publicata est apud Situs interretialis tabellarii — programma late notum ad API HTTP probandas.

Applicatio demonstrativa in nube Amazonica

Applicationem ad Amazon imposui quia IBM adhuc rationem meam promovere et mihi permittere non potuit ut servos virtuales crearem. Dominium quasi cerasum in summo addidi: www.citcoin.infoServitorem aliquamdiu currentem tenebo, deinde eum exstinguebo, cum pretium locationis paulatim adveniat et Citcoin in bursa nondum recensetur. Imagines demonstrationis in articulo includo ut ratio clara sit. Applicatio demonstrationis haec potest:

  • Initializa catenam catenarum;
  • Rationem Crea (sed nunc non licet novam Rationem creare, cum catena catenarum (blockchain) numerum maximum rationum in contractu intelligenti definitum attigerit);
  • Indicem Rationum accipe;
  • Nummos Citcoin inter Aliciam, Bobum et Alexum transfer;
  • Eventa accipere (sed nunc nulla via est ad eventa ostendenda, ergo simplicitatis causa interfacies dicit eventa non sustineri);
  • Actiones nota.

Primum, catenam catenarum ("blockchain") initiamus:

Claustrum: quid PoC aedificare debemus?

Deinde, rationem tuam crea et tempus cum aequilibrio ne perdas:

Claustrum: quid PoC aedificare debemus?

Indicem omnium rationum praesto accipimus:

Claustrum: quid PoC aedificare debemus?

Mittentem et accipientem elige et eorum reliqua accipe. Si mittentis et accipientis idem sunt, ratio eorum supplebitur:

Claustrum: quid PoC aedificare debemus?

Exsecutionem transactionum in registro observamus:

Claustrum: quid PoC aedificare debemus?

Haec omnia de programmate demonstrativo. Deinde, transactionem nostram in catena blockchain inspicere potes:

Claustrum: quid PoC aedificare debemus?

Et index generalis transactionum:

Claustrum: quid PoC aedificare debemus?

Probationem Conscientiae retiaculi Citcoin feliciter perfecimus. Quid aliud agendum est ut Citcoin retiaculum plene perfectum ad translationes nummorum fiat? Pauca tantum:

  • In stadio creationis rationis, generationem clavis privatae/publicae adhibe. Clavis privata ab usore rationis servanda est, clavis publica autem in catena catenarum (blockchain) servanda.
  • Transferre nummos pecuniae est quod clavem publicam, non nomen, ad usorem identificandum adhibet.
  • Transactiones ab usore ad servitorem euntes clave eius privata encrypta.

conclusio,

Rete Citcoin cum his facultatibus implementavimus: rationem addere, aequilibrium accipere, rationem supplere, et nummos ex una ratione in aliam transferre. Quanti igitur nobis constabat PoC construere?

  • Necesse est blockchain in genere et Hyperledger Fabric in specie studere;
  • Disce quomodo nubibus IBM vel Amazon uti;
  • Linguam programmandi JS et nonnullas structuras interretiales disce;
  • Si quaedam data non in catena catenarum (blockchain), sed in separata basi datorum conservanda sunt, tum disce integrationem cum, exempli gratia, PostgreSQL;
  • Et denique, sed non minime, sine scientia Linux nusquam in mundo hodierno!)

Non est ars difficilis, sed strenue laborandum erit!

Fontes in GitHub

Fontes imposui GitHubBrevis descriptio repositorii:
Catalogus «Server" — Servus Node.js
Catalogus «huius" — Cliens Node.js
Catalogus «blockchain» (valores parametrorum et claves, scilicet, non operantur et exempli gratia tantum dantur):

  • contractus — fons contractus callidi
  • crumena — claves usoris ad API Hyperledger Fabric utendum.
  • *.cds — versiones compilatae contractuum intelligentium
  • Fasciculi *.json — exempla fasciculorum configurationis ad API Hyperledger Fabric utendum

Hoc solum initium est!

Source: www.habr.com

Emptum certos hospites pro locis cum praesidio DDoS, VPS VDS servers 🔥 Eme hospitium interretiale fidum cum praesidio DDoS, servitores VPS VDS | ProHoster