Konsensuksen skaalaus yrityksille: IBFT-algoritmin selittäminen

blogi 1NewsDevelopersEnterpriseBlockchain ExplainedTapahtumat ja konferenssitPainaUutiskirjeet

tilaa uutiskirjeemme.

Sähköpostiosoite

Kunnioitamme yksityisyyttäsi

EtusivuBlogiYritys Blockchain

Konsensuksen skaalaus yrityksille: IBFT-algoritmin selittäminen

Kuinka Istanbulin bysanttilainen vikasietoisuus (IBFT) parantaa lopullisuutta ja lisää läpäisykykyä yksityisissä Ethereum-verkoissa. – ConsenSys 22. kesäkuuta 2018 Lähetetty 22. kesäkuuta 2018

Ethereumin sankari ConsenSys

Konsensusalgoritmit ovat yksi blockchainin ydininnovaatioista ja silti myös hämmentävimpiä. Satoshi Nakamoto loi version Proof of Work (PoW) -sovelluksesta, joka toteutettiin keinona samanaikaisesti turvata ja vahvistaa Bitcoin-tapahtumia. Lohkoketjuyhteisö on rakentanut tuon ydinvision luomaan aakkoskeitto vaarnan todistuksesta (PoS), auktoriteetin todistuksesta (PoA), PBFT: stä (käytännön bysanttilaisesta vikatoleranssista) ja monista muista, jotka kaikki on suunniteltu rakentamaan konsensusta hajautetussa muodossa järjestelmä, luomalla yksi totuuden lähde, joka tekee blockchainista niin arvokkaan.

IBFT (Istanbul Byzantine Fault Tolerant) on konsensusmekanismi, joka on vaihtoehto Ethereum-verkon työn todistamiselle. Muiden algoritmien tavoin IBFT varmistaa yhden, sovitun tilauksen lohkoketjussa tapahtuville liiketoimille ja tarjoaa yrityksille lisäetuja, mukaan lukien selvityksen lopullisuus. IBFT oli ensimmäisen kerran Gethissä toteuttanut Amis Technologies, ja pian sen jälkeen, kun se on pantu täytäntöön koorumissa.

Ennen kuin aloitat IBFT-konsensusmekanismin toiminnan, on syytä mainita, milloin ja miksi haluat käyttää IBFT: tä. Julkisessa estoketjussa lyhyt vastaus on todennäköisesti et. Mutta konsortion tai yksityisten lohkoketjujen suhteen IBFT alkaa näyttää melko houkuttelevalta.

PoW-algoritmi on huomattavan kallista sekä laitteistossa että sähkössä. Nämä kustannukset ovat tarkoituksellisia, jotta estetään ketään siirtämästä helposti verkkoa, ja näin ollen PoW soveltuu hyvin tilanteisiin, joissa on täydellinen hajauttaminen ja joihin kuka tahansa (hyökkääjät mukaan lukien) voi osallistua. Yritysten käyttämät konsortio- / yksityisten ketjujen solmut ovat kuitenkin luottamukseltaan luotettavampia kuin julkisessa ketjussa olevat. Sellaisena PoW-konsensusmekanismi voi olla liian rasittava, ja muut mekanismit voivat tarjota “tarpeeksi” luottamusta hajautetun järjestelmän ajamiseksi.

Panoksen todistaminen voi myös olla vähemmän merkityksellistä yrityksille, koska kaasun maksaminen on vähemmän tärkeää luvallisessa verkossa. Koska solmujen ei tarvitse (välttämättä) ylläpitää valuuttaa verkossa, PoS-järjestelmä ottaisi käyttöön ulkopuolisia vaatimuksia.

Kun otetaan huomioon nämä kompromissit, todistus viranomaisuudesta (PoA) nousee esiin mahdollisena parhaana ratkaisuna, joka käyttää järjestelmää, jossa verkon solmuille annetaan etuoikeus tuottaa uusia lohkoja ketjulle käyttämällä pyöreää robinia tai muuta mielivaltaista järjestelmää..

