Дистрибуирани регистар за групе точкова: Искуство са Хиперледгер Фабриц-ом

Поштовани, радим у тиму пројекта ДРД КП (дистрибуисани регистар података за праћење животног циклуса точкова). Овде желим да поделим искуство нашег тима у развоју пословног блоцкцхаина за овај пројекат под ограничењима технологије. Углавном ћу говорити о Хиперледгер Фабриц-у, али приступ који је овде описан може се екстраполирати на било који дозвољени блоцкцхаин. Крајњи циљ нашег истраживања је да припремимо корпоративна блокчејн решења тако да финални производ буде пријатан за коришћење и није превише тежак за одржавање.

Неће бити открића, неочекиваних решења, нити ће овде бити истакнути јединствени развоји (јер ја их немам). Само желим да поделим своје скромно искуство, да покажем да је „било могуће“ и, можда, у коментарима прочитам о искуствима других људи о доношењу добрих и не баш добрих одлука.

Проблем: Блоцкцхаинс се још не скалирају

Данас су напори многих програмера усмерени на то да блоцкцхаин буде заиста згодна технологија, а не темпирана бомба у прелепом омоту. Државни канали, оптимистични роллуп, плазма и шардинг ће вероватно постати уобичајени. Једног дана. Или ће можда ТОН поново одложити лансирање за шест месеци, а следећа Пласма група ће престати да постоји. Можемо да верујемо у следећу мапу пута и да читамо сјајне беле књиге ноћу, али овде и сада морамо нешто да урадимо са оним што имамо. Уради срање.

Задатак који је постављен нашем тиму у тренутном пројекту генерално изгледа овако: има много субјеката, који достижу неколико хиљада, који не желе да граде односе на поверењу; Неопходно је изградити решење на ДЛТ-у које ће радити на обичним рачунарима без посебних захтева за перформансама и обезбедити корисничко искуство ништа горе од било ког централизованог рачуноводственог система. Технологија која стоји иза решења мора да минимизира могућност злонамерне манипулације подацима – зато је блокчејн овде.

Слогани из белих књига и медија обећавају нам да ће нам следећи развој омогућити да правимо милионе трансакција у секунди. Шта је то заиста?

Маиннет Етхереум тренутно ради на ~30 тпс. Само због овога, тешко га је перципирати као блоцкцхаин на било који начин погодан за корпоративне потребе. Међу дозвољеним решењима постоје бенцхмаркови који показују 2000 тпс (Кворум) или 3000 тпс (Хиперледгер Фабриц, има нешто мање у публикацији, али морате узети у обзир да је бенцхмарк спроведен на старом консензус мотору). Био покушај радикалне обраде тканине, који је дао не најгоре резултате, 20000 тпс, али за сада је ово само академско истраживање које чека своју стабилну примену. Мало је вероватно да ће корпорација која може себи да приушти одржавање одељења блокчејн програмера поднети такве показатеље. Али проблем није само пропусност, већ постоји и кашњење.

Латентност

Кашњење од тренутка када је трансакција покренута до њеног коначног одобрења од стране система зависи не само од брзине којом порука пролази кроз све фазе валидације и наручивања, већ и од параметара формирања блока. Чак и ако нам наш блоцкцхаин дозвољава да се обавежемо брзином од 1000000 тпс, али је потребно 10 минута да генеришемо блок од 488 МБ, да ли ће нам то постати лакше?

Хајде да ближе погледамо животни циклус трансакције у Хиперледгер Фабриц-у да бисмо разумели где се време троши и како је повезано са параметрима генерисања блокова.

преузето одавде: хиперледгер-фабриц.реадтхедоцс.ио/ен/релеасе-1.4/арцх-дееп-диве.хтмл#свимлане

(1) Клијент креира трансакцију, шаље је вршњацима који подржавају, они симулирају трансакцију (примењују промене направљене ланчаним кодом на тренутно стање, али не обавезују се на књигу) и примају РВСет - имена кључева, верзије и вредности ​​преузето из колекције у ЦоуцхДБ-у, (2) индосанти шаљу назад потписани РВСет клијенту, (3) клијент или проверава присуство потписа свих потребних пеер-а (индосатора), а затим шаље трансакцију служби за наручивање , или га шаље без верификације (провера ће се ипак обавити касније), услуга наручивања формира блок и (4) шаље назад свим колегама, а не само индосантима; колеге проверавају да ли се верзије кључева у скупу за читање поклапају са верзијама у бази података, да ли сви индосанти имају потписе и коначно урезују блок.

