Pertimbangan Skalabilitas: Pilihan Antara Polkadot dan Web3

Di era di mana blockchain terus mencari efisiensi yang lebih tinggi, sebuah masalah kunci semakin muncul: bagaimana menjaga keamanan dan elastisitas sistem sambil meningkatkan kinerja? 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.

Sebagai pendorong penting untuk skalabilitas Web3, apakah Polkadot juga telah membuat beberapa kompromi dalam mengejar tujuan throughput tinggi dan latensi rendah? Apakah model rollup-nya mengorbankan desentralisasi, keamanan, atau interoperabilitas jaringan? Artikel ini akan menganalisis secara mendalam trade-off dan pertimbangan desain skalabilitas Polkadot, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, untuk mengeksplorasi pilihan jalur yang berbeda antara kinerja, keamanan, dan desentralisasi.

Tantangan dalam Desain Ekstensi Polkadot

Keseimbangan antara Elastisitas dan Desentralisasi

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

Operasi Rollup bergantung pada penyortir dari rantai penghubung, yang komunikasinya menggunakan mekanisme yang disebut protokol kolator. 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 inti 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 skalabilitas vertikal dengan memanfaatkan arsitektur multi-core Polkadot. Kemampuan baru ini diperkenalkan oleh fitur "skala elastis". Selama proses desain, kami menemukan bahwa karena validasi blok rollup tidak tetap dieksekusi pada satu core tertentu, hal ini dapat mempengaruhi elastisitasnya.

Karena protokol untuk mengirimkan blok ke rantai perantara adalah tanpa izin dan tanpa kepercayaan, siapa pun dapat mengirimkan blok untuk diverifikasi di core mana pun yang dialokasikan untuk rollup. Penyerang mungkin memanfaatkan ini dengan mengirimkan kembali blok yang sah yang telah diverifikasi sebelumnya 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 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 mengandalkan penyortir yang dipercaya secara default tidak akan berperilaku jahat, sehingga memastikan 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 Polkadot adalah: menyerahkan masalah sepenuhnya kepada fungsi transisi status rollup (Runtime). Runtime adalah satu-satunya sumber terpercaya untuk semua informasi konsensus, sehingga harus dinyatakan dengan jelas dalam output di mana verifikasi harus dilakukan pada core Polkadot mana.

Desain ini mewujudkan jaminan ganda antara elastisitas dan keamanan. Polkadot akan melakukan eksekusi ulang transisi status rollup dalam proses ketersediaan, dan memastikan akurasi distribusi core melalui protokol ekonomi terenkripsi ELVES.

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

Hasil verifikasi mencakup sebuah pemilih inti (core selector) yang digunakan untuk menentukan di inti mana blok harus diverifikasi. Verifikator akan membandingkan indeks tersebut apakah sesuai dengan inti yang menjadi tanggung jawabnya; jika tidak sesuai, 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 upaya untuk memperluas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai relai, hanya memerlukan satu pengurut jujur untuk mempertahankan kelangsungan hidup.

Dengan bantuan protokol ELVES, Polkadot akan memperluas keamanan secara menyeluruh ke semua rollup, memvalidasi semua perhitungan di atas core, tanpa 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 programabilitas 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 setiap periode 6 detik dapat 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 dari 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. 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 lebih awal melalui data historis dan antarmuka XCM.

Meskipun cara otomatisasi lebih efisien, biaya implementasi dan pengujian juga meningkat secara signifikan.

interoperabilitas

Polkadot mendukung interoperabilitas antar rollup yang berbeda, dan skalabilitas elastis tidak akan mempengaruhi throughput pengiriman pesan.

Komunikasi pesan antar rollup diimplementasikan oleh lapisan transmisi dasar, 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 relai sebagai kontrol, bukan sebagai data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan peningkatan skala elastis, 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, jika dilihat dari 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, tetapi mencapai 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 dipublikasikan sebelumnya dan dapat diverifikasi:

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

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

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

PoH dan pemrosesan paralel memiliki tuntutan yang sangat tinggi terhadap perangkat keras, 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 dan meningkatkan risiko sistem menjadi tidak berfungsi setelah diserang.

Solana mengorbankan desentralisasi dan ketahanan terhadap serangan demi 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, serta dalam kondisi jaringan dan perangkat keras yang ideal. Sementara Polkadot telah mencapai 128K TPS di jaringan publik terdesentralisasi.

Mekanisme konsensus TON memiliki risiko keamanan: identitas node validasi shard dapat terungkap lebih awal. Buku putih TON juga dengan jelas menyatakan, meskipun ini dapat mengoptimalkan bandwidth, tetapi juga dapat disalahgunakan. Karena kurangnya mekanisme "pembayaran bangkrut", penyerang dapat menunggu shard tertentu sepenuhnya dikuasai olehnya, atau mengganggu validator yang jujur melalui serangan DDoS, sehingga mengubah status.

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

Avalanche

Avalanche menggunakan arsitektur mainnet + subnet untuk melakukan skalabilitas, 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 teoretis hingga ~5.000, mirip dengan pendekatan Polkadot: mengurangi beban pada shard tunggal untuk mencapai skalabilitas. Namun, Avalanche memungkinkan validator memilih untuk berpartisipasi dalam subnet secara bebas, dan subnet dapat menetapkan persyaratan tambahan seperti geografis, KYC, dan sebagainya, mengorbankan desentralisasi dan keamanan.

Di Polkadot, semua rollup berbagi jaminan keamanan yang bersatu; sementara subnet Avalanche tidak memiliki jaminan keamanan secara default, beberapa bahkan bisa sepenuhnya terpusat. Jika ingin meningkatkan keamanan, perlu mengorbankan kinerja, dan sulit untuk memberikan janji keamanan yang pasti.

Ethereum

Strategi skala 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, memiliki masalah keamanan yang kurang, saling terisolasi, dan waktu tunda yang tinggi ( harus menunggu periode bukti penipuan, biasanya beberapa hari ) dan masalah lainnya.

ZK Rollup

Implementasi ZK rollup terbatas oleh jumlah data yang dapat diproses dalam satu transaksi. Permintaan komputasi untuk menghasilkan bukti nol pengetahuan sangat tinggi, dan mekanisme "pemenang mengambil semuanya" cenderung mengarah pada 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 Turing lengkap adalah sekitar 2x10^6 kali 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 lebih 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 terprediksi demi efisiensi, melainkan mencapai keseimbangan multidimensi antara keamanan, desentralisasi, dan kinerja tinggi melalui desain protokol yang elastis dan tanpa izin, lapisan keamanan yang seragam, dan mekanisme manajemen sumber daya yang fleksibel.

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