AssumeUTXO mempercepat awal penggunaan node Bitcoin dengan memuat snapshot, yaitu keadaan tersimpan pada blok tertentu. Untuk sementara, node mengandalkan sidik jari keadaan yang diharapkan dan tertanam dalam perangkat lunak. Node kemudian memproses riwayat sendiri dan membandingkan hasilnya; snapshot tidak menggantikan pekerjaan tersebut.
Peter memulai Full Node pertamanya, perangkat lunak yang memeriksa sendiri aturan Bitcoin. Blok mengelompokkan transaksi dalam satu kumpulan yang ditambahkan ke riwayat bersama. Proses awal biasa harus lebih dahulu melewati riwayat yang panjang. AssumeUTXO memungkinkannya mulai dari UTXO set yang sudah disiapkan: kumpulan keluaran transaksi yang belum dibelanjakan, masing-masing berisi nilai dan syarat untuk membelanjakannya. Snapshot menggambarkan keadaan setelah blok tertentu. Ini bukan arsip semua pembayaran atau bukti bahwa komputer Peter telah memeriksa seluruh masa lalu. [1] [3]
Nama berkas tidak membuat sebuah snapshot benar. Saat memuat melalui loadtxoutset, Bitcoin Core v29.0 memeriksa format, blok dasar (blok yang keadaannya dicatat dalam snapshot) dan parameter yang didukung. Program juga menghitung hash isi UTXO, sidik jari kriptografisnya, lalu membandingkannya dengan nilai yang diharapkan sebelum aktivasi. Isi yang diubah tidak bisa lolos hanya karena berkas diberi nama yang tampak tepercaya. [2] [3] [6]
Setelah snapshot diterima, node melanjutkan dari keadaan tersebut, memverifikasi blok berikutnya dan dapat mencapai ujung rantai saat ini. Node tidak menerimanya begitu saja: syarat pembelanjaan dan penciptaan bitcoin baru yang diizinkan tetap diperiksa. Keuntungannya, jalur menuju aktivitas terkini ini tidak harus menunggu riwayat lama selesai. Namun, itu bukan berarti riwayat lama sudah diperiksa secara lokal. [1] [6]
Pada saat yang sama, keadaan kedua dibangun dari blok historis, sejak awal sampai dasar snapshot. Ini adalah perhitungan mandiri berdasarkan riwayat, bukan salinan lain dari daftar yang diunduh. Karena itu, perangkat lunak sementara memelihara dua keadaan dengan kemajuan berbeda. Perintah teknis getchainstates menampilkannya; keadaan aktif yang mencapai blok terbaru tidak dengan sendirinya memastikan pekerjaan latar belakang selesai. [1] [8]
Hash yang diharapkan dan blok dasar yang didukung merupakan bagian dari versi perangkat lunak tertentu. Sampai node Peter selesai menghitung riwayat sendiri, ia bergantung pada kebenaran informasi bawaan itu. Membandingkan hash memungkinkan pemeriksaan kecocokan isi, tetapi tidak dengan sendirinya membuktikan bahwa isi tersebut berasal dari riwayat yang sah. Jika keadaan yang diharapkan ternyata keliru, penggunaan lebih awal akan bertumpu pada asumsi keliru tersebut. Itulah sebabnya verifikasi historis berikutnya berbeda dari pemeriksaan berkas saat dimuat. [2] [6]
Berkas dapat berasal dari operator lain, tetapi itu tidak memberinya hak menentukan keadaan yang diterima. Yang menentukan adalah kecocokan dengan nilai yang didukung program, bukan janji penyedia. Tidak semua snapshot dari semua blok dapat dimuat: dukungan bergantung pada versi dan jaringan. Pemeriksaan hash juga tidak menjamin berkas akan dikirim, atau menghilangkan waktu, bandwidth dan ruang disk yang dipakai untuk mengunduh serta memprosesnya. [2] [4] [7]
Ketika pekerjaan latar belakang mencapai blok dasar yang sama, node menghitung hash UTXO set yang dibangunnya lalu membandingkan dengan hash snapshot yang diharapkan. Ini bukan membandingkan keadaan hari ini dengan foto lama: keduanya mengacu pada titik riwayat yang sama. Jika berbeda, implementasi yang dijelaskan di sini menghentikan node dan berhenti menggunakan keadaan turunan snapshot. Perbedaan itu tidak disembunyikan atau dilaporkan sebagai verifikasi yang berhasil. [1] [6]
AssumeUTXO terutama mengubah waktu sampai node dapat digunakan. Pengunduhan dan verifikasi historis terus berjalan, sementara dua basis data keadaan dipelihara untuk sementara. Ini memerlukan pemrosesan dan aktivitas disk. Pruned Node menghemat ruang dengan menghapus berkas blok lama yang sudah diproses, tanpa melewatkan pemeriksaan aturan. Pruned Node juga dapat memakai snapshot, tetapi penghematan penyimpanan memiliki batasannya sendiri. Beberapa indeks pendukung harus memproses riwayat dari awal, sehingga node yang lebih cepat tersedia tidak membuat semua aplikasi terhubung langsung siap. [5] [7]
UTXO set berisi informasi keluaran yang belum dibelanjakan, bukan kunci privat yang mengizinkan pembelanjaan. Tanda tangan digital membuktikan otorisasi pembayaran menggunakan kunci privat, sebuah nilai angka rahasia, tanpa mengungkap kunci itu. UTXO set bukan cadangan dompet dan tidak mengembalikan Seed Phrase yang hilang, yaitu kata pemulihan dompet yang menggunakan mekanisme tersebut. Pembayaran lama juga belum tentu langsung muncul: mencarinya mungkin memerlukan blok sebelum snapshot. Mencadangkan kunci, menemukan riwayat dompet sendiri dan memverifikasi keadaan jaringan adalah tugas berbeda. [1] [7]
Nama yang mirip bisa membingungkan. AssumeUTXO mulai dari keadaan yang dimuat dan membangun kembali riwayat lama di latar belakang. Sebaliknya, assumevalid dapat melewati sebagian pemeriksaan skrip historis dalam kondisi tertentu, yakni pemeriksaan syarat pembelanjaan termasuk tanda tangan. Ini optimasi terpisah yang juga dapat memengaruhi verifikasi historis; selesainya AssumeUTXO saja tidak berarti optimasi itu dinonaktifkan. Saat membaca panduan, bedakan titik awal node, apa yang benar-benar diperiksa dan kapan masing-masing pemeriksaan selesai. [5] [6]
Untuk gambaran yang lebih utuh, baca entri ini bersama Initial Block Download, Pruned Node, Block Propagation, Nakamoto Consensus, Bitcoin, Bitcoin Core. Entri ini juga dirujuk dari Initial Block Download, Pruned Node, Utreexo.