Ir para o conteúdo
Financial Context Wiki

Prova de humanidade e unicidade

Os sistemas Prova de humanidade e unicidade tentam fornecer a cada humano elegível uma credencial utilizável dentro de um escopo definido sem exigir que cada aplicação conheça a identidade civil dessa pessoa.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Prova de humanidade e unicidade (PoP) é uma família de sistemas que tenta permitir que um aplicativo imponha uma pessoa elegível por credencial, conta, voto, reivindicação ou outra ação com escopo definido. Uma credencial PoP pode ser pseudônima: o aplicativo pode saber apenas que um emissor aceito cadastrou um ser humano único e que a mesma credencial ainda não atuou neste escopo. Não é necessário que ele saiba o nome da pessoa, endereço ou identificador governamental.

Essa descrição compacta reúne várias afirmações independentes. Humanidade pergunta se uma pessoa viva participou. Unicidade pergunta se ela já possui outra credencial segundo as regras do sistema. Controle pergunta se quem apresenta a prova controla atualmente a credencial. Elegibilidade pergunta se a pessoa pertence à população autorizada a agir. Não vinculabilidade pergunta se apresentações em contextos diferentes podem ser correlacionadas. Um projeto pode satisfazer uma afirmação e falhar em outra: uma verificação de vivacidade não elimina duplicatas, um passaporte único não prova que seu titular ainda controla a conta criada, e uma prova anônima não torna justo um processo de inscrição tendencioso.

PoP não é o mesmo que a verificação know-your-customer (KYC). KYC geralmente estabelece uma identidade civil e coleta atributos para fins legais ou de conformidade. PoP pode, em vez disso, emitir uma declaração restrita como “um participante aceito neste registro” e prová-la posteriormente sem divulgar a identidade civil. Por outro lado, um registro KYC pode ajudar a evitar duplicidade de candidatos, mas não fornece automaticamente apresentações não vinculáveis, resistência à transferência ou cobertura global.

PoP também não é, por si só, um protocolo de consenso de blockchain, uma regra de escolha de fork ou um mecanismo de finalização. Um protocolo pode usar um registro de personhood para alocar membros, recompensas ou peso de voto, mas ainda precisa de regras para propor, validar e finalizar o estado. O artigo original 2017 PoP propôs tokens de personhood como uma entrada para um design de criptomoeda; essa proposta não transforma todo credencial de personhood moderno em um sistema de consenso.

Como funciona

Não existe um método universal PoP. Os sistemas usam documentos governamentais, deduplicação biométrica, atestações de grafos sociais, cerimônias presenciais ou sincronizadas, desafios online, instituições confiáveis ou combinações desses. Cada método transfere a confiança em vez de eliminá-la: sistemas de documentos confiam em emissores e na validação dos documentos; sistemas biométricos confiam no hardware de captura, no software de correspondência e no gerenciamento de modelos; sistemas sociais confiam na entrada no grafo e na resistência à conluio; cerimônias confiam nos controles de presença e nos organizadores.

Uma implementação deve tornar explícito o seguinte ciclo de vida:

  1. Defina o escopo e a política. Especifique a ação que está sendo protegida, a população elegível, o período de tempo, as taxas de erro aceitáveis e o que ‘uma pessoa’ significa para casos extremos. Humanidade global, residência local, idade adulta e associação são reivindicações diferentes.
  2. Modele o adversário e os incentivos. Estime o valor de uma credencial extra e se os atacantes podem falsificar evidências, recrutar pessoas reais, subornar operadores, comprometer dispositivos, conluiar-se em um gráfico social ou comprar credenciais após a emissão.
  3. Inscreva-se e teste a humanidade. Coleta apenas as evidências exigidas pela política. A detecção de vivacidade ou de ataques de apresentação pode ajudar a mostrar que uma pessoa viva está presente, mas não é um teste de unicidade.
  4. Remover duplicatas dentro da população registrada. Compare documentos, dados biométricos, participação em cerimônias, atestações ou outros sinais de acordo com as regras publicadas. O resultado é a unicidade em relação àquele registro, tempo e método, não a prova de que nenhuma credencial existe em outro lugar.
  5. Emitir e vincular uma credencial. Vincule uma matrícula aprovada a uma chave, autenticador ou conta recuperável. Registre o emissor, período de validade, método de status e nível de garantia. A verificabilidade criptográfica prova quem assinou a reivindicação e se ela foi alterada; como W3C observa, isso por si só não prova que a reivindicação é verdadeira.
  6. Apresente uma prova delimitada. O portador pode revelar a credencial diretamente ou gerar uma apresentação de divulgação seletiva ou de conhecimento zero. Uma construção pode provar a adesão ao grupo e derivar um anulador específico do escopo para que o verificador rejeite uma segunda ação sem aprender um identificador global reutilizável.
  7. Operar o ciclo de vida. Verifique a atualidade e o escopo, previna a repetição, processe revogação e recuperação, publique alterações de regras e software, meça aceitação falsa e rejeição falsa, forneça revisão humana e recursos, e defina o que acontece se o emissor ou serviço encerrar.

