Neste artigo, vou contar como tentamos construir um serviço de aluguel descentralizado de scooters usando contratos inteligentes e por que ainda precisamos de um serviço centralizado.
Como tudo começou
Em novembro de 2018, participamos de um hackathon focado em IoT e blockchain. Como ideia, nossa equipe escolheu o compartilhamento de scooters, pois tínhamos uma scooter do patrocinador do hackathon. O protótipo parecia um aplicativo móvel que permitia ativar a scooter via NFC. Do ponto de vista do marketing, a ideia era apoiada pelo discurso sobre um "futuro brilhante" com um ecossistema aberto, onde qualquer um pode ser locatário ou locador, tudo isso baseado em contratos inteligentes.
A ideia agradou muito nossos stakeholders, e eles decidiram transformá-la em um protótipo para demonstração em feiras. Após algumas demonstrações bem-sucedidas no Mobile World Congress e na Bosch Connected World em 2019, decidimos testar o aluguel de scooters com usuários reais, funcionários da Deutsche Telekom. Assim, começamos a desenvolver um MVP completo.
Blockchain com muletas
Acho que não é necessário explicar a diferença entre um projeto para apresentação no palco e um que será usado por pessoas reais. Em seis meses, precisávamos transformar um protótipo bruto em algo adequado para um piloto. E aqui 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 por causa de sua popularidade e pela possibilidade de construir um aplicativo sem servidor. Planejávamos implementar nosso projeto da seguinte forma.
Mas, infelizmente, o contrato inteligente é um código executado pela máquina virtual no momento da transação, e ele não pode substituir um completo. servidor. Por exemplo, um contrato inteligente não pode executar ações adiadas ou agendadas. Em nosso projeto, isso impossibilitou a implementação de um serviço de aluguel por minuto, como fazem a maioria dos serviços modernos de carsharing. Por isso, cobramos a criptomoeda do usuário após a conclusão da operação, sem a garantia de que ele possui saldo suficiente. Esse método é aceitável apenas para um piloto interno e, sem dúvida, traz problemas ao projetar um projeto completo para produção.
Ao que foi dito, soma-se a umidade da própria plataforma. Por exemplo, ao escrever um contrato inteligente com uma lógica diferente dos tokens ERC-20, você encontrará problemas de manejo de erros. Normalmente, com uma entrada incorreta ou mau funcionamento de nossos métodos, recebemos um código de erro em resposta. No caso do Ethereum, não conseguimos obter nada além da quantidade de gás gasta na execução dessa função. Gás é a moeda que precisa ser paga por transações e cálculos: quanto mais operações em seu código, mais você pagará. Portanto, para entender por que o código não funciona, você testa primeiro, simulando todos os possíveis erros, e codifica o gás gasto como o código de erro. Mas se você modificar seu código, esse manejo de erros quebrará.
Além disso, praticamente é impossível criar um aplicativo móvel que funcione com blockchain de forma justa, sem usar uma chave armazenada em algum lugar na nuvem. Embora carteiras justas existam, elas não oferecem interfaces para assinar transações externas. Isso significa que um aplicativo nativo não será viável, a menos que ele integre uma carteira cripto, na qual os usuários terão pouca confiança (eu não confiaria). Como resultado, também tivemos que cortar uma esquina aqui. Os contratos inteligentes eram entregues em uma rede privada do Ethereum, e a carteira era na nuvem. Mas, apesar disso, nossos usuários sentiram todos os “encantos” dos serviços descentralizados, com longas esperas por transações várias vezes durante a sessão de aluguel.
Tudo isso nos leva a essa arquitetura. Concorde que é bastante diferente do que planejamos.
Um trunfo na manga: Identidade Auto-Soberana
Não é possível construir um sistema completamente descentralizado sem uma identificação descentralizada. Esta parte é responsabilidade da Identidade Soberana (Self-Sovereign Identity - SSI), cuja essência é que você elimina o provedor de identidade centralizado (IDP) e entrega ao público todos os dados e a responsabilidade sobre eles. Agora, o usuário decide quais dados precisa e com quem irá compartilhá-los. Todas essas informações ficam no dispositivo do usuário. Mas para a troca, precisamos de um sistema descentralizado de armazenamento de provas criptográficas. Todas as implementações modernas do conceito de SSI usam blockchain como armazenamento.
“Qual é o trunfo?” — você deve estar se perguntando. Lançamos o serviço para um teste interno com nossos próprios funcionários em Berlim e Bonn, e enfrentamos dificuldades com os sindicatos alemães. Na Alemanha, as empresas são proibidas de monitorar os deslocamentos dos empregados, e os sindicatos controlam isso. Essas restrições inviabilizam o armazenamento centralizado de dados de identificação dos usuários, pois nesse caso saberíamos a localização dos funcionários. Ao mesmo tempo, não podíamos deixar de verificá-los devido ao risco de roubo de scooters. Mas graças à Identidade Soberana, nossos usuários puderam usar o sistema de forma anônima, e a scooter verificava a validade da carteira de motorista antes do início do aluguel. Como resultado, armazenamos métricas anonimizadas dos usuários, não possuíamos documentos ou dados pessoais: todos eles estavam contidos nos dispositivos dos próprios motoristas. Assim, graças ao SSI, a solução do problema no nosso projeto estava pronta antes mesmo de sua aparição.
O dispositivo trouxe problemas
Não implementamos a Identidade Soberana (SSI) de forma independente, pois isso requer expertise em criptografia e muito tempo. Em vez disso, utilizamos o produto de nossos parceiros, a Jolocom, e integramos sua carteira móvel e serviços em nossa plataforma. Infelizmente, esse produto tem uma desvantagem significativa: a principal linguagem de desenvolvimento é Node.js.
Esse stack tecnológico limita bastante nossa escolha de hardware integrado ao scooter. Felizmente, desde o início do projeto, optamos pelo Raspberry Pi Zero, e aproveitamos todas as vantagens de um microcomputador completo. Isso nos permitiu rodar o Node.js robusto no scooter. Além disso, conseguimos monitoramento e acesso remoto através de vpn, utilizando ferramentas prontas.
Para concluir
Apesar de toda a ‘dor’ e problemas, o projeto foi lançado. Nem tudo funcionou como planejado, mas realmente era possível andar de scooter, alugando-as.
Sim, cometemos uma série de erros no design da arquitetura que nos impediram de tornar o serviço completamente descentralizado, mas mesmo sem esses erros, seria difícil criarmos uma plataforma serverless. É uma coisa escrever mais uma pirâmide cripto e outra bem diferente — um serviço completo no qual é necessário lidar com erros, resolver casos limite e executar tarefas pendentes. Esperamos que as novas plataformas que surgiram recentemente sejam mais flexíveis e funcionais.
Fonte: habr.com
