HeartlessX

La Propuesta Responde una Pregunta que no Estaba Haciendo

Abro la propuesta esperando entender cómo el Bitcoin nativo llega a Aave V4. En cambio, me sigo deteniendo en las mismas páginas. No se apresuran con el préstamo. Dedican tiempo a explicar la bóveda.

Al principio no entiendo por qué.

Si el destino es Aave, ¿por qué empezar con reglas de bloqueo de Bitcoin, bóvedas independientes y pruebas? Una explicación más breve podría haber funcionado. La propuesta no toma ese atajo.

Así que dejo de leerla, por un tiempo, como una propuesta de préstamo y empiezo a leerla como un diseño de bóveda.

Hay algo que no deja de aparecer. Cada usuario obtiene una bóveda independiente. Sin Bitcoin en grupo. Sin claves compartidas. La propuesta nunca se detiene a defender esa elección, pero construye todo silenciosamente sobre ella.

Luego los números hacen que esa decisión parezca aún más grande.

Babylon ya asegura 56,853 BTC, y la propuesta le pide a Aave V4 que acepte Bitcoin nativo a través de esa misma arquitectura en lugar de BTC envuelto. La bóveda ya no es una función separada. Decide cómo llega el Bitcoin a DeFi desde el principio.

La propuesta aún está en revisión, así que hoy no cambia nada.

Pero termino de leerla con una pregunta distinta a la que empecé.

Quería saber cómo el Bitcoin se convierte en colateral.

Ahora me pregunto si alguna vez el Bitcoin necesitó convertirse en otro activo antes de volverse colateral. #baby $BABY @BabylonLabs_io

TBV No es un puente. Es un modelo de confianza completamente diferente.

Casi me pierdo la parte que terminó sintiéndose como la más importante.

Al principio, estaba prestando más atención al lado del préstamo. Normalmente, ahí es donde se va mi enfoque. Luego noté algo extraño. Los documentos seguían volviendo una y otra vez a un mismo tema: quién controla el Bitcoin.

Eso me hizo frenar.

La mayoría de los proyectos de DeFi de Bitcoin pasan mucho tiempo explicando lo que puedes hacer con tu BTC después de que sale de Bitcoin. Aquí, sentí que la conversación más importante estaba ocurriendo antes de todo eso. El Bitcoin se queda en Bitcoin. Las reglas ya están ahí antes de que ocurra cualquier movimiento. Tal vez por eso llamar a TBV un puente nunca me pareció del todo correcto.

No estoy diciendo que los riesgos desaparezcan. No desaparecen. Los documentos son bastante claros al respecto. Hay controles, periodos de espera y todo el sistema aún tiene que funcionar como se supone. En realidad, lo encontré tranquilizador porque no se sentía como el típico mensaje de "solo confía en nosotros".

La parte de los préstamos es útil. Entiendo por qué está recibiendo atención.

Solo no creo que sea lo primero que voy a recordar.

Lo que se me quedó fue una idea mucho más simple. En vez de preguntar: "¿Cómo movemos el Bitcoin hacia DeFi?", TBV parece preguntar: "¿Podemos mantener el Bitcoin donde está y aun así hacerlo útil?"

Esa pregunta se quedó en mi cabeza mucho después de terminar de leer los documentos. #baby $BABY @BabylonLabs_io

Salman49

Salman49

Salman49

afirmación

Sigo notando el mismo patrón cada vez que los desarrolladores integran una API externa. La aplicación necesita una clave de API, así que la clave de API normalmente termina viviendo dentro de la infraestructura de la aplicación. Usar un secreto de forma silenciosa se convierte, en la práctica, en lo mismo que poseerlo.

Mientras leo el flujo de gestión de secretos de Newton, noto un enfoque diferente. Los desarrolladores cifran los secretos con HPKE antes de que esos secretos salgan de su propia máquina. La puerta de enlace (Gateway) nunca recibe texto sin cifrar, y ningún operador individual tiene la clave de descifrado completa. El secreto está protegido mucho antes de que algún oráculo necesite usarlo.

Una parte del flujo de ejecución mantiene mi atención un poco más. Cuando una política necesita una clave de API, los operadores reconstruyen el secreto solo dentro del entorno de ejecución WASM. El oráculo recibe el valor decodificado únicamente durante la duración de esa ejecución, y el material descifrado desaparece de la memoria en cuanto la tarea finaliza.

