Get best of the week

Desenvolva software para aluguel de scooter descentralizado. Quem disse que seria fácil?

Neste artigo, falarei sobre como tentamos criar um aluguel de scooter descentralizado com contratos inteligentes e por que ainda precisávamos de um serviço centralizado.



Como tudo começou


Em novembro de 2018, participamos de um hackathon dedicado à Internet das coisas e blockchain. Nossa equipe escolheu o compartilhamento de scooter como uma idéia, já que tínhamos uma scooter do patrocinador desta hackathon. O protótipo parecia um aplicativo móvel que permite executar uma scooter via NFC. Do ponto de vista de marketing, a idéia foi reforçada por uma história sobre um "futuro brilhante", com um ecossistema aberto, onde todos podem se tornar inquilinos ou proprietários, todos baseados em contratos inteligentes.

Nossos stakeholders gostaram muito dessa ideia e decidiram transformá-la em um protótipo para demonstração em exposições. Após vários shows de sucesso no Mobile World Congress e no Bosch Connected World em 2019, foi decidido testar o aluguel de scooters em usuários reais, funcionários da Deutsche Telekom. Então começamos a desenvolver um MVP completo.

Blockchain da muleta


Acho que não vale a pena explicar qual é a diferença entre um projeto para exibição no palco e o que as pessoas reais usarão. Por seis meses, tivemos que transformar o protótipo bruto em algo adequado para o piloto. E então percebemos o que "dor" significa.

Para tornar nosso sistema descentralizado e aberto, decidimos usar os contratos inteligentes da Ethereum. A escolha caiu nesta plataforma de serviços online descentralizados devido à sua popularidade e à capacidade de criar um aplicativo sem servidor. Planejamos implementar nosso projeto da seguinte maneira.



Infelizmente, porém, um contrato inteligente é um código executado por uma máquina virtual no momento de uma transação e não pode substituir um servidor de pleno direito. Por exemplo, um contrato inteligente não pode executar atividades pendentes ou agendadas. Em nosso projeto, isso não nos permitiu implementar o serviço de aluguel por minuto, como faz o compartilhamento de carros mais moderno. Portanto, deduzimos a criptomoeda do usuário após a conclusão da operação, sem a certeza de que ele possui dinheiro suficiente. Essa abordagem é aceitável apenas para o piloto interno e, é claro, aumenta os problemas ao projetar um projeto de produção completo.

Para todos os itens acima, a umidade da própria plataforma é adicionada. Por exemplo, a criação de um contrato inteligente com lógica diferente dos tokens do ERC-20 levará a um problema de manipulação de erros. Geralmente, com uma entrada incorreta ou operação incorreta de nossos métodos, obtemos um código de erro em resposta. No caso do Ethereum, não podemos obter nada além da quantidade de gás gasta para executar essa função. Gás é a moeda que você precisa pagar por transações e cálculos: quanto mais transações em seu código, mais você paga. Portanto, para entender por que o código não funciona, primeiro teste-o, simulando todos os erros possíveis e codifique o gás gasto como código de erro. Mas se você alterar seu código, esse tratamento de erros será interrompido.

Além disso, é quase impossível criar um aplicativo móvel que funcione honestamente com o blockchain, sem usar uma chave armazenada em algum lugar da nuvem. Embora existam carteiras honestas, elas não fornecem interfaces para assinar transações externas. Isso significa que você não poderá ver o aplicativo nativo se ele não tiver uma carteira criptográfica embutida, na qual os usuários terão pouca confiança (eu não confiaria). Como resultado, também tivemos que cortar um canto. Contratos inteligentes foram entregues à rede privada Ethereum e a carteira estava turva. Mas, apesar disso, nossos usuários sentiram todos os "encantos" dos serviços descentralizados na forma de uma longa espera por transações várias vezes por sessão de aluguel.

Tudo isso nos leva a essa arquitetura. Concordo, é muito diferente do que planejamos.



Ace na manga: Identidade Soberana


Você não pode construir um sistema totalmente descentralizado sem identificação descentralizada. A Identidade Soberana (SSI) é responsável por essa parte, cuja essência é que você descarta um provedor de identidade centralizado (IDP) e distribui para as pessoas todos os dados e responsabilidades por eles. Agora, o usuário decide quais dados ele precisa e com quem ele os compartilhará. Toda essa informação está no dispositivo do usuário. Mas, para compartilhar, precisamos de um sistema descentralizado de armazenamento de evidências criptográficas. Todas as implementações modernas do conceito SSI usam blockchain como armazenamento.

"O que tem o ás na minha manga?" - você pergunta. Lançamos o serviço para um teste interno em nossos próprios funcionários em Berlim e Bonn, e enfrentamos dificuldades diante dos sindicatos alemães. Na Alemanha, as empresas são proibidas de monitorar os movimentos dos funcionários, e os sindicatos controlam isso. Essas restrições acabam com o armazenamento centralizado dos dados de identidade do usuário, pois, nesse caso, teríamos conhecido a localização dos funcionários. Ao mesmo tempo, não pudemos verificá-los devido à possibilidade de seqüestrar scooters. Mas, graças à identidade auto-soberana, nossos usuários usaram o sistema anonimamente e a própria scooter verificou a disponibilidade da carteira de motorista antes de iniciar o aluguel. Como resultado, mantivemos métricas de usuário anonimizadas, não possuímos documentos ou dados pessoais: todos eles foram armazenados nos dispositivos dos próprios drivers.Assim, graças à SSI, a solução para o problema em nosso projeto estava pronta antes mesmo de aparecer.

O dispositivo lançou problemas


Não implementamos a identidade auto-soberana por conta própria, pois isso requer experiência em criptografia e muito tempo. Em vez disso, aproveitamos o produto de nossos parceiros Jolocom e integramos sua carteira e serviços móveis em nossa plataforma. Infelizmente, este produto tem uma desvantagem significativa: a principal linguagem de desenvolvimento é o Node.js.

Essa pilha tecnológica nos limita muito na escolha de ferro embutido em uma scooter. Felizmente, no início do projeto, nossa escolha recaiu sobre o Raspberry Pi Zero e aproveitamos o microcomputador completo. Isso nos permitiu executar o volumoso Node.js em uma scooter. Além disso, obtivemos monitoramento e acesso remoto via vpn usando ferramentas prontas.

Finalmente


Apesar de toda a “dor” e problemas, o projeto foi lançado. Nem tudo funcionou como planejado, mas era realmente possível andar de scooter alugando-as.

Sim, cometemos vários erros no design da arquitetura, o que não nos permitiu tornar o serviço completamente descentralizado, mas mesmo sem esses erros, dificilmente conseguiríamos criar uma plataforma sem servidor. Uma coisa é escrever outra pirâmide de criptografia e outra é um serviço completo no qual você precisa lidar com erros, resolver casos de fronteira e executar tarefas pendentes. Vamos torcer para que novas plataformas surgidas recentemente sejam mais flexíveis e funcionais.

More articles:


All Articles