¿Qué les ocurre a los validadores de Solana que no se actualizan a Agave 4.4.1?

Anza dio a los operadores de nodos de Solana hasta la época 1079 para instalar un parche que cambia cómo la red contabiliza los datos de cuenta que carga una transacción. Una máquina que ejecuta una compilación anterior podría permanecer en línea y aun así quedar desincronizada con la cadena aceptada, con diferentes consecuencias para los validadores que obtienen recompensas de staking y para los servicios de los que dependen las billeteras para obtener datos actuales.

Anza advirtió a los validadores antes de la época 1079 que los operadores que ejecutaran software anterior corrían el riesgo de quedar atrás cuando la red activara una nueva regla. Las versiones compatibles citadas fueron Agave 4.4.1 y Firedancer v26.10.6.

El rastreador de puertas de características de Agave identifica el cambio relevante como un tamaño mínimo de datos cargados para las cuentas ProgramData de loader-v3. Su tabla de versión mínima separa las versiones usadas por las redes de prueba de las planificadas para mainnet. Leer el calendario requiere verificar el clúster, la característica y la época en conjunto.

La fecha límite también abarcó a los nodos que no votan. Esas máquinas pueden proporcionar a las billeteras y a los exchanges saldos, hashes de bloque y datos de confirmación. Un problema en uno de ellos puede llegar a usuarios que nunca delegaron SOL ni eligieron un validador.

Qué hace el cambio

Un programa de Solana puede usar una cuenta para almacenar sus datos ejecutables. Cuando una transacción necesita cargar un programa, la red contabiliza los datos asociados con esa operación. Un mínimo aplicado a una cuenta de datos de programa cambia cómo el software compatible trata la transacción relevante bajo la nueva regla.

El propósito de una puerta de características es coordinar cuándo los participantes comienzan a usar una nueva regla. Los operadores pueden instalar una versión con antelación, mientras que el cambio real de la regla entra en vigor en un punto acordado. Por lo tanto, una versión puede admitir una característica antes de que esa característica esté activa en mainnet.

Una vez que la puerta se activa, una versión anterior puede discrepar del software actualizado sobre una transacción o el estado producido por un bloque. Un validador puede entonces dejar de seguir la cadena reconocida por el resto de la red aunque el servidor mismo permanezca en línea. Ese es el significado práctico de la advertencia de Anza sobre quedar bifurcado.

Por qué importa el stake detrás de los nodos

Cien validadores pequeños y un puñado de grandes operadores no necesariamente representan cantidades comparables de stake de voto. Para el funcionamiento de la red, la pregunta relevante es cuánto stake sigue las reglas compatibles. El rastreador indica que los cambios de versión mínima de mainnet en versiones menores normalmente siguen un umbral de adopción de stake y un período de espera. Esa regla general debe mantenerse distinta de la advertencia específica emitida antes de la época 1079.

Una verificación de adopción debería combinar la información de versión con el stake activo y luego comparar esas cifras con la participación en la votación después del límite. Un nodo que reporta la versión correcta puede aún estar poniéndose al día o experimentar una falla separada. A la inversa, un agregado estable puede ocultar problemas en un operador más pequeño si la mayor parte del stake permanece en línea y vota con normalidad.

Esa diferencia importa a los delegadores. Su experiencia depende del validador al que se asignó su stake, en lugar de si una mayoría de máquinas instaló la versión. Si un validador deja de votar de manera efectiva, la participación perdida puede reducir las recompensas atribuibles a ese stake. La evidencia relevante serían los créditos de voto y los registros de recompensas de las épocas afectadas.

Lo que notarían los usuarios y los exchanges

Un usuario que envía SOL se preocupa de que la transferencia sea aceptada y alcance el nivel de confirmación previsto. Eso puede comprobarse mediante los datos de la transacción y de la red. La afirmación de que varios operadores se perdieron una actualización no establece por sí misma confirmaciones más lentas, una detención o una interrupción generalizada.

Un exchange también puede pausar los depósitos o retiros mientras monitorea una actualización, incluso cuando las transferencias continúan onchain. Los saldos de sus clientes dependen de su propia infraestructura y de sus políticas de acreditación. Por lo tanto, una transacción que aparece onchain puede permanecer pendiente en la cuenta de exchange de un cliente hasta que ese venue reanude el procesamiento normal.

