Mengapa Web3 tidak bisa membaca — ForkLog

# Почему Web3 не умеет читать

Beberapa tahun lalu, industri masih memperdebatkan cara meningkatkan throughput blockchain. Hari ini, banyak jaringan sudah mampu memproses puluhan ribu transaksi, dan sebagian mengklaim bisa mencapai ratusan ribu. Namun ternyata menulis data ke blockchain hanyalah separuh pekerjaan. Data itu masih perlu ditemukan, diindeks, diverifikasi, dan disampaikan ke aplikasi.

Karena itulah kecepatan generasi data di beberapa tempat mulai melampaui kemampuan infrastruktur untuk memprosesnya. Bagaimana blockchain berubah dalam situasi ini—ForkLog telah mengulasnya.

Чем быстрее, тем дольше

Sekitar sepuluh tahun lalu, perkembangan blockchain digambarkan melalui apa yang disebut sebagai trilemma skalabilitas. Menurut konsep ini, jaringan dipaksa mencari kompromi antara keamanan, desentralisasi, dan performa. Namun pada tahun 2026, menjadi jelas bahwa meski masalah throughput bisa diatasi sebagian, muncul tantangan baru.

Blockchain itu sendiri tidak memiliki antarmuka pengguna. Peran ini diambil oleh berbagai aplikasi. Dan mereka, pada gilirannya, harus terus-menerus mendapatkan data:

• saldo alamat;
• riwayat transaksi;
• status smart contract;
• event dan log;
• analitik pasar;
• data untuk manajemen risiko;
• pesan lintas-jaringan.

Semakin cepat jaringan bekerja, semakin banyak data serupa yang harus diproses

Di kalangan pengguna, ada kesalahpahaman yang umum: jika informasi ditulis ke blockchain, berarti informasi itu tinggal diambil saja. Faktanya justru sebaliknya. Membaca data mentah langsung dari blockchain secara real time adalah proses yang lambat, mahal, dan rumit secara teknis. Di ekosistem Web3, lapisan infrastruktur perantara yang menghubungkan dompet dengan aplikasi dapp sangat lazim.

Misalnya, aplikasi dompet agar pengguna melihat saldo mereka dalam hitungan sepersekian detik, akan menghubungi penyedia RPC, pengindeks, platform analitik, server cache, basis data khusus, dan sebagainya.

Prosesnya berjalan seperti ini:

1. Pengumpulan data: Program khusus secara terus-menerus “membaca” blockchain saat blok-blok baru muncul.
2. Indeksasi (strukturisasi): Mereka mem-parse data ini dan menyusunnya ke basis data klasik yang sangat cepat (misalnya PostgreSQL atau ClickHouse). Di sana data itu sudah terstruktur dalam bentuk yang nyaman: “Alamat — Daftar semua token miliknya”.
3. Respons instan: Dompet menerima respons yang sudah jadi dan sudah difilter dari cache dalam hitungan milidetik.

Faktanya, sebagian besar aplikasi Web3 populer bekerja melalui lapisan pemrosesan informasi tambahan. Bayangkan jika blockchain memproses 50.000 operasi per detik, dan jutaan dompet secara bersamaan mengirim permintaan RPC untuk memperbarui layar. Server-server penyedia tidak mampu menanggung beban seperti itu. Membaca, mengindeks, dan mengurutkan data untuk pengguna adalah tugas komputasi yang paling sulit. Pengindeks dan layanan akses data sering tertinggal dari kondisi terbaru jaringan beberapa blok, karena pemrosesan, strukturisasi, dan pengiriman data membutuhkan waktu tambahan. Dan ini bukan cuma soal “infrastruktur yang ketinggalan”, meskipun tentu ada juga. Melainkan tentang konflik mendasar antara arsitektur Web2 dan Web3

Pengguna dan aplikasi berkomunikasi dengan blockchain seaktif dan sesering internet biasa yang memberikan respons instan. Saat Anda menggulir feed media sosial, aplikasi membuat ribuan permintaan per detik ke server untuk memperbarui like, komentar, dan gambar. Bot perdagangan di Web2 bisa menanyai server bursa jutaan kali per menit. Server Google atau Amazon dengan mudah mampu menahannya, karena mereka tersentralisasi: data pada dasarnya tersimpan dalam satu basis data besar yang bisa langsung disalin ke ribuan server mirror di seluruh dunia.

Blockchain bekerja secara berbeda, dan tidak “siap” untuk hal-hal seperti itu secara perangkat keras. Hingga belum lama, hambatan utama kecepatan di blockchain adalah matematika dan kriptografi. Harus dipastikan ribuan komputer di seluruh dunia cepat menyepakati (konsensus) bahwa sebuah transaksi itu valid. Para pengembang menyelesaikan masalah ini dengan “mengajari” mesin untuk menjalankan eksekusi paralel dan memisahkan konsensus dari eksekusi. Misalnya, Solana, Monad, dan Aptos mendukung eksekusi paralel untuk transaksi-transaksi independen—berbeda dari model klasik berurutan milik Ethereum. Pada Monad, pemisahan urutan persetujuan transaksi dan eksekusinya tampak terutama jelas, sedangkan di Solana dan Aptos, paralelisme diterapkan lewat arsitektur runtime dan manajemen konflik berdasarkan status.

