Pertanyaan favorit tentang sistem terdistribusi dari spesialis non-teknis adalah “Berapa banyak tps yang ada di blockchain Anda?”. Namun, jumlah yang diberikan sebagai tanggapan biasanya memiliki sedikit kesamaan dengan apa yang ingin didengar si penanya. Bahkan, ia ingin bertanya "apakah blockchain Anda sesuai dengan persyaratan bisnis saya", dan persyaratan ini bukan satu nomor, tetapi banyak syarat - di sini adalah toleransi kesalahan jaringan, persyaratan untuk finalitas, ukuran, sifat transaksi dan banyak parameter lainnya. Jadi jawaban untuk pertanyaan "berapa banyak tps" tidak mungkin sederhana, dan hampir tidak akan pernah lengkap. Sistem terdistribusi dengan lusinan dan ratusan node yang melakukan kalkulasi yang cukup kompleks dapat berupa sejumlah besar negara yang berbeda terkait dengan keadaan jaringan, konten blockchain, kegagalan teknis, masalah ekonomi, serangan jaringan dan banyak alasan lainnya. Tahap-tahap di mana masalah kinerja dimungkinkan berbeda dari layanan tradisional, dan server jaringan blockchain adalah layanan jaringan yang menggabungkan fungsionalitas database, server web, dan klien torrent, yang membuatnya sangat sulit dalam hal profil beban untuk semua subsistem. : prosesor, memori, jaringan, penyimpanan

Kebetulan jaringan dan blockchain yang terdesentralisasi adalah perangkat lunak yang cukup spesifik dan tidak biasa bagi pengembang perangkat lunak terpusat. Oleh karena itu, saya ingin menyoroti aspek-aspek penting dari kinerja dan keberlanjutan jaringan yang didesentralisasi, pendekatan untuk mengukurnya dan menemukan hambatan. Kami akan mempertimbangkan berbagai masalah kinerja yang membatasi kecepatan penyediaan layanan untuk pengguna blockchain dan mencatat fitur khusus untuk perangkat lunak jenis ini.

Tahap permintaan layanan klien Blockchain

Untuk berbicara jujur tentang kualitas layanan yang kurang lebih kompleks, Anda perlu memperhitungkan tidak hanya nilai rata-rata, tetapi juga maksimum / minimum, median, persentil. Secara teoritis, kita dapat berbicara sekitar 1000 tps di beberapa blockchain, tetapi jika 900 transaksi dieksekusi dengan kecepatan luar biasa, dan 100 “dibekukan” selama beberapa detik, maka waktu rata-rata yang terkumpul untuk semua transaksi tidak cukup sebagai metrik jujur untuk klien yang dalam beberapa detik tidak dapat menyelesaikan transaksi. "Lubang" sementara yang disebabkan oleh ronde konsensus atau pemisahan jaringan yang hilang dapat sangat merusak layanan yang menunjukkan kinerja sangat baik di tempat uji.

Untuk mengidentifikasi hambatan seperti itu - dan perlu untuk memahami dengan baik tahapan di mana blockchain nyata mungkin mengalami kesulitan melayani pengguna. Mari kita jelaskan siklus pengiriman dan pemrosesan suatu transaksi, serta memperoleh status blockchain baru dari mana klien dapat memverifikasi bahwa transaksinya telah diproses dan diperhitungkan.

transaksi terbentuk pada klien
transaksi ditandatangani pada klien
klien memilih salah satu node dan mengirimkan transaksinya
klien berlangganan pembaruan basis data keadaan node, menunggu kemunculan hasil eksekusi transaksi
sebuah node menyebarkan transaksi melalui jaringan P2P
beberapa atau satu BP (blok produser) akan memproses akumulasi transaksi, memperbarui database negara
BP membentuk blok baru, memproses jumlah transaksi yang diperlukan
BP mendistribusikan blok baru melalui jaringan P2P
blok baru dikirim ke node yang diakses oleh klien
node memperbarui basis data keadaan
simpul melihat pembaruan yang berkaitan dengan klien dan mengirimkannya notifikasi transaksi

