La colaboración de Chainlink debe dividirse en tres cosas distintas
En el anuncio de la colaboración aparece Chainlink, y mucha gente lo traduce directamente como “Dusk ya tiene un oráculo”. Pero CCIP, DataLink y Data Streams no resuelven el mismo problema. Mezclarlos en un solo logo haría que se pase por alto dónde realmente impacta esta colaboración los flujos de activos regulados.
DataLink se orienta a la publicación de datos institucionales: su enfoque es llevar los datos financieros existentes a la cadena de forma verificable; Data Streams se acerca más a la entrega de datos con baja latencia y se aplica a las aplicaciones que necesitan actualizaciones oportunas de precios o el estado del mercado; y CCIP se encarga de los mensajes y el movimiento de activos entre cadenas, permitiendo que el emisor configure rutas de conexión entre múltiples redes. Una parte se encarga del origen de los datos, otra de su puntualidad y otra de la comunicación entre cadenas; si falta cualquiera de esas piezas, las otras dos no pueden completarla automáticamente.
Para el emisor, lo más crítico no es “si se puede hacer entre cadenas”, sino a dónde, cuánto se puede transferir en una sola vez, quién puede pausar ante una anomalía y quién controla las actualizaciones del contrato. Los materiales oficiales mencionan limitaciones de velocidad y controles de actualización: aunque parezcan opciones conservadoras, en realidad son válvulas de seguridad que las instituciones necesitan. Cuando haya datos erróneos, congestión en la cadena destino o riesgo de llaves, el sistema debe poder acotar el impacto, en lugar de seguir ejecutando sin condiciones.
El servicio de datos también debe responder a la cuestión del tiempo. ¿Qué punto temporal se usa para valorar valores? Si los datos de origen llegan tarde, ¿se usa el valor anterior o se detiene la negociación? ¿Qué pasa con las órdenes que ya se han ejecutado después de corregir los datos? Nada de eso puede decidirse automáticamente con el simple hecho de que “el oráculo ya está integrado”. La aplicación de Dusk debe incluir en sus reglas los sellos de tiempo de los datos, la frecuencia de actualización y los umbrales de caducidad, para saber cuándo puede seguir ejecutándose.
Voy a clasificar @Dusk y los avances con Chainlink según la solidez de la evidencia: firmar la colaboración es una señal débil; que el servicio sea utilizable en un entorno de pruebas es una señal más fuerte; y que los activos reales dependan de esos datos o mensajes entre cadenas para completar la liquidación es la evidencia directa. El siguiente paso que más vale la pena divulgar públicamente no son más nombres de colaboraciones, sino de dónde provienen los datos de una transacción, cuándo se actualizan, cómo se gestionan los fallos entre cadenas y quién confirma finalmente. Mientras esta cadena de evidencias sea completa, Chainlink pasará de ser solo una lista de infraestructura a convertirse en parte del flujo de trabajo de mercado de Dusk. $DUSK #dusk
En el anuncio de la colaboración aparece Chainlink, y mucha gente lo traduce directamente como “Dusk ya tiene un oráculo”. Pero CCIP, DataLink y Data Streams no resuelven el mismo problema. Mezclarlos en un solo logo haría que se pase por alto dónde realmente impacta esta colaboración los flujos de activos regulados.
DataLink se orienta a la publicación de datos institucionales: su enfoque es llevar los datos financieros existentes a la cadena de forma verificable; Data Streams se acerca más a la entrega de datos con baja latencia y se aplica a las aplicaciones que necesitan actualizaciones oportunas de precios o el estado del mercado; y CCIP se encarga de los mensajes y el movimiento de activos entre cadenas, permitiendo que el emisor configure rutas de conexión entre múltiples redes. Una parte se encarga del origen de los datos, otra de su puntualidad y otra de la comunicación entre cadenas; si falta cualquiera de esas piezas, las otras dos no pueden completarla automáticamente.
Para el emisor, lo más crítico no es “si se puede hacer entre cadenas”, sino a dónde, cuánto se puede transferir en una sola vez, quién puede pausar ante una anomalía y quién controla las actualizaciones del contrato. Los materiales oficiales mencionan limitaciones de velocidad y controles de actualización: aunque parezcan opciones conservadoras, en realidad son válvulas de seguridad que las instituciones necesitan. Cuando haya datos erróneos, congestión en la cadena destino o riesgo de llaves, el sistema debe poder acotar el impacto, en lugar de seguir ejecutando sin condiciones.
El servicio de datos también debe responder a la cuestión del tiempo. ¿Qué punto temporal se usa para valorar valores? Si los datos de origen llegan tarde, ¿se usa el valor anterior o se detiene la negociación? ¿Qué pasa con las órdenes que ya se han ejecutado después de corregir los datos? Nada de eso puede decidirse automáticamente con el simple hecho de que “el oráculo ya está integrado”. La aplicación de Dusk debe incluir en sus reglas los sellos de tiempo de los datos, la frecuencia de actualización y los umbrales de caducidad, para saber cuándo puede seguir ejecutándose.
Voy a clasificar @Dusk y los avances con Chainlink según la solidez de la evidencia: firmar la colaboración es una señal débil; que el servicio sea utilizable en un entorno de pruebas es una señal más fuerte; y que los activos reales dependan de esos datos o mensajes entre cadenas para completar la liquidación es la evidencia directa. El siguiente paso que más vale la pena divulgar públicamente no son más nombres de colaboraciones, sino de dónde provienen los datos de una transacción, cuándo se actualizan, cómo se gestionan los fallos entre cadenas y quién confirma finalmente. Mientras esta cadena de evidencias sea completa, Chainlink pasará de ser solo una lista de infraestructura a convertirse en parte del flujo de trabajo de mercado de Dusk. $DUSK #dusk