A16z: Mengapa kinerja blockchain sulit diukur?

Asli: https://a16zcrypto.com/why-blockchain-performance-is-hard-to-measure/

Oleh Joseph Bonneau

Performa dan skalabilitas adalah tantangan yang banyak dibahas di ruang crypto, relevan dengan proyek layer 1 (blockchain mandiri) dan solusi layer 2 seperti rollup dan saluran off-chain. Namun, kami tidak memiliki metrik atau tolok ukur standar. Angka sering dilaporkan secara tidak konsisten dan tidak lengkap, membuat perbandingan proyek yang akurat menjadi sulit dan seringkali mengaburkan apa yang paling penting dalam praktiknya.

Kami membutuhkan pendekatan yang lebih terperinci dan menyeluruh untuk mengukur dan membandingkan kinerja—yang memecah kinerja menjadi komponen dan membandingkannya dengan kompromi di beberapa sumbu. Dalam posting ini, saya mendefinisikan istilah dasar, garis besar tantangan, dan memberikan pedoman dan prinsip utama untuk diingat saat mengevaluasi kinerja blockchain.

Skalabilitas dan Performa

Pertama, mari kita definisikan dua istilah, skalabilitas dan kinerja, yang memiliki arti ilmu komputer standar dan sering disalahgunakan dalam konteks blockchain. Kinerja mengukur apa yang dapat dicapai oleh sistem saat ini. 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: jika didefinisikan dengan baik, banyak cara untuk meningkatkan kinerja tidak akan meningkatkan skalabilitas sama sekali. Contoh sederhananya adalah menggunakan skema tanda tangan digital yang lebih efisien, seperti tanda tangan BLS, yang ukurannya sekitar setengah dari tanda tangan Schnorr atau ECDSA. Jika Bitcoin beralih dari ECDSA ke BLS, jumlah transaksi per blok dapat meningkat 20-30%, meningkatkan kinerja dalam semalam. Tapi kita hanya bisa melakukan ini sekali - tidak ada lagi skema tanda tangan hemat ruang untuk beralih (tanda tangan BLS juga bisa diagregasi untuk menghemat lebih banyak ruang, tapi ini trik satu kali).

Banyak trik sekali pakai lainnya (seperti Segregated Witness) 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 juga merupakan kebijaksanaan konvensional di banyak sistem komputer lainnya, seperti membangun server web. Dengan beberapa trik umum, Anda dapat membangun server yang sangat cepat; tetapi pada akhirnya, Anda memerlukan arsitektur multi-server yang terus menambahkan server tambahan untuk memenuhi permintaan yang terus meningkat.

Memahami perbedaan ini juga membantu menghindari kesalahan kelas umum yang ditemukan dalam pernyataan seperti "Blockchain X sangat terukur, dapat memproses Y transaksi per detik!" Pernyataan kedua mungkin mengesankan, tetapi ini adalah metrik kinerja, bukan metrik skalabilitas. Itu tidak memperhitungkan kemampuan untuk meningkatkan kinerja dengan menambahkan sumber daya.

Skalabilitas secara inheren membutuhkan eksploitasi paralelisme. Di ruang blockchain, penskalaan lapisan 1 tampaknya membutuhkan sharding atau yang terlihat seperti sharding. Konsep dasar sharding — memecah status menjadi potongan-potongan sehingga validator yang berbeda dapat memprosesnya secara mandiri — sangat cocok dengan definisi skalabilitas. Lapisan 2 memiliki lebih banyak opsi yang memungkinkan penambahan pemrosesan paralel — termasuk saluran off-chain, server rollup, dan sidechain.

Latensi vs. Throughput

Secara tradisional, kinerja sistem blockchain dievaluasi berdasarkan dua dimensi: latensi dan throughput: latensi mengukur seberapa cepat transaksi individu dapat dikonfirmasi, sementara throughput mengukur tingkat agregat transaksi dari waktu ke waktu. Sumbu ini berlaku untuk sistem Tingkat 1 dan Tingkat 2, serta banyak jenis sistem komputer lainnya seperti mesin permintaan basis data dan server Web.

Sayangnya, latensi dan throughput sulit diukur dan dibandingkan. Juga, pengguna individu tidak terlalu peduli dengan throughput (ini adalah ukuran seluruh sistem). Yang benar-benar mereka pedulikan adalah latensi dan biaya transaksi — lebih khusus lagi, transaksi mereka dikonfirmasi secepat mungkin dan semurah mungkin. Sementara banyak sistem komputer lain juga dievaluasi berdasarkan biaya/kinerja, biaya transaksi mewakili sumbu kinerja baru untuk sistem blockchain yang tidak ada dalam sistem komputer tradisional.

