• Nenhum resultado encontrado

Exemplo de Resposta da API Implantada na AWS para a Rota Flights

Fonte: o Autor

3.3.2.3 Construção da Inteface Gráfica

Visando permitir a interação de usuários com a aplicação resultante da prova de conceito, foi construída uma interface gráfica bem simples e objetiva. Ela foi construída com o uso da bibliotecaReactJSdo JavaScript, HTML e CSS. Tecnologias clássicas para construção do front-endde uma aplicação. Caso seja do interesse, é possível acessar ao repositório referenciado no apêndice A para visualizar o código-fonte.

A figura 18 mostra a tela que o usuário se deparará no primeiro acesso, em que ele ainda não conectou sua carteira cripto para poder interagir com a aplicação. As variações da tela poderão ser vistas no capítulo seguinte.

Figura 18 – Tela Inicial da Aplicação Resultante da Prova de Conceito

Fonte: o Autor

4 RESULTADOS

Com a delimitação de contexto definida e desenvolvimento da aplicação, foram obtidos resultados que corroboram a viabilidade técnica do uso deSmart Contractpara contratação de seguros paramétricos descentralizados. A seguir, será mostrado o fluxo prático de contratação de um seguro para voos atrasados.

4.1 CONTRATAÇÃO DO SEGURO PARAMÉTRICO

Ao clicar no botão de se conectar, que pode ser observado na figura 18, o usuário terá a possibilidade de pesquisar voos inserindo o número dele e visualizar os seus contratos existentes, caso possua algum. A figura 19 ilustra a nova tela apresentada ao usuário, quando uma carteira é vinculada, destacando-se o endereço da carteira conectada à aplicação e o campo em que é inserido o número do voo.

Figura 19 – Tela do Usuário com a Carteira Conectada

Fonte: o Autor

Ao inserir o número de um voo existente naAPI, será possível contratar o seguro para ele. Como já frisado no capítulo anterior, as informações de voos são fictícias e estão sendo provisionadas pelaAPIoráculo. Como ilustra a figura 20, as informações associadas ao voo são mostradas e é apresentado o botão de solicitar seguro. Observe, ainda, que os valores de prêmio

e recompensa já são previamente definidos. Para a finalidade deste trabalho, a sustentabilidade econômica não está sendo levada em consideração, apenas a implementação técnica. Portanto, os valores apresentados para prêmio do seguro e recompensa têm apenas um papel figurativo.

Além disso, é válido ressaltar que os valores estão sendo cotados emether(ETH), a criptomoeda nativa da redeBlockchain.

Figura 20 – Tela com Informações do Voo e Seguro

Fonte: o Autor

Então, ao clicar no botão de solicitar seguro, aMetamaskentra em ação e permite que o usuário realize a transação e interaja com oSmart Contract. A estratégia doSmart Contract construído para esta prova de conceito é ser uma fábrica de contratos inteligentes. O contrato pai, que é mantido pela seguradora, consegue gerar vários contratos filhos. A lógica de tal implementação pode ser observada no código-fonte presente no apêndice A.

O usuário terá duas interações com aMetamaskpara que oSmart Contractatribuído ao voo seja criado. A primeira interação é para pagar o prêmio do seguro à seguradora, ou seja, o valor do prêmio é alocado no contrato pai. A segunda transação é responsável por criar o contrato inteligente de seguro associado ao voo (contrato filho) e pertencente ao segurado. Quando um

contrato filho é criado, o valor da recompensa do seguro é retirado do saldo do contrato pai e alocado no saldo do contrato gerado para o voo.

A figura 21 mostra a interação com aMetamaske destaca algumas informações importantes a respeito da transação, como: rede em que ela está ocorrendo, valor da transação (prêmio do seguro) e a taxa de combustível (gas fee), que foi melhor explicada na subseção 2.1.6.4. Frisando novamente o não foco na sustentabilidade financeira do modelo, a taxa de combustível é uma questão que deve ser melhor tratada considerando a aplicação em uma situação real, visto que o valor do prêmio e recompensa do seguro não leva tal taxa em consideração.

