Pengantar

Saat ini, kita sudah melihat proyek mulai bereksperimen dengan Madara untuk rantai aplikasinya. Pragma, Kakarot, Mangata Finance, dan Dojo hanyalah beberapa contohnya. Selama kita percaya pada masa depan multi-rantai dan kekuatan penskalaan zk, kita hanya akan melihat lebih banyak lagi proyek-proyek ini di masa depan. Namun, meningkatnya jumlah rantai aplikasi juga menimbulkan pertanyaan

1. Desentralisasi
2. Komposabilitas
3. Pengalaman pengembangan

Pada postingan kali ini saya akan mencoba menjelaskan masalah yang muncul akibat banyaknya rantai aplikasi dan juga memberikan kemungkinan solusi untuk masalah tersebut yang saya anggap elegan dan optimal untuk Madara dan Starknet. Jika Anda sudah berpengalaman dengan rantai aplikasi dan pengurutan bersama, silakan beralih ke bagian “Tunggu, ini hanya Polkadot lagi”.

Apa yang terjadi di 100 rantai aplikasi?

Katakanlah kita berada di masa depan di mana kita sekarang memiliki 100 rantai aplikasi berbeda yang menggunakan Ethereum. Mari kita atasi semua masalah yang ditimbulkannya.

Desentralisasi yang terfragmentasi

Setiap rantai aplikasi perlu menyelesaikan masalah desentralisasinya sendiri. Saat ini desentralisasi rantai aplikasi tidak sepenting L1, terutama karena kita bergantung pada L1 untuk keamanan. Namun, kita masih memerlukan desentralisasi untuk memastikan keaktifan, ketahanan terhadap sensor dan untuk menghindari keuntungan monopoli (misalnya biaya yang tinggi). Namun, penting juga untuk dicatat bahwa jika setiap rantai aplikasi terus menyelesaikan desentralisasi dengan caranya sendiri, hal ini akan dengan cepat menyebabkan fragmentasi kumpulan validator. Setiap rantai aplikasi harus mengembangkan insentif ekonomi untuk menerima validator baru. Selain itu, validator perlu memilih klien mana yang mereka rasa nyaman untuk dijalankan. Belum lagi hambatan besar untuk masuk yang diciptakan oleh pengembang untuk meluncurkan rantai aplikasi mereka sendiri (vs menerapkan kontrak pintar yang hanya berupa transaksi).

Komposabilitas

Komposabilitas pada dasarnya berarti interaksi lintas aplikasi. Di Ethereum atau Starknet, ini berarti memanggil kontrak lain dan segala sesuatunya ditangani oleh protokol itu sendiri. Namun, dengan rantai aplikasi, hal ini menjadi jauh lebih sulit. Rantai aplikasi yang berbeda memiliki blok dan mekanisme konsensusnya sendiri. Setiap kali Anda mencoba berinteraksi dengan rantai aplikasi lain, Anda perlu memeriksa algoritme konsensus dan jaminan finalitas dengan cermat, lalu menyiapkan jembatan lintas rantai (langsung ke rantai atau melalui L1). Jika Anda ingin berinteraksi dengan 10 rantai aplikasi dengan desain berbeda, Anda harus melakukannya 10 kali berbeda.

Pengalaman pengembangan

Menyelesaikan desentralisasi dan menjembatani tidaklah mudah. Jika hal ini merupakan persyaratan untuk setiap rantai aplikasi, hal ini akan sangat menyulitkan pengembang kontrak pintar untuk membangun rantai aplikasinya sendiri. Selain itu, karena setiap rantai aplikasi mencoba memecahkan masalah ini dengan caranya masing-masing, kita akan segera melihat standar yang berbeda diikuti oleh rantai yang berbeda sehingga semakin sulit untuk bergabung dengan ekosistem tersebut.

Sequencer Bersama dapat mengatasi ini

Sekarang jika Anda mengikuti ruang rantai aplikasi, Anda mungkin pernah mendengar istilah “sequencer bersama”. Ini adalah gagasan untuk memiliki seperangkat validator umum untuk semua rantai yang bertujuan untuk memecahkan masalah yang disebutkan di atas. Begini Cara kerjanya.

