Perimbangan Skalabilitas Blockchain: Jalan Keseimbangan Polkadot dan Web3

Di era di mana Blockchain terus mengejar efisiensi yang lebih tinggi, sebuah pertanyaan kunci mulai muncul: Apakah harus mengorbankan keamanan dan elastisitas sistem sambil meningkatkan kinerja? Ini bukan hanya tantangan di tingkat teknis, tetapi juga pilihan mendalam dalam desain arsitektur. Bagi ekosistem Web3, sebuah sistem yang lebih cepat jika dibangun di atas pengorbanan kepercayaan dan keamanan seringkali sulit mendukung inovasi yang benar-benar berkelanjutan.

Polkadot sebagai pendorong penting untuk skalabilitas Web3, apakah model rollup-nya mengorbankan desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan menganalisis secara mendalam pengorbanan dan pertimbangan Polkadot dalam desain skalabilitasnya, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, untuk 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 Relay Chain (, apakah ini mungkin memperkenalkan risiko sentralisasi dalam beberapa aspek? Apakah mungkin terjadi titik kegagalan tunggal atau kontrol yang dapat mempengaruhi karakteristik desentralisasinya?

Operasi Rollup bergantung pada penyusun )sekuens ( yang menghubungkan rantai perantara, yang komunikasinya menggunakan mekanisme yang disebut protokol kolator. Protokol ini sepenuhnya tanpa izin, tanpa kepercayaan, siapa pun yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node rantai perantara, dan mengajukan permintaan perubahan status rollup. Permintaan ini akan diverifikasi oleh salah satu core rantai perantara, hanya perlu memenuhi satu syarat: harus merupakan perubahan status yang valid, jika tidak, status rollup tersebut tidak akan diperbarui.

) Pertimbangan Ekspansi Vertikal

Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "Elastic Scaling"###Elastic Scaling(. Selama proses desain, kami menemukan bahwa karena verifikasi blok rollup tidak tetap dijalankan di satu core tertentu, ini bisa 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 dialokasikan untuk rollup. Penyerang mungkin memanfaatkan hal ini dengan mengirimkan blok yang sudah diverifikasi secara sah berulang kali ke core yang berbeda, secara jahat menghabiskan sumber daya, sehingga mengurangi throughput dan efisiensi keseluruhan rollup.

Tujuan Polkadot adalah untuk mempertahankan elastisitas rollup dan pemanfaatan sumber daya rantai relai tanpa mempengaruhi karakteristik kunci sistem.

) 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 bisa 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 yang Tidak Kompromi

Solusi yang dipilih oleh Polkadot adalah: menyerahkan masalah sepenuhnya kepada fungsi konversi status rollup ###Runtime(. Runtime adalah satu-satunya sumber tepercaya untuk semua informasi konsensus, oleh karena itu harus dinyatakan secara jelas dalam output di mana verifikasi harus dilakukan pada inti Polkadot.

Desain ini memberikan jaminan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang pada proses ketersediaan untuk konversi status rollup, dan memastikan keakuratan distribusi core melalui protokol ekonomi kriptografi ELVES.

Sebelum data dari rollup blok ditulis ke lapisan ketersediaan data Polkadot )DA(, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima kuitansi kandidat )candidate receipt( dan bukti validitas )PoV( yang berisi blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi paralel, dan akan dieksekusi ulang oleh validator di rantai penghubung.

Hasil verifikasi mencakup pemilih inti (core selector) yang digunakan untuk menentukan di core mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut apakah konsisten dengan core yang menjadi tanggung jawabnya; jika tidak konsisten, blok tersebut akan dibuang.

Mekanisme ini memastikan bahwa sistem selalu mempertahankan sifat tanpa kepercayaan dan tanpa izin, menghindari perilaku jahat seperti pengendalian posisi verifikasi oleh penyortir, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, tetap dapat mempertahankan elastisitas.

) Keamanan

Dalam proses mengejar skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai penghubung, hanya membutuhkan satu pengurut 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 yang nyata tanpa mengorbankan keamanan.

Universalitas

Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung pelaksanaan perhitungan Turing-complete dalam lingkungan WebAssembly, asalkan eksekusi tunggal selesai dalam waktu 2 detik. Dengan ekspansi elastis, total jumlah perhitungan yang dapat dilakukan dalam setiap siklus 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 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. Contoh:

• Strategi sederhana: selalu gunakan jumlah core 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 otomatis lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.

Interoperabilitas

Polkadot mendukung interoperabilitas antara rollup yang berbeda, sementara penskalaan elastis tidak akan mempengaruhi throughput pengiriman pesan.

