#baby $BABY 评assar un protocolo de interoperabilidad entre cadenas, ahora mi orden es completamente lo contrario al de antes. Sin abrir primero el paper de pruebas ni el diseño criptográfico, primero pregunto un problema difícil de obtener con una respuesta convincente: si todos los componentes fuera de la cadena del protocolo están desconectados, ¿cuánta funcionalidad central queda? La criptografía determina si las transiciones de estado pueden verificarse correctamente, y la ejecución continua de los participantes fuera de la cadena determina si las transiciones de estado pueden activarse a tiempo. $BEAT
@BabylonLabs_io el papel del retador se queda justo atascado en este problema. En el proceso de liquidación de TBV, BitVM3 y BaBe resuelven el asunto de “una vez que se envía una prueba de refutación, el script de Bitcoin puede verificar su validez”. Pero la generación y el envío de la prueba de refutación no se automatizan: el retador necesita ejecutar nodos de monitoreo, identificar pruebas de liquidación sospechosas, construir la refutación y pagar el gas on-chain. Cada eslabón depende de la participación continua de las personas; que no se automatice no es porque no se quiera, sino porque el análisis del estado off-chain y el reconocimiento del fraude no pueden codificarse automáticamente en scripts desde la capa criptográfica.$COTI
Con una analogía basta para ver dónde está el problema. El documento de diseño del plan de recompensas por vulnerabilidades puede escribirse con gran perfección, pero el efecto real depende de si los investigadores realmente dedican tiempo a buscar fallos. Cuando hace buen tiempo, siempre alguien mira el código; pero cuando las necesidades de auditoría explotan de golpe, el tiempo del investigador se vuelve un recurso escaso. La red de retadores enfrenta el mismo problema: cuando la frecuencia de liquidación es baja, el costo operativo es bajo y hay muchos participantes; cuando aumenta el volumen de préstamos entre cadenas, dentro de cada ventana de desafío la verificación de pruebas y la construcción de refutaciones empiezan a presionar los recursos de ejecución limitados. La tasa real de participación de los retadores, si puede cubrir cada ventana, depende de la calidad del diseño del mecanismo de reparto de costos operativos, no de la propia estructura del protocolo de pruebas.
Mi postura no es negar la dirección de la arquitectura de retadores. Sustituir la revisión monopolizada por un comité con participación abierta, a largo plazo, efectivamente reduce el riesgo de centralización. Pero en la documentación actual del protocolo no se detalla mucho el mecanismo específico de incentivos económicos para los retadores: el origen de las recompensas por el envío de refutaciones, los estándares de compensación de gas, y el método de coordinación entre múltiples retadores. Estos detalles son más importantes para predecir la tasa real de participación que los componentes criptográficos. Cuando el esquema de incentivos comienza a mostrar desgaste, la velocidad a la que los participantes se marchan suele ser más rápida de lo que se esperaba.
@BabylonLabs_io el papel del retador se queda justo atascado en este problema. En el proceso de liquidación de TBV, BitVM3 y BaBe resuelven el asunto de “una vez que se envía una prueba de refutación, el script de Bitcoin puede verificar su validez”. Pero la generación y el envío de la prueba de refutación no se automatizan: el retador necesita ejecutar nodos de monitoreo, identificar pruebas de liquidación sospechosas, construir la refutación y pagar el gas on-chain. Cada eslabón depende de la participación continua de las personas; que no se automatice no es porque no se quiera, sino porque el análisis del estado off-chain y el reconocimiento del fraude no pueden codificarse automáticamente en scripts desde la capa criptográfica.$COTI
Con una analogía basta para ver dónde está el problema. El documento de diseño del plan de recompensas por vulnerabilidades puede escribirse con gran perfección, pero el efecto real depende de si los investigadores realmente dedican tiempo a buscar fallos. Cuando hace buen tiempo, siempre alguien mira el código; pero cuando las necesidades de auditoría explotan de golpe, el tiempo del investigador se vuelve un recurso escaso. La red de retadores enfrenta el mismo problema: cuando la frecuencia de liquidación es baja, el costo operativo es bajo y hay muchos participantes; cuando aumenta el volumen de préstamos entre cadenas, dentro de cada ventana de desafío la verificación de pruebas y la construcción de refutaciones empiezan a presionar los recursos de ejecución limitados. La tasa real de participación de los retadores, si puede cubrir cada ventana, depende de la calidad del diseño del mecanismo de reparto de costos operativos, no de la propia estructura del protocolo de pruebas.
Mi postura no es negar la dirección de la arquitectura de retadores. Sustituir la revisión monopolizada por un comité con participación abierta, a largo plazo, efectivamente reduce el riesgo de centralización. Pero en la documentación actual del protocolo no se detalla mucho el mecanismo específico de incentivos económicos para los retadores: el origen de las recompensas por el envío de refutaciones, los estándares de compensación de gas, y el método de coordinación entre múltiples retadores. Estos detalles son más importantes para predecir la tasa real de participación que los componentes criptográficos. Cuando el esquema de incentivos comienza a mostrar desgaste, la velocidad a la que los participantes se marchan suele ser más rápida de lo que se esperaba.