Bagaimana mengukur kinerja jaringan blockchain. Metrik kunci

gambar


Ada banyak metrik yang terkait dengan logika dan kualitas blockchain. Mereka membantu mengidentifikasi kemacetan dalam kode dan menemukan masalah logis dan optimisasi dalam konsensus dan algoritma akhir dalam blockchains. Setiap pengembangan sistem terdistribusi, termasuk blockchains, membutuhkan analisis pekerjaan banyak node sekaligus. Mereka memungkinkan tim proyek untuk memantau keadaan seluruh jaringan blockchain, melihat masalah dengan masing-masing node, mendeteksi terjadinya serangan DoS pada jaringan dan banyak lagi. Mari kita lihat yang utama. Mari selami.


“Transaksi per detik”


Dalam hal sistem terdistribusi, TPS adalah angka yang sangat murung dan ambigu, yang tidak selalu mencerminkan kualitas nyata dari layanan yang diberikan kepada pengguna. Pengukuran TPS datang kepada kami dari database terdistribusi. TPS dalam database adalah beberapa standar untuk transaksi pengujian atau set mereka (beberapa INSERT, beberapa UPDATE, begitu banyak DELETE dengan latar belakang SELECT konstan) untuk konfigurasi cluster hard-coded atau bahkan pada mesin yang sama. Metrik ini biasanya hanya memberikan perkiraan kasar tentang kinerja database terdistribusi atau blockchains, karena waktu pemrosesan transaksi dapat sangat bervariasi tergantung pada banyak faktor.


Basis data yang berorientasi pada konsistensi (lihat "CAP-teorema") tidak melakukan transaksi sampai mereka menerima sejumlah konfirmasi dari node lain dan ini lambat. Dan basis data yang berorientasi ketersediaan menganggap transaksi yang hanya ditulis agar disk berhasil. Mereka segera memberikan data yang diperbarui kepada klien dan sangat cepat (meskipun di masa depan, transaksi ini dapat dibatalkan). Juga, jika transaksi yang digunakan dalam benchmark hanya memperbarui satu sel dengan data, TPS jelas akan lebih tinggi daripada dalam kasus di mana transaksi dapat mempengaruhi banyak sel dan memblokir satu sama lain. Algoritma untuk bekerja dengan kunci-kunci ini di setiap basis data diimplementasikan dengan cara mereka sendiri - itulah mengapa kita tidak melihat "kompetisi TPS" antara Oracle, MSSQL, PostgreSQL di satu sisi dan MongoDB, Redis, Tarantool di sisi lain - ini adalah mekanisme internal yang sangat berbeda dan tugas yang berbeda .


Menurut pendapat saya, "mengukur TPS" dari blockchain berarti melakukan serangkaian penuh pengukuran kinerjanya:


  • dalam kondisi yang berulang
  • dengan jumlah blok validator yang mendekati kenyataan
  • menggunakan berbagai jenis transaksi:
    • tipikal untuk blockchain yang dipelajari (misalnya, transfer () dari cryptocurrency utama)
    • memuat subsistem penyimpanan (sejumlah besar perubahan dari setiap transaksi)
    • memuat bandwidth (volume transaksi besar)
    • CPU-loading (dalam hal kripto-transformasi atau perhitungan besar-besaran)

Untuk berbicara tentang "transaksi per detik" yang berharga, Anda perlu menggambarkan semua kondisi (jumlah validator, geo-distribusi, level packetloss, dll.) Dan menggambarkan logika pembandingan. Dalam blockchains, hanya menggulirkan transaksi ke database internal tidak berarti penerimaannya dengan konsensus. Misalnya, dalam hal Proof-of-Work, secara statistik, transaksi tidak pernah selesai sama sekali, dan jika transaksi termasuk dalam blokir pada satu mesin, ini tidak berarti bahwa itu akan diterima oleh seluruh jaringan (misalnya, jika garpu lain menang).


Jika blockchain memiliki algoritme tambahan untuk memastikan finalitas transaksi (EOS, Ethereum 2.0, Parachains Polkadot yang menggunakan konsensus dengan finalitas GRANDPA), maka waktu pemrosesan dapat dianggap sebagai kesenjangan antara node “melihat” transaksi dan blok final berikutnya di mana transaksi ini dilakukan. termasuk. Seperti itu, lebih dekat dengan kenyataan, "TPS" jarang terlihat dalam janji proyek. Secara alami, mereka lebih rendah daripada yang dijelaskan dalam Whitepaper, tetapi mereka seinformatif mungkin.


Jadi saya memperingatkan Anda lagi, banyak arti yang berbeda dapat tertanam dalam istilah "TPS". Bersikap skeptis dan minta detail.


