Pemindai blok DIY (Blockchain explorer): sedikit teori

Pada artikel terakhir kita melihat alasan mengapa kita mungkin memerlukan blockexplorer kita sendiri. Saya perhatikan bahwa daftar ini masih jauh dari lengkap, tetapi kami berasumsi bahwa kami telah memutuskan - kami memerlukan sumber data kami sendiri tentang transaksi dan hubungannya dengan alamat.

Mari kita coba menentukan apa yang kita perlukan untuk ini. Jelasnya, pertama-tama kita memerlukan salinan dari blockchain yang diinginkan, dan salinan ini harus tetap terkini (disinkronkan dengan jaringan yang sesuai). Yang terakhir ini mengisyaratkan bahwa kita perlu mengimplementasikan protokol yang sepenuhnya sesuai (yang jelas akan mubazir dan sangat mahal) atau menginstal perangkat lunak yang sesuai, yang lebih rasional. Untuk Ethereum, misalnya Geth (go-ethreum), bitcoind atau btcd (implementasi dalam golang) untuk Bitcoin, atau perangkat lunak terkait lainnya. Syarat utamanya adalah akses ke blockchain penuh (atau bagian yang ingin Anda lacak). 

Untuk lebih jelasnya, mari kita ingat bagaimana informasi harus disimpan dalam blockchain. Bitcoin dan turunannya (sebut saja “klasik”) menggunakan konsep UTXO (Output Transaksi Tak Terpakai). Hasil suatu transaksi dapat disebut “Keluar”, dan setiap transaksi, dengan satu pengecualian, harus mengacu pada “Masuk”. Jadi, setiap transaksi berisi alamat pengirim dan alamat penerima dalam satu atau lain bentuk (kami tidak akan membahas detailnya sekarang, fakta adanya informasi tersebut sudah cukup). Efek sampingnya adalah dari informasi ini kita juga dapat membangun pohon transaksi yang memungkinkan kita melacak setiap Satoshi yang melewati jaringan. 

Jaringan Ethereum menangani informasi dengan sedikit berbeda. Seperti yang saya sebutkan di artikel terakhir, konsep Ethereum berbeda, dan informasi disimpan langsung tentang saldo alamat. Namun informasi mengenai transaksi masih dalam blok dan tersimpan di jaringan. Dengan demikian, pengindeksan transaksi dan hubungannya dengan alamat masih dimungkinkan. Dalam artikel ini, saya sengaja tidak menyentuh kontrak pintar dan operasi dengan token (ERC20/ERC721/ERC1155) dan apa yang disebut “Transaksi Internal” - pembahasan topik ini memerlukan artikel terpisah.

Apa yang tidak tersedia bagi kami? Blockchain yang menggunakan algoritma “Zero-knowledge proof”, seperti Monero dan ZCash, tidak dapat diindeks dengan cara ini, seperti yang disarankan oleh desainnya. 

Prosesnya akan mudah dan sederhana, meskipun sangat memakan waktu dan dalam hal jumlah ruang disk yang Anda perlukan.. 

Langkah pertama - kami meminta blok awal melalui RPC (implementasi tergantung pada jaringan tertentu) dan, melalui transaksi satu per satu, mendekodekannya dan memilih informasi yang ingin kami indeks. Kami mungkin tertarik dengan hash transaksi, alamat yang digunakan, arah transaksi, waktu dan nomor blok. Daftar lengkapnya bergantung pada tugas Anda dan sumber daya yang tersedia untuk Anda (hambatan utamanya adalah ruang disk).

Selanjutnya, kami menyimpan informasi yang kami minati di beberapa versi database, ambil blok berikutnya dan ulangi langkah-langkah yang dijelaskan. Tidak terlalu elegan, tapi sayangnya tidak ada resep lain. 

Dan muncul pertanyaan logis - mengapa pengembang blockchain sendiri tidak menyediakan akses ke informasi yang jelas berguna tersebut? Apa yang menghalangi Anda untuk segera menyimpan dan mengindeks data tersebut saat melakukan sinkronisasi dengan jaringan? 

Jawabannya akan tumpang tindih dengan penjelasan mengapa ruang disk menjadi hambatan. 

