Smart Contract untuk Mencatat Hash Data Sensor IoT (Bukan Tutorial Solidity Dasar)

Di artikel sebelumnya, hash data sensor ESP32 membahas cara menghitung hash dan Merkle root dari pembacaan sensor, sampai ke langkah mencatat root itu ke blockchain. Artikel ini melanjutkan persis dari titik itu: bagaimana bentuk smart contract yang menerima dan menyimpan Merkle root tersebut. Ini bukan tutorial dasar Solidity — kalau Anda belum familiar dengan sintaks dasar Solidity (variabel, function, mapping), pelajari dulu seri dasar-dasar Solidity di bisaioti sebelum melanjutkan. Artikel ini fokus murni pada satu smart contract terapan untuk kasus IoT industri: mencatat bukti integritas data sensor.

Kenapa Bukan Smart Contract Generik

Banyak tutorial smart contract mengajarkan pola umum seperti token atau voting, yang tidak langsung relevan untuk kebutuhan IoT industri. Kontrak yang dibutuhkan di sini jauh lebih sempit fungsinya: menerima satu Merkle root beserta metadatanya (timestamp, ID device pencatat), menyimpannya secara permanen, dan menyediakan cara untuk membacanya kembali guna verifikasi. Tidak ada logika token, tidak ada mekanisme voting — hanya pencatatan bukti yang sederhana dan bisa diaudit.

Struktur Kontrak: DataAnchor

Berikut kontrak minimal yang menjalankan fungsi ini, dengan nama DataAnchor:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

contract DataAnchor {
    struct Anchor {
        bytes32 merkleRoot;
        uint256 timestamp;
        address pencatat;
    }

    mapping(uint256 => Anchor) public anchors;
    uint256 public jumlahAnchor;

    mapping(address => bool) public perangkatTerdaftar;
    address public admin;

    event AnchorTercatat(uint256 indexed id, bytes32 merkleRoot, uint256 timestamp, address pencatat);

    constructor() {
        admin = msg.sender;
    }

    modifier hanyaAdmin() {
        require(msg.sender == admin, "Bukan admin");
        _;
    }

    modifier hanyaPerangkatTerdaftar() {
        require(perangkatTerdaftar[msg.sender], "Perangkat tidak terdaftar");
        _;
    }

    function daftarkanPerangkat(address perangkat) external hanyaAdmin {
        perangkatTerdaftar[perangkat] = true;
    }

    function cabutPerangkat(address perangkat) external hanyaAdmin {
        perangkatTerdaftar[perangkat] = false;
    }

    function catatAnchor(bytes32 _merkleRoot) external hanyaPerangkatTerdaftar {
        anchors[jumlahAnchor] = Anchor(_merkleRoot, block.timestamp, msg.sender);
        emit AnchorTercatat(jumlahAnchor, _merkleRoot, block.timestamp, msg.sender);
        jumlahAnchor++;
    }

    function ambilAnchor(uint256 id) external view returns (bytes32, uint256, address) {
        Anchor memory a = anchors[id];
        return (a.merkleRoot, a.timestamp, a.pencatat);
    }
}

[GAMBAR: diagram alur — backend hitung Merkle root → panggil catatAnchor() → event AnchorTercatat → data tersimpan permanen di chain]

Penjelasan Bagian-Bagian Penting

Beberapa hal yang sengaja dirancang seperti ini, bukan kebetulan:

• Registry perangkat terdaftar (perangkatTerdaftar). Bukan sembarang alamat yang bisa mencatat anchor — hanya backend yang sudah didaftarkan admin. Ini menghubungkan langsung ke konsep identitas perangkat yang dibahas di identitas digital perangkat IoT: alamat yang mencatat di sini idealnya adalah alamat yang terasosiasi dengan identitas perangkat/backend yang sudah diverifikasi, bukan alamat sembarang.
• Event AnchorTercatat. Event ini bukan sekadar catatan — ini yang membuat pencatatan bisa dipantau secara real-time oleh sistem eksternal (dashboard, alert) tanpa harus terus-menerus membaca storage kontrak, yang jauh lebih mahal secara gas.
• Fungsi ambilAnchor bersifat view. Membaca data dari blockchain tidak memerlukan transaksi dan tidak memakan gas, sehingga siapa pun (auditor, sistem verifikasi pihak ketiga) bisa mengecek anchor kapan saja tanpa biaya.
• Tidak ada fungsi hapus. Ini disengaja — smart contract untuk bukti integritas sebaiknya tidak punya cara menghapus anchor yang sudah tercatat, karena itu bertentangan dengan tujuan awal (bukti yang tidak bisa diubah sepihak).

Memanggil Kontrak dari Backend (web3.py)

