Trade-off dan Tantangan Skalabilitas Blockchain: Solusi Polkadot
Di tengah upaya terus-menerus untuk mencapai efisiensi yang lebih tinggi dalam teknologi Blockchain, sebuah masalah kunci semakin terlihat: bagaimana meningkatkan kinerja tanpa mengorbankan keamanan dan kelincahan sistem? Ini bukan hanya tantangan di tingkat teknis, 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.
Polkadot sebagai pendorong penting dalam skalabilitas Web3, apakah model rollup-nya mengorbankan desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan menganalisis secara mendalam pertimbangan dan kompromi Polkadot dalam desain skalabilitasnya, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, mengeksplorasi pilihan jalur yang berbeda dalam kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara elastisitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan rantai relai (Relay Chain), yang mungkin memperkenalkan risiko sentralisasi dalam beberapa aspek. Operasi Rollup bergantung pada penyusun (sequencer) yang menghubungkan rantai relai, dengan komunikasi menggunakan mekanisme protokol collator. Protokol ini sepenuhnya tanpa izin, tanpa kepercayaan, siapa pun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node rantai relai, dan mengajukan permintaan perubahan status rollup.
pertimbangan perluasan vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "Elastic Scaling". Namun, karena validasi blok rollup tidak dilakukan secara tetap pada satu core, ini dapat mempengaruhi elastisitasnya. Penyerang mungkin memanfaatkan hal ini dengan mengajukan blok sah yang telah divalidasi sebelumnya berulang kali ke core yang berbeda, secara jahat menghabiskan sumber daya, sehingga mengurangi throughput dan efisiensi keseluruhan rollup.
Masalah kepercayaan Sequencer
Salah satu solusi sederhana adalah mengatur protokol menjadi "berlisensi", misalnya dengan menggunakan mekanisme daftar putih, atau secara default mempercayai urutan tidak akan berperilaku jahat. Namun, dalam filosofi desain Polkadot, tidak boleh ada asumsi kepercayaan terhadap sequencer, karena harus mempertahankan karakteristik "tanpa kepercayaan" dan "tanpa izin" dari sistem.
Solusi Polkadot
Solusi akhir yang dipilih oleh Polkadot adalah: menyerahkan masalah sepenuhnya kepada fungsi konversi status rollup (Runtime). Runtime adalah satu-satunya sumber informasi konsensus yang dapat dipercaya, dan harus secara jelas menyatakan di output di mana verifikasi harus dilakukan pada inti Polkadot.
Desain ini mewujudkan perlindungan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang transisi status rollup dalam proses ketersediaan, dan memastikan kebenaran alokasi inti melalui protokol ekonomi terenkripsi ELVES.
Sebelum data yang ditulis di lapisan ketersediaan data (DA) Polkadot untuk blok rollup, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima kandidat tanda terima dan bukti validitas yang diajukan oleh penyortir, yang berisi blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi dari rantai paralel dan dieksekusi ulang oleh validator di rantai relai.
Hasil verifikasi mencakup sebuah core selector, yang digunakan untuk menentukan pada core mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut apakah sesuai 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 manipulasi posisi verifikasi oleh pelaku jahat seperti sorter, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, ia tetap dapat mempertahankan elastisitas.
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 inti tanpa perlu membatasi atau membuat asumsi tentang jumlah inti yang digunakan.
Universalitas
Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung eksekusi komputasi Turing lengkap dalam lingkungan WebAssembly, asalkan setiap eksekusi selesai dalam waktu 2 detik. Dengan bantuan ekspansi elastis, jumlah total komputasi yang dapat dieksekusi dalam periode 6 detik dapat ditingkatkan, 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 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 dari 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, dan 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 lapisan kontrol, bukan lapisan data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan peningkatan skala elastis, yang lebih lanjut memperkuat kemampuan skala vertikal sistem.
Pertimbangan Protokol Lain
Seperti yang kita ketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, dari sudut pandang koefisien Nakamoto, meskipun tingkat desentralisasi beberapa pesaing Polkadot lebih rendah, kinerja mereka tidak memuaskan.
Solana
Solana menggunakan arsitektur throughput tinggi lapisan tunggal untuk mencapai skalabilitas, bergantung pada pembuktian sejarah (PoH), pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoritis mencapai 65.000. Desain kuncinya adalah mekanisme penjadwalan pemimpin yang dapat dipublikasikan dan diverifikasi sebelumnya.
Namun, PoH dan pemrosesan paralel memiliki tuntutan perangkat keras yang sangat tinggi, mengakibatkan sentralisasi node validasi. 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 menjadi lumpuh setelah diserang. Solana mengorbankan desentralisasi dan kemampuan anti serangan demi mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh di bawah Polkadot yang memiliki 172.
TON
TON mengklaim TPS dapat mencapai 104,715, tetapi angka ini dicapai di jaringan uji privat, dengan 256 node, dalam kondisi jaringan dan perangkat keras yang ideal. Sementara Polkadot di jaringan publik terdesentralisasi telah mencapai 128K TPS.
Mekanisme konsensus TON memiliki risiko keamanan: identitas node validasi sharding akan terungkap sebelumnya. Buku putih TON juga secara jelas menyatakan bahwa ini dapat mengoptimalkan bandwidth, tetapi juga dapat disalahgunakan. Karena kurangnya mekanisme "bangkrut penjudi", penyerang dapat menunggu suatu sharding berada di bawah kendalinya sepenuhnya, atau menggunakan serangan DDoS untuk menghalangi validator yang jujur, sehingga dapat memanipulasi status.
Dibandingkan dengan itu, 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 mengajukan sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk melakukan skalabilitas, di mana mainnet terdiri dari X-Chain (transfer, ~4.500 TPS), C-Chain (kontrak pintar, ~100-200 TPS), dan P-Chain (mengelola validator dan subnet). Setiap subnet secara teoritis dapat mencapai TPS hingga ~5.000, mirip dengan pendekatan Polkadot: mengurangi beban pada shard tunggal untuk mencapai skalabilitas.
Namun Avalanche memungkinkan validator untuk memilih secara bebas untuk berpartisipasi dalam subnet, dan subnet dapat menetapkan persyaratan tambahan seperti geografi, KYC, dan sebagainya, yang牺牲了去中心化与安全性. Di Polkadot, semua rollup berbagi jaminan keamanan yang seragam; 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 janji keamanan yang pasti.
Ethereum
Strategi skalabilitas Ethereum adalah bertaruh pada skalabilitas lapisan rollup, alih-alih menyelesaikan masalah di lapisan dasar secara langsung. Cara ini pada dasarnya tidak menyelesaikan masalah, melainkan meneruskan masalah ke lapisan di atas tumpukan.
Optimistic Rollup saat ini sebagian besar terpusat, memiliki masalah seperti kurangnya keamanan, terisolasi satu sama lain, dan latensi tinggi (harus menunggu periode bukti penipuan, biasanya beberapa hari).
Implementasi ZK Rollup terbatas oleh jumlah data yang dapat diproses per transaksi. Kebutuhan komputasi untuk menghasilkan bukti nol pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semuanya" cenderung menyebabkan sentralisasi sistem. Untuk memastikan TPS, ZK rollup sering membatasi volume transaksi per batch, yang dapat menyebabkan kemacetan jaringan dan kenaikan gas saat permintaan tinggi, mempengaruhi pengalaman pengguna.
Sebagai perbandingan, biaya ZK rollup yang Turing lengkap adalah sekitar 2x10^6 kali dari protokol keamanan ekonomi inti Polkadot. Selain itu, masalah ketersediaan data 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 seharusnya bukan kompromi. Dibandingkan dengan blockchain publik lainnya, Polkadot tidak mengambil jalan mengorbankan desentralisasi untuk kinerja, atau mengorbankan kepercayaan yang sudah ditetapkan untuk efisiensi, melainkan mencapai keseimbangan multidimensi antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang elastis dan tidak memerlukan izin, lapisan keamanan yang terpadu, serta mekanisme manajemen sumber daya yang fleksibel.
Dalam upaya untuk mewujudkan aplikasi berskala lebih besar, "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.
22 Suka
Hadiah
22
6
Bagikan
Komentar
0/400
DuskSurfer
· 07-09 17:45
DOT belum mati itu adalah hal yang baik
Lihat AsliBalas0
StakeOrRegret
· 07-09 03:46
Lao Gai telah dipermainkan oleh dot.
Lihat AsliBalas0
CryptoPunster
· 07-09 03:45
Sudah saatnya untuk membahas segitiga pengorbanan, siapa yang squat dan siapa yang berdiri jelas terlihat.
Lihat AsliBalas0
Token_Sherpa
· 07-09 03:43
meh... satu L1 lain menjanjikan trinitas suci dari skalabilitas. sudah ada, sudah dilakukan, kehilangan uang di ICOs smh
Lihat AsliBalas0
OnchainSniper
· 07-09 03:42
Lebih baik langsung membicarakan data kinerja.
Lihat AsliBalas0
SelfCustodyBro
· 07-09 03:31
Jangan bicara tentang perluasan, mari kita bicarakan tentang dot yang turun parah hari ini.
Bagaimana Polkadot mencapai perluasan kinerja tinggi tanpa mengorbankan keamanan dan Desentralisasi
Trade-off dan Tantangan Skalabilitas Blockchain: Solusi Polkadot
Di tengah upaya terus-menerus untuk mencapai efisiensi yang lebih tinggi dalam teknologi Blockchain, sebuah masalah kunci semakin terlihat: bagaimana meningkatkan kinerja tanpa mengorbankan keamanan dan kelincahan sistem? Ini bukan hanya tantangan di tingkat teknis, 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.
Polkadot sebagai pendorong penting dalam skalabilitas Web3, apakah model rollup-nya mengorbankan desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan menganalisis secara mendalam pertimbangan dan kompromi Polkadot dalam desain skalabilitasnya, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, mengeksplorasi pilihan jalur yang berbeda dalam kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara elastisitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan rantai relai (Relay Chain), yang mungkin memperkenalkan risiko sentralisasi dalam beberapa aspek. Operasi Rollup bergantung pada penyusun (sequencer) yang menghubungkan rantai relai, dengan komunikasi menggunakan mekanisme protokol collator. Protokol ini sepenuhnya tanpa izin, tanpa kepercayaan, siapa pun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node rantai relai, dan mengajukan permintaan perubahan status rollup.
pertimbangan perluasan vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "Elastic Scaling". Namun, karena validasi blok rollup tidak dilakukan secara tetap pada satu core, ini dapat mempengaruhi elastisitasnya. Penyerang mungkin memanfaatkan hal ini dengan mengajukan blok sah yang telah divalidasi sebelumnya berulang kali ke core yang berbeda, secara jahat menghabiskan sumber daya, sehingga mengurangi throughput dan efisiensi keseluruhan rollup.
Masalah kepercayaan Sequencer
Salah satu solusi sederhana adalah mengatur protokol menjadi "berlisensi", misalnya dengan menggunakan mekanisme daftar putih, atau secara default mempercayai urutan tidak akan berperilaku jahat. Namun, dalam filosofi desain Polkadot, tidak boleh ada asumsi kepercayaan terhadap sequencer, karena harus mempertahankan karakteristik "tanpa kepercayaan" dan "tanpa izin" dari sistem.
Solusi Polkadot
Solusi akhir yang dipilih oleh Polkadot adalah: menyerahkan masalah sepenuhnya kepada fungsi konversi status rollup (Runtime). Runtime adalah satu-satunya sumber informasi konsensus yang dapat dipercaya, dan harus secara jelas menyatakan di output di mana verifikasi harus dilakukan pada inti Polkadot.
Desain ini mewujudkan perlindungan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang transisi status rollup dalam proses ketersediaan, dan memastikan kebenaran alokasi inti melalui protokol ekonomi terenkripsi ELVES.
Sebelum data yang ditulis di lapisan ketersediaan data (DA) Polkadot untuk blok rollup, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima kandidat tanda terima dan bukti validitas yang diajukan oleh penyortir, yang berisi blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi dari rantai paralel dan dieksekusi ulang oleh validator di rantai relai.
Hasil verifikasi mencakup sebuah core selector, yang digunakan untuk menentukan pada core mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut apakah sesuai 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 manipulasi posisi verifikasi oleh pelaku jahat seperti sorter, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, ia tetap dapat mempertahankan elastisitas.
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 inti tanpa perlu membatasi atau membuat asumsi tentang jumlah inti yang digunakan.
Universalitas
Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung eksekusi komputasi Turing lengkap dalam lingkungan WebAssembly, asalkan setiap eksekusi selesai dalam waktu 2 detik. Dengan bantuan ekspansi elastis, jumlah total komputasi yang dapat dieksekusi dalam periode 6 detik dapat ditingkatkan, 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 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 dari 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, dan 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 lapisan kontrol, bukan lapisan data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan peningkatan skala elastis, yang lebih lanjut memperkuat kemampuan skala vertikal sistem.
Pertimbangan Protokol Lain
Seperti yang kita ketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, dari sudut pandang koefisien Nakamoto, meskipun tingkat desentralisasi beberapa pesaing Polkadot lebih rendah, kinerja mereka tidak memuaskan.
Solana
Solana menggunakan arsitektur throughput tinggi lapisan tunggal untuk mencapai skalabilitas, bergantung pada pembuktian sejarah (PoH), pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoritis mencapai 65.000. Desain kuncinya adalah mekanisme penjadwalan pemimpin yang dapat dipublikasikan dan diverifikasi sebelumnya.
Namun, PoH dan pemrosesan paralel memiliki tuntutan perangkat keras yang sangat tinggi, mengakibatkan sentralisasi node validasi. 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 menjadi lumpuh setelah diserang. Solana mengorbankan desentralisasi dan kemampuan anti serangan demi mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh di bawah Polkadot yang memiliki 172.
TON
TON mengklaim TPS dapat mencapai 104,715, tetapi angka ini dicapai di jaringan uji privat, dengan 256 node, dalam kondisi jaringan dan perangkat keras yang ideal. Sementara Polkadot di jaringan publik terdesentralisasi telah mencapai 128K TPS.
Mekanisme konsensus TON memiliki risiko keamanan: identitas node validasi sharding akan terungkap sebelumnya. Buku putih TON juga secara jelas menyatakan bahwa ini dapat mengoptimalkan bandwidth, tetapi juga dapat disalahgunakan. Karena kurangnya mekanisme "bangkrut penjudi", penyerang dapat menunggu suatu sharding berada di bawah kendalinya sepenuhnya, atau menggunakan serangan DDoS untuk menghalangi validator yang jujur, sehingga dapat memanipulasi status.
Dibandingkan dengan itu, 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 mengajukan sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk melakukan skalabilitas, di mana mainnet terdiri dari X-Chain (transfer, ~4.500 TPS), C-Chain (kontrak pintar, ~100-200 TPS), dan P-Chain (mengelola validator dan subnet). Setiap subnet secara teoritis dapat mencapai TPS hingga ~5.000, mirip dengan pendekatan Polkadot: mengurangi beban pada shard tunggal untuk mencapai skalabilitas.
Namun Avalanche memungkinkan validator untuk memilih secara bebas untuk berpartisipasi dalam subnet, dan subnet dapat menetapkan persyaratan tambahan seperti geografi, KYC, dan sebagainya, yang牺牲了去中心化与安全性. Di Polkadot, semua rollup berbagi jaminan keamanan yang seragam; 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 janji keamanan yang pasti.
Ethereum
Strategi skalabilitas Ethereum adalah bertaruh pada skalabilitas lapisan rollup, alih-alih menyelesaikan masalah di lapisan dasar secara langsung. Cara ini pada dasarnya tidak menyelesaikan masalah, melainkan meneruskan masalah ke lapisan di atas tumpukan.
Optimistic Rollup saat ini sebagian besar terpusat, memiliki masalah seperti kurangnya keamanan, terisolasi satu sama lain, dan latensi tinggi (harus menunggu periode bukti penipuan, biasanya beberapa hari).
Implementasi ZK Rollup terbatas oleh jumlah data yang dapat diproses per transaksi. Kebutuhan komputasi untuk menghasilkan bukti nol pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semuanya" cenderung menyebabkan sentralisasi sistem. Untuk memastikan TPS, ZK rollup sering membatasi volume transaksi per batch, yang dapat menyebabkan kemacetan jaringan dan kenaikan gas saat permintaan tinggi, mempengaruhi pengalaman pengguna.
Sebagai perbandingan, biaya ZK rollup yang Turing lengkap adalah sekitar 2x10^6 kali dari protokol keamanan ekonomi inti Polkadot. Selain itu, masalah ketersediaan data 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 seharusnya bukan kompromi. Dibandingkan dengan blockchain publik lainnya, Polkadot tidak mengambil jalan mengorbankan desentralisasi untuk kinerja, atau mengorbankan kepercayaan yang sudah ditetapkan untuk efisiensi, melainkan mencapai keseimbangan multidimensi antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang elastis dan tidak memerlukan izin, lapisan keamanan yang terpadu, serta mekanisme manajemen sumber daya yang fleksibel.
Dalam upaya untuk mewujudkan aplikasi berskala lebih besar, "ekstensibilitas tanpa kepercayaan" yang dipegang oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung perkembangan jangka panjang Web3.