Keseimbangan antara Skalabilitas, Keamanan, dan Desentralisasi: Pilihan Teknologi Polkadot

Di era blockchain yang terus mengejar efisiensi yang lebih tinggi, sebuah pertanyaan kunci semakin muncul: apakah perlu mengorbankan keamanan dan elastisitas sistem saat meningkatkan kinerja skalabilitas?

Ini bukan hanya tantangan di tingkat teknologi, tetapi juga pilihan mendalam dalam desain arsitektur. Untuk 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 pengorbanan dalam mencapai tujuan throughput tinggi dan latensi rendah? Apakah model rollup-nya telah mengorbankan desentralisasi, keamanan, atau interoperabilitas jaringan?

Artikel ini akan membahas masalah-masalah ini, menganalisis secara mendalam pengorbanan dan pertimbangan desain skalabilitas Polkadot, serta membandingkannya dengan solusi dari blockchain publik utama lainnya, mengeksplorasi pilihan jalur yang berbeda di antara kinerja, keamanan, dan Desentralisasi.

Tantangan dalam Desain Ekstensi Polkadot

Keseimbangan antara elastisitas dan Desentralisasi

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

Pengoperasian Rollup bergantung pada penyortir yang menghubungkan rantai perantara, dan komunikasinya menggunakan mekanisme yang disebut protokol collator. Protokol ini sepenuhnya tanpa izin dan tanpa kepercayaan, siapa saja yang memiliki koneksi jaringan dapat menggunakannya, menghubungkan sejumlah kecil node rantai perantara, dan mengajukan permintaan konversi status rollup. Permintaan ini akan diverifikasi oleh salah satu core rantai perantara, hanya perlu memenuhi satu syarat: harus merupakan konversi status yang valid, jika tidak, status rollup tersebut tidak akan dipromosikan.

Pertimbangan perpanjangan 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 verifikasi blok rollup tidak terikat pada satu core tertentu, ini dapat mempengaruhi elastisitasnya.

Karena protokol untuk mengirim blok ke rantai perantara tidak memerlukan izin dan tidak memerlukan kepercayaan, siapa pun dapat mengirimkan blok ke salah satu core yang dialokasikan untuk rollup untuk diverifikasi. Penyerang mungkin memanfaatkan hal ini dengan mengirimkan blok yang sah yang telah diverifikasi sebelumnya 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 penghubung 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 yang tidak akan berperilaku jahat, sehingga menjaga kelangsungan rollup.

Namun, dalam filosofi desain Polkadot, kita tidak dapat 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 Berkompromi

Solusi yang dipilih oleh Polkadot 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 mana.

Desain ini mewujudkan jaminan ganda fleksibilitas dan keamanan. Polkadot akan mengeksekusi ulang transisi status rollup dalam proses ketersediaan, dan memastikan kebenaran distribusi core melalui protokol ekonomi kriptografi ELVES.

Sebelum data dimasukkan ke dalam lapisan ketersediaan data Polkadot pada setiap blok rollup, sekelompok sekitar 5 validator akan terlebih dahulu memverifikasi keabsahannya. Mereka menerima kwitansi kandidat dan bukti validitas yang diajukan oleh penyortir, yang mencakup blok rollup dan bukti penyimpanan yang sesuai. Informasi ini akan diproses oleh fungsi verifikasi paralel chain, dan akan dijalankan ulang oleh validator di relay chain.

Hasil verifikasi mencakup sebuah core selector, yang digunakan untuk menentukan pada core mana blok harus diverifikasi. Validator akan membandingkan indeks tersebut apakah sesuai dengan core yang menjadi tanggung jawabnya; jika tidak sesuai, blok tersebut akan dibuang.

Mekanisme ini memastikan bahwa sistem selalu mempertahankan sifat tanpa perlu percaya dan tanpa izin, menghindari perilaku jahat seperti pengendali yang memanipulasi posisi verifikasi, memastikan bahwa bahkan jika rollup menggunakan beberapa core, tetap dapat mempertahankan elastisitas.

Keamanan

Dalam mengejar skalabilitas, Polkadot tidak mengorbankan keamanan. Keamanan rollup dijamin oleh rantai penghubung, hanya memerlukan satu penyusun jujur untuk menjaga kelangsungan.

Dengan bantuan protokol ELVES, Polkadot akan memperluas keamanan secara menyeluruh ke semua rollup, memverifikasi semua perhitungan di core tanpa perlu membatasi atau mengasumsikan jumlah core yang digunakan.

