Berapa banyak TPS di blockchain Anda?

Pertanyaan favorit tentang sistem terdistribusi apa pun dari orang non-teknis adalah “Berapa banyak tps di blockchain Anda?” Namun, angka yang diberikan sebagai jawaban biasanya tidak ada hubungannya dengan apa yang ingin didengar oleh si penanya. Faktanya, dia ingin bertanya “apakah blockchain Anda sesuai dengan kebutuhan bisnis saya,” dan persyaratan ini bukan hanya satu angka, tetapi banyak kondisi - berikut adalah toleransi kesalahan jaringan, persyaratan finalitas, ukuran, sifat transaksi, dan banyak parameter lainnya. Jadi jawaban atas pertanyaan “berapa tps” sepertinya tidak sederhana, dan hampir tidak pernah lengkap. Sebuah sistem terdistribusi dengan puluhan atau ratusan node yang melakukan perhitungan yang cukup rumit dapat berada dalam berbagai kondisi berbeda yang berkaitan dengan keadaan jaringan, isi dari blockchain, kegagalan teknis, masalah ekonomi, serangan terhadap jaringan dan banyak alasan lainnya. . Tahapan di mana masalah kinerja mungkin terjadi berbeda dari layanan tradisional, dan server jaringan blockchain adalah layanan jaringan yang menggabungkan fungsionalitas database, server web, dan klien torrent, yang membuatnya sangat kompleks dalam hal profil beban pada 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 terdesentralisasi, pendekatan untuk mengukurnya dan menemukan hambatan. Kami akan melihat berbagai masalah kinerja yang membatasi kecepatan penyediaan layanan kepada pengguna blockchain dan mencatat karakteristik fitur dari perangkat lunak jenis ini.

Tahapan permintaan layanan oleh klien blockchain

Untuk berbicara jujur ​​tentang kualitas layanan yang lebih atau kurang kompleks, Anda perlu memperhitungkan tidak hanya nilai rata-rata, tetapi juga maksimum/minimum, median, persentil. Secara teoritis, kita dapat berbicara tentang 1000 tps di beberapa blockchain, tetapi jika 900 transaksi diselesaikan dengan kecepatan luar biasa, dan 100 transaksi “terjebak” selama beberapa detik, maka waktu rata-rata yang dikumpulkan untuk semua transaksi bukanlah metrik yang sepenuhnya adil untuk klien. yang saya tidak dapat menyelesaikan transaksi dalam beberapa detik. “Lubang” sementara yang disebabkan oleh putaran konsensus atau perpecahan jaringan dapat sangat merusak layanan yang telah menunjukkan kinerja luar biasa di bangku pengujian.

Untuk mengidentifikasi hambatan tersebut, penting untuk memiliki pemahaman yang baik tentang tahapan di mana blockchain yang sebenarnya mungkin mengalami kesulitan dalam melayani pengguna. Mari kita jelaskan siklus pengiriman dan pemrosesan transaksi, serta memperoleh status baru dari blockchain, yang darinya klien dapat memverifikasi bahwa transaksinya telah diproses dan dipertanggungjawabkan.

  1. transaksi terbentuk pada klien
  2. transaksi ditandatangani pada klien
  3. klien memilih salah satu node dan mengirimkan transaksinya ke sana
  4. klien berlangganan pembaruan ke database status node, menunggu hasil transaksinya muncul
  5. node mendistribusikan transaksi melalui jaringan p2p
  6. beberapa atau satu BP (produsen blok) memproses akumulasi transaksi, memperbarui database negara
  7. BP membentuk blok baru setelah memproses jumlah transaksi yang diperlukan
  8. BP mendistribusikan blok baru melalui jaringan p2p
  9. blok baru dikirimkan ke node yang diakses klien
  10. node memperbarui basis data negara
  11. node melihat pembaruan mengenai klien dan mengiriminya pemberitahuan transaksi