Pada akhirnya, dimungkinkan untuk menyetujui puluhan ribu transaksi per detik (TPS). Namun di sinilah jebakannya.

Secara historis, blockchain menjalankan sekaligus empat fungsi:

• eksekusi transaksi;
• konsensus;
• penyimpanan data;
• penyediaan akses ke data.

Kenaikan performa sekaligus meningkatkan beban pada keempat fungsi tersebut. Sistem mulai menghasilkan data lebih cepat daripada infrastruktur yang bisa membacanya, sehingga muncul apa yang disebut indexer gap.

Di dokumentasi Helius—salah satu penyedia infrastruktur terbesar di ekosistem Solana—secara terang menyatakan bahwa struktur blockchain yang berurutan cocok untuk menjaga integritas data dan throughput yang tinggi, tetapi membuat permintaan historis menjadi lambat dan tidak efisien. Karena itu, kebanyakan perusahaan terpaksa membangun pengindeks mereka sendiri dan basis data terpisah di atas blockchain.

Analis ChainScore Labs menyebut indexer gap sebagai salah satu masalah kunci ekosistem Solana. Menurut penilaian mereka, pendekatan indeksasi tradisional tidak bekerja dengan baik untuk arsitektur jaringan yang memiliki frekuensi blok tinggi dan eksekusi transaksi paralel, yang menciptakan arus data yang sangat besar.

Hasilnya adalah efek seperti ini: jaringan bisa mengonfirmasi operasi hampir seketika, tetapi aplikasi membutuhkan waktu jauh lebih lama untuk memproses dampak dari operasi-operasi tersebut.

Скорости Web3 уперлись в банальную физику (и не только)

Lebih tepatnya—pada throughput prosesor, hard disk, dan kabel jaringan. Ternyata skalabilitas blockchain tidak sama dengan skalabilitas infrastruktur di sekelilingnya. Dan ini harus ditangani secepat mungkin

Bayangkan sebuah jaringan dengan 100.000 TPS. Tidak hanya perlu menulis transaksi, tetapi juga:

• menyimpan status;
• memperbarui indeks;
• menjawab permintaan dompet;
• melayani bot;
• melayani analis;
• melayani mesin pencari;
• melayani agen AI.

Karena itu, throughput yang tinggi menciptakan kompetisi sumber daya antara konsensus, eksekusi transaksi, dan layanan infrastruktur di atas jaringan.

Perkembangan paralel beberapa teknologi yang terlibat memaksa masalah ini ditangani sejak sekarang. Untuk manusia, penundaan dalam hitungan detik atau bahkan menit masih bisa ditoleransi. Untuk agen AI, sistem perdagangan, dan layanan otonom—tidak. Jika sebuah mesin mengambil keputusan berdasarkan data on-chain, maka informasi yang kedaluwarsa berarti kesalahan, hilangnya peluang, atau bahkan kerugian finansial langsung.

Sementara itu, Ethereum Foundation dalam dokumentasi terbarunya untuk tahun 2026 menyatakan bahwa node arsip membutuhkan ruang disk dari 3 hingga 12 TB, dan sinkronisasi awal bisa memakan waktu hingga satu bulan bahkan pada perangkat yang cukup kuat. Batasannya adalah kecepatan SSD, kapasitas memori, dan performa prosesor.

Lebih dari itu, pengembang Geth juga menjelaskan model lama penyimpanan arsip, di mana ukuran basis Ethereum bisa melebihi 20 TB, dan sinkronisasi memakan waktu berbulan-bulan. Itulah sebabnya akhirnya harus dibuat arsitektur penyimpanan baru berbasis path-based untuk status.

Jadi ya, “hardware”, prosesor, throughput jaringan, CPU—semuanya adalah batasan fisik nyata dalam perlombaan untuk pertumbuhan informasi. Tapi itu bukan satu-satunya. Server modern sudah mampu memproses volume data yang sangat besar. Pertanyaannya: berapa yang harus dibayar ratusan—bahkan ribuan—peserta jaringan independen untuk itu?

Misalnya, jika partisipasi penuh dalam ekosistem membutuhkan puluhan terabyte SSD, ratusan gigabyte RAM, saluran komunikasi yang mahal, maka jumlah operator infrastruktur pasti berkurang. Dari situlah muncul sentralisasi baru.

Secara formal, data bisa diproses, tetapi tidak mungkin membuatnya murah dan desentralisasi sekaligus. Biaya pemrosesan informasi mulai tumbuh lebih cepat daripada biaya transaksi itu sendiri.

Как отреагировал рынок

Para pelaku yang berlomba sudah paham bahwa pemenangnya adalah jaringan yang bisa mengubah transaksi menjadi informasi yang dapat diakses dengan lebih cepat, lebih murah, dan lebih andal. Dan sepanjang tahun ini, pasar secara mengejutkan mengalihkan perhatian ke peralihan ke modular blockchain.

