Perimbangan Ekstensibilitas: Pilihan Polkadot dan Web3

Di era di mana teknologi blockchain terus mencari peningkatan efisiensi, satu masalah kunci perlahan muncul: bagaimana meningkatkan skalabilitas tanpa mengorbankan keamanan dan elastisitas sistem? Ini bukan hanya tantangan di tingkat teknis, tetapi juga pilihan mendalam dalam desain arsitektur. Untuk 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 membuat beberapa kompromi dalam mengejar throughput tinggi dan latensi rendah? Apakah model rollup-nya telah mengorbankan desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan menganalisis secara mendalam kompromi dan pengorbanan Polkadot dalam desain skalabilitasnya, dan membandingkannya dengan solusi dari blockchain publik utama lainnya, serta membahas perbedaan pilihan mereka antara kinerja, keamanan, dan desentralisasi.

Tantangan 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 terjadi titik kegagalan tunggal atau kontrol yang dapat mempengaruhi karakteristik desentralisasinya?

Operasi Rollup bergantung pada penyortir yang terhubung ke rantai penghubung, yang komunikasinya menggunakan mekanisme yang disebut 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 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.

pertimbangan ekspansi vertikal

Rollup dapat mencapai skala vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan melalui fitur "skala elastis". Selama proses desain, ditemukan bahwa karena validasi blok rollup tidak tetap dilaksanakan di satu core tertentu, ini dapat mempengaruhi elastisitasnya.

Karena protokol untuk mengajukan blok ke rantai penghubung bersifat tanpa izin dan tanpa kepercayaan, siapa pun dapat mengajukan blok untuk diverifikasi di salah satu inti yang dialokasikan untuk rollup. Penyerang dapat memanfaatkan hal ini dengan mengajukan kembali blok yang sah yang telah diverifikasi sebelumnya ke inti yang berbeda, secara jahat menghabiskan sumber daya, sehingga mengurangi keseluruhan throughput dan efisiensi rollup.

Tujuan Polkadot adalah untuk mempertahankan elastisitas rollup dan pemanfaatan sumber daya rantai relay 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 penyortir yang tidak berperilaku jahat, sehingga memastikan keberlangsungan rollup.

Namun, dalam filosofi desain Polkadot, kita tidak dapat membuat asumsi kepercayaan terhadap sequencer, karena harus mempertahankan karakteristik "tanpa kepercayaan" dan "tanpa izin" pada sistem. Siapa pun seharusnya dapat menggunakan protokol collator untuk mengajukan permintaan perubahan status rollup.

Polkadot: Solusi Tanpa Kompromi

Solusi yang dipilih oleh Polkadot akhirnya adalah: menyerahkan masalah sepenuhnya kepada fungsi transisi 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.

Desain ini mencapai perlindungan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang terhadap transisi status rollup dalam proses ketersediaan, dan memastikan keakuratan alokasi inti melalui protokol ekonomi kriptografi ELVES.

Sebelum data dari rollup block ditulis ke lapisan ketersediaan data Polkadot, sekelompok kecil yang terdiri dari sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima kupon kandidat dan bukti validitas yang diajukan oleh sorter, yang berisi rollup block dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi parachain dan dieksekusi ulang oleh validator di relay chain.

Hasil verifikasi mencakup sebuah pemilih inti (core selector) yang digunakan untuk menentukan di core mana blok harus diverifikasi. Verifikator akan membandingkan apakah indeks tersebut sesuai dengan core 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, dan memastikan bahwa bahkan jika rollup menggunakan beberapa core, ia tetap dapat mempertahankan elastisitas.

Keamanan

Dalam upaya mencapai skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai relay, hanya memerlukan satu penyortir yang jujur untuk menjaga kelangsungan hidup.

Dengan bantuan protokol ELVES, Polkadot memperluas keamanan secara menyeluruh 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 eksekusi komputasi Turing lengkap dalam lingkungan WebAssembly, asalkan eksekusi tunggal diselesaikan dalam waktu 2 detik. Dengan bantuan ekspansi elastis, jumlah total komputasi yang dapat dieksekusi 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 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 di on-chain atau off-chain. Contohnya:

