blogul 1NewsDevelopersEnterpriseBlockchain Explained Evenimente și conferințe ApăsațiBuletine informative

Aboneaza-te la newsletter-ul nostru.

Adresa de email

Vă respectăm confidențialitatea

HomeBlogEnterprise Blockchain

Consensul de scalare pentru întreprindere: explicarea algoritmului IBFT

Modul în care Istanbul Byzantine Fault Tolerance (IBFT) îmbunătățește finalitatea și crește randamentul în rețelele private Ethereum. De ConsenSys 22 iunie 2018Publicat pe 22 iunie 2018

Eroul Ethereum ConsenSys

Algoritmii de consens sunt una dintre inovațiile esențiale ale blockchain-ului și totuși unul dintre cele mai confuze. Satoshi Nakamoto a creat o versiune a Proof of Work (PoW) care a fost implementată ca mijloc de securizare și validare simultană a tranzacțiilor Bitcoin. Comunitatea blockchain s-a bazat pe această viziune de bază pentru a crea o supă de alfabet de Dovadă de miză (PoS), Dovadă de autoritate (PoA), PBFT (Practical Byzantine Fault Tolerant) și multe altele care sunt toate concepute pentru a construi un consens într-o distribuție distribuită sistem, creând singura sursă de adevăr care face blockchain atât de valoros.

IBFT (Istanbul Byzantine Fault Tolerant) este un mecanism de consens care este o alternativă la dovada muncii într-o rețea Ethereum. La fel ca alți algoritmi, IBFT asigură o comandă unică, convenită, pentru tranzacții în blockchain și oferă beneficii suplimentare pentru întreprinderi, inclusiv finalitatea decontării. IBFT a fost implementat pentru prima dată în Geth de Amis Technologies, și la scurt timp implementat în Quorum.

Înainte de a intra în funcționarea mecanismului de consens IBFT, merită menționat când și de ce s-ar dori să se utilizeze IBFT. Într-un blockchain public, este posibil ca răspunsul scurt să nu fie posibil. Dar când vine vorba de consorțiu sau blockchain-uri private, IBFT începe să arate destul de atrăgător.

Algoritmul PoW este foarte costisitor, atât în ​​hardware, cât și în electricitate. Acest cost este intenționat, pentru a împiedica pe oricine să preia cu ușurință rețeaua și, prin urmare, PoW este foarte potrivit pentru situații cu descentralizare completă în care oricine (inclusiv atacatorii) poate participa. Cu toate acestea, nodurile din consorțiul / lanțurile private utilizate de întreprinderi sunt intrinsec mai de încredere decât cele dintr-un lanț public. Ca atare, mecanismul de consens PoW poate fi prea împovărător, iar alte mecanisme pot oferi încredere „suficientă” pentru a rula un sistem distribuit.

Dovada mizei, de asemenea, poate fi mai puțin relevantă pentru întreprinderi, deoarece plata pentru gaz este mai puțin importantă într-o rețea autorizată. Deoarece nodurile nu trebuie (neapărat) să mențină moneda în rețea, PoS ar introduce cerințe străine.

Luând în considerare aceste compromisuri, dovada autorității (PoA) apare ca cea mai bună soluție posibilă, utilizând un sistem prin care nodurilor din rețea li se alocă privilegiul de a produce blocuri noi pentru lanț folosind un sistem de tip round-robin sau alt sistem arbitrar.

IBFT este una dintre multele arome ale PoA și oferă următoarele beneficii:

  • Finalitatea blocului imediat. Există doar un bloc propus la o anumită înălțime a lanțului. Lanțul unic elimină astfel furcarea, blocurile unchiului și riscul ca o tranzacție să fie „anulată” o dată pe lanț ulterior.
  • Timp redus între blocuri. Efortul necesar pentru construirea și validarea blocurilor este semnificativ redus (în special în ceea ce privește PoW), crescând semnificativ debitul lanțului.
  • Integritate ridicată a datelor și toleranță la erori. IBFT folosește un grup de validatori pentru a asigura integritatea fiecărui bloc propus. O super-majoritate (~ 66%) dintre acești validatori trebuie să semneze blocul înainte de a fi inserat în lanț, ceea ce face falsificarea blocurilor foarte dificilă. „Conducerea” grupului se rotește, de asemenea, în timp – asigurându-se că un nod defect nu poate exercita o influență pe termen lung asupra lanțului.
  • Flexibil din punct de vedere operațional. Grupul de validatori poate fi modificat în timp, asigurându-se că grupul conține doar noduri de încredere completă.

Aici am oferit o prezentare generală a IBFT, în termeni preponderent non-tehnici. Pentru unele dintre propunerile originale ale IBFT, puteți consulta EIP-urile de pe GitHub:

