Guia de Segurança Web3 para Iniciantes

A segurança na Web3 diz respeito a como uma aplicação completa lida com identidade, permissões, comportamento de programas, registros compartilhados e informações externas. Uma blockchain pode fazer parte dessa aplicação sem ser a aplicação inteira. Sites, interfaces de conta, endpoints de rede, sistemas de arquivos e processos administrativos podem todos contribuir para o que uma pessoa vê e o que o sistema faz.

Este guia explica essas relações por meio de um arquivo de pesquisa fictício. O arquivo registra versões de documentos e permite que colaboradores designados enviem revisões. É um modelo educacional, sem necessidade de conexão de conta ou transação. O modelo permite discutir as propriedades de segurança com clareza, mantendo a explicação independente de qualquer produto específico.

O que Web3 significa neste guia

Web3 é um termo amplo para aplicações que usam registros baseados em blockchain e relações de contas como parte de seu design. O termo descreve uma família de abordagens em vez de uma única especificação técnica. A introdução da Ethereum aborda descentralização, participação e relações de contas controladas pelo usuário entre suas ideias centrais. Uma aplicação específica ainda precisa de uma descrição concreta de sua arquitetura. A introdução da Ethereum à Web3 fornece o contexto básico.

Um arquivo de pesquisa pode usar uma blockchain para registrar o identificador de cada versão do documento, enquanto um site convencional exibe o documento e um sistema de arquivos externo o armazena. Chamar o arquivo de Web3 não explica quem controla o site, como os arquivos permanecem disponíveis ou quais contas podem aprovar alterações. Esses são fatos adicionais sobre a aplicação real.

A tarefa educacional é, portanto, passar de um rótulo genérico para um mapa. Qual componente registra as informações? Qual componente as apresenta? Qual componente autoriza uma alteração? Uma vez que essas perguntas tenham respostas separadas, o significado da segurança na Web3 se torna mais específico.

Uma aplicação completa tem vários componentes

Uma aplicação descentralizada pode combinar um programa em blockchain com uma interface frontend. Sua interface e seu programa subjacente desempenham papéis diferentes e podem ser hospedados por meio de arranjos distintos. A introdução técnica da Ethereum descreve essa distinção entre a lógica onchain de uma aplicação e a interface por meio da qual as pessoas interagem com ela. A documentação da Ethereum sobre aplicações descentralizadas explica esse modelo.

O arquivo de pesquisa fictício como um mapa de componentes
Componente	Exemplo de responsabilidade	Relação importante
Site	Exibir descrições de documentos	Conectar explicações legíveis aos registros subjacentes
Interface de conta	Apresentar as solicitações de um colaborador	Representar o escopo da autoridade solicitada
Programa em blockchain	Aplicar regras de revisão	Interpretar instruções autorizadas
Rede	Manter o estado aceito	Aplicar regras de protocolo às alterações propostas
Armazenamento de arquivos	Tornar documentos recuperáveis	Manter o conteúdo disponível além de seu identificador

O mapa é deliberadamente mais amplo do que o livro-razão. Uma explicação completa diz respeito às conexões entre essas responsabilidades e às evidências disponíveis para cada uma delas.

As propriedades de segurança podem variar por componente

A integridade questiona se as informações e o comportamento permanecem consistentes com as regras relevantes. A autorização questiona quem ou o que pode solicitar uma ação. A disponibilidade questiona se o componente ou os dados necessários podem ser acessados. A confidencialidade questiona quem pode ler as informações. Uma aplicação pode fornecer uma dessas propriedades de forma robusta em um componente específico e ter um arranjo diferente em outro lugar.

No caso do arquivo, o registro na blockchain pode preservar o identificador de um documento aceito enquanto o arquivo em si fica temporariamente indisponível. A integridade do registro e a disponibilidade do arquivo são questões distintas. O material de assinatura de um colaborador pode ser confidencial enquanto o registro de revisão permanece legível publicamente. A confidencialidade de um item não torna privados todos os itens associados.

