Konszenzus skálázása a vállalkozások számára: az IBFT algoritmus ismertetése

blog 1NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressHírlevelek

Iratkozzon fel hírlevelünkre.

Email cím

Tiszteletben tartjuk a magánéletét

HomeBlogVállalkozás Blockchain

Konszenzus skálázása a vállalkozások számára: az IBFT algoritmus ismertetése

Hogyan javítja az isztambuli bizánci hibatűrés (IBFT) a véglegességet és növeli az áteresztőképességet a privát Ethereum hálózatokban. – ConsenSys 2018. június 22., 2018. június 22.

Ethereum hős ConsenSys

A konszenzusos algoritmusok a blokklánc egyik legfontosabb újítása, ugyanakkor a legzavarosabbak is. Satoshi Nakamoto létrehozta a Proof of Work (PoW) verzióját, amelyet a Bitcoin tranzakciók egyidejű biztonságának és érvényesítésének eszközeként valósítottak meg. A blokklánc-közösség arra az alapvető elképzelésre épített, hogy létrehozza a tétbiztosítás (PoS), a hatósági igazolás (PoA), a PBFT (gyakorlati bizánci hibatűrő) és sok más ábécé levesét, amelyek mind konszenzus kialakítására irányulnak egy elosztott rendszer, létrehozva az igazság egyetlen forrását, amely a blokkláncot olyan értékesé teszi.

Az IBFT (isztambuli bizánci hibatűrő) egy konszenzusos mechanizmus, amely alternatívája az Ethereum hálózatban végzett munka igazolásának. Más algoritmusokhoz hasonlóan az IBFT is biztosítja a blokklánc tranzakcióinak egyetlen, egyeztetett megrendelését, és további előnyöket biztosít a vállalkozások számára, ideértve az elszámolások véglegességét is. Az IBFT volt először a Geth-ben hajtotta végre az Amis Technologies, és nem sokkal később a Kvórumban végrehajtották.

Mielőtt belekezdenénk az IBFT konszenzusos mechanizmus működésébe, érdemes megemlíteni, hogy mikor és miért szeretné használni az IBFT-t. Egy nyilvános blokkláncban a rövid válasz valószínűleg nem így lenne. De amikor konzorciumról vagy privát blokkláncokról van szó, az IBFT elég vonzónak tűnik.

A PoW algoritmus híresen költséges, mind hardverben, mind villamos energiában. Ez a költség szándékos, hogy megakadályozza, hogy bárki könnyen átvegye a hálózatot, és így a PoW nagyon alkalmas olyan helyzetekre, ahol teljes decentralizáció zajlik, ahol bárki (beleértve a támadókat is) részt vehet. A vállalkozások által használt konzorcium / magánlánc csomópontjai azonban lényegében jobban megbízhatóak, mint egy állami láncban. Mint ilyen, a PoW konszenzus mechanizmusa túlzottan megterhelő lehet, más mechanizmusok pedig „elegendő” bizalmat nyújthatnak egy elosztott rendszer futtatásához.

A tét igazolása szintén kevésbé lehet releváns a vállalkozások számára, mivel a gázért fizetni kevésbé fontos egy engedélyezett hálózatban. Mivel a csomópontoknak nincs (szükségszerűen) szükségük a pénznem fenntartására a hálózatban, a PoS idegen követelményeket vezetne be.

Figyelembe véve ezeket a kompromisszumokat, a lehető legjobb megoldásként a Proof of Authority (PoA) jelenik meg, amely egy olyan rendszert használ, amelyben a hálózat csomópontjainak az a kiváltsága van, hogy új blokkokat állítsanak elő a lánc számára egy körbefutó vagy más tetszőleges rendszer segítségével..

