Любімым пытаннем аб любой размеркаванай сістэме ад нетэхнічнага спецыяліста з'яўляецца "Колькі tps у вашым блокчейне?". Аднак, названае ў адказ колькасць звычайна мае мала агульнага з тым, што хацеў бы пачуць дапытлівы. На справе, ён хацеў спытаць "ці падыдзе ваш блокчейн пад мае бізнес патрабаванні", і гэтыя патрабаванні - гэта не адна колькасць, а мноства ўмоў - тут і адмоваўстойлівасць сеткі, і патрабаванні да фінальнасці, памеры, характар транзакцый і мноства іншых параметраў. Так што адказ на пытанне "колькі tps" наўрад ці будзе простым, і амаль ніколі не будзе поўным. Размеркаваная сістэма з дзясяткамі і сотнямі вузлоў, якія выконваюць даволі складаныя вылічэнні, можа знаходзіцца ў велізарнай колькасці розных станаў, злучаных са станам сеткі, змесцівам блокчейна, тэхнічнымі збоямі, эканамічнымі праблемамі, нападамі на сетку і мноствам іншых чыннікаў. Этапы, на якіх магчымыя праблемы з прадукцыйнасцю адрозніваюцца ад традыцыйных сэрвісаў, а сервер блокчейн-сеткі - гэта сеткавы сэрвіс, які спалучае ў сабе функцыянал базы дадзеных, web-сервера і torrent-кліента, што робіць яго вельмі складаным у плане профілю нагрузкі на ўсе падсістэмы. : працэсар, памяць, сетка, storage

Так атрымалася, што дэцэнтралізаваныя сеткі і блокчейны з'яўляюцца даволі спецыфічным і нязвыклым софтам для распрацоўшчыкаў цэнтралізаванага ПЗ. Таму я хацеў бы асвятліць важныя аспекты прадукцыйнасці і ўстойлівасці дэцэнтралізаваных сетак, падыходы да іх вымярэння і знаходжанню 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-tree, вось артыкул.

Таксама не варта забываць, што кліенцкі код не проста шле транзакцыі ў блокчейн, а спачатку запытвае стан блокчейна - а гэтая дзейнасць можа ўплываць на загружанасць сеткі і блокчейн нод. Так што, праводзячы вымярэнні, разумным будзе эмуляваць як мага больш поўнай выявай паводзіны кліенцкага кода. Нават калі ў вашым блокчейне звычайныя лёгкія кліенты, якія ставяць звычайны лічбавы подпіс на найпростую транзакцыю па перакладзе якога небудзь asset-а, з кожным годам масіўных вылічэнняў на кліенце ўсё роўна становіцца больш, крыптаалгарытмы мацнеюць, і гэтая частка працэсінгу можа ператварыцца ў вагу будучыні. Таму будзьце асцярожныя, і не прапусціце сітуацыю, калі ў транзакцыі, якая доўжыцца 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 сетцы

У блокчейнах для перадачы паміж удзельнікамі транзакцый і блокаў выкарыстоўваецца peer-to-peer (p2p) networking. Транзакцыі распаўсюджваюцца па сетцы, пачынальна з адной з нод, пакуль не дасягаюць peer-ов-block producer-ов, якія пакуюць транзакцыі ў блокі і з дапамогай таго ж 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-datаbase: колькасць блокаў, якія апрацоўваюцца на нодзе, іх памер, колькасць транзакцый, колькасць пераключэнняў паміж форкамі ланцужкоў, колькасць невалідных блокаў , час працы віртуальнай машыны, час фіксацыі даных і г.д. Гэта дазволіць не зблытаць сеткавыя праблемы з памылкамі ў алгарытмах працэсінгу ланцужкоў.

Віртуальная машына, якая працэсуе транзакцыі, можа быць карыснай крыніцай інфармацыі, здольнай аптымізаваць працу блокчейна. Колькасць алакацый памяці, колькасць read/write інструкцый, і іншыя метрыкі, якія датычацца эфектыўнасці выканання кода кантрактаў могуць даць шмат карыснай інфармацыі распрацоўшчыкам. У той жа час, смарт-кантракты - гэта праграмы, а значыць у тэорыі яны могуць спажываць любыя з рэсурсаў: cpu/memory/network/storage, так што працэсінг транзакцый - даволі нявызначаны этап, які ў дадатак моцна змяняецца пры пераходзе паміж версіямі і пры змене кода кантрактаў. Таму метрыкі, якія тычацца працэсінгу транзакцый, таксама патрэбныя для эфектыўнай аптымізацыі прадукцыйнасці блокчейна.

