SertiKu: Cara Kerja Platform Sertifikat Digital di Blockchain Solana
Membedah arsitektur SertiKu: platform sertifikat digital yang mencatat hash sertifikat di blockchain Solana dan metadata di IPFS, dengan verifikasi QR Code.
Panji Ihsanudin Fajri
11 min read2 reads

Contents
- Apa itu SertiKu?
- Masalah yang diselesaikan: sertifikat palsu itu murah dibuat
- Arsitektur SertiKu: tiga lapisan yang saling melengkapi
- Cara kerja verifikasi: dari pindai QR sampai bukti on-chain
- Anatomi program Solana
- Pengujian di devnet sebelum production
- IPFS untuk metadata: kenapa tidak semuanya di blockchain?
- Lapisan keamanan: tidak mengandalkan blockchain saja
- Pelajaran desain untuk developer
- FAQ
- Apakah SertiKu masih memakai Polygon?
- Berapa biaya mencatat satu sertifikat di Solana?
- Apakah penerima sertifikat harus punya wallet kripto?
- Bagaimana kalau lembaga penerbit tutup?
- Apakah QR Code-nya bisa dipalsukan?
- Kesimpulan
Sertifikat palsu bukan masalah baru. Lembaga kursus, kampus, dan penyelenggara pelatihan sudah bertahun-tahun bergulat dengan dokumen yang mudah dipalsukan: cukup edit PDF, ganti nama, cetak ulang — selesai. SertiKu, platform sertifikat digital asal Indonesia, menjawab masalah ini dengan pendekatan yang tidak biasa: setiap sertifikat dicatat di blockchain Solana, metadata-nya disimpan di IPFS, dan verifikasinya cukup lewat pindai QR Code.
Artikel ini membedah cara kerja SertiKu dari sisi teknis — arsitektur sistemnya, program Solana yang dipakai, alur verifikasinya, dan pelajaran desain yang bisa dipakai ulang untuk proyek sejenis.
Ringkasan: SertiKu menerbitkan sertifikat digital yang hash-nya dicatat di blockchain Solana (program di jaringan Solana yang dibangun dengan Anchor framework). Metadata lengkap disimpan di IPFS via Pinata. Verifikasi dilakukan lewat QR Code tanpa perlu login. Arsitekturnya memisahkan penyimpanan murah (event blockchain + IPFS) dari state on-chain yang minimal. Pola ini menekan biaya transaksi sekaligus menjaga ketahanan terhadap pemalsuan.

Apa itu SertiKu?
SertiKu adalah platform untuk menerbitkan, mengelola, dan memverifikasi sertifikat digital. Lembaga (kampus, lembaga kursus, penyelenggara event) membuat template sertifikat lewat editor drag-and-drop, mengisi data penerima — manual atau bulk lewat CSV/Excel — lalu sistem menerbitkan sertifikat lengkap dengan QR Code unik. Penerima bisa mengunduh PDF-nya, dan siapa pun bisa memverifikasi keaslian sertifikat dengan memindai QR Code tersebut.
Yang membedakan SertiKu dari aplikasi sertifikat biasa adalah lapisan blockchain-nya. Setiap sertifikat yang diterbitkan, hash SHA-256 dari datanya dicatat ke blockchain Solana lewat sebuah program Anchor yang berjalan di jaringan Solana. Begitu tercatat, data tersebut tidak bisa diubah atau dihapus oleh siapa pun — termasuk penerbitnya sendiri. Inilah yang membuat klaim "sertifikat asli" bisa dibuktikan secara kriptografis, bukan sekadar dipercaya.
Masalah yang diselesaikan: sertifikat palsu itu murah dibuat
Sebelum membahas teknisnya, penting memahami kenapa pendekatan blockchain masuk akal di sini. Sertifikat digital konvensional — PDF yang diunduh dari sebuah website — punya satu titik kegagalan fundamental: file-nya bisa disalin dan dimodifikasi tanpa jejak. Tidak ada cara bagi pihak ketiga untuk memastikan bahwa PDF yang diklaim sebagai "sertifikat resmi" memang diterbitkan oleh lembaga yang tercantum di dalamnya.
Solusi lama untuk masalah ini adalah database terpusat: lembaga menyediakan halaman verifikasi, pengunjung memasukkan nomor sertifikat, sistem menjawab "valid" atau "tidak valid". Ini bekerja, tapi bergantung penuh pada satu pihak. Kalau database-nya diretas, dimanipulasi orang dalam, atau lembaganya tutup dan servernya mati, seluruh riwayat verifikasi ikut hilang.
Blockchain menyelesaikan dua hal sekaligus: integritas (data yang tercatat tidak bisa diubah retroaktif) dan ketersediaan verifikasi independen (siapa pun bisa memeriksa catatan di jaringan tanpa meminta izin ke penerbit). SertiKu memanfaatkan kedua sifat ini. Hash sertifikat hidup di Solana, metadata lengkapnya di IPFS — keduanya di luar kendali satu server.
Arsitektur SertiKu: tiga lapisan yang saling melengkapi

