Consensus schalen voor ondernemingen: uitleg van het IBFT-algoritme

blog 1NieuwsOntwikkelaarsEnterpriseBlockchain ExplainedEvenementen en conferentiesPersNieuwsbrieven

Abonneer op onze nieuwsbrief.

E-mailadres

Wij respecteren uw privacy

HomeBlogEnterprise Blockchain

Consensus schalen voor ondernemingen: uitleg van het IBFT-algoritme

Hoe Istanbul Byzantine Fault Tolerance (IBFT) de finaliteit verbetert en de doorvoer verhoogt in private Ethereum-netwerken. By ConsenSys 22 juni 2018 Geplaatst op 22 juni 2018

Ethereum-held ConsenSys

Consensusalgoritmen zijn een van de belangrijkste innovaties van blockchain, en toch ook een van de meest verwarrende. Satoshi Nakamoto heeft een versie van Proof of Work (PoW) gemaakt die werd geïmplementeerd als een middel voor het gelijktijdig beveiligen en valideren van Bitcoin-transacties. De blockchain-gemeenschap heeft voortgebouwd op die kernvisie om een ​​alfabetsoep te creëren van Proof of Stake (PoS), Proof of Authority (PoA), PBFT (Practical Byzantine Fault Tolerant) en vele anderen die allemaal zijn ontworpen om consensus op te bouwen in een gedistribueerde systeem, waardoor de enige bron van waarheid wordt gecreëerd die blockchain zo waardevol maakt.

IBFT (Istanbul Byzantine Fault Tolerant) is een consensusmechanisme dat een alternatief is voor Proof of Work in een Ethereum-netwerk. Net als andere algoritmen zorgt IBFT voor een enkele, overeengekomen bestelling voor transacties in de blockchain en biedt het extra voordelen voor ondernemingen, waaronder de finaliteit van de afwikkeling. IBFT was voor het eerst geïmplementeerd in Geth door Amis Technologies, en kort daarna geïmplementeerd in Quorum.

Voordat we met de werking van het IBFT-consensusmechanisme beginnen, is het de moeite waard om te vermelden wanneer en waarom men IBFT zou willen gebruiken. In een openbare blockchain is het korte antwoord waarschijnlijk dat u dat waarschijnlijk niet zou doen. Maar als het gaat om consortium- of privé-blockchains, begint IBFT er behoorlijk aantrekkelijk uit te zien.

Het PoW-algoritme is beroemd duur, zowel qua hardware als qua elektriciteit. Deze kosten zijn opzettelijk om te voorkomen dat iemand gemakkelijk het netwerk overneemt, en daarom is PoW zeer geschikt voor situaties met volledige decentralisatie waar iedereen (inclusief aanvallers) kan deelnemen. Knooppunten in de consortium / private ketens die door ondernemingen worden gebruikt, zijn echter intrinsiek meer vertrouwd dan die in een publieke keten. Als zodanig kan het PoW-consensusmechanisme te omslachtig zijn, en kunnen andere mechanismen “genoeg” vertrouwen bieden om een ​​gedistribueerd systeem te laten draaien..

Proof of Stake is mogelijk ook minder relevant voor bedrijven, omdat betalen voor gas minder belangrijk is in een vergund netwerk. Omdat knooppunten niet (noodzakelijkerwijs) valuta in het netwerk hoeven te behouden, zou PoS externe vereisten introduceren.

Gezien deze afwegingen komt Proof of Authority (PoA) naar voren als een mogelijke beste oplossing, gebruikmakend van een systeem waarbij knooppunten in het netwerk het privilege krijgen om nieuwe blokken voor de keten te produceren met behulp van een round-robin of ander willekeurig systeem.

