Perimbangan Skalabilitas Blockchain: Eksplorasi Polkadot dan Ekosistem Web3
Dalam dunia Blockchain yang terus mengejar efisiensi yang lebih tinggi, sebuah masalah kunci secara bertahap muncul: bagaimana cara meningkatkan kinerja tanpa mengorbankan keamanan dan ketahanan sistem?
Ini bukan hanya tantangan di tingkat teknologi, tetapi juga pilihan mendalam dalam desain arsitektur. Terutama untuk ekosistem Web3, sistem yang 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 melakukan pengorbanan tertentu dalam mencapai tujuan throughput tinggi dan latensi rendah? Apakah model rollup-nya telah mengorbankan desentralisasi, keamanan, atau interoperabilitas jaringan?
Artikel ini akan membahas masalah-masalah ini, menganalisis secara mendalam kompromi dan pertimbangan dalam desain skalabilitas Polkadot, dan membandingkannya dengan solusi blockchain utama lainnya, serta mengeksplorasi pilihan jalur yang berbeda antara kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara elastisitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan rantai penghubung (Relay Chain), 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 sequencer dari relay chain yang terhubung, yang komunikasinya menggunakan mekanisme yang disebut protokol collator. Protokol ini sepenuhnya tanpa izin dan tanpa kepercayaan, siapa pun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node relay chain, dan mengajukan permintaan perubahan status rollup. Permintaan ini akan diverifikasi oleh salah satu core dari relay chain, dengan hanya satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tersebut tidak akan maju.
Pertimbangan Ekspansi Vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "Elastic Scaling". Selama proses desain, kami menemukan bahwa karena verifikasi blok rollup tidak tetap dieksekusi pada satu core tertentu, ini dapat mempengaruhi elastisitasnya.
Karena protokol untuk mengirimkan blok ke rantai penghubung tidak memerlukan izin dan tidak memerlukan kepercayaan, siapa pun dapat mengirimkan blok untuk diverifikasi di salah satu core yang ditugaskan kepada rollup. Penyerang mungkin memanfaatkan ini dengan mengirimkan blok valid yang telah diverifikasi sebelumnya berulang kali ke core yang berbeda, secara jahat menghabiskan sumber daya, sehingga mengurangi throughput dan efisiensi keseluruhan dari 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 menggunakan mekanisme daftar putih, atau secara default mempercayai penyortir tidak akan berperilaku jahat, sehingga menjamin aktivitas 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 akhir yang dipilih oleh Polkadot adalah: sepenuhnya menyerahkan masalah kepada fungsi konversi 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 mengeksekusi kembali transisi status rollup dalam proses ketersediaan dan memastikan keakuratan alokasi core melalui protokol ekonomi kriptografi ELVES.
Sebelum data tersedia untuk rollup block ditulis ke lapisan ketersediaan data (DA) Polkadot, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat (candidate receipt) dan bukti validitas (PoV) yang diajukan oleh penyortir, yang berisi rollup block dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi parachain, dan dieksekusi ulang oleh validator di relay chain.
Hasil verifikasi mencakup pemilih inti (core selector) yang digunakan untuk menentukan di core mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut dengan core yang menjadi tanggung jawab mereka; jika tidak konsisten, blok tersebut akan dibuang.
Mekanisme ini memastikan sistem selalu mempertahankan sifat tanpa kepercayaan dan tanpa izin, menghindari perilaku jahat dari aktor seperti sorter yang dapat memanipulasi posisi verifikasi, memastikan bahwa bahkan jika rollup menggunakan beberapa core, ia tetap dapat mempertahankan elastisitas.
Keamanan
Dalam upaya mencapai skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai penghubung, hanya membutuhkan satu pengurut jujur untuk mempertahankan kelangsungan hidup.
Dengan bantuan protokol ELVES, Polkadot akan memperluas keamanan secara menyeluruh ke semua rollup, memvalidasi semua komputasi di semua inti, tanpa perlu membatasi atau mengasumsikan jumlah inti yang digunakan.
Oleh karena itu, rollup Polkadot dapat mencapai skalabilitas sejati tanpa mengorbankan keamanan.
Kegunaan Umum
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, total jumlah komputasi yang dapat dieksekusi dalam siklus 6 detik meningkat, tetapi jenis komputasi tidak terpengaruh.
Kompleksitas
Throughput yang lebih tinggi dan latensi yang lebih rendah secara tidak terelakkan memperkenalkan kompleksitas, 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 dari persyaratan RFC103 untuk menyesuaikan dengan berbagai skenario penggunaan.
Kompleksitas spesifik tergantung pada strategi manajemen sumber daya rollup, yang mungkin bergantung pada variabel di dalam atau di luar rantai. Contohnya:
Strategi sederhana: selalu gunakan jumlah tetap dari core, 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 metode otomatisasi lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.
Interoperabilitas
Polkadot mendukung interoperabilitas antar rollup yang berbeda, sementara skalabilitas elastis tidak mempengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diimplementasikan oleh lapisan pengiriman bawah, ruang blok komunikasi setiap rollup adalah tetap, tidak tergantung pada jumlah inti yang dialokasikan.
Di masa depan, Polkadot akan mendukung pengiriman pesan di luar rantai (off-chain messaging), dengan rantai penghubung sebagai lapisan kontrol, bukan lapisan data. Upgrade ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan peningkatan elastisitas, dan lebih lanjut memperkuat kemampuan skala vertikal sistem.
Apa kompromi yang dibuat oleh protokol lain?
Seperti yang kita ketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, dari sudut pandang koefisien Nakamoto, meskipun beberapa pesaing Polkadot memiliki tingkat desentralisasi yang lebih rendah, kinerja mereka juga tidak memuaskan.
Solana
Solana tidak menggunakan arsitektur sharding Polkadot atau Ethereum, melainkan mengimplementasikan skalabilitas dengan arsitektur throughput tinggi lapisan tunggal, bergantung pada 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 sebelumnya dan dapat diverifikasi:
Pada awal setiap epoch (sekitar dua hari atau 432.000 slot), slot dialokasikan berdasarkan jumlah staking;
Semakin banyak yang dipertaruhkan, semakin banyak yang didistribusikan. Misalnya, validator yang mempertaruhkan 1% akan mendapatkan sekitar 1% kesempatan untuk menghasilkan blok;
Semua pembuat blok diumumkan sebelumnya, meningkatkan risiko jaringan mengalami serangan DDoS terarah dan sering down.
PoH dan pemrosesan paralel memiliki tuntutan perangkat keras yang sangat tinggi, yang menyebabkan terpusatnya node verifikasi. Semakin banyak node yang dipertaruhkan, semakin besar peluang untuk menghasilkan blok, sementara node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan juga meningkatkan risiko sistem menjadi lumpuh setelah diserang.
Solana mengorbankan desentralisasi dan ketahanan terhadap serangan untuk mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh di bawah Polkadot yang memiliki 172.
TON
TON mengklaim TPS dapat mencapai 104,715, tetapi angka ini dicapai di jaringan pengujian privat, dengan 256 node, serta kondisi jaringan dan perangkat keras yang ideal. Sementara itu, Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.
Mekanisme konsensus TON memiliki risiko keamanan: identitas node verifikasi sharding akan terpapar sebelumnya. Whitepaper TON juga secara jelas menyatakan bahwa meskipun ini dapat mengoptimalkan bandwidth, namun juga dapat disalahgunakan. Karena kurangnya mekanisme "bangkrut penjudi", penyerang dapat menunggu shard tertentu sepenuhnya dikendalikan olehnya, atau dengan serangan DDoS menghalangi validator yang jujur, sehingga memanipulasi status.
Sebagai perbandingan, validator Polkadot ditugaskan secara acak dan diungkapkan dengan penundaan, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Serangan harus mempertaruhkan seluruh kontrol untuk berhasil, dan selama ada satu validator yang jujur yang mengajukan keberatan, serangan akan gagal dan menyebabkan kerugian bagi penyerang.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk skalabilitas, 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 memiliki TPS teoritis mencapai ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban shard tunggal untuk mencapai skalabilitas. Namun, Avalanche memungkinkan validator untuk memilih partisipasi 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 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, bukan menyelesaikan masalah di lapisan dasar secara langsung. Pendekatan 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 menyebabkan masalah keamanan yang tidak memadai, terisolasi satu sama lain, dan keterlambatan tinggi (harus menunggu periode bukti penipuan, biasanya beberapa hari).
ZK Rollup
Implementasi ZK rollup dibatasi oleh jumlah data yang dapat diproses per transaksi. Permintaan komputasi untuk menghasilkan bukti nol pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semuanya" cenderung menyebabkan sentralisasi sistem. Untuk memastikan TPS, ZK rollup sering membatasi jumlah 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 sekitar 2x10^6 kali dari protokol keamanan ekonomi kripto 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 untuk mengorbankan desentralisasi demi kinerja, atau mengorbankan kepercayaan yang ditetapkan demi efisiensi, tetapi telah mencapai keseimbangan multidimensi antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang fleksibel, tidak memerlukan izin, lapisan keamanan yang terintegrasi, dan mekanisme pengelolaan sumber daya yang fleksibel.
Dalam mengejar penerapan skala yang lebih besar saat ini, "skala nol 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.
14 Suka
Hadiah
14
5
Bagikan
Komentar
0/400
SignatureCollector
· 07-30 01:18
Titik rantai cepat naik cepat naik
Lihat AsliBalas0
ForumMiningMaster
· 07-30 01:15
Penghasilan 100 ribu per bulan hanya bergantung pada beberapa blockchain ini.
Lihat AsliBalas0
LostBetweenChains
· 07-30 01:12
Cukup dengan naikkan posisi BTC biasa.
Lihat AsliBalas0
BearMarketSunriser
· 07-30 01:12
Hanya dengan tps ini saja sudah berani membanggakan?
Polkadot Elastisitas Ekspansi: Jalan Kinerja Tinggi Web3 Tanpa Kompromi
Perimbangan Skalabilitas Blockchain: Eksplorasi Polkadot dan Ekosistem Web3
Dalam dunia Blockchain yang terus mengejar efisiensi yang lebih tinggi, sebuah masalah kunci secara bertahap muncul: bagaimana cara meningkatkan kinerja tanpa mengorbankan keamanan dan ketahanan sistem?
Ini bukan hanya tantangan di tingkat teknologi, tetapi juga pilihan mendalam dalam desain arsitektur. Terutama untuk ekosistem Web3, sistem yang 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 melakukan pengorbanan tertentu dalam mencapai tujuan throughput tinggi dan latensi rendah? Apakah model rollup-nya telah mengorbankan desentralisasi, keamanan, atau interoperabilitas jaringan?
Artikel ini akan membahas masalah-masalah ini, menganalisis secara mendalam kompromi dan pertimbangan dalam desain skalabilitas Polkadot, dan membandingkannya dengan solusi blockchain utama lainnya, serta mengeksplorasi pilihan jalur yang berbeda antara kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara elastisitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan rantai penghubung (Relay Chain), 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 sequencer dari relay chain yang terhubung, yang komunikasinya menggunakan mekanisme yang disebut protokol collator. Protokol ini sepenuhnya tanpa izin dan tanpa kepercayaan, siapa pun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node relay chain, dan mengajukan permintaan perubahan status rollup. Permintaan ini akan diverifikasi oleh salah satu core dari relay chain, dengan hanya satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tersebut tidak akan maju.
Pertimbangan Ekspansi Vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "Elastic Scaling". Selama proses desain, kami menemukan bahwa karena verifikasi blok rollup tidak tetap dieksekusi pada satu core tertentu, ini dapat mempengaruhi elastisitasnya.
Karena protokol untuk mengirimkan blok ke rantai penghubung tidak memerlukan izin dan tidak memerlukan kepercayaan, siapa pun dapat mengirimkan blok untuk diverifikasi di salah satu core yang ditugaskan kepada rollup. Penyerang mungkin memanfaatkan ini dengan mengirimkan blok valid yang telah diverifikasi sebelumnya berulang kali ke core yang berbeda, secara jahat menghabiskan sumber daya, sehingga mengurangi throughput dan efisiensi keseluruhan dari 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 menggunakan mekanisme daftar putih, atau secara default mempercayai penyortir tidak akan berperilaku jahat, sehingga menjamin aktivitas 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 akhir yang dipilih oleh Polkadot adalah: sepenuhnya menyerahkan masalah kepada fungsi konversi 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 mengeksekusi kembali transisi status rollup dalam proses ketersediaan dan memastikan keakuratan alokasi core melalui protokol ekonomi kriptografi ELVES.
Sebelum data tersedia untuk rollup block ditulis ke lapisan ketersediaan data (DA) Polkadot, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat (candidate receipt) dan bukti validitas (PoV) yang diajukan oleh penyortir, yang berisi rollup block dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi parachain, dan dieksekusi ulang oleh validator di relay chain.
Hasil verifikasi mencakup pemilih inti (core selector) yang digunakan untuk menentukan di core mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut dengan core yang menjadi tanggung jawab mereka; jika tidak konsisten, blok tersebut akan dibuang.
Mekanisme ini memastikan sistem selalu mempertahankan sifat tanpa kepercayaan dan tanpa izin, menghindari perilaku jahat dari aktor seperti sorter yang dapat memanipulasi posisi verifikasi, memastikan bahwa bahkan jika rollup menggunakan beberapa core, ia tetap dapat mempertahankan elastisitas.
Keamanan
Dalam upaya mencapai skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai penghubung, hanya membutuhkan satu pengurut jujur untuk mempertahankan kelangsungan hidup.
Dengan bantuan protokol ELVES, Polkadot akan memperluas keamanan secara menyeluruh ke semua rollup, memvalidasi semua komputasi di semua inti, tanpa perlu membatasi atau mengasumsikan jumlah inti yang digunakan.
Oleh karena itu, rollup Polkadot dapat mencapai skalabilitas sejati tanpa mengorbankan keamanan.
Kegunaan Umum
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, total jumlah komputasi yang dapat dieksekusi dalam siklus 6 detik meningkat, tetapi jenis komputasi tidak terpengaruh.
Kompleksitas
Throughput yang lebih tinggi dan latensi yang lebih rendah secara tidak terelakkan memperkenalkan kompleksitas, 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 dari persyaratan RFC103 untuk menyesuaikan dengan berbagai skenario penggunaan.
Kompleksitas spesifik tergantung pada strategi manajemen sumber daya rollup, yang mungkin bergantung pada variabel di dalam atau di luar rantai. Contohnya:
Strategi sederhana: selalu gunakan jumlah tetap dari core, 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 metode otomatisasi lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.
Interoperabilitas
Polkadot mendukung interoperabilitas antar rollup yang berbeda, sementara skalabilitas elastis tidak mempengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diimplementasikan oleh lapisan pengiriman bawah, ruang blok komunikasi setiap rollup adalah tetap, tidak tergantung pada jumlah inti yang dialokasikan.
Di masa depan, Polkadot akan mendukung pengiriman pesan di luar rantai (off-chain messaging), dengan rantai penghubung sebagai lapisan kontrol, bukan lapisan data. Upgrade ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan peningkatan elastisitas, dan lebih lanjut memperkuat kemampuan skala vertikal sistem.
Apa kompromi yang dibuat oleh protokol lain?
Seperti yang kita ketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, dari sudut pandang koefisien Nakamoto, meskipun beberapa pesaing Polkadot memiliki tingkat desentralisasi yang lebih rendah, kinerja mereka juga tidak memuaskan.
Solana
Solana tidak menggunakan arsitektur sharding Polkadot atau Ethereum, melainkan mengimplementasikan skalabilitas dengan arsitektur throughput tinggi lapisan tunggal, bergantung pada 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 sebelumnya dan dapat diverifikasi:
Pada awal setiap epoch (sekitar dua hari atau 432.000 slot), slot dialokasikan berdasarkan jumlah staking;
Semakin banyak yang dipertaruhkan, semakin banyak yang didistribusikan. Misalnya, validator yang mempertaruhkan 1% akan mendapatkan sekitar 1% kesempatan untuk menghasilkan blok;
Semua pembuat blok diumumkan sebelumnya, meningkatkan risiko jaringan mengalami serangan DDoS terarah dan sering down.
PoH dan pemrosesan paralel memiliki tuntutan perangkat keras yang sangat tinggi, yang menyebabkan terpusatnya node verifikasi. Semakin banyak node yang dipertaruhkan, semakin besar peluang untuk menghasilkan blok, sementara node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan juga meningkatkan risiko sistem menjadi lumpuh setelah diserang.
Solana mengorbankan desentralisasi dan ketahanan terhadap serangan untuk mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh di bawah Polkadot yang memiliki 172.
TON
TON mengklaim TPS dapat mencapai 104,715, tetapi angka ini dicapai di jaringan pengujian privat, dengan 256 node, serta kondisi jaringan dan perangkat keras yang ideal. Sementara itu, Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.
Mekanisme konsensus TON memiliki risiko keamanan: identitas node verifikasi sharding akan terpapar sebelumnya. Whitepaper TON juga secara jelas menyatakan bahwa meskipun ini dapat mengoptimalkan bandwidth, namun juga dapat disalahgunakan. Karena kurangnya mekanisme "bangkrut penjudi", penyerang dapat menunggu shard tertentu sepenuhnya dikendalikan olehnya, atau dengan serangan DDoS menghalangi validator yang jujur, sehingga memanipulasi status.
Sebagai perbandingan, validator Polkadot ditugaskan secara acak dan diungkapkan dengan penundaan, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Serangan harus mempertaruhkan seluruh kontrol untuk berhasil, dan selama ada satu validator yang jujur yang mengajukan keberatan, serangan akan gagal dan menyebabkan kerugian bagi penyerang.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk skalabilitas, 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 memiliki TPS teoritis mencapai ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban shard tunggal untuk mencapai skalabilitas. Namun, Avalanche memungkinkan validator untuk memilih partisipasi 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 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, bukan menyelesaikan masalah di lapisan dasar secara langsung. Pendekatan 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 menyebabkan masalah keamanan yang tidak memadai, terisolasi satu sama lain, dan keterlambatan tinggi (harus menunggu periode bukti penipuan, biasanya beberapa hari).
ZK Rollup
Implementasi ZK rollup dibatasi oleh jumlah data yang dapat diproses per transaksi. Permintaan komputasi untuk menghasilkan bukti nol pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semuanya" cenderung menyebabkan sentralisasi sistem. Untuk memastikan TPS, ZK rollup sering membatasi jumlah 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 sekitar 2x10^6 kali dari protokol keamanan ekonomi kripto 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 untuk mengorbankan desentralisasi demi kinerja, atau mengorbankan kepercayaan yang ditetapkan demi efisiensi, tetapi telah mencapai keseimbangan multidimensi antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang fleksibel, tidak memerlukan izin, lapisan keamanan yang terintegrasi, dan mekanisme pengelolaan sumber daya yang fleksibel.
Dalam mengejar penerapan skala yang lebih besar saat ini, "skala nol kepercayaan" yang dipegang oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung perkembangan jangka panjang Web3.