Bitcoin Core

Pavel menjual buku dan menerima bitcoin. Seorang pelanggan menunjukkan bukti pembayaran di ponselnya, tetapi Pavel ingin memastikan pembayaran benar-benar sampai dan masuk ke blok yang valid. Ia bisa bertanya kepada penjelajah blok publik atau menggunakan wallet yang terhubung ke node miliknya. Bitcoin Core adalah program untuk menjalankan node tersebut. Node di sini berarti komputer dengan perangkat lunak yang memeriksa aturan Bitcoin secara mandiri; blok adalah sekumpulan transaksi yang ditambahkan ke riwayat bersama. Data datang dari pihak lain, tetapi validitasnya dinilai sendiri. Pavel hanyalah contoh untuk menjelaskan gagasan ini: mengganti kepercayaan pada tampilan orang lain dengan pemeriksaan sendiri. Memasang program tidak menjadikannya penambang, memberinya BTC otomatis, atau memungkinkannya membatalkan pembayaran orang lain. Kode sumber diterbitkan dengan lisensi MIT sehingga dapat dipelajari, diubah, dan disebarkan kembali sesuai ketentuannya. [1] [16]

Kedua tugas mudah tertukar karena Bitcoin Core dapat menjalankan keduanya. Node memeriksa riwayat dan blok baru. Wallet melacak dana terkait, membuat alamat, dan menyiapkan transaksi; jika mengelola private key, wallet juga bisa menandatangani dengan kunci itu. Private key adalah data rahasia yang digunakan wallet untuk membuat tanda tangan digital yang mengizinkan pembelanjaan bitcoin terkait. Kuncinya sendiri tidak dikirim ke node lain. Namun, Core dapat berjalan tanpa wallet sama sekali. Pavel bisa membayar melalui aplikasi kompatibel lain dan mengambil data terverifikasi dari node sendiri; beberapa cara penghubungan memerlukan perangkat lunak tambahan. Menjalankan Core saja tidak otomatis mengarahkan semua wallet lain ke node tersebut. Agar nama-namanya lebih jelas: bitcoin-qt menyediakan antarmuka grafis, bitcoind berjalan di latar belakang, dan bitcoin-cli mengirim perintah ke program. [12] [17]

Node baru harus mengejar riwayat terlebih dahulu. Proses ini disebut Initial Block Download, atau IBD. Dalam sinkronisasi biasa, node mengunduh blok dan memeriksa keterkaitannya, kerja penambang, serta aturan transaksi. Hasilnya adalah chainstate: catatan lokal tentang keluaran transaksi yang belum dibelanjakan, yakni UTXO. Keluaran transaksi menetapkan jumlah dan syarat untuk membelanjakannya, misalnya tanda tangan yang diperlukan. Keluaran itu tetap dalam catatan hingga dibelanjakan oleh transaksi berikutnya. Ini bukan daftar nama dan rekening bank. Kecepatan bergantung pada komputer, penyimpanan, dan koneksi, sehingga awal yang lambat belum tentu menandakan kerusakan. Pavel memastikan sinkronisasi selesai sebelum memeriksa pembayaran terkini.

Ada rincian penting: dalam kondisi tertentu, assumevalid dapat melewati pemeriksaan skrip, yaitu syarat pembelanjaan, pada riwayat yang jauh lebih lama; -assumevalid=0 mematikan jalan pintas itu. Fitur berbeda, AssumeUTXO, memungkinkan node mulai dari cuplikan keadaan yang diperiksa sambil memproses riwayat sebelumnya di latar belakang. Cuplikan itu menyimpan keadaan UTXO pada blok tertentu. Program mula-mula membandingkan hash-nya, yaitu sidik jari digital, dengan nilai yang ditetapkan dalam kode; itu belum berarti seluruh riwayat sebelumnya sudah diperiksa secara mandiri. Asumsinya berbeda, jadi tidak tepat mengatakan setiap instalasi telah melakukan pemeriksaan yang persis sama sejak awal. [9] [10] [12] [17]

Sesudah sinkronisasi, Core terus menerima data dari node yang terhubung, disebut peers. Transaksi belum terkonfirmasi yang diterimanya disimpan dalam Mempool, ruang tunggu sementara miliknya. Berada di sana belum berarti mendapat konfirmasi dalam blok, dan isinya dapat berbeda antarnode. Core memeriksa setiap blok baru yang tiba. Di antara rantai kandidat yang valid, ia memilih akumulasi kerja terbesar, bukan suara terbanyak dari komputer atau sekadar jumlah blok. Karena itu, Pavel membedakan melihat pembayaran dengan mendapat konfirmasi. Node sendiri juga tidak menjamin transaksi segera dimasukkan dan tidak menghilangkan reorganisasi, ketika cabang valid lain mengganti sebagian riwayat yang sebelumnya diikuti. [16]

