Ringkasan

Selamat datang di seri “Crypto Tragedy of the Commons” dari GCC Research.

Dalam seri ini, kami menyoroti barang publik utama dalam blockchain—sebagai elemen fundamental ekosistem kripto yang kini cenderung menjauh dari akar desentralisasinya. Barang-barang ini menjadi fondasi Web3, namun kerap menghadapi kekurangan insentif, tantangan tata kelola, dan risiko sentralisasi. Ketimpangan antara ideal desentralisasi kripto dengan kebutuhan redundansi yang kokoh demi stabilitas nyata kini semakin terasa.

Edisi kali ini menyoroti salah satu aplikasi paling menonjol di ekosistem Ethereum: Polymarket beserta perangkat pengindeks datanya. Sejak awal tahun, berbagai kontroversi—dari manipulasi oracle terkait peluang elektoral Trump, taruhan logam tanah jarang Ukraina, hingga spekulasi politik soal warna jas Zelensky—berulang kali membawa Polymarket ke pusat perhatian. Skala besar dan pengaruh dana yang terlibat membuat perselisihan ini tak dapat diabaikan.

Lantas, apakah “pasar prediksi terdesentralisasi” andalan ini benar-benar telah mewujudkan desentralisasi pada lapisan paling penting—yakni pengindeksan data? Mengapa infrastruktur terdesentralisasi seperti The Graph masih gagal memenuhi harapan? Seperti apa solusi pengindeksan data publik yang benar-benar fungsional dan berkelanjutan?

I. Efek Domino dari Gangguan Platform Data Terpusat

Pada Juli 2024, Goldsky—platform infrastruktur data blockchain real-time untuk pengembang Web3 yang menawarkan layanan pengindeksan, subgraph, dan streaming data—mengalami gangguan selama enam jam. Akibatnya, sebagian besar ekosistem Ethereum terdampak: frontend DeFi gagal menampilkan posisi dan saldo pengguna, pasar prediksi seperti Polymarket tidak bisa menyajikan data yang benar, dan antarmuka berbagai proyek menjadi tidak dapat digunakan dari perspektif pengguna.

Padahal, inilah yang seharusnya dihindari oleh aplikasi terdesentralisasi. Sebab motivasi utama desain blockchain adalah menghapus titik kegagalan tunggal. Insiden Goldsky menyoroti kenyataan pahit: meski blockchain didesain untuk desentralisasi, infrastruktur yang menopang aplikasi on-chain justru masih sangat terpusat.

Permasalahan mendasar terletak pada pengindeksan dan pengambilan data blockchain yang merupakan barang publik digital—tidak bisa dikecualikan dan tidak bersaing—namun pengguna mengharapkan akses gratis atau nyaris gratis. Tetapi, membangun infrastruktur ini butuh investasi berkelanjutan untuk perangkat keras, penyimpanan, bandwidth, dan rekayasa. Tanpa model pendanaan yang berkelanjutan, sektor ini cenderung ke kompetisi winner-take-all: setelah satu penyedia memiliki keunggulan kecepatan dan modal, seluruh permintaan pengembang dialihkan ke penyedia tersebut, memunculkan titik ketergantungan baru. Gitcoin dan organisasi nirlaba lain telah berulang kali menyoroti bahwa “infrastruktur open-source menciptakan nilai miliaran, tetapi penciptanya sering kali tidak mampu menanggung kebutuhan hidupnya sendiri.”

Kesimpulannya jelas: dunia desentralisasi membutuhkan upaya serius—dengan pendanaan barang publik, redistribusi insentif, atau model berbasis komunitas—untuk mendiversifikasi infrastruktur Web3 dan menghindari bentuk sentralisasi baru. Kami mendorong para pengembang DApp untuk menerapkan pendekatan local-first, serta komunitas teknis agar merancang DApp yang tetap tangguh saat terjadi kegagalan pengambilan data—sehingga pengguna tetap dapat berinteraksi meski indexer offline.

II. Dari Mana Sebenarnya Data DApp Anda Berasal?

Untuk memahami insiden seperti gangguan Goldsky, kita perlu menelusuri lebih dalam cara kerja DApp. Sebagian besar pengguna hanya mengenal dua komponen: kontrak on-chain dan antarmuka frontend. Mereka terbiasa memeriksa status transaksi di Etherscan, mengakses informasi di frontend, dan berinteraksi dengan kontrak melalui UI. Namun, dari mana sebetulnya frontend memperoleh datanya?

Peran Kritis Layanan Pengambilan Data

