Pertimbangan Skalabilitas Web3: Solusi Polkadot

Dalam era blockchain yang terus mengejar efisiensi yang lebih tinggi, sebuah masalah kunci mulai muncul: bagaimana menjaga keamanan dan elastisitas sistem sambil meningkatkan kinerja skala?

Ini bukan hanya tantangan di tingkat teknologi, tetapi juga pilihan 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.

Polkadot sebagai pendorong penting untuk skalabilitas Web3, apakah model rollup-nya mengorbankan desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan menganalisis secara mendalam kompromi dan pertimbangan desain skalabilitas Polkadot, serta membandingkannya dengan solusi dari blockchain utama lainnya, untuk mengeksplorasi perbedaan pilihan jalur mereka antara kinerja, keamanan, dan desentralisasi.

Tantangan yang Dihadapi dalam Desain Ekspansi Polkadot

Keseimbangan antara elastisitas dan desentralisasi

Arsitektur Polkadot bergantung pada jaringan validator dan rantai relai, apakah ini mungkin memperkenalkan risiko sentralisasi dalam beberapa aspek? Apakah mungkin ada titik kegagalan tunggal atau kontrol yang dapat mempengaruhi karakteristik desentralisasinya?

Operasi Rollup bergantung pada penyortir yang terhubung ke 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 mengirimkan 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 tersebut tidak akan dipromosikan.

kompromi dari perpanjangan vertikal

Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi core Polkadot. Kemampuan baru ini diperkenalkan melalui fitur "ekspansi elastis". Selama proses desain, kami menemukan bahwa karena validasi blok rollup tidak tetap dijalankan pada satu core tertentu, ini dapat memengaruhi elastisitasnya.

Karena protokol untuk mengirim blok ke rantai perantara adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirim blok untuk divalidasi oleh salah satu inti yang dialokasikan untuk rollup. Penyerang mungkin memanfaatkan hal ini dengan mengirimkan kembali blok yang sah yang telah divalidasi sebelumnya ke inti yang berbeda, secara jahat menghabiskan sumber daya, sehingga mengurangi throughput dan efisiensi keseluruhan rollup.

Tujuan Polkadot adalah untuk mempertahankan fleksibilitas 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 secara default mempercayai pengurut yang tidak berperilaku jahat, sehingga menjamin aktivitas 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: 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 mencapai perlindungan ganda antara fleksibilitas dan keamanan. Polkadot akan mengeksekusi kembali transisi status rollup dalam proses ketersediaan dan memastikan keakuratan distribusi inti melalui protokol ekonomi terenskripsi ELVES.

Sebelum data dari rollup block ditulis ke lapisan ketersediaan data (DA) Polkadot, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima kupon kandidat dan bukti validitas yang diserahkan oleh sorter, yang berisi rollup block dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi validasi parachain, yang akan dijalankan ulang oleh validator di relay chain.

Hasil verifikasi mencakup pemilih inti (core selector) yang digunakan untuk menentukan di inti mana blok harus diverifikasi. Validator akan membandingkan apakah indeks tersebut konsisten dengan inti 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 manipulasi posisi verifikasi oleh aktor jahat seperti sorter, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, ia tetap dapat mempertahankan elastisitas.

Keamanan

Dalam mengejar skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai relay, hanya diperlukan satu penyusun yang jujur untuk menjaga keberlangsungan.

Dengan bantuan protokol ELVES, Polkadot memperluas keamanan secara utuh 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 skala nyata tanpa mengorbankan keamanan.

Universalitas

Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung pelaksanaan komputasi Turing lengkap dalam lingkungan WebAssembly, asalkan eksekusi tunggal selesai dalam waktu 2 detik. Dengan bantuan ekspansi elastis, jumlah total komputasi yang dapat dilakukan dalam setiap 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 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 melalui off-chain;

• 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 antara berbagai rollup, sementara skalabilitas yang elastis tidak mempengaruhi throughput pengiriman pesan.

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

Di masa depan, Polkadot juga akan mendukung pengiriman pesan di luar rantai, dengan rantai relay sebagai kontrol, bukan sebagai data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan peningkatan elastisitas, lebih lanjut memperkuat kemampuan skala vertikal sistem.

Apa saja kompromi yang dibuat oleh protokol lain?

Seperti yang kita ketahui, peningkatan kinerja sering kali mengorbankan desentralisasi dan keamanan. Namun, dari perspektif koefisien Nakamoto, meskipun beberapa pesaing Polkadot memiliki tingkat desentralisasi yang lebih rendah, kinerja mereka juga tidak memuaskan.

Sebuah Blockchain A