Essas distinções tornam as explicações mais úteis do que um único adjetivo tranquilizador. Uma descrição significativa identifica a propriedade, o componente e as premissas. Ela pode, então, explicar como essas premissas se conectam ao restante da aplicação. O resultado é um mapa de responsabilidades em vez de uma avaliação geral sem explicação.

Descentralização é uma questão de controle

A descentralização varia entre sistemas e entre componentes dentro de um sistema. A comparação da Ethereum entre Web2 e Web3 observa que centralização e descentralização estão em um espectro. A distribuição de uma rede, por si só, não descreve a administração ou a disponibilidade de cada aplicação construída em torno dela. A documentação da Ethereum sobre descentralização explica essa ressalva.

No arquivo, muitos computadores poderiam manter o registro aceito enquanto uma única organização mantém o site público. Vários colaboradores poderiam publicar revisões enquanto uma única conta administrativa altera a lista de colaboradores. Um sistema de arquivos distribuído ainda poderia ser acessado por meio de um gateway comumente utilizado. Cada arranjo descreve uma distribuição diferente de responsabilidade.

A palavra descentralizado, portanto, precisa de um sujeito. Ela pode se referir à manutenção de registros, administração de programas, hospedagem de arquivos, publicação de interfaces ou ao caminho usado para recuperar informações. Indicar o sujeito torna a descrição informativa. Contar apenas os participantes não determina se suas decisões, infraestrutura ou fontes originais de informação são independentes.

Identidade, autenticação e permissão

Um identificador de conta, um evento de autenticação e uma permissão são conceitos distintos. Um identificador nomeia uma conta dentro de um sistema. A autenticação estabelece algo sobre a autoridade que participa de uma sessão. A permissão determina quais operações essa autoridade pode realizar. Um sistema pode autenticar um participante com sucesso e, ao mesmo tempo, permitir apenas um conjunto limitado de ações.

Como um exemplo no contexto do Ethereum, o Sign-In with Ethereum utiliza um formato de mensagem estruturado para estabelecer uma relação de autenticação baseada em conta. Seu contexto inclui o site solicitante, em vez de ser uma declaração de uso geral sobre todas as aplicações. A documentação da MetaMask descreve o formato e sua relação de domínio. A documentação da MetaMask sobre autenticação baseada em conta fornece este exemplo específico.

No arquivo, reconhecer a conta de um colaborador não estabelece automaticamente suas qualificações no mundo real nem concede permissão para editar todos os documentos. Essas relações precisariam de suas próprias evidências e regras. Separar reconhecimento, declarações de identidade e autoridade de edição evita que uma verificação bem-sucedida seja interpretada como as três coisas.

Solicitações fazem a ponte entre o significado humano e o comportamento do programa

Uma pessoa lê palavras como confirmar, publicar ou revisar. Um programa recebe dados que representam uma operação. A interface conecta essas duas descrições. A relação entre as palavras e os dados faz parte do design da aplicação e merece uma explicação própria.

Suponha que a página do arquivo descreva uma solicitação proposta como a publicação de um resumo revisado. Os dados subjacentes poderiam incluir um identificador de documento, uma referência de versão e um contexto de permissão. Uma explicação completa identifica como esses campos se relacionam com a descrição visível. Ela não assume que um verbo familiar estabeleça todos os efeitos da instrução proposta.

O registro resultante é outra parte dessa relação. A explicação da página, a instrução autorizada e o resultado aceito são representações distintas. Elas podem coincidir, ou suas diferenças podem revelar uma explicação incompleta. A segurança da Web3 inclui a clareza com que essa relação é representada, juntamente com as regras técnicas usadas para processar a instrução.

Programas podem depender de outros programas

Componibilidade significa que componentes de software separados podem ser combinados em um sistema maior. No Ethereum, uma aplicação pode usar contratos existentes como componentes em vez de conter todas as operações em um único programa. O comportamento da aplicação mais ampla depende dessas relações. A documentação do Ethereum sobre componibilidade de contratos explica o princípio.

O arquivo pode usar um programa para registrar versões de documentos e outro para manter as permissões dos colaboradores. Uma instrução que passa pelo primeiro programa pode depender do estado atual do segundo programa. Uma explicação limitada ao programa de documentos deixaria de fora essa dependência.

