Recentemente, Gavin tem se concentrado na questão dos ataques Sybil (resistência civil). A PolkaWorld revisou o discurso principal do Dr. Gavin Wood no Polkadot Decoded 2024, explorando alguns de seus pensamentos sobre como prevenir ataques Sybil. Se você estiver interessado, continue lendo!

O que é um Ataque Sybil?

Você pode já saber que tenho estado a trabalhar em vários projetos. Estou a escrever um “gray paper” e a focar-me no projeto JAM, fazendo algum trabalho de codificação ao longo do caminho. Ao longo dos últimos dois anos, tenho pensado muito sobre uma questão crucial que é bastante significativa neste espaço - como prevenir ataques Sybil (resistência civil). Este problema está em todo o lado. Os sistemas blockchain são construídos com base na teoria dos jogos, e ao analisar jogos, frequentemente precisamos de limitar o número de participantes ou gerir comportamentos imprevisíveis que possam exibir.

Ao projetar sistemas digitais, queremos determinar se um ponto final específico - uma interface digital - é operado por um ser humano. Para esclarecer, não estou discutindo identidade aqui. A identidade é obviamente importante, mas não estamos nos concentrando em determinar a identidade do mundo real de alguém aqui. Em vez disso, o objetivo é distinguir entre dispositivos e se eles estão sendo operados ativamente por um humano em determinado momento. Além disso, surge outra pergunta importante: se um dispositivo está sendo de fato operado por um ser humano, podemos fornecer a eles um pseudônimo que nos permita identificá-los em um contexto específico e, se eles retornarem para interagir conosco, podemos reconhecê-los novamente?

À medida que as nossas interações se deslocaram de comunicar principalmente com outras pessoas (nos anos 80, quando nasci) para interagir com sistemas, sistemas digitais, particularmente sistemas descentralizados Web3, tornaram-se cada vez mais relevantes. Nos anos 80, as pessoas interagiam principalmente diretamente umas com as outras; nos anos 90, começamos a interagir com serviços por telefone, como a banca telefónica. Isto foi uma grande mudança para nós. Inicialmente, a banca telefónica envolvia grandes centros de atendimento operados por humanos, mas ao longo do tempo, esses sistemas evoluíram para os sistemas de resposta de voz automatizados de hoje. Com o surgimento da internet, as interações humanas tornaram-se mais raras e, na maioria dos serviços diários, já não comunicamos diretamente com humanos. Claro, com o crescimento do comércio eletrónico Web2, essa tendência tornou-se ainda mais evidente. Web3 consolida ainda mais isso—dentro do Web3, raramente interage com pessoas. A ideia central do Web3 é que interage com máquinas, e por vezes as máquinas interagem entre si.

Porque é que estudar ataques Sybil é importante?

Então, por que isso importa? É um elemento fundamental de qualquer sociedade real e está no cerne de muitos sistemas sociais, incluindo negócios, governança, votação e construção de consenso. Todos eles dependem fortemente de prevenir ataques Sybil para construir comunidades genuínas. Muitos mecanismos que são dados como certos em corporações são baseados em prevenir ataques Sybil. Seja o uso justo, controle de ruído ou gerenciamento de comunidades, todos eles dependem dessa capacidade defensiva. Muitas coisas exigem que confirmemos que uma entidade é de fato um ser humano real. Se alguém se comporta de maneira inadequada, podemos querer removê-lo temporariamente da comunidade. Isso é algo que pode ser observado em serviços digitais e, é claro, existe no mundo real também.

Ao prevenir ataques de Sybil, podemos introduzir mecanismos que restrinjam o comportamento sem elevar as barreiras de entrada ou comprometer a acessibilidade do sistema. Por exemplo, existem duas maneiras básicas de incentivar o comportamento: uma é através de uma abordagem de "cenoura e pau" (um sistema de recompensas e penalidades). O método de penalidade (pau) requer que você pague um depósito e, se você se comportar mal, esse depósito é confiscado. O staking é um exemplo simples disso. O método de recompensa (cenoura) assume que você terá um bom comportamento e, se você não atender às expectativas, perderá alguns de seus direitos. Isso é essencialmente como a maioria das sociedades civis opera.

