Любимият въпрос на всеки нетехнически специалист за всяка дистрибутивна система е "Колко tps има вашият блокчейн?". Въпреки това, числото, посочено в отговор, обикновено няма нищо общо с това, което въпросът иска да чуе. Всъщност, той иска да попита "подходи ли вашият блокчейн за моите бизнес изисквания", а тези изисквания не са едно число, а множество условия — от отказоустойчивост на мрежата до изисквания за финализация, размери, характер на транзакциите и много други параметри. Така че, отговорът на въпроса "колко tps" едва ли ще бъде прост и почти никога няма да бъде пълен. Дистрибутивна система с десетки и стотици възли, които извършват доста сложни изчисления, може да се намира в огромно количество различни състояния, свързани със състоянието на мрежата, съдържанието на блокчейна, технически неизправности, икономически проблеми, атаки срещу мрежата и много други причини. Етапите, на които могат да възникнат проблеми с производителността, се различават от традиционните услуги, а сървърът на блокчейн мрежата е мрежова услуга, която комбинира функционалността на база данни, уеб сървър и торент клиент, което го прави изключително сложен по отношение на профила на натоварването за всички подсистеми: процесор, памет, мрежа, хранилище.

Станало е така, че децентрализираните мрежи и блокчейни са доста специфичен и необичаен софтуер за разработчиците на централизирано ПО. Затова бих искал да подчертая важните аспекти на производителността и устойчивостта на децентрализираните мрежи, подходите към тяхното измерване и намирането на bottlenecks. Ще разгледаме различни проблеми с производителността, които ограничават скоростта на предоставяне на услугите на потребителите на блокчейни и ще отбележим особеностите, присъщи за този вид софтуер.

Етапите на заявка за услуга от клиента на блокчейна

За да се говори честно за качеството на всяка по-сложна услуга, е необходимо да се вземат предвид не само средните стойности, но и максималните/минималните, медианите, перцентилите. Теоретично, може да се говори за 1000 tps в някой блокчейн, но ако 900 транзакции са изпълнени с огромна скорост, а 100 — "зависнали" за няколко секунди, то средното време, събрано от всички транзакции — не е напълно честна метрика за клиента, който не можа да завърши сделката си за няколко секунди. Временните "ями", предизвикани от пропуснати кръгове на консенсуса или разделяне на мрежата, могат да развалят сериозно услугата, която на тестовите стендове показваше отлична производителност.

За да се идентифицират такива bottleneck-ове, е необходимо да се разберат добре етапите, на които реалният блокчейн може да изпитва затруднения при обслужването на потребителите. Нека опишем цикъла на доставка и обработка на транзакцията, както и получаването на новото състояние на блокчейна, от което клиентът може да се увери, че неговата транзакция е била обработена и отчетена.

транзакцията се формира на клиента
транзакцията се подписва на клиента
клиентът избира една от нодовете и изпраща в нея своята транзакция
клиентът подписва за актуализации на state database на нода, очаквайки появата на резултатите от изпълнението на своята транзакция
нодата разпространява транзакцията в p2p мрежата
няколко или един BP (block producer) обработват натрупаните транзакции, актуализирайки state database
BP формира нов блок, след като обработи нужното количество транзакции
BP разпространява новия блок в p2p мрежата
новият блок се доставя до нода, към която се обръща клиентът
нодата актуализира state database
нодата вижда актуализация, касаеща клиента, и изпраща му уведомление за транзакцията

Сега нека по-подробно разгледаме тези етапи и опишем потенциалните проблеми с производителността на всеки етап. В отличие от централизирани системи, ние също така ще разгледаме изпълнението на кода на клиентите в мрежата. Достатъчно често при измерване на tps времето за обработка на транзакции се събира от нодове, а не от клиента — това не е съвсем честно. Клиентът не се интересува колко бързо нодът е обработил неговата транзакция, най-важното за него е моментът, когато надеждната информация за тази транзакция, включена в блокчейна, стане достъпна за него. Именно тази метрика всъщност е времето за изпълнение на транзакцията. Това означава, че различните клиенти, дори изпращайки една и съща транзакция, могат да получат напълно различни времена, които зависят от канала, натовареността и близостта на нода и т.н. Затова е абсолютно необходимо да измерваме това време на клиентите, тъй като именно този параметър трябва да се оптимизира.