Misalkan node Pavel tidak menerima suatu transaksi belum terkonfirmasi ke Mempool. Itu tidak otomatis berarti transaksi tersebut mustahil masuk blok valid. Aturan konsensus menentukan blok dan pembelanjaan yang sah menurut node. Relay policy lokal menambah ketentuan tentang transaksi belum terkonfirmasi yang diterima dan diteruskan, misalnya untuk melindungi sumber daya dari kelebihan beban. Kebijakan itu tidak diterapkan dengan cara yang sama pada transaksi di dalam blok yang diterima; di sana validitas menurut konsensuslah yang menentukan. Perbedaan pengaturan Mempool saja tidak membelah jaringan. Memahami batas ini membantu membaca perdebatan tentang Core tanpa menganggap setiap pengaturan sebagai perubahan aturan uang. [13]

Core menyimpan data blok, keadaan node, dan wallet jika digunakan. Pruning menghemat ruang dengan menghapus berkas blok lama serta data pembatalan perubahannya setelah diproses. Node tetap memeriksa blok baru, hanya tidak lagi menyimpan seluruh arsip siap pakai. Kueri historis atau pemindaian ulang pembayaran lama bisa membutuhkan pengunduhan kembali. Indeks adalah catatan pendukung untuk mempercepat pencarian; txindex, misalnya, tidak kompatibel dengan pruning. Pilih menurut layanan yang perlu disediakan node. Perbedaan terpenting adalah data blok publik bisa diunduh lagi, tetapi private key yang hilang tidak bisa dipulihkan darinya. Wallet Core memerlukan cadangan aman tersendiri. Saat program berjalan, gunakan fungsi pencadangan seperti backupwallet, bukan asal menyalin basis data yang sedang ditulisi. [11] [12]

Pavel memulai dari situs resmi dan membaca petunjuk rilis pilihannya. Checksum SHA-256 adalah sidik jari berkas unduhan: ia mendeteksi perbedaan dari berkas yang diharapkan. Namun, sendirian ia tidak memberi tahu siapa yang menerbitkan sidik jari tersebut. Karena itu, tanda tangan digital dan identitas kunci penandatangan juga harus diperiksa. Jika penyerang menyediakan program sekaligus checksum buatannya, kecocokan keduanya tidak menggagalkan serangan. Untuk pemeriksaan lebih jauh, proyek memakai build yang dapat direproduksi: pihak independen dapat menghasilkan berkas identik dari kode sumber yang sama dan membandingkan hasil. Guix membantu menyeragamkan lingkungan build. Ini memperkuat pemeriksaan asal program, bukan membuktikan kodenya bebas kesalahan. [8] [7]

Core menyediakan JSON-RPC, antarmuka yang memungkinkan program lain mengendalikannya. Antarmuka ini berguna untuk membaca keadaan node dan menghubungkan layanan, tetapi tergantung wallet serta izin yang tersedia, juga dapat memungkinkan operasi atas dana. Jadi, jangan memberikan kredensial kepada seseorang yang mengaku membantu. Antarmuka ini sendiri tidak mengenkripsi lalu lintas jaringan dan tidak dirancang untuk dibuka ke internet publik. Koneksi biasa ke node Bitcoin lain berbeda dari membuka kontrol tersebut. Untuk akses lokal, Core juga memakai kredensial sementara dalam berkas .cookie. Administrasi jarak jauh membutuhkan sambungan aman dan akses terbatas sesuai dokumentasi. Sekadar mencoba node tidak mengharuskan Anda membuka administrasinya kepada dunia. [14]

Siapa pun boleh mengusulkan perubahan kode. Kontributor lain membaca, menguji, dan mendiskusikannya; pengelola repositori, yaitu maintainers, dapat menggabungkan perubahan yang diterima. Hal itu tidak memberi mereka kendali jarak jauh atas node Pavel. Operator memilih perangkat lunak yang dijalankan. Pilihan itu pun bukan surat suara yang membuat satu orang dapat mengubah aturan semua orang: perubahan yang tidak kompatibel bisa memisahkan nodenya dari yang lain. Bitcoin Core adalah implementasi aturan yang penting, bukan perusahaan pemilik seluruh jaringan. Saat membaca pengumuman, bedakan usulan, penerimaan ke kode, penerbitan rilis, dan penggunaan nyata. Jarak antartahap itu bisa panjang. [15]

Anda bisa mulai menjalankan node tanpa menyimpan private key di dalamnya. Pavel memeriksa berkas dan tanda tangan, menunggu IBD selesai, lalu memastikan wallet pilihannya benar-benar mengambil data dari node sendiri. Setelah itu ia memantau koneksi, kemajuan blok, dan ruang kosong. Sebelum memperbarui, ia membaca release notes yang menjelaskan perubahan serta kemungkinan syarat migrasi; jika memakai wallet, ia memeriksa cadangan dan pemulihannya. Berkas diagnostik debug.log membantu mencari masalah, tetapi tidak sebaiknya dipublikasikan tanpa pertimbangan. Pruning, indeks, dan RPC harus sesuai kebutuhan, bukan panduan yang tidak dipahami dan disalin begitu saja. Node pribadi seharusnya menjadi alat pemeriksaan yang dapat dipahami. Ia tidak wajib untuk pembelian kecil pertama, tetapi berguna ketika Anda ingin tahu mengapa pembayaran dianggap valid. [12] [14]