Az IBFT a PoA számos aromájának egyike, és a következő előnyöket nyújtja:

  • Azonnali blokk véglegesség. Csak egy blokk javasolt egy adott láncmagasságban. Az egyetlen lánc megszünteti a villákat, a nagybátyás blokkokat és annak kockázatát, hogy egy tranzakció később egyszer visszavonható legyen a láncon..
  • Csökkentett idő a blokkok között. A blokkok elkészítéséhez és validálásához szükséges erőfeszítés jelentősen csökken (különösen a PoW vonatkozásában), ami nagymértékben növeli a lánc áteresztőképességét.
  • Magas adatintegritás és hibatűrés. Az IBFT validátorok egy csoportját használja az egyes javasolt blokkok integritásának biztosítására. Ezen validátorok túlnyomó többségének (~ 66%) alá kell írnia a blokkot a láncba történő behelyezés előtt, ami nagyon megnehezíti a blokkhamisítást. A csoport „vezetése” is változik az idő múlásával – biztosítva, hogy a hibás csomópont nem gyakorolhat hosszú távú befolyást a láncra.
  • Működési szempontból rugalmas. Az érvényesítők csoportja időben módosítható, biztosítva, hogy a csoport csak teljes megbízhatóságú csomópontokat tartalmazzon.

Itt áttekintést nyújtottunk az IBFT-ről, többnyire nem műszaki szempontból. Az IBFT néhány eredeti javaslatához áttekintheti az EIP-ket a GitHubon:

A cikk további részében az IBFT technikai szempontjait tárjuk fel, megvitatva az EIP-kben található számos fogalmat, amelyeket saját kutatásunk során tanultunk meg.


Megjegyzés: Az IBFT kód megtalálható a go-ethereum 16385 számú lekérésében is.

Művelet

Az IBFT konszenzusos mechanizmus a következő összetevőket tartalmazza:

  1. A PBFT ihlette csoportkonszenzus modell.
  2. Olyan folyamat, amelynek során a tagok hozzáadhatók / eltávolíthatók az érvényesítő csoportból.

Az IBFT előírja, hogy a blokkfejlécet (finoman) át kell dolgozni, hogy támogassa a képesség minden aspektusát.

Csoportkonszenzus modell

Áttekintés

Az IBFT egy Ethereum hálózaton működő validáló csomópontok (validátorok) készletét használja annak megállapítására, hogy egy javasolt blokk alkalmas-e a lánc kiegészítésére.

A Validátorok egyik csomópontját önkényesen választják ki javaslattevőnek, és felelős azért, hogy a blokk-intervallumban blokkot építsen és megossza a blokkot a csoporttal. Ha a validátorok túlnyomó többsége a blokkot érvényesnek ítéli, akkor hozzáadódik a blokklánchoz.

A konszenzusos forduló végén az érvényesítők kiválaszthatnak egy új javaslattevőt, aki felelős lesz a blokkjelölt megadásáért a következő blokkintervallumban.

A konszenzus mechanizmus egy szinkronizált állapotgép, amely felelős azért, hogy az összes validátor ugyanazt a blokkot csatolja a lánchoz azonos magasságban.

Ha egy blokkot nem sikerül beilleszteni, a Proposer megváltozik, és a folyamat újrakezdődik.

Annak biztosítása érdekében, hogy csak egy blokkot lehessen csatolni az állapotgéphez, az IBFT megakadályozza a javasolt blokk megváltoztatását, ha a validátorok túlnyomó többsége beleegyezik a beillesztésébe (de az említett munkát nem hajtotta végre), ezt a folyamatot „Blokkzárásnak” nevezik..

Az IBFT konszenzus mechanizmusa biztosítja a rendszer stabilitását, feltéve, hogy az érvényesítő csomópontok kevesebb mint 1/3-a viselkedik helytelenül (vagy megsértés, vagy hibás kód miatt). Azaz. F hibás csomópontok tolerálásához az érvényesítési csoportnak legalább 3F + 1 csomópontot kell tartalmaznia (ennél több nem növeli a rendszer integritását).

Megjegyzés: Az F itt a rendszer által tolerált hibás csomópontok számát jelenti.

Államgép

IBFT állami gép

