Pool cadangan dan failover: untuk apa slot kedua dan ketiga di ASIC

Hampir semua firmware ASIC punya tiga kolom untuk alamat pool. Biasanya cuma satu yang diisi. Kolom kedua dan ketiga dibiarkan kosong atau diisi alamat yang sama, sehingga tidak berguna. Ini asuransi termurah dalam mining: pengaturannya cuma lima menit, tidak ada biayanya, dan menyelamatkan dari downtime saat pool utama down.

Di bawah ini kita bahas mekanisme perpindahan, hitung biaya downtime pakai rumus kita, dan bahas secara terpisah hal yang hampir tidak pernah dijelaskan siapa pun: apa yang terjadi pada kontribusi Anda di PPLNS ketika miner pindah ke cadangan.

Apa itu tiga slot pool di ASIC

Tiga slot ini adalah daftar prioritas. Miner menjaga koneksi stratum ke alamat pertama. Jika koneksi putus atau pool berhenti memberikan tugas, firmware mencoba alamat kedua, lalu ketiga. Tidak ada yang lebih pintar dari itu: ini pencarian berurutan dari atas ke bawah, tanpa load balancing dan tanpa membagi hashrate antar pool.

Poin penting soal perpindahan: ini tidak instan. Miner harus memastikan dulu bahwa koneksi benar-benar putus. Ia menunggu timeout habis, kadang mencoba reconnect beberapa kali ke alamat pertama, baru kemudian pindah ke alamat berikutnya. Durasi jendela waktu ini tergantung firmware dan versinya, tidak ada standar tunggal. Cek nilai pastinya di web interface perangkat Anda, di bagian pengaturan pool, atau di log: di situ terlihat berapa detik setelah putus koneksi miner mulai mengetuk alamat kedua.

Dari sini ada kesimpulan praktis. Failover tidak melindungi dari gangguan singkat yang cuma beberapa detik. Ia melindungi dari situasi yang berlangsung menit sampai jam: pool down, pool bermasalah DNS, provider Anda kehilangan rute ke data center tertentu. Cara membedakan masalah di sisi pool dari masalah di sisi Anda sendiri dibahas rinci di artikel pool sedang down: diagnosis langkah demi langkah.

Poin kedua: kebanyakan firmware kembali otomatis ke pool pertama begitu pool itu pulih. Artinya cadangan berfungsi sebagai tempat sementara, bukan pindah permanen. Tapi perilaku ini perlu diverifikasi terpisah di model Anda sendiri, karena juga tergantung firmware.

Berapa biaya satu jam downtime

Kita mulai dari rumus dasar produksi yang diharapkan. Pendapatan per periode pada hashrate tertentu:

```

BTC = H * 86400 * R / (D * 2^32)

```

di mana H adalah hashrate dalam hash per detik, 86400 jumlah detik dalam sehari, R reward blok dalam BTC, D difficulty jaringan. Rumus ini memberi ekspektasi matematis, bukan jaminan: pada volume kecil, produksi aktual berfluktuasi di sekitar angka ini.

Kita masukkan data jaringan per 08.09.2026: difficulty 127,45 triliun, reward 3,125 BTC, hashrate jaringan 930,73 EH/s, porsi fee dalam blok 0,66 persen. Dengan parameter ini, 100 TH/s menghasilkan 0,00004932 BTC per hari. Pada kurs 78.349 dolar, itu setara 3,86 dolar per hari, atau 16,1 sen per jam.

Selanjutnya aritmatika sederhana menurut skala:

Di satu S21 rumahan, selisih antara 1 dan 5 persen downtime per bulan diukur cuma beberapa dolar, dan pada level ini failover lebih soal kerapian daripada uang. Di sepuluh petahash, persentase yang sama berubah jadi ratusan dolar per bulan, dan pengaturan slot kedua sudah balik modal sejak gangguan pertama. Anda bisa hitung angka sendiri lewat kalkulator profitabilitas, dengan memasukkan hashrate dan harga listrik Anda.

Perlu diingat juga bahwa downtime tidak gratis dari sisi pengeluaran: perangkat yang down di sisi pool tetap mengonsumsi listrik kalau miner terus berputar kosong sambil mencoba reconnect.

Apa yang terjadi pada kontribusi PPLNS saat pindah ke cadangan

Jawaban langsung: di PPLNS, share yang sudah Anda kirim tidak langsung nol saat koneksi terputus. Share itu tetap ada di jendela dan terus ikut pembagian blok yang akan ditemukan pool dalam waktu dekat, lalu perlahan tergeser oleh share baru dari miner lain. Perpindahan singkat ke cadangan biayanya jauh lebih murah daripada yang biasa dikira. Perpindahan panjang menghabiskan kontribusi sepenuhnya.

Mekanismenya begini. PPLNS tidak membayar untuk share itu sendiri, tapi untuk proporsi share Anda di antara N share terakhir pool pada saat blok ditemukan. Selama share Anda masih di dalam jendela ini, setiap blok yang ditemukan membawa bagian reward untuk Anda. Begitu arus share orang lain mendorong share Anda keluar batas jendela, share itu berhenti dihitung. Ini bukan penalti maupun penghapusan, melainkan pergeseran alami jendela.

