Vienošanās mērogošana uzņēmumiem: IBFT algoritma skaidrojums

emuārs 1NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressBiļeteni

Abonējiet mūsu biļetenu.

Epasta adrese

Mēs cienām jūsu privātumu

SākumsBlogsUzņēmums Blockchain

Vienošanās mērogošana uzņēmumiem: IBFT algoritma skaidrojums

Kā Stambulas bizantiešu defektu tolerance (IBFT) uzlabo galīgumu un palielina caurlaidspēju privātajos Ethereum tīklos. – ConsenSys – 2018. gada 22. jūnijs Ievietots 2018. gada 22. jūnijā

Ethereum varonis ConsenSys

Vienprātības algoritmi ir viens no blokķēdes galvenajiem jauninājumiem, un tomēr arī viens no mulsinošākajiem. Satoshi Nakamoto izveidoja Proof of Work (PoW) versiju, kas tika ieviesta kā līdzeklis, lai vienlaikus nodrošinātu un apstiprinātu Bitcoin darījumus. Blokķēdes kopiena ir veidojusi šo pamatvīziju, lai izveidotu alfabēta zupu ar pierādījumiem par likmēm (PoS), autoritātes apliecinājumu (PoA), PBFT (praktiskā bizantiešu vainas tolerance) un daudziem citiem, kas visi ir paredzēti, lai izveidotu vienprātību izplatītā veidā sistēmu, radot vienotu patiesības avotu, kas padara blokķēdi tik vērtīgu.

IBFT (Stambulas bizantiešu defektu tolerants) ir vienprātības mehānisms, kas ir alternatīva darba pierādīšanai Ethereum tīklā. Tāpat kā citi algoritmi, arī IBFT nodrošina vienotu, saskaņotu darījumu pasūtīšanu blokķēdē un uzņēmumiem sniedz papildu priekšrocības, tostarp norēķinu galīgumu. IBFT bija pirmo reizi Gethā ieviesa Amis Technologies, un drīz pēc ieviešanas Kvorumā.

Pirms sākat darboties IBFT vienprātības mehānismā, ir vērts pieminēt, kad un kāpēc vēlaties izmantot IBFT. Publiskā blokķēdē īsa atbilde, visticamāk, jūs to nedarītu. Bet, runājot par konsorciju vai privātiem blokķēdēm, IBFT sāk izskatīties diezgan pievilcīgi.

PoW algoritms ir ļoti dārgs gan aparatūras, gan elektrības jomā. Šīs izmaksas ir tīšas, lai neļautu nevienam viegli pārņemt tīklu, un tādējādi PoW ir ļoti piemērots situācijām ar pilnīgu decentralizāciju, kur piedalīties var ikviens (arī uzbrucēji). Uzņēmumu izmantotie konsorcija / privāto ķēžu mezgli tomēr ir uzticamāki nekā publiskajā ķēdē esošie. Kā tāds, PoW vienprātības mehānisms var būt pārāk apgrūtinošs, un citi mehānismi var nodrošināt “pietiekamu” uzticību, lai palaistu sadalītu sistēmu.

Tāpat līdzdalības pierādījums uzņēmumiem var būt mazāk būtisks, jo atļautā tīklā maksāšana par gāzi ir mazāk svarīga. Tā kā mezgliem nav (obligāti) jāuztur valūta tīklā, PoS ieviesīs svešas prasības.

Ņemot vērā šos kompromisus, kā iespējamais labākais risinājums parādās autoritātes pierādījums (PoA), izmantojot sistēmu, kurā tīkla mezgliem tiek piešķirta privilēģija ražot jaunus ķēdes blokus, izmantojot apaļo vai citu patvaļīgu sistēmu.

