{"id":36157,"date":"2019-10-31T22:09:55","date_gmt":"2019-10-31T19:09:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/skolko-tps-v-vashem-blokchejne\/"},"modified":"2019-10-31T22:09:55","modified_gmt":"2019-10-31T19:09:55","slug":"skolko-tps-v-vashem-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"Hur m\u00e5nga TPS har din blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En favoritfr\u00e5ga om alla distribuerade system fr\u00e5n en icke-teknisk specialist \u00e4r \"Hur m\u00e5nga tps har din blockchain?\" Men det nummer som anges i svaret har vanligtvis lite att g\u00f6ra med vad fr\u00e5gest\u00e4llaren egentligen vill veta. I sj\u00e4lva verket ville han fr\u00e5ga \"uppfyller din blockchain mina aff\u00e4rskrav?\", och dessa krav handlar inte om ett enda nummer, utan om flera villkor \u2014 inklusive n\u00e4tverksresiliens, finalitetskrav, storlekar, karakt\u00e4r p\u00e5 transaktioner och m\u00e5nga andra parametrar. S\u00e5 svaret p\u00e5 fr\u00e5gan \"hur m\u00e5nga tps\" \u00e4r knappast enkelt, och kommer n\u00e4stan aldrig att vara fullst\u00e4ndigt. Ett distribuerat system med tiotals och hundratals noder som utf\u00f6r ganska komplexa ber\u00e4kningar kan befinna sig i en stor m\u00e4ngd olika tillst\u00e5nd, kopplade till n\u00e4tverkets status, blockchainens inneh\u00e5ll, tekniska fel, ekonomiska problem, attacker p\u00e5 n\u00e4tverket och m\u00e5nga andra orsaker. De steg d\u00e4r prestandaproblem kan uppst\u00e5 skiljer sig fr\u00e5n traditionella tj\u00e4nster, och servern f\u00f6r blockchain-n\u00e4tverket \u00e4r en n\u00e4tverkstj\u00e4nst som kombinerar funktionerna av en databas, webbserver och torrentklient, vilket g\u00f6r den extremt komplex n\u00e4r det kommer till belastningsprofilen p\u00e5 alla delsystem: processor, minne, n\u00e4tverk, lagring.<\/p>\n

<\/p>\n

Det har visat sig att decentraliserade n\u00e4tverk och blockchains \u00e4r ganska specifik och ovanlig programvara f\u00f6r utvecklare av centraliserad programvara. D\u00e4rf\u00f6r skulle jag vilja belysa viktiga aspekter av prestanda och motst\u00e5ndskraft hos decentraliserade n\u00e4tverk, metoder f\u00f6r att m\u00e4ta dem och identifiera flaskhalsar. Vi kommer att granska olika prestandaproblem som begr\u00e4nsar hastigheten p\u00e5 tj\u00e4nster som tillhandah\u00e5lls till blockchain-anv\u00e4ndare och notera de egenskaper som \u00e4r typiska f\u00f6r denna typ av programvara.<\/p>\n

<\/a><\/noindex><\/p>\n

Steg f\u00f6r beg\u00e4ran av tj\u00e4nst fr\u00e5n blockchain-kunden<\/h2>\n

<\/p>\n

F\u00f6r att kunna tala \u00e4rligt om kvaliteten p\u00e5 vilken mer eller mindre komplex tj\u00e4nst som helst, m\u00e5ste man ta h\u00e4nsyn till s\u00e5v\u00e4l medelv\u00e4rden som maximal\/minimal, medianer och percentiler. Teoretiskt kan man tala om 1000 tps i en viss blockchain, men om 900 transaktioner genomf\u00f6rdes med extrem hastighet, medan 100 \"h\u00e4ngde\" i flera sekunder, s\u00e5 \u00e4r medeltiden som samlats in f\u00f6r alla transaktioner inte riktigt en r\u00e4ttvis metric f\u00f6r en kund som inte kunde slutf\u00f6ra sitt aff\u00e4rsavtal p\u00e5 n\u00e5gra sekunder. Tids \"f\u00e4llor\" orsakade av missade konsensusrundor eller n\u00e4tverksuppdelning kan kraftigt f\u00f6rs\u00e4mra en tj\u00e4nst som visade utm\u00e4rkt prestanda p\u00e5 testb\u00e4nkar.<\/p>\n

