Votechain, uma solução mais segura, acessível e inovadora ...€¦ · Agradeço primeiramente à Deus por toda a capacidade que me foi dada, mas mais ... 1 Introdução Oprotocoloentituladode“Bitcoin:APeer-to-PeerElectronicCashSystem”

Universidade Federal do Rio Grande do NorteCentro de Tecnologia

Departamento de Engenharia de Computação e AutomaçãoCurso de Engenharia de Computação

Votechain, uma solução mais segura, acessívele inovadora para as eleições, implementada

com a tecnologia Blockchain

Thúlio Mattheus Pereira de Sousa

Natal-RN

Junho de 2019

Thúlio Mattheus Pereira de Sousa

Votechain, uma solução mais segura, acessível einovadora para as eleições, implementada com a

tecnologia Blockchain

Trabalho de Conclusão de Curso de Enge-nharia de Computação da Universidade Fe-deral do Rio Grande do Norte, apresentadocomo requisito parcial para a obtenção dograu de Bacharel em Engenharia de Compu-tação.

Orientador

Prof. Dr. Carlos Manuel Dias Viegas

Universidade Federal do Rio Grande do Norte - UFRNCentro de Tecnologia - CT

Departamento de Engenharia de Computação e Automação - DCACurso de Engenharia de Computação

Natal-RN

Junho de 2019

Trabalho de Conclusão de Curso de Graduação sob o título "Votechain, uma solução mais

segura, acessível e inovadora para as eleições, implementada com a tecnologia Blockchain"

apresentada por Thúlio Mattheus Pereira de Sousa e aceita pelo Departamento de En-

genharia de Computação e Automação do Centro de Tecnologia da Universidade Federal

do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora

abaixo especificada:

Prof. Dr. Carlos Manuel Dias ViegasPresidente

Departamento de Engenharia de Computação e Automação -DCA

Universidade Federal do Rio Grande do Norte - UFRN

Prof. Me. Sérgio Natan SilvaExaminador

Departamento de Engenharia de Computação e Automação -DCA

Universidade Federal do Rio Grande do Norte - UFRN

Prof. Me. Francisco Sales de Lima FilhoExaminador

Instituto Federal do Rio Grande do Norte - IFRN

Natal-RN, 24 de Junho de 2019

Dedico este trabalho primeiramente aos meus pais João Tomé e Joana D’arc, aos meus

familiares mais próximos à quem sou grato por tudo, aos meus poucos e grandes amigos,

e por último mas não menos importante, à companheira que sempre me apoiou e me deu

forças principalmente nos momentos de dificuldade, Kamila Medeiros.

Agradecimentos

Agradeço primeiramente à Deus por toda a capacidade que me foi dada, mas mais

ainda, pelas forças para enfrentar a vida quando a capacidade deixou de ser suficiente.

Dentre os parentes à quem mais devo agradecimento, destaco meus tios Márcia, Arthur

e Paula, por sempre terem me oferecido mais do que apenas o conhecimento necessário

para me destacar, mas principalmente pelo aprendizado humano e dedicação investida.

Além destes, um agradecimento especial é destinado a minha avó Maria Aparecida,

pois se meus tios muitas vezes se aproximaram de pais, esta senhora muitas vezes se

comportou como tal e por isso possuirá meus eternos agradecimentos.

Outra pessoa que merece uma lembrança destacada das demais é minha irmã Bruna.

Apesar de nunca termos sido exemplo desses clichês idealizados pela sociedade, com cer-

teza, à nossa maneira, sempre prezamos um pelo outro e por isso, a ela sou muito grato.

Apesar da distância e da personalidade complicada de ambos, alguém pelo qual possuo

admiração e devo muitos agradecimentos, é meu pai, o “Seu João”. Algumas qualidades

fundamentais à um homem como perseverança, trabalho duro e dedicação, sobram para

este senhor e o tornam alguém em quem se espelhar, até mesmo para mim.

Minha mãe. É, à esta cidadã devo inúmeros agradecimentos. Por todo o amor recebido,

pelos momentos de sacrifício vividos, na tentativa de me proporcionar coisas que a ti nunca

foram ofertadas, pelo enorme incentivo dado aos meus estudos e por todo o resto, agradeço

de coração. Tenho certeza de que não será a última vez que a farei orgulhosa.

Finalizando os agradecimentos, gostaria de lembrar da minha companheira Kamila.

Mesmo sendo complicado, crítico e exigente, tenho a sorte de ter uma pessoa incrivelmente

alegre, otimista e amorosa ao meu lado. “Bacorinha”, agradeço por você estar comigo nos

momentos alegres e mas ainda nos complicados, espero não parar de te orgulhar nunca.

Menções honrosas são dadas à meus familiares: Belise, Ketura, Miumo, Paulo, Sarah

e vovó Albertina, meus amigos de infância Thiago, André, Danyllo e Arthur, meus amigos

de curso Isaac, Dmytres e Judson, meus amigos de trabalho Adryel, Mateus, Lailson e

Diogo, além do meu orientador Viegas. Obrigado a todos, vocês também são parte disso.

“Ter em si próprio uma confiança exagerada é um excelente treino intelectual.”

Tristan Bernard

Votechain, uma solução mais segura, acessível einovadora para as eleições, implementada com a

tecnologia Blockchain

Autor: Thúlio Mattheus Pereira de Sousa

Resumo

Este trabalho apresenta uma alternativa ao atual modelo de votação executado no Brasil,

através do uso de uma blockchain. As técnicas utilizadas foram baseadas na blockchain do

Bitcoin e implementadas com adaptações, utilizando a linguagem de programação Python

e o framework de desenvolvimento Web, Django. A arquitetura do sistema é baseada em

uma rede Ponto-a-Ponto, em que não existe um servidor centralizador para guardar todas

as informações do cliente como nas aplicações comuns, em vez disso, todos os nós da

rede, em conjunto, são responsáveis por tal tarefa. Diversas estratégias como criptografia

assimétrica, criptografia de senhas na aplicação cliente e geração de assinaturas digitais,

foram utilizadas para garantir a segurança exigida durante um processo eleitoral. Os

resultados alcançados são observados em tempo real, ao se simular uma votação utilizando

contêineres em Docker para representar diferentes nós e alguns usuários conectados para

simular os eleitores. Pretende-se dar continuidade ao trabalho realizado, implementando

diversas melhorias que tornem o sistema ainda mais robusto e confiável.

Palavras-chave: Blockchain, Eleições, Criptografia, Segurança de Redes.

Votechain, a safer solution, accessible and innovative toelections, implemented with Blockchain technology

Author: Thúlio Mattheus Pereira de Sousa

Abstract

This work introduces a alternative to the current model of votation executed in Brazil,

through the use of a blockchain. The adopted techniques were based on Bitcoin block-

chain and implemented with adaptations, using the programming language Python and

the web development framework Django. The system architecture was based in a Peer-

