ProHoster > Blogs > Administrācija > Cik TPS ir jūsu blokķēdē?

Cik TPS ir jūsu blokķēdē?

IecienÄ«tākais jautājums par jebkuru izplatÄ«tu sistēmu, ko uzdod persona, kas nav tehniska, ir ā€œCik tps ir jÅ«su blokķēdē?ā€ Tomēr atbildē norādÄ«tajam skaitlim parasti ir maz kopÄ«ga ar to, ko jautātājs vēlētos dzirdēt. PatiesÄ«bā viņŔ vēlējās jautāt: ā€œVai jÅ«su blokķēde atbilst manām biznesa prasÄ«bāmā€, un Ŕīs prasÄ«bas nav viens skaitlis, bet gan daudzi nosacÄ«jumi ā€“ Å”eit ir tÄ«kla kļūdu tolerance, galÄ«guma prasÄ«bas, izmēri, darÄ«jumu veids un daudzi citi parametri. Tātad atbilde uz jautājumu ā€œcik tpsā€, visticamāk, nebÅ«s vienkārÅ”a un gandrÄ«z nekad nav pilnÄ«ga. Izkliedētā sistēma ar desmitiem vai simtiem mezglu, kas veic diezgan sarežģītus aprēķinus, var bÅ«t ļoti daudzos dažādos stāvokļos, kas saistÄ«ti ar tÄ«kla stāvokli, blokķēdes saturu, tehniskām kļūmēm, ekonomiskām problēmām, uzbrukumiem tÄ«klam un daudziem citiem iemesliem. . Posmi, kuros iespējamas veiktspējas problēmas, atŔķiras no tradicionālajiem pakalpojumiem, un blokķēdes tÄ«kla serveris ir tÄ«kla pakalpojums, kas apvieno datu bāzes, tÄ«mekļa servera un torrent klienta funkcionalitāti, kas padara to ārkārtÄ«gi sarežģītu visu apakÅ”sistēmu slodzes profila ziņā. : procesors, atmiņa, tÄ«kls, krātuve

Gadās, ka decentralizētie tÄ«kli un blokķēdes ir diezgan specifiska un neparasta programmatÅ«ra centralizētas programmatÅ«ras izstrādātājiem. Tāpēc es vēlētos izcelt svarÄ«gus decentralizēto tÄ«klu darbÄ«bas un ilgtspējas aspektus, pieejas to mērÄ«Å”anai un vājo vietu atraÅ”anai. Mēs apskatÄ«sim dažādas veiktspējas problēmas, kas ierobežo pakalpojumu sniegÅ”anas ātrumu blokķēdes lietotājiem, un atzÄ«mēsim Ŕāda veida programmatÅ«rai raksturÄ«gās funkcijas.

Blokķēdes klienta pakalpojuma pieprasījuma posmi

Lai godÄ«gi runātu par jebkura vairāk vai mazāk sarežģīta pakalpojuma kvalitāti, jāņem vērā ne tikai vidējās vērtÄ«bas, bet arÄ« maksimālās/minimālās, mediānas, procentiles. Teorētiski var runāt par 1000 tps kādā blokķēdē, bet, ja 900 transakcijas tika pabeigtas ar milzÄ«gu ātrumu un 100 tika ā€œiestrēguÅ”asā€ uz dažām sekundēm, tad vidējais laiks, kas savākts par visiem darÄ«jumiem, nav pilnÄ«gi godÄ«gs rādÄ«tājs klientam. kuru es nevarēju pabeigt darÄ«jumu dažu sekunžu laikā. ÄŖslaicÄ«gi ā€œcaurumiā€, ko izraisa nokavēti vienprātÄ«bas raundi vai tÄ«kla sadalÄ«jumi, var ievērojami sabojāt pakalpojumu, kas uzrādÄ«jis izcilu veiktspēju testa stendos.