Sekarang mari kita melihat lebih dekat pada langkah-langkah ini dan menggambarkan potensi masalah kinerja di setiap langkah. Tidak seperti sistem terpusat, kami juga mempertimbangkan eksekusi kode pada klien jaringan. Cukup sering, ketika mengukur tps, waktu pemrosesan transaksi dikumpulkan dari node, dan bukan dari klien - ini tidak sepenuhnya jujur. Klien tidak peduli seberapa cepat node memproses transaksinya, hal terpenting baginya adalah saat ketika informasi yang dapat dipercaya tentang transaksi ini, termasuk dalam blockchain, tersedia baginya. Metrik inilah yang pada dasarnya adalah waktu yang diperlukan untuk menyelesaikan transaksi. Ini berarti bahwa klien yang berbeda, bahkan mengirim transaksi yang sama, dapat menerima waktu yang sama sekali berbeda, yang tergantung pada saluran, memuat dan kedekatan node, dll. Jadi sangat penting untuk mengukur waktu ini pada klien, karena parameter inilah yang perlu dioptimalkan.

Persiapan transaksi di sisi klien

Mari kita mulai dengan dua poin pertama: transaksi dibentuk dan ditandatangani oleh klien. Anehnya, ini juga bisa menjadi penghambat kinerja blockchain dari sudut pandang klien. Ini tidak biasa untuk layanan terpusat, yang mengambil semua perhitungan dan operasi data untuk diri mereka sendiri, dan klien hanya menyiapkan permintaan singkat yang dapat meminta sejumlah besar data atau perhitungan, memperoleh hasil yang selesai. Dalam blockchains, kode klien menjadi semakin kuat, dan inti blockchain menjadi semakin ringan, dan merupakan kebiasaan untuk memberikan tugas-tugas komputasi besar-besaran ke perangkat lunak klien. Ada klien di blockchains yang dapat menyiapkan satu transaksi untuk waktu yang agak lama (saya berbicara tentang berbagai bukti merkle, bukti ringkas, tanda tangan ambang batas dan operasi kompleks lainnya di sisi klien). Sebuah contoh yang baik dari verifikasi on-chain yang mudah dan persiapan yang sulit dari sebuah transaksi pada klien adalah bukti memiliki daftar berdasarkan Merkle-tree, di sini ada sebuah artikel .

Juga, jangan lupa bahwa kode klien tidak hanya mengirim transaksi ke blockchain, tetapi terlebih dahulu menanyakan status blockchain - dan aktivitas ini dapat memengaruhi beban jaringan dan node blockchain. Jadi, dengan melakukan pengukuran, masuk akal untuk meniru perilaku kode klien dengan cara yang paling lengkap. Bahkan jika blockchain Anda memiliki klien ringan reguler yang memberikan tanda tangan digital sederhana pada transaksi paling sederhana untuk mentransfer beberapa aset, setiap tahun ada perhitungan yang semakin besar pada klien, algoritma kriptografi menjadi lebih kuat, dan bagian proses ini dapat berubah menjadi hambatan besar ke masa depan Oleh karena itu, berhati-hatilah dan jangan sampai ketinggalan situasi ketika dalam transaksi yang berlangsung 3.5s, 2.5s dihabiskan untuk menyiapkan dan menandatangani transaksi, dan 1.0s- untuk mengirim ke jaringan dan menunggu jawaban. Untuk menilai risiko kemacetan ini, Anda perlu mengumpulkan metrik dari mesin klien, dan bukan hanya dari node blockchain.

Mengirim transaksi dan memonitor statusnya

Langkah selanjutnya adalah mengirim transaksi ke node blockchain yang dipilih dan menerima status adopsi di kumpulan transaksi. Tahap ini mirip dengan akses database normal, node harus menulis transaksi ke kumpulan dan mulai mendistribusikan informasi tentang hal itu melalui jaringan p2p. Pendekatan untuk mengevaluasi kinerja di sini mirip dengan mengevaluasi kinerja layanan Web API tradisional, dan transaksi dalam blockchain sendiri dapat diperbarui dan secara aktif mengubah statusnya. Secara umum, pembaruan informasi transaksi di beberapa blockchain mungkin terjadi beberapa kali, misalnya, ketika beralih di antara garpu rantai atau ketika BP menginformasikan tentang niatnya untuk memasukkan transaksi dalam blok. Keterbatasan volume kumpulan ini dan jumlah transaksi di dalamnya dapat memengaruhi kinerja blockchain. Jika kumpulan transaksi tersumbat ke ukuran maksimum yang mungkin, atau tidak sesuai dengan RAM, kinerja jaringan dapat turun secara dramatis. Blockchain tidak memiliki perlindungan terpusat terhadap aliran pesan sampah, dan jika blockchain mendukung transaksi volume tinggi dan biaya rendah, ini dapat menyebabkan limpahan kumpulan transaksi - ini adalah potensi bottleneck kinerja lainnya.

