Salman49

Frenesí

Un estrecho. Cuatro mercados. Por qué cada inversor en criptomonedas debería estar vigilando Ormuz.

La mayoría de los inversores en cripto no siguen rutas de navegación. Yo normalmente tampoco. Pero el Estrecho de Ormuz es uno de esos lugares donde eventos fuera del mundo cripto pueden llegar rápidamente a tu cartera.

Los datos recientes muestran que el tráfico de embarcaciones a través de Ormuz cayó aproximadamente un 52%, mientras que el Brent subió por encima de los 85 dólares por barril a medida que crecían los temores por disrupciones en el suministro. Al mismo tiempo, los reportes de un aumento de la volatilidad en los mercados dispararon fuertes liquidaciones en todo el mercado cripto, recordándoles a los traders lo rápido que los eventos globales pueden cambiar el sentimiento de riesgo.

La lección no es que cada evento geopolítico vaya a desplomar las criptomonedas. Es que los mercados están conectados. Los precios más altos del petróleo pueden aumentar las preocupaciones por la inflación; una incertidumbre más fuerte a menudo aleja a los inversores de los activos de riesgo; y las posiciones apalancadas se vuelven mucho más fáciles de deshacer durante una volatilidad repentina.

Para mí, la principal conclusión no es predecir el próximo titular. Es entender la reacción en cadena. Una disrupción en una de las rutas energéticas más transitadas del mundo puede influir en el petróleo, las acciones, las divisas y, eventualmente, en las criptomonedas. Para cuando Bitcoin reacciona, la historia normalmente empezó en otro lugar.

Si operas con criptomonedas, mirar solo el mundo cripto ya no es suficiente. A veces, la primera señal aparece a cientos de millas de cualquier blockchain. NFA.DYOR.

El Mayor Riesgo Financiero Podría Ser Las Reglas Que Nadie Revisa

No intentaba cambiar nada en mi teléfono. Solo quería impedir que una aplicación pidiera mi ubicación. Unos toques más tarde, me di cuenta de que una docena de aplicaciones habían estado usando el mismo permiso durante meses. Había olvidado por completo haberlo concedido en primer lugar. Una configuración antigua había estado influyendo en todo lo que ocurrió después, en silencio.

Curiosamente, la misma idea me siguió hasta la documentación de Newton.

data.params parece algo normal al principio. Es donde viven los límites, los umbrales, las listas de permitidos (allowlists) y otros valores de configuración. Cuanto más exploraba la arquitectura, menos parecía configuración y más parecía la memoria del sistema. Cada transacción se evalúa en función de decisiones que quizá se tomaron mucho antes de que esa transacción existiera.

Probablemente por eso las organizaciones pasan tanto tiempo revisando las transacciones, pero rara vez cuestionan las reglas que están detrás de ellas. Una transacción dura unos segundos. Un umbral puede moldear miles de transacciones antes de que alguien piense en cambiarlo.

Newton mantiene la lógica de Policy separada de la configuración, para que las organizaciones puedan actualizar data.params sin reescribir la Policy en sí. La documentación también introduce --expire-after, que permite que los parámetros expiren después de un número definido de bloques. No lo leo como una función de conveniencia. Lo leo como un reconocimiento de que las suposiciones de ayer eventualmente se convierten en el riesgo de hoy.

Cuanto más lo pienso, más esto me parece un problema de sistemas, más que uno financiero. Los sistemas confiables no se construyen tomando decisiones perfectas una sola vez. Se construyen revisando las reglas invisibles que siguen tomando decisiones mucho después de que todos hayan olvidado que existen.
NFA.DYOR. #newt $NEWT @NewtonProtocol

Hemos estado construyendo sistemas financieros más rápidos. Quizá olvidamos construir firewalls.

Hace unos días estaba haciendo un pago en línea. El monto era pequeño, pero el pago se detuvo para un paso adicional de verificación. En ese momento me pareció innecesario. La aplicación ya conocía mi cuenta, mi saldo y el destinatario. Entonces, ¿por qué detenerme?

