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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Така че транзакцията сега трябва да бъде разпределена в цялата мрежа, така че производителите на блокове да могат да я видят и да я включат в блока. Възелът активно „разпределя“ нова транзакция на всички и слуша мрежата, чакайки блок, в чийто индекс ще се появи необходимата транзакция, за да уведоми чакащия клиент. Времето, което е необходимо на мрежата да прехвърли информация една на друга за нови транзакции и блокове в p2p мрежи, зависи от много голям брой фактори: броя на честните възли, работещи наблизо (от гледна точка на мрежата), „топло- нагоре” на кешовете на тези възли, размера на блоковете, транзакциите, естеството на промените, географията на мрежата, броя на възлите и много други фактори. Комплексните измервания на показателите за ефективност в такива мрежи са сложен въпрос; необходимо е едновременно да се оцени времето за обработка на заявката както на клиенти, така и на партньори (блокчейн възли). Проблеми във всеки от p2p механизмите, неправилно изхвърляне и кеширане на данни, неефективно управление на списъци с активни партньори и много други фактори могат да причинят забавяния, които влияят на ефективността на цялата мрежа като цяло, и това тясно място е най-трудно за анализ , тест и интерпретация на резултатите.

Обработка на блокчейн и актуализиране на държавна база данни

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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