Desentralisasi Bersama

Inti dari sequencer bersama adalah Anda tidak perlu memiliki kumpulan validator yang berbeda untuk setiap rantai aplikasi atau L2. Sebaliknya, Anda dapat memiliki seperangkat validator yang sangat efisien dan terdesentralisasi yang mengurutkan blok untuk semua rantai! Bayangkan blok yang berisi transaksi dari 100 rantai aplikasi berbeda. Anda mungkin berpikir ini akan membuat sequencer membengkak karena Anda harus mampu menangani mesin eksekusi untuk setiap rantai aplikasi.

Ya, kamu tidak melakukannya!

Karena saat ini hampir setiap sequencer terpusat, sequencer dianggap sebagai aplikasi tunggal yang mengumpulkan transaksi, memerintahkannya, mengeksekusinya dan memposting hasilnya di L1. Namun, pekerjaan ini dapat dipisahkan menjadi beberapa komponen modular. Demi penjelasan ini, saya akan membaginya menjadi dua.

1. Mesin pesanan: Ini bertanggung jawab untuk mengurutkan transaksi dalam urutan tertentu. Setelah perintah ini diputuskan oleh mesin pesanan, maka HARUS diikuti. Hal ini ditegakkan dengan melakukan perintah ini pada L1 dan memaksa verifikator L1 untuk memeriksa apakah transaksi dieksekusi dalam urutan yang diperlukan.
2. Mesin rollup: Mesin rollup pada dasarnya adalah segala sesuatu yang dilakukan rollup - mengumpulkan transaksi dari pengguna, mengeksekusinya, membuat bukti, dan memperbarui status pada L1. Idealnya, ini dapat dipecah menjadi lebih banyak komponen tetapi kami akan menghindarinya untuk postingan ini.

Di sini, mesin pemesanan adalah sequencer bersama dan mesin rollup pada dasarnya adalah logika rollup. Jadi siklus hidup transaksinya terlihat seperti ini

Sequencer bersama pada dasarnya mengurutkan transaksi di seluruh rollup dan mengkomitnya ke L1. Oleh karena itu, dengan mendesentralisasikan kumpulan sequencer bersama, pada dasarnya Anda mendesentralisasikan semua rollup yang terkait dengan kumpulan sequencer tersebut! Untuk mendapatkan gambaran lebih detail tentang cara kerja sequencer bersama, Anda juga dapat merujuk ke <a href="https://hackmd.io/@EspressoSystems/EspressoSequencer"> artikel 17 yang menakjubkan ini oleh Espresso.

Komposabilitas

Salah satu masalah utama dalam komposisi adalah memahami kapan transaksi diselesaikan di rantai aplikasi lain dan mengambil tindakan sesuai dengan itu di rantai aplikasi Anda. Namun dengan sequencer bersama, kedua rollup yang dapat dikomposisi berbagi blok satu sama lain. Jadi jika transaksi dibatalkan pada rollup B, seluruh blok dibatalkan, dan ini menyebabkan transaksi pada rollup A juga dibatalkan.

Sekarang ini tentu terdengar lebih mudah diucapkan daripada dilakukan. Untuk ini. komunikasi antar rollup harus efisien dan terukur. Sequencer bersama perlu memberikan standar yang tepat tentang bagaimana rollup dapat berkomunikasi, seperti apa seharusnya pesan lintas-rantai, bagaimana menangani peningkatan rollup, dll. Meskipun masalah-masalah ini dapat dipecahkan, namun masalah-masalah tersebut rumit dan tidak mudah untuk diselesaikan.

Pengalaman pengembang

Meskipun sequencer bersama mengabstraksi aspek desentralisasi dan membuat pengiriman pesan lintas rantai lebih mudah, masih ada beberapa standar yang harus diikuti oleh setiap rantai agar kompatibel dengan sequencer bersama. Misalnya, semua transaksi rollup perlu diubah ke dalam format umum yang dapat dipahami oleh sequencer. Demikian pula, blok dari sequencer perlu difilter untuk mengambil transaksi yang relevan. Untuk mengatasi hal ini, saya berasumsi sequencer bersama akan menghasilkan kerangka kerja rollup atau SDK yang mengabstraksi kode boilerplate dan hanya mengekspos bagian logika bisnis kepada pengembang rantai aplikasi.

