{"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 nella tua blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Una delle domande pi\u00f9 comuni che un non tecnico fa su qualsiasi sistema distribuito \u00e8 \"Qual \u00e8 il tuo tps nel blockchain?\" Tuttavia, il numero menzionato in risposta di solito ha poco a che fare con ci\u00f2 che il richiedente desidera sentire. In realt\u00e0, volevano chiedere \"il tuo blockchain soddisfa i miei requisiti aziendali?\", e questi requisiti non sono un singolo numero, ma una serie di condizioni: dal livello di tolleranza ai guasti della rete, alle necessit\u00e0 di finalit\u00e0, alle dimensioni, alla natura delle transazioni e a molti altri parametri. Quindi la risposta alla domanda \"quanti tps?\" difficilmente sar\u00e0 semplice e quasi mai sar\u00e0 completa. Un sistema distribuito con dozzine o centinaia di nodi che eseguono calcoli piuttosto complessi pu\u00f2 trovarsi in un numero enorme di stati diversi, legati allo stato della rete, ai contenuti del blockchain, ai guasti tecnici, ai problemi economici, agli attacchi alla rete e a molte altre ragioni. Le fasi in cui possono sorgere problemi di performance sono diverse rispetto ai servizi tradizionali, e un server di una rete blockchain \u00e8 un servizio di rete che combina le funzionalit\u00e0 di un database, di un web server e di un client torrent, rendendolo estremamente complesso in termini di profilo di carico su tutti i sottosistemi: processore, memoria, rete, storage.<\/p>\n

<\/p>\n

\u00c8 emerso che le reti decentralizzate e le blockchain sono un tipo di software piuttosto specifico e poco familiare per gli sviluppatori di software centralizzato. Pertanto, desidero evidenziare aspetti importanti delle prestazioni e della resilienza delle reti decentralizzate, i metodi per misurarle e per identificare i colli di bottiglia. Esamineremo varie problematiche di prestazione che limitano la velocit\u00e0 di fornitura dei servizi agli utenti delle blockchain, evidenziando le peculiarit\u00e0 caratteristiche di questo tipo di software.<\/p>\n

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

Fasi della richiesta di 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 qualche blockchain, ma se 900 transazioni sono state eseguite a velocit\u00e0 elevata mentre 100 hanno 'impiegato' alcuni secondi, allora il tempo medio calcolato su tutte le transazioni non \u00e8 una metrica completamente onesta per il cliente che non \u00e8 riuscito a completare la transazione in pochi secondi. Le 'buche temporali', causate da turni di consenso mancati o da segmentazioni della rete, possono compromettere seriamente un servizio che ha mostrato ottime prestazioni nei test.<\/p>\n

<\/p>\n

Per identificare tali bottleneck \u00e8 necessario avere una buona comprensione delle fasi in cui una blockchain reale pu\u00f2 avere difficolt\u00e0 a servire gli utenti. Descriviamo il ciclo di consegna e il processo di elaborazione delle transazioni, oltre alla ricezione del 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 viene formata sul client<\/li>\n
  2. la transazione viene firmata sul client<\/li>\n
  3. il cliente seleziona uno dei nodi e invia la propria transazione<\/li>\n
  4. il cliente si iscrive per ricevere aggiornamenti sul database di stato del nodo, aspettando i risultati dell'esecuzione della propria transazione<\/li>\n
  5. il nodo diffonde la transazione nella rete p2p<\/li>\n
  6. uno o pi\u00f9 BP (block producer) elaborano 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 recapitato al nodo a cui si rivolge il cliente<\/li>\n
  10. il nodo aggiorna il database di stato<\/li>\n
  11. il nodo rileva l'aggiornamento relativo al cliente e gli invia una notifica sulla transazione<\/li>\n<\/ol>\n

    <\/p>\n

    Esaminiamo pi\u00f9 in dettaglio queste fasi e descriviamo i potenziali problemi di performance in ogni fase. A differenza dei sistemi centralizzati, considereremo anche l'esecuzione del codice sui client della rete. Spesso, nel misurare il tps, il tempo di elaborazione delle transazioni viene raccolto dai nodi, e non dai client \u2014 questo non \u00e8 del tutto giusto. Al cliente non importa quanto velocemente un nodo ha elaborato la sua transazione; ci\u00f2 che conta di pi\u00f9 per lui \u00e8 il momento in cui le informazioni verificate su quella transazione, una volta incluse nella blockchain, gli saranno accessibili. Questa metrica \u00e8, in effetti, il tempo di esecuzione della transazione. Ci\u00f2 significa che diversi client, anche inviando la stessa transazione, possono ottenere tempi completamente diversi, a seconda del canale, del carico e della vicinanza del nodo, e cos\u00ec via. \u00c8 quindi assolutamente necessario misurare questo tempo sui client, poich\u00e9 \u00e8 proprio questo parametro che deve essere ottimizzato.<\/p>\n

    <\/p>\n

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

    <\/p>\n

    Iniziamo dai primi due punti: la transazione \u00e8 formata e firmata dal cliente. Stranamente, questo pu\u00f2 essere un collo di bottiglia nelle prestazioni della blockchain dal punto di vista del cliente. Questo \u00e8 insolito per i servizi centralizzati, dove tutti i calcoli e le operazioni sui dati sono gestiti da loro, mentre il cliente si limita a inviare una breve richiesta, capace di richiedere un grande volume 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, con compiti computazionali complessi delegati al software del client. Esistono clienti nelle blockchain che possono preparare una sola transazione per un lungo periodo (sto parlando di vari merkle proof, succinct proof, soglie di firma e altre operazioni complesse lato client). Un buon esempio di verifica on-chain leggera e di pesante preparazione della transazione lato client \u00e8 la prova di appartenenza a un elenco basata su Merkle-tree, ecco. articolo<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Non dimenticate che il codice client non invia semplicemente transazioni alla blockchain, ma prima richiede lo stato della blockchain \u2014 e questa attivit\u00e0 pu\u00f2 influenzare il carico della rete e dei nodi blockchain. Pertanto, durante le misurazioni, \u00e8 saggio emulare il comportamento del codice client nel modo pi\u00f9 completo possibile. Anche se nella vostra blockchain ci sono normalmente client leggeri che appongono una normale firma digitale sulla pi\u00f9 semplice delle transazioni relative a un asset, con ogni anno, il carico computazionale sul client sta aumentando, gli algoritmi crittografici diventano sempre pi\u00f9 robusti e questa parte del processamento potrebbe diventare un significativo collo di bottiglia in futuro. Quindi, fate attenzione e non trascurate la situazione in cui in una transazione della durata di 3,5 secondi, 2,5 secondi vengono spesi per la preparazione e la firma della transazione, e 1 secondo per l'invio alla rete e l'attesa della risposta. Per valutare i rischi di apparizione 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 della sua accettazione nel pool delle transazioni. Questa fase \u00e8 simile a una normale richiesta a un database, il nodo deve registrare la transazione nel pool e iniziare a diffondere l'informazione tramite la rete p2p. L'approccio alla valutazione delle prestazioni qui \u00e8 simile a quello dei tradizionali microservizi Web API, con transazioni nelle blockchain che possono essere aggiornate e cambiare stato attivamente. In generale, l'aggiornamento delle informazioni sulla transazione in alcune blockchain pu\u00f2 verificarsi pi\u00f9 volte, ad esempio, a seguito di cambiamenti tra fork della catena o quando i BP segnalano l'intenzione di includere la transazione in un blocco. Le limitazioni sulla dimensione di questo pool e sul numero di transazioni in esso possono influenzare le prestazioni della blockchain. Se il pool delle transazioni \u00e8 saturo fino alla massima capacit\u00e0 possibile, o se non entra in memoria operativa, le prestazioni della rete possono diminuire drasticamente. Le blockchain non dispongono di strumenti centralizzati per proteggersi da flussi di messaggi spazzatura e, se la blockchain supporta transazioni di grande volume e basse commissioni, questo pu\u00f2 portare a un sovraccarico del pool delle transazioni \u2014 un ulteriore potenziale collo di bottiglia nelle prestazioni.<\/p>\n

    <\/p>\n

    Nelle blockchain, il cliente invia una transazione a qualsiasi nodo della blockchain che preferisce, l'hash della transazione \u00e8 generalmente noto al cliente anche prima dell'invio, quindi tutto ci\u00f2 di cui ha bisogno \u00e8 stabilire una connessione e, dopo la trasmissione, attendere che la blockchain aggiorni il suo stato includendo la transazione. \u00c8 importante notare che nella misurazione del 'tps' si possono ottenere risultati totalmente diversi a causa dei vari metodi di connessione al nodo della blockchain. Pu\u00f2 trattarsi di un normale HTTP RPC o di un WebSocket che consente di implementare un modello di 'iscrizione'. Nel secondo caso, il cliente ricever\u00e0 una notifica prima, e il nodo consumer\u00e0 meno risorse (soprattutto memoria e traffico) nelle risposte sullo stato della transazione. Pertanto, nella misurazione del 'tps', \u00e8 necessario considerare il metodo di connessione dei clienti ai nodi. Perci\u00f2, per valutare i rischi di questo collo di bottiglia, il benchmark della blockchain deve essere in grado di emulare clienti con richieste WebSocket e HTTP RPC, in proporzioni che corrispondono a quelle delle reti reali, oltre a variare la natura delle transazioni e la loro dimensione.<\/p>\n

    <\/p>\n

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

    <\/p>\n

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

    <\/p>\n

    Nei blockchain, il trasferimento di transazioni e blocchi tra i partecipanti avviene tramite il networking peer-to-peer (p2p). Le transazioni si propagano nella rete a partire da uno dei nodi fino a raggiungere i peer e i produttori di blocchi, che confezionano le transazioni in blocchi e distribuiscono i nuovi blocchi a tutti i nodi della rete utilizzando lo stesso sistema p2p. La base della maggior parte delle moderne reti p2p sono diverse 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, da cui si pu\u00f2 comprendere che questo tipo di reti \u00e8 pi\u00f9 complesso e meno prevedibile rispetto a una rete centralizzata rigidamente configurata. Inoltre, ecco<\/a><\/noindex> un articolo che misura varie metriche interessanti per i nodi Ethereum.<\/p>\n

    <\/p>\n

    In breve, ogni peer in queste reti mantiene la propria lista dinamica di altri peer da cui richiede blocchi di informazioni, indirizzati per contenuto. Al ricevimento di una richiesta, il peer restituisce le informazioni richieste oppure passa la richiesta al prossimo peer pseudo-casuale della lista; una volta ottenuta la risposta, la rimanda a chi ha richiesto e la immagazzina in cache per un certo periodo, fornendo quel blocco informativo pi\u00f9 rapidamente la prossima volta. In questo modo, le informazioni popolari si trovano in molte cache di un gran numero di peer, mentre quelle impopolari vengono gradualmente eliminate. I peer tengono traccia di quante informazioni sono state trasferite tra di loro e la rete cerca di incentivare i distributori attivi, aumentando il loro punteggio e fornendo loro un livello di servizio pi\u00f9 elevato, escludendo automaticamente i partecipanti inattivi dalle liste dei peer.<\/p>\n

    <\/p>\n

    Ora la transazione deve essere diffusa nella rete affinch\u00e9 venga vista dai block-producer e inclusa nel blocco. Il nodo 'distribuisce' attivamente la nuova transazione a tutti gli interessati e ascolta la rete, attendendo il blocco in cui apparir\u00e0 la transazione necessaria, per notificare il cliente in attesa. Il tempo necessario affinch\u00e9 la rete scambi informazioni sulle nuove transazioni e sui blocchi nelle reti p2p dipende da un'enorme quantit\u00e0 di fattori: dal numero di nodi onesti e funzionanti (dal punto di vista della rete) vicini, dalla 'temperatura' delle cache di questi nodi, dalla dimensione dei blocchi, dalle transazioni, dalla natura delle modifiche, dalla geografia della rete, dal numero di nodi e da molti altri fattori. Le misurazioni complesse delle metriche di prestazione in tali reti sono un compito difficile, \u00e8 necessario valutare simultaneamente il tempo di elaborazione delle richieste sia sui clienti che sui peer (nodi blockchain). Problemi in uno qualsiasi dei meccanismi p2p, espulsione e caching errati dei dati, gestione inefficace delle liste di peer attivi e molti altri fattori possono causare ritardi che influenzano l'efficienza dell'intera rete, e questo collo di bottiglia \u00e8 il pi\u00f9 difficile da analizzare, testare e interpretare.<\/p>\n

    <\/p>\n

    El processamento della catena di blocchi e l'aggiornamento del database di stato<\/h2>\n

    <\/p>\n

    La parte pi\u00f9 importante del lavoro della blockchain \u00e8 l'algoritmo di consenso, la sua applicazione ai nuovi blocchi ricevuti dalla rete e l'elaborazione delle transazioni con registrazione dei risultati nel database di stato. L'aggiunta di un nuovo blocco alla catena e la successiva selezione della catena principale devono funzionare il pi\u00f9 rapidamente possibile. Tuttavia, nella vita reale 'deve' non significa 'funziona', e si pu\u00f2, ad esempio, immaginare una situazione in cui due lunghe catene concorrenti passano costantemente l'una all'altra, cambiando i metadati di migliaia di transazioni nel pool ad ogni switch, e producendo costanti rollback dello stato del database. Questo stadio, in termini di identificazione del collo di bottiglia, \u00e8 pi\u00f9 semplice rispetto al livello p2p della rete, poich\u00e9 l'esecuzione delle transazioni e l'algoritmo di consenso sono strettamente deterministici, e misurare qualcosa qui \u00e8 pi\u00f9 semplice.
    \nLa cosa principale \u00e8 non confondere la degradazione casuale delle prestazioni di questa fase con i problemi di rete: i nodi restituiscono i blocchi e le informazioni sulla catena principale pi\u00f9 lentamente e per il cliente esterno questo pu\u00f2 apparire come una rete lenta, mentre il problema si trova in un altro luogo.<\/p>\n

    <\/p>\n

    Per ottimizzare le prestazioni, \u00e8 utile raccogliere e monitorare le metriche direttamente dalle nodi, includendo quelle relative all'aggiornamento del database di stato: il numero di blocchi elaborati dal nodo, la loro dimensione, il numero di transazioni, il numero di switch tra fork delle catene, il numero di blocchi non validi, il tempo di funzionamento della macchina virtuale, il tempo di finalizzazione dei dati, ecc. Questo aiuter\u00e0 a non confondere i problemi di rete con gli errori negli algoritmi di elaborazione delle catene.<\/p>\n

    <\/p>\n

    La macchina virtuale che elabora 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 di lettura\/scrittura e altre metriche relative all'efficienza di esecuzione del codice dei contratti possono fornire molte informazioni preziose agli sviluppatori. Allo stesso tempo, i contratti smart sono programmi e, pertanto, in teoria, possono consumare qualsiasi risorsa: cpu\/memoria\/rete\/memorizzazione, quindi il processo di elaborazione delle transazioni \u00e8 una fase piuttosto indeterminata che cambia notevolmente con il passaggio tra versioni e con la modifica del codice dei contratti. Pertanto, anche le metriche relative all'elaborazione delle transazioni sono necessarie per un'ottimizzazione efficace delle prestazioni della blockchain.<\/p>\n

    <\/p>\n

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

    <\/p>\n

    Questo \u00e8 l'ultimo stadio di ottenimento del servizio da parte del cliente della blockchain, rispetto ad altre fasi, qui non ci sono grandi sovraccarichi, ma vale comunque la pena considerare la possibilit\u00e0 che il cliente riceva una risposta volumetrica dal nodo (ad esempio uno smart contract che restituisce un array di dati). In ogni caso, questo momento \u00e8 il pi\u00f9 importante per chi ha posto la domanda 'quanti tps ha la vostra blockchain?', poich\u00e9 \u00e8 in questo momento che si registra il tempo di ottenimento del servizio. <\/p>\n

    <\/p>\n

    In questo punto \u00e8 fondamentale inviare il tempo totale che il cliente ha dovuto attendere per ricevere una risposta dalla blockchain; proprio questo tempo \u00e8 quello che l'utente si aspetter\u00e0 di vedere confermato nella propria applicazione, e la sua ottimizzazione \u00e8 la principale responsabilit\u00e0 degli sviluppatori.<\/p>\n

    <\/p>\n

    Conclusione<\/h1>\n

    <\/p>\n

    Di conseguenza, si possono descrivere i tipi di operazioni che si svolgono nelle blockchain e dividerle in diverse categorie:<\/p>\n

    <\/p>\n

      \n
    1. trasformazioni crittografiche, costruzione di prove<\/li>\n
    2. networking 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 delle informazioni su transazioni e blocchi<\/li>\n
    5. richieste in sola lettura al database di stato, nodi API blockchain, servizi di abbonamento <\/li>\n<\/ol>\n

      <\/p>\n

      In generale, i requisiti tecnici per i nodi dei moderni blockchain sono estremamente severi: ci vogliono CPU veloci per la crittografia, una grande quantit\u00e0 di memoria RAM per memorizzare e accedere rapidamente al database di stato, un'interazione di rete che utilizzi un gran numero di connessioni aperte contemporaneamente, e uno storage ampio. Queste elevate richieste e la variet\u00e0 di operazioni comportano inevitabilmente che le risorse dei nodi possano non essere sufficienti, e in tal caso, qualsiasi fase esaminata potrebbe diventare un ulteriore collo di bottiglia per le prestazioni complessive della rete.<\/p>\n

      <\/p>\n

      Sviluppando e valutando le prestazioni delle blockchain, \u00e8 necessario tenere conto di tutti questi fattori. Per fare ci\u00f2, occorre raccogliere e analizzare metriche sia dai clienti che dai nodi della rete, cercare correlazioni tra di esse, valutare il tempo di risposta ai clienti, considerare tutte le risorse principali: cpu\/memory\/network\/storage, e comprendere come vengono utilizzate e come influiscono l'una sull'altra. Tutto ci\u00f2 rende estremamente difficile il confronto delle velocit\u00e0 delle diverse blockchain in termini di \"quanti TPS\", poich\u00e9 esiste un'enorme variet\u00e0 di configurazioni e stati. Nelle grandi sistemi centralizzati, come i cluster di centinaia di server, questi problemi sono altrettanto complessi e richiedono la raccolta di un gran numero di metriche, ma nelle blockchain, a causa delle reti p2p, delle macchine virtuali, dei contratti elaborati, e dell'economia interna, il numero di gradi di libert\u00e0 \u00e8 molto maggiore, rendendo il test anche su pochi server poco rappresentativo e mostrando solo valori estremamente approssimativi, quasi privi di connessione con la realt\u00e0.<\/p>\n

      <\/p>\n

      Pertanto, nella sviluppo del core delle 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 avvia automaticamente i benchmark e la raccolta delle metriche. Senza queste informazioni, \u00e8 estremamente difficile debuggare i protocolli che operano con molti partecipanti.<\/p>\n

      <\/p>\n

      Quindi, ricevuto il quesito \"quanti TPS ha la tua blockchain?\", offrite al vostro interlocutore un t\u00e8 e chiedete se \u00e8 disposto a esaminare una dozzina di grafici e a ascoltare tutti i vari problemi legati alle prestazioni delle blockchain e le vostre proposte per risolverli...<\/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\udd47Quanti TPS ci sono nella vostra blockchain? | ProHoster","description":"La domanda preferita di qualsiasi persona non tecnica riguardo a un sistema distribuito \u00e8: \u201cQuanti tps ci sono nella vostra blockchain?\u201d.","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}]}}