- Topik
88k Popularitas
42k Popularitas
14k Popularitas
4k Popularitas
5k Popularitas
29k Popularitas
16k Popularitas
22k Popularitas
13k Popularitas
3k Popularitas
- Sematkan
88k Popularitas
42k Popularitas
14k Popularitas
4k Popularitas
5k Popularitas
29k Popularitas
16k Popularitas
22k Popularitas
13k Popularitas
3k Popularitas
Pilihan Polkadot dan Ekspansi Web3: Keamanan dan Desentralisasi Tanpa Kompromi
Pilihan Ekspansif: Pertimbangan antara Polkadot dan Web3
Di era blockchain yang terus mengejar efisiensi yang lebih tinggi, sebuah masalah kunci mulai muncul: bagaimana cara meningkatkan kinerja sekaligus tidak mengorbankan keamanan dan ketahanan sistem? Ini bukan hanya tantangan di tingkat teknologi, tetapi juga keputusan mendalam dalam desain arsitektur. Bagi ekosistem Web3, sebuah sistem yang lebih cepat jika dibangun di atas pengorbanan kepercayaan dan keamanan, sering kali sulit untuk mendukung inovasi yang benar-benar berkelanjutan.
Sebagai pendorong penting untuk skalabilitas Web3, apakah Polkadot juga telah membuat 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 pertanyaan-pertanyaan ini, menganalisis secara mendalam kompromi dan pertimbangan dalam desain skalabilitas Polkadot, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, untuk mengeksplorasi pilihan jalur yang berbeda di antara kinerja, keamanan, dan desentralisasi.
Tantangan dalam Desain Ekspansi Polkadot
Keseimbangan antara Elastisitas dan Desentralisasi
Arsitektur Polkadot bergantung pada jaringan validator dan rantai relai terpusat, 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 terhubung, di mana komunikasinya menggunakan mekanisme protokol collator. Protokol ini sepenuhnya tanpa izin dan tanpa kepercayaan, siapa pun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node rantai penghubung, dan mengajukan permintaan untuk 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 tidak akan diperbarui.
pertimbangan ekspansi vertikal
Rollup dapat mencapai skalabilitas vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "skala elastis". Selama proses desain, ditemukan bahwa karena validasi blok rollup tidak tetap dijalankan pada satu core, ini dapat mempengaruhi elastisitasnya.
Karena protokol untuk mengirimkan blok ke blockchain perantara bersifat tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirimkan blok untuk diverifikasi di salah satu core yang dialokasikan untuk rollup. Penyerang mungkin memanfaatkan hal ini dengan mengirimkan kembali blok sah yang sebelumnya telah diverifikasi ke core yang berbeda, secara jahat menghabiskan sumber daya, sehingga menurunkan 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, menggunakan mekanisme daftar putih, atau secara default mempercayai penyortir yang tidak berperilaku jahat, sehingga menjaga aktifnya rollup.
Namun, dalam filosofi desain Polkadot, kita tidak dapat membuat asumsi kepercayaan terhadap sequencer, karena harus mempertahankan sifat "tanpa kepercayaan" dan "tanpa izin" dari sistem. Siapa pun harus 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 transisi status rollup (Runtime). Runtime adalah satu-satunya sumber informasi konsensus yang dapat dipercaya, sehingga harus dinyatakan secara jelas dalam output di mana verifikasi harus dilakukan di core Polkadot mana.
Desain ini memberikan jaminan ganda antara fleksibilitas dan keamanan. Polkadot akan melakukan eksekusi ulang status rollup dalam proses ketersediaan, dan memastikan keakuratan alokasi core melalui protokol ekonomi terenkripsi ELVES.
Sebelum menulis data yang tersedia di layer Polkadot dari setiap blok rollup, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahan data tersebut. Mereka menerima tanda terima kandidat dan bukti validitas yang diajukan oleh penyortir, yang berisi blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi paralel chain dan akan 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 apakah sesuai dengan inti yang mereka tanggung; jika tidak sesuai, blok tersebut akan dibuang.
Mekanisme ini memastikan bahwa sistem selalu mempertahankan atribut tanpa perlu mempercayai dan tanpa izin, menghindari manipulasi posisi verifikasi oleh pelaku jahat seperti sorter, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, ia dapat tetap elastis.
Keamanan
Dalam mengejar skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai relai, hanya membutuhkan satu penyortir yang jujur untuk mempertahankan keberlangsungan.
Dengan bantuan protokol ELVES, Polkadot memperluas keamanan secara lengkap 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 sejati tanpa mengorbankan keamanan.
Universalitas
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, jumlah total perhitungan yang dapat dilakukan dalam periode 6 detik meningkat, tetapi jenis perhitungan tidak terpengaruh.
kompleksitas
Throughput yang lebih tinggi dan latensi yang lebih rendah secara tidak 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 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 on-chain atau off-chain. Misalnya:
Meskipun cara otomatis lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.
Interoperabilitas
Polkadot mendukung interoperabilitas antara rollup yang berbeda, dan skalabilitas elastis tidak akan memengaruhi throughput pengiriman pesan.
Komunikasi pesan antar rollup diimplementasikan oleh lapisan transmisi dasar, ruang blok komunikasi setiap rollup adalah tetap, tidak tergantung pada jumlah inti yang dialokasikan.
Di masa depan, Polkadot juga akan mendukung pengiriman pesan off-chain, dengan rantai relai sebagai lapisan kontrol, bukan lapisan data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan perluasan elastis, semakin meningkatkan kemampuan pengembangan vertikal sistem.
Pertimbangan 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 lapisan tunggal berkecepatan tinggi, 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 diumumkan sebelumnya dan dapat diverifikasi:
PoH dan pemrosesan paralel memiliki tuntutan perangkat keras yang sangat tinggi, menyebabkan sentralisasi node validasi. Semakin banyak node yang dipertaruhkan, semakin besar peluang mereka untuk menghasilkan blok, sementara node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan juga meningkatkan risiko sistem terhenti 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, dan dalam kondisi jaringan serta perangkat keras yang ideal. Sementara itu, Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.
Mekanisme konsensus TON memiliki celah keamanan: identitas node verifikasi shard akan terungkap sebelumnya. Buku putih TON juga secara tegas menyatakan, meskipun ini dapat mengoptimalkan bandwidth, tetapi juga dapat disalahgunakan oleh pihak jahat. Karena kurangnya mekanisme "kebangkrutan penjudi", penyerang dapat menunggu shard tertentu sepenuhnya berada di bawah kendalinya, atau melalui serangan DDoS menghalangi validator yang jujur, sehingga dapat memanipulasi status.
Sebagai perbandingan, validator Polkadot ditugaskan secara acak dan pengungkapannya ditunda, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Serangan harus mempertaruhkan seluruh kontrol untuk berhasil; selama ada satu validator yang jujur yang mengajukan keberatan, serangan akan gagal dan menyebabkan penyerang kehilangan staking.
Avalanche
Avalanche menggunakan arsitektur mainnet + subnet untuk skala, mainnet terdiri dari X-Chain( transfer, ~4.500 TPS), C-Chain( kontrak pintar, ~100-200 TPS), dan P-Chain( untuk mengelola validator dan subnet).
Setiap subnet dapat mencapai TPS teoritis ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban shard tunggal untuk mencapai skalabilitas. Namun, Avalanche memungkinkan validator untuk bebas memilih 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 terintegrasi; sementara subnet Avalanche tidak memiliki jaminan keamanan secara default, beberapa bahkan dapat sepenuhnya terpusat. Jika ingin meningkatkan keamanan, tetap perlu berkompromi pada kinerja, dan sulit untuk memberikan jaminan 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 mengakibatkan masalah seperti kurangnya keamanan, terisolasi satu sama lain, dan keterlambatan tinggi ( yang perlu menunggu periode bukti penipuan, biasanya beberapa hari ).
ZK Rollup
Implementasi ZK rollup terbatas oleh jumlah data yang dapat diproses dalam satu transaksi. Permintaan komputasi untuk menghasilkan bukti tanpa 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 lengkap Turing kira-kira 2x10^6 kali lipat dari protokol keamanan ekonomi kripto inti Polkadot.
Selain itu, masalah ketersediaan data ZK rollup juga akan memperburuk kelemahannya. Untuk memastikan bahwa 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.
Penutup
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 ditentukan untuk efisiensi, melainkan melalui desain protokol yang fleksibel, tanpa izin, lapisan keamanan yang terintegrasi, dan mekanisme manajemen sumber daya yang fleksibel, mencapai keseimbangan multidimensi antara keamanan, desentralisasi, dan kinerja tinggi.
Dalam mengejar penerapan skala yang lebih besar saat ini, "ekstensi tanpa kepercayaan" yang dipegang oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung pengembangan jangka panjang Web3.