Secara garis besar, SertiKu terdiri dari tiga lapisan:
- Aplikasi web — tempat lembaga membuat template, mengelola data penerima, dan menerbitkan sertifikat. Di sinilah QR Code dibuat untuk setiap sertifikat, dan di sinilah pengguna melakukan verifikasi lewat halaman
/verifikasi. - Jaringan Solana (devnet) — tempat bukti penerbitan dicatat. Program di jaringan Solana menyimpan status setiap sertifikat (ada, dicabut, siapa penerbitnya) dalam akun PDA (Program Derived Address).
- IPFS via Pinata — penyimpanan desentralisasi untuk metadata dan file sertifikat, sehingga dokumen aslinya tetap bisa diakses walau server aplikasi bermasalah.
Alur penerbitan berjalan seperti ini: lembaga mengisi data penerima → aplikasi menghitung hash SHA-256 dari data sertifikat → metadata di-pin ke IPFS → transaksi pencatatan dikirim ke program Solana dengan hash dan data sertifikat → QR Code dibuat menunjuk ke URL verifikasi berisi hash tersebut. Seluruh proses ini juga bisa diotomatisasi lewat n8n yang sudah terintegrasi.
SertiKu awalnya berjalan di jaringan Polygon, lalu dimigrasikan ke Solana. Keputusan migrasi ini masuk akal untuk use case sertifikat: Solana menawarkan finalitas transaksi dalam hitungan detik dan biaya yang sangat rendah, dua hal yang penting ketika sebuah lembaga menerbitkan ratusan atau ribuan sertifikat sekaligus.
Cara kerja verifikasi: dari pindai QR sampai bukti on-chain
Verifikasi adalah fitur yang paling sering dipakai, jadi alurnya dibuat sesederhana mungkin — tanpa login, tanpa install aplikasi.

