Versão Alfa 0.7 Lançada!

Introdução

O alfa 0.7 chegou. Esta é uma ótima oportunidade para agradecer à comunidade pelo apoio e estar aqui neste marco, pois é certamente um dos mais importantes que alcançamos.

A versão 0.7 é inteiramente sobre a rede da Tangram. Ela vem com um nível adicional de anonimato que foi originalmente planejado para o longo prazo mas decidimos adiantar, à medida que chegamos à conclusão de que é algo necessário de ser implementado mais cedo.

O objetivo deste artigo é explicar as atualizações na nova versão.

  1. Introdução à arquitetura de rede da Tangram através da lógica, e delineando as propriedades que compõem os protocolos de fofoca.

2. Modificações na camada de rede e também no sistema de armazenamento e pesquisa

3. Variação em uma abordagem básica para obter uma estratégia mais robusta e eficiente, manipulando membros em uma rede e como isso é aplicado na Tangram.

4. Particularidades do armazenamento específico e do sistema de pesquisa (Kadence) implementado na Tangram

5. Recursos atualmente integrados que o Kadence oferece

6. Modelo de segurança que está sendo operado atualmente

7. Informações sobre o número de nodes na versão 0.7 e suas especificações, juntamente com uma breve visão geral e considerações futuras de avaliação de desempenho.

Por último, mas não menos importante, estamos anunciando que um nível adicional de anonimato foi antecipado: A Tangram agora funciona na livre e aberta rede TOR!

Uma introdução à topologia de rede da Tangram

A Tangram utiliza um protocolo de fofocas para gerenciar associações e eventos de nodes organizados de maneira arbitrária. A organização dos nodes é referida como topologia de rede. Nossa topologia de escolha será detalhada em outro parágrafo. Nesta seção, discutimos o protocolo de fofocas usado pela Tangram, que é baseado no “SWIM: Protocolo de Associação de Grupo de Processos de Estilo Infeccioso Fracamente-consistente e Escalável”. — Nós aconselhamos fortemente as pessoas que querem saber mais a ler o artigo no link. Logo a baixo, a tentativa da Tangram de descrever e reformular a abordagem de maneira simples.

Resumidamente, um protocolo de associação fornece a cada processo (“membro”) do grupo uma lista mantida localmente, de outros processos sem falhas. O protocolo garante que a lista de membros seja atualizada com as alterações resultantes de novos membros que ingressam no grupo ou que abandonam (voluntariamente ou por falha). [SWIM]

Conceitos básicos de um protocolo de fofocas

Existem dois componentes importantes no protocolo SWIM:

  1. Componente de Detecção de Falha, que detecta falhas de membros

2. Componente de Divulgação, que divulga informações sobre membros que recentemente aderiram, deixaram o grupo ou falharam.

Ambos os componentes trabalham em conjunto sequencialmente para garantir que quatro características chave atendam à composição dos protocolos de detecção de falhas.

Integridade forte: a falha de qualquer membro do grupo é detectada por todos os membros sem falhas

Velocidade de detecção de falha: o intervalo de tempo entre uma falha de um membro e sua detecção por outros membros sem falhas do grupo.

Precisão: a taxa de positivos falsos de detecção de falhas;

Carregamento da Mensagem da Rede, em bytes por segundo, gerada pelo protocolo. [Detectores de falhas não confiáveis ​​para sistemas distribuídos confiáveis]

Componente de Detecção de Falha

Com a detecção de falhas no SWIM, o procedimento a seguir ocorre. Um “ping” de um membro arbitrário da lista de membros (Alice) para um membro aleatório (Bob) dentro dessa lista. Alice então espera por uma resposta “ack” de Bob dentro de um tempo pré-definido (definido para 5 segundos).

Se Alice não receber uma resposta (‘ack’), ela indiretamente sondará Bob selecionando aleatoriamente um subgrupo de detecção de falha (Carol, Dave , Eve, etc…) e enviará uma mensagem ping-req a cada membro. Cada um desses membros então sondam Bob com o mesmo ping e encaminha (se recebido de Bob) o ack para Alice.

Alice verifica se algum ack foi recebido de Bob ou de Carol, Dave e Eve (sub-grupo de detecção de falhas). Se nenhum foi recebido de Bob e sua lista de membros, então Alice declara Bob como “falho” em sua lista de membros e fornece esta atualização ao Componente de Divulgação, que descrevemos abaixo.

