Baixar a Status
Contribuir

O Que é Realmente um Nó Status?

O Que é Realmente um Nó Status?

Em sua essência, um Nó Status é um software que permite a retransmissão de mensagens de usuários de aplicativos da maneira mais pseudônima e privada possível, ao mesmo tempo em que mantém os requisitos de recursos que podem ser atendidos por um dispositivo móvel ou laptop de baixo custo.

Um Nó Status precisa fornecer várias funcionalidades:

  • Comunicação com pares de forma descentralizada
  • Retransmissão de mensagens de maneira privada e anônima
  • Fornecimento de mensagens históricas para colegas que estão offline periodicamente

O software que usamos atualmente para fornecer a funcionalidade de Nó Status passou por muitas iterações e existem novas versões no horizonte, mas atualmente estamos usando exclusivamente a implementação status-go que foi construída em cima de um fork de go-ethereum. Nós divergimos um pouco da implementação original e agora a única coisa que realmente herdamos totalmente é o protocolo DevP2P e algumas funções criptográficas.

Protocolos & Limitações

Os Nós Status inicialmente se comunicavam através do protocolo Whisper, que se originou do projeto Ethereum como um protocolo Proof-of-Concept ponto a ponto para Dapps. A Status adotou o protocolo, pois parecia se adequar bem às nossas necessidades. Infelizmente, na realidade, havia vários problemas com ele, sendo os principais:

  • Problemas de escalabilidade, especialmente relacionados à largura de banda e natureza da transmissão
  • Fraca resistência a SPAM devido à incompatibilidade de proof-of-work com dispositivos móveis
  • Nenhuma forma integrada de fornecer incentivos para a execução de nós

Você pode ler em detalhes sobre os problemas de escalabilidade no excelente post "Fixing Whisper with Waku" de Oskar.

Por essas e muitas outras razões, o projeto Vac nasceu, e dele surgiu o protocolo Waku v1 - uma melhoria incremental do original. A principal diferença é o uso de interesses de tópico em vez de filtros Bloom para melhorar o uso da largura de banda, reduzindo as colisões e, de fato, reduzindo as entregas de envelopes indesejados.

Filtros Bloom

Um filtro Bloom é uma matriz de 512 bits (64 bytes) com todos os bits definidos como 0 por padrão. Esses bits são invertidos com base nos primeiros 4 bytes do hash SHA3-256 de determinado tópico, que é então convertido em 3 bits dos 512 disponíveis no filtro Bloom. Dessa forma, as informações sobre qual par está interessado em quais tópicos são ocultadas de quaisquer nós de retransmissão. O problema com essa abordagem é que ela também pode resultar em muitos falsos positivos, pois a inscrição em vários tópicos faria com que vários bits fossem invertidos no mesmo filtro.

Uma vez que o tamanho do filtro é de apenas 512 bits, e o número de canais que as pessoas podem se inscrever pode ser muito grande - até mesmo na casa das centenas - não seria tão improvável encontrar um par cujo filtro Bloom tenha mais da metade de seus bits invertidos, o que resulta em uma probabilidade muito alta de receber envelopes nos quais você não está interessado. Um filtro Bloom com todos os seus bits invertidos para 1 indicaria o desejo de receber todos os envelopes disponíveis.

Interesses de Tópico

Um tópico de interesse é um campo de 4 bytes que indica em quais mensagens o par na rede está interessado. O valor para este campo é derivado do hashing do nome do canal ou ID da partição com Keccak-256, mas em vez de convertê-lo para apenas 3 bits os primeiros 4 bytes são obtidos. Além disso, o Waku permite a definição de vários interesses de tópico para cada par, o que reduz drasticamente a possibilidade de uma colisão de tópico. No Waku v1, um par pode especificar até 10.000 interesses de tópico, efetivamente limitando o número de chats/grupos/comunidades em que eles podem se inscrever.

É importante notar que os interesses de tópico são um ajuste à compensação entre largura de banda e privacidade em favor de um melhor uso da largura de banda. Como os interesses de tópico contêm 4 bytes de dados em oposição a apenas 3 bits, é muito mais fácil identificar em quais canais um par está inscrito, fazendo o hash de nomes de canais bem conhecidos e comparando os resultados. E mesmo que o canal exato não seja conhecido, também é possível correlacionar aproximadamente se duas pessoas são membros do mesmo canal sem realmente saber qual é exatamente. Considerando os horríveis problemas de desempenho dos filtros Bloom, foi decidido que vale a pena compensar.

Descoberta de Pares

