Algo sobre las zkPermissions del protocolo de Newton me ha estado inquietando: la palabra «revocable.»
La idea es que los usuarios otorgan permisos a agentes con alcance y revocables en lugar de entregar claves privadas. Eso es una mejora real frente a la delegación ciega. Pero, ¿revocable en qué momento, exactamente?
Si un agente ya envió una intención de automatización y está en la cola esperando a un operador, esperando la atestación TEE, esperando la confirmación del validador: ¿revocar el permiso detiene esa acción específica a mitad de ejecución, o solo bloquea la siguiente? Las claves de sesión y las actualizaciones de permisos viven en el rollup del Keystore, que tiene sus propios tiempos de bloque y su propia finalidad. Hay una ventana, aunque sea pequeña, entre «el usuario decide revocar» y «el estado del permiso realmente se actualiza en la cadena.»
Para automatizaciones de baja criticidad como compras DCA, probablemente esa ventana no importa. Para cualquier cosa sensible al tiempo o de alto valor, sí podría.
@NewtonProtocol $NEWT #Newt
La idea es que los usuarios otorgan permisos a agentes con alcance y revocables en lugar de entregar claves privadas. Eso es una mejora real frente a la delegación ciega. Pero, ¿revocable en qué momento, exactamente?
Si un agente ya envió una intención de automatización y está en la cola esperando a un operador, esperando la atestación TEE, esperando la confirmación del validador: ¿revocar el permiso detiene esa acción específica a mitad de ejecución, o solo bloquea la siguiente? Las claves de sesión y las actualizaciones de permisos viven en el rollup del Keystore, que tiene sus propios tiempos de bloque y su propia finalidad. Hay una ventana, aunque sea pequeña, entre «el usuario decide revocar» y «el estado del permiso realmente se actualiza en la cadena.»
Para automatizaciones de baja criticidad como compras DCA, probablemente esa ventana no importa. Para cualquier cosa sensible al tiempo o de alto valor, sí podría.
@NewtonProtocol $NEWT #Newt