Мащабен консенсус за предприятието: Обяснение на алгоритъма IBFT

блог 1NewsDevelopersEnterpriseBlockchain ExplainedEvent and ConferencesPressБюлетини

Абонирайте се за нашия бюлетин.

Имейл адрес

Ние уважаваме вашата поверителност

HomeBlogEnterprise Blockchain

Мащабен консенсус за предприятието: Обяснение на алгоритъма IBFT

Как Истанбулската византийска толерантност към неизправности (IBFT) подобрява окончателността и увеличава пропускателната способност в частните мрежи на Ethereum. От ConsenSys 22 юни 2018 г. Публикувано на 22 юни 2018 г.

Героят на Ethereum ConsenSys

Консенсусните алгоритми са една от основните иновации на блокчейна, но в същото време и една от най-объркващите. Сатоши Накамото създаде версия на Proof of Work (PoW), която беше приложена като средство за едновременно осигуряване и валидиране на биткойн транзакции. Блокчейн общността е надградила тази основна визия, за да създаде азбучна супа от Proof of Stake (PoS), Proof of Authority (PoA), PBFT (Practical Byzantine Fault Tolerant) и много други, които са създадени да постигнат консенсус в разпределен система, създаваща единствения източник на истина, който прави блокчейна толкова ценен.

IBFT (Истанбулска византийска грешка) е механизъм за консенсус, който е алтернатива на Proof of Work в мрежа на Ethereum. Подобно на други алгоритми, IBFT осигурява единна, договорена поръчка за транзакции в блокчейна и предоставя допълнителни предимства за предприятията, включително окончателността на сетълмента. IBFT беше за първи път внедрен в Geth от Amis Technologies, и скоро след това внедрен в Кворума.

Преди да влезете в действие на механизма за консенсус IBFT, струва си да споменете кога и защо някой би искал да използва IBFT. В публичен блокчейн краткият отговор вероятно няма да го направите. Но що се отнася до консорциум или частни блокчейни, IBFT започва да изглежда доста привлекателен.

Алгоритъмът PoW е ​​изключително скъп както за хардуер, така и за електричество. Тази цена е умишлена, за да попречи на никого да поеме лесно мрежата и по този начин PoW е ​​много подходяща за ситуации с пълна децентрализация, където всеки (включително нападателите) може да участва. Възлите в консорциума / частните вериги, използвани от предприятията, обаче са по същество по-доверени от тези в публичната верига. Като такъв, механизмът за консенсус на PoW може да бъде прекалено обременителен, а други механизми могат да осигурят „достатъчно“ доверие за управление на разпределена система.

Доказателството за залог също може да е по-малко подходящо за предприятията, тъй като плащането на газ е по-малко важно в разрешената мрежа. Тъй като възлите не (задължително) трябва да поддържат валута в мрежата, PoS ще въведе външни изисквания.

Имайки предвид тези компромиси, Proof of Authority (PoA) се очертава като възможно най-доброто решение, използвайки система, чрез която възлите в мрежата получават привилегията да произвеждат нови блокове за веригата с помощта на кръг или друга произволна система.

IBFT е един от многото вкусове на PoA и осигурява следните предимства:

  • Незабавна окончателност на блока. Предлага се само 1 блок при дадена височина на веригата. По този начин единичната верига премахва разклоняването, блокирането на чичо и риска, че транзакцията може да бъде „отменена“ веднъж по веригата по-късно.
  • Намалено време между блоковете. Усилията, необходими за конструиране и валидиране на блокове, са значително намалени (по-специално по отношение на PoW), значително увеличавайки производителността на веригата.
  • Висока цялост на данните и толерантност към грешки. IBFT използва група валидатори, за да осигури целостта на всеки предложен блок. Свръх мнозинство (~ 66%) от тези валидатори трябва да подпишат блока преди вмъкването във веригата, което прави фалшифицирането на блока много трудно. „Ръководството“ на групата също се върти във времето – гарантирайки, че дефектният възел не може да упражнява дългосрочно влияние върху веригата.
  • Оперативно гъвкав. Групата на валидаторите може да бъде модифицирана навреме, като се гарантира, че групата съдържа само напълно надеждни възли.

Тук предоставихме общ преглед на IBFT, най-вече нетехнически. За някои от оригиналните предложения на IBFT можете да прегледате EIPs на GitHub:

В останалата част на тази статия ще проучим по-техническите съображения на IBFT, като обсъдим много от концепциите, открити в EIP, и които сме научили чрез нашето собствено изследване.


