Congelamento, propriedade e autoridade

Fonte mestra EN · P08-L04 · 45 minutos estimados · needs_review

Um selo “propriedade renunciada” pode coexistir com papel ativo de pausa ou controlador de atualização. Autoridade de emissão removida pode coexistir com autoridade de congelamento. Cada declaração pode ser verdadeira enquanto a conclusão ampla “ninguém tem controle” é falsa.

Esta lição ensina um mapa de controle em camadas. Você conectará cada privilégio a seu objeto, detentor atual, condição e possível caminho de administração. O resultado é um registro de evidência, não nota de segurança nem acusação.

Defina o objeto controlado

Não use owner sem um substantivo. Proprietário de programa de uma conta de dados Solana, autoridade de conta de token, owner Ownable EVM e proprietário de posição NFT são campos distintos. Seus nomes se parecem, mas governam mecanismos diferentes. Escreva o campo e o objeto junto ao valor.

Separe controle de saldo do token, restrições no nível do mint, papéis de aplicação e autoridade que altera código. Uma conclusão sobre uma camada não pode apagar uma permissão de outra. Por exemplo, um mint de token pode não ter autoridade de emissão enquanto uma aplicação que interage com o token permanece atualizável. Revise o papel da aplicação separadamente em vez de supor que governa o próprio Token Program padrão.

Um mapa de controle é um grafo de capacidades, não de identidades humanas. Uma autoridade listada pode ser conta de usuário ou endereço mediado por programa. Rótulos públicos de contas não estabelecem quem tem as chaves ou se múltiplas contas compartilham controlador.

Entenda congelamento como restrição de estado

O mecanismo de congelamento da Solana preserva proprietário, mint e saldo da conta de token, impedindo as operações documentadas de recebimento, transferência e queima até o descongelamento [S08-FREEZE]. Não é exclusão de saldo nem transferência à autoridade de congelamento.

Estado e autoridade devem ser registrados separadamente. Uma autoridade de congelamento pode existir enquanto uma conta está descongelada. Por outro lado, observar estado congelado não diz que um humano específico o causou. Solicite a operação bem-sucedida e sua autorização se atribuição importar.

Revogação remove um papel selecionado de autoridade, não uma coleção universal de poderes [S08-SET]. Não suponha que revogação do papel de emissão mudou estado de congelamento. Contas já congeladas e possíveis caminhos de recuperação/descongelamento precisam de exame próprio; evite descrever uma revogação restrita como prova de que toda conta pode transferir.

Inspecione papéis da aplicação além de Ownable

Renúncia Ownable OpenZeppelin desabilita funções protegidas por sua verificação de owner, enquanto permissões baseadas em papéis são um padrão separado [S08-ACCESS]. Se um token implantado combina esses padrões é questão de código e estado. Se um papel de pausa permanece, renunciar ao owner sozinho não pode removê-lo.

Construa tabela de propriedade, pausa, concessão/revogação de papéis e atualizações. Para cada linha, registre verificação real, autoridade presente, caminho de administração e incerteza. Um nome de papel é apenas descritivo até ser ligado a operação alcançável. “PAUSER” em metadados não prova uma função de pausa.

Um controle pode depender de timelock ou multisig. Verifique contrato relevante, limiar, atraso e condições de contorno em vez de aceitar um selo. Um atraso é condição temporal, não desaparecimento do controle. Um limiar multisig descreve assinaturas, não necessariamente humanos independentes.

Trace controle de proxy e implementação

Para proxies estilo ERC-1967, distinga ligação de implementação ou beacon do slot opcional de administrador. Um beacon resolve lógica para proxies associados; autorização estilo UUPS pode residir na lógica da implementação, portanto slot de administrador vazio sozinho não é conclusão completa [S08-PROXY; S08-UUPS].

O endereço de um proxy voltado ao usuário pode permanecer igual quando suas regras mudam. Fixe a implementação ao contexto revisado e depois inspecione o caminho capaz de mudá-la. Não audite uma página de implementação verificada deixando a ligação do proxy sem verificação. Uma implementação posterior pode invalidar premissas anteriores de comportamento.

Esta lição não ensina execução de atualizações. Ensina a descrever o caminho de autorização fornecido somente de leitura. Se as regras internas do controlador estiverem indisponíveis, marque-as como desconhecidas mesmo quando o endereço externo da autoridade é conhecido.

Distinga atualizações de programas Solana de papéis do mint

Sob loader-v3 da Solana, atualizações de programa dependem da autoridade de atualização; remover essa autoridade torna aquele programa imutável [S08-DEPLOY]. Isso não é o campo de autoridade de emissão do mint. Aplica-se ao programa e mecanismo de loader revisados, não a todo contrato conectado ou serviço fora da cadeia.

Um mint governado pelo Token Program padrão não deve ser casualmente descrito como atualizável de forma independente só porque uma aplicação personalizada o usa. Nomeie o programa personalizado e explique sua relevância. No conjunto de dados, PROGRAM-X é aplicação auxiliar, não o Token Program proprietário de MINT-F.

Imutabilidade é delimitada ao objeto de código. Não prova usuários honestos, metadados imutáveis, liquidez suficiente ou sistemas ao redor seguros. Da mesma forma, autoridade de atualização ativa prova capacidade sob condições, não que o código mudará maliciosamente.

Relate um resultado em camadas

Uma frase defensável nomeia contexto e limites: “Em S0 o campo owner está renunciado, enquanto PAUSER permanece atribuído e o controlador de atualização do proxy é fornecido, mas seu limiar interno é desconhecido.” Isso informa mais que um rótulo categórico “descentralizado”.