To-peer network, where there is no centralizer server to store all information of client as

in common applications, instead, all nodes of network together, are responsible to such

task. Several strategies like asymmetric encryption, password encryption on client appli-

cation and digital signature generation, were utilized to guarantee the required security

during the electoral process. The achieved results are observed in real time by simula-

ting a votation using Docker containers to represent different nodes and some connected

users to simulate the electors. The intention is to continue the work, implementing many

improvements that make the system even more robust and confiable.

Keywords : Blockchain, Elections, Cryptography, Computer Network Security.

Lista de figuras

1 Exemplo da blockchain de um nó. . . . . . . . . . . . . . . . . . . . . . p. 15

2 A blockchain anterior, após uma alteração nos dados . . . . . . . . . . p. 16

3 Exemplo da blockchain como lista distribuída de blocos . . . . . . . . . p. 17

4 Arquitetura de rede Ponto a Ponto . . . . . . . . . . . . . . . . . . . . p. 18

5 Consumo de energia do Bitcoin num período de um ano . . . . . . . . . p. 19

6 Exemplo de Cifragem de Mensagem com Criptografia Simétrica . . . . p. 22

7 Exemplo de Cifragem de Mensagem com Criptografia Assimétrica . . . p. 23

8 Exemplo de Assinatura Digital com Criptografia Assimétrica . . . . . . p. 23

9 Exemplo de Função Hash . . . . . . . . . . . . . . . . . . . . . . . . . p. 24

10 Estrutura da Votechain . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26

11 Diagrama de Implantação UML das aplicações . . . . . . . . . . . . . . p. 28

12 Diagrama Entidade-Relacionamento da votechainClient . . . . . . . . . p. 28

13 Diagrama Entidade-Relacionamento da votechainNode . . . . . . . . . p. 29

14 Exemplo de chave privada . . . . . . . . . . . . . . . . . . . . . . . . . p. 34

15 Verificação da assinatura digital . . . . . . . . . . . . . . . . . . . . . . p. 36

16 Estrutura da rede criada . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39

17 Tela de cadastro de um eleitor na aplicação ‘Cliente 1’ . . . . . . . . . p. 40

18 Tela do ‘Nó 1’ informando que sua cadeia de blocos está vazia . . . . . p. 40

19 Tela do ‘Cliente 1’ mostrando a criação de um voto . . . . . . . . . . . p. 41

20 Tela do ‘Cliente 1’ após o voto, mostrando a lista de votos já realizados p. 41

21 Tela do ‘Cliente 1’ impedindo o eleitor de votar com dados de outra pessoa p. 42

22 Tela do ‘Cliente 2’ mostrando sua lista de nós conhecidos . . . . . . . . p. 42

23 Tela do ’Nó 2’ mostrando suas informações básicas . . . . . . . . . . . p. 43

24 Tela que mostra as conexões do ‘Nó 1’ com o ‘Nó 2’ e o ‘Nó 3’ . . . . . p. 43

25 Resposta dada pelo ’Nó 1’ ao ’Nó 4’ da requisição de sua blockchain, em

JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44

26 Tela do ‘Nó 4’ mostrando a lista com todos os seus blocos de votos . . p. 45

Lista de abreviaturas e siglas

P2P – Peer to Peer

API – Application Programming Interface

REST – Representational State Transfer

HTTP – Hypertext Transfer Protocol

JSON – JavaScript Object Notation

UML – Unified Modeling Language

DER – Diagrama Entidade-Relacionamento

Sumário

1 Introdução p. 13

1.1 Motivação e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

1.2 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14

2 Referencial Teórico p. 15

2.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

2.2 Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

2.2.1 Django Rest Framework . . . . . . . . . . . . . . . . . . . . . . p. 20

2.2.2 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

2.2.3 Celery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

2.3 Criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22

2.3.1 Criptografia Simétrica . . . . . . . . . . . . . . . . . . . . . . . p. 22

2.3.2 Criptografia Assimétrica . . . . . . . . . . . . . . . . . . . . . . p. 23

2.3.3 Função Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24

2.4 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

2.4.1 Docker Compose . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

3 Desenvolvimento p. 26

3.1 Estrutura da Votechain . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26

3.1.1 Definição do escopo das aplicações . . . . . . . . . . . . . . . . p. 26

3.1.2 Modelagem do Banco de Dados . . . . . . . . . . . . . . . . . . p. 28

3.1.2.1 Blocos . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

3.1.3 Implementação do escopo da votechainClient . . . . . . . . . . . p. 33

3.1.4 Implementação do escopo da votechainNode . . . . . . . . . . . p. 35

3.1.4.1 Mineração dos Blocos . . . . . . . . . . . . . . . . . . p. 37

4 Resultados p. 39

5 Conclusão p. 46

5.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46

Referências p. 47

13

1 Introdução

O protocolo entitulado de “Bitcoin: A Peer-to-Peer Electronic Cash System” (NAKA-

MOTO, 2008), que livremente traduzindo para o português significa “Bitcoin: Um Sistema

Financeiro Eletrônico Ponto-a-Ponto”, foi responsável por descrever o Bitcoin e suas de-

pendências, construindo assim, a primeira aplicação com a tecnologia Blockchain (GOYAL,

2018).

Nos anos seguintes, o Bitcoin obteve uma valorização grande, chegando ao ponto

de no fim de 2017 ter sua unidade valendo R$ 69.700,00 (BITCOIN, 2018). Por causa

de todo esse sucesso, a blockchain foi diretamente atrelada à criação de moedas digitais

seguras, sendo novamente utilizada como base do Ethereum, Litecoin e todas as outras.

Entretanto, essa tecnologia tem potencial para ser utilizada em diversas outras áreas,

como saúde, entretenimento e transportes (MARR, 2018).

1.1 Motivação e Objetivos

Um dos maiores problemas durante a época de eleições, está diretamente relacionado

à desconfiança gerada na população pela forma como o processo acontece (SILVA, 2018).

Uma das queixas do modelo atual, se deve à dificuldade em obter transparência no

processo inteiro, ao se restringir o grupo verificador dos votos, fazendo com que alguns

acreditem até mesmo que o modelo antigo -o voto impresso- pudesse ser uma melhor

solução, como afirma o professor doutor do Instituto de Computação da Universidade

Estadual de Campinas e coordenador de equipes nos testes públicos de segurança de 2012

e 2017 (ARANHA, 2018), (MONTE, 2018).

Alguns países como Japão e Estados Unidos já iniciaram os experimentos de migração

do modelo eleitoral atual, para um modelo baseado em blockchain (BEEDHAM, 2018). No

fim do ano passado a empresa ABFintechs realizou a primeira eleição feita com blockchain

no Brasil (HAMIDEH, 2019). Ao se analisar as notícias e a busca crescente pela adoção do

14

modelo proposto, este trabalho terá grande importância no atual estado de compreensão

da tecnologia.

