10 Juni adalah hari ketiga aklimatisasi kami di Hong Kong. Dan 26 jam terakhir yang kami habiskan hampir tanpa tidur, mengembangkan proyek prototipe dengan nama kerja SensorPay pada tahap pertama hackathon EOS Global dengan total hadiah uang satu setengah juta dolar. Momen demonstrasi proyek di depan para hakim semakin dekat.

Jika Anda ingin mengetahui bagaimana kisah ini berakhir, lihat bagian terakhir segera. Sementara itu, kami akan mulai berbicara secara sistematis tentang teknologi EOS dan bagaimana kami sampai pada gagasan menautkan pembayaran untuk IoT ke EOS. Segera setelah itu akan ada deskripsi rinci tentang isian teknis proyek.

0. Latar Belakang

EOS adalah blockchain generasi baru, beberapa bahkan menganggapnya sebagai pembunuh Ethereum. Jika tiba-tiba Anda tidak tahu apa itu blockchain atau Ethereum, Google akan membantu. Dan kami, itu terjadi, mulai menggali EOS sekitar setahun yang lalu, termasuk dengan mempelajari produk sebelumnya dari penulisnya BitShares dan Steem.

Keuntungan EOS dibandingkan dengan Ethereum: throughput transaksi adalah tiga urutan lebih tinggi; mengembangkan sistem izin untuk kontrak pintar; kemampuan untuk mengembalikan akses yang hilang dan memperbaiki kesalahan dalam blockchain; manajemen jaringan onchain. Kelemahan: kekhawatiran sentralisasi, konsensus DPoS yang berpotensi lebih rentan, kode mentah, dan kurva pembelajaran yang lebih curam untuk pengembang.

Karena kami telah menyukai teknologi ini sejak lama dan menganggapnya menjanjikan, kami tidak dapat mengabaikan rangkaian hackathon, yang didukung oleh penulis EOS. Kami hanya ingin berada di sana, mewujudkan ide-ide kami di lingkungan yang menginspirasi ini dan membaginya dengan khalayak luas. Tentu saja, kesempatan untuk memenangkan uang yang baik juga menjadi motivator tambahan yang menyenangkan.

Jadi, EOS adalah satu-satunya solusi yang berfungsi untuk blockchain publik yang kami tahu di mana Anda dapat melakukan banyak transaksi. Di mana itu dibutuhkan? Tentu saja dalam IoT! Memang, jika setiap pemanggang menjadi pembayaran mikro, ia akan membayar setiap potong roti ke lemari es (dan ini asik secara default, seperti yang Anda mengerti), akan ada banyak transaksi. Belum lagi segala macam aplikasi lain dalam bidang kedokteran, industri dan kehidupan sehari-hari.

Beberapa minggu sebelum hackathon, ide-ide alternatif muncul secara berkala, dan brainstorm kecil diadakan. Kami membandingkan ide berdasarkan kriteria wasit terkenal: penggunaan kemampuan EOS, kreativitas, dampak publik, dan skalabilitas. Hasilnya, kami memilih IoT + EOS - solusi yang akan mengambil data dari sensor dan mengirim banyak transaksi pembayaran ke EOS.

Ngomong-ngomong, kami benar-benar ingin memberi tahu di sini juga tentang bagaimana kami meningkatkan Block Producer kami untuk EOS; bagaimana mereka berencana untuk membilasnya untuk konstruktor token ERC721 dan dukungan untuk fungsi konstan; bagaimana mereka mengajukan protokol ACL Merkle Root. Tetapi semua ini tidak sesuai dengan artikel, jadi kami akan kembali ke proyek utama kami.

1. Persiapan

1.1. IoT

Mempersiapkan bagian IoT dari proyek ini adalah memilih perangkat keras yang tepat. Dalam peran pembaca RFID, RC522 yang beroperasi pada bus SPI dipilih: populer dan mudah digunakan.

Saat mencari penghitung, kami fokus pada keberadaan output pulsa, karena memungkinkan Anda untuk membaca data dengan sangat sederhana: satu pulsa adalah X kW⋅h (di mana X bergantung pada model), sebagai hasilnya, kami berhenti di konter Mercury 201.5.

Hal yang paling sulit adalah memutuskan controller, yang harus mengumpulkan data dari sensor, membentuk transaksi, menandatanganinya dengan kunci pribadi Anda dan mengirimkannya ke jaringan. Karenanya, kami membutuhkan perangkat dengan modul jaringan yang dapat menandatangani transaksi menggunakan ECDSA (dalam kasus ini, pada kurva eliptik secp256k1, karena digunakan dalam EOS untuk penandatanganan).