Figura 21 – Realização da Transação para Depositar o Valor do Prêmio

Fonte: o Autor

A figura 22 mostra a segunda interação, cujo o contrato atribuído ao voo é criado. É neste momento que o contrato pai envia parte do seu saldo (o valor da recompensa do seguro) para o contrato filho que está sendo gerado.

Figura 22 – Realização da Transação para Criar o Contrato Atribuído ao Voo

Fonte: o Autor

4.2 REGISTRO DO SEGURO PARAMÉTRICO NA REDE RINKEBY

Cada interação com a Metamask representa uma transação na redeRinkebye, portanto, um registro no livro-razão. A figura 23 mostra o contrato pai na redeRinkebye as transações que ocorreram nele. Ainda, na figura 23, destacam-se as duas últimas transações referenciadas nas figuras 21 e 22 e o saldo do contrato que houve alteração se comparado à figura 16.

4.3 SOLICITAÇÃO DE RECOMPENSA

Uma recompensa de seguro só é solicitável para voos que já aconteceram, visto que o objetivo é ser beneficiado em caso de atraso ou cancelamento. Para realizar tal demonstração, será utilizada uma conta que possui um contrato passível de análise.

A interface gráfica indica quando um contrato já pode ser analisado, conforme mostra a figura 24, que também destaca a carteira com o saldo atual do segurado para fins de comparações a seguir.

Ao clicar em solicitar análise, o contrato atribuído ao voo recebe a informação do status do voo. Tal informação é fornecida pelaAPI oráculo. Então, em caso de atraso ou cancelamento,

o valor da recompensa do seguro é enviado à carteira do segurado. Caso contrário, o valor é enviado à carteira da seguradora.

Simulando um cenário na qual o segurado é beneficiado, isto é, houve atraso ou cancelamento do voo, a figura 25 mostra o novo saldo da carteira, com o acréscimo da recompensa do seguro1, e a atualização do estado do contrato na interface gráfica com a informação de que ele já foi analisado e, portanto, encerrado.

Figura 23 – Transações Registradas no Livro-razão da Rede Rinkeby

Fonte: o Autor

1Há um pequeno desconto devido à taxagas feecobrada pela rede para realizar a transação que informa ao contrato ostatusdo voo.

Figura 24 – Contrato Disponível para Solicitar Seguro

Fonte: o Autor

Figura 25 – Contrato Analisado após Solicitação

Fonte: o Autor

5 CONCLUSÃO

As figuras apresentadas no capítulo anterior ilustram o processo de contratação e solicitação de recompensa de seguro na prova de conceito. Nota-se que é um processo extremamente simples, mas com um resultado bem significativo, visto que que as interações entre contas e contratos sem um intermediário são comprovadas. É evidente que existem muitas abstrações e simplificações, principalmente no tocante à sustentabilidade financeira do modelo e ao consumo de informação externa à redeBlockchainpor meio de oráculos, mas a prova de conceito consegue cumprir o objetivo proposto: demonstrar a viabilidade técnica do uso de Smart Contractspara seguros paramétricos descentralizados.

Pensando no cenário de produção para um seguro paramétrico descentralizado contra atrasos ou cancelamentos de voos, que foi o produto considerado pela prova de conceito, muitas camadas precisam ser acrescidas. As mais relevantes, em conjunto com a refatoração do contrato para que o mesmo tenha mais complexidade e segurança, é o uso de alguma rede de oráculo Blockchaindescentralizada, visando aumentar a confiabilidade e garantia de neutralidade das relações entre segurado e seguradora e a adoção deAPIs com informações reais de voos. Para a questão do oráculo descentralizado, existem no mercado algumas soluções, sendoChainlinke Provable, no momento de escrita deste trabalho, as mais populares.

Um outro aspecto que pode ser melhor desenvolvido é quanto à viabilidade econômica.

A prova de conceito leva somente a viabilidade técnica em consideração. Então, para chegar à conclusão de que se trata de um modelo de negócio factível em sua totalidade, necessita-se demonstrar a viabilidade financeira.

