Tercera sesión, y hoy alcancé el mecanismo que hace posible el tbv en absoluto: el procedimiento de desafío basado en BABE, porque aquí mismo es donde la afirmación sin confianza vive o muere.
Primero, plantea el problema con precisión. Tu btc está bloqueado en bitcoin. Tu préstamo se repaga en ethereum. Ahora debería liberarse el btc, pero bitcoin no tiene idea de que existe ethereum. El script de bitcoin no puede consultar otra cadena, no puede ejecutar un oráculo, no puede verificar computación arbitraria. Entonces, ¿cómo aprende un UTXO de bitcoin que realmente ocurrió un evento de ethereum?
Cada respuesta anterior a esta pregunta ha sido de una parte confiable. Un custodio que observa ethereum y libera monedas. Una federación de firmantes votando sobre lo que vieron. Un contrato puente con operadores. Cada uno reintroduce exactamente el intermediario del que el depositante estaba tratando de escapar.
La respuesta de Babylons es que la redención de colateral usa un procedimiento de desafío que permite que bitcoin verifique pruebas de eventos de redención en ethereum usando únicamente primitivas existentes del script de bitcoin. Léelo con atención: solo PRIMITIVAS EXISTENTES. No se requiere un fork de bitcoin, no se agregan nuevos opcodes, no hay que esperar a que la comunidad de bitcoin apruebe nada. La maquinaria de verificación se ensambla completamente a partir de piezas que bitcoin ya tiene.
¿Por qué la propiedad de no-fork importa tanto? Porque todo diseño de defi de bitcoin que requiere que bitcoin cambie primero es, efectivamente, vaporware; bitcoin cambia en una escala de décadas. Un protocolo que funciona con el bitcoin de hoy es desplegable; un protocolo que necesita el bitcoin de mañana es un artículo de investigación.
Lo que todavía no tengo claro son las suposiciones de vivacidad en los procedimientos de desafío: quién presenta la prueba, quién puede impugnarla y qué ocurre si nadie aparece durante la ventana de desafío. Ahí es donde profundizo a continuación, porque los sistemas basados en desafíos solo son tan fuertes como su vigilante más perezoso.
@BabylonLabs_io #baby $BABY
Primero, plantea el problema con precisión. Tu btc está bloqueado en bitcoin. Tu préstamo se repaga en ethereum. Ahora debería liberarse el btc, pero bitcoin no tiene idea de que existe ethereum. El script de bitcoin no puede consultar otra cadena, no puede ejecutar un oráculo, no puede verificar computación arbitraria. Entonces, ¿cómo aprende un UTXO de bitcoin que realmente ocurrió un evento de ethereum?
Cada respuesta anterior a esta pregunta ha sido de una parte confiable. Un custodio que observa ethereum y libera monedas. Una federación de firmantes votando sobre lo que vieron. Un contrato puente con operadores. Cada uno reintroduce exactamente el intermediario del que el depositante estaba tratando de escapar.
La respuesta de Babylons es que la redención de colateral usa un procedimiento de desafío que permite que bitcoin verifique pruebas de eventos de redención en ethereum usando únicamente primitivas existentes del script de bitcoin. Léelo con atención: solo PRIMITIVAS EXISTENTES. No se requiere un fork de bitcoin, no se agregan nuevos opcodes, no hay que esperar a que la comunidad de bitcoin apruebe nada. La maquinaria de verificación se ensambla completamente a partir de piezas que bitcoin ya tiene.
¿Por qué la propiedad de no-fork importa tanto? Porque todo diseño de defi de bitcoin que requiere que bitcoin cambie primero es, efectivamente, vaporware; bitcoin cambia en una escala de décadas. Un protocolo que funciona con el bitcoin de hoy es desplegable; un protocolo que necesita el bitcoin de mañana es un artículo de investigación.
Lo que todavía no tengo claro son las suposiciones de vivacidad en los procedimientos de desafío: quién presenta la prueba, quién puede impugnarla y qué ocurre si nadie aparece durante la ventana de desafío. Ahí es donde profundizo a continuación, porque los sistemas basados en desafíos solo son tan fuertes como su vigilante más perezoso.
@BabylonLabs_io #baby $BABY