IBFT ir viens no daudzajiem PoA aromātiem un sniedz šādas priekšrocības:

  • Tūlītēja bloku galīgums. Noteiktā ķēdes augstumā ir ierosināts tikai 1 bloks. Tādējādi viena ķēde novērš dakšas, onku bloķēšanu un risku, ka darījumu var ķēdē vienu reizi vēlāk atsaukt..
  • Saīsināts laiks starp blokiem. Bloku konstruēšanai un validēšanai nepieciešamās pūles ir ievērojami samazinātas (īpaši attiecībā uz PoW), ievērojami palielinot ķēdes caurlaidspēju..
  • Augsta datu integritāte un kļūdu tolerance. IBFT izmanto validatoru grupu, lai nodrošinātu katra ierosinātā bloka integritāti. Šo apstiprinātāju lielākai daļai (~ 66%) ir jāparaksta bloks pirms ievietošanas ķēdē, kas ļoti apgrūtina bloka viltošanu. Laika gaitā mainās arī grupas “vadība” – nodrošinot, ka bojāts mezgls nevar ilgstoši ietekmēt ķēdi.
  • Darbībā elastīga. Validatoru grupu var mainīt laikā, nodrošinot, ka grupā ir tikai pilnībā uzticami mezgli.

Šeit mēs sniedzām pārskatu par IBFT, galvenokārt netehniskā izteiksmē. Dažus sākotnējos IBFT priekšlikumus varat pārskatīt EIP vietnē GitHub:

Šajā rakstā mēs izpētīsim IBFT tehniskākos apsvērumus, apspriežot daudzus EIP atrodamos jēdzienus un ko mēs esam iemācījušies, veicot savus pētījumus.


Piezīme: IBFT kodu var atrast arī go-ethereum pieprasījuma pieprasījumā Nr. 16385.

Darbība

IBFT vienprātības mehānisms sastāv no šādām sastāvdaļām:

  1. A PBFT iedvesmoja grupas vienprātības modeli.
  2. Process, kurā dalībniekus var pievienot / noņemt no apstiprināšanas grupas.

IBFT prasa, lai bloka galvene būtu (smalki) jāpārstrādā, lai atbalstītu visas iespējas.

Grupas konsensa modelis

Pārskats

IBFT izmanto validācijas mezglu (Validatoru) kopu, kas darbojas Ethereum tīklā, lai noteiktu, vai piedāvātais bloks ir piemērots pievienošanai ķēdei..

Viens Validatoru mezgls ir patvaļīgi izvēlēts kā ierosinātājs un ir atbildīgs par bloka izveidošanu bloka intervālā un minētā bloka koplietošanu ar grupu. Ja Validatoru vairākums uzskata bloku par derīgu, tas tiek pievienots blokķēdei.

Pēc vienprātības kārtas pabeigšanas apstiprinātāji var izvēlēties jaunu priekšlikumu iesniedzēju, kurš būs atbildīgs par kandidāta bloka nodrošināšanu nākamajā bloka intervālā.

Vienprātības mehānisms ir sinhronizēta stāvokļa mašīna, kas ir atbildīga par to, lai visi pārbaudītāji pievienotu to pašu bloku ķēdei vienā augstumā.

Ja bloku neizdodas ievietot, ierosinātājs tiek mainīts un process sākas no jauna.

Lai nodrošinātu, ka stāvokļa mašīnai var pievienot tikai vienu bloku, IBFT novērš ierosinātā bloka maiņu, ja lielākā daļa validatoru ir piekrituši tā ievietošanai (bet nav veikuši minēto darbu), šis process tiek saukts par “Bloka bloķēšanu”.

IBFT vienprātības mehānisms piedāvā sistēmas stabilitāti, ja mazāk nekā 1/3 apstiprinošo mezglu rīkojas nepareizi (vai nu tāpēc, ka ir apdraudēti, vai arī nepareiza koda dēļ). T.i. lai paciestu F kļūdainus mezglus, validācijas grupā jābūt vismaz 3F + 1 mezgliem (vairāk nekā tas nepalielina sistēmas integritāti).

Piezīme: Šeit F nozīmē kļūdainu mezglu skaitu, ko sistēma pieļauj.

Valsts mašīna

IBFT valsts mašīna