Pertama, contoh kecil. Mereka yang telah menerapkan node untuk Ethereum mengetahui bahwa ada beberapa opsi sinkronisasi Get. Dalam dokumentasi, bagian “Mode sinkronisasi” menyebutkan Node penuh dan Node cahaya. Yang terakhir ini tidak menarik bagi kami, tetapi Full node, pada gilirannya, secara kondisional dibagi menjadi Snap, Full dan Archive. Dan di sinilah hal-hal menjadi menarik, terutama jika Anda melihat lebih dekat ilustrasinya untuk melihat yang mana. Node Snap menyimpan informasi terperinci tentang 128 blok terakhir dan beberapa pos pemeriksaan di masa lalu yang relatif baru. Node Penuh, seperti ilustrasi berikut, menyimpan pos pemeriksaan dengan frekuensi tertentu hampir hingga “awal waktu”. Arsip sudah menyimpan informasi lengkap seluruh keberadaan Ethereum. Jika Anda menetapkan tujuan dan mencari tahu berapa banyak data yang disimpan oleh node Penuh, ternyata jumlahnya sekitar 1Tb (pada saat penulisan). Kami tidak akan membahas mekanisme “reorganisasi jaringan” dan trik lainnya. Kami tertarik pada hal lain, jumlah data yang disimpan oleh node Arsip sudah sekitar 16Tb(!). Ternyata lebih dari 90% informasi tentang blockchain tidak tersedia bagi kita?

Jika Anda menjalankan satu eksperimen sederhana, banyak hal yang akan terjadi. 

Mari kita gunakan layanan etherscan..io dan temukan transaksi acak “dari awal waktu”, misalnya 0x7d7062d6f865931e0bbbccea46551a73d5d58a6ef618d5592c35b5256a65e9ba(untuk sekitar Agustus 2015) dan coba dapatkan informasi tentangnya menggunakan konsol Dapatkan, disinkronkan dalam mode penuh. Kita bisa mendapatkan informasi ini, bukan? 

Selamat datang di konsol Geth JavaScript!

contoh: Geth/v1.12.0-stable-e501b3b0/linux-amd64/go1.20.3
di blok: 19122581 (Selasa 30 Jan 2024 23:24:11 GMT+0000 (UTC))
 datadir: /home/eth/ethereum
 modul: admin:1.0 debug:1.0 eth:1.0 penambang:1.0 net:1.0 pribadi:1.0 rpc:1.0 txpool:1.0 web3:1.0

Untuk keluar, tekan ctrl-d atau ketik exit
> eth.getTransaction("0x7d7062d6f865931e0bbbccea46551a73d5d58a6ef618d5592c35b5256a65e9ba")

batal

Um... Jadi belum ada informasi transaksinya? Tidak juga... Coba kita lihat isi blok dimana transaksi yang diinginkan berada, karena kita mengetahui nomor bloknya:

> eth.getBlockByNumber(122546)
{
...
   tanda pagar: "0xc58aa38cf7df6050d3be43f1557d61e3a28e3f34d7818b1644e6a9972003e80a",
...
   nomor: "0x1deb2",
...
   transaksi: ["0x7d7062d6f865931e0bbbccea46551a73d5d58a6ef618d5592c35b5256a65e9ba"],
...
}

Jadi, ini dia, di tempatnya! Jika kita menjalankan eth.getBlockByNumber(122546, true) (parameter tambahan yang menunjukkan permintaan untuk menampilkan semua informasi tentang transaksi di blok), maka kita akan menerima isi transaksi tersebut, dan misalnya kita akan mengetahui bahwa pengirimnya adalah alamat 0x5685620dce626248ccb7121e87fbc098fd5310bd dan penerima 0x9b0a028eafdecde3afc0fd00b7937098388b7c8a, serta semua informasi terkait. Mengapa kami tidak bisa mendapatkan informasi ini dengan bertanya secara langsung?

Tanpa membahas detail teknis, hanya node arsip yang sepenuhnya mengindeks seluruh blockchain dan semua koneksi antar blok, transaksi, dan alamat. Dan “bobot” dari indeks-indeks ini justru adalah hilangnya 15 terabyte informasi. 

Hal ini memberi kami pemahaman tentang volume data apa yang harus kami persiapkan. Namun, tugas spesifik Anda sama sekali tidak memerlukan pengindeksan mendetail seperti itu; kemungkinan besar database Anda akan lebih kompak. 

Sedangkan untuk bitcoin, terdapat mekanisme serupa, namun volume datanya jauh lebih kecil. Pada saat artikel ini ditulis, volume blockchain Bitcoin adalah 545 Gb, sehingga masalah yang ada akan jauh lebih sedikit...

Sebagai kesimpulan, beberapa kata tentang bagaimana Anda dapat mempercepat proses pengindeksan. Sama sekali tidak perlu memproses semua permintaan dengan menghubungi klien dari jaringan terkait. Seringkali, perangkat lunak untuk bekerja dengan blockchain bersifat terbuka, dan format database cukup terstandarisasi. Mungkin ada baiknya mempertimbangkan opsi untuk bekerja secara langsung dengan node yang sudah disinkronkan yang disimpan di disk, dan baru kemudian menyinkronkan blok baru. 

Pada artikel berikutnya kami akan mencoba merakit implementasi minimal dari alat yang tersedia untuk menyiapkan database pencarian alamat untuk berbagai blockchain.