Perimbangan Scalabilitas Blockchain: Pilihan Polkadot dan Web3
Dalam era teknologi Blockchain yang terus mengejar efisiensi yang lebih tinggi, satu masalah kunci mulai muncul: bagaimana meningkatkan kinerja sambil menjaga keamanan dan ketahanan sistem? Ini bukan hanya tantangan di tingkat teknologi, tetapi juga pilihan mendalam dalam desain arsitektur. Bagi ekosistem Web3, sebuah sistem yang hanya lebih cepat jika dibangun di atas pengorbanan kepercayaan dan keamanan, seringkali sulit untuk mendukung inovasi yang benar-benar berkelanjutan.
Sebagai pendorong penting untuk skalabilitas Web3, apakah Polkadot juga telah membuat beberapa kompromi dalam mengejar throughput tinggi dan latensi rendah? Apakah model rollup-nya membuat konsesi dalam hal desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan membahas pertanyaan-pertanyaan ini, menganalisis secara mendalam kompromi dan trade-off dalam desain skalabilitas Polkadot, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, untuk mengeksplorasi pilihan jalur yang berbeda dalam hal kinerja, keamanan, dan desentralisasi.
Tantangan Desain Ekspansi Polkadot
Keseimbangan antara elastisitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan rantai penghubung terpusat, 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 yang menghubungkan rantai perantara, dan komunikasinya menggunakan mekanisme yang disebut protokol collator. Protokol ini sama sekali tidak memerlukan izin dan tidak memerlukan kepercayaan, siapa pun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node rantai perantara, dan mengajukan permintaan perubahan status rollup. Permintaan ini akan diverifikasi oleh salah satu core rantai perantara, dengan satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tersebut tidak akan diperbarui.
kompromi ekspansi vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan melalui fitur "skala elastis". Selama proses desain ditemukan bahwa, karena verifikasi blok rollup tidak tetap dilakukan di satu core tertentu, ini dapat mempengaruhi elastisitasnya.
Karena protokol untuk mengirim blok ke rantai penghubung adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirim blok untuk diverifikasi di salah satu core yang dialokasikan untuk rollup. Penyerang mungkin memanfaatkan ini dengan mengirimkan kembali 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 pemanfaatan sumber daya rantai penghubung 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 secara default mempercayai penyortir tidak akan berperilaku jahat, sehingga menjamin keberlangsungan rollup.
Namun, dalam konsep desain Polkadot, kita tidak dapat membuat asumsi kepercayaan terhadap sequencer, karena harus mempertahankan karakteristik "tanpa kepercayaan" dan "tanpa izin" dari sistem. Siapa pun seharusnya dapat menggunakan protokol collator untuk mengajukan permintaan perubahan status rollup.
Polkadot: Solusi tanpa kompromi
Solusi yang akhirnya dipilih oleh Polkadot adalah: menyerahkan masalah sepenuhnya kepada fungsi konversi status rollup (Runtime). Runtime adalah satu-satunya sumber informasi konsensus yang dapat dipercaya, oleh karena itu harus dinyatakan dengan jelas di output di mana verifikasi harus dilakukan pada inti Polkadot mana.
Desain ini mewujudkan perlindungan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang perubahan status rollup dalam proses ketersediaan dan memastikan kebenaran alokasi inti melalui protokol ekonomi terenkripsi ELVES.
Sebelum menulis data dari rollup blok ke lapisan ketersediaan data Polkadot, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat dan bukti keabsahan yang diserahkan oleh penyortir, yang berisi blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi parachain dan dieksekusi ulang oleh validator di relay chain.
Hasil verifikasi mencakup sebuah core selector, yang digunakan untuk menentukan pada core mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut dengan core yang menjadi tanggung jawabnya; jika tidak konsisten, blok tersebut akan dibuang.
Mekanisme ini memastikan bahwa sistem selalu mempertahankan sifat tanpa kepercayaan dan tanpa izin, menghindari manipulasi posisi verifikasi oleh aktor jahat seperti sorter, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, itu tetap dapat bertahan.
Keamanan
Dalam proses mengejar skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai relai, hanya memerlukan satu pengurut jujur untuk menjaga kelangsungan hidup.
Dengan bantuan protokol ELVES, Polkadot sepenuhnya memperluas keamanannya ke semua rollup, memverifikasi semua perhitungan di core tanpa perlu membatasi atau membuat asumsi tentang jumlah core yang digunakan.
Oleh karena itu, rollup Polkadot dapat mencapai skalabilitas nyata tanpa mengorbankan keamanan.
Universalitas
Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung eksekusi komputasi Turing lengkap dalam lingkungan WebAssembly, asalkan eksekusi tunggal diselesaikan dalam waktu 2 detik. Dengan bantuan ekspansi elastis, total jumlah komputasi yang dapat dieksekusi dalam periode 6 detik meningkat, tetapi jenis komputasi tidak terpengaruh.
kompleksitas
Throughput yang lebih tinggi dan latensi yang lebih rendah pasti akan memperkenalkan kompleksitas, ini adalah satu-satunya cara 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 menyesuaikan dengan berbagai skenario penggunaan.
Kompleksitas spesifik tergantung pada strategi manajemen sumber daya rollup, yang mungkin bergantung pada variabel on-chain atau off-chain. Misalnya:
Strategi sederhana: selalu gunakan jumlah core yang tetap, atau sesuaikan secara manual melalui off-chain;
Strategi ringan: Memantau beban transaksi tertentu di mempool node;
Strategi otomatis: Mengkonfigurasi sumber daya layanan coretime dengan memanggil lebih awal melalui data historis dan antarmuka XCM.
Meskipun cara otomatisasi lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.
Interoperabilitas
Polkadot mendukung interoperabilitas antara berbagai rollup, sementara skalabilitas elastis tidak akan mempengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diwujudkan oleh lapisan transportasi dasar, ruang blok komunikasi setiap rollup adalah tetap dan tidak bergantung 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 seiring dengan peningkatan elastisitas, lebih lanjut memperkuat kemampuan skalabilitas vertikal sistem.
Apa kompromi yang dibuat oleh protokol lain?
Seperti yang kita ketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, dari perspektif 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, melainkan mencapai skalabilitas dengan arsitektur throughput tinggi lapisan tunggal, mengandalkan bukti sejarah (PoH), pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoritis mencapai 65.000.
Salah satu desain kunci adalah mekanisme penjadwalan pemimpin yang dipublikasikan dan dapat diverifikasi sebelumnya:
Pada awal setiap epoch (sekitar dua hari atau 432.000 slot), slot dialokasikan berdasarkan jumlah staking;
Semakin banyak yang dipertaruhkan, semakin banyak yang akan dialokasikan. Misalnya, validator yang mempertaruhkan 1% akan mendapatkan sekitar 1% peluang untuk memproduksi blok;
Semua penghasil blok diumumkan sebelumnya, meningkatkan risiko jaringan mengalami serangan DDoS terarah dan sering mengalami downtime.
PoH dan pemrosesan paralel memiliki tuntutan perangkat keras yang sangat tinggi, yang menyebabkan sentralisasi node verifikasi. Semakin banyak node yang dipertaruhkan, semakin besar peluang mereka untuk menghasilkan blok, sedangkan node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan meningkatkan risiko sistem mengalami keruntuhan setelah diserang.
Solana mengorbankan desentralisasi dan ketahanan terhadap serangan untuk mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh di bawah Polkadot yang mencapai 172.
TON
TON mengklaim TPS dapat mencapai 104,715, tetapi angka ini dicapai di jaringan pengujian privat, dengan 256 node, 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 validasi shard akan terungkap sebelumnya. Buku putih TON juga dengan jelas menyatakan bahwa meskipun ini dapat mengoptimalkan bandwidth, ini juga dapat disalahgunakan. Karena kurangnya mekanisme "kebangkrutan penjudi", penyerang dapat menunggu shard tertentu sepenuhnya berada di bawah kontrolnya, atau menggunakan serangan DDoS untuk memblokir validator yang jujur, sehingga mengubah status.
Sebaliknya, validator Polkadot ditugaskan secara acak dan diungkapkan dengan penundaan, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Serangan harus mempertaruhkan semua kontrol untuk berhasil; selama ada satu validator yang jujur yang mengajukan sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk skala, mainnet 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 pendekatan Polkadot: mengurangi beban shard tunggal untuk mencapai skalabilitas. Namun, Avalanche memungkinkan validator untuk memilih untuk berpartisipasi dalam subnet secara bebas, 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, perlu berkompromi pada kinerja, dan sulit untuk memberikan janji keamanan yang pasti.
Ethereum
Strategi skalabilitas Ethereum adalah bertaruh pada skalabilitas lapisan rollup, bukan langsung menyelesaikan masalah di lapisan dasar. Cara ini pada dasarnya tidak menyelesaikan masalah, tetapi 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 keamanan yang tidak memadai, saling terisolasi, dan latensi tinggi (harus menunggu periode pembuktian penipuan, biasanya beberapa hari).
ZK Rollup
Implementasi ZK rollup terbatas oleh jumlah data yang dapat diproses per transaksi. Permintaan komputasi untuk menghasilkan bukti nol pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semua" mudah menyebabkan sentralisasi sistem. Untuk menjamin TPS, ZK rollup sering membatasi jumlah transaksi per batch, yang dapat menyebabkan kemacetan jaringan dan kenaikan gas saat permintaan tinggi, mempengaruhi pengalaman pengguna.
Jika dibandingkan, biaya ZK rollup yang Turing lengkap adalah sekitar 2x10^6 kali dari protokol keamanan ekonomi inti Polkadot.
Selain itu, masalah ketersediaan data pada ZK rollup juga akan memperburuk kelemahannya. Untuk memastikan siapa pun dapat memverifikasi transaksi, data transaksi lengkap masih perlu disediakan. Ini biasanya bergantung pada solusi ketersediaan data tambahan, yang semakin meningkatkan biaya dan biaya pengguna.
Kesimpulan
Akhir dari skalabilitas tidak seharusnya menjadi kompromi.
Dibandingkan dengan blockchain publik lainnya, Polkadot tidak mengambil jalan untuk mengorbankan desentralisasi demi kinerja, atau mengorbankan kepercayaan yang telah ditentukan demi efisiensi, melainkan mencapai keseimbangan multidimensi antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang elastis, tanpa izin, lapisan keamanan yang terintegrasi, dan mekanisme pengelolaan sumber daya yang fleksibel.
Dalam mengejar penerapan skala yang lebih besar saat ini, "skala 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.
Ekspansi Fleksibel Polkadot: Solusi Tanpa Kompromi di Ekosistem Web3
Perimbangan Scalabilitas Blockchain: Pilihan Polkadot dan Web3
Dalam era teknologi Blockchain yang terus mengejar efisiensi yang lebih tinggi, satu masalah kunci mulai muncul: bagaimana meningkatkan kinerja sambil menjaga keamanan dan ketahanan sistem? Ini bukan hanya tantangan di tingkat teknologi, tetapi juga pilihan mendalam dalam desain arsitektur. Bagi ekosistem Web3, sebuah sistem yang hanya lebih cepat jika dibangun di atas pengorbanan kepercayaan dan keamanan, seringkali sulit untuk mendukung inovasi yang benar-benar berkelanjutan.
Sebagai pendorong penting untuk skalabilitas Web3, apakah Polkadot juga telah membuat beberapa kompromi dalam mengejar throughput tinggi dan latensi rendah? Apakah model rollup-nya membuat konsesi dalam hal desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan membahas pertanyaan-pertanyaan ini, menganalisis secara mendalam kompromi dan trade-off dalam desain skalabilitas Polkadot, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, untuk mengeksplorasi pilihan jalur yang berbeda dalam hal kinerja, keamanan, dan desentralisasi.
Tantangan Desain Ekspansi Polkadot
Keseimbangan antara elastisitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan rantai penghubung terpusat, 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 yang menghubungkan rantai perantara, dan komunikasinya menggunakan mekanisme yang disebut protokol collator. Protokol ini sama sekali tidak memerlukan izin dan tidak memerlukan kepercayaan, siapa pun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node rantai perantara, dan mengajukan permintaan perubahan status rollup. Permintaan ini akan diverifikasi oleh salah satu core rantai perantara, dengan satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tersebut tidak akan diperbarui.
kompromi ekspansi vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan melalui fitur "skala elastis". Selama proses desain ditemukan bahwa, karena verifikasi blok rollup tidak tetap dilakukan di satu core tertentu, ini dapat mempengaruhi elastisitasnya.
Karena protokol untuk mengirim blok ke rantai penghubung adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirim blok untuk diverifikasi di salah satu core yang dialokasikan untuk rollup. Penyerang mungkin memanfaatkan ini dengan mengirimkan kembali 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 pemanfaatan sumber daya rantai penghubung 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 secara default mempercayai penyortir tidak akan berperilaku jahat, sehingga menjamin keberlangsungan rollup.
Namun, dalam konsep desain Polkadot, kita tidak dapat membuat asumsi kepercayaan terhadap sequencer, karena harus mempertahankan karakteristik "tanpa kepercayaan" dan "tanpa izin" dari sistem. Siapa pun seharusnya dapat menggunakan protokol collator untuk mengajukan permintaan perubahan status rollup.
Polkadot: Solusi tanpa kompromi
Solusi yang akhirnya dipilih oleh Polkadot adalah: menyerahkan masalah sepenuhnya kepada fungsi konversi status rollup (Runtime). Runtime adalah satu-satunya sumber informasi konsensus yang dapat dipercaya, oleh karena itu harus dinyatakan dengan jelas di output di mana verifikasi harus dilakukan pada inti Polkadot mana.
Desain ini mewujudkan perlindungan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang perubahan status rollup dalam proses ketersediaan dan memastikan kebenaran alokasi inti melalui protokol ekonomi terenkripsi ELVES.
Sebelum menulis data dari rollup blok ke lapisan ketersediaan data Polkadot, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat dan bukti keabsahan yang diserahkan oleh penyortir, yang berisi blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi parachain dan dieksekusi ulang oleh validator di relay chain.
Hasil verifikasi mencakup sebuah core selector, yang digunakan untuk menentukan pada core mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut dengan core yang menjadi tanggung jawabnya; jika tidak konsisten, blok tersebut akan dibuang.
Mekanisme ini memastikan bahwa sistem selalu mempertahankan sifat tanpa kepercayaan dan tanpa izin, menghindari manipulasi posisi verifikasi oleh aktor jahat seperti sorter, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, itu tetap dapat bertahan.
Keamanan
Dalam proses mengejar skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai relai, hanya memerlukan satu pengurut jujur untuk menjaga kelangsungan hidup.
Dengan bantuan protokol ELVES, Polkadot sepenuhnya memperluas keamanannya ke semua rollup, memverifikasi semua perhitungan di core tanpa perlu membatasi atau membuat asumsi tentang jumlah core yang digunakan.
Oleh karena itu, rollup Polkadot dapat mencapai skalabilitas nyata tanpa mengorbankan keamanan.
Universalitas
Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung eksekusi komputasi Turing lengkap dalam lingkungan WebAssembly, asalkan eksekusi tunggal diselesaikan dalam waktu 2 detik. Dengan bantuan ekspansi elastis, total jumlah komputasi yang dapat dieksekusi dalam periode 6 detik meningkat, tetapi jenis komputasi tidak terpengaruh.
kompleksitas
Throughput yang lebih tinggi dan latensi yang lebih rendah pasti akan memperkenalkan kompleksitas, ini adalah satu-satunya cara 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 menyesuaikan dengan berbagai skenario penggunaan.
Kompleksitas spesifik tergantung pada strategi manajemen sumber daya rollup, yang mungkin bergantung pada variabel on-chain atau off-chain. Misalnya:
Strategi sederhana: selalu gunakan jumlah core yang tetap, atau sesuaikan secara manual melalui off-chain;
Strategi ringan: Memantau beban transaksi tertentu di mempool node;
Strategi otomatis: Mengkonfigurasi sumber daya layanan coretime dengan memanggil lebih awal melalui data historis dan antarmuka XCM.
Meskipun cara otomatisasi lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.
Interoperabilitas
Polkadot mendukung interoperabilitas antara berbagai rollup, sementara skalabilitas elastis tidak akan mempengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diwujudkan oleh lapisan transportasi dasar, ruang blok komunikasi setiap rollup adalah tetap dan tidak bergantung 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 seiring dengan peningkatan elastisitas, lebih lanjut memperkuat kemampuan skalabilitas vertikal sistem.
Apa kompromi yang dibuat oleh protokol lain?
Seperti yang kita ketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, dari perspektif 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, melainkan mencapai skalabilitas dengan arsitektur throughput tinggi lapisan tunggal, mengandalkan bukti sejarah (PoH), pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoritis mencapai 65.000.
Salah satu desain kunci adalah mekanisme penjadwalan pemimpin yang dipublikasikan dan dapat diverifikasi sebelumnya:
Pada awal setiap epoch (sekitar dua hari atau 432.000 slot), slot dialokasikan berdasarkan jumlah staking;
Semakin banyak yang dipertaruhkan, semakin banyak yang akan dialokasikan. Misalnya, validator yang mempertaruhkan 1% akan mendapatkan sekitar 1% peluang untuk memproduksi blok;
Semua penghasil blok diumumkan sebelumnya, meningkatkan risiko jaringan mengalami serangan DDoS terarah dan sering mengalami downtime.
PoH dan pemrosesan paralel memiliki tuntutan perangkat keras yang sangat tinggi, yang menyebabkan sentralisasi node verifikasi. Semakin banyak node yang dipertaruhkan, semakin besar peluang mereka untuk menghasilkan blok, sedangkan node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan meningkatkan risiko sistem mengalami keruntuhan setelah diserang.
Solana mengorbankan desentralisasi dan ketahanan terhadap serangan untuk mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh di bawah Polkadot yang mencapai 172.
TON
TON mengklaim TPS dapat mencapai 104,715, tetapi angka ini dicapai di jaringan pengujian privat, dengan 256 node, 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 validasi shard akan terungkap sebelumnya. Buku putih TON juga dengan jelas menyatakan bahwa meskipun ini dapat mengoptimalkan bandwidth, ini juga dapat disalahgunakan. Karena kurangnya mekanisme "kebangkrutan penjudi", penyerang dapat menunggu shard tertentu sepenuhnya berada di bawah kontrolnya, atau menggunakan serangan DDoS untuk memblokir validator yang jujur, sehingga mengubah status.
Sebaliknya, validator Polkadot ditugaskan secara acak dan diungkapkan dengan penundaan, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Serangan harus mempertaruhkan semua kontrol untuk berhasil; selama ada satu validator yang jujur yang mengajukan sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk skala, mainnet 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 pendekatan Polkadot: mengurangi beban shard tunggal untuk mencapai skalabilitas. Namun, Avalanche memungkinkan validator untuk memilih untuk berpartisipasi dalam subnet secara bebas, 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, perlu berkompromi pada kinerja, dan sulit untuk memberikan janji keamanan yang pasti.
Ethereum
Strategi skalabilitas Ethereum adalah bertaruh pada skalabilitas lapisan rollup, bukan langsung menyelesaikan masalah di lapisan dasar. Cara ini pada dasarnya tidak menyelesaikan masalah, tetapi 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 keamanan yang tidak memadai, saling terisolasi, dan latensi tinggi (harus menunggu periode pembuktian penipuan, biasanya beberapa hari).
ZK Rollup
Implementasi ZK rollup terbatas oleh jumlah data yang dapat diproses per transaksi. Permintaan komputasi untuk menghasilkan bukti nol pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semua" mudah menyebabkan sentralisasi sistem. Untuk menjamin TPS, ZK rollup sering membatasi jumlah transaksi per batch, yang dapat menyebabkan kemacetan jaringan dan kenaikan gas saat permintaan tinggi, mempengaruhi pengalaman pengguna.
Jika dibandingkan, biaya ZK rollup yang Turing lengkap adalah sekitar 2x10^6 kali dari protokol keamanan ekonomi inti Polkadot.
Selain itu, masalah ketersediaan data pada ZK rollup juga akan memperburuk kelemahannya. Untuk memastikan siapa pun dapat memverifikasi transaksi, data transaksi lengkap masih perlu disediakan. Ini biasanya bergantung pada solusi ketersediaan data tambahan, yang semakin meningkatkan biaya dan biaya pengguna.
Kesimpulan
Akhir dari skalabilitas tidak seharusnya menjadi kompromi.
Dibandingkan dengan blockchain publik lainnya, Polkadot tidak mengambil jalan untuk mengorbankan desentralisasi demi kinerja, atau mengorbankan kepercayaan yang telah ditentukan demi efisiensi, melainkan mencapai keseimbangan multidimensi antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang elastis, tanpa izin, lapisan keamanan yang terintegrasi, dan mekanisme pengelolaan sumber daya yang fleksibel.
Dalam mengejar penerapan skala yang lebih besar saat ini, "skala tanpa kepercayaan" yang dipegang oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung perkembangan jangka panjang Web3.