Universidade de Aveiro Edson Gabriel Pinto dos Santos. Sistema de Cripto-Pagamentos para Transportes

(1)

Universidade de Aveiro 2021

Edson Gabriel Pinto dos Santos

Sistema de Cripto-Pagamentos para Transportes

P´ ublicos

(2)

(3)

Universidade de Aveiro 2021

Edson Gabriel Pinto dos Santos

Sistema de Cripto-Pagamentos para Transportes P´ ublicos

Disserta¸cão apresentada à Universidade de Aveiro para cumprimento dos re- quisitos necessários à obten¸cão do grau de Mestre em Engenharia Eletrónica e Telecomunica¸cões, realizada sob a orienta¸cão cient´ıfica de Paulo Bartolo- meu, Investigador Auxiliar do Instituto de Telecomunica¸cões da Universidade de Aveiro.

Este trabalho é financiado pela FCT/MCTES através de fundos nacionais e quando aplicável cofinanciado por fundos comunitários no âmbito do projeto UIDB/50008/2020-UIDP/50008/2020.

(4)

(5)

o j´uri / the jury

presidente / president Professor Doutor Telmo Reis Cunha Professor Associado, Universidade de Aveiro

vogais / examiners committee Doutor Paulo Jorge de Campos Bartolomeu

Investigador Doutorado, Instituto de Telecomunica¸c˜oes da Universidade de Aveiro (orientador)

Professor Doutor M´ario Jo˜ao Barata Calha Professor Auxiliar, Universidade de Lisboa

(6)

(7)

agradecimentos / acknowledgements

Agrade¸co ao meu orientador por todo o apoio prestado na realiza¸c˜ao deste trabalho. E dedico um agradecimento muito especial aos meus pais e irm˜ao, por tudo o que fizeram por mim.

(8)

(9)

palavras-chave transportes p´ublicos, micropagamentos, criptomoedas, Hedera Hashgraph, sistemas BLE

resumo A tendência de crescimento da popula¸cão em áreas metropolitanas e o aumento da temperatura do planeta, exigem medidas que permitam melhorar a mobilidade urbana através do investimento no crescimento do uso de transportes públicos. Motivado por um ecossistema de aplica¸cões cada vez mais rico e heterogéneo temos assistido à massifica¸cão do uso de smartphones em vários contextos do nosso dia-a-dia. Esta disserta¸cão procura inovar os métodos de pagamento praticados em transportes públicos, propondo um sistema em que o pagamento é realizado de modo transparente usando os smartphones pessoais dos passageiros. Para projetar o sistema, foram explorados diversos sistemas CIBO (Check-in/Be-out) e BIBO (Be-in/Be- out), que procuram a integra¸cão de smartphones, substituindo os sistemas RFID por sistemas em que os check-ins e check-outs são efetuados com recurso à tecnologia BLE (Bluetooth Low Energy). No caso das transa¸cões monetárias propriamente ditas, foi estudada a viabilidade do uso de criptomoedas para efetuar micropagamentos, com base nas suas taxas por transa¸cão, velocidade da transa¸cão e capacidade computacional exigida.

O sistema proposto integra uma aplica¸cão executada num smartphone que recebe informa¸cão proveniente de sinalizadores BLE (beacons) integrados em ve´ıculos públicos e a usa para efetuar o respetivocheck-in/outno servidor do operador de transportes. Este é um processo que permite realizar o pagamento automático da viagem através de transa¸cões HBAR da criptomoeda Hedera Hashgraph. De forma a testar o desempenho do sistema de pagamento proposto, foram desenvolvidos protótipos para a aplica¸cão móvel dos passageiros e para o servidor do operador de transportes públicos. Os resultados da avalia¸cão experimental mostram que o pagamento de transportes públicos recorrendo à criptomoeda HBAR não só é tecnicamente viável como permitirá um maior conforto para os passageiros. Adicional- mente, para o operador de transportes, permite um maior “fluxo de caixa”

face ao recebimento quase em tempo-real do servi¸co prestado.

(10)

(11)

keywords public transportation, micropayments, cryptocurrencies, Hedera Hashgraph, BLE systems

abstract The population growth in metropolitan areas and the rising temperature of the planet, ask for measures as investing in public transportation to improve urban mobility. We also witness the massification of smartphones motiva- ted by a new landscape of uses cases, making them convenient to be part of our daily routines. The main goal of this master thesis is to innovate the payment methods currently used in public transportation, by proposing a system in which the payments are made in a transparent way using the passengers’ personal smartphones. Before the system proposal, this thesis explores CIBO (Check-in/Be-out) and BIBO (Be-in/Be-out) systems which intend to replace RFID technology by using smartphones and BLE (Blueto- oth Low Energy) technology in the detection of check-ins and check-outs.

As for the payments themselves, it was studied the viability of existing cryptocurrencies based on their fees, speed and computational power required by their transactions. The passenger’s smartphone in the proposed system receives information sent by BLE beacons installed in public vehicles and, through a mobile app, performs the check-in and check-out on the public transport operator server, automatically. This process allows the payment to be made automatically as well, using HBAR transactions of the chosen public distributed ledger - Hedera Hashgraph. To test the performance of the system’s transactions, prototypes were developed for the passengers’ app and the operator’s server. Results show that the micropayments performed by the chosen cryptocurrency are not only viable for public transportation but will allow a more comfortable environment for the passengers. Additio- nally, it will improve the cash flow of the operator, receiving the payments’

amount almost in real-time as the passengers check-in.

(12)

(13)

Conte´ udo

Conte´udo i

Lista de Figuras iii

Lista de Tabelas v

1 Introdu¸c˜ao 1

1.1 Contexto . . . 1

1.2 Objetivos . . . 2

1.3 Organiza¸c˜ao . . . 3

2 Sistemas BLE aplicados a transportes p´ublicos 5 2.1 BIBOLinz . . . 5

2.2 CIBOLisboa . . . 7

2.3 SEAT . . . 8

2.4 Anda . . . 12

2.5 Compara¸c˜ao de sistemas BLE . . . 13

3 Criptomoedas aplicadas a micropagamentos 15 3.1 IOTA . . . 15

3.1.1 IOTApass . . . 17

3.1.2 An´alise comparativa do sistema IOTApass . . . 18

3.2 Nano . . . 19

3.3 Hedera Hashgraph . . . 21

3.4 Compara¸c˜ao de criptomoedas . . . 23

4 Micropagamentos em transportes p´ublicos atrav´es de Hedera Hashgraph 25 4.1 HederaPass . . . 26

4.1.1 Arquitetura . . . 26

4.1.2 Funcionamento Global . . . 27

4.1.3 Mecanismo de Seguran¸ca . . . 28

4.2 An´alise comparativa do sistema HederaPass . . . 32

4.3 Aplica¸c˜oes m´oveis . . . 34

4.3.1 Registo . . . 34

4.3.2 Viagem . . . 34

4.4 Testnet . . . 39

(14)

5 Implementa¸c˜ao 43

5.1 Servidor do operador . . . 43

5.1.1 Registo do utilizador . . . 45

5.1.2 Autentica¸c˜ao do utilizador . . . 46

5.1.3 Autentica¸c˜ao dosbeacons . . . 47

5.1.4 Check-in . . . 48

5.1.5 Paragem interm´edia . . . 48

5.1.6 Check-out . . . 48

5.2 Aplica¸c˜ao m´ovel para passageiros . . . 50

5.2.1 Comunica¸c˜ao com o servidor . . . 51

5.2.2 Registo eLogin . . . 52

5.2.3 Menu . . . 54

5.2.4 Processamento dos an´uncios de paragem . . . 54

5.2.5 Paragem interm´edia . . . 55

5.2.6 Check-in . . . 55

5.2.7 Check-out . . . 56

5.2.8 Hist´orico de viagens . . . 56

5.2.9 Estado . . . 58

5.2.10 Detalhes . . . 58

5.2.11 Saldo . . . 59

6 Resultados 60 6.1 Testes à aplica¸cão móvel para passageiros . . . 60

6.2 Testes ao servidor do operador . . . 66

7 Conclus˜oes 73 7.1 S´ıntese . . . 73

7.2 Trabalho futuro . . . 74

Bibliografia 75

(15)

Lista de Figuras

2.1 Arquitetura do sistema BIBOLinz . . . 6

2.2 Dete¸c˜ao dos passageiros no sistema BIBOLinz . . . 7

2.3 M´etodo de pagamento do sistema BIBOLinz . . . 8

2.4 Arquitetura do sistema CIBOLisboa . . . 9

2.5 Arquitetura do sistema SEAT . . . 10

2.6 Comunica¸c˜oes do sistema SEAT . . . 10

2.7 Arquitetura do sistema Anda . . . 11

3.1 Estruturatangle . . . 16

3.2 Arquitetura do sistema IOTApass . . . 17

3.3 Blockchains Nano . . . 19

3.4 Estruturablock-lattice . . . 20

3.5 Estruturahashgraph . . . 22

4.1 Arquitetura do sistema HederaPass . . . 27

4.2 Encripta¸c˜ao de dados no sistema HederaPass . . . 28