Lai identificētu Ŕādas vājās vietas, ir labi jāizprot posmi, kuros Ä«stai blokķēdei var rasties grÅ«tÄ«bas apkalpot lietotājus. AprakstÄ«sim darÄ«juma piegādes un apstrādes ciklu, kā arÄ« jauna blokķēdes stāvokļa iegÅ«Å”anu, no kura klients var pārliecināties, ka viņa darÄ«jums ir apstrādāts un uzskaitÄ«ts.

  1. darījums tiek veidots uz klientu
  2. darījums tiek parakstīts uz klienta
  3. klients izvēlas vienu no mezgliem un nosūta tam savu darījumu
  4. klients abonē mezgla stāvokļa datu bāzes atjauninājumus, gaidot, kad parādīsies tā darījuma rezultāti
  5. mezgls izplata darījumu pa p2p tīklu
  6. vairāki vai viens BP (bloka ražotājs) apstrādā uzkrātos darījumus, aktualizējot valsts datubāzi
  7. BP veido jaunu bloku pēc nepiecieÅ”amā darÄ«jumu skaita apstrādes
  8. BP izplata jaunu bloku p2p tīklā
  9. jaunais bloks tiek piegādāts mezglā, kuram klients piekļūst
  10. mezgls atjaunina stāvokļa datu bāzi
  11. mezgls redz atjauninājumu attiecībā uz klientu un nosūta viņam darījuma paziņojumu

Tagad aplÅ«kosim Å”os posmus tuvāk un aprakstÄ«sim iespējamās veiktspējas problēmas katrā posmā. AtŔķirÄ«bā no centralizētajām sistēmām, mēs apsvērsim arÄ« koda izpildi tÄ«kla klientiem. Diezgan bieži, mērot TPS, darÄ«jumu apstrādes laiks tiek iekasēts no mezgliem, nevis no klienta - tas nav gluži godÄ«gi. Klientam ir vienalga, cik ātri mezgls apstrādāja viņa darÄ«jumu, viņam svarÄ«gākais ir brÄ«dis, kad viņam kļūst pieejama uzticama informācija par Å”o blokķēdē iekļauto darÄ«jumu. TieÅ”i Ŕī metrika bÅ«tÄ«bā ir darÄ«juma izpildes laiks. Tas nozÄ«mē, ka dažādi klienti, pat nosÅ«tot vienu un to paÅ”u transakciju, var saņemt pilnÄ«gi atŔķirÄ«gus laikus, kas ir atkarÄ«gi no kanāla, mezgla slodzes un tuvuma utt. Tāpēc ir absolÅ«ti nepiecieÅ”ams izmērÄ«t Å”o laiku klientiem, jo ā€‹ā€‹tas ir parametrs, kas ir jāoptimizē.

DarÄ«juma sagatavoÅ”ana klienta pusē

Sāksim ar pirmajiem diviem punktiem: darÄ«jumu noformē un paraksta klients. Savādi, bet tas var bÅ«t arÄ« blokķēdes veiktspējas saÅ”aurinājums no klienta viedokļa. Tas ir neparasti centralizētajiem dienestiem, kas pārņem visus aprēķinus un darbÄ«bas ar datiem, un klients vienkārÅ”i sagatavo Ä«su pieprasÄ«jumu, kas var pieprasÄ«t lielu datu apjomu vai aprēķinus, iegÅ«stot gatavu rezultātu. Blokķēdēs klienta kods kļūst arvien jaudÄ«gāks, un blokķēdes kodols kļūst arvien vieglāks, un masÄ«vi skaitļoÅ”anas uzdevumi parasti tiek pārsÅ«tÄ«ti uz klienta programmatÅ«ru. Blokķēdēs ir klienti, kas vienu darÄ«jumu var sagatavot diezgan ilgu laiku (es runāju par dažādiem merkle pierādÄ«jumiem, kodolÄ«giem pierādÄ«jumiem, sliekŔņa parakstiem un citām sarežģītām operācijām klienta pusē). Labs piemērs vienkārÅ”ai pārbaudei ķēdē un smagai darÄ«juma sagatavoÅ”anai ar klientu ir pierādÄ«jums dalÄ«bai sarakstā, kura pamatā ir Merkle-tree, Å”eit raksts.