No entanto, sem mecanismos para evitar ataques de Sybil na blockchain, esta abordagem não pode realmente ser aplicada. Na sociedade civil, esses mecanismos funcionam porque, se alguém é preso, eles não podem cometer a mesma ofensa novamente - pelo menos, não enquanto estão encarcerados. A liberdade é um direito inerente, e o governo pode, em princípio, retirá-la. Não estou sugerindo que prendamos alguém on-chain, mas atualmente não podemos impor restrições semelhantes na blockchain. Isso torna difícil reprimir comportamentos inadequados ao oferecer serviços gratuitos, e acabamos confiando apenas em incentivar bons comportamentos. O comércio e as atividades promocionais dependem fortemente da capacidade de confirmar que os usuários são pessoas reais.

Aqui está uma captura de ecrã de um site que eu uso às vezes. Oferece um uísque muito bom que muitas pessoas adoram e é difícil de encontrar no país de origem. Mas na Europa, é relativamente barato e parece que mantêm os preços baixos limitando o número de garrafas que cada pessoa pode comprar. No entanto, este tipo de operação é quase impossível de fazer cumprir num sistema Web3 real.

Existem também desafios significativos na construção da comunidade, airdrops e na identificação e distribuição aos membros da comunidade. Os airdrops são geralmente ineficientes quando se trata de despesas de capital, porque visam cobrir o maior número possível de pessoas. Para distribuir os airdrops de forma justa, é necessário identificar os indivíduos e dar a todos a mesma quantidade. Mas, na prática, surgem muitos problemas, como saldos de carteira variados. Eventualmente, você pode se encontrar em uma situação em que a curva de distribuição se torna extremamente desequilibrada, com grandes disparidades. Como resultado, a maioria das pessoas recebe quase nenhum incentivo.

Em relação à “utilização justa”, embora o impacto atual seja pequeno, se você usar em excesso os recursos da rede, o sistema geralmente apenas diminui a velocidade da sua conexão, embora ainda seja possível usar a rede.

Olhando para trás, há 10 a 15 anos, se você usasse muito a internet, o seu Provedor de Serviço de Internet (ISP) poderia considerar que você não estava usando esse serviço “ilimitado” de forma responsável. Então, eles cortariam completamente o seu serviço, em vez de apenas diminuir a velocidade como fazem agora. Essa abordagem permitia que eles fornecessem serviços de internet quase ilimitados para a maioria dos usuários, porque eles podiam identificar quem estava usando os recursos de forma responsável.

A Web2 é construída com base num modelo de serviço avançado, que depende muito da capacidade de identificar utilizadores. Há vinte anos, os mecanismos de identificação eram menos complexos, mas agora é muito diferente. Se quiser abrir uma conta, geralmente existem pelo menos três formas diferentes de confirmar que é uma pessoa real e que eles não se depararam consigo anteriormente. Por exemplo, se tentar registar uma conta Apple sem comprar um iPhone, é como passar por um campo de obstáculos. Essas empresas basicamente não querem dar-lhe uma conta. Claro, eles anunciam que pode obter uma conta gratuitamente, mas não sei o que a IA por trás das cenas está a fazer. Levei 10 tentativas antes de finalmente conseguir, e no fim, ainda tive de comprar um iPhone.

Acredito que se conseguíssemos identificar melhor as pessoas, muitos processos como a “Oracleização” (verificação de informação) se tornariam muito mais fáceis.

Um exemplo típico de uso da resistência Sybil como uma “prova de humanidade” para verificação de informações na sociedade é o sistema de júri. Quando precisamos de um juiz imparcial (ou seja, um Oráculo) para determinar a culpa de alguém, o sistema seleciona aleatoriamente um número ímpar de pessoas comuns da sociedade para ouvir as evidências e tomar uma decisão. Da mesma forma, em outras áreas da vida social, como representação e coleta de opiniões, a representação é uma parte importante da sociedade, e gerenciamos a representação usando métodos de resistência Sybil. Claro, esse tipo de gerenciamento nem sempre é perfeito devido às falhas na infraestrutura civil atual, especialmente quando a representação é confundida com a identidade. Muitas vezes, quando você deseja votar, precisa provar sua identidade real, como mostrando uma carteira de motorista ou passaporte. Mas, na realidade, votar representa seu direito de voto, não um vínculo direto com sua identidade pessoal.

Como podemos prevenir ataques Sybil? Quais soluções estão atualmente disponíveis?

Então, como podemos abordar isto?