Oleh karena itu, rollup Polkadot dapat mencapai skalabilitas yang sebenarnya tanpa mengorbankan keamanan.

Universalisme

Ekspansi elastis tidak akan membatasi kemampuan pemrograman rollup. Model rollup Polkadot mendukung eksekusi komputasi Turing lengkap dalam lingkungan WebAssembly, asalkan setiap eksekusi selesai dalam 2 detik. Dengan bantuan ekspansi elastis, jumlah total komputasi yang dapat dieksekusi dalam setiap periode 6 detik meningkat, tetapi jenis komputasinya tidak terpengaruh.

Kompleksitas

Throughput yang lebih tinggi dan latensi yang lebih rendah secara tak terelakkan membawa 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 dari persyaratan RFC103 untuk menyesuaikan diri dengan berbagai skenario penggunaan.

Kompleksitas spesifik tergantung pada strategi manajemen sumber daya dari rollup, yang mungkin bergantung pada variabel di dalam atau di luar rantai. Contohnya:

• Strategi sederhana: selalu gunakan jumlah tetap dari core, atau sesuaikan secara manual melalui off-chain;

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

• Strategi otomatisasi: 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 antar rollup yang berbeda, sementara skalabilitas yang fleksibel tidak akan mempengaruhi 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 di luar rantai, dengan rantai penghubung sebagai antarmuka kontrol, bukan antarmuka data. Peningkatan ini akan meningkatkan kemampuan komunikasi antar rollup seiring dengan peningkatan elastisitas, lebih lanjut memperkuat kemampuan skalabilitas vertikal sistem.

Apa saja pertimbangan yang dibuat oleh protokol lain?

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

Solana

Solana tidak menggunakan arsitektur pemecahan Polkadot atau Ethereum, tetapi mencapai skalabilitas dengan arsitektur lapisan tunggal berkecepatan tinggi, mengandalkan 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 telah dipublikasikan sebelumnya dan dapat diverifikasi:

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

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

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

Solana牺牲去中心化 dan kemampuan anti serangan untuk mengejar TPS, dengan koefisien Nakamoto hanya 20, jauh lebih rendah daripada Polkadot yang memiliki 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 itu, Polkadot telah mencapai 128K TPS di jaringan publik yang terdesentralisasi.

Mekanisme konsensus TON memiliki risiko keamanan: identitas node verifikasi shard akan terungkap sebelumnya. Whitepaper TON juga dengan jelas menyatakan bahwa meskipun ini dapat mengoptimalkan bandwidth, namun juga dapat disalahgunakan dengan niat jahat. Karena kurangnya mekanisme "kebangkrutan penjudi", penyerang dapat menunggu shard tertentu sepenuhnya dikendalikan olehnya, atau dengan serangan DDoS menghalangi validator yang jujur, sehingga mengubah status.

Sebaliknya, validator Polkadot ditugaskan 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 yang jujur yang memicu perselisihan, serangan akan gagal dan menyebabkan kerugian bagi penyerang.

Avalanche

Avalanche menggunakan arsitektur mainnet + subnet untuk skala, 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 secara teoritis dapat mencapai TPS ~5.000, mirip dengan pendekatan Polkadot: mengurangi beban shard tunggal untuk mencapai skala. Namun, Avalanche memungkinkan validator untuk memilih secara bebas untuk berpartisipasi dalam subnet, dan subnet dapat menetapkan persyaratan tambahan seperti geografi, KYC, dan lain-lain, mengorbankan desentralisasi dan keamanan.

Di Polkadot, semua rollup berbagi jaminan keamanan yang seragam; sementara subnet Avalanche tidak memiliki jaminan keamanan default, beberapa bahkan dapat sepenuhnya terdesentralisasi. Jika ingin meningkatkan keamanan, tetap perlu berkompromi pada kinerja, dan sulit untuk memberikan janji keamanan yang pasti.

Ethereum

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

Optimistic Rollup

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

ZK Rollup

Implementasi ZK rollup terbatas oleh jumlah data yang dapat diproses per transaksi. Permintaan komputasi untuk menghasilkan bukti zero-knowledge sangat tinggi, dan mekanisme "pemenang mengambil semua" mudah menyebabkan sistem menjadi terpusat. 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.

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

Selain itu, masalah ketersediaan data 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 lebih 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 ditetapkan demi efisiensi. Sebaliknya, Polkadot mencapai keseimbangan multidimensi 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 yang lebih besar, "skala tanpa kepercayaan" yang dipegang oleh Polkadot mungkin adalah solusi yang benar-benar dapat mendukung perkembangan jangka panjang Web3.