Skala konsensus för företag: Förklara IBFT-algoritmen

blogg 1NyheterUtvecklareFöretagBlockchain förklaradeHändelser och konferenserPressNyhetsbrev

Prenumerera på vårt nyhetsbrev.

E-postadress

Vi respekterar din integritet

HomeBlogEnterprise Blockchain

Skala konsensus för företag: Förklara IBFT-algoritmen

Hur Istanbul Byzantine Fault Tolerance (IBFT) förbättrar slutgiltigheten och ökar genomströmningen i privata Ethereum-nätverk. Av ConsenSys 22 juni 2018 Publicerad 22 juni 2018

Ethereum-hjälten ConsenSys

Konsensusalgoritmer är en av kärninnovationerna inom blockchain och ändå en av de mest förvirrande. Satoshi Nakamoto skapade en version av Proof of Work (PoW) som implementerades som ett medel för att samtidigt säkra och validera Bitcoin-transaktioner. Blockchain-communityn har byggt på den kärnvisionen att skapa en alfabetssoppa av Proof of Stake (PoS), Proof of Authority (PoA), PBFT (Practical Byzantine Fault Tolerant) och många andra som alla är utformade för att bygga konsensus i en distribuerad skapar den enda sanningskällan som gör blockchain så värdefullt.

IBFT (Istanbul Byzantine Fault Tolerant) är en konsensusmekanism som är ett alternativ till bevis på arbete i ett Ethereum-nätverk. Liksom andra algoritmer säkerställer IBFT en enda överenskommen beställning för transaktioner i blockchain och ger ytterligare fördelar för företag, inklusive slutlig avveckling. IBFT var först implementerad i Geth av Amis Technologies, och snart implementerad i kvorum.

Innan man börjar använda IBFT-konsensusmekanismen är det värt att nämna när och varför man skulle vilja använda IBFT. I en offentlig blockchain är det korta svaret troligt att du förmodligen inte skulle göra det. Men när det gäller konsortier eller privata blockchains börjar IBFT se ganska tilltalande ut.

PoW-algoritmen är berömt dyr, både hårdvara och el. Denna kostnad är avsiktlig för att förhindra att någon enkelt tar över nätverket, och därför är PoW mycket lämplig för situationer med full decentralisering där alla (inklusive angripare) kan delta. Noder i konsortiet / privata kedjor som används av företag är emellertid i själva verket mer betrodda än de i en offentlig kedja. Som sådan kan PoW-konsensusmekanismen vara alltför betungande, och andra mekanismer kan ge “tillräckligt” förtroende för att driva ett distribuerat system.

Bevis på stav kan också vara mindre relevant för företag, eftersom det är mindre viktigt att betala för gas i ett tillåtet nätverk. Eftersom noder inte (nödvändigtvis) behöver behålla valuta i nätverket skulle PoS införa främmande krav.

Med tanke på dessa avvägningar framträder Proof of Authority (PoA) som en möjlig bästa lösning genom att använda ett system där noder i nätverket tilldelas privilegiet att producera nya block för kedjan med hjälp av en rund-robin eller annat godtyckligt system.

IBFT är en av de många smakerna av PoA och ger följande fördelar:

  • Omedelbar blockfinalitet. Det finns bara ett block som föreslås vid en given kedjhöjd. Den enda kedjan tar därmed bort gafflar, farbrorblock och risken för att en transaktion kan “ångras” en gång i kedjan vid ett senare tillfälle.
  • Minskad tid mellan block. Ansträngningarna som behövs för att konstruera och validera block minskas avsevärt (särskilt med avseende på PoW), vilket kraftigt ökar kedjans genomströmning.
  • Hög dataintegritet och feltolerans. IBFT använder en grupp validerare för att säkerställa integriteten för varje block som föreslås. En supermajoritet (~ 66%) av dessa validerare måste underteckna blocket innan det sätts in i kedjan, vilket gör blockförfalskning mycket svårt. Gruppens “ledarskap” roterar också över tiden – så att en felaktig nod inte kan utöva långvarigt inflytande över kedjan.
  • Operativt flexibel. Gruppen validerare kan modifieras i tid, vilket säkerställer att gruppen endast innehåller helt betrodda noder.

Här gav vi en översikt över IBFT, i huvudsak icke-tekniska termer. För några av de ursprungliga förslagen från IBFT kan du granska EIP: erna på GitHub:

För resten av denna artikel kommer vi att utforska IBFTs mer tekniska överväganden, diskutera många av de begrepp som finns i EIP: erna och som vi har lärt oss genom vår egen forskning..