La comparación útil posterior a la actualización comprobaría tres cosas por separado. Primero, ¿siguieron produciéndose y confirmándose bloques? Segundo, ¿cambió efectivamente la cantidad de stake que vota? Tercero, ¿algún exchange nombrado pausó o reanudó transferencias en torno al límite? Cada respuesta necesita un registro diferente.

Por qué el plazo de la actualización también se aplicaba a la infraestructura

Las notas de la versión Agave de Anza identifican el cambio de contabilidad de ProgramData como un backport. La versión de Firedancer incluye soporte para la misma característica. Cuando dos clientes procesan la misma transacción después de la activación, tienen que coincidir en cuántos datos de cuenta carga. La regla compartida es lo que importa en el límite.

Un nodo RPC sin stake puede servir a una aplicación sin contribuir stake a los votos. Eso hace fácil que un usuario de billetera encuentre un problema local incluso si los validadores que votan siguen produciendo bloques. Una aplicación que lee desde un endpoint retrasado puede mostrar un estado antiguo o devolver un error. Comparar su respuesta con la misma solicitud a través de otro endpoint ayuda a identificar dónde ocurrió la interrupción.

La migración a Alpenglow de Solana en octubre ofrece contexto sobre cómo los operadores se preparan para un cambio coordinado. Esa migración concernía al protocolo de consenso. El parche de noviembre concernía a la carga de cuentas. Ambos dan a los operadores una versión que verificar, pero los efectos deben evaluarse contra la regla específica que cambió.

Qué hacía diferente al plazo de una fecha de lanzamiento

Anza publicó Agave 4.4.1 el 5 de noviembre. Su posterior advertencia a los operadores decía que el cambio estaba planificado para la época 1079, cuya inicio se estimaba alrededor de las 13:30 UTC del 6 de noviembre. La versión identificaba el software que los operadores necesitaban, mientras que la época identificaba cuándo la red planeaba comenzar a aplicar la regla.

Un límite de época depende del progreso de la cadena. La hora en la advertencia daba a los operadores una estimación práctica, pero la transición de la cadena a la nueva época era el evento importante. Los operadores no podían tratar una hora local posterior o una ventana de mantenimiento rutinario como una extensión del calendario.

Una versión puede incluir código que todavía no cambia cómo la red procesa las transacciones. Los operadores instalan el software primero, luego la red activa la característica en el punto planificado. Esa secuencia permite a los operadores prepararse sin que los nodos apliquen inmediatamente reglas diferentes al mismo bloque.

La ventana era corta incluso para los operadores que ya se habían pasado a Agave 4.4.0. El número de parche cambió en uno, pero la versión anterior carecía del soporte necesario para la nueva regla. Por lo tanto, una instalación reciente no sustituía la comprobación de la compilación exacta.

La versión Firedancer 26.10.6 soportaba la misma característica. Los operadores podían usar diferentes implementaciones de cliente, pero ambas necesitaban contar los mismos datos de cuenta al ejecutar una transacción bajo las reglas activas.

La distinción entre software y activación ya había aparecido en la cobertura de crypto.news sobre el despliegue en testnet de Alpenglow. Alpenglow cambió el consenso, mientras que el parche de noviembre concernía al procesamiento de transacciones. En ambos casos, que una compilación estuviera disponible era un hito separado de que la red requiriera su comportamiento.

Dónde entra ProgramData en la transacción

Una transacción enumera las cuentas que necesitan sus instrucciones. Un validador carga los datos asociados con esas cuentas para llevar a cabo las instrucciones. La red limita cuántos datos de cuentas puede cargar una transacción, lo que da a los validadores un límite en una categoría de trabajo que realizan antes o durante la ejecución.

El cargador actualizable de Solana utiliza una cuenta de programa y una cuenta ProgramData separada. Esta última almacena los datos del programa ejecutable y la información asociada para el cargador. Un usuario invoca el programa sin contabilizar manualmente el tamaño de esos datos ejecutables. El entorno de ejecución del validador se encarga de esa parte.

El parche establece un mínimo para la cantidad atribuida a una cuenta ProgramData de loader-v3 cuando se carga. Si la contabilidad anterior atribuía menos que el mínimo, la nueva regla cuenta al menos el mínimo contra el límite de datos cargados de la transacción. Una transacción muy por debajo del límite puede producir el mismo resultado después del cambio.

