: Organisation de la médiation au Musée du Quai Branly

Como mostrado no capítulo anterior, o Helios fornece diversas infor- mações relevantes para a auditoria de um processo de votação. Para acessar essas informações, foram criados endpoints para fornece-las, de forma que, apenas as relevantes são buscadas, evitando redundâncias e informações des- necessárias. Foi decidido de não alterar os endpoints originais para não causar uma pertubação no sistema, de forma a causar algum erro. Para os votos, não foi necessário nenhuma mudança no que já havia. Os criados foram:

• GET ‘elections/<election_uuid>/blockchain’ retorna informações do con- trato inteligente.

• GET ‘elections/<election_uuid>/blockchain/election’ retorna informa- ções públicas da eleição.

• GET ‘elections/<election_uuid>/blockchain/voters’ retorna informações públicas dos eleitores.

• GET ‘elections/<election_uuid>/blockchain/result’ retorna informações sobre o resultado.

Nas configurações do projeto, foi adicionado uma variável de ambi- ente contendo o keystore, que é um arquivo em formato JSON, com os dados de uma carteira Ethereum, contendo a chave privada, a cifra usada para guar- dar a chave privada e os demais atributos.

K E Y S T O R E = " / home / Helios / k e y s t o r e . json "

K E Y S T O R E _ P A S S W O R D = " TXv ? m ! U ;9 Q #% KMa "

Figura 9 – Configuração do Keystore

Esse keystore será usado para criar e assinar as transações e popular os contratos com os dados da votação. Vale notar que a carteira já deve contar com fundos necessários para arcar com o funcionamento dos contratos.

46

Além de uma outra variável de ambiente que contem o endereço do contrato inteligente. De forma ao acessar esse endereço, irá ser possível con- sultar o estado atual do contrato.

C O N T R A C T _ A D R E S S = " 0 x 6 9 2 a 7 0 D 2 e 4 2 4 a 5 6 D 2 C 6 C 2 7 a A 9 7 D 1 a 8 6 3 9 5 8 7 7 b3A "

Figura 10 – Endereço do contrato

5.2 CONTRATOS INTELIGENTES

5.2.1 Eleitores

O contrato dos eleitores serve para basicamente saber qual é a lista os eleitores, e o contrato pode variar de acordo com a votação. Por exem- plo, existem eleições onde a privacidade dos dados dos eleitores deve ser respeitada, de forma que seu nome e email não devem divulgados, para isso, bastaria uma pequena mudança no contrato a seguir, alterando o nome para um pseudônimo e a retirada do email.

1 c o n t r a c t Voters { 2 3 struct Voter { 4 string uuid ; 5 string name ; 6 string email ; 7 } 8

9 Voter [] public voters ;

10

11 f u n c t i o n a d d V o t e r (string memory _uuid , string memory

_name , string memory _email ) public {

12 voters .push( Voter ( _uuid , _name , _email ) ) ;

13 }

14 }

Figura 11 – Contrato dos eleitores

Uma vez populado os eleitores no Helios, bastaria populá-los no con- trato também. Como já visto anteriormente, a lista de eleitores não pode ser modificado uma vez que a eleição é congelada, portanto, uma adição de um eleitor não qualificado para a eleição, não estaria nos dados do contrato, cons-

47

tando uma fraude.

5.2.2 Votos

O contrato dos votos contêm uma peculiaridade, dado que será o único contrato que não será populado pelo servidor Helios. Essa decisão foi tomado levando em conta os seguintes aspectos, caso o servidor do Helios fosse inva- dido, um atacante poderia não publicar o voto, ou até mesmo, mudar o hash do voto para causar alguma confusão.

A premissa é que o eleitor é honesto, tanto o esquema proposto pelo Helios, quanto o desse trabalho, não há como garantir que caso algum votante alegue que o seu voto não foi computado, ou aquele voto associado a ele não foi ele que emitiu, não há como garantir ou provar nenhuma informação usando apenas o Helios, nem com o esquema proposto neste trabalho.