Sisi backend Python yang sudah menghitung Merkle root (dari artikel hash data sensor) memanggil fungsi catatAnchor seperti ini:

from web3 import Web3

w3 = Web3(Web3.HTTPProvider('https://rpc-endpoint-jaringan-anda'))
kontrak = w3.eth.contract(address=ALAMAT_KONTRAK, abi=ABI_KONTRAK)

def catat_merkle_root(merkle_root_hex, akun_pencatat, private_key):
    merkle_root_bytes = bytes.fromhex(merkle_root_hex)
    tx = kontrak.functions.catatAnchor(merkle_root_bytes).build_transaction({
        'from': akun_pencatat,
        'nonce': w3.eth.get_transaction_count(akun_pencatat),
        'gas': 100000,
    })
    tx_ditandatangani = w3.eth.account.sign_transaction(tx, private_key)
    tx_hash = w3.eth.send_raw_transaction(tx_ditandatangani.raw_transaction)
    return w3.to_hex(tx_hash)

[perlu verifikasi: versi library web3.py dan parameter gas yang sesuai dengan jaringan yang dipilih sebelum dipakai di produksi]

Estimasi Biaya dan Kapan Ini Masuk Akal

Menyimpan satu anchor (satu bytes32 plus metadata) tergolong operasi ringan dibanding smart contract kompleks, tapi tetap ada biaya gas setiap kali catatAnchor dipanggil. Kalau anchoring dilakukan per jam sebagaimana dibahas di arsitektur on-chain/off-chain, berarti 24 transaksi per hari — jauh lebih murah dibanding mencatat tiap pembacaan sensor individual. [perlu verifikasi/riset: estimasi biaya gas aktual dalam Rupiah untuk 24 transaksi/hari di jaringan yang dipilih, karena harga gas berfluktuasi].

Batasan yang Perlu Diingat

• Blockchain tidak berada di jalur kontrol. Fungsi kontrol, interlock, dan emergency stop tetap di PLC atau sistem safety yang sesuai standar.
• Smart contract tidak boleh menggerakkan aktuator secara langsung tanpa verifikasi dan interlock di sisi PLC/edge. Kontrak DataAnchor di atas murni pencatatan, tidak pernah memanggil aktuator apa pun.
• Waktu konfirmasi transaksi tidak deterministik, sehingga tidak layak untuk keputusan real-time yang menyangkut keselamatan.
• Kode kontrak di atas adalah contoh pembelajaran, bukan kode yang sudah diaudit keamanannya — audit smart contract profesional tetap diperlukan sebelum penggunaan produksi dengan nilai signifikan.
• Perubahan pada sistem produksi mengikuti prosedur manajemen perubahan dan izin pihak berwenang di fasilitas terkait.

Menguji Kontrak Sebelum Dipakai

Sebelum kontrak ini dipanggil dari backend produksi, ada baiknya diuji dulu di jaringan testnet (bukan mainnet langsung) menggunakan framework seperti Hardhat atau Foundry. Alur pengujian yang wajar: deploy kontrak ke testnet, panggil daftarkanPerangkat dengan alamat backend pengujian, lalu panggil catatAnchor berulang kali dengan data uji dan pastikan event AnchorTercatat muncul sesuai harapan serta ambilAnchor mengembalikan nilai yang benar. Pengujian di testnet ini juga kesempatan untuk mengukur estimasi gas riil sebelum kontrak dipindah ke jaringan produksi.

Kesimpulan

Smart contract untuk kebutuhan IoT industri tidak perlu rumit — kontrak DataAnchor di atas hanya menyimpan Merkle root, metadata, dan menyediakan cara membacanya kembali, dengan kontrol akses sederhana berbasis daftar perangkat terdaftar. Kesederhanaan ini justru kekuatan: lebih mudah diaudit, lebih murah dari sisi gas, dan risikonya lebih rendah dibanding kontrak dengan banyak fungsi kompleks.

Baca Juga

• Blockchain untuk IoT: fungsi nyata, arsitektur, dan roadmap belajarnya — gambaran umum sebelum masuk ke smart contract ini.
• Oracle: jembatan data sensor IoT ke smart contract — bagaimana data sampai ke kontrak ini secara aman.
• Tutorial proyek: membangun sistem monitoring IoT dengan bukti integritas blockchain — contoh penerapan kontrak ini dalam proyek nyata.

Mau Langsung Praktik?

Materi seperti ini jauh lebih cepat masuk kalau langsung dipraktikkan ke hardware. bisaioti mengadakan training IoT secara online (Zoom) dan offline dengan porsi praktik langsung ke perangkat nyata.

[perlu data training: tema, tanggal & waktu, format online/offline, lokasi, kuota, link pendaftaran]