La diferencia importa en el límite. Una transacción que combina varias instrucciones o utiliza varios programas puede ya cargar una cantidad sustancial de datos de cuentas. Si el nuevo mínimo sitúa la cantidad combinada por encima del límite, las reglas antigua y nueva pueden producir resultados diferentes incluso con las mismas instrucciones y el mismo firmante.

El límite de datos cargados es distinto del presupuesto de cómputo. El cómputo mide el trabajo de ejecución. Una transacción puede tener cómputo suficiente para ejecutar las instrucciones y aun así fallar un límite que rige qué cuentas puede cargar. Aumentar únicamente la asignación de cómputo no cambia la cantidad contabilizada contra el límite de datos cargados.

La regla también deja en su lugar las instrucciones desplegadas de una aplicación. El programa puede permanecer en la misma dirección y tener el mismo código mientras el validador cobra su cuenta ProgramData de manera diferente. Los equipos de aplicaciones tienen motivo para volver a verificar las transacciones cerca del límite incluso si no realizaron ningún despliegue propio.

Cómo dos nodos pueden discrepar sobre el mismo bloque

Los validadores ejecutan transacciones para verificar el estado producido por un bloque. Si dos nodos parten del mismo estado y aplican reglas diferentes a una de esas transacciones, pueden llegar a resultados diferentes. Ambos no pueden tratar el mismo estado resultante como válido a menos que se resuelva la diferencia.

Eso explica la advertencia de Anza sobre los nodos más antiguos quedando desincronizados. Un nodo antiguo puede permanecer en línea y seguir respondiendo solicitudes mientras no logra seguir la cadena aceptada por los validadores compatibles. Que su proceso esté activo es una prueba más débil que si está actualizado y de acuerdo con el clúster.

Un operador puede comparar el slot que reporta el nodo con una referencia independiente. Un validador votante también tiene que comprobar que sus votos se cuentan en la cadena aceptada. Los registros de errores pueden identificar un problema al reproducir bloques que sería invisible en una comprobación de tiempo de actividad.

La advertencia describía la consecuencia de la incompatibilidad. Una evaluación posterior a la fecha límite todavía necesita mostrar qué operadores estaban ejecutando compilaciones desactualizadas y qué les ocurrió a sus nodos. Una instantánea de versión recopilada después de que un operador se recuperara podría pasar por alto un breve período en el que ese validador estuvo desincronizado.

La fecha de activación y el momento en que un observador nota un problema también pueden diferir. Una regla estrecha solo afecta a las transacciones que la ejercitan. Un período sin divergencia visible inmediatamente después del límite no mostraría si un nodo podría manejar una transacción cerca del límite afectado.

Por qué un recuento de validadores cuenta solo parte de la historia

La importancia de un validador votante depende en parte de cuánto stake representa. Un puñado de grandes operadores puede representar más peso de voto que muchos más pequeños. Por lo tanto, un recuento de máquinas afectadas responde a una pregunta diferente de la del porcentaje de stake activo que siguió participando.

Los nodos sin stake tienen un papel aparte. Pueden proporcionar datos a aplicaciones, exchanges y billeteras o retransmitir transacciones firmadas. Una interrupción en un servicio popular puede afectar a muchos usuarios aunque el servicio no aporte stake al consenso.

Las medidas relevantes pueden moverse de forma independiente. La producción de bloques puede continuar mientras un proveedor de RPC en particular sirve datos obsoletos. Un validador puede perder votos mientras su sitio web de cara al público sigue disponible. Un exchange puede pausar los depósitos de Solana mientras la cadena continúa confirmando transferencias.

La cobertura anterior de la fecha límite de Alpenglow de Solana describía un traspaso que requería una preparación coordinada por parte de validadores y aplicaciones. El objetivo allí era una finalidad más rápida. La puerta de ProgramData tiene un efecto técnico más estrecho, pero los operadores aún tienen que juzgar la preparación en función de su propio lugar en la red.

Qué pueden establecer los delegadores a partir de los registros de votos y recompensas

Los delegadores tienen una pregunta económica incluso cuando la red permanece disponible. Quieren saber si el validador que obtiene recompensas en su nombre continuó participando. Un parche omitido no mueve por sí mismo el SOL delegado fuera de la cuenta de stake, pero una interrupción en la votación puede reducir las recompensas obtenidas durante el período correspondiente.

