Arsitektur On-Chain vs Off-Chain untuk Sistem IoT

Kesalahan paling umum saat pertama kali mencoba menggabungkan IoT dan blockchain adalah mencoba menulis setiap pembacaan sensor langsung ke chain. Terlihat sederhana di atas kertas, tapi begitu diterapkan ke sistem yang mengirim data setiap beberapa detik, pendekatan ini cepat menjadi tidak praktis. Artikel ini membahas pola arsitektur on-chain/off-chain yang realistis untuk sistem IoT industri — lihat juga panduan blockchain untuk IoT untuk gambaran fungsinya secara umum.

Kenapa Menulis Semua Data ke Chain Tidak Praktis

Ada tiga alasan konkret kenapa pendekatan ini bermasalah:

• Biaya yang menumpuk. Setiap transaksi on-chain punya biaya (gas fee di jaringan publik, atau biaya operasional node di jaringan permissioned). Kalau sensor mengirim data tiap beberapa detik, biaya ini terakumulasi cepat dan tidak sebanding dengan manfaatnya.
• Waktu konfirmasi yang tidak deterministik. Blok baru tidak selalu terbentuk dalam interval yang bisa diprediksi persis, sehingga data yang butuh diproses real-time tidak cocok menunggu konfirmasi on-chain.
• Keterbukaan data yang tidak selalu diinginkan. Sebagian besar jaringan blockchain publik bersifat terbuka — siapa pun bisa membaca data yang tercatat. Tidak semua data sensor industri pantas dipublikasikan seperti itu.

Ketiga alasan ini sering muncul bersamaan dalam satu proyek yang gagal: tim mulai dengan antusias mencatat setiap pembacaan suhu atau tekanan ke chain, lalu dalam hitungan minggu biaya transaksi membengkak, sistem monitoring jadi lambat karena menunggu konfirmasi blok, dan tim baru sadar sebagian data yang dicatat sebenarnya bersifat sensitif dan tidak seharusnya terbuka untuk dibaca siapa pun.

Prinsip Dasar: Off-Chain Menyimpan Data, On-Chain Menyimpan Bukti

Pola yang jauh lebih realistis adalah memisahkan dua hal: data mentah disimpan off-chain (database biasa, time-series database, atau storage terdistribusi), sementara yang naik ke chain hanya bukti integritasnya. Bukti ini biasanya berbentuk hash dari satu data poin, atau lebih efisien lagi, Merkle root yang meringkas ribuan pembacaan sekaligus menjadi satu nilai 32-byte.

Kalau suatu saat data dipertanyakan, siapa pun yang punya akses ke data off-chain bisa menghitung ulang hash-nya dan membandingkan dengan yang tercatat on-chain. Kalau cocok, data terbukti belum diubah sejak dicatat.

Prinsip ini sebenarnya bukan hal baru dalam dunia komputer — konsepnya mirip dengan checksum file yang sudah lama dipakai untuk memverifikasi integritas file setelah diunduh. Bedanya, blockchain menambahkan lapisan yang membuat catatan checksum itu sendiri sulit dipalsukan atau diubah diam-diam, karena tersebar di banyak node dan setiap perubahan akan merusak rantai hash ke blok-blok sesudahnya.

Diagram Arsitektur Lengkap

[GAMBAR: diagram arsitektur salah (semua sensor langsung ke chain) vs benar (sensor → backend/database off-chain → penghitung hash/Merkle root → anchoring periodik ke chain)]

Alur yang realistis biasanya seperti ini: perangkat IoT mengirim data ke backend seperti biasa (misalnya lewat MQTT), backend menyimpan data mentah di database, lalu secara periodik (per menit, per jam, atau per shift) backend menghitung hash/Merkle root dari kumpulan data pada periode tersebut dan mencatatnya ke smart contract. Proses anchoring ini bisa berjalan sebagai job terjadwal terpisah, tidak mengganggu jalur data utama.

Keuntungan memisahkan proses anchoring dari jalur data utama seperti ini adalah: kalau proses anchoring gagal atau jaringan blockchain sedang bermasalah, sistem monitoring utama tetap berjalan normal karena tidak bergantung padanya. Anchoring bisa dicoba ulang di kesempatan berikutnya tanpa mengganggu operasional harian.

