Trade-off Skalabilitas: Tantangan Polkadot dan Web3
Di era blockchain yang mengejar efisiensi lebih tinggi saat ini, sebuah pertanyaan kunci secara bertahap muncul: bagaimana cara meningkatkan kinerja tanpa mengorbankan keamanan dan ketahanan sistem? Ini bukan hanya tantangan di tingkat teknis, tetapi juga keputusan 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 juga telah mengorbankan beberapa hal demi mencapai tujuan throughput tinggi dan latensi rendah? Apakah model rollup-nya telah membuat pengorbanan dalam hal desentralisasi, keamanan, atau interoperabilitas jaringan?
Artikel ini akan membahas pertanyaan-pertanyaan ini, menganalisis secara mendalam kompromi dan pertimbangan dalam desain skalabilitas Polkadot, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, menjelajahi berbagai pilihan jalur mereka antara kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara fleksibilitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan 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 penyortir dari rantai penghubung, yang komunikasinya 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 dari rantai penghubung, dengan satu syarat: harus merupakan perubahan status yang valid, jika tidak, status Rollup tersebut tidak akan diperbarui.
trade-off untuk ekspansi vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "skala fleksibel". Selama proses desain, ditemukan bahwa karena validasi blok rollup tidak tetap dijalankan pada satu core tertentu, ini dapat mempengaruhi fleksibilitasnya.
Karena protokol untuk mengirimkan blok ke rantai penghubung adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirimkan blok untuk diverifikasi di core mana pun yang dialokasikan untuk rollup. Penyerang dapat memanfaatkan hal ini dengan mengirimkan blok legal yang telah diverifikasi sebelumnya berulang kali ke core yang berbeda, dengan niat jahat untuk 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 dengan menggunakan mekanisme daftar putih, atau default mempercayai pengurut tidak akan berperilaku jahat, sehingga menjamin aktivitas rollup.
Namun, dalam 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 Tanpa Kompromi
Solusi akhir yang dipilih oleh Polkadot adalah: menyerahkan masalah sepenuhnya kepada fungsi konversi status rollup (Runtime). Runtime adalah satu-satunya sumber terpercaya untuk semua informasi konsensus, sehingga harus secara jelas menyatakan di mana verifikasi harus dilakukan pada inti Polkadot mana.
Desain ini mencapai perlindungan ganda antara elastisitas dan keamanan. Polkadot akan mengeksekusi ulang status rollup dalam proses ketersediaan dan memastikan keakuratan distribusi core melalui protokol ekonomi kriptografi ELVES.
Sebelum menulis lapisan ketersediaan data Polkadot pada blok rollup mana pun, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat dan bukti kevalidan yang diajukan oleh pengurut, yang berisi blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi paralel, yang akan dieksekusi ulang oleh validator di rantai relai.
Hasil verifikasi mencakup satu 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 manipulasi posisi verifikasi oleh aktor jahat seperti sorter, serta memastikan bahwa bahkan jika rollup menggunakan beberapa core, tetap dapat mempertahankan elastisitas.
Keamanan
Dalam upaya mencapai skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai relai, hanya membutuhkan satu penyortir yang jujur untuk mempertahankan kelangsungan hidup.
Dengan bantuan protokol ELVES, Polkadot sepenuhnya memperluas keamanannya ke semua rollup, memverifikasi semua perhitungan di core tanpa membatasi atau membuat asumsi tentang jumlah inti yang digunakan.
Oleh karena itu, rollup Polkadot dapat mencapai skalabilitas nyata tanpa mengorbankan keamanan.
Kegunaan Umum
Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung eksekusi perhitungan Turing lengkap dalam lingkungan WebAssembly, asalkan eksekusi tunggal selesai dalam waktu 2 detik. Dengan bantuan ekspansi elastis, total jumlah perhitungan yang dapat dieksekusi dalam setiap siklus 6 detik meningkat, tetapi jenis perhitungan tidak terpengaruh.
kompleksitas
Throughput yang lebih tinggi dan latensi yang lebih rendah secara tak terhindarkan memperkenalkan kompleksitas, 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 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 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 skala elastis tidak akan memengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diimplementasikan oleh lapisan transportasi bawah, ruang blok komunikasi untuk setiap rollup adalah tetap, tidak tergantung pada 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 antar rollup seiring dengan peningkatan elastisitas, lebih lanjut memperkuat kemampuan penskalaan vertikal sistem.
Apa saja kompromi yang dilakukan oleh protokol lain?
Seperti yang kita semua 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 shard Polkadot atau Ethereum, melainkan menerapkan skala dengan arsitektur lapisan tunggal yang memiliki throughput tinggi, bergantung pada bukti sejarah (PoH), pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoritis mencapai 65.000.
Satu desain kunci adalah mekanisme penjadwalan pemimpin yang dipublikasikan sebelumnya dan dapat diverifikasi:
Slot dialokasikan berdasarkan jumlah staking pada awal setiap epoch (sekitar dua hari atau 432.000 slot);
Semakin banyak staking, semakin banyak distribusi. Misalnya, validator yang melakukan staking 1% akan mendapatkan sekitar 1% peluang untuk memproduksi blok;
Semua penambang blok diumumkan sebelumnya, meningkatkan risiko jaringan terkena serangan DDoS terarah dan sering mengalami downtime.
PoH dan pemrosesan paralel memiliki persyaratan perangkat keras yang sangat tinggi, yang mengarah pada 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 juga meningkatkan risiko sistem menjadi lumpuh setelah diserang.
Solana牺牲去中心化和抗攻击能力 untuk mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh di bawah Polkadot yang memiliki 172.
TON
TON mengklaim dapat mencapai 104,715 TPS, tetapi angka ini dicapai dalam pengujian privat, dengan 256 node, serta dalam kondisi jaringan dan perangkat keras yang ideal. Sementara Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.
Mekanisme konsensus TON memiliki potensi risiko keamanan: identitas node verifikasi shard dapat terungkap sebelumnya. Buku putih TON juga secara jelas menyatakan bahwa, meskipun ini dapat mengoptimalkan bandwidth, tetapi juga dapat disalahgunakan. Karena kurangnya mekanisme "kepailitan penjudi", penyerang dapat menunggu sebuah shard sepenuhnya dikendalikan olehnya, atau melalui serangan DDoS menghentikan validator yang jujur, sehingga dapat memanipulasi status.
Sebaliknya, validator Polkadot ditugaskan secara acak dan diungkapkan secara tertunda, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Penyerang harus mempertaruhkan semua kendali untuk berhasil, dan selama ada satu validator yang jujur yang mengajukan sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang yang mempertaruhkan.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk 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 memiliki TPS teoritis mencapai ~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 geografis, KYC, dll., 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 komitmen keamanan yang deterministik.
Ethereum
Strategi skalabilitas Ethereum adalah dengan bertaruh pada skalabilitas lapisan rollup, alih-alih langsung menyelesaikan masalah di lapisan dasar. Pendekatan ini pada dasarnya tidak menyelesaikan masalah, tetapi malah meneruskan masalah ke lapisan di atas tumpukan.
Optimistic Rollup
Saat ini, sebagian besar Optimistic rollup bersifat terpusat (beberapa bahkan hanya memiliki satu sequencer), sehingga ada masalah kurangnya keamanan, terisolasi satu sama lain, dan latensi tinggi (harus menunggu periode bukti penipuan, biasanya beberapa hari).
ZK Rollup
Implementasi ZK rollup terbatasi oleh jumlah data yang dapat diproses per transaksi. Permintaan komputasi untuk menghasilkan bukti nol pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semua" mudah menyebabkan sentralisasi sistem. Untuk menjamin TPS, ZK rollup sering membatasi jumlah transaksi per batch, yang dapat menyebabkan kemacetan jaringan dan kenaikan gas saat permintaan tinggi, mempengaruhi pengalaman pengguna.
Jika dibandingkan, biaya ZK rollup yang Turing lengkap adalah sekitar 2x10^6 kali lipat dari protokol keamanan ekonomi kripto inti Polkadot.
Selain itu, masalah ketersediaan data ZK rollup juga akan memperburuk kekurangan tersebut. Untuk memastikan siapa pun dapat memverifikasi transaksi, data transaksi lengkap tetap harus disediakan. Ini biasanya bergantung pada solusi ketersediaan data tambahan, yang semakin meningkatkan biaya dan biaya pengguna.
Kesimpulan
Akhir dari skalabilitas seharusnya bukan kompromi.
Dibandingkan dengan blockchain publik lainnya, Polkadot tidak mengambil jalan untuk mengorbankan desentralisasi demi kinerja, atau mengorbankan kepercayaan yang telah ditetapkan untuk efisiensi. Sebaliknya, melalui desain protokol yang elastis dan tanpa izin, lapisan keamanan yang terintegrasi, serta mekanisme pengelolaan sumber daya yang fleksibel, Polkadot mencapai keseimbangan multidimensional antara keamanan, desentralisasi, dan kinerja tinggi.
Dalam mengejar penerapan skala yang lebih besar saat ini, "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.
13 Suka
Hadiah
13
10
Bagikan
Komentar
0/400
DuskSurfer
· 07-24 17:29
Infrastruktur yang baik harus didahulukan sebelum dapat melaju dengan cepat.
Lihat AsliBalas0
TokenRationEater
· 07-24 00:36
Belum cukup cepat, sudah 22 tahun.
Lihat AsliBalas0
LiquidityWhisperer
· 07-22 15:35
Apakah kecepatan dan keamanan tidak bisa didapatkan sekaligus?
Lihat AsliBalas0
DiamondHands
· 07-22 13:17
Kecepatan dan keamanan memang saling bertentangan, bukan?
Lihat AsliBalas0
GasGuru
· 07-21 22:12
Ada chain lain yang sedang melakukan teknik penyeimbangan.
Lihat AsliBalas0
TokenVelocity
· 07-21 22:10
Apakah Polkadot benar-benar stabil? Atau hanya dianggap bodoh
Lihat AsliBalas0
BearMarketSage
· 07-21 21:53
Ikan dan telapak beruang tidak bisa didapatkan sekaligus.
Lihat AsliBalas0
MidnightSeller
· 07-21 21:52
Mengorbankan keamanan demi kecepatan, hampir sama dengan menunggu di atap.
Lihat AsliBalas0
PermabullPete
· 07-21 21:48
Mengerti, tapi di mana titiknya?
Lihat AsliBalas0
MEVSandwichMaker
· 07-21 21:48
Biaya pengorbanan selalu harus dibayar, tinggal lihat siapa yang meledak lebih dulu.
Bagaimana Polkadot mewujudkan perluasan tanpa kepercayaan untuk memimpin masa depan Web3
Trade-off Skalabilitas: Tantangan Polkadot dan Web3
Di era blockchain yang mengejar efisiensi lebih tinggi saat ini, sebuah pertanyaan kunci secara bertahap muncul: bagaimana cara meningkatkan kinerja tanpa mengorbankan keamanan dan ketahanan sistem? Ini bukan hanya tantangan di tingkat teknis, tetapi juga keputusan 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 juga telah mengorbankan beberapa hal demi mencapai tujuan throughput tinggi dan latensi rendah? Apakah model rollup-nya telah membuat pengorbanan dalam hal desentralisasi, keamanan, atau interoperabilitas jaringan?
Artikel ini akan membahas pertanyaan-pertanyaan ini, menganalisis secara mendalam kompromi dan pertimbangan dalam desain skalabilitas Polkadot, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, menjelajahi berbagai pilihan jalur mereka antara kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara fleksibilitas dan desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan 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 penyortir dari rantai penghubung, yang komunikasinya 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 dari rantai penghubung, dengan satu syarat: harus merupakan perubahan status yang valid, jika tidak, status Rollup tersebut tidak akan diperbarui.
trade-off untuk ekspansi vertikal
Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "skala fleksibel". Selama proses desain, ditemukan bahwa karena validasi blok rollup tidak tetap dijalankan pada satu core tertentu, ini dapat mempengaruhi fleksibilitasnya.
Karena protokol untuk mengirimkan blok ke rantai penghubung adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirimkan blok untuk diverifikasi di core mana pun yang dialokasikan untuk rollup. Penyerang dapat memanfaatkan hal ini dengan mengirimkan blok legal yang telah diverifikasi sebelumnya berulang kali ke core yang berbeda, dengan niat jahat untuk 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 dengan menggunakan mekanisme daftar putih, atau default mempercayai pengurut tidak akan berperilaku jahat, sehingga menjamin aktivitas rollup.
Namun, dalam 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 Tanpa Kompromi
Solusi akhir yang dipilih oleh Polkadot adalah: menyerahkan masalah sepenuhnya kepada fungsi konversi status rollup (Runtime). Runtime adalah satu-satunya sumber terpercaya untuk semua informasi konsensus, sehingga harus secara jelas menyatakan di mana verifikasi harus dilakukan pada inti Polkadot mana.
Desain ini mencapai perlindungan ganda antara elastisitas dan keamanan. Polkadot akan mengeksekusi ulang status rollup dalam proses ketersediaan dan memastikan keakuratan distribusi core melalui protokol ekonomi kriptografi ELVES.
Sebelum menulis lapisan ketersediaan data Polkadot pada blok rollup mana pun, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima tanda terima kandidat dan bukti kevalidan yang diajukan oleh pengurut, yang berisi blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi paralel, yang akan dieksekusi ulang oleh validator di rantai relai.
Hasil verifikasi mencakup satu 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 manipulasi posisi verifikasi oleh aktor jahat seperti sorter, serta memastikan bahwa bahkan jika rollup menggunakan beberapa core, tetap dapat mempertahankan elastisitas.
Keamanan
Dalam upaya mencapai skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai relai, hanya membutuhkan satu penyortir yang jujur untuk mempertahankan kelangsungan hidup.
Dengan bantuan protokol ELVES, Polkadot sepenuhnya memperluas keamanannya ke semua rollup, memverifikasi semua perhitungan di core tanpa membatasi atau membuat asumsi tentang jumlah inti yang digunakan.
Oleh karena itu, rollup Polkadot dapat mencapai skalabilitas nyata tanpa mengorbankan keamanan.
Kegunaan Umum
Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung eksekusi perhitungan Turing lengkap dalam lingkungan WebAssembly, asalkan eksekusi tunggal selesai dalam waktu 2 detik. Dengan bantuan ekspansi elastis, total jumlah perhitungan yang dapat dieksekusi dalam setiap siklus 6 detik meningkat, tetapi jenis perhitungan tidak terpengaruh.
kompleksitas
Throughput yang lebih tinggi dan latensi yang lebih rendah secara tak terhindarkan memperkenalkan kompleksitas, 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 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 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 skala elastis tidak akan memengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diimplementasikan oleh lapisan transportasi bawah, ruang blok komunikasi untuk setiap rollup adalah tetap, tidak tergantung pada 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 antar rollup seiring dengan peningkatan elastisitas, lebih lanjut memperkuat kemampuan penskalaan vertikal sistem.
Apa saja kompromi yang dilakukan oleh protokol lain?
Seperti yang kita semua 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 shard Polkadot atau Ethereum, melainkan menerapkan skala dengan arsitektur lapisan tunggal yang memiliki throughput tinggi, bergantung pada bukti sejarah (PoH), pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoritis mencapai 65.000.
Satu desain kunci adalah mekanisme penjadwalan pemimpin yang dipublikasikan sebelumnya dan dapat diverifikasi:
Slot dialokasikan berdasarkan jumlah staking pada awal setiap epoch (sekitar dua hari atau 432.000 slot);
Semakin banyak staking, semakin banyak distribusi. Misalnya, validator yang melakukan staking 1% akan mendapatkan sekitar 1% peluang untuk memproduksi blok;
Semua penambang blok diumumkan sebelumnya, meningkatkan risiko jaringan terkena serangan DDoS terarah dan sering mengalami downtime.
PoH dan pemrosesan paralel memiliki persyaratan perangkat keras yang sangat tinggi, yang mengarah pada 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 juga meningkatkan risiko sistem menjadi lumpuh setelah diserang.
Solana牺牲去中心化和抗攻击能力 untuk mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh di bawah Polkadot yang memiliki 172.
TON
TON mengklaim dapat mencapai 104,715 TPS, tetapi angka ini dicapai dalam pengujian privat, dengan 256 node, serta dalam kondisi jaringan dan perangkat keras yang ideal. Sementara Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.
Mekanisme konsensus TON memiliki potensi risiko keamanan: identitas node verifikasi shard dapat terungkap sebelumnya. Buku putih TON juga secara jelas menyatakan bahwa, meskipun ini dapat mengoptimalkan bandwidth, tetapi juga dapat disalahgunakan. Karena kurangnya mekanisme "kepailitan penjudi", penyerang dapat menunggu sebuah shard sepenuhnya dikendalikan olehnya, atau melalui serangan DDoS menghentikan validator yang jujur, sehingga dapat memanipulasi status.
Sebaliknya, validator Polkadot ditugaskan secara acak dan diungkapkan secara tertunda, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Penyerang harus mempertaruhkan semua kendali untuk berhasil, dan selama ada satu validator yang jujur yang mengajukan sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang yang mempertaruhkan.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk 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 memiliki TPS teoritis mencapai ~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 geografis, KYC, dll., 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 komitmen keamanan yang deterministik.
Ethereum
Strategi skalabilitas Ethereum adalah dengan bertaruh pada skalabilitas lapisan rollup, alih-alih langsung menyelesaikan masalah di lapisan dasar. Pendekatan ini pada dasarnya tidak menyelesaikan masalah, tetapi malah meneruskan masalah ke lapisan di atas tumpukan.
Optimistic Rollup
Saat ini, sebagian besar Optimistic rollup bersifat terpusat (beberapa bahkan hanya memiliki satu sequencer), sehingga ada masalah kurangnya keamanan, terisolasi satu sama lain, dan latensi tinggi (harus menunggu periode bukti penipuan, biasanya beberapa hari).
ZK Rollup
Implementasi ZK rollup terbatasi oleh jumlah data yang dapat diproses per transaksi. Permintaan komputasi untuk menghasilkan bukti nol pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semua" mudah menyebabkan sentralisasi sistem. Untuk menjamin TPS, ZK rollup sering membatasi jumlah transaksi per batch, yang dapat menyebabkan kemacetan jaringan dan kenaikan gas saat permintaan tinggi, mempengaruhi pengalaman pengguna.
Jika dibandingkan, biaya ZK rollup yang Turing lengkap adalah sekitar 2x10^6 kali lipat dari protokol keamanan ekonomi kripto inti Polkadot.
Selain itu, masalah ketersediaan data ZK rollup juga akan memperburuk kekurangan tersebut. Untuk memastikan siapa pun dapat memverifikasi transaksi, data transaksi lengkap tetap harus disediakan. Ini biasanya bergantung pada solusi ketersediaan data tambahan, yang semakin meningkatkan biaya dan biaya pengguna.
Kesimpulan
Akhir dari skalabilitas seharusnya bukan kompromi.
Dibandingkan dengan blockchain publik lainnya, Polkadot tidak mengambil jalan untuk mengorbankan desentralisasi demi kinerja, atau mengorbankan kepercayaan yang telah ditetapkan untuk efisiensi. Sebaliknya, melalui desain protokol yang elastis dan tanpa izin, lapisan keamanan yang terintegrasi, serta mekanisme pengelolaan sumber daya yang fleksibel, Polkadot mencapai keseimbangan multidimensional antara keamanan, desentralisasi, dan kinerja tinggi.
Dalam mengejar penerapan skala yang lebih besar saat ini, "ekstensibilitas tanpa kepercayaan" yang dipegang oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung perkembangan jangka panjang Web3.