A proposta deste trabalho é fazer uso dos benefícios trazidos pela blockchain na esfera

eleitoral, a fim de prover uma alternativa segura que possivelmente cause menos descon-

fiança e mais inclusão para a população. O modelo proposto se baseia em:

• Garantir a privacidade dos eleitores;

• Oferecer camadas de verificações que detectem e invalidem qualquer alteração feita

nos votos originais;

• Oferecer transparência ao processo inteiro;

• Permitir a possibilidade de uma votação prática e à distância.

1.2 Estrutura do Trabalho

A metodologia utilizada para a realização do trabalho corrente, foi baseada em uma

pesquisa que se deu através da leitura de diversos artigos, tutoriais e textos explicativos,

citados ao longo do documento.

Este trabalho é constituído fundamentalmente de 5 capítulos, este primeiro busca

mostrar ao leitor, os objetivos e motivações da criação da plataforma Votechain. O segundo

capítulo oferece o embasamento teórico das tecnologias utilizadas no desenvolvimento da

plataforma como Django, Docker e Blockchain. O terceiro capítulo é responsável por

explicar todo o desenvolvimento realizado, nele serão apresentadas dentre outras coisas,

a estrutura das aplicações criadas, os modelos dos bancos de dados utilizados e uma

explicação de como se deu a mineração dos blocos. O capítulo seguinte trata dos resultados

obtidos, mostrando algumas telas da aplicação e explicando as operações sendo realizadas.

Por fim, o último capítulo é a conclusão, onde se realiza uma breve análise dos resultados

obtidos, comparando-os com os previstos no início do projeto, além de citar os trabalhos

futuros que serão realizados, com a finalidade de melhorar a Votechain e torná-la mais

robusta.

15

2 Referencial Teórico

Para se desenvolver um sistema robusto e de maior complexidade, é comum os arqui-

tetos de software utilizarem ferramentas auxiliares como frameworks de desenvolvimento

Web, gerenciadores de tarefas assíncronas, agendadores automáticos de tarefas e bancos

de dados. A plataforma Votechain possuirá todas as necessidades citadas anteriormente,

além de outras que serão introduzidas nas próximas seções.

2.1 Blockchain

A Blockchain é uma lista distribuída de registros, conhecidos como blocos, interco-

nectados com o uso de criptografia (TAPSCOTT; TAPSCOTT, 2016). Cada bloco da cadeia

é geralmente constituído por seu identificador, o hash do bloco anterior, o hash do bloco

atual, a hora de criação do bloco (timestamp), os dados à serem guardados e um número

inteiro conhecido por Nonce que está relacionado à dificuldade do bloco e será melhor

explicado na Seção 3.1.2.1. Uma estrutura semelhante a esta é representada na Figura 1.

Figura 1: Exemplo da blockchain de um nó.

Fonte: https://anders.com/blockchain/blockchain.html

16

Ao analisar a Figura 1, é possível observar que o bloco 2 possui o hash anterior

igual ao hash atual do bloco 1. Além disso, nota-se que todos os hashs dos dois blocos,

começam com alguns caracteres iguais à zero. Essa estratégia é frequentemente utilizada

como definição da dificuldade do bloco e está diretamente relacionada ao atributo nonce.

Modificações nos valores de qualquer um dos atributos do bloco, geram uma alteração

em seu hash atual, tornando a blockchain inválida. Por tal motivo, sua estrutura se mostra

resistente à modificações. Um exemplo desse comportamento é ilustrado na Figura 2.

Figura 2: A blockchain anterior, após uma alteração nos dados

Fonte: https://anders.com/blockchain/blockchain.html

Percebe-se que o hash atual do bloco 2 não possui a mesma quantidade de caracteres de

antes, indicando que houve alguma alteração nos dados do bloco e, portanto, a blockchain

se tornou inválida.

Os exemplos mostrados nas Figuras 1 e 2 estão relacionados à apenas uma instância

da blockchain, porém, pelo fato desta ter sido definida como uma lista distribuída de

blocos, algumas operações adicionais precisam ser realizadas. Uma ilustração de como se

daria essa distribuição mencionada, pode ser vista na Figura 3.

17

Figura 3: Exemplo da blockchain como lista distribuída de blocos

Fonte: https://anders.com/blockchain/distributed.html

Partindo desse princípio, um pré-requisito fundamental para a construção de uma

blockchain é a utilização de uma rede que permita a interconexão de vários computadores

(LISK, 2019). Dessa forma, eles poderão trocar informações diretamente com facilidade.

Fazendo uma análise das principais arquiteturas de rede existentes, percebe-se que

a mais recomendada neste caso é a Peer to Peer, abreviada como P2P e traduzida

como Ponto a Ponto (BASSOTTO, 2018). Esta é caracterizada por substituir o modelo

utilizado na grande maioria das aplicações, o cliente-servidor, por um modelo onde os nós,

nome dado aos computadores da rede, podem funcionar tanto como clientes quanto como

servidores. Dessa maneira, cada nó torna-se independente de outros nós, entretanto, no

caso da P2P utilizada na Blockchain, os nós devem buscar o contínuo compartilhamento

de dados com o resto da rede, evitando a possibilidade de tornarem-se obsoletos. Um

exemplo da arquitetura P2P é visto na Figura 4.

18

Figura 4: Arquitetura de rede Ponto a Ponto

Fonte: https://medium.com/rodrigo-soares/blockchain-visão-arquitetural-4df7363fd42b

Essa arquitetura remove problemas como a existência de um ponto central de falha

que possa ser explorado por invasores mal intencionados (VU; LUPU; OOI, 2009). Além

disso, remove problemas de disponibilidade, pois caso algum nó deixe de existir ou torne-

se indisponível, outros nós possuirão uma cópia de suas informações e o substituirão.

Mesmo a blockchain possuindo diferentes versões individuais em cada nó, deve se fazer

presente uma forma de escolher a melhor de todas, a fim de resolver problemas como o

mostrado na Figura 3. Nela pode-se ver que somente a blockchain do nó ’A’ é válida,

tornando-se assim a melhor da rede e devendo ser utilizada por todos os nós da mesma.

Um algoritmo de consenso que geralmente é utilizado para definir qual a melhor

blockchain da rede, é o da maior cadeia válida (DEXTER, 2018). Esse algoritmo considera

a blockchain do nó que possui a maior quantidade de blocos como a melhor, tendo ainda

a restrição adicional de que mais da metade dos nós da rede a considere válida.

A blockchain possui dois tipos diferentes de usuários, os nós e os clientes (SARDAN,

2018). Os clientes têm o intuito de utilizar apenas as informações da blockchain que os

interessam, não precisando portanto de uma cópia inteira da mesma.

Por outro lado, os nós são responsáveis por guardar uma cópia inteira da melhor

cadeia, além de possuírem a possibilidade de minerar novos blocos na mesma. Mineração

é o nome dado à criação e indexação de novos blocos ao fim da blockchain.