Esa pregunta volvió cuando estaba leyendo la documentación de Newton. Llegué al punto del flujo en el que se evalúa un Intent antes de su ejecución. La Operator Network comprueba una Policy, produce una BLS Attestation y el PolicyClient verifica esa prueba antes de que la transacción pueda continuar. La primera vez que lo leí, solo lo vi como otro sistema de autorización.

Luego llegué a VaultKit y Shield Contracts, y un detalle me hizo detenerme a pensar. Una acción protegida no se reenvía si los operadores la rechazan, si no se alcanza el quórum requerido del 67%, si la attestation caduca o si falla la validación de Shield. Ese fue el momento en que mi primera impresión cambió.

Empecé a preguntarme si hemos estado viendo la seguridad financiera desde la dirección equivocada. La mayoría de los sistemas financieros se centran en detectar transacciones sospechosas después de que ocurren. Newton parece dedicar su esfuerzo a decidir si una transacción merece ocurrir en absoluto. Para mí, eso está mucho más cerca de cómo funciona un firewall que de cómo suele funcionar la seguridad financiera tradicional.

Quizá por eso el paso adicional de verificación durante mi pago de repente tuvo más sentido. No estaba cuestionando mi capacidad para enviar dinero. Estaba cuestionando si esa acción en particular había ganado el permiso para avanzar. Empiezo a pensar que la próxima mejora en finanzas no serán transacciones más rápidas. Serán mejores decisiones antes de que ocurran las transacciones.

Fuente: Documentación del Protocolo Newton. Los términos técnicos como Intent, Policy, Operator Network, BLS Attestation, PolicyClient, VaultKit, Shield Contracts y el quórum predeterminado del 67% se basan en la documentación. La comparación de "firewall financiero" es mi análisis personal. #newt $NEWT @NewtonProtocol #Web3 #AI

La mayor actualización de la IA podría ser aprender cuándo decir «No lo sé».

La mayoría de los usuarios de IA ya han visto que esto ocurre. Haces una pregunta, la respuesta suena segura y solo más tarde te das cuenta de que partes de ella están mal. Eso me hace pensar que la mayor mejora para la IA no es responder más preguntas. Podría ser saber cuándo no responder.

Esa idea volvió mientras leía la documentación de consenso de Newton. Un detalle me llamó la atención. Si los operadores no están de acuerdo con los datos, Newton no ignora en silencio la discrepancia y sigue adelante. Según la documentación, los valores fuera de la tolerancia predeterminada del 10% devuelven ToleranceExceeded, y los operadores no se excluyen en silencio. El protocolo simplemente se detiene.

El mismo patrón aparece en otras partes del sistema. Si ningún operador responde, el resultado es NoResponses. Si la red no puede alcanzar el quórum ponderado por participación del 67% predeterminado, el resultado es InsufficientQuorum. Según la documentación, esas no son fallas ocultas. Son señales explícitas de que la red no pudo llegar a una decisión confiable.

La analogía del cajero automático me ayudó a entender el diseño. Si tu banco no puede confirmar la transacción, preferirías ver «Transacción fallida» antes que el cajero intente adivinar tu saldo y entregue efectivo. Newton parece aplicar la misma idea. A veces negarse a continuar es más seguro que fingir que todo está bien.

No creo que esto sea solo una idea de blockchain. Es una idea de confianza. Los sistemas se vuelven más confiables cuando admiten la incertidumbre en lugar de ocultarla detrás de respuestas seguras. En mi opinión, «No lo sé» puede ser muchísimo más valioso que una respuesta que nunca fue confiable de todos modos.

Fuente: Newton Protocol Documentation (Consensus & Security). #newt $NEWT @NewtonProtocol

El mejor momento para encontrar un fallo no está en producción