Атрыманне кліентам апавяшчэння аб уключэнні транзакцыі ў блокчейн

Гэта завяршальны этап атрымання сэрвісу кліентам блокчейна, у параўнанні з іншымі этапамі тут няма вялікіх накладных выдаткаў, але ўсё роўна варта ўлічваць магчымасць атрымання кліентам аб'ёмнага адказу ад ноды (напрыклад смарт-кантракт, які аддае масіў дадзеных). У любым выпадку, менавіта гэты момант з'яўляецца найважнейшым для таго, хто задаў пытанне «а колькі tps у вашым блокчейне?», т.я. у гэты момант і фіксуецца час атрымання сервісу.

У гэтым месцы абавязкова прысутнічае адпраўка поўнага часу, якое прыйшлося затраціць кліенту на чаканне адказу ад блокчейна, менавіта гэты час карыстач будзе чакаць пацверджання ў сваім дадатку, і менавіта яго аптымізацыя з'яўляецца асноўнай задачай распрацоўшчыкаў.

Заключэнне

У выніку, можна апісаць тыпы аперацый, якія выконваюцца ў блокчейнах і падзяліць іх на некалькі катэгорый:

крыптаграфічныя пераўтварэнні, пабудова доказаў
peer-to-peer networking, рэплікацыя транзакцый і блокаў
працэсінг транзакцый, выкананне смарт-кантрактаў
ужыванне змен у блокчейне да state database, абнаўленне дадзеных аб транзакцыях і блоках
read-only запыты да state database, API блокчейн ноды, subscription сэрвісы

Наогул тэхнічныя патрабаванні да нодаў сучасных блокчейнов вельмі сур'ёзныя - гэта хуткія CPU для крыптаграфіі, вялікі аб'ём аператыўнай памяці для таго, каб захоўваць і хутка звяртацца да state database, сеткавае ўзаемадзеянне, якое выкарыстоўвае вялікі лік адначасова адкрытых злучэнняў, аб'ёмны storage. Такія высокія патрабаванні і багацце розных тыпаў аперацый непазбежна прыводзяць да таго, што рэсурсаў у нод можа бракаваць, і, тады любы з разгледжаных вышэй этапаў можа стаць чарговым bottleneck-ом для агульнай прадукцыйнасці сеткі.

Распрацоўваючы і ацэньваючы прадукцыйнасць блокчейнов, вам давядзецца ўлічваць усе гэтыя моманты. Для гэтага трэба збіраць і аналізаваць метрыкі адначасова з кліентаў і нод сеткі, шукаць карэляцыі паміж імі, ацэньваць час прадастаўлення сэрвісу кліентам, улічваць усе асноўныя рэсурсы: cpu/memory/network/storage, разумець як яны выкарыстоўваюцца і ўплываюць адзін на аднаго. Усё гэта робіць параўнанне хуткасцяў розных блокчейнов у выглядзе «колькі TPS» вельмі няўдзячным заняткам, бо існуе велізарная колькасць розных канфігурацый і станаў. У вялікіх цэнтралізаваных сістэмах, кластарах з сотняў сервераў, гэтыя праблемы таксама складаныя і таксама патрабуюць збору вялікай колькасці розных метрык, але ў блокчейнах, з-за p2p сетак, віртуальных машын, якія працэсяць кантракты, унутранай эканомікі, колькасць ступеняў свабоды значна больш, што робіць тэст нават на некалькіх серверах непаказальным і якія паказваюць толькі вельмі прыкладныя значэнні, амаль не мелыя сувязі з рэальнасцю.

Таму, пры распрацоўцы ў ядры блокчейна, для адзнакі прадукцыйнасці і адказу на пытанне «ці палепшылася ў параўнанні з мінулым разам» мы выкарыстоўваем даволі складаны софт, які аркеструе запуск блокчейна з дзясяткамі вузлоў і аўтаматычным запускам бенчмарку і зборам метрык, без гэтай інфармацыі вельмі складана адладжваць пратаколы, якія працуюць са мноствам удзельнікаў.

Так што, атрымаўшы пытанне «колькі TPS у вашым блокчейне?», прапануеце суразмоўцу гарбаты і ўдакладніце, ці гатовы ён азнаёміцца з дзясяткам графікаў а таксама выслухаць усе тры карабля праблем прадукцыйнасці блокчейнов і вашымі прапановы па іх вырашэнні.

Крыніца: habr.com

Колькі TPS у вашым блокчейне?