Awalnya, pilihan ada pada mikrokontroler ESP8266, ia memiliki modul Wi-Fi dan semua antarmuka yang diperlukan untuk menghubungkan sensor kami. Pada saat yang sama, sangat ringkas. Tetapi tidak satupun dari firmware memiliki implementasi asli dari primitif eliptik. Dimungkinkan untuk menulis implementasi Anda sendiri, tetapi ini bukan tugas untuk hackathon. Akibatnya, Raspberry Pi 3 B dipilih untuk prototipe, dan perpustakaan eosjs digunakan untuk menghasilkan dan menandatangani transaksi.

1.2. Infrastruktur

Beberapa hari sebelum hackathon, kami menyiapkan secara lokal dan pada server eos-hackathon.smartz.io sebuah perakitan EOS ( sumber ). Instalasi, perakitan, dan tes ketergantungan berjalan sangat lancar untuk proyek yang masih muda (menggunakan dokumentasi ). Tidak ada cukup waktu untuk persiapan infrastruktur lainnya, dan saya harus menghadapinya selama hackathon.

1.3. Arsitektur

Menjelang hackathon, kami membahas arsitektur dan menjelaskan detail produk. Kami akan menerapkan kasus-kasus utama berikut: pembayaran untuk listrik dan pembayaran untuk pembelian yang ditandai dengan tag RFID. Mereka juga berencana untuk membuat produk mudah diperluas dan menggunakannya di daerah lain.

Gagasan arsitektur adalah bahwa penyedia layanan (Produser) menciptakan satu kontrak - titik interaksi utama antara pemasok dan konsumen. Setiap konsumen memiliki saldo sendiri, yang dapat diisi ulang, dana didebit darinya berdasarkan sinyal sensor. Semua data - pengguna, sensor, statistik - disimpan dalam kontrak pemasok.

Preferensi pengguna dikaitkan dengan konsumen, atau bendera (misalnya, kategori pengguna preferensial) - user_meta . Beberapa sensor dapat dihubungkan dengan konsumen, untuk masing-masing dari mereka pengaturan kontrak dan penagihan ( billing_meta ) ditunjukkan. Jadi, Anda bisa mendapatkan kontrak penagihan stateless yang tidak dapat diubah, yang digunakan untuk sejumlah besar konsumen; data yang diperlukan akan muncul selama doa metode bill(payload, user_meta, billing_meta) . Juga, kemungkinan logika penagihan yang berbeda, yaitu, kontrak yang berbeda, diletakkan: misalnya, satu menganggap listrik, yang lain - barang. Setiap sensor memiliki "penunjuk" untuk kontrak penagihannya.

Diasumsikan bahwa konsumen mempercayai produsen sensor, tetapi tidak harus percaya pada penyedia layanan. Antarmuka interaksi dengan sensor sangat sederhana: ini adalah panggilan ke metode kontrak pemasok dengan parameter numerik, yang akan ditransfer ke penagihan. Penyedia layanan memulai konsumen, sensor, kontrak penagihan dan hubungan mereka dalam kontrak mereka, menggunakan kontrol transaksi - setter primitif. Ketika transaksi diterima dari sensor, data diperiksa, data untuk penagihan dihasilkan, penagihan disebut, pembayaran dicatat dan statistik dicatat.

Mungkin sebagian besar dari semua yang kita bahas masalah berikut ini yang penting untuk penerapan produk di dunia nyata:

• Uang muka atau pascabayar? Isi ulang akun Anda dan gunakan (seperti koneksi seluler) - atau gunakan, lalu bayar (seperti AWS)? Tidak ada jawaban benar atau salah di sini: bisnis yang berbeda lebih suka model yang berbeda. Untuk mempermudah, kami memutuskan untuk mengambil pembayaran di muka.
• Haruskah pengguna menyimpan akun terpisah untuk setiap pemasok, atau apakah semua biaya berasal dari satu akun? Lagi - tidak ada keputusan benar dan salah; selain itu, jawabannya terkait erat dengan jawaban pertanyaan sebelumnya. Pembayaran di muka adalah teman baik dengan akun konsumen individu - mereka diambil.
• Mengisi biaya dalam EOS, tanda penyedia layanan atau koin stabil (terkait dengan mata uang fiat)? Opsi selain koin stabil, tentu saja, tidak nyaman bagi konsumen karena volatilitas, dan koin stabil dalam kerangka EOS belum ada. Pada saat itu, bahkan jaringan EOS utama tidak ada di sana! Untuk kesederhanaan, mereka mengambil tanda kondisional.