IBFT is een van de vele smaken van PoA en biedt de volgende voordelen:

  • Onmiddellijke finaliteit van het blok. Er wordt slechts 1 blok voorgesteld op een bepaalde kettinghoogte. De enkele ketting verwijdert dus forking, oom-blokkades en het risico dat een transactie op een later tijdstip eenmaal in de ketting kan worden “ongedaan gemaakt”..
  • Minder tijd tussen blokken. De inspanning die nodig is om blokken te construeren en valideren wordt aanzienlijk verminderd (in het bijzonder met betrekking tot PoW), waardoor de doorvoer van de keten aanzienlijk toeneemt.
  • Hoge gegevensintegriteit en fouttolerantie. IBFT gebruikt een groep validators om de integriteit van elk voorgesteld blok te waarborgen. Een overgrote meerderheid (~ 66%) van deze validators is vereist om het blok te ondertekenen voordat het in de ketting wordt ingebracht, wat het vervalsen van blokken erg moeilijk maakt. Het ‘leiderschap’ van de groep roteert ook in de loop van de tijd – zodat een defecte node geen invloed op de lange termijn op de keten kan uitoefenen.
  • Operationeel flexibel. De groep validators kan in de tijd worden gewijzigd, zodat de groep alleen volledig vertrouwde knooppunten bevat.

Hier hebben we een overzicht gegeven van IBFT, in veelal niet-technische termen. Voor enkele van de originele voorstellen van IBFT kun je de EIP’s op GitHub bekijken:

Voor de rest van dit artikel zullen we de meer technische overwegingen van IBFT onderzoeken en veel van de concepten uit de EIP’s bespreken en die we hebben geleerd door ons eigen onderzoek.


Opmerking: IBFT-code is ook te vinden in een go-ethereum pull request # 16385.

Operatie

Het IBFT-consensusmechanisme omvat de volgende componenten:

  1. EEN PBFT geïnspireerd groepsconsensusmodel.
  2. Een proces waarmee leden kunnen worden toegevoegd / verwijderd uit de validatiegroep.

IBFT vereist dat de Block Header (subtiel) wordt herwerkt om alle facetten van de mogelijkheid te ondersteunen.

Groepsconsensusmodel

Overzicht

IBFT gebruikt een pool van validerende knooppunten (validators) die op een Ethereum-netwerk werken om te bepalen of een voorgesteld blok geschikt is om aan de keten toe te voegen.

Een knooppunt van de validators wordt willekeurig geselecteerd als de indiener en is verantwoordelijk voor het construeren van een blok met het blokinterval en het delen van het blok met de groep. Als een overgrote meerderheid van de Validators het blok als geldig beschouwt, wordt het aan de blockchain toegevoegd.

Na voltooiing van de consensusronde kunnen de validatoren een nieuwe indiener selecteren die verantwoordelijk zal zijn voor het verstrekken van het kandidaatblok bij het volgende blokinterval.

Het consensusmechanisme is een gesynchroniseerde toestandsmachine die ervoor zorgt dat alle validators hetzelfde blok op dezelfde hoogte aan de ketting toevoegen.

Als een blok niet kan worden ingevoegd, wordt de indiener gewijzigd en begint het proces opnieuw.

Om ervoor te zorgen dat slechts één blok aan de toestandsmachine kan worden toegevoegd, voorkomt IBFT dat het voorgestelde blok wordt gewijzigd zodra een overgrote meerderheid van validators akkoord is gegaan met het invoegen ervan (maar het genoemde werk niet heeft uitgevoerd), dit proces wordt ‘Block Locking’ genoemd..

Het IBFT-consensusmechanisme biedt systeemstabiliteit op voorwaarde dat minder dan 1/3 van de validatieknooppunten zich niet correct gedraagt ​​(ofwel omdat ze gecompromitteerd zijn of vanwege een foutieve code). D.w.z. om F defecte knooppunten te tolereren, moet de validatiegroep ten minste 3F + 1 knooppunten bevatten (meer dan dit verhoogt de systeemintegriteit niet).

Opmerking: hierin geeft F het aantal defecte knooppunten weer dat door het systeem wordt getolereerd.

Staat Machine

IBFT State Machine

