{"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\/it\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"Quanti TPS ci sono nel tuo blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La domanda preferita su qualsiasi sistema distribuito da un non tecnico \u00e8 \"Quanti tps ha la vostra blockchain?\" Tuttavia, il numero menzionato in risposta ha solitamente poco a che fare con quello che il domandante vorrebbe sentire. In realt\u00e0, voleva chiedere \"La vostra blockchain soddisfa le mie esigenze aziendali?\", e questi requisiti non sono un numero unico, ma una serie di condizioni: resilienza della rete, requisiti di finalit\u00e0, dimensioni, natura delle transazioni e molti altri parametri. Quindi, la risposta alla domanda \"quanti tps\" difficilmente sar\u00e0 semplice e quasi mai completa. Un sistema distribuito con decine e centinaia di nodi che eseguono calcoli complessi pu\u00f2 trovarsi in una grande variet\u00e0 di stati diversi, legati allo stato della rete, al contenuto della blockchain, ai guasti tecnici, ai problemi economici, agli attacchi alla rete e molte altre cause. Le fasi in cui possono verificarsi problemi di prestazioni sono diverse rispetto ai servizi tradizionali, e il server della rete blockchain \u00e8 un servizio di rete che combina le funzionalit\u00e0 di un database, un web server e un client torrent, rendendolo estremamente complesso in termini di carico su tutti i sottosistemi: CPU, memoria, rete, storage.<\/p>\n

<\/p>\n

\u00c8 successo che le reti decentralizzate e le blockchain siano un software piuttosto specifico e insolito per gli sviluppatori di software centralizzato. Pertanto, vorrei trattare gli aspetti importanti delle prestazioni e della resilienza delle reti decentralizzate, i metodi per misurarli e individuare i colli di bottiglia. Esamineremo diversi problemi di prestazioni che limitano la velocit\u00e0 di servizio agli utenti delle blockchain e evidenzieremo le caratteristiche specifiche di questo tipo di software.<\/p>\n

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

Fasi di richiesta del servizio da parte del cliente della blockchain<\/h2>\n

<\/p>\n

Per parlare onestamente della qualit\u00e0 di qualsiasi servizio complesso, \u00e8 necessario considerare non solo i valori medi, ma anche i massimi\/minimi, le mediane e i percentili. Teoricamente, si pu\u00f2 parlare di 1000 tps in un blockchain, ma se 900 transazioni sono state completate rapidamente e 100 sono \"bloccate\" per alcuni secondi, allora il tempo medio calcolato su tutte le transazioni non \u00e8 una metrica del tutto onesta per un cliente che non riesce a completare una transazione in pochi secondi. Le 'fosse' temporali, causate da turni di consenso persi o dalla separazione della rete, possono compromettere gravemente un servizio che in laboratorio ha mostrato un'ottima prestazione.<\/p>\n

<\/p>\n

Per identificare tali colli di bottiglia \u00e8 necessario comprendere bene le fasi in cui una blockchain reale pu\u00f2 avere difficolt\u00e0 nel servire gli utenti. Descriviamo il ciclo di consegna e il processo di elaborazione delle transazioni, cos\u00ec come l'ottenimento di un nuovo stato della blockchain, da cui il cliente pu\u00f2 verificare che la sua transazione sia stata elaborata e registrata.<\/p>\n

<\/p>\n

    \n
  1. la transazione si forma sul cliente<\/li>\n
  2. la transazione viene firmata sul cliente<\/li>\n
  3. il cliente sceglie uno dei nodi e invia la propria transazione a esso<\/li>\n
  4. il cliente si iscrive agli aggiornamenti del database di stato del nodo, in attesa dell'arrivo dei risultati dell'esecuzione della propria transazione<\/li>\n
  5. il nodo diffonde la transazione nella rete p2p<\/li>\n
  6. pi\u00f9 di un BP (block producer) elabora le transazioni accumulate, aggiornando il database di stato<\/li>\n
  7. il BP forma un nuovo blocco, elaborando il numero necessario di transazioni<\/li>\n
  8. il BP diffonde il nuovo blocco nella rete p2p<\/li>\n
  9. il nuovo blocco viene consegnato al nodo a cui si rivolge il cliente<\/li>\n
  10. il nodo aggiorna il database di stato<\/li>\n
  11. il nodo vede l'aggiornamento relativo al cliente e gli invia una notifica sulla transazione<\/li>\n<\/ol>\n

    <\/p>\n

    Ora analizziamo in dettaglio queste fasi e descriviamo i potenziali problemi di prestazioni in ciascuna fase. A differenza dei sistemi centralizzati, esamineremo anche l'esecuzione del codice sui client della rete. Spesso, quando si misura il tps, il tempo di elaborazione delle transazioni viene raccolto dai nodi, e non dal client: questo non \u00e8 del tutto corretto. Al cliente non importa quanto velocemente il nodo ha elaborato la sua transazione; ci\u00f2 che conta per lui \u00e8 il momento in cui le informazioni affidabili su questa transazione, incluse nella blockchain, diventeranno disponibili per lui. Questa metrica \u00e8 fondamentalmente il tempo di esecuzione della transazione. Ci\u00f2 significa che diversi client, anche inviando la stessa transazione, possono ottenere tempi completamente diversi, che dipendono dal canale, dal carico e dalla vicinanza del nodo, ecc. Quindi, \u00e8 assolutamente necessario misurare questo tempo sui client, poich\u00e9 \u00e8 questo parametro che deve essere ottimizzato.<\/p>\n

    <\/p>\n

    Preparazione della transazione sul lato client<\/h2>\n

    <\/p>\n

    Iniziamo con i primi due punti: la transazione viene formata e firmata dal client. Stranamente, questo pu\u00f2 anche essere un collo di bottiglia per le prestazioni della blockchain dal punto di vista del client. \u00c8 insolito per i servizi centralizzati, che gestiscono tutti i calcoli e le operazioni sui dati, mentre il client si limita a preparare una richiesta breve, capace di richiedere grandi volumi di dati o calcoli, ricevendo un risultato pronto. Nelle blockchain, il codice client diventa sempre pi\u00f9 potente, mentre il nucleo della blockchain diventa sempre pi\u00f9 leggero, e i compiti di calcolo complessi vengono affidati al software client. Nelle blockchain esistono client che possono impiegare molto tempo a preparare una transazione (parlo di vari merkle proof, succinct proof, firme threshold e altre operazioni complesse sul lato client). Un buon esempio di verifica on-chain leggera e di preparazione pesante della transazione sul client \u00e8 la prova di appartenenza a un elenco basata su Merkle-tree. su Habr.<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Inoltre, non bisogna dimenticare che il codice client non si limita a inviare transazioni alla blockchain, ma prima richiede lo stato della blockchain, e questa attivit\u00e0 pu\u00f2 influenzare il carico della rete e dei nodi blockchain. Pertanto, durante le misurazioni, \u00e8 sensato emulare il comportamento del codice client nel modo pi\u00f9 completo possibile. Anche se nella vostra blockchain ci sono normali client leggeri che appongono una comune firma digitale su una semplice transazione di trasferimento di un asset, ogni anno il carico computazionale sul client continua a crescere, gli algoritmi crittografici diventano pi\u00f9 robusti, e questa parte del processamento potrebbe trasformarsi in un considerevole collo di bottiglia in futuro. Pertanto, \u00e8 importante prestare attenzione e non trascurare situazioni in cui, in una transazione che dura 3,5 secondi, 2,5 secondi vengono spesi per la preparazione e la firma della transazione, e 1,0 secondo per l'invio nella rete e l'attesa della risposta. Per valutare i rischi di comparsa di questo collo di bottiglia \u00e8 necessario raccogliere metriche dalle macchine client, e non solo dai nodi blockchain.<\/p>\n

    <\/p>\n

    Invio della transazione e monitoraggio del suo stato<\/h2>\n

    <\/p>\n

    La fase successiva consiste nell'invio della transazione al nodo blockchain selezionato e nella ricezione dello stato di accettazione nella pool delle transazioni. Questa fase \u00e8 simile a una normale richiesta a un database, il nodo deve registrare la transazione nella pool e iniziare a diffondere le informazioni attraverso la rete p2p. L'approccio per valutare le prestazioni qui \u00e8 simile alla valutazione del lavoro dei tradizionali microservizi Web API, poich\u00e9 le stesse transazioni nelle blockchain possono essere aggiornate e cambiare stato attivamente. In generale, l'aggiornamento delle informazioni sulla transazione in alcune blockchain pu\u00f2 avvenire pi\u00f9 volte, ad esempio durante i passaggi tra fork della catena o quando i BP comunicano l'intenzione di includere la transazione in un blocco. Le limitazioni sulla dimensione di questa pool e sul numero di transazioni in essa possono influenzare le prestazioni della blockchain. Se la pool delle transazioni \u00e8 saturata fino alla dimensione massima possibile, o non pu\u00f2 essere contenuta nella memoria operativa, le prestazioni della rete potrebbero diminuire drasticamente. Le blockchain non dispongono di mezzi di protezione centralizzati contro il flusso di messaggi spazzatura, e se la blockchain supporta transazioni di grande volume e commissioni basse, ci\u00f2 potrebbe portare a un sovraccarico della pool delle transazioni, rappresentando un ulteriore potenziale collo di bottiglia delle prestazioni.<\/p>\n

    <\/p>\n

    Nei blockchain, un cliente invia una transazione a qualsiasi nodo del blockchain che preferisce, l'hash della transazione \u00e8 solitamente noto al cliente prima dell'invio, quindi tutto ci\u00f2 che deve fare \u00e8 stabilire una connessione e, dopo la trasmissione, attendere che il blockchain cambi il proprio stato, includendo la sua transazione. Si noti che, misurando il 'tps', si possono ottenere risultati completamente diversi a seconda dei modi di connessione al nodo del blockchain. Questo pu\u00f2 essere un normale HTTP RPC o WebSocket, che consente di implementare il pattern 'subscribe'. Nel secondo caso, il cliente ricever\u00e0 una notifica prima, e il nodo consumer\u00e0 meno risorse (principalmente memoria e traffico) per rispondere sullo stato della transazione. Quindi, nella misurazione del 'tps', \u00e8 necessario considerare il modo in cui i clienti si connettono ai nodi. Pertanto, per valutare i rischi di questo collo di bottiglia, il benchmark del blockchain deve essere in grado di emulare clienti sia con richieste WebSocket che HTTP RPC, in proporzioni corrispondenti alle reti reali, e anche di variare la natura delle transazioni e la loro dimensione.<\/p>\n

    <\/p>\n

    Per valutare i rischi di questo colli di bottiglia \u00e8 necessario raccogliere anche metriche dalle macchine client, e non solo dai nodi blockchain.<\/p>\n

    <\/p>\n

    Trasmissione di transazioni e blocchi attraverso una rete p2p<\/h2>\n

    <\/p>\n

    Nei blockchain, per il trasferimento di transazioni e blocchi tra i partecipanti si utilizza il networking peer-to-peer (p2p). Le transazioni si diffondono attraverso la rete, a partire da uno dei nodi, fino a raggiungere i peer - produttori di blocchi, che impacchettano le transazioni in blocchi e, utilizzando lo stesso p2p, distribuiscono i nuovi blocchi a tutti i nodi della rete. La base della maggior parte delle moderne reti p2p \u00e8 costituita da varie modifiche del protocollo Kademlia. Ecco<\/a><\/noindex> una buona panoramica di questo protocollo, e ecco<\/a><\/noindex> un articolo con varie misurazioni nella rete BitTorrent, dal quale si pu\u00f2 capire che questo tipo di rete \u00e8 pi\u00f9 complesso e meno prevedibile rispetto a una rete centralizzata rigidamente configurata. Inoltre, ecco<\/a><\/noindex> un articolo sulla misurazione di diverse metriche interessanti per i nodi Ethereum.<\/p>\n

    <\/p>\n

    In breve, ogni peer in tali reti mantiene la propria lista dinamica di altri peer, da cui richiede blocchi di informazioni, che sono indirizzati in base al contenuto. Quando riceve una richiesta, un peer restituisce le informazioni necessarie oppure trasferisce la richiesta al successivo peer pseudocasuale della lista, e una volta ricevuta la risposta, la trasmette a chi ha richiesto e la memorizza in cache per un certo periodo, restituendo questo blocco di informazioni per primo la prossima volta. In questo modo, le informazioni popolari si trovano in un gran numero di cache di molti peer, mentre quelle non popolari vengono gradualmente espulse. I peer registrano quanto e a chi hanno trasferito informazioni, e la rete cerca di incentivare i distributori attivi, aumentando il loro punteggio e garantendo loro un livello di servizio maggiore, espellendo automaticamente i partecipanti inattivi dalle liste dei peer.<\/p>\n

    <\/p>\n

    Quindi, ora \u00e8 necessario diffondere la transazione nella rete affinch\u00e9 i produttori di blocchi possano vederla e includerla nel blocco. Il nodo \u00abdistribuisce\u00bb attivamente la nuova transazione a chiunque lo desideri e ascolta la rete, aspettando il blocco in cui apparir\u00e0 la transazione desiderata, per notificare il cliente in attesa. Il tempo necessario affinch\u00e9 la rete trasferisca informazioni sulle nuove transazioni e blocchi nelle reti p2p dipende da un'enorme quantit\u00e0 di fattori: il numero di nodi onesti e funzionanti in prossimit\u00e0 (dal punto di vista della rete), la \u00abtemperatura\u00bb delle cache di questi nodi, la dimensione dei blocchi, delle transazioni, la natura delle modifiche, la geografia della rete, il numero di nodi e molti altri fattori. Misurare le metriche delle prestazioni in tali reti \u00e8 un compito complesso, poich\u00e9 \u00e8 necessario valutare contemporaneamente il tempo di elaborazione delle richieste sia sui clienti che sui peer (nodi blockchain). Problemi in uno qualsiasi dei meccanismi p2p, una gestione inadeguata dell'espulsione e della cache dei dati, una gestione non efficiente delle liste di peer attivi e molti altri fattori possono causare ritardi, influenzando l'efficienza dell'intera rete, e questo collo di bottiglia \u00e8 il pi\u00f9 difficile da analizzare, testare e interpretare i risultati.<\/p>\n

    <\/p>\n

    Processamento della catena di blocchi e aggiornamento del database di stato<\/h2>\n

    <\/p>\n

    La parte pi\u00f9 importante del funzionamento della blockchain \u00e8 l'algoritmo di consenso, la sua applicazione ai nuovi blocchi ricevuti dalla rete e il processo di elaborazione delle transazioni con registrazione dei risultati nella state database. L'aggiunta di un nuovo blocco alla catena e la scelta della catena principale successiva devono avvenire il pi\u00f9 rapidamente possibile. Tuttavia, nella vita reale \u00abdeve\u00bb non significa \u00abfunziona\u00bb, e si pu\u00f2, ad esempio, immaginare una situazione in cui due lunghe catene concorrenti si alternano costantemente, cambiando i metadati di migliaia di transazioni nel pool ad ogni cambio, e producendo continui rollback dello stato della state database. Questo passaggio, in termini di identificazione del collo di bottiglia, \u00e8 pi\u00f9 semplice rispetto allo strato p2p della rete, poich\u00e9 l'esecuzione delle transazioni e l'algoritmo di consenso sono strettamente deterministici, e misurare qualcosa qui \u00e8 pi\u00f9 facile.
    \nL'importante \u00e8 non confondere una degradazione casuale delle prestazioni di questa fase con i problemi di rete: i nodi forniscono blocchi e informazioni sulla catena principale pi\u00f9 lentamente e per un cliente esterno questo pu\u00f2 apparire come una rete lenta, anche se il problema risiede altrove.<\/p>\n

    <\/p>\n

    Per ottimizzare le prestazioni in questa fase \u00e8 utile raccogliere e monitorare metriche dai nodi stessi, includendo quelle relative all'aggiornamento del state database: numero di blocchi elaborati sul nodo, la loro dimensione, numero di transazioni, numero di passaggi tra fork delle catene, numero di blocchi non validi, tempo di esecuzione della macchina virtuale, tempo di finalizzazione dei dati, ecc. Questo eviter\u00e0 di confondere problemi di rete con errori negli algoritmi di processing delle catene.<\/p>\n

    <\/p>\n

    La macchina virtuale che processa le transazioni pu\u00f2 essere una fonte utile di informazioni in grado di ottimizzare il funzionamento della blockchain. La quantit\u00e0 di allocazioni di memoria, il numero di istruzioni read\/write e altre metriche relative all'efficienza dell'esecuzione del codice dei contratti possono fornire molte informazioni preziose agli sviluppatori. Allo stesso tempo, i smart contract sono programmi, il che significa che possono in teoria consumare qualsiasi risorsa: cpu\/memory\/network\/storage, quindi il processing delle transazioni \u00e8 una fase piuttosto indeterminata, che inoltre cambia notevolmente passando tra versioni e modificando il codice dei contratti. Pertanto, le metriche relative al processing delle transazioni sono anch'esse necessarie per un'ottimizzazione efficace delle prestazioni della blockchain.<\/p>\n

    <\/p>\n

    Ricezione della notifica da parte del cliente sull'inclusione della transazione nella blockchain<\/h2>\n

    <\/p>\n

    Questa \u00e8 la fase finale per ricevere il servizio del cliente blockchain; rispetto alle altre fasi, qui non ci sono grandi spese generali, ma \u00e8 comunque importante considerare la possibilit\u00e0 che il cliente riceva una risposta ampia dal nodo (ad esempio, un contratto intelligente che restituisce un array di dati). In ogni caso, questo momento \u00e8 il pi\u00f9 importante per chi ha posto la domanda \"quanti tps ci sono nel vostro blockchain?\", poich\u00e9 \u00e8 in questo momento che si registra il tempo di ricezione del servizio. <\/p>\n

    <\/p>\n

    In questo punto deve essere sempre presente l'invio del tempo totale che il cliente ha dovuto attendere per ricevere una risposta dalla blockchain; proprio questo tempo il utente aspetter\u00e0 una conferma nella propria applicazione, e proprio l'ottimizzazione di questo \u00e8 l'obiettivo principale degli sviluppatori.<\/p>\n

    <\/p>\n

    Conclusione<\/h1>\n

    <\/p>\n

    Di conseguenza, \u00e8 possibile descrivere i tipi di operazioni che vengono eseguite nelle blockchain e dividerle in diverse categorie:<\/p>\n

    <\/p>\n

      \n
    1. trasformazioni crittografiche, costruzione di prove<\/li>\n
    2. rete peer-to-peer, replicazione di transazioni e blocchi<\/li>\n
    3. elaborazione delle transazioni, esecuzione di contratti intelligenti<\/li>\n
    4. applicazione delle modifiche nella blockchain al database di stato, aggiornamento dei dati su transazioni e blocchi<\/li>\n
    5. richieste di sola lettura al database di stato, API del nodo blockchain, servizi in abbonamento <\/li>\n<\/ol>\n

      <\/p>\n

      In generale, i requisiti tecnici per i nodi delle moderne blockchain sono estremamente severi: richiedono CPU veloci per la crittografia, grande quantit\u00e0 di memoria RAM per memorizzare e accedere rapidamente al database di stato, interazione di rete che utilizza un numero elevato di connessioni aperte simultaneamente, e spazio di archiviazione consistente. Tali requisiti elevati e la variet\u00e0 di operazioni inevitabilmente portano al fatto che le risorse nei nodi potrebbero non essere sufficienti, e quindi ciascuna delle fasi sopra menzionate potrebbe diventare un collo di bottiglia per le prestazioni complessive della rete.<\/p>\n

      <\/p>\n

      Sviluppando e valutando le prestazioni delle blockchain, dovrai prendere in considerazione tutti questi fattori. Per fare ci\u00f2, \u00e8 necessario raccogliere e analizzare metriche contemporaneamente dai clienti e dai nodi della rete, cercare correlazioni tra di essi, valutare i tempi di fornitura del servizio ai clienti, tenere conto di tutte le risorse principali: cpu\/memory\/network\/storage, comprendere come vengono utilizzate e come influiscono l'una sull'altra. Tutto questo rende il confronto delle velocit\u00e0 di diverse blockchain in termini di \"quanti TPS\" un compito estremamente ingrato, dato che esiste un'enorme variet\u00e0 di configurazioni e stati. Nelle grandi sistemi centralizzati, cluster di centinaia di server, questi problemi sono altrettanto complessi e richiedono raccolte di un gran numero di diverse metriche, ma nelle blockchain, a causa delle reti p2p, delle macchine virtuali, dei contratti in esecuzione, dell'economia interna, il numero dei gradi di libert\u00e0 \u00e8 molto maggiore, rendendo il test anche su pi\u00f9 server poco rappresentativo e mostrando solo valori estremamente indicativi, quasi privi di collegamento con la realt\u00e0.<\/p>\n

      <\/p>\n

      Pertanto, durante lo sviluppo nel nucleo della blockchain, per valutare le prestazioni e rispondere alla domanda \"\u00e8 migliorato rispetto all'ultima volta?\", utilizziamo un software piuttosto complesso, che orchestra il lancio della blockchain con decine di nodi e avvio automatico del benchmark e raccolta di metriche; senza queste informazioni, \u00e8 estremamente difficile debugare i protocolli che operano con molti partecipanti.<\/p>\n

      <\/p>\n

      Quindi, ricevendo la domanda \"quanti TPS ci sono nel vostro blockchain?\", offri al tuo interlocutore una tazza di t\u00e8 e chiedi se \u00e8 pronto a esaminare una dozzina di grafici e ascoltare tutte e tre le scatole dei problemi di prestazioni delle blockchain e le tue proposte per le loro soluzioni...<\/p>\n

      Fonte: 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\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\udd47Quante TPS ci sono nella vostra blockchain? | ProHoster","description":"La domanda preferita su qualsiasi sistema distribuito da un non tecnico \u00e8 'Quante TPS ci sono nella vostra blockchain?'","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}