Komunikasi pesan antar rollup diimplementasikan oleh lapisan transportasi dasar, ruang blok komunikasi setiap rollup adalah tetap, tidak tergantung pada jumlah inti yang dialokasikan.

Di masa depan, Polkadot juga akan mendukung pesan off-chain ###, dengan relai rantai sebagai kontrol, bukan sebagai data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan perluasan elastis, lebih lanjut memperkuat kemampuan ekspansi vertikal sistem.

Apa saja 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 juga tidak memuaskan.

( Solana

Solana tidak menggunakan arsitektur pemotongan dari 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 dapat terbuka dan diverifikasi sebelumnya:

• Setiap epoch( berlangsung sekitar dua hari atau 432.000 slot) dimulai dengan membagi slot berdasarkan jumlah staking;

• Semakin banyak yang dipertaruhkan, semakin banyak distribusinya. Misalnya, validator yang mempertaruhkan 1% akan mendapatkan sekitar 1% kesempatan untuk menghasilkan blok;

• Semua penghasil blok diumumkan sebelumnya, meningkatkan risiko jaringan mengalami serangan DDoS terarah dan sering mengalami downtime.

PoH dan pemrosesan paralel memiliki tuntutan perangkat keras yang sangat tinggi, yang menyebabkan sentralisasi node validasi. Node yang melakukan staking lebih banyak memiliki peluang lebih besar untuk memproduksi blok, sedangkan node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan meningkatkan risiko sistem mengalami keruntuhan setelah diserang.

Solana mengorbankan desentralisasi dan kemampuan anti-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 pribadi, dengan 256 node, dan dalam kondisi jaringan serta perangkat keras yang ideal. Sementara Polkadot telah mencapai 128K TPS di jaringan publik yang terdesentralisasi.

Mekanisme konsensus TON memiliki potensi risiko keamanan: identitas node verifikasi shard dapat terungkap sebelumnya. Whitepaper TON juga dengan jelas menyatakan bahwa meskipun ini dapat mengoptimalkan bandwidth, hal itu juga dapat disalahgunakan secara jahat. Karena kurangnya mekanisme "kepailitan penjudi", penyerang dapat menunggu shard tertentu sepenuhnya dikendalikan oleh mereka, atau dengan serangan DDoS dapat memblokir validator yang jujur, sehingga mengubah status.

Sebaliknya, validator Polkadot dialokasikan secara acak dan pengungkapannya tertunda, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Serangan memerlukan taruhan semua kontrol untuk berhasil; selama ada satu validator yang jujur yang memulai sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang yang mempertaruhkan.

) Avalanche

Avalanche menggunakan arsitektur mainnet + subnet untuk ekspansi, mainnet terdiri dari transfer X-Chain###, ~4.500 TPS###, kontrak pintar C-Chain(, ~100--200 TPS), dan P-Chain( yang mengelola validator dan subnet).

Setiap subnet memiliki TPS teoritis mencapai ~5.000, mirip dengan pemikiran Polkadot: mengurangi beban pada shard tunggal untuk mencapai skala. Namun, Avalanche memungkinkan validator untuk memilih secara bebas untuk berpartisipasi dalam subnet, dan subnet dapat menetapkan persyaratan tambahan seperti geografis, KYC, dll., yang mengorbankan desentralisasi dan keamanan.

Di Polkadot, semua rollup berbagi jaminan keamanan yang seragam; sementara subnet Avalanche tidak memiliki jaminan keamanan default, beberapa bahkan bisa 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 langsung menyelesaikan masalah di lapisan dasar. 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 mengakibatkan kurangnya keamanan, terisolasi satu sama lain, dan tinggi latensi ( yang harus menunggu periode bukti penipuan, biasanya beberapa hari ) dan masalah lainnya.

(# ZK Rollup

Implementasi ZK rollup terbatas oleh jumlah data yang dapat diproses per transaksi. Permintaan komputasi untuk menghasilkan bukti nol-pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semuanya" rentan menyebabkan sentralisasi sistem. Untuk menjamin TPS, ZK rollup seringkali 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 adalah sekitar 2x10^6 kali dari protokol keamanan ekonomi inti Polkadot.

Selain itu, masalah ketersediaan data dari ZK rollup juga akan memperburuk kelemahannya. Untuk memastikan bahwa siapa pun dapat memverifikasi transaksi, data transaksi lengkap 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 ditentukan untuk efisiensi. Sebaliknya, Polkadot mencapai keseimbangan multidimensional 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 dijunjung oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung perkembangan jangka panjang Web3.