Postmortem del incidente: ventanas emergentes de confirmación lentas

A partir del jueves 25 de abril de 2019, los usuarios que interactuaban con dapps a través de MetaMask encontraron que algunas ventanas emergentes de confirmación tardaban un minuto más en cargarse. En este artículo, revisaremos por qué sucedió esto, qué hicimos al respecto y qué haremos de manera diferente la próxima vez para que este tipo de cosas sea menos probable que ocurra en el futuro.

TLDR; Tuvimos una supervisión del proceso, almacenamos en caché menos de lo que pudimos y teníamos un tiempo de espera de solicitud establecido demasiado lento. Recomendamos a los desarrolladores de Dapp que registren los nombres de los métodos de sus aplicaciones en el registro de métodos en cadena.

Contexto del cambio

En MetaMask, sabemos desde hace mucho tiempo que uno de nuestros deberes más importantes es hacer que las transacciones sean seguras y coherentes para que los usuarios las aprueben y, a lo largo de nuestro historial, hemos recorrido un largo camino para hacerlas más seguras y fáciles de entender. lo que estás haciendo con MetaMask, ¡pero aún nos queda un largo camino por recorrer!

A principios de este año, introdujimos la integración con el registro de métodos en cadena de Parity, lo que permitió a los desarrolladores verificar los nombres de sus funciones, para que pudiéramos representarlos en la pantalla de confirmación.

Elegimos este enfoque porque se basó en la misma infraestructura de confianza que el usuario ya ha configurado (Infura por defecto, o cualquier otro proveedor que elija), para solicitar un registro de contratos inteligentes que pueda verificar sin confianza las firmas de métodos que se le envían en -chain, lo que nos permite representar un nombre de método con un alto grado de certeza. Este fue el nombre del método que el desarrollador utilizó al escribir el contrato (aparte de las colisiones de hash).

Este enfoque está lejos de ser perfecto: carece de traducción, o realmente carece de una interpretación rica de la transacción, pero es algo agradable y fácil que sabíamos que podíamos agregar y que da contexto a una pantalla que de otro modo sería difícil de descifrar al interactuar con contratos con los que no está familiarizado.

A pesar de publicar esa integración, muchos desarrolladores no han registrado los nombres de sus métodos en ese registro en cadena, y nuestro programa MetaMetrics nos enfatizó aún más lo importante que es la pantalla de confirmación para nuestra experiencia de usuario.

Esto nos llevó a buscar un método de búsqueda de registro centralizado alternativo, aprovechando 4byte.directory de la maravillosa Piper Merriam. Nuestra vista de confirmación verificaría primero el registro en cadena, y si no estuviera disponible, probaría 4byte.

La naturaleza del problema

A pesar de este plan razonable, tuvimos algunos problemas con la forma en que finalmente se llevó a cabo.

En primer lugar, las búsquedas en el directorio bloquearon la carga de la pantalla de confirmación, que ya sabemos que es más lenta de lo ideal para cargar. Esto significa que si esas búsquedas son lentas, la ventana de confirmación también aparecerá lentamente.

En segundo lugar, aunque tuvimos un buen manejo de errores para este punto final, el período de tiempo de espera para la búsqueda de 4 bytes no se personalizó, por lo que el valor predeterminado era un minuto, por lo que si 4byte.directory era muy lento para responder o arrojar errores, los usuarios esperaría hasta un minuto antes de ver una ventana de confirmación genérica de “Interacción del contrato”.

En tercer lugar, también agregamos la representación del nombre del método a nuestra lista de transacciones, y estas búsquedas no se almacenaron en caché localmente, por lo que cada usuario que cargó su lista de transacciones contribuyó esencialmente a un DDoS de 4byte.directory durante ese tiempo.

En cuarto lugar, el cambio se revisó y fusionó sin coordinarse con 4byte en sí, por lo que 4byte no estaba preparado para la avalancha de solicitudes de los usuarios.

Si combina los DDoS de la lista de transacciones con el tiempo de espera prolongado de la búsqueda de confirmación, tendrá algunos usuarios que utilizan nombres de métodos no registrados que obtienen ventanas de confirmación de un minuto.

A través de este proceso, algunas personas nos han preguntado acerca de la naturaleza de nuestro proceso de control de calidad, y tenemos un proceso bastante completo y documentado para una versión, y también implementamos esta versión gradualmente, comenzando con el 3% de los usuarios de Chrome en El martes, y no se implementó por completo hasta el jueves, pero debido a que el problema solo se manifestaría realmente cuando se redujeran 4bytes, el problema no se hizo realmente visible hasta que estuvimos completamente implementados en producción, comenzó la actividad del viernes por la mañana y el DDoS estaba en pleno efecto.