Pergunte se uma afirmação pode ser refutada por uma linha restante. “Nenhum controle privilegiado” é contradito por uma capacidade ativa comprovada. Uma afirmação restrita como “o papel de owner Ownable está ausente” pode continuar sustentada mesmo quando a ampla falha. Preserve ambas.

• Estado de congelamento: restrição de operações em uma conta de token.
• Owner Ownable: autoridade sob um padrão específico de verificação de owner.
• Detentor de papel: conta que satisfaz uma verificação específica de participação.
• Controlador de atualização: autoridade que governa um caminho de mudança de código.
• Beacon: mecanismo de ligação de lógica do proxy.
• Timelock: condição que impõe atraso a operações especificadas.

ILLUSTRATIVE — FIX-P08-04. Objetos fictícios separados em S0.

PROGRAM-X não é o Token Program que governa MINT-F. O conjunto de dados não fornece efeitos do código que conectam essa aplicação auxiliar ao mint.

OBSERVED no conjunto de dados: F permanece, V está congelada, P/G permanecem e C/U são autoridades de atualização fornecidas.

INFERRED: “Todos os controles removidos” é contradito por essas capacidades separadas. Owner renunciado é uma declaração mais restrita sustentada sobre P2.

UNKNOWN: Regras internas de C, controladores humanos, quem congelou V e efeitos exatos da aplicação PROGRAM-X.

INSUFFICIENT EVIDENCE: Congelamento não significa destruição do saldo de V. Owner ausente não prova ausência de papéis ou atualizações. U não prova que o Token Program padrão é controlado por U.

Usar owner sem seu objeto; confundir saldo congelado com zero; supor que slot de administrador de proxy vazio exclui todas as atualizações; interpretar rótulo multisig como controle independente verificado; fundir autoridade de programa auxiliar com autoridade de mint.

Produza quatro camadas de controle: estado da conta, papéis do mint, papéis da aplicação EVM e caminhos de mudança de implementação. Reescreva “toda propriedade foi renunciada, então tudo é imutável”. Liste a próxima evidência necessária para C e V.

• Nomeie o objeto de cada campo owner.
• Separe autoridade de estado atual.
• Inspecione papéis após renúncia de propriedade.
• Resolva lógica e caminhos de atualização no mesmo contexto.
• Verifique limiares/atrasos em vez de rótulos.
• Delimite imutabilidade ao objeto revisado.

Controle tem camadas. Um papel removido estabelece um fato restrito; papéis ativos e caminhos de mudança de código precisam de revisão separada.

Congelamento é restrição, não exclusão. Renúncia de owner não é renúncia de todo controle. Autoridades de proxy, programa e mint são distintas.

Mapa de permissões em quatro faixas com referências F1–F3,P1–P3,X1; mostre saldo congelado inalterado 50. Desenhe PROXY-Q→LOGIC-Q e controlador C separado; PROGRAM-X/U isolado de MINT-F. Marque configuração de C como desconhecida.

Controles em camadas ilustrativos; ausência de owner é uma afirmação restrita.

Use SVG/HTML determinístico ou gráficos com alternativas textuais, azul-marinho escuro/preto e ciano, azul elétrico e violeta discretos. Rotule cada quantidade e incerteza. Em 390px empilhe painéis; a verificação em 768px/desktop e RTL árabe permanece trabalho futuro dos recursos visuais. Mantenha identificadores em LTR e eixos factuais/direções das arestas inalterados. Use apenas a marca oficial BlockAssay fornecida se identidade visual for adicionada. Ambos os registros são especificações, não recursos entregues.

Use RADAR para o propósito educacional delimitado da lição somente se suporte à rede, identidade exata, campos e procedência forem verificados. Nenhum endpoint de runtime ou capacidade de provedor é afirmado por este conteúdo. Use o conjunto de dados offline incorporado sem acesso pago. Dados ausentes permanecem desconhecidos; nenhuma conexão de carteira, assinatura de transação, lançamento de token ou operação ao vivo é necessária. Progresso na Academy, pagamentos e indicações nunca mudam evidências do Radar. Um Passaporte Diagnóstico preserva observações e limites, não uma previsão de preço ou certificado de segurança.

• Proxy OpenZeppelin 5.x — Mecanismos de atualização Transparent, beacon e UUPS baseados em implementação; a autorização real exige inspeção. Verificada em 2026-09-30.
• Congelar conta na Solana — Restrições do estado da conta distintas do valor ou da propriedade. Verificada em 2026-09-30.
• Definir autoridade na Solana — Mudanças e revogação específicas de cada papel; não é veredito global de segurança. Verificada em 2026-09-30.
• Controle de acesso OpenZeppelin 5.x — Padrões Ownable e de privilégios baseados em papéis; inspecionar a autorização realmente implantada. Verificada em 2026-09-30.
• Slots de armazenamento de proxy ERC-1967 — Slots de implementação, beacon e administrador opcional; inspeção específica do mecanismo. Verificada em 2026-09-30.
• Implantação de programas na Solana — Autoridade de atualização de programa Loader-v3; não é um papel do mint de token. Verificada em 2026-09-30.

A documentação apoia mecanismos, não valores fictícios do conjunto de dados. Todos os exemplos e registros dos exercícios são material ILLUSTRATIVE original, fixado neste arquivo. S0/S1 são rótulos de contexto sintéticos; observedAt é null porque nenhuma medição de registro ao vivo ou histórico foi coletada. Revise novamente a documentação e o comportamento realmente implantado antes de qualquer publicação ou integração.

P08-L05 após o exercício resolvido e a revisão do quiz.