2. Pengodean

Pertama-tama, mereka menentukan API dan kerangka kontrak pemasok untuk secara bersamaan memulai pengembangan frontend, kode perangkat, penagihan, dan kontrak utama ( sumber ).

2.1. IoT

Yang pertama menerapkan kode untuk membaca pulsa dari penghitung. Untuk bekerja dengan GPIO (pin tujuan umum), pustaka JS onoff digunakan. Kemudian, dua LED ditambahkan ke sirkuit untuk kejelasan: yang pertama berkedip ketika sinyal diterima dari konter, dan yang kedua ketika jawaban tentang transaksi yang berhasil datang dari node EOS. Demikian pula, kami mengembangkan skema dan kode untuk membaca tag RFID, dengan satu-satunya perbedaan: membaca terjadi pada bus SPI menggunakan perpustakaan MFRC522-python. Ternyata, pengaturan SPI untuk Raspberry Pi 3 berbeda dari pengaturan pada model board sebelumnya; Instruksi ini membantu kami untuk mengerti.

Perangkat ini didukung oleh bank daya, yang berhasil disajikan kepada semua peserta hackathon, dan mereka harus berbagi Internet sendiri dengan iPhone 5, karena Wi-Fi hackathon bekerja secara eksklusif pada 5 GHz, ini tidak bekerja untuk Raspberry Pi.

2.2. Infrastruktur dan Utilitas

Panitia menyarankan untuk mengambil gambar buruh pelabuhan dari eos-dev , tetapi kami bingung dengan kurangnya deskripsi dan dokumentasi dari gambar tersebut. Di server, mereka terus bekerja dengan perakitan yang disiapkan, dan secara lokal, untuk menghindari menginstal EOS secara sistematis, mereka menggunakan eos-dev.

Segera dibutuhkan kemampuan untuk membangun dan menguji dengan cepat. Ideal: buat dan jalankan file yang dapat dieksekusi secara lokal. Namun, tidak mungkin untuk mengabaikan fakta bahwa setelah perakitan, output membutuhkan WebAssembly dan, dalam lingkungan EOS, dengan dorongan yang sesuai, perpustakaan, kontrak sistem. Opsi kompilasi yang diperlukan dapat dimata-matai di eosiocpp.in , namun, kami memutuskan untuk tidak memainkan game ini. Hasil yang diprediksi, meskipun sedikit lebih lambat, lebih penting daripada solusi cepat dengan penggaruk potensial. Oleh karena itu, untuk perakitan kami mengambil eoscpp, yang ada di wadah eos-dev.

Ternyata menjadi lebih sulit dengan peluncuran, saya harus meningkatkan blockchain EOS lokal, dan sekali lagi tidak ada solusi siap pakai. Hanya perangkat lunak. Jadi versi pertama dari infrastruktur peluncuran muncul. Idenya adalah untuk menyembunyikan nuansa pemasangan dan konfigurasi dan mendapatkan seperangkat "tombol" yang konsisten sendiri untuk tindakan khusus. Kurang kontrol, tetapi lebih sedikit kemungkinan kesalahan, ditambah penghematan waktu.

Komponen utama EOS termasuk nodeos, keosd daemon, utilitas konsol cleos, dan kompiler eoscpp:

• nodeos - EOS node, daemon - peserta jaringan, menyediakan akses ke blockchain dan secara opsional menghasilkan blok baru;
• keosd - sebuah daemon untuk mengelola dompet lokal yang menyimpan pasangan kunci;
• cleos menyediakan perintah mulai dari memperoleh informasi tentang transaksi hingga bekerja dengan kunci, itu diimplementasikan berdasarkan panggilan dalam nodeos dan keosd melalui API HTTP;
• eoscpp mengkompilasi kontrak ke dalam WebAssembly, dan juga memungkinkan Anda untuk mendapatkan Application Binary Interface berdasarkan kode sumber.