• Strategi sederhana: selalu gunakan jumlah tetap core, atau sesuaikan secara manual di luar rantai;

• Strategi ringan: Memantau beban transaksi tertentu di mempool node;

• Strategi otomatis: Mengatur sumber daya dengan memanggil layanan coretime secara awal 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 fleksibel 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 pengiriman pesan di luar rantai, dengan rantai relai sebagai kontrol, bukan sebagai data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan peningkatan elastisitas, yang lebih lanjut memperkuat kemampuan skala vertikal sistem.

Apa saja kompromi yang dibuat oleh protokol lain?

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

Solana

Solana tidak menggunakan arsitektur pengelompokan Polkadot atau Ethereum, melainkan menerapkan arsitektur lapisan tunggal yang memiliki throughput tinggi untuk mencapai skalabilitas, 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 dibagikan berdasarkan jumlah staking;

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

• Semua penambang yang menghasilkan blok diumumkan sebelumnya, meningkatkan risiko jaringan mengalami serangan DDoS terarah dan seringnya downtime.

PoH dan pemrosesan paralel memiliki persyaratan perangkat keras yang sangat tinggi, yang menyebabkan sentralisasi node verifikasi. Semakin banyak node yang dipertaruhkan, semakin besar peluang mereka untuk menghasilkan blok, sementara node kecil hampir tidak memiliki slot, yang semakin memperburuk sentralisasi, serta meningkatkan risiko sistem menjadi lumpuh setelah diserang.

Solana mengorbankan desentralisasi dan kemampuan tahan serangan untuk mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh di bawah Polkadot yang 172.

TON

TON 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 yang terdesentralisasi.

Mekanisme konsensus TON memiliki kerentanan keamanan: identitas node verifikasi shard akan terpapar sebelumnya. Buku putih TON juga secara jelas menunjukkan bahwa meskipun ini dapat mengoptimalkan bandwidth, tetapi juga dapat disalahgunakan oleh pihak jahat. Karena kurangnya mekanisme "kebangkrutan penjudi", penyerang dapat menunggu sebuah shard sepenuhnya dikuasai olehnya, atau dengan melakukan serangan DDoS untuk memblokir validator yang jujur, sehingga merubah status.

Sebaliknya, validator Polkadot dialokasikan secara acak dan diungkapkan dengan penundaan, sehingga penyerang tidak dapat mengetahui identitas validator sebelumnya. Serangan harus mempertaruhkan semua kontrol untuk berhasil; selama ada satu validator jujur yang mengajukan sengketa, serangan akan gagal dan menyebabkan kerugian bagi penyerang.

Avalanche

Avalanche menggunakan arsitektur mainnet + subnetwork untuk skalabilitas, di mana mainnet terdiri dari X-Chain (transfer, ~4.500 TPS), C-Chain (smart contract, ~100-200 TPS), dan P-Chain (mengelola validator dan subnetwork).

Setiap subnet memiliki TPS teoritis mencapai ~5.000, mirip dengan pendekatan 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, dll., mengorbankan desentralisasi dan keamanan.

Di Polkadot, semua rollup berbagi jaminan keamanan yang seragam; sementara subnet Avalanche tidak memiliki jaminan keamanan yang default, beberapa bahkan bisa sepenuhnya terpusat. Jika ingin meningkatkan keamanan, masih perlu berkompromi dalam kinerja, dan sulit untuk memberikan janji keamanan yang deterministik.

Ethereum

Strategi skalabilitas Ethereum bertaruh pada skalabilitas lapisan rollup, alih-alih menyelesaikan masalah di lapisan dasar langsung. Cara 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, memiliki masalah keamanan yang kurang, terisolasi satu sama lain, dan memiliki latensi tinggi (diperlukan waktu untuk menunggu periode bukti penipuan, biasanya beberapa hari).

ZK Rollup

Implementasi ZK rollup dibatasi oleh jumlah data transaksi 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 dapat menyebabkan kemacetan jaringan dan peningkatan gas saat permintaan tinggi, mempengaruhi pengalaman pengguna.

Dibandingkan, biaya ZK rollup yang Turing lengkap sekitar 2x10^6 kali dari protokol keamanan ekonomi kripto inti Polkadot.

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

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