O verificador deve avaliar tanto a criptografia quanto a política. Uma prova válida pode estabelecer que uma chave pertence ao conjunto de credenciais atual e não foi utilizada duas vezes sob uma determinada regra de anulação. Ela não estabelece que os sensores de registro não foram comprometidos, que os operadores não coludiram, que toda pessoa elegível pôde se registrar, que a credencial não foi alugada, ou que a própria ação era legal ou justa.

As métricas devem manter seus denominadores. A aceitação falsa mede candidatos proibidos ou duplicatas aceitas incorretamente; a rejeição falsa mede candidatos legítimos rejeitados incorretamente; a cobertura mede quanto da população pretendida pode realisticamente se inscrever; o custo do ataque estima os recursos marginais necessários para outra credencial utilizável. Uma única porcentagem de “precisão” pode ocultar um pequeno grupo excluído, uma falha de baixa taxa-base ou um ataque economicamente lucrativo.

Exemplos resolvidos

Erros de matrícula

Suponha que as aplicações 100,000 contenham 90,000 pessoas elegíveis únicas e 10,000 duplicatas ou bots. Com uma taxa de rejeição falsa de 2%, 1,800 pessoas elegíveis são rejeitadas. Com uma taxa de aceitação falsa de 5%, 500 aplicações proibidas são aceitas. O sistema classifica 97,700 aplicações corretamente, ou 97.7%, mas esse número agregado não elimina a necessidade de corrigir 1,800 exclusões indevidas ou conter 500 credenciais extras.

Aluguel de credenciais em uma votação fechada

Uma votação entre credenciais 8,000 termina 4,050 a 3,950. Se as credenciais puderem ser alugadas por $5, o lado perdedor precisa de 101 votos adicionais para ganhar 4,051 a 4,050, custando $505. A exclusividade de inscrição não impediu transferência, coerção ou controle pago. Um instantâneo impede a criação tardia de contas apenas se o atacante não controlar as credenciais antes do instantâneo.

Anuladores com escopo

Em uma construção simplificada, um portador deriva N = H(person_secret || action_id) e prova em conhecimento zero que N foi derivado de uma credencial no conjunto aceito. Duas tentativas com action_id = grant-2026 produzem o mesmo N, então a segunda é rejeitada. Usar action_id = forum-2026 produz um N diferente e pode reduzir a ligação entre aplicações. Este é um exemplo conceitual; as entradas exatas do hash, domínios e a declaração de prova são específicas do protocolo, e os metadados ainda podem correlacionar os usuários.

A cobertura muda o resultado

Um airdrop tem tokens 1,000,000 e pretende pagar igualmente a todas as pessoas elegíveis. Se 10,000 pessoas se inscreverem, cada uma receberá 100 tokens. Se requisitos de viagem, dispositivo ou documentação excluírem 2,000 pessoas que seriam elegíveis, os 8,000 participantes inscritos receberão 125 tokens cada. O contrato executa seu registro corretamente, mas a distribuição não é igual em toda a população pretendida. Portanto, a cobertura faz parte do modelo de segurança e justiça, não apenas de uma métrica de experiência do usuário.

Riscos e controles

Matrícula e singularidade

  • Aceitação indevida: documentos forjados, capturas reutilizadas, mídia sintética, gêmeos, lacunas em bancos de dados ou atestadores coniventes podem criar credenciais extras. Teste todo o fluxo operacional, não apenas um comparador de laboratório.
  • Rejeição indevida: erros de correspondência e regras rígidas de evidência podem excluir pessoas legítimas. Publique o desempenho desagregado, exija revisão manual para correspondências de deduplicação com grande impacto e ofereça reparação acessível.
  • Domínio de unicidade limitada: um registro normalmente pode deduplicar apenas contra registros que ele pode inspecionar. Indique a geografia, os emissores, os canais de inscrição e o período coberto pela reivindicação.
  • Captura do verificador: subornar operadores ou comprometer o hardware de inscrição pode contornar até uma criptografia robusta. Separe funções, audite a emissão, alterne operadores e limite a autoridade unilateral.

Privacidade e proteção de dados

  • Vazamento biométrico insubstituível: um modelo de face ou íris não pode ser rotacionado como uma senha. Minimize a coleta, proteja os modelos, retenha e exclua documentos, e obtenha consentimento informado quando necessário.
  • Correlação entre contextos: um identificador estável, assinatura, anulador ou padrão de tempo pode vincular atividades entre aplicativos. Use separação de domínio e apresentações não vinculáveis, depois teste caminhos de metadados assim como valores de prova.
  • Conluio entre emissor e verificador: uma prova de conhecimento zero pode ocultar atributos do verificador enquanto os registros de emissão ainda identificam o titular. Documente a visão de cada parte, a política de retenção e a capacidade de combinar dados.
  • Publicação permanente: colocar biometria bruta, imagens de documentos ou hashes pessoais estáveis na blockchain torna a exclusão e a mitigação de riscos futuros difíceis. Mantenha dados sensíveis de cadastro fora dos livros-razão públicos.

