Jinjin Finance Blockchain, 10 de junio Un error en el código clasificador de Arbitrum esta semana provocó una breve interrupción de la capacidad de la red para enviar transacciones en lotes, y las transacciones no pudieron confirmarse en la cadena principal. Desde entonces, la vulnerabilidad se solucionó y se restauró la función de envío de lotes de transacciones. El 10 de junio, la Fundación Arbitrum publicó el informe de análisis a posteriori sobre el error clasificador de Arbitrum. A continuación, revisemos y veamos por qué este evento de error no provocó la pérdida de fondos de los usuarios.
Cronología del evento de error del clasificador de Arbitrrum
A las 06:04:53 del 7 de junio de 2023, el emisor del lote no pudo actualizar su vista de estado L1 debido a un problema temporal con el nodo L1 del recopilador de Arbitrum. Debido a un problema de causa raíz, el clasificador Arbitrum siguió intentando consultar el estado de su número de bloque de vista L1 anterior. Esto significa que incluso después de que se resuelva el problema del nodo L1 temporal, el publicador de lotes seguirá intentando consultar el estado del número de bloque L1 anterior y el nodo L1 ya no tendrá su estado porque no es un nodo de archivo.
A las 09:38:28 del 7 de junio de 2023, el cartel de lotes de Arbitrum dejó de publicar transacciones porque alcanzó el límite máximo configurado de transacciones en cola (256), que es el mismo que el límite de mempool. Si no se alcanza este límite, la publicación masiva continuará como de costumbre.
A las 11:09 a. m. del 7 de junio de 2023, debido a lotes no publicados, se activó una alerta en el contrato inteligente de la bandeja de entrada del secuenciador para buscar nuevos lotes y se envió una advertencia al canal de Slack.
A las 11:10 a. m., la falta de lanzamientos de lotes recientes activó una alerta basada en registros y envió una alerta de nivel crítico al canal de Slack.
A las 11:13 a. m., un miembro del equipo de la comunidad inició PagerDuty con un miembro del equipo de SRE, quien rápidamente reconoció el incidente y comenzó a responder.
A las 11:19:02 de la mañana, el equipo de la SRE reinició el cartel de lotes, pero debido al límite máximo de transacciones en cola mencionado anteriormente, el cartel de lotes no pudo publicar transacciones. El equipo de SRE notó este problema y comenzó a cambiar a un proveedor de RPC L1 de terceros en un intento de mitigar el problema.
A las 11:24:16 a. m., 5 minutos después de que comenzara el registro del lote, actualizó la vista de estado de L1 y publicó el primer lote de transacciones.
A las 11:25:09 a. m., la configuración del cartel de lotes se cambió para usar un proveedor de RPC L1 de terceros y se reinició porque el equipo de SRE ya había comenzado a realizar este cambio y no notó el procesamiento por lotes. Después de un reinicio, las transacciones por lotes continúan ocurriendo.
A las 11:30:21 de la mañana, 5 minutos después de que comenzara el cartel del lote, se actualizó la vista de estado de L1, lo que provocó que el estado de L1 no estuviera sincronizado, que también era la causa principal del problema. El estado L1 se actualizó al número de bloque final 17428199, pero utilizó el último nonce 178078, que corresponde al bloque más reciente en ese momento, en lugar del bloque final almacenado en su estado, lo que provocó que se borraran todas las transacciones en cola en Redis Excepto , porque Redis considera que estas transacciones están confirmadas.
A las 11:30:26 a. m., el cartel del lote publicó un nuevo lote. Redis se basa en la vista de estado L1 para determinar qué publicar, pero en este punto la cola de Redis está vacía, como se indicó anteriormente, el estado L1 es incorrecto y se publicó un lote con un número aleatorio en el estado 178078, pero para Determinar el lote a publicar, utilizando un número de bloque irrelevante 17428199, lo que resultó en la publicación de un lote antiguo con un número de serie de 229209, que en realidad se publicó a las 11:24:16 antes, y luego el cartel del lote se reinició. Debido a que el lote antiguo 229209 ya se publicó, la transacción L1 enviada por el lote se revirtió.
A las 11:36:35 AM, la dirección del cartel del lote se quedó sin Ether porque no reembolsó la tarifa del gas, por lo que dejó de publicarse. Este es un mecanismo intencional para evitar que el cartel del lote consuma todo el gas almacenado en el costo del lote de recuperación.
A las 11:46 a. m., un miembro del equipo de Nitro recibió una llamada para resolver un problema de software con la recuperación por lotes.
Alrededor de las 11:58 a. m., Arbitrum comenzó a recibir informes de que algunos usuarios encontraron que había un problema con el clasificador (transmitiendo transacciones recientemente ordenadas a los nodos RPC), porque cada vez más transacciones ordenadas se debían a problemas de publicación por lotes en lugar de publicar Para la cadena, este problema afecta principalmente a los clientes de alimentación con conexiones a Internet deficientes o asignación de memoria insuficiente, ya que es más probable que se caigan y experimenten problemas de reconexión. Arbitrum recomienda que los usuarios que ejecutan múltiples nodos RPC ejecuten un relé de alimentación local para reducir el ancho de banda externo requerido.
A las 12:03 p. m., Arbitrum eliminó el límite de velocidad de alimentación de Cloudflare para aliviar el problema de los clientes que alcanzan el límite de velocidad cuando intentan volver a conectarse después de haber sido desconectados debido a una conexión a Internet.
A las 12:05 p. m., Arbitrum eliminó todos los límites de velocidad de Cloudflare para permitir una mayor utilización pública de RPC para aquellos cuyos nodos tenían problemas para mantener las conexiones con la fuente.
A las 12:12:09 p. m., se cerró el cartel del lote defectuoso y se borró el almacén de la cola de Redis para eliminar el mal estado.
A las 12:12:40 p. m., el cartel del lote comenzó en la versión anterior v2.0.14 y no hubo ningún problema de raíz.
A las 12:21:56 p.
Lecciones aprendidas del evento de error del clasificador de arbitraje
Esta falla fue causada por un error en el cartel del lote. El secuenciador en sí no se vio afectado ni interrumpido y continuó procesando transacciones durante todo el proceso. Los informes de que el secuenciador se quedó sin fondos son incorrectos. El mecanismo de financiación de Arbitrum consta de dos monederos, a saber: el monedero del "secuenciador" y el monedero del "reembolsador de gas". Solo se reembolsará cuando el secuenciador pueda liberar con éxito el lote. La red de Arbitrum no ha reembolsado al secuenciador por este falla, fondos y los problemas relacionados no fueron causados por el secuenciador quedándose sin fondos, por lo que los fondos de los usuarios no estaban en riesgo.
Arbitrum limpiará las opciones de configuración que se agregaron en la solución temporal. Luego, planea volver a evaluar los problemas de tiempo de espera del servidor y del cliente del secuenciador para mejorar la confiabilidad de la red en el caso de retrasos en las transacciones. Una nueva "v2.1.0-beta Versión beta de .2". Además, Arbitrum creará una página de estado de la red pública para reducir la confusión si hay problemas con el servicio.
Se hace referencia a este artículo del sitio web oficial de la Fundación Arbitrum.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Golden Observation | Revisión del evento de error del clasificador de Arbitrum
Autor: Golden Finance Jason
Jinjin Finance Blockchain, 10 de junio Un error en el código clasificador de Arbitrum esta semana provocó una breve interrupción de la capacidad de la red para enviar transacciones en lotes, y las transacciones no pudieron confirmarse en la cadena principal. Desde entonces, la vulnerabilidad se solucionó y se restauró la función de envío de lotes de transacciones. El 10 de junio, la Fundación Arbitrum publicó el informe de análisis a posteriori sobre el error clasificador de Arbitrum. A continuación, revisemos y veamos por qué este evento de error no provocó la pérdida de fondos de los usuarios.
Cronología del evento de error del clasificador de Arbitrrum
A las 06:04:53 del 7 de junio de 2023, el emisor del lote no pudo actualizar su vista de estado L1 debido a un problema temporal con el nodo L1 del recopilador de Arbitrum. Debido a un problema de causa raíz, el clasificador Arbitrum siguió intentando consultar el estado de su número de bloque de vista L1 anterior. Esto significa que incluso después de que se resuelva el problema del nodo L1 temporal, el publicador de lotes seguirá intentando consultar el estado del número de bloque L1 anterior y el nodo L1 ya no tendrá su estado porque no es un nodo de archivo.
A las 09:38:28 del 7 de junio de 2023, el cartel de lotes de Arbitrum dejó de publicar transacciones porque alcanzó el límite máximo configurado de transacciones en cola (256), que es el mismo que el límite de mempool. Si no se alcanza este límite, la publicación masiva continuará como de costumbre.
A las 11:09 a. m. del 7 de junio de 2023, debido a lotes no publicados, se activó una alerta en el contrato inteligente de la bandeja de entrada del secuenciador para buscar nuevos lotes y se envió una advertencia al canal de Slack.
A las 11:10 a. m., la falta de lanzamientos de lotes recientes activó una alerta basada en registros y envió una alerta de nivel crítico al canal de Slack.
A las 11:13 a. m., un miembro del equipo de la comunidad inició PagerDuty con un miembro del equipo de SRE, quien rápidamente reconoció el incidente y comenzó a responder.
A las 11:19:02 de la mañana, el equipo de la SRE reinició el cartel de lotes, pero debido al límite máximo de transacciones en cola mencionado anteriormente, el cartel de lotes no pudo publicar transacciones. El equipo de SRE notó este problema y comenzó a cambiar a un proveedor de RPC L1 de terceros en un intento de mitigar el problema.
A las 11:24:16 a. m., 5 minutos después de que comenzara el registro del lote, actualizó la vista de estado de L1 y publicó el primer lote de transacciones.
A las 11:25:09 a. m., la configuración del cartel de lotes se cambió para usar un proveedor de RPC L1 de terceros y se reinició porque el equipo de SRE ya había comenzado a realizar este cambio y no notó el procesamiento por lotes. Después de un reinicio, las transacciones por lotes continúan ocurriendo.
A las 11:30:21 de la mañana, 5 minutos después de que comenzara el cartel del lote, se actualizó la vista de estado de L1, lo que provocó que el estado de L1 no estuviera sincronizado, que también era la causa principal del problema. El estado L1 se actualizó al número de bloque final 17428199, pero utilizó el último nonce 178078, que corresponde al bloque más reciente en ese momento, en lugar del bloque final almacenado en su estado, lo que provocó que se borraran todas las transacciones en cola en Redis Excepto , porque Redis considera que estas transacciones están confirmadas.
A las 11:30:26 a. m., el cartel del lote publicó un nuevo lote. Redis se basa en la vista de estado L1 para determinar qué publicar, pero en este punto la cola de Redis está vacía, como se indicó anteriormente, el estado L1 es incorrecto y se publicó un lote con un número aleatorio en el estado 178078, pero para Determinar el lote a publicar, utilizando un número de bloque irrelevante 17428199, lo que resultó en la publicación de un lote antiguo con un número de serie de 229209, que en realidad se publicó a las 11:24:16 antes, y luego el cartel del lote se reinició. Debido a que el lote antiguo 229209 ya se publicó, la transacción L1 enviada por el lote se revirtió.
A las 11:36:35 AM, la dirección del cartel del lote se quedó sin Ether porque no reembolsó la tarifa del gas, por lo que dejó de publicarse. Este es un mecanismo intencional para evitar que el cartel del lote consuma todo el gas almacenado en el costo del lote de recuperación.
A las 11:46 a. m., un miembro del equipo de Nitro recibió una llamada para resolver un problema de software con la recuperación por lotes.
Alrededor de las 11:58 a. m., Arbitrum comenzó a recibir informes de que algunos usuarios encontraron que había un problema con el clasificador (transmitiendo transacciones recientemente ordenadas a los nodos RPC), porque cada vez más transacciones ordenadas se debían a problemas de publicación por lotes en lugar de publicar Para la cadena, este problema afecta principalmente a los clientes de alimentación con conexiones a Internet deficientes o asignación de memoria insuficiente, ya que es más probable que se caigan y experimenten problemas de reconexión. Arbitrum recomienda que los usuarios que ejecutan múltiples nodos RPC ejecuten un relé de alimentación local para reducir el ancho de banda externo requerido.
A las 12:03 p. m., Arbitrum eliminó el límite de velocidad de alimentación de Cloudflare para aliviar el problema de los clientes que alcanzan el límite de velocidad cuando intentan volver a conectarse después de haber sido desconectados debido a una conexión a Internet.
A las 12:05 p. m., Arbitrum eliminó todos los límites de velocidad de Cloudflare para permitir una mayor utilización pública de RPC para aquellos cuyos nodos tenían problemas para mantener las conexiones con la fuente.
A las 12:12:09 p. m., se cerró el cartel del lote defectuoso y se borró el almacén de la cola de Redis para eliminar el mal estado.
A las 12:12:40 p. m., el cartel del lote comenzó en la versión anterior v2.0.14 y no hubo ningún problema de raíz.
A las 12:21:56 p.
Lecciones aprendidas del evento de error del clasificador de arbitraje
Esta falla fue causada por un error en el cartel del lote. El secuenciador en sí no se vio afectado ni interrumpido y continuó procesando transacciones durante todo el proceso. Los informes de que el secuenciador se quedó sin fondos son incorrectos. El mecanismo de financiación de Arbitrum consta de dos monederos, a saber: el monedero del "secuenciador" y el monedero del "reembolsador de gas". Solo se reembolsará cuando el secuenciador pueda liberar con éxito el lote. La red de Arbitrum no ha reembolsado al secuenciador por este falla, fondos y los problemas relacionados no fueron causados por el secuenciador quedándose sin fondos, por lo que los fondos de los usuarios no estaban en riesgo.
Arbitrum limpiará las opciones de configuración que se agregaron en la solución temporal. Luego, planea volver a evaluar los problemas de tiempo de espera del servidor y del cliente del secuenciador para mejorar la confiabilidad de la red en el caso de retrasos en las transacciones. Una nueva "v2.1.0-beta Versión beta de .2". Además, Arbitrum creará una página de estado de la red pública para reducir la confusión si hay problemas con el servicio.
Se hace referencia a este artículo del sitio web oficial de la Fundación Arbitrum.