Ingeniería del Camino Desafortunado: Entendiendo la Arquitectura de BitVM2 Parte Uno: La Seguridad Vive en el Camino de Disputa Un L2 de Bitcoin vive o muere en su camino desafortunado. En Bitcoin, no obtienes "ejecutar el verificador en la cadena y seguir adelante". Obtienes un entorno de ejecución restringido, gráficos de transacciones pre-firmadas y bloqueos temporales que definen exactamente cuándo puede actuar cada parte. BitVM2 es un patrón de ejecución optimista para Bitcoin: ejecuta fuera de la cadena, luego haz que la corrección sea exigible a través de un protocolo de disputa en la cadena construido a partir de transacciones pre-firmadas. Eso lleva a una regla de ingeniería simple: Si las disputas son costosas o pueden ser detenidas por tarifas, el modelo de seguridad simplemente no funciona. Los sistemas basados en BitVM funcionan permitiendo a los operadores ejecutar fuera de la cadena, luego dando a cualquiera la capacidad de desafiar en la cadena y forzar el protocolo a un camino de disputa bajo una suposición de honestidad 1-de-n (al menos un desafiante honesto para la validez; al menos un operador honesto para la vitalidad). Este camino de disputa es el mecanismo. Las transacciones pre-firmadas y las firmas de un solo uso (ventanas de desafío, plazos de respuesta, finalización) son el "tiempo de ejecución" del puente y sus salidas. Así que cuando hablamos de construir sobre BitVM2, la estrella del norte no son términos de marketing como "sin confianza". La estrella del norte es: • disputas que sean lo suficientemente baratas para ejecutar, • contexto de cadena que sea lo suficientemente objetivo para prevenir salidas de "probar el estado incorrecto" • flujos de transacciones que sigan progresando bajo condiciones reales de tarifas. Esta serie desglosa cómo abordamos esas limitaciones en el diseño del GOAT BitVM2, pieza por pieza. Próximamente en la Parte Dos: los bloqueadores prácticos para desplegar un zkRollup listo para producción en Bitcoin.