Али то није све. Речи „наручилац формира блок“ сакривају не само редослед трансакција, већ и 3 узастопна мрежна захтева од лидера до пратилаца и назад: лидер додаје поруку у дневник, шаље је пратиоцима, ови је додају у њихов дневник, шаље потврду успешне репликације лидеру, вођа урезује поруку, шаље потврду урезивања пратиоцима, пратиоци се урезују. Што је мања величина и време формирања блока, то ће служба за наручивање чешће морати да успостави консензус. Хиперледгер Фабриц има два параметра за формирање блока: БатцхТимеоут - време формирања блока и БатцхСизе - величина блока (број трансакција и величина самог блока у бајтовима). Чим један од параметара достигне границу, нови блок се ослобађа. Што више чворова налога, то ће дуже трајати. Према томе, морате повећати БатцхТимеоут и БатцхСизе. Али пошто су РВСетови верзионисани, што већи блок направимо, већа је вероватноћа МВЦЦ конфликта. Поред тога, како се БатцхТимеоут повећава, УКС се катастрофално деградира. Следећа шема за решавање ових проблема ми се чини разумном и очигледном.

Како избећи чекање на финализацију блока и не изгубити могућност праћења статуса трансакције

Што је дуже време формирања и величина блока, то је већа пропусност блок ланца. Једно не следи директно из другог, али треба имати на уму да успостављање консензуса у РАФТ-у захтева три мрежна захтева од лидера до следбеника и назад. Што више чворова налога, то ће дуже трајати. Што је мања величина и време формирања блока, то је више таквих интеракција. Како повећати време генерисања и величину блока без повећања времена одзива система за крајњег корисника?

Прво, морамо некако да решимо МВЦЦ конфликте изазване великом величином блока, која може укључивати различите РВСетове са истом верзијом. Очигледно, на страни клијента (у вези са блокчејн мрежом, ово би могло бити позадински део, и мислим то) треба вам МВЦЦ обрађивач конфликта, који може бити или засебна услуга или обичан декоратор изнад позива који иницира трансакцију са логиком поновног покушаја.

Поновни покушај се може применити са експоненцијалном стратегијом, али ће се латенција деградирати исто тако експоненцијално. Дакле, требало би да користите или насумични поновни покушај у одређеним малим границама или константан. Са оком на могуће колизије у првој опцији.

Следећи корак је да интеракцију клијента са системом учинимо асинхроном тако да не чека 15, 30 или 10000000 секунди, што ћемо поставити као БатцхТимеоут. Али у исто време, неопходно је задржати могућност да се провери да ли промене инициране трансакцијом су/нису забележене у блок ланцу.
База података се може користити за чување статуса трансакције. Најједноставнија опција је ЦоуцхДБ због своје лакоће коришћења: база података има кориснички интерфејс из кутије, РЕСТ АПИ и лако можете да подесите репликацију и дељење за њу. Можете једноставно да креирате засебну колекцију у истој ЦоуцхДБ инстанци која користи Фабриц за складиштење свог светског стања. Морамо да чувамо ове врсте докумената.

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

Овај документ се уписује у базу података пре него што се трансакција пошаље колегама, ИД ентитета се враћа кориснику (исти ИД се користи као кључ) ако је ово операција креирања, а затим се поља Статус, ТкИД и Еррор ажурирају како се релевантне информације добијају од колега.

У овој шеми, корисник не чека да се блок коначно формира, гледајући точак који се окреће на екрану 10 секунди, он добија тренутни одговор од система и наставља да ради.