Подготовка на транзакцията на страната на клиента

Нека започнем с първите два пункта: транзакцията се формира и подписва от клиента. Както и странно да звучи, това също може да бъде bottleneck на производителността на блокчейна от гледна точка на клиента. Това е необичайно за централизирани услуги, които вземат на себе си всички изчисления и операции с данни, а клиентът просто подготвя кратко запитване, способно да иска голям обем от данни или изчисления, получавайки готов резултат. В блокчейните клиентският код става все по-мощен, а ядро на блокчейна — все по-леко, като масивни изчислителни задачи се предават на клиентския софтуер. В блокчейните съществуват клиенти, които могат да подготвят една транзакция доста дълго (говоря за различни merkle proof-и, succinct proof-и, threshold подписи и други сложни операции на страната на клиента). Добър пример за лесна on-chain верификация и тежка подготовка на транзакция на клиента е доказателството за принадлежност към списък на базата на Merkle-дерево, ето статия.

Също така не трябва да се забравя, че клиентският код не просто изпраща транзакции в блокчейна, а първо запитва състоянието на блокчейна — а тази дейност може да повлияе на натовареността на мрежата и блокчейн възлите. Затова, при провеждане на измервания, разумно е да се емулира по възможно най-пълен начин поведението на клиентския код. Дори когато във вашия блокчейн има обикновени лесни клиенти, които слагат обикновен цифров подпис на най-простата транзакция за прехвърляне на някакъв актив, с всяка година обемът на изчисленията на клиента все пак става все по-голям, криптоалгоритмите се укрепват, и тази част от процесинга може да се превърне в значителен тясно място в бъдеще. Затова бъдете внимателни и не пропускайте ситуацията, когато в транзакция, продължаваща 3.5s, 2.5s отиват за подготовка и подписване на транзакцията, а 1.0s за изпращане в мрежата и изчакване на отговор. За оценка на рисковете от появата на това тясно място е необходимо да се събират метрики от клиентските машини, а не само от блокчейн възлите.

Изпращане на транзакция и мониторинг на нейния статус

Следващата стъпка е изпращането на транзакцията в избрания блокчейн възел и получаването на статус за приемането й в пул транзакции. Тази стъпка е подобна на обикновеното обращение към база данни, възелът трябва да запише транзакцията в пула и да започне да разпространява информация за нея през p2p мрежата. Подходът за оценка на производителността тук е подобен на оценката на работата на традиционните микросервизи Web API, като самите транзакции в блокчейните могат да се актуализират и активно да сменят статус. Всъщност, актуализацията на информацията за транзакция в някои блокчейни може да се случи няколко пъти, например при превключване между клонове на веригата или когато BP съобщават за намерението си да включат транзакцията в блок. Ограниченията за обема на този пул и броя на транзакциите в него могат да оказват влияние върху производителността на блокчейна. Ако пулът транзакции е запълнен до максималния си размер или не се побира в оперативната памет — производителността на мрежата може рязко да падне. Блокчейните нямат централизирани средства за защита от потока на боклук съобщения и, ако блокчейнът поддържа транзакции с голям обем и ниски такси, това може да доведе до пренаселване на пула на транзакции — това е още едно потенциално тясно място за производителността.

В блокчейн системите клиентът изпраща транзакция до всяка нода, която му харесва. Хешът на транзакцията обикновено е известен на клиента още преди изпращането, така че всичко, което му е нужно, е да установи връзка и след изпращането да изчака блокчейнът да промени своето състояние, включвайки транзакцията. Забележете, че при измерването на "tps" може да получите напълно различни резултати в зависимост от начина на свързване към нодата на блокчейна. Това може да бъде обикновен HTTP RPC или WebSocket, което позволява реализирането на патерна "subscribe". Във втория случай клиентът ще получи известие по-рано, а нодата ще изразходва по-малко ресурси (главно памет и трафик) за отговори относно състоянието на транзакцията. Следователно, при измерването на "tps" е необходимо да се вземе предвид методът на връзка на клиентите с нодите. Затова, за оценка на рисковете от появата на това bottleneck, бенчмаркът на блокчейна трябва да може да емулира клиенти и с WebSocket, и с HTTP RPC заявки, в пропорции, съответстващи на реалните мрежи, а също така да променя характера на транзакциите и техния размер.

