Implementação do escopo da votechainNode

Agora que os eleitores já podem votar, é necessário preparar a aplicação que será utili- zada pelos nós da rede. Além da estrutura da votechainNode facilitar o compartilhamento de dados, como foi dito anteriormente, uma interface simples e intuitiva foi utilizada, buscando facilitar seu entendimento.

Buscando manter a aplicação sempre disponível aos eleitores e aos outros nós, o Celery foi utilizado como gerenciador de tarefas programadas e/ou demoradas em segundo plano, tal como a mineração dos blocos ou o broadcast dos votos para os nós conhecidos.

36

Além disso, se o servidor do nó ficar temporariamente indisponível, mas o RabbitMQ atrelado à ele estiver funcionando, as mensagens recebidas serão guardadas pelo broker e reenviadas ao nó quando este voltar ao normal. Por outro lado, a votechainNode só usu- fruirá da plenitude de suas funcionalidades, caso Celery e RabbitMQ estejam “rodando”.

Considerando que a aplicação dos nós possui todos os serviços executando, ela está apta a receber os votos dos eleitores. Apesar de algumas verificações serem feitas no lado da aplicação cliente, nâo se pode garantir que as mensagens chegarão do mesmo jeito que foram enviadas, logo, as mesmas validações devem ser feitas no outro lado da conexão.

A primeira verificação realizada na votechainNode, é se a cópia da sua blockchain já possui algum voto do dado eleitor, no mesmo cargo do atual voto. Caso já exista algum voto, o que foi recebido por último é removido. A outra verificação que deve ser feita é relacionada à assinatura digital. Esta se baseia na chave pública do eleitor, na mensagem recebida e na própria assinatura digital, essas informações estão contidas no voto recebido.

A verificação da assinatura é baseada na comparação entre:

• O resultado da função hash utilizada para se gerar a assinatura, no caso SHA-256, na mensagem recebida;

• O resultado da decriptação da assinatura digital usando a chave pública do eleitor.

Figura 15: Verificação da assinatura digital

37

A assinatura só será considerada válida, caso os hashs gerados sejam iguais, como mostra a Figura 15. Após a etapa de validação ter sido completamente finalizada, começa o processo de broadcast dos votos para os nós conhecidos. Este será constituído unicamente pelo envio do voto validado, para cada um dos nós conhecidos.

3.1.4.1 Mineração dos Blocos

A etapa de mineração dos blocos pode ser interpretada como a função mais complexa de ambas as aplicações e portanto, merece uma atenção especial.

A primeira particularidade dessa função está relacionada à sua execução. A mine- ração dos blocos será iniciada à cada 5 minutos, de maneira automática e em segundo plano, graças ao agendador de tarefas do Celery, o Celery Beat. Com apenas algumas configurações no projeto da aplicação, esse serviço pode executar qualquer função criada, periodicamente.

Como a mineração é iniciada automaticamente, é importante executá-la apenas quando não estiver acontecendo outra mineração, evitando assim qualquer inconsistência, logo, uma verificação como esta é executada assim que a função é iniciada. Outra verificação que acontece no início da mineração, é relacionada à qual o nó conhecido que possui a melhor blockchain. Para tanto, uma requisição até a página de informações básicas desse nó é realizada, retornando dentre várias coisas, a quantidade de blocos do nó.

Existem três possibilidades distintas à partir daqui.

1. As blockchains de todos os nós conhecidos possuem no máximo a mesma quantidade de blocos que a sua.

2. A melhor blockchain dos nós conhecidos possui um bloco à mais que a sua.

3. A melhor blockchain dos nós conhecidos possui mais de um bloco que a sua, ou, sua cópia da blockchain está inválida.

A opção 1 é a mais trivial e não precisa de nenhuma ação extra.

A opção 2 representa o caso em que a sua cópia da blockchain está um pouco desatu- alizada e portanto, necessita de sincronização. Este problema é resolvido requisitando-se ao nó de melhor blockchain, o seu último bloco, e incorporando-o ao final de sua cadeia de blocos.

38

A opção 3 representa o caso em que sua cadeia de blocos está completamente desatu- alizada, ou pior, possui alguma inconsistência. Quando se está nessa situação, o melhor a fazer é desconsiderar toda sua cadeia e requisitar a melhor de todas, ao nó que a possui, adotando esta.

Independente de qual tenha sido o caso, ao final das alterações ocorridas (ou não), a cópia de sua blockchain será a melhor (ou uma das melhores) dentre todos os seus nós conhecidos. O passo seguinte da aplicação é minerar um novo bloco.

Essa mineração é iniciada por uma sequência de revalidações, passo necessário para se garantir a redundância de verificações, uma das principais características de um sis- tema baseado na segurança. As verificações buscam por votos que possuam assinaturas inválidas ou votos múltiplos de um mesmo eleitor em um dado cargo, removendo todas as inconsistências encontradas.

Após essa série de revalidações, a aplicação verifica se restam votos sem nenhum bloco atrelado à eles. Caso existam, os cinco mais antigos(no máximo), são escolhidos para serem incluídos no novo bloco e a Prova de Trabalho se inicia. Ao ser concluída, mais votos terão sido incluídos na blockchain e ela estará ainda mais atualizada.

39

4

Resultados

Para se realizar uma análise dos resultados, um processo eleitoral foi simulado. Esta simulação foi baseada na utilização de duas aplicações clientes, além de quatro aplicações para os nós. A estratégia de execução das aplicações foi a seguinte:

• O computador rodou uma aplicação cliente na porta 9000 e uma aplicação para os nós na porta 8000; A aplicação dos nós necessitava de serviços auxiliares represen- tados por uma instância do Celery, uma do Celery Beat e outra do RabbitMQ, cada uma delas em um container dedicado;

