Омиљено питање о било ком дистрибуираном систему од стране нетехничара је „Колико је тпс-а на вашем блоцкцхаин-у?“ Међутим, број који се даје у одговору обично нема много заједничког са оним што би питалац желео да чује. У ствари, желео је да пита „да ли ће ваш блок ланац одговарати мојим пословним захтевима“, а ови захтеви нису један број, већ многи услови – овде су толеранција на грешке мреже, захтеви за коначност, величине, природа трансакција и многи други параметри. Дакле, мало је вероватно да ће одговор на питање „колико тпс“ бити једноставан и скоро никада потпун. Дистрибуирани систем са десетинама или стотинама чворова који обављају прилично сложене прорачуне може бити у великом броју различитих стања везаних за стање мреже, садржај блокчејна, техничке кварове, економске проблеме, нападе на мрежу и многе друге разлоге. . Фазе у којима су могући проблеми са перформансама разликују се од традиционалних сервиса, а мрежни сервер блоцкцхаин је мрежни сервис који комбинује функционалност базе података, веб сервера и торрент клијента, што га чини изузетно сложеним у погледу профила оптерећења на свим подсистемима. : процесор, меморија, мрежа, складиште

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

Фазе захтева за услугу од стране блокчејн клијента

Да бисте искрено говорили о квалитету било које мање или више сложене услуге, потребно је узети у обзир не само просечне вредности, већ и максимум/минимум, медијане, перцентиле. Теоретски, можемо говорити о 1000 тпс у неком блокчејну, али ако је 900 трансакција завршено огромном брзином, а 100 је „заглављено“ на неколико секунди, онда просечно време прикупљено за све трансакције није сасвим фер метрика за клијента који нисам могао да завршим трансакцију за неколико секунди. Привремене „рупе“ узроковане пропуштеним рундама консензуса или поделама мреже могу у великој мери да покваре услугу која је показала одличне перформансе на тестним столовима.

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

трансакција се формира на клијенту
трансакција се потписује на клијенту
клијент бира један од чворова и шаље му своју трансакцију
клијент се претплаћује на ажурирања базе података стања чвора, чекајући да се прикажу резултати његове трансакције
чвор дистрибуира трансакцију преко п2п мреже
неколико или један БП (произвођач блокова) обрађује нагомилане трансакције, ажурирајући базу података стања
БП формира нови блок након обраде потребног броја трансакција
БП дистрибуира нови блок преко п2п мреже
нови блок се испоручује чвору којем клијент приступа
чвор ажурира базу података стања
чвор види ажурирање у вези са клијентом и шаље му обавештење о трансакцији

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

Припрема трансакције на страни клијента

Почнимо са прве две тачке: трансакцију формира и потписује клијент. Чудно, ово такође може бити уско грло перформанси блокчејна са становишта клијента. Ово је неуобичајено за централизоване сервисе, који преузимају све прорачуне и операције са подацима, а клијент једноставно припреми кратак захтев који може да захтева велику количину података или прорачуна, добијајући готов резултат. У блокчејновима, клијентски код постаје све моћнији, а језгро блокчејна постаје све лакше, а масивни рачунарски задаци се обично преносе на клијентски софтвер. У блокчејновима постоје клијенти који могу да припремају једну трансакцију доста дуго (говорим о разним меркле доказима, сажетим доказима, граничним потписима и другим сложеним операцијама на страни клијента). Добар пример лаке верификације на ланцу и тешке припреме трансакције на клијенту је доказ чланства у листи заснованој на Меркле-трее, овде чланак.

Такође, не заборавите да клијентски код не шаље једноставно трансакције у блок ланац, већ прво испитује стање блокчејна – и ова активност може утицати на загушење мреже и блокчејн чворова. Дакле, приликом мерења, било би разумно емулирати понашање клијентског кода што је могуће потпуније. Чак и ако у вашем блокчејну постоје обични лаки клијенти који стављају обичан дигитални потпис на најједноставнију трансакцију за пренос неке имовине, сваке године и даље постоје све масовније калкулације на клијенту, крипто алгоритми су све јачи, а овај део обраде може претворити у значајно уско грло у будућности. Зато, будите опрезни и не пропустите ситуацију да се у трансакцији која траје 3.5с потроши 2.5с на припрему и потписивање трансакције, а 1.0с на слање у мрежу и чекање одговора. Да бисте проценили ризике овог уског грла, потребно је да прикупите метрику са клијентских машина, а не само из блокчејн чворова.

