Pyeshtunja më e zakonshme për çdo sistem të shpërndarë nga një specialist jo teknik është "Sa tps ka blockchain-i juaj?". Megjithatë, numri që jepet në përgjigje zakonisht ka pak të përbashkët me atë që dëshiron të dëgjojë pyetësi. Në të vërtetë, ai donte të pyesë "A do të përputhet blockchain-i juaj me kërkesat e mia të biznesit?", dhe këto kërkesa nuk janë një numër, por një shumëllojshmëri kushtesh — këtu përfshihet qëndrueshmëria e rrjetit, kërkesat për përfundim, përmasat, natyra e transaksioneve dhe shumë parametra të tjerë. Prandaj, përgjigja në këtë pyetje "sa tps" nuk do të jetë e thjeshtë dhe pothuajse asnjëherë nuk do të jetë e plotë. Një sistem i shpërndarë me dhjetëra dhe qindra nyje që kryejnë llogaritje mjaft komplekse mund të ndodhet në një numër të madh gjendjesh të ndryshme të lidhura me gjendjen e rrjetit, përmbajtjen e blockchain-it, defekte teknike, probleme ekonomike, sulme në rrjet dhe shumë arsye të tjera. Fazat ku mund të ndodhin problemet me performancën dallojnë nga shërbimet tradicionale, dhe serveri i rrjetit blockchain është një shërbim rrjeti që përmbush funksionin e një baze të dhashurash, një server web dhe një klient torrent, duke e bërë atë jashtëzakonisht të komplikuar në aspektin e profilit të ngarkesës për të gjitha nën-sistemet: procesori, memoria, rrjeti, ruajtja.

Ndodhi që rrjetet e decentralizuara dhe blockchain-et janë një softuer mjaft specifik dhe i panjohur për zhvilluesit e softuerit të centralizuar. Prandaj, do të doja të theksoj aspektet e rëndësishme të performancës dhe qëndrueshmërisë së rrjeteve të decentralizuara, qasjet për matjen e tyre dhe identifikimin e bottlenecks. Ne do të shqyrtojmë probleme të ndryshme të performancës që kufizojnë shpejtësinë e shërbimit për përdoruesit e blockchain-eve dhe do të theksojmë veçoritë që janë karakteristike për këtë lloj softueri.

Fazat e kërkesës së shërbimit nga klienti i blockchain-it

Për të folur sinqerisht për cilësinë e çdo shërbimi më të avancuar, është e nevojshme të merret parasysh jo vetëm mesataria, por edhe maksimet / minimalet, medianat, percentilet. Teorikisht, mund të flitet për 1000 tps në ndonjë blockchain, por nëse 900 transaksione u realizuan me shpejtësi të madhe, ndërsa 100 u "ngatërruan" për disa sekonda, atëherë koha mesatare e mbledhur për të gjitha transaksionet nuk është plotësisht një metrikë e drejtë për klientin që nuk mundi të përfundojë marrëveshjen për disa sekonda. "Gropat" e kohës, të shkaktuara nga humbjet e raundeve të konsensusit ose ndarjet e rrjetit, mund të prishin shumë shërbimin, i cili në stendat testuese tregon performancë të shkëlqyer.

Për të identifikuar ato bottleneck-e, është e nevojshme të kuptohet mirë fazat në të cilat një blockchain real mund të përballet me vështirësi në shërbimin e përdoruesve. Le të përshkruajmë ciklin e dorëzimit dhe procesimit të transaksionit, si dhe marrjen e gjendjes së re të blockchain-it, nga e cila klienti mund të sigurohet që transaksioni i tij është përpunuar dhe regjistruar.

