$SUI El TPS máximo indica cuántas acciones puede procesar el sistema, pero hay otra cuestión que preocupa más a los usuarios: ¿cómo pueden recuperar los BTC que depositan? En el artículo anterior hablé de los usos de la financiación de Hashi y de los compromisos de capital; esta vez he repasado las rutas de salida a partir de los documentos de diseño. Después de leerlos, no interpretaré «los BTC permanecen en la red Bitcoin» como «el usuario puede transferirlos por su cuenta en cualquier momento».
La diferencia clave que se añade es que la cadena en la que está un activo y quién puede autorizar su gasto son cuestiones distintas. Según los User Flows de Hashi, el usuario deposita BTC en una dirección de Bitcoin exclusiva y, tras la confirmación, recibe hBTC en Sui. Para los gastos normales se utiliza una estructura 2 de 2: una parte es el comité MPC de Hashi y la otra, Guardian. MPC significa que varias partes colaboran para firmar, mientras que Guardian aporta una segunda comprobación. Que un usuario solicite un retiro no significa que tenga una clave que le permita transferir BTC directamente al margen del protocolo.
El valor de esta comprobación es que limita la liberación de activos en situaciones anómalas, como vulnerabilidades o comportamientos maliciosos. Sin embargo, las medidas de seguridad también pueden afectar a la velocidad de salida. La documentación de Limiter especifica que los retiros tienen una capacidad máxima y un cupo que se repone continuamente; si no hay capacidad suficiente, hay que esperar. Si una solicitud supera la capacidad máxima, se omite hasta que aumente el límite, y el usuario también puede cancelarla conforme a las reglas. Por lo general, se procesan por orden de llegada, pero no existe una garantía estricta. Por eso, que un retiro tarde mucho en procesarse no basta para afirmar que los fondos han sido robados; pero tampoco se puede garantizar que llegue de inmediato solo porque el sistema tenga protecciones. Hay que tener en cuenta conjuntamente la configuración de los límites, la cola y la ejecución efectiva.
También hay una ruta de recuperación que merece una explicación aparte. La documentación de Address Scheme especifica que, además del gasto normal, el script permite que el comité MPC gaste los fondos por separado una vez transcurridos 60 días de bloqueo temporal relativo desde la confirmación del UTXO. Un UTXO puede entenderse como una salida en la cadena que aún no se ha gastado. Este diseño ofrece una vía alternativa de recuperación ante situaciones como la pérdida de las claves de Guardian. El cómputo empieza cuando se confirma esa salida, no cuando el usuario presenta una solicitud de retiro. Tampoco transfiere el derecho de recuperación a cada usuario ni constituye una promesa de servicio de que «todos los retiros tardarán como máximo 60 días».
Por lo tanto, para evaluar si Hashi cumple lo prometido, no basta con fijarse en cuántos BTC se pueden depositar. También hay que observar si los retiros normales se procesan sin problemas, cómo se hacen públicos los parámetros de limitación y cómo se verifican la recuperación y el traspaso del comité si Guardian deja de funcionar. Añadir una comprobación de seguridad y conservar todo el control unilateral del usuario son dos mecanismos distintos. Para determinar si es adecuado para cierto tipo de fondos, hay que tener en cuenta todas estas condiciones de salida.
Este análisis se basa en los documentos de diseño públicos actuales, cuya página todavía indica Testnet; por tanto, no se puede afirmar que la red principal ya funcione plenamente con los mismos parámetros. El anuncio del 8 de octubre habla de un lanzamiento por fases durante este mes. Más adelante habrá que volver a comprobarlo a partir del despliegue efectivo y de los registros reales de salida. La demostración de 40,6 millones de TPS y los compromisos de capital superiores a 500 millones de dólares no sustituyen ese paso. La conclusión adicional por ahora es que para validar el valor de Hashi hay que comprobar tanto si los activos pueden entrar como si pueden salir conforme a las reglas, en condiciones normales y anómalas. Fuentes: User Flows, Guardian, Limiter y Address Scheme de Hashi, de Mysten Labs; la imagen es una ilustración del mecanismo.
La diferencia clave que se añade es que la cadena en la que está un activo y quién puede autorizar su gasto son cuestiones distintas. Según los User Flows de Hashi, el usuario deposita BTC en una dirección de Bitcoin exclusiva y, tras la confirmación, recibe hBTC en Sui. Para los gastos normales se utiliza una estructura 2 de 2: una parte es el comité MPC de Hashi y la otra, Guardian. MPC significa que varias partes colaboran para firmar, mientras que Guardian aporta una segunda comprobación. Que un usuario solicite un retiro no significa que tenga una clave que le permita transferir BTC directamente al margen del protocolo.
El valor de esta comprobación es que limita la liberación de activos en situaciones anómalas, como vulnerabilidades o comportamientos maliciosos. Sin embargo, las medidas de seguridad también pueden afectar a la velocidad de salida. La documentación de Limiter especifica que los retiros tienen una capacidad máxima y un cupo que se repone continuamente; si no hay capacidad suficiente, hay que esperar. Si una solicitud supera la capacidad máxima, se omite hasta que aumente el límite, y el usuario también puede cancelarla conforme a las reglas. Por lo general, se procesan por orden de llegada, pero no existe una garantía estricta. Por eso, que un retiro tarde mucho en procesarse no basta para afirmar que los fondos han sido robados; pero tampoco se puede garantizar que llegue de inmediato solo porque el sistema tenga protecciones. Hay que tener en cuenta conjuntamente la configuración de los límites, la cola y la ejecución efectiva.
También hay una ruta de recuperación que merece una explicación aparte. La documentación de Address Scheme especifica que, además del gasto normal, el script permite que el comité MPC gaste los fondos por separado una vez transcurridos 60 días de bloqueo temporal relativo desde la confirmación del UTXO. Un UTXO puede entenderse como una salida en la cadena que aún no se ha gastado. Este diseño ofrece una vía alternativa de recuperación ante situaciones como la pérdida de las claves de Guardian. El cómputo empieza cuando se confirma esa salida, no cuando el usuario presenta una solicitud de retiro. Tampoco transfiere el derecho de recuperación a cada usuario ni constituye una promesa de servicio de que «todos los retiros tardarán como máximo 60 días».
Por lo tanto, para evaluar si Hashi cumple lo prometido, no basta con fijarse en cuántos BTC se pueden depositar. También hay que observar si los retiros normales se procesan sin problemas, cómo se hacen públicos los parámetros de limitación y cómo se verifican la recuperación y el traspaso del comité si Guardian deja de funcionar. Añadir una comprobación de seguridad y conservar todo el control unilateral del usuario son dos mecanismos distintos. Para determinar si es adecuado para cierto tipo de fondos, hay que tener en cuenta todas estas condiciones de salida.
Este análisis se basa en los documentos de diseño públicos actuales, cuya página todavía indica Testnet; por tanto, no se puede afirmar que la red principal ya funcione plenamente con los mismos parámetros. El anuncio del 8 de octubre habla de un lanzamiento por fases durante este mes. Más adelante habrá que volver a comprobarlo a partir del despliegue efectivo y de los registros reales de salida. La demostración de 40,6 millones de TPS y los compromisos de capital superiores a 500 millones de dólares no sustituyen ese paso. La conclusión adicional por ahora es que para validar el valor de Hashi hay que comprobar tanto si los activos pueden entrar como si pueden salir conforme a las reglas, en condiciones normales y anómalas. Fuentes: User Flows, Guardian, Limiter y Address Scheme de Hashi, de Mysten Labs; la imagen es una ilustración del mecanismo.