Hyperledger Fabric 2.0: Next Generation Blockchain

Hyperledger Fabric har eksistert for bedriftene i ganske lang tid nå. I virkeligheten tilbyr den en av de kreative plattformene for blockchain-brukstilfeller. Men en teknologi som ikke forbedrer seg over tid blir foreldet veldig raskt. Derfor ga Hyperledger oss den nye Hyperledger Fabric 2.0-utgivelsen.

I utgangspunktet tilbød selskapet tidligere en stoffversjon 1.4. Men nå har vi neste generasjon blockchain blant oss. Hvis du er mer enn begeistret for den nye utgivelsen som oss, sjekk ut denne guiden. For i dag skal vi snakke om hva den nye Hyperledger Fabric 2.0-utgivelsen og om alle funksjonene den introduserte.

Men før vi begynner, vil vi gi en oversikt over hva Hyperledger Fabric-plattformen er og hvilke funksjoner den opprinnelig tilbød.

Så la oss begynne!

Hva er Hyperledger Fabric?

Hyperledger Fabric er en distribuert reskontroplattform for bedriftsklasser som kommer med allsidighet, modularitet og ytelse. Så som du vet, finnes det også tillatelsesløse plattformer. Men stoff er annerledes enn det.

Det tillater ikke hvem som helst å komme inn på plattformen. Snarere gir den tillatt tilgang til brukerne som har autoritet i systemet. Mer, det tilbyr også personvern og smarte kontrakter for skalerbar og sikker ytelse.

Derfor kan enhver bransje bare bruke Hyperledger Fabric til alle slags løsninger. Mulighetene er ubegrensede, og bedrifter vil alltid få det beste resultatet fra den distribuerte reskontroplattformen.

Selv om brukere i et nettverkssystem vil samarbeide, men bedriftene trenger å opprettholde personvernet for visse interaksjoner. Det er det bransjen er basert på. For eksempel, kanskje en kjøper selger et produkt til forskjellige leverandører, men i forskjellige prisklasser.

Men kjøperen må opprettholde personvernet om det. Og det er her Hyperledger Fabric kan hjelpe.

I virkeligheten kan du enkelt opprette separate kanaler i en transaksjon for separate selgere. Du kan også bruke private datalternativer for å holde informasjonen på et hysj-hysj-nivå.

 

Hvorfor Hyperledger Fabric?

I virkeligheten utviklet Hyperledger Fabric seg over tid ved hjelp av open source-fellesskapet, og fokuserte hovedsakelig på brukssaker av bedriftsklasse. Mer, det tilbyr nå mange funksjoner som bedriften ofte krever. Så, la oss se hva dette er –

  • Modulær og tillatt arkitektur.
  • En veldig fleksibel godkjenningsløsning for konsensus blant alle transaksjoner som handler.
  • Fleksible og åpne smarte kontrakter som kan støtte forskjellige datamodeller og løsninger som strukturerte data, kontomodell, ustrukturerte data, UTXO-modell osv..
  • Pluggbare konsensusprotokollalternativer for bestilling av transaksjoner og blockibution.
  • Fullstendig personvern for transaksjonsisolering eller deling av kun behovsinformasjon ved bruk av private datamodeller.
  • Smart kontraktsstøtte for flere programmeringsspråk som JavaScript, Java, Go osv.
  • Versjonering og styring for smarte kontrakter.
  • Støtte for soliditet.
  • Støtte for Ethereum Virtual Machine.
  • Kontinuerlige oppdateringer, bedriftsoperasjoner, asymmetrisk versjonsstøtte.
  • Kvadratiske data som rekkevidde-spørsmål, tastede spørsmål, on-chain JSON-spørsmål, og mange flere.

 

Hyperledger Fabric 2.0: Hva er nytt?

Den aller første Hyperledger Fabric-utgivelsen var tilbake i v1.0. Og nå har vi den andre store Hyperledger Fabric 2.0-utgivelsen. Denne gangen kommer det med mange nye og forbedrede funksjoner for både brukere og operatører i plattformen.

Hyperledger Fabric 2.0-utgivelsen inkluderer personvernmønstre og støtter nye applikasjoner, nye funksjoner for driftsnoder, forbedrede styringssystemer for smarte kontrakter og mange flere.

De vil imidlertid ikke tvinge deg til å oppgradere til den nyeste Hyperledger Fabric 2.0 hvis du ikke er klar ennå. Så du har muligheten til å oppgradere når du er klar, eller din bedrift er klar for overgangen.

