Neste artigo falarei sobre como tentamos construir o aluguel descentralizado de scooters em 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 ao blockchain. A nossa equipa escolheu a partilha de scooters como ideia, uma vez que tínhamos uma scooter do patrocinador deste hackathon. O protótipo parecia um aplicativo móvel que permite iniciar uma scooter via NFC. Do ponto de vista do marketing, a ideia foi apoiada por uma história sobre um “futuro brilhante” com um ecossistema aberto onde todos podem tornar-se inquilinos ou proprietários, tudo baseado em contratos inteligentes.
Os nossos stakeholders gostaram muito desta ideia e decidiram transformá-la num protótipo para exposição em exposições. Após várias demonstrações bem-sucedidas no Mobile World Congress e no Bosch Connected World em 2019, decidiu-se testar o aluguer de scooters com utilizadores reais, funcionários da Deutsche Telekom. Então começamos a desenvolver um MVP completo.
Blockchain de muletas
Não creio que valha a pena explicar qual é a diferença entre um projeto para ser exibido no palco e outro que será utilizado por pessoas reais. Em seis meses tivemos que transformar o protótipo rudimentar em algo adequado para um piloto. E então entendemos o que significa “dor”.
Para tornar nosso sistema descentralizado e aberto, decidimos usar contratos inteligentes Ethereum. A escolha recaiu sobre esta plataforma de serviços online descentralizados devido à sua popularidade e à capacidade de construir uma aplicação sem servidor. Planejamos implementar nosso projeto da seguinte maneira.
Mas, infelizmente, 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 completo. Por exemplo, um contrato inteligente não pode executar ações pendentes ou agendadas. Em nosso projeto, isso não nos permitiu implementar um serviço de aluguel por minuto, como fazem a maioria dos serviços modernos de compartilhamento de carros. Portanto, debitamos a criptomoeda do usuário após concluir a transação sem ter certeza de que ele tinha dinheiro suficiente. Esta abordagem só é aceitável para um piloto interno e, claro, acrescenta problemas ao conceber um projeto de produção completo.
Somado a tudo isso está a umidade da própria plataforma. Por exemplo, se você escrever um contrato inteligente com lógica diferente dos tokens ERC-20, encontrará problemas de tratamento de erros. Normalmente, se a entrada estiver incorreta ou nossos métodos não funcionarem corretamente, receberemos 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 realizar esta função. O gás é uma moeda que deve ser paga por transações e cálculos: quanto mais operações no seu código, mais você pagará. 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 um 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 na nuvem. Embora existam carteiras honestas, elas não fornecem interfaces para assinatura de transações externas. Isso significa que você não verá um aplicativo nativo, a menos que ele tenha uma carteira criptografada integrada, na qual os usuários confiarão pouco (eu não confiaria nela). Como resultado, também tivemos que cortar um atalho aqui. Os contratos inteligentes foram entregues à rede privada Ethereum e a carteira era baseada na nuvem. Mas, apesar disso, nossos usuários experimentaram todas as “delícias” dos serviços descentralizados na forma de longas esperas por transações, várias vezes por sessão de aluguel.
Tudo isso nos leva a essa arquitetura. Concordo, é muito diferente do que planejamos.
Ás na manga: Identidade Autossoberana
Não é possível construir um sistema completamente descentralizado sem identidade descentralizada. A Identidade Autossoberana (SSI) é responsável por esta parte, cuja essência é descartar o provedor de identidade centralizado (IDP) e distribuir todos os dados e responsabilidade por eles às pessoas. Agora o usuário decide quais dados precisa e com quem irá compartilhá-los. Todas essas informações estão localizadas no dispositivo do usuário. Mas para a troca precisaremos de um sistema descentralizado para armazenar evidências criptográficas. Todas as implementações modernas do conceito SSI usam blockchain como armazenamento.
“O que isso tem a ver com o ás na manga?” - você pergunta. Lançámos o serviço de testes internos aos nossos próprios funcionários em Berlim e Bona, e encontrámos dificuldades na forma de sindicatos alemães. Na Alemanha, as empresas estão proibidas de monitorizar os movimentos dos trabalhadores e os sindicatos controlam isso. Estas restrições acabam com o armazenamento centralizado dos dados de identidade dos utilizadores, pois neste caso saberíamos a localização dos funcionários. Ao mesmo tempo, não pudemos deixar de verificá-los devido à possibilidade de roubo de scooters. Mas graças à Identidade Autossoberana, nossos usuários usaram o sistema anonimamente e a própria scooter verificou sua carteira de motorista antes de iniciar o aluguel. Como resultado, armazenamos métricas de usuários anônimas; não tínhamos documentos ou dados pessoais: todos estavam contidos nos dispositivos dos próprios motoristas. Assim, graças à SSI, a solução para o problema do nosso projeto estava pronta antes mesmo de aparecer.
O dispositivo me deu problemas
Nós mesmos não implementamos a Identidade Autossoberana, pois isso requer experiência em criptografia e muito tempo. Em vez disso, aproveitamos o produto de nossos parceiros Jolocom e integramos sua carteira móvel e serviços em nossa plataforma. Infelizmente, este produto tem uma desvantagem significativa: a principal linguagem de desenvolvimento é Node.js.
Esta pilha de tecnologia limita muito a nossa escolha de hardware integrado numa scooter. Felizmente, logo no início do projeto escolhemos o Raspberry Pi Zero e aproveitamos todas as vantagens de um microcomputador completo. Isso nos permitiu executar Node.js volumosos na scooter. Além disso, recebemos monitoramento e acesso remoto via VPN por meio de ferramentas prontas.
Em conclusão
Apesar de todas as “dores” e problemas, o projeto foi lançado. Nem tudo funcionou como planejamos, mas foi realmente possível andar de scooter alugando-as.
Sim, cometemos uma série de erros ao projetar a arquitetura que não nos permitiram tornar o serviço totalmente descentralizado, mas mesmo sem esses erros dificilmente teríamos conseguido criar uma plataforma serverless. Uma coisa é escrever outra criptopirâmide e outra é escrever um serviço completo no qual você precisa lidar com erros, resolver casos limítrofes e executar tarefas pendentes. Esperemos que as novas plataformas que surgiram recentemente sejam mais flexíveis e funcionais.
Fonte: habr.com