4.3 Desencripta¸c˜ao de dados no sistema HederaPass . . . 29

4.4 Check-in no sistema HederaPass . . . 30

4.5 Processo de paragem interm´edia no sistema HederaPass . . . 31

4.6 Check-out no sistema HederaPass . . . 32

4.7 Registo na aplica¸c˜ao de passageiros . . . 35

4.8 Cria¸c˜ao de uma conta Hedera Hashgraph na aplica¸c˜ao de passageiros . . . 35

4.9 C´odigo recebido por SMS na aplica¸c˜ao de passageiros . . . 36

4.10 Login na aplica¸c˜ao de passageiros . . . 36

4.11 Menu da aplica¸c˜ao de passageiros . . . 37

4.12 Saldo insuficiente na aplica¸c˜ao de passageiros . . . 38

4.13 Menu da aplica¸c˜ao de revisores . . . 38

4.14 Aplica¸cões em caso de falha na liga¸cão à Internet . . . 39

4.15 Aplica¸c˜oes em caso de falha na liga¸c˜ao BLE . . . 40

4.16 Taxas numa transferˆencia de HBARs . . . 41

4.17 Exemplo de uma transferˆencia de 1 HBAR . . . 41

5.1 M´odulos que constituem o prot´otipo do servidor do operador . . . 43

5.2 Modelo de dados do servidor . . . 44

5.3 Resposta a umrequest HTTP decheck-in . . . 48

5.4 Registo de uma viagem completa na base de dados . . . 49

5.5 Registo das transa¸c˜oes de uma viagem completa na base de dados . . . 49

(16)

5.6 POSTs recebidos pelo servidor . . . 50

5.7 Bibliotecas que constituem o prot´otipo da aplica¸c˜ao HederaPass . . . 51

5.8 Ecr˜a de login implementado . . . 53

5.9 Ecr˜a de registo implementado . . . 53

5.10 Ecr˜a do menu implementado . . . 54

5.11 Ecr˜a implementado para o envio de an´uncios . . . 55

5.12 Ecr˜a de Hist´orico implementado . . . 57

5.13 Ecr˜as de Estado durante uma viagem com 1 paragem interm´edia . . . 57

5.14 Ecr˜a de Detalhes implementado . . . 58

5.15 Ecr˜a de Saldo implementado . . . 59

6.1 Setup de testes à aplica¸cão móvel do passageiro . . . 61

6.2 Linha de comandos “Logcat” . . . 61

6.3 Intervalos temporais testados no processo decheck-in de um passageiro . . . 62

6.4 Diagrama das amostras dos tempos decheck-in na aplica¸c˜ao . . . 63

6.5 Intervalo temporal testado no processo de identifica¸c˜ao de paragem . . . 63

6.6 Diagrama das amostras do tempo de identifica¸c˜ao de paragens na aplica¸c˜ao . 64 6.7 Intervalo temporal testado no processo decheck-out de um passageiro . . . . 64

6.8 Diagrama das amostras do tempo decheck-out na aplica¸c˜ao . . . 65

6.9 Setup de testes ao servidor . . . 67

6.10 Gr´aficos da resposta do servidor ao processo de check-in . . . 68

6.11 Gr´aficos da resposta do servidor ao processo de identifica¸c˜ao de paragem . . . 69

6.12 Gr´aficos da resposta do servidor ao processo de check-out (100/5) . . . 71

6.13 Gr´aficos da resposta do servidor ao processo de check-out (100/1) . . . 72

(17)

Lista de Tabelas

2.1 Compara¸c˜ao dos sistemas BLE . . . 13

2.2 Compara¸c˜ao dos sistemas BLE do ponto de vista do utilizador . . . 13

3.1 Caracter´ısticas do sistema IOTApass . . . 18

3.2 Compara¸c˜ao de criptomoedas . . . 23

4.1 Caracter´ısticas do sistema HederaPass . . . 33

6.1 Tempos de resposta no processo de check-in . . . 62

6.2 Tempos de resposta na identifica¸c˜ao de paragens . . . 63

6.3 Tempos de resposta no processo de check-out . . . 65

6.4 Requests e tempos de resposta do servidor no processo de check-in . . . 67

6.5 Requests e tempos de resposta do servidor na identifica¸c˜ao de paragens . . . . 68

6.6 Requests e tempos de resposta do servidor no processo de check-out . . . 70

(18)

(19)

Cap´ıtulo 1

Introdu¸ c˜ ao

1.1 Contexto

A tendência de crescimento das zonas urbanas [4], aponta a que no futuro o trânsito nas grandes cidades experiencie um aumento no seu congestionamento, provocado pelo aumento do transporte rodoviário particular de passageiros. Atualmente, estes ve´ıculos representam cerca de 32%¹ [2] das emissões de gases de efeito de estufa, responsáveis pelo aumento da temperatura do planeta. De forma a limitar o congestionamento nas grandes cidades e o aumento da temperatura a 2ºC², o futuro reside no investimento em transportes públicos que, para incentivar a adesão de novos passageiros, deverão continuar a evoluir no sentido de melhorar a sua pegada ecológica, aumentar o seu conforto e otimizar o método de pagamento para evitar filas de espera e diminuir o tempo de paragem dos ve´ıculos.

Paralelamente ao potencial crescimento dos transportes públicos, o acesso a smartphones aumentou mundialmente cerca de 74% nos últimos 6 anos [5] e não dá sinais de parar, fazendo destes fortes candidatos a serem utilizados no pagamento de transportes públicos. Assim, um passageiro deixa de ter a preocupa¸cão de perder bilhetes ou cartões, tendo à sua disposi¸cão o seu próprio smartphone que à partida estaria consigo, tanto no caso de ir viajar, como em qualquer outra situa¸cão.

Nos dias de hoje, a maioria dos transportes públicos onde ossmartphones dos passageiros fazem parte dos seus sistemas, recorrem a tecnologias como códigos QR ou NFC. Sistemas com estas tecnologias têm em comum o facto de necessitarem que os passageiros validem a informa¸cão que reside nos seus smartphones através de um contacto próximo com um equipamento da empresa de transporte público, que usa esta tecnologia para ler a informa¸cão, tipicamente dentro dos ve´ıculos, onde os passageiros necessitam de efetuar o seucheck-ine, no caso da viagem não ser pré-paga, também o seucheck-out. Este fator introduz uma fragilidade nos sistemas, tendo em conta que, caso haja um número elevado de passageiros a querer efetuar um check-in/out e um passageiro estiver com dificuldades em efetuar o seu, este pode dar origem a uma longa fila de espera. Uma solu¸cão para evitar este tipo de constrangimentos, é a transi¸cão para sistemas BLE (Bluetooth Low Energy), onde ossmartphones dos passageiros poderão interagir com equipamentos da empresa de transportes público à distância. Nesta disserta¸cão, os sistemas com esta tecnologia serão identificados como BIBO (Be-In/Be-Out) no caso de não exigirem qualquer intera¸cão do passageiro com o seusmartphone em situa¸cões

1Estat´ısticas de 2017, assumindo as proje¸c˜oes pr´e pandemia [3]

2Valor estabelecido pelo Acordo de Paris assinado em 2016 pelos membros do UNFCCC [1]

(20)

decheck-in echeck-out, e CIBO (Check-in/Be-Out), se estes necessitarem que os passageiros interajam com a aplica¸c˜ao instalada no seus smartphones para efetuarem os seus check-ins.

Estes sistemas CIBO, apesar de carecerem da intera¸cão dos passageiros com as suas aplica¸cões, os passageiros podem fazê-lo já nos devidos lugares do ve´ıculo, evitando assim um ambiente prop´ıcio à forma¸cão de filas.

Em rela¸cão aos poss´ıveis métodos de pagamento, hoje em dia, a maioria dos pagamentos online recorre awallets digitais como o PayPal, porém o crescimento de criptomoedas descen- tralizadas, como a Bitcoin e Ethereum, que nos últimos 5 anos obtiveram um crescimento de 8.600% e 27.000%³, acarreta um grande foco para o mundo das criptomoedas que, à medida que provar ser de confian¸ca, fará com que certas criptomoedas se possam vir a juntar à lista de métodos de pagamento mais comuns [6].

Criptomoedas como Bitcoin e Ethereum, que recorrem à tecnologia blockchain, exigem uma elevada capacidade de processamento para manter a integridade das suas estruturas e assegurar a seguran¸ca dos sistemas. A cada bloco de transa¸cões das blockchains, está associado um problema matemático complexo que exige um elevado esfor¸co computacional para ser resolvido, resultando num elevado consumo energético. Os envolvidos na resolu¸cão destes problemas são os mineiros (miners), que são recompensados com um determinado valor monetário que é cobrado sob a forma de uma taxa a quem fez transa¸cões da criptomoeda, desfavorecendo o uso destas criptomoedas para micropagamentos, tendo em conta o valor das taxas e o longo compasso de espera até que as transa¸cões sejam validadas. Criptomoedas como IOTA, NANO e HBAR, por sua vez, foram desenvolvidas com vista a ultrapassar os limites impostos pela minera¸cão. Ao eliminarem a necessidade de mineiros, foi resolvida a problemática das elevadas taxas por transa¸cão, a rapidez das transa¸cões aumentou e a capacidade de processamento necessário para as processar diminuiu, tornando estas criptomoedas ideais para efetuar micropagamentos e, consequentemente, fortes candidatas a fazer parte do método de pagamento de transportes públicos, como sugerem os objetivos esta disserta¸cão.