• Uma segunda máquina para a aplicação dos clientes foi executada em um container dedicado, e mapeada para a porta 9001 da máquina local;

• Três máquinas distintas para a aplicação dos nós foram executadas em containers dedicados e diferentes. Cada um deles foi mapeado para as portas 8001, 8002 e 8003, respectivamente, da máquina local. Além disso, o Docker Compose foi necessário para fazer com que os serviços auxiliares fossem integrados aos nós citados.

A figura 16 ilustra a estrutura da rede criada para a simulação.

Figura 16: Estrutura da rede criada Fonte: Autoria Própria

40

O primeiro passo para a realização da simulação é o cadastramento de um eleitor na aplicação cliente. Um exemplo deste passo pode ser visto na Figura 17.

Figura 17: Tela de cadastro de um eleitor na aplicação ‘Cliente 1’ Fonte: Autoria Própria

Em seguida, uma urna (nome dado na aplicação aos nós) deve estar disponível para receber os votos. A aplicação dos nós pode ser vista na Figura 18.

Figura 18: Tela do ‘Nó 1’ informando que sua cadeia de blocos está vazia Fonte: Autoria Própria

41

Essa configuração inicial é suficiente para a realização de um voto. Na Figura 19 podemos ver quais informações precisam ser inseridas pelo eleitor no ato do voto. O título de eleitor e a assinatura digital, gerada pela aplicação, também serão enviados ao nó.

Figura 19: Tela do ‘Cliente 1’ mostrando a criação de um voto Fonte: Autoria Própria

O resultado da operação anterior pode ser visto na Figura 20.

Figura 20: Tela do ‘Cliente 1’ após o voto, mostrando a lista de votos já realizados Fonte: Autoria Própria

42

Supondo que mais eleitores houvessem utilizado a mesma máquina para cadastrarem- se, o que teria acontecido caso algum eleitor tentasse utilizar a chave privada de outro para votar? A Figura 21 mostra o resultado dessa operação.

Figura 21: Tela do ‘Cliente 1’ impedindo o eleitor de votar com dados de outra pessoa Fonte: Autoria Própria

Uma funcionalidade desenvolvida para tornar a votechainClient robusta e indepen- dente da disponibilidade de apenas um nó, foi “Adicionar Urna”, oferecendo a possibilidade de conectar a aplicação à quaisquer nós. A lista de nós conectados é vista na Figura 22.

Figura 22: Tela do ‘Cliente 2’ mostrando sua lista de nós conhecidos Fonte: Autoria Própria

43

Para se adicionar um nó à uma aplicação cliente, esta verifica se o ip e a porta inseridos, realmente representam um nó. Caso representem, ainda deve ser conferido se este nó é válido. Essas informações podem ser acessadas na tela demonstrada na Figura 23.

Figura 23: Tela do ’Nó 2’ mostrando suas informações básicas Fonte: Autoria Própria

As conexões do nó podem ser visualizadas na aba Connected Nodes, como mostra a Figura 24, executada à partir do “Nó 1”.

Figura 24: Tela que mostra as conexões do ‘Nó 1’ com o ‘Nó 2’ e o ‘Nó 3’ Fonte: Autoria Própria

44

Supondo que o ‘Cliente 1’ realize votos numa frequência bem maior que o ‘Cliente 2’, o ‘Nó 4’ inevitavelmente se tornará desatualizado em algum momento e precisará portanto sincronizar sua cadeia de blocos com seus conhecidos, no caso o ‘Nó 1’.

Como foi dito na Seção 3.1.1, o envio dos dados é feito através de uma resposta no formato JSON. Um exemplo do arquivo enviado quando se solicita a blockchain de um nó, pode ser visto na Figura 25.

Figura 25: Resposta dada pelo ’Nó 1’ ao ’Nó 4’ da requisição de sua blockchain, em JSON Fonte: Autoria Própria

Após isso, o ‘Nó 4’ terá a melhor blockchain de sua rede, porém, esta pode não ser necessariamente a melhor existente, o que aumenta a necessidade de uma rede com o maior número possível de conexões.

45

Durante qualquer momento do processo eleitoral, é possível visualizar o resultado parcial, baseando-se nos votos realizados, validados e já minerados. Esses votos estarão disponíveis dentro da lista de blocos do nó e estão acessíveis à partir da aba Block List. A Figura 26 mostra o resultado da operação descrita.

Figura 26: Tela do ‘Nó 4’ mostrando a lista com todos os seus blocos de votos Fonte: Autoria Própria

46

5

Conclusão

Em suma, o presente trabalho propôs a criação de uma aplicação baseada em block- chain, para ser utilizada como um modelo alternativo de votação, através do uso de ferramentas baseadas em criptografia e no gerenciamento de tarefas concorrentes.

Dois tipos de aplicações complementares foram implementadas através da linguagem Python e do framework de desenvolvimento Web Django. A primeira delas foi focada nos eleitores e funciona como um site comum, já a segunda aplicação, foi voltada para os nós da rede e é caracterizada como uma API REST, podendo ainda ser acessada como um site comum, mas oferecendo diversas melhorias no processo de envio e recebimento de dados. Vários níveis de verificações e validações foram implementadas em ambas as aplica- ções, a fim de aumentar a segurança do sistema completo, além de diversas técnicas para melhorar o processamento dos dados e garantir maior disponibilidade à rede.

Ao se analisar os resultados obtidos após diversas execuções de validação, o trabalho foi considerado satisfatório, por ter cumprido todas as metas traçadas e explicadas durante o seu desenvolvimento. Além disso, o sistema construído se mostra robusto o suficiente para ser usado como base de projetos maiores relacionados ao tema.