Aprovações, permissões de gasto e revogação

Fonte mestra EN · P03-L04 · needs_review

Apenas estudo offline/somente leitura. Nunca forneça segredos, senhas ou códigos de autenticação. Sem conexão de carteira, aprovação real, revogação em tempo real, assinatura de transação, transferência, fundos ou operação. Recursos visuais são apenas especificações.

Permissões são específicas de ativo/destinatário da permissão de gasto/contexto. Permissão zero pode sustentar resultado útil enquanto outros tokens e autorizações assinadas permanecem não resolvidos.

Nomear tupla completa

ERC-20 descreve semântica de allowance, approve e transferFrom [ERC20]. Linha de permissão precisa de rede, token, proprietário, destinatário da permissão de gasto e contexto de observação. Token diferente é permissão diferente mesmo quando destinatário exibido é idêntico.

Ler estado em vez de rótulos de sessão

R1/R3 mostram mesma tupla em dois contextos estipulados. R2 mostra desconexão da interface; não descreve mudança de estado de contrato de token. Revogação solicitada, ação enviada e estado resultante seriam etapas separadas de evidência. R3 é fornecido offline; aluno não deve enviar revogação em tempo real.

R4 trata de TOKEN-B e não pode ser fundido à linha de TOKEN-A. Relatar apenas zero tranquilizador omitindo outra linha perderia alcance material. Preserve ambos os valores e explique qual pergunta cada um responde.

Manter autorizações assinadas não resolvidas quando necessário

Permit tem semântica separada de assinatura/nonce/prazo sob regras aplicáveis de contrato [PERMIT]. R5 omite deliberadamente relação com estado atual de nonce/consumo. Uma permissão zero não estabelece que toda assinatura pendente seja invalidada. Próxima verificação exigida são regras aplicáveis e estado relevante, não outra transação de aula em tempo real.

Estado de permissão também não reverte transferência anterior nem estabelece que proprietário nunca expôs material de recuperação. Inventário de permissões e exposição de capacidade de assinatura são perguntas distintas de pesquisa.

Declarar resultados restritos

OBSERVED: valores dos dados do exercício e estado da sessão. INFERRED: mudança da tupla selecionada de 100 para zero. UNKNOWN: inventário completo de permissões e viabilidade de R5. INSUFFICIENT EVIDENCE: «todos os ativos estão seguros». Conclusão delimitada nomeia tupla selecionada em H12 e deixa linhas separadas não resolvidas.

• Permissão de gasto: valor de permissão com alcance delimitado.
• Destinatário da permissão de gasto: papel aplicável de autorização.
• Evidência de revogação: estado resultante de permissão em contexto.
• Cobertura: linhas de permissão efetivamente fornecidas.

ILLUSTRATIVE cartões. R1 SIM-N/TOKEN-A/OWNER-X/SPENDER-Y em SIM-H10 permissão de gasto 100 unidades inteiras do exercício. R2 interface desconectada em T1. R3 mesma tupla H12 permissão de gasto 0. R4 TOKEN-B/mesmo proprietário/destinatário da permissão de gasto H12 permissão de gasto 80. R5 resumo de permit TOKEN-A com relação atual de nonce/consumo UNKNOWN. Nenhuma aprovação, assinatura ou transação real.

Matriz de tupla/contexto. R1→R3 é comparação selecionada; R4 permanece 80, R5 desconhecido. Colocar R2 numa linha de sessão sem ligação automática a estado na cadeia.

Estados selecionados dos dados do exercício e comparação delimitada.

Revogação em tempo real, redefinição completa de permissões, invalidação de todos os permits, reversão de perda ou segurança garantida.

• Chamar desconexão de revogação.
• Generalizar um zero a todo token.
• Presumir que estado zero cancela toda assinatura.

Construa linhas de permissão R1/R3/R4. Explique limites de R2 e R5. Reescreva «desconexão e zero tornam todo ativo seguro».

Entregue tabela e conclusão delimitada usando apenas material offline fornecido. Distribuição editorial: estudo 12 min, exercício 8 min, correção/questionário 10 min.

• Tupla/contexto completos.
• Sessão e estado separados.
• Solicitações e resultados separados.
• Tokens diferentes mantidos distintos.
• Nomear lacunas de assinaturas pendentes.

Resultado de permissão é contextual. Desconexão e uma permissão zero não estabelecem redefinição abrangente de autorizações nem segurança de ativos.

• Inspecionar destinatário da permissão de gasto, quantidade e limites de revogação
• Ler tuplas completas de permissão de gasto e contextos.
• Delimitar um estado zero sem afirmar redefinição de todas as autorizações.

P03-L05 após revisar pré-requisitos e correção.

NONE no catálogo autoritativo. Dados offline fornecidos bastam; não exige compra de produto nem operação de carteira.

• [ERC20] Padrão de token ERC-20 — approve, allowance e transferFrom para interfaces conformes.
• [PERMIT] ERC-2612 aprovações assinadas — Autorização de permissão por permit com owner, spender, value, nonce e deadline.

Documentação explica mecanismos. Registros históricos mantêm classe de fonte declarada. Inspeção de fonte não é aceitação editorial independente.