A dificuldade dos blocos da blockchain está relacionada à mineração do próprio bloco.

Essa dificuldade é baseada na busca de um nonce que torne o hash atual aceitável. Ten-

19

tando explicar de uma maneira simplificada, suponha que caso a dificuldade de mineração

de um bloco seja 4, ele precisa de quatro zeros como caracteres iniciais no seu hash atual.

Caso ela aumente para 8, passará a precisar de oito zeros. Essa dificuldade pode aumentar

ou diminuir, dependendo da função utilizada.

Geralmente, com o aumento de blocos na cadeia, a dificuldade de mineração tende a

crescer, tornando-se algo demorado e caro por necessitar de um maior poder computaci-

onal e um grande aumento de energia para se obter os mesmos resultados.

Para tornar o processo de criação de blocos atrativo aos mineradores, nome dado aos

criadores dos blocos, algoritmos de consenso foram desenvolvidos. Um dos mais conhe-

cidos é o Proof of Work, em português, Prova de Trabalho (TAR, 2018). Esse algoritmo

recompensa o primeiro minerador à resolver a função matemática, com algo de seu inte-

resse. No caso do Bitcoin, o primeiro minerador que consegue gerar um novo bloco válido,

recebe alguns satoshis, menor unidade monetária da criptomoeda (BITCOIN.ORG, 2019).

Técnicas como essa têm fundamental importância no ecossistema da blockchain, por

oferecer mais benefícios aos que “jogam limpo” e prejudicar os que tentam burlar as regras,

já que a maneira mais conhecida de se obter vantagem é possuir um poder computacional

maior do que metade da rede, problema conhecido como ataque dos 51 por cento (S.,

2018). Entretanto, pelo valor gasto de energia na posse de tal poder computacional, ser

maior do que o valor ganho ao minerar os blocos, a prática se torna desencorajada. Um

exemplo do alto consumo de energia gerado na mineração pode ser visto na Figura 5.

Figura 5: Consumo de energia do Bitcoin num período de um ano

Fonte: https://digiconomist.net/bitcoin-energy-consumption

20

2.2 Django

Django (DJANGO, 2019) é um framework bastante utilizado no desenvolvimento de

aplicações Web com Python. Frameworks Web são bibliotecas que oferecem um conjunto

de funções básicas para acessar a rede, já implementadas. Além disso, o Django se destaca

por algumas características como:

• Disponibilização de funcionalidades voltadas para segurança quase nunca ofertadas,

mas extremamente recorrentes, como controle de acesso, autenticação do usuário e

tratamento modular da verificação das senhas;

• Estrutura de projeto baseada em aplicativos, permitindo maior desacoplamento e

reuso das aplicações construídas;

• Fornecimento de uma conexão padrão já configurada ao SQLite, banco de dados

relacional para persistir os dados dos modelos do projeto;

• Maior comunidade de desenvolvedores dentre todos os frameworks Web para Python,

aumentando com isso a quantidade de soluções pré-existentes para diversas aplica-

ções.

Por esses e outros motivos que serão melhores compreendidos ao longo deste docu-

mento, o Django foi utilizado para configuração e desenvolvimento do projeto, permitindo

assim a criação das interfaces de usuário que serão utilizadas pelos eleitores e pelos nós

da blockchain.

2.2.1 Django Rest Framework

API é um conjunto de rotinas e padrões de programação que permitem o acesso à

dados de uma aplicação sem uma ligação direta com seu código. Já REST é um estilo

de arquitetura de software baseado em verbos HTTP , que tem a finalidade de integrar

aplicações pela Web. Ou seja, uma API REST permite que os dados de uma aplicação

sejam acessados de maneira indireta com o intuito de se integrarem a outra aplicação

Web.

O Django REST Framework (VINCENT, 2018) é um aplicativo que oferece diversas

funcionalidades para se construir uma aplicação deste tipo, e por tal razão foi utilizado

para permitir o acesso por parte dos eleitores, aos dados dos nós da blockchain sem

comprometê-los.

21

2.2.2 JSON

A API facilitará o compartilhamento dos dados, dado que será baseada em verbos

HTTP como o GET, para consultar dados, ou o POST, para adicionar registros. Além

disso, o formato dos dados manipulados será o JSON . Alguma das vantagens desse

formato em comparação aos outros disponíveis, são: maior facilidade de leitura e escrita,

maior velocidade na execução e transporte de dados, menor tamanho dos arquivos gerados

e estrutura baseada em objetos. Um exemplo desse formato pode ser visto no pseudocódigo

abaixo.

{

"numero" : 123 ,

" f r a s e " : "Uma␣ f r a s e ␣de␣ t e s t e " ,

" decimal " : 1 . 5 ,

" vetorDeFrutas " : [ "Uva" , "Maca" , "Laranja " ] ,

" d i c i o n a r i o " : {

" a t r ibu to1 " : "Qualquer␣ c o i s a " ,

" f l a g " : true

}

}

2.2.3 Celery

Celery (ALVES, 2015) é uma fila de tarefas assíncronas que se baseia na passagem

distribuída de mensagens e é usada como mecanismo para distribuir o trabalho entre

threads ou máquinas. Ela é focada nas operações em tempo real mas também suporta

agendamento de tarefas.

A ferramenta se fez necessária no momento que os nós realizavam o broadcast dos vo-

tos, mas concorrentemente, precisavam continuar acessíveis para consulta na API REST.

De maneira similar, a geração dos blocos de votos precisava ser executada periodicamente,

e por tal motivo decidiu-se por utilizar o agendador de tarefas do Celery, o Celery Beat

(BARTOSZ, 2018).

Como foi dito anteriormente, o Celery se baseia na passagem distribuída de men-

sagens, e para tal, necessita de um intermediário para enviá-lo as mensagens. O broker,

nome dado à esses intermediários, utilizado foi o RabbitMQ (CELERY, 2019), indicado

pela própria ferramenta em sua documentação.

22

2.3 Criptografia

A segurança da informação sempre foi indispensável à vida das pessoas, isso pode ser

comprovado em atitudes como: realizar treinos fechados à imprensa antes de um grande

jogo, não divulgar sua senha do banco para ninguém, ou até mesmo rasgar bilhetes confi-

denciais logo após sua leitura. Por tal motivo, um dos principais critérios para se avaliar

a qualidade de um sistema, é sua segurança.

Um dos principais artifícios para se garantir tal atributo, é fazer uso de criptografia.

Criptografia é o ato de codificar e decodificar dados, a fim de dificultar sua real interpre-

tação por pessoas não autorizadas (STALLINGS, 2014). Os principais tipos de criptografia

utilizados na grande maioria das aplicações são: Criptografia Simétrica, Criptografia As-

simétrica e Função Hash (KESSLER, 2019).

2.3.1 Criptografia Simétrica

A criptografia simétrica, ilustrada na Figura 6, é caracterizada pela utilização de