Og det er et stort pluss poeng for Hyperledger Fabric 2.0.

La oss sjekke ut noen av høydepunktene i den nye utgivelsen –

Smarte kontrakter desentralisert styring

Hyperledger Fabric 2.0 kommer nå med desentralisert styring, spesielt for smarte kontrakter. Det tilbyr også en ny prosess der du kan installere en kjettingkode på jevnaldrende og starte den på kanalen. Dermed tillater den nye kjedekoden livssyklusadministrasjon nå flere organisasjoner å komme til en avtale basert på parameterne for kjedekoden.

Så, i utgangspunktet vil du bruke retningslinjene for godkjenning av kjettingkoder for å samhandle med hovedboken. La oss se hvilke andre forbedringer det gir i løpet av den forrige livssyklusprosessen for kjedekoden –

 

Avtale med parametrene for kjettingkoden

I utgangspunktet, i forrige utgivelse, kunne bare en organisasjon i kjedekoden sette opp parametrene også for andre kanalmedlemmer. Men de andre medlemmene kunne nekte å få kjettingkoden og ikke delta i transaksjonsprosessen. Derfor påkaller det.

Imidlertid tilbyr den nye Hyperledger Fabric 2.0 en mer fleksibel rute for kjedekoden. Nå støtter den både sentraliserte kjedekodemodeller og desentraliserte kjedekodemodeller. I den desentraliserte versjonen må selskapene komme til enighet om kjedekoden for å bli aktiv på kanalen.

 

Forsiktige oppgraderinger av kjettingkoder

Tidligere kunne bare en enkelt organisasjon oppgradere transaksjonen. Dette vil imidlertid føre til at de andre kanalmedlemmene er i fare hvis de ikke har kjedekoden installert. Dermed tillater den nye Hyperledger Fabric versjonen 2.0 at kjedekoden kun kan oppgraderes etter at nok medlemmer er enige om oppgraderingen uten problemer.

 

Privat datainnsamling og enkle policyoppdateringer

Den nye Hyperledger Fabric versjonen 2.0 tilbyr en ny policy for godkjenning der du kan oppgradere den private datainnsamlingen eller policy-konfigurasjonen uten å installere kjettingkoden på nytt. Mer, brukerne kan benytte seg av godkjennelsespolitikken, ettersom det krever enighet fra et stort antall brukere på kanalen.

I virkeligheten vil policyen oppdateres hver gang et medlem kommer på hovedboken eller forlater hovedboken.

 

Inspiserbare kjettingkodepakker

Nå kommer Hyperledger Fabric versjon 2.0 med en lett lesbar tjærefil for kjedekode. Det vil hjelpe deg å inspisere kjedekodefilene enkelt og bestemme installasjonene på tvers av andre organisasjoner.

 

Flere kjedekoder på en kanal

I den forrige versjonen, brukte livssyklusen til å definere hver kjedekode ved hjelp av versjonen og navnet som ble spesifisert under installasjonen av pakken. Men nå kan du bare bruke en enkelt kjedekodepakke og distribuere den mer enn en gang med flere navn hver gang på nettverket. Du kan også gjøre det på forskjellige kanaler eller på samme kanal.

 

Kjedekodepakker på tvers av kanalmedlemmer

I Hyperledger Fabric versjon 2.0 kan brukerne utvide en kjedekode for egne tilfeller. For eksempel kan en organisasjon utvide en kjedekode for validering i sitt eget selskap. Men det er et minimum antall krav fra organisasjoner. Så når nok påtegning er mulig, blir transaksjonene validert og får plass på hovedboken.

Dermed vil det hjelpe din bedrift å automatisk løse eventuelle problemer i din egen tid uten å gå på kompromiss med hele nettverket.

 

Bruke den nye kjedekoden livssyklus

Hyperledger Fabric versjon 2.0 tilbyr nå en helt ny kjedekodes livssyklus. Men hvis du ikke er klar for de nye endringene, kan du bare fortsette å bruke den forrige livssyklusen med Hyperledger Fabric versjon 2.0.

I virkeligheten vil den nye livssyklusen bare bli aktiv når du oppdaterer funksjonene til v2.0.

 

Nye kjedekodeprogrammer

I utgangspunktet lar Hyperledger Fabric 2.0-veikart deg bruke samme desentraliserte konsensusmetode for dine egne kjedekodeapplikasjoner. Det vil sikre at organisasjonene har samtykke til datatransaksjonene før de forplikter seg til hovedboken.