transaksioni formohet në klient
transaksioni nënshkruhet në klient
klienti zgjedh një nga nyjet dhe i dërgon atij transaksionin e tij
klienti nënshkruhet për azhurnimet e bazës së të dhënave të gjendjes së nyjes, duke pritur shfaqjen e rezultateve të ekzekutimit të transaksionit të tij
nyja shpërndan transaksionin në rrjetin p2p
për disa, ose një BP (prodhues bllokesh) procesojnë transaksionet e grumbulluara, duke përmirësuar bazën e të dhënave të gjendjes
BP formon një bllok të ri, duke procesuar numrin e nevojshëm të transaksioneve
BP shpërndan bllokun e ri në rrjetin p2p
blloku i ri dorëzohet në nyjen, të cilës i drejtohet klienti
nyja përmirëson bazën e të dhënave të gjendjes
nyja sheh azhurnimin që lidhet me klientin dhe i dërgon atij një njoftim për transaksionin

Tani, le të shqyrtojmë këto faza më në detaje dhe të përshkruajmë problemet potenciale me performancën në çdo fazë. Ndryshe nga sistemet e centralizuara, ne gjithashtu do të shqyrtojmë ekzekutimin e kodit në klientët e rrjetit. Shpesh, gjatë matjes së tps, koha e përpunimit të transaksioneve mblidhet nga nyjat, jo nga klienti — kjo nuk është plotësisht e drejtë. Klientit nuk i intereson se sa shpejt e përpunoi nyja transaksionin e tij, më e rëndësishme për të është momenti kur informacioni i saktë për këtë transaksion, i regjistruar në blockchain, do t'i bëhet i disponueshëm atij. Kjo metrikë është në thelb koha e ekzekutimit të transaksionit. Kjo do të thotë se klientët e ndryshëm, madje duke dërguar të njëjtin transaksion, mund të marrin kohë krejtësisht të ndryshme, të cilat varen nga kanali, ngarkesa dhe afërsia e nyjes, etj. Pra, është thelbësore të matet kjo kohë në klientë, sepse ky parametr është ai që duhet optimizuar.

Përgatitja e transaksionit në anën e klientit

Начнем с первых двух пунктов: транзакция формируется и подписывается клиентом. Как ни странно, это тоже может быть bottleneck-ом производительности блокчейна с точки зрения клиента. Это непривычно для централизованных сервисов, которые все вычисления и операции с данными забирают себе, а клиент просто готовит короткий запрос, способный запросить большой объем данных или вычислений, получая готовый результат. В блокчейнах клиентский код становится все более и более мощным, а блокчейн ядро — все более и более легковесным, а массивные вычислительные задачи принято отдавать клиентскому софту. В блокчейнах существуют клиенты, которые могут готовить одну транзакцию довольно долго (я говорю о различных merkle proof-ах, succinct proof-ах, threshold подписях и других сложных операциях на стороне клиента). Хорошим примером легкой on-chain верификации и тяжелой подготовки трназакции на клиенте является доказательство принадлежности списку на основе Merkle-tree, вот artikull.

Также не стоит забывать, что клиентский код не просто шлет транзакции в блокчейн, а сначала запрашивает состояние блокчейна — а эта деятельность может влиять на загруженность сети и блокчейн нод. Так что, проводя измерения, разумным будет эмулировать как можно более полным образом поведение клиентского кода. Даже если в вашем блокчейне обычные легкие клиенты, которые ставят обычную цифровую подпись на простейшую транзакцию по переводу какого нибудь asset-а, с каждым годом массивных вычислений на клиенте все равно становится больше, криптоалгоритмы крепчают, и эта часть процессинга может превратиться в весомый bottleneck в будущем. Поэтому будьте осторожны, и не пропустите ситуацию, когда в транзакции, длящейся 3.5s, 2.5s уходит на подготовку и подписание транзакции, и 1.0s- на отправку в сеть и ожидание ответа. Для оценки рисков появления этого bottleneck нужно собирать метрики с клиентских машин, а не только с блокчейн-нод.

Отправка транзакции и мониторинг ее статуса

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

