Assinaturas, mensagens e transações

Fonte mestra EN · P03-L03 · 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.

Legenda de solicitação pode dizer login enquanto campos autorizam gasto. Solicitação efetiva e evidência de execução posterior devem ser avaliadas separadamente.

Classificar autorização

Transações carregam instruções assinadas [ETH_TX]. Mensagens também podem autorizar ações da aplicação. EIP-712 define assinatura estruturada e contexto de domínio; tratamento de repetição permanece responsabilidade da aplicação [TYPED]. ERC-2612 fornece mecanismo de permissão assinada usando owner, spender, value, nonce e deadline [PERMIT]. Nenhuma assinatura é criada nesta lição.

Comparar três resumos offline

R1 estipula declaração de tipo login, R2 solicitação em formato permit e R3 solicitação de transferência. Legenda de login de R2 não remove campos spender/value. R1 não tem autoridade estipulada sobre ativos, mas inocuidade fora do exercício simplificado não é estabelecida. Botão genérico de assinatura não responde como aplicação aceitará conteúdo assinado.

Preservar alcance

Leia rede/domínio, contrato verificador, autoridade, destinatário da permissão de gasto, quantidade, nonce e prazo quando aplicável. Se ausentes, registre UNKNOWN em vez de emprestar campos de outro cartão. Campo de nome familiar de domínio não é autenticação independente de projeto. Nonce e expiração precisam das regras da aplicação aceitante; formato sozinho não é política completa de segurança.

Um permit pode ser enviado por outra parte sob regras relevantes do contrato. Portanto, ausência de transação de gas enviada pelo signatário não prova que mensagem não possa autorizar permissão. Inversamente, solicitação exibida de permit não prova que qualquer assinatura exista ou tenha sido consumida.

Manter etapas no relatório

Solicitada, assinada, enviada e executada são linhas separadas. Aqui somente solicitações são fornecidas. OBSERVED: resumos e legendas. INFERRED: classificação sob esquemas estipulados. UNKNOWN: produção de assinatura e execução. INSUFFICIENT EVIDENCE: perda, intenção maliciosa ou identidade humana. Avalie capacidade sem fazer acusação e pare sem assinar nada.

• Mensagem tipada: conteúdo estruturado de assinatura.
• Permit: mecanismo aplicável de aprovação assinada.
• Separação de domínio: contexto de alcance, não prova de identidade.
• Nonce: valor conferido contra estado do contrato aceitante para distinguir autorizações; ERC-2612 incrementa nonce do proprietário após permit bem-sucedido.
• Prazo: último momento em que permit ERC-2612 pode ser aceito sob suas regras, não garantia de execução.
• Consumo: uso de autorização pela aplicação/contrato.

ILLUSTRATIVE resumos higienizados, não cargas úteis assináveis. R1 login/SIM-LOGIN/SIM-CHALLENGE, nenhuma permissão sobre ativos estipulada. R2 legenda login, tipo Permit, owner SIM-A, spender SIM-S, value 500 unidades inteiras do exercício, nonce 4, deadline SIM-T3, domínio SIM-N/contrato SIM-C. R3 solicitação de transferência de 7 unidades SIM para SIM-B em SIM-N. Nenhuma assinatura, calldata ou recibo.

Matriz de permissões: legenda/tipo/alcance/evidência de execução. Destacar R2 Permit/SIM-S/500 apesar de legenda login. Todos os cartões param antes da assinatura; nenhuma carga útil utilizável nem botão de transação.

Campos de solicitação e classificações estipuladas de capacidade.

Assinatura, inclusão, perda de ativos, proteção completa contra repetição ou intenção humana maliciosa.

• Chamar todas as mensagens de login inofensivo.
• Interpretar ausência de gas como ausência de autoridade.
• Equiparar exibição de solicitação a execução.

Classifique R1–R3 e liste campos de autoridade de R2. Preencha linhas solicitada/assinada/enviada/executada e especifique registro ausente necessário para execução.

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.

• Ler campos antes da legenda.
• Registrar contrato/rede/destinatário da permissão de gasto/quantidade.
• Manter contexto de nonce/expiração.
• Separar quatro etapas.
• Nunca assinar como exercício.

Assinatura de mensagem pode autorizar ações com consequências. Inspeção de capacidade não prova execução nem estabelece independentemente intenção maliciosa.

• Distinguir assinatura de mensagem de instruções que alteram ativos
• Ler campos de mensagens que carregam aprovação.
• Separar etapas solicitada, assinada, enviada e executada.

P03-L04 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.

• [TYPED] EIP-712 assinatura estruturada tipada — Campos de assinatura estruturada/domínio; proteções contra repetição da aplicação permanecem separadas.
• [PERMIT] ERC-2612 aprovações assinadas — Autorização de permissão por permit com owner, spender, value, nonce e deadline.
• [ETH_TX] Transações Ethereum — Instruções assinadas e inclusão distinta de envio.

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