Pertimbangan antara Skalabilitas dan Keamanan: Desain Arsitektur Web3 Polkadot
Di era di mana teknologi blockchain terus mengejar efisiensi yang lebih tinggi, sebuah pertanyaan kunci perlahan muncul: bagaimana cara meningkatkan performa tanpa mengorbankan keamanan dan ketahanan sistem? Ini bukan hanya tantangan di tingkat teknologi, tetapi juga melibatkan pertimbangan mendalam dalam desain arsitektur. Bagi ekosistem Web3, sebuah sistem yang cepat jika harus mengorbankan kepercayaan dan keamanan, sering kali sulit untuk mendukung inovasi yang benar-benar berkelanjutan.
Sebagai pendorong penting untuk skalabilitas Web3, apakah Polkadot telah membuat beberapa kompromi dalam mengejar throughput tinggi dan latensi rendah? Apakah model rollup-nya telah membuat pengorbanan dalam desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan membahas isu-isu ini, menganalisis dengan mendalam kompromi dan pertimbangan yang dilakukan Polkadot dalam desain skalabilitasnya, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, serta mengeksplorasi pilihan mereka yang berbeda antara kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara fleksibilitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan relai rantai, apakah ini mungkin memperkenalkan risiko sentralisasi dalam beberapa aspek? Apakah mungkin terbentuk titik kegagalan tunggal atau kontrol, yang dapat mempengaruhi karakteristik desentralisasinya?
Operasi Rollup bergantung pada penyortir yang terhubung ke rantai penghubung, dan komunikasi ini menggunakan mekanisme protokol kolator. 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 diverifikasi oleh salah satu core rantai penghubung, dengan satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tersebut tidak akan maju.
pertimbangan untuk memperluas secara 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 dijalankan pada satu core tertentu, hal ini dapat mempengaruhi elastisitasnya.
Karena protokol untuk mengirimkan blok ke rantai penghubung adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirimkan blok untuk diverifikasi pada inti mana pun yang dialokasikan untuk rollup. Penyerang mungkin memanfaatkan ini dengan mengirimkan kembali blok sah yang sebelumnya telah diverifikasi ke inti 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 relai tanpa mempengaruhi karakteristik kunci sistem.
Masalah Kepercayaan Sequencer
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 filosofi desain Polkadot, kita tidak dapat membuat asumsi kepercayaan terhadap sequencer, karena harus menjaga 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 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, sehingga 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 melaksanakan kembali proses transisi status rollup dalam alur ketersediaan, dan memastikan keakuratan alokasi core melalui protokol ekonomi kriptografi ELVES.
Sebelum menulis data dari rollup block ke lapisan ketersediaan data Polkadot, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat dan bukti keabsahan yang diajukan oleh penyorter, yang berisi rollup block dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi paralel chain dan dijalankan ulang oleh validator di relay chain.
Hasil verifikasi mencakup pemilih inti (core selector) yang digunakan untuk menentukan pada inti mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut dengan inti 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 perilaku jahat seperti pengendapan yang dapat memanipulasi posisi verifikasi, memastikan bahwa bahkan jika rollup menggunakan beberapa core, itu tetap dapat mempertahankan elastisitas.
Keamanan
Dalam upaya mencapai skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai relai, hanya membutuhkan satu pengurut jujur untuk menjaga kelangsungan.
Dengan bantuan protokol ELVES, Polkadot memperluas keamanan secara keseluruhan 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 sebenarnya tanpa mengorbankan keamanan.
Universalitas
Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung eksekusi komputasi Turing-complete dalam lingkungan WebAssembly, asalkan setiap eksekusi 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 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 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 elastisitas skala tidak mempengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diimplementasikan oleh lapisan transmisi dasar, ruang blok komunikasi setiap rollup adalah tetap, tidak terkait dengan jumlah inti yang dialokasikan.
Di masa depan, Polkadot juga akan mendukung pengiriman pesan di luar rantai, dengan rantai penghubung sebagai lapisan kontrol, bukan lapisan data. Peningkatan ini akan meningkatkan kemampuan komunikasi antara rollup seiring dengan peningkatan elastisitas, lebih lanjut memperkuat kemampuan skalabilitas vertikal sistem.
Pertimbangan Protokol Lain
Seperti yang diketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, melihat dari 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 menggunakan arsitektur throughput tinggi lapisan tunggal untuk mencapai skalabilitas, bergantung pada bukti sejarah, pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoritis mencapai 65.000.
Salah satu desain kunci adalah mekanisme penjadwalan pemimpin yang telah dipublikasikan sebelumnya dan dapat diverifikasi:
Pada awal setiap epoch (sekitar dua hari atau 432.000 slot), slot akan dialokasikan berdasarkan jumlah staking;
Semakin banyak staking, semakin banyak alokasi. Misalnya, validator yang melakukan staking 1% akan mendapatkan sekitar 1% kesempatan untuk memproduksi blok;
Semua pembuat blok diumumkan sebelumnya, meningkatkan risiko jaringan menghadapi serangan DDoS terarah dan downtime yang sering.
Sejarah membuktikan bahwa pemrosesan paralel memiliki tuntutan tinggi terhadap perangkat keras, yang menyebabkan sentralisasi node verifikasi. Semakin banyak node yang dipertaruhkan, semakin besar kesempatan untuk menghasilkan blok, sementara 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 mencapai 172.
TON
TON mengklaim TPS dapat mencapai 104.715, tetapi angka ini dicapai di jaringan pengujian privat, dengan 256 node, dan dalam kondisi jaringan dan perangkat keras yang ideal. Sementara itu, Polkadot telah mencapai 128K TPS di jaringan publik yang terdesentralisasi.
Mekanisme konsensus TON memiliki risiko keamanan: identitas node verifikasi shard akan terungkap sebelumnya. Buku putih TON juga dengan jelas menyatakan bahwa meskipun ini dapat mengoptimalkan bandwidth, namun 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 dapat memanipulasi status.
Sebagai perbandingan, validator Polkadot dialokasikan 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 atas taruhan.
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 sekitar ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban shard tunggal untuk mencapai skala. Namun, Avalanche memungkinkan validator untuk memilih dengan bebas untuk berpartisipasi dalam subnet, dan subnet dapat menetapkan persyaratan tambahan seperti geografis, KYC, dan lain-lain, mengorbankan desentralisasi dan keamanan.
Di Polkadot, semua rollup berbagi jaminan keamanan yang terpusat; sementara subnet Avalanche tidak memiliki jaminan keamanan secara default, beberapa bahkan bisa sepenuhnya terpusat. Jika ingin meningkatkan keamanan, masih harus mengorbankan performa, dan sulit untuk memberikan jaminan keamanan yang pasti.
Ethereum
Strategi skalabilitas Ethereum adalah bertaruh pada skalabilitas lapisan rollup, alih-alih menyelesaikan masalah langsung di lapisan dasar. Cara ini pada dasarnya tidak menyelesaikan masalah, tetapi justru memindahkan masalah ke lapisan yang lebih tinggi dalam tumpukan.
Optimistic Rollup
Saat ini, sebagian besar Optimistic rollup bersifat terpusat, yang memiliki masalah seperti kurangnya keamanan, terisolasi satu sama lain, dan latensi tinggi (harus 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 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 dari 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 semakin meningkatkan biaya dan biaya pengguna.
Kesimpulan
Akhir dari skalabilitas seharusnya bukan kompromi.
Dibandingkan dengan blockchain publik lainnya, Polkadot tidak memilih jalan untuk mengorbankan desentralisasi demi kinerja, atau mengorbankan efisiensi demi kepercayaan yang telah ditentukan sebelumnya. Sebaliknya, Polkadot mencapai keseimbangan multidimensional antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang elastis dan tanpa izin, lapisan keamanan yang terintegrasi, dan mekanisme manajemen sumber daya yang fleksibel.
Dalam mengejar penerapan yang lebih besar saat ini, "ekspansi 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.
19 Suka
Hadiah
19
5
Bagikan
Komentar
0/400
NFT_Therapy
· 07-16 00:58
Selamat datang kembali, fren saya dot!
Lihat AsliBalas0
LayerZeroHero
· 07-14 19:38
Faktanya ada trade-off yang pasti, dan perlu menjalankan benchmark untuk memverifikasinya...
Lihat AsliBalas0
BearMarketBuyer
· 07-14 19:17
dot sangat wangi.. sudah tiga tahun menjadi pemegang lama
Lihat AsliBalas0
WalletAnxietyPatient
· 07-14 19:16
Sudah berinvestasi terlalu awal dan mati terlalu awal.
Arsitektur Web3 Polkadot: Keseimbangan Sempurna antara Skalabilitas dan Keamanan
Pertimbangan antara Skalabilitas dan Keamanan: Desain Arsitektur Web3 Polkadot
Di era di mana teknologi blockchain terus mengejar efisiensi yang lebih tinggi, sebuah pertanyaan kunci perlahan muncul: bagaimana cara meningkatkan performa tanpa mengorbankan keamanan dan ketahanan sistem? Ini bukan hanya tantangan di tingkat teknologi, tetapi juga melibatkan pertimbangan mendalam dalam desain arsitektur. Bagi ekosistem Web3, sebuah sistem yang cepat jika harus mengorbankan kepercayaan dan keamanan, sering kali sulit untuk mendukung inovasi yang benar-benar berkelanjutan.
Sebagai pendorong penting untuk skalabilitas Web3, apakah Polkadot telah membuat beberapa kompromi dalam mengejar throughput tinggi dan latensi rendah? Apakah model rollup-nya telah membuat pengorbanan dalam desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan membahas isu-isu ini, menganalisis dengan mendalam kompromi dan pertimbangan yang dilakukan Polkadot dalam desain skalabilitasnya, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, serta mengeksplorasi pilihan mereka yang berbeda antara kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara fleksibilitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan relai rantai, apakah ini mungkin memperkenalkan risiko sentralisasi dalam beberapa aspek? Apakah mungkin terbentuk titik kegagalan tunggal atau kontrol, yang dapat mempengaruhi karakteristik desentralisasinya?
Operasi Rollup bergantung pada penyortir yang terhubung ke rantai penghubung, dan komunikasi ini menggunakan mekanisme protokol kolator. 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 diverifikasi oleh salah satu core rantai penghubung, dengan satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tersebut tidak akan maju.
pertimbangan untuk memperluas secara 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 dijalankan pada satu core tertentu, hal ini dapat mempengaruhi elastisitasnya.
Karena protokol untuk mengirimkan blok ke rantai penghubung adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirimkan blok untuk diverifikasi pada inti mana pun yang dialokasikan untuk rollup. Penyerang mungkin memanfaatkan ini dengan mengirimkan kembali blok sah yang sebelumnya telah diverifikasi ke inti 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 relai tanpa mempengaruhi karakteristik kunci sistem.
Masalah Kepercayaan Sequencer
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 filosofi desain Polkadot, kita tidak dapat membuat asumsi kepercayaan terhadap sequencer, karena harus menjaga 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 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, sehingga 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 melaksanakan kembali proses transisi status rollup dalam alur ketersediaan, dan memastikan keakuratan alokasi core melalui protokol ekonomi kriptografi ELVES.
Sebelum menulis data dari rollup block ke lapisan ketersediaan data Polkadot, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat dan bukti keabsahan yang diajukan oleh penyorter, yang berisi rollup block dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi paralel chain dan dijalankan ulang oleh validator di relay chain.
Hasil verifikasi mencakup pemilih inti (core selector) yang digunakan untuk menentukan pada inti mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut dengan inti 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 perilaku jahat seperti pengendapan yang dapat memanipulasi posisi verifikasi, memastikan bahwa bahkan jika rollup menggunakan beberapa core, itu tetap dapat mempertahankan elastisitas.
Keamanan
Dalam upaya mencapai skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai relai, hanya membutuhkan satu pengurut jujur untuk menjaga kelangsungan.
Dengan bantuan protokol ELVES, Polkadot memperluas keamanan secara keseluruhan 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 sebenarnya tanpa mengorbankan keamanan.
Universalitas
Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung eksekusi komputasi Turing-complete dalam lingkungan WebAssembly, asalkan setiap eksekusi 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 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:
Meskipun cara otomatisasi lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.
Interoperabilitas
Polkadot mendukung interoperabilitas antar rollup yang berbeda, sementara elastisitas skala tidak mempengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diimplementasikan oleh lapisan transmisi dasar, ruang blok komunikasi setiap rollup adalah tetap, tidak terkait dengan jumlah inti yang dialokasikan.
Di masa depan, Polkadot juga akan mendukung pengiriman pesan di luar rantai, dengan rantai penghubung sebagai lapisan kontrol, bukan lapisan data. Peningkatan ini akan meningkatkan kemampuan komunikasi antara rollup seiring dengan peningkatan elastisitas, lebih lanjut memperkuat kemampuan skalabilitas vertikal sistem.
Pertimbangan Protokol Lain
Seperti yang diketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, melihat dari 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 menggunakan arsitektur throughput tinggi lapisan tunggal untuk mencapai skalabilitas, bergantung pada bukti sejarah, pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoritis mencapai 65.000.
Salah satu desain kunci adalah mekanisme penjadwalan pemimpin yang telah dipublikasikan sebelumnya dan dapat diverifikasi:
Sejarah membuktikan bahwa pemrosesan paralel memiliki tuntutan tinggi terhadap perangkat keras, yang menyebabkan sentralisasi node verifikasi. Semakin banyak node yang dipertaruhkan, semakin besar kesempatan untuk menghasilkan blok, sementara 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 mencapai 172.
TON
TON mengklaim TPS dapat mencapai 104.715, tetapi angka ini dicapai di jaringan pengujian privat, dengan 256 node, dan dalam kondisi jaringan dan perangkat keras yang ideal. Sementara itu, Polkadot telah mencapai 128K TPS di jaringan publik yang terdesentralisasi.
Mekanisme konsensus TON memiliki risiko keamanan: identitas node verifikasi shard akan terungkap sebelumnya. Buku putih TON juga dengan jelas menyatakan bahwa meskipun ini dapat mengoptimalkan bandwidth, namun 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 dapat memanipulasi status.
Sebagai perbandingan, validator Polkadot dialokasikan 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 atas taruhan.
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 sekitar ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban shard tunggal untuk mencapai skala. Namun, Avalanche memungkinkan validator untuk memilih dengan bebas untuk berpartisipasi dalam subnet, dan subnet dapat menetapkan persyaratan tambahan seperti geografis, KYC, dan lain-lain, mengorbankan desentralisasi dan keamanan.
Di Polkadot, semua rollup berbagi jaminan keamanan yang terpusat; sementara subnet Avalanche tidak memiliki jaminan keamanan secara default, beberapa bahkan bisa sepenuhnya terpusat. Jika ingin meningkatkan keamanan, masih harus mengorbankan performa, dan sulit untuk memberikan jaminan keamanan yang pasti.
Ethereum
Strategi skalabilitas Ethereum adalah bertaruh pada skalabilitas lapisan rollup, alih-alih menyelesaikan masalah langsung di lapisan dasar. Cara ini pada dasarnya tidak menyelesaikan masalah, tetapi justru memindahkan masalah ke lapisan yang lebih tinggi dalam tumpukan.
Optimistic Rollup
Saat ini, sebagian besar Optimistic rollup bersifat terpusat, yang memiliki masalah seperti kurangnya keamanan, terisolasi satu sama lain, dan latensi tinggi (harus 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 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 dari 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 semakin meningkatkan biaya dan biaya pengguna.
Kesimpulan
Akhir dari skalabilitas seharusnya bukan kompromi.
Dibandingkan dengan blockchain publik lainnya, Polkadot tidak memilih jalan untuk mengorbankan desentralisasi demi kinerja, atau mengorbankan efisiensi demi kepercayaan yang telah ditentukan sebelumnya. Sebaliknya, Polkadot mencapai keseimbangan multidimensional antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang elastis dan tanpa izin, lapisan keamanan yang terintegrasi, dan mekanisme manajemen sumber daya yang fleksibel.
Dalam mengejar penerapan yang lebih besar saat ini, "ekspansi tanpa kepercayaan" yang dipegang oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung perkembangan jangka panjang Web3.