Skalering av konsensus for bedrifter: Forklaring av IBFT-algoritmen

blogg 1NyheterUtviklereEnterpriseBlockchain ExplainedBegivenheter og konferanserPresseNyhetsbrev

Abonner på vårt nyhetsbrev.

Epostadresse

Vi respekterer personvernet ditt

HomeBlogEnterprise Blockchain

Skalering av konsensus for bedrifter: Forklaring av IBFT-algoritmen

Hvordan Istanbul Byzantine Fault Tolerance (IBFT) forbedrer finaliteten og øker gjennomstrømningen i private Ethereum-nettverk. Av ConsenSys 22. juni 2018 Publisert 22. juni 2018

Ethereum-helten ConsenSys

Konsensusalgoritmer er en av kjerneinnovasjonene til blockchain, og likevel en av de mest forvirrende. Satoshi Nakamoto opprettet en versjon av Proof of Work (PoW) som ble implementert som et middel for samtidig å sikre og validere Bitcoin-transaksjoner. Blockchain-samfunnet har bygget på den kjernevisjonen om å lage en alfabetssuppe av Proof of Stake (PoS), Proof of Authority (PoA), PBFT (Practical Byzantine Fault Tolerant), og mange andre som alle er designet for å bygge konsensus i en distribuert systemet, og skaper den eneste sannhetskilden som gjør blockchain så verdifull.

IBFT (Istanbul Byzantine Fault Tolerant) er en konsensusmekanisme som er et alternativ til bevis på arbeid i et Ethereum-nettverk. Som andre algoritmer, sørger IBFT for en enkelt, avtalt bestilling for transaksjoner i blockchain, og gir ekstra fordeler for bedrifter, inkludert endelig avregning. IBFT var først implementert i Geth av Amis Technologies, og kort tid etter implementert i kvorumet.

Før du går i gang med IBFT-konsensusmekanismen, er det verdt å nevne når og hvorfor man vil bruke IBFT. I en offentlig blockchain er det korte svaret sannsynlig at du sannsynligvis ikke ville gjort det. Men når det gjelder konsortium eller private blockchains, begynner IBFT å se ganske tiltalende ut.

PoW-algoritmen er kjent som kostbar, både i maskinvare og strøm. Denne kostnaden er forsettlig, for å forhindre at noen enkelt tar over nettverket, og dermed er PoW veldig egnet for situasjoner med full desentralisering der alle (inkludert angripere) kan delta. Noder i konsortiet / private kjeder som brukes av bedrifter, er imidlertid iboende mer pålitelige enn de i en offentlig kjede. Som sådan kan PoW-konsensusmekanismen være for belastende, og andre mekanismer kan gi “nok” tillit til å kjøre et distribuert system.

Bevis for innsats kan også være mindre relevant for bedrifter, fordi det å betale for gass er mindre viktig i et tillatt nettverk. Siden noder ikke (nødvendigvis) trenger å opprettholde valuta i nettverket, vil PoS innføre fremmede krav.

Tatt i betraktning disse kompromissene, viser Proof of Authority (PoA) seg som en mulig best løsning, ved å bruke et system der noder i nettverket tildeles privilegiet å produsere nye blokker for kjeden ved hjelp av en round-robin eller et annet vilkårlig system.

IBFT er en av de mange smaker av PoA og gir følgende fordeler:

  • Umiddelbar blokkfinalitet. Det er bare en blokk foreslått i en gitt kjedehøyde. Den enkle kjeden fjerner dermed gafler, onkelblokker, og risikoen for at en transaksjon kan “angres” en gang i kjeden på et senere tidspunkt.
  • Redusert tid mellom blokker. Innsatsen som trengs for å konstruere og validere blokker er betydelig redusert (spesielt med hensyn til PoW), og øker kjedens gjennomstrømning betydelig.
  • Høy dataintegritet og feiltoleranse. IBFT bruker en gruppe validatorer for å sikre integriteten til hver blokk som foreslås. Et stort flertall (~ 66%) av disse validatorene er pålagt å signere blokken før innsetting i kjeden, noe som gjør forfalskning av blokker veldig vanskelig. Gruppens ‘ledelse’ roterer også over tid – for å sikre at en defekt node ikke kan utøve langsiktig innflytelse over kjeden.
  • Operasjonelt fleksibel. Gruppen av validatorer kan endres i tide, og sikre at gruppen bare inneholder fullverdige noder.

Her ga vi en oversikt over IBFT, i det meste ikke-tekniske termer. For noen av de opprinnelige forslagene fra IBFT kan du se gjennom EIP-ene på GitHub:

For resten av denne artikkelen vil vi utforske IBFTs mer tekniske betraktninger, diskutere mange av konseptene som finnes i EIP-ene, og som vi har lært gjennom vår egen forskning..


Merk: IBFT-kode kan også bli funnet i en go-ethereum pull-forespørsel # 16385.

Operasjon

IBFT-konsensusmekanismen består av følgende komponenter:

  1. EN PBFT inspirert gruppekonsensusmodell.
  2. En prosess der medlemmer kan legges til / fjernes fra valideringsgruppen.

IBFT krever at Block Header (subtly) omarbeides for å støtte alle fasetter av evnen.

Group Consensus Model

Oversikt

IBFT bruker en pool med valideringsnoder (Validators) som opererer på et Ethereum-nettverk for å avgjøre om en foreslått blokk er egnet for tillegg til kjeden.

En node av validatorene velges vilkårlig som forslagsstilleren og er ansvarlig for å konstruere en blokk ved blokkintervallet og dele nevnte blokk med gruppen. Hvis et stort flertall av validatorene anser blokken som gyldig, blir den lagt til blockchain.

Når konsensusrunden er fullført, kan validatorene velge en ny forslagsstiller som vil være ansvarlig for å gi kandidatblokken ved neste blokkeringsintervall..

Konsensusmekanismen er en synkronisert tilstandsmaskin som er ansvarlig for at alle validatorer legger den samme blokken til kjeden i samme høyde.

Hvis en blokk ikke kan settes inn, endres forslagsstiller, og prosessen starter på nytt.

For å sikre at bare en blokk kan legges til statsmaskinen, forhindrer IBFT å endre den foreslåtte blokken når et stort flertall av validatorer har blitt enige om at den settes inn (men ikke utførte nevnte arbeid), denne prosessen blir referert til som ‘Block Locking’.

IBFT-konsensusmekanismen tilbyr systemstabilitet forutsatt at mindre enn 1/3 av valideringsnodene oppfører seg feil (enten på grunn av kompromittering eller på grunn av feil kode). Dvs. for å tolerere F defekte noder må valideringsgruppen inneholde minst 3F + 1 noder (mer enn dette øker ikke systemintegriteten).

Merk: Her innebærer F antall defekte noder som systemet tolererer.

State Machine

IBFT State Machine

Stater
  • Venter på forslag. Validator venter på at en ny blokk skal leveres av den nåværende forslagsstilleren. Hvis validatoren er forslagsstiller for denne runden, forbereder de den foreslåtte blokken og overfører den i en forhåndsforberedende melding.
  • Forbereder. Har mottatt en (gyldig) foreslått blokk og varslet validator-kollegaer; venter nå på at validator-kollegaer skal varsle at de aksepterer blokken.
  • Klar. Har mottatt validator-kollegas aksept av blokkering, og venter på at de skal være i en lignende stilling. På dette stadiet har den foreslåtte blokken blitt ‘låst’, og kan ikke erstattes før et forsøk på innsetting er utført.
  • Round Change. Runden ble tidsavbrutt før konsensus ble nådd eller blokken ikke klarte å sette inn. Vent til alle validatorer er enige om neste rundenummer.
Overganger
  1. ENventer Forslag → Forbereder. Ved mottak av en ny blokk (Forbered klar melding) fra forslagsstiller (dvs. blokken er gyldig i innholdet, som det foreslåtte kjedeinnsettelsespunktet).
  2. Venter på forslag → Rund endring. Det mottatte forslaget var ikke en gyldig blokk i henhold til et gitt sett med regler (f.eks. Ugyldig forslagsstiller, feil rundnummerering).
  3. Forberedelse → Klar. Ved mottak av 2F + 1-varsler (Forbered melding) fra validator-peers som indikerer at den foreslåtte blokken er egnet for innsetting.
  4. Klar → Venter på forslag. Ved mottak av 2F + 1-varsler (Commit-melding) fra validator-peers som indikerer at de er klare til å legge blokken til kjeden. Ved overgang utføres prosessen med å feste blokken til kjeden (suksess).
  5. Klar → Rundskifte. I henhold til Ready->Venter på forslag mislyktes imidlertid innsetting av blokkering.
  6. Rund endring → Venter på forslag. 2F + 1 av validatorer blir enige om neste rundenummer som skal brukes.

Merk: Alle overganger til “RoundChange” resulterer i at Validator sender en “RoundChange” -melding til validator-kollegene.

Blokker låsing

IBFT pålegger at gafler ikke skal opprettes. For å oppnå dette, når en blokk er blitt enige om av et flertall (dvs. ved innreise til Klar-tilstand) blir den “låst”.