1.2 Objetivos

O principal foco desta disserta¸cão, é o desenvolvimento de um sistema de pagamento automático, para transportes públicos, que efetue transa¸cões através de uma criptomoeda.

Após o estudo e análise de criptomoedas existentes no mercado, a criptomoeda escolhida para as transa¸cões deve ser a que satisfa¸ca melhor as condi¸cões impostas pelo sistema: taxas por transa¸cão negligenciáveis, transa¸cões validadas num curto espa¸co de tempo, baixas exigências a n´ıvel de processamento e, de preferência, um SDK (Software Development Kit) favorável à programa¸cão das intera¸cões do sistema com a plataforma da criptomoeda.

O sistema, através da tecnologia BLE, deve permitir que os smartphones dos passageiros comuniquem combeacons BLE instalados nos ve´ıculos, o que introduz amea¸cas à seguran¸ca do sistema comospoofing ouhijacking, sendo que no primeiro caso a entidade maliciosa faz-se passar por um beacon do sistema através de umbeacon seu, enquanto que no segundo a entidade maliciosa obtém o controlo de umbeacon pertencente ao sistema e pode fazer altera¸cões

`

a informa¸cão transmitida. Para evitar este tipo de situa¸cões, o sistema deve garantir a autenticidade e integridade da informa¸cão que chega aos passageiros, através do desenvolvimento de um sistema de encripta¸cão.

3Equivalente a subidas de valor de$500 para$43.000 e$11 para$3.000.

(21)

O sistema, também deve incluir uma aplica¸cão móvel para passageiros que permita o envio automático da informa¸cão proveniente dosbeacons para o servidor da empresa de transporte público, permitindo efetuar check-ins e check-outs sem requerer a intera¸cão dos passageiros com a aplica¸cão ou qualquer outro dispositivo, fazendo deste sistema, um sistema BIBO. O mesmo processo automatizado, aplica-se ao pagamento das viagens que deve ser realizado através de transa¸cões de uma criptomoeda viável para este efeito. A aplica¸cão, além de permitir a comunica¸cão direta com o servidor da empresa de transporte público, também deve oferecer uma interfaceuser-friendlyque permita aos seus utilizadores obterem funcionalidades como: facilitar o carregamento do saldo da conta, auxiliar na orienta¸cão (ex.: mostrar o nome da última paragem efetuada e da paragem seguinte) e apresentar um histórico de viagens.

De forma a assegurar que os passageiros procedem de acordo com as regras preestabeleci- das para o bom funcionamento do sistema, este deve ainda incluir uma aplica¸cão móvel para revisores que os auxilia a verificar se os passageiros viajam legalmente e, no caso de haver falhas de Internet ou BLE nosmartphone de um passageiro, estes poderem estabelecer algum tipo de comunica¸cão com a aplica¸cão do passageiro para que este possa, mesmo assim, viajar legalmente.

Por fim, para testar o sistema desenvolvido, deverão ser desenvolvidos protótipos para os elementos da arquitetura responsáveis pelas transa¸cões, de forma a implementar um ambiente favorável a testes que estudem a viabilidade do uso da criptomoeda neste contexto.

1.3 Organiza¸ c˜ ao

Contando com a Introdu¸cão, a disserta¸cão é constitu´ıda por sete cap´ıtulos. O Cap´ıtulo 2 analisa e compara quatro sistemas BLE projetados para transportes públicos. O Cap´ıtulo 3 analisa e compara três criptomoedas com caracter´ısticas favoráveis a micropagamentos, além de analisar um novo sistema BLE que também é comparado com os sistemas analisados no Cap´ıtulo 2. O Cap´ıtulo 4 foca-se em micropagamentos em transportes públicos através da criptomoeda Hedera Hashgraph, e divide-se em quatro seçcões: a Seçcão 4.1 descreve uma proposta de arquitetura de um sistema BLE que usa a Hedera Hashgraph nos seus pagamentos (HederaPass), além de descrever o seu funcionamento e mecanismo de seguran¸ca; a Seçcão 4.2 compara o sistema HederaPass aos sistemas BLE analisados anteriormente; a Seçcão 4.3 faz uma descri¸cão mais detalhada das aplica¸cões móveis que fazem parte do HederaPass; e a Seçcão 4.4 explica o processo de cria¸cão de contas Hedera Hashgraph e transa¸cões entre elas numa plataforma de testes (Testnet). O Cap´ıtulo 5 descreve a implementa¸cão dos protótipos do servidor e aplica¸cão para passageiros que fazem parte do HederaPass. O Cap´ıtulo 6 descreve os testes feitos à aplica¸cão do passageiro e ao servidor implementados, apresenta os resultados e analisa-os. Por fim, o Cap´ıtulo 7 termina a disserta¸cão com uma análise geral da disserta¸cão e propostas de trabalho futuro.

(22)

(23)

Cap´ıtulo 2

Sistemas BLE aplicados a transportes p´ ublicos

Tendo o objetivo de melhorar a experiência de utiliza¸cão de transportes públicos, é ne- cessário abordar o tempo gasto em filas de espera para efetuar a compra e valida¸cão de bilhetes. Uma forma de melhorar este aspeto, é construir um sistema baseado na tecnologia BLE, que permita a dete¸cão das entradas e sa´ıdas dos passageiros à distância.

Neste cap´ıtulo serão analisados sistemas BIBO (Be-in/Be-out) como [7] e [10], e sistemas que necessitam da confirma¸cão manual de check-in, também conhecidos por CIBO (Check- in/Be-out), como o [9] e [11, 12] onde, apesar de ocheck-in não ser automático, este poderá ser efetuado com o smartphone do utilizador depois de este ocupar o seu devido lugar no transporte público, evitando também a forma¸cão de filas de espera.

2.1 BIBOLinz

Este projeto [7, 8] desenvolvido na Universidade Johannes Kepler no âmbito da inici- ativa austr´ıaca IV2Splus, tem o objetivo de melhorar a mobilidade de pessoas fisicamente incapacitadas, crian¸cas e idosos, em autocarros, através de um sistema BIBO que usa a tecnologia BLE. Não tendo sido encontrado um nome para este sistema na bibliografia, este será referenciado como BIBOLinz para facilitar a sua referência.

Dentro de cada autocarro, a arquitetura do sistema é composta por umbeaconpertencente ao passageiro (1) ou umsmartphone (2), um módulo “OBS” (On-Board-System), constitu´ıdo por uma unidade de processamento (Raspberry Pi) (3) com um dongle BLE acoplado (4), o computador de bordo do próprio autocarro (5) e uma base de dados local (6) que guarda a informa¸cão proveniente da unidade de processamento: ID dos clientes associados às suas localiza¸cões nos momentos de scanning do sistema e timestamps correspondentes. Fora dos autocarros, a arquitetura é constitu´ıda por um servidor remoto (backend) que, ao associar a informa¸cão pessoal dos passageiros (7) à informa¸cão da viagem (8), é responsável por taxá-los (9). O OBS comunica com o computador de bordo e funciona como uma unidade central que estabelece a liga¸cão entre o smartphone e obackend, como se verifica na Figura 2.1.

Neste sistema BIBO, o check-in e check-out dos passageiros é automático, e o papel de- sempenhado pelos smartphones é o de fazer broadcasts ao OBS para anunciar a presen¸ca dos respetivos passageiros no autocarro. Tendo em conta a simplicidade da fun¸cão dossmartphones, não são especificados quaisquer detalhes em rela¸cão a aplica¸cões móveis.

(24)

Figura 2.1: Arquitetura do sistema BIBOLinz.

Durante a viagem, para confirmar a presen¸ca dos passageiros, o OBS faz scansperiódicos despoletados por eventos do computador de bordo, de forma a realizá-los em momentos em que o ve´ıculo não se encontra perto de paragens, para não identificar dispositivos BLE que não perten¸cam a passageiros. Partindo deste princ´ıpio, o OBS pode efetuar um scan 30 segundos após o computador de bordo sinalizar que as portas do autocarro foram fechadas.

Um dispositivo BLE identificado por um determinado n´umero de scans, ´e identificado como um passageiro do autocarro.

Como se pode verificar na Figura 2.2, os beacons/smartphones, para estabelecerem um handshake com o OBS, come¸cam por fazer um broadcast BLE (1), que é recebido pelo OBS (2). Após estas primeiras intera¸cões, o OBS envia uma key AES de 128 bits encriptada (3) que, do lado do cliente, é desencriptada, concatenada ao ID do cliente (“client ID”) e encriptada novamente (4), que acaba por ser lida e desencriptada pelo OBS (5). Caso akey inicial consiga ser restaurada através da sua desencripta¸cão, o OBS valida o ID do cliente, guarda-o e envia-lhe a indica¸cão de que pode parar de fazerbroadcasts BLE (6) até voltarem a comunicar no próximo scan.

Com base em informa¸cão guardada antes do in´ıcio da viagem - nomes das paragens associados às suas localiza¸cões GPS ou associados à sequência de scans periódicos realizados pelo OBS - o ID dos clientes fica associado ao nome das paragens por onde passam, com os respetivostimestamps, na base de dados do OBS. Esta informa¸cão é transmitida, via Internet, ao servidor remoto (backend) onde é calculado o custo da viagem.

Quanto ao método de pagamento, este tem o banco do cliente como mediador entre o cliente e a empresa de transporte público, em que o banco fornece uma key ao utilizador, que o mesmo associa ao pagamento das viagens, como demonstra a Figura 2.3. Assim, a empresa de transporte público não tem acesso a informa¸cão delicada do utilizador e o banco não tem a informa¸cão de onde e quando o seu cliente viajou, limitando-se a retirar mensalmente da

(25)

Figura 2.2: Dete¸c˜ao dos passageiros no sistema BIBOLinz.

conta do seu cliente a quantia acumulada das viagens efetuadas pelo mesmo.

2.2 CIBOLisboa

Este sistema [9] desenvolvido no Instituto Superior Técnico de Lisboa, adaptado à CAR- RIS¹, propõe uma arquitetura que usa funcionalidades dossmartphones dos passageiros como GPS e sensores de movimento, para substituir a instala¸cão de uma unidade central de processamento no ve´ıculo (ex.: Raspberry Pi) ou liga¸cão ao computador de bordo do mesmo. O sistema será referenciado como CIBOLisboa, para facilitar a sua referência.

Este sistema é composto por quatrobeacons por autocarro comum da CARRIS (seis por articulado), umbackend e osmartphone do passageiro. Osbeacons enviam, periodicamente, informa¸cão estática aosmartphonepara confirmar a presen¸ca do passageiro no autocarro, e o smartphone reencaminha essa informa¸cão para obackend da empresa de transporte público, que é o responsável pela análise e processamento de dados. Além destes três elementos distintos da arquitetura, há ainda um revisor, que a qualquer momento pode confirmar se o

1Empresa de transporte p´ublico de Lisboa.

(26)

Figura 2.3: M´etodo de pagamento do sistema BIBOLinz.

passageiro est´a a viajar legalmente. A arquitetura do sistema encontra-se representada na Figura 2.4.

Quanto ao seu funcionamento, o utilizador come¸ca por fazer odownload da aplica¸cão no seu smartphone e registar-se. Após efetuar o login na aplica¸cão, deve confirmar o seu saldo e, caso esteja abaixo da quantia m´ınima estipulada para dar in´ıcio à viagem, terá de efetuar um carregamento. Já dentro do autocarro, com saldo suficiente, o smartphone identifica os beacons mais próximos e a aplica¸cão deve selecionar automaticamente o autocarro no qual se encontra o utilizador, opera¸cão que, em caso de falha, o utilizador deve confirmar manualmente o devido autocarro. Para dar in´ıcio à viagem, sucede-se o check-in manual na aplica¸cão, clicando no botão “Check-in”, e é esta a¸cão que vai enviar a localiza¸cão GPS do smartphone aobackend, identificando a esta¸cão/paragem de partida. Nesta fase, o passageiro apenas terá de interagir novamente com a aplica¸cão, caso o revisor pe¸ca que este prove que está a viajar legalmente, ao que o passageiro deve proceder a um clique num botão espec´ıfico da sua aplica¸cão para esta situa¸cão, que vai gerar um código QR e o revisor confirma-o com a câmara do seu próprio smartphone. No final da viagem, o smartphone do utilizador, ao sair do autocarro, deixa de identificar o número m´ınimo de beacons definido pelo sistema e a aplica¸cão dá por terminada a viagem automaticamente (Be-Out), voltando a enviar a localiza¸cão GPS ao backend, que a associa a uma esta¸cão. O backend, após o check-out, calcula o custo da viagem, baseado nas esta¸cões percorridas pelo passageiro e cobra-lhe esse montante. O histórico de viagens e o custo das mesmas podem ser consultados a qualquer momento no smartphone do utilizador.

2.3 SEAT

O sistema SEAT [10] desenvolvido na TU Delft, consiste numa nova perspetiva de um sistema BIBO. Este projeto aborda um sistema que difere dos anteriores, por usar diferentes tipos de dispositivos dentro dos ve´ıculos para efetuar check-ins,check-outs e comunicar com o backend.

A sua arquitetura, apresenta um dispositivo para registar ocheck-in (“vehicle check-in”),

(27)

Figura 2.4: Arquitetura do sistema CIBOLisboa.

outro para registar o check-out (“vehicle check-out”), um dispositivo central (“vehicle central”), umbackend (“back-end”) e osmartphonedo passageiro (“passenger”). Os dispositivos de check-in e check-out, têm a fun¸cão de receber a informa¸cão do smartphone do passageiro em rela¸cão à sua permanência no autocarro e comunicá-la ao dispositivo central que, além de comunicar com estes, também comunica diretamente com o backend.

Além destes elementos distintos da arquitetura, este sistema também recorre a um revisor, que a qualquer momento pode confirmar se um passageiro está a viajar legalmente, comu- nicando com o dispositivo central ou diretamente com o smartphone do passageiro. Esta arquitetura encontra-se representada na Figura 2.5.

O dispositivo de check-in, que comunica com o smartphone do passageiro por BLE, identifica-o na sua entrada para o autocarro. Esta identifica¸cão de check-in é registada pelo dispositivo central, que comunica a informa¸cão ao dispositivo decheck-out que, por sua vez, envia mensagens encriptadas ao smartphone do passageiro, também por BLE, para este as desencriptar e confirmar que se mantém presente no autocarro. A partir do momento em que o smartphone deixa de responder a esta troca de informa¸cão, é identificado ocheck-out.

Com base na informa¸cão agregada por estes dois dispositivos, o dispositivo central regista localmente a informa¸cão dos s´ıtios em que o passageiro efetuou ocheck-in e ocheck-out e reencaminha essa informa¸cão aobackend através de uma comunica¸cão 3G ou, em modooffline, pode comunicá-la apenas no final do dia de servi¸co².

Para o correto funcionamento do sistema, o utilizador necessita de fazer o download da aplica¸cão no seu smartphone e registar-se, enviando o registo para o backend que guarda o perfil do utilizador para efeitos de autentica¸cão. Sendo este um sistema BIBO, após efetuar o login na aplica¸cão, o utilizador não requer qualquer intera¸cão adicional com o seusmartphone

2O tipo de comunica¸cão não é especificada na bibliografia

(28)

Figura 2.5: Arquitetura do sistema SEAT.

Figura 2.6: Processo decheck-ine verifica¸c˜ao de permanˆencia do passageiro no sistema SEAT.

durante a viagem, necessitando apenas de o fazer caso o revisor o requisite. Nesse caso, o passageiro fornece ao revisor um código dispon´ıvel na sua aplica¸cão, que o revisor valida no seu próprio dispositivo³.

Quanto à sua seguran¸ca, o sistema recorre a um esquema complexo de distribui¸cão de keys composto por certificados, encripta¸cão assimétrica, códigos para autentica¸cão de mensagens (MAC)⁴, assinaturas digitais e encripta¸cão simétrica, em que as chaves são trocadas recorrendo ao método Diffie-Hellman. Obackend funciona como uma CA (Autoridade de Cer- tifica¸cão)⁵, onde tem um par de chaves assimétricas ECC (Criptografia de Curva El´ıtica)⁶, em que aprivate key é usada para assinar os certificados etokens atribu´ıdos aos dispositivos registados no sistema, e a public key é distribu´ıda pelos mesmos dispositivos, para estes poderem verificar a validade dessas assinaturas. Enquanto isso, o dispositivo central e o revisor também geram os seus pares de chaves ECC, de validade limitada e seguran¸ca inferior, e enviam as public keys desses pares aobackend, para que este lhes atribua um certificado tem- porário, permitindo-lhes estabelecer uma comunica¸cão segura com os passageiros através de

3A bibliografia n˜ao especifica o tipo de dispositivo.

4Message Authentication Code

5Certification Authority

6Elliptic-Curve Cryptography

(29)

Figura 2.7: Arquitetura do sistema Anda.

tokens e assinaturas digitais. As comunica¸cões do dispositivo do revisor com os passageiros e dispositivo central, recorrem a “session keys” - chaves simétricas de encripta¸cão AES de 128 bits - sistema de encripta¸cão também usado na comunica¸cão do smartphone do passageiro com o dispositivo de check-in, que usa uma chave temporária, que será referida como “CT”.

A comunica¸cão do smartphone do passageiro com o dispositivo de check-in, segue a ordem de eventos representada na Figura 2.6 (1-4). Inicialmente, o dispositivo de check-in envia um certificado com a sua public key ao passageiro (1), que usa essa chave para encriptar a chave CT, enviada junto da DH-1⁷e um MAC criado com a própria chave CT (2). Segue-se a resposta do dispositivo com a DH-2 e um MAC para esta chave criado também pela chave CT (3). Assim, fica estabelecida uma liga¸cão segura entre os dois elementos e é criada uma chave

“KeyJ”, que é usada para osmartphone encriptar o seutoken e enviá-lo para o dispositivo de check-in (4). Mais tarde, na comunica¸cão do smartphone do passageiro com o dispositivo de check-out (5-6), o dispositivo decheck-out vai enviar mensagens encriptadas pela chave KeyJ ao smartphone (5), que o smartphone desencripta e responde com mensagens de “Ok” (6), confirmando a sua presen¸ca.

Por fim, o responsável por calcular e cobrar o custo da viagem do passageiro, com base na sua distância percorrida, é o backend. Tendo em conta que, independentemente do modo (online ou offline) a comunica¸cão do dispositivo central com o backend só é feita no final da viagem do passageiro, pode-se depreender que este sistema é pós-pago.

(30)

2.4 Anda

O sistema Anda [11, 12] desenvolvido na FEUP, propõe melhorar o sistema Andante que atualmente comunica por RFID em esta¸cões da área metropolitana do Porto, através da sua transi¸cão para a tecnologia BLE. Para isso, propõe duas arquiteturas diferentes, uma para autocarros e outra para transportes ferroviários.

Para autocarros, o sistema prop˜oe o uso de um ou maisbeacons ligados por cabo ao computador de bordo dos ve´ıculos, um servidor remoto (backend) e o smartphone do utilizador.

Os beacons recebem informa¸cão acerca das paragens proveniente do computador de bordo e transmitem-na aosmartphone do passageiro, que a comunica ao backend. Este backend é da responsabilidade da empresa de transporte público e é lá que a informa¸cão é analisada e processada.

No caso dos transportes ferroviários, a arquitetura também é constitu´ıda por um servidor remoto, osmartphone do utilizador e beacons, porém não necessita do computador de bordo dos ve´ıculos e os beacons são instalados nos atuais postos de valida¸cão do sistema RFID Andante, situados em paragens/esta¸cões. Estes beacons apresentam um funcionamento mais simples que os beacons para o sistema de autocarros, por apenas necessitarem de enviar informa¸cão para o smartphone acerca da paragem/esta¸cão onde estão instalados. Enquanto que a informa¸cão enviada pelosbeacons no sistema para autocarros é dinâmica, a informa¸cão enviada pelos beacons no sistema para transportes ferroviários é estática, o que simplifica a complexidade destes segundos, porém aumenta a complexidade da aplica¸cão móvel dos passageiros. Estas duas arquiteturas podem ser consultadas na Figura 2.7.

Do ponto de vista do utilizador, o funcionamento do sistema para autocarros é idêntico ao sistema para transportes ferroviários. O utilizador come¸ca por fazer odownload da aplica¸cão para o seusmartphonee registar-se. Após efetuar ologin na aplica¸cão, osmartphoneidentifica osbeacons detetados nas proximidades e o utilizador necessita de fazer um check-in manual, selecionando a paragem/esta¸cão onde vai dar in´ıcio à sua viagem (beacon pertencente ao sistema, que está mais próximo).

Iniciando a sua viagem, a aplica¸cão recebe informa¸cão proveniente do autocarro ou paragens/esta¸cões, onde o utilizador pode verificar as paragens por onde já passou e as paragens por onde ainda vai passar até chegar ao seu destino. Durante a viagem, o revisor pode pe- dir ao utilizador que prove estar a viajar legalmente e este apenas necessita de mostrar um código alfanumérico dispon´ıvel na sua aplica¸cão gerado para esta situa¸cão, que o revisor valida introduzindo-o no seu próprio smartphone. Chegando ao destino, o check-out é automático.

Osmartphone ao ficar fora do alcance dosbeaconsque fazem parte da rota do ve´ıculo, deteta a quebra da sequência debeacons esperada e a viagem é dada por terminada, fazendo com que este seja um sistema CIBO (Check-In/Be-Out). Com a viagem conclu´ıda, obackend analisa o trajeto efetuado e calcula o seu custo, seguindo o método atual do Andante, com tarifas por zonas. Este sistema acumula o custo das viagens e, no final do mês, retira o montante total da conta do utilizador, sujeito a otimiza¸cões de tarifa que beneficiam os passageiros. O histórico de viagens e o custo das mesmas também podem ser consultados, a qualquer momento, no smartphone do utilizador.

(31)

BIBOLinz[7] CIBOLisboa[9] SEAT[10] Anda[11, 12]

Complex. Arq elevada moderada elevada elevada/moderada

Adaptabilidade baixa moderada baixa baixa/elevada

Seguran¸ca AM,unlink. - AM,unlink.,PFS -

Tabela 2.1: Compara¸c˜ao dos sistemas BLE.

BIBOLinz[7, 8] CIBOLisboa[9] SEAT[10] Anda[11, 12]

Usabilidade f´acil complexa moderada complexa

M´etodo Paga. banco mediador - - -

Pontualidade Paga. mensal fim da viagem fim da viagem mensal

Custo Inicial Paga. 0 valor de entrada - 0

Cálculo Tarifa n.ºparagens n.ºparagens distância zonas Tabela 2.2: Compara¸cão dos sistemas BLE do ponto de vista do utilizador.

2.5 Compara¸ c˜ ao de sistemas BLE

Para comparar os sistemas analisados anteriormente, foram avaliadas as seguintes caracter´ısticas na Tabela 2.1: complexidade das arquiteturas, adaptabilidade aos ve´ıculos e seguran¸ca dos sistemas. Nos casos em que não foi encontrada informa¸cão suficiente na presente bibliografia, a caracter´ıstica está representada por um h´ıfen. De salientar ainda que no sistema Anda, foram avaliadas, separadamente, a arquitetura projetada para autocarros (à esquerda) e a arquitetura projetada para transportes ferroviários (à direita).

A complexidade das arquiteturas foi avaliada com base no número de componentes que as integram e a complexidade de cada um dos elementos, fatores que também definem a adaptabilidade das mesmas. Come¸cando pelo sistema BIBOLinz, este necessita de uma unidade de processamento por autocarro, com liga¸cão ao computador de bordo do ve´ıculo, tal como na arquitetura projetada para autocarros do sistema Anda, o que eleva a complexidade dos sistemas e dificulta a sua adapta¸cão aos sistemas atuais. Já o sistema SEAT, apesar de não usar o computador de bordo do ve´ıculo, é complexo dado o número de dispositivos diferentes que envolve e a complexidade dos mesmos, fatores que resultam numa baixa adaptabilidade, tendo em conta o elevado número de novos dispositivos a adicionar aos ve´ıculos e o seu custo total. Quanto à complexidade da arquitetura do sistema CIBOLisboa, esta é moderada tal como a do sistema Anda para transportes ferroviários, por não necessitarem de uma unidade central de processamento nos ve´ıculos ou liga¸cão ao computador de bordo e usarembeacons que transmitem informa¸cão estática, o que faz com que a complexidade seja “transferida”

para as aplica¸cões móveis dos utilizadores. Quanto à adaptabilidade destes sistemas, esta distingue-se pela necessidade que o CIBOLisboa tem de instalar pelo menos doisbeacons por autocarro, enquanto que no sistema Anda para transportes ferroviários, os beacons são co- locados nos postos de valida¸cão RFID já existentes, fazendo com que este seja o sistema de melhor adaptabilidade.

7DH-1 - Primeira parte da chave Diffie-Hellman; DH-2 - Segunda parte

(32)

Por fim, no cap´ıtulo da seguran¸ca, o sistema BIBOLinz, através de umhandshake AES- 128 do smartphone dos passageiros com a OBS do ve´ıculo, oferece autentica¸cão mútua e unlinkability, enquanto que, no caso do sistema SEAT, além destes também há PFS (Perfect Forward Secrecy) no seu complexo sistema de distribui¸cão dekeyse protocolos de comunica¸cão entre os elementos da arquitetura.

Na Tabela 2.2 foram analisadas as seguintes caracter´ısticas de cada sistema do ponto de vista do utilizador: usabilidade do sistema, método de pagamento, pontualidade do pagamento, custo inicial da viagem (dinheiro que o utilizador precisa de ter dispon´ıvel para dar in´ıcio à viagem) e cálculo da tarifa.

Come¸cando pela usabilidade, no sistema BIBOLinz o smartphone tem apenas a fun¸cão de beacon para registar a presen¸ca do passageiro, fazendo com que este seja o sistema com a usabilidade mais simples. No outro sistema BIBO, o SEAT, a usabilidade é moderada, tendo em conta que o utilizador necessita de se registar e efetuar ologin na aplica¸cão, para o check-in e check-out serem registados automaticamente, só necessitando de interagir com a sua aplica¸cão novamente caso o revisor o requisite. Enquanto isso no caso dos sistemas CIBOLisboa e Anda, estes apresentam uma usabilidade mais complexa, dado que os sistemas requerem que o utilizador se registe, fa¸calogin na aplica¸cão e, antes de cada viagem, efetuem ocheck-in manualmente na aplica¸cão, podendo ainda de ter de fornecer um código ao revisor, caso este o requisite durante a viagem.

Em rela¸cão ao método de pagamento dos sistemas, o sistema BIBOLinz apresenta uma solu¸cão que tem o banco do cliente como mediador entre o cliente e a empresa de transporte público, em que o banco fornece umakey ao utilizador, que o mesmo associa ao pagamento das viagens. Os restantes sistemas não apresentam detalhes em rela¸cão ao método de pagamento, sendo que o sistema CIBOLisboa apenas faz referências à possibilidade da utiliza¸cão de pagamentos por smartphone através do Apple Pay, Google Wallet e PayPal, tal como o sistema Anda, que referencia o Apple Pay e o Android Pay. Quanto à pontualidade do pagamento dos sistemas e custo inicial das viagens, este é mensal, sem necessidade de saldo positivo no in´ıcio das viagens, nos casos dos sistemas BIBOLinz e Anda, enquanto que, no caso do sistema CIBOLisboa, é necessário um valor inicial de entrada para que o utilizador possa dar in´ıcio a uma viagem, e o pagamento é efetuado no check-out. O sistema SEAT apenas refere que obackend é o responsável por cobrar o montante da viagem do passageiro, no final da viagem. Por fim, o cálculo da tarifa dos sistemas BIBOLinz e CIBOLisboa é baseado no número de paragens por onde passa o passageiro, no sistema SEAT é baseado na distância percorrida e, no sistema Anda, o cálculo é efetuado com base nas zonas por onde circula o passageiro, como no atual sistema Andante.

(33)

Cap´ıtulo 3

Criptomoedas aplicadas a micropagamentos

Os métodos de pagamento atualmente praticados pelas empresas de transporte público, geralmente requerem que os passageiros fa¸cam uma compra prévia das suas viagens, como é o caso da compra de bilhetes f´ısicos e cartões RFID, que além de sujeitarem os passageiros à sua perda ou esquecimento, também podem fazê-los esperar em filas para os adquirirem. A problemática das filas de espera recorrentes pode ser mitigada através da aquisi¸cão de passes pré-pagos, ou passes com pagamentos feitos pelos passageiros no fim de cada mês. Porém, poderá levar os passageiros a pagar por viagens que não vão fazer ou, no caso de pagamentos mensais, poderá prejudicar a empresa de transporte público por ter de esperar pelo fim do mês para receber o montante.

Uma forma de resolver estes problemas, é substituir estes métodos de pagamento por um método de pagamento que permita aos passageiros pagarem as suas viagens, durante as próprias viagens, sem a necessidade de adquirirem objetos f´ısicos. O que pode ser implementado recorrendo a criptomoedas que possam ser transferidas rapidamente e com taxas muito reduzidas, através dos smartphones pessoais dos passageiros.

3.1 IOTA

A criptomoeda IOTA [16], foi criada a pensar na IoT (Internet of Things) para resolver problemas de descentraliza¸cão, escalabilidade e custo de transa¸cões, através da tangle.

A tangle é uma DLT (Distributed Ledger Technology) baseada no conceito matemático DAG (Directed Acyclic Graph), que elimina a necessidade de mineiros (miners) e melhora a sua eficiência quanto maior for o número de transa¸cões registadas no seu histórico.

Em tecnologiasblockchain, como a Bitcoin, cada bloco da sequência exige a resolu¸cão de um problema matemático complexo, para que possa fazer parte da sequência de blocos que definem o histórico de transa¸cões do sistema. Este problema, denominado de PoW (Prova de Trabalho)¹, é resolvido por um mineiro que, ao ter chegado primeiro à resposta, é recompen- sado pelo esfor¸co computacional que o problema lhe exigiu, com um certo valor monetário proveniente de taxas que os utilizadores que submeteram transa¸cões nesse bloco tiveram de pagar. Assim, este sistema apresenta custos elevados a quem pretende fazer transa¸cões e

1Proof-of-Work

(34)

Figura 3.1: Estrutura datangle.[14]

falhas na sua descentraliza¸cão, tendo em conta que, na “ca¸ca à recompensa”, apenas os mineiros com maiores recursos computacionais poderão adicionar blocos àblockchain. No caso datangle, não existem recompensas nem mineiros, resultando também na inexistência de taxas a quem pretende efetuar transa¸cões. Apesar desta plataforma também requerer provas de trabalho, estas são mais simples porque em vez de terem o objetivo de construir a rede, são apenas uma ferramenta para evitar o spam de transa¸cões ilegais efetuado por entidades maliciosas.

Os dispositivos responsáveis por assegurar a integridade datangle, são os nós (nodes). Es- tes recebem as transa¸cões dos utilizadores e anexam-nas àtangle. Para efetuar uma transa¸cão, um nó procede da seguinte forma: escolhe duas outras transa¸cões para validar (de acordo com um determinado algoritmo), vê se as valida¸cões não entram em conflito com a estrutura e, por fim, para que a própria transa¸cão seja validada, realiza a PoW anteriormente referida, gerandohashes até encontrar umnonce que valida a transa¸cão. Além destas funcionalidades, os nós também sincronizam a estrutura, registam o saldo dos utilizadores e fornecem APIs aos mesmos. Esta estrutura é retratada pela Figura 3.1, em que o tempo aumenta da esquerda para a direita, cada quadrado representa uma transa¸cão e, cada seta, representa a valida¸cão de uma transa¸cão (uma transa¸cão com uma seta apontada na sua dire¸cão, é uma transa¸cão validada pela transa¸cão da origem da seta) e, sempre que uma nova transa¸cão é registada, esta deve validar pelo menos duas outras transa¸cões anteriormente registadas na estrutura.

As transa¸c˜` oes que aguardam aprova¸c˜ao, ´e-lhes atribu´ıdo o termo “tip”.