5.1 TRABALHOS FUTUROS

A partir deste trabalho, nasce a possibilidade para muitos trabalhos futuros. Alguns diretamente relacionados ao que foi discutido aqui e outros que podem usar alguns assuntos abordados como fagulha inicial para uma linha de pesquisa bem diferente. Portanto, pode-se dividir em trabalhos futuros que se relacionam diretamente com esta linha de pesquisa e trabalhos futuros que se derivam desta linha de pesquisa.

Começando pelos que se relacionam diretamente:

a) Construção de modelos determinísticos de risco para assegurar a viabilidade financeira dos seguros paramétricos descentralizados;

b) Construção de uma prova de conceito com o uso de oráculos descentralizados;

c) Análise sociológica e econômica da existência de um modelo de seguro descentrali-zado;

d) Construção de uma redeBlockchainprivada;

e) Exploração de falhas de seguranças nosSmart Contracts;

f) Uso deSmart Contractspara seguros paramétricos agrícolas.

Trabalhos indiretamente relacionados:

a) Análise aprofundada dos algoritmos de consenso;

b) Aplicação deBlockchaineSmart Contractsem outras indústrias;

c) Desenvolvimentos de oráculosBlockchainbaseados emhardware d) Estratégias para a construção de oráculosBlockchain;

São muitas as possibilidades. Acima, têm-se algumas julgadas extremamente interessantes pelo autor.

5.2 CONSIDERAÇÕES FINAIS

O presente trabalho começou com a proposição de um projeto que dialogasse com os recentes avanços promovidos peloOpen Insurance, um análogo doOpen Bankingpara a indústria de seguros. A ideia inicial era a construção de um comparador de seguros baseado em sistemas de recomendação. Tratava-se de uma proposta motivada pela vontade de propor produtos e serviços que coloquem o cliente no centro.

À medida que os estudos específicos para o desenvolvimento do comparador iam evoluindo, notava-se uma grande dificuldade, dada a dependência da evolução das fases doOpen Insurance e toda a regulação imposta pela SUSEP.

Então, ao estudar o conceito deSmart Contract, a direção do trabalho mudou e uma nova ideia surgiu, resultando-se neste trabalho: uma prova de conceito, que apesar de bem diferente de um comparador, mantém o sentimento inicial de querer colocar o consumidor no centro, permitindo-o contratar um serviço de seguro transparente, objetivo e sem centralização de poder.

Ao abordar a ideia deSmart Contractsbaseados emBlockchain, um assunto de muito potencial tecnológico-científico, espera-se abrir espaço para o nascimento de discussões ricas e soluções que tornem o mundo um lugar mais equitativo.

A concepção do projeto como um todo pode ser vista nos seguintes repositórios doGithub (clique para ser redirecionado):

a) Aplicação (Smart Contractefront-end) b) API(oráculo mimetizado)

A seguir, têm-se os códigos-fonte julgados mais relevantes do projeto.

1 p r a g m a s o l i d i t y ^ 0 . 8 . 0 ; 2