Sekarang mari kita lihat lebih dekat tahap-tahap ini dan jelaskan potensi masalah kinerja di setiap tahap. Tidak seperti sistem terpusat, kami juga akan mempertimbangkan eksekusi kode pada klien jaringan. Seringkali, saat mengukur TPS, waktu pemrosesan transaksi dikumpulkan dari node, dan bukan dari klien - ini tidak sepenuhnya adil. Klien tidak peduli seberapa cepat node memproses transaksinya; yang paling penting baginya adalah saat informasi yang dapat dipercaya tentang transaksi ini yang termasuk dalam blockchain tersedia baginya. Metrik inilah yang pada dasarnya adalah waktu eksekusi transaksi. Ini berarti bahwa klien yang berbeda, bahkan mengirimkan transaksi yang sama, dapat menerima waktu yang sangat berbeda, tergantung pada saluran, beban dan kedekatan node, dll. Jadi pengukuran waktu ini pada klien mutlak diperlukan, karena ini adalah parameter yang perlu dioptimalkan.

Mempersiapkan transaksi di sisi klien

Mari kita mulai dengan dua poin pertama: transaksi dibuat dan ditandatangani oleh klien. Anehnya, hal ini juga bisa menjadi penghambat kinerja blockchain dari sudut pandang klien. Hal ini tidak biasa untuk layanan terpusat, yang mengambil alih semua penghitungan dan operasi dengan data, dan klien cukup menyiapkan permintaan singkat yang dapat meminta data atau penghitungan dalam jumlah besar, memperoleh hasil yang sudah jadi. Dalam blockchain, kode klien menjadi semakin kuat, dan inti blockchain menjadi semakin ringan, dan tugas komputasi besar-besaran biasanya ditransfer ke perangkat lunak klien. Di blockchain, ada klien yang bisa menyiapkan satu transaksi dalam waktu yang cukup lama (saya berbicara tentang berbagai bukti merkle, bukti ringkas, tanda tangan ambang batas, dan operasi kompleks lainnya di sisi klien). Contoh yang baik dari verifikasi on-chain yang mudah dan persiapan transaksi yang berat pada klien adalah bukti keanggotaan dalam daftar berdasarkan Merkle-tree, di sini artikel.

Selain itu, jangan lupa bahwa kode klien tidak hanya mengirim transaksi ke blockchain, namun terlebih dahulu menanyakan status blockchain - dan aktivitas ini dapat memengaruhi kemacetan jaringan dan node blockchain. Jadi, saat melakukan pengukuran, sebaiknya meniru perilaku kode klien selengkap mungkin. Bahkan jika di blockchain Anda ada klien ringan biasa yang membubuhkan tanda tangan digital biasa pada transaksi paling sederhana untuk mentransfer beberapa aset, setiap tahun masih ada perhitungan yang lebih besar pada klien, algoritma kripto semakin kuat, dan bagian pemrosesan ini bisa menjadi hambatan besar di masa depan. Oleh karena itu, berhati-hatilah dan jangan lewatkan situasi ketika, dalam transaksi yang berlangsung selama 3.5 detik, 2.5 detik dihabiskan untuk mempersiapkan dan menandatangani transaksi, dan 1.0 detik untuk mengirimkannya ke jaringan dan menunggu tanggapan. Untuk menilai risiko kemacetan ini, Anda perlu mengumpulkan metrik dari mesin klien, dan bukan hanya dari node blockchain.

Mengirim transaksi dan memantau statusnya

Langkah selanjutnya adalah mengirim transaksi ke node blockchain yang dipilih dan menerima status penerimaannya ke dalam kumpulan transaksi. Tahap ini mirip dengan akses database biasa; node harus mencatat transaksi di pool dan mulai mendistribusikan informasi tentangnya melalui jaringan p2p. Pendekatan untuk menilai kinerja di sini mirip dengan menilai kinerja layanan mikro API Web tradisional, dan transaksi itu sendiri di blockchain dapat diperbarui dan secara aktif mengubah statusnya. Secara umum, pembaruan informasi transaksi pada beberapa blockchain dapat terjadi beberapa kali, misalnya saat berpindah antar cabang rantai atau saat BP mengumumkan niatnya untuk memasukkan suatu transaksi ke dalam satu blok. Batasan ukuran kumpulan ini dan jumlah transaksi di dalamnya dapat memengaruhi kinerja blockchain. Jika kumpulan transaksi terisi hingga ukuran maksimum yang mungkin, atau tidak sesuai dengan RAM, kinerja jaringan dapat turun tajam. Blockchain tidak memiliki sarana terpusat untuk melindungi terhadap banjir pesan sampah, dan jika blockchain mendukung transaksi bervolume tinggi dan biaya rendah, hal ini dapat menyebabkan kumpulan transaksi meluap—potensi hambatan kinerja lainnya.