Um dos crit´erios mais relevantes para definir o n´ıvel de confian¸ca de uma transa¸c˜ao,

é o peso acumulado (cumulative weight), em que o peso de uma transa¸cão é proporcional

`

a “quantidade de trabalho” da PoW investida pelos nós que a anexaram à rede. Este é resultante da soma do peso da própria transa¸cão com o peso de todas as transa¸cões que a aprovam, direta ou indiretamente. Quanto maior for o peso acumulado, maior será o n´ıvel de confian¸ca que uma transa¸cão possui e quanto menor for o n´ıvel de confian¸ca, menor deverá ser a probabilidade dessa transa¸cão ser validada. A primeira e mais importante transa¸cão efetuada na tangle IOTA é conhecida por transa¸cão “genesis”, que é aprovada, direta ou indiretamente, por todas as transa¸cões existentes. Esta origem de toda a tangle, é a origem de todos os tokens existentes (2.779.530.283 MIOTA).

(35)

Figura 3.2: Arquitetura do sistema IOTApass.

3.1.1 IOTApass

Uma das aplica¸cões da plataforma IOTA são os pagamentos em transportes públicos, como se verifica no caso do IOTApass [15]. Este sistema alia um método de pagamento que recorre à transa¸cão de criptomoedas IOTA, ao facto de ser um sistema BIBO com comunica¸cão através de BLE.

A sua arquitetura, representada na Figura 3.2, é constitu´ıda por beacons dinâmicos com uma base de dados local, um servidor remoto (backend), osmartphonedo utilizador e atangle IOTA. O sistema está ainda adaptado a revisores que, a qualquer momento, podem confirmar se o passageiro está a viajar legalmente.

Em rela¸cão à comunica¸cão entre os elementos da arquitetura, os beacons transmitem informa¸cão sob a forma de hashes, que a base de dados local recebe do backend. Estas hashes apontam para atangle, onde está guardada a informa¸cão necessária para desencadear as transa¸cões monetárias entre o passageiro e a empresa de transporte público e, tendo em conta que diferentes pontos da viagem devem corresponder a diferentes custos, estashashes dependem da localiza¸cão GPS do ve´ıculo. Além das hashes, os beacons também enviam para osmartphone do passageiro os seus IDs e coordenadas GPS do ve´ıculo, que a aplica¸cão reencaminha para obackend (aquando do seucheck-in echeck-out), junto do ID do utilizador (“user ID”), obtido através do seu registo na aplica¸cão.

Antes de dar in´ıcio a uma viagem, o passageiro introduz o seu nome de utilizador (user- name), palavra-passe e, opcionalmente, o seu VAT². Ao submeter estes dados, a aplica¸cão cria um par de chaves, em que aprivate key é usada para assinar as mensagens enviadas em nome do utilizador e envia, junto das informa¸cões introduzidas no registo, apublic key para o backend, que por sua vez responde com a atribui¸cão de um user ID ao utilizador e lhe fornece apublic key do próprio servidor.

Com o login efetuado, ao entrar no ve´ıculo, o check-in ´e feito automaticamente com a

2Corresponde ao NIF (N´umero de Identifica¸c˜ao Fiscal).

(36)

aplica¸cão a enviar uma mensagem de check-in para o backend, composta pela informa¸cão proveniente dos beacons(ID e coordenadas GPS), junto da identifica¸cão do próprio utilizador (user ID). Após o envio da mensagem, a aplica¸cão acede à hash, valida a assinatura com a public key da empresa de transporte público e, através dessahash obtém o endere¸co IOTA da empresa de transporte público e o valor a transferir que corresponde à tarifa da viagem mais longa da rota do ve´ıculo, em IOTAs, a partir o seu check-in. A própria transa¸cão, além de transferir o montante referido, também identifica o passageiro e é assinada pela sua private key, ao que obackend responde, com uma mensagem que confirma o pagamento. De salientar que, enquanto a transferência do montante é efetuada mesmo que o servidor estejaoffline, a mensagem de confirma¸cão apenas se realizará com o servidoronline.

Durante a viagem, os passageiros apenas terão de interagir com os seussmartphones, caso um revisor o solicite. Nesta situa¸cão, a aplica¸cão do utilizador gera um código QR que dá acesso à sessão de check-in em curso, que o revisor lê e valida no seu próprio smartphone, através de uma aplica¸cão desenvolvida especificamente para este efeito.

No fim da viagem, a aplica¸cão recebe os mesmos parâmetros provenientes dos beacons e envia uma mensagem de check-out ao servidor remoto, semelhante à descrita anteriormente no check-in. Neste caso, a aplica¸cão cria uma transa¸cão na tangle, que identifica o utilizador e solicita o reembolso, com a informa¸cão das coordenadas GPS onde o ve´ıculo estava no momento em que o utilizador o abandonou. Caso o utilizador não tenha sa´ıdo na última paragem, este receberá de volta parte do montante transferido nocheck-in, em IOTAs, de forma a pagar apenas o custo referente à sua viagem. O cálculo deste montante é flex´ıvel, podendo ser adaptado a sistemas que atualmente funcionam por zonas, por número de paragens ou distância total percorrida.

3.1.2 An´alise comparativa do sistema IOTApass IOTApass

Complex. Arq elevada

Adaptabilidade moderada

Seguran¸ca -

Usabilidade moderada

M´etodo Paga. IOTA

Pontualidade Paga. in´ıcio da viagem c/reembolso no fim Custo Inicial Paga. valor total

C´alculo Tarifa flex´ıvel

Tabela 3.1: Caracter´ısticas do sistema IOTApass.

Comparando este sistema aos sistemas BLE analisados anteriormente com base nas caracter´ısticas descritas nas Tabelas 2.1 e 2.2, da Seçcão 2.5, foi constru´ıda a Tabela 3.1. O sistema IOTApass apresenta uma arquitetura de complexidade elevada atendendo à complexidade dosbeacons, que além de serem dinâmicos, transmitem informa¸cão que depende de um módulo GPS, sendo este mais um elemento a considerar na sua implementa¸cão. Enquanto isso, a adaptabilidade afetada pelo custo dos elementos a arquitetura, é mitigada pelo facto

(37)

Figura 3.3: Blockchains Nano.

do sistema ser versátil em rela¸cão ao transporte público ao qual é aplicado, fazendo desta moderada. Em rela¸cão ao sistema do ponto de vista dos passageiros, a usabilidade da aplica¸cão móvel é moderada devido ao facto desta não requerer a intera¸cão dos passageiros durante a viagem a não ser que os revisores do ve´ıculo o requisitem, mas necessitar do registo prévio, login ativo e liga¸cões BLE e Internet dispon´ıveis. Quanto ao método de pagamento, este consiste no envio e rece¸cão de transa¸cões IOTA, sendo que o passageiros paga a viagem no seucheck-in através de uma transa¸cão correspondente ao custo máximo da rota do ve´ıculo a partir dessa paragem e, aquando docheck-out, recebe um reembolso através de uma transa¸cão IOTA por parte da empresa de transporte público para a sua conta, caso não tenha sa´ıdo na última paragem. Apesar das transa¸cões serem feitas na primeira e última paragens dos passageiros, o cálculo da tarifa é flex´ıvel, podendo-se basear no número de paragens, distância ou zonas percorridas pelos passageiros durante a viagem.

3.2 Nano

A criptomoeda Nano [18], distingue-se pela sua escalabilidade ilimitada, transa¸cões rápidas e sem custos, através de uma arquitetura block-lattice.

Block-lattice é uma estrutura de dados que permite aos utilizadores terem contas individuais onde controlam a sua própria blockchain, assincronamente, em rela¸cão ao conjunto global de contas (ledger), fazendo com que as transa¸cões sejam quase instantâneas.

E chamada de conta, a´ public key que advém do par de chaves de uma assinatura digital, sendo esta um endere¸co público para os restantes participantes da rede. Um utilizador pode controlar diversas contas, mas cada conta apenas possui um endere¸co público. Uma conta é

(38)

Figura 3.4: Estrutura block-lattice.

criada através da forma¸cão do primeiro bloco da sequência (bloco 0), representado na Figura 3.3, aquando da primeira rece¸cão de fundos (transa¸cão open). Às contas, estão associados blocos que representam a codifica¸cão digital de transa¸cões individuais, assinadas pelaprivate key do par de chaves anteriormente referido. De um ponto de vista mais prático, cada bloco representa o saldo da conta nesse instante e a blockchain acaba por ser uma representa¸cão do histórico do saldo da conta. A primeira conta a ter sido criada no sistema, é chamada de conta “genesis” e contém o saldo “genesis”, que é o saldo máximo do sistema (133.248.297 NANO) e nunca poderá ser ultrapassado pela soma total dos saldos de todas as contas.

Para transferir fundos entre contas, as blockchains individuais comunicam entre si no ledger, como demonstra a Figura 3.4. Cada transferência envolve dois blocos/transa¸cões: um de envio (transa¸cãosend), criado na conta do remetente e que lhe deduz a quantia do saldo, e um de rece¸cão (transa¸cãoreceive), criado na conta do destinatário e que adiciona a quantia ao seu saldo. Assim que o bloco de envio do remetente é assinado, este é imutável e os fundos são deduzidos do saldo da conta, mesmo antes do destinatário assinar a rece¸cão. Este sistema de dois blocos permite manter as transa¸cões pequenas para caberem em pacotes UDP, minimizar o rastreio de dados, isolar as transa¸cões validadas das não validadas (não incorporadas no saldo cumulativo do destinatário) e ordenar a chegada de transferências não sincronizadas.

Várias contas remetentes podem estar a enviar fundos para a mesma conta destinatária em simultâneo e esta decide que transferência chegou primeiro, e representa essa decisão através da ordem das assinaturas dos blocos que recebe, na suablockchain.

De um ponto de vista high-level, a arquitetura do sistema, além de ser composta pelos utilizadores e estrutura de contas anteriormente definida, é constitu´ıda por nós (nodes). Os nós são o software dos dispositivos responsáveis por assegurar a integridade da rede Nano

(39)

e que permitem aos utilizadores interagirem com a mesma. Todas as transa¸cões têm um campo “work” que deve ser preenchido corretamente através da concatena¸cão de umnonce, computado pelo criador da transa¸cão, com um determinado campo dessa mesma transa¸cão, o que define a PoW realizada pelo nó, que no caso da Nano é apenas realizada como uma ferramentaanti-spam³.

Além das transa¸cões do tipoopen,send e receive, anteriormente referidas, existem ainda transa¸cõeschange, que permitem ao dono de uma conta mudar o nó representante (represen- tative). Este representante, é o responsável por votar em nome da conta, caso haja conflitos entre blocos. Quando são detetados dois blocos que na própria blockchain apontam para o mesmo bloco anterior, o representante da conta cria um voto dedicado a esse bloco e transmite-o para a rede. O representante observa os outros representantes online e os votos são contados durante 1 minuto, tendo em conta que o peso do voto de um nó representante é a soma dos saldos de todas as contas que o nomearam como representante. No fim da vota¸cão, o bloco que obteve mais votos permanece associado ao seu bloco predecessor e o bloco menos votado é descartado. O próprio utilizador pode ser representante, porém para muitos utilizadores não é praticável adquirir um nó que requer recursos de rede elevados para observar o tráfego de votos de outros representantes e publicar os seus próprios votos. A Nano oferece diferentes configura¸cões de nós, caracterizados pelos recursos que consomem. Destacando algumas configura¸cões, existem: nós transaction generating - os que requerem mais CPU, para realizarem a PoW que permite criar novas transa¸cões; nós representantive - requerem um CPU básico para verificar assinaturas de blocos, mas o máximo de recursos de rede para observar os restantes representantes e votar; nós observer - não votam e apenas requerem um CPU semelhante aos representantes para gerar a assinatura; nós historical - requerem a maior quantidade de memória para guardar o registo completo de todas as transa¸cões da Nano; nóscurrent - só guardam localmente o último bloco de cada conta; e, por fim, nóslight - não guardam qualquer registo local e só observam a atividade de contas do seu interesse ou, opcionalmente, criam transa¸cões com asprivate keys que possuem.

3.3 Hedera Hashgraph

A plataforma Hedera [19] ´e administrada por um grupo descentralizado de mais de 20 entidades⁴ e pretende colmatar falhas nas DLT atuais, atrav´es de uma arquiteturahashgraph.

Esta arquitetura, é uma estrutura de dados onde todas as transa¸cões são registadas por ordem cronológica e são comunicadas através de um protocologossip. O princ´ıpio dogossiping pode ser simplificado da seguinte forma: caso um membro submeta uma mensagem, esta vai ser transmitida para um membro aleatório da estrutura e, esse membro, vai enviar essa mesma mensagem para um outro membro aleatório e assim sucessivamente, até chegar a todos os membros.

No caso da Hedera Hashgraph, é usado o chamado “gossip about a gossip”, representado na Figura 3.5, onde o tempo evolui de baixo para cima, cada fila representa um membro/nó (node) da rede -software dos dispositivos responsáveis pelo controlo e intera¸cão dos utilizadores com a rede - e cada c´ırculo representa uma mensagem/evento, composta pela assinatura

3Assim como no sistema IOTA.

4Avery Dennison, Boeing, Chainlink Labs, Dentons, Deutsche Telekom, DLA Piper, EDF, eftpos, FIS, Google, IBM, IIT Madras, LG, LSE, Magalu, Nomura Holdings, Shinhan Bank, Standard Bank, Swirlds, Tata Group, UCL, Wipro, Zain Group.

(40)

Figura 3.5: Estruturahashgraph.

de quem a criou, hora a que foi criada, transa¸cões que contém (tal como num bloco de uma blockchain),hashda última mensagem criada pelo membro antes desta ehashda última mensagem recebida pelo membro. Assim, a Alice, ao enviar uma mensagem (c´ırculo vermelho), está a transmitir a um membro aleatório da estrutura (Carol), não só informa¸cão da própria mensagem, mas a sua liga¸cão às mensagens representadas por c´ırculos azuis, pelo que, indiretamente, cada nó consegue interligar toda a informa¸cão de eventos hashgraph, obtendo uma cópia de toda a rede e não só ficam a conhecer a cria¸cão de todos os eventos, mas também sabem quando estes foram criados.

No momento em que pelo menos 2/3 dos membros ficarem informados da cria¸cão de um evento, é assinalado o fim de uma ronda degossiping. Nesse momento, cada nó calcula o novo estado da hashgraph processando todos os eventos efetuados nessa ronda e nas anteriores, assina a hash desse novo estado (hashgraph completa), cria um evento com essa informa¸cão, faz gossip para o resto da rede e come¸ca uma nova ronda. Um utilizador no exterior da hashgraph, pode avaliar a validade deste estado, requisitando uma prova (proof), que inclui um livros de endere¸cos -public keys de todos os nós e respetivos saldos - e ainda um histórico de livros de endere¸cos, onde cada livro de endere¸cos corresponde a um estado e é assinado por nós suficientes de forma a que o saldo somado seja superior a 2/3 das criptomoedas totais da rede. Este histórico mostra os eventos até ao “genesis”, momento em que aHedera Hashgraph foi criada, tal como o total de criptomoedas que existirá na rede (50.000.000.000 HBAR). Para que haja consenso na organiza¸cão da hashgraph e cada nó guarde uma cópia idêntica da mesma, é realizada uma vota¸cão entre nós, sem a necessidade de os nós trocarem mensagens entre si, sobrecarregando a rede. Como cada nó tem uma cópia da hashgraph através do gossip about a gossip, um nó, como o da Alice, tem as mesmas informa¸cões que, por exemplo, o Bob e assim sabe qual seria o voto do Bob caso este participasse fisicamente na vota¸cão. Assim a vota¸cão é virtual e tem a capacidade de ordenar cronologicamente os eventos, calculando a mediana dos timestamps registados pelos relógios dos computadores que hospedaram os nós, de quando esses nós receberam cada evento.

De salientar ainda, que cada n´o tem acesso ao saldo dos restantes e, que o peso de cada

(41)

voto, é definido pela quantidade de criptomoedas (HBAR) que cada nó detém, fazendo, com que haja PoS (Proof-of-Stake). O algoritmo hashgraph diz-se “Byzantine Fault Tolerant”

ass´ıncrono (aBFT), tendo em conta que, desde que as entidades maliciosas que estejam a atacar a rede detenham menos de 1/3 da quantia total de HBARs, mais cedo ou mais tarde o consenso acabar´a por ser atingido.

Para os utilizadores (clients) da Hedera efetuarem transa¸cões, nomeadamente trans- ferências de criptomoedas, estes não precisam de adquirir nós, basta criarem um par de chaves para a sua assinatura digital. No entanto, estão sujeitos a pagar taxas que revertem a favor dos nós que participam na rede, como forma de incentivo pela sua participa¸cão. Há vários tipos de taxas, tais como: taxa por nó (node fee) - o utilizador paga o envio da transa¸cão que pretende efetuar ao nó que a vai enviar para a rede; taxa de rede (network fee) - quantia que será transferida para os nós que vão participar no gossiping; e taxa de servi¸co (service fee) - taxa proporcional ao tamanho e tempo que o conteúdo de uma transa¸cão necessita de ficar na rede. Cada transa¸cão da criptomoeda tem um custo de$0,0001.

3.4 Compara¸ c˜ ao de criptomoedas

IOTA[16] Nano[18] Hedera Hashgraph[19]

Estrutura Tangle Block-lattice Hashgraph

Valida¸c˜ao de Transa¸c˜oes PoW PoW aBFT

Grau de Confian¸ca peso acumulado PoS PoS

Taxa por Transa¸c˜ao $0 $0 $0,0001

Criptomoeda MIOTA NANO HBAR

n.ºCriptomoedas 2.779.530.283 133.248.297 50.000.000.000 n.º Cripto. Circula¸c˜ao 2.779.530.283 133.248.297 6.760.903.627

Valor Total (USD) $1.045.625.530 $366.597.960 $263.700.800 Tabela 3.2: Compara¸c˜ao de criptomoedas.

A Tabela 3.2, compara as criptomoedas analisadas em rela¸cão às suas estruturas, processos de valida¸cão de transa¸cões, a forma como são atribu´ıdos graus de confian¸ca às transa¸cões, a taxa a pagar pelo utilizador em cada transa¸cão, o nome da criptomoeda, o número total de criptomoedas existentes, o número de criptomoedas em circula¸cão e, por fim, o valor monetário total das criptomoedas em circula¸cão.

A escalabilidade necessária é conseguida pelas três criptomoedas, através de estruturas diferentes, que vêm substituir ablockchain usada em criptomoedas como a Bitcoin. A IOTA usa atangle, onde cada nova transa¸cão aprova 2 ou mais transa¸cões adicionadas anteriormente

`