Há alguns cenários no componente de detecção de falhas descrito acima que podem causar positivos falsos e é nesse ponto que é necessário haver um mecanismo para reduzir esse número na rede. Cenários:

1. Perda de pacotes de rede

2. Bob está dormindo

3. Alice tem um processo lento

Porém, um ou mais desses determinam que Bob deveria e seria removido de seu cluster dentro da rede.

Processo falho

Uma vez que Alice detectou que Bob falhou, ela notifica sua lista de membros. Os membros desse grupo excluem Bob da lista de membros.

Processo de abandono

O mesmo procedimento ocorre quando novos membros se juntam ou membros que saem voluntariamente.

Processo de junção

Quando um membro deseja ingressar na rede da Tangram, as mensagens de junção são transmitidas e agrupa membros dentro de um cluster que está ouvindo mensagens de associação probabilisticamente (jogando uma moeda) para responder.

Existem várias outras formas de membros ingressarem em um cluster (lista de membros).

1.Servidor bem conhecido ou endereço de IP multicast, todas as junções podem ser direcionadas para o endereço associado

2. Um coordenador estático pode ser mantido dentro do grupo com a finalidade de manipular solicitações de associação de grupo

3. Vários coordenadores são mantidos dentro de um grupo

O SWIM eficiente e robusto é apresentado com o seguinte:

Descrevemos brevemente a abordagem básica para um protocolo SWIM. Discutiremos agora a abordagem usada na Tangram, descrita mais detalhadamente no whitepaper em breve.

1.Componente de disseminação no estilo de infecção

2.Mecanismo de suspeita

3.Seleção de alvo de sonda round-robin (para completude forte limitada pelo tempo)

Componente de divulgação no estilo de infecção

A premissa do componente de disseminação do estilo de infecção é fazer um backup das atualizações de associação nas mensagens ping, ping-req e ack enviadas pelo protocolo de detecção de falhas. Essa abordagem beneficia o protocolo, dando mais qualidades às perdas de pacotes e de baixa latência do protocolo de detecção de falhas ao componente de divulgação, eliminando pacotes extras.

O que isso significa é que mensagens de falha, junção ou abandono são colocadas no mesmo pacote / transferência como ping, ping-req e ack, menos tipos de mensagens = menor taxa de falha e maior consistência de taxa de transferência de mensagens.

Mecanismo de suspeita

Nós descrevemos a abordagem básica para que o protocolo SWIM declare que um membro (Bob) falhou. Também foram descritas as razões alternativas pelas quais um membro poderia ser falsamente classificado como falho (devido a positivo falso). Para abordar a natureza probabilística da classificação, um subprotocolo de suspeita é introduzido.

Dessa forma, sempre que o componente detector de falhas encontra um pacote defeituoso de Bob, Carol, Eve ou quaisquer outros membros (como descrito acima), em vez de Alice declarar Bob como falho, forçando Bob a deixar o grupo, Alice declara Bob como suspeito na lista e então propaga essa mensagem através do Componente de Divulgação e todos os membros marcam Bob com a mesma mensagem. Isso é feito utilizando um procedimento de estilo de infecção, conforme descrito acima, em vez da abordagem básica do SWIM. Ou seja, Bob agora é suspeito e não é expulso da rede e, em vez disso, é tratado como um membro normal, onde os pings ainda seriam enviados a Bob para retornar se uma falha é verdadeira.

Existem dois cenários possíveis:

1.Bob foi vítima de um positivo falso

2.Bob é de fato um membro falho

Bob é vítima de um positivo falso

Se Bob ainda estiver marcado como suspeito em qualquer lista de membros de Alice quando ele responder com êxito com ack, ele não é identificado como suspeito e Alice transmite que Bob está vivo no grupo (através do Componente de Divulgação). Naturalmente, Bob não é mais suspeito. É importante notar que sempre que Bob é marcado como suspeito, ele transmite a mensagem de que está vivo imediatamente a todos os membros para propagação.

Bob é de fato um membro fracassado

Se Bob ainda estiver marcado como suspeito e não responder com uma mensagem de que está vivo antes de um tempo limite pré-especificado (5 segundos), os membros que já tiverem Bob como suspeito em sua lista transmitirão uma mensagem que confirma que Bob é de fato um membro falho e o remove da sua lista de membros.