Originalmente, usamos os mesmos mecanismos de descoberta normais dos nós do Ethereum - um protocolo inspirado no Kademlia DHT, que armazena e retransmite os registros dos nós - antes era o Discovery v5 (mas o problema com essa abordagem é que ela também descobriria muitos nós que não se comunicavam com os protocolos de que precisávamos), Whisper e, posteriormente, Waku v1. Por esse motivo, implantamos nossa própria versão modificada do protocolo de descoberta, chamado Rendezvous, que aceleraria a descoberta de pares, limitando-a apenas a nós com os recursos corretos.

A próxima solução possível que pode fazer parte do Waku v2 é usar a descoberta de DNS proposta no EIP-1459, que é a solução preferida para dispositivos de poucos recursos, como telefones inteligentes. Mas a realidade é que a melhor solução para o problema da descoberta é usar vários métodos - ou tantos quanto possível - para mantê-lo confiável e descentralizado.

Histórico de Mensagens

Uma das habilidades cruciais de um Nó Status é fornecer mensagens históricas a pontos que nem sempre estão online para recebê-las. Originalmente, os Nós Status com essa funcionalidade eram chamados de Mailservers e essa nomenclatura foi mantida para o Waku v1, mas atualmente os chamamos de Nós de Histórico. Seu objetivo principal é armazenar todos os envelopes recebidos em algum formato - no caso de nossa frota, é o banco de dados PostgreSQL - e responder às perguntas dos colegas por envelopes que correspondam a interesses de um tópico específico por um período de tempo especificado.

Os nós que fornecem o histórico são considerados "confiáveis" por seus pares porque têm permissão para responder com envelopes expirados. Além disso, eles podem receber atualizações mais frequentes de colegas sobre seus interesses de tópico, uma vez que sempre que um usuário entrar em um novo canal, muito provavelmente solicitará o histórico de mensagens desse canal. Na verdade, um Nó de Histórico tem uma oportunidade muito melhor para tentar traçar o perfil de um par e analisar seus hábitos de mensagens do que um nó de retransmissão.

Além do Waku v1

Considerando que a v1 é apenas uma pequena melhoria incremental no protocolo Whisper original e nossas necessidades de um protocolo gossip com bom desempenho irão crescer gradualmente conforme nosso número de usuários aumenta, a equipe Vac começou a trabalhar na versão v2 em paralelo. A segunda iteração é diferente de seus ancestrais de tal forma que pode ser considerada um protocolo completamente novo.

O Waku v2 é construído usando LibP2P em vez de DevP2P e é dividido em vários subprotocolos, sendo os estáveis ​​ou quase estáveis:

  • Relay - receber e enviar mensagens dentro do mesmo tópico pub-sub
  • Store - Retornar mensagens históricas de nós de retransmissão com base nos interesses do tópico
  • Filtro - Recebimento barato de mensagens com base em interesses de tópicos específicos
  • Lightpush - Envio barato de mensagens sem fazer parte da rede Relay usando o tópico pub-sub

Bem como protocolos futuros instáveis ​​relacionados à descoberta de pares ou à aplicação de limites de mensagem e largura de banda:

Algumas das melhorias introduzidas pelo Waku v2 são:

  • Menor uso de largura de banda devido ao uso de roteamento GossipSub
  • Fatores de amplificação mais baixos que causam crescimento rápido dos recursos necessários com base no número de usuários
  • Limites mais baixos de conectividade de pares relacionados a limites de nós e malha de conexões na rede

Para uma análise mais aprofundada do Waku v2, leia os excelentes artigos de Oskar, como "What's the Plan for Waku v2?" e "Privacy-preserving p2p economic spam protection in Waku v2".

Utilidade dos Nós Status da Comunidade

Existem alguns motivos pelos quais a Status deseja que a comunidade execute seus próprios nós:

  1. Isso ajuda a tornar a rede menos dependente de nossa própria infraestrutura, na verdade tornando-a realmente descentralizada
  2. Isso pode facilitar a comunicação em locais onde nossa própria frota de Nós Status está sendo bloqueada
  3. Isso nos ajuda a pesquisar e entender melhor as limitações do Waku v1

No entanto, existem alguns efeitos prejudiciais. Devido à natureza de transmissão do Waku v1, os nós de retransmissão adicionais na rede aumentarão a quantidade de tráfego entre os nós de maneira exponencial. Devido à pequena escala do Programa de Nós, isso não deve ser um problema, mas pode indicar mais claramente a necessidade de implantar o Waku v2 o mais rápido possível devido ao uso insuficiente de recursos.

Se você estiver interessado em executar um Nó Status, visite o site do Programa de Nós.

Links