<\/p>\n

F\u00f6r att identifiera s\u00e5dana flaskhalsar \u00e4r det n\u00f6dv\u00e4ndigt att f\u00f6rst\u00e5 v\u00e4l de steg d\u00e4r en verklig blockchain kan uppleva sv\u00e5righeter med att betj\u00e4na anv\u00e4ndare. L\u00e5t oss beskriva leveranscykeln och bearbetningsprocessen f\u00f6r transaktionen, samt hur man f\u00e5r det nya tillst\u00e5ndet f\u00f6r blockkedjan, som kunden kan f\u00f6rs\u00e4kra sig om att hans transaktion har bearbetats och beaktats.<\/p>\n

<\/p>\n

    \n
  1. transaktionen skapas p\u00e5 klienten<\/li>\n
  2. transaktionen signeras p\u00e5 klienten<\/li>\n
  3. klienten v\u00e4ljer en av noderna och skickar sin transaktion till den<\/li>\n
  4. klienten prenumererar p\u00e5 uppdateringar av nodens state database och v\u00e4ntar p\u00e5 resultaten av sin transaktions genomf\u00f6rande<\/li>\n
  5. noden sprider transaktionen i p2p-n\u00e4tverket<\/li>\n
  6. flera eller en blockproducent (BP) bearbetar de ackumulerade transaktionerna och uppdaterar state database<\/li>\n
  7. BP skapar en ny block efter att ha bearbetat det n\u00f6dv\u00e4ndiga antalet transaktioner<\/li>\n
  8. BP sprider den nya blocken i p2p-n\u00e4tverket<\/li>\n
  9. den nya blocken levereras till noden som klienten kontaktar<\/li>\n
  10. noden uppdaterar state database<\/li>\n
  11. noden ser uppdateringen som ber\u00f6r klienten och skickar en avisering om transaktionen<\/li>\n<\/ol>\n

    <\/p>\n

    L\u00e5t oss nu g\u00e5 igenom dessa steg mer detaljerat och beskriva potentiella prestationsproblem vid varje steg. Till skillnad fr\u00e5n centraliserade system kommer vi ocks\u00e5 att titta p\u00e5 kodk\u00f6rning p\u00e5 n\u00e4tverksklienter. Ofta, n\u00e4r tps m\u00e4ts, samlas behandlingstiden f\u00f6r transaktioner in fr\u00e5n noder, inte fr\u00e5n klienten \u2014 det \u00e4r inte helt r\u00e4ttvist. Klienten bryr sig inte om hur snabbt noden har behandlat hans transaktion, det viktigaste f\u00f6r honom \u00e4r \u00f6gonblicket n\u00e4r korrekt information om den transaktionen, som inkluderats i blockkedjan, blir tillg\u00e4nglig f\u00f6r honom. Den metrik \u00e4r egentligen tiden f\u00f6r transaktionens genomf\u00f6rande. Det inneb\u00e4r att olika klienter, \u00e4ven om de skickar samma transaktion, kan f\u00e5 helt olika tider, beroende p\u00e5 kanalen, belastningen och nodens n\u00e4rhet, osv. S\u00e5 det \u00e4r absolut n\u00f6dv\u00e4ndigt att m\u00e4ta denna tid p\u00e5 klienterna, eftersom det \u00e4r denna parameter som m\u00e5ste optimeras.<\/p>\n

    <\/p>\n

    F\u00f6reberedelse av transaktion p\u00e5 klientsidan<\/h2>\n

    <\/p>\n

    Vi b\u00f6rjar med de f\u00f6rsta tv\u00e5 punkterna: transaktionen skapas och signeras av klienten. Konstigt nog kan det h\u00e4r ocks\u00e5 vara en flaskhals f\u00f6r blockkedjans prestanda sett ur klientens perspektiv. Detta \u00e4r ovanligt f\u00f6r centraliserade tj\u00e4nster som tar hand om alla ber\u00e4kningar och databehandlingar, medan klienten bara f\u00f6rbereder en kort beg\u00e4ran som kan beg\u00e4ra en stor m\u00e4ngd data eller ber\u00e4kningar och sedan f\u00e5 det f\u00e4rdiga resultatet. I blockkedjor blir klientkoden allt mer kraftfull medan blockkedje-k\u00e4rnan blir allt mer l\u00e4ttviktig, och massiva ber\u00e4kningsuppgifter tenderar att \u00f6verl\u00e4mnas till klientprogramvara. I blockkedjor finns det klienter som kan f\u00f6rbereda en transaktion under l\u00e5ng tid (jag talar om olika merkle-bevis, succinct proof, threshold-signaturer och andra komplexa operationer p\u00e5 klientsidan). Ett bra exempel p\u00e5 l\u00e4tt on-chain verifiering och tung transaktionsberedning p\u00e5 klienten \u00e4r beviset f\u00f6r tillh\u00f6righet till en lista baserat p\u00e5 Merkle-tr\u00e4d, h\u00e4r. artikeln<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    T\u00e4nk ocks\u00e5 p\u00e5 att klientkoden inte bara skickar transaktioner till blockkedjan, utan f\u00f6rst beg\u00e4r tillst\u00e5ndet f\u00f6r blockkedjan \u2013 och denna aktivitet kan p\u00e5verka n\u00e4tverksbelastningen och blockkedjenoderna. D\u00e4rf\u00f6r, n\u00e4r du genomf\u00f6r m\u00e4tningar, \u00e4r det klokt att efterlikna klientkodens beteende s\u00e5 fullst\u00e4ndigt som m\u00f6jligt. \u00c4ven om din blockkedja har vanliga l\u00e4tta klienter som s\u00e4tter en vanlig digital signatur p\u00e5 en enkel transaktion f\u00f6r \u00f6verf\u00f6ring av n\u00e5got tillg\u00e5ng, \u00f6kar m\u00e4ngden ber\u00e4kningar p\u00e5 klienten med varje \u00e5r, kryptovalutaalgoritmerna st\u00e4rks, och denna del av processeringen kan bli en betydande flaskhals i framtiden. S\u00e5 var f\u00f6rsiktig s\u00e5 att du inte missar en situation d\u00e4r en transaktion, som varar i 3,5 sekunder, har 2,5 sekunder som g\u00e5r \u00e5t till f\u00f6rberedelse och signering av transaktionen, och 1,0 sekunder f\u00f6r att skicka till n\u00e4tverket och v\u00e4nta p\u00e5 svar. F\u00f6r att bed\u00f6ma riskerna f\u00f6r att denna flaskhals ska uppst\u00e5, beh\u00f6ver du samla in m\u00e4tv\u00e4rden fr\u00e5n klientmaskiner, och inte bara fr\u00e5n blockkedjenoder.<\/p>\n

    <\/p>\n

    Skicka transaktionen och \u00f6vervaka dess status<\/h2>\n

    <\/p>\n

    N\u00e4sta steg \u00e4r att skicka transaktionen till den valda blockkedjenoden och f\u00e5 status f\u00f6r dess acceptans i transaktionspoolen. Detta steg liknar ett vanligt databasanrop, noden m\u00e5ste skriva transaktionen i poolen och b\u00f6rja sprida information om den genom p2p-n\u00e4tverket. Tillv\u00e4gag\u00e5ngss\u00e4ttet f\u00f6r att bed\u00f6ma prestanda h\u00e4r liknar bed\u00f6mningen av traditionella mikrotj\u00e4nster i Web API, och sj\u00e4lvaste transaktionerna i blockkedjor kan uppdateras och aktivt f\u00f6r\u00e4ndra status. Generellt kan uppdateringen av transaktionsinformation i vissa blockkedjor ske flera g\u00e5nger, till exempel vid v\u00e4xling mellan forkar av kedjan eller n\u00e4r BP meddelar sin avsikt att inkludera transaktionen i en block. Begr\u00e4nsningar f\u00f6r volymen av denna pool och antalet transaktioner i den kan p\u00e5verka blockkedjans prestanda. Om transaktionspoolen \u00e4r full till maximalt m\u00f6jligt storlek, eller inte f\u00e5r plats i det interna minnet \u2013 kan n\u00e4tverkets prestanda falla dramatiskt. Blockkedjor har inte centraliserade skydd mot fl\u00f6den av skr\u00e4ppost, och om blockkedjan st\u00f6djer transaktioner med stora volymer och l\u00e5ga avgifter, kan detta leda till att transaktionspoolen \u00f6verfylls \u2013 detta \u00e4r ytterligare en potentiell flaskhals f\u00f6r prestanda.<\/p>\n

    <\/p>\n

    I blockchains skickar kunden en transaktion till vilken blockkedjenod som helst den gillar, hash av transaktionen \u00e4r vanligtvis k\u00e4nd f\u00f6r kunden redan f\u00f6re avs\u00e4ndningen, s\u00e5 allt som kr\u00e4vs \u00e4r att uppn\u00e5 en anslutning och sedan v\u00e4nta p\u00e5 att blockkedjan \u00e4ndrar sitt tillst\u00e5nd f\u00f6r att inkludera dess transaktion. Notera att m\u00e4tningen av \"tps\" kan ge helt olika resultat beroende p\u00e5 olika s\u00e4tt att ansluta till blockkedjenoden. Detta kan vara vanlig HTTP RPC eller WebSocket, vilket till\u00e5ter att implementera \"subscribe\" m\u00f6nstret. I det andra fallet f\u00e5r kunden en notifikation snabbare, och noden kommer att anv\u00e4nda mindre resurser (fr\u00e4mst minne och trafik) f\u00f6r att svara p\u00e5 transaktionens tillst\u00e5nd. S\u00e5 vid m\u00e4tning av \"tps\" \u00e4r det n\u00f6dv\u00e4ndigt att ta h\u00e4nsyn till hur kunder ansluter till noder. D\u00e4rf\u00f6r m\u00e5ste blockchainens benchmark kunna simulera kunder med b\u00e5de WebSocket och HTTP RPC-f\u00f6rfr\u00e5gningar, proportionellt till riktiga n\u00e4tverk, samt f\u00f6r\u00e4ndra typen av transaktioner och deras storlek.<\/p>\n

    <\/p>\n

    F\u00f6r att bed\u00f6ma risken f\u00f6r detta bottleneck \u00e4r det ocks\u00e5 viktigt att samla in metrik fr\u00e5n klientmaskiner, och inte bara fr\u00e5n blockchain-noder.<\/p>\n

    <\/p>\n

    \u00d6verf\u00f6ring av transaktioner och block \u00f6ver ett p2p-n\u00e4tverk<\/h2>\n

    <\/p>\n

    I blockchain anv\u00e4nds peer-to-peer (p2p) n\u00e4tverk f\u00f6r att \u00f6verf\u00f6ra transaktioner och block mellan deltagarna. Transaktioner sprids genom n\u00e4tverket, som b\u00f6rjar fr\u00e5n en av noderna, tills de n\u00e5r peer-block-producenter som packar in transaktionerna i block och sprider nya block genom hela n\u00e4tverket med samma p2p. Grunden f\u00f6r de flesta moderna p2p-n\u00e4tverk \u00e4r olika modifieringar av Kademlia-protokollet. H\u00e4r \u00e4r<\/a><\/noindex> en bra kort \u00f6versikt av detta protokoll, samt h\u00e4r<\/a><\/noindex> en artikel med olika m\u00e4tningar inom BitTorrent-n\u00e4tverket, d\u00e4r man kan f\u00f6rst\u00e5 att denna typ av n\u00e4tverk \u00e4r mer komplex och mindre f\u00f6ruts\u00e4gbar \u00e4n ett strikt konfigurerat n\u00e4tverk av en centraliserad tj\u00e4nst. Dessutom, h\u00e4r<\/a><\/noindex> en artikel om m\u00e4tning av olika intressanta metrik f\u00f6r Ethereum-noder.<\/p>\n

    <\/p>\n

    Sammanfattningsvis har varje peer i s\u00e5dana n\u00e4tverk sin egen dynamiska lista \u00f6ver andra peers, fr\u00e5n vilka den beg\u00e4r informationsblock som adresseras efter inneh\u00e5ll. N\u00e4r en beg\u00e4ran tas emot ger peer antingen den n\u00f6dv\u00e4ndiga informationen eller vidarebefordrar beg\u00e4ran till en pseudo-slumptals-peer fr\u00e5n listan och, efter att ha f\u00e5tt svar, vidarebefordrar den det till den beg\u00e4rande och cachar det under en tid, vilket g\u00f6r att den kan leverera detta informationsblock tidigare n\u00e4sta g\u00e5ng. P\u00e5 s\u00e5 s\u00e4tt hamnar popul\u00e4r information i m\u00e5nga cachar hos ett stort antal peers, medan mindre popul\u00e4r information gradvis tr\u00e4ngs ut. Peers h\u00e5ller reda p\u00e5 vem som har \u00f6verf\u00f6rt hur mycket information, och n\u00e4tverket f\u00f6rs\u00f6ker stimulera aktiva delare genom att \u00f6ka deras ranking och ge dem en h\u00f6gre serviceniv\u00e5, samtidigt som det automatiskt tr\u00e4nger ut inaktiva deltagare fr\u00e5n listorna \u00f6ver peers.<\/p>\n

    <\/p>\n

    Nu m\u00e5ste transaktionen spridas \u00f6ver n\u00e4tverket s\u00e5 att blockproducenterna kan se den och inkludera den i blocket. Noden \u201edistribuerar\u201c aktivt den nya transaktionen till alla intresserade och lyssnar p\u00e5 n\u00e4tverket, vilket v\u00e4ntar p\u00e5 ett block d\u00e4r den n\u00f6dv\u00e4ndiga transaktionen kommer att visas, f\u00f6r att informera den v\u00e4ntande klienten. Tiden det tar f\u00f6r n\u00e4tverket att \u00f6verf\u00f6ra information om nya transaktioner och block i p2p-n\u00e4tverk beror p\u00e5 ett stort antal faktorer: antalet \u00e4rliga, fungerande noder (ur n\u00e4tverkssynpunkt) n\u00e4ra varandra, \u201ev\u00e4rmen\u201c av dessa noder cache, blockens storlek, transaktioner, f\u00f6r\u00e4ndringarnas karakt\u00e4r, n\u00e4tverkets geografi, antalet noder och m\u00e5nga andra faktorer. Komplex m\u00e4tning av prestandan i s\u00e5dana n\u00e4tverk \u00e4r en sv\u00e5r uppgift, eftersom man m\u00e5ste bed\u00f6ma behandlingstiden f\u00f6r beg\u00e4rningar b\u00e5de p\u00e5 klienter och p\u00e5 peer-noder (blockchain-noder) samtidigt. Problem i n\u00e5got av p2p-mekanismerna, felaktig rensning och cachehantering av data, ineffektiv hantering av listor \u00f6ver aktiva peers, och m\u00e5nga andra faktorer kan orsaka f\u00f6rseningar som p\u00e5verkar hela n\u00e4tverkets effektivitet, och denna flaskhals \u00e4r den sv\u00e5raste att analysera, testa och tolka resultaten.<\/p>\n

    <\/p>\n

    Bearbetning av blockkedjan och uppdatering av state-databasen<\/h2>\n

    <\/p>\n

    Den viktigaste delen av blockchainens arbete \u00e4r konsensusalgoritmen, dess till\u00e4mpning p\u00e5 nya block som mottagits fr\u00e5n n\u00e4tverket och behandlingen av transaktioner med registrering av resultaten i state-databasen. Att l\u00e4gga till ett nytt block i kedjan och det efterf\u00f6ljande valet av huvudkedjan b\u00f6r fungera s\u00e5 snabbt som m\u00f6jligt. Men i verkliga livet betyder \u201eb\u00f6r\u201c inte n\u00f6dv\u00e4ndigtvis \u201efungerar\u201c, och man kan t\u00e4nka sig en situation d\u00e4r tv\u00e5 l\u00e5nga konkurrerande kedjor st\u00e4ndigt v\u00e4xlar mellan varandra, \u00e4ndrar metadata f\u00f6r tusentals transaktioner i poolen vid varje v\u00e4xling och medf\u00f6r kontinuerliga bak\u00e5tbelastningar av state-databasen. Detta steg, n\u00e4r det g\u00e4ller att identifiera flaskhalsar, \u00e4r enklare \u00e4n det n\u00e4tverksbaserade p2p-lagret, eftersom utf\u00f6randet av transaktioner och konsensusalgoritmen \u00e4r strikt deterministiskt, och att m\u00e4ta n\u00e5got h\u00e4r \u00e4r enklare.
    \nDet viktigaste \u00e4r att inte f\u00f6rv\u00e4xla tillf\u00e4llig nedgradering av prestanda vid detta steg med n\u00e4tverksproblem - noder \u00f6verl\u00e4mnar block och information om huvudkedjan mer l\u00e5ngsamt och f\u00f6r en extern klient kan detta verka som ett l\u00e5ngsamt n\u00e4tverk, \u00e4ven om problemet ligger p\u00e5 helt annat st\u00e4lle.<\/p>\n

    <\/p>\n

    F\u00f6r att optimera prestanda vid detta steg \u00e4r det bra att samla in och \u00f6vervaka m\u00e4tv\u00e4rden fr\u00e5n noderna sj\u00e4lva och inkludera de som r\u00f6r uppdateringen av state database: antal block som behandlas p\u00e5 noden, deras storlek, antal transaktioner, antal v\u00e4xlingar mellan kedjeforkar, antal ogiltiga block, tiden f\u00f6r virtuella maskinen, tiden f\u00f6r datalagring osv. Detta g\u00f6r det m\u00f6jligt att inte f\u00f6rv\u00e4xla n\u00e4tverksproblem med fel i kedjeprocesseringens algoritmer.<\/p>\n

    <\/p>\n

    Den processande maskinen f\u00f6r transaktioner kan vara en anv\u00e4ndbar informationsk\u00e4lla som kan optimera blockkedjans funktion. Antalet minnesallokeringar, antalet read\/write-instruktioner och andra m\u00e4tv\u00e4rden som r\u00f6r effektiviteten av kodens exekvering av kontrakt kan ge mycket anv\u00e4ndbar information till utvecklarna. Samtidigt \u00e4r smarta kontrakt program, vilket inneb\u00e4r att de i teorin kan konsumera alla typer av resurser: cpu\/memory\/network\/storage, s\u00e5 transaktionsprocesseringen \u00e4r en ganska os\u00e4ker fas, som dessutom f\u00f6r\u00e4ndras kraftigt vid \u00f6verg\u00e5ngar mellan versioner och \u00e4ndringar av kontraktskoden. D\u00e4rf\u00f6r beh\u00f6vs \u00e4ven m\u00e4tv\u00e4rden r\u00f6rande transaktionsprocessering f\u00f6r effektiv optimering av blockkedjans prestanda.<\/p>\n

    <\/p>\n

    Mottagande av kundnotification om aktivering av transaktion i blockkedjan<\/h2>\n

    <\/p>\n

    Detta \u00e4r det avslutande steget f\u00f6r kunden att f\u00e5 blockchain-tj\u00e4nsten. J\u00e4mf\u00f6rt med andra steg f\u00f6rekommer det inga stora driftskostnader h\u00e4r, men man b\u00f6r \u00e4nd\u00e5 ta h\u00e4nsyn till m\u00f6jligheten f\u00f6r kunden att f\u00e5 ett omfattande svar fr\u00e5n noden (till exempel ett smart kontrakt som returnerar en datam\u00e4ngd). I alla fall \u00e4r just detta \u00f6gonblick det mest avg\u00f6rande f\u00f6r den som st\u00e4ller fr\u00e5gan \"Hur m\u00e5nga TPS finns det i er blockchain?\", eftersom det \u00e4r d\u00e5 tiden f\u00f6r att f\u00e5 tj\u00e4nsten registreras. <\/p>\n

    <\/p>\n

    I detta steg m\u00e5ste den fulla tiden som kunden har spenderat p\u00e5 att v\u00e4nta p\u00e5 ett svar fr\u00e5n blockkedjan meddelas. Det \u00e4r denna tid som anv\u00e4ndaren kommer att v\u00e4nta p\u00e5 bekr\u00e4ftelse i sin applikation, och dess optimering \u00e4r huvuduppgiften f\u00f6r utvecklarna.<\/p>\n

    <\/p>\n

    Slutsats<\/h1>\n

    <\/p>\n

    Som ett resultat kan man beskriva typerna av operationer som genomf\u00f6rs i blockkedjor och dela in dem i flera kategorier:<\/p>\n

    <\/p>\n

      \n
    1. kryptografiska transformationer, bevisuppbyggnad<\/li>\n
    2. peer-to-peer-n\u00e4tverk, replikering av transaktioner och block<\/li>\n
    3. transaktionsbearbetning, utf\u00f6rande av smarta kontrakt<\/li>\n
    4. till\u00e4mpning av f\u00f6r\u00e4ndringar i blockkedjan mot state-databasen, uppdatering av transaktions- och blockdata<\/li>\n
    5. read-only-f\u00f6rfr\u00e5gningar till state-databasen, API f\u00f6r blockkedjenoden, prenumerationstj\u00e4nster <\/li>\n<\/ol>\n

      <\/p>\n

      De tekniska kraven p\u00e5 noderna i moderna blockkedjor \u00e4r \u00f6verlag mycket str\u00e4nga \u2014 det beh\u00f6vs snabba CPU:er f\u00f6r kryptografi, stor m\u00e4ngd RAM f\u00f6r att lagra och snabbt komma \u00e5t state-databasen, n\u00e4tverksinteraktion som anv\u00e4nder ett stort antal \u00f6ppna anslutningar samtidigt, och omfattande lagring. Dessa h\u00f6ga krav och m\u00e4ngden olika typer av operationer leder oundvikligen till att resurserna hos noderna kan bli otillr\u00e4ckliga, och d\u00e5 kan vilket som helst av de ovanst\u00e5ende stegen bli en flaskhals f\u00f6r n\u00e4tverkets totala prestanda.<\/p>\n

      <\/p>\n

      N\u00e4r du utvecklar och bed\u00f6mer blockkedjornas prestanda m\u00e5ste du ta h\u00e4nsyn till alla dessa faktorer. F\u00f6r detta \u00e4r det n\u00f6dv\u00e4ndigt att samla och analysera metrik fr\u00e5n b\u00e5de kunder och noder i n\u00e4tverket, leta efter korrelationer mellan dem, bed\u00f6ma tiden f\u00f6r att tillhandah\u00e5lla tj\u00e4nster till kunderna och beakta alla viktiga resurser: CPU \/ minne \/ n\u00e4tverk \/ lagring. Du m\u00e5ste f\u00f6rst\u00e5 hur dessa anv\u00e4nds och p\u00e5verkar varandra. Allt detta g\u00f6r j\u00e4mf\u00f6relsen av hastigheten mellan olika blockkedjor, ang\u00e5ende \"hur m\u00e5nga TPS\", till en otacksam uppgift eftersom det finns en stor m\u00e4ngd olika konfigurationer och tillst\u00e5nd. I stora centraliserade system med kluster av hundratals servrar \u00e4r dessa problem ocks\u00e5 komplexa och kr\u00e4ver insamling av m\u00e5nga olika m\u00e4tv\u00e4rden, men i blockkedjor, p\u00e5 grund av p2p-n\u00e4tverk, virtuella maskiner som bearbetar kontrakt och intern ekonomi, \u00e4r antalet frihetsgrader mycket st\u00f6rre, vilket g\u00f6r tester \u00e4ven p\u00e5 n\u00e5gra servrar ospecifika och visar endast extremt cirka v\u00e4rden som n\u00e4stan inte har n\u00e5gon relation till verkligheten.<\/p>\n

      <\/p>\n

      D\u00e4rf\u00f6r, vid utvecklingen av k\u00e4rnan i blockkedjan, f\u00f6r att bed\u00f6ma prestanda och svara p\u00e5 fr\u00e5gan \"Har det f\u00f6rb\u00e4ttrats j\u00e4mf\u00f6rt med f\u00f6rra g\u00e5ngen?\" anv\u00e4nder vi ganska avancerad programvara som orkestrerar k\u00f6rningen av blockkedjan med dussintals noder och automatiska k\u00f6rningar av benchmark och insamling av metrik. Utan denna information \u00e4r det extremt sv\u00e5rt att fels\u00f6ka protokoll som arbetar med m\u00e5nga deltagare.<\/p>\n

      <\/p>\n

      S\u00e5 n\u00e4r du f\u00e5r fr\u00e5gan \"Hur m\u00e5nga TPS finns det i er blockchain?\", erbjud din samtalspartner en kopp te och fr\u00e5ga om han \u00e4r redo att ta del av ett dussin diagram samt lyssna p\u00e5 alla tre stora problem g\u00e4llande blockkedjornas prestanda och dina f\u00f6rslag p\u00e5 hur de kan l\u00f6sas...<\/p>\n

      K\u00e4lla: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041b\u044e\u0431\u0438\u043c\u044b\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u043c \u043e \u043b\u044e\u0431\u043e\u0439 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u043e\u0442 \u043d\u0435\u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u201c\u0421\u043a\u043e\u043b\u044c\u043a\u043e tps \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435?\u201d. \u041e\u0434\u043d\u0430\u043a\u043e, \u043d\u0430\u0437\u0432\u0430\u043d\u043d\u043e\u0435 \u0432 \u043e\u0442\u0432\u0435\u0442 \u0447\u0438\u0441\u043b\u043e \u043e\u0431\u044b\u0447\u043d\u043e \u0438\u043c\u0435\u0435\u0442 \u043c\u0430\u043b\u043e \u043e\u0431\u0449\u0435\u0433\u043e \u0441 \u0442\u0435\u043c, \u0447\u0442\u043e \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0443\u0441\u043b\u044b\u0448\u0430\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0448\u0430\u044e\u0449\u0438\u0439. \u041d\u0430 \u0434\u0435\u043b\u0435, \u043e\u043d \u0445\u043e\u0442\u0435\u043b \u0441\u043f\u0440\u043e\u0441\u0438\u0442\u044c \u201c\u043f\u043e\u0434\u043e\u0439\u0434\u0435\u0442 \u043b\u0438 \u0432\u0430\u0448 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d \u043f\u043e\u0434 \u043c\u043e\u0438 \u0431\u0438\u0437\u043d\u0435\u0441 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f\u201d, \u0438 \u044d\u0442\u0438 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u043d\u0435 \u043e\u0434\u043d\u043e \u0447\u0438\u0441\u043b\u043e, \u0430 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0443\u0441\u043b\u043e\u0432\u0438\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36157","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Hur m\u00e5nga TPS har din blockkedja? | ProHoster","description":"Den favoritfr\u00e5gan om vilken distribuerad system som helst fr\u00e5n en icke-teknisk specialist \u00e4r 'Hur m\u00e5nga TPS har din blockkedja?'.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043a\u043e\u043b\u044c\u043a\u043e TPS \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435? | ProHoster","og:description":"\u041b\u044e\u0431\u0438\u043c\u044b\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u043c \u043e \u043b\u044e\u0431\u043e\u0439 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u043e\u0442 \u043d\u0435\u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u201c\u0421\u043a\u043e\u043b\u044c\u043a\u043e tps \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435?\u201d.","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:09:55+00:00","article:modified_time":"2019-10-31T19:09:55+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36157","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 02:15:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:49:44","updated":"2026-01-22 02:15:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}