Štatos
  • Gaida priekšlikumu. Validators gaida, kamēr pašreizējais ierosinātājs piegādās jaunu bloku. Ja validators ir šīs kārtas ierosinātājs, viņi sagatavo piedāvāto bloku un nosūta to iepriekšējas sagatavošanas ziņojumā.
  • Sagatavošanās. Ir saņēmis (derīgu) ierosinātu bloku un paziņojis validatoram vienaudžiem; tagad gaida, kad vienaudži validatori paziņos par bloka akceptēšanu.
  • Gatavs. Ir saņēmis apstiprinātāja un vienaudža piekrišanu blokam un gaida, kamēr viņi būs līdzīgā pozīcijā. Šajā posmā ierosinātais bloks ir “bloķēts”, un to nevar aizstāt, kamēr nav mēģināts ievietot.
  • Apaļā maiņa. Kārtas laiks iestājās, pirms tika panākta vienprātība vai bloku neizdevās ievietot. Pagaidiet, līdz visi validētāji vienojas par nākamo kārtas numuru.
Pārejas
  1. Agaida priekšlikumu → sagatavošana. Saņemot jaunu bloku (Sagatavot ziņojumu) no ierosinātāja (t.i., bloks ir derīgs savā saturā, tāpat kā tā piedāvātais ķēdes ievietošanas punkts).
  2. Gaida priekšlikumu → Apaļas izmaiņas. Saņemtais priekšlikums nebija derīgs bloks saskaņā ar noteikto noteikumu kopumu (piemēram, nederīgs ierosinātājs, nepareiza apaļā numerācija).
  3. Sagatavošanās → Gatavs. Saņemot 2F + 1 paziņojumus (Sagatavot ziņojumu) no vienaudžiem, kas norāda, ka piedāvātais bloks ir piemērots ievietošanai.
  4. Gatavs → Gaida priekšlikumu. Saņemot 2F + 1 paziņojumus (apņemšanās ziņojums) no vienaudžiem, kas norāda, ka viņi ir gatavi pievienot bloku ķēdei. Pārejas laikā tiek veikts bloka pievienošanas ķēdei process (panākumi).
  5. Gatavs → Apaļas izmaiņas. Kā gatavs->Gaida priekšlikumu, tomēr bloku ievietošana neizdevās.
  6. Kārtas maiņa → Gaida priekšlikumu. 2F + 1 apstiprinātāji vienojas par nākamās kārtas numuru, kas jāizmanto.

Piezīme. Visu pāreju laikā uz “RoundChange” Validator nosūta ziņojumu “RoundChange” saviem validatoriem..

Bloku bloķēšana

IBFT nosaka, ka dakšas nedrīkst izveidot. Šim nolūkam, tiklīdz bloks ir saskaņots ar balsu vairākumu (t.i., nonākot gatavajā stāvoklī), tas kļūst “bloķēts”.

Tas nozīmē, ka citu bloku ievietošana netiks apsvērta, kamēr netiks mēģināts pievienot šo bloku ķēdei. Tādējādi vai nu bloks tiek veiksmīgi ievietots (tiklīdz ir saņemts pietiekami daudz saistību ziņojumu vai nu šajā, vai nākamajās kārtās), vai arī bloks neizdodas ievietot, tiek izmests un tiek piedāvāts jauns bloks pašreizējā ķēdes augstumā.

Apstiprināšanas grupas dalība

Validācijas grupas locekļi laika gaitā var mainīties, izmantojot balsošanas mehānismu. Locekļus var pievienot vai noņemt ar balsu vairākumu (Floor (N / 2) + 1); katra balss tiek uztverta bloka galvenē.

Katrs tīkla mezgls (ieskaitot nederificējošus mezglus) ir atbildīgs par katra validētāja balsu skaitīšanas izsekošanu, lai noteiktu pašreizējos validatorus un nodrošinātu, ka paraksti uz izraktajiem blokiem ietilpst gaidāmajā grupā..

Tā kā katra balss ir iekļauta bloka galvenē, balsi var dot tikai attiecīgās kārtas ierosinātājs. Tāpēc ir svarīgi, lai mezgli tiktu savlaicīgi pievienoti / noņemti, regulāri jāatjaunina ierosinātāja loma.

Kad mezgls sasniedz balsu vairākumu, viņi nekavējoties pievienojas / atstāj validatoru grupu.

