A Figura 27 ilustra a visão geral da arquitetura, sendo esta dividida em três camadas denomina- das de camada blockchain, camada de comunicação e camada de aplicação. Na camada blockchain são armazenados os contratos inteligentes e as transações efetuadas no ambiente são validadas. Nesta ca- mada são utilizados dispositivos com poder computacional considerável para efetuar o processamento das requisições da blockchain. A camada de comunicação é responsável por gerir a comunicação
dispositivo-usuário. Para isso, utiliza-se um gateway, considerando que os dispositivos IoT não pos- suem poder computacional suficiente para se comunicar diretamente com a blockchain. Por fim, a camada de aplicação consiste no ambiente, usuário e dispositivo, no qual cada um interage com o outro através da aplicação mobile descentralizada desenvolvida. Nessa camada, também está disposto o serviço de armazenamento IPFS para armazenamento dos dados.
Blockchain Layer
Communication Layer
Application Layer
Environment User Device IPFS Storage
Gateway High Processing Devices
Figura 27. Arquitetura PRICHAIN.
Fonte: Ochôa et al. (2019).
Considerando a arquitetura ilustrada na Figura 27 e o middleware descrito na Seção 2.3.1, percebe-se que o PRICHAIN é uma implementação descentralizada do middleware UbiPri. A utilização dos contratos inteligentes em conjunto com o gateway e o serviço de armazenamento IPFS garantem a funcionalidade dos módulos do UbiPri. A utilização de diferentes contratos inteligentes, sendo um para o ambiente, um para o dispositivo e outro para o usuário, favorecem a implementação do UbiPri de maneira descentralizada. O serviço de armazenamento IPFS descentralizado e o gateway de comunicação auxiliam na implementação dos outros módulos do middleware.
4.2.1 Contratos Inteligentes
Como mencionado anteriormente, uma das premissas do middleware UbiPri refere-se ao conceito de que o ambiente denota as regras de privacidade. Sendo assim, optamos por utilizar um contrato inteligente especificamente para o ambiente. O usuário possui um contrato inteligente separado com suas preferências de privacidade individuais, essa escolha foi feita levando em conta que o usuário
pode não concordar com as regras do ambiente. Por fim os dispositivos (sensores e atuadores) também possuem contratos inteligentes com suas preferências de privacidade. A estrutura dos contratos pode ser observada em detalhes nos Apêndices D, E e C.
4.2.1.1 Contrato do Ambiente
O contrato Ambiente possui uma estrutura de regras com base em uma string de identificação, uma de descrição da regra e um campo byte de valores. Há também a possibilidade de se definir um valor para o nível de permissão necessário para interagir com o ambiente, além de definir se o Ambiente exigirá ou não o acesso ao histórico de dados do usuário. O contrato Usuário, descrito logo a seguir, possui uma estrutura de opções de privacidade, também contendo campos de identificação e valor.
Um nível de acesso pode ser definido para o usuário, tal como se ele permitirá ou não o acesso ao seu histórico de dados. Um método chamado connectToEnvironment exige o endereço de um Ambiente para verificar se as opções de privacidade, nível de acesso e uso de dados são compatíveis entre os contratos, retornando os itens incopatíveis caso haja algum. O método connectToDevice realiza as mesmas operações, mas com base em uma lista de dispositivos presente no Ambiente, no qual pode haver a descoberta de serviços pelo usuário. As opções de privacidade incompatíveis são armazenadas em uma estrutura de operações pendentes, na qual o usuário pode aplicar caso concorde com elas.
Antes de cada troca, os valores de privacidade antigos são armazenados em uma estrutura de backup, para que o usuário possa retorná-los a qualquer hora. Por último, o contrato Dispositivo também possui uma lista de privacidades exigidas, permissão para o uso do histórico do usuário e nível de permissão necessário. Além disso, o endereço MAC do dispositivo físico é armazenado pelo contrato, o qual será retornado, caso o usuário possa, com sucesso, conectar-se ao dispositivo. O Apêndice C ilustra o contrato descrito.
4.2.1.2 Contrato do Usuário
O usuário pode se comunicar com um ambiente, fornecendo seu endereço como argumento durante uma operação connectToEnvironment. A partir disso, a compatibilidade entre as preferências do usuário e as regras do ambiente será testada, bem como o nível de permissão necessário. Em caso de incompatibilidade, a blockchain retornará uma lista de quadros, incluindo o nome e o valor de preferências ausentes ou incompatíveis, bem como o número de itens nessa lista e um valor lógico indicando se a operação foi bem-sucedida ou não. No caso de compatibilidade, o contrato do ambiente será emparelhado com o contrato do usuário. O Apêndice D ilustra o contrato descrito.
4.2.1.3 Contrato do Dispositivo
Estando conectado ao ambiente, uma lista de dispositivos estará disponível no contrato e será apresentada ao usuário. O usuário, em seu contrato, poderá inserir como argumento o endereço do dispositivo alvo dentro da função connectToDevice. Todas as preferências, assim como o nível de permissão exigido, serão testados também, retornando, em caso de falha, a lista de preferências incompatíveis, tamanho da lista, código de operação em valor lógico e o endereço MAC nulo. Em caso de sucesso na comunicação, o endereço MAC correspondente do dispositivo poderá ser resgatado pelo aplicativo Android. O Apêndice E ilustra o contrato descrito.
A Figura 28 ilustra o diagrama de sequência da comunicação entre usuário e ambiente.
Contrato do
Ambiente Contrato do Usuário
Aplicação Mobile Descentralizada
1. Conexão
2.Solicita compatibilidade
3.Retorna Compatibilidade
4. Solicita alterações
5. Confirma alterações
6. Realiza Alterações
Figura 28. Comunicação Usuário-Ambiente.
Fonte: Adaptado de Ochôa et al. (2019).
4.2.2 Gateway de Comunicação
O gateway media a comunicação entre o usuário e o dispositivo. O protocolo de comunicação adotado foi o CoAP, utilizando a biblioteca CoAPthon3, para a linguagem Python. Todas as operações realizadas são baseadas nos recursos disponíveis através do gateway. Um dispositivo pode executar uma operação POST para fornecer um novo serviço (ou recurso) identificado pela concatenação de seu endereço MAC com o tipo de serviço oferecido (por exemplo, CA: FE: CA: FE: CA: FE-LED).
Assim, o dispositivo pode ser configurado para atualizar um recurso com os valores de um sensor ou executar um GET periódico em um recurso para obter o seu valor, como no estado de um LED alterado pelo usuário. Quando um dos pontos opera com PUT, o gateway lê a fonte, o endereço MAC de destino e os dados de comunicação. Essas informações de leitura serão enviadas imediatamente para um nó IPFS usando o ipfs-API, onde permanecerão inalteradas. O usuário poderá conectar-se a um recurso do dispositivo via MAC retornado da função de emparelhamento disponível no contrato inteligente, o qual concatena com um dos nomes de serviços descobertos. O Apêndice F ilustra o gateway implementado e o Apêndice G ilustra a interação do gateway com o Arduino.
4.2.3 Aplicação Mobile Descentralizada
Como prova de conceito e validação da arquitetura proposta, um aplicativo para smartphone foi desenvolvido usando a biblioteca Web3 baseada na plataforma React. O aplicativo da Web escrito em JavaScript e HTML5 fornece a interface do usuário para o cliente Ethereum, que por sua vez, interage com o blockchain.
O principal objetivo deste aplicativo é interagir com os três contratos inteligentes (Usuário, Ambiente e Dispositivo) mencionados acima. A Figura 29 representa a tela de login para o usuário do aplicativo controlar o ambiente, o menu com opções disponíveis e, finalmente, a lista de ambientes disponíveis para a interação do usuário.
Figura 29. Aplicação mobile PRICHAIN.
Fonte: Ochôa et al. (2019).
5 RESULTADOS
Neste capítulo são apresentadas as análises dos resultados obtidos durante os testes. Na Seção 5.1 é feita a descrição dos resultados obtidos em relação ao desempenho da blockchain no que se refere ao uso de gas e custo de transação. Na Seção 5.2 são analisados os resultados de desempenho do gateway, foram analisados os métodos GET e PUT em diferentes situações. Na Seção 5.3 é ilustrado como as preferências de privacidade são garantidas através da solução proposta. Na Seção??é ilustrado como o sistema IPFS garante segurança no armazenamento dos dados. Por fim, a Seção 5.4 ilustra quais funcionalidades do middleware UbiPri são satisfeitas na implementação proposta.
O hardware utilizado consiste em um Arduino Uno R3 de arquitetura 16 bits operando a 16MHz e 2KB de SRAM juntamente com Ethernet Shield W5100. Os sensores utilizados foram um DHT11 com resolução de 16 bits para medir temperatura e umidade e um sensor ultrassônico HC-SR04 para verificar presença de pessoas no ambiente. O gateway e o IPFS foram implementados em um notebook Dell com Intel Core I5 8265U com 4 núcleos, 8 threads, operando a 1.6GHz e 8gb de memória RAM DDR4 e sistema operacional Kubuntu 18.04 de 64 bits. A blockchain operou em um notebook Acer com Intel Core I3 8130U com 2 núcleos e 4 threads, operando a 2.2GHz e 4GB de memória RAM DDR4 com sistema operacional Linux Mint Cinnamon 19.1 64 bits. A comunicação CoAP no Arduino aconteceu através da biblioteca SimpleCoAP disponível no gerenciador de bibliotecas da Arduino IDE.
O sketch utilizado no Arduino ocupou 19998 bytes dos 32256 bytes de armazenamento flash disponível. Não utilizou armazenamento em EEPROM e 785 bytes de 2048 de memória dinâmica disponível no dispositivo, representando 38% do total. O ambiente foi simulado em rede local, por este motivo a latência de transmissão pela rede foi desconsiderada.
A TestNet Ropsten foi utilizada como blockchain privada, a fim de testar a interação entre os contratos sem custos de produção. A média de tempo para a mineração de um bloco é de 15 segundos, o seu preço de gás padrão é de 4 GWei e o limite de gás por bloco é de 6.721.975.