Berikut diagram tampilan rantai aplikasi dengan sequencer bersama

Tunggu, ini hanya Polkadot lagi

Polkadot mulai mengerjakan masa depan multi-rantai jauh sebelum Ethereum. Faktanya, mereka telah mengerjakannya selama lebih dari 5 tahun dan jika Anda familiar dengan Polkadot, Anda mungkin telah memperhatikan bahwa desain di atas pada dasarnya menciptakan kembali banyak hal yang telah dilakukan Polkadot!

Rantai Relay (Desentralisasi Bersama)

Rantai Relay pada dasarnya adalah mesin pemesanan + L1 pada diagram urutan di atas. Rantai relai

1. Transaksi pesanan di semua parachain (rollup)
2. Ini memverifikasi transaksi yang dieksekusi dengan benar (alih-alih verifikasi zk, ini sebenarnya menjalankan kembali kode eksekusi rollup untuk memverifikasi perbedaan status)

Anda mungkin telah menyadari bahwa relai pada dasarnya adalah sequencer bersama yang kita bahas di atas. Kecuali fakta bahwa rantai relai juga perlu memverifikasi eksekusi (karena Polkadot adalah L1) sedangkan kami menyerahkannya pada Ethereum.

XCM dan XCMP

Kami telah menyebutkan di bagian sebelumnya bahwa jika setiap rantai membangun metodenya sendiri untuk berinteroperasi dengan rantai lain, kami akan segera dipenuhi dengan standar dan format yang berbeda di semua rantai. Anda harus melacak semua format ini untuk setiap rantai yang berinteraksi dengan Anda. Selain itu, Anda juga perlu menjawab pertanyaan seperti apa yang terjadi jika suatu rantai ditingkatkan? Namun, masalah ini dapat diatasi secara elegan dengan memperkenalkan standar yang harus dipatuhi oleh semua jaringan.

Seperti yang sudah Anda duga, Polkadot sudah melakukan hal ini. XCM adalah format perpesanan dan XCMP adalah protokol perpesanan yang dapat digunakan oleh semua rantai media untuk berkomunikasi satu sama lain. Saya tidak akan membahas detailnya tetapi Anda dapat membacanya di sini 5.

Substrat dan Cumulus

Substrat adalah kerangka kerja yang dikembangkan oleh Parity yang dapat digunakan untuk membangun blockchain. Meskipun semua parachain di Polkadot menggunakan substrat, substrat sebenarnya dibuat dengan cara rantai-agnostik. Kerangka kerja ini mengabstraksi semua aspek umum dari blockchain sehingga Anda bisa fokus pada logika aplikasi Anda. Seperti yang kita ketahui, Madara dibangun di atas Substrat, begitu pula Polkadot, Polygon Avail dan masih banyak proyek lainnya. Selain itu, Cumulus adalah middleware di atas Substrat yang memungkinkan Anda menghubungkan rantai Anda ke Polkadot.

Jadi melanjutkan analogi kami seperti sebelumnya, Substrat dan Cumulus dapat dianggap sebagai pengganti kerangka rollup yang memungkinkan Anda membangun rantai aplikasi dan menghubungkannya ke sequencer bersama.

Sequencer Bersama → Rantai Relai
Komposabilitas → XCM dan XCMP
Kerangka Rollup/Tumpukan → Substrat dan Cumulus

Jadi ya, Polkadot lagi-lagi! Selain itu, Polkadot dan Parity memiliki beberapa tim paling berpengalaman dan didanai yang terus membangun Substrat dan Polkadot untuk menambahkan lebih banyak fitur dan membuatnya lebih terukur. Teknologi ini telah teruji selama bertahun-tahun dan memiliki banyak alat pengembangan yang siap digunakan.

Selesaikan Polkadot di Ethereum?