a rede; a Nano usa block-lattice, estruturada por contas, onde cada conta tem a sua própria blockchain; e a Hedera Hashgraph, que através daHashgraph, regista as transa¸cões por ordem cronológica e comunica-as para toda a rede através de “gossip about a gossip”.

Para controlar ataques aos sistemas, estas criptomoedas exigem algum tipo de prova aos nós da rede, de forma a validar a sua autenticidade. No caso dos sistemas IOTA e Nano, estes têm metodologias semelhantes no requistos de provas aos os nós envolvidos nas transa¸cões, exigindo uma PoW que envolve a computa¸cão de umnonce. Em rela¸cão à Hedera Hashgraph,

(42)

´e referido o “Byzantine Fault Tolerant” ass´ıncrono (aBFT), que permite que haja consenso desde que os atacantes da rede detenham menos de 1/3 da sua riqueza.

Em rela¸cão à atribui¸cão de um grau de confian¸ca a uma transa¸cão, as três criptomoedas assumem comportamentos distintos. Na IOTA, o fator mais relevante é o peso acumulado de uma transa¸cão, que consiste na soma do peso da própria transa¸cão ao peso de todas as transa¸cões que a aprovam direta ou indiretamente. No caso da Nano e Hedera Hashgraph, estas adotam um sistema de votos para assegurar o consenso dos nós da rede em rela¸cão

