La misma solicitud eth_chainId: la dirección de la red principal que figura en la documentación oficial no devolvió respuesta, mientras que la red de pruebas sí respondió con normalidad. No se puede tergiversar este resultado para afirmar que la red principal está caída. Lo que revela es un problema de otra índole. @Dusk incluye el punto de acceso en la documentación, lo cual solo demuestra que la dirección está declarada, no que mi equipo ya haya establecido con ella una conexión de confianza. Entre la existencia de la documentación y la disponibilidad para el cliente se interponen los certificados, la red y la identidad de la cadena.
Reduje las variables al mínimo. El cliente, el contenido de la solicitud POST y el tiempo de espera de 15 segundos fueron exactamente los mismos; solo cambié el endpoint RPC. El 24 de agosto de 2026 a las 00:08, la red de pruebas respondió con 0x2e9 y después devolvió el bloque 0x11bc06. La red principal se quedó atascada en TLS al aplicar una validación estricta de certificados: el estado HTTP fue 000, el resultado de la verificación fue 20 y no se llegó a obtener el chain ID en la capa de aplicación.
Lo más útil de esta comparación no es emitir un veredicto sobre el estado de la red. Un fallo de TLS estricto puede deberse a la cadena de certificados o manifestarse únicamente en la ruta de red que estoy usando ahora. El alcance de lo que demuestra está claro: al menos en este entorno de cliente, la dirección documentada todavía no ha superado la prueba de disponibilidad. Afirmar que un fallo de conexión puntual demuestra una avería de toda la red sería más imprudente que ignorar el fallo en sí.
Antes, veía un RPC y me ponía a configurar la cartera. Ahora tengo que cambiar el orden. Una conexión de confianza es la puerta; el chain ID, el número de la habitación; y que el bloque siga avanzando demuestra que hay alguien dentro. Si falta alguno de estos pasos, no debería arriesgar fondos reales para probar. En esta ocasión, los tres aspectos de la red de pruebas se pueden seguir verificando; la red principal se detuvo en el primero. La diferencia no es la velocidad, sino si se puede pasar a la siguiente comprobación.
Para que el endpoint EVM de $DUSK se considere realmente disponible, deben cumplirse a la vez estas tres condiciones: que el certificado sea de confianza, que el chain ID coincida con el esperado y que la altura del bloque siga cambiando. Si no reúno las tres pruebas, lo marcaré como pendiente de investigación, no como disponible, y mucho menos afirmaré que la red principal está caída. La medida más sencilla para que los usuarios comunes eviten pérdidas también es concreta: antes de transferir, hagan estas tres comprobaciones y deténganse si alguna no da resultado.
La documentación proporciona la dirección; solo una prueba real da luz verde. #dusk
Reduje las variables al mínimo. El cliente, el contenido de la solicitud POST y el tiempo de espera de 15 segundos fueron exactamente los mismos; solo cambié el endpoint RPC. El 24 de agosto de 2026 a las 00:08, la red de pruebas respondió con 0x2e9 y después devolvió el bloque 0x11bc06. La red principal se quedó atascada en TLS al aplicar una validación estricta de certificados: el estado HTTP fue 000, el resultado de la verificación fue 20 y no se llegó a obtener el chain ID en la capa de aplicación.
Lo más útil de esta comparación no es emitir un veredicto sobre el estado de la red. Un fallo de TLS estricto puede deberse a la cadena de certificados o manifestarse únicamente en la ruta de red que estoy usando ahora. El alcance de lo que demuestra está claro: al menos en este entorno de cliente, la dirección documentada todavía no ha superado la prueba de disponibilidad. Afirmar que un fallo de conexión puntual demuestra una avería de toda la red sería más imprudente que ignorar el fallo en sí.
Antes, veía un RPC y me ponía a configurar la cartera. Ahora tengo que cambiar el orden. Una conexión de confianza es la puerta; el chain ID, el número de la habitación; y que el bloque siga avanzando demuestra que hay alguien dentro. Si falta alguno de estos pasos, no debería arriesgar fondos reales para probar. En esta ocasión, los tres aspectos de la red de pruebas se pueden seguir verificando; la red principal se detuvo en el primero. La diferencia no es la velocidad, sino si se puede pasar a la siguiente comprobación.
Para que el endpoint EVM de $DUSK se considere realmente disponible, deben cumplirse a la vez estas tres condiciones: que el certificado sea de confianza, que el chain ID coincida con el esperado y que la altura del bloque siga cambiando. Si no reúno las tres pruebas, lo marcaré como pendiente de investigación, no como disponible, y mucho menos afirmaré que la red principal está caída. La medida más sencilla para que los usuarios comunes eviten pérdidas también es concreta: antes de transferir, hagan estas tres comprobaciones y deténganse si alguna no da resultado.
La documentación proporciona la dirección; solo una prueba real da luz verde. #dusk