Mengapa Kinerja Blockchain Sulit Diukur

Performa dan skalabilitas adalah tantangan yang banyak dibahas di ruang crypto, relevan dengan proyek Layer 1 (blockchain independen) dan solusi Layer 2 (seperti rollup dan saluran off-chain). Namun kami tidak memiliki metrik atau tolok ukur standar. Angka sering dilaporkan dengan cara yang tidak konsisten dan tidak lengkap, sehingga sulit untuk membandingkan proyek secara akurat dan seringkali mengaburkan hal yang paling penting dalam praktiknya. 

Kami membutuhkan pendekatan yang lebih bernuansa dan menyeluruh untuk mengukur dan membandingkan kinerja – yang memecah kinerja menjadi beberapa komponen, dan membandingkan timbal balik di berbagai sumbu. Dalam posting ini, saya mendefinisikan terminologi dasar, menguraikan tantangan, dan menawarkan pedoman dan prinsip utama untuk diingat saat mengevaluasi kinerja blockchain. 

Skalabilitas vs kinerja

Pertama, mari kita definisikan dua istilah, skalabilitas dan kinerja, yang memiliki arti ilmu komputer standar yang sering disalahgunakan dalam konteks blockchain. Performance mengukur apa itu sistem saat ini mampu mencapai. Seperti yang akan kita bahas di bawah, metrik kinerja mungkin mencakup transaksi per detik atau waktu konfirmasi transaksi rata-rata. Skalabilitas, di sisi lain, mengukur kemampuan sistem untuk meningkatkan kinerja dengan menambahkan sumber daya.

Perbedaan ini penting: Banyak pendekatan untuk meningkatkan kinerja tidak meningkatkan skalabilitas sama sekali, jika didefinisikan dengan benar. Contoh sederhananya adalah menggunakan skema tanda tangan digital yang lebih efisien, seperti tanda tangan BLS, yang kira-kira berukuran setengah dari tanda tangan Schnorr atau ECDSA. Jika Bitcoin beralih dari ECDSA ke BLS, jumlah transaksi per blok bisa naik 20-30%, meningkatkan kinerja dalam semalam. Tapi kita hanya bisa melakukan ini sekali — tidak ada skema tanda tangan yang lebih hemat ruang untuk beralih ke (tanda tangan BLS juga bisa diagregasi untuk menghemat lebih banyak ruang, tapi ini trik lain).

Sejumlah trik satu kali lainnya (seperti SegWit) dimungkinkan di blockchain, tetapi Anda memerlukan arsitektur yang dapat diskalakan untuk mencapai peningkatan kinerja berkelanjutan, di mana menambahkan lebih banyak sumber daya akan meningkatkan kinerja dari waktu ke waktu. Ini adalah kebijaksanaan konvensional di banyak sistem komputer lain juga, seperti membangun server web. Dengan beberapa trik umum, Anda dapat membangun satu server yang sangat cepat; tetapi pada akhirnya, Anda memerlukan arsitektur multi-server yang dapat memenuhi permintaan yang terus meningkat dengan terus menambahkan server ekstra.

Memahami perbedaannya juga membantu menghindari kesalahan kategori umum yang ditemukan dalam pernyataan seperti, “Blockchain X sangat skalabel, dapat menangani Y transaksi per detik!” Klaim kedua mungkin mengesankan, tapi itu a prestasi metrik, bukan metrik skalabilitas. Itu tidak berbicara tentang kemampuan untuk meningkatkan kinerja dengan menambahkan sumber daya.

Skalabilitas secara inheren membutuhkan eksploitasi paralelisme. Di ruang blockchain, penskalaan Layer 1 tampaknya membutuhkan sharding atau sesuatu yang terlihat seperti sharding. Konsep dasar sharding — membagi status menjadi beberapa bagian sehingga validator yang berbeda dapat memproses secara mandiri — sangat cocok dengan definisi skalabilitas. Bahkan ada lebih banyak opsi pada Layer 2 yang memungkinkan penambahan pemrosesan paralel — termasuk saluran off-chain, server rollup, dan sidechain.

Latensi vs. throughput