Segera menjadi jelas bahwa perintah cleos terkait dengan panggilan keosd tidak berfungsi. Karena kesalahan dikeluarkan yang menunjukkan tidak dapat diaksesnya jaringan keosd, kami menghabiskan waktu untuk mendiagnosis masalah jaringan di jaringan buruh pelabuhan. Namun, strace menunjukkan bahwa itu bukan jaringan: cleos mengakses alamat yang salah, selalu ke localhost (dan dalam hal infrastruktur kami, daemon yang berbeda memiliki alamat jaringan yang berbeda dalam jaringan buruh pelabuhan yang terpisah). Bug didiagnosis dalam cleos: memeriksa ketersediaan keosd, yang dilakukan sebelum perintah apa pun yang terkait dengan dompet, memperhitungkan port yang diteruskan dalam argumen, tetapi tidak memperhitungkan alamat. Di bawah hackathon, kami beralih ke jaringan host di buruh pelabuhan sebagai solusi.

Langkah selanjutnya adalah utilitas kompilasi kontrak menggunakan kompiler dalam wadah ( komit ). Direktori input dan output sudah terpasang. Dan akhirnya, kemampuan untuk mengunggah kontrak ke blockchain dan mengirim transaksi ( komit ). Lagi - utilitas dalam gaya yang konsisten, "tombol" sederhana. Ini mengakhiri infrastruktur dasar, tetapi kejutan terus berlanjut: kami menemukan masalah fungsi-C untuk bekerja dengan memori (lebih terinci di bawah).

Sebagai kesimpulan, mereka mulai mengatur akun dalam satu file (setiap kontrak dan peserta membutuhkan akun terpisah) tepat bersama dengan pasangan kunci yang dibuat secara otomatis ketika blockchain dimulai, sehingga satu tim dapat meningkatkan lingkungan pengujian. Satu salinan dari lingkungan ini digunakan untuk eos-hackathon.smartz.io.

2.3. Kontrak yang cerdas

2.3.1. Kontrak pemasok dan tagihan listrik

Setelah dimulainya hackathon, kami mulai menyusun struktur kontrak sesuai dengan skema di atas. Sistem terdiri dari kontrak-kontrak berikut:

• supplier - kontrak supplier ;
• billing_electricity - kontrak untuk menghitung pembayaran listrik untuk setiap centang meter.

Dalam kontrak supplier , sebagian besar pekerjaan dilakukan oleh operasi CRUD biasa: menambah pengguna, tarif, penghitung, menambah atau mengurangi saldo pengguna. Metode yang lebih kompleks bertanggung jawab untuk menerima data dari meteran, memanggil kontrak untuk menghitung pembayaran (penagihan), mendebit akun pribadi pengguna setelah panggilan balik dari kontrak penagihan. Kontrak penagihan yang diperlukan ditentukan berdasarkan tarif pengguna.

Setelah panggilan dalam kontrak untuk penagihan, pembayaran dihitung dan metode dipanggil untuk mendebit pembayaran dari akun pribadi pengguna. Setelah melempar logika utama, kami bahkan berpikir jika kami melakukan kontrak yang terlalu sederhana. Beberapa saat kemudian, setelah penyebaran kontrak di simpul dan pengujiannya, menjadi jelas bahwa kontrak mungkin sederhana, tetapi ada nuansa. :)

Setelah penyebaran, ternyata panggilan kontrak yang diharapkan dari satu sama lain tidak berfungsi. Tidak cukup hak. Tidak seperti kontrak pintar di Ethereum, di mana kontrak dipanggil dari kontrak atas nama kontrak panggilan, di EOS, seluruh rantai dimulai dengan pemrakarsa transaksi. Ketika suatu kontrak dipanggil dari suatu kontrak, akan diperiksa apakah pemrakarsa mengizinkan kontrak untuk melakukan hal ini.

Mentor segera menyarankan cara bertindak dalam kasus sederhana. Hak ditambahkan sebagai berikut (melalui panggilan kontrak pintar sistem eosio):

 ./cleos push action eosio updateauth '{"account":"electricity","permission":"active","parent":"owner","auth":{"keys":[{"key":"EOS7oPdzdvbHcJ4k9iZaDuG4Foh9YsjQffTGniLP28FC8fbpCDgr5","weight":1}],"threshold":1,"accounts":[{"permission":{"actor":"supplier","permission":"eosio.code"},"weight":1}],"waits":[]}}' -p electricity 

