Como se informó esta semana, una dirección asociada con el exploit FTX ha estado moviendo fondos a través de varios proyectos entre cadenas.
Si bien la mayoría de los fondos pasaron a través de Thorchain, algunos de ellos pasaron a través de tBTC. En el proceso, se han expuesto dos errores.
Ninguno de los errores pone en riesgo los fondos de los usuarios. El primero fue parcheado y lanzado ayer, mientras que el segundo requiere discusión y consenso de la comunidad.
El primer error: un vector de denegación de servicio
El sábado 30 de septiembre, una dirección asociada a FTX solicitó un canje de 76,81431578 BTC.
En tBTC hoy, cualquier usuario con un saldo de tBTC L1 puede solicitar canjes. Después de un tiempo, un mantenedor fuera de la cadena delegado por la DAO Threshold en el
Coordinador de billetera
El contrato verifica una solicitud de reembolso, lo que indica a los firmantes que consideren válida la solicitud de reembolso. Si 51 de los 100 firmantes de una billetera en particular están de acuerdo, firman y liberan conjuntamente esos fondos en la cadena de bloques de Bitcoin.
Después de un tiempo, el encargado de los canjes aprobó esta solicitud de canje. Al menos 51 de los firmantes de la billetera asociada aceptaron y el canje se completó.
9 horas después, una dirección diferente asociada con el exploit de FTX solicitó otro canje, esta vez por 76,62186419 BTC.
Poco después, sucedió algo increíble.
Un tercero desconocido envió transacciones BTC a dos de las billeteras detrás de tBTC.
Ahora bien, esto sucede todo el tiempo: después de todo, tBTC se acuña depositando BTC. Pero en lugar de una transacción de depósito normal, estas transacciones se crearon manualmente de tal manera que los clientes que firmaron tBTC pensaron que las billeteras estaban "ocupadas" moviendo fondos y no podían atender las solicitudes de canje. El encargado de la aprobación esperó a que las billeteras ya no estuvieran "ocupadas", lo que nunca sucedió.
Efectivamente, estas transacciones de BTC bloquearon todos los reembolsos de tBTC pendientes.
No sabemos quién envió estas transacciones, pero quienesquiera que hayan sido, sabían lo suficiente como para pausar por la fuerza el puente tBTC, quemando un simple exploit de día cero en el proceso y evitando que se aprobara el segundo canje asociado a FTX.
Esto es algo nuevo para mí. Ningún sombrero blanco se ha comunicado conmigo ni me ha ofrecido ninguna explicación, pero el momento es increíble.
En ese momento, los sistemas de alerta y monitoreo utilizados por los colaboradores en todo el DAO estaban en pleno apogeo. El equipo de desarrollo de Keep comenzó a preparar un parche para solucionar el problema de denegación de servicio durante el fin de semana.
Para entonces, también entendimos que uno de los canjes bloqueados estaba asociado con FTX.
El segundo error: falla en el diseño del mecanismo de redención
El segundo error se hizo evidente mientras preparábamos el primer parche.
El DAO Threshold puede delegar en múltiples direcciones de aprobadores en el
Coordinador de billetera
contrato.
Lamentablemente, hasta el día de hoy, solo ha habido una delegación a una única dirección de mantenimiento, lo que supone un único punto de fallo. Hoy, esa dirección está controlada por una empresa de propiedad estadounidense, a la que no se le permite aprobar el canje asociado a FTX.
Arreglando el diseño del mecanismo
El hecho de que solo haya un único aprobador delegado con 25 millones de dólares en saldos totales bloqueados fue un descuido. Sin embargo, el problema más grave es el diseño del mecanismo en sí.
Cualquier sistema que dependa de la aprobación explícita de un canje está destinado a tener otro problema como este. Cuando se lanzó el protocolo por primera vez, la razón para un mecanismo de aprobación era la velocidad y la facilidad de uso; las alternativas implicaban una peor experiencia de usuario.
No creo que el sistema actual haya hecho las concesiones correctas.
Hay dos enfoques claros para solucionar esta falla
Pasar de un flujo basado en aprobación a un flujo basado en veto
Eliminar todas las revisiones de redención a nivel de protocolo
Creo que el diseño de mecanismo más seguro, de cara al futuro, es algo que yo llamo "redenciones optimistas". En lugar de una lista de direcciones que finalizan las redenciones, tenemos una lista de direcciones que pueden vetar una redención, similar al papel del Guardián en la acuñación optimista.
Con este mecanismo en funcionamiento, todos los canjes son válidos de forma predeterminada. Si un canje es vetado debido a un presunto hackeo del puente, se puede retrasar. Si es vetado por suficientes guardianes, se puede recurrir a una votación de los poseedores de tokens. Si el veto es confirmado por una votación de los poseedores de tokens, el canje de tBTC rechazado se puede devolver automáticamente al usuario que realizó el canje.
La desventaja es que este mecanismo hipotético requiere un retraso adicional para cada canje. Sin embargo, con el tiempo, ese retraso podría reducirse a tan solo 15 minutos y eliminarse por completo para transacciones pequeñas.
Por último, si la comunidad considera que el sistema es seguro sin un período de revisión de canje, podría eliminar la demora por completo y migrar sin problemas del primer enfoque al segundo. De hecho, creo que un cronograma claro para eliminar la revisión de canje ayudaría a generar confianza en toda la comunidad.
Independientemente de cómo se resuelva este fallo en el diseño del mecanismo, hemos aprendido muchísimo de esta experiencia, y me alegro de que lo hayamos aprendido esta semana en lugar de diez veces a partir de ahora.
¿Qué sigue?
La DAO y la comunidad tienen que tomar decisiones.
Ya sea que la comunidad decida agregar otra dirección de aprobador, actualizar los contratos a un mecanismo de estilo de "redención optimista" o investigar y considerar otras opciones, como equipo de desarrollo, estamos aquí para asesorar y ayudar a construir un futuro de finanzas más sólido, seguro y neutral, juntos.