IBFT atzīst balsošanas laikmetu, kas nosaka punktu, kurā tiek noņemtas visas balsis, kas vēl nav sasniegušas vairākumu, liekot atsākt balsošanas kopskaitu. Tas nozīmē, ka, balsu skaitīšanas laikā, apstiprinātājiem jāsāk tikai pēdējā laikmetā. Pēc noklusējuma balsošanas laikmets notiek ik pēc 30 000 blokiem.

Balsis nosaka stāvokļa maiņu (t.i., kandidāti tiek nobalsoti, validētāji tiek nobalsoti), bet nebalsojot par konkrēto mezglu, Validator nevēlas, lai mezgls mainītu stāvokli (status quo uzturēšanai nav nepieciešams izteikts balsojums).

Bloķēt galvenes refaktoru

Lai atbalstītu IBFT Ethereum, bloka galvenēs ir jāveic vairākas izmaiņas. Šīs izmaiņas ietver:

  • saņēmējs: identificē mezglu, par kuru tiek balsots.
  • nonce: norāda balsojuma “virzienu” – AUTH vai DROP.
  • mixHash: piestiprināts burvju numurs, identificējot šo bloku kā IBFT validētu.
  • ommersHash: jābūt tukšas kopas hash, jo, darbojoties ar IBFT, nav ommer bloku.
  • laikspiedols: jābūt vismaz vecāka bloka laika zīmoga + bloķēšanas intervālam.
  • grūtība: jāaizpilda ar 0x000000000000000001.
  • extraData: satur specifiskus IBFT datus, tostarp Validatoru adrešu sarakstu, ProposerSeal (identificē ierosinātāju), CommittingSeals (to validatoru saraksts, kuri ziņoja par “bloka izdarīšanu” šajā blokā).

Tā kā katra validētāja CommittingSeals saraksts ir (potenciāli) atšķirīgs, ir svarīgi, lai bloka jaucējinstrumentā netiktu iekļauta šī informācija – t.i., kaut arī diviem blokiem ir atšķirīgi lauki CommittingSeals, tie pārstāv to pašu informāciju (t.i., darījumi utt. Ir identiski).

Secinājums

Noslēgumā jāsaka, ka IBFT ir bizantiešu kļūdu tolerants risinājums, kas piedāvā tūlītēju darījumu galīgumu, kas samazina nepieciešamo PoW pieprasīto infrastruktūru.

Lai gan maz ticams, ka to kādreiz izmantos Ethereum mainnet (ar daudz plašāku, nezināmu iesaistīto dalībnieku kopumu), tas piedāvā ievērojamus ieguvumus, ja tos izmanto privātā ķēdē, kur validatoru kopa ir uzticama un tiek saukta pie atbildības; tas nodrošina ideālu risinājumu ķēdei ar fiksētu ritmu un paredzamu darījumu apstrādes ātrumu.

Šajā rakstā izpētītie procesi dod pārliecību, ka tīkls, kas izmanto IBFT, būs tolerants pret Bizantijas mezgliem un to var atjaunot, ja tiek uzskatīts, ka šie mezgli pārvalda tīklu.

Abonējiet mūsu biļetenu, lai iegūtu jaunākos Ethereum jaunumus, uzņēmuma risinājumus, izstrādātāju resursus un daudz ko citu. E-pasta adrese Ekskluzīvs satursPilnīgs Blockchain biznesa tīklu ceļvedisVadīt

Pilnīgs Blockchain biznesa tīklu ceļvedis

Ievads tokenizācijāTīmekļa seminārs

Ievads tokenizācijā

Finanšu digitālo aktīvu un DeFi nākotneTīmekļa seminārs

Finanšu nākotne: digitālie aktīvi un DeFi

Kas ir Enterprise EthereumTīmekļa seminārs

Kas ir Enterprise Ethereum?

Centrālās bankas un naudas nākotneBaltā grāmata

Centrālās bankas un naudas nākotne

Komgo Blockchain preču tirdzniecības finansēšanaiLietu izpēte

Komgo: Blockchain preču tirdzniecības finansēšanai

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