Államok
  • Javaslatra vár. A Validator arra vár, hogy egy új blokkot adjon meg a jelenlegi javaslattevő. Ha a validátor a javaslattevő erre a fordulóra, akkor elkészítik a javasolt blokkot, és előre elkészített üzenetben továbbítják.
  • Előkészítés. (Érvényes) javasolt blokkot kapott, és értesítette az érvényesítőtársakat; most azt várja, hogy az érvényesítő partnerek értesítsék a blokk elfogadásáról.
  • Kész. Megkapta a validátor és a társ közötti blokk elfogadását, és várja, hogy hasonló pozícióba kerüljenek. Ebben a szakaszban a javasolt blokkot „bezárták”, és csak akkor lehet kicserélni, ha a beillesztési kísérletet végrehajtották.
  • Kerek változás. A forduló időtúllépése még a konszenzus elérése előtt történt, vagy a blokkot nem sikerült beilleszteni. Várja meg, amíg az összes érvényesítő megállapodik a következő kör számában.
Átmenetek
  1. Avárakozás Javaslat → Előkészítés. Új blokk (Preprepare message) vétele után a javaslattevőtől (vagyis a blokk tartalma érvényes, csakúgy, mint a javasolt láncbeillesztési pont).
  2. Várakozás a javaslatra → Kerek változás. A beérkezett javaslat egy adott szabályrendszer szerint nem volt érvényes blokk (pl. Érvénytelen javaslattevő, helytelen kerek számozás).
  3. Előkészítés → Kész. 2F + 1 értesítések (üzenet előkészítése) fogadásakor a validátor-társaktól, jelezve, hogy a javasolt blokk alkalmas beillesztésre.
  4. Kész → javaslatra vár. A 2F + 1 értesítések (Kötelező üzenet) fogadása a validátor társaitól, jelezve, hogy készek hozzáadni a blokkot a lánchoz. Átmenetkor a blokk hozzáfűzése a lánchoz folyamatban van (siker).
  5. Kész → Kerek váltás. A Ready szerint->A javaslatra várva azonban a blokk beillesztése nem sikerült.
  6. Kerek váltás → Várakozás javaslatra. 2F + 1 validátor megállapodik a következő felhasználandó kör számában.

Megjegyzés: Minden áttérés a „RoundChange” -re azt eredményezi, hogy a Validator továbbít egy „RoundChange” üzenetet az érvényesítő társainak.

Blokkolás

Az IBFT előírja, hogy nem szabad villákat létrehozni. Ebből a célból, ha a blokkról a többség megállapodott (azaz a Kész állapotba lépve), akkor „bezáródik”.

Ez azt jelenti, hogy más blokkok beillesztését nem veszik figyelembe, amíg nem próbálják meg megadni ezt a blokkot a lánchoz. Így vagy a blokk sikeresen beillesztésre kerül (ha elegendő véglegesítési üzenet érkezik, akár ebben, akár az azt követő körökben), vagy a blokkot nem sikerül beilleszteni, eldobjuk, és egy új blokkot javasolunk a jelenlegi láncmagasságban.

Validációs csoport tagság

A validációs csoport tagjai idővel megváltozhatnak egy szavazási mechanizmus révén. A tagokat többséggel lehet hozzáadni vagy eltávolítani (emelet (N / 2) + 1) szavazással; minden szavazatot a blokkfejléc rögzít.

A hálózat minden csomópontja (beleértve a nem érvényesítő csomópontokat is) felelős az egyes validátorok szavazatszámlálásának nyomon követéséért, hogy meghatározza az aktuális validátorokat és biztosítsa, hogy a kitermelt blokkok aláírása a várt csoportba kerüljön.

Mivel az egyes szavazatok a blokkfejlécben találhatók, csak az adott fordulóra pályázó adhat le szavazatot. Ezért fontos, hogy a csomópontok időben történő hozzáadásához / eltávolításához rendszeresen frissítse a Proposer szerepet.

Amint egy csomópont eléri a többségi szavazatot, azonnal csatlakoznak / elhagyják az érvényesítő csoportot.

