Hyperledger Fabric 2.0: nästa generations blockchain

Hyperledger Fabric har funnits för företagen under en längre tid nu. I verkligheten erbjuder den en av de kreativa plattformarna för blockchain-användningsfall. Men en teknik som inte förbättras med tiden blir föråldrad mycket snabbt. Det är därför Hyperledger gav oss den nya versionen av Hyperledger Fabric 2.0.

I grund och botten erbjöd företaget en Fabric-version 1.4. Men nu har vi nästa generations blockchain bland oss. Om du är mer än glad över den nya versionen som vi, kolla in den här guiden. För idag ska vi prata om vad den nya Hyperledger Fabric 2.0-versionen och om alla funktioner den introducerade.

Men innan vi börjar kommer vi att återspå vad Hyperledger Fabric-plattformen är och vilka funktioner den ursprungligen erbjöd.

Så, låt oss börja!

Vad är Hyperledger Fabric?

Hyperledger Fabric är en distribuerad ledgerplattform för företagslösningar som har mångsidighet, modularitet och prestanda. Så som du vet finns det också tillståndsfria plattformar. Men tyg skiljer sig från det.

Det tillåter inte vem som helst att komma in på plattformen. Det ger snarare behörig åtkomst till de användare som har behörighet i systemet. Mer så erbjuder den också dataintegritet och smarta kontrakt för skalbar och säker prestanda.

Därför kan alla branscher bara använda Hyperledger Fabric för alla typer av lösningar. Möjligheterna är obegränsade och företag kommer alltid att få bästa möjliga resultat från den distribuerade huvudplattformen.

Även om användare inom ett nätverkssystem kommer att arbeta tillsammans, men företagen behöver behålla integriteten för vissa interaktioner. Det är vad branschen bygger på. Till exempel kanske en köpare säljer en produkt till olika leverantörer men i olika prisklasser.

Men köparen måste behålla integriteten om det. Och det är här Hyperledger Fabric kan hjälpa till.

I verkligheten kan du enkelt skapa separata kanaler i en transaktion för separata säljare. Du kan också använda privata datalternativ för att hålla informationen på en tystnad-nivå.

 

Varför Hyperledger Fabric?


I själva verket utvecklades Hyperledger Fabric med tiden med hjälp av öppen källkod och fokuserade främst på användningsfall av företagsklass. Mer så erbjuder det nu många funktioner som företaget ofta kräver. Så, låt oss se vad det här är –

  • Modulär och tillåten arkitektur.
  • En mycket flexibel godkännandelösning för konsensus bland alla transaktionsorganisationer.
  • Flexibla och öppna smarta kontrakt som kan stödja olika datamodeller och lösningar som strukturerad data, kontomodell, ostrukturerad data, UTXO-modell, etc..
  • Pluggbara konsensusprotokollalternativ för att beställa transaktioner och blockibution.
  • Fullständig datasekretess för transaktionsisolering eller delning av endast information som behöver veta med hjälp av privata datamodeller.
  • Smart kontraktsstöd för flera programmeringsspråk som JavaScript, Java, Go, etc..
  • Version och styrning för smarta kontrakt.
  • Stöd för soliditet.
  • Stöd för Ethereum Virtual Machine.
  • Kontinuerliga uppdateringar, företagsdrift, stöd för asymmetrisk version.
  • Fyrkantsdata som intervallfrågor, nyckelfrågor, on-chain JSON-frågor och många fler.

 

Hyperledger Fabric 2.0: Vad är nytt?

Den allra första versionen av Hyperledger Fabric kom tillbaka i v1.0. Och nu har vi den andra stora versionen av Hyperledger Fabric 2.0. Den här gången kommer det med många nya och förbättrade funktioner för både användare och operatörer på plattformen.

Utgåvan av Hyperledger Fabric 2.0 innehåller sekretessmönster och stöder nya applikationer, nya funktioner för driftnoder, förbättrade styrsystem för smarta kontrakt och många fler.

De tvingar dig dock inte att uppgradera till den senaste Hyperledger Fabric 2.0 om du inte är redo än. Så du har möjlighet att uppgradera när du är redo, eller om ditt företag är redo för övergången.