IBFT on yksi monista PoA-makuista ja tarjoaa seuraavat edut:

  • Välitön lohkon lopullisuus. Tietyllä ketjun korkeudella on ehdotettu vain yksi lohko. Yksittäinen ketju poistaa tällöin haarukat, setälohkot ja riskin, että tapahtuma voidaan “kumota” kerran ketjussa myöhemmin.
  • Lyhempi aika lohkojen välillä. Lohkojen rakentamiseen ja validointiin tarvittavat toimet vähenevät merkittävästi (erityisesti PoW: n suhteen), mikä lisää merkittävästi ketjun läpäisykykyä.
  • Suuri tietojen eheys ja vikasietoisuus. IBFT käyttää validointiryhmää varmistaakseen jokaisen ehdotetun lohkon eheyden. Näiden validointilaitteiden ylivoimaisen enemmistön (~ 66%) vaaditaan allekirjoittavan lohko ennen asettamista ketjuun, mikä tekee lohkojen väärentämisestä erittäin vaikeaa. Myös ryhmän “johtajuus” kiertää ajan myötä – varmistamalla, että viallinen solmu ei voi vaikuttaa pitkään ketjuun.
  • Toiminnallisesti joustava. Validointiryhmää voidaan muuttaa ajoissa varmistaen, että ryhmässä on vain täysin luotettuja solmuja.

Tässä annoimme yleiskatsauksen IBFT: stä, lähinnä ei-teknisin termein. Joidenkin IBFT: n alkuperäisten ehdotusten osalta voit tarkistaa EIT: t GitHubissa:

Tämän artikkelin loppupuolella tutustumme IBFT: n teknisempiin näkökohtiin keskustelemalla monista EIP: n sisältämistä käsitteistä, jotka olemme oppineet omalla tutkimuksellamme.

Huomaa: IBFT-koodi löytyy myös go-ethereumin vetopyynnöstä # 16385.

Operaatio

IBFT-konsensusmekanismi käsittää seuraavat osat:

  1. A PBFT innoittamana ryhmän konsensusmalli.
  2. Prosessi, jolla jäseniä voidaan lisätä / poistaa validointiryhmästä.

IBFT edellyttää, että lohkootsikko on (hienovaraisesti) muokattu tukemaan ominaisuuden kaikkia puolia.

Ryhmän konsensusmalli

Yleiskatsaus

IBFT käyttää Ethereum-verkossa toimivien validointisolmujen (Validators) allasta selvittääkseen, onko ehdotettu lohko sopiva ketjun lisäämiseen.

Yksi Validatorien solmu valitaan mielivaltaisesti Ehdottajaksi, ja se on vastuussa lohkon rakentamisesta lohkovälillä ja mainitun lohkon jakamisesta ryhmän kanssa. Jos Validatorien suurin enemmistö pitää lohkoa kelvollisena, se lisätään lohkoketjuun.

Konsensuskierroksen päätyttyä validoijat voivat valita uuden ehdokkaan, joka vastaa ehdokaslohkon toimittamisesta seuraavalla lohkovälillä.

Konsensusmekanismi on synkronoitu tilakone, joka on vastuussa siitä, että kaikki validoijat liittävät saman lohkon ketjuun samalla korkeudella.

Jos lohkoa ei lisätä, ehdottaja muutetaan ja prosessi alkaa uudelleen.

Sen varmistamiseksi, että vain yksi lohko voidaan liittää tilakoneeseen, IBFT estää ehdotetun lohkon muuttamisen, kun ylimääräinen enemmistö validoijista on suostunut sen lisäämiseen (mutta ei suorittanut mainittua työtä), tätä prosessia kutsutaan nimellä ‘lohkon lukitus’.

IBFT-konsensusmekanismi tarjoaa järjestelmän vakauden edellyttäen, että alle 1/3 validoivista solmuista käyttäytyy väärin (joko vaarantuneen tai viallisen koodin vuoksi). Eli. F-viallisten solmujen sietämiseksi vahvistusryhmässä on oltava vähintään 3F + 1-solmua (enemmän kuin tämä ei lisää järjestelmän eheyttä).

Huomautus: Tässä F tarkoittaa järjestelmän sietämien viallisten solmujen määrää.

Valtion kone

IBFT-valtion kone