Одабрали смо БолтДБ за чување статуса трансакција јер морамо да уштедимо меморију и не желимо да губимо време на мрежну интеракцију са засебним сервером базе података, посебно када се ова интеракција одвија коришћењем протокола обичног текста. Успут, било да користите ЦоуцхДБ за имплементацију горе описане шеме или једноставно за складиштење стања света, у сваком случају има смисла оптимизовати начин на који се подаци чувају у ЦоуцхДБ-у. Подразумевано, у ЦоуцхДБ-у, величина чворова б-стабла је 1279 бајтова, што је много мање од величине сектора на диску, што значи да ће и читање и поновно балансирање стабла захтевати више физичког приступа диску. Оптимална величина одговара стандарду Напредни формат и износи 4 килобајта. Да бисмо оптимизовали, морамо да подесимо параметар бтрее_цхунк_сизе једнака 4096 у конфигурационој датотеци ЦоуцхДБ. За БолтДБ таква ручна интервенција није потребно.

Противпритисак: стратегија тампон

Али може бити много порука. Више него што систем може да поднесе, дељење ресурса са десетак других сервиса осим оних приказаних на дијаграму – и све ово би требало да функционише беспрекорно чак и на машинама на којима би покретање Интеллиј Идеа било изузетно заморно.

Проблем различитог капацитета комуникационих система, произвођача и потрошача, решава се на различите начине. Хајде да видимо шта можемо да урадимо.

Дроппинг: Можемо тврдити да смо способни да обрадимо највише Кс трансакција за Т секунди. Сви захтеви који прелазе ово ограничење се одбацују. Ово је прилично једноставно, али онда можете заборавити на УКС.

Контролисање: потрошач мора имати неку врсту интерфејса преко којег, у зависности од оптерећења, може да контролише ТПС произвођача. Није лоше, али намеће обавезе програмерима клијента који стварају оптерећење за имплементацију овог интерфејса. То је за нас неприхватљиво, јер ће блокчејн у будућности бити интегрисан у велики број већ дуго постојећих система.

Буфферинг: Уместо да покушавамо да се одупремо улазном току података, можемо да баферујемо овај ток и да га обрадимо потребном брзином. Очигледно је ово најбоље решење ако желимо да пружимо добро корисничко искуство. Бафер смо имплементирали користећи ред у РаббитМК-у.

Две нове акције су додате шеми: (1) након што стигне захтев АПИ-ју, порука са параметрима потребним за позивање трансакције се ставља у ред, а клијент добија поруку да је трансакција прихваћена од стране систем, (2) бацкенд чита податке брзином наведеном у конфигурацији из реда; покреће трансакцију и ажурира податке у складишту статуса.
Сада можете повећати време формирања и блокирати капацитет колико год желите, скривајући кашњења од корисника.

Други алати

Овде ништа није речено о ланчаном коду, јер у њему, по правилу, нема шта да се оптимизује. Цхаинцоде треба да буде што једноставнији и сигурнији - то је све што се од њега тражи. Оквир нам помаже да једноставно и безбедно пишемо ланчани код ЦЦКит од С7 Тецхлаб и статичког анализатора оживети^ЦЦ.

Поред тога, наш тим развија скуп услужних програма који ће рад са Фабриц учинити једноставним и пријатним: блоцкцхаин екплорер, услужни програм за аутоматске промене конфигурације мреже (додавање/уклањање организација, РАФТ чворова), услужни програм за одузимање сертификата и уклањање идентитета. Ако желите да допринесете, добродошли сте.

Закључак

Овај приступ вам омогућава да лако замените Хиперледгер Фабриц са Куорум-ом, другим приватним Етхереум мрежама (ПоА или чак ПоВ), значајно смањите стварну пропусност, али у исто време одржавате нормалан УКС (како за кориснике у претраживачу тако и за интегрисане системе). Када замените Фабриц са Етхереум-ом у шеми, мораћете само да промените логику сервиса/декоратора за поновни покушај са обраде МВЦЦ сукоба на атомско једнократно повећање и поновно слање. Баферовање и складиштење статуса омогућили су да се време одговора одвоји од времена формирања блока. Сада можете додати хиљаде чворова налога и не плашити се да се блокови формирају пречесто и учитавају услугу наручивања.

У суштини, то је све што сам желео да поделим. Биће ми драго ако ово некоме помогне у раду.

Извор: ввв.хабр.цом