Dette betyr at ingen andre blokker vil bli vurdert for innsetting før det er forsøkt å forsøke å legge denne blokken til kjeden. Dermed blir enten blokken satt inn vellykket (når tilstrekkelige kommisjonsmeldinger er mottatt, enten i denne eller påfølgende runder), eller blokken mislykkes i innsetting, blir kastet, og en ny blokk foreslås i gjeldende kjedehøyde.

Valideringsgruppemedlemskap

Medlemmene av valideringsgruppen kan endre seg over tid gjennom en stemmemekanisme. Medlemmer kan legges til eller fjernes ved flertall (etasje (N / 2) + 1). hver stemme fanges opp i blokkoverskriften.

Hver node i nettverket (inkludert ikke-validerende noder) er ansvarlig for å spore stemmetallet for hver validator for å bestemme gjeldende validatorer og sikre at signaturer på utvinnede blokker faller innenfor den forventede gruppen.

Gitt at hver stemme er inneholdt i blokkoverskriften, er det bare forslagsstiller for en gitt runde som er i stand til å avgi stemme. Derfor er det viktig, hvis noder skal legges til / fjernes i tide, at forslagsstillerrollen oppdateres regelmessig.

Når en node når flertallsstemmer, blir de umiddelbart med i / forlater valideringsgruppen.

IBFT anerkjenner en Stemningsepoke, som definerer et punkt der alle stemmer som ennå ikke har nådd flertall fjernes, og tvinger stemmetallet til å starte på nytt. Dette innebærer at når validering av stemmer stemmer Valider bare å starte i den siste epoken. Som standard skjer Stemningsepoken hver 30.000 blokker.

Stemmer definerer en statskifte (dvs. kandidater blir stemt inn, validatorer blir stemt ut), ikke å stemme på en gitt node innebærer at Validator ikke ønsker at noden skal endre tilstand (en eksplisitt stemme er ikke nødvendig for å opprettholde status quo).

Blokker Header Refactor

For å støtte IBFT i Ethereum må det gjøres en rekke endringer i blokkoverskriftene. Disse endringene inkluderer:

  • mottaker: identifiserer noden som en stemme avgis for.
  • nonce: spesifiserer “retning” – AUTH eller DROP.
  • mixHash: magisk nummer, som identifiserer denne blokken som IBFT-validert.
  • ommersHash: må være hash for et tomt sett, da det ikke er noen ommerblokker når du opererer under IBFT.
  • tidsstempel: må være minst foreldreblokkens tidsstempel + blokkintervall.
  • vanskelighetsgrad: må fylles med 0x0000000000000001.
  • extraData: inneholder IBFT-spesifikke data inkludert liste over validatoradresser, ProposerSeal (identifiserer forslagsstiller), CommittingSeals (liste over validatorer som rapporterte ‘commit’ i denne blokken).

Siden listen over CommittingSeals for hver validator er (potensielt) forskjellig, er det viktig at blokkeringshash ikke inkluderer denne informasjonen – dvs. selv om to blokker har forskjellige CommittingSeals-felt, representerer de den samme informasjonen (dvs. transaksjoner etc. er identiske).

Konklusjon

Avslutningsvis er IBFT en bysantinsk feiltolerant løsning som tilbyr umiddelbar transaksjonsfinalitet som reduserer den nødvendige infrastrukturen som PoW krever.

Selv om det usannsynlig noen gang blir brukt på Ethereum mainnet (med det mye bredere, ukjente settet av deltakende aktører), gir det betydelige fordeler når det brukes i en privat kjede der validatorpoolen er klarert og holdes ansvarlig; det gir en ideell løsning for en kjede med fast kadens og en forutsigbar prosesseringshastighet.

Prosessene som er utforsket i denne artikkelen gir tillit til at et nettverk som bruker IBFT vil være tolerant overfor bysantinske noder og kan gjenopprettes hvis disse nodene blir sett på å utøve kontroll over nettverket..

Abonner på vårt nyhetsbrev for de siste Ethereum-nyhetene, bedriftsløsninger, utviklerressurser og mer. E-postadresse Eksklusivt innholdKomplett guide til Blockchain Business NetworksGuide

Komplett guide til Blockchain Business Networks

Introduksjon til tokeniseringWebinar

Introduksjon til tokenisering

Fremtiden for digitale eiendeler og deFiWebinar

Fremtidens økonomi: digitale eiendeler og deFi

Hva er Enterprise EthereumWebinar

Hva er Enterprise Ethereum?

Sentralbanker og pengens fremtidHvitt papir

Sentralbanker og pengens fremtid

Komgo Blockchain for handelsvareøkonomiCase Stud

Komgo: Blockchain for handelsvareøkonomi

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