Dalam blockchains, klien mengirim transaksi ke node blockchain apa pun yang disukainya, hash transaksi biasanya diketahui oleh klien sebelum mengirim, jadi yang perlu ia lakukan hanyalah mendapatkan koneksi dan setelah transfer menunggu hingga blockchain mengubah statusnya, mengaktifkan transaksinya. Perhatikan bahwa dengan mengukur "tps" Anda bisa mendapatkan hasil yang sangat berbeda untuk berbagai cara menghubungkan ke node blockchain. Ini bisa berupa HTTP RPC atau WebSocket biasa, yang memungkinkan Anda menerapkan pola "berlangganan". Dalam kasus kedua, klien akan menerima pemberitahuan lebih awal, dan node akan menghabiskan lebih sedikit sumber daya (terutama memori dan lalu lintas) pada tanggapan tentang status transaksi. Jadi saat mengukur "tps", Anda perlu mempertimbangkan cara klien terhubung ke node. Oleh karena itu, untuk menilai risiko kemacetan ini, tolok ukur blockchain harus dapat meniru klien dengan permintaan WebSocket dan HTTP RPC, dalam pecahan yang sesuai dengan jaringan nyata, serta mengubah sifat transaksi dan ukurannya.

Untuk menilai risiko kemacetan ini, Anda juga perlu mengumpulkan metrik dari mesin klien, dan bukan hanya dari node blockchain.

Transmisi transaksi dan blokir melalui jaringan P2P

Dalam blockchains, jaringan peer-to-peer (p2p) digunakan untuk mentransfer antara peserta transaksi dan blok. Transaksi didistribusikan melalui jaringan, dimulai dengan salah satu node, hingga mencapai peer-blok produsen yang mengemas transaksi ke dalam blok dan menggunakan p2p yang sama mendistribusikan blok baru di semua node jaringan. Dasar dari sebagian besar jaringan P2P modern adalah berbagai modifikasi protokol Kademlia. Berikut ini adalah ikhtisar singkat yang baik dari protokol ini, dan di sini adalah artikel dengan berbagai pengukuran pada jaringan BitTorrent, yang menurutnya Anda dapat memahami bahwa jenis jaringan ini lebih rumit dan kurang dapat diprediksi daripada jaringan layanan terpusat yang dikonfigurasi dengan keras. Juga, inilah artikel tentang mengukur berbagai metrik yang menarik untuk node Ethereum.

Singkatnya, setiap rekan dalam jaringan semacam itu memelihara daftar dinamis rekan-rekan lain yang meminta blok informasi yang ditangani oleh konten. Setelah menerima permintaan tersebut, peer tersebut memberikan informasi yang diperlukan atau mengirimkan permintaan tersebut ke peer pseudo-random berikutnya dari daftar, dan setelah menerima respons, meneruskannya ke pemohon dan menyimpannya untuk sementara waktu, memberikan blok informasi ini di waktu berikutnya sebelumnya. Dengan demikian, informasi populer muncul di sejumlah besar cache di sejumlah besar rekan, dan informasi yang tidak populer secara bertahap ramai keluar. Peer melacak siapa yang mentransmisikan berapa banyak informasi kepada siapa, dan jaringan mencoba merangsang distributor aktif dengan meningkatkan peringkat mereka dan memberi mereka tingkat layanan yang lebih tinggi, secara otomatis menjatuhkan peserta yang tidak aktif dari daftar rekan.