Secara klasik, kinerja sistem blockchain dievaluasi dalam dua dimensi, latensi dan throughput: Latensi mengukur seberapa cepat suatu transaksi dapat dikonfirmasi, sedangkan throughput mengukur tingkat agregat transaksi dari waktu ke waktu. Sumbu ini berlaku untuk sistem Lapisan 1 dan Lapisan 2, serta banyak jenis sistem komputer lainnya (seperti mesin permintaan basis data dan server web).

Sayangnya, latensi dan throughput keduanya rumit untuk diukur dan dibandingkan. Selain itu, pengguna individu sebenarnya tidak peduli dengan throughput (yang merupakan ukuran seluruh sistem). Yang benar-benar mereka pedulikan adalah latensi dan biaya transaksi — lebih khusus lagi, bahwa transaksi mereka dikonfirmasi secepat dan semurah mungkin. Meskipun banyak sistem komputer lain juga dievaluasi berdasarkan biaya/kinerja, biaya transaksi adalah sumbu kinerja yang agak baru untuk sistem blockchain yang tidak benar-benar ada dalam sistem komputer tradisional.

Tantangan dalam mengukur latensi

Latensi pada awalnya tampak sederhana: berapa lama waktu yang diperlukan untuk mengonfirmasi transaksi? Tetapi selalu ada beberapa cara berbeda untuk menjawab pertanyaan ini.

Pertama, kita dapat mengukur latensi antara titik waktu yang berbeda dan mendapatkan hasil yang berbeda. Misalnya, apakah kita mulai mengukur latensi saat pengguna menekan tombol "kirim" secara lokal, atau saat transaksi mengenai mempool? Dan apakah kita menghentikan jam ketika transaksi berada di blok yang diusulkan, atau ketika sebuah blok dikonfirmasi dengan satu atau enam blok tindak lanjut?

Pendekatan yang paling umum mengambil sudut pandang validator, mengukur dari saat klien pertama kali menyiarkan transaksi hingga saat transaksi “dikonfirmasi” secara wajar (dalam arti bahwa pedagang dunia nyata akan mempertimbangkan pembayaran yang diterima dan melepaskan barang dagangan) . Tentu saja, pedagang yang berbeda dapat menerapkan kriteria penerimaan yang berbeda, dan bahkan satu pedagang dapat menggunakan standar yang berbeda tergantung pada jumlah transaksi.

Pendekatan yang berpusat pada validator melewatkan beberapa hal yang penting dalam praktiknya. Pertama, ini mengabaikan latensi pada jaringan peer-to-peer (berapa lama waktu yang dibutuhkan dari saat klien menyiarkan transaksi hingga sebagian besar node telah mendengarnya?) dan latensi sisi klien (berapa lama waktu yang dibutuhkan untuk menyiapkan transaksi pada mesin lokal klien?). Latensi sisi klien mungkin sangat kecil dan dapat diprediksi untuk transaksi sederhana seperti menandatangani pembayaran Ethereum, tetapi dapat menjadi signifikan untuk kasus yang lebih kompleks seperti membuktikan bahwa transaksi Zcash yang terlindung benar.

Bahkan jika kami menstandarkan jendela waktu yang kami coba ukur dengan latensi, jawabannya hampir selalu itu tergantung. Tidak ada sistem cryptocurrency yang pernah dibuat yang menawarkan latensi transaksi tetap. Aturan dasar yang perlu diingat adalah:

Latensi adalah distribusi, bukan angka tunggal.

Komunitas riset jaringan telah lama memahami hal ini (lihat, misalnya, ini pembicaraan yang sangat baik oleh Gil Tene). Penekanan khusus ditempatkan pada "ekor panjang" distribusi, karena latensi yang sangat tinggi bahkan dalam 0.1% transaksi (atau kueri server web) akan sangat dampak pengguna akhir.

Dengan blockchain, latensi konfirmasi dapat bervariasi karena sejumlah alasan:

Pengelompokan: sebagian besar transaksi batch sistem dalam beberapa cara, misalnya menjadi blok pada sebagian besar sistem Layer 1. Ini mengarah ke latensi variabel, karena beberapa transaksi harus menunggu sampai batch terisi. Orang lain mungkin beruntung dan bergabung dengan kelompok terakhir. Transaksi ini langsung dikonfirmasi dan tidak mengalami latensi tambahan.