В блокчейнах, клиент оправляет транзакцию в любую понравившуюся ему ноду блокчейна, хеш транзакции обычно известен клиенту еще до отправки, так что все что ему требуется — добиться соединения и после передачи ожидать когда блокчейн изменит свое состояние, включив его транзакцию. Заметим, что измеряя «tps» можно получить совершенно разные результаты для различных способов подключения к ноде блокчейна. Это может быть обычный HTTP RPC или WebSocket, позволяющий реализовать паттерн «subscribe». Во втором случае клиент получит уведомление раньше, а нода потратит меньше ресурсов (в основном памяти и трафика) на ответы о состоянии транзакции. Так что при измерении «tps» необходимо учитывать способ подключения клиентов к нодам. Поэтому, для оценки рисков появления этого bottleneck-а, benchmark блокчейна должен уметь эмулировать клиентов и с WebSocket и с HTTP RPC запросами, в долях, соответствующих реальным сетям, а также менять характер транзакций и их размер.

Для оценки рисков появления этого bottleneck нужно также собирать метрики с клиентских машин, а не только с блокчейн-нод.

Передача транзакций и блоков по p2p сети

Në blockchain, për transmetimin e transaksioneve dhe bllokëve midis pjesëmarrësve, përdoret rrjetë peer-to-peer (p2p). Transaksionet shpërndahen në rrjet nga njëra nga nodet derisa arrijnë tek peer-et dhe prodhuesit e bllokëve, të cilët paketojnë transaksionet në blloqe dhe me të njëjtën rrjetë p2p shpërndajnë blloqet e reja në të gjitha nodet e rrjetit. Baza e shumicës së rrjeteve moderne p2p është variacione të ndryshme të protokollit Kademlia. Këtu është një përmbledhje e shkurtër e këtij protokolli, këtu — një artikull me matje të ndryshme në rrjetin BitTorrent, nga i cili mund të kuptohet se ky lloj rrjeti është më kompleks dhe më pak i parashikueshëm se një rrjet i centralizuar i konfiguruar ngusht. Gjithashtu, këtu një artikull mbi matjen e metrikeve interesante për nodet Ethereum.

Në përmbledhje, çdo peer në këto rrjete mban një listë dinamikisht të ndryshueshme të peer-eve të tjerë, nga të cilët kërkon blloqe informacioni që i adresohet sipas përmbajtjes. Kur merr një kërkesë, peer-i ose jep informacionin e nevojshëm, ose ia kalon kërkesën një peer-i tjetër rastësor nga lista, dhe pasi merr përgjigjen, ia kalon atij që e kishte kërkuar dhe për një kohë e ruan atë, duke e dhënë këtë bllok informacioni më parë herën tjetër. Kështu, informacioni i popullarizuar përfundon në shumë cache të një numri të madh peer-ësh, ndërsa ai jo i popullarizuar gradualisht zëvendësohet. Peer-ët mbajnë shënim se kush ka kaluar sa informacion, dhe rrjeti përpiqet të stimulojë ndarësit aktiv duke rritur renditjen e tyre dhe duke u ofruar atyre një nivel më të lartë shërbimi, duke i zëvendësuar automatikisht pjesëmarrësit jo aktiv nga listat e peer-ëve.

Tani, transaksioni duhet të shpërndahet në rrjet, që ta shohin prodhuesit e bllokëve dhe ta përfshijnë në bllok. Noda aktivisht "ndajnë" transaksionin e ri me të gjithë që e kërkojnë dhe dëgjon rrjetin, duke pritur bllokun në indeksin e të cilit do të shfaqet transaksioni i nevojshëm, për ta njoftuar klientin që po pret. Koha gjatë së cilës rrjeti kalon informacionin për transaksionet dhe blloqet e reja në rrjetet p2p varet nga shumë faktorë: numri i nodëve të ndershëm që punojnë afër (nga pikëpamja rrjetore), "ngrohja" e cache-ve të këtyre nodëve, madhësia e blloqeve, transaksioneve, natyra e ndryshimeve, gjeografia e rrjetit, numri i nodëve dhe shumë faktorë të tjerë. Matjet komplekse të metrikeve të performancës në këto rrjete janë një punë e komplikuar, pasi është e nevojshme të evalohet njëkohësisht koha e përpunimit të kërkesave si tek klientët ashtu edhe tek peer-ët (nodet e blockchain). Problemet në ndonjë nga mekanizmat p2p, zëvendësimi dhe caching i pasaktë i të dhënave, menaxhimi jo efektiv i listave të peer-ëve aktivë, dhe shumë faktorë të tjerë mund të shkaktojnë vonesa që ndikojnë në efikasitetin e gjithë rrjetit, dhe ky bottleneck është më i vështirë për t'u analizuar, testuar dhe interpretuar rezultatet.

