この記事では、スマート コントラクトに基づいて分散型スクーター レンタルを構築しようとした方法と、それでも集中型サービスが必要な理由について説明します。
それはすべてどのように始まったのか
2018 年 XNUMX 月、私たちはモノのインターネットとブロックチェーンに特化したハッカソンに参加しました。 私たちのチームは、このハッカソンのスポンサーからスクーターをもらったので、アイデアとしてスクーターシェアリングを選択しました。 プロトタイプは、NFC 経由でスクーターを始動できるモバイル アプリケーションのように見えました。 マーケティングの観点から見ると、このアイデアは、スマート コントラクトに基づいて誰もがテナントまたは家主になれるオープン エコシステムを備えた「明るい未来」に関するストーリーによって裏付けられました。
私たちの関係者はこのアイデアを非常に気に入ってくれたので、展示会で展示するためにプロトタイプにすることにしました。 2019 年のモバイル ワールド コングレスとボッシュ コネクテッド ワールドでのいくつかのデモンストレーションが成功した後、実際のユーザーであるドイツテレコムの従業員を対象にスクーターのレンタルをテストすることが決定されました。 そこで私たちは本格的な MVP の開発を開始しました。
松葉杖上のブロックチェーン
ステージ上で披露されるプロジェクトと実際の人々が使用するプロジェクトとの違いは説明するまでもないと思います。 XNUMX か月かけて、粗製のプロトタイプをパイロットに適したものに変える必要がありました。 そして私たちは「痛み」が何を意味するのかを理解しました。
システムを分散化してオープンにするために、私たちはイーサリアム スマート コントラクトを使用することにしました。 その人気とサーバーレス アプリケーションを構築できる能力により、分散型オンライン サービスのこのプラットフォームが選択されました。 私たちは次のようにプロジェクトを実行することを計画しました。
しかし、残念ながら、スマート コントラクトはトランザクション時に仮想マシンによって実行されるコードであり、本格的なサーバーを置き換えることはできません。 たとえば、スマート コントラクトは保留中のアクションやスケジュールされたアクションを実行できません。 私たちのプロジェクトでは、このため、最新のカーシェアリング サービスのほとんどのように、分単位のレンタル サービスを実装することはできませんでした。 したがって、ユーザーが十分な資金を持っているかどうかを確認せずに、取引を完了した後、ユーザーから暗号通貨を引き落としました。 このアプローチは内部パイロットでのみ許容され、当然ながら、本格的な運用プロジェクトを設計する場合には問題が発生します。
上記のすべてに加えて、プラットフォーム自体の湿気も加わります。 たとえば、ERC-20 トークンとは異なるロジックでスマート コントラクトを作成すると、エラー処理の問題が発生します。 通常、入力が正しくない場合、またはメソッドが正しく機能しない場合は、応答としてエラー コードを受け取ります。 イーサリアムの場合、この機能を実行するために費やされたガスの量以外に何も得ることはできません。 Gas はトランザクションと計算のために支払わなければならない通貨です。コード内の操作が増えるほど、支払う金額も高くなります。 したがって、コードが機能しない理由を理解するには、まず考えられるすべてのエラーをシミュレートしてテストし、消費されたガスをエラー コードとしてハードコードします。 ただし、コードを変更すると、このエラー処理は機能しなくなります。
さらに、クラウドのどこかに保存されているキーを使用せずに、ブロックチェーンで正確に動作するモバイル アプリケーションを作成することはほぼ不可能です。 正直なウォレットは存在しますが、外部トランザクションに署名するためのインターフェイスを提供しません。 これは、暗号通貨ウォレットが組み込まれていない限り、ネイティブ アプリケーションは表示されないことを意味しており、ユーザーはそれをほとんど信頼していません (私は信用しません)。 結果として、ここでも手を抜く必要がありました。 スマート コントラクトはプライベート イーサリアム ネットワークに配信され、ウォレットはクラウドベースでした。 しかし、それにもかかわらず、ユーザーは、レンタル セッションごとに数回、トランザクションの長い待ち時間という形で分散型サービスのすべての「喜び」を経験しました。
これらすべてが私たちをこのアーキテクチャに導きます。 同意します、それは私たちが計画したものとは大きく異なります。
エース・イン・ザ・ホール: 自己主権的アイデンティティ
分散型アイデンティティがなければ、完全に分散型システムを構築することはできません。 セルフソブリン アイデンティティ (SSI) がこの部分を担当します。その本質は、集中型アイデンティティ プロバイダー (IDP) を放棄し、すべてのデータとその責任を人々に配布することです。 ユーザーは、どのデータが必要か、そしてそれを誰と共有するかを決定します。 これらの情報はすべてユーザーのデバイス上にあります。 しかし、交換のためには、暗号証拠を保存するための分散システムが必要になります。 SSI コンセプトの最新の実装はすべて、ブロックチェーンをストレージとして使用します。
「これとホールのエースと何の関係があるの？」 - あなたが尋ねる。 私たちはベルリンとボンで自社の従業員を対象とした内部テストのサービスを開始しましたが、ドイツの労働組合という形で困難に直面しました。 ドイツでは企業が従業員の移動を監視することは禁止されており、労働組合がこれを管理している。 これらの制限により、ユーザー ID データの集中保管は廃止されます。この場合、従業員の所在地が分かることになるからです。 同時に、スクーターが盗難される可能性も考えて、チェックせずにはいられませんでした。 しかし、Self-Sovereign Identity のおかげで、ユーザーは匿名でシステムを使用し、レンタルを開始する前にスクーター自体が運転免許証を確認しました。 その結果、私たちは匿名のユーザー指標を保存しました。文書や個人データは一切なく、それらはすべてドライバー自身のデバイスに含まれていました。 このように、SSI のおかげで、私たちのプロジェクトの問題に対する解決策は、それが現れる前から用意されていました。
デバイスで問題が発生しました
Self-Sovereign Identity は暗号化の専門知識と多くの時間が必要となるため、私たち自身では実装しませんでした。 代わりに、私たちはパートナーである Jolocom の製品を利用し、彼らのモバイル ウォレットとサービスを私たちのプラットフォームに統合しました。 残念ながら、この製品には重大な欠点が XNUMX つあります。それは、主な開発言語が Node.js であるということです。
この技術スタックにより、スクーターに組み込まれるハードウェアの選択が大幅に制限されます。 幸いなことに、プロジェクトの最初の段階で、私たちは Raspberry Pi Zero を選択し、本格的なマイクロコンピューターの利点をすべて活用することができました。 これにより、スクーター上でかさばる Node.js を実行できるようになりました。 さらに、既製のツールを使用した VPN 経由の監視とリモート アクセスも受けました。
結論
あらゆる「痛み」と問題にもかかわらず、プロジェクトは立ち上げられました。 すべてが計画通りに進んだわけではありませんが、スクーターをレンタルすることで実際に乗ることができました。
はい、アーキテクチャの設計時に多くの間違いを犯し、サービスを完全に分散化することができませんでしたが、これらの間違いがなかったとしても、サーバーレス プラットフォームを作成することはほとんどできなかったでしょう。 別の暗号ピラミッドを作成することと、エラーを処理し、境界線のケースを解決し、保留中のタスクを実行する必要がある本格的なサービスを作成することはまったく別のことです。 最近登場した新しいプラットフォームがより柔軟で機能的になることを期待しましょう。
出所： habr.com