apenas uma chave tanto para a encriptação da mensagem original, quanto para a decodi-

ficação da mensagem encriptada. O principal atributo desta metodologia é a garantia de

privacidade, dado que apenas os detentores da chave conseguirão ter acesso à mensagem

original.

Figura 6: Exemplo de Cifragem de Mensagem com Criptografia Simétrica

Fonte: https://en.wikipedia.org/wiki/Cryptography

23

2.3.2 Criptografia Assimétrica

A criptografia assimétrica, ilustrada na Figura 7, diferentemente da anterior faz uso

de duas chaves, uma que será usada pelo remetente e cifrará a mensagem original e outra

que o destinatário usará com o intuito de decriptar a mensagem recebida. Qualquer uma

das chaves é capaz de realizar as operações especificadas, entretanto, apenas a outra será

capaz de realizar a operação inversa, graças as propriedades matemáticas que as definem.

Figura 7: Exemplo de Cifragem de Mensagem com Criptografia Assimétrica


Outra aplicação importante da criptografia assimétrica é a geração de assinaturas

digitais. Estas são baseadas em sua chave privada e podem ser verificadas por qualquer

um que possua a respectiva chave pública, como ilustrado na Figura 8.

Figura 8: Exemplo de Assinatura Digital com Criptografia Assimétrica


24

Além disso, essa técnica garante a autenticidade da mensagem, pois Bob conseguiu

verificar a assinatura ao utilizar a chave pública de Alice, além do não-repúdio, caracterís-

tica de algo que não se pode negar, pois apenas a chave privada de Alice pode ter gerado

aquela assinatura. Por este motivo, esse é um dos principais conceitos da blockchain e será

usado para aumentar a segurança do sistema desenvolvido.

2.3.3 Função Hash

O último tipo de criptografia bastante utilizado é a Função Hash. Esta técnica encripta

uma mensagem de uma maneira tal, que esta não pode retornar ao seu formato original

por intermédio de uma função inversa, pelo fato da primeira função ser capaz de gerar

um mesmo resultado para diferentes mensagens de entrada. Uma demonstração de seu

uso pode ser visualizada na ilustração abaixo.

Figura 9: Exemplo de Função Hash

Fonte: http://learningspot.altervista.org/cryptographic-hash-functions/

Apesar da mensagem não poder retornar ao seu estado original, a verificação do resul-

tado gerado para uma dada mensagem, é facilmente obtido ao se aplicar a tal mensagem

na função hash. Este conceito será utilizado na criação e verificação das assinaturas ci-

tadas anteriormente, além de ser a estratégia para se autenticar as senhas de acesso e

chaves privadas dos eleitores, salvando no banco de dados apenas seus hashs, realizando

uma perfeita verificação sem ter acesso à informação original.

25

2.4 Docker

Docker (DOCKER, 2019) é uma ferramenta utilizada para tornar os processos de cons-

trução, execução e implantação de aplicações, mais simplificados, através da criação de

uma imagem desta aplicação.

As imagens do Docker são pacotes que contém todas as dependências necessárias

para se construir à aplicação nas quais foram baseadas. Caso ainda esteja complicado de

entender, pense nos executáveis utilizados para se instalar um programa no computador,

a operação realizada é similar.

Diferentemente dos executáveis, essas imagens podem ser usadas em diversos sistemas

operacionais, a fim de recriarem a aplicação original. Isso acontece graças aos Containers

do Docker.

A finalidade dos containers é isolar a aplicação empacotada, do resto do sistema, a

fim de torná-la reusável em qualquer outro computador que possua o Docker instalado.

Além disso, mais de um container pode ser utilizado para rodar uma mesma imagem,

podendo com isso serem entendidos como instâncias da aplicação.

2.4.1 Docker Compose

Em determinadas situações, é necessário isolar um conjunto de aplicações conecta-

das, ao invés de apenas uma aplicação e com esse intuito foi criado o Docker Compose

(TUNGKA, 2018).

Esta ferramenta é responsável por rodar ambientes com múltiplos containers integra-

dos, sendo capaz de replicar uma infraestrutura de serviços inteira.

No corrente trabalho, a ferramenta foi fundamental na simulação de uma votação real,

criando uma rede conectada por diversos serviços.

26

3 Desenvolvimento

3.1 Estrutura da Votechain

O primeiro passo para se construir a Votechain é definir sua estrutura. Como foi dito

no capítulo 2, uma blockchain possui dois tipos de usuários, nós e clientes, no caso da

Votechain não será diferente. Por este motivo, ela possuirá duas aplicações complementa-

res, uma que deve ser usada pelos eleitores, a votechainClient, e outra que deve ser usada

pelos nós da rede, a votechainNode. A Figura 10 ilustra essa estrutura.

Figura 10: Estrutura da Votechain

Fonte: Autoria Própria

3.1.1 Definição do escopo das aplicações

Cada aplicação possuirá uma série de funcionalidades distintas, que visam compreen-

der as necessidades de seus usuários. Vejamos as que estão relacionadas à votechainClient :

• Permitir registro dos eleitores na aplicação e gerar seu par de chaves;

• Permitir que o eleitor vote em um dado cargo, caso ele ainda não o tenha feito;

• Validar a identidade do eleitor e seu voto. Caso tudo esteja válido, gerar uma

assinatura digital para o voto;

• Enviar voto, o número do titulo do eleitor e a assinatura gerada para o primeiro

nó conhecido que esteja disponível;

• Guardar apenas os dados da votechain relacionados ao eleitor;

27

Buscando atender as necessidades citadas, foi decidido que uma aplicação Web seria

utilizada.

Por outro lado, a votechainNode terá uma perspectiva mais voltada aos nós da rede,

por isso, terá às seguintes tarefas:

• Estar disponível à aplicação dos eleitores, a fim de receber, validar e guardar os

votos;

• Reenviar os votos válidos para todos os nós conhecidos;

• Minerar blocos de votos de maneira periódica;

• Tornar sua blockchain disponível, em formato acessível, aos outros nós;

• Criar novos blocos com os votos que ainda não estão na blockchain;

• Verificar se algum nó conhecido possui uma blockchain mais atualizada que a

sua, em caso positivo, agir de acordo com as seguintes possibilidades:

– Caso I) A blockchain do nó conhecido é válida e possui um bloco a mais

que a sua. Nesse caso, deve-se incorporar este último bloco à sua cópia da

blockchain.

– Caso II) A blockchain do nó conhecido é válida e possui mais de um bloco

a mais que a sua. Nesse caso, deve-se substituir a sua cópia da blockchain

pela do nó conhecido.

• Guardar uma cópia completa da melhor blockchain da rede;

Diferentemente da aplicação cliente, a votechainNode terá uma alta taxa de troca

de informações, graças aos diversos clientes conectados, e à conexão feita com os outros

nós conhecidos. Por causa disso, é fundamental utilizar uma maneira rápida e fácil de se