Frekuensi Anchoring dan Trade-off-nya

Frekuensi anchoring adalah keputusan trade-off antara granularitas bukti dan biaya. Anchoring tiap menit memberi bukti yang sangat detail (sengketa bisa dilacak sampai ke rentang satu menit), tapi biayanya jauh lebih tinggi dibanding anchoring per shift atau per hari. Kebanyakan implementasi industri memilih titik tengah — misalnya per jam — yang cukup detail untuk kebutuhan audit tapi tidak membebani biaya operasional.

Sebagai ilustrasi sederhana: sebuah lini produksi dengan 50 sensor yang masing-masing mengirim data tiap 10 detik akan menghasilkan sekitar 432.000 pembacaan per hari. Menulis semuanya langsung ke chain jelas tidak masuk akal. Tapi dengan anchoring per jam, itu hanya berarti 24 transaksi on-chain per hari — masing-masing berupa satu Merkle root yang meringkas ribuan pembacaan pada jam tersebut. Kalau granularitas per jam dianggap kurang detail untuk kebutuhan audit tertentu, anchoring bisa dipersempit ke per 15 menit tanpa membuat biayanya membengkak seperti pendekatan per pembacaan.

Kriteria Memilih Jaringan

Pemilihan jaringan blockchain juga bagian dari keputusan arsitektur ini. Jaringan publik (Ethereum, Polygon, dan sejenisnya) cocok kalau transparansi ke pihak luar yang tidak dikenal adalah prioritas — misalnya kalau publik umum perlu bisa memverifikasi klaim tanpa harus diberi akses khusus. Jaringan permissioned (seperti Hyperledger Fabric) lebih cocok untuk konteks industri di mana pesertanya sudah dikenal (pabrik, pemasok, auditor) dan tidak semua data perlu terbuka ke publik — peserta yang berpartisipasi biasanya sudah melalui proses onboarding dan punya identitas yang jelas, bukan anonim seperti di jaringan publik.

Faktor lain yang perlu dipertimbangkan: throughput (berapa banyak transaksi yang bisa diproses per detik), finalitas transaksi (seberapa cepat sebuah transaksi dianggap benar-benar final dan tidak bisa dibatalkan), serta kemudahan operasional menjalankan node sendiri versus memakai penyedia layanan pihak ketiga. [perlu verifikasi/riset: perbandingan biaya operasional dan throughput jaringan publik vs permissioned untuk skala anchoring IoT industri].

Batas Arsitektur Ini

Arsitektur on-chain/off-chain ini membuktikan integritas data — bahwa data tidak diubah setelah dicatat — bukan kebenaran data itu sendiri. Arsitektur ini juga tidak dirancang untuk keputusan real-time yang menyangkut kontrol atau keselamatan; fungsi kontrol, interlock, dan emergency stop tetap harus berada di PLC atau sistem safety yang sesuai standar, bukan bergantung pada konfirmasi on-chain yang waktunya tidak deterministik.

Kesimpulan

Arsitektur blockchain untuk IoT yang realistis bukan soal mencatat semua data ke chain, tapi soal memisahkan dengan jelas mana yang perlu naik (bukti integritas) dan mana yang cukup tinggal di off-chain (data mentah). Keputusan frekuensi anchoring dan jenis jaringan yang dipakai adalah trade-off yang perlu disesuaikan dengan kebutuhan audit dan anggaran operasional masing-masing sistem.

Baca Juga

• Cara membuat hash data sensor ESP32 — implementasi teknis dari prinsip off-chain/on-chain yang dibahas di atas.
• Identitas digital perangkat IoT — lapisan pelengkap yang memastikan data berasal dari perangkat yang sah.

Belajar Lebih Terstruktur

Materi ini tersedia dalam bentuk course terstruktur di bisaioti.id, lengkap dengan kit hardware supaya bisa langsung dipraktikkan.

[perlu data: nama course yang relevan, link course, nama kit hardware]