분산형 스쿠터 대여를 위한 소프트웨어를 개발합니다. 누가 쉬울 거라고 했나요?

이 기사에서는 스마트 계약을 기반으로 분산형 스쿠터 대여를 구축하려고 시도한 방법과 여전히 중앙 집중형 서비스가 필요한 이유에 대해 설명합니다.

이 모든 시작하는 방법

2018년 XNUMX월, 우리는 사물인터넷과 블록체인을 주제로 한 해커톤에 참가했습니다. 우리 팀은 이번 해커톤의 스폰서로부터 스쿠터를 받았기 때문에 스쿠터 공유를 아이디어로 선택했습니다. 프로토타입은 NFC를 통해 스쿠터를 시동할 수 있는 모바일 애플리케이션처럼 보였습니다. 마케팅 관점에서 보면 누구나 스마트 계약을 기반으로 임차인이나 집주인이 될 수 있는 개방형 생태계를 갖춘 '밝은 미래'에 대한 이야기가 이 아이디어를 뒷받침했습니다.

우리 이해관계자들은 이 아이디어를 정말 좋아했고 이를 전시회에 전시할 프로토타입으로 만들기로 결정했습니다. 2019년 모바일 월드 콩그레스(Mobile World Congress)와 보쉬 커넥티드 월드(Bosch Connected World)에서 여러 차례 성공적인 시연을 한 후 실제 사용자인 Deutsche Telekom 직원을 대상으로 스쿠터 대여를 테스트하기로 결정했습니다. 그래서 우리는 본격적인 MVP를 개발하기 시작했습니다.

목발에 블록체인

무대에서 보여지는 프로젝트와 실제 사람들이 사용하게 될 프로젝트의 차이점은 설명할 가치가 없다고 생각합니다. XNUMX개월 만에 우리는 조잡한 프로토타입을 조종사에게 적합한 것으로 바꿔야 했습니다. 그리고 나서 우리는 "고통"이 무엇을 의미하는지 이해했습니다.

우리 시스템을 분산화하고 개방적으로 만들기 위해 우리는 이더리움 스마트 계약을 사용하기로 결정했습니다. 인기와 서버리스 애플리케이션 구축 능력으로 인해 이 분산형 온라인 서비스 플랫폼을 선택하게 되었습니다. 우리는 다음과 같이 프로젝트를 실행할 계획이었습니다.

하지만 안타깝게도 스마트 계약은 거래 시 가상 머신에 의해 실행되는 코드로, 본격적인 서버를 대체할 수는 없습니다. 예를 들어 스마트 계약은 보류 중이거나 예약된 작업을 수행할 수 없습니다. 우리 프로젝트에서는 대부분의 최신 자동차 공유 서비스처럼 분당 렌탈 서비스를 구현할 수 없었습니다. 따라서 우리는 사용자에게 충분한 돈이 있는지 확인하지 않고 거래를 완료한 후 사용자로부터 암호화폐를 인출했습니다. 이 접근 방식은 내부 파일럿에만 허용되며 물론 본격적인 생산 프로젝트를 설계할 때 문제가 추가됩니다.

위의 모든 사항에 플랫폼 자체의 습기가 추가되었습니다. 예를 들어 ERC-20 토큰과 다른 논리로 스마트 계약을 작성하면 오류 처리 문제가 발생합니다. 일반적으로 입력이 올바르지 않거나 메서드가 올바르게 작동하지 않으면 이에 대한 응답으로 오류 코드가 표시됩니다. 이더리움의 경우 이 기능을 수행하기 위해 소비된 가스량 외에는 아무것도 얻을 수 없습니다. 가스는 거래 및 계산을 위해 비용을 지불해야 하는 통화입니다. 코드에서 작업이 많을수록 더 많은 비용을 지불하게 됩니다. 따라서 코드가 작동하지 않는 이유를 이해하려면 먼저 가능한 모든 오류를 시뮬레이션하여 테스트하고 소비된 가스를 오류 코드로 하드코딩해야 합니다. 그러나 코드를 변경하면 이 오류 처리가 중단됩니다.

