Catatan waktu garap kerjaan teknis online: kenapa daftar periksa penilaian sebaiknya dikunci di depan sebelum mulai

Rizky Pratama — Sun, 25 Oct 2026 10:10:11 +0000

Halo teman-teman di #indonesia, beberapa minggu terakhir saya sempat ngobrol sama beberapa rekan developer di Jakarta yang sering ambil kerjaan sampingan jarak jauh — mulai dari bikin skrip backend, rapihin alur data, sampai nulis dokumentasi API. Hampir semuanya pernah ngalamin satu kejadian yang polanya mirip banget: waktu tugas baru disepakati di awal, deskripsi permintaannya cuma ditulis singkat tiga atau empat baris. Pas kita tanya apakah ada format khusus yang harus diikuti, jawabannya selalu terdengar santai, "bebas kok mas, yang penting jalan dan jelas." Tapi begitu hasil kerjaan diserahkan, tiba-tiba muncul daftar koreksi panjang soal hal-hal yang sejak awal sama sekali nggak pernah disebut. Kalau sudah begitu, mau debat juga percuma karena patokan tertulisnya memang nggak pernah dikunci sebelum pekerjaan dimulai.

Dari pengalaman itu saya makin sadar kalau masalah utama di kesepakatan kerja teknis sebenarnya jarang soal tempat penyimpanan dananya, melainkan soal urutan waktu perumusan kriteria serah-terimanya. Rekening bersama atau escrow biasa memang bisa menahan uang, tapi selama definisi tentang apa yang bikin sebuah hasil kerja dianggap selesai baru dikarang belakangan setelah berkas dikirim, posisi orang yang mengerjakan tetap saja rawan digantung.

