Turso cierra su programa de recompensas por errores
(turso.tech)- Turso cerró su programa de recompensas por errores tras operarlo durante casi un año, pagando 1,000 dólares por fallas que demostraran corrupción de datos
- Con la recompensa en juego, llegó una avalancha de PR de baja calidad generados por IA, y los mantenedores pasaron días cerrándolos
- Al inicio recompensaron a 5 personas, y algunas contribuciones llevaron a mejoras del simulador y al hallazgo de más de 10 bugs en SQLite
- Turso implementó un sistema de avales para cerrar automáticamente los PR sospechosos, pero los bots siguieron insistiendo con issues de revisión manual y reenviando PR similares
- Para mantener abiertas las contribuciones, Turso eligió eliminar el incentivo económico en lugar de cerrar el sistema
Por qué Turso detuvo su programa de recompensas por errores
- Turso pagó 1,000 dólares por bugs que pudieran demostrar corrupción de datos durante casi un año, pero ahora cerró el programa
- Después de agregar la recompensa económica, el repositorio de Turso se llenó de PR de baja calidad generados por IA, y los mantenedores tuvieron que dedicar la mayor parte de varios días a cerrarlos
- Turso quiere seguir siendo un proyecto de contribuciones abiertas, pero considera que pagar dinero por un tipo específico de bug hace que operar contribuciones abiertas sea casi imposible
- La decisión se hizo pública con la idea de que hay que aprender en conjunto cómo establecer la gobernanza del open source en esta nueva era
Por qué iniciaron el programa
- Turso está reimplementando SQLite, conocido como uno de los programas más confiables del mundo, y por eso necesita estándares de confiabilidad igual de altos
- Para igualar o superar el nivel de confiabilidad de SQLite, Turso opera varios sistemas de prueba
- un simulador determinista nativo
- varios fuzzers
- un motor de pruebas diferenciales basado en oráculos que compara contra SQLite
- un simulador de concurrencia
- ejecución extensiva en Antithesis
- Pero la infraestructura de pruebas también es software y no es perfecta; solo puede encontrar bugs dentro de las combinaciones que sus generadores realmente producen
- Por ejemplo, si un fuzzer no crea índices, será difícil encontrar bugs relacionados con índices aunque someta otras partes del sistema a mucho estrés
- Turso encontró un bug que solo aparecía cuando la base de datos superaba 1 GB, pero como inyectaban fallas agresivamente en cada ejecución, la base no alcanzaba ese tamaño y el bug escapó del simulador
- Relacionado: Una aventura escribiendo sistemas compatibles
- La ventaja de las pruebas automatizadas es que, incluso si un bug logra escapar una vez, al mejorar el generador de pruebas se puede eliminar toda una categoría de bugs
- El programa de recompensas era una forma de mostrar confianza en la metodología de pruebas de Turso y, al mismo tiempo, recompensar a quien encontrara áreas que el simulador no cubría bien
- El plan inicial era pagar 1,000 dólares por bugs de corrupción de datos hasta el lanzamiento de Turso 1.0, y después ampliar gradualmente el monto y el alcance de la recompensa
El impacto antes del aumento de envíos de baja calidad por IA
- Al principio del programa, un total de 5 personas recibieron recompensas y aportaron valor real al proyecto
- Alperen fue uno de los principales contribuidores al simulador de Turso y sabía dónde podía mejorarse
- Mikael usó LLM de forma creativa para encontrar puntos a los que el simulador no llegaba, y después fue contratado por Turso
- Pavan Nambi combinó el simulador con métodos formales para encontrar bugs no solo en Turso sino también más de 10 bugs en SQLite mismo
La carga operativa causada por los envíos generados por IA
- El criterio de envío que Turso quería no era simplemente señalar un bug, sino extender el simulador para demostrar un bug de corrupción de datos
- Gracias a esa condición, al principio hubo pocos PR malintencionados en busca de recompensa y tampoco aparecieron muchos bugs reales de corrupción de datos
- Después empezaron a llegar en masa envíos hechos al ordenar a un LLM que encontrara bugs en Turso y cobrara la recompensa
- Cuando recibía esa instrucción, el LLM generaba cualquier salida posible, pero que esa salida fuera válida era otra cuestión
Ejemplos representativos de envíos de baja calidad
-
Un PR que corrompía manualmente el encabezado de la base de datos
- PR #6257 afirmaba que la base de datos se corrompía después de inyectar manualmente bytes basura en el encabezado
- Incluso después de que un mantenedor señaló que ese resultado era obvio, el remitente o bot siguió respondiendo con largas réplicas al estilo de un LLM
-
Un envío que agregaba acceso fuera de límites directamente en el código fuente
- Otro envío agregaba manualmente un acceso a arreglo fuera de límites en el código fuente para corromper la base de datos
- Issue relacionado: tursodatabase/turso#5508
-
Un PR que afirmaba que ejecutar SQL era una vulnerabilidad
- PR #4322 estaba lleno de tablas, marcas de verificación verdes y em dashes, y afirmaba haber encontrado una vulnerabilidad crítica que permitía ejecutar sentencias SQL arbitrarias
- Turso considera que no se puede tratar como vulnerabilidad el simple hecho de que una base de datos SQL permita ejecutar sentencias SQL
-
Un PR que malinterpretaba la función de escrituras concurrentes de Turso
- PR #6874 activó la escritura concurrente, una de las diferencias clave de Turso, y luego mostró que SQLite no podía abrir el archivo hasta volver a cambiar el modo de journal a WAL y desactivar esa función
- Ese resultado era exactamente el comportamiento previsto por diseño
-
Un envío cuya intención era difícil de entender
- Otro envío era difícil de interpretar en cuanto a lo que intentaba hacer
- El mantenedor Mikael concluyó que el remitente había visto el anuncio de la recompensa y apuntó una herramienta de generación por IA contra Turso
La última respuesta: sistema de avales
- Como último intento por poner orden, Turso diseñó e implementó un sistema de avales
- El sistema cerraba automáticamente los envíos que parecían venir de bots, y durante un tiempo funcionó razonablemente bien
- Después los bots empezaron a abrir issues solicitando revisión manual, cuestionando por qué se habían cerrado sus PR
- También hubo varios casos en los que, al cerrarse un PR, el mismo usuario u otro distinto volvía a abrir de inmediato un PR igual o muy parecido
El choque entre contribuciones abiertas e incentivos económicos
- Quien genera envíos de baja calidad solo necesita alrededor de un minuto para producirlos, pero Turso debe dedicar varias horas a leerlos, entenderlos y responder
- En la práctica, este tipo de envíos puede generarse a una velocidad casi infinita
- Se pueden construir sistemas automatizados de filtrado, pero si hay una recompensa económica que no puede ignorarse, la IA seguirá teniendo incentivos para discutir y reabrir el mismo PR
- Turso valora a la comunidad de contribuidores de open source y seguirá fortaleciéndola, pero por ahora considera que ninguna forma de incentivo económico funciona bien en un sistema abierto
- Las opciones eran cerrar el sistema o quitar el incentivo, y por ahora Turso eligió lo segundo
1 comentarios
Comentarios en Hacker News
Esto demuestra que el cuello de botella no es escribir código, sino leerlo y entenderlo
Antes ya pasaba que en cada equipo había algún ingeniero “productivo” que subía PR gigantes mezclados con refactors masivos, hicieran falta o no. Eso era así incluso en una época en la que ni imaginábamos que una red neuronal pudiera generar tanto código
El resultado de esa “productividad” no era acelerar al equipo, sino casi detenerlo. O se iba todo el tiempo en revisar el PR con lupa, o se le daba un LGTM superficial y luego explotaba en producción y todos tenían que volver al tablero de diseño. Además, por culpa de la “productividad” de esa persona, la estructura del proyecto cambiaba demasiado rápido, así que la única persona que realmente sabía con claridad dónde estaba cada cosa era esa persona “tan inteligente, talentosa, productiva y leal a los objetivos de la empresa”
“Casi toda organización de desarrollo de software tiene al menos un desarrollador que lleva la programación táctica al extremo. Es un tornado táctico. Un tornado táctico es un programador prolífico que produce código mucho más rápido que los demás, pero trabaja de una forma completamente táctica. Nadie es más rápido que él para implementar una funcionalidad puntual. En algunas organizaciones, los gerentes tratan al tornado táctico como a un héroe. Pero el tornado táctico deja un rastro de destrucción. Los ingenieros que tienen que trabajar luego con ese código a menudo no lo ven como un héroe. Normalmente son otros ingenieros los que tienen que limpiar el desastre que dejó el tornado táctico, y por eso parece que esos ingenieros, que en realidad son los verdaderos héroes, avanzan más lento que el tornado táctico.”
Y además, mientras más código generado por IA haya, menos gente habrá que realmente lo entienda
Aun así, si tienes buenas pruebas de regresión y un linter sólido, y sabes que el código funciona y no está mal hecho, la revisión debería enfocarse en la calidad general a alto nivel, no en diseccionar la exactitud de cada carácter. Claro, la revisión siguió siendo dolorosa de todos modos
Naturalmente pasé más tiempo leyendo y entendiendo código que escribiéndolo, y a veces mi número de líneas escritas era negativo, algo de lo que me sentía orgulloso
Ahora, gracias a la IA, escribo todavía menos código, y ya renuncié al sueño de sentir logro de esa forma. Ojalá que la capacidad de entender rápido grandes volúmenes de código de procedencia dudosa, ya sea escrito por máquinas o por humanos, siga teniendo valor hasta que me jubile, sobre todo con ayuda de IA. ¿Cómo lo ven?
No escribimos código solo para que lo ejecute una máquina, sino también para que lo lean personas. La revisión de código, el debugging y los cambios futuros implican leer y entender el código que alguien escribió. Y hasta que exista una IA a la que se le puedan exigir responsabilidades por sus acciones, no podemos delegarle ese entendimiento
Es un buen momento para mencionar este gran proyecto: un repositorio honeypot para atraer bots
https://github.com/UnsafeLabs/Bounty-Hunters
Su tabla de posiciones correspondiente está aquí
https://clankers-leaderboard.pages.dev
Me pregunto qué pasará si la IA aprende de ese repositorio y de la actividad dentro de él. ¿Los reportes de bugs en los issues serán problemas reales que se pueden corregir o puro invento sin sentido?
Aunque probablemente no tarde en terminar en una lista de bloqueo de bots de IA
Cerrar el programa es totalmente razonable. Pero hay otras opciones. Se podría hacer que quien envía un reporte pague una pequeña tarifa, y que se le devuelva el dinero si se encuentra un bug real
No importa si el programa realmente paga recompensas. Si aunque sea un reporte se cierra mal, esa historia se va a repetir sin parar
En esos casos ya pierdes tiempo hoy; en adelante también perderías dinero
Sobre todo en empresas pequeñas, antes de enviar algo no tienes forma de saber cómo van a reaccionar
¿Quizás se podría exigir correr toda la suite de pruebas del simulador antes de enviar? Sería una buena verificación de que el remitente no rompió el simulador y, de paso, quizá produciría un artefacto como prueba de trabajo. No sé si sea viable porque no conozco bien el área de seguridad
Llevo más de un año intentando hacer que TursoDB cargue un solo archivo, pero no lo he logrado: https://github.com/ClickHouse/ClickBench/issues/336
Me pregunto cómo se vería hoy Hacktoberfest si todavía le diera una camiseta a todo el mundo. Probablemente no alcanzaría el algodón en todo el planeta
No debería recaer en cada maintainer individual la responsabilidad de frenar esto; GitHub y GitLab tendrían que bloquear estas cuentas antes de que siquiera lleguen al punto de poder abrir PR. En esencia, esto es spam
Vean al usuario que hizo el primer PR mencionado en el texto: https://github.com/Samuelsills. Cuentas así ni siquiera deberían acercarse a abrir un PR en un repositorio conocido
No conozco mucho del tema, así que quizá sea una pregunta tonta, pero si al final se exigiera ejecutar todas las pruebas del simulador para comprobar que los cambios enviados no rompieron funcionalidades existentes, ¿eso podría servir como prueba de trabajo?
¿Y si en vez de una bounty se hiciera una especie de mercado de predicción de verdadero/falso?
Que la gente apueste públicamente por la respuesta, usando sus propios tokens para verificar si el reporte tiene sustancia y comprar la apuesta. Si la mayoría concluye que es falso, gana el operador; si la mayoría concluye que es real, el operador paga
Lo digo en broma, aunque quizá no tanto
¿Alguien ha usado Turso en producción? Es una implementación compatible con SQLite reescrita en Rust, con funciones como soporte para múltiples escritores, y a diferencia de SQLite también está abierta a contribuciones externas
Estoy pensando en usarla en una app full-stack en Rust, porque todo funciona con cargo y no hace falta traer SQLite por separado
Turso también ofrece una base de datos como servicio con un plan gratuito muy generoso, y esa fue la razón principal por la que lo usé
https://x.com/doodlestein/status/2052910351474209258
¿No se podría responder de la misma manera y desplegar su propio bot de IA para hacer una revisión previa de los PR?
“Es posible configurar sistemas automatizados para frenarlo, pero cuando hay un valor monetario nada despreciable en juego, el incentivo para que las IAs sigan discutiendo y vuelvan a abrir el mismo PR es demasiado grande”
Desde fuera, es un problema difícil interesante. ¿Cuántos de esos bots estarán usando Turso en su backend?