Seleção de alvo por sonda round-robin

Acima descrevemos brevemente como o componente de detecção de falha no SWIM seleciona um membro (Alice) aleatoriamente de sua lista de associação (Bob), isso satisfaz a característica de Completude Forte em protocolos de detecção de falha, onde a detecção seria eventual. Isso pode, no entanto, levar a um grande atraso no processo entre os membros.

Uma solução para isso seria modificar a abordagem básica do SWIM, de modo que Alice não selecione um membro de sua lista de membros aleatoriamente (Bob), mas sim de modo round-robin.

Vamos dar um exemplo de um novo membro se juntando a um cluster. Bob é selecionado por Alice para fazer parte do mesmo cluster e fazer ping com Bob exatamente uma vez durante cada atualização na lista de membros dela, o que reduz a taxa de tempo de detecção de falhas de qualquer membro para Alice. Isso satisfaz a propriedade Completude de Tempo Limitado para que os membros sejam detectados como defeituosos ou sem falhas na lista de associação de Alice.

Kademlia

Descrevemos acima o processo de um protocolo de associação de grupo (SWIM). Com isto, descrevemos um sistema de armazenamento e pesquisa peer-to-peer utilizando o Kademlia.

O Kademlia possui vários recursos desejáveis ​​que não são oferecidos simultaneamente por qualquer sistema peer-to-peer anterior. É minimizado o número de mensagens de configuração que os nodes devem enviar para aprenderem um sobre o outro. As informações de configuração se espalham automaticamente como um efeito colateral das principais pesquisas. Os nodes têm conhecimento e flexibilidade suficientes para rotear consultas por caminhos de baixa latência, pois o Kademlia utiliza consultas assíncronas paralelas, a fim de evitar atrasos devido à nodes falhos. O algorítmo com o qual os nós registram a existência um do outro resiste a certos ataques básicos de negação de serviço. [Kademlia]

Para implementar um sistema de pesquisa e armazenamento peer-to-peer distribuído, a Tangram utiliza a biblioteca de estrutura de sistemas distribuídos extensível, reforçada e segura do Kadence, com algumas modificações que incorporam SWIM e Kadence para serem totalmente suportados no TOR e uma operação lockstep para envio e recebimento, que descreveremos na próxima seção.

Principais características do Kadence, atualmente em uso na Tangram:

Proteção contra DDoS e Spam

O Kadence aplica um sistema de prova de trabalho chamado Hashcash para retransmitir mensagens para evitar abusos e fazer negações de serviço em larga escala e custos de spam proibitivos.

Criptografia de ponta a ponta

O Kadence pode gerar automaticamente certificados SSL e suporta criptografia completa de ponta a ponta por meio de TLS usando o adaptador de transporte HTTPS integrado para impedir a espionagem e ataques de interceptação.

Identidades Criptográficas

O Kadence estende a seleção de identidade de nós do Kademlia com a mesma criptografia que o Bitcoin usa para garantir fundos. As identidades do node são derivadas do hash da parte pública de um par de chaves ECDSA e cada mensagem é assinada para garantir que ela não tenha sido adulterada em trânsito.

Mitigação Sybil & Eclipse

O Kadence emprega um sistema de prova de trabalho (PoW) usando o Scrypt para gerar identidades de nó válidas e posterior aceitação na rede de sobreposição. Isso força os nodes em setores suficientemente aleatórios do espaço de chaves e faz com que ataques Sybil e Eclipse sejam computacionalmente extremamente difíceis e, em última instância, ineficazes.

Traversal automático de NAT

O Kadence suporta múltiplas estratégias para penetrar na tradução de endereços de rede. Isso permite que peers, mesmo sobre os firewalls mais restritos, tornem-se endereçáveis ​​e entrem na rede. O fallback para proteger túneis reversos é suportado através do uso de servidores Diglet.

Múltiplos Transportes de Rede

O Kadence suporta o uso de múltiplos adaptadores de transporte e é agnóstico ao protocolo de rede subjacente. Suporte por padrão para UDP e envio HTTP / HTTPS. Plugue sua própria camada de transporte personalizada usando uma simples interface.