Pentru restul acestui articol, vom explora considerațiile mai tehnice ale IBFT, discutând multe dintre conceptele găsite în EIP și pe care le-am învățat prin propriile noastre cercetări..

Notă: codul IBFT poate fi găsit și într-o cerere de extragere go-ethereum # 16385.

Operațiune

Mecanismul de consens IBFT cuprinde următoarele componente:

  1. A PBFT model de consens de grup inspirat.
  2. Un proces prin care membrii pot fi adăugați / eliminați din grupul de validare.

IBFT cere ca antetul blocului să fie (subtil) refăcut pentru a susține toate fațetele capacității.

Model de consens de grup

Prezentare generală

IBFT folosește un grup de noduri de validare (validatoare) care operează pe o rețea Ethereum pentru a determina dacă un bloc propus este potrivit pentru adăugarea la lanț.

Un nod al validatorilor este selectat în mod arbitrar ca Propunător și este responsabil pentru construirea unui bloc la intervalul de bloc și pentru partajarea blocului menționat cu grupul. Dacă o super-majoritate a validatorilor consideră că blocul este valid, acesta este adăugat la blockchain.

La finalizarea rundei de consens, validatorii pot selecta un nou propunător care va fi responsabil pentru furnizarea blocului candidat la următorul interval de blocare.

Mecanismul consensului este o mașină de stare sincronizată care este responsabilă pentru asigurarea tuturor validatorilor de a adăuga același bloc lanțului la aceeași înălțime.

Dacă un bloc nu reușește să se insereze, Propunătorul este modificat și procesul începe din nou.

Pentru a se asigura că un singur bloc poate fi adăugat la mașina de stat, IBFT împiedică schimbarea blocului propus odată ce o super-majoritate a validatorilor au fost de acord cu inserarea acestuia (dar nu au efectuat lucrarea menționată), acest proces este denumit „Blocare bloc”.

Mecanismul de consens IBFT oferă stabilitate sistemului cu condiția ca mai puțin de 1/3 din nodurile de validare să se comporte incorect (fie din cauza compromiterii, fie din cauza codului defect). Adică pentru a tolera F noduri defecte grupul de validare trebuie să conțină cel puțin 3F + 1 noduri (mai mult decât atât nu crește integritatea sistemului).

Notă: Aici F implică numărul de noduri defecte tolerate de sistem.

Mașină de stat

IBFT State Machine

State
  • Se așteaptă propunerea. Validatorul așteaptă ca un nou bloc să fie furnizat de către actualul proponent. Dacă validatorul este cel care propune această rundă, pregătește blocul propus și îl transmite într-un mesaj de pregătire prealabilă.
  • Pregătirea. A primit un bloc (valid) propus și a notificat validatorii-colegi; așteaptă acum ca validatorii-colegi să notifice acceptarea blocului.
  • Gata. A primit acceptarea blocului de către validator-coleg și așteaptă ca aceștia să fie într-o poziție similară. În această etapă, blocul propus a fost „blocat” și nu poate fi înlocuit până nu a fost efectuată o încercare de inserare.
  • Schimbare rotundă. Runda a expirat înainte ca consensul să fie atins sau blocul nu a reușit să se insereze. Așteptați ca toți validatorii să fie de acord cu numărul următoarei runde.
Tranziții
  1. APropunere în așteptare → Pregătirea. La primirea unui bloc nou (mesajul Preprepare) de la propunător (adică blocul este valid în conținutul său, la fel ca și punctul de inserare a lanțului propus).
  2. Se așteaptă propunerea → Modificare rotundă. Propunerea primită nu a fost un bloc valid în conformitate cu un anumit set de reguli (de exemplu, propunător invalid, numerotare incorectă rotundă).
  3. Pregătirea → Gata. La primirea notificărilor 2F + 1 (Pregătiți mesajul) de la validatori-colegi, indicând că blocul propus este potrivit pentru inserare.
  4. Gata → Se așteaptă propunerea. La primirea notificărilor 2F + 1 (mesaj de comitere) de la validatori-colegi care indică faptul că sunt gata să atașeze blocul la lanț. La tranziție, se realizează procesul de atașare a blocului la lanț (succes).
  5. Gata → Modificare rotundă. Conform Ready->Cu toate acestea, în așteptarea propunerii, inserarea blocului a eșuat.
  6. Modificare rotundă → Se așteaptă propunerea. 2F + 1 al validatorilor sunt de acord cu următorul număr de rundă care va fi utilizat.

Notă: Toate tranzițiile în „RoundChange” au ca rezultat validarea transmiterii unui mesaj „RoundChange” către validatorii-colegi.

Blocare bloc

IBFT impune ca furcile să nu fie create. În acest scop, odată ce un bloc a fost agreat de majoritate (adică la intrarea în starea Ready), acesta devine „blocat”.