Procesimi i zinxhirit të blloqeve dhe përditësimi i state database

Pjesa më e rëndësishme e funksionimit të blockchain është algoritmi i konsensusit, aplikimi i tij në blloqet e rinj që merren nga rrjeti dhe procesi i transaksioneve me regjistrimin e rezultateve në state database. Shtimi i një blloku të ri në zinxhir dhe zgjedhja e rrugës kryesore pas tij duhet të funksionojë sa më shpejt. Megjithatë, në jetën reale "duhet" nuk do të thotë "funksionon", dhe mund të imagjinojmë një situatë ku dy zinxhirë konkurrues të gjatë vazhdimisht kalojnë nga njëri te tjetri, duke ndryshuar metadatët e mijëra transaksioneve në pool me çdo kalim, dhe duke bërë rikthime të vazhdueshme të gjendjes në state database. Ky etap, në aspektin e identifikimit të bottleneck, është më i lehtë se shtresa e rrjetit p2p, pasi ekzekutimi i transaksioneve dhe algoritmi i konsensusit janë tërësisht të determinueshëm, dhe është më e lehtë të matësh diçka këtu.
E rëndësishme është të mos ngatërrohet degradimi rastësor i performancës në këtë etap me problemet e rrjetit — nodet e japin më ngadalë blloqet dhe informacionin mbi zinxhirin kryesor dhe për klientin e jashtëm kjo mund të duket si një rrjet i ngadalshëm, ndonëse problemi ndodhet në një vend krejt tjetër.

Për optimizimin e performancës në këtë etap, është e dobishme të mblidhen dhe monitorohen metrike nga vetë nodet, dhe të përfshihen ato që lidhen me përditësimin e state database: numri i blloqeve që përpunohen në nodë, madhësia e tyre, numri i transaksioneve, numri i kalimeve midis fork-ëve të zinxhirëve, numri i blloqeve jo të vlefshme, koha e ekzekutimit të makinës virtuale, koha e ruajtjes së të dhënave, etj. Kjo do të ndihmojë që të mos ngatërrohen problemet e rrjetit me gabimet në algoritmet e përpunimit të zinxhirëve.

Një makinë virtuale për përpunimin e transaksioneve mund të jetë një burim i çmuar informacioni që optimizon funksionimin e blockchain. Sasia e alokimeve të memories, numri i instruktimeve të leximit/shkrimit dhe metrikat e tjera që lidhen me efikasitetin e ekzekutimit të kodit të kontratave mund të ofrojnë shumë informacion të dobishëm për zhvilluesit. Në të njëjtën kohë, kontratat inteligjente janë programe dhe, në teorinë, ato mund të konsumojnë ndonjë nga burimet: cpu/memoria/rete/storage, kështu që procesi i përpunimit të transaksioneve është një fazë mjaft e paqartë, e cila gjithashtu ndryshon shumë me kalimin e versioneve dhe ndryshimet në kodin e kontratave. Prandaj, metrikat që lidhen me procesimin e transaksioneve janë gjithashtu të nevojshme për optimizimin e efektivitetit të performancës së blockchain.

Njoftimi i klientit për përfshirjen e transaksionit në blockchain

Ky është faza përfundimtare e marrjes së shërbimit nga klienti në blockchain, në krahasim me fazat e tjera, nuk ka shpenzime të mëdha, por megjithatë duhet të merret parasysh mundësia e pranim të përgjigjes voluminoze nga nodi (për shembull, kontrata inteligjente që kthehet një array të dhënash). Në çdo rast, ky moment është më i rëndësishmi për ata që ndojnë pyetjen "sa tps ka blockchain juaj?" sepse në këtë moment regjistrohet koha e marrjes së shërbimit.