Jika generasi pertama jaringan mencoba menjalankan semua tugas secara bersamaan, maka generasi baru memisahkan tanggung jawab ke lapisan-lapisan khusus. Alih-alih satu jaringan, muncul lapisan-lapisan terpisah:

• execution layer — lapisan eksekusi (atau pelaksanaan);
• settlement layer — lapisan penyelesaian (pengaturan);
• consensus layer — lapisan konsensus;
• data availability layer — lapisan ketersediaan data.

Pengembang membandingkan proses ini dengan evolusi pusat data. Dulu, satu server menjalankan semua fungsi sekaligus. Hari ini, komputasi, penyimpanan data, dan layanan jaringan dapat diskalakan secara independen satu sama lain

Salah satu bidang pasar yang tumbuh paling cepat adalah jaringan DA. Sekilas, ide ini terlihat aneh: mengapa membuat blockchain terpisah untuk penyimpanan sementara data blockchain lain? Namun justru itu yang terjadi. Dalam arsitektur modular, eksekusi transaksi dan penyimpanan data dapat ada secara terpisah. Rollup mempublikasikan data ke lapisan DA eksternal, bukan ke jaringan utama. Ini memungkinkan menurunkan biaya skalabilitas secara signifikan dan meningkatkan throughput.

Beberapa tahun lalu, RPC dianggap sebagai detail teknis. Hari ini, RPC adalah salah satu elemen paling penting dari kriptoinfrastruktur. Pada Mei 2026, Triton One bersama Solana Foundation merilis pengumuman RPC 2.0 yang diperbarui—ini adalah pendekatan baru untuk membangun arsitektur pembacaan data di jaringan

Gagasan utamanya adalah memisahkan akses ke kondisi saat ini jaringan dan riwayatnya. Untuk itu, diperkenalkan dua modul independen: satu mengindeks status akun secara real time, yang kedua mengoptimalkan kerja dengan data historis. Alih-alih pemindaian penuh blockchain, sistem membentuk indeks adaptif untuk permintaan aplikasi tertentu, sehingga menurunkan latensi dan biaya pemrosesan.

Dengan cara itu, Triton dan Solana berusaha menghilangkan sejumlah batasan sistem: arsitektur monolitik RPC yang mahal dan tidak efisien, kumpulan sempit standar permintaan JSON-RPC, serta ketergantungan pengembang pada solusi mereka sendiri atau yang bersifat proprietari untuk bekerja dengan data. Dalam model baru, pembacaan diskalakan terpisah dari konsensus, dan akses ke riwayat menjadi lebih cepat berkat penggunaan penyimpanan kolumnar dan data yang sudah diprapilih.

Proyek ini bersandar pada alat-alat yang sudah diimplementasikan di ekosistem—termasuk streaming data dari validator (Geyser, Yellowstone gRPC) dan solusi untuk memproses riwayat. Seluruh infrastruktur disebarkan dengan kode sumber terbuka, dan pengembangannya dikoordinasikan dengan partisipasi Solana Foundation.

Akibatnya, Solana secara efektif mencoba beralih dari “RPC universal” ke infrastruktur data modular dan terspesialisasi yang konon harus menurunkan hambatan bagi pengembang serta membuat pekerjaan dengan data blockchain setara dalam hal kemudahan dengan basis data tradisional.

Решает ли модульность проблему?

Jika Solana berhasil menstandarkan lapisan pembacaan, itu bisa memperkuat posisinya sebagai jaringan dengan infrastruktur aplikasi yang berkembang, bukan sekadar throughput tinggi. Namun pada saat yang sama, ini memperkuat persaingan dengan penyedia RPC independen dan platform infrastruktur, yang harus menyesuaikan dengan standar baru atau menawarkan layanan tambahan di atasnya.

Arsitektur modular menghilangkan sebagian batasan infrastruktur, tetapi memindahkannya ke lapisan-lapisan lain dalam sistem. Sangat jelas keinginan untuk menurunkan biaya dan mempermudah akses ke data yang tanpanya DeFi, NFT, dompet, analitik, dan instrumen kepatuhan tidak bisa berjalan. Namun tampaknya, efek cascading complexity sudah tertanam dalam sifat dasar Web3: menyelesaikan satu masalah pasti menciptakan tantangan baru.

Skema baru secara pasti membutuhkan lapisan infrastruktur tingkat atas yang lebih kompleks: dengan indexer, storage, cache, pipeline terpisah, dan titik-titik kegagalan baru. Alih-alih satu lapisan RPC yang sederhana, ekosistem bisa mendapatkan beberapa implementasi paralel yang tidak saling kompatibel, optimasi yang berbeda, serta ketergantungan yang lebih besar pada penyedia infrastruktur. Dalam kasus seperti ini, secara formal arsitektur terbuka tidak selalu berarti model akses yang benar-benar terbuka dan nyaman untuk semua orang.

Saat ini, kita masih berada pada tahap ketika pasar bergeser dari persaingan siapa yang lebih baik dalam mengambil data dari jaringan, menuju perlombaan siapa yang pertama membuat produk berdasarkan data tersebut. Siapa dan berapa yang akan mereka bayar untuk itu—kemungkinan besar akan kita ketahui dalam waktu dekat