1 c o n t r a c t Votes { 2 3 struct Vote { 4 string v o t e _ h a s h ; 5 string v o t e r s _ h a s h ; 6 u i n t 2 5 6 c a s t _ a t ; 7 } 8

9 Vote [] public votes ;

10

11 f u n c t i o n a d d V o t e (string memory _vote_hash , string memory

_voters_hash , u i n t 2 5 6 _cast ) public {

12 votes .push( Vote ( _vote_hash , _voters_hash , _cast ) ) ;

13 }

14

15 }

Figura 12 – Contrato dos votos

Vale notar aqui que o voto cifrado não é publicado, apenas o seu hash. Essa decisão foi tomada pelo fato que a criptografia utilizada nos dias de hoje, como ElGamal pode não ser segura no futuro, como já temos exemplos de primitivas criptográficas no passado. (Shamir et al., 1982)

Partindo da premissa que o eleitor é honesto, então, isso seria uma prova que o seu voto existiu em dado momento, e que, se ele não estiver na hora da apuração do resultado, algo de errado houve com os votos, invali- dando a votação.

48

5.2.3 Eleição

O contrato eleição é o principal, ele vai ser instanciado uma vez por votação e o mesmo contêm os outros contratos instanciados como variáveis do contrato. Além do mais irá conter as informações gerais sobre a votação, como o seu uuid, que é seu identificador único, o nome da votação, a URL que será usada para votar, a data de criação, horário que irá abrir e fechar para os votos, além de conter todas as perguntas e respostas e a chave pública da votação, que é utilizada na hora da contagem e auditoria do votos.

49

1 c o n t r a c t E l e c t i o n { 2

3 string public uuid ;

4 string public name ;

5 string public c a s t _ u r l ; 6 u i n t 2 5 6 public c r e a t e d _ a t ; 7 u i n t 2 5 6 public f r o z e n _ a t ; 8 u i n t 2 5 6 public v o t i n g _ s t a r t s ; 9 u i n t 2 5 6 public v o t i n g _ e n d s ; 10 11 struct P u b l i c _ K e y { 12 string p ; 13 string q ; 14 string g ; 15 string y ; 16 } 17 18 P u b l i c _ K e y public p u b l i c _ k e y ; 19 20 struct Q u e s t i o n { 21 string q u e s t i o n ; 22 string[] a n w s e r s ; 23 } 24 25 Q u e s t i o n [] public q u e s t i o n s ; 26 27 Voters public v o t e r s _ c o n t r a c t ; 28 Votes public v o t e s _ c o n t r a c t ; 29 Result public r e s u l t _ c o n t r a c t ; 30

31 c o n s t r u c t o r(string memory _uuid , string memory _name ,

string memory _cast_url , u i n t 2 5 6 _created_at ,

u i n t 2 5 6 _ v o t i n g _ s t a r t s , u i n t 2 5 6 _voting_ends ,

u i n t 2 5 6 _voting_ends , string memory _p , string

memory _q , string memory _g , string memory _y )

public { 32 uuid = _uuid ; 33 name = _name ; 34 c a s t _ u r l = _ c a s t _ u r l ; 35 c r e a t e d _ a t = _ c r e a t e d _ a t ; 36 v o t i n g _ s t a r t s = _ v o t i n g _ s t a r t s ; 37 v o t i n g _ e n d s = _ v o t i n g _ e n d s ; 38 p u b l i c _ k e y = P u b l i c _ K e y ( _p , _q , _g , _y ) ; 39 v o t e r s _ c o n t r a c t = new Voters () ; 40 v o t e s _ c o n t r a c t = new Votes () ; 41 r e s u l t _ c o n t r a c t = new Result () ; 42 } 43

44 f u n c t i o n a d d Q u e s t i o n (string memory _question , string[]

memory _ a n s w e r s ) public {

45 q u e s t i o n s .push( Q u e s t i o n ( _question , _ a n w s e r s ) ) ;

46 }

47

48 }

50

Assim que configurado toda a votação, esse contrato seria populado com todos os dados da eleição a partir dos endpoints criados.

5.2.4 Resultado

O contrato do resultado foi criado para divulgar o resultado individual de cada pergunta, além do horário que foi divulgado e o hash dos eleitores. De maneira que é possível verificar se as questões foram alteradas e também conferir que o horário final da eleição estava de acordo com o previsto.