Na era da Web 2 e mesmo antes disso, tínhamos vários métodos para verificar a identidade. Nos sistemas da Web 2 atual, esses métodos são frequentemente combinados. Por exemplo, se você deseja criar uma nova conta do Google, pode ser necessário passar por um CAPTCHA e verificar tanto seu e-mail quanto seu número de telefone. Às vezes, a verificação por SMS pode substituir a conversa com uma pessoa real. Se você já teve sua conta da Amazon bloqueada, saberá do que estou falando - parece que está navegando em um labirinto complicado até finalmente acertar o botão certo para falar com um representante real do serviço ao cliente. Para uma prevenção mais avançada de ataques Sybil, podemos depender de IDs ou informações de cartão de crédito.

No entanto, quando nos deslocamos para o mundo Web 3, a solução perfeita continua a ser evasiva. Existem algumas soluções candidatas, mas diferem grandemente em três áreas-chave: descentralização, proteção da privacidade e resiliência (a capacidade de resistir a ataques).

A resiliência está se tornando uma questão cada vez mais importante, e a maioria dos sistemas enfrenta desafios nessas áreas.

Um exemplo é o que chamo de “sistema de confissão”, onde você divulga suas informações privadas a uma autoridade central. Essa autoridade então possui informações sobre você que você pode não querer que outros vejam. Por exemplo, você pode escanear seu passaporte e enviá-lo a uma instituição, dando a eles acesso a todos os seus dados pessoais. Isso os coloca em uma posição poderosa, pois eles controlam informações sensíveis. Essa abordagem não é adequada para a Web 3.

Você também pode encontrar sistemas que parecem ser Web 3, mas dependem de 'instituições centralizadas de gestão de chaves'. Essas instituições têm o poder de decidir quem se qualifica como um usuário legítimo, controlando as chaves. Às vezes, elas até mesmo possuem as chaves dos usuários. Em ambos os casos, elas controlam quem é considerado um participante válido.

Esse controle centralizado sobre identidade e privacidade contradiz os princípios centrais da Web 3, que se concentram na descentralização e autonomia do usuário.

Apenas colocar algo na cadeia não o torna Web 3. Você pode transferir práticas Web 2 ou modelos de autoridade centralizados para a blockchain, mas isso não muda a natureza do sistema. Isso apenas o torna mais resiliente, mas não o torna descentralizado. Um longo endereço hexadecimal não garante automaticamente a privacidade. Sem medidas específicas de privacidade, essa sequência ainda pode estar vinculada a identidades do mundo real.

Se um sistema depende de um “mecanismo de confissão”, não é uma solução de preservação da privacidade. Temos visto inúmeros casos de violações de dados que comprovam que armazenar dados atrás de firewalls corporativos ou hardware confiável não garante segurança. Uma solução adequada para a Web 3 não deve se concentrar em identidades locais ou identidades específicas da comunidade, mas sim em identidades globais e descentralizadas. Estes são conceitos completamente diferentes.

Alguns sistemas estão tentando resolver esse problema, mas muitas vezes dependem de hardware específico e gerenciamento de chaves centralizado, portanto, não atendem completamente aos padrões da Web 3. Por exemplo, o projeto Worldcoin tenta lidar com isso usando hardware confiável, mas depende de um sistema centralizado de gerenciamento de chaves e fonte de dados, o que não está alinhado com a ética descentralizada da Web 3.

O Gitcoin Passport é outro exemplo. É amplamente utilizado na comunidade Ethereum como uma plataforma abrangente de solução de identidade. No entanto, ele depende de um sistema federado de gerenciamento de chaves e as fontes de dados muitas vezes vêm de entidades centralizadas como a Coinbase.

Idena é uma interessante solução Web 3 que não utiliza gestão centralizada de chaves ou autoridades. No entanto, é um único mecanismo e, com o surgimento da IA, é incerto se essa abordagem terá a resiliência necessária para o futuro. Até agora, tem se saído bem, mas possui apenas cerca de mil usuários.

Em resumo, nenhuma solução atual aborda completamente o problema dos ataques de Sybil.

Perspetiva de Gavin sobre a resolução de ataques Sybil

Quando se trata de identidade individual, existem duas abordagens para pensar sobre isso: remota e local. As máquinas não entendem inerentemente a “identidade individual”, e é improvável que vejamos algum tipo de tecnologia de criptografia resolver isso de repente. Alguns podem argumentar que ferramentas biométricas como impressões digitais podem tornar cada humano único, e as máquinas poderiam medir isso, mas é difícil para sistemas puramente digitais provar isso. A coisa mais próxima de alcançar isso pode ser o Worldcoin, mas mesmo assim, é apenas uma máquina que pode verificar pessoas de uma forma difícil de trapacear.

