{"id":34101,"date":"2019-10-31T21:56:25","date_gmt":"2019-10-31T18:56:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ob-anonimnosti-v-account-based-blokchejnah\/"},"modified":"2019-10-31T21:56:25","modified_gmt":"2019-10-31T18:56:25","slug":"ob-anonimnosti-v-account-based-blokchejnah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","title":{"rendered":"Sobre la anonimato en blockchains basados en cuentas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Desde hace tiempo estamos interesados en el tema de la anonimidad en las criptomonedas y estamos atentos al desarrollo de tecnolog\u00edas en este campo. En nuestros art\u00edculos ya hemos analizado detalladamente los principios de funcionamiento de las transacciones confidenciales<\/a><\/noindex> en Monero, as\u00ed como hemos realizado una rese\u00f1a comparativa<\/a><\/noindex> tecnolog\u00edas existentes en este \u00e1mbito. Sin embargo, todas las criptomonedas an\u00f3nimas actuales se basan en un modelo de datos propuesto por Bitcoin \u2014 Unspent Transaction Output (UTXO). Para las blockchains basadas en cuentas como Ethereum, las soluciones existentes para implementar la anonimidad y confidencialidad (por ejemplo, Mobius<\/a><\/noindex> o Aztec<\/a><\/noindex>) intentaron replicar el modelo UTXO en contratos inteligentes.<\/p>\n

En febrero de 2019, un grupo de investigadores de la Universidad de Stanford y Visa Research<\/a><\/noindex> no se manifiesta publicaron un preprint<\/a><\/noindex> titulado \u201cZether: Hacia la privacidad en el mundo de los contratos inteligentes\u201d. Los autores propusieron por primera vez un enfoque para garantizar la anonimidad en las blockchains basadas en cuentas y presentaron dos variantes de contratos inteligentes: para transacciones confidenciales (ocultaci\u00f3n de saldos y montos de transferencias) y an\u00f3nimas (ocultaci\u00f3n del receptor y del emisor). Consideramos que la tecnolog\u00eda propuesta es interesante y nos gustar\u00eda compartir su funcionamiento, as\u00ed como discutir por qu\u00e9 el problema de la anonimidad en las blockchains basadas en cuentas se considera muy complejo y si los autores lograron resolverlo completamente.<\/p>\n

Sobre el funcionamiento de estos modelos de datos<\/h3>\n

\nEn el modelo UTXO, una transacci\u00f3n consta de \"entradas\" y \"salidas\". El equivalente directo a las \u201csalidas\u201d son los billetes en su cartera: cada \u201csalida\u201d tiene un cierto valor nominal. Cuando paga a alguien (forma una transacci\u00f3n), gasta una o m\u00e1s \u201csalidas\u201d, convirti\u00e9ndolas en \u201centradas\u201d de la transacci\u00f3n, y la blockchain las marca como gastadas. A su vez, el receptor de su pago (o usted mismo si necesita cambio) recibe nuevas \u201csalidas\u201d generadas. Esquema esto se puede representar as\u00ed:<\/p>\n

\"Sobre
\n
\nLas blockchains basadas en cuentas funcionan de manera similar a su cuenta bancaria. Solo operan con la cantidad en su cuenta y la cantidad de la transferencia. Cuando transfiere una cantidad desde su cuenta, no quema ninguna \u201csalida\u201d, y la red no necesita recordar qu\u00e9 monedas han sido gastadas y cu\u00e1les no. En el caso m\u00e1s simple, la verificaci\u00f3n de la transacci\u00f3n se reduce a comprobar la firma del emisor y la cantidad en su saldo:<\/p>\n

\"Sobre
\n<\/p>\n

An\u00e1lisis de la tecnolog\u00eda<\/h3>\n

\nA continuaci\u00f3n, hablaremos sobre c\u00f3mo Zether oculta la cantidad de las transacciones, el receptor y el remitente. A lo largo de la descripci\u00f3n de sus principios de funcionamiento, se\u00f1alaremos las diferencias entre la versi\u00f3n confidencial y la an\u00f3nima. Dado que es mucho m\u00e1s sencillo garantizar la confidencialidad en blockchains basados en cuentas, algunas de las restricciones impuestas por la anonimizaci\u00f3n no ser\u00e1n relevantes para la versi\u00f3n confidencial de la tecnolog\u00eda.<\/p>\n

Ocultamiento de saldos y montos de transferencias<\/h4>\n

\nPara cifrar los saldos y montos de transferencias en Zether se utiliza un esquema de cifrado de El-Gamal.<\/a><\/noindex>Funciona de la siguiente manera. Cuando Alice quiere enviar a Bob b<\/b><\/i> monedas a la direcci\u00f3n (su clave p\u00fablica) Y<\/b><\/i>, elige un n\u00famero aleatorio r<\/b><\/i> y cifra la cantidad:<\/p>\n

\"Sobre
\ndonde C<\/b><\/i> \u2014 cantidad cifrada, ataques<\/b><\/i> \u2014 valor auxiliar necesario para descifrar esta cantidad, G<\/b><\/i> \u2014 punto fijo en la curva el\u00edptica, que al multiplicar la clave secreta da como resultado la clave p\u00fablica.<\/p>\n

Cuando Bob recibe estos valores, simplemente los suma a su balance cifrado de la misma manera, lo que hace que este esquema sea conveniente.<\/p>\n

De manera an\u00e1loga, Alice resta de su saldo los mismos valores, solo que utiliza su clave p\u00fablica como Y<\/b><\/i> referencia.<\/p>\n

Ocultamiento del receptor y remitente<\/h4>\n

\nEl mezclado de \u201csalidas\u201d en UTXO apareci\u00f3 ya en los inicios de las criptomonedas y ayuda a ocultar al remitente. Para ello, el propio remitente al realizar la transferencia selecciona \u201csalidas\u201d aleatorias en la blockchain y las mezcla con las suyas. A continuaci\u00f3n, firma las \u201csalidas\u201d con una firma en anillo, un mecanismo criptogr\u00e1fico que permite convencer al verificador de que entre las \u201csalidas\u201d mezcladas se encuentran las monedas del remitente. Por supuesto, las monedas mezcladas no se gastan.<\/p>\n

Sin embargo, para ocultar al receptor no podemos generar \u201csalidas\u201d falsas. Por lo tanto, en UTXO cada \u201csalida\u201d tiene su direcci\u00f3n \u00fanica, que est\u00e1 criptogr\u00e1ficamente vinculada a la direcci\u00f3n del receptor de estas monedas. Actualmente no hay forma de identificar la relaci\u00f3n entre la direcci\u00f3n \u00fanica de la \u201csalida\u201d y la direcci\u00f3n del receptor sin conocer sus claves secretas.<\/p>\n

En un modelo basado en cuentas, no podemos usar direcciones desechables (de lo contrario, ser\u00eda un modelo de \u00absalidas\u00bb). Por lo tanto, el receptor y el remitente deben mezclarse entre otras cuentas en la cadena de bloques. En este proceso, de las cuentas mezcladas se deducen 0 monedas cifradas (o se a\u00f1aden 0 en el caso de mezclar al receptor), sin cambiar realmente su saldo real.<\/p>\n

Dado que tanto el remitente como el receptor siempre tienen una direcci\u00f3n constante, aqu\u00ed surge la necesidad, al realizar transferencias a las mismas direcciones, de utilizar los mismos grupos para la mezcla. Es m\u00e1s f\u00e1cil verlo con un ejemplo.<\/p>\n

Supongamos que Alicia decidi\u00f3 hacer una donaci\u00f3n a la fundaci\u00f3n ben\u00e9fica de Bob, pero prefiere que esta transferencia permanezca an\u00f3nima para un observador externo. Entonces, para ocultar su identidad en el campo del remitente, incluye tambi\u00e9n las cuentas de Ad\u00e1n y Adela. Y para ocultar a Bob, a\u00f1ade en el campo del receptor las cuentas de Ben y Bill. Al realizar la siguiente donaci\u00f3n, Alicia decidi\u00f3 incluir junto a s\u00ed a Alex y Amanda, y junto a Bob a Bruce y Benjen. En este caso, al analizar la cadena de bloques, solo habr\u00e1 un par de participantes intersectados en estas dos transacciones: Alicia y Bob, lo que desanonymiza estas transacciones.<\/p>\n

\"Sobre
\n<\/p>\n

Carreras de transacciones<\/h4>\n

\nComo ya mencionamos, para ocultar su saldo en sistemas basados en cuentas, el usuario cifra su saldo y la cantidad de la transferencia. Al hacerlo, debe demostrar que el saldo de su cuenta sigue siendo no negativo. El problema es que, al crear una transacci\u00f3n, el usuario construye una prueba en relaci\u00f3n con su estado actual de cuenta. \u00bfY qu\u00e9 sucede si Bob env\u00eda a Alicia una transacci\u00f3n, y esta se acepta antes que la enviada por Alicia? Entonces, la transacci\u00f3n de Alicia se considerar\u00e1 inv\u00e1lida, ya que la prueba de saldo se construy\u00f3 antes de la aceptaci\u00f3n de la transacci\u00f3n de Bob.<\/p>\n

\"Sobre
\n
\nLa primera soluci\u00f3n que se le ocurre a uno en tal situaci\u00f3n es congelar la cuenta hasta que se realice la transacci\u00f3n. Pero este enfoque no es adecuado, ya que, adem\u00e1s de la complejidad de resolver tal problema en un sistema distribuido, en un esquema an\u00f3nimo no ser\u00eda claro a qui\u00e9n se le debe bloquear la cuenta.<\/p>\n

Para solucionar este problema, la tecnolog\u00eda divide las transacciones entrantes y salientes: el gasto tiene un efecto inmediato en el estado del balance, mientras que los ingresos son diferidos. Para esto, se introduce el concepto de \u201c\u00e9pocas\u201d, que son grupos de bloques de tama\u00f1o fijo. La \u201c\u00e9poca\u201d actual se determina dividiendo la altura del bloque por el tama\u00f1o del grupo. Al procesar una transacci\u00f3n, la red actualiza inmediatamente el balance del remitente, mientras que los fondos del receptor se suman a un acumulador. Los fondos acumulados se ponen a disposici\u00f3n del receptor del pago solo cuando comienza una nueva \u201c\u00e9poca\u201d.<\/p>\n

Como resultado, el usuario puede enviar transacciones independientemente de la frecuencia con la que reciba fondos (en la medida en que su balance lo permita, por supuesto). El tama\u00f1o de la \u00e9poca se determina seg\u00fan la rapidez con que los bloques se difunden a trav\u00e9s de la red y qu\u00e9 tan r\u00e1pido una transacci\u00f3n entra en un bloque. <\/p>\n

Esta soluci\u00f3n funciona bien en el caso de transferencias privadas, sin embargo, en el caso de transacciones an\u00f3nimas, como veremos m\u00e1s adelante, plantea problemas serios.<\/p>\n

Protecci\u00f3n contra ataques de repetici\u00f3n<\/h4>\n

\nEn las cadenas de bloques basadas en cuentas, cada transacci\u00f3n se firma con la clave privada del remitente, lo que convence al verificante de que la transacci\u00f3n no ha sido alterada y que fue creada por el propietario de esa clave. Pero, \u00bfqu\u00e9 pasa si un atacante, que ha estado escuchando el canal de transmisi\u00f3n, intercepta este mensaje y env\u00eda exactamente el mismo segundo? El verificador comparar\u00e1 la firma de la transacci\u00f3n y estar\u00e1 convencido de su autor\u00eda, y la red deducir\u00e1 la misma cantidad del balance del remitente nuevamente.<\/p>\n

A este ataque se le llama ataque de repetici\u00f3n. En el modelo UTXO, tales ataques no son relevantes, ya que el atacante intentar\u00eda usar salidas gastadas, lo que en s\u00ed mismo no es v\u00e1lido y es rechazado por la red.<\/p>\n

Para evitar esto, se incorpora un campo con datos aleatorios en la transacci\u00f3n, que se llama nonce o simplemente \u201csal\u201d. Al volver a enviar una transacci\u00f3n con una \u201csal\u201d, el verificador comprueba si ese nonce se ha usado anteriormente y, si no, considera v\u00e1lida la transacci\u00f3n. Para no almacenar toda la historia de los nonces de los usuarios en la cadena de bloques, generalmente en la primera transacci\u00f3n se establece que su valor es cero y luego se incrementa en uno. A la red solo le queda verificar que el nonce de la nueva transacci\u00f3n difiera del anterior en uno.<\/p>\n

En un esquema an\u00f3nimo de transferencias surge el problema de validaci\u00f3n de los nonces de las transacciones. No podemos vincular el nonce de manera expl\u00edcita a la direcci\u00f3n del remitente, ya que, evidentemente, esto desanonimizar\u00eda la transferencia. Tampoco podemos incrementar en uno los nonces de todas las cuentas involucradas, ya que esto podr\u00eda entrar en conflicto con otras transferencias que est\u00e1n en proceso. <\/p>\n

Los autores de Zether proponen generar nonces criptogr\u00e1ficamente, dependiendo de la \"\u00e9poca\". Por ejemplo:<\/p>\n

\"Sobre
\nAqu\u00ed x<\/i><\/b> \u2014 la clave secreta del remitente, y Gepoch<\/i><\/b> \u2014 un generador adicional para la \u00e9poca, obtenido mediante la hashaci\u00f3n de una cadena del tipo 'Zether + '. Ahora, el problema parece resolverse: no revelamos el nonce del remitente y no interferimos con los nonces de participantes no implicados. Pero este enfoque impone una limitaci\u00f3n seria: una cuenta solo puede enviar una transacci\u00f3n por '\u00e9poca'. Este problema, lamentablemente, sigue sin resolverse y, en nuestra opini\u00f3n, hace que la versi\u00f3n an\u00f3nima de Zether sea apenas utilizable.<\/p>\n

Complejidad de las pruebas de cero conocimiento<\/h4>\n

\nEn UTXO, el remitente debe demostrar a la red que no est\u00e1 gastando una cantidad negativa, de lo contrario es posible generar nuevas monedas de la nada (por qu\u00e9 esto es posible, hemos escrito en uno de nuestros anteriores art\u00edculos<\/a><\/noindex>). Y tambi\u00e9n firmar los \"entradas\" con una firma de anillo para demostrar que entre las monedas mezcladas hay fondos que le pertenecen.<\/p>\n

En la versi\u00f3n an\u00f3nima de blockchain basada en cuentas, las expresiones para la prueba se vuelven mucho m\u00e1s complejas. El remitente demuestra que:<\/p>\n

    \n
  1. La cantidad enviada es positiva;<\/li>\n
  2. El saldo permanece no negativo;<\/li>\n
  3. El remitente ha cifrado correctamente las cantidades de las transferencias (incluidas las cero);<\/li>\n
  4. El saldo cambia \u00fanicamente en las cuentas del remitente y el receptor;<\/li>\n
  5. El remitente posee la clave secreta de su cuenta y realmente est\u00e1 en la lista de remitentes (entre los mezclados);<\/li>\n
  6. El nonce utilizado en la transacci\u00f3n est\u00e1 compuesto correctamente.<\/li>\n<\/ol>\n

    \nPara tal prueba compleja, los autores utilizan una mezcla A prueba de balas<\/a><\/noindex> (uno de los autores, por cierto, particip\u00f3 en su creaci\u00f3n) y el protocolo Sigma<\/a><\/noindex>, que se denomina Sigma-bullets. La prueba formal de tal afirmaci\u00f3n es una tarea bastante complicada y limita mucho el n\u00famero de interesados en implementar esta tecnolog\u00eda.<\/p>\n

    \u00bfCu\u00e1l es el resultado?<\/h4>\n

    \nEn nuestra opini\u00f3n, la parte de Zether que introduce privacidad en los blockchains basados en cuentas ya puede ser utilizada en este momento. Sin embargo, la versi\u00f3n an\u00f3nima de la tecnolog\u00eda impone serias limitaciones a su uso, y su complejidad representa un desaf\u00edo para su implementaci\u00f3n. No obstante, no se debe pasar por alto que los autores la lanzaron hace solo unos meses, y es posible que alguien m\u00e1s encuentre una soluci\u00f3n a los problemas actuales. Despu\u00e9s de todo, as\u00ed es como se hace ciencia.
    \n
    Fuente:     habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041c\u044b \u0443\u0436\u0435 \u0434\u0430\u0432\u043d\u043e \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u0443\u0435\u043c\u0441\u044f \u0442\u0435\u043c\u043e\u0439 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u0430\u0445 \u0438 \u0441\u0442\u0430\u0440\u0430\u0435\u043c\u0441\u044f \u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u044d\u0442\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u0438. \u0412 \u0441\u0432\u043e\u0438\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u043c\u044b \u0443\u0436\u0435 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e \u0440\u0430\u0437\u0431\u0438\u0440\u0430\u043b\u0438 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u043a\u043e\u043d\u0444\u0438\u0434\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0445 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u0432 Monero, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u043b\u0438 \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043e\u0431\u0437\u043e\u0440 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439, \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u043d\u0430 \u044d\u0442\u043e\u043c \u043f\u043e\u043b\u0435. \u041e\u0434\u043d\u0430\u043a\u043e \u0436\u0435 \u0432\u0441\u0435 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u044b\u0435 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u044b \u043d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u044b \u043d\u0430 \u043c\u043e\u0434\u0435\u043b\u0438 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0435\u043d\u043d\u043e\u0439 Bitcoin \u2014 […]<\/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-34101","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\udd47Sobre la anonimidad en los blockchains basados en cuentas | ProHoster","description":"Desde hace tiempo, estamos interesados en el tema de la anonimidad en las criptomonedas y nos esforzamos por seguir el desarrollo de tecnolog\u00edas en este campo.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","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\u041e\u0431 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 account-based \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430\u0445 | ProHoster","og:description":"\u041c\u044b \u0443\u0436\u0435 \u0434\u0430\u0432\u043d\u043e \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u0443\u0435\u043c\u0441\u044f \u0442\u0435\u043c\u043e\u0439 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u0430\u0445 \u0438 \u0441\u0442\u0430\u0440\u0430\u0435\u043c\u0441\u044f \u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u044d\u0442\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u0438.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","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-31T18:56:25+00:00","article:modified_time":"2019-10-31T18:56:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34101","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-21 17:56:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:28:34","updated":"2026-01-21 17:56: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\/34101","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=34101"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/34101\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=34101"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=34101"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=34101"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}