Automatiserte kontroller

En organisasjon kan legge til automatiserte sjekker i kjedekoden for å validere mer informasjon før de godkjenner en transaksjon på hovedboken.

Desentralisert avtale

Det beste er at Hyperledger Fabric 2.0-veikart lar deg modellere menneskelige beslutninger om kjedekoden for å spenne over mer enn en transaksjon. Du trenger imidlertid andre brukere fra organisasjoner for å samhandle med vilkårene og betingelsene i avtalen.

Til slutt kan et kjedekodeforslag bekrefte at alle brukerens vilkår er oppfylt og avgjøre transaksjonen ut fra det.

 

Evner

Det er visse funksjoner i veikartet Hyperledger Fabric 2.0. La oss se hva dette er –

Søknad V2_0: Den starter en ny livssyklus for kjedekoden for operatører, som nevnt i kjeden.

Kanal V2_0: I utgangspunktet har den ingen endringer, men du kan bruke den til å opprettholde samsvar med det bestilte funksjonsnivået og applikasjonene.

Bestiller V2_0: Denne styrer UseChannelCreationPolicyAsAdmins, og endrer måten vanligvis en kanaltransaksjon er validert på. Hvis du kombinerer det med alternativet -baseProfile, kan du endre de tidligere arvede verdiene i bestillersystemet.

 

Men når du oppdaterer kapasitetsnivåene, må du alltid huske å oppdatere kollegebinærene også. Oppdater også bestillerbinariene før du oppdaterer bestillings- og kanalfunksjonene.

 

Forbedringer av private data

Hyperledger Fabric 2.0-veikartet har også et nytt mønster for å dele alle dine private data uten å samle dem alle samtidig, og deretter kombinere kanalmedlemmer basert på det. Mer spesifikt, uten å dele privat informasjon med en samling brukere, kan du bare dele den med en enkelt organisasjon.

Men før vi går litt dypere inn i Hyperledger Fabric 2.0-dokumentasjonen, la oss se hva private data faktisk refererer til i Hyperledger.

 

Hva er private data?

I mange tilfeller kan et selskap ha behov for å holde viss informasjon privat i en kanal fra andre selskaper. Dermed må de opprette en ny kanal med bare organisasjonene som kan se informasjonen hver for seg. Men det betyr at det også vil trenge ekstra administrasjoner, policyer, tilgang til medlemskap og mange flere.

Mer, det tillater heller ikke at kanaldeltakeren bruker systemet i noen brukstilfeller der alle parter kan se en del av informasjonen mens andre forblir skjulte..

Nå vil imidlertid Hyperledger Fabric 2.0-veikartet hjelpe deg med å lage en privat datainnsamling. Her kan du definere et delsett av selskaper som kan se private data uten å opprette en ny kanal for hvert tilfelle.

 

Hva er privat datainnsamling?

I utgangspunktet er en samling en kombinasjon av to forskjellige elementer –

Den faktiske informasjonen som sendes mellom jevnaldrende ved hjelp av sladderprotokollen. Men her er det bare virksomheten som har tillatelse til å se det, som kan se dette. I utgangspunktet er disse dataene på en privat statsdatabase innenfor hovedbokene til jevnaldrende i den organisasjonen.

Mer, det er ingen bestillingstjenester her, og de kan ikke se den private informasjonen. Når sladderprotokollene sender informasjonen fra en kollega til en annen, må du uansett sette opp ankernoder i kanalen.

Den inneholder også en hash av de private dataene som er bestilt, godkjent og skrevet på hovedboken til alle jevnaldrende i kanalen. I utgangspunktet fungerer det som bevis for validering av en transaksjon på kanalen. Du kan også bruke den til revisjonsformål.

 

Bruke en samling

Innenfor en kanal

Du må bruke kanaler hvis du vil holde en hel transaksjon hemmelig for en gruppe organisasjoner innenfor kanalen.

Separat kanal

I følge Hyperledger Fabric 2.0-dokumentasjon kan du bruke samlinger når du bare trenger å holde en del av reskontroen hemmelig fra et sett med bedrifter.

I virkeligheten vil noen organisasjoner ha full tilgang til hovedboken, og andre kan bare se hva de har lov til. Hvis du også vil holde transaksjonsdata skjult fra bestillingstjenestene, kan du bruke private datainnsamlinger for konfidensialitet.

 