Tabelas de Roteamento Persistentes

O Kadence lembra os peers entre as reinicializações assim que você se une à rede, uma vez que as associações subsequentes são rápidas e selecionam automaticamente os melhores peers iniciais para bootstrapping.

Anonimato do remetente e do destino

O Kadence é fornecido com suporte total para o TOR, sem instalação de software adicional ou configuração necessária. Isso permite redes estruturadas totalmente anônimas e aproveita a versão mais recente do protocolo de serviços ocultos.

Lockstep

Vamos explicar o que é uma operação lockstep antes de detalhar como ela funciona na Tangram:

Suponha que Alice enviou uma transação a Bob e inclui:

1.O endereço

2.O valor da transação

Alice clica em enviar e uma operação lockstep primeiro enviará as propriedades e notificarão Bob de que uma transação está chegando. Bob agora está ciente, recebe a notificação e aguarda que a transação ocorra, então ele verifica a transação com base na operação lockstep.

O processo e o lockstep funcionam da seguinte maneira, onde um par de chave / valor é criado e passado para a função hash das entidades de mensagem.

Em seguida, é adicionado à entidade lockstep.

A chave fica à mostra e o hash é a combinação da chave e do valor.

Isso é passado como uma notificação para os outros nodes (Bob). Quando é recebida por Bob, ele armazena a mensagem lockstep (nenhuma verificação é processada se existir uma chave). A chave será substituída pelo novo valor, ou seja, criará uma nova entrada.

O lockstep é usado para validação quando dados extras ou com a mesma chave são recebidos. A chave é utilizada como uma pesquisa sobre o armazenamento e só pode fazer isso se o lockstep for visto, ou seja, com a chave para recuperar os dados que correspondem ao hash enviado, com o hash armazenado e, portanto, ela só passa como mensagem válida.

Modelo de segurança

Modelos de segurança sob os quais estamos operando:

  • Atores terceiros (não membros de um cluster dentro da rede) obtendo acesso a eventos
  • Membro (s) em uma manipulação de cluster
  • Mensagens inválidas / transferência de dados
  • Ataques “man in the middle”
  • Ataques de negação de serviço à rede ou a qualquer membro (s) da rede

n Nodes e especificações

Haverá 6 nodes totalmente validados. Seguindo as especificações para o lançamento inicial.

3:

2 núcleos

RAM: 6 GB

Armazenamento em disco: 500GB SSD-Boosted

Largura de banda: porta de 100 Mbit / s tráfego ILIMITADO

SO: Linux — CentOS7

Após o lançamento inicial, 3 nodes adicionais serão trazidos para testes, que são os seguintes:

3:

4 núcleos

RAM: 14GB

Armazenamento em disco: 1000GB SSD-Boosted

Largura de banda: porta de 100 Mbit / s tráfego ILIMITADO

SO: Linux — CentOS7

Avaliação de desempenho

O que demonstramos aplica-se a versão 0.7 e será testada com um cluster de membros de 1 membro cada, que compõem 3 clusters com 6 para estarem totalmente operacionais na próxima semana.

Todas as mensagens e transferências são feitas através de pacotes TCP, pois é a limitação da arquitetura TOR. O tamanho máximo de carga útil é de 2kb.

Mais testes de desempenho serão lançados dentro das próximas 2 semanas da data de lançamento.

Considerações Futuras

  • Medição de Largura de Banda
  • Políticas Confiáveis ​​Configuráveis
  • Medição do Onion load
  • e muito mais…

Resumo

A Tangram está crescendo constantemente e ainda está engatinhando. Com a introdução da versão alfa 0.7, consolidamos uma base sólida para fortalecer o software e avançar para aprimoramentos e otimização adicionais.

A chave para esta versão foi combinar vários recursos para a propagação de node a node, bem como a integridade de dados da comunicação do node dentro da rede e muito mais.

Aguardamos perguntas, sugestões e discussões. E, mais uma vez, um grande obrigado à comunidade pelo seu apoio.

Atualizaremos este artigo com base no feedback da comunidade.

REFERÊNCIAS

(link ao artigo em inglês)

Se você quiser conhecer de perto a Tangram e sua comunidade, participe de nossas mídias sociais:

Discord: https://discordapp.com/invite/eZJfaGG

Twitter: twitter.com/tangramd