El primer lugar donde buscar es la cuenta de votos del validador. Comparar los créditos de voto a lo largo de las épocas alrededor del límite puede establecer si su participación cambió. Los registros de recompensas ofrecen una verificación separada del efecto para cuentas de stake concretas.

Una recompensa menor no identifica por sí misma la actualización como la causa. La comisión, el rendimiento previo del validador y el estado de la cuenta de stake pueden afectar todos al importe registrado. La evidencia de que los votos se detuvieron en el límite y se reanudaron tras un cambio de cliente daría una explicación más sólida que una única recompensa menor.

Un token de staking líquido añade otra capa. Un pool puede repartir su stake entre varios validadores. Un problema en un operador puede contribuir solo a una parte del cambio en las recompensas del pool, dependiendo de su cuota de la delegación y de la contabilidad del pool.

El staking en exchanges añade una relación de servicio. El exchange puede operar sus propios validadores o usar otro proveedor, y luego acreditar a los clientes según sus términos. Un usuario necesitaría los registros del exchange para conectar un cambio onchain en los votos con la recompensa acreditada a una cuenta individual.

Qué puede hacer un endpoint RPC desactualizado a una billetera

Muchas billeteras obtienen saldos, blockhashes y resultados de transacciones a través de un endpoint RPC. Un nodo que se queda atrás puede informar un saldo anterior o no devolver una transacción reciente. Los usuarios pueden encontrar esos síntomas incluso si otros nodos están procesando la red con normalidad.

Un blockhash puede afectar a la transacción antes de que la red la ejecute. Una billetera que obtiene un blockhash desactualizado puede construir una transacción que ya no es válida cuando llega a un nodo saludable. El síntoma es un envío fallido, pero la razón puede ser información desactualizada en lugar de un cambio en el saldo o en las instrucciones.

La simulación depende de la misma relación. Un nodo que ejecuta reglas antiguas puede informar que una transacción se ajusta al límite de datos cargados aunque los nodos que aplican la nueva regla lleguen a un resultado diferente. Una simulación en un nodo compatible aún puede diferir de la ejecución final si el estado cambia entre la simulación y la inclusión.

Las aplicaciones con varios nodos detrás de un único endpoint se enfrentan a otra posibilidad. Las solicitudes pueden tener éxito o fallar según qué máquina las reciba. Un proveedor tiene que comprobar que todo el pool está actualizado antes de atribuir un problema intermitente a la cadena.

Una comparación entre endpoints independientes ayuda a separar esos problemas. Si varios endpoints actuales coinciden y un servicio difiere, la discrepancia puede ser local a ese servicio. Si observadores independientes también informan de un cambio en la producción de bloques o en las confirmaciones, hay evidencia más sólida de un problema de red.

La transición de consenso de octubre tuvo sus propios cambios de infraestructura. Crypto.news informó que Alpenglow eliminó las anteriores transacciones de votación onchain. Los equipos de aplicaciones tuvieron que distinguir el cambio en lo que observaban de si los validadores podían seguir el nuevo sistema. La regla de carga de cuentas de noviembre vuelve a hacer que la respuesta dependa del rol del observador.

Por qué el crédito del exchange puede ir por detrás de la cadena

Un exchange puede acreditar un depósito solo después de que sus sistemas reconozcan la transferencia y apliquen su política de confirmación. Por lo tanto, una transacción onchain exitosa no determina cuándo cambia el saldo interno del cliente en el exchange.

Un venue puede pausar depósitos o retiros mientras actualiza su infraestructura. También puede seguir recibiendo transferencias onchain mientras su cola de depósitos espera la confirmación de un nodo saludable. Un aviso del venue y un explorador de bloques pueden ser ambos precisos incluso si uno muestra una interrupción del servicio y el otro muestra una transferencia exitosa.

En el caso de los retiros, puede producirse un retraso antes de que el exchange firme o difunda la transacción. La ausencia de un registro onchain durante ese tiempo dice poco sobre si la red aceptaría la transacción una vez enviada. El estado de procesamiento del venue aborda esa parte de la línea temporal.