Och det är ett stort plus för Hyperledger Fabric 2.0.

Låt oss kolla in några av höjdpunkterna i den nya utgåvan –

Smarta kontrakt decentraliserad styrning

Hyperledger Fabric 2.0 kommer nu med decentraliserad styrning, särskilt för smarta kontrakt. Det erbjuder också en ny process där du kan installera en kedjekod på kamraterna och starta den på kanalen. Den nya kedjekodens livscykelhantering tillåter således flera organisationer att nå en överenskommelse baserad på kedjekodens parametrar.

Så i grund och botten kommer du att använda kedjekodspolicyn för att interagera med storboken. Låt oss se vilka andra förbättringar den erbjuder under den tidigare livscykelprocessen för kedjekod –

 

Överensstämmelse med kedjekodens parametrar

I grund och botten, i den tidigare utgåvan, kunde bara en organisation i kedjekoden ställa in parametrarna även för andra kanalmedlemmar. Men de andra medlemmarna kunde vägra att få kedjekoden och inte delta i transaktionsprocessen. Därför åberopa det.

Den nya Hyperledger Fabric 2.0 erbjuder dock en mer flexibel väg för kedjekoden. Nu stöder den både centraliserade kedjekodsmodeller och decentraliserade kedjekodsmodeller. I den decentraliserade versionen måste företagen nå en överenskommelse om kedjekoden för att bli aktiv på kanalen.

 

Försiktiga kedjekodsuppgraderingar

Tidigare kunde bara en enda organisation uppgradera transaktionen. Det skulle dock ge de andra kanalmedlemmarna risk om de inte har kedjekoden installerad. Således tillåter den nya Hyperledger Fabric version 2.0 kedjekoden att uppgraderas först efter att tillräckligt många medlemmar är överens om uppgraderingen utan några problem.

 

Privat datainsamling och enkla uppdateringar av policyer

Den nya Hyperledger Fabric version 2.0 erbjuder en ny godkännandepolicy där du kan uppgradera den privata datainsamlingen eller policykonfigurationen utan att installera om kedjekoden. Mer så kan användarna använda godkännandepolicyn eftersom det kräver överenskommelse från ett stort antal användare på kanalen.

I själva verket kommer policyn att uppdateras varje gång en medlem kommer på huvudboken eller lämnar storboken.

 

Inspekterbara kedjekodspaket

Nu kommer Hyperledger Fabric version 2.0 med en lättläst tjärfil för kedjekod. Det hjälper dig att enkelt inspektera kedjekodfilerna och bestämma installationerna i andra organisationer.

 

Flera kedjekoder på en kanal

I den tidigare versionen användes livscykeln för att definiera varje kedjekod med den version och namn som anges under paketinstallationen. Men nu kan du bara använda ett enda kedjekodspaket och distribuera det mer än en gång med flera namn varje gång i nätverket. Du kan också göra det på olika kanaler eller på samma kanal.

 

Kedjekodspaket över kanalmedlemmar

I Hyperledger Fabric version 2.0 kan användare utöka en kedjekod för sina egna användningsfall. Till exempel kan en organisation utöka en kedjekod för validering inom sitt eget företag. Men det finns ett minimalt antal krav från organisationer. Så när tillräckligt godkännande är möjligt kommer transaktionerna att valideras och få en plats på storboken.

Således kommer det att hjälpa ditt företag att automatiskt åtgärda eventuella problem på din egen tid utan att kompromissa med hela nätverket.

 

Använda den nya livscykeln för kedjekoden

Hyperledger Fabric version 2.0 erbjuder nu en helt ny livscykel för kedjekoden. Om du inte är redo för de nya ändringarna kan du bara fortsätta använda den tidigare livscykeln med Hyperledger Fabric version 2.0.

I verkligheten blir den nya livscykeln bara aktiv när du uppdaterar funktionerna till v2.0.

 

Nya applikationsmönster för kedjekod

I grund och botten tillåter Hyperledger Fabric 2.0-färdplanen att du använder samma decentraliserade konsensusmetod för dina egna kedjekodapplikationer. Det kommer att säkerställa att organisationerna har samtycke till datatransaktionerna innan de förbinder sig till huvudboken.

