Ahora la volatilidad del mercado de valores es alta; todo el capital está yendo al oro para diversificar el riesgo. Yo combino operaciones largas en oro para equilibrar la posición, y cuando hay caídas grandes cargo por lotes. Con la idea de inversión periódica, distribuyo el costo de entrada, con un riesgo más bajo #TradFi晒单
Recientemente, la comunidad ha estado discutiendo los parámetros de la función de personalización de TBV en la red de pruebas @BabylonLabs_io . Mucha gente exclama: por fin ya no nos tienen atados a plantillas fijas de los protocolos. Yo mismo probé a fondo las condiciones de restricción de los scripts de rutas múltiples de Taproot y el proceso de creación de vault, y les comparto algunas opiniones diferentes.
Lo más destacado de este esquema es el nivel de control que el usuario tiene sobre las garantías: el ratio de colateralización, los time locks y la línea de liquidación los configura el propio usuario y se escriben directamente en el script de Taproot, sin necesidad de aprobación por parte de ningún administrador del protocolo. Para quienes, como nosotros, ya hemos pasado por que una liquidación forzada por reglas rígidas de DeFi deje posiciones cerradas inesperadamente, poder alinear las condiciones de salida con la tolerancia al riesgo propia de verdad es un gran avance.$EUL
Pero por muy libre que sea el juego, la arquitectura subyacente todavía presenta un umbral de entrada para los usuarios que no se puede ignorar. Como los parámetros quedan “congelados” dentro del script de Bitcoin al crear el vault, después no se pueden modificar de ninguna manera. Esto significa que, si se configura mal el ratio de colateralización, se elige una longitud incorrecta de time lock o se subestima la volatilidad del mercado respecto a la línea de liquidación, la única vía de corrección es cerrar el vault actual y reconstruirlo, lo que implica el costo de dos transacciones de Bitcoin y una ronda de sincronización del estado entre cadenas. En el lado de Aave tampoco se puede leer tu intención de “querer cambiarlo”, solo acepta los valores ya escritos en el script. Aunque esta situación no es común, suele ser cuando los usuarios más se equivocan: no precisamente en escenarios de operación compleja, sino cuando creen que ya entienden las reglas y bajan la guardia.$DEXE
Estos días, en la red de pruebas configuré distintas combinaciones de parámetros y las ejecuté varias veces para validar el funcionamiento. En general, el flujo de interacción es muy fluido, y se nota que el equipo se esforzó mucho en el diseño de las rutas de los scripts. Pero, siendo honestos, siempre habrá una competencia entre flexibilidad y tolerancia a fallos; no existe ninguna configuración que satisfaga a la vez “ponerlo como quiera” y “si lo configuro mal, poder cambiarlo sin problemas”. Mi recomendación es que todos prueben en la red de pruebas todas las combinaciones de parámetros, pero al crear vault en la red principal no lo fijen de una vez con parámetros de largo plazo: primero pruébenlo con un time lock corto y a pequeña escala; si sale bien, recién entonces aumenten el tamaño. La libertad de parámetros está condicionada a comprender cómo se comporta cada parámetro en condiciones extremas de mercado; hay que mantener tres partes de lucidez para usar bien esta herramienta de reglas construidas por uno mismo.#baby $BABY
El grupo recientemente tomó la integración de Consumer Chain con Babylon como una señal de implementación de que BTC sirve como capa de seguridad compartida. Me tomé tres días para desplegar todos los nodos de la red de pruebas Babylon Genesis, sincronizar los datos de los bloques y seguir paso a paso el flujo de registro de Consumer Chain descrito en la documentación oficial. Fui comparando, sección por sección, con el fragmento del punto 7 del libro blanco titulado "BSN depende de Babylon para proporcionar finalidad", y exporté varios registros de firmas de asistencia para validación cruzada. Mi evaluación a largo plazo es que la seguridad entre cadenas solo depende de la independencia del origen de la finalidad, y no se ve afectada por datos operativos ni por la cantidad de nodos. En un análisis objetivo, desglosé el diseño subyacente que respalda la dependencia de Consumer Chain por la finalidad en esta configuración @BabylonLabs_io .
El comienzo del punto 7 del libro blanco ya señala la contradicción central del modelo de seguridad tradicional de IBC: dos cadenas usan sus propios conjuntos de validadores para determinar la finalidad, y el umbral de seguridad de una transacción entre cadenas depende del límite inferior de seguridad de los conjuntos de validadores de cada una. La arquitectura de BSN cambia el enfoque: cuando Consumer Chain no produce bloques, la producción de bloques la realiza su propio conjunto de validadores, pero la finalidad de los bloques queda a cargo de los Finality Providers registrados en la cadena Babylon Genesis, quienes confirman mediante firmas EOTS.
Consumer Chain no necesita buscar otra capa de seguridad adicional; en esencia, el problema de seguridad se asigna al presupuesto de seguridad económica de BTC de Babylon. $BABY en el sistema BSN asume el consumo de gas de las firmas de asistencia y la validación de la finalidad entre cadenas. El operador de Consumer Chain debe usar BABY para pagar las comisiones de asistencia e incentivar a los FP. Existe una vinculación directa entre los tokens y el mecanismo BSN: no hay un diseño que separe la economía de tokens de la capa de aplicación. $RIF
La tasa de producción de bloques de Consumer Chain debe estar alineada con el ritmo de confirmación de la finalidad de Babylon. El tiempo de bloque de la cadena Babylon es de aproximadamente 1 segundo; si Consumer Chain produce bloques demasiado rápido, acumulará una gran cola de bloques esperando la confirmación de Babylon. Las firmas de los FP dependen del estado en línea de los EOTS Managers y de la coordinación multisig del Covenant Committee: si alguno de los lados mantiene una ventana más larga, la confirmación de finalidad de Consumer Chain se retrasará en consecuencia.
Los defectos de implementación en la capa de acceso del protocolo emergente no constituyen una excepción: no se puede negar el rumbo de compartir la seguridad económica de BTC solo porque, en este momento, la ruta de registro de Consumer Chain no sea fluida. En lo personal, únicamente separé cantidades pequeñas de BABY para practicar el proceso de firmas de asistencia y validación entre cadenas en la red de pruebas. Prioricé familiarizarme con el mecanismo de sincronización de la finalidad entre Consumer Chain y la cadena Babylon, y luego ir incrementando gradualmente el volumen de participación. #baby
Sin darme cuenta, ya he acompañado a Binance durante tanto tiempo. ¡Feliz aniversario número nueve! Espero que la experiencia mejore cada vez más en el futuro y que sigamos explorando juntos el mundo digital #BinanceTurns9