Isso não torna a composição inerentemente inadequada. Apenas altera o objeto que está sendo explicado. Um componente pode ter uma função clara, enquanto o sistema completo requer uma descrição mais ampla de entradas, chamadas externas e relações administrativas. Um mapa de dependências mostra quais conclusões dizem respeito a um componente e quais dizem respeito à estrutura como um todo.

A administração continua fazendo parte da arquitetura

Alguns programas incluem funções que podem alterar configurações específicas ou redirecionar a execução para outra implementação. A documentação de atualização do Ethereum distingue a alteração do comportamento da aplicação por meio de padrões de atualização da reescrita do código histórico implantado. Portanto, um endereço de conta estável pode fazer parte de uma aplicação cujo comportamento pode ser alterado sob regras definidas. A documentação do Ethereum sobre atualizações de programas explica os mecanismos.

No arquivo, uma autoridade designada pode ser capaz de alterar o formato de revisão permitido. Outra função pode gerenciar quais contas podem publicar. Esses são poderes diferentes e precisam de descrições separadas. Uma regra que exige vários participantes para autorizar uma alteração adiciona um requisito de coordenação; ela não faz a existência ou o escopo da autoridade desaparecer.

A governança diz respeito a como as decisões se tornam alterações autorizadas. As informações úteis incluem os poderes disponíveis, o processo que os rege e quais partes da aplicação eles afetam. Um rótulo comunitário amplo, por si só, não explica o mecanismo real de decisão.

As evidências precisam de um escopo claro

Código-fonte publicado, um relatório de revisão, um resultado de teste e uma prova formal estabelecem coisas distintas. O resultado de uma verificação formal examina se um programa modelado satisfaz propriedades especificadas. Seu significado depende da especificação e das premissas representadas nesse modelo. A documentação do Ethereum sobre verificação formal explica essa relação.

Para o arquivo, uma prova de que apenas contas autorizadas podem atualizar um registro diria respeito a uma propriedade de controle de acesso declarada. Ela não estabeleceria a precisão factual do documento, a veracidade das credenciais de um colaborador ou a disponibilidade de longo prazo do arquivo. Esses objetos estão fora dessa propriedade específica.

O mesmo princípio se aplica a datas de revisão e versões. A avaliação de uma implementação descreve essa implementação dentro de seu escopo. Uma configuração ou componente posterior pode alterar a estrutura ao redor. As evidências são mais fáceis de interpretar quando o objeto revisado, a versão, os métodos e os limites estão disponíveis em conjunto.

Informações externas continuam sendo evidências externas

Um oráculo traz informações externas para o contexto da blockchain. O programa então opera com entradas registradas fornecidas por esse mecanismo. A aceitação da entrada pela rede não verifica separadamente cada fato sobre a observação original. A documentação do Ethereum sobre oráculos explica esse limite.

Suponha que o arquivo registre uma afirmação de que uma amostra física de pesquisa foi aprovada em uma inspeção. O programa na blockchain poderia preservar qual resultado foi enviado e qual conta o enviou. O método da inspeção, a identidade da amostra e a precisão da observação relatada continuam sendo questões sobre o processo externo.

Adicionar vários relatores pode alterar a organização das evidências, mas a relação entre eles importa. Três relatórios baseados em uma única observação original são diferentes de três observações independentes. O exemplo demonstra por que o número de entradas registradas, por si só, não descreve sua independência ou confiabilidade factual.

Armazenamento de arquivos e identificadores de conteúdo

As aplicações podem manter arquivos grandes fora da blockchain enquanto registram identificadores ou referências onchain. Sistemas de armazenamento descentralizado podem usar identificadores baseados em conteúdo e esquemas de recuperação distribuída. Identificar o conteúdo e torná-lo recuperável continuam sendo responsabilidades diferentes. A documentação do Ethereum sobre armazenamento descentralizado explica os modelos de armazenamento e seu contexto.