Automatiserade kontroller

En organisation kan lägga till automatiserade kontroller i kedjekoden för att validera mer information innan de godkänner en transaktion på huvudboken.

Decentraliserat avtal

Det bästa är att Hyperledger Fabric 2.0-färdplanen låter dig modellera mänskliga beslut om kedjekoden för att spänna över mer än en transaktion. Du skulle dock behöva andra användare från organisationer för att interagera med villkoren i avtalet.

Slutligen kan ett kedjekodsförslag verifiera att alla användares villkor är uppfyllda och lösa transaktionen baserat på det.

 

Förmågor

Det finns vissa funktioner i färdplanen för Hyperledger Fabric 2.0. Låt oss se vad det här är –

Tillämpning V2_0: Det startar en ny kedjekods livscykel för operatörer, som nämns i kedjekoden.

Kanal V2_0: I grund och botten har den inga förändringar, men du kan använda den för att upprätthålla överensstämmelse med den ordnade kapacitetsnivån och applikationerna.

Beställare V2_0: Den här styr UseChannelCreationPolicyAsAdmins och ändrar sättet som typiskt en kanaltransaktion valideras. Om du kombinerar det med alternativet -baseProfile kan du ändra de tidigare ärvda värdena i beställningssystemet.

 

Men när du uppdaterar dina kapacitetsnivåer, kom alltid ihåg att uppdatera peer-binärerna också. Uppdatera också beställarbinarierna innan du uppdaterar beställnings- och kanalfunktionerna.

 

Förbättringar av privata data

Färdplanen för Hyperledger Fabric 2.0 kommer också med ett nytt mönster för att dela alla dina privata data utan att samla in dem alla samtidigt och sedan kombinera kanalmedlemmar baserat på det. Mer specifikt, utan att dela privat information med en samling användare kan du bara dela den med en enda organisation.

Men innan vi går lite djupare in i Hyperledger Fabric 2.0-dokumentationen, låt oss se vad privata data faktiskt hänvisar till i Hyperledger.

 

Vad är privata data?

I många fall kan ett företag behöva hålla viss information privat i en kanal från andra företag. De måste alltså skapa en ny kanal med endast de organisationer som kan se informationen separat. Men det betyder att det också kommer att behöva ytterligare förvaltningar, policyer, tillgång till medlemskap och många fler.

Mer så tillåter det inte att kanaldeltagaren använder systemet i alla användningsfall där alla parter kan se någon del av informationen medan andra förblir dolda.

Men nu kan Hyperledger Fabric 2.0 färdplanen hjälpa dig att skapa en privat datainsamling. Här kan du definiera en delmängd av företag som kan se privata data utan att skapa en ny kanal för varje fall.

 

Vad är privat datainsamling?

I grund och botten är en samling en kombination av två olika element –

Den faktiska informationen som sänds mellan kamrater med hjälp av skvallerprotokollet. Men här är det bara företaget som har tillstånd att se det som kan se detta. I grund och botten är dessa data i en privat statlig databas inom huvudböckerna för kamraterna i den organisationen.

Mer, det finns inga beställningstjänster här och de kan inte se den privata informationen. Hur som helst, eftersom skvallerprotokollen sänder informationen från en kollega till en annan, måste du ställa in ankarnoder i kanalen.

Den innehåller också en hash av den privata informationen som beställs, godkänns och skrivs på huvudboken för alla kamrater i kanalen. I grund och botten fungerar det som bevis för validering av en transaktion på kanalen. Du kan också använda den för granskningsändamål.

 

Använda en samling

Inom en kanal

Du måste använda kanaler om du vill hålla en hel transaktion hemlig från en grupp organisationer inom kanalen.

Separat kanal

Enligt Hyperledger Fabric 2.0-dokumentationen kan du använda samlingar när du bara behöver hålla en del av huvudboken hemlig från en uppsättning företag.

I verkligheten kommer vissa organisationer att ha full tillgång till huvudboken, och andra kanske bara ser vad de får. Om du också vill hålla transaktionsdata dolda från beställningstjänsterna kan du använda privata datainsamlingar för konfidentialitet.

 

Ett exempel