Ukuran jendela berbeda antar pool, dan cara mendeskripsikannya juga berbeda. Menurut analisis kami atas dokumentasi:

Dari sini ada aturan praktis: makin lebar jendela pool utama, makin tenang Anda bisa melewati perpindahan singkat ke cadangan. Di Ocean, jendela delapan difficulty jaringan berarti satu share rata-rata sempat ikut pembagian berkali-kali, dan gangguan koneksi sepuluh menit hampir tidak mengambil apa-apa. Dengan jendela pendek, gangguan yang sama biayanya lebih mahal.

Sebaliknya: perpindahan ke cadangan selama berjam-jam berarti pada saat kembali, hampir tidak ada lagi sisa kontribusi Anda di jendela pool utama, dan akumulasi dimulai dari nol lagi. Karena itulah gangguan panjang lebih menyakitkan di PPLNS dibanding di PPS dan FPPS, di mana pembayaran tidak bergantung pada apakah pool menemukan blok atau tidak.

Catatan penting: kebanyakan pool BTC besar secara default tidak berjalan di PPLNS, melainkan FPPS atau PPS+. Kalau Anda di FPPS, seluruh aritmatika jendela ini tidak berlaku untuk Anda, dan perpindahan ke cadangan biayanya persis sebesar yang tidak Anda tambang selama downtime, tidak lebih tidak kurang.

Cara memilih pool cadangan

Jawaban langsung: ambil cadangan dengan skema pembayaran yang sama dengan pool utama, tapi jangan berusaha mencari pool berukuran sama. Kesamaan skema itu penting karena menentukan cara penghitungan pendapatan selama downtime dan apakah Anda harus memahami dua model pembayaran berbeda dalam satu minggu. Ukuran pool tidak berpengaruh di sini.

Kenapa skema lebih penting daripada ukuran. Kalau pool utama pakai FPPS dan cadangan pakai PPLNS, setiap perpindahan mulai mengumpulkan kontribusi dari nol di jendela asing, dan saat kembali kontribusi itu jadi tidak termanfaatkan penuh. Ditambah lagi lebih sulit mencocokkan laporan: di FPPS pendapatan rata, di PPLNS terikat pada penemuan blok. Skema yang sama membuat dua platform bisa dibandingkan.

Kenapa ukuran tidak krusial. Hashrate pool memengaruhi varians pembayaran: pool kecil menemukan blok lebih jarang, jadi pendapatan lebih tidak rata. Tapi cadangan menurut definisinya bekerja dalam episode singkat. Selama dua jam downtime, varians pool kecil tidak akan merusak apa pun, karena di FPPS varians itu sama sekali tidak ada, dan di PPLNS kontribusi selama beberapa jam tetap kecil.

Yang perlu benar-benar diperhatikan saat memilih cadangan:

1. Skema pembayaran sesuai dengan pool utama.
2. Ambang pembayaran bisa dicapai. Ini jebakan utama, dijelaskan lebih detail di bawah.
3. Lokasi geografis server berbeda dari pool utama. Cadangan di data center yang sama dengan pool utama tidak menyelamatkan dari kegagalan data center.
4. Registrasi tidak membutuhkan proses KYC selama seminggu, kalau tidak cadangan tidak bisa disiapkan dengan cepat.
5. Fee dan ambang diketahui sejak awal. Bisa dibandingkan antar pool di analisis fee dan pembayaran minimum kami.

Soal apakah ganti pool itu sepadan dan kenapa pindah-pindah sering tidak gratis, ada analisis terpisah: biaya ganti pool.

Perlukah pasang solo atau pool lain di slot ketiga

Jawaban langsung: slot ketiga masuk akal kalau bukan salinan slot kedua, melainkan asuransi terhadap kelas kegagalan yang berbeda. Slot kedua menutupi jatuhnya pool tertentu. Slot ketiga harus menutupi situasi ketika keduanya tidak bisa diakses, misalnya karena masalah rute ke satu wilayah atau blokir di sisi provider.

Opsi masuk akal untuk slot ketiga:

1. Pool dari yurisdiksi lain dengan infrastruktur jaringan lain. Pilihan paling praktis untuk kebanyakan orang.
2. Pool solo. Masuk akal kalau Anda secara prinsip siap dengan pendapatan nol sebagian besar waktu demi peluang undian menemukan blok. Sebagai mode permanen untuk hashrate kecil, ini taruhan sadar, bukan perhitungan. Sebagai slot ketiga yang diaktifkan pada jam-jam gangguan yang jarang, solo biayanya kira-kira sebesar biaya jam downtime dari tabel di atas.
3. Pool yang sama, tapi alamat endpoint stratum-nya yang lain di wilayah lain. Ini melindungi dari kegagalan regional, tapi tidak dari kegagalan pool secara keseluruhan.

Banyak orang memakai opsi 3 sebagai slot kedua, dan itu tidak buruk. Tapi kalau begitu, slot ketiga wajib berupa pool lain, kalau tidak seluruh daftar terikat pada satu operator saja.

