Ingeniería El camino infeliz: Entendiendo la arquitectura BitVM2 Parte Uno: La seguridad vive en el camino de la disputa Un L2 de Bitcoin vive o muere en su camino infeliz. En Bitcoin, no tienes "ejecuta el verificador en cadena y sigue adelante". Obtienes un entorno de ejecución restringido, gráficos de transacciones pre-firmados y timelocks que definen exactamente cuándo puede actuar cada parte. BitVM2 es un patrón de aplicación optimista para Bitcoin: ejecutar fuera de cadena y luego hacer que la corrección sea exigible mediante un protocolo de disputa on-chain construido a partir de transacciones prefirmadas. Esto conduce a una regla de ingeniería sencilla: si las disputas son costosas o pueden quedar con retraso en las tarifas, el modelo de seguridad simplemente no funciona. Los sistemas basados en BitVM funcionan permitiendo que los operadores ejecuten fuera de la cadena y luego dando a cualquiera la capacidad de impugnar la cadena y forzar el protocolo a una ruta de disputa bajo la suposición de honestidad de 1 de n (al menos un desafiante honesto para validez; al menos un operador honesto para la vivencia). Este camino de disputa es el mecanismo. Las transacciones prefirmadas y las firmas únicas (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 polar no es términos de marketing como "sin confianza". La estrella polar es: • disputas lo suficientemente baratas para ejecutarse, • contexto en cadena lo suficientemente objetivo como para evitar salidas de "probar el estado equivocado" • flujos de transacciones que continúan avanzando bajo condiciones reales de comisiones. Esta serie desglosa cómo abordamos esas limitaciones en el diseño de GOAT BitVM2, pieza a pieza. Próximamente en la Parte Dos: los obstáculos prácticos para desplegar un zkRollup listo para producción en Bitcoin.