Un informe de que varios exchanges pausaron operaciones aún tendría que identificar qué servicios se vieron afectados y qué razón dio cada uno. Un aviso de mantenimiento rutinario o una cola causada por otro problema pueden caer en la misma ventana que una actualización. La coincidencia es una razón para comparar registros, no una medida de la participación en la red.

Qué mostraría si los operadores omitieron el parche

El rastreador de feature gates de Anza separa el piso mínimo de versión de las activaciones individuales. La cobertura anterior de crypto.news sobre el despliegue de Alpenglow y el piso de mainnet describía la misma distinción. Una build puede cumplir el piso en un momento dado y carecer de un cambio programado para una época posterior.

El registro posterior a la activación más útil compararía la característica activa, la distribución del software y la participación de los operadores durante la misma ventana. El registro de la característica identifica cuándo empezó a aplicarse la regla. El registro del software identifica qué builds estaban en servicio. Los votos y los bloques muestran si la red y los operadores individuales se comportaron de manera diferente.

Los slots omitidos son una posible observación. También pueden aumentar por razones no relacionadas con el parche, incluido el rendimiento ordinario de los validadores asignados a liderar. Comparar varias ventanas y emparejar las omisiones con sus líderes da contexto a la observación.

El stake delincuente ofrece una visión diferente. La cantidad puede moverse cuando un gran validador deja de participar, incluso si el número total de nodos delincuentes apenas cambia. La comparación debe tener en cuenta a los operadores que ya eran delincuentes antes de la actualización.

Los efectos sobre RPC y exchanges deben documentarse por separado. Esos proveedores pueden atender a grandes cantidades de usuarios sin aparecer en la comparación de stake. Sus avisos, métricas de servicio y registros de cuándo los nodos volvieron a los slots actuales describirían interrupciones que los datos de votación no pueden capturar.

Por qué un despliegue por etapas aún necesita una prueba de activación

Una versión estable del cliente puede desplegarse gradualmente antes de que una nueva característica esté activa. Eso permite a los operadores ver si el software arranca correctamente, se pone al día y procesa transacciones bajo las reglas vigentes. También ayuda a revelar problemas de despliegue antes de que más nodos lo usen.

Un despliegue exitoso antes de la activación no puede ejercitar todas las consecuencias de la característica activa. Una transacción cerca del límite de datos de cuenta cargados debe probarse bajo ambos conjuntos de reglas para mostrar exactamente dónde cambia el resultado. Esa es una prueba diferente de observar si el binario permanece en línea.

Crypto.news informó anteriormente que Alpenglow apuntaba a un enfoque diferente de la finalidad. Sus criterios de éxito incluían qué ocurría con la velocidad de confirmación. El parche de ProgramData se juzga mejor por si los clientes coinciden en las transacciones que encuentran el nuevo límite y si la infraestructura sigue disponible después de que se active el gate.

Una reversión también cambia de significado en la activación. Antes del límite, una versión anterior compatible aún puede procesar las reglas ya vigentes. Después, volver a una build que carece de la característica puede traer de vuelta la misma incompatibilidad exacta que el operador intentaba resolver. Un fallback tiene que conservar el soporte para el gate activo.

Un operador con capacidad de reserva puede levantar un nodo parcheado y validarlo antes de asignarle tráfico. Un operador más pequeño puede tener que reiniciar su único nodo y esperar a que se ponga al día. El plazo es compartido, pero el tiempo que los usuarios pasan esperando puede depender de la redundancia del proveedor.

Por qué el precio de SOL no puede medir el efecto de la actualización

SOL puede caer o subir en las mismas horas en que los operadores instalan un parche. Se negocia contra muchas de las mismas monedas y bolsas de capital que otros activos cripto. Las tasas, los movimientos de Bitcoin y los cambios en el apalancamiento pueden afectar el precio durante la misma ventana.

Un problema técnico puede ser relevante para el trading si interrumpe las transferencias o hace que una aplicación no esté disponible. La evidencia de esa explicación incluiría avisos de los venues, cambios en los depósitos o retiros, o datos de ejecución onchain vinculados a las cuentas relevantes. El precio de un token por sí solo no identifica ese canal.

El fallo de una transacción individual también es distinto de la pérdida de control sobre una cuenta. Una billetera puede haber construido una transacción con información antigua o haberla enviado a través de un nodo obsoleto. El usuario todavía puede controlar la cuenta mientras la aplicación tiene problemas para alcanzar la red actual.