Jadi, transaksi sekarang perlu didistribusikan di seluruh jaringan sehingga produsen blok dapat melihatnya dan memasukkannya ke dalam blok. Noda aktif "mendistribusikan" transaksi baru kepada semua orang dan mendengarkan jaringan, menunggu blok, dalam indeks di mana transaksi yang diperlukan akan muncul untuk memberi tahu klien yang menunggu. Waktu hingga jaringan saling mengirim informasi tentang transaksi baru dan blok dalam jaringan P2P tergantung pada sejumlah besar faktor: jumlah node jujur yang bekerja di dekatnya (dari sudut pandang jaringan), "pemanasan" cache dari node-node ini, ukuran blok, transaksi, sifat perubahan , geografi jaringan, jumlah node dan banyak faktor lainnya. Pengukuran yang komprehensif dari metrik kinerja dalam jaringan tersebut adalah masalah yang kompleks, perlu untuk secara bersamaan mengevaluasi waktu pemrosesan permintaan pada klien dan rekan kerja (node blockchain). Masalah dalam salah satu mekanisme p2p, ekstrusi dan caching data yang salah, manajemen yang tidak efisien dari daftar rekan aktif, dan banyak faktor lain dapat menyebabkan keterlambatan yang mempengaruhi efisiensi seluruh jaringan secara keseluruhan, dan hambatan ini adalah yang paling sulit untuk dianalisis, diuji dan interpretasi hasil.

Blok rantai memproses dan memperbarui basis data negara

Bagian terpenting dari pekerjaan blockchain adalah algoritma konsensus, aplikasinya untuk blok baru yang diterima dari jaringan dan pemrosesan transaksi dengan mencatat hasil dalam database negara. Menambahkan blok baru ke rantai dan pemilihan rantai utama selanjutnya harus bekerja secepat mungkin. Namun, dalam kehidupan nyata, "seharusnya" tidak berarti "bekerja," dan Anda dapat, misalnya, membayangkan situasi di mana dua rantai panjang yang saling bersaing terus-menerus beralih di antara mereka sendiri, mengubah metadata ribuan transaksi di kumpulan pada setiap saklar, dan terus-menerus memutar kembali keadaan basis data negara. Langkah ini, dalam hal menentukan bottleneck, lebih sederhana daripada lapisan p2p jaringan, karena eksekusi transaksi dan algoritma konsensus ditentukan dengan ketat, dan mengukur apa pun di sini lebih mudah.
Hal utama adalah untuk tidak membingungkan penurunan kinerja tahap ini secara acak dengan masalah jaringan - node memberikan blok dan informasi tentang rantai utama lebih lambat dan untuk klien eksternal mungkin terlihat seperti jaringan lambat, meskipun masalahnya terletak di tempat yang sama sekali berbeda.

Untuk mengoptimalkan kinerja pada tahap ini, penting untuk mengumpulkan dan memantau metrik dari node itu sendiri, dan termasuk yang terkait dengan pembaruan database-negara: jumlah blok yang diproses pada node, ukurannya, jumlah transaksi, jumlah sakelar antara garpu rantai, jumlah blok tidak valid , runtime mesin virtual, waktu komit data, dll. Ini tidak akan membingungkan masalah jaringan dengan kesalahan dalam algoritma pemrosesan rantai.

Mesin virtual yang berjalan melalui transaksi dapat menjadi sumber informasi yang berguna yang dapat mengoptimalkan operasi blockchain. Jumlah alokasi memori, jumlah instruksi baca / tulis, dan metrik lainnya mengenai efisiensi pelaksanaan kode kontrak dapat memberikan banyak informasi yang berguna bagi pengembang. Pada saat yang sama, kontrak pintar adalah program, yang berarti secara teori mereka dapat menggunakan sumber daya apa pun: cpu / memori / jaringan / penyimpanan, sehingga pemrosesan transaksi merupakan langkah yang agak tidak pasti, yang selain itu sangat berubah ketika beralih antar versi dan saat mengubah kode kontrak. Oleh karena itu, metrik mengenai pemrosesan transaksi juga diperlukan untuk secara efektif mengoptimalkan kinerja blockchain.

Klien menerima pemberitahuan tentang penyertaan transaksi dalam blockchain