За оценка на рисковете от появата на този bottleneck е необходимо също да се събират метрики от клиентските машини, а не само от блокчейн нодовете.

Предаване на транзакции и блокове по p2p мрежа

В блокчейните за предаване на транзакции и блокове между участниците се използва peer-to-peer (p2p) мрежова свързаност. Транзакциите се разпространяват в мрежата, започвайки от една от нодите, докато не достигнат до peer-овете - производители на блокове, които опаковат транзакциите в блокове и с помощта на същата p2p мрежа разпространяват новите блокове до всички ноди в мрежата. Основата на повечето съвременни p2p мрежи са различни модификации на протокола Kademlia. Ето добро кратко обобщение на този протокол, а ето — статия с различни измервания в мрежата BitTorrent, от която може да се разбере — че този тип мрежи е по-сложен и по-малко предсказуем от стриктно конфигурирана мрежа на централен сервис. Също така, ето статия относно измерването на различни интересни метрики за нодовете на Ethereum.

Ако накратко, всеки peer в такива мрежи поддържа свой собствен динамичен списък на други peer-ове, от които иска блокове информация, адресирани по съдържание. При получаване на заявка, peer-ът или предоставя необходимата информация, или предава заявката на следващия псевдослучаен peer от списъка, а след като получи отговор, го предава на запитващия и за известно време го кешира, предоставяйки този блок информация по-рано следващия път. Така популярната информация се оказва в голям брой кешове при множество peer-ове, а непопулярната постепенно се изтласква. Peer-овете водят сметка кой на кого колко е предал информация, а мрежата се опитва да стимулира активните разпространители, повишавайки техния рейтинг и осигурявайки им по-високо ниво на услуга, автоматично изключвайки неактивни участници от списъците с peer-ове.

И така, транзакцията сега трябва да се разпространи в мрежата, за да я видят block-producer-ите и да я включат в блока. Нодата активно "раздава" новата транзакция на всички желаещи и слуша мрежата, изчаквайки блок, в индекса на който ще се появи нужната транзакция, за да уведоми очакващия клиент. Времето, за което мрежата прехвърля информация помежду си за нови транзакции и блокове в p2p мрежите зависи от много фактори: броя на честните, работещи наблизо (от мрежова гледна точка) ноди, "загряването" на кешовете на тези ноди, размера на блоковете, транзакциите, характера на промените, географията на мрежата, броя на нодовете и много други фактори. Комплексните измервания на метриките за производителност в такива мрежи са сложна работа; необходимо е едновременно да се оценяват времето за обработка на заявките и на клиентите, и на peer-овете (блокчейн нодовете). Проблемите в някой от p2p механизмите, неправилното изтласкване и кеширане на данни, неефективното управление на списъците с активни peer-ове и множеството други фактори могат да причинят закъснения, влияещи на ефективността на цялата мрежа като цяло, и този bottleneck е най-сложен за анализ, тестване и интерпретиране на резултатите.

Обработка на веригата от блокове и обновяване на state database

Най-важната част от работата на блокчейн е алгоритъмът на консенсуса, неговото приложение към новите блокове, получени от мрежата, и обработката на транзакции с записване на резултатите в state database. Добавянето на нов блок в веригата и последващият избор на основната верига трябва да работят максимално бързо. Въпреки това, в реалния живот „трябва“ не означава „работи“, и може, например, да си представим ситуация, в която две дълги конкуриращи се вериги постоянно превключват помежду си, променяйки метаданните на хиляди транзакции в пула при всяко превключване и извършвайки постоянни откати на състоянието на state database. Тази стъпка по отношение на определянето на bottleneck е по-лесна от мрежовия p2p слой, тъй като изпълнението на транзакции и алгоритмът на консенсуса са строго детерминирани, и измерването на нещо тук е по-лесно.
Основното е да не объркате случайната деградация на производителността на тази стъпка с проблеми в мрежата — възлите (нодите) бавят предаването на блокове и информация за основната верига и за външния клиент това може да изглежда като бавна мрежа, докато проблемът е съвсем в друга посока.