Забележка: IBFT кодът може да бъде намерен и в заявка за изтегляне на go-ethereum # 16385.

Операция

Механизмът за консенсус IBFT включва следните компоненти:

  1. A PBFT вдъхновен групов консенсус модел.
  2. Процес, чрез който членовете могат да бъдат добавени / премахнати от проверяващата група.

IBFT изисква заглавката на блока да бъде (прецизно) преработена, за да поддържа всички аспекти на възможността.

Модел на групов консенсус

Общ преглед

IBFT използва пул от валидиращи възли (валидатори), работещи в мрежа на Ethereum, за да определи дали предложеният блок е подходящ за добавяне към веригата.

Един възел на валидаторите е произволно избран като предложител и е отговорен за изграждането на блок в блоковия интервал и споделянето на споменатия блок с групата. Ако супер-мнозинството от валидаторите счете блока за валиден, той се добавя към блокчейна.

При завършване на консенсусния кръг Валидаторите могат да изберат нов Предложител, който ще бъде отговорен за предоставяне на кандидат Блок на следващия интервал на блока.

Механизмът за консенсус е синхронизиран автомат на състоянието, който е отговорен за гарантиране, че всички валидатори добавят един и същ блок към веригата на една и съща височина.

Ако даден блок не успее да се вмъкне, Предложителят се променя и процесът започва отново.

За да се гарантира, че само един блок може да бъде добавен към държавната машина, IBFT предотвратява промяната на предложения блок, след като свръх-мнозинството от валидаторите се съгласят за вмъкването му (но не са извършили споменатата работа), този процес се нарича „Блокиране на блока“.

Механизмът за консенсус IBFT предлага стабилност на системата, при условие че по-малко от 1/3 от валидиращите възли се държат неправилно (или поради компрометиране, или поради дефектен код). Т.е. за толериране на F дефектни възли групата за проверка трябва да съдържа поне 3F + 1 възли (повече от това не увеличава целостта на системата).

Забележка: Тук F предполага броя на дефектните възли, допустими от системата.

Държавна машина

Държавна машина на IBFT

Държави
  • Очаква предложение. Валидаторът чака нов блок да бъде предоставен от настоящия предложител. Ако валидаторът е предложител за този кръг, те подготвят предложения блок и го предават в съобщение за предварителна подготовка.
  • Приготвяне. Получил е (валиден) предложен блок и уведомил валидатор-партньори; сега чака валидаторите да уведомят за приемането на блока.
  • Готов. Получи приемане на блок от валидатор и очаква да бъдат в подобна позиция. На този етап предложеният блок е „заключен“ и не може да бъде заменен, докато не бъде извършен опит за вмъкване.
  • Кръгла промяна. Кръгът изтече, преди да бъде постигнат консенсус или блокът не успя да вмъкне. Изчакайте всички валидатори да се споразумеят за номера на следващия кръг.
Преходи
  1. Aизчакване Предложение → Подготовка. При получаване на нов блок (Подгответе съобщение) от предлагащия (т.е. блокът е валиден в съдържанието си, както и предложената точка за вмъкване на веригата).
  2. Очаквано предложение → Кръгла промяна. Полученото предложение не е валиден блок според даден набор от правила (напр. Невалиден предложител, неправилно номериране на кръг).
  3. Подготовка → Готов. При получаване на известия 2F + 1 (Подготвяне на съобщение) от валидатори, показващи, че предложеният блок е подходящ за вмъкване.
  4. Готово → Очаквано предложение. При получаване на 2F + 1 известия (съобщение за ангажиране) от валидатор-връстници, показващи, че са готови да добавят блока към веригата. При преход се извършва процесът на добавяне на блока към веригата (успех).
  5. Готово → Кръгла промяна. Според Ready->В очакване на предложението обаче вмъкването на блок е неуспешно.
  6. Кръгла промяна → Очаква предложение. 2F + 1 от валидаторите се съгласяват да се използва следващият кръг.

Забележка: Всички преходи в “RoundChange” водят до това, че валидаторът изпраща съобщение “RoundChange” на своите валидатори-връстници.

Заключване на блокове

IBFT разрешава да не се създават разклонения. За тази цел, след като блок е договорен с мнозинство (т.е. при влизане в състояние на готовност), той става „заключен“.