Gara-gara penasaran sama desain sistem yang mencoba membalik urutan tersebut, belakangan ini saya nyempetin waktu buat ngulik mekanisme yang dipakai protokol Verdikta di jaringan Base (https://bounties.verdikta.org). Hal yang menurut saya paling menarik dari kacamata teknis justru aturan utamanya yang mengharuskan rubrik penilaian dipublikasikan lebih dulu ke IPFS dan diikat langsung ke kontrak pintar bersamaan saat dana dikunci di escrow Base. Di dalam dokumen rubrik itu sudah dipisah secara terbuka bagian mana yang jadi syarat gerbang wajib lulus, bagian mana yang merupakan kriteria kualitas dengan bobot persentase tertentu, serta berapa angka skor ambang batas supaya kiriman dianggap sah. Karena rubriknya sudah terikat di on-chain sejak awal, syarat penilaiannya nggak bisa lagi digeser-geser sepihak di tengah jalan.

Waktu saya pelajari bagaimana kiriman pekerjaan diperiksa di sana, prosesnya juga nggak diserahkan ke mood satu orang, melainkan dijalankan oleh panel juri AI independen yang terdiri dari beberapa model berbeda. Bukannya cuma mengeluarkan vonis lolos atau gagal tanpa penjelasan, setiap kriteria di dalam rubrik diberi skor angka masing-masing lengkap dengan catatan alasan evaluasinya yang tercatat terbuka dan bisa diaudit siapa saja. Jadi kalau sebuah kiriman belum tembus ambang batas, kita bisa lihat persis di kriteria mana nilainya kurang dan berapa poin selisihnya. Aturan pencairannya juga lugas: kiriman pertama yang skor gabungannya berhasil melewati ambang batas langsung otomatis menerima dana escrow dari kontrak pintar, sedangkan kalau sampai tenggat waktu habis belum ada yang lolos, dananya kembali utuh ke pembuat tugas. Dari sisi biaya, protokolnya sendiri nggak memotong komisi platform (0% biaya platform), dan pengirim hanya perlu menyiapkan biaya gas Base serta deposit kecil sekitar 0.00024 ETH untuk membiayai putaran evaluasi orakel.

Walaupun alur seperti ini terasa jauh lebih terukur, menurut saya kita tetap harus jujur melihat batasannya di lapangan. Panel model AI pada dasarnya cuma bisa memeriksa apa yang dikirim dalam bentuk berkas, kode sumber, teks, atau tangkapan layar digital yang bisa diakses lewat jaringan, sehingga pendekatan ini jelas nggak bisa dipakai kalau tugasnya menuntut pengecekan perangkat keras fisik di dunia nyata. Selain itu, titik krusialnya pindah ke ketelitian orang yang menyusun rubrik di awal: kalau kalimat kriterianya ditulis terlalu kabur atau bobotnya nggak seimbang, skor yang keluar dari model AI juga bakal ikut timpang walaupun seluruh prosesnya transparan, apalagi rubrik yang sudah terkunci di kontrak nggak bisa diedit lagi. Belum lagi sifat kontrak pintar yang kaku terhadap angka ambang batas, di mana hasil kerja yang sebenarnya sudah rapi tapi kurang satu poin saja dari syarat kelulusan tetap bakal ditolak otomatis tanpa ruang tawar-menawar.

Terlepas dari keterbatasan tadi, kebiasaan mengunci tolok ukur penilaian di depan dan membuka alasan skor per kriteria menurut saya jauh lebih sehat daripada penolakan sepihak dengan alasan "kurang cocok." Buat teman-teman developer di komunitas #indonesia yang sering garap proyek lepas atau ngulik smart contract, menurut kalian apakah rubrik yang dikunci kaku di awal seperti ini bikin kerjaan jadi lebih tenang, atau malah terasa terlalu membatasi ruang diskusi teknis?

Tips Optimasi RPC dan Manajemen Nonce di Base L2 pake Node.js buat Developer Indonesia

Rizky Pratama — Sun, 25 Oct 2026 02:11:34 +0000

Halo rekan-rekan developer Indonesia! Belakangan ini gw lagi sering ngoprek script backend pake Node.js buat interaksi langsung sama jaringan Layer-2 terutama Base. Salah satu masalah yang paling sering kejadian waktu kita kirim beberapa transaksi beruntun dari satu wallet adalah error replacement transaction underpriced atau nonce too low gara-gara node RPC publik belum sempet sinkronisasi state mempool terbaru.

Buat ngatasin masalah ini tanpa harus sewa dedicated node yang mahal, ada tiga pendekatan praktis yang biasa gw terapin di project:

Tracking Nonce Lokal di Memori: Jangan panggil eth_getTransactionCount pake parameter latest setiap kali mau kirim transaksi baru dalam loop cepat. Ambil sekali di awal menggunakan parameter pending, lalu increment secara lokal di variabel aplikasi sambil tetep nyiapin mekanisme fallback reset kalo ada transaksi yang revert.
Buffer Gas Price 15–25%: Di jaringan L2 yang pake OP Stack kayak Base, biaya gas dasarnya memang sangat murah (sering di bawah 0.01 gwei), tapi fluktuasi kecil di base fee blok berikutnya bisa bikin transaksi nyangkut beberapa detik. Menambahkan buffer sekitar 20 persen di atas nilai eth_gasPrice saat ini hampir gak kerasa di biaya (tetep di bawah satu sen dolar), tapi bikin transaksi langsung masuk di blok berikutnya.
Polling Receipt dengan Exponential Backoff: Hindari melakukan spam request eth_getTransactionReceipt setiap 200ms karena bakal cepet kena rate-limit dari endpoint publik. Interval 2 detik udah sangat ideal karena block time di Base memang 2 detik.

Semoga catatan singkat ini bermanfaat buat teman-teman di komunitas developer Indonesia yang lagi bangun aplikasi atau automasi on-chain. Kalo ada yang punya trik lain buat handle failover multi-RPC, boleh banget diskusi di kolom komentar!

DEV Community: Rizky Pratama

Catatan waktu garap kerjaan teknis online: kenapa daftar periksa penilaian sebaiknya dikunci di depan sebelum mulai

Tips Optimasi RPC dan Manajemen Nonce di Base L2 pake Node.js buat Developer Indonesia