Ini adalah tahap terakhir dari menerima layanan blockchain oleh klien, dibandingkan dengan tahap lain tidak ada overhead yang besar, tetapi masih layak mempertimbangkan kemungkinan klien menerima respon volume dari sebuah node (misalnya, kontrak pintar yang mengembalikan array data). Bagaimanapun, momen ini adalah yang paling penting bagi orang yang mengajukan pertanyaan "berapa banyak tps dalam blockchain Anda?", Karena pada saat ini waktu menerima layanan sudah diperbaiki.

Di tempat ini, selalu ada pengiriman penuh waktu sehingga klien harus menunggu respons dari blockchain, inilah saatnya pengguna akan menunggu konfirmasi dalam aplikasinya, dan pengoptimalan itulah yang menjadi tugas utama pengembang.

Kesimpulan

Akibatnya, dimungkinkan untuk menggambarkan jenis operasi yang dilakukan pada blockchain dan membaginya ke dalam beberapa kategori:

transformasi kriptografi, pembuatan bukti
jaringan peer-to-peer, transaksi dan memblokir replikasi
pemrosesan transaksi, pelaksanaan kontrak pintar
menerapkan perubahan dalam blockchain ke database negara, memperbarui transaksi dan memblokir data
permintaan hanya baca untuk menyatakan database, blockchain node API, layanan berlangganan

Secara umum, persyaratan teknis untuk node blockchains modern sangat serius - mereka adalah CPU cepat untuk kriptografi, sejumlah besar RAM untuk menyimpan dan dengan cepat mengakses database negara, interaksi jaringan menggunakan sejumlah besar koneksi terbuka secara bersamaan, dan penyimpanan yang banyak. Persyaratan yang begitu tinggi dan banyaknya berbagai jenis operasi pasti mengarah pada fakta bahwa sumber daya dari node mungkin tidak cukup, dan kemudian salah satu langkah yang dibahas di atas dapat menjadi penghambat berikutnya untuk kinerja jaringan secara keseluruhan.

Ketika mengembangkan dan mengevaluasi kinerja blockchain, Anda harus mempertimbangkan semua poin ini. Untuk melakukan ini, Anda perlu mengumpulkan dan menganalisis metrik pada saat yang sama dari klien dan node jaringan, mencari korelasi di antara mereka, mengevaluasi waktu layanan diberikan kepada pelanggan, memperhitungkan semua sumber daya utama: cpu / memori / jaringan / penyimpanan, memahami bagaimana mereka digunakan dan saling mempengaruhi. Semua ini membuat membandingkan kecepatan berbagai blockchain dalam bentuk "berapa banyak TPS" tugas yang sangat tidak berterima, karena ada sejumlah besar konfigurasi dan kondisi yang berbeda. Dalam sistem terpusat besar, kelompok ratusan server, masalah ini juga kompleks dan juga memerlukan pengumpulan sejumlah besar metrik yang berbeda, tetapi di blockchains, karena jaringan p2p, mesin virtual yang menjalankan kontrak, ekonomi internal, jumlah derajat kebebasan jauh lebih besar, yang membuat pengujian bahkan di beberapa server tidak ditampilkan dan hanya menampilkan nilai perkiraan yang hampir tidak ada hubungannya dengan kenyataan.

Oleh karena itu, ketika mengembangkan blockchain pada intinya, untuk mengevaluasi kinerja dan menjawab pertanyaan “apakah sudah membaik dibandingkan dengan yang terakhir kali”, kami menggunakan perangkat lunak yang agak rumit, mengatur peluncuran blockchain dengan puluhan node dan secara otomatis meluncurkan benchmark dan mengumpulkan metrik, tanpa informasi ini sangat sulit untuk di-debug Protokol yang bekerja dengan banyak peserta.

Jadi, setelah menerima pertanyaan "berapa banyak TPS di blockchain Anda?", Tawarkan orang yang Anda ajak bicara minum teh dan cari tahu apakah dia siap untuk berkenalan dengan selusin grafik dan juga dengarkan semua tiga kotak masalah kinerja blockchain dan saran Anda untuk menyelesaikannya ...

Berapa banyak TPS di blockchain Anda?