Në këtë pikë, është e domosdoshme të dërgohet koha totale që klienti ka pritur për përgjigje nga blockchain, kjo është koha që përdoruesi do të presë për konfirmim në aplikacionin e tij dhe optimizimi i saj është detyra kryesore e zhvilluesve.

Përfundimi

Si rezultat, mund të përshkruhen llojet e operacioneve që kryhen në blockchain dhe të klasifikohen në disa kategori:

transformime kriptografike, ndërtimi i provave
rrjeti peer-to-peer, replikimi i transaksioneve dhe blloqeve
përpunimi i transaksioneve, ekzekutimi i kontratave inteligjente
aplikimi i ndryshimeve në blockchain në bazën e të dhënave të gjendjes, përditësimi i të dhënave për transaksionet dhe blloqet
kërkesat vetëm për lexim në bazën e të dhënave të gjendjes, API e nodit të blockchain, shërbimet e abonimit

Në përgjithësi, kërkesat teknike për nodet e blockchain-eve moderne janë shumë serioze - këto janë CPU të shpejtë për kriptografi, një sasi e madhe e memories operuese për të ruajtur dhe për të aksesuar shpejt bazën e të dhënave të gjendjes, ndërveprimi rrjetor që përdor një numër të madh të lidhjeve të hapura njëkohësisht dhe hapësirë të madhe ruajtjeje. Këto kërkesa të larta dhe shumllojshmëria e operacioneve të ndryshme e bëjnë të mundur që resurset e nodit të mos mjaftojnë, dhe në këtë rast, çdo nga fazat e shqyrtuara më sipër mund të bëhet një ngushticë për performancën e përgjithshme të rrjetit.

Kur zhvilloni dhe vlerësoni performancën e blockchain-eve, do t'ju duhet të merrni parasysh të gjitha këto pika. Për këtë, është e nevojshme të mbledhni dhe analizoni metrikat njëkohësisht nga klientët dhe nodet e rrjetit, të kërkoni korelacionet midis tyre, të vlerësoni kohën e ofrimit të shërbimeve për klientët, të merrni parasysh të gjitha burimet kryesore: cpu/memoria/rete/storage, të kuptoni se si ato përdoren dhe ndikojnë njëra-tjetrën. Të gjitha këto e bëjnë krahasimin e shpejtësive të blockchain-eve të ndryshme në formën "sa TPS" një detyrë të paçmuar, pasi ekziston një numër i madh konfigurationsh dhe gjendjesh të ndryshme. Në sistemet e mëdha centralizuese, grupe të qindra serverëve, këto probleme janë gjithashtu të komplikuara dhe kërkojnë mbledhjen e një numri të madh metrikash të ndryshme, por në blockchain-e, për shkak të rrjeteve p2p, makinave virtuale që përpunojnë kontratat, ekonomisë së brendshme, numri i gradave të lirisë është shumë më i madh, duke e bërë testin edhe në disa serverë të jetë jo-informatues dhe të tregojë vetëm vlera të përafërta, që kanë shumë pak lidhje me realitetin.

Prandaj, kur zhvilloni në bërthamën e blockchain-it, për vlerësimin e performancës dhe për t'iu përgjigjur pyetjes "a është përmirësuar krahasuar me herën e kaluar", ne përdorim një softuer të përshtatshëm, që orkestron lançimin e blockchain-it me dhjetëra node dhe startimin automatik të benchmark-ut dhe mbledhjen e metrikave, pa këtë informacion, është jashtëzakonisht e vështirë të diagnostikosh protokollet që punojnë me shumë pjesëmarrës.

Kështu, duke marrë pyetjen "sa TPS ka blockchain juaj?", ofroni një filxhan çaji palës tjetër dhe pyetni nëse është i gatshëm të njihet me dhjetëra grafikë si dhe të dëgjoni të gjitha problematikat e performancës së blockchain-eve dhe propozimet tuaja për zgjidhjen e tyre...

Burimi: habr.com