Dalam hal ini, akun electricity memungkinkan kontrak supplier untuk memanggil kontrak lain atas namanya. Anda dapat membaca lebih lanjut tentang hak di WP Teknis EOS . Di negara kita, kontrak supplier menyebabkan kontrak billing , dan pada gilirannya, lagi-lagi disebut supplier . Menambahkan dengan analogi hak dalam formulir ini tidak berhasil:

 ./cleos push action eosio updateauth '{"account":"electricity","permission":"active","parent":"owner","auth":{"keys":[{"key":"EOS7oPdzdvbHcJ4k9iZaDuG4Foh9YsjQffTGniLP28FC8fbpCDgr5","weight":1}],"threshold":1,"accounts":[{"permission":{"actor":"supplier","permission":"eosio.code"},"weight":1},{"permission":{"actor":"billelectro","permission":"eosio.code"},"weight":1}],"waits":[]}}' -p electricity 

Terjadi kesalahan: Otoritas tidak valid. Di sini para mentor tidak dapat lagi membantu kami: mereka berkata bahwa mereka sendiri tidak melakukan ini. Dan siapa yang melakukannya? Mungkin hanya Dan Larimer. Kami tidak dapat dengan cepat menemukan penyebab kesalahan dalam kode EOS dan sudah mulai mempertimbangkan opsi alternatif, tanpa rantai panggilan. Ini dicegah dengan indah bahwa mekanisme untuk memanggil kontrak lain di EOS juga berbeda dari eter. Ketika kontrak lain dipanggil, panggilan ini diantrekan dan hanya akan selesai setelah panggilan saat ini selesai. Tidak akan bekerja untuk memanggil kontrak dan setelah panggilan untuk membaca data yang dicatat oleh kontrak ini.

Kemudian, setelah semua, mereka menemukan dalam kode EOS alasan kesalahan ketika menetapkan hak untuk dua kontrak. Ternyata akun dalam daftar hak harus disortir berdasarkan akun: Memastikan semua kunci unik dan diurutkan dan semua izin akun unik dan diurutkan ( authority.hpp ). Setelah mengubah urutan akun, pembaruan hak berhasil - dan sistem kontrak kami mulai beroperasi.

2.3.2. Masalah fungsi-C dengan memori

Mengatakan hal itu konyol, tetapi pada akhirnya kami tidak dapat menggunakan fungsi yang sudah jadi untuk menguraikan angka (!) Untuk membaca konfigurasi penagihan. Mengikuti std::istringstream fungsi std::istringstream ditarik ke atas, yang agak aneh. Dan ketika menggunakan atof dan sejenisnya, serta sscanf - env.realloc diperketat. Untuk beberapa alasan, fungsi-fungsi yang disebutkan bekerja dengan memori pustaka C standar tidak ditemukan selama pemuatan kode di nodeos. Fungsi C ++ bekerja dengan memori berfungsi.

Tentu saja, ketika menjalankan kontrak WebAssembly, bukan pengalokasi memori standar yang digunakan, tetapi kotak pasirnya sendiri, yang disediakan untuk setiap transaksi dalam kondisi tertentu. Juga, dukungan untuk fungsi-C yang bekerja dengan memori di atas kotak pasir ini telah diimplementasikan untuk waktu yang lama, implementasinya dalam kontrak EOS standar . Mungkin ada yang tidak beres pada tahap penautan.

Setelah menghabiskan sekitar satu jam mencari jalan keluar, termasuk dengan bantuan salah satu mentor, kami memutuskan untuk tidak melanjutkan dan membuat solusi: tulis kode kami sendiri yang memecahkan masalah parsing angka. Mekanisme datastream EOS tidak sesuai dengan kita: diperlukan kemampuan untuk menyimpan paket data dari struktur yang berbeda dalam satu bidang dan membentuknya dengan tangan (konfigurasi yang sangat penagihan).

2.3.3. Tagihan belanja

Pada angin kedua, yang dibuka baik oleh insinyur listrik atau saat sarapan pagi, mereka menulis tagihan untuk berbelanja di toko. Skema kerja umum adalah sebagai berikut:

1. Pemasok membuat kontrak penagihan dan menetapkannya dalam kontrak umum.
2. Di outlet toko, pemasok membuat kerangka kerja yang dapat membaca RFID, berinteraksi dengan EOS dan memiliki akun sendiri yang ditentukan dalam kontrak penagihan.
3. Setiap produk di toko dilengkapi dengan tag RFID, semua tag terdaftar dalam kontrak penagihan.
4. Pembeli membayar barang dengan memindai RFID-nya, dan barang dihapus dari kontrak penagihan.
5. Di pintu keluar dari toko, bingkai juga membaca pembelian RFID. Jika barang masih ada di toko, transaksi tidak lulus, dan frame harus membunyikan alarm (ya, sebenarnya, Anda bahkan tidak dapat mengirim transaksi, tetapi cukup membaca tabel).

