Un amigo mío intentó explicarme el escrow (en garantía) una vez usando una analogía de un casillero: tú metes tus cosas, otra persona guarda la llave y tú confías en que te la devolverán cuando digan que lo harán. Yo le dije que así es como yo también imaginaba cada configuración de cripto custodiada, un casillero con la mano de alguien más sobre la llave. Esa comparación se desmoronó para mí cuando seguí el rastro de cómo se crean las rutas de gasto dentro de una bóveda de Babylon, porque resulta que no hay ninguna llave “en manos” de la manera en que yo lo imaginaba. El depositante firma conjuntamente el script de Bitcoin de antemano, en el momento de creación de la bóveda, y cada forma legítima en la que el BTC pueda moverse alguna vez queda firmada y creada desde ese instante, de manera conjunta por el depositante y los participantes del protocolo. Esto lo entendí después de revisar un hilo desde @BabylonLabs_io que recorría la construcción de la bóveda paso a paso.
No queda ninguna “puerta lateral” para más adelante. Una vez que la bóveda existe, nadie, ni el protocolo, ni un conjunto de validadores, ni alguna votación de gobernanza futura, puede inventar una nueva condición de gasto, porque el conjunto válido de firmas quedó fijado al inicio y nada después puede ampliarlo. Lo que es fácil pasar por alto es que esto no es que el protocolo prometa no usar mal los fondos: es que el protocolo no tiene una forma mecánica de construir una transacción fuera de lo que ya fue prefirmado. Es un modelo de seguridad distinto al de la mayoría de configuraciones custodiadas o de puentes con multisig, donde normalmente se conserva flexibilidad a propósito para que las llaves o umbrales puedan ajustarse después del despliegue, conveniente para actualizaciones, pero que a menudo es exactamente la “costura” que termina siendo explotada.
Lo que aún no logro imaginar es cómo se mantiene esa rigidez en situaciones más enredadas: se activan condiciones de slashing, vencen timelocks y el conjunto de participantes rota a lo largo de la vida de una bóveda. Que no existan rutas nuevas y aun así el sistema tenga que adaptarse se siente como una tensión. Así que el principio de diseño en sí parece sólido, más conservador de lo que yo esperaba, pero el comportamiento en casos límite es algo que @BabylonLabs_io aún no me ha mostrado en la práctica.
#BABY $BABY @BabylonLabs_io #IntelRises9%AfterHours $COTI $ON #USStorageStocksExtendLosses
La seguridad de la bóveda depende sobre todo de ?
No queda ninguna “puerta lateral” para más adelante. Una vez que la bóveda existe, nadie, ni el protocolo, ni un conjunto de validadores, ni alguna votación de gobernanza futura, puede inventar una nueva condición de gasto, porque el conjunto válido de firmas quedó fijado al inicio y nada después puede ampliarlo. Lo que es fácil pasar por alto es que esto no es que el protocolo prometa no usar mal los fondos: es que el protocolo no tiene una forma mecánica de construir una transacción fuera de lo que ya fue prefirmado. Es un modelo de seguridad distinto al de la mayoría de configuraciones custodiadas o de puentes con multisig, donde normalmente se conserva flexibilidad a propósito para que las llaves o umbrales puedan ajustarse después del despliegue, conveniente para actualizaciones, pero que a menudo es exactamente la “costura” que termina siendo explotada.
Lo que aún no logro imaginar es cómo se mantiene esa rigidez en situaciones más enredadas: se activan condiciones de slashing, vencen timelocks y el conjunto de participantes rota a lo largo de la vida de una bóveda. Que no existan rutas nuevas y aun así el sistema tenga que adaptarse se siente como una tensión. Así que el principio de diseño en sí parece sólido, más conservador de lo que yo esperaba, pero el comportamiento en casos límite es algo que @BabylonLabs_io aún no me ha mostrado en la práctica.
#BABY $BABY @BabylonLabs_io #IntelRises9%AfterHours $COTI $ON #USStorageStocksExtendLosses
La seguridad de la bóveda depende sobre todo de ?
Fixed paths
50%
No side door
31%
Timelocks
13%
Edge case
6%
16 Votos • Votación cerrada