Obs! IBFT-kod finns också i en begäran om go-ethereum pull # 16385.

Drift

IBFT-konsensusmekanismen består av följande komponenter:

  1. A PBFT inspirerad gruppkonsensusmodell.
  2. En process genom vilken medlemmar kan läggas till / tas bort från valideringsgruppen.

IBFT kräver att Block Header (subtilt) omarbetas för att stödja alla aspekter av kapaciteten.

Group Consensus Model

Översikt

IBFT använder en pool av valideringsnoder (Validatorer) som arbetar på ett Ethereum-nätverk för att avgöra om ett föreslaget block är lämpligt för tillägg till kedjan.

En nod i validerarna väljs godtyckligt som förslagsställaren och är ansvarig för att konstruera ett block vid blockintervallet och dela nämnda block med gruppen. Om en majoritet av validerarna anser att blocket är giltigt läggs det till blockchain.

Vid slutförandet av konsensusrundan kan validerarna välja en ny förslagsställare som kommer att ansvara för att tillhandahålla kandidatblocket vid nästa blockintervall.

Konsensusmekanismen är en synkroniserad tillståndsmaskin som ansvarar för att alla validerare lägger till samma block i kedjan i samma höjd.

Om ett block inte infogas ändras förslagsställaren och processen börjar på nytt.

För att säkerställa att endast ett block kan läggas till tillståndsmaskinen, förhindrar IBFT att ändra det föreslagna blocket när en överväldig majoritet av validerarna har gått med på att det införs (men inte utfört nämnda arbete), denna process kallas “Block Locking”.

IBFT-konsensusmekanismen erbjuder systemstabilitet förutsatt att mindre än 1/3 av valideringsnoderna beter sig felaktigt (antingen på grund av att de äventyras eller på grund av felaktig kod). Dvs för att tolerera F felaktiga noder måste valideringsgruppen innehålla minst 3F + 1 noder (mer än detta ökar inte systemintegriteten).

Anmärkning: F innebär här att antalet felaktiga noder som tolereras av systemet.

Statsmaskin

IBFT State Machine

stater
  • Väntar på förslag. Validator väntar på att ett nytt block ska levereras av den nuvarande förslagsställaren. Om valideraren är den som föreslår denna runda förbereder de det föreslagna blocket och överför det i ett förberedande meddelande.
  • Förbereder. Har fått ett (giltigt) föreslaget block och meddelat validerings-kollegor; väntar nu på att validerings-kollegor ska meddela att de accepterar blocket.
  • Redo. Har fått validator-peer godkännande av block och väntar på att de ska vara i en liknande position. I det här skedet har det föreslagna blocket varit “låst in” och kan inte ersättas förrän ett försök till införande har genomförts.
  • Round Change. Omgången gick ut innan konsensus nåddes eller blocket misslyckades med att infoga. Vänta tills alla validerare kommer överens om nästa omgångsnummer.
Övergångar
  1. Aväntar Förslag → Förbereder. Vid mottagning av ett nytt block (Förbered meddelande) från förslagsställaren (dvs. blocket är giltigt i sitt innehåll, liksom dess föreslagna kedjeinsättningspunkt).
  2. Väntar på förslag → Round Change. Det mottagna förslaget var inte ett giltigt block enligt en viss uppsättning regler (t.ex. ogiltig förslag, felaktig numrering).
  3. Förbereder → Klar. Vid mottagning av 2F + 1-meddelanden (Förbered meddelande) från validerings-kollegor som indikerar att det föreslagna blocket är lämpligt för insättning.
  4. Klar → Väntar på förslag. Vid mottagning av 2F + 1-meddelanden (Commit-meddelande) från validerings-kollegor som anger att de är redo att lägga till blocket i kedjan. Vid övergången utförs processen att fästa blocket i kedjan (framgång).
  5. Klar → Rundbyte. Enligt Ready->I väntan på förslag misslyckades dock införandet av blockering.
  6. Round Change → Väntar på förslag. 2F + 1 av validerarna är överens om nästa omgångsnummer som ska användas.

Obs: Alla övergångar till “RoundChange” resulterar i att Validator skickar ett “RoundChange” -meddelande till sina validerings-kollegor.

Blockera låsning

IBFT föreskriver att gafflar inte ska skapas. För detta ändamål, när ett block har överenskommits av majoriteten (dvs. vid inträde till Ready-tillståndet) blir det “låst”.