Dalam blockchain, klien mengirimkan transaksi ke node blockchain mana pun yang dia suka, hash transaksi biasanya diketahui oleh klien sebelum dikirim, jadi yang perlu dia lakukan hanyalah mencapai koneksi dan, setelah transmisi, menunggu hingga blockchain berubah. keadaannya, memungkinkan transaksinya. Perhatikan bahwa dengan mengukur “tps” Anda bisa mendapatkan hasil yang sangat berbeda untuk berbagai metode koneksi ke node blockchain. Ini bisa berupa RPC HTTP biasa atau WebSocket 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) untuk respons mengenai status transaksi. Jadi ketika mengukur “tps” perlu memperhitungkan cara klien terhubung ke node. Oleh karena itu, untuk menilai risiko kemacetan ini, benchmark blockchain harus mampu meniru klien dengan permintaan WebSocket dan HTTP RPC, dalam proporsi yang sesuai dengan jaringan sebenarnya, 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 blok melalui jaringan p2p

Dalam blockchain, jaringan peer-to-peer (p2p) digunakan untuk mentransfer transaksi dan blok antar peserta. Transaksi menyebar ke seluruh jaringan, mulai dari salah satu node, hingga mencapai produsen blok rekan, yang mengemas transaksi ke dalam blok dan, menggunakan p2p yang sama, mendistribusikan blok baru ke semua node jaringan. Dasar dari sebagian besar jaringan p2p modern adalah berbagai modifikasi protokol Kademlia. di sini adalah ringkasan yang bagus tentang protokol ini, dan di sini - sebuah artikel dengan berbagai pengukuran dalam jaringan BitTorrent, yang darinya orang dapat memahami bahwa jenis jaringan ini lebih kompleks dan kurang dapat diprediksi dibandingkan jaringan layanan terpusat yang dikonfigurasi secara kaku. Juga, di sini artikel tentang mengukur berbagai metrik menarik untuk node Ethereum.

Singkatnya, masing-masing rekan dalam jaringan tersebut memelihara daftar dinamis rekan-rekan lain yang meminta blok informasi yang dialamatkan oleh konten. Ketika rekan menerima permintaan, ia memberikan informasi yang diperlukan atau meneruskan permintaan tersebut ke rekan pseudo-acak berikutnya dari daftar, dan setelah menerima tanggapan, ia meneruskannya ke pemohon dan menyimpannya dalam cache untuk sementara waktu, memberikan ini blok informasi sebelumnya pada waktu berikutnya. Dengan demikian, informasi populer berakhir di sejumlah besar cache dari sejumlah besar rekan, dan informasi yang tidak populer secara bertahap digantikan. Rekan mencatat siapa yang telah mentransfer berapa banyak informasi kepada siapa, dan jaringan mencoba merangsang distributor aktif dengan meningkatkan peringkat mereka dan memberi mereka tingkat layanan yang lebih tinggi, yang secara otomatis mengeluarkan peserta yang tidak aktif dari daftar rekan.