`

as transa¸cões, ou seja, a confian¸ca das transa¸cões está dependente do poder que os nós têm nas vota¸cões. Ambas envolvem vota¸cões com base numa PoS, mas os critérios que definem o poder de cada nó numa vota¸cão são diferentes. No caso da Nano, os nós que votam são os nós representantes e, o peso de cada um, é definido pela soma dos saldos das contas que cada um representa, enquanto que no caso da Hedera Hashgraph, todos os nós votam e o peso de cada um é definido pelo seu próprio saldo.

Quanto à taxa por cada transa¸cão efetuada, através da IOTA e Nano, nenhum custo recai sobre o utilizador, enquanto que, no caso da Hedera Hashgraph, o utilizador necessita de pagar um montante muito pouco significativo, tipicamente de$0,0001.

Apesar de referidas como criptomoedas, IOTA⁵, Nano e Hedera Hashgraph, são as plataformas que suportam as respetivas criptomoedas: MIOTA, NANO e HBAR. Aquando dos “genesis” das mesmas, foram criadas 2.779.530.283 MIOTA, 133.248.297 NANO e 50.000.000.000 HBAR, estando todas em circula¸cão no caso das plataformas IOTA e Nano, e 6.760.903.627 das 50 mil milhões de HBAR⁶. Atualmente, estas têm um valor total de mercado respetivo de$1.045.625.530, $366.597.960 e $263.700.800 [20].

5IOTA ´e tamb´em uma unidade da criptomoeda (1 MIOTA = 1.000.000 IOTA)

6At´e ao momento.