Tantangan Mengukur Latensi

Penundaan tampaknya sederhana pada awalnya: berapa lama waktu yang diperlukan untuk konfirmasi transaksi? Tetapi selalu ada beberapa cara berbeda untuk menjawab pertanyaan ini.

Pertama, kita dapat mengukur penundaan antara titik waktu yang berbeda dan mendapatkan hasil yang berbeda. Misalnya, apakah kita mulai mengukur latensi saat pengguna menekan tombol "kirim" lokal, atau saat transaksi mengenai mempool? Apakah kita menghentikan waktu saat sebuah transaksi berada di blok yang diusulkan, atau saat sebuah blok dikonfirmasi oleh satu atau enam blok berikutnya?

Cara paling umum untuk mengukur ini adalah dari sudut pandang validator, dari saat klien pertama kali menyiarkan transaksi hingga saat "dikonfirmasi" secara wajar (dalam arti bahwa pedagang dunia nyata akan mempertimbangkan untuk menerima pembayaran dan mengirimkan item) Tentu saja, pedagang yang berbeda mungkin memiliki kriteria penerimaan yang berbeda, dan bahkan satu pedagang mungkin memiliki kriteria yang berbeda berdasarkan jumlah transaksi.

Pendekatan validator-centric mengabaikan beberapa hal yang penting dalam praktiknya. Pertama, ini mengabaikan latensi pada jaringan peer-to-peer (berapa lama klien menyiarkan transaksi hingga mayoritas node mendengarnya?) dan latensi sisi klien (berapa lama waktu yang dibutuhkan transaksi untuk disiapkan pada mesin lokal klien?). Untuk transaksi sederhana seperti menandatangani pembayaran Ethereum, latensi sisi klien bisa sangat kecil dan dapat diprediksi, tetapi untuk kasus yang lebih rumit seperti membuktikan bahwa transaksi Zcash yang dilindungi benar, ini bisa menjadi signifikan.

Bahkan jika kami menormalkan jendela waktu yang kami coba ukur dengan latensi, jawabannya hampir selalu bergantung padanya. Belum pernah ada sistem cryptocurrency yang menawarkan latensi transaksi tetap. Aturan dasar praktis yang perlu diingat adalah:

Latensi adalah distribusi, bukan angka.

Komunitas riset jaringan telah lama memahami hal ini. Penekanan khusus ditempatkan pada "ekor panjang" distribusi, karena latensi tinggi bahkan dalam 0,1% transaksi (atau kueri server web) dapat sangat memengaruhi pengguna akhir.

Dalam blockchain, penundaan konfirmasi dapat bervariasi karena sejumlah alasan:

Batching: Sebagian besar sistem mengelompokkan transaksi dalam beberapa cara, seperti blok pada sebagian besar sistem layer 1. Ini menyebabkan latensi variabel karena beberapa transaksi harus menunggu hingga kumpulan terisi. Orang lain mungkin beruntung dan bergabung dengan kelompok terakhir. Transaksi ini dikonfirmasi secara instan tanpa penundaan tambahan.

Kemacetan variabel: Sebagian besar sistem mengalami kemacetan, artinya ada (setidaknya beberapa waktu) lebih banyak transaksi untuk diproses daripada yang dapat ditangani sistem sekaligus. Tingkat kemacetan dapat meningkat ketika transaksi disiarkan pada waktu yang tidak dapat diprediksi (sering diabstraksi sebagai proses Poisson), atau ketika tingkat transaksi baru berubah selama satu hari atau satu minggu, atau sebagai respons terhadap peristiwa eksternal seperti penerbitan NFT yang populer. .

Perbedaan lapisan konsensus: Mengonfirmasi transaksi pada lapisan 1 biasanya memerlukan kumpulan node terdistribusi untuk mencapai konsensus pada blok, yang dapat menambah latensi variabel tanpa terpengaruh oleh kemacetan. Sistem proof-of-work menemukan blok pada waktu yang tidak dapat diprediksi (juga diabstraksikan sebagai proses Poisson). Sistem Proof-of-Stake juga dapat menambahkan berbagai penundaan (misalnya, jika tidak ada cukup node online untuk membentuk komite dalam satu putaran, atau jika tampilan perlu diubah sebagai respons terhadap leader crashing).

Untuk alasan ini, pedoman yang baik adalah:

Pernyataan 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 sebagian gambaran, penilaian yang akurat dari suatu sistem membutuhkan pertimbangan dari keseluruhan distribusi. Dalam beberapa aplikasi, latensi rata-rata dapat memberikan wawasan yang baik jika distribusi latensi relatif sederhana (misalnya, Gaussian). Namun dalam mata uang kripto, hal ini hampir tidak pernah terjadi: biasanya, waktu konfirmasi akan sangat lama.

