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

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

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

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

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

1. транзакцията се формира на клиента
2. транзакцията се подписва на клиента
3. клиентът избира един от нодовете и изпраща транзакцията си към него
4. клиентът се подписва за обновления на state database на нода, очаквайки резултатите от изпълнението на транзакцията си
5. нодът разпространява транзакцията в p2p мрежата
6. няколко или един BP (block producer) обработват натрупаните транзакции, обновявайки state database
7. BP формира нов блок, обработвайки нужния брой транзакции
8. BP разпространява новия блок в p2p мрежата
9. новият блок достига до нода, до който се обръща клиентът
10. нодът обновява state database
11. нодът вижда обновлението, касаещо клиента, и му изпраща уведомление за транзакцията

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

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

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

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

Изпращане на транзакция и наблюдение на нейния статус

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

В блокчейните клиент изпраща транзакция към всяка желана от него нода на блокчейна. Хешът на транзакцията обикновено е известен на клиента преди изпращането, така че всичко, което той трябва да направи, е да осигури свързване и след предаване да чака блокчейнът да промени състоянието си, включвайки неговата транзакция. Забележете, че измервайки "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-ите.

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

Процесинг на верига от блокове и обновление на state database

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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