Kemacetan variabel: sebagian besar sistem mengalami kemacetan, yang berarti lebih banyak transaksi yang diposting (setidaknya beberapa waktu) daripada yang dapat segera ditangani oleh sistem. Seberapa padat dapat bervariasi ketika transaksi disiarkan pada waktu yang tidak dapat diprediksi (sering diabstraksikan sebagai a Proses Poison) atau ketika tingkat transaksi baru berubah sepanjang hari atau minggu, atau sebagai respons terhadap peristiwa eksternal seperti peluncuran NFT yang populer.

Varian lapisan konsensus: Mengkonfirmasi transaksi pada Layer 1 biasanya membutuhkan sekumpulan node terdistribusi untuk mencapai konsensus pada sebuah blok, yang dapat menambah penundaan variabel terlepas dari kemacetan. Sistem Proof-of-work menemukan blok pada waktu yang tidak dapat diprediksi (juga secara abstrak merupakan proses Poisson). Sistem proof-of-stake juga dapat menambahkan berbagai penundaan (misalnya, jika jumlah node yang online tidak mencukupi untuk membentuk komite dalam satu putaran, atau jika perubahan tampilan diperlukan sebagai tanggapan atas tabrakan pemimpin).

Untuk alasan ini, pedoman yang baik adalah:

Klaim tentang latensi harus menyajikan distribusi (atau histogram) waktu konfirmasi, bukan angka tunggal seperti rata-rata atau median.

Sementara ringkasan statistik seperti rata-rata, median, atau persentil memberikan gambaran parsial, mengevaluasi sistem secara akurat memerlukan pertimbangan seluruh distribusi. Dalam beberapa aplikasi, latensi rata-rata dapat memberikan wawasan yang baik jika distribusi latensi relatif sederhana (misalnya, Gaussian). Tetapi dalam cryptocurrency, hampir tidak pernah seperti ini: Biasanya, ada ekor panjang dari waktu konfirmasi yang lambat.

Jaringan saluran pembayaran (mis. Lightning Network) adalah contoh yang bagus. Solusi penskalaan L2 klasik, jaringan ini menawarkan konfirmasi pembayaran yang sangat cepat di sebagian besar waktu, tetapi kadang-kadang memerlukan pengaturan ulang saluran yang dapat meningkatkan latensi dengan urutan besarnya.

Dan bahkan jika kami memiliki statistik yang baik tentang distribusi latensi yang tepat, mereka kemungkinan akan bervariasi dari waktu ke waktu karena sistem dan permintaan pada sistem berubah. Juga tidak selalu jelas bagaimana membandingkan distribusi latensi antara sistem yang bersaing. Misalnya, pertimbangkan satu sistem yang mengonfirmasi transaksi dengan latensi terdistribusi secara merata antara 1 dan 2 menit (dengan rata-rata dan median 90 detik). Jika sistem pesaing mengkonfirmasi 95% transaksi tepat dalam 1 menit, dan 5% lainnya dalam 11 menit (dengan rata-rata 90 detik dan median 60 detik), sistem mana yang lebih baik? Jawabannya mungkin beberapa aplikasi lebih memilih yang pertama dan beberapa yang terakhir.

Terakhir, penting untuk diperhatikan bahwa di sebagian besar sistem, tidak semua transaksi diprioritaskan secara setara. Pengguna dapat membayar lebih untuk mendapatkan prioritas penyertaan yang lebih tinggi, jadi selain semua hal di atas, latensi bervariasi sebagai fungsi dari biaya transaksi yang dibayarkan. Kesimpulan:

Latensi itu rumit. Semakin banyak data yang dilaporkan, semakin baik. Idealnya, distribusi latensi lengkap harus diukur dalam berbagai kondisi kemacetan. Perincian latensi menjadi komponen yang berbeda (lokal, jaringan, pengelompokan, penundaan konsensus) juga membantu.

Tantangan dalam mengukur throughput

Throughput juga tampak sederhana pada pandangan pertama: berapa banyak transaksi yang dapat diproses sistem per detik? Dua kesulitan utama muncul: apa sebenarnya "transaksi" itu, dan apakah kita mengukur apa yang dilakukan sistem saat ini atau apa yang mungkin dapat dilakukannya?