Detta innebär att inga andra block kommer att övervägas för införande förrän ett försök att lägga till detta block i kedjan har försökt. Således införs blocket framgångsrikt (när tillräckligt många meddelanden mottagits, antingen i denna eller efterföljande omgångar), eller blocket misslyckas införandet, kasseras och ett nytt block föreslås i den aktuella kedjhöjden.

Valideringsgruppsmedlemskap

Medlemmarna i valideringsgruppen kan förändras över tid genom en omröstningsmekanism. Medlemmar kan läggas till eller tas bort genom en majoritetsröst (våning (N / 2) + 1); varje röst fångas i blockrubriken.

Varje nod i nätverket (inklusive icke-validerande noder) är ansvarig för att spåra omröstningen för varje validerare för att bestämma de aktuella validerarna och se till att signaturer på brytade block faller inom den förväntade gruppen..

Med tanke på att varje röst finns i blockrubriken är det bara förslagsställaren för en given runda som kan rösta. Det är därför viktigt, om noder ska läggas till / tas bort i tid, att förslagsrollen uppdateras regelbundet.

När en nod når majoritetsröster går de / lämnar omedelbart valideringsgruppen.

IBFT erkänner en röstningsperiod, som definierar en punkt där alla röster som ännu inte har nått majoritet tas bort, vilket tvingar omröstningen att startas om. Detta innebär att validerare bara måste börja vid den senaste epoken när man röstar om röster. Som standard sker röstningsepoken var 30 000 kvarter.

Omröstningar definierar en tillståndsförändring (dvs. kandidater röstas in, validerare röstas ut), inte röstar för en viss nod innebär att Validator inte vill att noden ska ändra tillstånd (en uttrycklig omröstning krävs inte för att bibehålla status quo).

Blockera rubrikrefaktor

För att stödja IBFT i Ethereum måste ett antal ändringar göras i blockrubrikerna. Dessa förändringar inkluderar:

  • mottagare: identifierar den nod för vilken en röst avges.
  • nonce: anger röstriktningen – AUTH eller DROP.
  • mixHash: fast magiskt nummer, vilket identifierar att detta block är IBFT-validerat.
  • ommersHash: måste vara hash för en tom uppsättning, eftersom det inte finns några ommerblock när du arbetar under IBFT.
  • tidsstämpel: måste vara minst moderblockets tidsstämpel + blockintervall.
  • svårighet: måste fyllas med 0x0000000000000001.
  • extraData: innehåller IBFT-specifika data inklusive lista över valideringsadresser, ProposerSeal (identifierar förslagsställaren), CommittingSeals (lista över validerare som rapporterade ‘commit’ i detta block).

Eftersom listan över CommittingSeals för varje validerare är (potentiellt) annorlunda är det viktigt att block-hash inte innehåller denna information – dvs. även om två block har olika CommittingSeals-fält, representerar de samma information (dvs. transaktioner etc. är identiska).

Slutsats

Avslutningsvis är IBFT en bysantinsk feletolerant lösning som erbjuder omedelbar transaktionsslutlighet som minskar den nödvändiga infrastrukturen som PoW kräver.

Det är osannolikt att det någonsin kommer att användas på Ethereum mainnet (med den mycket bredare, okända uppsättningen deltagande aktörer), men det ger betydande fördelar när det används i en privat kedja där valideringspoolen är betrodd och hålls ansvarig; det ger en idealisk lösning för en kedja med en fast kadens och en förutsägbar transaktionshastighet.

Processerna som undersöks i den här artikeln ger förtroende för att ett nätverk som använder IBFT kommer att vara tolerant mot bysantinska noder och kan återställas om dessa noder skulle ses utöva kontroll över nätverket.

Prenumerera på vårt nyhetsbrev för de senaste Ethereum-nyheterna, företagslösningar, utvecklarresurser med mera. E-postadress Exklusivt innehållKomplett guide till blockchain-affärsnätverkGuide

Komplett guide till blockchain-affärsnätverk

Introduktion till tokeniseringWebinar

Introduktion till tokenisering

Framtiden för finansiella digitala tillgångar och DeFiWebinar

Framtiden för ekonomi: digitala tillgångar och deFi

Vad är Enterprise EthereumWebinar

Vad är Enterprise Ethereum?

Centralbanker och pengarnas framtidVitt papper

Centralbanker och pengarnas framtid

Komgo Blockchain för handelsfinansiering av råvarorCase Stud

Komgo: Blockchain för handelsfinansiering av råvaror

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