Osavaltiot
  • Odotetaan ehdotusta. Validator odottaa uuden lohkon toimittavan nykyisen ehdotuksen tekijän. Jos validoija on tämän kierroksen ehdottaja, he valmistelevat ehdotetun lohkon ja lähettävät sen esivalmisteluviestissä.
  • Valmistautuminen. On saanut (voimassa olevan) ehdotetun eston ja ilmoittanut validator-vertaisryhmille; odottaa nyt, että validator-vertaisryhmät ilmoittavat hyväksyvänsä lohkon.
  • Valmis. Hän on saanut validator-vertaisryhmän hyväksynnän lohkolle ja odottaa heidän olevan samanlaisessa asemassa. Tässä vaiheessa ehdotettu lohko on ”lukittu”, eikä sitä voida vaihtaa ennen kuin yritetään sijoittaa.
  • Pyöreä muutos. Kierros aikakatkaistiin ennen konsensuksen saavuttamista tai lohkon lisääminen epäonnistui. Odota, että kaikki validoijat sopivat seuraavan kierroksen numerosta.
Siirtymät
  1. Aodottaa ehdotusta → valmistellaan. Vastaanotettuaan uuden lohkon (Valmistele viesti) ehdotuksen tekijältä (ts. Lohko on kelvollinen sisällöltään, samoin kuin sen ehdotettu ketjun lisäyskohta).
  2. Odotetaan ehdotusta → Pyöreä muutos. Saatu ehdotus ei ollut kelvollinen lohko annettujen sääntöjen mukaan (esim. Virheellinen ehdottaja, väärä pyöristysnumerointi).
  3. Valmistelu → Valmis. Saatuaan 2F + 1 -ilmoitukset (Valmistele viesti) validoija-vertaisilta, jotka osoittavat, että ehdotettu lohko soveltuu lisättäväksi.
  4. Valmis → Odottaa ehdotusta. Vastaanotettuaan 2F + 1 -ilmoitukset (sitoutumisviesti) validointityökaluilta ilmoittavat olevansa valmiita liittämään lohkon ketjuun. Siirtymässä lohkon liittäminen ketjuun suoritetaan (menestys).
  5. Valmis → Pyöreä vaihto. Kuten valmiina->Odotetaan ehdotusta, mutta lohkon lisäys epäonnistui.
  6. Pyöreä muutos → Odottaa ehdotusta. 2F + 1 validoijia sopivat seuraavan kierroksen numerosta.

Huomaa: Kaikki siirtymät ”RoundChange” -ohjelmaan johtavat siihen, että Validator lähettää ”RoundChange” -sanoman validointipartnerilleen..

Estolukitus

IBFT määrää, että haarukoita ei saa luoda. Tätä varten, kun lohkosta on sovittu enemmistöllä (ts. Siirtyessä Valmiustilaan), se “lukittuu”.

Tämä tarkoittaa, että muita lohkoja ei harkita lisättäväksi, ennen kuin on yritetty lisätä tämä lohko ketjuun. Tällöin joko lohko lisätään onnistuneesti (kun riittävät sitoutumisviestit on vastaanotettu joko tässä tai seuraavissa kierroksissa), tai lohko epäonnistuu, hylätään ja ehdotetaan uutta lohkoa ketjun nykyisellä korkeudella.

Vahvistusryhmän jäsenyys

Vahvistusryhmän jäsenet voivat vaihtua ajan myötä äänestysmekanismin avulla. Jäseniä voidaan lisätä tai poistaa enemmistöllä (kerros (N / 2) + 1); kukin ääni tallennetaan lohkootsikkoon.

Kukin verkon solmu (mukaan lukien ei-validoivat solmut) on vastuussa kunkin vahvistimen ääntenlaskun seuraamisesta nykyisten validointilaitteiden määrittämiseksi ja sen varmistamiseksi, että louhittujen lohkojen allekirjoitukset kuuluvat odotettuun ryhmään.

Koska jokainen ääni sisältyy lohkootsikkoon, vain tietyn kierroksen ehdottaja voi äänestää. Siksi on tärkeää, että solmut lisätään / poistetaan ajoissa, että ehdottajarooli päivitetään säännöllisesti.

Kun solmu saavuttaa enemmistöäänestykset, ne liittyvät välittömästi validointiryhmään / poistuvat siitä.