3 c o n t r a c t I n s u r a n c e {

4 a d d r e s s p u b l i c i n s u r e r ; 5 a d d r e s s p u b l i c i n s u r e d ;

6 s t r i n g p u b l i c a i r l i n e C o m p a n y ; 7 u i n t 2 5 6 p u b l i c f l i g h t N u m b e r ; 8 u i n t 2 5 6 p u b l i c p r e m i u m ; 9 u i n t 2 5 6 p u b l i c p a y o u t ;

10 b o o l p u b l i c i s F l i g h t D e l a y e d ; 11 u i n t 2 5 6 p u b l i c d e p a r t u r e D a t e ; 12 u i n t 2 5 6 p u b l i c t i m e s t a m p;

13 b o o l i s O r a c l e A l r e a d y C a l l e d = f a l s e; 14

15 c o n s t r u c t o r(

16 a d d r e s s _ i n s u r e r ,

17 a d d r e s s _ i n s u r e d ,

18 s t r i n g m e m o r y _ a i r l i n e C o m p a n y , 19 u i n t 2 5 6 _ f l i g h t N u m b e r ,

20 u i n t 2 5 6 _ p r e m i u m ,

21 u i n t 2 5 6 _payout ,

22 u i n t 2 5 6 _ d e p a r t u r e D a t e

23 ) p u b l i c {

24 i n s u r e r = _ i n s u r e r ; 25 i n s u r e d = _ i n s u r e d ;

26 a i r l i n e C o m p a n y = _ a i r l i n e C o m p a n y ; 27 f l i g h t N u m b e r = _ f l i g h t N u m b e r ; 28 p r e m i u m = _ p r e m i u m ;

29 p a y o u t = _ p a y o u t ;

30 d e p a r t u r e D a t e = _ d e p a r t u r e D a t e ; 31 p a y o u t = _ p a y o u t ;

32 i s F l i g h t D e l a y e d = f a l s e; 33 t i m e s t a m p = b l o c k.t i m e s t a m p;

34 } 35

36 f u n c t i o n t r a n s f e r P a y o u t (a d d r e s s p a y a b l e r e c i p i e n t ) p u b l i c p a y a b l e { 37 r e q u i r e(msg.s e n d e r == i n s u r e d ) ;

38

39 r e c i p i e n t .t r a n s f e r( p a y o u t ) ;

40 }

41

42 f u n c t i o n c a l l O r a c l e (b o o l _ o r a c l e I n f o r m a t i o n ) p u b l i c { 43 r e q u i r e(msg.s e n d e r == i n s u r e d ) ;

44 r e q u i r e(! i s O r a c l e A l r e a d y C a l l e d ) ; 45

46 i s F l i g h t D e l a y e d = _ o r a c l e I n f o r m a t i o n ; 47

48 if ( i s F l i g h t D e l a y e d ) {

49 t r a n s f e r P a y o u t (p a y a b l e( i n s u r e d ) ) ;

50 } e l s e {

51 t r a n s f e r P a y o u t (p a y a b l e( i n s u r e r ) ) ;

52 }

53

54 i s O r a c l e A l r e a d y C a l l e d = t r u e;

55 }

56

57 f u n c t i o n g e t B a l a n c e () p u b l i c v i e w r e t u r n s (u i n t 2 5 6) { 58 r e t u r n a d d r e s s(t h i s) .b a l a n c e;

59 }

60

61 r e c e i v e () e x t e r n a l p a y a b l e {}

62 } 63

