Al ver en TBV funciones como Vault Provider, Application Vault Keeper, Universal Challenger, etc., también me surgieron dudas al principio: si el sistema todavía necesita a tantos operadores, ¿cómo puede llamarse “no custodial”?
Después de seguir investigando, creo que la clave no está en si hay personas involucradas en el sistema, sino en qué poder tiene realmente cada una.
Vault Provider impulsa los depósitos y los rescates, genera las pruebas y las difunde en transacciones de Bitcoin; Application Vault Keeper participa en la configuración del lado de la aplicación y, en integraciones con Aave, incluso puede intervenir en la liquidación y la liquidación/ajuste de cuentas; Universal Challenger se encarga de supervisar continuamente las pruebas de retiro y de impedir retiros inválidos.
Estos roles pueden afectar si el proceso es oportuno, pero no pueden crear temporalmente una ruta nueva de gasto de Bitcoin. A dónde puede fluir el BTC ya está escrito en los scripts y en la estructura de prefirmas cuando se crea el Vault. Incluso si el Provider deja de prestar servicio, no puede mover el BTC de los usuarios a su propia dirección; además, los usuarios aún pueden impulsar el retiro por sí mismos apoyándose en los materiales guardados.
Esto me hizo replantear “desconfianza” (no necesitar confianza): no significa que el sistema no requiera operadores en absoluto, sino que los operadores pasan de ser controladores de activos a ejecutores de servicios.
Un buen protocolo no debería asumir que todos los proveedores de servicios siempre están en línea y son honestos; debería dar por hecho que una parte se desconectará, cometerá errores o incluso actuará con mala intención, y luego limitar los peores resultados que pueden causar.
Por eso, al observar la estructura de los participantes de TBV, no me fijo tanto en la cantidad de roles, sino en lo que cada rol puede y no puede hacer, y en si el usuario puede reemplazarlo cuando ese rol falla. El poder tiene límites; y eso es más importante que simplemente reducir el número de nodos. #baby $BABY @BabylonLabs_io
Después de seguir investigando, creo que la clave no está en si hay personas involucradas en el sistema, sino en qué poder tiene realmente cada una.
Vault Provider impulsa los depósitos y los rescates, genera las pruebas y las difunde en transacciones de Bitcoin; Application Vault Keeper participa en la configuración del lado de la aplicación y, en integraciones con Aave, incluso puede intervenir en la liquidación y la liquidación/ajuste de cuentas; Universal Challenger se encarga de supervisar continuamente las pruebas de retiro y de impedir retiros inválidos.
Estos roles pueden afectar si el proceso es oportuno, pero no pueden crear temporalmente una ruta nueva de gasto de Bitcoin. A dónde puede fluir el BTC ya está escrito en los scripts y en la estructura de prefirmas cuando se crea el Vault. Incluso si el Provider deja de prestar servicio, no puede mover el BTC de los usuarios a su propia dirección; además, los usuarios aún pueden impulsar el retiro por sí mismos apoyándose en los materiales guardados.
Esto me hizo replantear “desconfianza” (no necesitar confianza): no significa que el sistema no requiera operadores en absoluto, sino que los operadores pasan de ser controladores de activos a ejecutores de servicios.
Un buen protocolo no debería asumir que todos los proveedores de servicios siempre están en línea y son honestos; debería dar por hecho que una parte se desconectará, cometerá errores o incluso actuará con mala intención, y luego limitar los peores resultados que pueden causar.
Por eso, al observar la estructura de los participantes de TBV, no me fijo tanto en la cantidad de roles, sino en lo que cada rol puede y no puede hacer, y en si el usuario puede reemplazarlo cuando ese rol falla. El poder tiene límites; y eso es más importante que simplemente reducir el número de nodos. #baby $BABY @BabylonLabs_io