Ciclo de vida das credenciais

  • Venda, aluguel e coerção: uma credencial única ainda pode ser controlada por outra pessoa. Modele mercados de credenciais e coerção; não afirme não transferibilidade apenas porque um token não pode se mover na cadeia.
  • Comprometimento de chave ou dispositivo: a posse criptográfica prova o controle de um segredo, não qual pessoa o utiliza. Ofereça autenticadores seguros, comunicação de comprometimentos e uma recuperação cuidadosamente delimitada.
  • Duplicação na recuperação: emitir uma substituição sem invalidar a credencial antiga cria duas identidades utilizáveis; uma recuperação excessivamente rigorosa exclui permanentemente o titular. Torne a substituição atômica e auditável.
  • Dependência de revogação: verificações de status podem permitir censura, rastreamento ou interrupções. Restrinja a autoridade de revogação, publique motivos e níveis de serviço e ofereça recursos ou migração.

Governança e inclusão

  • Pontos de estrangulamento centralizados: um verificador on-chain não descentraliza sensores proprietários, um emissor, uma chave de atualização ou um banco de dados biométrico. Mapeie a autoridade componente por componente.
  • Mudanças nas regras: administradores podem alterar limites, documentos aceitos ou critérios de elegibilidade depois do cadastro dos usuários. Use políticas versionadas, períodos de aviso, avaliações de impacto e procedimentos de reversão.
  • Barreiras de acesso: custo, deslocamento, idioma, deficiência, idade, documentação, conectividade e requisitos de dispositivo afetam quem pode participar. Meça as taxas de conclusão e rejeição em toda a população-alvo.
  • Falha institucional: emissores podem encerrar atividades, perder chaves ou parar de manter dados de revogação. Defina antes do lançamento os caminhos de exportação, sucessão, encerramento e novo cadastro.

Aplicação e integridade econômica

  • Escopo ou erros de reprodução: um domínio de anulador reutilizado pode criar vínculos indesejados, enquanto um domínio omitido ou inconsistente pode permitir ações repetidas. Vincule provas ao verificador, ação, rede, nonce e expiração conforme exigido pelo protocolo.
  • Escalada de incentivo: quando um voto, airdrop ou conta se torna mais valioso, ataques que anteriormente eram antieconômicos podem se tornar lucrativos. Reavalie os controles em relação ao valor atual de uma credencial extra.
  • Má conduta humana: PoP podem limitar a multiplicidade de contas, mas não podem impedir que pessoas verificadas coordenem, mintam, enviem spam, corrompam ou quebrem regras. Mantenha o conteúdo, a fraude e os controles de governança separados.
  • Implantação ampla demais: a alocação de recursos escassos pode justificar a unicidade, enquanto leitura, fala ou pagamentos comuns talvez não. Exija necessidade e proporcionalidade em vez de transformar PoP em um requisito universal de acesso.

Equívocos comuns

Não necessariamente. Um sistema pode provar a associação a um conjunto aceito de humanos únicos sem revelar um nome ou identificador civil. Se ele realmente alcança essa privacidade depende dos dados de inscrição, do design da apresentação, dos metadados e das partes que podem coludir.

Liveness, um CAPTCHA ou uma selfie prova unicidade

Essas verificações podem aumentar o custo da automação ou de ataques de apresentação, mas não mostram que a mesma pessoa não tenha se inscrito através de outro dispositivo, documento ou conta. A deduplicação é uma reivindicação separada.

Uma prova de conhecimento zero torna a inscrição confiável

O conhecimento zero pode limitar o que uma apresentação revela e provar uma declaração formal sobre dados comprometidos. Ele não corrige uma alegação falsa do emissor, um comparador tendencioso, um sensor comprometido, um operador subornado ou uma política excludente.

Colocar o registro na blockchain torna o sistema descentralizado

A cadeia pode tornar atualizações e regras de verificação auditáveis, mas o registro, a produção de hardware, a correspondência, as atualizações, a revogação e o acesso a dados podem permanecer concentrados. A descentralização deve ser avaliada para cada autoridade e dependência.

Uma pessoa, uma credencial cria automaticamente consenso ou governança justa

PoP pode fornecer uma entrada de resistência a Sybil ou de associação. Não fornece ordenação de blocos, escolha de fork, finalização, participação informada, sigilo de voto, resistência à coerção ou um limite de elegibilidade justo. Esses exigem mecanismos e escolhas de política separadas.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...