Слање трансакције и праћење њеног статуса

Следећи корак је слање трансакције на изабрани блоцкцхаин чвор и добијање статуса прихватања у скуп трансакција. Ова фаза је слична редовном приступу бази података, чвор мора да сними трансакцију у скупу и почне да дистрибуира информације о њој кроз п2п мрежу. Приступ процени перформанси овде је сличан процени перформанси традиционалних микросервиса веб АПИ-ја, а саме трансакције у блок-чејновима могу да се ажурирају и активно мењају свој статус. Уопштено говорећи, ажурирање информација о трансакцијама на неким блоцкцхаин-овима може се десити више пута, на пример када се пребацујете између ланчаних виљушки или када БП најаве своју намеру да укључе трансакцију у блок. Ограничења величине овог пула и броја трансакција у њему могу утицати на перформансе блоцкцхаина. Ако је скуп трансакција попуњен до највеће могуће величине или се не уклапа у РАМ, перформансе мреже могу нагло пасти. Блоцкцхаинс немају централизована средства за заштиту од поплаве нежељених порука, а ако блок ланца подржава велике количине трансакција и ниске накнаде, то може довести до преливања скупа трансакција – још једно потенцијално уско грло у перформансама.

У блоцкцхаин-у, клијент шаље трансакцију на било који блок ланца чвора који жели, хеш трансакције је обично познат клијенту пре слања, тако да све што треба да уради је да успостави везу и, након преноса, сачека да се блоцкцхаин промени њено стање, омогућавајући његову трансакцију. Имајте на уму да мерењем „тпс“ можете добити потпуно различите резултате за различите методе повезивања на блок ланца чвора. Ово може бити обичан ХТТП РПЦ или ВебСоцкет који вам омогућава да примените образац „претплате“. У другом случају, клијент ће добити обавештење раније, а чвор ће потрошити мање ресурса (углавном меморије и саобраћаја) на одговоре о статусу трансакције. Дакле, када се мери „тпс” потребно је узети у обзир начин на који се клијенти повезују са чворовима. Стога, да би проценио ризике овог уског грла, бенчмарк блок ланац мора бити у стању да емулира клијенте са ВебСоцкет и ХТТП РПЦ захтевима, у пропорцијама које одговарају стварним мрежама, као и да промени природу трансакција и њихову величину.

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

Пренос трансакција и блокова преко п2п мреже

У блокчејновима, пеер-то-пеер (п2п) умрежавање се користи за пренос трансакција и блокова између учесника. Трансакције се шире широм мреже, почевши од једног од чворова, све док не стигну до пеер блок произвођача, који пакују трансакције у блокове и, користећи исти п2п, дистрибуирају нове блокове свим чворовима мреже. Основа већине модерних п2п мрежа су различите модификације Кадемлиа протокола. ovde је добар резиме овог протокола, и овде - чланак са различитим мерењима у БитТоррент мрежи, из којег се може разумети да је ова врста мреже сложенија и мање предвидљива од ригидно конфигурисане мреже централизованог сервиса. такође, овде чланак о мерењу различитих занимљивих метрика за Етхереум чворове.

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

Дакле, трансакција сада треба да се дистрибуира широм мреже тако да произвођачи блокова могу да је виде и укључе у блок. Чвор активно „дистрибуира“ нову трансакцију свима и ослушкује мрежу, чекајући блок у чијем индексу ће се појавити потребна трансакција како би обавестио клијента који чека. Време које је потребно мрежи да пренесе информације о новим трансакцијама и блоковима једни другима у п2п мрежама зависи од веома великог броја фактора: броја поштених чворова који раде у близини (са тачке гледишта мреже), „топло- горе” кеша ових чворова, величине блокова, трансакција, природе промена, географије мреже, броја чворова и многих других фактора. Свеобухватна мерења метрике перформанси у таквим мрежама су сложена ствар, потребно је истовремено проценити време обраде захтева и на клијентима и на колегама (блоцкцхаин чворовима). Проблеми у било ком од п2п механизама, нетачно избацивање и кеширање података, неефикасно управљање листама активних пеер-а и многи други фактори могу узроковати кашњења која утичу на ефикасност целе мреже у целини, а ово уско грло је најтеже анализирати , тестирање и тумачење резултата.

