iPreMyZX
2.3k Publicaciones
iPreMyZX
Denunciar
Bloquear usuario
Abrir trade
Trader frecuente
2.5 año(s)
40 Siguiendo
10.5K+ Seguidores
7.0K+ Me gusta
Publicaciones
Cartera
Todo
Citas
·
--
Al principio miré $DUSK como miraría la mayoría de tokens de nivel L1: oferta, liquidez, rendimiento por staking y demanda del mercado.
Pero cuanto más estudiaba Dusk, más me daba cuenta de que el token tiene un papel mucho más práctico dentro de la red.
DUSK se utiliza para las comisiones de transacción y el staking. Cada transacción consume gas, mientras que hacer staking de DUSK permite que los proveedores de nodos participen en el consenso y obtengan recompensas del protocolo.
Eso genera una suposición con la que no me siento del todo cómodo:
Si Dusk crece, ¿la demanda de tokens crece realmente con ello?
Depende de qué tipo de actividad crezca.
Más aplicaciones podrían significar más transacciones y, por lo tanto, más uso de gas. Más actividad financiera también podría aumentar la importancia de validadores confiables que aseguren la red.
Pero hay otro lado.
Dusk actualmente tiene una oferta inicial de 500 millones de DUSK, con otros 500 millones programados para emitirse durante 36 años como incentivos de staking.
Así que no creo que tenga sentido analizar la economía de DUSK solo a través de la oferta.
Me interesa más la relación entre la actividad de la red → consumo de gas → staking → seguridad → demanda de tokens.
Si Dusk se convierte en infraestructura para activos regulados, transacciones privadas y aplicaciones financieras, entonces DUSK podría, gradualmente, dejar de tratarse simplemente de mantener un token de blockchain y pasar a tratarse de acceder y asegurar una red financiera real.
Pero esa sigue siendo una suposición.
La prueba real es si el uso significativo eventualmente crea suficiente actividad onchain para que la utilidad de DUSK importe económicamente.
Esa es la parte que estoy observando.
No solo lo que $DUSK vale hoy, sino lo necesario que se vuelve si Dusk realmente llega a utilizarse.
@Dusk_Foundation #dusk
Al principio miré $DUSK como miraría la mayoría de tokens de nivel L1: oferta, liquidez, rendimiento por staking y demanda del mercado.
Pero cuanto más estudiaba Dusk, más me daba cuenta de que el token tiene un papel mucho más práctico dentro de la red.
DUSK se utiliza para las comisiones de transacción y el staking. Cada transacción consume gas, mientras que hacer staking de DUSK permite que los proveedores de nodos participen en el consenso y obtengan recompensas del protocolo.
Eso genera una suposición con la que no me siento del todo cómodo:
Si Dusk crece, ¿la demanda de tokens crece realmente con ello?
Depende de qué tipo de actividad crezca.
Más aplicaciones podrían significar más transacciones y, por lo tanto, más uso de gas. Más actividad financiera también podría aumentar la importancia de validadores confiables que aseguren la red.
Pero hay otro lado.
Dusk actualmente tiene una oferta inicial de 500 millones de DUSK, con otros 500 millones programados para emitirse durante 36 años como incentivos de staking.
Así que no creo que tenga sentido analizar la economía de DUSK solo a través de la oferta.
Me interesa más la relación entre la actividad de la red → consumo de gas → staking → seguridad → demanda de tokens.
Si Dusk se convierte en infraestructura para activos regulados, transacciones privadas y aplicaciones financieras, entonces DUSK podría, gradualmente, dejar de tratarse simplemente de mantener un token de blockchain y pasar a tratarse de acceder y asegurar una red financiera real.
Pero esa sigue siendo una suposición.
La prueba real es si el uso significativo eventualmente crea suficiente actividad onchain para que la utilidad de DUSK importe económicamente.
Esa es la parte que estoy observando.
No solo lo que $DUSK vale hoy, sino lo necesario que se vuelve si Dusk realmente llega a utilizarse.
@Dusk #dusk
Pero cuanto más estudiaba Dusk, más me daba cuenta de que el token tiene un papel mucho más práctico dentro de la red.
DUSK se utiliza para las comisiones de transacción y el staking. Cada transacción consume gas, mientras que hacer staking de DUSK permite que los proveedores de nodos participen en el consenso y obtengan recompensas del protocolo.
Eso genera una suposición con la que no me siento del todo cómodo:
Si Dusk crece, ¿la demanda de tokens crece realmente con ello?
Depende de qué tipo de actividad crezca.
Más aplicaciones podrían significar más transacciones y, por lo tanto, más uso de gas. Más actividad financiera también podría aumentar la importancia de validadores confiables que aseguren la red.
Pero hay otro lado.
Dusk actualmente tiene una oferta inicial de 500 millones de DUSK, con otros 500 millones programados para emitirse durante 36 años como incentivos de staking.
Así que no creo que tenga sentido analizar la economía de DUSK solo a través de la oferta.
Me interesa más la relación entre la actividad de la red → consumo de gas → staking → seguridad → demanda de tokens.
Si Dusk se convierte en infraestructura para activos regulados, transacciones privadas y aplicaciones financieras, entonces DUSK podría, gradualmente, dejar de tratarse simplemente de mantener un token de blockchain y pasar a tratarse de acceder y asegurar una red financiera real.
Pero esa sigue siendo una suposición.
La prueba real es si el uso significativo eventualmente crea suficiente actividad onchain para que la utilidad de DUSK importe económicamente.
Esa es la parte que estoy observando.
No solo lo que $DUSK vale hoy, sino lo necesario que se vuelve si Dusk realmente llega a utilizarse.
@Dusk #dusk
1
1
101
·
--
Solía asumir que, cuando una blockchain habla de una finalización rápida, el beneficio principal es algo simple: las transacciones se sienten más rápidas.
Cuanto más observo Dusk, más pienso que eso no capta el punto más importante.
La arquitectura de Dusk se basa en el asentamiento determinista mediante DuskDS y su mecanismo de consenso de Atestación Sucinta. Una vez que un bloque se finaliza, la red trata ese estado como definitivo, en lugar de dejar que los usuarios tengan que lidiar con la incertidumbre habitual asociada a reorganizaciones.
Así que empecé a hacer una pregunta diferente:
¿Qué cambia realmente la finalidad determinista en los flujos de trabajo financieros?
Mi suposición era que mejoraría sobre todo la experiencia de usuario.
Pero si miro los activos tokenizados, las consecuencias parecen ser más interesantes.
Una transacción regulada no es solo “enviar el token A desde la billetera X a la billetera Y”. Puede haber una etapa de activo, una etapa de pago, requisitos de elegibilidad, restricciones de transferencia y condiciones de liquidación. El diseño de infraestructura de mercado de Dusk conecta específicamente la finalidad determinista con estos flujos, incluyendo la entrega contra pago.
Eso cambia cómo interpreto la velocidad.
El valor quizá no sea ahorrar unos segundos al transferir un activo.
El valor podría estar en reducir la incertidumbre entre la ejecución de la operación y la liquidación real.
Y eso importa aún más cuando el activo que se transfiere representa algo como una seguridad regulada, un fondo u otro instrumento financiero.
Todavía soy cauto al asumir que una mejor liquidación crea automáticamente adopción. La infraestructura puede ser técnicamente elegante sin convertirse en algo comercialmente importante.
Pero mi hipótesis de trabajo ha cambiado:
La finalidad de Dusk no es interesante porque sea rápida. Es interesante si esa finalidad hace que los flujos de trabajo financieros sea más fácil coordinarlos onchain.
Esa es la parte que quiero vigilar.
@Dusk_Foundation #dusk $DUSK
Solía asumir que, cuando una blockchain habla de una finalización rápida, el beneficio principal es algo simple: las transacciones se sienten más rápidas.
Cuanto más observo Dusk, más pienso que eso no capta el punto más importante.
La arquitectura de Dusk se basa en el asentamiento determinista mediante DuskDS y su mecanismo de consenso de Atestación Sucinta. Una vez que un bloque se finaliza, la red trata ese estado como definitivo, en lugar de dejar que los usuarios tengan que lidiar con la incertidumbre habitual asociada a reorganizaciones.
Así que empecé a hacer una pregunta diferente:
¿Qué cambia realmente la finalidad determinista en los flujos de trabajo financieros?
Mi suposición era que mejoraría sobre todo la experiencia de usuario.
Pero si miro los activos tokenizados, las consecuencias parecen ser más interesantes.
Una transacción regulada no es solo “enviar el token A desde la billetera X a la billetera Y”. Puede haber una etapa de activo, una etapa de pago, requisitos de elegibilidad, restricciones de transferencia y condiciones de liquidación. El diseño de infraestructura de mercado de Dusk conecta específicamente la finalidad determinista con estos flujos, incluyendo la entrega contra pago.
Eso cambia cómo interpreto la velocidad.
El valor quizá no sea ahorrar unos segundos al transferir un activo.
El valor podría estar en reducir la incertidumbre entre la ejecución de la operación y la liquidación real.
Y eso importa aún más cuando el activo que se transfiere representa algo como una seguridad regulada, un fondo u otro instrumento financiero.
Todavía soy cauto al asumir que una mejor liquidación crea automáticamente adopción. La infraestructura puede ser técnicamente elegante sin convertirse en algo comercialmente importante.
Pero mi hipótesis de trabajo ha cambiado:
La finalidad de Dusk no es interesante porque sea rápida. Es interesante si esa finalidad hace que los flujos de trabajo financieros sea más fácil coordinarlos onchain.
Esa es la parte que quiero vigilar.
@Dusk #dusk $DUSK
Cuanto más observo Dusk, más pienso que eso no capta el punto más importante.
La arquitectura de Dusk se basa en el asentamiento determinista mediante DuskDS y su mecanismo de consenso de Atestación Sucinta. Una vez que un bloque se finaliza, la red trata ese estado como definitivo, en lugar de dejar que los usuarios tengan que lidiar con la incertidumbre habitual asociada a reorganizaciones.
Así que empecé a hacer una pregunta diferente:
¿Qué cambia realmente la finalidad determinista en los flujos de trabajo financieros?
Mi suposición era que mejoraría sobre todo la experiencia de usuario.
Pero si miro los activos tokenizados, las consecuencias parecen ser más interesantes.
Una transacción regulada no es solo “enviar el token A desde la billetera X a la billetera Y”. Puede haber una etapa de activo, una etapa de pago, requisitos de elegibilidad, restricciones de transferencia y condiciones de liquidación. El diseño de infraestructura de mercado de Dusk conecta específicamente la finalidad determinista con estos flujos, incluyendo la entrega contra pago.
Eso cambia cómo interpreto la velocidad.
El valor quizá no sea ahorrar unos segundos al transferir un activo.
El valor podría estar en reducir la incertidumbre entre la ejecución de la operación y la liquidación real.
Y eso importa aún más cuando el activo que se transfiere representa algo como una seguridad regulada, un fondo u otro instrumento financiero.
Todavía soy cauto al asumir que una mejor liquidación crea automáticamente adopción. La infraestructura puede ser técnicamente elegante sin convertirse en algo comercialmente importante.
Pero mi hipótesis de trabajo ha cambiado:
La finalidad de Dusk no es interesante porque sea rápida. Es interesante si esa finalidad hace que los flujos de trabajo financieros sea más fácil coordinarlos onchain.
Esa es la parte que quiero vigilar.
@Dusk #dusk $DUSK
1
113
·
--
Al principio, esto me pareció una complicación innecesaria.
Si Dusk ya ofrece un entorno EVM con Solidity, carteras y herramientas familiares como Hardhat y Foundry, ¿por qué alguien elegiría un entorno nativo de ejecución separado?
La respuesta se vuelve más clara cuando observas para qué están diseñados realmente los dos caminos.
DuskEVM está construido para la compatibilidad. Ofrece a los desarrolladores un entorno familiar estilo Ethereum, pero utilizando DuskDS por debajo para la liquidación y la disponibilidad de datos. Eso tiene sentido para DeFi, aplicaciones de activos tokenizados y proyectos que desean infraestructura EVM existente.
DuskVM está resolviendo un problema diferente.
Ejecuta contratos Rust/WASM directamente en la Dusk L1 y está pensado para aplicaciones que necesitan un acceso más profundo a los activos nativos, los modelos de transacción de Dusk, funciones de privacidad o capacidades de conocimiento cero.
Eso crea un intercambio interesante.
DuskEVM reduce la barrera de entrada.
DuskVM aumenta el acceso al protocolo subyacente.
Así que no creo que la pregunta sea realmente “¿Cuál es mejor?”.
Se trata más bien de qué intenta optimizar la aplicación.
Si la prioridad es la compatibilidad, EVM tiene un sentido evidente. Pero si la aplicación necesita funcionalidades que se sitúan cerca de la privacidad de Dusk y de los primitivos de la L1, agregar otra capa de abstracción quizá no sea deseable.
Eso es lo que me parece interesante de la arquitectura de Dusk.
No está obligando a cada desarrollador a un único modelo de ejecución. Está separando la compatibilidad de la capacidad nativa, manteniendo ambas conectadas a la misma base de liquidación.
La prueba real ahora es si los desarrolladores encuentran esa elección lo bastante valiosa como para usarla.
Porque la arquitectura solo se convierte en una ventaja cuando los creadores pueden notar la diferencia.
@Dusk_Foundation #dusk $DUSK
Al principio, esto me pareció una complicación innecesaria.
Si Dusk ya ofrece un entorno EVM con Solidity, carteras y herramientas familiares como Hardhat y Foundry, ¿por qué alguien elegiría un entorno nativo de ejecución separado?
La respuesta se vuelve más clara cuando observas para qué están diseñados realmente los dos caminos.
DuskEVM está construido para la compatibilidad. Ofrece a los desarrolladores un entorno familiar estilo Ethereum, pero utilizando DuskDS por debajo para la liquidación y la disponibilidad de datos. Eso tiene sentido para DeFi, aplicaciones de activos tokenizados y proyectos que desean infraestructura EVM existente.
DuskVM está resolviendo un problema diferente.
Ejecuta contratos Rust/WASM directamente en la Dusk L1 y está pensado para aplicaciones que necesitan un acceso más profundo a los activos nativos, los modelos de transacción de Dusk, funciones de privacidad o capacidades de conocimiento cero.
Eso crea un intercambio interesante.
DuskEVM reduce la barrera de entrada.
DuskVM aumenta el acceso al protocolo subyacente.
Así que no creo que la pregunta sea realmente “¿Cuál es mejor?”.
Se trata más bien de qué intenta optimizar la aplicación.
Si la prioridad es la compatibilidad, EVM tiene un sentido evidente. Pero si la aplicación necesita funcionalidades que se sitúan cerca de la privacidad de Dusk y de los primitivos de la L1, agregar otra capa de abstracción quizá no sea deseable.
Eso es lo que me parece interesante de la arquitectura de Dusk.
No está obligando a cada desarrollador a un único modelo de ejecución. Está separando la compatibilidad de la capacidad nativa, manteniendo ambas conectadas a la misma base de liquidación.
La prueba real ahora es si los desarrolladores encuentran esa elección lo bastante valiosa como para usarla.
Porque la arquitectura solo se convierte en una ventaja cuando los creadores pueden notar la diferencia.
@Dusk #dusk $DUSK
Si Dusk ya ofrece un entorno EVM con Solidity, carteras y herramientas familiares como Hardhat y Foundry, ¿por qué alguien elegiría un entorno nativo de ejecución separado?
La respuesta se vuelve más clara cuando observas para qué están diseñados realmente los dos caminos.
DuskEVM está construido para la compatibilidad. Ofrece a los desarrolladores un entorno familiar estilo Ethereum, pero utilizando DuskDS por debajo para la liquidación y la disponibilidad de datos. Eso tiene sentido para DeFi, aplicaciones de activos tokenizados y proyectos que desean infraestructura EVM existente.
DuskVM está resolviendo un problema diferente.
Ejecuta contratos Rust/WASM directamente en la Dusk L1 y está pensado para aplicaciones que necesitan un acceso más profundo a los activos nativos, los modelos de transacción de Dusk, funciones de privacidad o capacidades de conocimiento cero.
Eso crea un intercambio interesante.
DuskEVM reduce la barrera de entrada.
DuskVM aumenta el acceso al protocolo subyacente.
Así que no creo que la pregunta sea realmente “¿Cuál es mejor?”.
Se trata más bien de qué intenta optimizar la aplicación.
Si la prioridad es la compatibilidad, EVM tiene un sentido evidente. Pero si la aplicación necesita funcionalidades que se sitúan cerca de la privacidad de Dusk y de los primitivos de la L1, agregar otra capa de abstracción quizá no sea deseable.
Eso es lo que me parece interesante de la arquitectura de Dusk.
No está obligando a cada desarrollador a un único modelo de ejecución. Está separando la compatibilidad de la capacidad nativa, manteniendo ambas conectadas a la misma base de liquidación.
La prueba real ahora es si los desarrolladores encuentran esa elección lo bastante valiosa como para usarla.
Porque la arquitectura solo se convierte en una ventaja cuando los creadores pueden notar la diferencia.
@Dusk #dusk $DUSK
1
88
·
--
Al principio, esto me pareció una complicación innecesaria.
Si Dusk ya ofrece un entorno EVM con Solidity, carteras y herramientas conocidas como Hardhat y Foundry, ¿por qué alguien elegiría un entorno de ejecución nativo por separado?
La respuesta se aclara cuando observas para qué están diseñados realmente ambos caminos.
DuskEVM se construye para la compatibilidad. Ofrece a los desarrolladores un entorno familiar de estilo Ethereum mientras utiliza DuskDS por debajo para la liquidación y la disponibilidad de datos. Eso tiene sentido para DeFi, aplicaciones de activos tokenizados y proyectos que quieren la infraestructura EVM existente.
DuskVM está resolviendo un problema diferente.
Ejecuta contratos Rust/WASM directamente en la Dusk L1 y está pensado para aplicaciones que necesitan un acceso más profundo a activos nativos, a los modelos de transacción de Dusk, a capacidades de privacidad o de cero-conocimiento.
Eso crea un interesante equilibrio.
DuskEVM reduce la barrera de entrada.
DuskVM aumenta el acceso al protocolo subyacente.
Así que no creo que la pregunta sea realmente “¿Cuál es mejor?”
Se trata más bien de qué está intentando optimizar la aplicación.
Si la prioridad es la compatibilidad, EVM tiene un sentido evidente. Pero si la aplicación necesita funcionalidades que se sitúan cerca de la privacidad y los primitivas de L1 de Dusk, añadir otra capa de abstracción quizá no sea lo más deseable.
Eso es lo que me resulta interesante de la arquitectura de Dusk.
No obliga a que cada desarrollador se ajuste a un único modelo de ejecución. Separa la compatibilidad de la capacidad nativa, mientras mantiene ambos conectados a la misma base de liquidación.
La prueba real ahora es si los desarrolladores consideran esa elección lo bastante valiosa como para usarla.
Porque la arquitectura solo se convierte en una ventaja cuando los creadores pueden notar la diferencia.
@Dusk_Foundation #dusk $DUSK
Al principio, esto me pareció una complicación innecesaria.
Si Dusk ya ofrece un entorno EVM con Solidity, carteras y herramientas conocidas como Hardhat y Foundry, ¿por qué alguien elegiría un entorno de ejecución nativo por separado?
La respuesta se aclara cuando observas para qué están diseñados realmente ambos caminos.
DuskEVM se construye para la compatibilidad. Ofrece a los desarrolladores un entorno familiar de estilo Ethereum mientras utiliza DuskDS por debajo para la liquidación y la disponibilidad de datos. Eso tiene sentido para DeFi, aplicaciones de activos tokenizados y proyectos que quieren la infraestructura EVM existente.
DuskVM está resolviendo un problema diferente.
Ejecuta contratos Rust/WASM directamente en la Dusk L1 y está pensado para aplicaciones que necesitan un acceso más profundo a activos nativos, a los modelos de transacción de Dusk, a capacidades de privacidad o de cero-conocimiento.
Eso crea un interesante equilibrio.
DuskEVM reduce la barrera de entrada.
DuskVM aumenta el acceso al protocolo subyacente.
Así que no creo que la pregunta sea realmente “¿Cuál es mejor?”
Se trata más bien de qué está intentando optimizar la aplicación.
Si la prioridad es la compatibilidad, EVM tiene un sentido evidente. Pero si la aplicación necesita funcionalidades que se sitúan cerca de la privacidad y los primitivas de L1 de Dusk, añadir otra capa de abstracción quizá no sea lo más deseable.
Eso es lo que me resulta interesante de la arquitectura de Dusk.
No obliga a que cada desarrollador se ajuste a un único modelo de ejecución. Separa la compatibilidad de la capacidad nativa, mientras mantiene ambos conectados a la misma base de liquidación.
La prueba real ahora es si los desarrolladores consideran esa elección lo bastante valiosa como para usarla.
Porque la arquitectura solo se convierte en una ventaja cuando los creadores pueden notar la diferencia.
@Dusk #dusk $DUSK
Si Dusk ya ofrece un entorno EVM con Solidity, carteras y herramientas conocidas como Hardhat y Foundry, ¿por qué alguien elegiría un entorno de ejecución nativo por separado?
La respuesta se aclara cuando observas para qué están diseñados realmente ambos caminos.
DuskEVM se construye para la compatibilidad. Ofrece a los desarrolladores un entorno familiar de estilo Ethereum mientras utiliza DuskDS por debajo para la liquidación y la disponibilidad de datos. Eso tiene sentido para DeFi, aplicaciones de activos tokenizados y proyectos que quieren la infraestructura EVM existente.
DuskVM está resolviendo un problema diferente.
Ejecuta contratos Rust/WASM directamente en la Dusk L1 y está pensado para aplicaciones que necesitan un acceso más profundo a activos nativos, a los modelos de transacción de Dusk, a capacidades de privacidad o de cero-conocimiento.
Eso crea un interesante equilibrio.
DuskEVM reduce la barrera de entrada.
DuskVM aumenta el acceso al protocolo subyacente.
Así que no creo que la pregunta sea realmente “¿Cuál es mejor?”
Se trata más bien de qué está intentando optimizar la aplicación.
Si la prioridad es la compatibilidad, EVM tiene un sentido evidente. Pero si la aplicación necesita funcionalidades que se sitúan cerca de la privacidad y los primitivas de L1 de Dusk, añadir otra capa de abstracción quizá no sea lo más deseable.
Eso es lo que me resulta interesante de la arquitectura de Dusk.
No obliga a que cada desarrollador se ajuste a un único modelo de ejecución. Separa la compatibilidad de la capacidad nativa, mientras mantiene ambos conectados a la misma base de liquidación.
La prueba real ahora es si los desarrolladores consideran esa elección lo bastante valiosa como para usarla.
Porque la arquitectura solo se convierte en una ventaja cuando los creadores pueden notar la diferencia.
@Dusk #dusk $DUSK
91
·
--
Al principio miré la arquitectura de Dusk desde el lado de la ejecución.
Eso me pareció natural. Los smart contracts son donde viven las aplicaciones, así que asumí que esa era la historia principal.
Luego miré con más detenimiento a DuskDS.
Dusk separa su base de liquidación y disponibilidad de datos de sus entornos de ejecución. DuskDS se encarga del consenso, la finalidad, la disponibilidad de datos y los modelos de transacciones de la red, mientras que DuskVM y DuskEVM ofrecen distintas formas para que las aplicaciones ejecuten la lógica.
Esa separación cambia la manera en que pienso sobre el diseño.
En lugar de preguntar: “¿Qué entorno de ejecución es mejor?”, creo que la pregunta más útil es: ¿qué responsabilidades deben realmente acoplarse?
DuskEVM le da a los desarrolladores Solidity, herramientas EVM familiares e infraestructura compatible con Ethereum. DuskVM toma una ruta diferente, permitiendo que contratos en Rust/WASM se ejecuten directamente en el Dusk L1 cuando las aplicaciones necesitan un acceso más profundo a activos nativos, privacidad o capacidades de conocimiento cero.
Mientras tanto, DuskDS permanece debajo de todo como la capa de liquidación.
Para aplicaciones financieras reguladas, esa distinción podría importar más de lo que inicialmente parece.
Un activo tokenizado puede necesitar un entorno para la lógica de la aplicación, otro conjunto de primitivas para la privacidad y una liquidación determinista por debajo de todo. Dusk, en esencia, está intentando separar esos trabajos en lugar de forzar que cada aplicación se ajuste a un único modelo de ejecución.
Lo interesante no es simplemente que Dusk sea modular.
Es si esa modularidad permite que las aplicaciones financieras elijan el entorno de ejecución que realmente necesitan sin sacrificar una base común de liquidación.
Ese es el intercambio arquitectónico que ahora estoy observando con más atención.
@Dusk_Foundation #dusk $DUSK
Al principio miré la arquitectura de Dusk desde el lado de la ejecución.
Eso me pareció natural. Los smart contracts son donde viven las aplicaciones, así que asumí que esa era la historia principal.
Luego miré con más detenimiento a DuskDS.
Dusk separa su base de liquidación y disponibilidad de datos de sus entornos de ejecución. DuskDS se encarga del consenso, la finalidad, la disponibilidad de datos y los modelos de transacciones de la red, mientras que DuskVM y DuskEVM ofrecen distintas formas para que las aplicaciones ejecuten la lógica.
Esa separación cambia la manera en que pienso sobre el diseño.
En lugar de preguntar: “¿Qué entorno de ejecución es mejor?”, creo que la pregunta más útil es: ¿qué responsabilidades deben realmente acoplarse?
DuskEVM le da a los desarrolladores Solidity, herramientas EVM familiares e infraestructura compatible con Ethereum. DuskVM toma una ruta diferente, permitiendo que contratos en Rust/WASM se ejecuten directamente en el Dusk L1 cuando las aplicaciones necesitan un acceso más profundo a activos nativos, privacidad o capacidades de conocimiento cero.
Mientras tanto, DuskDS permanece debajo de todo como la capa de liquidación.
Para aplicaciones financieras reguladas, esa distinción podría importar más de lo que inicialmente parece.
Un activo tokenizado puede necesitar un entorno para la lógica de la aplicación, otro conjunto de primitivas para la privacidad y una liquidación determinista por debajo de todo. Dusk, en esencia, está intentando separar esos trabajos en lugar de forzar que cada aplicación se ajuste a un único modelo de ejecución.
Lo interesante no es simplemente que Dusk sea modular.
Es si esa modularidad permite que las aplicaciones financieras elijan el entorno de ejecución que realmente necesitan sin sacrificar una base común de liquidación.
Ese es el intercambio arquitectónico que ahora estoy observando con más atención.
@Dusk #dusk $DUSK
Eso me pareció natural. Los smart contracts son donde viven las aplicaciones, así que asumí que esa era la historia principal.
Luego miré con más detenimiento a DuskDS.
Dusk separa su base de liquidación y disponibilidad de datos de sus entornos de ejecución. DuskDS se encarga del consenso, la finalidad, la disponibilidad de datos y los modelos de transacciones de la red, mientras que DuskVM y DuskEVM ofrecen distintas formas para que las aplicaciones ejecuten la lógica.
Esa separación cambia la manera en que pienso sobre el diseño.
En lugar de preguntar: “¿Qué entorno de ejecución es mejor?”, creo que la pregunta más útil es: ¿qué responsabilidades deben realmente acoplarse?
DuskEVM le da a los desarrolladores Solidity, herramientas EVM familiares e infraestructura compatible con Ethereum. DuskVM toma una ruta diferente, permitiendo que contratos en Rust/WASM se ejecuten directamente en el Dusk L1 cuando las aplicaciones necesitan un acceso más profundo a activos nativos, privacidad o capacidades de conocimiento cero.
Mientras tanto, DuskDS permanece debajo de todo como la capa de liquidación.
Para aplicaciones financieras reguladas, esa distinción podría importar más de lo que inicialmente parece.
Un activo tokenizado puede necesitar un entorno para la lógica de la aplicación, otro conjunto de primitivas para la privacidad y una liquidación determinista por debajo de todo. Dusk, en esencia, está intentando separar esos trabajos en lugar de forzar que cada aplicación se ajuste a un único modelo de ejecución.
Lo interesante no es simplemente que Dusk sea modular.
Es si esa modularidad permite que las aplicaciones financieras elijan el entorno de ejecución que realmente necesitan sin sacrificar una base común de liquidación.
Ese es el intercambio arquitectónico que ahora estoy observando con más atención.
@Dusk #dusk $DUSK
3
2
150
·
--
Solía pensar que la tokenización consistía principalmente en tomar un activo financiero existente y ponerle un token encima.
A medida que miraba más a fondo Dusk Trade, esa definición se me fue quedando corta.
Dusk Trade se presenta como la capa de aplicación para activos financieros tokenizados, pero el flujo de trabajo va mucho más allá de crear y transferir un token. Incluye descubrimiento del activo, incorporación de inversores, conexión de billeteras, elegibilidad, operaciones, coordinación de pagos y liquidación.
Esa distinción importa.
Un token puede existir en la cadena (onchain) mientras que las partes importantes del proceso financiero permanecen en algún otro lugar. La propia documentación de Dusk separa la tokenización ordinaria de la emisión nativa, donde la emisión, las transferencias, la gestión y la liquidación pueden diseñarse en torno al libro contable en sí.
Esa es la parte que me resulta más interesante.
Si un inversor todavía tiene que moverse entre sistemas separados para identidad, elegibilidad, custodia, operaciones y liquidación, entonces el hecho de poner el activo en la cadena (onchain) no necesariamente ha cambiado la estructura del mercado. Puede que solo haya digitalizado un componente.
Dusk está intentando abordar el problema de forma distinta: conectar esas piezas usando la misma infraestructura, manteniendo la información sensible en privado y permitiendo revelar información específica cuando sea necesario.
Así que mi pregunta no es simplemente si Dusk puede tokenizar valores.
Es si una cadena de bloques puede absorber realmente lo suficiente del flujo de trabajo financiero que la rodea como para que la tokenización sea de verdad algo distinto a los sistemas que se supone que debe mejorar.
Eso parece una prueba más difícil.
Y probablemente la más importante.
@Dusk_Foundation #dusk $DUSK
Solía pensar que la tokenización consistía principalmente en tomar un activo financiero existente y ponerle un token encima.
A medida que miraba más a fondo Dusk Trade, esa definición se me fue quedando corta.
Dusk Trade se presenta como la capa de aplicación para activos financieros tokenizados, pero el flujo de trabajo va mucho más allá de crear y transferir un token. Incluye descubrimiento del activo, incorporación de inversores, conexión de billeteras, elegibilidad, operaciones, coordinación de pagos y liquidación.
Esa distinción importa.
Un token puede existir en la cadena (onchain) mientras que las partes importantes del proceso financiero permanecen en algún otro lugar. La propia documentación de Dusk separa la tokenización ordinaria de la emisión nativa, donde la emisión, las transferencias, la gestión y la liquidación pueden diseñarse en torno al libro contable en sí.
Esa es la parte que me resulta más interesante.
Si un inversor todavía tiene que moverse entre sistemas separados para identidad, elegibilidad, custodia, operaciones y liquidación, entonces el hecho de poner el activo en la cadena (onchain) no necesariamente ha cambiado la estructura del mercado. Puede que solo haya digitalizado un componente.
Dusk está intentando abordar el problema de forma distinta: conectar esas piezas usando la misma infraestructura, manteniendo la información sensible en privado y permitiendo revelar información específica cuando sea necesario.
Así que mi pregunta no es simplemente si Dusk puede tokenizar valores.
Es si una cadena de bloques puede absorber realmente lo suficiente del flujo de trabajo financiero que la rodea como para que la tokenización sea de verdad algo distinto a los sistemas que se supone que debe mejorar.
Eso parece una prueba más difícil.
Y probablemente la más importante.
@Dusk #dusk $DUSK
A medida que miraba más a fondo Dusk Trade, esa definición se me fue quedando corta.
Dusk Trade se presenta como la capa de aplicación para activos financieros tokenizados, pero el flujo de trabajo va mucho más allá de crear y transferir un token. Incluye descubrimiento del activo, incorporación de inversores, conexión de billeteras, elegibilidad, operaciones, coordinación de pagos y liquidación.
Esa distinción importa.
Un token puede existir en la cadena (onchain) mientras que las partes importantes del proceso financiero permanecen en algún otro lugar. La propia documentación de Dusk separa la tokenización ordinaria de la emisión nativa, donde la emisión, las transferencias, la gestión y la liquidación pueden diseñarse en torno al libro contable en sí.
Esa es la parte que me resulta más interesante.
Si un inversor todavía tiene que moverse entre sistemas separados para identidad, elegibilidad, custodia, operaciones y liquidación, entonces el hecho de poner el activo en la cadena (onchain) no necesariamente ha cambiado la estructura del mercado. Puede que solo haya digitalizado un componente.
Dusk está intentando abordar el problema de forma distinta: conectar esas piezas usando la misma infraestructura, manteniendo la información sensible en privado y permitiendo revelar información específica cuando sea necesario.
Así que mi pregunta no es simplemente si Dusk puede tokenizar valores.
Es si una cadena de bloques puede absorber realmente lo suficiente del flujo de trabajo financiero que la rodea como para que la tokenización sea de verdad algo distinto a los sistemas que se supone que debe mejorar.
Eso parece una prueba más difícil.
Y probablemente la más importante.
@Dusk #dusk $DUSK
1
88
·
--
👀 Hoy me adentré un poco más en Zedger y creo que al principio estaba mirando la cosa equivocada.
Mi primera impresión fue básicamente: ok, @Dusk_Foundation está poniendo valores regulados en cadena. Entendido.
Pero Zedger se vuelve más interesante cuando miras más allá del propio token.
Está construido en torno a activos regulados y admite cosas como la emisión (minting), la destrucción (burning) y las acciones corporativas. En otras palabras, la cadena no necesariamente solo actúa como un recibo digital de un activo que vive en otro lugar.
Gran parte del ciclo de vida real puede gestionarse como parte de la infraestructura.
Y eso cambia la forma en que pienso sobre los valores tokenizados.
Un valor no es solo un saldo que está sentado en una cartera. La propiedad puede cambiar. Se pueden aplicar reglas. Pueden ocurrir eventos corporativos. El activo puede crearse, modificarse, redimirse o eliminarse.
Si algunos de esos procesos pueden ocurrir directamente dentro de la infraestructura, potencialmente hay menos separación entre “el activo” y “el sistema que gestiona el activo”.
Esa es la parte que me resulta realmente interesante de Zedger.
Pero también hay un matiz.
Cuanta más lógica financiera lleves a la cadena, más complejidad del mundo real tiene que manejar correctamente el protocolo.
Ya no solo estás moviendo tokens. Estás intentando representar reglas legales y financieras en un sistema que tiene que comportarse de manera predecible.
Así que me queda una pregunta más que una conclusión:
¿Poner más del ciclo de vida de un valor en cadena en realidad hace que la infraestructura financiera sea más simple… o solo estamos moviendo más complejidad a la blockchain?
Esa es la parte de Zedger en la que todavía estoy pensando.
#dusk $DUSK
👀 Hoy me adentré un poco más en Zedger y creo que al principio estaba mirando la cosa equivocada.
Mi primera impresión fue básicamente: ok, @Dusk está poniendo valores regulados en cadena. Entendido.
Pero Zedger se vuelve más interesante cuando miras más allá del propio token.
Está construido en torno a activos regulados y admite cosas como la emisión (minting), la destrucción (burning) y las acciones corporativas. En otras palabras, la cadena no necesariamente solo actúa como un recibo digital de un activo que vive en otro lugar.
Gran parte del ciclo de vida real puede gestionarse como parte de la infraestructura.
Y eso cambia la forma en que pienso sobre los valores tokenizados.
Un valor no es solo un saldo que está sentado en una cartera. La propiedad puede cambiar. Se pueden aplicar reglas. Pueden ocurrir eventos corporativos. El activo puede crearse, modificarse, redimirse o eliminarse.
Si algunos de esos procesos pueden ocurrir directamente dentro de la infraestructura, potencialmente hay menos separación entre “el activo” y “el sistema que gestiona el activo”.
Esa es la parte que me resulta realmente interesante de Zedger.
Pero también hay un matiz.
Cuanta más lógica financiera lleves a la cadena, más complejidad del mundo real tiene que manejar correctamente el protocolo.
Ya no solo estás moviendo tokens. Estás intentando representar reglas legales y financieras en un sistema que tiene que comportarse de manera predecible.
Así que me queda una pregunta más que una conclusión:
¿Poner más del ciclo de vida de un valor en cadena en realidad hace que la infraestructura financiera sea más simple… o solo estamos moviendo más complejidad a la blockchain?
Esa es la parte de Zedger en la que todavía estoy pensando.
#dusk $DUSK
Mi primera impresión fue básicamente: ok, @Dusk está poniendo valores regulados en cadena. Entendido.
Pero Zedger se vuelve más interesante cuando miras más allá del propio token.
Está construido en torno a activos regulados y admite cosas como la emisión (minting), la destrucción (burning) y las acciones corporativas. En otras palabras, la cadena no necesariamente solo actúa como un recibo digital de un activo que vive en otro lugar.
Gran parte del ciclo de vida real puede gestionarse como parte de la infraestructura.
Y eso cambia la forma en que pienso sobre los valores tokenizados.
Un valor no es solo un saldo que está sentado en una cartera. La propiedad puede cambiar. Se pueden aplicar reglas. Pueden ocurrir eventos corporativos. El activo puede crearse, modificarse, redimirse o eliminarse.
Si algunos de esos procesos pueden ocurrir directamente dentro de la infraestructura, potencialmente hay menos separación entre “el activo” y “el sistema que gestiona el activo”.
Esa es la parte que me resulta realmente interesante de Zedger.
Pero también hay un matiz.
Cuanta más lógica financiera lleves a la cadena, más complejidad del mundo real tiene que manejar correctamente el protocolo.
Ya no solo estás moviendo tokens. Estás intentando representar reglas legales y financieras en un sistema que tiene que comportarse de manera predecible.
Así que me queda una pregunta más que una conclusión:
¿Poner más del ciclo de vida de un valor en cadena en realidad hace que la infraestructura financiera sea más simple… o solo estamos moviendo más complejidad a la blockchain?
Esa es la parte de Zedger en la que todavía estoy pensando.
#dusk $DUSK
2
1
3
83
·
--
Empecé a analizar la tecnología de conocimiento cero de Dusk desde la perspectiva de la privacidad.
Ese era el lugar obvio para empezar.
Si una blockchain puede verificar algo sin exponer toda la información subyacente, parece natural pensar en el conocimiento cero como una forma de mantener privadas las transacciones y los saldos.
Pero cuanto más miraba a Dusk, más interesante se volvía la vertiente de cumplimiento.
Piensa en un activo regulado.
Un inversor podría necesitar demostrar que es elegible para comprarlo. Una transacción podría tener que cumplir ciertas reglas. Una organización podría necesitar demostrar que se cumplieron las condiciones adecuadas.
Pero nada de eso implica necesariamente que todo el mundo deba ver la identidad completa del inversor, su situación financiera o su historial de transacciones.
Esa distinción es donde el enfoque de Dusk llamó mi atención.
Con Citadel proporcionando infraestructura de identidad y Dusk usando mecanismos de conocimiento cero y divulgación selectiva, la posibilidad interesante no es simplemente ocultar información.
Consiste en probar un hecho específico sin exponer todo lo que hay detrás de ese hecho.
No necesariamente necesitas revelar el perfil financiero completo de alguien para demostrar que es elegible.
Necesitas una forma fiable de probar que cumple la condición requerida.
Eso cambia la manera en que pienso sobre el conocimiento cero en Dusk.
Quizá su papel más importante no sea hacer privadas las transacciones de blockchain.
Quizá sea hacer que el cumplimiento sea, en sí mismo, más selectivo.
La pregunta más grande para @Dusk_Foundation es hasta dónde puede llegar realmente este modelo.
¿Pueden los requisitos regulatorios convertirse en cosas que una blockchain verifica de forma criptográfica, mientras la información sensible permanece protegida?
Si eso funciona, privacidad y cumplimiento dejan de parecer requisitos enfrentados.
Empiezan a parecer dos partes de la misma infraestructura.
$DUSK #dusk
Empecé a analizar la tecnología de conocimiento cero de Dusk desde la perspectiva de la privacidad.
Ese era el lugar obvio para empezar.
Si una blockchain puede verificar algo sin exponer toda la información subyacente, parece natural pensar en el conocimiento cero como una forma de mantener privadas las transacciones y los saldos.
Pero cuanto más miraba a Dusk, más interesante se volvía la vertiente de cumplimiento.
Piensa en un activo regulado.
Un inversor podría necesitar demostrar que es elegible para comprarlo. Una transacción podría tener que cumplir ciertas reglas. Una organización podría necesitar demostrar que se cumplieron las condiciones adecuadas.
Pero nada de eso implica necesariamente que todo el mundo deba ver la identidad completa del inversor, su situación financiera o su historial de transacciones.
Esa distinción es donde el enfoque de Dusk llamó mi atención.
Con Citadel proporcionando infraestructura de identidad y Dusk usando mecanismos de conocimiento cero y divulgación selectiva, la posibilidad interesante no es simplemente ocultar información.
Consiste en probar un hecho específico sin exponer todo lo que hay detrás de ese hecho.
No necesariamente necesitas revelar el perfil financiero completo de alguien para demostrar que es elegible.
Necesitas una forma fiable de probar que cumple la condición requerida.
Eso cambia la manera en que pienso sobre el conocimiento cero en Dusk.
Quizá su papel más importante no sea hacer privadas las transacciones de blockchain.
Quizá sea hacer que el cumplimiento sea, en sí mismo, más selectivo.
La pregunta más grande para @Dusk es hasta dónde puede llegar realmente este modelo.
¿Pueden los requisitos regulatorios convertirse en cosas que una blockchain verifica de forma criptográfica, mientras la información sensible permanece protegida?
Si eso funciona, privacidad y cumplimiento dejan de parecer requisitos enfrentados.
Empiezan a parecer dos partes de la misma infraestructura.
$DUSK #dusk
Ese era el lugar obvio para empezar.
Si una blockchain puede verificar algo sin exponer toda la información subyacente, parece natural pensar en el conocimiento cero como una forma de mantener privadas las transacciones y los saldos.
Pero cuanto más miraba a Dusk, más interesante se volvía la vertiente de cumplimiento.
Piensa en un activo regulado.
Un inversor podría necesitar demostrar que es elegible para comprarlo. Una transacción podría tener que cumplir ciertas reglas. Una organización podría necesitar demostrar que se cumplieron las condiciones adecuadas.
Pero nada de eso implica necesariamente que todo el mundo deba ver la identidad completa del inversor, su situación financiera o su historial de transacciones.
Esa distinción es donde el enfoque de Dusk llamó mi atención.
Con Citadel proporcionando infraestructura de identidad y Dusk usando mecanismos de conocimiento cero y divulgación selectiva, la posibilidad interesante no es simplemente ocultar información.
Consiste en probar un hecho específico sin exponer todo lo que hay detrás de ese hecho.
No necesariamente necesitas revelar el perfil financiero completo de alguien para demostrar que es elegible.
Necesitas una forma fiable de probar que cumple la condición requerida.
Eso cambia la manera en que pienso sobre el conocimiento cero en Dusk.
Quizá su papel más importante no sea hacer privadas las transacciones de blockchain.
Quizá sea hacer que el cumplimiento sea, en sí mismo, más selectivo.
La pregunta más grande para @Dusk es hasta dónde puede llegar realmente este modelo.
¿Pueden los requisitos regulatorios convertirse en cosas que una blockchain verifica de forma criptográfica, mientras la información sensible permanece protegida?
Si eso funciona, privacidad y cumplimiento dejan de parecer requisitos enfrentados.
Empiezan a parecer dos partes de la misma infraestructura.
$DUSK #dusk
1
99
·
--
Cuanto más estudio Dusk, menos convincente se vuelve la habitual descripción de “blockchain privada”.
Un sistema de privacidad realmente interesante no puede simplemente hacer que la información desaparezca. Los mercados financieros aún necesitan verificación. Alguien tiene que establecer que una transacción es válida, que un inversor es elegible o que se ha seguido una regla financiera.
Eso crea una tensión que me resulta mucho más interesante que la privacidad por sí sola.
Dusk lo aborda mediante una combinación de transacciones protegidas, pruebas de conocimiento cero y divulgación selectiva.
La idea no necesariamente es exponer la información subyacente. En su lugar, las pruebas criptográficas pueden demostrar que se cumplen ciertas condiciones sin revelar todo lo que hay detrás de la transacción.
Esa distinción importa.
Imagina que una institución necesita demostrar que una transacción siguió las reglas requeridas. En una blockchain completamente transparente, la solución más sencilla suele ser publicar la actividad subyacente y permitir que todos la inspeccionen.
Pero eso crea otro problema: la información financiera sensible queda visible de forma permanente.
El enfoque de Dusk plantea una pregunta diferente:
¿Realmente necesitas revelar los datos o solo necesitas probar algo sobre los datos?
Ahí es donde la tecnología de conocimiento cero se vuelve especialmente interesante para mí.
El objetivo no es “ocultarlo todo”.
Es más bien demostrar lo que debe demostrarse, manteniendo la información innecesaria en privado.
La divulgación selectiva añade otra capa. Cuando una parte autorizada realmente necesita información adicional, la privacidad no significa necesariamente negarse al acceso. Puede significar controlar quién la recibe y en qué circunstancias.
Así que estoy empezando a ver la arquitectura de privacidad de Dusk menos como un intento de escapar de la verificación y más como un intento de separar la verificación de la exposición.
Pero la prueba más grande, sin embargo, es la práctica.
¿Pueden las instituciones operar realmente de esta manera a escala?
Porque demostrar algo sin revelar todo suena elegante en el papel. La historia real comienza cuando los mercados financieros dependen de ello.
@Dusk_Foundation #dusk $DUSK
Cuanto más estudio Dusk, menos convincente se vuelve la habitual descripción de “blockchain privada”.
Un sistema de privacidad realmente interesante no puede simplemente hacer que la información desaparezca. Los mercados financieros aún necesitan verificación. Alguien tiene que establecer que una transacción es válida, que un inversor es elegible o que se ha seguido una regla financiera.
Eso crea una tensión que me resulta mucho más interesante que la privacidad por sí sola.
Dusk lo aborda mediante una combinación de transacciones protegidas, pruebas de conocimiento cero y divulgación selectiva.
La idea no necesariamente es exponer la información subyacente. En su lugar, las pruebas criptográficas pueden demostrar que se cumplen ciertas condiciones sin revelar todo lo que hay detrás de la transacción.
Esa distinción importa.
Imagina que una institución necesita demostrar que una transacción siguió las reglas requeridas. En una blockchain completamente transparente, la solución más sencilla suele ser publicar la actividad subyacente y permitir que todos la inspeccionen.
Pero eso crea otro problema: la información financiera sensible queda visible de forma permanente.
El enfoque de Dusk plantea una pregunta diferente:
¿Realmente necesitas revelar los datos o solo necesitas probar algo sobre los datos?
Ahí es donde la tecnología de conocimiento cero se vuelve especialmente interesante para mí.
El objetivo no es “ocultarlo todo”.
Es más bien demostrar lo que debe demostrarse, manteniendo la información innecesaria en privado.
La divulgación selectiva añade otra capa. Cuando una parte autorizada realmente necesita información adicional, la privacidad no significa necesariamente negarse al acceso. Puede significar controlar quién la recibe y en qué circunstancias.
Así que estoy empezando a ver la arquitectura de privacidad de Dusk menos como un intento de escapar de la verificación y más como un intento de separar la verificación de la exposición.
Pero la prueba más grande, sin embargo, es la práctica.
¿Pueden las instituciones operar realmente de esta manera a escala?
Porque demostrar algo sin revelar todo suena elegante en el papel. La historia real comienza cuando los mercados financieros dependen de ello.
@Dusk #dusk $DUSK
Un sistema de privacidad realmente interesante no puede simplemente hacer que la información desaparezca. Los mercados financieros aún necesitan verificación. Alguien tiene que establecer que una transacción es válida, que un inversor es elegible o que se ha seguido una regla financiera.
Eso crea una tensión que me resulta mucho más interesante que la privacidad por sí sola.
Dusk lo aborda mediante una combinación de transacciones protegidas, pruebas de conocimiento cero y divulgación selectiva.
La idea no necesariamente es exponer la información subyacente. En su lugar, las pruebas criptográficas pueden demostrar que se cumplen ciertas condiciones sin revelar todo lo que hay detrás de la transacción.
Esa distinción importa.
Imagina que una institución necesita demostrar que una transacción siguió las reglas requeridas. En una blockchain completamente transparente, la solución más sencilla suele ser publicar la actividad subyacente y permitir que todos la inspeccionen.
Pero eso crea otro problema: la información financiera sensible queda visible de forma permanente.
El enfoque de Dusk plantea una pregunta diferente:
¿Realmente necesitas revelar los datos o solo necesitas probar algo sobre los datos?
Ahí es donde la tecnología de conocimiento cero se vuelve especialmente interesante para mí.
El objetivo no es “ocultarlo todo”.
Es más bien demostrar lo que debe demostrarse, manteniendo la información innecesaria en privado.
La divulgación selectiva añade otra capa. Cuando una parte autorizada realmente necesita información adicional, la privacidad no significa necesariamente negarse al acceso. Puede significar controlar quién la recibe y en qué circunstancias.
Así que estoy empezando a ver la arquitectura de privacidad de Dusk menos como un intento de escapar de la verificación y más como un intento de separar la verificación de la exposición.
Pero la prueba más grande, sin embargo, es la práctica.
¿Pueden las instituciones operar realmente de esta manera a escala?
Porque demostrar algo sin revelar todo suena elegante en el papel. La historia real comienza cuando los mercados financieros dependen de ello.
@Dusk #dusk $DUSK
3
102
·
--
Al principio miré a Phoenix a través de la lente habitual: transacciones privadas, montos ocultos y menos información expuesta en la cadena.
Esa descripción es técnicamente útil, pero creo que pasa por alto la parte más interesante de Dusk.
Phoenix no se limita a hacer que la actividad financiera desaparezca. La arquitectura está diseñada en torno a transacciones protegidas (shielded), manteniendo al mismo tiempo el acceso autorizado a la información relevante mediante mecanismos de visualización.
Eso cambia la pregunta.
En lugar de preguntar, “¿Qué tan anónima es esta blockchain?”, creo que la mejor pregunta es:
¿Quién debería poder ver qué, y bajo qué condiciones?
Esa es una forma muy diferente de pensar sobre la privacidad.
Para un usuario común, la privacidad podría significar mantener los saldos y el historial de transacciones lejos de los observadores públicos. Pero las instituciones financieras tienen un requisito más complejo. Es posible que necesiten confidencialidad frente al mercado en general, pero que aun así puedan demostrar información a un auditor, regulador, contraparte u otra parte autorizada.
Aquí es donde Phoenix se vuelve para mí más interesante.
Las pruebas de conocimiento cero pueden establecer que una transacción sigue las reglas requeridas sin exponer cada detalle subyacente. Luego, la divulgación selectiva puede crear una vía controlada para revelar información cuando exista una razón legítima para hacerlo.
Así que Dusk no necesariamente está eligiendo entre privacidad y cumplimiento.
Está explorando si pueden coexistir mediante una visibilidad controlada.
Y eso podría ser un modelo mucho más relevante para los mercados financieros regulados que simplemente hacer todo público o todo privado.
Lo que estoy observando ahora es si esta arquitectura realmente cambia la forma en que se comportan las instituciones.
Porque construir privacidad selectiva es un desafío.
Hacer que la actividad financiera real dependa de ello es una prueba mucho más difícil.
@Dusk_Foundation #dusk $DUSK
Al principio miré a Phoenix a través de la lente habitual: transacciones privadas, montos ocultos y menos información expuesta en la cadena.
Esa descripción es técnicamente útil, pero creo que pasa por alto la parte más interesante de Dusk.
Phoenix no se limita a hacer que la actividad financiera desaparezca. La arquitectura está diseñada en torno a transacciones protegidas (shielded), manteniendo al mismo tiempo el acceso autorizado a la información relevante mediante mecanismos de visualización.
Eso cambia la pregunta.
En lugar de preguntar, “¿Qué tan anónima es esta blockchain?”, creo que la mejor pregunta es:
¿Quién debería poder ver qué, y bajo qué condiciones?
Esa es una forma muy diferente de pensar sobre la privacidad.
Para un usuario común, la privacidad podría significar mantener los saldos y el historial de transacciones lejos de los observadores públicos. Pero las instituciones financieras tienen un requisito más complejo. Es posible que necesiten confidencialidad frente al mercado en general, pero que aun así puedan demostrar información a un auditor, regulador, contraparte u otra parte autorizada.
Aquí es donde Phoenix se vuelve para mí más interesante.
Las pruebas de conocimiento cero pueden establecer que una transacción sigue las reglas requeridas sin exponer cada detalle subyacente. Luego, la divulgación selectiva puede crear una vía controlada para revelar información cuando exista una razón legítima para hacerlo.
Así que Dusk no necesariamente está eligiendo entre privacidad y cumplimiento.
Está explorando si pueden coexistir mediante una visibilidad controlada.
Y eso podría ser un modelo mucho más relevante para los mercados financieros regulados que simplemente hacer todo público o todo privado.
Lo que estoy observando ahora es si esta arquitectura realmente cambia la forma en que se comportan las instituciones.
Porque construir privacidad selectiva es un desafío.
Hacer que la actividad financiera real dependa de ello es una prueba mucho más difícil.
@Dusk #dusk $DUSK
Esa descripción es técnicamente útil, pero creo que pasa por alto la parte más interesante de Dusk.
Phoenix no se limita a hacer que la actividad financiera desaparezca. La arquitectura está diseñada en torno a transacciones protegidas (shielded), manteniendo al mismo tiempo el acceso autorizado a la información relevante mediante mecanismos de visualización.
Eso cambia la pregunta.
En lugar de preguntar, “¿Qué tan anónima es esta blockchain?”, creo que la mejor pregunta es:
¿Quién debería poder ver qué, y bajo qué condiciones?
Esa es una forma muy diferente de pensar sobre la privacidad.
Para un usuario común, la privacidad podría significar mantener los saldos y el historial de transacciones lejos de los observadores públicos. Pero las instituciones financieras tienen un requisito más complejo. Es posible que necesiten confidencialidad frente al mercado en general, pero que aun así puedan demostrar información a un auditor, regulador, contraparte u otra parte autorizada.
Aquí es donde Phoenix se vuelve para mí más interesante.
Las pruebas de conocimiento cero pueden establecer que una transacción sigue las reglas requeridas sin exponer cada detalle subyacente. Luego, la divulgación selectiva puede crear una vía controlada para revelar información cuando exista una razón legítima para hacerlo.
Así que Dusk no necesariamente está eligiendo entre privacidad y cumplimiento.
Está explorando si pueden coexistir mediante una visibilidad controlada.
Y eso podría ser un modelo mucho más relevante para los mercados financieros regulados que simplemente hacer todo público o todo privado.
Lo que estoy observando ahora es si esta arquitectura realmente cambia la forma en que se comportan las instituciones.
Porque construir privacidad selectiva es un desafío.
Hacer que la actividad financiera real dependa de ello es una prueba mucho más difícil.
@Dusk #dusk $DUSK
1
2
105
·
--
Cuando miré por primera vez la arquitectura de transacciones de Dusk, esperaba que la historia de la privacidad fuera sencilla: una blockchain diseñada en torno a transacciones confidenciales.
Luego noté algo más interesante.
DuskDS admite dos modelos de transacción diferentes: Moonlight, que utiliza un enfoque transparente basado en cuentas, y Phoenix, que emplea notas protegidas para transferencias confidenciales.
Al principio, tener ambos puede parecer una complejidad innecesaria. Si la privacidad es tan importante en Dusk, ¿por qué no hacerlo todo privado?
Pero cuanto más pienso en los mercados financieros regulados, más este diseño empieza a tener sentido.
No todas las transacciones necesitan el mismo nivel de confidencialidad.
Hay situaciones en las que la actividad transparente es útil. Una transferencia pública puede facilitar la contabilidad, el monitoreo, las operaciones de tesorería o ciertas formas de verificación.
Luego están las transacciones en las que exponer el monto, los participantes o las relaciones financieras crea una filtración de información que una institución simplemente no quiere.
Ahí es donde Phoenix se vuelve más interesante.
En lugar de obligar a toda la red a encajar en un solo modelo de privacidad, Dusk parece estar tratando la visibilidad de las transacciones como algo que puede depender del caso de uso.
Y creo que esa es la idea más grande.
Un activo regulado podría necesitar cumplimiento sin exigir que cada participante del mercado vea cada detalle de la transacción. Una institución podría necesitar demostrar algo a una parte autorizada mientras mantiene la información financiera sensible fuera del mercado en general.
Así que estoy empezando a ver Moonlight y Phoenix menos como sistemas de transacciones rivales y más como dos herramientas diferentes que operan sobre la misma capa de liquidación.
La pregunta real para mí no es si uno es mejor.
Es si tener ambos permite que Dusk atienda aplicaciones financieras que se sitúan en algún punto entre blockchains completamente transparentes y sistemas completamente privados.
Ese punto intermedio podría ser donde realmente vive la parte interesante de la arquitectura de Dusk.
@Dusk_Foundation #dusk $DUSK
Cuando miré por primera vez la arquitectura de transacciones de Dusk, esperaba que la historia de la privacidad fuera sencilla: una blockchain diseñada en torno a transacciones confidenciales.
Luego noté algo más interesante.
DuskDS admite dos modelos de transacción diferentes: Moonlight, que utiliza un enfoque transparente basado en cuentas, y Phoenix, que emplea notas protegidas para transferencias confidenciales.
Al principio, tener ambos puede parecer una complejidad innecesaria. Si la privacidad es tan importante en Dusk, ¿por qué no hacerlo todo privado?
Pero cuanto más pienso en los mercados financieros regulados, más este diseño empieza a tener sentido.
No todas las transacciones necesitan el mismo nivel de confidencialidad.
Hay situaciones en las que la actividad transparente es útil. Una transferencia pública puede facilitar la contabilidad, el monitoreo, las operaciones de tesorería o ciertas formas de verificación.
Luego están las transacciones en las que exponer el monto, los participantes o las relaciones financieras crea una filtración de información que una institución simplemente no quiere.
Ahí es donde Phoenix se vuelve más interesante.
En lugar de obligar a toda la red a encajar en un solo modelo de privacidad, Dusk parece estar tratando la visibilidad de las transacciones como algo que puede depender del caso de uso.
Y creo que esa es la idea más grande.
Un activo regulado podría necesitar cumplimiento sin exigir que cada participante del mercado vea cada detalle de la transacción. Una institución podría necesitar demostrar algo a una parte autorizada mientras mantiene la información financiera sensible fuera del mercado en general.
Así que estoy empezando a ver Moonlight y Phoenix menos como sistemas de transacciones rivales y más como dos herramientas diferentes que operan sobre la misma capa de liquidación.
La pregunta real para mí no es si uno es mejor.
Es si tener ambos permite que Dusk atienda aplicaciones financieras que se sitúan en algún punto entre blockchains completamente transparentes y sistemas completamente privados.
Ese punto intermedio podría ser donde realmente vive la parte interesante de la arquitectura de Dusk.
@Dusk #dusk $DUSK
Luego noté algo más interesante.
DuskDS admite dos modelos de transacción diferentes: Moonlight, que utiliza un enfoque transparente basado en cuentas, y Phoenix, que emplea notas protegidas para transferencias confidenciales.
Al principio, tener ambos puede parecer una complejidad innecesaria. Si la privacidad es tan importante en Dusk, ¿por qué no hacerlo todo privado?
Pero cuanto más pienso en los mercados financieros regulados, más este diseño empieza a tener sentido.
No todas las transacciones necesitan el mismo nivel de confidencialidad.
Hay situaciones en las que la actividad transparente es útil. Una transferencia pública puede facilitar la contabilidad, el monitoreo, las operaciones de tesorería o ciertas formas de verificación.
Luego están las transacciones en las que exponer el monto, los participantes o las relaciones financieras crea una filtración de información que una institución simplemente no quiere.
Ahí es donde Phoenix se vuelve más interesante.
En lugar de obligar a toda la red a encajar en un solo modelo de privacidad, Dusk parece estar tratando la visibilidad de las transacciones como algo que puede depender del caso de uso.
Y creo que esa es la idea más grande.
Un activo regulado podría necesitar cumplimiento sin exigir que cada participante del mercado vea cada detalle de la transacción. Una institución podría necesitar demostrar algo a una parte autorizada mientras mantiene la información financiera sensible fuera del mercado en general.
Así que estoy empezando a ver Moonlight y Phoenix menos como sistemas de transacciones rivales y más como dos herramientas diferentes que operan sobre la misma capa de liquidación.
La pregunta real para mí no es si uno es mejor.
Es si tener ambos permite que Dusk atienda aplicaciones financieras que se sitúan en algún punto entre blockchains completamente transparentes y sistemas completamente privados.
Ese punto intermedio podría ser donde realmente vive la parte interesante de la arquitectura de Dusk.
@Dusk #dusk $DUSK
1
92
·
--
Entré en la documentación de Trustless Bitcoin Vaults (TBV) pensando que el BTC envuelto y el préstamo con garantía de BTC nativo estaban resolviendo el mismo problema con herramientas diferentes.
Después de unas horas de lectura, no creo que partan ni siquiera de la misma suposición.
Wrapped BTC pregunta: "¿Cómo metemos Bitcoin en DeFi?"
TBV parece preguntar: "¿Por qué Bitcoin tiene que convertirse en otra cosa antes de que DeFi pueda usarlo?"
Esa diferencia se me quedó grabada más que el propio flujo de préstamo.
La forma más fácil de pensar en el BTC envuelto es que crea otra versión de Bitcoin con la que las aplicaciones ya saben trabajar. Es práctico, y por eso se convirtió en el estándar. Pero cada capa adicional también trae consigo otro conjunto de supuestos que tiene que seguir funcionando como se espera.
TBV no elimina la complejidad: la desplaza.
En lugar de crear otra representación de Bitcoin, el protocolo intenta mantener el BTC nativo donde ya pertenece mientras demuestra su condición de colateral ante aplicaciones como Aave v4. El reto de ingeniería pasa de crear un activo envuelto a coordinar la verificación entre sistemas distintos.
Esa es una filosofía de diseño diferente.
No estoy diciendo que un enfoque reemplace automáticamente al otro. Wrapped BTC tiene un ecosistema establecido y una liquidez profunda hoy. Pero tras comparar ambos modelos, me di cuenta de que optimizan cosas distintas. Uno prioriza la compatibilidad con DeFi existente. El otro prioriza reducir los cambios directamente en Bitcoin.
Ese fue mi aprendizaje más importante.
Entré en este agujero de conejo pensando que la innovación era "pedir prestado contra Bitcoin". Salí pensando que la pregunta más interesante es dónde se introducen las suposiciones de confianza, y si pueden reducirse sin renunciar a la usabilidad.
Eso es lo que parece que vale la pena seguir conversando mientras Trustless Bitcoin Vaults (TBV) avanza más allá de la testnet pública.
@babylonlabs_io $BABY #baby
Entré en la documentación de Trustless Bitcoin Vaults (TBV) pensando que el BTC envuelto y el préstamo con garantía de BTC nativo estaban resolviendo el mismo problema con herramientas diferentes.
Después de unas horas de lectura, no creo que partan ni siquiera de la misma suposición.
Wrapped BTC pregunta: "¿Cómo metemos Bitcoin en DeFi?"
TBV parece preguntar: "¿Por qué Bitcoin tiene que convertirse en otra cosa antes de que DeFi pueda usarlo?"
Esa diferencia se me quedó grabada más que el propio flujo de préstamo.
La forma más fácil de pensar en el BTC envuelto es que crea otra versión de Bitcoin con la que las aplicaciones ya saben trabajar. Es práctico, y por eso se convirtió en el estándar. Pero cada capa adicional también trae consigo otro conjunto de supuestos que tiene que seguir funcionando como se espera.
TBV no elimina la complejidad: la desplaza.
En lugar de crear otra representación de Bitcoin, el protocolo intenta mantener el BTC nativo donde ya pertenece mientras demuestra su condición de colateral ante aplicaciones como Aave v4. El reto de ingeniería pasa de crear un activo envuelto a coordinar la verificación entre sistemas distintos.
Esa es una filosofía de diseño diferente.
No estoy diciendo que un enfoque reemplace automáticamente al otro. Wrapped BTC tiene un ecosistema establecido y una liquidez profunda hoy. Pero tras comparar ambos modelos, me di cuenta de que optimizan cosas distintas. Uno prioriza la compatibilidad con DeFi existente. El otro prioriza reducir los cambios directamente en Bitcoin.
Ese fue mi aprendizaje más importante.
Entré en este agujero de conejo pensando que la innovación era "pedir prestado contra Bitcoin". Salí pensando que la pregunta más interesante es dónde se introducen las suposiciones de confianza, y si pueden reducirse sin renunciar a la usabilidad.
Eso es lo que parece que vale la pena seguir conversando mientras Trustless Bitcoin Vaults (TBV) avanza más allá de la testnet pública.
@BabylonLabs_io $BABY #baby
Después de unas horas de lectura, no creo que partan ni siquiera de la misma suposición.
Wrapped BTC pregunta: "¿Cómo metemos Bitcoin en DeFi?"
TBV parece preguntar: "¿Por qué Bitcoin tiene que convertirse en otra cosa antes de que DeFi pueda usarlo?"
Esa diferencia se me quedó grabada más que el propio flujo de préstamo.
La forma más fácil de pensar en el BTC envuelto es que crea otra versión de Bitcoin con la que las aplicaciones ya saben trabajar. Es práctico, y por eso se convirtió en el estándar. Pero cada capa adicional también trae consigo otro conjunto de supuestos que tiene que seguir funcionando como se espera.
TBV no elimina la complejidad: la desplaza.
En lugar de crear otra representación de Bitcoin, el protocolo intenta mantener el BTC nativo donde ya pertenece mientras demuestra su condición de colateral ante aplicaciones como Aave v4. El reto de ingeniería pasa de crear un activo envuelto a coordinar la verificación entre sistemas distintos.
Esa es una filosofía de diseño diferente.
No estoy diciendo que un enfoque reemplace automáticamente al otro. Wrapped BTC tiene un ecosistema establecido y una liquidez profunda hoy. Pero tras comparar ambos modelos, me di cuenta de que optimizan cosas distintas. Uno prioriza la compatibilidad con DeFi existente. El otro prioriza reducir los cambios directamente en Bitcoin.
Ese fue mi aprendizaje más importante.
Entré en este agujero de conejo pensando que la innovación era "pedir prestado contra Bitcoin". Salí pensando que la pregunta más interesante es dónde se introducen las suposiciones de confianza, y si pueden reducirse sin renunciar a la usabilidad.
Eso es lo que parece que vale la pena seguir conversando mientras Trustless Bitcoin Vaults (TBV) avanza más allá de la testnet pública.
@BabylonLabs_io $BABY #baby
3
1
105
·
--
Abrí las Bóvedas Bitcoin sin fideicomiso (TBV) de la red de pruebas pensando que lo interesante sería el flujo de préstamo. Bloqueo BTC, tomo prestados activos a través de Aave v4 y listo. Eso es en lo que se enfocan los titulares.
Al final, terminé prestando atención a otra cosa completamente.
La parte que me seguía atrayendo no era lo que podía pedir prestado. Era lo que no había ocurrido antes del préstamo. Bitcoin nativo no se estaba envolviendo primero en otro token, y eso cambia dónde viven las suposiciones de confianza.
Esa es una diferencia sutil, pero creo que es importante.
La mayoría de las conversaciones sobre DeFi de Bitcoin terminan convirtiéndose en discusiones sobre puentes, custodios o representaciones sintéticas. TBV parece estar planteando una pregunta distinta: si Bitcoin ya es la garantía, ¿por qué debería convertirse primero en otra cosa para poder participar?
La red de pruebas también me recordó que hacer que esto funcione no es sencillo. Detrás de lo que parece un flujo de usuario directo hay mucha coordinación entre Bitcoin, Ethereum y el propio protocolo. La interfaz es lo bastante limpia como para que sea fácil pasar por alto cuántas piezas móviles tienen que mantenerse sincronizadas.
Dejé comentarios después de probarlo porque probablemente esa sea la parte más valiosa de una red de pruebas pública. La documentación explica el diseño, pero los usuarios reales revelan los puntos de fricción que los diagramas nunca muestran.
Mi conclusión más importante no fue que logré pedir prestado contra Bitcoin. Fue darme cuenta de que Babylon parece estar menos interesado en competir con los mercados de préstamos de BTC existentes y más interesado en cambiar las suposiciones en las que esos mercados han confiado durante años.
Si ese enfoque se convierte en el nuevo estándar sigue siendo una pregunta abierta. Pero después de probar el flujo yo mismo, creo que esa es la pregunta que vale la pena seguir.
@babylonlabs_io $BABY #baby
Abrí las Bóvedas Bitcoin sin fideicomiso (TBV) de la red de pruebas pensando que lo interesante sería el flujo de préstamo. Bloqueo BTC, tomo prestados activos a través de Aave v4 y listo. Eso es en lo que se enfocan los titulares.
Al final, terminé prestando atención a otra cosa completamente.
La parte que me seguía atrayendo no era lo que podía pedir prestado. Era lo que no había ocurrido antes del préstamo. Bitcoin nativo no se estaba envolviendo primero en otro token, y eso cambia dónde viven las suposiciones de confianza.
Esa es una diferencia sutil, pero creo que es importante.
La mayoría de las conversaciones sobre DeFi de Bitcoin terminan convirtiéndose en discusiones sobre puentes, custodios o representaciones sintéticas. TBV parece estar planteando una pregunta distinta: si Bitcoin ya es la garantía, ¿por qué debería convertirse primero en otra cosa para poder participar?
La red de pruebas también me recordó que hacer que esto funcione no es sencillo. Detrás de lo que parece un flujo de usuario directo hay mucha coordinación entre Bitcoin, Ethereum y el propio protocolo. La interfaz es lo bastante limpia como para que sea fácil pasar por alto cuántas piezas móviles tienen que mantenerse sincronizadas.
Dejé comentarios después de probarlo porque probablemente esa sea la parte más valiosa de una red de pruebas pública. La documentación explica el diseño, pero los usuarios reales revelan los puntos de fricción que los diagramas nunca muestran.
Mi conclusión más importante no fue que logré pedir prestado contra Bitcoin. Fue darme cuenta de que Babylon parece estar menos interesado en competir con los mercados de préstamos de BTC existentes y más interesado en cambiar las suposiciones en las que esos mercados han confiado durante años.
Si ese enfoque se convierte en el nuevo estándar sigue siendo una pregunta abierta. Pero después de probar el flujo yo mismo, creo que esa es la pregunta que vale la pena seguir.
@BabylonLabs_io $BABY #baby
Al final, terminé prestando atención a otra cosa completamente.
La parte que me seguía atrayendo no era lo que podía pedir prestado. Era lo que no había ocurrido antes del préstamo. Bitcoin nativo no se estaba envolviendo primero en otro token, y eso cambia dónde viven las suposiciones de confianza.
Esa es una diferencia sutil, pero creo que es importante.
La mayoría de las conversaciones sobre DeFi de Bitcoin terminan convirtiéndose en discusiones sobre puentes, custodios o representaciones sintéticas. TBV parece estar planteando una pregunta distinta: si Bitcoin ya es la garantía, ¿por qué debería convertirse primero en otra cosa para poder participar?
La red de pruebas también me recordó que hacer que esto funcione no es sencillo. Detrás de lo que parece un flujo de usuario directo hay mucha coordinación entre Bitcoin, Ethereum y el propio protocolo. La interfaz es lo bastante limpia como para que sea fácil pasar por alto cuántas piezas móviles tienen que mantenerse sincronizadas.
Dejé comentarios después de probarlo porque probablemente esa sea la parte más valiosa de una red de pruebas pública. La documentación explica el diseño, pero los usuarios reales revelan los puntos de fricción que los diagramas nunca muestran.
Mi conclusión más importante no fue que logré pedir prestado contra Bitcoin. Fue darme cuenta de que Babylon parece estar menos interesado en competir con los mercados de préstamos de BTC existentes y más interesado en cambiar las suposiciones en las que esos mercados han confiado durante años.
Si ese enfoque se convierte en el nuevo estándar sigue siendo una pregunta abierta. Pero después de probar el flujo yo mismo, creo que esa es la pregunta que vale la pena seguir.
@BabylonLabs_io $BABY #baby
3
1
126
·
--
#baby $BABY
Empecé a leer sobre Trustless Bitcoin Vaults (TBV) porque quería entender el flujo de préstamo.
Al final, pensé mucho más en dónde el protocolo decide conservar la confianza.
Al principio, “colateral nativo de Bitcoin” sonaba como otra descripción de producto. A medida que profundicé en la arquitectura, cada vez más se convirtió en una decisión de diseño.
No se le está pidiendo a Bitcoin que se vuelva más rápido.
Tampoco se le está pidiendo que se convierta en un activo EVM.
En cambio, el sistema se construye aceptando las propias reglas de Bitcoin y diseñando el resto de la infraestructura en torno a ellas.
Eso se siente como una filosofía sorprendentemente distinta.
La mayoría de los sistemas entre cadenas intentan minimizar la fricción introduciendo otra capa que hace que los activos sea más fácil de mover. TBV parece adoptar casi el enfoque contrario. Acepta que Bitcoin tiene su propio modelo de liquidación y luego pregunta cómo la infraestructura de préstamos puede respetarlo en lugar de reemplazarlo.
Cuanto más comparé esos enfoques, menos pensé que esto era un debate sobre eficiencia de capital.
Se convirtió en una discusión sobre qué supuestos merecen permanecer intactos.
Todo protocolo tiene concesiones. TBV no está exento de eso. La coordinación, la verificación y la complejidad operativa no desaparecen solo porque la custodia esté minimizada.
Pero la complejidad y la confianza no siempre son lo mismo.
Una proviene de la ingeniería.
La otra proviene de pedir a los usuarios que crean en partes adicionales.
Sigo trabajando con la documentación, pero esa fue la distinción que se me quedó.
Tal vez el futuro de Bitcoin en DeFi no lo decida el protocolo que mueva BTC más rápido.
Tal vez se decida por el protocolo que cambie menos cosas sobre el motivo por el que la gente confiaba en Bitcoin desde el principio.
@babylonlabs_io
#baby $BABY
#baby $BABY
Empecé a leer sobre Trustless Bitcoin Vaults (TBV) porque quería entender el flujo de préstamo.
Al final, pensé mucho más en dónde el protocolo decide conservar la confianza.
Al principio, “colateral nativo de Bitcoin” sonaba como otra descripción de producto. A medida que profundicé en la arquitectura, cada vez más se convirtió en una decisión de diseño.
No se le está pidiendo a Bitcoin que se vuelva más rápido.
Tampoco se le está pidiendo que se convierta en un activo EVM.
En cambio, el sistema se construye aceptando las propias reglas de Bitcoin y diseñando el resto de la infraestructura en torno a ellas.
Eso se siente como una filosofía sorprendentemente distinta.
La mayoría de los sistemas entre cadenas intentan minimizar la fricción introduciendo otra capa que hace que los activos sea más fácil de mover. TBV parece adoptar casi el enfoque contrario. Acepta que Bitcoin tiene su propio modelo de liquidación y luego pregunta cómo la infraestructura de préstamos puede respetarlo en lugar de reemplazarlo.
Cuanto más comparé esos enfoques, menos pensé que esto era un debate sobre eficiencia de capital.
Se convirtió en una discusión sobre qué supuestos merecen permanecer intactos.
Todo protocolo tiene concesiones. TBV no está exento de eso. La coordinación, la verificación y la complejidad operativa no desaparecen solo porque la custodia esté minimizada.
Pero la complejidad y la confianza no siempre son lo mismo.
Una proviene de la ingeniería.
La otra proviene de pedir a los usuarios que crean en partes adicionales.
Sigo trabajando con la documentación, pero esa fue la distinción que se me quedó.
Tal vez el futuro de Bitcoin en DeFi no lo decida el protocolo que mueva BTC más rápido.
Tal vez se decida por el protocolo que cambie menos cosas sobre el motivo por el que la gente confiaba en Bitcoin desde el principio.
@BabylonLabs_io
#baby $BABY
Empecé a leer sobre Trustless Bitcoin Vaults (TBV) porque quería entender el flujo de préstamo.
Al final, pensé mucho más en dónde el protocolo decide conservar la confianza.
Al principio, “colateral nativo de Bitcoin” sonaba como otra descripción de producto. A medida que profundicé en la arquitectura, cada vez más se convirtió en una decisión de diseño.
No se le está pidiendo a Bitcoin que se vuelva más rápido.
Tampoco se le está pidiendo que se convierta en un activo EVM.
En cambio, el sistema se construye aceptando las propias reglas de Bitcoin y diseñando el resto de la infraestructura en torno a ellas.
Eso se siente como una filosofía sorprendentemente distinta.
La mayoría de los sistemas entre cadenas intentan minimizar la fricción introduciendo otra capa que hace que los activos sea más fácil de mover. TBV parece adoptar casi el enfoque contrario. Acepta que Bitcoin tiene su propio modelo de liquidación y luego pregunta cómo la infraestructura de préstamos puede respetarlo en lugar de reemplazarlo.
Cuanto más comparé esos enfoques, menos pensé que esto era un debate sobre eficiencia de capital.
Se convirtió en una discusión sobre qué supuestos merecen permanecer intactos.
Todo protocolo tiene concesiones. TBV no está exento de eso. La coordinación, la verificación y la complejidad operativa no desaparecen solo porque la custodia esté minimizada.
Pero la complejidad y la confianza no siempre son lo mismo.
Una proviene de la ingeniería.
La otra proviene de pedir a los usuarios que crean en partes adicionales.
Sigo trabajando con la documentación, pero esa fue la distinción que se me quedó.
Tal vez el futuro de Bitcoin en DeFi no lo decida el protocolo que mueva BTC más rápido.
Tal vez se decida por el protocolo que cambie menos cosas sobre el motivo por el que la gente confiaba en Bitcoin desde el principio.
@BabylonLabs_io
#baby $BABY
3
123
·
--
#baby $BABY
Empecé a leer sobre los Trustless Bitcoin Vaults (TBV), pensando que terminaría comparando las tasas de préstamo.
No pasó.
Seguí volviendo a algo mucho menos evidente: dónde reside la confianza una vez que el Bitcoin nativo se convierte en garantía.
Durante años, el camino predeterminado parecía resuelto. Envolver BTC, hacer el puente, interactuar con DeFi y seguir adelante. Yo trataba esas capas extra como el costo inevitable de hacer que Bitcoin sea útil fuera de su propia cadena.
Los TBV me hicieron cuestionar si esa suposición merecía convertirse en el predeterminado.
Lo que destacó no es que de pronto Bitcoin se vuelva sin fricciones. No lo es. El BTC nativo sigue el propio ritmo de liquidación de Bitcoin, y esa cadencia no desaparece solo porque otra cadena quiera una ejecución más rápida.
La diferencia es en dónde el protocolo decide absorber esas fricciones.
En lugar de introducir otra representación de Bitcoin, los TBV mantienen la garantía ligada al propio Bitcoin mientras construyen la lógica de préstamos a partir de esa realidad. La espera no desaparece: simplemente sigue las reglas de Bitcoin en lugar de las de un puente o un custodio.
Cuanto más lo pienso, menos se siente esto como una discusión sobre préstamos.
Es una discusión sobre prioridades de diseño.
¿Es mejor optimizar para la comodidad inmediata, o preservar las suposiciones de seguridad que hicieron que Bitcoin fuera valioso en primer lugar?
Todavía estoy trabajando en la arquitectura, y estoy seguro de que aún no he apreciado completamente algunos compromisos.
Pero una cosa ha cambiado.
Ya no juzgo la infraestructura de Bitcoin por la rapidez con la que mueve BTC.
Estoy prestando mucha más atención a lo que me pide que confíe antes de que mueva cualquier cosa.
@babylonlabs_io
#baby
#baby $BABY
Empecé a leer sobre los Trustless Bitcoin Vaults (TBV), pensando que terminaría comparando las tasas de préstamo.
No pasó.
Seguí volviendo a algo mucho menos evidente: dónde reside la confianza una vez que el Bitcoin nativo se convierte en garantía.
Durante años, el camino predeterminado parecía resuelto. Envolver BTC, hacer el puente, interactuar con DeFi y seguir adelante. Yo trataba esas capas extra como el costo inevitable de hacer que Bitcoin sea útil fuera de su propia cadena.
Los TBV me hicieron cuestionar si esa suposición merecía convertirse en el predeterminado.
Lo que destacó no es que de pronto Bitcoin se vuelva sin fricciones. No lo es. El BTC nativo sigue el propio ritmo de liquidación de Bitcoin, y esa cadencia no desaparece solo porque otra cadena quiera una ejecución más rápida.
La diferencia es en dónde el protocolo decide absorber esas fricciones.
En lugar de introducir otra representación de Bitcoin, los TBV mantienen la garantía ligada al propio Bitcoin mientras construyen la lógica de préstamos a partir de esa realidad. La espera no desaparece: simplemente sigue las reglas de Bitcoin en lugar de las de un puente o un custodio.
Cuanto más lo pienso, menos se siente esto como una discusión sobre préstamos.
Es una discusión sobre prioridades de diseño.
¿Es mejor optimizar para la comodidad inmediata, o preservar las suposiciones de seguridad que hicieron que Bitcoin fuera valioso en primer lugar?
Todavía estoy trabajando en la arquitectura, y estoy seguro de que aún no he apreciado completamente algunos compromisos.
Pero una cosa ha cambiado.
Ya no juzgo la infraestructura de Bitcoin por la rapidez con la que mueve BTC.
Estoy prestando mucha más atención a lo que me pide que confíe antes de que mueva cualquier cosa.
@BabylonLabs_io
#baby
Empecé a leer sobre los Trustless Bitcoin Vaults (TBV), pensando que terminaría comparando las tasas de préstamo.
No pasó.
Seguí volviendo a algo mucho menos evidente: dónde reside la confianza una vez que el Bitcoin nativo se convierte en garantía.
Durante años, el camino predeterminado parecía resuelto. Envolver BTC, hacer el puente, interactuar con DeFi y seguir adelante. Yo trataba esas capas extra como el costo inevitable de hacer que Bitcoin sea útil fuera de su propia cadena.
Los TBV me hicieron cuestionar si esa suposición merecía convertirse en el predeterminado.
Lo que destacó no es que de pronto Bitcoin se vuelva sin fricciones. No lo es. El BTC nativo sigue el propio ritmo de liquidación de Bitcoin, y esa cadencia no desaparece solo porque otra cadena quiera una ejecución más rápida.
La diferencia es en dónde el protocolo decide absorber esas fricciones.
En lugar de introducir otra representación de Bitcoin, los TBV mantienen la garantía ligada al propio Bitcoin mientras construyen la lógica de préstamos a partir de esa realidad. La espera no desaparece: simplemente sigue las reglas de Bitcoin en lugar de las de un puente o un custodio.
Cuanto más lo pienso, menos se siente esto como una discusión sobre préstamos.
Es una discusión sobre prioridades de diseño.
¿Es mejor optimizar para la comodidad inmediata, o preservar las suposiciones de seguridad que hicieron que Bitcoin fuera valioso en primer lugar?
Todavía estoy trabajando en la arquitectura, y estoy seguro de que aún no he apreciado completamente algunos compromisos.
Pero una cosa ha cambiado.
Ya no juzgo la infraestructura de Bitcoin por la rapidez con la que mueve BTC.
Estoy prestando mucha más atención a lo que me pide que confíe antes de que mueva cualquier cosa.
@BabylonLabs_io
#baby
1
1
123
·
--
#baby $BABY
Pasé más tiempo del que esperaba leyendo sobre bóvedas de Bitcoin sin confianza (TBV) anoche.
Entré pensando que la parte interesante sería pedir prestado contra Bitcoin nativo. Esa es la característica que todo el mundo nota primero.
Pero en cambio, seguí volviendo a algo mucho más silencioso.
¿Hacia dónde se mueve realmente la confianza?
La mayoría de los diseños de DeFi de Bitcoin resuelven la interoperabilidad agregando otra capa: un activo tokenizado, un puente o un custodio. Ganas flexibilidad, pero también heredas otro sistema cuya seguridad importa casi tanto como la de Bitcoin.
TBV no finge que esos compromisos desaparezcan.
Cambia el lugar donde viven.
El BTC nativo sigue estando asegurado por Bitcoin, mientras que su estatus como colateral es reconocido para aplicaciones como los préstamos. Eso suena como una decisión arquitectónica pequeña hasta que te das cuenta de que desplaza la prioridad del protocolo de mover Bitcoin a preservar el modelo de confianza de Bitcoin.
Cuanto más lo comparé con enfoques anteriores, menos pensé que esto fuera una historia sobre préstamos.
Empezó a parecer una historia sobre filosofía de diseño.
Un camino le pide a Bitcoin que se adapte a la infraestructura DeFi existente.
El otro le pide a la infraestructura que se adapte alrededor de Bitcoin.
Todavía sigo leyendo los detalles, porque todo sistema tiene límites, y esos límites suelen ser donde se esconden las lecciones más interesantes.
Pero esa fue la pregunta con la que cerré mi cuaderno:
A medida que Bitcoin se vuelve utilizable en más ecosistemas, ¿los diseños ganadores serán los que maximizan la conveniencia o los que minimizan los cambios en el propio Bitcoin?
@babylonlabs_io
#baby
#baby $BABY
Pasé más tiempo del que esperaba leyendo sobre bóvedas de Bitcoin sin confianza (TBV) anoche.
Entré pensando que la parte interesante sería pedir prestado contra Bitcoin nativo. Esa es la característica que todo el mundo nota primero.
Pero en cambio, seguí volviendo a algo mucho más silencioso.
¿Hacia dónde se mueve realmente la confianza?
La mayoría de los diseños de DeFi de Bitcoin resuelven la interoperabilidad agregando otra capa: un activo tokenizado, un puente o un custodio. Ganas flexibilidad, pero también heredas otro sistema cuya seguridad importa casi tanto como la de Bitcoin.
TBV no finge que esos compromisos desaparezcan.
Cambia el lugar donde viven.
El BTC nativo sigue estando asegurado por Bitcoin, mientras que su estatus como colateral es reconocido para aplicaciones como los préstamos. Eso suena como una decisión arquitectónica pequeña hasta que te das cuenta de que desplaza la prioridad del protocolo de mover Bitcoin a preservar el modelo de confianza de Bitcoin.
Cuanto más lo comparé con enfoques anteriores, menos pensé que esto fuera una historia sobre préstamos.
Empezó a parecer una historia sobre filosofía de diseño.
Un camino le pide a Bitcoin que se adapte a la infraestructura DeFi existente.
El otro le pide a la infraestructura que se adapte alrededor de Bitcoin.
Todavía sigo leyendo los detalles, porque todo sistema tiene límites, y esos límites suelen ser donde se esconden las lecciones más interesantes.
Pero esa fue la pregunta con la que cerré mi cuaderno:
A medida que Bitcoin se vuelve utilizable en más ecosistemas, ¿los diseños ganadores serán los que maximizan la conveniencia o los que minimizan los cambios en el propio Bitcoin?
@BabylonLabs_io
#baby
Pasé más tiempo del que esperaba leyendo sobre bóvedas de Bitcoin sin confianza (TBV) anoche.
Entré pensando que la parte interesante sería pedir prestado contra Bitcoin nativo. Esa es la característica que todo el mundo nota primero.
Pero en cambio, seguí volviendo a algo mucho más silencioso.
¿Hacia dónde se mueve realmente la confianza?
La mayoría de los diseños de DeFi de Bitcoin resuelven la interoperabilidad agregando otra capa: un activo tokenizado, un puente o un custodio. Ganas flexibilidad, pero también heredas otro sistema cuya seguridad importa casi tanto como la de Bitcoin.
TBV no finge que esos compromisos desaparezcan.
Cambia el lugar donde viven.
El BTC nativo sigue estando asegurado por Bitcoin, mientras que su estatus como colateral es reconocido para aplicaciones como los préstamos. Eso suena como una decisión arquitectónica pequeña hasta que te das cuenta de que desplaza la prioridad del protocolo de mover Bitcoin a preservar el modelo de confianza de Bitcoin.
Cuanto más lo comparé con enfoques anteriores, menos pensé que esto fuera una historia sobre préstamos.
Empezó a parecer una historia sobre filosofía de diseño.
Un camino le pide a Bitcoin que se adapte a la infraestructura DeFi existente.
El otro le pide a la infraestructura que se adapte alrededor de Bitcoin.
Todavía sigo leyendo los detalles, porque todo sistema tiene límites, y esos límites suelen ser donde se esconden las lecciones más interesantes.
Pero esa fue la pregunta con la que cerré mi cuaderno:
A medida que Bitcoin se vuelve utilizable en más ecosistemas, ¿los diseños ganadores serán los que maximizan la conveniencia o los que minimizan los cambios en el propio Bitcoin?
@BabylonLabs_io
#baby
1
105
·
--
#baby $BABY
Antes pensaba que entendía por qué la gente envolvía Bitcoin.
Solo parecía el camino normal. Si querías usar BTC en DeFi, lo envolvías, lo conectabas (hacías el puente) y seguías adelante. En realidad nunca lo cuestioné porque a todos les parecía tratarlo como el precio de participar.
Luego, una tarde-noche me encontré leyendo sobre Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io.
Lo que empezó como una investigación casual se convirtió en un agujero de conejo mucho más largo de lo que esperaba.
Lo interesante no era que TBV ofrezca otra forma de usar Bitcoin. Era la pregunta que se escondía debajo.
¿Por qué Bitcoin tiene que convertirse en otra cosa antes de volverse útil?
Esa idea se quedó conmigo.
Cuanto más aprendía, más me daba cuenta de que nos hemos acostumbrado a añadir capas extra alrededor de Bitcoin en lugar de preguntarnos si esas capas eran necesarias desde el principio. Envoltorios, puentes, custodios: resolvieron problemas reales, pero también se convirtieron en suposiciones que rara vez cuestionamos.
TBV lo aborda de manera diferente: permite que el Bitcoin nativo sirva como colateral, mientras permanece anclado al propio modelo de seguridad de Bitcoin. No se trata de fingir que no existen compensaciones (trade-offs). Se trata de cambiar qué compensaciones tienen que aceptar los usuarios.
Todavía estoy aprendiendo, así que no pretendo tener todas las respuestas.
Pero de vez en cuando, un protocolo cambia la forma en que piensas en lugar de simplemente añadir otra característica para comparar.
Para mí, @babylonlabs_io ha hecho exactamente eso.
Quizá lo más valioso que gané no fue un producto nuevo que seguir: fue una nueva pregunta para seguir haciéndome.
#baby $BABY
Antes pensaba que entendía por qué la gente envolvía Bitcoin.
Solo parecía el camino normal. Si querías usar BTC en DeFi, lo envolvías, lo conectabas (hacías el puente) y seguías adelante. En realidad nunca lo cuestioné porque a todos les parecía tratarlo como el precio de participar.
Luego, una tarde-noche me encontré leyendo sobre Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io.
Lo que empezó como una investigación casual se convirtió en un agujero de conejo mucho más largo de lo que esperaba.
Lo interesante no era que TBV ofrezca otra forma de usar Bitcoin. Era la pregunta que se escondía debajo.
¿Por qué Bitcoin tiene que convertirse en otra cosa antes de volverse útil?
Esa idea se quedó conmigo.
Cuanto más aprendía, más me daba cuenta de que nos hemos acostumbrado a añadir capas extra alrededor de Bitcoin en lugar de preguntarnos si esas capas eran necesarias desde el principio. Envoltorios, puentes, custodios: resolvieron problemas reales, pero también se convirtieron en suposiciones que rara vez cuestionamos.
TBV lo aborda de manera diferente: permite que el Bitcoin nativo sirva como colateral, mientras permanece anclado al propio modelo de seguridad de Bitcoin. No se trata de fingir que no existen compensaciones (trade-offs). Se trata de cambiar qué compensaciones tienen que aceptar los usuarios.
Todavía estoy aprendiendo, así que no pretendo tener todas las respuestas.
Pero de vez en cuando, un protocolo cambia la forma en que piensas en lugar de simplemente añadir otra característica para comparar.
Para mí, @BabylonLabs_io ha hecho exactamente eso.
Quizá lo más valioso que gané no fue un producto nuevo que seguir: fue una nueva pregunta para seguir haciéndome.
Antes pensaba que entendía por qué la gente envolvía Bitcoin.
Solo parecía el camino normal. Si querías usar BTC en DeFi, lo envolvías, lo conectabas (hacías el puente) y seguías adelante. En realidad nunca lo cuestioné porque a todos les parecía tratarlo como el precio de participar.
Luego, una tarde-noche me encontré leyendo sobre Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io.
Lo que empezó como una investigación casual se convirtió en un agujero de conejo mucho más largo de lo que esperaba.
Lo interesante no era que TBV ofrezca otra forma de usar Bitcoin. Era la pregunta que se escondía debajo.
¿Por qué Bitcoin tiene que convertirse en otra cosa antes de volverse útil?
Esa idea se quedó conmigo.
Cuanto más aprendía, más me daba cuenta de que nos hemos acostumbrado a añadir capas extra alrededor de Bitcoin en lugar de preguntarnos si esas capas eran necesarias desde el principio. Envoltorios, puentes, custodios: resolvieron problemas reales, pero también se convirtieron en suposiciones que rara vez cuestionamos.
TBV lo aborda de manera diferente: permite que el Bitcoin nativo sirva como colateral, mientras permanece anclado al propio modelo de seguridad de Bitcoin. No se trata de fingir que no existen compensaciones (trade-offs). Se trata de cambiar qué compensaciones tienen que aceptar los usuarios.
Todavía estoy aprendiendo, así que no pretendo tener todas las respuestas.
Pero de vez en cuando, un protocolo cambia la forma en que piensas en lugar de simplemente añadir otra característica para comparar.
Para mí, @BabylonLabs_io ha hecho exactamente eso.
Quizá lo más valioso que gané no fue un producto nuevo que seguir: fue una nueva pregunta para seguir haciéndome.
102
·
--
#baby $BABY
No esperaba que un solo documento me hiciera cuestionar algo que había aceptado durante años.
Pasó a altas horas de la noche mientras leía sobre la infraestructura de Bitcoin. Veía el mismo patrón una y otra vez. Cada vez que Bitcoin quería participar en DeFi, la primera instrucción era casi automática.
Envuélvelo.
Enlázalo.
Muévelo a otro lugar.
En algún momento me di cuenta de que había dejado de preguntarme el porqué.
Quizá eso es lo que pasa cuando una idea se repite el tiempo suficiente: deja de sentirse como un compromiso y empieza a parecer la única opción.
Luego empecé a leer sobre las Trustless Bitcoin Vaults (TBV) de @babylonlabs_io .
Lo que llamó mi atención no fue que prometiera algo más rápido o más grande. Fue que cuestionaba la suposición que yo nunca había cuestionado.
¿Por qué Bitcoin tendría que salir de Bitcoin para volverse útil?
Cuanto más me quedaba con esa idea, más todo lo demás empezó a verse hacia atrás. Tal vez hemos pasado años diseñando formas de adaptar Bitcoin a DeFi, en lugar de adaptar DeFi para respetar el modelo de seguridad propio de Bitcoin.
TBV no elimina mágicamente cada compensación. Bitcoin sigue siendo Bitcoin. La liquidación sigue tomando tiempo.
Pero cambia la confianza.
En lugar de pedir a los usuarios que crean en “wrappers”, puentes o custodios, el sistema se apoya con más fuerza en las propias reglas de Bitcoin.
Eso se siente menos como perseguir conveniencia y más como respetar el activo que estás intentando desbloquear.
Quizá esa es la dirección que Bitcoin DeFi ha estado echando en falta desde hace todo este tiempo.
#baby $BABY
No esperaba que un solo documento me hiciera cuestionar algo que había aceptado durante años.
Pasó a altas horas de la noche mientras leía sobre la infraestructura de Bitcoin. Veía el mismo patrón una y otra vez. Cada vez que Bitcoin quería participar en DeFi, la primera instrucción era casi automática.
Envuélvelo.
Enlázalo.
Muévelo a otro lugar.
En algún momento me di cuenta de que había dejado de preguntarme el porqué.
Quizá eso es lo que pasa cuando una idea se repite el tiempo suficiente: deja de sentirse como un compromiso y empieza a parecer la única opción.
Luego empecé a leer sobre las Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io .
Lo que llamó mi atención no fue que prometiera algo más rápido o más grande. Fue que cuestionaba la suposición que yo nunca había cuestionado.
¿Por qué Bitcoin tendría que salir de Bitcoin para volverse útil?
Cuanto más me quedaba con esa idea, más todo lo demás empezó a verse hacia atrás. Tal vez hemos pasado años diseñando formas de adaptar Bitcoin a DeFi, en lugar de adaptar DeFi para respetar el modelo de seguridad propio de Bitcoin.
TBV no elimina mágicamente cada compensación. Bitcoin sigue siendo Bitcoin. La liquidación sigue tomando tiempo.
Pero cambia la confianza.
En lugar de pedir a los usuarios que crean en “wrappers”, puentes o custodios, el sistema se apoya con más fuerza en las propias reglas de Bitcoin.
Eso se siente menos como perseguir conveniencia y más como respetar el activo que estás intentando desbloquear.
Quizá esa es la dirección que Bitcoin DeFi ha estado echando en falta desde hace todo este tiempo.
No esperaba que un solo documento me hiciera cuestionar algo que había aceptado durante años.
Pasó a altas horas de la noche mientras leía sobre la infraestructura de Bitcoin. Veía el mismo patrón una y otra vez. Cada vez que Bitcoin quería participar en DeFi, la primera instrucción era casi automática.
Envuélvelo.
Enlázalo.
Muévelo a otro lugar.
En algún momento me di cuenta de que había dejado de preguntarme el porqué.
Quizá eso es lo que pasa cuando una idea se repite el tiempo suficiente: deja de sentirse como un compromiso y empieza a parecer la única opción.
Luego empecé a leer sobre las Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io .
Lo que llamó mi atención no fue que prometiera algo más rápido o más grande. Fue que cuestionaba la suposición que yo nunca había cuestionado.
¿Por qué Bitcoin tendría que salir de Bitcoin para volverse útil?
Cuanto más me quedaba con esa idea, más todo lo demás empezó a verse hacia atrás. Tal vez hemos pasado años diseñando formas de adaptar Bitcoin a DeFi, en lugar de adaptar DeFi para respetar el modelo de seguridad propio de Bitcoin.
TBV no elimina mágicamente cada compensación. Bitcoin sigue siendo Bitcoin. La liquidación sigue tomando tiempo.
Pero cambia la confianza.
En lugar de pedir a los usuarios que crean en “wrappers”, puentes o custodios, el sistema se apoya con más fuerza en las propias reglas de Bitcoin.
Eso se siente menos como perseguir conveniencia y más como respetar el activo que estás intentando desbloquear.
Quizá esa es la dirección que Bitcoin DeFi ha estado echando en falta desde hace todo este tiempo.
1
117
·
--
#baby $BABY
Hace unos días, estaba siguiendo mi rutina habitual. Café sobre el escritorio, algunas pestañas abiertas y otra noche más leyendo sobre infraestructura cripto en lugar de revisar gráficos.
No estaba buscando un proyecto nuevo. En realidad, intentaba entender por qué Bitcoin todavía se siente desconectado de gran parte de DeFi, a pesar de ser el activo más grande del sector.
La respuesta obvia siempre parecía ser: "Solo envuélvelo".
Durante años, acepté eso sin darle demasiadas vueltas.
Pero cuanto más leía sobre @babylonlabs_io y Trustless Bitcoin Vaults (TBV), más me di cuenta de que envolver Bitcoin podría haber sido un atajo con el que nos acostumbramos, no necesariamente la mejor solución.
Resolvió un problema al introducir varios otros.
Mover Bitcoin entre cadenas, dependiendo de puentes, o confiar en intermediarios, poco a poco se volvió el camino normal. No creo que muchos de nosotros nos detuviéramos a preguntarnos si Bitcoin realmente necesitaba salir de su propio modelo de seguridad para volverse útil en otros lugares.
Eso fue lo que me llamó la atención de TBV.
En lugar de cambiar Bitcoin, la idea es permitir que el Bitcoin nativo se use como garantía, mientras se mantiene anclado a Bitcoin mismo. Se siente menos como forzar a Bitcoin a encajar en DeFi y más como diseñar una infraestructura que respeta lo que Bitcoin ya es.
Sigo aprendiendo, y no creo que ningún protocolo tenga todas las respuestas.
Pero de vez en cuando te topas con una idea que te hace replantearte una suposición que llevabas años sosteniendo.
Para mí, @babylonlabs_io ha sido uno de esos proyectos.
#baby $BABY
Hace unos días, estaba siguiendo mi rutina habitual. Café sobre el escritorio, algunas pestañas abiertas y otra noche más leyendo sobre infraestructura cripto en lugar de revisar gráficos.
No estaba buscando un proyecto nuevo. En realidad, intentaba entender por qué Bitcoin todavía se siente desconectado de gran parte de DeFi, a pesar de ser el activo más grande del sector.
La respuesta obvia siempre parecía ser: "Solo envuélvelo".
Durante años, acepté eso sin darle demasiadas vueltas.
Pero cuanto más leía sobre @BabylonLabs_io y Trustless Bitcoin Vaults (TBV), más me di cuenta de que envolver Bitcoin podría haber sido un atajo con el que nos acostumbramos, no necesariamente la mejor solución.
Resolvió un problema al introducir varios otros.
Mover Bitcoin entre cadenas, dependiendo de puentes, o confiar en intermediarios, poco a poco se volvió el camino normal. No creo que muchos de nosotros nos detuviéramos a preguntarnos si Bitcoin realmente necesitaba salir de su propio modelo de seguridad para volverse útil en otros lugares.
Eso fue lo que me llamó la atención de TBV.
En lugar de cambiar Bitcoin, la idea es permitir que el Bitcoin nativo se use como garantía, mientras se mantiene anclado a Bitcoin mismo. Se siente menos como forzar a Bitcoin a encajar en DeFi y más como diseñar una infraestructura que respeta lo que Bitcoin ya es.
Sigo aprendiendo, y no creo que ningún protocolo tenga todas las respuestas.
Pero de vez en cuando te topas con una idea que te hace replantearte una suposición que llevabas años sosteniendo.
Para mí, @BabylonLabs_io ha sido uno de esos proyectos.
Hace unos días, estaba siguiendo mi rutina habitual. Café sobre el escritorio, algunas pestañas abiertas y otra noche más leyendo sobre infraestructura cripto en lugar de revisar gráficos.
No estaba buscando un proyecto nuevo. En realidad, intentaba entender por qué Bitcoin todavía se siente desconectado de gran parte de DeFi, a pesar de ser el activo más grande del sector.
La respuesta obvia siempre parecía ser: "Solo envuélvelo".
Durante años, acepté eso sin darle demasiadas vueltas.
Pero cuanto más leía sobre @BabylonLabs_io y Trustless Bitcoin Vaults (TBV), más me di cuenta de que envolver Bitcoin podría haber sido un atajo con el que nos acostumbramos, no necesariamente la mejor solución.
Resolvió un problema al introducir varios otros.
Mover Bitcoin entre cadenas, dependiendo de puentes, o confiar en intermediarios, poco a poco se volvió el camino normal. No creo que muchos de nosotros nos detuviéramos a preguntarnos si Bitcoin realmente necesitaba salir de su propio modelo de seguridad para volverse útil en otros lugares.
Eso fue lo que me llamó la atención de TBV.
En lugar de cambiar Bitcoin, la idea es permitir que el Bitcoin nativo se use como garantía, mientras se mantiene anclado a Bitcoin mismo. Se siente menos como forzar a Bitcoin a encajar en DeFi y más como diseñar una infraestructura que respeta lo que Bitcoin ya es.
Sigo aprendiendo, y no creo que ningún protocolo tenga todas las respuestas.
Pero de vez en cuando te topas con una idea que te hace replantearte una suposición que llevabas años sosteniendo.
Para mí, @BabylonLabs_io ha sido uno de esos proyectos.
84
·
--
#baby $BABY
Cuando la gente habla de Bitcoin en DeFi, la conversación normalmente gira en torno al rendimiento. ¿Qué protocolo ofrece más? ¿Qué estrategia es más eficiente?
Cuanto más exploré el espacio, más sentí que esas discusiones estaban pasando por alto una pregunta mucho más grande.
¿A qué estamos de acuerdo antes incluso de obtener ese rendimiento?
Durante años, usar Bitcoin en DeFi ha significado a menudo aceptar una serie de compensaciones. Envolver tu BTC. Moverlo a otra cadena. Confiar en un custodio o en otra capa de infraestructura. Esos pasos se volvieron tan comunes que muchos de nosotros dejamos de verlos como compromisos.
Leer sobre las Trustless Bitcoin Vaults (TBV) de @babylonlabs_io me hizo replantear esa suposición.
Lo que destacó no fue la promesa de mayores retornos, sino el intento de reducir la confianza innecesaria. TBV está diseñado para permitir que el Bitcoin nativo sirva como colateral sin envolverlo, sin hacer el puente a otra cadena y sin depender de intermediarios centralizados. Ese enfoque se siente mucho más cercano al modelo de seguridad original de Bitcoin.
También me resulta interesante que la primera implementación se centre en préstamos con Bitcoin nativo como respaldo, con Aave v4. En lugar de intentar reinventar DeFi, replantea cómo entra Bitcoin en él desde el principio.
No estoy diciendo que cada solución existente sea incorrecta ni que TBV sea la respuesta final. Pero sí creo que desplaza la conversación hacia algo más fundamental.
Quizá la innovación más grande no sea encontrar otra forma de generar rendimiento.
Quizá sea reducir la cantidad de compromisos que aceptamos en silencio antes de llegar allí.
Esa es la perspectiva con la que @babylonlabs_io me dejó pensando.
#baby $BABY
Cuando la gente habla de Bitcoin en DeFi, la conversación normalmente gira en torno al rendimiento. ¿Qué protocolo ofrece más? ¿Qué estrategia es más eficiente?
Cuanto más exploré el espacio, más sentí que esas discusiones estaban pasando por alto una pregunta mucho más grande.
¿A qué estamos de acuerdo antes incluso de obtener ese rendimiento?
Durante años, usar Bitcoin en DeFi ha significado a menudo aceptar una serie de compensaciones. Envolver tu BTC. Moverlo a otra cadena. Confiar en un custodio o en otra capa de infraestructura. Esos pasos se volvieron tan comunes que muchos de nosotros dejamos de verlos como compromisos.
Leer sobre las Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io me hizo replantear esa suposición.
Lo que destacó no fue la promesa de mayores retornos, sino el intento de reducir la confianza innecesaria. TBV está diseñado para permitir que el Bitcoin nativo sirva como colateral sin envolverlo, sin hacer el puente a otra cadena y sin depender de intermediarios centralizados. Ese enfoque se siente mucho más cercano al modelo de seguridad original de Bitcoin.
También me resulta interesante que la primera implementación se centre en préstamos con Bitcoin nativo como respaldo, con Aave v4. En lugar de intentar reinventar DeFi, replantea cómo entra Bitcoin en él desde el principio.
No estoy diciendo que cada solución existente sea incorrecta ni que TBV sea la respuesta final. Pero sí creo que desplaza la conversación hacia algo más fundamental.
Quizá la innovación más grande no sea encontrar otra forma de generar rendimiento.
Quizá sea reducir la cantidad de compromisos que aceptamos en silencio antes de llegar allí.
Esa es la perspectiva con la que @BabylonLabs_io me dejó pensando.
Cuando la gente habla de Bitcoin en DeFi, la conversación normalmente gira en torno al rendimiento. ¿Qué protocolo ofrece más? ¿Qué estrategia es más eficiente?
Cuanto más exploré el espacio, más sentí que esas discusiones estaban pasando por alto una pregunta mucho más grande.
¿A qué estamos de acuerdo antes incluso de obtener ese rendimiento?
Durante años, usar Bitcoin en DeFi ha significado a menudo aceptar una serie de compensaciones. Envolver tu BTC. Moverlo a otra cadena. Confiar en un custodio o en otra capa de infraestructura. Esos pasos se volvieron tan comunes que muchos de nosotros dejamos de verlos como compromisos.
Leer sobre las Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io me hizo replantear esa suposición.
Lo que destacó no fue la promesa de mayores retornos, sino el intento de reducir la confianza innecesaria. TBV está diseñado para permitir que el Bitcoin nativo sirva como colateral sin envolverlo, sin hacer el puente a otra cadena y sin depender de intermediarios centralizados. Ese enfoque se siente mucho más cercano al modelo de seguridad original de Bitcoin.
También me resulta interesante que la primera implementación se centre en préstamos con Bitcoin nativo como respaldo, con Aave v4. En lugar de intentar reinventar DeFi, replantea cómo entra Bitcoin en él desde el principio.
No estoy diciendo que cada solución existente sea incorrecta ni que TBV sea la respuesta final. Pero sí creo que desplaza la conversación hacia algo más fundamental.
Quizá la innovación más grande no sea encontrar otra forma de generar rendimiento.
Quizá sea reducir la cantidad de compromisos que aceptamos en silencio antes de llegar allí.
Esa es la perspectiva con la que @BabylonLabs_io me dejó pensando.
87
Inicia sesión para explorar más contenidos
Únete a usuarios globales de criptomonedas en Binance Square
⚡️ Obtén información útil y actualizada sobre criptos.
💬 Avalado por el mayor exchange de criptomonedas en el mundo.
👍 Descubre perspectivas reales de creadores verificados.
Email/número de teléfono
Temas populares
AppleDebutsFoldablePhone
46,054 vistas
904 están debatiendo
Apple está a punto de hacer su esperada entrada en el mercado de los smartphones plegables con el iPhone Fold, previsto para su lanzamiento en 2026. Este movimiento estratégico posiciona a Apple como un competidor directo de Samsung, que ha mantenido una presencia dominante en el segmento plegable desde el lanzamiento de su serie Galaxy Z Fold en 2019. Al aprovechar su marca, reconocida a nivel mundial, y su ecosistema estrechamente integrado, Apple busca poner en jaque el liderazgo de Samsung. Sin embargo, este ambicioso paso conlleva consideraciones fundamentales, como las estrategias de precios, la preparación de la cadena de suministro y la confianza del consumidor en un dispositivo plegable de primera generación.
#AppleDebutsFoldablePhone
CriptoUBarber
·0 me gusta
·168 vistas
TSMCAugustRevenueUp53.3%YoY
10,432 vistas
292 están debatiendo
IranSaysReadyToEscalateWarWithUS
13,123 vistas
293 están debatiendo