Trade-off dan Keseimbangan Skalabilitas Blockchain: Studi Kasus Polkadot
Dalam era teknologi Blockchain yang terus mengejar efisiensi yang lebih tinggi, satu masalah kunci perlahan muncul: bagaimana menghindari pengorbanan keamanan dan elastisitas sistem sambil meningkatkan kinerja skala? Ini bukan hanya tantangan di tingkat teknologi, tetapi juga pilihan mendalam dalam desain arsitektur. Bagi ekosistem Web3, sebuah sistem yang lebih cepat jika dibangun di atas pengorbanan kepercayaan dan keamanan, sering kali sulit untuk mendukung inovasi yang benar-benar berkelanjutan.
Sebagai pendorong penting untuk skalabilitas Web3, apakah Polkadot juga telah melakukan beberapa pengorbanan dalam mencapai tujuan throughput tinggi dan latensi rendah? Apakah model rollup-nya telah membuat konsesi dalam hal desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan membahas masalah ini, menganalisis dengan mendalam pengorbanan dan pertimbangan desain skalabilitas Polkadot, dan membandingkannya dengan solusi dari blockchain publik utama lainnya, serta mengeksplorasi pilihan jalur mereka yang berbeda antara kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara elastisitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan chain relay, 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 penyusun (sorter) dari rantai penghubung (relay chain), yang komunikasinya menggunakan mekanisme yang disebut protokol collator. Protokol ini sepenuhnya tanpa izin, tanpa kepercayaan, siapa pun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node rantai penghubung, dan mengajukan permintaan perubahan status rollup. Permintaan ini akan divalidasi oleh salah satu core dari rantai penghubung, hanya perlu memenuhi satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tidak akan maju.
trade-off ekspansi vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "ekspansi yang fleksibel". Selama proses desain, ditemukan bahwa karena verifikasi blok rollup tidak tetap pada satu core tertentu, ini dapat mempengaruhi fleksibilitasnya.
Karena protokol untuk mengirim blok ke rantai perantara adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirim blok untuk diverifikasi di salah satu core yang ditugaskan kepada rollup. Penyerang mungkin memanfaatkan ini dengan mengirimkan blok sah yang telah diverifikasi sebelumnya berulang kali ke core yang berbeda, secara jahat menghabiskan sumber daya, sehingga menurunkan throughput dan efisiensi keseluruhan rollup.
Tujuan Polkadot adalah untuk mempertahankan elastisitas rollup dan pemanfaatan 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 secara default mempercayai penyortir tidak akan berperilaku jahat, sehingga menjamin aktivitas rollup.
Namun, dalam desain Polkadot, kita tidak dapat melakukan 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 Kompromi
Solusi yang dipilih oleh Polkadot pada akhirnya adalah: menyerahkan masalah sepenuhnya kepada fungsi konversi status rollup (Runtime). Runtime adalah satu-satunya sumber informasi konsensus yang dapat dipercaya, oleh karena itu harus secara jelas menyatakan pada output di mana verifikasi harus dilakukan pada inti Polkadot.
Desain ini mewujudkan perlindungan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang status rollup dalam proses ketersediaan, dan memastikan keakuratan distribusi inti melalui protokol ekonomi terenkripsi ELVES.
Sebelum data yang ditulis ke dalam lapisan ketersediaan data Polkadot oleh rollup Blok, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat dan bukti validitas yang diajukan oleh penyortir, yang mencakup Blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi paralel, yang akan dijalankan ulang oleh validator di rantai penghubung.
Hasil verifikasi mencakup sebuah core selector, yang digunakan untuk menentukan di core mana blok harus diverifikasi. Validator akan membandingkan indeks ini dengan core yang menjadi tanggung jawabnya; jika tidak sesuai, blok tersebut akan dibuang.
Mekanisme ini memastikan bahwa sistem selalu mempertahankan sifat tanpa kepercayaan dan tanpa izin, menghindari perilaku jahat seperti pengendali urutan yang memanipulasi posisi verifikasi, memastikan bahwa bahkan jika rollup menggunakan beberapa core, ia tetap dapat mempertahankan elastisitas.
Keamanan
Dalam upaya untuk mencapai skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai penghubung, hanya membutuhkan satu penyortir yang jujur untuk mempertahankan kelangsungan hidup.
Dengan bantuan protokol ELVES, Polkadot memperluas keamanan secara menyeluruh 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 yang nyata tanpa mengorbankan keamanan.
Keterpakaian
Ekspansi elastis tidak akan membatasi kemampuan pemrograman 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 setiap siklus 6 detik meningkat, tetapi jenis komputasi tidak terpengaruh.
Kompleksitas
Melalui throughput yang lebih tinggi dan latensi yang lebih rendah, kompleksitas tidak dapat dihindari, yang merupakan satu-satunya cara untuk melakukan trade-off 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. Contohnya:
Strategi sederhana: selalu gunakan jumlah core yang tetap, 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 antara berbagai rollup, 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, terlepas dari jumlah inti yang dialokasikan.
Di masa depan, Polkadot juga akan mendukung pengiriman pesan di luar rantai, dengan rantai perantara sebagai kontrol, bukan sebagai data. Pembaruan ini akan meningkatkan kemampuan komunikasi antar rollup bersamaan dengan peningkatan elastisitas, lebih lanjut memperkuat kemampuan skalabilitas vertikal sistem.
Apa kompromi yang dilakukan oleh protokol lain?
Seperti yang kita ketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, dari segi koefisien Nakamoto, meskipun beberapa pesaing Polkadot memiliki tingkat desentralisasi yang lebih rendah, kinerja mereka juga tidak memuaskan.
Solana
Solana tidak menggunakan arsitektur shard Polkadot atau Ethereum, melainkan mengimplementasikan skalabilitas dengan arsitektur throughput tinggi lapisan tunggal, bergantung pada bukti historis, pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoritis mencapai 65.000.
Salah satu desain kunci adalah mekanisme penjadwalan pemimpin yang dipublikasikan sebelumnya dan dapat diverifikasi:
Pada awal setiap epoch (sekitar dua hari atau 432.000 slot), slot dibagikan berdasarkan jumlah staking;
Semakin banyak yang dipertaruhkan, semakin banyak alokasi yang didapat. Misalnya, validator yang mempertaruhkan 1% akan mendapatkan sekitar 1% peluang untuk menghasilkan blok;
Semua penghasil blok diumumkan sebelumnya, meningkatkan risiko jaringan terkena serangan DDoS terarah dan sering mengalami downtime.
Sejarah membuktikan bahwa pemrosesan paralel memerlukan perangkat keras yang sangat tinggi, yang mengakibatkan sentralisasi nodus verifikasi. Semakin banyak nodus yang dipertaruhkan, semakin besar peluang mereka untuk memproduksi blok, sementara nodus kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan juga meningkatkan risiko sistem lumpuh setelah diserang.
Solana牺牲去中心化和 kemampuan anti serangan demi mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh lebih rendah daripada Polkadot yang mencapai 172.
TON
TON mengklaim TPS dapat mencapai 104.715, tetapi angka ini dicapai di jaringan uji privat, dengan 256 node, dan dalam kondisi jaringan serta perangkat keras yang ideal. Sementara Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.
Mekanisme konsensus TON memiliki potensi risiko keamanan: identitas node verifikasi sharding akan terungkap sebelumnya. Buku putih TON juga secara jelas menyatakan bahwa meskipun ini dapat mengoptimalkan bandwidth, hal ini juga dapat disalahgunakan. Karena kurangnya mekanisme "kepailitan penjudi", penyerang dapat menunggu shard tertentu sepenuhnya berada di bawah kendalinya, atau dengan serangan DDoS menghalangi validator yang jujur, sehingga memanipulasi status.
Sebaliknya, 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 jika ada satu validator yang jujur mengajukan sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk melakukan skala, mainnet terdiri dari X-Chain (transfer, ~4.500 TPS), C-Chain (smart contract, ~100-200 TPS), P-Chain (mengelola validator dan subnet).
Setiap subnet memiliki TPS teoritis hingga ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban shard tunggal untuk mencapai skalabilitas. Namun, Avalanche memungkinkan validator untuk memilih partisipasi dalam subnet secara bebas, dan subnet dapat menetapkan persyaratan tambahan seperti geografis, KYC, dan lain-lain, mengorbankan desentralisasi dan keamanan.
Di Polkadot, semua rollup berbagi jaminan keamanan yang terintegrasi; sedangkan subnet Avalanche tidak memiliki jaminan keamanan default, beberapa bahkan dapat sepenuhnya terpusat. Jika ingin meningkatkan keamanan, masih perlu mengorbankan kinerja, dan sulit untuk memberikan komitmen keamanan yang pasti.
Ethereum
Strategi skalabilitas Ethereum adalah bertaruh pada skalabilitas lapisan rollup, bukan menyelesaikan masalah secara langsung di lapisan dasar. Cara ini pada dasarnya tidak menyelesaikan masalah, melainkan meneruskan masalah tersebut 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, terisolasi satu sama lain, dan latensi tinggi (perlu menunggu periode bukti 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" cenderung menyebabkan sentralisasi sistem. Untuk memastikan TPS, ZK rollup sering membatasi volume transaksi per batch, yang dapat menyebabkan kemacetan jaringan dan peningkatan gas saat permintaan tinggi, mempengaruhi pengalaman pengguna.
Jika dibandingkan, biaya ZK rollup yang Turing lengkap adalah sekitar 2x10^6 kali dari protokol keamanan ekonomi kriptografi inti Polkadot.
Selain itu, masalah ketersediaan data ZK rollup juga akan memperburuk kelemahannya. Untuk memastikan siapa pun dapat memverifikasi transaksi, data transaksi lengkap tetap harus disediakan. Ini biasanya bergantung pada solusi ketersediaan data tambahan, yang semakin meningkatkan biaya dan biaya pengguna.
Kesimpulan
Akhir dari skalabilitas seharusnya bukan kompromi.
Dibandingkan dengan blockchain publik lainnya, Polkadot tidak mengambil jalan untuk mengganti kinerja dengan sentralisasi atau efisiensi dengan kepercayaan yang telah ditentukan, melainkan mencapai keseimbangan multidimensional antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang fleksibel dan 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.
Polkadot elastisitas skala: mencari keseimbangan antara kinerja dan Desentralisasi
Trade-off dan Keseimbangan Skalabilitas Blockchain: Studi Kasus Polkadot
Dalam era teknologi Blockchain yang terus mengejar efisiensi yang lebih tinggi, satu masalah kunci perlahan muncul: bagaimana menghindari pengorbanan keamanan dan elastisitas sistem sambil meningkatkan kinerja skala? Ini bukan hanya tantangan di tingkat teknologi, tetapi juga pilihan mendalam dalam desain arsitektur. Bagi ekosistem Web3, sebuah sistem yang lebih cepat jika dibangun di atas pengorbanan kepercayaan dan keamanan, sering kali sulit untuk mendukung inovasi yang benar-benar berkelanjutan.
Sebagai pendorong penting untuk skalabilitas Web3, apakah Polkadot juga telah melakukan beberapa pengorbanan dalam mencapai tujuan throughput tinggi dan latensi rendah? Apakah model rollup-nya telah membuat konsesi dalam hal desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan membahas masalah ini, menganalisis dengan mendalam pengorbanan dan pertimbangan desain skalabilitas Polkadot, dan membandingkannya dengan solusi dari blockchain publik utama lainnya, serta mengeksplorasi pilihan jalur mereka yang berbeda antara kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara elastisitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan chain relay, 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 penyusun (sorter) dari rantai penghubung (relay chain), yang komunikasinya menggunakan mekanisme yang disebut protokol collator. Protokol ini sepenuhnya tanpa izin, tanpa kepercayaan, siapa pun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node rantai penghubung, dan mengajukan permintaan perubahan status rollup. Permintaan ini akan divalidasi oleh salah satu core dari rantai penghubung, hanya perlu memenuhi satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tidak akan maju.
trade-off ekspansi vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "ekspansi yang fleksibel". Selama proses desain, ditemukan bahwa karena verifikasi blok rollup tidak tetap pada satu core tertentu, ini dapat mempengaruhi fleksibilitasnya.
Karena protokol untuk mengirim blok ke rantai perantara adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirim blok untuk diverifikasi di salah satu core yang ditugaskan kepada rollup. Penyerang mungkin memanfaatkan ini dengan mengirimkan blok sah yang telah diverifikasi sebelumnya berulang kali ke core yang berbeda, secara jahat menghabiskan sumber daya, sehingga menurunkan throughput dan efisiensi keseluruhan rollup.
Tujuan Polkadot adalah untuk mempertahankan elastisitas rollup dan pemanfaatan 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 secara default mempercayai penyortir tidak akan berperilaku jahat, sehingga menjamin aktivitas rollup.
Namun, dalam desain Polkadot, kita tidak dapat melakukan 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 Kompromi
Solusi yang dipilih oleh Polkadot pada akhirnya adalah: menyerahkan masalah sepenuhnya kepada fungsi konversi status rollup (Runtime). Runtime adalah satu-satunya sumber informasi konsensus yang dapat dipercaya, oleh karena itu harus secara jelas menyatakan pada output di mana verifikasi harus dilakukan pada inti Polkadot.
Desain ini mewujudkan perlindungan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang status rollup dalam proses ketersediaan, dan memastikan keakuratan distribusi inti melalui protokol ekonomi terenkripsi ELVES.
Sebelum data yang ditulis ke dalam lapisan ketersediaan data Polkadot oleh rollup Blok, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat dan bukti validitas yang diajukan oleh penyortir, yang mencakup Blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi paralel, yang akan dijalankan ulang oleh validator di rantai penghubung.
Hasil verifikasi mencakup sebuah core selector, yang digunakan untuk menentukan di core mana blok harus diverifikasi. Validator akan membandingkan indeks ini dengan core yang menjadi tanggung jawabnya; jika tidak sesuai, blok tersebut akan dibuang.
Mekanisme ini memastikan bahwa sistem selalu mempertahankan sifat tanpa kepercayaan dan tanpa izin, menghindari perilaku jahat seperti pengendali urutan yang memanipulasi posisi verifikasi, memastikan bahwa bahkan jika rollup menggunakan beberapa core, ia tetap dapat mempertahankan elastisitas.
Keamanan
Dalam upaya untuk mencapai skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai penghubung, hanya membutuhkan satu penyortir yang jujur untuk mempertahankan kelangsungan hidup.
Dengan bantuan protokol ELVES, Polkadot memperluas keamanan secara menyeluruh 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 yang nyata tanpa mengorbankan keamanan.
Keterpakaian
Ekspansi elastis tidak akan membatasi kemampuan pemrograman 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 setiap siklus 6 detik meningkat, tetapi jenis komputasi tidak terpengaruh.
Kompleksitas
Melalui throughput yang lebih tinggi dan latensi yang lebih rendah, kompleksitas tidak dapat dihindari, yang merupakan satu-satunya cara untuk melakukan trade-off 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. Contohnya:
Strategi sederhana: selalu gunakan jumlah core yang tetap, 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 antara berbagai rollup, 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, terlepas dari jumlah inti yang dialokasikan.
Di masa depan, Polkadot juga akan mendukung pengiriman pesan di luar rantai, dengan rantai perantara sebagai kontrol, bukan sebagai data. Pembaruan ini akan meningkatkan kemampuan komunikasi antar rollup bersamaan dengan peningkatan elastisitas, lebih lanjut memperkuat kemampuan skalabilitas vertikal sistem.
Apa kompromi yang dilakukan oleh protokol lain?
Seperti yang kita ketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, dari segi koefisien Nakamoto, meskipun beberapa pesaing Polkadot memiliki tingkat desentralisasi yang lebih rendah, kinerja mereka juga tidak memuaskan.
Solana
Solana tidak menggunakan arsitektur shard Polkadot atau Ethereum, melainkan mengimplementasikan skalabilitas dengan arsitektur throughput tinggi lapisan tunggal, bergantung pada bukti historis, pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoritis mencapai 65.000.
Salah satu desain kunci adalah mekanisme penjadwalan pemimpin yang dipublikasikan sebelumnya dan dapat diverifikasi:
Pada awal setiap epoch (sekitar dua hari atau 432.000 slot), slot dibagikan berdasarkan jumlah staking;
Semakin banyak yang dipertaruhkan, semakin banyak alokasi yang didapat. Misalnya, validator yang mempertaruhkan 1% akan mendapatkan sekitar 1% peluang untuk menghasilkan blok;
Semua penghasil blok diumumkan sebelumnya, meningkatkan risiko jaringan terkena serangan DDoS terarah dan sering mengalami downtime.
Sejarah membuktikan bahwa pemrosesan paralel memerlukan perangkat keras yang sangat tinggi, yang mengakibatkan sentralisasi nodus verifikasi. Semakin banyak nodus yang dipertaruhkan, semakin besar peluang mereka untuk memproduksi blok, sementara nodus kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan juga meningkatkan risiko sistem lumpuh setelah diserang.
Solana牺牲去中心化和 kemampuan anti serangan demi mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh lebih rendah daripada Polkadot yang mencapai 172.
TON
TON mengklaim TPS dapat mencapai 104.715, tetapi angka ini dicapai di jaringan uji privat, dengan 256 node, dan dalam kondisi jaringan serta perangkat keras yang ideal. Sementara Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.
Mekanisme konsensus TON memiliki potensi risiko keamanan: identitas node verifikasi sharding akan terungkap sebelumnya. Buku putih TON juga secara jelas menyatakan bahwa meskipun ini dapat mengoptimalkan bandwidth, hal ini juga dapat disalahgunakan. Karena kurangnya mekanisme "kepailitan penjudi", penyerang dapat menunggu shard tertentu sepenuhnya berada di bawah kendalinya, atau dengan serangan DDoS menghalangi validator yang jujur, sehingga memanipulasi status.
Sebaliknya, 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 jika ada satu validator yang jujur mengajukan sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk melakukan skala, mainnet terdiri dari X-Chain (transfer, ~4.500 TPS), C-Chain (smart contract, ~100-200 TPS), P-Chain (mengelola validator dan subnet).
Setiap subnet memiliki TPS teoritis hingga ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban shard tunggal untuk mencapai skalabilitas. Namun, Avalanche memungkinkan validator untuk memilih partisipasi dalam subnet secara bebas, dan subnet dapat menetapkan persyaratan tambahan seperti geografis, KYC, dan lain-lain, mengorbankan desentralisasi dan keamanan.
Di Polkadot, semua rollup berbagi jaminan keamanan yang terintegrasi; sedangkan subnet Avalanche tidak memiliki jaminan keamanan default, beberapa bahkan dapat sepenuhnya terpusat. Jika ingin meningkatkan keamanan, masih perlu mengorbankan kinerja, dan sulit untuk memberikan komitmen keamanan yang pasti.
Ethereum
Strategi skalabilitas Ethereum adalah bertaruh pada skalabilitas lapisan rollup, bukan menyelesaikan masalah secara langsung di lapisan dasar. Cara ini pada dasarnya tidak menyelesaikan masalah, melainkan meneruskan masalah tersebut 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, terisolasi satu sama lain, dan latensi tinggi (perlu menunggu periode bukti 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" cenderung menyebabkan sentralisasi sistem. Untuk memastikan TPS, ZK rollup sering membatasi volume transaksi per batch, yang dapat menyebabkan kemacetan jaringan dan peningkatan gas saat permintaan tinggi, mempengaruhi pengalaman pengguna.
Jika dibandingkan, biaya ZK rollup yang Turing lengkap adalah sekitar 2x10^6 kali dari protokol keamanan ekonomi kriptografi inti Polkadot.
Selain itu, masalah ketersediaan data ZK rollup juga akan memperburuk kelemahannya. Untuk memastikan siapa pun dapat memverifikasi transaksi, data transaksi lengkap tetap harus disediakan. Ini biasanya bergantung pada solusi ketersediaan data tambahan, yang semakin meningkatkan biaya dan biaya pengguna.
Kesimpulan
Akhir dari skalabilitas seharusnya bukan kompromi.
Dibandingkan dengan blockchain publik lainnya, Polkadot tidak mengambil jalan untuk mengganti kinerja dengan sentralisasi atau efisiensi dengan kepercayaan yang telah ditentukan, melainkan mencapai keseimbangan multidimensional antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang fleksibel dan 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.