Así lo veo: eso cambia la relación entre las aplicaciones y las credenciales. Un oráculo puede llamar a un servicio externo sin poseer permanentemente la clave de API que hace posible la solicitud. El acceso se vuelve temporal, mientras que la propiedad permanece separada de la infraestructura que realiza el trabajo.

También noto que este modelo les pide a los desarrolladores pensar de forma distinta sobre la gestión de secretos. Los secretos permanecen vinculados a un despliegue específico de PolicyData; por lo tanto, actualizar o redeployar la política implica cargar nuevamente los secretos cifrados. El trabajo operativo no desaparece. Se desplaza hacia gestionar el ciclo de vida del secreto con más intención.

Lo que se me queda no es HPKE ni la criptografía por umbral. Para mí, la idea más interesante es que Newton trata las credenciales sensibles como algo que la infraestructura puede usar brevemente sin llegar realmente a poseerlas. Esa pequeña decisión arquitectónica podría, de manera discreta, reducir la exposición de credenciales en todo el ecosistema de oráculos. @NewtonProtocol $NEWT #Newt

Las atestaciones de Newton convierten la aprobación en prueba

La mayoría de las transacciones en blockchain son fáciles de verificar después de que ocurren. La aprobación que hay detrás de esas transacciones, por lo general, no lo es. Puedes ver que ese valor se movió, pero probar quién la autorizó, bajo qué política, y si esa aprobación seguía siendo válida en el momento de la ejecución es una pregunta mucho más difícil.

Newton aborda las aprobaciones de forma diferente. En lugar de tratarlas como señales temporales, su sistema de atestación las convierte en evidencia criptográfica. Antes de la ejecución, PolicyClient verifica que la atestación coincide con la tarea correcta, la política, la aplicación, el quórum del operador y la ventana de validez. Si alguna de esas condiciones falla, la transacción no se ejecuta.

La consecuencia interesante no es un paso de verificación adicional. Cambia lo que los operadores optimizan. Una aprobación descuidada ya no es algo que la red simplemente olvida después de la ejecución. Cada atestación se puede comprobar más tarde, y las aprobaciones incorrectas o contradictorias exponen a los operadores a slashing. La estrategia más segura pasa a ser producir decisiones que sigan siendo defendibles mucho después de que la transacción termine.

Eso establece un estándar distinto para la rendición de cuentas de la red. La confianza se desplaza gradualmente de recordar quién aprobó algo hacia verificar de manera independiente que la aprobación realmente siguió la política requerida.

Por supuesto, garantías más sólidas vienen con trabajo de ingeniería adicional. Coordinar firmas BLS, validar atestaciones y gestionar ventanas de expiración hace que el sistema sea más complejo. El intercambio es directo: infraestructura más simple o evidencia más sólida.

La parte sobre la que sigo pensando no es que las transacciones se vuelvan más fáciles de verificar. Es que las aprobaciones dejan de ser promesas hechas por los operadores y empiezan a convertirse en una prueba que la red puede comprobar de forma independiente.

Fuente: Documentación del Protocolo Newton (Sistema de atestación, Firmas BLS, AttestationValidator & Expiration Blocks). Análisis personal. #newt $NEWT @NewtonProtocol

La composición de servicios podría hacer que los modelos gigantes sean menos importantes

Abrí la documentación de Newton esperando pasar la mayor parte de mi tiempo mirando la Composición de Servicios en sí. Eso no fue lo que quedó en mis notas.

Lo que seguí retomando fue lo rápido que un solo servicio deja de necesitar hacerlo todo. Uno podía planificar. Otro podía comprobar. Otro podía ejecutar. Ninguno de ellos parecía estar completo por sí solo, pero el flujo de trabajo sí.

Ese fue el momento en que algo encajó para mí. Dejé de buscar el servicio más fuerte de la cadena. Empecé a prestar atención al que, en silencio, se volvió imposible de eliminar. Si quitar un servicio empeora todo el flujo de trabajo, su valor ya no proviene del tamaño. Proviene de su ubicación.

Lo anoté porque fue cambiando la forma en que miraba modelos más grandes. De pronto, el tamaño pareció menos interesante que la posición. Un servicio más pequeño del que depende cada flujo de trabajo podría acabar importando más que uno más grande que intenta hacerlo todo por sí mismo.

Cerré la documentación de Newton pensando menos en la Composición de Servicios y más en la dependencia. El servicio que gana podría no ser el que más sabe. Podría ser el que el resto del flujo de trabajo rechaza silenciosamente para funcionar sin él.