compartilhar dados. Ao analisar essas informações, foi decidido que uma API REST seria

a forma mais recomendada para a aplicação dos nós.

O Python possui uma biblioteca para se conectar com APIs e manipular arquivos

JSON, a Requests Library(RONQUILLO, 2019). Esta foi utilizada durante o desenvolvi-

mento da Votechain. Após essa estruturação e definição do escopo da Votechain, vejamos

como ficou o Diagrama de Implantação UML de cada uma das aplicações na Figura 11.

28

Figura 11: Diagrama de Implantação UML das aplicações


3.1.2 Modelagem do Banco de Dados

Assim foi definida a necessidade de uma aplicação para os eleitores e outra para os

nós, haverá também um banco de dados distinto para cada aplicação.

O Diagrama Entidade-Relacionamento mostrado na Figura 12, dá a ideia de como

será o banco de dados da votechainClient.

Figura 12: Diagrama Entidade-Relacionamento da votechainClient


29

A aplicação dos eleitores conterá três entidades principais: Nós, Votos e Usuários.

Vejamos uma breve explicação de cada uma delas.

A entidade Nó é constituída, além de seu id, de apenas três atributos, o IP e a porta

do nó conhecido, e uma chave estrangeira para a tabela Usuario, simbolizando a conexão

do dado eleitor com o nó.

Já a entidade Voto possui apenas informações relacionadas ao candidato que foi vo-

tado, ao usuário que realizou o voto e à assinatura digital gerada pela aplicação.

Por fim, a entidade Usuario contém somente informações do próprio eleitor. Por outro

lado, dois de seus atributos merecem uma atenção especial, a senha e a chave privada.

Ambas, não poderiam ser salvas no banco em texto limpo, pois isso seria caracterizado

como uma grave falha de segurança.

Para resolver o problema encontrado, ao invés de salvar a senha e a chave privada

no banco, apenas o resultado da função hash SHA-256 (BELLET, 2018) aplicada à cada

um dos atributos mencionados foi salvo no banco. Dessa forma, quando o usuário for se

autenticar no sistema, a aplicação usará a senha inserida no login como entrada dessa

mesma função hash e comparará com o resultado salvo no banco, caso os valores sejam

iguais, o usuário terá acesso ao sistema. Processo semelhante será realizado com a chave

privada.

Após definir o modelo da aplicação cliente, o próximo passo é analisar o DER da

votechainNode.

Figura 13: Diagrama Entidade-Relacionamento da votechainNode


30

O diagrama da Figura 13 possui diversas semelhanças com o da Figura 12 . A primeira

delas é que as entidades Nó e Voto posuem exatamente os mesmos atributos, além da

ausência do atributo idUsuario, dado que esta aplicação não necessitará de autenticação,

o sistema foi construído de maneira à automatizar as tarefas mais cruciais, explicadas

posteriormente, garantindo com isso sua segurança.

Apesar da ausência citada na tabela Voto, um novo atributo se fez presente, o idBloco.

Para um eleitor, não faz diferença em qual bloco o voto dele estará na blockchain, entre-

tanto, para os nós, definir isso é fundamental e motiva a inclusão deste relacionamento.

3.1.2.1 Blocos

A única entidade que ainda necessita de análise é Bloco. Esta possui os mesmos

atributos definidos na primeira seção do capítulo 2, mas algumas considerações extras

devem ser realizadas. Em primeiro lugar, explicaremos a função usada para calcular a

dificuldade.

Esse cálculo se baseará na quantidade de tempo gasto nas minerações dos últimos

blocos, considerando que o tempo médio ideal para se minerar um bloco, seja de 3 minutos.

Apesar de grande parte do trabalho ter se baseado na blockchain do Bitcoin, essa definição

de tempo foi completamente arbitrária.

Vejamos como foi implementada a função para então a explicarmos.

# Funcao para re tornar a d i f i c u l d a d e a t ua l i z a da do b l oco a t ua l

def r e to rneDi f i cu ldadeB locoAtua l ( ) :

# A cada n="tamanhoBlocosPorRodada " , a t u a l i z a r a d i f i c u l d a d e

tamanhoBlocosPorRodada = 5

# Di f i cu l dade i n i c i a l da b l o c k cha in

se ( quant idadeBlocosBlockchain = 0 ) :

r e t o rne 4

senao :

# No caso de ser uma nova rodada

# A d i f i c u l d a d e dos b l o co s des ta nova rodada deve ser a jus tada

31

se ( blocoAtualPertenceNovaRodada ) :

# Diferenca de tempo entre o u l t imo e o

# primeiro b l oco da rodada an t e r i o r

diferencaTempo = horaUltBlocoRodAnt − horaPriBlocoRodAnt

# Caso demore menos de 3 minutos por b l oco

se ( diferencaTempo < 3 minutos por b loco ) :

r e t o rne ( d i f i c u l dadeB l o coAnt e r i o r + 1)

# Caso demore menos de 3 minutos por b l oco

senao se ( diferencaTempo > 5 minutos por b loco ) :

r e t o rne ( d i f i c u l dadeB l o coAnt e r i o r − 1)

# Caso nenhum caso an t e r i o r tenha s ido atendido

r e t o rne d i f i c u l dadeB l o coAnt e r i o r

Como o pseudocódigo anterior demonstra, existe uma verificação da necessidade de

atualização dos blocos na aplicação. Caso o bloco atual seja múltiplo de 5, verifique:

1. Caso o tempo gasto entre o primeiro bloco da última rodada e o último bloco da

mesma rodada, seja inferior à 3 minutos por bloco, quer dizer que está muito fácil

minerar, então aumente a dificuldade em 1.

2. Caso o tempo gasto no mesmo período, seja superior à 5 minutos por bloco, quer

dizer que está muito difícil minerar, então diminua a dificuldade em 1.

3. Caso o tempo gasto no mesmo período, esteja entre 3 e 5 minutos por bloco, quer

dizer que a dificuldade está boa, então use a anterior.

Outro atributo interessante da entidade Bloco é o hashBlocoAtual. Ele é baseado em

todos os outros atributos dessa entidade, exceto o Id, ou seja, se o valor de qualquer

atributo mudar, o hash atual também mudará. Além disso, ele precisa ter os N primeiros

caracteres iguais à zero, onde N é igual à dificuldade do bloco.

A função utilizada para definir esse hash atual é bem simples, mas bastante custosa.

Vejamos um pseudocódigo para explicar seu cálculo.

32

# Atr i bu to s com va l o r e s d e f i n i d o s antes da cr iacao do b l oco

i n d i c e = ind i c e do bloco an t e r i o r + 1

votes = l i s t a dos votos em JSON

hashBlocoAnter ior = Hash atua l do b loco an t e r i o r

hashBlocoAtual = 11111111111111111111

# Atr i bu to s d e f i n i d o s antes da i t e r a cao

