Cuando me puse a revisar los materiales de “Babylon” desvelado, en principio solo quería comprobar los límites de los permisos del liquidador. Pero cuanto más leía, más me daba sueño… hasta que algo en particular me hizo volver en sí: el depósito y el retiro no comparten en absoluto la misma lógica de confianza.
Al principio pensé que todo el modelo de confianza del sistema de la bóveda era uniforme. Sin embargo, al avanzar, me di cuenta de que en la etapa de depósito necesitas que un montón de personas asientan con la cabeza, mientras que la lógica de confianza de retiros y liquidaciones es totalmente distinta.
En la parte de depósitos, tienes que pedirle ayuda a otros. Al crear la bóveda, debes enviar una solicitud de Peg-In en Ethereum, adjuntando un secreto de hash-lock que solo tú conoces. Luego, en la red de Bitcoin, difundes una transacción Pre-PegIn, bloqueando BTC en una dirección Taproot vinculada al hash-lock. Después viene el verdadero problema: necesitas que el Vault Provider y el AVK, fuera de la cadena, construyan contigo el grafo de transacciones prefirmadas, y cada participante debe firmar. Solo cuando el depositante revela el secreto del hash-lock, la bóveda se activa formalmente.
En los retiros y las liquidaciones, la lógica es completamente diferente. El retiro sigue la ruta de transacción prefirmada: al momento de crear la bóveda, todas las rutas de gasto legales ya quedan prefirmadas, y una vez generada la bóveda, nadie puede falsificar nuevas rutas de gasto. Cuando se realiza el retiro, el depositante transmite directamente la transacción usando las claves con las que se creó, sin necesidad de que participe nadie más.
En la liquidación, la condición de activación es que el factor de salud del prestatario caiga por debajo de 1.0. Hay dos caminos: con permisos y sin permisos. Pero, sin importar cuál sea, las reglas ya quedan fijadas al crear la bóveda; el liquidador no necesita pedirle a nadie aprobación.
Una frase del documento me hizo parar y pensar: “Trust is optional and removable”. El depósito requiere participación de múltiples partes porque la bóveda aún no existe; la relación de confianza todavía está en construcción: necesitas que el Vault Provider impulse la configuración, que el AVK firme conjuntamente y que los Universal Challengers sirvan como testigos. Pero una vez establecida la bóveda, cuando el grafo de transacciones prefirmadas se congela, ya no necesitas depender de ningún tercero.
Revisé durante toda una noche: no llegué a terminar de entender los permisos del liquidador, pero me perdí en la diferencia de confianza entre depósitos y retiros. Sin embargo, después de pensarlo bien, me pareció razonable: pedirle a otros para que hagan el depósito tiene sentido porque la confianza aún no se ha establecido; en cambio, no pedirle a nadie en retiros y liquidaciones tiene sentido porque la confianza ya quedó bloqueada en el código. ¿Crees que este diseño de “depender de personas durante la fase de construcción y luego depender solo del código” es ingenioso o es redundante? Hablemos en los comentarios.
#BABY $BABY @BabylonLabs_io
Al principio pensé que todo el modelo de confianza del sistema de la bóveda era uniforme. Sin embargo, al avanzar, me di cuenta de que en la etapa de depósito necesitas que un montón de personas asientan con la cabeza, mientras que la lógica de confianza de retiros y liquidaciones es totalmente distinta.
En la parte de depósitos, tienes que pedirle ayuda a otros. Al crear la bóveda, debes enviar una solicitud de Peg-In en Ethereum, adjuntando un secreto de hash-lock que solo tú conoces. Luego, en la red de Bitcoin, difundes una transacción Pre-PegIn, bloqueando BTC en una dirección Taproot vinculada al hash-lock. Después viene el verdadero problema: necesitas que el Vault Provider y el AVK, fuera de la cadena, construyan contigo el grafo de transacciones prefirmadas, y cada participante debe firmar. Solo cuando el depositante revela el secreto del hash-lock, la bóveda se activa formalmente.
En los retiros y las liquidaciones, la lógica es completamente diferente. El retiro sigue la ruta de transacción prefirmada: al momento de crear la bóveda, todas las rutas de gasto legales ya quedan prefirmadas, y una vez generada la bóveda, nadie puede falsificar nuevas rutas de gasto. Cuando se realiza el retiro, el depositante transmite directamente la transacción usando las claves con las que se creó, sin necesidad de que participe nadie más.
En la liquidación, la condición de activación es que el factor de salud del prestatario caiga por debajo de 1.0. Hay dos caminos: con permisos y sin permisos. Pero, sin importar cuál sea, las reglas ya quedan fijadas al crear la bóveda; el liquidador no necesita pedirle a nadie aprobación.
Una frase del documento me hizo parar y pensar: “Trust is optional and removable”. El depósito requiere participación de múltiples partes porque la bóveda aún no existe; la relación de confianza todavía está en construcción: necesitas que el Vault Provider impulse la configuración, que el AVK firme conjuntamente y que los Universal Challengers sirvan como testigos. Pero una vez establecida la bóveda, cuando el grafo de transacciones prefirmadas se congela, ya no necesitas depender de ningún tercero.
Revisé durante toda una noche: no llegué a terminar de entender los permisos del liquidador, pero me perdí en la diferencia de confianza entre depósitos y retiros. Sin embargo, después de pensarlo bien, me pareció razonable: pedirle a otros para que hagan el depósito tiene sentido porque la confianza aún no se ha establecido; en cambio, no pedirle a nadie en retiros y liquidaciones tiene sentido porque la confianza ya quedó bloqueada en el código. ¿Crees que este diseño de “depender de personas durante la fase de construcción y luego depender solo del código” es ingenioso o es redundante? Hablemos en los comentarios.
#BABY $BABY @BabylonLabs_io