Pada artikel ini saya akan berbicara tentang bagaimana kami mencoba membangun persewaan skuter terdesentralisasi pada kontrak pintar dan mengapa kami masih membutuhkan layanan terpusat.
Bagaimana semuanya dimulai
Pada bulan November 2018, kami mengambil bagian dalam hackathon yang didedikasikan untuk Internet of Things dan blockchain. Tim kami memilih ide berbagi skuter karena kami mendapat skuter dari sponsor hackathon ini. Prototipenya tampak seperti aplikasi seluler yang memungkinkan Anda menyalakan skuter melalui NFC. Dari sudut pandang pemasaran, ide ini didukung oleh cerita tentang “masa depan cerah” dengan ekosistem terbuka di mana siapa pun bisa menjadi penyewa atau tuan tanah, semuanya berdasarkan kontrak pintar.
Pemangku kepentingan kami sangat menyukai ide ini, dan mereka memutuskan untuk mengubahnya menjadi prototipe untuk dipamerkan di pameran. Setelah beberapa demonstrasi sukses di Mobile World Congress dan Bosch Connected World pada tahun 2019, diputuskan untuk menguji persewaan skuter dengan pengguna sebenarnya, karyawan Deutsche Telekom. Jadi kami mulai mengembangkan MVP yang lengkap.
Blockchain pada kruk
Saya rasa tidak ada gunanya menjelaskan perbedaan antara proyek yang akan ditampilkan di panggung dan proyek yang akan digunakan oleh orang sungguhan. Dalam enam bulan kami harus mengubah prototipe kasar menjadi sesuatu yang cocok untuk uji coba. Dan kemudian kita memahami apa arti “rasa sakit”.
Untuk membuat sistem kami terdesentralisasi dan terbuka, kami memutuskan untuk menggunakan kontrak pintar Ethereum. Pilihan jatuh pada platform layanan online terdesentralisasi ini karena popularitasnya dan kemampuan untuk membangun aplikasi tanpa server. Kami berencana untuk mengimplementasikan proyek kami sebagai berikut.
Namun sayangnya, kontrak pintar adalah kode yang dieksekusi oleh mesin virtual pada saat transaksi, dan tidak dapat menggantikan server lengkap. Misalnya, kontrak pintar tidak dapat melakukan tindakan yang tertunda atau terjadwal. Dalam proyek kami, hal ini tidak memungkinkan kami menerapkan layanan sewa per menit, seperti yang dilakukan sebagian besar layanan berbagi mobil modern. Oleh karena itu, kami mendebit mata uang kripto dari pengguna setelah menyelesaikan transaksi tanpa yakin bahwa dia memiliki cukup uang. Pendekatan ini hanya dapat diterima untuk uji coba internal dan, tentu saja, menambah masalah saat merancang proyek produksi penuh.
Ditambah dengan semua hal di atas adalah kelembapan platform itu sendiri. Misalnya, jika Anda menulis kontrak pintar dengan logika yang berbeda dari token ERC-20, Anda akan mengalami masalah penanganan kesalahan. Biasanya, jika masukan salah atau metode kami tidak berfungsi dengan benar, kami menerima kode kesalahan sebagai tanggapan. Dalam kasus Ethereum, kita tidak bisa mendapatkan apa pun selain jumlah bahan bakar yang dikeluarkan untuk menjalankan fungsi ini. Gas adalah mata uang yang harus dibayar untuk transaksi dan penghitungan: semakin banyak operasi dalam kode Anda, semakin banyak Anda akan membayar. Jadi untuk memahami mengapa kode tersebut tidak berfungsi, Anda terlebih dahulu mengujinya dengan mensimulasikan semua kemungkinan kesalahan dan melakukan hardcode pada gas yang dikeluarkan sebagai kode kesalahan. Namun jika Anda mengubah kode, penanganan kesalahan ini akan rusak.
Selain itu, hampir tidak mungkin untuk membuat aplikasi seluler yang bekerja dengan blockchain secara jujur, tanpa menggunakan kunci yang disimpan di suatu tempat di cloud. Meskipun dompet yang jujur ada, mereka tidak menyediakan antarmuka untuk menandatangani transaksi eksternal. Artinya, Anda tidak akan melihat aplikasi asli kecuali aplikasi tersebut memiliki dompet kripto bawaan, yang tidak begitu dipercaya oleh pengguna (saya tidak akan mempercayainya). Akibatnya, kami juga harus mengambil jalan pintas di sini. Kontrak pintar dikirimkan ke jaringan Ethereum pribadi, dan dompetnya berbasis cloud. Namun meskipun demikian, pengguna kami merasakan semua “kenikmatan” layanan terdesentralisasi dalam bentuk menunggu lama untuk transaksi beberapa kali per sesi sewa.
Semua ini membawa kita pada arsitektur ini. Setuju, ini sangat berbeda dari yang kami rencanakan.
Ace in the hole: Identitas Kedaulatan Diri
Anda tidak dapat membangun sistem yang sepenuhnya terdesentralisasi tanpa identitas yang terdesentralisasi. Self-Sovereign Identity (SSI) bertanggung jawab untuk bagian ini, yang intinya adalah Anda membuang penyedia identitas terpusat (IDP) dan mendistribusikan semua data dan tanggung jawabnya kepada masyarakat. Sekarang pengguna memutuskan data apa yang dia butuhkan dan dengan siapa dia akan membagikannya. Semua informasi ini terletak di perangkat pengguna. Namun untuk pertukarannya kita memerlukan sistem terdesentralisasi untuk menyimpan bukti kriptografi. Semua implementasi modern dari konsep SSI menggunakan blockchain sebagai penyimpanan.
“Apa hubungannya ini dengan kartu as di dalam lubang?” - Anda bertanya. Kami meluncurkan layanan pengujian internal terhadap karyawan kami sendiri di Berlin dan Bonn, dan kami menemui kesulitan dalam bentuk serikat pekerja Jerman. Di Jerman, perusahaan dilarang memantau pergerakan karyawan, dan serikat pekerja mengontrol hal ini. Pembatasan ini mengakhiri penyimpanan data identitas pengguna yang terpusat, karena dalam hal ini kita akan mengetahui lokasi karyawan. Pada saat yang sama, kami mau tidak mau memeriksanya karena kemungkinan skuter dicuri. Namun berkat Self-Sovereign Identity, pengguna kami menggunakan sistem secara anonim, dan skuter itu sendiri memeriksa SIM mereka sebelum mulai menyewa. Hasilnya, kami menyimpan metrik pengguna secara anonim; kami tidak memiliki dokumen atau data pribadi apa pun: semuanya terdapat di perangkat pengemudi itu sendiri. Oleh karena itu, berkat SSI, solusi terhadap masalah dalam proyek kami telah siap bahkan sebelum masalah tersebut muncul.
Perangkat itu memberi saya masalah
Kami tidak menerapkan Self-Sovereign Identity sendiri, karena memerlukan keahlian dalam kriptografi dan banyak waktu. Sebaliknya, kami memanfaatkan produk mitra kami Jolocom dan mengintegrasikan dompet seluler dan layanan mereka ke dalam platform kami. Sayangnya, produk ini memiliki satu kelemahan signifikan: bahasa pengembangan utamanya adalah Node.js.
Tumpukan teknologi ini sangat membatasi pilihan perangkat keras yang terpasang pada skuter. Untungnya, di awal proyek, kami memilih Raspberry Pi Zero, dan kami memanfaatkan semua keunggulan komputer mikro yang lengkap. Hal ini memungkinkan kami menjalankan Node.js yang besar di skuter. Selain itu, kami menerima pemantauan dan akses jarak jauh melalui VPN menggunakan alat yang sudah jadi.
Sebagai kesimpulan
Terlepas dari semua “rasa sakit” dan masalah, proyek ini diluncurkan. Tidak semuanya berjalan sesuai rencana, namun mengendarai skuter sangat mungkin dilakukan dengan menyewanya.
Ya, kami membuat sejumlah kesalahan saat merancang arsitektur yang tidak memungkinkan kami membuat layanan sepenuhnya terdesentralisasi, namun tanpa kesalahan ini kami tidak akan mampu menciptakan platform tanpa server. Menulis piramida kripto lain adalah satu hal, dan menulis layanan lengkap di mana Anda perlu menangani kesalahan, menyelesaikan kasus-kasus batas, dan melakukan tugas-tugas yang tertunda adalah satu hal. Semoga platform baru yang muncul belakangan ini lebih fleksibel dan fungsional.
Sumber: www.habr.com