nonce = 0

d i f i c u l d ad e = funcao de d i f i c u l d ad e

hashBlocoAtual = hashBlocoAtual

# N i gu a l a d i f i c u l d a d e

enquanto ( pr ime i rosNCaracte re sDi f e rentesDeZero ( hashBlocoAtual ) ) :

nonce = nonce + 1

timestamp = hora e data a tua i s

# Lis ta com os a t r i b u t o s do b l o co

l i s t aA t r i b u t o s = [

ind i c e ,

dateToStr ing ( timestamp ) ,

votes ,

nonce ,

d i f i c u l dade ,

hashBlocoAnter ior

]

hashBlocoAtual = encryptSha256 ( concatenate ( l i s t aA t r i b u t o s ) )

Como pudemos ver, o nonce é basicamente um incrementador que só para de crescer

quando os primeiros N caracteres do hash atual do bloco são iguais à zero. Essa tarefa

pode parecer simples, mas com o crescimento da dificuldade, o tempo necessário para

tal operação pode crescer exponencialmente. Para fins de curiosidade, em alguns dos

testes realizados durante à construção da aplicação, uma dificuldade igual à 4 era feita de

maneira praticamente instantânea, entretanto quando à crescia para 6, o tempo decorrido

33

geralmente passava de meia hora. A operação que acabou de ser explicada é conhecida

como Proof of Work, ou Prova de Trabalho e é um dos algoritmos de consenso mais

utilizados atualmente.

Agora que finalmente passamos por todas essas definições de modelos de entidades e

seus atributos, podemos seguir para a próxima etapa.

3.1.3 Implementação do escopo da votechainClient

Relembrando o escopo da aplicação cliente, vemos que uma de suas primeiras neces-

sidades é permitir que os eleitores se cadastrem e recebam um par de chaves.

Como foi dito na subseção 2.2 que fala sobre o Django, este framework oferece diversas

funcionalidades pré-implementadas por padrão, algumas estão diretamente relacionadas

aos usuários, como cadastro e login.

Dada a especificidade da aplicação desenvolvida, algumas modificações tiveram que

ser realizadas como a criação do par de chaves e o tratamento especial à chave privada.

Assim como a senha de acesso do eleitor, sua chave privada não fica salva no banco

de dados, mas seu hash sim. Por outro lado, diferentemente da senha, o usuário -salvo

algumas exceções- não tem como lembrar de uma sequência tão grande de caracteres. Um

exemplo da chave pode ser visto na Figura 14.

Para contornar este problema, a estratégia adotada foi gerar um arquivo contendo a

chave privada em seu formato original e disponibilizá-lo offline na máquina do cliente.

Dessa maneira, toda vez que o eleitor precisar inserir a chave privada, na geração da

assinatura digital do voto, este poderá fazer uso do arquivo, utilizado pela aplicação

apenas para leitura, sem comprometer seus dados por mantê-los disponíveis apenas em

seu computador.

34

Figura 14: Exemplo de chave privada


A segunda funcionalidade definida no escopo da aplicação cliente é fundamental para

o propósito da votação, o voto único. No início do projeto houveram muitas dúvidas com

relação à criação ou não de uma entidade para os candidatos, mas baseando-se no modelo

atual, foi considerado que os candidatos seriam escolhidos por seus partidos e teriam seus

números divulgados na mídia.

Com isso, definimos que a funcionalidade consistirá de uma busca na própria base

de dados, a fim de verificar se o eleitor conectado já realizou algum voto no cargo em

questão. Em caso negativo, as outras verificações são iniciadas.

Como já foi mencionado no 4o parágrafo desta seção, o usuário precisa entrar com

sua chave privada no momento do voto. No caso de duas pessoas utilizarem o mesmo

computador, há a possibilidade de alguém querer se aproveitar dessa situação e tentar

votar pela outra pessoa, utilizando tua chave privada. Infelizmente para esta pessoa, a

aplicação valida o hash da chave inserida, comparando-o com o hash salvo no banco e

impedindo assim a realização do voto.

35

Após essa validação de identidade ter sido concluída, caso o usuário esteja realmente

usando a própria chave privada e não tenha votado no cargo em questão ainda, o sistema

deve gerar uma assinatura digital e anexá-la ao voto. Com base na introdução de assina-

tura apresentada no capítulo anterior, vejamos como é realizada sua geração na aplicação.

A biblioteca cryptography (CRYPTOGRAPHY, 2019) foi utilizada como base.

Para gerar a assinatura, são necessários a chave privada do eleitor, a mensagem (os

dados do voto) e um algoritmo para gerar uma função hash. Mais uma vez o algoritmo esco-

lhido para tal tarefa foi o SHA-256. A função disponibilizada pela biblioteca cryptography,

ainda permite a utilização de uma variável chamada salt. Essa variável serve como uma

espécie de identidade da assinatura, por gerar duas assinaturas diferentes mesmo quando

se utiliza os mesmos dados de entrada, por causa dos salts diferentes.

Com a geração da assinatura digital, o voto foi validado com sucesso e já está pronto

para ser enviado à algum nó conhecido, com a intenção de ser minerado e integrado à

Votechain. Como se pôde ver no DER ilustrado na Figura 12, uma entidade para represen-

tar os nós conhecidos pela aplicação do eleitor se faz presente. Esses nós serão utilizados

apenas no momento de finalização dos votos, sendo responsáveis por recebê-los e tratá-los.

A estratégia utilizada para a comunicação entre as aplicações é baseada na utiliza-

ção da biblioteca Requests do Python e na lista de nós conhecidos. O processo é iniciado

quando a aplicação cliente tenta enviar o voto recém-finalizado para algum dos nós co-

nectados, caso haja indisponibilidade por parte deste nó, a aplicação tentará outro, até

que receba uma confirmação de sucesso ou tenha percorrido todos os nós.

Para concluir o escopo da votechainClient, a aplicação deve guardar apenas as infor-

mações relacionadas ao próprio eleitor. Entretanto, esse requisito já é contemplado em

sua modelagem, graças à existência do relacionamento entre usuários e votos.

3.1.4 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

Fonte: https://medium.com/@meruja/digital-signature-generation-75cc63b7e1b4

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


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’


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


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


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


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


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


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


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’


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


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


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.

5.1 Trabalhos Futuros

Algumas funcionalidades importantes à uma votação, como a contagem de votos para

cada candidato e a validação do título eleitoral por ambas as aplicações, são listadas

como fundamentais numa próxima versão do sistema. Entretanto, a maior prioridade será

a criação de métodos que garantam a manutenção de votos contidos apenas localmente,

ao se desprezar o próprio conjunto de votos e blocos e adotar a melhor blockchain da

rede. Esse problema pode ser considerado como praticamente inexistente em redes com

múltiplas conexões entre nós.

47

Referências