Aceasta înseamnă că nu vor fi luate în considerare alte blocuri pentru inserare până când nu s-a încercat o încercare de a adăuga acest bloc în lanț. Astfel, fie blocul este inserat cu succes (odată primite suficiente mesaje de confirmare, fie în rundele următoare sau ulterioare), fie blocarea eșuează inserarea, este eliminat și se propune un bloc nou la înălțimea curentă a lanțului.

Calitate de membru al grupului

Membrii grupului de validare se pot schimba în timp printr-un mecanism de vot. Membrii pot fi adăugați sau eliminați prin vot majoritar (Floor (N / 2) + 1); fiecare vot este capturat în antetul blocului.

Fiecare nod din rețea (inclusiv noduri nevalidante) este responsabil pentru urmărirea numărului de voturi pentru fiecare validator pentru a determina validatorii curenți și pentru a se asigura că semnăturile de pe blocurile minate se încadrează în grupul așteptat.

Având în vedere că fiecare vot este cuprins în antetul blocului, numai Propunătorul pentru o rundă dată este capabil să voteze. Astfel, este important, dacă nodurile vor fi adăugate / eliminate în timp util, ca rolul de propunător să fie actualizat în mod regulat.

Odată ce un nod atinge majoritatea voturilor, aceștia se alătură / părăsesc imediat grupul validatorului.

IBFT recunoaște o epocă de votare, care definește un punct în care toate voturile care nu au ajuns încă la majoritate sunt eliminate, forțând repornirea numărului de voturi. Acest lucru implică atunci când contează voturile, validatorii trebuie să înceapă doar din cea mai recentă epocă. În mod implicit, Epoca de vot are loc la fiecare 30.000 de blocuri.

Voturile definesc o schimbare de stare (adică candidații sunt votați, validatorii sunt votați), nevotarea pentru un anumit nod implică validatorul nu dorește ca nodul să schimbe starea (un vot explicit nu este necesar pentru a menține status quo-ul).

Refactor antet bloc

Pentru a sprijini IBFT în Ethereum, trebuie făcute o serie de modificări la antetele blocului. Aceste modificări includ:

  • beneficiar: identifică nodul pentru care se votează.
  • nonce: specifică „direcția” votului – AUTH sau DROP.
  • mixHash: număr magic fixat, identificând acest bloc ca fiind validat IBFT.
  • ommersHash: trebuie să fie hashul unui set gol, deoarece nu există blocuri ommer atunci când funcționează sub IBFT.
  • timestamp: trebuie să fie cel puțin intervalul timestamp + bloc al blocului părinte.
  • dificultate: trebuie completat cu 0x0000000000000001.
  • extraData: conține date specifice IBFT, inclusiv Lista de adrese de validare, ProposerSeal (identifică propunătorul), CommittingSeals (lista validatorilor care au raportat „commit” pe acest bloc).

Deoarece lista CommittingSeals pentru fiecare validator este (potențial) diferită, este important ca hash-ul blocului să nu includă aceste informații – adică, chiar dacă două blocuri au câmpuri CommittingSeals diferite, ele reprezintă aceleași informații (adică tranzacțiile etc. sunt identice).

Concluzie

În încheiere, IBFT este o soluție bizantină tolerantă la erori, care oferă finalitatea imediată a tranzacției, care reduce infrastructura necesară pe care PoW o cere.

Deși este puțin probabil să fie folosit vreodată pe rețeaua principală Ethereum (cu un set mult mai larg și necunoscut de actori participanți), acesta oferă beneficii substanțiale atunci când este utilizat pe un lanț privat în care grupul de validatori este de încredere și responsabilizat; oferă o soluție ideală pentru un lanț cu cadență fixă ​​și o rată de procesare previzibilă a tranzacțiilor.

Procesele explorate în acest articol oferă încredere că o rețea care utilizează IBFT va fi tolerantă față de nodurile bizantine și poate fi recuperată în cazul în care aceste noduri exercită controlul asupra rețelei.

Newsletter Abonați-vă la newsletter-ul nostru pentru cele mai recente știri Ethereum, soluții pentru întreprinderi, resurse pentru dezvoltatori și multe altele. Adresa de e-mail Conținut exclusivGhid complet pentru rețelele de afaceri BlockchainGhid

Ghid complet pentru rețelele de afaceri Blockchain

Introducere în tokenizareWebinar

Introducere în tokenizare

Viitorul activelor digitale și al DeFi-ului financiarWebinar

Viitorul finanțelor: active digitale și DeFi

Ce este Enterprise EthereumWebinar

Ce este Enterprise Ethereum?

Băncile centrale și viitorul banilorHartie alba

Băncile centrale și viitorul banilor

Blockchain Komgo pentru finanțarea comerțului cu mărfuriStudiu de caz

Komgo: Blockchain pentru finanțarea comerțului cu mărfuri

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me