Skalabilitas dan Trade-off: Bagaimana Polkadot Mencari Keseimbangan dalam Ekosistem Web3
Di era di mana blockchain terus mengejar efisiensi yang lebih tinggi, sebuah masalah kunci secara bertahap muncul: bagaimana cara meningkatkan kinerja sambil menghindari pengorbanan keamanan dan elastisitas sistem? Ini bukan hanya tantangan di tingkat teknis, tetapi juga merupakan pilihan mendalam dalam desain arsitektur. Bagi ekosistem Web3, sebuah 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 telah melakukan beberapa pengorbanan dalam mencapai tujuan throughput tinggi dan latensi rendah? Apakah model rollup-nya telah mengorbankan desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan membahas pertanyaan-pertanyaan ini, menganalisis secara mendalam kompromi dan trade-off Polkadot dalam desain skalabilitas, serta membandingkannya dengan solusi blockchain publik utama lainnya, mengeksplorasi pilihan jalur yang berbeda antara kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara fleksibilitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan rantai relai terpusat, apakah ini mungkin memperkenalkan risiko sentralisasi dalam beberapa aspek? Apakah mungkin terbentuknya titik kegagalan atau kontrol tunggal yang dapat mempengaruhi karakteristik desentralisasinya?
Operasi Rollup bergantung pada penyortir yang menghubungkan rantai penghubung, dan 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 diverifikasi oleh salah satu core rantai penghubung, dengan satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tidak akan diproses.
pertimbangan perluasan vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "skala elastis". Selama proses desain, kami menemukan bahwa karena verifikasi blok rollup tidak tetap dieksekusi pada satu core tertentu, hal ini dapat mempengaruhi elastisitasnya.
Karena protokol untuk mengirimkan blok ke rantai perantara adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirimkan blok untuk diverifikasi di mana saja pada core yang dialokasikan untuk rollup. Penyerang mungkin memanfaatkan ini dengan mengirimkan kembali blok yang sah yang sebelumnya telah diverifikasi ke core yang berbeda, dengan niat jahat untuk menghabiskan sumber daya, sehingga mengurangi throughput dan efisiensi keseluruhan rollup.
Tujuan Polkadot adalah untuk mempertahankan elastisitas rollup dan pemanfaatan sumber daya rantai penghubung tanpa mengorbankan 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 yang tidak melakukan perilaku jahat, sehingga menjamin aktivitas rollup.
Namun, dalam filosofi desain Polkadot, kita tidak dapat membuat asumsi kepercayaan terhadap sequencer, karena untuk mempertahankan sifat "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 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, sehingga harus secara jelas menyatakan di mana verifikasi harus dilakukan pada inti Polkadot yang mana.
Desain ini mewujudkan jaminan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang terhadap transisi status rollup dalam proses ketersediaan, dan memastikan keakuratan distribusi core melalui protokol ekonomi kriptografi ELVES.
Sebelum data dari rollup block ditulis ke lapisan ketersediaan data (DA) Polkadot, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat dan bukti validitas yang diajukan oleh penyortir, yang mencakup block rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi parachain dan dieksekusi ulang oleh validator di relay chain.
Hasil verifikasi mencakup 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 cocok, blok tersebut akan dibuang.
Mekanisme ini memastikan sistem selalu mempertahankan sifat tanpa kepercayaan dan tanpa izin, menghindari perilaku jahat seperti pengendalian posisi verifikasi oleh penyortir, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, tetap dapat mempertahankan elastisitas.
Keamanan
Dalam mengejar skalabilitas, Polkadot tidak berkompromi pada keamanan. Keamanan rollup dijamin oleh rantai relai, hanya membutuhkan satu penyortir yang jujur untuk mempertahankan kelangsungan.
Dengan bantuan protokol ELVES, Polkadot memperluas keamanan secara menyeluruh ke semua rollup, memvalidasi semua perhitungan di atas core, tanpa perlu membatasi atau membuat asumsi tentang jumlah core yang digunakan.
Oleh karena itu, rollup Polkadot dapat mencapai skalabilitas sejati tanpa mengorbankan keamanan.
Universalitas
Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung pelaksanaan komputasi Turing lengkap dalam lingkungan WebAssembly, asalkan setiap eksekusi selesai dalam waktu 2 detik. Dengan ekspansi elastis, total jumlah komputasi yang dapat dijalankan dalam periode 6 detik meningkat, tetapi jenis komputasi tidak terpengaruh.
Kompleksitas
Throughput yang lebih tinggi dan latensi yang lebih rendah secara tak terhindarkan 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 harus 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 di luar rantai;
Strategi Ringan: Memantau beban transaksi tertentu di mempool node;
Strategi otomatis: Mengonfigurasi sumber daya dengan memanggil layanan coretime lebih awal melalui data historis dan antarmuka XCM.
Meskipun cara otomatisasi lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.
Interoperabilitas
Polkadot mendukung interoperabilitas antar rollup yang berbeda, dan elastisitas skala tidak akan mempengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diimplementasikan oleh lapisan transportasi yang mendasarinya, ruang blok komunikasi setiap rollup bersifat tetap, tidak tergantung pada jumlah inti yang dialokasikan.
Di masa depan, Polkadot juga akan mendukung pengiriman pesan di luar rantai, dengan rantai penghubung bertindak sebagai lapisan kontrol, bukan lapisan data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan perluasan elastis, yang selanjutnya memperkuat kemampuan ekspansi vertikal sistem.
Apa kompromi yang dilakukan 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 tidak memuaskan.
Solana
Solana tidak menggunakan arsitektur sharding Polkadot atau Ethereum, melainkan mencapai 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 akan dialokasikan berdasarkan jumlah staking;
Semakin banyak yang dipertaruhkan, semakin banyak yang akan dialokasikan. Misalnya, validator yang mempertaruhkan 1% akan mendapatkan sekitar 1% kesempatan untuk menghasilkan blok;
Semua penambang blok diumumkan sebelumnya, meningkatkan risiko jaringan menghadapi serangan DDoS terarah dan sering mengalami downtime.
PoH dan pemrosesan paralel memiliki tuntutan perangkat keras yang sangat tinggi, menyebabkan sentralisasi node validator. Semakin banyak node yang dipertaruhkan, semakin besar peluang mereka untuk menghasilkan blok, sementara node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan meningkatkan risiko sistem yang lumpuh setelah diserang.
Solana mengorbankan desentralisasi dan kemampuan tahan serangan demi mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh di bawah Polkadot yang memiliki 172.
TON
Sebuah proyek blockchain mengklaim TPS dapat mencapai 104.715, tetapi angka ini dicapai di jaringan pengujian pribadi, dengan 256 node, dalam kondisi jaringan dan perangkat keras yang ideal. Sementara Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.
Mekanisme konsensus proyek ini memiliki kerentanan keamanan: identitas node verifikasi shard akan terungkap sebelumnya. Buku putihnya juga secara jelas menyatakan bahwa ini dapat mengoptimalkan bandwidth, tetapi juga bisa disalahgunakan. Karena kurangnya mekanisme "kebangkrutan penjudi", penyerang dapat menunggu shard tertentu untuk sepenuhnya mereka kendalikan, atau menggunakan serangan DDoS untuk memblokir 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 semua kontrol untuk berhasil, dan selama ada satu validator yang jujur yang mengajukan sengketa, serangan akan gagal dan menyebabkan penyerang kehilangan taruhan.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk melakukan skala, di mana mainnet terdiri dari X-Chain (transfer, ~4.500 TPS), C-Chain (kontrak pintar, ~100-200 TPS), dan P-Chain (pengelolaan validator dan subnet).
Setiap subnet secara teoritis dapat mencapai TPS ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban 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 lainnya, mengorbankan desentralisasi dan keamanan.
Di Polkadot, semua rollup berbagi jaminan keamanan yang terpusat; sementara subnet Avalanche tidak memiliki jaminan keamanan secara default, beberapa bahkan dapat sepenuhnya terpusat. Untuk meningkatkan keamanan, tetap perlu mengorbankan kinerja, dan sulit untuk memberikan komitmen keamanan yang pasti.
Ethereum
Strategi skala Ethereum adalah bertaruh pada skalabilitas lapisan rollup, bukannya menyelesaikan masalah di lapisan dasar secara langsung. Cara ini pada dasarnya tidak menyelesaikan masalah, melainkan mengalihkan 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 seperti kurangnya keamanan, isolasi satu sama lain, dan latensi tinggi (harus menunggu periode pembuktian penipuan, biasanya beberapa hari).
ZK Rollup
Implementasi ZK rollup dibatasi oleh jumlah data yang dapat diproses dalam satu 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 pada saat permintaan tinggi dapat menyebabkan kemacetan jaringan, kenaikan gas, dan mempengaruhi pengalaman pengguna.
Sebagai perbandingan, biaya ZK rollup yang Turing lengkap sekitar 2x10^6 kali lipat 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 telah ditetapkan demi efisiensi, melainkan mencapai keseimbangan multidimensi antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang fleksibel, tanpa izin, lapisan keamanan yang terintegrasi, dan mekanisme manajemen sumber daya yang fleksibel.
Dalam mengejar penerapan skala yang lebih besar saat ini, "ekstensibilitas tanpa kepercayaan" yang ditegaskan 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.
13 Suka
Hadiah
13
8
Bagikan
Komentar
0/400
MysteryBoxOpener
· 07-22 22:03
dot benar-benar mengalahkan blockchain publik lainnya
Lihat AsliBalas0
NotFinancialAdviser
· 07-22 21:00
Jangan berlebihan, dot juga hanya begitu saja.
Lihat AsliBalas0
LuckyBearDrawer
· 07-22 00:01
Gelombang DOT ini akan To da moon ya
Lihat AsliBalas0
P2ENotWorking
· 07-19 22:40
Apa gunanya cepat jika tidak bertahan hidup dulu?
Lihat AsliBalas0
BrokenDAO
· 07-19 22:39
Sekali lagi menggambarkan keseimbangan yang sempurna... Apakah kita masih ingat gelombang keruntuhan ekosistem di tahun 2021?
Lihat AsliBalas0
ser_we_are_early
· 07-19 22:39
Puncak! Artikel teknologi seperti ini, saya hanya peduli pada satu hal, naik atau tidak naik.
Lihat AsliBalas0
DevChive
· 07-19 22:32
dot adalah masa depan, siapa lagi yang menentang?
Lihat AsliBalas0
MagicBean
· 07-19 22:31
polka menunggu hasil, tidak bisa menahan diri untuk mengatakan masih pasti bisa To da moon
Jalan Perimbangan Polkadot: Skalabilitas Tanpa Kompromi dalam Ekosistem Web3
Skalabilitas dan Trade-off: Bagaimana Polkadot Mencari Keseimbangan dalam Ekosistem Web3
Di era di mana blockchain terus mengejar efisiensi yang lebih tinggi, sebuah masalah kunci secara bertahap muncul: bagaimana cara meningkatkan kinerja sambil menghindari pengorbanan keamanan dan elastisitas sistem? Ini bukan hanya tantangan di tingkat teknis, tetapi juga merupakan pilihan mendalam dalam desain arsitektur. Bagi ekosistem Web3, sebuah 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 telah melakukan beberapa pengorbanan dalam mencapai tujuan throughput tinggi dan latensi rendah? Apakah model rollup-nya telah mengorbankan desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan membahas pertanyaan-pertanyaan ini, menganalisis secara mendalam kompromi dan trade-off Polkadot dalam desain skalabilitas, serta membandingkannya dengan solusi blockchain publik utama lainnya, mengeksplorasi pilihan jalur yang berbeda antara kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara fleksibilitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan rantai relai terpusat, apakah ini mungkin memperkenalkan risiko sentralisasi dalam beberapa aspek? Apakah mungkin terbentuknya titik kegagalan atau kontrol tunggal yang dapat mempengaruhi karakteristik desentralisasinya?
Operasi Rollup bergantung pada penyortir yang menghubungkan rantai penghubung, dan 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 diverifikasi oleh salah satu core rantai penghubung, dengan satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tidak akan diproses.
pertimbangan perluasan vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "skala elastis". Selama proses desain, kami menemukan bahwa karena verifikasi blok rollup tidak tetap dieksekusi pada satu core tertentu, hal ini dapat mempengaruhi elastisitasnya.
Karena protokol untuk mengirimkan blok ke rantai perantara adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirimkan blok untuk diverifikasi di mana saja pada core yang dialokasikan untuk rollup. Penyerang mungkin memanfaatkan ini dengan mengirimkan kembali blok yang sah yang sebelumnya telah diverifikasi ke core yang berbeda, dengan niat jahat untuk menghabiskan sumber daya, sehingga mengurangi throughput dan efisiensi keseluruhan rollup.
Tujuan Polkadot adalah untuk mempertahankan elastisitas rollup dan pemanfaatan sumber daya rantai penghubung tanpa mengorbankan 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 yang tidak melakukan perilaku jahat, sehingga menjamin aktivitas rollup.
Namun, dalam filosofi desain Polkadot, kita tidak dapat membuat asumsi kepercayaan terhadap sequencer, karena untuk mempertahankan sifat "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 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, sehingga harus secara jelas menyatakan di mana verifikasi harus dilakukan pada inti Polkadot yang mana.
Desain ini mewujudkan jaminan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang terhadap transisi status rollup dalam proses ketersediaan, dan memastikan keakuratan distribusi core melalui protokol ekonomi kriptografi ELVES.
Sebelum data dari rollup block ditulis ke lapisan ketersediaan data (DA) Polkadot, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat dan bukti validitas yang diajukan oleh penyortir, yang mencakup block rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi parachain dan dieksekusi ulang oleh validator di relay chain.
Hasil verifikasi mencakup 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 cocok, blok tersebut akan dibuang.
Mekanisme ini memastikan sistem selalu mempertahankan sifat tanpa kepercayaan dan tanpa izin, menghindari perilaku jahat seperti pengendalian posisi verifikasi oleh penyortir, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, tetap dapat mempertahankan elastisitas.
Keamanan
Dalam mengejar skalabilitas, Polkadot tidak berkompromi pada keamanan. Keamanan rollup dijamin oleh rantai relai, hanya membutuhkan satu penyortir yang jujur untuk mempertahankan kelangsungan.
Dengan bantuan protokol ELVES, Polkadot memperluas keamanan secara menyeluruh ke semua rollup, memvalidasi semua perhitungan di atas core, tanpa perlu membatasi atau membuat asumsi tentang jumlah core yang digunakan.
Oleh karena itu, rollup Polkadot dapat mencapai skalabilitas sejati tanpa mengorbankan keamanan.
Universalitas
Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung pelaksanaan komputasi Turing lengkap dalam lingkungan WebAssembly, asalkan setiap eksekusi selesai dalam waktu 2 detik. Dengan ekspansi elastis, total jumlah komputasi yang dapat dijalankan dalam periode 6 detik meningkat, tetapi jenis komputasi tidak terpengaruh.
Kompleksitas
Throughput yang lebih tinggi dan latensi yang lebih rendah secara tak terhindarkan 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 harus 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 di luar rantai;
Strategi Ringan: Memantau beban transaksi tertentu di mempool node;
Strategi otomatis: Mengonfigurasi sumber daya dengan memanggil layanan coretime lebih awal melalui data historis dan antarmuka XCM.
Meskipun cara otomatisasi lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.
Interoperabilitas
Polkadot mendukung interoperabilitas antar rollup yang berbeda, dan elastisitas skala tidak akan mempengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diimplementasikan oleh lapisan transportasi yang mendasarinya, ruang blok komunikasi setiap rollup bersifat tetap, tidak tergantung pada jumlah inti yang dialokasikan.
Di masa depan, Polkadot juga akan mendukung pengiriman pesan di luar rantai, dengan rantai penghubung bertindak sebagai lapisan kontrol, bukan lapisan data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan perluasan elastis, yang selanjutnya memperkuat kemampuan ekspansi vertikal sistem.
Apa kompromi yang dilakukan 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 tidak memuaskan.
Solana
Solana tidak menggunakan arsitektur sharding Polkadot atau Ethereum, melainkan mencapai 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 akan dialokasikan berdasarkan jumlah staking;
Semakin banyak yang dipertaruhkan, semakin banyak yang akan dialokasikan. Misalnya, validator yang mempertaruhkan 1% akan mendapatkan sekitar 1% kesempatan untuk menghasilkan blok;
Semua penambang blok diumumkan sebelumnya, meningkatkan risiko jaringan menghadapi serangan DDoS terarah dan sering mengalami downtime.
PoH dan pemrosesan paralel memiliki tuntutan perangkat keras yang sangat tinggi, menyebabkan sentralisasi node validator. Semakin banyak node yang dipertaruhkan, semakin besar peluang mereka untuk menghasilkan blok, sementara node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan meningkatkan risiko sistem yang lumpuh setelah diserang.
Solana mengorbankan desentralisasi dan kemampuan tahan serangan demi mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh di bawah Polkadot yang memiliki 172.
TON
Sebuah proyek blockchain mengklaim TPS dapat mencapai 104.715, tetapi angka ini dicapai di jaringan pengujian pribadi, dengan 256 node, dalam kondisi jaringan dan perangkat keras yang ideal. Sementara Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.
Mekanisme konsensus proyek ini memiliki kerentanan keamanan: identitas node verifikasi shard akan terungkap sebelumnya. Buku putihnya juga secara jelas menyatakan bahwa ini dapat mengoptimalkan bandwidth, tetapi juga bisa disalahgunakan. Karena kurangnya mekanisme "kebangkrutan penjudi", penyerang dapat menunggu shard tertentu untuk sepenuhnya mereka kendalikan, atau menggunakan serangan DDoS untuk memblokir 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 semua kontrol untuk berhasil, dan selama ada satu validator yang jujur yang mengajukan sengketa, serangan akan gagal dan menyebabkan penyerang kehilangan taruhan.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk melakukan skala, di mana mainnet terdiri dari X-Chain (transfer, ~4.500 TPS), C-Chain (kontrak pintar, ~100-200 TPS), dan P-Chain (pengelolaan validator dan subnet).
Setiap subnet secara teoritis dapat mencapai TPS ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban 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 lainnya, mengorbankan desentralisasi dan keamanan.
Di Polkadot, semua rollup berbagi jaminan keamanan yang terpusat; sementara subnet Avalanche tidak memiliki jaminan keamanan secara default, beberapa bahkan dapat sepenuhnya terpusat. Untuk meningkatkan keamanan, tetap perlu mengorbankan kinerja, dan sulit untuk memberikan komitmen keamanan yang pasti.
Ethereum
Strategi skala Ethereum adalah bertaruh pada skalabilitas lapisan rollup, bukannya menyelesaikan masalah di lapisan dasar secara langsung. Cara ini pada dasarnya tidak menyelesaikan masalah, melainkan mengalihkan 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 seperti kurangnya keamanan, isolasi satu sama lain, dan latensi tinggi (harus menunggu periode pembuktian penipuan, biasanya beberapa hari).
ZK Rollup
Implementasi ZK rollup dibatasi oleh jumlah data yang dapat diproses dalam satu 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 pada saat permintaan tinggi dapat menyebabkan kemacetan jaringan, kenaikan gas, dan mempengaruhi pengalaman pengguna.
Sebagai perbandingan, biaya ZK rollup yang Turing lengkap sekitar 2x10^6 kali lipat 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 telah ditetapkan demi efisiensi, melainkan mencapai keseimbangan multidimensi antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang fleksibel, tanpa izin, lapisan keamanan yang terintegrasi, dan mekanisme manajemen sumber daya yang fleksibel.
Dalam mengejar penerapan skala yang lebih besar saat ini, "ekstensibilitas tanpa kepercayaan" yang ditegaskan oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung perkembangan jangka panjang Web3.