Staten
  • In afwachting van voorstel. Validator wacht op een nieuw blok dat wordt aangeleverd door de huidige aanbieder. Als de validator de indiener van deze ronde is, bereiden ze het voorgestelde blok voor en verzenden het in een voorbereidingsbericht.
  • voorbereidingen treffen. Heeft een (geldig) voorgesteld blok ontvangen en aangemelde validator-peers; wacht nu op validator-peers om hun acceptatie van de blokkering door te geven.
  • Klaar. Heeft de acceptatie van blokkering door validator-peer ontvangen en wacht tot ze zich in een vergelijkbare positie bevinden. In dit stadium is het voorgestelde blok ‘vergrendeld’ en kan het pas worden vervangen als een poging tot invoeging is uitgevoerd.
  • Ronde verandering. De ronde liep uit voordat consensus werd bereikt of het blok kon niet worden ingevoegd. Wacht tot alle validators het eens zijn over het volgende ronde nummer.
Overgangen
  1. EENwachten Voorstel → Voorbereiden. Bij ontvangst van een nieuw blok (voorbereidingsbericht) van de indiener (d.w.z. het blok is geldig qua inhoud, evenals het voorgestelde kettinginvoegpunt).
  2. In afwachting van voorstel → Round Change. Het ontvangen voorstel was geen geldig blok volgens een bepaalde set regels (bijv. Ongeldige indiener, onjuiste rondenummering).
  3. Voorbereiden → Klaar. Bij ontvangst van 2F + 1-meldingen (bericht voorbereiden) van validator-peers die aangeven dat het voorgestelde blok geschikt is om in te voegen.
  4. Klaar → In afwachting van voorstel. Bij ontvangst van 2F + 1-meldingen (Commit-bericht) van validator-peers die aangeven dat ze klaar zijn om het blok aan de ketting toe te voegen. Bij de overgang wordt het proces van het toevoegen van het blok aan de ketting uitgevoerd (succes).
  5. Klaar → ronde verandering. Volgens Ready->In afwachting van voorstel is het invoegen van blokken echter mislukt.
  6. Round Change → In afwachting van voorstel. 2F + 1 van validators zijn het eens over het volgende ronde nummer dat moet worden gebruikt.

Opmerking: alle overgangen naar “RoundChange” resulteren erin dat de Validator een “RoundChange” -bericht verzendt naar zijn validator-peers.

Blokkering vergrendelen

IBFT schrijft voor dat er geen vorken mogen worden gemaakt. Daartoe wordt een blok dat eenmaal door een meerderheid is overeengekomen (d.w.z. bij binnenkomst in de status Gereed) ‘opgesloten’.

Dit betekent dat er geen andere blokken zullen worden overwogen om in te voegen totdat een poging is gedaan om dit blok aan de ketting toe te voegen. Dus ofwel wordt het blok met succes ingevoegd (zodra voldoende vastleggingsberichten zijn ontvangen, hetzij in deze of volgende rondes), of het invoegen van het blok mislukt, wordt weggegooid en wordt een nieuw blok voorgesteld op de huidige ketenhoogte.

Lidmaatschap van validatiegroep

De leden van de validatiegroep kunnen in de loop van de tijd veranderen door middel van een stemmechanisme. Leden kunnen worden toegevoegd of verwijderd bij meerderheid van stemmen (verdieping (N / 2) + 1); elke stem wordt vastgelegd in de Block Header.

Elk knooppunt in het netwerk (inclusief niet-validerende knooppunten) is verantwoordelijk voor het bijhouden van het aantal stemmen voor elke validator om de huidige validators te bepalen en ervoor te zorgen dat handtekeningen op gedolven blokken binnen de verwachte groep vallen.

Aangezien elke stem is opgenomen in de Block Header, kan alleen de indiener van een bepaalde ronde een stem uitbrengen. Het is dus belangrijk dat, als knooppunten tijdig worden toegevoegd / verwijderd, de rol van de indiener regelmatig wordt bijgewerkt..

