Perkembangan ekosistem blockchain tidak hanya ditentukan oleh keberadaan aset digital, aktivitas perdagangan, maupun pertumbuhan jumlah pengguna. Infrastruktur teknis yang menopang komunikasi antara aplikasi dan jaringan blockchain juga memiliki peran sangat penting dalam menentukan kualitas sebuah ekosistem. Salah satu komponen utama infrastruktur tersebut adalah Remote Procedure Call (RPC), sebuah mekanisme komunikasi yang memungkinkan dompet digital, aplikasi terdesentralisasi, explorer, dan berbagai layanan blockchain berinteraksi dengan node jaringan untuk memperoleh maupun mengirimkan informasi transaksi.
Gambaran mengenai kondisi infrastruktur tersebut muncul melalui sebuah dashboard pemantauan bertajuk CMS Mining Pool — Live Dashboard. Platform ini menampilkan fitur Community RPC Consensus Checks yang digunakan untuk memeriksa sejumlah endpoint RPC komunitas BlockDAG. Berdasarkan tangkapan layar bertanggal 9 November 2026, sistem tersebut melaporkan telah memeriksa 12 endpoint RPC menggunakan mekanisme pemeriksaan multi-sumber yang diklaim dilakukan setiap 60 detik. Hasilnya memperlihatkan beragam kendala teknis yang menarik untuk dianalisis lebih jauh.
Temuan tersebut menjadi relevan karena ketersediaan RPC merupakan salah satu fondasi penting dalam membangun pengalaman pengguna blockchain. Ketika RPC mengalami gangguan, pengguna dapat menghadapi kesulitan menghubungkan dompet, membaca saldo, memeriksa transaksi, mengakses data blok, maupun berinteraksi dengan smart contract. Dengan demikian, kualitas RPC bukan sekadar persoalan teknis pengelola server, melainkan bagian dari kesiapan infrastruktur ekosistem blockchain dalam mendukung pertumbuhan aplikasi dan aktivitas ekonomi digital.
Namun, hasil dashboard tersebut perlu dipahami secara proporsional. Status yang ditampilkan merupakan laporan dari sistem pemantauan CMS Mining Pool, bukan hasil audit independen terhadap seluruh jaringan BlockDAG. Gangguan pada endpoint RPC tidak otomatis membuktikan bahwa konsensus blockchain mengalami masalah. Perbedaan antara kesehatan node, ketersediaan layanan RPC, dan kondisi jaringan utama harus menjadi dasar dalam membaca setiap temuan.
CMS Mining Pool Menguji 12 Endpoint RPC Komunitas
Salah satu fitur yang paling menarik dari dashboard CMS Mining Pool adalah Community RPC Consensus Checks. Fitur ini memperlihatkan pendekatan pemantauan yang tidak hanya mengandalkan satu server, melainkan membandingkan respons dari sejumlah endpoint RPC komunitas. Pendekatan multi-sumber memiliki nilai penting karena sebuah sistem blockchain idealnya tidak bergantung pada satu penyedia infrastruktur untuk memperoleh informasi mengenai kondisi jaringan.
Dalam dashboard tersebut disebutkan bahwa sebanyak 12 RPC komunitas diperiksa terhadap suatu mekanisme pemeriksaan quorum multi-sumber independen. Pemeriksaan dijadwalkan berlangsung setiap 60 detik. Secara konseptual, pendekatan ini memungkinkan sistem membandingkan hasil respons berbagai node untuk mengetahui apakah informasi yang diperoleh menunjukkan kesesuaian atau justru memperlihatkan perbedaan yang perlu diselidiki.
Daftar endpoint yang terlihat mencakup CMS Mining Pool, BlockDAG East, BlockDAG West, DVD Mining, CapeDAG, BdagScan, BlockDAG Works, DagTech, BlockDAG Brazil, BlockDAG England, RMS, dan BlockDAG Engineering. Keberadaan sejumlah penyedia dengan nama dan domain berbeda memperlihatkan adanya upaya membangun infrastruktur RPC yang melibatkan berbagai pihak dalam komunitas. Akan tetapi, banyaknya endpoint belum otomatis menjamin kualitas layanan apabila tidak disertai standar operasional, pemantauan, dan validasi data yang memadai.
Dari perspektif pengembangan ekosistem, keberagaman penyedia RPC sebenarnya merupakan perkembangan yang patut diperhatikan. Apabila berbagai operator mampu menyediakan node yang tersinkronisasi dan dapat diakses secara konsisten, pengguna memiliki lebih banyak alternatif ketika salah satu layanan mengalami gangguan. Model seperti ini juga dapat mengurangi ketergantungan terhadap satu penyedia layanan dan membuka kesempatan bagi komunitas untuk berpartisipasi dalam pembangunan infrastruktur blockchain.
Timeout Menjadi Kendala yang Paling Banyak Terlihat
Salah satu pola yang paling menonjol dalam hasil pemeriksaan CMS Mining Pool adalah munculnya pesan timeout pada sejumlah endpoint. CMS Mining Pool sendiri menampilkan status block fetch failed: The read operation timed out. Sementara itu, BlockDAG East, BlockDAG West, DVD Mining, dan CapeDAG memperlihatkan pesan verified local block unavailable: timed out. Kondisi tersebut menunjukkan bahwa sistem pemantauan tidak berhasil memperoleh respons yang dibutuhkan dalam batas waktu pemeriksaan.
Timeout merupakan kondisi ketika suatu permintaan telah dikirimkan, tetapi server tidak memberikan respons sebelum batas waktu yang ditentukan berakhir. Dalam infrastruktur blockchain, penyebabnya dapat beragam, mulai dari kapasitas server yang terbatas, beban permintaan terlalu tinggi, latensi jaringan, proses sinkronisasi node, hingga konfigurasi layanan RPC yang kurang optimal. Oleh sebab itu, timeout tidak selalu menunjukkan bahwa node berhenti bekerja atau kehilangan koneksi dengan jaringan blockchain.
Perlu dibedakan pula antara node yang masih terhubung dengan jaringan peer-to-peer dan endpoint RPC yang dapat melayani permintaan pengguna. Sebuah node mungkin tetap memiliki koneksi dengan peer lainnya, tetapi layanan RPC yang berjalan di atasnya mengalami keterlambatan dalam memberikan respons. Kondisi ini dapat terjadi ketika sumber daya komputasi terbatas, penyimpanan mengalami hambatan, atau proses pemrosesan permintaan berlangsung lebih lambat daripada kemampuan sistem pemantauan.
Bagi pengguna biasa, gangguan semacam ini dapat menimbulkan pengalaman yang membingungkan. Dompet digital mungkin gagal memperbarui saldo, aplikasi tidak berhasil membaca riwayat transaksi, atau explorer mengalami keterlambatan ketika menampilkan informasi blok terbaru. Dalam lingkungan aplikasi terdesentralisasi, masalah RPC bahkan dapat menghambat proses interaksi dengan smart contract. Karena itu, stabilitas layanan perlu menjadi salah satu prioritas utama dalam pembangunan infrastruktur BlockDAG.
BdagScan Menampilkan 6.041 Mismatches, Perlu Investigasi Mendalam
Bagian yang paling menarik perhatian dalam dashboard tersebut adalah hasil pemeriksaan terhadap endpoint BdagScan. Baris yang mencantumkan alamat https://rpc.bdagscan.com memperlihatkan angka nol pada kolom Matches dan 6.041 pada kolom Mismatches. Pada saat yang sama, status endpoint menunjukkan RPC unavailable: The read operation timed out. Angka tersebut cukup besar untuk menjadi perhatian, terutama karena BdagScan dikenal sebagai salah satu layanan yang berkaitan dengan penjelajahan informasi jaringan BlockDAG.
Meskipun demikian, angka 6.041 mismatches tidak boleh langsung ditafsirkan sebagai bukti bahwa BdagScan menyajikan data blockchain yang salah. Status timeout yang muncul bersamaan menunjukkan bahwa sistem pemantauan menghadapi persoalan dalam memperoleh respons. Tanpa mengetahui secara terperinci algoritma pemeriksaan, definisi mismatch, periode penghitungan, dan data pembanding yang digunakan, belum dapat dipastikan apakah angka tersebut mencerminkan perbedaan hash blok, ketidaksesuaian nomor blok, kegagalan pengambilan data, atau mekanisme penilaian internal lainnya.
Dalam pengujian blockchain yang benar, perbandingan tidak cukup dilakukan hanya dengan melihat nomor blok terbaru. Dua node dapat memiliki nomor blok yang sama, tetapi tetap perlu diperiksa apakah hash blok pada ketinggian tersebut identik. Hash merupakan identitas kriptografis suatu blok yang dapat digunakan untuk mendeteksi perbedaan isi maupun struktur blok. Pemeriksaan lanjutan juga dapat mencakup parent hash, timestamp, transaksi yang terkandung di dalam blok, serta informasi jaringan yang digunakan oleh masing-masing node.
Apabila dua endpoint benar-benar mengarah ke jaringan dan riwayat blockchain yang sama, hash blok pada ketinggian yang sama semestinya menunjukkan kesesuaian. Sebaliknya, apabila hasilnya berbeda, operator perlu memeriksa kemungkinan perbedaan jaringan, konfigurasi chain, keterlambatan sinkronisasi, atau kondisi node yang belum mengikuti perkembangan jaringan utama. Dengan pendekatan tersebut, investigasi menjadi lebih objektif dan tidak bergantung pada satu angka yang ditampilkan dashboard.
Error SSL dan DNS Menunjukkan Persoalan Berbeda
Selain timeout, dashboard CMS Mining Pool juga memperlihatkan beberapa jenis kesalahan lain yang memiliki karakteristik berbeda. Endpoint BlockDAG Works dengan alamat rpc.blockdag.works menampilkan pesan SSL: WRONG_VERSION_NUMBER. Kesalahan tersebut umumnya berkaitan dengan ketidaksesuaian konfigurasi protokol komunikasi antara klien dan server. Salah satu kemungkinan adalah klien mencoba melakukan koneksi HTTPS terhadap layanan yang sebenarnya tidak dikonfigurasi untuk menangani TLS pada port tersebut.
Persoalan SSL/TLS sangat penting karena komunikasi antara dompet digital, aplikasi, dan server RPC idealnya dilindungi melalui enkripsi. Konfigurasi yang tidak tepat dapat menyebabkan koneksi gagal meskipun node blockchain di belakang layanan tersebut sebenarnya masih aktif. Operator perlu memastikan bahwa sertifikat, port, reverse proxy, dan konfigurasi protokol telah disesuaikan dengan kebutuhan endpoint yang dipublikasikan kepada pengguna.
Masalah berbeda terlihat pada endpoint DagTech yang menampilkan HTTP Error 530, sedangkan BlockDAG Brazil dan BlockDAG England memperlihatkan HTTP Error 502: Bad Gateway. Kesalahan 502 biasanya menunjukkan bahwa gateway atau proxy tidak berhasil memperoleh respons yang valid dari server tujuan. Sementara itu, kode 530 dapat berkaitan dengan kegagalan pada lapisan layanan perantara atau konfigurasi akses tertentu, bergantung pada penyedia infrastrukturnya. Kedua jenis kesalahan ini tidak secara langsung membuktikan bahwa jaringan blockchain mengalami gangguan konsensus.
Perhatian khusus juga tertuju pada BlockDAG Engineering dengan alamat rpc.blockdag.engineering. Dashboard menampilkan pesan blocked: Hostname does not resolve. Artinya, sistem pemeriksaan tidak berhasil menerjemahkan nama domain menjadi alamat IP melalui DNS. Penyebabnya dapat berupa konfigurasi DNS yang belum benar, record yang tidak tersedia, gangguan resolver, atau masalah pada domain itu sendiri. Dalam kondisi seperti ini, permintaan belum tentu berhasil mencapai server RPC karena proses penerjemahan nama domain sudah mengalami kegagalan.
Angka Matches Tidak Selalu Menunjukkan RPC Sehat
Dashboard CMS Mining Pool juga memperlihatkan angka Matches yang cukup besar pada beberapa endpoint. CMS Mining Pool mencatat 12.977 matches, CapeDAG 10.780 matches, BlockDAG England 12.896 matches, dan BlockDAG Brazil 5.256 matches. Sementara itu, beberapa endpoint lainnya memiliki angka yang jauh lebih rendah. Informasi tersebut memberikan gambaran bahwa sistem telah mengumpulkan sejumlah hasil pemeriksaan, tetapi angka tersebut harus dibaca bersama status konektivitas masing-masing layanan.
Hal ini terlihat jelas pada CMS Mining Pool sendiri. Meskipun mencatat 12.977 matches dan nol mismatches, status terbarunya justru menunjukkan block fetch failed akibat read operation timed out. Kondisi tersebut memperlihatkan bahwa hasil pemeriksaan historis atau akumulasi pengujian tidak selalu mencerminkan kondisi endpoint pada saat terakhir diperiksa. Sebuah layanan dapat memiliki catatan kesesuaian yang tinggi, tetapi tetap mengalami gangguan ketika permintaan terbaru dilakukan.
Dalam sistem pemantauan profesional, indikator konsistensi dan ketersediaan layanan idealnya ditampilkan secara terpisah. Konsistensi berkaitan dengan kesesuaian data yang diperoleh dari berbagai node, sedangkan ketersediaan menunjukkan kemampuan endpoint memberikan respons ketika diminta. Selain itu, latensi, tingkat keberhasilan permintaan, waktu aktif atau uptime, serta tinggi blok terakhir juga perlu dipantau secara berkala.
Dengan demikian, pengguna maupun operator dapat memperoleh gambaran yang lebih lengkap mengenai kualitas setiap RPC. Endpoint yang memiliki banyak matches belum tentu menjadi pilihan terbaik apabila tingkat keberhasilan permintaannya rendah. Sebaliknya, endpoint yang cepat merespons juga belum tentu dapat dipercaya apabila data yang diberikan tidak konsisten dengan jaringan utama. Kualitas RPC harus dinilai melalui kombinasi beberapa indikator teknis yang saling melengkapi.
18 Peers dan Nol Miners: Memahami Status Mining Pool
Selain tabel RPC, bagian atas dashboard menampilkan informasi 18 peers dan 0 miners, disertai status Shaft Warming Up. Ketiga indikator ini memberikan gambaran mengenai kondisi operasional CMS Mining Pool berdasarkan sistem yang ditampilkan. Namun, ketiganya memiliki makna yang berbeda dan tidak boleh disamakan dengan indikator kesehatan keseluruhan jaringan BlockDAG.
Peers merupakan perangkat atau node lain yang terhubung melalui mekanisme komunikasi jaringan. Jumlah 18 peers menunjukkan bahwa dashboard melaporkan adanya 18 koneksi peer. Koneksi tersebut dapat menjadi salah satu indikator aktivitas komunikasi node, tetapi belum cukup untuk memastikan bahwa seluruh peer telah tersinkronisasi dengan baik atau bahwa node memiliki kemampuan melayani permintaan RPC secara optimal.
Sementara itu, indikator 0 miners menunjukkan bahwa dashboard belum mendeteksi miner aktif pada saat informasi tersebut ditampilkan. Status ini tidak otomatis membuktikan bahwa jaringan BlockDAG tidak memiliki aktivitas mining. Dashboard tersebut merupakan representasi kondisi sistem CMS Mining Pool, sehingga informasi jumlah miner perlu dipahami dalam konteks layanan yang sedang dipantau. Adapun status Shaft Warming Up kemungkinan menggambarkan tahap persiapan atau pemanasan operasional berdasarkan terminologi yang digunakan platform.
Informasi tersebut menarik karena memperlihatkan bahwa CMS Mining Pool tidak hanya menampilkan daftar endpoint RPC, tetapi juga berusaha menggabungkan informasi mengenai konektivitas peer dan aktivitas mining. Jika dikembangkan dengan indikator yang lebih terukur, pendekatan semacam ini dapat membantu operator memahami hubungan antara kinerja node, ketersediaan layanan, dan kesiapan infrastruktur mining pool dalam mendukung ekosistem blockchain.
Mengapa Infrastruktur RPC Independen Penting bagi BlockDAG?
Salah satu pelajaran utama dari dashboard ini adalah pentingnya keberagaman penyedia RPC. Ketika pengguna hanya mengandalkan satu endpoint, gangguan pada server tersebut dapat menyebabkan berbagai aplikasi tidak dapat berkomunikasi dengan blockchain. Sebaliknya, keberadaan beberapa penyedia independen memberikan alternatif koneksi dan memungkinkan aplikasi melakukan pergantian endpoint ketika layanan utama mengalami gangguan.
Infrastruktur RPC yang tersebar juga dapat mendukung ketahanan ekosistem. Operator yang berbeda dapat mengelola node pada lokasi geografis, pusat data, dan penyedia jaringan yang berbeda. Jika salah satu wilayah mengalami gangguan konektivitas, endpoint lain masih berpotensi memberikan akses kepada pengguna. Akan tetapi, manfaat tersebut baru dapat diwujudkan apabila setiap penyedia menjalankan node yang benar-benar tersinkronisasi dan memiliki konfigurasi jaringan yang sesuai.
Dalam konteks pengembangan BlockDAG, peluang ini terbuka bagi komunitas, pengembang aplikasi, operator node, hingga penyedia infrastruktur independen. Mereka dapat berkontribusi melalui penyediaan public RPC, layanan monitoring, blockchain explorer, node arsip, dan berbagai fasilitas pendukung lainnya. Kehadiran lebih banyak operator yang kompeten dapat memperkuat fondasi teknis ekosistem sekaligus mengurangi ketergantungan terhadap beberapa layanan tertentu.
Namun, desentralisasi infrastruktur tidak cukup hanya diukur berdasarkan jumlah domain RPC yang tersedia. Hal yang lebih penting adalah kepemilikan dan pengelolaan node yang independen, keterbukaan informasi operasional, serta kemampuan setiap operator untuk membuktikan bahwa data yang disajikan sesuai dengan jaringan yang benar. Jika banyak endpoint ternyata hanya menggunakan satu sumber backend, keberagaman domain tersebut belum tentu menghasilkan desentralisasi yang sesungguhnya.
Membangun RPC Mandiri Menjadi Peluang Strategis
Temuan dalam dashboard CMS Mining Pool juga memberikan gambaran mengenai peluang pengembangan RPC mandiri. Bagi komunitas yang ingin membangun layanan infrastruktur sendiri, pendekatan tersebut dapat dimulai dengan menyediakan node BlockDAG yang kompatibel dengan jaringan utama, memastikan proses sinkronisasi berjalan baik, dan membuka layanan JSON-RPC melalui domain publik yang dikelola secara profesional.
Penggunaan layanan penyedia infrastruktur seperti Blucores dapat menjadi salah satu pilihan untuk mengeksplorasi kebutuhan komputasi dan pengelolaan server. Namun, penyediaan server saja tidak otomatis menghasilkan RPC BlockDAG yang berfungsi. Pengelola tetap harus memperoleh perangkat lunak node yang sesuai, memahami konfigurasi jaringan, menyiapkan penyimpanan yang memadai, mengelola konektivitas peer, serta memastikan layanan JSON-RPC dapat diakses melalui konfigurasi yang aman.
Setelah node berhasil berjalan, tahap berikutnya adalah menyiapkan domain khusus, DNS record, sertifikat SSL/TLS, dan reverse proxy. Penggunaan HTTPS diperlukan untuk menyediakan komunikasi terenkripsi bagi aplikasi dan pengguna. Selain itu, operator perlu menerapkan pembatasan permintaan, pemantauan sumber daya, pencatatan error, serta mekanisme perlindungan terhadap penyalahgunaan endpoint. Seluruh komponen tersebut berperan dalam menjaga kualitas layanan ketika jumlah pengguna meningkat.
Pengujian juga tidak boleh berhenti pada keberhasilan membuka alamat RPC melalui browser. Endpoint harus diuji menggunakan metode JSON-RPC seperti eth_chainId, eth_blockNumber, eth_getBlockByNumber, eth_syncing, net_peerCount, dan web3_clientVersion apabila metode tersebut didukung oleh implementasi node. Hasilnya perlu dibandingkan dengan beberapa sumber independen untuk memastikan kesesuaian jaringan, nomor blok, hash blok, dan kondisi sinkronisasi. Dengan demikian, layanan yang dibangun tidak hanya dapat diakses, tetapi juga memiliki dasar verifikasi teknis yang jelas.
Standar Transparansi Menjadi Kebutuhan Ekosistem
Perkembangan jumlah aplikasi blockchain akan meningkatkan kebutuhan terhadap infrastruktur yang dapat diandalkan. Dompet digital, decentralized exchange, platform staking, aplikasi tokenisasi aset, hingga sistem sertifikat digital semuanya membutuhkan akses terhadap data blockchain. Apabila layanan RPC tidak stabil, berbagai aplikasi yang berada di lapisan atas dapat ikut mengalami gangguan meskipun masalah sebenarnya berasal dari infrastruktur komunikasi.
Karena itu, ekosistem BlockDAG membutuhkan standar transparansi yang memungkinkan pengguna mengetahui kondisi setiap endpoint secara objektif. Dashboard monitoring idealnya tidak hanya menampilkan status online atau offline, tetapi juga menyertakan waktu respons, persentase keberhasilan permintaan, nomor blok terakhir, hash blok, identitas chain, jumlah peer, serta riwayat gangguan. Informasi tersebut akan membantu pengguna menentukan endpoint yang sesuai berdasarkan bukti teknis, bukan sekadar popularitas atau klaim penyedia layanan.
Penerapan mekanisme pemeriksaan multi-sumber juga dapat menjadi fondasi bagi sistem pemantauan yang lebih kuat. Namun, sistem tersebut perlu menjelaskan metode pengujian, sumber pembanding, definisi matches dan mismatches, serta cara menangani kondisi ketika salah satu endpoint tidak memberikan respons. Keterbukaan mengenai metodologi menjadi sangat penting agar hasil pemeriksaan dapat dipahami, direproduksi, dan diverifikasi oleh pihak lain.
Dalam jangka panjang, transparansi semacam ini dapat mendorong persaingan sehat di antara operator RPC. Penyedia layanan tidak hanya berlomba menawarkan endpoint gratis atau kapasitas server yang lebih besar, tetapi juga meningkatkan kualitas sinkronisasi, kecepatan respons, keamanan, dan konsistensi data. Persaingan berdasarkan kualitas teknis akan memberikan manfaat langsung kepada pengembang aplikasi maupun pengguna akhir.
Kesimpulan: Gangguan RPC Bukan Akhir, Melainkan Momentum Evaluasi
Dashboard CMS Mining Pool memberikan gambaran menarik mengenai tantangan operasional yang dihadapi sejumlah endpoint RPC komunitas BlockDAG. Dari 12 endpoint yang ditampilkan, sistem melaporkan berbagai persoalan, mulai dari timeout, ketidaktersediaan data blok lokal, kesalahan SSL, HTTP 502, HTTP 530, hingga kegagalan resolusi DNS. Hasil yang paling mencolok adalah catatan 6.041 mismatches pada endpoint BdagScan, meskipun angka tersebut masih memerlukan verifikasi metodologi sebelum dapat ditafsirkan sebagai ketidaksesuaian data blockchain yang sebenarnya.
Temuan ini sekaligus memperlihatkan bahwa membangun ekosistem blockchain yang kuat membutuhkan perhatian serius terhadap infrastruktur pendukung. Keberadaan token, aplikasi, dan aktivitas komunitas memang penting, tetapi semuanya membutuhkan jaringan komunikasi yang stabil, node yang tersinkronisasi, serta endpoint RPC yang dapat memberikan informasi secara konsisten. Tanpa fondasi tersebut, pengalaman pengguna dan kemampuan pengembang dalam membangun aplikasi akan menghadapi berbagai keterbatasan.
Bagi BlockDAG, momentum ini dapat dimanfaatkan untuk memperkuat kolaborasi antara operator node, pengembang, penyedia RPC, dan komunitas. Peningkatan standar monitoring, pengujian independen, transparansi data, serta pembangunan endpoint mandiri dapat menjadi langkah konkret untuk memperkuat ketahanan infrastruktur. Semakin banyak operator yang mampu menyediakan layanan berkualitas dan benar-benar independen, semakin besar pula peluang terciptanya ekosistem yang tidak bergantung pada satu titik layanan.
Pada akhirnya, kualitas sebuah jaringan blockchain tidak hanya ditentukan oleh teknologi konsensus yang digunakan, tetapi juga oleh kemampuan infrastruktur pendukungnya dalam memberikan akses yang stabil, aman, dan dapat diverifikasi. Dashboard CMS Mining Pool menjadi salah satu contoh bagaimana pemantauan terbuka dapat membantu mengidentifikasi persoalan sekaligus membuka ruang evaluasi. Tantangan RPC seharusnya tidak dipandang sebagai hambatan permanen, melainkan sebagai dorongan untuk membangun infrastruktur BlockDAG yang lebih tangguh, transparan, dan siap mendukung pertumbuhan ekonomi digital di masa depan.
Catatan editorial: Artikel ini menggunakan tangkapan layar CMS Mining Pool bertanggal 9 November 2026 sebagai sumber utama. Angka dan status merupakan informasi yang dilaporkan dashboard tersebut, bukan hasil verifikasi independen. Dengan demikian, artikel tidak menyimpulkan bahwa jaringan utama BlockDAG mengalami kegagalan konsensus ataupun bahwa BdagScan terbukti menyajikan data yang keliru.