La mayoría de los desarrolladores no se preocupa por escribir código. Se preocupan por descubrir demasiado tarde que el código se comporta de una forma distinta a la esperada. Leer la documentación de pruebas de Newton cambió la manera en que pienso en ese problema. Previsualizamos fotos antes de publicarlas y verificamos indicaciones antes de un largo viaje en coche. Implementar una política sin probarla empieza a sentirse como saltarse ambos pasos.

La documentación de Newton sigue un principio sencillo: prueba primero, despliega después. Los desarrolladores pueden validar componentes individuales o simular el flujo de trabajo completo antes de que algo llegue a la blockchain. El paso final, simulatePolicy(), recopila datos del oráculo, evalúa la política Rego y muestra si el resultado sería permitir o denegar antes del despliegue.

Ahí es donde la documentación dejó de sentirse como una guía de depuración para mí. Empezó a responder una pregunta que los desarrolladores a menudo solo se hacen después de que algo se rompe: "¿Qué hará realmente esta política?" En lugar de descubrir la respuesta mediante una transacción fallida, la simulación revela la decisión mientras los cambios aún son seguros y baratos.

Newton también separa las pruebas en diferentes etapas. simulatePolicyData() comprueba si el oráculo devuelve los datos esperados. simulatePolicy() valida el flujo de autorización completo. simulateTask() ayuda a volver a ejecutar tareas existentes durante la depuración. Cada herramienta se centra en un problema en lugar de intentar resolverlo todo.

Una limitación vale la pena tenerla presente. simulateTask() se ejecuta localmente, por lo que no ejercita todo el pipeline del Operator. Los desarrolladores aún necesitan simulatePolicy() para validar el flujo de ejecución completo antes del despliegue.

Mi conclusión es que los sistemas confiables no se construyen evitando errores. Se construyen encontrando la mayoría de los errores antes de que los usuarios los vean.

Fuente: Documentación del Protocolo Newton (Testing & Debugging, Testing Policies & Oracles, SDK Reference). Análisis personal donde se indique explícitamente. NFA.DYOR. #Newt $NEWT @NewtonProtocol

Los certificados de Newton BN254 reducen en silencio el costo de la confianza entre cadenas

Dedico mucho tiempo a leer sobre cómo los activos se mueven entre blockchains. Esta vez termino siguiendo algo diferente. Quiero entender cómo una cadena de destino decide si debe confiar en un resultado sin preguntar a Ethereum cada vez.

Mientras leo la documentación de multichain de Newton, sigo el flujo de certificados en lugar del flujo de activos. Después de que los Operadores evalúan una solicitud y producen una firma agregada BLS, Newton empaqueta el resultado en un Certificado BN254. La cadena de destino verifica ese certificado sin hacer una consulta en vivo de vuelta a Ethereum.

Un detalle mantiene mi atención. La cadena de destino verifica cada Certificado BN254 contra una tabla de Operadores en caché sincronizada desde Ethereum. Combinado con el precompilado BN254 de Ethereum, la verificación se convierte en una comprobación criptográfica local en lugar de otra dependencia entre cadenas.

Eso cambia la forma en que pienso sobre el desarrollo multichain. Los desarrolladores no necesitan un sistema diferente de verificación de confianza para cada cadena admitida. Pueden desplegar un PolicyClient en otra cadena y reutilizar el mismo modelo de confianza de Operadores en lugar de reconstruir la verificación desde cero.
Ese enfoque aún depende de una infraestructura disciplinada. La tabla de Operadores en caché debe mantenerse sincronizada, y las actualizaciones de Operadores deben ocurrir de manera atómica o la verificación del certificado puede fallar.

Después de leer el flujo varias veces, me quedo con una impresión diferente. La parte interesante no es el propio Certificado BN254. Es que Newton trata la confianza como algo que las aplicaciones pueden reutilizar entre cadenas en lugar de reconstruirlo cada vez que se despliegan en algún lugar nuevo.

Fuente: Documentación del protocolo Newton (Multichain Support, Cross-Chain Interoperability & BLS Attestation). Análisis personal. #newt $NEWT @NewtonProtocol