Zodra een knooppunt meerderheidsstemmen heeft bereikt, sluiten ze zich onmiddellijk aan bij / verlaten ze de validatorgroep.

IBFT erkent een stemtijdvak, dat een punt definieert waarop alle stemmen die nog geen meerderheid hebben bereikt, worden verwijderd, waardoor de stemming opnieuw moet worden gestart. Dit houdt in dat validators bij het tellen van stemmen alleen hoeven te beginnen bij het meest recente tijdperk. Standaard vindt het stemtijdvak elke 30.000 blokken plaats.

Stemmen definiëren een statuswijziging (d.w.z. kandidaten worden gestemd, validators worden weggestemd), niet stemmen voor een bepaald knooppunt betekent dat de validator niet wil dat het knooppunt van status verandert (een expliciete stem is niet vereist om de status-quo te behouden).

Block Header Refactor

Om IBFT in Ethereum te ondersteunen, moeten een aantal wijzigingen worden aangebracht in de block headers. Deze wijzigingen zijn onder meer:

  • begunstigde: identificeert het knooppunt waarvoor een stem wordt uitgebracht.
  • nonce: specificeert de stem “richting” – AUTH of DROP.
  • mixHash: vast magisch nummer, waarmee dit blok wordt geïdentificeerd als IBFT-gevalideerd.
  • ommersHash: moet de hash zijn van een lege set, aangezien er geen ommer-blokken zijn bij het werken onder IBFT.
  • tijdstempel: moet ten minste het tijdstempel + blokinterval van het bovenliggende blok zijn.
  • moeilijkheid: moet worden gevuld met 0x0000000000000001.
  • extraData: bevat IBFT-specifieke gegevens, waaronder List of Validator Addresses, ProposerSeal (identificeert de indiener), CommittingSeals (lijst van validators die ‘commit’ hebben gerapporteerd op dit blok).

Aangezien de lijst met CommittingSeals voor elke validator (potentieel) verschillend is, is het belangrijk dat de block-hash deze informatie niet bevat – d.w.z. hoewel twee blokken verschillende CommittingSeals-velden hebben, vertegenwoordigen ze dezelfde informatie (d.w.z. transacties enz. Zijn identiek).

Gevolgtrekking

Tot slot is IBFT een Byzantijnse fouttolerante oplossing die onmiddellijke transactie-finaliteit biedt, waardoor de vereiste infrastructuur die PoW nodig heeft, wordt verminderd.

Hoewel het onwaarschijnlijk is dat het ooit zal worden gebruikt op Ethereum-mainnet (met de veel bredere, onbekende reeks deelnemende actoren), biedt het aanzienlijk voordeel wanneer het wordt gebruikt in een privéketen waar de validatorpool wordt vertrouwd en verantwoordelijk wordt gehouden; het biedt een ideale oplossing voor een ketting met een vaste cadans en een voorspelbare transactieverwerkingssnelheid.

De processen die in dit artikel worden onderzocht, geven het vertrouwen dat een netwerk dat IBFT gebruikt tolerant zal zijn voor Byzantijnse knooppunten en kan worden hersteld als blijkt dat die knooppunten de controle over het netwerk uitoefenen..

Abonneer u op onze nieuwsbrief voor het laatste Ethereum-nieuws, bedrijfsoplossingen, bronnen voor ontwikkelaars en meer.Volledige gids voor Blockchain-bedrijfsnetwerkenGids

Volledige gids voor Blockchain-bedrijfsnetwerken

Inleiding tot tokenisatieWebinar

Inleiding tot tokenisatie

De toekomst van digitale activa en defiWebinar

De toekomst van financiën: digitale activa en deFi

Wat is Enterprise EthereumWebinar

Wat is Enterprise Ethereum?

Centrale banken en de toekomst van geldWit papier

Centrale banken en de toekomst van geld

Komgo Blockchain voor Commodity Trade FinanceCase Stud

Komgo: Blockchain voor Commodity Trade Finance

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