Meskipun benar bahwa Polkadot mulai membangun masa depan multi-rantai jauh sebelum Ethereum, tidak dapat disangkal bahwa saat ini, Ethereum adalah blockchain paling terdesentralisasi dan tempat di mana sebagian besar aplikasi dan likuiditas berada. Namun, bagaimana jika ada cara untuk menghadirkan semua teknologi Polkadot ke dalam ekosistem Ethereum?

Ada! Faktanya, kami sudah memulainya dengan Madara. Madara menggunakan kerangka Substrat untuk memungkinkan siapa pun membangun solusi L2/L3 bertenaga zk mereka sendiri di atas Ethereum. Yang kita butuhkan selanjutnya adalah relay chain Polkadot berupa shared sequencer. Jadi pada dasarnya, jika kita bisa menggunakan kembali rantai relay Polkadot tapi

1. Hapus bagian verifikasi seperti yang terjadi pada L1 melalui zk proofs
2. Komit urutan transaksi ke L1
3. Optimalkan node dan algoritma konsensus untuk mendukung Tendermint/HotStuff

Kita bisa mendapatkan sequencer bersama seperti yang disebutkan sebelumnya. Tentu saja, hal ini lebih mudah diucapkan daripada dilakukan. Namun, saya yakin jalur ini lebih pragmatis daripada membangun kembali sequencer, standar, dan kerangka kerja dari awal. Polkadot telah memecahkan banyak masalah dengan cara agnostik rantai yang dapat kita pinjam untuk Ethereum. Sebagai produk sampingan, kami mendapatkan

1. Sekelompok pengembang aktif yang terus membangun dan mendidik dunia tentang Substrat
2. Perangkat pengembang yang aktif dan komunitas yang kuat
3. Banyak parachain aktif dapat memilih untuk menggunakan Ethereum juga jika mereka ingin melakukannya (kami melihat Astar melakukan hal yang sama baru-baru ini dengan Polygon CDK)

Kesimpulan

Ide utama saya di balik penulisan postingan ini adalah untuk membuka diskusi di antara ekosistem Starknet dan Ethereum yang lebih luas. Saya merasa model pengurutan bersama akan memainkan peran penting dalam desentralisasi tidak hanya di Starknet tetapi juga semua rantai aplikasi yang mempertimbangkan untuk mengembangkannya. Selama kami yakin dengan tesis rantai aplikasi dan penskalaan zk, analisis menyeluruh terhadap model pengurutan bersama tidak dapat dihindari. Terlebih lagi, seiring dengan peralihan Madara ke arah produksi dan Starknet telah mulai melakukan desentralisasi, saya merasa topik ini penting untuk dibahas. Oleh karena itu, saya meminta semua orang yang membaca ini untuk meninggalkan masukan/saran apa pun yang Anda miliki tentang topik ini. Berharap untuk membaca pemikiran Anda!

Lampiran

Polkadot vs Kosmos

Cosmos, mirip dengan Polkadot, telah memecahkan masa depan multi-rantai selama bertahun-tahun. Hasilnya, Cosmos SDK dan IBC telah mengalami banyak perkembangan dan kami juga melihat banyak rantai aplikasi yang dibangun di atas ekosistem Cosmos. Oleh karena itu, wajar jika mempertimbangkan Cosmos juga untuk pendekatan ini. Pandangan pribadi saya tentang topik ini adalah bahwa Polkadot lebih relevan karena memecahkan masalah sequencer bersama sedangkan Cosmos mengharuskan setiap rantai aplikasi untuk membuat set validatornya sendiri. Selain itu, Substrat selalu dibangun dengan cara rantai-agnostik untuk memungkinkan pengembang membangun blockchain tanpa asumsi tentang algoritma konsensus atau ekosistem Polkadot. Hal ini pula yang menjadi alasan kami memilih Substrat untuk Madara. Namun, meskipun demikian, pengalaman saya di Cosmos terbatas dan saya ingin mendengar lebih banyak tentang hal ini dari orang-orang yang lebih berpengalaman! Anda juga dapat mengetahui lebih lanjut tentang perbandingan kedua jaringan di sini

Penafian:

1. Artikel ini dicetak ulang dari [starknet]. Semua hak cipta milik penulis asli [apoorvsadana]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.