Tidak masuk akal untuk memikirkan kode kontrak itu sendiri: ini adalah standar C ++ 14 dengan beberapa konstruksi dan pustaka spesifik EOS. Lebih baik dikatakan di EOSIO Wiki dan Portal Pengembang EOSIO .

2.3.4. Frontend

Bagian depan dari proyek diimplementasikan menggunakan React. Alih-alih biasanya banyak Redux memutuskan untuk menggunakan MobX, yang secara signifikan mempercepat pengembangan dan memungkinkan Anda untuk mengelola status global tanpa sakit kepala.

Fase integrasi front-blockchain tidak berjalan semulus yang diharapkan. Paket eosjs sedang diselesaikan dengan sangat aktif, diikuti oleh dompet EOS untuk browser Scatter . Dalam kelompok ini, ini sering menyebabkan masalah. Dan bukan fakta bahwa kode yang bekerja kemarin akan berfungsi dengan baik hari ini. Kami menginjak menyapu ini (dan bukan yang pertama kali). Satu jam mencoba dan men-debug dalam kondisi mengantuk - masalah terpecahkan.

Pertimbangkan diagram yang disederhanakan dari interaksi sisi klien dari aplikasi dengan eos. Untuk melakukan ini, Anda memerlukan perpustakaan eosjs dan ekstensi browser Scatter.

Kami mengingatkan Anda! Menyebarkan secara aktif diperbarui setelah eosjs, jangan lupa untuk memperbarui perpustakaan.

Selanjutnya, sekilas membaca dan menulis. Ada dua cara untuk berkomunikasi dengan kontrak pintar dalam EOS: mengirim transaksi (itu menyebabkan blockchain akan dimodifikasi, tanpa nilai pengembalian yang disediakan) dan membaca tabel (tindakan hanya baca).

