{"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\/es\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"\u00bfCu\u00e1ntos TPS tiene su blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La pregunta favorita de cualquier persona no t\u00e9cnica sobre un sistema distribuido es \u201c\u00bfCu\u00e1ntos TPS tiene su blockchain?\u201d. Sin embargo, el n\u00famero mencionado en respuesta a menudo tiene poco que ver con lo que el preguntador desea escuchar. En realidad, quer\u00eda preguntar \u201c\u00bfse adaptar\u00e1 su blockchain a mis requisitos comerciales?\u201d, y estos requisitos no son un solo n\u00famero, sino un conjunto de condiciones: la resiliencia de la red, los requisitos de finalizaci\u00f3n, el tama\u00f1o, la naturaleza de las transacciones y muchos otros par\u00e1metros. As\u00ed que la respuesta a la pregunta \u201c\u00bfcu\u00e1ntos TPS?\u201d probablemente no ser\u00e1 simple, y casi nunca ser\u00e1 completa. Un sistema distribuido con decenas y cientos de nodos realizando c\u00e1lculos bastante complejos puede estar en una enorme cantidad de estados diferentes, relacionados con el estado de la red, el contenido del blockchain, fallos t\u00e9cnicos, problemas econ\u00f3micos, ataques a la red y muchas otras razones. Las etapas en las que pueden surgir problemas de rendimiento son diferentes de los servicios tradicionales, y el servidor de la red blockchain es un servicio en red que combina las funciones de una base de datos, un servidor web y un cliente de torrent, lo que lo hace extremadamente complejo en t\u00e9rminos de perfil de carga en todos los subsistemas: CPU, memoria, red, almacenamiento.<\/p>\n

<\/p>\n

Resulta que las redes descentralizadas y los blockchains son un software bastante espec\u00edfico y poco familiar para los desarrolladores de software centralizado. Por lo tanto, me gustar\u00eda destacar aspectos importantes del rendimiento y la resiliencia de las redes descentralizadas, enfoques para medirlas y localizar bottlenecks. Abordaremos diversos problemas de rendimiento que limitan la velocidad de entrega del servicio a los usuarios de blockchains y se\u00f1alaremos caracter\u00edsticas que son propias de este tipo de software.<\/p>\n

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

Fases de la solicitud de servicio del cliente de blockchain<\/h2>\n

<\/p>\n

Para hablar con honestidad sobre la calidad de cualquier servicio relativamente complejo, es necesario considerar no solo los valores medios, sino tambi\u00e9n los m\u00e1ximos\/m\u00ednimos, las medianas y los percentiles. Te\u00f3ricamente, se puede hablar de 1000 tps en alguna blockchain, pero si 900 transacciones se ejecutaron a gran velocidad y 100 'se quedaron colgadas' durante varios segundos, entonces el tiempo promedio recopilado de todas las transacciones no es una m\u00e9trica del todo justa para un cliente que no pudo completar una transacci\u00f3n en varios segundos. Los 'baches' temporales, causados por rondas de consenso omitidas o divisiones de red, pueden perjudicar seriamente un servicio que mostr\u00f3 un rendimiento excelente en bancos de pruebas.<\/p>\n

<\/p>\n

Para identificar tales cuellos de botella, es necesario entender bien las etapas en las que un blockchain real puede experimentar dificultades para atender a los usuarios. Describamos el ciclo de entrega y procesamiento de transacciones, as\u00ed como la obtenci\u00f3n de un nuevo estado del blockchain, del cual el cliente puede asegurarse de que su transacci\u00f3n ha sido procesada y contabilizada.<\/p>\n

<\/p>\n

    \n
  1. la transacci\u00f3n se forma en el cliente<\/li>\n
  2. la transacci\u00f3n se firma en el cliente<\/li>\n
  3. el cliente elige uno de los nodos y env\u00eda su transacci\u00f3n a \u00e9l<\/li>\n
  4. el cliente se suscribe a las actualizaciones de la base de datos de estado del nodo, esperando la aparici\u00f3n de los resultados de la ejecuci\u00f3n de su transacci\u00f3n<\/li>\n
  5. el nodo propaga la transacci\u00f3n a trav\u00e9s de la red p2p<\/li>\n
  6. varios o un BP (productor de bloques) procesan las transacciones acumuladas, actualizando la base de datos de estado<\/li>\n
  7. el BP forma un nuevo bloque, procesando la cantidad necesaria de transacciones<\/li>\n
  8. el BP propaga el nuevo bloque a trav\u00e9s de la red p2p<\/li>\n
  9. el nuevo bloque es entregado al nodo al que se dirige el cliente<\/li>\n
  10. el nodo actualiza la base de datos de estado<\/li>\n
  11. el nodo ve una actualizaci\u00f3n relacionada con el cliente y le env\u00eda una notificaci\u00f3n sobre la transacci\u00f3n<\/li>\n<\/ol>\n

    <\/p>\n

    Ahora analicemos estos pasos con m\u00e1s detalle y describamos los posibles problemas de rendimiento en cada etapa. A diferencia de los sistemas centralizados, tambi\u00e9n consideraremos la ejecuci\u00f3n del c\u00f3digo en los clientes de la red. Es bastante com\u00fan que al medir tps, el tiempo de procesamiento de las transacciones se obtenga de los nodos y no del cliente; esto no es del todo justo. Al cliente no le importa cu\u00e1n r\u00e1pido proces\u00f3 el nodo su transacci\u00f3n, lo m\u00e1s importante para \u00e9l es el momento en que la informaci\u00f3n verificada sobre esa transacci\u00f3n, incluida en la blockchain, est\u00e9 disponible para \u00e9l. Esta m\u00e9trica es, en esencia, el tiempo de ejecuci\u00f3n de la transacci\u00f3n. Esto significa que diferentes clientes, incluso al enviar la misma transacci\u00f3n, pueden obtener tiempos completamente diferentes, que dependen del canal, la carga y la cercan\u00eda del nodo, entre otros factores. Por lo tanto, es absolutamente necesario medir este tiempo en los clientes, ya que es este par\u00e1metro el que necesita ser optimizado.<\/p>\n

    <\/p>\n

    Preparaci\u00f3n de la transacci\u00f3n del lado del cliente<\/h2>\n

    <\/p>\n

    Empezaremos con los primeros dos puntos: la transacci\u00f3n se forma y se firma por el cliente. Curiosamente, esto tambi\u00e9n puede ser un cuello de botella para el rendimiento de la blockchain desde el punto de vista del cliente. Esto es inusual para los servicios centralizados, que realizan todos los c\u00e1lculos y operaciones con datos, mientras que el cliente solo prepara una breve solicitud capaz de solicitar grandes vol\u00famenes de datos o c\u00e1lculos, obteniendo un resultado listo. En las blockchains, el c\u00f3digo del cliente se vuelve cada vez m\u00e1s poderoso, mientras que el n\u00facleo de la blockchain se vuelve cada vez m\u00e1s liviano, y las tareas computacionales masivas se suelen delegar al software del cliente. En las blockchains, existen clientes que pueden preparar una transacci\u00f3n durante un tiempo considerable (hablo de diferentes pruebas de Merkle, pruebas concisas, firmas umbral y otras operaciones complejas del lado del cliente). Un buen ejemplo de verificaci\u00f3n on-chain ligera y preparaci\u00f3n pesada de la transacci\u00f3n en el cliente es la prueba de pertenencia a una lista basada en Merkle-tree. Windows<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Tambi\u00e9n es importante recordar que el c\u00f3digo del cliente no solo env\u00eda transacciones a la cadena de bloques, sino que primero consulta el estado de la cadena de bloques; y esta actividad puede afectar la carga de la red y de los nodos de la cadena de bloques. Por lo tanto, al realizar mediciones, es razonable emular lo m\u00e1s completamente posible el comportamiento del c\u00f3digo del cliente. Incluso si en su cadena de bloques hay clientes ligeros comunes que solo firman digitalmente una transacci\u00f3n sencilla de transferencia de alg\u00fan activo, cada a\u00f1o las computaciones masivas en el cliente siguen aumentando, los algoritmos criptogr\u00e1ficos se van volviendo m\u00e1s robustos, y esta parte del procesamiento puede convertirse en un bottleneck significativo en el futuro. As\u00ed que tenga cuidado, y no pase por alto la situaci\u00f3n en la que, durante una transacci\u00f3n que dura 3.5 segundos, 2.5 segundos se destinan a la preparaci\u00f3n y firma de la transacci\u00f3n, y 1.0 segundos a su env\u00edo a la red y la espera de la respuesta. Para evaluar los riesgos de aparici\u00f3n de este bottleneck, es necesario recopilar m\u00e9tricas de las m\u00e1quinas de los clientes, y no solo de los nodos de la cadena de bloques.<\/p>\n

    <\/p>\n

    Env\u00edo de transacciones y monitoreo de su estado<\/h2>\n

    <\/p>\n

    El siguiente paso es enviar la transacci\u00f3n al nodo de la cadena de bloques elegido y recibir el estado de su aceptaci\u00f3n en el grupo de transacciones. Este paso es similar a una consulta normal a una base de datos, el nodo debe registrar la transacci\u00f3n en el grupo y comenzar a difundir la informaci\u00f3n sobre ella a trav\u00e9s de la red p2p. El enfoque para evaluar el rendimiento aqu\u00ed es similar al de evaluar el funcionamiento de microservicios tradicionales de API web, de modo que las propias transacciones en las cadenas de bloques pueden actualizarse y cambiar de estado activamente. En general, la actualizaci\u00f3n de la informaci\u00f3n sobre la transacci\u00f3n en algunas cadenas de bloques puede ocurrir varias veces, por ejemplo, al cambiar entre bifurcaciones de la cadena o cuando los BP notifican sobre la intenci\u00f3n de incluir la transacci\u00f3n en un bloque. Las limitaciones sobre el tama\u00f1o de este grupo y la cantidad de transacciones en \u00e9l pueden influir en el rendimiento de la cadena de bloques. Si el grupo de transacciones est\u00e1 lleno hasta su tama\u00f1o m\u00e1ximo, o no cabe en la memoria RAM, el rendimiento de la red puede caer dr\u00e1sticamente. Las cadenas de bloques no tienen medios de protecci\u00f3n centralizados contra flujos de mensajes basura, y si la cadena de bloques admite transacciones de gran volumen y comisiones bajas, esto puede llevar a un desbordamiento del grupo de transacciones; este es otro potencial bottleneck de rendimiento.<\/p>\n

    <\/p>\n

    En las blockchains, el cliente env\u00eda una transacci\u00f3n a cualquier nodo de blockchain que le guste; el hash de la transacci\u00f3n generalmente es conocido por el cliente antes del env\u00edo, por lo que todo lo que necesita hacer es establecer la conexi\u00f3n y, tras la transferencia, esperar a que la blockchain cambie su estado, incorporando su transacci\u00f3n. Cabe se\u00f1alar que al medir 'tps' se pueden obtener resultados completamente diferentes seg\u00fan el m\u00e9todo de conexi\u00f3n al nodo de blockchain. Esto puede ser a trav\u00e9s de HTTP RPC convencional o WebSocket, que permite implementar el patr\u00f3n 'subscribe'. En este segundo caso, el cliente recibir\u00e1 una notificaci\u00f3n antes, y el nodo consumir\u00e1 menos recursos (principalmente memoria y tr\u00e1fico) en las respuestas sobre el estado de la transacci\u00f3n. Por lo tanto, al medir 'tps', es necesario tener en cuenta el m\u00e9todo de conexi\u00f3n de los clientes a los nodos. Por esta raz\u00f3n, para evaluar los riesgos de que aparezca este cuello de botella, el benchmark de la blockchain debe ser capaz de emular clientes tanto con WebSocket como con solicitudes HTTP RPC, en proporciones que correspondan a redes reales, as\u00ed como cambiar la naturaleza de las transacciones y su tama\u00f1o.<\/p>\n

    <\/p>\n

    Para evaluar los riesgos de aparici\u00f3n de este bottleneck, tambi\u00e9n es necesario recopilar m\u00e9tricas desde las m\u00e1quinas de los clientes, y no solo desde los nodos de la cadena de bloques.<\/p>\n

    <\/p>\n

    Transmisi\u00f3n de transacciones y bloques a trav\u00e9s de la red p2p<\/h2>\n

    <\/p>\n

    En las cadenas de bloques, se utiliza la red peer-to-peer (p2p) para la transmisi\u00f3n de transacciones y bloques entre los participantes. Las transacciones se propaguen por la red, comenzando desde uno de los nodos, hasta que alcanzan a los pares-productores de bloques, que empaquetan las transacciones en bloques y, utilizando el mismo p2p, distribuyen los nuevos bloques a todos los nodos de la red. La base de la mayor\u00eda de las redes p2p modernas son varias modificaciones del protocolo Kademlia. Aqu\u00ed<\/a><\/noindex> una buena visi\u00f3n general de este protocolo, y aqu\u00ed<\/a><\/noindex> \u2014 un art\u00edculo con diversas mediciones en la red BitTorrent, a partir del cual se puede entender \u2014 que este tipo de redes es m\u00e1s complejo y menos predecible que una red de servicio centralizada r\u00edgidamente configurada. Adem\u00e1s, aqu\u00ed<\/a><\/noindex> un art\u00edculo sobre la medici\u00f3n de diversas m\u00e9tricas interesantes para los nodos de Ethereum.<\/p>\n

    <\/p>\n

    En resumen, cada peer en estas redes mantiene su propia lista din\u00e1mica de otros peers a los que solicita bloques de informaci\u00f3n, los cuales se direccionan por contenido. Al recibir una solicitud, el peer proporciona la informaci\u00f3n requerida o reenv\u00eda la solicitud al siguiente peer pseudoaleatorio de la lista, y al obtener una respuesta, la env\u00eda al solicitante y la almacena en cach\u00e9 por un tiempo, entregando este bloque de informaci\u00f3n antes la pr\u00f3xima vez. As\u00ed, la informaci\u00f3n popular se encuentra en muchos cach\u00e9s de un gran n\u00famero de peers, mientras que la informaci\u00f3n impopular se desplaza gradualmente. Los peers llevan un registro de cu\u00e1nta informaci\u00f3n ha transferido cada uno, y la red intenta incentivar a los donantes activos, aumentando su clasificaci\u00f3n y proporcion\u00e1ndoles un mejor nivel de servicio, expulsando autom\u00e1ticamente a los participantes inactivos de las listas de peers.<\/p>\n

    <\/p>\n

    Ahora, la transacci\u00f3n debe distribuirse por la red para que los block producers la vean e ingresen en un bloque. El nodo est\u00e1 activamente 'repartiendo' la nueva transacci\u00f3n a todos los interesados y escucha la red, esperando el bloque en cuyo \u00edndice aparecer\u00e1 la transacci\u00f3n deseada para notificar al cliente en espera. El tiempo que tarda la red en intercambiar informaci\u00f3n sobre nuevas transacciones y bloques en redes p2p depende de una gran cantidad de factores: la cantidad de nodos honestos y operativos cercanos (desde un punto de vista de red), el 'calentamiento' de las cach\u00e9s de estos nodos, el tama\u00f1o de los bloques, las transacciones, la naturaleza de los cambios, la geograf\u00eda de la red, el n\u00famero de nodos y muchos otros factores. Las mediciones complejas de las m\u00e9tricas de rendimiento en estas redes son un asunto complicado; es necesario evaluar simult\u00e1neamente el tiempo de procesamiento de solicitudes tanto en los clientes como en los peers (nodos de blockchain). Los problemas en cualquiera de los mecanismos p2p, la eliminaci\u00f3n incorrecta y la cach\u00e9 de datos, la gesti\u00f3n ineficaz de listas de peers activos, y muchos otros factores pueden causar retrasos que afectan la eficiencia de toda la red en su conjunto, y este cuello de botella es el m\u00e1s dif\u00edcil de analizar, probar e interpretar los resultados.<\/p>\n

    <\/p>\n

    Procesamiento de la cadena de bloques y actualizaci\u00f3n de la base de datos de estado<\/h2>\n

    <\/p>\n

    La parte m\u00e1s importante del funcionamiento de la blockchain es el algoritmo de consenso, su aplicaci\u00f3n a nuevos bloques recibidos de la red y el procesamiento de transacciones con registro de resultados en la base de datos de estado. La adici\u00f3n de un nuevo bloque a la cadena y la selecci\u00f3n de la cadena principal que sigue debe funcionar lo m\u00e1s r\u00e1pido posible. Sin embargo, en la vida real, 'debe' no significa 'funciona', y se puede imaginar, por ejemplo, una situaci\u00f3n en la que dos largas cadenas en competencia cambian constantemente entre s\u00ed, modificando los metadatos de miles de transacciones en el pool en cada cambio y provocando retrocesos constantes en el estado de la base de datos. Esta etapa, en t\u00e9rminos de identificar el cuello de botella, es m\u00e1s simple que la capa de red p2p, ya que la ejecuci\u00f3n de transacciones y el algoritmo de consenso son estrictamente deterministas, y medir algo aqu\u00ed es m\u00e1s f\u00e1cil.
    \nLo principal es no confundir la degradaci\u00f3n aleatoria del rendimiento de esta etapa con problemas de red; los nodos devuelven bloques e informaci\u00f3n sobre la cadena principal m\u00e1s lentamente, y para un cliente externo esto puede parecer una red lenta, aunque el problema radica en otro lugar.<\/p>\n

    <\/p>\n

    Para optimizar el rendimiento en esta etapa, es \u00fatil recopilar y supervisar m\u00e9tricas de los propios nodos e incluir aquellas que se relacionan con la actualizaci\u00f3n de la base de datos de estado: el n\u00famero de bloques procesados en cada nodo, su tama\u00f1o, el n\u00famero de transacciones, la cantidad de cambios entre bifurcaciones de cadenas, el n\u00famero de bloques inv\u00e1lidos, el tiempo de ejecuci\u00f3n de la m\u00e1quina virtual, el tiempo de grabaci\u00f3n de datos, etc. Esto permitir\u00e1 no confundir problemas de red con errores en los algoritmos de procesamiento de cadenas.<\/p>\n

    <\/p>\n

    La m\u00e1quina virtual que procesa transacciones puede ser una fuente \u00fatil de informaci\u00f3n capaz de optimizar el funcionamiento de la blockchain. La cantidad de asignaciones de memoria, el n\u00famero de instrucciones de lectura\/escritura y otras m\u00e9tricas relacionadas con la eficiencia de la ejecuci\u00f3n del c\u00f3digo de contratos pueden proporcionar mucha informaci\u00f3n \u00fatil a los desarrolladores. Al mismo tiempo, los contratos inteligentes son programas, y eso significa que, en teor\u00eda, pueden consumir cualquiera de los recursos: CPU\/memoria\/red\/almacenamiento, por lo que el procesamiento de transacciones es una etapa bastante indefinida, que adem\u00e1s cambia significativamente al pasar entre versiones y al modificar el c\u00f3digo de los contratos. Por lo tanto, las m\u00e9tricas relacionadas con el procesamiento de transacciones tambi\u00e9n son necesarias para una optimizaci\u00f3n eficiente del rendimiento de la blockchain.<\/p>\n

    <\/p>\n

    Notificaci\u00f3n del cliente sobre la activaci\u00f3n de la transacci\u00f3n en la blockchain<\/h2>\n

    <\/p>\n

    Esta es la etapa final para que el cliente obtenga el servicio de blockchain. En comparaci\u00f3n con otras etapas, aqu\u00ed no hay grandes costos asociados, pero a\u00fan es importante considerar la posibilidad de que el cliente reciba una respuesta extensa de la nodo (por ejemplo, un contrato inteligente que devuelve un array de datos). En cualquier caso, este momento es crucial para quien se pregunta '\u00bfqu\u00e9 tps tiene su blockchain?', ya que es en este momento cuando se registra el tiempo de obtenci\u00f3n del servicio. <\/p>\n

    <\/p>\n

    En este punto, se debe enviar el tiempo completo que el cliente ha tardado en esperar la respuesta de la blockchain. Este es el tiempo que el usuario esperar\u00e1 para recibir la confirmaci\u00f3n en su aplicaci\u00f3n, y la optimizaci\u00f3n de este tiempo es la principal tarea de los desarrolladores.<\/p>\n

    <\/p>\n

    Conclusi\u00f3n<\/h1>\n

    <\/p>\n

    Como resultado, se pueden describir los tipos de operaciones que se realizan en las blockchains y dividirlas en varias categor\u00edas:<\/p>\n

    <\/p>\n

      \n
    1. transformaciones criptogr\u00e1ficas, construcci\u00f3n de pruebas<\/li>\n
    2. redes peer-to-peer, replicaci\u00f3n de transacciones y bloques<\/li>\n
    3. procesamiento de transacciones, ejecuci\u00f3n de contratos inteligentes<\/li>\n
    4. aplicaci\u00f3n de cambios en la blockchain a la base de datos de estado, actualizaci\u00f3n de datos sobre transacciones y bloques<\/li>\n
    5. consultas de solo lectura a la base de datos de estado, API de nodos de blockchain, servicios de suscripci\u00f3n <\/li>\n<\/ol>\n

      <\/p>\n

      En general, los requisitos t\u00e9cnicos para los nodos de las blockchains modernas son extremadamente serios: se necesitan CPUs r\u00e1pidas para la criptograf\u00eda, una gran cantidad de memoria RAM para almacenar y acceder r\u00e1pidamente a la base de datos de estado, interacciones de red que utilicen un gran n\u00famero de conexiones abiertas simult\u00e1neamente, y un almacenamiento voluminoso. Estas altas exigencias y la variedad de tipos de operaciones conducen inevitablemente a que los nodos puedan no tener suficientes recursos, lo que puede hacer que cualquiera de las etapas discutidas anteriormente se convierta en un nuevo cuello de botella para el rendimiento general de la red.<\/p>\n

      <\/p>\n

      Al desarrollar y evaluar el rendimiento de las blockchains, deber\u00e1 tener en cuenta todos estos aspectos. Para ello, necesita recopilar y analizar m\u00e9tricas tanto de los clientes como de los nodos de la red, buscar correlaciones entre ellos, evaluar el tiempo de servicio a los clientes y considerar todos los recursos principales: cpu\/memoria\/red\/almacenamiento, entendiendo c\u00f3mo se utilizan y se afectan entre s\u00ed. Todo esto hace que la comparaci\u00f3n de velocidades de diferentes blockchains en t\u00e9rminos de '\u00bfcu\u00e1ntos TPS?' sea una tarea ingrata, ya que existe una enorme cantidad de configuraciones y estados distintos. En grandes sistemas centralizados, clusters de cientos de servidores, estos problemas son igualmente complejos y requieren la recopilaci\u00f3n de un gran n\u00famero de m\u00e9tricas diferentes, pero en blockchains, debido a las redes p2p, m\u00e1quinas virtuales, contratos procesales y econom\u00edas internas, el n\u00famero de grados de libertad es mucho mayor, lo que hace que incluso las pruebas en unos pocos servidores sean poco representativas y ofrezcan valores que apenas tienen relaci\u00f3n con la realidad.<\/p>\n

      <\/p>\n

      Por lo tanto, al desarrollar en el n\u00facleo de la blockchain, para evaluar el rendimiento y responder a la pregunta '\u00bfha mejorado en comparaci\u00f3n con la vez anterior?' utilizamos un software bastante complejo que orquesta el lanzamiento de blockchain con decenas de nodos y el lanzamiento autom\u00e1tico de benchmarks y la recopilaci\u00f3n de m\u00e9tricas. Sin esta informaci\u00f3n, es extremadamente complicado depurar protocolos que operan con m\u00faltiples participantes.<\/p>\n

      <\/p>\n

      As\u00ed que, al recibir la pregunta '\u00bfcu\u00e1ntos TPS tiene su blockchain?', ofrezca al interlocutor un t\u00e9 y pregunte si est\u00e1 dispuesto a revisar una docena de gr\u00e1ficos, as\u00ed como escuchar todos los problemas de rendimiento de las blockchains y sus propuestas para solucionarlos...<\/p>\n

      Fuente: 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\udd47\u00bfCu\u00e1ntos TPS tiene su blockchain? | ProHoster","description":"La pregunta favorita sobre cualquier sistema distribuido de un no t\u00e9cnico es '\u00bfcu\u00e1ntos TPS tiene su blockchain?'.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}