Tāpat neaizmirstiet, ka klienta kods nevis vienkārÅ”i nosÅ«ta darÄ«jumus uz blokķēdi, bet vispirms vaicā par blokķēdes stāvokli ā€“ un Ŕī darbÄ«ba var ietekmēt tÄ«kla un blokķēdes mezglu pārslodzi. Tātad, veicot mērÄ«jumus, bÅ«tu saprātÄ«gi pēc iespējas pilnÄ«gāk atdarināt klienta koda uzvedÄ«bu. Pat ja jÅ«su blokķēdē ir parastie vieglie klienti, kuri uz vienkārŔākā darÄ«juma, lai pārsÅ«tÄ«tu kādu aktÄ«vu, uzliek parastu ciparparakstu, katru gadu joprojām tiek veikti masÄ«vāki klienta aprēķini, kripto algoritmi kļūst spēcÄ«gāki, un Ŕī apstrādes daļa var kļūt par bÅ«tisku saÅ”aurinājumu nākotnē. Tāpēc esiet uzmanÄ«gi un nepalaidiet garām situāciju, kad darÄ«jumā, kas ilgst 3.5s, darÄ«juma sagatavoÅ”anai un parakstÄ«Å”anai tiek tērēti 2.5s, bet nosÅ«tÄ«Å”anai tÄ«klā un atbildes gaidÄ«Å”anai 1.0s. Lai novērtētu Ŕīs vājās vietas riskus, jums ir jāapkopo metrika no klientu iekārtām, nevis tikai no blokķēdes mezgliem.

Darījuma nosūtīŔana un tā statusa uzraudzība

Nākamais solis ir nosÅ«tÄ«t transakciju uz izvēlēto blokķēdes mezglu un saņemt tā pieņemÅ”anas statusu darÄ«jumu pÅ«lā. Å is posms ir lÄ«dzÄ«gs parastai piekļuvei datubāzei; mezglam ir jāreÄ£istrē darÄ«jums pÅ«lā un jāsāk izplatÄ«t informāciju par to caur p2p tÄ«klu. Pieeja veiktspējas novērtÄ“Å”anai Å”eit ir lÄ«dzÄ«ga tradicionālo Web API mikropakalpojumu veiktspējas novērtÄ“Å”anai, un paÅ”us darÄ«jumus blokķēdēs var atjaunināt un aktÄ«vi mainÄ«t to statusu. Parasti darÄ«jumu informācijas atjaunināŔana dažās blokķēdēs var notikt vairākas reizes, piemēram, pārslēdzoties starp ķēdes dakŔām vai kad BP paziņo par nodomu iekļaut darÄ«jumu blokā. Å Ä« pÅ«la lieluma un tajā veikto darÄ«jumu skaita ierobežojumi var ietekmēt blokķēdes veiktspēju. Ja darÄ«jumu kopums ir piepildÄ«ts lÄ«dz maksimālajam iespējamajam izmēram vai neietilpst RAM, tÄ«kla veiktspēja var strauji samazināties. Blokķēdēm nav centralizētu lÄ«dzekļu aizsardzÄ«bai pret nevēlamu ziņojumu plÅ«diem, un, ja blokķēde atbalsta liela apjoma darÄ«jumus un zemas maksas, tas var izraisÄ«t darÄ«jumu kopas pārplÅ«di ā€” vēl vienu potenciālu veiktspējas vājo vietu.

Blokķēdēs klients nosÅ«ta darÄ«jumu uz jebkuru blokķēdes mezglu, kas viņam patÄ«k, darÄ«juma hash parasti ir zināms klientam pirms nosÅ«tÄ«Å”anas, tāpēc viņam atliek tikai panākt savienojumu un pēc pārraides gaidÄ«t, kamēr blokķēde mainÄ«sies. tā stāvokli, ļaujot veikt darÄ«jumu. Ņemiet vērā, ka, mērot ā€œtpsā€, jÅ«s varat iegÅ«t pilnÄ«gi atŔķirÄ«gus rezultātus dažādām savienojuma metodēm ar blokķēdes mezglu. Tas var bÅ«t parasts HTTP RPC vai WebSocket, kas ļauj ieviest ā€œabonÄ“Å”anasā€ modeli. Otrajā gadÄ«jumā klients saņems paziņojumu agrāk, un mezgls tērēs mazāk resursu (galvenokārt atmiņu un trafiku) atbildēm par darÄ«juma statusu. Tāpēc, mērot ā€œtpsā€, ir jāņem vērā veids, kā klienti savienojas ar mezgliem. Tāpēc, lai novērtētu Ŕīs vājās vietas riskus, etalona blokķēdei ir jāspēj emulēt klientus gan ar WebSocket, gan HTTP RPC pieprasÄ«jumiem, proporcijās, kas atbilst reālajiem tÄ«kliem, kā arÄ« jāmaina darÄ«jumu raksturs un to apjoms.

Lai novērtētu Ŕīs vājās vietas riskus, jums ir jāapkopo arÄ« metrika no klientu iekārtām, nevis tikai no blokķēdes mezgliem.