IBFT tunnustaa äänestysjakson, jossa määritetään kohta, josta kaikki äänet, jotka eivät ole vielä saavuttaneet enemmistöä, poistetaan, mikä pakottaa äänestyslaskennan aloittamaan uudelleen. Tämä tarkoittaa sitä, että kun ääntä lasketaan, vahvistajien on aloitettava vasta viimeisimmässä aikakaudessa. Äänestysjakso tapahtuu oletusarvoisesti 30000 lohkon välein.

Äänet määrittelevät tilanmuutoksen (ts. Ehdokkaat äänestetään, validoijat äänestetään pois), ei äänestys tietylle solmulle tarkoittaa, että Validator ei halua solmun vaihtavan tilaa (status quon ylläpitämiseksi ei vaadita nimenomaista äänestystä).

Estä ylätunnistin

IBFT: n tukemiseksi Ethereumissa on tehtävä useita muutoksia lohkon otsikoihin. Näitä muutoksia ovat:

  • edunsaaja: tunnistaa solmun, jolle äänestetään.
  • nonce: määrittää äänestyssuunnan – AUTH tai DROP.
  • mixHash: kiinnitetty maaginen numero, joka tunnistaa tämän lohkon olevan IBFT-validoitu.
  • ommersHash: täytyy olla tyhjän sarjan hajautus, koska IBFT: n alla toimittaessa ei ole ommer-lohkoja.
  • aikaleima: on oltava vähintään päälohkon aikaleima + lohkoväli.
  • vaikeus: on täytettävä 0x0000000000000001.
  • extraData: sisältää IBFT-erityistietoja, mukaan lukien luettelo Validator-osoitteista, ProposerSeal (tunnistaa ehdotuksen tekijän), CommittingSeals (luettelo validoijista, jotka ilmoittivat ‘sitoutumisesta’ tässä lohkossa).

Koska kunkin validointilaitteen CommittingSeals-luettelo on (mahdollisesti) erilainen, on tärkeää, että lohkon hajautusarvo ei sisällä näitä tietoja – ts. Vaikka kahdella lohkolla on erilaiset CommittingSeals-kentät, ne edustavat samaa tietoa (ts. Tapahtumat ovat samanlaisia).

Johtopäätös

Lopuksi, IBFT on bysanttilainen vikasietoinen ratkaisu, joka tarjoaa välittömän tapahtuman lopullisuuden, mikä vähentää tarvittavaa infrastruktuuria, jota PoW vaatii.

Vaikka sitä ei todennäköisesti käytetä Ethereum mainnetissä (mukana on paljon laajempi, tuntematon joukko osallistuvia toimijoita), se tarjoaa huomattavaa hyötyä käytettäessä yksityisessä ketjussa, jossa validointipooliin luotetaan ja siitä pidetään vastuussa se tarjoaa ihanteellisen ratkaisun ketjulle, jolla on kiinteä poljinnopeus ja ennakoitava tapahtumien käsittelynopeus.

Tässä artikkelissa tutkitut prosessit antavat varmuuden siitä, että IBFT: tä käyttävä verkko on suvaitsevainen bysanttilaisille solmuille ja voidaan palauttaa, jos näiden solmujen katsotaan käyttävän verkon hallintaa.

Tilaa uutiskirjeemme, jossa on uusimmat Ethereum-uutiset, yritysratkaisut, kehittäjien resurssit ja paljon muuta.Täydellinen opas Blockchain-yritysverkoihinOpas

Täydellinen opas Blockchain-yritysverkoihin

Johdatus tokenisaatioonWebseminaari

Johdatus tokenisaatioon

Digitaalisten varojen ja DeFi: n tulevaisuusWebseminaari

Rahoituksen tulevaisuus: digitaaliset varat ja DeFi

Mikä on Enterprise EthereumWebseminaari

Mikä on Enterprise Ethereum?

Keskuspankit ja rahan tulevaisuusValkoinen paperi

Keskuspankit ja rahan tulevaisuus

Komgo Blockchain hyödykekaupan rahoitukseenTapaustutkimus

Komgo: Blockchain for Commodity Trade Finance

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