0xr1

Retírate de las características individuales, y la propuesta real de NewtonProtocol es eliminar una categoría de confianza ciega de la que la financiación on-chain ha dependido en silencio durante años. Los vaults piden a los depositantes que confíen en que las reglas de riesgo fuera de la cadena realmente se están cumpliendo. Los emisores de stablecoins le piden a reguladores y usuarios que confíen en que las verificaciones de cumplimiento están ocurriendo en algún lugar detrás de escena. Los agentes de IA piden que todos confíen en que un prompt del sistema es un sustituto adecuado de una barrera técnica estricta.
La respuesta de Newton en las tres situaciones sigue el mismo patrón: representar la acción como una intención, evaluarla frente a una política transparente y auditable a través de una red descentralizada de operadores, y solo continuar una vez que una atestación criptográfica confirme que la política se aplicó realmente, y no solo se afirmó. Ya sea que esa política codifique límites de riesgo de los vaults, el filtrado de sanciones o el tope de gasto de un agente de IA, el mecanismo de aplicación subyacente es la misma capa verificable.

El modelo de seguridad económica de NewtonProtocol se basa en que los operadores tienen intereses reales en juego. Los operadores apuestan NEWT para unirse a la red y ganar comisiones por evaluar políticas: comisiones que se distribuyen de forma proporcional en función de la contribución real, incluida la computación en WASM, las llamadas a proveedores de datos externos y el ancho de banda utilizado, no solo una división fija y plana por operador.
Esa misma apuesta es lo que se reduce si un operador se comporta mal: presentar una atestación inválida, desconectarse cuando no debería, o, de otro modo, fallar en hacer su trabajo correctamente. Los retadores añaden otra capa de rendición de cuentas: pueden apostar NEWT específicamente para disputar la evaluación de un operador durante una ventana de desafío y, si la disputa se resuelve a su favor, el retador es recompensado mientras el operador sufre una penalización por reducción.

Uno de los problemas más difíciles en la aplicación de políticas en cadena es gestionar datos que solo existen fuera de la cadena, en una sesión web normal — como el número de seguidores de una red social — sin simplemente confiar en quien los informa. El enfoque de zkTLS de NewtonProtocol aborda esto con pruebas de TLSNotary: un flujo basado en el navegador genera una prueba criptográfica de una sesión TLS real (por ejemplo, una solicitud a un endpoint de la API de Twitter/X), y esa prueba se almacena y se referencia mediante un identificador de contenido.
Esa prueba, junto con las entradas de política que admite, se envía como una tarea de Newton junto con una intención de transacción, y la política la evalúa — verificando, por ejemplo, si el número de seguidores de una cuenta supera un umbral configurado — antes de decidir si aprueba la transacción asociada. El proceso de recuperación de la prueba vuelve a verificar que los bytes devueltos coinciden realmente con el identificador de contenido esperado, de modo que una pasarela comprometida o mal configurada no pueda reemplazar en silencio datos distintos.