Jaringan saluran pembayaran seperti Lightning Network adalah contoh yang bagus. Sebagai solusi penskalaan L2 klasik, jaringan ini memberikan konfirmasi pembayaran yang sangat cepat dalam banyak kasus, tetapi terkadang memerlukan pengaturan ulang saluran, yang dapat menambah urutan besarnya ke latensi.

Meskipun kami memiliki statistik yang baik tentang distribusi latensi yang tepat, statistik tersebut dapat bervariasi dari waktu ke waktu karena sistem dan persyaratan sistem berubah. Juga tidak selalu jelas bagaimana membandingkan distribusi latensi antara sistem yang bersaing. Misalnya, perhatikan sistem yang mengonfirmasi transaksi dengan latensi terdistribusi secara merata antara 1 dan 2 menit (rata-rata dan median 90 detik). Jika sistem pesaing secara akurat mengonfirmasi 95% transaksi dalam 1 menit dan 5% lainnya dalam 11 menit (rata-rata 90 detik, median 60 detik), sistem mana yang lebih baik? Jawabannya mungkin beberapa aplikasi lebih suka yang pertama dan beberapa lebih suka yang terakhir.

Terakhir, penting untuk dicatat bahwa di sebagian besar sistem tidak semua transaksi memiliki prioritas yang sama. Pengguna dapat membayar lebih untuk mendapatkan prioritas penyertaan yang lebih tinggi, jadi selain semua hal di atas, latensi bergantung pada biaya transaksi yang dibayarkan. Pendeknya:

Latensi itu rumit. Semakin banyak data yang dilaporkan, semakin baik. Idealnya, profil delay yang lengkap harus diukur pada kondisi kemacetan yang berbeda. Memecah latensi menjadi komponen yang berbeda (lokal, jaringan, batch, latensi konsensus) juga membantu.

Tantangan Mengukur Throughput

Throughput juga tampak sederhana pada pandangan pertama: berapa banyak transaksi per detik yang dapat ditangani sistem? 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" (tps) adalah ukuran de facto kinerja blockchain, transaksi sebagai satuan ukuran bermasalah. Untuk sistem yang menawarkan programabilitas umum ("kontrak pintar") atau bahkan fungsionalitas terbatas seperti opsi verifikasi multi-transaksi atau multi-tanda tangan Bitcoin, pertanyaan mendasarnya adalah:

Tidak semua kesepakatan diciptakan sama.

Ini jelas benar di Ethereum, di mana transaksi dapat menyertakan kode arbitrer dan mengubah status secara arbitrer. Konsep gas di Ethereum digunakan untuk mengukur (dan membebankan biaya) total pekerjaan transaksi, tetapi ini sangat relevan dengan lingkungan eksekusi EVM. Tidak ada cara mudah untuk membandingkan jumlah total pekerjaan yang dilakukan oleh satu set transaksi EVM dengan satu set transaksi Solana menggunakan lingkungan BPF. Membandingkan semua ini dengan satu set transaksi bitcoin sama mengkhawatirkannya.

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

Lapisan eksekusi yang lebih sederhana, seperti server rollup yang hanya mendukung transaksi pembayaran, menghindari kesulitan perhitungan kuantitatif. Namun, dalam hal ini pun, jumlah input dan output yang dibayarkan akan berbeda. Jumlah "hop" yang diperlukan untuk transaksi saluran pembayaran dapat bervariasi, yang memengaruhi throughput. Throughput server rollup mungkin bergantung pada seberapa jauh kumpulan transaksi dapat "dipecah" menjadi kumpulan perubahan gabungan yang lebih kecil.

Tantangan lain terkait throughput adalah melampaui pengukuran kinerja saat ini secara empiris untuk menilai kapasitas teoretis. Ini memperkenalkan berbagai masalah pemodelan untuk menilai potensi kapasitas. Pertama, kita harus menentukan beban kerja transaksional aktual pada lapisan eksekusi. Kedua, sistem nyata hampir tidak pernah mencapai kapasitas teoretis, terutama sistem blockchain. Untuk alasan ketangguhan, kami ingin implementasi node menjadi heterogen dan beragam dalam praktiknya (berlawanan dengan semua klien yang menjalankan implementasi perangkat lunak tunggal). Ini membuat simulasi akurat dari throughput blockchain menjadi lebih sulit.

Keseluruhan:

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

Pengorbanan latensi-throughput

Latensi dan throughput seringkali merupakan tradeoff. Seperti dicatat oleh Lefteris Kokoris-Kogias, trade-off ini seringkali tidak mulus, dengan latensi yang meningkat secara dramatis saat beban sistem mendekati throughput maksimumnya.