O arquivo poderia registrar o identificador de conteúdo de um documento sem colocar o documento completo no estado compartilhado da blockchain. Esse identificador ajuda a distinguir versões. Ele não contém um documento completo legível por humanos, não estabelece sua precisão científica nem explica quais participantes continuam a disponibilizá-lo.

Um gateway pode adicionar outro componente entre o leitor e o sistema de arquivos. Uma página legível pode estar indisponível por uma rota enquanto o identificador permanece registrado. Descrever localização, identificação, recuperação e persistência de arquivos separadamente evita transformar uma função bem-sucedida em uma afirmação sobre as quatro.

Disponibilidade de dados e provas de execução

Um sistema precisa de acesso a dados relevantes para verificar ou reconstruir seu estado. Um compromisso compacto, uma prova e os dados subjacentes desempenham funções distintas. A documentação de disponibilidade de dados do Ethereum explica por que apenas um resumo não determina se os dados necessários para uma verificação independente estão acessíveis. A documentação do Ethereum sobre disponibilidade de dados fornece a base.

No arquivo, um registro compacto poderia identificar uma coleção de revisões. Alguém que queira inspecionar essas revisões ainda precisa do material subjacente. A integridade do identificador e a disponibilidade do material são propriedades diferentes. Isso continua sendo verdade mesmo quando uma interface exibe uma descrição confiante da coleção.

Uma declaração sobre prova deve, portanto, identificar o que foi provado e quais informações ainda são necessárias. Correção, disponibilidade, confidencialidade e legibilidade são dimensões distintas. Uma prova que aborda uma dimensão deve ser interpretada dentro dessa dimensão e de suas suposições declaradas.

Sistemas de segunda camada acrescentam outro contexto

Os sistemas de segunda camada podem processar atividades em um arranjo de execução separado, ao mesmo tempo em que dependem de uma rede base para funções específicas. A documentação de escalabilidade do Ethereum distingue abordagens com diferentes relações com a execução e a segurança. O rótulo segunda camada descreve uma categoria, portanto a arquitetura específica ainda importa. A documentação do Ethereum sobre escalabilidade explica a visão geral.

Os optimistic rollups utilizam uma abordagem baseada em contestação para avaliar os resultados enviados, enquanto os validity rollups enviam evidências criptográficas relativas a mudanças de estado computadas. Essas descrições dizem respeito a diferentes mecanismos de verificação. A documentação do Ethereum sobre optimistic rollups e a documentação do Ethereum sobre validity rollups explicam seus respectivos modelos.

Para o arquivo, a analogia é um sistema que processa muitas revisões juntas e registra evidências em outra rede. A explicação precisa identificar onde o processamento ocorre, quais evidências são fornecidas, como os dados se tornam disponíveis e quais componentes administrativos continuam envolvidos. Um único nome de rede familiar não fornece todas essas informações.

Registros entre redes criam fronteiras adicionais

Uma ponte conecta ambientes de blockchain que de outra forma seriam separados por meio de mecanismos que comunicam ou representam atividades entre eles. Pontes diferentes usam arranjos diferentes de validação e confiança. Um registro aceito em uma rede não se torna automaticamente um registro verificado de forma independente em outra. A documentação do Ethereum sobre pontes explica essas relações.

Imagine dois arquivos independentes que trocam referências a revisões de documentos. O arquivo de destino precisa de uma regra para reconhecer informações originadas no outro arquivo. Essa regra pode depender de evidências verificadas por software ou de participantes designados. O mecanismo de reconhecimento é outro componente do sistema completo.

Mesmo nomes de documentos e formatos de conta correspondentes não eliminam a fronteira. O contexto completo inclui ambos os ambientes, o formato da mensagem e o método pelo qual o ambiente de destino aceita a mensagem. Compreender essas conexões faz parte da compreensão do registro resultante.

Registros públicos e contexto pessoal

Um registro público pode usar identificadores sem conter o nome legal de uma pessoa. Outras informações podem, no entanto, conectar um identificador a uma pessoa, organização ou atividade. A publicação dessa conexão cria contexto para registros públicos anteriores e posteriores. Identificadores pseudônimos descrevem, portanto, uma representação, não uma promessa completa de anonimato.