Sebuah blockchain publik A tidak menggunakan arsitektur sharding Polkadot atau Ethereum, melainkan menggunakan arsitektur lapisan tunggal dengan throughput tinggi untuk mencapai skalabilitas, bergantung pada bukti sejarah, pemrosesan paralel CPU, dan mekanisme konsensus berbasis pemimpin, dengan TPS teoritis mencapai 65.000.

Salah satu desain kunci adalah mekanisme penjadwalan pemimpin yang terbuka dan dapat diverifikasi sebelumnya:

• 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% peluang untuk memproduksi blok;

• Semua pembuat blok diumumkan sebelumnya, meningkatkan risiko jaringan mengalami serangan DDoS terarah dan seringnya pemadaman.

Sejarah membuktikan bahwa pemrosesan paralel memerlukan persyaratan perangkat keras yang sangat tinggi, yang menyebabkan sentralisasi node verifikasi. Semakin banyak node yang dipertaruhkan, semakin besar kemungkinan mereka untuk memproduksi blok, sementara node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi dan meningkatkan risiko sistem menjadi lumpuh setelah diserang.

Sebuah blockchain publik A mengorbankan desentralisasi dan kemampuan tahan serangan demi mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh lebih rendah dari Polkadot yang memiliki 172.

Beberapa Blockchain B

Sebuah blockchain publik B mengklaim TPS dapat mencapai 104.715, tetapi angka ini dicapai dalam jaringan pengujian pribadi, dengan 256 node, di bawah kondisi jaringan dan perangkat keras yang ideal. Sementara itu, Polkadot telah mencapai 128K TPS di publik terdesentralisasi.

Ada risiko keamanan dalam mekanisme konsensus pada blockchain publik B: identitas node verifikasi shard akan terungkap sebelumnya. Whitepaper blockchain publik B juga secara jelas menyatakan bahwa meskipun ini dapat mengoptimalkan bandwidth, hal ini juga dapat disalahgunakan. Karena kurangnya mekanisme "bangkrut penjudi", penyerang dapat menunggu shard tertentu berada di bawah kendalinya sepenuhnya, atau memblokir validator yang jujur melalui serangan DDoS, sehingga dapat memanipulasi status.

Sebagai perbandingan, validator Polkadot ditugaskan secara acak dan pengungkapannya ditunda, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Penyerang harus mempertaruhkan seluruh kendali untuk berhasil, dan jika ada satu validator yang jujur mengajukan sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang.

Sebuah Blockchain C

Sebuah blockchain publik C menggunakan arsitektur mainnet + subnet untuk melakukan 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 teoritis TPS dapat mencapai ~5.000, mirip dengan pendekatan Polkadot: mengurangi beban shard tunggal untuk mencapai skalabilitas. Namun, suatu blockchain C mengizinkan 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 di blockchain publik C tidak memiliki jaminan keamanan secara default, beberapa bahkan bisa sepenuhnya terpusat. Jika ingin meningkatkan keamanan, masih perlu mengorbankan kinerja, dan sulit untuk memberikan komitmen keamanan yang pasti.

Ethereum

Strategi skalabilitas Ethereum adalah dengan bertaruh pada skalabilitas lapisan rollup, bukan dengan langsung menyelesaikan masalah di lapisan dasar. Pendekatan ini pada dasarnya tidak menyelesaikan masalah, tetapi hanya memindahkan masalah ke lapisan di atas tumpukan.

Optimis Rollup

Saat ini, sebagian besar Optimistic rollup bersifat terpusat (beberapa bahkan hanya memiliki satu sequencer), yang menyebabkan masalah seperti kurangnya keamanan, terisolasi satu sama lain, dan latensi tinggi (harus menunggu periode bukti penipuan, biasanya beberapa hari).

ZK Rollup

Implementasi ZK rollup terbatas pada jumlah data transaksi 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 peningkatan gas saat permintaan tinggi, mempengaruhi pengalaman pengguna.

Jika dibandingkan, biaya ZK rollup yang Turing lengkap sekitar 2x10^6 kali lipat dari protokol keamanan ekonomi kriptografi inti Polkadot.

Selain itu, masalah ketersediaan data pada 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 memilih jalan untuk mengorbankan desentralisasi demi kinerja, atau mengorbankan kepercayaan yang sudah ditentukan demi efisiensi, melainkan mencapai keseimbangan multidimensi antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang dapat diperluas secara elastis, tanpa izin, lapisan keamanan yang terintegrasi, dan mekanisme pengelolaan sumber daya yang fleksibel.

Dalam mengejar aplikasi skala yang lebih besar, "skala tanpa kepercayaan" yang dipegang oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung perkembangan jangka panjang Web3.