Това означава, че няма да се вземат предвид други блокове за вмъкване, докато не се направи опит за добавяне на този блок към веригата. По този начин или блокът се вмъква успешно (след като бъдат получени достатъчно съобщения за фиксиране, или в този, или в следващите кръгове), или блокът не успее да се вмъкне, се отхвърля и се предлага нов блок на текущата височина на веригата.

Членство в групата за валидиране

Членовете на групата за валидиране могат да се променят с течение на времето чрез механизъм за гласуване. Членовете могат да бъдат добавени или отстранени чрез мнозинство (Етаж (N / 2) + 1) гласуване; всеки глас се улавя в заглавката на блока.

Всеки възел в мрежата (включително непроверяващи възли) е отговорен за проследяване на броя на гласовете за всеки валидатор, за да се определят текущите валидатори и да се гарантира, че подписите върху минните блокове попадат в очакваната група.

Като се има предвид, че всеки глас се съдържа в заглавката на блока, само вносителят на даден кръг може да гласува. Поради това е важно, ако възлите трябва да бъдат добавени / премахнати своевременно, ролята на предложенията да се актуализира редовно.

След като един възел достигне мнозинство гласове, те незабавно се присъединяват / напускат групата на валидатора.

IBFT признава Епоха на гласуване, която определя точка, при която всички гласове, които все още не са достигнали мнозинство, се премахват, което налага принудителното подбиране на гласовете. Това предполага, че при преброяване на гласовете валидаторите трябва да започнат само в най-новата епоха. По подразбиране гласуващата епоха се случва на всеки 30 000 блока.

Гласовете определят промяна на състоянието (т.е. кандидатите се гласуват, валидаторите се гласуват), ако не се гласува за даден възел означава, че валидаторът не желае възелът да променя състоянието си (не е необходимо изрично гласуване, за да се запази статуквото).

Рефактор на заглавката на блока

За да се поддържа IBFT в Ethereum, трябва да се направят редица промени в блоковите заглавки. Тези промени включват:

  • бенефициент: идентифицира възела, за който се гласува.
  • nonce: определя гласуването “посока” – AUTH или DROP.
  • mixHash: фиксирано магическо число, идентифициращо този блок като потвърден от IBFT.
  • ommersHash: трябва да е хеш на празен набор, тъй като няма ommer блокове, когато работи под IBFT.
  • timestamp: трябва да бъде поне времевата марка + интервал на блока на родителския блок.
  • трудност: трябва да се попълни с 0x0000000000000001.
  • extraData: съдържа специфични за IBFT данни, включително списък с адреси за валидатор, ProposerSeal (идентифицира предложителя), CommtingSeals (списък на валидаторите, които са докладвали „ангажиране“ на този блок).

Тъй като списъкът на CommitingSeals за всеки валидатор е (потенциално) различен, важно е хешът на блока да не включва тази информация – т.е. въпреки че два блока имат различни полета CommitingSeals, те представляват една и съща информация (т.е. транзакциите и т.н. са идентични).

Заключение

В заключение IBFT е византийско толерантно решение, предлагащо незабавна окончателност на транзакциите, което намалява необходимата инфраструктура, която PoW изисква.

Макар че е малко вероятно да бъде използван някога в основната мрежа на Ethereum (с много по-широкия, неизвестен набор от участващи актьори), той предлага значителна полза, когато се използва в частна верига, където пулът на валидатора има доверие и отговорност; осигурява идеално решение за верига с фиксиран каданс и предвидима скорост на обработка на транзакциите.

Процесите, изследвани в тази статия, дават увереност, че мрежа, използваща IBFT, ще бъде толерантна към византийските възли и може да бъде възстановена, ако тези възли упражняват контрол върху мрежата.

Абонирайте се за нашия бюлетин за най-новите новини за Ethereum, корпоративни решения, ресурси за разработчици и др. Имейл адрес Изключително съдържаниеПълно ръководство за бизнес мрежи на BlockchainРъководство

Пълно ръководство за бизнес мрежи на Blockchain

Въведение в токенизациятаУебинар

Въведение в токенизацията

Бъдещето на финансите Digital Assets и DeFiУебинар

Бъдещето на финансите: цифрови активи и DeFi

Какво е Enterprise EthereumУебинар

Какво е Enterprise Ethereum?

Централни банки и бъдещето на паритеБяла хартия

Централни банки и бъдещето на парите

Komgo Blockchain за търговия със стокиДело Stud

Komgo: Блокчейн за търговия със стоки

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