Darījumu un bloku pārsūtīŔana caur p2p tīklu

Blokķēdēs tiek izmantots vienādranga (p2p) tÄ«kls, lai pārsÅ«tÄ«tu darÄ«jumus un blokus starp dalÄ«bniekiem. DarÄ«jumi izplatās visā tÄ«klā, sākot no viena no mezgliem, lÄ«dz tie sasniedz vienādranga bloku ražotājus, kuri saliek darÄ«jumus blokos un, izmantojot to paÅ”u p2p, izplata jaunus blokus visiem tÄ«kla mezgliem. MÅ«sdienu p2p tÄ«klu pamatā ir dažādas Kademlia protokola modifikācijas. Å”eit ir labs Ŕī protokola kopsavilkums un Å”eit - raksts ar dažādiem mērÄ«jumiem BitTorrent tÄ«klā, no kura var saprast, ka Ŕāda veida tÄ«kls ir sarežģītāks un mazāk paredzams nekā stingri konfigurēts centralizēta servisa tÄ«kls. Tāpat Å”eit raksts par dažādu interesantu metrikas mērÄ«Å”anu Ethereum mezgliem.

ÄŖsāk sakot, katrs lÄ«dzinieks Ŕādos tÄ«klos uztur savu dinamisko sarakstu ar citiem vienaudžiem, no kuriem tas pieprasa informācijas blokus, uz kuriem attiecas saturs. Kad partneris saņem pieprasÄ«jumu, tas vai nu sniedz nepiecieÅ”amo informāciju, vai nodod pieprasÄ«jumu nākamajam pseidogadÄ«juma partnerim no saraksta un, saņēmis atbildi, nodod to pieprasÄ«tājam un kādu laiku saglabā keÅ”atmiņā, sniedzot Å”o informācijas bloku nākamreiz. Tādējādi populārā informācija nonāk lielā skaitā liela skaita vienaudžu keÅ”atmiņas, un nepopulārā informācija pakāpeniski tiek aizstāta. Vienādrangi veic uzskaiti par to, kurÅ” un kam ir nosÅ«tÄ«jis informāciju, un tÄ«kls mēģina stimulēt aktÄ«vos izplatÄ«tājus, paaugstinot viņu reitingus un nodroÅ”inot viņiem augstāku pakalpojumu lÄ«meni, automātiski izspiežot neaktÄ«vos dalÄ«bniekus no vienaudžu sarakstiem.

Tātad darÄ«jums tagad ir jāizplata visā tÄ«klā, lai bloku ražotāji to varētu redzēt un iekļaut blokā. Mezgls aktÄ«vi ā€œizplataā€ jaunu transakciju visiem un klausās tÄ«klu, gaidot bloku, kura indeksā parādÄ«sies vajadzÄ«gais darÄ«jums, lai informētu gaidoÅ”o klientu. Laiks, kas nepiecieÅ”ams, lai tÄ«kls pārsÅ«tÄ«tu informāciju par jauniem darÄ«jumiem un blokiem viens otram p2p tÄ«klos, ir atkarÄ«gs no ļoti daudziem faktoriem: tuvumā strādājoÅ”o godÄ«go mezglu skaita (no tÄ«kla viedokļa), ā€œsiltā- uz augÅ”uā€ no Å”o mezglu keÅ”atmiņām, bloku lielumu, transakcijām, izmaiņu raksturu, tÄ«kla Ä£eogrāfiju, mezglu skaitu un daudziem citiem faktoriem. Kompleksi veiktspējas metriku mērÄ«jumi Ŕādos tÄ«klos ir sarežģīts jautājums, ir nepiecieÅ”ams vienlaicÄ«gi novērtēt pieprasÄ«jumu apstrādes laiku gan klientiem, gan vienādrangiem (blokķēdes mezgliem). Problēmas jebkurā no p2p mehānismiem, nepareiza datu izlikÅ”ana un keÅ”atmiņa, neefektÄ«va aktÄ«vo vienaudžu sarakstu pārvaldÄ«ba un daudzi citi faktori var izraisÄ«t aizkavÄ“Å”anos, kas ietekmē visa tÄ«kla efektivitāti kopumā, un Å”o vājo vietu ir visgrÅ«tāk analizēt. , testÄ“Å”ana un rezultātu interpretācija.