Обрада блокчејна и ажурирање базе података стања

Најважнији део блокчејна је алгоритам консензуса, његова примена на нове блокове примљене из мреже и обрада трансакција са евидентирањем резултата у бази података стања. Додавање новог блока у ланац, а затим одабир главног ланца требало би да функционише што је брже могуће. Међутим, у стварном животу, „требало би“ не значи „ради“, а може се, на пример, замислити ситуација у којој се два дуга конкурентска ланца непрестано пребацују између себе, мењајући метаподатке хиљада трансакција у групи на сваком прекидачу , и стално враћање базе података стања. Ова фаза, у смислу дефинисања уског грла, је једноставнија од п2п мрежног слоја, јер извршење трансакције и консензус алгоритам су строго детерминистички, и овде је лакше било шта измерити.
Главна ствар је да не бркате насумичне деградације у перформансама ове фазе са мрежним проблемима - чворови су спорији у испоруци блокова и информација о главном ланцу, а за екстерног клијента ово може изгледати као спора мрежа, иако проблем лежи у сасвим друго место.

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

Виртуелна машина која обрађује трансакције може бити користан извор информација који може оптимизовати рад блоцкцхаина. Број алокација меморије, број инструкција за читање/писање и друге метрике везане за ефикасност извршавања кода уговора могу пружити много корисних информација програмерима. Истовремено, паметни уговори су програми, што у теорији значи да могу да троше било који од ресурса: цпу/меморију/мрежу/складиште, тако да је обрада трансакција прилично неизвесна фаза, која се, поред тога, у великој мери мења када се креће између верзија а при промени шифри уговора. Стога су метрике које се односе на обраду трансакција такође потребне да би се ефективно оптимизовале перформансе блоцкцхаина.

Пријем од стране клијента обавештења о укључивању трансакције у блоцкцхаин

Ово је последња фаза примања услуге блокчејн клијента у поређењу са другим фазама, нема великих режијских трошкова, али ипак вреди размотрити могућност да клијент добије обимни одговор од чвора (на пример, паметни уговор; враћање низа података). У сваком случају, ова тачка је најважнија за онога ко је поставио питање „колико тпс је у вашем блокчејну?“, јер У овом тренутку се бележи време пријема услуге.

На овом месту увек постоји слање пуног времена које је клијент морао да проведе чекајући одговор од блоцкцхаина. То је време када ће корисник чекати потврду у својој апликацији, а то је његова оптимизација главни задатак програмера.

Закључак

Као резултат тога, можемо описати врсте операција које се изводе на блок-чејновима и поделити их у неколико категорија:

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

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

Приликом дизајнирања и процене перформанси блок-чејна, мораћете да узмете у обзир све ове тачке. Да бисте то урадили, потребно је да прикупите и анализирате метрику истовремено од клијената и мрежних чворова, потражите корелације између њих, процените време потребно за пружање услуга клијентима, узмете у обзир све главне ресурсе: цпу/меморију/мрежу/складиште , разумеју како се користе и утичу једни на друге. Све ово чини упоређивање брзина различитих блок ланаца у облику „колико ТПС“ изузетно незахвалним задатком, јер постоји огроман број различитих конфигурација и стања. У великим централизованим системима, кластерима стотина сервера, ови проблеми су такође сложени и такође захтевају прикупљање великог броја различитих метрика, али у блокчејновима, због п2п мрежа, виртуелних машина за обраду уговора, интерне економије, броја степена слободе је много већа, што чини тест чак и на неколико сервера, није индикативан и показује само изузетно приближне вредности које немају скоро никакве везе са стварношћу.

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

Дакле, када добијете питање „колико је ТПС-а у вашем блокчејну?“, понудите саговорнику мало чаја и питајте га да ли је спреман да погледа десетак графикона и саслуша све три кутије проблема са перформансама блокчејна и ваше предлоге за решавање њих...

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

Колико ТПС-а има на вашем блокчејну?