Et eksempel

La oss sjekke ut et eksempel fra dokumentasjonen Hyperledger Fabric 2.0 for å forstå situasjonen bedre.

La oss si at det i en handelsplattform er fem bedrifter i en kanal.

  • Bonden som selger varer
  • Distributør som flytter varene
  • Avsender som flytter varer mellom to parter
  • Grossist som kjøper varer fra distributøren
  • Forhandler som kjøper varene fra grossistene og avsenderne

I utgangspunktet kan distributøren lade opp ulikt i alle tilfeller. Så han vil kanskje holde transaksjoner med avsender og Farmer private fordi han kan ha andre avtaler med forhandleren og grossisten.

Distributøren krever også mindre av en grossist enn av en forhandler. Dermed vil han kanskje holde det hemmelig fra forhandleren.

Grossisten kan derimot også ha private forhold til avsenderen og forhandleren. Men hvis du vil opprette en egen kanal for hver privat informasjon, vil systemet bli mye mer komplisert.

I stedet for å gjøre det, kan du ha forskjellige private datasamlinger eller PDCer for hvert av medlemmene.

Som for eksempel,

Privat datainnsamling-1: Avsender, bonde og distributør

Privat datainnsamling-2: Avsender, forhandler og grossist

Privat datainnsamling-3: Grossist og distributør

I henhold til dokumentasjonen til Hyperledger Fabric 2.0, vil alle distributørpartnere ha private databaser som inneholder private data for relasjon mellom avsender, bonde og distributør og grossist og distributørrelasjon..

 

Forbedringer i datamønstre

I følge Hyperledger Fabric 2.0-dokumentasjon er det noen forbedringer som faktisk gjør det mulig for de nye private datamønstrene å fungere. Disse er –

Deling og verifisering av private data

Mottakende parter kan bruke GetPrivateDataHash () API for å verifisere om de private dataene som deles med dem er autentiske eller ikke i to scenarier –

  • Når du deler privat informasjon med en kanalbruker som ikke er medlem av en samling.
  • Når du deler den med en annen samling som kommer med ett eller flere medlemmer.

 

Politikk for påtegningsnivå på samlingsnivå

Du kan nå definere private datasamlinger ved hjelp av en godkjenningspolicy som kan overstyre andre kjedekodenivåpolicyer for nøkler i samlingen. I utgangspunktet kan du bruke den til å begrense andre bedrifter til å skrive på samlingen og hva som kan muliggjøre kjedekodes livssyklus og applikasjonsmønstre.

Vel, for eksempel kan det hende du trenger godkjenning der hvis majoritetsbedrifter er enige, kan du starte transaksjonen, men i tilfeller kan det hende du trenger avtalen fra en bestemt organisasjon for å få den til å fungere.

 

Implisitte samlinger per organisasjon

I henhold til Hyperledger Fabric 2.0-dokumentasjon, hvis du vil bruke et privat datamønster per organisasjon enn du kan distribuere kjedekode uten å definere samlingen i den nye versjonen. Det er en av de viktigste Hyperledger Fabric 2.0-funksjonene.

 

Ekstern kjettingkode Launcher

De ekstern kjedekode launcher er en av de fantastiske Hyperledger Fabric 2.0-funksjonene. Hovedsakelig vil det styrke operatørene ettersom de nå kan velge å lansere kjedekoden for deres valg av teknologi. Mer, du trenger ikke å bruke en ekstern launcher eller builder for det, og den kjører kjedekoden ved hjelp av Docker API.

I utgangspunktet trenger ikke jevnaldrende nå få tilgang til en Docker-demon for å kjøre eller bygge kjedekoden. I et produksjonsmiljø er det absolutt ikke ønskelig, og det er derfor jevnaldrende kan nå eliminere avhengigheten av Docker-demon.

Nå trenger du ikke å kjøre en kjedekode i en Docker-container, du kan saksøke ditt eget miljøvalg for å kjøre kjedekoden.

I tillegg kan operatørene tilby kjørbare eksterne byggere for å overstyre hvordan brukerne starter eller bygger kjedekode.

Tidligere lanserte jevnaldrende en kjedekode, og deretter ble den koblet tilbake til dem. Men nå kan du kjøre den som den eksterne tjenesten.

 

Forbedret ytelse på CouchDB