A informação mais importante é o hash dos eleitores, pois como o contrato dos eleitores foi populado previamente, é possível calcular o hash novamente, desta forma, é possível saber que apenas os votantes válidos par- ticiparam da eleição. 1 c o n t r a c t Result { 2 3 struct Q u e s t i o n { 4 string q u e s t i o n ; 5 int result ; 6 } 7 8 Q u e s t i o n [] public q u e s t i o n s ; 9 string public v o t e r s _ h a s h ; 10 u i n t 2 5 6 public r e l e s e d _ a t ; 11

12 f u n c t i o n a d d Q u e s t i o n (string memory _question , int

_ r e s u l t ) public { 13 q u e s t i o n s .push( Q u e s t i o n ( _question , _ r e s u l t ) ) ; 14 } 15 16 f u n c t i o n s e t V o t e r s H a s h (string memory _ v o t e r s _ h a s h ) public { 17 v o t e r s _ h a s h = _ v o t e r s _ h a s h ; 18 } 19 20 f u n c t i o n s e t R e l e a s e A t (u i n t 2 5 6 _ r e l e s e d _ a t ) public { 21 r e l e s e d _ a t = _ r e l e s e d _ a t ; 22 } 23 }

54

Dados obtidos em 25/09/2019.

Contrato Método Gas Dólar

Resultado constructor 571316 $2.41 Resultado ddQuestion 84624 $0.35 Resultado setVotersHash 87482 $0.36 Resultado setReleasedAt 42164 $0.17 Votos constructor 389806 $1.64 Votos addVote 128449 $0.54 Eleitores constructor 508588 $2.14 Eleitores addVoter 151882 $0.64 Eleição constructor 2684091 $11.34 Eleição addQuestion 129270 $0.54

Tabela 1 – Custos dos métodos dos contratos

Agora, será estimado uma votação hipotética, composta por mil elei- tores, três questão e levando em consideração que 10% dos eleitores tenham votado duas vezes, visto que é permitido votar mais de uma vez e é conside- rado apenas o último. As chamadas para os contratos seriam a seguinte:

1. 1x construtor do contrato eleição. 2. 3x addQuestion do contrato eleição. 3. 1000x addVoter do contrato eleitores. 4. 1100x addVote do contrato votos. 5. 3x addQuestion do contrato resultado. 6. 1x setVotersHash do contrato resultado. 7. 1x setReleasedAt do contrato resultado.

Considerando os valores calculados nas tabelas anteriores temos um total de US$ 1248.54 para rodar todo processo, até mesmo a divulgação do resultado.

Fica claro que o maior custo está associado a adicionar os dados dos eleitores e no momento de publicar a estrutra do voto. Dado que o custo para publicar os outros dados, ficam marginais de acordo com a quantidade. Como é mostrado no gráfico a seguir.

55 1000 5000 10000 50000 0 20,000 40,000 60,000 Dólares Eleitores

57

6 CONCLUSÃO

Neste trabalho, foi desenvolvido um esquema e uma implementação de um módulo para garantir maior auditabilidade e transparência para o sis- tema de eleição online Helios, com a utilização da blockchain para garantir a imutabilidade dos dados inseridos.

Uma conclusão muito importante feito a partir da análise de custos do modelo proposto. Foi que há um custo relativamente elevado para rodar o modelo. Desta forma, dependendo do caso de uso da eleição, não há a necessidade de se ter tanta segurança no processo, de forma que o custo se torne incompatível com as necessidades. Entretanto, para votações onde já há um custo elevado para a realização da mesma, há a possibilidade de se alterar para utilização do Helios junto com módulo desenvolvido para se ter maior segurança para o processo de votação, sendo um caso de uso legítimo.

A pergunta da pesquisa pode ser respondida a partir dos dados obtidos do modelo construído, conjuntamente com as hipóteses propostas, de forma que foi criado um módulo utilizando blockchain para garantir auditabilidade. Foi feito estudo do custo para o volume de dados. Além de ter discutido se esse modelo é economicamente viável.