또한 클라우드 어딘가에 저장된 키를 사용하지 않고 블록체인과 정직하게 작동하는 모바일 애플리케이션을 만드는 것은 거의 불가능합니다. 정직한 지갑이 존재하더라도 외부 거래에 서명하기 위한 인터페이스를 제공하지 않습니다. 이는 사용자가 거의 신뢰하지 않는 암호화폐 지갑이 내장되어 있지 않으면 기본 애플리케이션을 볼 수 없다는 것을 의미합니다(나는 그것을 신뢰하지 않습니다). 결과적으로 우리는 여기서도 코너를 잘라야 했습니다. 스마트 계약은 프라이빗 이더리움 네트워크에 전달되었으며 지갑은 클라우드 기반이었습니다. 그러나 그럼에도 불구하고 우리 사용자들은 임대 세션당 여러 번 거래를 오랫동안 기다리는 형태로 분산형 서비스의 모든 "즐거움"을 경험했습니다.

이 모든 것이 우리를 이 아키텍처로 이끈다. 동의합니다. 우리가 계획한 것과는 매우 다릅니다.

구멍 속의 에이스: 자주권 신원

분산화된 신원 없이는 완전히 분산된 시스템을 구축할 수 없습니다. SSI(Self-Sovereign Identity)가 이 부분을 담당하는데, 그 핵심은 중앙 집중식 IDP(IDP)를 버리고 이에 대한 모든 데이터와 책임을 국민에게 분배한다는 것입니다. 이제 사용자는 자신에게 필요한 데이터와 이를 누구와 공유할지 결정합니다. 이 모든 정보는 사용자의 장치에 있습니다. 그러나 교환을 위해서는 암호화 증거를 저장하기 위한 분산형 시스템이 필요합니다. SSI 개념의 모든 최신 구현은 블록체인을 저장소로 사용합니다.

“이게 구멍 속의 에이스와 무슨 관련이 있는 걸까요?” - 물어. 우리는 베를린과 본에 있는 우리 직원들을 대상으로 내부 테스트 서비스를 시작했고, 독일 노동조합의 형태로 어려움을 겪었습니다. 독일에서는 기업이 직원의 동선을 모니터링하는 것이 금지되어 있으며 노동조합이 이를 통제합니다. 이러한 제한으로 인해 사용자 신원 데이터의 중앙 집중식 저장이 중단됩니다. 이 경우 직원의 위치를 ​​알 수 있기 때문입니다. 동시에, 스쿠터가 도난당할 가능성이 있기 때문에 확인을 하지 않을 수 없었습니다. 하지만 자기 주권 신원(Self-Sovereign Identity) 덕분에 우리 사용자들은 시스템을 익명으로 사용했고, 스쿠터 자체가 렌트를 시작하기 전에 운전 면허증을 확인했습니다. 결과적으로 우리는 익명의 사용자 지표를 저장했으며 문서나 개인 데이터는 없었으며 모두 운전자의 장치에 포함되어 있었습니다. 따라서 SSI 덕분에 우리 프로젝트의 문제에 대한 해결책은 문제가 나타나기도 전에 준비되었습니다.

장치에서 문제가 발생했습니다.

자기주권신원(Self-Sovereign Identity)은 암호화에 대한 전문 지식과 많은 시간이 필요하기 때문에 자체적으로 구현하지 않았습니다. 대신, 우리는 파트너인 Jolocom의 제품을 활용하고 그들의 모바일 지갑과 서비스를 우리 플랫폼에 통합했습니다. 불행하게도 이 제품에는 한 가지 중요한 단점이 있습니다. 주요 개발 언어가 Node.js라는 것입니다.

이 기술 스택은 스쿠터에 내장된 하드웨어 선택을 크게 제한합니다. 다행스럽게도 우리는 프로젝트 초기에 Raspberry Pi Zero를 선택했고, 본격적인 마이크로컴퓨터의 모든 장점을 활용했습니다. 이를 통해 스쿠터에서 부피가 큰 Node.js를 실행할 수 있었습니다. 또한 기성 도구를 사용하여 VPN을 통해 모니터링 및 원격 액세스를 받았습니다.

결론적으로

모든 “고통”과 문제에도 불구하고 프로젝트는 시작되었습니다. 모든 것이 계획대로 되지는 않았지만 스쿠터를 빌려 타는 것은 정말 가능했습니다.

예, 우리는 서비스를 완전히 분산화할 수 없는 아키텍처를 설계할 때 많은 실수를 저질렀습니다. 그러나 이러한 실수가 없었다고 해도 서버리스 플랫폼을 만드는 것은 거의 불가능했을 것입니다. 또 다른 암호화 피라미드를 작성하는 것과 오류를 처리하고 경계선 문제를 해결하며 보류 중인 작업을 수행하는 데 필요한 본격적인 서비스를 작성하는 것은 또 다른 일입니다. 최근 등장한 새로운 플랫폼이 더욱 유연하고 기능적이기를 바랍니다.

출처 : habr.com