Låt oss ta en titt på dokument från Hyperledger Fabric 2.0 för att förstå situationen bättre.

Låt oss säga, i en handelsplattform finns det fem företag i en kanal.

  • Bonden som säljer varor
  • Distributör som flyttar varorna
  • Avsändare som flyttar varor mellan två parter
  • Grossist som köper varor från distributören
  • Återförsäljare som köper varorna från grossisterna och avsändarna

I grund och botten kan distributören ladda annorlunda i alla fall. Så kanske han vill hålla transaktioner med avsändaren och Farmer privata eftersom han kan ha andra erbjudanden med återförsäljaren och grossisten.

Dessutom debiterar distributören mindre till en grossist än till en återförsäljare. Således kanske han vill hålla det hemligt från återförsäljaren.

Grossisten kan å andra sidan också ha privata relationer med avsändaren och återförsäljaren. Men om du vill skapa en separat kanal för varje privat information, skulle systemet bli mycket mer komplicerat.

Istället för att göra det kan du ha olika privata datainsamlingar eller PDC för var och en av medlemmarna.

Till exempel,

Privat-data-insamling-1: Avsändare, jordbrukare och distributör

Privat-data-insamling-2: Avsändare, återförsäljare och grossist

Privat-data-insamling-3: Grossist och distributör

Enligt Hyperledger Fabric 2.0-dokumentation kommer alla distributörspartners att ha privata databaser som innehåller privata data för relation mellan avsändare, jordbrukare och distributörer samt grossist- och distributörsrelationer.

 

Förbättringar i datamönster

Enligt dokumentationen för Hyperledger Fabric 2.0 finns det några förbättringar som faktiskt gör det möjligt för de nya privata datamönstren att fungera. Dessa är –

Dela och verifiera privata data

Mottagande parter kan använda GetPrivateDataHash () API för att verifiera om de privata data som delas med dem är giltiga eller inte i två scenarier –

  • När du delar privat information med en kanalanvändare som inte är medlem i en samling.
  • När du delar den med en annan samling som kommer med en eller flera medlemmar.

 

Insamlingspolicyer på samlingsnivå

Du kan nu definiera privata datainsamlingar med hjälp av en godkännandepolicy som kan åsidosätta andra kedjekodspolicyer för nycklar i samlingen. I grund och botten kan du använda den för att begränsa andra företag att skriva på samlingen och vad som kan möjliggöra kedjekods livscykel och applikationsmönster.

Tja, till exempel kan du behöva godkännande där om majoritetsföretag håller med, kan du starta transaktionen, men i vissa fall kan du behöva avtalet från en specifik organisation för att få det att fungera.

 

Implicita samlingar per organisation

Enligt Hyperledger Fabric 2.0-dokumentation, om du vill använda ett privat datamönster per organisation, kan du i vilket fall som helst distribuera kedjekod utan att definiera samlingen i den nya versionen. Det är en av de viktigaste Hyperledger Fabric 2.0-funktionerna.

 

Extern kedjelansering

De extern kedjekodstart är en av de fantastiska Hyperledger Fabric 2.0-funktionerna. Huvudsakligen kommer det att ge operatörerna möjlighet eftersom de nu kan välja att starta kedjekoden för deras val av teknik. Mer behöver du inte använda en extern launcher eller byggare för det, och det kommer att köra kedjekoden med Docker API.

I grund och botten behöver kamraterna nu inte komma åt en Docker-demon för att köra eller bygga kedjekoden. I en produktionsmiljö är det absolut inte önskvärt, och det är därför kamrater kan eliminera beroendet av Docker-demon.

Nu behöver du inte köra en kedjekod i en Docker-container, du kan stämma ditt eget val av miljö för att köra kedjekoden.

Dessutom kan operatörerna erbjuda externa byggkörbara filer för att åsidosätta hur användarna startar eller bygger kedjekod.

Tidigare lanserade kamrater en kedjekod och sedan kopplades den tillbaka till dem. Men nu kan du köra den som extern tjänst.

 

Förbättrad prestanda på CouchDB