Blokķēdes apstrāde un stāvokļa datu bāzes atjaunināŔana

BÅ«tiskākā blokķēdes daļa ir konsensa algoritms, tā pielietoÅ”ana jauniem blokiem, kas saņemti no tÄ«kla un darÄ«jumu apstrāde ar rezultātu ierakstÄ«Å”anu valsts datu bāzē. Jauna bloka pievienoÅ”anai ķēdei un pēc tam galvenās ķēdes izvēlei vajadzētu darboties pēc iespējas ātrāk. Tomēr reālajā dzÄ«vē "vajadzētu" nenozÄ«mē "strādā", un, piemēram, var iedomāties situāciju, kad divas garas konkurējoÅ”as ķēdes pastāvÄ«gi pārslēdzas savā starpā, mainot tÅ«kstoÅ”iem darÄ«jumu metadatus pÅ«lā katrā pārslēgÅ”anās reizē. , un pastāvÄ«gi atgriežot valsts datubāzi. Å is posms saÅ”aurinājuma noteikÅ”anas ziņā ir vienkārŔāks nekā p2p tÄ«kla slānis, jo darÄ«jumu izpilde un konsensa algoritms ir stingri deterministiski, un Å”eit ir vieglāk izmērÄ«t jebko.
Galvenais ir nesajaukt nejauÅ”u Ŕī posma veiktspējas pasliktināŔanos ar tÄ«kla problēmām - mezgli lēnāk piegādā blokus un informāciju par galveno ķēdi, un ārējam klientam tas var izskatÄ«ties kā lēns tÄ«kls, lai gan problēma ir pavisam cita vieta.

Lai optimizētu veiktspēju Å”ajā posmā, ir lietderÄ«gi apkopot un pārraudzÄ«t metriku no paÅ”iem mezgliem un iekļaut tajos datus, kas saistÄ«ti ar stāvokļa datu bāzes atjaunināŔanu: mezglā apstrādāto bloku skaits, to lielums, transakciju skaits, slēdžu skaits starp ķēdes dakŔām, nederÄ«go bloku skaits, virtuālās maŔīnas darbÄ«bas laiks, datu izpildes laiks utt. Tas novērsÄ«s tÄ«kla problēmu sajaukÅ”anu ar kļūdām ķēdes apstrādes algoritmos.

Virtuālā maŔīna, kas apstrādā darÄ«jumus, var bÅ«t noderÄ«gs informācijas avots, kas var optimizēt blokķēdes darbÄ«bu. Atmiņas pieŔķīrumu skaits, lasÄ«Å”anas/rakstÄ«Å”anas instrukciju skaits un citi rādÄ«tāji, kas saistÄ«ti ar lÄ«guma koda izpildes efektivitāti, var sniegt izstrādātājiem daudz noderÄ«gas informācijas. Tajā paŔā laikā viedie lÄ«gumi ir programmas, kas teorētiski nozÄ«mē, ka tās var patērēt jebkuru no resursiem: cpu/atmiņu/tÄ«klu/krātuvi, tāpēc darÄ«jumu apstrāde ir diezgan nenoteikts posms, kas turklāt ļoti mainās, pārvietojoties starp versijām. un mainot lÄ«guma kodus. Tāpēc, lai efektÄ«vi optimizētu blokķēdes veiktspēju, ir nepiecieÅ”ami arÄ« rādÄ«tāji, kas saistÄ«ti ar darÄ«jumu apstrādi.

Klienta paziņojuma saņemÅ”ana par darÄ«juma iekļauÅ”anu blokķēdē

Å is ir pēdējais posms, kad blokķēdes klients saņem pakalpojumu; salÄ«dzinājumā ar citiem posmiem nav lielu pieskaitāmu izmaksu, taču joprojām ir vērts apsvērt iespēju klientam saņemt apjomÄ«gu atbildi no mezgla (piemēram, viedo lÄ«gumu). datu masÄ«va atgrieÅ”ana). Jebkurā gadÄ«jumā Å”is punkts ir vissvarÄ«gākais tam, kurÅ” uzdeva jautājumu ā€œcik tps ir jÅ«su blokķēdē?ā€, jo Uz Å”o brÄ«di tiek fiksēts pakalpojuma saņemÅ”anas laiks.