Az IBFT elismeri a Szavazás korszakát, amely meghatározza azt a pontot, amelyen az összes szavazat, amely még nem jutott többségre, eltávolításra kerül, a szavazatszámlálás újrakezdésére kényszerítve. Ez azt jelenti, hogy a szavazatok számlálásakor a Validatoroknak csak a legújabb korszakban kell elindulniuk. Alapértelmezés szerint a Szavazás korszaka 30 000 blokkonként történik.

A szavazatok meghatározzák az állapotváltozást (azaz a jelöltek szavaznak be, az érvényesítőket kiszavazzák), ha nem szavazunk egy adott csomópontra, az azt jelenti, hogy a Validator nem kívánja, hogy a csomópont megváltoztassa az állapotát (a status quo fenntartásához nincs szükség kifejezett szavazásra).

Blokkolja a fejléc refaktort

Az IBFT támogatásához az Ethereumban számos változtatást kell végrehajtani a blokkfejléceken. Ezek a változások a következők:

  • kedvezményezett: azonosítja azt a csomópontot, amelyre szavazatot adnak le.
  • nonce: meghatározza a szavazás „irányát” – AUTH vagy DROP.
  • mixHash: rögzített mágikus szám, amely ezt a blokkot IBFT validáltnak azonosítja.
  • ommersHash: egy üres halmaz kivonatának kell lennie, mivel IBFT alatt nem működik ommer blokk.
  • időbélyeg: legalább a szülőblokk időbélyegének + blokkintervallumnak kell lennie.
  • nehézség: 0x000000000000000001-gyel kell kitölteni.
  • extraData: IBFT-specifikus adatokat tartalmaz, beleértve a Validator címek listáját, a ProposerSeal (azonosítja a javaslattevőt), a CommittingSeals (a validátorok listája, amelyek jelentést tettek ebben a blokkban).

Mivel az egyes validátorok CommittingSeals listája (potenciálisan) eltér, fontos, hogy a blokk hash ne tartalmazza ezeket az információkat – vagyis annak ellenére, hogy két blokknak különböző CommittingSeals mezői vannak, ugyanazokat az információkat képviselik (azaz a tranzakciók stb. Azonosak).

Következtetés

Zárásként az IBFT egy bizánci hibatűrő megoldás, amely azonnali tranzakciós véglegességet kínál, amely csökkenti a PoW által igényelt szükséges infrastruktúrát.

Bár nem valószínű, hogy valaha is használják az Ethereum mainnet-en (a részt vevő szereplők sokkal szélesebb, ismeretlen körével együtt), jelentős előnyöket kínál, ha egy privát láncban használják, ahol az ellenőrző készlet megbízható és felelősségre vonható; ideális megoldást kínál fix láncú és kiszámítható tranzakciófeldolgozási sebességű lánc számára.

Az ebben a cikkben feltárt folyamatok meggyőződnek arról, hogy az IBFT-t alkalmazó hálózat toleráns lesz a bizánci csomópontokkal szemben, és helyreállítható, ha úgy látják, hogy ezek a csomópontok gyakorolják az irányítást a hálózaton.

Iratkozzon fel hírlevelünkre a legfrissebb Ethereum hírekről, vállalati megoldásokról, fejlesztői erőforrásokról és egyebekről. E-mail cím Exkluzív tartalomTeljes útmutató a Blockchain üzleti hálózatokhozÚtmutató

Teljes útmutató a Blockchain üzleti hálózatokhoz

Bevezetés a tokenizálásbaWebinárium

Bevezetés a tokenizálásba

A pénzügyi eszközök digitális eszközei és a DeFi jövőjeWebinárium

A pénzügyek jövője: digitális eszközök és DeFi

Mi az Enterprise EthereumWebinárium

Mi az Enterprise Ethereum?

A központi bankok és a pénz jövőjeFehér papír

A központi bankok és a pénz jövője

Komgo Blockchain az árukereskedelem finanszírozásáhozEsettanulmány

Komgo: Blockchain az árukereskedelem finanszírozásához

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