ALVES, F. Tarefas demoradas de forma assíncrona com Django e Celery. Jul 2015.Disponível em: <https://fernandofreitasalves.com/tarefas-assincronas-com-django-e-celery/>. Acesso em 16 de jun. de 2019.

ARANHA, D. F. Voto impresso pode tornar eleições mais seguras e transparentes.2018. Disponível em: <https://blogs.oglobo.globo.com/ciencia-matematica/post/voto-impresso-pode-tornar-eleicoes-mais-seguras-e-transparentes.html>. Acesso em 20 de jun.de 2019.

BARTOSZ. How to schedule ‘the Boring Stuff’ with Django and Celery Beat. 2018.Disponível em: <https://www.merixstudio.com/blog/django-celery-beat/>. Acesso em18 de jun. de 2019.

BASSOTTO, L. P2P ou “peer-to-peer”: Como funciona uma rede sem intermediários?Aug 2018. Disponível em: <https://cointimes.com.br/p2p-ou-peer-to-peer-como-funciona/>. Acesso em 20 de jun. de 2019.

BEEDHAM, M. Japan is experimenting with a blockchain-powered voting system.Sep 2018. Disponível em: <https://thenextweb.com/hardfork/2018/09/03/japan-city-blockchain-voting/>. Acesso em 20 de jun. de 2019.

BELLET, C. Part 5: Hashing with SHA-256. Jan 2018. Disponível em:<https://medium.com/biffures/part-5-hashing-with-sha-256-4c2afc191c40>. Acesso em17 de jun. de 2019.

BITCOIN, P. do. Há um ano atrás o Bitcoin atingia o maior preço da história. Dec2018. Disponível em: <https://portaldobitcoin.com/ha-um-ano-atras-o-bitcoin-atingia-o-maior-preco-da-historia/>. Acesso em 20 de jun. de 2019.

BITCOIN.ORG. Blockchain Guide. Jun 2019. Disponível em:<https://bitcoin.org/en/blockchain-guide#proof-of-work>. Acesso em 20 de jun.de 2019.

CELERY. Using RabbitMQ. 2019. Disponível em:<https://docs.celeryproject.org/en/latest/getting-started/brokers/rabbitmq.html>.Acesso em 16 de jun. de 2019.

CRYPTOGRAPHY. Welcome to pyca/cryptography. 2019. Disponível em:<https://cryptography.io/en/latest/>. Acesso em 18 de jun. de 2019.

DEXTER, S. Longest Chain – How Are Blockchain Forks Resolved? Jun 2018. Disponívelem: <https://www.mangoresearch.co/blockchain-forks-explained/>. Acesso em 20 dejun. de 2019.

48

DJANGO. Django makes it easier to build better Web apps more quickly and with lesscode. Jun 2019. Disponível em: <https://www.djangoproject.com/>. Acesso em 16 dejun. de 2019.

DOCKER. Get Started with Docker. 2019. Disponível em: <https://www.docker.com/get-started>. Acesso em 18 de jun. de 2019.

GOYAL, S. The History of Blockchain Technology: Must Know Timeline. 2018. Disponívelem: <https://101blockchains.com/history-of-blockchain-timeline/>. Acessoem 10 de jun. de 2019.

HAMIDEH, J. OriginalMy na Mídia: Blockchain e o futuro das eleições. Mar 2019.Disponível em: <https://blog.originalmy.com/blockchain-e-o-futuro-das-eleicoes/>.Acesso em 20 de jun. de 2019.

KESSLER, G. C. An Overview of Cryptography. May 2019. Disponível em:<https://www.garykessler.net/library/crypto.html#types>. Acesso em 10 dejun. de 2019.

LISK. Peer to Peer Network. 2019. Disponível em: <https://lisk.io/academy/blockchain-basics/how-does-blockchain-work/what-is-a-peer-to-peer-network>. Acesso em 20 de jun.de 2019.

MARR, B. 35 Amazing Real World Examples Of How Blockchain Is Changing Our World.2018. Disponível em: <https://www.forbes.com/sites/bernardmarr/2018/01/22/35-amazing-real-world-examples-of-how-blockchain-is-changing-our-world/#2f2d69b943b5>. Acesso em 20 de jun. de 2019.

MONTE, R. Urna eletrônica é vulnerável e pode ser fraudada, diz especialista.2018. Disponível em: <https://portalcorreio.com.br/eleicao-de-2018-esta-sob-risco-diz-especialista-em-seguranca-computacional/>. Acesso em 20 de jun. de 2019.

NAKAMOTO, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. Disponível em:<https://bitcoin.org/bitcoin.pdf>. Acesso em 12 de jun. de 2019.

RONQUILLO, A. Python’s Requests Library (Guide). Jan 2019. Disponível em:<https://realpython.com/python-requests/>. Acesso em 17 de jun. de 2019.

S., J. Blockchain: how a 51% attack works (double spend attack). May 2018. Disponívelem: <https://medium.com/coinmonks/what-is-a-51-attack-or-double-spend-attack-aa108db63474>. Acesso em 20 de jun. de 2019.

SARDAN, T. What is a light client and why you should care? Jul 2018. Disponível em:<https://www.parity.io/what-is-a-light-client/>. Acesso em 20 de jun. de 2019.

SILVA, V. H. Pesquisa mostra desconfiança em urnas eletrônicas usadas no Brasil. 2018.Disponível em: <https://tecnoblog.net/256951/desconfianca-urnas-eletronicas/>. Acessoem 20 de jun. de 2019.

STALLINGS, W. Criptografia e Segurança de Redes: Princípios e Práticas. 6th. ed. [S.l.]:Pearson, 2014.

49

TAPSCOTT, D.; TAPSCOTT, A. Blockchain revolution: como a tecnologia por trás dobitcoin está mudando o dinheiro, os negócios e o mundo. São Paulo: Senai-SP, 2016.

TAR, A. Prova de trabalho (PoW), Explicado. Jan 2018. Disponível em:<https://br.cointelegraph.com/explained/proof-of-work-explained>. Acesso em20 de jun. de 2019.

TUNGKA, D. P. Using Docker Compose to Run Your Applications. 2018. Disponível em:<https://medium.com/rate-engineering/using-docker-containers-to-run-a-distributed-application-locally-eeabd360bca3>. Acesso em 18 de jun. de 2019.

VINCENT, W. Official Django REST Framework Tutorial - A Beginners Guide. Nov2018. Disponível em: <https://wsvincent.com/official-django-rest-framework-tutorial-beginners-guide/>. Acesso em 16 de jun. de 2019.

VU, Q. H.; LUPU, M.; OOI, B. C. Peer-to-peer computing: Principles and applications.[S.l.]: Springer Science & Business Media, 2009.

Documents

Votechain, uma solução mais segura, acessível e inovadora ...€¦ · Agradeço primeiramente à Deus por toda a capacidade que me foi dada, mas mais ... 1 Introdução Oprotocoloentituladode“Bitcoin:APeer-to-PeerElectronicCashSystem”