Å ajā vietā vienmēr tiek nosÅ«tÄ«ts pilns laiks, kas klientam bija jāpavada, gaidot atbildi no blokķēdes; tieÅ”i Å”ajā laikā lietotājs gaidÄ«s apstiprinājumu savā lietojumprogrammā, un tā ir tā optimizācija. izstrādātāju galvenais uzdevums.

Secinājums

Rezultātā mēs varam aprakstīt blokķēdes veikto darbību veidus un iedalīt tos vairākās kategorijās:

  1. kriptogrāfiskās transformācijas, pierādījumu konstrukcija
  2. peer-to-peer tīklu, darījumu un bloku replikāciju
  3. darījumu apstrāde, viedo līgumu izpilde
  4. blokķēdes izmaiņu piemēroÅ”ana valsts datu bāzei, datu par darÄ«jumiem un blokiem aktualizācija
  5. tikai lasāmi pieprasÄ«jumi valsts datu bāzei, blokķēdes mezgla API, abonÄ“Å”anas pakalpojumi

Kopumā mÅ«sdienu blokķēdes mezglu tehniskās prasÄ«bas ir ārkārtÄ«gi nopietnas - ātri CPU kriptogrāfijai, liels operatÄ«vās atmiņas apjoms, lai saglabātu un ātri piekļūtu stāvokļa datu bāzei, tÄ«kla mijiedarbÄ«ba, izmantojot lielu skaitu vienlaikus atvērtu savienojumu, un liela krātuve. Tik augstas prasÄ«bas un dažāda veida operāciju pārpilnÄ«ba neizbēgami noved pie tā, ka mezgliem var nepietikt resursu, un tad jebkurÅ” no iepriekÅ” apskatÄ«tajiem posmiem var kļūt par vēl vienu vājo vietu kopējā tÄ«kla veiktspējai.

Izstrādājot un novērtējot blokķēžu veiktspēju, jums bÅ«s jāņem vērā visi Å”ie punkti. Lai to izdarÄ«tu, vienlaicÄ«gi ir jāapkopo un jāanalizē metrika no klientiem un tÄ«kla mezgliem, jāmeklē korelācijas starp tiem, jānovērtē laiks, kas nepiecieÅ”ams pakalpojumu sniegÅ”anai klientiem, jāņem vērā visi galvenie resursi: cpu/atmiņa/tÄ«kls/atmiņa. , saprast, kā tie tiek izmantoti un ietekmēt viens otru. Tas viss padara dažādu blokķēžu ātrumu salÄ«dzināŔanu ā€œcik TPSā€ veidā par ārkārtÄ«gi nepateicÄ«gu uzdevumu, jo ir ļoti daudz dažādu konfigurāciju un stāvokļu. Lielās centralizētās sistēmās, simtiem serveru klasteros, arÄ« Ŕīs problēmas ir sarežģītas un arÄ« prasa savākt lielu skaitu dažādu metriku, bet blokķēdēs, pateicoties p2p tÄ«kliem, virtuālās maŔīnas, kas apstrādā lÄ«gumus, iekŔējās ekonomijas, grādu skaitu. brÄ«vÄ«ba ir daudz lielāka, kas padara testu pat vairākos serveros, tas nav indikatÄ«vs un parāda tikai ārkārtÄ«gi aptuvenas vērtÄ«bas, kurām nav gandrÄ«z nekādas saistÄ«bas ar realitāti.

Tāpēc, izstrādājot blokķēdes kodolā, lai novērtētu veiktspēju un atbildētu uz jautājumu ā€œvai tas ir uzlabojies salÄ«dzinājumā ar iepriekŔējo reizi?ā€, mēs izmantojam diezgan sarežģītu programmatÅ«ru, kas organizē blokķēdes palaiÅ”anu ar desmitiem mezglu un automātiski palaiž etalonu un apkopo metriku. ; bez Ŕīs informācijas ir ārkārtÄ«gi grÅ«ti atkļūdot protokolus, kas darbojas ar vairākiem dalÄ«bniekiem.

Tātad, kad saņemat jautājumu ā€œcik TPS ir jÅ«su blokķēdē?ā€, piedāvājiet savam sarunu biedram tēju un pajautājiet, vai viņŔ ir gatavs apskatÄ«t duci grafiku, kā arÄ« noklausÄ«ties visas trÄ«s blokķēdes veiktspējas problēmas un jÅ«su ieteikumus tos risinot...

Avots: www.habr.com

Pievieno komentāru