Sementara "transaksi per detik" (atau tps) adalah standar de facto untuk mengukur kinerja blockchain, transaksi bermasalah sebagai unit pengukuran. Untuk sistem yang menawarkan programabilitas tujuan umum (“kontrak pintar”) atau bahkan fitur terbatas seperti transaksi multipleks Bitcoin atau opsi untuk verifikasi multi-sig, masalah mendasarnya adalah:

Tidak semua transaksi sama.

Ini jelas benar di Ethereum, di mana transaksi dapat menyertakan kode arbitrer dan mengubah status secara arbitrer. Gagasan gas di Ethereum digunakan untuk mengukur (dan membebankan biaya untuk) jumlah keseluruhan pekerjaan yang dilakukan transaksi, tetapi ini sangat spesifik untuk lingkungan eksekusi EVM. Tidak ada cara sederhana untuk membandingkan jumlah total pekerjaan yang dilakukan oleh satu set transaksi EVM dengan, misalnya, satu set transaksi Solana yang menggunakan lingkungan BPF. Membandingkan salah satu dari satu set transaksi Bitcoin sama-sama penuh.

Blockchain yang memisahkan lapisan transaksi menjadi lapisan konsensus dan lapisan eksekusi dapat memperjelas hal ini. Pada lapisan konsensus (murni), throughput dapat diukur dalam byte yang ditambahkan ke rantai per unit waktu. Lapisan eksekusi akan selalu lebih kompleks.

Lapisan eksekusi yang lebih sederhana, seperti server rollup yang hanya mendukung transaksi pembayaran, menghindari kesulitan perhitungan kuantifikasi. Bahkan dalam kasus ini, pembayaran dapat bervariasi dalam jumlah input dan output. Saluran pembayaran transaksi dapat bervariasi dalam jumlah "hop" yang diperlukan yang mempengaruhi throughput. Dan throughput server rollup dapat bergantung pada sejauh mana kumpulan transaksi dapat "dijaring" ke kumpulan perubahan ringkasan yang lebih kecil.

Tantangan lain terkait throughput adalah melampaui pengukuran kinerja saat ini secara empiris untuk mengevaluasi kapasitas teoretis. Ini memperkenalkan segala macam pertanyaan pemodelan untuk mengevaluasi potensi kapasitas. Pertama, kita harus memutuskan beban kerja transaksi yang realistis untuk lapisan eksekusi. Kedua, sistem nyata hampir tidak pernah mencapai kapasitas teoretis, terutama sistem blockchain. Untuk alasan ketangguhan, kami berharap implementasi node bersifat heterogen dan beragam dalam praktiknya (daripada semua klien menjalankan implementasi perangkat lunak tunggal). Hal ini membuat simulasi akurat dari throughput blockchain menjadi lebih sulit untuk dilakukan. 

Keseluruhan:

Klaim throughput membutuhkan penjelasan yang cermat tentang beban kerja transaksi dan populasi validator (kuantitas, implementasi, dan konektivitas jaringannya). Dengan tidak adanya standar yang jelas, beban kerja historis dari jaringan populer seperti Ethereum sudah cukup.

Pengorbanan latensi-throughput

Latensi dan throughput biasanya merupakan tradeoff. Sebagai Lefteris Kokoris-Kogias menguraikan, tradeoff ini seringkali tidak mulus, dengan titik belok di mana latensi meningkat tajam saat beban sistem mendekati throughput maksimumnya.

Sistem rollup tanpa pengetahuan menyajikan contoh alami dari pertukaran throughput/latensi. Sejumlah besar transaksi meningkatkan waktu pembuktian yang meningkatkan latensi. Tetapi jejak on-chain, baik dalam hal ukuran bukti dan biaya validasi, akan diamortisasi selama lebih banyak transaksi dengan ukuran batch yang lebih besar, sehingga meningkatkan throughput.

Biaya transaksi

Maklum, pengguna akhir lebih peduli tentang pertukaran antara latensi dan Biaya, bukan latensi dan throughput. Pengguna tidak memiliki alasan langsung untuk peduli dengan throughput sama sekali, hanya karena mereka dapat mengkonfirmasi transaksi dengan cepat dengan biaya serendah mungkin (dengan beberapa pengguna lebih peduli tentang biaya dan lainnya lebih tentang latensi). Pada tingkat tinggi, biaya dipengaruhi oleh beberapa faktor:

1. Berapa banyak permintaan pasar yang ada untuk melakukan transaksi?
2. Throughput keseluruhan apa yang dicapai oleh sistem?
3. Berapa pendapatan keseluruhan yang diberikan sistem kepada validator atau penambang?
4. Berapa banyak dari pendapatan ini didasarkan pada biaya transaksi vs hadiah inflasi?

Dua faktor pertama adalah kira-kira kurva penawaran/permintaan yang mengarah pada harga kliring pasar (meskipun diklaim bahwa penambang bertindak sebagai kartel untuk menaikkan biaya di atas titik ini). Semuanya sama, lebih banyak throughput cenderung mengarah pada biaya yang lebih rendah, tetapi masih banyak lagi yang terjadi.

Secara khusus, poin 3 dan 4 di atas adalah pertanyaan mendasar tentang desain sistem blockchain, namun kami tidak memiliki prinsip yang baik untuk keduanya. Kami memiliki beberapa pemahaman tentang keuntungan dan kerugian memberikan pendapatan kepada penambang dari hadiah inflasi vs. biaya transaksi. Namun, meskipun banyak analisis ekonomi dari protokol konsensus blockchain, kami masih belum memiliki model yang diterima secara luas untuk berapa banyak pendapatan yang harus masuk ke validator. Saat ini sebagian besar sistem membuat tebakan terpelajar tentang berapa banyak pendapatan yang cukup untuk membuat validator berperilaku jujur ​​tanpa mencekik penggunaan praktis sistem. Dalam model yang disederhanakan, dapat ditunjukkan bahwa biaya pemasangan serangan 51% berskala dengan hadiah untuk validator.

Menaikkan biaya serangan adalah hal yang baik, tetapi kami juga tidak tahu seberapa besar keamanan yang "cukup". Bayangkan Anda sedang mempertimbangkan untuk pergi ke dua taman hiburan. Salah satunya mengklaim membelanjakan 50% lebih sedikit untuk perawatan berkendara daripada yang lain. Apakah ide yang baik untuk pergi ke taman ini? Mungkin mereka lebih efisien dan mendapatkan keamanan yang setara dengan lebih sedikit uang. Mungkin yang lain membelanjakan lebih dari yang dibutuhkan untuk menjaga keamanan wahana tanpa manfaat. Tapi bisa juga taman pertama itu berbahaya. Sistem blockchain serupa. Setelah Anda memfaktorkan throughput, blockchain dengan biaya lebih rendah memiliki biaya lebih rendah karena memberi penghargaan (dan karena itu memberi insentif) lebih sedikit kepada validator mereka. Kami tidak memiliki alat yang baik hari ini untuk menilai apakah ini baik-baik saja atau apakah membuat sistem rentan terhadap serangan. Keseluruhan:

Membandingkan biaya antar sistem bisa menyesatkan. Meskipun biaya transaksi penting bagi pengguna, namun dipengaruhi oleh banyak faktor selain desain sistem itu sendiri. Throughput adalah metrik yang lebih baik untuk menganalisis sistem secara keseluruhan.

Kesimpulan

Mengevaluasi kinerja secara adil dan akurat itu sulit. Ini juga berlaku untuk mengukur performa mobil. Sama seperti dengan blockchain, orang yang berbeda akan peduli dengan hal yang berbeda. Dengan mobil, beberapa pengguna akan peduli dengan kecepatan atau akselerasi tertinggi, yang lain tentang jarak tempuh bahan bakar dan yang lainnya lagi tentang kapasitas derek. Semua ini tidak sepele untuk dievaluasi. Di AS, misalnya, Badan Perlindungan Lingkungan memiliki pedoman terperinci tentang bagaimana jarak tempuh bahan bakar dievaluasi serta bagaimana hal itu harus disajikan kepada pengguna di dealer.

Ruang blockchain masih jauh dari tingkat standardisasi ini. Di area tertentu, kita mungkin sampai di sana di masa mendatang dengan beban kerja standar untuk mengevaluasi throughput sistem atau grafik standar untuk menampilkan distribusi latensi. Untuk saat ini, pendekatan terbaik untuk evaluator dan pembangun adalah mengumpulkan dan mempublikasikan data sebanyak mungkin, dengan deskripsi terperinci tentang metodologi evaluasi, sehingga dapat direproduksi dan dibandingkan dengan sistem lain.