Bayangkan Anda membangun protokol peminjaman yang menampilkan posisi, margin, dan utang pengguna. Implementasi sederhana akan membuat frontend langsung mengambil data dari blockchain. Namun, sebagian besar kontrak hanya memungkinkan query posisi berdasarkan ID, bukan seluruh posisi berdasarkan alamat pengguna. Jadi, untuk menampilkan posisi pengguna, Anda harus menarik seluruh posisi terbuka dan memilah satu per satu—ibarat mencari manual di jutaan entri ledger. Secara teknis mungkin, tapi sangat lambat dan tidak efisien. Bahkan bila dijalankan di server backend, proyek DeFi berskala besar bisa menghabiskan waktu berjam-jam untuk menarik data ini dari node lokal.

Pada titik ini, infrastruktur khusus sangat penting. Penyedia seperti Goldsky menghadirkan layanan pengindeksan data yang secara drastis mempercepat akses. Gambar berikut mengilustrasikan ragam data yang difasilitasi layanan ini untuk aplikasi.

Beberapa pembaca mungkin bertanya: Bukankah The Graph menawarkan pengambilan data terdesentralisasi untuk Ethereum? Bagaimana perbandingannya dengan Goldsky—dan mengapa banyak proyek DeFi lebih memilih Goldsky daripada The Graph?

Hubungan The Graph, Goldsky, dan SubGraph

Untuk memperjelasnya, berikut penjelasan mengenai konsep teknis inti:

• SubGraph adalah framework pengembangan yang memungkinkan tim untuk menulis kode guna membaca dan mengagregasi data on-chain untuk tampilan di frontend.
• The Graph merupakan platform pengambilan data terdesentralisasi yang menciptakan framework SubGraph menggunakan AssemblyScript. Pengembang memanfaatkan SubGraph untuk menangkap event kontrak dan menuliskannya ke database, kemudian dapat diakses melalui GraphQL atau SQL.
• Penyedia layanan yang menjalankan SubGraph disebut operator SubGraph. Baik The Graph maupun Goldsky berperan sebagai penyedia hosting untuk proyek SubGraph, sebab kode SubGraph harus tetap dijalankan di server. Berikut cuplikan dokumentasi Goldsky:

Mengapa ada banyak operator SubGraph?

Sebab framework ini hanya mengatur cara mengambil data dari blok dan menuliskannya ke database—tanpa menentukan secara pasti mekanisme aliran atau keluaran data. Masing-masing operator mengimplementasikan detailnya secara independen.

Operator dapat membuat modifikasi node khusus dan optimasi kinerja. Kini, The Graph memakai Firehouse untuk pengindeksan cepat; runtime inti SubGraph Goldsky masih bersifat closed source.

Pada dasarnya, The Graph adalah pusat terdesentralisasi bagi operator SubGraph. Contohnya, subgraph Uniswap v3 didukung banyak operator, sehingga The Graph menjadi marketplace kolektif tempat pengguna mengajukan kode SubGraph dan beberapa operator dapat melayani pengambilan data.

Model Harga Goldsky

Goldsky, sebagai layanan SaaS terpusat, menggunakan model pembayaran berdasarkan sumber daya yang digunakan. Sebagian besar engineer telah mengenal skema ini. Berikut adalah kalkulator harga Goldsky:

Model Harga The Graph

Model harga The Graph berbeda: biaya query dan insentif ditanamkan dalam tokenomik GRT. Berikut ringkasannya:

• Setiap query ke SubGraph membagi biaya: 1% GRT dibakar; 10% masuk pool kurator (biasanya pengembang); sekitar 89% diberikan ke Indexer dan Delegator sesuai algoritme.
• Indexer wajib staking setidaknya 100.000 GRT agar dapat berpartisipasi dan akan dikenakan penalti jika hasil query tidak valid. Delegator melakukan staking GRT ke Indexer agar mendapatkan porsi reward 89% tersebut.
• Kurator (umumnya pengembang) melakukan signal dengan staking GRT pada bonding curve untuk SubGraph mereka. Semakin besar staking, semakin banyak sumber daya Indexer yang tertarik. Komunitas menyarankan staking 5.000–10.000 GRT agar SubGraph diindeks secara konsisten.

Biaya Query:

Untuk menggunakan The Graph, developer harus mendaftar API key dan prabayar GRT, biaya dihitung per permintaan.

Biaya Staking Signal:

Untuk mengindeks SubGraph, developer perlu staking GRT guna “signal” value sehingga operator tertarik. Baru setelah GRT terkumpul (misal 10.000) Indexer akan mengambil SubGraph untuk produksi.

Saat pengujian, SubGraph bisa dideploy gratis lewat staging operator The Graph, namun ini bukan untuk produksi. Untuk produksi, SubGraph harus dipublikasikan ke jaringan, dan Indexer secara sukarela memilih SubGraph terbaik berdasarkan signal staking.