La prueba más directa después de la fecha límite se sitúa, por tanto, a nivel del servicio. Un nodo de votación debería estar actualizado y registrando votos. Un servicio RPC debería estar respondiendo solicitudes de la cadena aceptada. Un exchange debería poder dar cuenta de si procesó y cuándo procesó las transferencias enviadas en torno al cambio.

Esa evidencia puede respaldar una evaluación incluso si el precio se mueve por razones no relacionadas. También da a los delegadores una forma de evaluar el desempeño de su propio validador sin tratar un requisito de versión a nivel de red como una declaración sobre los resultados de cada operador.

Qué sucede cuando un operador vuelve a estar en línea

Instalar el software parcheado es un paso en la restauración de un nodo. El operador necesita entonces ver si el proceso se pone al día con la cadena aceptada y la sigue bajo las reglas actuales. Un servidor puede reiniciarse con éxito mientras todavía está reproduciendo bloques o devolviendo datos que van por detrás de la punta.

Un nodo de votación también necesita mostrar que su participación se ha reanudado. Su operador puede comparar los votos actuales con el momento en que el nodo se recuperó. Un delegador que lea los datos de recompensas más tarde puede entonces distinguir el punto de recuperación del momento en que se instaló el parche.

Un proveedor de servicios puede retirar de la rotación un nodo parcheado hasta que se haya puesto al día y haya superado las comprobaciones. El operador puede comparar el slot, el resultado de una transacción reciente y el resultado de una simulación con una referencia separada. Un proveedor que devuelve el nodo al tráfico antes de estas comprobaciones puede hacer que una actualización de software parezca completa mientras los clientes todavía encuentran datos antiguos.

La cronología importa al evaluar el impacto. Un nodo que divergió y regresó dentro de la misma época puede parecer saludable en un directorio posterior. Su participación perdida todavía puede importar para el operador o los delegadores. Una cronología pública del incidente necesitaría suficiente detalle para mostrar cuándo se detuvo el servicio y cuándo se reanudó la actividad normal.

Los equipos de aplicaciones también pueden examinar transacciones que fallaron solo a través de un backend particular. Si reenviarlas a través de un nodo actual resuelve el problema sin cambios en las instrucciones, el endpoint anterior se convierte en una fuente probable del fallo. Si la misma transacción falla consistentemente en nodos actuales cerca del límite de datos de la cuenta, la transacción misma puede necesitar ser reconstruida.

Tal reconstrucción puede implicar reducir los datos cargados por la transacción o separar instrucciones donde la aplicación pueda tolerar múltiples transacciones. Dividir una transacción puede cambiar sus garantías, porque las instrucciones que debían tener éxito o fallar juntas pueden ya no hacerlo. El cambio pertenece, por tanto, al propio diseño de la aplicación, junto con sus requisitos de carga de cuentas.

Las consecuencias para un usuario dependen de dónde ocurrió la incompatibilidad. Un operador puede perder participación, un RPC puede devolver información obsoleta y una aplicación puede construir una transacción que ya no encaja. Los dos primeros pueden abordarse restaurando infraestructura compatible, mientras que el tercero depende de la transacción y de la regla activa.

Una verificación de la recuperación de Solana debería mantener esas observaciones separadas. Debería comparar los registros de votos de los operadores, los registros de servicio de los proveedores y los resultados de ejecución de las aplicaciones afectadas. Hacerlo permite identificar un efecto acotado incluso si la red siguió produciendo bloques durante todo el proceso.

La fecha límite de noviembre dio a los operadores una versión con nombre y un límite de época. El registro duradero de su impacto provendrá de lo que hicieron los nodos en torno a ese límite y del servicio que pudieron proporcionar después.

Qué observar

• Versiones compatibles: El calendario de Anza y las notas de la versión pueden establecer el mínimo de la mainnet y sus equivalentes entre clientes.
• Participación en la votación: El stake activo y los créditos de voto pueden mostrar si la participación en la votación cambió en torno al límite.
• Confirmaciones de red: Los registros de bloques y confirmaciones pueden mostrar si la red continuó procesando transacciones en torno al cambio.
• Operaciones de exchange: Los avisos de las plataformas pueden establecer si un exchange pausó sus propios depósitos o retiros de Solana.

Preguntas frecuentes