Muchos usuarios nos tuitearon, y nuestro equipo de soporte lamenta no haber notado la correlación de estos informes, pero tomados individualmente, el problema era similar a una variedad de otros problemas, como usuarios con conexiones lentas a Internet, por lo que recibieron ayuda. de una manera más genérica.

También recibimos una serie de informes sobre nuestro GitHub, que permitieron a los usuarios concentrarse en problemas comunes, haciendo mucho más obvio que los informes eran un problema nuevo y generalizado, y esto, en última instancia, es lo que primero llamó la atención de nuestro equipo.

Nuestra respuesta

Una vez que nos alertaron sobre el problema, identificamos la causa muy rápidamente y teníamos una corrección de reversión de relaciones públicas lista en una hora, que luego publicamos de inmediato en las tiendas de Firefox y Chrome.

Tuvimos miembros del equipo que se comunicaron con los usuarios en GitHub y por correo electrónico y redes sociales sobre la naturaleza del problema, y ​​cómo podrían solucionarlo instalando la nueva solución manualmente si fuera necesario, en lugar de esperar a que la actualización se auto- instalar.

Desafortunadamente, la tienda de Google Chrome también marcó automáticamente esta versión en particular (la corrección) para una revisión manual, que fue un procedimiento nuevo para nosotros. No teníamos idea de cuánto tiempo iba a tomar ese proceso, por lo que comenzamos a trabajar en soluciones alternativas para situaciones en las que Google podría demorar inaceptablemente en aceptar nuestro cambio.

Estábamos preparados para actualizar en gran medida el registro en cadena, evitando a su vez nuestras búsquedas en 4byte.directory, en el momento en que Google aceptó la actualización de nuestra versión y, desde entonces, debería estar disponible para todos los usuarios.

Aprendizajes y próximos pasos

Ha pasado un tiempo desde que tuvimos un problema de usabilidad grave como este, por lo que estamos aprovechando la oportunidad para aprender todo lo posible sobre nuestro proceso de este evento.

En primer lugar, estamos mejorando nuestra política de revisión de código para incluir requisitos sobre solicitudes de extracción que involucran API de terceros, incluida la coordinación con ellos, el almacenamiento en caché adecuado de esas solicitudes y garantizar que los tiempos de espera se consideren teniendo en cuenta una buena experiencia de usuario.

Se sugirió que invitáramos a la comunidad a facilitar nuestro proceso de control de calidad, por lo que actualmente estamos considerando un programa de control de calidad de la comunidad en el que publicaríamos compilaciones “nocturnas” durante un período antes de pasar a la producción, con recompensas de errores en cada una. uno.

Planeamos hacer que nuestras ventanas de confirmación se carguen más rápido con varias estrategias, que incluyen permitir que los datos no críticos se carguen en línea (y no bloquear la carga del resto de la interfaz). También estamos planeando agregar un almacenamiento en caché mucho más completo para estas firmas de métodos, para reducir la cantidad de solicitudes salientes, y también estamos buscando alojar una caché de CDN de firmas de métodos, para no sobrecargar la infraestructura de la comunidad.

Por último, también estamos redactando una guía de respuesta a crisis que incluye algunos trucos que se nos ocurrieron durante este evento para ayudarnos a coordinarnos de manera más eficaz con los usuarios afectados en los numerosos canales de comunicación en los que se comunican con nosotros.

Si es un desarrollador de dapp, también puede mejorar la experiencia de usuario registrando los nombres de sus funciones en el registro en cadena como se describe en nuestros documentos aquí.

Conclusión

En MetaMask, tenemos el privilegio de facilitarle el uso de la web descentralizada y, a medida que nuestra base de usuarios ha crecido, también lo ha hecho nuestra responsabilidad de ofrecerle una experiencia sólida. Estamos orgullosos de cuánto tiempo ha pasado desde que tuvimos un problema de usabilidad que afectó a tanta gente, pero solo nos hemos vuelto tan estables como lo somos a través de una disciplina rigurosa y un compromiso con la calidad en todos los niveles, por lo que estamos felices para aprovechar esta oportunidad de aprender y crecer, y al mostrarle cómo estamos lidiando con los problemas que enfrentamos, esperamos que mantengamos su confianza en que estamos aquí, tomándonos en serio su experiencia y seguridad.