За оптимизиране на производителността на този етап е полезно да се събират и наблюдават метрики от самите възли и да се включват тези, които касаят обновяването на state-database: брой блокове, обработвани на възела, техният размер, брой транзакции, количество превключвания между форкове на веригите, брой невалидни блокове, време на работа на виртуалната машина, време за фиксиране на данни и т.н. Това ще помогне да не се объркват мрежовите проблеми с грешки в алгоритмите за обработка на веригите.

Процесиращата транзакции виртуална машина може да бъде полезен източник на информация, способен да оптимизира работата на блокчейна. Количеството алокации на памет, брой read/write инструкции и други метрики, свързани с ефективността на изпълнението на кода на контрактите могат да предоставят много полезна информация на разработчиците. В същото време, смарт-контрактите – това са програми, и следователно, те теоретично могат да консумират всякакви ресурси: cpu/memory/network/storage, така че обработката на транзакции е доста неопределен етап, който в допълнение силно се променя при преминаване между версии и при промяна на кода на контрактите. Поради това метриките, свързани с обработката на транзакции, също са необходими за ефективна оптимизация на производителността на блокчейна.

Получаване на уведомление от клиента за включване на транзакция в блокчейн

Това е завършващият етап в получаването на услугата от клиента на блокчейна, в сравнение с другите етапи, тук няма големи разходи, но все пак е важно да се вземе предвид възможността клиентът да получи обширен отговор от нодата (например смарт-контракт, който връща масив от данни). В какъвто и случай, точно този момент е най-важният за тези, които задават въпроса „колко tps е в вашия блокчейн?“, тъй като именно в този момент се записва времето за получаване на услугата.

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

Заключение

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

криптографски преобразования, създаване на доказателства
peer-to-peer мрежи, репликация на транзакции и блокове
обработка на транзакции, изпълнение на смарт-контракти
прилагане на промени в блокчейна към state database, актуализация на данни за транзакции и блокове
read-only заявки към state database, API на блокчейн нода, услуги за абонамент

Всъщност техническите изисквания към нодовете в съвременните блокчейни са изключително сериозни - това са бързи CPU за криптография, голямо количество оперативна памет, за да се съхраняват и бързо достъпват state database, мрежова свързаност с голям брой едновременно отворени връзки, значителен storage. Такива високи изисквания и множеството различни типове операции неизбежно водят до ситуации, в които ресурсите на нодовете могат да са недостатъчни, и тогава всеки един от описаните по-горе етапи може да стане следващото bottleneck за общата производителност на мрежата.

При разработването и оценката на производителността на блокчейни, трябва да се вземат предвид всички тези аспекти. За целта е необходимо да се събират и анализират метрики едновременно от клиентите и възлите на мрежата, да се търсят корелации между тях, да се оценява времето за предоставяне на услугите на клиентите, да се вземат предвид основните ресурси: cpu/memory/network/storage, и да се разбере как те се използват и влияят помежду си. Всичко това прави сравнението на скоростите на различните блокчейни под формата на „колко TPS“ изключително трудоемко, тъй като съществува огромно количество различни конфигурации и състояния. В големите централизирани системи, клъстери от стотици сървъри, тези проблеми също са сложни и изискват събиране на множество различни метрики, но в блокчейни, заради p2p мрежите, виртуалните машини и съдържащите се в тях контракти, вътрешната икономика, броят на степените на свобода е значително по-голям, което прави тестуването дори на няколко сървъра ненадеждно и показващо само много приблизителни стойности, почти без връзка с реалността.

Затова, при разработването в ядрата на блокчейна, за оценка на производителността и отговор на въпроса „поправило ли се е в сравнение с предишния път“ ние използваме доста сложен софтуер, който оркестрира старта на блокчейна с десетки възли и автоматично стартиране на бенчмарка и събиране на метрики; без тази информация е изключително трудно да се отстраняват проблеми с протоколите, работещи с множество участници.

Така че, когато получите въпрос „колко TPS в вашия блокчейн?“, предложете на събеседника чай и уточнете дали е готов да се запознае с десетина графики, както и да изслуша всички три кутии проблеми с производителността на блокчейните и вашите предложения за тяхното решаване…

Източник: habr.com