Metrik khusus blockchain


gambar


Tps lokal


Jumlah transaksi yang diproses oleh node dan waktu max / avg / min pemrosesan mereka pada node lokal sangat mudah untuk diukur, karena fungsi yang melakukan operasi ini biasanya secara eksplisit dialokasikan dalam kode. Anda cukup mengukur berapa lama transaksi bekerja dengan memperbarui database negara. Transaksi-transaksi ini mungkin belum diterima melalui konsensus, tetapi telah melewati validasi, dan node sudah dapat memberikan data yang diperbarui kepada klien (dengan asumsi bahwa rantai garpu tidak muncul).
Metrik ini tidak terlalu jujur: jika cabang lain dari rantai dipilih sebagai yang utama, maka statistik transaksi yang dibatalkan juga harus dibatalkan. Tetapi untuk pengujian, ini hampir selalu dapat diabaikan.


Seringkali, ini adalah angka yang ditulis dalam laporan singkat: "blockchain kami mendapat 8.000 tps kemarin," karena mudah untuk diukur - hanya satu simpul yang berjalan dan skrip yang memuatnya sudah cukup. Dalam hal ini, tidak ada penundaan jaringan, yang memperlambat jaringan mencapai konsensus, dan metrik menunjukkan kinerja database negara tanpa pengaruh jaringan. Angka ini bukan bandwidth sebenarnya dari jaringan blockchain, tetapi menunjukkan batas di mana ia akan berusaha jika konsensus dan jaringan cukup cepat.


Hasil dari setiap transaksi blockchain adalah beberapa pembaruan atom ke penyimpanan. Misalnya, transaksi pembayaran dalam Bitcoin adalah penghapusan beberapa UTXO lama (hapus) dan penambahan beberapa UTXO baru (masukkan), dan dalam Ethereum itu adalah pelaksanaan kode kontrak pintar pendek dan, sekali lagi, memperbarui beberapa pasangan nilai kunci. Jumlah operasi penulisan "atom" ini bisa menjadi metrik yang sangat baik yang memungkinkan Anda untuk mengidentifikasi kemacetan dalam subsistem penyimpanan dan logika transaksi internal.


Juga, node blockchain dapat diimplementasikan dalam beberapa bahasa pemrograman - ini lebih dapat diandalkan. Ini harus diperhitungkan ketika mengevaluasi kinerja jaringan, misalnya, node Ethereum ada dalam implementasi pada Rust dan Go. Blockchain lainnya juga berupaya memiliki implementasi tambahan untuk keandalan.


Jumlah blok yang diproduksi lokal


Metrik sederhana ini menunjukkan validator mana yang menghasilkan banyak blok. Ini adalah produk konsensus dan dapat dianggap sebagai produk utama untuk menilai "kegunaan" untuk jaringan validator individu.


Menghasilkan uang di setiap blok, validator tertarik pada operasi yang stabil dan keamanan mesin mereka. Nomor ini membantu menentukan calon validator mana yang paling memenuhi syarat, dilindungi, dan siap bekerja di jaringan publik dengan aset pengguna nyata. Nilai metrik dapat diperiksa secara publik dengan hanya mengunduh blockchain dan menghitung siapa yang menghasilkan berapa banyak blok.


Finalitas dan Blok Terakhir yang Tidak Dapat Direversikan


Dalam jaringan dengan finalitas yang diimplementasikan dengan jelas (EOS, Ethereum, Tendermint, Polkadot, dll), selain konsensus dasar, cepat (di mana satu tanda tangan validator per blok sudah cukup), beberapa blok memerlukan koordinasi oleh sekelompok validator. Blok-blok ini dianggap final, dan algoritma pengumpulan tanda tangan dianggap final. Tugas finalitas adalah untuk memastikan bahwa semua transaksi yang termasuk dalam blockchain sebelum blok final tidak pernah dipompa keluar dan tidak digantikan oleh cabang lain dari rantai. Ini adalah perlindungan terhadap serangan pembelanjaan ganda di jaringan proof-of-stake, dan cara cepat, dalam beberapa detik, mengembalikan konfirmasi transaksi cryptocurrency kepada pengguna yang dapat diandalkan.


Dari sudut pandang pengguna blockchain, transaksi tidak selesai pada saat ketika itu diterima oleh node, tetapi ketika sebuah blok muncul yang menyelesaikan rantai di mana transaksi berada. Untuk menyelesaikan blok, validator harus menerima blok ini di jaringan p2p, dan bertukar tanda tangan satu sama lain. Di sinilah kecepatan sebenarnya dari blockchain diperiksa, karena pengguna tertarik pada saat menyelesaikan blok dengan transaksinya, dan tidak hanya menerima dan menulisnya ke disk salah satu node.