Tidigare, när du skulle använda CouchDB-tillståndsdatabasen, skulle du möta läsförseningar i validering och godkännande. Så det var svårt att få prestanda så smidig som möjligt. Men nu, med Hyperledger Fabric 2.0-funktioner, får du en ny peer-cache som kommer att ersätta långa sökningar med snabba utdata. Mer så kan du konfigurera dem med core.yaml-egenskapen cacheSize.

 

Alpinbaserade Docker-bilder

I den nya Hyperledger Fabric 2.0 kommer den att använda Alpine Linux för Docker-bilderna. Alpine Linux är en säkrare och lättare Linux-distribution som enkelt kan öka nätverkets prestanda.

I verkligheten betyder det att Docker-bilder kommer att vara mindre i storlek, så det tar mindre tid att ladda ner eller för start. Mer än så tar det inte för mycket utrymme från och med nu.

Företaget designade Alpine Linux från grunden, med tanke på säkerheten, och den minimalistiska funktionen i denna distribution blir av med alla sårbarheter.

 

Exempel på testnätverk

Nu har du ett nytt provtestnätverk i förvaret för tygprover. Det är en av de coola Hyperledger Fabric 2.0-funktionerna. I verkligheten är detta testnätverk modulärt och enkelt att använda. Så du har inga problem med att testa dina smarta kontrakt eller applikationer innan du lanserar lösningen.

Dessutom kan du också distribuera nätverket med certifikatutfärdare tillsammans med cryptogen.

 

Hur man uppgraderar till Fabric v2.0

Varje gång en större version inträffar ger det massor av problem med uppgraderingsöverväganden. I många fall kan du behöva installera den nya versionen från grunden, men det kan ha driftstopp. Men en av Hyperledger Fabric 2.0-funktionerna är att om du redan är på version 1.4 kan du direkt uppgradera till version 2.0 utan driftstopp.

De har också omarbetat och utökat uppgraderingsdokumenten så att du kan checka ut och har också ett fristående hem i sitt dokumentationer. Vill du uppgradera? Kolla sedan in deras dokumentation på det.

I grund och botten är uppgradering till den senaste utgåvan en process i fyra steg –

  • Först måste du säkerhetskopiera dina huvudböcker och MSP.
  • Börja sedan uppgradera på rullande sätt beställarens binärer till den senaste versionen.
  • Därefter följer du samma uppdateringsprocess för peer-binärer.
  • Slutligen måste du uppdatera applikationskanalerna och beställarsystemkanalen till deras senaste funktioner när de är tillgängliga. Mer så kommer inte alla utgåvor att öka kapaciteterna, ibland har de stora förbättringar någon gång de inte har.

 

Uppgradera självstudier

Innan du uppgraderar några processer bör du överväga att kolla in deras handledning för det. Du kan också ta en titt på vår tyghandledning. Hur som helst, vi ger en kort version av det här –

  • Innan du uppgraderar dina funktioner bör du först uppgradera alla dina komponenter. Se till att de är den senaste versionen.
  • Se också till att uppdatera alla noder till den senaste versionen innan du uppdaterar hela kanalen.
  • Du måste lägga till godkännandepolicyer för ett specifikt företag för att starta en ny kedjekods livscykel i systemet.

Tyget betraktar nu uppgradering av noder och ökad kapacitet som en standard.

Notera: Vi rekommenderar att du också uppgraderar din SDK till den senaste versionen. Även om din SDK borde kunna hantera motsvarande versioner av Hyperledger Fabric och lägre version, skulle det vara bäst att uppdatera det för då kan du använda de senaste Fabric-funktionerna effektivt.

Om du fortfarande är förvirrad över uppgraderingsprocessen, kolla in deras dokumentation om den.

 

Slutsats

Den senaste versionen av version 2.0 är en milstolpe i historien. I själva verket anses Fabric 2.0 vara nästa generations blockchain-teknik. Mer, det finns så många Hyperledger Fabric 2.0-funktioner som erbjuder många möjligheter.

Från och med nu vet vi fortfarande inte hur denna teknik kommer att fungera eller om den nya versionen äntligen kan bli av med de negativa aspekterna av blockchain. Ändå gav den nya milstolpen för Hyperledger-familjen och samhället massor av nya förbättringar, och vi kan bara hoppas på det bästa.

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