64 c o n t r a c t I n s u r a n c e F a c t o r y {

65 a d d r e s s p r o v i d e r = msg.s e n d e r;

66 a d d r e s s p r o v i d e r C o n t r a c t A d d r e s s = a d d r e s s(t h i s) ; 67 b o o l i s C o n t r a c t A c t i v e = t r u e;

68

69 s t r u c t I n s u r a n c e I n f o r m a t i o n s { 70 a d d r e s s c o n t r a c t A d d r e s s ;

71 a d d r e s s i n s u r e d ;

72 s t r i n g a i r l i n e C o m p a n y ;

73 u i n t 2 5 6 f l i g h t N u m b e r ;

74 u i n t 2 5 6 p r e m i u m ;

75 u i n t 2 5 6 p a y o u t ;

76 u i n t 2 5 6 d e p a r t u r e D a t e ; 77 u i n t 2 5 6 t i m e s t a m p;

78 }

79

80 I n s u r a n c e I n f o r m a t i o n s [] i n s u r a n c e s ; 81

82 c o n s t r u c t o r() p a y a b l e {}

83

84 e v e n t N e w I n s u r a n c e (

85 a d d r e s s i n d e x e d insured ,

86 s t r i n g a i r l i n e C o m p a n y , 87 u i n t 2 5 6 f l i g h t N u m b e r ,

88 u i n t 2 5 6 premium ,

89 u i n t 2 5 6 payout ,

90 u i n t 2 5 6 d e p a r t u r e D a t e ,

91 u i n t 2 5 6 t i m e s t a m p

92 ) ;

93

94 f u n c t i o n c r e a t e I n s u r a n c e (

95 s t r i n g m e m o r y _ a i r l i n e C o m p a n y , 96 u i n t 2 5 6 _ f l i g h t N u m b e r ,

97 u i n t 2 5 6 _ p r e m i u m ,

98 u i n t 2 5 6 _payout ,

99 u i n t 2 5 6 _ d e p a r t u r e D a t e 100 ) p u b l i c p a y a b l e {

101 r e q u i r e( i s C o n t r a c t A c t i v e ) ;

102 r e q u i r e( h a s B a l a n c e T o C o v e r P a y o u t ( _ p a y o u t ) ) ; 103

104 I n s u r a n c e i n s u r a n c e = new I n s u r a n c e (

105 p r o v i d e r ,

106 msg.sender,

107 _ a i r l i n e C o m p a n y ,

108 _ f l i g h t N u m b e r ,

109 _ p r e m i u m ,

110 _payout ,

111 _ d e p a r t u r e D a t e

112 ) ; 113

114 i n s u r a n c e s .p u s h(

115 I n s u r a n c e I n f o r m a t i o n s (

116 a d d r e s s( i n s u r a n c e ) ,

117 msg.sender,

118 _ a i r l i n e C o m p a n y ,

119 _ f l i g h t N u m b e r ,

120 _ p r e m i u m ,

121 _payout ,

122 _ d e p a r t u r e D a t e ,

123 b l o c k.t i m e s t a m p

124 )

125 ) ;

126

127 e m i t N e w I n s u r a n c e (

128 msg.sender,

129 _ a i r l i n e C o m p a n y ,

130 _ f l i g h t N u m b e r ,

131 _ p r e m i u m ,

132 _payout ,

133 _ d e p a r t u r e D a t e ,

134 b l o c k.t i m e s t a m p

135 ) ;

136

137 (b o o l success , ) = (a d d r e s s( i n s u r a n c e ) ) .c a l l{v a l u e: _ p a y o u t }(" ")

;

138 r e q u i r e( success , " F a i l e d to w i t h d r a w m o n e y f r o m c o n t r a c t . ") ;

139 }

140

141 f u n c t i o n g e t A l l I n s u r a n c e s ()

142 p u b l i c

143 v i e w

144 r e t u r n s ( I n s u r a n c e I n f o r m a t i o n s [] m e m o r y)

145 {

146 r e t u r n i n s u r a n c e s ;

147 }

148

149 f u n c t i o n g e t P r o v i d e r () p u b l i c v i e w r e t u r n s (a d d r e s s) {

150 r e t u r n p r o v i d e r ;

151 }

152

153 f u n c t i o n g e t R e s i d u a l E t h () p u b l i c p a y a b l e { 154 r e q u i r e(msg.s e n d e r == p r o v i d e r ) ;

155

156 p a y a b l e( p r o v i d e r ) .t r a n s f e r(a d d r e s s(t h i s) .b a l a n c e) ;

157 }

158

159 f u n c t i o n g e t B a l a n c e () p u b l i c v i e w r e t u r n s (u i n t 2 5 6) { 160 r e t u r n a d d r e s s(t h i s) .b a l a n c e;

161 }

162

163 f u n c t i o n e n d C o n t r a c t () p u b l i c { 164 r e q u i r e(msg.s e n d e r == p r o v i d e r ) ; 165 i s C o n t r a c t A c t i v e = f a l s e;

166 g e t R e s i d u a l E t h () ;

167 }

168

169 f u n c t i o n h a s B a l a n c e T o C o v e r P a y o u t (u i n t 2 5 6 _ p a y o u t )

170 p u b l i c

171 v i e w

172 r e t u r n s (b o o l)

173 {

174 if ( _ p a y o u t >= a d d r e s s( p r o v i d e r C o n t r a c t A d d r e s s ) .b a l a n c e) {

175 r e t u r n f a l s e;

176 }

177

178 r e t u r n t r u e;

179 }

180

181 r e c e i v e () e x t e r n a l p a y a b l e {}

182 }

Documentos relacionados