Jadi, transaksi tersebut sekarang perlu didistribusikan ke seluruh jaringan sehingga produsen blok dapat melihatnya dan memasukkannya ke dalam blok. Node secara aktif “mendistribusikan” transaksi baru ke semua orang dan mendengarkan jaringan, menunggu blok di indeks di mana transaksi yang diperlukan akan muncul untuk memberi tahu klien yang menunggu. Waktu yang dibutuhkan jaringan untuk mentransfer informasi tentang transaksi baru dan blok satu sama lain di jaringan p2p bergantung pada sejumlah besar faktor: jumlah node jujur ​​​​yang bekerja di dekatnya (dari sudut pandang jaringan), “pemanasan” naik” dari cache node ini, ukuran blok, transaksi, sifat perubahan, geografi jaringan, jumlah node dan banyak faktor lainnya. Pengukuran kompleks metrik kinerja dalam jaringan seperti itu adalah masalah yang kompleks; perlu untuk mengevaluasi waktu pemrosesan permintaan secara bersamaan pada klien dan rekan (node ​​blockchain). Masalah dalam salah satu mekanisme p2p, penggusuran dan caching data yang salah, pengelolaan daftar rekan aktif yang tidak efektif, dan banyak faktor lainnya dapat menyebabkan penundaan yang memengaruhi efisiensi seluruh jaringan secara keseluruhan, dan hambatan ini adalah yang paling sulit untuk dianalisis. , tes dan interpretasi hasil.

Pemrosesan blockchain dan pembaruan basis data negara

Bagian terpenting dari blockchain adalah algoritma konsensus, penerapannya pada blok baru yang diterima dari jaringan dan pemrosesan transaksi dengan pencatatan hasilnya di database negara. Menambahkan blok baru ke rantai dan kemudian memilih rantai utama akan bekerja secepat mungkin. Namun, dalam kehidupan nyata, “seharusnya” tidak berarti “berhasil”, dan kita dapat, misalnya, membayangkan situasi di mana dua rantai panjang yang saling bersaing terus-menerus berpindah di antara mereka sendiri, mengubah metadata dari ribuan transaksi di kumpulan pada setiap peralihan. , dan terus-menerus mengembalikan database negara bagian. Tahap ini, dalam hal mendefinisikan kemacetan, lebih sederhana dibandingkan lapisan jaringan p2p, karena eksekusi transaksi dan algoritma konsensus sangat deterministik, dan lebih mudah untuk mengukur apa pun di sini.
Hal utama adalah jangan mengacaukan penurunan kinerja tahap ini secara acak dengan masalah jaringan - node lebih lambat dalam mengirimkan blok dan informasi tentang rantai utama, dan untuk klien eksternal ini mungkin terlihat seperti jaringan yang lambat, meskipun masalahnya terletak pada tempat yang sama sekali berbeda.

Untuk mengoptimalkan kinerja pada tahap ini, akan berguna untuk mengumpulkan dan memantau metrik dari node itu sendiri, dan memasukkan metrik yang berkaitan dengan pembaruan database negara: jumlah blok yang diproses pada node, ukurannya, jumlah transaksi, jumlah peralihan antar garpu rantai, jumlah blok yang tidak valid, waktu pengoperasian mesin virtual, waktu penerapan data, dll. Hal ini akan mencegah masalah jaringan menjadi bingung dengan kesalahan dalam algoritma pemrosesan rantai.

Mesin virtual yang memproses transaksi dapat menjadi sumber informasi berguna yang dapat mengoptimalkan pengoperasian blockchain. Jumlah alokasi memori, jumlah instruksi baca/tulis, dan metrik lain yang terkait dengan efisiensi eksekusi kode kontrak dapat memberikan banyak informasi berguna bagi pengembang. Pada saat yang sama, kontrak pintar adalah program, yang berarti secara teori kontrak tersebut dapat menggunakan sumber daya apa pun: cpu/memori/jaringan/penyimpanan, sehingga pemrosesan transaksi merupakan tahap yang agak tidak pasti, yang, terlebih lagi, sangat berubah ketika berpindah antar versi. dan ketika mengubah kode kontrak. Oleh karena itu, metrik yang terkait dengan pemrosesan transaksi juga diperlukan untuk mengoptimalkan kinerja blockchain secara efektif.

Penerimaan oleh klien atas pemberitahuan tentang penyertaan transaksi di blockchain