Algoritma finalitas juga berbeda, berpotongan, dan bergabung dengan konsensus utama (untuk membaca: Casper dalam Ethereum, Last Irreversible Blocks di EOS, GRANDPA di Parity Polkadot dan modifikasinya, misalnya MixBytes RANDPA).


Untuk jaringan di mana tidak setiap blok diselesaikan, metrik yang berguna adalah kelambatan dari blok terakhir yang diselesaikan dari blok terakhir saat ini. Angka ini menunjukkan bagaimana validator tertinggal, menyetujui rantai yang benar. Jika gapnya besar, maka algoritma finalisasi membutuhkan analisis dan optimisasi tambahan.


Metrik blockchain lainnya


Metrik lainnya biasanya sangat bergantung pada jenis konsensus, sehingga tidak terlalu tepat untuk mewakili mereka di antara yang utama. Di antara parameter ini, misalnya: jumlah rantai garpu, panjangnya dalam blok, hunian blok dengan transaksi, dll. Mereka dapat digunakan untuk mengidentifikasi situasi pemisahan jaringan atau dengan cepat melokalisasi masalah dari validator tertentu.


Lapisan P2P


gambar


Sangat penting untuk mengingat dasar perantara dari jaringan blockchain - subsistem peer-to-peer. Dialah yang memperkenalkan keterlambatan samar dalam pengiriman blok dan transaksi antara validator. Ketika jumlah validator kecil, mereka dilokalkan, daftar rekan dikodekan, semuanya berfungsi dengan baik dan cepat. Tapi ada baiknya menambahkan validator, mendistribusikan node secara geografis dan meniru packetloss, karena kegagalan signifikan muncul di "tps".


Misalnya, ketika menguji konsensus EOS dengan algoritma finalitas opsional, meningkatkan jumlah validator bahkan menjadi 80-100 mesin yang ditempatkan di empat benua tidak secara signifikan mempengaruhi kecepatan mencapai finalitas. Pada saat yang sama, peningkatan packetloss sangat memengaruhi lag of finality, yang mengindikasikan perlunya konfigurasi tambahan dari lapisan p2p untuk resistensi yang lebih besar terhadap hilangnya paket jaringan, dan bukan pada latensi yang besar. Sayangnya, ada banyak pengaturan dan faktor yang berbeda, oleh karena itu, hanya tolok ukur yang memungkinkan kami untuk memahami jumlah validator yang memberikan kecepatan yang cukup nyaman dari blockchain.


Subsistem p2p perangkat dapat dipahami dari dokumentasi, misalnya, pada libp2p atau dokumentasi pada protokol Kademlia atau BitTorrent .


Metrik penting untuk p2p adalah:


  • lalu lintas masuk-keluar
  • jumlah koneksi yang berhasil / tidak berhasil dengan rekan-rekan lain
  • berapa kali data cache yang sebelumnya di-cache dikembalikan, dan berapa kali diperlukan untuk meneruskan permintaan lebih lanjut untuk mencari potongan yang diinginkan (analog dengan cache hit / misses)

Sebagai contoh, sejumlah besar kesalahan ketika mengakses data berarti bahwa hanya sejumlah kecil node yang memiliki data yang diminta, dan mereka tidak punya waktu untuk mendistribusikannya kepada semua orang, dan jumlah lalu lintas p2p yang diterima / diberikan akan memungkinkan Anda untuk membuat simpul yang memiliki masalah dengan konfigurasi jaringan atau saluran.


Metrik sistem simpul Blockchain


gambar


Metrik sistem standar dari node blockchain dijelaskan dalam sejumlah besar sumber, jadi saya akan menjelaskannya secara singkat. Peran mereka adalah untuk membantu mencari kemacetan dan kesalahan di semua bagian kode, yang menunjukkan subsistem node mana yang paling banyak dimuat dan tugas apa.


CPU


Mereka berbicara tentang berapa banyak perhitungan yang dilakukan prosesor. Jika beban CPU tinggi, maka simpul sedang menghitung sesuatu, aktif menggunakan logika atau FPU (hampir tidak pernah digunakan dalam blockchains). Dalam blockchains, ini bisa, misalnya, karena fakta bahwa node memeriksa tanda tangan elektronik, memproses transaksi dengan kriptografi berat, atau membuat perhitungan yang rumit.


CPU dapat "dipotong" menjadi beberapa metrik yang lebih berguna untuk memahami bagian mana dari kode yang paling mahal. Misalnya, sistem adalah kode kernel, pengguna adalah proses pengguna, io sedang menunggu i / o dari perangkat eksternal yang lambat (disk / jaringan), dll. Ini artikel terkait yang bagus.