Mengapa Developer (dan Akuntan) Tidak Menyukai Harga Berbasis Token

Bagi banyak proyek, alur kerja The Graph terasa membingungkan. Meskipun pembelian GRT sederhana bagi tim Web3, proses kurasi berlangsung lama dan penuh ketidakpastian. Masalah utama:

• Ketidakpastian: Developer sulit menemukan acuan berapa banyak GRT yang perlu di-stake maupun durasi sampai Indexer mulai mengindeks SubGraph mereka.
• Kebingungan Akuntansi: Harga berbasis tokenomik menyulitkan pelacakan biaya, sehingga perusahaan dan akuntan kesulitan mengklasifikasikan pengeluaran.

“Apakah Sentralisasi Memang Lebih Mudah?”

Bagi kebanyakan developer, Goldsky lebih mudah: harganya transparan, layanan langsung aktif setelah pembayaran, dan minim ketidakpastian. Karena itu, ketergantungan pada satu penyedia pengindeks data di Web3 sangat tinggi.

Tokenomik GRT di The Graph mungkin berangkat dari niat baik, namun kompleksitasnya membuat pengguna berpaling dan seharusnya tidak dibebankan ke end-user—khususnya staking kurasi, yang selayaknya dapat disederhanakan lewat antarmuka pembayaran langsung.

Bukan cuma pendapat pribadi: Paul Razvan Berg, engineer smart contract ternama dan pencipta Sablier, secara terbuka mengkritik pengalaman publikasi SubGraph serta pembayaran GRT sebagai sangat buruk.

III. Solusi yang Ada untuk Gangguan Data Indexer

Bagaimana ekosistem merespons titik kegagalan tunggal pada pengindeksan data? Sudah dijelaskan, developer dapat menggunakan The Graph, tapi harus siap menghadapi proses staking GRT dan kurasi untuk membayar penggunaan API.

Pada ekosistem EVM terdapat banyak alternatif pengindeksan data. Referensi bermanfaat: Dune: The State of EVM Indexing, rindexer: EVM Indexing Tools Overview, serta thread terbaru ini.

Artikel ini tidak akan mengulas akar teknis insiden Goldsky; menurut laporan insiden mereka, Goldsky hanya berbagi detail dengan klien enterprise. Laporan menyebutkan masalah terjadi ketika proses penulisan data indeks ke database, dan akses database baru pulih setelah kolaborasi dengan AWS.

Berikut pendekatan lain yang bisa dipertimbangkan:

• ponder adalah alat pengindeksan data yang sederhana, ramah developer, dan mudah dideploy. Developer bisa melakukan self-host pada infrastruktur mereka sendiri.
• local-first adalah filosofi pengembangan yang mengusulkan agar DApp tetap dapat digunakan meski tanpa koneksi jaringan. Dalam ranah blockchain, artinya pengalaman pengguna tetap optimal selama bisa terhubung ke chain—meskipun indexer offline.

Ponder: DIY Data Indexing

Mengapa ponder direkomendasikan?

• Tidak terikat vendor: awalnya dikembangkan developer independen, ponder hanya membutuhkan endpoint Ethereum RPC dan database Postgres—tanpa keterlibatan layanan terkelola.
• Pengalaman developer luar biasa: dibangun dengan TypeScript menggunakan pustaka Viem, ponder sangat mudah digunakan (penulis telah memakainya secara luas).
• Kinerja sangat baik.

Ada kekurangan: ponder berkembang pesat, sehingga perubahan mayor kadang mengganggu deployment lama. Untuk informasi teknis dan best practice, tinjau dokumentasi resmi.

Menariknya, baru-baru ini ponder mulai dikomersialkan sesuai dengan “teori separasi” yang diulas pada artikel sebelumnya.

Intinya: Barang publik memberi manfaat untuk semua, namun jika dipungut biaya, kesejahteraan sosial bisa menurun karena pengguna marginal tersisih (tidak Pareto optimal). Harga berbeda secara teori bisa memaksimalkan surplus, namun implementasinya mahal dan rumit. Teori separasi menyarankan segmentasi subkelompok homogen, menagih biaya hanya pada mereka, sementara sisanya tetap gratis.

Penerapan konkret pada ponder:

• Deploy membutuhkan kemampuan teknis—developer wajib mengatur dependency eksternal (endpoint RPC, database).
• Pemeliharaan rutin diperlukan (misal, menggunakan proxy untuk load balancing dan memastikan pengambilan data berjalan mulus). Ini bisa cukup menantang bagi sejumlah developer.
• Ponder kini menawarkan beta deployment otomatis melalui Marble: pengguna cukup mengirim kode ke platform untuk deployment instan.