Portanto, precisamos reconhecer que a identidade individual é mais sobre autenticação. Trata-se de como os elementos dentro de um sistema digital verificam se outros elementos são indivíduos reais. A questão então passa a ser: qual é a base dessa autenticação? É o contato físico ou alguma outra forma de comprovação? Podemos confiar que uma conta está vinculada a uma pessoa real porque a conhecemos e presumimos que ela não interagiu com mais ninguém. Ou talvez confiemos na identidade de alguém com base em certas informações que vemos na tela, corroboradas por outras evidências.

Quando falamos sobre autenticação remota (autenticação sem prova física direta), a IA (inteligência artificial) pode criar complicações. Por outro lado, se confiarmos em provas físicas, a implementação prática se torna desafiadora. Assim, estamos presos entre essas limitações. Mas acredito que com criatividade e inovação, podemos encontrar soluções viáveis.

O que precisamos de fazer?

Qual é a solução? Qual é o plano?

Para tornar o Polkadot mais prático no mundo real (além dos DeFi, NFTs e espaços virtuais de blockchain), a chave é encontrar uma maneira simples de identificar indivíduos. Isso não significa saber quem é alguém, como "Eu sei que este é Gavin Wood", mas mais como reconhecer "este é um indivíduo único". Não acredito que exista uma solução única, então precisamos de uma estrutura modular e escalável.

Primeiro, podemos integrar soluções existentes (como Idena). Em segundo lugar, o sistema não deve ser limitado pelas ideias de apenas uma pessoa ou baseado apenas na visão individual de uma pessoa sobre o que pode funcionar. Ele precisa ser aberto, permitindo que outros contribuam para a solução. Em seguida, precisamos de uma pseudonimidade contextual forte. A princípio, escrevi “anonimato” e, de certa forma, quero dizer anonimato, especialmente em relação à sua identidade no mundo real. Mas ao mesmo tempo, queremos pseudonimidade, de forma que em um contexto específico, você possa provar que é uma pessoa única. Além disso, quando você usa o sistema novamente nesse mesmo contexto, deve ser capaz de provar que é o mesmo indivíduo de antes.

Finalmente, precisamos de um SDK robusto e API para que esta funcionalidade seja tão fácil de usar como qualquer outra funcionalidade nos contratos inteligentes Substrate ou Polkadot, ou no próximo ecossistema JAM. Precisa ser simples de implementar. Para ser mais específico: se já escreveu código Frame antes, talvez tenha encontrado uma linha como let account = ensure_signed (origin). Isto recupera a origem da transação e verifica se veio de uma conta, dizendo-me qual é a conta. Mas uma conta não é o mesmo que um indivíduo. Uma pessoa pode usar várias contas, e também pode um script. As contas não fornecem informações sobre a identidade individual. Se quisermos ter a certeza de que uma transação vem de uma pessoa real - e não apenas de uma entre um milhão de contas -, precisamos substituir este código por algo como let alias = ensure_person (origin, &b”Meu contexto”).

Existem dois benefícios-chave para isso. Primeiro, em vez de apenas perguntar se uma conta está assinando a transação, estamos perguntando se uma pessoa está assinando. Isso abre muitas novas possibilidades.

Em segundo lugar, diferentes operações ocorrem em contextos diferentes, e podemos manter tanto o anonimato quanto a proteção de pseudônimos nesses contextos. Quando o contexto muda, o pseudônimo também muda, e pseudônimos em diferentes contextos não podem ser vinculados ou rastreados até a pessoa por trás deles. Esses pseudônimos são completamente anônimos, o que os torna uma ferramenta poderosa no desenvolvimento de blockchain, especialmente ao desenvolver sistemas úteis no mundo real.

Então, que restrições podemos impor aos mecanismos que identificam indivíduos? Em primeiro lugar, esses mecanismos precisam ser amplamente acessíveis. Se estiverem disponíveis apenas para um grupo seleto de pessoas, não serão muito úteis. Eles não devem exigir a posse de ativos ou ter altas taxas - pelo menos, nada excessivo.

Haverá inevitavelmente compensações entre diferentes mecanismos. Não acredito que exista uma solução única para todos. No entanto, algumas compensações são aceitáveis, enquanto outras não. Não devemos comprometer a resiliência, descentralização ou soberania do usuário. Alguns mecanismos podem exigir menos esforço, mas mais confiança, enquanto outros podem exigir mais esforço, mas oferecem maior garantia. Devemos ter expectativas realistas de que os indivíduos verificados pelo sistema (sejam contas vinculadas a indivíduos ou pseudônimos) são realmente pessoas únicas e reais.