Ini adalah tahap akhir dari klien blockchain yang menerima layanan; dibandingkan dengan tahap lainnya, tidak ada biaya overhead yang besar, namun masih layak untuk mempertimbangkan kemungkinan klien menerima respons yang banyak dari node (misalnya, kontrak pintar mengembalikan array data). Bagaimanapun, poin ini adalah yang paling penting bagi orang yang mengajukan pertanyaan “berapa banyak tps di blockchain Anda?”, karena Pada saat ini, waktu penerimaan layanan dicatat.

Di tempat ini, selalu ada pengiriman waktu penuh yang harus dihabiskan klien untuk menunggu respons dari blockchain; inilah saat pengguna akan menunggu konfirmasi dalam aplikasinya, dan optimalisasinya itulah yang tugas utama para pengembang.

Kesimpulan

Hasilnya, kami dapat menjelaskan jenis operasi yang dilakukan pada blockchain dan membaginya menjadi beberapa kategori:

  1. transformasi kriptografi, konstruksi bukti
  2. jaringan peer-to-peer, transaksi dan replikasi blok
  3. pemrosesan transaksi, pelaksanaan kontrak pintar
  4. menerapkan perubahan dalam blockchain ke database negara, memperbarui data transaksi dan blok
  5. permintaan baca-saja ke database negara, API node blockchain, layanan berlangganan

Secara umum, persyaratan teknis untuk node blockchain modern sangat serius - CPU yang cepat untuk kriptografi, sejumlah besar RAM untuk menyimpan dan mengakses database negara dengan cepat, interaksi jaringan menggunakan sejumlah besar koneksi terbuka secara bersamaan, dan penyimpanan yang besar. Persyaratan yang tinggi dan banyaknya jenis operasi yang berbeda pasti mengarah pada fakta bahwa node mungkin tidak memiliki sumber daya yang cukup, dan kemudian salah satu tahapan yang dibahas di atas dapat menjadi hambatan lain dalam kinerja jaringan secara keseluruhan.

Saat merancang dan mengevaluasi kinerja blockchain, Anda harus mempertimbangkan semua poin ini. Untuk melakukan ini, Anda perlu mengumpulkan dan menganalisis metrik secara bersamaan dari klien dan node jaringan, mencari korelasi di antara keduanya, memperkirakan waktu yang diperlukan untuk memberikan layanan kepada klien, memperhitungkan semua sumber daya utama: cpu/memori/jaringan/penyimpanan , memahami bagaimana mereka digunakan dan mempengaruhi satu sama lain. Semua ini membuat membandingkan kecepatan berbagai blockchain dalam bentuk “berapa banyak TPS” menjadi tugas yang sangat sia-sia, karena ada banyak sekali konfigurasi dan status yang berbeda. Dalam sistem terpusat yang besar, cluster yang terdiri dari ratusan server, masalah ini juga rumit dan juga memerlukan pengumpulan sejumlah besar metrik yang berbeda, namun dalam blockchain, karena jaringan p2p, kontrak pemrosesan mesin virtual, ekonomi internal, jumlah derajat kebebasan jauh lebih besar, yang membuat pengujian bahkan pada beberapa server, ini non-indikatif dan hanya menunjukkan nilai perkiraan yang hampir tidak ada hubungannya dengan kenyataan.

Oleh karena itu, ketika mengembangkan inti blockchain, untuk mengevaluasi kinerja dan menjawab pertanyaan “apakah sudah ada peningkatan dibandingkan sebelumnya?” kami menggunakan perangkat lunak yang cukup kompleks yang mengatur peluncuran blockchain dengan lusinan node dan secara otomatis meluncurkan tolok ukur dan mengumpulkan metrik ; tanpa informasi ini sangat sulit untuk men-debug protokol yang bekerja dengan banyak peserta.

Jadi, ketika Anda menerima pertanyaan “berapa banyak TPS di blockchain Anda?”, tawarkan teh kepada lawan bicara Anda dan tanyakan apakah dia siap untuk melihat selusin grafik dan juga dengarkan ketiga kotak masalah kinerja blockchain dan saran Anda untuk menyelesaikannya...

Sumber: www.habr.com

Tambah komentar