Tidligere, når du bruker CouchDB-tilstandsdatabasen, vil du møte leseforsinkelser i validering og godkjenning. Så det var vanskelig å få ytelsen så jevn som mulig. Men nå, med Hyperledger Fabric 2.0-funksjoner, får du en ny peer-cache som vil erstatte lange oppslag med raske utganger. Mer, du kan konfigurere dem med core.yaml eiendom cacheSize.

 

Alpine-baserte Docker-bilder

I den nye Hyperledger Fabric 2.0 vil den bruke Alpine Linux til Docker-bildene. Alpine Linux er en sikrere og lett Linux-distribusjon som enkelt kan øke ytelsen til nettverket.

I virkeligheten betyr det at Docker-bilder vil ha mindre størrelse, så det vil ta kortere tid å laste ned eller for oppstart. Mer, det vil ikke ta for mye plass fra nå av også.

Selskapet designet Alpine Linux fra bunnen av, med tanke på sikkerhet, og den minimalistiske funksjonen i denne distribusjonen blir kvitt alle sårbarheter.

 

Eksempel på testnettverk

Nå har du et nytt prøvetestnettverk i stoff-prøvelageret. Det er en av de kule Hyperledger Fabric 2.0-funksjonene. I virkeligheten er dette testnettverket modulært og enkelt å bruke. Så du har ingen problemer med å teste ut smarte kontrakter eller applikasjoner før du lanserer løsningen.

I tillegg kan du også distribuere nettverket med sertifikatmyndigheter sammen med cryptogen.

 

Hvordan oppgradere til Fabric v2.0

Hver gang en større utgivelse oppstår, gir det massevis av problemer med hensyn til oppgradering. I mange tilfeller kan det hende du må installere den nye versjonen fra bunnen av, men det kan ha stansetid. Men en av Hyperledger Fabric 2.0-funksjonene er at hvis du allerede er på versjon 1.4, kan du oppgradere direkte til versjon 2.0 uten nedetid.

De har også omarbeidet og utvidet oppgraderingsdokumentene slik at du kan sjekke ut, og har også et frittstående hjem i dokumentasjoner. Vil du oppgradere? Så sjekk ut deres dokumentasjon på det.

I utgangspunktet er oppgradering til den siste utgivelsen en firetrinnsprosess –

  • Først må du sikkerhetskopiere hovedbøkene og MSP-ene.
  • Deretter begynner du å oppgradere på rullende måte bestillerbinariene til den nyeste versjonen.
  • Etter det, følg den samme oppdateringsprosessen også for kollegabinærene.
  • Til slutt må du oppdatere applikasjonskanalene og bestillersystemkanalen til deres nyeste funksjoner når de er tilgjengelige. Mer, ikke alle utgivelsene vil ha økende evner, noen ganger har de store forbedringer en gang de ikke vil.

 

Oppgradere opplæringsprogrammer

Før du oppgraderer noen prosesser, bør du vurdere å sjekke ut veiledningene deres for det. Du kan også se på stoffveiledningen vår også. Uansett gir vi en kort versjon av det her –

  • Før du oppgraderer mulighetene dine, bør du oppgradere alle komponentene dine først. Forsikre deg om at de er den nyeste versjonen.
  • Sørg også for å oppdatere alle nodene til den nyeste versjonen før du oppdaterer hele kanalen.
  • Du må legge til påtegningsretningslinjer for et bestemt selskap for å starte en ny livssyklus for kjedekoden i systemet.

Stoffet anser nå oppgradering av noder og økende evner som en standard.

Merk: Det anbefales at du også oppgraderer SDK-en til den nyeste versjonen. Selv om SDK-en din burde være i stand til å håndtere tilsvarende utgivelser av Hyperledger Fabric og lavere versjon, ville det være best å oppdatere den, for da kan du bruke de nyeste Fabric-funksjonene effektivt.

Hvis du fremdeles er forvirret om oppgraderingsprosessen, kan du sjekke dokumentasjonen for den.

 

Konklusjon

Den siste utgivelsen av versjonen 2.0 er en milepæl i historien. I virkeligheten anses Fabric 2.0 å være neste generasjons blockchain-teknologi. Mer, det er så mange Hyperledger Fabric 2.0-funksjoner som gir mange muligheter.

Fra nå av vet vi fortsatt ikke hvordan denne teknologien vil utføre, eller om den nye versjonen endelig kan kvitte seg med de negative sidene ved blockchain. Likevel ga den nye milepælen for Hyperledger-familien og samfunnet mange nye forbedringer, og vi kan bare håpe på det beste.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
map