Quando diferentes mecanismos em sistemas descentralizados Web3 avaliam a identidade individual, usando bases de resiliência e não autoritárias, pode haver alguma sobreposição. Isso significa que não devemos esperar a perfeição, mas a margem de erro deve ser muito menor do que uma ordem de magnitude. Além disso, o sistema deve ser altamente resistente ao abuso de identidade para evitar que um pequeno grupo ou organização assuma o controle de um grande número de identidades.

É crucial que o sistema tenha salvaguardas para evitar tal abuso. Alguns mecanismos podem oferecer pontuações de identidade individual com baixa confiança, o que poderia ser um objetivo mais elevado. Alguns podem ter sucesso em alcançar isso, alguns podem não ter e alguns podem adotar uma abordagem binária: ou confiamos que a conta pertence a um indivíduo único, ou não. Outros mecanismos podem sugerir que estamos 50% confiantes, o que significa que o indivíduo pode ter duas contas e estamos 50% confiantes em ambas.

Tudo isso precisa ser sem permissão e relativamente fácil de implementar. Não deveria ter que enfatizar isso, mas o sistema não deve depender de mecanismos comuns de confissão ou de instituições de gestão de chaves.

Qual é o benefício desta abordagem?

Porque devemos fazer isto? Quais são os benefícios?

Falámos sobre como a sociedade utiliza e depende de identidades individuais, mas como é que isto pode ser aplicado on-chain? Imagine um sistema Polkadot onde as taxas de transação não têm de ser pagas, tornando o uso razoável gratuito. Imagine algo como uma “cadeia de Praça” (Plaza), que é essencialmente um Asset Hub atualizado com capacidades de contrato inteligente e um sistema de staking.

Neste tipo de cadeia Plaza, pode-se imaginar um cenário em que não são necessárias taxas de gás. Desde que esteja a usar o sistema dentro de limites razoáveis, o gás é gratuito. Claro, se estiver a executar scripts ou a realizar um grande número de transações, teria de pagar taxas, uma vez que isso vai além do que um utilizador típico poderia fazer. Imagine esses sistemas a abrir de forma gratuita ao público. Poderíamos eficientemente impulsionar comunidades usando métodos direcionados como airdrops. Ao mesmo tempo, poderíamos imaginar modelos de governação ainda mais avançados para o Polkadot.

Pessoalmente, não estou totalmente vendido à ideia de "uma pessoa, um voto". Em alguns casos, é necessário garantir a legitimidade, mas nem sempre produz os melhores resultados. No entanto, poderíamos considerar modelos de votação alternativos, como o voto quadrático ou o voto regional. Em alguns elementos representativos, "uma pessoa, um voto" pode ser bastante perspicaz.

Também podemos imaginar um sistema Oracle semelhante a um júri, onde parachains e contratos inteligentes podem utilizar sistemas Oracle locais e subordinados, talvez para previsões de preços ou resolução de disputas de usuários. Eles também podem ter um sistema de "grande júri" ou "Supremo Tribunal", onde os membros são selecionados aleatoriamente de um grupo de indivíduos conhecidos para tomar decisões, ajudar a resolver disputas e receber pequenas recompensas. Como esses jurados são escolhidos aleatoriamente de um grupo grande e neutro, esse método ofereceria uma maneira resiliente e confiável de resolver conflitos.

Você também poderia imaginar um sistema de controle de ruído, especialmente dentro de integrações descentralizadas de mídias sociais, para gerenciar spam e comportamento indesejado. Em DeFi, poderíamos ver sistemas baseados em reputação semelhantes aos scores de crédito, mas mais focados em saber se alguém deixou de pagar no prazo. Dessa forma, o sistema poderia funcionar em um modelo freemium, oferecendo diferentes níveis de serviço.

Está bem, isso conclui a primeira parte deste discurso. Espero que tenha sido útil.

Aviso Legal:

1. Este artigo é uma reimpressão de [PolkaWorld]. Direitos de autor pertencem ao autor original [PolkaWorld]. Se houver alguma preocupação com a reprodução, por favor entre em contato com oEquipe Gate Learn, e a equipe irá resolver o problema o mais rápido possível.
2. Aviso legal: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. Outras versões em diferentes idiomas do artigo foram traduzidas pela equipe Gate Learn. A menos queGate.ioÉ mencionado que a cópia, distribuição ou plágio do conteúdo traduzido é proibido.