Fuente: documentación del Protocolo Newton. Este es mi análisis personal basado en la Composición de Servicios. No es asesoramiento financiero. Infórmate por tu cuenta. #newt $NEWT @NewtonProtocol $POWER $EVAA

El problema del “Agente Fantasma” en el registro de modelos de Newton

He estado revisando el Registro de Modelos del protocolo Newton y creo que hay un problema que deberíamos abordar pronto. Lo llamaré el problema del “Agente Fantasma”.

El Registro de Modelos es donde los desarrolladores listan agentes de IA. Para listar un agente pagas una tarifa de registro en NEWT. Los operadores también ponen en garantía NEWT para ejecutar tareas. La idea es sencilla. Los buenos agentes ganan comisiones. Los malos son penalizados. Con el tiempo, el mercado elimina los servicios deficientes.

Pero aquí está la brecha que veo. ¿Y si pago la tarifa y nunca ejecuto el agente? No pongo en garantía a ningún operador. No ejecuto ninguna tarea. Solo lo dejo listado en el registro.

¿Por qué alguien haría eso? Para ocupar un nombre. Para crear ruido. Para dificultar que se encuentren agentes reales. Lo llamaré “Agent Squatting” (acaparamiento de agentes).

Ahora mismo no veo ninguna regla pública que diga que hay que retirar un agente si no se utiliza. Así que puede permanecer en el registro para siempre, con cero ejecuciones. El slashing solo ocurre si hay un operador y una tarea fallida. Sin actividad, no hay nada que penalizar.

Mi propuesta es Prueba de Uso.

Si un agente tiene cero ejecuciones durante 90 días, se le retira automáticamente del registro.

90 días parece justo. Da tiempo a los desarrolladores para encontrar usuarios, pero evita que la gente se quede acaparando nombres indefinidamente.

Esto podría funcionar rastreando last_execution_timestamp en cadena. Después de 90 días de inactividad, se elimina el listado. No hay reembolso de la tarifa, así que hacer spam se vuelve costoso. Puedes volver a listar en cualquier momento pagando la tarifa de nuevo.

Esto no cierra el registro. Solo lo mantiene limpio. Los usuarios ven agentes que realmente se están usando. Los operadores obtienen una mejor señal. Y el acaparamiento se vuelve caro.

Newton quiere ser la capa de coordinación para automatización en cadena. Para eso, el registro debería reflejar agentes que realmente están funcionando, no solo agentes que pagaron una tarifa una vez.

Esto es solo mi punto de vista basado en cómo está diseñado el registro hoy. Pero creo que Prueba de Uso es una regla pequeña que podría prevenir un problema grande a medida que el mercado crece.@NewtonProtocol #newt $NEWT

La característica más valiosa en la IA podría ser un botón de cancelar
Hay una idea que no deja de volver cuando leo sobre agentes de IA. Pasamos una cantidad increíble de tiempo discutiendo cuánta autoridad debería recibir un agente. Rara vez veo que se le preste una atención igual a la pregunta contraria: ¿qué tan fácil debería ser que esa autoridad desaparezca?
Cuanto más lo pienso, más creo que la autoridad permanente es un atajo de diseño. Resulta conveniente hasta que el mundo cambia. La intención del usuario cambia. El riesgo cambia. Las prioridades cambian. Un sistema de IA que solo puede ganar autoridad, pero le cuesta perderla, se va alejando lentamente de la persona a la que debería representar.
Esa fue la parte de Newton que se me quedó grabada. Su mecanismo de revocación de permisos no es solo otra función de seguridad. Trata la autoridad, en silencio, como algo temporal en lugar de permanente. Para mí, esa es una filosofía diferente. La confianza deja de ser una decisión única y empieza a convertirse en algo que puede evolucionar cada vez que el usuario cambia de opinión.
Creo que esta idea va mucho más allá de un solo protocolo. A medida que los agentes de IA empiecen a gestionar pagos, inversiones y decisiones cotidianas, la inteligencia sola no determinará si la gente confía en ellos. La capacidad de retirar la autoridad sin fricción podría volverse igual de importante que la capacidad de concederla por primera vez.
Por supuesto, los sistemas reversibles introducen una coordinación adicional y la gestión del estado. La simplicidad suele favorecer los permisos permanentes. La seguridad rara vez.
Empiezo a pensar que el futuro no pertenecerá a la IA con más autoridad. Pertenecerá a la IA que sabe que su autoridad siempre está en préstamo, nunca es propia.@NewtonProtocol #newt $NEWT $VANRY $BLUR