Algo sobre o zkPermissions do Newton Protocol tem me incomodado: a palavra "revogável."
A ideia é que os usuários concedem aos agentes permissões escopadas e revogáveis em vez de entregarem chaves privadas. Isso é uma melhoria real em relação à delegação cega. Mas revogável quando, exatamente?
Se um agente já enviou uma intenção de automação e ela está na fila aguardando um operador, aguardando atestação do TEE, aguardando confirmação do validador: a revogação da permissão interrompe aquela ação específica no meio do caminho, ou apenas bloqueia a próxima? As chaves de sessão e as atualizações de permissão ficam no rollup do Keystore, que tem seus próprios tempos de bloco e finalização. Existe uma janela, mesmo que pequena, entre "o usuário decide revogar" e "o estado da permissão realmente atualizar onchain."
Para automações de baixo risco, como compras de DCA, provavelmente isso não importa. Para qualquer coisa sensível ao tempo ou de alto valor, pode importar.
@NewtonProtocol $NEWT #Newt
A ideia é que os usuários concedem aos agentes permissões escopadas e revogáveis em vez de entregarem chaves privadas. Isso é uma melhoria real em relação à delegação cega. Mas revogável quando, exatamente?
Se um agente já enviou uma intenção de automação e ela está na fila aguardando um operador, aguardando atestação do TEE, aguardando confirmação do validador: a revogação da permissão interrompe aquela ação específica no meio do caminho, ou apenas bloqueia a próxima? As chaves de sessão e as atualizações de permissão ficam no rollup do Keystore, que tem seus próprios tempos de bloco e finalização. Existe uma janela, mesmo que pequena, entre "o usuário decide revogar" e "o estado da permissão realmente atualizar onchain."
Para automações de baixo risco, como compras de DCA, provavelmente isso não importa. Para qualquer coisa sensível ao tempo ou de alto valor, pode importar.
@NewtonProtocol $NEWT #Newt