No arquivo, um pesquisador poderia associar publicamente uma conta a um projeto. Essa associação pode tornar outras revisões públicas da conta mais fáceis de interpretar. Se os documentos subjacentes incluem informações pessoais é uma questão separada de saber se o identificador da conta em si é legível.

Também existem informações fora da blockchain. Um site e seus endpoints de rede recebem as informações técnicas necessárias para suas próprias comunicações. O quadro completo de privacidade depende dos componentes reais e do processamento realizado por eles. Uma descrição ampla dos dados públicos da blockchain não deve substituir a explicação de privacidade separada pertencente a cada site ou aplicativo.

Como é uma explicação completa

Um relato claro do arquivo fictício começa com seu propósito: manter um registro de versões de documentos. Em seguida, nomeia os componentes, identifica quem pode autorizar quais alterações, descreve como as informações transitam entre os componentes e distingue evidências de interpretações. Ele declara qual conteúdo é visível publicamente e quais informações existem em outros lugares.

A explicação também utiliza alegações delimitadas. Uma afirmação sobre revisões registradas diz respeito a esses registros. Uma afirmação sobre recuperação de arquivos diz respeito a um arranjo de armazenamento. Uma afirmação sobre uma propriedade formal diz respeito a um modelo e especificação. Cada alegação é informativa porque seu objeto permanece visível.

Essa abordagem não requer a escolha de um produto específico ou um procedimento operacional. É uma maneira de ler descrições técnicas com precisão. A segurança na Web3 se torna compreensível quando os componentes, poderes, evidências e limites podem ser descritos em linguagem comum e conectados ao propósito real da aplicação.

Um glossário compacto

Onchain: Registrado ou executado no contexto de rede aplicável de uma blockchain.
Offchain: Existente ou operando fora desse contexto de execução registrado da blockchain.
Frontend: A interface que apresenta uma aplicação ao seu leitor ou participante.
Autenticação: O estabelecimento de uma relação de autoridade para uma sessão ou solicitação específica.
Autorização: As regras que determinam quais ações essa autoridade pode executar.
Componibilidade: A combinação de componentes separados em um arranjo de software mais amplo.
Disponibilidade de dados: A acessibilidade dos dados necessários para verificar ou reconstruir o estado relevante.
Ponte: Um mecanismo que relaciona informações ou atividades entre ambientes distintos de blockchain.

Perguntas frequentes de iniciantes

O uso de uma blockchain remove todos os operadores?

Não. O site, as funções administrativas, o armazenamento e o acesso à rede de uma aplicação podem ter seus próprios operadores. A arquitetura identifica as responsabilidades de cada um.

Informações legíveis publicamente são automaticamente compreensíveis?

Não. Os dados podem estar visíveis e ainda assim exigir decodificação e contexto. A interpretação deve identificar sua fonte e distingui-la do registro subjacente.

Uma única prova estabelece todas as propriedades de uma aplicação?

Uma prova aborda propriedades e suposições definidas. A disponibilidade de arquivos, observações do mundo real, o significado da interface e o contexto pessoal podem exigir evidências diferentes.

Para o Metasecudary, ALCENITA SILVA TOMAZ utiliza o modelo de arquivo para explicar como as responsabilidades das aplicações se encaixam. ALCENITA SILVA TOMAZ publica este artigo com o objetivo editorial mais amplo de tornar conceitos relacionados a blockchain compreensíveis em diferentes usos e sistemas.

Nossa perspectiva editorial

ALCENITA SILVA TOMAZ publica o Metasecudary a partir de Imperatriz, Maranhão, Brasil, para leitores internacionais. Nosso interesse editorial mais amplo é a forma como os sistemas digitais atribuem responsabilidades. A Web3 oferece um cenário útil para examinar essa questão porque um site, uma rede e uma aplicação podem ser administrados por participantes diferentes. O guia acompanha essas relações em vez de presumir que um único operador controla toda a experiência.

Referências primárias

Documentação oficial usada para verificar as explicações neste artigo. Seguir uma referência abre o site do editor original.