Pendekatan ini “memisahkan” mereka yang ingin solusi praktis—mereka membayar layanan hosted Marble—sementara pengguna self-host tetap bisa memakai ponder gratis.

Penggunaan ponder vs Goldsky:

• Alat self-host yang benar-benar permissionless seperti ponder sangat populer di proyek kecil yang menginginkan fleksibilitas dan otonomi.
• Proyek berskala besar dengan tuntutan performa tinggi lebih memilih layanan terkelola seperti Goldsky yang menawarkan ketersediaan dan redundansi lebih baik.

Kedua model mengandung risiko. Gangguan Goldsky membuktikan bahwa setiap pengembang perlu mempertimbangkan memelihara indexer ponder sendiri sebagai rencana cadangan. Saat menggunakan ponder, validasi data RPC juga patut diperhatikan—safe sempat melaporkan insiden data RPC tidak valid yang menyebabkan indexer crash. Tidak ada bukti pasti gangguan Goldsky terjadi karena masalah RPC, namun faktor ini tetap perlu diwaspadai.

Paradigma Pengembangan Local-First

Konsep local-first semakin banyak dibahas dalam beberapa tahun terakhir. Pada intinya, local-first menuntut:

• Ketersediaan offline
• Kolaborasi lintas klien

Mayoritas diskusi teknis local-first menyinggung CRDT (Conflict-free Replicated Data Types)—struktur data dengan resolusi konflik otomatis untuk editing terdistribusi. Praktisnya, CRDT adalah protokol konsensus ringan untuk menjaga konsistensi data di berbagai perangkat.

Dalam konteks pengembangan blockchain, persyaratan dapat dilonggarkan: target utama adalah menjamin pengguna tetap bisa mengakses minimal fitur meski backend indexer offline, sebab blockchain secara inheren sudah menyediakan konsistensi lintas klien.

Secara praktik, DApp local-first dapat:

• Menyimpan informasi penting secara lokal—seperti saldo atau posisi—agar pengguna tetap dapat melihat status terakhir meski indexer sedang mati.
• Degradasi fungsi dengan baik—mengambil data utama langsung dari RPC saat indexer tidak tersedia, sehingga pengguna tetap dapat mengakses sebagian data on-chain secara real-time.

Pendekatan ini sangat meningkatkan ketahanan aplikasi. Dalam skenario ideal, DApp local-first terbaik adalah yang membolehkan pengguna menjalankan node lokal sendiri dan query data menggunakan alat seperti TrueBlocks. Bacaan tambahan tentang pengindeksan terdesentralisasi dan lokal dapat dilihat pada thread Literally no one cares about decentralized frontends and indexers.

IV. Kesimpulan

Gangguan Goldsky selama enam jam menjadi peringatan serius bagi seluruh ekosistem Web3. Meski blockchain telah didesain terdesentralisasi dan tangguh, pada tataran aplikasi, mayoritas proyek masih sangat bergantung pada infrastruktur data terpusat—menciptakan risiko sistemik baru.

Artikel ini telah membedah mengapa The Graph—meski sangat dihargai—kesulitan diadopsi akibat kerumitan tokenomik GRT dan hambatan bagi pengembang. Kami juga membahas strategi membangun pengindeksan data yang tangguh, mendorong pengembang untuk menggunakan framework self-host seperti ponder sebagai backup sekaligus menyoroti jalur komersialisasi inovatif ponder. Terakhir, kami mengulas paradigma local-first, mengajak pengembang DApp menjamin aplikasi tetap usable walaupun indexer sedang gagal.

Semakin banyak pengembang Web3 yang menyadari bahwa titik kegagalan tunggal pada pengindeksan data adalah kerentanan kritikal. GCC mendorong komunitas untuk memusatkan perhatian pada tantangan infrastruktur ini, dan bereksperimen dengan indexer data terdesentralisasi maupun merancang framework agar frontend DApp tetap berjalan walau indexer offline.

Disclaimer:

1. Diterbitkan ulang dari TechFlow. Hak cipta tetap milik penulis asli, shew. Jika Anda keberatan dengan publikasi ulang ini, silakan hubungi tim Gate Learn untuk penyelesaian.
2. Disclaimer: Pandangan dan opini yang diungkapkan dalam artikel ini sepenuhnya milik penulis dan bukan merupakan nasihat investasi.
3. Terjemahan oleh tim Gate Learn tidak boleh disalin, didistribusikan, atau dijiplak tanpa atribusi yang jelas ke Gate.com.