Perimbangan Skalabilitas Blockchain: Pilihan Polkadot dan Web3
Dalam blockchain yang terus mengejar peningkatan efisiensi hari ini, satu masalah kunci secara bertahap muncul: bagaimana cara meningkatkan kinerja sambil menghindari pengorbanan keamanan dan elastisitas sistem?
Ini bukan hanya tantangan di tingkat teknologi, tetapi juga pilihan mendalam dalam desain arsitektur. Untuk ekosistem Web3, hanya mengejar sistem yang lebih cepat tanpa memperhatikan kepercayaan dan keamanan, sulit untuk mendukung inovasi yang benar-benar berkelanjutan.
Sebagai pendorong penting untuk skalabilitas Web3, apakah Polkadot juga melakukan beberapa kompromi dalam mengejar throughput tinggi dan latensi rendah? Apakah model rollup-nya berkompromi pada desentralisasi, keamanan, atau interoperabilitas jaringan?
Artikel ini akan membahas masalah ini, menganalisis secara mendalam kompromi desain skalabilitas Polkadot, dan membandingkannya dengan solusi dari blockchain utama lainnya, serta mengeksplorasi pilihan berbeda mereka dalam hal kinerja, keamanan, dan desentralisasi.
Tantangan Desain Ekspansi Polkadot
Keseimbangan antara elastisitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan relai rantai, apakah ini mungkin memperkenalkan risiko sentralisasi dalam beberapa aspek? Apakah mungkin terjadi titik kegagalan tunggal atau kontrol yang dapat mempengaruhi karakteristik desentralisasinya?
Operasi Rollup bergantung pada penyortir dari rantai penghubung, yang berkomunikasi menggunakan mekanisme protokol kolator. Protokol ini sepenuhnya tanpa izin dan tanpa kepercayaan, siapapun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node rantai penghubung, dan mengajukan permintaan perubahan status rollup. Permintaan ini akan diverifikasi oleh salah satu core rantai penghubung, hanya perlu memenuhi satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tersebut tidak akan maju.
trade-off untuk ekspansi vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "skala elastis". Selama proses desain, ditemukan bahwa karena verifikasi blok rollup tidak tetap dijalankan pada satu core tertentu, ini dapat mempengaruhi elastisitasnya.
Karena protokol untuk mengirim blok ke rantai perantara tidak memerlukan izin atau kepercayaan, siapa pun dapat mengirim blok untuk diverifikasi di salah satu core yang dialokasikan untuk rollup. Penyerang mungkin memanfaatkan ini untuk mengirim ulang blok yang sah yang telah diverifikasi sebelumnya ke core yang berbeda, secara jahat menghabiskan sumber daya, sehingga mengurangi throughput dan efisiensi keseluruhan rollup.
Tujuan Polkadot adalah untuk mempertahankan elastisitas rollup dan penggunaan sumber daya rantai relai tanpa mempengaruhi karakteristik kunci sistem.
Apakah Sequencer dapat dipercaya?
Salah satu solusi sederhana adalah mengatur protokol menjadi "berlisensi": misalnya dengan menggunakan mekanisme daftar putih, atau dengan secara default mempercayai penyortir yang tidak melakukan tindakan jahat, sehingga menjamin aktivitas rollup.
Namun, dalam filosofi desain Polkadot, kita tidak dapat membuat asumsi kepercayaan terhadap sequencer, karena harus mempertahankan karakteristik "tanpa kepercayaan" dan "tanpa izin" dari sistem. Siapa pun harus dapat menggunakan protokol collator untuk mengajukan permintaan perubahan status rollup.
Polkadot: Solusi yang Tidak Berkompromi
Solusi akhir yang dipilih oleh Polkadot adalah: menyerahkan masalah sepenuhnya kepada fungsi transisi status rollup (Runtime). Runtime adalah satu-satunya sumber informasi konsensus yang dapat dipercaya, oleh karena itu harus dinyatakan dengan jelas dalam output di mana verifikasi harus dilakukan pada core Polkadot mana.
Desain ini mencapai perlindungan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang status rollup dalam proses ketersediaan, dan memastikan kebenaran distribusi core melalui protokol ekonomi terenkripsi ELVES.
Sebelum data dari rollup blok ditulis ke lapisan ketersediaan data Polkadot, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima resi kandidat dan bukti validitas yang diserahkan oleh penyortir, yang mencakup blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi paralel chain, yang akan dieksekusi ulang oleh validator di relay chain.
Hasil verifikasi mencakup satu pemilih inti (core selector) yang digunakan untuk menentukan pada inti mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut apakah sesuai dengan inti yang menjadi tanggung jawabnya; jika tidak sesuai, blok tersebut akan dibuang.
Mekanisme ini memastikan sistem selalu mempertahankan sifat tanpa kepercayaan dan tanpa izin, menghindari manipulasi posisi verifikasi oleh pelaku jahat seperti sorter, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, ia tetap dapat mempertahankan elastisitas.
Keamanan
Dalam pencarian skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai penghubung, hanya perlu satu sorter jujur untuk menjaga kelangsungan hidup.
Dengan bantuan protokol ELVES, Polkadot akan memperluas keamanan secara menyeluruh ke semua rollup, memvalidasi semua perhitungan di core tanpa perlu membatasi atau mengasumsikan jumlah core yang digunakan.
Oleh karena itu, rollup Polkadot dapat mencapai skalabilitas yang sebenarnya tanpa mengorbankan keamanan.
Universality
Ekspansi elastis tidak akan membatasi programabilitas rollup. Model rollup Polkadot mendukung eksekusi komputasi Turing lengkap dalam lingkungan WebAssembly, asalkan eksekusi tunggal selesai dalam waktu 2 detik. Dengan bantuan ekspansi elastis, jumlah total komputasi yang dapat dieksekusi dalam siklus 6 detik meningkat, tetapi jenis komputasi tidak terpengaruh.
kompleksitas
Throughput yang lebih tinggi dan latensi yang lebih rendah tidak dapat dihindari untuk memperkenalkan kompleksitas, yang merupakan satu-satunya cara kompromi yang dapat diterima dalam desain sistem.
Rollup dapat menyesuaikan sumber daya secara dinamis melalui antarmuka Agile Coretime untuk mempertahankan tingkat keamanan yang konsisten. Mereka juga perlu memenuhi sebagian persyaratan RFC103 untuk beradaptasi dengan berbagai skenario penggunaan.
Kompleksitas spesifik tergantung pada strategi manajemen sumber daya rollup, yang mungkin bergantung pada variabel on-chain atau off-chain. Contohnya:
Strategi sederhana: selalu gunakan jumlah tetap core, atau sesuaikan secara manual di luar rantai;
Strategi ringan: Memantau beban transaksi tertentu di mempool node;
Strategi otomatis: Mengonfigurasi sumber daya dengan memanggil layanan coretime sebelumnya melalui data historis dan antarmuka XCM.
Meskipun cara otomatisasi lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.
Interoperabilitas
Polkadot mendukung interoperabilitas antar rollup yang berbeda, sementara skalabilitas elastis tidak akan mempengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diimplementasikan oleh lapisan transportasi dasar, ruang blok komunikasi setiap rollup adalah tetap, tidak tergantung pada jumlah inti yang dialokasikan.
Di masa depan, Polkadot juga akan mendukung pengiriman pesan di luar rantai, dengan rantai relai sebagai kontrol, bukan sebagai data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup bersamaan dengan perluasan elastis, lebih lanjut meningkatkan kemampuan ekspansi vertikal sistem.
Pertimbangan Protokol Lain
Seperti yang kita ketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, dari sudut pandang koefisien Nakamoto, meskipun beberapa pesaing Polkadot memiliki tingkat desentralisasi yang lebih rendah, kinerja mereka juga tidak memuaskan.
Solana
Solana tidak menggunakan arsitektur sharding Polkadot atau Ethereum, tetapi menerapkan skalabilitas dengan arsitektur throughput tinggi lapisan tunggal, bergantung pada bukti sejarah (PoH), pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoretis mencapai 65.000.
Salah satu desain kunci adalah mekanisme penjadwalan pemimpin yang diumumkan sebelumnya dan dapat diverifikasi:
Pada awal setiap epoch (sekitar dua hari atau 432.000 slot), slot dialokasikan berdasarkan jumlah staking;
Semakin banyak yang di-stake, semakin banyak distribusinya. Misalnya, validator yang melakukan staking 1% akan mendapatkan sekitar 1% peluang untuk memproduksi blok;
Semua penambang blok diumumkan sebelumnya, meningkatkan risiko jaringan mengalami serangan DDoS terarah dan sering mengalami downtime.
PoH dan pemrosesan paralel memiliki persyaratan perangkat keras yang sangat tinggi, menyebabkan sentralisasi node validasi. Semakin banyak node yang dipertaruhkan, semakin besar peluang mereka untuk memproduksi blok, sedangkan node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan juga meningkatkan risiko sistem menjadi lumpuh setelah diserang.
Solana mengorbankan desentralisasi dan ketahanan terhadap serangan untuk mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh lebih rendah dibandingkan Polkadot yang mencapai 172.
TON
TON mengklaim TPS dapat mencapai 104,715, tetapi angka ini dicapai di jaringan pengujian privat, dengan 256 node, serta dalam kondisi jaringan dan perangkat keras yang ideal. Sementara itu, Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.
Mekanisme konsensus TON memiliki risiko keamanan: identitas node verifikasi sharding dapat terungkap sebelumnya. Buku putih TON juga menyatakan dengan jelas bahwa meskipun ini dapat mengoptimalkan bandwidth, tetapi juga dapat disalahgunakan. Karena kurangnya mekanisme "pembangkang penjudi", penyerang dapat menunggu agar suatu sharding sepenuhnya berada di bawah kontrolnya, atau melalui serangan DDoS memblokir validator yang jujur, sehingga dapat memanipulasi status.
Sebagai perbandingan, validator Polkadot ditugaskan secara acak dan diungkapkan dengan penundaan, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Penyerang harus mempertaruhkan semua kontrol untuk berhasil, dan selama ada satu validator jujur yang memicu sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang.
Avalanche
Avalanche menggunakan arsitektur jaringan utama + subnet untuk skalabilitas, jaringan utama terdiri dari X-Chain (transfer, ~4.500 TPS), C-Chain (kontrak pintar, ~100-200 TPS), P-Chain (mengelola validator dan subnet).
Setiap subnet secara teoritis dapat mencapai TPS ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban shard tunggal untuk mencapai skalabilitas. Namun, Avalanche memungkinkan validator untuk bebas memilih subnet yang akan diikuti, dan subnet dapat menetapkan persyaratan tambahan seperti geografi, KYC, dan lain-lain, mengorbankan desentralisasi dan keamanan.
Di Polkadot, semua rollup berbagi jaminan keamanan yang seragam; sementara subnet Avalanche tidak memiliki jaminan keamanan secara default, beberapa bahkan bisa sepenuhnya terpusat. Jika ingin meningkatkan keamanan, masih perlu mengorbankan kinerja, dan sulit untuk memberikan komitmen keamanan yang pasti.
Ethereum
Strategi perluasan Ethereum bertaruh pada skalabilitas lapisan rollup, bukan secara langsung menyelesaikan masalah di lapisan dasar. Cara ini pada dasarnya tidak menyelesaikan masalah, melainkan hanya memindahkan masalah ke lapisan di atas tumpukan.
Optimistic Rollup
Saat ini, sebagian besar Optimistic rollup bersifat terpusat (beberapa bahkan hanya memiliki satu sequencer), yang mengakibatkan masalah seperti kurangnya keamanan, isolasi satu sama lain, dan latensi tinggi (perlu menunggu periode bukti penipuan, biasanya beberapa hari).
ZK Rollup
Implementasi ZK rollup terpengaruh oleh batasan jumlah data yang dapat diproses dalam satu transaksi. Permintaan komputasi untuk menghasilkan bukti nol pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semua" mudah menyebabkan sentralisasi sistem. Untuk memastikan TPS, ZK rollup sering membatasi jumlah transaksi per batch, yang dapat menyebabkan kemacetan jaringan dan kenaikan gas pada saat permintaan tinggi, mempengaruhi pengalaman pengguna.
Sebagai perbandingan, biaya ZK rollup yang Turing lengkap adalah sekitar 2x10^6 kali dari protokol keamanan ekonomi kripto inti Polkadot.
Selain itu, masalah ketersediaan data ZK rollup juga akan memperburuk kelemahannya. Untuk memastikan bahwa siapa pun dapat memverifikasi transaksi, data transaksi lengkap tetap perlu disediakan. Ini biasanya bergantung pada solusi ketersediaan data tambahan, yang lebih lanjut meningkatkan biaya dan biaya pengguna.
Kesimpulan
Akhir dari skalabilitas seharusnya bukan kompromi.
Dibandingkan dengan blockchain publik lainnya, Polkadot tidak mengambil jalan untuk mengorbankan desentralisasi demi kinerja atau mengorbankan efisiensi demi kepercayaan yang telah ditetapkan, tetapi mencapai keseimbangan multidimensional antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang fleksibel, tanpa izin, lapisan keamanan yang terintegrasi, dan mekanisme manajemen sumber daya yang fleksibel.
Dalam mengejar penerapan skala yang lebih besar saat ini, "ekstensibilitas tanpa kepercayaan" yang dipegang oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung perkembangan jangka panjang Web3.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
16 Suka
Hadiah
16
6
Posting ulang
Bagikan
Komentar
0/400
Fren_Not_Food
· 07-23 13:22
Proyek ini terdengar cukup baik, mari kita lihat kinerjanya.
Lihat AsliBalas0
BlockchainDecoder
· 07-23 11:10
Mengacu pada data terbaru dari kelompok penelitian Cho, tps rantai tunggal umumnya di bawah 3k, masalah trade-off perlu segera dipecahkan.
Lihat AsliBalas0
GasGuzzler
· 07-21 02:15
Ekspansi linier murni tidak akan menang
Lihat AsliBalas0
DataOnlooker
· 07-21 02:15
Lihat lagi~ DOT belum terbang
Lihat AsliBalas0
LidoStakeAddict
· 07-21 02:04
Kata-kata yang bagus, hilang begitu saja hanya dengan satu kalimat.
Lihat AsliBalas0
LiquidatedTwice
· 07-21 02:04
dot adalah masa depan, tidak berlebihan dan tidak meremehkan.
Polkadot tanpa kompromi dalam skala: Pilihan baru untuk ekosistem Web3
Perimbangan Skalabilitas Blockchain: Pilihan Polkadot dan Web3
Dalam blockchain yang terus mengejar peningkatan efisiensi hari ini, satu masalah kunci secara bertahap muncul: bagaimana cara meningkatkan kinerja sambil menghindari pengorbanan keamanan dan elastisitas sistem?
Ini bukan hanya tantangan di tingkat teknologi, tetapi juga pilihan mendalam dalam desain arsitektur. Untuk ekosistem Web3, hanya mengejar sistem yang lebih cepat tanpa memperhatikan kepercayaan dan keamanan, sulit untuk mendukung inovasi yang benar-benar berkelanjutan.
Sebagai pendorong penting untuk skalabilitas Web3, apakah Polkadot juga melakukan beberapa kompromi dalam mengejar throughput tinggi dan latensi rendah? Apakah model rollup-nya berkompromi pada desentralisasi, keamanan, atau interoperabilitas jaringan?
Artikel ini akan membahas masalah ini, menganalisis secara mendalam kompromi desain skalabilitas Polkadot, dan membandingkannya dengan solusi dari blockchain utama lainnya, serta mengeksplorasi pilihan berbeda mereka dalam hal kinerja, keamanan, dan desentralisasi.
Tantangan Desain Ekspansi Polkadot
Keseimbangan antara elastisitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan relai rantai, apakah ini mungkin memperkenalkan risiko sentralisasi dalam beberapa aspek? Apakah mungkin terjadi titik kegagalan tunggal atau kontrol yang dapat mempengaruhi karakteristik desentralisasinya?
Operasi Rollup bergantung pada penyortir dari rantai penghubung, yang berkomunikasi menggunakan mekanisme protokol kolator. Protokol ini sepenuhnya tanpa izin dan tanpa kepercayaan, siapapun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node rantai penghubung, dan mengajukan permintaan perubahan status rollup. Permintaan ini akan diverifikasi oleh salah satu core rantai penghubung, hanya perlu memenuhi satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tersebut tidak akan maju.
trade-off untuk ekspansi vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "skala elastis". Selama proses desain, ditemukan bahwa karena verifikasi blok rollup tidak tetap dijalankan pada satu core tertentu, ini dapat mempengaruhi elastisitasnya.
Karena protokol untuk mengirim blok ke rantai perantara tidak memerlukan izin atau kepercayaan, siapa pun dapat mengirim blok untuk diverifikasi di salah satu core yang dialokasikan untuk rollup. Penyerang mungkin memanfaatkan ini untuk mengirim ulang blok yang sah yang telah diverifikasi sebelumnya ke core yang berbeda, secara jahat menghabiskan sumber daya, sehingga mengurangi throughput dan efisiensi keseluruhan rollup.
Tujuan Polkadot adalah untuk mempertahankan elastisitas rollup dan penggunaan sumber daya rantai relai tanpa mempengaruhi karakteristik kunci sistem.
Apakah Sequencer dapat dipercaya?
Salah satu solusi sederhana adalah mengatur protokol menjadi "berlisensi": misalnya dengan menggunakan mekanisme daftar putih, atau dengan secara default mempercayai penyortir yang tidak melakukan tindakan jahat, sehingga menjamin aktivitas rollup.
Namun, dalam filosofi desain Polkadot, kita tidak dapat membuat asumsi kepercayaan terhadap sequencer, karena harus mempertahankan karakteristik "tanpa kepercayaan" dan "tanpa izin" dari sistem. Siapa pun harus dapat menggunakan protokol collator untuk mengajukan permintaan perubahan status rollup.
Polkadot: Solusi yang Tidak Berkompromi
Solusi akhir yang dipilih oleh Polkadot adalah: menyerahkan masalah sepenuhnya kepada fungsi transisi status rollup (Runtime). Runtime adalah satu-satunya sumber informasi konsensus yang dapat dipercaya, oleh karena itu harus dinyatakan dengan jelas dalam output di mana verifikasi harus dilakukan pada core Polkadot mana.
Desain ini mencapai perlindungan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang status rollup dalam proses ketersediaan, dan memastikan kebenaran distribusi core melalui protokol ekonomi terenkripsi ELVES.
Sebelum data dari rollup blok ditulis ke lapisan ketersediaan data Polkadot, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima resi kandidat dan bukti validitas yang diserahkan oleh penyortir, yang mencakup blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi paralel chain, yang akan dieksekusi ulang oleh validator di relay chain.
Hasil verifikasi mencakup satu pemilih inti (core selector) yang digunakan untuk menentukan pada inti mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut apakah sesuai dengan inti yang menjadi tanggung jawabnya; jika tidak sesuai, blok tersebut akan dibuang.
Mekanisme ini memastikan sistem selalu mempertahankan sifat tanpa kepercayaan dan tanpa izin, menghindari manipulasi posisi verifikasi oleh pelaku jahat seperti sorter, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, ia tetap dapat mempertahankan elastisitas.
Keamanan
Dalam pencarian skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai penghubung, hanya perlu satu sorter jujur untuk menjaga kelangsungan hidup.
Dengan bantuan protokol ELVES, Polkadot akan memperluas keamanan secara menyeluruh ke semua rollup, memvalidasi semua perhitungan di core tanpa perlu membatasi atau mengasumsikan jumlah core yang digunakan.
Oleh karena itu, rollup Polkadot dapat mencapai skalabilitas yang sebenarnya tanpa mengorbankan keamanan.
Universality
Ekspansi elastis tidak akan membatasi programabilitas rollup. Model rollup Polkadot mendukung eksekusi komputasi Turing lengkap dalam lingkungan WebAssembly, asalkan eksekusi tunggal selesai dalam waktu 2 detik. Dengan bantuan ekspansi elastis, jumlah total komputasi yang dapat dieksekusi dalam siklus 6 detik meningkat, tetapi jenis komputasi tidak terpengaruh.
kompleksitas
Throughput yang lebih tinggi dan latensi yang lebih rendah tidak dapat dihindari untuk memperkenalkan kompleksitas, yang merupakan satu-satunya cara kompromi yang dapat diterima dalam desain sistem.
Rollup dapat menyesuaikan sumber daya secara dinamis melalui antarmuka Agile Coretime untuk mempertahankan tingkat keamanan yang konsisten. Mereka juga perlu memenuhi sebagian persyaratan RFC103 untuk beradaptasi dengan berbagai skenario penggunaan.
Kompleksitas spesifik tergantung pada strategi manajemen sumber daya rollup, yang mungkin bergantung pada variabel on-chain atau off-chain. Contohnya:
Meskipun cara otomatisasi lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.
Interoperabilitas
Polkadot mendukung interoperabilitas antar rollup yang berbeda, sementara skalabilitas elastis tidak akan mempengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diimplementasikan oleh lapisan transportasi dasar, ruang blok komunikasi setiap rollup adalah tetap, tidak tergantung pada jumlah inti yang dialokasikan.
Di masa depan, Polkadot juga akan mendukung pengiriman pesan di luar rantai, dengan rantai relai sebagai kontrol, bukan sebagai data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup bersamaan dengan perluasan elastis, lebih lanjut meningkatkan kemampuan ekspansi vertikal sistem.
Pertimbangan Protokol Lain
Seperti yang kita ketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, dari sudut pandang koefisien Nakamoto, meskipun beberapa pesaing Polkadot memiliki tingkat desentralisasi yang lebih rendah, kinerja mereka juga tidak memuaskan.
Solana
Solana tidak menggunakan arsitektur sharding Polkadot atau Ethereum, tetapi menerapkan skalabilitas dengan arsitektur throughput tinggi lapisan tunggal, bergantung pada bukti sejarah (PoH), pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoretis mencapai 65.000.
Salah satu desain kunci adalah mekanisme penjadwalan pemimpin yang diumumkan sebelumnya dan dapat diverifikasi:
PoH dan pemrosesan paralel memiliki persyaratan perangkat keras yang sangat tinggi, menyebabkan sentralisasi node validasi. Semakin banyak node yang dipertaruhkan, semakin besar peluang mereka untuk memproduksi blok, sedangkan node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan juga meningkatkan risiko sistem menjadi lumpuh setelah diserang.
Solana mengorbankan desentralisasi dan ketahanan terhadap serangan untuk mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh lebih rendah dibandingkan Polkadot yang mencapai 172.
TON
TON mengklaim TPS dapat mencapai 104,715, tetapi angka ini dicapai di jaringan pengujian privat, dengan 256 node, serta dalam kondisi jaringan dan perangkat keras yang ideal. Sementara itu, Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.
Mekanisme konsensus TON memiliki risiko keamanan: identitas node verifikasi sharding dapat terungkap sebelumnya. Buku putih TON juga menyatakan dengan jelas bahwa meskipun ini dapat mengoptimalkan bandwidth, tetapi juga dapat disalahgunakan. Karena kurangnya mekanisme "pembangkang penjudi", penyerang dapat menunggu agar suatu sharding sepenuhnya berada di bawah kontrolnya, atau melalui serangan DDoS memblokir validator yang jujur, sehingga dapat memanipulasi status.
Sebagai perbandingan, validator Polkadot ditugaskan secara acak dan diungkapkan dengan penundaan, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Penyerang harus mempertaruhkan semua kontrol untuk berhasil, dan selama ada satu validator jujur yang memicu sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang.
Avalanche
Avalanche menggunakan arsitektur jaringan utama + subnet untuk skalabilitas, jaringan utama terdiri dari X-Chain (transfer, ~4.500 TPS), C-Chain (kontrak pintar, ~100-200 TPS), P-Chain (mengelola validator dan subnet).
Setiap subnet secara teoritis dapat mencapai TPS ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban shard tunggal untuk mencapai skalabilitas. Namun, Avalanche memungkinkan validator untuk bebas memilih subnet yang akan diikuti, dan subnet dapat menetapkan persyaratan tambahan seperti geografi, KYC, dan lain-lain, mengorbankan desentralisasi dan keamanan.
Di Polkadot, semua rollup berbagi jaminan keamanan yang seragam; sementara subnet Avalanche tidak memiliki jaminan keamanan secara default, beberapa bahkan bisa sepenuhnya terpusat. Jika ingin meningkatkan keamanan, masih perlu mengorbankan kinerja, dan sulit untuk memberikan komitmen keamanan yang pasti.
Ethereum
Strategi perluasan Ethereum bertaruh pada skalabilitas lapisan rollup, bukan secara langsung menyelesaikan masalah di lapisan dasar. Cara ini pada dasarnya tidak menyelesaikan masalah, melainkan hanya memindahkan masalah ke lapisan di atas tumpukan.
Optimistic Rollup
Saat ini, sebagian besar Optimistic rollup bersifat terpusat (beberapa bahkan hanya memiliki satu sequencer), yang mengakibatkan masalah seperti kurangnya keamanan, isolasi satu sama lain, dan latensi tinggi (perlu menunggu periode bukti penipuan, biasanya beberapa hari).
ZK Rollup
Implementasi ZK rollup terpengaruh oleh batasan jumlah data yang dapat diproses dalam satu transaksi. Permintaan komputasi untuk menghasilkan bukti nol pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semua" mudah menyebabkan sentralisasi sistem. Untuk memastikan TPS, ZK rollup sering membatasi jumlah transaksi per batch, yang dapat menyebabkan kemacetan jaringan dan kenaikan gas pada saat permintaan tinggi, mempengaruhi pengalaman pengguna.
Sebagai perbandingan, biaya ZK rollup yang Turing lengkap adalah sekitar 2x10^6 kali dari protokol keamanan ekonomi kripto inti Polkadot.
Selain itu, masalah ketersediaan data ZK rollup juga akan memperburuk kelemahannya. Untuk memastikan bahwa siapa pun dapat memverifikasi transaksi, data transaksi lengkap tetap perlu disediakan. Ini biasanya bergantung pada solusi ketersediaan data tambahan, yang lebih lanjut meningkatkan biaya dan biaya pengguna.
Kesimpulan
Akhir dari skalabilitas seharusnya bukan kompromi.
Dibandingkan dengan blockchain publik lainnya, Polkadot tidak mengambil jalan untuk mengorbankan desentralisasi demi kinerja atau mengorbankan efisiensi demi kepercayaan yang telah ditetapkan, tetapi mencapai keseimbangan multidimensional antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang fleksibel, tanpa izin, lapisan keamanan yang terintegrasi, dan mekanisme manajemen sumber daya yang fleksibel.
Dalam mengejar penerapan skala yang lebih besar saat ini, "ekstensibilitas tanpa kepercayaan" yang dipegang oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung perkembangan jangka panjang Web3.