Kesalahan umum dalam pengaturan failover

1. Alamat yang sama di ketiga slot. Kasus paling sering terjadi. Daftarnya terlihat terisi, tapi tidak ada perlindungan: pool down, ketiga entri ikut down.
2. Cadangan dengan worker yang tidak terverifikasi. Login diketik dari ingatan, dengan salah ketik atau untuk subakun yang tidak ada. Selama pool utama masih hidup, kesalahan itu tidak terlihat. Saat gangguan terjadi, miner berpindah dan mendapat penolakan otorisasi.
3. Ambang pembayaran yang tidak akan pernah Anda capai. Kalau cadangan membayar mulai dari jumlah yang baru bisa dikumpulkan hashrate Anda selama bertahun-tahun gangguan langka, uangnya cuma menumpuk di saldo. Di sebagian pool, sisa di bawah ambang tidak hilang dan menunggu siklus berikutnya, tapi di sebagian lain ada aturan soal akun tidak aktif dan alamat pembayaran yang belum diatur, sampai kehilangan hak atas akumulasi sesuai ketentuan layanan. Baca ketentuan pool tertentu sebelum menjadikannya cadangan.
4. Failover sudah diatur, tapi belum pernah diuji. Kategori paling menyesalkan, karena orangnya yakin dirinya terlindungi.
5. Cadangan dengan alamat pembayaran dan email yang sama dengan pool utama, tanpa verifikasi akses terpisah. Kalau Anda kehilangan akses akun tepat saat gangguan terjadi, slot yang sudah diatur itu tidak banyak gunanya.
6. Cadangan yang ditambahkan hanya di sebagian perangkat. Di farm berisi tiga puluh ASIC, pengaturan lewat template konfigurasi menjamin keseragaman, sementara pengecekan manual satu per satu hampir selalu meninggalkan celah.

Cara memverifikasi bahwa failover berfungsi

Jawaban langsung: verifikasi harus dilakukan dengan memutus koneksi ke pool utama secara paksa, bukan lewat teori. Cara paling aman adalah mengubah sementara urutan slot atau memblokir alamat pool utama di router, mengamati bahwa miner pindah ke alamat kedua dan mulai mengirim share yang diterima, lalu mengembalikan semuanya seperti semula.

Urutan langkah:

1. Pastikan worker di pool cadangan sudah dibuat dan terlihat di dashboard-nya. Cara paling mudah adalah mengarahkan satu miner ke cadangan selama sepuluh menit dan melihat hashrate muncul di worker tersebut.
2. Catat kondisi saat ini: alamat di ketiga slot, nama worker, hashrate saat ini di pool utama.
3. Blokir akses ke pool utama. Opsi: aturan di router berdasarkan domain atau IP, mematikan port tertentu, atau mengganti sementara alamat slot pertama dengan alamat yang pasti tidak berfungsi.
4. Ukur waktunya. Catat berapa detik setelahnya miner pindah ke alamat kedua. Ini timeout failover nyata Anda, dan nilai inilah yang harus diingat saat menilai kerugian.
5. Cek di dashboard pool cadangan bahwa share dari worker sudah masuk dan diakui valid. Sekadar ada koneksi saja tidak cukup.
6. Lepas blokirnya dan lihat apakah miner kembali sendiri ke slot pertama. Kalau tidak, berarti kembalinya manual, dan ini perlu diperhitungkan dalam prosedur.
7. Ulangi hal yang sama untuk slot ketiga, dengan memblokir pool pertama dan kedua sekaligus.
8. Catat hasil dan tanggal verifikasi. Ulangi setelah setiap update firmware: perilaku failover berubah dari versi ke versi.

Verifikasi ini enak digabung dengan pekerjaan terjadwal, saat sebagian hashrate memang sedang tidak aktif. Biaya verifikasi itu sendiri dihitung dengan tabel yang sama: sepuluh menit di 10 PH/s sekitar 2,7 dolar, biaya sekali bayar demi memastikan proteksinya bekerja.

Ringkasnya

Tiga slot alih-alih satu tidak menambah pendapatan. Slot-slot itu menghilangkan penurunan dari grafik yang kalau tidak, akan terus berlanjut sampai Anda menyadari masalahnya secara manual. Pada hashrate kecil, keuntungannya diukur dalam beberapa dolar per bulan; pada skala industri, dalam ratusan dan ribuan dolar.

Ada tiga hal yang berguna diingat. Perpindahan tidak instan, mengikuti timeout firmware, dan nilainya perlu diukur sendiri di perangkat Anda. Di PPLNS, perpindahan singkat ke cadangan biayanya lebih murah dari yang terlihat, karena share menua di jendela secara bertahap, bukan langsung nol. Dan failover yang sudah diatur tapi belum pernah diuji bukanlah perlindungan, melainkan imitasinya saja.

Untuk memperkirakan berapa biaya downtime pada konfigurasi spesifik Anda, gunakan kalkulator, dan untuk membandingkan syarat pool sebagai cadangan, lihat bagian perbandingan pool.