- Pindai QR Code di sertifikat. QR Code mengarah ke halaman verifikasi dengan hash sertifikat sebagai parameter, misalnya
/verifikasi/{hash}. - Sistem memeriksa hash ke program Solana: apakah hash ini tercatat, siapa penerbitnya, dan apakah statusnya masih aktif atau sudah dicabut.
- Hasil tampil — detail sertifikat (nama penerima, nama pelatihan, tanggal terbit, nama lembaga) beserta status validitasnya. Ada juga opsi unduh PDF dan pratinjau dokumen.
Di balik layar, endpoint seperti /verifikasi/check dan /verifikasi/file menangani pemeriksaan ini. Pemeriksaan integritas file memakai SHA-256 (dan MD5 sebagai pelengkap): hash file yang diunggah untuk verifikasi dibandingkan dengan hash yang tercatat di blockchain. Kalau satu byte saja berubah, hash-nya berbeda dan verifikasi gagal. Ini mekanisme yang sederhana tapi kuat — tidak ada cara untuk "sedikit memodifikasi" sertifikat tanpa ketahuan.
Fitur tambahan yang patut dicatat: halaman verifikasi publik juga menerima laporan penipuan, sehingga masyarakat bisa melaporkan sertifikat mencurigakan langsung dari halaman hasil verifikasi.
Anatomi program Solana
Bagian paling menarik secara teknis adalah program Solana-nya. Ditulis dengan Anchor framework (Rust), program ini memakai pola hybrid storage — sebuah optimasi yang penting di Solana karena penyimpanan on-chain itu mahal (setiap byte akun butuh rent).
Struktur datanya minimal. Setiap sertifikat direpresentasikan oleh satu akun PDA (Program Derived Address), dan hanya menyimpan tiga informasi:
Ketiga informasi tersebut adalah status keberadaan sertifikat, status pencabutan, dan identitas penerbit. Tidak lebih.
Data lengkap sertifikat (nomor sertifikat, nama penerima, nama pelatihan, tanggal terbit, nama lembaga) tidak disimpan di akun — melainkan diemisikan sebagai event. Event di Solana jauh lebih murah daripada penyimpanan akun karena tidak membutuhkan rent (biaya sewa penyimpanan on-chain). Pola ini secara signifikan menekan biaya pencatatan per sertifikat dibandingkan menyimpan seluruh data di akun.
Program ini menyediakan empat operasi utama:
- Inisialisasi — menyiapkan registry global dengan pemilik dan penghitung sertifikat.
- Pencatatan sertifikat — mencatat sertifikat baru ke blockchain. Sistem menolak hash yang tidak valid dan data kosong, serta memakai aritmetika yang aman dari overflow saat menaikkan penghitung.
- Pencabutan sertifikat — mencabut sertifikat yang sudah diterbitkan. Hanya bisa dilakukan oleh penerbit asli atau pemilik registry, dan pencabutan ganda ditolak.
- Transfer kepemilikan — memindahkan kepemilikan registry ke alamat baru, dengan validasi yang menolak alamat tidak valid.
Saat pencatatan terjadi, program memvalidasi hash terlebih dahulu, lalu mengemisikan event yang berisi hash, data sertifikat, identitas penerbit, dan stempel waktu. Semua validasi ini berjalan on-chain, sehingga tidak ada pihak yang bisa mem-bypass aturan.
Satu detail operasional yang cerdas: SertiKu memakai backend wallet untuk membayar fee Solana. Artinya lembaga tidak perlu punya wallet atau membeli SOL untuk menerbitkan sertifikat — biaya transaksi ditanggung backend aplikasi. Ini menghilangkan hambatan adopsi terbesar untuk pengguna non-kripto, sambil tetap memberi mereka jaminan blockchain di balik layar. Konfigurasi backend-nya menunjukkan tim memikirkan manajemen saldo wallet secara eksplisit, termasuk batas minimum saldo dan alokasi biaya penyimpanan per sertifikat.
Untuk interaksi dari backend, tersedia perkakas pengujian yang bisa dijalankan melawan jaringan Solana devnet sebelum deployment ke production.
Pengujian di devnet sebelum production
Satu praktik yang layak ditiru: program Solana diuji dulu di devnet dengan skenario yang realistis. Pengujiannya mencakup inisialisasi registry, pencatatan sertifikat oleh penerbit yang sah, penolakan pencatatan oleh pihak tak berwenang, hingga pencabutan ganda yang harus gagal. Semua dijalankan melawan program yang benar-benar ter-deploy di devnet Solana, bukan sekadar mock lokal.
Pola ini penting karena bug di smart contract yang sudah ter-deploy jauh lebih mahal diperbaiki daripada bug di aplikasi web biasa. Program Solana memang bisa di-upgrade (kecuali dibuat immutable), tapi setiap upgrade butuh otorisasi dan bisa mengganggu integrasi yang sudah berjalan. Menguji alur otorisasi — siapa boleh mencatat, siapa boleh mencabut — di devnet sebelum menyentuh mainnet adalah standar minimum yang seharusnya tidak ditawar.
IPFS untuk metadata: kenapa tidak semuanya di blockchain?
Pertanyaan wajar: kalau blockchain sudah anti-rusak, kenapa masih butuh IPFS? Jawabannya soal ekonomi dan kepraktisan.
Menyimpan dokumen PDF lengkap atau JSON metadata besar di blockchain — di chain mana pun — itu mahal dan tidak efisien. Blockchain optimal untuk menyimpan bukti (hash, status, timestamp), bukan konten. SertiKu memisahkan keduanya: bukti di Solana, konten di IPFS via Pinata.
IPFS sendiri adalah jaringan penyimpanan content-addressed: file diakses lewat hash isinya (CID), bukan lewat lokasi server. Artinya file yang diambil dari IPFS bisa diverifikasi keasliannya secara independen — hash-nya harus cocok dengan yang tercatat di blockchain. Kalau tidak cocok, file-nya bukan yang asli. Pinata berperan sebagai pinning service yang memastikan file tetap tersedia di jaringan.
Dukungan IPFS di SertiKu bersifat opsional dan bisa diaktifkan sesuai kebutuhan deployment. Desain ini masuk akal: tidak semua deployment butuh desentralisasi penuh, tapi opsinya tersedia untuk yang butuh.
Lapisan keamanan: tidak mengandalkan blockchain saja
Satu hal yang SertiKu lakukan dengan benar: blockchain bukan satu-satunya lapisan keamanan. Platform ini menerapkan pertahanan berlapis:
- Autentikasi multi-metode — email/password, Google OAuth, dan login via wallet. Verifikasi email memakai kode OTP 6 digit.
- Anti-bot ganda — Google reCAPTCHA v2 dan Cloudflare Turnstile di form login dan registrasi.
- Integritas file — verifikasi SHA-256/MD5 setiap kali file sertifikat diperiksa.
- Peran berjenjang — User, Lembaga, Admin, dan Master dengan hak akses berbeda.
- Privasi — banner persetujuan cookie untuk kepatuhan regulasi.
Pembayaran juga fleksibel: Midtrans untuk pembayaran konvensional (IDR) dan NOWPayments untuk pembayaran kripto. Kombinasi ini relevan untuk pasar Indonesia — lembaga lokal bisa bayar pakai transfer bank/QRIS lewat Midtrans, sementara opsi kripto tersedia untuk pengguna internasional.
Fitur bulk upload CSV/Excel layak disorot karena menyentuh realitas operasional: lembaga pelatihan sering menerbitkan ratusan sertifikat sekaligus setelah satu angkatan lulus. Tanpa bulk upload, fitur blockchain-nya sehebat apa pun tidak akan dipakai.
Pelajaran desain untuk developer
Terlepas dari apakah kamu membangun platform sertifikat atau bukan, ada beberapa pola dari SertiKu yang layak dibawa pulang:
- Pisahkan bukti dari konten. Simpan hash dan status di blockchain, konten di storage murah (IPFS, object storage). Ini pola universal untuk aplikasi yang butuh integritas tanpa membayar mahal.
- Event lebih murah daripada state. Di Solana, emisikan data lewat event kalau data itu hanya perlu dibaca, bukan diubah. Di EVM, log punya peran serupa.
- Sembunyikan kompleksitas wallet dari pengguna. Backend wallet yang menanggung fee membuat UX setara aplikasi web biasa, sementara jaminan blockchain tetap ada. Pola ini juga dipakai banyak aplikasi Web3 mainstream.
- Buat verifikasi tanpa akun. Setiap langkah pendaftaran yang dihapus dari alur verifikasi melipatgandakan kemungkinan orang benar-benar memverifikasi.
- Dukung migrasi chain sejak awal. Desain yang memisahkan lapisan blockchain dari logika aplikasi membuat SertiKu bisa pindah dari Polygon ke Solana tanpa menulis ulang seluruh aplikasi. Kalau kamu membangun integrasi blockchain hari ini, rancang untuk kemungkinan pindah besok.
Topik terkait yang sudah dibahas di blog ini: prinsip desain REST API untuk merancang endpoint verifikasi yang bersih, dan panduan MCP kalau kamu ingin mengekspos data sertifikat ke AI agent.
FAQ
Apakah SertiKu masih memakai Polygon?
Dukungan untuk jaringan Polygon masih tersedia, tapi pengembangan aktif sudah pindah ke Solana dengan program Anchor yang baru. Migrasi ini memetakan ulang setiap komponen dari smart contract aslinya ke arsitektur Solana.
Berapa biaya mencatat satu sertifikat di Solana?
Programnya dirancang hemat: setiap sertifikat hanya memakai satu akun PDA kecil berisi tiga informasi (status keberadaan, status pencabutan, identitas penerbit), sementara data lengkapnya diemisikan sebagai event yang tidak butuh rent. Konfigurasi default mencadangkan sekitar 0.0011832 SOL untuk rent akun sertifikat. Biaya aktual tergantung kondisi jaringan Solana saat transaksi dikirim.
Apakah penerima sertifikat harus punya wallet kripto?
Tidak. SertiKu memakai backend wallet — biaya transaksi blockchain ditanggung oleh backend aplikasi, bukan oleh lembaga penerbit atau penerima. Penerima cukup menerima PDF sertifikat dan membagikannya seperti biasa.
Bagaimana kalau lembaga penerbit tutup?
Inilah keunggulan arsitektur desentralisasi: bukti penerbitan tercatat di blockchain Solana dan metadata di IPFS, keduanya independen dari server SertiKu. Selama jaringan Solana dan IPFS berjalan, sertifikat tetap bisa diverifikasi lewat hash-nya.
Apakah QR Code-nya bisa dipalsukan?
QR Code hanyalah pembawa hash — yang menentukan keaslian adalah catatan di blockchain. Memalsukan QR Code untuk menunjuk ke hash yang tidak tercatat hanya menghasilkan halaman "tidak valid". Satu-satunya cara membuat sertifikat palsu yang lolos verifikasi adalah mengendalikan private key penerbit, yang berada di luar jangkauan QR Code.
Kesimpulan
SertiKu menunjukkan cara yang pragmatis menggabungkan teknologi desentralisasi dengan kebutuhan dunia nyata. Blockchain Solana memberi jaminan integritas yang tidak bisa ditawarkan database biasa; IPFS memastikan dokumen tetap aksesibel; QR Code membuat verifikasi bisa dilakukan siapa saja dalam hitungan detik. Dan semua kompleksitas Web3 disembunyikan di balik UX aplikasi web biasa — keputusan desain yang tepat untuk target pengguna non-teknis.
Pola intinya bisa diringkas dalam satu kalimat: bukti di blockchain, konten di storage desentralisasi, verifikasi tanpa akun. Kalau kamu merancang sistem yang butuh kepercayaan tanpa perantara — ijazah, lisensi, sertifikasi profesi — pola ini layak jadi titik awal.
Untuk memahami fondasi API di balik endpoint verifikasi seperti ini, baca juga panduan desain REST API. Dan kalau kamu tertarik mengekspos data terverifikasi ke AI agent, panduan MCP membahas protokol standarnya. Untuk konteks bagaimana data tidak terstruktur disimpan dan dicari, panduan RAG membahas pola retrieval yang relevan.