Memori


Blokir modern menggunakan basis data nilai kunci (LevelDB, RocksDB), yang secara konstan menyimpan data panas di memori. Seperti halnya layanan yang dimuat, kebocoran memori selalu dimungkinkan sebagai akibat dari kesalahan atau serangan yang ditargetkan pada kode node. Jika konsumsi node memori meningkat atau meningkat tajam, maka ini kemungkinan besar disebabkan oleh peningkatan jumlah kunci dalam database negara, antrian transaksi besar, atau peningkatan jumlah pesan antara berbagai subsistem node. Memori yang terlalu sedikit dapat menunjukkan kemungkinan peningkatan batas data dalam blok atau kompleksitas transaksi maksimum.


Untuk node lengkap, yaitu https://habrastorage.org/webt/qa/sn/m5/qasnm5bougkjuagneevjkpg9x0w.png yang terkait dengan klien jaringan, metrik cache file juga penting. Klien mengakses berbagai bagian dari basis data negara dan log transaksi. Ini menciptakan peningkatan blok-blok lama dari disk, yang dapat mendesak keluar blok-blok baru, yang pada gilirannya memperlambat respons terhadap klien.


Jaringan


Metrik jaringan internal utama adalah jumlah lalu lintas dalam byte, jumlah paket jaringan yang dikirim dan diterima untuk masing-masing protokol, rasio packet loss. Dalam blockchains, metrik ini sering tidak terlalu diperhatikan, karena blockchains belum memproses transaksi dengan kecepatan 1 Gbit / detik.


Ada proyek-proyek blockchain yang memungkinkan pengguna untuk berbagi wifi mereka atau menyediakan layanan untuk menyimpan dan mentransfer file atau pesan. Saat menguji jaringan seperti itu, kuantitas dan kualitas lalu lintas melalui antarmuka jaringan menjadi metrik yang sangat penting, karena saluran jaringan yang ramai memengaruhi semua layanan lain pada mesin, tanpa kecuali.


Penyimpanan


Subsistem disk adalah komponen paling lambat dalam layanan apa pun dan seringkali menjadi penyebab masalah kinerja yang serius. Pencatatan yang berlebihan, cadangan yang tidak terduga, pola baca / tulis yang tidak nyaman, volume total blockchain yang besar - semua ini dapat menyebabkan perlambatan yang signifikan dalam pengoperasian node atau pada persyaratan perangkat keras yang sangat berlebihan.


Log transaksi secara teknis dapat dianggap sebagai WAL ( WAL ) untuk basis data keadaan, oleh karena itu metrik penyimpanan itu penting yang memungkinkan Anda untuk mencari kemacetan dalam mekanisme basis data nilai kunci modern. Ini adalah jumlah IOPS baca / tulis, latensi maksimum / minimum / rata-rata dan banyak metrik lain yang membantu mengoptimalkan operasi disk.


Kesimpulan


Jadi, kami memeriksa beberapa set metrik yang dapat memberikan informasi yang sangat berharga tentang operasi jaringan blockchain dan kemungkinan untuk optimalisasi. Untuk meringkas, Anda dapat mengumpulkannya dalam tiga kelompok:


  • metrik node blockchain:
    jumlah blok yang diproduksi, jumlah transaksi yang diproses, waktu pemrosesan, waktu penyelesaian, dll.
  • metrik p2p subsistem:
    jumlah permintaan hit / miss, jumlah rekan aktif, volume dan struktur lalu lintas P2P, dll.
  • metrik sistem node:
    cpu, memori, penyimpanan, jaringan, dll.

Masing-masing kelompok penting dengan caranya sendiri, karena di masing-masing subsistem mungkin ada kesalahan yang membatasi operasi komponen lainnya, dan memperlambat bahkan sejumlah kecil validator dapat berdampak serius pada seluruh jaringan. Juga, kesalahan paling sulit dalam konsensus dan algoritma finalitas hanya muncul dengan aliran transaksi yang besar atau perubahan dalam parameter konsensus. Analisis mereka membutuhkan kondisi pengujian yang dapat direproduksi dan skenario pemuatan yang rumit.


Pengembangan blockchains selalu merupakan orkestrasi dari beberapa mesin, skrip untuk meletakkan konfigurasi dan peluncuran terkoordinasi node dan benchmark, server untuk mengumpulkan metrik dan log dari semua mesin. Karena itu, ketika mengembangkan blockchain Anda, pertimbangkan untuk mempekerjakan devoop yang berkualitas - itu akan memberikan dukungan yang tak ternilai bagi tim pengembangan. Semoga beruntung

Source: https://habr.com/ru/post/id473846/


All Articles