Pertimbangkan kode pengiriman transaksi:

  sendTransaction(funcName, data) { return this.scatter .suggestNetwork(this.network) .then(() => this.scatter.getIdentity({ accounts: [this.network] })) .then((identity) => { let accountName = this.getAccountName(identity); // wrap eos instance const eos = this.scatter.eos(this.network, Eos, this.configEosInstance); return eos.transaction(accountName, (contract) => { contract[funcName](data, { authorization: accountName }); }); }); } 

Input argumen: nama fungsi dan objek, nilainya adalah argumen fungsi ini. Baris ketiga: kami mengkonfirmasi jaringan tempat kami berinteraksi dengan EOS. Baris keempat: kita mendapatkan identity , parameternya adalah objek dengan bidang accounts (untuk jaringan ini). Fungsi getAccountName mengembalikan akun pertama dari daftar akun yang diterima (di objek identity ).

Dalam contoh ini, Scatter digunakan untuk menandatangani transaksi. Scatter adalah pembungkus atas instance dari kelas Eos . Pada baris 9, kita memanggil metode eos , parameternya:

1. this.network - objek dengan parameter jaringan.
2. Eos adalah turunan dari eosjs.
3. this.configEosInstance - objek dengan parameter untuk instance Eos (lihat dock eosjs).

Metode transaction terakhir menerima nama akun dan callback sebagai input, argumen callback adalah kontrak yang terletak di nama akun. Dalam callback 'e, kita memanggil metode kontrak yang diterima dengan objek, kuncinya adalah argumen dari metode yang disebut.

Pertimbangkan metode membaca tabel:

  readTable(data) { this.eos = this.scatter.eos(this.network, Eos, this.configEosInstance); return this.eos.getTableRows({ json: true, limit: 1, ...data, }); } 

Di sini untuk membaca kita hanya perlu contoh eos .

Untuk mendesain antarmuka, kami menjatuhkan Materialize, Semantic, dan Ant, membuat gaya sendiri. Pada jam-jam terakhir hackathon, sebuah ide muncul untuk menghidupkan kembali UI, menambahkan visualisasi proses. Sorot baris baru tabel selama dua detik berwarna hijau dan dapatkan efek keren harga saham. Perbaikan secara signifikan meningkatkan daya tarik proyek dan menjadi tahap akhir membangun UI.

3. Majelis

Tiga jam sebelum akhir waktu, kami memiliki Raspberry Pi dengan meteran listrik Merkurius dan pembaca RFID yang terhubung dengannya, serta indikasi cahaya. Semua listrik meja melewati Merkurius. Untuk setiap 0,3125 Wh / jam yang dihabiskan, serta untuk setiap "pembelian", Raspberry Pi mengirim transaksi ke blockchain kami, dan penyedia layanan dapat mengelola pengguna, sensor, penagihan, dan melihat statistik konsumsi.

Selama satu jam lagi, kami dengan tenang melakukan cek dan menambahkan sentuhan akhir. Dua jam sebelum akhir waktu, kami menerima produk lengkap dengan dua case yang diimplementasikan, sepenuhnya menggambarkan konsep, dan bahkan tidak ada komitmen di menit terakhir!

4. Demonstrasi

Demonstrasi proyek (alias pitches) terdiri dari dua tahap. Pada tahap pertama, 69 tim yang berpartisipasi dibagi menjadi empat kelompok, masing-masing diberi makan secara terpisah di depan dua juri dan tanpa penonton. Para juri memberikan nilai (masing-masing empat kriteria dari 5 poin), dan berdasarkan nilai ini, 10 tim teratas dipilih untuk tahap kedua. Tim-tim ini diberi kesempatan untuk menggelar proyek di panggung besar di depan penonton dan kedelapan hakim.

Kami berakhir di kelompok pertama, hakim kami adalah CEO dan presiden (saya bertanya-tanya bagaimana posisi ini berbeda) dari Everipedia. Tiga menit dialokasikan untuk kinerja, mereka dipantau secara ketat oleh timer. Kami menyelesaikan ketidakkonsistenan kami, tetapi meminta untuk mengesankan pidato 30 detik lebih cepat dari jadwal. Para hakim menanyakan sesuatu secara dangkal dan agak singkat, dan demonstrasi berakhir.

Kami, yang naif, terkejut bahwa kami tidak memperhatikan kapasitas kerja produk yang sebenarnya, dan lebih lagi pada kode hakim. Masalah implementasi teknis tidak menarik bagi mereka bahkan pada tingkat sedikit pun. Kami juga bisa menunjukkan lampu Raspberry Pi yang berkedip dan gambar di bagian depan.

Ada perasaan bahwa dengan presentasi proyek kami gagal, karena kami berharap untuk mengesankan dengan solusi aktual, prototipe, dan bukan hanya deskripsi warna-warni dari proyek yang signifikan secara sosial dan ambisius. Semuanya dimainkan seolah-olah dengan catatan: kami menggambarkan masalah, rasa sakit, solusi kami, menunjukkan cara kerjanya, dan menggambarkan rencana pengembangan proyek. Mengetahui sebelumnya tentang metode penilaian, kita akan melakukan banyak hal berbeda.

Para juri dari empat aliran putaran pertama mengurangi skor mereka dan bertukar pandangan 15 menit setelah akhir lemparan. Setelah pengumuman pemenang dimulai. Suasana gugup memerintah di aula: lelah setelah maraton 26 jam, orang-orang ingin menang, ada banyak tim yang kuat, dan mereka tahu bahwa mereka dapat mengklaim kemenangan. Dan kami tahu itu - dan menunggu hasilnya.

Agar penonton tidak rileks, hasilnya diumumkan dalam tiga bagian. Empat finalis pertama, kemudian tiga lagi, lalu tiga lainnya. Antara pengumuman dan di akhir pertunjukan. Kami tidak masuk ke 10 besar dan tidak mendapat kesempatan untuk memasuki panggung besar. Dua tim berbahasa Rusia berhasil masuk dalam sepuluh besar, salah satunya akhirnya menjadi yang ketiga. Selamat untuk para pemenang, mereka pantas mendapatkan hadiah mereka.

5. Kesimpulan dan rencana

AngelHack . , . — , , . , , , — .

26 IoT- EOS. , .

— UI ( — -- Smartz ), . - , blockchain-ready , , — . :)

, , «», «» . . 5 . , 100 , . SensorPay !

:

Yuvasee (entrepreneur)
algs (hardware & backend developer)
therealal (architect, backend developer, devops)
bolbu (frontend developer)
quantum (blockchain & backend developer)