Sistem rollup tanpa pengetahuan memberikan contoh alami dari pertukaran throughput/latensi. Sejumlah besar transaksi meningkatkan waktu pembuktian dan dengan demikian latensi. Namun, dalam hal ukuran bukti dan biaya verifikasi, jejak on-chain akan diamortisasi pada lebih banyak transaksi dengan batch yang lebih besar, sehingga meningkatkan throughput.

biaya transaksi

Dapat dipahami bahwa pengguna akhir lebih mementingkan pertukaran antara latensi dan biaya daripada latensi dan throughput. Pengguna tidak memiliki alasan langsung untuk peduli dengan throughput sama sekali, hanya saja mereka dapat mengonfirmasi transaksi dengan cepat dengan biaya serendah mungkin (beberapa pengguna lebih peduli dengan biaya, yang lain lebih peduli dengan latensi). Secara keseluruhan, biaya dipengaruhi oleh sejumlah faktor:

• Berapa banyak permintaan pasar yang ada untuk berdagang?
• Berapa total throughput yang dicapai oleh sistem?
• Berapa total pendapatan yang diberikan sistem kepada validator atau penambang?
• Berapa banyak dari pendapatan ini didasarkan pada biaya transaksi versus imbalan inflasi?

Dua faktor pertama kira-kira adalah kurva penawaran dan permintaan yang mengarah ke harga kliring pasar (walaupun ada klaim bahwa penambang bertindak sebagai kartel untuk mendorong biaya di atas titik ini). Semuanya sama, lebih banyak throughput akan menghasilkan biaya yang lebih rendah, tetapi ada lebih banyak lagi.

Terutama poin ke-3 dan ke-4 di atas adalah masalah dasar dari desain sistem blockchain, tetapi kami kekurangan prinsip yang baik untuk mereka. Kami memiliki beberapa pemahaman tentang pro dan kontra memberikan pendapatan kepada penambang dari imbalan inflasi vs. biaya transaksi. Namun, meskipun banyak analisis ekonomi dari protokol konsensus blockchain, kami masih belum memiliki model yang diterima secara luas untuk menentukan berapa banyak pendapatan yang perlu mengalir ke validator. Sebagian besar sistem saat ini dibangun berdasarkan tebakan terpelajar tentang berapa banyak pendapatan yang cukup bagi validator untuk bertindak jujur tanpa menghalangi penggunaan sistem yang sebenarnya. Dalam model yang disederhanakan, dapat ditunjukkan bahwa biaya peluncuran serangan 51% sebanding dengan imbalan kepada 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? Bisa jadi mereka lebih efisien dan mendapatkan keamanan yang sama dengan uang lebih sedikit. Mungkin orang lain menghabiskan lebih dari yang diperlukan untuk menjaga keamanan wahana tanpa manfaat. Tapi bisa juga taman pertama itu berbahaya. Sistem blockchain serupa. Setelah throughput diperhitungkan, blockchain dengan biaya lebih rendah memiliki biaya lebih rendah karena memberi penghargaan (dan dengan demikian memberi insentif) lebih sedikit validator. Kami tidak memiliki alat yang baik hari ini untuk menilai apakah ini mungkin, atau apakah akan membuat sistem rentan. Keseluruhan:

Membandingkan biaya antara sistem yang berbeda 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 keseluruhan sistem.

Kesimpulannya

Menilai kinerja secara adil dan akurat itu sulit. Hal yang sama berlaku untuk mengukur performa mobil. Sama seperti blockchain, orang yang berbeda akan peduli pada hal yang berbeda. Dengan mobil, beberapa pengguna akan peduli dengan kecepatan atau akselerasi tertinggi, yang lain akan peduli dengan konsumsi bahan bakar, dan yang lain lagi akan peduli dengan kapasitas derek. Semua ini tidak mudah untuk dievaluasi. Di Amerika Serikat, misalnya, Badan Perlindungan Lingkungan memberikan pedoman rinci tentang bagaimana gas mileage dinilai dan bagaimana harus disajikan kepada pengguna di dealer.

Ruang blockchain masih jauh dari tingkat standardisasi ini. Di beberapa area, di masa mendatang kami dapat mengukur throughput sistem melalui beban kerja yang dinormalisasi atau grafik yang dinormalisasi untuk menyajikan distribusi latensi. Untuk saat ini, tindakan terbaik untuk evaluator dan pembangun adalah mengumpulkan dan mempublikasikan data sebanyak mungkin, dan menjelaskan metodologi evaluasi secara rinci sehingga dapat direplikasi dan dibandingkan dengan sistem lain.